Elemente mbështetëse standarde IEEE 90. Proceset e ciklit jetësor të softuerit. Përshkrimi i sinjalit për korrektësinë e të dhënave të transmetuara

Në fushën e TI-së, standardet më praktike publikohen nga organizatat e mëposhtme:

• Instituti i Inxhinierëve Elektrikë dhe Elektronikë(IEEE, www.ieee.org) ka qenë një organizatë udhëheqëse shkencore dhe teknike për shumë vite, duke përfshirë krijimin e standardeve të dokumentacionit software. Shumica e standardeve zhvillohen nga komitete të ndryshme të përbëra nga inxhinierë profesionistë me përvojë dhe përgjegjës. Disa nga standardet IEEE janë bërë gjithashtu standarde ANSI (Instituti Kombëtar Amerikan i Standardeve). Kryesisht standardet IEEE formuan bazën për përgatitjen e MU për CP. Schmidt M. Implementimi i Standardeve të Inxhinierisë Softuerike IEEE.
• Organizata ndërkombëtare mbi standardizimin (ISO) ka ndikim të madh në mbarë botën, veçanërisht në mesin e organizatave prodhuese që merren me Bashkimin Evropian (BE). Aktualisht, pothuajse të gjitha standardet moderne të TI-së të përkthyera dhe të miratuara në Federatën Ruse janë standarde të përgatitura nga ISO së bashku me Komisionin Ndërkombëtar Elektroteknik - IEC. Ju e dini se vëmendje e veçantë i kushtohet sigurimit të cilësisë së produktit në nivel ndërkombëtar, prandaj, sipas Dekretit të Qeverisë së Federatës Ruse nr. 113, datë 02.02.1998, respektimi i kërkesave të ISO 9000 (një seri standardesh që rregullojnë menaxhimin e cilësisë (menaxhimi i cilësisë) në ndërmarrje) - kusht i kërkuar për të marrë urdhra nga qeveria.
• Instituti i Teknologjive të Inxhinierisë Softuerike(Instituti i Inxhinierisë së Softuerit - SEI, sei.cmu.edu - më shumë se 1000 artikuj) u krijua nga Departamenti i Mbrojtjes i SHBA në Universitetin Carnegie Mellon për të ngritur nivelin e teknologjisë së softuerit midis kontraktorëve të Departamentit të Mbrojtjes. Puna e SEI është miratuar gjithashtu nga shumë kompani tregtare të cilat e konsiderojnë përmirësimin e procesit të zhvillimit të softuerit një qëllim strategjik. detyrë korporative. Ne do të shohim një nga standardet e zhvilluara nga SEI të quajtur Modeli i Maturitetit të Kapacitetit (CMM).
• Konsorciumi i Teknologjisë së Manipulimit të Objekteve(Object Management Group, www.omg.org) është organizatë jo fitimprurëse, e cila ka si anëtarë rreth 700 kompani. OMG vendos standarde për llogaritjen e shpërndarë të orientuar nga objekti. Duhet të theksohet se OMG përdor gjuhën e unifikuar të modelimit UML si standardin e saj për përshkrimin e projekteve. Ne do të studiojmë UML në detaje, sepse... Përdorimi i kësaj gjuhe në lidhje me procesin e unifikuar nga Rational është baza për zhvillimin e thelbit të projektit të kursit.

Koncepti i ciklit jetësor të sistemit

Nevoja për standardizimin e zhvillimit të softuerit është përshkruar më së miri në prezantimin e standardit GOST R ISO/IEC 12207-99 " Teknologjia e informacionit. Proceset cikli i jetes software» : “Softueri është pjesë përbërëse e teknologjisë së informacionit dhe sistemeve tradicionale si transporti, ushtarak, mjekësor dhe financiar. Ekzistojnë shumë standarde, procedura, metoda, vegla dhe lloje të ndryshme të mjediseve operative për zhvillimin dhe menaxhimin e softuerit. Ky diversitet krijon sfida në hartimin dhe menaxhimin e softuerit, veçanërisht kur kombinohen produktet dhe shërbimet softuerike. Strategjia e zhvillimit të softuerit kërkon kalimin nga kjo mori në një rend të përbashkët që do t'i lejojë praktikuesit e softuerit të "flasin të njëjtën gjuhë" kur zhvillojnë dhe menaxhojnë softuer. Ky standard ndërkombëtar siguron atë rend të përgjithshëm.”

Standardi GOST R ISO/IEC 12207-99 përcakton konceptin bazë të një sistemi softuer - “cikli i jetës” (GOST R ISO/IEC TO 15271-2002 “Teknologjia e informacionit. Udhëzime për aplikimin e GOST R ISO/IEC 12207”).

GOST R ISO/IEC 12207-99 prezanton konceptin e një modeli të ciklit jetësor si një strukturë e përbërë nga procese që mbulon jetën e një sistemi që nga vendosja e kërkesave për të deri në fund të përdorimit të tij. Propozohet të korrigjohet ky përkufizim dhe të ndahet në dy përkufizime:

1. cikli i jetes– një grup procesesh të ndara në punë dhe detyra, duke përfshirë zhvillimin, funksionimin dhe mirëmbajtjen produkt software, që mbulon jetëgjatësinë e një sistemi nga vendosja e kërkesave për të deri në fund të përdorimit të tij.
2. modeli i ciklit jetësor– një strukturë që përcakton sekuencën e proceseve, punëve dhe detyrave të kryera gjatë ciklit jetësor të një sistemi softuerik, si dhe marrëdhëniet ndërmjet tyre.

Proceset e ciklit jetësor ndahen në tre grupe: kryesore, ndihmëse dhe organizative.

Grupi i proceseve kryesore përfshin: blerjen, furnizimin, zhvillimin, funksionimin dhe mbështetjen. Proceset kryesore të ciklit jetësor zbatohen nën kontrollin e palëve kryesore të përfshira në ciklin jetësor të softuerit. Pala kryesore është një nga ato organizata që inicon ose kryen zhvillimin, funksionimin ose mirëmbajtjen e produkteve softuerike. Palët kryesore janë klienti, furnizuesi, zhvilluesi, operatori dhe personeli mbështetës i softuerit.

Figura - Proceset kryesore të ciklit jetësor të IS

Grupi i proceseve ndihmëse përfshin procese që sigurojnë ekzekutimin e proceseve kryesore:

• dokumentacion;
• menaxhimi i konfigurimit;
• sigurimi i cilësisë;
• verifikimi;
• certifikim;
• gradë;
• auditimi;
• zgjidhjen e problemeve.

Grupi proceset organizative përfshin proceset:

• menaxhimi i projektit;
• krijimi i infrastrukturës së projektit;
• përcaktimin, vlerësimin dhe përmirësimin e vetë ciklit jetësor;
• arsimimi.

Në tekstin e GOST 12207-99 Puna e përfshirë në proceset kryesore, ndihmëse dhe organizative karakterizohet shumë në përgjithësi, në fakt, përshkruhen vetëm drejtimet e tyre, prandaj, për të filluar hartimin, do të nevojiten standarde dhe literaturë shtesë që zbulojnë përmbajtjen e secilit. proces të veçantë ose, më mirë akoma, një vepër më vete.
Nga grupi i proceseve kryesore, procesi i zhvillimit është me interes më të madh.
Duhet të theksohet se GOST 34.601-90 " Sisteme të automatizuara. Fazat e krijimit" procesi i krijimit të një sistemi të automatizuar ndahet në fazat e mëposhtme:

• formimi i kërkesave për folësit,
• zhvillimi i konceptit të AC,
• detyrë teknike,
• projekti paraprak,
• projekt teknik,
• dokumentacionin e punës,
• vënia në punë,
• shoqërim.

Fazat ndahen në faza, përmbajtja e të cilave përputhet me përmbajtjen e një numri detyrash të përshkruara në GOST 12207-99.

Procesi i zhvillimit

procesi i zhvillimit parashikon veprimet dhe detyrat e kryera nga zhvilluesi, dhe mbulon punën për krijimin e softuerit dhe komponentëve të tij në përputhje me kërkesat e specifikuara, duke përfshirë përgatitjen e projektimit dhe dokumentacionit operacional; përgatitja e materialeve të nevojshme për testimin e performancës dhe cilësisë së duhur të produkteve softuerike, materialeve të nevojshme për organizimin e trajnimit të personelit, etj.

Figura - Struktura e procesit të zhvillimit

Punë përgatitore

fillon me zgjedhjen e një modeli të ciklit jetësor të PS që korrespondon me shkallën, rëndësinë dhe kompleksitetin e projektit. Aktivitetet dhe detyrat e procesit të zhvillimit duhet të korrespondojnë me modelin e zgjedhur. Zhvilluesi duhet të zgjedhë, të përshtatet me kushtet e projektit dhe të përdorë standardet, metodat dhe mjetet e zhvillimit të dakorduara me klientin, si dhe të hartojë një plan ekzekutimi të punës.

Analiza e kërkesave

Analiza e kërkesave të softuerit përfshin përcaktimin e karakteristikave të mëposhtme për secilin komponent të softuerit:

• funksionalitetin, duke përfshirë karakteristikat e performancës dhe mjedisin e funksionimit të komponentit;
• ndërfaqet e jashtme;
• specifikimet e besueshmërisë dhe sigurisë;
• kërkesat ergonomike;
• kërkesat për të dhënat e përdorura;
• kërkesat e instalimit dhe pranimit;
• kërkesat për dokumentacionin e përdoruesit;
• kërkesat për funksionim dhe mirëmbajtje.

Dizajni i arkitekturës

sistemi në një nivel të lartë është të përcaktojë komponentët e pajisjeve të tij, softuerin dhe operacionet e kryera nga personeli që operon sistemin. Arkitektura e sistemit duhet të jetë në përputhje me kërkesat e sistemit dhe standardet dhe praktikat e pranuara të projektimit.
Dizajnimi i një arkitekture softueri përfshin detyrat e mëposhtme (për secilin komponent të softuerit):

• transformimi i kërkesave për softuerin në një arkitekturë që përcakton në një nivel të lartë strukturën e softuerit dhe përbërjen e komponentëve të tij;
• zhvillimin dhe dokumentimin e ndërfaqeve softuerike për sistemet softuerike dhe bazat e të dhënave;
• zhvillimi i një versioni paraprak të dokumentacionit të përdoruesit;
• zhvillimin dhe dokumentimin e kërkesave të testimit paraprak dhe një plan integrimi softuerësh.

Dizajn i detajuar

PS përfshin detyrat e mëposhtme:

• përshkrimin e komponentëve të softuerit dhe ndërfaqeve ndërmjet tyre në një nivel më të ulët, të mjaftueshëm për kodimin dhe testimin e mëvonshëm të pavarur;
• zhvillimin dhe dokumentimin e një dizajni të detajuar të bazës së të dhënave;
• zhvillimin dhe dokumentimin e kërkesave të testimit dhe një plan testimi për komponentët e softuerit;

Kodimi dhe testimi

PS mbulon detyrat e mëposhtme:

• zhvillimin (kodimin) dhe dokumentimin e çdo komponenti softueri dhe bazën e të dhënave, si dhe një grup procedurash testimi dhe të dhënash për testimin e tyre;
• testimi i çdo komponenti të softuerit dhe bazës së të dhënave për pajtueshmërinë me kërkesat për to. Rezultatet e testimit të komponentëve duhet të dokumentohen;
• përditësimi (nëse është e nevojshme) dokumentacioni i përdoruesit;
• përditësimi i planit të integrimit të PS.

Për secilin nga komponentët e grumbulluar, grupet e testimit dhe procedurat e testimit janë zhvilluar për të verifikuar secilën nga kërkesat e kualifikimit gjatë testimit të mëpasshëm të kualifikimit. Kërkesa për kualifikimështë një grup kriteresh ose kushtesh që duhet të plotësohen për të cilësuar një produkt softuer si që plotëson specifikimet e tij dhe i gatshëm për përdorim në terren.

GOST R ISO/IEC 12119-2000 “Teknologjia e informacionit. Paketat softuerike. Kërkesat e cilësisë dhe testimi" përmban udhëzime që përcaktojnë procedurën për testimin e një produkti për pajtueshmërinë me kërkesat e tij të cilësisë. Testimi është një proces intensiv i punës. Sipas disa ekspertëve, përqindja
Shpërndarja e kohës ndërmjet proceseve projektim – zhvillim – testim është në raportin 40-20-40. Në këtë drejtim, sistemet e automatizimit të testimit po bëhen të përhapura. Standardi IEEE 1209-1992, "Praktika e rekomanduar për vlerësimin dhe përzgjedhjen e mjeteve CASE", përcakton kërkesat e përgjithshme për funksionalitetin e mjeteve të automatizimit të testimit.

Integrimi i sistemit

konsiston në montimin e të gjithë përbërësve të tij, duke përfshirë nënstacionet dhe pajisjet. Pas integrimit, sistemi, nga ana tjetër, i nënshtrohet testimit të kualifikimit për pajtueshmërinë me një sërë kërkesash për të. Në të njëjtën kohë, përgatitet dhe verifikohet një grup i plotë dokumentacioni për sistemin.

Instalimi i sistemit

kryhet nga zhvilluesi në përputhje me planin në mjedis dhe mbi pajisjet e parashikuara nga kontrata. Gjatë procesit të instalimit, kontrollohet funksionaliteti i softuerit dhe bazave të të dhënave.

Pranimi i sistemit

parashikon vlerësimin e rezultateve të testimit të kualifikimit të softuerit dhe sistemit dhe dokumentimin e rezultateve të vlerësimit, të cilat kryhen nga klienti me ndihmën e zhvilluesit. Zhvilluesi kryen transferimin përfundimtar të softuerit te klienti në përputhje me kontratën, duke ofruar trajnimin dhe mbështetjen e nevojshme. Kursi ynë synon kryesisht një ekzaminim të detajuar të katër punimeve të para të procesit të zhvillimit të softuerit. Secila prej këtyre punimeve do t'i kushtohet një seksioni të veçantë, dhe tani për prezantim të mëtejshëm është e nevojshme të themi disa fjalë për modelet e ciklit jetësor të PS.

Modelet e ciklit jetësor të softuerit

Modeli i ciklit jetësor– një strukturë që përcakton sekuencën e proceseve, punëve dhe detyrave të kryera gjatë gjithë ciklit jetësor të një sistemi informacioni, si dhe marrëdhëniet ndërmjet tyre.

Deri më sot, dy modele kryesore të ciklit jetësor janë bërë më të përhapura:

• modeli i kaskadës (ujëvarës);
• model spirale.

Modeli i kaskadës

Modeli i kaskadës demonstron një qasje klasike ndaj zhvillimit sisteme të ndryshme në fusha të ndryshme aplikimi. Për zhvillim sistemet e informacionit ky model u përdor gjerësisht në vitet '70 dhe gjysmën e parë të viteve '80. Është modeli kaskadë që formon bazën e serisë GOST 34.xxx dhe standardit të Departamentit të Mbrojtjes të SHBA-së DOD-STD-2167A. Përpunon GOST 12207-99 në GOST 34.601-90 "Sistemet e automatizuara. Fazat e krijimit" quhen faza dhe ndryshojnë pak në përbërje.
Modeli kaskadë parashikon organizimin sekuencial të proceseve. Për më tepër, kalimi në procesin e ardhshëm ndodh vetëm pasi të gjitha punimet në atë të mëparshme të kenë përfunduar plotësisht. Çdo proces përfundon me lëshimin e një grupi të plotë dokumentacioni, të mjaftueshëm në mënyrë që puna të mund të vazhdojë nga një ekip tjetër zhvillimi.

Disavantazhi kryesor i modelit të kaskadës është se gabimet dhe mangësitë në çdo fazë shfaqen, si rregull, në fazat pasuese të punës, gjë që çon në nevojën për t'u kthyer prapa. Sipas informacioneve kompani konsulence Grupi Standish në vitin 1998 në SHBA, më shumë se 28% e projekteve të sistemeve të informacionit të korporatave (IT) përfunduan me dështim; pothuajse 46% e projekteve të TI-së janë përfunduar mbi buxhet (mesatarisht 189%); dhe vetëm 26% e projekteve përshtaten brenda kornizës kohore dhe buxhetit të caktuar.

Për më tepër, disavantazhet e modelit të kaskadës përfshijnë:

• vështirësi në paralelizimin e punës;
• kompleksiteti i menaxhimit të projektit;
• niveli i lartë i rrezikut dhe investimi jo i besueshëm (kthimi në fazat e mëparshme mund të shoqërohet jo vetëm me gabime, por edhe me ndryshime që kanë ndodhur në fushën e temës ose në kërkesat e klientëve gjatë zhvillimit. Për më tepër, kthimi i projektit për rishikim për këto arsye nuk garanton që fusha e temës nuk do të ndryshojë më në kohën kur versioni tjetër i projektit të jetë gati.Në fakt, kjo do të thotë se ekziston mundësia që procesi i zhvillimit të "shkojë në cikle" dhe sistemi të mos arrijë kurrë në pikën e Kostot e projektit do të rriten vazhdimisht, dhe koha e dorëzimit të produktit të përfunduar vonohet vazhdimisht).

Modeli spirale

Ndryshe nga kaskada, ai përfshin një proces përsëritës të zhvillimit të një sistemi informacioni. Modeli spirale u propozua në mesin e viteve 1980 nga Barry Boehm. Çdo kthesë e spirales korrespondon me krijimin e një fragmenti ose versioni të një produkti softuer, ku qartësohen qëllimet dhe karakteristikat e projektit, përcaktohet cilësia e tij dhe planifikohet puna për kthesën e ardhshme të spirales. Në çdo përsëritje, detajet e projektit thellohen dhe specifikohen vazhdimisht, dhe mblidhen të dhëna metrike, të cilat përdoren për të optimizuar përsëritjet pasuese. Megjithatë, mekanizmat për sigurimin e integritetit të dokumentacionit bëhen më të ndërlikuara (kur një kërkesë ose përkufizim i veçantë jepet në tekst vetëm një herë), gjë që kërkon përdorimin e mjeteve speciale.
Karakteristikat kryesore të modelit spirale:

• refuzimi për të rregulluar kërkesat dhe caktimin e prioriteteve për kërkesat e përdoruesve;
• zhvillimi i një sekuence prototipash duke filluar me kërkesat me prioritet më të lartë;
• identifikimin dhe analizën e rrezikut në çdo përsëritje;
• Vlerësimi i rezultateve në fund të çdo përsëritjeje dhe planifikimi i përsëritjes tjetër.

