Ciclul de viață al software-ului

Ciclul de viață al software-ului , în informatică și în special în ingineria software , se referă la modul în care o metodologie de dezvoltare descompune activitatea de creare a produselor software în subtaskuri coordonate, al căror rezultat final este realizarea produsului în sine și toată documentația asociată: fazele tipice includ studiul sau analiza, proiectarea , construcția , testarea , dezvoltarea, instalarea , întreținerea și extinderea, ^[1] toate de către unul sau mai mulți dezvoltatori de software .

Dezvoltarea software-ului este un lucru foarte complex și vast în toate fazele sale, astfel încât uneori este nevoie ca mulți dezvoltatori de software să fie finalizați într-un timp rezonabil sau fix; uneori, un proiect software este realizat de o comunitate de utilizatori distribuiți într-o rețea activă printr-un grup de discuții , așa cum se întâmplă de exemplu pentru diferite distribuții Linux ; atunci când un proiect software dezvoltă altul pornind de la același tip de program, dar realizat de o altă comunitate, vorbim despre un fork .

Istorie

Apariția în literatură și în practica dezvoltării software a conceptului de „ciclu de viață” poate fi făcută să coincidă cu nașterea ingineriei software , deoarece reprezintă un pasaj istoric de la dezvoltarea de software înțeles ca o activitate „meșteșugărească” (adică încredințată creativității libere a indivizilor) unei abordări mai industriale , în care crearea de programe și sisteme software este considerată ca un proces complex care necesită planificare, control și documentare adecvate (așa cum se întâmplă în mod tradițional în sectoarele mai mature ale ingineriei ) .

În cele din urmă, această tranziție poate fi urmărită până la complexitatea crescută a sistemelor, apariția unei piețe software reale, precum și cerințe de calitate noi și mai stricte, legate de exemplu de utilizarea sistemelor IT în contexte critice (centrale electrice, sisteme aerospațiale, armament etc.). Această schimbare de perspectivă a început să aibă loc, istoric, între sfârșitul anilor 1960 și începutul deceniului următor . De atunci, cercetarea asupra acestor probleme a fost extrem de prolifică atât în industrie, cât și în mediul academic. De multe ori complexitatea unui proiect software necesită supravegherea sau gestionarea de către unul sau mai mulți manageri de proiect de către back office-ul companiei.

Descriere

Aproape toate modelele ciclului de viață ale software-ului implică descompunerea procesului de dezvoltare în seturi similare (dacă nu identice) de activități. Distincțiile dintre diferite cicluri de viață sunt evidențiate pe alte aspecte, cum ar fi:

accentul relativ acordat fiecărei activități;
identificarea actorilor specifici responsabili de fiecare activitate;
ordinea în care se desfășoară activitățile.

Documentarea produselor diferitelor sub-sarcini joacă, de asemenea, un rol esențial în toate ciclurile de viață ale software-ului; redactarea documentației este, prin urmare, reglementată în același mod cu activitățile menționate. Fazele de proiectare a software-ului sunt:

Analize

Analiza este investigarea preliminară a contextului în care trebuie să se încadreze produsul software, asupra caracteristicilor sau cerințelor pe care trebuie să le prezinte și, eventual, asupra costurilor și aspectelor logistice ale realizării acestuia; această fază poate fi împărțită în sub-activități precum analiza de fezabilitate , analiza și modelarea domeniului aplicației , analiza cerințelor și așa mai departe. Într-un sens mai larg se poate spune că analiza își propune să definească (cât mai exact posibil) problema de rezolvat. Această fază constă, de asemenea, în colectarea datelor prin interviuri între client / client și dezvoltatori conexi. La sfârșitul fazei, va fi creat un document care descrie caracteristicile sistemului, acest document este denumit document de specificații funcționale .

Proiecta

Același subiect în detaliu: model de proiectare .

