Qasje për zhvillimin e softuerit. Qasja Strukturore

1.Kodimi

Në fazën e zhvillimit të softuerit kryhen këto veprime kryesore: kodimi; duke testuar; zhvillimi i sistemit të ndihmës së PP; krijimi i dokumentacionit të përdoruesit; krijimi i versionit dhe instalimi i softuerit,

Kodimi është procesi i konvertimit të rezultateve të dizajnit të nivelit të lartë dhe të nivelit të ulët në një produkt softuerik të përfunduar. Me fjalë të tjera, gjatë kodimit, modeli i kompiluar PP përshkruhet me anë të gjuhës së programimit të zgjedhur, e cila mund të jetë ndonjë nga gjuhët ekzistuese. Zgjedhja e gjuhës kryhet ose me kërkesë të klientit, ose duke marrë parasysh problemin që zgjidhet dhe përvojën personale të zhvilluesve.

Kur kodoni, është e nevojshme të ndiqni standardin për gjuhën e zgjedhur, për shembull, për gjuhën C është ANSI C, dhe për C ++ - ISO / IEC 14882 "Standartforthe C ++ ProgrammingLanguage".

Përveç standardit të pranuar përgjithësisht për një gjuhë programimi, kompania mund të përdorë gjithashtu kërkesat e veta shtesë për rregullat për shkrimin e programeve. Në thelb, ato lidhen me rregullat për formatimin e tekstit të programit.

Ndjekja e standardeve dhe rregullave të kompanisë ju lejon të krijoni një program funksional të saktë, lehtësisht të lexueshëm, të kuptueshëm për zhvilluesit e tjerë, që përmban informacione për zhvilluesin, datën e krijimit, emrin dhe qëllimin, si dhe të dhënat e nevojshme për menaxhimin e konfigurimit.

Në fazën e kodimit, programuesi shkruan programe dhe i teston ato vetë. Ky testim quhet testim i njësisë. Të gjitha çështjet që lidhen me testimin e PCB janë diskutuar në Kre. 10, ai përshkruan gjithashtu teknologjinë e testimit që përdoret në fazën e zhvillimit të softuerit. Kjo teknologji quhet testim "Glass box" (xhamakut); ndonjëherë quhet edhe testim Kutia e bardhë në krahasim me konceptin klasik blackbox.

Gjatë testimit të "kutisë së zezë", programi konsiderohet si një objekt, struktura e brendshme e të cilit nuk dihet. Testuesi fut të dhëna dhe analizon rezultatin, por ai nuk e di saktësisht se si funksionon programi. Duke zgjedhur teste, një specialist kërkon të dhëna hyrëse dhe kushte që janë interesante nga këndvështrimi i tij, të cilat mund të çojnë në rezultate jo standarde. Ai është kryesisht i interesuar për ata përfaqësues të secilës klasë të të dhënave hyrëse, në të cilat gabimet e programit në provë kanë më shumë gjasa të shfaqen.

Gjatë testimit të "kutisë së qelqit", situata është krejtësisht e ndryshme. Testuesi (në këtë rast vetë programuesi) zhvillon teste bazuar në njohuritë e kodit burimor në të cilin ai ka akses të plotë. Si rezultat, ai merr përfitimet e mëposhtme.

1. Fokusi i testimit. Programuesi mund ta testojë programin në pjesë, të zhvillojë rutina të veçanta testimi që thërrasin modulin nën provë dhe t'i kalojnë të dhënat me interes programuesit. Një modul individual është shumë më i lehtë për t'u testuar si një "kuti xhami".

2. Mbulimi i plotë i kodit. Programuesi gjithmonë mund të përcaktojë se cilat pjesë të kodit po ekzekutohen në çdo test. Ai sheh se cilat degë të tjera të kodit mbeten të patestuara dhe mund të zgjedhë kushtet në të cilat ato do të testohen. Më poshtë përshkruan se si të gjurmoni mbulimin e kodit tuaj nga testet që kryeni.

3. Aftësia për të kontrolluar rrjedhën e komandave. Programuesi e di gjithmonë se cili funksion duhet të ekzekutohet më pas në program dhe cila duhet të jetë gjendja e tij aktuale. Për të zbuluar nëse një program funksionon ashtu siç mendon, një programues mund të përfshijë në të komandat e korrigjimit që shfaqin informacion në lidhje me ecurinë e ekzekutimit të tij, ose të përdorë një pjesë të veçantë të softuerit të quajtur korrigjues për ta bërë këtë. Debugger mund të bëjë shumë gjëra të dobishme: gjurmoni dhe ndryshoni sekuencën e ekzekutimit të komandave të programit, tregoni përmbajtjen e variablave të tij dhe adresat e tyre në memorie, etj.

4. Aftësia për të gjurmuar integritetin e të dhënave. Programuesi e di se cila pjesë e programit duhet të ndryshojë çdo element të të dhënave. Duke gjurmuar gjendjen e të dhënave (duke përdorur të njëjtin korrigjues), ai mund të identifikojë gabime të tilla si ndryshimi i të dhënave nga modulet e gabuara, keqinterpretimi i tyre ose organizimi i pasuksesshëm. Programuesi mund të automatizojë testimin vetë.

5.Vizioni i pikave të kufirit të brendshëm. Në kodin burimor, ju mund të shihni ato pika kufitare të programit që janë të fshehura nga pamja e jashtme. Për shembull, disa algoritme krejtësisht të ndryshme mund të përdoren për të kryer një veprim të caktuar dhe është e pamundur të përcaktohet se cilin prej tyre ka zgjedhur programuesi pa shikuar kodin. Një shembull tjetër i zakonshëm do të ishte një problem i tejmbushjes së tamponit që përdoret për të ruajtur përkohësisht të dhënat hyrëse. Programuesi mund të tregojë menjëherë se sa të dhëna do të vërshojnë buferi dhe ai nuk ka nevojë të kryejë mijëra teste.

6. Mundësia e testimit, e përcaktuar nga algoritmi i përzgjedhur. Testimi i përpunimit të të dhënave që përdor algoritme shumë komplekse llogaritëse mund të kërkojë teknologji të veçantë. Transformimet e matricës dhe renditja e të dhënave janë shembuj klasikë. Një testues, ndryshe nga një programues, duhet të dijë saktësisht se cilat algoritme përdoren, ndaj duhet t'i drejtohet literaturës speciale.

Testimi i kutisë së qelqit është pjesë e procesit të programimit. Programuesit e bëjnë këtë punë gjatë gjithë kohës, ata testojnë çdo modul pasi e shkruajnë atë, dhe pastaj përsëri pasi e integrojnë atë në sistem.

Kur kryeni testimin e njësisë, mund të përdorni ose testimin strukturor, testimin funksional ose të dyja.

Strukturore testimi është një lloj testimi i kutisë së qelqit. Ideja e tij kryesore është zgjedhja e saktë e rrugës së testuar të softuerit. Përballë tij funksionale testimi i përket kategorisë së testimit të kutisë së zezë. Çdo funksion i programit testohet duke futur hyrjet e tij dhe duke analizuar rezultatet. Në të njëjtën kohë, struktura e brendshme e programit merret parasysh shumë rrallë.

Megjithëse testimi strukturor ka një bazë teorike shumë më të fuqishme, testimi funksional preferohet nga shumica e testuesve. Testimi strukturor i jep veten më mirë modelimit matematik, por kjo nuk do të thotë se është më efektiv. Secila prej teknologjive ju lejon të identifikoni gabimet që mungojnë në rastin e përdorimit të tjetrës. Nga ky këndvështrim, ato mund të quhen po aq efektive.

Objekti i testimit mund të jetë jo vetëm rruga e plotë e programit (sekuenca e komandave që ai ekzekuton nga fillimi deri në përfundim), por edhe seksionet e tij individuale. Është absolutisht joreale të testohen të gjitha mënyrat e mundshme të ekzekutimit të programit. Prandaj, specialistët e testimit veçojnë ato grupe nga të gjitha rrugët e mundshme që duhet të testohen pa dështuar. Për përzgjedhje, ata përdorin kritere të veçanta të quajtura kriteret e mbulimit, të cilat përcaktojnë një numër shumë real (edhe pse mjaft të madh) testesh. Këto kritere nganjëherë referohen si kriteret logjike të mbulimit, ose kriteret e plotësisë.

3. Zhvillimi i sistemit të ndihmës së produktit softuer. Krijimi i dokumentacionit të përdoruesit

