Programet e zhvillimit të softverit. Mjetet e zhvillimit të softuerit. Kur duhet përdorur Agile

Sot, procesi i krijimit të kompleksit aplikacione softuerike është e pamundur të imagjinohet pa u ndarë në faza të ciklit jetësor. Me ciklin jetësor të një programi nënkuptojmë një sërë fazash:

Analiza e fushës lëndore dhe krijimi i specifikimeve teknike (ndërveprimi me klientin)
Hartimi i strukturës së programit
Kodimi (bashkësia e kodit të programit sipas dokumentacionit të projektit)
Testimi dhe korrigjimi i gabimeve
Zbatimi i programit
Mbështetja e programit
Riciklimi

Le të ndalemi në procesin e projektimit në detaje. Gjatë procesit të projektimit, një arkitekt ose një programues me përvojë krijon dokumentacionin e projektit, duke përfshirë përshkrimet e tekstit, diagramet, modelet e programit të ardhshëm. UML do të na ndihmojë në këtë çështje të vështirë.

UML është një gjuhë grafike për vizualizimin, përshkrimin e parametrave, ndërtimin dhe dokumentimin e sistemeve të ndryshme (programe në veçanti). Diagramet krijohen duke përdorur mjete speciale të RASTIT siç janë Rational Rose (http://www-01.ibm.com/software/rational/) dhe Enterprise Architect (http://www.sparxsystems.com.au/). Një model i unifikuar i informacionit është ndërtuar mbi bazën e teknologjisë UML. Mjetet e mësipërme të RASTIT janë të afta të gjenerojnë kod në gjuhë të ndryshme të orientuara drejt objektit, dhe gjithashtu kanë një funksion shumë të dobishëm inxhinierik të kundërt. (Inxhinieria e kundërt ju lejon të krijoni një model grafik nga kodi ekzistues dhe komentet për të.)

Merrni parasysh llojet e diagrameve për vizualizimin e modelit (kjo është e domosdoshme, megjithëse ka shumë më shumë lloje):

Merrni parasysh ndryshimet e ardhshme në objekte dhe subjekte

Komponentët duhet të analizohen në mënyrë të qëndrueshme dhe së bashku, duke marrë parasysh mënyrën se si ato kombinohen, mirëmbahen ose zëvendësohen. Nga projekti, duhet të kemi parasysh që vetitë e sistemit dhe përdoruesve të tij vazhdimisht ndryshojnë. Disa faktorë për tu marrë në konsideratë janë rritja e popullsisë së përdoruesve, ndikimi i migrimit në sistem ose mënyra se si ato do të ndikojnë në dobësitë e ardhshme për komponentët që janë vendosur në një shkallë të gjerë.

Procedurat e rinovimit duhet të hartohen me një horizont të ardhshëm prej muajsh, vitesh, apo edhe dekadash. Organizatat e krijuara kanë filluar të kuptojnë se identifikimi dhe rregullimi i problemeve herët ka një kosto që është në përpjesëtim të kundërt me kohën kur një gabim mbetet në sistem.

Përdorni diagramin e shkronjave

Sistemi i hartuar përfaqësohet si një tërësi entitetesh ose aktorësh që ndërveprojnë me sistemin duke përdorur të ashtuquajturat raste përdorimi. Në këtë rast, një aktor (aktor) ose një aktor është çdo entitet që bashkëvepron me sistemin nga jashtë. Me fjalë të tjera, çdo rast përdorimi përcakton një grup të caktuar veprimesh të kryera nga sistemi kur ndërvepron me aktorin. Në të njëjtën kohë, asgjë nuk thuhet se si do të zbatohet ndërveprimi i aktorëve me sistemin.

Diagrami i klasës

Një diagram klasë përdoret për të përfaqësuar strukturën statike të një modeli sistemi në drejtim të klasave të programimit të orientuar drejt objektit. Një diagram klasor mund të pasqyrojë, në veçanti, marrëdhënie të ndryshme midis njësive individuale të fushës, të tilla si objektet dhe nënsistemet, dhe gjithashtu përshkruan strukturën e tyre të brendshme (fushat, metodat ...) dhe llojet e marrëdhënieve (trashëgimia, zbatimi i ndërfaqeve ...). Kjo diagramë nuk ofron informacion mbi aspektet kohore të funksionimit të sistemit. Nga kjo pikëpamje, diagrami i klasës është një zhvillim i mëtejshëm i modelit konceptual të sistemit të hartuar. Në këtë fazë, njohja e qasjes OOP dhe modelet e dizajnit është thelbësore.

Kjo është e njëjta paketë aplikimi. Në këtë mënyrë mund të keni të njëjtën paketë aplikimi për të gjitha platformat. Justshtë vetëm një koleksion i kontratave dhe versioneve. Ato ju lejojnë të përcaktoni se ku mund të ekzekutohet aplikacioni. Sistemi operativ nuk përdoret më si destinacion. Aplikacioni tani synon një ose më shumë familje pajisjesh. Merrni më shumë informacion mbi këtë.

Nëse dëshironi të përdorni këto emulatorë, duhet ta instaloni këtë softuer në një kompjuter fizik. Kjo është një listë e asaj që ju nevojitet softuer... Ky dokumentacion është arkivuar dhe nuk po azhurnohet. Theksoni kodin, linjat, imazhet dhe, në disa raste, edhe ndërfaqen e përdoruesit. Kur të përfundojnë, shabllonet e projektit shfaqen në një kuti të re dialogu për projektin.

Diagrami i gjendjes (diagrami i statechart)

Qëllimi kryesor i kësaj diagrami është të përshkruajë sekuencat e mundshme të gjendjeve dhe kalimeve që karakterizojnë kolektivisht sjelljen e një elementi model gjatë ciklit të tij jetësor. Një diagram shtetëror paraqet sjelljen dinamike të entiteteve, bazuar në specifikimin e përgjigjes së tyre ndaj perceptimit të disa ngjarjeve specifike.

Kjo përfshin çdo logjikë biznesi, integrim në re, hyrje në bazën e të dhënave ose ndonjë kod tjetër. Kodi i vetëm që nuk mund të ndahet është specifik për platformën. Ju mund ta ndani kodin tuaj duke përdorur një projekt të përbashkët, një projekt të bibliotekës së klasës portative, ose të dyja. Ju mund të zbuloni se disa janë të përshtatshme për një kod më efikas në një projekt të përbashkët, dhe disa kode kanë më shumë kuptim brenda një projekti të bibliotekës së klasës portative.

Përcaktoni se për çfarë lloji të zhvillimit të softuerit jeni të interesuar. Ekzistojnë dy fusha kryesore të zhvillimit: zhvillimi i aplikacioneve dhe zhvillimi i sistemit. Zhvillimi i aplikacioneve përqendrohet në krijimin e programeve që plotësojnë nevojat e përdoruesit, duke filluar nga aplikacionet deri te telefonat celular dhe duke përfunduar me video lojëra me cilësi të lartë në softuerin e kontabilitetit. Zhvillimi i sistemit përqendrohet në ndërtimin dhe mirëmbajtjen e sistemeve operative. Ky zhvillim shpesh ka të bëjë me performancën e rrjetit dhe mbrojtjen e të dhënave.

Diagrami i sekuencës

Të modelojë ndërveprimin e objekteve në uML përdoren diagramet e duhura të ndërveprimit. Ndërveprimet e objekteve mund të shihen me kalimin e kohës, dhe pastaj një diagramë sekuence përdoret për të përfaqësuar karakteristikat kohore të transmetimit dhe marrjes së mesazheve midis objekteve. Objektet që ndërveprojnë shkëmbejnë disa informacione me njëri-tjetrin. Informacioni pastaj merr formën e mesazheve të plota. Me fjalë të tjera, megjithëse mesazhi ka përmbajtje informative, ai fiton veçori shtesë të ushtrimit të një ndikimi të drejtuar te marrësi i tij.

Mësoni një gjuhë programimi. Çdokush mund të ketë një ide, por një zhvillues mund t'i shndërrojë ato ide në diçka konkrete. Edhe nëse thjesht doni të punoni në problemet e zhvillimit të softuerit, duhet të dini mirë programimin dhe të jeni në gjendje të prototiponi, ka shumë programe që mund t'i mësoni vetë. Disa nga ato më të dobishmet dhe më të rëndësishmet.

Përdoret shumë për lojëra video dhe kompani dhe shpesh rekomandohet si gjuha kryesore. Ashtë një gjuhë e shkëlqyeshme të dish nëse je një zhvillues i pavarur. Alsoshtë gjithashtu një gjuhë shumë miqësore për lojërat video. ... Kodimi i shkruar mirë do të jetë ndoshta burimi juaj më i mirë dhe mund të këshilloni shpejt ndërsa punoni në projekte. Përveç librave, uebi është një burim i pashtershëm udhëzimesh dhe udhëzimesh. Ndiqni kurset. Edhe nëse nuk ju nevojitet një diplomë për tu futur në inxhinierinë e softuerit, pjesëmarrja në kurse nuk ju dëmton.

Diagrami i bashkëpunimit

Në një diagram bashkëpunimi, objektet që marrin pjesë në bashkëveprim janë përshkruar në formën e drejtkëndëshave, që përmbajnë emrin e objektit, klasën e tij dhe, ndoshta, vlerat e atributeve. Ashtu si me një diagram të klasës, asociacionet midis objekteve tregohen si linja të ndryshme lidhëse. Në këtë rast, ju mund të specifikoni qartë emrat e shoqatës dhe rolet që luajnë objektet në këtë shoqatë.
Ndryshe nga një diagram sekuence, një diagram bashkëpunimi përshkruan vetëm marrëdhëniet midis objekteve që luajnë role specifike në një ndërveprim.

Do të keni mundësinë të përfitoni nga një mësim privat dhe do të përballeni me probleme për të cilat nuk do të kishit menduar nëse vetë do t’i dinit. Mësimet kushtojnë shumë, prandaj sigurohuni që të regjistroheni në klasa që ju ndihmojnë të mësoni atë që dëshironi të dini. Ndërsa shumë zhvillues mund të hyjnë në industri vetëm bazuar në aftësitë e tyre, ju do të jeni në gjendje të theksoni nëse keni një diplomë të shkencave kompjuterike. Shkalla do t'ju japë njohuri më të thella dhe qasje në mësime të dobishme të tilla si matematika dhe logjika. Duke punuar në projekte të vogla.

Para se të filloni të përdorni aftësitë tuaja programuese në botën e punës, po punoni për disa projekte për veten tuaj. Sfidat për të zgjidhur problemet duke përdorur programe. Kjo do t'ju ndihmojë jo vetëm të përmirësoni aftësitë tuaja, por edhe të zgjeroni aftësitë tuaja kurrikula.

Diagrami i përbërësit

Diagrami përbërës, në kontrast me diagramet e shqyrtuara më parë, përshkruan tiparet e paraqitjes fizike të sistemit. Një diagramë përbërëse ju lejon të përcaktoni arkitekturën e sistemit që po zhvillohet duke vendosur varësi midis komponentëve të softuerit, të cilat mund të jenë burim, kod binar dhe i ekzekutueshëm. Në shumë mjedise zhvillimi, një modul ose komponent korrespondon me një skedar. Shigjetat me pika që lidhin modulet tregojnë ndërvarësi të ngjashme me ato që ndodhin gjatë përpilimit të kodit burimor. Elementet kryesore grafike të një diagrami përbërës janë përbërësit, ndërfaqet dhe varësitë ndërmjet tyre.

Për shembull, në vend që të përdorni një kalendar kompjuterik për të renditur takimet, provoni ta krijoni vetë! Nëse jeni të interesuar të zhvilloni lojëra video, ajo funksionon me lojëra të thjeshta që nuk përqendrohen në grafikë ose mekanikë komplekse.

Në vend të kësaj, është çështje origjinaliteti dhe argëtimi.
Një koleksion lojërash të vegjël të krijuar nga ju do ta bëjnë figurën tuaj një figurë të bukur.

Bëj pyetje. Interneti është një mënyrë e shkëlqyeshme për tu lidhur me zhvilluesit e tjerë. Sigurohuni që të bëni pyetje të zgjuara dhe të provoni zgjidhjet e mundshme.

Diagrami i vendosjes

Diagrami i vendosjes ka për qëllim të vizualizojë elementet dhe përbërësit e një programi që ekzistojnë vetëm në fazën e ekzekutimit të tij (koha e ekzekutimit). Në këtë rast, paraqiten vetëm instancat-përbërës të programit, të cilët janë skedarë të ekzekutueshëm ose biblioteka dinamike. Komponentët që nuk përdoren gjatë kohës së ekzekutimit nuk tregohen në diagramin e vendosjes.
Një diagram i vendosjes përmban paraqitje grafike të procesorëve, pajisjeve, proceseve dhe marrëdhënieve ndërmjet tyre. Ndryshe nga skemat logjike të pamjes, një diagram vendosje është i njëjtë për sistemin në tërësi, pasi që duhet të pasqyrojë plotësisht specifikat e zbatimit të tij. Kjo skemë në thelb plotëson procesin OOAP për një specifik sistemi softuerik dhe zhvillimi i tij është zakonisht hapi i fundit në specifikimin e modelit.

Praktikohuni çdo ditë. Punoni në projektet tuaja personale çdo ditë, madje edhe për një orë. Kjo do t'ju ndihmojë të qëndroni aktiv dhe gjithmonë të mësoni teknika të reja. Përkthimi ditor duke përdorur gjuhën do t'ju ndihmojë ta mësoni më mirë. Vendosni për një kohë të ditës për t'iu përkushtuar programimit, ose caktoni një afat në të cilin duhet të respektoni. Mundohuni të punoni në projektet tuaja çdo ditë gjatë javës që të mund të bëni një pushim gjatë fundjavës. Kërkoni për programe në dispozicion për të përfunduar detyrën që dëshironi të përmbushni dhe kontrolloni nëse ka ndonjë mënyrë për ta bërë procesin më të lehtë ose më të qartë. i ofron përdoruesit shumë dobi. Shkruani ndonjë ide. Edhe ato që duken budallaqe ose absurde, sepse mund të lindin diçka të dobishme ose të shkëlqyer.

Mendoni për idetë.
Një program i mirë bën një detyrë që ia bën jetën më të lehtë përdoruesit.
Rishikoni operacionet që bëni çdo ditë në kompjuterin tuaj.

Eksploroni programe të tjera.

Kjo përfundon udhëtimin tonë të përgjithshëm të diagrameve dhe të dizajnit në përgjithësi. Vlen të përmendet se procesi i dizajnit është bërë prej kohësh standardi për zhvillimin e softuerit, por shpesh duhet të merret me një program të shkruar shkëlqyeshëm, i cili, për shkak të mungesës së dokumentacionit normal, rritet me funksione anësore të panevojshme, paterica, bëhet i rëndë dhe humbet cilësinë e tij të mëparshme. \u003d (

Cfare po bejne ata? Si mund të përmirësohen ato? Përgjigjja e këtyre pyetjeve mund t'ju ndihmojë të gjeni ide. Shkruaj një dokument të projektit. Ky dokument do të përshkruajë funksionet dhe detyrat e projektit tuaj. Ndërtoni një prototip. Ky do të jetë një prototip që tregon tiparet që jeni duke u përpjekur të merrni. Prototipi është program i shpejtëdhe duhet të rregullohet për të gjetur një dizajn që funksionon. Për shembull, nëse krijoni një orar për një kalendar, prototipi juaj do të jetë një kalendar i thjeshtë dhe një mënyrë për të shtuar ngjarje.

Prototipi juaj do të ndryshojë shpesh gjatë ciklit të zhvillimit ndërsa gjeni mënyra të reja për të zgjidhur problemet ose mendoni për një ide që dëshironi të integroni në programin tuaj. Në fakt, grafika dhe dizajni duhet të jenë një nga gjërat e fundit për t'u përqëndruar.

Prototipi nuk ka nevojë të redaktohet grafikisht.
Duke përdorur shembullin e kalendarit, prototipi juaj duhet të jetë vetëm me tekst.

Gabimet në kod dhe përdorimet e papritura mund të shkaktojnë shumë probleme në produktin e përfunduar. Provoni sa më shumë që të mundeni, ndërsa vazhdoni të punoni në prototipin tuaj.

Jam i bindur që një programues është, para së gjithash, një kodues - ai NUK duhet të komunikojë me klientin, ai NUK duhet të mendojë për arkitekturën e sistemit, ai nuk duhet të shpikë një ndërfaqe me programin, ai duhet të kodojë vetëm - të zbatojë algoritme, funksionalitet, pamja e jashtme, përdorshmëria, por jo më shumë. Nga ana tjetër, projektuesi duhet, duke filluar nga diagramet abstrakte (duke përshkruar zonën e temës) te diagramet që përfaqësojnë strukturën e të dhënave, klasat dhe proceset e ndërveprimit të tyre, të përshkruajnë gjithçka hap pas hapi në detaje. Kjo është, kompleksiteti i punës dhe paga e krijuesit duhet të jetë një rend i madhësisë më i lartë se ai i programuesit \u003d\u003d kodues. Na vjen keq për kryengritjen ...

Bëni më të mirën tuaj për të gjetur mete të programit dhe më pas përpiquni të shmangni mete në të ardhmen. Provoni një program për miqtë dhe familjen dhe kërkoni që të ju tregojnë se çfarë gjetën. Datat shumë të vjetra ose e ardhmja e largët mund të shkaktojë reagime të çuditshme në program.

Mundohuni të futni data të çuditshme nëse programi juaj punon me data.
Vendosni llojet e ndryshoreve të pavlefshme.

Përfundoni projektet tuaja. Ndërsa ky është vetëm një draft i përafërt për prototipin dhe fazën e zhvillimit, nëse doni që përdoruesit e tjerë ta përdorin atë, do të duhet të merrni kohë për ta përfunduar.

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

Kjo do të thotë që menutë janë të lidhura logjikisht, që ndërfaqja e përdoruesit të jetë e pastër dhe e lehtë për t’u përdorur, që nuk ka ndonjë gabim të dukshëm ose kritik dhe që grafika të mbështetet mirë. Dizajni i ndërfaqes mund të jetë shumë kompleks dhe kompleks, ka profesionistë që i përkushtohen vetëm këtij aspekti të programimit, thjesht sigurohuni që projekti juaj personal të jetë i lehtë për t'u përdorur dhe i kënaqshëm për shikuesin. llogari e madhe dhe ekipi i zhvillimit. Nëse keni para, mund të punësoni një dizajner grafik për të bërë ndërfaqen për ju. Nëse keni krijuar një projekt të shkëlqyeshëm që mund të jetë një program i suksesshëm, gjeni një projektues të mirë dhe vendosini në ekip. Kjo do t'ju lejojë të merrni sugjerime për kodin tuaj dhe të ndihmoni të tjerët që kërkojnë zgjidhje që mund të gjeni.

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

Një nga më të vjetrat, nënkupton një kalim të njëpasnjëshëm të fazave, secila prej të cilave duhet të përfundojë plotësisht para fillimit të fazës tjetër. Modeli Waterfall është i lehtë për tu menaxhuar me projektin. Për shkak të ngurtësisë së tij, zhvillimi është i shpejtë, kostoja dhe afati janë të paracaktuara. Por kjo është një shpatë me dy tehe. Modeli i ujëvarës do të japë rezultat i shkëlqyeshëm vetëm në projekte me kërkesa të qarta dhe të paracaktuara dhe metodat e zbatimit të tyre. Nuk ka asnjë mënyrë për të bërë një hap prapa, testimi fillon vetëm pasi zhvillimi të ketë përfunduar ose gati të ketë përfunduar. Produktet e zhvilluara sipas këtij modeli pa një zgjedhje të arsyeshme mund të kenë defekte (lista e kërkesave nuk mund të rregullohet në çdo kohë), e cila bëhet e njohur vetëm në fund për shkak të sekuencës së rreptë të veprimeve. Kostoja e bërjes së një ndryshimi është e lartë sepse duhet të presë që i gjithë projekti të përfundojë për ta iniciuar atë. Sidoqoftë, kostoja fikse shpesh tejkalon të metat e qasjes. Korrigjimi i mangësive të realizuara në procesin e krijimit është i mundur, dhe, në përvojën tonë, kërkon nga një deri në tre marrëveshje shtesë për kontratën me një TK të vogël.

Shpërndani softuerin. Pasi të keni një produkt të përfunduar, mund të vendosni nëse do ta shpërndani atë apo jo. Ka shumë mënyra për ta bërë këtë, varësisht nga lloji i programit që krijoni. Një metodë e përdorur nga shumica e ekipeve ose zhvilluesve të pavarur është publikimi i softuerit në një faqe personale në internet. Sigurohuni që të gjitha tiparet e programit janë të dokumentuara mirë dhe përfshijnë imazhe dhe manuale. Nëse jeni duke shitur programin tuaj, sigurohuni që të ofroni një dixhital sistemi i pagesave dhe përdorni një server ku mund ta shpërndani atë. Nëse jeni duke zhvilluar softuer për një pajisje specifike ose sistemi operativ, ju mund të përdorni një nga shumë dyqanet dixhitale. Kur biznesi juaj është specifik, dhe zgjidhjet standarde të softuerit nuk mund të plotësojnë kërkesat tuaja, ju keni nevojë për një program të veçantë të krijuar posaçërisht për ju.

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

Kur përdoret metodologjia e ujëvarave?

Vetëm kur kërkesat dihen, kuptohen dhe rregullohen. Nuk ka kërkesa kontradiktore.
Nuk ka asnjë problem me disponueshmërinë e programuesve të kualifikimeve të duhura.
Në projekte relativisht të vogla.

2. "Modeli V"

Trashëguar strukturën hap pas hapi nga modeli i ujëvarë. Modeli në formë V është i zbatueshëm për sistemet për të cilat funksionimi i qetë është veçanërisht i rëndësishëm. Për shembull, aplikacione klinike për monitorimin e pacientit, softuer i integruar për kontrollin e jastëkëve të automjeteve, etj. Një tipar i modelit mund të konsiderohet se ka për qëllim kontrollimin dhe testimin e plotë të një produkti që tashmë është në fazat fillestare të dizajnit. Faza e testimit ndodh njëkohësisht me fazën përkatëse të zhvillimit, për shembull, testet njësi shkruhen gjatë kodimit.

Si klient, ju do të merrni softuerin që ju nevojitet nga ne. Qëllimi ynë është të krijojmë aplikacione afatshkurtra të shpejta dhe të besueshme që plotësojnë nevojat dhe kërkesat e klientëve tanë. Përpjekjet tona kanë për qëllim krijimin e zgjidhjeve cilësore që mund të përdoren në mënyrë intuitive dhe të lehtë nga ekspertë të fushave të ndryshme, jo vetëm specialistë të IT-së. Teknologjitë që përdorim për të zhvilluar softuer sigurojnë fleksibilitet dhe hapësirë \u200b\u200bpër zhvillimin e aplikacioneve në të ardhmen.

Klientët tanë mund të mbështeten në zgjidhje të standardizuara dhe të personalizuara për të përmbushur kërkesat e tyre. Siguroni zgjidhjen e duhur për nevojat tuaja. Ju ndihmojmë të bëni sa më shumë investime në teknologjinë tuaj. Ky proces referohet si një cikël i vazhdueshëm për të siguruar që çdo projekt të jetë në përputhje me qëllimet tuaja afatgjata të biznesit.

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

Kur përdoret modeli V?

Nëse kërkohet një test 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 qartë dhe të fiksuara.
Në kushtet e disponueshmërisë së inxhinierëve me kualifikimet e nevojshme, veçanërisht testuesit.

3. "Modeli në rritje" (modeli në rritje)

Në një model në rritje, kërkesat e përgjithshme të sistemit ndahen në asamble të ndryshme. Terminologjia shpesh përdoret për të përshkruar montimin në faza të softuerit. Disa cikle zhvillimi ndodhin dhe së bashku ato përbëjnë ciklin e jetës me shumë ujëvara. Laku është i ndarë në module më të vogla, lehtësisht të ndërtueshme. Secili modul kalon nëpër fazat e përcaktimit, dizajnit, kodimit, zbatimit dhe testimit të kërkesave. Procedura e zhvillimit e bazuar në modelin rritës supozon lëshimin në fazën e parë të madhe të produktit në funksionalitetin themelor, dhe më pas shtimin vijues të funksioneve të reja, të ashtuquajturat "rritje". Procesi vazhdon derisa të krijohet një sistem i plotë.

Modelet në rritje përdoren aty ku kërkesat individuale të ndryshimit 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 elektronike Vivaldi.

Le të përshkruajmë thelbin e një rritje si një shembull. zëvendësoi DefView. DefView është i lidhur me një server të dokumenteve dhe tani mund të lidhet me shumë. Në faqen e një institucioni që dëshiron të transmetojë përmbajtjen e tij në një audiencë të veçantë, është instaluar një server i ruajtjes që akseson drejtpërdrejt në dokumente dhe i kthen ato në formatin e dëshiruar... U shfaq elementi rrënjësor i arkitekturës - serveri qendror Vivaldi, i cili vepron si një i vetëm motor kërkimi nëpër të gjithë serverat e ruajtjes të instaluar në institucione të ndryshme.

Kur përdoret një model në rritje?

Kur kërkesat themelore për sistemin janë përcaktuar dhe kuptuar qartë. Në të njëjtën kohë, disa detaje mund të përmirësohen me kalimin e kohës.
Kërkohet fillimi i hershëm i tregut.
Ka disa karakteristika ose qëllime të rrezikshme.

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

Modeli RAD është një lloj modeli rritës. Në një model RAD, komponentët ose funksionet zhvillohen nga disa ekipe shumë të kualifikuara paralelisht, si disa mini-projekte. Afati kohor për një cikël është rreptësisht i kufizuar. Modulet e krijuara integrohen më pas në një prototip që funksionon. Sinergjia ju lejon të siguroni shumë shpejt klientin për të parë diçka që funksionon në mënyrë që të merrni reagime dhe duke bërë ndryshime.

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

Modelimi i biznesit: përcaktimi i një liste të flukseve 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 dizajnit.
Ndërtoni aplikacionin: Përdor mjetet e montimit automatik për të kthyer modelet CAD në kod.
Testimi: testohen përbërës dhe ndërfaqe të reja.

Kur përdoret modeli RAD?

Mund të përdoret vetëm me arkitektë shumë të kualifikuar dhe shumë të specializuar. Buxheti i projektit është i madh për të paguar për këta specialistë së bashku me koston e mjeteve të gatshme të montimit të automatizuar. Modeli RAD mund të zgjidhet me njohuri të sigurta për biznesin e synuar dhe nevojën për prodhim urgjent të sistemit brenda 2-3 muajve.

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

Në një metodologji zhvillimi "të shkathët", pas çdo përsëritje, klienti mund të vëzhgojë rezultatin dhe të kuptojë nëse e plotëson atë 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ësosh kostot e punës dhe koston e nevojshme për zhvillim. Programim ekstrem (XP) është një nga përdorimet më të njohura praktike të modelit të shkathët.

Ky lloj bazohet në takime të shkurtra ditore të quajtura "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ë detyrash që punonjësi duhet të kryejë përpara takimit të radhës;
vështirësitë e hasura gjatë punës.

Metodologjia është e përshtatshme për projekte të mëdha ose afatgjata që përshtaten vazhdimisht me kushtet e tregut. Prandaj, kërkesat ndryshojnë gjatë procesit të zbatimit. Vlen të kujtohet klasa e njerëzve krijues që tentojnë të gjenerojnë, lëshojnë dhe provojnë ide të reja në baza javore apo edhe ditore. Zhvillimi i shkathët është më i përshtatshmi për këtë lloj drejtuesi. Ne zhvillojmë startup të brendshëm duke përdorur Agile. Një shembull i projekteve të klientëve është Sistemi Elektronik i Provimeve Mjekësore, i krijuar për të kryer ekzaminime masive mjekësore brenda pak minutash. Në paragrafin e dytë të këtij rishikimi, partnerët tanë amerikanë përshkruan një gjë shumë të rëndësishme që është thelbësore për suksesin në Agile.

Kur ta përdorim Agile?

Kur nevojat e përdoruesve ndryshojnë vazhdimisht në një biznes dinamik.
Ndryshimet e shkathëta zbatohen me më pak kosto për shkak të rritjeve të shpeshta.
Ndryshe nga një model ujëvarë, në një model fleksibël, mjafton një planifikim i vogël për të filluar një projekt.

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

Një model i ciklit jetësor përsëritës 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ë ideal, gjëja kryesore është që ajo të funksionojë. Duke kuptuar qëllimin përfundimtar, ne përpiqemi për të në mënyrë që secili hap të jetë efektiv, dhe secili version të jetë i zbatueshëm.

Diagrami tregon "zhvillimin" përsëritës të Mona Lizës. Siç mund ta shihni, në përsëritjen e parë ekziston vetëm një skicë e Mona Lisa, në të dytën - shfaqen ngjyrat, dhe përsëritja e tretë shton detaje, mbushje dhe përfundon procesin. Në modelin rritës, funksionaliteti i produktit ndërtohet pjesë për pjesë, produkti përbëhet nga pjesë. Ndryshe nga modeli përsëritës, secila pjesë është një element koherent.

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 është përmirësuar. Sidoqoftë, njohja e përsosur ende nuk është arritur, prandaj, problemi nuk është zgjidhur ende plotësisht.

Kur është optimale të përdoret një model përsëritës?

Kërkesat për sistemin përfundimtar janë të përcaktuara mirë dhe të kuptuara paraprakisht.
Projekti është i madh ose shumë i madh.
Sfida kryesore duhet të përcaktohet, por detajet e zbatimit mund të evoluojnë me kalimin e kohës.

7. "Modeli spiral"

Modeli Spiral është i ngjashëm me modelin rritës, por me një theks në analizën e rrezikut. Funksionon mirë për zgjidhjen e problemeve kritike të biznesit, kur dështimi është i papajtueshëm me aktivitetet e ndërmarrjes, në kushtet e linjave të produkteve të reja, kur kërkimi dhe testimi praktik është i nevojshëm.

Modeli spiral merr 4 faza për secilin lak:

planifikimi;
analiza e rrezikut;
dizajni;
vlerësimi i rezultatit dhe, me një cilësi të 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 projekte komplekse dhe të shtrenjta, siç është zhvillimi i një sistemi të menaxhimit të dokumenteve për një bankë, kur secili hap tjetër kërkon më shumë analiza për të vlerësuar pasojat sesa programimi. Në lidhje me 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ë bashkon dy dosje. Projektet shtetërore në të cilat morëm pjesë filluan me përgatitjen e një koncepti të shtrenjtë nga komuniteti i ekspertëve, i cili nuk është aspak gjithmonë i padobishëm, pasi që ju jep shpagim në shkallë vendi.

Le të përmbledhim

Rrëshqitja tregon ndryshimet midis dy metodologjive më të zakonshme.

Në praktikën moderne, modelet e zhvillimit të softverit janë shumë variabla. Nuk ka asnjë të vërtetë për të gjitha projektet, kushtet fillestare dhe modelet e pagesës. Edhe Agile, aq i dashur për të gjithë ne, nuk mund të zbatohet kudo për shkak të mungesës së disa klientëve ose 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 po përdorni?