Conceptul ciclului de viață al software-ului (software-ul LC) este unul dintre elementele de bază ale ingineriei software. Ciclul de viață al software-ului este definit ca o perioadă de timp care începe atunci când se ia decizia cu privire la necesitatea de a crea un software și se termină atunci când este complet retras din serviciu.
Modelul de software LMC este înțeles ca fiind structura care determină succesiunea de implementare și interconectare a proceselor, acțiunilor și sarcinilor în cadrul LC. Modelul LC depinde de specificul, amploarea și complexitatea proiectului și de specificul condițiilor în care sistemul este creat și funcționează.
Standardul ISO / IEC 12207 nu oferă un model GC specific și metode de dezvoltare software. Dispozițiile sale sunt comune oricăror modele LC, metode și tehnologii de dezvoltare software. Standardul descrie structura proceselor software-ului, dar nu specifică în detaliu modul de implementare sau executare a acțiunilor și sarcinilor incluse în aceste procese.
Modelul LC orice software special EIS determină natura procesului de creare a acestuia, care este o colecție ordonată de interconectate și temporar integrate în locuri de muncă pas, care sunt necesare și suficiente pentru a crea software-ul care corespunde cerințelor specificate.
În EIS omogene din anii '70 și '80. Software-ul aplicat a fost un singur întreg. Pentru a dezvolta acest tip de software, a fost utilizată o abordare în cascadă (un alt nume este o cascadă) (Figura 1.3). Caracteristica principală a abordării în cascadă este track-yuschee: du-te la pasul următor se efectuează numai după terminarea lucrărilor la etapa actuală, și returnează a trecut în etapa nu este prevăzută. Fiecare etapă se termină cu primirea unor rezultate, care servesc ca intrare pentru etapa următoare. Cerințele pentru software-ul în curs de dezvoltare, determinate în etapa de formare a cerințelor, sunt strict documentate sub forma unei sarcini tehnice și sunt fixate pe întreaga durată a dezvoltării proiectului. Fiecare etapă se încheie cu lansarea unui set complet de documente, suficient pentru ca dezvoltarea să fie continuată de o altă echipă de dezvoltare. Criteriul calității dezvoltării cu această abordare este corectitudinea specificării atribuției tehnice.
1.3 Schema de dezvoltare software în cascadă 1.4 Proces real
În același timp, atenția dezvoltatorilor se concentrează în principal pe obținerea valorilor optime ale caracteristicilor tehnice ale software-ului dezvoltat: performanța, cantitatea de memorie etc.
Avantajele utilizării metodei cascade sunt următoarele:
în fiecare etapă se formează un set complet de documente de proiectare, care îndeplinește criteriile de exhaustivitate și consecvență;
executate într-o succesiune logică a etapei de lucru vă permit să programați finalizarea tuturor lucrărilor și costurile aferente.
În același timp, această abordare are o serie de dezavantaje, cauzate în primul rând de faptul că procesul actual de creare de software nu a intrat niciodată complet într-o astfel de schemă rigidă. Procesul de creare a software-ului este, de regulă, iterativ: rezultatele etapei următoare cauzează adesea schimbări în soluțiile de proiectare dezvoltate în etapele anterioare. Astfel, există o necesitate constantă de a reveni la etapele anterioare și de a rafina sau revizui deciziile anterioare. Ca rezultat, procesul real de creare a software-ului are o formă diferită (Figura 1.4).
Cel prezentat în Fig. 1.4 Schema este deseori menționată ca un model separat, așa-numitul model cu control intermediar. în care corecțiile între intervale oferă o mai mare fiabilitate în comparație cu modelul cascadă, deși ele măresc întreaga perioadă de dezvoltare.
Principalul dezavantaj al abordării în cascadă este o întârziere semnificativă a rezultatelor și, ca o consecință, un risc suficient de mare de a crea un sistem care nu răspunde nevoilor în schimbare ale utilizatorilor. Practica arată că în stadiul inițial al proiectului nu este posibilă formularea pe deplin și cu exactitate a tuturor cerințelor pentru viitorul sistem. Acest lucru se explică prin două motive: 1) utilizatorii nu pot să-și expună imediat toate cerințele și nu pot să prevadă modul în care se vor schimba în timpul dezvoltării; 2) în timpul dezvoltării, pot apărea schimbări în mediul extern care vor afecta cerințele sistemului. Ca parte a unei abordări în cascadă, cerințele pentru EIS sunt fixate sub forma unor specificații tehnice pentru tot timpul va construi-TION și aprobarea rezultatelor pentru utilizatori numai în punctele, planificate după finalizarea fiecărei etape (cu posibilitatea de ajustare a rezultatelor feedback-ul utilizatorilor, în cazul în care nu afectează cerințele stabilite în termenii de referință). Astfel, utilizatorii pot face comentarii semnificative numai după finalizarea lucrărilor la sistem. În cazul unei declarații inexacte a cerințelor sau al modificărilor pe durata unei lungi perioade de creare a software-ului, utilizatorii primesc un sistem care nu le satisface nevoile. Ca rezultat, trebuie să începem un nou proiect, care să înțeleagă aceeași soartă.
Pentru a depăși aceste probleme la mijlocul anilor 80. a fost propus un model spiralat al LC (Figura 1.5).
Caracteristica principală a acestuia este următoarea: software-ul de aplicație nu este creat imediat, ca în cazul abordării în cascadă, dar în părți folosind metoda prototipării. Un prototip este o componentă software de operare care implementează funcții separate și interfețe externe ale software-ului în curs de dezvoltare. Crearea prototipurilor se realizează în mai multe iterații sau în rotații de spirală. Fiecare iteratie corespunde la crearea unui fragment sau credință aceste software-ul pe acesta clarifică scopul și caracteristicile calității proiectului, otse-teren a rezultatelor și a lucrărilor planificate pentru următoarea iterație. La fiecare iterație, a făcut depășirile meticuloase Nye de evaluare a riscului și costul proiectului pentru a determina dacă să efectueze o altă iterație, gradul macacul este înțelegerea corectă și completă a cerințelor de sistem, precum și ca fiind încetarea fezabilitatea proiectului. Modelul spiral împiedică utilizatorii și dezvoltatorii de software să trebuiască să formuleze pe deplin și exact cerințele de sistem în stadiul inițial, deoarece sunt specificate la fiecare iterație. Astfel, detaliile proiectului sunt aprofundate și specificate secvențial, și ca rezultat, este aleasă o opțiune rezonabilă, care este pusă în practică.
Modelul elicoidal nu exclude utilizarea abordării în cascadă în etapele finale ale proiectului în cazurile în care cerințele pentru sistem sunt complet determinate.
Principala problemă a ciclului spiral este determinarea momentului tranziției către etapa următoare. Pentru ao rezolva, trebuie să introduceți restricții temporare pentru fiecare dintre etapele ciclului de viață. Tranziția se realizează în conformitate cu planul, chiar dacă nu toate lucrările planificate sunt finalizate. Planul se realizează pe baza datelor statistice obținute în proiectele anterioare și a experienței personale a dezvoltatorilor.
Toate materialele din secțiunea "Informatică"
Articole similare
-
Prezentare generală a modelelor ciclului de viață al software-ului pentru dezvoltarea software-ului
-
Prezentarea pe activstudio activstudio a fost creată special pentru
Trimiteți-le prietenilor: