Ciclul de viață al sistemelor informaționale. Ciclul de viață al sistemului informațional

Ca un organism viu, fiecare produs (bun sau serviciu) are propriile sale ciclu de viață , care începe din momentul „nașterii” ei (sau, poate, din momentul nașterii unei idei) și se termină cu „moartea”, sau retragerea din uz.

Ciclu de viață EIS – un set de etape prin care parcurge un EIS în dezvoltarea sa din momentul în care se ia o decizie cu privire la crearea lui și până la încetarea funcționării.

Ciclul de viață al economiei Sistem informatic include următorii pași:

1) anteproiect;

2) proiectare logica si tehnica;

3) proiectare de lucru (fizică);

4) implementare;

5) exploatare;

6) retragere.

pre-proiect etapa cuprinde studiul si analiza sistemului de management al companiei, identificarea consumatorilor de informatii existenti. Scopul acestei etape este formarea cerințelor IP care să reflecte corect și cu acuratețe scopurile și obiectivele organizației client. Pentru a specifica procesul de creare a unui IS care să răspundă nevoilor organizației, trebuie să aflați și să articulați clar care sunt aceste nevoi. Pentru a face acest lucru, este necesar să se determine cerințele clienților pentru IS și să le afișeze în limbajul modelelor în cerințele pentru dezvoltarea unui proiect IS, astfel încât să se asigure că viitorul SI îndeplinește scopurile și obiectivele organizației.

Sarcina de a forma cerințe pentru IP este una dintre cele mai responsabile, greu de oficializat și cea mai costisitoare și dificil de corectat în cazul unei erori.

Instrumentele și produsele software moderne vă permit să creați rapid IS în conformitate cu cerințele gata făcute. Dar adesea aceste sisteme nu satisfac clienții, necesită numeroase îmbunătățiri, ceea ce duce la o creștere bruscă a costului real al IS. Motivul principal pentru această prevedere este incorectă, inexactă sau definiție incompletă Cerințele IP în etapa de analiză.

În această etapă, ar trebui rezolvate problemele legate de elaborarea termenilor de referință, a unui plan de acțiune pentru pregătirea unității, inclusiv pregătirea personalului și finanțare. În această etapă, se efectuează și o analiză a fezabilității PI și anume, are în vedere:

fezabilitate operațională - este posibil să se creeze acest IS, cât de convenabil va fi în funcțiune și va îndeplini cerințele specificate;

· fezabilitate economică – cost, eficiență din punctul de vedere al utilizatorului;

Proiecta logic și tehnic este dezvoltarea în conformitate cu cerințele formulate și nevoile de informații identificate ale arhitecturii sistemului și funcționale a EIS.

În etapa de proiectare, în primul rând, se formează modele de date. Designerii primesc rezultatele analizei ca informații inițiale. Construirea modelelor de date logice și fizice este o parte majoră a proiectării bazei de date. Modelul informațional obținut în timpul analizei este mai întâi convertit într-un model de date logic și apoi într-un model de date fizic.

În paralel cu proiectarea schemei bazei de date, se realizează proiectarea proceselor pentru a obține specificații (descrieri) tuturor modulelor IS. Ambele procese de proiectare sunt strâns legate deoarece o parte din logica de afaceri este de obicei implementată în baza de date (constrângeri, declanșatoare, proceduri stocate). Scopul principal al proiectării proceselor este de a mapa funcțiile obținute în etapa de analiză în modulele sistemului informațional. La proiectarea modulelor, sunt definite interfețele programului: aspectul meniului, aspectul ferestrei, tastele rapide și apelurile aferente.

În plus, în faza de proiectare, se realizează și dezvoltarea arhitecturii IS, care include alegerea platformei (platformelor) și a sistemului de operare (sisteme de operare). Într-un IS eterogen, mai multe computere pot funcționa pe platforme hardware diferite și pot rula sisteme de operare diferite.

Pe lângă alegerea unei platforme, în etapa de proiectare se determină tipuri de arhitectură:

arhitectura „file-server” sau „client-server”;

Baza de date este centralizată sau distribuită. Dacă baza de date este distribuită, atunci ce mecanisme vor fi utilizate pentru a menține consistența și relevanța datelor;

· servere, paralele sau unice pentru baze de date (pentru a atinge performanța cerută), etc.

