Ciclul de viață al sistemelor informaționale. Ciclul de viață IP și structura acestuia

Ciclul de viață al unui sistem informațional este o perioadă de timp care începe din momentul în care se ia o decizie privind necesitatea creării unui sistem informațional și se termină în momentul retragerii sale complete din funcționare.

concept ciclu de viață este unul dintre conceptele de bază ale metodologiei de proiectare a sistemelor informaţionale.

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

Ciclul complet de viață al unui sistem informațional include, de regulă, planificare strategica, analiză, proiectare, implementare, implementare și exploatare. În general, ciclul de viață poate fi, la rândul său, împărțit în mai multe etape. În principiu, această împărțire în etape este destul de arbitrară. Vom lua în considerare una dintre opțiunile pentru o astfel de divizie, oferită de Rational Software Corporation, una dintre companiile lider pe piața de software pentru instrumente de dezvoltare a sistemelor informatice (printre care instrumentul universal CASE Rational Rose merită o mare popularitate).

Etapele ciclului de viață IP

Etapa - parte a procesului de creare a unui IS, limitată de un anumit interval de timp și care se termină cu lansarea unui anumit produs (modele, componente software, documentație), determinată de cerințele specificate pentru această etapă. Relația dintre procese și etape este determinată și de modelul ciclului de viață IS utilizat.

Conform metodologiei oferite de Rational Software, ciclul de viață al unui sistem informațional este împărțit în patru etape.

Granițele fiecărei etape sunt definite de anumite momente în timp în care este necesar să se ia anumite decizii critice și, prin urmare, să se atingă anumite obiective cheie.

1) Etapa inițială

Pe stadiul inițial se stabilește domeniul de aplicare al sistemului și se determină condițiile la limită. Pentru a face acest lucru, este necesar să se identifice toate obiectele externe cu care sistemul dezvoltat ar trebui să interacționeze și să se determine natura acestei interacțiuni la un nivel înalt. În etapa inițială, sunt identificate toate capacitățile funcționale ale sistemului și se face o descriere a celor mai semnificative dintre ele.

2) Etapa de rafinare

La etapa de rafinare se efectuează o analiză a zonei de aplicare și se dezvoltă baza arhitecturală a sistemului informațional.

La luarea oricăror decizii cu privire la arhitectura sistemului, este necesar să se țină cont de sistemul în curs de dezvoltare în ansamblu. Aceasta înseamnă că este necesar să descrii cele mai multe funcţionalitate sistem și să țină cont de relația dintre componentele sale individuale.

La sfârșitul etapei de clarificare, se efectuează o analiză solutii arhitecturaleși modalități de a elimina principalii factori de risc din proiect.

3) Etapa de construcție

În etapa de proiectare, este dezvoltat un produs finit, gata de transfer către utilizator.

La finalul acestei etape se determină performanța software-ului dezvoltat.

4) Etapa de punere în funcțiune

În etapa de punere în funcțiune, software-ul dezvoltat este transferat utilizatorilor. Când se operează sistemul dezvoltat în condiții reale, apar adesea diferite tipuri de probleme care necesită muncă suplimentară pentru a face ajustări la produsul dezvoltat. Acest lucru este de obicei asociat cu detectarea erorilor și defectelor.

La finalul fazei de predare trebuie stabilit dacă obiectivele de dezvoltare au fost atinse sau nu.

Standardele ciclului de viață IP

Rețelele moderne sunt dezvoltate pe baza standardelor, ceea ce face posibilă furnizarea, în primul rând, a acestora Eficiență ridicatăși, în al doilea rând, posibilitatea interacțiunii lor între ele.

Printre cele mai cunoscute standarde se numără următoarele:

GOST 34.601-90 - se aplică sistemelor automate și stabilește etapele și etapele creării acestora. În plus, standardul conține o descriere a domeniului de activitate în fiecare etapă. Etapele și etapele de lucru, consacrate în standard, sunt mai în concordanță cu modelul ciclului de viață în cascadă.

ISO / IEC 12207 (Organizația Internațională de Standardizare / Comisia Electrotehnică Internațională) 1995 - un standard pentru procese și organizarea ciclului de viață. Se aplică tuturor tipurilor de software personalizat. Standardul nu conține descrieri ale fazelor, etapelor și etapelor.

Procesul Rational Unified (RUP) oferă un model de dezvoltare iterativ care include patru faze: pornire, explorare, construire și implementare. Fiecare fază poate fi împărțită în etape (iterații) care au ca rezultat o eliberare pentru uz intern sau extern. Trecerea prin patru faze principale se numește ciclu de dezvoltare, fiecare ciclu se termină cu generarea unei versiuni a sistemului. Dacă după aceea lucrarea la proiect nu se oprește, atunci produsul rezultat continuă să se dezvolte și trece din nou prin aceleași faze. Esența muncii în cadrul RUP este crearea și întreținerea modelelor bazate pe UML.

Microsoft Solution Framework (MSF) este similar cu RUP, include și patru faze: analiză, proiectare, dezvoltare, stabilizare, este iterativă, implică utilizarea modelării orientate pe obiecte. MSF se concentrează mai mult pe dezvoltarea de aplicații de afaceri decât RUP.

Programare extremă (XP). Extreme Programming (cea mai nouă dintre metodologiile luate în considerare) a fost înființată în 1996. Metodologia se bazează pe lucrul în echipă, comunicare eficientă între client și contractor pe parcursul întregului proiect de dezvoltare IP, iar dezvoltarea se realizează folosind prototipuri rafinate succesiv.

ciclul de viață în spirală în cascadă

ZHIS este perioada de creare și utilizare a IS, începând din momentul în care apare nevoia de IS și terminând cu momentul în care acesta este complet nefuncțional.

Ciclul de viață este un model de creare și utilizare a software-ului, reflectând diferitele sale stări, începând din momentul în care apare nevoia acestui produs software și terminând cu momentul în care acesta este complet neutilizat pentru toți utilizatorii.

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

• analiza cerințelor;
• proiecta;
• codificare (programare);
• testare și depanare;
• operare si intretinere.

Etapele ciclului de viață al unui sistem informațional

1. Sondaj înainte de proiect
   • 1.1. Colectare de materiale pentru proiectare; în același timp, se evidențiază formularea cerințelor, studiul obiectului de automatizare, se dau concluzii preliminare ale versiunii de pre-proiectare a IS.
   • 1.2. Analiza materialelor și elaborarea documentației; un studiu de fezabilitate cu o sarcină tehnică pt Design IC.
2. Proiecta
   • 2.1. Proiectare preliminară:
     • selectarea soluțiilor de proiectare pe aspecte ale dezvoltării SI;
     • descrierea componentelor IS reale;
     • proiectare si aprobare proiect tehnic(TP).
   • 2.2. Design detaliat:
     • selecție sau dezvoltare metode matematice sau algoritmi de program;
     • ajustarea structurilor bazei de date;
     • realizarea documentatiei pentru livrare si instalare produse software;
     • selectarea unui complex de mijloace tehnice cu documentație pentru instalarea acestuia.
   • 2.3. Dezvoltarea unui proiect tehnologic de IP (TRP).
   • 2.4. Elaborarea unei metodologii de implementare a funcțiilor de management folosind SI și o descriere a reglementărilor pentru acțiunile aparatului de management.
3. Dezvoltarea IS
   • receptie si instalare hardware si software;
   • testarea și reglarea fină a pachetului software;
   • elaborarea de instrucţiuni de operare a software-ului şi hardware-ului.
4. Punerea în funcțiune a IS
   • introducerea mijloacelor tehnice;
   • introducerea de software;
   • instruirea și certificarea personalului;
   • operațiune de probă;
   • livrarea si semnarea actelor de receptie si livrare a lucrarilor.
5. Operare IP
   • funcționare zilnică;
   • sprijinul general al întregului proiect.

