Conceptul de ciclu de viață al software-ului. Ciclul de viață al sistemelor software

Adnotare.

Introducere.

1. Ciclul de viață al software-ului

Introducere.

Etapele procesului de programare Riley

Introducere.

1.1.1. Formularea problemei.

1.1.2. Proiectarea soluției.

1.1.3. Codarea algoritmului.

1.1.4. Suport program.

1.1.5. Documentația software.

Concluzie la clauza 1.1

1.2. Determinarea LCPO conform Lehman.

Introducere.

1.2.1 Definirea sistemului.

1.2.2. Implementarea.

1.2.3. Serviciu.

Concluzie la clauza 1.2.

1.3. Fazele și lucrul LCPO conform lui Boehm

1.3.1. Model în cascadă.

1.3.2. Justificare economică pentru modelul în cascadă.

1.3.3. Îmbunătățirea modelului în cascadă.

1.3.4. Determinarea fazelor ciclului de viață.

1.3.5. Lucrarea principală a proiectului.

Literatură.

Introducere

Utilizarea industrială a computerelor și cererea în creștere pentru programe au pus provocări urgente pentru a crește semnificativ productivitatea dezvoltării software, dezvoltarea metodelor industriale de planificare și proiectare a programelor, transferul tehnicilor, modelelor și metodelor organizatorice, tehnice, tehnice, economice și socio-psihologice din sfera producției materiale în sfera utilizării computerului. O abordare complexă proceselor de dezvoltare, operare și întreținere a software-ului, el a prezentat o serie de probleme presante, a căror soluție va elimina blocajele în proiectarea programelor, va reduce timpul de finalizare a lucrărilor, va îmbunătăți selecția și adaptarea programelor existente și poate determina soarta sistemelor cu calculatoare încorporate.

În practica dezvoltării de proiecte software mari, adesea nu există abordare unificată la evaluarea costurilor cu forța de muncă, a termenelor de lucru și a costurilor materiale, ceea ce împiedică creșterea productivității dezvoltării software și, în cele din urmă, gestionarea eficientă a ciclului de viață al software-ului. Deoarece un program de orice tip devine un produs (cu excepția, poate, a programelor educaționale, prototip), abordarea producției sale ar trebui să fie în multe privințe similară cu abordarea producției de produse industriale, iar problemele de proiectare a programelor devin extrem de importante. Această idee se află în centrul cărții lui B.W. Boehm „Inginerie software”, pe care l-am folosit când am scris acest lucru de curs. În această carte, proiectarea software se referă la procesul de creare a unui design pentru un produs software.

1 Ciclul de viață al software-ului

INTRODUCERE

LCPO este un proces continuu care începe din momentul în care se ia o decizie cu privire la necesitatea de a crea software și se termină în momentul în care acesta este complet scos din serviciu.

Există mai multe abordări pentru a determina fazele și activitățile ciclului de viață al software-ului (SLC), etapele procesului de programare, modelele în cascadă și spirală. Dar toate conțin componente fundamentale comune: enunțarea problemei, proiectarea soluției, implementarea, întreținerea.

Cel mai faimos și complet, poate, este structura procesului ciclului de viață conform lui Boehm, care include opt faze. Va fi prezentat mai detaliat în viitor.

Una dintre opțiunile posibile ar putea fi o descriere de nivel superior conform lui Lehman, care include trei faze principale și reprezintă o descriere a ciclului de viață în cel mai general caz.

Și, pentru varietate, vă prezentăm etapele procesului de programare prezentate de D. Riley în cartea „Using the Modula-2 Language”. Această idee, în opinia mea, este foarte simplă și familiară și să începem cu ea.

1.1 Etapele procesului de programare Riley

Introducere

Procesul de programare presupune patru pași (Figura 1):

enunţarea problemei, de ex. obținerea unei înțelegeri adecvate a sarcinii pe care trebuie să o îndeplinească programul;

proiectarea unei soluții la o problemă deja enunțată (în general, o astfel de soluție este mai puțin formală decât programul final);

codificarea programului, adică traducerea soluției proiectate într-un program care poate fi executat pe o mașină;

suport de program, de ex. procesul continuu de depanare a programului și adăugarea de noi funcții.

Orez. 1.Patru pași de programare.

Programarea începe din momentul în care utilizator, adică cineva care are nevoie de un program pentru a rezolva o problemă afirmă problema analist de sistem. Utilizatorul și analistul de sistem definesc împreună declarația problemei. Acesta din urmă este apoi transmis algoritmist, care este responsabil pentru proiectarea soluției. O soluție (sau algoritm) reprezintă o succesiune de operații, a căror execuție duce la rezolvarea unei probleme. Deoarece algoritmul nu este adesea potrivit pentru execuție pe o mașină, ar trebui tradus într-un program de mașină. Această operație este efectuată de codificator. Menținătorul este responsabil pentru modificările ulterioare ale programului. programator. Și analistul de sistem, și algoritmistul, și codificatorul și programatorul care îl însoțește - toți sunt programatori.

În cazul unui proiect software mare, numărul de utilizatori, analiști de sistem și algoritmi poate fi semnificativ. În plus, poate fi necesară revenirea la pașii anteriori din cauza unor circumstanțe neprevăzute. Toate acestea servesc ca un argument suplimentar în favoarea unui proiect software atent: rezultatele fiecărui pas ar trebui să fie complete, precise și de înțeles.

1.1.1 Declarația problemei

Unul dintre cei mai importanți pași în programare este definirea problemei. Funcționează ca un contract între utilizator și programator(i). La fel ca un contract prost redactat din punct de vedere legal, o declarație de problemă scrisă prost este inutilă. Cu o declarație bună a problemei, atât utilizatorul, cât și programatorul reprezintă în mod clar și fără ambiguitate sarcina care trebuie efectuată, de exemplu. în acest caz, sunt luate în considerare atât interesele utilizatorului, cât și ale programatorului. Utilizatorul poate planifica să folosească software care nu a fost încă creat, pe baza cunoștințelor despre ceea ce poate face. O enunțare bună a problemei servește drept bază pentru formularea soluției acesteia.

Formularea problemei (specificarea programului); în esență înseamnă o descriere precisă, completă și de înțeles a ceea ce se întâmplă atunci când este executat un anumit program. Utilizatorul privește de obicei computerul ca pe o cutie neagră: pentru el, nu contează cum funcționează computerul, dar important este ce poate face computerul care îl interesează pe utilizator. În acest caz, atenția principală este concentrată pe interacțiunea omului cu mașina.

Caracteristicile unei declarații bune de problemă:

Precizie, adică eliminând orice ambiguitate. Nu ar trebui să existe nicio întrebare cu privire la ceea ce va fi rezultatul programului pentru orice intrare dată.

Completitudine, adică luarea în considerare a tuturor opțiunilor pentru o intrare dată, inclusiv intrarea eronată sau neintenționată și determinarea ieșirii corespunzătoare.

Claritate, adică trebuie să fie de înțeles atât pentru utilizator, cât și pentru analistul de sistem, deoarece enunțul problemei este singurul contract între ei.

Adesea, cerințele pentru acuratețe, completitudine și claritate sunt în conflict. Astfel, multe acte juridice sunt greu de înțeles deoarece sunt scrise într-un limbaj formal, ceea ce permite formularea unor prevederi cu o precizie extremă, excluzând orice discrepanțe minore. De exemplu, unele întrebări din lucrările de examen sunt uneori formulate atât de precis încât studentul petrece mai mult timp înțelegând întrebarea decât răspunzând la ea. Mai mult, studentul poate să nu înțeleagă sensul principal al întrebării din cauza numărului mare de detalii. Cea mai bună formulare a problemei este cea care realizează un echilibru între toate cele trei cerințe.

Forma standard de enunțare a problemei.

Luați în considerare următoarea afirmație a problemei: „Introduceți trei numere și scoateți numerele în ordine.”

O astfel de afirmație nu îndeplinește cerințele de mai sus: nu este nici exactă, nici completă, nici de înțeles. Într-adevăr, numerele trebuie introduse câte unul pe linie sau toate numerele pe o singură linie? Expresia „în ordine” înseamnă ordonarea de la cel mai mare la cel mai mic, de la cel mai mic la cel mai mare, sau aceeași ordine în care au fost introduse.

Evident, o astfel de afirmație nu răspunde la multe întrebări. Dacă luăm în considerare răspunsurile la toate întrebările, atunci enunțul problemei va deveni pronunțat și greu de înțeles. Prin urmare, D. Riley sugerează utilizarea unui formular standard pentru a seta problema, care asigură acuratețe maximă, completitudine, claritate și include:

numele sarcinii (definiție schematică);

descriere generală (scurt rezumat al sarcinii);

erori (opțiunile de intrare neobișnuite sunt enumerate în mod explicit pentru a arăta utilizatorilor și programatorilor ce acțiuni ar întreprinde mașina în astfel de situații);

exemplu (un exemplu bun poate transmite esența problemei și, de asemenea, poate ilustra diferite cazuri).

Exemplu. Enunțarea problemei într-o formă standard.

NUME

Sortarea a trei numere întregi.

DESCRIERE

Intrarea și ieșirea a trei numere întregi, sortate de la cel mai mic la cel mai mare număr.

Se introduc trei numere întregi, câte un număr pe linie. Un număr întreg este una sau mai multe cifre zecimale consecutive, care pot fi precedate de un semn plus „+” sau de un semn minus „–”.

Cele trei numere întregi introduse sunt tipărite, toate trei fiind tipărite pe aceeași linie. Numerele adiacente sunt separate printr-un spațiu. Numerele sunt afișate de la cel mai mic la cel mai mare, de la stânga la dreapta.

1) Dacă sunt introduse mai puțin de trei numere, programul așteaptă introducerea suplimentară.

2) Liniile de intrare altele decât primele trei sunt ignorate.

Ciclu de viață este un model pentru crearea și utilizarea unui sistem software. Ea reflectă diferitele stări ale unui sistem software, începând din momentul în care apare necesitatea acestui sistem software și se ia decizia de a-l crea și terminând cu retragerea completă a sistemului software din funcțiune.

Standardul internațional ISOIES 12207 definește un cadru de ciclu de viață care conține procesele, activitățile și sarcinile care trebuie efectuate în timpul creării software-ului. Conform acestui standard, ciclul de viață al software-ului se bazează pe trei grupuri de procese:

principalele procese ale ciclului de viață, adică achiziția, livrarea, dezvoltarea, operarea și întreținerea;

procese auxiliare care asigură implementarea proceselor principale, adică documentarea, verificarea, certificarea, evaluarea calității și altele;

procesele organizaționale, adică managementul proiectelor, crearea infrastructurii de proiect și formarea.

Dezvoltarea include toate lucrările pentru a crea software în conformitate cu cerințele specificate. Aceasta include pregătirea documentației de proiectare și operaționale, pregătirea materialelor necesare pentru a testa funcționalitatea și calitatea produselor software.

Etapele principale ale procesului de dezvoltare:

analiza cerințelor clienților;

proiecta;

implementare (programare).

Procesul de operare include lucrări de punere în funcțiune a software-ului, inclusiv configurarea stațiilor de lucru, instruirea personalului, localizarea problemelor operaționale și eliminarea cauzelor apariției acestora, modificarea software-ului în cadrul reglementărilor stabilite și pregătirea propunerilor de modernizare a sistemului.

Fiecare proces este caracterizat de anumite sarcini și metode de rezolvare a acestora, precum și de date și rezultate inițiale.

Ciclul de viață al software-ului este, de regulă, de natură iterativă, adică sunt implementate etapele, începând de la cele mai timpurii, care se repetă ciclic în conformitate cu cerințele în schimbare ale condițiilor externe și introducerea de restricții.

Modele ciclului de viață al software-ului

Există mai multe modele de ciclu de viață care determină ordinea de execuție a etapelor de dezvoltare și criteriile de trecere de la o etapă la alta. Până în prezent, două modele de ciclu de viață au devenit cele mai răspândite: cascadăȘi spirală.

În sistemele informaționale omogene existente anterior, fiecare aplicație era un singur întreg. Pentru a dezvolta astfel de aplicații a fost folosit un model de ciclu de viață în cascadă, numit și clasic sau cascadă.

Când se folosește modelul cascadă, dezvoltarea a fost privită ca o secvență de etape, tranziția la următoarea etapă inferioară având loc numai după ce toate lucrările din etapa actuală au fost complet finalizate. Implicația este că în modelul în cascadă, dezvoltarea începe la nivel de sistem și continuă prin analiză, proiectare, codificare, testare și întreținere.

Figura 1 – Principalele etape ale dezvoltării unui model în cascadă

1. Analiza sistemului specifică rolul fiecărui element într-un sistem informatic și interacțiunea elementelor între ele. Deoarece software-ul este considerat parte a unui sistem mai mare, analiza începe cu determinarea cerințelor pentru toate elementele sistemului. Necesitatea analizei sistemului se manifestă clar atunci când se formează interfața software-ului cu alte elemente, adică. cu hardware sau baze de date. În aceeași etapă, începe soluționarea problemelor de planificare a proiectelor. În timpul planificării proiectului, se determină volumul lucrărilor proiectului și riscul acestuia, costurile cu forța de muncă necesare, se formează sarcinile de lucru și se formează un program de lucru.

Analiza cerințelor se referă la un singur element software. În această etapă, funcțiile fiecărui element, caracteristicile și interfața acestuia sunt clarificate și detaliate. În aceeași etapă, soluția problemei de planificare a proiectului este finalizată.

2. Designul constă în crearea:

arhitecturi software;

structură software modulară;

structura algoritmică a software-ului;

structuri de date;

interfață de intrare/ieșire (formulare de date de intrare/ieșire).

La rezolvarea problemelor de proiectare, atenția principală este acordată calității viitorului produs software.

3. Codarea sau dezvoltarea constă în traducerea rezultatelor de proiectare în cod de program.

4. Testarea este executarea unui program pentru identificarea defectelor în funcțiile, logica și forma de implementare a unui produs software.

5. Întreținerea face modificări la software-ul de operare pentru a:

corectarea erorilor;

adaptarea la schimbările din mediul extern software-ului;

îmbunătățirea software-ului în conformitate cu cerințele clienților.

Avantajele utilizării modelului în cascadă:

oferă un plan și un orar de timp pentru toate etapele proiectului, eficientizând astfel progresul dezvoltării;

la fiecare etapă, se generează un set complet de documentație de proiectare, verificată pentru completitudine și coerență;

etapele de lucru efectuate într-o succesiune logică fac posibilă planificarea calendarului de finalizare a tuturor lucrărilor și a costurilor corespunzătoare.

Modelul în cascadă s-a dovedit bine în construcția sistemelor informaționale, pentru care chiar la începutul dezvoltării este posibil să se formuleze destul de precis toate cerințele din sistem, de exemplu, sisteme complexe de calcul, diverse sisteme în timp real etc. .

Dezavantajele modelului în cascadă:

proiectele reale necesită adesea abateri de la succesiunea standard de pași;

modelul în cascadă se bazează pe formularea precisă a cerințelor software inițiale, dar în realitate, într-un număr de cazuri, la începutul proiectului, cerințele clientului sunt doar parțial determinate;

rezultatele proiectului sunt disponibile clientului numai după finalizarea tuturor lucrărilor.

Datorită necesității în procesul de creare a software-ului de a reveni constant la etapele anterioare și de a clarifica sau revizui deciziile luate anterior, procesul real de dezvoltare a software-ului bazat pe modelul cascadă poate fi reprezentat prin următoarea diagramă (Fig. 2).

Figura 2 – Procesul de dezvoltare software bazat pe modelul cascadă

Standardele ciclului de viață al software-ului

GOST 34.601-90
ISO/IEC 12207:1995 (echivalent rusesc - GOST R ISO/IEC 12207-99)

Metodologii de dezvoltare software

