Ciclul de viață al sistemelor software. Ciclul de viață al programului Cicluri de viață de dezvoltare după tip

Orez. 5.2.

Aceste aspecte sunt:

aspectul contractual, în care clientul și furnizorul intră în relații contractuale și implementează procesele de achiziție și livrare;
aspectul de management, care include acțiunile de management ale persoanelor care participă la ciclul de viață al software-ului (furnizor, client, dezvoltator, operator etc.);
aspectul operațional, care include acțiunile operatorului de a furniza servicii utilizatorilor sistemului;
aspectul de inginerie, care conține acțiunile dezvoltatorului sau serviciului de asistență pentru rezolvarea problemelor tehnice asociate cu dezvoltarea sau modificarea produselor software;
aspect al suportului asociat cu implementarea proceselor de suport prin care oferă birourile de asistență servicii necesare tuturor celorlalți participanți la lucru. Sub acest aspect, putem evidenția aspectul managementului calității software, care include procese de asigurare a calității, verificare, certificare, evaluare comună și audit.

Procesele organizaționale se desfășoară la nivel corporativ sau la nivelul întregii organizații în ansamblu, creând baza pentru implementarea și îmbunătățirea continuă a proceselor ciclului de viață al software-ului.

5.6. Modele și etape ale ciclului de viață al software-ului

Modelul ciclului de viață al software-ului este înțeles ca o structură care definește secvența execuției și relațiile proceselor, acțiunilor și sarcinilor de-a lungul ciclului de viață al software-ului. 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 ISO/IEC 12207 nu oferă un model specific de ciclu de viață și metode de dezvoltare software. Prevederile sale sunt generale pentru orice model de ciclu de viață, metode și tehnologii de dezvoltare software. Standardul descrie structura proceselor ciclului de viață al software-ului, dar nu specifică modul de implementare sau executare a acțiunilor și sarcinilor incluse în aceste procese.

Modelul ciclului de viață al oricărui software specific determină natura procesului de creare a acestuia, care este un set de lucrări ordonate în timp, interconectate și combinate în etape (faze), a căror implementare este necesară și suficientă pentru a crea un software care îndeplinește cerințele specificate.

Etapa (faza) creării software-ului este înțeleasă ca parte a procesului de creare a software-ului, limitată de un anumit interval de timp și se termină cu lansarea unui anumit produs (modele software, componente software, documentație etc.), determinată de cerințe. specificate pentru această etapă. Etapele creării software-ului se disting din motive de planificare rațională și organizare a muncii care se încheie cu rezultate specificate. Ciclul de viață al software-ului include de obicei următoarele etape:

formarea cerințelor software;
proiectarea (dezvoltarea unui proiect de sistem);
implementare (poate fi împărțit în sub-etape: proiectare detaliată, codificare);
testare (pot fi împărțite în testare și integrare autonome și integrate);
punerea în funcțiune (implementarea);
operare si intretinere;
dezafectarea.

Unii experți introduc o etapă inițială suplimentară - analiza de fezabilitate sisteme. Aici ne referim la un sistem hardware și software pentru care software-ul este creat, achiziționat sau modificat.

Etapa de formare a cerințelor software este una dintre cele mai importante și determină într-o măsură semnificativă (chiar decisivă!) succesul întregului proiect. Începutul acestei etape este obținerea unei arhitecturi de sistem aprobate și validate, inclusiv acorduri de bază privind distribuția funcțiilor între hardware și software. Acest document ar trebui să conțină, de asemenea, confirmarea înțelegerii generale a funcționării software-ului, inclusiv acordurile de bază despre distribuirea funcțiilor între persoană și sistem.

Etapa de generare a cerințelor software include următoarele etape.

Planificarea lucrărilor înainte de a lucra la proiect. Principalele obiective ale etapei sunt stabilirea scopurilor de dezvoltare, preliminare evaluare economică proiect, construirea unui program de lucru, crearea și formarea unui grup de lucru comun.
Efectuarea unui studiu asupra activităților organizației automatizate (obiect), în cadrul căruia se realizează identificarea preliminară a cerințelor pentru viitorul sistem, determinarea structurii organizației, determinarea listei de funcții țintă ale organizației, analiza distribuției funcțiilor între departamente și angajați, identificarea interacțiunilor funcționale între departamente, fluxurile de informații în interiorul și între departamente, obiectele externe organizației și influențele informaționale externe, analiza mijloacelor existente de automatizare a activităților organizației.

Construirea unui model al activității unei organizații (obiect), care implică prelucrarea materialelor de anchetă și construirea a două tipuri de modele:

modelul „AS-IS” (“Așa cum este”), reflectând starea actuală a lucrurilor în organizație la momentul sondajului și permițând să înțelegem cum funcționează organizația, precum și să identifice blocajele și să formuleze propuneri pentru îmbunătățirea situaţie;
modelul „TO-BE” („cum ar trebui să fie”), reflectând ideea de noi tehnologii pentru organizație.

Fiecare dintre modele ar trebui să includă un model complet funcțional și informațional al activităților organizației, precum și (dacă este necesar) un model care descrie dinamica comportamentului organizației. Rețineți că modelele construite au independente semnificație practică, indiferent dacă un sistem informațional va fi dezvoltat și implementat la întreprindere, deoarece cu ajutorul lor este posibilă instruirea angajaților și îmbunătățirea proceselor de afaceri ale întreprinderii.

Rezultatul finalizării etapei de generare a cerințelor software este specificațiile software, specificațiile funcționale, tehnice și de interfață, pentru care se confirmă integralitatea, verificabilitatea și fezabilitatea acestora.

Etapa de proiectare include următoarele etape.

Dezvoltarea unui proiect de sistem software. În această etapă, este dat răspunsul la întrebarea „Ce ar trebui să facă viitorul sistem?”, și anume: arhitectura sistemului, funcțiile acestuia, condițiile externe de operare, interfețele și distribuția funcțiilor între utilizatori și sistem, cerințele pentru software și componentele informaționale, compoziția performanților și termenele limită sunt determinate de dezvoltare, planul de depanare a software-ului și controlul calității.

Baza unui proiect de sistem este alcătuită din modele ale sistemului proiectat, care sunt construite pe modelul „TO-BE”. Rezultatul dezvoltării unui proiect de sistem trebuie să fie o specificație aprobată și confirmată a cerințelor software: specificații funcționale, tehnice și de interfață, pentru care se confirmă completitatea, verificabilitatea și fezabilitatea acestora.
Elaborarea unui proiect detaliat (tehnic). În această etapă, se realizează proiectarea software-ului propriu-zis, inclusiv proiectarea arhitecturii sistemului și proiectarea detaliată. Astfel, se dă răspunsul la întrebarea: „Cum să construim un sistem astfel încât să satisfacă cerințele?”

Rezultatul designului detaliat este dezvoltarea unei specificații software verificate, inclusiv:

formarea unei ierarhii de componente software, interfețe intermodulare pentru date și management;
specificarea fiecărei componente software, nume, scop, ipoteze, dimensiuni, secvență de apeluri, date de intrare și ieșire, erori ieșiri, algoritmiși circuite logice;
formarea structurilor de date fizice și logice până la nivelul câmpurilor individuale;
elaborarea unui plan de distribuire a resurselor de calcul (timp procesor central, memorie etc.);
verificarea completității, coerenței, fezabilității și validității cerințelor;
plan preliminar pentru integrare și depanare, plan pentru manual de utilizare și testare de acceptare.

Finalizarea etapei de proiectare detaliată este de la capăt la capăt

La 01 martie 2012, Agenția Federală pentru Reglementare Tehnică și Metrologie a Federației Ruse a adoptat standardul GOST R ISO/IEC 12207-2010 „Tehnologia informației. Inginerie de sistem și software. Procesele ciclu de viață software”, identic cu standardul internațional ISO/IEC 12207:2008 „Ingineria sistemelor și software - Procese ciclului de viață al software-ului”.

Acest standard, folosind terminologia consacrata, stabileste structura generala procesele ciclului de viață al software-ului, care pot fi ghidate în industria software-ului. Standardul definește procesele, activitățile și sarcinile care sunt utilizate în achiziție produs software sau servicii, precum și în timpul furnizării, dezvoltării, utilizării prevăzute, întreținerii și încetării utilizării produselor software.

Procesele ciclului de viață al software-ului

Grupuri standard diverse tipuri activități care pot fi efectuate pe parcursul ciclului de viață al sistemelor software în șapte grupuri de procese. Fiecare dintre procesele ciclului de viață din cadrul acestor grupuri este descris în termeni de obiective și rezultate dorite, liste de acțiuni și sarcini care trebuie efectuate pentru a obține acele rezultate.

procese de acord - două procese;
procese de sprijin organizațional al proiectului - cinci procese;
procese de proiect - șapte procese;
procese tehnice - unsprezece procese;
procese de implementare software - șapte procese;
procese de suport software - opt procese;
procese de reutilizare a software-ului - trei procese.
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-2010 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.

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 de prelucrare simbolică 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, de ex. 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. În prezent, a devenit unul dintre principalele domenii de aplicare a calculatoarelor 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 interdependente (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 a software-ului, 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 ansamblu continuu și ordonat de activități desfășurate și gestionate în cadrul fiecărui proiect de dezvoltare și exploatare a software-ului, pornind din momentul în care ideea (planul) creării unor softwareși luarea unei decizii cu privire la necesitatea creării sale și a încetării în momentul retragerii sale complete din serviciu din motive:

a) uzura;

b) pierderea nevoii de a rezolva problemele relevante.

Abordările tehnologice sunt mecanisme de implementare a ciclului de viață.

Abordarea tehnologică este determinată de combinația specifică de etape și procese, concentrată pe diferite clase de software și pe 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 poate fi prezentat cu diferite grade de detaliere a etapei. 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ă. Evident, atunci când se dezvoltă și se creează programe mari, o astfel de schemă nu este suficient de corectă (inaplicabilă), dar poate fi luată ca bază.

etapa Aaliz se concentrează asupra cerinţele de sistem. Cerințele sunt definite și specificate (descrise). Dezvoltarea și integrarea modelelor funcționale și a modelelor de date pentru sistem este în curs de desfășurare. În plus, sunt înregistrate cerințele nefuncționale și alte cerințe de sistem.

Faza de proiectare este împărțită în două subfaze principale: 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 de cele 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 repartizarea 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;

Cu toate acestea, crearea, întreținerea și dezvoltarea de software aplicat 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 de complexe moderne distribuite. programe de aplicație calitate superioarăîn sisteme de control şi prelucrare a datelor cu arhitecturi diverse.

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

ISO - International Organization of Standardization - International Organization for Standardization, 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 o sarcină atât de simplă, motiv pentru care 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, sprijin). Ne vom concentra pe acesta din urmă.

2) procese auxiliare care asigură executarea proceselor principale ( 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, se pune problema luării în considerare a conexiunilor și funcțiilor acestora, creând o structură unificată (adică unică) ș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 de determinare dacă starea curentă a software-ului a fost atinsă la în această etapă, cerințele acestei etape.

3. Certificare– confirmarea prin examinare și prezentarea de dovezi obiective că cerințele specifice pentru obiecte specifice realizat pe deplin.

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 a produselor sau proceselor software cu cerințele stabilite. Examinare vă permite să evaluați conformitatea parametrilor de dezvoltare cu cerințele inițiale. Verificarea este parțial aceeași cu testarea, care este utilizată pentru a determina diferențele dintre rezultatele reale și cele așteptate și pentru a evalua dacă performanța software-ului îndeplinește cerințele originale. În procesul de implementare a proiectului, un loc important îl ocupă problemele de identificare, descriere și control al configurației componentelor individuale și a întregului sistem în ansamblu.

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 compozitiei echipamentul necesar, software și operațiuni efectuate de personalul de întreținere.

5) analiza cerințelor software- determinarea 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 pentru datele utilizate, 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 utilizator, 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

planul de integrare și testarea software-ului pentru conformitate cerințe de calificare, reprezentând un set de criterii sau condiții care trebuie îndeplinite pentru a califica un produs software ca îndeplinind 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, este de asemenea verificată 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:

· declarația problemei (TOR) (conform GOST 19.102-77 etapa „Specificații tehnice”)

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

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

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

În termeni simpli, 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 internațional există 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;
posibilitatea 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 ridicată și vă permite să schimbați tempo-ul, înălțimea și să aplicați efecte FX suplimentare în timp real.

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

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

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

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

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

Perspective de dezvoltare

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

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

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

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

Dar dacă spunem că dezvoltarea de software de orice tip (de control sau aplicație) nu stă pe loc, putem spune doar că astăzi se referă nu numai la sisteme informatice, ci și 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, este destul de arbitrar să spunem că acesta s-a încheiat la un anumit moment în timp, deoarece produsele software încă beneficiază de sprijin de la dezvoltatorii care le-au creat. Mai degrabă, 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 de progresul tehnologic, multe dintre ele pot deveni în curând insuportabile. Apoi va trebui să luați o decizie fie de a lansa actualizări, fie de a revizui complet întregul concept încorporat inițial în produsul software. De aici și noul ciclu, care presupune schimbarea condițiilor inițiale, a mediului de dezvoltare, testare și posibilă utilizare pe termen lung într-o anumită zonă.

Dar în 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ă numai în acest caz principii 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 sisteme automatizate managementul producției. Aici nici măcar programatorii ies în prim-plan, ci marketerii trebuie să răspundă în timp util la schimbările de pe piața calculatoarelor. Și nu există atât de mulți astfel de specialiști în lume. Personalul cu înaltă calificare care poate ține degetul pe pulsul pieței devine cel mai solicitat. Și ei sunt adesea așa-numiții „cardinali gri” de care depinde succesul sau eșecul unui anumit produs software în domeniul IT.

S-ar putea să nu înțeleagă întotdeauna esența programării, dar sunt în mod clar capabili să determine modele ale ciclului de viață al software-ului și durata utilizării lor, pe baza tendințelor globale în acest domeniu. 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. Cât costă „zombificarea” canalelor de știri sau site-urilor de internet, ca să nu mai vorbim de utilizarea mai multor mijloace puternice, cum ar fi expunerea la infrasunete (aceasta a fost folosită într-o producție de operă), în urma căreia 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?

Conceptul de „ciclu de viață” implică ceva care se naște, se dezvoltă și moare. Asemenea unui 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ă denumiri general acceptate pentru aceste faze și numărul lor. Dar nu există nici 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 organizațiile științifice și universități, de exemplu, predomină dezvoltarea de programe de primă clasă, iar în design și organizatii industriale- al doilea.

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ă a programului este discutată între 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țe pentru funcționale și caracteristici de proiectare, de regulă, nu sunt formalizate, nu există teste formalizate de programe. 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 pentru analiza sistemuluiși design.

Toate prezentările ulterioare se concentrează pe tema dezvoltării unor instrumente software mari (complexe) pentru gestionarea și procesarea 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;

Proiectarea bazei 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) funcționare;

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 așteaptă utilizatorul de la produsul 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.

Cercetările 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.

Nerespectarea acestei cerințe poate încetini semnificativ implementarea proiectului în viitor, din cauza solicitărilor repetate și repetate adresate utilizatorului de a clarifica detaliile interpretate incorect, condițiile nespecificate și, în consecință, va fi necesară reelaborarea pieselor 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% capătă forma sa finală.

Această fază a vieții acoperă diverse activități ale proiectului și poate fi împărțită î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 forma interacțiunii sale externe 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 duce la economii în timpul general de dezvoltare, precum și la asigurarea verificărilor de corectitudine solutii de proiectare, iar în unele cazuri influențează soluționarea 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 de sistem, care este apoi exprimată în textul unui program specific.

Faza de programare se termină atunci 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 documentatia necesara, 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 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 caracteristici de performanta programe ale multor produse, în replicarea și transferul produselor software către diverse tipuri de mijloace 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 un singur program este proiectat, 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.