Ciclul de viață este format în conformitate cu principiul design de sus în josși, de regulă, este de natură iterativă: etapele implementate, începând de la cele mai timpurii, se repetă ciclic în funcție de modificările cerințelor și condițiilor externe, introducerea de restricții etc. La fiecare etapă a ciclului de viață se generează un anumit set de documente și soluții tehnice; totodată, pentru fiecare etapă, documentele și deciziile obținute la etapa anterioară sunt cele inițiale. Fiecare etapă se încheie cu verificarea documentelor și soluțiilor generate pentru a verifica conformitatea acestora cu cele originale.

Principalul document de reglementare care reglementează ciclul de viață al software-ului este standardul internațional ISO/IEC 12207 (ISO – International Organization of Standardization – International Organization for Standardization, IEC – International Electrotechnical Commission – International Electrotechnical Commission). Acesta definește o structură a ciclului de viață care conține procesele, activitățile și sarcinile care trebuie finalizate în timpul dezvoltării software.

Structura ciclului de viață al software-ului conform standardului ISO/IEC 12207 se bazează pe trei grupuri de procese:

• principalele procese ale ciclului de viață al software-ului (achiziție, furnizare, dezvoltare, operare, întreținere);
• procese auxiliare care asigură implementarea principalelor procese (documentare, managementul configurației, asigurarea calității, verificarea, certificarea, evaluarea, auditul, rezolvarea problemelor);
• procese organizatorice (managementul de proiect, crearea infrastructurii proiectului, definirea, evaluarea și îmbunătățirea ciclului de viață în sine, instruire).

Dezvoltarea include toate lucrările privind crearea de software și componentele acestuia în conformitate cu cerințele specificate. Aceasta include execuția documentației de proiectare și exploatare, pregătirea materialelor necesare pentru testarea operabilității și a corespunzătoare calitatea produselor software, materiale necesare organizării pregătirii personalului etc. Dezvoltarea software include de obicei analiză, proiectare și implementare (programare).

Funcționarea include lucrările privind punerea în funcțiune a componentelor software. Acest proces include configurarea bazei de date și a stațiilor de lucru ale utilizatorilor, furnizarea documentației operaționale, desfășurarea instruirii personalului etc. și operarea directă, inclusiv localizarea problemelor și eliminarea cauzelor apariției acestora, modificarea software-ului în cadrul reglementărilor stabilite, pregătirea propunerilor de îmbunătățire, dezvoltare și modernizarea sistemului.

Managementul proiectelor este legat de problemele de planificare și organizare a muncii, crearea de echipe de dezvoltatori și monitorizarea timpului și calității muncii efectuate. Sprijinul tehnic și organizatoric al proiectului include alegerea metodelor și instrumentelor pentru implementarea proiectului, definirea metodelor de descriere a stărilor intermediare de dezvoltare, dezvoltarea metodelor și instrumentelor pentru testarea software-ului, pregătirea personalului etc. Asigurarea calității proiectului este legată de problemele de verificare, verificare și testare a software-ului.

Verificarea este procesul prin care se determină dacă starea actuală de dezvoltare atinsă la o anumită etapă îndeplinește cerințele etapei respective. Validarea vă permite să evaluați conformitatea parametrilor de dezvoltare cu cerințele originale. Verificarea se suprapune cu testarea, care se preocupă de identificarea diferențelor dintre rezultatele reale și cele așteptate și de evaluarea dacă caracteristicile software îndeplinesc cerințele originale. În procesul de implementare a proiectului loc important sunt ocupate chestiuni de identificare, descriere și control al configurației componentelor individuale și a întregului sistem în ansamblu.

Managementul configurației este unul dintre procesele auxiliare care susțin procesele principale ale ciclului de viață al software-ului, în primul rând procesele de dezvoltare și întreținere software. Atunci când se creează proiecte IS complexe constând din multe componente, fiecare dintre ele putând avea varietăți sau versiuni, se pune problema luării în considerare a relațiilor și funcțiilor acestora, crearea unei structuri unificate și asigurarea dezvoltării întregului sistem. Managementul configurației vă permite să organizați, să luați în considerare sistematic și să controlați modificările aduse software-ului în toate etapele ciclului de viață. Principii generale iar recomandările pentru contabilitatea configurației, planificarea și gestionarea configurațiilor software sunt reflectate în proiectul standardului ISO 12207-2.

Fiecare proces este caracterizat de anumite sarcini și metode de rezolvare a acestora, datele inițiale obținute în etapa anterioară și rezultatele. Rezultatele analizei, în special, sunt modele funcționale, modele de informații și diagramele lor corespunzătoare. Ciclul de viață al software-ului este de natură iterativă: rezultatele etapei următoare provoacă adesea schimbări în deciziile de proiectare dezvoltate în etapele anterioare.

Ciclul de viață nu este o perioadă de timp de existență, ci un proces de schimbări succesive de stare, datorită tipului de impacturi produse (R 50-605-80-93).

Termenul „ciclu de viață al sistemului” este de obicei înțeles ca evoluția unui nou sistem sub forma mai multor etape, incluzând etape atât de importante precum conceperea, dezvoltarea, producția, exploatarea și dezafectarea finală:70.

Istoria conceptului de ciclu de viață

Conceptul de ciclu de viață a apărut la sfârșitul secolului al XIX-lea. ca un set de idei care includ ideile de ereditate și dezvoltare la nivelul indivizilor și organismelor, precum și adaptarea, supraviețuirea și extincția la nivelul speciilor individuale și populațiilor întregi de organisme vii.

Modele generice ale ciclului de viață al sistemului

Nu există un model unic de ciclu de viață care să satisfacă cerințele fiecărei sarcini posibile. Diverse organizații de standardizare, agenții guvernamentale și comunități de inginerie își publică propriile modele și tehnologii care pot fi utilizate pentru a construi modelul. Astfel, este nepotrivit să se afirme existența singurului algoritm posibil pentru construirea unui model de ciclu de viață.

Unii ingineri de sisteme sugerează să se ia în considerare un model de ciclu de viață al sistemului bazat pe următoarele trei surse: Modelul de management al logisticii al Departamentului de Apărare al Statelor Unite (DoD) (DoD 5000.2), modelul ISO/IEC 15288 și Societatea Națională a Inginerilor Profesionişti (NSPE). ) model. ) :71 .

ISO/IEC 15288 Model generic de ciclu de viață

Conform standardului, procesele și activitățile ciclului de viață sunt definite, configurate și utilizate corespunzător pe parcursul etapei ciclului de viață, pentru a satisface pe deplin obiectivele și rezultatele în această etapă. Diferite organizații pot fi implicate în diferite etape ale ciclului de viață. Nu există un model universal unic al ciclurilor de viață ale sistemelor. Anumite etape ale ciclului de viață pot fi absente sau prezente în funcție de fiecare caz specific de dezvoltare a sistemului :34 .

Următoarele etape ale ciclului de viață au fost date ca exemplu în standard:

1. Proiecta.
2. Dezvoltare.
3. Productie.
4. Aplicație.
5. Suport aplicatie.
6. Încetarea și anularea.

Versiunea 2008 a standardului (ISO/IEC 15288:2008) nu include exemple de etape ale ciclului de viață.

Modelul generic al ciclului de viață al Departamentului de Apărare al SUA

Pentru a gestiona riscurile în aplicarea tehnologiilor avansate și pentru a minimiza erorile tehnice sau manageriale costisitoare, Departamentul de Apărare al SUA a elaborat un manual care conține toate principiile necesare pentru dezvoltarea sistemelor. Aceste principii sunt incluse într-o listă specială de directive - DoD 5000.

Modelul ciclului de viață al sistemului de management al logisticii DoD constă din cinci etape:71:

1. Analiză.
2. Dezvoltarea tehnologiei.
3. Inginerie și dezvoltare producție.
4. Productie si implementare.
5. Operare și suport.

Modelul de referință al ciclului de viață al sistemului Societății Naționale a Inginerilor Profesioniști (NSPE).

Acest model este adaptat pentru dezvoltarea sistemelor comerciale. Acest model este axat în principal pe dezvoltarea de noi produse, de obicei rezultatul progres tehnic. Modelul NSPE este o vedere alternativă a versiunii US DoD a modelului. Ciclul de viață conform modelului NSPE este împărțit în șase etape:72:

1. Concept.
2. Implementare tehnica.
3. Dezvoltare.
4. Validare comercială și pre-producție.
5. Productie la scara completa.
6. Asistență pentru produsul final.

Model tipic ciclului de viață al produsului conform R 50-605-80-93

În documentul de ghidare R 50-605-80-93, ciclul de viață al unui produs industrial, inclusiv al echipamentelor militare, este elaborat cu atenție.

Pentru produsele industriale civile se propun următoarele etape:

1. Cercetare și proiectare.
2. De fabricație.
3. Manipulare și implementare.
4. exploatare sau consum.

Ca parte a ciclului de viață al produselor industriale civile, se propune să se ia în considerare 73 de tipuri de muncă și 23 de tipuri de părți interesate („participanți la lucru” în terminologia documentului).

Pentru produsele industriale militare se propun următoarele etape:

1. Cercetarea și justificarea dezvoltării.
2. Dezvoltare.
3. Productie.
4. Exploatare.
5. Reparații capitale.

Ca parte a ciclului de viață al produselor industriale militare, se propune să se ia în considerare 25 de tipuri de muncă și 7 tipuri de părți interesate (participanți la muncă).

Modelul ciclului de viață al software-ului generic

Etapele ciclului de viață al sistemului și fazele componente ale acestora, prezentate în figura Modelul ciclului de viață al sistemului, se aplică majorității sistemelor complexe, inclusiv celor care conțin software cu o cantitate semnificativă de funcționalitate la nivel de componentă. În sistemele intensive de software, în care software-ul îndeplinește aproape toate funcțiile (de exemplu, în sistemele financiare moderne, în sistemele de rezervare a companiilor aeriene, pe internetul global etc.), de regulă, ciclurile de viață sunt similare în conținut, dar sunt adesea complicat de procese iterative și prototipare :72-73 .

Etapele principale ale ciclului de viață al sistemului (Kossiakoff, Sweet, Seymour, Biemer)

După cum se arată în figura modelului ciclului de viață al sistemului, modelul ciclului de viață al sistemului conține 3 etape. Primele 2 etape sunt dezvoltarea, iar a treia etapă acoperă post-dezvoltarea. Aceste etape arată tranzițiile mai generale de la stare la stare, în ciclul de viață al unui sistem și, de asemenea, arată schimbări în tipul și domeniul de aplicare al activităților implicate în ingineria sistemelor. Etapele sunt :73:

• etapa de dezvoltare a conceptului;
• stadiul de dezvoltare tehnică;
• etapa post-dezvoltare.

Etapa de dezvoltare a conceptului

Scopul etapei de dezvoltare a conceptului este de a evalua noi oportunități în domeniul de aplicare a sistemului, dezvoltarea preliminară Cerințe de sistemși posibile soluții de proiectare. Etapa de dezvoltare a designului conceptual începe cu realizarea necesității de a crea un nou sistem sau de a modifica unul existent. Etapa cuprinde începutul cercetării faptelor, se evaluează perioada de planificare, bazele economice, tehnice, strategice și de piață pentru acțiunile viitoare. Există un dialog între părțile interesate și dezvoltatori.

Obiectivele principale ale etapei de dezvoltare a conceptului:74:

1. Realizarea de studii pentru a stabili ceea ce este necesar pentru un nou sistem, precum și pentru a stabili fezabilitatea tehnică și economică a acestui sistem.
2. Explorați concepte potențiale de sistem și formulați și validați un set de cerințe de performanță a sistemului.
3. Alege cel mai atractiv concept de sistem, definește-l caracteristici functionale, precum și elaborarea unui plan detaliat pentru etapele ulterioare de proiectare, producție și implementare operațională a sistemului.
4. Dezvoltați orice tehnologie nouă adecvat pentru conceptul de sistem ales și validarea capacității acestuia de a răspunde nevoilor.

Etapa de dezvoltare tehnică

Etapa de dezvoltare tehnică se referă la procesul de proiectare a unui sistem pentru a implementa funcțiile formulate în conceptul de sistem într-o implementare fizică care poate fi susținută și operată cu succes în mediul său de operare. Ingineria sistemelor se ocupă în primul rând de direcția dezvoltării și proiectării, gestionarea interfeței, dezvoltarea planurilor de testare și determină modul în care discrepanțele în performanța sistemului neverificate în timpul testării și evaluării ar trebui corectate în mod corespunzător. Cea mai mare parte a activităților de inginerie se desfășoară în această etapă.

Obiectivele principale ale etapei de dezvoltare tehnică sunt:74:

1. Efectuați dezvoltarea inginerească a unui prototip de sistem care îndeplinește cerințele de performanță, fiabilitate, întreținere și siguranță.
2. Proiectați un sistem utilizabil și demonstrați adecvarea operațională a acestuia.

Etapa post-dezvoltare

Etapa de post-dezvoltare constă în activități în afara perioadei de dezvoltare a sistemului, dar necesită totuși sprijin semnificativ din partea inginerilor de sistem, mai ales atunci când se întâlnesc probleme neprevăzute care trebuie rezolvate cât mai curând posibil. În plus, progresele tehnologice necesită adesea actualizări interne ale sistemului de servicii, care pot fi la fel de dependente de ingineria sistemelor precum conceptul și etapele de inginerie.

Laboratorul #1

Izolarea ciclurilor de viață ale proiectării sistemelor informatice

Scopul lucrării: familiarizați-vă cu modelele ciclului de viață al sistemelor informatice, determinați avantajele și dezavantajele modelelor, alegeți un model pentru construirea unui sistem informatic al unei sarcini individuale de proiectare și instrumente software, întocmește un plan pentru implementarea unui individ sarcina de proiectare.

Informații teoretice scurte.

Ciclul de viață al sistemului informațional

Dezvoltarea sistemelor informatice complexe (SI) este imposibilă fără o abordare metodologică atent analizată. Conceptul de ciclu de viață este unul dintre conceptele de bază ale metodologiei de proiectare a sistemelor informaționale.

Ciclul de viață IP –este un proces continuu din momentul în care se ia o decizie cu privire la necesitatea de a lua o decizie cu privire la necesitatea creării ei până la finalizarea completă a funcționării sale.

Procesul de proiectare AIS este reglementat de următoarea documentație (standarde, metodologii, modele):

· GOST 34.601-90. Intrat în vigoare la 01.01.1992. Stabilește etapele și etapele creării sistemelor automatizate și oferă conținutul lucrării la fiecare etapă. Etapele și etapele de lucru, fixate în standard, corespund model de cascadă ciclu de viață.

· ISO/IEC 12207:1995. Un standard internațional care descrie procesele ciclului de viață al software-ului. Conține o descriere a peste 220 de lucrări de bază, a căror implementare poate fi necesară în procesul de creare a unui IS. Toate procesele ciclului de viață al software-ului sunt împărțite în trei grupuri mari:

o Procese de bază (achiziție, furnizare, dezvoltare, operare, întreținere);

o Procese de ajutor(documentare, managementul configurației, asigurarea calității, rezolvarea problemelor, audit, validare, evaluare comună, verificare);

o Procese organizaționale (crearea infrastructurii, management, instruire, îmbunătățire).

Pentru a implementa prevederile standardului, trebuie selectate instrumente care formează împreună un complex interconectat de suport tehnologic și automatizare a ciclului de viață al software-ului și să nu contravină setului pre-asamblat. documente normative. A facilita uz practic standard, organizația internațională de standardizare a elaborat și aprobat următoarele documente:

o ISO/IEC TR 15271:1998 - ghid pentru aplicarea ISO/IEC 12207;

o ISO/IEC TR 16326:1999 - îndrumări privind managementul de proiect atunci când se utilizează ISO/IEC 12207.