Këshillohet që të caktohet një nga stafi i projektit si redaktor teknik i dokumentacionit. Ky punonjës mund të kryejë punë të tjera, por detyra e tij kryesore duhet të jetë analiza e dokumentacionit, edhe nëse është duke u zhvilluar nga punonjës të tjerë.

Ndodh shpesh që disa njerëz janë duke punuar për krijimin e një softueri, por asnjëri prej tyre nuk mban përgjegjësi të plotë për cilësinë e tij. Si rezultat, PP jo vetëm që nuk përfiton nga fakti që zhvillohet nga më shumë njerëz, por edhe humbet, sepse secili në mënyrë të pandërgjegjshme kalon përgjegjësinë te tjetri dhe pret që kjo apo ajo pjesë e punës të bëhet nga kolegët e tij. . Ky problem zgjidhet me emërimin e një redaktori i cili mban përgjegjësi të plotë për cilësinë dhe saktësinë e dokumentacionit teknik.

Sistemi i ndihmës PP është formuar në bazë të materialit të zhvilluar për manualin e përdoruesit. Ajo formohet dhe krijohet nga personi përgjegjës për kryerjen e kësaj pune. Mund të jetë ose një redaktues teknik ose një nga zhvilluesit së bashku me një redaktues teknik.

Një PCB e mirë-dokumentuar ka përparësitë e mëposhtme.

1. Lehtësia e përdorimit. Nëse PP është e dokumentuar mirë, atëherë është shumë më e lehtë të aplikohet. Përdoruesit e mësojnë atë më shpejt, bëjnë më pak gabime dhe, si rezultat, e bëjnë punën e tyre më shpejt dhe me efikasitet.

2. Kosto më e ulët e mbështetjes teknike. Kur përdoruesi nuk mund të kuptojë se si të kryejë veprimet që i nevojiten, ai thërret prodhuesin e PCB-së në shërbimin e mbështetjes teknike. Mirëmbajtja e një shërbimi të tillë është shumë e shtrenjtë. Udhëzimet e mira i ndihmojnë përdoruesit të zgjidhin vetë problemet dhe kanë më pak nevojë të kontaktojnë ekipin e mbështetjes teknike.

3. Besueshmëri e lartë. Dokumentacioni i pakuptueshëm ose i ngathët e bën softuerin më pak të besueshëm, sepse përdoruesit e tij bëjnë gabime më shpesh, është e vështirë për ta të kuptojnë se cili është shkaku i tyre dhe si të përballen me pasojat e tyre.

Lehtësia e mirëmbajtjes. Një sasi e madhe parash dhe kohe është shpenzuar për të analizuar problemet që shkaktohen nga gabimet e përdoruesve. Ndryshimet e bëra në versionet e reja të softuerit janë shpesh vetëm një ndryshim në ndërfaqen e funksioneve të vjetra. Ato janë prezantuar në mënyrë që përdoruesit më në fund të kuptojnë se si të përdorin softuerin dhe të ndalojnë thirrjen e mbështetjes teknike. Udhëheqje e mirë pak a shumë

Kur merret parasysh teknologjia e zhvillimit të softuerit, është e nevojshme të përdoret një qasje sistematike, e cila përfshin marrjen në konsideratë jo të disa aspekteve individuale të problemit të zhvillimit të softuerit, por të problemit në tërësi. Qasja sistemore zbatohet në hapësirë ​​dhe kohë.

Një qasje sistematike në kohë merr parasysh sekuencën e fazave të zhvillimit të softuerit që nga momenti i formimit të një nevoje të paplotësuar për softuer deri në zgjidhjen e tij dhe mirëmbajtjen në funksionim të produktit softuerik që rezulton.

Qasja e sistemeve në "hapësirë" parashikon marrjen në konsideratë të softuerit të zhvilluar si pjesë e sistemit. Në të njëjtën kohë, bazuar në studimin e nevojave informative të sistemit, i cili do të përfshijë softuerin e zhvilluar, formulohen qëllimet dhe një sërë funksionesh softuerike, analizohen prototipet e softuerit. Kërkesat për softuer janë formuar dhe dokumentuar.

Teknologjia moderne e zhvillimit të softuerit e konsideron programimin si një nga fazat e zhvillimit në zinxhirin e fazave të njëpasnjëshme të ciklit të zhvillimit. Të gjitha këto faza janë të bashkuara nga koncepti i ciklit jetësor të softuerit dhe duhet të mbështeten nga mjetet e duhura softuerike dhe harduerike.

Në përputhje me standardin ndërkombëtar ISO / IEC 12207 "Teknologjia e informacionit - Proceset e ciklit jetësor të softuerit", procesi i zhvillimit të softuerit përmban fazat e mëposhtme të ciklit jetësor të softuerit:

1) analiza e kërkesave të sistemit dhe fushëveprimit;

2) dizajni i arkitekturës së sistemit;

3) analiza e kërkesave të softuerit (specifikimet, ndërfaqet e jashtme,);

4) dizajni i arkitekturës së softuerit;

5) dizajni i detajuar i secilës njësi softuerike;

6) kodimi i softuerit (programimi)

7) testimi i njësive softuerike;

8) integrimi (bashkimi i softuerit) dhe testimi i një sërë njësive softuerike;

9) testet e kualifikimit të softuerit (testimi kompleks);

10) njësitë e integrimit të sistemit të strukturës së softuerit duhet të kombinohen me njësi të harduerit;

11) testet e kualifikimit të sistemit;

12) instalimi i softuerit.

Kështu, procesi i zhvillimit të softuerit fillon nga sistemi ku do të përdoret ky softuer dhe përfundon përsëri në sistem.

Pas fazave të zhvillimit në ciklin jetësor të softuerit, vijon faza e funksionimit dhe mirëmbajtjes së softuerit. Ndonjëherë jepet një listë fazash në ciklin jetësor të softuerit me disa përgjithësime (zgjerime) të 12 fazave të dhëna. Për shembull, fazat e projektimit të sistemit dhe përcaktimi i kërkesave të softuerit, dizajnimi i një pakete softuerike, dizajnimi i algoritmeve të softuerit, programimi (kodimi), korrigjimi i softuerit offline, korrigjimi i integruar i softuerit, funksionimi i softuerit.

Neglizhimi i fazave të projektimit të softuerit, përpjekja për të filluar programimin menjëherë pa përpunuar mjaftueshëm algoritme dhe çështje të ndërveprimit midis njësive strukturore të softuerit shpesh çon në një proces kaotik të zhvillimit të softuerit me pak shanse suksesi.

Modeli spirale i ciklit jetësor të softuerit. Teknologjitë e zhvillimit të softuerit "të rëndë dhe të lehtë" (të shpejtë).

Modeli i konsideruar i ciklit jetësor (LC) i referohet modelit të tipit kaskadë. Ky lloj modeli i ciklit jetësor është i mirë për softuerin, për të cilin në fillim të zhvillimit është e mundur të formulohen plotësisht dhe me saktësi të gjitha kërkesat e softuerit.

Diagrami i ciklit jetësor spirale të softuerit. Megjithatë, procesi real i zhvillimit të softuerit nuk përshtatet gjithmonë në një skemë kaq të ngurtë dhe shpeshherë lind nevoja për t'u kthyer në fazat e mëparshme me sqarime ose rishikim të vendimeve të marra.

Për softuerin, si dhe për sistemet e tjera komplekse, kërkesat fillestare për të cilat nuk janë mjaftueshëm të plota, është karakteristik një proces zhvillimi përsëritës. Në të njëjtën kohë, për disa lloje softuerësh, madje është e dëshirueshme që të kaloni në fazën tjetër sa më shpejt që të jetë e mundur. Në të njëjtën kohë, disavantazhet e pashmangshme me një punë të tillë të nxituar eliminohen në përsëritjen tjetër ose mbeten përgjithmonë.

Detyra kryesore është arritja e softuerit të zbatueshëm sa më shpejt që të jetë e mundur, duke aktivizuar në këtë mënyrë procesin e specifikimit dhe plotësimit të kërkesave. Ky është i ashtuquajturi model spirale i ciklit jetësor të softuerit.

Në çdo kthesë të spirales, krijohet një version i produktit, specifikohen kërkesat për softuerin dhe planifikohet puna e kthesës tjetër. Modeli spirale i ciklit jetësor të softuerit pasqyron procesin ekzistues objektiv të zhvillimit të softuerit përsëritës (Fig. 8.2).

Besohet se skema spirale e ciklit jetësor të softuerit është menduar jo aq për zhvilluesit e nxituar sa për softuerin, versionet e para me cilësi të ulët të të cilave janë të pranueshme për qëllimin funksional të softuerit.

