Duhet të fillojmë duke përcaktuarCikli i jetës së softuerit(Modeli i Ciklit të Jetës së Softuerit) është një periudhë kohore që fillon nga momenti kur merret vendimi për të krijuar një produkt softuer dhe përfundon në momentin që ai tërhiqet plotësisht nga shërbimi. Ky cikël është procesi i ndërtimit dhe zhvillimit të softuerit.
Modelet e ciklit jetësor të softuerit
Cikli i jetës mund të përfaqësohet në formën e modeleve. Aktualisht më të zakonshmet janë:kaskadë, në rritje (model me skenë me kontroll të ndërmjetëm ) dhe spiralemodelet e ciklit jetësor.
Modeli i kaskadës
Modeli i kaskadës(eng. modeli i ujëvarës) është një model i procesit të zhvillimit të softuerit, cikli jetësor i të cilit duket si një rrjedhë që kalon në mënyrë sekuenciale nëpër fazat e analizës së kërkesave, projektimit. zbatimin, testimin, integrimin dhe mbështetjen.
Procesi i zhvillimit zbatohet duke përdorur një sekuencë të urdhëruar hapash të pavarur. Modeli parashikon që çdo hap pasues të fillojë pas përfundimit të hapit të mëparshëm. Në të gjitha hapat e modelit kryhen procese dhe punë ndihmëse dhe organizative, duke përfshirë menaxhimin e projektit, vlerësimin dhe menaxhimin e cilësisë, verifikimin dhe certifikimin, menaxhimin e konfigurimit dhe zhvillimin e dokumentacionit. Si rezultat i përfundimit të hapave, formohen produkte të ndërmjetme që nuk mund të ndryshohen në hapat pasues.
Cikli i jetës tradicionalisht ndahet në kryesoret e mëposhtmefazat:
- Analiza e kërkesave,
- Dizajn,
- Kodimi (programimi),
- Testimi dhe korrigjimi,
- Funksionimi dhe mirëmbajtja.
Avantazhet e modelit:
- stabiliteti i kërkesave gjatë gjithë ciklit jetësor të zhvillimit;
- në çdo fazë, formohet një grup i plotë i dokumentacionit të projektit që plotëson kriteret për plotësinë dhe konsistencën;
- siguria dhe kuptueshmëria e hapave të modelit dhe thjeshtësia e zbatimit të tij;
- fazat e punës së kryer në një sekuencë logjike ju lejojnë të planifikoni kohën e përfundimit të të gjithë punës dhe burimet përkatëse (monetare, materiale dhe njerëzore).
Disavantazhet e modelit:
- kompleksiteti i formulimit të qartë të kërkesave dhe pamundësia e ndryshimit dinamik të tyre gjatë ciklit të plotë të jetës;
- fleksibilitet i ulët në menaxhimin e projektit;
- sekuenca e strukturës lineare të procesit të zhvillimit, si rezultat, kthimi në hapat e mëparshëm për zgjidhjen e problemeve të shfaqura çon në një rritje të kostove dhe prishje të orarit të punës;
- papërshtatshmëria e produktit të ndërmjetëm për përdorim;
- pamundësia e modelimit fleksibël të sistemeve unike;
- zbulimi i vonshëm i problemeve të lidhura me ndërtimin për shkak të integrimit të njëkohshëm të të gjitha rezultateve në fund të zhvillimit;
- pjesëmarrja e pamjaftueshme e përdoruesve në krijimin e sistemit - në fillim (gjatë zhvillimit të kërkesave) dhe në fund (gjatë testeve të pranimit);
- përdoruesit nuk mund të binden për cilësinë e produktit të zhvilluar deri në fund të të gjithë procesit të zhvillimit. Ata nuk kanë mundësi të vlerësojnë cilësinë, sepse nuk mund të shohin produktin e përfunduar të zhvillimit;
- përdoruesi nuk ka mundësi të mësohet gradualisht me sistemin. Procesi i mësimit ndodh në fund të ciklit jetësor, kur softueri është vënë tashmë në funksion;
- çdo fazë është një parakusht për ekzekutimin e veprimeve të mëvonshme, gjë që e bën një metodë të tillë një zgjedhje të rrezikshme për sistemet që nuk kanë analoge, sepse. nuk i përshtatet modelimit fleksibël.
Është e vështirë të zbatohet Modeli i Ciklit të Jetës së Ujëvarës për shkak të kompleksitetit të zhvillimit të PS pa u kthyer në hapat e mëparshëm dhe pa ndryshuar rezultatet e tyre për të eliminuar problemet e shfaqura.
Fusha e modelit të kaskadës
Kufizimi i shtrirjes së modelit të kaskadës përcaktohet nga të metat e tij. Përdorimi i tij është më efektiv në rastet e mëposhtme:
- kur zhvillohen projekte me të qarta, të pandryshueshmecikli i jetes kërkesat e kuptueshme nga zbatimi dhe metodologjitë teknike;
- kur zhvillon një projekt të përqendruar në ndërtimin e një sistemi ose produkti të të njëjtit lloj siç është zhvilluar më parë nga zhvilluesit;
- kur zhvillon një projekt në lidhje me krijimin dhe lëshimin e një versioni të ri të një produkti ose sistemi ekzistues;
- kur zhvillon një projekt në lidhje me transferimin e një produkti ose sistemi ekzistues në një platformë të re;
- kur kryeni projekte të mëdha që përfshijnë disa ekipe të mëdha zhvillimi.
modeli në rritje
(modeli me skemë me kontroll të ndërmjetëm)
modeli në rritje(eng. rritje- rritje, rritje) nënkupton zhvillimin e softuerit me një sekuencë lineare fazash, por në disa rritje (versione), d.m.th. me përmirësime të planifikuara të produktit për aq kohë sa përfundon cikli jetësor i zhvillimit të softuerit.
Zhvillimi i softuerit kryhet në përsëritje me cikle reagimesh midis fazave. Rregullimet ndërfazore bëjnë të mundur që të merret parasysh ndikimi aktual i ndërsjellë i rezultateve të zhvillimit në faza të ndryshme, jetëgjatësia e secilës prej fazave zgjatet gjatë gjithë periudhës së zhvillimit.
Në fillim të punës për projektin, përcaktohen të gjitha kërkesat themelore për sistemin, të ndara në ato gjithnjë e më pak të rëndësishme. Pas kësaj, zhvillimi i sistemit kryhet në mënyrë shtesë, në mënyrë që zhvilluesi të mund të përdorë të dhënat e marra gjatë zhvillimit të softuerit. Çdo rritje duhet të shtojë funksione të caktuara në sistem. Në këtë rast, lëshimi fillon me komponentët me përparësinë më të lartë. Kur të përcaktohen pjesët e sistemit, merrni pjesën e parë dhe filloni ta detajoni duke përdorur procesin më të përshtatshëm për këtë. Në të njëjtën kohë, është e mundur të përpunohen kërkesat për pjesët e tjera që janë ngrirë në grupin aktual të kërkesave të kësaj pune. Nëse është e nevojshme, mund të ktheheni në këtë pjesë më vonë. Nëse pjesa është gati, i dorëzohet klientit, i cili mund ta përdorë atë në punën e tij. Kjo do t'i lejojë klientit të qartësojë kërkesat për komponentët e mëposhtëm. Pastaj ata zhvillojnë pjesën tjetër të sistemit. Hapat kyç në këtë proces janë zbatimi i thjeshtë i një nëngrupi të kërkesave të softuerit dhe përsosja e modelit gjatë një serie lëshimesh të njëpasnjëshme derisa softueri të zbatohet plotësisht.
Cikli jetësor i këtij modeli është tipik për zhvillimin e sistemeve komplekse dhe komplekse për të cilat ekziston një vizion i qartë (si nga ana e klientit ashtu edhe nga zhvilluesi) se cili duhet të jetë rezultati përfundimtar. Zhvillimi i versionit kryhet për arsye të ndryshme:
- mungesa e aftësisë së klientit për të financuar menjëherë të gjithë projektin e shtrenjtë;
- mungesa e burimeve të nevojshme që zhvilluesi të zbatojë një projekt kompleks në një kohë të shkurtër;
- kërkesat për zbatimin në faza dhe zhvillimin e produktit nga përdoruesit përfundimtarë. Futja e të gjithë sistemit menjëherë mund të shkaktojë refuzim tek përdoruesit e tij dhe vetëm të "ngadalësojë" procesin e kalimit në teknologjitë e reja. Në mënyrë figurative, ata thjesht nuk mund të "tretin një copë të madhe, kështu që duhet të shtypet dhe të jepet në pjesë".
Përparësitë dhe kufizimettë këtij modeli (strategjisë) janë të njëjta me ato të kaskadës (modeli klasik i ciklit jetësor). Por ndryshe nga strategjia klasike, klienti mund t'i shohë rezultatet më herët. Bazuar në rezultatet e zhvillimit dhe zbatimit të versionit të parë, ai mund të ndryshojë pak kërkesat për zhvillim, ta braktisë atë ose të ofrojë zhvillimin e një produkti më të avancuar me lidhjen e një kontrate të re.
Përparësitë:
- kostot e bëra për shkak të ndryshimit të kërkesave të përdoruesve janë reduktuar, ri-analiza dhe mbledhja e dokumentacionit janë reduktuar ndjeshëm në krahasim me modelin e ujëvarës;
- është më e lehtë të marrësh komente nga klienti për punën e bërë - klientët mund të shprehin komentet e tyre për pjesët e përfunduara dhe mund të shohin se çfarë është bërë tashmë. Sepse pjesët e para të sistemit janë prototipi i sistemit në tërësi.
- klienti ka aftësinë për të përvetësuar dhe zotëruar shpejt softuerin - klientët mund të marrin përfitime reale nga sistemi më shpejt se sa do të ishte e mundur me modelin e ujëvarës.
Disavantazhet e modelit:
- menaxherët duhet të matin vazhdimisht ecurinë e procesit. në rastin e zhvillimit të shpejtë, nuk ia vlen të krijohen dokumente për çdo ndryshim minimal të versionit;
- struktura e sistemit ka tendencë të përkeqësohet kur shtohen komponentë të rinj - ndryshimet e vazhdueshme prishin strukturën e sistemit. Për të shmangur këtë, kërkohet kohë dhe para shtesë për rifaktorim. Struktura e dobët e bën softuerin të vështirë dhe të kushtueshëm për t'u modifikuar më vonë. Dhe cikli i jetës së softuerit i ndërprerë çon në humbje edhe më të mëdha.
Skema nuk lejon marrjen e menjëhershme të ndryshimeve në zhvillim dhe sqarimet e kërkesave të softuerit. Koordinimi i rezultateve të zhvillimit me përdoruesit kryhet vetëm në pikat e planifikuara pas përfundimit të secilës fazë të punës, dhe kërkesat e përgjithshme për softuerin fiksohen në formën e një detyre teknike për të gjithë kohën e krijimit të tij. Kështu, përdoruesit shpesh marrin softuer që nuk i plotëson nevojat e tyre reale.
model spirale
Modeli spirale:Cikli i jetës - në çdo kthesë të spirales, krijohet versioni tjetër i produktit, specifikohen kërkesat e projektit, përcaktohet cilësia e tij dhe planifikohet puna e kthesës tjetër. Vëmendje e veçantë i kushtohet fazave fillestare të zhvillimit - analizës dhe projektimit, ku fizibiliteti i zgjidhjeve të caktuara teknike testohet dhe justifikohet përmes krijimit të prototipeve.
Ky model është një proces zhvillimi softuerësh që kombinon dizajnin dhe prototipimin me faza për të kombinuar përfitimet e koncepteve nga poshtë-lart dhe nga lart-poshtë, duke theksuar fazat fillestare të ciklit jetësor: analizën dhe dizajnin.Tipar dallues Ky model i kushton vëmendje të veçantë rreziqeve që ndikojnë në organizimin e ciklit jetësor.
Në fazat e analizës dhe projektimit, realizueshmëria e zgjidhjeve teknike dhe shkalla e kënaqësisë së nevojave të klientit kontrollohet duke krijuar prototipa. Çdo kthesë e spirales korrespondon me krijimin e një fragmenti ose versioni të funksionueshëm të sistemit. Kjo ju lejon të sqaroni kërkesat, qëllimet dhe karakteristikat e projektit, të përcaktoni cilësinë e zhvillimit dhe të planifikoni punën e kthesës tjetër të spiralës. Kështu, detajet e projektit thellohen dhe konkretizohen në mënyrë konsistente dhe si rrjedhojë zgjidhet një opsion i arsyeshëm që plotëson kërkesat aktuale të klientit dhe vihet në zbatim.
Cikli i jetës në çdo kthesë të spirales - mund të aplikohen modele të ndryshme të procesit të zhvillimit të softuerit. Rezultati përfundimtar është një produkt i përfunduar. Modeli kombinon aftësitë e një modeli prototipues dhemodeli i ujëvarës. Zhvillimi me përsëritje pasqyron ciklin spirale ekzistues objektiv të krijimit të sistemit. Përfundimi jo i plotë i punës në secilën fazë ju lejon të kaloni në fazën tjetër pa pritur përfundimin e plotë të punës në atë aktuale. Detyra kryesore është t'u tregohet përdoruesve të sistemit një produkt të zbatueshëm sa më shpejt të jetë e mundur, duke aktivizuar kështu procesin e qartësimit dhe plotësimit të kërkesave.
Avantazhet e modelit:
- ju lejon t'u tregoni shpejt përdoruesve të sistemit një produkt të zbatueshëm, duke aktivizuar kështu procesin e sqarimit dhe plotësimit të kërkesave;
- lejon ndryshime në kërkesat gjatë zhvillimit të softuerit, gjë që është tipike për shumicën e zhvillimeve, përfshirë ato standarde;
- modeli parashikon mundësinë e dizajnit fleksibël, pasi ai mishëron avantazhet e modelit kaskadë, dhe në të njëjtën kohë lejohen përsëritjet në të gjitha fazat e të njëjtit model;
- ju lejon të merrni një sistem më të besueshëm dhe të qëndrueshëm. Ndërsa softueri evoluon, gabimet dhe dobësitë gjenden dhe rregullohen në çdo përsëritje;
- ky model i lejon përdoruesit të marrin pjesë aktive në planifikim, analizë risku, zhvillim, si dhe në kryerjen e aktiviteteve të vlerësimit;
- zvogëloni rrezikun e klientit. Klienti mund të përfundojë zhvillimin e një projekti jo premtues me humbje minimale financiare;
- reagimet nga përdoruesit tek zhvilluesit kryhen me frekuencë të lartë dhe në fillim të modelit, gjë që siguron që produkti i dëshiruar të jetë me cilësi të lartë.
Disavantazhet e modelit:
- nëse projekti është me rrezik të ulët ose i vogël, modeli mund të jetë i shtrenjtë. Vlerësimi i rrezikut pas çdo spirale është i shtrenjtë;
- Cikli i jetës së modelit ka një strukturë të ndërlikuar, kështu që aplikimi i tij nga zhvilluesit, menaxherët dhe klientët mund të jetë i vështirë;
- spiralja mund të vazhdojë pafundësisht, pasi përgjigja e çdo klienti ndaj versionit të krijuar mund të gjenerojë një cikël të ri, i cili vonon përfundimin e projektit;
- një numër i madh i cikleve të ndërmjetme mund të çojë në nevojën për të përpunuar dokumentacion shtesë;
- përdorimi i modelit mund të jetë i kushtueshëm dhe madje i papërballueshëm, sepse koha. shpenzimet për planifikimin, ri-shënjestrimin, kryerjen e analizave të rrezikut dhe prototipimin mund të jenë të tepërta;
- mund të jetë e vështirë të përcaktohen qëllimet dhe piketa që tregojnë gatishmërinë për të vazhduar procesin e zhvillimit në të ardhmen dhe
Problemi kryesor i ciklit spirale është përcaktimi i momentit të kalimit në fazën tjetër. Për ta zgjidhur atë, futen afate kohore për secilën nga fazat.cikli i jetes dhe tranzicioni vazhdon sipas planit, edhe nëse nuk ka përfunduar e gjithë puna e planifikuar.Planifikimiështë bërë në bazë të të dhënave statistikore të marra në projekte të mëparshme dhe përvojës personale të zhvilluesve.
Shtrirja e modelit spirale
Përdorimi i modelit spirale këshillohet në rastet e mëposhtme:
- kur zhvilloni projekte duke përdorur teknologji të reja;
- kur zhvillon një seri të re produktesh ose sistemesh;
- kur zhvilloni projekte me ndryshime të rëndësishme ose shtesa të pritshme në kërkesat;
- për zbatimin e projekteve afatgjata;
- kur zhvilloni projekte që kërkojnë demonstrim të cilësisë dhe versioneve të një sistemi ose produkti për një periudhë të shkurtër kohore;
- gjatë zhvillimit të projekteve. për të cilat është e nevojshme të llogariten kostot që lidhen me vlerësimin dhe zgjidhjen e rreziqeve.
Në këtë standard PS (ose software) 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 që transformojnë disa të dhëna hyrëse në të dhëna dalëse (G. Myers i quan këto të dhëna përkthim). Çdo proces karakterizohet nga detyra dhe metoda të caktuara për zgjidhjen e tyre. Nga ana tjetër, çdo proces ndahet në një grup veprimesh dhe çdo veprim ndahet në një grup detyrash. Ç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 e të dhënave hyrëse).
Duhet të theksohet se në Bashkimin Sovjetik, dhe më pas në Rusi, krijimi i softuerit (softuerit) fillimisht, në vitet 70 të shekullit të kaluar, u rregullua nga standardet GOST ESPD (Sistemi i Unifikuar për Dokumentimin e Programit - GOST 19.XXX seri), të cilat u fokusuan në programet e klasës relativisht të thjeshta me vëllim të vogël të krijuar nga programues individualë. Aktualisht, këto standarde janë të vjetruara konceptualisht dhe në formë, vlefshmëria e tyre ka skaduar dhe përdorimi i tyre është i papërshtatshëm.
Proceset e krijimit të sistemeve të automatizuara (AS), të cilat përfshijnë gjithashtu softuer, rregullohen nga standardet GOST 34.601-90 "Teknologjia e informacionit. Një grup standardesh për sistemet e automatizuara. Fazat e krijimit", GOST 34.602-89 "Teknologjia e informacionit. A. grup standardesh për sistemet e automatizuara. Detyrë teknike për krijimin e një sistemi të automatizuar" dhe GOST 34.603-92 "Teknologjia e informacionit. Llojet e testeve të sistemeve të automatizuara". Megjithatë, shumë dispozita të këtyre standardeve janë të vjetruara, ndërsa të tjerat nuk janë pasqyruar aq sa duhet për t'u përdorur për projekte serioze për krijimin e PS. Prandaj këshillohet përdorimi i standardeve moderne ndërkombëtare në zhvillimet e brendshme.
Në përputhje me standardin ISO/IEC 12207, të gjitha proceset e ciklit jetësor të softuerit ndahen në tre grupe (Fig. 5.1).
Oriz. 5.1.
Pesë procese kryesore përcaktohen në grupet: blerja, furnizimi, zhvillimi, funksionimi dhe mirëmbajtja. Tetë nën-procese sigurojnë ekzekutimin e proceseve kryesore, përkatësisht dokumentacionin, menaxhimi i konfigurimit, sigurimi i cilësisë, verifikimi, vlefshmëria, vlerësimi i përbashkët, auditimi, zgjidhja e problemit. Katër proceset organizative ofrojnë qeverisje, ndërtim të infrastrukturës, përmirësim dhe mësim.
5.2. Proceset kryesore të ciklit jetësor të PS
Procesi i blerjes përbëhet nga aktivitetet dhe detyrat e klientit që blen softuerin. Ky proces mbulon hapat e mëposhtëm:
- fillimi i blerjes;
- përgatitja e propozimeve për aplikim;
- përgatitja dhe rregullimi i kontratës;
- mbikëqyrja e aktiviteteve të furnizuesit;
- pranimi dhe përfundimi i punës.
Fillimi i blerjes përfshin detyrat e mëposhtme:
- përcaktimi nga klienti i nevojave të tij në blerjen, zhvillimin ose përmirësimin e sistemit, produkteve ose shërbimeve softuerike;
- marrjen e një vendimi në lidhje me blerjen, zhvillimin ose përmirësimin e softuerit ekzistues;
- kontrollimin e disponueshmërisë së dokumentacionit të nevojshëm, garancive, certifikatave, licencave dhe mbështetjes në rast të blerjes së një produkti softuer;
- përgatitjen dhe miratimin e planit të blerjes, duke përfshirë kërkesat e sistemit, llojin e kontratës, përgjegjësitë e palëve, etj.
Ofertat duhet të përmbajnë:
- Kërkesat e sistemit;
- lista e produkteve softuerike;
- kushtet e blerjes dhe marrëveshjes;
- kufizimet teknike (për shembull, në mjedisin operativ të sistemit).
Ofertat i dërgohen një furnizuesi të përzgjedhur ose furnitorëve të shumtë në rast të një tenderi. Furnizuesi është një organizatë që lidh një kontratë me një klient për furnizimin e një sistemi, softueri ose shërbimi softuerësh sipas kushteve të përcaktuara në kontratë.
Përgatitja dhe rregullimi i kontratës përfshin detyrat e mëposhtme:
- përcaktimi nga klienti i procedurës për zgjedhjen e një furnizuesi, duke përfshirë kriteret për vlerësimin e propozimeve të furnitorëve të mundshëm;
- përzgjedhja e një furnizuesi specifik bazuar në analizën e propozimeve;
- përgatitjen dhe përfundimin kontratat e furnitorëve;
- duke bërë ndryshime (nëse është e nevojshme) në kontratë në procesin e zbatimit të saj.
Aktivitetet e furnizuesit mbikëqyren në përputhje me veprimet e përcaktuara në proceset e përbashkëta të vlerësimit dhe auditimit. Gjatë procesit të pranimit përgatiten dhe kryhen testet e nevojshme. Përfundimi i punës sipas kontratës kryhet në rast të plotësimit të të gjitha kushteve të pranimit.
Procesi i dorëzimit mbulon aktivitetet dhe detyrat e kryera nga një shitës që furnizon një klient me një produkt ose shërbim softuerësh. Ky proces përfshin hapat e mëposhtëm:
- fillimi i dorëzimit;
- përgatitja e një përgjigje për ofertat;
- përgatitja e kontratës;
- planifikimi i punës me kontratë;
- kryerja dhe kontrolli i punëve kontraktuale dhe vlerësimi i tyre;
- dorëzimin dhe përfundimin e punimeve.
Fillimi i furnizimit konsiston në shqyrtimin nga furnizuesi i ofertave dhe vendimin nëse do të pajtohen me kërkesat dhe kushtet e përcaktuara ose do të ofrojnë të tyret (të dakorduara). Planifikimi përfshin detyrat e mëposhtme:
- marrjen e një vendimi nga furnizuesi në lidhje me kryerjen e punës vetë ose me përfshirjen e një nënkontraktori;
- zhvillimi nga furnizuesi i një plani të menaxhimit të projektit që përmban strukturën organizative të projektit, përcaktimin e përgjegjësive, kërkesat teknike për mjedisin dhe burimet e zhvillimit, menaxhimin e nënkontraktorëve, etj.
Procesi i zhvillimit parashikon aktivitetet dhe detyrat e kryera nga zhvilluesi, dhe mbulon punën e krijimit të softuerit dhe komponentëve të tij në përputhje me kërkesat e specifikuara. Kjo përfshin përgatitjen e dokumentacionit të projektimit dhe operacional, përgatitjen e materialeve të nevojshme për testimin e performancës dhe cilësinë e produkteve softuerike, materialet e nevojshme për organizimin e trajnimit të personelit etj.
Procesi i zhvillimit përfshin hapat e mëposhtëm:
- punë përgatitore;
- analiza e kërkesave për sistemin;
- dizajni i arkitekturës së sistemit;
- analiza e kërkesave për softuer;
- dizajni i arkitekturës së 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.
Puna përgatitore fillon me zgjedhjen e një modeli të ciklit jetësor të softuerit të përshtatshëm për shkallën, rëndësinë dhe kompleksitetin e projektit. Aktivitetet dhe detyrat e procesit të zhvillimit duhet të jenë në përputhje me modelin e zgjedhur. Zhvilluesi duhet të zgjedhë, të përshtatet me kushtet e projektit dhe të përdorë standardet, metodat dhe metodat e dakorduara me klientin. mjetet e zhvillimit, si dhe të hartojë një plan pune.
Analiza e kërkesave për sistemin përfshin përcaktimin e funksionalitetit të tij, kërkesat me porosi, kërkesat për besueshmërinë, sigurinë, kërkesat për ndërfaqet e jashtme, performancën, etj. Kërkesat e sistemit vlerësohen në bazë të kritereve të fizibilitetit dhe verifikueshmërisë gjatë testimit.
Dizajni i arkitekturës së sistemit konsiston në përcaktimin e komponentëve të pajisjeve të tij (harduerit), softuerit dhe operacioneve 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 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.
Kërkesat e softuerit vlerësohen në bazë të kritereve të përputhshmërisë me kërkesat për sistemin në tërësi, fizibilitetit dhe verifikueshmërisë gjatë testimit.
Dizajni i arkitekturës së softuerit përfshin detyrat e mëposhtme për secilin komponent të softuerit:
- transformimi i kërkesave të softuerit në një arkitekturë që përcakton strukturën e softuerit dhe përbërjen e komponentëve të tij në një nivel të lartë;
- zhvillimi dhe dokumentimi i ndërfaqeve programore për softuer dhe baza të të dhënave (DB);
- zhvillimi i një versioni paraprak të dokumentacionit të përdoruesit;
- zhvillimin dhe dokumentimin e parakushteve për teste dhe planin e integrimit të softuerit.
Dizajni i detajuar i softuerit 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;
- zhvillimin dhe dokumentimin e një dizajni të detajuar të bazës së të dhënave;
- përditësimi (nëse është e nevojshme) dokumentacioni i përdoruesit;
- zhvillimin dhe dokumentimin e kërkesave të testimit dhe një plan për testimin e komponentëve të softuerit;
Kodimi dhe testimi i softuerit përfshin detyrat e mëposhtme:
- kodimin dhe dokumentimin e çdo komponenti të softuerit dhe bazës së të dhënave, si dhe përgatitjen e një grupi procedurash testimi dhe të dhënash për testimin e tyre;
- testimin e secilit komponent të softuerit dhe bazës së të dhënave për pajtueshmërinë me kërkesat për to, e ndjekur nga dokumentacioni i rezultateve të testimit;
- përditësimi i dokumentacionit (nëse është e nevojshme);
- përditësimin e planit të integrimit të softuerit.
Integrimi i softuerit parashikon montimin e komponentëve të softuerit të zhvilluar në përputhje me planin e integrimit dhe testimit për komponentët e grumbulluar. Për secilin nga komponentët e grumbulluar, grupet e testimit dhe procedurat e testimit janë zhvilluar për të testuar secilën prej kompetencave në testimin e mëpasshëm të aftësisë. Një kërkesë kualifikimi është një grup kriteresh ose kushtesh që duhet të plotësohen për t'u kualifikuar. software si konform specifikave të tij dhe gati për përdorim në terren.
Testimi i kualifikimit të softuerit kryhet nga zhvilluesi në prani të klientit (
Procesi i funksionimit mbulon aktivitetet dhe detyrat e organizatës së operatorit që operon sistemin. Procesi i funksionimit përfshin hapat e mëposhtëm.
Puna përgatitore, e cila përfshin kryerjen e detyrave të mëposhtme nga operatori:
- 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 operacional kryhet për çdo botim të ardhshëm të produktit softuer, pas së cilës ky botim transferohet në funksionim.
- Funksionimi aktual i sistemit, i cili kryhet në mjedisin e destinuar për këtë në përputhje me dokumentacionin e përdoruesit.
- analiza e problemeve dhe kërkesave për modifikim të softuerit (analiza e mesazheve në lidhje me një problem që ka lindur ose një kërkesë për modifikim, vlerësimi i shkallës, kostoja e modifikimit, efekti që rezulton, vlerësimi i fizibilitetit të modifikimit);
- modifikimi i softuerit (duke bërë ndryshime në komponentët dhe dokumentacionin e produktit softuerik në përputhje me rregullat e procesit të zhvillimit);
- verifikimi dhe pranimi (përsa i përket integritetit të sistemit që modifikohet);
- transferimi i softuerit në një mjedis tjetër (konvertimi i programeve dhe të dhënave, funksionimi paralel i softuerit në mjedisin e vjetër dhe të ri për një periudhë të caktuar kohore);
- çmontimi i softuerit me vendim të klientit me pjesëmarrjen e organizatës operuese, shërbimit të mirëmbajtjes dhe përdoruesve. Në të njëjtën kohë, produktet softuerike dhe dokumentacioni i nënshtrohen arkivimit në përputhje me kontratën.
Shënim.
Prezantimi.
1. Cikli i jetës së softuerit
Prezantimi.
Hapat e procesit të programimit Riley
Prezantimi.
1.1.1. Formulimi i problemit.
1.1.2. Dizajni i zgjidhjes.
1.1.3. Kodimi i algoritmit.
1.1.4. Mbështetja e programit.
1.1.5. Dokumentacioni i softuerit.
Konkluzioni për paragrafin 1.1
1.2. Përkufizimi i ZhTsPO sipas Lehman.
Prezantimi.
1.2.1 Përkufizimi i sistemit.
1.2.2. Zbatimi.
1.2.3. Shërbimi.
Konkluzioni për pikën 1.2.
1.3. Fazat dhe punët e programit të ciklit jetësor sipas Boehm
1.3.1. modeli i kaskadës.
1.3.2. Arsyetimi ekonomik i modelit të kaskadës.
1.3.3. Përmirësimi i modelit të kaskadës.
1.3.4. Përkufizimi i fazave të ciklit jetësor.
1.3.5. Puna bazë në projekt.
Letërsia.
Prezantimi
Aplikimi industrial i kompjuterëve dhe kërkesa në rritje për programe kanë vendosur detyra urgjente për një rritje të konsiderueshme produktiviteti i zhvillimit të softuerit, zhvillimi i metodave industriale për planifikimin dhe hartimin e programeve, transferimi i metodave, modeleve dhe metodave organizative, teknike, teknike, ekonomike dhe socio-psikologjike nga sfera e prodhimit material në sferën e kompjuterëve. Një qasje komplekse proceseve të zhvillimit, funksionimit dhe mirëmbajtjes së softuerit parashtron një sërë problemesh të ngutshme, zgjidhja e të cilave do të eliminojë "blloqet" në hartimin e programeve, do të zvogëlojë kohën e përfundimit, do të përmirësojë përzgjedhjen dhe përshtatjen e programeve ekzistuese dhe ndoshta përcaktojnë fatin e sistemeve me kompjuterë të integruar.
Në praktikën e zhvillimit të projekteve të mëdha softuerike, shpesh nuk ka qasje të unifikuar për vlerësimin e kostove të punës, kushteve të punës dhe kostove materiale, gjë që pengon rritjen e produktivitetit të zhvillimit të softuerit, dhe në fund të fundit menaxhimin efektiv të ciklit jetësor të softuerit. Meqenëse një program i çdo lloji bëhet produkt (përveç, ndoshta, programeve arsimore, modele), qasja ndaj prodhimit të tij duhet të jetë e ngjashme në shumë aspekte me qasjen ndaj prodhimit të produkteve industriale, dhe çështjet e dizajnit të softuerit bëhen jashtëzakonisht të rëndësishme. . Kjo ide qëndron në themel të B.U. Boehm "Dizajnimi i softuerit inxhinierik", të cilin e kemi përdorur gjatë shkrimit të këtij termi. Në këtë libër, dizajni i softuerit i referohet procesit të krijimit të një dizajni për një produkt softuer.
1 Cikli i jetës së softuerit
PREZANTIMI
LCPE është një proces i vazhdueshëm që fillon nga momenti kur merret një vendim për nevojën e krijimit të softuerit dhe përfundon në momentin që ai tërhiqet plotësisht nga funksionimi.
Ka disa qasje për përcaktimin e fazave dhe aktiviteteve të ciklit jetësor të softuerit (SLLC), hapat e procesit të programimit, modelet e ujëvarës dhe spirale. Por të gjitha ato përmbajnë komponentë të përbashkët themelorë: deklaratën e problemit, dizajnin e zgjidhjes, zbatimin, mirëmbajtjen.
Më e famshmja dhe më e plota, ndoshta, është struktura e ciklit jetësor sipas Boehm, e cila përfshin tetë faza. Më vonë do të prezantohet më në detaje.
Një nga opsionet e mundshme mund të jetë përshkrimi i nivelit të lartë sipas Lehman, i cili përfshin tre faza kryesore dhe paraqet përshkrimin e programit të ciklit jetësor në rastin më të përgjithshëm.
Dhe, për një ndryshim, këtu janë hapat e procesit të programimit të paraqitura nga D. Riley në librin “Using the Modula-2 Language”. Kjo ide, për mendimin tim, është shumë e thjeshtë dhe e njohur, dhe ne do të fillojmë me të.
1.1 Hapat e procesit të programimit Riley
Prezantimi
Procesi i programimit përfshin katër hapa (Fig. 1):
deklarata e problemit, d.m.th. marrja e një ideje adekuate se çfarë detyre duhet të kryejë programi;
hartimi i një zgjidhjeje për një problem të paraqitur tashmë (në përgjithësi, një zgjidhje e tillë është më pak formale se programi përfundimtar);
kodimi i programit, pra përkthimi i zgjidhjes së projektuar në një program që mund të ekzekutohet në një makinë;
mbështetjen e programit, d.m.th. një proces i vazhdueshëm i rregullimit të gabimeve në program dhe shtimit të veçorive të reja.
Oriz. 1.Katër hapa programimi.
Programimi fillon nga momenti kur përdorues, d.m.th. dikush që ka nevojë për një program për të zgjidhur një problem paraqet një problem analist i sistemit. Përdoruesi dhe analisti i sistemit përcaktojnë së bashku deklaratën e problemit. Kjo e fundit më pas transferohet algoritmisti i cili është përgjegjës për hartimin e zgjidhjes. Një zgjidhje (ose algoritëm) është një sekuencë operacionesh, ekzekutimi i të cilave çon në zgjidhjen e një problemi. Meqenëse algoritmi shpesh nuk përshtatet për t'u ekzekutuar në një makinë, ai duhet të përkthehet në një program makine. Ky operacion kryhet nga koduesi. Mbajtësi është përgjegjës për ndryshimet e mëvonshme në program. programues. Dhe analisti i sistemit, dhe algoritmisti, dhe koduesi dhe programuesi shoqërues - ata janë të gjithë programues.
Në rastin e një projekti të madh softuerësh, numri i përdoruesve, analistëve të sistemit dhe algoritmeve mund të jetë i rëndësishëm. Përveç kësaj, mund të jetë e nevojshme të ktheheni në hapat e mëparshëm për shkak të rrethanave të paparashikuara. E gjithë kjo shërben si një argument shtesë në favor të dizajnit të kujdesshëm të softuerit: rezultatet e secilit hap duhet të jenë të plota, të sakta dhe të kuptueshme.
1.1.1 Deklarata e problemit
Një nga hapat më të rëndësishëm në programim është vendosja e një problemi. Ajo funksionon si një kontratë midis përdoruesit dhe programuesit. Ashtu si një kontratë e hartuar dobët ligjërisht, një deklaratë e keqe e misionit është e padobishme. Me një deklaratë të mirë problemi, si përdoruesi ashtu edhe programuesi përfaqësojnë qartë dhe pa mëdyshje detyrën që duhet kryer, d.m.th. në këtë rast merren parasysh interesat si të përdoruesit ashtu edhe të programuesit. Përdoruesi mund të planifikojë të përdorë softuerin që ende nuk është krijuar, bazuar në njohuritë që mundet. Një deklaratë e mirë e problemit shërben si bazë për formimin e zgjidhjes së tij.
Formulimi i problemit (specifikimi i programit); në thelb nënkupton një përshkrim të saktë, të plotë dhe të kuptueshëm të asaj që ndodh kur një program i caktuar ekzekutohet. Përdoruesi zakonisht e shikon kompjuterin si një kuti të zezë: për të nuk ka rëndësi se si funksionon kompjuteri, por është e rëndësishme që kompjuteri të mund të bëjë atë që i intereson përdoruesit. Fokusi është në ndërveprimin midis njeriut dhe makinës.
Karakteristikat e një deklarate të mirë problemi:
Saktësia, d.m.th. përjashtimi i çdo paqartësie. Nuk duhet të ketë dyshim se cili do të jetë rezultati i programit për çdo hyrje të dhënë.
plotësinë, d.m.th. duke marrë parasysh të gjitha opsionet për një input të caktuar, duke përfshirë hyrjen e gabuar ose të papritur, dhe përcaktimin e prodhimit të duhur.
Qartësia, d.m.th. duhet të jetë e kuptueshme si për përdoruesin ashtu edhe për analistin e sistemit, pasi deklarata e problemit është e vetmja kontratë ndërmjet tyre.
Shpesh kërkesat për saktësi, plotësi dhe qartësi janë në konflikt. Kështu, shumë dokumente ligjore janë të vështira për t'u kuptuar, sepse ato janë shkruar në një gjuhë zyrtare që ju lejon të formuloni disa dispozita me saktësinë më të madhe, duke përjashtuar edhe mospërputhjet më të parëndësishme. Për shembull, disa pyetje në fletët e provimit ndonjëherë formulohen aq saktë sa studenti shpenzon më shumë kohë për të kuptuar pyetjen sesa për t'iu përgjigjur asaj. Për më tepër, studenti mund të mos e kuptojë fare kuptimin kryesor të pyetjes për shkak të numrit të madh të detajeve. Deklarata më e mirë e problemit është ajo që arrin një ekuilibër të të tre kërkesave.
Forma standarde e deklaratës së problemit.
Merrni parasysh deklaratën e mëposhtme të problemit: "Fut tre numra dhe nxirr numrat sipas radhës."
Një deklaratë e tillë nuk i plotëson kërkesat e mësipërme: nuk është as e saktë, as e plotë dhe as e kuptueshme. Në të vërtetë, a duhet të futen numrat një për rresht, apo të gjithë numrat në një rresht? A do të thotë shprehja "në rregull" renditja nga më e madhja tek më e vogla, nga më e vogla te më e madhja apo të njëjtin rend në të cilin janë futur ato.
Është e qartë se një deklaratë e tillë nuk i përgjigjet shumë pyetjeve. Nëse marrim parasysh përgjigjet për të gjitha pyetjet, atëherë deklarata e problemit do të bëhet fjalëpakë dhe e vështirë për t'u kuptuar. Prandaj, D. Riley propozon përdorimin e formularit standard për vendosjen e problemit, i cili siguron saktësinë, plotësinë, qartësinë maksimale dhe përfshin:
emri i detyrës (përkufizimi skematik);
përshkrim i përgjithshëm (deklaratë e shkurtër e detyrës);
gabime (opsionet e pazakonta të hyrjes janë renditur në mënyrë eksplicite për t'u treguar përdoruesve dhe programuesve veprimet që do të ndërmarrë makina në situata të tilla);
shembull (një shembull i mirë mund të përcjellë thelbin e problemit, si dhe të ilustrojë raste të ndryshme).
Shembull. Paraqitja e problemit në formën standarde.
TITULLI
Renditni tre numra të plotë.
PËRSHKRIM
Hyrja dhe dalja e tre numrave të plotë, të renditur nga më i vogli tek më i madhi.
Futen tre numra të plotë, një numër për rresht. Në këtë rast, një numër i plotë është një ose më shumë shifra dhjetore të njëpasnjëshme, të cilat mund të paraprihen nga një shenjë plus "+" ose një shenjë minus "-".
Tre numrat e plotë të futur dalin, me të tre të shfaqur në të njëjtën linjë. Numrat ngjitur ndahen me një hapësirë. Numrat shfaqen nga më i vogli tek më i madhi, nga e majta në të djathtë.
1) Nëse futen më pak se tre numra, programi pret për hyrje shtesë.
2) Linjat hyrëse të tjera nga tre të parat injorohen.
3) Nëse ndonjë nga tre rreshtat e parë përmban më shumë se një numër të plotë, atëherë programi del dhe lëshon një mesazh.
Shënim.
Prezantimi.
1. Cikli i jetës së softuerit
Prezantimi.
Hapat e procesit të programimit Riley
Prezantimi.
1.1.1. Formulimi i problemit.
1.1.2. Dizajni i zgjidhjes.
1.1.3. Kodimi i algoritmit.
1.1.4. Mbështetja e programit.
1.1.5. Dokumentacioni i softuerit.
Konkluzioni për paragrafin 1.1
1.2. Përkufizimi i ZhTsPO sipas Lehman.
Prezantimi.
1.2.1 Përkufizimi i sistemit.
1.2.2. Zbatimi.
1.2.3. Shërbimi.
Konkluzioni për pikën 1.2.
1.3. Fazat dhe punët e programit të ciklit jetësor sipas Boehm
1.3.1. modeli i kaskadës.
1.3.2. Arsyetimi ekonomik i modelit të kaskadës.
1.3.3. Përmirësimi i modelit të kaskadës.
1.3.4. Përkufizimi i fazave të ciklit jetësor.
1.3.5. Puna bazë në projekt.
Letërsia.
Prezantimi
Aplikimi industrial i kompjuterëve dhe kërkesa në rritje për programe kanë vendosur detyra urgjente për një rritje të konsiderueshme produktiviteti i zhvillimit të softuerit, zhvillimi i metodave industriale për planifikimin dhe hartimin e programeve, transferimi i metodave, modeleve dhe metodave organizative, teknike, teknike, ekonomike dhe socio-psikologjike nga sfera e prodhimit material në sferën e kompjuterëve. Një qasje komplekse proceseve të zhvillimit, funksionimit dhe mirëmbajtjes së softuerit parashtron një sërë problemesh të ngutshme, zgjidhja e të cilave do të eliminojë "blloqet" në hartimin e programeve, do të zvogëlojë kohën e përfundimit, do të përmirësojë përzgjedhjen dhe përshtatjen e programeve ekzistuese dhe ndoshta përcaktojnë fatin e sistemeve me kompjuterë të integruar.
Në praktikën e zhvillimit të projekteve të mëdha softuerike, shpesh nuk ka qasje të unifikuar për vlerësimin e kostove të punës, kushteve të punës dhe kostove materiale, gjë që pengon rritjen e produktivitetit të zhvillimit të softuerit, dhe në fund të fundit menaxhimin efektiv të ciklit jetësor të softuerit. Meqenëse një program i çdo lloji bëhet produkt (përveç, ndoshta, programeve arsimore, modele), qasja ndaj prodhimit të tij duhet të jetë e ngjashme në shumë aspekte me qasjen ndaj prodhimit të produkteve industriale, dhe çështjet e dizajnit të softuerit bëhen jashtëzakonisht të rëndësishme. . Kjo ide qëndron në themel të B.U. Boehm "Dizajnimi i softuerit inxhinierik", të cilin e kemi përdorur gjatë shkrimit të këtij termi. Në këtë libër, dizajni i softuerit i referohet procesit të krijimit të një dizajni për një produkt softuer.
1 Cikli i jetës së softuerit
PREZANTIMI
LCPE është një proces i vazhdueshëm që fillon nga momenti kur merret një vendim për nevojën e krijimit të softuerit dhe përfundon në momentin që ai tërhiqet plotësisht nga funksionimi.
Ka disa qasje për përcaktimin e fazave dhe aktiviteteve të ciklit jetësor të softuerit (SLLC), hapat e procesit të programimit, modelet e ujëvarës dhe spirale. Por të gjitha ato përmbajnë komponentë të përbashkët themelorë: deklaratën e problemit, dizajnin e zgjidhjes, zbatimin, mirëmbajtjen.
Më e famshmja dhe më e plota, ndoshta, është struktura e ciklit jetësor sipas Boehm, e cila përfshin tetë faza. Më vonë do të prezantohet më në detaje.
Një nga opsionet e mundshme mund të jetë përshkrimi i nivelit të lartë sipas Lehman, i cili përfshin tre faza kryesore dhe paraqet përshkrimin e programit të ciklit jetësor në rastin më të përgjithshëm.
Dhe, për një ndryshim, këtu janë hapat e procesit të programimit të paraqitura nga D. Riley në librin “Using the Modula-2 Language”. Kjo ide, për mendimin tim, është shumë e thjeshtë dhe e njohur, dhe ne do të fillojmë me të.
1.1 Hapat e procesit të programimit Riley
Procesi i programimit përfshin katër hapa (Fig. 1):
deklarata e problemit, d.m.th. marrja e një ideje adekuate se çfarë detyre duhet të kryejë programi;
hartimi i një zgjidhjeje për një problem të paraqitur tashmë (në përgjithësi, një zgjidhje e tillë është më pak formale se programi përfundimtar);
kodimi i programit, pra përkthimi i zgjidhjes së projektuar në një program që mund të ekzekutohet në një makinë;
mbështetjen e programit, d.m.th. një proces i vazhdueshëm i rregullimit të gabimeve në program dhe shtimit të veçorive të reja.
Oriz. 1.Katër hapa programimi.
Programimi fillon nga momenti kur përdorues, d.m.th. dikush që ka nevojë për një program për të zgjidhur një problem paraqet një problem analist i sistemit. Përdoruesi dhe analisti i sistemit përcaktojnë së bashku deklaratën e problemit. Kjo e fundit më pas transferohet algoritmisti i cili është përgjegjës për hartimin e zgjidhjes. Një zgjidhje (ose algoritëm) është një sekuencë operacionesh, ekzekutimi i të cilave çon në zgjidhjen e një problemi. Meqenëse algoritmi shpesh nuk përshtatet për t'u ekzekutuar në një makinë, ai duhet të përkthehet në një program makine. Ky operacion kryhet nga koduesi. Programuesi shoqërues është përgjegjës për ndryshimet e mëvonshme në program. Dhe analisti i sistemit, dhe algoritmisti, dhe koduesi dhe programuesi shoqërues - ata janë të gjithë programues.
Në rastin e një projekti të madh softuerësh, numri i përdoruesve, analistëve të sistemit dhe algoritmeve mund të jetë i rëndësishëm. Përveç kësaj, mund të jetë e nevojshme të ktheheni në hapat e mëparshëm për shkak të rrethanave të paparashikuara. E gjithë kjo shërben si një argument shtesë në favor të dizajnit të kujdesshëm të softuerit: rezultatet e secilit hap duhet të jenë të plota, të sakta dhe të kuptueshme.
1.1.1 Deklarata e problemit
Një nga hapat më të rëndësishëm në programim është vendosja e një problemi. Ajo funksionon si një kontratë midis përdoruesit dhe programuesit. Ashtu si një kontratë e hartuar dobët ligjërisht, një deklaratë e keqe e misionit është e padobishme. Me një deklaratë të mirë problemi, si përdoruesi ashtu edhe programuesi përfaqësojnë qartë dhe pa mëdyshje detyrën që duhet kryer, d.m.th. në këtë rast merren parasysh interesat si të përdoruesit ashtu edhe të programuesit. Përdoruesi mund të planifikojë të përdorë softuerin që ende nuk është krijuar, bazuar në njohuritë që mundet. Një deklaratë e mirë e problemit shërben si bazë për formimin e zgjidhjes së tij.
Formulimi i problemit (specifikimi i programit); në thelb nënkupton një përshkrim të saktë, të plotë dhe të kuptueshëm të asaj që ndodh kur një program i caktuar ekzekutohet. Përdoruesi zakonisht e shikon kompjuterin si një kuti të zezë: për të nuk ka rëndësi se si funksionon kompjuteri, por është e rëndësishme që kompjuteri të mund të bëjë atë që i intereson përdoruesit. Fokusi është në ndërveprimin midis njeriut dhe makinës.
Karakteristikat e një deklarate të mirë problemi:
Saktësia, d.m.th. përjashtimi i çdo paqartësie. Nuk duhet të ketë dyshim se cili do të jetë rezultati i programit për çdo hyrje të dhënë.
plotësinë, d.m.th. duke marrë parasysh të gjitha opsionet për një input të caktuar, duke përfshirë hyrjen e gabuar ose të papritur, dhe përcaktimin e prodhimit të duhur.
Qartësia, d.m.th. duhet të jetë e kuptueshme si për përdoruesin ashtu edhe për analistin e sistemit, pasi deklarata e problemit është e vetmja kontratë ndërmjet tyre.
Shpesh kërkesat për saktësi, plotësi dhe qartësi janë në konflikt. Kështu, shumë dokumente ligjore janë të vështira për t'u kuptuar, sepse ato janë shkruar në një gjuhë zyrtare që ju lejon të formuloni disa dispozita me saktësinë më të madhe, duke përjashtuar edhe mospërputhjet më të parëndësishme. Për shembull, disa pyetje në fletët e provimit ndonjëherë formulohen aq saktë sa studenti shpenzon më shumë kohë për të kuptuar pyetjen sesa për t'iu përgjigjur asaj. Për më tepër, studenti mund të mos e kuptojë fare kuptimin kryesor të pyetjes për shkak të numrit të madh të detajeve. Deklarata më e mirë e problemit është ajo që arrin një ekuilibër të të tre kërkesave.
Forma standarde e deklaratës së problemit.
Merrni parasysh deklaratën e mëposhtme të problemit: "Fut tre numra dhe nxirr numrat sipas radhës."
Një deklaratë e tillë nuk i plotëson kërkesat e mësipërme: nuk është as e saktë, as e plotë dhe as e kuptueshme. Në të vërtetë, a duhet të futen numrat një për rresht, apo të gjithë numrat në një rresht? A do të thotë shprehja "në rregull" renditja nga më e madhja tek më e vogla, nga më e vogla te më e madhja apo të njëjtin rend në të cilin janë futur ato.
Është e qartë se një deklaratë e tillë nuk i përgjigjet shumë pyetjeve. Nëse marrim parasysh përgjigjet për të gjitha pyetjet, atëherë deklarata e problemit do të bëhet fjalëpakë dhe e vështirë për t'u kuptuar. Prandaj, D. Riley propozon përdorimin e formularit standard për vendosjen e problemit, i cili siguron saktësinë, plotësinë, qartësinë maksimale dhe përfshin:
emri i detyrës (përkufizimi skematik);
përshkrim i përgjithshëm (deklaratë e shkurtër e detyrës);
gabime (opsionet e pazakonta të hyrjes janë renditur në mënyrë eksplicite për t'u treguar përdoruesve dhe programuesve veprimet që do të ndërmarrë makina në situata të tilla);
shembull (një shembull i mirë mund të përcjellë thelbin e problemit, si dhe të ilustrojë raste të ndryshme).
Shembull. Paraqitja e problemit në formën standarde.
TITULLI
Renditni tre numra të plotë.
PËRSHKRIM
Hyrja dhe dalja e tre numrave të plotë, të renditur nga më i vogli tek më i madhi.
Futen tre numra të plotë, një numër për rresht. Në këtë rast, një numër i plotë është një ose më shumë shifra dhjetore të njëpasnjëshme, të cilat mund të paraprihen nga një shenjë plus "+" ose një shenjë minus "-".
Tre numrat e plotë të futur dalin, me të tre të shfaqur në të njëjtën linjë. Numrat ngjitur ndahen me një hapësirë. Numrat shfaqen nga më i vogli tek më i madhi, nga e majta në të djathtë.
1) Nëse futen më pak se tre numra, programi pret për hyrje shtesë.
Më 1 Mars 2012, Agjencia Federale për Rregullimin Teknik dhe Metrologjinë e Federatës Ruse miratoi standardin GOST R ISO/IEC 12207-2010 "Teknologjia e informacionit. Inxhinieri e sistemit dhe softuerit. Proceset e ciklit jetësor të softuerit”, identike me standardin ndërkombëtar ISO/IEC 12207:2008 “Inxhinieria e sistemit dhe softuerit - Proceset e ciklit jetësor të softuerit”.
Ky standard, duke përdorur terminologjinë e vendosur, krijon një kornizë të përbashkët për proceset e ciklit jetësor të softuerit që mund të përdoret si udhëzues në industrinë e softuerit. Standardi përcakton proceset, aktivitetet dhe detyrat që përdoren në blerjen e një produkti ose shërbimi softuer, si dhe në ofrimin, zhvillimin, përdorimin e synuar, mirëmbajtjen dhe ndërprerjen e produkteve softuerike.
Proceset e ciklit jetësor të softuerit
Standardi grupon aktivitetet e ndryshme që mund të kryhen gjatë ciklit jetësor të sistemeve softuerike në shtatë grupe procesi. Secili nga proceset e ciklit jetësor brenda këtyre grupeve përshkruhet në kuptimin e qëllimit dhe rezultateve të dëshiruara, listave të veprimeve dhe detyrave që duhen kryer për të arritur ato rezultate.
- proceset e marrëveshjes - dy procese;
- proceset e mbështetjes organizative të projektit - pesë procese;
- proceset e projektit - shtatë procese;
- proceset teknike - njëmbëdhjetë procese;
- proceset e implementimit të softuerit - shtatë procese;
- proceset e mbështetjes së softuerit - tetë procese;
- proceset e ripërdorimit të softuerit - tre procese.
- Kryesor:
- Blerja (veprimet dhe detyrat e klientit që blen softuerin)
- Dorëzimi (aktivitetet dhe detyrat e furnizuesit që furnizon klientin me një produkt ose shërbim softuerësh)
- Zhvillimi (veprimet dhe detyrat e kryera nga zhvilluesi: krijimi i softuerit, hartimi i dokumentacionit të projektimit dhe operacional, përgatitja e materialeve të testimit dhe trajnimit, etj.)
- Operacioni (veprimet dhe detyrat e operatorit - organizata që operon sistemin)
- Mirëmbajtja (veprimet dhe detyrat e kryera nga organizata shoqëruese, domethënë shërbimi i mirëmbajtjes). Mirëmbajtja - duke bërë ndryshime 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.
- Ndihmës
- Dokumentacioni (përshkrimi i formalizuar i informacionit të krijuar gjatë ciklit të jetës së softuerit)
- Menaxhimi i konfigurimit (zbatimi i procedurave administrative dhe teknike gjatë gjithë ciklit jetësor të softuerit për të përcaktuar gjendjen e komponentëve të softuerit, për të menaxhuar modifikimet e tij).
- Sigurimi i cilësisë (duke siguruar që IS dhe proceset e ciklit të tij jetësor përputhen me kërkesat e specifikuara dhe planet e miratuara)
- Verifikimi (përcaktimi që produktet softuerike, të cilat janë rezultat i disa veprimeve, plotësojnë plotësisht kërkesat ose kushtet për shkak të veprimeve të mëparshme)
- Certifikimi (përcaktimi i plotësisë së përputhshmërisë së kërkesave të specifikuara dhe sistemit të krijuar me qëllimin e tyre specifik funksional)
- Vlerësimi i përbashkët (vlerësimi i gjendjes së punës në projekt: kontrolli i planifikimit dhe menaxhimit të burimeve, personelit, pajisjeve, mjeteve)
- Auditimi (përcaktimi i përputhshmërisë me kërkesat, planet dhe kushtet e kontratës)
- Zgjidhja e problemit (analiza dhe zgjidhja e problemeve, pavarësisht nga origjina ose burimi i tyre, që zbulohen gjatë zhvillimit, funksionimit, mirëmbajtjes ose proceseve të tjera)
- Organizative
- Menaxhimi (aktivitetet dhe detyrat që mund të kryhen nga çdo palë që menaxhon proceset e tyre)
- Krijimi i infrastrukturës (përzgjedhja dhe mirëmbajtja e teknologjisë, standardeve dhe mjeteve, përzgjedhja dhe instalimi i harduerit dhe softuerit të përdorur për zhvillimin, funksionimin ose mirëmbajtjen e softuerit)
- Përmirësimi (vlerësimi, matja, kontrolli dhe përmirësimi i proceseve të ciklit jetësor)
- Trajnimi (trajnimi fillestar dhe zhvillimi i vazhdueshëm i stafit)
Çdo proces përfshin një sërë aktivitetesh. Për shembull, procesi i blerjes mbulon hapat e mëposhtëm:
- Fillimi i blerjes
- Përgatitja e ofertave
- Përgatitja dhe rregullimi i kontratës
- Mbikëqyrja e furnizuesit
- Pranimi dhe përfundimi i punimeve
Çdo veprim përfshin një numër detyrash. Për shembull, përgatitja e ofertave duhet të përfshijë:
- Formimi i kërkesave për sistemin
- Formimi i një liste të produkteve softuerike
- Vendosja e kushteve dhe marrëveshjeve
- Përshkrimi i kufizimeve teknike (mjedisi i funksionimit të sistemit, etj.)
Fazat e ciklit jetësor të softuerit, marrëdhënia ndërmjet proceseve dhe fazave
Modeli i ciklit jetësor të softuerit- një strukturë që përcakton sekuencën e ekzekutimit dhe marrëdhënien 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.
Standardi GOST R ISO/IEC 12207-2010 nuk ofron një model specifik të ciklit jetësor. Dispozitat e tij janë të zakonshme për çdo model të ciklit jetësor, metoda dhe teknologji për krijimin e IP. Ai përshkruan strukturën e proceseve të ciklit jetësor pa specifikuar mënyrën e zbatimit ose kryerjes së aktiviteteve dhe detyrave të përfshira në këto procese.
Modeli i ciklit jetësor të softuerit përfshin:
- fazat;
- Rezultatet e punës në çdo fazë;
- Ngjarjet kryesore - pikat e përfundimit të punës dhe vendimmarrjes.