Faza de proiectare se încheie cu dezvoltarea proiect tehnic ESTE.

Proiecta lucrul (fizic) include crearea și configurarea programelor, completarea bazelor de date, crearea instrucțiunilor de lucru pentru personal. Designul se încheie cu crearea unui proiect de lucru.

Un proiect de lucru este o documentație tehnică aprobată în modul prescris, care conține date actualizate și soluții detaliate de proiectare la nivelul întregului sistem, programe și instrucțiuni pentru rezolvarea problemelor, precum și o evaluare actualizată. eficiență economică sistem de control automatizat și o listă actualizată de măsuri pentru pregătirea instalației pentru implementare.

În perioada experimentală și industrială implementare se efectuează o ajustare cuprinzătoare a sistemului și instruirea personalului.

Implementarea sistemului este un proces de trecere treptată de la EIS existent la unul nou, prevăzut de documentația de lucru a proiectului pentru întregul sistem. Introducerea sarcinilor și subsistemelor individuale poate fi efectuată în paralel cu dezvoltarea unui proiect de lucru pentru întregul sistem.

Principalele etape ale implementării sistemului sunt:

pregătirea facilității pentru implementarea sistemului;

livrarea sarcinilor și subsistemelor pentru operare de probă;

efectuarea operațiunii de probă;

livrarea sarcinilor, subsistemelor, a sistemului ca întreg în exploatare comercială.

Operarea de probă a IS constă în verificarea algoritmilor, programelor și legăturilor proces tehnologic prelucrarea datelor in conditii reale. Este pentru următoarele:

depanarea finală a programelor și dezvoltarea procesului tehnologic de rezolvare a problemelor;

Verificarea gradului de pregătire a bazei de informații;

· elaborarea interrelației sarcinilor sistemului;

Dobândirea deprinderilor de muncă de către personalul întreprinderii;

Ajustarea întregului sistem în ansamblu și eliminarea deficiențelor identificate.

După finalizarea operațiunii pilot a sistemului, se întocmește un raport de implementare. Cu rezultate pozitive ale operațiunii de probă, sistemul este pus în funcțiune comercială.

Exploatare EIS - utilizarea sa în condiții reale. În timpul exploatării se efectuează, de asemenea, întreținerea, analiza funcționării sistemului, corectarea erorilor și deficiențelor, înregistrarea cerințelor și elaborarea planurilor de modernizare și extindere a sistemului.

Retragere EIS scos din funcțiune se numește eliminarea completă a EIS din funcționare sau o modernizare semnificativă, ceea ce ne permite să vorbim despre crearea unui sistem informațional fundamental nou.

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 consecință, următoarele trei modele de ciclu de viață sunt cele mai utilizate pe scară largă:

1) un model în cascadă care implică trecerea la următoarea etapă după finalizarea lucrărilor la etapa anterioară;

2) model etapizat cu control intermediar, i.e. model de dezvoltare iterativă cu bucle de feedback între etape. Avantajul acestui model este că ajustările între etape asigură o intensitate mai mică a forței de muncă în comparație cu modelul în cascadă, dar durata de viață a fiecărei etape este prelungită pe întreaga perioadă de dezvoltare;

3) modelul în spirală se concentrează pe etapele inițiale ale ciclului de viață: analiza cerințelor, proiectarea specificațiilor, 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 versiune a unui produs software, pe care sunt specificate obiectivele și caracteristicile proiectului, calitatea acestuia este determinată și munca următoarei ture a spirala 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.

În toate etapele ciclului de viață EIS, specialiștii economici joacă un rol important, care:

formulare cerințe pentru viitorul sistem informațional sau un plan de modernizare a acestuia;

· fundamentarea și calcularea eficienței economice a soluțiilor individuale utilizate ca parte a SI și a sistemului în ansamblu;

· să participe direct la procesul de creare a unui SI, ajutând la modelarea proceselor de afaceri și a proceselor lor informaționale corespunzătoare, inclusiv angajații întreprinderii pentru care se creează un SI, în conformitate cu unul dintre principiile creării unui SI.

Participa la depanarea sistemului în timpul trecerii acestuia în funcțiune;

· (experții) își folosesc cunoștințele și experiența pentru a completa bazele de date și cunoștințele;

· în etapa de implementare, ei elaborează instrucțiuni și formează personalul, punând în aplicare cunoștințele și experiența practică.

Studii recente au arătat că câștigurile de productivitate prin utilizarea tehnologiei informației sunt rareori obținute. Motivul principal prin aceea că noile tehnologii informaționale sunt adesea imagini în oglindă ale metodelor și proceselor anterioare. Această realizare a dus la

apariția unei noi direcții în domeniul managementului - reinginerie procese de afaceri, care se referă la îmbunătățirea sau îmbunătățirea unui proces de afaceri existent prin utilizarea tehnologiei informației cu o regândire fundamentală paralelă și o reorientare radicală a proceselor de afaceri pentru a obține îmbunătățiri dramatice ale indicatorilor importanți (creșterea productivității, îmbunătățirea calității, reducerea costurilor) .

Conceptul de ciclu de viață este unul dintre conceptele de bază ale metodologiei de proiectare a sistemelor informaționale. Ciclul de viață al unui sistem informațional este un proces continuu care începe! din momentul în care se ia decizia de creare a unui sistem informatic şi se încheie în momentul retragerii complete a acestuia din exploatare.

Standardul ISO/IEC 12207 definește un cadru ciclului de viață care conține procesele, activitățile și sarcinile care trebuie efectuate în timpul creării unui sistem informațional. Conform acestui standard, structura ciclului de viață se bazează pe trei grupuri de procese:

1. principalele procese ale ciclului de viață (achiziție, furnizare, dezvoltare, exploatare, întreținere);

2. procese auxiliare care asigură implementarea proceselor principale (documentare, managementul configurației, asigurarea calității, verificarea, atestarea, evaluarea, auditul, rezolvarea problemelor);

3. procese organizatorice (managementul de proiect, crearea infrastructurii proiectului, definirea, evaluarea si imbunatatirea ciclului de viata propriu-zis, instruire).

Dintre principalele procese ale ciclului de viață, dezvoltarea, operarea și întreținerea sunt de cea mai mare importanță. Fiecare proces este caracterizat de anumite sarcini și metode pentru rezolvarea lor, date inițiale; obținute în etapa anterioară și rezultatele.

1. Dezvoltare

Dezvoltarea unui sistem informatic include toate lucrările privind dezvoltarea software-ului informațional și a componentelor acestuia în conformitate cu cerințele specificate. Dezvoltarea software-ului de informare include, de asemenea:

1. înregistrarea documentației de proiectare și exploatare;

2. pregătirea materialelor necesare testării secrete produse software;

3. elaborarea materialelor necesare organizării pregătirii personalului.

Dezvoltarea este unul dintre cele mai importante procese ale ciclului de viață al unui sistem informațional și, de regulă, include planificarea strategică, analiza, proiectarea și implementarea (programarea).

2. Funcționare

Lucrările operaționale pot fi împărțite în pregătitoare și principale. Pregătirile includ:

1. configurarea bazei de date și a stațiilor de lucru ale utilizatorilor;

2. furnizarea utilizatorilor cu documentație operațională;

3. formarea personalului.

Activitățile operaționale majore includ;

1. Operare directă;

2. localizarea problemelor și eliminarea cauzelor acestora;

3. modificare software;

4. pregătirea propunerilor de îmbunătățire a sistemului;

5. dezvoltarea şi modernizarea sistemului.

3. Escortă

Servicii suport tehnic joacă un rol foarte important în viața oricărui sistem de informații corporative. Disponibilitatea întreținerii calificate în stadiul de funcționare a sistemului informațional este o condiție prealabilă pentru rezolvarea sarcinilor care îi sunt atribuite. Mai mult, erorile personalului de întreținere pot duce la pierderi financiare evidente sau ascunse comparabile cu costul sistemului informațional în sine.

Modele de ciclu de viață

Modelul ciclului de viață este înțeles ca o structură care determină succesiunea execuției și relația proceselor, activităților și sarcinilor efectuate de-a lungul ciclului de viață. Modelul ciclului de viață depinde de specificul sistemului informațional și de specificul condițiilor în care acesta din urmă este creat și funcționează.

Până în prezent, cele mai utilizate pe scară largă sunt următoarele modele principale de ciclu de viață:

1. model de sarcină;

2. model în cascadă (sau sistemic) (70-85);

3. model în spirală (prezent).

Model de sarcină

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

