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 evoluează în timp.

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

Există mai multe faze ale existenței unui produs software pe parcursul ciclului său de viață. Nu există încă nume general acceptate pentru aceste faze și numărul lor. Dar nu există 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. Întrebarea dacă o anumită partiție este mai bună decât altele nu este cea principală. Principalul lucru este să organizați corect dezvoltarea de software ținând cont de ele.

În funcție de durata ciclului de viață, produsele software pot fi împărțite în două clase: mic Și mare timp de viață. Aceste clase de programe corespund unei abordări flexibile (soft) a creării și utilizării lor și unei abordări industriale rigide pentru proiectarea și operarea reglementate a produselor software. În organizațiile științifice și universitățile, de exemplu, predomină dezvoltarea programelor de primă clasă, în timp ce în organizațiile de design și industriale - a doua.

Produse software cu o durată de viață scurtă sunt create în principal pentru a rezolva probleme științifice și de inginerie, pentru a obține rezultate specifice de calcule. Astfel de programe sunt de obicei relativ mici. Sunt dezvoltate de un specialist sau de un grup mic. Ideea principală a programului este discutată de un programator și utilizator final. Unele detalii sunt puse pe hârtie, iar proiectul este implementat în câteva zile sau săptămâni. Ele nu sunt destinate reproducerii și transferului pentru utilizare ulterioară în alte echipe. Ca atare, astfel de programe fac parte dintr-un proiect de cercetare și nu ar trebui să fie considerate produse software de unică folosință.

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

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

Întreținerea și modificarea unor astfel de programe nu este obligatorie, iar ciclul lor de viață este finalizat după primirea rezultatelor calculelor. 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

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

Produse software cu o durată lungă de viață creat pentru procesarea și gestionarea periodică a informațiilor. Structura unor astfel de programe este complexă. Dimensiunile lor pot varia într-o gamă largă (1...1000 de mii de comenzi), dar toate au proprietăți de cunoaștere și posibilitatea de modificare în procesul de întreținere și utilizare 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 sunt produse software înstrăinate de la 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 formalizate 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 cade pe operare și întreținere. Datorită replicării în masă și întreținerii pe termen lung, costurile totale în timpul exploatării și întreținerii unor astfel de produse software depășesc semnificativ costurile de analiză și proiectare a sistemului.

Toate prezentările ulterioare se concentrează pe dezvoltarea 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 de sistem:

a) cercetare;

b) studiu de fezabilitate:

operațional;

Economic;

Comercial.

II. Proiectare software:

a) proiectare:

Descompunerea funcțională a sistemului, arhitectura acestuia;

Proiectare software extern;

Proiectare baze de date;

Arhitectura software;

b) programare:

Proiectare software intern;

Proiectare externă a modulelor software;

Proiectare internă a modulelor software;

Codificare;

Programe de depanare;

Aspectul programului;

c) depanare software.

III. Evaluarea (testarea) software-ului.

IV. Utilizare software:

a) exploatare;

b) sprijin.

eu. Analiza de sistem. La începutul dezvoltării software, se efectuează o analiză a sistemului (proiectarea sa preliminară), în timpul căreia se determină necesitatea acestuia, scopul și principalele caracteristici funcționale. Sunt estimate costurile și eficiența posibilă a aplică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 implementării cărora se dezvoltă proiectul în sine. În faza de analiză a sistemului se pot distinge două domenii: cercetare și analiza de fezabilitate.

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

Lucrarea constă în planificarea și coordonarea acțiunilor necesare întocmirii unei liste oficiale scrise de mână de cerințe pentru produsul software dezvoltat.

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

Studiu de fezabilitate există o parte tehnică a cercetării ș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 distribuirea resurselor (forța de muncă).

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

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

- fezabilitate economica , Costul produsului dezvoltat este acceptabil? Care este acest cost? Va fi produsul un instrument rentabil în mâinile utilizatorului?

- fezabilitate comerciala, Va fi produsul atractiv, comercializabil, ușor de instalat, util, ușor de învățat?

Acestea și alte întrebări trebuie abordate în principal atunci când se iau î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 lucrările la proiect, este necesar să vă asigurați că sunt primite toate informațiile necesare. Aceste informații trebuie să fie corecte, înțelese și aplicabile. Ar trebui să fie un set complet de cerințe care să satisfacă utilizatorul pentru produsul software dezvoltat, întocmit sub forma unui caiet de sarcini.

Dacă această cerință nu este respectată, este posibilă încetinirea semnificativă a implementării proiectului în viitor din cauza solicitărilor repetate și repetate adresate utilizatorului de clarificare a detaliilor interpretate incorect, a condițiilor nespecificate și, în consecință, va fi necesar să se relucrați părțile deja dezvoltate ale acestuia.

Adesea, în perioada analizei 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ă tipuri diferite activitatea proiectului și poate fi împărțit în trei etape principale: proiectarea, programarea și depanarea unui produs software.

Constructie Dezvoltarea software-ului începe de obicei încă din faza studiului de fezabilitate, de îndată ce unele obiective și cerințe preliminare pentru acesta sunt fixate pe hârtie.

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

În acest segment al vieții software-ului, se efectuează următoarele:

Descompunerea funcțională a problemei care se rezolvă, pe baza căreia se determină arhitectura sistemului acestei probleme;

Design extern de software, exprimat sub forma interacțiunii sale externe cu utilizatorul;

Proiectarea bazei de date, dacă este necesar;

Proiectare arhitectură software - definirea obiectelor, modulelor și interfațarea acestora.

Începe programarea deja în faza de construcție, de îndată ce specificațiile principale pentru componentele individuale ale produsului software devin disponibile, dar nu înainte de aprobarea acordului de cerințe. Suprapunerea dintre fazele de programare și construcție are ca rezultat economii în timpul general de dezvoltare, precum și asigurarea de validare a deciziilor de proiectare și, în unele cazuri, are un impact asupra problemelor cheie.

În această etapă se efectuează lucrările asociate cu asamblarea produsului software. Constă într-o proiectare internă detaliată a unui produs software, în dezvoltarea logicii interne a fiecărui modul al sistemului, care este apoi exprimată în textul unui anumit program.

Faza de programare se termină când dezvoltatorii au terminat de documentat, depanat și de conectat părțile individuale ale produsului software într-un întreg.

Depanare software se realizează după ce toate componentele sale sunt depanate separat și asamblate într-o singură software.

III. Evaluarea (testarea) software-ului.În această fază, produsul software este supus testării riguroase a sistemului de către un grup de non-dezvoltatori.

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

Faza de evaluare începe odată ce toate componentele (modulele) au fost puse împreună ș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 funcționare.

Continuă atâta timp cât se programează.

IV. Utilizarea software-ului. Dacă analiza sistemului este un îndemn la acțiune, designul este un atac și o întoarcere cu o victorie, atunci folosirea unui produs software este o apărare zilnică, vitală, dar de obicei nu onorabilă pentru dezvoltatori.

