CRUSSPICSTMPL
Tämä heuristiikka pureutuu laatuun. Tämä kattaa käytännössä kaikki "itility"-asiat (plus pari muuta). En käy tässä läpi muuta kuin englanninkielisen sisällön: C = Capability, R = Reliability, U = Usability, S = Security, S = Scalability, P = Performance, I = Installability, C = Compatibility, S = Supportability, T = Testability, M = Maintainability, P = Portability, L = Localizability. Jokainen laatukriteeri saattaa nostaa tai laskea toisen kriteerin tärkeyttä, ja puutteet yhdessä voivat johtaa puutteeseen toisessa. Kaikesta huolimatta laadulliset puutteet johtavat tuotteen arvon vähenemiseen.
Kyvykkyys tai kykenevyys (näiden "itilyjen" suomentaminen on melko hankalaa joskus) viittaa siihen, että onko järjestelmällä kyky käsitellä tiettyjä asioita. Onko järjestelmällä oikeuksia suorittaa sisäisiä tai ulkoisia toimintoja. Hyvänä esimerkkinä luku ja kirjoitusoikeudet. Tämä voisi ehkä liipata läheltä "auhtorizability"-sanaa (vaikka se ei ehkä sana olekaan).
Luotettavuus on periaatteessa itseään selittävä asia, jolla mitataan järjestelmän kykyä suorittaa prosesseja pitkällä ajalla virheettä.
Käytettävyys on oma tieteenalansa sellaisenaan, joten en tässä puutu käytettävyyteen sen kummemmin. Käytettävyys saattaa kuitenkin vähentää esimerkiksi turvallisuutta, jos käyttäjälle näytetään käytettävyyden nimissä näytetään käyttäjälle tietoja, joita hänen ei ole pakko nähdä. Turvallisuus tuo omalta osaltaan ristiriitaa monen laatukriteerin tarkasteluun. Voidaanko luoda esimerkiksi käytettävyyttä ilman että turvallisuus kärsii? Voidaanko luoda turvallisuutta ilman että suorituskyky tai asennettavuus kärsii? Turvallisuusaspekteja on lisäksi lukematon määrä, joten laatukriteerien keskenäinen priorisointi turvallisuutta vasten on joskus vaikeaa.
Skaalautuvuus tarkoittaa järjestelmän kykyä tukea kasvua. Suorituskyky tarkoittaa järjestelmän kykyä suoriutua tietomääristä, jotka järjestelmää tällä hetkellä kuormittaa (tai oletetuista raja-arvoista).
Asennettavuus on käytännössä kykyä tulla asennetuksi eri alustoille. Tämä ei ole validi esimerkiksi webbisoftissa muuten kuin selaimen yhteydessä tarkasteltaessa. Yhteensopivuus liittyy myös selaimiin, mutta myös kaikkiin järjestelmiin jotka kommunikoivat toistensa kanssa. Siirrettävyys koskee osittain asennettavuutta, mutta tämä liittyy siis softan siirtämistä uuteen rautaan, tms.
Tuettavuus, ylläpidettävyys ja testattavuus ovat ominaisuuksia, joitka tukevat laatua vaikka eivät sellaisenaan suoraan heikennä tai vahvista laatua. Ylläpidettävyydellä voidaan helpottaa jatkokehitystä, debugausta, jne. kun taas tuettavuudella tarkoitetaan kykyä jatkaa elinkaarta matalalilla kuluilla. Eli tukeminen ei tule kalliimmaksi kuin uuden softan tekeminen alusta.
Lokalisointi on maakohtaistamista eli kilisyyksiä tai aikavyöhykkeitä. Lokalisaatio tulee erityisen tärkeäksi, kun palvelua käytetään ympäri maailmaa, valtiota.
Pidän itse edelleen lyhyistä heuristiikoista, koska en muista mitään noin pitkää. FURPS riittää aika pitkälle (functionality, usability, reliability, performance, security/safety & supportability - valitse mieluisin S). Towo Toivolan joskus muotoilema pidempi versio TFIRPUSS myös iskee aika kivasti vielä, eli lisätään testability ja interoperability. Tuo I on erityinen suosikkini, kun muistuttelee ettei riitä että meidän pala toimii, jos se ei toimi toimintaympäristössään. Muistan eräänkin ilmaistuotteen joka disabloi vastaavan maksullisen yhteensopivuusongelmien vuoksi.
ReplyDeleteNäiden Boltonin kasaamien heuristiikoiden lisäksi haluaisin kuulla lisää tarpeeseen kasatuista heuristiikoista. Nyt nämä tuppaavat kasaantuvan "best practises" -muotoon eli noudatetaan sitä mitä joku joskus vakuuttavasti sanoi ja oikeutetaan itsellemme sen toimivuus.
ReplyDeleteEsimerkkinä heuristiikka SAMI, Simple Available Magnificent Intert-adjective-here. Voisin ottaa asiakseni myydä ja vakuuttaa, että tuo on hyvä juttu. Voisin jopa perustella jokaisen noista kohdista ja tapella alan gurujen kanssa seminaareissa ja illanistujaisissa tuon puolesta.
Sen sijaan kunnioitan Boltonin toivetta; Kasatkaa itsellenne toimiva heuristiikka tai useita sen pohjalta mitä olette itse oppineet ja mitä ala on oppinut. RST-kurssin innoittamana loin itselleni HTSM-mindmapin (Heuristic Test Strategy Model), josta alkaa muodostua mielettömän monimutkainen häkkyrä, joka venyy kauas kirjainlyhenteiden ulottumattomiin. Siellä ovat Boltonin lyhenteet aivan kuten Maaretin ja Towonkin, siellä ovat Whittakerin "rundit" (tours), hyvät jutut TMapista ja ISTQB:stä, herkkuja standardimaailmasta (mm. ISO9126), tekniikoita, input/output-variaatioita, muistilistaa koodareiden heikkouksista, jne. jne. Ja kaikki on vasta alkua. Se on kuin monitahoinen kemiallinen kaava, joka antaa lupauksen jostain suuremmasta; Testauksen syöpälääkkeestä. Jos sille pitäisi kuvata lyhenne, olisi lopputulos jotain tyyliin maailmankaikkeutta kuvaava japanilainen kanji-merkkisarja...
No jopas nyt innostuin! :)
Sami... Mitä? XD
ReplyDeleteHaluaisin tuon ko. kartan kyllä nähdä!
Itse ole kehitellyt turvallisuustestauksen heuristiikkaa, joka ottaa oppia Mike Andrewsin ajatuksista softatestauksen saralla. Pistän sen luettavaksi, kun olen saanut lisää lihaa luiden ympärille.