Bevezetés

A modern komplex rendszerek legfontosabb része az szoftver termékek- intellektuális komponens. A szoftvertermékeket ma már az emberi tevékenység szinte minden területén menedzsment problémák megoldására használják: a gazdaságban, a szociális, katonai és egyéb területeken. Biztonság Jó minőség hazai szoftvertermékeikkel tömeges fejlesztésés a különböző alkalmazások ellátása az országban és a világpiacon stratégiai céllá vált.

A szoftverfejlesztésben és a szoftvertermékek minőségbiztosításában jelenleg két, szinte független szabványosítási terület létezik, amelyeket feltételesen nevezhetünk ISO szabványprofiloknak ( nemzetközi szervezet szabványosítási) és SEI (US Software Engineering Institute) lejárati modelljei. Az elsők teljesen a [ , ]-ban, a másodikak pedig a [ , ]-ban vannak. A cikk fő tartalma az érettségi modelleknek szól.

A komplex szoftvertermékek világában a versenyképesség és sikeres export lehetőségének biztosítása érdekében azokat a követelményeknek megfelelően kell fejleszteni és tanúsítani. nemzetközi szabványok profiljai az alapon ISO 9000:2000 vagy érettségi modellek - CMMI:2003(Capability Maturity Model Integration – Integrált szoftvermérnöki érettségi felmérési modell). Ez a két irány módszertanilag nagyon közel áll egymáshoz, és részben kölcsönös hivatkozásokon keresztül metszi egymást.

A műszaki-gazdasági mutatók és a szoftvertermékek minőségének javítását, valamint a hibák és hibák megelőzését a modern technológiák szoftverfejlesztés és rendszerek számítógéppel segített tervezés. Ezek nagy teljesítményű, erőforrás-takarékos technológiák kiváló minőségű, megbízható és biztonságos szoftverkomplexumok létrehozására, amelyek célja a szoftvereszközök (PS) tervezéséhez, megvalósításához és karbantartásához szükséges erőforrások teljes költségének csökkentése. Ehhez mindenekelőtt olyan elemzési és tervezési módszereket és eszközöket kell alkalmazni, amelyek a kezdetektől fogva biztosítják a célok, célok és funkciók konkretizálását, legpontosabb ábrázolását. életciklus(LC) a PS és megakadályozza a lehetséges rendszerhibák továbbterjedését a fejlesztés további szakaszaira. Az ilyen szoftverfejlesztési technológiák lehetővé teszik az üzemeltetésre átadott szoftvertermékek rendszer-, algoritmus- és szoftverhibáinak kiküszöbölését vagy jelentős csökkentését. Ezen kívül hatékonyak a PS módosításában és karbantartásában, valamint a külső környezet megváltoztatásában.

A komplex, kritikus rendszerek minőségének, megbízhatóságának és biztonságos használatának igazolására az azokban használt szoftvertermékeket tanúsítvány minősített, probléma-orientált vizsgálóközpontok vagy laboratóriumok. Az ilyen teszteket akkor kell elvégezni, ha a programok összetett, kritikus folyamatokat kezelnek, vagy olyan fontos információkat dolgoznak fel, amelyek hibái vagy nem megfelelő minősége jelentős károkat okozhat. A tanúsítási teszteknek meg kell állapítaniuk a szoftverkomplexumok megfelelését a dokumentáció követelményeinek, és lehetővé kell tenniük, hogy a tesztek során vizsgált külső környezet paramétereiben bekövetkező változások határain belül működjenek. Az ilyen típusú teszteket a legszigorúbb és legmélyebb ellenőrzés jellemzi, és a fejlesztőktől és ügyfelektől (felhasználóktól) független szakembereknek kell elvégezniük.

A tanúsítás alapját a szoftvercsomagok szabványosított vevői követelményeknek való megfelelés szempontjából történő tesztelésére szolgáló részletes és hatékony programok és módszerek, a speciálisan kialakított tesztproblémák és azok kialakítására szolgáló generátorok, valamint a tesztelők magas minősítése és tekintélye kell, hogy képezzék. Alkalmazás vállalkozásoknál - szoftvertermékek fejlesztőinél, tanúsított minőségbiztosítási rendszerekben a PS életciklusának biztosítására a követelmények alapján ISO 9000:2000 vagy CMMI:2003, garantálja a folyamatok és termékek életciklusának magas, fenntartható minőségi irányítását, és sok esetben lehetővé teszi a végső szoftvertermék tanúsításának megkönnyítését is. Ezért a komplex szoftverprojektek ügyfelei hajlamosak olyan kivitelező vállalkozókat választani, akik az adaptált nemzetközi szabványprofilokon vagy lejárati modelleken alapuló minőségbiztosítási rendszerek alkalmazását tanúsító tanúsítvánnyal rendelkeznek.

A szoftverfejlesztési módszerek tanításának hiányosságai tág teret hagynak a szakemberek önkényének a munkájuk minőségének megítélésében, valamint a szoftverprojektek számos hibájának és hibájának megjelenésére. A programok által megoldott modern feladatok egyre összetettebbé válása és felelőssége, valamint az eredmények nem megfelelő minőségéből adódó esetleges károk jelentősen megnövelték a módszerek elsajátításának relevanciáját a minőségi jellemzőkre vonatkozó követelmények és a mérési módszerek teljes, szabványos leírásához. valós, elért értékeik a szoftver életciklusának különböző szakaszaiban. Jelentősen megnőtt az igény, hogy a szakemberek ismerjék a szoftvertermékek minőségi jellemzőinek értékelésére szolgáló fogalmakat, definíciókat és módszereket.

A szoftverkomplexumok rohamos növekedése és bonyolódása nagy, professzionális munkamegosztással rendelkező programozói csapatok létrehozásához vezet, amelyekben egyetlen projekten kell szabályozni a szakembercsoportok összehangolt tevékenységét. A fejlesztők szerződésekben tett ígéreteit, hogy a megállapodás szerinti határidőn belül jó minőségű szoftvereket szállítanak, gyakran nem tartják be. Ez gyakran abból adódik, hogy a megrendelő és a kivitelező eltérő szempontok szerint értékeli a minőségi szintet, és nincs egyetértés ebben a kérdésben, illetve a programok minőségének értékelése nem kellően formalizált. Ezen túlmenően néha hiányzik a képesség a magas színvonalú programok megvalósításához szükséges erőforrások megfelelő felmérésére. Ennek eredményeként a szoftvertermékek minősége gyakran alacsony, megbízhatatlan és nem versenyképes a nemzetközi piacon. Ezért a legfontosabb probléma a fejlesztés és alkalmazása sok modern rendszerek a szoftvermérnöki területen dolgozó szakemberek képzése, oktatása, olyan nemzetközi szabványok alkalmazása, amelyek hozzájárulnak a szoftver magas minőségéhez és megbízható értékeléséhez, azzal a fő céllal, hogy projektfolyamatokat lehessen megvalósítani. kezelhető, és az eredmények a következők kiszámítható. Szükséges a követelmények formalizálása és a komplex szoftvercsomagok működésének és alkalmazásának minőségi jellemzőinek meghatározott értékeinek elérése, figyelembe véve a minőség biztosításához és javításához rendelkezésre álló erőforrásokat.

CMMI lejárati modell - 1.1 finomítja és javítja a korábbi modelleket CMM(lásd ), és részben figyelembe veszi a szoftvermenedzsment területén meglévő nemzetközi szabványok alapvető követelményeit is. Jelentős figyelem CMMI a fejlesztési folyamatok és az iterációk számbavétele a vevői igények megváltoztatásakor, a funkciók, komponensek, tesztek és projektdokumentumok nyomon követhetősége. A közelmúltban információk jelentek meg a 2003-as verzió SEI verziójának modernizálásáról. CMMI-1.1 a felhalmozott tapasztalatok és a vállalkozások visszajelzései alapján. A tervek szerint 2006-ban fog megjelenni a modell új, jelentősen továbbfejlesztett változata CMMI-1.2, ami után az 1.1-es verziót ki kell állítani. 2007 végéig a felhasználóknak át kell váltaniuk a verzióra CMMI-1.2, és a jövőben kötelezővé válik a vállalati technológia minőségének formalizált értékelése (tanúsítása) a szoftverfejlesztés területén. A tanúsítvány érvényességi ideje három évre korlátozódik. A nagy szoftverrendszerek vásárlóinak és fejlesztőinek az 1.2-es verzió SEI általi hivatalos közzététele előtt fel kell készülniük ezekre a változásokra.

A CMMI érettségi modell felépítése és tartalma - 1.1

Két modell opció CMMI-1.1 biztosítására tervezték folyamatos folyamatok komplexének értékelése ben bizonyos terület szoftver létrehozása ill szakaszos a vállalkozás érettségének értékelésére, javítására, valamint általában a programkomplexumok életciklusának megszervezésére. Modellek CMMI segítséget nyújtanak a szakembereknek termékeik megszervezésében és fejlesztésében, valamint a PS fejlesztési és karbantartási folyamatok racionalizálásában és kiszolgálásában. Ezen modellek koncepciója kiterjed a komplex rendszerek kiforrottságának menedzselésére, értékelésére, a szoftvertervezésre, valamint az integrált szoftvertermékek létrehozásának és fejlesztésének javítására irányuló folyamatokra. A folyamatos és szakaszos modellek komponensei nagymértékben hasonlóak, az egyes projektek tulajdonságaitól és jellemzőitől függően eltérő összetételben és felhasználási sorrendben választhatók ki és alkalmazhatók.

A modellleírási lehetőségek egyetlen séma szerint épülnek fel, amely általános szakaszokat tartalmaz:

• Előszó;
• 1 szakasz - bevezetés;
• 2. szakasz – alkatrészmodell;
• 3. szakasz – terminológia;
• 4. szakasz - a szintek tartalma és a modell egyes verzióinak fő összetevői (célok és eljárások kidolgozása);
• 5. szakasz - a folyamatok kölcsönhatásának szerkezete; a 7. szakaszban a folyamatok négy kategóriája annotációval, azok általános áttekintésével és a CMMI-folyamatok interakciós sémáival van ellátva:
  • folyamatmenedzsment;
  • menedzsment - projektmenedzsment;
  • mérnöki technika (technológia);
  • támogatás;
• 6. szakasz – A modell használata CMMI- rövid ajánlások a felhasználók számára a modell alkalmazásával és a képzéssel kapcsolatban; a modellfolyamatok kompatibilitását és megfelelőségét a szabvány 2. és 3. részében szereplő korábbi CMM modell szabályozott folyamataival ISO 15504.
• A 7. szakasz az utolsó, a legnagyobb minden szabványban, körülbelül 500 oldalt foglal el a teljes dokumentumból, ami több mint 700 oldal. Ez a rész részletes ajánlásokat ad a benne felsorolt ​​egyes folyamatok megvalósításához, amelyek figyelembe veszik egy adott modell jellemzőit.

Első lehetőség(folyamatos) modell a dokumentumot tükrözi: Képesség-érettségi modell-integráció (CMMI) rendszertervezés/szoftverfejlesztés/integrált termék- és folyamatfejlesztéshez, 1.1-es verzió, folyamatos ábrázolás (CMMI-SE/SW/IPPD, V1.1, folyamatos). Integrált rendszertervezés/szoftverfejlesztés/integrált termékek és fejlesztési folyamatok érettségi értékelési modellje – folyamatos nézet. Ebben a modellben a hetedik szakasz a folyamatokból áll:

• folyamatmenedzsment:
  • képzés szervezése;
  • folyamatok átalakításának (változásainak) megszervezése;
  • innovációk és bővítések szervezése;
• projektmenedzsment:
  • projekt tervezés;
  • projektfolyamatok nyomon követése és ellenőrzése;
  • Kockázatok kezelése;
  • kvantitatív projektmenedzsment;
• mérnök (technológia):
  • követelménykezelés;
  • követelményfejlesztés;
  • műszaki megoldások;
  • termékintegráció;
  • igazolás;
  • érvényesítés (tanúsítás, jóváhagyás);
• támogatás:
  • konfiguráció-menedzsment;
  • változások elemzése és döntéshozatal;
  • kiváltó ok elemzése és problémamegoldás (hibaelhárítás).

Az öt melléklet a következőket tartalmazza:

ÉS- a felhasznált irodalmi források és dokumentumok összetétele, amely azonban nem említ szabványokat ISO;

NÁL NÉL- rövidítések;

TÓL TŐL- szószedet alapú terminológia ISO csak négy szabványban használják ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - követelmények leírása és javaslatok a modellkomponensek kialakítására érettségi szintek szerint;

E - a fejlesztésben résztvevők listája CMMI- projekt.

Ebben a modellben a figyelem a szervezeti folyamatokra, a szoftverprojektek megvalósítási folyamatainak tervezésére, menedzselésére és ellenőrzésére, a szoftvertermékek követelményeinek kialakítására és menedzselésére összpontosul. A következő példák a részletekre CMMI néhány közülük.

Projekt tervezés ebben és a második modellben is:

• a szoftvertermék lehetséges méretének (léptékének) felmérése;
• a PS projekt funkciói és jellemzői összetettségének értékelése;
• a szoftvercsomag modelljének és életciklusának szakaszainak meghatározása;
• a projekt megvalósíthatósági tanulmánya - az alállomás költségének, munkaintenzitásának és életciklusának időtartamának meghatározása;
• szakaszos munkaterv és projekt költségvetés kialakítása;
• projektkockázatok elemzése, azonosítása és értékelése;
• folyamatok és termékek dokumentációjának tervezése és kezelése a PS projekt életciklusában;
• a műszaki és emberi erőforrások tervezése és elosztása a PS életciklusának szakaszai szerint;
• a projekt megvalósításához egy szakembergárda tudás- és képzettségi biztosításának tervezése;
• a PS projekt tervkészletének általánosítása és elemzése;
• az életciklus szakaszaira vonatkozó munkák és erőforrások koordinálása a fejlesztő által a PS projekt megrendelőjével;
• a munkaterv dokumentálása és a projektfejlesztő menedzser általi jóváhagyása.

Követelmények Fejlesztési folyamatok egy szoftvertermékhez hasonló folyamatok mindkét modellben, és a következőket tartalmazzák:

• az ügyfél és a felhasználók valós igényeinek azonosítása a szoftvertermék funkcióival és jellemzőivel kapcsolatban;
• a szoftvertermék funkcióinak kezdeti, alapkövetelményeinek kialakítása és koordinálása a megrendelő és a fejlesztő között;
• a rendelkezésre álló erőforrások és a szoftvercsomag projekt korlátainak meghatározása;
• a PS funkcióira vonatkozó alapvető kezdeti követelmények bontása a szoftvercsomag összetevőire és tesztjére vonatkozó követelményrendszerre;
• követelmények formalizálása a komponensek közötti interfészekre, a működési és külső környezetre;
• szoftvertermék koncepciójának és felhasználási forgatókönyveinek kidolgozása;
• követelmények kialakítása a funkcionális alkalmasság általánosított jellemzőire és a szoftvertermék funkcióinak rendeltetésszerű használatára.

Követelménykezelés mindkét modell tartalmazza:

• a PS projekt követelményeinek egyértelmű megértése az ügyfél és a fejlesztők részéről;
• az ügyfél által a szoftvertermékkel szemben támasztott összes követelmény teljesítésére vonatkozó kötelezettségek megszerzése a fejlesztőktől;
• a PS projekt követelményeiben bekövetkezett változások kezelése a megrendelő és a fejlesztő között;
• a PS projekt általános követelményeitől a komponensekre és konkrét folyamatokra vonatkozó követelményekre vonatkozó változtatások helyességének biztosítása;
• a projektfejlesztési folyamatok és a vevői igények közötti eltérések azonosítása és azonosítása.

Második lehetőség bemutatja a dokumentumot: Képesség-érettségi modell-integráció (CMMI) rendszermérnöki/szoftvertervezési/integrált termék- és folyamatfejlesztéshez, 1.1-es verzió, szakaszos ábrázolás (CMMI-SE/SW/IPPD, V1.1, fokozatos). Integrált rendszertervezés/szoftverfejlesztés/integrált termékek és fejlesztési folyamatok érettségi értékelési modellje - szakaszos bevezetés. A modell az öt érettségi szint koncepciójának fenntartásán alapul CMM[ , ]. A folyamatok összetétele gyakorlatilag megismétli a modell első változatánál fentebb megadottat, de kissé eltérő sorrendben és viszonylag kis kiegészítésekkel.

Első szint Jelentős bizonytalanság jellemzi a különböző viszonylag egyszerű projektekben a folyamatok összetételében és tartalmában, ezért a dokumentumban nem kommentálunk. Ezért a folyamatok tartalmának tisztázásakor és részletezésekor szakaszos változatban CMMI ajánlott korlátozni négy fő szint:

• második szint- formalizálja alapvető menedzsment projektek:
  • követelménykezelés;
  • projekt tervezés;
  • projekt monitoring és ellenőrzés;
  • beszállítókkal kötött megállapodások kezelése;
  • folyamatok és termékek mérése és elemzése;
  • a folyamatok és termékek minőségének biztosítása;
  • konfiguráció-menedzsment;
• harmadik szint- tartalmazza a fő folyamatok szabványosítását:
  • követelményfejlesztés;
  • műszaki megoldások;
  • termékintegráció;
  • igazolás;
  • érvényesítés (tanúsítás);
  • a szervezeti folyamatok tartalma;
  • a szervezeti folyamatok meghatározása;
  • képzés szervezése;
  • projektfolyamatok és termékek integrált kezelése;
  • Kockázatok kezelése;
  • a fejlesztőcsapat integrációja;
  • integrált beszállítói menedzsment;
  • problémák elemzése és megoldása (hibaelhárítás);
  • az integrációs környezet megszervezése;
• negyedik szint- meghatározza a mennyiségi gazdálkodást:
  • a folyamatok minőségi képviseletének megszervezése;
  • a teljes projekt és erőforrások mennyiségi kezelése;
• ötödik szint- optimalizálás, folyamatos fejlesztés:
  • szervezés, innováció, folyamatok mennyiségi kezelése és erőforrások biztosítása;
  • a hibák okainak elemzése, a folyamatok és termékek minőségének és menedzselésének javítása.

A modell második verziójában található alkalmazások összetételében hasonlóak az első modell fenti alkalmazásaihoz. Minden magasabb érettségi szinten ajánlott jelentkezni minden folyamatot korábbi alsóbb szintek. A modell mindkét változatában az egyes fentebb kiemelt alapfolyamatokat a gyakorlati megvalósításukra vonatkozó részletes ajánlások kommentálják, amelyek mintegy 20-30 oldalas leírásokat tartalmaznak egységes szerkezetben:

• az elérendő folyamat átfogó céljai;
• bevezető megjegyzések és a folyamatfunkciók általános leírása;
• konkrét folyamatcélok;
• folyamatmenedzsment;
• folyamatkövetelmények kialakítása;
• interakció és interfészek más folyamatokkal;
• gyakorlati célok - a folyamattevékenységek szükséges eredményei;
• cselekvések tervezése egy adott folyamatban;
• a folyamat megvalósításának eredményeinek elemzése és validálása (jóváhagyása);
• a folyamat nyomon követése és ellenőrzése.

Ezek az ajánlások az alapfolyamatok leírásának terjedelmét, tartalmát és teljességét tekintve hasonlóak a PS Life Cycle Profile-ra vonatkozó számos szabványhoz, amelyet itt mutatnak be. Az alkalmazott folyamatok teljességének az érettségi szinteknek megfelelő megrendelése és értékelése lehetővé teszi a vállalkozások - szoftvertermékek fejlesztői - termelési potenciáljának megállapítását a folyamatok előre jelzett minősége és tevékenységük eredményei, valamint a tanúsításra való felkészültség tekintetében. a modell bizonyos érettségi szintjének való megfelelés CMMI - 1.1.

A hangsúly a modelleken CMMI a PS projekt irányítási folyamataihoz tartozik. A modellek ezen követelményei és folyamatai gyakorlatilag megfelelnek a szabványokban foglalt szabályozott és részletes ajánlásoknak. ISO 9001:2000 valamint a komplex PS-életciklus-szabványok profiljának fő összetevői [, ]. Követelmények a szabványok 4-8. funkcionális szakaszaiban szereplő folyamatokra ISO 9001, ISO 9004, ISO 90003 a modellben számos tartalmilag megfelelő szakasz összehasonlítható CMMI(az 1. ábrán a tartalmi átfedési zóna). A folyamatok és követelmények közössége a hasonlóságban rejlik: összetétel, terminológia, struktúra, ajánlott irányítási folyamatok listája, tervezés, rendelkezésre álló erőforrások elszámolása, szoftverfejlesztési folyamatok megvalósítása, szakemberek értékelése és szervezése.

1. ábra A szabványok és lejárati modellek folyamatainak és követelményeinek közössége

A nagy szoftverprojektek teljes életciklusának támogatása, szabályozása szempontjából a modellek hiányosságai CMMI a meglévő szabványok profilját illetően ISO a következőket tartalmazhatja:

A fent bemutatott PS életciklusát biztosító folyamatok érettségi szintjének meghatározására kiterjedt műszaki jelentést dolgoztak ki és hagytak jóvá 1998-ban. ISO 15504, amely kilenc részből és számos alkalmazásból áll. Felvázolja az érettségi modellt CMMés nyolc alapelvek szabványon alapuló szoftverfejlesztés ISO 9000:2000. Aztán be ISO ezt a dokumentumot a célok és a koncepció maradéktalan megtartása mellett a szerkezet és a tartalom radikális átdolgozása, csökkentése, egyszerűsítése és jóváhagyása szabvány szerintöt részben.

Alapértelmezett ISO 15504:1-5:2003-2006 szabályozza a vállalkozások által végzett szoftvereszközök és rendszerek létrehozási, karbantartási és fejlesztési folyamatainak érettségének felmérését és tanúsítását:

• hogy megteremtse a saját állapotát technológiai folyamatokés fejlesztésük;
• annak meghatározása, hogy a saját folyamatok megfelelnek-e bizonyos követelményeknek vagy vevői követelmények osztályainak;
• teljesítőképességére való tekintettel bizonyos szerződések PS és rendszerek vásárlóival.

A szabvány hozzájárul: a vállalkozások érettségének önértékeléséhez, a tanúsított folyamatok megfelelő kezelésének biztosításához, a folyamatminősítések profiljának meghatározásához, valamint az operációs rendszer és rendszer bármely hatóköréhez és méretéhez illeszkedik. A szabvány alkalmazása a vállalkozások és a szakemberek fejlesztését célozza a folyamatos fejlesztés technológiai érettségének kultúrája a PS projektek üzleti céljainak megfelelő életciklusának biztosítása és a rendelkezésre álló erőforrások felhasználásának optimalizálása. A vállalati folyamatok érettségének felmérése lehetőséget ad ezek összehasonlítására és kiválasztására, amelyek bizonyos projekteknél előnyösebbek:

• vevők, vásárlók, szoftvertermékek és -rendszerek felhasználói számára: a szállító életciklus-folyamatainak jelenlegi és potenciális érettségének meghatározása;
• szállítók és fejlesztők számára: saját szoftvereik és rendszereik életciklus-folyamatai, folyamatfejlesztési területei és prioritásai jelenlegi és potenciális érettségének meghatározása;
• érettségi értékelők számára: az értékelési folyamatok lebonyolításának és fejlesztésének kerete.

A szabványban való jóváhagyással foglalkozik két szempont: egy adott vállalkozás PS és rendszereinek életciklus-folyamatainak javítása, valamint annak megállapítása, hogy a projekt vagy a vállalati támogatási folyamatok deklarált érettsége megfelel-e a ténylegesen alkalmazott folyamatoknak. Ezt tükrözi a szabvány következő öt része. ISO 15504:1-5:2003-2006.

1. rész - Fogalom és szókincs.Általános információkat tartalmaz a szoftverek és rendszerek érettségének tanúsítási folyamatairól, valamint ajánlásokat a szabvány egyes részeinek használatára vonatkozóan. Körvonalazva Általános követelmények a tanúsítás, a terminológia, a struktúra tekintetében meghatározzák a szabvány többi részének hatályát.

