Ohjelmiston laadunvarmistus. Nykyaikaiset ohjelmistolaatumallit

Huomautus: Ohjelmistotuotteiden laatuominaisuudet huomioidaan. On huomattava, että laatukysymyksiä on käsiteltävä koko elinkaaren ajan. On osoitettu, että ohjelmistotuotteen testaus antaa meille mahdollisuuden taata tietyt laatuparametrit. VisualStudio 2012:ssa tarkastellaan erilaisia ​​testejä ja testaustyökaluja. On osoitettu, että koodin uudelleenjärjestely parantaa ohjelmistotuotteen laatua.

Voit ladata tämän luennon esityksen.

Luennon tarkoitus:

Hanki ymmärrys menetelmistä ja työkaluista ohjelmistotuotteiden laadun varmistamiseksi.

Johdanto

Ohjelmistotuotteiden laatu määräytyy useilla kriteereillä. Laadullinen ohjelmisto on täytettävä toiminnalliset ja ei-toiminnalliset vaatimukset, joiden mukaisesti se luotiin, sillä on oltava liikearvoa ja täytettävä käyttäjien odotukset.

Sovellusten hallinnan elinkaaren aikana laatua tulee seurata ohjelmiston elinkaaren kaikissa vaiheissa. Se alkaa muodostua tunnistamalla tarvittavat vaatimukset. Vaatimuksia määriteltäessä on ilmoitettava haluttu toiminnallisuus ja kuinka sen toteutuminen varmistetaan.

Laadullinen ohjelmisto on oltava korkea kuluttajalaatuinen sovellusalasta riippumatta: kehittäjän sisäinen käyttö, liiketoiminta, tiede ja koulutus, lääketiede, kaupallinen myynti, sosiaalinen sfääri, viihde, verkko jne. Käyttäjälle ohjelmisto hänen on tyydytettävä tietty taso tarpeistaan.

Tärkeä näkökohta korkealaatuisten ohjelmistojen luomisessa on varmistaa ei-toiminnalliset vaatimukset, kuten helppokäyttöisyys, luotettavuus, esitys, turvallisuus, huollon helppous. Ohjelmiston luotettavuus määrittää kyvyn suorittaa määrätyt toiminnot ilman vikoja tietyissä olosuhteissa ja tietyn ajanjakson ajan. Esitys jolle on ominaista tiettyjen tapahtumien tai pitkäaikaisten toimintojen suoritusaika. Suojaus määrittää, missä määrin järjestelmä on suojattu vaurioilta, katoamiselta, luvattomalta käytöltä ja rikolliselta toiminnalta. Huollon helppous määrittelee tuotteen ylläpidon helppouden, mikä tarkoittaa, että vikojen korjaaminen, säätöjen tekeminen uusiin vaatimuksiin ja muuttuneen ympäristön hallinta on helppoa.

Ohjelmistotuotteiden elinkaaren hallinta auttaa kehittäjiä saavuttamaan määrätietoisesti korkealaatuisten ohjelmistojen luomista ja välttämään ajanhukkaa ohjelmistojen uusimiseen, suunnitteluun ja ohjelmointiin.

Ohjelmistojen testaus

Ohjelmistotuotteiden testauksen avulla voimme varmistaa ohjelmiston koko elinkaaren ajan, että ohjelmistoprojektit täyttävät määritetyt laatuparametrit. Testauksen päätavoite on tunnistaa poikkeamat toiminnallisten vaatimusten toteutuksessa, havaita virheet ohjelman suorituksessa ja korjata ne mahdollisimman varhaisessa vaiheessa projektin aikana.

Ohjelmiston kehitystyön elinkaaren aikana käytetään erilaisia ​​testauksia, joilla varmistetaan, että virstanpylväsjulkaisut täyttävät määritetyt laatumittarit. Tässä tapauksessa käytetään automaattisia ja manuaalisia testejä.

Yksikkötestaus	Tarkoituksena on tarkistaa ohjelmistoluokan menetelmien oikea toiminta. Yksikkötestit kirjoittavat ja suorittavat kehittäjät koodausprosessin aikana. Yksikkötestausta käytetään sekä sovelluskoodin laadun että tietokantaobjektien tarkistamiseen.
	on tarkoitettu testaukseen, jossa testaajalla ei ole ennalta määritettyjä testiskenaarioita ja se yrittää intuitiivisesti tutkia ohjelmistotuotteen ominaisuuksia sekä havaita ja korjata tuntemattomia virheitä.
Integraatiotestaus	käytetään ohjelmistotuotteen komponenttien oikean toiminnan tarkistamiseen.
Toiminnallinen testaus	sisältää tiettyjen ohjelmistovaatimusten tarkistamisen ja se suoritetaan uusien toimintojen lisäämisen jälkeen järjestelmään.
Stressitestaus	on tarkoitettu ohjelmistotuotteen toimivuuden testaamiseen suurimmalla syöttökuormalla.
Regressiotestaus	käytetään tehtäessä muutoksia ohjelmistoon, jotta voidaan tarkistaa, että järjestelmäkomponentit, jotka voivat olla vuorovaikutuksessa muutetun komponentin kanssa, toimivat oikein.
Kattava testaus	suunniteltu testaamaan ohjelmistotuotteen koko järjestelmän toiminnallisia ja ei-toiminnallisia vaatimuksia.
Hyväksymistesti	on toimintatesti, jonka tulee varmistaa, että ohjelmistotuote täyttää käyttäjien ja asiakkaiden vaatimukset ja odotukset. Hyväksymistestien kirjoittavat yritysanalyytikot, laadunvarmistusasiantuntijat ja testaajat.

Ohjelmistokehittäjänä VisualStudio 2012 tarjoaa mahdollisuuden luoda yksikkö-, lataus- ja käyttöliittymätestejä. VisualStudio 2012 tarjoaa seuraavat testiprojektimallit:

• yksikkötestiprojekti, jonka avulla voit luoda yksikkötestejä kehityksen aikana;
• projekti web-suorituskyky- ja lataustesteillä;
• projekti, jossa on koodattuja käyttöliittymätestejä.

VisualStudio 2012:n testaustyökalusarja on MicrosoftTestManager (MTM). MTM on suunniteltu hallitsemaan ohjelmistotestauksen elinkaarta, mukaan lukien suunnittelu, testaus ja seuranta. MTM on integroitu TeamFoundationServeriin. Microsoft TestManagerin avulla testaajat laativat testisuunnitelmia ja hallitsevat testausta. Kun luot testisuunnitelman, lisäät testaukseen tarvittavat testisarjat, testitapaukset ja kokoonpanot. Konfiguraatioita käytetään ympäristön määrittämiseen, jossa testisarjat suoritetaan. Microsoft TestManagerin avulla voit suorittaa manuaalisia, automaattisia ja tutkivia testejä. Testitulokset tallennetaan tietokantaan, jonka avulla voit laatia erilaisia ​​analyyttisiä raportteja. Testauksen aikana havaitut virheet tallennetaan, dokumentoidaan ja siirretään kehittäjille poistettaviksi. Kun ohjelmistojärjestelmän koodiin tehdään muutoksia, syntyy tarve regressiotestaukselle ja MTM luo automaattisesti regressiotestisuunnitelman, joka tunnistaa, mitkä testit on suoritettava uudelleen.

Ohjelmistojen testaajille ja kehittäjille VisualStudio 2012 sisältää LabManagement-virtuaaliympäristön hallinnan. LabManagement-testaustyökalujen avulla voit luoda infrastruktuurin, joka jäljittelee mahdollisimman tarkasti ohjelmistotuotteen suunnitellun käytön todellista ympäristöä. Tällaisia ​​ympäristöjä voidaan käyttää automaattisten koontiversioiden suorittamiseen, testien automatisointiin ja kehitetyn koodin suorittamiseen.

Refaktorointi

Ohjelmistotuotteen koodin laatu määräytyy suurelta osin sen mukaan, kuinka vaikeaa tai helppoa koodiin on tehdä muutoksia, sekä kuinka helposti koodi on ymmärrettävissä. Luotu ohjelmistosovellus saattaa suorittaa vaaditut toiminnot, mutta sillä on ongelmia muutosten tekemisessä tai luodun koodin ymmärtämisessä. Tässä tapauksessa tällaista ohjelmistoa ei voida kutsua korkealaatuiseksi, koska sen ylläpitovaiheessa voi syntyä ongelmia sen muuttamisessa, kun käyttäjän vaatimukset muuttuvat.

Ohjelmistosovelluskoodin laadun parantamiseksi käytetään refaktorointia [,]. Fowler M.:n mukaan refaktorointi määritellään "prosessiksi, jossa ohjelmistojärjestelmää muutetaan siten, että sen ulkoinen käyttäytyminen ei muutu, mutta sen sisäinen rakenne paranee". Tästä syystä suunnitteluprosessissa korkealaatuisen ohjelmistotuotteen luomiseksi on välttämätöntä varmistaa toiminnallisten vaatimusten täyttymisen lisäksi myös ei-toiminnallisten vaatimusten täyttyminen, erityisesti ylläpidettävyys, mikä tarkoittaa mahdollisuutta ja helppoutta tehdä muutoksia koodi sekä kyky ymmärtää luotu koodi helposti.

Huono koodisuunnittelu määräytyy useiden merkkien perusteella:

• jäykkyys - ohjelman ominaisuus, joka vaikeuttaa muutosten tekemistä koodiin;
• hauraus - ohjelman kyky vaurioitua monissa paikoissa, kun yksi muutos tehdään;
• stagnaatiolle on ominaista se, että koodi sisältää osia, joista voi olla hyötyä muissa järjestelmissä, mutta vaiva ja riski, joka liittyy näiden koodin osien erottamiseen alkuperäisestä järjestelmästä, on liian suuri;
• tarpeettomaan monimutkaisuuteen on ominaista se, että ohjelma sisältää elementtejä, joita ei tällä hetkellä käytetä;
• tarpeeton toisto, joka koostuu ohjelman toistuvista koodinpätkistä;
• opasiteetti, joka luonnehtii koodin ymmärtämisen vaikeutta.

Laadukkaan koodisuunnittelun luomiseksi on suositeltavaa soveltaa joitain ohjelmistosuunnittelun periaatteita ja malleja [,].

Yhteisen vastuun periaate sanoo, että luokalla saa olla vain yksi syy muutokseen. Tästä periaatteesta seuraa, että luokalle on suositeltavaa antaa vain yksi vastuu.

Avoin/kiinni -periaate määrää, että ohjelmistokokonaisuudet (luokat, moduulit, funktiot) ovat avoinna laajennuksille, mutta suljettuina muokkauksille.

Liskovin substituutioperiaate määrää, että mikä tahansa sen alatyypeistä pitäisi olla mahdollista korvata perusluokan sijaan.

Riippuvuuden inversioperiaate määrittelee kaksi ehtoa:

• Ylimmän tason moduulit eivät saa olla riippuvaisia ​​alemman tason moduuleista. Molempien on oltava riippuvaisia ​​abstraktioista;
• abstraktioiden ei pitäisi riippua yksityiskohdista. Yksityiskohtien tulee riippua abstraktioista.

Rajapintojen erotteluperiaate määrittelee, että asiakkaiden tulee olla tietoisia vain abstrakteista liitännöistä, joilla on koheesio-ominaisuus.

Suunnittelumallit tarjoavat universaaleja, käytännössä testattuja ratkaisuja. Tarjolla on laaja luettelo kuvioista. Yleisestä malliluettelosta on syytä korostaa ne, jotka sopivat käytettäväksi ketterässä ohjelmistokehityksessä. Nämä mallit ovat tiimi, strategia, julkisivu, välittäjä, yksittäinen, tehdas, säveltäjä, tarkkailija, tiivistelmäpalvelin/sovitin/yhdyskäytävä, välityspalvelin ja yhdyskäytävä, vierailija ja tila.

Käyttämällä malleja kehitystyössä voit luoda ohjelmisto, jota on helppo muokata ja ylläpitää.

On huomioitava, että uudelleenfaktoroinnin suorittamiseksi tarvitaan luotettavia testejä, jotka varmistavat toiminnallisten vaatimusten noudattamisen ja parantavat ohjelmistokoodin suunnittelua.

Avainkäsitteet

Yksikkötestaus	testaus, joka on suunniteltu varmistamaan ohjelmistoluokan menetelmien oikea toiminta.
Tutkiva testaus	testaus, jossa testaajalla ei ole ennalta määrättyjä testiskenaarioita ja hän yrittää intuitiivisesti tutkia ohjelmistotuotteen ominaisuuksia ja havaita ja korjata tuntemattomia virheitä.
Integraatiotestaus	testaus, joka on suunniteltu varmistamaan ohjelmistotuotteen osien oikea toiminta.
Toiminnallinen testaus	erityisten ohjelmistovaatimusten tarkistamiseen suunniteltu testaus, joka suoritetaan uusien toimintojen lisäämisen jälkeen järjestelmään.
Stressitestaus	testaus, joka on suunniteltu tarkistamaan ohjelmistotuotteen toimivuus suurimmalla syöttökuormalla.
Regressiotestaus	testaus, jota käytetään tehtäessä muutoksia ohjelmistoon varmistaakseen, että järjestelmäkomponentit, jotka voivat olla vuorovaikutuksessa muutetun komponentin kanssa, toimivat oikein.
Kattava testaus	testaus, joka on suunniteltu varmistamaan ohjelmistotuotteen koko järjestelmän toiminnallisten ja ei-toiminnallisten vaatimusten noudattaminen.
Hyväksymistesti	testaus, joka on toiminnallista testausta, jonka on varmistettava, että ohjelmistotuote täyttää käyttäjien ja asiakkaiden vaatimukset ja odotukset.
MicrosoftTestManager	Microsoftin työkalut, jotka on suunniteltu hallitsemaan ohjelmistotestauksen elinkaarta.
LabManagement	virtuaalisen testausympäristön johtaja.

Harjoituspaketti

Kysymyksiä

1. Mitä ominaisuuksia laadukkaalla ohjelmistotuotteella tulee olla?
2. Mitkä ei-toiminnalliset vaatimukset määräävät ohjelmistotuotteen laadun?
3. Mikä on testauksen rooli ohjelmistotuotteen laadun varmistamisessa?
4. Millaisia ​​testejä käytetään ohjelmistotuotteen laadun tarkistamiseen?
5. Mihin regressiotestausta käytetään?
6. Mitä testiprojektimalleja on saatavana VisualStudio 2012:ssa?
7. Mihin MicrosoftTestManageria käytetään? Mitä toimintoja siinä on?
8. Mitä LabManagementia käytetään testaamiseen?
9. Mihin koodin uudelleenkäsittelyä käytetään?
10. Anna merkkejä huonolaatuisesta koodista.

Harjoitukset

1. Laadi analyyttinen katsaus NUnit-testaukseen.
2. Valmistele analyyttinen katsaus xUnit.net-testauksesta.
3. Laadi analyyttinen katsaus MbUnit-testaukseen.

Ohjelmiston laatu on ohjelmistosuunnittelun jatkuva huolenaihe, ja siitä keskustellaan monilla tiedon aloilla.

• Phil Crosby: Laatu on käyttäjien vaatimusten mukaisuutta.
• Watts Humphrey: Laatu on erinomaisen käytettävyystason saavuttamista.
• IBM Yritys: loi ilmauksen "markkinalähtöinen laatu".
• Baldrigen kriteeri:"asiakaslähtöistä laatua".
• ISO 9001 -laatujärjestelmä: Laatu tarkoittaa sitä, missä määrin luontaiset ominaisuudet vastaavat vaatimuksia.

Hyväksyttävä laatu- tämä on luodun tuotteen (palvelun) haluttu täydellisyysaste, joka pystyy tyydyttämään käyttäjiä ja saavutettavissa annetuissa suunnittelurajoituksissa.

