Sissejuhatus

Kaasaegsete keeruliste süsteemide kõige olulisem osa on tarkvaratooted – intellektuaalne komponent. Tarkvaratooteid kasutatakse nüüd juhtimisprobleemide lahendamiseks peaaegu kõigis inimtegevuse valdkondades: majanduses, sotsiaal-, sõjalistes ja muudes valdkondades. Turvalisus Kõrge kvaliteet kodumaised tarkvaratooted oma massiline areng ja tarnimine erinevatele rakendustele riigis ja maailmaturul on muutunud strateegiliseks eesmärgiks.

Praegu on tarkvaratehnikas ja tarkvaratoodete kvaliteedi tagamises kaks peaaegu sõltumatut standardimisvaldkonda, mida võib tinglikult nimetada ISO (International Standards Organisation) standardite profiilideks ja SEI (US Software Engineering Institute) küpsusmudeliteks. Esimesed on üsna täielikult esindatud [ , ]-s ja teised - [ , ]-s. Artikli põhisisu on pühendatud küpsusmudelitele.

Et tagada konkurentsivõime komplekssete tarkvaratoodete maailmas ja nende eduka ekspordi võimalus, peavad need olema välja töötatud ja sertifitseeritud vastavalt nõuetele rahvusvaheliste standardite profiilid alusel ISO 9000:2000 või küpsusmudelid - CMMI: 2003(Capability Maturity Model Integration – integreeritud tarkvaratehnoloogia küpsuse hindamise mudel). Need kaks suunda on metodoloogiliselt väga lähedased ja ristuvad osaliselt vastastikuste viidete kaudu.

Tarkvaratoodete tehniliste ja majanduslike näitajate ja kvaliteedi paranemine ning vigade ja defektide vältimine on tagatud programmide kasutamisega. kaasaegsed tehnoloogiad tarkvaratehnika ja süsteemid arvutipõhine disain. Need on suure jõudlusega, ressursse säästvad tehnoloogiad kvaliteetse, töökindluse ja turvalisusega tarkvarakomplekside loomiseks, mille eesmärk on vähendada tarkvaratööriistade (PS) projekteerimise, juurutamise ja hooldamise ressursside kogumaksumust. Selleks on vaja ennekõike rakendada analüüsi ja disaini meetodeid ja tööriistu, tagades algusest peale konkretiseerimise ning eesmärkide, eesmärkide ja funktsioonide võimalikult täpse esituse. eluring(LC) PS-i ja vältida võimalike süsteemidefektide levikut järgmistesse arendusfaasidesse. Sellised tarkvaratehnoloogia tehnoloogiad võimaldavad kõrvaldada või oluliselt vähendada süsteemi-, algoritmi- ja tarkvaravigade taset käitamiseks üleantud tarkvaratoodetes. Lisaks on need tõhusad PS-i muutmisel ja hooldamisel, samuti väliskeskkonna muutustel.

Keeruliste, kriitiliste süsteemide kasutamise kvaliteedi, töökindluse ja ohutuse tõendamiseks allutatakse neis kasutatavatele tarkvaratoodetele sertifitseerimine sertifitseeritud probleemidele orienteeritud katsekeskused või laborid. Sellised testid tuleks läbi viia, kui programmid haldavad keerulisi, kriitilisi protsesse või töötlevad nii olulist teavet, et nende defektid või ebapiisav kvaliteet võivad põhjustada olulist kahju. Sertifitseerimistestid peaksid tuvastama tarkvarakomplekside vastavuse dokumentatsiooni nõuetele ja võimaldama neil töötada testide käigus uuritud väliskeskkonna parameetrite muutumise piires. Seda tüüpi teste iseloomustab kontrollide suurim raskusaste ja sügavus ning need peaksid läbi viima arendajatest ja klientidest (kasutajatest) sõltumatud spetsialistid.

Sertifitseerimise aluseks peaksid olema üksikasjalikud ja tõhusad programmid ja meetodid tarkvarapakettide testimiseks standardiseeritud kliendinõuetele vastavuse tagamiseks, spetsiaalselt loodud testimisprobleemid ja generaatorid nende kujundamiseks, samuti testijate kõrge kvalifikatsioon ja autoriteet. Rakendus ettevõtetes-tarkvaratoodete arendajates, sertifitseeritud kvaliteedisüsteemid PS elutsükli tagamiseks vastavalt nõuetele ISO 9000:2000 või CMMI: 2003, tagab nende elutsükli protsesside ja toodete kõrge jätkusuutliku kvaliteedijuhtimise ning võimaldab paljudel juhtudel hõlbustada ka lõpliku tarkvaratoote sertifitseerimist. Seetõttu kipuvad keerukate tarkvaraprojektide kliendid valima rakendavaid töövõtjaid, kellel on kohandatud rahvusvaheliste standardite profiilidel või küpsusmudelitel põhinevate kvaliteeditagamissüsteemide rakendamist tõendavad sertifikaadid.

Tarkvaratehnika meetodite õpetamise lüngad jätavad laia välja nii spetsialistide omavolile oma töö kvaliteedi hindamisel kui ka arvukate defektide ja vigade ilmnemisele tarkvaraprojektides. Programmidega lahendatavate kaasaegsete ülesannete kasvav keerukus ja vastutustunne, samuti nende tulemuste ebapiisava kvaliteedi tõttu tekkiv võimalik kahju on oluliselt suurendanud meetodite valdamise olulisust kvaliteedinäitajate nõuete ja mõõtmismeetodite täielikuks, standardseks kirjeldamiseks. nende tegelikud, saavutatud väärtused tarkvara elutsükli erinevatel etappidel. Järsult on kasvanud spetsialistide vajadus tarkvaratoodete kvaliteedi tunnuste hindamise mõistete, definitsioonide ja meetodite tundmise järele.

Tarkvarakomplekside kiire kasv ja komplitseerimine toob kaasa professionaalse tööjaotusega suurte programmeerimismeeskondade loomise, milles on vaja reguleerida spetsialistide rühmade koordineeritud tegevust ühe projektiga. Sageli ei täideta arendajate lepingutes antud lubadusi tarnida kokkulepitud aja jooksul kvaliteetne tarkvara. Sageli juhtub see seetõttu, et tellija ja töövõtja hindavad kvaliteeditaset erinevate kriteeriumide alusel ning neil puudub selles küsimuses üksmeel ning programmide kvaliteedi hindamise lähenemine ei ole piisavalt vormistatud. Lisaks puudub mõnikord võimekus korralikult hinnata kvaliteetsete programmide saavutamiseks vajalikke ressursse. Seetõttu jääb tarkvaratoodete kvaliteet rahvusvahelisel turul sageli madalaks, ebausaldusväärseks ja konkurentsivõimetuks. Seetõttu on paljude väljatöötamisel ja rakendamisel kõige olulisem probleem kaasaegsed süsteemid on tarkvaratehnika valdkonna spetsialistide koolitamine ja koolitamine, tarkvara kõrgele kvaliteedile kaasaaitavate rahvusvaheliste standardite kasutamine ja selle usaldusväärne hindamine põhieesmärgiga - teha projektiprotsesse juhitav, ja tulemused on etteaimatav. Vaja on suutma vormistada nõudeid ja saavutada keerukate tarkvarapakettide toimimise ja rakendamise kvaliteedi omaduste spetsiifilised väärtused, võttes arvesse selle kvaliteedi tagamiseks ja parandamiseks olemasolevaid ressursse.

CMMI küpsusmudel – 1.1 täiustab ja täiustab eelmisi mudeleid CMM(vt ), ning võtab osaliselt arvesse ka olemasolevate rahvusvaheliste standardite põhinõudeid tarkvarahalduse valdkonnas. Märkimisväärne tähelepanu sisse CMMI on antud arendusprotsessidele ja iteratsioonide arvestamisele kliendi nõuete muutumisel, nende jälgitavusele funktsioonidele, komponentidele, testidele ja projektidokumentidele. Hiljuti on ilmunud teave 2003. aasta versiooni SEI versiooni moderniseerimise kohta. CMMI-1.1 kogutud kogemuste ja ettevõtete tagasiside põhjal. See peaks 2006. aastal välja laskma mudeli uue, oluliselt täiustatud versiooni CMMI-1.2, mille järel tuleks versioon 1.1 järk-järgult kasutusest kõrvaldada. Kuni 2007. aasta lõpuni peaksid kasutajad versioonile üle minema CMMI-1.2, ja edaspidi muutub see kohustuslikuks tarkvaratehnika valdkonna ettevõttetehnoloogia kvaliteedi (sertifitseerimise) ametlikul hindamisel. Sertifikaadi kehtivusaeg on piiratud kolme aastaga. Suurte tarkvarasüsteemide kliendid ja arendajad peaksid nendeks muudatusteks valmistuma enne, kui SEI avaldab ametlikult versiooni 1.2.

CMMI küpsusmudeli ülesehitus ja sisu - 1.1

Kaks mudelivalikut CMMI-1.1 mõeldud pakkuma pidev protsesside kompleksi hindamine sisse teatud piirkond tarkvara loomine või etapiviisiline ettevõtte küpsuse hindamiseks ja parandamiseks, samuti programmikomplekside elutsükli korraldamiseks üldiselt. Mudelid CMMI abistada spetsialiste nende toodete organiseerimisel ja täiustamisel, samuti PS arendamise ja hooldamise protsesside tõhustamisel ja teenindamisel. Nende mudelite kontseptsioon hõlmab keeruliste süsteemide küpsuse juhtimist ja hindamist, tarkvaratehnikat, aga ka integreeritud tarkvaratoodete loomise ja nende arendamise täiustamise protsesse. Pideva ja etapiviisilise mudeli komponendid on suures osas sarnased ning neid saab valida ja rakendada erineva koostise ja kasutusjärjestusena, olenevalt konkreetsete projektide omadustest ja omadustest.

Mudelikirjelduse valikud on üles ehitatud ühe skeemi järgi, mis sisaldab üldisi jaotisi:

• eessõna;
• 1 osa – sissejuhatus;
• 2. jagu - komponendi mudel;
• 3. jagu – terminoloogia;
• 4. jagu - mudeli iga versiooni tasemete ja põhikomponentide sisu (eesmärkide ja protseduuride väljatöötamine);
• 5. jagu – protsesside koosmõju struktuur; jaotises 7 on märgitud neli protsesside kategooriat, nende üldine ülevaade ja CMMI protsesside interaktsiooniskeemid:
  • protsesside juhtimine;
  • juhtimine - projektijuhtimine;
  • tehnika (tehnoloogia);
  • toetus;
• 6. jagu – mudeli kasutamine CMMI- lühisoovitused kasutajatele mudeli rakendamiseks ja koolituseks; märgitakse ära mudeliprotsesside ühilduvus ja vastavus eelmise CMM mudeli reguleeritud protsessidele standardi 2. ja 3. osas ISO 15504.
• 7. jaotis on iga standardi viimane, suurim, see võtab kogu dokumendist umbes 500 lehekülge, mis on üle 700 lehekülje. Selles jaotises antakse üksikasjalikud soovitused kõigi selles loetletud protsesside rakendamiseks, mis võtavad arvesse konkreetse mudeli omadusi.

Esimene variant(pidev) mudel kajastab dokumenti: Suutlikkuse küpsusmudeli integreerimine (CMMI) süsteemitehnika / tarkvaratehnika / integreeritud toote- ja protsessiarenduse jaoks, versioon 1.1, pidev esitus (CMMI-SE/SW/IPPD, V1.1, pidev). Integreeritud süsteemitehnika/tarkvaratehnika/integreeritud tooted ja arendusprotsesside küpsuse hindamise mudel – pidev vaade. Selles mudelis koosneb seitsmes jaotis protsessidest:

• protsessi juhtimine:
  • koolituse korraldamine;
  • protsesside ümberkujundamise (muutuste) korraldamine;
  • uuenduste ja laienduste korraldamine;
• projekti juht:
  • projekti planeerimine;
  • projekti protsesside jälgimine ja kontroll;
  • Riskide juhtimine;
  • kvantitatiivne projektijuhtimine;
