Prezantimi

Pjesa më e rëndësishme e sistemeve komplekse moderne janë produktet softuerike - komponenti intelektual. Produktet softuerike tani përdoren për të zgjidhur problemet e menaxhimit në pothuajse të gjitha fushat e veprimtarisë njerëzore: në ekonomi, sociale, ushtarake dhe fusha të tjera. Siguria Cilesi e larte produkte softuerike vendase me të tyre zhvillim masiv dhe furnizimi për aplikime të ndryshme në vend dhe në tregun botëror është kthyer në një objektiv strategjik.

Aktualisht, ekzistojnë dy fusha pothuajse të pavarura të standardizimit në inxhinierinë e softuerit dhe sigurimin e cilësisë së produkteve softuerike, të cilat mund të quhen me kusht profilet e standardeve ISO (Organizata Ndërkombëtare e Standardeve) dhe modelet e pjekurisë SEI (Instituti i Inxhinierisë së Softuerit të SHBA). Të parat përfaqësohen plotësisht në [ , ] dhe të dytat - në [ , ]. Përmbajtja kryesore e artikullit i kushtohet modeleve të maturimit.

Për të siguruar konkurrencën në botën e produkteve softuerike komplekse dhe mundësinë e eksportit të tyre të suksesshëm, ato duhet të zhvillohen dhe certifikohen në përputhje me kërkesat. profile të standardeve ndërkombëtare në bazë ISO 9000:2000 ose modelet e maturimit - CMMI: 2003(Capability Maturity Model Integration - Integrated Software Engineering Mature Model vlerësimi i maturitetit). Këto dy drejtime metodologjikisht janë shumë të afërta dhe pjesërisht kryqëzohen përmes referencave të ndërsjella.

Përmirësimi i treguesve tekniko-ekonomikë dhe i cilësisë së produkteve softuerike, si dhe parandalimi i gabimeve dhe defekteve, sigurohet nga përdorimi i teknologjive moderne inxhinieri softuerike dhe sistemet dizajn me ndihmën e kompjuterit. Këto janë teknologji me performancë të lartë, që kursejnë burime për krijimin e komplekseve softuerike me cilësi, besueshmëri dhe siguri të lartë, që synojnë uljen e kostos totale të burimeve për projektimin, zbatimin dhe mirëmbajtjen e mjeteve softuerike (PS). Për ta bërë këtë, para së gjithash, është e nevojshme të aplikohen metoda dhe mjete për analizë dhe projektim, duke siguruar konkretizimin dhe paraqitjen sa më të saktë të qëllimeve, qëllimeve dhe funksioneve që në fillim. cikli i jetes(LC) i PS dhe parandalimi i përhapjes së defekteve të mundshme të sistemit në fazat pasuese të zhvillimit. Teknologji të tilla inxhinierike softuerike bëjnë të mundur eliminimin ose uljen e ndjeshme të nivelit të gabimeve të sistemit, algoritmit dhe softuerit në produktet softuerike të transferuara për funksionim. Përveç kësaj, ato janë efektive në modifikimin dhe mirëmbajtjen e PS, si dhe në ndryshimet në mjedisin e jashtëm.

Për të vërtetuar cilësinë, besueshmërinë dhe sigurinë e përdorimit të sistemeve komplekse, kritike, produktet softuerike të përdorura në to i nënshtrohen certifikimit qendra testimi ose laboratorë të certifikuar, të orientuar drejt problemeve. Teste të tilla duhet të kryhen kur programet menaxhojnë procese komplekse, kritike ose përpunojnë informacione aq të rëndësishme sa defektet në to ose cilësia e pamjaftueshme mund të shkaktojnë dëme të konsiderueshme. Testet e certifikimit duhet të përcaktojnë përputhshmërinë e komplekseve softuerike me kërkesat e dokumentacionit dhe t'i lejojnë ata të funksionojnë brenda kufijve të ndryshimeve në parametrat e mjedisit të jashtëm të studiuar gjatë testeve. Këto lloj testesh karakterizohen nga ashpërsia dhe thellësia më e madhe e kontrolleve dhe duhet të kryhen nga specialistë të pavarur nga zhvilluesit dhe klientët (përdoruesit).

Baza për certifikim duhet të jenë programet dhe metodat e detajuara dhe efektive për testimin e paketave softuerike për pajtueshmëri me kërkesat e standardizuara të klientëve, problemet e testimit dhe gjeneratorët e projektuar posaçërisht për formimin e tyre, si dhe kualifikimi dhe autoriteti i lartë i testuesve. Aplikim tek ndërmarrjet-zhvillues të produkteve softuerike, sisteme cilësore të certifikuara për sigurimin e ciklit jetësor të PS bazuar në kërkesat ISO 9000:2000 ose CMMI: 2003, garanton menaxhim të cilësisë së lartë dhe të qëndrueshme të proceseve dhe produkteve të ciklit të tyre jetësor, dhe gjithashtu lejon në shumë raste të lehtësojë certifikimin e produktit përfundimtar të softuerit. Prandaj, klientët e projekteve komplekse softuerike priren të zgjedhin kontraktorët zbatues të cilët kanë certifikata që vërtetojnë aplikimin e tyre të sistemeve të sigurimit të cilësisë bazuar në profilet e përshtatura të standardeve ndërkombëtare ose modelet e maturimit.

Mangësitë në mësimdhënien e metodave të inxhinierisë softuerike lënë një fushë të gjerë për arbitraritetin e specialistëve në vlerësimin e cilësisë së punës së tyre, si dhe për shfaqjen e defekteve dhe gabimeve të shumta në projektet softuerike. Kompleksiteti dhe përgjegjësia në rritje e detyrave moderne të zgjidhura nga programet, si dhe dëmtimi i mundshëm nga cilësia e pamjaftueshme e rezultateve të tyre, ka rritur ndjeshëm rëndësinë e metodave të zotërimit për një përshkrim të plotë, të standardizuar të kërkesave për karakteristikat e cilësisë dhe metodat e matjes. vlerat e tyre reale, të arritura në faza të ndryshme të ciklit jetësor të softuerit. Nevoja që specialistët të njohin konceptet, përkufizimet dhe metodat për vlerësimin e karakteristikave të cilësisë së produkteve softuerike është rritur ndjeshëm.

Rritja e shpejtë dhe ndërlikimi i komplekseve softuerike çon në krijimin e ekipeve të mëdha programuese me një ndarje profesionale të punës, në të cilën është e nevojshme të rregullohen aktivitetet e koordinuara të grupeve të specialistëve në një projekt të vetëm. Premtimet e zhvilluesve në kontrata për të ofruar softuer me cilësi të lartë brenda afateve kohore të dakorduara shpesh nuk mbahen. Shpesh kjo ndodh për faktin se klienti dhe kontraktori vlerësojnë nivelin e cilësisë sipas kritereve të ndryshme, dhe nuk kanë marrëveshje për këtë çështje, dhe qasja për vlerësimin e cilësisë së programeve nuk është mjaft e formalizuar. Përveç kësaj, ndonjëherë mungon aftësia për të vlerësuar siç duhet burimet e nevojshme për të arritur programe me cilësi të lartë. Si rezultat, cilësia e produkteve softuerike shpesh mbetet e ulët, jo e besueshme dhe jo konkurruese në tregun ndërkombëtar. Prandaj, problemi më i rëndësishëm në zhvillimin dhe zbatimin e shumë sistemet moderneështë trajnimi dhe edukimi i specialistëve në fushën e inxhinierisë softuerike, përdorimi i standardeve ndërkombëtare që kontribuojnë në cilësinë e lartë të softuerit dhe vlerësimin e besueshëm të tij me qëllimin kryesor - të bëjë procese projekti të menaxhueshme, dhe rezultatet janë e parashikueshme. Është e nevojshme të jeni në gjendje të formalizoni kërkesat dhe të arrini vlera specifike të karakteristikave të cilësisë së funksionimit dhe aplikimit të paketave komplekse softuerike, duke marrë parasysh burimet që janë në dispozicion për të siguruar dhe përmirësuar këtë cilësi.

Modeli i maturimit CMMI - 1.1 përpunon dhe përmirëson modelet e mëparshme CMM(shih ), dhe gjithashtu merr pjesërisht parasysh kërkesat themelore të standardeve ekzistuese ndërkombëtare në fushën e menaxhimit të softuerit. Vëmendje e konsiderueshme në CMMI i jepet proceseve të zhvillimit dhe llogaritjes së përsëritjeve kur ndryshojnë kërkesat e klientëve, gjurmueshmërinë e tyre ndaj funksioneve, komponentëve, testeve dhe dokumenteve të projektit. Kohët e fundit, janë shfaqur informacione për modernizimin e versionit SEI të versionit 2003. CMMI-1.1 bazuar në përvojën e grumbulluar dhe reagimet nga ndërmarrjet. Ai supozohet të nxjerrë në 2006 një version të ri, të përmirësuar ndjeshëm të modelit CMMI-1.2, pas së cilës versioni 1.1 duhet të hiqet gradualisht. Deri në fund të vitit 2007, përdoruesit duhet të kalojnë në versionin CMMI-1.2, dhe në të ardhmen do të bëhet i detyrueshëm për një vlerësim të zyrtarizuar të cilësisë (certifikimit) të teknologjisë së ndërmarrjes në fushën e inxhinierisë softuerike. Periudha e vlefshmërisë së certifikatës do të kufizohet në tre vjet. Klientët dhe zhvilluesit e sistemeve të mëdha softuerike duhet të përgatiten për këto ndryshime përpara publikimit zyrtar të versionit 1.2 nga SEI.

Struktura dhe përmbajtja e modelit të maturimit CMMI - 1.1

Dy opsione modeli CMMI-1.1 projektuar për të ofruar të vazhdueshme vlerësimi i një kompleksi procesesh në zonë të caktuar krijimi i softuerit ose me faza vlerësimin dhe përmirësimin e pjekurisë së ndërmarrjes, si dhe për organizimin e ciklit jetësor të komplekseve programore në përgjithësi. Modelet CMMI ofrojnë asistencë për specialistët në organizimin dhe përmirësimin e produkteve të tyre, si dhe në thjeshtimin dhe shërbimin e proceseve të zhvillimit dhe mirëmbajtjes së PS. Koncepti i këtyre modeleve mbulon menaxhimin dhe vlerësimin e pjekurisë së sistemeve komplekse, inxhinierinë softuerike, si dhe proceset e krijimit të produkteve të integruara softuerike dhe përmirësimin e zhvillimit të tyre. Komponentët e modeleve të vazhdueshme dhe me faza janë kryesisht të ngjashme, dhe mund të zgjidhen dhe aplikohen në një përbërje dhe sekuencë të ndryshme përdorimi, në varësi të vetive dhe karakteristikave të projekteve specifike.

Opsionet e përshkrimit të modelit ndërtohen sipas një skeme të vetme, e cila përfshin seksione të përgjithshme:

• parathënie;
• 1 seksion - hyrje;
• Seksioni 2 - modeli i komponentit;
• Seksioni 3 - terminologjia;
• Seksioni 4 - përmbajtja e niveleve dhe përbërësit kryesorë të secilit version të modelit (zhvillimi i qëllimeve dhe procedurave);
• Seksioni 5 - struktura e ndërveprimit të proceseve; katër kategoritë e proceseve në seksionin 7 janë shënuar, pasqyra e përgjithshme e tyre dhe skemat e ndërveprimit të proceseve CMMI:
  • menaxhimi i procesit;
  • menaxhim - menaxhim projektesh;
  • inxhinieri (teknologji);
  • mbështetje;
• Seksioni 6 - Përdorimi i Modelit CMMI- rekomandime të shkurtra për përdoruesit për aplikimin e modelit dhe trajnimin; vihet re përputhshmëria dhe përputhshmëria e proceseve të modelit me proceset e rregulluara të modelit të mëparshëm CMM në pjesët 2 dhe 3 të standardit ISO 15504.
• Seksioni 7 është i fundit, më i madhi në secilin standard, ai zë rreth 500 faqe të dokumentit total, që është mbi 700 faqe. Ky seksion ofron rekomandime të detajuara për zbatimin e secilit prej proceseve të listuara në të, të cilat marrin parasysh karakteristikat e një modeli të veçantë.

Opsioni i parë Modeli (i vazhdueshëm) pasqyron dokumentin: Integrimi i Modelit të Maturimit të Kapacitetit (CMMI) për Inxhinieri Sistemesh/Inxhinieri Softuerësh/Produkt i integruar dhe Zhvillimi i Procesit, Versioni 1.1, Përfaqësimi i Vazhdueshëm (CMMI-SE/SW/IPPD, V1.1, E vazhdueshme). Modeli i Vlerësimit të Pjekurisë së Inxhinierisë së Sistemit të Integruar/Inxhinierisë Softuerësh/Produkteve të Integruara dhe Procesit të Zhvillimit - pamje e vazhdueshme. Në këtë model, seksioni i shtatë përbëhet nga proceset:

• menaxhimi i procesit:
  • organizimi i trajnimit;
  • organizimi i transformimit (ndryshimeve) të proceseve;
  • organizimi i inovacioneve dhe zgjerimeve;
• menaxhimi i projektit:
  • planifikimi i projektit;
  • monitorimi dhe kontrolli i proceseve të projektit;
  • Menaxhimi i rreziqeve;
  • menaxhimi sasior i projektit;
• inxhinieri (teknologji):
  • menaxhimi i kërkesave;
  • zhvillimi i kërkesave;
  • zgjidhje teknike;
  • integrimi i produktit;
  • verifikimi;
  • vërtetimi (vërtetimi, miratimi);
• mbështetje:
  • menaxhimi i konfigurimit;
  • analiza dhe vendimmarrja për ndryshimet;
  • analiza e shkakut rrënjësor dhe zgjidhja e problemit (eliminimi i defektit).

Pesë shtojcat ofrojnë:

POR- përbërjen e burimeve dhe dokumenteve letrare të përdorura, të cilat, megjithatë, nuk përmendin standarde ISO;

AT- shkurtesat;

NGA- terminologji e bazuar në fjalor ISO përdoret vetëm në katër standarde ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - përshkrimet e kërkesave dhe propozimet për formimin e komponentëve të modelit sipas niveleve të maturimit;

E - lista e pjesëmarrësve në zhvillim CMMI- projekt.

Në këtë model, vëmendja përqendrohet në proceset organizative, në planifikimin, menaxhimin dhe kontrollin e proceseve për zbatimin e projekteve softuerike, në zhvillimin dhe menaxhimin e kërkesave për produktet softuerike. Më poshtë janë shembuj të detajeve në CMMI disa prej tyre.

Planifikimi i projektit në këtë si dhe në modelin e dytë përfshin:

• vlerësimi i madhësisë (shkallës) së mundshme të produktit softuer;
• vlerësimi i kompleksitetit të funksioneve dhe karakteristikave të projektit të PS;
• përcaktimi i modelit dhe fazave të ciklit jetësor të paketës softuerike;
• studimi i fizibilitetit të projektit - përcaktimi i kostos, intensiteti i punës dhe kohëzgjatja e ciklit jetësor të nënstacionit;
• zhvillimi i një plani pune me faza dhe buxheti i projektit;
• analiza, identifikimi dhe vlerësimi i rreziqeve të projektit;
• planifikimin dhe menaxhimin e dokumentacionit të proceseve dhe produkteve në ciklin jetësor të projektit PS;
• planifikimi dhe shpërndarja e burimeve teknike dhe njerëzore sipas fazave të ciklit jetësor të SP-së;
• planifikimi i ofrimit të njohurive dhe kualifikimeve të një ekipi specialistësh për zbatimin e projektit;
• përgjithësimi dhe analiza e grupit të planeve për projektin PS;
• koordinimi i punimeve dhe burimeve për fazat e ciklit jetësor nga zhvilluesi me klientin e projektit PS;
• dokumentimin e planit të punës dhe miratimin e tij nga menaxheri i zhvilluesit të projektit.

Proceset e zhvillimit të kërkesave për një produkt softuerësh janë të ngjashëm me proceset në të dy modelet dhe përfshijnë:

• identifikimi i nevojave reale të klientit dhe përdoruesve për funksionet dhe karakteristikat e produktit softuer;
• zhvillimi dhe koordinimi ndërmjet klientit dhe zhvilluesit të kërkesave fillestare, themelore për funksionet e produktit softuer;
• përcaktimi i burimeve në dispozicion dhe kufizimeve të projektit të paketës softuerike;
• zbërthimi i kërkesave fillestare bazë për funksionet e PS në një grup kërkesash për komponentët dhe testet e paketës softuerike;
• formalizimi i kërkesave për ndërlidhjet ndërmjet komponentëve, me mjedisin operativ dhe atë të jashtëm;
• zhvillimi i konceptit të një produkti softuerik dhe skenarëve për përdorimin e tij;
• zhvillimi i kërkesave për karakteristikat e përgjithësuara të përshtatshmërisë funksionale dhe përdorimi i funksioneve të produktit softuer për qëllimin e tij të synuar.

Menaxhimi i Kërkesave të dy modelet përfshijnë:

• arritja e një kuptimi të qartë të kërkesave për projektin PS nga klienti dhe zhvilluesit;
• marrjen nga klienti nga zhvilluesit e detyrimeve për të përmbushur të gjitha kërkesat e tij për produktin softuer;
• menaxhimi i ndryshimeve në kërkesat për projektin PS të rënë dakord midis klientit dhe zhvilluesit;
• sigurimin e korrektësisë së ndryshimeve nga kërkesat e përgjithshme për projektin PS deri tek kërkesat për komponentët dhe proceset e veçanta;
• identifikimin dhe identifikimin e mospërputhjeve ndërmjet proceseve të zhvillimit të projektit dhe kërkesave të klientëve.

Opsioni i dytë paraqet dokumentin: Integrimi i Modelit të Maturimit të Kapacitetit (CMMI) për Inxhinierinë e Sistemeve/Inxhinierinë e Softuerëve/Zhvillimin e Integruar të Produktit dhe Procesit, Versioni 1.1, Përfaqësimi në Stadium (CMMI-SE/SW/IPPD, V1.1, Stage). Modeli i Vlerësimit të Pjekurisë së Inxhinierisë së Sistemit të Integruar/Inxhinierisë Softuerësh/Produkteve të Integruara dhe Procesit të Zhvillimit - prezantimi me faza. Modeli bazohet në ruajtjen e konceptit të pesë niveleve të pjekurisë CMM[ , ]. Përbërja e proceseve praktikisht përsërit atë të dhënë më sipër për versionin e parë të modelit, por në një sekuencë paksa të ndryshme dhe me shtesa relativisht të vogla.

Niveli i parë karakterizohet nga pasiguri e theksuar në përbërjen dhe përmbajtjen e proceseve në projekte të ndryshme relativisht të thjeshta, prandaj nuk komentohet në dokument. Prandaj, kur sqarohet dhe detajohet përmbajtja e proceseve në një version me faza CMMI rekomandohet të jetë i kufizuar katër nivele kryesore:

• niveli i dytë- zyrtarizon menaxhimi bazë projektet:
  • menaxhimi i kërkesave;
  • planifikimi i projektit;
  • monitorimi dhe kontrolli i projektit;
  • menaxhimi i marrëveshjeve me furnitorët;
  • matja dhe analiza e proceseve dhe produkteve;
  • sigurimi i cilësisë së proceseve dhe produkteve;
  • menaxhimi i konfigurimit;
• niveli i tretë- përmban standardizimin e proceseve kryesore:
  • zhvillimi i kërkesave;
  • zgjidhje teknike;
  • integrimi i produktit;
  • verifikimi;
  • vërtetimi (certifikimi);
  • përmbajtjen e proceseve organizative;
  • përcaktimi i proceseve organizative;
  • organizimi i trajnimit;
  • menaxhim i integruar i proceseve dhe produkteve të projektit;
  • Menaxhimi i rreziqeve;
  • integrimi i ekipit të zhvillimit;
  • menaxhim i integruar i furnitorëve;
  • analiza dhe zgjidhja e problemeve (eliminimi i defekteve);
  • organizimi i mjedisit për integrim;
• niveli i katërt- përcakton menaxhimin sasior:
  • organizimi i përfaqësimit të cilësisë së proceseve;
  • menaxhimi sasior i të gjithë projektit dhe burimeve;
• niveli i pestë- optimizim, përmirësim i vazhdueshëm:
  • organizimi, inovacioni, menaxhimi sasior i proceseve dhe sigurimi i burimeve;
  • analiza e shkaqeve të defekteve, përmirësimi i cilësisë dhe menaxhimi i proceseve dhe produkteve.

Aplikimet në versionin e dytë të modelit janë të ngjashme në përbërje me aplikacionet e mësipërme për modelin e parë. Rekomandohet të aplikohet në çdo nivel më të lartë maturimi të gjitha proceset nivelet më të ulëta të mëparshme. Në të dy versionet e modelit, çdo proces bazë i theksuar më sipër komentohet me rekomandime të detajuara për zbatimin praktik të tij, të cilat përmbajnë përshkrime prej rreth 20-30 faqesh të unifikuara në strukturë:

• objektivat e përgjithshme të procesit që do të arrihen;
• vërejtje hyrëse dhe një përshkrim i përgjithshëm i funksioneve të procesit;
• objektivat specifike të procesit;
• menaxhimi i procesit;
• zhvillimi i kërkesave të procesit;
• ndërveprim dhe ndërlidhje me procese të tjera;
• qëllimet praktike - rezultatet e kërkuara të aktiviteteve të procesit;
• planifikimi i veprimeve në një proces të caktuar;
• analiza dhe vërtetimi (miratimi) i rezultateve të zbatimit të procesit;
• monitorimin dhe kontrollin e procesit.

Këto rekomandime për sa i përket fushës, përmbajtjes dhe plotësisë së përshkrimeve të proceseve bazë janë të ngjashme me një sërë standardesh për profilin e ciklit jetësor të PS të paraqitura në. Renditja dhe vlerësimi i plotësisë së proceseve të përdorura në përputhje me nivelet e pjekurisë, ju lejon të krijoni potencialin e prodhimit të ndërmarrjeve - zhvilluesve të produkteve softuerike për sa i përket cilësisë së parashikuar të proceseve dhe rezultateve të aktiviteteve të tyre dhe gatishmërisë për certifikim për pajtueshmërinë me një nivel të caktuar pjekurie të modelit CMMI - 1.1.

Theksi në modele CMMI i jepet proceseve të menaxhimit të projektit të PS. Këto kërkesa dhe procese të modeleve praktikisht korrespondojnë me rekomandimet e rregulluara dhe të detajuara në standarde. ISO 9001:2000 dhe komponentët kryesorë të profilit të standardeve komplekse të ciklit jetësor të PS [ , ]. Kërkesat për proceset në seksionet funksionale 4-8 të standardeve ISO 9001, ISO 9004, ISO 90003 në model mund të krahasohen një sërë seksionesh adekuate në përmbajtje CMMI(në Fig. 1, zona e mbivendosjes së përmbajtjes). E përbashkëta e proceseve dhe kërkesave konsiston në ngjashmërinë: përbërja, terminologjia, struktura, lista e proceseve të rekomanduara të menaxhimit, planifikimi, llogaritja e burimeve në dispozicion, zbatimi i proceseve të inxhinierisë softuerike, vlerësimi dhe organizimi i specialistëve.

Figura 1. Përbashkësia e proceseve dhe kërkesave të standardeve dhe modeleve të maturimit

Nga pikëpamja e mbështetjes dhe rregullimit të ciklit të plotë jetësor të projekteve të mëdha softuerike, mangësitë e modeleve CMMI lidhur me profilin e standardeve ekzistuese ISO mund të përfshijë sa vijon:

Një raport teknik i gjerë u hartua dhe u miratua fillimisht në vitin 1998 për të përcaktuar nivelet e pjekurisë së proceseve për sigurimin e ciklit jetësor të SP të paraqitur më sipër. ISO 15504, i përbërë nga nëntë pjesë dhe shumë aplikacione. Ai përshkruan modelin e pjekurisë CMM dhe tetë parimet bazë inxhinieri softuerike bazuar në standard ISO 9000:2000. Pastaj në ISO ky dokument ka pësuar një rishikim rrënjësor, reduktim, thjeshtësim të strukturës dhe përmbajtjes, duke ruajtur plotësisht qëllimet dhe konceptin dhe është miratuar. si standard në pesë pjesë.

Standard ISO 15504:1-5:2003-2006 rregullon vlerësimin dhe certifikimin e pjekurisë së proceseve të krijimit, mirëmbajtjes dhe përmirësimit të mjeteve dhe sistemeve softuerike të kryera nga ndërmarrjet:

• për të krijuar shtetin e vet proceset teknologjike dhe përmirësimin e tyre;
• për të përcaktuar përshtatshmërinë e proceseve të veta për të përmbushur kërkesat specifike ose klasat e kërkesave të klientëve;
• me synimin për përshtatshmërinë e tij për performancë traktate të caktuara me klientët e PS dhe sistemeve.

Standardi kontribuon në: vetëvlerësimin e pjekurisë së ndërmarrjeve, sigurimin e menaxhimit adekuat të proceseve të vërtetuara, përcaktimin e profilit të vlerësimeve të procesit, si dhe përshtatet me çdo fushëveprimi dhe madhësie të OS dhe sistemeve. Aplikimi i standardit synon zhvillimin e ndërmarrjeve dhe specialistëve kultura e përmirësimit të vazhdueshëm të pjekurisë teknologjike sigurimi i ciklit jetësor të PS që përmbush qëllimet e biznesit të projekteve dhe optimizimi i përdorimit të burimeve në dispozicion. Vlerësimi i pjekurisë së procesit të ndërmarrjes ofron një mundësi për të krahasuar dhe përzgjedhur ato, të cilat janë të preferueshme për projekte të caktuara:

• për klientët, blerësit, përdoruesit e produkteve dhe sistemeve softuerike: aftësia për të përcaktuar maturimin aktual dhe potencial të proceseve të ciklit jetësor të furnizuesit;
• për shitësit dhe zhvilluesit: aftësia për të përcaktuar maturimin aktual dhe potencial të proceseve të ciklit jetësor të softuerit dhe sistemeve të tyre, fushat dhe prioritetet për përmirësimin e procesit;
• për vlerësuesit e maturës: një kornizë për kryerjen dhe përmirësimin e proceseve të vlerësimit.

Miratimi në standard trajtohet në dy aspekte: për të përmirësuar proceset e ciklit jetësor të PS dhe sistemeve të një ndërmarrje të caktuar dhe për të përcaktuar nëse maturimi i deklaruar i projektit ose i proceseve mbështetëse të ndërmarrjes korrespondon me proceset aktuale të përdorura. Kjo pasqyrohet në pesë pjesët e mëposhtme të standardit. ISO 15504:1-5:2003-2006.

Pjesa 1 - Koncepti dhe fjalori. Përmban informacion të përgjithshëm në lidhje me proceset e certifikimit të pjekurisë së softuerit dhe sistemeve dhe rekomandime për përdorimin e pjesëve të standardit. të përvijuara Kërkesat e përgjithshme për certifikimin, terminologjinë, strukturën, përcaktohet fushëveprimi i pjesëve të mbetura të standardit.

Pjesa 2 - Kryerja (prodhimi) i certifikimit. Ai përfshin kërkesa të detajuara për kryerjen e proceseve të certifikimit si bazë për përmirësimin dhe përcaktimin e nivelit të pjekurisë së proceseve teknologjike për të siguruar ciklin jetësor të PS dhe sistemeve. Dokumenti përcakton proceset për kryerjen e vërtetimit, modelet për proceset e rekomanduara për vërtetimin dhe verifikimin e proceseve në mënyrë që ato të jenë objektive, kuptimplota dhe përfaqësuese.

Pjesa 3 - Udhëzues për prodhimin e certifikimit. Ofron një përmbledhje të teknologjisë për kryerjen e proceseve të vlerësimit të pjekurisë dhe interpretimin e zbatimit të kërkesave. Ai pasqyron: performancën e certifikimit; mjete matëse për përcaktimin e proceseve të maturimit; përzgjedhja dhe aplikimi i mjeteve të certifikimit; vlerësimi i kompetencës së certifikuesve; verifikimi i konformitetit të vërtetimit me kërkesat e deklaruara. Mjetet e verifikimit mund të përdoren nga ndërmarrjet në planifikimin, menaxhimin, monitorimin, kontrollin dhe përmirësimin e produkteve dhe sistemeve softuerike, në blerjen, zhvillimin, aplikimin dhe mirëmbajtjen e tyre.

Pjesa 4 - Udhëzimet e përdoruesit për përmirësimin e procesit dhe pjekurinë e procesit në këto dy aspekte. Rekomandohen një sërë hapash që përfshijnë: aplikimin e rezultateve të proceseve të vlefshmërisë; vendosjen e objektivave për vlerësimin e pjekurisë; përcaktimi i të dhënave fillestare për certifikim; vlerësimi i reduktimit të mundshëm të rreziqeve që rezultojnë; hapat për përmirësimin e proceseve; hapat për të përcaktuar nivelin e pjekurisë; duke krahasuar rezultatet e analizës së kualifikimit me kërkesat.

Pjesa 5 - Model model i proceseve të vërtetimit për përputhjen me kërkesat e paraqitura në Pjesën 2. Një dokument i gjerë (162 faqe) ofron shembuj praktikë të pjesëve të mëparshme të standardit për organizimin, vlerësimin dhe përmirësimin e vlerësimeve të pjekurisë së procesit të ciklit jetësor për fusha të ndryshme aplikimi, projekte softuerike dhe ndërmarrje.

Në zbatimin praktik të projekteve dhe sigurimin e ciklit jetësor të softuerit kompleks, ndonjëherë është e vështirë për zhvilluesit dhe furnitorët të identifikojnë dhe të nxjerrin në pah avantazhet e modeleve për aplikim. CMMI. Në varësi të traditave të ndërmarrjes dhe karakteristikave të një projekti të madh, shpesh këshillohet të përdoret PS si e plota kryesore. profilin e standardeveISO, dhe për vlerësimin e klientit niveli i pjekurisë Menaxhimi, mbështetja organizative dhe teknologjike e projekteve të PS zbatohen rekomandime specifike CMMI. Këto udhëzime mund të përdoren në mënyrë efektive në certifikimin e cilësisë së procesit në ndërmarrjet që ofrojnë ciklin jetësor të SP, si një alternativë ose së bashku me certifikimin sipas një sërë standardesh menaxhimi ISO 9000, në varësi të specifikave të projektit dhe kërkesave të aplikantit për certifikimin e një produkti ose teknologjie softuerike për të siguruar ciklin e jetës së tij.

Organizimi i certifikimit të produkteve softuerike

Certifikimi përbëhet nga një sërë procesesh organizative që përbëjnë sistemi i certifikimit, këto procese mbështeten me procedura dhe dokumente të rregulluara dhe duhet të kryhen nga ekspertë - inspektorë të kualifikuar, të certifikuar. Për certifikimin e ndërmarrjes-zhvilluesi dhe rezultatet e aktiviteteve të saj - produkte softuerike, modele CMMI ose profilet e standardeve ISO[ , ] rekomandohet një disiplinë e caktuar, e cila duhet t'i përshtatet karakteristikave specifike të objekteve dhe mjedisit të ciklit jetësor të SP. Proceset dhe dokumentet e listuara më poshtë janë krijuar për projekte të mëdha dhe mund të reduktohen me marrëveshje midis zhvilluesve, klientëve dhe certifikuesve në raste më të thjeshta.

Puna e certifikimit fillon me akreditimin e një organi ose një laboratori testimi, formimin dhe paraqitjen e një aplikacioni dhe një grupi dokumentesh pranë Trupit Qendror të Çertifikimit për një vendim mbi fizibilitetin e akreditimit. Nëse rezultatet e testit janë pozitive, hartohet dhe lëshohet një certifikatë akreditimi.

Rregullore për organizmin ose laboratorin certifikuesështë dokumenti kryesor që përcakton fushën lëndore të akreditimit, statusin ligjor, funksionet, strukturën, të drejtat dhe detyrimet, metodat, mjetet dhe organizimin e testeve. Pasaporta e laboratorit të certifikimit (qendrës) duhet të përmbajë informacione për pajisjet Shkenca Kompjuterike të nevojshme për testimin, mbi personelin dhe personelin, pajisjet me mjete testimi, sigurimin e dokumenteve rregullatore, teknike dhe metodologjike, si dhe burime të tjera të nevojshme për testim.