Zhvillimi i shpejtë i aplikacioneve

Në vitet '90 të shekullit të 20-të, një teknologji praktike e quajtur "zhvillimi i shpejtë i aplikacioneve" - ​​RAD (Rapid Application Development) u themelua në bazë të modelit spirale. Në këtë rast, cikli i jetës përbëhej nga katër faza:

• analiza dhe planifikimi i kërkesave,
• dizajni,
• zbatimi,
• zbatimi.

Parimet themelore të RAD:

• zhvillimi i aplikacioneve në përsëritje;
• përfundimi opsional i punës në çdo fazë të ciklit jetësor të softuerit;
• përfshirja e detyrueshme e përdoruesve në procesin e zhvillimit;
• përdorimi i mjeteve të menaxhimit të konfigurimit që lehtësojnë ndryshimet në projekt dhe mirëmbajtjen e sistemit të përfunduar;
• përdorimi i prototipit për të kuptuar dhe plotësuar më mirë nevojat e përdoruesve;
• testimin dhe zhvillimin e projektit, të kryera njëkohësisht me zhvillimin;
• zhvillim nga një ekip i vogël dhe i mirëmenaxhuar profesionistësh;
• Menaxhimi kompetent i zhvillimit të sistemit, planifikimi i qartë dhe kontrolli i ekzekutimit të punës.

Në fillim të vitit 2001, një numër ekspertësh kryesorë në fushën e inxhinierisë softuerike (Martin Fowler, Kent Beck, etj.) formuan një grup të quajtur Aleanca Agile për të mbështetur dhe zhvilluar një qasje të re në dizajn - "zhvillimi i shpejtë i softuerit" (Agile Software Zhvillimi). Një zbatim i kësaj qasjeje është Programimi Ekstrem (XP).

Parimet e Programimit Ekstrem janë si më poshtë:

1. Ekipi përbëhet nga tre deri në dhjetë programues. Një ose më shumë klientë duhet të jenë në gjendje të ofrojnë vazhdimisht ekspertizë të vazhdueshme.
2. Programet zhvillohen në përsëritje trejavore. Çdo përsëritje prodhon kod funksional dhe të testuar që mund të përdoret menjëherë nga klientët. Sistemi i kompletuar dërgohet te përdoruesit fundorë në fund të çdo periudhe lëshimi, e cila mund të zgjasë nga dy deri në pesë përsëritje.
3. Njësia e kërkesave të softuerit të mbledhur është një "histori e përdoruesit", e shkruar në një kartë indeksi, që përshkruan funksionalitetin nga këndvështrimi i përdoruesit që mund të zhvillohet në një përsëritje të vetme. Konsumatorët dhe programuesit planifikojnë punën për përsëritjen e ardhshme në këtë mënyrë:
   • programuesit vlerësojnë kohën për të përfunduar çdo kartë;
   • klientët vendosin prioritete, i ndryshojnë dhe i rishikojnë sipas nevojës. Zhvillimi i një historie fillon me diskutimin e saj midis programuesve dhe ekspertit të klientit.
4. Programuesit punojnë në çifte dhe ndjekin standardet strikte të kodimit që ata vendosin në fillim të projektit. Ata krijojnë teste njësi për gjithçka që shkruajnë dhe sigurojnë që ato teste të ekzekutohen sa herë që kodi i nënshtrohet kontrollit të detyrueshëm të versionit dhe menaxhimit të konfigurimit.
5. Ndërsa programuesit punojnë, klientët vizitojnë programuesit për të sqaruar idetë, shkruajnë testet e pranimit të sistemit për t'u ekzekutuar gjatë përsëritjes dhe në fund të përsëritjes zgjedhin histori për t'i zbatuar në përsëritjen tjetër.
6. Çdo ditë, ekipi mban takime operacionale ku programuesit flasin për atë që po punojnë, çfarë po shkon mirë dhe çfarë ka nevojë për ndihmë. Në fund të çdo përsëritjeje, ka një takim tjetër ku ata vlerësojnë se çfarë shkoi mirë dhe çfarë duhet të punohet herën tjetër. Kjo listë është postuar që të gjithë ta shohin ndërsa punojnë në përsëritjen tjetër.
7. Një person në ekip caktohet si "mentor". Së bashku me anëtarët e ekipit, ai vlerëson përdorimin e tyre të teknikave bazë: programimin dhe testimin e çifteve, rrotullimin e çifteve, mbajtjen e zgjidhjeve të projektimit të thjeshta, komunikimin, etj. me qëllim të përmirësimit të vazhdueshëm të procesit të zhvillimit.

Qasja e zhvillimit të shpejtë të softuerit nuk është universale dhe është e zbatueshme vetëm për projektet e një klase të caktuar. Për të karakterizuar projekte të tilla, Alistair Coburn prezantoi dy parametra - kritikitetin dhe shkallën.
Kriticiteti përcaktohet nga pasojat e shkaktuara nga defektet në softuer dhe mund të ketë një nga katër nivelet:

• C – defektet shkaktojnë humbje të komoditetit;
• D – defektet shkaktojnë humbje të fondeve të rikuperueshme (materiale ose financiare);
• E – defektet shkaktojnë humbje të fondeve të pazëvendësueshme;
• L - defektet paraqesin një kërcënim për jetën e njeriut.

Shkalla përcaktohet nga numri i zhvilluesve që marrin pjesë në projekt:

• nga 1 deri në 6 persona - në shkallë të vogël;
• nga 6 deri në 20 persona - në shkallë të mesme;
• mbi 20 persona - në shkallë të gjerë.

Sipas Coburn, zhvillimi i shpejtë i softuerit është i zbatueshëm vetëm për projektet e vogla dhe të mesme me kriticitet të ulët (C ose D). Kjo do të thotë se teknologjitë RAD dhe XP janë më të përshtatshmet për projekte relativisht të vogla të zhvilluara për një klient specifik dhe nuk janë të zbatueshme për ndërtimin e programeve komplekse llogaritëse, sistemeve operative ose programeve për menaxhimin e objekteve komplekse në kohë reale, si dhe sistemet nga të cilat varet siguria. të njerëzve.

Procesi i unifikuar i zhvillimit të softuerit

Aktualisht, puna vazhdon për të krijuar një lloj procesi universal të zhvillimit të IS. Në vitin 1999 Punonjësit Racional, Ivar Jacobson, Gradi Booch dhe James Rumbaugh botuan librin Unified Software Development Process, i cili u përkthye në Rusisht dhe u botua nga shtëpia botuese Peter në 2002. Procesi i Unifikuar është një përpjekje për të kombinuar modele ujëvare dhe përsëritëse J C.

Në të njëjtën kohë, cikli i jetës ndahet në 4 faza:

1. Fillimi: kryhet një vlerësim fillestar i projektit.
   • është krijuar një model i thjeshtuar i rasteve të përdorimit që përmban rastet më kritike të përdorimit nga pikëpamja e zbatimit;
   • krijohet një version provë i arkitekturës që përmban nënsistemet më të rëndësishme;
   • identifikohen dhe prioritizohen rreziqet;
   • është planifikuar faza e projektimit;
   • i gjithë projekti në tërësi vlerësohet përafërsisht;
2. sqarim (përpunim): shumica e rasteve të përdorimit përshkruhen në detaje dhe zhvillohet arkitektura e sistemit. Në fund të fazës së projektimit, menaxheri i projektit llogarit burimet e nevojshme për të përfunduar projektin. Është e nevojshme t'i përgjigjemi pyetjes: a janë mjaftueshëm të zhvilluara rastet e përdorimit, arkitektura dhe plani në mënyrë që të mundësohet dhënia e detyrimeve kontraktuale për kryerjen e punës dhe vazhdimi i përgatitjes dhe nënshkrimit të “Specifikimeve Teknike”?;
3. ndërtimi– krijimi i produktit. Në fund të kësaj faze, produkti përfshin të gjitha rastet e përdorimit që zhvilluesit dhe klienti vendosën të përfshijnë në versionin aktual;
4. zbatimi (tranzicioni)– lëshimi i produktit. Versioni beta i produktit testohet nga departamenti i testimit të kompanisë dhe në të njëjtën kohë organizohet funksionimi provë i sistemit nga përdoruesit. Zhvilluesit më pas rregullojnë çdo gabim që gjejnë dhe përfshijnë disa nga përmirësimet e sugjeruara në një version të madh që është gati për shpërndarje të gjerë.

Çdo fazë USDP mund të përfshijë një ose më shumë përsëritje, në varësi të madhësisë së projektit. Gjatë çdo përsëritjeje, mund të ekzekutohen 5 thread-e kryesore dhe një numër punëtor shtesë.
Rrjedhat kryesore të punës në USDP përfshijnë:

• përcaktimi i kërkesave (RD);
• analiza (A);
• dizajni (P);
• zbatimi (P);
• testimi (T).

Temat shtesë të punës mund të përfshijnë:

• punë për sigurimin e cilësisë (K),
• dokumentacioni (D),
• menaxhimi i projektit (P),
• menaxhimi i konfigurimit (CM),
• krijimi dhe menaxhimi i infrastrukturës (I)
• dhe të tjerët.

Figura - Modeli i ciklit jetësor sipas procesit të unifikuar të zhvillimit të softuerit

Zgjedhja e modelit të ciklit jetësor varet kryesisht nga lloji dhe shkalla e sistemit që po zhvillohet. Për zhvillimin e shumicës së sistemeve të kontrollit të automatizuar me kohë të lirë, është i zbatueshëm modeli i ciklit jetësor iterativ, ndërsa modeli i ujëvarës është më i përshtatshëm për sistemet në kohë reale. Gjatë leksioneve, kur studiojmë çështjet e dizajnit të IS, do t'i kushtojmë vëmendje të veçantë përdorimit të Gjuhës së Unifikuar të Modelimit (UML), dhe duke qenë se krijuesit e saj janë Grady Booch dhe James Rumbaugh, do t'i drejtohemi edhe ideologjisë së Procesit të Unifikuar të Zhvillimit.

vizatim - Rregulloret, që shoqëron procesin e zhvillimit

Mbështetja e proceseve të ciklit jetësor

Procesi i Sigurimit të Cilësisë

Procesi i sigurimit të cilësisë jep garancitë e duhura që sistemi i softuerit dhe proceset e ciklit të tij jetësor përputhen me kërkesat e specifikuara dhe planet e miratuara. Cilësia e softuerit kuptohet si një grup karakteristikash që karakterizojnë aftësinë e softuerit për të përmbushur kërkesat e specifikuara.

Figura - Struktura e proceseve të ciklit jetësor ndihmës

Në kontekstin e GOST R ISO/IEC 9126-93. “Teknologjia e informacionit. Vlerësimi i produkteve softuerike. Karakteristikat e cilësisë dhe udhëzimet për përdorimin e tyre "Karakteristika e cilësisë" kuptohet si "një grup i vetive (atributeve) të një produkti softuer me të cilin përshkruhet dhe vlerësohet cilësia e tij".

Standardi përcakton gjashtë karakteristika gjithëpërfshirëse që përshkruajnë cilësinë e softuerit me dyfishim minimal:

• funksionalitetin– një grup atributesh që lidhen me thelbin e grupit të funksioneve dhe vetitë e tyre specifike. Funksionet janë ato që realizojnë nevojat e deklaruara ose të parashikuara;
• besueshmëria– një grup atributesh që lidhen me aftësinë e softuerit për të ruajtur nivelin e tij të performancës në kushte të caktuara për një periudhë të caktuar kohore;
• praktike– një grup atributesh që lidhen me fushën e punës së kërkuar për përdorim dhe vlerësimin individual të një përdorimi të tillë nga një gamë e caktuar ose e synuar përdoruesish;
• efikasiteti– një grup atributesh që lidhen me marrëdhënien midis nivelit të cilësisë së funksionimit të softuerit dhe sasisë së burimeve të përdorura në kushte të caktuara
• mirëmbajtjen– një grup atributesh që lidhen me fushën e punës së kërkuar për të kryer ndryshime (modifikime) specifike;
• lëvizshmërisë– një grup atributesh që lidhen me aftësinë e softuerit për t'u transferuar nga një mjedis në tjetrin.

GOST 28195-89 "Vlerësimi i cilësisë së softuerit. Dispozitat e përgjithshme» në krye, së pari, niveli, ai identifikon 6 tregues - faktorë të cilësisë: besueshmërinë, korrektësinë, lehtësinë e përdorimit, efikasitetin, shkathtësinë dhe mirëmbajtjen. Këta faktorë detajohen kolektivisht nga 19 kritere të cilësisë në nivelin e dytë. Detajimi i mëtejshëm i treguesve të cilësisë përfaqësohet nga metrikë dhe elementë vlerësimi, prej të cilëve janë rreth 240. Secili prej tyre rekomandohet të vlerësohet me ekspertizë duke filluar nga 0 në 1. Propozohet të zgjidhet përbërja e faktorëve, kritereve dhe matjeve të përdorura. në varësi të qëllimit, funksioneve dhe fazave të ciklit jetësor të softuerit.

Standardi GOST 28806-90 "Cilësia e softuerit. Termat dhe përkufizimet" janë zyrtarizuar konceptet e përgjithshme programet, mjetet softuerike, produktet softuerike dhe cilësia e tyre. Janë dhënë përkufizimet e 18 termave më të përdorur që lidhen me vlerësimin e karakteristikave të programit. Konceptet e treguesve bazë të cilësisë të dhëna në GOST 28195-89 janë sqaruar.
Çështja e sigurimit të cilësisë së PS kërkon vëmendje të veçantë, pasi sipas Dekretit të Qeverisë Ruse nr. 113, datë 02.02.1998, respektimi i kërkesave të standardit ndërkombëtar të sigurimit të cilësisë dhe menaxhimit ISO 9000 është një parakusht për marrjen e një urdhri qeveritar.
Aktiv skenë moderne Nuk mjafton të kesh vetëm metoda për vlerësimin e cilësisë së softuerit të prodhuar dhe të përdorur (kontrolli i prodhimit); është e nevojshme të jesh në gjendje të planifikosh cilësinë, ta matësh atë në të gjitha fazat e ciklit jetësor të softuerit dhe të rregullosh procesin e prodhimit të softuerit në përmirësojnë cilësinë.

Seritë e standardeve ISO 9000 janë shumë të përgjithshme. Çdo kompani që prodhon softuer dhe dëshiron të zbatojë një sistem efektiv të menaxhimit të cilësisë bazuar në standardet e serisë ISO 9000, duhet të marrë parasysh specifikat e industrisë së saj dhe të zhvillojë një sistem treguesish të cilësisë që do të pasqyronin ndikimin real të faktorëve të cilësisë në produktin softuer. Për këtë qëllim, shumë organizata kanë krijuar një proces për sistematike të veçanta dhe kontroll i plotë– Sigurimi i cilësisë, i cili fillon me fillimin e projektit, përfshin inspektimin dhe testimin dhe në mënyrë ideale kryhet nga ndonjë organizatë e pavarur. Në realitet, më shpesh, kontrolli i cilësisë kryhet nga një grup kolegësh të autorit të veprës.
Qëllimi i inspektimit është të kontrollojë pjesë të projektit për defekte:

• dokumentacion,
• Kërkesat,
• rezultatet e analizës,
• dizajni,
• listimet etj.

Rëndësia e inspektimit tregohet duke krahasuar koston dhe zbulimin dhe korrigjimin e një defekti gjatë inspektimit dhe gjatë integrimit sipas Fagin, M., "Inspektimet e projektimit dhe kodit për të reduktuar gabimet në zhvillimin e programit", IBM Systems Journal. Disa autorë i konsiderojnë këto të dhëna si shumë të nënvlerësuara.

Çështja e gjetjes së defekteve filloi të merrej shumë më seriozisht pasi një satelit amerikan me vlerë disa miliardë dollarë, i dërguar në Venus, humbi kontrollin për shkak të një gabimi shtypi në nënprogramin e korrigjimit të trajektores - në vend të presjes u fut një pikëpresje.
Vlerësimi dhe përmirësimi i cilësisë kryhet nëpërmjet përdorimit të metrikës - karakteristikave sasiore të treguesve të caktuar të procesit.

Për të kryer një inspektim, kërkohen hapat e mëposhtëm:

1. Procesi i inspektimit fillon me planifikimin.Është duke u zhvilluar një klasifikim i defekteve sipas përshkrimit, ashpërsisë dhe llojit. Përzgjedhja e matjeve me të cilat do të kryhet inspektimi, zgjedhja e mjeteve për mbledhjen dhe analizimin e të dhënave të marra, si dhe shpërndarja e roleve ndërmjet inspektorëve kryhen:
   • Drejtuesi është përgjegjës për kryerjen e duhur të inspektimit.
   • Korrektori është përgjegjës për aktivitetet e ekipit dhe i drejton ato në drejtimin e duhur. Në inspektim merr pjesë korrektori.
   • Regjistruesi është përgjegjës për regjistrimin e përshkrimit dhe klasifikimit të defekteve, siç është zakon në ekip. Në inspektim merr pjesë edhe regjistruesi.
   • Një inspektor i specializuar është një specialist në një fushë të caktuar të ngushtë të cilës i përket fragmenti i inspektuar.
2. Nëse është e nevojshme, mund të organizohet një seminar rishikimi për të kuptuar më mirë temën e inspektimit.
3. Kryerja e një inspektimi. Inspektorët kontrollojnë të gjithë punën në vendet e tyre të punës (për shembull, duke kontrolluar nëse kodi i programit të inspektuar korrespondon me dizajnin e detajuar). Inspektorët zakonisht regjistrojnë të gjitha defektet në një bazë të dhënash (p.sh. të aksesueshme nëpërmjet një rrjeti) së bashku me përshkrimet dhe klasifikimet. Pjesët e inspektuara të sistemit duhet të jenë logjikisht të plota.
4. Mbahet një takim inspektimi gjatë të cilit pjesëmarrësit paraqesin rezultatet e tyre.
5. Autori korrigjon defektet (faza e rishikimit).
6. Në takimin përfundimtar pas përfundimit të punës, korrektori dhe autori sigurohen që të gjitha defektet të jenë korrigjuar. Megjithatë, kjo nuk nënkupton një rishikim të detajuar të të gjithë veprës nga një korrektues. Të gjitha korrigjimet mbeten përgjegjësi e autorit, i cili është përgjegjës për punën e tij.
7. Ashtu si me proceset e tjera, grupi mblidhet për të diskutuar vetë procesin e inspektimit dhe për të vendosur se si mund të përmirësohet.

Kompania mban shënime për kohën e kaluar në inspektime dhe sasinë e punës së inspektuar për përdorim të mëtejshëm në vlerësimin e inspektimeve të ardhshme. Në kushtet e kufizimeve të rrepta kohore, të ashtuquajturat një sistem “tutorshipi” në të cilin çdo anëtar i ekipit mbikëqyret nga kolegu i tij.
Për të marrë parasysh të gjithë faktorët e kontrollit të cilësisë, është e përshtatshme të përdoren listat pyetjet e testit. Listat e tilla përmbajnë artikuj që duhet të kontrollohen në mënyrë sekuenciale.
Për shembull, Plani i Sigurimit të Cilësisë së Softuerit (SQAP) në përputhje me standardin IEEE 739-1989 specifikon:

• kush do të jetë përgjegjës për cilësinë - individual, menaxher, grup, organizatë etj.;
• çfarë dokumentacioni kërkohet;
• cilat metoda do të përdoren për të siguruar cilësinë - inspektimi, testimi, etj.;
• cilat aktivitete duhet të kryhen gjatë menaxhimit të procesit - takime, auditime, rishikime, etj.

Besueshmëria dhe siguria

Një nga karakteristikat më domethënëse të përfshira në konceptin e cilësisë është vetia e besueshmërisë.
Sipas përkufizimit të vendosur në GOST 13377-75 "Besueshmëria në teknologji. Termat dhe përkufizimet", besueshmëria është pronë e një objekti për të kryer funksione të specifikuara, duke ruajtur me kalimin e kohës vlerat e treguesve të vendosur operacionalë brenda kufijve të specifikuar që korrespondojnë me mënyrat dhe kushtet e specifikuara të përdorimit, mirëmbajtjes, riparimit, ruajtjes dhe transportit. Kështu, besueshmëria është një pronë e brendshme e sistemit, e natyrshme gjatë krijimit të tij dhe manifestohet me kalimin e kohës gjatë funksionimit dhe funksionimit.
Besueshmëria e funksionimit të një nënstacioni karakterizohet më gjerësisht nga qëndrueshmëria, ose aftësia për të funksionuar pa dështim, dhe rikuperimi i një gjendje operative pas dështimeve ose dështimeve.
Monitorimi i besueshmërisë dhe sigurisë së programeve të krijuara dhe të modifikuara duhet të shoqërojë të gjithë ciklin jetësor të softuerit përmes një efektiv të organizuar posaçërisht sistemi teknologjik duke siguruar cilësinë e tyre. Verifikimi dhe konfirmimi i cilësisë së softuerit kompleks dhe kritik duhet të sigurohet me certifikim nga laboratorë të çertifikuar të çertifikuar të orientuar drejt problemeve.

Standardet në terren siguria e informacionit ndarë në dy grupe:

• standardet e vlerësimit të dizajnuara për të vlerësuar dhe klasifikuar IP-në dhe mjetet e sigurisë sipas kërkesave të sigurisë - standardi i Departamentit të Mbrojtjes të SHBA-së “Kriteret për vlerësimin e besuar sistemet kompjuterike", "Kriteret e harmonizuara të vendeve evropiane", standardi ndërkombëtar "Kriteret për vlerësimin e sigurisë së teknologjive të informacionit", Dokumentet udhëzuese të Komisionit Teknik Shtetëror të Rusisë;
• specifikimet që rregullojnë aspekte të ndryshme zbatimin dhe përdorimin e mjeteve dhe teknikave të sigurisë të publikuara nga Task Forca e Inxhinierisë së Internetit (IETF) dhe nënndarjet e saj, Grupi i Punës për Sigurinë.

Standardet më të rëndësishme të vlerësimit përfshijnë:

• Komisioni Shtetëror Teknik i Rusisë. Dokument udhëzues. Pajisjet kompjuterike. Firewalls. Mbrojtje kundër aksesit të paautorizuar në informacion. Treguesit e sigurisë kundër aksesit të paautorizuar në informacion. – Moskë, 1997 – klasifikon muret e zjarrit në përputhje me nivelin e filtrimit të rrjedhës së të dhënave të modelit referencë me shtatë nivele.
• ISO/IEC 15408:1999 Kriteret për vlerësimin e sigurisë së teknologjisë së informacionit.

Grupi i dytë përfshin dokumentet e mëposhtme:

• X.800 Arkitektura e Sigurisë për Ndërveprim sistemet e hapura" Theksohen shërbimet kryesore të sigurisë së rrjetit: vërtetimi, kontrolli i aksesit, sigurimi i konfidencialitetit dhe/ose integritetit të të dhënave. Për zbatimin e shërbimeve, ofrohen mekanizmat e mëposhtëm të sigurisë së rrjetit dhe kombinimet e tyre: enkriptimi, elektronik nënshkrimi dixhital, kontrolli i aksesit, kontrolli i integritetit të të dhënave, vërtetimi, mbushja e trafikut, kontrolli i rrugëzimit, noterizimi.
• Specifikimi i Komunitetit të Internetit RFC 1510, Shërbimi i Autentifikimit të Rrjetit Kerberos (V5), trajton problemin e vërtetimit në një mjedis të shpërndarë heterogjen me mbështetje për konceptin e një hyrjeje të vetme në rrjet;
• X.500 "Shërbimet e drejtorisë: Një përmbledhje e koncepteve, modeleve dhe shërbimeve", X.509 "Shërbimet e drejtorisë: Kornizat e certifikatës" çelësat publikë dhe atributet."

Proceset e verifikimit, certifikimit dhe auditimit

Verifikimi, certifikimi dhe auditimi janë pjesë integrale IEEE 739-1989 Plani i Kontrollit të Cilësisë SQAP.
Verifikimi i përgjigjet pyetjes: "A po bëjmë atë që kemi planifikuar në këtë fazë?" Certifikimi dhe auditimi i përgjigjet pyetjes: "A i plotëson objekti në ndërtim nevojat e klientit?"
Standardi IEEE 1012-1986 i Planit të Verifikimit dhe Validimit të Softuerit (SVVP) kombinon proceset e certifikimit dhe auditimit të quajtura validim dhe përcakton se si ato kryhen.

Gjatë procesit të verifikimit, kontrollohen kushtet e mëposhtme:

• konsistenca e kërkesave për sistemin dhe shkalla në të cilën janë marrë parasysh nevojat e përdoruesve;
• aftësia e furnizuesit për të përmbushur kërkesat e specifikuara;
• pajtueshmërinë e proceseve të ciklit jetësor të PS-së së përzgjedhur me kushtet e kontratës;
• përshtatshmëria e standardeve, procedurave dhe mjedisit të zhvillimit me proceset e ciklit jetësor të SP;
• pajtueshmërinë e specifikimeve të projektimit të nënstacionit me kërkesat e specifikuara;
• korrektësia e përshkrimit në specifikimet e projektimit të të dhënave hyrëse dhe dalëse, sekuenca e ngjarjeve, ndërfaqet, logjika, etj.;
• pajtueshmëria e kodit me specifikimet dhe kërkesat e projektimit;
• testueshmëria dhe korrektësia e kodit, përputhshmëria e tij me standardet e pranuara të kodimit;
• integrimi korrekt i komponentëve të softuerit në sistem;
• përshtatshmërinë, plotësinë dhe konsistencën e dokumentacionit.

Procesi i përbashkët i shqyrtimit

Procesi i përbashkët i shqyrtimit synon të vlerësojë statusin e punës në një projekt dhe fokusohet kryesisht në monitorimin e planifikimit dhe menaxhimit të burimeve, personelit, pajisjeve dhe mjeteve të projektit.
Vlerësimi zbatohet si gjatë menaxhimit të projektit ashtu edhe gjatë zbatimit teknik të projektit dhe kryhet gjatë gjithë kohëzgjatjes së kontratës. Ky proces mund të kryhet nga çdo dy palë të përfshira në kontratë, me njëra palë që verifikon tjetrën.

Procesi i zgjidhjes së problemit

Procesi i zgjidhjes së problemit përfshin analizën dhe zgjidhjen e problemeve (përfshirë mospërputhjet e zbuluara) pavarësisht nga origjina ose burimi i tyre, të cilat zbulohen gjatë zhvillimit, funksionimit, mirëmbajtjes ose proceseve të tjera. Procesi i zgjidhjes së problemit është i lidhur ngushtë me menaxhimin e rrezikut. Faktorët që çojnë në dështimin e projektit manifestohen në formën e rreziqeve. Menaxhimi i rrezikut konsiston në identifikimin, planifikimin e eliminimit, prioritizimin, eliminimin (ose zbutjen).

Arsyet për shfaqjen e rreziqeve mund të jenë si më poshtë:

1. Formulim i paqartë dhe/ose jo i plotë i kërkesave;
2. Përfshirja e pamjaftueshme e palëve të interesuara në projekt;
3. Planifikimi i dobët - mungesa e menaxhimit kompetent të projektit;
4. Ndryshimet e shpeshta në kërkesat e shkaktuara nga ndryshimet në fushëveprimin, qëllimet e projektit dhe arsye të tjera;
5. Papërsosmëria e teknologjisë së projektimit të përdorur;
6. Mungesa e njohurive apo aftësive në mesin e interpretuesve.

Ekzistojnë dy mënyra për të parandaluar rreziqet:

1. duke bërë ndryshime në kërkesat e projektit që eliminojnë shkakun e rrezikut;
2. zhvillimin e teknologjisë, zgjidhjen e problemit lidhur me shfaqjen e rrezikut.

Gjatë procesit të menaxhimit të projektit, menaxheri duhet herë pas here të iniciojë procesin e identifikimit të rreziqeve në pjesë të ndryshme të projektit në mënyrë që të përpilojë një listë të rreziqeve që presin trajtim. Për çdo rrezik përcaktohen tre vlera: probabiliteti i shfaqjes së rrezikut; dëmi i shkaktuar projektit nga ky rrezik nëse ndodh; duke vlerësuar koston e eliminimit të rrezikut. Të gjitha vlerat përdorin të njëjtën shkallë, për shembull 1 - 10.

Procesi i menaxhimit të dokumentacionit dhe konfigurimit

“Menaxhimi i dokumentacionit të projektit të softuerit kërkon përpjekje të konsiderueshme organizative, sepse... dokumentacioni është një sistem kompleks subjekt i ndryshimeve të vazhdueshme që mund të bëhen njëkohësisht nga shumë njerëz" (E. Braude)

Procesi i dokumentimit përfshin një të formalizuar përshkrimi i informacionit, krijuar gjatë ciklit jetësor të PS. Ky proces përbëhet nga një sërë aktivitetesh që planifikojnë, projektojnë, zhvillojnë, prodhojnë, modifikojnë, shpërndajnë dhe mirëmbajnë dokumentet e nevojshme për të gjithë aktorët (menaxherët, specialistë teknikë dhe përdoruesit e sistemit).

GOST R ISO/IEC 9294-93. “Teknologjia e informacionit. Udhëzimet për Menaxhimin e Dokumentacionit të Softuerit" përcakton udhëzimet për menaxhim efektiv duke dokumentuar PS. Qëllimi i standardit është të ndihmojë në përcaktimin e një strategjie për dokumentimin e softuerit; zgjedhja e standardeve të dokumentacionit; zgjedhja e procedurave të dokumentacionit; përcaktimi i burimeve të nevojshme; hartimin e planeve të dokumentacionit.

Menaxhimi i dokumenteve do të thotë ta mbash atë të plotë dhe të qëndrueshëm (disa autorë përfshijnë këtu menaxhimin e konfigurimit).

Plotësia e dokumentacionit karakterizohet nga numri i standardeve dhe dokumenteve rregullatore që përbëjnë bazën e grupit të dokumentacionit që shoqëron një proces të veçantë në ciklin e jetës së softuerit.
Konsistenca e dokumentacionit do të thotë se grupi i dokumenteve nuk përmban kontradikta të brendshme. Kjo arrihet duke vendosur çdo specifikim vetëm në një vend - ky quhet dokumentacion holistik. Integriteti i dokumentacionit sigurohet nëpërmjet përdorimit të hiperlidhjeve.

Çdo kërkesë duhet të jetë e gjurmueshme Për të arritur këtë, secilës kërkesë i jepet një numër unik, i cili më pas referohet gjatë zhvillimit të konceptit, dizajnimit dhe deri te listimet e metodave.

• // kërkesa 4.3
• // autor
• // version
• // argumentet
• ... listimi i metodave...

Pjesët e projektit përfshijnë jo vetëm kodin burimor të programeve, por edhe të gjithë dokumentacionin, përfshirë planin e projektit. Gjatë jetës së tyre, projektet pësojnë ndryshime në dy drejtime:

• Së pari, kjo është blerja e pjesëve të reja,
• Së dyti, marrja e versioneve të reja të pjesëve ekzistuese. Për të gjurmuar saktë këto ndryshime, përdoret një grup i organizuar posaçërisht i procedurave administrative dhe teknike që lidhen me procesin e menaxhimit të konfigurimit.

Për të mbajtur gjurmët e pjesëve të një projekti, ju duhet të përcaktoni kufijtë e tyre dhe të identifikoni artikujt e konfigurimit (Artikujt e konfigurimit - CI). Elementet e konfigurimit mund të jenë klasa, më rrallë funksione, grupe të rëndësishme të të dhënave - tabela globale, dokumentacion. Llogaritja e gjendjes së konfigurimit kryhet duke regjistruar gjendjen e komponentëve të softuerit, duke përgatitur raporte për të gjitha modifikimet e zbatuara dhe të refuzuara të versioneve të komponentëve të softuerit. Një grup raportesh ofron një pasqyrim të qartë të gjendjes aktuale të sistemit dhe përbërësve të tij, si dhe mbajtjen e një historie modifikimesh.
Ekzistojnë mjete të veçanta softuerësh për menaxhimin e konfigurimit (për shembull, Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation, IBM Rational ClearCase, Subversion, etj.).

Në mënyrë tipike, sistemet e menaxhimit të konfigurimit plotësojnë kërkesat minimale të mëposhtme:

• aftësia për të përcaktuar elementet e konfigurimit;
• ruajtja në bazën e të dhënave të menaxhimit të konfigurimit të kronologjive të plota të versioneve të çdo objekti të krijuar ose ndryshuar gjatë procesit të zhvillimit të sistemit (kjo përfshin kodin e programit burimor, bibliotekat, programet e ekzekutueshme, modelet, dokumentacionin, testet, faqet e internetit dhe drejtoritë);
• mbështetje për ekipet e zhvillimit gjeografikisht të largëta;
• mohimi i të drejtave të modifikimit për të parandaluar më shumë se një person të punojë në një artikull konfigurimi në të njëjtën kohë;
• kontrolli i ndryshimeve të bëra në të gjitha objektet e sistemit;
• montimi i versioneve të softuerit nga komponentët e projektit.

IEEE zhvilloi standardin IEEE 828-1990"Plani i menaxhimit të konfigurimit të softuerit (SCMP)." Titulli i standardit dhe një shembull i një plani të menaxhimit të konfigurimit janë dhënë në librin e Eric Braude.

Figura - Dokumentet rregullatore të proceseve të ciklit jetësor ndihmës

Proceset e ciklit jetësor organizativ

Proceset organizative të ciklit jetësor përfshijnë: procesin e krijimit të infrastrukturës, procesin e përmirësimit, procesin e trajnimit, procesin e menaxhimit.

Figura - Struktura e proceseve të ciklit jetësor organizativ

Procesi i krijimit të infrastrukturës

është procesi i krijimit dhe sigurimit (mirëmbajtjes) të infrastrukturës, e cila mund të përmbajë harduer dhe softuer, mjete, metodologji, standarde dhe kushte për zhvillim, funksionim ose mirëmbajtje. Në fazën e parë të krijimit të infrastrukturës, bëhet zgjedhja e një sistemi mbështetës të dizajnit CASE, zgjedhja e një gjuhe programimi dhe një DBMS; organizimi i shërbimeve mbështetëse - administratorët e sistemit, administratorët e rrjetit, administratorët e bazës së të dhënave, sekretarët, etj.
Gjatë zgjidhjes së problemit të përzgjedhjes duke përdorur burime letrare, është e nevojshme të analizohen aftësitë e sistemeve instrumentale më të zakonshme për të ndërtuar një klasifikim dhe më pas, brenda një grupi të caktuar klasifikimi, të përcaktohen parametrat me të cilët do të bëhet përzgjedhja.
Vetë procedura e përzgjedhjes përfshin hapat e mëposhtëm:

1. Identifikohen treguesit bazë të sistemit të përzgjedhur, të cilët janë domethënës gjatë hartimit të një ACS të caktuar, duke marrë parasysh veçoritë, kufizimet, burimet, etj.
2. Të gjithë treguesit përmblidhen në një tabelë (shih tabelën 5), në të cilën, bazuar në vlerësimet e ekspertëve, secilit tregues i caktohet një koeficient peshe Vi (për shembull, nga 1 në 10), i cili karakterizon rëndësinë e këtij treguesi në krahasim me të tjerët. Shuma e vlerave të të gjithë koeficientëve të peshimit duhet të jetë e barabartë me kufirin e sipërm të koeficientit të peshimit (për shembull, 10).
3. Duke përdorur të dhëna të marra nga burime letrare dhe/ose nga ekspertë, për çdo tregues të i-të për çdo sistem të j-të, përcaktohet shkalla e dobisë Ui,j (nga 1 - minimale, në 10 - maksimale). Për shembull, një sistem i menaxhimit të konfigurimit që është relativisht i shtrenjtë mund të ketë një vlerësim të shërbimeve prej 1, ndërsa një sistem i disponueshëm lirisht do të kishte një vlerësim të shërbimeve prej 10.
4. Për çdo sistem të j-të që krahasohet, vlera e funksionit të vlerësimit llogaritet duke përdorur formulën: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. Bazuar në vlerën e funksionit të vlerësimit, bëhet një përfundim për këshillueshmërinë e përdorimit të një sistemi të caktuar në një projekt të caktuar, duke marrë parasysh kriteret e zgjedhura dhe kufizimet e specifikuara. Sistemi për të cilin vlera e funksionit të vlerësimit është më e madhe është më i miri për sa i përket zgjedhjes nga alternativat e krahasuara.

Procesi mësimor

është procesi i ofrimit të trajnimit fillestar dhe të vazhdueshëm për personelin. Porositja, shpërndarja, zhvillimi, funksionimi dhe mirëmbajtja e produkteve softuerike varen kryesisht nga kualifikimet e personelit. Prandaj, trajnimi i personelit duhet të planifikohet dhe kryhet paraprakisht për t'i përgatitur ata për punën në porositjen, furnizimin, zhvillimin, funksionimin ose mirëmbajtjen e një projekti softuerësh.

Procesi i përmirësimit

është procesi i krijimit, vlerësimit, matjes, kontrollit dhe përmirësimit të çdo procesi të ciklit jetësor të softuerit. Në praktikën inxhinierike, kur zhvillohet IS, përdoren metrikë - karakteristika sasiore të treguesve të caktuar.

Metrikat më të përdorura janë:

• sasia e punës së kryer, e matur në njësi fizike (për shembull, numri i rreshtave të kodit);
• koha e kaluar në punë;
• shkalla e defektit (për shembull, numri i defekteve për 1000 rreshta kodi, numri i defekteve për faqe dokumentacioni, etj.).

Vlerat metrike paraprake ose të dëshiruara parashikohen paraprakisht dhe më pas krahasohen me rezultatet e marra.
Meqenëse metrikat që lidhen me defektin luajnë një rol të veçantë, ne rendisim disa prej tyre:

1. Numri i defekteve për një mijë rreshta të kodit të softuerit të identifikuar brenda 12 javëve pas dorëzimit të projektit.
2. Devijimet në orar në çdo fazë: (Kohëzgjatja aktuale - Kohëzgjatja e planifikuar) / Kohëzgjatja e planifikuar.
3. Devijimet në kosto: (Kostoja aktuale - Kostoja e planifikuar) / Kostoja e planifikuar.
4. Koha totale e projektimit / Koha totale e programimit (sipas disa vlerësimeve duhet të jetë së paku 50%).
5. Shkalla në të cilën defektet shfaqen dhe zbulohen në një fazë është një nga metrikat më të thjeshta.

Kur rezultatet e zbulimit të defekteve krahasohen me standardet e organizatës, vlerësohet i gjithë procesi i krijimit të sistemit në tërësi, jo vetëm një projekt specifik. Të dhënat e akumuluara për defektet në çdo fazë paraqiten në tabelë siç tregohet, për shembull, në tabelë.

Fazat në të cilat u zbuluan defektet (në këtë projekt / standard)	Fazat që përmbajnë defekte
	Formimi i kërkesave	Detyrë teknike	Projektim paraprak
Formimi i kërkesave	2/5
Detyrë teknike	0,5/1,5	3/1
Projektim paraprak	0,1/0,3	1/3	2/2

Analiza e fazës “Formimi i kërkesave”. tregon se shkalla e zbulimit të defektit është më e vogël se normalja në të gjitha fazat e projektit. Më shumë defekte të projektimit u gjetën menjëherë në fazën kur u prodhuan dhe më pak defekte u gjetën në fazat e mëvonshme. Zakonisht kjo arrihet përmes inspektimit.

Sekuenca e veprimeve që duhet të ndërmerren gjatë gjithë ciklit jetësor të projektit për ta përmirësuar atë, për shembull, mund të jetë si kjo:

1. Identifikoni dhe përcaktoni metrikat që do të përdoren nga ekipi në çdo fazë, duke përfshirë:
   • koha e shpenzuar për kërkimin, zbatimin dhe analizën e rezultateve;
   • madhësia (për shembull, numri i rreshtave të kodit);
   • numri i defekteve të zbuluara në modul (për shembull, numri i rreshtave të kodit) dhe burimi i zbulimit të defektit;
   • vlerësimi i cilësisë në një shkallë nga 1 në 10.
2. Dokumentoni informacionin e marrë në SQAP.
3. Mblidhni statistika në çdo fazë.
4. Caktoni zhvilluesit përgjegjës për mbledhjen e të dhënave në çdo fazë, për shembull, "oficeri i cilësisë".
5. Planifikoni rishikimet e të dhënave metrike që do të jenë të dobishme në të ardhmen. Është e nevojshme të vendosni paraprakisht se cilat mund të jenë vlerat e metrikës dhe cilat duhet të jenë ato. Të dhënat e marra do të bëhen baza për krijimin e një baze të dhënash të projekteve të kompanisë.

Modeli i pjekurisë së aftësive organizative

Procesi i përmirësimit të teknologjisë së krijimit të softuerit reflektohet në planet strategjike të organizatës, strukturën e saj, teknologjitë e përdorura, kulturën e përgjithshme shoqërore dhe sistemin e menaxhimit.
Në fillim të viteve 1990, Instituti Amerikan i Inxhinierisë së Softuerit (SEI i Universitetit Carnegie Mellon (Pittsburgh, Pensilvania, SHBA)) formoi një model të pjekurisë teknologjike të organizatave CMM (Modeli i Maturitetit të Kapacitetit). Aktualisht, në Perëndim, një kompani zhvillimi po përjeton vështirësi të konsiderueshme në marrjen e një porosie nëse nuk është e certifikuar sipas CMM.
SMM përfaqëson material metodologjik, i cili përcakton rregullat për formimin e një sistemi menaxhues për krijimin dhe mirëmbajtjen e softuerit dhe metodat për përmirësimin gradual dhe të vazhdueshëm të kulturës së prodhimit. Qëllimi i SMM është t'u sigurojë organizatave zhvillimore udhëzimet e nevojshme mbi zgjedhjen e një strategjie për përmirësimin e cilësisë së proceseve duke analizuar shkallën e pjekurisë teknologjike të tyre dhe faktorët që ndikojnë më shumë në cilësinë e produkteve. Në çdo nivel të SMM vendosen kërkesa, përmbushja e të cilave siguron stabilizimin e treguesve më të rëndësishëm të procesit.

Procesi i menaxhimit

Menaxhimi i projektit ka të bëjë me arritjen e një ekuilibri midis kostos, aftësive, cilësisë dhe orarit. Ka disa aspekte që lidhen me procesin e menaxhimit të projektit: menaxhimi i personelit, planifikimi, vlerësimi i kostos së projektit.

Menaxhimi i personelit

Të dhënat empirike janë të njohura për të përcaktuar numrin optimal të anëtarëve të ekipit.

Figura - Varësia e efektivitetit të ekipit të zhvillimit nga përbërja e tij

Kjo varësi çon në nevojën e përdorimit të strukturave hierarkike të menaxhimit

Figura - Struktura hierarkike e menaxhimit

Përkundër faktit se numri i lidhjeve të secilit punonjës është i kënaqshëm, ata nuk marrin pjesë në formulimin e problemit, gjë që shkel një nga kërkesat kryesore të analizës së sistemit - numri maksimal i mundshëm i palëve të interesuara duhet të marrë pjesë në diskutimin e problemit. .
Një skemë alternative për organizimin e një ekipi punonjësish quhet "ekip i të barabartëve". Në këtë rast, të gjithë anëtarët e ekipit janë në të njëjtin nivel të hierarkisë dhe rolet shpërndahen ndërmjet tyre. Për më tepër, shpërndarja e roleve mund të ndryshojë pas një periudhe të caktuar kohe. Problemi i rritjes së numrit të lidhjeve në projekt i madh në këtë rast, zgjidhet duke theksuar rolin e personit përgjegjës për komunikimet e jashtme.

Në konceptin e programimit ekstrem të propozuar nga Kent Beck. theksi vihet në marrëdhënien e vazhdueshme midis zhvilluesve dhe klientit (dhe klienti bëhet një nga pjesëmarrësit në zhvillim), dëshira për të thjeshtuar rrënjësisht procesin e zhvillimit të sistemit dhe programimin e çifteve. Për më tepër, me programimin në çift, zhvilluesit punojnë vetëm së bashku në një kompjuter, me radhë. Kjo zbaton një formë të inspektimit të vazhdueshëm.

Përgatitja e një orari

Ka shumë standarde që përshkruajnë krijimin dhe mirëmbajtjen e planeve të menaxhimit të projekteve softuerike. Rekomandohet përdorimi i IEEE 1058.1-1987 Software Project Management Plan (SPMP). SPMP ofron një plan që përcakton se si dhe kur duhet të përfundojnë fazat e ndryshme të projektit. Pas përfundimit të çdo faze të mëvonshme të projektimit, orari duhet të plotësohet dhe rregullohet. Forma më e zakonshme e paraqitjes së një plani projekti është një grafik Gantt.

Figura - Pamje e përafërt e një grafiku Gantt

Rekomandohet që plani të përfshijë periudha buferike kur nuk është planifikuar të ekzekutohet asnjë proces. Një orar në formën e një grafiku Gantt, në shumicën e rasteve, ndërtohet duke përdorur Microsoft Office Project.
Procesi i planifikimit të punës për zbatimin e një projekti në veçanti dhe menaxhimit të projektit në përgjithësi shoqërohet me vlerësimin e kostos dhe kohëzgjatjes së projektit. Ky informacion është dhënë në seksionin 5.4. "Alokimi i buxhetit dhe burimeve" SPMP dhe, përveç kësaj, një vlerësim paraprak i kostos së projektit mund të ndikojë në versionin përfundimtar të kontratës midis klientit dhe kontraktorit, dhe për këtë arsye duhet të kryhet përpara nënshkrimit të termave të referencës.

Vlerësimi i kostove për krijimin e një PS

Procesi i vlerësimit të intensitetit të punës, si rregull, fillon njëkohësisht me fillimin e projektit dhe vazhdon edhe në fazën e shkrimit të kodit të programit.

Ndër metodat më të zakonshme për vlerësimin e intensitetit të punës janë këto:

• Modelimi algoritmik. Metoda bazohet në analizën e të dhënave statistikore për projektet e përfunduara më parë, dhe përcaktohet varësia e intensitetit të punës së projektit nga disa tregues sasiorë të produktit softuer (zakonisht madhësia e kodit të programit). Ky tregues është duke u vlerësuar për të këtij projekti, pas së cilës modeli parashikon kostot e ardhshme.
• Vlerësimet e ekspertëve.Është kryer një anketë me disa ekspertë në teknologjinë e zhvillimit të softuerit, të cilët e njohin fushën e aplikimit të produktit softuer që po krijohet. Secili prej tyre jep vlerësimin e vet për intensitetin e punës së projektit. Pastaj të gjitha vlerësimet krahasohen dhe diskutohen.
• Vlerësimi me analogji. Kjo metodë përdoret nëse projekte të ngjashme janë zbatuar tashmë në një zonë të caktuar të aplikimit të softuerit që po krijohet. Metoda bazohet në krahasimin e projektit të planifikuar me projektet e mëparshme që kanë karakteristika të ngjashme. Ai përdor të dhënat e ekspertëve ose të dhënat e ruajtura të projektit. Ekspertët llogaritin një vlerësim të lartë, të ulët dhe me shumë gjasa të përpjekjes bazuar në dallimet midis projektit të ri dhe projekteve të mëparshme.

Çdo metodë vlerësimi ka dobësi dhe pikat e forta Prandaj, aktualisht përdoren qasje që kombinojnë metoda të ndryshme.

Procedura për vlerësimin e intensitetit të punës së zhvillimit të softuerit përbëhet nga hapat e mëposhtëm:

1. vlerësimi i madhësisë së produktit në zhvillim;
2. vlerësimi i intensitetit të punës në muaj njerëzor ose në orë pune;
3. vlerësimi i kohëzgjatjes së projektit në muaj kalendarik;
4. vlerësimi i kostos së projektit.

Njësitë kryesore të matjes së madhësisë së softuerit janë:

• numri i rreshtave të kodit (LOC – Lines of Code);
• pikat e funksionit (FP – Function Points).

Metodologjia për vlerësimin e madhësisë funksionale

Metodologjia për vlerësimin e madhësisë funksionale (FP – Pikat Funksionale)është të maten në mënyrë uniforme të gjitha aftësitë e një aplikacioni dhe të shprehë madhësinë e aplikacionit si një numër i vetëm. Ky numër më pas mund të përdoret për të vlerësuar numrin e rreshtave të kodit, koston dhe afatin kohor të projektit.
Për të llogaritur madhësinë funksionale, renditja dhe kompleksiteti përcaktohen për çdo karakteristikë informacioni të sistemit. Grupi Ndërkombëtar i Përdoruesve të Pikave të Funksionit (IFPUG, www.ifpug.org) ka publikuar kriteret për identifikimin e karakteristikave të informacionit, të cilat ndahen në pesë grupe:

• – një grup i njohur nga përdoruesi i të dhënave të lidhura logjikisht që ndodhet brenda aplikacionit dhe shërbehet përmes hyrjeve të jashtme.

• – një grup i njohur nga përdoruesi i të dhënave të lidhura logjikisht që ndodhet brenda dhe mirëmbahet nga një aplikacion tjetër. Skedari i jashtëm i një aplikacioni të caktuar është një skedar logjik i brendshëm në një aplikacion tjetër.

• – një proces elementar që lëviz të dhënat nga mjedisi i jashtëm në aplikacion. Të dhënat mund të vijnë përmes kanaleve të komunikimit, nga përdoruesi në një ekran hyrës ose nga një aplikacion tjetër. Të dhënat mund të përdoren për përditësimin e skedarëve logjikë të brendshëm dhe mund të përmbajnë informacione të menaxhimit dhe biznesit. Të dhënat e kontrollit nuk duhet të modifikojnë skedarin e brendshëm logjik (p.sh. fushat e futjes së të dhënave, mesazhet e gabimit, vlerat e llogaritura, butonat).

• – një proces elementar që zhvendos të dhënat e llogaritura në një aplikacion në mjedisi i jashtëm. Përveç kësaj, skedarët logjikë të brendshëm mund të përditësohen gjatë këtij procesi. Të dhënat krijojnë raporte ose skedarë dalës që dërgohen në aplikacione të tjera. Raportet dhe skedarët krijohen bazuar në skedarët logjikë të brendshëm dhe skedarët e ndërfaqes së jashtme. Për më tepër, ky proces mund të përdorë të dhëna hyrëse që përfshijnë kriteret dhe parametrat e kërkimit që nuk mbështeten nga skedarët logjikë të brendshëm. Të dhënat hyrëse vijnë nga jashtë, por janë të përkohshme dhe nuk ruhen në një skedar logjik të brendshëm (për shembull, fushat e të dhënave në raporte, vlerat e llogaritura, mesazhet e gabimit).

• – një proces elementar që funksionon si me të dhënat hyrëse ashtu edhe ato dalëse, i përbërë nga një kombinim kërkesë-përgjigje, por jo i lidhur me llogaritjen e të dhënave të përftuara ose përditësimin e ILF. Rezultati i tij janë të dhënat e kthyera nga skedarët logjikë të brendshëm dhe skedarët e ndërfaqes së jashtme. Pjesa hyrëse e procesit nuk modifikon skedarët e brendshëm logjikë dhe pjesa dalëse nuk mbart të dhëna të llogaritura nga aplikacioni (ky është ndryshimi midis një kërkese dhe një daljeje). Për shembull: elementet hyrëse - fusha e përdorur për kërkim, klikimi i mausit; elementet e shfaqura – fushat e shfaqura në ekran.

Baryshnikova Marina Yurievna
MSTU im. N.E. Bauman
Caf. IU-7

Leksioni 3

Cikli i jetës së softuerit
dispozitë

Cikli i jetës së softuerit

është një periudhë kohore që fillon me
momentin e vendimmarrjes
nevoja për të krijuar softuer
dispozitë dhe përfundon në këtë moment
tërheqjen e plotë të tij nga shërbimi
(IEEE Std. 610.12 – 19990 Fjalori standard i softuerit
Terminologjia inxhinierike)

Konceptet themelore të përfshira në përcaktimin e ciklit jetësor

Artefaktet janë informacion i krijuar nga njeriu
entitete - dokumente, në një kuptim mjaft të përgjithshëm
duke marrë pjesë si të dhëna hyrëse dhe duke rezultuar në
cilësinë e rezultateve të aktiviteteve të ndryshme.
Roli është një grup abstrakt i personave të interesuar,
të përfshirë në krijimin dhe funksionimin e
sisteme që zgjidhin të njëjtat probleme ose kanë të njëjtat
dhe të njëjtat interesa në lidhje me të
Produkt softuerik - një grup programesh kompjuterike,
procedurat dhe dokumentacioni mundësisht shoqërues dhe
të dhëna
Një proces është një grup veprimesh të ndërlidhura,
duke transformuar disa të dhëna hyrëse në dalje

Cikli i jetës së softuerit sipas standardit ISO/IEC 12207: 1995
"Teknologjia ndërkombëtare - proceset e ciklit jetësor të softuerit"
(GOST ISO IEC 12207-99 Teknologjitë e informacionit.
Cikli i jetës së softuerit)
Cikli i jetes
Organizative
proceset
Kontrolli
projekti
Krijim
infrastrukturës
Vlerësimi dhe përmirësimi
cikli i jetes
Arsimi
bazë
proceset
Përvetësimi
Ndihmës
proceset
Dokumentacioni
Furnizimi
Kontrolli
konfigurimi
Zhvillimi
Siguria
cilësisë
Shfrytëzimi
Verifikimi
Shoqërues
Certifikimi
E përbashkët
gradë
Auditimi
Leja
probleme

Procesi i blerjes së softuerit
Përcakton veprimet e klientit që blen softuerin
softuerët ose shërbimet që lidhen me softuerin bazuar në kontratë
marrëdhëniet
Gjatë këtij procesi, klienti kryen sa më poshtë:
veprimet:
ndërgjegjësimin për nevojat tuaja në sistemin softuer dhe
marrjen e vendimeve në lidhje me blerjen, zhvillimin me porosi
ose përmirësime në një sistem ekzistues;
përgatitjen e propozimeve të ofertave që përmbajnë kërkesat për
sistemi, kushtet e tij të funksionimit dhe teknike
kufizimet, si dhe kushte të tjera të kontratës
Blerja është procesi i marrjes së një sistemi,
produkt softuerik ose shërbim softuerik

