Shënim: Koncepti i procesit të zhvillimit të softuerit. Procesi universal. procesi aktual. proces specifik. proces standard. Permiresimi i procesit. Strategjitë e tërheqjes/shtyrjes. Modelet klasike të procesit: modeli i ujëvarës, modeli spirale. Fazat dhe aktivitetet.

Avantazhi i këtij modeli ishte kufizimi i mundësisë së kthimit në një hap mbrapa arbitrar, për shembull, nga testimi në analizë, nga zhvillimi në punën me kërkesat, etj. U vu re se kthime të tilla mund të rrisin në mënyrë katastrofike koston e projektit dhe kohën e zbatimit të tij. Për shembull, nëse gjatë testimit gjenden gabime në projektim ose analizë, rregullimi i tyre shpesh rezulton në një ridizajnim të plotë të sistemit. Ky model lejoi vetëm kthimin në hapin e mëparshëm, për shembull, nga testimi në kodim, nga softueri ky model u kritikua në mënyrë aktive nga pothuajse çdo autor i artikujve dhe teksteve përkatëse. Është bërë përgjithësisht e pranuar se nuk pasqyron veçoritë e zhvillimit të softuerit. Disavantazhet e modelit të ujëvarës janë:

• identifikimi i fazave dhe aktiviteteve, që sjell një humbje të fleksibilitetit të zhvillimit, në veçanti, vështirësinë për të mbështetur një proces zhvillimi përsëritës;
• kërkesa për përfundimin e plotë të fazës së aktivitetit, duke fiksuar rezultatet në formën e një dokumenti burimor të detajuar (termi i referencës, specifikimi i projektit); megjithatë, përvoja e zhvillimit të softuerit tregon se nuk është e mundur të plotësohen plotësisht zhvillimi i kërkesave, dizajnimi i sistemit, etj. - e gjithë kjo mund të ndryshojë; dhe arsyet këtu nuk janë vetëm se mjedisi i projektit është i lëvizshëm, por edhe se nuk është e mundur të përcaktohen dhe formulohen me saktësi shumë vendime paraprakisht, ato qartësohen dhe rafinohen vetëm më vonë;
• integrimi i të gjitha rezultateve të zhvillimit ndodh në fund, si rezultat i të cilit problemet e integrimit ndihen shumë vonë;
• përdoruesit dhe klienti nuk mund të njihen me opsionet e sistemit gjatë zhvillimit dhe ta shohin rezultatin vetëm në fund; kështu, ato nuk mund të ndikojnë në procesin e krijimit të sistemit dhe për rrjedhojë rriten rreziqet e keqkuptimit ndërmjet zhvilluesve dhe përdoruesve/klientëve;
• modeli është i paqëndrueshëm ndaj dështimeve në financimin e projekteve apo rishpërndarjen e fondeve, zhvillimi që ka nisur, në fakt nuk ka alternativa “në lëvizje”.

Megjithatë këtë model vazhdon të përdoret në praktikë - për projekte të vogla ose në zhvillimin e sistemeve tipike, ku përsëritja nuk është aq e kërkuar. Me ndihmën e tij, është i përshtatshëm për të gjurmuar zhvillimin dhe për të kryer kontrollin në faza mbi projektin. Ky model përdoret gjithashtu shpesh në projektet në det të hapur 1 Nga offshore angleze - jashtë bregdetit, në një interpretim të zgjeruar - jashtë një vendi. me paga për orë. Modeli i ujëvarës ka hyrë si pjesë përbërëse e modeleve dhe metodologjive të tjera, për shembull, në MSF.

model spirale u propozua nga Bary Boehm në 1988 për të kapërcyer mangësitë e modelit të ujëvarës, kryesisht për menaxhim më të mirë të rrezikut. Sipas këtij modeli, zhvillimi i produktit kryhet në një spirale, çdo kthesë e së cilës është një fazë e caktuar e zhvillimit. Ndryshe nga modeli i ujëvarës, modeli spirale nuk ka një grup kthesash të paracaktuar dhe të detyrueshëm, çdo kthesë mund të jetë e fundit në zhvillimin e sistemit, kur të përfundojë, hartohen planet për kthesën tjetër. Së fundi, spiralja është vetëm një fazë dhe jo një lloj aktiviteti, pasi në modelin e ujëvarës mund të kryhen shumë lloje të ndryshme aktiviteti brenda kornizës së saj, domethënë modeli është dydimensional.

