Avantaje și dezavantaje ale modelului de cascadă. Avantajele modelului de cascadă. Modelul de dezvoltare a cascadei de atenuare a riscurilor - o modificare a cascadei clasice, care adaugă spirale de reducere a riscului care împart proiectul în mini-proiecte și le corespund acestora

Metodologia de dezvoltare software este organizarea muncii, inclusiv principii ideologice, un plan, control asupra proceselor, o abordare a angajaților. Să selectăm 12 tipuri:

Cascada este abordarea tradițională.
RUP (Rational Unified Process) este rațional.
Agile este o metodologie generală pentru dezvoltarea agilă.
Crystal Clear este o abordare de nivelare a echipei.
Spirala este o metodă spirală.
DSDM (Dynamic Systems Development Model) este un model dinamic.
FDD (Feature Driven Development) este o metodologie care ia în considerare schimbările viitoare.
JAD (Joint Application Development) este o abordare centrată pe utilizator.
RAD (Rapid Application Development) este un model de dezvoltare rapidă.
Scrum este un concept de lucru în condiții de termene limită ratate și criză ideologică.
XP (Extreme Programming) - dezvoltare extremă într-un mediu dinamic.
LD (Lean Development) este o metodă care presupune respect pentru toți participanții la proces.

Să încercăm să ne dăm seama ce se ascunde în spatele acestor nume englezești.

Cascadă

Modelul Waterfall se referă la înțelegerea clasică a dezvoltării software. Întregul proces este rigid și liniar, are obiective clare pentru fiecare etapă, la sfârșitul celei anterioare începe o nouă fază, fără întoarcere. Avantajele metodologiei cascade sunt descentralizarea și controlul strict asupra calendarului și calității execuției.

În practică, Cascada nu corespunde așteptărilor, deoarece ignoră schimbările dinamice. Deci, după testare, este foarte dificil să retragi procesul și să stabilești funcții care nu au fost luate în considerare în etapa de dezvoltare. Cascada este, de asemenea, ineficientă, deoarece implică perioade temporare de nefuncționare pentru angajați în cadrul unui singur proiect. Testarea se face doar la sfârșitul dezvoltării, deși problemele găsite în această etapă sunt remedieri costisitoare.

RUP

RUP este o abordare iterativă care rezolvă problemele pe care le are Waterfall. De ce este bun RUP:

Permite schimbarea cerințelor. Oricât de bun este managerul de proiect, este imposibil să iei în calcul totul la început.
Integrarea funcțiilor are loc treptat, adică fiecare „detaliu” trece printr-un ciclu de dezvoltare, testare și implementare în proiect. Ca urmare, riscurile și costurile de producție sunt reduse.
Lansare timpurie a produsului. Software-ul iese cu funcționalitate redusă pentru a ocupa o nișă pe piață și a rezista concurenților, după care devine copleșit de „carne”.
Reutilizați. Când construiți funcționalitatea, este mai ușor de evidențiat soluții tipice care va reduce dezvoltarea.
Învățare continuă. Datorită iterațiilor frecvente, dezvoltatorii nu au pauze lungi între revizuirile de cod, așa că creștere profesională se întâmplă fără probleme și fără durere.
Îmbunătățirea continuă a produsului. Iterațiile vă permit să evaluați proiectul nu numai în ceea ce privește conformitatea cu planul și specificațiile tehnice, ci și să găsiți modalități de a crește eficiența și calitatea produsului.

Agil

Agile este o metodă de dezvoltare agilă software care implică un număr mare de iterații. Documentul Agile Manifesto descrie 4 idei și 12 principii ale unei abordări agile, poate fi descris pe scurt cu doar două puncte:

Relațiile informale sunt mai importante decât cele documentate. Adică acordurile verbale între angajați, între client și antreprenor sunt cele mai importante, ceea ce se reflectă în planuri, contracte și termeni de referinta... Cu alte cuvinte, clientul are întotdeauna dreptate.
Un produs de lucru este principala măsură a progresului. Nu instrumentele, soluțiile, performanța și finețea contează, ci faptul că toate caracteristicile planificate au fost implementate.

În ciuda deficiențelor sale, Agile a devenit un concept fundamental pentru dezvoltarea software și se reflectă în alte metodologii, care vor fi discutate mai jos.

Cristal limpede

Metodologie concepută pentru echipe mici de 6-10 angajați. Susține, de asemenea, principiile dezvoltării agile, dar are ceva mai multă specificitate. Ideea principală, care este conținută în nume - fiecare echipă este un set de oameni cu niveluri diferite de cunoștințe, abilități și experiență diferite.

De aceea nu există o abordare universală pentru dezvoltarea software-ului, aceasta trebuie determinată în procesul de comunicare în cadrul grupului. Acolo sunt atribuite și roluri, instrumente, standarde. Apoi grupul este luat ca unitate și aceleași probleme sunt rezolvate cu un nivel mai înalt până când ierarhia ajunge la client.

Spirală

Model în spirală ciclu de viață este o organizare complexă a ciclului de viață al software-ului care se concentrează pe identificarea timpurie și diminuarea riscurilor proiectului. Dezvoltarea începe la scară mică, problemele locale sunt rezolvate, riscurile sunt evaluate și modalitățile de reducere a acestora. Următorul pas acoperă sarcini mai complexe - următoarea tură a spiralei.

Avantajul acestei abordări nu este de a crește viteza de dezvoltare, ci de a reduce nivelul de apariție a riscului. Succesul metodei spiralate depinde de un management bun, atent și competent, iar dimensiunea proiectului nu este critică.

DSDM

Modelul de dezvoltare a sistemelor dinamice a fost dezvoltat în Marea Britanie la mijlocul anilor 1990 și este o dezvoltare evolutivă a dezvoltării rapide a aplicațiilor (RAD). Ideea de bază este standard: atunci când planificați de la început, este imposibil să înțelegeți toate subtilitățile dezvoltării, astfel încât întregul proces este muncă de cercetare.