• tehnika (tehnoloogia):
  • nõuete haldamine;
  • nõuete väljatöötamine;
  • tehnilised lahendused;
  • toote integreerimine;
  • kontrollimine;
  • valideerimine (atesteerimine, kinnitamine);
• toetus:
  • Konfiguratsiooni juhtimine;
  • muudatuste analüüs ja otsuste tegemine;
  • algpõhjuste analüüs ja probleemi lahendamine (defektide kõrvaldamine).

Viis lisa pakuvad järgmist:

AGA- kasutatud kirjandusallikate ja dokumentide koosseis, mis aga ei maini standardeid ISO;

AT- lühendid;

FROM- sõnastikupõhine terminoloogia ISO kasutatakse ainult neljas standardis ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - nõuete kirjeldused ja ettepanekud mudelikomponentide moodustamiseks küpsusastmete kaupa;

E - arenduses osalejate nimekiri CMMI- projekt.

Selles mudelis on tähelepanu suunatud organisatsiooni protsessidele, tarkvaraprojektide elluviimise protsesside planeerimisele, juhtimisele ja kontrollile, tarkvaratoodete nõuete väljatöötamisele ja haldamisele. Järgnevalt on toodud üksikasjade näited CMMI mõned neist.

Projekti planeerimine nii selles kui ka teises mudelis on:

• tarkvaratoote võimaliku suuruse (mastaabi) hindamine;
• PS projekti funktsioonide ja omaduste keerukuse hindamine;
• tarkvarapaketi elutsükli mudeli ja etappide määratlemine;
• projekti tasuvusuuring - alajaama maksumuse, töömahukuse ja eluea kestuse määramine;
• etapiviisilise töögraafiku ja projekti eelarve väljatöötamine;
• projekti riskide analüüs, tuvastamine ja hindamine;
• protsesside ja toodete dokumentatsiooni planeerimine ja haldamine PS projekti elutsüklis;
• tehniliste ja inimressursside planeerimine ja jaotamine PS elutsükli etappide kaupa;
• spetsialistide meeskonna teadmiste ja kvalifikatsiooni andmise kavandamine projekti elluviimiseks;
• PS projekti plaanide kogumi üldistamine ja analüüs;
• elutsükli etappide tööde ja ressursside kooskõlastamine arendaja poolt PS projekti tellijaga;
• tööplaani dokumenteerimine ja selle kinnitamine projektiarendaja juhi poolt.

Nõuete väljatöötamise protsessid tarkvaratoote jaoks on sarnased mõlema mudeli protsessidega ja hõlmavad järgmist:

• kliendi ja kasutajate tegelike vajaduste tuvastamine tarkvaratoote funktsioonide ja omaduste osas;
• tarkvaratoote funktsioonide esialgsete, põhinõuete väljatöötamine ja kooskõlastamine kliendi ja arendaja vahel;
• tarkvarakomplekti projekti saadaolevate ressursside ja piirangute kindlaksmääramine;
• PS-i funktsioonide põhiliste algnõuete dekomponeerimine tarkvarapaketi komponentide ja testide nõuete kogumiks;
• nõuete vormistamine komponentide vahelistele liidestele, töö- ja väliskeskkonnaga;
• tarkvaratoote kontseptsiooni ja selle kasutamise stsenaariumide väljatöötamine;
• nõuete väljatöötamine funktsionaalse sobivuse üldistatud tunnuste ja tarkvaratoote funktsioonide sihtotstarbelise kasutamise kohta.

Nõuete haldamine Mõlemad mudelid sisaldavad:

• tellija ja arendajate poolt PS projekti nõuetest üheselt mõistetava arusaamise saavutamine;
• kliendi poolt arendajatelt kohustuste võtmine täita kõiki oma nõudeid tarkvaratootele;
• tellija ja arendaja vahel kokkulepitud PS projekti nõuete muudatuste haldamine;
• PS projekti üldnõuetest komponentide ja konkreetsete protsesside nõuete muudatuste õigsuse tagamine;
• projekti arendusprotsesside ja kliendi nõudmiste vaheliste lahknevuste tuvastamine ja tuvastamine.

Teine variant esitab dokumendi: Suutlikkuse küpsusmudeli integreerimine (CMMI) süsteemitehnika/tarkvaratehnika/integreeritud toote- ja protsessiarenduse jaoks, versioon 1.1, etapiviisiline esitus (CMMI-SE/SW/IPPD, V1.1, etapiviisiline). Integreeritud süsteemitehnika/tarkvaratehnika/integreeritud tooted ja arendusprotsesside küpsuse hindamise mudel – etapiviisiline sissejuhatus. Mudel põhineb viie küpsustaseme kontseptsiooni säilitamisel CMM[ , ]. Protsesside koosseis kordab praktiliselt mudeli esimese versiooni puhul ülaltoodut, kuid veidi erinevas järjestuses ja suhteliselt väikeste täiendustega.

Esimene tase iseloomustab oluline ebakindlus protsesside koosseisus ja sisus erinevates suhteliselt lihtsates projektides, mistõttu seda dokumendis ei kommenteerita. Seetõttu protsesside sisu selgitamisel ja täpsustamisel etapiviisilises versioonis CMMI soovitatav piirata neli peamist taset:

• teine ​​tase- vormistab põhiline juhtimine projektid:
  • nõuete haldamine;
  • projekti planeerimine;
  • projekti seire ja kontroll;
  • tarnijatega sõlmitud lepingute haldamine;
  • protsesside ja toodete mõõtmine ja analüüs;
  • protsesside ja toodete kvaliteedi tagamine;
  • Konfiguratsiooni juhtimine;
• kolmas tase- sisaldab põhiprotsesside standardimist:
  • nõuete väljatöötamine;
  • tehnilised lahendused;
  • toote integreerimine;
  • kontrollimine;
  • valideerimine (sertifitseerimine);
  • organisatsiooniliste protsesside sisu;
  • organisatsiooniliste protsesside määratlemine;
  • koolituse korraldamine;
  • projektiprotsesside ja toodete integreeritud juhtimine;
  • Riskide juhtimine;
  • arendusmeeskonna integreerimine;
  • integreeritud tarnijate haldus;
  • probleemide analüüs ja lahendamine (defektide kõrvaldamine);
  • integratsioonikeskkonna korraldamine;
• neljas tase- määratleb kvantitatiivse juhtimise:
  • protsesside kvaliteedi esindamise korraldamine;
  • kogu projekti ja ressursside kvantitatiivne juhtimine;
• viies tase- optimeerimine, pidev täiustamine:
  • organiseerimine, innovatsioon, protsesside kvantitatiivne juhtimine ja ressurssidega varustamine;
  • defektide põhjuste analüüs, protsesside ja toodete kvaliteedi ja juhtimise parandamine.

Mudeli teise versiooni rakendused on koostiselt sarnased ülaltoodud esimese mudeli rakendustega. Soovitatav on taotleda igal kõrgemal küpsusastmel kõik protsessid varasemad madalamad tasemed. Mudeli mõlemas versioonis on iga ülaltoodud põhiprotsessi kommenteeritud üksikasjalike soovitustega selle praktiliseks rakendamiseks, mis sisaldavad umbes 20–30 lehekülje pikkuseid kirjeldusi, mis on struktuurilt ühtsed:

• saavutatavad protsessi üldised eesmärgid;
• sissejuhatavad märkused ja protsessi funktsioonide üldine kirjeldus;
• konkreetsed protsessi eesmärgid;
• protsesside juhtimine;
• protsessinõuete väljatöötamine;
• interaktsioon ja liidesed teiste protsessidega;
• praktilised eesmärgid - protsessi tegevuste nõutavad tulemused;
• tegevuste kavandamine konkreetses protsessis;
• protsessi rakendamise tulemuste analüüs ja valideerimine (kinnitamine);
• protsessi jälgimine ja kontroll.

Need soovitused on põhiprotsesside kirjelduste ulatuse, sisu ja täielikkuse osas sarnased mitmete PS elutsükli profiili standarditega, mis on esitatud aastal. Kasutatavate protsesside täielikkuse tellimine ja hindamine vastavalt küpsusastmetele võimaldab teil kindlaks teha ettevõtete - tarkvaratoodete arendajate - tootmispotentsiaali protsesside prognoositava kvaliteedi ja nende tegevuse tulemuste ning sertifitseerimisvalmiduse osas. vastavus mudeli teatud küpsusastmele CMMI - 1.1.

Rõhk mudelitel CMMI on antud PS projekti juhtimisprotsessidele. Need mudelite nõuded ja protsessid vastavad praktiliselt standardite reguleeritud ja üksikasjalikele soovitustele. ISO 9001:2000 ja keeruliste PS elutsükli standardite profiili põhikomponendid [ , ]. Nõuded protsessidele standardite funktsionaalsetes osades 4-8 ISO 9001, ISO 9004, ISO 90003 mudelis saab võrrelda mitmeid sisult piisavaid jaotisi CMMI(joonisel 1 sisu kattumise tsoon). Protsesside ja nõuete ühisosa seisneb sarnasuses: koosseis, terminoloogia, struktuur, soovitatavate juhtimisprotsesside loetelu, planeerimine, olemasolevate ressursside arvestus, tarkvaratehnika protsesside rakendamine, spetsialistide hindamine ja organiseerimine.

Joonis 1. Protsesside ja standardite ning küpsusmudelite nõuete ühtsus

Suurte tarkvaraprojektide kogu elutsükli toetamise ja reguleerimise seisukohalt mudelite puudused CMMI olemasolevate standardite profiili kohta ISO võib sisaldada järgmist:

Eespool esitatud PS elutsükli tagamise protsesside küpsusastmete määramiseks töötati välja ulatuslik tehniline aruanne ja see kiideti algselt heaks 1998. aastal. ISO 15504, mis koosneb üheksast osast ja paljudest rakendustest. See kirjeldab küpsusmudelit CMM ja kaheksa põhiprintsiibid standardil põhinev tarkvaratehnika ISO 9000:2000. Siis sisse ISO see dokument on läbinud põhjaliku läbivaatamise, vähendamise, struktuuri ja sisu lihtsustamise, säilitades samal ajal täielikult eesmärgid ja kontseptsiooni ning heaks kiidetud standardina viies osas.

Standard ISO 15504:1-5:2003-2006 reguleerib ettevõtetes teostatavate tarkvaratööriistade ja süsteemide loomise, hooldamise ja täiustamise protsesside küpsuse hindamist ja sertifitseerimist:

• oma riiki kehtestada tehnoloogilised protsessid ja nende parandamine;
• teha kindlaks oma protsesside sobivus konkreetsete nõuete või kliendinõuete klasside täitmiseks;
• pidades silmas selle sobivust jõudluseks teatud lepingud PS-i ja süsteemide klientidega.

Standard aitab kaasa: ettevõtete küpsuse enesehinnangule, atesteeritud protsesside piisava juhtimise tagamisele, protsessi reitingute profiili määramisele ning sobib ka operatsioonisüsteemi ja süsteemide mis tahes ulatuse ja suurusega. Standardi rakendamine on suunatud ettevõtete ja spetsialistide arendamisele pideva täiustamise tehnoloogia küpsuse kultuur projektide ärieesmärkidele vastava PS elutsükli tagamine ja olemasolevate ressursside kasutamise optimeerimine. Ettevõtlusprotsesside küpsuse hindamine annab võimaluse neid võrrelda ja valida, mis on teatud projektide puhul eelistatav:

• klientidele, ostjatele, tarkvaratoodete ja süsteemide kasutajatele: võime määrata tarnija elutsükli protsesside praegust ja potentsiaalset küpsust;
• hankijatele ja arendajatele: võime määrata oma tarkvara ja süsteemide elutsükli protsesside, protsesside täiustamise valdkonnad ja prioriteedid praegust ja potentsiaalset küpsust;
• immatrikuleerimise hindajatele: hindamisprotsesside läbiviimise ja täiustamise raamistik.