În activitatea de proiectare , liniile esențiale ale structurii produsului software sunt definite în funcție de cerințele evidențiate de analiză, de obicei apanajul unui analist programator . Chiar și designul poate fi împărțit în subtaskuri, de la designul arhitectural la designul detaliat . Se poate spune că proiectarea are scopul de a defini (la un anumit nivel de detaliu) soluția problemei. În această fază va fi elaborat un document care va permite să existe o definiție a structurii generale (arhitectură de nivel înalt) și o definiție a caracteristicilor componentelor individuale ( module ).

Implementare

Același subiect în detaliu: cadru și cod sursă .

Implementarea , numită și dezvoltare sau codificare a produsului software, este faza de realizare a software-ului, care concretizează soluția software prin programare sau scrierea de programe de către programatori sau dezvoltatori.

Organizare

Același subiect în detaliu: Modul (programare) .

În majoritatea cazurilor, programatorii care se ocupă de implementare disting cel puțin două activități legate de implementare: implementarea modulelor individuale care alcătuiesc sistemul și integrarea acestor module pentru a forma sistemul general. De exemplu, o aplicație desktop ar putea fi împărțită în trei componente de bază: interfața cu utilizatorul (GUI), logica de procesare și gestionarea datelor. În mod obișnuit, dezvoltarea codului unei aplicații are loc local pe PC-ul dezvoltatorului, care va putea efectua o primă fază de testare, verificând bunătatea sau nu rezultatul programului realizat.

Produsul final al acestei faze este denumit de obicei versiunea alfa a software-ului, în timp ce următoarea versiune beta este cea care include corecțiile și îmbunătățirile sugerate de feedback-ul de la testeri (sau testeri ) în faza următoare numită, de fapt, testare, până la distribuirea celei mai recente versiuni care îndeplinește specificațiile funcționale solicitate.

Tehnologie

Același subiect în detaliu: mediu de dezvoltare integrat și control versiune .

Faza de implementare implică adesea numeroase tehnologii legate nu numai de produs, ci și de procesul care îl creează. În ceea ce privește produsul, scrierea programelor necesită cel puțin un limbaj de programare , unele dintre bibliotecile sale, dar implică adesea alte limbaje, de exemplu scripturi și alte tehnologii, cum ar fi bazele de date sau internetul în sine.

Procesul de implementare, pe de altă parte, nu poate ignora un editor pentru scrierea codului sursă și un compilator sau un interpret pentru a testa execuția codului; nu de puține ori sunt utilizate instrumente automate de construcție sau depanare . Scrierea documentației produsului, pe de altă parte, poate fi generată automat pornind de la comentariile scrise în codul sursă prin instrumente adecvate, grație unor instrumente precum Doxygen sau Javadoc . Dacă implementarea este realizată de o echipă de dezvoltatori, coordonarea acestora este de obicei asistată de sisteme de control al reviziei (de exemplu, Subversion sau GIT ), care identifică fiecare versiune intermediară a produsului.

Uneori, unele sau multe dintre tehnologiile necesare producției sunt disponibile într-un mediu de dezvoltare integrat , o aplicație care unifică instrumentele necesare programatorului, sau în seturi de dezvoltare (SDK-uri), o distribuție a documentației și implementarea unui program de limbaj sau platformă.

Testarea

Același subiect în detaliu: Testarea software-ului .

Testarea sau testarea , apanajul unuia sau mai multor testere , constă în verificarea și validarea cât (măsurabilitate) produsul software implementat îndeplinește cerințele identificate de analiză. Infrastructura de suport utilizată în această fază se numește mediu de testare ; cu alte cuvinte, testarea evaluează corectitudinea în ceea ce privește specificațiile . De asemenea, pentru testare, pot fi identificate cele două sarcini secundare de testare a modulelor individuale și testarea sistemului integrat ; în plus, pot fi identificate subtaskuri suplimentare pentru fiecare aspect al produsului software care urmează să fie testat: testarea funcțională , testarea performanței , testarea spargerii , testarea regresiei , testarea siguranței , testarea accesibilității , testarea acceptării etc. . În cazul nerespectării specificațiilor, software-ul, împreună cu documentul anomaliilor sau erorilor, revine la dezvoltatori cu sarcina de a rezolva problemele găsite prin depanarea software-ului. În general, anomaliile de operare sunt gestionate prin intermediul unui software special de raportare a anomaliilor , numit și sisteme de biletare sau de urmărire a erorilor , care înregistrează problemele raportate echipei de dezvoltare și facilitează organizarea, clasificarea și gestionarea acestora (de exemplu, Bugzilla , Mantis , Atlassian Jira etc.) .

Eliberare și punere în funcțiune

Același subiect în detaliu: implementare .

Odată ce software-ul a trecut cu succes testele fazei de testare, acesta este publicat într-o versiune definitivă și pus la dispoziție, conform regulilor licenței de utilizare specifice alese, oricui sau numai cumpărătorilor. Faza de instalare și punere în funcțiune a software-ului produs pe platformele de operare se numește implementare .

Uneori, software-ul este pus în funcțiune , adică instalarea și configurarea produsului software în infrastructura de execuție care poate fi utilizată de utilizatori, numită mediul de operare sau de producție sau de operare. În funcție de complexitatea acestei infrastructuri, implementarea poate fi împărțită în diferite subactivități; de fapt, poate varia de la simpla copie a unui fișier, la „copia adecvată” a multor fișiere organizate într-o ierarhie complexă de directoare și componente software, distribuite eventual pe diferite hardware .

întreținere

Întreținerea include acele subtaskuri necesare pentru modificările produsului software după distribuție, pentru a corecta alte erori prin patch-uri ( întreținere corectivă ), pentru a-l adapta la noile medii de operare ( întreținere adaptivă sau migrarea mediului), pentru a extinde funcționalitatea acestuia ( întreținere evolutivă ) sau pentru a converti implementarea sa într-o altă structură (de exemplu , migrarea cadrului sau platformei ). Întreținerea afectează costurile pentru o estimare care este de aproximativ 60% din costurile totale. Orice modificare a software-ului implică în mod necesar necesitatea unor noi teste, atât legate de orice caracteristici noi introduse, cât și destinate verificării faptului că modificările efectuate nu au compromis caracteristicile preexistente ( testarea de regresie ).

Documentație

În paralel cu fazele de dezvoltare menționate mai sus, este o practică obișnuită și bună pentru echipa de proiectare, dezvoltare și testare să pregătească documentația software corespunzătoare care va fi însoțită de software în faza finală sau în timpul fazelor individuale pentru a sprijini următoarea fază. .

Inspecția software-ului

Același subiect în detaliu: inspecția software-ului .

Fiecare fază de dezvoltare software descrisă poate intra în așa-numita inspecție software .

Etapele dezvoltării

Pre-alfa

Versiunea pre-alfa se referă la toate activitățile desfășurate în timpul proiectului software înainte de testele oficiale. Aceste activități pot include analiza cerințelor, proiectarea software-ului, dezvoltarea software-ului și testarea unităților. În dezvoltarea tipică open source, există mai multe tipuri de versiuni pre-alfa.

Alfa

Același subiect în detaliu: versiunea Alpha .

Versiunea alfa identifică software-ul în curs de dezvoltare, ale cărui caracteristici nu au fost încă implementate complet și care are cu siguranță o serie lungă de bug-uri care vor trebui remediate.

De obicei, în timpul dezvoltării unui software, mai multe versiuni alfa sunt făcute publice, în unele cazuri (în special în cazul software-ului open-source), pentru a introduce noi caracteristici ale software-ului, care este necesar pentru a verifica funcționarea cu atenție. Prin urmare, versiunile alfa trebuie considerate incomplete și lipsite de unele caracteristici și, adesea, instabile și, prin urmare, nu sunt potrivite pentru utilizatorul final.

Beta

Același subiect în detaliu: versiunea beta .

Versiunea beta este software-ul care nu este definitiv, dar deja testat de experți și pus la dispoziția unui număr mai mare de utilizatori (de obicei utilizatori finali), având încredere exact în acțiunile lor imprevizibile care ar putea scoate la lumină noi erori sau incompatibilități ale software-ului în sine .

Publicare

Odată publicat, software-ul este în general cunoscut sub numele de „versiune stabilă”. Termenul formal depinde adesea de metodă: suport fizic, versiune online sau o aplicație web.

Lansare în fabricație (RTM)

Același subiect în detaliu: Lansarea în fabricație .

Termenul de lansare în producție ( RTM ), (GA) este utilizat atunci când produsul este distribuit publicului.

Este de obicei utilizat în anumite contexte pentru producția de masă cu amănuntul - spre deosebire de o producție sau proiectare specializată de software într-o producție sau distribuție comercială sau guvernamentală - în care software-ul este vândut ca parte a unui pachet într-o vânzare de hardware și de obicei software-ul și hardware-ul aferent va fi în cele din urmă disponibil și vândut publicului larg la punctele de vânzare cu amănuntul pentru a indica faptul că software-ul a atins un nivel de calitate definit și că este pregătit pentru distribuția cu amănuntul în masă. RTM ar putea însemna, de asemenea, în alte contexte, că software-ul a fost livrat unui client pentru instalare sau distribuire către computerele sau computerele utilizatorilor finali. Termenul nu definește mecanismul de livrare sau volumul; doar afirmă că calitatea este suficientă pentru distribuția în masă.

Disponibilitate generală (GA)

Ciclul de viață al produsului: disponibilitate generală (GA), anunț de sfârșit de viață (EOLA), data ultimei comenzi (LOD) și sfârșit de viață (EOL)

Disponibilitatea generală sau disponibilitatea generală (GA) este faza de marketing în care au fost finalizate toate activitățile de marketing necesare și un produs software este disponibil pentru cumpărare, în funcție de limba regiunii, de disponibilitatea electronică decât media. ^[2] Activitățile de comercializare ar putea include teste de securitate și conformitate, precum și localizare și disponibilitate la nivel mondial. Timpul dintre RTM și GA poate merge de la o săptămână la luni, în unele cazuri, înainte ca o versiune disponibilă în general să poată fi declarată din cauza timpului necesar pentru finalizarea tuturor activităților de marketing solicitate de GA.

Lansare pe web (RTW)

Lansarea pe web ( RTW ) este un mijloc de livrare de software care utilizează internetul pentru distribuție. Producătorul nu produce materiale fizice în acest tip de mecanism de distribuție. Versiunile web devin din ce în ce mai frecvente pe măsură ce crește utilizarea internetului.

Procese de dezvoltare software

Majoritatea metodologiilor de dezvoltare software constau, cel puțin în principiu, dintr-un limbaj de modelare și un proces.

Limbajul de modelare este notația utilizată de metodologii pentru a exprima caracteristicile de proiectare ;
procesul este lista cu indicații referitoare la pașii care trebuie parcurși pentru realizarea proiectului în sine.

UML ( Unified Modeling Language ), de exemplu, este un limbaj de modelare, utilizat de procese pentru a crea, organiza, documenta produsele create de fazele care alcătuiesc procesul. Cei care, individual sau în grup, lucrează la dezvoltarea sau modificarea unui software, adoptă în mod necesar o anumită abordare în modul de relaționare cu clienții / utilizatorii lor, în organizarea muncii lor, în alegerea tehnicilor care trebuie utilizate, adoptă un proces.

Indiferent dacă este conștient sau nu, fiecare dezvoltator de software (sau grup de dezvoltatori) are propriul său proces de dezvoltare, adică propriul său mod de lucru, bazat pe propria experiență, pe propria cultură și pe contextul cultural și organizațional în care operează.

Istoria succeselor (și mai ales a eșecurilor) proiectelor de dezvoltare software a învățat că fiecare proces de dezvoltare are propriile sale puncte forte și limitări și că un proces de dezvoltare care nu este adecvat nevoilor concrete ale proiectului specific poate duce la eșec a proiectului în sine. sau, în orice caz, nemulțumirea clienților / utilizatorilor și a dezvoltatorilor înșiși.

Ciclul de dezvoltare software, în majoritatea cazurilor, este iterativ și fiecare iterație își produce propria versiune . Enumerăm mai jos fazele principale care pot face parte din fiecare iterație:

Specificarea cerințelor : ceea ce este solicitat de client ;
Studiu de fezabilitate ( producere sau cumpărare );
Analiză și proiectare unde prin analiză se înțelege studiul a ceea ce trebuie să facă sistemul (punct de vedere „logic”) și prin proiectare studiul modului în care sistemul trebuie implementat (punct de vedere „tehnic”). În ultimii ani, distincția tradițională între analiză și design a intrat în criză.
Implementare ;
Integrare și testare .

În timp ce modelele ciclului de viață al software-ului erau inițial doar instrumente conceptuale, mediile moderne de dezvoltare inginerie software asistată de computer ( CASE) automatizează adesea aplicarea unui anumit ciclu de viață, precum și alte aspecte ale dezvoltării software-ului.

Câteva exemple de metodologie de dezvoltare software

Același subiect în detaliu: metodologia de dezvoltare software .

Model în cascadă

Același subiect în detaliu: Modelul cascadei .

Din punct de vedere istoric, modelul cascadei a fost primul model al ciclului de viață al software-ului. Aceasta implică executarea secvențială a fazelor de analiză , proiectare , dezvoltare , testare și întreținere .

Modele iterative

Categoria modelelor iterative include toate procesele de dezvoltare care vă permit să reveniți la o fază a procedurii deja tratate anterior. Pentru fiecare fază „iterabilă” tindem să începem cu o schiță a soluției care va fi ulterior rafinată în etapa următoare.

Modelele incrementale și evolutive sunt o specificație a modelelor iterative.

Modele incrementale

Același subiect în detaliu: Modelul incremental .

Modele evolutive

Același subiect în detaliu: Model evolutiv .

Conform celei mai comune viziuni în ingineria software modernă, modelul cascadă nu mai este potrivit pentru aplicație, cel puțin pentru majoritatea aplicațiilor. Printre elementele care au contribuit la declinul acestui model se numără creșterea complexității aplicațiilor, introducerea interfețelor grafice (care au adus anterior atenția designerilor probleme minore de utilizare ) și apariția noilor paradigme de programare și analiză și proiectare. metodologii, în special cele legate de paradigma orientată pe obiect .

În special, s-au stabilit o vastă clasă de așa-numitele modele evolutive, toate bazate pe ideea centrală de a implica mai mult clientul (sau utilizatorul), trimitându-i periodic versiuni parțiale sau prototipuri ale produsului final. O tehnică tradițională în acest sens este, de exemplu, cea a prototipării rapide . În această linie de gândire, una dintre ultimele generații este cea a așa-numitelor metodologii agile .

Notă

^ (EN) ND Birrell și Martyn A. Ould, A Practical Handbook for Software Development, Cambridge University Press, 1988, ISBN 978-0-521-34792-1 .
^ Yvan Philippe Luxembourg, Top 200 SAM Terms - A Glossary Of Software Asset Management Terms , OMTCO, 20 mai 2013. Accesat 21 mai 2013 ( arhivat 10 august 2013) .

Elemente conexe

Alte proiecte

Portal IT

Portal de inginerie

[BMO1998-1] (EN) ND Birrell și Martyn A. Ould, A Practical Handbook for Software Development, Cambridge University Press, 1988, ISBN 978-0-521-34792-1 .

[2] Yvan Philippe Luxembourg, Top 200 SAM Terms - A Glossary Of Software Asset Management Terms , OMTCO, 20 mai 2013. Accesat 21 mai 2013 ( arhivat 10 august 2013) .

[1]

[2]