Ciclul de viață al software-ului. Etape și etape. Ciclul de viață al sistemelor software Conceptul de ciclu de viață al unui program și etapele sale

Dezvoltarea tehnologiei informatice extinde constant clasele de probleme rezolvabile legate de prelucrarea informațiilor de diferite tipuri.

Acestea sunt, practic, trei tipuri de informații și, în consecință, trei clase de probleme pentru care sunt utilizate computerele:

1) Probleme de calcul legate de prelucrarea informaţiei numerice. Acestea includ, de exemplu, problema rezolvării unui sistem de ecuații liniare de dimensiuni mari. Anterior, era principala zonă dominantă de utilizare a computerului.

2) Sarcini simbolice de prelucrare a informațiilor legate de crearea, editarea și transformarea datelor text. Rezolvarea unor astfel de probleme implică munca, de exemplu, a unei secretare-dactilografe.

3) Sarcini de prelucrare a informațiilor grafice ᴛ.ᴇ. diagrame, desene, grafice, schițe etc. Astfel de sarcini includ, de exemplu, sarcina unui proiectant care dezvoltă desene pentru produse noi.

4) Sarcini de prelucrare a informațiilor alfanumerice - IS. Astăzi a devenit unul dintre domeniile de bază ale aplicației computerizate, iar sarcinile devin din ce în ce mai complexe.

Rezolvarea problemelor fiecărei clase pe computer are propriile sale specificități, dar poate fi împărțită în mai multe etape caracteristice majorității problemelor.

Tehnologia de programarestudiază procesele tehnologice și ordinea parcurgerii lor (etape) folosind cunoștințe, metode și instrumente.

Este convenabil să se caracterizeze tehnologiile în două dimensiuni – verticală (reprezentând procese) și orizontală (reprezentând etape).

Desen

Un proces este un set de acțiuni interconectate (operații tehnologice) care transformă unele date de intrare în date de ieșire. Procesele constau dintr-un set de acțiuni (operații tehnologice), iar fiecare acțiune constă dintr-un set de sarcini și metode de rezolvare a acestora. Dimensiunea verticală reflectă aspectele statice ale proceselor și operează cu concepte precum procesele de lucru, acțiunile, sarcinile, rezultatele performanței, performanții.

O etapă este o parte a activităților de creare de software, limitată de un anumit interval de timp și care se termină cu lansarea unui anumit produs, determinată de cerințele specificate pentru această etapă. Uneori, etapele sunt combinate în intervale de timp mai mari numite faze sau etape. Deci, dimensiunea orizontală reprezintă timpul, reflectă aspectele dinamice ale proceselor și operează cu concepte precum faze, etape, etape, iterații și puncte de control.

Dezvoltarea software-ului urmează un ciclu de viață specific.

Ciclu de viață Software-ul este un set continuu și ordonat de activități desfășurate și gestionate în cadrul fiecărui proiect de dezvoltare și exploatare a software-ului, începând din momentul în care apare ideea (planul) de creare a unui software și se ia o decizie cu privire la importanța critică. de crearea sa și încetarea în momentul retragerii sale complete din serviciu din următoarele motive:

a) uzura;

b) pierderi de extremă importanţă în rezolvarea problemelor relevante.

Abordări tehnologice – mecanisme de implementare ciclu de viață.

Abordarea tehnologică este determinată de combinația specifică de etape și procese, axate pe diferite clase Software-ul și caracteristicile echipei de dezvoltare.

Ciclul de viață definește etape (faze, etape), astfel încât un produs software trece de la o etapă la alta, începând de la începutul conceptului de produs și terminând cu etapa colapsului acestuia.

Ciclul de viață al dezvoltării software ar trebui să fie prezentat cu diferite grade de detaliere a etapelor. Cea mai simplă reprezentare a ciclului de viață include etapele:

Proiecta

Implementarea

Testare și depanare

Implementare, operare si intretinere.

Cea mai simplă reprezentare a unui program de ciclu de viață (abordare tehnologică în cascadă a managementului ciclului de viață):

Procesele

Proiecta

Programare

Testare

Escorta

Analiză Proiectare Implementare Testare Implementare Operație

și depanare și întreținere

De fapt, există un singur proces efectuat la fiecare etapă. Este evident că atunci când se dezvoltă și se creează programe mari Această schemă nu este suficient de corectă (inaplicabilă), dar poate fi luată ca bază.

etapa Aaliz se concentrează pe cerințele de sistem. Cerințele sunt definite și specificate (descrise). Se realizează dezvoltarea și integrarea modelelor funcționale și modelelor de date pentru sistem. În același timp, sunt înregistrate cerințele nefuncționale și alte cerințe de sistem.

Faza de proiectare este împărțită în două subfaze de bază: proiectare arhitecturală și proiectare de detaliu. În special, designul programului, interfața cu utilizatorul și structurile de date sunt în curs de perfecționare. Problemele de proiectare care afectează înțelegerea, mentenabilitatea și scalabilitatea sistemului sunt ridicate și documentate.

Etapa de implementare include scrierea unui program.

Diferențele de hardware și software sunt vizibile în special la scenă operare. Dacă bunurile de larg consum trec prin etapele de introducere pe piață, creștere, maturitate și declin, atunci viața software-ului seamănă mai mult cu istoria unei clădiri (avion) ​​neterminate, dar în curs de finalizare și actualizare constantă. (Abonat).

Ciclul de viață al software-ului este reglementat de multe standarde, inclusiv și internaționale.

Scopul standardizării ciclurilor de viață ale stațiilor complexe:

Generalizarea experienței și a rezultatelor cercetării multor specialiști;

Se lucrează procese tehnologiceși tehnici de dezvoltare, precum și o bază metodologică pentru automatizarea acestora.

Standardele includ:

Reguli de descriere a informațiilor inițiale, metode și metode de efectuare a operațiunilor;

Stabilirea regulilor de monitorizare a proceselor tehnologice;

Stabilirea cerințelor pentru prezentarea rezultatelor;

Reglementează conținutul documentelor tehnologice și operaționale;

Defini structura organizatorica echipa de dezvoltare;

Asigura distributia si planificarea sarcinilor;

Asigurați controlul asupra progresului creării PS.

În Rusia există standarde care reglementează ciclul de viață:

Etapele dezvoltării software – GOST 19.102-77

Etapele creării AS - GOST 34.601 –90;

Specificații tehnice pentru crearea AS - GOST 34.602-89;

Tipuri de testare AC - GOST 34.603-92;

În același timp, crearea, întreținerea și dezvoltarea de aplicații software pentru sistemele informaționale nu se reflectă suficient în aceste standarde, iar unele dintre prevederile acestora sunt depășite din punctul de vedere al construirii complexelor moderne de programe de aplicații distribuite. calitate superioarăîn sisteme de control şi prelucrare a datelor cu arhitecturi diverse.

În acest sens, este de remarcat standardul internațional ISO/IEC 12207-1999 – „Tehnologia informației – Procesele ciclului de viață al software-ului”.

ISO - Organizația Internațională de Standardizare - Organizație internațională privind standardizarea, IEC - International Electrotechnical Commission - International Commission on Electrical Engineering.

Acesta definește structura ciclului de viață al software-ului și procesele acestuia.

Aceste. crearea de software nu este așa sarcină simplă, în legătură cu aceasta, există standarde în care totul este descris: ce trebuie făcut, când și cum.

Structura ciclului de viață al software-ului conform standardului internațional ISO/IEC 12207-95 se bazează pe trei grupuri de procese:

1) principalele procese ale ciclului de viață al software-ului (cumpărare, livrare, dezvoltare, operare, întreținere). Ne vom concentra pe acesta din urmă.

2) procese auxiliare care asigură executarea procese de bază (documentare, managementul configurației, asigurarea calității, verificare, certificare, analiză comună (evaluare), audit, rezolvare de probleme).

1. Managementul configurațieiAcest un proces care susține principalele procese ale ciclului de viață al software-ului, în primul rând procesele de dezvoltare și întreținere. Atunci când se dezvoltă proiecte software complexe constând din mai multe componente, fiecare dintre acestea putând avea variații sau versiuni, apare problema luării în considerare a conexiunilor și funcțiilor acestora, crearea unei structuri unificate (ᴛ.ᴇ. unificate) și asigurarea dezvoltării întregului sistem. . Managementul configurației vă permite să organizați, să luați în considerare sistematic și să controlați modificările la diferite componente software în toate etapele ciclului său de viață.

2. Verificare este procesul prin care se determină dacă starea curentă a software-ului atinsă într-o anumită etapă îndeplinește cerințele acelei etape.

3. Certificare– confirmarea prin examinare și prezentare de dovezi obiective că cerințele specifice pentru anumite obiecte sunt pe deplin implementate.

4. Analiză comună (evaluare) – determinarea sistematică a gradului de conformitate a unui obiect cu criteriile stabilite.

5. Audit– o verificare efectuată de o autoritate (persoană) competentă pentru a se asigura evaluare independentă gradul de conformitate al produselor sau proceselor software cerințele stabilite. Examinare vă permite să evaluați conformitatea parametrilor de dezvoltare cu cerințele inițiale. Verificarea coincide parțial cu testarea este efectuată pentru a determina diferențele dintre rezultatele reale și cele așteptate și pentru a evalua conformitatea caracteristicilor software cu cerințele originale. În procesul de implementare a proiectului, problemele de identificare, descriere și control al configurației componentelor individuale și a întregului sistem în ansamblu ocupă un loc important.

3) procese organizatorice (managementul de proiect, crearea infrastructurii proiectului, definirea, evaluarea si imbunatatirea ciclului de viata in sine, instruire).

Management de proiect asociate cu probleme de planificare și organizare a muncii, crearea de echipe de dezvoltare și monitorizarea timpului și a calității muncii efectuate. Sprijinul tehnic și organizatoric al proiectului include selecția metodelor și instrumentelor pentru implementarea proiectului, determinarea metodelor de descriere a stărilor intermediare de dezvoltare, dezvoltarea metodelor și instrumentelor de testare a software-ului creat, pregătirea personalului etc. Asigurarea calității proiectului este asociată cu probleme de verificare, verificare și testare a componentelor software.

Vom lua în considerare ciclul de viață al software-ului din punctul de vedere al dezvoltatorului.

Procesul de dezvoltare în conformitate cu standardul implică acțiuni și sarcini efectuate de dezvoltator și acoperă lucrările de creare a software-ului și a componentelor acestuia în conformitate cu cerințele specificate, inclusiv pregătirea documentației de proiectare și operaționale, precum și pregătirea materialelor necesare pentru testarea funcționalității și conformității calității produselor software, materialelor necesare pregătirii personalului etc.

Conform standardului, ciclul de viață al software-ului IS include următoarele acțiuni:

1) apariția și cercetarea unei idei (plan);

2) etapa pregătitoare - alegerea unui model de ciclu de viață, standarde, metode și instrumente de dezvoltare, precum și întocmirea unui plan de lucru.

3) analiza cerintelor sistemului informatic - definindu-l

funcţionalitate, cerințele utilizatorului, cerințele de fiabilitate și securitate, cerințele pentru interfețe externe etc.

4) proiectarea arhitecturii sistemelor informatice - Determinarea compoziției echipamentelor, software-ului și operațiunilor critice efectuate de personalul de întreținere.

5) analiza cerințelor software- Definirea funcționalității, inclusiv caracteristicile de performanță, mediul de operare al componentelor, interfețele externe, specificațiile de fiabilitate și siguranță, cerințe ergonomice, cerințe de date, instalare, acceptare, documentație pentru utilizator, operare și întreținere.

6) proiectarea arhitecturii software - definirea structurii software, documentarea interfețelor componentelor sale, elaborarea unei versiuni preliminare a documentației utilizator, precum și a cerințelor de testare și a unui plan de integrare.

7) proiectare detaliată a software-ului - detaliat

descrierea componentelor software și a interfețelor dintre acestea, actualizarea documentației utilizatorului, dezvoltarea și documentarea cerințelor de testare și a unui plan de testare, componente software, actualizarea planului de integrare a componentelor.

8) codare software -– dezvoltare și documentare

fiecare componentă software;

9)testarea software-ului – dezvoltarea unui set de proceduri de testare și date pentru testarea acestora, testarea componentelor, actualizarea documentației utilizatorului, actualizarea planului de integrare software;

10) integrare software–asamblarea componentelor software în conformitate cu

un plan de integrare și testarea software-ului pentru conformitatea cu cerințele de calificare, care sunt un set de criterii sau condiții care sunt extrem de importante de îndeplinit pentru a califica un produs software ca îndeplinește specificațiile sale și gata de utilizare în condiții de operare specificate;

11) testarea calificării software-ului – testarea software-ului în

prezența clientului pentru a demonstra conformitatea acestuia

cerințele și pregătirea pentru funcționare; în același timp, se verifică și gradul de pregătire și caracterul complet al documentației tehnice și de utilizare;

12) integrarea sistemului – asamblarea tuturor componentelor sistemului informatic, inclusiv software și hardware;

13) Testarea calificării IP – testarea sistemului pentru

respectarea cerințelor pentru aceasta și verificarea executării și completității documentației;

14) instalare software – instalarea software-ului pe echipamentul clientului și verificarea funcționalității acestuia;;

15) acceptarea software-ului – evaluarea rezultatelor unui calificat

testarea software-ului și a sistemelor informaționale în ansamblu și

documentarea rezultatelor evaluării împreună cu clientul, certificarea și transferul final al software-ului către client.

16) Gestionarea și elaborarea documentației;

17) funcționare

18) acompaniament – procesul de creare și implementare a noilor versiuni

produs software. ;

19) finalizarea operațiunii.

Aceste acțiuni pot fi grupate în următoarele etape principale ale dezvoltării software:

· expunerea problemei (TOR) (conform GOST 19.102-77 stadiul ʼʼ Termeni de referințăʼʼ)

· analiza cerințelor și elaborarea specificațiilor (conform GOST 19.102-77 etapa ʼʼ Proiect de proiectʼʼ)

· proiectare (conform GOST 19.102-77 etapa „Proiectare tehnică”)