Urgență extremă (este necesar ca măcar să fie rezolvate sarcinile cumva; atunci trebuie să faci totul din nou);

Experimentarea și adaptarea clientului (algoritmii nu sunt clari, soluțiile sunt bâjbâite prin încercare și eroare).

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

Model în cascadă

În primele sisteme informatice omogene, nu foarte mari, fiecare aplicație era un singur întreg. Pentru dezvoltarea acestui tip de aplicație a fost utilizată o metodă în cascadă. Caracteristica sa principală este împărțirea întregii dezvoltări în etape, iar trecerea de la o etapă la alta are loc numai după finalizarea completă a lucrării la cea actuală (Fig. 2). Fiecare etapă se termină cu lansarea set complet documentație suficientă pentru ca dezvoltarea să poată fi continuată de o altă echipă de dezvoltare.

Laturi pozitive Aplicațiile abordării în cascadă sunt următoarele:

la fiecare etapă, se formează un set complet de documentație de proiect care îndeplinește criteriile de completitudine și coerență;

etapele de lucru efectuate într-o secvență logică vă permit să planificați momentul finalizării tuturor lucrărilor și costurile corespunzătoare.

Orez. . Schema de dezvoltare a cascadei

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

Orez. 3. Procesul real de dezvoltare software conform schemei în cascadă

Principalul dezavantaj al abordării în cascadă este o întârziere semnificativă în obținerea rezultatelor. Coordonarea rezultatelor cu utilizatorii se realizează numai în punctele planificate după finalizarea fiecărei etape de lucru, cerințele pentru sistemele informaționale sunt „înghețate” sub forma unei sarcini tehnice pe toată durata creării acesteia. Astfel, utilizatorii își pot trimite comentariile numai după ce lucrarea la sistem este complet finalizată. Dacă cerințele nu sunt precizate cu acuratețe sau modificate pe o perioadă lungă de dezvoltare a software-ului, utilizatorii ajung să aibă un sistem care nu le satisface nevoile. Modelele (atât funcționale, cât și informaționale) ale unui obiect automatizat pot deveni învechite simultan cu aprobarea lor. Esența unei abordări sistematice a dezvoltării SI constă în descompunerea (partiționarea) acestuia în funcții automate: sistemul este împărțit în subsisteme funcționale, care la rândul lor sunt împărțite în subfuncții, subdivizate în sarcini și așa mai departe. Procesul de partiţionare continuă până la proceduri specifice. În același timp, sistemul automatizat păstrează o viziune holistică în care toate componentele sunt interconectate. Astfel, acest model are principalul avantaj al dezvoltării sistematice, iar principalele dezavantaje sunt lente și costisitoare.

model în spirală

Pentru a depăși aceste probleme, a fost propus un model de ciclu de viață în spirală (Fig. 4), care se concentrează pe etapele inițiale ale ciclului de viață: analiză și proiectare. În aceste etape, fezabilitatea soluțiilor tehnice este testată prin realizarea de prototipuri. Fiecare tură a spiralei corespunde creării unei piese sau a unei versiuni a software-ului, pe care sunt specificate obiectivele și caracteristicile proiectului, este determinată calitatea acestuia și este planificată activitatea următoarei ture a spiralei. Astfel, detaliile proiectului sunt aprofundate și concretizate în mod consecvent, iar ca urmare, se selectează o opțiune rezonabilă, care este adusă la implementare.

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

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

Figura 4. Modelul spiralat al ciclului de viață al IS

Una dintre posibilele abordări ale dezvoltării software în cadrul modelului ciclului de viață în spirală este timpuri recente Metodologie larg răspândită pentru dezvoltarea rapidă a aplicațiilor RAD (Rapid Application Development). Acest termen este de obicei înțeles ca un proces de dezvoltare software care conține 3 elemente:

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

scurt dar bine lucrat program de productie(de la 2 la 6 luni);

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

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

1. faza definirii si analizei cerintelor;

2. faza de proiectare;

3. faza de implementare;

4. faza de implementare.

Curs 6. Clasificarea sistemelor informatice

Sistem informatic- un set interconectat de mijloace, metode și personal utilizate pentru stocarea, procesarea și emiterea de informații în interesul atingerii scopului

Clasificare la scară

După scară, sistemele informaționale sunt împărțite în următoarele grupe:

1. singur;

2. grup;