Kualitet cilësor përmban një deklaratë të parimeve, një përshkrim të metodave dhe procedurave që lidhen me zbatimin e funksioneve dhe detyrave kryesore të organizmit ose laboratorit të certifikimit, duke siguruar cilësinë e testeve dhe besimin në rezultatet e vlerësimeve, testeve dhe ekzaminimeve. Manuali i cilësisë zakonisht përfshin seksione [ TWLSC$

• politika në fushën e sigurimit të cilësisë së testimeve dhe ekzaminimeve;
• pajisjen e qendrës me materiale përkatëse metodologjike dhe softuer dhe mjete testimi;
• formalizimi i kërkesave për objektet e provës;
• politika në fushën e pajisjes teknike të qendrës dhe zhvillimit të stafit;
• arkivimin dhe kontrollin e sigurisë së dokumentacionit të rezultateve të certifikimit.

Për vlerësimin e produkteve ose proceseve që i nënshtrohen certifikimit, aplikanti i dërgon një aplikim organit të certifikimit në formën e miratuar në sistemin e certifikimit. Organizmi certifikues kryen punë për përgatitjen dhe organizimin e certifikimit të produktit me aplikim. Kjo punë përfshin:

• zgjedhja e një skeme certifikimi duke marrë parasysh specifikat e produkteve (vëllimi, teknologjia, kërkesat e dokumenteve rregullatore, etj.) dhe propozimet e zhvilluesit;
• përcaktimin e numrit dhe rendit të marrjes së mostrave dhe komponentëve që do të testohen, nëse kjo nuk është e specifikuar në standarde;
• përzgjedhjen dhe identifikimin e një laboratori testimi të akredituar për kryerjen e testeve;
• përgatitjen e projektkontratës për kryerjen e punës.

Pjesa përgatitore e punës për certifikimin përfundon me nxjerrjen e një vendimi në formën e miratuar në sistemin e certifikimit. Vendimi së bashku me projektkontratën e kryerjes së punës i dërgohet aplikantit. Gjatë organizimit të testeve të certifikimit, përzgjedhjes dhe studimit të dokumenteve aktuale rregullatore për produktet e deklaruara për certifikim, kryhen metodat e testimit dhe vlerësimit të rezultateve.

Aplikanti merr vendimet përfundimtare se cilët elementë të sistemit të cilësisë, fushat dhe llojet e veprimtarive organizative dhe teknike i nënshtrohen verifikimit gjatë certifikimit në një interval kohor të caktuar. Aplikanti duhet të krijojë kushte dhe të dorëzojë dokumente për të siguruar proceset e verifikimit. Ai mund t'i paraqesë organit të certifikimit raporte testimi të kryera gjatë zhvillimit dhe prodhimit të produkteve, dokumente për testet e kryera nga laboratorë testimi të palëve të treta dhe dokumente të tjera që tregojnë përputhshmërinë e teknologjisë ose produkteve me kërkesat e përcaktuara. Bazuar në analizën e provave të dokumentuara të konformitetit të produkteve të tij me kërkesat e vendosura, të paraqitura me aplikimin, organi i certifikimit mund të vendosë të zvogëlojë fushën e provave ose të lëshojë një certifikatë.

Testet kryhen nga laboratorë testimi të akredituar për të kryer vetëm ato teste që parashikohen në dokumentet e tyre rregullatore, të akreditimit. Nëse nuk është e mundur të kryhen teste në objektin e testimit të një laboratori të akredituar, testet mund të kryhen nga personeli i këtij laboratori tek prodhuesi ose konsumatori i këtij produkti duke përdorur pajisjet e laboratorit të testimit ose pajisjet e testimit të disponueshme nga furnizuesi. .

Procesi i certifikimit të produkteve softuerike dhe sistemeve të cilësisë së ndërmarrjes përfshin:

• analiza dhe përzgjedhja nga zhvilluesi ose klienti (aplikuesi) i një organi kompetent në këtë fushë dhe i një laboratori të certifikuar për kryerjen e testeve të certifikimit;
• dorëzimi nga aplikanti i një aplikacioni për testim pranë organit të certifikimit dhe miratimi nga certifikuesit e një vendimi për aplikimin, zgjedhja e një skeme certifikimi, përfundimi i një marrëveshjeje certifikimi;
• identifikimin e kërkesave për sistemin e cilësisë së ndërmarrjes dhe/ose për versionin e produktit softuer që do të testohet;
• kryerja e testeve të certifikimit të sistemit të cilësisë së kompanisë ose versionit të produktit softuer nga laboratori i certifikimit;
• analiza e rezultateve të marra dhe vendimmarrja nga laboratori dhe/ose organi certifikues për mundësinë e lëshimit të një certifikate konformiteti për aplikantin;
• lëshimin nga organi certifikues për aplikantin - një certifikatë dhe një licencë për të përdorur markën e konformitetit dhe për të lëshuar produkte të certifikuara - versione të produktit softuer;
• zbatimi i kontrollit inspektues nga organi certifikues i sistemit të certifikuar të cilësisë së ndërmarrjes dhe/ose produkteve;
• kryerja nga aplikanti i masave korrigjuese në rast të shkeljes së konformitetit të proceseve të sistemit të cilësisë dhe/ose produkteve me kërkesat e vendosura dhe në rast të aplikimit të gabuar të shenjës së konformitetit.

Gjatë kontrollit të përgjegjësisë së menaxhmentit të zhvilluesit për cilësinë e produktit, duhet të përcaktohet se ndërmarrja ose projekti ka një politikë, qëllime dhe detyrime të dokumentuara në fushën e cilësisë, si dhe shkallën në të cilën kjo politikë kuptohet, zbatohet dhe mirëmbahet. ne gjendje pune ne te gjitha nivelet e organizates. Duhet të konstatohet se ndërmarrja ka një përfaqësues drejtues, i cili, pavarësisht nga detyrat e tjera, ka autoritetin dhe përgjegjësinë për zbatimin e vazhdueshëm të kërkesave të standardeve dhe dokumenteve rregullatore të sistemit të cilësisë. Duhet të kontrollohet disponueshmëria e kërkesave, procedurave, mjeteve dhe personelit të trajnuar për zbatimin praktik të proceseve të sistemit të cilësisë, si dhe rëndësia dhe dokumentacioni sistematik i të gjithë komponentëve, kërkesave dhe dispozitave të sistemit të cilësisë, i cili është një proces i integruar në të gjithë. ciklin jetësor të PS. Kontrollet e sistemit të cilësisë duhet të përfshijë një përkufizim:

• disponueshmëria dhe plotësia e dokumentacionit teknologjik dhe pajtueshmëria me kërkesat e tij në praktikë;
• gjendja e pajisjeve teknologjike dhe disponueshmëria e një sistemi për mirëmbajtjen e tyre;
• ekzistencën dhe efektivitetin e sistemit të kontrollit dhe testimit;
• gjendja e instrumenteve matëse dhe testuese;
• disponueshmëria e një sistemi për identifikimin dhe eliminimin e mangësive të identifikuara në produkte ose teknologji.

Në bazë të testeve vlerësohen rezultatet e marra dhe vërtetohen konkluzionet në lidhje me përputhshmërinë ose mospërputhjen e produkteve ose proceseve me kërkesat e dokumenteve rregullatore. Raportet e testimit i dorëzohen organit të certifikimit, si dhe aplikantit me kërkesë të tij. Raportet e testimit janë objekt i ruajtjes për periudhat e përcaktuara në rregullat e sistemeve të certifikimit të produkteve dhe në dokumentet e laboratorit të testimit, por jo më pak se tre vjet.

Pas marrjes dhe kontrollit të plotësisë dhe cilësisë së dokumentacionit, specialistët e laboratorit të testimit duhet të kryejnë ekzaminimi i shkallës së zbatimit aktual të sistemit të cilësisë në ndërmarrje. Testimi fillon me zhvillimin e një programi testimi të sistemit të cilësisë, i cili duhet të shërbejë si një plan pune për punën e mëvonshme. Programi është një dokument i brendshëm pune i laboratorit të testimit dhe duhet të përmbajë një listë të punimeve, të detajuara në përputhje me specifikat e ndërmarrjes zhvilluese dhe duke përfshirë një analizë të plotësisë dhe cilësisë së dokumenteve burimore të paraqitura dhe shkallën e zbatimit të tyre praktik. në projektimin, zhvillimin dhe shpërndarjen e softuerit. Ekzaminimi i aplikimit të procedurave të sistemit të cilësisë kryhet nga laboratori i testimit në vendet e punës të ndërmarrjes që siguron ciklin jetësor të SP. Kontrollet kryhen për praninë e specialistëve-zhvilluesve të dokumenteve përkatëse në vendin e punës dhe për plotësinë e përdorimit të dispozitave dhe rekomandimeve të tyre. Rishikimet e statusit të projektit dhe auditimet e brendshme të sistemit të cilësisë, proceseve dhe/ose produkteve duhet të kryhen nga personel i pavarur nga ata që janë drejtpërdrejt përgjegjës për zbatimin e këtyre punimeve.

Metodat për të kontrolluar cilësinë e zhvillimit duhet të sigurohet burimet e nevojshme për zbatimin e programit të testimit, metodat e planifikimit dhe zhvillimin e procedurave të testimit privat. Metodat duhet të përmbajnë: objektet dhe qëllimet e testimit; tregues të cilësisë së vlerësuar; kushtet dhe procedura për testim; metodat e përpunimit, analizës dhe vlerësimit të rezultateve të testimit; mbeshtetje teknike testimi dhe raportimi. Duhet të tregohen hardueri dhe softueri i përdorur gjatë testeve dhe procedurës së testimit, si dhe rezultatet e pritshme të kontrolleve. Duhet të zhvillohen metoda për të kontrolluar korrigjimet, veprimet për korrigjimin e defekteve, nëse një kërkesë e tillë merret nga shërbimi i menaxhimit të auditimit. Shërbimi i menaxhimit të programit të testimit duhet të vendosë procedura për ruajtjen e konfidencialitetit të çdo informacioni testimi, si dhe të të dhënave të mbajtura nga vlerësuesit.

Raportet e testimit dorëzuar aplikantit dhe organizmit certifikues. Aplikanti mund t'i paraqesë organit të certifikimit raporte testimi, duke marrë parasysh kushtet e vlefshmërisë së tyre, të kryera gjatë zhvillimit dhe prodhimit të produkteve, ose dokumente për testet e kryera nga laboratorë testimi vendas ose të huaj, të akredituar ose të njohur në sistemin e certifikimit. Mbi bazën e protokolleve të testimit të certifikimit, rezultatet e marra vlerësohen dhe konkluzionet e nxjerra në lidhje me përputhshmërinë ose mospërputhjen e produkteve me kërkesat e dokumenteve rregullatore.

Konkluzioni mbi rezultatet e testeve të certifikimitështë zhvilluar nga certifikuesit dhe përmban informacion të përgjithësuar në lidhje me rezultatet e testit dhe arsyetimin për lëshimin e një certifikate. Në rast të marrjes së rezultateve negative të testeve të certifikimit, merret vendim për refuzimin e lëshimit të një certifikate konformiteti. Pas përfundimit të produktit të certifikuar ose sistemit të cilësisë, testet mund të përsëriten. Rezultatet e analizës së gjendjes së teknologjisë ose cilësisë së produktit përpilohen me akt, i cili jep vlerësime për të gjitha pozicionet e Programit të Testimit dhe përmban përfundime, duke përfshirë një vlerësim të përgjithshëm të gjendjes së prodhimit dhe produkteve, nevojën për masa korrigjuese. Akti përdoret nga organi certifikues së bashku me raportet e testimit, një aplikim për lëshimin dhe përcaktimin e periudhës së vlefshmërisë së një certifikate për një produkt softuer, frekuencën e kontrollit të inspektimit, si dhe për hartimin e masave korrigjuese.

Bazuar në rezultatet e testeve të certifikimit dhe ekzaminimit të dokumentacionit, merret një vendim për lëshimin e një certifikate. Në rast të marrjes së rezultateve negative të testeve të certifikimit, merret vendim për refuzimi për të lëshuar një certifikatë pajtueshmërisë. Për më tepër, propozimet mund t'i dërgohen ndërmarrjes aplikante për të eliminuar shkaqet e supozuara të rezultateve negative të testit, pas përfundimit të produkteve të certifikuara, testet mund të përsëriten.

Organi certifikues, pasi ka analizuar raportet e provës, ka vlerësuar prodhimin, certifikon sistemin e cilësisë, analizon dokumentacionin e specifikuar në vendimin për aplikimin, vlerëson konformitetin e produkteve me kërkesat e vendosura, harton një certifikatë bazuar në mendimin e ekspertëve. dhe e regjistron atë. Kur bën ndryshime në projektimin ose dokumentacionin operacional që mund të ndikojnë në cilësinë e sistemit ose produktit softuer të certifikuar gjatë certifikimit, aplikanti duhet të njoftojë organin e certifikimit për këtë në mënyrë që të vendosë për nevojën për teste shtesë. Pas regjistrimit, certifikata hyn në fuqi dhe i dërgohet kompanisë aplikuese. Njëkohësisht me lëshimin e një certifikate, sipërmarrja aplikuese mund të lëshohet liçensë për të drejtën e përdorimit të shenjës së konformitetit.

Për produktet softuerike të certifikuara gjatë funksionimit të tyre gjatë gjithë periudhës së vlefshmërisë së certifikatës së konformitetit, kontrollin e inspektimit. Kontrolli inspektues kryhet në formë periodike dhe inspektime të paplanifikuara pajtueshmërinë me kërkesat për cilësinë e teknologjisë dhe produkteve të certifikuara. Objektet e kontrollit, në varësi të skemës së certifikimit, janë produktet e certifikuara, sistemi i cilësisë ose qëndrueshmëria e prodhimit të zhvilluesit. Gjatë përcaktimit të shpeshtësisë dhe shtrirjes së inspektimit, merren parasysh faktorët e mëposhtëm: shkalla e rrezikut të mundshëm të produktit softuer, stabiliteti i prodhimit, vëllimi i lëshimit, disponueshmëria dhe aplikimi i një sistemi të cilësisë gjatë zhvillimit, informacioni. mbi rezultatet e testeve të produktit dhe prodhimit të tij të kryera nga prodhuesi, organet shtetërore të kontrollit dhe mbikëqyrjes.

Rezultatet e kontrollit inspektues përpilohen me akt, i cili vlerëson rezultatet e testeve të mostrës dhe kontrolleve të tjera, bën një përfundim të përgjithshëm për gjendjen e prodhimit të produkteve të certifikuara dhe mundësinë e ruajtjes së vlefshmërisë së certifikatës së lëshuar. Akti ruhet në organin e certifikimit dhe kopjet e tij i dërgohen zhvilluesit dhe organizatave që morën pjesë në kontrollin e inspektimit. Bazuar në rezultatet e kontrollit të inspektimit, organi certifikues mund të pezullojë ose anulojë vlefshmërinë e certifikatës dhe të revokojë licencën për të drejtën e përdorimit të shenjës së konformitetit në rast të mospërputhjes së produkteve me kërkesat e dokumenteve rregullatore të kontrolluara gjatë certifikimit. , si dhe në rastet e mëposhtme:

• ndryshime thelbësore në modelin e maturimit, profilin e standardeve, rregulloret e produktit ose metodën e testimit;
• ndryshime në dizajn (përbërje), plotësinë e produkteve;
• ndryshimet në organizimin ose teknologjinë e zhvillimit dhe prodhimit;
• mospërputhja me kërkesat e teknologjisë, metodat e kontrollit dhe testimit, sistemi i cilësisë, nëse ndryshimet e listuara mund të shkaktojnë mospërputhje të produkteve me kërkesat e kontrolluara gjatë certifikimit.

Vendimi për pezullimin e vlefshmërisë së certifikatës dhe licencës për të drejtën e përdorimit të markës së konformitetit nuk merret nëse, nëpërmjet masave korrigjuese të rënë dakord me organin certifikues që e ka lëshuar atë, aplikanti mund të eliminojë shkaqet e zbuluara të mospërputhjes dhe të konfirmojë , pa ritestuar në një laborator të akredituar, konformitetin e produktit ose proceseve me dokumentet normative. Nëse kjo nuk mund të bëhet, atëherë vlefshmëria e certifikatës anulohet dhe licenca për të drejtën e përdorimit të markës së konformitetit anulohet. Informacioni për pezullimin ose anulimin e certifikatës i jepet nga organi certifikues që e ka lëshuar atë tek aplikanti, konsumatorët dhe organizatat e tjera të interesuara. Vlefshmëria e certifikatës dhe e drejta për të etiketuar produktet me shenjën e konformitetit mund të rinovohet nëse ndërmarrja zhvilluese plotëson kushtet e mëposhtme:

• identifikimin e shkaqeve të mospërputhjes dhe eliminimin e tyre;
• paraqitjen pranë organizmit certifikues të një raporti për punën e bërë për përmirësimin dhe sigurimin e cilësisë së produktit;
• kryerjen e testeve shtesë të produkteve sipas metodave dhe nën kontrollin e organizmit certifikues dhe marrjen e rezultateve pozitive.

Dokumentimi i proceseve dhe rezultateve të certifikimit të produkteve softuerike

Përbërja dhe përmbajtja e dokumentacionit për certifikimin e sistemit të cilësisë ndërmarrjet varen nga karakteristikat e projektimit, zhvillimit dhe modifikimit të softuerit, si dhe nga kërkesat për cilësinë e tyre dhe karakteristikat e mjedisit teknologjik. Prandaj, grupi i nevojshëm i dokumenteve për çdo ndërmarrje ose projekt duhet të zgjidhet dhe përshtatet në lidhje me këto karakteristika. Treguesit e sistemit të cilësisë që vlerësohen gjatë certifikimit janë disponueshmëria e dokumenteve përkatëse dhe përmbushja praktike e kërkesave të një niveli të caktuar të modelit të maturimit. SMMI ose një profil standardesh të përshtatura bazuar në ISO 9000:2000, si dhe të krijuara mbi bazën e tyre, përshkrimet e punës specialistë të ndërmarrjes-zhvilluesit. Aplikanti duhet të përgatisë dhe të dorëzojë në laboratorin e testimit një grup dokumentesh të rënë dakord ndërmjet klientit dhe zhvilluesit dhe të miratuara për të verifikuar besueshmërinë, mjaftueshmërinë e përbërjes dhe mjeshtërinë e tyre në përputhje me dokumentet rregullatore.

Një grup tregues i dokumenteve bazë për certifikim përbëhet nga tre grupe:

• bazë rregulloret sistemet e cilësisë në përputhje me nomenklaturën dhe përmbajtjen e profilit të standardeve të bazuara në ISO 9000:2000 ose modelet e maturimit SMMI, si dhe programin, manualin dhe udhëzimet e përgatitura nga zhvilluesit mbi bazën e tyre, të paraqitura para testuesve (ekspertëve) të sistemit të cilësisë ose produkteve të ndërmarrjes së audituar;
• dokumentet burimore që karakterizojnë një ndërmarrje ose projekt të caktuar, si dhe ciklin e jetës së një mjeti softuer, të përgatitur nga menaxhmenti i projektit për certifikimin e cilësisë së tij;
• Dokumentet e raportimit të testuesve që pasqyrojnë rezultatet e auditimit (certifikimit) të sistemit të cilësisë dhe/ose produktit softuer të ndërmarrjes, të dorëzuara pranë organit të certifikimit, aplikantit dhe menaxhmentit të ndërmarrjes së audituar.

Produkti softuer ose sistemi i cilësisë së ndërmarrjes i paraqitur për certifikim duhet të dorëzohet së bashku me dokumentacionin përkatës. Lista dhe përmbajtja e përafërt e grupeve të këtyre dokumenteve përqendrohet në rastin e përgjithshëm të kontrollit të sistemeve të cilësisë së ndërmarrjeve që sigurojnë ciklin jetësor të produkteve të mëdha softuerike. Grupi i dokumenteve mund të reduktohet dhe përshtatet sipas marrëveshjes ndërmjet aplikantit, certifikuesit dhe menaxhmentit të ndërmarrjes së audituar në përputhje me karakteristikat e projekteve softuerike. Disa dokumente mund të kombinohen në raporte të integruara me një përgjegjësi të qartë të specialistëve të caktuar për zbatimin e tyre.

Dokumentet bazë të sistemit të cilësisë së ndërmarrjes dhe ciklit jetësor të softuerit

1. Koncepti, terminologjia, kërkesat dhe udhëzimet për përmirësimin e performancës - sistemet e menaxhimit të cilësisë - ISO 9000:2000 ose një version të modelit të maturimit CMMI.
2. Versionet e përshtatura ose lista e seksioneve dhe rekomandimet e standardeve ISO 12207, ISO 15504, ndryshimet e tyre dhe udhëzimet e aplikimit, të zgjedhura gjatë përshtatjes dhe të detyrueshme për t'u përdorur në sistemin e cilësisë së një ndërmarrje të caktuar ose projekti produkti softuer.
3. Versioni i përshtatur ose lista e seksioneve dhe rekomandimeve të standardit ISO 900003, i zgjedhur gjatë përshtatjes dhe i detyrueshëm për përdorim në sistemin e cilësisë së një ndërmarrje që prodhon një produkt softuer.
4. Karakteristikat themelore dhe atributet e cilësisë së projektit PS, të identifikuara, të përshtatura dhe të specifikuara në bazë të standardeve ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Versioni i përshtatur dhe botimi i miratuar i manualit të menaxhimit të mirëmbajtjes dhe konfigurimit bazuar në rekomandimet e standardeve ISO 14764, ISO 10007, ISO 15846.
6. Një grup përshkrimesh pune që përcaktojnë përgjegjësinë, autoritetin dhe procedurën për ndërveprimin e të gjithë menaxherëve, kryerjes dhe kontrollit të punës së personelit të përfshirë në procedurat e sistemit të cilësisë së ndërmarrjes për një projekt specifik të SP.

Dokumentet burimore që pasqyrojnë veçoritë e ciklit jetësor të një vegle të veçantë softuerike

1. Përshkrimi i karakteristikave të produkteve softuerike të krijuara në ndërmarrje, sistemi dhe mjedisi i jashtëm i ciklit të tyre të jetës, të nevojshme për përshtatjen dhe përgatitjen e versioneve të punës të standardeve dhe kërkesave të projektit PS dhe sistemit të cilësisë së ndërmarrjes në përputhje me rekomandimet e standardeve ISO 12207, ISO 15504, ISO 90003 dhe ISO 9126.
2. Përshkrimi i qëllimeve, kërkesave dhe detyrimeve të ndërmarrjes-zhvillues në fushën e sistemit të cilësisë, kriteret e cilësisë për proceset dhe produktet e zhvillimit, ofrimit dhe mbështetjes së të gjithë ciklit jetësor të softuerit.
3. Një grup dokumentesh operacionale të ofruara për klientin dhe përdoruesit për të siguruar ciklin e jetës dhe përdorimin e një versioni specifik të produktit softuer bazuar në standardet e përshtatura ISO 9294, ISO 15910, ISO 18019.
4. Mjetet e dokumentacionit dhe automatizimit për projektimin, zhvillimin, modifikimin, kontrollin dhe testimin e përdorur për të siguruar ciklin e jetës së një produkti softuer.
5. Planet dhe metodat për testimin e aplikacionit dhe vlerësimin e efektivitetit të proceseve të sistemit të cilësisë së ndërmarrjes dhe produktit softuer.
6. Metodat e mirëmbajtjes, identifikimi i komponentëve dhe dokumentacionit të produktit softuer, analiza dhe miratimi i versioneve të softuerit dhe komplekseve të të dhënave.
7. Metodologjia për menaxhimin e konfigurimit, miratimin, ruajtjen, mbrojtjen, kopjimin e versioneve të produkteve softuerike dhe dokumenteve shoqëruese, si dhe grumbullimin dhe ruajtjen e të dhënave për karakteristikat cilësore të regjistruara në arkivin e ndërmarrjes gjatë ciklit jetësor të versioneve të produkteve softuerike.

Dokumentet e testimit që rezultojnë - certifikimi i sistemit të cilësisë së ndërmarrjes dhe / ose produktit softuer

1. Një raport mbi disponueshmërinë, rëndësinë dhe ekzekutimin sistematik të dokumentacionit të përshtatur me kërkesat dhe dispozitat e sistemit të cilësisë së ndërmarrjes, i cili siguron një proces të integruar të sigurimit të cilësisë gjatë gjithë ciklit jetësor të produktit softuer.
2. Rezultatet e monitorimit dhe testimit të gjendjes dhe aplikimit të sistemit të cilësisë, të kryera në mënyrë periodike për të përcaktuar përshtatshmërinë dhe efektivitetin e tij.
3. Raport mbi disponueshmërinë dhe mirëmbajtjen e metodave për kryerjen e inspektimeve dhe raporte të dokumentuara mbi rezultatet e cilësisë së arritur të përmbushjes së kërkesave të marrëveshjes së certifikimit me klientin.
4. Rezultatet e regjistrimit të karakteristikave cilësore të arritura të paketës softuerike: identifikimi, grumbullimi, ruajtja e të dhënave të regjistruara mbi karakteristikat dhe atributet e cilësisë së produktit softuerik dhe përbërësve të tij.
5. Rezultatet e zbatimit të planit të zhvillimit, të dhënat hyrëse dhe dalëse të dokumentuara të fazave të zhvillimit dhe protokollet për kontrollin e zbatimit të ciklit jetësor të SP.
6. Rezultatet e zbatimit praktik të programit të cilësisë dhe zbatimit të aktiviteteve të rregulluara në fushën e cilësisë në të gjitha fazat e ciklit jetësor të SP.
7. Rezultatet e certifikimit të simulatorëve të mjedisit dhe gjeneratorëve të testimit, si dhe një vlerësim i mjaftueshmërisë së tyre për kryerjen e testeve të certifikimit të një produkti softuer.
8. Rezultatet e analizës së zbatimit të planeve dhe metodave të provës, raportet e testimit, vlerësimet e përputhshmërisë së rezultateve të testimit me kërkesat, si dhe rezultatet e testimit të miratuara nga përfaqësuesit e aplikantit, klientit dhe furnizuesit.
9. Akti i rezultateve të verifikimit të karakteristikave reale të ciklit jetësor të sistemit softuerik dhe sistemit të cilësisë së ndërmarrjes, konkluzione në lidhje me përputhjen e tyre me kërkesat për certifikimin e prodhimit të një produkti softuer.
10. Certifikata e sistemit të cilësisë së ndërmarrjes dhe/ose produktit softuer dhe sigurimi i ciklit jetësor të tij, licencë për përdorimin e markave të konformitetit.

Letërsia

V.V. Lipaev -- Profilet e standardeve të ciklit jetësor të softuerit. -- Jet Info, Buletini, N 12, 2005

K. Milman, S. Milman -- SMMI është një hap drejt së ardhmes. -- sistemet e hapura., N 5-6. (2005), N2. (2006), 2005, 2006

Vlerësimi dhe certifikimi i pjekurisë së proceseve për krijimin dhe mirëmbajtjen e mjeteve softuerike dhe sistemeve të informacionit ISO IEC TR 15504-CMMI. Per. nga anglishtja -- M.: Libri dhe biznesi, 2001

V.V. Lipaev -- Proceset dhe standardet e ciklit jetësor të softuerit kompleks. Drejtoria.-- M.: SINTEG, 2006

V.V. Lipaev -- Metodat për sigurimin e cilësisë së softuerit në shkallë të gjerë.-- M.: RFBR. SINTEG, 2003

"; antiburim: "Produktet softuerike përdoren tani për të zgjidhur problemet e menaxhimit në pothuajse të gjitha fushat e veprimtarisë njerëzore: në ekonomi, sociale, ushtarake dhe fusha të tjera. Sigurimi i cilësisë së lartë të produkteve softuerike vendase gjatë zhvillimit të tyre masiv dhe shpërndarjes për aplikacione të ndryshme në vend dhe në tregun botëror është kthyer në një detyrë strategjike."; kusht: 1]$

Shënim: Rrethi i ideve që qëndron në themel të asaj që është ndoshta metodologjia më e njohur për përmirësimin e proceseve të zhvillimit është studiuar në detaje. software- SMM. Analizohet logjika dhe struktura e HMM. Tregohet lidhja midis HMM dhe modeleve të procesit të studiuar më parë.

Një mjet i mrekullueshëm praktik i krijuar në kuadër të qasja e procesit për përshkrimin e aktivitetit organizimi i projektimit në veçanti, organizata që zhvillon Sistemet e Informacionit , demonstron metodologjinë HMM. CMM qëndron për Modeli i Maturitetit të Kapacitetit, që afërsisht do të thotë "modeli i maturimit të sistemit të menaxhimit". Në literaturë, CMM më shpesh përmendet si një model i pjekurisë organizative, dhe unë do ta ndjek këtë traditë gjithashtu.

Historia e shfaqjes së SMM është si më poshtë. Në fund të viteve 80. shekullin e kaluar, Departamenti Amerikan i Mbrojtjes urdhëroi Institutin e Inxhinierisë Softuerike 1Eng. ISHM - Instituti i Inxhinierisë Softuerike Universiteti Carnegie Mellon po punon për një sistem kriteresh për përzgjedhjen e nënkontraktorëve në projektet e zhvillimit të softuerit. Puna përfundoi në vitin 1991 dhe rezultati ishte CMM. Duhet të bëjmë menjëherë një rezervë që modeli të mos përmbajë asnjë financiar, ekonomik, politik, organizativ kriteret e përzgjedhjes nënkontraktor, si dhe kriteret për mundësinë e pranimit në punë sekrete (ndoshta, detyra të tilla nuk ishin vendosur). Po flasim vetëm për kritere që përshkruajnë aftësinë e një nënkontraktori të mundshëm në drejtim të zhvillimit të sistemeve softuerike.

Struktura CMM

Krijuesit e modelit morën proceset e organizatës si bazë për vlerësimin e aftësisë së një organizate për të kryer punë cilësore, e cila (aftësia) quhej pjekuri. Pastaj ata bënë disa supozime jo të parëndësishme, të cilat më pas u pranuan dhe u njohën si të drejta nga shumë profesionistë të IT-së (dhe ndoshta shumica prej tyre).

Supozimi 1. Ka nivele të pjekurisë cilësisht të ndryshme organizimi i projektimit duke u zhvilluar Sistemet e Informacionit(ka pesë nivele të tilla në modelin HMM).

Supozimi 2. Çdo organizatë zhvillimore është e interesuar të kalojë në një nivel më të lartë pjekurie (jo vetëm për të rritur shanset e saj në luftën për kontratat e Departamentit të Mbrojtjes, por edhe për të përmirësuar veten).

Supozimi 3. Kalimi është i mundur vetëm në nivelin tjetër në rregull. Është e pamundur të "kërcesh" mbi nivelin (më saktë, rreziqet për organizatën rriten ndjeshëm në të njëjtën kohë).

Kështu, nivelet formojnë një "shkallë" përgjatë së cilës organizata ngrihet si zhvillimin e vet. Çdo nivel karakterizohet nga një përbërje dhe veti e caktuar e proceseve të organizatës. SMM "Shkallët e Nivelit" është pranuar dhe shpërndarë gjerësisht. Ja si duket ajo.

Niveli 1 "Fillimtar". Procesi i prodhimit në tërësi karakterizohet si i krijuar çdo herë për një projekt specifik, e ndonjëherë edhe si kaotik. Përcaktohen vetëm disa procese dhe suksesi i projektit varet nga përpjekjet e individëve.

Niveli 2 "I përsëritur". Proceset kryesore të menaxhimit të projektit janë krijuar, duke ju lejuar të gjurmoni kostot, të monitoroni orarin e punës dhe funksionalitetin e zgjidhjes softuerike që po krijohet. Krijoi disiplinën e procesit të nevojshëm për të përsëritur sukseset e kaluara në projekte të ngjashme të zhvillimit të aplikacioneve.

Niveli 3 "E caktuar". Procesi i prodhimit është i dokumentuar dhe i standardizuar për të dyja punë menaxheriale si dhe për dizajn. Ky proces është i integruar në procesin standard të prodhimit të organizatës. Të gjitha projektet përdorin një version të përshtatur të miratuar të procesit standard të operimit të organizatës.

Niveli 4 "Menaxhuar". Janë mbledhur tregues të detajuar sasior të procesit të prodhimit dhe cilësisë së produktit që krijohet. Si procesi i prodhimit ashtu edhe produktet vlerësohen dhe kontrollohen nga pikëpamja sasiore.

Niveli 5 "Optimizimi". Përmirësimi i vazhdueshëm i procesit arrihet përmes sasisë reagimet me procesin dhe zbatimin e ideve dhe teknologjive të avancuara në të.

Pavarësisht mungesës së ashpërsisë, përkufizimi i mësipërm intuitivisht më shpesh nuk ngre kundërshtime. Për më tepër, specialistët me përvojë e kuptojnë pse kalimet janë të mundshme vetëm në nivelin tjetër, si dhe pse ia vlen të përpiqesh fare për një tranzicion të tillë. Në të njëjtën kohë, modeli HMM nuk përmban asnjë vërtetim sasior apo edhe formal të një qasjeje të tillë, e cila, megjithatë, nuk i heq meritat e saj.

Më tej, siç thonë ata, është një çështje teknologjie. Përcaktohet struktura e modelit (Figura 7.1), jepen përkufizimet dhe fillon puna e mundimshme për të përshkruar me saktësi çdo proces në çdo nivel. Për të vlerësuar vlerën praktike të asaj që është bërë, le të kalojmë një pjesë të kësaj rruge.

Oriz. 7.1.

Në fig. 7.1 përmban konceptet e mëposhtme.

Grupi i procesit kyç. Siç thuhet në (Paulk, et al., 1995), "çdo grup procesesh kyçe përcakton një bllok aktivitetesh të lidhura, si rezultat i të cilave arrihet një grup qëllimesh që janë të rëndësishme për rritjen e produktivitetit të procesit të prodhimit. Për shembull, për një grup procesesh kryesore " Menaxhimi i Kërkesave"(Shih Figurën 7.2) qëllimi është të pajtohen kërkesat e projektit të zhvillimit të softuerit midis klientit dhe zhvilluesit."

Nuk ka procese individuale në CMM. Në vend të kësaj, ka punime individuale, të quajtura praktika kyçe (shih më poshtë), të lidhura me hyrje dhe dalje me njëra-tjetrën dhe që shërbejnë si material burimor për proceset e ndërtimit. CMM nuk jep udhëzime se si duhet të strukturohen proceset, d.m.th., duke lidhur praktikat kryesore në sekuenca logjike. Grupet e praktikave kryesore quhen grupe kyçe të procesit.

Oriz. 7.2.

Grupet e proceseve kryesore në CMM janë të përcaktuara në nivelet e maturimit (Figura 7.2), d.m.th., të gjitha praktikat në një nivel ndërveprojnë vetëm me njëra-tjetrën dhe nuk ndërveprojnë me praktikat në nivele të tjera. Kjo ju lejon të garantoni performancën e plotë të të gjitha proceseve në një nivel specifik dhe, për rrjedhojë, të lidhni nivelin me fazën e përfunduar të zhvillimit të organizatës.

Mbiemri "çelës" nënkupton se ka grupet e procesit(d.m.th., grupe praktikash) që nuk janë kyçe për sa i përket një niveli specifik pjekurie, d.m.th., nuk lidhen me arritjen e qëllimeve të këtij niveli (shih më poshtë). Modeli HMM nuk përshkruan gjithçka grupet e procesit që kanë të bëjnë me zhvillimin dhe mirëmbajtjen e softuerit. Ai përshkruan vetëm ato grupe që identifikohen si përcaktues kryesorë të produktivitetit të procesit të prodhimit.

Golat. Qëllimet në CMM nuk shoqërohen me procese, por me grupe të proceseve kryesore. Siç u përmend më lart, qëllimet arrihen përmes zbatimit të praktikave kryesore. Në CMM, arritja e qëllimit do të thotë që, së pari, pas zbatimit të praktikave kryesore, të merret rezultati i dëshiruar dhe, së dyti, të merret mjaft konsistente. Mënyra në të cilën arrihen objektivat e Grupit të Procesit kyç mund të ndryshojë nga projekti në projekt për shkak të dallimeve në fusha lëndore ose mjedisi.

Nëse këto synime realizohen për të gjitha projektet, atëherë kjo do të thotë se organizata ka arritur nivelin e pjekurisë së procesit të prodhimit, i cili është i ndërlidhur me këtë grup procesesh kyçe.

Kapitulli. Seksionet (janë pesë prej tyre në çdo nivel dhe ato janë gjithmonë të njëjta) përfaqësojnë vetitë e grupeve të proceseve kryesore që duhet të zbatohen në nivelin përkatës. Këto veti përshkruajnë se si zbatohen proceset dhe deri në çfarë mase ato legalizohen në organizatë, d.m.th. të miratuara zyrtarisht dhe të koordinuara me procedurat, politikat dhe proceset e tjera të korporatës. Këtu janë pesë seksionet.

Detyrimet e ekzekutimit

Përshkruani veprimet që organizata duhet të ndërmarrë për të siguruar që procesi të jetë i vendosur dhe i qëndrueshëm. Detyrimet e performancës zakonisht lidhen me krijimin e politikave organizative dhe mbështetjen nga menaxhmenti i lartë.

Parakushtet

Përshkruani parakushtet që duhet të plotësohen në një projekt ose organizatë për zbatimin kompetent të një procesi prodhimi; zakonisht lidhen me burimet, strukturat organizative dhe trajnimet e nevojshme.

Operacionet në vazhdim

Seksioni Operacionet në Progres përshkruan punën thelbësore që duhet të kryhet në këtë nivel. Operacionet e kryera zakonisht përfshijnë krijimin e planeve dhe zbatimin e operacioneve specifike, ekzekutimin dhe gjurmimin e punës dhe marrjen e veprimeve korrigjuese sipas nevojës.

Matjet dhe analizat

Seksioni "Matje dhe

“Çdo grup procesesh kyçe shprehet me praktika kyçe, zbatimi i të cilave kontribuon në arritjen e qëllimeve të grupit.Praktikat kryesore përshkruajnë infrastrukturën dhe operacionet që kontribuojnë më shumë në zbatimin efektiv dhe ngritjen e një grupi procesesh kyçe.

Çdo praktikë kyçe përbëhet nga një fjali e vetme, e ndjekur shpesh nga një përshkrim më i detajuar që mund të përfshijë shembuj dhe sqarime. Praktikat kryesore, ndonjëherë të referuara si praktika kyçe të nivelit të lartë, krijojnë politikat, procedurat dhe operacionet bazë për një grup procesesh kyçe. Komponentët e përshkrimit të detajuar shpesh quhen nën-praktika."

Praktikat kryesore përshkruajnë ÇFARË duhet bërë, por ato nuk duhet të merren si dogmë rreth SI duhet të arrihen qëllimet. Objektivat e grupit kyç të procesit mund të arrihen nëpërmjet praktikave alternative. Interpretimi i praktikave kryesore duhet të jetë i arsyeshëm, duke lejuar arritjen e objektivave të grupit të proceseve kryesore mënyrë efektive, edhe pse ndoshta formalisht dhe ndryshe nga CMM e rekomanduar.

Një vështrim në aktivitetet e menaxhimit të TI-së, në të cilat, në vend të proceseve, merren parasysh komponentët e tyre - praktikat kryesore, dhe proceset janë të pranishme vetëm virtualisht, pasi diçka që mund të ndërtohet nga praktikat kryesore, duket disi ekzotike në shikim të parë. Deri më tani, detyra e përmirësimit të menaxhimit të TI-së zgjidhej me futjen e proceseve të gatshme nga modeli i procesit të referencës. Tani ekziston një grup nivelesh që përmbajnë praktika kyçe të ndryshme (d.m.th. të pa integruara në procese) dhe një sekuencë të rekomanduar për lëvizjen nëpër nivele. Menaxhimi i IT, sipas CMM, përmirësohet ndërsa kalon në një nivel më të lartë pjekurie. Çfarë ndodh me këtë promovim?

Në përkufizimet e niveleve (shih Figurën 7.2), u shfaq një gjë e tillë si "procesi i prodhimit". Ajo është gjithashtu e pranishme në përkufizimin e një grupi procesesh kyçe, dhe kjo nuk është një rastësi. Procesi i prodhimit, ose siç quhet me vend në CMM, Standardi Procesi i prodhimit Organizatat (OSS) është një nga konceptet qendrore të të gjithë modelit.

Në nëntor 1986, Instituti Amerikan i Inxhinierisë së Softuerit (SEI), në bashkëpunim me Mitre Corporation, filloi zhvillimin e një Rishikimi të Maturitetit të Procesit të Zhvillimit të Softuerit, i cili kishte për qëllim të ndihmonte në përmirësimin e proceseve të tyre të brendshme.

Zhvillimi i këtij rishikimi u nxit nga një kërkesë nga qeveria federale e SHBA-së për një metodë për vlerësimin e nënkontraktorëve për zhvillimin e softuerit. Problemi i vërtetë ishte paaftësia për të menaxhuar projekte të mëdha. Në shumë kompani, projektet u dorëzuan dukshëm me vonesë dhe mbi buxhet. Ishte e nevojshme për të gjetur një zgjidhje për këtë problem.

Në shtator 1987, SEI u lirua rishikim i shkurtër proceset e zhvillimit të softuerit me një përshkrim të niveleve të tyre të pjekurisë, si dhe një pyetësor i krijuar për të identifikuar fushat në kompani në të cilat nevojiteshin përmirësime. Megjithatë, shumica e kompanive e konsideruan këtë pyetësor si një model të gatshëm, si rezultat i të cilit, pas 4 vitesh, pyetësori u shndërrua në një model real, Modeli i Maturitetit të Kapacitetit për Software (CMM). Versioni i parë i CMM (Versioni 1.0), i lëshuar në 1991, u rishikua në 1992 nga pjesëmarrësit e takimit të punës, ku morën pjesë rreth 200 specialistë të softuerit dhe anëtarë të shoqërisë së zhvilluesve.

1. Elementare. Statusi më primitiv i organizatës. Organizata është e aftë të zhvillojë softuer. Organizata nuk ka një proces të vetëdijshëm të qartë, dhe cilësia e produktit përcaktohet tërësisht nga aftësitë individuale të zhvilluesve. Njëri merr iniciativën dhe ekipi ndjek udhëzimet e tij. Suksesi i një projekti nuk garanton suksesin e një tjetri. Në fund të projektit, të dhënat për kostot e punës, orarin dhe cilësinë nuk regjistrohen.
2. të përsëritshme. Në një farë mase, procesi monitorohet. Bëhen shënime për kostot dhe planet e punës. Funksionaliteti i secilit projekt përshkruhet me shkrim. Në mesin e vitit 1999, vetëm 20% e organizatave ishin të nivelit 2 ose më të lartë.
3. Instaluar. Të ketë një të përcaktuar, të dokumentuar dhe procesi i vendosur punë e pavarur nga individët. Kjo është, dakord standardet profesionale, dhe zhvilluesit i zbatojnë ato. Organizata të tilla janë në gjendje të parashikojnë me mjaft besueshmëri kostot e projekteve të ngjashme me ato të përfunduara më parë.
4. Menaxhuar. Ata mund të parashikojnë me saktësi kohën dhe koston e punës. Ekziston një bazë të dhënash e matjeve të grumbulluara. Por nuk ka ndryshime me shfaqjen e teknologjive dhe paradigmave të reja.
5. Optimizuar. Ekziston një procedurë e vazhdueshme për gjetjen dhe zotërimin e metodave dhe mjeteve të reja dhe të përmirësuara.

Zhvillimi

Përdorimi i modelit në praktikë zbuloi paqartësitë në qasjet për arritjen e niveleve më të larta të organizimit të proceseve të zhvillimit të softuerit. Prandaj, deri në vitin 2002 po zhvillohen rekomandime për përmirësimin e procesit të zhvillimit, të cilat quhen CMMI (Capability Maturity Model Integration). Aktualisht Versioni i fundit CMMi - 1.3 (botuar në nëntor 2010) .

Shiko gjithashtu

Lidhjet

Forumi Studentor MIT > Seksioni kryesor > Testet > Simulimi i sistemeve të kontrollit

Pamje versioni i plotë: Simulimi i sistemeve të kontrollit

I zgjidha të gjitha modulet, kalova gjithçka me 4, dhe atë përfundimtare me 2, tani pas tre ditësh do të përpiqem të kaloj përsëri, nuk kishte asnjë pyetje të vetme identike. U përpoqa të korrigjoj testin përfundimtar, por kontrollo, nuk mund të garantoj për korrektësinë, ekspozoj gjithçka që kam, ndoshta dikush do ta kalojë më mirë se unë. Nese dikush ka perpjekje te dyte, te trete, vendos, nese nuk te pengon, disipline, vertet shume e veshtire.:eek:

Testi përfundimtar 100 nga 100

A është rezultati i ndryshëm çdo herë?

Më shumë pyetje që nuk janë renditur këtu dhe më kanë kapur. Nuk kerkova pergjigje se pa te kalova 4. Kush deshiron te ngaterrohet per te tjerat ngarkoji pergjigjet ketu 🙂

Moduli 1:
Çfarë nuk duhet të konsiderohet si shenjë dalluese e një procesi biznesi?

Vlera e shtuar

Zgjidhni një përgjigje:
Një produkt i një procesi që mishëron qëllimet e përcaktuara më parë

Zgjidhni një përgjigje:

Në finale (kaloi më 4.

Cili është modeli i maturimit të aftësive? (CMM)

Këto pyetje + ato tashmë në forum):
1. Zgjidhni pohimin e saktë.
Zgjidhni një përgjigje:
Procesi i biznesit të divizioneve përbëhet nga zinxhirë të ndryshëm vlerash (PASIGURT)
Një proces biznesi nga fundi në fund përbëhet nga proceset e biznesit organizata të ndryshme
Procesi ndërfunksional i biznesit, si rregull, përbëhet nga proceset e biznesit të departamenteve

2. Cili nuk është një element i grafikut universal të rrjedhës së procesit të biznesit?
Zgjidhni një ose më shumë përgjigje:
Burimet e procesit
Rreziqet
Aktivitetet e menaxhimit të procesit të biznesit
Faktorët e mjedisit
Aktivitet për konvertimin e hyrjeve në dalje

3. Burimet materiale si element bazë të proceseve janë:
Zgjidhni një përgjigje:
Subjektet aktive të veprimtarisë të bashkuara në sisteme që ndërveprojnë me njëri-tjetrin dhe me burime të tjera
Veprimet e kontrollit të drejtuara nga subjektet e veprimtarisë mbi objektet e veprimtarisë, të cilat përcaktojnë qëllimet dhe rezultatet e proceseve
Objektet dhe aktivitetet pasive të përdorura për të kryer procese (JO E SIGURT)

28.03.2014, 10:07

Moduli 1:
Çfarë nuk duhet të konsiderohet si shenjë dalluese e një procesi biznesi? Zgjidhni një ose më shumë përgjigje:
Konvertimi i hyrjeve në dalje
Dorëzimi i produktit te një konsumator i jashtëm
Vlera e shtuar
Formimi i tepricës dhe/ose vlerës së përdorimit

Rezultatet si elemente bazë të proceseve janë:
Zgjidhni një përgjigje:
Subjektet aktive të veprimtarisë të bashkuara në sisteme që ndërveprojnë me njëri-tjetrin dhe me burime të tjera
Një produkt i një procesi që mishëron qëllimet e përcaktuara më parë Objektet dhe aktivitetet pasive të përdorura për të kryer proceset
Tërësia e objekteve materiale, energjie dhe informacioni të nevojshme për të përfunduar procesin

Çfarë është reagimi brenda një procesi biznesi?
Zgjidhni një përgjigje:
Ndikim i qëllimshëm dhe i vetëdijshëm në proces, i krijuar për të siguruar rezultatin e dëshiruar
Analiza dhe krahasimi i rezultateve të procesit me qëllimet e përcaktuara më parë
Ndikimi në sistemin e objekteve dhe faktorëve të mjedisit, të cilët janë burim i llojeve të ndryshme të devijimeve në funksionimin e sistemit
Unë u përgjigja kështu! por prapë doli 4

Në fund - Këto pyetje + ato që ekzistojnë tashmë:
1 Zgjidhni mangësitë e strukturave të projektimit-target nga lista.

2 Zgjidhni shembuj të përdorimit të komandave nga lista.
Kukulla cilësore
Komitetet
Ekipet e punës

3 Zgjidhni nga lista kushtet për aplikimin e strukturave organizative organike.
Punëtorët motivohen nga nevoja komplekse
Qëllimet janë të paqarta dhe ndryshojnë në mënyrë dinamike
Fuqia vihet në dyshim dhe testohet, kërkon konfirmim nga vartësit

4 Zgjidhni nga lista përfitimet e strukturave organizative të bazuara në projekte.
nënshtrimi i drejtpërdrejtë i punonjësve ndaj menaxherit të projektit dhe në këtë mënyrë arrihet paqartësia e drejtimit të përpjekjeve të këtyre punonjësve.

5 Proceset mbështetëse:
Siguroni zbatim efektiv proceset kryesore

Nota përfundimtare 5
pyetja 1
Zgjidhni nga lista e shembujve të përdorimit të komandave.

Kukulla cilësore
Komitetet
Ekipet e punës

Pyetja 2
Për çfarë përdoren ndërmjetësit brenda strukturës funksionale?

Për të integruar aktivitetet e divizioneve të ndryshme strukturore

Pyetja 3
Emërtoni llojet e marrëdhënieve në modelin SADT:
Kontrolli
dalje-mekanizmi
Input Feedback

Pyetja 4
Cili nga proceset e mëposhtme të biznesit është më i shkurtër?
Procesi i biznesit të divizionit

Pyetja 5
Cilat metoda, metodologji dhe mjete mund të përdoren për të krijuar modele informacioni të procesit të biznesit?

Metodologjia Gein-Sarson
Gjuha e modelimit të Chen dhe Barker

Pyetja 6
Cili përfaqësim i procesit të biznesit korrespondon me nivelin më të ulët (nga ato të listuara)?

Operacionet e Procesit të Biznesit

Pyetja 7
Gjatësia e procesit të biznesit:

Është subjektive

Pyetja 8
Burimet materiale si element bazë i proceseve janë:

Mjetet dhe objektet pasive të veprimtarisë që përdoren për të kryer procese

Pyetja 9
Zgjidhni nga lista përfitimet e strukturave organizative të bazuara në projekte.

Zbatohet vartësia e drejtpërdrejtë e punonjësve ndaj menaxherit të projektit dhe kështu arrihet paqartësia e drejtimit të përpjekjeve të këtyre punonjësve.

Pyetja 10
Zgjidhni nga lista përfitimet e strukturave organizative të matricës.

Mundësia për të personalizuar në mënyrë fleksibël Struktura organizative brenda një spektri të gjerë: nga matrica e dobët në të fortë

Pyetja 11
Çfarë përfshin cikli i dytë i menaxhimit të sistemit të biznesit?

Nënsistemi i kontrollit të funksionimit
nënsistemin e menaxhimit të zhvillimit

Pyetja 12
Modeli i përgjithshëm i procesit të një sistemi biznesi përfshin elementët e mëposhtëm:

Dilni
procesi
Hyrja
Shqetësim

Pyetja 13
Cili standard IDEF ju lejon të modeloni aktivitetet, rrjedhat dhe gjendjen e objekteve?

Pyetja 14
Cilat janë kompetencat e Menaxherit të Projektit në një strukturë të fortë matrice?

Mesatare deri te larte

Pyetja 15
Çfarë mund t'i atribuohet elementeve kryesore të investimeve dhe proceseve financiare?

Investitorët
Huadhënësit

Pyetja 16
Zgjidhni nga lista mangësitë e strukturave të projektimit-objektivit.

Prodhueshmëri e reduktuar në zonat funksionale

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

Cila është rendi i dominimit në diagramet SADT?
Përgjigje: Funksionet më dominuese janë të vendosura në këndin e sipërm të majtë.

ndihmë 3trajnimi kush e ka pliz

Shtohet pas 1 minute
Kërkoj 3 trajnime nga kushdo që ka Modelimin e sistemeve të kontrollit

vBulletin® v3.8.7, e drejta e autorit 2000-2018, vBulletin Solutions, Inc.

Përkthimi që mund të thoni:

Metodologjia për zhvillimin e IS. Modeli i maturimit CMM/CMMI.

Në vitin 1991, Instituti i Inxhinierisë Softuerike të Universitetit

Carnegie Mellon (Instituti i Inxhinierisë së Softuerit, SEI) krijoi modelin e maturimit CMM (Modeli i maturimit të aftësive) për zhvillimin e produkteve softuerike. Me kalimin e kohës, një familje e tërë modelesh është lëshuar:

SW-CMM - për produktet softuerike, SE-CMM - për inxhinierinë e sistemeve, CMM për blerje - për prokurim, People CMM - për menaxhimin e burimeve njerëzore, ICMM - për integrimin e produktit.

Një shumëllojshmëri modelesh doli të ishin mjaft të vështira për t'u kuptuar dhe zbatuar. Që kur janë krijuar grupe të ndryshme specialistëve, përmbajtja e këtyre modeleve nuk ishte gjithmonë në përputhje me njëra-tjetrën, si dhe me

kërkesat e standardeve ndërkombëtare. Prandaj, në vitin 2002, SEI publikoi një model të ri CMMI (Capability Maturity Model Integration), duke kombinuar modelet e lëshuara më parë dhe duke marrë parasysh kërkesat

standardet ndërkombëtare. CMMI është një grup modelesh (metodologjish) për përmirësimin e proceseve në organizata të madhësive dhe aktiviteteve të ndryshme. CMMI dallon grupet e mëposhtme të fushave të përmirësimit: menaxhimi i procesit, menaxhimi i projektit, fushat inxhinierike, shërbimi

zonave. Në këtë rast, të gjitha fushat përcaktohen në formën e kërkesave që përcaktojnë jo mënyrën se si ato zbatohen, por kërkesat e ndërfaqes. Nga kjo ka dy pasoja.

Pasoja 1. CMMI lejon implementime të ndryshme dhe nuk është një metodologji e zhvillimit të softuerit si MSF, Scrum, RUP, etj. Kjo e fundit mund të përdoret në zbatimin e saj. Për shembull, ekziston një model i veçantë procesi në VSTS për CMMI i quajtur MSF për CMMI.

Përfundim 2. CMMI përdoret për të certifikuar kompanitë për maturimin e proceseve të tyre. Fillimisht, në fund të viteve '80 dhe në fillim të viteve '90, CMM (atëherë jo ende CMMI) u krijua pikërisht si një mjet certifikimi.

nënkontraktorët federalë. Dhe vetëm më vonë, pasi u përhap në botë, filloi të përdoret dhe më pas u fokusua në përmirësimin e proceseve. Vëmë re edhe një karakteristikë e rëndësishme CMMI. Ai synohet jo vetëm për zhvillimin e sistemeve softuerike. Shumë kompanitë e mëdha ata nuk prodhojnë softuer, por produkte të synuara, ku softveri përfshihet si pjesë integrale.

Për shembull, aviacioni, industritë e hapësirës ajrore. Kjo është, zhvillimi i softuerit

ndodh së bashku me punët inxhinierike të llojeve të tjera. Dhe shpesh ndodh që në një projekt përfshihen më shumë se dy lloje të ndryshme inxhinierie. Detyra e CMMI është të sigurojë projekte dhe kompani të tilla me një platformë të vetme për organizimin e procesit të zhvillimit.

Ndryshe nga modeli klasik CMM, i cili ishte rreptësisht hierarkik dhe lejonte vetëm përmirësimin sekuencial të proceseve sipas niveleve, modeli CMMI ka dy dimensione - sekuenciale, si p.sh.

njësoj si në CMM, dhe e vazhdueshme, duke lejuar përmirësimin e proceseve në organizatë deri në një masë në mënyrë arbitrare. Këtu do të fokusohemi në modeli sekuencial. Ka 5 nivele

pjekuria e procesit (Fig. 1).

Niveli i parë(niveli i maturimit 1) është niveli në të cilin, sipas përkufizimit, ndodhet çdo kompani. Në këtë nivel, zhvillimi i softuerit është pak a shumë kaotik.

Niveli i menaxhuar(niveli i maturimit 2) - politikat dhe procedurat për organizimin e proceseve të miratuara në nivel kompanie tashmë shfaqen këtu. Por shtrirja e plotë e proceseve ekziston vetëm brenda kornizës së projekteve individuale.

Një nivel të caktuar(niveli i maturimit 3) - këtu shfaqet një proces standard në nivelin e të gjithë kompanisë në tërësi.

Çfarë është Modeli i Pjekurisë së Aftësisë (CMM)? Cilat janë nivelet CMM?

Ky është një grup i madh dhe vazhdimisht në rritje të aseteve të procesit: shabllone dokumentesh,

Modelet e ciklit jetësor, mjetet softuerike, praktikat, etj. Çdo proces specifik përftohet duke u prerë nga ky standard.

Niveli sasior(niveli i maturimit 4) nënkupton shfaqjen e një sistemi matjesh në kompani, të cilat ndodhin në bazë të një procesi standard dhe lejojnë menaxhimin sasior të zhvillimit.

Niveli i optimizmit(niveli i pjekurisë 5) nënkupton përmirësim të vazhdueshëm të proceseve të zhvillimit, si në rritje, në rritje dhe revolucionare. Në të njëjtën kohë, këto ndryshime nuk janë të detyruara, por probleme dhe vështirësi proaktive. Procesi është duke u përmirësuar vetvetiu dhe vazhdimisht janë vënë në zbatim mekanizmat e duhur.

Shumë njerëz e dinë shkurtesën CMMI, shumë njerëz e dinë se ky është një model, d.m.th. një grup rekomandimesh se si të përmirësohen proceset që lidhen, për shembull, me zhvillimin e softuerit. Por pak njerëz e dinë se ka disa modele CMMI. Më i famshmi prej tyre është CMMI për Zhvillim (CMMI-DEV), i cili është i lidhur me të vërtetë në shumë aspekte me aktivitetet e kompanive të zhvillimit (d.m.th., ato kompani dhe organizata që zhvillojnë dhe furnizojnë një produkt të caktuar softuerësh ose softuer dhe pajisje të tjera komplekse. zgjidhje).

Por çfarë ndodh me ata që ofrojnë jo një produkt, por shërbime (për shembull, mbështetje për produktin me një pjesë të parëndësishme të zhvillimit në kostot totale të punës ose pa kosto pune fare)? Për ta, ekziston gjithashtu një grup rekomandimesh - modeli CMMI për Shërbime (CMMI-SVC). Për departamentet e IT, për shembull, ky model (më saktë, rekomandimet e tij) mund të ndihmojë për të kuptuar se çfarë duhet bërë në mënyrë që, për shembull, të njëjtat rekomandime ITIL të bëhen një proces normal, dhe jo një lloj "praktike e shenjtë".

Modeli i maturimit të aftësive (CMM)

Është kurioze që rekomandimet e këtij modeli janë mjaft universale dhe nuk "mbyllen" vetëm Teknologjia e Informacionit. Prezantimi pilot i praktikave të këtij modeli u bë ... në një nga spitalet në Shtetet e Bashkuara (në fund të fundit, edhe kujdesi mjekësor është një shërbim).

Megjithatë, ndonjë nga modelet e listuara është më mirë për t'u mësuar. Dhe nëse ka disa qindra njerëz të trajnuar në modelin CMMI-DEV për të gjithë CIS (rreth 250-300 persona), atëherë ka vetëm 6 persona të trajnuar në modelin CMMI-SVC në CIS. Po flasim për të trajnuarit, jo për instruktorët. Ky ishte pikërisht problemi kryesor deri në dhjetor 2011: për CMMI-DEV, kishte vetëm një instruktor rusisht-folës të certifikuar nga SEI (zhvilluesi i modelit CMMI) në të gjithë botën, dhe për modelet e tjera nuk kishte fare! Tani një instruktor i tillë është shfaqur edhe sipas modelit CMMI-SVC (prandaj 6 të parët e trajnuar). Ky instruktor është autori i këtij publikimi, i cili është në dispozicion për t'iu përgjigjur çdo pyetjeje në lidhje me modelet e përmendura dhe në lidhje me trajnimin formal. Pyete!

Ky material është një regjistrim privat i një anëtari të komunitetit Club.CNews.
Redaktorët e CNews nuk janë përgjegjës për përmbajtjen e tij.

Ne do të shqyrtojmë evolucionin e modeleve të sigurimit të cilësisë në bazë të "modelit të pjekurisë së procesit" ose "modelit të përmirësimit të kapacitetit" CMM (Capability Maturity Model). Edhe pse modelja SMM ka për qëllim sigurimin e cilësisë së softuerit, aspektet metodologjike të tij janë të zbatueshme për modelet për sigurimin e cilësisë së çdo produkti (mallra, punë, shërbime).

Kryesorja në model SMMështë koncepti i pjekurisë organizative.

i papjekur konsiderohet një organizatë në të cilën procesi i zhvillimit të softuerit varet vetëm nga interpretues dhe menaxherë të veçantë, dhe vendimet shpesh merren "në fluturim". Në këtë rast, ekziston një probabilitet i lartë i tejkalimit të buxhetit ose dështimit të realizimit të projektit, dhe për këtë arsye menaxherët janë të detyruar të merren vetëm me zgjidhjen e problemeve të menjëhershme.

I pjekur Një organizatë konsiderohet se plotëson kushtet e mëposhtme:

• – ka procedura të mirëpërcaktuara për krijimin e produkteve softuerike dhe menaxhimin e projekteve, të cilat rafinohen dhe përmirësohen projekte pilot duke analizuar komponentët e "kosto - fitim";
• – vlerësimet e kohës dhe kostos së kryerjes së punës bazohen në përvojën e grumbulluar dhe për këtë arsye janë mjaft të sakta;
• – kompania ka standarde për proceset e zhvillimit, testimit dhe zbatimit të softuerit, rregulla për hartimin e kodit përfundimtar të programit, komponentët, ndërfaqet, etj. E gjithë kjo përbën infrastrukturën dhe Kulturë korporative që mbështet procesin e zhvillimit të softuerit.

Pra standardi SMMështë një model i sigurimit të cilësisë që përbëhet nga kritere për vlerësimin e pjekurisë së një organizate dhe receta për përmirësimin e proceseve ekzistuese. Në model SMM janë përcaktuar pesë nivele të pjekurisë së organizatave, karakteristikat e të cilave janë paraqitur në fig. 5.3.

Oriz. 5.3. Pesë nivele të pjekurisë së modelitSMM

Niveli i parë (niveli fillestar)është baza për zhvillimin e ndërmarrjes në nivelet e mëposhtme. Besohet se në ndërmarrjen e nivelit fillestar të organizatës nuk ka kushte të qëndrueshme për krijimin e softuerit me cilësi të lartë. Rrjedhimisht, rezultati i çdo projekti varet tërësisht nga cilësitë personale të menaxherit dhe përvoja e programuesve. Kjo do të thotë se suksesi në një projekt mund të përsëritet vetëm nëse të njëjtët menaxherë dhe programues caktohen në projektin tjetër. Sidoqoftë, nëse menaxherët ose programuesit që kanë fituar përvojë në projekte largohen nga ndërmarrja, atëherë cilësia e softuerit të prodhuar bie ndjeshëm me largimin e tyre.

Duhet pranuar se në nivelin fillestar, në situata stresuese, një varësi e madhe nga faktori njeri procesi i zhvillimit reduktohet në shkrimin e kodit dhe testimin minimal të tij.

Arritja e të dytës niveli i përsëritshëm (nivel i përsëritur) përcaktohet nga zbatimi i teknologjisë së menaxhimit të projektit në ndërmarrje. Planifikimi dhe menaxhimi i projektit në ndërmarrje bazohet në përvojën e akumuluar, ekzistojnë dhe përdoren standarde për softuerin e zhvilluar, pajtueshmëria me të cilat kontrollohet nga një grup i veçantë i sigurimit të cilësisë. Besohet se niveli i dytë mund të ofrojë mundësi për përmirësim të mëtejshëm (kalimi në nivelin e tretë), dhe nuk përjashton mundësinë e një kthimi regresiv të cilësisë së procesit të zhvillimit të softuerit në nivelin fillestar në kushte kritike.

Së treti, një nivel të caktuar (përcaktuar majtas) karakterizohet nga fakti se procesi standard i krijimit dhe mirëmbajtjes së softuerit është plotësisht i dokumentuar, nga zhvillimi i softuerit deri te menaxhimi i projektit. Hipoteza e prezantimit të këtij niveli është se në procesin e standardizimit, ndërmarrja kalon në praktikat dhe teknologjitë më efektive. Për të krijuar dhe ruajtur funksionimin e standardeve për zhvillimin e softuerit dhe menaxhimin e projektit në një organizatë, duhet të krijohet një grup i veçantë. Një parakusht për të arritur nivelin e tretë është prania në ndërmarrje e një programi të zhvillimit të vazhdueshëm profesional dhe trajnimit të punonjësve. Besohet se duke filluar nga ky nivel, organizata pushon së varuri nga cilësitë e zhvilluesve specifikë dhe nuk tenton të rrëshqasë në një nivel më të ulët në situata stresuese.

Në të katërtin, niveli i menaxhuar (niveli i menaxhuar) ndërmarrja vendos tregues sasiorë të cilësisë - si për produktet softuerike ashtu edhe për proceset e krijimit të tyre në përgjithësi. Kështu, menaxhimi më i mirë i projektit arrihet duke reduktuar devijimet e treguesve të ndryshëm të projektit. Në të njëjtën kohë, ndahen variacionet kuptimplote (sinjale) të proceseve të implementuara të zhvillimit të softuerit dhe variacionet e rastësishme (zhurma) të procesit.

E pesta (më e larta), niveli i optimizimit (niveli i optimizimit) karakterizohet nga fakti se masat e përmirësimit zbatohen jo vetëm për proceset ekzistuese, por edhe për të vlerësuar efektivitetin e futjes së teknologjive të reja. Detyra kryesore e ndërmarrjes në këtë nivel është përmirësimi i vazhdueshëm i proceseve ekzistuese. Në të njëjtën kohë, përmirësimi i procesit duhet të ndihmojë në parandalimin gabimet e mundshme dhe defekte. Në të njëjtën kohë, duhet të punohet për të ulur koston e zhvillimit të softuerit.

5 faza evolucionare në menaxhimin e proceseve organizative. Shpjegimi i modelit të maturimit të aftësisë. CMM

Modeli i pjekurisë së aftësisë CM-CEI është një model organizativ që përshkruan 5 fazat (nivelet) evolucionare në të cilat menaxhohen proceset në një organizatë.

I krijuar fillimisht për zhvillimin e softuerit, qëllimi i Modelit të Pjekurisë së Kapacitetit është që një organizatë duhet të jetë në gjendje të pranojë dhe të mbështesë aplikacionet e saj softuerike. Modeli gjithashtu sugjeron hapa dhe iniciativa konkrete për të ndihmuar organizatën të rritet në nivelin tjetër.

5 fazat e modelit të maturimit të aftësive

Fillestare (proceset janë ad hoc, kaotike, ose në fakt pak prej tyre janë të përcaktuara) Të përsëritura (proceset bazë janë vendosur dhe ka disiplinë për t'iu përmbajtur atyre proceseve) Përcaktuar (të gjitha proceset janë të përcaktuara, të dokumentuara) , të unifikuara dhe të integruara) Menaxhuar ( proceset maten duke grumbulluar të dhëna të detajuara mbi proceset dhe cilësinë e tyre) Optimizimi (zhvillimi i vazhdueshëm i procesit nëpërmjet reagimeve sasiore dhe testimit të ideve dhe teknologjive të reja)

Modeli i zhvillimit të softuerit

CMM përshkruan parimet dhe praktikat që qëndrojnë në themel të konceptit të pjekurisë së procesit të softuerit. Ato janë krijuar për të ndihmuar firmat e zhvillimit dhe shitjes së softuerit të përmirësojnë sofistikimin e proceseve të tyre softuerike në një mënyrë evolucionare. Duke filluar nga proceset ad hoc, kaotike, duke kaluar në procese softuerike të pjekura dhe të disiplinuara. Fokusi është në identifikimin e fushave kryesore të procesit dhe praktikave shembullore që mund të përbëjnë procese të disiplinuara softuerike. Koncepti i pjekurisë CMM krijon një kontekst në të cilin:

Praktikat mund të përsëriten. Nëse nuk e përsëritni ndonjë operacion, atëherë nuk duhet ta përmirësoni atë. Ekzistojnë rregulla, procedura dhe praktika që detyrojnë një organizatë të zbatojë dhe zbatojë në mënyrë të vazhdueshme. Praktikat më të mira për organizimin e punës së prodhimit mund të ndahen shpejt midis grupeve. Praktikat janë përcaktuar për të lejuar shkëmbimin ndërmjet projekteve, duke siguruar kështu njëfarë standardizimi për organizatën. Devijimet në ekzekutimin e këtyre metodave janë minimizuar. Përcaktohen qëllime sasiore për detyrat; dhe matjet vendosen, prodhohen dhe mirëmbahen për të formuar bazën për vlerësim. Praktikat përmirësohen vazhdimisht për të përmirësuar aftësinë (optimizimin).

Modeli i pjekurisë së aftësive është i dobishëm jo vetëm për zhvillimin e softuerit, por edhe për të përshkruar nivelet evolucionare të organizatave në përgjithësi dhe për të përshkruar nivelin e menaxhimit që një organizatë ka zbatuar ose dëshiron të arrijë.

Struktura e modelit të zhvillimit të veçorive

Nivelet e pjekurisë janë një koncept i shtresuar që siguron qëndrueshmërinë e disiplinës që nevojitet për të arritur përmirësim të vazhdueshëm. Është e rëndësishme të theksohet këtu se një organizatë zhvillon aftësinë për të vlerësuar pasojat e një praktike, teknologjie ose mjeti të ri. Prandaj, nuk është çështja e pranimit të këtyre risive, por më tepër se si këto përpjekje inovative ndikojnë në praktikat ekzistuese. Ai mbështet projekte, grupe dhe organizata duke u dhënë atyre një bazë për të bërë zgjedhje të informuara. Fushat kryesore të procesit - Një zonë kyçe e procesit (KPA) përcakton një grup aktivitetesh të ndërlidhura që, kur kryhen së bashku, arrijnë një numër qëllimesh të rëndësishme. Objektivat - Objektivat e një zone kyçe të procesit përshkruajnë dispozitat që duhet të ekzistojnë për atë zonë kyçe të procesit. Rregulloret duhet të zbatohen në mënyrë efikase dhe të sigurt. Shkalla në të cilën qëllimet janë përmbushur tregon se çfarë lloj aftësie ka krijuar organizata në atë nivel të përsosmërisë. Objektivat përcaktojnë qëllimin, kufijtë dhe qëllimin e secilës zonë kyçe të procesit. Karakteristikat e Përgjithshme - Karakteristikat e përgjithshme përfshijnë praktikat që zbatojnë dhe institucionalizojnë fushat kryesore të procesit. Këto 5 lloje karakteristikat e përgjithshme përfshijnë: Angazhimin për të kryer, aftësinë për të kryer, iniciativat që duhen kryer, matjen dhe analizën dhe kontrollin e zbatimit. Praktikat kryesore - Praktikat kryesore përshkruajnë elementët dhe praktikat e infrastrukturës që kontribuojnë në mënyrë më efektive në zbatimin dhe institucionalizimin e fushave kryesore të procesit.

Kriteret për përcaktimin e një procesi

Kriteret për përcaktimin e një procesi janë një grup elementësh të procesit që duhet të përfshihen në një përshkrim të procesit të softuerit në mënyrë që njerëzit t'i përdorin ato në praktikë. Për të vendosur kriteret, duhet të bëni pyetjen - "Për çfarë informacioni procesi i softuerit nevojiten per dokumentacion?