Procesul rațional unificat (RUP).
Microsoft Solutions Framework (MSF). Include 4 faze: analiză, proiectare, dezvoltare, stabilizare, implică utilizarea modelării orientate pe obiecte.
Programare extremă ( Programare extremă, XP). Metodologia se bazează pe munca în echipă și comunicarea eficientă între client și contractor pe parcursul întregului proiect de dezvoltare IP. Dezvoltarea se realizează folosind prototipuri rafinate succesiv.

Standard GOST 34.601-90

Standardul GOST 34.601-90 prevede următoarele etape și etape ale creării unui sistem automat:

Formarea cerințelor pentru vorbitori
1. Inspecția instalației și justificarea necesității creării unei centrale nucleare
2. Formarea cerințelor utilizatorilor pentru difuzoare
3. Întocmirea unui raport privind finalizarea lucrărilor și a unei cereri pentru dezvoltarea unei CNE
Dezvoltarea conceptului AC
1. Studierea obiectului
2. Efectuarea lucrărilor de cercetare necesare
3. Dezvoltarea opțiunilor de concept AC și selectarea unei opțiuni de concept AC care satisface cerințele utilizatorului
4. Întocmirea unui raport cu privire la munca depusă
Sarcina tehnică
1. Elaborarea și aprobarea specificațiilor tehnice pentru realizarea centralelor nucleare
Proiectare preliminară
1. Dezvoltarea de soluții preliminare de proiectare pentru sistem și părțile sale
Proiect tehnic
1. Dezvoltarea de soluții de proiectare pentru sistem și piesele sale
2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
3. Elaborarea si executarea documentatiei pentru furnizarea componentelor
4. Dezvoltarea sarcinilor de proiectare în părțile adiacente ale proiectului
Documentatie de lucru
1. Elaborarea documentației de lucru pentru CNE și părțile sale
2. Dezvoltarea și adaptarea programelor
Punere in functiune
1. Pregătirea unui obiect de automatizare
2. Instruirea personalului
3. Set complet de difuzoare cu produsele furnizate (software și hardware, sisteme software și hardware, produse informatice)
4. Lucrari de constructii si montaj
5. Lucrări de punere în funcțiune
6. Efectuarea de teste preliminare
7. Efectuarea operațiunii de probă
8. Efectuarea testelor de acceptare
Suport AC.
1. Efectuarea lucrărilor în conformitate cu obligațiile de garanție
2. Service post-garanție

Schița, desenele tehnice și documentația de lucru sunt construcția consecventă a soluțiilor de proiectare din ce în ce mai precise. Este posibil să excludeți etapa „Proiectare schiță” și etapele individuale de lucru în toate etapele, pentru a combina etapele „Proiectare tehnică” și „Documentație de lucru” într-un „Proiectare tehnică detaliată”, pentru a efectua diferite etape și a lucra în paralel , și să includă altele suplimentare.

Acest standard nu este pe deplin potrivit pentru evoluțiile actuale: multe procese nu sunt reflectate suficient, iar unele prevederi sunt depășite.

Standardul ISO/IEC 12207/ și aplicarea acestuia

Standardul ISO/IEC 12207:1995 „Tehnologia informației - Procese ale ciclului de viață al software-ului” este principalul document de reglementare care reglementează compoziția proceselor ciclului de viață al software-ului. Acesta definește o structură a ciclului de viață care conține procesele, activitățile și sarcinile care trebuie finalizate în timpul creării software-ului.

Fiecare proces este împărțit într-un set de acțiuni, fiecare acțiune într-un set de sarcini. Fiecare proces, activitate sau sarcină este inițiată și executată de un alt proces după cum este necesar și nu există secvențe de execuție predeterminate. Conexiunile dintre datele de intrare sunt păstrate.

Procesele ciclului de viață al software-ului

De bază:
- Achiziție (acțiuni și sarcini ale clientului care achiziționează software-ul)
- Livrare (acțiuni și sarcini ale furnizorului care furnizează clientului un produs sau serviciu software)
- Dezvoltare (acțiuni și sarcini efectuate de dezvoltator: crearea de software, pregătirea documentației de proiectare și operaționale, pregătirea materialelor de testare și instruire etc.)
- Operare (acțiuni și sarcini ale operatorului - organizația care operează sistemul)
- Întreținere (acțiuni și sarcini efectuate de organizația însoțitoare, adică serviciul de suport). Asistență - efectuarea de modificări la software pentru a corecta erorile, a îmbunătăți productivitatea sau a se adapta la condițiile sau cerințele de operare în schimbare.
Auxiliar
- Documentație (descrierea formalizată a informațiilor create în timpul ciclului de viață al software-ului)
- Managementul configurației (aplicarea procedurilor administrative și tehnice pe tot parcursul ciclului de viață al software-ului pentru a determina starea componentelor software și a gestiona modificările acestuia).
- Asigurarea calității (oferind garanții că sistemul informațional și procesele ciclului său de viață respectă cerințele specificate și planurile aprobate)
- Verificare (determinarea faptului că produsele software rezultate dintr-o anumită acțiune îndeplinesc pe deplin cerințele sau condițiile impuse de acțiunile anterioare)
- Certificare (determinarea completității conformității cerințelor specificate și a sistemului creat cu scopul lor funcțional specific)
- Evaluare comună (evaluarea stării lucrărilor la proiect: controlul planificării și gestionării resurselor, personalului, echipamentelor, instrumentelor)
- Audit (determinarea conformității cu cerințele, planurile și termenii contractului)
- Rezolvarea problemelor (analiza și rezolvarea problemelor, indiferent de originea sau sursa lor, care sunt descoperite în timpul dezvoltării, exploatării, întreținerii sau altor procese)
organizatoric
- Control (acțiuni și sarcini care pot fi efectuate de orice parte care își gestionează procesele)
- Crearea infrastructurii (selectarea și întreținerea tehnologiei, standardelor și instrumentelor, selectarea și instalarea hardware-ului și software-ului utilizat pentru dezvoltarea, operarea sau întreținerea software-ului)
- Îmbunătățirea (evaluarea, măsurarea, controlul și îmbunătățirea proceselor ciclului de viață)
- Instruire (formare inițială și dezvoltare continuă ulterioară a personalului)

Fiecare proces include o serie de acțiuni. De exemplu, procesul de achiziție acoperă următoarele activități:

Inițierea achiziției
Pregatirea propunerilor de licitatie
Intocmirea si ajustarea contractului
Supravegherea activitatilor furnizorilor
Recepția și finalizarea lucrărilor

Fiecare activitate include o serie de sarcini. De exemplu, pregătirea propunerilor de ofertă ar trebui să includă:

Formarea cerințelor de sistem
Generarea unei liste de produse software
Stabilirea termenilor si acordurilor
Descrierea limitărilor tehnice (mediul de operare al sistemului etc.)

Etapele ciclului de viață al software-ului, relațiile dintre procese și etape

Modelul ciclului de viață al software-ului- o structură care determină succesiunea execuției și relațiile dintre procese, acțiuni și sarcini de-a lungul ciclului de viață. Modelul ciclului de viață depinde de specificul, scara și complexitatea proiectului și de condițiile specifice în care sistemul este creat și funcționează.

Standardul GOST R ISO/IEC 12207-99 nu oferă un model de ciclu de viață specific. Prevederile sale sunt comune oricăror modele, metode și tehnologii ale ciclului de viață pentru crearea IP. Descrie structura proceselor ciclului de viață fără a specifica modul de implementare sau finalizare a activităților și sarcinilor incluse în acele procese.

Modelul ciclului de viață al software-ului include:

Etape;
Rezultatele muncii în fiecare etapă;
Evenimentele cheie sunt punctele de finalizare a muncii și de luare a deciziilor.

Etapă- parte a procesului de creare a software-ului, limitată de un anumit interval de timp și care se încheie cu lansarea unui anumit produs (modele, componente software, documentație), determinată de cerințele specificate pentru această etapă.

În fiecare etapă, pot fi efectuate mai multe procese definite în standardul GOST R ISO/IEC 12207-99 și invers, același proces poate fi efectuat în diferite etape. Relația dintre procese și etape este determinată și de modelul ciclului de viață al software-ului utilizat.

Modele ciclului de viață al software-ului

Un model de ciclu de viață este o structură care definește secvența de execuție și relațiile proceselor, activităților și sarcinilor efectuate de-a lungul ciclului de viață. Modelul ciclului de viață depinde de specificul sistemului informațional și de condițiile specifice în care acesta din urmă este creat și funcționează

Până în prezent, următoarele modele principale de ciclu de viață au devenit cele mai răspândite:

Modelul problemei;

model în cascadă (sau sistem) (70-85);

model în spirală (prezent).

Model cu probleme

Când se dezvoltă un sistem „de jos în sus” de la sarcini individuale la întregul sistem (model de sarcină), o abordare unificată a dezvoltării se pierde inevitabil și apar probleme la conectarea componentelor individuale cu informații. De regulă, pe măsură ce numărul de sarcini crește, dificultățile cresc și este necesar să se schimbe constant programele și structurile de date existente. Viteza de dezvoltare a sistemului încetinește, ceea ce încetinește dezvoltarea organizației în sine. Cu toate acestea, în unele cazuri, această tehnologie poate fi recomandabilă:

Urgență extremă (problemele trebuie rezolvate cumva; atunci totul va trebui refăcut);

Experimentarea și adaptarea clientului (algoritmii nu sunt clari, soluțiile se găsesc prin încercare și eroare).

Concluzia generală este că este imposibil să se creeze în acest fel un sistem informațional suficient de mare și eficient.

Model în cascadă

Model în cascadă ciclul de viață a fost propus în 1970 de Winston Royce. Acesta prevede implementarea succesivă a tuturor etapelor proiectului într-o ordine strict fixă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrărilor în etapa anterioară (Fig. 1). Cerințele determinate în etapa formării cerințelor sunt strict documentate sub formă de specificații tehnice și sunt înregistrate pentru întreaga dezvoltare a proiectului. Fiecare etapă culminează cu lansarea unui set complet de documentație suficientă pentru a permite continuarea dezvoltării de către o altă echipă de dezvoltare.

Aspectele pozitive ale utilizării abordării în cascadă sunt următoarele:

la fiecare etapă se generează un set complet de documentație de proiectare care îndeplinește criteriile de completitudine și coerență;

etapele de lucru desfășurate într-o succesiune logică fac posibilă planificarea timpului de finalizare a tuturor lucrărilor și a costurilor corespunzătoare.

Etapele proiectului conform modelului cascada:

Formarea cerințelor;
Proiecta;
Implementarea;
Testare;
Implementarea;
Operare și întreținere.

Orez. 1. Schema de dezvoltare în cascadă

Abordarea în cascadă s-a dovedit bine în construcția sistemelor informaționale, pentru care chiar la începutul dezvoltării toate cerințele pot fi formulate destul de precis și complet pentru a oferi dezvoltatorilor libertatea de a le implementa cât mai bine din punct de vedere tehnic. vedere. Sistemele complexe de calcul, sistemele în timp real și alte sarcini similare se încadrează în această categorie. Cu toate acestea, în procesul de utilizare a acestei abordări, au fost descoperite o serie de deficiențe ale acesteia, cauzate în primul rând de faptul că procesul real de creare a sistemelor nu se încadrează niciodată complet într-o schemă atât de rigidă. În timpul procesului de creație, a existat o nevoie constantă de a reveni la etapele anterioare și de a clarifica sau revizui deciziile luate anterior. Ca rezultat, procesul real de creare a software-ului a luat următoarea formă (Fig. 2):

Orez. 2. Proces real de dezvoltare software folosind o schemă în cascadă

Principalul dezavantaj al abordării în cascadă este întârzierea semnificativă în obținerea rezultatelor. Coordonarea rezultatelor cu utilizatorii se realizează numai în punctele planificate după finalizarea fiecărei etape de lucru, cerințele pentru sistemele informaționale sunt „înghețate” sub formă de specificații tehnice pentru întreaga perioadă de creare. Astfel, utilizatorii își pot face comentariile numai după finalizarea completă a lucrărilor la sistem. Dacă cerințele sunt declarate incorect sau se schimbă pe o perioadă lungă de dezvoltare a software-ului, utilizatorii ajung să aibă un sistem care nu le satisface nevoile. Modelele (atât funcționale, cât și informaționale) ale obiectului automatizat pot deveni învechite simultan cu aprobarea lor. Esența unei abordări sistematice a dezvoltării SI constă în descompunerea (defalcarea) acestuia în funcții automate: sistemul este împărțit în subsisteme funcționale, care la rândul lor sunt împărțite în subfuncții, subdivizate în sarcini și așa mai departe. Procesul de partiționare continuă până la proceduri specifice. În același timp, sistemul automatizat menține o viziune holistică în care toate componentele sunt interconectate. Astfel, principalul avantaj al acestui model este dezvoltarea sa sistematică, iar principalele sale dezavantaje sunt că este lent și scump.

Model în spirală

Pentru a depăși aceste probleme, s-a propus model în spirală ciclul de viață (Figura 3), care a fost dezvoltat la mijlocul anilor 1980 de Barry Boehm. Se bazează pe etapele inițiale ale ciclului de viață: analiză și proiectare. În aceste etape, fezabilitatea soluțiilor tehnice este testată prin crearea de prototipuri.

Prototip- o componentă software de operare care implementează funcții individuale și interfețe externe. Fiecare iterație corespunde creării unui fragment sau a unei versiuni a software-ului, la care se clarifică obiectivele și caracteristicile proiectului, se evaluează calitatea rezultatelor obținute și se planifică activitatea următoarei iterații.

Fiecare iterație reprezintă un ciclu complet de dezvoltare, care are ca rezultat lansarea unei versiuni interne sau externe a unui produs (sau a unui subset al produsului final) care este îmbunătățită de la iterație la iterație pentru a deveni un sistem complet.

Fiecare tură a spiralei corespunde creării unui fragment sau a unei versiuni a software-ului, în care obiectivele și caracteristicile proiectului sunt clarificate, calitatea acestuia este determinată și este planificată activitatea următoarei ture a spiralei. Astfel, detaliile proiectului sunt aprofundate și specificate în mod consecvent și, ca urmare, este selectată o opțiune rezonabilă, care este adusă la implementare.

Dezvoltarea prin iterații reflectă ciclul spiral existent în mod obiectiv al creării unui sistem. Finalizarea incompletă a lucrărilor la fiecare etapă vă permite să treceți la următoarea etapă fără a aștepta finalizarea completă a lucrărilor la cea curentă. Cu o metodă de dezvoltare iterativă, munca lipsă poate fi finalizată în următoarea iterație. Sarcina principală este de a arăta utilizatorilor sistemului un produs funcțional cât mai repede posibil, activând astfel procesul de clarificare și completare a cerințelor.

Principala problemă a ciclului spirală este determinarea momentului de tranziție la etapa următoare. Pentru a o rezolva, este necesar să se introducă restricții de timp pentru fiecare etapă a ciclului de viață. Tranziția decurge conform planului, chiar dacă nu toate lucrările planificate sunt finalizate. Planul este întocmit pe baza datelor statistice obținute în proiectele anterioare și a experienței personale a dezvoltatorilor.

Figura 3. Modelul spiralat al ciclului de viață al unui circuit integrat

Una dintre posibilele abordări ale dezvoltării software în cadrul modelului ciclului de viață în spirală este metodologia RAD (Rapid Application Development), care a devenit recent răspândită. Acest termen se referă de obicei la un proces de dezvoltare software care conține 3 elemente:

o echipă mică de programatori (de la 2 la 10 persoane);

program de producție scurt, dar atent elaborat (de la 2 la 6 luni);

un ciclu iterativ în care dezvoltatorii, pe măsură ce aplicația începe să prindă contur, solicită și implementează în produs cerințele primite prin interacțiunea cu clientul.

Ciclul de viață al software-ului conform metodologiei RAD constă din patru faze:

faza de definire și analiză a cerințelor;

fază de proiectare;

faza de implementare;

faza de implementare.

La fiecare iterație sunt evaluate următoarele:

riscul depășirii termenelor și costurilor proiectului;
necesitatea de a efectua o altă iterație;
gradul de completitudine și acuratețe de înțelegere a cerințelor sistemului;
fezabilitatea rezilierii proiectului.

Avantajele abordării iterative:

Dezvoltarea iterativă simplifică foarte mult efectuarea de modificări la proiect atunci când cerințele clienților se modifică.
Atunci când se utilizează modelul în spirală, elementele individuale ale sistemului informațional sunt integrate treptat într-un singur întreg. Cu o abordare iterativă, integrarea are loc practic continuu. Deoarece integrarea începe cu mai puține elemente, există mult mai puține probleme în timpul implementării acesteia (conform unor estimări, atunci când se utilizează modelul de dezvoltare în cascadă, integrarea reprezintă până la 40% din toate costurile la sfârșitul proiectului).
Dezvoltarea iterativă oferă o mai mare flexibilitate în managementul proiectelor, făcând posibilă efectuarea de modificări tactice la produsul dezvoltat.
Abordarea iterativă simplifică reutilizarea componentelor (implementează o abordare bazată pe componente a programării). Acest lucru se datorează faptului că este mult mai ușor să identifici părți comune ale unui proiect atunci când acestea au fost deja parțial dezvoltate decât să încerci să le identifici chiar la începutul proiectului. Analizând designul după câteva iterații inițiale dezvăluie componente comune, reutilizabile, care vor fi îmbunătățite în iterațiile ulterioare.
Modelul în spirală permite un sistem mai fiabil și mai stabil. Acest lucru se datorează faptului că, pe măsură ce sistemul evoluează, erorile și punctele slabe sunt descoperite și corectate la fiecare iterație. În același timp, pot fi ajustați parametrii critici de performanță, ceea ce în cazul unui model în cascadă este posibil doar înainte ca sistemul să fie implementat.
Abordarea iterativă face posibilă îmbunătățirea procesului de dezvoltare - analiza efectuată la sfârșitul fiecărei iterații ne permite să evaluăm ceea ce trebuie schimbat în organizația de dezvoltare și să îl îmbunătățim la următoarea iterație.

Adnotare.

Introducere.

1. Ciclul de viață al software-ului

Introducere.

Etapele procesului de programare Riley

Introducere.

1.1.1. Formularea problemei.

1.1.2. Proiectarea soluției.

1.1.3. Codarea algoritmului.

1.1.4. Suport program.

1.1.5. Documentația software.

Concluzie la clauza 1.1

1.2. Determinarea LCPO conform Lehman.

Introducere.

1.2.1 Definirea sistemului.

1.2.2. Implementarea.

1.2.3. Serviciu.

Concluzie la clauza 1.2.

1.3. Fazele și lucrul LCPO conform lui Boehm

1.3.1. Model în cascadă.

1.3.2. Justificare economică pentru modelul în cascadă.

1.3.3. Îmbunătățirea modelului în cascadă.

1.3.4. Determinarea fazelor ciclului de viață.

1.3.5. Lucrarea principală a proiectului.

Literatură.

Introducere

1 Ciclul de viață al software-ului

INTRODUCERE

Cel mai faimos și complet, poate, este structura procesului ciclului de viață conform lui Boehm, care include opt faze. Va fi prezentat mai detaliat în viitor.

1.1 Etapele procesului de programare Riley

Procesul de programare presupune patru pași (Figura 1):

enunţarea problemei, de ex. obținerea unei înțelegeri adecvate a sarcinii pe care trebuie să o îndeplinească programul;

proiectarea unei soluții la o problemă deja enunțată (în general, o astfel de soluție este mai puțin formală decât programul final);

codificarea programului, adică traducerea soluției proiectate într-un program care poate fi executat pe o mașină;

suport de program, de ex. procesul continuu de depanare a programului și adăugarea de noi funcții.

Orez. 1.Patru pași de programare.

Programarea începe din momentul în care utilizator, adică cineva care are nevoie de un program pentru a rezolva o problemă afirmă problema analist de sistem. Utilizatorul și analistul de sistem definesc împreună declarația problemei. Acesta din urmă este apoi transmis algoritmist, care este responsabil pentru proiectarea soluției. O soluție (sau algoritm) reprezintă o succesiune de operații, a căror execuție duce la rezolvarea unei probleme. Deoarece algoritmul nu este adesea potrivit pentru execuție pe o mașină, ar trebui tradus într-un program de mașină. Această operație este efectuată de codificator. Programatorul însoțitor este responsabil pentru modificările ulterioare ale programului. Și analistul de sistem, și algoritmistul, și codificatorul și programatorul care îl însoțește - toți sunt programatori.

1.1.1 Declarația problemei

Caracteristicile unei declarații bune de problemă:

Precizie, adică eliminând orice ambiguitate. Nu ar trebui să existe nicio întrebare cu privire la ceea ce va fi rezultatul programului pentru orice intrare dată.

Completitudine, adică luarea în considerare a tuturor opțiunilor pentru o intrare dată, inclusiv intrarea eronată sau neintenționată și determinarea ieșirii corespunzătoare.

Claritate, adică trebuie să fie de înțeles atât pentru utilizator, cât și pentru analistul de sistem, deoarece enunțul problemei este singurul contract între ei.

Forma standard de enunțare a problemei.

Luați în considerare următoarea afirmație a problemei: „Introduceți trei numere și scoateți numerele în ordine.”

numele sarcinii (definiție schematică);

descriere generală (scurt rezumat al sarcinii);

erori (opțiunile de intrare neobișnuite sunt enumerate în mod explicit pentru a arăta utilizatorilor și programatorilor ce acțiuni ar întreprinde mașina în astfel de situații);

exemplu (un exemplu bun poate transmite esența problemei și, de asemenea, poate ilustra diferite cazuri).

Exemplu. Enunțarea problemei într-o formă standard.

NUME

Sortarea a trei numere întregi.

DESCRIERE

Intrarea și ieșirea a trei numere întregi, sortate de la cel mai mic la cel mai mare număr.

1) Dacă sunt introduse mai puțin de trei numere, programul așteaptă introducerea suplimentară.

2) Liniile de intrare altele decât primele trei sunt ignorate.

3) Dacă oricare dintre primele trei linii conține mai mult de un număr întreg, atunci programul se iese și afișează un mesaj.

EROARE DE INTRODUCERE - Este permis doar un număr întreg pe linie.

intrare ® – 3

Acest pas de programare este cel mai dificil. În această etapă, enunțul problemei trebuie transformat într-un algoritm. Prin urmare, un designer de algoritm trebuie să aibă suficientă experiență de programare și să abordeze fiecare nouă problemă pe baza unei metodologii de proiectare bine stabilite. Din păcate, în zilele noastre toate programele mari conțin bug-uri, ceea ce duce la proiecte proaste. Proiectele proaste, la rândul lor, sunt o consecință a complexității problemelor și a utilizării unor metode de proiectare inadecvate. Pentru a evita erorile în programe, algoritmiștii trebuie să utilizeze proceduri de proiectare atent concepute, bazate pe reguli de inferență.

Există două modele principale de inferență:

Primul model este cunoscut ca inferență deductivă. Această formă de gândire logică a fost imortalizată de celebrul detectiv Sherlock Holmes. Logica deductivă aplică reguli generale în cazuri specifice. De exemplu, Holmes ar putea deduce afirmația specifică „Majordomul este criminalul” din cunoștințele mai generale „Ucigașul blond” și „Majordomul este singurul bărbat blond care poate fi suspectat”.

Al doilea model este ieșire inductivă, care este opusul inferenței deductive. Logica inductivă trage concluzii generale din cazuri individuale. De exemplu, inferența inductivă poate fi folosită pentru a justifica concluzia generală „soarele răsare în est” pe baza multor observații individuale că soarele a răsărit întotdeauna în est.

Aceste două procese de inferență sunt − deducere(de la general la specific) și inducţie(de la specific la general) - sunt strâns legate de cele două metode de proiectare cele mai utilizate pe scară largă: "de sus în jos"Și "jos sus". La fel ca deducția, designul de sus în jos începe cu o problemă mare care este defalcată în subprobleme. De exemplu, proiectantul unui nou frigider-congelator, pe baza unui set inițial de specificații ale unității (adică, declarația problemei), trebuie să realizeze proiecte și specificații detaliate pentru produsul final (adică, designul).

Dacă folosește o metodă de proiectare de sus în jos, atunci o singură problemă de proiectare poate fi împărțită în două subprobleme mai mici: (1) proiectarea unității de refrigerare și (2) proiectarea congelatorului.

Cu toate acestea, puteți utiliza metoda de proiectare de jos în sus și puteți începe prin a proiecta compresorul frigorific și apoi conductele de refrigerare, unitatea sau camera frigorifică. În acest caz, această alegere va impune anumite restricții asupra întregului proiect.

Sarcina designerului este de a crea un algoritm care acționează ca o legătură între enunțul problemei și programul gata de execuție. Verificarea algoritmului creat, adică cât de bine reflectă acesta din urmă formularea problemei, este efectuată de un analist de sistem. Din acest motiv, atât analistul de sisteme, cât și proiectantul trebuie să fie capabili să citească și să înțeleagă algoritmul. Fiecare algoritm este scris într-un pseudo-limbaj . Algoritmii, numiți și pseudocoduri, nu pot fi executați pe niciun computer.

Sarcina codificatorului este de a traduce algoritmul într-un program. Pentru a crea un program complet, precis și ușor de înțeles, sunt necesare tehnici adecvate de scriere a programelor. De exemplu, rețetele culinare sunt de obicei scrise în limbi naturale, cum ar fi engleza, franceză, rusă sau japoneză. Programele sunt scrise în limbaje de programare. În prezent, niciunul dintre limbajele naturale nu poate fi folosit ca limbaj de programare, deoarece sunt prea complexe pentru a fi „înțelese” de mașini. Spre deosebire de limbajele naturale, limbajele de programare sunt create special pentru a reprezenta o soluție la o problemă care poate fi rezolvată de un computer.

Codificatorul trebuie să se asigure că programul se potrivește cu pseudocodul înainte de a ieși. Apoi, analistul de sistem, algoritmistul și, cel mai important, utilizatorul trebuie să testeze și să confirme că funcționează corect. După aceasta, putem presupune că programul este gata pentru a fi transferat utilizatorului complet cu toată documentația necesară.

Cu toate acestea, programarea nu se termină aici; urmată de pasul de acompaniament. Cert este că pot exista erori în program, fie din cauza unei enunțuri inadecvate a problemei, fie a faptului că proiectul nu satisface enunțul problemei sau programul nu corespunde proiectului. Oricare ar fi motivul, utilizatorul are dreptul de a cere ajustări ale programului, deoarece nu și-a imaginat că programul va funcționa în acest fel. Corectarea erorilor este una dintre sarcinile principale ale întreținerii programului. O altă sarcină la fel de importantă a întreținerii programului este modificarea acestuia, adică adăugarea de noi funcții la program sau modificarea celor existente. Utilizatorul poate modifica cerințele pentru funcționarea programului, ceea ce, la rândul său, va duce la necesitatea rescrierii acestuia. Complexitatea întreținerii programului depinde de tipul de modificări care trebuie făcute: în cel mai rău caz, este posibil ca programul să fie complet reproiectat de la producție la codare. De obicei, se petrece mai mult timp întreținând un program decât creând-l.

Ultima parte a procesului de programare este documentație. Include o gamă largă de descrieri care facilitează procesul de programare și îmbogățesc programul rezultat. Documentarea continuă ar trebui să fie o parte integrantă a fiecărui pas de programare. Declarația problemei, documentele de proiectare, algoritmii și programele - toate acestea sunt documente. Documentația internă inclusă direct în program face codul mai ușor de citit. Scopul unui manual de instruire (o altă formă de documentare) este de a învăța utilizatorul cum să folosească un nou program; Manualul de referință oferă o descriere a comenzilor software.

Concluzie la clauza 1.1.

Conform modelului prezentat în acest capitol, programarea poate fi împărțită în patru etape: definirea problemei, proiectarea soluțiilor, codificarea programului și menținerea programului. În plus, modelul include documentarea programului ca activități care trebuie efectuate pe tot parcursul procesului de programare.

Modelul de programare este construit special pentru a rezolva probleme mari, deoarece sunt de interes pentru informaticieni. Cu toate acestea, în practică, este important să se utilizeze tehnici de inginerie atent selectate pentru proiectarea programelor, indiferent de dimensiunea problemelor: abilitățile dobândite în rezolvarea unor probleme mai mici pot fi consolidate și implementate cu succes în rezolvarea unor probleme mai mari.

definiții;

implementare;

serviciu.

1.2.1 Definirea sistemului

Procesul de creare a software-ului începe cu cercetări practice care conduc la analiza sistemului, a cărei sarcină este de a determina cerințele generale pentru sistem și programe. O astfel de analiză ar trebui, în primul rând, să stabilească nevoi și scopuri reale și, dacă este posibil, să identifice metodele disponibile pentru atingerea scopului. Dacă este necesar, analiza se poate baza pe scheme matematice sau alte scheme formale. Se crede că, cu orice abordare, analiza specificată trebuie să aibă o anumită structură și să fie efectuată în conformitate cu o anumită teorie. Analiza și perfecționarea, efectuate în comun cu analiștii și potențialii utilizatori, ar trebui să conducă la dezvoltarea unei specificații finale a cerințelor .

Procesul de redactare a unei astfel de specificații are ca scop obținerea unei specificații tehnice corecte, complete în sensul reflectării cerințelor și coerente cu definiția implementării. Urmează întocmirea caietului de sarcini este faza proiecta, al cărui sens este identificarea și structurarea datelor, transformarea acestora și organizarea transferului lor. În plus, în această fază este necesar să se realizeze, într-un anumit sens, o distribuție optimă a funcțiilor sistemului, selectarea unui algoritm și proceduri, precum și identificarea componentelor sistemului și a relației dintre acestea.

După ce a finalizat proiecta putem începe implementare sisteme. Cu toate acestea, în practică, fazele de proiectare și implementare se suprapun. Astfel, pe măsură ce procesul ierarhic de partiţionare continuă, analiza unor elemente ale sistemului poate fi considerată suficient de completă pentru a trece la implementare, în timp ce alte elemente necesită clarificări suplimentare.

În timpul procesului de implementare, este necesar să se stabilească corectitudinea programului. Procedurile moderne se bazează în mare parte pe teste, deși utilizarea metodelor de control structural end-to-end și de validare a programelor a crescut în ultimii ani.

În orice caz, testarea prin execuția programului se face de obicei de jos în sus, mai întâi la nivel de bloc (modular sau procedural), apoi funcțional, componentă cu componentă. Pe măsură ce componentele individuale sunt testate, acestea sunt combinate într-un sistem în timpul procesului de aranjare, după care începe testarea sistemului. În cele din urmă, după ce calitatea funcționării sistemului a fost verificată independent și parametrii acestuia au fost evaluați, acesta este considerat pregătit pentru eliberare.

1.2.3 Întreținere

Procesul de întreținere începe imediat după eliberarea sistemului. Erorile trebuie identificate și corectate. Dacă o eroare împiedică funcționarea normală a utilizatorului, programul defect poate fi eliminat temporar din sistem sau pot fi făcute remedieri temporare sau permanente la unele sau la toate sistemele aflate în uz. Remedierea sau modificarea permanentă poate fi apoi inclusă într-o nouă ediție a sistemului. Pentru a adapta toate modificările și combinațiile acestora, sunt create mai multe versiuni ale elementelor sistemului. Sarcina principală devine gestionarea configurației sistemului. Un rol decisiv în managementul programării revine serviciilor de suport care colectează și reglementează automat toate modificările din sistem.

Concluzie la clauza 1.2.

Metasistemul în cadrul căruia se dezvoltă programul conține un număr semnificativ mai mare de bucle de feedback decât este indicat mai sus. Multe activități se suprapun, sunt împletite în moduri complexe și sunt repetate sistematic. Prin urmare, modelul LCPO prezentat de Boehm este suficient de justificat.

1.3 Fazele și activitatea centrelor ciclului de viață conform Boehm

Modelul în cascadă a fost introdus în anii 70 - 80. Este convenabil pentru software-ul omogen, când fiecare aplicație era un singur întreg.

Principalele caracteristici ale modelului:

Ciclul de viață este împărțit în etape (faze);

Trecerea de la etapa la etapa - numai dupa finalizarea completa a etapei curente;

Etapa se încheie cu lansarea unui set complet de documentație, suficient pentru ca lucrarea să poată fi finalizată de o altă echipă de dezvoltare.

Principalele caracteristici model în cascadă următoarele:

parcurgerea fiecărei etape cu verificare și validare, al cărei scop este eliminarea cât mai multor probleme asociate dezvoltării produsului;

repetări ciclice ale fazelor implementate încă din cea mai timpurie fază posibilă.

Fig.2. Modelul în cascadă al LCPO.

În modelul în cascadă, finalizarea cu succes a uneia dintre fazele ciclului de viață înseamnă atingerea obiectivului de programare inginerească corespunzător (a se vedea paragraful 2.4.). La aceste subobiective trebuie să adăugați încă două:

Designabilitate detaliată– obținerea de specificații și structuri de control și date complete verificate, conexiuni de interfață, caracteristici, algoritmi de bază și determinarea condițiilor de funcționare a fiecărei componente software.

Codabilitate– obținerea unui set complet, verificat de componente ale programului.

Principalele avantaje:

Formarea unui set complet de documentație de proiect la sfârșitul lucrărilor pe scenă. Documentația îndeplinește criteriile de completitudine și exhaustivitate;

Abilitatea de a planifica termene limită și costuri. Pentru o serie de aplicații software, acest model este fezabil - acesta este pentru sistemele pentru care în etapa de analiză este posibil să se formuleze cu acuratețe și complet toate cerințele. De exemplu, programe de calcul complexe.

Principalele dezavantaje:

Timp lung de livrare de la analiză până la finalizare;

Cerințele software sunt „înghețate” sub formă de specificații tehnice până la sfârșitul dezvoltării.

1.3.2 Justificare economică a modelului în cascadă

Fără să aprofundăm în analiza economică pe care B.U. Boehm acordă multă atenție în cartea „Inginerie software”, să spunem doar că justificarea economică a modelului cascadă, axată pe atingerea succesivă a obiectivelor, se bazează pe două premise principale:

Pentru a obține un produs software de înaltă calitate (adică unul care satisface pe deplin toate obiectivele produsului software solicitat), este necesar, în orice caz, implementarea tuturor sub-obiectivelor în fiecare etapă.

Orice altă ordonare a subscopurilor are ca rezultat crearea unui produs software de calitate inferioară.

1.3.3 Îmbunătățirea modelului în cascadă

Să luăm în considerare una dintre îmbunătățirile modelului ideal de cascadă - dezvoltarea pas cu pas.

Dezvoltare pas cu pas este o îmbunătățire a metodei de proiectare iterativă cu prototipare și dezvoltare stratificată de sus în jos. Această metodă implică creșterea progresivă a funcționalității software-ului în timpul procesului de dezvoltare.

Ca model avansat de cascadă, dezvoltarea incrementală a fost folosită cu succes pentru a crea produse software atât de mari dimensiuni, cât și de mici.

Principalele avantaje ale dezvoltării pas cu pas față de dezvoltarea absolut iterativă și dezvoltarea de sus în jos nivel cu nivel sunt următoarele:

utilizarea extensiilor succesive ale programului oferă o modalitate mult mai puțin costisitoare de a încorpora experiența utilizatorului într-un produs îmbunătățit decât prin redezvoltare;

Extinderea funcționalității este mult mai ușor de testat și este mai utilă decât produsele intermediare în dezvoltarea stratificată.

Valoarea dezvoltării incrementale constă în principal în modificarea distribuției costurilor forței de muncă pentru proiect. O variantă a modelului în cascadă pentru dezvoltarea pas cu pas este prezentată în Figura 3.

1.3.4 Definirea fazelor ciclului de viață

Mai jos va fi prezentată formularea obiectivelor finale ale fiecărei etape pentru trecerea la faza următoare. Pentru dezvoltarea pas cu pas, afirmațiile date se referă la limitele de fază ale fiecărei etape de extindere.

Începe faza de planificare și analiză a cerințelor.(Revizuire conceptuală completă a LCPE.)

Obținerea unei arhitecturi de sistem aprobate și confirmate, inclusiv acorduri de bază privind distribuția funcțiilor între hardware și programe. Obținerea unei înțelegeri generale aprobate și confirmate a funcționării software-ului, inclusiv acorduri de bază privind distribuția funcțiilor între persoană și sistem.

Formarea unui plan general pentru procesul ciclului de viață, definind principalele etape, resurse, responsabilități, termene și principalele lucrări.

Finalizați faza de planificare și analiză a cerințelor. Începeți faza de proiectare a produsului.(Revizuire completă a cerințelor software).

Formarea unui plan detaliat de dezvoltare: indicatori detaliați pentru finalizarea etapelor de dezvoltare, planuri de alocare a resurselor, diagrame de structură organizatorică, responsabilități, termene, lucrări, metode și produse.

Formarea unui plan detaliat de utilizare: puncte ale planului de dezvoltare, al cărui conținut este axat pe instruire, transfer de programe, implementare, operare și întreținere.

Formarea unui plan detaliat de depanare a produsului - plan de management al configurației hardware, plan de control al calității, plan general de verificare și confirmare.

Specificații pentru cerințele software aprobate și validate: specificații funcționale, tehnice și de interfață care s-au dovedit a fi complete, consecvente, verificabile și fezabile.

Un acord de dezvoltare aprobat (formal sau informal) bazat pe punctele de mai sus.

Finalizați faza de proiectare a produsului. Începeți faza de proiectare detaliată.(Finalizarea analizei rezultatelor designului produsului.)

Dezvoltarea unei specificații verificate pentru un proiect de produs software:

formarea unei ierarhii de componente software, interfețe interbloc pentru date și control;

formarea structurilor de date fizice și logice până la nivelul câmpurilor individuale;

elaborarea unui plan de distribuire a resurselor de calcul (timp, memorie, precizie);

verificarea completității, coerenței, fezabilității și validității cerințelor.

Stabilirea și rezolvarea tuturor contradicțiilor de dezvoltare care cresc gradul de risc.

Dezvoltarea unei etape preliminare de integrare și depanare, a unui plan manual de utilizare și a testelor de acceptare.

Finalizați faza de proiectare detaliată. Începeți faza de codare și depanare offline.(Finalizarea controlului proiectului de la capăt la capăt sau analizei critice bloc cu bloc a proiectului.)

Specificații detaliate verificate pentru fiecare bloc:

specificarea fiecărei subrutine, nume, scop, ipoteze, dimensiuni, secvență de apeluri, ieșiri de eroare, date de intrare și ieșire, algoritmi și design logic;

descrierea bazei de date până la nivelul parametrilor, simbolurilor și biților individuali;

Verificarea completității, coerenței și conformității cu specificațiile de proiectare a sistemului și cu planurile de alocare a resurselor.

Plan de testare de acceptare aprobat.

Manuale de utilizare, precum și un plan preliminar de integrare și depanare completat.

Finalizați faza de copiere și depanare. Începeți faza de integrare și depanare.(Satisface criteriile de depanare offline.)

Verificarea funcționării tuturor unităților nu numai pentru valorile nominale, ci și pentru valorile excepționale și limită.

Verificarea tuturor opțiunilor de intrare și de ieșire, inclusiv a mesajelor de eroare.

Executarea tuturor operatorilor și a tuturor ramurilor de transfer de control.

Verificarea conformității cu standardele de programare.

Completarea documentației bloc cu bloc a structurii interne.

Finalizați faza de integrare și testare. Începe faza de implementare.(Finalizarea analizei rezultatelor testului de acceptare.)

Verificarea conformității cu testul de acceptare a programului:

verificarea conformității cu cerințele software;

Demonstrarea acceptabilității caracteristicilor de performanță specificate în specificații în condiții anormale.

Acceptarea produselor software furnizate, rapoarte, manuale, baze de date, specificații de structură internă.

Finalizați faza de implementare. Începeți faza de operare și întreținere.(Examinarea completă a acceptării sistemului.)

Verificarea rezultatelor satisfăcătoare ale testelor de acceptare a sistemului.

Verificarea faptului că cerințele de sistem sunt satisfăcătoare.

Verificarea pregătirii pentru producție a software-ului, hardware-ului, instrumentelor de întreținere și personalului.

Acceptarea produselor furnizate și incluse în sistem: hardware, software, documentație, instrumente de instruire și întreținere.

Finalizarea tuturor lucrărilor specificate și punerea în funcțiune a sistemului.

Finalizați faza de operare și întreținere(prin întrerupere).

Îndeplinirea tuturor punctelor din planul de dezafectare: transfer de programe, documentare, crearea unei arhive, trecerea la un nou sistem.

1.3.5 Lucrări principale ale proiectului

Analiza cerințelor.

Design de produs.

Programare.

Planificarea depanării.

Verificare și confirmare.

Management de proiect.

Managementul configurației și controlul calității.

Deci, au fost luate în considerare trei abordări pentru a determina ciclul de viață al software-ului. În opinia mea, toți au dreptul de a exista, deoarece într-o măsură sau alta reflectă practica programării. Mai mult, este ușor de descoperit puncte comune (se stabilește o sarcină - se definește un sistem - se analizează cerințele; întreținerea programului - întreținerea - operarea și întreținerea).

Cu toate acestea, trebuie remarcat faptul că definiția lui Boehm a fazelor și lucrării procesului ciclului de viață este cea mai justificată, deoarece se bazează pe o abordare mai concentrată în programarea inginerească (care vizează obținerea unui produs software de înaltă calitate și implementarea unui proces eficient de dezvoltare și întreținere software) și este justificată din punct de vedere economic.

Pe baza acestui raport, este clar cât de important și necesar este să cunoaștem nevoile lumii moderne atunci când se creează un produs (produs) software. Atunci când se elaborează un program pentru automatizarea oricărui sistem, este important să se țină cont de faptul că lumea modernă este în continuă schimbare, ceea ce înseamnă că programul trebuie să fie capabil de schimbare.

De asemenea, este important, la întocmirea unui program, să se țină cont de faptul că programul trebuie să fie corect; complet în conținut și potrivit pentru a lucra atât cu probleme mici, cât și cu probleme mari, în conformitate cu scopul său; clar - astfel încât utilizatorul să poată lucra cu el calm și fără dificultate. Și, de asemenea, pentru ca programul să poată fi corectat sau completat cu ușurință în orice moment, în conformitate cu cerințele în schimbare din lumea modernă.

Trebuie amintit că o programare bună nu este despre codificarea unei soluții rapide folosind orice tehnică adecvată, ci despre o procedură de inginerie atent instrumentată, care produce un software complet, precis și ușor de înțeles (clar).

1. B.U. Boehm, Inginerie software. M.: Radio și comunicații. 1985.

2. D. Riley. „Utilizarea limbajului Modula-2”. M.: Mir. 1993.

3. Yu.V. Ivanov „Programele și ciclurile lor de viață” (rezumat despre disciplina „Metrologie software”). 1998.

Bună ziua, dragi locuitori din Khabrovsk! Cred că va fi interesant ca cineva să-și amintească ce modele de dezvoltare, implementare și utilizare a software-ului au existat anterior, ce modele sunt utilizate în principal acum, de ce și ce este de fapt. Acesta va fi micul meu subiect.

De fapt, ce este ciclul de viață al software-ului- o serie de evenimente care apar cu sistemul în timpul creării și utilizării ulterioare. Cu alte cuvinte, acesta este timpul de la momentul inițial al creării oricărui produs software până la sfârșitul dezvoltării și implementării acestuia. Ciclul de viață al software-ului poate fi reprezentat sub formă de modele.

Modelul ciclului de viață al software-ului- o structură care conține procese de acțiune și sarcini care sunt efectuate în timpul dezvoltării, utilizării și întreținerii unui produs software.
Aceste modele pot fi împărțite în 3 grupuri principale:

Abordare inginerească
Ținând cont de specificul sarcinii
Tehnologii moderne de dezvoltare rapidă

Acum să ne uităm la modelele (subclasele) existente și să evaluăm avantajele și dezavantajele acestora.

Model de codificare și eliminare a erorilor

Un model complet simplu, tipic pentru studenții universitari. În conformitate cu acest model, majoritatea studenților dezvoltă, să spunem, lucrări de laborator.
Acest model are următorul algoritm:

Formularea problemei
Performanţă
Verificarea rezultatului
Dacă este necesar, treceți la primul punct

Model de asemenea teribilînvechit. Este tipic pentru anii 1960-1970, deci practic nu are avantaje față de următoarele modele din recenzia noastră, dar dezavantajele sunt evidente. Face parte din primul grup de modele.

Modelul ciclului de viață al software-ului în cascadă (cascada)

Algoritmul acestei metode, pe care îl arăt în diagramă, are o serie de avantaje față de algoritmul modelului anterior, dar are și un număr de semnificativ neajunsuri.

Avantaje:

Implementarea succesivă a etapelor proiectului într-o ordine strict fixă
Vă permite să evaluați calitatea produsului în fiecare etapă

Defecte:

Fără feedback între etape
Nu corespunde condițiilor reale de dezvoltare a produsului software

Face parte din primul grup de modele.

Model în cascadă cu control intermediar (vârtej)

Acest model este aproape echivalent ca algoritm cu modelul anterior, cu toate acestea, are conexiuni de feedback cu fiecare etapă a ciclului de viață și dă naștere unui dezavantaj foarte semnificativ: Creșterea de 10 ori a costurilor de dezvoltare. Face parte din primul grup de modele.

Model V (dezvoltare bazată pe teste)

Acest model are un algoritm mai apropiat de metodele moderne, dar are totuși o serie de dezavantaje. Este una dintre practicile principale ale programării extreme.

Model bazat pe dezvoltarea prototipului

Acest model se bazează pe dezvoltarea de prototipuri și prototiparea produselor.
Prototiparea utilizate în primele etape ale ciclului de viață al software-ului:

Clarificarea cerințelor neclare (prototip UI)
Alegeți una dintre numeroasele soluții conceptuale (implementarea scenariilor)
Analizați fezabilitatea proiectului

Clasificarea prototipurilor:

Orizontală și verticală
De unică folosință și evolutiv
hârtie și storyboard-uri

Orizontală prototipuri - modelează exclusiv UI fără a afecta logica de procesare și baza de date.
Vertical prototipuri - testarea solutiilor arhitecturale.
De unică folosință prototipuri - pentru dezvoltare rapidă.
Evolutiv prototipurile sunt prima aproximare a unui sistem evolutiv.

Modelul aparține celui de-al doilea grup.

Modelul ciclului de viață al software-ului în spirală

Modelul în spirală este un proces de dezvoltare software care combină atât proiectarea, cât și prototiparea incrementală pentru a combina beneficiile conceptelor de jos în sus și de sus în jos.

Avantaje:

Obțineți rezultate rapid
Creșterea competitivității
Schimbarea cerințelor nu este o problemă

Defecte:

Lipsa regulamentului de etapă

Al treilea grup include modele precum programare extremă(XP) SCRUM, model incremental(RUP), dar aș vrea să vorbesc despre ele într-un subiect separat.

Mulțumesc foarte mult pentru atenție!