Ciclul de viață al software-ului: concept, standarde, procese. Ciclul de viață al sistemelor software Ciclul de viață al definirii sistemelor software

Ciclu de viață software

Unul dintre conceptele de bază ale metodologiei de proiectare software este conceptul ciclului său de viață al software-ului (SOLC). Ciclul de viață al software-ului este un proces continuu care începe din momentul în care se ia o decizie cu privire la necesitatea creării acestuia și se termină în momentul retragerii sale complete din serviciu.

Principal document normativ, care reglementează ciclul de viață al software-ului este standardul internațional ISO/IEC 12207 (ISO - International Organization of Standardization, IEC - International Electrotechnical Commission). Acesta definește structura ciclului de viață care conține procesele, activitățile și sarcinile care trebuie efectuate în timpul creării software-ului. În acest standard Software (produs software) definit ca un set programe de calculator, proceduri și eventual documentația și datele asociate. Proces este definit ca un set de acțiuni interconectate care transformă unele date de intrare în date de ieșire. Fiecare proces este caracterizat de anumite sarcini și metode de rezolvare a acestora, date de intrare obținute din alte procese și rezultate.

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

· principalele procese ale ciclului de viață al software-ului (cumpărare, livrare, dezvoltare, operare, suport);

· procese auxiliare care asigură implementarea principalelor procese (documentare, managementul configurației, asigurarea calității, verificare, certificare, evaluare, audit, rezolvare de probleme);

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

Modele ciclului de viață al software-ului

Modelul ciclului de viață- o structură care determină succesiunea execuției și relația dintre etapele și etapele efectuate pe parcursul ciclului de viață. Modelul ciclului de viață depinde de specificul software-ului și de condițiile specifice în care acesta din urmă este creat și funcționează. Principalele modele de ciclu de viață sunt următoarele.

1. Model în cascadă(până în anii 70 ai secolului XX) determină trecerea consistentă la următoarea etapă după ce cea precedentă este finalizată.

Acest model se caracterizează prin automatizarea sarcinilor individuale nelegate, care nu necesită integrarea și compatibilitatea informațiilor, software, interfață tehnică și organizatorică.

Demnitate: indicatori buni în ceea ce privește timpul de dezvoltare și fiabilitatea la rezolvarea problemelor individuale.

Defect: Nu se aplică proiectelor mari și complexe din cauza variabilității cerințelor de sistem pe o perioadă lungă de proiectare.

2. Model iterativ(anii 70-80 ai secolului XX) corespunde tehnologiei de proiectare „de jos în sus”. Permite reveniri iterative la etapele anterioare după finalizarea etapei următoare;

Modelul prevede generalizarea rezultatelor obţinute solutii de proiectare probleme individuale în soluții la nivelul întregului sistem. În acest caz, este necesar să se revizuiască cerințele formulate anterior.

Demnitate: capacitatea de a face rapid ajustări la proiect.

Defect: cu un număr mare de iterații, timpul de proiectare crește, apar discrepanțe în soluțiile de proiectare și documentație, iar arhitectura funcțională și de sistem a software-ului creat devine confuză. Necesitatea reproiectării celui vechi sau a crea sistem nou poate apărea imediat după faza de implementare sau operare.

3. Model în spirală(anii 80-90 ai secolului XX) corespunde tehnologiei de design „de sus în jos”. Implica utilizarea unui prototip software care permite extensia software. Proiectarea sistemului repetă ciclic calea de la detalierea cerințelor până la detalierea codului programului.

La proiectarea unei arhitecturi de sistem, se determină mai întâi compoziția subsistemelor funcționale și se rezolvă probleme la nivelul întregului sistem (organizarea unei baze de date integrate, tehnologie de colectare, transmitere și stocare a informațiilor). Apoi se formulează problemele individuale și se dezvoltă tehnologia pentru rezolvarea lor.