Standardis kinnitamist käsitletakse aastal kaks aspekti: parandada konkreetse ettevõtte PS-i ja süsteemide elutsükli protsesse ning teha kindlaks, kas projekti või ettevõtte tugiprotsesside deklareeritud tähtaeg vastab tegelikult kasutatavatele protsessidele. See kajastub standardi viies järgmises osas. ISO 15504:1-5:2003-2006.

1. osa - Mõiste ja sõnavara. Sisaldab üldist teavet tarkvara ja süsteemide küpsuse sertifitseerimise protsesside kohta ning soovitusi standardi osade kasutamiseks. Välja toodud Üldnõuded sertifitseerimise, terminoloogia, struktuuri jaoks määratakse standardi ülejäänud osade ulatus.

2. osa – Sertifitseerimise teostamine (tootmine). See sisaldab üksikasjalikke nõudeid sertifitseerimisprotsesside läbiviimiseks, mis on aluseks PS-i ja süsteemide elutsükli tagamise tehnoloogiliste protsesside täiustamisele ja küpsusastme määramisele. Dokumendis on määratletud atesteerimise teostamise protsessid, mudelid soovitatud atesteerimisprotsesside ja protsesside kontrollimiseks, et need oleksid objektiivsed, sisukad ja esinduslikud.

3. osa – Sertifikaadi koostamise juhend. Annab ülevaate küpsushindamise protsesside läbiviimise ja nõuete rakendamise tõlgendamise tehnoloogiast. See kajastab: sertifitseerimise tulemuslikkust; mõõteriistad küpsusprotsesside määramiseks; sertifitseerimisvahendite valik ja rakendamine; sertifitseerijate pädevuse hindamine; tunnistuse deklareeritud nõuetele vastavuse kontrollimine. Valideerimistööriistu saavad ettevõtted kasutada tarkvaratoodete ja süsteemide planeerimisel, haldamisel, jälgimisel, kontrollimisel ja täiustamisel, nende hankimisel, arendamisel, rakendamisel ja hooldamisel.

4. osa – Kasutusjuhend protsesside täiustamiseks ja protsessi küpsuse saavutamiseks nendes kahes aspektis. Soovitatakse mitmeid samme, mis hõlmavad järgmist: valideerimisprotsesside tulemuste rakendamine; küpsushindamise eesmärkide seadmine; sertifitseerimiseks lähteandmete määramine; sellest tulenevate riskide võimaliku vähendamise hindamine; sammud protsesside parandamiseks; küpsusastme määramise sammud; kvalifikatsioonianalüüsi tulemuste võrdlemine nõuetega.

5. osa – Osas 2 esitatud nõuetele vastavuse tõendamisprotsesside näidismudel. Mahukas dokument (162 lk) pakub praktilisi näiteid standardi eelmistest osadest elutsükli protsesside küpsushinnangute korraldamiseks, hindamiseks ja täiustamiseks erinevate rakendusvaldkondade, tarkvaraprojektide ja ettevõtete jaoks.

Projektide praktilisel elluviimisel ja keeruka tarkvara elutsükli tagamisel on arendajatel ja tarnijatel mõnikord keeruline tuvastada ja esile tuua rakendusmudelite eeliseid. CMMI. Sõltuvalt ettevõtte traditsioonidest ja suure projekti omadustest on sageli soovitatav kasutada PS-i peamise täispikana. standardite profiilISO ja klientide hindamiseks küpsusaste PS-projektide juhtimine, organisatsiooniline ja tehnoloogiline tugi rakendab konkreetseid soovitusi CMMI. Neid juhiseid saab tõhusalt kasutada protsessi kvaliteedi sertifikaat ettevõtetes, mis pakuvad PS elutsüklit alternatiivina või koos juhtimisstandardite kogumi sertifikaadiga ISO 9000, olenevalt projekti spetsiifikast ja tarkvaratoote või tehnoloogia elutsükli tagamiseks sertifitseerimise taotleja nõuetest.

Tarkvaratoodete sertifitseerimise korraldamine

Sertifitseerimine koosneb reast organisatsioonilistest protsessidest, mis moodustavad sertifitseerimissüsteem, neid protsesse toetavad reguleeritud protseduurid ja dokumendid ning need peavad läbi viima kvalifitseeritud, sertifitseeritud eksperdid – inspektorid. Ettevõtte arendaja ja tema tegevuse tulemuste sertifitseerimiseks - tarkvaratooted, mudelid CMMI või standardprofiilid ISO[ , ] on soovitatav teatud distsipliin, mis peaks olema kohandatud objektide spetsiifilistele omadustele ja PS elutsükli keskkonnale. Allpool loetletud protsessid ja dokumendid on mõeldud suurte projektide jaoks ning lihtsamatel juhtudel võib arendajate, klientide ja sertifitseerijate kokkuleppel neid vähendada.

Sertifitseerimistöö algab asutuse või katselabori akrediteerimisest, taotluse ja dokumentide komplekti vormistamisest ja esitamisest kesksele sertifitseerimisasutusele akrediteerimise otstarbekuse otsustamiseks. Kui testi tulemused on positiivsed, vormistatakse ja väljastatakse akrediteerimistunnistus.

Sertifitseerimisasutuse või labori eeskirjad on peamine dokument, mis määrab kindlaks akrediteerimise teemavaldkonna, õigusliku staatuse, funktsioonid, struktuuri, õigused ja kohustused, meetodid, vahendid ja testide korraldamise. Sertifitseerimislabori (keskuse) pass peab sisaldama teavet seadmete kohta arvutiteadus testimiseks vajalik personali ja personali kohta, seadmed koos testimisvahenditega, regulatiivsete, tehniliste ja metoodiliste dokumentide ning muude testimiseks vajalike vahenditega varustamine.

