A szoftver életciklusa: koncepció, szabványok, folyamatok. A szoftver életciklusa. Egy szoftverfejlesztési projekt életciklusának szakaszai és szakaszai

Életciklus szoftver(Szoftver) - az az időszak, amely attól a pillanattól kezdődik, hogy a szoftvertermék létrehozásának szükségességéről döntés születik, és a szolgáltatásból való teljes kilépéskor ér véget. Ez a ciklus a szoftverek készítésének és fejlesztésének folyamata.

Az életciklus szakaszai:

2. Tervezés

3. Végrehajtás

4. Összeszerelés, tesztelés, tesztelés

5. Végrehajtás (kiadás)

6. Kísérő

A szoftvergyártásnak két esete van: 1) A szoftvert egy adott ügyfél számára készítik. Ebben az esetben az alkalmazott feladatot programozóvá kell alakítania. Meg kell érteni, hogyan működik az automatizálandó környezet (üzleti folyamatok elemzése). Ennek eredményeként megjelenik a követelmény dokumentációs specifikációja, ahol pontosan meg kell jelölni a feladatokat. megoldódott és milyen feltételek mellett. Ezt a munkát rendszerelemző (üzleti folyamat elemző) végzi.

2) A szoftvert a piacra fejlesztették. Szükséges végrehajtani marketing kutatásés megtudja, milyen termék nincs a piacon. Ez nagy kockázattal jár. A cél egy követelményspecifikáció kidolgozása.

Tervezés

Cél - Meghatározás általános szerkezet(építészeti) szoftver. Az eredmény egy szoftver specifikáció. Ezt a feladatot a rendszerprogramozó végzi.

Végrehajtás

Programkód írása. A megvalósítás magában foglalja a fejlesztést, tesztelést és dokumentációt.

Összeszerelés, tesztelés, tesztelés

Összeszerelni mindent, amit különböző programozók végeztek. A teljes szoftvercsomag tesztelése. Hibakeresés - a hibák okainak megtalálása és kiküszöbölése. Teszt - finomítás technikai sajátosságok... Ennek eredményeként a program garantáltan működik.

Végrehajtás (kiadás)

Megvalósítás - amikor egy ügyfélnél dolgoznak. Ez magában foglalja a program beállítását az ügyfélnél, az ügyfél képzését, tanácsadást, a hibák és nyilvánvaló hiányosságok kiküszöbölését. A szoftvert el kell idegeníteni - a felhasználó dolgozhat a szoftverrel a szerző részvétele nélkül.

Kiadás - amikor a szoftvert piacra fejlesztették. A béta tesztelési fázissal kezdődik. Megfelelő verzió - béta verzió. Az alfa tesztelés ugyanazon szervezet embereinek tesztelése, akik nem vettek részt szoftverfejlesztésben. Béta tesztelés - a szoftver több másolatának elkészítése és elküldése a potenciális ügyfeleknek. A cél a szoftverfejlesztés kétszeri ellenőrzése.

Ha egy alapvetően új szoftvert bocsátanak a piacra, akkor több béta teszt is lehetséges. Béta tesztelés után - a kereskedelmi verzió megjelenése.

Kíséret

A működés során észlelt hibák kiküszöbölése. Kisebb javítások elvégzése. Javaslatok összegyűjtése a következő verzió kifejlesztésére.

Életciklus modellek

1. Vízesés ("vízesés", kaszkád modell)

2. Prototípuskészítés

Először is nem magát a szoftverterméket fejlesztik ki, hanem annak prototípusát, amely tartalmazza a megoldást a fejlesztők előtt álló fő problémákra. A prototípus -fejlesztés sikeres befejezése után a valódi szoftverterméket ugyanazon elvek szerint fejlesztik. A prototípus lehetővé teszi, hogy jobban megértse a kidolgozott program követelményeit. A prototípus használatával az ügyfél pontosabban is megfogalmazhatja igényeit. A fejlesztőnek lehetősége van prototípus segítségével bemutatni munkája előzetes eredményeit a megrendelőnek.

3. Iteratív modell

A feladatot részfeladatokra osztják, és meghatározzák azok végrehajtásának sorrendjét, így minden további részfeladat kibővíti a szoftver képességeit. A siker lényegében attól függ, hogy a feladatokat mennyire osztják fel részfeladatokra, és hogyan választják ki a sorrendet. Előnyök: 1) az ügyfél aktív részvételének lehetősége a fejlesztésben, lehetősége van a fejlesztés során tisztázni igényeit; 2) az újonnan kifejlesztett és a korábban kifejlesztett alkatrészek együttes tesztelésének képessége, ez csökkenti a komplex hibakeresés költségeit; 3) a fejlesztés során elkezdheti a megvalósítást részenként.

Megjegyzés.

Bevezetés.

1. A szoftver életciklusa

Bevezetés.

Riley programozási folyamat lépései

Bevezetés.

1.1.1. A probléma megfogalmazása.

1.1.2. A megoldás tervezése.

1.1.3. Algoritmus kódolás.

1.1.4. A program karbantartása.

1.1.5. Szoftver dokumentáció.

Következtetés az 1.1

1.2. Az életciklus-termelés meghatározása Lehman szerint.

Bevezetés.

1.2.1 A rendszer meghatározása.

1.2.2. Végrehajtás.

1.2.3. Szolgáltatás.

Következtetés az 1.2.

1.3. A ZHCPO fázisai és munkája Boehm szerint

1.3.1. Vízesés modell.

1.3.2. Gazdasági indoklás kaszkád modell.

1.3.3. A vízesés modell javítása.

1.3.4. Az életciklus fázisainak meghatározása.

1.3.5. Alapvető munka a projekten.

Irodalom.

Bevezetés

A számítógépek ipari használata és a szoftverek iránti növekvő kereslet sürgős feladatokat jelentett a számuk jelentős növekedéséhez szoftverfejlesztési termelékenység, a programok tervezéséhez és tervezéséhez szükséges ipari módszerek fejlesztése, a szervezeti és műszaki, műszaki, gazdasági és szociálpszichológiai technikák, minták és módszerek átvitele az anyaggyártás területéről a számítógépek használatának területére. Összetett megközelítés a szoftverfejlesztési, üzemeltetési és karbantartási folyamatokhoz számos sürgető problémát vetett fel, amelyek megoldása megszünteti a szűk keresztmetszeteket a programok tervezésében, csökkenti a munka befejezési idejét, javítja a meglévők kiválasztását és adaptálását programokat, és talán meghatározza a beágyazott számítógépekkel rendelkező rendszerek sorsát.

A nagy szoftverprojektek fejlesztésének gyakorlatában gyakran nincs egységes megközelítés a munkaerőköltségek, a munka időzítése és anyagköltségek, ami hátráltatja a szoftverfejlesztési termelékenység növekedését, és végül - hatékony menedzsment szoftver életciklusa. Mivel bármilyen programból termék lesz (kivéve talán oktatási, mintaprogramokat), előállításának megközelítésének sok tekintetben hasonlónak kell lennie az ipari termékek előállításához, és a programok tervezésének kérdései rendkívül fontossá válnak. . Ez az ötlet áll B.W. Boehm "Szoftverfejlesztés", amelyet ennek írásában használtunk lejáratú papírok... Ebben a könyvben a szoftvertervezés a szoftvertervezés létrehozásának folyamatára utal.

1 A szoftver életciklusa

BEVEZETÉS

Az életciklus -program egy folyamatos folyamat, amely attól a pillanattól kezdődik, hogy a szoftver létrehozásának szükségességéről döntés születik, és a szolgáltatásból való teljes kilépéskor fejeződik be.

A szoftver életciklusának (LCP) fázisainak és tevékenységeinek, a programozási folyamat lépéseinek, a vízesésnek és a spirálmodelleknek a meghatározására számos megközelítés létezik. De mindegyik közös alapvető összetevőket tartalmaz: problémamegoldás, megoldástervezés, megvalósítás, karbantartás.

A legismertebb és legteljesebb talán az életciklus-központ Boehm szerinti felépítése, amely nyolc fázist tartalmaz. A jövőben részletesebben bemutatják.

Az egyik lehetséges lehetőség a felső szint leírása Lehmann szerint, amely három fő fázist tartalmaz, és az élet életciklusának leírását mutatja be a legáltalánosabb esetben.

És változtatásképpen - bemutatjuk a programozási folyamat lépéseit, amelyeket D. Riley mutatott be a "A 2. modul nyelvének használata" című könyvben. Ez az ötlet véleményem szerint nagyon egyszerű és ismerős, és ezzel kezdjük.

1.1 A Riley programozási folyamat lépései

Bevezetés

A programozási folyamat négy lépést tartalmaz (1. ábra):

problémajelentés, azaz megfelelő elképzelés megszerzése arról, hogy a programnak milyen feladatot kell végrehajtania;

megoldást tervezni egy már felvetett problémára (általában egy ilyen megoldás kevésbé formális, mint a végleges program);

a program kódolása, azaz a tervezett megoldás lefordítása a gépen végrehajtható programmá;

a program karbantartása, azaz folyamatos hibaelhárítási folyamat a programban és új funkciók hozzáadása.

Rizs. 1. A programozás négy lépése.

A programozás attól a pillanattól kezdődik, amikor felhasználó, azaz valaki, akinek programra van szüksége a probléma megoldásához, bemutatja a problémát rendszerelemző. A felhasználó és a rendszerelemző közösen határozza meg a problémajelentést. Ez utóbbit továbbítják algoritmus aki felelős a megoldás megtervezéséért. A megoldás (vagy algoritmus) egy műveletsort jelent, amelynek végrehajtása egy probléma megoldásához vezet. Mivel az algoritmus gyakran nem olvasható géppel, le kell fordítani egy gépi programra. Ezt a műveletet a kódoló hajtja végre. A karbantartó felelős a program későbbi változtatásaiért. programozó. A rendszer -elemző, az algoritmus, a kódoló és a kísérő programozó mind programozók.

Nagy szoftverprojekt esetén jelentős lehet a felhasználók, a rendszerelemzők és az algoritmusok száma. Ezenkívül előre nem látható körülmények miatt szükséges lehet visszatérni az előző lépésekhez. Mindez kiegészíti a gondos szoftvertervezés érvelését: minden lépés eredményének teljesnek, pontosnak és érthetőnek kell lennie.

1.1.1 Problémajelentés