· ISO/IEC 15288:2002. Descrierea standardului internațional procese posibile ciclul de viață al sistemelor create de om. A fost creată ținând cont de experiența în proiectarea sistemelor informatice automatizate, precum și cu implicarea specialiștilor din diverse domenii: inginerie de sistem, programare, administrare, managementul calității, securitate etc. Se presupune că standardul conține setul complet de procese care pot avea loc în timpul ciclului de viață al sistemului. Astfel, sarcina dezvoltatorului IS este de a forma setul de care are nevoie - mediul de proces. Revizuirea standardului notează că acesta nu conține o descriere a metodelor și procedurilor necesare pentru a se asigura că scopurile, obiectivele și rezultatele acestor procese sunt îndeplinite. În 2003, a fost publicat un ghid de aplicare a standardului (ISO/IEC TR 19760:2003). În prezent, lucrările continuă la pregătirea unei noi ediții a standardului din seria 15288.

· Rational Unified Process (RUP) - conceptul de dezvoltare software iterativă (spirală) propus de Rational Software (acum o divizie a IBM). Ciclul de viață al IP constă din patru faze: inițiere, cercetare (elaborare), proiectare (construcție) și implementare (tranziție). Fiecare fază poate conține mai multe iterații. În plus, finalizarea tuturor celor patru faze nu înseamnă întotdeauna finalizarea lucrărilor la proiect - dezvoltarea acestuia poate continua cu un nou ciclu. Ca parte a iterațiilor, sunt create modele convenite de comun acord, care sunt descrise într-un UML (Unified Modeling Language) special dezvoltat.

· Microsoft Solution Framework (MSF). O metodologie iterativă de dezvoltare a aplicațiilor similară cu RUP. De asemenea, include patru faze: analiză, proiectare, dezvoltare, stabilizare și implică utilizarea modelării orientate pe obiecte. În comparație cu RUP, este mai axat pe dezvoltarea IP pentru afaceri.

· Programare extremă (XP). Programarea extremă este cea mai nouă dintre metodologiile luate în considerare (primele idei au fost formate la mijlocul anilor 1990). Principii de bază: lucru în echipă, interacțiune eficientă între client și antreprenor pe toată durata dezvoltării SI, utilizarea de prototipuri îmbunătățite constant, atingerea flexibilității maxime de dezvoltare (adaptare la cerințele în schimbare ale clienților).

Modele ale ciclului de viață al IS.

Modelul ciclului de viață IS este înțeles ca o structură care determină succesiunea execuției și relația dintre procesele de acțiune și sarcinile de-a lungul ciclului de viață.

Modelul ciclului de viață IP- este o structură care descrie procesele, activitățile și sarcinile care sunt efectuate în timpul dezvoltării, exploatării și întreținerii de-a lungul întregului ciclu de viață al sistemului.

Alegerea unui model de ciclu de viață depinde de specificul, scara, complexitatea proiectului și setul de condiții în care este creat și funcționează AIS.

În conformitate cu modele celebre Ciclurile de viață software definesc modelele ciclului de viață IS - cascadă, iterativă, spirală.

I. Model în cascadă descrie abordarea clasică a dezvoltării sistemelor în orice domeniu; a fost utilizat pe scară largă în anii 1970 și 80.

Modelul în cascadă oferă o organizare secvențială a muncii, iar principala caracteristică a modelului este împărțirea tuturor lucrărilor în etape. Trecerea de la etapa anterioară la următoarea are loc numai după finalizarea completă a tuturor lucrărilor precedentei.

Aloca cinci etape de dezvoltare durabilă, practic independente de domeniul de studiu:

În prima etapă, se efectuează un studiu al zonei cu probleme, se formulează cerințele clienților. Rezultatul acestei etape sunt termenii de referință (sarcina de dezvoltare), conveniți cu toate părțile interesate.

În a doua etapă, în conformitate cu cerințele caietului de sarcini, sunt dezvoltate anumite soluții de proiectare. Rezultatul este un set documentatia proiectului.

A treia etapă este implementarea proiectului; în esență, dezvoltarea software-ului (codarea) în conformitate cu deciziile de proiectare din etapa anterioară. Metodele de implementare nu au o importanță fundamentală. Rezultatul etapei este un produs software finit.

În a patra etapă, software-ul primit este verificat pentru conformitatea cu cerințele prevăzute în termenii de referință. Operarea de probă vă permite să identificați diferite tipuri de deficiențe ascunse care se manifestă în condiții reale de funcționare a IS.

Ultima etapă este livrarea proiectului finalizat.

În fiecare etapă, se formează un set complet de documentație de proiect care îndeplinește criteriile de completitudine și coerență. În etapele finale, este elaborată documentația utilizatorului, care acoperă toate tipurile de suport AIS prevăzute de standarde (organizațional, informațional, software, tehnic etc.). Execuția secvențială a etapelor de lucru vă permite să planificați datele de finalizare și costurile aferente.

În același timp, pentru modelul în cascadă, este necesar să se constate întârzieri semnificative în obținerea rezultatelor, complexitatea lucrărilor paralele de proiect și complexitatea managementului proiectelor și, ca urmare, un nivel ridicat de risc și nefiabilitate a investițiilor în IP. . În plus, erorile și neajunsurile în oricare dintre etape apar, de regulă, în etapele ulterioare de lucru, ceea ce duce la necesitatea unei retururi.

II. Model iterativ se află într-o serie cicluri scurte(pași) a planifica, implementa, învăța, acționa. IS este în curs de dezvoltare 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 este prelungită pe întreaga perioadă de dezvoltare.

Crearea SI complex presupune coordonarea soluțiilor de proiectare obținute în implementarea sarcinilor individuale. Abordarea de proiectare „de jos în sus” necesită astfel de iterații ale returnărilor, atunci când soluțiile de proiectare pentru sarcini individuale sunt combinate în soluții de sistem comune. În acest caz, este necesar să se revizuiască cerințele formate anterior.

În modelul iterativ, ajustările între etape oferă mai puțin efort de dezvoltare în comparație cu modelul în cascadă.

Totodată, durata de viață a fiecărei etape este prelungită pe toată perioada de lucru, datorită un numar mare iterații, dezacorduri apar în implementarea deciziilor de proiectare și a documentației, este posibil ca în etapa de implementare să apară necesitatea reproiectării întregului sistem.

III. model în spirală , spre deosebire de cascadă, dar similar cu cea anterioară, implică un proces iterativ de dezvoltare a SI. În același timp, crește importanța etapelor inițiale, precum analiza și proiectarea, care verifică și justifică fezabilitatea soluțiilor tehnice prin realizarea de prototipuri.

Fiecare iterație este un ciclu complet de dezvoltare care duce la 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:

Astfel, fiecare tură a spiralei corespunde creării unui fragment sau a unei versiuni a unui produs software, specifică scopurile și caracteristicile proiectului, determină calitatea acestuia și planifică munca la următoarea tură a spiralei. Fiecare iterație servește la aprofundarea și specificarea consecventă a detaliilor proiectului, în urma căruia este selectată o opțiune rezonabilă pentru implementarea finală.

Utilizarea modelului în spirală permite trecerea la următoarea etapă execuția proiectului fără a aștepta finalizarea celui actual - lucrarea neterminată poate fi finalizată la următoarea iterație. Sarcina principală a fiecărei iterații este de a crea un produs funcțional pentru demonstrarea utilizatorilor cât mai repede posibil. Astfel, procesul de introducere a clarificărilor și completărilor în proiect este mult simplificat.

Abordarea spirală a dezvoltării software depășește majoritatea deficiențelor modelului cascadă, în plus, oferă o serie de caracteristici suplimentare, făcând procesul de dezvoltare mai flexibil. Atunci când se utilizează modelul în spirală, este foarte simplificat să se facă modificări în proiect atunci când se modifică cerințele clienților, nivelul riscurilor este redus (nivelul riscurilor este maxim la începutul dezvoltării proiectului, pe măsură ce dezvoltarea progresează, scade), este asigurată o mai mare flexibilitate în managementul proiectelor datorită posibilității de a efectua modificări tactice asupra produsului dezvoltat, capacității de îmbunătățire a procesului de dezvoltare - ca urmare a analizei, la sfârșitul fiecărei iterații, o evaluare a schimbărilor în organizarea dezvoltării Se efectuează; în următoarea iterație, se îmbunătățește, reutilizarea componentelor este simplificată, deoarece este mult mai ușor să identifici (identificarea) părțile comune ale proiectului atunci când acestea sunt deja parțial dezvoltate decât să încerci să le evidențiezi chiar la începutul proiectului. Modelul în spirală vă permite să obțineți un sistem mai fiabil și mai stabil. Acest lucru se datorează faptului că pe măsură ce sistemul evoluează, erorile și punctele slabe sunt găsite și remediate la fiecare iterație. Ajustat în același timp parametri critici eficienta, care in cazul modelului cascada este disponibila doar inainte de implementarea sistemului. Implicarea utilizatorilor în procesul de proiectare și copiere a aplicației vă permite să primiți comentarii și completări la cerințe direct în procesul de proiectare a aplicației, reducând timpul de dezvoltare. Reprezentanții clientului au posibilitatea de a controla procesul de creare a sistemului și de a influența conținutul funcțional al acestuia. Rezultatul este punerea în funcțiune a unui sistem care ține cont de majoritatea nevoilor clienților.

Cu toate acestea, organizarea proiectării circuitelor integrate în funcție de modelul în spirală are de obicei un cost ridicat (prin urmare, este logic să îl folosiți pentru sisteme complexe și costisitoare). Modelul are structura complexa, ceea ce poate face dificilă utilizarea în practică de către specialiști și clienți nepregătiți. Spirala poate continua la nesfârșit, deoarece răspunsul fiecărui client la versiunea creată poate genera un nou ciclu de lucru. Un număr mare de etape intermediare complică întreținerea documentației proiectului. Pot exista dificultăți în determinarea momentului de tranziție la următoarea iterație a buclei. De regulă, limitele de timp sunt impuse pentru execuția iterației și fiecare dintre etapele acesteia.

În unele situații, aplicarea modelului în spirală este imposibilă sau limitată, deoarece nu este posibilă utilizarea/testarea unui produs cu funcționalitate incompletă (de exemplu, dezvoltări militare, energie nucleara etc.). Implementarea iterativă în etape a sistemelor informaționale corporative este de obicei asociată cu dificultăți organizaționale (transfer de date, integrare de sistem, modificări ale proceselor de afaceri, politici contabile, instruire utilizatori). Costurile cu forța de muncă în timpul implementării iterative în faze se dovedesc a fi mult mai mari, iar managementul analfabet al procesului de implementare poate anula toate rezultatele obținute. Din acest motiv, în etapa de implementare, se renunță adesea la modelele iterative, implementând sistemul „o dată pentru totdeauna”.

©2015-2019 site
Toate drepturile aparțin autorilor lor. Acest site nu pretinde autor, dar oferă o utilizare gratuită.
Data creării paginii: 27-04-2016

PRELEZA 10

CICLU DE VIAȚĂ A SISTEMULUI

Modelele ciclului de viață și etapele sale principale

Când descrieți ciclul de viață al unui sistem, sunt utilizate următoarele concepte:

proces - un lanț de lucrări efectuate succesiv;

etape - perioade succesive de timp în care se execută munca . Pe parcursul etapei pot fi efectuate lucrări legate de diferite procese. Baza pentru crearea și utilizarea unui sistem automat de management al întreprinderii (AMS) este conceptul ciclului său de viață (LC). LC este un model pentru crearea și utilizarea sistemelor de control automatizate, reflectând diferitele sale stări, începând din momentul în care apare necesitatea acestui produs și terminând cu momentul în care acesta este complet neutilizat pentru toți utilizatorii fără excepție.

În mod tradițional, se disting următoarele etape principale ale ciclului de viață al sistemelor de control automatizate:

analiza cerințelor;

proiecta;

programare/implementare;

testare și depanare;

operare si intretinere.

Ciclul de viață este format în conformitate cu principiul proiectării de sus în jos și, de regulă, este de natură iterativă: etapele implementate, începând de la cele mai timpurii, se repetă ciclic în funcție de schimbările cerințelor și condițiilor externe, introducerea de restricții etc. La fiecare etapă a ciclului de viață, un anumit set de documente și soluții tehnice, în timp ce pentru fiecare etapă documentele și soluțiile obținute în etapa anterioară sunt cele inițiale. Fiecare etapă se încheie cu verificarea documentelor și soluțiilor generate pentru a verifica conformitatea acestora cu cele originale.

Modelele de ciclu de viață existente determină ordinea de execuție a etapelor în timpul dezvoltării, precum și criteriile de trecere de la o etapă la alta. În conformitate cu aceasta, următoarele trei modele de ciclu de viață sunt cele mai utilizate pe scară largă:

1. Model în cascadă(în anii 70-80) - implică trecerea la etapa următoare după finalizarea lucrărilor din etapa anterioară și se caracterizează printr-o separare clară a datelor și proceselor pentru prelucrarea acestora.

2. Model treptat cu control intermediar(în anii 80-85) - un model de dezvoltare iterativ cu bucle de feedback între etape. Avantajul acestui model este că ajustările între etape necesită mai puțină muncă decât modelul în cascadă; pe de altă parte, durata de viață a fiecărei etape este prelungită pe întreaga perioadă de dezvoltare.

3. Model în spirală(în anii 86-90) - se concentrează pe etapele inițiale ale ciclului de viață: analiza cerințelor, proiectarea caietului de sarcini, proiectarea preliminară și detaliată. În aceste etape se verifică și se justifică fezabilitatea soluțiilor tehnice prin realizarea de prototipuri. Fiecare tură a spiralei corespunde unui model pas cu pas pentru crearea unui fragment sau a unei versiuni a sistemului, pe care sunt specificate obiectivele și caracteristicile proiectului, calitatea acestuia este determinată și munca următoarei ture a sistemului. spirală este planificată. Astfel, detaliile proiectului sunt aprofundate și concretizate în mod consecvent, iar ca urmare, se selectează o opțiune rezonabilă, care este adusă la implementare.

Experții notează următoarele avantaje ale modelului în spirală:

acumularea și reutilizarea instrumentelor software, modelelor și prototipurilor;

orientarea către dezvoltarea și modificarea sistemului în procesul de proiectare a acestuia;

analiza riscurilor și costurilor în procesul de proiectare

. Rețineți că principala caracteristică a industriei CAM este concentrarea complexității pe primele etape Ciclul de viață (analiză, proiectare) cu complexitate relativ scăzută și intensitate de muncă a etapelor ulterioare. În plus, problemele nerezolvate și erorile făcute în timpul fazelor de analiză și proiectare dau naștere la probleme dificile, adesea de nerezolvat în etapele ulterioare și, în cele din urmă, pot priva succesul.

Analiza cerințelor

Analiza cerințelor este prima fază a dezvoltării unui sistem de control automat, în care cerințele clientului sunt specificate, formalizate și documentate. De fapt, în această etapă, se dă un răspuns la întrebarea: „Ce ar trebui să facă viitorul sistem?”. Aici se află cheia succesului întregului proiect. În practica de a crea sisteme mari există multe exemple de implementare nereușită a proiectelor tocmai din cauza caracterului incomplet și vag al definiției cerințelor de sistem.

Lista de cerințe pentru sistemul de control automat ar trebui să includă:

Ansamblul de condiții în care se presupune că va funcționa viitorul sistem (resurse hardware și software furnizate sistemului; condiții externe pentru funcționarea acestuia; componența oamenilor și a muncii legate de acesta);

Descrierea funcțiilor îndeplinite de sistem;

Limitări în procesul de dezvoltare (termene directive pentru finalizarea etapelor individuale, resurse disponibile, proceduri organizatorice și măsuri pentru asigurarea protecției informațiilor).

Scopul analizei este de a transforma cunoștințele comune, neclare despre cerințele pentru viitorul sistem în definiții precise (dacă este posibil). Rezultatul etapei ar trebui să fie un model de cerințe de sistem (cu alte cuvinte, un proiect de sistem) , definind:

Arhitectura sistemului, funcțiile sale, condițiile externe, distribuția funcțiilor între componente hardware și software (FC);

Interfețe și distribuție de funcții între o persoană și un sistem;

Cerințe pentru componentele software și informații ale invertorului , resursele hardware necesare, cerințele bazei de date, caracteristicile fizice ale componentelor unității, interfețele acestora. Modelul de cerințe ar trebui să includă:

Un model funcțional complet al cerințelor pentru viitorul sistem cu un studiu aprofundat la nivelul fiecărei operațiuni a fiecărui funcționar;

Specificațiile operațiunilor de nivel inferior;

Un pachet de rapoarte și documente privind un model funcțional, inclusiv o descriere a obiectului de modelare, o listă de subsisteme, cerințe pentru metode și mijloace de comunicare pentru schimbul de informații între componente, cerințe pentru caracteristicile interconexiunilor sistemului cu sistemele adiacente, cerințe pentru funcțiile sistemului;

Model informativ conceptual al cerințelor;

Un pachet de rapoarte și documente privind modelul informațional;

Arhitectura sistemului cu referire la modelul informatic conceptual;

Sugestii pentru o structură organizatorică care să susțină sistemul.

Astfel, modelul de cerințe conține modele funcționale, informaționale și, eventual, de evenimente (dacă sistemul țintă este un sistem în timp real), oferind o serie de avantaje față de modelul tradițional:

1. Dezvoltarea tradițională se caracterizează prin implementarea etapelor inițiale în moduri artizanale neformalizate. Ca rezultat, clienții și utilizatorii pot vedea sistemul pentru prima dată după ce acesta a fost deja implementat în mare măsură. Desigur, acest sistem va fi diferit de ceea ce se așteptau să vadă. Prin urmare, vor urma mai multe iterații ale dezvoltării sau modificării sale, ceea ce necesită costuri suplimentare (și semnificative) de bani și timp. Cheia pentru rezolvarea acestei probleme este modelul cerințelor, care permite:

Descrieți, „vedeți” și corectați viitorul sistem înainte ca acesta să fie implementat fizic;

Reducerea costurilor de dezvoltare și implementare a sistemului;

Evaluează evoluția în termeni de timp și rezultate;

Realizarea înțelegerii reciproce între toți participanții la lucru (clienți, utilizatori, dezvoltatori, programatori etc.);

Pentru a îmbunătăți calitatea sistemului dezvoltat, și anume, pentru a efectua descompunerea funcțională a acestuia și a proiecta structura optimă a bazei de date integrate.

2. Modelul de cerințe este complet independent și separabil de dezvoltatorii specifici, nu necesită întreținere din partea creatorilor săi și poate fi transferat fără durere altora. Mai mult, dacă dintr-un motiv oarecare întreprinderea nu este pregătită să implementeze sistemul pe baza modelului de cerințe, acesta poate fi pus „pe raft” până când apare necesitatea.

3. Modelul de cerințe poate fi utilizat pentru dezvoltarea sau ajustarea independentă a instrumentelor software deja implementate pe baza acestuia de către programatorii departamentului de automatizare a întreprinderii.

4. Modelul cerințelor poate fi utilizat pentru instruirea automată și rapidă a noilor angajați într-o zonă specifică a întreprinderii, deoarece tehnologia sa este conținută în model.

Etapa de analiză a cerințelor este cea mai importantă dintre toate etapele ciclului de viață. Are un impact semnificativ asupra tuturor etapelor ulterioare, fiind în același timp procesul cel mai puțin studiat și înțeles. În această etapă, în primul rând, este necesar să se înțeleagă ce ar trebui făcut și, în al doilea rând, să se documenteze, deoarece dacă cerințele nu sunt fixate și puse la dispoziția participanților la proiect, atunci acestea nu par să existe. În același timp, limbajul în care sunt formulate cerințele ar trebui să fie destul de simplu și de înțeles de către client.

Pe de altă parte, etapa considerată a ciclului de viață este cea mai dificilă parte a dezvoltării. Următoarele probleme cu care se confruntă un analist de sisteme sunt interdependente (și acesta este unul dintre principalele motive pentru dificultățile lor de rezolvare):

Analistul nu are întotdeauna informații cuprinzătoare pentru a evalua cerințele pentru sistem din punctul de vedere al clientului;

Clientul, la rândul său, nu are suficiente informații despre problema prelucrării datelor pentru a judeca ce este fezabil și ce nu;

Analistul se confruntă cu o cantitate excesivă de informații detaliate atât despre domeniul subiectului, cât și despre sistem nou;

Specificația tradițională (textuală) a sistemului este adesea de neînțeles pentru client din cauza volumului de termeni tehnici;

Dacă o astfel de specificație este înțeleasă de client, aceasta nu va fi suficientă pentru proiectanți și programatori care creează sau adaptează sistemul.

Desigur, utilizarea unor metode analitice binecunoscute înlătură problemele individuale de analiză, dar o soluție acceptabilă la totalitatea acestor probleme poate fi găsită doar prin aplicarea metodelor moderne de inginerie a sistemelor și a software-ului, locul cheie printre care îl ocupă metodologii de analiză structurală și orientată pe obiecte.

Metode structurale de analiză

Analiza structurală se numește de obicei o metodă de studiere a unui sistem, care începe cu o privire de ansamblu asupra acestuia și apoi îl detaliază, dobândind o structură ierarhică cu un număr tot mai mare de niveluri. . Aceste metode se caracterizează prin:

Împărțirea în niveluri de abstractizare cu o limită a numărului de elemente la fiecare nivel (de obicei de la 3 la 7, în timp ce limita superioară corespunde capacității creierului uman de a percepe o anumită cantitate de obiecte interconectate, iar cel de jos a fost ales din motive bun simț);

Context limitat, incluzând doar detalii esențiale la fiecare nivel;

Utilizarea regulilor stricte de înregistrare formală;

Abordare consecventă a rezultatului final.

Metodele de analiză structurală fac posibilă depășirea complexității sistemelor mari prin împărțirea lor în părți („cutii negre”) și organizarea ierarhică a acestor cutii negre. . Avantajul utilizării cutiilor negre este că utilizatorul nu trebuie să știe cum funcționează, ci doar intrările și ieșirile lor și scopul lor (adică funcția pe care o îndeplinesc). În lumea din jurul nostru, se găsesc cutii negre în număr mare: un magnetofon și un televizor la nivel de gospodărie, o întreprindere din punctul de vedere al clientului etc. Să ilustrăm avantajele sistemelor alcătuite din acestea, folosind exemplul unui centru muzical.

Designul sistemului cutie neagră este mult simplificat. Este mult mai ușor să proiectați un magnetofon sau o placă turnantă dacă nu trebuie să vă faceți griji cu privire la construirea unei unități de amplificare încorporate.

Testarea unor astfel de sisteme este facilitată. Dacă auziți un sunet rău de la unul dintre difuzoare, puteți schimba difuzoarele. Dacă defecțiunea s-a mutat cu coloana, atunci ea este cea care trebuie reparată; dacă nu, atunci problema este în amplificator, casetofon sau unde sunt conectate.

Este posibil să reconfigurați cu ușurință sistemul cutie neagră. Dacă difuzorul este defect, îl puteți duce la un atelier de reparații și puteți continua să ascultați înregistrările în modul mono.

Facilitează accesibilitatea pentru înțelegere și stăpânire. Este posibil să devii un specialist în casetofon fără cunoștințe aprofundate despre difuzoare.

Ușurința modificării este îmbunătățită. Mai multe difuzoare pot fi achiziționate Calitate superioarăși un amplificator mai puternic, dar asta nu înseamnă că este nevoie de o placă turnantă mai mare.

Astfel, primul pas în simplificarea unui sistem complex este împărțirea acestuia în cutii negre (principiul „împărți și cuceri” este principiul rezolvării problemelor dificile prin împărțirea lor în multe sarcini independente, care sunt ușor de înțeles și de rezolvat), în timp ce astfel de o diviziune trebuie să îndeplinească următoarele criterii:

Fiecare cutie neagră trebuie să implementeze o singură funcție a sistemului;

Funcția fiecărei cutii negre ar trebui să fie ușor de înțeles, indiferent de complexitatea implementării acesteia (de exemplu, un sistem de control al rachetei poate avea o cutie neagră pentru a-și calcula locul de aterizare: în ciuda complexității algoritmului, funcția cutiei negre este evident - calculul punctului de aterizare);

Comunicarea între cutiile negre trebuie introdusă numai dacă există o conexiune între funcțiile corespunzătoare ale sistemului (de exemplu, în contabilitate, este necesară o cutie neagră pentru a calcula totalul salariile un angajat, iar celălalt - pentru calcularea impozitelor, este necesară o conexiune între aceste cutii negre: ​​valoarea salariului este necesară pentru calcularea impozitelor);

Legăturile dintre cutiile negre ar trebui să fie cât mai simple posibil pentru a asigura independența între ele.

A doua idee importantă din spatele metodelor structurale este ideea de ierarhie. Pentru înțelegerea unui sistem complex, nu este suficient să-l divizăm în părți, este necesară organizarea acestor părți într-un anumit mod, și anume sub formă de structuri ierarhice. Toate sistemele complexe ale Universului sunt organizate în ierarhii. Da, și în sine include galaxii, sisteme stelare, planete, molecule, atomi, particule elementare. Atunci când creează sisteme complexe, o persoană imită și natura. Orice organizație are un director, adjuncți pe zone, o ierarhie de șefi de departament și angajați obișnuiți. Astfel, al doilea principiu al analizei structurale (principiul ordonarii ierarhice), pe langa faptul ca este mai usor de inteles problema daca este sparta in parti, declara ca si aranjarea acestor parti este esentiala pentru intelegere. Comprehensibilitatea unei probleme crește dramatic atunci când părțile sale sunt organizate în structuri ierarhice arborescente, adică sistemul poate fi înțeles și construit pe niveluri, fiecare dintre acestea adăugând noi detalii.

În cele din urmă, al treilea principiu: metodele structurale folosesc pe scară largă notațiile grafice, servind de asemenea la facilitarea înțelegerii sistemelor complexe. Este bine cunoscut faptul că „o imagine valorează cât o mie de cuvinte”.

Respectarea acestor principii este necesară atunci când se organizează lucrul în etapele inițiale ale ciclului de viață, indiferent de tipul de sistem dezvoltat și de metodologiile utilizate. Managementul tuturor principiilor într-un complex permite mai mult primele etape dezvoltare pentru a înțelege cum va fi sistemul creat, pentru a detecta greșelile și neajunsurile, care, la rândul lor, vor facilita munca în etapele ulterioare ale ciclului de viață și vor reduce costurile de dezvoltare.

În scopul analizei structurale, sunt utilizate în mod tradițional trei grupuri de instrumente, ilustrând:

funcțiile pe care sistemul trebuie să le îndeplinească,

relaţiile dintre date

comportamentul dependent de timp al sistemului (aspecte în timp real).

Dintre varietatea de notații grafice utilizate pentru a rezolva problemele de mai sus, următoarele sunt cele mai des și cel mai eficient utilizate în metodologiile de analiză structurală:

DFD(Diagrame de flux de date) - diagrame de flux de date impreuna cu dicționare de date și specificații de proces (mini-specificații);

ERD(Diagrame entitate-relație) - diagrame"esență-conexiune»;

STD(Diagrame de tranziție de stat) - diagrame de tranziție de stare.

DFD clasic arată sursele de date și receptorii (destinațiile) externe sistemului, identifică funcții logice (procese) și grupuri de elemente de date care leagă o funcție de alta (fluxuri) și, de asemenea, identifică depozitele de date (acumulatori) care sunt accesate. Structurile fluxului de date și definițiile componentelor lor sunt stocate și analizate în dicționarul de date. Fiecare funcție logică (proces) poate fi detaliată folosind DFD de nivel inferior; când detaliile suplimentare nu mai sunt utile, se trece la exprimarea logicii funcției folosind o specificație de proces (mini-specificație). Conținutul fiecărui magazin este stocat și într-un dicționar de date, modelul de date al magazinului este expus folosind ERD. În cazul timpului real, DFD este completat prin descrierea comportamentului dependent de timp al sistemului, care sunt dezvăluite folosind STD. Aceste relații sunt prezentate în fig. 20.

Trebuie remarcat faptul că pentru modelarea funcțională, împreună cu DFD, este adesea folosită o altă notație - SADT (mai precis, subsetul său standardizat IDEFO). Analiza comparativa aceste două abordări ale modelării funcțiilor sistemului vor fi prezentate mai jos.

Astfel, instrumentele enumerate mai sus vă permit să faceți Descriere completa sistem, indiferent dacă este existent sau în curs de dezvoltare de la zero. Această descriere detaliată a ceea ce ar trebui să facă sistemul, eliberată cât mai mult posibil de luarea în considerare a căilor de implementare, se numește specificația cerințelor, care oferă proiectantului care implementează următoarea etapă a ciclului de viață o idee clară a rezultatelor finale. de atins.

Notațiile grafice enumerate mai sus sunt folosite (într-un set sau altul) în aproape toate metodologii moderne analiza sistemului structural. Rolul acestor metodologii este de a reglementa bazele dezvoltării sistemelor complexe. Ele descriu succesiunea de pași, modele și

Orez. 20

abordări care, dacă sunt urmate cu atenție, vor duce la sisteme care funcționează bine. Deși, în general, metodologiile nu garantează calitatea sistemelor construite, ele totuși ajută la acoperirea și luarea în considerare a tuturor etapelor, etapelor și momentelor importante de dezvoltare, ajută la rezolvarea problemelor dimensionale și, în cele din urmă, la evaluarea progresului. Mai mult, metodologiile oferă suport organizațional care permite echipelor mari de dezvoltatori să funcționeze într-o manieră coordonată.

Cu alte cuvinte, metodologia de analiză structurală definește liniile directoare pentru construirea și evaluarea modelului de cerințe ale sistemului în curs de dezvoltare, etapele de lucru care trebuie efectuate, succesiunea acestora, precum și regulile de repartizare și repartizare a operațiunilor și metodelor utilizate. in acest.

În prezent, aproape toate metodologiile cunoscute de analiză structurală sunt utilizate cu succes, totuși, cele mai utilizate metodologii sunt SADT (Structured Analysis and Design Technique), analiza sistemului structural Gane-Sarson, analiza și proiectarea structurală Yourdon-DeMarko. ), dezvoltarea de Sistemele Jackson (Jackson), dezvoltarea sistemelor structurale Warne-Orr (Warmer-Orr), analiza și proiectarea sistemelor în timp real Ward-Mellor (Ward-Mellor) și Hatley (Hatley), modelarea informațiilor Martin (Martin).

Metodologiile structurale enumerate reglementează cu strictețe fazele analizei cerințelor și proiectării specificațiilor și reflectă abordarea dezvoltării sistemului din punctul de vedere al rețetelor „carte de bucate”. Specificațiile cerințelor includ caracteristicile sistemului țintă și performanța estimată, designul interfeței cu utilizatorul (meniuri, ecrane și formulare), criteriile de sănătate a sistemului, mediile software și hardware. Documentul rezultat cu specificațiile cerințelor este transformat în continuare în specificații de proiectare care detaliază implementarea intenționată a FC. Specificațiile de proiectare identifică modulele principale, căile de comunicație și control între module, principalele subrutine din cadrul fiecărui modul, structurile de date, specificațiile formatului fișierelor de intrare și ieșire. Pentru procesele cheie, specificațiile de proiectare includ adesea detaliile algoritmilor în limbajul de proiectare cu mini-specificații. În viitor, metodologiile structurale oferă o tehnică de traducere a specificațiilor de proiectare în coduri de program. Generarea codului presupune existența unor standarde de cod care specifică formatul antetelor subrutinei, forma în trepte a blocurilor imbricate, nomenclatura pentru specificarea variabilelor și a numelor subrutinelor etc.

Metodologiile structurale moderne sunt clasificate în funcție de următoarele trei criterii:

DerelațieLascoli - Inginerie software (SE) șiIngineria Informației (IE);

în ordinea construirii modelului - orientat procedural și orientat către informație;

tip sisteme țintă - pentru sisteme în timp real (RTS) și sisteme informaționale (IS).

SE este o disciplină universală pentru dezvoltarea sistemelor software de toate tipurile (IS, RTS). IE este o disciplină de construire a SI în general, și nu doar componentele lor software și include mai multe nivel inalt(de exemplu, planificarea strategică), dar la etapa de analiză a cerințelor pentru partea de software, aceste discipline sunt similare.

Abordarea tradițională orientată pe procedură reglementează primatul proiectării componentelor funcționale în raport cu proiectarea structurilor de date: cerințele de date sunt relevate prin cerințele funcționale. Cu o abordare orientată către informație, intrările și ieșirile sunt cele mai importante - structurile de date sunt definite mai întâi, iar componentele procedurale sunt derivate din cele date.

Principala caracteristică a sistemelor în timp real este că sunt controlate și controlate de evenimente externe; a răspunde în timp la aceste evenimente este funcția principală și primară a unor astfel de sisteme. Diferențele fundamentale dintre sistemele informaționale și sistemele în timp real sunt prezentate în tabel. 2;

masa 2

Prin susținerea acestor caracteristici, metodologiile structurale corespunzătoare diferă. Trebuie remarcat faptul că, în scopul analizării cerințelor pentru sistemele în timp real, se folosesc tipuri speciale de diagrame structurale: diagrame de flux de control, diagrame de tranziție de stare, matrice de stare/eveniment, tabele de decizie etc. Cu toate acestea, multe dintre ele sunt variații. de diagrame structurale pentru analiza cerinţelor pentru sistemele informaţionale. Mai mult, binecunoscutele metodologii pentru analiza și proiectarea RTS (în special, metodologiile lui Hutley și Ward-da-Mellore) se bazează pe metodologiile de mai sus pentru analiza și proiectarea SI, extinzându-le cu tehnici de diagramă adecvate.

În tabel. Tabelul 3 prezintă clasificarea celor mai frecvent utilizate metodologii în conformitate cu caracteristicile de mai sus (date privind frecvența de utilizare au fost obținute pe baza analizei informațiilor pe 127 de pachete CASE).

După cum sa menționat deja, cea mai semnificativă diferență între varietățile de analiză structurală constă în metodele și mijloacele de modelare funcțională. Din acest punct de vedere, toate varietățile de analiză a sistemelor structurale pot fi împărțite în două grupe: cele care utilizează metode și tehnologie DFD (în diverse notații) și cele care utilizează metodologia SADT. Conform materialelor celei mai autorizate companii de cercetare din domeniul luat în considerare, CASE Consulting Group, raportul de utilizare a acestor două tipuri de analiză structurală în practică este de 90% pentru DFD și 10% pentru SADT.

Tabelul 3

anticipând analiza comparativă a abordărilor DFD și SADT , de exemplu, luați în considerare nivelul superior al modelului de cerințe pentru sistemul de automatizare pentru gestionarea unei firme angajate în distribuția de mărfuri pe comenzi (Fig. 21 și, respectiv, Fig. 22). Comenzile sunt supuse controlului și sortării primite. În cazul în care comanda nu corespunde gamei de produse sau este executată incorect, atunci aceasta este anulată cu notificarea corespunzătoare a clientului. Dacă comanda nu este anulată, se stabilește dacă articolul corespunzător este în stoc. În cazul unui răspuns pozitiv, se emite o factură de plată și se prezintă clientului, la primirea plății, marfa este trimisă clientului. În cazul în care comanda nu este furnizată cu stocuri de depozit, atunci o cerere pentru mărfuri este trimisă producătorului. După ce mărfurile necesare ajung la depozitul companiei, comanda devine securizată și repetă traseul descris mai sus.

O analiză comparativă a acestor două tipuri de metodologii se realizează conform următorii parametri:

adecvarea mijloacelor la problema luată în considerare;

coerența cu alte mijloace de analiză structurală;

integrarea cu etapele ulterioare de dezvoltare (și mai ales cu etapa de proiectare).

1) Adecvarea. Alegerea uneia sau alteia metodologii structurale depinde direct de domeniul pentru care este creat modelul. În cazul nostru, metodologiile sunt aplicate sistemelor automate de control al întreprinderii, și nu sistemelor în general, așa cum se presupune în SADT. Pentru problemele luate în considerare, DFD este în afara competiției.

În primul rând, diagramele SADT sunt mult mai puțin expresive și convenabile pentru modelarea sistemelor de control automate (comparați Fig. 21 și Fig. 22). Deci, arcele din SADT sunt tipizate rigid (intrare, ieșire, control, mecanism). În același timp, în raport cu sistemele de control automatizate, diferența semantică dintre intrări și ieșiri, pe de o parte, și comenzi și mecanisme, pe de altă parte, este ștearsă: intrările, ieșirile, mecanismele și controalele sunt fluxuri de date și/ sau controale și regulile de transformare a acestora. Analizarea unui sistem cu fluxuri de date și a proceselor care le transformă este mai transparentă și lipsită de ambiguitate.

sisteme (de exemplu, depozitele de date sunt prototipuri de fișiere sau baze de date, entitățile externe reflectă interacțiunea sistemului simulat cu lumea de afara).

În al doilea rând, în SADT nu există mijloace expresive pentru modelarea caracteristicilor sistemului de control automat. Încă de la început, DFD-urile au fost create ca mijloc de proiectare a sistemelor informaționale care reprezintă nucleul sistemului de control automat și au un set mai bogat de elemente care reflectă în mod adecvat specificul celor de nivelul trei; prezența mini-specificațiilor de procesele DFD de nivel inferior fac posibilă depășirea incompletității logice a SADT de nivel scăzut, când detaliile sale ulterioare devin lipsite de sens) și construirea unei specificații funcționale complete a sistemului dezvoltat.

2) Consecvență. Principalul avantaj al oricăror modele este posibilitatea integrării lor cu modele de alte tipuri. În acest caz, vorbim despre coerența modelelor funcționale cu mijloacele de informare și modelarea evenimentului (temporal). Potrivirea modelului SADT cu ERD și/sau STD este aproape imposibilă sau banală. La rândul lor, DFD, ERD și STD se completează reciproc și sunt în esență reprezentări consistente ale diferitelor aspecte ale aceluiași model (vezi Figura 20). În tabel. 4 arată posibilitatea unei astfel de integrări pentru modelele DFD și SADT.

Tabelul 4

Rețineți că integrarea DFD-STD se realizează prin extinderea DFD-ului clasic cu instrumente speciale pentru proiectarea sistemelor în timp real (procese de control, fluxuri, depozite de date), iar STD este un detaliu al procesului de control, în concordanță cu fluxurile de control și magazine. Integrarea DFD-ERD se realizează folosind un obiect care lipsește în SADT - stocarea datelor, a cărui structură este descrisă folosind ERD și este în concordanță cu fluxurile corespunzătoare și alte stocări de pe DFD.

3) Integrarea cu pașii următori. Caracteristica importanta metodologia - compatibilitatea acesteia cu etapele ulterioare de aplicare a rezultatelor analizei (și, mai ales, cu etapa de proiectare imediat următoare analizei și pe baza rezultatelor acesteia). DFD-urile pot fi ușor convertite în modele de proiectare (hărți structurale) - acestea sunt modele strâns legate. Mai mult, o serie de algoritmi sunt cunoscuți pentru conversia automată a ierarhiei DFD în hărți structurale de diferite tipuri, ceea ce asigură o tranziție logică și nedureroasă de la etapa de analiză a cerințelor la proiectarea sistemului. Pe de altă parte, nu există metode formale cunoscute pentru convertirea diagramelor SADT în soluții de proiectare APCS.

Cu toate acestea, trebuie remarcat faptul că varietățile considerate de analiză structurală sunt în esență două limbi cu aproximativ aceeași putere pentru a transmite înțelegere. Și unul dintre criteriile principale de selecție este următorul: cât de bine vorbește un consultant sau analist fiecare dintre aceste limbi, cât de competent își poate exprima gândurile în această limbă.