Ciclul de viață al aplicației. Ciclul de viață al programului

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 in timpul functionarii. Realizarea 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.

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. Formularea problemei
2. Performanţă
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 utilizate în primele etape ale 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.

Mulțumesc foarte mult pentru atenț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

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

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.

Î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 pentru proiectarea atentă a software-ului: 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ă utilizeze 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ă se concentrează 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 verbosă și greu de înțeles. Prin urmare, D. Riley sugerează utilizarea unui formular standard pentru a seta problema, care asigură acuratețea, completitudinea, claritatea maximă ș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ă.

Î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 dezvoltării conceptului inițial al sistemului ș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 anumit 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-unul sau altul 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 că împărțirea ciclului de viață în etape ajută uneori la ascunderea unor aspecte importante ale creării de 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 interne (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 pentru a asigura executarea 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. Se stabilește ce ar trebui să facă sistemul și cum ar trebui să o facă.

Analiza cerințelor de sistem (2.2). Descrie modul în care solicitările utilizatorului trebuie satisfăcute, în ceea ce privește conceptele funcționale specifice, sunt descrise acțiunile sistemului propus, datele stocate, interfața utilizată - toate acestea fără a ține cont de implementarea fizică. Adecvarea acestor concepte specifice este testată.

Proiectarea sistemului (3.1). Structura sistemului sau, cu alte cuvinte, arhitectura acestuia este stabilită prin prisma principalelor componente ale acestui sistem și implementarea preconizată a acestora (hardware, software, utilizarea mediului etc.). Sunt stabilite cerințe pentru fiecare componentă, precum și o strategie de testare și integrare.

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 folosirea 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. Putem distinge următoarele etape ale ciclului de viață al sistemelor software (în paranteze, ca și înainte, sunt analogi din 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),

codificare (4.1.1),

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ă, iar 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

• formularea 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. Si de aceea.

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 ridicată și vă permite să schimbați tempo-ul, înălțimea și să aplicaț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 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 nesustenabilă 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, este destul de arbitrar să spunem că acesta s-a încheiat la un anumit moment în timp, deoarece produsele software încă beneficiază de sprijin 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.

Mediile 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 de timp pentru utilizarea 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 realizăm 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?