Sekuenca e kthesave mund të jetë si më poshtë: në kthesën e parë, merret një vendim për këshillueshmërinë e krijimit të softuerit, në tjetrën Kërkesat e sistemit , pastaj kryhet dizajnimi i sistemit etj. Kthesat mund të kenë kuptime të tjera.

Çdo spirale ka strukturën (sektorët) e mëposhtëm:

• përcaktimi i qëllimeve, kufizimeve dhe alternativave të projektit;
• vlerësimi i alternativave, vlerësimi dhe zgjidhja e rreziqeve; është e mundur të përdoret prototipizim (përfshirë krijimin e një sërë prototipash), simulimin e sistemit, modelimin vizual dhe analizën e specifikimeve; fokusimi në pjesët më të rrezikshme të projektit;
• zhvillimi dhe testimi - këtu është i mundur një model ujëvarë ose përdorimi i modeleve dhe metodave të tjera të zhvillimit të softuerit;
• planifikimi për përsëritjet e ardhshme - analizohen rezultatet, planet dhe burimet për zhvillimin e mëvonshëm, merret një vendim (ose jo) për një raund të ri; analizohet nëse ka kuptim të vazhdohet me zhvillimin e sistemit apo jo; zhvillimi mund të pezullohet, për shembull, për shkak të ndërprerjeve në financim; model spirale ju lejon ta bëni atë në mënyrë korrekte.

Një spirale e vetme mund të korrespondojë me zhvillimin e disa komponentëve të softuerit ose futjen e ndryshimeve të ardhshme në produkt. Kështu, modeli mund të ketë një dimension të tretë.

Modeli spirale është i papërshtatshëm për t'u aplikuar në projekte me shkallë të ulët rreziku, me buxhet të kufizuar, për projekte të vogla. Përveç kësaj, mungesa e mjeteve të mira të prototipit mund ta bëjë të papërshtatshëm përdorimin e modelit spirale.

model spirale nuk gjeti aplikim të gjerë në industri dhe është i rëndësishëm, përkundrazi, në aspektin historik dhe metodologjik: është modeli i parë përsëritës, ka një metaforë të bukur - një spirale, dhe, si modeli i ujëvarës, u përdor më vonë për të krijuar modele të tjera të procesit dhe metodologji të zhvillimit të softuerit.

Zhvillimi i produkteve softuerike njeh shumë metodologji të denja - me fjalë të tjera, praktika më të mira të vendosura mirë. Zgjedhja varet nga specifikat e projektit, sistemi i buxhetimit, preferencat subjektive dhe madje edhe temperamenti i menaxherit. Artikulli përshkruan metodologjitë që hasim rregullisht në Edison.

1. "Modeli i ujëvarës" (modeli i kaskadës ose "ujëvara")

Një nga më të vjetrat, përfshin kalimin e njëpasnjëshëm të fazave, secila prej të cilave duhet të përfundojë plotësisht përpara fillimit të fazës tjetër. Është e lehtë të menaxhosh një projekt në modelin Waterfall. Për shkak të ngurtësisë së tij, zhvillimi është i shpejtë, kostoja dhe koha janë të paracaktuara. Por kjo është një thikë me dy tehe. Modeli i ujëvarës do të funksionojë mirë vetëm për projektet me kërkesa të përcaktuara qartë dhe mënyrën se si ato do të zbatohen. Nuk ka asnjë mënyrë për të bërë një hap prapa, testimi fillon vetëm pasi zhvillimi është i plotë ose pothuajse i përfunduar. Produktet e zhvilluara sipas këtij modeli pa një zgjedhje të justifikuar mund të kenë mangësi (lista e kërkesave nuk mund të rregullohet në çdo kohë), të cilat bëhen të njohura vetëm në fund për shkak të sekuencës së rreptë të veprimeve. Kostoja e bërjes së ndryshimeve është e lartë, pasi duhet të prisni që të përfundojë i gjithë projekti për ta inicializuar. Megjithatë, kostoja fikse shpesh tejkalon anët negative të qasjes. Korrigjimi i mangësive të realizuara gjatë procesit të krijimit është i mundur dhe, sipas përvojës sonë, kërkon një deri në tre marrëveshje shtesë të kontratës me një specifikim të vogël teknik.

Me ndihmën e modelit të ujëvarës, ne kemi krijuar shumë projekte nga e para, duke përfshirë zhvillimin e vetëm specifikimeve teknike. Projektet për të cilat është shkruar në Habré: e mesme - , e vogël - .

Kur të përdoret metodologjia e ujëvarës?

• Vetëm kur kërkesat njihen, kuptohen dhe rregullohen. Nuk ka kërkesa kontradiktore.
• Nuk ka probleme me disponueshmërinë e programuesve të kualifikimeve të kërkuara.
• Për projekte relativisht të vogla.

2. "V-Model"

Trashëgoi strukturën hap pas hapi nga modeli i ujëvarës. Modeli në formë V është i zbatueshëm për sistemet që janë veçanërisht të rëndësishme për funksionimin e pandërprerë. Për shembull, programet e aplikimit në klinikat për monitorimin e pacientëve, softuer të integruar për mekanizmat e kontrollit të airbagëve të urgjencës në automjete, etj. Një tipar i modelit mund të konsiderohet se ai synon një kontroll dhe testim të plotë të produktit, i cili tashmë është në fazat fillestare të projektimit. Faza e testimit kryhet njëkohësisht me fazën përkatëse të zhvillimit, për shembull testet e njësisë shkruhen gjatë kodimit.

Një shembull i punës sonë bazuar në metodologjinë V - një aplikacion mobil për evropianët operatori celular, e cila kursen kostot e roaming gjatë udhëtimit. Projekti kryhet sipas një TOR të qartë, por përfshin një fazë të rëndësishme të testimit: komoditetin e ndërfaqes, funksionalitetin, ngarkesën, përfshirë integrimin, i cili duhet të konfirmojë që disa komponentë nga prodhues të ndryshëm punojnë së bashku në mënyrë të qëndrueshme, vjedhja e parave dhe kredia është e pamundur.

Kur të përdoret modeli V?

• Nëse kërkohet testim i plotë i produktit, atëherë modeli V do të justifikojë idenë themelore: vërtetimin dhe verifikimin.
• Për projekte të vogla dhe të mesme ku kërkesat janë të përcaktuara dhe të fiksuara qartë.
• Duke pasur parasysh disponueshmërinë e inxhinierëve me kualifikimet e nevojshme, veçanërisht testuesit.

3. "Modeli rritës" (modeli inkremental)

Në një model inkremental, kërkesat e plota të sistemit ndahen në asamble të ndryshme. Terminologjia përdoret shpesh për të përshkruar një ndërtim në skenë të softuerit. Ka shumë cikle zhvillimi dhe së bashku ato përbëjnë ciklin jetësor me shumë ujëvara. Cikli është i ndarë në module më të vogla të krijuara lehtësisht. Çdo modul kalon nëpër fazat e përcaktimit të kërkesave, projektimit, kodimit, zbatimit dhe testimit. Procedura e zhvillimit sipas modelit inkremental përfshin lëshimin e produktit në fazën e parë kryesore në funksionalitetin bazë, dhe më pas shtimin e vazhdueshëm të veçorive të reja, të ashtuquajturat "rritje". Procesi vazhdon derisa të krijohet një sistem i plotë.

Modelet rritëse përdoren aty ku kërkesat individuale për ndryshim janë të qarta dhe mund të zyrtarizohen dhe zbatohen lehtësisht. Në projektet tona, ne e përdorëm atë për të krijuar lexuesin DefView dhe më pas rrjetin e bibliotekave dixhitale Vivaldi.

Si shembull, le të përshkruajmë thelbin e një rritjeje. zëvendësoi DefView. DefView dikur lidhej me një server dokumentesh, por tani mund të lidhet me shumë. Në faqen e një institucioni që dëshiron të transmetojë përmbajtjen e tij në një audiencë të caktuar, është instaluar një server ruajtjeje që akseson drejtpërdrejt dokumentet dhe i konverton ato në formatin e dëshiruar. U shfaq elementi rrënjësor i arkitekturës - serveri qendror Vivaldi, duke vepruar si një i vetëm motor kërkimi në të gjithë serverët e ruajtjes të instaluar në institucione të ndryshme.

Kur të përdorni një model në rritje?

• Kur kërkesat bazë për sistemin janë të përcaktuara dhe të kuptueshme qartë. Në të njëjtën kohë, disa detaje mund të përmirësohen me kalimin e kohës.
• Kërkon nisje të hershme në treg.
• Ka disa tipare ose qëllime të rrezikshme.