3. corporative.

Sisteme informatice unice implementat de obicei pe un sistem autonom calculator personal(rețeaua nu este utilizată). Un astfel de sistem poate conține mai multe aplicații simple conectate printr-un fond comun de informații și este conceput pentru funcționarea unui utilizator sau a unui grup de utilizatori care împart un loc de muncă în timp. Astfel de aplicații pot fi create folosind așa-numitele sisteme de gestionare a bazelor de date desktop sau locale (DBMS). Dintre DBMS-urile locale, cele mai cunoscute sunt Clarion, Clipper, FoxPro, Paradox, dBase și Microsoft Access.

Sisteme informatice de grup sunt concentrate pe utilizarea colectivă a informațiilor de către membrii grupului de lucru și sunt construite cel mai adesea pe baza unei rețele locale. Aceste aplicații sunt dezvoltate folosind servere de baze de date (numite și servere SQL) pentru grupuri de lucru. Există un număr destul de mare de servere SQL diferite, atât comerciale, cât și distribuite gratuit. Dintre acestea, cele mai cunoscute servere de baze de date sunt Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.

Sisteme informatice corporative sunt o evoluție a sistemelor pentru grupuri de lucru, sunt concentrate pe companii mari și pot suporta noduri sau rețele dispersate geografic. Practic, au o structură ierarhică de mai multe niveluri. Astfel de sisteme se caracterizează printr-o arhitectură client-server cu specializarea serverelor sau o arhitectură pe mai multe niveluri. La dezvoltarea unor astfel de sisteme, pot fi utilizate aceleași servere de baze de date ca și la dezvoltarea sistemelor de informații de grup. Cu toate acestea, în sistemele informatice mari, cele mai utilizate servere sunt Oracle, DB2 și Microsoft SQL Server.

Pentru sistemele de grup și corporative, cerințele pentru fiabilitatea funcționării și siguranța datelor sunt semnificativ crescute. Aceste proprietăți sunt furnizate prin menținerea integrității datelor, legăturilor și tranzacțiilor în serverele de baze de date.

Clasificarea după domeniu

În funcție de domeniul de aplicare al sistemelor informaționale sunt de obicei împărțite în patru grupuri:

1. sisteme de procesare a tranzacțiilor;

2. sisteme decizionale;

3. sisteme informatice si de referinta;

4. sisteme informatice de birou.

Sisteme de procesare a tranzacțiilor, la rândul lor, în funcție de eficiența prelucrării datelor, se împart în sisteme informaționale pe lot și sisteme informaționale operaționale. În sistemele informaționale de management organizațional predomină modul de prelucrare operațională a tranzacțiilor, pentru a reflecta la zi starea subiectului în orice moment, iar procesarea lotului ocupă o parte foarte limitată.

Sisteme de sprijinire a deciziei - DSS (Decision Support Systeq) - sunt un alt tip de sisteme informatice în care, cu ajutorul unor interogări destul de complexe, datele sunt selectate și analizate în diverse secțiuni: indicatori temporali, geografici și de altă natură.

Clasa extinsa sisteme informatice si de referinta bazată pe documente hipertext și multimedia. Astfel de sisteme informatice au primit cea mai mare dezvoltare pe Internet.

Clasă sisteme informatice de birou are ca scop transformarea documentelor pe hârtie în formă electronică, automatizarea de birou și managementul documentelor.

Clasificarea după organizare

Conform metodei de organizare, sistemele informaționale de grup și corporative sunt împărțite în următoarele clase:

1. sisteme bazate pe arhitectura file-server;

2. sisteme bazate pe arhitectura client-server;

3. sisteme bazate pe o arhitectură pe mai multe niveluri;

4. sisteme bazate pe tehnologii Internet/Intranet.

În orice sistem informațional, este posibil să se identifice componentele funcționale necesare care ajută la înțelegerea limitărilor diferitelor arhitecturi ale sistemelor informaționale.

Arhitectura serverului de fișiere extrage doar date din fișiere, astfel încât utilizatorii și aplicațiile suplimentare să adauge doar o încărcare minoră pe CPU. Fiecare client nou adaugă putere de procesare rețelei.