Laatu projektitoiminnassa:

• Vaatimusten hallinta ("laatuattribuutit" ei-toiminnallisten vaatimusten luokkana);
• Testaus (ns. MTBF, mittarit, kuten MTTF - Mean Time To Failure, eli keskimääräinen aika havaittujen järjestelmävikojen välillä jne.).

"Hyväksyttävä laatu" voidaan verrata tietyn SLA - Service Level sopimuksen palvelutasoon. Eli hyväksyttävää laatua voidaan pitää<количественно выраженный>asiakkaan ja urakoitsijan välinen kompromissi tuotteen ominaisuuksista, jotka urakoitsija on luonut<решения задач>asiakas, ottaen huomioon muut projektin rajoitukset (erityisesti kustannukset, joita usein kutsutaan "laadun kustannuksiksi").

Kuva "Tietoalue - Ohjelmiston laatu"

Kuva "Laadunhallintajärjestelmän malli"

Ohjelmiston laadun perusteet

Laatuvaatimuksista päästiin sopimukseen sekä selkeä viestintä insinööreille siitä, mitä laatu tarkoittaa<получаемого продукта>, vaativat keskustelua ja muodollista määrittelyä monista laatunäkökohdista.

Insinöörien on ymmärrettävä laadun käsite, ominaisuudet ja laadun merkitys suhteessa kehitettäviin tai ylläpidettäviin ohjelmistoihin.

Tärkeä ajatus on, että ohjelmistovaatimukset määrittelevät vaaditut ohjelmiston laatuominaisuudet ja vaikuttavat myös näiden ominaisuuksien arvioimiseksi laadittuihin kvantifiointimenetelmiin.<соответствующие>hyväksymisperusteet.

Ohjelmistotekniikan kulttuuri ja etiikka

Ohjelmistoinsinöörien odotetaan hyväksyvän ohjelmiston laatukysymykset osaksi omaa toimintaansa<профессиональной>kulttuuri.
Eettisillä näkökohdilla voi olla merkittävä rooli ohjelmiston laadussa, kulttuurissa ja insinöörien asenteissa.<к своей работе>. IEEE Computer Society ja ACM ovat kehittäneet kahdeksaan periaatteeseen perustuvat eettiset ja ammatilliset käytännöt auttamaan insinöörejä vahvistamaan sitoutumistaan ​​laatuun ja riippumattomuuteen.<в решении вопросов обеспечения достойного качества создаваемых программных продуктов>päivittäisessä työssään.

Arvo ja laadun kustannukset

Käsite "laatu" ei itse asiassa ole niin ilmeinen ja yksinkertainen kuin miltä se ensi silmäyksellä näyttää. Jokaiselle suunnittelutuotteelle niitä on monia<интерпретаций>laatu riippuen tietystä "koordinaattijärjestelmästä". Monia näistä näkökulmista on keskusteltava ja määritettävä ohjelmistotuotteen vaatimusten kehittämisvaiheessa. Laatuominaisuuksia voidaan vaatia vaihtelevasti, ne voivat puuttua tai ne voivat asettaa tiettyjä vaatimuksia, jotka kaikki voivat olla tulosta jonkinlaisesta kompromissista.

Laadun hinta voidaan jakaa seuraaviin:

• varoituksen hinta<дефектов>(ehkäisykustannukset),
• arviointikustannukset,
• sisäiset vikakustannukset,
• ulkoiset vikakustannukset.

Ohjelmistoprojektien liikkeellepaneva voima on halu luoda ohjelmistoja, joilla on tietty arvo. Ohjelmiston arvo voidaan ilmaista kustannusten muodossa tai ei. Asiakkaalla on yleensä oma käsitys maksimikustannusinvestoinnista, jonka tuottoa odotetaan, mikäli ohjelmiston luomisen päätavoitteet saavutetaan. Asiakkaalla voi myös olla tiettyjä odotuksia ohjelmiston laadusta. Joskus asiakkaat eivät ajattele laatukysymyksiä ja niihin liittyviä kustannuksia. Ovatko laatuominaisuudet puhtaasti koristeellisia vai ovatko ne olennainen osa ohjelmistoa? Vastaus on luultavasti jossain puolivälissä, kuten näissä tapauksissa lähes aina tapahtuu, ja on kysymys siitä, missä määrin asiakas on mukana päätöksentekoprosessissa ja ymmärtääkö asiakas täysin kustannukset ja hyödyt. jotka liittyvät tietyn laatutason saavuttamiseen. Ihannetapauksessa useimmat näistä päätöksistä tulisi tehdä vaatimusprosessin aikana, mutta näitä ongelmia saattaa ilmetä koko ohjelmiston elinkaaren aikana. Niitä ei ole<“стандартных”>säännöt siitä, miten tällaiset päätökset pitäisi tehdä. Insinöörien on kuitenkin kyettävä kuvittelemaan erilaisia ​​vaihtoehtoja ja niiden kustannuksia.

Mallit ja laatuominaisuudet

ISO/IEC määrittelee kolme toisiinsa liittyvää ohjelmiston laatumallia (ISO 9126-01 Software Engineering – Product Quality, Osa 1: Laatumalli):

• sisäinen laatu,
• ulkoinen laatu ja
• laatu käytön aikana sekä joukko asiaankuuluvia töitä ohjelmiston laadun arvioimiseksi (ISO14598-98 Software Product Evaluation).

Ohjelmistosuunnitteluprosessin laatu

Laadunhallinta (ohjelmiston laadunhallinta) ja ohjelmistosuunnitteluprosessien laatu (ohjelmistosuunnitteluprosessin laatu) liittyvät suoraan luodun ohjelmistotuotteen laatuun.

Ohjelmiston laadun alalla on kaksi tärkeää standardia.

• TickIT- koskee yleisen laatujärjestelmän ISO 9001-00 huomioon ottamista ohjelmistoprojekteissa.
• Toinen tärkeä standardi on CMMI Ohjelmistotuotantoprosessin osaamisalueella käsitelty , tarjoaa suosituksia prosessin parantamiseksi. CMMI-prosessialueet (kompetenssialueet) liittyvät suoraan laadunhallintaan:
  • prosessin ja tuotteen laadunvarmistus (CMMI:n tukiprosessiluokka),
  • todentaminen (luokka "Insinöörityö") ja
  • sertifiointi (validointi, luokka "Engineering").

Samalla CMMI luokittelee arvostelu Ja tarkastaa todentamismenetelminä, mutta ei itsenäisinä prosesseina.

Näitä standardeja pidetään edelleen toisiaan täydentävinä, ja ISO 9001 -sertifiointi auttaa saavuttamaan CMMI-kypsyystason ylemmän tason.

Ohjelmistotuotteiden laatu

Ensinnäkin insinöörien on määritettävä tavoitteet ohjelmistojen luomiselle. Tässä yhteydessä on erityisen tärkeää muistaa, että asiakkaiden vaatimukset ovat ensisijaisia ​​ja sisältävät vaatimuksia laadulle, ei vain toimivuudelle (toiminnalliset vaatimukset). Siten insinöörit ovat vastuussa laatuvaatimusten poimimisesta, joita ei aina esitetä yksiselitteisesti, sekä keskustelemaan niiden tärkeydestä ja niiden saavuttamisen vaikeusasteesta. Kaikki laatuun liittyvät prosessit (esim. kokoonpano, tarkastus ja laadun parantaminen) on suunniteltava näitä vaatimuksia silmällä pitäen, ja niiden on katettava suurimmat lisäkustannukset (tärkeänä osana ohjelmiston kustannuksia).

ISO 9126-01 -standardi (Ohjelmistotekniikka – Tuotteen laatu, Osa 1: Laatumalli) määrittelee kahdelle siinä kuvatuista kolmesta mallista niihin liittyvät ominaisuudet ja laadun "aliominaisuudet" sekä mittareita, jotka ovat hyödyllisiä ohjelmistotuotteiden laadun arvioinnissa.

Termi "tuote" on laajennettu käsittämään kaikki artefaktit, jotka on luotu kaikkien lopullisen ohjelmistotuotteen luomiseen käytettyjen prosessien tuloksena. Tuoteesimerkkejä ovat (mutta eivät rajoitu):

• täydellinen järjestelmävaatimusten erittely,
• ohjelmistovaatimusten määrittely järjestelmän ohjelmistokomponenteille (ohjelmistovaatimusmäärittely, SRS),
• mallit,
• testidokumentaatio,
• laatuanalyysityön tuloksena syntyneet raportit.

Vaikka termiä laatu käytetään useimmiten suhteessa lopputuotteeseen ja järjestelmän käyttäytymiseen toiminnan aikana, on hyvä insinöörikäytäntö edellyttää, että tulosten/elinkaarituotteiden vaatimustenmukaisuus arvioidaan kaikissaa.

Laadun parantaminen

Ohjelmiston laatua voidaan parantaa jatkuvan jatkuvan parantamisen iteratiivisella prosessilla. Tämä edellyttää valvontaa, koordinointia ja palautetta useiden samanaikaisesti käynnissä olevien prosessien hallinnassa:

1. elinkaariprosessit,
2. prosessi vikojen/vikojen havaitsemiseksi, poistamiseksi ja estämiseksi
3. laadun parantamisprosessit.

Ohjelmistosuunnitteluun soveltuvat teoriat ja käsitteet ovat taustalla oleva laadun parannus. Esimerkiksi virheiden ennaltaehkäisy ja varhainen diagnosointi, jatkuva parantaminen ja asiakkaan vaatimusten huomioiminen (asiakaslähtöisyys), jotka muodostavat "laadun rakentamisen" periaatteen. Nämä konseptit perustuvat laatuasiantuntijoiden työhön, jotka ovat tulleet uskomaan, että tuotteen laatu liittyy suoraan sen luomiseen käytettyjen prosessien laatuun.

Lähestymistapoja kuten TQM(Total Quality Management - täydellinen laadunhallinta) ja PDCA(Plan, Do, Check, Act – Planning, Action, Check, Reaction/Adjustment) ovat työkaluja laatuun liittyvien tavoitteiden saavuttamiseksi. Johdon tuki auttaa prosessien suorittamisessa, tuotteiden arvioinnissa ja kaiken tarvittavan tiedon hankkimisessa. Lisäksi kehitetyssä parannusohjelmassa (yleensä kohdennettu ja koko osaston tai organisaation työn kattava parannusohjelma) yksilöidään yksityiskohtaisesti kaikki toimenpiteet ja parannusprojektit.<отдельных аспектов деятельности>tietyn ajan kuluessa, jonka aikana tällaiset hankkeet voidaan toteuttaa ratkaisemalla asianmukaiset ongelmat onnistuneesti. Samalla johdon tuki tarkoittaa, että kaikilla parannusprojekteilla on riittävästi resursseja tavoitteidensa saavuttamiseksi. Johdon tuki liittyy läheisesti aktiivisen vuorovaikutuksen toteuttamiseen tiimissä, ja sen tulee estää mahdollisten ongelmien syntyminen (ja passiivinen tai jopa aktiivinen vastustus parannusohjelman tai sen yksittäisten projektien toteuttamista vastaan). Työryhmien muodostaminen, keskijohtajien tukeminen ja projektitason omista resurssit käsitellään osaamisalueella ”Ohjelmistosuunnitteluprosessi”.

Ohjelmiston laatuprosessit

Ohjelmiston laadunhallinta (SQM, Software Quality Management) koskee kaikkia prosesseja, tuotteita ja resursseja. SQM määrittelee prosessit, prosessien omistajat sekä prosessivaatimukset, prosessien ja niiden tulosten mittaukset sekä palautekanavat.

Laadunhallintaprosessit sisältävät monia toimintoja. Jotkut niistä antavat sinun löytää vikoja suoraan, kun taas toiset auttavat sinua määrittämään, missä tarkalleen voi olla tärkeää suorittaa yksityiskohtaisempia tutkimuksia, minkä jälkeen taas tehdään töitä virheiden havaitsemiseksi suoraan. Monia toimia voidaan myös toteuttaa molempien tavoitteiden saavuttamiseksi.

Ohjelmiston laatusuunnittelu sisältää:

1. Vaaditun tuotteen määritelmä laatuominaisuuksien perusteella.
2. Suunnittele prosessit tarvittavan tuotteen saamiseksi.

Nämä prosessit eroavat SQM-prosesseista sinänsä, jotka puolestaan ​​tähtäävät suunniteltujen laatusuorituskykyjen arvioimiseen pikemminkin kuin näiden suunnitelmien toteuttamiseen. Laadunhallintaprosessien tulee keskittyä siihen, kuinka hyvin tuote vastaa asiakkaiden ja sidosryhmien tarpeita, tuottaa arvoa asiakkaalle ja sidosryhmille ja että sillä on vaadittu laatu täyttääkseen ohjelmistovaatimukset.

SQM:llä voidaan arvioida sekä loppu- että välituotteita. Jotkut erikoistuneista SQM-prosesseista on määritelty standardissa 12207:

• Laadunvarmistusprosessi;
• Varmennusprosessi;
• Validointiprosessi;
• Yhteinen tarkistusprosessi;
• Tarkastusprosessi.

Kaikki nämä prosessit tukevat laadun tavoittelua ja auttavat myös mahdollisten virheiden tunnistamisessa. Ne eroavat kuitenkin siitä, mihin ne keskittyvät.

SQM-prosessit koostuvat tehtävistä ja tekniikoista, suunniteltu arvioimaan, kuinka ohjelmistosuunnitelmat toteutuvat ja kuinka hyvin väli- ja lopputuotteet täyttävät tietyt vaatimukset. Näiden tehtävien tulokset raportoidaan esimiehille ennen asianmukaisten korjaavien toimenpiteiden toteuttamista. SQM-prosessia hallitaan luottaen siihen, että raportointitiedot ovat tarkkoja.
Kuten tällä tietoalueella on kuvattu, SQM-prosessit liittyvät läheisesti toisiinsa. Ne voivat mennä päällekkäin ja joskus jopa yhdistää. Ne näyttävät olevan luonteeltaan reaktiivisia, koska he tarkastelevat prosesseja opittujen käytäntöjen ja jo valmistettujen tuotteiden kontekstissa. Niillä on kuitenkin tärkeä rooli suunnitteluvaiheessa, sillä ne ovat proaktiivisia prosesseina ja menettelyinä, joita tarvitaan sidosryhmien vaatimien ominaisuuksien ja laatutasojen saavuttamiseksi.<проекта>ohjelmisto.

Riskienhallinnalla voi myös olla merkittävä rooli laadukkaiden ohjelmistojen toimittamisessa. "Säännöllisen" (pysyvänä, ei säännöllisenä; alkuperäisessä – kurinalaisen) riskianalyysin sisällyttäminen ja<соответствующих>ohjausteknikko<рисками>ohjelmistojen elinkaaren prosesseihin voi lisätä mahdollisuuksia tuottaa laadukasta tuotetta. Tarkempia tietoja riskienhallinnasta löytyy tietoalueelta ”Ohjelmiston hallinta”.

Ohjelmiston laadunvarmistus (SQA)

SQA-prosessit toimittaa todisteita siitä, että ohjelmistotuotteet ja projektin elinkaariprosessit täyttävät tietyt vaatimukset. Tällainen vahvistus suoritetaan suunnittelun, asettamisen perusteella<работ>toteuttaa ja suorittaa joukko toimia, joilla pyritään varmistamaan, että laadusta tulee olennainen osa ohjelmistoa.
Tämä näkemys edellyttää ongelman selkeää ja täsmällistä muotoilua sekä sitä, että vastaavan ratkaisun vaatimukset on määritelty ja selkeästi ilmaistu, täydellinen ja yksiselitteisesti tulkittu.<программному>päätös. SQA saavuttaa laadunvarmistuksen kehitys- ja ylläpitoprosessissa suorittamalla erilaisia ​​toimintoja kaikissa vaiheissa<жизненного цикла>, jonka avulla voit tunnistaa varhaisessa vaiheessa ongelmat, jotka ovat melkein väistämättömiä missä tahansa monimutkaisessa toiminnassa.