4. "Modeli RAD" (modeli i zhvillimit të shpejtë të aplikacionit ose zhvillimi i shpejtë i aplikacionit)

Modeli RAD është një variant i modelit rritës. Në modelin RAD, komponentët ose funksionet zhvillohen paralelisht nga disa ekipe shumë të aftë, si disa mini-projekte. Afati kohor i një cikli është rreptësisht i kufizuar. Modulet e krijuara më pas integrohen në një prototip pune. Synergy ju lejon të paraqisni shpejt diçka që funksionon tek klienti për rishikim në mënyrë që të merrni reagime dhe të bëni ndryshime.

Modeli i zhvillimit të shpejtë të aplikacionit përfshin fazat e mëposhtme:

• Modelimi i biznesit: përcaktimi i një liste të rrjedhave të informacionit ndërmjet departamenteve të ndryshme.
• Modelimi i të dhënave: Informacioni i mbledhur në hapin e mëparshëm përdoret për të përcaktuar objektet dhe entitetet e tjera të nevojshme për të qarkulluar informacionin.
• Modelimi i procesit: Rrjedhat e informacionit lidhin objektet për të arritur qëllimet e projektimit.
• Ndërtimi i aplikacionit: Përdor mjetet e ndërtimit automatik për të kthyer modelet CAD në kod.
• Testimi: janë testuar komponentë dhe ndërfaqe të reja.

Kur përdoret modeli RAD?

Mund të përdoret vetëm me arkitektë të kualifikuar dhe shumë të specializuar. Buxheti i projektit është mjaft i madh për të paguar këta specialistë, së bashku me koston e mjeteve të gatshme të montimit të automatizuara. Modeli RAD mund të zgjidhet nëse e njihni biznesin e synuar me besim dhe keni nevojë të prodhoni urgjentisht sistemin brenda 2-3 muajve.

5. "Modeli i shkathët" (metodologjia e zhvillimit të shkathët)

Në metodologjinë e zhvillimit "të shkathët", pas çdo përsëritjeje, klienti mund të vëzhgojë rezultatin dhe të kuptojë nëse e kënaq apo jo. Ky është një nga përfitimet e një modeli fleksibël. Disavantazhet e tij përfshijnë faktin se, për shkak të mungesës së formulimeve specifike të rezultateve, është e vështirë të vlerësohen kostot e punës dhe kostot e nevojshme për zhvillim. Programimi ekstrem (XP) është një nga aplikacionet më të njohura të modelit të shkathët në praktikë.

Ky lloj bazohet në takime të shkurtra ditore - "Scrum" dhe takime të përsëritura rregullisht (një herë në javë, një herë në dy javë ose një herë në muaj) të quajtura "Sprint". Në takimet e përditshme, anëtarët e ekipit diskutojnë:

• një raport mbi punën e bërë që nga Scrum-i i fundit;
• një listë e detyrave që punonjësi duhet të kryejë përpara takimit të ardhshëm;
• vështirësitë e hasura gjatë punës.

Metodologjia është e përshtatshme për projekte të mëdha ose afatgjata që po përshtaten vazhdimisht me kushtet e tregut. Prandaj, në procesin e zbatimit, kërkesat ndryshojnë. Vlen të kujtohet klasa e njerëzve krijues që priren të gjenerojnë, nxjerrin dhe testojnë ide të reja çdo javë apo edhe çdo ditë. Zhvillimi i shkathët është më i përshtatshmi për këtë lloj lideri. Ne zhvillojmë startup të brendshëm të kompanisë duke përdorur Agile. Një shembull i projekteve të klientëve është Sistemi Elektronik i Ekzaminimeve Mjekësore, i krijuar për të kryer ekzaminime masive mjekësore në pak minuta. Në paragrafin e dytë të këtij rishikimi, partnerët tanë amerikanë përshkruan një gjë shumë të rëndësishme, thelbësore për suksesin në Agile.

Kur të përdorni Agile?

• Kur nevojat e përdoruesve ndryshojnë vazhdimisht në një biznes dinamik.
• Ndryshimet e shkathëta zbatohen me një kosto më të ulët për shkak të rritjeve të shpeshta.
• Ndryshe nga modeli i ujëvarës, modelit të shkathët i duhet vetëm pak planifikim për të nisur një projekt.

