Ciclul de viață al sistemelor software. Ciclul de viață al software-ului Etapele ciclului de viață

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

Ciclu de viață software 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 pierderii nevoii de a rezolva problemele relevante.

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

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

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

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

Produse software cu durată de viață scurtă

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

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

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

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

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

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

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

eu. Analiza sistemului:

a) cercetare;

b) analiza de fezabilitate:

Operațional;

Economic;

Comercial.

II. Design software:

a) proiectare:

Descompunerea funcțională a sistemului, arhitectura acestuia;

Proiectare software extern;

Proiectare baze de date;

Arhitectura software;

b) programare:

Proiectare software intern;

Proiectare externă a modulelor software;

Proiectare internă a modulelor software;

Codificare;

Programe de depanare;

Aspectul programului;

c) depanare software.

III. Evaluare software (testare).

IV. Utilizare software:

a) exploatare;

b) acompaniament.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Proiectarea bazei de date, dacă este necesar;

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

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

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

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

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

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

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

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

Durează cât se programează.

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

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

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

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

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

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

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

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

Întreținere software constă în întreținere operațională, dezvoltare funcţionalitateși creșterea caracteristicilor operaționale ale produsului software, în replicarea și transferul produsului software către diverse tipuri facilitati de calcul.

Acompaniamentul joacă un rol necesar feedback din stadiul de operare.

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

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

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

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

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 ciclului de viață al produsului software considerat, cu unele modificări, poate servi drept model pentru proiecte mici.

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

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

Standardele ciclului de viață al software-ului

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

Metodologii de dezvoltare software

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

Standard GOST 34.601-90

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

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

Schița, desenele tehnice și documentația de lucru sunt construcția consecventă a soluțiilor de proiectare din ce în ce mai precise. Este posibil să excludeți etapa „Proiectare schiță” și etapele individuale de lucru în toate etapele, pentru a combina etapele „Proiectare tehnică” și „Documentație de lucru” într-un „Proiectare tehnică detaliată”, pentru a efectua diferite etape și a lucra în paralel , și să includă altele suplimentare.

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

Standardul ISO/IEC 12207/ și aplicarea acestuia

Standardul ISO/IEC 12207:1995 „Tehnologia informației - Procesele ciclului de viață al software-ului” este principalul standard document normativ reglementarea compoziției proceselor ciclului de viață al software-ului. Acesta definește o structură a ciclului de viață care conține procesele, activitățile și sarcinile care trebuie finalizate în timpul creării software-ului.

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

Procesele ciclului de viață al software-ului

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

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

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

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

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

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

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

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

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

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

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

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

Modele ciclului de viață al software-ului

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

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

• Modelul problemei;

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

• model în spirală (prezent).

Model cu probleme

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

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

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

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

Model în cascadă

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

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

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

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

Etapele proiectului conform modelului cascada:

1. Formarea cerințelor;
2. Proiecta;
3. Implementare;
4. Testare;
5. Implementare;
6. Operare și întreținere.

Orez. 1. Schema de dezvoltare în cascadă

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

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

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

Model în spirală

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

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

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

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

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

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

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

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

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

• program de producție scurt, dar atent elaborat (de la 2 la 6 luni);

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

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

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

• faza de proiectare;

• faza de implementare;

• faza de implementare.

La fiecare iterație sunt evaluate următoarele:

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

Avantajele abordării iterative:

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

Ar trebui să începem prin a definiCiclul de viață al software-ului(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 scos 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:cascadă, incrementale (model treptat cu control intermediar ) Și spiralămodele de ciclu de viață.

Model în cascadă

Model în cascadă(engleză) 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ă şi proiectare a cerinţelor. implementare, testare, integrare și suport.

Procesul de dezvoltare este implementat printr-o succesiune ordonată de pași independenți. Modelul prevede că fiecare pas următor începe după ce pasul anterior este complet finalizat. La toate etapele modelului, auxiliare și procesele organizatoriceși munca, inclusiv managementul proiectelor, evaluarea și managementul calității, verificarea și certificarea, managementul configurației, 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 parcursul întregului ciclu de viață al dezvoltării;
• la fiecare etapă se generează un set complet de documentație de proiectare care îndeplinește criteriile de completitudine și coerență;
• certitudinea și claritatea etapelor modelului și ușurința aplicării acestuia;
• etapele de lucru efectuate într-o succesiune logică fac posibilă planificarea calendarului de finalizare a tuturor lucrărilor și a resurselor corespunzătoare (monetare, materiale și umane).

Dezavantajele modelului:

• dificultatea de a formula clar cerințele și imposibilitatea de a le modifica dinamic pe parcursul întregului ciclu de viață;
• flexibilitate scăzută în managementul proiectelor;
• ulterior structura liniara procesul de dezvoltare, ca urmare, revenirea la pașii anteriori pentru a rezolva problemele emergente duce la creșterea costurilor și la perturbarea programului de lucru;
• neadecvarea produsului intermediar pentru utilizare;
• imposibilitatea modelării flexibile a sistemelor unice;
• Detectarea tardivă a problemelor de asamblare 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 siguri de calitatea produsului dezvoltat până la finalizarea întregului proces de dezvoltare. Ei nu au posibilitatea de a evalua calitatea, deoarece este imposibil să se vadă 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 acțiunile ulterioare, ceea ce face din această metodă o alegere riscantă pentru sistemele care nu au analogi, deoarece nu se pretează modelării flexibile.

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

Domeniul de aplicare al modelului Cascade

Limitarea domeniului de aplicare a 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, implementare și metode tehnice ușor de înțeles;
2. la dezvoltarea unui proiect axat pe construirea unui sistem sau produs de același tip care a fost deja dezvoltat de dezvoltatori anterior;
3. la dezvoltarea unui proiect legat de crearea și lansarea noua versiune un produs sau sistem existent;
4. la dezvoltarea unui proiect legat de transferul unui produs sau sistem existent pe o nouă platformă;
5. la executarea unor proiecte mari care implică mai multe echipe mari de dezvoltare.

Model incremental

(model pas cu pas cu control intermediar)

Model incremental(engleză) creştere- creştere, creştere) presupune dezvoltarea unui software cu o succesiune liniară de etape, dar în mai multe trepte (versiuni), adică. cu îmbunătățirea planificată a produsului pentru tot timpul până când ciclul de viață al dezvoltării software se încheie.

Dezvoltarea software-ului are loc î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 este extinsă pe întreaga perioadă de dezvoltare.

La începutul lucrărilor la proiect, toate cerințele de bază pentru sistem sunt determinate și împărțite în unele din ce în ce mai puțin importante. Sistemul este apoi dezvoltat progresiv, astfel încât dezvoltatorul să poată utiliza datele obținute în timpul dezvoltării software. Fiecare increment ar trebui să adauge anumite funcționalități sistemului. În acest caz, lansarea începe cu componentele cu cea mai mare prioritate. Odată ce părțile sistemului sunt identificate, luați prima parte și începeți să o detaliați folosind cel mai potrivit proces pentru aceasta. În același timp, este posibil să se clarifice cerințele pentru alte părți care au fost înghețate în setul actual de cerințe pentru această lucrare. 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 dezvoltă următoarea parte a sistemului. Etape cheie Acest proces implică pur și simplu implementarea unui subset al cerințelor software și rafinarea modelului pe o serie de versiuni succesive până când software-ul este implementat complet.

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

• incapacitatea clientului de a finanța simultan întregul proiect costisitor;
• dezvoltatorului îi lipsesc resursele necesare pentru a implementa un proiect complex într-un timp scurt;
• cerințe pentru implementarea și adoptarea în faze a produsului de către utilizatorii finali. Implementarea î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 pot pur și simplu „să nu digere o bucată mare, așa că trebuie tăiată și dată în bucăți”.

AvantajeŞi defecteAcest model (strategii) 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 pentru dezvoltare, poate să o abandoneze sau să ofere dezvoltarea unui produs mai avansat cu încheierea unui nou contract.

Avantaje:

• costurile suportate ca urmare a modificărilor cerințelor utilizatorilor sunt reduse, reanalizarea și documentarea sunt reduse semnificativ în comparație cu modelul în cascadă;
• Este mai ușor să obțineți feedback de la client cu privire la munca depusă - clienții își pot exprima comentariile cu privire la piesele finite și pot vedea ceea ce a fost deja făcut. Deoarece Primele părți ale sistemului sunt un prototip al sistemului ca întreg.
• clientul are capacitatea de a obține și stăpâni rapid software-ul - clienții pot realiza beneficii reale din sistem mai devreme decât ar fi posibil cu un model în cascadă.

Dezavantajele modelului:

• managerii trebuie să măsoare continuu progresul procesului. în cazul dezvoltării rapide, nu ar trebui să creați documente pentru fiecare modificare minimă a versiunii;
• structura unui sistem tinde să se deterioreze pe măsură ce noi componente sunt adăugate — schimbările constante perturbă structura sistemului. Pentru a evita acest lucru ai nevoie timp suplimentarși bani pentru refactorizare. Designul slab face ca software-ul să fie dificil și costisitor de schimbat ulterior. Iar un ciclu de viață întrerupt al software-ului duce la pierderi și mai mari.

Schema nu vă permite să luați în considerare rapid schimbările emergente și clarificări 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 înregistrate 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 clarifică cerințele proiectului, se determină calitatea acestuia și se planifică activitatea următoarei ture. O atenție deosebită se plateste la etapele initiale de dezvoltare - analiza si proiectarea, unde fezabilitatea anumitor solutii tehnice este testata si justificata prin realizarea de prototipuri.

Acest model este un proces de dezvoltare software care combină atât designul, cât și prototipul incremental pentru a combina beneficiile conceptelor de jos în sus și de sus în jos, subliniind etapele inițiale ciclul de viață: analiză și proiectare.Trăsătură distinctivă Acest model acordă o atenție deosebită riscurilor care afectează organizarea ciclului de viață.

În fazele de analiză și proiectare, prin realizarea de prototipuri se verifică fezabilitatea soluțiilor tehnice și gradul în care nevoile clienților sunt îndeplinite. 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. În acest fel, detaliile proiectului sunt aprofundate și specificate în mod consecvent și, ca urmare, este selectată o opțiune rezonabilă care satisface cerințele reale ale clientului și este adusă la implementare.

Ciclul de viață pe fiecare tură a spiralei - poate fi folosit diferite modele procesul de dezvoltare software. În cele din urmă, rezultatul 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 unui sistem. Finalizarea incompletă a lucrărilor la fiecare etapă vă permite să treceți la următoarea etapă fără a aștepta finalizarea completă a lucrărilor la cea curentă. Sarcina principală este de a arăta utilizatorilor sistemului un produs funcțional cât mai repede posibil, activând astfel procesul de clarificare și completare a cerințelor.

Avantajele modelului:

• vă permite să afișaț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 permite un design flexibil, deoarece întruchipează beneficiile modelului cascadă, permițând în același timp iterații în 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 descoperite și corectate la fiecare iterație;
• acest model permite utilizatorilor să participe activ la activități de planificare, analiză de risc, proiectare și evaluare;
• riscurile clienților sunt reduse. Clientul poate finaliza dezvoltarea unui proiect nepromițător cu pierderi financiare minime;
• Feedback-ul de la utilizatori către dezvoltatori apare cu frecvență ridicată și la începutul modelului, ceea ce asigură crearea produsului dorit de înaltă calitate.

Dezavantajele modelului:

• dacă proiectul are un risc scăzut sau are dimensiuni reduse, modelul poate fi costisitor. Evaluarea riscului după fiecare spirală este asociată cu costuri ridicate;
• Ciclul de viață al modelului are o structură complexă, astfel încât utilizarea sa de către dezvoltatori, manageri și clienți poate fi dificilă;
• spirala poate continua pe termen nelimitat, deoarece fiecare răspuns al clientului la versiunea creată poate genera un nou ciclu, care întârzie sfârșitul proiectului;
• un număr mare de cicluri intermediare poate duce la necesitatea procesării documentației suplimentare;
• utilizarea modelului se poate dovedi a fi costisitoare și chiar inaccesibilă, deoarece timp. timpul alocat planificării, redefinirii obiectivelor, efectuării analizelor de risc și prototipării poate fi excesiv;
• Poate fi dificil de definit obiectivele și reperele care indică disponibilitatea de a continua procesul de dezvoltare în următorul și

Problema principală a ciclului spirală este determinarea momentului de tranziție la etapa următoare. Pentru a rezolva această problemă, se introduc restricții de timp pentru fiecare etapă.ciclu de viață iar tranziția se desfășoară conform planului, chiar dacă nu toate lucrările planificate sunt finalizate.Planificareprodus pe baza datelor statistice obținute în proiectele anterioare și a experienței personale a dezvoltatorilor.

Domeniul de aplicare al modelului spiralat

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;
• să realizeze proiecte 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.

Adnotare.

Introducere.

1. Ciclul de viață al software-ului

Introducere.

Etapele procesului de programare Riley

Introducere.

1.1.1. Enunțarea 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 clauza 1.1

1.2. Determinarea LCPO conform lui Lehman.

Introducere.

1.2.1 Definirea sistemului.

1.2.2. Implementarea.

1.2.3. Serviciu.

Concluzie la clauza 1.2.

1.3. Fazele și lucrul LCPO conform lui Boehm

1.3.1. Model în cascadă.

1.3.2. Justificare economică model în cascadă.

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

1.3.4. Determinarea fazelor ciclului de viață.

1.3.5. Lucrarea principală a proiectului.

Literatură.

Introducere

Aplicație industrială calculatoarele și cererea în creștere pentru programe au stabilit sarcini urgente să crească semnificativ productivitatea dezvoltării software, dezvoltarea metodelor industriale de planificare și proiectare a programelor, transferul de tehnici, modele și metode organizatorice, tehnice, tehnice, economice și socio-psihologice din sferă producerea materialuluiîn domeniul aplicaţiilor informatice. Abordare integrată proceselor de dezvoltare, operare și întreținere a software-ului a prezentat o serie de probleme presante, a căror soluție va elimina „ blocajele„Î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 estimarea costurilor cu forța de muncă, a termenelor de lucru și costurile materiale, care împiedică îmbunătățirea productivității dezvoltării software și, în cele din urmă - management eficient ciclul de viață al software-ului. Deoarece un program de orice tip devine un produs (cu excepția, poate, a programelor educaționale, prototip), abordarea producției sale ar trebui să fie în multe privințe similară cu abordarea producției de produse industriale, iar problemele de proiectare a programelor devin extrem de importante. Această idee se află în centrul cărții lui B.W. „Ingineria software” a lui Boehm pe care am folosit-o pentru a scrie asta munca de curs. Î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

ZHTSPO este proces continuu, care începe din momentul în care se ia o decizie cu privire la necesitatea creării de software și se termină în momentul în care acesta este scos complet din funcțiune.

Există mai multe abordări pentru a determina fazele și activitățile ciclului de viață al software-ului (SLC), etapele procesului de programare, modelele î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, probabil, este structura ciclurilor de viață a lui Boehm, care include opt faze. Va fi prezentat mai detaliat în viitor.

Unul dintre opțiuni posibile poate servi o descriere de nivel superior conform lui Lehmann, care include trei faze principale și reprezintă o descriere a ciclului de viață în cazul cel mai general.

Și, pentru varietate, vă prezentăm etapele procesului de programare prezentate de D. Riley în cartea „Using the Modula-2 Language”. Această idee, în opinia mea, este foarte simplă și familiară, așa că să începem cu ea.

1.1 Etapele procesului de programare Riley

Procesul de programare presupune patru pași (Figura 1):

enunţarea problemei, de ex. obținerea unei înțelegeri adecvate a sarcinii pe care trebuie să o îndeplinească programul;

proiectarea unei soluții la o problemă deja enunțată (î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. procesul continuu de depanare a problemelor din program și adăugarea de noi funcții.

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ă afirmă problema analist de sistem. Utilizatorul și analistul de sistem definesc împreună declarația problemei. Acesta din urmă este apoi transmis algoritmist, care este responsabil pentru proiectarea soluției. O soluție (sau algoritm) reprezintă o succesiune de operații, a căror execuție duce la rezolvarea unei probleme. Deoarece algoritmul nu este adesea potrivit pentru execuție pe o mașină, ar trebui tradus într-un program de mașină. Această operație este efectuată de codificator. Programatorul însoțitor este responsabil pentru modificările ulterioare ale programului. Și analistul de sistem, și algoritmistul, și codificatorul și programatorul care îl însoțește - 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ă revenirea la pașii anteriori din cauza unor circumstanțe neprevăzute. Toate acestea servesc ca un argument suplimentar pentru proiectarea atentă a software-ului: rezultatele fiecărui pas ar trebui să fie complete, precise și ușor de înțeles.

1.1.1 Declarația problemei

Una dintre cele mai multe pași importanți programarea este enunțul problemei. 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 proastă a problemei 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 să utilizeze software 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 formularea soluției acesteia.

Enunțarea problemei (specificarea programului); în esență înseamnă o descriere precisă, completă și de înțeles a ceea ce se întâmplă atunci când este executat un anumit program. Utilizatorul privește de obicei computerul ca pe o cutie neagră: pentru el, nu contează cum funcționează computerul, dar important este ce poate face computerul care îl interesează pe utilizator. În acest caz, atenția principală se concentrează pe interacțiunea omului cu mașina.

Caracteristicile unei declarații bune de problemă:

Precizie, adică eliminând orice ambiguitate. 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 neintenționată și determinarea ieșirii corespunzătoare.

Claritate, adică trebuie să fie de înțeles atât pentru utilizator, cât și pentru analistul de sistem, deoarece enunțul 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, ceea ce permite formularea unor prevederi cu o precizie extremă, excluzând orice discrepanțe minore. De exemplu, unele întrebări din 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 decât atât, este posibil ca elevul să nu înțeleagă deloc sensul principal al întrebării din cauza cantitate mare detalii. Cea mai bună formulare a problemei este cea care realizează un echilibru între toate cele trei cerințe.

Forma standard de enunțare a 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 exactă, 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.

Evident, 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 sugerează utilizarea unui formular standard pentru a seta problema, care asigură acuratețe maximă, completitudine, claritate și include:

numele sarcinii (definiție schematică);

descriere generală(expunerea pe scurt a problemei);

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

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

Exemplu. Enunțarea problemei într-o formă standard.

NUME

Sortarea a trei numere întregi.

DESCRIERE

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

Se introduc trei numere întregi, câte un număr pe linie. 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 tipărite, toate trei fiind tipărite 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ă.

Ciclul de viață al software-ului. Etape și repere

Ciclul de viață al unui IS este o serie de evenimente care au loc cu un sistem în timpul procesului de creare și utilizare a acestuia.

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

Ciclul de viață este modelat în mod tradițional ca un anumit număr de etape succesive (sau etape, faze). În prezent, nu există o împărțire general acceptată a ciclului de viață al unui sistem software în etape. Uneori, o etapă este evidențiată ca un punct separat, uneori este inclusă ca parte integrantă a unei etape mai mari. Acțiunile efectuate într-unul sau altul pot varia. Nu există o uniformitate în denumirile acestor etape.

În mod tradițional, se disting următoarele etape principale ale ciclului de viață al software-ului:

Analiza cerințelor,

Proiecta,

Codare (programare),

Testare și depanare,

Operare și întreținere.

Ciclul de viață al software-ului. Model în cascadă

modelul în cascadă (70-80 de ani) ≈ implică trecerea la etapa următoare după finalizarea completă a lucrărilor la etapa anterioară,

Principala realizare a modelului în cascadă este completitudinea etapelor. Acest lucru face posibilă planificarea costurilor și a termenelor limită. În plus, se formează documentatia proiectului, completă și consecventă.

Modelul cascadă este aplicabil proiectelor software mici cu cerințe clar definite și neschimbabile. Un proces real poate dezvălui eșecuri în orice etapă, ceea ce duce la o revenire la una dintre etapele anterioare. Modelul unei astfel de producții de software este cascadă-retur

Ciclul de viață al software-ului. Model treptat cu control intermediar

model pas cu pas cu control intermediar (80-85) ≈ model iterativ de dezvoltare software cu bucle de feedback între etape. Avantajul acestui model este că ajustările între etape asigură o intensitate mai mică a muncii în comparație cu modelul în cascadă; cu toate acestea, durata de viață a fiecărei etape se extinde pe întreaga perioadă de dezvoltare,

Principalele etape ale rezolvării problemelor

Scopul programării este de a descrie procesele de prelucrare a datelor (denumite în continuare simple procese).

Datele sunt prezentarea unor fapte și idei într-o formă formalizată, potrivită pentru transmiterea și prelucrarea într-un anumit proces, iar informația este sensul care se acordă datelor atunci când sunt prezentate.

Prelucrarea datelor este efectuarea unei secvențe sistematice de acțiuni asupra datelor. Datele sunt prezentate și stocate pe medii de stocare.

Setul de purtători de date utilizate pentru orice prelucrare a datelor se numește mediul informațional (mediul de date).

Un set de date continute in orice moment in mediul informatic - stare mediul informațional.

Un proces poate fi definit ca o secvență de stări succesive ale unui mediu informațional.

A descrie un proces înseamnă a determina succesiunea stărilor mediului informațional. Pentru ca procesul cerut să fie generat automat pe orice computer conform unei descrieri date, este necesar ca această descriere să fie oficializată.

Criterii de calitate software

Un produs comercial (produs, serviciu) trebuie să îndeplinească cerințele consumatorilor.

Calitatea este o caracteristică obiectivă a unui produs (produs, serviciu), care arată gradul de satisfacție a consumatorului

Caracteristici de calitate:

› Performanţă– sistemul funcționează și implementează funcțiile necesare.

› Fiabilitate– sistemul funcționează fără defecțiuni sau defecțiuni.

› Recuperare.

› Eficienţă– sistemul își implementează funcțiile în cel mai bun mod posibil.

› Eficienta economica – costul minim al produsului final cu profit maxim.

Caracteristici de calitate:

› Ținând cont de factorul uman- ușurință de utilizare, viteza de învățare a lucrului cu software, ușurință de întreținere, efectuarea de modificări.

› Portabilitate(mobilitate) – portabilitatea codului către o altă platformă sau sistem.

› Completitudine funcțională– poate cea mai completă implementare a funcțiilor externe.

› Precizia calculelor

Proprietățile algoritmului.

Eficienţă înseamnă posibilitatea de a obţine un rezultat după efectuarea unui număr finit de operaţii.

Certitudine consta in coincidenta rezultatelor obtinute, indiferent de utilizator si de mijloacele tehnice folosite.

Caracter de masă constă în posibilitatea aplicării algoritmului la o întreagă clasă de probleme similare care diferă în valorile specifice ale datelor inițiale.

Discretenie - posibilitatea de a împărți procesul de calcule prescrise de algoritm în etape separate, posibilitatea de a selecta secțiuni ale programului cu o anumită structură.

Modalități de a descrie algoritmi

Există următoarele moduri de a descrie algoritmii (prezenti):

1. descriere verbală;

2. descrierea algoritmului folosind formule matematice;

3. descrierea grafică a algoritmului sub formă de diagramă bloc;

4. descrierea algoritmului folosind pseudocod;

5. metoda combinata imagini ale algoritmului folosind metode verbale, grafice și alte metode .

6. folosind reţele Petri.

Descriere verbală algoritmul este o descriere a structurii algoritmului în limbaj natural. De exemplu, la dispozitive aparate electrocasnice, de regulă, se atașează un manual de instrucțiuni, adică. o descriere verbală a algoritmului conform căruia acest dispozitiv ar trebui utilizat.

Descriere graficăalgoritm sub forma unei diagrame bloc este o descriere a structurii algoritmului folosind forme geometrice cu linii de comunicare.

O diagramă de flux de algoritm este o reprezentare grafică a unei metode de rezolvare a unei probleme care utilizează simboluri speciale pentru a reprezenta operații.

Simbolurile care compun diagrama bloc al algoritmului sunt determinate de GOST 19.701-90. Acest GOST respectă standard international proiectarea algoritmilor, prin urmare diagrame bloc ale algoritmilor, proiectate în conformitate cu GOST 19.701-90, în diferite țări sunt clar înțelese.

Pseudocod– descrierea structurii algoritmului într-un limbaj natural, dar parțial formalizat. Pseudocodul utilizează unele constructe formale și simboluri matematice comune. Nu există reguli de sintaxă stricte pentru scrierea pseudocodului.

Să luăm în considerare cel mai simplu exemplu. Să presupunem că este necesar să descriem algoritmul de afișare pe un ecran de monitor cea mai mare valoare din două numere.

Figura 1 - Un exemplu de descriere a algoritmului sub forma unei diagrame bloc

Descrierea aceluiași algoritm în pseudocod:

2. Introduceți numere: Z, X

3. Dacă Z > X atunci ieșire Z

4. În caz contrar, ieșirea X

Fiecare dintre metodele enumerate de reprezentare a algoritmilor are avantaje și dezavantaje. De exemplu, metoda verbală este verbosă și lipsită de claritate, dar face posibilă o mai bună descriere a operațiilor individuale. Metoda grafică este mai vizuală, dar adesea este nevoie de a descrie unele operații în formă verbală. Prin urmare, atunci când dezvoltați algoritmi complecși, este mai bine să utilizați o metodă combinată.

Tipuri de algoritmi

liniar;

ramificare;

ciclic.

· Algoritm liniar- un set de comenzi (instructiuni) executate secvential una dupa alta.

· Algoritm de ramificare- un algoritm care conține cel puțin o condiție, ca urmare a verificării căreia computerul asigură o tranziție la unul dintre cei doi pași posibili.

· Algoritmul round robin- un algoritm care presupune repetarea repetată a aceleiași acțiuni (aceleași operații) pe date inițiale noi. Majoritatea metodelor de calcul și enumerare a opțiunilor sunt reduse la algoritmi ciclici. Ciclul programului - o secvență de comenzi (serie, corp buclă) care poate fi executată în mod repetat (pentru date sursă noi) până când este îndeplinită o anumită condiție.

C. Tipuri de date.

Un tip de date este o descriere a intervalului de valori pe care le poate lua o variabilă de un tip specificat. Fiecare tip de date este caracterizat prin:
   1. numărul de octeți ocupați (dimensiune)
   2. intervalul de valori pe care o poate lua o variabilă de acest tip.

Toate tipurile de date pot fi împărțite în următoarele tipuri:
   1. tipuri simple (scalare) și complexe (vectorale);
   2. de bază (sistem) și utilizator (definit de utilizator).
  În limbajul SI, sistemul de tipuri de bază este format din patru tipuri de date:
   1. simbolic,
   2. întreg,
   3. o singură precizie reală,
   4. dublă precizie reală.

Structura unui program C.

1. Operatori de limbaj C++

Operatorii controlează procesul de execuție a programului. Setul de operatori de limbaj C++ conține toate constructele de control ale programării structurate.
O declarație compusă este delimitată de acolade. Toate celelalte afirmații se termină cu punct și virgulă.
Operator gol – ;
O instrucțiune goală este o instrucțiune care constă numai dintr-un punct și virgulă. Poate apărea oriunde într-un program unde sintaxa necesită o instrucțiune. Executarea unei instrucțiuni goale nu schimbă starea programului.
Operator compus – (...)
Efectul unei instrucțiuni compuse este de a executa secvențial instrucțiunile pe care le conține, cu excepția cazului în care o instrucțiune transferă în mod explicit controlul într-un alt loc din program.
Declarație de gestionare a excepțiilor

incearca (<операторы> }
prinde (<объявление исключения>) { <операторы> }
prinde (<объявление исключения>) { <операторы> }
...
prinde (<объявление исключения>) { <операторы> }

Operator condiționat

daca (<выражение>) <оператор 1>

Comutator de operator

comutator (<выражение>)
(caz<константное выражение 1>: <операторы 1>
caz<константное выражение 2>: <операторы 2>
...
caz<константное выражение N>: <операторы N>
}
Instrucțiunea switch este folosită pentru a selecta una dintre mai multe căi alternative pentru execuția programului. Evaluarea unei instrucțiuni switch începe cu evaluarea unei expresii, după care controlul este transferat instrucțiunii marcate cu o expresie constantă egală cu valoarea evaluată a expresiei. Ieșirea din instrucțiunea switch este efectuată de instrucțiunea break. Dacă valoarea expresiei nu este egală cu nicio expresie constantă, atunci controlul este transferat instrucțiunii marcate cu cuvântul cheie implicit, dacă există.
Operator de buclă cu precondiție

în timp ce (<выражение>) <оператор>

Operator de buclă cu postcondiție

do<оператор>în timp ce<выражение>;
În limbajul C++, acest operator diferă de implementarea clasică a unei bucle cu o postcondiție prin faptul că, dacă expresia este adevărată, bucla continuă, mai degrabă decât iese din buclă.
Operator de buclă în pas

pentru ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Corpul instrucțiunii for este executat până când expresia condiționată devine falsă (egal cu 0). Expresiile inițiale și de increment sunt de obicei folosite pentru a inițializa și modifica parametrii buclei și alte valori. Expresia inițială este evaluată o dată înainte ca expresia condiționată să fie testată pentru prima dată, iar expresia incrementală este evaluată după fiecare execuție a instrucțiunii. Oricare dintre cele trei expresii de antet de buclă, și chiar toate trei, pot fi omise (doar nu uitați să omiteți punctele și virgulă). Dacă expresia condiționată este omisă, este considerată adevărată și bucla devine infinită.
Operatorul de buclă pas cu pas în limbajul C++ este o construcție flexibilă și convenabilă, prin urmare operatorul de buclă cu o precondiție while este folosit extrem de rar în limbajul C++, deoarece în cele mai multe cazuri este mai convenabil să utilizați pentru operator.
Operator de pauză

pauză;
Operatorul break întrerupe execuția instrucțiunilor while, do, for și switch. Acesta poate fi inclus doar în corpul acestor declarații. Controlul este transferat operatorului de program în urma celui întrerupt. Dacă o instrucțiune break este scrisă în interiorul instrucțiunilor imbricate while, do, for, switch, atunci se încheie numai instrucțiunea care o include imediat.
operator de continuare

continua;
Operatorul de continuare transferă controlul către următoarea iterație în operatorii while, do, pentru buclă. Acesta poate fi inclus doar în corpul acestor declarații. În instrucțiunile do și while, următoarea iterație începe cu evaluarea expresiei condiționate. Într-o instrucțiune for, următoarea iterație începe prin evaluarea expresiei de increment și apoi evaluează expresia condiționată.
Operator de retur

intoarce [<выражение>];
Instrucțiunea return încheie execuția funcției care o conține și returnează controlul funcției apelante. Controlul este transferat la punctul în care funcția de apelare

Dacă (expresie booleană)

operator;

Dacă (expresie booleană)

operator_1;

operator_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

Dacă valoarea expresiei logice este adevărată, atunci expresia_1 este evaluată, în caz contrar expresia_2 este evaluată.

comutare (expresie întreagă)

valoarea cazului_1:

secvență_de_instrucțiuni_1;

valoarea cazului_2:

secvență_de_instrucțiuni_2;

case value_n:

statement_sequence_n;

implicit:

secvența_operator_n+1;

Ramura implicit nu poate fi descris. Se execută dacă nici una dintre expresiile superioare nu este satisfăcută.

Operator de buclă.

Turbo C are următoarele structuri care vă permit să programați cicluri: în timp ce, fă în timp ce Şi pentru . Structura lor poate fi descrisă după cum urmează:

Bucle care verifică starea în partea de sus:

Operator de selecție

Dacă acțiunile pe care doriți să le efectuați într-un program depind de valoarea unei variabile, puteți utiliza operatorul select. Cu toate acestea, în C++ doar variabilele numerice pot fi folosite ca variabile în operatorul de selecție. ÎN vedere generală intrarea declarației de selecție arată astfel:

comutator (variabil)
{
valoare caz 1:
acțiuni 1
pauză;

valoarea cazului 2:
acțiuni 2
pauză;
...

implicit:
acțiuni implicite
}

Cuvânt cheie pauză trebuie adăugată la capătul fiecărei ramuri. Oprește rularea operațiunii de selecție. Dacă nu îl scrieți, după executarea acțiunilor dintr-o ramură de selecție, executarea acțiunilor din următoarele ramuri va continua. Cu toate acestea, uneori această proprietate de selecție este utilă, de exemplu, dacă trebuie să efectuați aceleași acțiuni pentru sensuri diferite variabilă.

comutator (variabil)
{
valoare caz 1:
valoarea cazului 2:
acțiuni 1
pauză;

valoarea cazului 3:
acțiuni 2
pauză;
...
}

Exemplu de utilizare a select:

int n, x;
...
comutator(n)
{
cazul 0:
pauză; //dacă n este 0, atunci nu efectuăm nicio acțiune

cazul 1:
cazul 2:
cazul 3:
x = 3 * n; //dacă n este 1, 2 sau 3, atunci efectuați unele acțiuni
pauză;

cazul 4:
x = n; //dacă n este 4, atunci efectuați alte acțiuni
pauză;

implicit:
x = 0; //pentru toate celelalte valori ale lui n, efectuați acțiunile implicite
}

C.Cic: bucla cu parametru

Forma generalăînregistrări

pentru (inițializarea parametrilor; verificarea stării finale; corectarea parametrilor) (

bloc de operațiuni;

for - bucla parametrică (bucla cu un număr fix de repetări). Pentru a organiza un astfel de ciclu, trebuie efectuate trei operații:

§ inițializarea parametrilor- atribuirea unei valori inițiale parametrului ciclului;

§ verificarea stării finale- compararea valorii parametrului cu o anumită valoare limită;

§ corectarea parametrilor- modificarea valorii parametrului de fiecare dată când corpul buclei este trecut.

Aceste trei operații sunt scrise între paranteze și separate prin punct și virgulă (;). De obicei, parametrul buclei este o variabilă întreagă.
Inițializarea parametrului are loc o singură dată - când începe să se execute bucla for. Condiția de terminare este verificată înainte de fiecare execuție posibilă a corpului buclei. Când o expresie devine falsă ( egal cu zero), ciclul se termină. Parametrul este ajustat la sfârșitul fiecărei execuții a corpului buclei. Parametrul poate crește sau descrește.

Exemplu

#include
int main() (

pentru(num = 1; num< 5; num++)

printf("num = %d\n",num);

Si. Buclă cu precondiție

Formular general de înregistrare

în timp ce(expresie) (

bloc de operațiuni;
}

Dacă expresia este adevărată (nu este egală cu zero), atunci blocul de operații cuprins între acolade este executat, atunci expresia este verificată din nou. Secvența de acțiuni constând în verificarea și executarea unui bloc de operații se repetă până când expresia devine falsă (egale cu zero). În acest caz, bucla este ieșită și operația care urmează operatorului buclă este executată.

Exemplu

int k=5;
int i=1;
int suma=0;
în timp ce (i<=k) {

Când se construiește o buclă while, este necesar să se includă constructe care modifică valoarea expresiei testate, astfel încât în ​​cele din urmă să devină falsă (egal cu zero). În caz contrar, bucla va rula la nesfârșit (buclă infinită), de exemplu

bloc de operațiuni;
}

while este o buclă cu o precondiție, deci este foarte posibil ca corpul buclei să nu fie executat nici măcar o dată dacă la momentul primei verificări condiția verificată se dovedește a fi falsă.

Si. Bucla cu postcondiție

Buclă cu do...while postcondition

Formular general de înregistrare

bloc de operațiuni;

) while(expresie);

Bucla cu postcondiție

O buclă do...while este o buclă cu o postcondiție, în care adevărul expresiei este verificat după efectuarea tuturor operațiilor incluse în blocul delimitat de acolade Corpul buclei este executat până când expresia devine falsă este, corpul buclei cu o postcondiție este executat deși o singură dată.

Este mai bine să folosiți o buclă do...while în cazurile în care trebuie finalizată cel puțin o iterație sau când inițializarea obiectelor implicate în verificarea stării are loc în interiorul corpului buclei.

Exemplu. Introduceți un număr de la 0 la 10

#include
#include
int main() (

system("chcp 1251");

printf("Introduceți un număr de la 0 la 10: ");

scanf("%d", &num);

) în timp ce((num< 0) || (num > 10));

printf("Ai introdus numarul %d", num);

getchar(); getchar();

Definirea Funcțiilor

Să ne uităm la definiția unei funcții folosind funcția sumă ca exemplu.

În C și C++, funcțiile nu trebuie definite până când nu sunt utilizate, dar trebuie declarate în prealabil. Dar chiar și după toate acestea, în cele din urmă această funcție trebuie definită. Prototipul funcției și definiția acestuia sunt apoi asociate și funcția poate fi utilizată.

Dacă o funcție a fost declarată anterior, aceasta trebuie definită cu aceeași valoare returnată și tipuri de date, altfel va fi creată o funcție nouă, supraîncărcată. Rețineți că numele parametrilor funcției nu trebuie să fie identice.