În cazul general, un sistem software, pe lângă programele în sine, conține și hardware și este, de obicei, considerat înconjurat de alte sisteme software și hardware.

Ciclul de viață al unui sistem software este de obicei înțeles ca întreaga perioadă de existență a unui sistem software, începând din momentul în care conceptul inițial al sistemului este dezvoltat și terminând atunci când sistemul devine învechit. Concept „ciclul de viață”” utilizat atunci când se așteaptă ca sistemul software să aibă o durată de viață destul de lungă, spre deosebire de programarea experimentală în care programele sunt rulate de mai multe ori și nu sunt utilizate din nou.

Ciclul de viață este modelat în mod tradițional ca un număr de etape succesive (sau etape, faze). În prezent, nu există o împărțire general acceptată a ciclului de viață al unui sistem software în etape. Uneori, o etapă este evidențiată ca un punct separat, uneori este inclusă ca parte integrantă a unei etape mai mari. Acțiunile efectuate într-o etapă sau alta pot varia. Nu există o uniformitate în denumirile acestor etape. Prin urmare, vom încerca mai întâi să descriem un ciclu de viață generalizat al unui sistem software și apoi să demonstrăm câteva exemple de cicluri de viață diferite, indicând analogii din acest ciclu generalizat.

Etapele ciclului de viață al software-ului

Ciclul de viață al software-ului este perioada dezvoltării și exploatării software-ului, care cuprinde de obicei următoarele etape: -1- apariția și cercetarea unei idei; -2- analiza si proiectarea cerintelor; -3- programare; -4- testare și depanare; -5- punerea în aplicare a programului; -6- operarea si intretinerea; -7- sfârșitul funcționării.

Trebuie remarcat faptul că împărțirea ciclului de viață în etape poate ascundea uneori unele aspecte importante ale dezvoltării software; Acest lucru este valabil mai ales în legătură cu un proces atât de necesar precum implementarea iterativă a diferitelor etape ale ciclului de viață pentru a corecta erorile, a schimba deciziile care s-au dovedit a fi incorecte sau a lua în considerare modificările cerințelor generale ale sistemului.

Exemple de descrieri ale ciclului de viață

Să ne uităm la mai multe descrieri ale ciclului de viață al software-ului, care vor servi ca un fel de comentariu asupra etapelor ciclului de viață generalizat.

În documentele de reglementare naționale (de exemplu, GOST ESPD), se adoptă următoarea împărțire în etape, care este dată cu o indicație a analogiilor din lista dată la începutul secțiunii:

elaborarea specificațiilor tehnice (etapele 1 și 2);

proiectare tehnică (etapa a treia până la 3.2.1 inclusiv);

proiect de lucru (3.2.2, 4.2.1 și, parțial, 4.2, 4.3);

implementare pilot (4.2 și 4.3);

punerea in functiune in exploatare comerciala (etapa 5);

exploatare industrială (etapa 6).

O astfel de descriere se bazează pe tehnologia de dezvoltare hardware și, prin urmare, nu ia în considerare pe deplin toate caracteristicile distinctive ale designului software. O descriere mai adecvată a ciclului de viață software pare să fie 12 etape, care sunt foarte asemănătoare cu etapele ciclului de viață generalizat (vezi Figura 1.1). În paranteze după numele fazei, este indicat un analog din ciclul generalizat. Aproape toate etapele se încheie cu verificarea rezultatelor obținute la etapa corespunzătoare.

Orez. 1.1 Exemplu de ciclu de viață al sistemelor software

Inițierea și planificarea proiectului (etapa 1). Sunt determinate acțiunile necesare, planurile și organizarea managementului de proiect.

Sunt determinate măsuri care să asigure implementarea continuă a fazelor ciclului de viață.

Analiza cerințelor țintă (2.1).

Se determină caracteristicile generale ale sistemului pe care acesta trebuie să le satisfacă, fără a lua în considerare mijloacele de implementare.

Proiectare software preliminară (3.2.1). Determinarea componentelor software specifice care vor fi dezvoltate și implementate în sistemul final. Verificarea acestui set de componente pentru consecvența cu cerințele generale ale software-ului. Determinarea cerințelor funcționale, operaționale și de testare pentru fiecare componentă specifică.

Proiectare software detaliată (3.2.2). În ceea ce privește constructele software utilizate, se face o descriere a modului în care fiecare componentă specifică va fi dezvoltată.

Sunt descrise modurile de utilizare ale fiecărei componente din sistem.

Codare și testare software (4.1.1 și 4.1.2). Crearea, testarea modulelor individuale, documentarea și acceptarea componentelor software care alcătuiesc sistemul software.

Integrare software (partea 4.2). Testarea performanței și completității funcționale a părților software ale sistemului într-un mediu previzibil (hardware și mediu).

Integrarea sistemului (4.3). Testarea performanței și completității funcționale a părților sistemului general în ansamblu.

Recepția și livrarea sistemului (5). Sistemul este acceptat de client și acesta este livrat acestuia.

Exploatarea și întreținerea sistemului (6). Lansarea versiunilor sau versiunilor ulterioare ale sistemului, a căror nevoie apare din cauza eliminării defectelor, testării cerințelor modificate etc.

Finalizarea proiectului (7). Formarea unui model post-origine al acțiunilor proiectului cu o analiză a avantajelor, dezavantajelor etc., și utilizarea acestora ca bază pentru îmbunătățirea procesului de dezvoltare.

Ca exemplu următor, luați în considerare un ciclu de viață incomplet al software-ului, fără etape de operare și întreținere (vezi Fig. 1.2). Această opțiune nu fixează succesiunea fazelor sau etapelor, ci propune mai degrabă o listă de acțiuni care trebuie efectuate pe tot parcursul ciclului de viață al software-ului. Aceste acțiuni pot fi defalcate sau, dimpotrivă, grupate în diferite etape, în funcție de condițiile specifice. Se pot distinge următoarele etape ale ciclului de viață al sistemelor software (în paranteze, ca și înainte, sunt analogi cu modelul ciclului generalizat):

etapa de planificare, care determină și coordonează activitățile de dezvoltare a sistemului software (etapa 1);

etapa de dezvoltare la care este creat un sistem software:

enunțul problemei (etapa 2),

proiectare (3),

obținerea codului executabil (4.1.1, 4.3);

o etapă integrată care asigură corectarea, verificarea și determinarea completității sistemului software, precum și lansarea acestuia. Această etapă include verificarea, monitorizarea configurației sistemului, evaluarea calității și verificarea interacțiunii dintre etape. Din denumirea acestei etape este clar că se realizează împreună cu alte etape de-a lungul ciclului de viață al sistemului.

Orez. 1.2 Opțiune pentru un ciclu de viață simplificat al unui sistem software.

Absența unei etape integrate în ciclul general de viață nu înseamnă că verificarea se efectuează numai acolo unde acest lucru este clar indicat în denumirea etapei (de exemplu, 4.2.1 și 4.2). Fiecare etapă poate fi considerată finalizată doar atunci când rezultatele obținute în această etapă sunt considerate satisfăcătoare, iar pentru aceasta este necesară verificarea rezultatelor la fiecare etapă. În rezumatul ciclului de viață, unele verificări au fost evidențiate ca elemente separate pentru a demonstra volumul crescut, complexitatea și importanța acestor verificări.

Secvența etapelor ciclului de viață pentru diferite sisteme software este determinată de caracteristici precum funcționalitatea, complexitatea, dimensiunea, stabilitatea, utilizarea rezultatelor obținute anterior, strategia în curs de dezvoltare și hardware-ul.

În fig. 1.3. arată secvența etapelor de dezvoltare a software-ului pentru componente individuale ale unui singur sistem software cu cicluri de viață diferite.

Orez. 1.3 Secvența etapelor de dezvoltare a componentelor software

Pentru componenta W, din setul de cerințe de sistem pentru un singur produs, se formează un subset de cerințe legate de această componentă, aceste cerințe sunt utilizate la formarea unui proiect pentru o componentă software, acest proiect este implementat în codul sursă și apoi componenta este integrată cu hardware-ul. Componenta X arată utilizarea software-ului dezvoltat anterior. Componenta Y arată utilizarea unei singure funcții simple care poate fi codificată direct pe baza cerințelor software. Componenta Z arată utilizarea strategiei prototip. De obicei, obiectivele prototipării sunt de a înțelege mai bine cerințele software și de a reduce riscurile tehnice și de dezvoltare în crearea produsului final. Cerințele inițiale sunt folosite ca bază pentru obținerea unui prototip. Acest prototip este convertit într-un mediu tipic pentru dezvoltarea specifică a sistemului. Rezultatul transformării sunt date rafinate care sunt utilizate pentru a crea produsul software final.

Aproape toate etapele ciclului de viață sunt combinate cu verificarea.

Dezvoltarea software-ului este imposibilă fără înțelegerea așa-numitului ciclu de viață al software-ului. Este posibil ca utilizatorul mediu să nu aibă nevoie să știe acest lucru, dar este recomandabil să stăpânească standardele de bază (mai târziu se va spune de ce este necesar acest lucru).

Ce este ciclul de viață într-un sens formal?

Ciclul de viață al oricărei aplicații este de obicei înțeles ca momentul existenței acesteia, începând din stadiul de dezvoltare și până în momentul abandonării complete a utilizării în domeniul de aplicare ales, până la retragerea completă a aplicației din utilizare.

În termeni simpli, sistemele informaționale sub formă de programe, baze de date sau chiar „sisteme de operare” sunt solicitate doar dacă datele și oportunitățile pe care le oferă sunt la zi.

Se crede că definiția ciclului de viață nu se aplică în niciun fel aplicațiilor de testare, cum ar fi versiunile beta, care sunt cele mai instabile în funcționare. Ciclul de viață al software-ului în sine depinde de mulți factori, printre care unul dintre rolurile principale este jucat de mediul în care programul va fi utilizat. Cu toate acestea, este posibil să se identifice condițiile generale utilizate în definirea conceptului de ciclu de viață.

Cerințe inițiale

• enunțul problemei;
• analiza cerințelor reciproce ale viitorului software pentru sistem;
• proiecta;
• programare;
• codificare și compilare;
• testare;
• depanare;
• implementarea și întreținerea produsului software.

Dezvoltarea software constă din toate etapele menționate mai sus și nu se poate face fără cel puțin una dintre ele. Dar au fost stabilite standarde speciale pentru controlul unor astfel de procese.

Standarde de proces pentru ciclul de viață al software-ului

Printre sistemele care predetermină condițiile și cerințele pentru astfel de procese, astăzi putem numi doar trei principale:

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

Pentru al doilea standard internațional există un analog rusesc. Acesta este GOST R ISO/IEC 12207-2010, care este responsabil pentru ingineria sistemului și a software-ului. Dar ciclul de viață al software-ului descris în ambele reguli este în esență identic. Acest lucru este explicat destul de simplu.

Tipuri de software și actualizări

Apropo, pentru majoritatea programelor multimedia cunoscute în prezent, acestea reprezintă un mijloc de salvare a parametrilor de configurare de bază. Utilizarea software-ului de acest tip este, desigur, destul de limitată, dar înțelegerea principiilor generale de lucru cu aceleași playere media nu va strica. Și iată de ce.

De fapt, acestea includ ciclul de viață al software-ului doar la nivelul actualizării versiunii playerului propriu-zis sau al instalării de codecuri și decodore. Și transcodificatoarele audio și video sunt atribute integrante ale oricărui sistem audio sau video.

Exemplu bazat pe FL Studio

Inițial, studioul-sequencer virtual FL Studio se numea Fruity Loops. Ciclul de viață al software-ului în modificarea sa inițială a expirat, dar aplicația a fost oarecum transformată și a căpătat forma actuală.

Dacă vorbim despre etapele ciclului de viață, mai întâi, în etapa de stabilire a problemei, au fost stabilite câteva condiții obligatorii:

• crearea unui modul de tobe similar cu aparatele de ritm precum Yamaha RX, dar folosind mostre sau secvențe one-shot în format WAV înregistrate live în studiouri;
• integrare în sistemele de operare Windows;
• capacitatea de a exporta un proiect în formate WAV, MP3 și OGG;
• Compatibilitatea proiectelor cu aplicația suplimentară Fruity Tracks.

În stadiul de dezvoltare, s-au folosit instrumentele limbajului de programare C. Dar platforma arăta destul de primitivă și nu a oferit utilizatorului final calitatea necesară a sunetului.

În acest sens, în etapa de testare și depanare, dezvoltatorii au trebuit să urmeze calea corporației germane Steinberg și să aplice suport pentru modul Full Duplex în cerințele pentru driverul de sunet principal. Calitatea sunetului a devenit mai mare și vă permite să schimbați tempo-ul, înălțimea și să adăugați efecte FX suplimentare în timp real.

Sfârșitul ciclului de viață al acestui software este considerat a fi lansarea primei versiuni oficiale a FL Studio, care, spre deosebire de strămoșii săi, avea deja interfața unui secvențior cu drepturi depline, cu capacitatea de a edita parametrii pe un 64 virtual. -consola de mixare a canalelor cu adăugare nelimitată de piese audio și piese MIDI.

Nu s-a oprit aici. În etapa de management al proiectului, a fost introdus suport pentru conectarea plug-in-urilor în format VST (mai întâi a doua, apoi a treia versiune), care a fost odată dezvoltată de Steinberg. În linii mari, orice sintetizator virtual care acceptă VST-host se poate conecta la program.

Nu este surprinzător că în curând orice compozitor ar putea folosi analogi ale modelelor „hardware”, de exemplu, seturi complete de sunete ale odată popularul Korg M1. Mai departe - mai mult. Utilizarea modulelor precum Addictive Drums sau pluginul universal Kontakt a făcut posibilă reproducerea sunetelor live ale instrumentelor reale înregistrate cu toate nuanțele de articulație în studiouri profesionale.

În același timp, dezvoltatorii au încercat să obțină o calitate maximă prin crearea de suport pentru driverele ASIO4ALL, care s-au dovedit a fi cu cap și umeri deasupra modului Full Duplex. În consecință, a crescut și rata de biți. Astăzi, calitatea fișierului audio exportat poate fi de 320 kbps la o rată de eșantionare de 192 kHz. Și acesta este sunet profesional.

În ceea ce privește versiunea inițială, ciclul său de viață ar putea fi numit complet complet, dar o astfel de declarație este relativă, deoarece aplicația și-a schimbat doar numele și a dobândit noi capabilități.

Perspective de dezvoltare

Care sunt etapele ciclului de viață al software-ului este deja clar. Dar dezvoltarea unor astfel de tehnologii merită menționată separat.

Inutil să spun că orice dezvoltator de software nu este interesat să creeze un produs trecător care este puțin probabil să supraviețuiască pe piață timp de câțiva ani. Pe termen lung, toată lumea se uită la utilizarea sa pe termen lung. Acest lucru poate fi realizat în diferite moduri. Dar, de regulă, aproape toate se reduc la lansarea de actualizări sau versiuni noi de programe.

Chiar și în cazul sistemului de operare Windows, astfel de tendințe pot fi observate cu ochiul liber. Este puțin probabil ca astăzi să existe cel puțin un utilizator care folosește sisteme precum modificările 3.1, 95, 98 sau Millennium. Ciclul lor de viață s-a încheiat după lansarea XP. Dar versiunile de server bazate pe tehnologii NT sunt încă relevante. Chiar și Windows 2000 astăzi nu este doar foarte relevant, dar în anumite parametri de instalare sau de securitate depășește chiar și cele mai recente evoluții. Același lucru este valabil și pentru sistemul NT 4.0, precum și pentru o modificare specializată a Windows Server 2012.

Dar în legătură cu aceste sisteme, suportul este încă declarat la cel mai înalt nivel. Dar odinioară senzațională Vista se confruntă în mod clar cu declinul ciclului său. Nu numai că s-a dovedit a fi neterminat, dar au existat și atât de multe erori în ea și lacune în sistemul său de securitate, încât se poate doar ghici cum o astfel de soluție insuportabilă ar putea fi lansată pe piața de software.

Dar dacă spunem că dezvoltarea software-ului de orice tip (de control sau aplicație) nu stă pe loc, putem spune doar că astăzi se referă nu numai la sisteme informatice, ci și la dispozitive mobile, în care tehnologiile folosite sunt deseori înaintea sectorul calculatoarelor. Apariția cipurilor de procesor bazate pe opt nuclee nu este cel mai bun exemplu? Dar nu orice laptop se poate lăuda cu un astfel de hardware.

Câteva întrebări suplimentare

În ceea ce privește înțelegerea ciclului de viață al software-ului, se poate spune foarte condiționat că acesta s-a încheiat la un anumit moment în timp, deoarece produsele software au în continuare suport de la dezvoltatorii care le-au creat. Mai degrabă, finalul se referă la aplicații vechi care nu îndeplinesc cerințele sistemelor moderne și nu pot rula în mediul lor.

Dar chiar și ținând cont de progresul tehnologic, multe dintre ele pot deveni în curând insuportabile. Apoi va trebui să luați o decizie fie de a lansa actualizări, fie de a revizui complet întregul concept încorporat inițial în produsul software. De aici și noul ciclu, care presupune schimbarea condițiilor inițiale, a mediului de dezvoltare, testare și posibilă utilizare pe termen lung într-o anumită zonă.

Dar în tehnologia informatică astăzi se preferă dezvoltarea sistemelor de control automate (ACS), care sunt utilizate în producție. Chiar și sistemele de operare, în comparație cu programele specializate, pierd.

Aceleași medii bazate pe Visual Basic rămân mult mai populare decât sistemele Windows. Și nu vorbim deloc despre aplicații software pentru sisteme UNIX. Ce putem spune dacă aproape toate rețelele de comunicații ale acelorași Statele Unite ale Americii funcționează exclusiv pentru ei. Apropo, sisteme precum Linux și Android au fost create inițial pe această platformă. Prin urmare, cel mai probabil, UNIX are mult mai multe perspective decât alte produse combinate.

În loc de un total

Rămâne de adăugat că în acest caz sunt date doar principiile generale și etapele ciclului de viață al software-ului. De fapt, chiar și sarcinile stabilite inițial pot varia foarte semnificativ. În consecință, diferențele pot fi observate în alte etape.

Dar tehnologiile de bază pentru dezvoltarea produselor software și suportul lor ulterior ar trebui să fie clare. În rest, ar trebui să se țină cont de specificul software-ului creat, de mediile în care ar trebui să funcționeze și de capacitățile programelor furnizate utilizatorului final sau producției și multe altele.

În plus, uneori ciclurile de viață pot depinde de relevanța instrumentelor de dezvoltare. Dacă, de exemplu, un limbaj de programare devine învechit, nimeni nu va scrie programe bazate pe el, cu atât mai puțin le va implementa în sistemele automate de control al producției. Aici nici măcar programatorii ies în prim-plan, ci marketerii trebuie să răspundă în timp util la schimbările de pe piața calculatoarelor. Și nu există atât de mulți astfel de specialiști în lume. Personalul cu înaltă calificare care poate ține degetul pe pulsul pieței devine cel mai solicitat. Și ei sunt adesea așa-numiții „cardinali gri” de care depinde succesul sau eșecul unui anumit produs software în domeniul IT.

S-ar putea să nu înțeleagă întotdeauna esența programării, dar sunt în mod clar capabili să determine modele ale ciclului de viață al software-ului și durata utilizării lor, pe baza tendințelor globale în acest domeniu. Un management eficient produce adesea rezultate mai tangibile. Da, cel puțin tehnologii de PR, publicitate etc. Este posibil ca utilizatorul să nu aibă nevoie de vreo aplicație, dar dacă este promovată activ, utilizatorul o va instala. Acesta este deja, ca să spunem așa, un nivel subconștient (același efect al celui de-al 25-lea cadru, când informația este introdusă în conștiința utilizatorului independent de el).

Desigur, astfel de tehnologii sunt interzise în lume, dar mulți dintre noi nici nu realizează că ele pot fi încă folosite și influențează subconștientul într-un anumit fel. Priviți doar costul „zombificării” de către canalele de știri sau site-urile de internet, ca să nu mai vorbim de utilizarea unor mijloace mai puternice, cum ar fi expunerea la infrasunete (aceasta a fost folosită într-o producție de operă), în urma cărora o persoană poate experimenta frică sau emoții nepotrivite.

Revenind la software, merită adăugat că unele programe folosesc un semnal sonor la pornire pentru a atrage atenția utilizatorului. Și, după cum arată cercetările, astfel de aplicații sunt mai viabile decât alte programe. Desigur, și ciclul de viață al software-ului crește, indiferent de funcția care i-a fost atribuită inițial. Și, din păcate, mulți dezvoltatori folosesc acest lucru, ceea ce ridică îndoieli cu privire la legalitatea unor astfel de metode.

Dar nu este de la noi să judecăm asta. Este posibil ca în viitorul apropiat să fie dezvoltate instrumente pentru a identifica astfel de amenințări. Până acum aceasta este doar o teorie, dar, potrivit unor analiști și experți, mai rămâne foarte puțin până la aplicarea practică. Dacă ei creează deja copii ale rețelelor neuronale ale creierului uman, atunci ce putem spune?

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:

1. Abordare inginerească
2. Ținând cont de specificul sarcinii
3. 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:

1. Enunțarea problemei
2. Execuţie
3. Verificarea rezultatului
4. 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 utilizat la începutul ciclului de viață al software-ului:

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

Clasificarea prototipurilor:

1. Orizontală și verticală
2. De unică folosință și evolutiv
3. 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.

Vă mulțumesc foarte mult pentru atenție!

Ciclul de viață al programului.

Ciclul de viață al software-ului este o perioadă de timp care începe din momentul în care se ia o decizie cu privire la necesitatea de a crea un produs software și se termină când acesta este complet scos din serviciu. Acest ciclu este procesul de construire și dezvoltare a software-ului.

Etapele ciclului de viață:

2. Design

3. Implementare

4. Asamblare, testare, testare

5. Implementare (lansare)

6. Escortă

Există 2 cazuri de producție de software: 1) Software-ul este realizat pentru un anumit client. În acest caz, trebuie să transformați sarcina aplicată într-una de programare. Trebuie să înțelegeți cum funcționează mediul care trebuie automatizat (analiza procesului de afaceri). Ca urmare, apare o specificație a documentației cerinței, care indică sarcinile specifice care trebuie efectuate. rezolvate si in ce conditii. Această activitate este efectuată de un analist de sisteme (analist de procese de afaceri).

2) Software-ul este dezvoltat pentru piață. Trebuie să efectuați cercetări de marketing și să găsiți ce produs nu este pe piață. Acest lucru vine cu o mulțime de riscuri. Scopul este de a dezvolta o specificație de cerințe.

Proiecta

Scopul este de a determina structura generală (arhitectura) software-ului. Rezultatul este o specificație software. Această activitate este efectuată de un programator de sistem.

Implementarea

Scrierea codului programului. Implementarea include dezvoltarea, testarea și documentarea.

Asamblare, testare, testare

O compilație a tot ceea ce este realizat de diferiți programatori. Testarea întregului pachet software. Depanare – găsirea și eliminarea cauzelor erorilor. Testare – clarificarea caracteristicilor tehnice. Drept urmare, programul este garantat să funcționeze.

Implementare (lansare)

Implementare – atunci când lucrează pentru un singur client. Include configurarea unui program la sediul clientului, instruirea clientului, consultații, eliminarea erorilor și a deficiențelor evidente. Software-ul trebuie să fie înstrăinat - utilizatorul poate lucra cu software-ul fără participarea autorului.

Lansare – când software-ul este dezvoltat pentru piață. Începe cu etapa de testare beta. Resp. versiune - versiune beta. Testarea Alpha este testarea de către persoane din aceeași organizație care nu au fost implicate în dezvoltarea programelor. Testarea beta este producerea mai multor copii ale software-ului și trimiterea către potențiali clienți. Scopul este de a verifica din nou dezvoltarea software-ului.

Dacă pe piață este lansat un software fundamental nou, atunci sunt posibile mai multe teste beta. După testarea beta - lansarea unei versiuni comerciale.

Escorta

Eliminarea erorilor observate în timpul funcționării. Efectuarea de îmbunătățiri neesențiale. Acumularea de propuneri pentru dezvoltarea versiunii următoare.

Modele de ciclu de viață

1. Cascada („cascada”, model în cascadă)

2. Prototiparea

În primul rând, nu produsul software în sine este dezvoltat, ci prototipul său, care conține o soluție la principalele probleme cu care se confruntă dezvoltatorii. După finalizarea cu succes a dezvoltării prototipului, produsul software real este dezvoltat folosind aceleași principii. Un prototip vă permite să înțelegeți mai bine cerințele pentru programul în curs de dezvoltare. Folosind un prototip, clientul își poate formula și mai precis cerințele. Dezvoltatorul are posibilitatea, folosind un prototip, de a prezenta clientului rezultatele preliminare ale muncii sale.

3. Model iterativ

Sarcina este împărțită în subsarcini și ordinea implementării lor este determinată astfel încât fiecare subsarcină ulterioară să extindă capacitățile software-ului. Succesul depinde în mod semnificativ de cât de bine sunt împărțite sarcinile în subsarcini și de modul în care este aleasă ordinea. Avantaje: 1) posibilitatea de participare activă a clientului la dezvoltare, acesta având posibilitatea de a-și clarifica cerințele în timpul dezvoltării; 2) capacitatea de a testa piese nou dezvoltate împreună cu cele dezvoltate anterior, aceasta va reduce costul depanării complexe; 3) în timpul dezvoltării, puteți începe implementarea în părți.

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 și 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:

1. 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
2. Dezvoltarea conceptului AC
   1. Studiind obiectul
   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ă
3. Termeni de referință
   1. Elaborarea și aprobarea specificațiilor tehnice pentru realizarea centralelor nucleare
4. Proiect de proiect
   1. Dezvoltarea de soluții preliminare de proiectare pentru sistem și părțile sale
5. 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
6. Documentatie de lucru
   1. Elaborarea documentației de lucru pentru CNE și părțile sale
   2. Dezvoltarea și adaptarea programelor
7. Punerea în funcțiune
   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
8. 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:

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

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

1. Formarea cerințelor de sistem
2. Generarea unei liste de produse software
3. Stabilirea termenilor si acordurilor
4. 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:

1. Etape;
2. Rezultatele muncii în fiecare etapă;
3. 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 în conexiunea informațională a componentelor individuale. De regulă, pe măsură ce numărul sarcinilor 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 cascadei:

1. Formarea cerințelor;
2. Proiecta;
3. Implementare;
4. Testare;
5. Implementare;
6. 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ă ce lucrările la sistem sunt complet finalizate. 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, acest model are principalul avantaj al dezvoltării sistematice, iar principalele dezavantaje sunt că este lent și costisitor.

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

O posibilă abordare a 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;

• faza 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 sunt 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 eficiență, 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.