Arhitectura client-server este conceput pentru a rezolva problemele aplicațiilor server de fișiere prin separarea componentelor aplicației și plasarea lor acolo unde vor funcționa cel mai eficient. O caracteristică a arhitecturii client-server este utilizarea serverelor de baze de date dedicate care înțeleg interogările în limbajul de interogare structurat (SQL) și efectuează căutări, sortare și agregare a informațiilor.

În prezent, arhitectura client-server a fost recunoscută și utilizată pe scară largă ca o modalitate de organizare a aplicațiilor pentru grupuri de lucru și sisteme informaționale la nivel de întreprindere. Această organizare a muncii crește eficiența execuției aplicației prin utilizarea capacităților serverului de baze de date, descărcarea rețelei și asigurarea controlului integrității datelor.

Arhitectură stratificată a devenit dezvoltarea arhitecturii client-server și în forma sa clasică constă din trei niveluri:

1. Stratul inferior sunt aplicațiile client care au o interfață de programare pentru a apela aplicația din stratul mijlociu;

2. nivel mediu este un server de aplicații;

3. Nivelul superior este un server de baze de date specializat la distanță.

Arhitectura pe trei niveluri echilibrează și mai mult sarcina pe diferite gazde și rețele, promovează specializarea instrumentelor de dezvoltare a aplicațiilor și elimină deficiențele modelului client-server pe două niveluri.

În dezvoltare tehnologii Internet/intranet accentul principal se pune până acum pe dezvoltarea de instrumente software. În același timp, există o lipsă de instrumente dezvoltate pentru dezvoltarea aplicațiilor care funcționează cu baze de date. O soluție de compromis pentru crearea unor sisteme informaționale convenabile și ușor de utilizat și de întreținut care funcționează eficient cu bazele de date a fost combinația dintre tehnologia Internet / Intranet cu o arhitectură pe mai multe niveluri. În acest caz, structura aplicației de informații ia următoarea formă: browser - server de aplicații - server de baze de date - server de pagini dinamice - server web.

În funcție de natura informațiilor stocate, bazele de date sunt împărțite în fapticeși documentare. Dacă facem o analogie cu exemplele de depozite de informații descrise mai sus, atunci bazele de date factografice sunt dulapuri de fișiere, iar bazele de date documentare sunt arhive. Stocarea bazelor de date faptice informatii scurteîntr-un format strict definit. Bazele de date documentare conțin tot felul de documente. Și poate fi nu numai documente text dar și grafică, video și sunet (multimedia).

Sistemul de control automat (ACS) este un set de hardware și software, împreună cu structuri organizatorice(persoane individuale sau o echipă), asigurarea managementului unui obiect (complex) într-un mediu industrial, științific sau social.

Alocați sisteme informatice de management al educației (De exemplu, programe de personal, solicitant, student, bibliotecă). Sisteme automatizate pt cercetare științifică(ASNI), care sunt sisteme software și hardware care prelucrează date din diferite tipuri de configurații experimentale și instrumente de măsurare și, pe baza analizei acestora, facilitează detectarea de noi efecte și modele.Sisteme de proiectare asistată de computer și sisteme de informații geografice.

Un sistem de inteligență artificială construit pe baza cunoștințelor speciale de înaltă calitate despre un anumit domeniu (obținut de la experți - specialiști în acest domeniu) se numește sistem expert. Sistemele experte - unul dintre puținele tipuri de sisteme de inteligență artificială - sunt utilizate și găsite pe scară largă uz practic. Există sisteme expert pentru afaceri militare, geologie, inginerie, informatică, tehnologie spațială, matematică, medicină, meteorologie, industrie, agricultură, management, fizică, chimie, electronică, drept etc. Și doar faptul că sistemele expert rămân programe foarte complexe, costisitoare și, cel mai important, foarte specializate, împiedică distribuția lor și mai largă.

Sistemele experte (ES) sunt programe de calculator, creat pentru a efectua acele tipuri de activități care sunt în puterea unui expert uman. Ele funcționează într-un mod care imită comportamentul unui expert uman și diferă semnificativ de algoritmii precisi și bine motivați și nu seamănă cu procedurile matematice ale majorității dezvoltărilor tradiționale.

Din programa de lucru:

Tema 2. Standarde și ghiduri normative pentru ingineria sistemelor și software-ului.

ISO/IEC 15288 „Ingineria sistemelor - Procese ale ciclului de viață al sistemelor”.

GOST 34: Un set de standarde pentru sisteme automate.