Ekziston Agile Software Development, i cili ofron një bazë ideologjike për pikëpamjet që lidhen me modelin e ciklit jetësor spirale. Këto teknologji bazohen në katër ide:

Ndërveprimi ndërveprues i individëve është më i rëndësishëm se procedurat dhe mjetet formale,

Puna e softuerit është më e rëndësishme sesa të kesh dokumentacion për të,

Bashkëpunimi me klientin është më i rëndësishëm se kontratat formale,

Një përgjigje e shpejtë ndaj ndryshimeve të jashtme është më e rëndësishme sesa respektimi i rreptë i planeve të përshkruara.

Oriz. 8.2 - Skema e softuerit të ciklit jetësor spirale

Me fjalë të tjera, teknologjitë e shpejta synojnë të zëvendësojnë procedurat e ndërveprimit të dokumentuara formale dhe që kërkojnë kohë gjatë zhvillimit me ato interaktive, gjë që është e mundur me një madhësi të vogël projekti, cilësi të zgjedhura të stafit, vendosjen e zhvilluesve dhe klientëve "në të njëjtën dhomë" dhe për zhvillimin e softuer për sisteme jo kritike.

Korrektësia e këtyre parimeve në një masë të caktuar, kur zhvillimi i softuerit kryhet nga një numër i vogël "fansish" të kualifikuar dhe të përkushtuar) për zhvillimin e llojeve të caktuara të softuerit është e vështirë të kundërshtohet. Megjithatë, teknologjitë Agile, dhe kjo njihet nga ideologët e tyre, janë të zbatueshme në projektet softuerike të një klase dhe shkalle të caktuar, njësoj si modeli i ciklit jetësor spirale në përgjithësi, përkatësisht kur gabimet e softuerit çojnë në disa shqetësime ose humbje të fondeve të rimbursueshme.

Kur softueri që funksionon gabimisht çon në një kërcënim për jetën e njerëzve ose në humbje të mëdha materiale, duhet të përdoren teknologji të plota të menduara mirë për të siguruar besueshmërinë e produktit softuer.

Me një rritje në shkallën e një projekti softuerësh, një rritje të numrit të njerëzve që marrin pjesë në të, rritet nevoja për një teknologji të ngurtë zhvillimi që përbën një cikli jetësor të softuerit ujëvarë. Këtu duhet dokumentacion, pasi në çdo moment është e mundur humbja e ndonjë prej zhvilluesve, formalizimi i lidhjeve ndërprogramore, menaxhimi i ndryshimit të softuerit etj. Jo më kot është futur një model i ciklit jetësor kaskadë në standardet e zhvillimit të softuerit. Në të njëjtën kohë, ju lejon gjithashtu të zbatoni një proces zhvillimi përsëritës për shkak të fazave të parashikuara në hartimin e CTS dhe softuerit për ta.

Për projekte shumë të mëdha softuerike (një ekip prej më shumë se 100 zhvilluesish), teknologjia e zhvillimit është një faktor kyç që ndikon jo vetëm në cilësinë e softuerit, por edhe në vetë mundësinë e krijimit të tij.

Teknologjitë e zhvillimit të softuerit "të rëndë dhe të lehtë". . Zhvilluesit e shumë llojeve të softuerit e shohin modelin e ujëvarës së ciklit jetësor shumë të rregulluar, shumë të dokumentuar dhe të rëndë, dhe për këtë arsye joracional. Ekziston Agile Software Development i cili ofron një bazë ideologjike për këto pikëpamje. Këto teknologji bazohen në katër ide:

1. Ndërveprimi ndërveprues i individëve është më i rëndësishëm se procedurat dhe mjetet formale,

2. Softueri i punës është më i rëndësishëm se disponueshmëria e dokumentacionit për të,

3. bashkëpunimi me klientin është më i rëndësishëm se kontratat formale me të,

4. reagimi i shpejtë ndaj ndryshimeve të jashtme është më i rëndësishëm sesa respektimi i rreptë i planeve të përshkruara.

Korrektësia e këtyre parimeve, përveç të tretit në një masë të caktuar (zhvillimi i softuerit kryhet nga një numër i vogël programuesish të kualifikuar - "tifozë" të cilët nuk kanë nevojë për kontroll dhe motivim shtesë) për zhvillimin e softuerit është e vështirë të kundërshtohet. Megjithatë, teknologjitë e shkathëta, dhe kjo njihet nga ideologët e tyre, janë të zbatueshme në projektet softuerike të një klase dhe shkalle të caktuar, si dhe në modelin e ciklit të jetës spirale në përgjithësi, përkatësisht kur gabimet e softuerit çojnë në disa shqetësime ose humbje të fondeve të rimbursueshme dhe ku kërkesat e softuerit ndryshojnë vazhdimisht. , pasi ato ishin të përcaktuara keq paraprakisht, dhe kërkohet përshtatje e shpejtë ndaj këtyre ndryshimeve.

Teknologjitë e shpejta - përpjekjet për të arritur një kompromis midis një disipline të rreptë zhvillimi dhe mungesës së plotë të saj në emër të reduktimit të fluksit të letrave që shoqërojnë zhvillimin.Teknologjitë e shpejta nuk mund të sigurojnë besueshmëri të lartë të një produkti softuer pikërisht për shkak të minimizimit të letrave që konfirmojnë ligjërisht përgjegjësinë e zhvilluesit .

Një shembull i teknologjisë Agile është Programimi Extreme (XP). Përsëritjet XP janë shumë të shkurtra dhe përbëhen nga katër hapa: kodimi, testimi, dëgjimi i klientit, dizajnimi. Parimet e XP - minimalizmi, thjeshtësia, përfshirja e klientit, cikli i shkurtër, ndërveprimi i ngushtë i zhvilluesve - ata duhet të ulen në të njëjtën dhomë, takimet e përditshme operacionale me klientin duken të arsyeshme dhe janë përdorur prej kohësh jo vetëm në teknologjitë e shpejta, por në XP ato kanë janë sjellë në vlera ekstreme.

Një analizë e shumë projekteve softuerike ka treguar se teknologjitë e lehta që predikojnë parimet e vetëorganizimit, duke theksuar përdorimin e aftësive individuale të zhvilluesve, përsëritjet e shkurtra të zhvillimit në një model spirale, XP, SCRUM janë të zakonshme dhe shpesh çojnë në sukses, duke përfituar sa më shumë. të veçorive të punës në ekipe të vogla.

Aty ku softueri që funksionon gabimisht çon në një kërcënim për jetën e njerëzve ose në humbje të mëdha materiale, duhet të përdoren teknologji të rregullta, të menduara plotësisht dhe të parashikueshme të formalizuara "të rënda" për të siguruar besueshmërinë e produktit softuer edhe në rastin e zhvilluesve të nivelit të mesëm. në të njerëzit nevoja për një teknologji të ngurtë dhe formale zhvillimi, duke fiksuar përgjegjësinë e secilit pjesëmarrës në zhvillim, duke përbërë një cikël jetësor të softuerit ujëvarë, po rritet. Jo më kot modeli i ciklit jetësor të kaskadës është futur në standardet e zhvillimit të softuerit.

Në ekipet e mëdha të zhvillimit, problemi i menaxhimit del në pah.

Për projekte shumë të mëdha softuerike, çështjet e zhvillimit të koordinuar të rregullt: strukturimi, integrimi, sigurimi i ndërveprimit korrekt të programeve, organizimi i zbatimit korrekt dhe të koordinuar të ndryshimeve të pashmangshme janë thelbësore. dhe ndikojnë në vetë mundësinë e krijimit të tyre.

Në projektet e vogla softuerike, përsosjet algoritmike, ndikimi i individëve individualë të talentuar luajnë një rol vendimtar, ndërsa në projektet e mëdha këta faktorë janë të niveluar dhe nuk kanë një ndikim vendimtar në procesin e zhvillimit.

Zhvilluesit e programeve kompjuterike me aftësi mesatare, dhe shumica e tyre, dhe duke iu përmbajtur disiplinës teknologjike brenda kornizës së teknologjisë së duhur, duhet të zhvillojnë softuer të cilësisë së kërkuar. Ruani rendin dhe ai do t'ju mbështesë.

Shënim: Janë marrë parasysh qasja fleksibël ndaj zhvillimit të softuerit, parimet bazë të zhvillimit të shkathët. Jepet një listë e teknikave që, në një masë të caktuar, korrespondojnë me parimet e zhvillimit të softuerit të shkathët. Janë analizuar vlerat dhe parimet kryesore të zhvillimit të shkathët.