Riskienhallinta on vakava lisätyökalu ohjelmiston laadun varmistamiseen.

SWEBOKin muotoilema SQA keskittyy prosesseihin. SQA:n tehtävänä on varmistaa, että prosessit suunnitellaan asianmukaisesti, että prosessit jatkuvat suunnitelman mukaisesti ja että tarvittavat prosessimittaukset tehdään ja mittaustulokset välitetään sidosryhmille (organisaatioille ja henkilöille).

SQA-suunnitelma määrittelee keinot, joilla varmistetaan, että kehitetty tuote täyttää tietyt käyttäjien vaatimukset korkeimmalla mahdollisella laatutasolla määriteltyjen suunnittelurajoitusten puitteissa.

Tämän saavuttamiseksi on ensinnäkin välttämätöntä, että laatutavoitteet ovat selkeästi määriteltyjä ja ymmärrettäviä (ja myös selkeästi tulkittavia, mikä on edellytys kaikille tavoitteille ja vastaaville vaatimuksille). Tämän tulee näkyä asianmukaisissa hoitosuunnitelmissa.<проектом>, kehitystä ja tukea.

Erityiset laadunvarmistustoiminnot ja -tehtävät on jäsennelty yksityiskohtaisilla vaatimuksilla niiden kustannuksille ja niihin liittyville resursseille, johtamistavoitteille ja vastaaville aikatauluille johtamis-, kehitys- ja kunnossapitosuunnitelmien tavoitteiden yhteydessä. SQA-suunnitelmassa yksilöidään asiakirjat, standardit, käytännöt ja käytännöt, joita käytetään projektin ohjaamiseen ja kuinka nämä näkökohdat varmistetaan ja valvotaan määritellyn suunnitelman riittävyyden ja noudattamisen varmistamiseksi.
SQA-suunnitelma identifioi mittarit, tilastolliset tekniikat, ongelmaraportointi- ja korjaustoimenpiteet, työkalut, kuten työkalut, tekniikat ja menetelmät, fyysisen median tietoturvakysymykset, koulutuksen sekä SQA-asioihin liittyvän raportoinnin ja dokumentoinnin.

Lisäksi SQA-suunnitelmassa käsitellään myös muuntyyppisiin toimintoihin liittyviä laadunvarmistustoimintoja koskevia kysymyksiä<различных>suunnitelmat ohjelmistojen luomiseksi, joihin sisältyy myös tiettyä ohjelmistoprojektia varten tarvittavien räätälöityjen ja/tai monistettavien/valmiiden ohjelmistoratkaisujen (kaupalliset valmiit ohjelmistoratkaisut, COTS) toimittaminen, asennus, ylläpito. SQA-suunnitelma voi sisältää ohjelmistojen hyväksymiskriteerit sekä laadun varmistamiseksi tarvittavat raportointi- ja hallintatoimet.<и контролю над>toimii.

Vahvistus ja validointi (V&V)

Ohjelmistojen todentaminen ja sertifiointi on kurinalainen lähestymistapa ohjelmistotuotteiden arviointiin, jota sovelletaan koko elinkaaren ajan. Todentamis- ja pätevöintitoimilla pyritään varmistamaan laatu ohjelmiston olennaisena ominaisuutena ja käyttäjien tarpeiden tyydyttämisessä.
V&V käsittelee suoraan ohjelmiston laatuongelmia ja käyttää asianmukaisia ​​testaustekniikoita tiettyjen vikojen havaitsemiseen. V&V:tä voidaan kuitenkin käyttää välituotteisiin, mikäli välivaiheet vastaavat<соответствующих>elinkaaren prosesseja.

V&V-prosessi määrittää, missä määrin tietyn kehitys- ja ylläpitotyön tuote (tulos) täyttää näiden töiden puitteissa laaditut vaatimukset ja lopputuote täyttää määritetyt tavoitteet ja käyttäjien vaatimukset.

Todentaminen- yritys varmistaa, että tuote on suunniteltu oikein (tuote on rakennettu oikein; yleensä välituotteille, joskus lopputuotteelle) siinä mielessä, että toiminnolla valmistettu tuote täyttää edellisen toiminnon määritykset .
Sertifiointi– yritys varmistaa, että oikea tuote rakennetaan (oikea tuote rakennetaan; yleensä lopputuotteen yhteydessä) asetetun tavoitteen saavuttamisen kannalta.

Molemmat prosessit – todentaminen ja sertifiointi– alkaa kehityksen ja ylläpidon alkuvaiheessa. Ne tarjoavat tuotteiden keskeisten ominaisuuksien tarkastelua (tutkimusta) sekä välittömästi edeltävien suoritteiden (välituotteiden) yhteydessä että asiaankuuluvien eritelmien täyttämisen kannalta. V&V-suunnittelun tarkoituksena on tarjota varmennus- ja sertifiointiprosesseille tarvittavat resurssit ja jakaa selkeästi roolit ja vastuut. Tuloksena saadut V&V-suunnitelmaasiakirjat ja<детально>kuvailee erilaisia ​​resursseja, rooleja ja toimintoja sekä käytettyjä tekniikoita ja työkaluja.
Suunnitelmassa käsitellään myös todentamis- ja pätevöintitoimintojen hallintaa, viestintää, käytäntöjä ja menettelytapoja sekä niiden vuorovaikutusta. Lisäksi se voi käsitellä virheraportointiin ja vaatimusten dokumentointiin liittyviä ongelmia.

Tarkastus ja tarkastukset

Viisi erityyppistä arviointia ja auditointia:

• Johdon arvostelut
• Tekniset arvostelut
• Tarkastukset
• “Läpikävelyt”
• Tarkastukset

Johdon arvostelut

Johdon arvioinnin tarkoituksena on seurata kehitystä<проекта/продукта>, suunnitelmien ja aikataulujen tilan määrittäminen, vaatimusten hyväksyminen ja resurssien kohdentaminen tai asetettujen tavoitteiden saavuttamiseen käytettyjen johtamismenetelmien tehokkuuden arviointi.

Johdon arvioinnit tukevat päätöksiä tehdä muutoksia ja tehdä tarvittavia korjaavia toimenpiteitä ohjelmistoprojektin toteutuksen aikana.

Johdon arvioinnit määrittävät suunnitelmien, aikataulujen ja vaatimusten riittävyyden ja tarkkailevat niiden edistymistä tai noudattamatta jättämistä. Nämä arvioinnit voidaan suorittaa tuotteelle, ja ne tallennetaan auditointiraporttien, tila- (kehitys)raporttien, V&V-raporttien sekä erityyppisten suunnitelmien muodossa - projektin riskienhallinta/projektinhallinta, konfiguraatiohallinta, turvallisuus<использования>ohjelmistot (turvallisuus), riskinarviointi jne.

Tekniset arvostelut

Teknisten arvioiden tarkoituksena on tutkia ohjelmistotuote sen sopivuuden selvittämiseksi aiottuun tarkoitukseen. Tavoitteena on tunnistaa poikkeamat hyväksytyistä spesifikaatioista ja standardeista. Teknisten arvioiden varmistamiseksi on jaettava seuraavat roolit: päätöksentekijä; tarkastelun johtaja; tallennin; sekä tekninen henkilöstö, joka tukee (suoraan) arviointitoimia.

Tekninen arviointi vaatii ehdottomasti seuraavat syöttötiedot:

• Tavoitelauseet
• Tietty ohjelmistotuote (arvioinnissa)
• Tietty projektisuunnitelma (projektinhallintasuunnitelma)
• Luettelo tuotteeseen liittyvistä ongelmista (kysymyksistä).
• Tekniset arviointimenettelyt

Tiimi<технической оценки> noudattaa määriteltyä arviointimenettelyä. Pätevät (teknisesti) henkilöt antavat yleiskatsauksen tuotteesta (edustaen kehitystiimiä). Opiskelu<продукта> suoritetaan yhdessä tai useammassa kokouksessa (tuotteen esittelijöiden ja arvioinnin antajien välillä). Tekninen arviointi saatetaan päätökseen, kun kaikki määrätyt tuotetutkimustoimet on suoritettu.

Tarkastukset

Tarkastusten tarkoituksena on havaita ja tunnistaa ohjelmistotuotteen poikkeavuuksia. Tarkastusten ja arvioiden (hallinnollisen ja teknisen) välillä on kaksi suurta eroa:

1. Tarkastuksiin ei tulisi osallistua henkilöitä, jotka ovat johtotehtävissä (johtajat) suhteessa tarkastusryhmän jäseniin.
2. Tarkastusta tulee johtaa puolueeton (projektista ja sen tavoitteista riippumaton) johtaja, joka on koulutettu tarkastustekniikoihin.

Ohjelmiston tarkastuksessa ovat aina mukana väli- tai lopputuotteen tekijät, toisin kuin arvioinneissa, jotka eivät välttämättä vaadi tätä. Tarkastuksiin (väliaikaisina organisaatioyksiköinä - ryhmät, ryhmät) kuuluu johtaja, rekisterinpitäjä, tarkastaja ja useita (2-5) tarkastajia. Tarkastusryhmän jäsenet voivat erikoistua eri osaamisalueille (ovat eri osaamisalueet), esimerkiksi aihealueeseen, suunnittelumenetelmiin, kieleen jne. Tiettynä ajankohtana (ajanjaksona) tarkastuksia tehdään erilliselle pienelle osalle tuotetta (useimmissa tapauksissa keskittyen yksittäisiin toiminnallisiin tai muihin ominaisuuksiin; usein alkaen yksittäisistä liiketoimintasäännöistä, toiminnallisista vaatimuksista tai laatuominaisuuksista , tekijän huomautus). Jokaisen tiimin jäsenen tulee tutkia ohjelmistotuote ja muut syötteet ennen tarkastuskokousta, ehkä soveltaa erilaisia ​​analyyttisiä tekniikoita tuotteen pieniin osiin tai tuotteeseen kokonaisuutena, jälkimmäisessä tapauksessa tarkastelemalla vain yhtä osa-aluetta, kuten esim. käyttöliittymät. Kaikki löydetyt poikkeamat tulee dokumentoida ja tiedot välittää tarkastuksen johtajalle. Tarkastusprosessin aikana johtaja johtaa istunnon<инспекции>ja tarkistaa kaiken<члены команды>valmisteltu tarkastusta varten.

Yleinen tarkastuksessa käytetty työkalu on tarkistuslista, joka sisältää poikkeavuuksia ja näkökohtiin liittyviä kysymyksiä<программного продукта>, herättää kiinnostusta. Tuloksena oleva taulukko luokittelee usein poikkeamat, ja tiimi arvioi sen täydellisyyden ja tarkkuuden. Päätös tarkastuksen suorittamisesta tehdään yhden (millä tahansa) kolmesta kriteeristä:

1. Hyväksyminen<продукта>ilman tai vain vähän käsittelyä
2. Hyväksyminen<продукта>käsiteltyjen fragmenttien tarkistamisen kanssa
3. Uudelleentarkastuksen tarve

Tarkastuskokoukset kestävät yleensä useita tunteja, toisin kuin tekniset arvioinnit ja auditoinnit, jotka vaativat useimmissa tapauksissa enemmän työtä ja kestävät siten pidempään.

Esittelyt

Ajon tarkoituksena on arvioida ohjelmistotuote. Testi voidaan suorittaa yleisön tutustuttamiseksi (kouluttamiseen) ohjelmistotuotteeseen.

Juoksun päätavoitteet ovat:

• Etsitään poikkeavuuksia
• Tuotteen parannus
• Keskustelua vaihtoehtoisista toteutustavoista
• Standardien ja eritelmien noudattamisen arviointi

Kävittely on samanlainen kuin tarkastus, mutta se tehdään yleensä vähemmän muodollisesti. Pohjimmiltaan juoksun järjestävät insinöörit muille tiimin jäsenille saadakseen heiltä palautetta heidän työstään yhtenä laadunvarmistuksen elementistä (tekniikasta).

Tarkastukset

Ohjelmiston auditoinnin tarkoitus on ohjelmistotuotteiden ja prosessien riippumaton arviointi soveltuvien määräysten, standardien, ohjeiden, suunnitelmien ja menettelytapojen noudattamisesta.

Auditointi on muodollisesti organisoitua toimintaa, jossa osallistujat suorittavat tiettyjä rooleja, kuten päätarkastajan, toisen tarkastajan, tallentajan ja aloitteentekijän. Tarkastukseen osallistuu arvioitavan organisaation/organisaatioyksikön edustaja. Auditoinnin tuloksena havaitaan poikkeamat ja laaditaan tiimin vaatima raportti<разработки>ryhtymään korjaaviin toimiin.

Vaikka arvioinneille ja auditoinneille on olemassa useita muodollisia nimiä (ja luokituksia), on tärkeää huomata, että tämän tyyppisiä toimintoja voidaan suorittaa melkein mille tahansa tuotteelle missä tahansa kehitys- tai ylläpitoprosessin vaiheessa.

Käytännön huomioita

Ohjelmiston laatuvaatimukset

Vaikutustekijät

SQM-toimintojen ja -tekniikoiden suunnitteluun, hallintaan ja valintaan vaikuttavat useat tekijät, kuten:

• Järjestelmän laajuus, jossa ohjelmisto toimii (turvallisuuskriittinen)<людей>), liiketoimintakriittiset jne.)
• Järjestelmä- ja ohjelmistovaatimukset
• Mitä komponentteja järjestelmässä käytetään - kaupallinen (ulkoinen) tai vakio (sisäinen)
• Mitkä ohjelmistosuunnittelustandardit ovat sovellettavissa tietyssä kontekstissa?
• Mitä menetelmiä ja ohjelmistotyökaluja käytetään kehitykseen ja ylläpitoon sekä laadunvarmistukseen ja parantamiseen (tuote ja prosessit)
• Budjetti, henkilöstö, projektitoiminnan organisointi, suunnitelmat ja aikataulut kaikille prosesseille
• Ketkä ovat kohdekäyttäjiä ja mikä on järjestelmän tarkoitus
• Järjestelmän eheyden taso

Tieto näistä tekijöistä vaikuttaa siihen, miten SQM-prosessit tarkasti organisoidaan ja dokumentoidaan, mitkä SQM-toiminnot valitaan (standardisoidaan projektin, tiimin, organisaatioyksikön, organisaation sisällä), mitä resursseja tarvitaan ja mitä rajoituksia on asetettu varmistaa laadun.

Luotettavuus

Takuu-takuu<высокой>luotettavuus, suojaus vikoja vastaan.
Tapauksissa, joissa järjestelmävika voi johtaa äärimmäisen vakaviin seurauksiin (tällaisia ​​järjestelmiä kutsutaan joskus englanninkielisissä lähteissä "korkea luotettavuus" tai "high integrity system", venäjäksi niitä kutsutaan joskus "korkean luotettavuuden järjestelmiksi", "korkeaksi". saatavuus” ja jne.), järjestelmän yleinen (kumulatiivinen) takuukapasiteetti (laitteiston, ohjelmiston ja ihmisten yhdistelmänä) on tärkein ja ensisijainen laatuvaatimus suhteessa päätoimintoihin<системы>.

Luotettavuus ohjelmisto sisältää sellaisia ​​ominaisuuksia kuin vikasietoisuus, käytön turvallisuus (turvallisuus - turvallisuus ihmisten terveydelle, liiketoiminnalle, omaisuudelle jne. aiheutuvan hyväksyttävän riskin yhteydessä), tietoturva tai turvallisuus (turvallisuus - tietojen suojaaminen luvattomalta toiminnalta, mukaan lukien lukuoikeudet sekä tietojen saatavuuden takaaminen valtuutetuille käyttäjille heille annettujen oikeuksien rajoissa sekä mukavuus ja helppokäyttöisyys (käytettävyys). Luotettavuus on myös kriteeri, joka voidaan määritellä takuun kannalta.

Asian käsittelyssä laaja kirjallisuus korkean luotettavuuden järjestelmistä on merkittävässä roolissa. Samalla käytetään terminologiaa, joka tulee perinteisten mekaanisten ja sähköisten järjestelmien alalta (mukaan lukien ne, jotka eivät sisällä ohjelmistoja) ja kuvaavat vaaran, riskien, järjestelmän eheyden jne. käsitteitä.

Ohjelmiston eheystasot

Ohjelmiston eheystaso määritetään ohjelmistovian mahdollisten seurausten ja tällaisen vian esiintymisen todennäköisyyden perusteella. Kun eri turvallisuusnäkökohdat (sovellus- ja tietoturva) ovat tärkeitä, voidaan vaara-analyysin (käyttöturvallisuuden yhteydessä) ja uhka-analyysin (tietoturvallisuuden yhteydessä) tekniikoiden avulla kehittää työsuunnitelmia mahdollisten onnettomuuksien hotspotien tunnistamiseksi. . Samankaltaisten järjestelmien vikojen historia voi myös auttaa tunnistamaan hyödyllisimmät tekniikat vikojen havaitsemiseksi ja<всесторонней>ohjelmiston laadun arviointi.

Tarkasteltaessa ohjelmiston eheyttä tarkemmin yksittäisten projektien yhteydessä, on välttämätöntä kiinnittää erityistä huomiota (oikea resurssien kohdentaminen ja tarvittavien töiden suorittaminen) paitsi SQM-prosesseihin (erityisesti muodollisiin, mukaan lukien auditointi ja sertifiointi), vaan myös vaatimusten hallintaan (kriteerien eheyden kannalta), riskienhallintaan (mukaan lukien riskien suunnittelu sekä kehitysvaiheessa että järjestelmän käyttö- ja ylläpitovaiheessa), suunnittelu (johon takuukapasiteetin lisäämiseksi tarvitaan välttämättä -käytettäviksi suunniteltujen arkkitehtonisten ja teknisten ratkaisujen syvällinen analyysi ja todentaminen, usein luomalla pilottihankkeita, esittelyosastoja jne.) ja testaus (jotta varmistetaan kattava tutkimus järjestelmän käyttäytymisominaisuuksista, mukaan lukien käyttöympäristön emulointi /konfiguraatio, jossa järjestelmää tulee käyttää käytön aikana).

Vian luonnehdinta

SQM-prosessit varmistavat, että viat löydetään. Vikaominaisuuksien kuvauksella on olennainen rooli tuotteen ymmärtämisessä, se helpottaa prosessin tai tuotteen säätöjä ja tiedottaa projektipäälliköille ja asiakkaille prosessin tai tuotteen tilasta. Vikojen (epäonnistumisen) taksonomioita (luokituksia ja strukturointimenetelmiä) on monia. Vikojen karakterisointia käytetään myös auditoinnissa ja arvioinneissa, joissa arvioinnin johtaja usein esittää luettelon arviointiryhmän jäsenten luomista poikkeavuuksista keskustelua varten asianmukaisissa kokouksissa.

Suunnittelumenetelmien ja -kielten evoluution (ja uusien ilmaantumisen) taustalla sekä uusien ohjelmistoteknologioiden kanssa ilmaantuu uusia virheluokkia. Tämä vaatii valtavasti vaivaa tulkita (ja korjata) aiemmin määriteltyjä vikaluokkia (vikoja). Vikoja jäljittäessään insinööri on kiinnostunut paitsi niiden lukumäärästä, myös niiden tyypistä. Vikojen jakautuminen tyypeittäin on erityisen tärkeää järjestelmän heikoimpien osien tunnistamisessa käytettävien teknologioiden ja arkkitehtonisten ratkaisujen kannalta, mikä johtaa niiden syvälliseen tutkimiseen, erityisten pilottiprojektien luomiseen, lisätodistuksia. konsepti (POC - usein käytetty lähestymistapa uusien teknologioiden käytössä), ulkopuolisten asiantuntijoiden houkutteleminen jne. Tieto itsessään, ilman luokittelua, on usein yksinkertaisesti hyödytöntä vikojen syiden tunnistamisessa, koska ongelmien ratkaisemistapojen määrittämiseksi on tarpeen ryhmitellä ne sopiviin tyyppeihin. Kysymys on määritellä virhetaksonomia, jolla on merkitystä insinööreille ja koko organisaatiolle.

SQM varmistaa tiedon keräämisen kaikissa ohjelmistokehityksen ja -ylläpidon vaiheissa. Yleensä kun sanomme "vika", tarkoitamme "vika", kuten alla on määritelty. Eri kulttuurit ja standardit voivat kuitenkin tarkoittaa eri merkityksiä näille termeille.

Tällaisten käsitteiden osittaiset määritelmät ovat seuraavat:

• Virhe:"Ero... oikean tuloksen ja lasketun tuloksen välillä<полученным с использованием программного обеспечения>”
• Vika:"Väärä vaihe, prosessi tai datamäärittely tietokoneohjelmassa."
• Epäonnistuminen: “<Некорректный>puutteen seurauksena saatu tulos"
• Ihmisen/käyttäjän virhe (virhe):"Ihmisen toiminta, joka johti väärään tulokseen"

Tätä aihetta käsiteltäessä vika ymmärretään ohjelmistovian seurauksena. Luotettavuusmallit rakennetaan ohjelmistotestauksen tai käytön aikana kerättyjen vikatietojen perusteella. Tällaisten mallien avulla voidaan ennustaa tulevia epäonnistumisia ja auttaa päättämään, lopetetaanko testaus.

Vikojen havaitsemiseen tähtäävän SQM-työn tulosten perusteella ryhdytään toimenpiteisiin vikojen poistamiseksi tutkittavasta tuotteesta. Asia ei kuitenkaan lopu tähän. On olemassa muita mahdollisia toimia, joilla voidaan hyödyntää täysimääräisesti asiaankuuluvan SQM-työn tuloksia. Niitä ovat analyysi ja yhteenveto (tiivistelmä)<по обнаруженным несоответствиям/дефектам>, kvantitatiivisten arviointitekniikoiden käyttö (mittareiden hankkiminen) tuotteen ja prosessin parantamiseksi, vikojen seuranta ja niiden poistaminen järjestelmästä (tarvittavien korjaavien toimenpiteiden hallinta ja tekninen valvonta). Tietolähde puolestaan ​​erityisesti prosessin parantamiseen on SQM-prosessi.

Tiedot asiaankuuluvien SQM-tekniikoiden käyttöönoton aikana löydetyistä epäjohdonmukaisuuksista ja vioista on kirjattava, jotta ne eivät katoa. Joissakin tekniikoissa (esim. tekninen arviointi, auditointi, tarkastukset) tallentimen läsnäolo on pakollista juuri tällaisten tietojen tallentamiseksi sekä asioiden (mukaan lukien lisäharkintaa vaativat) ja tehtyjen päätösten tallentamiseksi. Tapauksissa, joissa käytetään asianmukaisia ​​automaatiotyökaluja, ne voivat myös tarjota tarvittavat ulostulotiedot vioista (esim. yhteenvetotilastot vikatiloista, vastuuhenkilöistä jne.). Vikatietoja voidaan kerätä ja tallentaa ohjelmistomuutospyyntöjen (SCR) muodossa, ja ne voidaan myöhemmin syöttää tietyntyyppisiin tietokantoihin (esimerkiksi projektien välisten/historiallisten tilastojen seuraamiseksi lisäanalyysiä ja prosessin parantamista varten) sekä manuaalisesti että automaattisesti sopivista analyysityökaluista (useiden nykyaikaisten suunnittelutyökalujen ja erikoistyökalujen avulla voit analysoida koodia ja malleja sopivilla mittareilla, jotka ovat tärkeitä tuotteiden ja prosessien laadun varmistamiseksi). Vikaraportit lähetetään organisaation/organisaation yksikön tai rakenteen johtotasolle (asianmukaisten projektia, tuotetta, prosessia, henkilöstöä, budjettia jne. koskevien päätösten tekemiseksi).

Ohjelmiston laadunhallintatekniikat

SQM-tekniikat voidaan luokitella useisiin luokkiin:

• staattinen
• tekniikoita, jotka vaativat intensiivistä henkilöresurssien käyttöä
• analyyttinen
• dynaaminen

Staattiset tekniikat

Staattiset tekniikat sisältävät<детальное>suunnitteludokumentaation, ohjelmiston ja muun ohjelmistotuotteen tiedon tutkimus (tutkinta) ilman sen toteuttamista. Nämä tekniikat voivat sisältää muita jäljempänä käsiteltyjä "kollektiivisia" arviointeja tai "yksittäisiä" analyysitoimintoja riippumatta siitä, missä määrin automaatiota käytetään.

Ihmisintensiivisiä tekniikoita

Tämäntyyppiset tekniikat, mukaan lukien arviointi ja auditointi, voivat vaihdella muodollisista kokouksista epävirallisiin kokouksiin tai tuotetta koskeviin keskusteluihin ilman edes viittausta sen koodiin. Tyypillisesti tämäntyyppinen tekniikka sisältää kasvokkain tapahtuvan vuorovaikutuksen vähintään kahden ja useimmissa tapauksissa useamman asiantuntijan välillä. Samanaikaisesti tällaiset kokoukset voivat vaatia alustavaa valmistelua (lähes aina kokousten sisällön eli käsiteltävien asioiden listan määrittelyyn liittyvää). Tällaisissa tekniikoissa käytettävät resurssit sekä tutkittavat artefaktit (tuote, dokumentaatio, mallit jne.) voivat sisältää erilaisia ​​tarkistuslistoja ja analyyttisten tekniikoiden tuloksia (käsitellään alla) ja testaustyötä. Näitä tekniikoita käsitellään esimerkiksi standardissa 12207 tarkastelun ja auditoinnin yhteydessä.

Analyyttiset tekniikat

Ohjelmistoinsinöörit käyttävät tyypillisesti analyyttisiä tekniikoita. Kettereiden menetelmien ja lähestymistapojen näkökulmasta yksilöt ja vuorovaikutukset olettavat<непосредственное>viestintä ja jatkuva vuorovaikutus tiimin jäsenten välillä.

Joskus useat insinöörit käyttävät samaa tekniikkaa, mutta tuotteen eri osissa. Jotkut tekniikat perustuvat käytettyjen työkalujen erityispiirteisiin, toiset sisältävät "manuaalista" työtä. Monet voivat auttaa löytämään vikoja suoraan, mutta useimmiten niitä käytetään tukemaan muita tekniikoita. Useat tekniikat sisältävät myös erityyppisiä tutkimuksia (arviointia) olennaisena osana yleistä laatuanalyysiä. Esimerkkejä tällaisista tekniikoista ovat monimutkaisuusanalyysi, ohjauslogiikkaanalyysi (tai ohjausvirta-analyysi) ja algoritminen analyysi.

Jokaisella analyysityypillä on tietty tarkoitus, eivätkä kaikki tyypit sovellu kaikkiin projekteihin. Esimerkki tukitekniikasta on monimutkaisuusanalyysi, joka on hyödyllinen tunnistamaan järjestelmäsuunnittelun osat, jotka ovat liian monimutkaisia ​​oikein toteutettavaksi, testattavaksi tai ylläpidettäväksi. Monimutkaisuusanalyysin tulosta voidaan käyttää myös testitapausten kehittämiseen. Vianilmaisutekniikoita, kuten ohjauslogiikkaanalyysiä, voidaan käyttää myös muissa tapauksissa. Ohjelmistoissa, joissa on laaja algoritmilogiikka, on erittäin tärkeää soveltaa algoritmitekniikoita, erityisesti tapauksissa, joissa virheellinen algoritmi (ei sen toteutus, vaan logiikka, tekijän huomautus) voi johtaa katastrofaalisiin tuloksiin (esim. avioniikkaohjelmistot, joiden turvallisuus käyttöongelmat – turvallisuudella on ratkaiseva rooli).

Muut, muodollisemmat analyyttiset tekniikat tunnetaan muodollisina menetelminä. Niitä käytetään vaatimusten ja suunnittelun tarkistamiseen (tosin vain satunnaisesti nykypäivän teollisen ohjelmistokehityksen käytännössä). Oikeustarkistusta sovelletaan kriittisiin ohjelmistoihin (jolla ei yleisesti ottaen ole juurikaan tekemistä muodollisten menetelmien kanssa - tämä on luonnollinen tapa saavuttaa hyväksyttävä laatu ja minimoida kustannukset). Useimmiten niitä käytetään toiminnan kannalta kriittisten järjestelmien erityisen tärkeiden osien, esimerkiksi erityisvaatimusten, tarkistamiseen<информационной>turvallisuus ja luotettavuus.

Dynaamiset tekniikat

Ohjelmistojen kehittämis- ja ylläpitoprosessissa on turvauduttava erilaisiin dynaamisiin tekniikoihin. Pohjimmiltaan nämä ovat testaustekniikoita. Simulaatiotekniikoita, mallin tarkistusta ja "symbolista suoritusta" voidaan kuitenkin pitää dynaamisina tekniikoina (symbolinen suoritus sisältää usein "tyhjennettyjen" moduulien käytön suoritettavan logiikan kannalta, emuloidulla syötteellä ja lähdöllä, kun tarkastellaan yleistä skenaariota monimoduulijärjestelmien käyttäytyminen joskus Tämä termi sisältää myös muita tekniikoita valitusta lähteestä riippuen).

Koodin tarkistamista (lukemista) pidetään yleensä staattisena tekniikkana, mutta kokenut insinööri voi suorittaa koodin suoraan "samalla" sitä lukeessaan (esimerkiksi käyttämällä interaktiivisia vaiheittaisia ​​virheenkorjaustyökaluja jonkun toisen koodin tarkistamiseen tai arvioimiseen). Tästä tekniikasta voidaan siis puhua myös dynaamisena. Tällaiset erot tekniikoiden luokittelussa osoittavat selvästi, että henkilön roolista organisaatiossa riippuen hän voi hyväksyä ja soveltaa samoja tekniikoita eri tavoin.

Riippuen organisaatiosta<ведения>SQA- ja V&V-prosessien ohjelmistojärjestelmien kehittämisen aikana voidaan tehdä tiettyjä testaustyötä. Koska SQM-suunnitelmassa käsitellään testausongelmia, tämä aihe sisältää joitain kommentteja testauksesta.

Testaus

Vahvistusprosessit<качества> , kuvattu SQA:ssa ja V&V:ssä<планах>, tutkia ja arvioida kaikki tulosteet (mukaan lukien väli- ja lopputuotteet), jotka liittyvät ohjelmiston vaatimuksiin seuraaville kohteille:

• jäljitettävyys
• johdonmukaisuus
• täydellisyys/täydellisyys,
• oikeellisuus
• ja suora toteutus<требований>(esitys).

Tällainen vahvistus kattaa myös kaikki kehitys- ja ylläpitoprosessien tuotosartefaktit, tulosten keräämisen, analysoinnin ja kvantifioinnin. SQA-toiminnalla varmistetaan, että sopivat (jossa projektikontekstissa tarvittavat) testityypit suunnitellaan, suunnitellaan ja toteutetaan ja V&V - testisuunnitelmien, strategioiden, skriptien ja menettelytapojen kehittäminen<тестирования>.
Testauskysymyksiä käsitellään yksityiskohtaisesti Testaustiedot -alueella. Kahden tyyppinen testaus noudattaa SQA:n ja V&V:n asettamia tavoitteita, koska ne ovat vastuussa projektissa käytetyn datan laadusta:

• Projektissa käytettyjen työkalujen arviointi ja testaus
• Komponenttien ja COTS-tuotteiden (COTS - kaupallinen, käyttövalmis tuote) vaatimustenmukaisuustestaus (tai vaatimustenmukaisuustestien arviointi) käytettäväksi luotavassa tuotteessa.

Joskus riippumattomat V&V-organisaatiot voivat vaatia kykyä valvoa testausprosessia ja tietyissä tapauksissa varmentaa (tai useammin dokumentoida/tallentaa) todellista toteutusta.<тестов>varmistaakseen, että ne suoritetaan määrättyjen menettelyjen mukaisesti. Toisaalta V&V:lle voidaan soittaa arvioimaan itse testausta: suunnitelmien ja toimintatapojen riittävyyttä, tulosten soveltuvuutta ja tarkkuutta.

Toinen V&V-organisaation valvonnassa suoritettava testaustyyppi on kolmannen osapuolen testaus. Tällainen kolmas osapuoli ei ole itse tuotteen kehittäjä eikä ole millään tavalla sidoksissa tuotteen kehittäjään. Kolmas osapuoli on lisäksi riippumaton arvioinnin lähde, jolla on yleensä akkreditointi asianmukaiset valtuudet (esimerkiksi standardin kehittänyt organisaatio, jonka noudattamista arvioi riippumaton asiantuntija ja jonka toiminnan standardin laatija vahvistaa ). Tämäntyyppisen testauksen tarkoituksena on tarkistaa, että tuote täyttää tietyt vaatimukset (esimerkiksi tietoturva).

Ohjelmiston laadun mittaus

Ohjelmistotuotteiden laatumallit sisältävät usein mittareita, joilla määritetään tuotteen kunkin laatuominaisuuden taso.

Jos laatuominaisuudet valitaan oikein, tällaiset mittaukset voivat tukea laatua (laatutasoa) monin tavoin. Mittarit voivat auttaa ohjaamaan päätöksentekoprosessia. Mittarit voivat auttaa tunnistamaan prosessien ongelmalliset näkökohdat ja pullonkaulat. Mittarit ovat työkalu insinööreille arvioida työnsä laatua - sekä SQA:n määrittelemiin tarkoituksiin että pidemmän aikavälin parannusprosessin näkökulmasta<достигаемого>laatu.
Ohjelmiston sisäisen monimutkaisuuden ja kehittyneisyyden lisääntyessä laatuongelmat menevät paljon pidemmälle kuin sen tosiasian ilmoittaminen, että ohjelmisto toimii tai ei toimi. Kysymys on siitä, kuinka hyvin määrälliset laatutavoitteet saavutetaan.

On useita muita aiheita, jotka käsittelevät mittareita, jotka tukevat suoraan SQM:ää. Näihin kuuluu apua päätettäessä, milloin testaus lopetetaan. Tässä yhteydessä luotettavuusmallit ja vertailut näytteisiin (standardit, jotka hyväksytään esimerkkeinä tietystä laadusta - vertailuarvot) vaikuttavat hyödyllisiltä.

SQM-prosessin kustannukset ovat yksi<проблемных>kysymyksiä, jotka tulevat aina esille päätettäessä, miten projekti (suunnittelutyö) järjestetään. Usein käytetään yleisiä kustannusmalleja, jotka perustuvat siihen, että määritetään tarkalleen, milloin vika havaitaan ja kuinka paljon vaivaa sen korjaaminen vaatii verrattuna tilanteeseen, jos vika löydettäisiin aiemmin elinkaaren aikana. Suunnittelutiedot voivat auttaa antamaan selkeämmän kuvan kustannuksista.

Lopuksi SQM-raportointi itsessään tarjoaa hyödyllistä tietoa ei vain itse prosesseista (mikä tarkoittaa niiden nykytilaa, kirjoittajan huomautus), vaan myös siitä, kuinka kaikkia elinkaariprosesseja voidaan parantaa.

Vaikka laatuominaisuuksien kvantitatiiviset arviot (tässä tapauksessa puhumme arviointien tuloksista, ei mittausprosessista) voivat olla hyödyllisiä sinänsä (esimerkiksi täyttämättömien vaatimusten määrä ja tällaisten vaatimusten osuus), ne voivat<эффективно>käyttää matemaattisia ja graafisia tekniikoita metristen arvojen tulkinnan helpottamiseksi. Tällaiset tekniikat luokitellaan luonnollisesti esimerkiksi seuraavasti:

• Perustuu tilastollisiin menetelmiin (esim. Pareto-analyysi, normaalijakauma jne.)
• Tilastolliset testit
• Trendianalyysi
• Ennuste (esim. luotettavuusmallit)

Tilastolliset tekniikat ja tilastolliset testit tarjoavat usein "tilanteen" tutkittavan ohjelmistotuotteen ongelmallisimmista alueista (ja muuten, sama pätee usein prosesseihin). Tuloksena olevat kaaviot ja kaaviot auttavat päätöksentekijöitä visuaalisesti tunnistamaan alueita, joihin resurssit keskitetään<проекта>. Trendianalyysin tulokset voivat osoittaa, että aikataulua rikotaan esimerkiksi testauksen aikana; tai että tietyt vikaluokat yleistyvät, kunnes korjaavat toimet toteutetaan kehityksen aikana. Ennustustekniikat auttavat testien ajoittamisessa ja epäonnistumisten ennustamisessa.

Ohjelmiston laatuominaisuudet

Siirrettävyys- Joukko attribuutteja, jotka liittyvät ohjelmiston kykyyn siirtää ympäristöstä toiseen.
HUOMAA Ympäristö voi sisältää organisatorisen, teknisen tai ohjelmistoympäristön.

Luotettavuus- Joukko määritteitä, jotka liittyvät ohjelmiston kykyyn ylläpitää suoritustasoaan tietyissä olosuhteissa tietyn ajanjakson ajan.

Huomautuksia:

1. Ohjelmistossa ei ole kulumista tai ikääntymistä. Luotettavuusrajoitukset johtuvat virheistä vaatimuksissa, suunnittelussa ja toteutuksessa. Näistä virheistä johtuvat viat riippuvat ohjelmiston käytöstä ja aiemmin valituista ohjelmistoversioista.
2. ISO 8402 määrittelee "luotettavuuden" "elementin kyvyksi suorittaa vaadittu toiminto". Tässä standardissa toiminnallisuus on vain yksi ohjelmiston laadun ominaisuuksista. Siksi luotettavuuden määritelmää on laajennettu siten, että se "säilyttää suorituskykynsä" sen sijaan, että "suorittaisi vaaditun toiminnon".

Käytettävyys- Joukko attribuutteja, jotka liittyvät käyttöön vaadittavan työn laajuuteen ja tietyn tai aiotun käyttäjien suorittaman käytön yksilölliseen arviointiin.

Huomautuksia:

1. "Käyttäjät" voidaan tulkita suurimmaksi osaksi interaktiivisen ohjelmiston suoria käyttäjiä. Käyttäjiä voivat olla operaattoreita, loppukäyttäjiä ja epäsuoria käyttäjiä, joihin ohjelmisto vaikuttaa tai jotka ovat siitä riippuvaisia. Käytännöllisyys on otettava huomioon kaikissa käyttäjien käyttöolosuhteissa, jotka voivat vaikuttaa ohjelmistoon, mukaan lukien käyttöön valmistautuminen ja tulosten arviointi.
2. Käytettävyys, joka tässä standardissa määritellään ohjelmistotuotteen tietyksi ominaisuusjoukoksi, eroaa määritelmästä ergonomian näkökulmasta, jossa muita ominaisuuksia, kuten tehokkuutta ja tehottomuutta, pidetään käytettävyyden komponentteina.

Ylläpidettävyys- Joukko määritteitä, jotka liittyvät tiettyjen muutosten (muokkausten) suorittamiseen vaadittavien töiden laajuuteen.
HUOMAA Muutokset voivat sisältää korjauksia, parannuksia tai ohjelmiston mukautuksia ympäristön, vaatimusten ja käyttöolosuhteiden muutoksiin.

Toiminnallisuus- Joukko attribuutteja, jotka liittyvät funktiojoukon olemukseen ja niiden erityisiin ominaisuuksiin. Toiminnot ovat niitä, jotka täyttävät ilmoitettuja tai ennakoituja tarpeita.

Huomautuksia:

1. Tämä attribuuttijoukko kuvaa, mitä ohjelmisto tekee tarpeiden tyydyttämiseksi, kun taas muut joukot kuvaavat ensisijaisesti sitä, milloin ja miten se suoritetaan.
2. Tässä spesifikaatiossa laadunmäärittelyhuomautus on otettu huomioon ilmoitettujen ja ennakoitujen tarpeiden osalta.

Tehokkuus- Joukko määritteitä, jotka liittyvät ohjelmiston toiminnan laatutason ja tietyissä olosuhteissa käytettyjen resurssien määrän väliseen suhteeseen.
HUOM. Resurssit voivat sisältää muita ohjelmistotuotteita, laitteistoja, materiaaleja (esimerkiksi tulostuspaperia, levykkeitä) ja käyttö-, huolto- tai huoltohenkilöstön palveluita.

Ohjelmistotuotteiden laatu

Ohjelmiston laatu- ohjelmistotuotteen ominaisuuksien ja ominaisuuksien koko valikoima, joka liittyy sen kykyyn täyttää olemassa olevat tai odotettavissa olevat tarpeet.

Kunkin laatuominaisuuden tärkeys vaihtelee ohjelmistoluokan mukaan. Esimerkiksi luotettavuus on tärkeintä taistelukriittisille järjestelmäohjelmistoille, tehokkuus on tärkeintä aikakriittisille reaaliaikaisille järjestelmäohjelmistoille ja käytettävyys on tärkeintä loppukäyttäjien dialogiohjelmistoille.

Kunkin laatuominaisuuden tärkeys vaihtelee myös valitun näkökulman mukaan.

Käyttäjänäkymä

Käyttäjiä kiinnostaa pääasiassa ohjelmiston sovellus, sen suorituskyky ja käytön tulokset. Käyttäjät arvioivat ohjelmistoa tutkimatta sen sisäisiä puolia tai ohjelmiston luomistapaa.

Käyttäjä voi olla kiinnostunut seuraavista kysymyksistä:

• Onko ohjelmistossa tarvittavat ominaisuudet?
• Kuinka luotettava ohjelmisto on?
• Kuinka tehokas ohjelmisto on?
• Onko ohjelmisto helppokäyttöinen?
• Kuinka helppoa ohjelmistojen ja muiden ympäristöjen siirtäminen on?

Kehittäjänäkymä

Luontiprosessi edellyttää, että käyttäjä ja kehittäjä käyttävät samoja ohjelmiston laatuominaisuuksia, joita käytetään vaatimusten ja hyväksynnän määrittämiseen. Kun ohjelmistoa kehitetään myytäväksi, laatuvaatimusten on vastattava aiottuja tarpeita.

Koska kehittäjät ovat vastuussa sellaisten ohjelmistojen luomisesta, joiden on täytettävä laatuvaatimukset, he ovat yhtä kiinnostuneita välituotteiden laadusta kuin lopputuotteen laadusta. Arvioidakseen välituotteiden laatua kehityssyklin jokaisessa vaiheessa kehittäjien on käytettävä eri mittareita samoilla ominaisuuksilla, koska samat mittarit eivät päde kaikkiin elinkaaren vaiheisiin.

Käyttäjä ymmärtää tehokkuuden esimerkiksi vasteajan perusteella, kun taas suunnittelija käyttää suunnitteluspesifikaatioissa reitin pituuden ja latenssin sekä pääsyajan termejä. Tuotteen ulkoisessa käyttöliittymässä käytetyt mittarit ovat vaihdettavissa sen rakenteessa käytettyjen mittareiden kanssa.

Johtajan esittely

Johtaja saattaa olla enemmän kiinnostunut kokonaislaadusta kuin tietystä laatuominaisuudesta, ja tästä syystä hänen on määritettävä yksittäisten ominaisuuksien liiketoiminnan vaatimuksia heijastavien arvojen merkitys.
Johtajan on ehkä myös punnittava laatuparannuksia hallittavuuskriteereihin, kuten suunniteltuihin viivästyksiin tai kustannusylityksiin, nähden, koska hän haluaa optimoida laadun kustannusten, työvoiman ja ajan rajoissa.

Ohjelmistotuotteiden laadun arviointi

Seuraavassa kuvassa esitetään tärkeimmät vaiheet ohjelmiston laadun arvioimiseksi.

Kuva "Arviointiprosessin malli"

Arviointiprosessi koostuu kolmesta vaiheesta: laatuvaatimusten asettaminen (määrittely), arviointiin valmistautuminen ja arviointimenettely. Tätä prosessia voidaan soveltaa kunkin ohjelmistokomponentin elinkaaren missä tahansa sopivassa vaiheessa.
Alkuvaiheen tarkoituksena on asettaa laatuominaisuuksia koskevat vaatimukset. Vaatimukset ilmaisevat ulkoisen ympäristön tarpeita kyseiselle ohjelmistotuotteelle ja ne on määritettävä ennen kehityksen aloittamista.
Toisen vaiheen tarkoituksena on valmistella perusteet arvioinnille.
Kolmannen tulos on johtopäätös ohjelmistotuotteiden laadusta. Yleistä laatua verrataan sitten muihin tekijöihin, kuten aikaan ja kustannuksiin. Lopullinen johdon päätös tehdään ohjattavuuskriteerin perusteella. Tuloksena on johdon päätös hyväksyä tai hylätä tai julkaista tai olla julkaisematta ohjelmistotuotteita.

Prosessin laatumalli

Kehitysprosessi on rakennettava siten, että tuotteen laatua voidaan mitata. Tehdyt tutkimukset osoittavat, että mitä laadukkaampi kehitysprosessi on, sitä korkeampi on tässä prosessissa kehitetty ohjelmisto. Laatu projektin jokaisessa vaiheessa paranee ensinnäkin suorana seurauksena prosessin kypsyydestä ja toiseksi edellisessä vaiheessa tuotetun korkealaatuisemman välituotteen käytön vuoksi. Korostetaan, että toisen syyn merkitys, joka varmistaa kypsien prosessien laadun nousun elinkaaren aikana, osoittautuu paljon tärkeämmäksi. Kaikki tämä voidaan esittää jonkin mallin muodossa.

Kuva "Kehitysprosessin laadun käsitteellinen malli"

Tästä seuraa seuraavat seuraukset:
Ensinnäkin: laatu kumuloituu tuotteeseen kompleksisessa tuotannossa kumulatiivisesti, ja alkuvaiheessa tehty panos laatuun vaikuttaa lopputuotteeseen voimakkaammin kuin myöhemmissä vaiheissa. Tämän vahvistaa kaikki ohjelmointikäytäntö, esimerkiksi tiedetään, että järjestelmän suunnittelun puutteita ei voida kompensoida korkealaatuisella koodauksella.
Siksi monimutkaisen järjestelmän rakentamisen laadun hallitsemiseksi on välttämätöntä valita valmistajat käytettävien kehitysprosessien kypsyysasteen ja läpinäkyvyyden mittaamisen perusteella. Urakoitsijan kehitysprosessin laadun mittaaminen on tärkeä osa kokonaislaadunhallintaa, tärkeämpää kuin vastaanottotestauksen aikana valmistetun lopputuotteen laadun mittaaminen.
Toiseksi: testausta ja laadunmittausta on tapahduttava elinkaaren kaikissa vaiheissa. Laadukkaiden tietojen hakeminen alkuvaiheessa voi olla erittäin kallista ilman täydellisiä tuloksia

Laatuominaisuuksien soveltamisohjeet

1 Soveltuvuus

2 Ideoita ohjelmiston laadusta

2.1 Käyttäjänäkymä
2.2 Kehittäjän esittely
2.3 Johtajan esittely

3.1 Laatuvaatimusten asettaminen

3.2 Arviointiin valmistautuminen

3.2.1 Laatumittareiden (indikaattorien) valinta
3.2.2 Sijoitustasojen määrittäminen
3.2.3 Arviointikriteerin määrittely

3.3 Arviointimenettely

3.3.1 Mittaus
3.3.2 Ranking
3.3.3 Arviointi

1. Esittely

2 Kattavien laatuindikaattoreiden määrittely

2.1 Toiminnallisuus

2.1.1 Soveltuvuus
2.1.2 Tarkkuus
2.1.3 Yhteentoimivuus
2.1.4 Vaatimustenmukaisuus
2.1.5 Turvallisuus

2.2 Luotettavuus

2.2.1 Vakaus (maturiteetti)
2.2.2 Vikasietokyky
2.2.3 Palautettavuus

2.3 Käytettävyys

2.3.1 Ymmärrettävyys
2.3.2 Oppittavuus
2.3.3 Helppokäyttöisyys (käytettävyys)

2.4 Tehokkuusedut

2.4.1 Aikakäyttäytyminen
2.4.2 Resurssien käyttäytyminen

2.5 Ylläpidettävyys

2.5.1 Analysoitavuus
2.5.2 Vaihdettavuus
2.5.3 Vakaus
2.5.4 Testattavuus

2.6 Siirrettävyys

2.6.1 Sopeutuvuus
2.6.2 Käyttöönoton helppous (asennettavuus)
2.6.3 Yhdenmukaisuus
2.6.4 Vaihdettavissa

Huomautuksia:

1. Yhteensopivuuden sijaan käytetään vaihdettavuutta, jotta vältetään mahdolliset sekaannukset yhteentoimivuuteen.
2. Vaihdettavuus tietyn ohjelmistotyökalun kanssa ei tarkoita, että työkalu olisi vaihdettavissa kyseisen ohjelmistotyökalun kanssa.
3. Vaihdettavuus voi sisältää toteutuksen helppouden ja mukautuvuuden ominaisuuksia. Käsite otettiin käyttöön erillisenä alaominaisuutena sen tärkeyden vuoksi.

Projektin laatu

Laatu sisältää kaikki hankkeen toiminnot, joilla varmistetaan, että hanke täyttää tavoitteet, joita varten se on toteutettu. Laadunhallinta koskee siis sekä projektia että projektituotetta.
Laatu on erittäin tärkeää, koska se ilmaisee ja tallentaa tavoitteet ja tekee niistä dokumentoituja (virallisia).
Siksi laatu on kriittinen osa projektirakenteen hallintaa.
Laadun kannalta kaikki on mitattavissa.

Projektin laadunhallinta

Jos laadunhallinta keskittyy johonkin organisaation osaan, siitä ei tule universaalia. Projektipäällikkö voi delegoida laadunhallinnan osa-alueita. Projektipäällikköllä on lopullinen vastuu.

Laatuperiaatteet (ISO 9000)

1. Asiakaslähtöisyys
2. Johdon vastuu
3. Ihmisten sitouttaminen
4. Prosessilähestyminen
5. Systemaattinen lähestymistapa johtamiseen
6. Jatkuva parantaminen
7. Tosiasioihin perustuva päätöksenteko
8. Molempia osapuolia hyödyttävät suhteet tavarantoimittajien kanssa

Kuva "Erot laadunhallinnan ymmärtämisessä ISO 9000:ssa ja PMBoK:ssa"

Projektin laadunhallinta (PMI): osaprosessit

• Laadukas suunnittelu
• Laatuvakuutus
• Laadunvalvonta

Laadukas suunnittelu

Yksi vaiheista on määrittää, mitä olemassa olevia standardeja sovelletaan tiettyyn hankkeeseen ja miten niitä noudatetaan. Laatusuunnittelun tulos on luettelo kaikista projektiin sovellettavista laatustandardeista. Ohessa on luettelo suosituksista, kuinka näiden standardien vaatimukset täytetään.

Laadun suunnitteluprosessi: panokset

• Laatupolitiikka. Dokumentti, joka sisältää periaatteet siitä, miten organisaatio määrittelee laadun, mutta ei sisällä tapoja saavuttaa laatua.
• Hankkeen sisältö (laajuus). Määrittää, mitä projektin tuloksena on tehtävä ja mitä siten laadunhallintaprosesseissa on seurattava. Tämä asiakirja on hankkeen laajuuden suunnitteluprosessin tulos.
• Tuotteen Kuvaus. Sisältää teknisiä yksityiskohtia ja muita olennaisia ​​näkökohtia, jotka voivat vaikuttaa laatusuunnitteluun.
• Standardit ja määräykset. Luettelo tiettyä aluetta tai hanketta koskevista standardeista ja määräyksistä.
• Muut asiakirjat.

Laadun suunnitteluprosessi: työkalut ja teknologiat

• Hyöty/kustannusanalyysi. Liittyy keskusteluun laadun kustannuksista. Tämän työkalun tarkoituksena on verrata laadun puutteen todellisia kustannuksia laadunvarmistuksen hyötyihin.
• Vertailu. Käytetään parannusideoiden luomiseen muihin projekteihin verrattuna. Se on tehokkainta, kun vertailu tehdään parhaiden kanssa, ei vain muiden sisäisten projektien kanssa.
• Kaaviot. Käytetään osoittamaan, kuinka eri elementit toimivat vuorovaikutuksessa. Kaavioita on monenlaisia, mukaan lukien syy-seurauskaavio.
• Kokeiden määrittäminen. Käytä mitä jos -skenaarioita määrittääksesi, mitkä muuttujat vaikuttavat eniten projektin lopputulokseen.
• Laadun hinta.

Laadun suunnitteluprosessi: tuotokset, tulokset

• Laadunhallintasuunnitelma. Kuvaa, kuinka projektinjohtoryhmä toteuttaa laatupolitiikkaa. Pitäisi kattaa seuraavat alueet:
• Suunnittelun ohjaus.
• Dokumentaation valvonta.
• Materiaalihankinnan valvonta.
• Tarkastukset.
• Testien valvonta (testaus).
• Ohjaus- ja mittauslaitteiden valvonta.
• Korjaavat toimenpiteet.
• Laatulevyjä.
• Tarkastukset (suunnitelma ja menettely)
• Dokumentoidut menettelyt ja työohjeet. Niissä kuvataan yksityiskohtaisesti prosesseja ja kuinka prosessin, osaprosessin ja suoritettujen yksittäisten toimien laatua mitataan.
• Tarkistuslistat. Luettelo kysymyksistä varmistaaksesi, ettei mitään puutu.

Laatuvakuutus

Laadunvarmistusprosessi- tämä on suunniteltujen systemaattisten toimenpiteiden hyväksymistä, jotta varmistetaan kaikkien määriteltyjen prosessien toteuttaminen, jotta hanke (tuote, palvelu) täyttää laatuvaatimukset.
Laadunvarmistus on laadunhallinnan tärkein osaprosessi. Tämä toiminta jatkuu koko projektin ajan.

Laatuprosessi: tulot

• Työohjeet. Toinen laatusuunnitteluprosessin tulos.
• Laadunvalvontamittausten tulokset. Laadunvalvontaprosessin tulos.

Laadunvarmistusprosessi: työkalut ja tekniikat

Laadukkaat suunnittelutyökalut ja -tekniikat. Näitä ovat kustannus-hyötyanalyysit, vertailut, kaaviot, kokeellinen suunnittelu ja laadun kustannusarviot.

Laatuauditoinnit

Strukturoidut "sisäänkirjautumiset", jotka vahvistavat "oppitunteja". Laatuauditoinnin tyypit ovat:

• sisäinen ulkoinen,
• järjestelmä / tuote / prosessi / organisaatio,
• suunniteltu/säännöllinen,
• erikoista ja monimutkaista.

Laadunvarmistusprosessi: Tuotokset

Laadun parantaminen. Sisältää toimenpiteitä hankkeen tehokkuuden ja tuottavuuden lisäämiseksi, jotta projektin omistajille saadaan lisäetuja.

Laadunvalvonta

Valvonta tiettyjä tuloksia, jotta voidaan määrittää niiden noudattaminen hyväksyttyjen laatustandardien kanssa ja tunnistaa tapoja poistaa epätyydyttävän suorituskyvyn syyt.

Laadunvalvontaprosessi: tulot

• Työn tulokset. Tulokset näkyvät aina yhteistyön, toteutuksen ja projektin uudelleensuunnittelun prosessissa.
• Laadunhallintasuunnitelma. Laatusuunnitteluprosessin tulos.
• Työohjeet. Laatusuunnitteluprosessin tulos.
• Tarkistuslistat.

Laadunvalvonta: työkalut ja tekniikat

• Tarkastukset. Sisältää toimintoja, kuten mittauksen, testauksen, testauksen sen varmistamiseksi, että tulos täyttää vaatimukset.
• Kontrollikaaviot. Ajokaaviot määrittelevät tilastollisesti ylä- ja alarajat, jotka näkyvät prosessin keskiarvojen kummallakin puolella.
• Kaaviot: Ishikawa, Pareto.
• Tilastollinen otanta.
• Trendianalyysi.

« Työkalujen käytön tarkoitus– tallenna tulokset tai muutokset, näytä ne graafisesti ja tunnista ja korjaa ongelmat sopivalla tavalla."

Laadunvalvontaprosessi: lähdöt

• Laadun parantaminen. Poistu laadunvarmistusprosessista.
• Tehdä päätöksiä. Päätökset tehdään sen mukaan, hyväksytäänkö vai hylätäänkö tarkastettu kohde.
• Korjaavat toimenpiteet. Toimi, jolla pyritään saattamaan vaatimustenvastainen esine vaatimustenmukaiseksi.
• Täytetyt tarkistuslistat.
• Prosessin asetukset.

Viitteet

• http://sorlik.blogspot.com, Sergei Orlik, 2004-2005
• Genelt A.E. Koulutus- ja metodologinen käsikirja tieteenalalle "Ohjelmistokehityslaadun hallinta" 2007, Pietari

Laadunhallinnan suurin ongelma on se, että laadun määritelmä on liian epämääräinen ja moniselitteinen. Tämä johtuu siitä, että termi laatu ymmärretään yleensä väärin. Tämä hämmennys voi johtua useista syistä...

Yritetään vastata kysymyksiin:

• Suosittu näkemys laadusta
• johtopäätöksiä

Mikä on ohjelmiston laatu?

Ensimmäisessä jaksossa yritämme määritellä termit laatu ja ohjelmiston laatu.

Laadunhallinnan suurin ongelma on se, että laadun määritelmä on liian epämääräinen ja moniselitteinen. Tämä johtuu siitä, että termi laatu ymmärretään yleensä väärin. Tämä hämmennys voi johtua useista syistä.

Ensimmäinen, laatu ei ole yksittäinen idea tai käsite, vaan moniulotteinen ja monipuolinen käsite.

Toinen, mille tahansa käsitteelle ja määritelmälle on olemassa useita abstraktiotasoja, esimerkiksi kun ihmiset puhuvat laadusta, yksi osa ymmärtää sen hyvin laajasti ja epämääräisesti, kun taas toinen voi viitata tiettyyn määritelmään ja merkitykseen.

Kolmanneksi, termi laatu on olennainen osa jokapäiväistä viestintäämme, mutta yleinen ja ammattimainen käyttö voi olla hyvinkin erilaista.

Suosittu näkemys laadusta

Yleisesti hyväksytty näkemys laadusta on, että se on jotain aineetonta ja "aineetonta" - siitä voidaan keskustella ja keskustella, sitä voidaan kritisoida ja kehua, mutta laatua on mahdotonta punnita ja mitata. Sellaiset ilmaisut kuin "hyvä laatu" ja "huono laatu" ovat selkeä esimerkki siitä, kuinka ihmiset puhuvat jostakin, joka on heille epämääräinen, josta ei voi selvästi luonnehtia ja määritellä. Tämä näkemys heijastaa sitä tosiasiaa, että ihmiset näkevät ja tulkitsevat laadun eri tavalla. Ymmärretään, että laatua ei voida valvoa ja hallita, eikä sitä voi vielä enempää mitata. Tämä näkemys eroaa jyrkästi ammattimaisesta laadunhallinnan lähestymistavasta - laatu on selkeästi määritelty suure, jota voidaan mitata ja valvoa, sitä voidaan hallita ja parantaa.

Toinen suosittu mielipide on, että laatu liittyy erottamattomasti ylellisyyteen, ensiluokkaiseen ja herkkään makuun. Kallis, hyvin harkittu ja teknisesti monimutkaisempi tuote nähdään korkeamman laadun takuuna kuin halvemmat analogit. Tämän logiikan mukaan Cadillac on laadukas auto, mutta Chevrolet ei ole, luotettavuudestaan ​​ja vikojen lukumäärästä huolimatta; tai HI-FI-järjestelmä on laadukas järjestelmä, mutta tavallinen radio ei ole. Tämän lähestymistavan mukaan laatu rajoittuu tiettyyn kalliisiin tuotteisiin, joissa on monimutkaiset toiminnot ja luokan tuotteet. Yksinkertaisesti sanottuna edullista tuotetta ei todennäköisesti luokitella laadukkaaksi tuotteeksi.

Ammattimainen lähestymistapa laatuun

Valitettavasti tällaista epämääräistä ja epämääräistä näkemystä ei voida käyttää ohjelmistokehitysprosessien parantamiseen. Siksi on tarpeen antaa selkeä ja toimiva määritelmä. Vuonna 1979 Crosby määritteli laadun "vaatimustenmukaiseksi" ja Juran ja Gryna vuonna 1970 määrittelivät laadun "sopivuudeksi käyttöön". Nämä kaksi määritelmää liittyvät läheisesti toisiinsa ja sopivat täydellisesti, kuten näemme myöhemmin.

"Vaatimusten noudattaminen" olettaa, että vaatimukset on määriteltävä niin selkeästi, ettei niitä voida ymmärtää väärin tai tulkita väärin. Myöhemmin, kehitysvaiheessa, tehdään kehitetyn tuotteen säännöllisiä mittauksia vaatimustenmukaisuuden toteamiseksi. Kaikki poikkeamat on katsottava puutteeksi - laadun puutteeksi. Esimerkiksi tietyn radiomallin eritelmät voivat edellyttää kykyä vastaanottaa tietyn taajuuden radioaaltoja yli 30 kilometrin etäisyydellä lähetyslähteestä. Jos radioasema ei pysty täyttämään tätä vaatimusta, se ei täytä laatuvaatimuksia ja sitä on pidettävä käyttökelvottomana ja huonolaatuisena. Samojen periaatteiden mukaan, jos Cadillac täyttää kaikki Cadillac-autoille asetetut vaatimukset, se on laatuauto. Jos Chevrolet täyttää kaikki Chevrolet-autojen vaatimukset, se on myös laadukas auto. Nämä kaksi autoa voivat olla täysin erilaisia ​​tyyliltään, nopeudeltaan ja taloudellisuudeltaan, mutta jos molemmat mitataan standardistandardeihinsa nähden, ne ovat molemmat laadukkaita autoja.

Määritelmä "Käytettävyyttä" ottaa huomioon tuotteen loppukäyttäjien vaatimukset ja odotukset, jotka odottavat tarjottavan tuotteen tai palvelun olevan heidän tarpeisiinsa sopiva. Eri käyttäjät voivat kuitenkin käyttää tuotetta eri tavoin, mikä tarkoittaa, että tuotteella tulee olla mahdollisimman monta erilaista käyttötapaa. Juranin määritelmän mukaan jokainen käyttötapaus on laatuominaisuus ja ne kaikki voidaan luokitella käytettävyysparametreiksi.

Nämä kaksi laadun määritelmää ("vaatimustenmukaisuus" ja "sopivuus tarkoitukseen") ovat pohjimmiltaan samat. Erona on, että "kelpoisuus" tarkoittaa, että asiakkaiden vaatimukset ja odotukset ovat tärkeitä. Asiakkaan roolia suhteessa laatuun ei voi koskaan yliarvioida. Asiakkaan näkökulmasta hänen ostamansa tuotteen laatu koostuu monista eri tekijöistä, kuten hinnasta, suorituskyvystä, luotettavuudesta jne.

Vain asiakkaasi voi kertoa sinulle laadusta, koska tämä on ainoa asia, jota hän todella ostaa. Asiakas ei osta tuotetta. Hän ostaa takuusi siitä, että kaikki hänen tuotetta koskevat odotuksensa täyttyvät.

Guaspari "Tiedän sen, kun näen sen"

johtopäätöksiä

Yritetään uudelleen määritellä laatu tuotteen asiakkaan tai käyttäjän näkökulmasta.

Laatu on käyttökelpoista. Tekeekö tämä tuote mitä tarvitsen, helpottaako se työtäni, voinko käyttää sitä minulle sopivalla tavalla.

Katsotaanpa nyt kehittäjän näkökulmaa.

Laatu on määriteltyjen ja kerättyjen vaatimusten noudattamista Tekeekö tuote kaiken sen mitä sen pitää?

Ongelmana on, että määritellyt ja kerätyt vaatimukset ovat yleensä vain osa asiakkaan todellisista vaatimuksista ja odotuksista. Missä on oikea laadun määritelmä?

Laatu on todellisten vaatimusten noudattamista, eksplisiittisiä ja implisiittisiä. Hyvin usein implisiittiset vaatimukset ovat asiakkaalle tai käyttäjälle niin ilmeisiä, että hän ei edes oleta, että ne ovat kehittäjille tuntemattomia. Palataanpa esimerkiksi autoihimme - asiakas voi kuvailla yksityiskohtaisesti vaatimukset suunnittelulle, moottorin parametreille, sisustukselle, korin värille, mutta ei missään osoita, että renkaiden tulee olla pyöreitä ja tuulilasin läpinäkyvä.

Asiakas on tyytyväinen vain, kun ostettu tuote täyttää täysin hänen todelliset ja elintärkeät vaatimukset riippumatta siitä, onko se määritelty tai ei.

Menetelmät Liittyvät tieteenalat

Ohjelmiston laatu- ohjelmiston (ohjelmiston) ominaisuudet sen vaatimustenmukaisuuden asteena. Samanaikaisesti vaatimuksia voidaan tulkita varsin laajasti, mikä synnyttää useita itsenäisiä käsitteen määritelmiä. Yleisimmin käytetty määritelmä on ISO 9001, jonka mukaan laatu on "aste, missä määrin luontaiset ominaisuudet vastaavat vaatimuksia".

Lähdekoodin laatu

Koodin laatu voidaan määrittää useilla kriteereillä. Jotkut niistä ovat merkityksellisiä vain ihmisen näkökulmasta. Esimerkiksi ohjelman tekstin muotoilulla ei ole tietokoneelle mitään merkitystä, mutta sillä voi olla vakavia seurauksia myöhempään ylläpitoon. Monet olemassa olevat koodausstandardit, jotka määrittelevät kielikohtaisia ​​käytäntöjä ja asettavat useita koodin luettavuutta parantavia sääntöjä, on tarkoitettu helpottamaan tulevaa ohjelmiston ylläpitoa, mukaan lukien virheenkorjaus ja päivitys. On olemassa muita kriteerejä, jotka määrittävät, onko koodi "hyvin" kirjoitettu, kuten esimerkiksi strukturointi - missä määrin koodi on loogisesti jaettu useisiin hallittaviin lohkoihin.

• Koodin luettavuus
• Helppo tuki, testaus, virheenkorjaus, virheenkorjaus, muokkaus ja siirrettävyys
• Matala koodin monimutkaisuus
• Vähäinen resurssien käyttö: muisti ja suorittimen aika
• Oikea poikkeuskäsittely
• Muutamia varoituksia kokoamisen ja linkittämisen aikana

Menetelmät koodin laadun parantamiseksi: uudelleenfaktorointi.

Laatutekijät

Ohjelmiston laatutekijä on ohjelman ei-toiminnallinen vaatimus, jota ei yleensä ole kuvattu asiakkaan kanssa tehdyssä sopimuksessa, mutta joka on kuitenkin toivottava vaatimus, joka parantaa ohjelman laatua.

Jotkut laatutekijöistä ovat:

Ymmärrettävyys Ohjelmiston tarkoituksen tulee olla selvää itse ohjelmasta ja dokumentaatiosta. Täydellisyys Ohjelman kaikki tarvittavat osat on esitettävä ja pantava kokonaan täytäntöön. lyhyys Tarpeettoman, päällekkäisen tiedon puuttuminen. Toistuvat koodin osat tulee muuntaa yhteiseksi proseduurikutsuksi. Sama koskee dokumentaatiota. siirrettävyys Ohjelman helppo mukauttaa toiseen ympäristöön: toiseen arkkitehtuuriin, alustaan, käyttöjärjestelmään tai sen versioon. Johdonmukaisuus Samoja käytäntöjä, muotoja ja merkintöjä on käytettävä koko ohjelmassa ja dokumentaatiossa. ylläpidettävyys Kuinka vaikeaa on muuttaa ohjelmaa vastaamaan uusia vaatimuksia. Tämä vaatimus määrittelee myös, että ohjelman tulee olla hyvin dokumentoitu, ei liian hämmentävä ja resurssien käytössä (muisti, prosessori) on oltava kasvua. testattavuus Onko ohjelman avulla mahdollista tarkistaa hyväksyntäominaisuudet, tuetaanko suorituskyvyn mittauskykyä. helppokäyttöisyys Ohjelman yksinkertaisuus ja helppokäyttöisyys. Tämä vaatimus koskee ensisijaisesti käyttöliittymää. luotettavuus, vikojen ja epäonnistumisten puuttuminen ohjelmien toiminnassa sekä vikojen ja virheiden korjaamisen helppous: strukturoitu tehokkuus Kuinka järkevästi ohjelma kohtelee resursseja (muisti, prosessori) tehtäviään suorittaessaan. turvallisuutta

Käyttäjän näkökulmasta

Ohjelmiston laadun teknisen näkemyksen lisäksi on myös laadun arviointia käyttäjän näkökulmasta. Termiä "käytettävyys" käytetään joskus tästä laadun näkökulmasta. Tietylle ohjelmistotuotteelle on melko vaikeaa saada käytettävyysluokitusta. Tärkeimmät arviointiin vaikuttavat asiat:

• Onko käyttöliittymä intuitiivinen?
• Kuinka helppoa on suorittaa yksinkertaisia, toistuvia toimintoja?
• Kuinka helppoja monimutkaisia ​​operaatioita on suorittaa?
• Tuottaako ohjelma selkeitä virheilmoituksia?
• Toimiiko ohjelma aina odotetulla tavalla?
• Onko dokumentaatiota ja kuinka kattava se on?
• Onko käyttöliittymä itsekuvaava/itsedokumentoiva?
• Ovatko ohjelman vastausviiveet aina hyväksyttäviä?

Katso myös

Linkit

Kuuluisa lukuja
Käsitellä asiaa
Käsitteet
Ohjeet
Mallit kehitystä
Muut mallit
muu

Wikimedia Foundation. 2010.

• NLite
• Keskiyö hautausmaalla (elokuva)

Katso, mitä "ohjelmiston laatu" tarkoittaa muissa sanakirjoissa:

Ohjelmiston laatu- ohjelmistotuotteen kyky validoida spesifikaationsa edellyttäen, että spesifikaatiossa keskitytään käyttäjän toivomiin ominaisuuksiin. Katso myös: Ohjelmiston laatu Ohjelmistotaloudellinen… … Taloussanakirja

Ohjelmistokehitys- Grace Hopperin työskennellessä Harvard Mark II -tietokoneen parissa Harvardin yliopistossa, hänen kollegansa löysivät tämän koin juuttuneen releeseen ja siten häiritsevän laitteen toimintaa, minkä jälkeen hän totesi, että he "korjasivat" järjestelmää.... . .. Wikipedia

Ohjelmistojen testaus- Ohjelmistokehitys Ohjelmistojen kehitysprosessi Prosessin vaiheet Analyysi Suunnittelu Ohjelmointiasiakirja ... Wikipedia

Ohjelmiston valmistaja- Ohjelmistokehitys (eng. ohjelmistosuunnittelu, ohjelmistokehitys) on eräänlainen toiminta (ammatti) ja prosessi, jonka tarkoituksena on luoda ja ylläpitää ohjelmistojen toimivuutta, laatua ja luotettavuutta... Wikipedia

Ohjelmistokriisi- "Ohjelmistokriisi" on aikoinaan tietojenkäsittelytieteessä käytetty termi kuvaamaan tietokoneiden laskentatehon nopean kasvun seurauksia ja niiden avulla ratkaistavien ongelmien monimutkaisuutta. Pohjimmiltaan tämä on... ... Wikipedia

Ohjelmistotuotanto- Uusi Airbus A 380 käyttää melko paljon ohjelmistoja modernin ohjaamon luomiseksi koneeseen. Ohjelmistosuunnittelumenetelmä mahdollisti miljoonilla riveillä kuvatun lentokoneohjelmiston luomisen... Wikipedia

Ohjelmiston liikkuvuus- ohjelmiston kyky toimia eri laitteistoalustoilla tai eri käyttöjärjestelmissä. Synonyymit: Ohjelmiston siirrettävyys Katso myös: Ohjelmiston laatu Avoimet järjestelmät... ... Taloussanakirja

Ohjelmiston käyttäjäystävällisyys- ohjelmistotuotteen ominaisuudet, jotka: mahdollistavat käyttäjien ponnistelujen minimoimisen alkutietojen valmistelussa, ohjelmistotuotteen käyttämisessä ja saatujen tulosten arvioinnissa sekä mahdollistavat positiivisten tunteiden herättämisen... ... Taloussanakirja

Ohjelmiston ylläpidettävyys- ohjelmistotuotteen ominaisuudet, jotka mahdollistavat sen muutosten minimoimisen: virheiden poistaminen; tai muutetaan käyttäjien muuttuvien tarpeiden mukaan. Katso myös: Ohjelmiston laatu... ... Taloussanakirja

Ohjelmiston toiminnallisuus- ohjelmistotuotteen kyky suorittaa joukko toimintoja: määritelty sen ulkoisessa kuvauksessa; ja käyttäjien määriteltyjen tai oletettujen tarpeiden tyydyttäminen. Synonyymit: Ohjelmistojen yhteentoimivuus Katso myös: Laatu... ... Taloussanakirja

Kirjat

• Code Perfect: A Practical Guide to Software Development, kirjoittanut S. McConnell Yli 10 vuoden ajan tämän kirjan ensimmäistä painosta on pidetty yhtenä parhaista käytännön ohjelmointioppaista. Nyt tämä kirja on päivitetty täysin nykyaikaiset trendit ja teknologiat huomioiden...

Ohjelmiston laatua koskevat lähestymistavat

Luokitetaan erilaisia ​​lähestymistapoja ohjelmistojen laatuun käyttämällä kahta ulottuvuutta.

Ensimmäinen ulottuvuus on joko tuote- tai prosessisuuntautunut. Ohjelmiston laadun parantamiseksi voit keskittyä esimerkiksi itse tuotteen laatuun, jolloin siitä tulee käyttäjäystävällisempi. Vaihtoehtoinen lähestymistapa on parantaa kehitysprosessia olettaen, että mitä parempi prosessi, sitä parempi ohjelmiston laatu.

Toinen ulottuvuus liittyy joko vaatimustenmukaisuuteen tai parantamiseen. Noudatuksella tarkoitamme minkä tahansa standardin noudattamista. Parannuksella pyritään siirtymään parempiin menetelmiin ja parempiin käytäntöihin laadun parantamiseksi.

ISO 9126 on tuotteen laatustandardi, joka määrittelee laatuattribuutit ja -ominaisuudet, mukaan lukien mittaukset näiden ominaisuuksien määrittämiseksi.

"parannettu käytäntö" on esimerkiksi parannettu ohjelmiston konfiguroinnin hallinta, tarkastus, testaus jne.;

ISO 9000 on joukko standardeja, jotka määrittelevät laatujärjestelmien vaatimukset. Ohjelmistokehityksen näkökulmasta hyödyllisimpiä ovat Ohjeet ISO 9001:n soveltamiseksi ohjelmistojen kehittämisessä, toimittamisessa ja ylläpidossa;

Ohjelmistokehitysprosessin parantamismenetelmät tarjoavat asteikon tasoista jaa, joiden mukaan tietokoneyritys voidaan sijoittaa tälle asteikolle. Kaksi tunnetuinta ja suosituinta menetelmää ovat:

ohjelmistokehitysprosessin kypsyysmalli – Software Engineering Instituten (SEI) ehdottama Capability Maturity Model for Software (CMM);

mahdollisuuksien tunnistaminen ja ohjelmistojen luontiprosessin parantaminen. ISO/IEC 15504 Software Process Improvement and Capability Determination (SPICE).

Laadun saavuttamisen taustalla on kaksi kriittistä lausuntoa.

• Laatu alkaa kehittäjien tarpeiden täyttämisestä.
• Laadun todistaa käyttäjien tarpeiden tyydyttäminen.

Lähestymistavat laadun saavuttamiseksi ovat:

• laatu saavutetaan pätevien kehittäjien, prosessien tiukan noudattamisen ja onnistuneiden teknologisten lähestymistapojen avulla;
• laatu saavutetaan ymmärtämällä täysin kaikki toimet ja muutokset. Ohjelmassa ei saa lisätä tai muuttaa yhtään riviä ilman täydellistä ymmärrystä siitä, mitä, miksi ja miten se tehdään;
• laatu saavutetaan testaamalla ohjelma perusteellisesti ennen kuin se asetetaan käyttäjän saataville;
• laadun saavuttaminen on suunniteltava;
• Laadun saavuttaminen on jokaisen kehittäjän vastuulla.

Ohjelmiston laatuominaisuudet

Tällä hetkellä ohjelmiston laadulle ei ole yleisesti hyväksyttyjä kriteerejä.

Standardin ISO 9000-3 kohta 6.4.1

Klassinen laadun määritelmä on, että kehitetty ohjelmistotuote vahvistaa spesifikaationsa ja määrittelyn tulee olla suunnattu asiakkaan toivomiin ominaisuuksiin.

Nykyaikaiset standardit selventävät laadun käsitettä ottamalla käyttöön joukon ominaisuuksia ja ominaisuuksia, jotka vaikuttavat sen kykyyn täyttää tiettyjä käyttäjien tarpeita. Listataan joukko sellaisia ​​ominaisuuksia [Zhogolev 1996].

Toimivuus (soveltuvuus, tarkkuus, yhteentoimivuus, johdonmukaisuus, turvallisuus). Toiminnallisuus on ohjelmistotuotteen kykyä suorittaa joukko toimintoja, jotka täyttävät käyttäjien tietyt tai oletetut tarpeet. Tällaisten toimintojen joukko on määritelty ohjelmistotuotteen ulkoisessa kuvauksessa.

Luotettavuus (täydellisyys, vakaus, talteentettavuus).

Mukavuus (ymmärrettävyys, helppokäyttöisyys, ergonomia). Mukavuus on ohjelmistotuotteen ominaisuus, jonka avulla voidaan minimoida käyttäjän ponnistelut alkutietojen valmistelussa, ohjelmistotuotteen käyttämisessä ja saatujen tulosten arvioinnissa sekä herättää positiivisia tunteita tietyssä tai implisiittisessä käyttäjässä.

Tehokkuus (ajan ja resurssien suhteen). Tehokkuus on ohjelmistotuotteen käyttäjälle tietyissä olosuhteissa tarjoamien palveluiden tason suhde käytettyjen resurssien määrään.

Ylläpidettävyys (analyysin helppous, muunnettavuus, vakaus, todennettavuus). Ylläpidettävyys on ohjelmistotuotteen ominaisuuksia, jotka minimoivat muutosten tekemiseen tarvittavat vaivat virheiden poistamiseksi ja muokkaamiseksi käyttäjien muuttuvien tarpeiden mukaisesti.

Siirrettävyys (mukautettavuus, asennuksen joustavuus, yhdenmukaisuus standardien ja sääntöjen kanssa, vaihdettavuus). Siirrettävyys tarkoittaa ohjelmistotuotteen kykyä siirtää ympäristöstä toiseen, erityisesti laitteistoarkkitehtuurista toiseen.

Hyvä laatu (rationaalinen organisointi, huomaavaisuus). Tarkastellaanpa tarkemmin kahta mielenkiintoisinta ominaisuutta.

Luotettavuus on ohjelman kykyä suorittaa tiettyjä toimintoja ilman vikaa tietyissä olosuhteissa tietyn ajanjakson ajan riittävän suurella todennäköisyydellä. Luotettava ohjelmistotuote ei sulje pois virheiden esiintymistä siinä. Tässä on tärkeää, että virheitä käytännön soveltamisessa tietyissä olosuhteissa tapahtuu melko harvoin. Luotettavuusasteelle on ominaista todennäköisyys, että ohjelmistotuote toimii ilman vikaa tietyn ajan.

Seuraavat lähestymistavat luotettavuuden varmistamiseksi ovat olemassa:

• virheiden ehkäisy;
• virheiden itsetunnistus;
• virheiden itsekorjaus;
• varmistaa virhetoleranssin.

Ohjelman hyvä puoli on siinä, että ohjelma on järkevästi ja rationaalisesti organisoitu, ohjausvirtojen ja tietovirtojen organisointi on varsin harkittu, eikä se ole liian monimutkainen. Laatutekijän käsitteen otti käyttöön Pottosin [Pottosin 1997] arvioidakseen ohjelman toteutuksen sisäisiä etuja tekniseltä puolelta. Pottosin esittelee ohjelmille neljä laatukriteeriluokkaa.

Ohjelmien monimutkaisuuden arviointimenetelmiin liittyvät määrälliset kriteerit. Otetaan esimerkkejä numeerisista ominaisuuksista.

Halstead mittaa [Halstead 1981], joka sisältää sarjan kaavoja, jotka arvioivat ohjelmien pituutta, määrää, tasoa ja henkistä sisältöä.

Ohjelman ohjauskaavion monimutkaisuuden arviointi. Ohjelman fragmentti voidaan arvioida sen ohjausgraafin syklomaattisella numerolla, joka on yhtä kuin m - n + 2, missä m on kaarien lukumäärä, an on ohjausgraafin kärkien lukumäärä. Uskotaan, että syklomaattinen luku ei saa ylittää 10:tä.

Ohjelman modularisoinnin arviointi. Tällaisen arvioinnin tulisi koostua useista kriteereistä. Esimerkiksi moduulin monimutkaisuus arvioidaan siinä määriteltyjen prosessien monimutkaisuuden kokonaisuuden ja moduulin yhteyksien monimutkaisuuden perusteella muiden määritettyjen entiteettien tuontia ja vientiä varten.

Ohjelman alkuperään ja sen luomisen kurinalaisuuteen liittyvät geneettiset kriteerit.

Rakenteelliset kriteerit, jotka liittyvät johtamisorganisaation arviointiin ohjelmassa ja johtamisorganisaation heijastukseen ohjelmatekstissä.

Pragmaattiset kriteerit, jotka liittyvät sen arvioimiseen, missä määrin ohjelman teksti vastaa ohjelman tarkoitusta. Laaditaan luettelo ylilyönneistä, joita ei pitäisi olla hyvissä ohjelmissa, esimerkiksi laskennallinen redundanssi.

Kehitysprosessin laadun arviointi

Samalla ohjelmalla vaaditaan sekä tehokkuutta että joustavuutta

se on kuin etsisi viehättävää ja vaatimatonta vaimoa.

Ilmeisesti meidän pitäisi pysähtyä yhteen kahdesta asiasta.

D. Weinberg

Tämän osan alussa totesimme, että ohjelmistotuotteen laadun arvioinnissa voidaan käyttää kahta lähestymistapaa.

• Arvioi lopputuotteen laatu.
• Arvioi kehitysprosessin laatu.

Lopputuotteen laatua voidaan arvioida testaamalla ja käyttämällä. Aikaa tähän tulisi varata ohjelman päätyön jälkeen. Mutta toisesta lähestymistavasta pitäisi tulla osa yrityksen pitkän aikavälin strategiaa.

Ohjelmistokehitysprosessin kypsyysmalli

Malli määrittelee viisi organisaation kypsyystasoa (http://www.sei.cmu.edu/cmm).

Ensimmäinen taso. Tällä tasolla kehitysprosessille on ominaista johtamisprosessien virtuaalinen puuttuminen. Projektin onnistuminen riippuu projektiin osallistujien yksilöllisistä ponnisteluista, henkilökohtaisista ominaisuuksista ja jopa sankaruudesta.

Toistettava taso. Tällä kypsyysasteella yrityksellä tulisi olla ydinjohtamisprosessit, joilla seurataan projektin kustannuksia, aikataulua ja toimivuutta. Tasolle on ominaista se, että projektinhallinta perustuu kertyneeseen kokemukseen ja aiemmin saavutetut onnistumiset toistuvat vastaavissa sovelluksissa.

Tietty taso. Ohjelmistokehitysprosessi (sekä johdon että suunnittelun tasolla) on dokumentoitu, standardoitu ja integroitu koko organisaatioon. Prosessi lakkaa olemasta riippuvainen yksittäisten kehittäjien yksilöllisistä ominaisuuksista, eikä se voi liukua alemmalle tasolle kriisitilanteissa.

Hallittu taso. Yritys asettaa yksityiskohtaiset määrälliset indikaattorit kehitysprosessille ja tuotteiden laadulle. Sekä kehitysprosessi että tuotteet ovat ymmärrettäviä ja hallittavissa.

Optimointitaso. Kehitysprosessin jatkuva parantaminen perustuen nykyisten prosessitulosten analysointiin ja innovatiivisten ideoiden ja teknologioiden soveltamiseen.

Mahdollisuuksien tunnistaminen ja ohjelmiston luomisprosessin parantaminen

Tämä malli on hyvin lähellä kypsyysmallia, mutta kykytasoja voidaan soveltaa organisaation kokonaisuuden lisäksi myös yksittäisiin prosesseihin. Tämän tyyppisiä malleja kutsutaan usein jatkuviksi. Jatkuvissa malleissa yksi prosessi voi olla matalalla ja toinen korkealla maturiteettitasolla. Standardi määrittelee kuusi prosessin kypsyysastetta.

Taso 0: Prosessi ei ole käynnissä.

Taso 1. Suoritusprosessi.

Taso 2. Hallittu prosessi.

Taso 3. Vakiintunut prosessi.

Taso 4: Ennustettava prosessi.

Taso 5. Optimointiprosessi.

Prosessien laatua arvioitaessa ja parantaessa suoritetaan alla kuvatut tehtävät [Terehov, Tuñon 1999].

Tietyssä organisaatiossa olevan ohjelmistokehitysprosessin vertailu standardissa kuvattuun malliin. Tulosten analysoinnin avulla voidaan määrittää prosessin vahvuudet ja heikkoudet, sen sisäiset riskit.

Tietyn prosessin parantamismahdollisuuksien arvioiminen nykyisten valmiuksien tunnistamisen perusteella.

Annettujen tehtävien tekninen toteutus perustuen muotoiltuihin prosessin parantamistavoitteisiin. Tämän jälkeen koko työkierto alkaa alusta.

Puolustusministeriön roolista

Huomaa, että historiallisesti kehitysprosessin laadun arvioinnin malleja on luotu tavoitteena saada järkevät menettelytavat teknisten prosessien arviointiin ja myöhempään kehittämiseen niissä organisaatioissa, jotka hakevat tilauksia puolustuksen kannalta merkittävien hankkeiden kehittämiseen. Mallit soveltuvat monimutkaisia ​​ja reaaliaikaisia ​​järjestelmiä kehittäviin yrityksiin. Nämä ovat järjestelmiä, joilla on pitkät elinkaariajat ja joissa ohjelmistovirheet voivat olla kriittisiä.

"Tarpeeksi hyvä" ohjelmisto

Eilen Seattlessa sen jälkeen, kun Bill Gates mainitsi beta-version julkaisemisen

Microsoftin uusi ohjelma kärsi maanjäristys.

Käyttäjät odottavat kauhuissaan ilmoitusta tuotteen lopullisen version julkaisusta.

"Tarpeeksi hyvän" ohjelmiston promoottori on Edward Yordon [Yordon 2001]. Korostamme, että hän soveltaa tätä käsitettä "kadonneisiin hankkeisiin", joita sitovat tiukat aika-, budjetti- ja henkilöresurssit (katso kohta 1.6). Useimmissa toivottomissa projekteissa asiakas voi tyytyä järjestelmään, joka on riittävän halpa, riittävän suorituskykyinen, jolla on tarvittavat ominaisuudet, riittävän vankka ja pian valmis. Itse asiassa näitä ominaisuuksia voidaan pitää "riittävän hyvän" ohjelmiston määritelmänä.

Osoittautuu, että jopa "riittävän hyvää" ohjelmistoa on vaikea luoda. Esitetään joitakin syitä, jotka selittävät tämän [Yordon 2001].

Usein he yrittävät määritellä laadun vain vikojen (virheiden) perusteella. Käyttäjän näkökulmasta esimerkiksi valmius tiettyyn päivämäärään eivät ole yhtä tärkeitä.

Oletuksena on, että vähemmän virheitä tarkoittaa parempaa laatua, ja käyttäjä suosii tätä laatua. Joskus käyttäjä on kuitenkin valmis tekemään kompromisseja ja hyväksymään joitakin virheitä vastineeksi saadakseen työn valmiiksi nopeammin.

Jätetään huomioimatta tekijät, kuten kehitystiimin moraali ja riittävät työolosuhteet.

James Bach huomauttaa seuraavat välttämättömät ehdot "riittävän hyvän" ohjelmiston luomiseksi:

• utilitaristinen strategia - kvantitatiivisen analyysin taito ja nettohyödyn maksimointi epävarmoissa tilanteissa;
• evoluutiostrategia - ei huomioida pelkästään projektin elinkaaren, vaan myös ihmisten, prosessien ja resurssien suhteen;
• sankarilliset tiimit eivät ole vahvoja loistavia ohjelmoijia, vaan tavallisia taitavia asiantuntijoita, jotka kykenevät tehokkaaseen yhteistyöhön;
• dynaaminen infrastruktuuri on byrokratian ja politiikan dominanssin vastakohta;
• dynaamiset prosessit - prosessit, jotka tukevat työtä evoluutionaarisessa ympäristössä.

Valitettavasti "riittävän hyvä" ohjelmisto on harvoin todella tarpeeksi hyvä. Niklaus Wirth huomauttaa, että tämä on "seuraus aikamme hengen surullisesta ilmenemisestä, jossa henkilökohtainen ylpeys työstään katoaa". Hänen mukaansa "ei voi odottaa laadukasta työtä, jos ei anna itseään sille täysin, jos siitä ei ole henkilökohtaista tyytyväisyyttä, lisäksi nautintoa."

Monet ohjelmoijat ovat tehneet mielenkiintoisen havainnon, että jotkut yritykset pyrkivät alentamaan tuotteidensa käyttäjien älyllistä tasoa. Yrityksille on erittäin hyödyllistä olla tekemisissä ihmisten kanssa, joiden tekninen pätevyys ei anna heidän määrittää ohjelmistotuotteen todellisia puolia (esimerkiksi laatua, monimutkaisuutta, arvoa). Työn "yksinkertaistamisen" ja tietokoneiden helpottamista käyttäjille tarkoitetun varjolla yritykset ylikuormittavat ja monimutkaistavat ohjelmistoja toistuvasti siten, että käyttäjän on äärimmäisen vaikea ymmärtää, miten se todella toimii, ja tulla ammattilaiseksi.

Tietotekniikan standardointi

Standardi on yleisesti hyväksytty määritelmä sopimuksesta johtuvalle laitteiston tai ohjelmiston osalle. Profiili on joukko oikeudellisia ja/tai tosiasiallisia standardeja, jotka keskittyvät tietyn tehtävän suorittamiseen [Kozlov 1999].

Standardit voidaan luokitella seuraavasti:

• vaatimusten määrittämisen tyypin mukaan:
• vaatimusten asettaminen esineelle;
• prosessivaatimusten määrittäminen;
• mittakaavan mukaan:
• kansainvälinen;
• hallitus;
• ala;
• yritykset;
• laillisen rekisteröinnin asteen mukaan:
• hyväksytty laillisesti;
• todella toimiva.

Tietotekniikan standardointiprosessia tukee kolme pääorganisaatioryhmää. Kansainväliset järjestöt, jotka ovat YK:n jäseniä. International Organization for Standardization (ISO) on kansainvälinen standardointijärjestö.

Tietoja ISO:sta

Vuonna 1947 25 maan edustajat päättivät perustaa organisaation, jonka päätehtävänä olisi koordinoida kehitystä ja yhtenäistää kansainvälisiä standardeja. Uusi organisaatio sai nimekseen International Organization for Standardization (ISO). Koko nimen ja lyhenteen välinen ristiriita selittyy sillä, että "ISO" on kreikkalainen etuliite, joka tarkoittaa "yhtä".

International Electrotechnical Commission (IEC) - kansainvälinen sähkötekninen komissio.

International Telecommunication Union-Telecommunications (ITU-T) - kansainvälinen televiestintäliitto - televiestintä. Vuoteen 1993 asti tätä järjestöä kutsuttiin Kansainväliseksi telegraph and Telephone Consultative Committeeksi - puhelintoiminnan ja lennätyksen kansainväliseksi neuvoa-antavaksi komiteaksi.

Teollisuuden ammatti- tai hallintoorganisaatiot.

Institute of Electrical and Electronics Engineers (IEEE) – Institute of Electrical and Electronics Engineers.

Internet Activity Board (IAB) on Internet-toimintaa hallitseva lautakunta.

Teollisuuskonsortiot.

Object Management Group (OMG) - objektien hallintaryhmä.

X/Open on tietokonelaitteiden toimittajien ryhmän järjestämä konsortio.

Open Software Foundation (OSF) on avoin ohjelmistosäätiö.

Vuonna 1987 ISO ja IEC yhdistivät toimintansa tietotekniikan standardoinnin alalla ja loivat yhden elimen - Joint Technical Committee 1 (JTC1) -komitean tarkoituksena on muodostaa tietotekniikan perusstandardijärjestelmä.