Idei cheie ale ingineriei sistemelor: abordarea sistemelor, ciclul de viață al sistemului, ingineria cerințelor, proiectarea arhitecturală, abordare procesuala, abordare de proiectare.

2.1. ISO 15288 „Ingineria sistemelor – Procese ale ciclului de viață a sistemelor”.

2.2. Ciclul de viață al sistemului.

2.3. Vizualizări ale ciclului de viață ale sistemului.

2.4. Ciclul de viață al sistemului informațional

2.5. Modele de ciclu de viață

2.6. Alegerea unui model de ciclu de viață

2.1. ISO 15288 „Ingineria sistemelor – procese ciclului de viață a sistemelor”.

Ingineria sistemelor este aplicată pentru a rezolva problemele asociate cu complexitatea tot mai mare a sistemelor create de om. Standardul ISO 15288, care descrie metodele de inginerie a sistemelor, prevede o descriere a ciclului de viață a sistemului și a practicilor acestuia. O astfel de descriere este necesară pentru progresul cu succes al sistemului de-a lungul ciclului de viață. Dar standardul nu indică metodele prin care trebuie creată o astfel de descriere.

Obiectivele standardului:

Pentru a permite organizațiilor (antreprenori interni și externi) să convină asupra combinației de idei, procese pentru proiectarea, construirea, operarea și dezafectarea unei game largi de sisteme create de om - de la scobitori la centrale nucleare, de la sisteme de standardizare la corporații

Implementați o serie de idei cheie ale ingineriei sistemelor în practica organizației:

• abordarea sistemelor

  ciclu de viață

  ingineria cerinţelor

  design arhitectural

  abordarea procesuala

  abordarea proiectului

  cultura contractării

Estetoriyacreare

Dezvoltarea în comun a ISO și IEC, participarea activă a INCOSE

Începutul lucrărilor în 1996, versiuni în 2002, 2005 (GOST R ISO / IEC 15288-2005), 2008

Conceput pentru a armoniza așa-numita „mlaștină de standarde” a ingineriei sistemelor (numeroase standarde adoptate de diferite departamente militare, state, organizații de standarde industriale)

În elaborarea standardului au fost implicați experți din diverse domenii: ingineria sistemelor, programare, managementul calității, resurse umane, securitate etc. S-a luat în considerare experiența practică în crearea de sisteme în organizații guvernamentale, comerciale, militare și academice. Standardul este aplicabil unei clase largi de sisteme, dar scopul său principal este de a sprijini crearea de sisteme computerizate.

2.2. Ciclul de viață al sistemului

abreviere rusă: J C

abreviere în engleză: LC (viaţăciclu)

Rusă: "ciclu de viață". Ciclul de viață englezesc în tehnologie obișnuia să însemne și să se traducă ca „durată de viață” și uneori chiar „durată de viață până la prima revizie majoră”. „Life Cycle” este o traducere relativ nouă. Uneori, „ciclu” este tradus ca „perioadă”, dar o astfel de traducere nu s-a stabilit (deși este mai precisă în acest caz: „perioada de viață” a sistemului). Cuvântul „ciclu” nu trebuie să confunde - nu există nimic ciclic în ciclul de viață. Cuvântul „ciclu” are sensul de „tipic”, adică același lucru se întâmplă cu alte sisteme.

Formal: ciclul de viață este o schimbare a stărilor sistemului (evoluția sistemului) în perioada de timp de la concepție până la încetarea existenței acestuia.

Sistemul și ciclul de viață sunt frați gemeni. Spunem sistem - ne referim la ciclul de viață, spunem ciclul de viață - ne referim la sistem.

Definiții.

Definiția ISO/IEC 15288:2008 (Definiție: ciclu de viață -- evoluția unui sistem, produs, serviciu, proiect sau alte entități create de om de la concepție până la retragere (ISO 15288, 4.11):

ciclu de viață (Cicul de viață) este evoluția unui sistem, produs, serviciu, proiect sau alt obiect creat de om de la concepție până la întrerupere.

Definirea standardului ISO 15704 (Sisteme de automatizare industriale - Cerințe pentru arhitecturi și metodologii de referință pentru întreprinderi

ciclu de viață (LC) este un set finit de faze și etape principale prin care trece sistemul de-a lungul istoriei existenței.

Fiecare sistem, indiferent de tipul și scara sa, parcurge întregul său ciclu de viață conform unei descrieri. Progresul sistemului prin părți din această descriere este ciclul de viață al sistemului. Descrierea ciclului de viață este astfel - aceasta este o segmentare conceptuală pe etape facilitând planificarea, implementarea, operarea și sprijinul sistemului țintă.

Etapele (Tabelul 2.1) reprezintă cele mai mari perioade ale ciclului de viață asociat unui sistem și corespund stărilor descrierii sistemului sau implementării sistemului ca ansamblu de produse sau servicii. Etapele descriu principalele etape ale progresului și succesului sistemului pe parcursul ciclului de viață. Astfel de segmente permit sistemului să progreseze într-o manieră ordonată prin revizuiri stabilite de alocare a resurselor, ceea ce reduce riscurile și asigură un progres satisfăcător. Motivul principal pentru utilizarea descrierilor ciclului de viață este necesitatea de a lua decizii cu privire la anumite criterii înainte de a trece sistemul la etapa următoare.

Tabelul 2.1

Etapele dezvoltării sistemului (ISO/IEC 15288)
№ n/n	Etapă	Descriere
	Formarea conceptului	Analiza nevoilor, alegerea conceptului și a designului
	Dezvoltare	Proiectarea sistemului
	Implementarea	Fabricarea sistemului
	Exploatare	Punerea în funcțiune și utilizarea sistemului
	A sustine	Asigurarea functionarii sistemului
	Dezafectarea	Incetarea utilizarii, dezmembrarea, arhivarea sistemului

ciclu (LC).

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;
     • executarea si aprobarea proiectului tehnic (TP).
   • 2.2. Design detaliat:
     • selectarea sau dezvoltarea de metode matematice sau algoritmi de program;
     • ajustarea structurilor bazei de date;
     • crearea documentației pentru livrarea și instalarea produselor 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 si 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.

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 APCS este concentrarea complexității în etapele inițiale ale ciclului de viață (analiza, proiectare) cu complexitate relativ scăzută și intensitatea muncii din etapele 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 neclar al definiției Cerințe 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 detalii atât despre domeniul subiectului, cât și despre noul sistem;

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ă este de obicei numită o metodă de studiere a unui sistem, care începe cu Prezentare generală acesta și apoi se detaliază, dobândind o structură ierarhică cu un număr tot mai mare de niveluri . Aceste metode se caracterizează prin:

Spargerea în niveluri de abstractizare cu o limită a numărului de elemente la fiecare dintre niveluri (de obicei de la 3 la 7, în timp ce limita superioară corespunde capacităților creierului uman de a percepe un anumit număr de obiecte interconectate, iar limita inferioară este ales din motive de 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ă. Puteți obține difuzoare mai bune și un amplificator mai puternic, dar asta nu înseamnă că aveți 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 ar trebui introdusă numai dacă există o conexiune între funcțiile corespunzătoare ale sistemului (de exemplu, în contabilitate, o cutie neagră este necesară pentru a calcula salariul total al unui angajat, iar cealaltă este necesară pentru a calcula impozitele, este necesară o legătură între aceste cutii negre: valoarea salariilor 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. douăzeci.

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). O analiză comparativă a acestor două abordări pentru modelarea funcțiilor sistemului va fi prezentată 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 metodologiile moderne de analiză a sistemelor structurale. Rolul acestor metodologii este de a reglementa bazele dezvoltării sistemelor complexe. Ele descriu succesiunea de pași, modele și

Orez. douăzeci

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:

perelaț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 software ale acestora, și include etape de nivel superior (de exemplu, planificarea strategică), cu toate acestea, în etapa de analiză a cerințelor pentru partea 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

Metodologii	Frecvența de utilizare	Şcoală	Comanda de constructie	Tipul sistemelor țintă
Jodan De Marco			orientat procedural
Gein-Sarson			orientat procedural
Constantin			orientat procedural
			orientat spre informare
Warnier-Orr			orientat spre informare
			orientat spre informare
			orientat procedural

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 modelat cu lumea exterioară).

Î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

Nume			Hărți structurale

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, sunt cunoscuți o serie de algoritmi pentru transformarea automată a ierarhiei DFD în hărți structurale. diferite feluri, care oferă o tranziție logică și nedureroasă de la analiza 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ă.