Metodologia de proiectare a sistemelor informaționale descrie procesul de creare și întreținere a sistemelor în formă ciclu de viață(LC) IS, prezentându-l ca o anumită succesiune de etape și procese efectuate asupra acestora. Pentru fiecare etapă se determină componența și succesiunea lucrărilor efectuate, rezultatele obținute, metodele și mijloacele necesare pentru finalizarea lucrării, rolurile și responsabilitățile participanților etc. O astfel de descriere formală a ciclului de viață al unui sistem informațional face posibilă planificarea și organizarea procesului de dezvoltare colectivă și asigurarea managementului acestui proces.

Ciclu de viață IS poate fi reprezentat ca o serie de evenimente care au loc cu un sistem în timpul procesului de creare și utilizare a acestuia.

Modelul ciclului de viață reflectă diferitele stări ale sistemului, începând din momentul în care apare nevoia unui anumit IS și terminând cu momentul învechirii sale complete. Modelul ciclului de viață- o structură care conține procese, acțiuni și sarcini care sunt efectuate în timpul dezvoltării, exploatării și întreținerii produs software pe toată durata de viață a sistemului, de la definirea cerințelor până la finalizarea utilizării acestuia.

Următoarele sunt cunoscute și utilizate în prezent modele de ciclu de viață:

• Model în cascadă(Fig. 2.1) prevede implementarea succesivă a tuturor etapelor proiectului într-o ordine strict fixă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrărilor în etapa anterioară.
• (Fig. 2.2). Dezvoltarea IS se realizează în iterații cu bucle de feedback între etape. Ajustările între etape fac posibilă luarea în considerare a influenței reciproce reale a rezultatelor dezvoltării în diferite etape; Durata de viață a fiecărei etape se extinde pe întreaga perioadă de dezvoltare.
• Model în spirală(Fig. 2.3). La fiecare tură a spiralei, se creează următoarea versiune a produsului, se precizează cerințele proiectului, se determină calitatea acestuia și se planifică o atenție deosebită etapele inițiale dezvoltare - analiză și proiectare, unde se verifică și se justifică fezabilitatea anumitor soluții tehnice prin realizarea de prototipuri (prototipare).

Orez. 2.1.

Orez. 2.2.

Orez. 2.3.

În practică, cele mai utilizate sunt două principale: modele de ciclu de viață:

• model în cascadă(tipic pentru perioada 1970-1985);
• model în spirală(tipic pentru perioada de după 1986).

În proiectele timpurii de IS destul de simplu, fiecare aplicație era un singur bloc, independent din punct de vedere funcțional și informațional. Metoda în cascadă s-a dovedit a fi eficientă pentru dezvoltarea acestui tip de aplicație. Fiecare etapă a fost finalizată după finalizarea completă și documentarea tuturor lucrărilor necesare.

Se pot distinge următoarele aspecte pozitive aplicarea abordării în cascadă:

• la fiecare etapă se formează un set complet documentatia proiectului, îndeplinind criteriile de completitudine și coerență;
• etapele de lucru efectuate într-o succesiune logică fac posibilă planificarea timpului de finalizare a tuturor lucrărilor și a costurilor corespunzătoare.

Abordarea în cascadă s-a dovedit bine în construcția de circuite integrate relativ simple, când chiar la începutul dezvoltării este posibil să se formuleze destul de precis și complet toate cerințele pentru sistem. Principalul dezavantaj al acestei abordări este că procesul real de creare a unui sistem nu se încadrează niciodată complet într-o schemă atât de rigidă, există în mod constant nevoia de a reveni la etapele anterioare și de a clarifica sau revizui mai devreme; deciziile luate. Ca rezultat, procesul real de creare a IP se dovedește a fi corespunzător model pas cu pas cu control intermediar.

Cu toate acestea, această schemă nu ne permite să luăm în considerare rapid schimbările emergente și clarificarea cerințelor de sistem. Coordonarea rezultatelor dezvoltării cu utilizatorii se realizează numai în punctele planificate după finalizarea fiecărei etape de lucru și cerințe generale la IS sunt fixate în formă termeni de referință pentru tot timpul creării sale. Astfel, utilizatorii ajung adesea cu un sistem care nu le satisface nevoile reale.

Model în spirală Ciclul de viață a fost propus pentru a depăși aceste probleme. Î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 să satisfacă cerinţele clientuluiși este adusă la bun sfârșit.

Dezvoltarea iterativă reflectă un ciclu de creație în spirală existent în mod obiectiv sisteme complexe. Vă permite să treceți la următoarea etapă fără a aștepta finalizarea completă a lucrărilor pe cea curentă și a rezolva sarcina principală - să le arătați utilizatorilor sistemului un produs funcțional cât mai repede posibil, activând astfel procesul de clarificare și completare a cerințelor .

Principala problemă 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 decurge conform planificării, chiar dacă nu toate lucrările planificate sunt finalizate. Planificarea se face pe baza datelor statistice obținute în proiectele anterioare și experiență personală dezvoltatori.