La programare, sunt dezvoltate mai întâi modulele software principale, apoi sunt dezvoltate modulele care îndeplinesc funcții individuale. În primul rând, se asigură interacțiunea modulelor între ele și cu baza de date, iar apoi implementarea algoritmilor.

Avantaje:

1. reducerea numărului de iterații și, în consecință, a numărului de erori și inconsecvențe care trebuie corectate;

2. reducerea timpului de proiectare;

3. simplificarea creaţiei documentatia proiectului.

Defect: cerințe ridicate pentru calitatea depozitului la nivel de sistem (bază de date de proiectare comună).

Modelul în spirală este baza tehnologii de dezvoltare rapidă a aplicațiilor sau tehnologia RAD (dezvoltare rapidă a aplicațiilor), care presupune participarea activă a utilizatorilor finali ai viitorului sistem la procesul de creare a acestuia. Principalele etape ale ingineriei informaționale sunt următoarele:

· Analiza și planificarea strategiei informaționale. Utilizatorii, împreună cu dezvoltatorii specialiști, participă la identificarea zonei cu probleme.

· Proiecta. Utilizatorii, sub îndrumarea dezvoltatorilor, participă la proiectarea tehnică.

· Constructii. Dezvoltatorii proiectează o versiune de lucru a software-ului folosind limbaje de generația a 4-a;

· Implementarea. Dezvoltatorii instruiesc utilizatorii să lucreze în noul mediu software.

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. Treaba asta este făcută analist de sisteme(analist de procese de afaceri).

2) Software-ul este dezvoltat pentru piață. Este necesar să se efectueze cercetare de marketingși 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

Scop - Definiție structura generala software (arhitectură). 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. Test – clarificare caracteristici tehnice. Drept urmare, programul este garantat să funcționeze.

Implementare (lansare)

Implementare – atunci când lucrează pentru un singur client. Include crearea 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. Efectuarea de îmbunătățiri neesențiale. Acumularea de propuneri pentru dezvoltarea versiunii următoare.

Modele de ciclu de viață

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

2. Prototiparea

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

3. Model iterativ

Sarcina este împărțită în subsarcini și ordinea implementării lor este determinată astfel încât fiecare subsarcină ulterioară să extindă capacitățile software-ului. Succesul depinde în mod semnificativ de cât de bine sunt împărțite sarcinile în subsarcini și de modul în care este aleasă ordinea. Avantaje: 1) oportunitate participarea activă clientul este în dezvoltare, are 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.

î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 un set 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ă.

Procese de creație sisteme automatizate(AS), care include software, sunt reglementate de standardele GOST 34.601-90 " Tehnologia de informație. Un set de standarde pentru sisteme automate. 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. Cele patru procese organizaționale asigură management, infrastructură, îmbunătățire și învățare.

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ătorii pași:

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

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

determinarea de către client a nevoilor sale pentru achiziția, dezvoltarea sau îmbunătățirea unui sistem, produse software sau servicii;
luarea deciziilor privind achiziția, dezvoltarea sau îmbunătățirea software-ului existent;
verificare disponibilitate documentatia necesara, garantii, certificate, licente si suport in cazul achizitionarii unui produs software;
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ă:

cerințe pentru sistem;
lista de produse software;
termenii de achiziție și acord;
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:

determinarea de către client a unei proceduri de selectare a unui furnizor, inclusiv a criteriilor de evaluare a propunerilor de la eventualii furnizori;
selectarea unui anumit furnizor pe baza analizei propunerilor;
pregătire și încheiere acorduri cu furnizorul;
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:

inițierea livrării;
pregătirea unui răspuns la propunerile de licitație;
intocmirea contractului;
planificarea lucrărilor conform contractului;
execuție și control munca contractualași evaluarea acestora;
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:

luarea unei decizii de către furnizor cu privire la executarea lucrărilor pe cont propriu sau cu implicarea unui subcontractant;
elaborarea de către furnizor a unui plan de management de proiect care să conţină structura organizatorica proiect, împărțirea responsabilităților, cerințe tehnice pentru 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:

munca pregatitoare;
analiza cerințelor sistemului;
proiectarea arhitecturii sistemului;
analiza cerințelor software;
proiectarea arhitecturii software;
proiectare detaliată a software-ului;
codificare și testare software;
integrare software;
testarea calificării software-ului;
integrarea sistemului;
testarea calificării sistemului;
instalare software;
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 un sistem implică determinarea acestuia funcţionalitate, 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:

funcționalitatea, inclusiv caracteristicile de performanță și mediul de operare al componentei;
interfețe externe;
specificații de fiabilitate și siguranță;
cerințe ergonomice;
cerințe pentru datele utilizate;
cerințe de instalare și acceptare;
cerințe pentru documentația utilizatorului;
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:

transformarea cerinţelor software într-o arhitectură care defineşte nivel înalt structura software și compoziția componentelor sale;
dezvoltarea și documentarea interfețelor software și a bazelor de date (DB);
dezvoltarea unei versiuni preliminare a documentației utilizatorului;
dezvoltarea și documentarea cerințelor preliminare de testare și a planului de integrare software.

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

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

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

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;
testarea fiecărei componente software și bază de date pentru conformitatea cu cerințele pentru acestea, urmată de documentarea rezultatelor testelor;
actualizarea documentației (dacă este necesar);
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.

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.
Testare operațională efectuată pentru fiecare ediție ulterioară a unui produs software, după care această ediție este pusă în funcțiune.
Funcționarea efectivă a sistemului, care se realizează în mediul destinat acestui scop în conformitate cu documentația utilizatorului.
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);
modificarea software-ului (efectuarea de modificări la componentele produsului software și la documentație în conformitate cu regulile procesului de dezvoltare);
verificarea și acceptarea (din punct de vedere al integrității sistemului modificat);
transferul de software într-un alt mediu (conversia de programe și date, operarea paralelă a software-ului în mediul vechi și nou pentru o anumită perioadă de timp);
scoaterea din funcțiune a software-ului prin decizia clientului cu participarea organizației de exploatare, a serviciului de asistență și a utilizatorilor. În același timp produse softwareși documentația sunt supuse arhivării în conformitate cu acordul.

Standardele ciclului de viață al software-ului

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

Metodologii de dezvoltare software

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

Standard GOST 34.601-90

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

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

Schița, desenele tehnice și documentația de lucru sunt construcția consecventă a soluțiilor de proiectare din ce în ce mai precise. Este posibil să excludeți etapa „Proiectare schiță” și etapele individuale de lucru în toate etapele, să combinați etapele „Proiectare tehnică” și „Documentație de lucru” în „Proiectare tehnică detaliată” și să efectuați lucrări paralele diverse etapeși munca, includeți altele suplimentare.

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

Standardul ISO/IEC 12207/ și aplicarea acestuia

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

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

Procesele ciclului de viață al software-ului

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

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

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

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

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

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

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

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

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

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

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

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

Modele ciclului de viață al software-ului

Un model de ciclu de viață este o structură care definește secvența de execuție și relațiile proceselor, activităților și sarcinilor efectuate de-a lungul ciclului de viață. Modelul ciclului de viață depinde de specific sistem informatic si specificul conditiilor in care acesta din urma este creat si functioneaza

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

Modelul problemei;

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

model în spirală (prezent).

Model cu probleme

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

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

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

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

Model în cascadă

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

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

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

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

Etapele proiectului conform modelului cascadei:

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

Orez. 1. Schema de dezvoltare în cascadă

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

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

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

Model în spirală

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

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

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

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

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

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

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

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

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

scurt dar atent cercetat programul de producție(de la 2 la 6 luni);

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

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

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

faza de proiectare;

faza de implementare;

faza de implementare.

La fiecare iterație sunt evaluate următoarele:

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

Avantajele abordării iterative:

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