6. "Modeli përsëritës" (modeli përsëritës ose përsëritës)

Modeli i përsëritur i ciklit jetësor nuk kërkon një specifikim të plotë të kërkesave për të filluar. Në vend të kësaj, krijimi fillon me zbatimin e një pjese të funksionalitetit, e cila bëhet baza për përcaktimin e kërkesave të mëtejshme. Ky proces përsëritet. Versioni mund të mos jetë i përsosur, gjëja kryesore është se funksionon. Duke kuptuar qëllimin përfundimtar, ne përpiqemi për të në mënyrë që çdo hap të jetë efektiv dhe çdo version të jetë i zbatueshëm.

Diagrami tregon një "zhvillim" përsëritës të Mona Lizës. Siç mund ta shihni, në përsëritjen e parë ka vetëm një skicë të Mona Lizës, në të dytën - shfaqen ngjyrat, dhe përsëritja e tretë shton detaje, ngopje dhe përfundon procesin. Në modelin inkremental, funksionaliteti i produktit ndërtohet pak nga pak, produkti përbëhet nga pjesë. Ndryshe nga modeli përsëritës, çdo pjesë është një element integral.

Një shembull i zhvillimit përsëritës është njohja e zërit. Hulumtimi dhe përgatitja e parë e aparatit shkencor filloi shumë kohë më parë, në fillim - në mendime, pastaj - në letër. Me çdo përsëritje të re, cilësia e njohjes përmirësohej. Sidoqoftë, njohja e përsosur ende nuk është arritur, prandaj, problemi ende nuk është zgjidhur plotësisht.

Kur është koha më e mirë për të përdorur një model përsëritës?

• Kërkesat për sistemin përfundimtar janë përcaktuar qartë dhe kuptohen paraprakisht.
• Projekti është i madh ose shumë i madh.
• Detyra kryesore duhet të përcaktohet, por detajet e zbatimit mund të evoluojnë me kalimin e kohës.

7. "Spiral Model" (modeli spirale)

"Modeli spirale" është i ngjashëm me modelin inkremental, por me theks në analizën e rrezikut. Ai funksionon mirë për sfidat kritike të biznesit ku dështimi është i papajtueshëm me operacionet e kompanisë, linjat e reja të produkteve, kërkimin dhe provat në terren.

Modeli spirale supozon 4 faza për çdo kthesë:

1. planifikimi;
2. analiza e rrezikut;
3. ndërtimi;
4. vlerësimi i rezultatit dhe, nëse cilësia është e kënaqshme, kalimi në një raund të ri.

Ky model nuk është i përshtatshëm për projekte të vogla, është i arsyeshëm për ato komplekse dhe të shtrenjta, siç është zhvillimi i një sistemi të menaxhimit të dokumenteve për një bankë, kur çdo hap tjetër kërkon më shumë analiza për të vlerësuar pasojat sesa programim. Në projektin për zhvillimin e një EDMS për ODU të Siberisë SO UES, dy takime për ndryshimin e kodifikimit të seksioneve të një arkivi elektronik marrin 10 herë më shumë kohë sesa një programues që kombinon dy dosje. Projektet shtetërore në të cilat kemi marrë pjesë filluan me përgatitjen nga ana e komunitetit të ekspertëve të një koncepti të shtrenjtë, i cili nuk është gjithmonë i padobishëm, pasi jep rezultate në shkallë kombëtare.

Le të përmbledhim

Sllajdi tregon ndryshimet midis dy metodologjive më të zakonshme.

Në praktikën moderne, modelet e zhvillimit të softuerit janë shumëvariare. Nuk ka asnjë të drejtë për të gjitha projektet, kushtet e fillimit dhe modelet e pagesës. Edhe Agile, aq i dashur nga të gjithë ne, nuk mund të aplikohet kudo për shkak të papërgatitjes së disa klientëve apo pamundësisë së financimit fleksibël. Metodologjitë pjesërisht mbivendosen në mjete dhe janë disi të ngjashme me njëra-tjetrën. Disa koncepte të tjera u përdorën vetëm për të promovuar përpiluesit e tyre dhe nuk sollën asgjë të re në praktikë.

Rreth teknologjive të zhvillimit:
.
.
.
.

Çfarë metodologjish përdorni?