Ju mund ta shkarkoni prezantimin për këtë ligjëratë.

Qëllimi i ligjëratës:

Merrni një kuptim të qëllimit dhe parimeve bazë të zhvillimit të softuerit të shkathët.

Prezantimi

Metodologjia e zhvillimit të softuerit të shkathët fokusohet në përdorimin e një qasje përsëritëse në të cilën software krijohet gradualisht, me hapa të vegjël, duke përfshirë zbatimin e një grupi specifik kërkesash. Kjo supozon se kërkesat janë subjekt i ndryshimit. Ekipet e shkathët janë të përbëra nga zhvillues të përgjithshëm që kryejnë detyra të ndryshme në procesin e zhvillimit të produktit softuer.

Kur përdoren metodologji të shkathëta, rreziqet minimizohen duke reduktuar zhvillimin në një seri ciklesh të shkurtra të quajtura përsëritjet, që zgjat 2-3 javë. Një përsëritje është një koleksion detyrash të planifikuara për të kryer gjatë një periudhe të caktuar kohore. Në çdo përsëritje, krijohet një version i zbatueshëm i sistemit softuerik, në të cilin prioriteti më i lartë (për këtë përsëritje) kërkesat e klientëve... Çdo përsëritje plotëson të gjitha detyrat e nevojshme për të krijuar softuer të zbatueshëm: planifikimin, analizën e kërkesave, dizajnimin, kodimin, testimin dhe duke dokumentuar... Edhe pse një përsëritje e veçantë zakonisht nuk është e mjaftueshme për të nxjerrë një version të ri të një produkti, kuptohet se aktuale software gati për lëshim në fund të çdo përsëritjeje. Në fund të çdo përsëritjeje, ekipi rivlerëson prioritetet e kërkesave për produktin softuerik, duke bërë ndoshta rregullime në zhvillimin e sistemit.

Parimet dhe rëndësia e zhvillimit të shkathët

Për metodologjinë e zhvillimit të shkathët, deklarohen postulatet kryesore që lejojnë ekipet të arrijnë performancë të lartë:

• njerëzit dhe ndërveprimet e tyre;
• dërgimi i softuerit të punës;
• bashkëpunimi me klientin;
• reagim ndaj ndryshimit.

Njerëzit dhe ndërveprimi. Njerëzit janë pjesa më e rëndësishme e suksesit. Anëtarët individualë të ekipit dhe komunikimi i mirë janë thelbësore për ekipet me performancë të lartë. Metodat e shkathët përfshijnë diskutime të shpeshta të rezultateve të punës dhe ndryshime në vendime për të lehtësuar komunikimin. Diskutimet mund të zhvillohen çdo ditë për disa minuta dhe në fund të çdo përsëritjeje me një analizë të rezultateve të punës dhe një retrospektivë. Për komunikim efektiv gjatë takimeve, anëtarët e ekipit duhet t'u përmbahen rregullave kryesore të mëposhtme të sjelljes:

• respekt për mendimin e secilit anëtar të ekipit;
• jini të sinqertë në çdo komunikim;
• transparenca e të gjitha të dhënave, veprimeve dhe vendimeve;
• besimi se secili pjesëmarrës do të mbështesë ekipin;
• përkushtimi ndaj ekipit dhe qëllimeve të tij.

Për të krijuar ekipe me performancë të lartë në metodologjitë e shkathëta, përveç një ekipi efektiv dhe komunikimit të mirë, nevojiten mjete të përsosura softuerike.

Softueri i punës është më i rëndësishëm se dokumentacioni gjithëpërfshirës. Të gjitha metodologjitë e shkathëta theksojnë nevojën për t'i dorëzuar klientit pjesë të vogla të softuerit të punës në intervale të caktuara. Software zakonisht duhet të kalojë nivelin e testimit të njësisë, testimin e nivelit të sistemit. Në të njëjtën kohë, sasia e dokumentacionit duhet të jetë minimale. Gjatë procesit të projektimit, ekipi duhet të mbajë të përditësuar një dokument të shkurtër që përmban arsyetimin për vendimin dhe një përshkrim të strukturës.

Bashkëpunimi me klientin është më i rëndësishëm se marrëveshjet kontraktuale formale. Që një projekt të përfundojë me sukses, kërkohet komunikim i rregullt dhe i shpeshtë me klientin. Klienti duhet të marrë pjesë rregullisht në diskutimin e vendimeve të marra në softuer, të shprehë dëshirat dhe komentet e tij. Përfshirja e klientit në procesin e zhvillimit të softuerit është e nevojshme për të krijuar një produkt cilësor.

Përgjegjshmëria ndaj ndryshimit është më e rëndësishme sesa t'i përmbahesh planit. Aftësia për të reaguar ndaj ndryshimit është kryesisht përgjegjëse për suksesin e një projekti softuerik. Në procesin e krijimit të një produkti softuer, ato shumë shpesh ndryshojnë kërkesat e klientëve... Konsumatorët shumë shpesh nuk e dinë saktësisht se çfarë duan derisa ta shohin atë duke funksionuar software... Metodologjitë e shkathëta kërkojnë reagime nga klientët në procesin e krijimit të një produkti softuer. Përgjegjshmëria ndaj ndryshimit është thelbësore për të krijuar një produkt që kënaq klientin dhe i jep vlerë biznesit.

Postulatet e zhvillimit të shkathët mbështeten nga 12 parime. Metodologjitë specifike të zhvillimit Agile përcaktojnë procese dhe rregulla që janë pak a shumë në përputhje me këto parime. Metodologjitë fleksibël për krijimin e produkteve softuerike bazohen në parimet e mëposhtme:

1. Kënaqësia e klientit është një përparësi kryesore duke ofruar softuer të dobishëm në një orar të ngushtë, të ndjekur nga përditësime të vazhdueshme. Praktikat e shkathët përfshijnë lëshimin e shpejtë fillestar dhe përditësimet e shpeshta. Qëllimi i ekipit është të japë një version të zbatueshëm brenda pak javësh nga fillimi i projektit. Më pas, sistemet softuerike me funksionalitet në rritje duhet të dërgohen çdo disa javë. Klienti mund të fillojë funksionimin komercial të sistemit nëse mendon se është mjaftueshëm funksional. Gjithashtu, klienti thjesht mund të njihet me versionin aktual të softuerit, të japë komentet e tij me komente.
2. Mos i injoroni kërkesat në ndryshim, edhe në një fazë të mëvonshme të zhvillimit. Proceset fleksibël lejojnë që ndryshimet të akomodohen për të siguruar një avantazh konkurrues për klientin. Ekipet e shkathët përpiqen ta bëjnë strukturën e programit të mirë, me ndikim minimal në sistemin në tërësi.
3. Jepni versione të reja pune të softuerit shpesh, me një interval prej një jave deri në dy muaj, duke preferuar një kornizë kohore më të shkurtër. Në të njëjtën kohë, qëllimi është të ofrohet një program që plotëson nevojat e përdoruesit, me një minimum dokumentacioni shoqërues.
4. Klientët dhe zhvilluesit duhet të punojnë së bashku gjatë gjithë projektit. Besohet se për një projekt të suksesshëm, klientët, zhvilluesit dhe të gjithë palët e interesuara duhet të komunikojnë shpesh dhe në sasi të mëdha për të përmirësuar me qëllim produktin e softuerit.
5. Projektet duhet të realizohen nga njerëz të motivuar. Krijoni një mjedis të shëndetshëm pune për ekipin e projektit, siguroni mbështetjen që i nevojitet dhe besoni se anëtarët e ekipit do ta shohin atë deri në fund.
6. Metoda më efektive dhe produktive për komunikimin e informacionit me ekipin e zhvillimit dhe shkëmbimin e mendimeve brenda tij është biseda ballë për ballë. Në projektet e shkathëta, mënyra kryesore e komunikimit është komunikimi i thjeshtë njerëzor. Dokumentet e shkruara krijohen dhe përditësohen gradualisht me zhvillimin e softuerit dhe vetëm kur është e nevojshme.
7. Një program në ekzekutim është treguesi kryesor i progresit të projektit. Qasja e një projekti të shkathët drejt përfundimit gjykohet nga sa mirë i plotëson programi aktual kërkesat e klientit.
8. Proceset e shkathëta lehtësojnë zhvillimin afatgjatë. Konsumatorët, zhvilluesit dhe përdoruesit duhet të jenë në gjendje të mbajnë një ritëm konstant për aq kohë sa dëshirojnë.
9. Një fokus i pamëshirshëm në përsosmërinë teknike dhe dizajnin cilësor rrit kthimin e teknologjisë fleksibël. Anëtarët e ekipit të shkathët përpiqen të krijojnë kod cilësor përmes rifaktorimit të rregullt.
10. Thjeshtësia është arti për të arritur më shumë duke bërë më pak. Anëtarët e ekipit i zgjidhin problemet aktuale sa më thjeshtë dhe me efikasitet të jetë e mundur. Nëse në të ardhmen ka ndonjë problem, atëherë është e mundur të bëhen ndryshime në kodin me cilësi të lartë pa shpenzime të mëdha.
11. Arkitekturat, kërkesat dhe dizajnet më të mira ofrohen nga ekipe vetë-organizuese. Në ekipet e shkathëta, detyrat nuk u caktohen anëtarëve individualë, por ekipit në tërësi. Ekipi vendos vetë se si të zbatojë më mirë kërkesat e klientit. Anëtarët e ekipit punojnë së bashku në të gjitha aspektet e projektit. Çdo pjesëmarrës lejohet të kontribuojë në kauzën e përbashkët. Nuk ka asnjë anëtar ekipi që është i vetëm përgjegjës për arkitekturën, kërkesat ose testet.
12. Ekipi duhet të mendojë rregullisht se si të bëhet edhe më efektiv dhe më pas të rregullojë dhe rregullojë sjelljen e tyre në përputhje me rrethanat. Një ekip fleksibël po rregullon vazhdimisht organizimin, rregullat, marrëveshjet dhe marrëdhëniet e tij.

