Kokkuvõte: Infosüsteemide elutsükkel.
Tööõppekavast:
Teema 2. Süsteemide ja tarkvaratehnika standardid ja regulatiivsed juhised.
ISO/IEC 15288 "Süsteemide projekteerimine – süsteemide elutsükli protsessid".
GOST 34: standardite kogum automatiseeritud süsteemid.
Süsteemitehnika põhiideed: süsteemilähenemine, süsteemi elutsükkel, nõuete kavandamine, arhitektuurne projekteerimine, protsessi lähenemine, projekti lähenemine.
2.1. ISO 15288 "Süsteemide ehitus – süsteemide elutsükli protsessid".
2.2. Süsteemi elutsükkel.
2.3. Süsteemi elutsükli vaated.
2.4. Infosüsteemi elutsükkel
2.5. Elutsükli mudelid
2.6. Elutsükli mudeli valimine
2.1. ISO 15288 süsteemitehnika – süsteemide elutsükli protsessid.
Süsteemitehnoloogiat kasutatakse inimeste loodud süsteemide keerukuse suurenemisega seotud probleemide lahendamiseks. ISO 15288 standard, mis kirjeldab süsteemitehnilisi tavasid, nõuab süsteemi elutsükli ja selle tavade kirjeldust. Selline kirjeldus on vajalik süsteemi edukaks edasiliikumiseks selle elutsükli jooksul. Kuid standard ei täpsusta meetodeid, mille abil selline kirjeldus tuleb luua.
Standardi eesmärgid:
Võimaldada organisatsioonidel (välis- ja sisetöövõtjatel) kokku leppida mitmesuguste tehissüsteemide – hambaorkidest tuumaelektrijaamadeni, standardimissüsteemidest ettevõteteni – ideede, projekteerimisprotsesside, loomise, käitamise ja dekomisjoneerimise protsesside osas.
süstemaatiline lähenemine
eluring
nõuete insener
arhitektuurne projekteerimine
protsessi lähenemine
projekti lähenemine
lepingukultuur
Rakendage organisatsiooni praktikas mitmeid olulisi süsteemitehnoloogia ideid:
OnTOriyalooming
ISO ja IEC ühine arendus, INCOSE aktiivne osalemine
Töö algus 1996, versioonid 2002, 2005 (GOST R ISO/IEC 15288-2005), 2008
Mõeldud süsteemitehnoloogia niinimetatud "standardite soo" ühtlustamiseks (arvukad standardid, mille on vastu võtnud erinevad sõjaväeosakonnad, osariigid, tööstuse standardiorganisatsioonid)
Standardi väljatöötamisse kaasati eksperte erinevatest valdkondadest: süsteemitehnika, programmeerimine, kvaliteedijuhtimine, personalijuhtimine, turvalisus jne. Arvesse võeti praktilisi kogemusi süsteemide loomisel valitsus-, kaubandus-, militaar- ja akadeemilistes organisatsioonides. Standard on rakendatav paljudele süsteemide klassile, kuid selle peamine eesmärk on toetada arvutisüsteemide loomist.
2.2. Süsteemi elutsükkel
Venekeelne lühend: J C
Ingliskeelne lühend: L.C. (EluTsükkel)
vene keel: "eluring". Ingliskeelne elutsükkel tehnoloogias tähendas ja seda tõlgiti varem kui "kasutusiga" ja mõnikord isegi "tööiga kuni esimese suurema remondini". "Eluring" on suhteline uus tõlge. Mõnikord tõlgitakse "tsükkel" kui "periood", kuid seda tõlget pole kindlaks tehtud (kuigi see on antud juhul täpsem: süsteemi "eluperiood"). Sõna "tsükkel" ei tohiks segadust tekitada - elutsüklis pole midagi tsüklilist. Sõnal "tsükkel" on tähendus "tüüpilisus", mis viitab sellele, et sama juhtub ka teiste süsteemidega.
Formaalselt: elutsükkel on süsteemi olekute muutumine (süsteemi areng) aja jooksul alates kontseptsioonist kuni selle eksisteerimise lõppemiseni.
Süsteem ja elutsükkel on kaksikvennad. Me ütleme süsteem - me mõtleme elutsüklit, me ütleme elutsüklit - me mõtleme süsteemi.
Definitsioonid.
ISO/IEC 15288:2008 standardi määratlus (määratlus: elutsükkel – süsteemi, toote, teenuse, projekti või muu inimese loodud üksuse areng alates selle loomisest kuni pensionile jäämiseni (ISO 15288, 4.11):
eluring (elutsükkel) on süsteemi, toote, teenuse, projekti või muu tehisobjekti areng alates selle loomisest kuni kasutamise lõpetamiseni.
ISO 15704 standardi määratlus (Tööstuslikud automatiseerimissüsteemid – Nõuded ettevõtte võrdlusarhitektuuridele ja metoodikatele)
eluring (Elutsükkel) on peamiste faaside ja etappide piiratud kogum, mille süsteem läbib kogu oma eksisteerimise ajaloo jooksul.
Iga süsteem, olenemata selle tüübist ja mastaabist, läbib mingi kirjelduse kohaselt kogu oma elutsükli. Süsteemi edenemine läbi selle kirjelduse osade on süsteemi elutsükkel. Elutsükli kirjeldus on seega see on kontseptuaalne segmenteerimine etappide kaupa, mis hõlbustab sihtsüsteemi planeerimist, kasutuselevõttu, toimimist ja toetamist.
Kõige enam esindavad etapid (tabel 2.1). suuremad perioodid elutsükkel, mis on seotud süsteemiga ja on seotud süsteemi kirjelduse olekutega või süsteemi kui toodete või teenuste kogumi rakendamisega. Etapid kirjeldavad peamist kontrollpunktid süsteemi edu ja edu kogu selle elutsükli jooksul. Sellised segmendid tagavad süsteemi korrapärase edenemise kehtestatud ressursside jaotamise muudatuste kaudu, mis vähendab riske ja tagab rahuldava edenemise. Peamine elutsükli kirjelduste kasutamise põhjus on vajadus langetada otsuseid teatud kriteeriumide alusel enne süsteemi üleviimist järgmine etapp.
Tabel 2.1
Süsteemi arendamise etapid (ISO/IEC 15288) |
||
№ p./lk. |
Lava |
Kirjeldus |
Mõiste kujunemine |
Vajaduste analüüs, kontseptsiooni valik ja disainilahendused |
|
Areng |
Süsteemi disain |
|
Rakendamine |
Süsteemi tootmine |
|
Ärakasutamine |
Süsteemi kasutuselevõtt ja kasutamine |
|
Toetus |
Süsteemi toimimise tagamine |
|
Dekomisjoneerimine |
Süsteemi kasutamise lõpetamine, demonteerimine, arhiveerimine |
Tabel 2.1
Definitsioonid.
1. Standardi ISO/IEC 15288:2008 määratlus (määratlus: elutsükkel – süsteemi, toote, teenuse, projekti või muu inimese loodud üksuse areng alates selle loomisest kuni pensionile jäämiseni (ISO 15288, 4.11):
elutsükkel (LC) on süsteemi, toote, teenuse, projekti või muu tehisobjekti areng alates selle loomisest kuni kasutamise lõpetamiseni.
2. ISO 15704 standardi määratlus (Tööstuslikud automatiseerimissüsteemid – Nõuded ettevõtte võrdlusarhitektuuridele ja metoodikatele)
elutsükkel (LC) on põhifaaside ja etappide piiratud kogum, mille süsteem läbib kogu oma eksisteerimise ajaloo jooksul.
Iga süsteem, olenemata selle tüübist ja mastaabist, läbib mingi kirjelduse kohaselt kogu oma elutsükli. Süsteemi edenemine läbi selle kirjelduse osade on süsteemi elutsükkel. Elutsükli kirjeldus on seega see on kontseptuaalne segmenteerimine etappide kaupa, mis hõlbustab sihtsüsteemi planeerimist, kasutuselevõttu, toimimist ja toetamist.
Etapid (tabel 2.1) esindavad süsteemiga seotud elutsükli suurimaid perioode ja vastavad süsteemi kirjelduse või süsteemi kui toodete või teenuste kogumi rakendamise olekutele. Etapid kirjeldavad süsteemi edenemise ja edu peamisi verstaposte kogu selle elutsükli jooksul. Sellised segmendid tagavad süsteemi korrapärase edenemise kehtestatud ressursside jaotamise muudatuste kaudu, mis vähendab riske ja tagab rahuldava edenemise. Peamine põhjus elutsükli kirjelduste kasutamiseks on vajadus langetada otsuseid teatud kriteeriumide alusel enne süsteemi järgmisse etappi viimist.
Kommentaar: elutsükkel on alati konkreetse süsteemi elutsükkel. “Eluringi” pole olemas, välja arvatud standardite tekstides, elus on alati “elutsükkel X”, kus X on sihtsüsteemi nimi. Elutsükli protsessid on protsessid, mida osalejad süsteemis/koos süsteemiga teostavad ja mis muudavad süsteemi olekut, põhjustades selle elutsükli jooksul arenemise. "Elutsükli juhtimine" on elutsükli protsesside kirjeldamise lähenemisviisi üldtunnustatud nimetus (ja sageli ka elutsükli protsesside rühma nimi, mida seda lähenemisviisi kasutades kirjeldatakse).
Süsteemil on kaks põhivaadet: siht (arhitektuurne, kõige sagedamini struktuurne oma baasil, pluss protsessid süsteemi töö käigus) ja elutsükkel (elutsükli ajaline areng - tugisüsteemide protsessid). Selle üle, mil määral kumbki neist seisukohtadest on osa teisest, võib vaielda, kuid süsteemi õigeks kirjeldamiseks tuleb alati kasutada mingit elutsükli vaadet.
Esiteks on vaja eristada elutsüklit (mõnikord piirdub ainult inseneritööga, kuid mitte täieliku elutsükliga, öeldakse ka tarneprotsess, mõnikord tarkvara jaoks - tarkvaraprotsess) ja muud "protsessi esitused" - DEMO tehingud. , loogilised “äriprotsessid” (praktikad ), töövood, projekti vaated (täpsemalt - http://ailev.livejournal.com/904643.html). Kuigi on palju lähenemisviise, milles kõik need erinevaid aspekte organisatsiooni ja selle töömeetodite kirjeldused on segased.
Elutsükli mudel peegeldab erinevad osariigid süsteemid, alates hetkest, mil vajadus selle infosüsteemi järele tekib ja lõpetades selle täieliku vananemise hetkega. Elutsükli mudel on struktuur, mis sisaldab protsesse, toiminguid ja ülesandeid, mida viiakse läbi tarkvaratoote arendamise, töötamise ja hooldamise käigus kogu süsteemi eluea jooksul alates nõuete määramisest kuni selle kasutamise lõpuni.
Nende keelte elutsükli ning teksti ja graafiliste tähistuste esitamiseks on palju keeli; näiteks piirdume ainult järgmisega:\
· "Viilutatud vorst"
V-diagramm
Viilutatud vorst."
Lihtsalt loetledes elutsükli etapid nende nimede järgi; väljendusrikkuse huvides on nimed pakendatud “vorsti” segmentidesse (joonis 2.1)
Joonis 2.1. Traditsiooniline esitus eluring
Traditsioonilise “vorsti” ümber võib välja tuua veel kaks: kuidas elutsüklit näevad juhid (projekti juhid) ja kuidas elutsüklit näevad insenerid (projekti elluviijad) (joonis 2.2).
Joonis 2.2. Elutsükli vaate näide
Eluringe vaadeldakse üksikute toodete ja vajaduste ajaloos, kaubamärgid, ettevõtted, terved tööstusharud ja turud. Elutsükkel on lahutamatu konkreetsest süsteemist, seega funktsioonidest erinevad süsteemid tekitada väga erinevaid elutsükli "vorsti" isendeid (joonis 2.3).
Joon.2.3. Elutsüklite mitmekesisus
1. IS elutsükkel ja selle struktuur. 2
1.1 IS elutsükli etapid.. 3
1.2 IS elutsükli standardid.. 4
2. Elutsükli mudelid. 6
2.1 IS elutsükli mudelite tüübid.. 6
2.2 IS elutsükli mudelite eelised ja puudused.. 8
3. IS elutsükli protsessid................................................ ........................ üksteist
3.1 Põhilised elutsükli protsessid. üksteist
3.2 Olelusringi protsesside toetamine. 13
3.3 Organisatsiooniprotsessid.. 14
Kasutatud kirjanduse loetelu... 16
Infosüsteemi elutsükkel on ajavahemik, mis algab hetkest, mil tehakse otsus infosüsteemi loomise vajaduse kohta ja lõpeb hetkega, mil see täielikult kasutusest kõrvaldatakse.
Elutsükli mõiste on üks põhimõisteid disainimetoodikad infosüsteemid.
Infosüsteemide projekteerimise metoodika kirjeldab süsteemide loomise ja hooldamise protsessi IS elutsükli (LC) kujul, esitades selle teatud etappide ja nendel läbiviidavate protsesside jadana. Iga etapi jaoks määratakse kindlaks tehtud tööde koosseis ja järjestus, saadud tulemused, töö tegemiseks vajalikud meetodid ja vahendid, osalejate rollid ja vastutus jne. Infosüsteemi elukaare selline formaalne kirjeldus võimaldab planeerida ja korraldada kollektiivse arendusprotsessi ning tagada selle protsessi juhtimise.
Infosüsteemi kogu elutsükkel hõlmab tavaliselt strateegiline planeerimine, analüüs, kavandamine, rakendamine, rakendamine ja toimimine. Üldiselt võib elutsükli omakorda jagada mitmeks etapiks. Põhimõtteliselt on selline etappideks jaotus üsna meelevaldne. Kaalume ühte sellise jaotuse võimalust, mida pakub Rational Software Corporation, üks juhtivaid ettevõtteid infosüsteemide arendustööriistade tarkvaraturul (mille hulgas on universaalne CASE tööriist Rational Rose teenitult väga populaarne).
1.1 IP elutsükli etapid
Etapp - osa IP loomise protsessist, mis on piiratud teatud ajaraamiga ja lõpeb konkreetse toote (mudelid, tarkvarakomponendid, dokumentatsioon) väljalaskmisega, mis määratakse kindlaks selle etapi nõuetega. Protsesside ja etappide vahelise seose määrab ka kasutatav IS elutsükli mudel.
Rational Software poolt välja pakutud metoodika järgi on infosüsteemi elutsükkel jagatud nelja etappi.
Iga etapi piirid on määratletud teatud ajahetkega, mil tuleb teha teatud kriitilised otsused ja seetõttu tuleb saavutada teatud põhieesmärgid.
1) Esialgne etapp
Peal esialgne etapp kehtestatakse süsteemi rakendusala ja määratakse piirtingimused. Selleks on vaja tuvastada kõik välised objektid, millega arendatud süsteem peab suhtlema, ja määrata selle interaktsiooni olemus kõrge tase. Algstaadiumis tehakse kindlaks kõik süsteemi funktsionaalsused ja kirjeldatakse neist olulisemad.
2) Selgitamise etapp
Selgitamise etapis viiakse läbi rakendusala analüüs, töötatakse välja infosüsteemi arhitektuurne alus.
Süsteemi arhitektuuri puudutavate otsuste tegemisel tuleb arvestada arendatava süsteemi kui tervikuga. See tähendab, et kirjeldada on vaja enamikku funktsionaalsust süsteemi ja võtma arvesse selle üksikute komponentide vahelisi seoseid.
Selgitamisetapi lõpus viiakse läbi arhitektuursete lahenduste ja projekti peamiste riskitegurite kõrvaldamise võimaluste analüüs.
3) Ehitusetapp
Projekteerimisetapis töötatakse välja valmistoode, mis on valmis kasutajale tarnimiseks.
Selle etapi lõpus tehakse kindlaks arendatud tarkvara jõudlus.
4) Kasutuselevõtu etapp
Kasutuselevõtu etapis antakse väljatöötatud tarkvara kasutajatele üle. Töötades väljatöötatud süsteemi reaalsetes tingimustes, tekivad sageli erinevat tüüpi probleemid, mis nõuavad täiendavat tööd arendatud toote kohandamiseks. Tavaliselt seostatakse seda vigade ja puuduste avastamisega.
Kasutuselevõtu etapi lõpus on vaja kindlaks teha, kas arenduseesmärgid on saavutatud või mitte.
1.2 IP elutsükli standardid
Kaasaegsed võrgud on välja töötatud standardite alusel, mis võimaldab tagada esiteks nende kõrge efektiivsusega ja teiseks nende omavahelise suhtlemise võimalus.
Kõige tuntumate standardite hulgas on järgmised:
GOST 34.601-90 - kehtib automatiseeritud süsteemide kohta ja määrab nende loomise etapid ja etapid. Lisaks sisaldab standard iga etapi töö sisu kirjeldust. Standardis sätestatud tööetapid ja etapid on paremini kooskõlas kaskaadi elutsükli mudeliga.
ISO/IEC 12207 (Rahvusvaheline Standardiorganisatsioon / International Electrotechnical Commission) 1995 – protsesside ja elutsükli korralduse standard. Kehtib igat tüüpi kohandatud tarkvara kohta. Standard ei sisalda faaside, etappide ja etappide kirjeldusi.
Rational Unified Process (RUP) pakub iteratiivset arendusmudelit, mis sisaldab nelja faasi: käivitamine, uurimine, ehitamine ja rakendamine. Iga faasi saab jaotada etappideks (iteratsioonideks), mille tulemusel väljastatakse versioon sise- või väliskasutuseks. Nelja põhifaasi läbimist nimetatakse arendustsükliks, iga tsükkel lõpeb süsteemi versiooni genereerimisega. Kui projekti kallal töötamine pärast seda ei peatu, jätkab saadud toode arenemist ja läbib uuesti samad etapid. RUP-i raames tehtava töö põhiolemus on UML-põhiste mudelite loomine ja hooldamine.
Microsoft Solution Framework (MSF) sarnaneb RUP-iga, see sisaldab ka nelja faasi: analüüs, projekteerimine, arendus, stabiliseerimine, see on iteratiivne ja hõlmab objektorienteeritud modelleerimise kasutamist. MSF on RUP-iga võrreldes rohkem keskendunud ärirakenduste arendamisele.
Extreme Programming (XP). Ekstreemprogrammeerimine (vaatluse all olevatest metoodikatest uusim) moodustati 1996. aastal. Metoodika põhineb meeskonnatööl, efektiivsel suhtlusel tellija ja töövõtja vahel kogu IP arendusprojekti vältel ning arendus toimub kasutades järjepidevat kõrgelt viimistletud prototüübid.
2. Elutsükli mudelid
IS-i elutsükli mudel on struktuur, mis määratleb protsesside, toimingute ja ülesannete vahelised toimingud ja seosed kogu elutsükli jooksul. Elutsükli mudel sõltub projekti spetsiifikast, ulatusest ja keerukusest ning konkreetsetest tingimustest, milles süsteem luuakse ja töötab.
IS elutsükli mudel sisaldab:
töö tulemused igas etapis;
võtmesündmused - tööde lõpetamise ja otsustamise punktid.
Elutsükli mudel kajastab süsteemi erinevaid olekuid, alustades hetkest, mil tekib vajadus antud IS järele ja lõpetades selle täieliku vananemise hetkega.
2.1 IS elutsükli mudelite tüübid
Praegu on teada ja kasutusel järgmised elutsükli mudelid:
Kaskaadmudel (joonis 2.1) näeb ette projekti kõigi etappide järjestikuse rakendamise rangelt fikseeritud järjekorras. Üleminek järgmisele etapile tähendab töö täielikku lõpetamist eelmises etapis.
Lavastatud mudel vahepealse juhtimisega (joon. 2.2). IS arendamine toimub iteratsioonidena tsüklitega tagasisidet etappide vahel. Etappidevahelised kohandused võimaldavad arvestada arendustulemuste tegelikku vastastikust mõju erinevatel etappidel; Iga etapi eluiga ulatub üle kogu arendusperioodi.
Spiraalmudel (joon. 2.3). Igal spiraali pöördel luuakse toote järgmine versioon, täpsustatakse projekti nõuded, määratakse selle kvaliteet ja planeeritakse järgmise pöörde tööd. Erilist tähelepanu pööratakse arenduse algfaasidele - analüüsile ja projekteerimisele, kus teatud tehniliste lahenduste teostatavust testitakse ja põhjendatakse prototüüpide (paigutus) loomise kaudu.
Riis. 2.1. IS elutsükli kaskaadmudel
Riis. 2.2. Vahejuhtimisega astmeline mudel
Riis. 2.3. IS elutsükli spiraalmudel
Praktikas kasutatakse kõige laialdasemalt kahte peamist elutsükli mudelit:
kaskaadmudel (tüüpiline perioodil 1970–1985);
spiraalmudel (tüüpiline perioodile pärast 1986. aastat).
2.2 IP elutsükli mudelite eelised ja puudused
Varasemates üsna lihtsa IS-i projektides oli iga rakendus üks funktsionaalselt ja informatsiooniliselt sõltumatu plokk. Seda tüüpi rakenduste väljatöötamisel on kaskaadmeetod osutunud tõhusaks. Iga etapp lõpetati pärast täielikku lõpetamist ja dokumentatsioon kõik planeeritud tööd.
1. IS elutsükkel ja selle struktuur. 2
1.1 IS elutsükli etapid.. 3
1.2 IS elutsükli standardid.. 4
2. Elutsükli mudelid. 6
2.1 IS elutsükli mudelite tüübid.. 6
2.2 IS elutsükli mudelite eelised ja puudused.. 8
3. IS elutsükli protsessid................................................ ........................ üksteist
3.1 Põhilised elutsükli protsessid. üksteist
3.2 Olelusringi protsesside toetamine. 13
3.3 Organisatsiooniprotsessid.. 14
Kasutatud kirjanduse loetelu... 16
Infosüsteemi elutsükkel on ajavahemik, mis algab hetkest, mil tehakse otsus infosüsteemi loomise vajaduse kohta ja lõpeb hetkega, mil see täielikult kasutusest kõrvaldatakse.
Elutsükli mõiste on infosüsteemide projekteerimise metoodika üks põhimõisteid.
Infosüsteemide projekteerimise metoodika kirjeldab süsteemide loomise ja hooldamise protsessi IS elutsükli (LC) kujul, esitades selle teatud etappide ja nendel läbiviidavate protsesside jadana. Iga etapi jaoks määratakse kindlaks tehtud tööde koosseis ja järjestus, saadud tulemused, töö tegemiseks vajalikud meetodid ja vahendid, osalejate rollid ja vastutus jne. Infosüsteemi elukaare selline formaalne kirjeldus võimaldab planeerida ja korraldada kollektiivse arendusprotsessi ning tagada selle protsessi juhtimise.
Infosüsteemi kogu elutsükkel hõlmab tavaliselt strateegilist planeerimist, analüüsi, kavandamist, rakendamist, rakendamist ja toimimist. Üldiselt võib elutsükli omakorda jagada mitmeks etapiks. Põhimõtteliselt on selline etappideks jaotus üsna meelevaldne. Kaalume ühte sellise jaotuse võimalust, mida pakub Rational Software Corporation, üks juhtivaid ettevõtteid infosüsteemide arendustööriistade tarkvaraturul (mille hulgas on universaalne CASE tööriist Rational Rose teenitult väga populaarne).
1.1 IP elutsükli etapid
Etapp - osa IP loomise protsessist, mis on piiratud teatud ajaraamiga ja lõpeb konkreetse toote (mudelid, tarkvarakomponendid, dokumentatsioon) väljalaskmisega, mis määratakse kindlaks selle etapi nõuetega. Protsesside ja etappide vahelise seose määrab ka kasutatav IS elutsükli mudel.
Rational Software poolt välja pakutud metoodika järgi on infosüsteemi elutsükkel jagatud nelja etappi.
Iga etapi piirid on määratletud teatud ajahetkega, mil tuleb teha teatud kriitilised otsused ja seetõttu tuleb saavutada teatud põhieesmärgid.
1) Esialgne etapp
Algstaadiumis määratakse kindlaks süsteemi ulatus ja määratakse kindlaks piirtingimused. Selleks on vaja tuvastada kõik välised objektid, millega arendatud süsteem peab suhtlema, ja määrata selle interaktsiooni olemus kõrgel tasemel. Algstaadiumis tehakse kindlaks kõik süsteemi funktsionaalsused ja kirjeldatakse neist olulisemad.
2) Selgitamise etapp
Selgitamise etapis viiakse läbi rakendusala analüüs, töötatakse välja infosüsteemi arhitektuurne alus.
Süsteemi arhitektuuri puudutavate otsuste tegemisel tuleb arvestada arendatava süsteemi kui tervikuga. See tähendab, et on vaja kirjeldada enamikku süsteemi funktsionaalsusest ja arvestada selle üksikute komponentide vahelisi seoseid.
Selgitamisetapi lõpus viiakse läbi arhitektuursete lahenduste ja projekti peamiste riskitegurite kõrvaldamise võimaluste analüüs.
3) Ehitusetapp
Projekteerimisetapis töötatakse välja valmistoode, mis on valmis kasutajale tarnimiseks.
Selle etapi lõpus tehakse kindlaks arendatud tarkvara jõudlus.
4) Kasutuselevõtu etapp
Kasutuselevõtu etapis antakse väljatöötatud tarkvara kasutajatele üle. Töötades väljatöötatud süsteemi reaalsetes tingimustes, tekivad sageli erinevat tüüpi probleemid, mis nõuavad täiendavat tööd arendatud toote kohandamiseks. Tavaliselt seostatakse seda vigade ja puuduste avastamisega.
Kasutuselevõtu etapi lõpus on vaja kindlaks teha, kas arenduseesmärgid on saavutatud või mitte.
1.2 IP elutsükli standardid
Kaasaegsed võrgud on välja töötatud standardite alusel, mis võimaldab tagada esiteks nende kõrge efektiivsuse ja teiseks nende üksteisega suhtlemise võimaluse.
Kõige tuntumate standardite hulgas on järgmised:
GOST 34.601-90 - kehtib automatiseeritud süsteemide kohta ja määrab nende loomise etapid ja etapid. Lisaks sisaldab standard iga etapi töö sisu kirjeldust. Standardis sätestatud tööetapid ja etapid on paremini kooskõlas kaskaadi elutsükli mudeliga.
ISO/IEC 12207 (Rahvusvaheline Standardiorganisatsioon / International Electrotechnical Commission) 1995 – protsesside ja elutsükli korralduse standard. Kehtib igat tüüpi kohandatud tarkvara kohta. Standard ei sisalda faaside, etappide ja etappide kirjeldusi.
Rational Unified Process (RUP) pakub iteratiivset arendusmudelit, mis sisaldab nelja faasi: käivitamine, uurimine, ehitamine ja rakendamine. Iga faasi saab jaotada etappideks (iteratsioonideks), mille tulemusel väljastatakse versioon sise- või väliskasutuseks. Nelja põhifaasi läbimist nimetatakse arendustsükliks, iga tsükkel lõpeb süsteemi versiooni genereerimisega. Kui projekti kallal töötamine pärast seda ei peatu, jätkab saadud toode arenemist ja läbib uuesti samad etapid. RUP-i raames tehtava töö põhiolemus on UML-põhiste mudelite loomine ja hooldamine.
Microsoft Solution Framework (MSF) sarnaneb RUP-iga, see sisaldab ka nelja faasi: analüüs, projekteerimine, arendus, stabiliseerimine, see on iteratiivne ja hõlmab objektorienteeritud modelleerimise kasutamist. MSF on RUP-iga võrreldes rohkem keskendunud ärirakenduste arendamisele.
Extreme Programming (XP). Ekstreemprogrammeerimine (vaatluse all olevatest metoodikatest uusim) moodustati 1996. aastal. Metoodika põhineb meeskonnatööl, efektiivsel suhtlusel tellija ja töövõtja vahel kogu IP arendusprojekti vältel ning arendus toimub kasutades järjepidevat kõrgelt viimistletud prototüübid.
2. Elutsükli mudelid
IS-i elutsükli mudel on struktuur, mis määratleb protsesside, toimingute ja ülesannete vahelised toimingud ja seosed kogu elutsükli jooksul. Elutsükli mudel sõltub projekti spetsiifikast, ulatusest ja keerukusest ning konkreetsetest tingimustest, milles süsteem luuakse ja töötab.
IS elutsükli mudel sisaldab:
töö tulemused igas etapis;
võtmesündmused - tööde lõpetamise ja otsustamise punktid.
Elutsükli mudel kajastab süsteemi erinevaid olekuid, alustades hetkest, mil tekib vajadus antud IS järele ja lõpetades selle täieliku vananemise hetkega.
2.1 IS elutsükli mudelite tüübid
Praegu on teada ja kasutusel järgmised elutsükli mudelid:
Kaskaadmudel (joonis 2.1) näeb ette projekti kõigi etappide järjestikuse rakendamise rangelt fikseeritud järjekorras. Üleminek järgmisele etapile tähendab töö täielikku lõpetamist eelmises etapis.
Lavastatud mudel vahepealse juhtimisega (joon. 2.2). IS-i arendus toimub iteratsioonidena koos etappidevahelise tagasisideahelaga. Etappidevahelised kohandused võimaldavad arvestada arendustulemuste tegelikku vastastikust mõju erinevatel etappidel; Iga etapi eluiga ulatub üle kogu arendusperioodi.
Spiraalmudel (joon. 2.3). Igal spiraali pöördel luuakse toote järgmine versioon, täpsustatakse projekti nõuded, määratakse selle kvaliteet ja planeeritakse järgmise pöörde tööd. Erilist tähelepanu pööratakse arenduse algfaasidele - analüüsile ja projekteerimisele, kus teatud tehniliste lahenduste teostatavust testitakse ja põhjendatakse prototüüpide (paigutus) loomise kaudu.
Riis. 2.1. IS elutsükli kaskaadmudel
Riis. 2.2. Vahejuhtimisega astmeline mudel
Riis. 2.3. IS elutsükli spiraalmudel
Praktikas kasutatakse kõige laialdasemalt kahte peamist elutsükli mudelit:
kaskaadmudel (tüüpiline perioodil 1970–1985);
spiraalmudel (tüüpiline perioodile pärast 1986. aastat).
2.2 IP elutsükli mudelite eelised ja puudused
Varasemates üsna lihtsa IS-i projektides oli iga rakendus üks funktsionaalselt ja informatsiooniliselt sõltumatu plokk. Seda tüüpi rakenduste väljatöötamisel on kaskaadmeetod osutunud tõhusaks. Iga etapp viidi lõpule pärast kõigi vajalike tööde täielikku lõpetamist ja dokumenteerimist.
Eristada saab järgmist positiivseid külgi kaskaadmeetodi rakendamine:
igas etapis koostatakse täielik projektdokumentatsiooni komplekt, mis vastab täielikkuse ja järjepidevuse kriteeriumidele;
loogilises järjestuses teostatavad tööde etapid võimaldavad planeerida kõigi tööde valmimise aega ja vastavaid kulusid.
Kaskaadlähenemine on end hästi tõestanud suhteliselt lihtsate integraallülituste ehitamisel, kui juba arenduse alguses on võimalik üsna täpselt ja täielikult sõnastada kõik süsteemile esitatavad nõuded. Selle lähenemisviisi peamiseks puuduseks on see, et tegelik süsteemi loomise protsess ei mahu kunagi täielikult nii jäigasse skeemi, pidevalt on vaja naasta eelmiste etappide juurde ja varem täpsustada või üle vaadata. tehtud otsused. Selle tulemusena osutub tegelik IS-i loomise protsess vastavaks vahepealse juhtimisega etapiviisilisele mudelile.
Nende probleemide lahendamiseks pakuti välja spiraalne elutsükli mudel. Analüüsi ja projekteerimise etapis kontrollitakse prototüüpide loomisega tehniliste lahenduste teostatavust ja kliendi vajaduste rahuldamise taset. Iga spiraali pööre vastab toimiva fragmendi või süsteemi versiooni loomisele. See võimaldab teil teha selgeks projekti nõuded, eesmärgid ja omadused, määrata arenduse kvaliteedi ja planeerida spiraali järgmise pöörde tööd. Nii süvendatakse ja järjepidevalt täpsustatakse projekti detaile ning selle tulemusena valitakse välja mõistlik ja kliendi tegelikke nõudmisi rahuldav variant, mis viiakse ellu.
Spiraaltsükli põhiprobleemiks on järgmisse etappi ülemineku hetke kindlaksmääramine. Selle probleemi lahendamiseks kehtestatakse elutsükli iga etapi jaoks ajalised piirangud ja üleminek toimub vastavalt plaanile, isegi kui kõik kavandatud tööd ei ole lõpetatud. Planeerimine toimub varasemates projektides saadud statistiliste andmete alusel ja isiklik kogemus arendajad.
Vaatamata IC disaini- ja arendusekspertide tugevatele soovitustele kasutavad paljud ettevõtted iteratiivse mudeli mõne variatsiooni asemel juga mudelit. Peamised põhjused, miks juga mudel on endiselt populaarne, on järgmised:
Harjumus – paljud IT-spetsialistid said hariduse ajal, mil õpetati ainult kose mudelit, mistõttu nad kasutavad seda ka tänapäeval.
Illusioon projektis osalejate (tellija ja töövõtja) riskide vähendamisest. Kaskaadmudel hõlmab valmistoodete väljatöötamist igas etapis: tehnilised kirjeldused, tehniline projekt, tarkvaratoode ja kasutajadokumentatsioon. Väljatöötatud dokumentatsioon võimaldab mitte ainult määrata järgmise etapi tootele esitatavaid nõudeid, vaid määrata ka osapoolte kohustused, tööde mahu ja tähtajad, kusjuures lõplik hinnang projekti ajastusele ja maksumusele tehakse kl. esialgsed etapid, pärast eksami lõpetamist. Ilmselgelt kui projekti elluviimise käigus muutuvad nõuded infosüsteemile ja dokumentide kvaliteet osutub madalaks (nõuded on puudulikud ja/või vastuolulised), siis tegelikkuses tekitab kose mudeli kasutamine ainult kindluse illusiooni ja tegelikult suurendab riske, vähendades vaid projektis osalejate vastutust.
Rakendusprobleemid iteratiivse mudeli kasutamisel. Mõnes valdkonnas ei saa spiraalmudelit kasutada, kuna pole võimalik kasutada/testida toodet, mille funktsionaalsus on puudulik (näiteks sõjaline arendus, tuumaenergia jne). Äriinfosüsteemi etapiviisiline iteratiivne juurutamine on võimalik, kuid on seotud organisatsiooniliste raskustega (andmeedastus, süsteemide integreerimine, äriprotsesside muudatused, arvestuspoliitikad, kasutajakoolitus). Tööjõukulud etapiviisilise iteratiivse rakendamise ajal osutuvad palju suuremaks ja projektijuhtimine nõuab tõelist kunsti. Neid raskusi ennetades valivad kliendid kose mudeli, et "süsteemi üks kord rakendada".
Protsessi määratletakse kui omavahel seotud tegevuste kogumit, mis muudab sisendid väljunditeks. Iga protsessi kirjeldus sisaldab lahendatavate ülesannete loetelu, sisendandmeid ja tulemusi.
Vastavalt rahvusvahelisele põhistandardile ISO/IEC 12207 on kõik tarkvara elutsükli protsessid jagatud kolme rühma:
3.1 Põhilised elutsükli protsessid
Omandamine (IP-d ostva kliendi toimingud ja ülesanded)
Tarne (tarnija tegevused ja ülesanded, kes tarnib kliendile tarkvaratoote või -teenuse)
Arendus (arendaja toimingud ja ülesanded: tarkvara loomine, projekteerimis- ja töödokumentatsiooni koostamine, test- ja koolitusmaterjalide koostamine jne)
Töötamine (operaatori – süsteemi haldava organisatsiooni tegevused ja ülesanded)
Hooldus (saatva organisatsiooni ehk tugiteenistuse toimingud ja ülesanded). Tugi – tarkvara muudatuste tegemine vigade parandamiseks, tootlikkuse parandamiseks või muutunud töötingimuste või -nõuetega kohanemiseks.
Peamiste elutsükli protsesside hulgas on kõige olulisemad kolm: arendus, käitamine ja hooldus. Iga protsessi iseloomustavad teatud ülesanded ja nende lahendamise meetodid, eelmises etapis saadud lähteandmed ja tulemused.
Areng
Infosüsteemi arendamine hõlmab kogu tööd infotarkvara ja selle komponentide loomisel vastavalt kindlaksmääratud nõuetele. Infotarkvara arendus hõlmab ka:
projekteerimis- ja kasutusdokumentatsiooni koostamine;
arendatud tarkvaratoodete testimiseks vajalike materjalide ettevalmistamine;
personali väljaõppeks vajalike materjalide väljatöötamine.
Arendus on infosüsteemi elutsükli üks olulisemaid protsesse ning hõlmab reeglina strateegilist planeerimist, analüüsi, disaini ja elluviimist (programmeerimist).
Ärakasutamine
Operatiivtöö võib jagada ettevalmistavaks ja põhiliseks. Ettevalmistavad hõlmavad järgmist:
andmebaasi ja kasutaja tööjaamade seadistamine;
kasutajatele tegevusdokumentatsiooni pakkumine;
koolitust.
Peamised operatiivtegevused hõlmavad järgmist:
otsene toimimine;
probleemide lokaliseerimine ja nende esinemise põhjuste kõrvaldamine;
tarkvara muutmine;
ettepanekute koostamine süsteemi parendamiseks;
süsteemi arendamine ja kaasajastamine.
Saatja
Tehnilised tugiteenused mängivad iga ettevõtte infosüsteemi elus väga olulist rolli. Kvalifitseeritud tehnilise teeninduse olemasolu infosüsteemi tööetapis on vajalik tingimus talle pandud ülesannete lahendamine ja hoolduspersonali vead võivad kaasa tuua ilmseid või varjatud rahalisi kaotusi, mis on võrreldavad infosüsteemi enda maksumusega.
Peamised eeltoimingud infosüsteemi hoolduse korraldamise ettevalmistamisel on:
süsteemi kõige kriitilisemate komponentide tuvastamine ja nende jaoks seisakuaja kriitilisuse määramine (see võimaldab tuvastada infosüsteemi kõige kriitilisemad komponendid ja optimeerida hoolduseks ressursside jaotust);
hooldusülesannete väljaselgitamine ja nende jaotus sisemisteks, mida lahendab teenindusosakond, ja välisteks, mida lahendavad spetsialiseerunud teenindusorganisatsioonid (seega on selgelt määratletud täidetavate funktsioonide ring ja vastutuse jaotus);
kirjeldatud ülesannete ja pädevusjaotuse raames hoolduse korraldamiseks vajalike olemasolevate sisemiste ja väliste ressursside analüüsi läbiviimine (analüüsi peamised kriteeriumid: seadmete garantii olemasolu, remondifondi seisukord, personali kvalifikatsioon);
hoolduse korraldamise plaani koostamine, milles on vaja määrata tehtavate toimingute etapid, nende teostamise ajastus, etappide kulud, teostajate vastutus.
3.2 Olelusringi protsesside toetamine
Dokumentatsioon (IS elutsükli jooksul loodud teabe vormistatud kirjeldus)
Konfiguratsioonihaldus (haldus- ja tehniliste protseduuride rakendamine kogu IS-i elutsükli jooksul IS-i komponentide oleku määramiseks ja selle muudatuste haldamiseks).
Kvaliteedi tagamine (garantii andmine, et infosüsteem ja selle olelusringi protsessid vastavad kindlaksmääratud nõuetele ja kinnitatud plaanidele)
Kontrollimine (määramine, kas mõne toimingu tulemusel saadud tarkvaratooted vastavad täielikult eelmiste toimingute poolt kehtestatud nõuetele või tingimustele)
Sertifitseerimine (määratud nõuete ja loodud süsteemi vastavuse täielikkuse kindlaksmääramine nende konkreetsele funktsionaalsele otstarbele)
Ühine hindamine (projekti töö seisu hindamine: ressursside, personali, seadmete, tööriistade planeerimise ja juhtimise kontroll)
Audit (nõuetele, plaanidele ja lepingutingimustele vastavuse kindlakstegemine)
Probleemide lahendamine (arendus-, töö-, hooldus- või muude protsesside käigus avastatud probleemide analüüs ja lahendamine, sõltumata nende päritolust või allikast)
3.3 Organisatsiooniprotsessid
Juhtimine (toimingud ja ülesanded, mida saab teha iga oma protsesse haldav osapool)
Infrastruktuuri loomine (tehnoloogia, standardite ja tööriistade valik ja hooldus, tarkvara arendamiseks, käitamiseks või hooldamiseks kasutatava riist- ja tarkvara valik ja paigaldamine)
Täiustamine (elutsükli protsesside hindamine, mõõtmine, kontroll ja täiustamine)
Koolitus (esialgne koolitus ja sellele järgnev pidev personali arendamine)
Projektijuhtimine on seotud töö planeerimise ja korraldamise, arendusmeeskondade loomise ning teostatavate tööde ajastuse ja kvaliteedi jälgimise küsimustega. Tehniline ja organisatsiooniline tugi projektile hõlmab järgmist:
meetodite ja vahendite valik projekti elluviimiseks;
vahepealsete arenguseisundite kirjeldamise meetodite määramine;
meetodite ja vahendite väljatöötamine loodud tarkvara testimiseks;
1. Izbachkov S.Yu., Petrov V.N. Infosüsteemid – Peterburi: Peter, 2008. – 655 lk.
2. http://ru.wikipedia.org
3. http://www.intuit.ru