Copyright Oy Laatukonsultointi P. Kantelinen Ab  

Tsekkilista teknisen määrittelyn (arkkitehtuurin) tarkastamiseen

• Kattaako tekninen määrittely kaikki vaatimusmäärittelyn ja toiminnallisen määrittelyn vaatimukset.
• Oliko toiminnallinen määrittely riittävän tarkka, laaja ja yksityiskohtainen teknisen määrittelyn pohjaksi.
• Muodostaako toiminnallinen määrittely ja tekninen määrittely yhdessä riittävän yksityiskohtaisen pohjan
  • yksityiskohtaiselle suunnittelulle
  • toteutukselle
  • integrointitestauksen ja -testitapausten suunnittelulle.
• Onko teknisen määrittelyn dokumentointimallia sovellettu tarkoituksenmukaisesti.
• Onko suunnittelumenetelmiä sovellettu tarkoituksenmukaisesti.
• Onko kaikki yleisestä poikkeavat merkintätavat, symbolit ja konventiot dokumentoitu ja selitetty.
• Onko jokin kohta saanut enemmän/vähemmän huomiota kuin se ansaitsee.
• Onko kuvia käytetty riittävästi ja tarkoituksenmukaisesti.
• Ovatko kuvat ja teksti sopusoinnussa keskenään.
• Onko arkkitehtuuri
  • ymmärrettävä
  • ylläpidettävä, helposti laajennettava ja joustava
  • liian yleinen tai liian rajoittunut
  • tehokas
  • helposti testattava.
• Onko jokin kohta suunniteltu samalla tavalla kuin aikaisemminkin. Jos on, niin miksi ja onko se tarkoituksenmukaista tässä tilanteessa.
• Onko erilaiset poikkeustilanteet ja niihin reagointi tai niistä toipuminen huomioitu.
• Onko määritelty politiikka, miten poikkeustilanteisiin - sanoma saapuu väärään aikaan, ei saavu ollenkaan, saapuu virheellisenä, jne. - reagoidaan ja heijastuuko politiikka oikealla tavalla arkkitehtuurissa.
• Onko määritelty politiikka ja yleismoduuli(t) virheilmoitusten antamiseen, kuittaamiseen ja virheistä toipumiseen.
• Onko yksiköiden tai moduulien (prosessit/taskit, luokat/pakkaukset, funktiot/aliohjelmat, jne.) väliset kytkennät ja kytkentöjen tiukkuus minimoitu.
• Onko kunkin yksikön tai moduulin (prosessi/taski, luokka/pakkaus, funktio/aliohjelma, jne.) kiinteys hyväksyttävä.
• Onko globaalia dataa käytetty. Jos on, onko se perusteltua ja onko se dokumentoitu hyvin.
• Onko
  • algoritmit
  • tietorakenteet
  • tiedostot/tietokannat
  • toteutusratkaisut
  • laitteet
  • jne.

• Onko ylipäätään varauduttu siihen, että tehtyjä ratkaisuja on mahdollisimman helppo
  • muuttaa
  • korjata
  • vaihtaa
  • optimoida
• Onko arkkitehtuuri liian "kerrostettu" abstraktio-/hierarkiatasoihin (josta voi seurata suorituskykyongelmia).
• Onko ratkaisu liian vähän "kerrostettu" (josta voi seurata ylläpito ja ymmärrettävyysongelmia).
• Onko aiemmin tehtyä työtä (yksiköitä, moduuleita, algoritmeja, suunnitteluratkaisuja, jne.) käytetty uudelleen aina, kun se on mahdollista tai tarkoituksenmukaista.
• Voiko tätä arkkitehtuuria tai jotain sen osaa käyttää uudelleen muualla sellaisenaan.
• Voiko tätä arkkitehtuuria tai jotain sen osaakäyttää uudelleen muualla hieman muutettuna. Jos voi, onko tätä ratkaisua syytä muuttaa nyt.
• jne.

Reaali-aikajärjestelmät:

• Onko taskeja/prosesseja liikaa tai liian vähän, onko taski-/prosessijako tehty oikein tai tarkoituksenmukaisesti.
• Onko varmistettu, että taskien/prosessien välinen kommunikointi ei aiheuta pullonkaulaa.
• Onko herätteiden/herätetyyppien käynnistämät sanomasekvenssit kuvattu
• Onko taskien/prosessien prioriteetit määritelty
• Onko dead-lockit eliminoitu.
• Onko varmistettu, että usealle taskille/prosessille yhteisten resurssien - esimerkiksi laitteiden, tietojen, tietorakenteiden, tietokantojen, jne. - yhtäaikainen käsittely on estetty, silloin, kun yhtäaikaisesta käsittelystä voisi aiheutua ongelmia.
• Perustuuko arkkitehtuuri jossain kohtaa keskeytysten estämiseen? Jos perustuu, onko varmistettu, että siitä ei aiheudu ongelmia, esimerkiksi sanomien tai muiden keskeytysten "hukkaamista".
• Perustuuko arkkitehtuuri jossain kohtaa siihen, että prosessi odottaa vain tietty(j)ä sanoma(i)a tai tapahtuma(i)a? Jos perustuu, onko varmaa, että siitä ei aiheudu ongelmia, (esimerkiksi sanomien "hukkaamista").
• Onko varmaa, että prosessien välinen tiukka kytkentä - esimerkiksi prosessi jää odottamaan toiselta prosessilta kuittausta tai vastausta, ennen kuin jatkaa omaa suoritustaan - ei aiheuta ohjelmiston "jumiutumista" tai suorituskyvyn hidastumista.
• jne.