Industria software-ului se dezvoltă într-un ritm rapid, dar nu este un secret că procesul de dezvoltare este încă foarte departe de a fi perfect și este caracterizat de multe probleme interne. Conform cercetărilor realizate de Standish Group (www.standishgroup.com), mai puțin de o treime proiecte software se dovedesc a fi de succes, restul fie nu se încadrează în intervalele financiare și de timp, fie se termină cu un eșec total.

Un erou care lucrează singur -
programatorul este un anacronism.
Edward Yordon

Studiul menționat mai sus afirmă că proiectele mici au cel mai mare succes, iar cu cât proiectul este mai mare, cu atât este mai mare riscul de eșec. Acest lucru indică faptul că, pe măsură ce dimensiunea sarcinii crește, managerii nu pot gestiona resursele alocate.

De fapt, problema creșterii complexității managementului în funcție de creșterea dimensiunii organizației este departe de a fi nouă, totuși, în programare ia forme noi: dacă nu există suficiente resurse pentru a implementa proiectul la timp, atunci pur și simplu le crește. nu va face decât să agraveze problema și termenul limită va fi amânat și mai mult (vorbim în primul rând de resurse umane, întrucât restul sunt mult mai puțin semnificative în programare).

Acest lucru a fost discutat serios pentru prima dată după publicarea cărții lui Frederick Brooks, The Mythical Man-Moon, în 1975, care mai târziu a devenit un clasic. Este caracteristic că a fost republicat de mulți ani, iar principalele sale prevederi rămân valabile. În mai mult munca târzie Brooks a identificat două componente ale complexității dezvoltării software: dificultăți inerente specificului creării de software și cele accidentale - în acest context, cele care sunt asociate cu limitări în nivelul de dezvoltare a științei și tehnologiei. Acestea din urmă sunt depășite mai mult sau mai puțin cu succes pe calea progresului științific și tehnologic, dar primele vor însoți întotdeauna dezvoltarea software-ului.

Managementul eficient al oricărui proces este posibil cu condiția ca subiectul de control să perceapă în mod adecvat starea și comportamentul obiectului de control. În ceea ce privește crearea de software, aceasta este o sarcină foarte dificilă, deoarece procesul de dezvoltare este o activitate pur intelectuală, în mare măsură creativă, pentru care pipeline sau alte metode similare nu sunt aplicabile. Prin urmare, s-au făcut încercări active de a prezenta un model al procesului de creare a software-ului care să țină cont de caracteristicile sale inerente la maximum și să-l facă gestionabil.

Modele bazate pe o abordare inginerească

Codare-Model de eliminare a erorilor. Este descris astfel: 1) stabiliți o sarcină; 2) să o efectueze până la finalizarea cu succes sau anulare; 3) verifica rezultatul; 4) repetați dacă este necesar de la pasul 1.

Desigur, un astfel de model nu a structurat în niciun fel procesul de dezvoltare și este inutil să vorbim despre posibilitatea utilizării eficiente a acestuia, mai ales în proiectele mari.

Model în cascadă. Primul model care a devenit cunoscut pe scară largă și a structurat cu adevărat procesul de dezvoltare este modelul în cascadă sau cascadă. A fost creat după Conferința NATO pentru Știință și Tehnologie din 1968, unde au fost discutate probleme similare, și împarte procesul de creare a unui produs software în etape succesive (de remarcat că era deja folosit de diverși dezvoltatori la acea vreme, dar nici numărul şi nici conţinutul etapelor neunificate).

La scurt timp după naștere, modelul în cascadă a fost modificat de Winst Royce, ținând cont de interdependența etapelor și de necesitatea revenirii la etapele anterioare, care poate fi cauzată, de exemplu, de cerințe incomplete sau erori în formarea sarcina. Modelul în cascadă a existat în această formă „reversibilă”. pentru o lungă perioadă de timpși a stat la baza multor proiecte (Fig. 1).

Cu toate acestea, utilizarea practică a acestui model a dezvăluit multe dintre deficiențele sale, principala dintre acestea fiind că este mai potrivit pentru tipurile tradiționale de activități de inginerie decât pentru dezvoltarea de software. În special, una dintre cele mai mari probleme s-a dovedit a fi „predispoziția” sa la posibile inconsecvențe între produsul rezultat și cerințele care i-au fost impuse. Motivul principal pentru aceasta este că produsul complet format apare doar etapele ulterioare dezvoltare, dar deoarece munca în diferite etape a fost de obicei efectuată de diferiți specialiști și proiectul a fost transferat de la un grup la altul, atunci, conform principiului unui telefon stricat, s-a dovedit că rezultatul nu a fost exact ceea ce se aștepta la început.

Model în formă de V. A fost propus tocmai pentru a elimina neajunsurile modelului în cascadă, iar denumirea - în formă de V sau articulată - a apărut datorită reprezentării sale grafice specifice (Fig. 2).

Modelul în formă de V a făcut posibilă îmbunătățirea semnificativă a calității software-ului datorită concentrării sale asupra testării și, de asemenea, a rezolvat în mare măsură problema conformității produsului creat cu cerințele propuse, datorită procedurilor de verificare și certificare din primele etape ale dezvoltare (liniile punctate din figură indică dependența etapelor de planificare/stabilire a problemei și testare/acceptare).

Cu toate acestea, în general, modelul în formă de V este doar o modificare a modelului în cascadă și are multe dintre dezavantajele sale. În special, ambele sunt slab adaptate posibile modificări cerinţele clientului. Dacă procesul de dezvoltare durează mult (uneori până la câțiva ani), atunci produsul rezultat poate fi de fapt inutil pentru client, deoarece nevoile acestuia s-au schimbat semnificativ.

La fel de relevantă este și problema influenței progresului științific și tehnologic: cerințele pentru software sunt prezentate ținând cont de stadiul actual al realizărilor științifice și practice în domeniul hardware-ului. software, cu toate acestea, sectorul IT se dezvoltă foarte repede, iar un proces de dezvoltare prelungit poate duce la crearea unui produs care se bazează pe tehnologii învechite și se dovedește a fi necompetitiv chiar înainte de apariția sa.

Problema indicatorilor de planificare a funcționalității așteptate este de asemenea importantă, deoarece în aceste modele nu este altceva decât o presupunere: în special, este aproape imposibil să se determine ce viteză de procesare a datelor va oferi produsul creat sau câtă memorie va ocupa la stadiul stabilirii problemei. Dacă astfel de cerințe sunt clar menționate în termenii contractului dintre client și antreprenor, atunci este probabil ca soluția rezultată să nu le satisfacă, deși acest lucru va deveni cunoscut abia în etapele finale de dezvoltare, atunci când principalele resurse au a fost deja cheltuită.

Ca urmare, clientul va fi obligat fie să suporte limitările soluției create pe baza modelelor luate în considerare, fie să investească fonduri suplimentare pentru a obține cu adevărat ceea ce este necesar.

Modele care țin cont de specificul dezvoltării software

Întrucât primele modele au fost împrumutate din domeniul ingineriei tradiționale, ele nu au luat în considerare pe deplin specificul producției de software. Cu toate acestea, modelele ulterioare au fost mult mai concentrate pe caracteristicile acestui tip de activitate, care are multe diferențe fundamentale față de construcția obiectelor lumii materiale.

Model bazat pe prototipare. Datorită faptului că clientul nu este adesea un specialist în software, de obicei nu percepe bine specificațiile produsului „goale”. Pentru a depăși bariera informațională dintre client și dezvoltator și pentru a reduce riscul de a obține un produs care nu îndeplinește cerințele, a început să fie utilizată o abordare care vizează realizarea de prototipuri, care sunt modele funcționale integral sau parțial ale sistemului finit. . Vă permite să îmbunătățiți în mod semnificativ înțelegerea reciprocă între toți participanții la proces datorită dezvoltării consecvente și evolutive a sistemului, bazată pe rafinarea iterativă a prototipurilor.

Utilizarea acestora din urmă este similară cu utilizarea modelelor reduse de clădiri în arhitectură - fac posibilă vizualizarea rezultatul final, construcția și modificarea lor necesită mult mai puțină muncă în comparație cu construcția și modificarea clădirii în sine.

Cu toate acestea, în ciuda tuturor avantajelor, acest model nici nu a devenit un panaceu. Principalele sale probleme constau în planul relației „client-executor”: primul era interesat să creeze prototipuri cât mai detaliate pentru a reduce riscul de a primi un sistem inadecvat, în timp ce pentru al doilea, fiecare prototip nou însemna costuri suplimentare. de timp și resurse și, ca rezultat - o scădere a profitabilității proiectului.

Model incremental. Software-ul, spre deosebire, de exemplu, de un microcircuit, poate fi pus în funcțiune pe părți, ceea ce înseamnă că poate fi dezvoltat și livrat clientului treptat. Tocmai pe asta se bazează modelul incremental, care presupune fragmentarea produsului în componente relativ independente, care sunt dezvoltate și puse în funcțiune separat.

Acest model este benefic atât pentru client, cât și pentru creatorul sistemului, deoarece vă permite să mergeți mai departe, respectând interesele ambelor părți. Cu toate acestea, are dezavantajele sale. Împărțirea în blocuri funcționale încetinește în general procesul, deoarece devine necesar să se asigure interacțiunea acestora. Pentru multe soluții, această metodă nu este aplicabilă, deoarece este imposibil să izolați componentele individuale de la acestea, care pot fi furnizate și funcționale independent. Încărcarea personalului de conducere crește, de asemenea, în mod semnificativ din cauza complicației sarcinilor de coordonare a lucrărilor asupra componentelor individuale ale sistemului, iar costul efectuării de modificări la componentele gata făcute care sunt deja instalate și care lucrează cu clientul crește.

Model în spirală. Propus de Barry Boehm în 1988, a fost o descoperire semnificativă în înțelegerea naturii dezvoltării software, deși, în mare, este o combinație a două modele: cascadă și prototipare (Fig. 3).

Model în spirală Boema este axat pe design. Dezvoltarea software în sine are loc doar la ultima cotitură a spiralei conform modelului obișnuit în cascadă, dar aceasta este precedată de mai multe iterații de proiectare bazate pe crearea de prototipuri - fiecare iterație include etapa de identificare și analiză a riscurilor și a celor mai complexe sarcini.