O astfel de comparație este adecvată având în vedere faptul că în timpul utilizării unui produs software, erorile care s-au strecurat în timpul proiectării acestuia sunt corectate.

Faza de utilizare a produsului 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 realizează pregătirea personalului, implementarea, configurarea, întreținerea și, eventual, extinderea produsului software - așa-numita proiectare continuă.

Faza de utilizare se încheie atunci când produsul este retras din utilizare și încetează activitățile menționate mai sus. Rețineți, totuși, că produsul software poate fi utilizat de altcineva pentru o lungă perioadă de timp după încheierea fazei de utilizare, așa cum este definită aici. Deoarece cineva poate folosi cu succes produsul software chiar și fără ajutorul unui dezvoltator.

Utilizarea produsului software este determinată de funcționarea și întreținerea acestuia.

Funcționarea produsului software constă în executarea acestuia, funcționarea acestuia pe un computer pentru prelucrarea informațiilor și în obținerea rezultatelor care constituie scopul creării acestuia, precum și în asigurarea fiabilității și fiabilității datelor emise.

Întreținere software consta in intretinere, dezvoltare funcţionalitate si ridicarea caracteristici de performanta multe produse software, în duplicarea și transferul produsului software către tipuri diferite mijloace de calcul.

Întreținerea joacă rolul de feedback necesar din faza de funcționare.

În timpul funcționării software-ului, este posibilă detectarea erorilor în programe și devine necesară modificarea acestora și extinderea funcțiilor acestora.

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 instanțele software, următoarea versiune a produsului software le înlocuiește pe cele utilizate anterior sau pe unele dintre ele. În același timp, procesul de operare a produsului software poate fi practic continuu, deoarece înlocuirea versiunii produsului software este pe termen scurt. Aceste circumstanțe duc la faptul că procesul de operare a unei versiuni a unui produs software rulează de obicei în paralel și independent de faza de întreținere.

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

Suprapunerile între diferitele faze ale ciclului de viață al produsului software sunt posibile și de obicei de dorit. Cu toate acestea, nu ar trebui să existe o suprapunere între procesele necontigue.

Feedback-ul între faze este posibil. 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 considerat al ciclului de viață al unui produs software, cu unele modificări, poate servi și ca model pentru proiecte mici.

De exemplu, atunci când un singur program este proiectat, deseori se face fără proiectarea arhitecturii sistemului și

proiectarea bazei de date; procesele de proiectare externă inițială și detaliată se îmbină adesea împreună etc.

Subiect: Modele clasice și flexibile ale LCPP: definiție, descriere, trăsături distinctive, succesiunea pașilor. Metode de alegere a unui model de ZhCPP în dezvoltarea de software în diverse domenii.

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

Modelul ciclului de viață al software-ului 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ță 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 propune un model specific de ciclu de viață și metode de dezvoltare software. Prevederile sale sunt comune oricăror modele 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 activităților ș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 unite în etape (faze), a căror implementare este necesară și suficientă pentru a crea un software care să îndeplinească cerințele specificate.

Etapa (faza) creării software-ului este înțeleasă ca parte a procesului de dezvoltare software, 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țele specificate. pentru această etapă. Etapele creării software-ului se disting din motive de planificare rațională și organizare a muncii, terminând cu rezultatele specificate. Ciclul de viață al software-ului include de obicei următoarele etape:

1. formarea cerințelor software;
2. proiectarea (dezvoltarea unui proiect de sistem);
3. implementare (poate fi împărțit în sub-etape: proiectare detaliată, codificare);
4. testare (pot fi împărțite în testare și integrare autonome și complexe);
5. punere în funcțiune (implementare);
6. operare si intretinere;
7. dezafectare.

Unii experți introduc o etapă inițială suplimentară - studiu de fezabilitate sisteme. Aceasta se referă la sistemul software și hardware 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ă în mare măsură (chiar decisiv!) succesul întregului proiect. Începutul acestei etape este obținerea unei arhitecturi de sistem aprobate și aprobate cu includerea acordurilor de bază privind distribuția funcțiilor între hardware și software. Acest document ar trebui să conțină, de asemenea, o confirmare a ideii generale a funcționării software-ului, inclusiv principalele acorduri privind distribuția funcțiilor între persoană și sistem.

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

1. Planificarea lucrărilor înainte de proiect. Sarcinile principale ale etapei sunt definirea obiectivelor de dezvoltare, preliminare evaluare economică proiect, construirea unui program de lucru, crearea și formarea unui grup de lucru comun.
2. Efectuarea unui studiu asupra activităților unei organizații (obiect) automatizate, în cadrul căreia se realizează o identificare preliminară a cerințelor pentru viitorul sistem, determinarea structurii organizației, determinarea listei de funcții țintă ale organizației, analizarea distribuția funcțiilor pe departamente și angajați, identificarea interacțiunilor funcționale între departamente, a fluxurilor de informații în cadrul departamentelor și între acestea, exterioare organizării obiectelor și externe. influențează informația, analiza mijloacelor existente de automatizare a activitatilor organizatiei.

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

• un model „AS-IS” („așa cum este”) care reflectă starea actuală a lucrurilor din organizație la momentul sondajului și vă permite să înțelegeți cum funcționează organizația, precum și să identificați blocajele și să formulați propuneri pentru îmbunătățirea situatie;
• Modelul „TO-BE” („cum ar trebui să fie”), reflectând ideea noilor tehnologii ale activității organizației.

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 un independent valoare practică, indiferent dacă întreprinderea va dezvolta și implementa un sistem informațional, deoarece acestea pot fi folosite pentru a instrui angajații și a îmbunătăți procesele de afaceri ale întreprinderii.

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

Etapa de proiectare include următorii pași.

1. Dezvoltarea unui proiect de sistem software. În această etapă se dă răspunsul la întrebarea „Ce ar trebui să facă viitorul sistem?” și anume: arhitectura sistemului, funcțiile acestuia, condițiile externe de funcționare, interfețele și distribuția funcțiilor între utilizatori și sistem, cerințele pentru se determină componente software și informaționale, componența performanților și termenele limită, dezvoltarea, planul de depanare software și controlul calității.

   La baza proiectului de sistem sunt modelele sistemului proiectat, care sunt construite pe modelul „TO-BE”. Rezultatul dezvoltării unui proiect de sistem ar trebui 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.

2. Elaborarea unui proiect (tehnic) detaliat. Î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 inter-module pentru date și control;
• specificarea fiecărei componente software, nume, scop, ipoteze, dimensiuni, secvență de apeluri, date de intrare și ieșire, eronate ieșiri, algoritmiși circuite logice;
• formarea structurilor de date fizice și logice până la nivelul câmpurilor individuale;
• elaborarea unui plan de distribuție a resurselor de calcul (timpul procesoarelor centrale, memorie etc.);
• verificarea completității, coerenței, fezabilității și validității cerințelor;
• plan preliminar de integrare și depanare, ghid de utilizare și plan de testare de acceptare.