În DSDM există și o divizare în echipe, fiecare având o persoană autorizată să ia decizii strategice. Toate părțile interesate pot participa la proces: utilizatori, dezvoltatori, clienți, manageri. Testarea se efectuează pe parcursul întregului ciclu de viață.

FDD

FDD este un proces pentru asigurarea scalabilității și repetabilității, încurajând în același timp creativitatea și inovația. Iată principiile de bază:

Dezvoltarea fiecărui proiect major trebuie să fie sistematică.
Procesele ar trebui să fie simple și bine definite.
Valoarea și coerența procesului ar trebui să fie clare pentru fiecare membru al echipei.
Sunt de preferat cicluri scurte de dezvoltare iterativă. Acest lucru reduce numărul de erori și vă permite să construiți funcționalități mai rapid.

FDD reglementează timpul care trebuie alocat fiecărui proces. Activitati organizatoriceîntr-un ciclu nu ar trebui să ia mai mult de 23-25%, în timp ce 75-77% din timp ar trebui să fie alocat dezvoltării directe, asamblarii și testării funcțiilor.

JAD

JAD este o metodologie menită să profite la maximum de dezvoltarea utilizatorilor finali. Acest lucru se întâmplă prin întâlniri și seminarii comune. JAD a fost inventat în anii 1970 de către angajații IBM și este destinat afacerii în general. Cu toate acestea, de-a lungul timpului, acest concept a fost aplicat cu succes dezvoltării de software.

Spre deosebire de abordarea Waterfall, JAD are ca rezultat timpi de dezvoltare mai scurti, o mai mare satisfacție a clienților și economii de costuri în cercetarea de piață. Pe de altă parte, acest lucru necesită un eșantion mare de clienți și necesitatea dezvoltatorilor de a lucra nu cu cerințe stricte ale specificației tehnice, ci cu o opinie în continuă schimbare.

RAD

RAD este o metodologie care acordă prioritate vitezei și ușurinței dezvoltării. Una dintre condițiile principale este utilizarea unui limbaj de dezvoltare rapidă. Acesta este numele unui limbaj de programare abstract, cu ajutorul căruia un programator este capabil să rezolve probleme mai rapid decât reprezentanții generației a treia (C/C++, Pascal sau Fortran). Iată încă câteva puncte ale conceptului:

Utilizarea focus-grupurilor pentru a colecta cerințe.
Prototiparea și testarea de către utilizatori a design-urilor.
Reutilizarea componentelor software.
Folosirea unui plan care nu include reproiectarea sau proiectarea următoarei versiuni a produsului.
Desfășurarea de ședințe informale la cererea uneia dintre părți.

RAD presupune utilizarea unui întreg set de instrumente pe lângă limbajul de dezvoltare rapidă: sisteme de colectare a cerințelor, medii de dezvoltare, cadre, programe pentru comunicare în grup, software pentru testare.

Scrum

Scrum - metoda flexibila managementul proiectelor, al cărui scop este creșterea productivității muncii în echipele anterior paralizate de procese metodologice mai dificile. Conceptul se bazează pe „sprinturi”. Sprintul este o iterație scurtă, strict limitată în timp (de obicei 2-4 săptămâni). În acest timp, durata întâlnirilor este redusă la minimum, dar frecvența acestora crește (se numesc „contracții”).

Acest lucru face controlul execuției mai flexibil, iar dezvoltatorii răspund mai rapid la problemele emergente. Planificarea tradițională trece în fundal, fiind înlocuită de jurnalul de sprint.

XP

Programare extremă - capacitatea de a se dezvolta în fața cerințelor în continuă schimbare. Iată câteva semne:

Joc de planificare. La începutul proiectului, există doar un plan brut, după fiecare iterație, claritatea acestuia crește.
Frecvența mare a lansărilor. Noua versiune a produsului are modificări minore comparativ cu precedentul, dar timpul de lansare este minim.
Contact client. Pentru a satisface cerințele publicului final, este necesar raspuns prompt pentru comentarii si sugestii.
Refactorizarea. Îmbunătățirea calității codului fără a sacrifica funcționalitatea.
Standard de executare a codului. Sau sunt aplicate reguli generale, sau dezacordurile în design nu sunt supuse discuțiilor și criticilor.
Responsabilitate colectivă. În ciuda faptului că fiecare membru al echipei își desfășoară propria secțiune de lucru, întreaga echipă este responsabilă pentru codul în ansamblu.

LD

Dezvoltarea software Lean este o altă ramură metodologie agilă, care presupune păstrarea unui moral ridicat și a unei stări funcționale a dezvoltatorilor. Aceasta se exprimă în:

Recompensarea angajaților pentru munca de succes.
Schimbarea sarcinilor curente doar la nevoie sau la cererea clientului.
Îndeplinirea strictă a planului: totul în exces este considerat o pierdere de timp și resurse.
Implementarea conceptului general „A gândi larg, a face puțin, a greși rapid, a învăța rapid”.

În contextul unui scurt rezumat, este dificil să dezvălui toate avantajele și dezavantajele metodologiilor, să arate domenii eficiente de aplicare. Vom vorbi separat despre cele mai relevante concepte astăzi. Care? Lasă-ți dorințele în comentarii.

Dezvoltarea software nu este ca ingineria tradițională. O metodologie este ceea ce este folosit de dezvoltatori pentru a descompune munca în pași progresivi gestionați, în care fiecare pas poate fi validat pentru a asigura calitatea. Echipele lucrează împreună cu clientul pentru a crea un gata făcut produs software folosind una dintre metodologiile de dezvoltare software. Cele mai populare dintre ele sunt considerate modelul în spirală, cascadă sau cascadă (Waterfall); RAD sau Dezvoltare rapidă a aplicațiilor; Model Agile, sau model flexibil și iterativ, sau model iterativ. Există și alte opțiuni, dar în acest articol vom lua în considerare doar modelul în cascadă sau în cascadă și vom explora, de asemenea, avantajele și dezavantajele acestuia. Să explicăm imediat că este o secvență de anumiți pași, iar particularitatea sa este aceea noua etapa nu este posibil până la finalizarea celui precedent.

Istoria modelului cascadei

Metodologia în forma sa tradițională lasă puțin loc pentru schimbări neașteptate. Dacă echipa de dezvoltare nu este prea mare, iar proiectele sunt previzibile, atunci Waterfall se poate asigura că sunt finalizate într-un anumit interval de timp.

Modelul de dezvoltare a cascadei există de peste patruzeci de ani. A fost descris pentru prima dată în 1970 într-un articol al lui W. Royce ca fiind unul dintre cele mai vechi modele oficiale pentru procesul de dezvoltare. A fost descris ca fiind ineficient pentru proiecte mari de dezvoltare de software, dar nimeni nu a interzis utilizarea lui pentru cele mici. La aproape o jumătate de secol după ce a fost descoperită, această tehnică încă contează în lumea afacerilor de astăzi. Se numește modelul moștenit și este tratat cu oarecare dispreț din cauza învechirii abordării tradiționale de management al designului. Dar Waterfall este o abordare utilă și previzibilă atunci când cerințele sunt fixe, bine documentate și clare, când tehnologia este clară și când proiectul nu durează mult până la finalizare. În acest caz, modelul în cascadă poate oferi un rezultat final mai previzibil pentru un anumit buget, cronologie și sfera de activitate.

Ce este un model de dezvoltare a cascadei?

Modelul Waterfall poate fi descris ca o dezvoltare liniară, secvențială a proiectului, în care procesele se deplasează constant de la cerințe la proiectare, apoi la implementare, validare și implementare, urmată de întreținere continuă. Se crede că modelul cascadă al ciclului de viață a fost creat datorită lui W. Royce, deși el însuși a folosit un model de dezvoltare iterativ.

Accentul principal în dezvoltarea modelului Waterfall este pus pe planificare, calendar, obiective, bugete și în cele din urmă implementarea întregului sistem ca un singur obiect. Principalele avantaje aici sunt planificarea și implementarea simplă înainte și înapoi.

Descrierea modelului de cascadă

În comparație cu alte metodologii, Waterfall se concentrează mai mult pe un set clar și definit de pași. Modelul original a constat din cinci pași. Este adesea descris ca un model liniar secvenţial al ciclului de viaţă. Aceasta înseamnă că urmează o structură simplă de fază, în care rezultatele fiecărei faze progresează la următorul nivel de dezvoltare. Principalele etape sunt:

Colectarea cerințelor și crearea documentației.
Proiectare și inginerie de sistem.
Implementarea.
Testare și implementare.
A sustine.

Echipele trebuie să finalizeze întregul pas înainte de a trece la următorul, așa că dacă ceva nu este gata până la o anumită dată, devine imediat vizibil. Și, de asemenea, spre deosebire de Six Sigma sau Scrum, Waterfall nu necesită certificare sau pregătire specială pentru managerii de proiect sau angajați.

Critica la modelul cascadei

Modelul ciclului de viață al cascadei Sistem informatic a fost criticat pentru inflexibilitatea sa după parcurgerea fiecărui pas și pentru întârzierea capacității clientului de a oferi feedback. Cu toate acestea, această metodologie poate funcționa bine pe proiecte mici cu bugete limitate. Este adesea comparată cu o metodologie binecunoscută pentru ciclul de viață al proiectului, PRINCE2, care a fost creată de guvernul Regatului Unit. Această metodologie este folosită și astăzi în sectorul public. Una dintre diferențele cheie dintre PRINCE2 și modelul ciclului de viață al cascadei este că acesta din urmă necesită o descriere în scris toate cerințele de la bun început, pentru că mai târziu va fi dificil să le revizuim. Înainte de a începe crearea oricărui cod, acesta trebuie definit și fixat cu precizie. Acesta este un avantaj important al modelului ciclului de viață al cascadei.

Avantaje și dezavantaje ale modelului cascadă

Deoarece documentația tehnică este o parte necesară a fazei inițiale de dezvoltare a cerințelor, aceasta înseamnă că toți membrii echipei înțeleg clar obiectivele proiectului. Dezvoltatorii noi își pot da seama rapid de regulile de codare și pot intra în fluxul de lucru fără prea multe probleme. Dacă se folosește un model în cascadă al ciclului de viață al unui sistem informatic sau al unui proiect, etapizarea asigură disciplina.

Fiecare pas are un punct de plecare și o concluzie bine definite, ceea ce face ușoară monitorizarea progresului. Acest lucru ajută la reducerea oricărei abateri a proiectului de la intervalul de timp convenit. În acest model, spre deosebire de spirală, software-ul este considerat ca un întreg. Prin urmare, cu condiția îndeplinirii tuturor cerințelor, funcționează mai eficient. Dacă continuăm să comparăm modelele ciclului de viață în cascadă și spirală, putem concluziona că primul este mai universal și poate fi aplicat în diverse domenii.

Etapa de discuție a cerințelor

Un alt avantaj al modelului cascadă ciclului de viață este că costurile pot fi estimate cu un grad destul de ridicat de acuratețe după ce toate cerințele au fost identificate. Dacă se aplică, înseamnă că în prima etapă, toate scenariile de testare sunt deja detaliate în specificația funcțională, ceea ce face procesul de testare mai simplu și mai transparent. Și, de asemenea, chiar înainte de începerea dezvoltării software, designul este elaborat în detaliu, ceea ce face ca nevoile și rezultatul să fie ușor de înțeles pentru toată lumea.