2. rész - A tanúsítás teljesítése (gyártása). Részletes követelményeket tartalmaz a tanúsítási folyamatok lefolytatására vonatkozóan, amely a PS és a rendszerek életciklusát biztosító technológiai folyamatok fejlesztésének és érettségi szintjének meghatározásának alapja. A dokumentum meghatározza a tanúsítás végrehajtásának folyamatait, modelljeit az ajánlott tanúsítási folyamatokhoz és a folyamatok ellenőrzéséhez, hogy azok objektívek, értelmesek és reprezentatívak legyenek.

3. rész - Útmutató a tanúsítvány elkészítéséhez.Áttekintést ad az érettségértékelési folyamatok végrehajtásának és a követelmények megvalósításának értelmezésének technológiájáról. Ez tükrözi: a tanúsítás teljesítését; mérőeszközök az érettségi folyamatok meghatározásához; tanúsítási eszközök kiválasztása és alkalmazása; a tanúsítók kompetenciájának felmérése; annak ellenőrzése, hogy a tanúsítvány megfelel-e a bejelentett követelményeknek. A validációs eszközöket a vállalkozások szoftvertermékek és -rendszerek tervezése, menedzselése, monitorozása, ellenőrzése és fejlesztése során, azok beszerzésében, fejlesztésében, alkalmazásában és karbantartásában használhatják.

4. rész – Felhasználói útmutató a folyamatfejlesztéshez és a folyamatok érettségéhez ebben a két vonatkozásban. Számos lépést javasolunk, amelyek magukban foglalják: a validációs folyamatok eredményeinek alkalmazása; érettségi értékelési célok kitűzése; kezdeti adatok meghatározása a tanúsításhoz; az ebből eredő kockázatok lehetséges csökkentésének értékelése; lépések a folyamatok javítására; lépések az érettség szintjének meghatározására; a minősítési elemzés eredményeinek összevetése a követelményekkel.

5. rész - A 2. részben bemutatott követelményeknek való megfelelés tanúsítási folyamatainak mintamodellje. Egy terjedelmes dokumentum (162 oldal) gyakorlati példákat ad a szabvány előző részeire az életciklus-folyamatok érettségi felméréseinek szervezésére, értékelésére és javítására különböző alkalmazási területek, szoftverprojektek és vállalkozások számára.

A projektek gyakorlati megvalósítása és a komplex szoftverek életciklusának biztosítása során a fejlesztők és a beszállítók esetenként nehezen tudják azonosítani és kiemelni az alkalmazási modellek előnyeit. CMMI. A vállalkozás hagyományaitól és egy nagy projekt jellemzőitől függően gyakran tanácsos a PS-t használni fő teljes szabványos profilISO, és az ügyfelek értékelésére érettségi szint A PS projektek irányítása, szervezési és technológiai támogatása konkrét ajánlásokat alkalmaz CMMI. Ezeket az irányelveket hatékonyan lehet alkalmazni folyamatminőségi tanúsítás a PS életciklusát biztosító vállalkozásoknál, alternatívaként vagy irányítási szabványok szerinti tanúsítással együtt ISO 9000, a projekt sajátosságaitól és a szoftvertermék vagy technológia életciklusát biztosító tanúsítást igénylő követelményeitől függően.

Szoftvertermékek tanúsításának szervezése

A tanúsítás egy sor szervezeti folyamatból áll, amelyek alkotják tanúsítási rendszer, ezeket a folyamatokat szabályozott eljárások és dokumentumok támogatják, és képzett, minősített szakértőknek - ellenőröknek kell elvégezniük. A vállalkozás-fejlesztő tanúsításához és tevékenységének eredményeihez - szoftvertermékek, modellek CMMI vagy szabványos profilok ISO[ , ] egy bizonyos tudományág ajánlott, amelyet a PS életciklusának tárgyi adottságaihoz és környezetéhez kell igazítani. Az alább felsorolt ​​folyamatok és dokumentumok nagy projektekhez készültek, és egyszerűbb esetekben a fejlesztők, ügyfelek és tanúsítók megállapodása alapján csökkenthetők.

A tanúsítási munka egy testület vagy vizsgálólaboratórium akkreditálásával, kérelem és dokumentumcsomag kialakításával és benyújtásával kezdődik a Központi Tanúsító Szervezethez, hogy döntést hozzon az akkreditáció megvalósíthatóságáról. Pozitív vizsgálati eredmények esetén akkreditációs tanúsítványt állítanak ki és állítanak ki.

A tanúsító szervezetre vagy laboratóriumra vonatkozó előírások a fő dokumentum, amely meghatározza az akkreditáció tárgykörét, a jogállást, a funkciókat, a struktúrát, a jogokat és kötelezettségeket, a tesztek módszereit, eszközeit és megszervezését. A tanúsító laboratórium (központ) útlevelének tartalmaznia kell a berendezésre vonatkozó információkat Számítástechnika a teszteléshez szükséges személyzetről és személyzetről, vizsgálóeszközökkel ellátott berendezésekről, szabályozási, műszaki és módszertani dokumentumok, valamint a teszteléshez szükséges egyéb erőforrások biztosítása.

Minőségi árajánlat tartalmazza az alapelveket, a tanúsító szervezet vagy laboratórium fő funkcióinak és feladatainak végrehajtásához kapcsolódó módszerek és eljárások leírását, biztosítva a vizsgálatok minőségét, valamint az értékelések, tesztek és vizsgálatok eredményeibe vetett bizalmat. A minőségügyi kézikönyv általában [ TWLSC$

• politika a tesztelések és vizsgálatok minőségbiztosítása terén;
• a központ felszerelése megfelelő módszertani anyagokkal és szoftverekkel és tesztelő eszközökkel;
• a tesztobjektumokra vonatkozó követelmények formalizálása;
• politika a központ technikai felszerelése és a személyzet fejlesztése terén;
• a tanúsítási eredmények dokumentálásának archiválása és biztonsági ellenőrzése.

A tanúsítás alá eső termékek vagy eljárások értékelésére a kérelmező a tanúsítási rendszerben elfogadott formában kérelmet küld a tanúsító szervezetnek. A tanúsító szervezet igény szerint végzi a terméktanúsítás előkészítését és megszervezését. Ez a munka a következőket tartalmazza:

• tanúsítási séma kiválasztása a termékek sajátosságait (mennyiség, technológia, szabályozó dokumentumok követelményei stb.) és a fejlesztő javaslatait figyelembe véve;
• a mintavételek és a vizsgálandó alkatrészek számának és sorrendjének meghatározása, ha ezt a szabvány nem írja elő;
• a vizsgálatok elvégzésére akkreditált vizsgálólaboratórium kiválasztása és azonosítása;
• munkavégzésre vonatkozó szerződéstervezet elkészítése.

A tanúsítással kapcsolatos munka előkészítő része a tanúsítási rendszerben elfogadott formájú határozat kiadásával zárul. A határozatot a munkavégzésre vonatkozó szerződés tervezetével együtt megküldik a kérelmezőnek. A tanúsítási tesztek megszervezése során a tanúsításra bejelentett termékekre vonatkozó hatályos szabályozási dokumentumok kiválasztása és tanulmányozása, a vizsgálati módszerek és az eredmények értékelése történik.

A kérelmező hozza meg a végső döntést, hogy a minőségbiztosítási rendszer mely elemei, területei, szervezési és műszaki tevékenységei tartoznak az adott időintervallumban történő tanúsítás során igazolásra. A kérelmezőnek feltételeket kell teremtenie és dokumentumokat kell benyújtania az ellenőrzési folyamatok biztosításához. Benyújthatja a tanúsító szervezetnek a termékek fejlesztése és gyártása során elvégzett vizsgálati jelentéseket, a harmadik fél vizsgálólaboratóriumai által végzett vizsgálatokról szóló dokumentumokat és egyéb olyan dokumentumokat, amelyek jelzik a technológia vagy termékek megfelelését a megállapított követelményeknek. A tanúsító szervezet a kérelemmel együtt bemutatott, termékei előírt követelményeknek való megfelelőségét dokumentált bizonyítékok elemzése alapján dönthet a vizsgálatok körének szűkítéséről vagy tanúsítvány kiadásáról.

A vizsgálatokat csak olyan vizsgálatok elvégzésére akkreditált vizsgálólaboratóriumok végzik, amelyeket a hatósági, akkreditációs dokumentumaik előírnak. Ha egy akkreditált laboratórium vizsgálóhelyiségében nem lehetséges a vizsgálatokat lefolytatni, a vizsgálatokat ennek a laboratóriumnak a személyzete végezheti el a termék gyártójánál vagy fogyasztójánál a vizsgálólaboratórium saját létesítményei vagy a szállítótól rendelkezésre álló vizsgálóberendezések segítségével. .

A szoftvertermékek és vállalati minőségbiztosítási rendszerek tanúsításának folyamata a következőket tartalmazza:

• a fejlesztő vagy a megrendelő (pályázó) elemzése és kiválasztása az e területen illetékes testület és egy minősített laboratórium számára a tanúsítási vizsgálatok elvégzésére;
• a kérelmező vizsgálati kérelmének benyújtása a tanúsító szervezethez, és a tanúsítók által a kérelemmel kapcsolatos határozat elfogadása, a tanúsítási rendszer kiválasztása, a tanúsítási megállapodás megkötése;
• a vállalkozás minőségbiztosítási rendszerére és/vagy a tesztelendő szoftvertermék verziójára vonatkozó követelmények azonosítása;
• a vállalat minőségügyi rendszerének vagy a szoftvertermék verziójának tanúsítási tesztjeinek elvégzése a tanúsító laboratórium által;
• a kapott eredmények elemzése és a laboratórium és/vagy tanúsító szervezet döntéshozatala a kérelmező részére megfelelőségi tanúsítvány kiállításának lehetőségéről;
• a tanúsító szervezet által a kérelmező részére - tanúsítványt és engedélyt a megfelelőségi jel használatára és tanúsított termékek kiadására - a szoftvertermék verzióit;
• a vállalkozás és/vagy termékek tanúsított minőségbiztosítási rendszerének tanúsító szervezet általi ellenőrzési ellenőrzésének végrehajtása;
• korrekciós intézkedések végrehajtása a kérelmező által a minőségbiztosítási rendszer és/vagy termékek folyamatainak a megállapított követelményeknek való megfelelőségének megsértése és a megfelelőségi jelzés helytelen alkalmazása esetén.

A fejlesztő vezetőségének termékminőségi felelősségének ellenőrzésekor meg kell határozni, hogy a vállalkozásnak vagy projektnek van-e dokumentált politikája, céljai és kötelezettségei a minőség területén, valamint azt, hogy ezt az irányelvet milyen mértékben értik, hajtják végre és tartják fenn. működőképes állapotban a szervezet minden szintjén. Meg kell állapítani, hogy a vállalkozásnak legyen olyan vezetőségi képviselője, aki egyéb feladatoktól függetlenül jogosult és felelős a minőségbiztosítási rendszer szabványai és szabályozó dokumentumai követelményeinek folyamatos végrehajtásáért. Ellenőrizni kell a követelmények, eljárások, eszközök és képzett személyzet rendelkezésre állását a minőségbiztosítási rendszer folyamatainak gyakorlati megvalósításához, valamint a minőségbiztosítási rendszer összes összetevőjének, követelményének és rendelkezésének relevanciáját és szisztematikus dokumentálását, amely a minőségbiztosítási rendszer egészében integrált folyamat. a PS életciklusa. Minőségügyi rendszer ellenőrzések tartalmaznia kell egy meghatározást:

• a technológiai dokumentáció rendelkezésre állása, teljessége és követelményeinek való megfelelés a gyakorlatban;
• a technológiai berendezések állapota és a karbantartásukra szolgáló rendszer rendelkezésre állása;
• az ellenőrzési és tesztelési rendszer megléte és hatékonysága;
• a mérő- és vizsgálóeszközök állapota;
• a termékekben vagy a technológiában feltárt hiányosságok azonosítására és kiküszöbölésére szolgáló rendszer rendelkezésre állása.

A tesztek alapján kiértékelik a kapott eredményeket, és alátámasztják a termékek vagy folyamatok hatósági dokumentumok követelményeinek való megfelelőségére vagy nem megfelelőségére vonatkozó következtetéseket. A vizsgálati jelentéseket benyújtják a tanúsító szervezetnek, valamint kérésére a kérelmezőnek. A vizsgálati jegyzőkönyveket a terméktanúsítási rendszerek szabályaiban és a vizsgálólaboratórium dokumentumaiban meghatározott ideig, de legalább három évig meg kell őrizni.

A vizsgálólaboratórium szakemberei a dokumentáció átvétele és hiánytalanságának és minőségének ellenőrzése után a minőségbiztosítási rendszer tényleges alkalmazásának mértékének vizsgálata a vállalkozásnál. A tesztelés a minőségbiztosítási rendszer tesztelési programjának kidolgozásával kezdődik, amely munkatervként szolgál a későbbi munkákhoz. A program a tesztelő laboratórium belső munkadokumentuma, és tartalmaznia kell a fejlesztő vállalkozás sajátosságainak megfelelően részletezett munkák listáját, amely tartalmazza a benyújtott forrásdokumentumok teljességének és minőségének elemzését, valamint gyakorlati alkalmazásuk mértékét. a szoftver tervezésében, fejlesztésében és szállításában. A minőségbiztosítási eljárások alkalmazásának vizsgálatát a PS életciklusát biztosító vállalkozás munkahelyein működő vizsgáló laboratórium végzi. Ellenőrzik a megfelelő dokumentumokat kidolgozó szakemberek munkahelyi jelenlétét, valamint rendelkezéseik és ajánlásaik alkalmazásának teljességét. A projekt állapotának felülvizsgálatát és a minőségbiztosítási rendszer, folyamatok és/vagy termékek belső auditjait olyan személyzetnek kell elvégeznie, amely független a munkák végrehajtásáért közvetlenül felelős személyektől.

A fejlesztés minőségének ellenőrzési módszerei biztosítani kell szükséges erőforrásokat a tesztprogram megvalósításához, a tervezési módszerekhez és a privát teszteljárások kidolgozásához. A módszereknek tartalmazniuk kell: a tesztelés tárgyait és céljait; értékelt minőségi mutatók; a vizsgálat feltételei és eljárása; a vizsgálati eredmények feldolgozásának, elemzésének és értékelésének módszerei; technikai támogatás tesztelés és jelentéskészítés. Fel kell tüntetni a tesztek és a vizsgálati eljárás során használt hardvert és szoftvert, valamint az ellenőrzések várható eredményeit. Módszereket kell kidolgozni a korrekciók ellenőrzésére, a hibák kijavítására irányuló intézkedéseket, ha ilyen kérés érkezik az auditirányítási szolgálathoz. A tesztprogram-kezelő szolgálatnak eljárásokat kell kidolgoznia a tesztinformációk, valamint az értékelők által birtokolt adatok titkosságának megőrzésére.

Tesztjelentések benyújtani a kérelmezőnek és a tanúsító szervezetnek. A kérelmező benyújthatja a tanúsító szervezethez azok érvényességi feltételeinek figyelembevételével a termékek fejlesztése és gyártása során elvégzett vizsgálati jegyzőkönyveket, illetve a tanúsítási rendszerben akkreditált vagy elismert hazai vagy külföldi vizsgálólaboratóriumok által végzett vizsgálatokról szóló dokumentumokat. Tanúsítási vizsgálati jegyzőkönyvek alapján a kapott eredményeket értékelik, és alátámasztják a termékek hatósági dokumentumok követelményeinek való megfelelőségére vagy nem megfelelőségére vonatkozó következtetéseket.

Következtetés a tanúsítási tesztek eredményeiről tanúsítók dolgozzák ki, és általános információkat tartalmaz a vizsgálati eredményekről és a tanúsítvány kiállításának indoklásáról. A tanúsítási tesztek negatív eredménye esetén a megfelelőségi tanúsítvány kiadásának megtagadásáról döntenek. A tanúsított termék vagy minőségbiztosítási rendszer befejezése után a tesztek megismételhetők. A technológia állása vagy a termékminőség elemzésének eredményei törvény állítja össze, amely becsléseket ad a Tesztprogram összes pozíciójára, és következtetéseket tartalmaz, beleértve a gyártás és a termékek állapotának általános értékelését, a korrekciós intézkedések szükségességét. Az aktust a tanúsító szervezet a vizsgálati jegyzőkönyvekkel, a szoftvertermék tanúsítványának kiállítására és érvényességi idejének meghatározására, az ellenőrzések gyakoriságára vonatkozó kérelemmel, valamint a korrekciós intézkedések kidolgozására használja fel.

A tanúsítási vizsgálatok eredményei és a dokumentáció vizsgálata alapján döntés születik a tanúsítvány kiadásáról. A minősítő tesztek negatív eredménye esetén döntés születik az igazolás kiadásának megtagadása megfelelés. Ezen túlmenően javaslatokat lehet küldeni a pályázó vállalkozásnak a negatív vizsgálati eredmények feltételezett okainak megszüntetésére, a tanúsított termékek elkészülte után a vizsgálatok megismételhetők.

A tanúsító szervezet a vizsgálati jegyzőkönyvek elemzése, a gyártás értékelése, a minőségbiztosítási rendszer tanúsítása, a pályázati határozatban meghatározott dokumentáció elemzése után értékeli a termékek megfelelőségét a megállapított követelményeknek, szakértői véleménye alapján tanúsítványt állít ki. és regisztrálja. A tanúsítás során tanúsított rendszer vagy szoftvertermék minőségét befolyásoló terv- vagy üzemeltetési dokumentáció módosításakor a kérelmező köteles erről értesíteni a tanúsító szervezetet, hogy a további vizsgálatok szükségességéről döntsön. A regisztrációt követően a tanúsítvány hatályba lép, és megküldésre kerül a kérelmező cégnek. Az igazolás kiállításával egyidejűleg a pályázó vállalkozás kibocsátására kerülhet sor engedély a megfelelőségi jel használatának jogáért.

Tanúsított szoftvertermékek esetében azok működése során a megfelelőségi tanúsítvány teljes érvényességi ideje alatt, ellenőrzés ellenőrzése. Az ellenőrzési ellenőrzést időszakos és nem tervezett ellenőrzések a technológia és a tanúsított termékek minőségére vonatkozó követelmények betartása. Az ellenőrzés tárgya a tanúsítási rendszertől függően a tanúsított termékek, a minőségbiztosítási rendszer vagy a fejlesztő gyártási stabilitása. Az ellenőrzés gyakoriságának és mértékének meghatározásakor a következő tényezőket veszik figyelembe: a szoftvertermék potenciális veszélyességének mértéke, a gyártás stabilitása, a kiadás mennyisége, a minőségbiztosítási rendszer elérhetősége és alkalmazása a fejlesztés során, információk a gyártó, az állami ellenőrző és felügyeleti szervek által a termékre és annak előállítására végzett vizsgálatok eredményeiről.

Az ellenőrzési ellenőrzés eredményei törvény állítja össze, amely a mintavizsgálatok és egyéb ellenőrzések eredményeit értékeli, általános következtetést von le a tanúsított termékek gyártási állapotáról és a kiadott tanúsítvány érvényességének fenntartásának lehetőségéről. Az okiratot a tanúsító szervezet tárolja, másolatait megküldi a fejlesztőnek és az ellenőrzésben részt vevő szervezeteknek. Az ellenőrzési ellenőrzés eredménye alapján a tanúsító szervezet felfüggesztheti vagy visszavonhatja a tanúsítvány érvényességét, valamint visszavonhatja a megfelelőségi jelölés használatára vonatkozó engedélyt, ha a termékek nem felelnek meg a tanúsítás során ellenőrzött hatósági dokumentumok követelményeinek. , valamint a következő esetekben:

• alapvető változások az érettségi modellben, a szabványprofilban, a termékszabályozásban vagy a vizsgálati módszerben;
• változások a termékek kialakításában (összetételében), teljességében;
• változások a fejlesztés és a gyártás szervezetében vagy technológiájában;
• a technológia, az ellenőrzési és vizsgálati módszerek, a minőségbiztosítási rendszer követelményeinek való meg nem felelés, ha a felsorolt ​​változtatások a termékek tanúsítás során ellenőrzött követelményeknek való nem megfelelőségét okozhatják.

Nem születik döntés a megfelelőségi jel használatára vonatkozó tanúsítvány és engedély érvényességének felfüggesztéséről, ha a kérelmező az azt kibocsátó tanúsító szervezettel egyeztetett korrekciós intézkedésekkel meg tudja szüntetni a nem megfelelőség észlelt okait és megerősíti. , akkreditált laboratóriumban történő újbóli vizsgálat nélkül, a termék vagy folyamatok normatív dokumentumoknak való megfelelőségét. Ha ezt nem lehet megtenni, akkor a tanúsítvány érvényessége törlésre kerül, és a megfelelőségi jelzés használatára vonatkozó engedély is megszűnik. A tanúsítvány felfüggesztéséről vagy visszavonásáról az azt kiállító tanúsító szervezet tájékoztatja a kérelmezőt, a fogyasztókat és más érdekelt szervezeteket. A tanúsítvány érvényessége és a termékek megfelelőségi jelzéssel való címkézésének joga megújítható, ha a fejlesztő vállalkozás teljesíti az alábbi feltételeket:

• a meg nem felelés okainak feltárása és megszüntetése;
• jelentés benyújtása a tanúsító szervezetnek a termékminőség javítása és biztosítása érdekében végzett munkáról;
• a termékek további tesztelése a tanúsító szervezet módszerei szerint és ellenőrzése mellett, és pozitív eredmények elérése.

Szoftvertermékek tanúsítási folyamatainak és eredményeinek dokumentálása

A minőségbiztosítási rendszer tanúsításához szükséges dokumentáció összetétele és tartalma a vállalkozások a szoftverek tervezésének, fejlesztésének és módosításának jellemzőitől, valamint azok minőségi követelményeitől és a technológiai környezet jellemzőitől függenek. Ezért minden vállalkozáshoz vagy projekthez ki kell választani a szükséges dokumentumkészletet, és ezekhez a jellemzőkhöz kell igazítani. A minőségbiztosítási rendszer tanúsítás során értékelt mutatói a vonatkozó dokumentumok rendelkezésre állása, valamint az érettségi modell egy bizonyos szintjére vonatkozó követelmények gyakorlati teljesítése. SMMI vagy egy adaptált szabványprofil alapján ISO 9000:2000, valamint ezek alapján készültek, munkaköri leírások a vállalkozás-fejlesztő szakemberei. A kérelmezőnek el kell készítenie és be kell nyújtania a vizsgálólaboratóriumnak a megrendelő és a fejlesztő között egyeztetett és jóváhagyott dokumentumcsomagot, amely igazolja azok megbízhatóságát, megfelelő összetételét és kivitelezését a szabályozási dokumentumokkal összhangban.

A tanúsításhoz szükséges alapdokumentumok indikatív készlete három csoportból áll:

• alapvető előírások alapján a szabványok nómenklatúrájának és tartalmának megfelelő minőségbiztosítási rendszerek ISO 9000:2000 vagy lejárati modellek SMMI, valamint az ezek alapján a fejlesztők által elkészített, az ellenőrzött vállalkozás minőségügyi rendszerének vagy termékeinek tesztelőinek (szakértőinek) bemutatott programot, kézikönyvet és utasításokat;
• egy adott vállalkozást vagy projektet, valamint egy szoftvereszköz életciklusát jellemző forrásdokumentumok, amelyeket a projektvezetés minőségi tanúsítása céljából készített;
• a tesztelőknek a vállalkozás minőségbiztosítási rendszerének és/vagy szoftvertermékének auditálásának (tanúsításának) eredményeit tükröző, a tanúsító szervezetnek, a kérelmezőnek és az auditált vállalkozás vezetésének benyújtott jelentési dokumentumai.

A tanúsításra benyújtott szoftverterméket vagy vállalati minőségbiztosítási rendszert a vonatkozó dokumentációval együtt kell benyújtani. E dokumentumok csoportjainak listája és hozzávetőleges tartalma a nagy szoftvertermékek életciklusát biztosító vállalkozások minőségi rendszereinek ellenőrzésének általános esetére összpontosít. A dokumentumkészlet a kérelmező, a tanúsító és az ellenőrzött vállalkozás vezetése közötti megállapodás szerint szűkíthető és módosítható, a szoftverprojektek jellemzőinek megfelelően. Egyes dokumentumok integrált jelentésekké kombinálhatók, amelyek végrehajtásáért bizonyos szakemberek egyértelműen felelősek.

A vállalati minőségbiztosítási rendszer és szoftver életciklusának alapdokumentumai

1. Koncepció, terminológia, követelmények és útmutató a teljesítmény javításához - minőségirányítási rendszerek - ISO 9000:2000 vagy a CMMI érettségi modell egy változata.
2. A szabványok adaptált változatai vagy szakaszainak listája és ajánlásai ISO 12207, ISO 15504, azok változásai és alkalmazási irányelvei, amelyeket az adaptáció során választanak ki, és kötelezőek egy adott vállalat vagy szoftvertermék projekt minőségbiztosítási rendszerében.
3. A szabvány adaptált változata vagy szakaszainak listája és ajánlásai ISO 900003, az adaptáció során kiválasztott és szoftverterméket előállító vállalkozás minőségbiztosítási rendszerében kötelezően használni.
4. A PS projekt alapvető jellemzői és minőségi jellemzői, szabványok alapján azonosítva, adaptálva és specifikálva ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. A karbantartási és konfigurációkezelési kézikönyv adaptált változata és jóváhagyott kiadása a szabványok ajánlásai alapján ISO 14764, ISO 10007, ISO 15846.
6. Munkaköri leírások készlete, amely meghatározza a vállalati minőségbiztosítási rendszer eljárásaiban részt vevő összes vezető, végrehajtó és ellenőrző személyzet felelősségét, hatáskörét és együttműködési eljárását egy adott PS projekt esetében.

Egy adott szoftvereszköz életciklusának jellemzőit tükröző forrásdokumentumok

1. A PS projekt és a vállalati minőségbiztosítási rendszer szabványainak és követelményeinek adaptálásához, munkaverzióinak elkészítéséhez szükséges, a vállalkozásnál létrehozott szoftvertermékek jellemzőinek leírása, a rendszer és az életciklusuk külső környezete. szabványok ajánlásait ISO 12207, ISO 15504, ISO 90003és ISO 9126.
2. A vállalkozás-fejlesztő céljainak, követelményeinek és kötelezettségeinek ismertetése a minőségi rendszer területén, a fejlesztési folyamatok és termékek minőségi kritériumai, szállítása és támogatása a szoftver teljes életciklusára vonatkozóan.
3. Működési dokumentumok készlete, amelyet az ügyfelek és a felhasználók rendelkezésére bocsátanak, hogy biztosítsák a szoftvertermék adott verziójának életciklusát és használatát az adaptált szabványok alapján ISO 9294, ISO 15910, ISO 18019.
4. A szoftvertermékek életciklusának biztosítására használt dokumentációs és automatizálási eszközök tervezéshez, fejlesztéshez, módosításhoz, vezérléshez és teszteléshez.
5. Tervek és módszerek az alkalmazás tesztelésére és a folyamatok hatékonyságának értékelésére a vállalat minőségügyi rendszerében és a szoftvertermékben.
6. Karbantartási módszerek, szoftvertermék-összetevők azonosítása és dokumentációja, szoftverek és adatkomplexumok verzióinak elemzése és jóváhagyása.
7. A szoftvertermék-verziók és a kísérő dokumentumok konfigurációkezelésének, jóváhagyásának, tárolásának, védelmének, másolásának, valamint a vállalati archívumban regisztrált minőségi jellemzőkre vonatkozó adatok felhalmozásának és tárolásának módszertana a szoftvertermék verziók életciklusa során.

Az így kapott tesztdokumentumok - a vállalat és/vagy szoftvertermék minőségbiztosítási rendszerének tanúsítása

1. Jelentés a vállalati minőségbiztosítási rendszer követelményeihez és előírásaihoz igazodó dokumentáció elérhetőségéről, relevanciájáról és szisztematikus végrehajtásáról, amely integrált minőségbiztosítási folyamatot biztosít a szoftvertermék teljes életciklusa során.
2. A minőségbiztosítási rendszer állapotának és alkalmazásának monitorozásának és tesztelésének eredményei, időszakosan elvégzve annak alkalmasságának és eredményességének megállapítása érdekében.
3. Jelentés az ellenőrzések lebonyolítására szolgáló módszerek elérhetőségéről és karbantartásáról, valamint dokumentált jelentések az ügyféllel kötött tanúsítási megállapodás követelményeinek teljesítésének elért minőségéről.
4. A szoftvercsomag elért minőségi jellemzőinek nyilvántartásba vételének eredményei: a szoftvertermék és összetevői minőségi jellemzőiről, attribútumairól regisztrált adatok azonosítása, felhalmozása, tárolása.
5. A fejlesztési terv megvalósításának eredményei, a fejlesztési szakaszok dokumentált bemeneti és kimeneti adatai, valamint a PS életciklusának megvalósulását ellenőrző protokollok.
6. A minőségi program gyakorlati megvalósításának és a minőségügyben szabályozott tevékenységek végrehajtásának eredményei a PS életciklusának minden szakaszában.
7. Környezetszimulátorok és tesztgenerátorok tanúsításának eredményei, valamint azok alkalmasságának felmérése egy szoftvertermék tanúsítási tesztjének elvégzéséhez.
8. A tervek és vizsgálati módszerek végrehajtásának elemzésének eredményei, vizsgálati jegyzőkönyvek, a vizsgálati eredmények követelményeknek való megfelelőségének értékelései, valamint a kérelmező, a megrendelő és a szállító képviselői által jóváhagyott vizsgálati eredmények.
9. A szoftverrendszer életciklusa és a vállalat minőségbiztosítási rendszere valós jellemzőinek ellenőrzésének eredményei, következtetések a szoftvertermék gyártásának tanúsítására vonatkozó követelményeknek való megfelelésükről.
10. A vállalkozás és/vagy szoftvertermék minőségbiztosítási rendszerének és életciklusának biztosítására vonatkozó tanúsítvány, engedély a megfelelőségi jelzések használatára.

Irodalom

V.V. Lipaev -- Szoftver életciklus-szabvány profilok. -- Jet Info, Hírlevél, N 12, 2005

K. Milman, S. Milman -- Az SMMI egy lépés a jövőbe. -- nyílt rendszerek., N 5-6. (2005), N2. (2006), 2005, 2006

Szoftvereszközök és információs rendszerek létrehozására és karbantartására szolgáló folyamatok érettségének értékelése és tanúsítása ISO IEC TR 15504-CMMI. Per. angolról -- M.: Könyv és üzlet, 2001

V.V. Lipaev -- A komplex szoftverek életciklusának folyamatai és szabványai. Könyvtár.-- M.: SINTEG, 2006

V.V. Lipaev -- Módszerek a nagyméretű szoftverek minőségének biztosítására.-- M.: RFBR. SINTEG, 2003

"; antisource: "A szoftvertermékeket ma már vezetési problémák megoldására használják az emberi tevékenység szinte minden területén: a gazdaságban, a szociális, katonai és egyéb területeken. Stratégiai feladattá vált a hazai szoftvertermékek magas minőségének biztosítása azok tömeges fejlesztése és szállítása során különböző alkalmazásokhoz az országban és a világpiacon."; feltétel: 1]$

Megjegyzés: A fejlesztési folyamatok javításának talán legismertebb módszertana mögött meghúzódó gondolatkört részletesen tanulmányozzuk. szoftver- SMM. Elemezzük a HMM logikáját és szerkezetét. Bemutatjuk a HMM és a korábban vizsgált folyamatmodellek közötti kapcsolatot.

keretein belül készült csodálatos praktikus eszköz folyamat megközelítés a tevékenység leírásához tervező szervezet különösen a fejlődő szervezet Információs rendszerek , bemutatja a HMM módszertant. A CMM a Capability Maturity Model rövidítése, ami nagyjából azt jelenti, hogy "menedzsmentrendszer érettségi modellje". A szakirodalomban a CMM-et inkább szervezeti érettségi modellnek nevezik, és én is ezt a hagyományt követem.

Az SMM megjelenésének története a következő. A 80-as évek végén. múlt században az Egyesült Államok Védelmi Minisztériuma elrendelte az Institute of Software Engineering 1Eng. SEI - Software Engineering Institute A Carnegie Mellon Egyetem a szoftverfejlesztési projektek alvállalkozóinak kiválasztásának kritériumrendszerén dolgozik. A munka 1991-ben fejeződött be, és az eredmény a CMM lett. Azonnal fenntartással kell élnünk, hogy a modell nem tartalmaz pénzügyi, gazdasági, politikai, szervezeti jellegű kiválasztási feltételek alvállalkozót, valamint a titkos munkára bocsátás feltételeit (valószínűleg ilyen feladatokat nem tűztek ki). Csak olyan kritériumokról beszélünk, amelyek leírják a potenciális alvállalkozó fejlesztési képességét szoftverrendszerek.

CMM szerkezet

A modell megalkotói a szervezet folyamatait vették alapul a szervezet minőségi munkavégzési képességének felméréséhez, amelyet (képességet) érettségnek neveztek. Aztán megfogalmaztak néhány nem triviális feltevést, amelyeket később sok informatikai szakember (és talán legtöbbjük) elfogadott és tisztességesnek ismert el.

1. feltételezés. Az érettségnek minőségileg különböző szintjei vannak tervező szervezet fejlesztés Információs rendszerek(a HMM modellben öt ilyen szint van).

2. feltételezés. Bármely fejlesztő szervezet érdekelt a magasabb érettségi szintre lépésben (nem csak azért, hogy esélyeit növelje a Honvédelmi Minisztérium szerződésekért folytatott harcában, hanem azért is, hogy saját magát javítsa).

3. feltételezés. Az átmenet csak sorrendben lehetséges a következő szintre. A szintet nem lehet „átugrani” (pontosabban a szervezet kockázatai ugyanakkor meredeken megnövekednek).

Így a szintek egy "létrát" alkotnak, amely mentén a szervezet emelkedik saját fejlesztés. Minden szintre jellemző a szervezeti folyamatok bizonyos összetétele és tulajdonságai. Az SMM "Szintlétra" széles körben elfogadott és terjesztett. Íme, hogy néz ki.

1. szint "Kezdő". A gyártási folyamat egészére jellemző, hogy minden alkalommal egy adott projekthez jön létre, sőt néha kaotikus. Csak néhány folyamat van meghatározva, és a projekt sikere az egyének erőfeszítéseitől függ.

2. szint "Ismételhető". Kialakították a fő projektmenedzsment folyamatokat, amelyek lehetővé teszik a költségek nyomon követését, a munka ütemezésének és a készülő szoftvermegoldás funkcionalitásának figyelemmel kísérését. Létrehozta azt a folyamatfegyelmet, amely a hasonló alkalmazásfejlesztési projektekben elért múltbeli sikerek megismétléséhez szükséges.

3. szint "Határozott". A gyártási folyamat mindkét esetben dokumentált és szabványosított vezetői munka valamint a tervezéshez. Ez a folyamat beépül a szervezet szabványos gyártási folyamatába. Minden projekt a szervezet szabványos működési folyamatának jóváhagyott testreszabott verzióját használja.

4. szint "kezelt". A gyártási folyamatról és a készülő termék minőségéről részletes mennyiségi mutatókat gyűjtenek. Mind a gyártási folyamatot, mind a termékeket mennyiségi szempontból értékelik és ellenőrzik.

5. szint "Optimalizálás". A folyamatok folyamatos fejlesztése kvantitatív módon történik Visszacsatolás a folyamattal és a fejlett ötletek és technológiák megvalósításával benne.

A szigorúság hiánya ellenére a fenti meghatározás intuitív módon legtöbbször nem emel kifogást. Ráadásul a tapasztalt szakemberek megértik, hogy miért csak a következő szintre lehet áttérni, és miért érdemes egyáltalán ilyen átmenetre törekedni. Ugyanakkor a HMM modell sem mennyiségi, sem formai alátámasztást nem tartalmaz egy ilyen megközelítésre, ami azonban nem von le érdemeit.

Továbbá, mint mondják, technológia kérdése. Meghatározzuk a modell felépítését (7.1. ábra), megadjuk a definíciókat, és megkezdődik a fáradságos munka az egyes folyamatok pontos leírására minden szinten. Annak érdekében, hogy felmérjük az eddigiek gyakorlati értékét, menjünk végig ezen az úton.

Rizs. 7.1.

ábrán. A 7.1 a következő fogalmakat tartalmazza.

Key Process Group. Amint azt (Paulk, et al., 1995) kifejti, "a kulcsfolyamatok minden csoportja meghatározza a kapcsolódó tevékenységek egy-egy blokkját, amelynek eredményeként olyan célokat érnek el, amelyek jelentősek a termelési folyamat termelékenységének növelése szempontjából. például kulcsfontosságú folyamatok csoportjára " Követelménykezelés"(Lásd: 7.2. ábra) a cél a szoftverfejlesztési projekt követelményeinek egyeztetése a megrendelő és a fejlesztő között."

A CMM-ben nincsenek egyedi folyamatok. Ehelyett vannak egyéni munkák kulcsfontosságú gyakorlatoknak nevezett (lásd alább), bemenetek és kimenetek kapcsolják össze egymással, és az építési folyamatok forrásanyagaként szolgálnak. A CMM nem ad útmutatást a folyamatok felépítéséhez, azaz a kulcsfontosságú gyakorlatok logikai sorozatokba kapcsolásához. A kulcsgyakorlatok halmazait kulcsfolyamat-csoportoknak nevezzük.

Rizs. 7.2.

A CMM kulcsfolyamatainak csoportjai érettségi szintekre vannak leképezve (7.2. ábra), azaz egy szinten minden gyakorlat csak egymással kölcsönhatásban van, és nem lép kölcsönhatásba más szinteken lévő gyakorlatokkal. Ez lehetővé teszi, hogy egy adott szinten garantálja az összes folyamat teljes körű végrehajtását, és ezáltal a szintet korrelálja a szervezet fejlődésének befejezett szakaszával.

A "kulcs" melléknév arra utal, hogy vannak folyamatcsoportok(azaz gyakorlatok halmazai), amelyek nem kulcsfontosságúak egy adott érettségi szint szempontjából, azaz nem kapcsolódnak e szint céljainak eléréséhez (lásd alább). A HMM modell nem ír le mindent folyamatcsoportok szoftverek fejlesztésével és karbantartásával kapcsolatban. Csak azokat a csoportokat írja le, amelyek a termelési folyamat termelékenységének kulcsfontosságú meghatározói.

Gólok. A CMM céljai nem folyamatokhoz, hanem kulcsfolyamatok csoportjaihoz kapcsolódnak. Mint fentebb említettük, a célokat kulcsfontosságú gyakorlatok megvalósításával érik el. A CMM-ben a cél elérése azt jelenti, hogy egyrészt a kulcsfontosságú gyakorlatok végrehajtása után a kívánt eredményt, másrészt pedig meglehetősen következetesen elérjük. A Key Process Group céljainak elérésének módja projektenként eltérő lehet a különbségek miatt tárgykörben vagy környezet.

Ha ezek a célok minden projektnél megvalósulnak, akkor ez azt jelenti, hogy a szervezet elérte a termelési folyamat érettségi szintjét, ami korrelál a kulcsfolyamatok ezen csoportjával.

Fejezet. A szekciók (minden szinten öt darab van, és mindig ugyanazok) a kulcsfolyamatok csoportjainak tulajdonságait képviselik, amelyeket a megfelelő szinten kell megvalósítani. Ezek a tulajdonságok azt írják le, hogy a folyamatok hogyan valósulnak meg, és milyen mértékben vannak legalizálva a szervezetben, azaz hivatalosan jóváhagyva és összehangolva a vállalati eljárásokkal, szabályzatokkal és egyéb folyamatokkal. Íme az öt rész.

Teljesítési kötelezettségek

Ismertesse azokat a lépéseket, amelyeket a szervezetnek meg kell tennie annak érdekében, hogy a folyamat megalapozott és stabil legyen. A teljesítési kötelezettségek jellemzően a szervezeti politikák kialakítására és a felső vezetés támogatására vonatkoznak.

Előfeltételek

Ismertesse azokat az előfeltételeket, amelyeknek egy projektben vagy szervezetben meg kell felelniük egy gyártási folyamat kompetens megvalósításához; általában az erőforrásokhoz, a szervezeti struktúrákhoz és a szükséges képzéshez kapcsolódnak.

Műveletek folyamatban

A folyamatban lévő műveletek szakasz leírja az ezen a szinten elvégzendő érdemi munkát. Az elvégzett műveletek jellemzően magukban foglalják a tervek elkészítését és konkrét műveletek végrehajtását, a munkák végrehajtását és nyomon követését, valamint szükség szerint a korrekciós intézkedések megtételét.

Mérések és elemzések

A "Mérések és

„A kulcsfolyamatok minden csoportját olyan kulcsgyakorlatok fejezik ki, amelyek megvalósítása hozzájárul a csoport céljainak eléréséhez. A kulcsgyakorlatok azt az infrastruktúrát és műveleteket írják le, amelyek leginkább hozzájárulnak a kulcsfolyamatok egy csoportjának hatékony megvalósításához és kialakításához.

Minden kulcsfontosságú gyakorlat egyetlen mondatból áll, amelyet gyakran egy részletesebb leírás követ, amely példákat és magyarázatokat tartalmazhat. A kulcsgyakorlatok, amelyeket néha legfelső szintű kulcsgyakorlatoknak is neveznek, meghatározzák az alapvető irányelveket, eljárásokat és műveleteket a kulcsfolyamatok egy csoportjához. A részletes leírási összetevőket gyakran algyakorlatoknak nevezik."

A kulcsfontosságú gyakorlatok leírják, MIT kell tenni, de nem szabad dogmának tekinteni a célokat HOGYAN kell elérni. A kulcsfolyamat-csoport céljai alternatív gyakorlatokkal érhetők el. A kulcsgyakorlatok értelmezésének ésszerűnek kell lennie, lehetővé téve a kulcsfolyamatok csoportjának céljainak elérését hatékony mód, bár talán formálisan és eltér az ajánlott CMM-től.

Első ránézésre kissé egzotikusnak tűnik az informatikai menedzsment tevékenységek, amelyekben a folyamatok helyett azok összetevőit veszik figyelembe - kulcsgyakorlatok, a folyamatok pedig csak virtuálisan vannak jelen, mint kulcsgyakorlatokból felépíthető valami. Az informatikai menedzsment fejlesztésének feladatát eddig a referencia folyamatmodellből kész folyamatok bevezetésével oldották meg. Most van egy szintkészlet, amely eltérő (azaz nem a folyamatokba integrált) kulcsfontosságú gyakorlatokat tartalmazza, és egy ajánlott sorrend a szinteken való haladáshoz. Az IT-menedzsment a CMM szerint javul, ahogy az érettség magasabb szintjére lép. Mi történik ezzel a promócióval?

A szintek definícióiban (lásd 7.2. ábra) megjelent egy olyan dolog, mint a "gyártási folyamat". A kulcsfolyamatok egy csoportjának meghatározásában is jelen van, és ez nem véletlen. A gyártási folyamat, vagy ahogy találóan nevezik a CMM-ben, a szabvány Gyártási folyamat A szervezetek (OSS) az egész modell egyik központi fogalma.

1986 novemberében az American Software Engineering Institute (SEI) a Mitre Corporation-nel együttműködve elkezdte kidolgozni a Szoftverfejlesztési folyamatok érettségi felülvizsgálatát, amelynek célja a belső folyamatok javítása volt.

A felülvizsgálat kidolgozását az Egyesült Államok szövetségi kormányának kérése indította el a szoftverfejlesztési alvállalkozók értékelési módszerére vonatkozóan. Az igazi probléma az volt, hogy képtelenség kezelni nagy projektek. Sok vállalatnál a projekteket jelentősen késve és a költségvetésen felül teljesítették. Erre a problémára kellett megoldást találni.

1987 szeptemberében a SEI megjelent rövid áttekintés szoftverfejlesztési folyamatok érettségi szintjének leírásával, valamint egy kérdőív, amely a vállalat azon területeinek azonosítására szolgál, ahol fejlesztésre van szükség. A legtöbb cég azonban kész modellnek tekintette ezt a kérdőívet, melynek eredményeként 4 év elteltével a kérdőívből valós modell lett, a Capability Maturity Model for Software (CMM). A CMM 1991-ben megjelent első verzióját (1.0-s verzió) 1992-ben felülvizsgálták a mintegy 200 szoftverszakértő részvételével zajló munkaértekezlet résztvevői, valamint a fejlesztői közösség tagjai.

1. Alapvető. A szervezet legprimitívebb státusza. A szervezet képes szoftverfejlesztésre. A szervezetnek nincs kifejezetten tudatos folyamata, a termék minőségét teljes mértékben a fejlesztők egyéni képességei határozzák meg. Az egyik kezdeményez, a csapat pedig követi az utasításait. Egy projekt sikere nem garantálja a másik sikerét. A projekt végén a munkaerőköltségre, ütemezésre és minőségre vonatkozó adatokat nem rögzítik.
2. megismételhető. Bizonyos mértékig a folyamatot figyelemmel kísérik. A bérköltségekről és a tervekről nyilvántartás készül. Az egyes projektek funkcionalitását írásban ismertetjük. 1999 közepén a szervezeteknek csak 20%-a volt 2-es vagy magasabb szintű.
3. Telepítve. Legyen meghatározott, dokumentált és kialakult folyamat egyénektől független munkavégzés. Vagyis megegyezett szakmai standardok, és a fejlesztők megvalósítják azokat. Az ilyen szervezetek meglehetősen megbízhatóan megjósolhatják a korábban befejezett projektekhez hasonló projektek költségeit.
4. Kezelve. Pontosan megjósolhatják a munka időzítését és költségét. Van egy adatbázis az összesített mérésekről. Az új technológiák és paradigmák megjelenésével azonban nincs változás.
5. Optimalizált. Folyamatban van egy eljárás az új és továbbfejlesztett módszerek és eszközök felkutatására és elsajátítására.

Fejlődés

A modell gyakorlati alkalmazása feltárta a szoftverfejlesztési folyamatok magasabb szintű szervezettségének elérésére irányuló megközelítések kétértelműségét. Ezért 2002-re ajánlásokat dolgoznak ki a fejlesztési folyamat javítására, amelyeket ún CMMI (Capability Maturity Model Integration). Ebben a pillanatban legújabb verzió CMMi - 1.3 (közzétéve: 2010. november) .

Lásd még

Linkek

MIT Hallgatói Fórum > Fő rész > Tesztek > Vezérlőrendszerek szimulációja

Kilátás teljes verzió: Vezérlőrendszerek szimulációja

Az összes modult megoldottam, mindent 4-el, a végsőt 2-vel teljesítettem, most három nap múlva újra megpróbálom átadni, egyetlen egyforma kérdés sem volt. Megpróbáltam javítani az utolsó teszten, de ellenőrizze, nem tudom garantálni a helyességet, mindent felteszek, amim van, hátha valaki jobban átmegy rajtam. Ha valakinek van második, harmadik próbálkozása, tegye fel, ha nem bánja, fegyelmezz, tényleg nagyon nehéz.:eek:

Utolsó teszt 100 a 100-ból

Minden alkalommal más az eredmény?

További kérdések, amelyek itt nem szerepelnek, és megfogtak. Nem kerestem a válaszokat, mert enélkül átmentem a 4.-ig. Aki össze akar zavarodni, töltse fel ide a válaszokat a többiért 🙂

1. modul:
Mit nem szabad egy üzleti folyamat fémjelének tekinteni?

Értéknövelés

Válassz egy választ:
Egy folyamat terméke, amely megtestesíti a korábban kitűzött célokat

Válassz egy választ:

A döntőben (4-én továbbjutott.

Mi az a képesség-érettségi modell? (CMM)

Ezek a kérdések + azok, amelyek már fent vannak a fórumon):
1. Válassza ki a megfelelő állítást.
Válassz egy választ:
A részlegek üzleti folyamata különböző értékláncokból áll (UNSURE)
A végpontok közötti üzleti folyamatok üzleti folyamatokból állnak különféle szervezetek
A többfunkciós üzleti folyamat általában az osztályok üzleti folyamataiból áll

2. Mi nem az univerzális üzleti folyamat folyamatábra eleme?
Válasszon egy vagy több választ:
Folyamat erőforrások
Kockázatok
Üzleti folyamatmenedzsment tevékenységek
Környezeti tényezők
A bemeneteket kimenetekké alakító tevékenység

3. Anyagi erőforrások a folyamatok alapvető elemei:
Válassz egy választ:
A tevékenység aktív alanyai egymással és más erőforrásokkal kölcsönhatásban álló rendszerekben egyesülnek
A tevékenység alanyai által a tevékenység tárgyaira irányított cselekvések ellenőrzése, amelyek meghatározzák a folyamatok céljait és eredményeit
A folyamatok végrehajtásához használt passzív létesítmények és tevékenységek (NEM BIZTOS)

28.03.2014, 10:07

1. modul:
Mit nem szabad egy üzleti folyamat fémjelének tekinteni? Válasszon egy vagy több választ:
Bemenetek konvertálása kimenetekké
A termék kiszállítása külső fogyasztóhoz
Értéknövelés
Többlet és/vagy használati érték képződése

Az eredmények, mint a folyamatok alapvető elemei:
Válassz egy választ:
A tevékenység aktív alanyai egymással és más erőforrásokkal kölcsönhatásban álló rendszerekben egyesülnek
Egy folyamat terméke, amely megtestesíti a korábban kitűzött célokat A folyamatok végrehajtásához használt passzív létesítmények és tevékenységek
A folyamat befejezéséhez szükséges anyagi, energia- és információs objektumok halmaza

Mi a visszajelzés az üzleti folyamaton belül?
Válassz egy választ:
Céltudatos és tudatos befolyásolás a folyamatban, úgy tervezve, hogy biztosítsa a kívánt eredményt
A folyamat eredményeinek elemzése, összehasonlítása a korábban kitűzött célokkal
A környezet tárgyrendszerére és tényezőire gyakorolt ​​hatás, amelyek a rendszer működésében bekövetkező különféle eltérések forrásai
így válaszoltam! de mégis kijött 4

A döntőben - Ezek a kérdések + a már létezők:
1 Válassza ki a listából a tervezési-célszerkezetek hiányosságait.

2 Válasszon példákat a parancshasználatra a listából.
Minőségi bögrék
bizottságok
Munkacsoportok

3 Válassza ki a listából az organikus szervezeti struktúrák alkalmazásának feltételeit.
A dolgozókat összetett szükségletek motiválják
A célok homályosak és dinamikusan változnak
A hatalmat megkérdőjelezik és tesztelik, megerősítést igényel a beosztottaktól

4 Válassza ki a listából a projektalapú szervezeti struktúrák előnyeit.
az alkalmazottak közvetlen alárendeltsége a projektmenedzsernek, és így megvalósul ezen alkalmazottak erőfeszítéseinek irányának egyértelműsége

5 támogató folyamatok:
Biztosítani hatékony végrehajtása fő folyamatok

Utolsó évfolyam 5
1. kérdés
Válasszon a parancshasználati példák listájából.

Minőségi bögrék
bizottságok
Munkacsoportok

2. kérdés
Mire használják a közvetítőket a funkcionális struktúrán belül?

A különböző szerkezeti részlegek tevékenységének integrálása

3. kérdés
Nevezze meg a kapcsolatok típusait a SADT modellben:
Ellenőrzés
kilépési mechanizmus
Bemeneti visszajelzés

4. kérdés
Az alábbi üzleti folyamatok közül melyik a legrövidebb?
Divíziós üzleti folyamat

5. kérdés
Milyen módszerekkel, módszertanokkal, eszközökkel lehet üzleti folyamat információs modelleket létrehozni?

Gein-Sarson módszertan
Chen és Barker modellezési nyelve

6. kérdés
Melyik üzleti folyamatábrázolás felel meg a legalacsonyabb szintnek (a felsoroltak közül)?

Üzleti folyamatok műveletei

7. kérdés
Üzleti folyamat hossza:

Ez szubjektív

8. kérdés
Az anyagi erőforrások, mint a folyamatok alapvető elemei:

A folyamatok végrehajtásához használt passzív eszközök és tevékenységi tárgyak

9. kérdés
Válassza ki a listából a projektalapú szervezeti struktúrák előnyeit.

Megvalósul az alkalmazottak projektmenedzsernek való közvetlen alárendeltsége, és így érhető el ezen alkalmazottak erőfeszítéseinek irányának egyértelműsége.

10. kérdés
Válassza ki a listából a mátrix szervezeti struktúrák előnyeit.

Rugalmas testreszabási lehetőség szervezeti struktúra széles spektrumon belül: a gyengetől az erős mátrixig

11. kérdés
Mit tartalmaz az üzleti rendszermenedzsment második köre?

Üzemirányítási alrendszer
fejlesztésirányítási alrendszer

12. kérdés
Az üzleti rendszer általános folyamatmodellje a következő elemeket tartalmazza:

Kimenet
folyamat
Bejárat
Zavarás

13. kérdés
Melyik IDEF szabvány teszi lehetővé a tevékenységek, folyamatok és az objektumok állapotának modellezését?

14. kérdés
Milyen jogosítványai vannak a projektmenedzsernek egy erős mátrixstruktúrában?

Közepestől magasig

15. kérdés
Mi tulajdonítható a befektetési és pénzügyi folyamatok fő elemeinek?

Befektetők
Hitelezők

16. kérdés
Válassza ki a listából a tervezési-célszerkezetek hiányosságait.

Csökkentett gyárthatóság a funkcionális területeken

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

Mi a dominancia sorrendje a SADT diagramokban?
Válasz: A legdominánsabb funkciók a bal felső sarokban találhatók.

segítsen 3tréning, akinek van pliz

1 perc után hozzáadva
3 képzést kérek mindenkitől, aki rendelkezik Irányítórendszerek Modellezésével

vBulletin® v3.8.7, Copyright 2000-2018, vBulletin Solutions, Inc.

Fordítás, amit mondhatsz:

Az IS fejlesztésének módszertana. CMM/CMMI érettségi modell.

1991-ben az Egyetem Szoftvermérnöki Intézete

Carnegie Mellon (Szoftvermérnöki Intézet, SEI) létrehozta a CMM érettségi modellt (Capability Maturity Model) szoftvertermékek fejlesztésére. Az idő múlásával modellek egész családja jelent meg:

SW-CMM - szoftvertermékekhez, SE-CMM - rendszertervezéshez, Beszerzési CMM - beszerzéshez, People CMM - humánerőforrás-menedzsmenthez, ICMM - termékintegrációhoz.

A különféle modellek megértése és megvalósítása meglehetősen nehézkesnek bizonyult. Amióta létrejöttek különböző csoportok szakértők, ezeknek a modelleknek a tartalma nem mindig volt összhangban egymással, valamint

nemzetközi szabványok követelményeinek. Ezért 2002-ben a SEI kiadott egy új CMMI modellt (Capability Maturity Model Integration), amely a korábban kiadott modelleket kombinálja és figyelembe veszi a követelményeket.

nemzetközi szabványok. A CMMI modellek (módszerek) halmaza a különböző méretű és tevékenységű szervezetek folyamatainak javítására. A CMMI a fejlesztési területek következő csoportjait különbözteti meg: folyamatmenedzsment, projektmenedzsment, mérnöki területek, szolgáltatás

területeken. Ebben az esetben az összes területet követelmények formájában határozzák meg, amelyek nem a megvalósítás módját, hanem az interfész követelményeket határozzák meg. Ebből két következmény van.

Következmény 1. A CMMI különféle implementációkat tesz lehetővé, és nem olyan szoftverfejlesztési módszertan, mint az MSF, Scrum, RUP stb. Ez utóbbi használható a megvalósításában. Például van egy speciális folyamatsablon a VSTS for CMMI-ben, az úgynevezett MSF for CMMI.

Következmény 2. A CMMI-t a vállalatok folyamataik érettségének tanúsítására használják. Kezdetben, a 80-as évek végén és a 90-es évek elején a CMM (akkor még nem CMMI) éppen a tanúsítás eszközeként jött létre.

szövetségi alvállalkozók. És csak később, miután széles körben elterjedt a világon, kezdték használni, majd a folyamatok javítására összpontosították. Még egyet megjegyezünk fontos jellemzője CMMI. Nem csak szoftverrendszerek fejlesztésére szolgál. Sok nagy cégek nem szoftvereket, hanem céltermékeket gyártanak, ahol a szoftverek szerves részeként szerepelnek.

Például a repülés, az űripar. Vagyis szoftverfejlesztés

más típusú mérnöki munkákkal együtt fordul elő. És gyakran előfordul, hogy egy projektben kettőnél többen vesznek részt. különféle fajták mérnöki. A CMMI feladata, hogy az ilyen projekteknek és cégeknek egységes platformot biztosítson a fejlesztési folyamat szervezéséhez.

A klasszikus CMM-modelltől eltérően, amely szigorúan hierarchikus volt, és csak a folyamatok szintek szerinti szekvenciális javítását tette lehetővé, a CMMI modellnek két dimenziója van - szekvenciális, pl.

ugyanaz, mint a CMM-ben, és folyamatos, lehetővé téve a szervezet folyamatainak tetszőleges mértékű javítását. Itt a szekvenciális modellre fogunk összpontosítani. 5 szintje van

folyamat érettsége (1. ábra).

Első szint(1. lejárati szint) az a szint, amelyen definíció szerint bármely vállalat rendelkezik. Ezen a szinten a szoftverfejlesztés többé-kevésbé kaotikus.

Felügyelt szint(2. érettségi szint) - itt már megjelennek a vállalati szinten jóváhagyott folyamatok szervezésére vonatkozó irányelvek és eljárások. A folyamatok teljes terjedelmében azonban csak az egyes projektek keretében léteznek.

Bizonyos szint(3. érettségi szint) - itt egy standard folyamat jelenik meg a teljes vállalat egészének szintjén.

Mi az a képesség-érettségi modell (CMM)? Mik azok a CMM szintek?

Ez a folyamateszközök nagy és folyamatosan bővülő készlete: dokumentumsablonok,

életciklus-modellek, szoftvereszközök, gyakorlatok stb. Bármilyen konkrét folyamatot ebből a szabványból való kivágással lehet elérni.

Mennyiségi szint(4. érettségi szint) egy olyan mérési rendszer kialakulását jelenti a vállalatban, amely szabványos folyamat alapján történik, és lehetővé teszi a fejlődés mennyiségi irányítását.

Optimalizálási szint(5. érettségi szint) a fejlesztési folyamatok folyamatos javítását jelenti, mind inkrementálisan, mind inkrementálisan, mind forradalmian. Ugyanakkor ezek a változások nem kényszerűek, hanem proaktív problémák és nehézségek. A folyamat önmagában javul, folyamatosan, megfelelő mechanizmusokat vezettek be.

Sokan ismerik a CMMI rövidítést, sokan tudják, hogy ez egy modell, i.e. ajánlások sorozata például a szoftverfejlesztéssel kapcsolatos folyamatok javítására. De kevesen tudják, hogy több CMMI modell létezik. Közülük a leghíresebb a CMMI for Development (CMMI-DEV), amely valóban sok tekintetben kapcsolódik a fejlesztő cégek tevékenységéhez (vagyis azokhoz a cégekhez és szervezetekhez, amelyek egy-egy szoftverterméket vagy egyéb komplex szoftvert és hardvert fejlesztenek és szállítanak). megoldás).

De mi a helyzet azokkal, akik nem terméket, hanem szolgáltatást szállítanak (például terméktámogatást a teljes munkaerőköltségen belül elenyésző fejlesztési részaránnyal, vagy egyáltalán nem bérelnek)? Számukra is van egy sor ajánlás - a CMMI for Services modell (CMMI-SVC). Az informatikai részlegek számára például ez a modell (pontosabban ajánlásai) segíthet megérteni, mit kell tenni ahhoz, hogy például ugyanazok az ITIL-ajánlások normális folyamattá váljanak, ne pedig valamiféle „szent gyakorlattá”.

Képességi érettségi modell (CMM)

Érdekes, hogy ennek a modellnek az ajánlásai meglehetősen univerzálisak, és nem csak „bezáródnak”. Információs technológia. Ennek a modellnek a gyakorlatainak pilot bevezetésére ... az Egyesült Államok egyik kórházában került sor (elvégre az orvosi ellátás is szolgáltatás).

A felsorolt ​​modellek bármelyikét azonban jobb megtanulni. És ha a CMMI-DEV modellben több száz fő van kiképezve a teljes FÁK-ra (kb. 250-300 fő), akkor a CMMI-SVC modellre csak 6 fő van kiképezve a FÁK-ban. A képzettekről beszélünk, nem az oktatókról. Pontosan ez volt a fő probléma 2011 decemberéig: a CMMI-DEV-nél csak egy oroszul beszélő, SEI (CMMI modellfejlesztő) által hitelesített oktató volt az egész világon, a többi modellnél pedig egy sem! Most egy ilyen oktató is megjelent a CMMI-SVC modell szerint (tehát az első 6 képzett). Ez az oktató ennek a kiadványnak a szerzője, aki készséggel válaszol az említett modellekkel és a formális képzéssel kapcsolatos kérdésekre. Kérdez!

Ez az anyag a Club.CNews közösség egy tagjának magánrekordja.
A CNews szerkesztői nem vállalnak felelősséget a tartalmáért.

A minőségbiztosítási modellek fejlődését a „folyamat érettségi modell” vagy „kapacitásfejlesztési modell” alapján fogjuk megvizsgálni. CMM (Capability Maturity Model). Annak ellenére, hogy a modell SMM a szoftver minőségének biztosítására irányul, módszertani vonatkozásai bármely termék (áru, alkotás, szolgáltatás) minőségét biztosító modellekre alkalmazhatók.

Fő a modellben SMM a szervezeti érettség fogalma.

éretlen olyan szervezetnek tekintik, amelyben a szoftverfejlesztési folyamat csak meghatározott előadóktól és menedzserektől függ, és a döntések gyakran „menet közben” születnek. Ebben az esetben nagy a valószínűsége annak, hogy túllépik a költségvetést, vagy nem sikerül a projektet teljesíteni, ezért a vezetők kénytelenek csak az azonnali problémák megoldásával foglalkozni.

Érett Egy szervezet a következő feltételeknek minősül:

• – jól meghatározott eljárások vannak a szoftvertermékek létrehozására és a projektmenedzsmentre, amelyeket finomítanak és továbbfejlesztenek kísérleti projektek a "költség - nyereség" összetevőinek elemzésével;
• – a munka elvégzésének idejére és költségére vonatkozó becslések a felhalmozott tapasztalatokon alapulnak, ezért meglehetősen pontosak;
• – a vállalat rendelkezik szabványokkal a szoftverek fejlesztési, tesztelési és implementációs folyamataira, a végleges programkód, komponensek, interfészek stb. Mindez alkotja az infrastruktúrát és vállalati kultúra amely támogatja a szoftverfejlesztési folyamatot.

Tehát a szabvány SMM egy minőségbiztosítási modell, amely a szervezet érettségének felmérésére szolgáló kritériumokból és a meglévő folyamatok javításának receptjéből áll. A modellben SMM A szervezetek öt érettségi szintjét határozzák meg, amelyek jellemzőit az 1. ábra mutatja be. 5.3.

Rizs. 5.3. A modell érettségének öt szintjeSMM

Első szint (kezdeti szint) ez az alapja a vállalkozás fejlesztésének a következő szinteken. Úgy gondolják, hogy a szervezet belépő szintű vállalkozásában nincsenek stabil feltételek a kiváló minőségű szoftverek létrehozásához. Következésképpen minden projekt eredménye teljes mértékben a menedzser személyes tulajdonságaitól és a programozók tapasztalatától függ. Ez azt jelenti, hogy egy projekt sikere csak akkor ismétlődhet meg, ha ugyanazokat a menedzsereket és programozókat rendelik a következő projekthez. Ha azonban projektekben tapasztalatot szerzett menedzserek vagy programozók kilépnek a vállalkozásból, akkor távozásukkal meredeken csökken az előállított szoftver minősége.

Fel kell ismerni, hogy a kezdeti szinten, stresszes helyzetekben nagy a függőség emberi tényező A fejlesztési folyamat a kód írására és annak minimális tesztelésére redukálódik.

A második elérése ismételhető szint (ismételhető szint) a projektmenedzsment technológia vállalkozásnál történő megvalósítása határozza meg. A vállalatnál a tervezés és a projektmenedzsment a felhalmozott tapasztalatokon alapul, a kifejlesztett szoftverekre vannak és használatosak szabványok, amelyek betartását egy speciális minőségbiztosítási csoport ellenőrzi. Úgy gondolják, hogy a második szint lehetőséget biztosíthat a további fejlesztésre (átmenet a harmadik szintre), és nem zárja ki annak lehetőségét, hogy kritikus körülmények között a szoftverfejlesztési folyamat minősége a kezdeti szintre regresszív módon visszatérjen.

A harmadik, bizonyos szint (definiált bal) jellemzi, hogy a szoftver létrehozásának és karbantartásának szabványos folyamata teljes mértékben dokumentált, a szoftverfejlesztéstől a projektmenedzsmentig. E szint bevezetésének hipotézise az, hogy a szabványosítás során a vállalat a leghatékonyabb gyakorlatok és technológiák felé mozdul el. Egy szervezet szoftverfejlesztési és projektmenedzsment szabványainak létrehozásához és működésének fenntartásához külön csoportot kell létrehozni. A harmadik szint elérésének előfeltétele a folyamatos szakmai továbbképzési program jelenléte a vállalkozásnál. Úgy gondolják, hogy ettől a szinttől kezdve a szervezet megszűnik az adott fejlesztők kvalitásaitól függeni, és nem hajlamos lecsúszni egy alacsonyabb szintre stresszes helyzetekben.

A negyediken, menedzselt szinten (felügyelt szint) a vállalkozás mennyiségi minőségi mutatókat állít fel - mind a szoftvertermékekre, mind általában a létrehozásuk folyamataira vonatkozóan. Így jobb projektmenedzsment érhető el a különböző projektmutatók eltéréseinek csökkentésével. Ugyanakkor elkülönül a megvalósított szoftverfejlesztési folyamatok értelmes (jel)variációi és a folyamat véletlenszerű (zaj) változatai.

Ötödik (legmagasabb), optimalizálási szint (optimalizálási szint) jellemzi, hogy a fejlesztési intézkedéseket nemcsak a meglévő folyamatokra alkalmazzák, hanem az új technológiák bevezetésének hatékonyságát is. A vállalkozás fő feladata ezen a szinten a meglévő folyamatok folyamatos fejlesztése. Ugyanakkor a folyamatfejlesztésnek segítenie kell a megelőzésében lehetséges hibákatés hibák. Ugyanakkor a szoftverfejlesztés költségeinek csökkentésére is törekedni kell.

5 evolúciós szakasz a szervezeti folyamatok menedzselésében. A képesség-érettségi modell magyarázata. CMM

A CM-CEI Capability Maturity Model egy olyan szervezeti modell, amely leírja azt az 5 evolúciós szakaszt (szintet), amelyen a szervezet folyamatait menedzseli.

Eredetileg szoftverfejlesztésre készült, a Capability Maturity Model lényege, hogy egy szervezet képes legyen elfogadni és támogatni szoftveralkalmazásait. A modell konkrét lépéseket és kezdeményezéseket is javasol a szervezet következő szintre való felemelkedéséhez.

A képesség-érettségi modell 5 szakasza

Kezdeti (a folyamatok ad hoc, kaotikus, vagy valójában csak kevés van meghatározva) Megismételhető (az alapfolyamatok létrejöttek, és ezekhez a folyamatokhoz van fegyelem) Meghatározott (minden folyamat definiált, dokumentált), egységes és integrált) Kezelhető ( a folyamatok mérése a folyamatokra és azok minőségére vonatkozó részletes adatok összesítésével történik) Optimalizálás (folyamatos folyamatfejlesztés kvantitatív visszacsatolással és új ötletek és technológiák tesztelésével)

Szoftverfejlesztési modell

A CMM leírja azokat az elveket és gyakorlatokat, amelyek a szoftverfolyamat-érettség koncepcióját támasztják alá. Úgy tervezték, hogy segítsék a szoftverfejlesztő és értékesítő cégeket szoftverfolyamataik kifinomultabbá tételében evolúciós módon. Az ad hoc, kaotikus folyamatoktól kezdve a kiforrott, fegyelmezett szoftverfolyamatok felé haladva. A hangsúly a kulcsfontosságú folyamatterületek és példaértékű gyakorlatok azonosításán van, amelyek fegyelmezett szoftverfolyamatokat alkothatnak. A CMM-érettség fogalma olyan kontextust teremt, amelyben:

A gyakorlatok megismételhetők. Ha nem ismétel meg néhány műveletet, akkor nem szabad javítania. Vannak szabályok, eljárások és gyakorlatok, amelyek a szervezetet a megvalósításra és következetes végrehajtásra kényszerítik. A termelési munka megszervezésének legjobb gyakorlatai gyorsan megoszthatók a csoportok között. A gyakorlatokat úgy határozták meg, hogy lehetővé tegyék a projektek közötti cserét, így biztosítva a szervezet számára némi szabványosítást. Ezen módszerek végrehajtásában az eltérések minimálisak. A feladatokhoz mennyiségi célokat tűznek ki; és méréseket hoznak létre, készítenek és tartanak fenn, hogy az értékelés alapját képezzék. A gyakorlatok folyamatos fejlesztése a képesség javítása érdekében (optimalizálás).

A képesség-érettségi modell nemcsak a szoftverfejlesztéshez hasznos, hanem általában a szervezetek evolúciós szintjének leírására is, valamint a szervezet által megvalósított vagy elérni kívánt menedzsment szintjének leírására is.

A szolgáltatásfejlesztési modell felépítése

Az érettségi szintek egy többrétegű koncepció, amely biztosítja a fegyelem következetességét, amely a folyamatos fejlődés eléréséhez szükséges. Itt fontos megjegyezni, hogy a szervezetben kialakul az a képesség, hogy értékelje egy új gyakorlat, technológia vagy eszköz következményeit. Ezért nem ezeknek az újításoknak az elfogadásáról van szó, hanem arról, hogy ezek az innovációs törekvések hogyan hatnak a meglévő gyakorlatokra. Támogatja a projekteket, csoportokat és szervezeteket azáltal, hogy alapot ad a megalapozott döntésekhez. Kulcsfontosságú folyamatterületek – A kulcsfontosságú folyamatterület (KPA) olyan kapcsolódó tevékenységek csoportját határozza meg, amelyek együttes végrehajtása során számos fontos célt érnek el. Célok – Egy kulcsfontosságú folyamatterület céljai leírják azokat a rendelkezéseket, amelyeknek létezniük kell az adott kulcsfontosságú folyamatterülethez. A rendeleteket hatékonyan és biztonságosan kell végrehajtani. A célok teljesülésének mértéke jelzi, hogy a szervezet milyen képességekkel rendelkezik ezen a kiválósági szinten. A célok körülhatárolják az egyes kulcsfontosságú folyamatterületek hatókörét, határait és célját. Általános jellemzők – Az általános jellemzők közé tartoznak a kulcsfontosságú folyamatterületeket megvalósító és intézményesítő gyakorlatok. Ez az 5 típus Általános tulajdonságok a következőket tartalmazza: Teljesítés iránti elkötelezettség, Teljesítési képesség, Végrehajtandó kezdeményezések, Mérés és elemzés, valamint a végrehajtás ellenőrzése. Kulcsgyakorlatok – A Kulcsgyakorlatok azokat az infrastrukturális elemeket és gyakorlatokat írják le, amelyek a leghatékonyabban járulnak hozzá a kulcsfontosságú folyamatterületek megvalósításához és intézményesítéséhez.

A folyamat meghatározásának kritériumai

A folyamat meghatározásának kritériumai olyan folyamatelemek összessége, amelyeket egy szoftveres folyamatleírásban kell szerepeltetni ahhoz, hogy az emberek a gyakorlatban is használhassák azokat. A kritériumok beállításához fel kell tennie a kérdést: „Milyen információ szoftveres folyamat szükséges a dokumentációhoz?