Kvaliteetne hind sisaldab põhimõtete kirjeldust, sertifitseerimisasutuse või labori põhiülesannete ja -ülesannete täitmisega seotud meetodite ja protseduuride kirjeldust, mis tagab testide kvaliteedi ning usalduse hindamiste, testide ja uuringute tulemuste vastu. Kvaliteedijuhend sisaldab tavaliselt jaotisi [ TWLSC$

• testimise ja eksamite kvaliteedi tagamise poliitika;
• keskuse varustamine asjakohaste metoodiliste materjalide ja tarkvara ning testimisvahenditega;
• nõuete vormistamine katseobjektidele;
• keskuse tehnilise varustuse ja personali arendamise poliitika;
• sertifitseerimistulemuste dokumentatsiooni arhiveerimine ja ohutuskontroll.

Sertifitseerimisele kuuluvate toodete või protsesside hindamiseks saadab taotleja sertifitseerimisasutusele taotluse sertifitseerimissüsteemis vastuvõetud vormis. Sertifitseerimisasutus teostab taotluse alusel toote sertifitseerimise ettevalmistamise ja korraldamise tööd. See töö sisaldab:

• sertifitseerimisskeemi valik, võttes arvesse toodete eripära (maht, tehnoloogia, normatiivdokumentide nõuded jne) ja arendaja ettepanekuid;
• proovivõtu ja testitavate komponentide arvu ja järjekorra määramine, kui see ei ole standardites ette nähtud;
• testide läbiviimiseks akrediteeritud katselabori valimine ja määramine;
• tööde teostamise lepingu projekti koostamine.

Sertifitseerimistöö ettevalmistav osa lõpeb otsuse avaldamisega sertifitseerimissüsteemis vastuvõetud kujul. Otsus koos tööde teostamise lepingu projektiga saadetakse taotlejale. Sertifitseerimiskatsete korraldamisel viiakse läbi sertifitseerimiseks deklareeritud toodete kehtivate regulatiivsete dokumentide valik ja uurimine, testimismeetodid ja tulemuste hindamine.

Taotleja teeb lõpliku otsuse, millised kvaliteedisüsteemi elemendid, valdkonnad ning organisatsiooniliste ja tehniliste tegevuste liigid kuuluvad sertifitseerimise käigus teatud ajavahemike järel kontrollimisele. Taotleja peab looma tingimused ja esitama dokumendid tõendamisprotsesside tagamiseks. Ta saab esitada sertifitseerimisasutusele toodete arendamise ja tootmise käigus tehtud katseprotokollid, dokumente kolmandate isikute katselaborite tehtud katsete kohta ja muid dokumente, mis näitavad tehnoloogia või toodete vastavust kehtestatud nõuetele. Koos taotlusega esitatud dokumenteeritud tõendite analüüsi põhjal, mis kinnitavad oma toodete vastavust kehtestatud nõuetele, võib sertifitseerimisasutus otsustada katsete ulatust vähendada või sertifikaadi väljastada.

Katseid viivad läbi katselaborid, mis on akrediteeritud tegema ainult neid katseid, mis on ette nähtud nende regulatiivsetes akrediteerimisdokumentides. Kui akrediteeritud labori katseasutuses ei ole võimalik katseid läbi viia, võivad selle labori töötajad teha katseid selle toote tootja või tarbija juures, kasutades katselabori enda rajatisi või tarnijalt saadaolevaid katseseadmeid. .

Tarkvaratoodete ja ettevõtte kvaliteedisüsteemide sertifitseerimisprotsess hõlmab järgmist:

• arendaja või tellija (taotleja) analüüs ja valimine selles valdkonnas pädeva asutuse ja sertifitseeritud labori poolt sertifitseerimiskatsete tegemiseks;
• taotleja poolt katsetamise taotluse esitamine sertifitseerimisasutusele ja sertifitseerijate poolt taotluse kohta otsuse vastuvõtmine, sertifitseerimisskeemi valik, sertifitseerimislepingu sõlmimine;
• nõuete tuvastamine ettevõtte kvaliteedisüsteemile ja/või testitava tarkvaratoote versioonile;
• ettevõtte kvaliteedisüsteemi või tarkvaratoote versiooni sertifitseerimistestide läbiviimine sertifitseerimislabori poolt;
• saadud tulemuste analüüs ja labori ja/või sertifitseerimisasutuse poolt taotlejale vastavussertifikaadi väljastamise võimaluse kohta otsuste tegemine;
• sertifitseerimisasutuse poolt taotlejale väljastamine - sertifikaat ja litsents vastavusmärgi kasutamiseks ja sertifitseeritud toodete väljastamiseks - tarkvaratoote versioonid;
• ettevõtte ja/või toodete sertifitseeritud kvaliteedisüsteemi kontrolli teostamine sertifitseerimisasutuse poolt;
• taotleja poolt parandusmeetmete rakendamine kvaliteedisüsteemi ja/või toodete protsesside kehtestatud nõuetele vastavuse rikkumise ja vastavusmärgi ebaõige kasutamise korral.

Kontrollides arendaja juhtkonna vastutust toote kvaliteedi eest, tuleks kindlaks teha, et ettevõttel või projektil on kvaliteedivaldkonnas dokumenteeritud poliitika, eesmärgid ja kohustused, samuti see, mil määral seda poliitikat mõistetakse, rakendatakse ja järgitakse. töökorras kõigil organisatsiooni tasanditel. Tuleks kehtestada, et ettevõttes on juhtkonna esindaja, kellel on sõltumata muudest ülesannetest volitused ja vastutus kvaliteedisüsteemi standardite ja regulatiivdokumentide nõuete pideva rakendamise eest. Kontrollida tuleks kvaliteedisüsteemi protsesside praktiliseks rakendamiseks vajalike nõuete, protseduuride, tööriistade ja koolitatud personali olemasolu, samuti kvaliteedisüsteemi kõigi komponentide, nõuete ja sätete asjakohasust ja süstemaatilist dokumenteerimist, mis on terviklik protsess läbivalt. PS elutsükkel. Kvaliteedisüsteemi kontrollid peaks sisaldama määratlust:

• tehnoloogilise dokumentatsiooni kättesaadavus ja täielikkus ning vastavus selle nõuetele praktikas;
• tehnoloogiliste seadmete seisukord ja nende hooldussüsteemi olemasolu;
• kontrolli- ja testimissüsteemi olemasolu ja tõhusus;
• mõõte- ja katseseadmete seisund;
• toodete või tehnoloogia tuvastatud puuduste tuvastamise ja kõrvaldamise süsteemi olemasolu.

Testide põhjal hinnatakse saadud tulemusi ning põhjendatakse järeldusi toodete või protsesside vastavuse või mittevastavuse kohta normatiivdokumentide nõuetele. Katseprotokollid esitatakse sertifitseerimisasutusele, samuti taotlejale tema nõudmisel. Katseprotokollid kuuluvad säilitamisele toodete sertifitseerimissüsteemide eeskirjades ja katselabori dokumentides sätestatud perioodid, kuid mitte vähem kui kolm aastat.

Pärast dokumentatsiooni täielikkuse ja kvaliteedi kontrollimist peaksid katselabori spetsialistid läbi viima kvaliteedisüsteemi tegeliku kohaldamise astme uurimine ettevõtte juures. Testimine algab kvaliteedisüsteemi testimisprogrammi väljatöötamisega, mis peaks toimima tööplaanina järgnevaks tööks. Programm on katselabori sisemine töödokument ja peaks sisaldama tööde loendit, mis on üksikasjalikult koostatud vastavalt arendaja ettevõtte spetsiifikale ja sisaldama analüüsi esitatud algdokumentide terviklikkuse ja kvaliteedi ning nende praktilise rakendamise taseme kohta. tarkvara kavandamisel, arendamisel ja tarnimisel. Kvaliteedisüsteemi protseduuride rakendamise kontrolli viib läbi PS elutsüklit tagava ettevõtte töökohtades asuv katselabor. Kontrollitakse asjakohaste dokumentide väljatöötajate spetsialistide kohalolekut töökohal ning nende sätete ja soovituste kasutamise täielikkust. Projekti oleku ülevaatamist ja kvaliteedisüsteemi, protsesside ja/või toodete siseauditeid peaksid läbi viima nende tööde teostamise eest otseselt vastutavatest isikutest sõltumatud töötajad.

Arenduskvaliteedi kontrollimise meetodid tuleks ette näha vajalikke ressursse testimisprogrammi rakendamiseks, planeerimismeetoditeks ja eratestiprotseduuride väljatöötamiseks. Meetodid peaksid sisaldama: testimise objekte ja eesmärke; hinnatud kvaliteedinäitajad; testimise tingimused ja kord; katsetulemuste töötlemise, analüüsi ja hindamise meetodid; tehniline abi testimine ja aruandlus. Märkida tuleks testide ja katseprotseduuri käigus kasutatud riist- ja tarkvara, samuti kontrollide oodatavad tulemused. Tuleks välja töötada meetodid paranduste kontrollimiseks, toimingud defektide parandamiseks, kui auditihaldusteenistus saab sellise taotluse. Testiprogrammi haldusteenus peaks kehtestama protseduurid mis tahes testiteabe ja hindajate valduses olevate andmete konfidentsiaalsuse säilitamiseks.

Katsearuanded esitatakse taotlejale ja sertifitseerimisasutusele. Taotleja võib esitada sertifitseerimisasutusele nende kehtivusaega arvestades toodete väljatöötamise ja tootmise käigus tehtud katseprotokollid või dokumente sertifitseerimissüsteemis akrediteeritud või tunnustatud kodumaiste või välismaiste katselaborite tehtud katsete kohta. Sertifitseerimiskatsete protokollide alusel hinnatakse saadud tulemusi ning põhjendatakse järeldusi, mis tehakse toodete vastavuse või mittevastavuse kohta normatiivdokumentide nõuetele.

Järeldus sertifitseerimiskatsete tulemuste kohta on välja töötatud sertifitseerijate poolt ja see sisaldab üldistatud teavet testitulemuste ja sertifikaadi väljastamise põhjenduste kohta. Sertifitseerimiskatsete negatiivsete tulemuste saamise korral tehakse otsus keelduda vastavussertifikaadi väljastamisest. Pärast sertifitseeritud toote või kvaliteedisüsteemi valmimist saab katseid korrata. Tehnoloogia seisu või toote kvaliteedi analüüsi tulemused on koostatud aktiga, mis annab hinnangud kõikide katseprogrammi positsioonide kohta ja sisaldab järeldusi, sealhulgas üldist hinnangut tootmise ja toodete seisukorrale, parandusmeetmete vajadusele. Akti kasutab sertifitseerimisasutus koos testiprotokollite, tarkvaratoote sertifikaadi väljastamise ja kehtivusaja määramise taotlusega, kontrollimise sageduse ja ka parandusmeetmete koostamiseks.

Sertifitseerimiskatsete ja dokumentatsiooni uurimise tulemuste põhjal tehakse otsus sertifikaadi väljastamise kohta. Sertifitseerimiskatsete negatiivsete tulemuste saamise korral tehakse otsus tunnistuse väljastamisest keeldumine vastavust. Lisaks saab taotlevale ettevõttele saata ettepanekuid negatiivsete testitulemuste väidetavate põhjuste kõrvaldamiseks, pärast sertifitseeritud toodete valmimist saab katseid korrata.

Sertifitseerimisasutus pärast katsearuannete analüüsimist, toodangu hindamist, kvaliteedisüsteemi sertifitseerimist, taotluse otsuses märgitud dokumentatsiooni analüüsimist hindab toodete vastavust kehtestatud nõuetele, koostab ekspertide arvamuse põhjal sertifikaadi. ja registreerib selle. Projektis või töödokumentatsioonis muudatuste tegemisel, mis võivad mõjutada sertifitseerimise käigus sertifitseeritud süsteemi või tarkvaratoote kvaliteeti, peab taotleja sellest teavitama sertifitseerimisasutust, et otsustada lisatestide vajaduse üle. Pärast registreerimist sertifikaat jõustub ja saadetakse taotlevale ettevõttele. Samaaegselt tunnistuse väljastamisega võidakse väljastada taotlev ettevõte litsents vastavusmärgi kasutamise õiguse eest.

Sertifitseeritud tarkvaratoodete puhul nende töötamise ajal kogu vastavussertifikaadi kehtivusaja jooksul, ülevaatuse kontroll. Ülevaatuse kontroll toimub perioodilise ja plaanivälised kontrollid vastavus tehnoloogia ja sertifitseeritud toodete kvaliteedinõuetele. Kontrolliobjektid, olenevalt sertifitseerimisskeemist, on sertifitseeritud tooted, kvaliteedisüsteem või arendaja toodangu stabiilsus. Kontrollimise sageduse ja ulatuse määramisel võetakse arvesse järgmisi tegureid: tarkvaratoote võimaliku ohtlikkuse määr, tootmise stabiilsus, väljalaske maht, kvaliteedisüsteemi kättesaadavus ja rakendamine arenduse käigus, teave tootja, riikliku kontrolli- ja järelevalveorganite poolt läbi viidud toote ja selle tootmise katsete tulemuste kohta.

Kontrollimise tulemused on koostatud aktiga, mis hindab näidistestide ja muude kontrollide tulemusi, teeb üldise järelduse sertifitseeritud toodete tootmise seisu ja väljastatud sertifikaadi kehtivuse säilitamise võimaluse kohta. Akt säilitatakse sertifitseerimisasutuses ning selle koopiad saadetakse arendajale ja kontrollikontrollis osalenud organisatsioonidele. Inspekteerimiskontrolli tulemuste põhjal võib sertifitseerimisasutus peatada või tühistada sertifikaadi kehtivuse ning tunnistada kehtetuks vastavusmärgi kasutamise õiguse litsentsi, kui tooted ei vasta sertifitseerimise käigus kontrollitud regulatiivsete dokumentide nõuetele. , samuti järgmistel juhtudel:

• põhimõttelised muudatused küpsusmudelis, standardiprofiilis, toote eeskirjades või katsemeetodis;
• muudatused toodete disainis (koostises), komplektsuses;
• muutused arenduse ja tootmise korralduses või tehnoloogias;
• mittevastavus tehnoloogia, kontrolli- ja katsemeetodite, kvaliteedisüsteemi nõuetele, kui loetletud muudatused võivad põhjustada toodete mittevastavust sertifitseerimise käigus kontrollitud nõuetele.

Vastavusmärgi kasutusõiguse sertifikaadi ja litsentsi kehtivuse peatamise otsust ei võeta vastu, kui taotleja suudab selle väljastanud sertifitseerimisasutusega kokkulepitud parandusmeetmete abil kõrvaldada tuvastatud mittevastavuse põhjused ja kinnitada , ilma kordustestimiseta akrediteeritud laboris, toote või protsesside vastavust normatiivdokumentidele. Kui seda ei ole võimalik teha, siis sertifikaadi kehtivus tühistatakse ja vastavusmärgi kasutamise õiguse litsents tühistatakse. Teave sertifikaadi peatamise või tühistamise kohta toob taotlejale, tarbijatele ja teistele huvitatud organisatsioonidele selle väljastanud sertifitseerimisasutus. Sertifikaadi kehtivusaega ja toodete vastavusmärgiga märgistamise õigust saab uuendada, kui arendusettevõte täidab järgmised tingimused:

• mittevastavuse põhjuste väljaselgitamine ja nende kõrvaldamine;
• sertifitseerimisasutusele aruande esitamine toote kvaliteedi parandamiseks ja tagamiseks tehtud töö kohta;
• toodete lisatestide läbiviimine vastavalt sertifitseerimisasutuse meetoditele ja kontrolli all ning positiivsete tulemuste saamine.

Tarkvaratoodete sertifitseerimise protsesside ja tulemuste dokumenteerimine

Kvaliteedisüsteemi sertifitseerimise dokumentatsiooni koosseis ja sisu ettevõtted sõltuvad tarkvara projekteerimise, arendamise ja muutmise omadustest, samuti nende kvaliteedinõuetest ja tehnoloogilise keskkonna omadustest. Seetõttu tuleks iga ettevõtte või projekti jaoks valida vajalik dokumentide kogum ja kohandada neid vastavalt nendele omadustele. Sertifitseerimisel hinnatavateks kvaliteedisüsteemi näitajateks on asjakohaste dokumentide olemasolu ja küpsusmudeli teatud taseme nõuete praktiline täitmine. SMMI või sellel põhinev kohandatud standardiprofiil ISO 9000:2000, samuti nende alusel loodud, töökirjeldus ettevõtte arendaja spetsialistid. Taotleja peab koostama ja katselaborile esitama tellija ja arendaja vahel kokku lepitud ja kinnitatud dokumentide komplekti, et kontrollida nende töökindlust, koostise ja tööde piisavust vastavalt regulatiivsetele dokumentidele.

Sertifitseerimise alusdokumentide soovituslik kogum koosneb kolmest rühmast:

• põhilised määrused kvaliteedisüsteemid vastavalt nomenklatuurile ja standardite profiili sisule, mis põhinevad ISO 9000:2000 või küpsusmudelid SMMI, samuti nende alusel arendajate poolt koostatud programm, juhend ja juhised, mis esitatakse auditeeritava ettevõtte kvaliteedisüsteemi või toodete testijatele (ekspertidele);
• konkreetset ettevõtet või projekti, samuti tarkvaratööriista elutsüklit iseloomustavad algdokumendid, mille projektijuhtkond on koostanud selle kvaliteedi tõendamiseks;
• ettevõtte kvaliteedisüsteemi ja/või tarkvaratoote auditi (sertifitseerimise) tulemusi kajastavad testijate aruandedokumendid, mis esitatakse sertifitseerimisasutusele, taotlejale ja auditeeritava ettevõtte juhtkonnale.

Sertifitseerimiseks esitatav tarkvaratoode või ettevõtte kvaliteedisüsteem tuleb esitada koos vastava dokumentatsiooniga. Nende dokumentide rühmade loetelu ja ligikaudne sisu on keskendunud suurte tarkvaratoodete elutsüklit tagavate ettevõtete kvaliteedisüsteemide kontrollimise üldisele juhtumile. Dokumentide kogumit võib taotleja, sertifitseerija ja auditeeritava ettevõtte juhtkonna kokkuleppel vähendada ja kohandada vastavalt tarkvaraprojektide tunnustele. Mõningaid dokumente saab kombineerida integreeritud aruanneteks, mille rakendamise eest vastutavad teatud spetsialistid selgelt.

Ettevõtte kvaliteedisüsteemi ja tarkvara elutsükli alusdokumendid

1. Tulemuslikkuse parandamise kontseptsioon, terminoloogia, nõuded ja juhised – kvaliteedijuhtimissüsteemid – ISO 9000:2000 või CMMI küpsusmudeli versioon.
2. Standardite kohandatud versioonid või jaotiste loetelu ja soovitused ISO 12207, ISO 15504, nende muudatused ja rakendusjuhised, mis valitakse kohandamise käigus ja on kohustuslikud kasutamiseks konkreetse ettevõtte või tarkvaratoote projekti kvaliteedisüsteemis.
3. Standardi kohandatud versioon või jaotiste ja soovituste loend ISO 900003, mis on kohandamise käigus valitud ja tarkvaratoodet tootva ettevõtte kvaliteedisüsteemis kasutamiseks kohustuslik.
4. PS-projekti põhinäitajad ja kvaliteediatribuudid, mis on standardite alusel tuvastatud, kohandatud ja täpsustatud ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Hooldus- ja konfiguratsioonihaldusjuhendi kohandatud versioon ja heakskiidetud väljaanne, mis põhineb standardite soovitustel ISO 14764, ISO 10007, ISO 15846.
6. Ametijuhendite kogum, mis määratleb konkreetse PS-projekti jaoks ettevõtte kvaliteedisüsteemi protseduuridega seotud kõigi juhtkonna, töö teostamise ja kontrollimise personali vastutuse, volitused ja suhtlemise korra.

Algdokumendid, mis kajastavad konkreetse tarkvaratööriista elutsükli funktsioone

1. Ettevõttes loodud tarkvaratoodete, süsteemi ja nende elutsükli väliskeskkonna omaduste kirjeldus, mis on vajalikud PS-projekti standardite ja nõuete ning ettevõtte kvaliteedisüsteemi tööversioonide kohandamiseks ja koostamiseks. standardite soovitused ISO 12207, ISO 15504, ISO 90003 ja ISO 9126.
2. Ettevõtte-arendaja eesmärkide, nõuete ja kohustuste kirjeldus kvaliteedisüsteemi valdkonnas, tarkvara arendusprotsesside ja toodete kvaliteedikriteeriumid, tarne ja tugi kogu tarkvara elutsükli jooksul.
3. Kliendile ja kasutajatele tarnitud tegevusdokumentide komplekt, et tagada tarkvaratoote konkreetse versiooni elutsükkel ja kasutamine kohandatud standardite alusel ISO 9294, ISO 15910, ISO 18019.
4. Dokumentatsiooni- ja automatiseerimisvahendid projekteerimiseks, arendamiseks, muutmiseks, juhtimiseks ja testimiseks, mida kasutatakse tarkvaratoote elutsükli tagamiseks.
5. Plaanid ja meetodid rakenduse testimiseks ning ettevõtte kvaliteedisüsteemi ja tarkvaratoote protsesside efektiivsuse hindamiseks.
6. Hooldusmeetodid, tarkvaratoote komponentide ja dokumentatsiooni tuvastamine, tarkvara ja andmekomplekside versioonide analüüs ja kinnitamine.
7. Tarkvaratoodete versioonide ja kaasnevate dokumentide konfiguratsioonihalduse, kinnitamise, säilitamise, kaitsmise, kopeerimise, samuti ettevõtte arhiivis registreeritud kvaliteedinäitajate andmete kogumise ja säilitamise metoodika tarkvaratoote versioonide elutsükli jooksul.

Saadud testidokumendid – ettevõtte ja/või tarkvaratoote kvaliteedisüsteemi sertifikaat

1. Aruanne ettevõtte kvaliteedisüsteemi nõuete ja sätetega kohandatud dokumentatsiooni kättesaadavuse, asjakohasuse ja süstemaatilise täitmise kohta, mis tagab tervikliku kvaliteedi tagamise protsessi kogu tarkvaratoote elutsükli jooksul.
2. Kvaliteedisüsteemi seisukorra ja rakendamise seire ja testimise tulemused, mis viiakse läbi perioodiliselt, et teha kindlaks selle sobivus ja tõhusus.
3. Aruanne ülevaatuste läbiviimise meetodite olemasolu ja hoolduse kohta ning dokumenteeritud aruanded kliendiga sõlmitud sertifitseerimislepingu nõuete täitmise saavutatud kvaliteedi tulemuste kohta.
4. Tarkvarapaketi saavutatud kvaliteedinäitajate registreerimise tulemused: tarkvaratoote ja selle komponentide kvaliteedi omaduste ja atribuutide identifitseerimine, kogumine, registreeritud andmete salvestamine.
5. Arengukava elluviimise tulemused, arendusetappide dokumenteeritud sisend- ja väljundandmed ning protokollid PS elutsükli täitmise kontrollimiseks.
6. Kvaliteediprogrammi praktilise rakendamise ja kvaliteedivaldkonna reguleeritud tegevuste elluviimise tulemused PS kõigis elutsükli etappides.
7. Keskkonnasimulaatorite ja testgeneraatorite sertifitseerimise tulemused, samuti hinnang nende piisavusele tarkvaratoote sertifitseerimistestide läbiviimiseks.
8. Plaanide ja katsemeetodite elluviimise analüüsi tulemused, katseprotokollid, hinnangud katsetulemuste nõuetele vastavuse kohta, samuti taotleja, tellija ja tarnija esindajate poolt kinnitatud katsetulemused.
9. Tarkvarasüsteemi elukaare ja ettevõtte kvaliteedisüsteemi tegelike omaduste kontrollimise tulemuste akt, järeldused nende vastavuse kohta tarkvaratoote tootmise sertifitseerimise nõuetele.
10. Ettevõtte ja/või tarkvaratoote kvaliteedisüsteemi ja selle elutsükli tagamise sertifikaat, litsents vastavusmärgiste kasutamiseks.

Kirjandus

V.V. Lipaev - Tarkvara elutsükli standardite profiilid. -- Jet Info, uudiskiri, N 12, 2005

K. Milman, S. Milman -- SMMI on samm tulevikku. -- avatud süsteemid., N 5-6 (2005), N2 (2006), 2005, 2006

Tarkvaratööriistade ja infosüsteemide loomise ja hooldamise protsesside küpsuse hindamine ja sertifitseerimine ISO IEC TR 15504-CMMI. Per. inglise keelest -- M.: Raamat ja äri, 2001

V.V. Lipaev - Keerulise tarkvara elutsükli protsessid ja standardid. Kataloog.-- M.: SINTEG, 2006

V.V. Lipaev - Meetodid suuremahulise tarkvara kvaliteedi tagamiseks.-- M.: RFBR. SINTEG, 2003

"; antisource: "Tarkvaratooteid kasutatakse nüüd juhtimisprobleemide lahendamiseks peaaegu kõigis inimtegevuse valdkondades: majanduses, sotsiaal-, sõjalistes ja muudes valdkondades. Kodumaiste tarkvaratoodete kõrge kvaliteedi tagamine nende massilise arendamise ja tarnimise käigus erinevatele rakendustele riigis ja maailmaturul on muutunud strateegiliseks ülesandeks."; tingimus: 1]$

Märkus: Üksikasjalikult uuritakse ideede ringi, mille aluseks on ilmselt kõige tuntum arendusprotsesside täiustamise metoodika. tarkvara- SMM. Analüüsitakse HMM-i loogikat ja struktuuri. Näidatud on seos HMM-i ja varem uuritud protsessimudelite vahel.

raames loodud imeline praktiline tööriist protsessi lähenemine tegevuse kirjelduse juurde projekteerimisorganisatsioon eelkõige arenev organisatsioon Infosüsteemid , demonstreerib HMM-i metoodikat. CMM tähistab võimekuse küpsusmudelit, mis tähendab umbkaudu "juhtimissüsteemi küpsusmudelit". Kirjanduses nimetatakse CMM-i sagedamini organisatsiooni küpsuse mudeliks ja ma järgin ka seda traditsiooni.

SMM-i tekkimise ajalugu on järgmine. 80ndate lõpus. eelmisel sajandil tellis USA kaitseministeerium Tarkvaratehnoloogia Instituudi 1Eng. SEI – Tarkvaratehnika instituut Carnegie Melloni ülikool töötab tarkvaraarendusprojektide alltöövõtjate valiku kriteeriumide süsteemi kallal. Töö valmis 1991. aastal ja tulemuseks oli CMM. Peame kohe tegema reservatsiooni, et mudel ei sisalda rahalist, majanduslikku, poliitilist ega organisatsioonilist valikukriteeriumid alltöövõtja, samuti salatööle lubamise võimaluse kriteeriumid (ilmselt selliseid ülesandeid ei seatud). Räägime ainult kriteeriumidest, mis kirjeldavad potentsiaalse alltöövõtja võimekust tarkvarasüsteemide arendamise osas.

CMM struktuur

Mudeli loojad võtsid organisatsiooni protsessid aluseks, et hinnata organisatsiooni võimekust teha kvaliteetset tööd, mida (võimekust) nimetati küpsuseks. Seejärel tegid nad mõned mittetriviaalsed oletused, mida paljud IT-spetsialistid (ja võib-olla enamik neist) hiljem aktsepteerisid ja õiglaseks tunnistasid.

Eeldus 1. Küpsusastmeid on kvalitatiivselt erinevad projekteerimisorganisatsioon arenev Infosüsteemid(HMM-i mudelis on viis sellist taset).

2. eeldus. Iga arendusorganisatsioon on huvitatud kõrgemale küpsusastmele liikumisest (mitte ainult selleks, et suurendada oma võimalusi võitluses kaitseministeeriumi lepingute pärast, vaid ka selleks, et ennast täiendada).

3. eeldus. Üleminek on võimalik ainult järjekorras järgmisele tasemele. Üle taseme “hüppamine” on võimatu (täpsemalt tõusevad samal ajal järsult riskid organisatsiooni jaoks).

Seega moodustavad tasemed "redeli", mida mööda organisatsioon tõuseb enda areng. Iga taset iseloomustab organisatsiooni protsesside teatud koostis ja omadused. SMM "Level Ladder" on laialdaselt tunnustatud ja levinud. Siin on, kuidas ta välja näeb.

Tase 1 "Algaja". Tootmisprotsessi tervikuna iseloomustatakse kui iga kord konkreetse projekti jaoks loodud ja mõnikord isegi kaootilist. Määratletakse vaid mõned protsessid ja projekti edu sõltub üksikisikute pingutustest.

2. tase "korduv". Põhilised projektijuhtimise protsessid on paika pandud, mis võimaldavad jälgida kulusid, jälgida töögraafikut ja loodava tarkvaralahenduse funktsionaalsust. Kehtestatud protsessidistsipliin, mis on vajalik sarnaste rakenduste arendusprojektide varasemate edusammude kordamiseks.

3. tase "kindel". Tootmisprotsess on mõlema jaoks dokumenteeritud ja standardiseeritud juhtimistöö samuti disaini jaoks. See protsess on integreeritud organisatsiooni standardsesse tootmisprotsessi. Kõik projektid kasutavad organisatsiooni standardse tööprotsessi kinnitatud kohandatud versiooni.

4. tase "Hallatud". Kogutakse üksikasjalikud kvantitatiivsed näitajad tootmisprotsessi ja loodava toote kvaliteedi kohta. Nii tootmisprotsessi kui ka tooteid hinnatakse ja kontrollitakse kvantitatiivsest aspektist.

5. tase "Optimeerimine". Protsessi pidev täiustamine saavutatakse kvantitatiivse abil tagasisidet protsessiga ning arenenud ideede ja tehnoloogiate rakendamisega selles.

Vaatamata ranguse puudumisele ei tekita ülaltoodud määratlus intuitiivselt enamasti vastuväiteid. Veelgi enam, kogenud spetsialistid mõistavad, miks on üleminekud võimalikud ainult järgmisele tasemele, aga ka seda, miks tasub sellise ülemineku poole üldse pingutada. Samas ei sisalda HMM-mudel sellise lähenemise kvantitatiivset ega isegi formaalset põhjendust, mis aga selle eeliseid ei kahanda.

Edasi, nagu öeldakse, on tehnoloogia küsimus. Määratletakse mudeli struktuur (joonis 7.1), antakse definitsioonid ja hakatakse vaeva nägema iga protsessi täpselt kirjeldama igal tasandil. Selleks, et hinnata tehtu praktilist väärtust, käime osa sellest teest läbi.

Riis. 7.1.

Joonisel fig. 7.1 sisaldab järgmisi mõisteid.

Võtmeprotsesside rühm. Nagu on öeldud (Paulk et al., 1995), "iga võtmeprotsesside rühm määratleb seotud tegevuste ploki, mille tulemusena saavutatakse eesmärkide kogum, mis on tootmisprotsessi tootlikkuse tõstmiseks olulised. näiteks võtmeprotsesside rühma jaoks " Nõuete haldamine"(Vt joonis 7.2) eesmärk on ühildada tarkvara arendusprojekti nõuded kliendi ja arendaja vahel."

CMM-is pole üksikuid protsesse. Selle asemel on üksikud tööd, mida nimetatakse võtmepraktikateks (vt allpool), mis on omavahel ühendatud sisendite ja väljundite kaudu ning toimivad ehitusprotsesside lähtematerjalina. CMM ei anna juhiseid protsesside struktureerimiseks, st peamiste tavade sidumiseks loogilisteks järjestusteks. Võtmepraktikate komplekte nimetatakse võtmeprotsessirühmadeks.

Riis. 7.2.

Võtmeprotsesside rühmad CMM-is on kaardistatud küpsustasemetele (joonis 7.2), st kõik ühe taseme praktikad suhtlevad ainult üksteisega ja ei suhtle teiste tasandite praktikatega. See võimaldab tagada kõigi protsesside täieliku toimimise konkreetsel tasemel ja seega korreleerida taseme organisatsiooni lõppenud arenguetapiga.

Omadussõna "võti" viitab sellele, et neid on protsessi rühmad(st praktikate kogumid), mis ei ole konkreetse küpsusastme seisukohalt võtmetähtsusega, st ei ole seotud selle taseme eesmärkide saavutamisega (vt allpool). HMM-mudel ei kirjelda kõike protsessi rühmad seotud tarkvara arendamise ja hooldusega. See kirjeldab ainult neid rühmi, mis on määratletud tootmisprotsessi tootlikkuse võtmeteguritena.

Eesmärgid. CMM-i eesmärgid ei ole seotud protsessidega, vaid võtmeprotsesside rühmadega. Nagu eespool mainitud, saavutatakse eesmärgid võtmepraktikate rakendamise kaudu. CMM-is tähendab eesmärgi saavutamine seda, et esiteks saavutatakse pärast võtmepraktikate rakendamist soovitud tulemus ja teiseks saadakse see üsna järjepidevalt. Võtmeprotsessirühma eesmärkide saavutamise viis võib projektiti erineda, tulenevalt erinevustest ainevaldkond või keskkond.

Kui need eesmärgid realiseeruvad kõigi projektide puhul, tähendab see, et organisatsioon on jõudnud tootmisprotsessi küpsusastmeni, mis on korrelatsioonis selle võtmeprotsesside rühmaga.

Peatükk. Sektsioonid (neid on igal tasandil viis ja need on alati samad) esindavad võtmeprotsesside rühmade omadusi, mida tuleb vastaval tasemel realiseerida. Need omadused kirjeldavad, kuidas protsesse rakendatakse ja mil määral on need organisatsioonis legaliseeritud, st ametlikult kinnitatud ja kooskõlastatud ettevõtte protseduuride, poliitikate ja muude protsessidega. Siin on viis jaotist.

Täitmiskohustused

Kirjeldage tegevusi, mida organisatsioon peab tegema, et tagada protsessi väljakujunemine ja stabiilsus. Tulemuslikkuse kohustused on tavaliselt seotud organisatsiooni poliitikate kehtestamisega ja tippjuhtkonna toega.

Eeldused

Kirjeldage eeldusi, mis peavad olema projektis või organisatsioonis täidetud tootmisprotsessi pädevaks rakendamiseks; tavaliselt seotud ressursside, organisatsiooniliste struktuuride ja nõutava koolitusega.

Toimingud pooleli

Jaotises Tegevused pooleli kirjeldatakse sisulist tööd, mida sellel tasemel tuleb teha. Tehtavad toimingud hõlmavad tavaliselt plaanide koostamist ja konkreetsete toimingute elluviimist, tööde teostamist ja jälgimist ning vajadusel parandusmeetmete võtmist.

Mõõtmised ja analüüsid

Jaotis "Mõõtmised ja

„Iga võtmeprotsesside gruppi väljendavad võtmepraktikad, mille rakendamine aitab kaasa grupi eesmärkide saavutamisele.Võtmepraktikad kirjeldavad infrastruktuuri ja toiminguid, mis aitavad enim kaasa võtmeprotsesside rühma efektiivsele rakendamisele ja loomisele.

Iga põhipraktika koosneb ühest lausest, millele sageli järgneb üksikasjalikum kirjeldus, mis võib sisaldada näiteid ja täpsustusi. Võtmetavad, mida mõnikord nimetatakse ka tipptaseme võtmepraktikateks, kehtestavad põhiprotsesside rühma põhipoliitikad, protseduurid ja toimingud. Üksikasjaliku kirjelduse komponente nimetatakse sageli alampraktikateks."

Põhitavad kirjeldavad, MIDA tuleb teha, kuid neid ei tohiks võtta dogmana selle kohta, KUIDAS eesmärke saavutada. Võtmeprotsessirühma eesmärgid on saavutatavad alternatiivsete praktikate kaudu. Võtmepraktikate tõlgendamine peaks olema mõistlik, võimaldades saavutada võtmeprotsesside rühma eesmärgid tõhus viis, kuigi võib-olla formaalselt ja erineb soovitatud CMM-ist.

Pilk IT-juhtimise tegevustele, milles protsesside asemel arvestatakse nende komponente - võtmepraktikaid ning protsessid on olemas vaid virtuaalselt, kui võtmepraktikatest ülesehitatavale asjale, tundub esmapilgul mõneti eksootiline. Seni lahendati IT-juhtimise täiustamise ülesanne võrdlusprotsessi mudelist valmisprotsesside kasutuselevõtuga. Nüüd on olemas tasemete komplekt, mis sisaldab erinevaid (st protsessidesse integreerimata) põhipraktikaid, ja soovitatavat järjestust tasandite vahel liikumiseks. IT-juhtimine paraneb CMM-i sõnul, kui see liigub kõrgemale küpsustasemele. Mis selle reklaamiga saab?

Tasemete definitsioonides (vt joonis 7.2) ilmus selline asi nagu "tootmisprotsess". See on olemas ka võtmeprotsesside rühma määratluses ja see pole juhus. Tootmisprotsess või nagu seda CMM-is tabavalt nimetatakse, standard Tootmisprotsess Organisatsioonid (OSS) on kogu mudeli üks keskseid kontseptsioone.

Novembris 1986 alustas American Software Engineering Institute (SEI) koostöös Mitre Corporationiga tarkvaraarenduse protsesside küpsuse ülevaate väljatöötamist, mille eesmärk oli aidata parandada nende sisemisi protsesse.

Selle ülevaate väljatöötamise ajendiks oli USA föderaalvalitsuse taotlus tarkvaraarenduse alltöövõtjate hindamise meetodi kohta. Tõeline probleem oli suutmatus majandada suured projektid. Paljudes ettevõtetes viidi projektid üle märkimisväärselt hilinemisega ja üle eelarve. Sellele probleemile oli vaja lahendus leida.

Septembris 1987 andis SEI välja lühike ülevaade tarkvaraarenduse protsessid koos nende küpsustasemete kirjeldusega, samuti küsimustik, mille eesmärk on tuvastada ettevõttes valdkonnad, milles on vaja parandusi. Enamik ettevõtteid pidas seda küsimustikku siiski valmis mudeliks, mille tulemusena muudeti 4 aasta pärast küsimustik reaalseks mudeliks, tarkvara võimekuse küpsusmudeliks (CMM). 1991. aastal välja antud CMM-i esimene versioon (versioon 1.0) vaadati 1992. aastal üle töökoosolekul, millest võttis osa umbes 200 tarkvaraspetsialisti, ja arendajate kogukonna liikmed.

1. Elementaarne. Organisatsiooni kõige primitiivsem staatus. Organisatsioon on võimeline tarkvara arendama. Organisatsioonil puudub selgesõnaliselt teadlik protsess ja toote kvaliteedi määravad täielikult arendajate individuaalsed võimed. Üks võtab initsiatiivi ja meeskond järgib tema juhiseid. Ühe projekti edu ei taga teise edu. Projekti lõppedes ei fikseerita andmeid tööjõukulude, ajakava ja kvaliteedi kohta.
2. korratav. Mingil määral jälgitakse protsessi. Tööjõukulude ja plaanide kohta tehakse arvestust. Iga projekti funktsionaalsust kirjeldatakse kirjalikult. 1999. aasta keskel oli ainult 20% organisatsioonidest tasemel 2 või kõrgem.
3. Paigaldatud. Omama määratletud, dokumenteeritud ja kehtestatud protsess töö üksikisikutest sõltumatult. See tähendab, et nõus kutsestandardid ja arendajad rakendavad neid. Sellised organisatsioonid suudavad üsna usaldusväärselt prognoosida varem lõppenud projektidega sarnaste projektide kulusid.
4. Hallatud. Nad suudavad täpselt ennustada töö aega ja maksumust. Olemas on akumuleeritud mõõtmiste andmebaas. Kuid uute tehnoloogiate ja paradigmade esilekerkimisega muutusi ei toimu.
5. Optimeeritud. Käimas on protseduur uute ja täiustatud meetodite ja vahendite leidmiseks ja valdamiseks.

Areng

Mudeli kasutamine praktikas näitas tarkvaraarendusprotsesside kõrgema organiseerituse taseme saavutamise lähenemisviiside ebaselgust. Seetõttu töötatakse 2002. aastaks välja soovitused arendusprotsessi parandamiseks, mida nimetatakse CMMI (võimekuse küpsusmudeli integreerimine). Praegu Uusim versioon CMMi - 1.3 (avaldatud novembris 2010) .

Vaata ka

Lingid

MIT üliõpilaste foorum > põhijaotis > testid > juhtimissüsteemide simulatsioon

Vaade täisversioon: Juhtsüsteemide simulatsioon

Lahendasin kõik moodulid, läbisin kõik 4-ga ja lõpliku 2-ga, nüüd kolme päeva pärast proovin uuesti läbida, polnud ühtegi identset küsimust. Üritasin lõputesti parandada, aga kontrollige, õigsuse eest ei saa garanteerida. Avaldan kõik, mis mul on, äkki keegi läbib selle minust paremini. Kui kellelgi on teine, kolmas katse, siis pane vastu, kui ei pahanda, distsiplineeri, tõesti väga raske.:eek:

Lõpukatse 100 100-st

Kas tulemus on iga kord erinev?

Veel küsimusi, mida siin pole loetletud ja mis mind haarasid. Vastuseid ma ei otsinud, sest ilma selleta sain 4. Kes tahab segaduses olla, laadige ülejäänud vastused siia 🙂

1. moodul:
Mida ei tohiks pidada äriprotsessi tunnuseks?

Lisaväärtus

Valige üks vastus:
Protsessi produkt, mis kehastab eelnevalt seatud eesmärke

Valige üks vastus:

Finaalis (edasi 4.

Mis on võimekuse küpsuse mudel? (CMM)

Need küsimused + need, mis juba foorumis on):
1. Valige õige väide.
Valige üks vastus:
Osakondade äriprotsess koosneb erinevatest väärtusahelatest (UNSURE)
Läbiv äriprotsess koosneb äriprotsessidest erinevad organisatsioonid
Ristfunktsionaalne äriprotsess koosneb reeglina osakondade äriprotsessidest

2. Mis ei ole universaalse äriprotsessi vooskeemi element?
Valige üks või mitu vastust:
Protsessi ressursid
Riskid
Äriprotsesside juhtimise tegevused
Keskkonnategurid
Tegevus sisendite teisendamiseks väljunditeks

3. Materiaalsed ressursid protsesside põhielemendina on:
Valige üks vastus:
Aktiivsed tegevussubjektid on ühendatud süsteemides, mis suhtlevad üksteise ja teiste ressurssidega
Kontrollige tegevussubjektide poolt tegevusobjektidele suunatud tegevusi, mis määravad protsesside eesmärgid ja tulemused
Protsesside läbiviimiseks kasutatavad passiivsed rajatised ja tegevused (POLE KINDEL)

28.03.2014, 10:07

1. moodul:
Mida ei tohiks pidada äriprotsessi tunnuseks? Valige üks või mitu vastust:
Sisendite teisendamine väljunditeks
Toote tarnimine välistarbijale
Lisaväärtus
Ülejäägi ja/või kasutusväärtuse teke

Tulemused protsesside põhielementidena on:
Valige üks vastus:
Aktiivsed tegevussubjektid on ühendatud süsteemides, mis suhtlevad üksteise ja teiste ressurssidega
Protsessi toode, mis kehastab eelnevalt seatud eesmärke Protsesside läbiviimiseks kasutatavad passiivsed rajatised ja tegevused
Protsessi lõpuleviimiseks vajalik materjali-, energia- ja infoobjektide kogum

Mis on tagasiside äriprotsessis?
Valige üks vastus:
Protsessi sihipärane ja teadlik mõjutamine, mille eesmärk on tagada soovitud tulemus
Protsessi tulemuste analüüs ja võrdlemine eelnevalt seatud eesmärkidega
Mõju objektide süsteemile ja keskkonnateguritele, mis on mitmesuguste kõrvalekallete allikad süsteemi toimimises
Vastasin nii! aga välja tuli ikkagi 4

Finaalis - need küsimused + need, mis on juba olemas:
1 Valige loendist projekteerimis-sihtstruktuuride puudused.

2 Valige loendist näited käskude kasutamise kohta.
Kvaliteetsed kruusid
komiteed
Töörühmad

3 Valige loendist orgaaniliste organisatsiooniliste struktuuride rakendamise tingimused.
Töötajaid motiveerivad keerulised vajadused
Eesmärgid on hägused ja muutuvad dünaamiliselt
Võimu seatakse kahtluse alla ja katsetatakse, nõuab alluvate kinnitust

4 Valige loendist projektipõhiste organisatsioonistruktuuride eelised.
töötajate otsene allutamine projektijuhile ja seeläbi saavutatakse nende töötajate jõupingutuste suuna üheselt mõistetavus

5 toetavad protsessid:
Pakkuda tõhusat rakendamist peamised protsessid

Lõplik hinne 5
küsimus 1
Valige käskude kasutamise näidete loendist.

Kvaliteetsed kruusid
komiteed
Töörühmad

2. küsimus
Milleks funktsionaalses struktuuris vahendajaid kasutatakse?

Integreerida erinevate struktuuriüksuste tegevusi

3. küsimus
Nimetage SADT mudeli seoste tüübid:
Kontroll
väljumismehhanism
Sisend tagasiside

4. küsimus
Milline järgmistest äriprotsessidest on kõige lühem?
Osakonna äriprotsess

5. küsimus
Milliseid meetodeid, metoodikat ja tööriistu saab kasutada äriprotsesside infomudelite loomiseks?

Gein-Sarsoni metoodika
Cheni ja Barkeri modelleerimiskeel

6. küsimus
Milline äriprotsesside esitus vastab madalaimale tasemele (loetletutest)?

Äriprotsesside toimingud

7. küsimus
Äriprotsessi pikkus:

See on subjektiivne

8. küsimus
Materiaalsed ressursid protsesside põhielemendina on:

Protsesside läbiviimiseks kasutatavad passiivsed vahendid ja tegevusobjektid

9. küsimus
Valige loendist projektipõhiste organisatsioonistruktuuride eelised.

Rakendatakse töötajate otsest allumist projektijuhile ja seeläbi saavutatakse nende töötajate jõupingutuste suuna üheselt mõistetavus

10. küsimus
Valige loendist maatriksorganisatsiooni struktuuride eelised.

Võimalus paindlikult kohandada organisatsiooniline struktuur laias spektris: nõrgast tugeva maatriksini

11. küsimus
Mida hõlmab ärisüsteemi haldamise teine ​​ahel?

Töö juhtimise allsüsteem
arendusjuhtimise allsüsteem

12. küsimus
Ärisüsteemi üldine protsessimudel sisaldab järgmisi elemente:

Välju
protsessi
Sissepääs
Häirimine

13. küsimus
Milline IDEF-standard võimaldab modelleerida tegevusi, voogusid ja objektide olekut?

14. küsimus
Millised on projektijuhi volitused tugevas maatriksstruktuuris?

Keskmine kuni kõrge

15. küsimus
Mida saab seostada investeerimis- ja finantsprotsesside põhielementidega?

Investorid
Laenuandjad

16. küsimus
Valige loendist projekteerimis-sihtstruktuuride puudused.

Vähendatud valmistatavus funktsionaalsetes piirkondades

Control Systems Modeling.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

Milline on domineerimise järjekord SADT diagrammidel?
Vastus: Kõige domineerivamad funktsioonid asuvad vasakus ülanurgas.

abi 3koolitus kellel see on pliz

Lisatud 1 minuti pärast
Palun 3 koolitust kõigilt, kellel on juhtimissüsteemide modelleerimine

vBulletin® v3.8.7, autoriõigus 2000–2018, vBulletin Solutions, Inc.

Tõlge, mida saate öelda:

IS arendamise metoodika. CMM/CMMI küpsusmudel.

1991. aastal ülikooli Tarkvaratehnika instituut

Carnegie Mellon (Software Engineering Institute, SEI) lõi tarkvaratoodete arendamiseks CMM küpsusmudeli (Capability Maturity Model). Aja jooksul on välja antud terve perekond mudeleid:

SW-CMM - tarkvaratoodete jaoks, SE-CMM - süsteemide projekteerimiseks, Acquisition CMM - hankeks, Inimesed CMM - personalijuhtimiseks, ICMM - toodete integreerimiseks.

Erinevaid mudeleid oli üsna raske mõista ja rakendada. Alates nende loomisest erinevad rühmad spetsialistid, ei olnud nende mudelite sisu alati üksteisega kooskõlas

rahvusvaheliste standardite nõuetele. Seetõttu avaldas SEI 2002. aastal uue CMMI mudeli (Capability Maturity Model Integration), kombineerides varem välja antud mudeleid ja võttes arvesse nõudeid.

rahvusvahelistele standarditele. CMMI on mudelite (metoodikate) kogum protsesside täiustamiseks erineva suuruse ja tegevusalaga organisatsioonides. CMMI eristab järgmisi parendusvaldkondade rühmi: protsessijuhtimine, projektijuhtimine, insenerivaldkonnad, teenindus

alad. Sel juhul on kõik valdkonnad määratletud nõuete kujul, mis määravad mitte nende rakendamise, vaid liidesenõuded. Sellest on kaks tagajärge.

Tagajärg 1. CMMI võimaldab erinevaid teostusi ja ei ole tarkvaraarendusmetoodika nagu MSF, Scrum, RUP jne. Viimast saab selle juurutamisel kasutada. Näiteks on VSTS-is CMMI jaoks spetsiaalne protsessimall nimega MSF for CMMI.

Järeldus 2. CMMI-d kasutatakse ettevõtete protsesside küpsuse sertifitseerimiseks. Esialgu, 80ndate lõpus ja 90ndate alguses, loodi CMM (siis veel mitte CMMI) just sertifitseerimisvahendina.

föderaalsed alltöövõtjad. Ja alles hiljem, olles maailmas laialt levinud, hakati seda kasutama ja seejärel keskenduma protsesside täiustamisele. Märgime veel ühe oluline omadus CMMI. See ei ole mõeldud ainult tarkvarasüsteemide arendamiseks. Palju suured ettevõtted nad ei tooda mitte tarkvara, vaid sihttooteid, mille lahutamatuks osaks on tarkvara.

Näiteks lennundus, kosmosetööstus. See tähendab tarkvaraarendust

toimub koos muud tüüpi inseneritöödega. Ja sageli juhtub, et ühte projekti on kaasatud rohkem kui kaks erinevat tüüpi inseneritööd. CMMI ülesanne on pakkuda sellistele projektidele ja ettevõtetele ühtset platvormi arendusprotsessi korraldamiseks.

Erinevalt klassikalisest CMM-i mudelist, mis oli rangelt hierarhiline ja võimaldas ainult protsesside järjestikust täiustamist tasemete kaupa, on CMMI mudelil kaks mõõdet - järjestikune, näiteks

sama mis CMM-is ja pidev, võimaldades suvaliselt mingil määral organisatsiooni protsesse täiustada. Siin keskendume järjestikune mudel. Sellel on 5 taset

protsessi küpsus (joon. 1).

Esimene tase(küpsusaste 1) on tase, millel definitsiooni järgi on mis tahes ettevõte. Sellel tasemel on tarkvaraarendus enam-vähem kaootiline.

Hallatud tase(küpsusaste 2) - siin ilmuvad juba ettevõtte tasemel kinnitatud protsesside korraldamise poliitikad ja protseduurid. Kuid protsesside täielik ulatus eksisteerib ainult üksikute projektide raames.

Teatud tase(küpsusaste 3) - siin ilmneb standardprotsess kogu ettevõtte kui terviku tasemel.

Mis on võimekuse küpsusmudel (CMM)? Mis on CMM-i tasemed?

See on suur ja pidevalt kasvav protsessivarade komplekt: dokumendimallid,

olelustsükli mudelid, tarkvaratööriistad, tavad jne. Iga konkreetne protsess saadakse sellest standardist lõikamise teel.

Kvantitatiivne tase(küpsusaste 4) eeldab mõõtmissüsteemi tekkimist ettevõttes, mis toimuvad standardse protsessi alusel ja võimaldavad arengut kvantitatiivselt juhtida.

Optimeerimise tase(küpsusaste 5) tähendab arendusprotsesside pidevat täiustamist, nii järkjärgulist, inkrementaalset kui ka revolutsioonilist. Samas pole need muudatused pealesunnitud, vaid proaktiivsed probleemid ja raskused. Protsessi täiustatakse iseenesest ja pidevalt on rakendatud vastavaid mehhanisme.

Paljud teavad lühendit CMMI, paljud teavad, et tegemist on mudeliga, st. soovituste kogum, kuidas parandada näiteks tarkvaraarendusega seotud protsesse. Kuid vähesed inimesed teavad, et CMMI mudeleid on mitu. Tuntuim neist on CMMI for Development (CMMI-DEV), mis on tõesti paljuski seotud arendusettevõtete tegevusega (st need ettevõtted ja organisatsioonid, kes arendavad ja tarnivad teatud tarkvaratoodet või muud keerulist tarkvara ja riistvara lahendus).

Aga kuidas on lood nendega, kes tarnivad mitte toodet, vaid teenuseid (näiteks tootetugi, mille arenduse osakaal tööjõu kogukuludes on tühine või puudub tööjõukulu üldse)? Nende jaoks on ka rida soovitusi - CMMI for Services mudel (CMMI-SVC). Näiteks IT-osakondade jaoks võib see mudel (täpsemalt selle soovitused) aidata mõista, mida tuleb teha, et näiteks samad ITIL-i soovitused muutuksid tavapäraseks protsessiks, mitte mingiks "pühaks praktikaks".

Võimekuse küpsusmudel (CMM)

On uudishimulik, et selle mudeli soovitused on üsna universaalsed ega "sulgu" ainult Infotehnoloogia. Selle mudeli praktikate piloottutvustus toimus ... ühes USA haiglas (arstiabi on ju ka teenus).

Siiski on parem õppida mõnda loetletud mudelitest. Ja kui CMMI-DEV mudelis on koolitatud mitusada inimest kogu SRÜ jaoks (umbes 250-300 inimest), siis SRÜ-s on CMMI-SVC mudelis koolitatud ainult 6 inimest. Me räägime koolitatutest, mitte juhendajatest. Täpselt see põhiprobleem oli kuni 2011. aasta detsembrini: CMMI-DEV-i jaoks oli kogu maailmas ainult üks vene keelt kõnelev SEI (CMMI mudeliarendaja) poolt sertifitseeritud instruktor, teiste mudelite puhul aga mitte ühtegi! Nüüd on selline juhendaja ka CMMI-SVC mudeli järgi tekkinud (seega esimesed 6 koolitatud). See juhendaja on selle väljaande autor, kes on valmis vastama kõigile mainitud mudelite ja ametliku koolituse kohta käivatele küsimustele. Küsi!

See materjal on Club.CNewsi kogukonna liikme privaatne rekord.
CNewsi toimetajad ei vastuta selle sisu eest.

Vaatleme kvaliteedi tagamise mudelite arengut protsessi küpsusmudeli või võimsuse parandamise mudeli alusel. CMM (Capability Maturity Model). Kuigi modell SMM on suunatud tarkvara kvaliteedi tagamisele, selle metoodilised aspektid on rakendatavad mis tahes toote (kaubad, tööd, teenused) kvaliteedi tagamise mudelitele.

Peamine mudelis SMM on organisatsiooni küpsuse mõiste.

ebaküps peetakse organisatsiooniks, milles tarkvara arendusprotsess sõltub ainult konkreetsetest tegijatest ja juhtidest ning otsused tehakse sageli "lennult". Sel juhul on eelarve ületamise või projekti täitmata jätmise tõenäosus suur ning seetõttu on juhid sunnitud tegelema vaid koheste probleemide lahendamisega.

Küpsed Organisatsioon loetakse vastavaks järgmistele tingimustele:

• – tarkvaratoodete loomiseks ja projektijuhtimiseks on täpselt määratletud protseduurid, mida täiustatakse ja täiustatakse pilootprojektid"kulu - kasum" komponentide analüüsimisega;
• – hinnangud tööde teostamise aja ja maksumuse kohta põhinevad kogunenud kogemustel ja on seetõttu üsna täpsed;
• – ettevõttel on standardid tarkvara arendamise, testimise ja juurutamise protsesside kohta, reeglid lõpliku programmikoodi, komponentide, liideste jms kujundamiseks. Kõik see moodustab infrastruktuuri ja ärikultuuri mis toetab tarkvara arendusprotsessi.

Nii et standard SMM on kvaliteedi tagamise mudel, mis koosneb organisatsiooni küpsuse hindamise kriteeriumidest ja retseptidest olemasolevate protsesside täiustamiseks. Mudelis SMM määratletakse viis organisatsioonide küpsusastet, mille tunnused on toodud joonisel fig. 5.3.

Riis. 5.3. Viis mudeli küpsusastetSMM

Esimene tase (esialgne tase) on aluseks ettevõtte arengule järgmistel tasanditel. Arvatakse, et organisatsiooni algtaseme ettevõttes pole kvaliteetse tarkvara loomiseks stabiilseid tingimusi. Järelikult sõltub iga projekti tulemus täielikult juhi isikuomadustest ja programmeerijate kogemustest. See tähendab, et ühe projekti edu saab korrata vaid siis, kui järgmisesse projekti on määratud samad juhid ja programmeerijad. Kui aga projektides kogemusi omandanud juhid või programmeerijad lahkuvad ettevõttest, siis nende lahkumisega langeb toodetava tarkvara kvaliteet järsult.

Tuleb tunnistada, et algtasemel on stressirohketes olukordades suur sõltuvus inimfaktor arendusprotsess taandub koodi kirjutamisele ja selle minimaalsele testimisele.

Teise saavutamine korratav tase (korduv tase) on määratud projektijuhtimise tehnoloogia rakendamisega ettevõttes. Planeerimine ja projektijuhtimine ettevõttes põhineb kogutud kogemustel, arendatud tarkvarale on olemas ja kasutatakse standardeid, mille täitmist kontrollib spetsiaalne kvaliteeditagamisgrupp. Arvatakse, et teine ​​tase võib pakkuda nii võimalusi edasiseks täiustamiseks (kolmandale tasemele üleminek) kui ka ei välista võimalust tarkvara arendusprotsessi kvaliteedi regressiivseks naasmiseks algtasemele kriitilistes tingimustes.

Kolmandaks teatud tase (määratletud vasakul) mida iseloomustab tõsiasi, et tarkvara loomise ja hooldamise standardprotsess on täielikult dokumenteeritud alates tarkvaraarendusest kuni projektijuhtimiseni. Selle taseme juurutamise hüpotees on, et standardimise käigus liigub ettevõte kõige tõhusamate tavade ja tehnoloogiate poole. Tarkvaraarenduse ja projektijuhtimise standardite loomiseks ja toimimise säilitamiseks organisatsioonis tuleks luua spetsiaalne rühm. Kolmandale tasemele jõudmise eelduseks on pideva professionaalse arengu ja töötajate koolituse programmi olemasolu ettevõttes. Arvatakse, et alates sellest tasemest lakkab organisatsioon sõltumast konkreetsete arendajate omadustest ega kipu stressiolukordades libisema madalamale tasemele.

Neljandal, juhitud tase (hallatud tase) ettevõte kehtestab kvantitatiivsed kvaliteedinäitajad - nii tarkvaratoodetele kui ka nende loomise protsessidele üldiselt. Seega saavutatakse parem projektijuhtimine, vähendades erinevate projektinäitajate hälbeid. Samal ajal eraldatakse rakendatud tarkvara arendusprotsesside tähenduslikud (signaal)variatsioonid ja protsessi juhuslikud (müra)variatsioonid.

viies (kõrgeim), optimeerimise tase (optimeerimise tase) mida iseloomustab asjaolu, et parendusmeetmeid rakendatakse mitte ainult olemasolevatele protsessidele, vaid ka uute tehnoloogiate kasutuselevõtu tõhususe hindamiseks. Ettevõtte peamine ülesanne sellel tasemel on olemasolevate protsesside pidev täiustamine. Samas peaks protsesside täiustamine aitama ennetada võimalikud vead ja defektid. Samal ajal tuleks teha tööd tarkvaraarenduse kulude vähendamiseks.

5 evolutsioonilist etappi organisatsiooni protsesside juhtimises. Võimeküpsuse mudeli selgitus. CMM

CM-CEI võimekuse küpsuse mudel on organisatsioonimudel, mis kirjeldab 5 arenguetappi (taset), millel organisatsioonis protsesse juhitakse.

Algselt tarkvaraarenduse jaoks loodud võimekuse küpsuse mudeli mõte seisneb selles, et organisatsioon peaks olema võimeline oma tarkvararakendusi vastu võtma ja toetama. Mudel pakub välja ka konkreetseid samme ja algatusi, mis aitavad organisatsioonil järgmisele tasemele tõusta.

Võimekuse küpsuse mudeli 5 etappi

Esialgne (protsessid on ad hoc, kaootilised või tegelikult on neid määratletud vähesed) Korratav (põhiprotsessid on paika pandud ja nendele protsessidele tuleb kinni pidada) Määratletud (kõik protsessid on määratletud, dokumenteeritud), ühtsed ja integreeritud) Hallatav ( protsesse mõõdetakse protsesside ja nende kvaliteedi üksikasjalike andmete koondamise teel) Optimeerimine (pidev protsesside arendamine läbi kvantitatiivse tagasiside ning uute ideede ja tehnoloogiate testimise)

Tarkvaraarenduse mudel

CMM kirjeldab põhimõtteid ja tavasid, mis on tarkvaraprotsessi küpsuse kontseptsiooni aluseks. Need on loodud selleks, et aidata tarkvaraarendus- ja müügifirmadel oma tarkvaraprotsesse evolutsioonilisel viisil täiustada. Alustades ad hoc, kaootilistest protsessidest, liikudes edasi küpsete, distsiplineeritud tarkvaraprotsessideni. Keskendutakse peamiste protsessivaldkondade ja eeskujulike tavade väljaselgitamisele, mis võivad kujutada endast distsiplineeritud tarkvaraprotsesse. CMM-i küpsuse kontseptsioon loob konteksti, milles:

Harjutusi saab korrata. Kui te mõnda toimingut ei korda, ei tohiks te seda parandada. On olemas reeglid, protseduurid ja tavad, mis sunnivad organisatsiooni rakendama ja järjepidevalt täitma. Tootmistöö korraldamise parimaid praktikaid saab kiiresti rühmade vahel jagada. Tavad on määratletud nii, et võimaldada projektide vahelist vahetust, pakkudes seega organisatsioonile mõningast standardimist. Kõrvalekalded nende meetodite täitmisel on viidud miinimumini. Ülesannetele seatakse kvantitatiivsed eesmärgid; ja mõõtmised kehtestatakse, toodetakse ja säilitatakse, et olla hindamise aluseks. Tavasid täiustatakse pidevalt võimekuse parandamiseks (optimeerimine).