Deoarece modelul în spirală acoperă în principal designul, în forma sa originală nu a fost utilizat pe scară largă ca metodă de gestionare a întregului ciclu de viață al creării de software. Cu toate acestea, ideea sa principală, care este că procesul de lucru la un proiect poate consta din cicluri care trec prin aceleași etape, a servit drept punct de plecare pentru cercetări ulterioare și a devenit baza pentru majoritatea. modele moderne procesul de dezvoltare software.

Modele moderne

Până la mijlocul anilor 1990, industria software-ului se maturizase, proiectele complexe erau implementate cu succes folosind metodologia din ce în ce mai populară orientată pe obiecte, iar echipele de dezvoltare adoptau abordări care valorificau cele mai semnificative avantaje ale modelelor anterioare.

Model orientat pe obiecte. Această metodologie presupune construirea unei soluții software din obiecte gata făcute, pentru care sunt determinate regulile de interacțiune a acestora, transferând obiecte dintr-o stare în alta. Acest model, care prevede conformitatea deplină a procesului de dezvoltare cu prevederile metodologiei orientate pe obiect (analiza orientată pe obiecte, proiectare, programare), este eficient în proiecte mari, precum și acolo unde așa-numitele instrumente de dezvoltare rapidă (RAD, Rapid Application Development) sunt utilizate, bazate pe aceste tehnologii și care conțin biblioteci gata făcute cursuri.

Cu toate acestea, sistemele RAD în sine nu încurajează crearea de soluții orientate pe obiecte. Programatorii, răsfățați de instrumente care le permit să creeze produse în câteva ore din componente gata făcute, care anterior necesitau zile și luni de muncă, consideră că nu este necesar să se deranjeze. studiu detaliat metodologia și UML, cu atât mai puțin se străduiesc să-și oficializeze soluțiile sub formă de clase reutilizabile.

Astfel, modelul orientat pe obiecte este utilizat în primul rând în proiecte foarte mari, în care se acordă atenția cuvenită etapelor de analiză și proiectare și unde dezvoltatorii sunt strict controlați pentru respectarea regulilor stabilite.

Model iterativ. Propus pentru prima dată de Philippe Kratchen în 1995, acest model combină principalele avantaje ale metodelor spiralate, incrementale, în cascadă, de prototipare și de dezvoltare orientată pe obiecte (Figura 4). A câștigat o mare popularitate și este folosit într-o formă sau alta în multe proiecte moderne.

Conform modelului iterativ, există patru faze principale ale ciclului de viață al dezvoltării software (inițiere, explorare, construcție și implementare). În fiecare fază, proiectul trece prin mai multe iterații, ducând la crearea unor versiuni funcționale: în etapele inițiale se creează prototipuri, se clarifică cerințele și se rezolvă cele mai complexe probleme; cele finale duc la crearea unui produs, imbunatatirea acestuia si extinderea functionalitatii.

Modelul iterativ, pe lângă fazele principale, mai distinge două grupuri de procese: de lucru (managementul cerințelor, analiză și proiectare, implementare, testare, implementare) și auxiliare (configurare și management al schimbării, proiect și proces). Numărul și esența proceselor variază în funcție de nevoile dezvoltatorului, ele pot avea și cicluri proprii, care nici măcar nu corespund neapărat fazelor principale. Cu toate acestea, fluxurile de lucru duc întotdeauna la crearea de versiuni de produs.

Un model iterativ, ca unul în spirală, face posibilă gestionarea cu succes a riscurilor. Dacă, în timpul lucrului la următoarea versiune, se determină că costurile cu forța de muncă pentru implementarea funcționalității necesare sunt prea mari, atunci depășirile bugetului și termenele nerespectate pot fi evitate prin corelarea priorităților de dezvoltare și a costurilor cu forța de muncă la începutul fiecărei iterații. Astfel, acest model este foarte potrivit pentru majoritatea tipurilor de proiecte software, dar avantajele sale sunt remarcabile mai ales atunci când se lucrează la produse destinate să intre pe piața liberă, datorită concentrării inițiale pe lansarea versiunilor secvențiale.

Philip Kratchen lucrează de mult timp la Rational Software, care este acum deținută de IBM. Tocmai din acest motiv, modelul iterativ a devenit baza RUP (Rational Unified Process) - una dintre cele mai comune metode de management integrat al procesului de dezvoltare software. Pe baza acestuia, a fost dezvoltat principalul concurent al RUP de la Microsoft, MSF (Microsoft Solutions Framework), precum și o abordare similară de la Borland - ALM (Application Lifecycle Management).

Modele de dezvoltare rapidă. Multe limitări ale metodologiilor moderne de dezvoltare de software au dus la faptul că companiile de dezvoltare au devenit în multe privințe similare cu sistemele birocratice gigantice. Disponibilitate cantitate mare Procedurile și regulile formale îngustează în mod semnificativ libertatea de acțiune a fiecărui programator în parte, transformându-l într-un roți de roată într-o mașină uriașă și stângace. În ciuda faptului că astfel de mașini sunt capabile să facă față cu succes sarcinilor cu care se confruntă, eficiența lor este de obicei destul de scăzută, iar productivitatea specifică a unui dezvoltator individual este atât de mică încât poate fi considerat normal ca un programator să scrie mai multe linii de cod. pe zi.

Modelele de dezvoltare rapidă, cum ar fi Extreme Programming, sunt concepute pentru a contesta astfel de abordări formaliste. Esența lor constă în respingerea a tot ceea ce nu este necesar care nu are legătură directă cu crearea unui produs software de înaltă calitate și doar cele mai eficiente metode de creare a software-ului sunt luate ca bază. O atenție deosebită este acordată problemelor de interacțiune cu clientul, organizația munca productivași testare. Multe dintre ideile de dezvoltare rapidă nu erau noi, de exemplu, testele unitare au fost folosite în multe proiecte de mult timp, dar atunci când sunt reunite și au devenit obligatorii pentru utilizare, au avut un efect pozitiv. Despre aceste metode în în ultima vreme au început să fie vorbite din ce în ce mai des, iar elementele lor au început să fie împrumutate de multe modele clasice.

În condițiile moderne, dezvoltarea rapidă este o abordare foarte la modă și este folosită din ce în ce mai activ. Principalul avantaj este că echipele relativ mici de dezvoltatori sunt capabile să finalizeze proiecte în aceeași perioadă de timp în care este nevoie de ordine de mărime echipelor mai mari pentru a utiliza metode mai tradiționale.

Cu toate acestea, există și dezavantaje aici, în special, dezvoltarea rapidă este slab potrivită pentru proiectele mari și se concentrează în principal pe cele mici și mijlocii, în plus; utilizare eficientă Acest lucru este posibil numai dacă creatorii de software au calificări foarte înalte și experiență semnificativă.

Modele adaptate și combinate. De fapt, pe măsură ce modelele ciclului de viață de dezvoltare a software-ului au evoluat, ideile noi nu le-au înlocuit complet pe cele vechi. Este mai corect să considerăm că fiecare dintre ele are propriul său domeniu de aplicare. În plus, în fiecare caz specific se poate dovedi că nu există nicio tehnică care să fie ideală pentru rezolvarea unei anumite probleme. În acest caz, managerii de proiect software ar trebui să ia în considerare opțiunile de adaptare a modelelor la nevoi specifice sau să utilizeze metode combinate care includ elemente abordări diferite. De exemplu, succesul dezvoltării rapide a dus la faptul că modelele mai conservatoare și-au adoptat tehnicile cele mai eficiente și au început să le folosească ca parte a proceselor lor.

Cursul 2.

Conceptul de ciclu de viață și modelul ciclului de viață. Modelul în cascadă al ciclului de viață. Model treptat cu control intermediar. Spirală modelciclu de viață. Proceseciclu de viațăDE. Dezvoltare rapidă a aplicațiilor (RAD). Programare extremă (XP). Procesul rațional unificat (RUP). Microsoft Solution Framework (MSF). Metodă de dezvoltare personalizată (metodologieOracol).

2.1. Conceptul de ciclu de viață și modelul ciclului de viață

ciclul de viață IS - perioada de timp care începe din momentul în care se ia o decizie privind necesitatea creării unui IP și se termină în momentul în care este complet retras din utilizare. Ciclul de viață al unui sistem informațional poate fi reprezentat ca o serie de evenimente care au loc cu sistemul în timpul procesului de creare și utilizare a acestuia.

Modelul ciclului de viață este înțeles ca o structură care definește succesiunea de execuție și relațiile proceselor, acțiunilor și sarcinilor care se desfășoară în timpul dezvoltării, exploatării și întreținerii unui produs software pe toată durata de viață a sistemului, de la determinarea cerințelor până la sfârșitul utilizării acestuia. (diapozitivul 2) .

Modelul ciclului de viață al software-ului include (diapozitivul 3) : etape, rezultatele muncii la fiecare etapă, evenimente cheie- puncte de finalizare a lucrărilor și de luare a deciziilor.

Sub etapă este înțeles ca o 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ă.

Un caz extrem al modelului ciclului de viață poate fi considerat așa-numitul model „cutie neagră” sau „cod și remediere”, ceea ce înseamnă de fapt absența oricărui model. În acest caz, nu este posibilă identificarea unor etape raționale în procesul de dezvoltare a software-ului, deoarece nu există planificare și organizare a muncii.

În prezent sunt cunoscute și utilizate următoarele modele de ciclu de viață:

Model în cascadă(tipic pentru perioada 1970-1980);

Model treptat cu control intermediar(tipic pentru perioada 1980-1985);

Model în spirală(tipic pentru perioada de după 1986)

2.2. Modelul ciclului de viață în cascadă

În 1970, expertul în software Winston Royce a publicat un articol apreciat pe scară largă în care și-a exprimat părerile despre o tehnică care mai târziu a devenit cunoscută sub numele de modelul cascadei. (diapozitivul 4) .

Ulterior, acest model a fost reglementat de multe documente de reglementare, în special, binecunoscutul standard al Departamentului de Apărare al SUA Dod-STD-2167A și standardele rusești din seria GOST 34.

Model în cascadăprevede implementarea succesivă a tuturor etapelor proiectului într-o ordine strict fixă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrărilor în etapa anterioară.

Proprietățile fundamentale ale așa-numitului model în cascadă „pur” sunt următoarele:

Fixarea cerințelor pentru sistem înainte de livrarea acestuia către client;

Execuția secvențială a etapelor.

Trecerea la următoarea etapă a proiectului numai după finalizarea completă a lucrărilor la etapa actuală, fără a reveni la etapele finalizate.

Fără suprapunere temporară a etapelor

Fără întoarcere la etapele anterioare

Disponibilitatea rezultatelor numai la sfârșitul dezvoltării.

Avantajele utilizării modelului î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 efectuate într-o succesiune logică fac posibilă planificarea timpului de finalizare a tuturor lucrărilor și a costurilor corespunzătoare.

Principalul dezavantaj al acestei abordări este că procesul real de creare a unui sistem nu se încadrează niciodată complet într-o schemă atât de rigidă, există în mod constant nevoia de a reveni la etapele anterioare și de a clarifica sau revizui deciziile luate anterior;

Alte dezavantaje ale abordării cu cascadă sunt:

depistarea tardivă a problemelor. Erorile sunt identificate și eliminate numai în faza de testare, care poate dura mult timp sau nu poate fi finalizată niciodată.

părăsirea programului calendaristic, întârzieri în obținerea rezultatelor;

cantitate excesivă de documente;

incapacitatea de a sparge sistemul în părți (întregul produs este dezvoltat la un moment dat);

risc ridicat de a crea un sistem care nu satisface nevoile în schimbare ale utilizatorilor.

Din punct de vedere istoric, acesta este primul model de ciclu de viață IS. A fost folosit pentru sisteme informatice destul de simple, când fiecare aplicație era un singur bloc, independent din punct de vedere funcțional și informațional. Acum modelul cascadă poate fi folosit pentru a crea software 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 din punct de vedere tehnic cât mai bine posibil.

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

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

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

Vorbitor într-un limbaj simplu, sisteme informatice sub formă de programe, baze de date sau chiar „sisteme de operare” sunt solicitate doar dacă datele și oportunitățile pe care le oferă sunt la zi.

Se crede că definiția ciclului de viață nu se aplică în niciun fel aplicațiilor de testare, cum ar fi versiunile beta, care sunt cele mai instabile în funcționare. Ciclul de viață al software-ului în sine depinde de mulți factori, printre care unul dintre rolurile principale este jucat de mediul în care programul va fi utilizat. Cu toate acestea, este posibil și evidențiat conditii generale, utilizat în definirea conceptului de ciclu de viață.

Cerințe inițiale

• enunțul problemei;
• analiza cerințelor reciproce ale viitorului software pentru sistem;
• proiecta;
• programare;
• codificare și compilare;
• testare;
• depanare;
• implementarea și întreținerea produsului software.

Dezvoltarea software constă din toate etapele menționate mai sus și nu se poate face fără cel puțin una dintre ele. Dar au fost stabilite standarde speciale pentru controlul unor astfel de procese.

Standarde de proces pentru ciclul de viață al software-ului

Printre sistemele care predetermină condițiile și cerințele pentru astfel de procese, astăzi putem numi doar trei principale:

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

Pentru al doilea standard international disponibil analog rusesc. Acesta este GOST R ISO/IEC 12207-2010, care este responsabil pentru ingineria sistemului și a software-ului. Dar ciclul de viață al software-ului descris în ambele reguli este în esență identic. Acest lucru este explicat destul de simplu.

Tipuri de software și actualizări

Apropo, pentru majoritatea acum programe celebre Multimedia este un mijloc de stocare a parametrilor de configurare de bază. Utilizarea software-ului de acest tip este, desigur, destul de limitată, dar înțelegerea principiilor generale de lucru cu aceleași playere media nu va strica. Și iată de ce.

De fapt, acestea includ ciclul de viață al software-ului doar la nivelul actualizării versiunii playerului propriu-zis sau al instalării de codecuri și decodore. Și transcodificatoarele audio și video sunt atribute integrante ale oricărui sistem audio sau video.

Exemplu bazat pe FL Studio

Inițial, studioul-sequencer virtual FL Studio se numea Fruity Loops. Ciclul de viață al software-ului în modificarea sa inițială a expirat, dar aplicația a fost oarecum transformată și a căpătat forma actuală.

Dacă vorbim despre etapele ciclului de viață, mai întâi, în etapa de stabilire a problemei, au fost stabilite câteva condiții obligatorii:

• crearea unui modul de tobe similar cu aparatele de ritm precum Yamaha RX, dar folosind mostre sau secvențe one-shot în format WAV înregistrate live în studiouri;
• integrare în sistemele de operare Windows;
• capacitatea de a exporta un proiect în formate WAV, MP3 și OGG;
• Compatibilitatea proiectelor cu aplicația suplimentară Fruity Tracks.

În stadiul de dezvoltare, s-au folosit instrumentele limbajului de programare C. Dar platforma arăta destul de primitivă și nu a oferit utilizatorului final calitatea necesară a sunetului.

În acest sens, în etapa de testare și depanare, dezvoltatorii au trebuit să urmeze calea corporației germane Steinberg și să aplice suport pentru modul Full Duplex în cerințele pentru driverul de sunet principal. Calitatea sunetului a devenit mai ridicată și vă permite să schimbați tempo-ul, înălțimea și să aplicați efecte FX suplimentare în timp real.

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

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

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

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

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

Perspective de dezvoltare

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

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

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

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

Dar dacă spunem că dezvoltarea software-ului de orice tip (de control sau aplicație) nu stă pe loc, putem spune doar că astăzi se referă nu numai la sisteme informatice, ci și la dispozitive mobile, în care tehnologiile folosite sunt deseori înaintea sectorul calculatoarelor. Apariția cipurilor de procesor bazate pe opt nuclee nu este cea mai bună cel mai bun exemplu? Dar nu orice laptop se poate lăuda cu un astfel de hardware.

Câteva întrebări suplimentare

În ceea ce privește înțelegerea ciclului de viață al software-ului, este destul de arbitrar să spunem că acesta s-a încheiat la un anumit moment în timp, deoarece produsele software încă beneficiază de sprijin de la dezvoltatorii care le-au creat. Mai degrabă, sfârșitul se referă la aplicații vechi care nu îndeplinesc cerințele sisteme moderneși nu pot lucra în mediul lor.

Dar chiar și ținând cont de progresul tehnologic, multe dintre ele pot deveni în curând insuportabile. Apoi va trebui să luați o decizie fie de a lansa actualizări, fie de a revizui complet întregul concept încorporat inițial în produsul software. De aici și noul ciclu, care presupune schimbarea condițiilor inițiale, a mediului de dezvoltare, testare și posibilă utilizare pe termen lung într-o anumită zonă.

Dar în tehnologia informatică astăzi se preferă dezvoltarea sistemelor automate de control (ACS), care sunt utilizate în producție. Chiar și sistemele de operare, în comparație cu programele specializate, pierd.

Aceleași medii bazate pe Visual Basic rămân mult mai populare decât sistemele Windows. Și nu vorbim deloc despre aplicații software pentru sisteme UNIX. Ce putem spune dacă aproape toate rețelele de comunicații ale acelorași Statele Unite ale Americii funcționează exclusiv pentru ei. Apropo, sisteme precum Linux și Android au fost create inițial pe această platformă. Prin urmare, cel mai probabil, UNIX are mult mai multe perspective decât alte produse combinate.

În loc de un total

Rămâne de adăugat că numai în acest caz principii generaleși etapele ciclului de viață al software-ului. De fapt, chiar și sarcinile stabilite inițial pot varia foarte semnificativ. În consecință, diferențele pot fi observate în alte etape.

Dar tehnologiile de bază pentru dezvoltarea produselor software și suportul lor ulterior ar trebui să fie clare. În rest, ar trebui să se țină cont de specificul software-ului creat, de mediile în care ar trebui să funcționeze și de capacitățile programelor furnizate utilizatorului final sau producției și multe altele.

În plus, uneori ciclurile de viață pot depinde de relevanța instrumentelor de dezvoltare. Dacă, de exemplu, un limbaj de programare devine învechit, nimeni nu va scrie programe bazate pe el, cu atât mai puțin le va implementa în sistemele automate de control al producției. Aici nici măcar programatorii ies în prim-plan, ci marketerii trebuie să răspundă în timp util la schimbările de pe piața calculatoarelor. Și nu există atât de mulți astfel de specialiști în lume. Personalul cu înaltă calificare care poate ține degetul pe pulsul pieței devine cel mai solicitat. Și sunt adesea așa-numitele „ cardinali cenuşii”, de care depinde succesul sau eșecul unui anumit produs software în domeniul IT.

S-ar putea să nu înțeleagă întotdeauna esența programării, dar sunt în mod clar capabili să determine modele ale ciclului de viață al software-ului și durata de timp pentru utilizarea lor, pe baza tendințelor globale în acest domeniu. Un management eficient produce adesea rezultate mai tangibile. Da, cel puțin tehnologii de PR, publicitate etc. Este posibil ca utilizatorul să nu aibă nevoie de vreo aplicație, dar dacă este promovată activ, utilizatorul o va instala. Acesta este deja, ca să spunem așa, un nivel subconștient (același efect al celui de-al 25-lea cadru, când informația este introdusă în conștiința utilizatorului independent de el).

Desigur, astfel de tehnologii sunt interzise în lume, dar mulți dintre noi nici nu realizăm că ele pot fi încă folosite și influențează subconștientul într-un anumit fel. Priviți doar costul „zombificării” de către canalele de știri sau site-urile de internet, ca să nu mai vorbim de utilizarea unor mijloace mai puternice, cum ar fi expunerea la infrasunete (aceasta a fost folosită într-o producție de operă), în urma cărora o persoană poate experimenta frică sau emoții nepotrivite.

Revenind la software, merită adăugat că unele programe folosesc un semnal sonor la pornire pentru a atrage atenția utilizatorului. Și, după cum arată cercetările, astfel de aplicații sunt mai viabile decât alte programe. Desigur, și ciclul de viață al software-ului crește, indiferent de funcția care i-a fost atribuită inițial. Și, din păcate, mulți dezvoltatori folosesc acest lucru, ceea ce ridică îndoieli cu privire la legalitatea unor astfel de metode.

Dar nu este de noi să judecăm asta. Este posibil ca în viitorul apropiat să fie dezvoltate instrumente pentru a identifica astfel de amenințări. Până acum aceasta este doar o teorie, dar, potrivit unor analiști și experți, până la aplicare practică A mai rămas foarte puțin. Dacă fac deja copii rețele neuronale creierul uman, atunci ce pot spune?

Bună ziua, dragi locuitori din Khabrovsk! Cred că va fi interesant ca cineva să-și amintească ce modele de dezvoltare, implementare și utilizare a software-ului au existat anterior, ce modele sunt utilizate în principal acum, de ce și ce este de fapt. Acesta va fi micul meu subiect.

De fapt, ce este ciclul de viață al software-ului- o serie de evenimente care apar cu sistemul în timpul creării și utilizării ulterioare. Cu alte cuvinte, acesta este timpul de la momentul de pornire crearea oricărui produs software până la finalul dezvoltării și implementării acestuia. Ciclul de viață al software-ului poate fi reprezentat sub formă de modele.

Modelul ciclului de viață al software-ului- o structură care conține procese de acțiune și sarcini care sunt efectuate în timpul dezvoltării, utilizării și întreținerii unui produs software.
Aceste modele pot fi împărțite în 3 grupuri principale:

1. Abordare inginerească
2. Ținând cont de specificul sarcinii
3. Tehnologii moderne de dezvoltare rapidă

Acum să ne uităm la modelele (subclasele) existente și să evaluăm avantajele și dezavantajele acestora.

Model de codificare și eliminare a erorilor

Absolut model simplu, tipic pentru studenții universitari. În conformitate cu acest model, majoritatea studenților dezvoltă, să spunem, lucrări de laborator.
Acest model are următorul algoritm:

1. Enunțarea problemei
2. Execuţie
3. Verificarea rezultatului
4. Dacă este necesar, treceți la primul punct

Model de asemenea teribilînvechit. Este tipic pentru anii 1960-1970, deci practic nu are avantaje față de următoarele modele din recenzia noastră, dar dezavantajele sunt evidente. Face parte din primul grup de modele.

Modelul ciclului de viață al software-ului în cascadă (cascada)

Algoritmul acestei metode, pe care îl arăt în diagramă, are o serie de avantaje față de algoritmul modelului anterior, dar are și un număr de semnificativ neajunsuri.

Avantaje:

• Implementarea succesivă a etapelor proiectului într-o ordine strict fixă
• Vă permite să evaluați calitatea produsului în fiecare etapă

Defecte:

• Fără feedback între etape
• Nu se potrivește conditii reale dezvoltare de produse software

Face parte din primul grup de modele.

Model în cascadă cu control intermediar (vârtej)

Acest model este aproape echivalent ca algoritm cu modelul anterior, cu toate acestea, are feedback-uri cu fiecare etapă a ciclului de viață, dând în același timp la un dezavantaj foarte semnificativ: Creșterea de 10 ori a costurilor de dezvoltare. Face parte din primul grup de modele.

Model V (dezvoltare bazată pe teste)

Acest model are un algoritm mai apropiat de metodele moderne, dar are totuși o serie de dezavantaje. Este una dintre practicile principale ale programării extreme.

Model bazat pe dezvoltarea prototipului

Acest model se bazează pe dezvoltarea de prototipuri și prototiparea produselor.
Prototiparea utilizat la începutul ciclului de viață al software-ului:

1. Clarificarea cerințelor neclare (prototip UI)
2. Alegeți una dintre numeroasele soluții conceptuale (implementarea scenariilor)
3. Analizați fezabilitatea proiectului

Clasificarea prototipurilor:

1. Orizontală și verticală
2. De unică folosință și evolutiv
3. hârtie și storyboard-uri

Orizontală prototipuri - modelează exclusiv UI fără a afecta logica de procesare și baza de date.
Vertical prototipuri - testarea solutiilor arhitecturale.
De unică folosință prototipuri - pentru dezvoltare rapidă.
Evolutiv prototipurile sunt prima aproximare a unui sistem evolutiv.

Modelul aparține celui de-al doilea grup.

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

Modelul în spirală este un proces de dezvoltare software care combină atât proiectarea, cât și prototiparea incrementală pentru a combina beneficiile conceptelor de jos în sus și de sus în jos.

Avantaje:

• Obțineți rapid rezultate
• Creșterea competitivității
• Schimbarea cerințelor nu este o problemă

Defecte:

• Lipsa regulamentului de etapă

Al treilea grup include modele precum programare extremă(XP) SCRUM, model incremental(RUP), dar aș vrea să vorbesc despre ele într-un subiect separat.

Vă mulțumesc foarte mult pentru atenție!