Unul dintre beneficiile importante ale utilizării Waterfall este încercarea de a obține produsul final, sau rezultatul final, încă de la început. Prin urmare, echipele trebuie să evite abaterea de la obiectiv. Pentru proiectele mici în care intenția este suficient de clară, acest pas face echipa conștientă de Tel comun de la bun început, ceea ce reduce șansa de a te pierde în detalii pe măsură ce proiectul avansează. Abordarea Waterfall este foarte metodică, motiv pentru care subliniază importanța comunicării curate a informațiilor în fiecare etapă. În procesul de dezvoltare a software-ului, la fiecare nou pas apar oameni noi. Prin urmare, este important să ne străduim să documentăm informațiile de-a lungul întregului ciclu de viață al proiectului.

Dezavantajele modelului ciclului de viață în cascadă

Potențialele probleme de dezvoltare pot fi investigate și rezolvate în timpul fazei de proiectare. De asemenea, sunt elaborate soluții alternative și sunt selectate cele optime. Toate acestea se întâmplă înainte de începerea proiectului. Multe organizații apreciază atenția acordată documentării de la început, deoarece înseamnă, de asemenea, că nu ar trebui să existe surprize cu produsul final. Dar, în practică, rareori reușești să faci fără modificări. Clienților le este adesea dificil să-și înțeleagă propriile nevoi în ceea ce privește specificațiile funcționale în etapa formării cerințelor. Aceasta înseamnă că se pot răzgândi de îndată ce văd produsul final. Această problemă este greu de rezolvat. Uneori, o aplicație trebuie reproiectată aproape complet.

Lipsa flexibilității în modelul cascadă

Un alt dezavantaj al modelului cascadă al ciclului de viață al unui IP (sau al unui proiect) este potențiala lipsă de flexibilitate. Pot apărea întrebări cu privire la noile modificări sau modificări ale cerințelor care au apărut de la consultarea inițială.

Este posibil ca ajustările datorate planurilor de afaceri sau influențelor pieței să nu fi fost luate în considerare în planificare. De asemenea, proiectele pot dura mai mult decât utilizarea unei metodologii iterative precum Agile.

Puncte importante atunci când utilizați metodologia cascadă

Când vine vorba de dezvoltarea Waterfall, este foarte important ca dezvoltatorii de software să poată ghida și sfătui eficient clienții să rezolve mai târziu toate aceste probleme. Adesea, cel mai critic aspect al utilizării modelului ciclului de viață în cascadă este că clienții nu știu cu adevărat ce își doresc cu adevărat. În multe cazuri, comunicarea reală bidirecțională între dezvoltatori și clienți nu are loc până când clientul vede modelul în acțiune.

Pentru comparație, în dezvoltarea Agile, clientul poate vedea fragmente de cod de lucru care au fost create în timpul lucrului la proiect. Spre deosebire de Scrum, care împarte proiectele în sprinturi separate, Waterfall se concentrează întotdeauna pe obiectivul final. Dacă echipa ta are un obiectiv specific cu o dată clară de încheiere, Waterfall va elimina riscul de a rata un termen limită atunci când lucrezi la el. Pe baza acestor avantaje și dezavantaje, dezvoltarea Waterfall este, în general, recomandată pentru proiectele care cel mai probabil nu se vor schimba sau nu vor avea nevoie de noi dezvoltări pe parcursul ciclului de viață al proiectului.

Ce este un model de cascadă

Ciclul de viață al software-ului este perioada de existență a software-ului asociată cu pregătirea pentru dezvoltarea, dezvoltarea, utilizarea și prelucrarea acestuia, începând din momentul în care se ia decizia de a dezvolta sistem nou până în momentul în care toată folosirea lui este complet oprită. Modelul ciclului de viață al software-ului identifică seturi specifice de activități, artefacte, roluri și relațiile lor. Determină care artefacte sunt date de intrare pentru care activități și care artefacte apar ca rezultate, ce roluri sunt implicate în diverse activități, modul în care activitățile se leagă între ele în timp, care sunt criteriile de calitate ale rezultatelor obținute, cum se evaluează gradul de corespondență al diferitelor artefacte sarcini comune proiect și când să treci de la o activitate la alta.

Model în cascadă al ciclului de viață al software-ului presupune implementarea secvențială a diferitelor etape de activitate, inclusiv analiza cerințelor, proiectarea, codificarea și testarea modulelor (componentelor) individuale, testarea ansamblurilor și testarea integrată a întregului produs final. În acest caz, se presupune o delimitare clară a etapelor, la care setul de documente elaborat în etapa anterioară este transmis ca date de intrare pentru următoarea. Astfel, fiecare tip de activitate se desfășoară într-o anumită fază a ciclului de viață al software-ului, mișcarea în reversul acest lanț este imposibil.

Etapele activității

Analiză. În etapa de analiză, sarcina pe care programul ar trebui să o îndeplinească este studiată și determinată. Rezultatul acestei faze este un set de cerințe software.

Proiecta. În această etapă, cerințele identificate în timpul analizei sunt transformate într-o descriere a principiilor de decizie - un document în conformitate cu care se iau decizii specifice la implementarea programului. Principalul rezultat al celei de-a doua faze este primirea unui proiect, care poate include un text în limbaj natural, un model software, algoritmi, tabele, formule matematice etc. Proiectarea detaliată presupune alocarea componentelor software, determinarea structurii acestora și metode de interacțiune.

Implementarea. La finalizarea proiectării inițiale, urmează faza de implementare, în care modulele software identificate în timpul proiectării sunt create și testate. Principalele rezultate ale acestei faze sunt modulele de cod sursă și testele unitare de sine stătătoare. După implementare, se procedează la testarea sistemului și apoi la punerea în funcțiune.

Implementare și exploatare. Produsul software finit este predat clientului, se efectuează teste de acceptare, se efectuează instruirea utilizatorilor și operarea de probă, după care software-ul este întreținut și începe operarea de producție a sistemului software.

Dezavantajele abordării în cascadă

Acumularea diferitelor greșeli comise în primele etape ale proiectului. Dacă doar spre finalul proiectului devine evident că s-au făcut greșeli, atunci orice revenire la etapele anterioare pentru a corecta greșelile devine extrem de costisitoare. Metoda „cascadei” nu identifică și nu atenuează în mod eficient consecințele unor astfel de riscuri.
Creșterea nejustificată a timpului de implementare, depășirile bugetare și riscul de eșec complet al proiectului datorită acumulării de erori de la etapă la etapă.
Toate deciziile cheie sunt luate atunci când analiștii și dezvoltatorii nu au o înțelegere completă a sistemului. Este foarte dificil să potriviți procesul real de creare a software-ului într-o schemă atât de rigidă, așa că este întotdeauna nevoie să reveniți la etapele anterioare pentru a clarifica și revizui mai devreme. deciziile luate... La începutul unui proiect, dezvoltatorii se confruntă cu sarcina descurajantă de a defini complet toate cerințele de sistem. Pentru aceasta, este necesar să discutăm amănunțit și cuprinzător cu utilizatorii și să cercetăm procesele de afaceri. Utilizatorii ar trebui să fie de acord cu tot ceea ce reiese dintr-un astfel de sondaj, deși este posibil să nu fie pe deplin familiarizați cu rezultatele. Cu puțin noroc în acest fel, în faza de analiză, este posibil să colectăm aproximativ 80% din cerințele de sistem. În timpul proiectării, pot apărea noi probleme, acestea trebuie discutate din nou cu utilizatorii, ceea ce va duce la apariția de noi cerințe pentru sistem. În procesul de implementare și testare, se descoperă adesea că unele dintre soluțiile adoptate anterior nu pot fi implementate sau rezultă că cerințele nu au fost suficient de detaliate și implementarea lor este incorectă. Trebuie să reveniți la etapa de analiză și să revizuiți aceste cerințe.
Metoda cascadei nu permite adaptarea rapidă la schimbări, în special în etapele ulterioare ale ciclului de viață al software-ului.
Este posibil ca produsul final să nu fie solicitat din cauza unei declarații inexacte a cerințelor sau a modificărilor acestora de-a lungul unei lungi perioade de dezvoltare a software-ului.

Când se aplică abordarea în cascadă

Abordarea cascadă funcționează bine în proiectele în care cerințele pentru produsul software sunt clar definite și nu ar trebui să se schimbe, nu este necesară implicarea clientului în procesul de dezvoltare. Același lucru este valabil și pentru proiectele software, a căror complexitate este determinată de necesitatea de a implementa algoritmi complecși, iar rolul și domeniul de aplicare al interfeței cu utilizatorul sunt mici.

Comparația dintre cascadă și abordări iterative

Figura de mai jos arată clar diferențele dintre abordările în cascadă și iterative. Abordarea în cascadă presupune fixarea funcționalității software și posibilitatea de a varia timpul și resursele (de obicei în sus din motivele prezentate mai sus).

Cu abordarea în cascadă, clientul este implicat în proiect doar într-un stadiu incipient (pentru a determina cerințele software) sau, dacă este necesar, pentru a face modificări descoperite de dezvoltatori. El poate evalua doar rezultatul final, care poate să nu corespundă ideilor sale.

Abordarea iterativă presupune participarea reprezentantului clientului la proiect în toate etapele. O abordare iterativă face posibilă facilitarea și simplificarea semnificativă a procesului de schimbare a funcționalității software.

Principalele avantaje ale abordării iterative pot fi rezumate după cum urmează:

Capacitatea de a atenua impactul riscurilor grave în fazele incipiente ale proiectului, în timp ce acest lucru poate fi încă realizat cu cost minim... Diferența de cost al erorii în determinarea cerințelor la începutul proiectului și la sfârșitul proiectului este egală cu 1: 200.
capacitatea de a organiza feedback fructuos cu viitorii utilizatori finali pentru a crea un sistem care să răspundă cu adevărat nevoilor acestora;
concentrarea eforturilor pe cele mai importante și critice zone ale proiectului;
testarea iterativă continuă a produsului final pentru a evalua succesul întregului proiect în ansamblu;
detectarea precoce a discrepanțelor între cerințe, modele și codul programului;
utilizarea eficientă a experienței acumulate;
evaluare reală a stării actuale a proiectului și, ca urmare, o mai mare încredere a clienților și a participanților direcți în finalizarea cu succes a acestuia.

programare,

Dezvoltarea aplicațiilor mobile

Dezvoltarea de produse software cunoaște multe metodologii decente - cu alte cuvinte, cele mai bune practici bine stabilite. Alegerea depinde de specificul proiectului, de sistemul de bugetare, de preferințele subiective și chiar de temperamentul managerului. Acest articol descrie metodologiile pe care le întâlnim în mod regulat la Edison.

1. „Model cascadă” (model în cascadă sau „cascada”)