Procesi i dorëzimit
Përcakton veprimet e organizatës furnizuese mbi
në lidhje me ofertat e klientit
Procesi përfshin:
shqyrtimi i propozimeve të klientit për ofertën dhe përfshirja në to
rregullimet tuaja (nëse është e nevojshme);
përgatitja e një marrëveshjeje me klientin;
planifikimi i ekzekutimit të punës (në këtë rast, puna mund
kryhet vetë ose me përfshirjen e një nënkontraktori);
zhvillimin Struktura organizative projekt, teknik
kërkesat për mjedisin dhe burimet e zhvillimit, masat për
menaxhimi i projektit etj.
Procesi i dorëzimit është përgjegjës për ekzekutimin e proceseve
zhvillimi, funksionimi dhe (ose) mirëmbajtja

Procesi i zhvillimit

Përcakton veprimet e kryera nga zhvilluesi në
procesi i krijimit të softuerit dhe i tij
komponentët sipas kërkesave të specifikuara
Ky proces përfshin, por nuk kufizohet në:
regjistrimin e projektimit dhe operacional
dokumentacion;
përgatitja e materialeve të nevojshme për verifikim
funksionueshmërinë e produktit softuer dhe të tij
pajtueshmëria me standardet e cilësisë;
zhvillimi i materialeve (metodologjike dhe edukative),
të nevojshme për trajnimin dhe edukimin e personelit dhe
etj.

Procesi i zhvillimit

Zgjedhja e një modeli të ciklit jetësor
Analiza e kërkesave të sistemit
Dizajni i arkitekturës së sistemit
Analiza e kërkesave të softuerit
Dizajn i detajuar i softuerit
Kodimi dhe testimi i softuerit
Integrimi i softuerit
Testimi i kualifikimit të softuerit
Integrimi i sistemit
Testimi i kualifikimit të sistemit
Instalimi i softuerit
Pranimi i softuerit

10. Analiza e kërkesave të sistemit

Në këtë fazë, merret parasysh fusha e aplikimit të sistemit.
Lista e kërkesave për sistemin që po zhvillohet duhet të përfshijë:
një sërë kushtesh në të cilat synohet të funksionojë
sistemi i ardhshëm (burimet e harduerit dhe softuerit,
i ofruar sistemit; kushtet e jashtme të funksionimit të tij;
përbërja e njerëzve dhe punët që lidhen me të);
përshkrimin e funksioneve të kryera nga sistemi;
kufizimet në procesin e zhvillimit (afat e direktivës për përfundimin
fazat individuale, burimet në dispozicion, procedurat organizative
dhe masat për të siguruar mbrojtjen e informacionit, etj.)
Kërkesat e sistemit vlerësohen në bazë të kritereve
fizibiliteti dhe verifikueshmëria gjatë testimit

11. Analiza e kërkesave për softuer

Përfshin përcaktimin e sa vijon
karakteristikat për çdo komponent të softuerit:
funksionalitetin, duke përfshirë
karakteristikat e performancës dhe mjedisit
funksionimin e komponentit
ndërfaqet e jashtme
specifikimet e besueshmërisë dhe sigurisë;
kërkesat ergonomike
kërkesat për të dhënat e përdorura
kërkesat e instalimit dhe pranimit
kërkesat e dokumentacionit të përdoruesit
kërkesat për funksionim dhe mirëmbajtje

12. Dizajni i arkitekturës së softuerit

Arkitektura e softuerit
është një përshkrim i nënsistemeve dhe komponentëve të softuerit
sistemet, si dhe lidhjet ndërmjet tyre
Si pjesë e projektimit të një arkitekture për të gjithë
Komponenti i softuerit kryen detyrat e mëposhtme:
përcaktimi i një strukture në një nivel të lartë abstraksioni
softuerin dhe përbërjen e komponentëve të tij
zhvillimin dhe dokumentimin e softuerit
ndërfaqet e softuerit dhe bazës së të dhënave
zhvillimi i një versioni paraprak të një zakoni
dokumentacionin
zhvillimin dhe dokumentimin e paraprake
kërkesat e testimit dhe plani i integrimit të softuerit

13. Dizajn i detajuar i softuerit (plani i punës për zhvillimin e softuerit)

Përfshin detyrat e mëposhtme:
përshkrimi i komponentëve të softuerit dhe ndërfaqeve ndërmjet
ato në një sasi të mjaftueshme për të
kodimi i mëvonshëm i pavarur dhe
duke testuar
zhvillimin dhe dokumentimin e detajuar
projekti i bazës së të dhënave
përditësimi i dokumentacionit të përdoruesit
zhvillimin dhe dokumentimin e kërkesave për
testet dhe plani i testimit të komponentëve të softuerit

14. Kodimi dhe testimi i softuerit përfshin zgjidhjen e detyrave të mëposhtme:

zhvillimi (kodimi) dhe dokumentacioni
çdo komponent softuerik dhe bazë të dhënash, si dhe
grup procedurash testimi dhe të dhënash për
duke testuar
testimi i çdo komponenti të softuerit dhe bazës së të dhënave
të dhëna për respektimin e kërkesave për to
Kërkesat
përditësimi (nëse është e nevojshme) përdoruesi
dokumentacionin
përditësimi i planit të integrimit të softuerit

15. Integrimi i sistemit

konsiston në montimin e të gjithëve
komponentët, duke përfshirë softuerin dhe
pajisje dhe testim
komponentët e agreguar
Procesi i integrimit gjithashtu prodhon
regjistrimin dhe verifikimin e kompletit
dokumentacioni i sistemit

16. Testimi i kualifikimit të softuerit

kryhet nga zhvilluesi në prani
klientit për të demonstruar se softueri
plotëson specifikimet e tij dhe
gati për përdorim në kushte
operacion
Kjo gjithashtu kontrollon plotësinë
dokumentacioni teknik dhe i përdoruesit dhe
përshtatshmërinë e tij ndaj komponentëve të softuerit

17. Instalimi dhe pranimi i softuerit

Instalimi i softuerit kryhet nga zhvilluesi në
sipas planit në atë mjedis dhe mbi atë
pajisjet e parashikuara në kontratë. NË
Gjatë procesit të instalimit kontrollohet funksionaliteti
Software dhe bazat e të dhënave
Pranimi i softuerit përfshin vlerësimin e rezultateve
testimin e kualifikimit të sistemit dhe
dokumentacioni i rezultateve të vlerësimit, i cili
prodhuar nga klienti me ndihmën e zhvilluesit.
Zhvilluesi kryen transferimin përfundimtar të softuerit
klientit në përputhje me kontratën, duke siguruar
me trajnimin dhe mbështetjen e nevojshme

18. Funksionimi i softuerit

Sistemi operohet në
mjedisi i destinuar për këtë qëllim
sipas zakonit
dokumentacionin
Përfshin instalimin
standardet operacionale dhe
kryerjen operacionale
duke testuar

19. Mirëmbajtja e softuerit (sipas standardit IEEE – 90)

duke bërë ndryshime në softuer për të korrigjuar
gabime, përmirësime të performancës ose
përshtatja ndaj kushteve të ndryshuara të punës
ose kërkesat
Funksionet e shërbimit mbështetës:
analiza e problemeve dhe kërkesave për modifikime të softuerit
modifikimi i një produkti softuerik
verifikimin dhe pranimin e tij
transferimi i softuerit në një mjedis tjetër
çmontimi i softuerit

20. Proceset mbështetëse të ciklit jetësor të softuerit

Dokumentacioni
Menaxhimi i konfigurimit
Sigurimi i cilësisë
Verifikimi
Certifikimi
Vlerësimi me pjesëmarrje
Auditimi
Zgjidhja e problemit

21. Procesi i dokumentimit

Dokumentacioni - përshkrim i zyrtarizuar
informacioni i krijuar në të gjithë
cikli jetësor i softuerit
Ky është një grup veprimesh me të cilat
planifikoni, projektoni, zhvilloni,
prodhojnë, modifikojnë, shpërndajnë dhe
të shoqërojë dokumentet e nevojshme për të gjithë
palët e interesuara të përfshira në zhvillim
Software, si dhe për përdoruesit e sistemit

22. Menaxhimi i konfigurimit

Konfigurimi i softuerit është
tërësia e tij funksionale dhe fizike
karakteristikat e përcaktuara në teknik
dokumentacionin dhe të zbatuar në programe
Procesi ju lejon të organizoni, sistematikisht
të marrë parasysh dhe të kontrollojë ndryshimet në
Software në të gjitha fazat e ciklit jetësor
Janë pasqyruar parimet dhe rekomandimet e përgjithshme për menaxhimin e konfigurimit
në standardin ISO/IEC CD 12207 – 2:1995 “Information Technology – Software”
Proceset e ciklit. Pjesa 2. Menaxhimi i konfigurimit për softuerin”

23. Procesi i Sigurimit të Cilësisë

Ofron siguri se produkti softuerik dhe
proceset e ciklit jetësor të tij korrespondojnë me të specifikuarit
kërkesat, si dhe të zhvilluara dhe miratuara
planet e punës
Cilësia është një grup karakteristikash që karakterizojnë
aftësia e softuerit për të kënaqur
duke pasur parasysh kërkesat dhe nevojat e të gjithë të interesuarve
partive
Procesi është krijuar për të siguruar pajtueshmërinë
proceset e ciklit jetësor, mjedisi i zhvillimit dhe
kualifikimet e personelit sipas kushteve të kontratës së vendosur
standardet dhe procedurat. Për këtë duhet të ketë
sigurohet cilësia e produktit, cilësia e procesit dhe të tjera
treguesit e cilësisë së sistemit

24. Verifikimi

Ky është procesi i përcaktimit nëse gjendja aktuale e zhvillimit përmbushet
të arritura në këtë fazë, kërkesat e kësaj faze. Në vazhdim
verifikimi kontrollon kushtet e mëposhtme:
konsistenca e kërkesave të sistemit dhe shkalla e shqyrtimit të nevojave
përdorues
aftësia e furnizuesit për të përmbushur kërkesat e specifikuara
pajtueshmërinë e proceseve të ciklit jetësor të përzgjedhur me kushtet e kontratës
përshtatshmërinë e standardeve, procedurave dhe mjedisit të zhvillimit me proceset e ciklit jetësor të softuerit
pajtueshmërinë e specifikimeve të projektimit me kërkesat e specifikuara
korrektësia e përshkrimit në specifikimet e projektimit të hyrjes dhe daljes
të dhënat, sekuenca e ngjarjeve, logjika etj.
përputhshmëria e kodit me specifikimet dhe kërkesat e projektimit
testueshmëria dhe korrektësia e kodit, përputhshmëria e tij me standardet e pranuara
kodimi
integrimi korrekt i komponentëve të softuerit në sistem
përshtatshmërinë, plotësinë dhe konsistencën e dokumentacionit
Verifikimi është një grup veprimesh të krahasuara
rezultati i përftuar i ciklit jetësor me karakteristikat e kërkuara
për këtë rezultat, i cili konsiderohet si një provë formale
korrektësia e softuerit

25. Vërtetim

parashikon përcaktimin e plotësisë
pajtueshmërinë me kërkesat e specifikuara dhe
sistemi ose softueri i krijuar
produktit sipas specifikave të tyre
qëllim funksional
Verifikimi dhe certifikimi - dy pikëpamje për cilësinë:
nëse verifikimi vlerëson softuerin për sa i përket mënyrës se si është krijuar,
atëherë certifikimi merr parasysh sistemi softuerik nga pikëpamja
çfarë bën (d.m.th. vlerësohet aftësia e sistemit softuerik
plotësoni nevojat funksionale të përdoruesve)

26. Proceset organizative të ciklit jetësor të softuerit

Kontrolli
Krijimi i infrastrukturës (infrastrukturës
projekti softuerik përfshin teknologjitë dhe
standardet, si dhe një grup pajisjesh,
softuerët dhe mjetet për
zhvillimi, funksionimi ose mirëmbajtja e softuerit)
Përmirësimi
Trajnimi (trajnimi fillestar dhe
rritje e mëvonshme e përhershme
kualifikimet e personelit, duke përfshirë zhvillimin
materiale mësimore)

27. Grupet e standardeve ESPD

Kodi i grupit
0
1
2
3
4
5
6
7
8
9
Emri i grupit
Dispozitat e përgjithshme
Standardet Themelore
Rregullat për ekzekutimin e dokumentacionit të zhvillimit
Rregullat për plotësimin e dokumentacionit të prodhimit
Rregullat për ekzekutimin e dokumentacionit mbështetës
Rregullat për zbatimin e dokumentacionit operacional
Rregullat për qarkullimin e dokumentacionit të softuerit
Grupet e rezervave
Standarde të tjera
Përcaktimi i standardit ESPD përbëhet nga:
numri 19 (i caktuar në klasën e standardeve ESPD);
një shifër (pas pikës) që tregon kodin e grupit të klasifikimit të standardeve,
treguar në tabelë;
një numër dyshifror (pas një vize) që tregon vitin e regjistrimit të standardit

28. Lista e dokumenteve të ESPD

GOST 19.001-77 ESPD. Dispozitat e përgjithshme
GOST 19.101-77 ESPD. Llojet e programeve dhe dokumentet e programit
GOST 19.102-77 ESPD. Fazat e zhvillimit
GOST 19.103-77 ESPD. Përcaktimi i programeve dhe dokumenteve të programit
GOST 19.104-78 ESPD. Mbishkrimet bazë
GOST 19.105-78 ESPD. Kërkesat e përgjithshme për të programuar dokumentet
GOST 19.106-78 ESPD. Kërkesat për dokumentet e printuara të programit
GOST 19.201-78 ESPD. Detyrë teknike. Kërkesat për përmbajtjen dhe dizajnin
GOST 19.202-78 ESPD. Specifikim. Kërkesat për përmbajtjen dhe dizajnin
GOST 19.301-79 ESPD. Procedura dhe metodologjia e testimit
GOST 19.401-78 ESPD. Teksti i programit. Kërkesat për përmbajtjen dhe dizajnin
GOST 19.402-78 ESPD. Përshkrimi i programit
GOST 19.404-79 ESPD. Shënim shpjegues. Kërkesat për përmbajtjen dhe dizajnin
GOST 19.501-78 ESPD. Forma. Kërkesat për përmbajtjen dhe dizajnin
GOST 19.502-78 ESPD. Përshkrimi i aplikimit. Kërkesat për përmbajtjen dhe dizajnin
GOST 19.503-79 ESPD. Udhëzuesi i Programuesit të Sistemit. Kërkesat e përmbajtjes dhe
regjistrimin
GOST 19.504-79 ESPD. Udhëzues për programues
GOST 19.505-79 ESPD. Manuali i operatorit
GOST 19.506-79 ESPD. Përshkrimi i gjuhës
GOST 19.508-79 ESPD. Udhëzues mirëmbajtjen. Kërkesat e përmbajtjes dhe
regjistrimin
GOST 19.604-78 ESPD. Rregullat për të bërë ndryshime në dokumentet e programit të ekzekutuara
në formë të shtypur
GOST 19.701-90 ESPD. Skemat e algoritmeve, programeve, të dhënave dhe sistemeve. Legjenda Dhe
rregullat e ekzekutimit
GOST 19.781-90. Sigurimi i sistemeve të përpunimit të informacionit

29. Përparësitë e përdorimit të standardeve ESPD

Standardet ESPD futin një element të renditjes në
procesi i dokumentimit të softuerit
(PS);
pavarësisht nga kërkesat për kompletin
dokumentacionin për softuerin e parashikuar nga standardet
ESPD, ato ju lejojnë të shtoni lloje shtesë
dokumente;
Standardet ESPD ju lejojnë të ndryshoni celularin
strukturat dhe përmbajtja e specieve të vendosura
dokumentet e programit bazuar në kërkesat
klient dhe përdorues

30. Disavantazhet e standardeve ESPD

orientimi drejt një modeli të vetëm, "kaskadë" të jetës
cikli i softuerit;
mungesa e udhëzimeve të qarta të dokumentacionit
karakteristikat e cilësisë së softuerit;
mungesa e lidhjes sistematike me të tjerat ekzistuese
sistemet e brendshme të standardeve të ciklit jetësor dhe
dokumentacioni i produkteve në përgjithësi, për shembull, ESKD;
qasje e paqartë për dokumentimin e softuerit si
produkte komerciale;
mungesa e rekomandimeve për vetë-dokumentimin e softuerit,
për shembull, në formën e menyve në ekran dhe mjeteve të ndihmës në internet
përdorues ("ndihmon");
mungesa e rekomandimeve për përbërjen, përmbajtjen dhe dizajnin
dokumente për softuer të rënë dakord
rekomandimet e standardeve ndërkombëtare dhe rajonale

31. Standardi GOST 34.601-90: fazat dhe fazat e krijimit të një sistemi të automatizuar

1.
Formimi i kërkesave për folësit
2.
Zhvillimi i konceptit të AC
3.
Studimi i objektit
Kryerja e punës së nevojshme kërkimore
Zhvillimi i opsioneve për konceptin AC dhe përzgjedhja e një opsioni për konceptin AC,
përmbushja e kërkesave të përdoruesve
Hartimi i një raporti për punën e bërë
Detyrë teknike
4.
Inspektimi i objektit dhe arsyetimi për nevojën e krijimit të një centrali bërthamor
Formimi i kërkesave të përdoruesve për folësit
Përgatitja e një raporti për përfundimin e punës dhe një aplikim për zhvillimin e një NPP
Zhvillimi dhe miratimi Termat e referencës për të krijuar një AS
Projektim paraprak
Zhvillimi i zgjidhjeve të projektimit paraprak për sistemin dhe pjesët e tij

32.

Standardi GOST 34.601-90: fazat dhe fazat
krijimi i një sistemi të automatizuar
5.
Projekt teknik
6.
Dokumentacioni i punës
7.
Hartimi i dokumentacionit të punës për TEC-in dhe pjesët e tij
Zhvillimi dhe përshtatja e programeve
Komisionimi
8.
Zhvillimi i zgjidhjeve të projektimit për sistemin dhe pjesët e tij
Zhvillimi i dokumentacionit për sistemin e altoparlantëve dhe pjesët e tij
Zhvillimi dhe ekzekutimi i dokumentacionit për furnizimin e komponentëve
Zhvillimi i detyrave të projektimit në pjesët ngjitur të projektit
Përgatitja e një objekti automatizimi
Trajnimi i personelit
Set i plotë i altoparlantëve me produktet e furnizuara (softuer dhe harduer,
sistemet softuerike dhe harduerike, produktet e informacionit)
Punimet e ndertimit dhe instalimit
Punimet e komisionimit
Kryerja e testeve paraprake
Kryerja e operacionit provë
Kryerja e testeve të pranimit
Mbështetje AC
Kryerja e punës në përputhje me detyrimet e garancisë
Shërbimi pas garancisë

Qëllimet dhe objektivat e metodologjisë së projektimitNGA. Zonat kryesore të projektimitNGA. Fazat e krijimitNGA.

Software (Software) është një produkt inteligjent, i pavarur nga mediumi në të cilin është regjistruar, duke përfshirë programet, rregullat dhe të dhënat e lidhura, të cilat, kur ngarkohen në zonën e ekzekutimit të një programi kompjuterik, siguron funksionimin e tij.

Software (Produkt softuerik) - një grup programesh kompjuterike, procedurash dhe, ndoshta, dokumentacione dhe të dhëna të lidhura.

Software (Produkt softuerik) - çdo grup programesh kompjuterike, procedurash dhe dokumentacioni dhe të dhënash shoqëruese të marra si rezultat i zhvillimit të softuerit dhe të destinuara për t'i dorëzuar përdoruesit [ISO/IEC 12207]. Shënim. Produktet përfshijnë produkte të ndërmjetme dhe produkte të destinuara për përdoruesit si zhvilluesit dhe personeli i mirëmbajtjes.

Zhvillimi i softuerit Inxhinieria e softuerit është një formë zhvillimi që zbaton parimet e shkencës kompjuterike, teknologjisë së informacionit, matematikës dhe shkencës së aplikimit për të arritur zgjidhje me kosto efektive për problemet praktike përmes softuerit.

Dizajni i Softuerit është procesi i ndërtimit të aplikacioneve me madhësi reale dhe rëndësi praktike që plotësojnë kërkesat e specifikuara të funksionalitetit dhe performancës.

Programimi - është një nga aktivitetet e përfshira në ciklin e zhvillimit të softuerit.

Fazat e krijimit të softuerit

1. Kuptoni natyrën dhe qëllimin e produktit të propozuar.

2. Zgjidhni një proces zhvillimi dhe krijoni një plan.

3. Mblidhni kërkesat.

4. Dizajnoni dhe montoni produktin.

5. Kryeni testimin e produktit.

6. Lëshoni produktin dhe jepni mbështetjen e tij.

Me ciklin jetësor të një programi nënkuptojmë një grup fazash:

Analiza e fushës së lëndës dhe krijimi i specifikimeve teknike (ndërveprimi me klientin)

Hartimi i strukturës së programit

Kodimi (bashkësia e kodit të programit sipas dokumentacionit të projektit)

Testimi dhe korrigjimi

Zbatimi i programit

Mbështetja e programit

Asgjesimi

Koncepti i ciklit jetësor të softuerit (LC). Përkufizimi i ciklit jetësor sipas standardit ndërkombëtar ISO/IEC 12207:1995. Proceset bazë të ciklit jetësor të softuerit.

Cikli i jetës së softuerit është një proces i vazhdueshëm që fillon që nga momenti kur merret një vendim për nevojën e krijimit të tij dhe përfundon kur ai hiqet plotësisht nga shërbimi.

Cikli i jetës (LC) i softuerit përkufizohet si një periudhë kohore që fillon nga momenti kur merret një vendim për nevojën e krijimit të softuerit dhe përfundon në momentin që ai hiqet plotësisht nga shërbimi.

Dokumenti kryesor rregullator që rregullon përbërjen e proceseve të ciklit jetësor të softuerit është standardi ndërkombëtar ISO/IEC 12207: 1995 "Teknologjia e informacionit - Proceset e ciklit të jetës së softuerit" (ISO - Organizata Ndërkombëtare për Standardizim, IEC - Komisioni Ndërkombëtar Elektroteknik - Komisioni Ndërkombëtar për Standardizim) Inxhinieria elektrike Përcakton strukturën e ciklit jetësor që përmban proceset, veprimet dhe detyrat që duhet të kryhen gjatë krijimit të softuerit.

Në këtë standard Software (ose produkt softuer) përkufizohet si një grup programesh kompjuterike, procedurash, dhe ndoshta dokumentacioni dhe të dhënash të lidhura.

Procesi përkufizohet si një grup veprimesh të ndërlidhura (një grup punimesh të ndërlidhura) që transformojnë disa fillestare (të dhëna hyrëse) në dalje (rezultate). Çdo proces karakterizohet nga detyra dhe metoda të caktuara për zgjidhjen e tyre, të dhëna hyrëse të marra nga procese të tjera dhe rezultate.

Çdo procesi të ndarë në një sërë veprimesh, secili veprim– për grup detyrat. Çdo proces, veprim ose detyrë inicohet dhe ekzekutohet nga një proces tjetër sipas nevojës, dhe nuk ka sekuenca të paracaktuara ekzekutimi (natyrisht, duke ruajtur lidhjet në të dhënat hyrëse).

Proceset bazë të ciklit jetësor :

Porosi (blerje);

Veprimi - fillimi i blerjes

Veprimi – përgatitja e propozim-propozimeve

Veprimi - përgatitja dhe rregullimi i kontratës

Veprimi - mbikëqyrja e aktiviteteve të furnitorëve

Në vazhdim pranimi përgatiten dhe kryhen analizat e nevojshme. Përfundimi i punës sipas kontratës kryhet nëse plotësohen të gjitha kushtet e pranimit

Furnizimi;

Fillimi i dorëzimit

Planifikimi

Zhvillimi;

Procesi i zhvillimit përfshin aktivitetet dhe detyrat e kryera nga zhvilluesi dhe përfshin sa vijon:

Punë përgatitore

Analiza e kërkesave të sistemit

Dizajni i arkitekturës së sistemit në një nivel të lartë është identifikimi i komponentëve të harduerit, softuerit dhe operacioneve të tij të kryera nga personeli që operon sistemin. Arkitektura e sistemit duhet të jetë në përputhje me kërkesat e sistemit dhe standardet dhe praktikat e pranuara të projektimit.

Analiza e kërkesave të softuerit

Dizajni i arkitekturës së softuerit

Kodimi dhe testimi i softuerit

Integrimi i softuerit

Testimi i kualifikimit të softuerit

Integrimi i sistemit

Instalimi i softuerit

Pranimi i softuerit

Shfrytëzimi; mbulon veprimet dhe detyrat e operatorit - organizatës që operon sistemin dhe përfshin veprimet:

Punë përgatitore përfshin operatorin që kryen detyrat e mëposhtme:

planifikimi i aktiviteteve dhe punës së kryer gjatë operimit dhe vendosja e standardeve operacionale;

përcaktimin e procedurave për lokalizimin dhe zgjidhjen e problemeve që dalin gjatë operimit.

Testimi i performancës kryhet për çdo botim të ardhshëm të produktit softuer, pas së cilës ai transferohet në funksion.

Operacioni i Sistemit

Mbështetja e përdoruesit

Procesipërcjellje parashikon veprimet dhe detyrat e kryera nga shërbimi mbështetës. Në përputhje me standardin IEEE-90 nën shoqërim i referohet bërjes së ndryshimeve në softuer për të korrigjuar gabimet, për të përmirësuar performancën ose për t'u përshtatur me ndryshimin e kushteve ose kërkesave të funksionimit.

Punë përgatitore shërbimet mbështetëse përfshijnë detyrat e mëposhtme:

planifikimi i veprimeve dhe punës së kryer gjatë procesit të mbështetjes;

përcaktimin e procedurave për lokalizimin dhe zgjidhjen e problemeve që dalin gjatë procesit të mirëmbajtjes.

Analiza e problemeve dhe kërkesave për modifikime të softuerit

Modifikimi i softuerit

Inspektimi dhe pranimi

Çmontimi i softuerit kryhet sipas gjykimit të klientit me pjesëmarrjen e organizatës operuese, shërbimit mbështetës dhe përdoruesve. Në këtë rast, produktet softuerike dhe dokumentacioni përkatës i nënshtrohen arkivimit në përputhje me marrëveshjen.

Koncepti i ciklit jetësor të softuerit (LC). Përkufizimi i ciklit jetësor sipas standardit ndërkombëtar ISO/IEC 12207:1995. Proceset ndihmëse të ciklit jetësor të softuerit.

Shih pikën 2

Proceset ndihmëse të ciklit jetësor :

Dokumentacioni; një përshkrim i formalizuar i informacionit të krijuar gjatë ciklit jetësor të softuerit.

Procesi i dokumentimit përfshin hapat e mëposhtëm:

punë përgatitore;

projektimi dhe zhvillimi;

lëshimi i dokumentacionit;

shoqërim

Menaxhimi i konfigurimit asaj; për të përcaktuar statusin e komponentëve të softuerit në sistem, për të menaxhuar modifikimet e softuerit, për të përshkruar dhe përgatitur raporte mbi statusin e komponentëve të softuerit dhe kërkesat për modifikim, për të siguruar plotësinë, përputhshmërinë dhe korrektësinë e softuerit, për të menaxhuar ruajtjen dhe shpërndarjen e softuerit. Sipas standardit IEEE - 90 konfigurimi Softueri kuptohet si tërësia e funksionalitetit dhe karakteristikat fizike instaluar në dokumentacioni teknik dhe të implementuara në softuer.

punë përgatitore

identifikimi i konfigurimit vendos rregulla që mund të përdoren për të identifikuar dhe dalluar qartë komponentët e softuerit dhe versionet e tyre

kontrolli i konfigurimit ka për qëllim një vlerësim sistematik të modifikimeve të softuerit të propozuar dhe zbatimin e tyre të koordinuar, duke marrë parasysh efektivitetin e secilit modifikim dhe kostot e zbatimit të tij

kontabiliteti i statusit të konfigurimit (paraqet regjistrimin e gjendjes së komponentëve të softuerit, përgatitjen e raporteve për të gjitha modifikimet e zbatuara dhe të refuzuara të versioneve të komponentëve të softuerit). + historia e modifikimeve

vlerësimi i konfigurimit (konsiston në vlerësimin e plotësisë funksionale të komponentëve të softuerit, si dhe përputhshmërinë e gjendjes së tyre fizike me përshkrimin teknik aktual);

menaxhimin e lirimit dhe furnizimin (mbulon prodhimin e kopjeve referuese të programeve dhe dokumentacionit, ruajtjen dhe dërgimin e tyre tek përdoruesit në përputhje me procedurën e miratuar në organizatë).

Sigurimi i cilësisë;

Procesi i Sigurimit të Cilësisë jep garancitë e duhura që softueri dhe proceset e ciklit të tij jetësor përputhen me kërkesat e specifikuara dhe planet e miratuara. Nën cilësinë e softuerit kuptohet si një grup karakteristikash që karakterizojnë aftësinë e softuerit për të përmbushur kërkesat e specifikuara.

Procesi i sigurimit të cilësisë përfshin aktivitetet e mëposhtme:

punë përgatitore

sigurimin e cilësisë së produktit që garanton përputhjen e plotë të produkteve softuerike dhe dokumentacionit të tyre me kërkesat e klientit të përcaktuara në kontratë;

sigurimi i cilësisë së procesit të përputhshmërisë së proceseve të ciklit jetësor të softuerit, metodave të zhvillimit, mjedisit të zhvillimit dhe kualifikimeve të personelit me kushtet e kontratës së vendosur duke siguruar tregues të tjerë të cilësisë së sistemit

Verifikimi; konsiston në përcaktimin se produktet softuerike plotësojnë plotësisht kërkesat ose kushtet e përcaktuara nga veprimet e mëparshme (verifikimi në kuptimin e ngushtë nënkupton prova formale të korrektësisë së softuerit).

punë përgatitore;

verifikimi;

Kushtet e mëposhtme kontrollohen gjatë procesit të verifikimit:

konsistenca e kërkesave për sistemin dhe shkalla në të cilën janë marrë parasysh nevojat e përdoruesve;

aftësia e furnizuesit për të përmbushur kërkesat e specifikuara;

pajtueshmërinë e proceseve të ciklit të jetës së zgjedhur me kushtet e kontratës;

përshtatshmëria e standardeve, procedurave dhe mjedisit të zhvillimit për procesin e ciklit jetësor të softuerit;

pajtueshmërinë e specifikimeve të dizajnit të softuerit me kërkesat e specifikuara;

korrektësia e përshkrimit në specifikimet e projektimit të të dhënave hyrëse dhe dalëse, sekuenca e ngjarjeve, ndërfaqet, logjika;

pajtueshmëria e kodit me specifikimet dhe kërkesat e projektimit;

testueshmëria dhe korrektësia e kodit, përputhshmëria e tij me standardet e pranuara të kodimit;

integrimi korrekt i komponentëve të softuerit në sistem;

përshtatshmërinë, plotësinë dhe konsistencën e dokumentacionit.

Certifikimi;

përfshin përcaktimin e plotësisë së përputhshmërisë së kërkesave të specifikuara dhe sistemit të krijuar ose produktit softuerik me qëllimin e tyre përfundimtar funksional. Certifikimi zakonisht nënkupton konfirmimin dhe vlerësimin e besueshmërisë së testimit të kryer. Rekomandohet që certifikimi të kryhet duke testuar në të gjitha situatat e mundshme dhe duke përdorur specialistë të pavarur.

Vlerësimi me pjesëmarrje(Analiza me pjesëmarrje); për të vlerësuar statusin e punës në projekt dhe softuer.

Vlerësimi zbatohet si në nivelin e menaxhimit të projektit ashtu edhe në nivelin e zbatimit teknik të projektit dhe kryhet gjatë gjithë kohëzgjatjes së kontratës. Ky proces mund të kryhet nga çdo dy palë të përfshira në kontratë, me njëra palë që verifikon tjetrën.

Procesi i vlerësimit me pjesëmarrje përfshin aktivitetet e mëposhtme:

punë përgatitore;

vlerësimi (analiza) e menaxhimit të projektit;

vlerësim teknik.

Auditimi;

përcaktimin e pajtueshmërisë me kërkesat, planet dhe kushtet e kontratës. Një auditim mund të kryhet nga çdo dy palë të përfshira në kontratë, ku njëra palë auditon tjetrën. Auditimi është një auditim (inspektim) i kryer nga një autoritet (person) kompetent për të siguruar vlerësim i pavarur shkalla e përputhshmërisë së softuerit ose proceseve me kërkesat e përcaktuara.

Leja(Zgjidhja) probleme.

përfshin analizën dhe zgjidhjen e problemeve (përfshirë mospërputhjet e zbuluara) pavarësisht nga origjina ose burimi i tyre, të cilat zbulohen gjatë zhvillimit, funksionimit, mirëmbajtjes ose proceseve të tjera. Çdo problem i zbuluar duhet të identifikohet, përshkruhet, analizohet dhe zgjidhet.

Koncepti i ciklit jetësor të softuerit (LC). Përkufizimi i ciklit jetësor sipas standardit ndërkombëtar ISO/IEC 12207:1995. Proceset organizative të ciklit jetësor të softuerit. Marrëdhënia ndërmjet proceseve të ciklit jetësor të softuerit.

Shih pikën 2

Proceset e ciklit jetësor organizativ :

Kontrolli;

përbëhet nga veprime ( punime të përgjithshme) dhe detyrat që mund të kryhen nga çdo palë që menaxhon burimet e saj. Kjo palë (menaxher) është përgjegjëse për menaxhimin e lëshimit të produktit, menaxhimin e projektit dhe menaxhimin e detyrave të proceseve të lidhura, të tilla si blerja, dorëzimi, zhvillimi, funksionimi, mirëmbajtja, etj. Për shembull, një administrator është përgjegjës për menaxhimin e projektit, shpërndarjen, zhvillimin, funksionimin, mirëmbajtjen, etj.

Procesi i menaxhimit përfshin veprimet e mëposhtme:

përgatitja dhe përcaktimi i fushës së menaxhimit . Menaxheri duhet të sigurojë që burimet e nevojshme për menaxhim (personeli, pajisjet dhe teknologjia) të jenë në dispozicion të tij në sasi të mjaftueshme;

planifikimi përfshin kryerjen e të paktën detyrave të mëposhtme:

hartimi i orarit të punës;

vlerësimi i kostos;

alokimi i burimeve të nevojshme;

shpërndarja e përgjegjësisë;

vlerësimin e rreziqeve që lidhen me detyra specifike;

krijimi i infrastrukturës së menaxhimit.

ekzekutimi dhe kontrolli;

verifikimi dhe vlerësimi;

përfundimi.

Krijimi i infrastrukturës;

mbulon përzgjedhjen dhe mbështetjen (mbështetje teknologjike), standardet dhe mjetet, përzgjedhjen dhe instalimin e harduerit dhe softuerit të përdorur për zhvillimin, funksionimin ose mirëmbajtjen e softuerit. Infrastruktura duhet të modifikohet dhe mirëmbahet në përputhje me ndryshimet në kërkesat për proceset përkatëse. Infrastruktura, nga ana tjetër, është një nga objektet e menaxhimit të konfigurimit.

Përmirësimi;

parashikon vlerësimin, matjen, kontrollin dhe përmirësimin e proceseve të ciklit jetësor të softuerit.

Arsimi.

mbulon trajnimin fillestar dhe zhvillimin e vazhdueshëm të stafit.

Marrëdhënia ndërmjet proceseve të ciklit jetësor të softuerit

Proceset e ciklit jetësor të softuerit, të rregulluara nga standardi ISO/IEC 12207, mund të përdoren nga organizata të ndryshme në projekte specifike në mënyra të ndryshme. Megjithatë, standardi ofron një grup bazë të marrëdhënieve ndërmjet proceseve nga këndvështrime të ndryshme (Fig. 1). Këto aspekte janë:

aspekti kontraktual;

aspekti i menaxhimit;

aspekti i funksionimit;

aspekti inxhinierik;

aspekti mbështetës.

