Pro și contra contra modelului cascadei. Avantajele modelului de cascadă. Model de dezvoltare a cascadei de atenuare a riscurilor - o modificare a cascadei clasice, care adaugă spirale de reducere a riscurilor care împart proiectul în mini-proiecte și le corespund

Metodologia de dezvoltare software este organizarea muncii, inclusiv principiile ideologice, un plan, controlul 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 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 de software. Întregul proces este rigid și liniar, are obiective clare pentru fiecare etapă, o nouă fază începe la sfârșitul celei anterioare, nu există întoarcere. Avantajele metodologiei cascadei sunt descentralizarea și controlul strict asupra calendarului și calității execuției.

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

RUP

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

Permite modificarea cerințelor. Pe cât de bun este managerul de proiect, este imposibil să ții cont de toate 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.
Lansarea 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 acoperit de „carne”.
Reutilizați. Atunci când creșteți funcționalitatea, este mai ușor să identificați soluțiile tipice care vor reduce dezvoltarea.
Învățare continuă. Datorită iterațiilor frecvente, dezvoltatorii nu au pauze lungi între revizuirile codului, astfel încât creșterea profesională este lină și nedureroasă.
Î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 spori eficiența și calitatea produsului.

Agil

Agile este o metodă de dezvoltare software agilă care implică un număr mare de iterații. Documentul Manifest Agil 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 dintre angajați, dintre client și interpret sunt cele mai importante, ceea ce se reflectă în planuri, contracte și termeni de referință. Cu alte cuvinte, clientul are întotdeauna dreptate.
Un produs funcțional 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 neajunsurilor sale, Agile a devenit un concept fundamental pentru dezvoltarea de software și se reflectă în alte metodologii, care vor fi discutate mai jos.

Cristal clar

Metodologie creată pentru echipe mici de 6-10 angajați. De asemenea, susține principiile dezvoltării agile, dar are ceva mai multe detalii. Ideea principală, care este conținută în nume - fiecare echipă este o colecție 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, acesta trebuie determinat în procesul de comunicare din cadrul grupului. Roluri, instrumente, standarde sunt, de asemenea, atribuite acolo. Apoi grupul este luat ca unitate și aceleași probleme sunt rezolvate cu un nivel mai mare până când ierarhia ajunge la client.

Spirală

Spiral Lifecycle Model este o organizație complexă a ciclului de viață al software-ului, care se concentrează pe identificarea timpurie și reducerea 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 abordării nu este creșterea vitezei de dezvoltare, ci reducerea nivelului de apariție a riscului. Succesul metodei în spirală 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 planificăm la început, este imposibil să înțelegem toate subtilitățile dezvoltării, prin urmare întregul proces este o lucrare de cercetare.

DSDM are, de asemenea, o diviziune în echipe, fiecare dintre acestea 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 tot parcursul ciclului de viață.

FDD

FDD este un proces care asigură scalabilitatea și repetabilitatea, î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 consecvența procesului ar trebui să fie clare pentru fiecare membru al echipei.
Sunt preferate ciclurile de dezvoltare iterative scurte. Aceasta reduce bug-urile și permite acumularea mai rapidă a funcționalității.

FDD reglementează timpul care trebuie petrecut pentru fiecare dintre procese. Activitățile organizatorice din ciclu nu ar trebui să dureze mai mult de 23-25%, în timp ce 75-77% din timp ar trebui să fie cheltuit pentru dezvoltarea directă, asamblarea și testarea funcțiilor.

JAD

JAD este o metodologie care vizează ocuparea maximă în 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 vizează afacerea î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 scurți, o mai mare satisfacție a clienților și economii în cercetarea pieței. Pe de altă parte, acest lucru necesită un eșantion mare de clienți și necesitatea ca dezvoltatorii să lucreze nu cu cerințe stricte ale specificațiilor tehnice, ci cu o opinie în continuă schimbare.

RAD