Finalizarea etapei de proiectare detaliată este controlul de la capăt la capăt al proiectului sau analiza blocului critic al proiectului.

Etapa de implementare – executia urmatoarelor lucrari.

1. Dezvoltarea unei specificații detaliate verificate pentru fiecare subrutină (un bloc de nu mai mult de 100 de comenzi sursă dintr-un limbaj de nivel înalt).

   Specificațiile externe trebuie să conțină următoarele informații:

   • nume modul - este indicat numele folosit pentru apelarea modulului (pentru un modul cu mai multe intrări, trebuie să existe specificații separate pentru fiecare intrare);
   • function - defineste functia sau functiile efectuate de modul;
   • lista parametrilor (numar si ordine) trecuti la modul;
   • parametrii de intrare - o descriere exactă a tuturor datelor returnate de modul (trebuie determinat comportamentul modulului în orice condiții de intrare);
   • efecte externe (tipărirea unui mesaj, citirea unei solicitări de la terminal etc.).
2. Proiectarea logicii modulelor si programarea modulelor (codare).
3. Verificarea corectitudinii modulelor.
4. Testarea modulelor.
5. Descrierea bazei de date până la nivelul parametrilor, simbolurilor și biților individuali.
6. Planul de testare de acceptare.
7. Manualul utilizatorului.
8. Plan preliminar de integrare și depanare. Conținutul etapelor ulterioare coincide practic cu procesele corespunzătoare ale ciclului de viață al software-ului. În general, etapele tehnologice se disting pe baza considerațiilor de planificare și organizare a muncii rezonabile și raționale. O posibilă variantă a relației și etapelor de lucru cu procesele ciclului de viață al software-ului este prezentată în figură.

Orez. unu.

Tipuri de modele de ciclu de viață software

Model cascadă (ciclu de viață clasic)

Acest model își datorează apariția lui W. Royce (1970). Modelul are un alt nume - o cascadă (cascada). Particularitatea modelului este că trecerea la următoarea etapă se realizează numai după ce lucrarea din etapa anterioară este complet finalizată; Revenirea la etapele finalizate nu este furnizată.

Cerințele pentru PS dezvoltat, determinate la etapele de formare și analiză, sunt strict documentate sub formă de TOR și sunt fixate pe toată durata derulării proiectului. Fiecare etapă se încheie cu lansarea unui set complet de documentație (TOR, EP, TP, RP), suficient pentru ca dezvoltarea să fie continuată de o altă echipă de dezvoltare. Criteriul pentru calitatea dezvoltării cu această abordare este acuratețea îndeplinirii specificațiilor TOR. Atenția principală a dezvoltatorilor este concentrată pe atingerea valorilor optime ale caracteristicilor tehnice ale PS dezvoltat - performanță, cantitatea de memorie ocupată etc.

Avantaje model de cascadă:

• la fiecare etapă se formează un set complet documentatia proiectului, care îndeplinește criteriile de completitudine și coerență;
• etapele de lucru efectuate într-o secvență logică vă permit să planificați momentul finalizării tuturor lucrărilor și costurile corespunzătoare.

Abordarea în cascadă s-a dovedit bine în construirea de PS, pentru care toate cerințele pot fi formulate complet și clar chiar de la începutul proiectului. Atâta timp cât toate acestea sunt controlate de standarde și diferite comisii de acceptare de stat, schema funcționează bine.

dezavantaje model de cascadă:

• identificarea și eliminarea erorilor se realizează numai în etapa de testare, care poate fi extinsă semnificativ;
• proiectele reale necesită adesea abateri de la secvența standard de pași;
• ciclul se bazează pe formularea exactă a cerințelor inițiale pentru PS, în realitate, la începutul proiectului, cerințele clientului sunt doar parțial definite;
• rezultatele lucrării sunt disponibile clientului numai după finalizarea proiectului.

Model iterativ al ciclului de viață al PS

Odată cu creșterea proiectelor comerciale, a devenit clar că nu este întotdeauna posibil să se elaboreze proiectarea viitorului sistem în detaliu, deoarece multe aspecte ale funcționării acestuia în zone dinamice de activitate (afaceri) se schimbă în timpul creării sistemului. A fost necesară modificarea procesului de dezvoltare pentru a se asigura că s-au făcut corecțiile necesare după finalizarea oricărei etape de dezvoltare. Așa a apărut modelul iterativ al ciclului de viață al PS, numit model cu control intermediar sau model cu repetare ciclică a fazelor.

Într-un model iterativ, deficiențele de proiectare și programare pot fi eliminate ulterior prin revenirea parțială la etapa anterioară. Cu cât rata de detectare a erorilor este mai mică, cu atât este mai costisitoare să o remediați. Dacă costul eforturilor necesare pentru detectarea și eliminarea erorilor în etapa de scriere a codului este luat ca unul, atunci costul identificării și eliminării unei erori în etapa cerințelor va fi de 5-10 ori mai mic, iar costul identificării și eliminarea unei erori în faza de întreținere va fi de 20 de ori mai mică.mai mult.

Într-o astfel de situație, etapa de formulare a cerințelor, întocmirea caietului de sarcini și realizarea unui plan de sistem este de mare importanță. Arhitecții software sunt personal responsabili pentru toate modificările ulterioare ale deciziilor de proiectare. Volumul documentației se ridică la mii de pagini, numărul ședințelor de aprobare este uriaș. Multe proiecte nu părăsesc niciodată etapa de planificare, căzând în paralizia analizei. Una dintre modalitățile posibile de a evita astfel de situații este breadboarding (prototiparea).

Prototiparea

Adesea, clientul nu poate formula cerințe pentru intrarea, procesarea sau ieșirea datelor pentru un viitor produs software. Dezvoltatorul se poate îndoi de adecvarea produsului pentru sistemul de operare, sub forma unui dialog cu utilizatorul, sau de eficacitatea algoritmului. În astfel de cazuri, este recomandabil să folosiți prototipuri. Scopul principal al prototipării este de a elimina incertitudinea în cerințele clientului. Modelarea (prototiparea) este procesul de creare a unui model al produsului necesar.

Modelul poate lua următoarele forme.

1. Machetă pe hârtie (diagrama desenată manual a dialogului om-mașină) sau machetă pe computer.
2. Un aspect de lucru care implementează unele dintre funcționalitățile necesare.
3. Un program existent ale cărui caracteristici trebuie îmbunătățite.

După cum se arată în figură, prototipul se bazează pe iterații repetate la care participă clientul și dezvoltatorul.

Secvența de acțiuni pentru prototipare este prezentată în figură. Prototiparea începe cu colectarea și specificarea cerințelor pentru sistemul software creat. Dezvoltatorul și clientul definesc împreună obiectivele software-ului, stabilesc ce cerințe sunt cunoscute și care urmează să fie redefinite. Apoi se realizează proiectarea rapidă. Se concentrează pe caracteristicile care ar trebui să fie vizibile pentru utilizator. Proiectarea rapidă duce la construirea unui layout. Aspectul este evaluat de către client și este folosit pentru a clarifica cerințele software. Iterațiile continuă până când aspectul dezvăluie toate cerințele clientului și îi permite dezvoltatorului să înțeleagă ce trebuie făcut.

Avantajul prototipării este capacitatea de a se asigura că cerințele complete ale sistemului sunt definite. Dezavantaje aspect:

• clientul poate prelua aspectul produsului;
• dezvoltatorul poate confunda aspectul cu produsul.

Neajunsurile ar trebui explicate. Când clientul vede o versiune funcțională a PS, el încetează să realizeze că, în căutarea unei versiuni funcționale a PS, multe probleme de calitate și comoditatea de acompaniament sisteme. Atunci când dezvoltatorul îi spune clientului despre acest lucru, răspunsul poate fi indignarea și o cerere pentru transformarea rapidă a aspectului într-un produs funcțional. Acest lucru afectează negativ managementul dezvoltării software.

Pe de altă parte, pentru a obține rapid un aspect funcțional, dezvoltatorul face adesea anumite compromisuri. De exemplu, pot fi folosite limbaje de programare neadecvate sau sistem de operare. Pentru o demonstrație simplă, poate fi utilizat un algoritm (simplu) ineficient. După ceva timp, dezvoltatorul uită de motivele pentru care aceste instrumente nu sunt potrivite. Ca rezultat, o opțiune selectată departe de a fi ideală este integrată în sistem.

Înainte de a analiza alte modele de ciclu de viață a software-ului care au înlocuit model de cascadă, ar trebui să ne oprim asupra strategiilor de proiectare sisteme software. Strategia de proiectare software este cea care determină în mare măsură modelul ciclului de viață al software-ului.

Strategii de proiectare software

Există trei strategii pentru construirea de sisteme software:

• o singură trecere (strategia în cascadă discutată mai sus) - o secvență liniară a pașilor de proiectare;
• strategie incrementală. La începutul procesului, toate cerințele utilizatorului și ale sistemului sunt determinate, restul construcției se realizează ca o serie de versiuni. Prima versiune implementează unele dintre caracteristicile planificate, următoarea versiune implementează caracteristici suplimentare și așa mai departe până când se obține sistemul complet;
• strategie evolutivă. Sistemul este construit și ca o serie de versiuni, dar nu toate cerințele sunt definite la începutul procesului. Cerințele sunt specificate ca urmare a dezvoltării versiunilor. Caracteristicile strategiilor de proiectare software în conformitate cu cerințele standardului IEEE/EIA 12207 sunt prezentate în Tabelul 1.

model incremental

Modelul incremental este un exemplu clasic de strategie de proiectare incrementală. Combină elemente ale unui model de cascadă secvenţial cu o filozofie iterativă de aspect (propusă de B. Boehm ca o îmbunătăţire). model de cascadă). Fiecare secvență de linii aici generează un increment de software furnizat. De exemplu, software-ul de procesare de text în primul increment (versiunea) implementează funcții de bază de procesare a fișierelor, editare și documentare; în al 2-lea pas - capabilități de editare și documentare mai sofisticate; în a 3-a increment - verificare ortografică și gramaticală; în al 4-lea increment - capabilități de aspect de pagină.

Prima creștere are ca rezultat un produs de bază care implementează cerințele de bază (cu toate acestea, multe cerințe auxiliare rămân nerealizate). Planul pentru următorul increment implică modificarea produsului de bază pentru a oferi caracteristici și funcționalități suplimentare.

Prin natura sa, procesul incremental este iterativ, dar spre deosebire de breadboarding, modelul incremental oferă un produs de lucru la fiecare increment.

O diagramă a unui astfel de model de ciclu de viață al software-ului este prezentată în figură. Una dintre implementările moderne ale abordării incrementale este programarea extremă (concentrată pe incremente foarte mici de funcționalitate).

Modelul ciclului de viață al software-ului în spirală

model în spirală este un exemplu clasic de strategie de proiectare evolutivă. Modelul (autor B. Boehm, 1988) se bazează pe cele mai bune proprietăți ale ciclului de viață clasic și prototipării, la care se adaugă un nou element - analiza riscului, care este absentă în aceste paradigme. Modelul definește patru activități reprezentate de cele patru cadrane ale spiralei.

1. Planificarea este definirea obiectivelor, opțiunilor și constrângerilor.
2. Analiza riscurilor – analiza opțiunilor și recunoașterea/selectarea riscurilor.
3. Ingineria este următorul nivel de dezvoltare a produsului.
4. Evaluare - evaluarea de către client a rezultatelor actuale de proiectare.

Aspect integrator model în spirală este evident când se consideră dimensiunea radială a helixului. Cu fiecare iterație, din ce în ce mai mult versiuni complete PS. În prima tură a spiralei sunt definite obiectivele inițiale, opțiunile și constrângerile, riscul este recunoscut și analizat. Dacă analiza de risc relevă incertitudinea cerințelor, prototipul utilizat în cadranul de proiectare vine în sprijinul dezvoltatorului și al clientului.

Modelarea poate fi utilizată pentru a identifica în continuare cerințele problematice și rafinate. Clientul evaluează lucrările de inginerie (proiectare) și face propuneri de modificări (cadrantul de evaluare a clientului). Următoarea fază de planificare și analiză de risc se bazează pe sugestiile clienților. În fiecare ciclu prin spirală, rezultatele analizei de risc se formează sub forma „continuați, nu continuați”. Dacă riscul este prea mare, proiectul poate fi oprit.

În cele mai multe cazuri, spirala continuă, fiecare pas împingând dezvoltatorii către un model de sistem mai general. Fiecare buclă din spirală necesită un construct (cadrantul din dreapta jos), care poate fi implementat printr-un ciclu de viață sau o machetă clasică. Rețineți că numărul activităților de dezvoltare (care au loc în cadranul din dreapta jos) crește pe măsură ce vă îndepărtați de centrul spiralei.

Aceste acțiuni sunt numerotate și au următorul conținut:

1. – colectarea cerințelor inițiale și planificarea proiectului;
2. – aceeași lucrare, dar pe baza recomandărilor clientului;
3. – analiza riscului pe baza cerințelor inițiale;
4. – analiza riscului pe baza răspunsului clientului;
5. – trecerea la un sistem integrat;
6. – aspectul inițial al sistemului;
7. - nivelul următor al layout-ului;
8. – sistem proiectat;
9. - Evaluare de catre client.

Avantaje model în spirală:

1. cel mai realist (sub formă de evoluție) reflectă dezvoltarea software-ului;
2. vă permite să luați în considerare în mod explicit riscul în fiecare etapă a evoluției dezvoltării;
3. include pasul abordarea sistemelorîntr-o structură de dezvoltare iterativă;
4. folosește simularea pentru a reduce riscul și a îmbunătăți produsul software.

dezavantaje model în spirală:

• noutate comparativă (nu există suficiente statistici privind eficacitatea modelului);
• cerințe crescute pentru client;
• Dificultăți în monitorizarea și gestionarea timpului de dezvoltare.

Modelul procesului de dezvoltare în spirală este cel mai comun în prezent. Cele mai cunoscute variante ale sale sunt RUP (Rational Unified Process) de la Rational și MSF (Microsoft Solution Framework). UML (Unified Modeling Language) este folosit ca limbaj de modelare. Crearea sistemului se presupune a fi efectuată în mod iterativ, deplasându-se în spirală și trecând prin aceleași etape, la fiecare pas pentru a rafina caracteristicile viitorului produs. S-ar părea că acum totul este în regulă: doar ceea ce poate fi prevăzut este planificat, ceea ce este planificat este dezvoltat, iar utilizatorii încep să se familiarizeze cu produsul din timp, având posibilitatea de a face ajustările necesare.

Cu toate acestea, acest lucru necesită fonduri foarte mari. Într-adevăr, dacă mai devreme era posibil să se creeze și să dizolve grupuri de specialiști la nevoie, acum toți trebuie să participe constant la proiect: arhitecți, programatori, testeri, instructori etc. Mai mult, eforturile diverse grupuri trebuie să fie sincronizate pentru a reflecta deciziile de proiectare în timp util și pentru a face modificările necesare.

Proces rațional unificat

Raţional proces unificat(Rational Unified Process, RUP) este una dintre cele mai bune metodologii de dezvoltare software. Bazat pe experiența multor proiecte software de succes, RUP vă permite să creați sisteme software complexe bazate pe metode de dezvoltare industrială. Condițiile preliminare pentru dezvoltarea RUP au apărut la începutul anilor 1980. la corporația Rational Software. La începutul anului 2003, Rational a achiziționat IBM. Unul dintre principalii piloni pe care se bazează RUP este procesul de creare a modelelor folosind Unified Modeling Language (UML).

RUP este una dintre metodologiile de dezvoltare software în spirală. Metodologia este întreținută și dezvoltată de Rational Software. Baza comună de cunoștințe folosește Unified Modeling Language (UML) ca limbaj de modelare. Dezvoltarea software iterativă și incrementală în RUP implică împărțirea unui proiect în mai multe proiecte care sunt executate secvențial, iar fiecare iterație de dezvoltare este clar definită de un set de obiective care trebuie atinse la sfârșitul iterației. Iterația finală presupune că setul de obiective al iterației trebuie să se potrivească exact cu setul de obiective specificat de clientul produsului, adică toate cerințele trebuie îndeplinite.

Procesul presupune evoluția modelelor; o iterație a ciclului de dezvoltare corespunde în mod unic unei anumite versiuni a modelului software. Fiecare dintre iterații conține controale ciclul de viață al software-ului: analiză și proiectare (modelare), implementare, integrare, testare, implementare. În acest sens, RUP este o implementare model în spirală, deși este destul de des descris sub forma unui tabel grafic.

Această figură prezintă două dimensiuni: axa orizontală reprezintă timpul și prezintă aspectele temporale ale ciclului de viață al procesului; axa verticală reprezintă disciplinele care definesc structura fizică a procesului. Puteți vedea cum se schimbă accentul în proiect în timp. De exemplu, iterațiile timpurii petrec mai mult timp pe cerințe; în iterațiile ulterioare, mai mult timp este dedicat implementării. Axa orizontală este formată din perioade de timp - iterații, fiecare dintre acestea fiind un ciclu de dezvoltare independent; scopul ciclului este de a aduce un anumit rafinament tangibil predeterminat produsului final care este util din punctul de vedere al părților interesate.

De-a lungul axei timpului, ciclul de viață este împărțit în patru faze principale.

1. Start (Incepție) - formarea conceptului de proiect, înțelegerea a ceea ce creăm, o idee despre produs (viziune), dezvoltarea unui plan de afaceri (caz de afaceri), pregătirea unui program prototip sau o soluție parțială. Aceasta este faza de colectare a informațiilor și analiza cerințelor, definirea imaginii proiectului în ansamblu. Scopul este de a obține sprijin și finanțare. În ultima iterație, rezultatul acestei etape este termenii de referință.
2. Proiectare, dezvoltare (Elaborare) - clarificarea planului, înțelegerea modului în care îl creăm, proiectarea, planificarea acțiunilor și resurselor necesare, detalierea caracteristicilor. Etapa se încheie cu o arhitectură executabilă, când se iau toate deciziile arhitecturale și se iau în considerare riscurile. O arhitectură executabilă este un software care rulează care demonstrează implementarea principalului solutii arhitecturale. În ultima iterație, acesta este un proiect tehnic.
3. Implementarea, crearea sistemului (Constructia) este etapa de extindere a functionalitatii sistemului incorporat in arhitectura. În ultima iterație, acesta este un proiect de lucru.
4. Implementare, implementare (Tranziție). Crearea versiunii finale a produsului. Faza de implementare a produsului, livrarea produsului către un anumit utilizator (replicare, livrare și instruire).

Axa verticală este formată din discipline, fiecare dintre acestea putând fi descrisă mai detaliat în ceea ce privește sarcinile îndeplinite, rolurile responsabile pentru acestea, produsele care sunt introduse în sarcini și eliberate în timpul executării acestora etc.

De-a lungul acestei axe se află disciplinele cheie ale ciclului de viață RUP, care sunt adesea numite procese în limba rusă, deși acest lucru nu este în întregime adevărat din punctul de vedere al acestei metodologii, susținută de instrumente IBM (și/sau terțe părți).

1. Analiza și modelarea afacerilor ( Business modeling ) asigură implementarea principiilor modelării pentru a studia afacerea organizației și a acumula cunoștințe despre aceasta, a optimiza procesele de afaceri și a lua decizii cu privire la automatizarea lor parțială sau completă.
2. Managementul cerințelor se referă la preluarea informațiilor de la părțile interesate și transformarea acestora într-un set de cerințe care definesc conținutul sistemului în curs de dezvoltare și detaliază așteptările cu privire la ceea ce ar trebui să facă sistemul.
3. Analiza și proiectarea (Analiză și proiectare) acoperă procedurile de transformare a cerințelor în descrieri intermediare (modele) reprezentând modul în care aceste cerințe ar trebui implementate.
4. Implementarea acoperă dezvoltarea codului, testarea la nivel de dezvoltator și integrarea componentelor, subsistemelor și întregului sistem în conformitate cu specificațiile stabilite.
5. Testarea este dedicată evaluării calității produsului creat.
6. Implementarea acoperă operațiunile care au loc în livrarea produselor către clienți și în punerea produsului la dispoziția utilizatorilor finali.
7. Managementul configurației și managementul schimbărilor (Configuration management) este dedicat sincronizării produselor intermediare și finale și gestionării dezvoltării acestora în timpul proiectului și găsirii problemelor ascunse.
8. Managementul de proiect este dedicat planificării proiectelor, managementului riscului, monitorizării progresului proiectului și evaluării continue a indicatorilor cheie.
9. Mediul de management (Mediul) include elemente ale formării mediului de dezvoltare Sistem informaticși sprijin pentru activitățile proiectului.

În funcție de specificul proiectului, pot fi utilizate orice instrumente IBM Rational, precum și instrumente terțe. RUP recomandă următoarele șase practici pentru dezvoltarea de succes a proiectelor: dezvoltare iterativă; managementul cerințelor; utilizarea arhitecturilor modulare; modelare vizuală; verificarea calitatii; urmărirea modificărilor.

O parte integrantă a RUP sunt artefactele (artefactul), precedentele (precedentele) și rolurile (rolul). Artefactele sunt unele dintre produsele proiectului care sunt generate sau utilizate în acesta atunci când se lucrează la produsul final. Cazurile de utilizare sunt secvențe de acțiuni efectuate de sistem pentru a produce un rezultat observabil. De fapt, orice rezultat al muncii unui individ sau a unui grup este un artefact, fie că este un document de analiză, un element model, un fișier de cod, un script de testare, o descriere a unei erori etc. Anumiți specialiști sunt responsabili pentru creând unul sau altul tip de artefact. Astfel, RUP definește clar responsabilitățile - rolurile - ale fiecărui membru al echipei de dezvoltare într-o etapă sau alta, adică când și cine ar trebui să creeze cutare sau cutare artefact. Întregul proces de dezvoltare a unui sistem software este considerat în RUP ca un proces de creare a artefactelor - de la documente de analiză inițială la module executabile, manuale de utilizare și așa mai departe.

Pentru suportul computerizat al proceselor RUP, IBM a dezvoltat o gamă largă de instrumente:

• Rational Rose-CASE- instrument de modelare vizuală sisteme informatice, care are capacitatea de a genera elemente de cod. O ediție specială a produsului - Rational Rose RealTime - vă permite să obțineți un modul executabil la ieșire;
• Rational Requisite Pro este un instrument de management al cerințelor care vă permite să creați, structurați, prioritizați, urmăriți, controlați modificările cerințelor care apar în orice stadiu al dezvoltării componentelor aplicației;
• Rational ClearQuest este un produs de management al schimbărilor și de urmărire a erorilor care se integrează strâns cu instrumentele de testare și management al cerințelor și oferă un mediu unic pentru conectarea tuturor erorilor și documentelor între ele;
• Rational SoDA este un produs pentru generarea automată a documentației de proiect care vă permite să stabiliți un standard corporativ pentru documentele interne ale companiei. De asemenea, este posibil să aduceți deja documentația standardele existente(ISO, CMM);
• Rational Purify, Rational Quantify Rational PureCoverage, instrumente de testare și depanare;
• Rational Visual Quantify este un instrument de măsurare a performanței pentru dezvoltatorii de aplicații și componente C/C++, Visual Basic și Java; ajută la identificarea și eliminarea blocajelor în performanța software-ului;
• Rational Visual PureCoverage - detectează automat zonele de cod care nu sunt testate;
• Rational ClearCase este un produs de management al configurației software (Rational's Software Configuration Management, SCM) care permite controlul versiunilor tuturor documentelor de proiect. Poate fi folosit pentru a menține mai multe versiuni ale proiectelor în același timp, comutând rapid între ele. Rational Requisite Pro acceptă actualizări și urmărește modificările cerințelor pentru echipa de dezvoltare;
• Instrumentul SQA TeamTest automatizare de testare;
• Rational TestManager este un sistem de management al testelor care reunește toate instrumentele, artefactele, scripturile și datele legate de testare;
• Rational Robot - un instrument pentru crearea, modificarea și rularea automată a testelor;
• SiteLoad, SiteCheck - instrumente pentru testarea site-urilor Web pentru performanță și link-uri întrerupte;
• Rational PerformanceStudio - Măsoară și prezice caracteristicile de performanță ale sistemelor.

Acest set de produse este în mod constant îmbunătățit și extins. De exemplu, recentul produs IBM Rational Software Architect (RSA) face parte din IBM Software Development Platform, un set de instrumente care sprijină ciclul de viață al dezvoltării sistemelor software. Produsul IBM Rational Software Architect este conceput pentru a construi modele de sisteme software dezvoltate folosind limbajul de modelare unificat UML 2.0, în primul rând modele ale arhitecturii aplicației dezvoltate. Cu toate acestea, RSA combină funcționalitatea produselor software, cum ar fi Rational Application Developer, Rational Web Developer și Rational Software Modeler, permițând astfel arhitecților și analiștilor să creeze diferite vederi ale sistemului informațional în curs de dezvoltare folosind limbajul UML 2.0, iar dezvoltatorilor să realizeze dezvoltarea. J2EE, XML, servicii web etc.

Urmând principiile RUP, Rational Software Architect vă permite să creați modelele necesare în cadrul fluxurilor de lucru ale disciplinelor precum:

• analiză și modelare de afaceri (modelare de afaceri);
• managementul cerințelor (Cerințe);
• analiză și proiectare (Analiză și proiectare);
• implementare (Implementare).

În plus, Rational Software Architect acceptă tehnologia model-driven development (MDD), care vă permite să modelați software-ul la diferite niveluri de abstractizare cu trasabilitate.

MSF (Microsoft Solution Framework)

În 1994, într-un efort de a profita la maximum de proiectele IT, Microsoft a lansat un set de linii directoare pentru proiectarea, dezvoltarea, implementarea și menținerea eficientă a soluțiilor construite pe baza tehnologiei sale. Aceste cunoștințe se bazează pe experiența dobândită de Microsoft în timp ce lucra la proiecte mari de dezvoltare și întreținere software, pe experiența consultanților Microsoft și pe tot ce a acumulat industria IT până în prezent. Toate acestea sunt prezentate sub forma a două domenii de cunoștințe interconectate și bine complementare: Microsoft Solutions Framework (MSF) și Microsoft Operations Framework (MOF).

De menționat că Microsoft a dezvoltat metodologii bazate pe metodele generale MSF pentru aplicații aplicate și specializate. Mai mult, Microsoft certifică experți special pentru cunoștințele aplicate în aplicarea MSF (de exemplu, certificarea MCTS 74-131 pentru expertiză în metodologia de management de proiect). Înainte de a afla despre metodele MSF, trebuie mai întâi să determinați ce aplicație a MSF aveți în vedere.

Cele mai populare variante de aplicație ale MSF dezvoltate de Microsoft sunt:

• metodologia de implementare a solutiilor in domeniul managementului de proiect;
• Metodologie de management de proiect IT bazată pe metodologii MSF și Agile.

Importanța variantelor aplicate de MSF este subliniată de faptul că în „versiunea pură” metodologia MSF în sine nu este folosită de Microsoft în proiectele sale IT. Proiectele Microsoft Consulting Services folosesc o metodologie hibridă între MSF și Agile. În ciuda diferențelor externe semnificative dintre versiunile aplicate ale MSF dezvoltate de experții Microsoft, baza metodelor MSF pentru acestea rămâne comună și reflectă abordări metodologice comune ale managementului iterativ al proiectelor.

MOF este conceput pentru a oferi organizațiilor care construiesc soluții IT esențiale, bazate pe produse și tehnologii Microsoft, îndrumări tehnice despre cum să-și atingă fiabilitatea, disponibilitatea, comoditatea de acompaniament(suportabilitate) și manevrabilitate (gestionabilitate). MOF abordează probleme legate de organizarea personalului și a proceselor; tehnologii și management în condiții de medii IT complexe (complexe), distribuite (distribuite) și eterogene (eterogene). MOF se bazează pe cele mai bune practici colectate în Biblioteca de infrastructură IT (ITIL) compilată de Central Computer and Telecommunications Agency, o agenție guvernamentală din Regatul Unit.

Crearea unei soluții de afaceri în timpul și bugetul alocat necesită o bază metodologică dovedită. MSF oferă metodologii dovedite pentru planificarea, proiectarea, dezvoltarea și implementarea soluțiilor IT de succes. Cu flexibilitatea, scalabilitatea și lipsa de linii directoare rigide, MSF este capabilă să răspundă nevoilor organizațiilor de orice dimensiune sau echipelor de proiect. Metodologia MSF constă din principii, modele și discipline pentru managementul personalului, proceselor, elementelor tehnologice și problemelor legate de toți acești factori tipici majorității proiectelor. MSF constă din două modele și trei discipline. Sunt detaliate în 5 documente albe. Este mai bine să începeți să studiați MSF cu modele (model de echipă de proiect, model de proces), apoi să treceți la discipline (disciplina de management de proiect, disciplina de management al riscului, disciplina de management al instruirii).

Modelul de proces MSF reprezintă o metodologie generală pentru dezvoltarea și implementarea soluțiilor IT. Particularitatea acestui model este că, datorită flexibilității sale și absenței procedurilor impuse rigid, poate fi aplicat în dezvoltarea unei game foarte largi de proiecte IT. Acest model combină proprietățile a două modele standard de producție: cascadă (cascada) și spirală (spirală). Modelul de proces din MSF 3.0 a fost și mai inovator: acoperă întregul ciclu de viață al unei soluții, de la început până la implementare. Această abordare ajută echipele de proiect să se concentreze asupra valorii de afaceri a soluției, deoarece această valoare devine reală numai după ce implementarea este finalizată și produsul este în uz.

Procesul MSF este axat pe „etapele de referință” - punctele cheie ale proiectului, care caracterizează realizarea în cadrul său a oricărui rezultat semnificativ (intermediar sau final). Acest rezultat poate fi evaluat și analizat, ceea ce presupune răspunsuri la întrebările: „Did grup de proiectînțelegerea clară a obiectivelor și domeniului proiectului?”, „Este suficient de pregătit planul de acțiune?”, „Produsul îndeplinește specificația aprobată?”, „Soluția satisface nevoile clientului?” etc.

Modelul de proces MSF ia în considerare cerințele în continuă schimbare ale proiectului. Ea pornește de la faptul că dezvoltarea unei soluții ar trebui să constea în cicluri scurte care creează o mișcare progresivă de la cele mai simple versiuni ale soluției la forma sa finală.

Caracteristicile modelului de proces MSF sunt:

• o abordare de etapă și de reper;
• abordare iterativă;
• o abordare integrată a creării și implementării soluțiilor.

Modelul de proces include astfel de faze principale ale procesului de dezvoltare, cum ar fi:

• dezvoltarea conceptului (Envisioning);
• planificare (Planificare);
• dezvoltare (Dezvoltare);
• stabilizare (stabilizare);
• implementare (Implementare).

În plus, există un numar mare de etape intermediare care arată realizarea unui anumit progres în cursul proiectului și descompun segmente mari de lucru în secțiuni mai mici, observabile. Pentru fiecare fază a modelului de proces, MSF definește:

• care (ce artefacte) este rezultatul acestei faze;
• la ce lucrează fiecare dintre grupurile de rol în această fază.

În cadrul MSF, codul, documentația, desenele, planurile și alte materiale de lucru sunt de obicei create într-o manieră iterativă. MSF vă recomandă să începeți să dezvoltați o soluție prin construirea, testarea și implementarea funcționalității sale de bază. Apoi, din ce în ce mai multe funcții sunt adăugate la soluție. Această strategie se numește strategie de versiuni. Deși o singură versiune poate fi suficientă pentru proiecte mai mici, se recomandă să nu ratați ocazia de a crea mai multe versiuni pentru o singură soluție. Odată cu crearea de noi versiuni, funcționalitatea soluției evoluează.

O abordare iterativă a procesului de dezvoltare necesită utilizarea unei documentații flexibile. Documentele vii ar trebui să se schimbe pe măsură ce proiectul evoluează, împreună cu modificările cerințelor pentru produsul final. MSF oferă o serie de șabloane standard de documente care sunt artefacte ale fiecărei etape de dezvoltare a produsului și pot fi utilizate pentru a planifica și controla procesul de dezvoltare.

O soluție nu are valoare comercială până când este implementată. Din acest motiv, modelul de proces MSF conține întregul ciclu de viață al creării unei soluții, inclusiv implementarea acesteia, până în momentul în care soluția începe să ofere valoare.

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 aceste sau acele 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.

Ciclul de viață al software-ului

Ciclul de viață al software-ului este o perioadă de timp care începe din momentul în care se ia decizia privind necesitatea creării unui produs software și se termină în momentul retragerii sale complete din funcționare. (IEEE Std 610.12)

Necesitatea de a determina etapele ciclului de viață al software-ului (LC) se datorează dorinței dezvoltatorilor de a îmbunătăți calitatea software-ului prin gestionarea optimă a dezvoltării și utilizarea diferitelor mecanisme de control al calității în fiecare etapă, de la stabilirea sarcinilor până la suport pentru crearea de software. . Cea mai generală reprezentare a ciclului de viață al software-ului este un model sub formă de etape de bază - procese, care includ:

Analiza sistemului și justificarea cerințelor software;

Proiectare software preliminară (schiță) și detaliată (tehnică);

Dezvoltarea componentelor software, integrarea acestora și depanarea software în general;

Testare, operare de probă și replicare de software;

Operarea regulată a software-ului, întreținerea funcționării și analiza rezultatelor;

Întreținerea software-ului, modificarea și îmbunătățirea acestuia, crearea de noi versiuni.

Acest model este general acceptat și corespunde atât cu cele domestice documente de reglementareîn domeniul dezvoltării software, și străine. Din punctul de vedere al asigurării securității tehnologice, este recomandabil să se ia în considerare mai detaliat caracteristicile reprezentării etapelor ciclului de viață în modele străine, deoarece software-ul străin este cel mai probabil purtător al defectelor software ale tip sabotaj.

Standardele ciclului de viață al software-ului

GOST 34.601-90

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

Reprezentarea grafică a modelelor ciclului de viață vă permite să evidențiați vizual caracteristicile acestora și unele proprietăți ale proceselor.

Inițial, a fost creat un model în cascadă al ciclului de viață, în care etapele majore au început una după alta folosind rezultatele lucrărilor anterioare. Acesta prevede implementarea succesivă a tuturor etapelor proiectului într-o ordine strict fixă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrării în etapa anterioară. Cerințele definite în etapa de formare a cerințelor sunt strict documentate sub formă de termeni de referință și fixate pe întreaga durată a dezvoltării proiectului. Fiecare etapă culminează cu lansarea unui set complet de documentație suficientă pentru ca dezvoltarea să fie continuată de o altă echipă de dezvoltare. Inexactitatea oricărei cerințe sau interpretarea ei incorectă ca urmare duce la faptul că trebuie să „retragi” la faza incipientă a proiectului, iar revizuirea necesară nu numai că scoate echipa de proiect în afara programului, dar duce adesea la o creșterea calitativă a costurilor și, este posibil, până la rezilierea proiectului în forma în care a fost conceput inițial. Principala eroare a autorilor modelului cascadă este presupunerea că proiectarea trece prin întregul proces o dată, arhitectura proiectată este bună și ușor de utilizat, proiectarea implementării este rezonabilă și erorile în implementare sunt ușor eliminate cu testarea. Acest model presupune că toate erorile vor fi concentrate în implementare și, prin urmare, eliminarea lor are loc uniform în timpul testării componentelor și a sistemului. Astfel, modelul cascadă pentru proiecte mari nu este foarte realist și poate fi folosit eficient doar pentru a crea sisteme mici.

Cel mai specific este modelul spiral al ciclului de viață. În acest model, atenția este concentrată asupra procesului iterativ al etapelor inițiale de proiectare. În aceste etape, conceptele, specificațiile cerințelor, proiectarea preliminară și detaliată sunt create succesiv. La fiecare rundă se precizează conținutul lucrării și se concentrează aspectul software-ului creat, se evaluează calitatea rezultatelor obținute și se planifică munca următoarei iterații. La fiecare iterație se evaluează următoarele:

Riscul depășirii termenilor și costului proiectului;

Necesitatea de a efectua o altă iterație;

Gradul de completitudine și acuratețe al înțelegerii cerințelor pentru sistem;

Oportunitatea rezilierii proiectului.

Standardizarea ciclului de viață al software-ului se realizează în trei direcții. Prima direcție este organizată și stimulată de Organizația Internațională de Standardizare (ISO – International Standard Organization) și Comisia Electrotehnică Internațională (IEC – International Electro-technical Commission). Acest nivel standardizează cele mai comune procese tehnologice importante pentru cooperarea internațională. A doua direcție este dezvoltată în mod activ în SUA de către Institutul de Ingineri Electrici și Electronici (IEEE - Institute of Electrotechnical and Electronics Engineers) împreună cu Institutul Național American de Standarde (ANSI). Standardele ISO/IEC și ANSI/IEEE sunt în mare parte de natură consultativă. A treia direcție este stimulată de Departamentul de Apărare al SUA (Departamentul de Apărare-DOD). Standardele DOD sunt obligatorii pentru firmele care lucrează în numele Departamentului de Apărare al SUA.

Pentru proiectare software sistem complex, în special sistemele în timp real, este recomandabil să se utilizeze un model de ciclu de viață la nivelul întregului sistem, bazat pe integrarea tuturor lucrări celebreîn curs de revizuire procese de bază. Acest model este destinat utilizării în planificarea, programarea, gestionarea diverselor proiecte software.

Este recomandabil să împărțiți setul de etape ale acestui model de ciclu de viață în două părți, care diferă semnificativ în caracteristicile proceselor, caracteristicile tehnice și economice și factorii care le influențează.

În prima parte a ciclului de viață, se efectuează analiza sistemului, proiectarea, dezvoltarea, testarea și testarea software-ului. Gama lucrărilor, complexitatea lor, durata și alte caracteristici în aceste etape depind în mod semnificativ de obiectul și mediul de dezvoltare. Studiul unor astfel de dependențe pentru diferite clase de software face posibilă prezicerea compoziției și principalelor caracteristici ale programelor de lucru pentru noile versiuni de software.

A doua parte a ciclului de viață, care reflectă suport pentru operarea și întreținerea software-ului, este relativ slab legată de caracteristicile obiectului și ale mediului de dezvoltare. Gama de lucru în aceste etape este mai stabilă, iar complexitatea și durata lor pot varia semnificativ și depind de aplicarea în masă a software-ului. Pentru orice model de furnizare a ciclului de viață Calitate superioară sistemele software este posibilă numai atunci când se utilizează un proces tehnologic reglementat în fiecare dintre aceste etape. Un astfel de proces este susținut de instrumente de automatizare a dezvoltării, pe care este indicat să le alegeți dintre cele existente sau să le creați ținând cont de obiectul de dezvoltare și de lista de lucrări adecvate acestuia.

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 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 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 etapele de lansare, creștere, maturitate și declin, atunci viața software-ului seamănă mai degrabă 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;

Dezvoltarea proceselor tehnologice și a tehnicilor 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;

Determinarea structurii organizatorice a echipei 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 acestea 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 diferitelor componente software în toate etapele ciclului său de viață.

2. Verificare este procesul de determinare dacă Starea curenta Software-ul atins în 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. Analiză 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 a 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 materialelor. necesare pentru a verifica operabilitatea și conformitatea calității produselor software, materialelor 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 sistemului informatic - definindu-l

funcționalitate, cerințe ale utilizatorului, cerințe de fiabilitate și securitate, cerințe 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 conformitate cerințe de calificare, care sunt un set de criterii sau condiții care trebuie îndeplinite pentru a califica un produs software ca fiind conform cu specificațiile sale și gata de utilizare în condiții de operare date;

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ția sarcinii (TOR) (în conformitate cu etapa GOST 19.102-77 „Termeni de referință”)