NË aspekti kontraktual Klienti dhe furnizuesi hyjnë në një marrëdhënie kontraktuale dhe zbatojnë proceset e prokurimit dhe dorëzimit në përputhje me rrethanat. NË aspekti i menaxhimit klienti, furnizuesi, zhvilluesi, operatori, shërbimi mbështetës dhe palët e tjera të përfshira në ciklin jetësor të softuerit menaxhojnë ekzekutimin e proceseve të tyre. NË aspekti operacional operatori që operon sistemin ofron shërbimet e nevojshme për përdoruesit. NË aspekti inxhinierik një zhvillues ose shërbim mbështetës zgjidh problemet teknike përkatëse duke zhvilluar ose modifikuar produkte softuerike. NË aspekti mbështetës shërbimet që zbatojnë procese ndihmëse ofrojnë shërbimet e nevojshme për të gjithë pjesëmarrësit e tjerë në punë.

Marrëdhëniet ndërmjet proceseve të përshkruara në standard janë karakter statik . Më e rëndësishme lidhjet dinamike ndërmjet proceseve dhe palëve që i zbatojnë ato vendosen në projekte reale.

Koncepti i modelit dhe faza e ciklit jetësor të softuerit. Karakteristikat e fazave të krijimit të softuerit.

1) Standardi ndërkombëtar ISO/ IEC 12207: 1995 Kështu e përcakton modeli i ciklit jetësor:

Modeli i ciklit jetësor të softuerit kuptohet si një strukturë që përcakton sekuencën e ekzekutimit dhe marrëdhëniet e proceseve, veprimeve dhe detyrave gjatë gjithë ciklit jetësor. Modeli i ciklit jetësor varet nga specifikat, shkalla dhe kompleksiteti i projektit dhe kushtet specifike në të cilat sistemi është krijuar dhe funksionon.

2) GOST R ISO/IEC 12207-99 Kështu e përcakton modeli i ciklit jetësor:

Një model i ciklit jetësor është një strukturë e përbërë nga procese, punë dhe detyra, duke përfshirë zhvillimin, funksionimin dhe mirëmbajtjen e një produkti softuer, që mbulon jetën e një sistemi nga vendosja e kërkesave për të deri në fund të përdorimit të tij.

Nën fazë Krijimi i softuerit kuptohet si një pjesë e procesit të krijimit të softuerit, i kufizuar nga një kornizë kohore e caktuar dhe që përfundon me lëshimin e një produkti specifik (modele softuerësh, komponentë softuerësh, dokumentacion), të përcaktuar nga kërkesat e specifikuara për këtë fazë. Fazat e krijimit të softuerit dallohen për arsye të planifikimit dhe organizimit racional të punës që përfundon me rezultate të specifikuara.

Cikli i jetës së softuerit zakonisht përfshin stacionet e mëposhtme:

Formimi i kërkesave për softuer.

Dizajn.

Zbatimi.

Duke testuar.

Komisionimi.

Funksionimi dhe mirëmbajtja.

Dekomisionimi.

Koncepti i një modeli të ciklit jetësor të softuerit. Modeli ujëvarë (kaskadë) i ciklit jetësor të softuerit.

Shih pikën 5

Në IS origjinale homogjene, çdo aplikim ishte një tërësi e vetme. Për të zhvilluar këtë lloj aplikimi, u përdor metoda e ujëvarës. Karakteristika kryesore e tij është ndarja e të gjithë zhvillimit në faza, dhe kalimi nga një fazë në tjetrën ndodh vetëm pasi të ketë përfunduar plotësisht puna në atë aktuale (Fig. 2). Çdo fazë përfundon me lëshimin e një grupi të plotë dokumentacioni, të mjaftueshëm në mënyrë që zhvillimi të mund të vazhdojë nga një ekip specialistësh në fazën tjetër.

Përparësitë e përdorimit të metodës së kaskadës :

në çdo fazë, gjenerohet një grup i plotë i dokumentacionit të projektimit që plotëson kërkesat e plotësisë dhe konsistencës;

fazat e punës të kryera në një sekuencë logjike bëjnë të mundur planifikimin e kohës së përfundimit të të gjithë punës dhe kostot përkatëse.

Qasja e kaskadës është dëshmuar mirë në ndërtimin e sistemeve të informacionit, për të cilat, në fillim të zhvillimit, të gjitha kërkesat mund të formulohen mjaft saktë dhe plotësisht, në mënyrë që t'u ofrojë zhvilluesve lirinë për t'i zbatuar ato teknikisht sa më mirë që të jetë e mundur. .

Në të njëjtën kohë, kjo qasje ka një sërë disavantazhesh, të shkaktuara kryesisht nga fakti se procesi aktual i krijimit të softuerit nuk përshtatet kurrë plotësisht në një skemë kaq të ngurtë. Procesi i krijimit të softuerit është zakonisht natyrë përsëritëse : Rezultatet e fazës tjetër shpesh shkaktojnë ndryshime në zgjidhjet e projektimit të zhvilluara në fazat e mëparshme. Kështu, ekziston një nevojë e vazhdueshme për t'u kthyer në fazat e mëparshme dhe për të qartësuar ose rishikuar vendimet e marra më parë. Si rezultat, procesi real i krijimit të softuerit merr një formë tjetër (Fig. 2).

Vonesa e konsiderueshme në marrjen e rezultateve. Koordinimi i rezultateve me përdoruesit kryhet vetëm në pikat e planifikuara pas përfundimit të secilës fazë të punës; kërkesat për IS janë "ngrirë" në formën e specifikimeve teknike për të gjithë kohën e krijimit të tij. Kështu, përdoruesit mund të bëjnë komentet e tyre vetëm pasi të ketë përfunduar plotësisht puna në sistem. Nëse kërkesat janë deklaruar në mënyrë të pasaktë ose ato ndryshojnë gjatë një periudhe të gjatë të zhvillimit të softuerit, përdoruesit përfundojnë me një sistem që nuk i plotëson nevojat e tyre. Modelet (si funksionale ashtu edhe ato informative) të objektit të automatizuar mund të bëhen të vjetëruara njëkohësisht me miratimin e tyre.

Koncepti i një modeli të ciklit jetësor të softuerit.Modeli i zhvillimit të shpejtë të aplikacioneve. Shih paragrafin 5

Një nga qasjet e mundshme për zhvillimin e softuerit aplikativ brenda kornizës së modelit të ciklit jetësor spirale është metoda e përdorur gjerësisht e të ashtuquajturës zhvillimi i shpejtë i aplikacioneve, ose RAD (Rapid Application Development). RAD ka tre komponentë:

grupe të vogla zhvilluesish (3-7 persona) që kryejnë punë në hartimin e nënsistemeve individuale të softuerit. Kjo është për shkak të kërkesës për kontrollueshmëri maksimale të ekipit;

orar i shkurtër, por i përpunuar me kujdes i prodhimit (deri në 3 muaj);

një cikël përsëritës në të cilin zhvilluesit, kur aplikacioni fillon të marrë formë, kërkojnë dhe zbatojnë në produkt kërkesat e marra nga ndërveprimi me klientin.

Ekipi i zhvillimit duhet të jetë një grup profesionistësh me përvojë në dizajnimin, programimin dhe testimin e softuerit, të aftë për të ndërvepruar mirë me përdoruesin përfundimtar dhe për të transformuar propozimet e tyre në prototipe pune.

Dallohen këto: fazat e procesit të zhvillimit të RAD :

Modelimi i biznesit . Rrjedhat e informacionit ndërmjet funksioneve të biznesit janë modeluar.

Modelimi i të dhënave . Rrjedha e informacionit hartuar në një grup objektesh të dhënash.

Simulimi i përpunimit . Transformimet e objekteve të të dhënave janë përcaktuar për të siguruar zbatimin e funksioneve të biznesit.

Gjenerimi i aplikacionit . Gjuhët e programimit të gjeneratës së 4-të dhe komponentët e gatshëm përdoren për të ndërtuar mjetin e automatizimit.

Testimi dhe bashkimi . Përdorimi i komponentëve të ripërdorshëm redukton kohën e testimit.

Çdo funksion kryesor zhvillohet nga një grup i veçantë zhvilluesish paralelisht për jo më shumë se 3 muaj, dhe më pas ato integrohen në të gjithë sistemin.

Disavantazhet e përdorimit RAD :

Projektet e mëdha kërkojnë burime të rëndësishme njerëzore për të krijuar ekipe.

Modeli është i zbatueshëm vetëm për ato sisteme që mund të zbërthehen në module të veçanta dhe në të cilat performanca nuk është një vlerë kritike.

I pazbatueshëm në kushtet e rreziqeve të larta teknike, d.m.th. kur përdorni teknologjinë e re.

Koncepti i një modeli të ciklit jetësor të softuerit. Modeli i ciklit jetësor të softuerit në formë V.

Modeli i ciklit jetësor në formë V u krijua për të ndihmuar ekipin e projektit në planifikimin për të siguruar testimin e mëtejshëm të sistemit. Ky model vë theks të veçantë në aktivitetet që synojnë verifikimin dhe vërtetimin e produktit. Ai tregon se testimi i produktit diskutohet, projektohet dhe planifikohet në fillim të ciklit jetësor të zhvillimit.

Një plan testimi i pranimit të klientit zhvillohet gjatë fazës së planifikimit dhe një plan testimi i paraqitjes së sistemit zhvillohet gjatë fazave të analizës, zhvillimit të projektimit, etj. Ky proces i zhvillimit të planeve të testimit tregohet nga vija me pika midis drejtkëndëshave të modelit në formë V.

Modeli në formë V u zhvillua si një variant i modelit të kaskadës, dhe për këtë arsye trashëgoi të njëjtën strukturë vijuese prej tij. Çdo fazë pasuese fillon me përfundimin e marrjes së rezultateve të fazës së mëparshme.

Modeli demonstron Një qasje komplekse për përcaktimin e fazave të procesit të zhvillimit të softuerit. Ai nënvizon marrëdhëniet që ekzistojnë midis fazave analitike dhe të projektimit që i paraprijnë kodimit, të ndjekura nga fazat e testimit. Vijat me pika tregojnë se këto faza duhet të konsiderohen paralelisht.

Oriz. . Modeli i ciklit V të jetës

E dhënë më poshtë Përshkrim i shkurtërçdo fazë e modelit V, nga planifikimi i projektit dhe kërkesat deri te testimi i pranimit:

planifikimi i projektit dhe kërkesave – përcaktohen kërkesat e sistemit, si dhe si do të ndahen burimet e organizatës për të përmbushur kërkesat (nëse është e nevojshme, në këtë fazë përcaktohen funksionet për harduerin dhe softuerin);

analiza e kërkesave dhe specifikimeve të produktit – analiza e problemit ekzistues të softuerit përfundon me një specifikim të plotë të sjelljes së jashtme të pritshme të sistemit të krijuar softuerik;

arkitekturë apo dizajn në nivelin më të lartë – përcakton se si duhet të përdoren funksionet e softuerit në zbatimin e projektit;

zhvillimi i detajuar i projektit – përcakton dhe dokumenton algoritmet për çdo komponent që është përcaktuar gjatë fazës së arkitekturës. Këto algoritme më vonë do të shndërrohen në kod;

zhvillimi i kodit të programit – algoritmet e përcaktuara në fazën e projektimit të detajuar shndërrohen në softuer të përfunduar;

testimi i njësisë – çdo modul i koduar kontrollohet për gabime;

integrimin dhe testimin – vendosja e marrëdhënieve ndërmjet grupeve të moduleve të testuara më parë element pas elementi, në mënyrë që të konfirmohet se këto grupe funksionojnë si dhe modulet e testuara në mënyrë të pavarur nga njëri-tjetri në fazën e testimit element pas elementi;

testimi i sistemit dhe pranimit – kontrollohet funksionimi i sistemit softuerik në tërësi (sistemi plotësisht i integruar), pasi vendoset në mjedisin e tij harduerik në përputhje me specifikimin e kërkesave softuerike;

prodhimit, funksionimit dhe mirëmbajtjes – softueri vihet në prodhim. Kjo fazë përfshin gjithashtu modernizimin dhe ndryshimet;

testet e pranimit (nuk tregohet në figurë) - lejon përdoruesin të testojë funksionalitetin e sistemit për pajtueshmërinë me kërkesat fillestare. Pas testimit përfundimtar, softueri dhe pajisja përreth bëhen funksionale. Pas kësaj, sigurohet mirëmbajtja e sistemit.

Përparësitë:

Modeli vë theks të veçantë në planifikimin që synon verifikimin dhe certifikimin e produktit në zhvillim në fazat e hershme të zhvillimit të tij. Faza e testimit të njësisë vërteton dizajnin e detajuar. Fazat e integrimit dhe testimit zbatojnë dizajnin ose dizajnin arkitekturor në nivelin më të lartë. Faza e testimit të sistemit konfirmon që faza e kërkesave të produktit dhe specifikimet e tij janë plotësuar saktë;

modeli parashikon certifikimin dhe verifikimin e të gjitha të dhënave të jashtme dhe të brendshme të marra, dhe jo vetëm të vetë produktit softuer;

në modelin V, përcaktimi i kërkesave kryhet përpara dizajnimit të sistemit, dhe dizajni i softuerit përpara zhvillimit të komponentëve;

modeli përcakton produktet që duhet të merren si rezultat i procesit të zhvillimit dhe secila e dhënë e marrë duhet të testohet;

falë modelit, menaxherët e projektit mund të ndjekin ecurinë e procesit të zhvillimit, pasi në këtë rast është mjaft e mundur të përdoret një afat kohor, dhe përfundimi i secilës fazë është një moment historik;

Modeli është i lehtë për t'u përdorur (në lidhje me projektin për të cilin është i përshtatshëm).

të metat:

me ndihmën e saj nuk është e lehtë të përballesh me ngjarje paralele;

nuk merr parasysh përsëritjet ndërmjet fazave;

modeli nuk parashikon paraqitjen e kërkesave për ndryshime dinamike në faza të ndryshme të ciklit jetësor;

testimi i kërkesave në ciklin e jetës ndodh shumë vonë, si rezultat i të cilit është e pamundur të bëhen ndryshime pa ndikuar në orarin e projektit;

Modeli nuk përfshin veprime që synojnë analizën e rrezikut.

Për të kapërcyer këto mangësi, modeli në formë V mund të modifikohet për të përfshirë sythe përsëritëse të dizajnuara për të zgjidhur ndryshimet në kërkesat jashtë fazës së analizës.

Ashtu si paraardhësi i tij, modeli i ujëvarës, modeli në formë V funksionon më mirë kur të gjitha informacionet e kërkesave janë të disponueshme paraprakisht. Një modifikim i zakonshëm i modelit V për të kapërcyer mangësitë e tij përfshin futjen e cikleve përsëritëse për të zgjidhur ndryshimet në kërkesat jashtë fazës së analizës.

Përdorimi i modelit është efektiv kur informacioni për metodën e zbatimit të zgjidhjes dhe teknologjinë disponohet, dhe stafi ka aftësitë dhe përvojën e nevojshme për të punuar me këtë teknologji.

Modeli në formë V është një zgjedhje e shkëlqyer për sistemet që kërkojnë besueshmëri të lartë, të tilla si aplikacionet e monitorimit klinik të pacientëve dhe softueri i integruar për kontrollet e airbagëve të automobilave.

Koncepti i një modeli të ciklit jetësor të softuerit. Modeli spirale i Boehm-it i ciklit jetësor të softuerit.

Modeli spirale - një shembull klasik i aplikimit të një strategjie të projektimit evolucionar. Modeli spirale (nga Barry Boehm, 1988) bazohet në vetitë më të mira të ciklit klasik të jetës dhe prototipit, të cilit i shtohet një element i ri - analiza e rrezikut, e cila më parë mungonte.

Siç tregohet në Fig. 3, modeli përcakton katër veprime, të përfaqësuara nga katër kuadrantet e spirales:

Planifikimi - përcaktimi i qëllimeve, opsioneve dhe kufizimeve.

Analiza e riskut - analiza e opsioneve dhe njohja/zgjedhja e riskut.

Dizajn - zhvillimi i një produkti të nivelit tjetër.

Vlerësimi - vlerësimi i klientit për rezultatet aktuale të projektimit.

Aspekti integrues i modelit spirale është i dukshëm kur merret parasysh dimensioni radial i spirales. Me çdo përsëritje në një spirale (duke lëvizur nga qendra në periferi), gjithnjë e më shumë versionet e plota NGA.

Procesi i menaxhimit konfigurimi përfshin procedura administrative dhe teknike gjatë gjithë ciklit jetësor të softuerit për të përcaktuar statusin e komponentëve të softuerit, për të përshkruar dhe përgatitur raporte mbi statusin e komponentëve të softuerit dhe kërkesat për modifikim, për të siguruar plotësinë, përputhshmërinë dhe korrektësinë e komponentëve të softuerit, për të menaxhuar ruajtjen dhe shpërndarjen e software.

Sipas standardit IEEE-90, konfigurimi i softuerit kuptohet si tërësia e karakteristikave të tij funksionale dhe fizike të vendosura në dokumentacionin teknik dhe të zbatuara në softuer. Menaxhimi i konfigurimit ju lejon të organizoni, merrni parasysh dhe kontrolloni në mënyrë sistematike futjen e ndryshimeve në softuer në të gjitha fazat e ciklit jetësor. Parimet dhe rekomandimet e përgjithshme për menaxhimin e konfigurimit të softuerit pasqyrohen në standardin ISO/IEC 15288 "Teknologjia e informacionit. Procesi i ciklit të jetës së softuerit. Menaxhimi i konfigurimit për softuerin".

Procesi i menaxhimit konfigurimi përfshin hapat e mëposhtëm:

1. puna përgatitore e menaxhimit të konfigurimit të planifikimit;
2. identifikimi i konfigurimit, i cili vendos rregulla me të cilat komponentët e softuerit dhe versionet e tyre identifikohen në mënyrë unike. Në këtë rast, çdo komponent korrespondon në mënyrë unike me një grup dokumentesh;
3. kontrolli i konfigurimit është një veprim i destinuar për vlerësimin sistematik të modifikimeve të propozuara të softuerit dhe zbatimin e tyre të koordinuar, duke marrë parasysh efektivitetin e çdo modifikimi dhe kostot e zbatimit të tij;
4. kontabiliteti i statusit të konfigurimit, i cili është një regjistrim i gjendjes së komponentëve të softuerit. Ofron përgatitjen e raporteve për modifikimet e zbatuara dhe të refuzuara të versioneve të komponentëve të softuerit. Një grup raportesh ofron një pasqyrim të qartë të gjendjes aktuale të sistemit dhe komponentëve të tij, dhe gjithashtu ofron një histori modifikimesh;
5. vlerësimi i konfigurimit, i cili konsiston në përcaktimin plotësia funksionale komponentët e softuerit, si dhe përputhshmëria e gjendjes së tyre fizike me përshkrimin teknik aktual;
6. menaxhimin dhe dorëzimin e lëshimit, i cili mbulon prodhimin e kopjeve kryesore të programeve dhe dokumentacionit, ruajtjen e tyre dhe dërgimin te përdoruesit në përputhje me procedurat organizative.

Procesi i sigurimit Sigurimi i cilësisë duhet të sigurojë që softueri dhe proceset e ciklit të tij jetësor përputhen me kërkesat e specifikuara dhe planet e miratuara. Cilësia e softuerit kuptohet si një grup karakteristikash që karakterizojnë aftësinë e softuerit për të përmbushur kërkesat e specifikuara. Për të marrë vlerësime të besueshme rreth softuerit që po krijohet procesi i ofrimit cilësia e tij duhet të ndodhë në mënyrë të pavarur nga subjektet që lidhen drejtpërdrejt me zhvillimin e produktit softuer. Kjo mund të përdorë rezultatet e proceseve të tjera mbështetëse si verifikimi, vlefshmëria, vlerësimi i përbashkët, auditimi dhe zgjidhja e problemit.

Procesi i sigurimit cilësia përfshin veprimet e mëposhtme:

1. punë përgatitore (koordinimi me proceset e tjera mbështetëse dhe planifikimi i vetë procesit të sigurimit të cilësisë së softuerit, duke marrë parasysh standardet, metodat, procedurat dhe mjetet e përdorura);
2. sigurimin e cilësisë së produktit, që nënkupton përputhshmëri të plotë të garantuar të softuerit dhe dokumentacionit të tij me kërkesat e klientit të përcaktuara në kontratë;
3. sigurimin e cilësisë së procesit, që nënkupton përputhshmërinë e garantuar të proceseve të ciklit jetësor të softuerit, metodave të zhvillimit, mjedisit të zhvillimit dhe kualifikimeve të personelit me kushtet e kontratës, standardet dhe procedurat e vendosura;
4. sigurimin e treguesve të tjerë të cilësisë së softuerit, të kryer në përputhje me kushtet e kontratës dhe standardin e cilësisë ISO 9001.

Procesi i verifikimit konsiston në përcaktimin që softueri që rezulton nga një aktivitet i caktuar plotëson plotësisht kërkesat ose kushtet e vendosura nga aktivitetet e mëparshme. Për të përmirësuar efikasitetin e të gjithë procesit të ciklit jetësor të softuerit, verifikimi duhet të integrohet sa më shpejt që të jetë e mundur me proceset që e përdorin atë (d.m.th., dorëzimi, zhvillimi, funksionimi). Procesi i verifikimit mund të përfshijë analizën, vlerësimin dhe testimin.

Verifikimi mund të kryhet me shkallë të ndryshme pavarësie (nga vetë interpretuesi deri te specialistë nga një organizatë tjetër e pavarur nga furnizuesi, zhvilluesi, etj.). Gjatë procesit të verifikimit, kontrollohen kushtet e mëposhtme:

1. konsistenca e kërkesave për sistemin dhe shkalla në të cilën janë marrë parasysh nevojat e përdoruesve;
2. aftësia e furnizuesit për të përmbushur kërkesat e specifikuara;
3. pajtueshmërinë e proceseve të ciklit të jetës së zgjedhur me kushtet e kontratës;
4. përshtatshmëria e standardeve, procedurave dhe mjedisit të zhvillimit me proceset e ciklit jetësor të softuerit;
5. pajtueshmërinë e specifikimeve të dizajnit të softuerit me kërkesat e specifikuara;
6. korrektësia e përshkrimit në specifikimet e projektimit të të dhënave hyrëse dhe dalëse, sekuenca e ngjarjeve, ndërfaqet, logjika, etj.;
7. pajtueshmëria e kodit me specifikimet dhe kërkesat e projektimit;
8. testueshmëria dhe korrektësia e kodit, përputhshmëria e tij me standardet e pranuara të kodimit;
9. integrimi korrekt i komponentëve të softuerit në sistem;
10. përshtatshmërinë, plotësinë dhe konsistencën e dokumentacionit.

Procesi i certifikimit synon të përcaktojë plotësinë e përputhshmërisë së kërkesave të specifikuara dhe softuerit të krijuar me qëllimin e tyre specifik funksional (ajo që kërkohet nga konsumatori). Certifikimi zakonisht i referohet konfirmimit dhe vlerësimit të besueshmërisë së testimit të një produkti softuer. Certifikimi duhet të sigurojë përputhjen e plotë të softuerit me specifikimet, kërkesat dhe dokumentacionin, si dhe mundësinë e përdorimit të sigurt dhe të besueshëm të softuerit nga përdoruesi.

Certifikimi, si verifikimi, mund të kryhet me shkallë të ndryshme pavarësie (deri në një organizatë të pavarur nga furnizuesi, zhvilluesi, operatori ose shërbimi mbështetës).

Procesi i vlerësimit bashkëpunues synon të vlerësojë statusin e punës së projektit dhe produktit softuer të krijuar gjatë zbatimit të kësaj pune. Ai fokusohet kryesisht në kontrollin e planifikimit dhe menaxhimit të burimeve të projektit, personelit, pajisjeve dhe mjeteve.

Vlerësimi zbatohet si në nivelin e menaxhimit të projektit ashtu edhe në nivelin e zbatimit teknik të projektit dhe kryhet gjatë gjithë kohëzgjatjes së kontratës. Ky proces mund të kryhet nga dy palë të përfshira në kontratë, ku njëra palë verifikon tjetrën.

Procesi i auditimit është një përcaktim i konformitetit të projektit dhe produktit me kërkesat, planet dhe kushtet e kontratës. Një auditim mund të kryhet nga çdo dy palë të përfshira në kontratë, ku njëra palë auditon tjetrën.

Një auditim është një auditim (verifikim) i kryer nga një autoritet (person) kompetent për të siguruar një vlerësim të pavarur të shkallës së përputhshmërisë së softuerit ose proceseve me kërkesat e përcaktuara.

Auditimi shërben për të përcaktuar nëse puna dhe raportet aktuale janë në përputhje me kërkesat, planet dhe kontratën. Auditorët nuk duhet të kenë varësi të drejtpërdrejtë nga zhvilluesit e softuerit. Ato përcaktojnë statusin e punës, përdorimin e burimeve, përputhjen e dokumentacionit me specifikimet dhe standardet, korrektësinë e testimit etj.

Procesi i zgjidhjes së problemit përfshin analizimin dhe zgjidhjen e problemeve (duke përfshirë mospërputhjet e identifikuara) që zbulohen gjatë zhvillimit, operacioneve ose proceseve të tjera, pavarësisht nga origjina ose burimi i tyre.

5.4. Proceset organizative të ciklit jetësor të softuerit

Procesi i menaxhimit përbëhet nga aktivitete dhe detyra që mund të kryhen nga çdo palë që menaxhon proceset e saj. Kjo anë(menaxheri) është përgjegjës për menaxhimin e lëshimit të produktit,

Struktura e ciklit jetësor të softuerit në përputhje me standardin ISO/IEC 12207 bazohet në tre grupe procesesh (Fig. 1):

· proceset kryesore të ciklit jetësor të softuerit (blerja, shpërndarja, zhvillimi, funksionimi, mbështetja);

· procese ndihmëse që sigurojnë zbatimin e proceseve kryesore (dokumentimi, menaxhimi i konfigurimit, sigurimi i cilësisë, verifikimi, certifikimi, vlerësimi, auditimi, zgjidhja e problemeve);

· proceset organizative (menaxhimi i projektit, krijimi i infrastrukturës së projektit, përcaktimi, vlerësimi dhe përmirësimi i vetë ciklit jetësor, trajnimi).

Oriz. 1. Proceset e ciklit jetësor të softuerit.

Procesi i blerjes(procesi i blerjes). Ai përbëhet nga veprime

dhe detyrat e klientit që blen softuerin. Ky proces mbulon hapat e mëposhtëm:

1) fillimi i blerjes;

2) përgatitja e propozimeve të ofertave;

3) përgatitja dhe rregullimi i kontratës;

4) mbikëqyrja e aktiviteteve të furnizuesit;

5) pranimi dhe përfundimi i punës.

Procesi i dorëzimit(procesi i furnizimit). Ai mbulon aktivitetet dhe detyrat e kryera nga shitësi që furnizon klientin me një produkt ose shërbim softuerësh. Ky proces përfshin hapat e mëposhtëm:

1) fillimi i dorëzimit;

2) përgatitja e përgjigjes për propozimet e ofertave;

3) përgatitja e kontratës;

4) planifikimi;

5) ekzekutimi dhe kontrolli;

6) inspektimi dhe vlerësimi;

7) dorëzimi dhe përfundimi i punës.

Procesi i zhvillimit(procesi i zhvillimit). Ai parashikon veprimet dhe detyrat e kryera nga zhvilluesi dhe mbulon krijimin e softuerit dhe përbërësve të tij në përputhje me kërkesat e specifikuara, duke përfshirë përgatitjen e dokumentacionit të projektimit dhe operacional, përgatitjen e materialeve të nevojshme për testimin e funksionalitetit dhe cilësisë së duhur të softuerit. produkte, materiale të nevojshme për organizimin e personelit të trajnimit, etj.

Procesi i zhvillimit përfshin hapat e mëposhtëm:

1) analiza e kërkesave të sistemit;

2) projektimi i arkitekturës së sistemit;

3) analiza e kërkesave për softuer;

4) dizajni i arkitekturës së softuerit;

5) dizajn i detajuar i softuerit;

6) kodimi dhe testimi i softuerit;

7) integrimi i softuerit;

8) testimi i kualifikimit të softuerit;

9) integrimi i sistemit;

10) testimin kualifikues të sistemit;

11) instalimi i softuerit;

12) pranimi i softuerit.

Procesi i funksionimit(procesi i funksionimit). Ai mbulon veprimet dhe detyrat e operatorit - organizatës që operon sistemin. Ky proces përfshin hapat e mëposhtëm:

1) testimi operacional;

2) funksionimin e sistemit;

3) mbështetje për përdoruesit.

Procesi i mirëmbajtjes(procesi i mirëmbajtjes). Ai parashikon veprimet dhe detyrat e kryera nga organizata shoqëruese (shërbimi i shoqërimit). Ky proces aktivizohet kur ndryshimet (modifikimet) e produktit softuerik dhe dokumentacionit përkatës shkaktohen nga probleme ose nevoja për modernizim ose përshtatje të softuerit. Në përputhje me standardin IEEE-90, mirëmbajtja i referohet bërjes së ndryshimeve në softuer me qëllim korrigjimin e gabimeve, përmirësimin e performancës ose përshtatjen me kushtet e ndryshuara të funksionimit ose

Kërkesat. Ndryshimet e bëra në softuerin ekzistues nuk duhet të shkelin

integritetin e saj. Procesi i mirëmbajtjes përfshin transferimin e softuerit në një mjedis tjetër (migrim) dhe përfundon me çmontimin e softuerit.

Procesi i mirëmbajtjes përfshin veprimet e mëposhtme:

1) analiza e problemeve dhe kërkesave për modifikim të softuerit;

2) modifikimi i softuerit;

3) inspektimi dhe pranimi;

4) transferimi i softuerit në një mjedis tjetër;

5) çmontimi i softuerit.

Grupi i proceseve ndihmëse përfshin:

Dokumentacioni;

Menaxhimi i konfigurimit; sigurimi i cilësisë;

Verifikimi; certifikim;

Vlerësimi me pjesëmarrje;

Zgjidhja e problemit.

Procesi i dokumentimit(procesi i dokumentimit). Ai ofron një përshkrim të formalizuar të informacionit të krijuar gjatë ciklit jetësor të softuerit. Procesi i dokumentimit përfshin hapat e mëposhtëm:

1) projektimi dhe zhvillimi;

2) lëshimi i dokumentacionit;

3) mbështetje dokumentacioni.

Procesi i menaxhimit të konfigurimit(procesi i menaxhimit të konfigurimit). Ai përfshin përdorimin e procedurave administrative dhe teknike gjatë gjithë ciklit jetësor të softuerit për të përcaktuar statusin e komponentëve të softuerit në sistem, për të menaxhuar modifikimet e softuerit, për të përshkruar dhe përgatitur raporte mbi statusin e komponentëve të softuerit dhe kërkesat për modifikim, për të siguruar plotësinë, përputhshmërinë dhe korrektësinë. e komponentëve të softuerit, menaxhoni ruajtjen dhe shpërndarjen NGA. Sipas standardit IEEE-90, konfigurimi i softuerit kuptohet si tërësia e karakteristikave të tij funksionale dhe fizike.

karakteristikat e përcaktuara në dokumentacionin teknik dhe të implementuara në softuer.

Menaxhimi i konfigurimit ju lejon të organizoni, merrni parasysh dhe kontrolloni në mënyrë sistematike ndryshimet në softuer në të gjitha fazat e ciklit jetësor. Parimet e përgjithshme dhe rekomandimet për menaxhimin e konfigurimit të softuerit janë pasqyruar në draft standardin ISO/I EC CD 12207-2: 1995 "Teknologjia e Informacionit - Proceset e Ciklit të Jetës së Softuerit. Pjesa 2.

Menaxhimi i konfigurimit për softuerin". Procesi i menaxhimit të konfigurimit përfshin veprimet e mëposhtme:

1) identifikimi i konfigurimit;

2) kontrolli i konfigurimit;

3) llogaritja e statusit të konfigurimit;

4) vlerësimi i konfigurimit;

5) menaxhimi dhe dorëzimi i lëshimit.

Procesi i Sigurimit të Cilësisë(procesi i sigurimit të cilësisë). Ai ofron sigurinë e duhur që softueri dhe proceset e ciklit të tij jetësor përputhen me kërkesat e specifikuara dhe planet e miratuara. Cilësia e softuerit kuptohet si një grup karakteristikash që karakterizojnë aftësinë e softuerit për të përmbushur kërkesat e specifikuara. Për të marrë vlerësime të besueshme të softuerit që krijohet, procesi i sigurimit të cilësisë së tij duhet të ndodhë pavarësisht nga subjektet që lidhen drejtpërdrejt me zhvillimin e softuerit. Mund të përdoren rezultatet e proceseve të tjera mbështetëse si verifikimi, vlefshmëria, vlerësimi i përbashkët, auditimi dhe zgjidhja e problemit. Procesi i sigurimit të cilësisë përfshin aktivitetet e mëposhtme:

1) sigurimi i cilësisë së produktit;

2) sigurimin e cilësisë së procesit;

3) sigurimin e treguesve të tjerë të cilësisë së sistemit.

Procesi i verifikimit(procesi i verifikimit). Ai konsiston në përcaktimin që produktet softuerike që janë rezultat i disa veprimeve plotësojnë plotësisht kërkesat ose kushtet e përcaktuara nga veprimet e mëparshme (verifikimi në kuptimin e ngushtë nënkupton prova formale të korrektësisë së softuerit).

Procesi i certifikimit(procesi i vërtetimit). Ai përfshin përcaktimin e plotësisë së përputhshmërisë së kërkesave të specifikuara dhe sistemit të krijuar ose produktit softuerik me qëllimin e tyre specifik funksional. Certifikimi zakonisht i referohet konfirmimit dhe vlerësimit të besueshmërisë së testimit të softuerit.

Procesi i vlerësimit me pjesëmarrje(procesi i rishikimit të përbashkët). Ai synon të vlerësojë statusin e punës në projekt dhe softuerin e krijuar gjatë ekzekutimit të këtyre punimeve (veprimeve). Ai fokusohet kryesisht në kontrollin e planifikimit dhe menaxhimit të burimeve të projektit, personelit, pajisjeve dhe mjeteve.

Procesi i auditimit(procesi i auditimit). Është një përcaktim i pajtueshmërisë me kërkesat, planet dhe kushtet e kontratës.

Procesi i zgjidhjes së problemit(procesi i zgjidhjes së problemit). Ai përfshin analizën dhe zgjidhjen e problemeve (përfshirë mospërputhjet e zbuluara) pavarësisht nga origjina ose burimi i tyre, të cilat zbulohen gjatë zhvillimit, funksionimit, mirëmbajtjes ose proceseve të tjera. Çdo problem i zbuluar duhet të identifikohet, përshkruhet, analizohet dhe zgjidhet.

Grupi i proceseve organizative të ciklit jetësor të softuerit përfshin:

Kontrolli;

Krijimi i infrastrukturës;

Përmirësimi;

Lëshimi i versioneve të reja;

Arsimi.

Procesi i menaxhimit(procesi i menaxhimit). Ai përbëhet nga aktivitete dhe detyra që mund të kryhen nga çdo palë që menaxhon proceset e tyre. Kjo palë (menaxher) është përgjegjëse për menaxhimin e lëshimit të produktit, menaxhimin e projektit dhe menaxhimin e detyrave të proceseve të lidhura, të tilla si blerja, dorëzimi, zhvillimi, funksionimi, mirëmbajtja, etj.

Procesi i krijimit të infrastrukturës(procesi i infrastrukturës). Ai mbulon zgjedhjen dhe mbështetjen (mirëmbajtjen) e teknologjisë, standardeve dhe mjeteve, përzgjedhjen dhe instalimin e harduerit dhe softuerit të përdorur për zhvillimin, funksionimin ose mirëmbajtjen e softuerit. Infrastruktura duhet të modifikohet dhe mirëmbahet në përputhje me ndryshimet në kërkesat për proceset përkatëse. Infrastruktura, nga ana tjetër, është një nga objektet e menaxhimit të konfigurimit.

Procesi i përmirësimit(procesi i përmirësimit). Ai parashikon vlerësimin, matjen, kontrollin dhe përmirësimin e proceseve të ciklit jetësor të softuerit. Përmirësimi i proceseve të ciklit jetësor të softuerit synon rritjen e produktivitetit të të gjithë specialistëve të përfshirë në to duke përmirësuar teknologjinë e përdorur, metodat e menaxhimit, përzgjedhjen e mjeteve dhe trajnimin.

personelit.

Procesi mësimor(procesi i trajnimit). Ai mbulon trajnimin fillestar dhe zhvillimin e vazhdueshëm të stafit.