· implementare (codare, testare și depanare) (conform GOST 19.102-77 etapa „Schior detaliat”).

· operare și întreținere.

Ciclul de viață și etapele dezvoltării software - concept și tipuri. Clasificarea și caracteristicile categoriei „Ciclul de viață și etapele dezvoltării software” 2017, 2018.

în inginerie electrică). Acest standard definește o structură a ciclului de viață care conține procesele, activitățile și sarcinile care trebuie finalizate în timpul creării unui sistem software.

În acest standard PS (sau produs software) este definită ca o colecție de programe de calculator, proceduri și, eventual, documentație și date asociate. Un proces este definit ca un set de acțiuni interconectate care transformă unele date de intrare în ieșire (G. Myers numește această traducere a datelor). Fiecare proces este caracterizat de anumite sarcini și metode de rezolvare a acestora. La rândul său, fiecare proces este împărțit într-un set de acțiuni, iar fiecare acțiune într-un set de sarcini. Fiecare proces, acțiune sau sarcină este inițiată și executată de un alt proces după cum este necesar și nu există secvențe de execuție predeterminate (desigur, menținând conexiunile între datele de intrare).

Trebuie remarcat faptul că în Uniunea Sovietică și apoi în Rusia, crearea de software (software) a fost inițial, în anii 70 ai secolului trecut, reglementată de standardele GOST ESPD ( Sistem unificat documentația programului - seria GOST 19.ХХХ), care s-au concentrat pe clasa privind programe simple volum mic creat de programatori individuali. În prezent, aceste standarde sunt depășite din punct de vedere conceptual și din punct de vedere al formei, perioada lor de valabilitate a expirat și utilizarea lor este inadecvată.

Procesele de creare a sistemelor automate (AS), care includ software, sunt reglementate de standardele GOST 34.601-90. Tehnologia de informație. Un set de standarde pentru sisteme automatizate. Etapele creației”, GOST 34.602-89 „Tehnologia informației. Un set de standarde pentru sisteme automate. Termeni de referință pentru crearea unui sistem automatizat” și GOST 34.603-92 „Tehnologia informației. Tipuri de testare a sistemelor automatizate." Cu toate acestea, multe dintre prevederile acestor standarde sunt depășite, iar altele nu sunt suficient de reflectate pentru a fi folosite pentru proiecte serioase de creare a substațiilor. Prin urmare, în dezvoltările interne, este recomandabil să se utilizeze standarde internaționale moderne. .

În conformitate cu standardul ISO / IEC 12207, toate procesele ciclului de viață al software-ului sunt împărțite în trei grupuri (Fig. 5.1).

Orez. 5.1.

Grupurile definesc cinci procese principale: achiziție, livrare, dezvoltare, operare și suport. Opt procese auxiliare asigură executarea proceselor principale, și anume documentare, managementul configurației, asigurarea calitatii, verificarea, certificarea, evaluarea comuna, auditul, rezolvarea problemelor. Patru proces organizatoric asigură management, crearea infrastructurii, îmbunătățirea și formarea.

5.2. Principalele procese ale ciclului de viață PS

Procesul de achiziție constă în acțiunile și sarcinile clientului care achiziționează software-ul. Acest proces acoperă următoarele activități:

1. inițierea achiziției;
2. pregătirea propunerilor de licitație;
3. intocmirea si ajustarea contractului;
4. supravegherea activitatilor furnizorului;
5. acceptarea și finalizarea lucrărilor.

Inițierea unei achiziții include următoarele sarcini:

1. determinarea de către client a nevoilor sale pentru achiziția, dezvoltarea sau îmbunătățirea unui sistem, produse software sau servicii;
2. luarea deciziilor privind achiziția, dezvoltarea sau îmbunătățirea software-ului existent;
3. verificarea disponibilității documentației necesare, garanții, certificate, licențe și suport în cazul achiziționării unui produs software;
4. pregătirea și aprobarea planului de achiziții, inclusiv cerințele de sistem, tipul de contract, responsabilitățile părților etc.

Propunerile de aplicare trebuie să conțină:

1. cerințe pentru sistem;
2. lista de produse software;
3. termenii de achiziție și acord;
4. restricții tehnice (de exemplu, asupra mediului de operare al sistemului).

Ofertele sunt trimise furnizorului selectat sau mai multor furnizori în cazul unei licitații. Un furnizor este o organizație care încheie un contract cu un client pentru furnizarea unui sistem, software sau serviciu software în condițiile specificate în contract.

Pregătirea și ajustarea contractului include următoarele sarcini:

1. determinarea de către client a unei proceduri de selectare a unui furnizor, inclusiv a criteriilor de evaluare a propunerilor de la eventualii furnizori;
2. selectarea unui anumit furnizor pe baza analizei propunerilor;
3. pregătire și încheiere acorduri cu furnizorul;
4. efectuarea de modificări (dacă este necesar) la contract în timpul implementării acestuia.

Supravegherea activităților furnizorului se realizează în conformitate cu acțiunile prevăzute în procesele comune de evaluare și audit. În timpul procesului de acceptare sunt pregătite și efectuate testele necesare. Finalizarea lucrărilor conform contractului se realizează dacă sunt îndeplinite toate condițiile de acceptare.

Procesul de livrare acoperă activitățile și sarcinile efectuate de furnizorul care furnizează clientului un produs sau serviciu software. Acest proces include următorii pași:

1. inițierea livrării;
2. pregătirea unui răspuns la propunerile de licitație;
3. intocmirea contractului;
4. planificarea lucrărilor conform contractului;
5. executarea și controlul lucrărilor contractuale și evaluarea acestora;
6. livrarea si finalizarea lucrarilor.

Inițierea livrării constă în examinarea de către furnizor a ofertelor și decizia dacă este de acord cu cerințele și condițiile menționate sau dacă le oferă propriile lor (de acord). Planificarea include următoarele sarcini:

1. luarea unei decizii de către furnizor cu privire la executarea lucrărilor pe cont propriu sau cu implicarea unui subcontractant;
2. elaborarea de către furnizor a unui plan de management al proiectului care să conțină structura organizatorică a proiectului, delimitarea responsabilităților, cerințe tehnice la mediul și resursele de dezvoltare, managementul subcontractanților etc.

Procesul de dezvoltare implică acțiunile și sarcinile efectuate de dezvoltator și acoperă munca de creare a software-ului și a componentelor acestuia în conformitate cu cerințele specificate. Aceasta include pregătirea documentației de proiectare și operaționale, pregătirea materialelor necesare pentru testarea performanței și calitatea produselor software, materiale necesare organizării pregătirii personalului etc.

Procesul de dezvoltare include următorii pași:

1. munca pregatitoare;
2. analiza cerințelor sistemului;
3. proiectarea arhitecturii sistemului;
4. analiza cerințelor software;
5. proiectarea arhitecturii software;
6. proiectare detaliată a software-ului;
7. codificare și testare software;
8. integrare software;
9. testarea calificării software-ului;
10. integrarea sistemului;
11. testarea calificării sistemului;
12. instalare de software;
13. acceptarea software-ului.

Munca pregătitoare începe cu selectarea unui model de ciclu de viață al software-ului corespunzător amplorii, semnificației și complexității proiectului. Activitățile și sarcinile procesului de dezvoltare trebuie să corespundă modelului ales. Dezvoltatorul trebuie să selecteze, să se adapteze la condițiile proiectului și să utilizeze standarde, metode și instrumente de dezvoltare, precum și întocmirea unui plan de execuție a lucrărilor.

Analiza cerințelor pentru sistem implică determinarea funcționalității acestuia, cerinţele utilizatorului, cerințe de fiabilitate, securitate, cerințe pentru interfețe externe, performanță etc. Cerințele de sistem sunt evaluate pe baza criteriilor de fezabilitate și testabilitate.

Proiectarea arhitecturii unui sistem implică determinarea componentelor hardware (hardware), software-ului și operațiunilor efectuate de personalul care operează sistemul. Arhitectura sistemului trebuie să se conformeze cerințelor sistemului și standardelor și practicilor de proiectare acceptate.

Analiza cerințelor software implică determinarea următoarelor caracteristici pentru fiecare componentă software:

1. funcționalitatea, inclusiv caracteristicile de performanță și mediul de operare al componentei;
2. interfețe externe;
3. specificații de fiabilitate și siguranță;
4. cerințe ergonomice;
5. cerințe pentru datele utilizate;
6. cerințe de instalare și acceptare;
7. cerințe pentru documentația utilizatorului;
8. cerinţele de operare şi întreţinere.

Cerințele software sunt evaluate pe baza criteriilor de conformitate cu cerințele pentru întregul sistem, fezabilitate și testabilitate.

Proiectarea arhitecturii software include următoarele sarcini pentru fiecare componentă software:

1. transformarea cerințelor software într-o arhitectură care definește la un nivel înalt structura software-ului și compoziția componentelor acestuia;
2. dezvoltarea și documentarea interfețelor software și a bazelor de date (DB);
3. dezvoltarea unei versiuni preliminare a documentației utilizatorului;
4. dezvoltarea și documentarea cerințelor preliminare de testare și a planului de integrare software.

Proiectarea detaliată a software-ului include următoarele sarcini:

1. descrierea componentelor software și a interfețelor dintre ele la un nivel inferior suficient pentru codarea și testarea ulterioară;
2. dezvoltarea și documentarea unui proiect detaliat al bazei de date;
3. actualizarea (dacă este necesar) documentația utilizatorului;
4. dezvoltarea și documentarea cerințelor de testare și un plan de testare pentru componentele software;

Codarea și testarea software-ului includ următoarele sarcini:

1. codificarea și documentarea fiecărei componente software și bază de date, precum și pregătirea unui set de proceduri de testare și date pentru testarea acestora;
2. testarea fiecărei componente software și bază de date pentru conformitatea cu cerințele pentru acestea, urmată de documentarea rezultatelor testelor;
3. actualizarea documentației (dacă este necesar);
4. actualizarea planului de integrare software.

Integrarea software implică asamblarea componentelor software dezvoltate în conformitate cu planul de integrare și testare pentru componentele agregate. Pentru fiecare dintre componentele agregate, seturi de testare și proceduri de testare sunt dezvoltate pentru a verifica fiecare dintre cerințele de calificare în timpul testelor de calificare ulterioare. Cerință de calificare este un set de criterii sau condiții care trebuie îndeplinite pentru a se califica produs software ca întrunind specificațiile sale și gata de utilizare în teren.

Testarea calificării software-ului este efectuată de dezvoltator în prezența clientului (

Procesul de operare acoperă activitățile și sarcinile organizației operatorului care operează sistemul. Procesul de operare include următorii pași.

1. Lucrări pregătitoare, care includ operatorul care îndeplinește următoarele sarcini:

   1. planificarea activităților și lucrărilor efectuate în timpul funcționării și stabilirea standardelor operaționale;
   2. determinarea procedurilor de localizare si rezolvare a problemelor aparute in timpul functionarii.
2. Testare operațională efectuată pentru fiecare ediție ulterioară a unui produs software, după care această ediție este pusă în funcțiune.
3. Funcționarea efectivă a sistemului, care se realizează în mediul destinat pentru aceasta în conformitate cu documentația utilizatorului.
4. analiza problemelor și solicitărilor de modificare a software-ului (analiza mesajelor despre o problemă sau cerere de modificare, evaluarea scalei, costul modificării, efectul rezultat, evaluarea fezabilității modificării);
5. modificarea software-ului (efectuarea de modificări la componentele produsului software și la documentație în conformitate cu regulile procesului de dezvoltare);
6. verificarea și acceptarea (din punct de vedere al integrității sistemului modificat);
7. transferul de software într-un alt mediu (conversia programelor și datelor, operarea paralelă a software-ului în mediul vechi și nou pentru o anumită perioadă de timp);
8. scoaterea din funcțiune a software-ului prin decizia clientului cu participarea organizației de exploatare, a serviciului de asistență și a utilizatorilor. În acest caz, produsele software și documentația sunt supuse arhivării în conformitate cu acordul.

Conceptul de ciclu de viață al software-ului (SOLC) este unul dintre cele de bază în ingineria software. Ciclu de viață definită ca perioada de timp care începe din momentul în care se ia o decizie cu privire la necesitatea creării unui software și se termină în momentul în care acesta este complet scos din serviciu.

În conformitate cu standardul ISO/IEC 12207, toate procesele ciclului de viață sunt împărțite în trei grupuri (Fig. 2.1).

Sub modelul ciclului de viață Software-ul este înțeles ca o structură care determină succesiunea execuției și relațiile proceselor, acțiunilor și sarcinilor de-a lungul ciclului de viață. Depinde de specificul, amploarea și complexitatea proiectului și de condițiile specifice în care este creat și funcționează sistemul. Ciclul de viață al software-ului include de obicei următoarele etape:

1. Formarea cerințelor software.

2. Design.

3. Implementare.

4. Testare.

5. Punerea în funcţiune.

6. Operare și întreținere.

7. Dezafectarea.

În prezent, următoarele modele principale ale ciclului de viață al software-ului sunt cele mai utilizate:

a) cascadă și

b) spirală (evolutivă).

Primul a fost folosit pentru programe mici care constituie un singur întreg. Caracteristica fundamentală abordare în cascadă este că trecerea la următoarea etapă se efectuează numai după finalizarea completă a lucrării la cea actuală și nu se oferă nicio revenire la etapele finalizate. Diagrama sa este prezentată în Fig. 2.2.

Avantajele utilizării modelului în cascadă sunt următoarele:

La fiecare etapă se formează un set complet documentatia proiectului;

Etapele lucrărilor care se desfășoară fac posibilă planificarea datei de finalizare și a costurilor asociate.

Acest model este utilizat pentru sistemele pentru care toate cerințele pot fi formulate cu precizie la începutul dezvoltării. Acestea includ, de exemplu, sisteme în care sunt rezolvate în principal probleme de calcul. Procesele reale au de obicei o natură iterativă: rezultatele etapei următoare provoacă adesea schimbări în soluțiile de proiectare dezvoltate în etapele anterioare. Astfel, modelul mai comun este cu control intermediar, care este prezentat în Fig. 2.3.

Principalul dezavantaj al abordării în cascadă este o întârziere semnificativă în obținerea rezultatelor și, în consecință, un risc destul de mare de a crea un sistem care nu răspunde nevoilor în schimbare ale utilizatorilor.

Aceste probleme sunt eliminate în modelul ciclului de viață în spirală (Fig. 2.4). Caracteristica sa fundamentală este că aplicația software nu este creată imediat, ca în cazul abordării în cascadă, ci în părți folosind metoda prototipare . Un prototip este înțeles ca o componentă software de lucru care implementează funcții individualeși interfața externă a software-ului dezvoltat. Crearea prototipurilor se realizează în mai multe iterații - rotații în spirală.

Modelul în cascadă (evolutiv) poate fi reprezentat sub forma unei diagrame, care este prezentată în Figura 2.5.

Unul dintre rezultatele utilizării modelului ciclului de viață în spirală este metoda utilizată pe scară largă a așa-numitului dezvoltarea rapidă a aplicațiilor , sau RAD (Dezvoltare rapidă a aplicațiilor). Ciclul de viață al software-ului conform acestei metode include patru etape:

1) analiza și planificarea cerințelor;

2) proiectare;

3) implementare;

4) implementare.

Analiza ciclului de viață al programelor ne permite să clarificăm conținutul și să evidențiem următoarele procese de proiectare a sistemelor complexe.

1) Strategie;

2) Analiza;

3) Design;

4) Implementare;

5) Testare;

6) Implementare;

7) Funcționarea și suport tehnic.

Strategie

Definirea unei strategii presupune examinarea sistemului. Obiectivul principal al sondajului este de a evalua sfera reală a proiectului, scopurile și obiectivele acestuia, precum și obținerea de definiții la nivel înalt ale entităților și funcțiilor. În această etapă sunt atrași analiști de afaceri cu înaltă calificare care au acces constant la managementul companiei. În plus, este de așteptat o interacțiune strânsă cu principalii utilizatori ai sistemului și cu experții în afaceri. Sarcina principală a unei astfel de interacțiuni este de a obține informații cât mai complete despre sistem, de a înțelege clar cerințele clientului și de a transfera informațiile primite într-o formă oficială analiștilor de sistem. De obicei, informațiile despre sistem pot fi obținute printr-o serie de conversații (sau ateliere) cu management, experți și utilizatori.

Rezultatul etapei de definire a strategiei este un document care precizează clar următoarele:

Ce anume se datorează clientului dacă acesta este de acord să finanțeze proiectul;

Când va putea primi produsul finit (program de lucru);

Cât îl va costa (programarea etapelor de finanţare a lucrărilor pentru proiecte mari).

Documentul ar trebui să reflecte nu numai costurile, ci și beneficiile, de exemplu, perioada estimată de rambursare a proiectului efect economic(dacă poate fi evaluat).

Etapa considerată a ciclului de viață al software-ului poate fi reprezentată o singură dată în model, mai ales dacă modelul are o structură ciclică. Acest lucru nu înseamnă că în modelele ciclice planificare strategică făcut o dată pentru totdeauna. În astfel de modele, etapele definirii și analizei strategiei sunt, parcă, combinate, iar separarea lor există doar chiar în prima etapă, când conducerea întreprinderii ia o decizie fundamentală de a începe proiectul. În general etapa strategică este dedicat elaborării unui document la nivelul managementului întreprinderii.

Etapa de analiză presupune un studiu detaliat al proceselor de business (funcții definite în etapa anterioară) și al informațiilor necesare implementării acestora (entități, atribute și conexiuni (relații) acestora). Această etapă produce un model informațional, iar următoarea etapă de proiectare produce un model de date.

Toate informațiile despre sistem colectate în etapa de definire a strategiei sunt formalizate și clarificate în etapa de analiză. O atenție deosebită Acordă atenție caracterului complet al informațiilor primite, analizei sale pentru coerență, precum și căutării informațiilor neutilizate sau duplicate. De regulă, clientul formează mai întâi cerințe nu pentru sistemul ca întreg, ci pentru componentele sale individuale. Și în acest caz particular, modelele ciclice ale ciclului de viață al software-ului au un avantaj, deoarece este probabil să fie necesară o reanalizare în timp, deoarece clientul are adesea poftă când mănâncă. În această etapă se determină componentele necesare ale planului de testare.

Analiștii colectează și înregistrează informații în două forme interdependente:

a) funcții - informații despre evenimente și procese care au loc în afaceri;

b) entitati - informatii despre obiecte care sunt importante pentru organizatie si despre care se stie ceva.

Aceasta creează diagrame ale componentelor, fluxurilor de date și ciclurilor de viață care descriu dinamica sistemului. Acestea vor fi discutate mai târziu.

Proiecta

În etapa de proiectare, se formează un model de date. Designerii procesează datele de analiză. Produsul final al fazei de proiectare este o schemă de bază de date (dacă există una în proiect) sau o schemă de depozit de date (model ER) și un set de specificații ale modulelor de sistem (model funcțional).

Într-un proiect mic (de exemplu, un curs), aceiași oameni pot acționa ca analiști, designeri și dezvoltatori. Diagramele și modelele enumerate mai sus ajută la găsirea, de exemplu, a componentelor sistemului nedescrise deloc, descrise neclar, descrise inconsecvent și a altor deficiențe, ceea ce ajută la prevenirea potențialelor erori.

Toate specificațiile trebuie să fie foarte precise. Planul de testare a sistemului este, de asemenea, finalizat în această fază de dezvoltare. În multe proiecte, rezultatele fazei de proiectare sunt formalizate sub forma unui singur document - așa-numita specificație tehnică. În același timp aplicare largă a primit limbajul UML, care vă permite să obțineți simultan atât documente de analiză, care sunt mai puțin detaliate (consumatorii lor sunt directori de producție), cât și documente de proiectare (consumatorii lor sunt manageri ai grupurilor de dezvoltare și testare). Acest limbaj va fi discutat mai târziu. Software-ul construit folosind UML facilitează generarea codului - cel puțin ierarhia claselor, precum și unele părți ale codului metodelor (proceduri și funcții) în sine.

Obiectivele de proiectare sunt:

Revizuirea rezultatelor analizei și verificarea caracterului lor complet;

Seminarii cu clientul;

Identificarea zonelor critice ale proiectului și evaluarea limitărilor acestuia;

Definirea arhitecturii sistemului;

Decizia asupra utilizării produselor terților, precum și asupra metodelor de integrare și mecanismelor de schimb de informații cu aceste produse;

Proiectare depozit de date: model bază de date;

Proiectare proces și cod: selecția finală a instrumentelor de dezvoltare, definirea interfețelor programului, maparea funcțiilor sistemului la modulele sale și determinarea specificațiilor modulelor;

Determinarea cerințelor pentru procesul de testare;

Determinarea cerințelor de securitate a sistemului.

Implementarea

La implementarea unui proiect, este deosebit de importantă coordonarea echipelor de dezvoltare. Toți dezvoltatorii sunt supuși unor reguli stricte de control al sursei. Ei, după ce au primit proiect tehnic, începeți să scrieți codul modulului. Sarcina principală a dezvoltatorilor este să înțeleagă specificația: designerul scrie ceea ce trebuie făcut, iar dezvoltatorul determină cum să o facă.

În etapa de dezvoltare, există o interacțiune strânsă între designeri, dezvoltatori și grupurile de testare. În cazul dezvoltării intensive, testerul este literalmente inseparabil de dezvoltator, devenind efectiv un membru al echipei de dezvoltare.

Cel mai adesea, interfețele utilizatorului se schimbă în timpul etapei de dezvoltare. Acest lucru se datorează demonstrării periodice a modulelor către client. De asemenea, poate modifica semnificativ interogările de date.

Faza de dezvoltare este asociată cu faza de testare, iar ambele procese rulează în paralel. Sistemul de urmărire a erorilor sincronizează acțiunile testatorilor și dezvoltatorilor.

Bug-urile trebuie clasificate în funcție de prioritate. Pentru fiecare clasă de erori, trebuie definită o structură clară de acțiuni: „ce să faci”, „cât de urgent”, „cine este responsabil pentru rezultat”. Fiecare problemă ar trebui să fie urmărită de designerul/dezvoltatorul/testerul responsabil cu remedierea acesteia. Același lucru este valabil și pentru situațiile în care sunt încălcate dezvoltarea planificată și livrarea modulelor pentru testare.

În plus, ar trebui organizate depozite de module de proiect gata făcute și biblioteci care sunt utilizate la asamblarea modulelor. Acest depozit este actualizat constant. O persoană ar trebui să controleze procesul de actualizare. Un depozit este creat pentru modulele care au trecut testele funcționale, al doilea - pentru modulele care au trecut testele de conectivitate. Primul este schițele, al doilea este ceva din care puteți asambla o distribuție a sistemului și o puteți demonstra clientului pentru teste de control sau pentru trecerea oricăror etape de lucru.

Testare

Echipele de testare pot fi implicate în colaborare deja în fazele incipiente ale dezvoltării proiectului. De obicei, testarea complexă este separată într-o etapă de dezvoltare separată. În funcție de complexitatea proiectului, testarea și remedierea erorilor poate dura o treime, jumătate din timpul total petrecut lucrând la proiect sau chiar mai mult.

Cu cât proiectul este mai complex, cu atât este mai mare nevoia de a automatiza sistemul de urmărire a erorilor, care oferă următoarele funcții:

Stocarea mesajului de eroare (la ce componentă a sistemului se referă eroarea, cine a găsit-o, cum să-l reproducă, cine este responsabil pentru remedierea lui, când ar trebui remediată);

Sistem de notificare despre apariția de noi erori, despre modificările stării erorilor cunoscute în sistem (notificări de la e-mail);

Rapoarte despre erorile curente pentru componentele sistemului;

Informații despre eroare și istoricul acesteia;

Reguli de accesare a erorilor din anumite categorii;

Interfață de acces limitat la sistemul de urmărire a erorilor pentru utilizatorul final.

Astfel de sisteme iau multe probleme organizatorice, în special problemele de notificare automată a erorilor.

Testele de sistem în sine sunt de obicei împărțite în mai multe categorii:

o) teste offline module; sunt utilizate deja în stadiul de dezvoltare a componentelor sistemului și vă permit să urmăriți erorile componentelor individuale;

b) teste de conectare componente ale sistemului; aceste teste sunt folosite și în etapa de dezvoltare vă permit să monitorizați interacțiunea corectă și schimbul de informații între componentele sistemului;

c) testarea sistemului ; este principalul criteriu de acceptare a sistemului; de regulă, acesta este un grup de teste care include teste autonome, teste de conectare și modele; un astfel de test trebuie să reproducă funcționarea tuturor componentelor și funcțiilor sistemului; scopul său principal este acceptarea internă a sistemului și evaluarea calității acestuia;

d) test de acceptare; scopul său principal este predarea sistemului către client;

e) teste de performanță și sarcină; Acest grup de teste este inclus în cel de sistem este cel principal pentru evaluarea fiabilității sistemului.

Fiecare grup include în mod necesar teste de modelare a eșecului. Ei testează răspunsul unei componente, al unui grup de componente și al sistemului în ansamblu la următoarele defecțiuni:

O componentă separată a sistemului informațional;

Grupuri de componente ale sistemului;

Principalele module ale sistemului;

Sistem de operare;

Defecțiune hard (cădere de curent, defecțiune hard disk).

Aceste teste fac posibilă evaluarea calității subsistemului pentru restabilirea stării corecte a sistemului informațional și servesc drept sursă principală de informații pentru elaborarea strategiilor de prevenire a consecințelor negative ale defecțiunilor în timpul funcționării industriale.

Un alt aspect important al unui program de testare a sistemelor informatice este disponibilitatea generatoarelor de date de testare. Acestea sunt utilizate pentru a efectua teste ale funcționalității, fiabilității și performanței sistemului. Problema evaluării caracteristicilor dependenței performanței unui sistem informațional de creșterea volumelor de informații prelucrate nu poate fi rezolvată fără generatori de date.

Implementarea

Operațiunea de probă se suprapune cu procesul de testare. Sistemul este rareori implementat complet. De obicei, acesta este un proces gradual sau iterativ (în cazul unui ciclu de viață ciclic).

Punerea în funcțiune trece prin cel puțin trei etape:

2) acumularea de informații;

3) atingerea capacității de proiectare (adică trecerea efectivă la etapa de exploatare).

informațiile pot provoca o gamă destul de restrânsă de erori: în principal, nepotrivirea datelor în timpul încărcării și erorile proprii ale încărcătoarelor. Pentru identificarea și eliminarea acestora se folosesc metode de control al calității datelor. Astfel de erori trebuie corectate cât mai repede posibil.

În timpul acumulare de informații este relevat în sistemul informaţional cel mai mare număr erori legate de accesul multi-utilizator. A doua categorie de corecții este legată de faptul că utilizatorul nu este mulțumit de interfață. În același timp, modelele ciclice și modelele cu feedback pe etapă pot reduce costurile. Această etapă este, de asemenea, cel mai serios test - testele de acceptare a clienților.

Sistemul atinge capacitatea de proiectare V opțiune bună- aceasta este reglarea fină a erorilor minore și a erorilor grave rare.

Operare si suport tehnic

În această etapă, ultimul document pentru dezvoltatori este certificatul de acceptare tehnică. Documentul defineste personalul necesarși echipamentul necesar pentru a susține funcționalitatea sistemului, precum și condițiile de defecțiune a produsului și responsabilitățile părților. În plus, termenii și condițiile de asistență tehnică sunt de obicei întocmite ca document separat.

Conceptul de „ciclu de viață” implică ceva care se naște, se dezvoltă și moare. Ca un organism viu, produsele software sunt create, operate și dezvoltate în timp.

Ciclu de viață software-ul include toate etapele dezvoltării sale: de la apariția unei nevoi pentru acesta până la încetarea completă a utilizării sale din cauza învechirii sau a pierderii nevoii de a rezolva problemele relevante.

Putem distinge mai multe faze ale existenței unui produs software pe parcursul ciclului său de viață. Nu există încă nume general acceptate pentru aceste faze și numărul lor. Dar nu există un dezacord special în această problemă. Prin urmare, există mai multe opțiuni pentru împărțirea ciclului de viață al software-ului în etape. Dacă această partiție este mai bună decât altele, nu este întrebarea principală. Principalul lucru este să organizați corect dezvoltarea software-ului ținând cont de ele.

În funcție de durata ciclului lor de viață, produsele software pot fi împărțite în două clase: mic Şi durata de viata lunga. Aceste clase de programe corespund unei abordări flexibile (soft) a creării și utilizării lor și unei abordări industriale dure pentru proiectarea și operarea reglementate a produselor software. ÎN organizatii stiintificeși universități, de exemplu, predomină dezvoltarea de programe de primă clasă, iar în organizațiile de design și industriale - a doua.

Produse software cu durată de viață scurtă sunt create în principal pentru a rezolva probleme științifice și de inginerie, pentru a obține rezultate de calcul specifice. Astfel de programe sunt de obicei relativ mici. Ele sunt dezvoltate de un specialist sau de un grup mic. Ideea principală programele sunt discutate de către un programator și utilizatorul final. Unele detalii sunt scrise pe hârtie și proiectul este finalizat în câteva zile sau săptămâni. Nu sunt destinate reproducerii sau transferului pentru utilizare ulterioară în alte grupuri. În esență, astfel de programe fac parte din munca de cercetare și nu pot fi considerate produse software alienabile.

Ciclul lor de viață constă într-un interval lung de analiză a sistemului și formalizare a problemei, o etapă semnificativă de proiectare a programului și un timp relativ scurt de funcționare și obținere a rezultatelor. Cerințele pentru caracteristicile funcționale și de design, de regulă, nu sunt formalizate și nu există teste formale ale programelor. Indicatorii lor de calitate sunt controlați numai de dezvoltatori în conformitate cu ideile lor informale.

Produse software cu durată de viață scurtă

Întreținerea și modificarea unor astfel de programe nu sunt necesare, iar ciclul lor de viață se încheie după primirea rezultatelor calculului. Principalele costuri din ciclul de viață al unor astfel de programe se încadrează pe etapele analizei și proiectării sistemului, care durează de la o lună la 1...2 ani, ca urmare

prin care ciclul de viață al unui produs software depășește rar 3 ani.

Produse software cu o durată lungă de viață sunt create pentru procesarea și gestionarea periodică a informațiilor. Structura unor astfel de programe este complexă. Dimensiunile lor pot varia foarte mult (1...1000 de mii de comenzi), dar toate au proprietăți de cunoaștere și posibilitatea de modificare în timpul întreținerii și utilizării pe termen lung de către diverși specialiști. Produsele software din această clasă pot fi replicate, sunt însoțite de documentație ca produse industriale și reprezintă produse software înstrăinate de dezvoltator.

Produse software cu o durată lungă de viață

Proiectarea și funcționarea acestora sunt realizate de echipe mari de specialiști, ceea ce necesită formalizarea sistemului software, precum și testarea și determinarea oficializate a indicatorilor de calitate atinși ai produsului final. Ciclul lor de viață este de 10...20 de ani. Până la 70...90% din acest timp este cheltuit pentru operare și întreținere. Datorită replicării în masă și întreținerii pe termen lung, costurile totale în timpul exploatării și întreținerii unor astfel de produse software depășesc semnificativ costurile de analiză și proiectare a sistemului.

Toate prezentările ulterioare se concentrează pe tema dezvoltării mari (complexe) software management și prelucrare a informațiilor.

Model generalizat ciclu de viață Produsul software ar putea arăta astfel:

eu. Analiza sistemului:

a) cercetare;

b) analiza de fezabilitate:

Operațional;

Economic;

Comercial.

II. Design software:

a) proiectare:

Descompunerea funcțională a sistemului, arhitectura acestuia;

Proiectare software extern;

Proiectare baze de date;

Arhitectura software;

b) programare:

Proiectare software intern;

Proiectare externă a modulelor software;

Proiectare internă a modulelor software;

Codificare;

Programe de depanare;

Aspectul programului;

c) depanare software.

III. Evaluare software (testare).

IV. Utilizare software:

a) exploatare;

b) acompaniament.

eu. Analiza sistemului. La începutul dezvoltării software, se efectuează o analiză a sistemului (proiectare preliminară), în timpul căreia se determină necesitatea acestuia, scopul și principalele caracteristici funcționale. Sunt evaluate costurile și eficacitatea posibilă a utilizării viitorului produs software.

În această etapă, se întocmește o listă de cerințe, adică o definiție clară a ceea ce se așteaptă utilizatorul produs finit. Aici sunt stabilite scopuri și obiective, de dragul cărora este dezvoltat proiectul în sine. În faza de analiză a sistemului se pot distinge două direcții: cercetare și analiza de fezabilitate.

Încep cercetările din momentul în care managerul de dezvoltare realizează necesitatea software-ului.

Lucrarea constă în planificarea și coordonarea activităților necesare pregătirii unei liste oficiale, scrise de mână, de cerințe pentru produsul software dezvoltat.

Cercetarea se încheie când cerințele sunt astfel formate încât să devină vizibile și, dacă este necesar, să poată fi modificate și aprobate de către managerul responsabil.

Analiza de fezabilitate Există partea tehnica cercetarea și începe atunci când intenția managementului este suficient de puternică încât să fie numit un manager de proiect care să organizeze proiectarea și alocarea resurselor (forței de muncă).

Lucrarea constă în studierea produsului software propus în vederea obținerii unei evaluări practice a fezabilității proiectului, în special se determină următoarele:

- fezabilitate operațională , Va fi produsul suficient de convenabil pentru utilizare practică?

- fezabilitate economică , Costul produsului în curs de dezvoltare este acceptabil? Care este acest cost? Produsul va fi economic? instrument eficientîn mâinile utilizatorului?

- fezabilitate comerciala, Va fi produsul atractiv, la cerere, ușor de instalat, ușor de întreținut, ușor de învățat?

Acestea și alte probleme trebuie abordate în primul rând luând în considerare cerințele de mai sus.

Studiul de fezabilitate se încheie când toate cerințele au fost colectate și aprobate.

Înainte de a continua proiectul, este necesar să vă asigurați că au fost obținute toate informațiile necesare. Aceste informații trebuie să fie corecte, ușor de înțeles și posibile. Ar trebui să reprezinte un set complet de cerințe care să satisfacă utilizatorul pentru produsul software în curs de dezvoltare, formalizate sub forma unei specificații.

În caz de nerespectare această cerință este posibilă încetinirea semnificativă a implementării proiectului în viitor, din cauza solicitărilor repetate repetate adresate utilizatorului de clarificare a detaliilor interpretate incorect, a condițiilor nespecificate și, în consecință, va fi necesară reelaborarea părților sale deja dezvoltate.

Adesea, în timpul perioadei de analiză a sistemului, se ia decizia de a opri dezvoltarea ulterioară a software-ului.

II. Proiectare software. Designul este faza principală și decisivă a ciclului de viață al software-ului, în timpul căreia un produs software este creat și 90% ia forma finală.

Această fază a vieții acoperă diverse tipuri activitățile proiectului și pot fi împărțite în trei etape principale: proiectarea, programarea și depanarea produsului software.

Constructii dezvoltarea software-ului începe de obicei în faza de analiză a fezabilității, de îndată ce unele obiective și cerințe preliminare pentru acesta sunt înregistrate pe hârtie.

Până la aprobarea cerințelor, lucrările în faza de proiectare vor fi în plină desfășurare.

În această etapă a vieții software-ului, se efectuează următoarele:

Descompunerea funcțională a problemei care se rezolvă, pe baza căreia se determină arhitectura de sistem a acestei sarcini;

Design extern de software, exprimat sub formă interacțiune externă aceasta cu utilizatorul;

Proiectarea bazei de date, dacă este necesar;

Proiectarea arhitecturii software - definirea obiectelor, modulelor și interfețelor acestora.

Începe programarea deja în faza de proiectare, de îndată ce specificațiile de bază pentru componentele individuale ale produsului software devin disponibile, dar nu înainte de aprobarea acordului de cerințe. Suprapunerea fazelor de programare și proiectare are ca rezultat economii în timpul general de dezvoltare, precum și asigurarea faptului că corectitudinea deciziilor de proiectare este verificată și în unele cazuri influențează rezolvarea problemelor cheie.

În această etapă se efectuează lucrări legate de asamblarea produsului software. Constă în proiectarea internă detaliată a unui produs software, în dezvoltarea logicii interne a fiecărui modul al sistemului, care este apoi exprimată în textul unui program specific.

Faza de programare se termină când dezvoltatorii termină documentarea, depanarea și asamblarea părților individuale ale produsului software într-un singur întreg.

Depanare software se realizează după ce toate componentele sale au fost depanate separat și asamblate într-un singur produs software.

III. Evaluare software (testare).În această fază, produsul software este supus unei teste riguroase de sistem de către un grup de non-dezvoltatori.

Acest lucru se face pentru a se asigura că produsul software finit îndeplinește toate cerințele și specificațiile, poate fi utilizat în mediul utilizatorului, nu prezintă defecte și conține documentația necesară care descrie corect și complet produsul software.

Faza de evaluare începe imediat ce toate componentele (modulele) sunt asamblate și testate, adică. după depanarea completă a produsului software finit. Se încheie după primirea confirmării că produsul software a trecut toate testele și este gata de utilizare.

Durează cât se programează.

IV. Folosind software-ul. Dacă analiza sistemului este un semnal de luptă, designul este un atac și revine victorios, atunci folosirea unui produs software este o apărare zilnică, vitală, dar de obicei deloc onorabilă pentru dezvoltatori.

O astfel de comparație este adecvată datorită faptului că în timpul utilizării unui produs software, erorile care s-au strecurat în timpul procesului de proiectare sunt corectate.

Faza de utilizare a unui produs software începe atunci când produsul este transferat în sistemul de distribuție.

Acesta este timpul în care produsul este în funcțiune și utilizat eficient.

În acest moment, se efectuează pregătirea personalului, implementarea, configurarea, întreținerea și, eventual, extinderea produsului software - așa-numitul design în curs.

Faza de utilizare se termină atunci când produsul este scos din utilizare și încetează activitățile menționate mai sus. Rețineți, totuși, că produsul software poate continua să fie utilizat de altcineva mult timp după încheierea fazei de utilizare, așa cum este definită aici. Deoarece acest cineva poate folosi cu succes produsul software acasă chiar și fără ajutorul unui dezvoltator.

Utilizarea unui produs software este determinată de operarea și întreținerea acestuia.

Funcționarea produsului software constă în executarea acestuia, funcționarea pe un calculator pentru prelucrarea informațiilor și obținerea de rezultate care constituie scopul creării acestuia, precum și asigurarea acurateței și fiabilității datelor produse.

Întreținere software constă în întreținerea operațională, dezvoltarea funcționalității și îmbunătățirea caracteristicilor de performanță ale produsului software, replicarea și transferul produsului software către diverse tipuri facilitati de calcul.

Întreținerea joacă rolul de feedback necesar din etapa de exploatare.

În timpul funcționării software-ului, pot fi detectate erori în programe și este necesară modificarea acestora și extinderea funcțiilor.

Aceste îmbunătățiri, de regulă, sunt efectuate simultan cu funcționarea versiunii curente a produsului software. După verificarea ajustărilor pregătite pe una dintre copiile programului, următoarea versiune a produsului software le înlocuiește pe cele utilizate anterior sau pe unele dintre ele. În acest caz, procesul de operare a unui produs software poate fi aproape continuu, deoarece înlocuirea unei versiuni a unui produs software este pe termen scurt. Aceste circumstanțe duc la faptul că procesul de operare a unei versiuni a unui produs software decurge de obicei în paralel și indiferent de etapa de întreținere.

Suprapunerea între fazele ciclului de viață al produsului software

Suprapunerea între diferitele faze ale ciclului de viață al unui produs software este posibilă și de obicei de dorit. Cu toate acestea, nu ar trebui să existe o suprapunere între procesele neadiacente.

Posibil feedbackîntre faze. De exemplu, în timpul unuia dintre pașii de proiectare externă, pot fi descoperite erori în formularea obiectivelor, apoi trebuie să reveniți imediat și să le corectați.

Modelul ciclului de viață al produsului software considerat, cu unele modificări, poate servi drept model pentru proiecte mici.

De exemplu, atunci când este proiectat un singur program, este adesea posibil să se evite proiectarea arhitecturii sistemului și

proiectare baze de date; procesele de proiectare externă inițială și detaliate sunt adesea îmbinate etc.

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.

Vorbitor într-un limbaj simplu, sisteme informatice 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 și evidențiat conditii generale, folosit î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

Dintre 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 international disponibil 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 etapa de dezvoltare, au fost folosite instrumente limbaj de programare C. Dar platforma arăta destul de primitivă și nu a oferit utilizatorului final calitatea cerută sunet.

Î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ă 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 unor module precum Addictive Drums sau pluginul universal Kontakt a făcut posibilă reproducerea sunetelor live instrumente reale, înregistrată 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 de exportat fișier de sunet 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 moduri diferite. 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 insuportabilă ar putea fi lansată pe piața de software.

Dar dacă spunem că dezvoltarea de software de orice tip (de control sau aplicație) nu stă pe loc, putem spune doar că astăzi se referă nu numai sisteme informatice, și dispozitive mobile, în care tehnologiile folosite sunt adesea înaintea sectorului informatic. Apariția cipurilor de procesor bazate pe opt nuclee nu este cea mai bună 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ă, sfârșitul se referă la aplicații vechi care nu îndeplinesc cerințele sisteme moderneși nu pot lucra în mediul lor.

Dar chiar și ținând cont progres tehnic multe dintre ele pot deveni în curând insolvabile. 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 tehnologii informatice Astăzi, se preferă dezvoltarea sistemelor automate de control (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 programatorii ies în prim-plan, ci marketerii trebuie să răspundă la schimbări în timp util. piata 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. 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, până la aplicare practică A mai rămas foarte puțin. Dacă ei creează deja copii ale rețelelor neuronale ale creierului uman, atunci ce putem spune?