Una dintre cele mai vechi, implică o trecere secvențială de etape, fiecare dintre acestea trebuie finalizată complet înainte de începerea următoarei. Este ușor de gestionat proiectul în modelul Waterfall. Datorită rigidității sale, dezvoltarea este rapidă, costurile și timpul sunt prestabilite. Dar aceasta este o sabie cu două tăișuri. Modelul cascadă va oferi doar rezultate excelente în proiecte cu cerințe clare și predefinite și modalități de implementare a acestora. Nu există nicio modalitate de a face un pas înapoi, testarea începe doar după ce dezvoltarea este finalizată sau aproape finalizată. Produsele dezvoltate conform acestui model fără o alegere rezonabilă a acestuia pot avea defecte (lista de cerințe nu poate fi ajustată în niciun moment), care devine cunoscută abia la sfârșit datorită secvenței stricte a acțiunilor. Costul efectuării unei modificări este mare, deoarece trebuie să aștepte finalizarea întregului proiect pentru a-l inițializa. Cu toate acestea, costul fix depășește adesea dezavantajele abordării. Corectarea deficiențelor percepute în procesul de creație este posibilă și, din experiența noastră, necesită de la unu la trei acorduri suplimentare la un contract cu un mic TK.

Cu ajutorul modelului cascada am realizat multe proiecte de la zero, inclusiv elaborarea doar a specificațiilor tehnice. Proiecte despre care se scrie pe Habré: mediu -, mic -.

Când să folosiți metodologia cascadă?

Doar atunci când cerințele sunt cunoscute, înțelese și fixate. Nu există cerințe contradictorii.
Nu există probleme cu disponibilitatea programatorilor cu calificările potrivite.
În proiecte relativ mici.

2. „V-Model”

A moștenit structura pas cu pas din modelul cascadei. Modelul în formă de V este aplicabil sistemelor în care funcționarea fără probleme este deosebit de importantă. De exemplu, aplicații clinice pentru monitorizarea pacientului, software integrat pentru controlul airbag-urilor vehiculului și așa mai departe. O caracteristică a modelului poate fi considerată că are ca scop verificarea și testarea amănunțită a unui produs care se află deja în fazele inițiale de proiectare. Faza de testare are loc concomitent cu faza de dezvoltare corespunzătoare, de exemplu, testele unitare sunt scrise în timpul codării.

Un exemplu al muncii noastre bazat pe metodologia V - o aplicație mobilă pentru european operator celular ceea ce economisește taxele de roaming în timpul călătoriei. Proiectul este realizat conform unei specificații tehnice clare, dar include o etapă semnificativă de testare: confortul interfeței, funcțional, încărcare și inclusiv integrarea, care ar trebui să confirme că mai multe componente de la diferiți producători lucrează împreună stabil, este imposibil. să fure bani și împrumuturi.

Când să folosiți modelul V?

Dacă este necesară o testare amănunțită a produsului, atunci modelul V va justifica ideea de bază: validare și verificare.
Pentru proiecte mici și mijlocii în care cerințele sunt clar definite și fixate.
In conditiile de disponibilitate a inginerilor cu calificarile necesare, in special a testatorilor.

3. „Model incremental”

Într-un model incremental, cerințele generale ale sistemului sunt împărțite în diferite ansambluri. Terminologia este adesea folosită pentru a descrie asamblarea în faze a software-ului. Au loc mai multe cicluri de dezvoltare și împreună constituie ciclul de viață cu mai multe cascade. Bucla este împărțită în module mai mici, ușor de creat. Fiecare modul trece prin fazele de definire a cerințelor, proiectare, codificare, implementare și testare. Procedura de dezvoltare bazată pe modelul incremental presupune lansarea în prima etapă mare a produsului în funcționalitatea de bază, iar apoi adăugarea secvențială de noi funcții, așa-numitele „incremente”. Procesul continuă până când este creat un sistem complet.

Modelele incrementale sunt utilizate în cazul în care cererile individuale de modificare sunt clare și pot fi formalizate și implementate cu ușurință. În proiectele noastre, l-am folosit pentru a crea un cititor DefView și apoi o rețea biblioteci electronice Vivaldi.

Să descriem esența unui increment ca exemplu. a înlocuit DefView. DefView s-a conectat la un server de documente și acum se poate conecta la mai multe. Un server de stocare este instalat pe site-ul unei instituții care dorește să-și difuzeze conținutul unui anumit public, care accesează direct documentele și le convertește în formatul dorit. A apărut elementul rădăcină al arhitecturii - serverul central Vivaldi, care acționează ca un singur motor de căutare pe toate serverele de stocare instalate în diferite instituții.

Când să folosiți un model incremental?

Când cerințele de bază pentru sistem sunt clar definite și înțelese. În același timp, unele detalii pot fi îmbunătățite în timp.
Lansarea timpurie pe piață este necesară.
Există mai multe caracteristici sau obiective riscante.

4. „Model RAD” (model de dezvoltare rapidă a aplicațiilor sau dezvoltare rapidă a aplicațiilor)

Modelul RAD este un fel de model incremental. Într-un model RAD, componentele sau funcțiile sunt dezvoltate de mai multe echipe înalt calificate în paralel, precum mai multe mini-proiecte. Perioada de timp pentru un ciclu este strict limitată. Modulele create sunt apoi integrate într-un prototip de lucru. Synergy vă permite să oferiți foarte rapid un client pentru a revizui ceva care funcționează pentru a obține feedback și a face modificări.

Modelul de dezvoltare rapidă a aplicațiilor include următoarele faze:

Modelarea afacerilor: definirea unei liste de fluxuri de informații între diferite departamente.
Modelarea datelor: Informațiile adunate în pasul anterior sunt folosite pentru a defini obiectele și alte entități necesare pentru a circula informațiile.
Modelarea proceselor: fluxurile de informații leagă obiectele pentru a atinge obiectivele de proiectare.
Creați aplicația: utilizează instrumente de asamblare automată pentru a converti modelele CAD în cod.
Testare: noi componente și interfețe sunt testate.

Când este utilizat modelul RAD?

Poate fi folosit numai cu arhitecți cu înaltă calificare și înaltă specializare. Bugetul proiectului este mare de plătit pentru acești specialiști, împreună cu costul instrumentelor de asamblare automatizate gata făcute. Modelul RAD poate fi ales cu cunoștințe sigure despre afacerea țintă și necesitatea producției urgente a sistemului în 2-3 luni.

