• Ce poți găti din calmar: rapid și gustos

    Descrierea prezentării Etapele creării unui model de ciclu de viață AIS AIS pe diapozitive

    Ciclul de viață al unui AIS este un set de etape prin care parcurge un AIS în dezvoltarea sa din momentul în care se ia decizia de a crea un sistem și până în momentul în care acesta încetează să funcționeze.

    Etape ciclu de viață 1 Planificare și analiză (etapa de pre-proiectare) - determinarea a ceea ce ar trebui să facă sistemul. Întocmirea unui studiu de fezabilitate (TES) și a specificațiilor tehnice (TOR).

    2 Proiectare (proiectare tehnică și logică) - determinarea modului în care va funcționa sistemul (specificarea* subsistemelor, componentelor funcționale și modalităților de interacțiune a acestora). Înregistrare proiect tehnic. * Specificație - o descriere precisă, completă și clar formulată a cerințelor pentru o anumită sarcină.

    3. Implementare (proiectare detaliată, programare) - Crearea componentelor funcționale și a subsistemelor individuale, conectarea subsistemelor într-un singur întreg. Completarea bazei de date. Crearea de instrucțiuni pentru personal. Înregistrarea unui proiect de lucru

    4 Implementare (testare, operațiune de probă) – instalarea și punerea în funcțiune a sistemului, depanarea subsistemelor, instruirea personalului. Întocmirea unui raport de testare de recepție.

    Note 1. Etapele 2 și 3 pot fi combinate într-una singură: proiectare tehnică de lucru sau sinteza sistemului. 2. În fiecare etapă a ciclului de viață se utilizează un anumit set de soluții tehnice și documente relevante

    3. Pentru fiecare etapă, documentele și deciziile luate la etapa precedentă constituie punctele de plecare. 4. Modelele ciclului de viață determină ordinea de execuție a etapelor în procesul de creare a unui sistem și criteriile de trecere de la etapă la etapă.

    Un model de ciclu de viață este un model pentru crearea și utilizarea unui AIS, care reflectă diferitele stări ale sistemului din momentul înființării sale până în momentul în care acesta ieșire completă scos din uz.

    Modele de bază ale ciclului de viață Cascada - implică trecerea la următoarea etapă după finalizarea completă a lucrărilor anterioare. Acest model este utilizat în construcția sistemelor informatice automatizate pentru care toate cerințele sunt formulate precis și complet încă de la început. Dezavantaje: schema rigida - imposibilitatea revenirii la etapele anterioare si utilizare pentru sisteme complexe.

    Model iterativ pas cu pas Presupune prezența feedback-ului între cicluri. Avantajul este că ajustările între etape oferă o mai mare flexibilitate și mai puțin efort. Dezavantajul este că durata de viață a fiecărei etape se poate extinde pe întreaga perioadă de creare a sistemului Dificultăți și dezavantaje ale modelului ciclului de viață în spirală Principala problemă este determinarea tranziției la următoarea etapă: pentru a rezolva aceasta, se introduc restricții de timp pentru fiecare. a etapelor. Tranziția se realizează în conformitate cu un plan întocmit pe baza datelor statistice din proiectele anterioare și a experienței dezvoltatorilor. Dezavantaje: Greșelile făcute în timpul etapelor de analiză și proiectare pot duce la probleme în etapele ulterioare și eșecul întregului proiect.

    Rolul de utilizator AIS este creat pentru a satisface nevoile de informații ale unui anumit utilizator. El este implicat direct în activitatea sa. .

    Utilizatorul participă la formularea problemei și efectuează operațiuni de probă, în timpul căreia poate detecta deficiențe în formulare, poate ajusta informațiile de intrare și de ieșire, formulare pentru emiterea rezultatelor și documente.

    Participarea utilizatorilor la crearea sistemelor informatice automatizate asigură soluții prompte și de înaltă calitate la probleme și reduce timpul de introducere a noilor tehnologii.

    Abordarea în cascadă s-a dovedit bine în construcția sistemelor informaționale, pentru care chiar la începutul dezvoltării este posibil să se formuleze toate cerințele destul de precis și complet pentru a oferi dezvoltatorilor libertatea de a le implementa tehnic cât mai bine posibil. . Această categorie include sisteme complexe cu un număr mare de sarcini de calcul, sisteme în timp real etc.

    Modelul ciclului de viață AIS este o structură care descrie procesele, acțiunile ș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.

    Modelul ciclului de viață AIS include:

    Rezultatele muncii în fiecare etapă;

    Evenimente cheie sau puncte de finalizare a lucrărilor și luarea deciziilor.

    În conformitate cu modelele de ciclu de viață cunoscute, software-ul determină modelele de ciclu de viață AIS - cascadă, iterativă, spirală.

    I. Model în cascadă descrie abordarea clasică a dezvoltării sistemelor în orice domeniu; 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.

    Evidențiați cinci etape de dezvoltare durabilă, practic independente de domeniul de studiu

    Pe primulÎn această etapă, se efectuează un studiu al zonei cu probleme și se formulează cerințele clientului. Rezultatul acestei etape este termeni de referință(sarcina de dezvoltare), convenită cu toate părțile interesate.

    În timpul doilea etapa, conform cerintelor caietului de sarcini, sunt dezvoltate anumite solutii de proiectare. Rezultatul este un set documentatia proiectului.

    Treilea etapa - implementarea proiectului; în esenţă dezvoltare software(codificare) în conformitate cu soluțiile de proiectare ale etapei precedente. Metodele de implementare nu au o importanță fundamentală în acest caz. Rezultatul acestei etape este un produs software finit.

    Pe patruleaÎn această etapă, software-ul rezultat este verificat pentru conformitatea cu cerințele prevăzute în specificațiile tehnice. Funcționarea de probă face posibilă identificarea diferitelor tipuri de deficiențe ascunse care apar în condițiile reale de funcționare ale AIS.

    Ultima etapă este livrarea proiectului finit, iar principalul lucru aici este să convingi clientul că toate cerințele sale sunt pe deplin îndeplinite.

    Fig. 1.1 Modelul în cascadă al ciclului de viață AIS



    Etapele de lucru din cadrul modelului cascadă sunt adesea numite părți ale ciclului proiectului AIS, deoarece etapele constau în multe proceduri iterative pentru clarificarea cerințelor sistemului și a opțiunilor de soluție de proiectare. Ciclul de viață al unui AIS este semnificativ mai complex și mai lung: poate include un număr arbitrar de cicluri de clarificare, modificări și completări la deciziile de proiectare deja adoptate și implementate. În aceste cicluri, AIS este dezvoltat și componentele sale individuale sunt modernizate.

    Avantajele modelului în cascadă:

    1) la fiecare etapă, se generează un set complet de documentație de proiectare 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.);

    2) implementarea secvențială a etapelor de lucru vă permite să planificați datele de finalizare și costurile corespunzătoare.

    Modelul în cascadă a fost dezvoltat inițial pentru a rezolva diferite tipuri de probleme de inginerie și nu și-a pierdut importanța pentru domeniul aplicat până în prezent. În plus, abordarea cascadă este ideală pentru dezvoltarea AIS, deoarece chiar la începutul dezvoltării este posibil să se formuleze destul de precis și complet toate cerințele pentru a oferi dezvoltatorilor libertatea de implementare tehnică. Astfel de AIS, în special, includ sisteme complexe de calcul și sisteme în timp real.

    Dezavantajele modelului în cascadă:

    Întârziere semnificativă în obținerea rezultatelor;

    Erorile și deficiențele în orice etapă apar, de regulă, în etapele ulterioare de lucru, ceea ce duce la necesitatea unei retururi;

    Dificultatea lucrului paralel la proiect;

    Suprasaturarea excesivă de informații a fiecărei etape;

    Complexitatea managementului de proiect;

    Nivel înalt riscul și nefiabilitatea investițiilor.

    Întârziere în primirea rezultatelor se manifestă prin faptul că o abordare consecventă a rezultatelor dezvoltării sunt convenite cu părțile interesate numai după finalizarea următoarei etape de lucru. Ca urmare, se poate dovedi că AIS în curs de dezvoltare nu îndeplinește cerințele și astfel de inconsecvențe pot apărea în orice stadiu de dezvoltare; în plus, erorile pot fi introduse neintenționat atât de către designeri-analiști, cât și de către programatori, deoarece nu li se cere să aibă o bună înțelegere a domeniilor pentru care este dezvoltat AIS.

    Reveniți la etapele anterioare. Acest dezavantaj este o manifestare a celui precedent: lucrul secvenţial pas cu pas asupra unui proiect poate duce la faptul că erorile făcute în etapele anterioare sunt descoperite doar în etapele ulterioare. Drept urmare, proiectul este revenit la etapa anterioară, reluat și abia apoi transferat la lucrările ulterioare. Acest lucru poate cauza întreruperi de program și poate complica relațiile dintre echipele de dezvoltare care efectuează etapele individuale.

    Cea mai proastă opțiune este atunci când deficiențele etapei anterioare sunt descoperite nu în etapa următoare, ci mai târziu. De exemplu, în etapa de operare de probă, pot apărea erori în descrierea domeniului subiectului. Aceasta înseamnă că o parte din proiect trebuie să fie readusă la stadiul inițial de lucru.

    Dificultate în munca paralelă este asociată cu necesitatea de a coordona diferite părți ale proiectului. Cu cât este mai puternică interconectarea părților individuale ale proiectului, cu atât mai des și mai atent trebuie efectuată sincronizarea, cu atât echipele de dezvoltare sunt mai dependente unele de altele. Ca urmare, avantajele muncii paralele se pierd pur și simplu; Lipsa paralelismului afectează negativ și organizarea muncii a întregii echipe.

    Problemă suprasaturarea informatiei apare din cauza dependențelor puternice dintre diferitele grupuri de dezvoltare. Faptul este că atunci când se fac modificări la una dintre părțile proiectului, este necesar să se anunțe acei dezvoltatori care l-au folosit (ar putea folosi) în munca lor. Când există un număr mare de subsisteme interconectate, sincronizarea documentației interne devine o sarcină critică separată: dezvoltatorii trebuie să se familiarizeze constant cu modificările și să evalueze modul în care aceste modificări vor afecta rezultatele obținute.

    Complexitatea managementului de proiect se datorează în principal secvenței stricte a etapelor de dezvoltare și prezenței unor relații complexe între diferitele părți ale proiectului. Secvența reglementată de lucru duce la faptul că unele grupuri de dezvoltare trebuie să aștepte rezultatele muncii altor echipe, astfel încât este necesară intervenția administrativă pentru a conveni asupra calendarului și componenței documentației transferate.

    Dacă în lucrare sunt detectate erori, este necesar să revenim la etapele anterioare; munca curentă a celor care au greșit este întreruptă. Consecința acestui lucru este de obicei un termen limită ratat atât pentru proiectele reparate, cât și pentru cele noi.

    Este posibil să se simplifice interacțiunea dintre dezvoltatori și să se reducă suprasaturarea de informații a documentației prin reducerea numărului de conexiuni între părțile individuale ale proiectului, dar nu fiecare AIS poate fi împărțit în subsisteme slab conectate.

    Nivel ridicat de risc. Cu cât proiectul este mai complex, cu atât durează mai mult fiecare etapă de dezvoltare și cu atât relațiile dintre părțile individuale ale proiectului sunt mai complexe, numărul cărora crește și el. În plus, rezultatele dezvoltării pot fi văzute și evaluate cu adevărat numai în etapa de testare, adică după finalizarea analizei, proiectării și dezvoltării - etape a căror implementare necesită timp și bani semnificativi.

    Evaluarea tardivă creează probleme serioase în identificarea erorilor de analiză și proiectare - este necesară revenirea la etapele anterioare și repetarea procesului de dezvoltare. Cu toate acestea, revenirea la etapele anterioare poate fi asociată nu numai cu erori, ci și cu schimbări care au avut loc în domeniul subiectului sau în cerințele clienților în timpul dezvoltării. În același timp, nimeni nu garantează că subiectul nu se va schimba din nou până când următoarea versiune a proiectului este gata. De fapt, aceasta înseamnă că există posibilitatea unei „ciclări” a procesului de dezvoltare: costurile proiectului vor crește constant, iar data de livrare a produsului finit va fi întârziată în mod constant.

    II. Model iterativ (Model treptat cu control intermediar) constă dintr-o serie de cicluri (pași) scurte de planificare, implementare, studiu, acțiune.

    Crearea de sisteme informatice automatizate complexe presupune aprobarea solutiilor de proiectare obtinute in timpul implementarii sarcinilor individuale. Abordarea „de jos în sus” a proiectării necesită astfel de iterații ale returnărilor, atunci când soluțiile de proiectare pentru sarcini individuale sunt combinate în cele generale de sistem. În același timp, este necesar să se revizuiască cerințele formate anterior.

    Avantaj Modelul iterativ este că ajustările între etape asigură o intensitate mai mică a muncii de dezvoltare în comparație cu modelul în cascadă.

    Defecte model de iterație:

    · durata de viață a fiecărei etape se extinde pe întreaga perioadă de lucru;

    · din cauza unui număr mare de iterații, apar discrepanțe în implementarea deciziilor de proiectare și a documentației;

    · complexitatea arhitecturii;

    · dificultățile în utilizarea documentației de proiectare în etapele de implementare și exploatare necesită reproiectarea întregului sistem.

    III. Model în spirală, spre deosebire de cel în cascadă, dar similar celui precedent, presupune un proces iterativ de dezvoltare a unui AIS. În același timp, crește importanța etapelor inițiale, precum analiza și proiectarea, la care se verifică și se justifică fezabilitatea soluțiilor tehnice prin realizarea de prototipuri.

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

    Orez. 1.2. Model în spirală al ciclului de viață AIS

    Astfel, fiecare tură a spiralei corespunde creării unui fragment sau a unei versiuni a unui produs software, obiectivele și caracteristicile proiectului sunt clarificate, calitatea acestuia este determinată și lucrul este planificat pentru 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ă vă permite să treceți la următoarea etapă a proiectului fără a aștepta ca cea actuală să fie complet finalizată - lucrul neterminat poate fi finalizat la următoarea iterație. Sarcina principală a fiecărei iterații este de a crea un produs funcțional pe care să-l demonstreze utilizatorilor cât mai repede posibil. Astfel, procesul de realizare a clarificărilor și completărilor la proiect este simplificat semnificativ.

    Abordarea spirală a dezvoltării software depășește majoritatea dezavantajelor modelului cascadă, în plus, oferă o serie de caracteristici suplimentare, făcând procesul de dezvoltare mai flexibil.

    Avantaje abordare iterativă:

    Dezvoltarea iterativă simplifică semnificativ efectuarea de modificări la proiect atunci când cerințele clienților se modifică;

    Când se utilizează modelul în spirală, elementele individuale ale AIS sunt integrate treptat într-un singur întreg. Deoarece integrarea începe cu mai puține elemente, există mult mai puține probleme în timpul integrării;

    Reducerea nivelului riscurilor (o consecință a avantajului anterior, deoarece riscurile sunt descoperite tocmai în timpul integrării). Nivelul de risc este maxim la începutul dezvoltării proiectului și scade pe măsură ce dezvoltarea progresează;

    Dezvoltarea iterativă oferă o mai mare flexibilitate în managementul proiectelor, făcând posibilă efectuarea de modificări tactice la produsul dezvoltat. Astfel, puteți reduce timpul de dezvoltare prin reducerea funcționalității sistemului sau folosiți-l ca componente produse ale companiilor terțe în locul dezvoltărilor proprii (relevante într-o economie de piață, când este necesar să reziste promovării produselor concurenților);

    Abordarea iterativă facilitează reutilizarea componentelor deoarece este mult mai ușor să identifici părți comune ale unui proiect atunci când acestea sunt deja parțial dezvoltate decât să încerci să le izolezi chiar la începutul proiectului. Analizând designul după câteva iterații inițiale dezvăluie componente comune, reutilizabile, care vor fi îmbunătățite în iterațiile ulterioare;

    Modelul în spirală permite un sistem mai fiabil și mai stabil. Acest lucru se datorează faptului că pe măsură ce sistemul evoluează, erorile și punctele slabe sunt descoperite și corectate la fiecare iterație. În același timp, sunt ajustați parametrii critici de eficiență, care în cazul modelului în cascadă sunt disponibili numai înainte de implementarea sistemului;

    Abordarea iterativă permite îmbunătățirea procesului
    dezvoltare - ca rezultat al analizei la finalul fiecărei iterații, se evaluează schimbările în organizarea dezvoltării; se îmbunătățește în următoarea iterație.

    Problema principală a ciclului spiral- dificultatea de a determina momentul trecerii la etapa urmatoare. Pentru a o rezolva, este necesar să se introducă restricții de timp pentru fiecare etapă a ciclului de viață. În caz contrar, procesul de dezvoltare se poate transforma într-o îmbunătățire nesfârșită a ceea ce a fost deja făcut.

    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 timpul procesului de proiectare a aplicației, reducând timpul de dezvoltare. Reprezentanții clienților 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.

    Modelul ciclului de viață și tehnologia de proiectare

    Mai devreme spuneam că tehnologia de proiectare stabilește succesiunea de acțiuni necesare obținerii unui proiect IP. Evident, implementarea fiecăreia dintre aceste acțiuni înseamnă o tranziție a sistemului informațional de la o stare la alta. Astfel, orice tehnologie de proiectare descrie în mod unic un anumit model de ciclu de viață. Pe de altă parte, prin construirea unui model de ciclu de viață al unui sistem informațional, adică prin definirea:

    · sarcini, alcătuirea și succesiunea lucrărilor efectuate;

    · rezultatele obținute în urma fiecărei acțiuni efectuate;

    · metode și mijloace necesare pentru efectuarea lucrării;

    · rolurile și responsabilitățile participanților;

    · alte informații necesare pentru planificarea, organizarea și gestionarea dezvoltării colective a PI,

    vom primi o descriere clară a tehnologiei de proiectare pe care am ales-o. Astfel, modelul ciclului de viață este un integral și partea cea mai importantă tehnologii de proiectare sisteme informatice.

    Etape și etape de proiectare

    Conceptele de „etapă” și „etapă” de proiectare sunt adesea confundate. Uneori vorbesc despre etape sau faze ciclu de viață, trepte proiecta. Apare întrebarea: care este calea corectă?

    Trebuie amintit că în diferit standarde internaționale Terminologia utilizată poate varia. Ne vom concentra, ori de câte ori este posibil, pe terminologia GOST-urilor interne. Etapa de proiectare vom numi o parte a procesului de creare a unui IP, limitată de un anumit interval de timp și care se încheie cu lansarea unui anumit produs (model, documentație, text program etc.). Pe baza obiectivelor comune, etapele de proiectare pot fi combinate în etape. De exemplu, etapa „Proiectare tehnică”, etapa „Implementare” etc.

    Conform datelor publicate, fiecare etapă a dezvoltării AIS necesită o anumită perioadă de timp. În cea mai mare parte (45-50%) timpul este alocat codării, testării complexe și offline. În medie, dezvoltarea unui AIS ocupă o treime din întregul ciclu de viață al sistemului.

    Orez. Distribuția timpului în timpul dezvoltării AIS

    Etapele creării unui AIS (ISO/IEC 15288)

    Standardul ISO/IEC 12207 definește o structură a ciclului de viață care conține procesele, activitățile și sarcinile care trebuie efectuate în timpul creării unui sistem informațional.

    Orice activitate a companiei se reflectă în documente, iar pentru a îmbunătăți calitatea proceselor de afaceri este necesară îmbunătățirea fluxului documentelor, adică optimizarea acestuia. Optimizarea fluxului de documente este înțeleasă ca un set de măsuri organizaționale, tehnice, software și de proiectare efectuate de o organizație.

    Utilizarea acestor metodologii în timpul construcției modelelor de proces de afaceri sub forma unei ierarhii de diagrame asigură claritatea și completitudinea afișajului lor și vă permite să analizați activitățile întreprinderii.

    IDEF0 - prima secțiune de informații - funcționalitatea sistemului. Principala dintre cele trei metodologii suportate de BPwin este IDEF0. IDEF0, aparține familiei IDEF, care a apărut la sfârșitul anilor șaizeci sub denumirea SADT (Structured Analysis and Design Technique). IDEF0 poate fi folosit pentru a modela o gamă largă de sisteme. Pentru sistemele noi, utilizarea IDEF0 are ca scop definirea cerințelor și specificarea funcțiilor pentru dezvoltarea ulterioară a unui sistem care îndeplinește cerințele și implementează funcțiile selectate. Când este aplicat sistemelor IDEF0 existente, acesta poate fi utilizat pentru a analiza funcțiile îndeplinite de sistem și pentru a mapa mecanismele prin care sunt îndeplinite acele funcții. Rezultatul aplicării IDEF0 la un sistem este un model al acelui sistem constând dintr-un set ordonat ierarhic de diagrame, text de documentație și vocabulare care sunt încrucișate împreună.

    Cele mai importante două componente care alcătuiesc diagramele IDEF0 sunt funcțiile sau activitățile de afaceri (reprezentate în diagrame sub formă de casete) și datele și obiectele (reprezentate ca săgeți) care leagă activitățile. În acest caz, săgețile, în funcție de ce față a dreptunghiului de lucru intră sau din ce față ies, sunt împărțite în cinci tipuri:

    • - Săgeți de intrare (incluse în partea stângă a lucrării) - prezintă date sau obiecte care se modifică în timpul execuției lucrării.
    • - Săgețile de control (incluse în marginea superioară a lucrării) - descriu regulile și restricțiile în funcție de care este efectuată lucrarea.
    • - Săgeți de ieșire (ieșind din marginea dreaptă a lucrării) - descriu date sau obiecte care apar ca urmare a lucrării.
    • - Săgețile mecanismului (incluse în marginea de jos a lucrării) - descriu resursele necesare pentru finalizarea lucrării, dar nu se modifică în timpul lucrării (de exemplu, echipamente, resurse umane).
    • - Săgeți de apel (care vin de la marginea de jos a lucrării) - descriu conexiuni între diferite diagrame sau modele, indicând o anumită diagramă în care această lucrare este discutată mai detaliat.

    Toate locurile de muncă și săgețile trebuie să fie denumite. Prima diagramă din ierarhia diagramei IDEF0 descrie întotdeauna funcționarea sistemului ca întreg. Astfel de diagrame se numesc diagrame de context. Contextul diagramei include o descriere a scopului modelării, domeniul de aplicare (descrieri a ceea ce va fi considerat ca o componentă a sistemului și ceea ce influență externă) și punct de vedere (poziția din care va fi construit modelul). De obicei, punctul de vedere este punctul de vedere al persoanei sau obiectului responsabil de funcționarea sistemului modelat ca întreg.

    În această lucrare, numele modelului este „Contabilitatea prezenței în grădiniţă”, numele proiectului „Înregistrarea prezenței la grădiniță”, numele autorului și tipul de model - Oshchepkov Maxim și Time Frame: AS - IS (As is).

    Scopul muncii (Scopul) este de a modela procesele curente de afaceri ale unui angajat al departamentului IT, punctul de vedere (Punctul de vedere) al unui inginer de sisteme. Să adăugăm o definiție a modelului: „Acesta este un model care ține evidența prezenței la grădiniță” și scopul: „Păstrează evidența prezenței, înregistrează munca efectuată, organizează căutări și raportări”.

    Prima diagramă din ierarhia diagramei IDEF0 descrie întotdeauna funcționarea sistemului ca întreg. Astfel de diagrame sunt numite diagrame de context (Figura 2).

    Figura 2. Diagrama contextuală „Înregistrarea prezenței la grădiniță”

    În conformitate cu metoda IDEF0, definim datele de intrare, datele de ieșire, controlul și mecanismul, care sunt reprezentate în diagramă prin săgeți:

    • - Date de intrare: Aplicația unui angajat care indică motivul inoperabilității computerului și numărul acestuia.
    • - Date de ieșire: Diverse tipuri componente de raportare, corectate și necorectate.
    • - Guvernare: Legislație, reguli și reglementări.
    • - Mecanism: Angajații departamentului IT și ai altor departamente ale organizațiilor.

    După ce contextul este descris, se realizează construcția urmatoarele diagrameîn ierarhie. Fiecare diagramă ulterioară este o descriere (descompunere) mai detaliată a uneia dintre lucrările din diagrama de mai sus. Un exemplu de descompunere contextuală a lucrării este prezentat în Figura 3.


    Figura 3. Diagrama de descompunere „Înregistrarea prezenței la grădiniță”

    Descrierea fiecărui subsistem este realizată de un analist împreună cu un expert în domeniu. De obicei, expertul este persoana responsabilă de acel subsistem și, prin urmare, are o cunoaștere aprofundată a tuturor funcțiilor acestuia.

    Astfel, întregul sistem este împărțit în subsisteme la nivelul necesar de detaliu și se obține un model care aproximează sistemul cu un anumit nivel de precizie. După ce a primit un model care reflectă în mod adecvat procesele actuale de afaceri (așa-numitul model AS-IS), analistul poate vedea cu ușurință toate punctele cele mai vulnerabile ale sistemului. După aceasta, ținând cont de deficiențele identificate, puteți construi un model noua organizare procesele de afaceri (modelul TO-BE).

    BPwin sincronizează automat modificările aduse obiectelor diagramei la toate nivelurile de detaliu, eliberând astfel utilizatorul de a menține manual un dicționar de obiecte model. Deci dacă o corectăm nivel superior numele obiectului, apoi obținem o schimbare la toate nivelurile unde apare acest obiect. Dublarea accidentală a titlurilor lucrărilor este, de asemenea, imposibilă. Când apare o astfel de situație, BPwin generează un mesaj de avertizare.

    Diagramele de flux de date pun toate simbolurile utilizate într-o imagine de ansamblu care oferă o imagine clară a datelor care sunt utilizate și ce funcții sunt îndeplinite de sistemul de flux de lucru. În același timp, adesea se dovedește că fluxurile de informații existente care sunt importante pentru activitățile companiei nu sunt implementate în mod fiabil și trebuie reorganizate.

    Modele de ciclu de viață AIS - O structură care definește implementarea secvențială a proceselor, acțiunilor, sarcinilor efectuate de-a lungul ciclului de viață și relațiile dintre aceste procese.

    Model în cascadă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrărilor în etapa anterioară. Cerințele determinate în etapa formării cerințelor sunt strict documentate sub formă de specificații tehnice și sunt înregistrate pentru întreaga dezvoltare a proiectului. Fiecare etapă culminează cu lansarea unui set complet de documentație suficientă pentru a permite continuarea dezvoltării de către o altă echipă de dezvoltare.

    Etape ale proiectului conform modelului cascada:

    1. Formarea cerințelor;

    2. Design;

    3. Dezvoltare;

    4. Testare;

    5. Implementare;

    6. Operare și întreținere.

    Avantaje:

    -Documentația completă și agreată la fiecare etapă;

    -O anumită ordine a secvenței de lucru;

    -Vă permite să planificați clar termenele limită și costurile.

    Defecte:

    -Întârziere semnificativă în obținerea rezultatelor finale;

    -Erorile în orice etapă sunt identificate în etapele ulterioare, ceea ce duce la necesitatea returnării și reînregistrării documentației de proiect;

    - Complexitatea managementului de proiect.

    Model în spirală. Fiecare iterație corespunde creării unui fragment sau a unei versiuni a software-ului, la care se clarifică obiectivele și caracteristicile proiectului, se evaluează calitatea rezultatelor obținute și se planifică activitatea următoarei iterații.

    Fiecare iterație este un ciclu de dezvoltare finalizat sub forma primei versiuni a AIS.

    Etape de iterație:

    1. Formarea cerințelor

    3.Design

    4.Dezvoltare

    5.Integrare

    La fiecare iterație sunt evaluate următoarele:

    Risc de depășire a termenelor și costurilor proiectului;

    Necesitatea de a efectua o altă iterație;

    Gradul de completitudine și acuratețe de înțelegere a cerințelor sistemului;

    Fezabilitatea rezilierii proiectului.

    Avantaje:

    -Se simplifică procesul de efectuare a modificărilor în proiect;

    - Oferă o mai mare flexibilitate în managementul proiectelor;

    -Capacitatea de a obține un sistem fiabil și stabil, deoarece erorile și inconsecvențele sunt detectate la fiecare iterație;

    -Influența clientului asupra lucrării în timpul procesului de verificare a fiecărei iterații.

    Defecte:

    -Dificultate de planificare;

    -Program de lucru intens pentru dezvoltatori;

    -Planificarea muncii se realizează pe baza experienței existente și nu există suficiente metrici pentru a măsura calitatea fiecărei versiuni.

    Cerințe pentru tehnologia de proiectare, dezvoltare și suport AIS

    Tehnologia de proiectare- definește o combinație de trei componente:



    -procedura pas cu pas care defineste succesiunea operatiilor de proiectare tehnologica;

    -reguli utilizate pentru evaluarea rezultatelor operațiunilor tehnologice;

    -depunerea dezvoltării proiectului spre examinare și aprobare.

    Instrucțiunile tehnologice, care constituie conținutul principal al tehnologiei, trebuie să conțină o descriere a succesiunii operațiilor tehnologice, condițiile în funcție de care se efectuează una sau alta operațiune și descrieri ale operațiunilor în sine.

    Tehnologia de proiectare, dezvoltare și întreținere IS trebuie să satisfacă următoarele cerințe generale:

    Tehnologia trebuie să suporte întregul ciclu de viață al software-ului;

    Tehnologia trebuie să asigure realizarea garantată a obiectivelor de dezvoltare SI cu o calitate dată și într-un timp stabilit;

    Tehnologia ar trebui să ofere capacitatea de a efectua lucrări de proiectare a subsistemelor individuale în grupuri mici (3-7 persoane). Acest lucru se datorează principiilor managementului echipei și creșterii productivității prin minimizarea numărului de conexiuni externe;

    Tehnologia ar trebui să ofere capacitatea de a gestiona configurația proiectului, de a menține versiunile proiectului și ale componentelor acestuia, abilitatea de a elibera automat documentația proiectului și de a sincroniza versiunile acestuia cu versiunile de proiect;

    Utilizarea oricărei tehnologii pentru proiectarea, dezvoltarea și întreținerea sistemelor informaționale într-o anumită organizație și un anumit proiect este imposibilă fără dezvoltarea unui număr de standarde (reguli, acorduri) care trebuie respectate de toți participanții la proiect. La asa ceva standardele includ următoarele:

    -standard de proiectare;

    - standard pentru documentația de proiectare;

    -standard de interfață cu utilizatorul.

    Cerința de dezvoltare

    - Efectuarea lucrărilor de realizare a software-ului;

    Pregătirea pentru implementarea AIS;



    Monitorizarea și testarea indicatorilor cheie de proiect.

    Cerințe de întreținere

    Finalizarea implementării SIC ar trebui să fie însoțită de publicarea unui sistem de reglementări administrative și fișele postului, definind ordinea de functionare a organizatiei. Din momentul punerii în funcțiune a sistemului informațional, funcționarea are loc în baza „Regulamentului de funcționare a sistemului informațional” și a unui număr de reglementări. Întreținerea sistemului și funcționarea neîntreruptă a acestuia este efectuată de o divizie a organizației autorizată prin ordinul relevant. Rafinarea sistemului informatic după punerea în funcțiune se realizează în conformitate cu proiectele individuale și specificațiile tehnice.

    În procesul de menținere a unui CSI, sarcina este de a menține viabilitatea acestuia. Viabilitatea SIC este în mare măsură determinată de cât de bine corespunde sarcinilor și nevoilor reale ale universității, care se schimbă pe parcursul ciclului de viață al SIC.

    Design canonic AIS


    Dezvoltare și proiectare AISîncepe cu crearea unui model conceptual al modului de utilizare a sistemului. În primul rând, trebuie determinată fezabilitatea creării unui sistem, al acestuia functii specificeși sarcinile care urmează să fie automatizate. Trebuie evaluate nu numai obiectivele, ci și fezabilitatea creării sistemului. În continuare, sunt analizate cerințele pentru AIS, proiectarea detaliată, interrelația etapelor, programarea și testarea, minimizarea pierderilor în timpul trecerii de la un nivel de prezentare a informațiilor la altul, integrarea în sistemul existent, implementarea și suportul.

    Există trei clase de metodologii de proiectare AIS:
    · modelarea conceptuală a disciplinei;
    · identificarea cerințelor și specificarea sistemului informațional prin prototiparea acestuia;
    · arhitectura de sistem software susținută de instrumentele tehnologice CASE (CASE - Computer Aided Software Engineering - tehnologie pentru crearea și întreținerea software-ului pentru diverse sisteme).

    Etapa creării unui sistem automat - parte a procesului de creare a unui AS, stabilit documente de reglementareși se încheie cu eliberarea documentației pentru CNE, care ar trebui să conțină un model al sistemului la nivelul acestei etape, fabricarea componentelor neseriale sau acceptarea CNE în exploatare.
    Fiecare etapă este evidențiată din motive de planificare și organizare rațională a muncii și trebuie neapărat să se încheie cu un anumit rezultat. Conținutul documentației la fiecare etapă este determinat de compoziția și specificul lucrării.
    GOST 34.601-90 definește opt etape de creare a sistemelor automate:

    1. Formarea cerințelor pentru vorbitori.
    2. Dezvoltarea conceptului AC.
    3. Specificatii tehnice.
    4. Proiect de proiect.
    5. Proiect tehnic.
    6. Documentatie de lucru.
    7. Punerea în funcțiune.
    8. Suport AC.
    Se pot distinge trei perioade de creare a sistemului: pre-proiectare, proiectare, punere în funcțiune.
    Etapele 1, 2, 3 aparțin primei perioade, etapele 4, 5, 6 - celei de-a doua perioade, etapele 7, 8 - celei de-a treia.
    În perioada de pre-proiectare, sunt elaborate un studiu de fezabilitate (TES) și specificații tehnice (TOR) pentru proiectarea sistemului. În această perioadă, în etapa formării cerințelor pentru CNE, se desfășoară trei etape de lucru:
    • examinarea obiectului domeniului și justificarea necesității creării unui sistem;
    • formarea cerințelor utilizatorilor pentru sistem;
    • întocmirea unui proces-verbal asupra lucrărilor efectuate și a unei aplicații pentru dezvoltarea sistemului.
    În etapa de dezvoltare a conceptului AS, sunt efectuate patru etape de lucru:
    • studierea obiectului;
    • efectuarea de lucrări de cercetare;
    • alegerea unei optiuni de concept de sistem dintre mai multe dezvoltate;
    • întocmirea unui proces-verbal asupra lucrărilor efectuate.
    La a 3-a etapă se elaborează și se aprobă specificațiile tehnice pentru realizarea CNE.
    Specificații tehnice (TOR) — aceasta este o listă a cerințelor operaționale, tehnologice, economice și de altă natură pe care instalația proiectată trebuie să le satisfacă în toate etapele existenței sale. După aprobarea specificațiilor tehnice, începe a doua perioadă de creare a CNE - perioada de proiectare a sistemului.
    Design - procesul de selecție justificată a caracteristicilor sistemului, formarea modelelor logico-matematice și economico-matematice, elaborarea documentației.
    În etapa de realizare a unui proiect preliminar, în prima etapă, sunt dezvoltate soluții de proiectare preliminară pentru sistem și părțile sale, în etapa a 2-a - documentația pentru NAS și părțile sale.
    La a 5-a etapă, la crearea unui proiect tehnic, dezvoltarea se realizează în patru etape:
    • soluții de proiectare pentru sistem și piesele sale;
    • documentație privind AS și părțile sale;
    • documentatie pentru furnizarea produselor pentru completarea AS si specificatii tehnice pentru dezvoltarea acestora;
    • sarcini n# proiectare în părțile adiacente ale proiectului obiect de automatizare.
    A treia perioadă este punerea în funcțiune a CNE. Acestea asigură dezvoltarea de echipamente non-standard, furnizarea de echipamente, materiale, produse achiziționate, instalare, punere în funcțiune și implementare.
    La etapa 7, sistemul este pus în funcțiune în opt etape:
    • pregătirea obiectului de automatizare pentru punerea în funcțiune a AS;
    • instruirea personalului;
    • dotarea boxelor cu software, hardware, instrumente de informare și produse;
    • lucrari de constructii si montaj;
    • lucrări de punere în funcțiune;
    • teste preliminare;
    • operațiune de probă;
    • teste de acceptare.
    Conținutul etapelor de creare a unui AS în diferite etape
    Pentru a îmbunătăți gestionarea progresului de proiectare, fiecare etapă este detaliată, adică împărțită în etape.
    Etapa creării unui sistem automat - parte a etapei creării unui AS, determinată de natura lucrării, rezultatul acesteia sau specializarea interpreților.
    Metodologiile moderne de proiectare a sistemului ar trebui să ofere o descriere a obiectelor de automatizare, o descriere a funcționalității AIS, o specificație de proiect care să garanteze atingerea caracteristicilor specificate ale sistemului, un plan detaliat pentru crearea unui sistem cu o estimare a timpului de dezvoltare și o descrierea implementării unui sistem specific.

    Ciclul de viață AIS
    Baza creației și utilizării AIS constă conceptul de ciclu de viață (LC).
    Ciclul de viață este un model pentru crearea și utilizarea unui sistem informatic automatizat, care reflectă diferitele stări ale sistemului din momentul în care mijloacele apar într-un complex dat și până în momentul în care acesta iese complet din uz.

    Pentru AIS, se disting în mod convențional următoarele etape principale ale ciclului lor de viață:
    1. analiza - determinarea a ceea ce ar trebui sa faca sistemul;
    2. proiectare - determinarea modului în care va funcționa sistemul: în primul rând, specificarea subsistemelor, a componentelor funcționale și a modalităților de interacțiune a acestora în sistem;
    3. dezvoltare - crearea de componente funcționale și subsisteme individuale, conectarea subsistemelor într-un singur întreg;
    4. testare - verificarea conformității funcționale și parametrice a sistemului cu indicatorii determinați în etapa de analiză;
    5. implementare - instalarea si punerea in functiune a sistemului;
    6. suport - asigurarea procesului normal de operare a sistemului la întreprinderea clientului.

    Etapele dezvoltării, testării și implementării AIS sunt desemnate printr-un singur termen - implementare.
    În fiecare etapă a ciclului de viață se generează un anumit set de soluții tehnice și documente care le reflectă, iar pentru fiecare etapă documentele inițiale și deciziile luate în etapa anterioară sunt punctele de plecare.
    Modelele de ciclu de viață existente determină ordinea de execuție a etapelor în procesul de creare a unui sistem, precum și criteriile de trecere de la etapă la etapă. Următoarele modele sunt cele mai răspândite.

    Model în cascadă presupune trecerea la etapa următoare după finalizarea completă a lucrărilor etapei precedente. Acest model este utilizat în construcția sistemelor informatice automatizate, pentru care toate cerințele pot fi formulate destul de precis și complet chiar la începutul dezvoltării. Acest lucru oferă dezvoltatorilor libertatea de a le implementa cât mai tehnic posibil. Această categorie include sisteme complexe de calcul, sisteme în timp real și altele. Cu toate acestea, această abordare are o serie de dezavantaje, cauzate în primul rând de faptul că procesul real de creare a unui sistem nu se încadrează niciodată complet într-o schemă rigidă. De exemplu, în procesul de creare a software-ului, este nevoie de a reveni la etapele anterioare și de a clarifica sau revizui deciziile luate anterior.

    Model în spirală se bazează pe etapele inițiale ciclu de viață: analiză, proiectare preliminară și detaliată.
    Fiecare tură a spiralei corespunde unui model pas cu pas pentru crearea unui fragment sau a unei versiuni a sistemului pe ea, obiectivele și caracteristicile proiectului sunt clarificate, calitatea acestuia este determinată și munca următoarei ture; spirala este planificată. Problema principală este determinarea momentului de tranziție la etapa următoare. Pentru a o rezolva, este necesar să se introducă restricții de timp pentru fiecare dintre etapele ciclului de viață. Tranziția se realizează în conformitate cu planul, care este întocmit pe baza datelor statistice obținute în proiectele anterioare și experiență personală dezvoltatori. Dezavantajul acestei abordări îl reprezintă problemele nerezolvate și erorile făcute în timpul etapelor de analiză și proiectare. Acestea pot duce la probleme în etapele ulterioare și chiar la eșecul întregului proiect. Din acest motiv, analiza și proiectarea trebuie efectuate cu o grijă deosebită.