A programozás egyik legfontosabb lépése a problémamegoldás. Szerződésként szolgál a felhasználó és a programozó (k) között. A jogilag rosszul írt szerződéshez hasonlóan a rossz célzás haszontalan. A feladat jó megfogalmazásával mind a felhasználó, mind a programozó egyértelműen és egyértelműen ábrázolja az elvégzendő feladatot, azaz ebben az esetben mind a felhasználó, mind a programozó érdekeit figyelembe veszik. A felhasználó tervezheti a még nem létrehozott szoftver használatát, a tudása alapján. A probléma jó megfogalmazása alapul szolgál a megoldás kialakításához.

A probléma megfogalmazása (program specifikáció); lényegében pontos, teljes és érthető leírást jelent arról, hogy mi történik egy adott program végrehajtásakor. A felhasználó általában úgy néz a számítógépre, mintha egy fekete doboz lenne: számára nem mindegy, hogyan működik a számítógép, hanem az számít, hogy a számítógép mit tehet, ami érdekli a felhasználót. Ebben az esetben a fő hangsúly egy személy és egy gép közötti interakción van.

A jó feladatmegállapítás jellemzői:

Pontosság, azaz minden kétértelműség kiküszöbölése. Nem lehet kérdés, hogy az adott bemenethez milyen program kimenete lesz.

Teljesség, azaz az adott bemenetre vonatkozó összes lehetőség mérlegelése, beleértve a hibás vagy nem szándékolt bemenetet, és a megfelelő kimenet meghatározása.

Világosság, azaz egyértelműnek kell lennie mind a felhasználó, mind a rendszerelemző számára, mivel a probléma megállapítása az egyetlen szerződés közöttük.

A pontosság, a teljesség és az egyértelműség iránti követelmények gyakran ütköznek. Például sok jogi dokumentumot nehéz megérteni, mert olyan hivatalos nyelven íródtak, amely lehetővé teszi bizonyos rendelkezések legpontosabb megfogalmazását, kizárva az esetleges kisebb eltéréseket. Például a vizsgajegyek néhány kérdése olykor annyira pontos, hogy a hallgató több időt tölt a kérdés megértésével, mint a megválaszolásával. Sőt, a hallgató a részletek nagy száma miatt egyáltalán nem fogja fel a kérdés fő jelentését. A probléma legjobb megfogalmazása az, amely mindhárom követelmény egyensúlyát eléri.

A problémajelentés szabványos formája.

Tekintsük a következő problémajelentést: "Írjon be három számot, és adja ki sorrendben a számokat."

Ez a megfogalmazás nem felel meg a fenti követelményeknek: nem pontos, nem teljes és nem érthető. Valóban, a számokat soronként egyet kell beírni, vagy az összes számot egy sorba? A "sorrendben" kifejezés a legmagasabbtól a legalacsonyabbig, a legalacsonyabbtól a legmagasabbig terjedő sorrendet jelenti, vagy ugyanazt a sorrendet, amelyben bevezették.

Nyilvánvaló, hogy egy ilyen megfogalmazás nem sok kérdésre ad választ. Ha figyelembe vesszük az összes kérdésre adott választ, akkor a probléma megfogalmazása szöveges és nehezen érthető lesz. Ezért D. Riley javasolja egy szabványos űrlap használatát a probléma beállításához, amely maximális pontosságot, teljességet és egyértelműséget biztosít, és a következőket tartalmazza:

feladat neve (sematikus meghatározás);

Általános leírása(a probléma összefoglalása);

hibák (a szokatlan beviteli lehetőségek kifejezetten fel vannak sorolva, hogy megmutassák a felhasználóknak és a programozóknak, hogy a gép mit fog tenni ilyen helyzetekben);

példa ( jó példaát tudja adni a probléma lényegét, és szemlélteti a különböző eseteket is).

Példa. Nyilatkozat a problémáról szabványos formában.

CÍM

Három egész szám rendezése.

LEÍRÁS

Három egész szám be- és kimenete, a legalacsonyabbtól a legnagyobbig rendezve.

Három egész szám van megadva, soronként egy szám. Ebben az esetben egy egész szám egy vagy több egymást követő tizedes számjegy, amelyet egy "+" vagy egy "-" pluszjel előzhet meg.

A három beírt egész szám megjelenik, mindhárom ugyanazon a soron. A szomszédos számokat szóközzel válassza el. A számok a legalacsonyabbtól a legnagyobbig, balról jobbra jelennek meg.

1) Ha háromnál kevesebb számot ad meg, a program további bevitelre vár.

2) Az első három kivételével más beviteli sorokat figyelmen kívül hagynak.

3) Ha az első három sor bármelyike egynél több egész számot tartalmaz, akkor a program kilép és üzenetet jelenít meg.

Megjegyzés.

Bevezetés.

1. A szoftver életciklusa

Bevezetés.

Riley programozási folyamat lépései

Bevezetés.

1.1.1. A probléma megfogalmazása.

1.1.2. A megoldás tervezése.

1.1.3. Algoritmus kódolás.

1.1.4. A program karbantartása.

1.1.5. Szoftver dokumentáció.

Következtetés az 1.1

1.2. Az életciklus-termelés meghatározása Lehman szerint.

Bevezetés.

1.2.1 A rendszer meghatározása.

1.2.2. Végrehajtás.

1.2.3. Szolgáltatás.

Következtetés az 1.2.

1.3. A ZHCPO fázisai és munkája Boehm szerint

1.3.1. Vízesés modell.

1.3.2. A vízesés modell gazdasági indoklása.

1.3.3. A vízesés modell javítása.

1.3.4. Az életciklus fázisainak meghatározása.

1.3.5. Alapvető munka a projekten.

Irodalom.

Bevezetés

A számítógépek ipari használata és a szoftverek iránti növekvő kereslet sürgős feladatokat jelentett a számuk jelentős növekedéséhez szoftverfejlesztési termelékenység, a programok tervezéséhez és tervezéséhez szükséges ipari módszerek fejlesztése, a szervezeti-technikai, műszaki-gazdasági és szociálpszichológiai technikák, minták és módszerek átvitele az anyaggyártás területéről a számítógépek használatának területére. Összetett megközelítés a szoftverfejlesztési, üzemeltetési és karbantartási folyamatokhoz számos sürgető problémát vetett fel, amelyek megoldása megszünteti a szűk keresztmetszeteket a programok tervezésében, csökkenti a munka befejezési idejét, javítja a meglévők kiválasztását és adaptálását programokat, és talán meghatározza a beágyazott számítógépekkel rendelkező rendszerek sorsát.

A nagy szoftverprojektek fejlesztésének gyakorlatában gyakran nincs egységes megközelítés a munkaerőköltségek, a munkaidő és az anyagköltségek becsléséhez, ami akadályozza a szoftverfejlesztés termelékenységének növekedését, és végső soron - a szoftver életciklusának hatékony kezelését. Mivel egy bármilyen programból termék lesz (kivéve talán az oktatási, mintaprogramokat), előállításának megközelítésének sok tekintetben hasonlónak kell lennie az ipari termékek előállításához, és a programok tervezésének kérdései rendkívül fontossá válnak. . Ez az ötlet áll B.W. Boehm "Szoftverfejlesztés" című könyvét, amelyet ennek a szakdolgozatnak az írásakor használtunk. Ebben a könyvben a szoftvertervezés a szoftvertervezés létrehozásának folyamatára utal.

1 A szoftver életciklusa

BEVEZETÉS

A szoftver életciklusának (LCP) fázisainak és tevékenységeinek, a programozási folyamat lépéseinek, a vízesésnek és a spirálmodelleknek a meghatározásához többféle megközelítés létezik. De mindegyik közös alapvető összetevőket tartalmaz: problémamegoldás, megoldástervezés, megvalósítás, karbantartás.

A legismertebb és legteljesebb talán az életciklus-központ Boehm szerinti felépítése, amely nyolc fázist tartalmaz. A jövőben részletesebben bemutatják.

Az egyik lehetséges lehetőség a felső szint leírása Lehmann szerint, amely három fő fázist tartalmaz, és az élet életciklusának leírását mutatja be a legáltalánosabb esetben.

És változtatásképpen - bemutatjuk a programozási folyamat lépéseit, amelyeket D. Riley mutatott be a "Module -2 nyelv használata" című könyvben. Ez az ötlet véleményem szerint nagyon egyszerű és ismerős, és ezzel kezdjük.

1.1 A Riley programozási folyamat lépései

A programozási folyamat négy lépést tartalmaz (1. ábra):

problémajelentés, azaz megfelelő elképzelés megszerzése arról, hogy a programnak milyen feladatot kell végrehajtania;

megoldást tervezni egy már felvetett problémára (általában ez a megoldás kevésbé formális, mint a végső program);

a program kódolása, azaz a tervezett megoldás lefordítása a gépen végrehajtható programmá;

a program karbantartása, azaz folyamatos hibaelhárítási folyamat a programban és új funkciók hozzáadása.

Rizs. 1. A programozás négy lépése.

A programozás attól a pillanattól kezdődik, amikor felhasználó, azaz valaki, akinek programra van szüksége a probléma megoldásához, bemutatja a problémát rendszerelemző. A felhasználó és a rendszerelemző közösen határozza meg a problémajelentést. Ez utóbbit továbbítják algoritmus aki felelős a megoldás megtervezéséért. A megoldás (vagy algoritmus) egy műveletsort jelent, amelynek végrehajtása egy probléma megoldásához vezet. Mivel az algoritmus gyakran nem gépen való futtatásra van adaptálva, le kell fordítani egy gépprogramba. Ezt a műveletet a kódoló hajtja végre. A karbantartó felelős a program későbbi módosításaiért. A rendszer -elemző, az algoritmus, a kódoló és a kísérő programozó mind programozók.

Nagy szoftverprojekt esetén jelentős lehet a felhasználók, a rendszerelemzők és az algoritmusok száma. Ezenkívül előre nem látható körülmények miatt szükség lehet az előző lépésekhez való visszatérésre. Mindez kiegészíti a gondos szoftvertervezés érvelését: minden lépés eredményének teljesnek, pontosnak és érthetőnek kell lennie.

1.1.1 Problémajelentés

A programozás egyik legfontosabb lépése a problémamegoldás. Szerződésként szolgál a felhasználó és a programozó (k) között. A jogilag rosszul írt szerződéshez hasonlóan a rossz problémamegállapítás haszontalan. A probléma jó megfogalmazásával mind a felhasználó, mind a programozó egyértelműen és egyértelműen képviseli az elvégzendő feladatot, azaz ebben az esetben mind a felhasználó, mind a programozó érdekeit figyelembe veszik. A felhasználó tervezheti a még nem létrehozott szoftver használatát, a tudása alapján. A probléma jó megfogalmazása alapul szolgál a megoldás kialakításához.

A jó feladatmegállapítás jellemzői:

Pontosság, azaz minden kétértelműség kiküszöbölése. Nem lehet kérdés, hogy az adott bemenethez milyen program kimenete lesz.

Teljesség, azaz az adott bemenetre vonatkozó összes lehetőség mérlegelése, beleértve a hibás vagy nem szándékolt bemenetet, és a megfelelő kimenet meghatározása.

Világosság, azaz egyértelműnek kell lennie mind a felhasználó, mind a rendszerelemző számára, mivel a probléma megállapítása az egyetlen szerződés közöttük.

Gyakran a pontosság, a teljesség és az egyértelműség követelménye ellentétes. Például sok jogi dokumentumot nehéz megérteni, mert olyan hivatalos nyelven íródtak, amely lehetővé teszi bizonyos rendelkezések legpontosabb megfogalmazását, kizárva az esetleges kisebb eltéréseket. Például a vizsgajegyek néhány kérdése olykor annyira pontos, hogy a hallgató több időt tölt a kérdés megértésével, mint a megválaszolásával. Sőt, a hallgató a részletek nagy száma miatt egyáltalán nem fogja fel a kérdés fő jelentését. A probléma legjobb megfogalmazása az, amely mindhárom követelmény egyensúlyát eléri.

A problémajelentés szabványos formája.

Tekintsük a következő problémajelentést: "Írjon be három számot, és adja ki sorrendben a számokat."

feladat neve (sematikus meghatározás);

általános leírás (a probléma rövid leírása);

hibák (a szokatlan beviteli lehetőségek kifejezetten fel vannak sorolva, hogy megmutassák a felhasználóknak és a programozóknak, hogy a gép mit fog tenni ilyen helyzetekben);

példa (egy jó példa közvetíti a probléma lényegét, és szemlélteti a különböző eseteket is).

Példa. Nyilatkozat a problémáról szabványos formában.

CÍM

Három egész szám rendezése.

LEÍRÁS

Három egész szám be- és kimenete, a legalacsonyabbtól a legnagyobbig rendezve.

Három egész szám kerül megadásra, soronként egy szám. Ebben az esetben egy egész szám egy vagy több egymást követő tizedes számjegy, amelyet egy "+" vagy egy "-" pluszjel előzhet meg.

A három beírt egész szám megjelenik, mindhárom ugyanazon a soron. A szomszédos számokat szóközzel válassza el. A számok a legalacsonyabbtól a legnagyobbig, balról jobbra jelennek meg.

1) Ha háromnál kevesebb számot ad meg, a program további bevitelre vár.

Téma: Klasszikus és rugalmas életciklus -modellek: meghatározás, leírás, megkülönböztető tulajdonságok, szakaszok sorrendje. Az életciklus -modell kiválasztásának módszerei a szoftverfejlesztésben különböző témákban.

Információforrás: https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

A szoftver életciklusának modelljei és szakaszai

Az életciklus -modell olyan szerkezet, amely meghatározza a folyamatok, műveletek és feladatok végrehajtásának sorrendjét és összefüggését a szoftver életciklusa során. Az életciklus -modell a projekt sajátosságaitól, méretétől és összetettségétől, valamint a rendszer létrehozásának és működésének feltételeitől függ.

Az ISO / IEC 12207 nem nyújt konkrét életciklus -modellt és szoftverfejlesztési módszereket. Ennek rendelkezései közösek a szoftverfejlesztés bármely életciklus -modelljéhez, módszeréhez és technológiájához. A szabvány leírja a szoftver életciklus -folyamatainak felépítését, de nem határozza meg, hogyan kell végrehajtani vagy végrehajtani az ezekben a folyamatokban szereplő műveleteket és feladatokat.

Bármely konkrét szoftver életciklus -modellje határozza meg létrehozásának folyamatának jellegét, amely időben megrendelt, a munka szakaszaiban (fázisaiban) összekapcsolt és egyesített munkahalmaz, amelynek végrehajtása szükséges és elegendő a szoftver létrehozásához amely megfelel a meghatározott követelményeknek.

A szoftver létrehozásának szakaszát (fázisát) a szoftver létrehozásának folyamatának részeként kell érteni, amelyet bizonyos időkeretek korlátoznak, és egy adott termék (szoftvermodellek, szoftverkomponensek, dokumentáció stb.) Megjelenésével végződnek, amelyet a követelmények határoznak meg állítva erre a szakaszra. A szoftverfejlesztés szakaszait a racionális tervezés és a munkaszervezés okán különböztetjük meg, a megadott eredményekkel zárva. A szoftver életciklusa általában a következő szakaszokat foglalja magában:

szoftverkövetelmények kialakítása;
tervezés (rendszerprojekt kidolgozása);
megvalósítás (alszakaszokra bontható: részletes tervezés, kódolás);
tesztelés (felosztható önálló és komplex tesztelésés integráció);
üzembe helyezés (megvalósítás);
üzemeltetés és karbantartás;
leszerelés.

Egyes szakértők bevezetnek egy további kezdeti szakaszt - megvalósíthatósági tanulmány rendszereket. Ez arra a szoftver- és hardverrendszerre vonatkozik, amelyhez szoftvert készítenek, vásárolnak vagy módosítanak.

A szoftverkövetelmények kialakításának szakasza az egyik legfontosabb, és nagy (akár döntő!) Fokú is meghatározza az egész projekt sikerét. Ennek a szakasznak a kezdete egy jóváhagyott és validált rendszer architektúra beszerzése, amely tartalmazza a hardver és a szoftver közötti funkciómegosztásra vonatkozó alapvető megállapodásokat. Ennek a dokumentumnak tartalmaznia kell a szoftver működésének általános megértésének megerősítését is, beleértve a funkciók személy és a rendszer közötti elosztásáról szóló alapvető megállapodásokat.

A szoftverkövetelmények kialakításának szakasza a következő szakaszokat foglalja magában.

A munka megtervezése a projekt megkezdése előtt. A szakasz fő feladatai a fejlesztési célok meghatározása, előzetes gazdasági értékelés projekt, munkarend összeállítása, közös munkacsoport létrehozása és képzése.
Az automatizált szervezet (objektum) tevékenységeinek felmérése, amelynek keretében a jövő rendszerére vonatkozó követelmények előzetes azonosítása történik, a szervezet szerkezetének meghatározása, a célfunkciók listájának meghatározása a szervezet részlegei, a funkciók osztályok és alkalmazottak szerinti megoszlásának elemzése, a részlegek közötti funkcionális kölcsönhatások azonosítása, az információáramlások az osztályokon belül és között, külső az objektumok szervezésével és a külső információs befolyásokkal kapcsolatban, elemzés meglévő alapok a szervezet tevékenységének automatizálása.

A szervezet (objektum) tevékenységének modelljének felépítése, a felmérési anyagok feldolgozásának biztosítása és kétféle modell felépítése:

egy "AS-IS" ("ahogy van") modell, amely tükrözi a szervezet jelenlegi állapotát a felmérés idején, és lehetővé teszi a szervezet működésének megértését, valamint a szűk keresztmetszetek azonosítását és javaslatok megfogalmazását a helyzet;
modell "TO-BE" ("hogyan kell"), amely tükrözi a szervezet új technológiáinak elképzelését.

Mindegyik modellnek tartalmaznia kell a szervezet tevékenységeinek teljes funkcionális és információs modelljét, valamint (ha szükséges) egy olyan modellt, amely leírja a szervezet viselkedésének dinamikáját. Vegye figyelembe, hogy a felépített modellek függetlenek gyakorlati jelentősége függetlenül attól, hogy a vállalkozás kifejleszt és bevezet egy információs rendszert, mivel ezek felhasználhatók az alkalmazottak képzésére és a vállalkozás üzleti folyamatainak javítására.

A szoftverkövetelmények kialakításának szakaszának befejezése eredményeként a szoftver specifikációi, a funkcionális, a műszaki és az interfész specifikációk, amelyek teljességét, tesztelhetőségét és megvalósíthatóságát megerősítették.

A tervezési szakasz a következő szakaszokat tartalmazza.

Szoftverrendszer projekt kidolgozása. Ebben a szakaszban a válasz a "Mit kell tennie a jövőbeli rendszernek?" Fejlesztésre, szoftver hibakeresési tervre és minőség -ellenőrzésre.

A rendszer tervezése a rendszertervezési modelleken alapul, amelyek a "TO-BE" modellre épülnek. A rendszerprojekt fejlesztésének eredménye a szoftverkövetelmények jóváhagyott és megerősített specifikációja: funkcionális, műszaki és interfész specifikációk, amelyek teljességét, tesztelhetőségét és megvalósíthatóságát megerősítették.
Részletes (műszaki) projekt kidolgozása. Ebben a szakaszban a szoftver tényleges tervezése történik, beleértve a rendszer architektúrájának és a részletes tervezésnek a tervezését. Így a válasz a következő kérdésre adható: "Hogyan lehet felépíteni egy rendszert úgy, hogy megfeleljen a követelményeknek?"

A részletes tervezés eredménye egy ellenőrzött szoftver specifikáció kifejlesztése, beleértve:

a szoftverkomponensek, az adatok és vezérlés intermoduláris interfészei hierarchiájának kialakítása;
az egyes szoftverösszetevők specifikációja, név, cél, feltételezések, méretek, hívások sorrendje, bemeneti és kimeneti adatok, téves kimenetek, algoritmusokés logikai áramkörök;
kialakulása fizikai és logikai struktúrák adatok az egyes mezők szintjéig;
a számítási erőforrások (központi processzorok ideje, memória stb.) elosztására vonatkozó terv kidolgozása;
a követelmények teljességének, következetességének, megvalósíthatóságának és érvényességének ellenőrzése;
előzetes integrációs és hibakeresési terv, felhasználói kézikönyv és elfogadási tesztterv.

A részletes tervezési szakasz befejezése a teljes körű projektirányítás vagy a projekt kritikus blokkelemzése.

A megvalósítás szakasza az alábbi munkák megvalósítása.

Minden egyes alprogram ellenőrzött részletes specifikációjának kidolgozása (a magas szintű nyelv legfeljebb 100 forrásparancsból álló blokkja).

A külső előírásoknak a következő információkat kell tartalmazniuk:
- modul neve - jelzi a modul hívásához használt nevet (több bemenettel rendelkező modul esetén minden bemenethez külön előírásokat kell megadni);
- funkció - meghatározza a modul által végrehajtott funkciót;
- a modulnak átadott paraméterek listája (szám és sorrend);
- bemeneti paraméterek - a modul által visszaadott összes adat pontos leírása (a modul viselkedését minden beviteli feltétel esetén meg kell határozni);
- külső hatások (üzenet nyomtatása, kérés olvasása a terminálról stb.).
A modulok logikájának és a programozó (kódoló) modulok tervezése.
A modulok helyességének ellenőrzése.
Modulok tesztelése.
Az adatbázis leírása az egyes paraméterek, szimbólumok és bitek szintjéig.
Elfogadási vizsgálati terv.
Használati utasítás.
Az integráció és a hibakeresés előzetes terve. A későbbi szakaszok tartalma alapvetően egybeesik a szoftver életciklusának megfelelő folyamataival. Általában véve a technológiai szakaszokat megkülönböztetik az ésszerű és racionális tervezés és munkaszervezés megfontolásai alapján. A szoftver életciklusával való kapcsolat és szakaszok lehetséges változata az ábrán látható.

Rizs. 1.

Az életciklus -szoftvermodellek típusai

Vízeséses modell (klasszikus életciklus)

Ez a modell W. Royce -nek (1970) köszönheti megjelenését. A modellnek más neve is van - vízesés. A modell sajátossága, hogy a következő szakaszra való áttérést csak az előző szakaszban végzett munka befejezése után hajtják végre; visszatérítés a letelt szakaszokra nem biztosított.

Rizs. 2.

A kialakított és elemzési szakaszokban meghatározott, a fejlesztett szoftverrendszerre vonatkozó követelményeket szigorúan dokumentálják műszaki előírások formájában, és rögzítik a projektfejlesztés teljes időszakára. Minden szakasz egy teljes dokumentáció (TOR, EP, TP, RP) kiadásával ér véget, amely elegendő ahhoz, hogy a fejlesztést egy másik fejlesztőcsoport folytathassa. A fejlesztés minőségének kritériuma ezzel a megközelítéssel a TK előírásainak végrehajtásának pontossága. A fejlesztők fő figyelme a fejlesztett szoftverrendszer műszaki jellemzőinek optimális értékeinek elérésére összpontosul - teljesítmény, a foglalt memória mennyisége stb.

Előnyök kaszkád modell:

minden szakaszban egy komplett projektdokumentációt állítanak össze, amely megfelel a teljesség és következetesség kritériumainak;
a logikai sorrendben végzett munkaszakaszok lehetővé teszik az összes munka befejezésének ütemezését és a kapcsolódó költségeket.

A vízesés megközelítése jól bevált egy szoftverrendszer kiépítésekor, amelyhez a projekt legelején lehetőség van minden követelmény teljes és egyértelmű megfogalmazására. Mindaddig, amíg mindezt szabványok és különböző állami elfogadó bizottságok ellenőrzik, a rendszer jól működik.

hátrányai kaszkád modell:

a hibák azonosítása és kiküszöbölése csak a tesztelési szakaszban történik, amely jelentősen meghosszabbítható;
a valós projektek gyakran eltéréseket igényelnek a szokásos lépések sorrendjétől;
a ciklus a PS -re vonatkozó kezdeti követelmények pontos megfogalmazásán alapul, valójában a projekt elején az ügyfél igényeit csak részben határozzák meg;
a munka eredményei csak a projekt befejezése után állnak a megrendelő rendelkezésére.

A PS életciklusának iteratív modellje

A kereskedelmi projektek növekedésével világossá vált, hogy nem mindig lehetséges részletesen kidolgozni a jövő rendszerének projektjét, mivel a működés dinamikus tevékenységi (üzleti) területein való működésének számos aspektusa változik a rendszer létrehozása során. Szükséges volt a fejlesztési folyamat megváltoztatása annak biztosítása érdekében, hogy a szükséges javítások bármely fejlesztési szakasz befejezése után megtörténjenek. Így jelent meg a PS életciklus iteratív modellje, amelyet köztes vezérlésű modellnek vagy a fázisok ciklikus ismétlődésének modelljének neveznek.

Rizs. 3.

Egy iteratív modellben a tervezési és programozási hibákat később, az előző szakaszhoz való részleges visszatéréssel lehet kijavítani. Minél alacsonyabb a hibafelismerési arány, annál drágább a javítása. Ha a hibák észleléséhez és kiküszöböléséhez szükséges erőfeszítések költségét a kódírás szakaszában egységként vesszük, akkor a hiba azonosításának és kiküszöbölésének költsége a követelmények kidolgozásának szakaszában 5-10-szer alacsonyabb lesz, és a a hiba azonosítása és kiküszöbölése a karbantartási szakaszban 20 -szor kevesebb lesz.

Rizs. 4.

Ilyen helyzetben a követelmények megfogalmazásának, a specifikációk elkészítésének és a rendszerterv elkészítésének szakasza nagy jelentőségűvé válik. A szoftverfejlesztők személyesen felelősek minden későbbi tervezési változtatásért. A dokumentáció terjedelme több ezer oldal, a jóváhagyó értekezletek száma pedig óriási. Sok projekt soha nem hagyja el a tervezési szakaszt, és "elemzési bénulásba" esik. Az ilyen helyzetek elkerülésének egyik lehetséges módja a prototípus (prototípus).

Elrendezés

Gyakran az ügyfél nem tudja megfogalmazni a jövőbeli szoftvertermék adatainak bevitelére, feldolgozására vagy kimenetére vonatkozó követelményeket. A fejlesztőnek kétségei lehetnek a termék operációs rendszerre való alkalmasságával kapcsolatban, a felhasználóval való párbeszéd formájában, vagy az algoritmus hatékonyságával kapcsolatban. Ilyen esetekben célszerű prototípusokat használni. A prototípus -készítés fő célja az, hogy megszüntesse a vevői követelmények bizonytalanságát. Az elrendezés (prototípus) a szükséges termék modelljének létrehozása.

A modell a következő formákat öltheti.

Papír makett (kézzel rajzolt diagram az ember-gép párbeszédről) vagy PC-alapú makett.
Működő elrendezés, amely megvalósítja a szükséges funkciók egy részét.
Egy meglévő program, amelynek tulajdonságain javítani kell.

Amint az ábrán látható, a prototípus -készítés az ügyfél és a fejlesztő közötti ismételt iterációkon alapul.

Rizs. 5.

A prototípuskészítéshez szükséges műveletek sorrendjét az ábra mutatja. A prototípuskészítés a létrehozandó szoftverrendszer követelményeinek összegyűjtésével és tisztázásával kezdődik. A fejlesztő és a megrendelő közösen határozzák meg a szoftver céljait, meghatározzák, hogy mely követelmények ismertek és melyeket kell tovább meghatározni. Ezután elkészül egy gyors tervezés. Azokra a jellemzőkre összpontosít, amelyeknek láthatónak kell lenniük a felhasználó számára. A gyors tervezés elrendezéshez vezet. Az elrendezést az ügyfél értékeli, és a szoftverkövetelmények tisztázására szolgál. Az ismétlések addig folytatódnak, amíg az elrendezés nem azonosítja az ügyfél összes követelményét, és lehetőséget ad a fejlesztőnek, hogy megértse, mit kell tennie.

A prototípus előnye, hogy képes biztosítani a teljes rendszerkövetelmények meghatározását. Az elrendezés hátrányai:

az ügyfél átveheti a termék elrendezését;
a fejlesztő elhibázhatja a termék elrendezését.

Tisztázni kell a hiányosságok lényegét. Amikor az ügyfél meglátja a PS működő változatát, nem veszi észre, hogy a PS működő verziójának keresése során sok minőségi probléma maradt megoldatlan. könnyű karbantartás rendszereket. Amikor a fejlesztő erről tájékoztatja az ügyfelet, a válasz felháborodás lehet, és az elrendezés leggyorsabb működő termékké történő átalakításának igénye. Ez negatívan befolyásolja a szoftverfejlesztés irányítását.

Rizs. 6.

Másrészről, a fejlesztő gyakran bizonyos kompromisszumokat köt, hogy gyorsan megkapja a működő elrendezést. Például rossz programozási nyelvet vagy operációs rendszert használhat. Egyszerű bemutatáshoz egy nem hatékony (egyszerű) algoritmus használható. Egy idő után a fejlesztő megfeledkezik azokról az okokról, amelyek miatt ezek az eszközök nem megfelelőek. Ennek eredményeképpen a választott opció messze nem ideális a rendszerbe.

Mielőtt más, életciklusra kiterjedő szoftvermodelleket fontolgatna kaszkád modell, a tervezési stratégiákra kell összpontosítanunk szoftverrendszerek... A szoftver tervezési stratégia határozza meg nagymértékben a szoftver életciklus -modelljét.

Szoftvertervezési stratégiák

A szoftverrendszerek tervezésére három stratégia létezik:

single pass (kaszkád stratégia, fentebb tárgyalt) - a tervezési lépések lineáris sorozata;
inkrementális stratégia. A folyamat elején minden felhasználói és rendszerkövetelmény meghatározásra kerül, a tervezés többi része változatok sorozataként történik. Az első verzió a tervezett funkciók egy részét valósítja meg, a következő verzió további funkciókat valósít meg, és így tovább, amíg a teljes rendszer meg nem érkezik;
evolúciós stratégia. A rendszer változatos sorozatban is fel van építve, de nem minden követelmény van definiálva a folyamat elején. A követelmények a verziófejlesztés eredményeként finomodnak. Az IEEE / EIA 12207 szabvány követelményeinek megfelelő szoftver -tervezési stratégiák jellemzőit az 1. táblázat tartalmazza.

Inkrementális modell

Az inkrementális modell az inkrementális tervezési stratégia klasszikus példája. Egyesíti a szekvenciális vízesés modell elemeit a prototípus -készítés iteratív filozófiájával (B. Boehm javasolta javításként kaszkád modell). Itt minden lineáris szekvencia generál egy szoftver növekményt. Például a szavak 1. lépésben történő feldolgozására szolgáló szoftver (verzió) megvalósítja az alapvető fájlfeldolgozási, szerkesztési és dokumentációs funkciókat; a 2. lépésben - összetettebb szerkesztési és dokumentálási lehetőségek; a 3. lépésben - helyesírás és nyelvtan ellenőrzés; 4. lépésben - oldal elrendezési képességek.

Az első lépés egy alapterméket eredményez, amely megvalósítja az alapvető követelményeket (bár sok kiegészítő követelmény nem teljesül). A következő növekedési terv az alaptermék módosításait tartalmazza, hogy további szolgáltatásokat és funkcionalitást biztosítson.

A növekményes folyamat eredendően iteratív, de a prototípusokkal ellentétben az inkrementális modell minden növekménynél működő terméket biztosít.

A szoftver életciklusának ilyen modelljének diagramját az ábra mutatja. Az inkrementális megközelítés egyik modern megvalósítása az extrém programozás (a funkcionalitás nagyon kis lépéseire összpontosítva).

Rizs. 7.

Az életciklus -szoftver spirális modellje

Spirális modell Az evolúciós tervezési stratégia klasszikus példája. A modell (B. Boehm, 1988) a klasszikus életciklus és a prototípus -készítés legjobb tulajdonságain alapul, amelyekhez egy új elemet adnak - a kockázatelemzést, amely ezekben a paradigmákban hiányzik. A modell négy cselekvést határoz meg, amelyeket a spirál négy negyede képvisel.

Rizs. nyolc.

Tervezés - célok, lehetőségek és korlátok meghatározása.
Kockázatelemzés - a lehetőségek elemzése és a kockázat felismerése / kiválasztása.
A mérnöki tevékenység a termékfejlesztés következő szintje.
Értékelés - az ügyfél értékelése az aktuális tervezési eredményekről.

Az integráló szempont spirális modell nyilvánvaló, ha figyelembe vesszük a spirál radiális méretét. Minden iterációval a PS egyre teljesebb verziói spirálba épülnek. A spirál első fordulójában azonosítják a kezdeti célokat, lehetőségeket és korlátokat, valamint felismerik és elemzik a kockázatokat. Ha a kockázatelemzés feltárja a követelmények félreérthetőségét, akkor a tervezési kvadránsban használt prototípus a fejlesztő és a megrendelő segítségére lesz.

A modellezés felhasználható a problémás és finomított követelmények további azonosítására. A megrendelő értékeli a mérnöki (tervezési) munkát, és javaslatokat tesz a módosítások elvégzésére (a vevő értékelésének negyedéve). A tervezés és a kockázatelemzés következő fázisa az ügyfél javaslatain alapul. Minden kockázati ciklusban a kockázatelemzés eredményei "folytatni, nem folytatni" formában alakulnak ki. Ha a kockázat túl nagy, a projekt leállítható.

A legtöbb esetben a spirál folytatódik, és minden lépés a rendszer általánosabb modellje felé mozdítja el a fejlesztőket. Minden spirálciklushoz olyan tervezésre van szükség (jobb alsó kvadráns), amelyet a klasszikus életciklus vagy prototípus készítéssel lehet megvalósítani. Ne feledje, hogy a fejlesztési tevékenységek száma (amelyek a jobb alsó negyedben fordulnak elő) növekszik, amikor elmozdul a spirál közepétől.

Ezek a műveletek számozottak, és a következő tartalommal rendelkeznek:

- a követelmények kezdeti összegyűjtése és a projekttervezés;
- ugyanaz a munka, de az ügyfél ajánlásai alapján;
- a kezdeti követelményeken alapuló kockázatelemzés;
- kockázatelemzés az ügyfél reakciója alapján;
- átmenet integrált rendszerre;
- a rendszer kezdeti elrendezése;
- az elrendezés következő szintje;
- tervezett rendszer;
- az ügyfél általi értékelés.

Méltóság spirális modell:

a legreálisabban (evolúció formájában) mutatja a szoftverfejlesztést;
lehetővé teszi, hogy kifejezetten vegye figyelembe a kockázatot a fejlődés minden szakaszában;
szisztematikus megközelítési lépést tartalmaz egy iteratív fejlesztési struktúrában;
szimulációt használ a kockázat csökkentésére és a szoftvertermék fejlesztésére.

hátrányai spirális modell:

összehasonlító újdonság (nincs elegendő statisztika a modell hatékonyságáról);
megnövekedett követelmények az ügyfelekkel szemben;
nehézségek a fejlesztési idő ellenőrzésében és kezelésében.

A spirális fejlesztési folyamat modellje jelenleg a legelterjedtebb. A leghíresebb változatok a RUP (Rational Unified Process) a Rational -tól és az MSF (Microsoft Solution Framework). Modellezési nyelvként az UML -t (Unified Modeling Language) használják. A rendszer létrehozását feltételezhetően iteratív módon kell végrehajtani, egy spirálban haladva, és ugyanazon szakaszokon átmenve, minden hurkon finomítani a jövőbeli termék jellemzőit. Úgy tűnik, most minden rendben van: csak az előre láthatót tervezik, a tervezettet fejlesztik, és a felhasználók megkezdik a termék előzetes megismerését, lehetőségük van a szükséges kiigazításokra.

Ehhez azonban nagyon nagy pénzeszközökre van szükség. Valóban, ha korábban szükség szerint lehetett szakemberekből álló csoportokat létrehozni és feloszlatni, akkor most mindannyiuknak folyamatosan részt kell venniük a projektben: építészek, programozók, tesztelők, oktatók, stb. Ezen túlmenően a különböző csoportok erőfeszítéseit össze kell hangolni. hogy időben tükrözze a tervezési megoldásokat és elvégezze a szükséges változtatásokat.

Racionális egységes folyamat

Racionális egységes folyamat(Rational Unified Process, RUP) az egyik legjobb szoftverfejlesztési módszertan. Sok sikeres szoftverprojekt tapasztalatai alapján a RUP lehetővé teszi az ipari fejlesztési módszereken alapuló komplex szoftverrendszerek létrehozását. A RUP kialakulásának előfeltételei az 1980 -as évek elején kezdődtek. a Rational Software vállalatnál. 2003 elején a Rational felvásárolta az IBM -et. A RUP egyik fő pillére a modellek létrehozásának folyamata az Unified Modeling Language (UML) használatával.

A RUP az egyik spirál szoftverfejlesztési módszer. A módszertant a Rational Software támogatja és fejleszti. Az egységes modellező nyelvet (UML) használják modellezési nyelvként az általános tudásbázisban. Az iterációs és inkrementális szoftverfejlesztés a RUP -ban magában foglalja a projekt több projektre történő felosztását, amelyeket egymás után hajtanak végre, és a fejlesztés minden iterációját egyértelműen meghatározza az iteráció végén elérendő célhalmaz. A végső iteráció feltételezi, hogy az iteráció célkitűzésének pontosan meg kell egyeznie a termék vevője által meghatározott célhalmazzal, vagyis minden követelménynek teljesülnie kell.

A folyamat magában foglalja a modellek fejlesztését; A fejlesztési ciklus iterációja egyedi módon kapcsolódik a szoftvermodell egy adott verziójához. Az iterációk mindegyike tartalmaz vezérlőket szoftver életciklusa: elemzés és tervezés (modellezés), megvalósítás, integráció, tesztelés, megvalósítás. Ebben az értelemben a RUP egy megvalósítás spirális modell, bár gyakran grafikon-táblázat formájában ábrázolják.

Ez az ábra két dimenziót mutat be: a vízszintes tengely az időt jelzi, és a folyamat életciklusának időbeli vonatkozásait mutatja; a függőleges tengely azokat a tudományágakat képviseli, amelyek meghatározzák a folyamat fizikai szerkezetét. Láthatja, hogyan változnak a projekt ékezetei az idő múlásával. Például a korai iterációkban több időt szentelnek a követelményeknek; a későbbi iterációkban több időt fordítanak a végrehajtásra. A vízszintes tengelyt időintervallumok - iterációk alkotják, amelyek mindegyike független fejlesztési ciklus; a ciklus célja, hogy az előre meghatározott, kézzelfogható finomítást hozza a végtermékbe, amely hasznos az érintettek szempontjából.

Rizs. kilenc.

Az életciklus négy fő szakaszra oszlik az időtengely mentén.

Kezdet - egy projektkoncepció kialakítása, annak megértése, hogy mit hozunk létre, egy termék víziója (jövőkép), üzleti terv kidolgozása (üzleti eset), egy program prototípusának vagy részmegoldásának elkészítése. Ez az információgyűjtés és a követelmények elemzésének fázisa, amely meghatározza a projekt egészének arculatát. A cél a támogatás és a finanszírozás megszerzése. A végső iterációban ennek a szakasznak az eredménye a feladatmeghatározás.
Tervezés, fejlesztés (kidolgozás) - a terv tisztázása, annak létrehozásának megértése, a szükséges intézkedések és erőforrások megtervezése, tervezése, a jellemzők részletezése. A szakasz a végrehajtható architektúrával fejeződik be, amikor minden építészeti döntést meghoznak, és figyelembe veszik a kockázatokat. A végrehajtható architektúra egy futó szoftver, amely bemutatja az alapvető építészeti megoldások megvalósítását. Az utolsó iterációban ez: műszaki projekt.
Megvalósítás, a rendszer létrehozása (építés) - a rendszer funkcionalitásának bővítésének szakasza, beépítve az architektúrába. A végső iterációban ez egy működő tervezet.
Végrehajtás, telepítés (átmenet). A termék végleges verziójának elkészítése. A termék bevezetésének szakasza, a termék szállítása egy adott felhasználóhoz (replikáció, szállítás és képzés).

A függőleges tengely tudományágakból áll, mindegyik részletesebben leírható az elvégzett feladatok, az azokért felelős szerepek, a feladatokhoz bemenetként benyújtott és végrehajtásuk során felszabaduló termékek stb.

E tengely mentén találhatók a RUP életciklusának kulcsfontosságú tudományterületei, amelyeket oroszul gyakran folyamatoknak neveznek, bár ez nem teljesen igaz e módszertan szempontjából, amelyet az IBM (és / vagy harmadik féltől származó) eszközök támogatnak.

Az üzleti elemzés és modellezés (Üzleti modellezés) biztosítja a modellezés elveinek megvalósítását annak érdekében, hogy tanulmányozza a szervezet üzleti tevékenységét, és felhalmozza az ezzel kapcsolatos ismereteket, optimalizálja az üzleti folyamatokat, és eldöntse azok részleges vagy teljes automatizálását.
A követelmények kezelése arról szól, hogy információkat szerezzünk az érdekelt felektől, és azokat olyan követelményrendszerré alakítsuk át, amely meghatározza a fejlesztendő rendszer tartalmát, és részletezi a rendszer teendőit.
Az elemzés és a tervezés lefedi azokat az eljárásokat, amelyek során a követelményeket közbenső leírásokká (modellekké) alakítják át, amelyek azt mutatják, hogyan kell ezeket a követelményeket végrehajtani.
A megvalósítás kiterjed a kód fejlesztésére, a fejlesztői szintű tesztelésre, valamint az összetevők, alrendszerek és az egész rendszer integrálására a megállapított előírásoknak megfelelően.
A tesztelés (teszt) a létrehozott termék minőségének felmérésére szolgál.
A telepítés kiterjed azokra a műveletekre, amelyek akkor történnek, amikor a termékeket átadják az ügyfeleknek, és amikor a terméket a végfelhasználók rendelkezésére bocsátják.
A konfigurációkezelés lényege a köztes szoftverek és a végtermékek szinkronizálása, azok fejlesztésének irányítása a projekt során és rejtett problémák keresése.
A projektmenedzsment (menedzsment) elkötelezett a projekttervezés, a kockázatkezelés, az előrehaladás nyomon követése és a legfontosabb mutatók folyamatos értékelése mellett.
A környezetgazdálkodás (Környezet) magában foglalja az információs rendszer fejlesztési környezet kialakításának elemeit és a projekttevékenységek támogatását.

A projekt sajátosságaitól függően bármilyen IBM Rational vagy harmadik féltől származó eszköz használható. A RUP hat gyakorlatot javasol a sikeres projektfejlesztéshez: iteratív fejlesztés; követelmények kezelése; moduláris architektúrák használata; vizuális modellezés; minőségellenőrzés; változások követése.

A RUP szerves része műtárgyak, előzmények és szerepek. A műtermékek a projekt néhány terméke, amelyeket a végtermék kidolgozásakor hoznak létre vagy használnak fel. A használati esetek olyan műveletsorok, amelyeket a rendszer végez megfigyelhető eredmény elérése érdekében. Valójában az egyén vagy csoport munkájának bármely eredménye műtermék, legyen az elemző dokumentum, modellelem, kódfájl, tesztszkript, hibaleírás stb. Bizonyos szakemberek felelősek a létrehozásért ilyen vagy olyan típusú műtárgyakról. Így a RUP egyértelműen meghatározza a fejlesztőcsapat minden tagjának felelősségét - szerepét - egy vagy másik szakaszban, azaz mikor és kinek kell létrehoznia ezt vagy azt a műterméket. A szoftverrendszer kifejlesztésének teljes folyamatát a RUP a műtermékek létrehozásának folyamatának tekinti - a kezdeti elemzési dokumentumoktól a végrehajtható modulokig, felhasználói kézikönyvekig stb.

A RUP folyamatok számítógépes támogatásához az IBM számos eszközt fejlesztett ki:

Racionális rózsa - ESET vizuális szimulátor információs rendszerek, amelyek képesek kód elemeket generálni. A termék egy speciális kiadása - a Rational Rose RealTime - lehetővé teszi, hogy végrehajtható modult kapjon a kimeneten;
A Rational Requisite Pro egy követelménykezelő eszköz, amely lehetővé teszi az alkalmazások összetevőinek fejlesztésének bármely szakaszában bekövetkező változások létrehozását, strukturálását, rangsorolását, nyomon követését, ellenőrzését;
A Rational ClearQuest egy termék a változások kezeléséhez és a projekt hibáinak nyomon követéséhez (hibakövetés), szorosan integrálva a tesztelési és követelménykezelési eszközökkel, és egyetlen környezetet biztosítva az összes hiba és dokumentum egymással való összekapcsolásához;
A Rational SoDA a projektdokumentáció automatikus generálására szolgáló termék, amely lehetővé teszi a belső dokumentumok vállalati szabványának meghatározását. Lehetőség van arra is, hogy a dokumentációt a meglévő szabványokhoz (ISO, CMM) hozzák;
Rational Purify, Rational Quantify Rational PureCoverage - tesztelési és hibakeresési eszközök;
A Rational Visual Quantify egy teljesítménymérő eszköz azoknak az alkalmazás- és komponensfejlesztőknek, akik C / C ++, Visual Basic és Java nyelven programoznak; segít azonosítani és megszüntetni a szoftver teljesítményének szűk keresztmetszeteit;
Rational Visual PureCoverage - Automatikusan azonosítja azokat a kódrészeket, amelyeket nem tesztelnek.
A Rational ClearCase egy szoftverkonfiguráció -kezelő (SCM) termék, amely lehetővé teszi az összes projektdokumentum verziószabályozását. Lehetővé teszi a projektek több verziójának egyidejű karbantartását, gyors váltást közöttük. A Rational Requisite Pro támogatja a frissítéseket és követi a követelmények változásait a fejlesztő csapat számára;
SQA TeamTest - eszköz teszt automatizálás;
A Rational TestManager egy tesztkezelő rendszer, amely összegyűjti az összes teszttel kapcsolatos eszközt, műterméket, szkriptet és adatot;
Rational Robot - eszköz tesztek létrehozásához, módosításához és automatikus futtatásához;
SiteLoad, SiteCheck - eszközök webhelyek teljesítményének és hibás linkjeinek tesztelésére;
Rational PerformanceStudio - A rendszer teljesítményjellemzőinek mérése és előrejelzése.

Ezt a termékcsomagot folyamatosan fejlesztik és feltöltik. Például a legújabb termék, az IBM Rational Software Architect (RSA) az IBM Software Development Platform része, amely a szoftverfejlesztés életciklusát támogató eszközkészlet. Az IBM Rational Software Architect termék kifejlesztett szoftverrendszerek modelljeinek építésére szolgál az UML 2.0 egységes modellező nyelv használatával, elsősorban a fejlesztett alkalmazás architektúrájának modelljeivel. Az RSA azonban integrálja az olyan szoftvertermékek funkcióit, mint a Rational Application Developer, a Rational Web Developer és a Rational Software Modeler, ezáltal lehetővé téve az építészek és elemzők számára, hogy különböző nézeteket hozzanak létre a fejlesztés alatt álló információs rendszerről az UML 2.0 és a J2EE, XML, webszolgáltatások segítségével stb.

A RUP elveit követve a Rational Software Architect lehetővé teszi a szükséges modellek létrehozását a tudományágak munkafolyamataiban, például:

üzleti elemzés és modellezés (Üzleti modellezés);
követelmények kezelése (Követelmények);
elemzés és tervezés (Elemzés és tervezés);
végrehajtás

Ezenkívül a Rational Software Architect támogatja a modellvezérelt fejlesztési (MDD) technológiát, amely lehetővé teszi a szoftver modellezését különböző szinteken absztrakciók nyomon követhetőséggel.

MSF (Microsoft Solution Framework)

1994 -ben, az informatikai projektek hatásának maximalizálása érdekében a Microsoft kiadott egy iránymutatást a technológiáin alapuló megoldások hatékony tervezéséhez, fejlesztéséhez, megvalósításához és karbantartásához. Ez a tudás a Microsoft által a szoftverek fejlesztésére és karbantartására irányuló nagy projekteken dolgozva szerzett tapasztalatokon, a Microsoft tanácsadói tapasztalatain és az IT -ipar eddigi legjobbjain alapul. Mindezt két egymással összefüggő és egymást jól kiegészítő tudásterület formájában mutatjuk be: a Microsoft Solutions Framework (MSF) és a Microsoft Operations Framework (MOF).

Megjegyzendő, hogy a Microsoft kifejlesztett módszereket az MSF általános módszerei alapján az alkalmazott és speciális felhasználásra. Ezenkívül a Microsoft kifejezetten az MSF alkalmazásában alkalmazott gyakorlati ismeretekben tanúsítja a szakértőket (például az MCTS 74-131 tanúsítványt a projektmenedzsment technikákkal kapcsolatos szakértelemért). Mielőtt megtanulná az MSF technikákat, először meg kell határoznia, hogy melyik MSF alkalmazásra hivatkozik.

A Microsoft által fejlesztett legnépszerűbb MSF alkalmazások:

módszerek a megoldások megvalósításához a projektmenedzsment területén;
módszertan az informatikai projektek kezeléséhez MSF és Agile módszerek alapján.

Az MSF -alkalmazások fontosságát hangsúlyozza, hogy a Microsoft nem használja magát az MSF -módszert IT -projektjeiben "tiszta verzióban". A Microsoft Consulting Services projektek hibrid MSF és Agile módszertant használnak. Annak ellenére, hogy a Microsoft szakértői által kifejlesztett MSF alkalmazott változataiban jelentős külső különbségek vannak, az MSF módszerek alapja továbbra is közös, és tükrözi az iteratív projektmenedzsment általános módszertani megközelítéseit.

A MOF célja, hogy a Microsoft termékein és technológiáin alapuló, küldetéskritikus informatikai megoldásokat építő szervezetek számára műszaki útmutatást nyújtson a megbízhatóságuk, rendelkezésre állásuk eléréséhez, könnyű karbantartás(támogathatóság) és kezelhetőség (kezelhetőség). A MOF foglalkozik az emberek és folyamatok szervezésével kapcsolatos kérdésekkel; technológia és menedzsment komplex, elosztott és heterogén informatikai környezetekben. A MOF a Központi Számítógépes és Távközlési Ügynökség (UK Government Agency) által összeállított IT Infrastructure Library (ITIL) könyvtárban összeállított legjobb gyártási gyakorlatokon alapul.

Az üzleti megoldás kiépítése a megadott időn és költségvetésen belül bizonyított módszertani keretet igényel. Az MSF bevált módszereket kínál a sikeres informatikai megoldások tervezéséhez, tervezéséhez, fejlesztéséhez és megvalósításához. Rugalmasságának, méretezhetőségének és a merev irányelvek hiányának köszönhetően az MSF képes bármilyen méretű szervezet vagy projektcsapat igényeinek kielégítésére. Az MSF módszertan az emberek, folyamatok, technológiai elemek és a kapcsolódó problémák kezelésére vonatkozó elvekből, modellekből és tudományágakból áll, amelyek a legtöbb projektben közösek. Az MSF két modellből és három tudományágból áll. Ezeket 5 fehér háttérkép tartalmazza. Jobb, ha modellekkel (projektcsapat -modell, folyamatmodell) kezdjük el az MSF tanulmányozását, majd továbblépünk a tudományterületekre (projektmenedzsment fegyelem, kockázatkezelési fegyelem, képzési menedzsment fegyelem).

Az MSF folyamatmodell általános módszertant nyújt az informatikai megoldások fejlesztéséhez és megvalósításához. Ennek a modellnek az a sajátossága, hogy rugalmassága és a mereven előírt eljárások hiánya miatt nagyon széles körű informatikai projektek fejlesztésében alkalmazható. Ez a modell két szabványos gyártási modell tulajdonságait ötvözi: a vízesés és a spirál. Az MSF 3.0 folyamatmodelljét egy újabb innovatív aspektus egészítette ki: a megoldás létrehozásának teljes életciklusát lefedi, a kiindulási ponttól a tényleges megvalósításig. Ez a megközelítés segíti a tervezőcsapatokat, hogy a megoldás üzleti értékére összpontosítsanak, mivel ez a megtérülés csak a megvalósítás befejezése és a termék használatba vétele után válik valósággá.

Az MSF folyamata a "mérföldkövekre" összpontosít - a projekt kulcsfontosságú pontjaira, amelyek jellemzik a jelentős (közbenső vagy végső) eredmények keretében elért eredményeket. Ezt az eredményt ki lehet értékelni és elemezni, ami a következő kérdésekre ad választ: "A projektcsapat egyértelműen megértette -e a projekt céljait és hatókörét?", "Elég kész -e az intézkedési terv?" A megoldás megfelel a az ügyfél igényei? " stb.

Az MSF folyamatmodell alkalmazkodik a tervezési követelmények állandó változásához. Feltételezi, hogy a megoldás kifejlesztésének rövid ciklusokból kell állnia, amelyek progresszív mozgást hoznak létre a megoldás legegyszerűbb verzióiból a végső formájába.

Az MSF folyamatmodell jellemzői:

fázis és mérföldkő megközelítése;
iteratív megközelítés;
integrált megközelítés a megoldások létrehozásához és megvalósításához.

A folyamatmodell a fejlesztési folyamat fő fázisait tartalmazza, mint például:

koncepciófejlesztés (elképzelés);
tervezés (tervezés);
fejlesztés (Fejlesztés);
stabilizáció;
telepítés (telepítés).

Ezenkívül számos mérföldkő található, amelyek némi előrelépést mutatnak a projektben, és a munka nagy szegmenseit kisebb, látható területekre bontják. A folyamatmodell minden fázisához az MSF meghatározza:

mi (milyen műtárgyak) ennek a fázisnak az eredménye;
hogy az egyes szerepcsoportok ezen a fázison mit dolgoznak.

Az MSF -en belül a kód, dokumentáció, tervek, tervek és egyéb munkaanyagok általában iteratív módon jönnek létre. Az MSF azt javasolja, hogy a megoldásfejlesztést az alapvető funkciók kiépítésével, tesztelésével és megvalósításával kezdje. Ezután egyre több funkcióval bővül a megoldás. Ezt a stratégiát verzióstratégiának nevezik. Bár egy kiadás elegendő lehet kis projektekhez, ajánlott figyelni arra a lehetőségre, hogy egyetlen verzióhoz több verziót hozzon létre. Az új verziók létrehozásával a megoldás funkcionalitása fejlődik.

A fejlesztési folyamat iteratív megközelítése rugalmas dokumentációt igényel. Az élő dokumentumoknak a projekt fejlődésével együtt a végtermékre vonatkozó követelmények változásával együtt változniuk kell. Az MSF számos szabványos dokumentum sablont kínál, amelyek a termékfejlesztés minden szakaszának műtermékei, és felhasználhatók a fejlesztési folyamat tervezéséhez és ellenőrzéséhez.

A megoldásnak nincs üzleti értéke, amíg meg nem valósítják. Éppen ezért az MSF folyamatmodell tartalmazza a megoldás teljes életciklusát, beleértve annak megvalósítását is, egészen addig a pontig, amikor a megoldás megtérül.

A szoftver életciklus (szoftver életciklus) fogalma a szoftverfejlesztés egyik alapfogalma. Életciklus az az időtartam, amely a szoftver létrehozásának szükségességéről szóló döntés meghozatalának pillanatától kezdődik, és a szolgáltatásból való teljes kilépéskor ér véget.

Az ISO / IEC 12207 szabványnak megfelelően minden életciklus -folyamat három csoportra oszlik (2.1. Ábra).

Alatt életciklus -modell A szoftver alatt olyan szerkezetet értünk, amely meghatározza a végrehajtás sorrendjét és a folyamatok, műveletek és feladatok kapcsolatát az egész életciklus során. Ez a projekt sajátosságaitól, méretétől és összetettségétől, valamint a rendszer létrehozásának és működésének feltételeitől függ. A szoftver életciklusa általában a következő szakaszokat foglalja magában:

1. A szoftverkövetelmények kialakítása.

2. Tervezés.

3. Végrehajtás.

4. Tesztelés.

5. Üzembe helyezés.

6. Üzemeltetés és karbantartás.

7. Leszerelés.

Jelenleg a szoftverek életciklusának alábbi alapvető modelljeit használják a legszélesebb körben:

a) lépcsőzetes és

b) spirál (evolúciós).

Az elsőt kis programokhoz használták, amelyek egyetlen egészet alkotnak. A fő jellemző vízesés megközelítése az, hogy a következő szakaszra való áttérést csak az aktuális munkálatok befejezése után hajtják végre, és nincs visszatérés a letelt szakaszokhoz. Diagramja az ábrán látható. 2.2.

A vízesés modell használatának előnyei a következők:

Minden szakaszban egy komplett projektdokumentációt készítenek;

Az elvégzett munka szakaszai lehetővé teszik a befejezés dátumának és a megfelelő költségek megtervezését.

Ezt a modellt olyan rendszerekhez használják, amelyekre a fejlesztés elején minden követelmény pontosan megfogalmazható. Ide tartoznak például azok a rendszerek, amelyekben elsősorban számítási típusú problémákat oldanak meg. A valódi folyamatok általában iteratív jellegűek: a következő szakasz eredményei gyakran változásokat okoznak a korábbi szakaszokban kidolgozott tervezési megoldásokban. Így a gyakoribb modell a köztes vezérlés, amely az ábrán látható. 2.3.

A kaszkád megközelítés fő hátránya, hogy jelentősen késik az eredmények elérése, és ennek következtében meglehetősen nagy a kockázata annak, hogy olyan rendszert hozzanak létre, amely nem felel meg a felhasználók megváltozott igényeinek.

Ezek a problémák ben oldódnak meg spirális életciklus -modell (2.4. ábra). Alapvető jellemzője, hogy az alkalmazási szoftvert nem azonnal hozzák létre, mint a vízeséses megközelítés esetében, hanem a módszert alkalmazó részekben prototípus készítés ... A prototípus alatt olyan operációs szoftver -összetevőt értünk, amely megvalósítja az egyes funkciókat és a fejlesztendő szoftver külső felületét. A prototípusok készítése több iterációban történik - a spirál fordulatai között.

A vízesés (evolúciós) modellt diagram formájában lehet ábrázolni, amelyet a 2.5.

A spirális életciklus-modell alkalmazásának egyik eredménye a széles körben alkalmazott módszer az ún gyors alkalmazásfejlesztés , vagy RAD (Gyors alkalmazásfejlesztés). E módszer szerint a szoftver életciklusa négy szakaszból áll:

1) a követelmények elemzése és tervezése;

2) tervezés;

3) megvalósítás;

4) végrehajtás.

A programok életciklusának elemzése lehetővé teszi a tartalom tisztázását és a következő folyamatok kiemelését az összetett rendszerek tervezéséhez.

1) stratégia;

2) Elemzés;

3) Tervezés;

4) Végrehajtás;

5) Tesztelés;

6) Végrehajtás;

7) Üzemeltetés és technikai támogatás.

Stratégia

A stratégia meghatározása magában foglalja a rendszer vizsgálatát. A felmérés fő feladata a projekt valós volumenének, céljainak felmérése, valamint az entitások és funkciók magas szintű meghatározásának megszerzése. Ebben a szakaszban magasan képzett üzleti elemzők vesznek részt, akik folyamatosan hozzáférnek a cég vezetéséhez. Ezen túlmenően szoros interakció várható a rendszer fő felhasználóival és üzleti szakértőkkel. Az ilyen interakció fő feladata a lehető legteljesebb információ megszerzése a rendszerről, a vevő igényeinek egyértelmű megértése és a kapott információk formalizált formában történő továbbítása a rendszer elemzőinek. A rendszerrel kapcsolatos információk általában a vezetőséggel, szakértőkkel és felhasználókkal folytatott beszélgetések (vagy szemináriumok) során nyerhetők.

A stratégia meghatározásának szakaszának eredménye egy olyan dokumentum, amelyben a következők egyértelműen megfogalmazottak:

Pontosan mi jár az ügyfélnek, ha vállalja a projekt finanszírozását;

Mikor lesz képes átvenni a készterméket (munkarend)?

Mennyibe fog neki kerülni (a nagy projektek finanszírozási szakaszának ütemezése).

A dokumentumnak nemcsak a költségeket, hanem az előnyöket is tükröznie kell, például a projekt megtérülési idejét, a várható gazdasági hatást (ha felbecsülhető).

A szoftver életciklusának figyelembe vett szakasza csak egyszer ábrázolható a modellben, különösen, ha a modell ciklikus szerkezetű. Ez nem jelenti azt, hogy a ciklikus modellekben stratégiai tervezés egyszer és mindenkorra előállították. Az ilyen modellekben a stratégia és az elemzés meghatározásának szakaszai mintegy kombinálódnak, és elkülönítésük csak a legelső szakaszban létezik, amikor a vállalat vezetése elfogadja elvi döntés a projekt kezdetéről. Általánosságban elmondható, hogy a stratégiai szakasz a dokumentumok vállalatirányítási szinten történő kidolgozásának szentelt.

Az elemzési szakasz az üzleti folyamatok (az előző szakaszban meghatározott funkciók) és a végrehajtásukhoz szükséges információk (entitások, tulajdonságaik és kapcsolataik (kapcsolatok)) részletes tanulmányozását foglalja magában. Ez a szakasz biztosítja az információs modellt, a következő tervezési szakasz pedig az adatmodell.

A rendszerrel kapcsolatos minden, a stratégia meghatározásának szakaszában gyűjtött információ formalizálásra és finomításra kerül az elemzés szakaszában. Különös figyelmet fordítanak a kapott információk teljességére, a következetesség elemzésére, valamint a fel nem használt vagy sokszorosított információk keresésére. Általános szabály, hogy az ügyfél először nem a rendszer egészére, hanem annak egyes összetevőire vonatkozik. És ebben a konkrét esetben a szoftver életciklusának ciklikus modelljei előnyösek, mivel idővel nagy valószínűséggel szükség lesz rá újraelemzés, mivel az ügyfél étvágya gyakran az evéssel jár. Ugyanebben a szakaszban határozzák meg a vizsgálati terv szükséges összetevőit.

Az elemzők két egymással összefüggő formában gyűjtik és rögzítik az információkat:

a) funkciók - információ az üzletben előforduló eseményekről és folyamatokról;

b) entitások - információk a szervezet számára releváns elemekről, amelyekről valami ismert.

Ezzel párhuzamosan komponensek, adatáramok és életciklusok diagramjai készülnek, amelyek leírják a rendszer dinamikáját. Ezekről később lesz szó.

Tervezés

A tervezési szakaszban adatmodellt alakítanak ki. A tervezők feldolgozzák az elemzési adatokat. A tervezési fázis végterméke egy adatbázis -séma (ha létezik ilyen a projektben) vagy egy adattárház -séma (ER -modell) és egy rendszermodul -specifikáció (funkciómodell).

Egy kis projektben (például egy tanfolyamban) ugyanazok az emberek járhatnak el elemzőként, tervezőként és fejlesztőként. A fenti sémák és modellek segítenek megtalálni például a egyáltalán nem leírt, homályosan leírt, ellentmondásban leírt rendszerösszetevőket és egyéb hiányosságokat, ami segít megelőzni a lehetséges hibákat.

Minden specifikációnak nagyon pontosnak kell lennie. A rendszervizsgálati terv véglegesítése is folyamatban van. Sok projekt esetében a tervezési szakasz eredményeit egyetlen dokumentumban - az úgynevezett műszaki specifikációban - dokumentálják. Ugyanakkor az UML nyelv széles körben elterjedt, amely lehetővé teszi egyszerre a kevésbé részletes elemzési dokumentumok (fogyasztói a gyártásmenedzserek) és a tervezési dokumentumok (fogyasztóik a fejlesztési és tesztcsoportok vezetői) egyidejű beszerzését. Ezt a nyelvet később tárgyaljuk. Az UML használatával készült szoftver megkönnyíti a kód generálását - legalábbis az osztályhierarchiát, valamint a módszerek (eljárások és funkciók) kódjának egyes részeit.

A tervezési feladatok a következők:

Az elemzési eredmények mérlegelése és teljességének ellenőrzése;

Szemináriumok az ügyféllel;

A projekt kritikus területeinek azonosítása és korlátainak értékelése;

A rendszer architektúrájának meghatározása;

Döntés a harmadik féltől származó termékek használatáról, valamint az integrációs módszerekről és az ezekkel a termékekkel történő információcsere mechanizmusairól;

Adattárház kialakítása: adatbázis modell;

Folyamat- és kódtervezés: a fejlesztőeszközök végső kiválasztása, a program interfészeinek meghatározása, a rendszerfunkciók leképezése a modulokhoz és a modul specifikációinak meghatározása;

A vizsgálati eljárás követelményeinek meghatározása;

A rendszer biztonsági követelményeinek meghatározása.

Végrehajtás

Egy projekt megvalósításakor különösen fontos a fejlesztőcsapat (ok) összehangolása. Minden fejlesztőnek be kell tartania a forráskontroll szigorú szabályait. Miután megkapta a műszaki projektet, elkezdik a modulkód írását. A fejlesztők fő feladata a specifikáció megértése: a tervező írta, hogy mit kell tenni, és a fejlesztő határozza meg, hogyan kell csinálni.

A fejlesztési szakaszban szoros kapcsolat van a tervezők, a fejlesztők és a tesztelő csapatok között. Intenzív fejlesztés esetén a tesztelő szó szerint elválaszthatatlan a fejlesztőtől, gyakorlatilag a fejlesztőcsapat tagja lesz.

Leggyakrabban a felhasználói felületek változnak a fejlesztési szakaszban. Ez annak köszönhető, hogy a modulokat rendszeresen bemutatják a vevőnek. Jelentősen módosíthatja az adatlekérdezéseket is.

A fejlesztési szakasz a tesztelési fázishoz kapcsolódik, és mindkét folyamat párhuzamosan fut. A hibakövető rendszer szinkronizálja a tesztelők és a fejlesztők műveleteit.

A hibákat prioritás szerint kell osztályozni. A hibák minden osztályára vonatkozóan világos cselekvési struktúrát kell meghatározni: „mit kell tenni”, „milyen sürgős”, „ki a felelős az eredményért”. Minden problémát egy tervezőnek / fejlesztőnek / tesztelőnek kell nyomon követnie, aki felelős a javításért. Ugyanez vonatkozik azokra a helyzetekre is, amikor megsértik a modulok tervezett fejlesztési és tesztelési feltételeit.

Ezenkívül meg kell szervezni a kész projektmodulok és a modulok összeállításakor használt könyvtárak tárházait. Ez az adattár folyamatosan frissül. Egy személynek kell felügyelnie a frissítési folyamatot. Az egyik lerakat a funkcionális tesztelésen átesett modulok számára jön létre, a másik a link tesztelésen átesett modulok számára. Az első a huzat, a második valami, amiből már össze lehet állítani a rendszer elosztó készletét, és bemutatni azt a vevőnek ellenőrző tesztekhez vagy a munka bármely szakaszának leszállításához.

Tesztelés

A tesztcsapatok már a projekt kidolgozása során bevonhatók az együttműködésbe. Általában a komplex tesztelést külön fejlesztési szakaszra osztják. A projekt összetettségétől függően a tesztelés és a hibajavítás a projekt teljes idejének egyharmadát, felét vagy akár többet is igénybe vehet.

Minél összetettebb a projekt, annál nagyobb szükség van a hibakövető rendszer automatizálására, amely a következő funkciókat biztosítja:

A hibaüzenet tárolása (a rendszer melyik összetevőjéhez tartozik a hiba, ki találta meg, hogyan kell reprodukálni, ki a felelős a javításért, mikor kell kijavítani);

Az értesítési rendszer az új hibák megjelenéséről, a rendszerben ismert hibák állapotának változásáról (e-mail értesítések);

Jelentések a rendszerkomponensek tényleges hibáiról;

Információ a hibáról és annak előzményeiről;

Bizonyos kategóriák hibáinak elérésére vonatkozó szabályok;

Hibakövetési rendszer korlátozott hozzáférési felület a végfelhasználó számára.

Az ilyen rendszerek számos szervezeti problémát vállalnak fel, különösen az automatikus hibajelzés kérdéseit.

A tényleges rendszerteszteket általában több kategóriába sorolják:

a) offline tesztek modulok; ezeket már a rendszerkomponensek fejlesztési szakaszában használják, és lehetővé teszik az egyes összetevők hibáinak nyomon követését;

b) link tesztek rendszer összetevők; ezeket a teszteket a fejlesztési szakaszban is használják, lehetővé teszik a rendszerösszetevők közötti helyes interakció és információcsere nyomon követését;

c) rendszer teszt; ez a rendszer elfogadásának fő kritériuma; Jellemzően ez a tesztek csoportja, amely magában foglalja az önálló teszteket és a kapcsolódási teszteket és modelleket; egy ilyen vizsgálatnak reprodukálnia kell a rendszer összes összetevőjének és funkciójának működését; fő célja a rendszer belső elfogadása és minőségének értékelése;

d) elfogadási teszt; fő célja a rendszer átadása az ügyfélnek;

e) teljesítmény- és terhelésvizsgálatok; ez a tesztcsoport szerepel a rendszerben, ő a fő a rendszer megbízhatóságának értékeléséhez.

Minden csoport szükségszerűen tartalmaz teszteket a hibák modellezésére. Ellenőrzik a komponensek, az alkatrészcsoportok és a rendszer egészének válaszát a következő hibákra:

Az információs rendszer különálló összetevője;

Rendszerkomponensek csoportjai;

A rendszer fő moduljai;

Operációs rendszer;

Kemény hiba (áramszünet, merevlemezek).

Ezek a tesztek lehetővé teszik az alrendszer minőségének felmérését az információs rendszer megfelelő állapotának helyreállítása érdekében, és fő információforrásként szolgálnak az ipari működés során fellépő meghibásodások negatív következményeinek megelőzésére irányuló stratégiák kidolgozásához.

Az információs rendszerek tesztelési programjának másik fontos szempontja a tesztadat -generátorok rendelkezésre állása. Ezeket a rendszer működőképességének, megbízhatóságának és teljesítményének tesztelésére használják. Adatgenerátorok nélkül lehetetlen megoldani azt a problémát, hogy felmérjük az információs rendszer teljesítményének a feldolgozott információ mennyiségének növekedésétől való függőségének jellemzőit.

Végrehajtás

A próbaüzem átfedi a tesztelési folyamatot. A rendszert ritkán hajtják végre teljesen. Jellemzően ez egy fokozatos vagy iteratív folyamat (ciklikus életciklus esetén).

Az üzembe helyezés legalább három szakaszon megy keresztül:

2) információgyűjtés;

3) a tervezési kapacitás elérése (azaz a tényleges átmenet az üzemeltetési szakaszba).

Az információk meglehetősen szűk körű hibákat okozhatnak: főként az adatok eltérései a betöltés során és a rendszerbetöltő saját hibái. Ezek azonosítására és kiküszöbölésére adatminőség -ellenőrzési módszereket alkalmaznak. Az ilyen hibákat a lehető leghamarabb ki kell javítani.

Az időszak alatt információgyűjtés v tájékoztatási rendszer a legtöbb felhasználóhoz tartozó hibát észleli a rendszer. A javítások második kategóriája azzal a ténnyel kapcsolatos, hogy a felhasználó nem elégedett a kezelőfelülettel. Ugyanakkor a szakaszok ciklikus és visszacsatolási modelljei csökkenthetik a költségeket. Ez a szakasz a legkomolyabb teszt is - az ügyfél -elfogadási tesztek.

A rendszer eléri tervezési kapacitását jó változatban apró hibák és ritka súlyos hibák finomhangolása.

Működés és műszaki támogatás

Ebben a szakaszban a végső dokumentum a fejlesztők számára a műszaki elfogadási aktus. A dokumentum meghatározza a rendszer működőképességének támogatásához szükséges személyzetet és felszereléseket, valamint a termék működésének megszakításának feltételeit és a felek felelősségét. Ezenkívül a műszaki támogatás feltételeit általában külön dokumentumként kell elkészíteni.