RAD este o metodologie care prioritizează viteza și ușurința dezvoltării. Una dintre condițiile principale este utilizarea unui limbaj de dezvoltare rapidă. Acesta este numele unui limbaj de programare abstract, cu care un programator este capabil să rezolve problemele mai repede decât reprezentanții celei de-a treia generații (C / C ++, Pascal sau Fortran). Iată câteva alte puncte ale conceptului:

Folosirea focus grupurilor pentru a colecta cerințe.
Prototiparea și testarea de către utilizatori a proiectelor.
Reutilizarea componentelor software.
Folosirea unui plan care nu include relucrarea sau proiectarea următoarei versiuni a produsului.
Organizarea de întâlniri informale la cererea uneia dintre părți.

RAD își asumă utilizarea unui set întreg de instrumente în plus față de limbajul de dezvoltare rapidă: sisteme de colectare a cerințelor, medii de dezvoltare, cadre, programe pentru comunicarea de grup, software pentru testare.

Scrum

Scrum este o metodă flexibilă de gestionare a proiectelor care urmărește creșterea productivității în echipe care anterior erau paralizate de procese metodologice mai grele. 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 ședințelor este minimizată, dar frecvența acestora crește (se numesc „contracții”).

Acest lucru face controlul execuției mai flexibil, iar dezvoltatorii răspund mai repede la problemele emergente. Planificarea tradițională ocupă un loc în spate la jurnalul 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 dur, după fiecare iterație, claritatea acestuia crește.
Frecvența ridicată a lansărilor. Noua versiune a produsului are modificări minore în comparație cu cea precedentă, dar timpul de lansare este minim.
Contactați clientul. Pentru a îndeplini cerințele publicului final, este necesar un răspuns prompt la comentarii și sugestii.
Refactorizare. Îmbunătățirea calității codului fără a sacrifica funcționalitatea.
Standard de execuție a codului. Fie se aplică regulile generale, fie dezacordurile în proiectare nu sunt supuse discuției și criticilor.
Responsabilitatea 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ă a metodologiei agile, care implică menținerea unui moral ridicat al dezvoltatorilor. Aceasta se exprimă în:

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

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

Dezvoltarea software-ului nu este ca ingineria tradițională. O metodologie este ceea ce este folosit de dezvoltatori pentru a împărți munca în pași progresivi gestionabili, în care fiecare pas poate fi validat pentru a asigura calitatea. Echipele lucrează împreună cu clientul pentru a crea un produs software finit folosind una dintre metodologiile de dezvoltare software. Cele mai populare dintre ele sunt considerate modelul în spirală, cascadă sau cascadă (Cascadă); RAD sau Dezvoltarea Rapidă a Aplicațiilor Model Agile, sau model flexibil și iterativ sau iterativ. Există alte opțiuni, dar în acest articol vom analiza doar cascada sau cascada, modelăm și explorăm avantajele și dezavantajele acesteia. Să explicăm imediat că este o succesiune de anumiți pași, iar particularitatea sa este că o nouă etapă este imposibilă până la finalizarea celei anterioare.

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 și proiectele sunt previzibile, atunci Cascada se poate asigura că acestea 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 de W. Royce ca unul dintre primele modele oficiale pentru procesul de dezvoltare. A fost descris ca ineficient pentru proiectele mari de dezvoltare de software, dar nimeni nu interzice utilizarea acestuia pentru cele mici. La aproape jumătate de secol după ce a fost descoperită, această tehnică are încă un sens în lumea afacerilor de astăzi. Se numește modelul moștenit și este tratat cu oarecare dispreț din cauza caducității abordării tradiționale de gestionare a designului. Dar Cascada 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 cascadei poate oferi un rezultat final mai previzibil pentru un anumit buget, cronologie și sarcină de lucru.

Ce este un model de dezvoltare a cascadei?

Modelul Waterfall poate fi descris ca o dezvoltare liniară, secvențială a proiectului, în care procesele trec în mod constant de la cerințe la proiectare, apoi la implementare, validare și implementare, urmată de întreținere continuă. Se crede că modelul cascadei 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 în conformitate cu modelul 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 simple înainte și înapoi.

Descrierea modelului cascadei

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

Colectarea cerințelor și crearea documentației.
Proiectarea și ingineria sistemului.
Implementare.
Testare și implementare.
A sustine.

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

Critica modelului cascadei

Modelul de cascadă al ciclului de viață al sistemului informațional a fost criticat pentru inflexibilitatea sa după finalizarea fiecărei etape, precum și pentru întârzierea capacității clientului de a oferi feedback. Cu toate acestea, această metodologie poate funcționa bine pentru proiecte mici cu bugete limitate. Este adesea comparat cu o metodologie binecunoscută a ciclului de viață al proiectului, PRINCE2, care a fost creată de guvernul britanic. Această metodologie este utilizată ș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 scrisă a tuturor cerințelor de la început, deoarece vor fi dificil de revizuit ulterior. Înainte de a începe crearea oricărui cod, acestea trebuie definite și fixate cu precizie. Acesta este un avantaj important al modelului ciclului de viață al cascadei.

Pro și contra modelului cascadei

Deoarece documentația tehnică este o parte necesară a fazei inițiale de dezvoltare a cerințelor, acest lucru înseamnă că toți membrii echipei înțeleg clar obiectivele proiectului. Noii dezvoltatori îș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 de cascadă a ciclului de viață al unui sistem sau proiect de informații, 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 termenul convenit. În acest model, spre deosebire de spirală, software-ul este considerat ca un întreg. Prin urmare, dacă toate cerințele sunt îndeplinite, funcționează mai eficient. Dacă continuăm să comparăm modelele ciclului de viață în cascadă și în spirală, putem concluziona că primul este mai universal și poate fi aplicat în diferite domenii.

Etapa de discuție privind cerințele

Un alt avantaj al modelului cascadei ciclului de viață este că costurile pot fi estimate cu un grad destul de ridicat de precizie după identificarea tuturor cerințelor. Dacă este aplicat, î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-ului, proiectarea 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 cascadei este căutarea pentru produsul final sau rezultatul final de la bun î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 la început de obiectivul comun, reducând șansele de a se pierde în detaliu pe măsură ce proiectul avansează. Abordarea cascadei este foarte metodică, deci subliniază importanța comunicării informațiilor curate în fiecare etapă. În procesul de dezvoltare de software, apar oameni noi la fiecare pas nou. Prin urmare, este important să ne străduim să documentăm informații pe parcursul întregului ciclu de viață al proiectului.

Dezavantaje ale modelului ciclului de viață al cascadei

Problemele potențiale de dezvoltare pot fi investigate și rezolvate în timpul fazei de proiectare. Soluțiile alternative sunt, de asemenea, elaborate și sunt selectate cele optime. Toate acestea se întâmplă înainte de începerea proiectului. Multe organizații apreciază din timp atenția asupra documentației, 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ă a face modificări. Clienților le este greu să-și înțeleagă propriile nevoi în ceea ce privește specificațiile funcționale în etapa de formare a cerințelor. Aceasta înseamnă că se pot răzgândi imediat ce văd produsul final. Această problemă este greu de rezolvat. Uneori, o aplicație trebuie reproiectată aproape complet.

Lipsa de flexibilitate în modelul cascadă

Un alt dezavantaj al modelului de cascadă al ciclului de viață al IS (sau al proiectului) este lipsa potențială de flexibilitate. Pot apărea întrebări cu privire la noile modificări sau modificări ale cerințelor care au avut loc 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 timp pentru a fi finalizate în comparație cu utilizarea unei metodologii iterative, cum ar fi Agile.

Puncte importante atunci când se utilizează metodologia cascadei

Când vine vorba de dezvoltarea cascadei, este foarte important ca dezvoltatorii de software să poată ghida și sfătui în mod eficient clienții să rezolve toate aceste probleme ulterior. Adesea, cel mai critic aspect al utilizării unui model al ciclului de viață al cascadei este acela că clienții nu știu cu adevărat ce își doresc cu adevărat. În multe cazuri, adevărata comunicare bidirecțională între dezvoltatori și clienți nu are loc până când clientul nu 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, Cascada se concentrează întotdeauna pe scopul final. Dacă echipa dvs. are un obiectiv specific cu o dată de încheiere clară, Cascada va elimina riscul de a pierde un termen limită atunci când lucrați la el. Pe baza acestor argumente pro și contra, dezvoltarea cascadei este în general recomandată pentru proiectele care este puțin probabil să se schimbe sau să aibă 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 sa, de la momentul în care se ia decizia de a dezvolta un nou sistem până la momentul în care întreaga sa utilizare este oprită complet. Modelul ciclului de viață al software-ului identifică seturi specifice de activități, artefacte, roluri și relația lor. Determină ce artefacte sunt date de intrare pentru ce tipuri de activități și ce artefacte apar ca rezultate, ce roluri sunt implicate în diferite activități, cum se raportează activitățile între ele în timp, care sunt criteriile de calitate ale rezultatelor obținute, cum să evalueze gradul de corespondență a diferitelor artefacte cu cele comune sarcinile proiectului și când să treci de la o activitate la alta.

Model cascadă a ciclului de viață al software-ului implică implementarea secvențială a diferitelor etape de activitate, inclusiv analiza cerințelor, proiectarea, codificarea și testarea modulelor individuale (componente), testarea ansamblurilor și testarea integrată a întregului produs final. Aceasta presupune o delimitare clară a etapelor în care setul de documente dezvoltate în etapa anterioară este transmis ca date de intrare pentru următoarea. Astfel, fiecare tip de activitate se efectuează la o singură fază a ciclului de viață al software-ului, mișcarea în direcția opusă de-a lungul acestui lanț este imposibilă.

Etape de activitate

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

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

Implementare. După finalizarea proiectării inițiale, urmează faza de implementare, în care sunt create și testate modulele software identificate în timpul proiectării. 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 funcționare. Produsul software finit este predat clientului, se efectuează teste de acceptare, se efectuează instruirea utilizatorilor și se efectuează testarea, după care software-ul este întreținut și începe operațiunea de producție a sistemului software.

Dezavantaje ale abordării cascadei

Acumularea diferitelor greșeli făcute în primele etape ale proiectului. Dacă doar spre sfârșitul proiectului, devine evident că s-au făcut greșeli, atunci orice revenire la etapele anterioare pentru a remedia greșelile devine extrem de costisitoare. Metoda „cascadei” nu identifică și nivelează în mod eficient consecințele unor astfel de riscuri.
Creșterea nejustificată a timpului de implementare, depășirea bugetului și riscul eșecului 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ă se încadreze procesul real de creare a software-ului într-o schemă atât de rigidă, deci există o nevoie constantă de a reveni la etapele anterioare pentru a clarifica și revizui deciziile luate anterior. La începutul unui proiect, dezvoltatorii se confruntă cu o sarcină descurajantă: definirea completă a tuturor cerințelor de sistem. Pentru aceasta, este necesar să discutați temeinic și cuprinzător cu utilizatorii și să cercetați procesele de afaceri. Utilizatorii ar trebui să fie de acord cu tot ceea ce rezultă dintr-un astfel de sondaj, deși este posibil să nu fie familiarizați cu rezultatele. Cu ceva noroc în acest fel, în etapa de analiză, este posibil să colectăm aproximativ 80% din cerințele sistemului. La proiectare, pot apărea noi probleme, acestea trebuie discutate din nou cu utilizatorii, ceea ce va duce la 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 că 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 declarației inexacte a cerințelor sau a modificărilor acestora pe o perioadă lungă de timp de dezvoltare software.

Când se aplică abordarea cascadei

Abordarea cascadei funcționează bine în proiecte în care cerințele pentru produsul software sunt clar definite și nu ar trebui să se schimbe, implicarea clientului în procesul de dezvoltare nu este necesară. Același lucru se aplică proiectelor software, a căror complexitate este determinată de necesitatea implementării algoritmilor complexi, iar rolul și domeniul de aplicare al interfeței cu utilizatorul sunt mici.

Comparația cascadei și abordările iterative

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

Cu abordarea cascadei, clientul este implicat în proiect doar într-un stadiu incipient (pentru a determina cerințele software-ului) sau, dacă este necesar, pentru a face modificările 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-ului.

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

Capacitatea de a atenua impactul riscurilor grave în primele etape ale proiectului, în timp ce acesta poate fi realizat cu costuri minime. Diferența în costul unei erori la determinarea cerințelor la începutul proiectului și la sfârșit este de 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 lor;
concentrarea eforturilor pe cele mai importante și critice domenii ale proiectului;
testarea iterativă continuă a produsului final, care vă permite să evaluați succesul întregului proiect în ansamblu;
detectarea timpurie a discrepanțelor dintre cerințe, modele și codul programului;
utilizarea efectivă a experienței acumulate;
o evaluare reală a stării actuale a proiectului și, ca rezultat, o mai mare încredere a clienților și a participanților direcți la finalizarea cu succes a acestuia.

Programare,

Dezvoltarea de aplicații mobile

Dezvoltarea produselor software cunoaște multe metodologii bune - 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. „Modelul cascadei” (modelul cascadei sau „cascada”)

Una dintre cele mai vechi, implică trecerea secvențială a etapelor, fiecare dintre acestea trebuie finalizată complet înainte de începerea următoarei. Modelul Waterfall este ușor de gestionat proiectul. Datorită rigidității sale, dezvoltarea este rapidă, costul și intervalul de timp sunt prestabilite. Dar aceasta este o sabie cu două tăișuri. Modelul cascadei va oferi doar rezultate excelente în proiecte cu cerințe și modalități 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 în conformitate cu acest model fără o alegere rezonabilă pot avea defecte (lista cerințelor nu poate fi ajustată în niciun moment), care devine cunoscută doar la sfârșit datorită secvenței stricte de acțiuni. Costul efectuării unei modificări este ridicat, 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 realizate în procesul de creare este posibilă și, din experiența noastră, necesită de la unu la trei acorduri suplimentare la contract cu un TK mic.

Cu ajutorul modelului cascadă, am creat multe proiecte de la zero, inclusiv dezvoltarea numai a specificațiilor tehnice. Proiecte despre care este scris pe Habré: mediu - mic -.

Când se folosește metodologia cascadei?

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

2. „Model V”

A moștenit structura pas cu pas de modelul cascadei. Modelul în formă de V este aplicabil sistemelor pentru care funcționarea lină este deosebit de importantă. De exemplu, aplicații clinice pentru monitorizarea pacientului, software integrat pentru mecanisme de control al accidentelor vehiculelor și așa mai departe. O caracteristică a modelului poate fi considerată faptul că vizează verificarea și testarea amănunțită a unui produs care se află deja în etapele 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 este o aplicație mobilă pentru un operator european de telefonie mobilă care economisește costurile de roaming în timpul călătoriilor. Proiectul se desfășoară în conformitate cu o specificație tehnică clară, dar include o etapă semnificativă de testare: confortul interfeței, funcțional, încărcare și integrare, 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 proiectele mici și mijlocii în care cerințele sunt clar definite și fixate.
În condițiile disponibilității inginerilor cu calificările necesare, în special testeri.

3. „Model incremental” (model incremental)

În modelul incremental, cerințele generale ale sistemului sunt împărțite în ansambluri diferite. Terminologia este adesea utilizată pentru a descrie ansamblul etapizat al 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 definiția cerințelor, proiectare, codificare, implementare și faze de testare. Procedura de dezvoltare bazată pe modelul incremental presupune lansarea în prima etapă majoră a produsului în funcționalitatea de bază, și apoi adăugarea secvențială a unor noi funcții, așa-numitele „incremente”. Procesul continuă până când se creează un sistem complet.

Sunt utilizate modele incrementale atunci când cererile individuale de modificare sunt clare și pot fi ușor formalizate și implementate. În proiectele noastre, l-am folosit pentru a crea cititorul DefView, apoi rețeaua Vivaldi de biblioteci electronice.

De exemplu, să descriem esența unui increment. a înlocuit DefView. DefView este conectat la un singur 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ă transmită conținutul său unui anumit public, care accesează direct documentele și le convertește în formatul dorit. A apărut elementul rădăcină al arhitecturii - serverul Vivaldi central, care acționează ca un singur motor de căutare pentru toate serverele de stocare instalate în diferite instituții.

Când se folosește un model incremental?

Atunci 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.
Este necesară lansarea timpurie pe piață.
Există mai multe caracteristici sau obiective riscante.

4. "Model RAD" (model de dezvoltare rapidă a aplicației 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, cum ar fi 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 clientului ceva care funcționează pentru a fi analizat pentru a obține feedback și a face modificări.

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

Modelarea afacerii: definirea unei liste de fluxuri de informații între diferite departamente.
Modelarea datelor: Informațiile colectate în pasul anterior sunt utilizate 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.
Construiț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 se folosește modelul RAD?

Poate fi utilizat numai cu arhitecți cu înaltă calificare și cu o înaltă specializare. Bugetul proiectului este mare pentru a plăti acești specialiști, împreună cu costul instrumentelor de asamblare automate gata făcute. Modelul RAD poate fi ales cu cunoștințe sigure despre afacerea țintă și necesitatea unei producții urgente a sistemului în termen de 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ă îl satisface sau nu. Acesta este unul dintre beneficiile unui model flexibil. Dezavantajele sale includ faptul că, din lipsa unor formulări specifice ale rezultatelor, este dificil de estimat costurile forței de muncă și costurile necesare dezvoltării. Programarea extremă (XP) este una dintre cele mai cunoscute utilizări practice ale modelului agil.

Acest tip se bazează pe întâlniri zilnice scurte numite „Scrum” și întâlniri 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ă a sarcinilor pe care angajatul trebuie să le îndeplinească înainte de următoarea întâlnire;
dificultăți întâmpinate în cursul muncii.

Metodologia este potrivită pentru proiecte pe termen lung sau pe termen lung, care se adaptează constant la condițiile pieței. În consecință, cerințele se schimbă în timpul procesului de implementare. Merită să ne amintim 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 executiv. 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 examinări medicale de masă în câteva minute. În al doilea paragraf al acestei revizuiri, partenerii noștri americani au descris un lucru foarte important, care este fundamental pentru succesul Agile.

Când se folosește Agile?

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

6. „Model iterativ” (model iterativ sau iterativ)

Un model de ciclu de viață iterativ nu necesită o specificație completă a cerințelor pentru a începe. În schimb, crearea începe cu implementarea unei piese de funcționalitate, care devine baza pentru definirea unor cerințe suplimentare. Acest proces se repetă. Este posibil ca versiunea să nu fie ideală, principalul lucru este că funcționează. Înțelegând obiectivul final, ne străduim să-l atingem, astfel încât fiecare pas să fie eficient și fiecare versiune să fie realizabilă.

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

Un exemplu de dezvoltare iterativă este recunoașterea vocii. Prima cercetare și pregătirea 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ă realizată, prin urmare, problema nu a fost încă rezolvată pe deplin.

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

Cerințele pentru sistemul final sunt clar definite și înțelese în prealabil.
Proiectul este mare sau foarte mare.
Principala provocare trebuie definită, dar detaliile implementării pot evolua în timp.

7. „Model în spirală”

Modelul spiralat este similar cu modelul incremental, dar cu accent pe analiza riscurilor. Funcționează bine pentru rezolvarea problemelor critice de afaceri, atunci când eșecul este incompatibil cu activitățile companiei, în condițiile noilor linii de produse, când sunt necesare cercetări și testări practice.

Modelul spiralat 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 proiectele mici, este rezonabil pentru proiectele complexe și costisitoare, de exemplu, cum ar fi dezvoltarea unui sistem de gestionare a documentelor pentru o bancă, când fiecare pas următor necesită mai multe analize pentru a evalua consecințele decât programarea. În ceea ce privește proiectul de dezvoltare a unui EDMS pentru ODU din Siberia, SO UES, două întâlniri privind schimbarea codificării secțiunilor unei arhive electronice necesită de 10 ori mai mult timp decât combinarea a două foldere de către un programator. Proiectele de stat la care am participat au început cu pregătirea unui concept scump de către comunitatea de experți, care nu este deloc întotdeauna inutilă, deoarece se plătește la scară națională.

Să rezumăm

Diapozitivul arată diferențele dintre cele două cele mai comune metodologii.

În practica modernă, modelele de dezvoltare software sunt multivariate. Nu există nimeni adevărat pentru toate proiectele, condițiile de pornire și modelele de plată. Nici Agile, atât de iubit de noi toți, nu poate fi aplicat peste tot din cauza indisponibilității unor clienți sau a imposibilității unei finanțări flexibile. Metodologiile se suprapun parțial în mijloace și sunt oarecum similare una cu cealaltă. Unele alte concepte au fost folosite doar pentru a-și promova propriile compilatoare și nu au adus nimic nou în practică.

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 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, sfera de lucru, obiectivele clienților și bugetul. În al doilea rând, nu uitați de specificul companiei IT. Asistența tehnică, externalizarea și dezvoltarea internă a proiectului dvs. necesită abordări diferite.

Unele dintre cele mai frecvente categorii de modele de dezvoltare software sunt Agile și Waterfall, flexibile și respectiv Waterfall. Vom face o scurtă descriere a fiecăruia, vom lua în considerare avantajele, dezavantajele și vom decide asupra sistemului corect pentru proiect.

Metodologiile agile aderă la principiile de proiectare iterative. 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 Time & Materials (T&M) atunci când plătesc dezvoltatorii. Am comparat deja unele dintre mecanismele de construire a relațiilor financiare cu un contractor. Descoperirile noastre din perspectiva clientului și dezvoltatorului pot fi găsite.

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

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

Clasa Agile include tehnici precum programarea extremă (XP), FDD, DSDM, Scrum și altele.

Cascadă

Principiul unui sistem în cascadă este consistența. Procesul de dezvoltare este împărțit în următorii pași:

1. Analiza cerințelor

2. Planificare

3. Implementare

4. Integrare

5. Testarea

7. Suport

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

Acum, să comparăm punctele tari și punctele slabe ale Agile și Cascade.

Avantaje ale metodologiilor:

Model flexibil

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

Model în cascadă

O structură de proces clară și simplă potrivită pentru echipele cu puțină experiență.
Documentație de înaltă calitate și detaliată.
Într-un proiect, puteți 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 experimentată, orientată spre client.
Noile cerințe pot intra în conflict cu arhitectura sau funcționalitatea existentă.
Cu toate ajustările și modifică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 dificil să schimbi ceva.
Lipsa feedback-ului între etapele de dezvoltare.

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

Modelul de dezvoltare agil este valabil dacă:

1. O echipă experimentată 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ă dezvoltați rapid software-ul 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 petrecute;

3. Proiectul este dezvoltat prin externalizare;

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

Trebuie spus că ambele modele vă vor ajuta să vă implementați proiectul. În primul rând, alegeți opțiunea care vă permite să realizați produse de calitate și să vă gestionați bugetul eficient.

Desigur, odată ce vă aflați în acasă, nimeni nu va fi interesat de metodologia aleasă. Prin urmare, chiar dacă modelul de dezvoltare nu este potrivit, 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: