Ar trebui să începem prin a definiCiclu de viață software (Software Life Cycle Model) este o perioadă de timp care începe din momentul în care se ia decizia de a crea un produs software și se termină în momentul în care acesta este complet retras din serviciu. Acest ciclu este procesul de construire și dezvoltare a software-ului.

Modele de ciclu de viață software

Ciclul de viață poate fi reprezentat sub formă de modele. În prezent, cele mai frecvente sunt:în cascadă, incrementale (model în etape cu control intermediar ) și spiralămodele de ciclu de viață.

Model în cascadă

Model în cascadă(ing. model de cascadă) este un model al procesului de dezvoltare software, al cărui ciclu de viață arată ca un flux care trece secvenţial prin fazele de analiză a cerinţelor, proiectare. implementare, testare, integrare și suport.

Procesul de dezvoltare este implementat folosind o secvență ordonată de pași independenți. Modelul prevede că fiecare pas ulterior începe după finalizarea pasului anterior. La toate etapele modelului, sunt efectuate procese și lucrări auxiliare și organizaționale, inclusiv managementul proiectelor, evaluarea și managementul calității, verificarea și certificarea, managementul configurației și dezvoltarea documentației. Ca urmare a parcurgerii etapelor, se formează produse intermediare care nu pot fi modificate în etapele ulterioare.

Ciclul de viață este împărțit în mod tradițional în următoarele principaleetape:

1. Analiza cerințelor,
2. Proiecta,
3. Codare (programare),
4. Testare și depanare,
5. Operare și întreținere.

Avantajele modelului:

• stabilitatea cerințelor pe tot parcursul ciclului de viață al dezvoltării;
• la fiecare etapă se formează un set complet documentatia proiectului, care îndeplinește criteriile de completitudine și coerență;
• certitudinea și comprehensibilitatea etapelor modelului și simplitatea aplicării acestuia;
• etapele de lucru efectuate într-o succesiune logică vă permit să planificați momentul finalizării tuturor lucrărilor și resursele corespunzătoare (monetare, materiale și umane).

Dezavantajele modelului:

• complexitatea formulării clare a cerințelor și imposibilitatea schimbării dinamice a acestora pe parcursul întregului ciclu de viață;
• flexibilitate scăzută în managementul proiectelor;
• ulterior structura liniara procesul de dezvoltare, ca urmare a revenirii la pașii anteriori pentru rezolvarea problemelor emergente duce la creșterea costurilor și perturbarea programului de lucru;
• neadecvarea produsului intermediar pentru utilizare;
• imposibilitatea modelării flexibile a sistemelor unice;
• detectarea tardivă a problemelor legate de construcție datorită integrării simultane a tuturor rezultatelor la sfârșitul dezvoltării;
• participarea insuficientă a utilizatorilor la crearea sistemului - la început (în timpul dezvoltării cerințelor) și la sfârșit (în timpul testelor de acceptare);
• utilizatorii nu pot fi convinși de calitatea produsului dezvoltat până la sfârșitul întregului proces de dezvoltare. Ei nu au posibilitatea de a evalua calitatea, deoarece nu pot vedea produsul finit de dezvoltare;
• utilizatorul nu are posibilitatea de a se obișnui treptat cu sistemul. Procesul de învățare are loc la sfârșitul ciclului de viață, când software-ul a fost deja pus în funcțiune;
• fiecare fază este o condiție prealabilă pentru execuția acțiunilor ulterioare, ceea ce face ca o astfel de metodă să fie o alegere riscantă pentru sistemele care nu au analogi, deoarece. nu se pretează modelării flexibile.

Este dificil de implementat modelul ciclului de viață în cascadă din cauza complexității dezvoltării PS fără a reveni la pașii anteriori și a le modifica rezultatele pentru a elimina problemele emergente.

Domeniul de aplicare al modelului în cascadă

Limitarea domeniului de aplicare al modelului în cascadă este determinată de deficiențele acestuia. Utilizarea sa este cea mai eficientă în următoarele cazuri:

1. la dezvoltarea proiectelor cu clare, neschimbabileciclu de viață cerințe înțelese prin implementare și metodologii tehnice;
2. la dezvoltarea unui proiect axat pe construirea unui sistem sau a unui produs de același tip cu cel dezvoltat anterior de dezvoltatori;
3. la dezvoltarea unui proiect legat de crearea și lansarea versiune noua un produs sau sistem existent;
4. la dezvoltarea unui proiect legat de transferul unui produs sau sistem existent pe o nouă platformă;
5. la realizarea unor proiecte mari care implică mai multe echipe mari de dezvoltare.

model incremental

(model treptat cu control intermediar)

model incremental(ing. creştere- crestere, crestere) presupune dezvoltarea de software cu o succesiune liniara de etape, dar in mai multe trepte (versiuni), i.e. cu îmbunătățiri planificate ale produsului atâta timp cât ciclul de viață al dezvoltării software se încheie.

Dezvoltarea software-ului se realizează în iterații cu bucle de feedback între etape. Ajustările între etape fac posibilă luarea în considerare a influenței reciproce reale a rezultatelor dezvoltării la diferite etape, durata de viață a fiecărei etape fiind prelungită pe întreaga perioadă de dezvoltare.

La începutul lucrărilor la proiect sunt determinate toate cerințele de bază ale sistemului, împărțite în unele mai mult și mai puțin importante. După aceea, dezvoltarea sistemului se realizează pe o bază incrementală, astfel încât dezvoltatorul să poată utiliza datele obținute în timpul dezvoltării software-ului. Fiecare increment ar trebui să adauge anumite funcționalități sistemului. În acest caz, lansarea începe cu componentele cu cea mai mare prioritate. Când părțile sistemului sunt definite, luați prima parte și începeți să o detaliați folosind cel mai potrivit proces pentru aceasta. În același timp, este posibilă rafinarea cerințelor pentru alte părți care au fost înghețate în setul actual de cerințe ale acestei lucrări. Dacă este necesar, puteți reveni la această parte mai târziu. Daca piesa este gata, aceasta este livrata clientului, care o poate folosi in munca sa. Acest lucru va permite clientului să clarifice cerințele pentru următoarele componente. Apoi ei dezvoltă următoarea parte a sistemului. Pașii cheie în acest proces sunt pur și simplu implementarea unui subset de cerințe software și rafinarea modelului pe o serie de versiuni succesive până când întregul software este implementat.

Ciclul de viață al acestui model este tipic pentru dezvoltarea de sisteme complexe și complexe pentru care există o viziune clară (atât din partea clientului, cât și a dezvoltatorului) a ceea ce ar trebui să fie rezultat final. Dezvoltarea versiunii se realizează din mai multe motive:

• lipsa capacității clientului de a finanța imediat întregul proiect costisitor;
• lipsa dezvoltatorului resursele necesare să implementeze un proiect complex într-un timp scurt;
• cerințe pentru implementarea și dezvoltarea în faze a produsului de către utilizatorii finali. Introducerea întregului sistem deodată poate provoca respingere în rândul utilizatorilor săi și nu face decât să „încetinească” procesul de tranziție la noile tehnologii. Figurat vorbind, ei pur și simplu „nu pot digera o bucată mare, așa că trebuie zdrobită și dată în părți”.

Avantajeși limităriale acestui model (strategie) sunt aceleași cu cele ale cascadei (modelul clasic al ciclului de viață). Dar spre deosebire de strategia clasică, clientul poate vedea rezultatele mai devreme. Pe baza rezultatelor dezvoltării și implementării primei versiuni, el poate modifica ușor cerințele de dezvoltare, poate să o abandoneze sau să ofere dezvoltarea unui produs mai avansat cu încheierea unui nou contract.

Avantaje:

• costurile suportate ca urmare a schimbării cerințelor utilizatorilor sunt reduse, reanalizarea și colectarea documentației sunt reduse semnificativ în comparație cu modelul în cascadă;
• este mai ușor să obțineți feedback de la client despre munca depusă - clienții își pot exprima comentariile cu privire la piesele finite și pot vedea ceea ce a fost deja făcut. pentru că primele părți ale sistemului sunt prototipul sistemului ca întreg.
• clientul are capacitatea de a achiziționa și stăpâni rapid software-ul - clienții pot obține beneficii reale din sistem mai repede decât ar fi posibil cu modelul în cascadă.

Dezavantajele modelului:

• managerii trebuie să măsoare constant progresul procesului. în cazul dezvoltării rapide, nu merită să creați documente pentru fiecare modificare minimă a versiunii;
• structura sistemului tinde să se deterioreze atunci când sunt adăugate noi componente - schimbările constante perturbă structura sistemului. Pentru a evita acest lucru, sunt necesare timp și bani suplimentari pentru refactorizare. Structura slabă face ca software-ul să fie dificil și costisitor de modificat ulterior. Iar ciclul de viață întrerupt al software-ului duce la pierderi și mai mari.

Schema nu permite luarea în considerare cu promptitudine a modificărilor și clarificărilor emergente ale cerințelor software. Coordonarea rezultatelor dezvoltării cu utilizatorii se realizează numai în punctele planificate după finalizarea fiecărei etape de lucru și Cerințe generale software-ului sunt fixate sub formă de specificații tehnice pentru întreaga perioadă de creare a acestuia. Astfel, utilizatorii primesc adesea software care nu le satisface nevoile reale.

model în spirală

Model spiralat:Ciclul de viață - la fiecare tură a spiralei, se creează următoarea versiune a produsului, se precizează cerințele proiectului, se determină calitatea acestuia și se planifică activitatea următoarei ture. O atenție deosebită este acordată etapelor inițiale de dezvoltare - analiză și proiectare, în cazul în care fezabilitatea anumitor solutii tehnice testat și justificat prin prototipare.

Acest model este un proces de dezvoltare software care combină atât proiectarea, cât și prototiparea în etape pentru a combina beneficiile conceptelor de jos în sus și de sus în jos, punând accent pe etapele inițiale ale ciclului de viață: analiză și proiectare.Trăsătură distinctivă Acest model acordă o atenție deosebită riscurilor care afectează organizarea ciclului de viață.

La etapele de analiza si proiectare se verifica fezabilitatea solutiilor tehnice si gradul de satisfacere a nevoilor clientilor prin realizarea de prototipuri. Fiecare rotație a spiralei corespunde creării unui fragment sau a unei versiuni funcționale a sistemului. Acest lucru vă permite să clarificați cerințele, obiectivele și caracteristicile proiectului, să determinați calitatea dezvoltării și să planificați activitatea următoarei ture a spiralei. Astfel, detaliile proiectului sunt aprofundate și concretizate în mod consecvent și, ca urmare, este selectată o opțiune rezonabilă care să răspundă cerințelor reale ale clientului și să fie adusă la implementare.

Ciclul de viață pe fiecare tură a spiralei - pot fi aplicate diferite modele ale procesului de dezvoltare software. Rezultatul final este un produs finit. Modelul combină capacitățile unui model de prototipare șimodel de cascadă. Dezvoltarea prin iterații reflectă ciclul spiral existent în mod obiectiv al creării sistemului. 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 pe cea curentă. sarcina principală- să arate cât mai curând posibil utilizatorilor sistemului un produs funcțional, activând astfel procesul de clarificare și completare a cerințelor.

Avantajele modelului:

• vă permite să arătați rapid utilizatorilor sistemului un produs funcțional, activând astfel procesul de clarificare și completare a cerințelor;
• permite modificări ale cerințelor în timpul dezvoltării software, ceea ce este tipic pentru majoritatea dezvoltărilor, inclusiv cele standard;
• modelul oferă posibilitatea de proiectare flexibilă, deoarece întruchipează avantajele modelului cascadă, în timp ce, în același timp, sunt permise iterații prin toate fazele aceluiași model;
• vă permite să obțineți un sistem mai fiabil și mai stabil. Pe măsură ce software-ul evoluează, erorile și punctele slabe sunt găsite și remediate la fiecare iterație;
• acest model permite utilizatorilor să participe activ la planificare, analiza riscului, dezvoltare, precum și la realizarea activităților de evaluare;
• reduce riscul clientului. Clientul poate finaliza dezvoltarea unui proiect nepromițător cu pierderi financiare minime;
• feedback-ul de la utilizatori către dezvoltatori este de înaltă frecvență și la începutul modelului pentru a asigura că produsul potrivit este construit Calitate superioară.

Dezavantajele modelului:

• dacă proiectul are un risc scăzut sau mic, modelul poate fi costisitor. Evaluarea riscului după fiecare spirală este costisitoare;
• Ciclul de viață al modelului are o structură complicată, astfel încât aplicarea acestuia de către dezvoltatori, manageri și clienți poate fi dificilă;
• spirala poate continua la nesfârșit, deoarece răspunsul fiecărui client la versiunea creată poate genera un nou ciclu, care întârzie finalizarea proiectului;
• un număr mare de cicluri intermediare poate duce la necesitatea procesării documentației suplimentare;
• utilizarea modelului poate fi costisitoare și chiar inaccesibilă, deoarece timp. cheltuielile pentru planificare, redirecționare, efectuarea analizei de risc și crearea de prototipuri pot fi excesive;
• poate fi dificil să se definească obiectivele și reperele care indică disponibilitatea de a continua procesul de dezvoltare la următoarea și

Principala problemă a ciclului spirală este determinarea momentului de tranziție la etapa următoare. Pentru a o rezolva, se introduc limite de timp pentru fiecare dintre etape.ciclu de viață iar tranziția se desfășoară conform planului, chiar dacă nu toate lucrările planificate sunt finalizate.Planificareproduse pe baza datelor statistice obţinute în proiectele anterioare şi experienta personala dezvoltatori.

Domeniul de aplicare al modelului în spirală

Utilizarea modelului în spirală este recomandată în următoarele cazuri:

• la dezvoltarea proiectelor folosind noile tehnologii;
• la dezvoltarea unei noi serii de produse sau sisteme;
• atunci când se dezvoltă proiecte cu modificări semnificative așteptate sau completări la cerințe;
• pentru implementarea proiectelor pe termen lung;
• atunci când se dezvoltă proiecte care necesită demonstrarea calității și a versiunilor unui sistem sau produs într-o perioadă scurtă de timp;
• la dezvoltarea proiectelor. pentru care este necesar să se calculeze costurile asociate cu evaluarea și rezolvarea riscurilor.

Dezvoltarea CT extinde constant clasele de sarcini de rezolvat legate de prelucrarea informațiilor de altă natură.

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

1) Sarcini de calcul asociate procesării informațiilor numerice. Acestea includ, de exemplu, problema rezolvării unui sistem de ecuații liniare de dimensiuni mari. A fost principala zonă dominantă de utilizare a computerelor.

2) Sarcini pentru prelucrarea informațiilor simbolice asociate cu crearea, editarea și transformarea datelor text. Munca, de exemplu, a unui secretar-dactilograf este asociată cu rezolvarea unor astfel de probleme.

3) Sarcini de prelucrare a informațiilor grafice, de ex. diagrame, desene, grafice, schițe etc. Astfel de sarcini includ, de exemplu, sarcina de a dezvolta desene de produse noi de către un designer.

4) Sarcini de prelucrare a informațiilor alfanumerice - IS. În prezent, a devenit unul dintre principalele domenii de aplicare a computerelor iar sarcinile devin din ce în ce mai complicate.

Soluția computerizată a problemelor fiecărei clase are propriile sale specificități, dar poate fi împărțită în mai multe etape care sunt tipice pentru majoritatea problemelor.

Tehnologia de programarestudiază procesele tehnologice și ordinea parcurgerii acestora (etapele) folosind cunoștințe, metode și mijloace.

Tehnologiile sunt caracterizate convenabil în două dimensiuni - verticală (reprezentând procese) și orizontală (reprezentând etape).

Imagine

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

O etapă este o parte a activităților de dezvoltare software, limitată de un anumit interval de timp și se termină cu lansarea unui anumit produs, determinată de cerințele stabilite 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 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, începând din momentul în care apare o idee (concept) de creare a unui software și se ia o decizie privind trebuie să-l creeze și se încheie în momentul retragerii sale complete din exploatare din motive:

a) uzura;

b) pierderea nevoii de rezolvare a sarcinilor corespunzătoare.

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

Abordarea tehnologică este determinată de specificul combinației de etape și procese, axat pe diferite clase de software și pe caracteristicile echipei de dezvoltare.

Ciclul de viață definește etapele (faze, etape) astfel încât produsul software să treacă de la o etapă la alta, începând de la conceperea produsului și terminând cu etapa de pliere a acestuia.

Ciclul de viață al dezvoltării software poate fi prezentat cu diferite grade de detaliere a etapelor. Cea mai simplă reprezentare a ciclului de viață, include etapele:

Proiecta

Implementarea

Testare și depanare

Implementare, operare si intretinere.

Cea mai simplă reprezentare a ciclului de viață al programului (abordarea tehnologiei în cascadă a managementului ciclului de viață):

Procese

Proiecta

Programare

Testare

Escorta

Analiză Proiectare Implementare Testare Implementare Operație

și depanare și întreținere

De fapt, există un singur proces care rulează la fiecare etapă. Evident, atunci când se dezvoltă și se creează programe mari, o astfel de schemă nu este suficient de corectă (nu este cazul), dar poate fi luată ca bază.

Etapa de analiză se concentrează pe cerințele de sistem. Cerințele sunt definite și specificate (descrise). Se realizează dezvoltarea și integrarea modelelor funcționale și modelelor de date pentru sistem. În plus, cerințele nefuncționale și alte cerințe de sistem sunt fixate.

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 rafinate. Problemele de proiectare care afectează înțelegerea, mentenabilitatea și scalabilitatea sistemului sunt ridicate și remediate.

Faza de implementare include scrierea unui program.

Diferențele de hardware și software sunt vizibile în special la scenă exploatare. Dacă bunurile de larg consum trec prin etape de introducere pe piață, creștere, maturitate și declin, atunci viața software-ului seamănă mai mult cu povestea unei clădiri (aeronave) neterminate, dar permanent finalizate și actualizate. (Abonat).

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

Scopul standardizării ciclului de viață al PS complex:

Rezumarea 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 control al procesului;

Stabilirea cerințelor pentru prezentarea rezultatelor;

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

A determina structura organizationala echipă de dezvoltare;

Asigura distributia si programarea sarcinilor;

Oferiți control asupra progresului creării PS.

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

Etape de dezvoltare software - GOST 19.102-77

Etapele creării AS - GOST 34.601-90;

TK pentru crearea AS - GOST 34.602-89;

Tipuri de test AS - GOST 34.603-92;

Cu toate acestea, crearea, întreținerea și dezvoltarea de aplicații software pentru IP în aceste standarde nu sunt suficient reflectate, iar unele dintre prevederile acestora sunt depășite din punctul de vedere al construirii de sisteme moderne distribuite de programe de aplicații de înaltă calitate în sisteme de control și prelucrare a datelor cu arhitecturi diferite.

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

ISO - Organizația Internațională de Standardizare - organizatie internationala pentru standardizare, IEC - International Electrotechnical Commission - International Electrotechnical Commission.

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

Acestea. crearea de software nu este o sarcină atât de ușoară, prin urmare există standarde în care totul este scris: 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 grupe de procese:

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

2) procese auxiliare care asigură implementarea proceselor principale ( documentație, managementul configurației, asigurarea calității, verificare, validare, revizuire colaborativă (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 ele putând avea varietăți sau versiuni, se pune problema luării în considerare a relațiilor și funcțiilor acestora, crearea unei structuri unificate (adică unică) și asigurarea dezvoltării întregului sistem. Managementul configurației vă permite să organizați, să luați în considerare în mod 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 curenta software realizat pe această etapă, cerințele acestei etape.

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

4. Analiza comună (evaluare) – determinarea sistematică a gradului de conformitate a obiectului cu criteriile stabilite.

5. Audit– verificarea efectuată de către autoritatea (persoana) competentă în vederea asigurării evaluare independentă gradul în care produsele sau procesele software sunt conforme cu cerințele specificate. Examinare vă permite să evaluați conformitatea parametrilor de dezvoltare cu cerințele inițiale. Verificarea se suprapune cu testarea, care este efectuată pentru a determina diferențele dintre rezultatele reale și cele așteptate și pentru a evalua dacă caracteristicile software-ului îndeplinesc cerințele originale. În procesul de implementare a proiectului, problemele de identificare, descriere și control al configurației componentelor individuale și a întregului sistem în ansamblu ocupă un loc important.

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

Management de proiect legate de problemele de planificare și organizare a muncii, crearea de echipe de dezvoltatori și monitorizarea timpului și calității muncii efectuate. Suportul tehnic și organizatoric al proiectului include alegerea metodelor și instrumentelor pentru implementarea proiectului, definirea 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 legată de problemele 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 prevede acțiunile și sarcinile efectuate de dezvoltator și acoperă crearea de software și componentele acestuia în conformitate cu cerințele specificate, inclusiv pregătirea documentației de proiectare și operaționale, precum și pregătirea materiale necesare verificării operabilității și conformității calității produselor software, materiale necesare pregătirii personalului etc.

Conform standardului, ciclul de viață al software-ului IP include următorii pași:

1) apariția și studiul ideii (conceptului);

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

3) analiza cerintelor pentru Sistem 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 service.

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

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

7) proiectare detaliată a software-ului - detaliat

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

8) codare software -– dezvoltare și documentare

fiecare componentă software;

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

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

planul de integrare și testarea software-ului pentru conformitatea cu cerințele de calificare, care reprezintă un set de criterii sau condiții care trebuie îndeplinite pentru a califica un produs software ca fiind în conformitate cu specificațiile sale și gata de utilizare în condiții de operare specificate;

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

prezența clientului pentru a demonstra conformitatea acestuia

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

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

13) Testarea calificării IP – testarea sistemului pentru

respectarea cerințelor pentru aceasta și verificarea proiectării și a caracterului complet al documentației;

14) instalarea software-ului – instalarea software-ului pe echipamentul clientului și verificarea performanței acestuia;;

15) acceptarea software-ului – evaluarea rezultatelor unui calificat

testarea software-ului și a sistemelor informaționale în general ș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) escortă - procesul de creare și implementare a noilor versiuni

produs software.;

19) finalizarea operațiunii.

Aceste acțiuni pot fi grupate, evidențiind condiționat următoarele etape principale ale dezvoltării software:

declarație de sarcină (TOR) (în conformitate cu etapa GOST 19.102-77 " Sarcina tehnică»)

Conceptul de ciclu de viață al software-ului (LC) este unul dintre conceptele de bază în ingineria software. Ciclu de viață este definită ca o perioadă de timp care începe din momentul în care se ia o decizie cu privire la necesitatea creării unui software și se termină în momentul retragerii sale complete din funcționare.

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

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

1. Formarea cerințelor software.

2. Design.

3. Implementare.

4. Testare.

5. Punerea în funcţiune.

6. Operare și întreținere.

7. Dezafectarea.

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

a) cascadă şi

b) spirală (evolutivă).

Primul a fost folosit pentru programe de volum mic, care sunt un singur întreg. Caracteristica principală abordarea cascadei este că trecerea la următoarea etapă se efectuează numai după finalizarea completă a lucrărilor la cea actuală și nu există reveniri la etapele trecute. Schema sa este prezentată în Fig. 2.2.

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

La fiecare etapă se formează un set complet de documentație de proiect;

Etapele de lucru efectuate vă permit să planificați timpul de finalizare a acestora și costurile corespunzătoare.

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

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

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

Modelul în cascadă (evoluționar) poate fi reprezentat sub formă de diagramă, care este prezentată în Figura 2.5.

Unul dintre rezultatele aplicării modelului spiral al ciclului de viață este metoda așa-numitului Dezvoltarea rapidă a aplicațiilor , sau RAD (Dezvoltarea rapidă a aplicațiilor). Ciclul de viață al software-ului în conformitate cu această metodă include patru etape:

1) analiza și planificarea cerințelor;

2) proiectare;

3) implementare;

4) implementare.

Analiza ciclului de viață al programelor vă permite să clarificați conținutul și să identificați următoarele procese pentru proiectarea sistemelor complexe.

1) Strategie;

2) Analiza;

3) Design;

4) Implementare;

5) Testare;

6) Introducere;

7) Operare și suport tehnic.

Strategie

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

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

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

Când poate obține produsul finit (program de lucru);

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

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

Etapa considerată a ciclului de viață al software-ului poate fi reprezentată în model o singură dată, mai ales dacă modelul are o structură ciclică. Acest lucru nu înseamnă că în modelele ciclice planificare strategica produs o dată pentru totdeauna. În astfel de modele, etapele de determinare a strategiei și de analiză par a fi combinate, iar separarea lor există abia în prima rundă, când conducerea companiei ia o decizie fundamentală de a demara proiectul. În general etapa strategica este dedicat elaborării unui document la nivelul managementului întreprinderii.

Etapa de analiză presupune un studiu detaliat al proceselor de afaceri (funcții definite în etapa anterioară) și al informațiilor necesare implementării acestora (entități, atribute și relații (relații) acestora). Această fază oferă modelul de informații, iar următoarea fază de proiectare, modelul de date.

Toate informațiile despre sistem colectate în etapa de definire a strategiei sunt formalizate și rafinate în etapa de analiză. O atenție deosebită se acordă completității informațiilor primite, analizei acesteia pentru coerență, precum și căutării informațiilor neutilizate sau duplicate. De regulă, clientul formează mai întâi cerințele nu pentru sistemul ca întreg, ci pentru componentele sale individuale. Și în acest caz particular, modelele ciclice ale ciclului de viață al software-ului au un avantaj, deoarece este probabil să fie necesară o reanalizare în timp, deoarece clientului de multe ori îi este foame de mâncare. În aceeași etapă se determină componentele necesare ale planului de testare.

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

a) funcții - informații despre evenimentele și procesele care au loc în afacere;

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

Acest lucru creează diagrame de componente, fluxuri de date și cicluri de viață care descriu dinamica sistemului. Ele vor fi discutate mai târziu.

Proiecta

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

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

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

Sarcinile de proiectare sunt:

Luarea în considerare a rezultatelor analizei și verificarea completității acestora;

Seminarii cu clientul;

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

Determinarea arhitecturii sistemului;

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

Proiectare depozit de date: model bază de date;

Procesul și proiectarea codului: alegerea finală instrumente de dezvoltare, definirea interfețelor programelor, maparea funcțiilor sistemului la modulele sale și definirea specificațiilor modulelor;

Determinarea cerințelor pentru procesul de testare;

Determinarea cerințelor de securitate a sistemului.

Implementarea

Atunci când implementați un proiect, este deosebit de important să coordonați grupul (grupurile) de dezvoltatori. Toți dezvoltatorii trebuie să respecte regulile stricte de control al sursei. Ei, după ce au primit proiect tehnic, începeți să scrieți codul modulului. Sarcina principală a dezvoltatorilor este să înțeleagă specificația: designerul scrie ceea ce trebuie făcut, iar dezvoltatorul determină cum să o facă.

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

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

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

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

În plus, ar trebui organizate depozite de module de proiect gata făcute și biblioteci care sunt utilizate la asamblarea modulelor. Acest depozit este actualizat constant. O persoană ar trebui să supravegheze procesul de actualizare. Un depozit este creat pentru modulele care au trecut testarea funcțională, al doilea - pentru modulele care au trecut testarea legăturilor. Primul este schițele, al doilea este ceva din care este deja posibil să asamblați kitul de distribuție al sistemului și să îl demonstrați clientului pentru teste de control sau pentru livrarea oricăror etape de lucru.

Testare

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

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

Stocarea mesajului de eroare (de ce componentă de sistem aparține eroarea, cine a găsit-o, cum să o reproducă, cine este responsabil pentru remedierea acesteia, când ar trebui remediată);

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

Rapoarte despre erorile curente ale componentelor sistemului;

Informații despre eroare și istoricul acesteia;

Reguli de accesare a erorilor din anumite categorii;

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

Astfel de sisteme preia multe probleme organizatorice, în special problemele notificării automate a erorilor.

De fapt, testele de sistem sunt de obicei împărțite în mai multe categorii:

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

b) teste de linkuri componentele sistemului; aceste teste sunt folosite și în etapa de dezvoltare, vă permit să urmăriți interacțiunea corectă și schimbul de informații între componentele sistemului;

c) testarea sistemului; este principalul criteriu de acceptare a sistemului; de regulă, acesta este un grup de teste, incluzând atât teste de sine stătătoare, cât și teste de legătură și model; un astfel de test ar trebui să reproducă funcționarea tuturor componentelor și funcțiilor sistemului; scopul său principal este acceptarea internă a sistemului și evaluarea calității acestuia;

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

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

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

O componentă separată a sistemului informațional;

Grupuri de componente ale sistemului;

Principalele module ale sistemului;

sistem de operare;

Defecțiunea hard (penea de curent, hard disk-uri).

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

O alta aspect important Programul de testare a sistemelor informatice este prezența generatoarelor de date de testare. Sunt folosite pentru a testa funcționalitatea, fiabilitatea și performanța sistemului. Sarcina de a evalua caracteristicile dependenței performanței unui sistem informațional de creșterea volumului de informații prelucrate nu poate fi rezolvată fără generatori de date.

Implementarea

Operațiunea de probă anulează procesul de testare. Sistemul este rareori introdus complet. De regulă, acesta este un proces gradual sau iterativ (în cazul unui ciclu de viață ciclic).

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

2) acumularea de informații;

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

În cursul perioadei acumulare de informatiiîn sistemul informaţional este relevat cel mai mare număr erori legate de accesul multi-utilizator. A doua categorie de corecții este legată de faptul că utilizatorul nu este mulțumit de interfață. În același timp, modele ciclice și modele cu părere pași pentru reducerea costurilor. Etapa luată în considerare este, de asemenea, cel mai serios test - testul de acceptare a clienților.

Sistemul atinge capacitatea de proiectareîntr-o versiune bună, aceasta este reglarea fină a erorilor minore și a erorilor grave rare.

Operare si suport tehnic

În această etapă, ultimul document pentru dezvoltatori este certificatul de acceptare tehnică. Documentul definește personalul necesarși echipamentul necesar pentru a menține sistemul în funcțiune, precum și condițiile de încălcare a produsului și răspunderea părților. În plus, condițiile de asistență tehnică sunt de obicei emise sub forma unui document separat.

În acest standard PS (sau 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 date de ieșire (G. Myers numește această traducere a datelor). Fiecare proces este caracterizat de anumite sarcini și metode pentru rezolvarea lor. La rândul său, fiecare proces este împărțit într-un set de acțiuni, iar fiecare acțiune este împărțită î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 de date de intrare).

Trebuie remarcat faptul că în Uniunea Sovietică și apoi în Rusia, crearea de software (software) inițial, în anii 70 ai secolului trecut, a fost reglementată de standardele GOST ESPD (Sistemul unificat pentru documentarea programelor - GOST 19.XXX). serie), care s-au concentrat pe clasa de programe relativ simple de volum mic create de programatori individuali. În prezent, aceste standarde sunt depășite din punct de vedere conceptual și din punct de vedere al formei, valabilitatea lor a expirat și utilizarea lor este inadecvată.

Procese de creație sisteme automatizate(AS), care include și software, sunt reglementate de GOST 34.601-90 " Tehnologia de informație. Set de standarde pentru sisteme automate. Etapele creației”, GOST 34.602-89 „Tehnologia informației. Set de standarde pentru sisteme automate. Sarcina tehnică pentru crearea unui sistem automatizat” și GOST 34.603-92 „Tehnologia informației. Tipuri de teste ale sistemelor automate". Cu toate acestea, multe prevederi ale acestor standarde sunt depășite, în timp ce altele nu sunt suficient de reflectate pentru a fi utilizate pentru proiecte serioase de creare a PS. Prin urmare, este recomandabil să se folosească standarde internaționale moderne în evoluțiile interne.

Î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.

Cinci procese principale sunt definite în grupuri: achiziție, furnizare, dezvoltare, operare și întreținere. Opt subprocese asigură executarea proceselor principale și anume documentație, managementul configurației, asigurarea calitatii, verificarea, validarea, evaluarea comuna, auditul, rezolvarea problemelor. Cele patru procese organizaționale asigură guvernanță, construirea infrastructurii, îmbunătățire și învățare.

5.2. Principalele procese ale ciclului de viață al PS

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

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

Inițierea achiziției include următoarele sarcini:

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

Ofertele trebuie să conțină:

1. Cerințe de sistem;
2. lista de produse software;
3. termenii de achiziție și acord;
4. limitări tehnice (de exemplu, asupra mediului de operare al sistemului).

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

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

1. determinarea de către client a procedurii de selectare a unui furnizor, inclusiv a criteriilor de evaluare a propunerilor posibililor furnizori;
2. selectarea unui anumit furnizor pe baza analizei propunerilor;
3. pregătire și încheiere contracte de furnizori;
4. efectuarea de modificări (dacă este necesar) la contract în procesul de implementare a acestuia.

Activitățile furnizorului sunt supravegheate î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ă în cazul îndeplinirii tuturor condițiilor de acceptare.

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

1. inițierea livrării;
2. pregătirea unui răspuns la oferte;
3. intocmirea contractului;
4. planificarea lucrărilor prin contract;
5. efectuarea și controlul lucrărilor contractuale și evaluarea acestora;
6. livrarea si finalizarea lucrarilor.

Inițierea furnizării constă în luarea în considerare de către furnizor a propunerilor de ofertă și decizia de a fi de acord cu cerințele și condițiile stabilite sau de a oferi propriile lor (acordate). Planificarea include următoarele sarcini:

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

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

Procesul de dezvoltare include următorii pași:

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

Lucrarea pregătitoare începe cu selectarea unui model de ciclu de viață al software-ului adecvat dimensiunii, semnificației și complexității proiectului. Activitățile și sarcinile procesului de dezvoltare ar trebui să fie în concordanță cu modelul ales. Dezvoltatorul trebuie să selecteze, să se adapteze la condițiile proiectului și să utilizeze standardele, metodele și metodele convenite cu clientul. instrumente de dezvoltare, precum și să întocmească un plan de lucru.

Analiza cerințelor pentru sistem implică determinarea funcționalității acestuia, cerințe personalizate, 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 de verificabilitate în timpul testării.

Proiectarea arhitecturii sistemului constă în determinarea componentelor echipamentului (hardware-ului), software-ului și operațiunilor efectuate de personalul care operează sistemul. Arhitectura sistemului trebuie să respecte cerințele sistemului și standardele și practicile de proiectare acceptate.

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

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

Cerințele software sunt evaluate pe baza criteriilor de conformitate cu cerințele pentru întregul sistem, fezabilitate și verificabilitate în timpul testării.

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

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

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

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

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

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

Integrarea software implică asamblarea componentelor software dezvoltate în conformitate cu planul de integrare și testare pentru componentele agregate. Pentru fiecare dintre componentele agregate, se dezvoltă suite de testare și proceduri de testare pentru a testa fiecare dintre competențe în testele ulterioare de competență. Cerință de calificare este un set de criterii sau condiții care trebuie îndeplinite pentru a se califica software ca fiind conformă cu specificațiile sale și gata de utilizare în teren.

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

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

1. Lucrări pregătitoare, care includ îndeplinirea următoarelor sarcini de către operator:

   1. planificarea activităților și lucrărilor efectuate în timpul funcționării și stabilirea standardelor operaționale;
   2. determinarea procedurilor de localizare și rezolvare a problemelor apărute în timpul funcționării.
2. Testarea operațională efectuată pentru fiecare ediție următoare a produsului software, după care această ediție este trecută în funcțiune.
3. Funcționarea efectivă a sistemului, care se realizează în mediul destinat pentru aceasta, în conformitate cu documentația utilizatorului.
4. analiza problemelor și solicitărilor de modificare a software-ului (analiza mesajelor despre o problemă apărută sau o cerere de modificare, evaluarea baremului, costul modificării, efectul rezultat, evaluarea fezabilității modificării);
5. modificarea software-ului (efectuarea de modificări la componentele produsului software și la documentație în conformitate cu regulile procesului de dezvoltare);
6. verificare și acceptare (în ceea ce privește integritatea sistemului care se modifică);
7. 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);
8. scoaterea din funcțiune a software-ului prin decizia clientului cu participarea organizației de exploatare, a serviciului de întreținere și a utilizatorilor. în care produse softwareși documentația sunt supuse arhivării în conformitate cu contractul.

Adnotare.

Introducere.

1. Ciclul de viață al software-ului

Introducere.

Etapele procesului de programare Riley

Introducere.

1.1.1. Formularea problemei.

1.1.2. Proiectarea soluției.

1.1.3. Codarea algoritmului.

1.1.4. Suport program.

1.1.5. Documentația software.

Concluzie la punctul 1.1

1.2. Definiția ZhTsPO conform Lehman.

Introducere.

1.2.1 Definirea sistemului.

1.2.2. Implementarea.

1.2.3. Serviciu.

Concluzie la punctul 1.2.

1.3. Fazele și lucrările programului ciclului de viață conform Boehm

1.3.1. model în cascadă.

1.3.2. Fundamentarea economică a modelului în cascadă.

1.3.3. Îmbunătățirea modelului în cascadă.

1.3.4. Definirea fazelor ciclului de viață.

1.3.5. Lucrări de bază pe proiect.

Literatură.

Introducere

Aplicația industrială a computerelor și cererea în creștere pentru programe au stabilit sarcini urgente pentru o creștere semnificativă a productivitatea dezvoltării software, dezvoltarea metodelor industriale de planificare și proiectare a programelor, transferul tehnicilor, modelelor și metodelor organizatorice, tehnice, tehnice, economice și socio-psihologice din sfera producției materiale în sfera calculatoarelor. O abordare complexă procesele de dezvoltare, operare și întreținere a software-ului au prezentat o serie de probleme presante, a căror soluție va elimina „gâturile de sticlă” în proiectarea programelor, va reduce timpul de finalizare, va îmbunătăți selecția și adaptarea programelor existente și poate determina soarta sistemelor cu computere încorporate.

În practica dezvoltării de proiecte software mari, adesea nu există abordare unificată la evaluarea costurilor cu forța de muncă, a termenilor de muncă și a costurilor materiale, ceea ce împiedică creșterea productivității dezvoltării software și în cele din urmă gestionarea eficientă a ciclului de viață al software-ului. Deoarece un program de orice fel devine un produs (cu excepția, poate, a programelor educaționale, modele), abordarea producției sale ar trebui să fie similară în multe privințe cu abordarea producției de produse industriale, iar problemele de proiectare a software-ului devin extrem de importante . Această idee stă la baza B.U. Boehm „Software Engineering Design”, pe care l-am folosit pentru a scrie asta termen de hârtie. În această carte, proiectarea software se referă la procesul de creare a unui design pentru un produs software.

1 Ciclul de viață al software-ului

INTRODUCERE

LCPE este un proces continuu care începe din momentul în care se ia o decizie privind necesitatea creării unui software și se termină în momentul în care acesta este complet retras din exploatare.

Există mai multe abordări pentru definirea fazelor și activităților ciclului de viață al software-ului (SLLC), etapelor procesului de programare, modelelor în cascadă și spirală. Dar toate conțin componente fundamentale comune: enunțarea problemei, proiectarea soluției, implementarea, întreținerea.

Cel mai faimos și complet, poate, este structura ciclului de viață conform lui Boehm, care include opt faze. Acesta va fi prezentat mai detaliat ulterior.

Una dintre opțiunile posibile poate fi descrierea nivelului superior după Lehman, care include trei faze principale și reprezintă descrierea programului ciclului de viață în cel mai general caz.

Și, spre schimbare, iată care sunt etapele procesului de programare prezentate de D. Riley în cartea „Using the Modula-2 Language”. Această idee, după părerea mea, este foarte simplă și familiară și vom începe cu ea.

1.1 Etapele procesului de programare Riley

Introducere

Procesul de programare include patru pași (Fig. 1):

declarația problemei, adică obținerea unei idei adecvate despre ce sarcină ar trebui să îndeplinească programul;

proiectarea unei soluții la o problemă deja pusă (în general, o astfel de soluție este mai puțin formală decât programul final);

codificarea programului, adică traducerea soluției proiectate într-un program care poate fi executat pe o mașină;

suport de program, de ex. un proces continuu de remediere a erorilor din program și de adăugare de noi caracteristici.

Orez. 1.Patru pași de programare.

Programarea începe din momentul în care utilizator, adică cineva care are nevoie de un program pentru a rezolva o problemă pune o problemă analist de sistem. Utilizatorul și analistul de sistem definesc împreună declarația problemei. Acesta din urmă este apoi transferat algoritmist care este responsabil pentru proiectarea soluției. O soluție (sau algoritm) este o succesiune de operații, a căror execuție duce la rezolvarea unei probleme. Deoarece algoritmul nu este adesea adaptat pentru a fi executat pe o mașină, ar trebui tradus într-un program de mașină. Această operație este efectuată de codificator. Menținătorul este responsabil pentru modificările ulterioare ale programului. programator. Și analistul de sistem, și algoritmistul, și codificatorul și programatorul însoțitor - toți sunt programatori.

În cazul unui proiect software mare, numărul de utilizatori, analiști de sistem și algoritmi poate fi semnificativ. În plus, poate fi necesar să reveniți la pașii anteriori din cauza unor circumstanțe neprevăzute. Toate acestea servesc ca un argument suplimentar în favoarea unui proiect software atent: rezultatele fiecărui pas ar trebui să fie complete, precise și de înțeles.

1.1.1 Enunțarea problemei

Unul dintre cei mai importanți pași în programare este setarea unei probleme. Funcționează ca un contract între utilizator și programator(i). La fel ca un contract prost redactat din punct de vedere legal, o declarație de misiune proastă este inutilă. Cu o declarație bună a problemei, atât utilizatorul, cât și programatorul reprezintă în mod clar și fără ambiguitate sarcina care trebuie efectuată, de exemplu. în acest caz, sunt luate în considerare atât interesele utilizatorului, cât și ale programatorului. Utilizatorul poate planifica utilizarea software-ului care nu a fost încă creat, pe baza cunoștințelor pe care le poate. O enunțare bună a problemei servește drept bază pentru formarea soluției acesteia.

Formularea problemei (specificarea programului); în esență înseamnă o descriere precisă, completă și de înțeles a ceea ce se întâmplă atunci când un anumit program este executat. Utilizatorul privește de obicei computerul ca pe o cutie neagră: pentru el nu contează cum funcționează computerul, dar este important ca computerul să poată face ceea ce îl interesează utilizatorul. Accentul este pus pe interacțiunea dintre om și mașină.

Caracteristicile unei enunțuri bune de problemă:

Precizie, adică excluderea oricărei ambiguități. Nu ar trebui să existe nicio întrebare cu privire la ceea ce va fi rezultatul programului pentru orice intrare dată.

completitudine, adică luarea în considerare a tuturor opțiunilor pentru o intrare dată, inclusiv intrarea eronată sau neașteptată și determinarea ieșirii corespunzătoare.

Claritate, adică ar trebui să fie de înțeles atât pentru utilizator, cât și pentru analistul de sistem, deoarece declarația problemei este singurul contract între ei.

Adesea, cerințele pentru acuratețe, completitudine și claritate sunt în conflict. Astfel, multe acte juridice sunt greu de înțeles deoarece sunt scrise într-un limbaj formal care vă permite să formulați anumite prevederi cu cea mai mare precizie, excluzând chiar și cele mai nesemnificative discrepanțe. De exemplu, unele întrebări de pe lucrările de examen sunt uneori formulate atât de precis încât studentul petrece mai mult timp înțelegând întrebarea decât răspunzând la ea. Mai mult, studentul poate să nu înțeleagă deloc sensul principal al întrebării din cauza numărului mare de detalii. Cea mai bună enunțare a problemei este cea care realizează un echilibru între toate cele trei cerințe.

Forma standard a enunțului problemei.

Luați în considerare următoarea afirmație a problemei: „Introduceți trei numere și scoateți numerele în ordine”.

O astfel de afirmație nu îndeplinește cerințele de mai sus: nu este nici precisă, nici completă, nici de înțeles. Într-adevăr, numerele trebuie introduse câte unul pe linie sau toate numerele pe o singură linie? Expresia „în ordine” înseamnă ordonarea de la cel mai mare la cel mai mic, de la cel mai mic la cel mai mare sau aceeași ordine în care au fost introduse.

Este evident că o astfel de afirmație nu răspunde la multe întrebări. Dacă luăm în considerare răspunsurile la toate întrebările, atunci enunțul problemei va deveni pronunțat și greu de înțeles. Prin urmare, D. Riley propune utilizarea formularului standard pentru stabilirea problemei, care asigură acuratețea, completitudinea, claritatea maximă și include:

numele sarcinii (definiție schematică);

descriere generală (enunțare pe scurt a sarcinii);

erori (opțiunile de intrare neobișnuite sunt enumerate în mod explicit pentru a arăta utilizatorilor și programatorilor acțiunile pe care mașina le va întreprinde în astfel de situații);

exemplu ( bun exemplu poate transmite esența problemei, precum și ilustra diferite cazuri).

Exemplu. Enunțarea problemei în formularul standard.

TITLU

Sortați trei numere întregi.

DESCRIERE

Intrarea și ieșirea a trei numere întregi, sortate de la cel mai mic la cel mai mare.

Se introduc trei numere întregi, câte un număr pe linie. În acest caz, un număr întreg este una sau mai multe cifre zecimale consecutive, care pot fi precedate de un semn plus „+” sau de un semn minus „-”.

Cele trei numere întregi introduse sunt afișate, toate trei fiind afișate pe aceeași linie. Numerele adiacente sunt separate printr-un spațiu. Numerele sunt afișate de la cel mai mic la cel mai mare, de la stânga la dreapta.

1) Dacă sunt introduse mai puțin de trei numere, programul așteaptă introducerea suplimentară.

2) Liniile de intrare altele decât primele trei sunt ignorate.

3) Dacă oricare dintre primele trei linii conține mai multe numere întregi, atunci programul se închide și emite un mesaj.