Një numër i metodologjive të zhvillimit të softuerit korrespondojnë me parimet e mësipërme në një masë të caktuar:

AgileModeling	një grup konceptesh, parimesh dhe teknikash (praktikash) që ju lejojnë të kryeni shpejt dhe lehtë modelimin dhe dokumentimin në projektet e zhvillimit të softuerit;
AgileUnifiedProcess (AUP)	një version i thjeshtuar i IBM RationalUnifiedProcess (RUP), i cili përshkruan një përafrim (model) të thjeshtë dhe të drejtpërdrejtë për ndërtimin e softuerit për aplikacionet e biznesit;
Hapu	është një metodë e zhvillimit të softuerit përsëritës në rritje. I pozicionuar si një version i lehtë dhe fleksibël i RUP;
Metoda AgileData	një grup metodash përsëritëse të zhvillimit të softuerit në të cilat kërkesat dhe zgjidhjet arrihen përmes bashkëpunimit ndërmjet ekipeve të ndryshme ndërfunksionale;
DSDM	Metodologjia e zhvillimit të sistemeve dinamike e bazuar në konceptin e zhvillimit të shpejtë të aplikacioneve (RapidApplication Development, RAD). Është një qasje përsëritëse dhe në rritje që thekson pjesëmarrjen e vazhdueshme të përdoruesve/konsumatorëve në proces;
Programimi ekstrem (XP)	programim ekstrem;
Zhvillimi adaptiv i softuerit (ADD)	zhvillimi adaptiv i softuerit;
Featuredrivendevelopment (FDD)	zhvillimi i fokusuar në shtimin gradual të funksionalitetit;
Getting Real	një qasje përsëritëse pa specifika funksionale e përdorur për aplikacionet në ueb;
MSFfogAgileSoftwareDevelopment	metodologji fleksibile e zhvillimit të softuerit nga Microsoft;
Scrum	vendos rregullat për menaxhimin e procesit të zhvillimit dhe ju lejon të përdorni praktikat ekzistuese të kodimit, duke rregulluar kërkesat ose duke futur ndryshime taktike [

Modeli i ujëvarës Analiza e kërkesave Projektimi Implementimi Testimi i integrimit Specifikimi i produktit është duke u hartuar Arkitektura e produktit po hartohet Zhvillimi i kodit burim Integrimi i pjesëve të veçanta të kodit burimor Testimi dhe eliminimi i defekteve

Procesi i Unifikuar i Zhvillimit të Softuerit (USDP) Një model i rastit të përdorimit që përshkruan rastet në të cilat do të përdoret një aplikacion. Modeli analitik përshkruan klasat bazë për aplikacionin. Modeli i projektimit përshkruan marrëdhëniet dhe marrëdhëniet ndërmjet klasave dhe objekteve të alokuara.Një model vendosjeje përshkruan shpërndarjen e softuerit nëpër kompjuterë. Modeli i zbatimit përshkruan organizimin e brendshëm të kodit të programit. Modeli i testimit përbëhet nga komponentë testimi, procedura testimi dhe opsione të ndryshme testimi

Komponentët tipikë të arkitekturës së një produkti softuerësh dhe kërkesat tipike të softuerit Organizimi i programit Klasat kryesore të sistemit Organizimi i të dhënave Rregullat e biznesit Ndërfaqja e përdoruesit Menaxhimi i burimeve Siguria Performanca Shkallueshmëria Ndërveprimi me sistemet e tjera (integrimi) Ndërkombëtarizimi, lokalizimi Të dhënat I/O Trajtimi i gabimeve

Komponentët tipikë të arkitekturës së një produkti softuerësh dhe kërkesat tipike të softuerit Toleranca ndaj gabimeve është një grup karakteristikash të një sistemi që rrit besueshmërinë e tij duke zbuluar gabime, duke rikuperuar dhe izoluar pasojat e këqija për sistemin. Gjatë projektimit të një sistemi real për të siguruar tolerancën e gabimeve, është e nevojshme të parashikohen të gjitha llojet e situatave që mund të çojnë në një dështim të sistemit dhe të zhvillohen mekanizma për trajtimin e dështimeve. Besueshmëria është aftësia e një sistemi për t'i bërë ballë dështimeve dhe dështimeve të ndryshme. Dështimi është kalimi i sistemit si rezultat i një gabimi në një gjendje plotësisht jofunksionale. Dështimi - një gabim në funksionimin e sistemit, i cili nuk çon në dështim të sistemit. Sa më pak dështime dhe dështime gjatë një periudhe të caktuar kohore, aq më i besueshëm është sistemi.

Komponentët tipikë të arkitekturës së një produkti softuerik dhe kërkesat tipike të softuerit Aftësitë zbatuese të arkitekturës së zhvilluar. Mundësitë për zbatimin e arkitekturës së zhvilluar. Funksionalitet i tepërt. Funksionalitet i tepërt. Marrja e një vendimi për blerjen e komponentëve të softuerit të gatshëm. Marrja e një vendimi për blerjen e komponentëve të softuerit të gatshëm. Ndryshoni strategjinë. Ndryshoni strategjinë.

A është përshkruar qartë organizimi i përgjithshëm i programit; A përfshin specifikimi një pasqyrë të arkitekturës dhe arsyetimit të saj. A është përshkruar qartë organizimi i përgjithshëm i programit; A përfshin specifikimi një pasqyrë të arkitekturës dhe arsyetimit të saj. A janë përcaktuar në mënyrë adekuate komponentët kryesorë të programit, fushat e tyre të përgjegjësisë dhe ndërveprimet me komponentët e tjerë? A janë përcaktuar në mënyrë adekuate komponentët kryesorë të programit, fushat e tyre të përgjegjësisë dhe ndërveprimet me komponentët e tjerë? A zbatohen të gjitha funksionet e specifikuara në specifikimet e kërkesave nga një numër i arsyeshëm i komponentëve të sistemit. A zbatohen të gjitha funksionet e specifikuara në specifikimet e kërkesave nga një numër i arsyeshëm i komponentëve të sistemit. A ka një përshkrim të klasave më të rëndësishme dhe arsyetimin e tyre. A ka një përshkrim të klasave më të rëndësishme dhe arsyetimin e tyre. A ka një përshkrim të organizimit të bazës së të dhënave. A ka një përshkrim të organizimit të bazës së të dhënave. A janë përcaktuar të gjitha rregullat e biznesit? A janë përcaktuar të gjitha rregullat e biznesit? Nëse ndikimi i tyre në sistem është përshkruar. Nëse ndikimi i tyre në sistem është përshkruar. Një listë kontrolli pyetjesh për të nxjerrë përfundime në lidhje me cilësinë e arkitekturës:

Një listë kontrolli për të nxjerrë përfundime në lidhje me cilësinë e arkitekturës: A përshkruhet një strategji e projektimit të ndërfaqes së përdoruesit? A është përshkruar një strategji e projektimit të ndërfaqes së përdoruesit. A është bërë ndërfaqja e përdoruesit modulare në mënyrë që ndryshimet të mos ndikojnë në pjesën tjetër të sistemit. A është bërë ndërfaqja e përdoruesit modulare në mënyrë që ndryshimet të mos ndikojnë në pjesën tjetër të sistemit. A ka një përshkrim të strategjisë së hyrjes/daljes së të dhënave. A ka një përshkrim të strategjisë së hyrjes/daljes së të dhënave. A është bërë një analizë e performancës së sistemit që do të zbatohet duke përdorur këtë arkitekturë? A është bërë një analizë e performancës së sistemit që do të zbatohet duke përdorur këtë arkitekturë? A është kryer analiza e besueshmërisë së sistemit të projektuar? A është kryer analiza e besueshmërisë së sistemit të projektuar? A është bërë analiza e çështjeve të shkallëzueshmërisë dhe shtrirjes së sistemit? A është bërë analiza e çështjeve të shkallëzueshmërisë dhe shtrirjes së sistemit?

Rifaktorimi i softuerit Kodi përsëritet; zbatimi i metodës është shumë i madh; shumë fole të sytheve, ose vetë laku është shumë i madh; klasa ka kohezion të dobët (vetitë dhe metodat e një klase duhet të përshkruajnë vetëm 1 objekt); ndërfaqja e klasës nuk formon një abstraksion të qëndrueshëm; metoda merr shumë parametra. Duhet të bëhen përpjekje për të mbajtur numrin e parametrave në mënyrë të arsyeshme minimale; pjesët individuale të klasës ndryshojnë në mënyrë të pavarur nga pjesët e tjera të klasës; Rifaktorimi përfshin përshtatjen e softuerit me harduerin e ri dhe me sistemet e reja operative, mjetet e reja të zhvillimit, kërkesat e reja, si dhe arkitekturën dhe funksionalitetin e softuerit. Ky është një ndryshim në strukturën e brendshme të softuerit pa ndryshuar sjelljen e tij të jashtme, i krijuar për të siguruar modifikimin e softuerit. Arsyet e arsyeshme për rifaktorim:

Rifaktorimi i softuerit kur ndryshon programin kërkon një ndryshim të njëkohshëm të disa klasave. Nëse krijohet një situatë e tillë, është e nevojshme të riorganizohen klasat për të minimizuar vendet e ndryshimeve të mundshme në të ardhmen; duhet të ndryshojnë disa hierarki të trashëgimisë paralelisht; ju duhet të ndryshoni disa blloqe çështjesh. Është e nevojshme të modifikohet programi në atë mënyrë që të bëhet zbatimi i bllokut të rasteve dhe ta thërrasë atë sa herë të jetë e nevojshme në program; vëllezërit e motrat e përdorura së bashku nuk janë të organizuar në klasa. Nëse përdorni në mënyrë të përsëritur të njëjtin grup artikujsh të dhënash, atëherë këshillohet të merrni parasysh kombinimin e këtyre të dhënave dhe t'i vendosni operacionet e kryera mbi to në një klasë të veçantë;

Metoda e rifaktorimit të softuerit përdor më shumë elementë të një klase tjetër sesa të vetat. Kjo do të thotë që metoda duhet të zhvendoset në një klasë tjetër dhe të thirret nga e vjetra; Lloji primitiv i të dhënave është i mbingarkuar. Është më mirë të përdoret një klasë për të përshkruar një entitet në botën reale sesa të mbingarkohet çdo lloj i të dhënave ekzistuese; klasa ka funksionalitet shumë të kufizuar. Është më mirë të heqësh qafe këtë klasë duke transferuar funksionalitetin e saj në një klasë tjetër; të dhënat e roaming kalohen përgjatë zinxhirit të metodës. Të dhënat që i kalohen një metode vetëm për t'u kaluar në një metodë tjetër quhen "stray". Kur lindin këto situata, përpiquni të ridizajnoni klasat dhe metodat tuaja për t'i hequr qafe ato.

Rifaktorimi i softuerit të një objekti ndërmjetësimi nuk bën asgjë. Nëse roli i një klase reduktohet në ridrejtimin e thirrjeve të metodës në klasa të tjera, atëherë është më mirë të eliminoni një objekt të tillë ndërmjetës dhe të bëni thirrje drejtpërsëdrejti në klasa të tjera; një klasë di shumë për një klasë tjetër. Në këtë situatë, është e nevojshme që kapsulimi të bëhet më i rreptë në mënyrë që të sigurohet njohuri minimale e trashëgimtarit për prindin e tij; metoda ka një emër fatkeq; këta anëtarë janë publikë. Kjo mjegullon kufirin midis ndërfaqes dhe zbatimit, në mënyrë të pashmangshme prish kapsulimin dhe kufizon fleksibilitetin e programit; postoni komente në kodin burimor;

Rifaktorimi i softuerit Një nënklasë përdor vetëm një pjesë të vogël të metodave të paraardhësve të saj. Kjo situatë ndodh kur një klasë e re krijohet vetëm për të trashëguar disa metoda nga klasa bazë, dhe jo për të përshkruar ndonjë entitet të ri. Për të shmangur këtë, është e nevojshme të transformohet klasa bazë në atë mënyrë që t'i japë akses klasës së re vetëm metodave që i nevojiten; kodi përmban variabla globale. Vetëm ato variabla që përdoren aktualisht nga i gjithë programi duhet të jenë globale. Të gjithë variablat e tjerë ose duhet të jenë lokalë ose duhet të bëhen veti të disa objekteve; programi përmban kodin që mund t'ju nevojitet një ditë. Kur zhvilloni një sistem, këshillohet të jepni vende ku kodi burim mund të shtohet në të ardhmen.

Në pjesën e parë, ne zgjodhëm të krahasonim metodologjitë e zhvillimit të softuerit, tregues të tillë si raporti i metodologjisë me zhvillimin përsëritës dhe shkalla e formalitetit në hartimin e materialeve të punës dhe në përgjithësi në procesin e zhvillimit. Në këtë pjesë, ne përdorim këto metrika për të krahasuar teknikat më të njohura të zhvillimit të softuerit.

Të shohim si do të shkojë…

Mjerisht, kjo është kategoria më e vështirë për t'u përshkruar - në fund të fundit, ajo përfshin si produktin e hedhjes konvulsive të një fillestari që përpiqet me çdo kusht të përfundojë projektin e tij të parë, ashtu edhe metodologjitë mjaft të pjekura dhe të vendosura mirë që kanë zhytur shumë vite dhe përvoja të ndryshme të ekipeve specifike të zhvillimit dhe madje edhe ato të përshkruara në rregulloret e brendshme. Meqenëse njerëzit që janë në gjendje të zhvillojnë metodologjinë e tyre, si rregull, mund ta vlerësojnë vetë atë në drejtim të përsëritjes dhe formalizimit, ne do të përqendrohemi te fillestarët. Mjerisht, më shpesh kjo do të thotë që rregullat për zhvillimin e zhvillimit ose nuk ekzistojnë fare, ose ato janë zhvilluar dhe miratuar, por nuk respektohen. E natyrshme në kushte të tilla është niveli jashtëzakonisht i ulët i formalizmit të zhvillimit. Pra, gjithçka është e qartë me këtë.

Zhvillimi "Si shkon"

Po në lidhje me qasjen përsëritëse? Mjerisht, si rregull, nuk përdoret në projekte të tilla. Para së gjithash, sepse do të lejonte që në përsëritjet e para të vlerësohej projekti si jashtëzakonisht i dyshimtë dhe që kërkon ndërhyrje urgjente nga një menaxhment më i lartë për të vendosur gjërat në rregull. Në të vërtetë, në një projekt përsëritës, përgjigjja tradicionale e një programuesi se gjithçka është tashmë 90% gati për të ndodh vetëm deri në fund të përsëritjes së parë ...

Metodologjitë strukturore

Metodologjitë strukturore

Metodat strukturore janë një grup metodologjish të zhvilluara, si rregull, përpara përdorimit të gjerë të gjuhëve të orientuara nga objekti. Të gjitha përfshijnë zhvillimin e ujëvarave. Edhe pse, siç doli, edhe në atë artikull, i cili shpesh përmendet si prezantimi i parë i qasjes së ujëvarës, u tha se është e këshillueshme që projekti të fillojë me zhvillimin e një prototipi, domethënë të kryhet të paktën. dy përsëritje.

Sidoqoftë, baza e këtyre metodologjive është një kalim vijues nga puna në punë dhe transferimi i rezultateve (dokumenteve) të fazës tjetër te pjesëmarrësit e fazës tjetër.

Gjithashtu, të gjitha këto metodologji supozojnë një qasje shumë të formalizuar, megjithëse në to mund të gjenden deklarata për një sasi të arsyeshme dokumentacioni. Një nga shembujt jo të qartë që metodologjitë e zhvillimit të softuerit u zhvilluan jo vetëm në Perëndim, është një citim nga një libër i botuar në vendin tonë në fillim të viteve 1980, i cili thotë se shkalla e formalizimit të një detyre programimi duhet të përcaktohet bazuar në atë se sa mirë analisti dhe programuesi. Dhe kjo përkundër faktit se tema e librit përfshinte zhvillimin e sistemeve mjaft kritike, siç quhen tani, gabime në të cilat çojnë në humbje serioze apo edhe në katastrofa.

Metodologjitë e shkathëta

Metodologjitë e shkathëta bazohen në dhjetë parime, nga të cilat do të përmendim vetëm ato që përcaktojnë vlerësimin e këtyre metodologjive sipas parametrave të zgjedhur:

• gjëja kryesore është të kënaqni klientin dhe t'i siguroni atij produktin sa më shpejt të jetë e mundur;
• lëshimet e reja të produktit duhet të shfaqen çdo disa javë, në raste ekstreme - muaj;
• mënyra më efektive për të transferuar njohuri tek dhe ndërmjet pjesëmarrësve të zhvillimit është komunikimi personal;
• një program në zhvillim është treguesi më i mirë i progresit të zhvillimit.

Kështu, këto metoda janë të orientuara qartë drejt zhvillimit të softuerit përsëritës dhe formalizimit minimal të procesit. Megjithatë, në lidhje me pikën e dytë, është e nevojshme të bëhet një rezervë: metodat e përmendura janë të fokusuara në nivelin minimal të pranueshëm të formalizimit për një projekt të caktuar. Të paktën një nga metodologjitë e përfshira në grupin fleksibël - Crystal - ka modifikime të krijuara për të kryer procese me numër të ndryshëm pjesëmarrësish dhe kritika të ndryshme të softuerit që po zhvillohet (kriticiteti i softuerit përcaktohet nga pasojat e mundshme të gabimeve, të cilat mund të ndryshojnë në variojnë nga humbjet e parëndësishme financiare deri te korrigjimet e gabimeve deri te ato katastrofike). Në mënyrë që krahasimi i mëtejshëm me metodologjitë e shkathëta të mos jetë i pakuptimtë, do të japim përshkrime të shkurtra të disa prej tyre.

Programim ekstreme, ose XP (programim ekstrem)

Metodologjia XP, e zhvilluar nga Kent Beck, Ward Cunningham dhe Ron Jeffries, është metodologjia më e njohur Agile sot. Ndonjëherë vetë koncepti i Agile identifikohet në mënyrë eksplicite ose të nënkuptuar me XP, i cili mbron komunikimin, thjeshtësinë, reagimet dhe guximin. Ai përshkruhet si një grup praktikash: planifikimi i lojërave, publikimet e shkurtra, metaforat, dizajni i thjeshtë, rifaktorimi, zhvillimi i testeve përpara, programimi i çifteve, zotërimi i kodit kolektiv, 40 orë në javë pune, prania e klientit dhe standardet e kodit. Interesi për XP u rrit nga poshtë lart - nga zhvilluesit dhe testuesit, të torturuar nga procesi i dhimbshëm, dokumentacioni, metrikat dhe formalizmi tjetër. Ata nuk e mohuan disiplinën, por nuk donin të përmbushnin pa qëllim kërkesat formale dhe kërkuan qasje të reja, të shpejta dhe fleksibël për zhvillimin e programeve me cilësi të lartë.

Me XP, dizajni i kujdesshëm paraprak i softuerit zëvendësohet, nga njëra anë, nga prania e vazhdueshme e një klienti në ekip, i gatshëm për t'iu përgjigjur çdo pyetjeje dhe për të vlerësuar çdo prototip, dhe nga ana tjetër, nga rishikimet e rregullta të kodit (të ashtuquajturat rifaktorimi). Kodi i komentuar tërësisht konsiderohet baza e dokumentacionit të projektimit. Një vëmendje e madhe i kushtohet testimit në metodologji. Si rregull, për çdo metodë të re, fillimisht shkruhet një test dhe më pas zhvillohet kodi aktual i metodës derisa testi të fillojë të ekzekutohet me sukses. Këto teste ruhen në suita që ekzekutohen automatikisht pas çdo ndryshimi të kodit.

Ndërsa programimi në çift dhe një javë pune 40-orëshe janë ndoshta tiparet më të njohura të XP, ato janë ende mbështetëse dhe kontribuojnë në produktivitet të lartë të zhvilluesve dhe më pak gabime zhvillimi.

Kristal e qartë

Crystal është një familje e metodologjive që përcaktojnë shkallën e nevojshme të formalizimit të procesit të zhvillimit, në varësi të numrit të pjesëmarrësve dhe kritikës së detyrave.

Metodologjia Crystal Clear është inferiore ndaj XP për sa i përket performancës, por është sa më e lehtë për t'u përdorur. Ajo kërkon përpjekje minimale për t'u zbatuar pasi është e orientuar drejt zakoneve njerëzore. Besohet se kjo metodologji përshkruan rendin natyror të zhvillimit të softuerit që vendoset në ekipe mjaft të kualifikuara, nëse ata nuk janë të angazhuar në zbatimin e synuar të një metodologjie tjetër.

Karakteristikat kryesore të Crystal Clear:

• zhvillimi përsëritës në rritje;
• testimi automatik i regresionit;
• përdoruesit janë të përfshirë në pjesëmarrje aktive në projekt;
• përbërja e dokumentacionit përcaktohet nga pjesëmarrësit e projektit;
• në përgjithësi, përdoret kontrolli i versionit të kodit.

Përveç Crystal Clear, familja Crystal përfshin disa metodologji të tjera të dizajnuara për të trajtuar projekte më të mëdha ose më kritike. Ata kanë kërkesa pak më të rrepta dokumentacioni dhe procedura mbështetëse si ndryshimi dhe kontrolli i versionit.

Zhvillimi i drejtuar nga tiparet

Feature Driven Development (FDD) funksionon me konceptin e një funksioni ose veçorie (veçorie) të sistemit, që është mjaft afër konceptit të një rasti përdorimi të përdorur në RUP. Ndoshta ndryshimi më domethënës është një kufizim shtesë: "çdo funksion duhet të jetë në gjendje të zbatohet në jo më shumë se dy javë". Kjo do të thotë, nëse rasti i përdorimit është mjaft i vogël, ai mund të konsiderohet funksion, dhe nëse është i madh, atëherë duhet të ndahet në disa funksione relativisht të pavarura.

FDD përfshin pesë procese, me dy të fundit të përsëritura për secilin funksion:

• zhvillimi i një modeli të përgjithshëm;
• duke bërë një listë të funksioneve të nevojshme të sistemit;
• planifikimi i punës për secilin funksion;
• dizajni i funksionit;
• duke ndërtuar një funksion.

Puna në një projekt përfshin ndërtime të shpeshta dhe ndahet në përsëritje, secila prej të cilave zbatohet duke përdorur një grup specifik funksionesh.

Zhvilluesit në FDD ndahen në "mjeshtër të klasës" dhe "programues kryesorë". Programuesit kryesorë përfshijnë pronarët e klasave të përfshira në punën në pronën tjetër. Për krahasim, XP nuk ka përgjegjësi personale për klasat ose metodat.

Karakteristikat e përbashkëta

Lista e metodologjive të shkathëta është aktualisht mjaft e gjerë. Megjithatë, metodologjitë që kemi përshkruar japin një pamje shumë të plotë të të gjithë familjes.

Pothuajse të gjitha metodologjitë e shkathët përdorin një qasje përsëritëse, në të cilën vetëm një sasi e kufizuar e punës që lidhet me lëshimin e versionit të ardhshëm është planifikuar në detaje.

Pothuajse të gjitha metodologjitë e shkathëta janë të fokusuara në qasjen më informale të zhvillimit. Nëse problemi mund të zgjidhet gjatë një bisede të rastësishme, atëherë është më mirë ta bëni këtë. Për më tepër, është e nevojshme të hartohet vendimi i marrë në formën e një dokumenti letre ose elektronik vetëm kur është e pamundur të bëhet pa të.

Metodologjitë e shkathëta

GOST

GOST-të, si kërkesat CMM të përshkruara në seksionin vijues, nuk janë metodologji. Ata, si rregull, nuk përshkruajnë vetë proceset e zhvillimit të softuerit, por vetëm formulojnë kërkesa të caktuara për proceset, të cilat në një shkallë ose në një tjetër korrespondojnë me metodologji të ndryshme. Krahasimi i kërkesave sipas të njëjtave kritere me të cilat ne krahasojmë metodologjitë do të ndihmojë për të përcaktuar menjëherë se cilat metodologji duhet të përdoren nëse keni nevojë të zhvilloni në përputhje me GOST.

Aktualisht, GOST-të e vjetra të serive të 19-të dhe 34-të dhe GOST R ISO IEC 122207 më të reja janë në fuqi në Rusi. GOST-të e serive të 19-të dhe 34-të janë të përqendruara në mënyrë të ngurtë në një qasje kaskade për zhvillimin e softuerit. Zhvillimi në përputhje me këto GOST kryhet në faza, secila prej të cilave përfshin zbatimin e një pune të përcaktuar rreptësisht dhe përfundon me lëshimin e një numri mjaft të madh dokumentesh shumë të formalizuara dhe të gjera. Kështu, respektimi i menjëhershëm i rreptë i këtyre standardeve jo vetëm që çon në një qasje ujëvare, por gjithashtu siguron një shkallë shumë të lartë të formalizimit të zhvillimit.

Kërkesat e GOST

GOST 12207, ndryshe nga standardet e serive të 19-të dhe 34-të, përshkruan zhvillimin e softuerit si një grup procesesh bazë dhe ndihmëse që mund të funksionojnë nga fillimi deri në fund të një projekti. Modeli i ciklit jetësor mund të zgjidhet bazuar në karakteristikat e projektit. Kështu, ky GOST nuk e ndalon në mënyrë eksplicite përdorimin e qasjes përsëritëse, por nuk rekomandon në mënyrë eksplicite përdorimin e saj. GOST 12207 është gjithashtu më fleksibël për sa i përket kërkesave për formalitetin e procesit të zhvillimit. Ai përmban vetëm udhëzime mbi nevojën për të dokumentuar rezultatet kryesore të të gjitha proceseve, por nuk ka lista të dokumenteve dhe udhëzimeve të kërkuara në lidhje me përmbajtjen e tyre.

Kështu, GOST 12207 lejon zhvillimin e softuerit përsëritës dhe më pak të zyrtarizuar.

Modelet e maturimit të zhvillimit (CMM, CMMI)

Përveç standardeve kombëtare dhe ndërkombëtare, ekzistojnë disa qasje për certifikimin e procesit të zhvillimit. Më të famshmit prej tyre në Rusi janë, me sa duket, CMM dhe CMMI.

CMM (Capability Maturity Model) është një model maturimi i procesit të zhvillimit të softuerit, i cili është krijuar për të vlerësuar nivelin e pjekurisë së procesit të zhvillimit në një kompani të caktuar. Sipas këtij modeli, ekzistojnë pesë nivele të pjekurisë së zhvillimit. Niveli i parë korrespondon me zhvillimin e "si do të dalë", kur zhvilluesit shkojnë në çdo projekt sikur të ishte një vepër. E dyta korrespondon me procese pak a shumë të vendosura mirë, kur është e mundur me besim të mjaftueshëm të mbështetet në një rezultat pozitiv të projektit. E treta korrespondon me praninë e proceseve të zhvilluara dhe të përshkruara mirë të përdorura në zhvillim, dhe e katërta korrespondon me përdorimin aktiv të metrikës në procesin e menaxhimit për të vendosur qëllime dhe për të monitoruar arritjen e tyre. Së fundi, niveli i pestë i referohet aftësisë së kompanisë për të optimizuar procesin sipas nevojës.

Kërkesat CMM dhe CMMI

Pas ardhjes së CMM, filluan të zhvillohen modele të specializuara maturimi për krijimin e sistemeve të informacionit, për procesin e përzgjedhjes së furnitorëve dhe disa të tjera. Mbi bazën e tyre, u zhvillua një model i integruar CMMI (Capability Maturity Model Integration). Për më tepër, CMMI u përpoq të kapërcejë mangësitë e CMM-së që ishin shfaqur deri në atë kohë - ekzagjerimin e rolit të përshkrimeve formale të proceseve, kur disponueshmëria e dokumentacionit të caktuar u vlerësua dukshëm më e lartë se thjesht një dokumentacion i mirë-krijuar, por i pa përshkruar. procesi. Megjithatë, CMMI është gjithashtu e fokusuar në përdorimin e një procesi shumë të formalizuar.

Kështu, baza e modeleve CMM dhe CMMI është formalizimi i procesit të zhvillimit. Ata synojnë zhvilluesit në zbatimin e një procesi të përshkruar në detaje në rregullore dhe udhëzime, të cilat, nga ana tjetër, nuk mund të mos kërkojnë zhvillimin e një vëllimi të madh të dokumentacionit të projektit për kontrollin dhe raportimin e duhur.

Marrëdhënia e CMM dhe CMMI me zhvillimin përsëritës është më indirekte. Formalisht, as njëri dhe as tjetri nuk bëjnë ndonjë kërkesë specifike për t'iu përmbajtur një qasjeje ujëvare ose përsëritëse. Megjithatë, sipas disa ekspertëve, CMM është më i pajtueshëm me qasjen e ujëvarës, ndërsa CMMI gjithashtu lejon një qasje përsëritëse.

RUP

Sigurisht, RUP është një metodologji përsëritëse. Megjithëse zyrtarisht detyrimi për të përfunduar të gjitha fazat ose një numër minimal i përsëritjeve nuk tregohet askund në RUP, e gjithë qasja fokusohet në faktin se ka shumë prej tyre. Numri i kufizuar i përsëritjeve nuk ju lejon të përfitoni plotësisht nga përfitimet e plota të RUP. Në të njëjtën kohë, RUP mund të përdoret gjithashtu në projekte pothuajse ujëvara që në fakt përfshijnë vetëm disa përsëritje: njëra në fazën e Ndërtimit dhe tjetra në fazën e Transferimit. Nga rruga, ky është numri i përsëritjeve që përdoren në të vërtetë në projektet kaskadë. Në fund të fundit, testimi dhe funksionimi i provës i sistemit përfshin futjen e korrigjimeve, të cilat mund të nënkuptojnë veprime të caktuara që lidhen me analizën, projektimin dhe zhvillimin, domethënë, në fakt, ato janë një tjetër kalim nëpër të gjitha fazat e zhvillimit.

Metodologjia RUP

Sa i përket formalitetit të metodologjisë, këtu RUP paraqet një gamë shumë të gjerë mundësish për përdoruesit. Nëse i kryeni të gjitha punët dhe detyrat, krijoni të gjitha artefaktet dhe zyrtarisht (me një recensues zyrtar, me përgatitjen e një rishikimi të plotë në formën e një dokumenti elektronik ose letre, etj.) kryeni të gjitha rishikimet, RUP mund të jetë një metodologji jashtëzakonisht formale, e rëndë. Në të njëjtën kohë, RUP ju lejon të zhvilloni vetëm ato artefakte dhe të kryeni vetëm ato aktivitete dhe detyra që janë të nevojshme për një projekt specifik. Dhe artefaktet e përzgjedhura mund të ekzekutohen dhe rishikohen me çdo shkallë formaliteti. Ju mund të kërkoni një studim të detajuar dhe hartim të kujdesshëm të çdo dokumenti, sigurimin e një rishikimi të ekzekutuar dhe të ekzekutuar po aq me kujdes, madje, sipas praktikës së vjetër, të miratoni çdo rishikim të tillë në këshillin shkencor dhe teknik të ndërmarrjes. Ose mund të kufizoni veten në një email ose një skicë në letër. Për më tepër, ka gjithmonë një mundësi më shumë: të formoni një dokument në kokë, domethënë të mendoni për pyetjen përkatëse dhe të merrni një vendim konstruktiv. Dhe nëse ky vendim ka të bëjë vetëm me ju, atëherë kufizoni veten, për shembull, në një koment në kodin e programit.

Kështu, RUP është një metodologji përsëritëse me një gamë shumë të gjerë zgjidhjesh të mundshme në drejtim të formalizimit të procesit të zhvillimit.

Le të përmbledhim rezultatet e pjesës së dytë të artikullit. RUP, ndryshe nga shumica e metodologjive të tjera, ju lejon të zgjidhni në një gamë të gjerë shkallën e formalizimit dhe përsëritjes së procesit të zhvillimit, në varësi të karakteristikave të projekteve dhe organizatës në zhvillim.

Dhe pse kjo është kaq e rëndësishme - ne do të diskutojmë në pjesën tjetër.