Võimekuse küpsuse mudel on kasulik mitte ainult tarkvaraarenduse jaoks, vaid ka organisatsioonide evolutsioonitasemete kirjeldamiseks üldiselt ja juhtimistaseme kirjeldamiseks, mida organisatsioon on rakendanud või soovib saavutada.

Funktsioonide arendusmudeli struktuur

Küpsustasemed on kihiline kontseptsioon, mis tagab pideva täiustamise saavutamiseks vajaliku distsipliini järjepidevuse. Siinkohal on oluline märkida, et organisatsioonis areneb võime hinnata uue praktika, tehnoloogia või tööriista tagajärgi. Seetõttu ei ole küsimus nende uuenduste aktsepteerimises, vaid pigem selles, kuidas need uuenduslikud jõupingutused olemasolevaid tavasid mõjutavad. See toetab projekte, rühmitusi ja organisatsioone, andes neile aluse teadlike valikute tegemiseks. Võtmeprotsessivaldkonnad – võtmeprotsesside valdkond (KPA) määratleb seotud tegevuste rühma, mis koos sooritades saavutavad mitmeid olulisi eesmärke. Eesmärgid – võtmeprotsessi valdkonna eesmärgid kirjeldavad sätteid, mis peavad selle võtmeprotsessi valdkonna jaoks olemas olema. Eeskirju tuleb rakendada tõhusal ja turvalisel viisil. Eesmärkide saavutamise ulatus näitab, millise võimekuse organisatsioon on sellel tipptasemel loonud. Eesmärgid piiritlevad iga võtmeprotsessi valdkonna ulatuse, piirid ja eesmärgi. Üldised omadused – üldtunnused hõlmavad tavasid, mis juurutavad ja institutsionaliseerivad peamisi protsessivaldkondi. Need 5 tüüpi üldised omadused hõlmavad järgmist: täitmiskohustus, suutlikkus sooritada, teostatavad algatused, mõõtmine ja analüüs ning rakendamise kontroll. Võtmetavad – võtmepraktikad kirjeldavad infrastruktuuri elemente ja praktikaid, mis aitavad kõige tõhusamalt kaasa peamiste protsessivaldkondade rakendamisele ja institutsionaliseerimisele.

Protsessi määratlemise kriteeriumid

Protsessi määratlemise kriteeriumid on protsessi elementide kogum, mis tuleb lisada tarkvara protsessi kirjeldusse, et inimesed saaksid neid praktikas kasutada. Kriteeriumide seadmiseks peate esitama küsimuse - "Millise teabe kohta tarkvara protsess vajalik dokumenteerimiseks?