5. „Model Agile” (metodologie de dezvoltare flexibilă)

Într-o metodologie de dezvoltare „agilă”, după fiecare iterație, clientul poate observa rezultatul și poate înțelege dacă este mulțumit de acesta sau nu. Acesta este unul dintre avantajele unui model flexibil. Dezavantajele sale includ faptul că, din cauza lipsei de formulări specifice a rezultatelor, este dificil de estimat costurile forței de muncă și costurile necesare dezvoltării. Extreme Programming (XP) este una dintre cele mai cunoscute utilizări ale modelului agil în practică.

Acest tip se bazează pe întâlniri zilnice scurte numite „Scrum” și întâlniri periodice periodice (o dată pe săptămână, o dată la două săptămâni sau o dată pe lună) numite „Sprint”. În întâlnirile zilnice, membrii echipei discută:

un raport despre munca depusă de la ultimul Scrum;
o listă de sarcini pe care angajatul trebuie să le îndeplinească înainte de următoarea întâlnire;
dificultăți întâmpinate în timpul muncii.

Metodologia este potrivită pentru proiecte mari sau pe termen lung care se adaptează constant la condițiile pieței. În consecință, cerințele se modifică în timpul procesului de implementare. Merită să ne amintim de clasa de oameni creativi care tind să genereze, să emită și să încerce idei noi săptămânal sau chiar zilnic. Dezvoltarea agilă este cea mai potrivită pentru acest tip de lider. Dezvoltăm startup-uri interne folosind Agile. Un exemplu de proiecte ale clienților este Sistemul Electronic de examinări medicale, creat pentru a efectua examene medicale în masă în câteva minute. În al doilea paragraf al acestei recenzii, partenerii noștri americani au descris un lucru foarte important care este fundamental pentru succesul pe Agile.

Când să folosești Agile?

Când nevoile utilizatorilor sunt în continuă schimbare într-o afacere dinamică.
Schimbările agile sunt implementate la un cost mai mic datorită creșterilor frecvente.
Spre deosebire de modelul în cascadă, într-un model flexibil, doar puțină planificare este suficientă pentru a începe un proiect.

6. „Model iterativ”

Un model de ciclu de viață iterativ nu necesită o specificare completă a cerințelor pentru a începe. În schimb, crearea începe cu implementarea unei piese de funcționalitate, care devine baza pentru definirea cerințelor ulterioare. Acest proces se repetă. Este posibil ca versiunea să nu fie ideală, principalul lucru este că funcționează. Înţelegere scopul suprem, ne străduim pentru aceasta, astfel încât fiecare pas să fie eficient și fiecare versiune să fie funcțională.

Diagrama arată „dezvoltarea” iterativă a Mona Lisa. După cum puteți vedea, în prima iterație există doar o schiță a Mona Lisei, în a doua apar culori, iar a treia iterație adaugă detalii, saturație și completează procesul. În modelul incremental, funcționalitatea produsului este construită bucată cu piesă, produsul este compus din piese. Spre deosebire de model iterativ, fiecare piesă este un element coerent.

Un exemplu de dezvoltare iterativă este recunoașterea vocii. Prima cercetare și pregătire a aparatului științific a început cu mult timp în urmă, la început - în gânduri, apoi - pe hârtie. Cu fiecare nouă iterație, calitatea recunoașterii s-a îmbunătățit. Cu toate acestea, recunoașterea perfectă nu a fost încă atinsă, prin urmare, problema nu a fost încă rezolvată pe deplin.

Când este optim să folosiți un model iterativ?

Cerințele pentru sistemul final sunt bine definite și ușor de înțeles în prealabil.
Proiectul este mare sau foarte mare.
Principala provocare trebuie definită, dar detaliile de implementare pot evolua în timp.

7. „Model în spirală”

Modelul Spiral este similar cu modelul incremental, dar cu accent pe analiza riscului. Funcționează bine pentru rezolvarea problemelor critice de afaceri, când eșecul este incompatibil cu activitățile companiei, când sunt lansate noi linii de produse, când sunt necesare cercetări și teste practice.

Modelul spirală presupune 4 etape pentru fiecare buclă:

planificare;
analiza de risc;
proiecta;
evaluarea rezultatului și, dacă calitatea este satisfăcătoare, trecerea la o nouă rundă.

Acest model nu este potrivit pentru proiecte mici, este rezonabil pentru proiecte complexe și costisitoare, precum dezvoltarea unui sistem de management al documentelor pentru o bancă, când fiecare pas următor necesită mai multe analize pentru a evalua consecințele decât programarea. Despre proiectul de dezvoltare a unui EDMS pentru ODU din Siberia, SO UES, două întâlniri privind schimbarea codificării secțiunilor arhiva electronica ia de 10 ori mai mult decât programatorul care fuzionează două foldere. Proiectele de stat la care am participat au început cu pregătirea unui concept costisitor de către comunitatea de experți, care nu este deloc întotdeauna inutil, pentru că dă roade la scară națională.

Să rezumam

Slide-ul arată diferențele dintre cele două metodologii cele mai comune.

În practica modernă, modelele de dezvoltare software sunt multivariate. Nu există nimeni adevărat pentru toate proiectele, condiţiile de pornireși modele de plată. Chiar și atât de îndrăgit de noi toți, Agile nu poate fi aplicat universal din cauza indisponibilității unor clienți sau a imposibilității finanțării flexibile. Metodologiile se suprapun parțial în mijloace și sunt oarecum asemănătoare între ele. Alte concepte au fost folosite doar pentru a-și promova propriile compilatoare și nu au adus în practică nimic nou.

Despre tehnologiile de dezvoltare:
.
.
.
.

Numai utilizatorii înregistrați pot participa la sondaj. Intrati va rog.

Din păcate, nu există un proces unic de dezvoltare de software care să se potrivească fiecărui proiect. În prim-plan se află metodologiile - sisteme de standarde care conțin concepte, metode și tehnici care definesc stilul de dezvoltare software.

Metodologia este selectată, în primul rând, pentru sarcini specifice, domeniul de activitate, obiectivele clienților și buget. În al doilea rând, nu uitați de specificul companiei IT. Suportul tehnic, externalizarea și dezvoltarea internă a proiectului dumneavoastră implică abordări diferite.

Unele dintre cele mai comune categorii de modele de dezvoltare software sunt Agile și Waterfall, flexibil și, respectiv, Waterfall. Vom da scurta descriere fiecare, luați în considerare avantajele, dezavantajele și decideți asupra sistemului corect pentru proiect.

Metodologiile agile aderă la principiile de proiectare iterativă. Procesul de creare a produsului este împărțit într-o serie de cicluri scurte de 1-4 săptămâni. Fiecare iterație este un proiect separat cu planificare, proiectare, programare, testare și retrospectivă.

Dezvoltatorii agili aleg de obicei între o echipă dedicată și un sistem de timp și materiale (T&M) atunci când plătesc dezvoltatorii. Am comparat deja unele dintre mecanismele de construire a relațiilor financiare cu un antreprenor. Descoperirile noastre din perspectiva clientului și dezvoltatorului pot fi găsite.

Modelul de dezvoltare agilă se bazează pe 12 principii, dintre care considerăm următoarele definitorii:

software-ul de lucru este cel mai bun indicator al eficacității echipei de dezvoltare;
cerințele de editare sunt încurajate în orice stadiu de dezvoltare;
comunicarea personală este cea mai productivă modalitate de comunicare;
versiuni noi ale produsului sunt lansate fie la fiecare iterație, fie la câteva luni, în funcție de proiect.

Clasa Agile include tehnici precum Extreme Programming (XP), FDD, DSDM, Scrum și altele.

Cascadă

Principiu sistem în cascadă constă dintr-o succesiune. Procesul de dezvoltare este împărțit în următorii pași:

1. Analiza cerințelor

2. Planificare

3. Implementare

4. Integrare

5. Testare

7. Suport

Trecerea la fiecare fază are loc numai după încheierea celei anterioare. Noi funcții sunt adăugate după lansare și remedieri pentru erorile anterioare. Datorită documentației clare și cerințelor stabile pentru proiectele în cascadă, un model de interacțiune financiară cu preț fix este mai potrivit.

Acum să comparăm cei puternici și părțile slabe Agil și Cascada.

Avantajele metodologiilor:

Model flexibil

Ajustările cerințelor funcționale sunt incluse în procesul de dezvoltare pentru a se asigura avantaj competitiv... De fapt, după 2 iterații, proiectul poate fi implementat la 360 de grade și poate realiza un produs complet diferit.
Proiectul este împărțit în iterații scurte și transparente.
Minimizați riscurile cu un proces de schimbare flexibil.
Obțineți rapid prima versiune funcțională a produsului.

Model în cascadă

O structură de proces clară și simplă, convenabilă pentru echipele cu puțină experiență.
Documentație de înaltă calitate și detaliată.
Proiectul poate urmări cu ușurință resursele, riscurile și timpul petrecut.
Obiectivele produsului sunt consistente de la început până la sfârșit.

Contra metodologiilor:

Model flexibil

Este imposibil să se calculeze cantitatea exactă de muncă din cauza cerințelor în continuă schimbare.
Deoarece Agile este mai mult o filozofie decât un proces, trebuie să vă scufundați în sistem și să-l acceptați, ceea ce nu este necesar pentru fiecare proiect.
Echipa trebuie să fie înalt calificată și cu experiență, orientată către client.
Noile cerințe pot intra în conflict cu arhitectura sau funcționalitatea existente.
Cu toate ajustările și schimbările, există riscul ca proiectul să nu se termine niciodată.

Model în cascadă

Cerințele sunt definite și fixate chiar de la început, ceea ce face ca procesul de dezvoltare să fie flexibil.
Mai mult timp și resurse sunt cheltuite pentru proiect.
Clientul va vedea doar produsul finit, este extrem de greu de schimbat ceva.
Lipsa feedback-urilor între etapele de dezvoltare.

După ce am studiat materialul, putem învăța cu ușurință să jonglam Agile și Waterfall în proiectele noastre!

Modelul de dezvoltare agilă este valabil dacă:

1. O echipă cu experiență este implicată în proiect.

2. Funcționalitatea finală a produsului este încă necunoscută, iar modificările trebuie făcute cât mai repede posibil.

3. Utilizatorul final este „gătit” în proiect încă de la început.

4. Este necesar să se dezvolte rapid software de lucru.

5. Sunteți un startup.

Alegeți un model de cascadă atunci când:

1. Cerințele pentru proiect sunt stabile și practic neschimbate;

2. Calitatea produsului este mult mai importantă decât timpul și resursele cheltuite;

3. Proiectul este în curs de dezvoltare pe outsourcing;

4. Utilizatorul final acceptă doar rezultatul lucrării, neparticipând la proces.

Trebuie spus că ambele modele vă vor ajuta să vă implementați proiectul. In primul rand, alegi varianta care iti permite sa realizezi produse de calitate si sa iti gestionezi eficient bugetul.

Bineînțeles, odată ce ai ajuns în cursa de acasă, nimeni nu va fi interesat de metodologia aleasă. Prin urmare, chiar dacă modelul de dezvoltare s-a dovedit a fi nepotrivit, echipa trebuie să fie suficient de puternică pentru a obține rezultate decente.

Acum du-te și fă-ți proiectul!

Ar putea fi util să citiți: