Există multe metode și opțiuni pentru dezvoltarea AIS, a căror utilizare depinde de diverși factori, de exemplu, dimensiunea întreprinderilor și (sau) IS-ul acestora, scopurile creării unui IS, resursele disponibile etc. Metode și principii de proiectare un IS sunt discutate în capitolele precedente.
Ciclul de viață al proiectului software este un set de etape și etape ale dezvoltării software pornind de la analiza de sistemși dezvoltarea cerințelor inițiale înainte de instalarea (instalarea) pe un computer.
Experiența în dezvoltarea și implementarea diferitelor clase de AIS a demonstrat o eficiență ridicată (inclusiv economică) a aplicării acestora, în special în mari intreprinderi... Se reflectă într-o bună organizare a muncii și a producției, o creștere a acurateței planificării și implementării sarcinilor stabilite, în asigurarea ritmului întreprinderii, reducerea ponderii muncii manuale, suport informațional eficient (inclusiv operațional) pentru diverse categorii de utilizatori etc. Perioada medie de rambursare pentru astfel de sisteme nu depășește de obicei doi ani.
La dezvoltarea SI, in cele mai multe cazuri, se prefera solutiile standard de proiectare, adaptate conditiilor si capacitatilor specifice ale Clientului. Proiecte individuale sunt dezvoltate în absența soluțiilor standard sau când parametrii de bază ai organizației diferă semnificativ (cu mai mult de 10-15%) de soluțiile standard. Acest lucru se aplică de obicei organizațiilor mari și mai mari.
Nicio schemă de dezvoltare IC nu este absolută. Sunt posibile diferite opțiuni, în funcție, de exemplu, de condițiile inițiale în care se realizează dezvoltarea: se dezvoltă un sistem complet nou; a fost deja efectuat un sondaj al întreprinderii și există un model al activității acesteia; întreprinderea are deja un IS care poate fi folosit ca prototip inițial sau ar trebui integrat cu cel dezvoltat.
Dezvoltarea detaliată a proiectului AIS presupune disponibilitatea unui set complet de documentație organizatorică, de proiectare, tehnologică și operațională.
Proiectarea oricărui obiect se realizează cu:
- a) determinarea scopului său funcțional (de ce este necesar, ce și cum face obiectul proiectat);
- b) identificarea conexiunilor logice (modul în care obiectul proiectat își îndeplinește scopul funcțional, ce informații sunt procesate și în ce secvență);
- c) alegere resurse materiale implementarea obiectului proiectat - aspect funcțional, tehnologic și tehnic (media, instrumente de prelucrare a datelor etc.),
- d) amplasarea spațială (teritorială) a mijloacelor materiale de vânzare în zonele alocate sau posibile de utilizare,
- e) formarea structurii organizatorice și de conducere a obiectului proiectat (compunerea departamentelor, competențe și responsabilități funcționale muncitorii)
După alegerea metodei de proiectare AIS, este necesar să se planifice un set de lucrări pentru a crea un sistem în conformitate cu etapele tipice ale dezvoltării acestuia. Proiectul este revizuit și aprobat de către Client. Proiectarea AIS presupune implementarea anumitor etape și etape.
Pentru implementarea cu succes a proiectului, este necesar să se stabilească etape reale cu începutul și sfârșitul clar marcate. Dezvoltarea plan detaliat munca este asociată cu o descriere a proceselor și a succesiunii acestora efectuate în fiecare etapă, a specialiștilor necesari, a fondurilor și a resurselor. Această abordare ajută într-o mai mare măsură la evitarea omisiunilor și a greșelilor. Este necesar pentru angajații care implementează implementarea unui proiect de automatizare și are, de asemenea, un impact pozitiv asupra persoanelor care îl finanțează.
Implementare eficientă în etape munca de proiectare asociat cu necesitatea de a dezvolta un program pentru implementarea lor, inclusiv resursele și termenii (etapele) implementării lor (a se vedea graficele și figurile anterioare). Resursele includ personalul necesar, hardware, software, finanțare și infrastructură. În același timp, este mai bine să îl finanțați separat pentru fiecare tip de lucrare (achiziționare de fonduri și software, instalare, instruire, etape individuale de proiectare etc.).
Pentru automatizarea diferitelor tipuri de activități (management, proiectare, cercetare etc.), inclusiv combinațiile acestora, sunt utilizate prevederile GOST 34.601-90. Acesta prevede următoarele etape și etape de proiectare (tabelul 1).
masa 2
|
1. Formarea cerințelor pentru UA |
|
|
2. Dezvoltare concepte de vorbitor |
|
|
3. Termeni de referință |
3.1. Elaborarea și aprobarea specificațiilor tehnice pentru crearea unei UA |
|
4. Proiect de proiect |
|
|
6. Documentație de lucru |
|
|
7. Punerea în funcţiune |
|
|
8. Acompaniamentul UA |
|
Standardul mai precizează că:
- · Etapele și etapele efectuate de organizațiile care participă la crearea UA sunt stabilite în contracte și Termeni de referință bazați pe acest standard.
- · Este permisă excluderea etapei „Proiectare proiect” și etape separate de lucru în toate etapele, combinarea „Proiectare tehnică” și „Documentație de lucru” într-o singură etapă „Proiectare tehnică de lucru”. În funcție de specificul sistemelor nucleare care se creează și de condițiile de realizare a acestora, este permisă efectuarea unor etape individuale de lucru înainte de finalizarea etapelor anterioare, paralele în timp execuției etapelor de lucru, includerea de noi etape de lucru. .
Proiectul preliminar conține elementele fundamentale circuite electriceși documentația de proiectare a obiectului de dezvoltare și a componentelor acestuia, o listă de instrumente software și hardware gata făcute selectate (inclusiv tipuri de computere, sisteme de operare, programe de aplicație etc.), algoritmi pentru rezolvarea problemelor pentru dezvoltarea de noi instrumente software).
Proiectare detaliată - etapa finală de proiectare, în general, care prevede rafinarea și detalierea rezultatelor etapelor anterioare, crearea și testarea unui prototip al obiectului de automatizare, dezvoltarea și testarea produselor software, documentația tehnologică și operațională.
În practica modernă de proiectare a sistemelor informatice automatizate (de exemplu, AIPS, ASNTI, ACS etc.), aceasta poate fi etapa inițială a implementării lor în activitatea unei organizații sau serviciu a Clientului proiectului, sau a șefului. unul dintr-o serie de alte organizații automate, servicii etc.
Dezvoltarea detaliată a proiectării sistemului presupune disponibilitatea unui set complet de documentație organizatorică, de proiectare, tehnologică și operațională.
Standardul de stat GOST 19.102-77 stabilește următoarele etape de dezvoltare a documentației software:
- 1. Termeni de referință;
- 2. Proiect de proiect;
- 3. Proiectare tehnică;
- 4. Proiect de lucru;
- 5. Implementare.
Rețineți că pentru proiectele mici numărul de etape poate fi redus.
Ca parte a implementării primei etape „Formarea cerințelor pentru AU”, obiectul este analizat și necesitatea creării unui AIS este fundamentată, ținând cont de cerințele utilizatorului pentru AIS proiectat. Aceste proceduri din prima etapă de proiectare fac parte din studiul pre-proiect. Aceasta poate include și procedurile din a doua etapă de proiectare - „Dezvoltarea conceptului CNE”.
În procesul cercetării de pre-proiectare, se realizează un studiu de fezabilitate pentru fezabilitatea creării unui AIS; dezvoltarea cerințelor generale pentru dezvoltarea AIS.
În procesul unui studiu de pre-proiectare pentru implementarea lucrărilor de proiectare necesare, se identifică următoarele:
- · resurse materiale,
- · resurse financiare,
- · resurse umane,
- · Resurse temporare.
În prezent, orice organizație are la dispoziție niște resurse materiale, de regulă, de origine eterogenă. Pentru a asigura siguranța acestor resurse, este necesar să se țină evidențe și să desemneze persoane responsabile. Soluția la această problemă poate fi realizată folosind diverse aplicații, cum ar fi 1C: Enterprise, AVARD și multe altele. Dar aceste programe sunt foarte scumpe, atât la cumpărare, cât și la întreținere. Necesită educație și pregătire specială a personalului.
Nbsp; Modele de ciclu de viață AIS
Modelul ciclului de viață AIS este o structură care descrie procesele, acțiunile și sarcinile care sunt efectuate și î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 la fiecare etapă;
Evenimente cheie sau puncte de finalizare și luare a deciziilor.
În conformitate cu modelele binecunoscute ale ciclului de viață al software-ului, modelele ciclului de viață al AIS sunt determinate - cascadă, iterativă, spirală.
I. Model cascadă descrie abordarea clasică a dezvoltării sistemelor în orice domeniu; a fost utilizat pe scară largă în anii 1970 și 1980.
Modelul în cascadă prevede organizarea secvențială a muncii, iar principala caracteristică a modelului este împărțirea tuturor lucrărilor în etape. Trecerea de la etapa anterioară la următoarea are loc numai după finalizarea completă a tuturor lucrărilor precedentei.
Aloca cinci stadii stabile de dezvoltare, practic independente de domeniul subiectului (Fig. 1.1).
Pe primulÎn această etapă se realizează un studiu al zonei cu probleme, se formulează cerințele clientului. Rezultatul această etapă este o sarcină tehnică (sarcină de dezvoltare), agreată cu toate părțile interesate.
Pe parcursul al doilea etapă, în funcție de cerințele sarcinii tehnice, se dezvoltă anumite soluții de proiectare. Rezultatul este un set documentatia proiectului.
Al treilea etapa - implementarea proiectului; în esență, dezvoltarea software-ului (codarea) în conformitate cu deciziile de proiectare din etapa anterioară. În acest caz, metodele de implementare nu au o importanță fundamentală. Rezultatul acestei etape este un produs software finit.
Pe Al patruleaÎn această etapă, software-ul primit este verificat pentru conformitatea cu cerințele prevăzute în termenii de referință. Operarea de probă vă permite să identificați diferite tipuri de defecte ascunse care apar în condițiile reale ale AIS.
Ultima etapă este capitularea proiect finalizat, iar principalul lucru aici este să convingi clientul că toate cerințele sale sunt îndeplinite pe deplin.
Figura 1.1 Modelul cascadă al ciclului de viață AIS
Etapele de lucru din cadrul modelului cascadă sunt adesea numite părți ale ciclului de proiectare AIS, deoarece etapele constau în multe proceduri iterative pentru clarificarea cerințelor sistemului și a opțiunilor de proiectare. Ciclul de viață AIS este mult mai complicat și mai lung: poate include număr arbitrar cicluri de clarificare, modificări și completări la soluțiile de proiectare deja adoptate și implementate. În aceste cicluri are loc dezvoltarea AIS și modernizarea componentelor sale individuale.
Avantajele modelului în cascadă:
1) la fiecare etapă se formează un set complet de documentație de proiect care îndeplinește criteriile de completitudine și coerență. În etapele finale, se elaborează documentația utilizatorului, care acoperă toate tipurile de suport AIS oferit de standarde (organizațional, informațional, software, tehnic etc.);
2) implementarea secvențială a etapelor de lucru vă permite să planificați timpul de finalizare și costurile corespunzătoare.
Modelul cascadei a fost dezvoltat inițial pentru a rezolva diferite tipuri de probleme de inginerie și nu și-a pierdut semnificația pentru domeniul aplicat până în prezent. În plus, abordarea în cascadă este ideală pentru dezvoltarea AIS, deoarece deja la începutul dezvoltării, este posibil să se formuleze toate cerințele cu suficientă acuratețe pentru a oferi dezvoltatorilor libertatea de implementare tehnică. Astfel de AIS, în special, includ sisteme complexe de decontare și sisteme în timp real.
Dezavantajele modelului de cascadă:
Întârziere semnificativă în obținerea rezultatelor;
Erorile și neajunsurile în orice etapă apar, de regulă, în etapele ulterioare de lucru, ceea ce duce la necesitatea revenirii;
Complexitatea lucrărilor paralele la proiect;
Suprasaturarea excesivă de informații a fiecărei etape;
Complexitatea managementului de proiect;
Nivel ridicat de risc și nefiabilitatea investițiilor.
Întârziere în primirea rezultatelor se manifestă prin faptul că o abordare consecventă a dezvoltării acordului rezultatelor cu părțile interesate se realizează numai după finalizarea etapei următoare de lucru. Ca urmare, se poate dovedi că AIS dezvoltat nu îndeplinește cerințele și astfel de inconsecvențe pot apărea în orice stadiu de dezvoltare; în plus, erorile pot fi introduse din neatenție atât de către proiectanții analitici, cât și de către programatori, deoarece nu li se cere să fie bine versați în domeniile pentru care AIS este dezvoltat.
Reveniți la etapele anterioare. Acest dezavantaj este una dintre manifestările celui precedent: munca secvenţială pas cu pas la un proiect poate duce la faptul că greşelile 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 lucrarea ulterioară. Acest lucru poate duce la o întrerupere a programului și poate complica relația dintre grupurile de dezvoltare care realizează etapele individuale.
Cea mai proastă opțiune este atunci când defectele 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 reîntoarsă la stadiul inițial de lucru.
Complexitatea muncii paralele legat de necesitatea coordonării diferitelor părți ale proiectului Cu cât relația dintre părțile individuale ale proiectului este mai puternică, cu atât mai des și mai minuțios trebuie efectuată sincronizarea, cu atât echipele de dezvoltare sunt mai dependente unele de altele. Ca urmare, beneficiile muncii paralele sunt pur și simplu pierdute; lipsa paralelismului afectează negativ organizarea muncii întregii echipe.
Problemă suprasaturarea informatiei apare din dependențe puternice între diferite grupuri de dezvoltare. Faptul este că atunci când se efectuează modificări la una dintre părțile proiectului, este necesar să se anunțe acei dezvoltatori care l-au folosit (au putut folosi) în munca lor. În prezența unui număr mare de subsisteme interconectate, sincronizarea documentației interne devine o sarcină critică separată: dezvoltatorii trebuie să se familiarizeze în mod constant cu modificările și să evalueze modul în care aceste modificări vor afecta rezultatele obținute.
Complexitatea managementului de proiectîn principal datorită 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, prin urmare, este necesară intervenția administrativă pentru a conveni asupra calendarului și componenței documentației depuse.
Dacă în lucrare sunt detectate erori, este necesară o revenire la etapele anterioare; munca curentă a celor care au greșit este întreruptă. Consecința acestui lucru este de obicei o întârziere în finalizarea atât a proiectului corectat, cât și a noului proiect.
Este posibil să se simplifice interacțiunea dintre dezvoltatori și să se reducă supraîncărcarea 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 cuplate.
Nivel ridicat de risc. Cu cât proiectul este mai complex, cu atât este mai lungă fiecare etapă de dezvoltare și cu atât sunt mai complexe interconexiunile dintre părțile individuale ale proiectului, numărul cărora crește și el. Mai mult, rezultatele dezvoltării pot fi văzute și evaluate cu adevărat doar în etapa de testare, adică după finalizarea etapelor de analiză, proiectare și dezvoltare, a căror implementare necesită timp și bani semnificativi.
Evaluarea tardivă creează probleme serioase în identificarea erorilor de analiză și proiectare - necesită 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 apărut în domeniul subiectului sau în cerințele clientului î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ă o probabilitate de „buclă” a procesului de dezvoltare: costurile proiectului vor crește constant, iar termenele limită pentru livrarea produsului finit sunt amânate în mod constant.
II. Model iterativ constă dintr-o serie de cicluri (pași) scurte de planificare, implementare, studiu, acțiune.
Crearea unui AIS complex presupune aprobarea soluțiilor de proiectare obținute în implementarea sarcinilor individuale. Abordarea proiectării de jos în sus necesită astfel de iterații ale returnărilor, atunci când soluțiile de proiectare pentru sarcini individuale sunt combinate în unele sistemice comune. În același timp, este necesar să se revizuiască cerințele formate anterior.
Avantaj modelul iterativ este că ajustările între etape asigură o dezvoltare mai puțin intensivă în muncă în comparație cu modelul în cascadă.
Defecte model iterativ:
· Durata de viață a fiecărei etape se prelungește pe toată perioada de lucru;
· Din cauza unui număr mare de iterații, există inconsecvențe în implementarea soluțiilor de proiectare și a documentației;
· Complexitatea arhitecturii;
· Dificultăţile în utilizarea documentaţiei de proiectare în etapele de implementare şi operare necesită reproiectarea întregului sistem.
III. Model în spirală, spre deosebire de cascadă, dar similar cu cea anterioară, implică un proces iterativ de dezvoltare 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 duce la lansarea unei versiuni interne sau externe a unui produs (sau a unui subset al produsului final), care este îmbunătățită de la iterație la iterație pentru a deveni un sistem complet (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 produsului software, obiectivele și caracteristicile proiectului sunt specificate pe ea, calitatea acestuia este determinată, lucrul este planificat pentru următoarea tură a spiralei. Fiecare iterație servește la aprofundarea și concretizarea 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 finalizarea completă a celui actual - lucrarea neterminată poate fi finalizată la următoarea iterație. Scopul principal al fiecărei iterații este acela de a crea un produs funcțional pentru demonstrație pentru utilizatori cât mai curând posibil. Astfel, procesul de efectuare a ajustărilor și completărilor la proiect este mult simplificat.
Abordarea spirală a dezvoltării software depășește majoritatea deficiențelor modelului cascadă, în plus, oferă o serie de capabilități suplimentare, făcând procesul de dezvoltare mai flexibil.
Avantaje abordare iterativă:
Dezvoltarea iterativă simplifică foarte mult introducerea de modificări în proiect atunci când cerințele clientului se modifică;
Când se utilizează modelul în spirală, elementele AIS individuale sunt integrate treptat într-un singur întreg. Deoarece integrarea începe cu mai puține elemente, există mult mai puține probleme în implementarea ei;
Reducerea nivelului riscurilor (o consecință a avantajului anterior, deoarece riscurile sunt detectate tocmai în timpul integrării). Nivelul riscurilor este maxim la începutul dezvoltării proiectului, pe măsură ce dezvoltarea evoluează, acesta scade;
Dezvoltarea iterativă oferă o mai mare flexibilitate în managementul proiectelor, permițând modificări tactice asupra produsului dezvoltat. Așadar, puteți scurta timpul de dezvoltare prin reducerea funcționalității sistemului sau folosiți produsele companiilor terțe în locul propriilor dezvoltări ca părți componente (este important într-o economie de piață când este necesar să rezistați promovării concurenților). ' produse);
O abordare iterativă facilitează reutilizarea componentelor, deoarece este mult mai ușor să identifici (identificarea) părțile comune ale proiectului atunci când acestea sunt deja parțial dezvoltate decât să încerci să le izolezi chiar la începutul proiectului. Analiza proiectului după mai multe iterații inițiale relevă 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 remediate la fiecare iterație. În același timp, sunt ajustați parametrii critici de performanță, care în cazul unui model în cascadă sunt disponibili numai înainte de implementarea sistemului;
O abordare iterativă îmbunătățește procesul
dezvoltare - ca urmare a analizei de la sfârșitul fiecărei iterații, se realizează o evaluare a schimbărilor în organizarea dezvoltării; se îmbunătățește la următoarea iterație.
Principala problemă a ciclului spiral- dificultatea de a determina momentul trecerii la etapa urmatoare. Pentru a o rezolva, este necesar să se introducă limite 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 procesul de proiectare a aplicației, reducând timpul de dezvoltare. Reprezentanții clienților sunt capabili să controleze procesul de creare a unui sistem și să influențeze conținutul funcțional al acestuia. Rezultatul este punerea în funcțiune a unui sistem care ține cont de majoritatea nevoilor clienților.
Metodologiile moderne și tehnologiile de proiectare AIS care le implementează sunt livrate în formă electronică împreună cu instrumentele CASE și includ biblioteci de procese, șabloane, metode, modele și alte componente destinate construirii de software din clasa de sisteme către care se concentrează metodologia. Metodologiile și tehnologiile electronice constituie nucleul unui set de instrumente de dezvoltare AIS armonizate. Caracteristicile soluțiilor metodologice moderne pentru proiectarea AIS nu pot fi implementate fără anumite tehnologii de proiectare care corespund dimensiunii și specificului proiectului.
Tehnologia de proiectare AIS este un set de metode și instrumente pentru proiectarea AIS, precum și metode și instrumente pentru organizarea designului (gestionarea procesului de creare și modernizare a unui proiect AIS).
Conform designului TP, AIS este un set de lanțuri de acțiuni secvenţial-paralele, conectate și subordonate, fiecare dintre acestea putând avea propriul subiect. Acțiunile care se realizează în proiectarea AIS pot fi definite ca operații tehnologice indivizibile sau ca subprocese ale operațiunilor tehnologice. Toate acțiunile pot fi corecte proiecta, care modelează sau modifică rezultatele de proiectare și estimat, care sunt elaborate după criteriile stabilite de evaluare a rezultatelor proiectării.
Astfel, tehnologia de proiectare este stabilită de o succesiune reglementată de operațiuni tehnologice efectuate în procesul de creare a unui proiect bazat pe o metodă sau alta.
Subiectul tehnologiei de proiectare aleasă ar trebui să fie reflectarea proceselor de proiectare interconectate în toate etapele ciclului de viață AIS.
Principalele cerințe pentru tehnologia de proiectare aleasă sunt următoarele:
· Proiectul creat cu ajutorul acestei tehnologii trebuie sa corespunda cerintelor clientului;
· Tehnologia ar trebui să reflecte cât mai mult posibil toate etapele ciclului de viață al proiectului;
· Tehnologia ar trebui să ofere costuri minime de muncă și costuri pentru proiectare și sprijin pentru proiect;
· Tehnologia ar trebui să contribuie la creșterea productivității designerilor;
· Tehnologia ar trebui să asigure fiabilitatea proiectării și exploatării proiectului;
· Tehnologia ar trebui să faciliteze întreținerea ușoară a documentației proiectului.
Tehnologia de proiectare AIS implementează o metodologie de proiectare specifică. La rândul său, metodologia de proiectare presupune prezența unor concepte, principii de proiectare și este implementată printr-un set de metode și instrumente.
Metodele de proiectare AIS pot fi clasificate în funcție de gradul de utilizare a instrumentelor de automatizare, soluții tipice de proiectare, adaptabilitate la schimbările anticipate.
După gradul de automatizare, se disting:
proiectare manuală, în care proiectarea componentelor AIS se realizează fără utilizarea instrumentelor speciale instrumente software; programarea se face în limbaje algoritmice;
proiectarea calculatorului, în care generarea sau configurarea (tuningul) soluțiilor de proiectare se realizează folosind instrumente software speciale.
În funcție de gradul de utilizare a soluțiilor tipice de proiectare, acestea se disting:
original (individual) proiectare, atunci când soluțiile de proiectare sunt dezvoltate „de la zero” în conformitate cu cerințele pentru AIS;
design tipic, presupunând configurarea AIS din soluții de proiectare standard gata făcute (module software).
Design original AIS ia în considerare maximă caracteristicile unei instalații automate.
Design tipic se realizează pe baza unor soluții gata făcute și reprezintă o generalizare a experienței acumulate anterior în crearea proiectelor conexe.
După gradul de adaptabilitate al soluțiilor de proiectare următoarele metode diferă:
reconstrucţie- adaptarea soluțiilor de proiectare se realizează prin prelucrarea componentelor corespunzătoare (reprogramarea modulelor software);
parametrizare- solutiile de proiectare sunt ajustate in concordanta cu parametrii specificati si variabili;
restructurarea modelului- se modifică modelul disciplinei, ceea ce duce la reformarea automată a soluțiilor de proiectare.
Combinația diferitelor semne de clasificare a metodelor de proiectare determină natura tehnologiei de proiectare AIS utilizată. Există două clase principale de tehnologie de proiectare: canonicși industrial... Tehnologia designului industrial este împărțită în două subclase: automatizate(utilizarea tehnologiilor CASE) și tipic proiectare (orientată pe parametri parametri sau pe model).
Tabelul 1.1.Caracteristicile claselor de tehnologie de proiectare
Design canonic AIS se concentrează pe utilizarea în principal a modelului cascadă al ciclului de viață AIS.
În funcție de complexitatea obiectului de automatizare și de setul de sarcini care trebuie rezolvate la crearea unui AIS specific, etapele și etapele de lucru pot avea intensitate diferită a muncii. Este permisă combinarea etapelor succesive și excluderea unora dintre ele în orice etapă a proiectului. De asemenea, este permisă începerea lucrărilor etapei următoare înainte de sfârșitul celei anterioare.
Etapele și etapele creării AIS, efectuate de organizațiile participante, sunt prevăzute în contracte și termeni de referință pentru efectuarea lucrărilor.
Etapa 1. Formarea cerințelor pentru AIS:
· Analiza instalației și justificarea necesității de a crea AIS;
· Formarea cerințelor utilizatorilor pentru AIS;
· Întocmirea unui raport asupra lucrărilor efectuate și a unei sarcini tactice și tehnice pentru dezvoltare.
Etapa 2. Dezvoltarea conceptului AIS:
· Studiul obiectului automatizării;
· Efectuarea lucrărilor de cercetare necesare;
· Dezvoltarea de opțiuni pentru conceptul de AIS, care să satisfacă cerințele utilizatorilor;
· Intocmirea raportului si aprobarea conceptului.
Etapa 3. Sarcina tehnica:
Elaborarea și aprobarea specificațiilor tehnice pentru crearea AIS.
Etapa 4. Proiectare preliminară:
· Dezvoltarea de soluții de proiectare preliminară pentru sistem și părțile acestuia;
· Dezvoltarea documentației generale pentru AIS și părțile sale.
Etapa 5. Proiect tehnic:
· Dezvoltarea de soluții de proiectare pentru sistem și piesele acestuia;
· Dezvoltarea documentației pentru AIS și părțile sale;
· Elaborarea si executarea documentatiei pentru furnizarea componentelor;
· Dezvoltarea sarcinilor de proiectare în părțile conexe ale proiectului.
Etapa 6. Documentatie de lucru:
· Elaborarea documentației de lucru pentru AIS și părțile sale;
· Dezvoltarea și adaptarea programelor.
Etapa 7. Punere in functiune:
· Pregatirea obiectului de automatizare; pregatirea personalului;
· Set complet de produse furnizate AIS (software și hardware, complexe software și hardware, produse de informare);
· Lucrari de constructii si montaj; lucrări de punere în funcțiune;
· Efectuarea de teste preliminare;
· Efectuarea operațiunii de probă;
· Efectuarea testelor de acceptare.
Etapa 8. escorta AIS:
· Efectuarea lucrărilor în conformitate cu obligațiile de garanție;
· Service post-garanție.
Studiu- este studiul şi analiza structurii organizatorice a întreprinderii, a activităţilor acesteia şi sistemul existent procesarea informatiei.
Materialele obținute în urma sondajului sunt utilizate pentru:
Justificarea dezvoltării și implementării etapizate a sistemelor;
Întocmirea specificațiilor tehnice pentru dezvoltarea sistemelor;
Dezvoltarea proiectelor tehnice si de lucru ale sistemelor.
În stadiul anchetei, este recomandabil să distingem două componente: definirea strategiei de implementare a AIS și o analiză detaliată a activităților organizației.
Sarcina principală a primei etape a sondajului este de a evalua volumul real al proiectului, scopurile și obiectivele acestuia pe baza funcțiilor identificate și a elementelor informaționale ale obiectului automatizat de nivel înalt. Aceste sarcini pot fi implementate fie de către clientul AIS în mod independent, fie cu implicarea organizațiilor de consultanță. Această etapă implică o interacțiune strânsă cu principalii potențiali utilizatori ai sistemului și experții în afaceri. Sarcina principală a interacțiunii este de a obține o înțelegere completă și fără ambiguitate a cerințelor clientului. De obicei, informatie necesara pot fi obținute prin interviuri, conversații sau workshop-uri cu management, experți și utilizatori.
După finalizarea etapei de sondaj, devine posibilă determinarea abordărilor tehnice probabile pentru crearea sistemului și estimarea costurilor implementării acestuia (pentru hardware, pentru software achiziționat și pentru dezvoltarea de software nou).
Rezultatul etapei de definire a strategiei este un document (studiu de fezabilitate - studiu de fezabilitate - proiect), în care se formulează clar ce va primi clientul dacă este de acord să finanțeze proiectul, când primește produsul finit (programul de lucru) și cum mult va costa (pentru proiecte mari - acesta este programul de finanțare în diferite etape de lucru). Este de dorit să se reflecte în document nu numai costurile, ci și beneficiile proiectului, de exemplu, timpul de rambursare a proiectului, efectul economic așteptat (dacă poate fi estimat).
Limitări, riscuri, factori critici care pot afecta succesul proiectului;
Setul de condiții în care se presupune că va funcționa viitorul sistem - arhitectura sistemului, resursele hardware și software, condițiile de operare, personalul de service și utilizatorii sistemului;
Condiții de parcurgere a etapelor individuale, forma de acceptare/predare a lucrării, resursele implicate, măsurile de protecție a informațiilor;
Descrierea funcțiilor îndeplinite de sistem;
Oportunități de dezvoltare și modernizare a sistemului;
Interfețe și distribuție de funcții între o persoană și un sistem;
cerințe pentru software și sisteme de management al bazelor de date (DBMS).
În etapa unei analize detaliate a activităților organizației, sunt studiate activități care asigură implementarea funcțiilor de management, structura organizationala, personalul și conținutul lucrărilor privind managementul întreprinderii, precum și natura subordonării organelor superioare de conducere. Aici este necesar să se contureze materialele instructiv-metodologice și directive, pe baza cărora se determină componența subsistemelor și lista sarcinilor, precum și posibilitatea utilizării unor noi metode de rezolvare a problemelor.
Analiștii colectează și înregistrează informații în două forme interdependente:
Funcții - informații despre evenimente și procese care au loc în organizația automatizată;
Entități - Informații despre clasele de obiecte care sunt relevante pentru organizație și despre care datele sunt colectate.
La studierea fiecărei sarcini de control funcțional, se determină următoarele:
Numele sarcinii; termenii și frecvența deciziei sale;
Gradul de formalizabilitate a problemei;
Surse de informații necesare pentru rezolvarea problemei;
Indicatori și caracteristicile lor cantitative;
Procedura de corectare a informațiilor;
Algoritmi de operare pentru calcularea indicatorilor si posibile metode de control;
Mijloacele existente de colectare, transmitere și prelucrare a informațiilor;
Mijloacele de comunicare existente;
Acuratețea acceptată a soluției problemei;
Complexitatea rezolvării problemei;
Formele existente de prezentare a datelor inițiale și rezultatele prelucrării acestora sub formă de documente;
Consumatorii informațiilor rezultate cu privire la sarcină.
Una dintre sarcinile cele mai consumatoare de timp, deși bine formalizate, ale acestei etape este descrierea fluxului de lucru al organizației. La examinarea fluxului de lucru, se întocmește o diagramă a rutei de mișcare a documentelor, care ar trebui să reflecte:
Număr de documente;
Locul de formare a indicatorilor documentelor;
Interrelaţionarea documentelor în timpul formării lor;
Traseul și durata deplasării documentului;
Locul de utilizare și depozitare a acestui document;
Comunicatii interne si externe;
Volumul documentului în semne.
Pe baza rezultatelor sondajului, se stabilește o listă a sarcinilor de management I care urmează să fie automatizate, precum și succesiunea dezvoltării acestora.
În timpul fazei de sondaj, funcțiile planificate ale sistemului trebuie clasificate în funcție de importanța lor. Unul dintre formatele posibile pentru prezentarea unei astfel de clasificări este MuSCoW. Această abreviere înseamnă: Trebuie să aibă - funcții necesare; Ar trebui să aibă - funcțiile dorite; Ar putea avea - I posibile funcții; Nu va avea caracteristici lipsă.
Funcțiile din prima categorie oferă oportunități critice pentru funcționarea cu succes a sistemului. Implementarea funcțiilor categoriilor a doua și a treia este limitată de timpul și cadrul financiar: necesar, precum și maxim posibil, în ordinea priorităților, numărul de funcții din categoriile a doua și a treia. Ultima categorie de funcții este deosebit de importantă, deoarece este necesar să se înțeleagă clar limitele proiectului I și setul de funcții care vor lipsi în sistem.
Modelele de activitate organizațională sunt create în două tipuri 1:
Modelul „ca atare” reflectă procesele de afaceri existente în organizație;
Modelul „a fi” reflectă schimbările necesare în procesele de afaceri ținând cont de implementarea AIS. j
Deja în faza de analiză, este necesar să se implice grupul de testare în munca de rezolvare a următoarelor sarcini:
Obținerea de caracteristici comparative ale platformelor hardware, sistemelor de operare, DBMS etc.;
Elaborarea unui plan de lucru pentru a asigura fiabilitatea AIS și testarea acestuia.
Angajarea testerilor la începutul dezvoltării este o idee bună pentru orice proiect. Cu cât sunt descoperite mai târziu erori în soluțiile de proiectare, cu atât este mai costisitoare să le remediezi; cel mai rău caz este detectarea lor în faza de implementare. Astfel, cu cât echipele de testare încep să identifice mai devreme erorile în AIS, cu atât costul lucrului la sistem este mai mic. Timpul pentru testarea sistemului și pentru corectarea erorilor detectate ar trebui furnizat nu numai în etapa de dezvoltare, ci și în etapa de proiectare.
Sistemele speciale de urmărire a erorilor sunt concepute pentru a facilita și crește eficiența testării. Utilizarea lor vă permite să aveți un singur depozit de erori, să urmăriți reapariția acestora, să controlați viteza și eficiența remedierii erorilor, să vedeți cele mai instabile componente ale sistemului și, de asemenea, să mențineți comunicarea între echipa de dezvoltare și echipa de testare.
Rezultatele sondajului reprezintă o bază obiectivă pentru formarea specificațiilor tehnice pentru AIS.
Sarcina tehnică Este un document care definește obiectivele, cerințele și datele inițiale de bază necesare dezvoltării unui sistem de control automatizat.
La elaborarea unei sarcini tehnice (TOR), este necesar să se rezolve următoarele sarcini:
· Stabilirea scopului general al creării AIS;
· Stabilirea cerințelor generale pentru sistemul proiectat;
Dezvoltați și fundamentați cerințele de informații, matematice, software, tehnice și suport tehnologic;
· Să determine componenţa subsistemelor şi sarcinilor funcţionale;
· Dezvoltarea și fundamentarea cerințelor pentru subsisteme;
· Stabiliți etapele creării sistemului și momentul implementării acestora;
· Să efectueze un calcul preliminar al costurilor de creare a unui sistem și să determine nivelul de eficiență economică a implementării;
· Să determine componența interpreților.
| Capitol | Conţinut |
| Informatii generale | Numele complet al sistemului și simbolul acestuia. Cod subiect sau cod (număr) al contractului. Numele întreprinderilor dezvoltatorului și clientului sistemului, detaliile acestora. Lista documentelor pe baza cărora este creat IS. Date programate pentru începerea și sfârșitul lucrărilor. Informații despre sursele și procedura de finanțare a lucrării. Procedura de înregistrare și prezentare către client a rezultatelor lucrărilor privind crearea sistemului, părțile sale și mijloacele individuale |
| Scopul și scopurile creării (dezvoltării) sistemului | Tipul de activitate care trebuie automatizată. Lista obiectelor în care sistemul ar trebui să fie utilizat. Denumirile și valorile cerute ale indicatorilor tehnic, tehnologic, de producție-economic și de altă natură ai obiectului, care trebuie atinse la introducerea SI |
| Descrierea obiectelor de automatizare | Informații scurte despre obiectul de automatizare. Condiții de funcționare și informații de performanță mediu inconjurator |
| Cerințe de sistem | Cerințe pentru sistemul în ansamblu: cerințe pentru structura și funcționarea sistemului (lista de subsisteme, niveluri de ierarhie, grad de centralizare, metode de schimb de informații, moduri de funcționare, interacțiune cu sistemele adiacente, perspective de dezvoltare a sistemului). sistem); cerințe pentru personal (număr de utilizatori, calificări, ore de lucru, procedură de formare); indicatori de scop (gradul de adaptabilitate a sistemului la modificările proceselor de control și a valorilor parametrilor) cerințe de fiabilitate, siguranță, ergonomie, portabilitate, operare, întreținere și reparare, protecția și siguranța informațiilor, protecția împotriva influențelor externe, pentru puritatea brevetului, pentru standardizare și unificare. Cerințe pentru funcții (pe subsisteme): o listă de sarcini care trebuie automatizate; calendarul de implementare a fiecărei funcții; cerințe pentru calitatea implementării fiecărei funcții, pentru forma de prezentare a informațiilor de ieșire, caracteristicile de acuratețe, fiabilitatea rezultatelor; lista și criteriile de refuz. Cerințe pentru tipurile de suport: matematic (compoziția și sfera de aplicare a modelelor și metodelor matematice, algoritmi standard și dezvoltați); |
Cerințele tipice pentru compoziția și conținutul specificațiilor tehnice sunt date în tabel. 1.6.
Tablitsa 1.6. Compoziția și conținutul sarcinii tehnice (GOST 34.602-89)
| informaționale (compunerea, structura și organizarea datelor, schimbul de date între componentele sistemului, compatibilitatea informațiilor cu sistemele adiacente, clasificatoare utilizate, SGBD, controlul datelor și întreținerea matricelor de informații, proceduri de dare a efectului juridic documentelor de ieșire); lingvistice (limbaje de programare, limbaje de interacțiune a utilizatorului cu sistemul, sisteme de codare, limbaje de intrare-ieșire); software (independența software-ului față de platformă, calitatea software-ului și metodele de control al acestuia, utilizarea fondurilor de algoritmi și programe); tehnic; metrologice; organizatorice (structura și funcțiile unităților de operare, protecție împotriva acțiunilor eronate ale personalului); metodologic (compunerea documentației normative și tehnice) | |
| Compoziția și conținutul lucrărilor privind crearea sistemului | Lista etapelor și etapelor de lucru. Termenele limită. Componența organizațiilor care execută lucrări. Tipul și procedura de examinare a documentației tehnice. Program de asigurare a fiabilității. Program de sprijin metrologic |
| Controlul sistemului și procedura de acceptare | Tipuri, compoziție, domeniul de aplicare și metode de testare ale sistemului. Cerințe generale pentru recepția lucrărilor pe etape. Statutul comisiei de admitere |
| Cerințe pentru compoziția și conținutul lucrărilor de pregătire a obiectului de automatizare pentru punerea în funcțiune a sistemului | Conversia informațiilor de intrare într-o formă care poate fi citită de mașină. Modificări ale obiectului de automatizare. Termeni si procedura de recrutare si instruire a personalului |
| Cerințe de documentare | Lista documentelor care urmează a fi elaborate. Lista documentelor de pe suportul mașinii |
| Surse de dezvoltare | Documente și materiale informative pe baza cărora sunt dezvoltate TK și sistemul |
Proiect exclusiv prevede dezvoltarea de soluții preliminare de proiectare pentru sistem și piesele sale. Proiectarea preliminară nu este o etapă strict obligatorie. Dacă principalele soluții de proiectare sunt definite mai devreme sau sunt suficient de evidente pentru un anumit AIS și obiect de automatizare, atunci această etapă poate fi exclusă din succesiunea generală a lucrărilor.
funcții AIS;
Funcțiile subsistemelor, obiectivele acestora și efectul așteptat al implementării;
Componența seturi de sarcini și sarcini individuale;
Conceptul de bază de informații și structura sa extinsă;
Funcțiile sistemului de management al bazelor de date;
Compoziția unui sistem de calcul și a altor mijloace tehnice;
Funcțiile și parametrii software-ului principal.
Pe baza rezultatelor lucrărilor efectuate, documentația este întocmită, convenită și aprobată în cantitatea necesară pentru a descrie setul complet de decizii de proiectare adoptate și suficientă pentru lucrările ulterioare privind crearea sistemului.
În conformitate cu GOST 19.102-77, etapa de proiectare preliminară conține două etape: dezvoltarea unui proiect preliminar; aprobarea proiectului de proiect.
Prima etapă de dezvoltare constă în:
Dezvoltarea preliminară a structurii datelor de intrare și de ieșire;
Rafinarea metodelor de rezolvare a problemei;
Elaborarea unei descrieri generale a algoritmului de rezolvare a problemei;
Elaborarea unui studiu de fezabilitate;
Elaborarea unei note explicative.
În acest caz, este permisă combinarea și excluderea unor lucrări.
Mai jos este un set de documente care ar trebui și pot fi pregătite la sfârșitul designului schiței.
Documente obligatorii:
1) termeni de referință actualizați pentru proiectare și dezvoltare
munca AIS;
2) caietul de sarcini cerințe de calificare pe AIS;
3) un set de specificații de cerințe pentru componentele software funcționale și descrieri de date;
4) specificarea cerințelor pentru interfețele interne ale componentei și interfețele cu mediul extern;
5) o descriere a sistemului de management al bazei de date, structura și distribuția software-ului și a obiectelor informaționale din baza de date;
6) proiect de linii directoare pentru protecția informațiilor și asigurarea fiabilității funcționării AIS;
7) o versiune preliminară a manualului administratorului AIS;
8) o versiune preliminară a manualului de utilizare AIS;
9) un plan revizuit de implementare a proiectului;
10) plan rafinat de management al asigurării calității AIS;
11) nota explicativă a anteproiectului AIS;
12) un contract (acord) revizuit cu clientul pentru un detaliu
noul design al AIS.
Documente intocmite de comun acord cu clientul:
1) o descriere preliminară a funcționării AIS;
2) o diagramă a fluxurilor de date între componentele funcționale ale AIS;
3) o diagramă rafinată a arhitecturii AIS, interacțiunea componentelor software și informaționale, organizarea procesului de calcul și alocarea resurselor;
4) o descriere a indicatorilor de calitate ai componentelor și cerințele pentru aceștia pe etapele dezvoltării AIS;
5) raport privind indicatorii tehnici și economici, calendarul de implementare a proiectului, alocarea resurselor și buget;
6) un tabel de repartizare a specialiștilor pe componente și pe etape de lucru;
7) certificate ale dezvoltatorilor pentru dreptul de a utiliza tehnologia și instrumentele de automatizare pentru dezvoltarea AIS;
8) o descriere a cerințelor pentru alcătuirea și formele documentelor rezultate pe etape de lucru;
9) un plan de depanare a componentelor software, oferindu-i metode și instrumente de automatizare a testelor;
10) îndrumări preliminare pentru proiectarea detaliată
vaniya, programarea și depanarea componentelor AIS;
11) plan preliminar de vânzare și implementare;
12) o descriere a structurii preliminare a bazei de date.
Proiect tehnic sistemele sunt documentație tehnică care conține soluții de proiectare la nivelul întregului sistem, algoritmi pentru rezolvarea problemelor, precum și o evaluare a eficienței economice a AIS.În această etapă, se desfășoară un complex de cercetare și muncă experimentală pentru a selecta principalele soluții de proiectare și a calcula eficienta economica a sistemului. Compoziția și conținutul proiectului tehnic sunt date în tabel. 1.7
Tabelul 1.7. Conținutul proiectului tehnic
| Capitol | Conţinut |
| Notă explicativă | Baza dezvoltării sistemului. Lista organizațiilor de dezvoltatori. O scurtă descriere a obiectului, indicând principalii indicatori tehnici și economici ai funcționării acestuia și conexiunile cu alte obiecte. Scurte informații despre principalele soluții de proiectare pentru părțile funcționale și suport ale sistemului |
| Structura funcțională și organizatorică a sistemului | Justificarea subsistemelor alocate, lista și scopul acestora. Lista sarcinilor de rezolvat în fiecare subsistem, cu o scurtă descriere a conținutului acestora. Schema de legături de informații între subsisteme și între sarcini din cadrul fiecărui subsistem |
| Enunțarea problemei și algoritmi de rezolvare | Esența organizatorică și economică a problemei (numele, scopul soluției, rezumatul, metoda, frecvența și timpul de rezolvare a problemei, metode de colectare și transfer de date, legarea problemei cu alte probleme, natura utilizării rezultatelor soluţie în care sunt utilizate). Modelul economic și matematic al problemei (forma structurală și detaliată de prezentare). Introduceți informații operaționale (caracteristicile indicatorilor, gama de modificări, forme de prezentare). Informații de referință (INS) (formulare de conținut și de prezentare). Informații stocate pentru comunicarea cu alte sarcini. Informații acumulate pentru soluții ulterioare la această problemă. Schimbarea informațiilor (schimbarea sistemului și lista de informații care pot fi modificate). Algoritm de rezolvare a problemei (secvența etapelor de calcul, diagramă, formule de calcul). Caz de testare (un set de documente de intrare completate cu date, documente condiționate cu informații acumulate și stocate, formulare de ieșire completate pe baza rezultatelor rezolvării unei probleme economice și tehnice și în conformitate cu algoritmul de calcul dezvoltat) |
| Organizarea bazei de informații | Sursele de informare și metodele de transmitere a acesteia. Un set de indicatori utilizați în sistem. Componența documentelor, termenele și frecvența de primire a acestora. Soluții de proiectare de bază pentru organizarea fondului INS. Compoziția INS, inclusiv lista de detalii, definiția acestora, gama de modificări și lista documentelor INS. Lista seturi de date de date de referință, volumul acestora, ordinea și frecvența corectării informațiilor. Structura fondului INS cu o descriere a relației dintre elementele sale; cerințe pentru tehnologia de creare și întreținere a fondului. Metode de stocare, recuperare, modificare și control. Determinarea volumelor și fluxurilor de date de referință informaționale. Caz de testare pentru efectuarea de modificări la NSI. Propuneri de unificare a documentației |
| Album de formulare de documente | Dispărut |
| Sistem software | Justificarea structurii software-ului. Justificarea alegerii sistemului de programare. Lista de programe standard |
| Principiul construirii unui complex de mijloace tehnice | Descrierea și justificarea organigramei de prelucrare a datelor. Justificarea și alegerea structurii complexului de mijloace tehnice și a grupurilor sale funcționale. Justificarea cerințelor pentru dezvoltarea echipamentelor nestandardizate. Un set de măsuri pentru a asigura fiabilitatea funcționării mijloacelor tehnice |
| Calculul randamentului economic al sistemului | O estimare sumară a costurilor asociate cu funcționarea sistemelor. Calculul eficienței economice anuale, ale cărei surse sunt optimizarea structurii de producție a economiei (asociare), reducerea costului de producție datorită utilizării raționale a resurselor de producție și reducerea pierderilor, îmbunătățirea managementului. deciziile luate |
| Măsuri de pregătire a unității pentru implementarea sistemului | Lista măsurilor organizaționale pentru îmbunătățirea proceselor de afaceri. Lista lucrărilor privind implementarea sistemului care trebuie efectuate în etapa de proiectare detaliată, indicând timpul și persoanele responsabile |
| Lista documentelor | Dispărut |
La etapa „Documentație de lucru”, se creează un produs software și se dezvoltă toată documentația însoțitoare. Documentația trebuie să conțină toate informațiile necesare și suficiente pentru a asigura efectuarea lucrărilor de punere în funcțiune a AIS și de funcționare a acestuia, precum și pentru a menține nivelul caracteristicilor operaționale (calității) sistemului. Documentația elaborată trebuie să fie întocmită, agreată și aprobată corespunzător.
La etapa „Punere în funcțiune” pentru AIS se stabilesc următoarele tipuri principale de încercări: teste preliminare, teste de funcționare și de acceptare. Dacă este necesar, este permisă efectuarea suplimentară a altor tipuri de teste ale sistemului și ale părților sale.
În funcție de relația dintre componentele AIS și obiectul de automatizare, testele pot fi autonome și complexe. Componentele sistemului sunt implicate în testarea autonomă. Acestea sunt efectuate de îndată ce piesele sistemului sunt gata pentru punere în funcțiune. Testele complexe sunt efectuate pentru grupuri de componente interconectate (subsisteme) sau pentru sistem în ansamblu.
Pentru a planifica desfășurarea tuturor tipurilor de teste, este în curs de elaborare documentul „Program și Metodologie de testare”. Elaboratorul documentului este stabilit în contract sau TK. Testele sau cazurile de testare pot fi incluse în document ca atașament.
Depanarea este procesul de proiectare care consumă cel mai mult timp. Erorile ascunse apar uneori după mulți ani de funcționare a sistemului. Este imposibil să evitați complet erorile, ceea ce se datorează numărului astronomic de opțiuni pentru funcționarea sistemului. Este aproape imposibil să le verificați pe toate pentru funcționarea corectă în viitorul apropiat.
Costul identificării și eliminării erorilor în etapele ulterioare de proiectare crește aproximativ exponențial (Figura 1.10).
Cercetătorii numără 169 de tipuri de erori, rezumate în 19 clase mari:
1) logic;
2) erori de manipulare a datelor;
3) erori de intrare-ieșire;
4) erori de calcul;
Orez. 1.10. Costul relativ al detectării și remedierii unei singure erori
5) erori în interfețele utilizatorului;
6) erori în sistem de operareși programe auxiliare;
7) erori de layout;
8) erori în interfețele de interprogramare;
9) erori în interfețele „Program – software de sistem”;
10) erori la manipularea dispozitivelor externe;
11) erori de interfatare cu baza de date (DB);
12) erori de inițializare a bazei de date;
13) erori de modificari la cerere din exterior;
14) erori legate de variabile globale;
15) greșeli repetitive;
16) erori de documentare;
17) încălcarea cerințelor tehnice;
18) erori nerecunoscute;
19) erori de operator.
Nu toate erorile provin de la dezvoltator. Potrivit diverșilor cercetători, între 6 și 19% dintre erori sunt cauzate de erori în documentație.
Relația dintre dezvoltare și testare la diferite etape ale proiectării AIS este prezentată în Fig. 1.11.
Acest lanț este doar condiționat „întins” într-o linie. Există întotdeauna bucle recurente în interiorul ei. Pentru a identifica erorile, dezvoltatorii creează teste speciale și efectuează o etapă de depanare. Dacă nu se găsesc erori, asta nu înseamnă că nu există - poate că testul s-a dovedit a fi prea slab.
Orez. 1.11. Corelația între dezvoltare și testare pe etape de proiectare AIS
Metodologia de depanare ia în considerare simptomele posibile greșeli:
Procesare incorectă (răspuns greșit, rezultat) - până la 30%;
Transfer greșit al controlului - 16%;
Incompatibilitatea programelor cu datele utilizate - 15%;
Incompatibilitatea programelor pentru datele transmise - până la 9%.
La dezvoltarea sarcinilor de depanare, sunt rezolvate următoarele sarcini:
Teste de scriere;
Selectarea punctelor, zonelor și rutelor de control;
Stabilirea listei cantităților controlate și a procedurii de fixare a valorilor acestora;
Stabilirea ordinii de testare;
Evaluarea fiabilității și complexității depanării.
Programul care este depanat trebuie să lucreze cel puțin o dată prin fiecare ramură a algoritmului și, în același timp, să atribuie un număr de valori variabilelor, captând limitele intervalului, mai multe valori în cadrul acestuia, valori zero și puncte singulare (dacă există). Pentru sistemele specializate, sunt dezvoltate limbaje speciale de depanare. Ele pot conține un număr relativ mic de comenzi (20-30) cu parametri de reglare suplimentari pentru a rezolva următoarele sarcini:
Controlul retragerii;
Modelarea procesului de execuție a programului depanat;
Emiterea stării componentelor memoriei în timpul execuției programului;
Verificarea conditiilor de realizare a anumitor stari in procesul de executie a programului;
Stabilirea valorilor de testare ale datelor inițiale;
Implementarea de salturi condiționate în testare, în funcție de rezultatele execuției altor macro-uri sau diverse teste;
Efectuarea operațiunilor de service pentru pregătirea programului pentru testare.
Procesul de depanare nu poate fi clasificat ca pe deplin formalizat, prin urmare există recomandări empirice pentru desfășurarea acestuia, care sunt date mai jos.
1. Utilizați o abordare semantică și atentă a depanării, planificați procesul de depanare și proiectați cu atenție seturi de date de testare din cele mai simple opțiuni posibile, eliminând cele mai probabile surse de eroare.
2. Colectați și analizați informații pentru a eficientiza procesul de testare:
Caracteristici și statistici de eroare;
Despre specificul datelor inițiale și succesiunea variabilelor în schimbare în program și influența reciprocă a acestora;
Despre structura algoritmului și caracteristicile implementării software a acestuia.
3. Localizați o singură eroare la un moment dat.
Utilizați mijloacele de înregistrare și afișare a informațiilor despre erori, inclusiv în programul cod special de depanare pentru tipărirea valorilor eșantionului de variabile, mesaje despre sfârșitul secțiunilor individuale ale programului, urmărire, condiții logice etc.
5. Studiați cu atenție rezultatul rezultat și comparați-l cu rezultatele așteptate, precalculate.
6. Acordați atenție datelor, analizați cu atenție funcționarea programului atunci când utilizați valori limită și când introduceți incorect; controlați tipurile de date, intervalele, dimensiunile câmpurilor și precizia.
7. Utilizați analiza fluxului de date și analiza fluxului de control pentru a valida și a stabili sfera datelor pentru diferite rute de execuție a programului.
8. Folosiți diferite instrumente de depanare în același timp, fără a insista asupra unei singure posibilități. Utilizați instrumente automate și depanare și testare manuală în același timp, verificând performanța codului programului, ținând cont de erorile cele mai probabile.
9. Documentați orice erori găsite și remediate, diferențele, locația și tipul acestora. Aceste informații vor fi utile pentru a preveni erorile viitoare.
10. Măsurați complexitatea programelor. În programele cu complexitate ridicată, există o probabilitate mare de erori de specificație și proiectare, iar cu complexitate redusă - erori de codare și de scris.
11. Pentru a crește experiența și practica în depanare, plasați artificial erori în programe. După o anumită perioadă de depanare, programatorul ar trebui să semnaleze orice erori rămase pe care nu le-a găsit. O astfel de „însămânțare” este utilizată pe scară largă pentru a estima numărul de erori nedetectate (dacă atât erorile artificiale, cât și erorile reale sunt detectate și corectate uniform, atunci procentul de erori introduse introduse și erori reale poate fi folosit pentru a ghici câte dintre ele rămân).
Testele preliminare sunt efectuate pentru a determina operabilitatea sistemului și pentru a rezolva problema posibilității acceptării acestuia în funcționare de probă. Testele preliminare trebuie efectuate după ce dezvoltatorul a depanat și testat software-ul și hardware-ul furnizat sistemului și a transmis documentele relevante despre pregătirea lor pentru testare, precum și după familiarizarea personalului AIS cu documentația operațională.
Funcționarea de probă a sistemului este efectuată pentru a determina valorile reale ale caracteristicilor cantitative și calitative ale sistemului și gradul de pregătire a personalului de a lucra în condițiile de funcționare a acestuia, precum și pentru a determina eficiența reală și ajustarea. , dacă este necesar, documentația.
Testele de acceptare sunt efectuate pentru a determina conformitatea sistemului cu specificațiile tehnice, pentru a evalua calitatea funcționării de probă și pentru a rezolva problema posibilității de a accepta sistemul pentru funcționare permanentă.
Respectarea principiilor de mai sus este necesară atunci când se efectuează lucrări în toate etapele creării și funcționării AIS și AIT, de exemplu. de-a lungul întregului ciclu de viață al acestora.
Ciclu de viață(Cicul de viață) - perioada de creare și utilizare a AIS (AIT), începând din momentul în care apare necesitatea acestui sistem automatizat și terminând cu momentul retragerii acestuia din utilizare.
Ciclul de viață al AIS și AIT ne permite să distingem patru etape principale, fiecare etapă de proiectare este împărțită într-un număr de etape și asigură munca corespunzătoare:
Etapa I - inspecție înainte de proiect:
Etapa 1 - formarea cerințelor, studiul obiectului de proiectare, dezvoltarea și selectarea unei variante a conceptului de sistem;
Etapa a 2-a - analiza materialelor si formarea documentatiei - realizarea si aprobarea unui studiu de fezabilitate si specificatii tehnice pentru proiectarea sistemului pe baza analizei materialelor de sondaj colectate in prima etapa.
Etapa II - proiecta:
etapa 1 - proiectare tehnica, unde se efectuează căutarea celor mai raționale soluții de proiectare pentru toate aspectele dezvoltării, toate componentele sistemului sunt create și descrise, iar rezultatele lucrării sunt reflectate în proiectul tehnic;
a 2-a etapa - design detaliat,în procesul căruia se realizează elaborarea și perfecţionarea programelor, ajustarea structurilor bazei de date, crearea documentaţiei pentru furnizare, instalarea mijloacelor tehnice şi instrucţiunilor de funcţionare a acestora, întocmirea fişelor de post pentru fiecare utilizator. Proiectele tehnice și de lucru pot fi combinate într-un singur document - un proiect tehnic de lucru.
Etapa III - intrarea sistemului in actiune:
etapa 1 - pregătirea pentru implementare- instalarea și punerea în funcțiune a mijloacelor tehnice, încărcarea bazelor de date și operarea de probă a programelor, pregătirea personalului;
a 2-a etapa - testare pilot toate componentele sistemului înainte de transferul în exploatare industrială, pregătirea personalului;
Etapa a 3-a (etapa finală a creării AIS și AIT) - punerea în funcțiune comercială; se intocmeste prin acte de receptie si predare a lucrarilor.
Etapa IV - operare industriala - pe lângă operarea de zi cu zi, include întreținerea instrumentelor software și a întregului proiect, întreținerea operațională și administrarea bazei de date.
5. Metode de lucru de proiectare
Crearea sistemelor și tehnologiilor informatice automatizate poate fi realizată în două moduri. Prima opțiune presupune că această activitate este efectuată de firme specializate cu experiență profesională în pregătirea produselor software de o anumită orientare. Conform celei de-a doua opțiuni, proiectarea și crearea dezvoltărilor sunt realizate de designeri-programatori care fac parte din personalul întreprinderilor, unde sunt create noi tehnologii și sisteme informaționale.
În procesul de dezvoltare a sistemelor automate, a locurilor de muncă și a tehnologiilor, designerii se confruntă cu o serie de probleme interdependente:
Este dificil pentru un proiectant să obțină informații complete pentru a evalua cerințele pentru sistem nou sau tehnologie.
Adesea, clientul nu are suficiente cunoștințe despre problemele de automatizare pentru a evalua fezabilitatea implementării anumitor inovații. În același timp, proiectantul se confruntă cu o cantitate excesivă de informații detaliate despre zona problemei, ceea ce provoacă dificultăți în modelarea și descrierea oficială a proceselor informaționale și rezolvarea problemelor funcționale.
Datorită volumului mare și a termenilor tehnici, specificația sistemului care se proiectează este adesea de neînțeles pentru client, iar simplificarea excesivă a acestuia nu poate satisface specialiștii care realizează sistemul.
Cu ajutorul unor metode analitice binecunoscute, este posibil să se rezolve unele dintre problemele enumerate, totuși, o soluție radicală este oferită doar de metodele structurale moderne, printre care metodologia analizei structurale ocupă un loc central.
Analiză structurală se numește metoda de studiere a unui sistem, care începe cu privirea generală a acestuia și apoi detaliile, dobândind o structură ierarhică cu un număr tot mai mare de niveluri.
Analiza structurală presupune împărțirea sistemului în niveluri de abstractizare cu un număr limitat de elemente la fiecare dintre niveluri (de obicei de la 3 la 6-7). La fiecare nivel sunt evidențiate doar detaliile care sunt esențiale pentru sistem.
Metodologia analizei structurale se bazeaza pe principiile descompunerii si principiul ordonarii ierarhice.
Principiul de descompunere presupune rezolvarea unor probleme dificile prin descompunerea lor în probleme ușor de înțeles și rezolvat.
Principiul ordonării ierarhice declară că sistemul poate fi înțeles și construit în niveluri, fiecare dintre acestea adăugând noi detalii.
Pe etapa pre-proiect se efectuează un studiu și o analiză a tuturor caracteristicilor obiectului de design pentru a clarifica cerințele clientului. În special, este identificat un set de condiții în care se presupune că va funcționa viitorul sistem (resurse hardware și software; condiții externe de funcționare a acestuia; componența oamenilor și a muncii legate de acesta și participarea la procesele de informare și management), a descrierea funcțiilor îndeplinite de sistem etc. P.
În această etapă se determină următoarele:
Arhitectura sistemului, funcțiile sale, condițiile externe, distribuția funcțiilor între hardware și software;
Interfețe și distribuție de funcții între o persoană și un sistem;
Cerințe pentru componentele software și informaționale ale sistemului, resursele hardware necesare, cerințele pentru o bază de date, caracteristicile fizice ale componentelor sistemului, interfețele acestora.
Calitatea proiectării ulterioare depinde în mod decisiv de alegerea corectă a metodelor de analiză, de cerințele formulate pentru tehnologia nou creată.
Metodele utilizate în etapa de cercetare pre-proiect sunt împărțite în:
- Metode pentru studiul și analiza stării reale a unui obiect sau tehnologie. Aceste metode vă permit să identificați blocajele în procesele studiate și includ: întrebări orale sau scrise; chestionar scris; observare, măsurare și evaluare; discuție în grup; analiza sarcinilor; analiza proceselor de productie si management.
În general, metodele de studiu și analiză a stării actuale a activităților de management și a tehnologiei existente pentru rezolvarea problemelor sunt destinate să colecteze materialele necesare și să formeze baza pentru proiectarea AIS și AIT.
- Metode pentru generarea unei stări date. Acestea se bazează pe justificarea tuturor componentelor AIS pe baza obiectivelor, cerințelor și condițiilor clientului. Aceste metode, care sunt instrumente de lucru ale designerilor, includ metode: modelarea procesului de control; Design structural; descompunere; analiza procesului informaţional.
- Metoda de modelare a procesului de control.În procesul studierii obiectului de proiectare se construiesc modele economico-organizaționale și informațional-logice. Acestea reflectă relațiile de afaceri și de management, precum și fluxurile de informații asociate acestora.
- Metoda de proiectare structurală permite împărțirea întregului complex de sarcini în sub-complexe (module) vizibile și analizabile.
- Metoda de descompunere module prevede împărțirea în continuare a sub-seturi de sarcini în sarcini separate, indicatori.
- Analiza proceselor informaţionale este conceput pentru a identifica și reprezenta relația dintre rezultat, procesul de prelucrare și introducerea datelor. De asemenea, este folosit pentru a analiza și forma legături de informații între locurile de muncă ale lucrătorilor din conducere, specialiști, personal tehnic și tehnologia informației. În acest scop, sunt descrise informațiile de intrare și de ieșire, precum și algoritmul de procesare a informațiilor pentru fiecare loc de muncă.
- Metode de reprezentare grafică a stărilor reale și țintă prevede utilizarea unei reprezentări vizuale a proceselor de prelucrare a informațiilor. Cele mai cunoscute dintre ele includ metoda diagramei bloc, diagramele cu săgeți, diagramele de rețea, tabelele de flux de proces.
Dacă în etapa de pre-proiectare cerințele pentru crearea AIS și AIT trebuie formulate în termenii de referință, atunci proiectul trebuie să răspundă la întrebarea: „Cum va îndeplini sistemul cerințele pentru acesta?”
Ca urmare a etapelor de proiectare, ar trebui să se obțină un proiect de sistem în limita bugetului resurselor alocate.
Etapele de proiectare includ următoarele lucrări principale:
Dezvoltarea obiectivelor și principiilor organizatorice ale AIS;
Formarea unei versiuni de AIS și AIT;
Programe de depanare;
Operațiune de probă;
Livrarea proiectului AIS și AIT.
În procesul de organizare a designului, se iau o varietate de decizii care afectează dinamica și calitatea muncii. Așadar, pentru fiecare etapă de proiectare se determină: rezultatele și documentele așteptate; funcțiile personale ale capului; deciziile luate de șef; funcțiile clientului și dezvoltatorului AIS și AIT.
Documentația de proiectare și as-built include: instrucțiuni pentru procesele de lucru, programe pentru locurile de muncă, instrucțiuni pentru întocmirea documentelor, recomandări de utilizare a informațiilor, metode, tabele de decizie etc.
În condiții moderne, AIS, AIT și AWP, de regulă, nu sunt create de la zero. Nevoia de informații operaționale la timp, de înaltă calitate și evaluarea acesteia ca cea mai importantă resursă în procesele de management, precum și cele mai recente realizări ale progresului științific și tehnologic, necesită restructurarea AIS funcționale și crearea AIS și AIT pe noi baze tehnice si tehnologice.
Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați formularul de mai jos
Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.
postat pe http://www.allbest.ru/
Ministerul Educației și Științei al Federației Ruse
Bugetul Federal al Statului instituție educațională studii profesionale superioare
Universitatea de Stat de Tehnologie și Design din Sankt Petersburg
Lucru de curs
După disciplină: „Arhitectura sistemelor informaționale”
Pe tema: „Proiectarea sistemelor informatice automatizate”
INTRODUCERE
În prezent, tehnologia informatică devine din ce în ce mai răspândită atât în producție, cât și în fluxul de lucru al întreprinderilor, iar lista sarcinilor acoperite de aceasta devine din ce în ce mai largă. Volumul și complexitatea informațiilor procesate este în continuă creștere; sunt necesare toate tipurile noi de prezentare a acesteia.
Iată doar câteva dintre beneficiile utilizării computerului pentru o organizație:
* Posibilitatea controlului operațional asupra acurateței informațiilor;
* Reducerea numărului de erori posibile la generarea datelor derivate;
* Abilitatea de a accesa rapid orice date;
* Capacitatea de a genera rapid rapoarte;
* Economisirea costurilor cu forța de muncă și a timpului petrecut cu prelucrarea informațiilor.
Toate aceste avantaje sunt în prezent apreciate de multe organizații, prin urmare, astăzi există un proces de dezvoltare rapidă a sistemelor informatice automatizate și implementarea acestora în activitatea diferitelor instituții. În acest sens, tema pe care am ales-o este foarte relevantă în prezent.
Principala caracteristică a industriei sistemelor de automatizare pentru diverse întreprinderi și instituții, caracterizată printr-o gamă largă de date de intrare cu diverse rute pentru prelucrarea acestor date, este concentrarea complexității în etapele inițiale ale analizei cerințelor și proiectării specificațiilor sistemului cu relativ complexitatea redusă și laboriozitatea etapelor ulterioare. De fapt, aici are loc înțelegerea a ceea ce va face viitorul sistem și a modului în care va funcționa pentru a satisface cerințele impuse asupra acestuia. Și anume, neclaritatea și incompletitudinea cerințelor sistemului, problemele nerezolvate și greșelile făcute în etapele de analiză și proiectare dau naștere la probleme dificile, adesea de nerezolvat în etapele ulterioare și, în cele din urmă, duc la eșecul întregii lucrări în ansamblu. O simplă replicare chiar și a unui sistem de management al întreprinderii foarte bun nu se va potrivi niciodată pe deplin clientului, deoarece nu poate ține cont de specificul acestuia. Mai mult, în acest caz, se pune problema alegerii exacte a sistemului care este cel mai potrivit pentru o anumită întreprindere. Și această problemă este și mai complicată de faptul că cuvintele cheie care caracterizează diferite sisteme informaționale sunt practic aceleași:
* Mediul informațional unificat al întreprinderii;
* Modul în timp real;
* Independenta fata de legislatie;
* Integrare cu alte aplicații (inclusiv sisteme care funcționează deja la întreprindere);
* Implementare în etape etc.
De fapt, problema automatizării complexe a devenit relevantă pentru fiecare întreprindere. Și pentru a realiza automatizări complexe, aveți nevoie de cunoștințe structurate în acest domeniu.
Scopul acestei lucrări: Să se familiarizeze cu conceptul de sisteme informatice automatizate, să se ia în considerare procesul de proiectare.
Pentru a atinge obiectivul, este necesar să rezolvați următoarele sarcini:
§ Formularea unor definiţii ale conceptelor şi termenilor de bază;
§ Luați în considerare scopurile și obiectivele designului;
§ Familiarizarea cu principalele etape de proiectare;
§ Evidențierea fazelor de dezvoltare a sistemelor informatice automatizate;
§ Luați în considerare compoziția și structura sarcinii tehnice și a proiectului tehnic.
1. DEFINIREA CONCEPTELOR SISTEM INFORMATIC AUTOMAT (AIS), SISTEM INFORMATIC (IS), PROIECT ȘI DESIGN
La structurarea proceselor în domeniu activitate umana se folosesc diferite metode de separare a componentelor (subprocese) și se obțin rezultate diferite – precum cercetarea și dezvoltarea, analiza și sinteza etc.
Este destul de acceptabil să considerăm designul ca un concept generalizant pentru multe sarcini intelectuale care sunt rezolvate în procesul de gândire și se disting în moduri diferite.
Rădăcina cuvântului design subliniază legătura dintre procesul care are un astfel de nume și principalele rezultate ale acestui proces, după cum urmează:
a) proiecție - ceea ce se obține prin analizarea fenomenelor complexe pentru a obține reprezentări simplificate, și
b) proiect - ceea ce se obţine prin sintetizarea reprezentărilor complexe dintr-un set de imagini mai simple.
Cele două motive de mai sus au servit drept rațiune pentru alegerea actuală a cuvântului design ca termen care denotă esența acestuia. activitate principala, care se desfășoară în informatică.
În proiectarea sistemelor informaționale, sistemele informaționale sunt obiectele de proiectare, iar acest lucru este destul de firesc pentru informatică (deoarece SI sunt considerate obiectele sale principale).
După cum știți, sistemele informaționale sunt capabile să afișeze cele mai diverse fenomene ale universului și, prin urmare, toate fenomenele se dovedesc, de asemenea, a fi potențiale obiecte de proiectare.
Sistemele informaționale se dovedesc în multe cazuri a fi subiecte de proiectare, adică. acei executanți care realizează în sine procesul de proiectare. Prin studierea procesului de proiectare, suntem în mare măsură implicați în studiul sistemelor informaționale.
Un sistem este înțeles ca orice obiect care este considerat simultan atât ca un întreg, cât și ca un ansamblu de elemente eterogene combinate în interesul realizării scopurilor stabilite. Sistemele diferă semnificativ unele de altele atât în ceea ce privește compoziția, cât și în ceea ce privește obiectivele lor principale.
În informatică, conceptul de sistem este larg răspândit și are multe semnificații semantice. Cel mai adesea este folosit în legătură cu un set de hardware și software. Adăugarea la conceptul cuvântului sistem informațional reflectă scopul creării și funcționării acestuia. Sistemele informatice asigură colectarea, stocarea, prelucrarea, căutarea și livrarea informațiilor necesare în procesul de luare a deciziilor asupra problemelor din orice domeniu. Ele ajută la analiza problemelor și la crearea de produse noi.
Sistemul informațional (SI) este un set interconectat de instrumente, metode și personal utilizat pentru stocarea, procesarea și emiterea de informații în vederea atingerii scopului stabilit.
Tehnologiile informaționale moderne oferă o gamă largă de metode de implementare a IP, a căror alegere se bazează pe cerințele utilizatorilor vizați, care, de regulă, se modifică în timpul procesului de dezvoltare.
Adăugarea termenului „automatizat” la conceptul de „sistem” reflectă modalitățile de creare și funcționare a unui astfel de sistem.
Un sistem automatizat (conform GOST) este un sistem format dintr-un set interconectat de unități organizaționale și un set de instrumente de automatizare a activităților care implementează funcții automate pentru anumite tipuri Activități.
Un sistem informatic automatizat (AIS) este un complex de instrumente software, tehnice, informatice, lingvistice, organizatorice si tehnologice si personal, concepute pentru a rezolva problemele serviciilor de referinta si informatii si (sau) suport informativ pentru utilizatori.
Un sistem informatic automatizat este o colecție de informații, metode și modele economice și matematice, tehnici, software, instrumente tehnologice și specialiști menite să prelucreze informații și să ia decizii de management.
Scopul principal al sistemelor informatice automatizate este nu numai de a colecta și salva resursele electronice de informații, ci și de a oferi utilizatorilor acces la acestea. Una dintre cele mai importante caracteristici ale AIS este organizarea recuperării datelor în matricele lor de informații (baze de date).
Prin proiectul AIS ne referim la proiectare și documentație tehnologică, care oferă o descriere a soluțiilor de proiectare pentru crearea și funcționarea SI într-un mediu software și hardware specific.
Se pot distinge următoarele caracteristici distinctive principale ale proiectului ca obiect de management:
· Limitarea scopului final;
· Durată limitată;
· Buget limitat;
· Resurse limitate necesare;
· Noutate pentru intreprinderea pentru care se implementeaza proiectul;
· Complexitate;
· Suport juridic și organizatoric.
Având în vedere planificarea și managementul proiectelor, este necesar să înțelegem clar că vorbim despre managementul unui anumit obiect dinamic. Prin urmare, sistemul de management al proiectelor trebuie să fie suficient de flexibil pentru a permite posibilitatea modificării fără schimbări globale în program de lucru... Executarea lucrarilor este asigurata de disponibilitatea resurselor necesare: materiale; echipamente; resurse umane... Din punctul de vedere al teoriei sistemelor de control, proiectul ca obiect de control trebuie să fie observabil și gestionabil, adică se disting unele caracteristici prin care evoluția proiectului poate fi monitorizată constant. În plus, sunt necesare mecanisme care să influențeze progresul proiectului în timp util.
Proiectarea AIS este înțeleasă ca procesul de conversie a informațiilor de intrare despre un obiect, metode și experiență în proiectarea obiectelor cu un scop similar în conformitate cu GOST într-un proiect IS.
Din acest punct de vedere, proiectarea AIS se reduce la formalizarea secvenţială a soluţiilor de proiectare la diferite etape ale ciclului de viaţă AIS: planificarea şi analiza cerinţelor, proiectarea tehnică şi detaliată, implementarea şi operarea AIS.
Amploarea sistemelor dezvoltate determină compoziția și numărul de participanți la procesul de proiectare. Cu un volum mare și termene strânse pentru implementarea lucrărilor de proiectare, mai multe echipe de proiectare (organizații de dezvoltare) pot lua parte la dezvoltarea sistemului. În acest caz, este alocată organizația-mamă, care coordonează activitățile tuturor organizațiilor co-executoare.
Tehnologia de proiectare AIS este un set de metodologie și instrumente de proiectare pentru AIS, precum și metode și mijloace de organizare a acestuia (managementul procesului de creare și modernizare a unui proiect AIS).
Tehnologia de proiectare se bazează pe un proces tehnologic care determină acțiunile, succesiunea acestora, compoziția necesară a interpreților, mijloacele și resursele.
Procesul tehnologic de proiectare a AIS în ansamblu este împărțit într-un set de lanțuri de acțiuni secvenţial-paralele, conectate și subordonate, fiecare dintre acestea putând avea propriul subiect. Astfel, tehnologia de proiectare este stabilită de o succesiune reglementată de operațiuni tehnologice efectuate pe baza unei metode sau alteia, în urma căreia devine clar nu numai ce trebuie făcut pentru a crea un proiect, ci și cum, de către cine, și în ce ordine.
Subiectul oricărei tehnologii de proiectare alese ar trebui să fie reflectarea proceselor de proiectare interconectate în toate etapele ciclului de viață AIS. Principalele cerințe pentru tehnologia de proiectare selectată includ următoarele:
· Proiectul creat trebuie sa satisfaca cerintele clientului;
· Reflectare maximă a tuturor etapelor ciclului de viață al proiectului;
· Asigurarea costurilor minime de manopera si cost pentru proiectarea si intretinerea proiectului;
· Tehnologia ar trebui să fie baza comunicării între proiectare și sprijinul proiectului;
· Creșterea productivității proiectantului;
· Fiabilitatea proiectării și exploatării proiectului;
· Întreținerea simplă a documentației proiectului.
Tehnologia de proiectare AIS se bazează pe metodologia care definește esența, principalele caracteristici tehnologice distinctive.
O metodologie de proiectare presupune prezența unor concepte, principii de proiectare, implementate printr-un set de metode, care, la rândul lor, trebuie susținute prin unele mijloace.
Organizarea proiectării presupune determinarea metodelor de interacțiune între designeri și cu clientul în procesul de creare a unui proiect AIS, care poate fi susținut și de un set de instrumente specifice.
sistem informatic de proiectare asistată de calculator
2. SCOP ŞI OBIECTIVE DE PROIECTARE
Proiectarea sistemelor informatice începe întotdeauna cu definirea scopului proiectului. Scopul designului este selectarea suportului tehnic și formarea informațiilor, matematice, software și organizatorice și juridice.
Selectarea suportului tehnic ar trebui să fie astfel încât să asigure colectarea, înregistrarea, transferul, stocarea, completarea și prelucrarea în timp util a informațiilor.
Suportul informațional ar trebui să prevadă crearea și funcționarea unui singur fond de informații al sistemului, reprezentat de o varietate de matrice de informații, un set de date sau o bază de date.
Formarea suportului matematic al sistemelor include un set complet de metode și algoritmi pentru rezolvarea problemelor funcționale. La dezvoltarea sistemelor software, se acordă o atenție deosebită creării unui set de programe și instrucțiuni de utilizare și alegerii produselor software eficiente.
Sarcina principală a oricărui proiect de succes este să se asigure că la momentul lansării sistemului și pe toată durata funcționării acestuia, ar fi posibil să se asigure:
· Functionalitatea ceruta a sistemului si gradul de adaptare la conditiile schimbatoare ale functionarii acestuia;
· Debitul necesar al sistemului;
· Timpul de răspuns necesar al sistemului la cerere;
· Funcționarea fără probleme a sistemului în modul cerut, cu alte cuvinte - disponibilitatea și disponibilitatea sistemului de a procesa cererile utilizatorilor;
· Ușurință în operare și suport al sistemului;
· Securitate necesară.
Performanța este principalul factor determinant al eficienței sistemului. O soluție bună de proiectare formează baza unui sistem de înaltă performanță.
Proiectarea sistemelor informatice automatizate acoperă trei domenii principale:
· Proiectarea obiectelor de date care vor fi implementate în baza de date;
· Proiectarea de programe, ecrane, rapoarte care vor asigura executarea interogarilor la date;
· Luând în considerare un mediu sau o tehnologie specifică, și anume: topologia rețelei, configurația hardware, arhitectura utilizată (fișier-server sau client-server), procesare paralelă, prelucrare distribuită a datelor etc.
În condiții reale, proiectarea este căutarea unei metode care să îndeplinească cerințele funcționalității sistemului prin intermediul tehnologiilor disponibile, ținând cont de constrângerile date.
O serie de cerințe absolute sunt impuse oricărui proiect, de exemplu, timpul maxim de dezvoltare a proiectului, investiția financiară maximă în proiect etc. Una dintre dificultățile proiectării este că nu este o sarcină atât de structurată precum analiza cerințelor pentru un proiect sau implementarea unei anumite soluții de proiectare.
3. ETAPE DE PROIECTARE
Procesul de creare a AIS este împărțit într-un număr de etape (etape), limitate de un anumit interval de timp și care se termină cu lansarea unui anumit produs.
Fiecare proiect, indiferent de complexitatea și volumul de muncă necesar implementării lui, trece prin anumite stări în dezvoltarea sa. De la starea când „proiectul nu există încă” la starea când „proiectul nu mai există”. Setul de etape de dezvoltare de la apariția unei idei până la finalizarea completă a proiectului este de obicei împărțit în faze.
Scopul etapelor inițiale de creare a AIS, realizate în etapa de analiză a activităților organizației, este de a formula cerințe pentru AIS care să reflecte corect și cu acuratețe scopurile și obiectivele organizației client. Pentru a specifica procesul de creare a unui AIS care să răspundă nevoilor organizației, este necesar să se clarifice și să se articuleze clar care sunt aceste nevoi. Pentru a face acest lucru, este necesar să se determine cerințele clienților pentru AIS și să le mapeze în limbajul modelelor în cerințele pentru dezvoltarea proiectului AIS, astfel încât să se asigure conformitatea cu scopurile și obiectivele organizației.
Se pot distinge următoarele faze de dezvoltare a sistemelor informatice automatizate:
3.1 Formarea conceptului. Faza conceptuală
Aceasta include:
· Formarea ideii;
· Formarea unei echipe cheie de proiect;
· Studiul motivațiilor și cerințelor clientului și ale altor participanți;
· Colectarea datelor inițiale și analiza stării existente;
· Determinarea cerințelor și restricțiilor de bază, a resurselor materiale, financiare și de muncă necesare;
· Evaluarea comparativă a alternativelor;
· Depunerea propunerilor, examinarea și aprobarea acestora.
Sarcina de a forma cerințe pentru AIS este una dintre cele mai responsabile, greu de oficializat și cea mai costisitoare și dificil de corectat în caz de eroare. Instrumentele și produsele software moderne vă permit să creați rapid AIS conform cerințelor gata făcute. Dar adesea aceste sisteme nu satisfac clienții, necesită numeroase modificări, ceea ce duce la o creștere bruscă a costului costului real al AIS. Motivul principal pentru această situație este definirea incorectă, inexactă sau incompletă a cerințelor pentru AIS în etapa de analiză.
3.2 Întocmirea unei propuneri tehnice
§ dezvoltarea conţinutului principal al structurii de bază a proiectului;
§ elaborarea si aprobarea specificatiilor tehnice;
§ planificarea, descompunerea modelului structural de baza al proiectului;
§ intocmirea devizelor si bugetului proiectului;
§ dezvoltare planuri calendaristiceși program de lucru lărgit;
§ semnarea unui contract cu un client;
§ punerea în funcţiune a mijloacelor de comunicare ale participanţilor la proiect şi a mijloacelor de monitorizare a derulării lucrărilor.
3.3 Proiectare
În faza de proiectare, sunt determinate subsistemele, interrelațiile lor și sunt selectate cele mai eficiente modalități de proiectare și utilizare a resurselor. Lucrări caracteristice aceasta faza:
§ executarea lucrărilor de proiectare de bază;
§ elaborarea specificaţiilor tehnice private;
§ implementarea designului conceptual;
§ intocmirea specificatiilor si instructiunilor tehnice;
§ prezentarea dezvoltării, examinării și aprobării proiectării.
În etapa de proiectare, modelele de date sunt mai întâi formate. Designerii primesc rezultatele analizei ca intrare. Construirea modelelor de date logice și fizice este o parte esențială a proiectării bazei de date. Modelul informațional obținut în timpul analizei este mai întâi transformat într-un model de date logic și apoi într-un model de date fizic.
3.4 Dezvoltare
În faza de dezvoltare, se realizează coordonarea și controlul operațional al lucrărilor de proiect, subsistemele sunt fabricate, combinate și testate.
După ce testul autonom a fost trecut cu succes, modulul este inclus în partea dezvoltată a sistemului și un grup de module generate sunt supuse unor teste de comunicare, care ar trebui să urmărească influența lor reciprocă.
Mai mult, un grup de module este testat pentru fiabilitatea funcționării, adică trec, în primul rând, teste pentru a simula defecțiunile sistemului și, în al doilea rând, teste ale timpului de funcționare dintre defecțiuni. Primul grup de teste arată cât de bine se recuperează sistemul de la defecțiuni software, defecțiuni hardware. Al doilea grup de teste determină gradul de stabilitate a sistemului în timpul funcționării normale și vă permite să estimați timpul de funcționare al sistemului. Suita de teste de stabilitate ar trebui să includă teste care simulează sarcina maximă a sistemului.
Apoi, întregul set de module este supus unui test de sistem - un test intern de acceptare a produsului, care arată nivelul calității acestuia. Acestea includ teste de funcționalitate și teste de fiabilitate a sistemului.
Ultimul test al sistemului informatic automatizat este testele de acceptare. Un astfel de test presupune arătarea sistemului informațional către client și trebuie să conțină un grup de teste care simulează procese reale de afaceri.
3.5 Punerea în funcțiune a sistemului
În etapa de punere în funcțiune a sistemului se efectuează teste, sistemul este testat în condiții reale, se poartă negocieri asupra rezultatelor proiectului și asupra eventualelor noi contracte.
Principalele tipuri de munca:
§ teste complexe;
§ instruirea personalului pentru operarea sistemului în curs de creare;
§ intocmirea documentatiei de lucru, livrarea sistemului catre client si punerea in functiune a acestuia;
§ acompaniament, sprijin, serviciu;
§ evaluarea rezultatelor proiectului si intocmirea documentelor finale.
4. COMPOZIȚIA ȘI STRUCTURA SARCINII TEHNICE ȘI PROIECTAREA TEHNICĂ
1. Dispoziții generale
1.1. Termenii de referință (TOR) sunt documentul principal care definește cerințele și procedura pentru crearea (dezvoltarea sau modernizarea - crearea ulterioară) a sistemului informațional, în conformitate cu care se realizează dezvoltarea SI și acceptarea acestuia la punerea în funcțiune. .
1.2. TK este dezvoltat pentru întregul sistem, conceput pentru a funcționa independent sau ca parte a unui alt sistem.
1.3. Cerințe pentru IS în volumul stabilit de acest standard pot fi incluse în sarcina de proiectare a unui obiect de informatizare nou creat. În acest caz, TK-ul nu este dezvoltat.
1.4. Cerințele incluse în TK trebuie să corespundă nivelului actual de dezvoltare a tehnologiilor informaționale și să nu fie inferioare cerințelor similare pentru cei mai buni omologi moderni interni și străini. Cerințele stabilite în TK nu ar trebui să limiteze dezvoltatorul de sistem în găsirea și implementarea celor mai eficiente soluții tehnice, tehnice, economice și de altă natură.
1.5. TK include doar acele cerințe care completează cerințele pentru sisteme de acest tip și sunt determinate de specificul unui anumit obiect pentru care sistemul este creat.
1.6. Modificările la TK sunt întocmite printr-o completare sau un protocol semnat de client și dezvoltator. Suplimentul sau protocolul specificat este o parte integrantă a TK on IP. Pe pagina de titlu a TK ar trebui să existe o intrare „Valabil de la...”.
2. Compoziție și conținut
2.1. TK conține următoarele secțiuni, care pot fi împărțite în subsecțiuni:
1) informații generale;
2) scopul și scopurile creării (dezvoltării) sistemului;
3) caracteristicile obiectelor;
4) cerințe de sistem;
5) compoziția și conținutul lucrărilor privind crearea sistemului;
6) procedura de control și acceptare a sistemului;
7) cerințe pentru alcătuirea și conținutul lucrărilor privind pregătirea obiectului de dezvoltare pentru punerea în funcțiune a sistemului;
8) cerințe pentru documentare;
9) sursele de dezvoltare.
TK poate include aplicații.
2.2. În funcție de tipul, scopul, caracteristicile specifice ale proiectului și condițiile de funcționare a sistemului, este permisă oficializarea secțiunilor TK sub formă de aplicații, introducerea unor subsecțiuni suplimentare, excluderea sau combinarea TK.
TK pentru părți ale sistemului nu include secțiuni care dublează conținutul secțiunilor TK ca întreg.
2.3. În secțiunea „Informații generale” indicați:
1) numele complet al sistemului și simbolul acestuia;
2) codul temei sau codul (numărul) contractului;
3) numele companiilor dezvoltatorului și clientului (utilizatorului) sistemului și detaliile acestora;
4) o listă a documentelor pe baza cărora este creat sistemul, de către cine și când au fost aprobate aceste documente;
5) datele de început și de încheiere planificate pentru crearea sistemului;
6) informatii despre sursele si procedura de finantare a lucrarii;
7) procedura de înregistrare și prezentare către client a rezultatelor lucrărilor privind crearea sistemului (părțile sale), privind fabricarea și reglarea mijloacelor individuale (hardware, software, informații) și software și hardware (software și metodologic ) sistemele sistemului.
2.4. Secțiunea „Scopul și obiectivele creării (dezvoltării) sistemului” este formată din subsecțiuni:
1) scopul sistemului;
2) scopul creării sistemului.
2.4.1. În subsecțiunea „Scopul sistemului” indicați tipul de activitate a sistemului (management, proiectare etc.) și lista obiectelor de informatizare (obiecte) pe care se presupune că este utilizat.
2.4.2. În subsecțiunea „Obiectivele creării sistemului” sunt date denumirile și valorile cerute ale indicatorilor tehnici, tehnologici, de producție-economici sau de altă natură ai obiectului informatizării, care trebuie realizate ca urmare a creării SI. , iar criteriile de evaluare a realizării obiectivelor de realizare a sistemului sunt indicate.
2.5. În secțiunea „Caracteristicile obiectului de informatizare” se menționează:
1) informatie scurta despre obiectul informatizarii sau legaturi catre documente care contin astfel de informatii;
2) informații despre condițiile de funcționare ale obiectului de automatizare.
2.6. Secțiunea Cerințe de sistem este formată din următoarele subsecțiuni:
1) cerințe pentru sistem în ansamblu;
2) cerinţele pentru funcţiile (sarcinile) îndeplinite de sistem;
3) cerințe pentru tipurile de securitate.
Compoziția cerințelor pentru sistem, incluse în această secțiune a TK pentru IS, este stabilită în funcție de tipul, scopul, caracteristicile specifice și condițiile de funcționare a unui anumit sistem.
2.6.1. În subsecțiunea „Cerințe pentru sistem în ansamblu” indicați:
cerințe pentru structura și funcționarea sistemului;
cerințe privind numărul și calificările personalului din sistem și modul de lucru al acestora;
indicatori de destinație;
cerințe de fiabilitate;
cerințe de siguranță;
cerințe de ergonomie și estetică tehnică;
cerințe pentru operarea, întreținerea, repararea și depozitarea componentelor sistemului;
cerințe pentru protecția informațiilor împotriva accesului neautorizat;
cerințe pentru siguranța informațiilor în caz de accidente;
cerințe de protecție împotriva influențelor externe;
cerințe pentru puritatea brevetului;
cerințe pentru standardizare și unificare;
Cerințe suplimentare.
2.6.1.1. Cerințele pentru structura și funcționarea sistemului includ:
1) o listă de subsisteme, scopul și caracteristicile de bază ale acestora, cerințele pentru numărul de niveluri de ierarhie și gradul de centralizare a sistemului;
2) cerințe pentru metode și mijloace de comunicare pentru schimbul de informații între componentele sistemului;
3) cerințe privind caracteristicile interconexiunilor sistemului care se creează cu sisteme adiacente, cerințe pentru compatibilitatea acestuia, inclusiv instrucțiuni privind modul de schimb de informații (automat, prin trimiterea de documente, prin telefon etc.);
4) cerințe pentru modurile de funcționare ale sistemului;
5) cerințe pentru diagnosticarea sistemului;
6) perspective de dezvoltare, modernizare a sistemului.
2.6.1.2. Cerințele pentru numărul și calificările personalului IS includ:
§ cerințe privind numărul de personal (utilizatori) IS;
§ cerințe pentru calificarea personalului, procedura de pregătire a acestuia și controlul cunoștințelor și aptitudinilor;
§ modul de operare necesar al personalului IS.
2.6.1.3. În cerințele pentru indicatorii scopului SI sunt date valorile parametrilor care caracterizează gradul de conformitate a sistemului cu scopul său.
2.6.1.4. Cerințele de fiabilitate includ:
1) compoziția și valorile cantitative ale indicatorilor de fiabilitate pentru sistemul în ansamblu sau subsistemele acestuia;
2) o listă a situațiilor de urgență pentru care trebuie reglementate cerințe de fiabilitate și valorile indicatorilor corespunzători;
3) cerințe pentru fiabilitatea hardware și software;
4) cerințe pentru metodele de evaluare și monitorizare a indicatorilor de fiabilitate în diferite etape ale creării sistemului în conformitate cu documentele de reglementare și tehnice actuale.
2.6.1.5. Cerințele de siguranță includ cerințe pentru asigurarea siguranței în timpul livrării, punerii în funcțiune, exploatării și întreținerii sistemului.
2.6.1.6. Cerințele pentru ergonomie și estetică tehnică includ indicatori IP care stabilesc calitatea cerută interacţiunea om-maşină şi confortul condiţiilor de muncă ale personalului.
2.6.1.7. Cerințele pentru protejarea informațiilor împotriva accesului neautorizat includ cerințele stabilite de industrie și mediul informațional al clientului.
2.6.1.8. În cerințele privind siguranța informațiilor se dă o listă de evenimente: accidente, defecțiuni ale mijloacelor tehnice (inclusiv pierderea puterii) etc., în care trebuie asigurată siguranța informațiilor din sistem.
2.6.1.9. Cerințele privind puritatea brevetului indică o listă de țări pentru care trebuie asigurată puritatea brevetului a sistemului și a părților acestuia.
2.6.1.10. Cerințele suplimentare includ cerințe speciale, la discreția dezvoltatorului sau clientului sistemului.
2.6.2. În subsecțiunea „Cerințe pentru funcțiile (sarcinile)” îndeplinite de sistem, sunt date următoarele:
§ pentru fiecare subsistem, o listă de funcții, sarcini sau complexe ale acestora (inclusiv cele care asigură interacțiunea unor părți ale sistemului) care urmează să fie automatizate;
§ la crearea unui sistem în două sau mai multe cozi - o listă de subsisteme funcționale, funcții individuale sau sarcini care sunt puse în funcțiune în fazele 1 și ulterioare;
§ calendarul de implementare a fiecărei funcții, sarcini (sau set de sarcini);
§ cerințe pentru calitatea implementării fiecărei funcții (sarcină sau complex de sarcini), pentru forma de prezentare a informațiilor de ieșire, caracteristici ale preciziei și timpului de execuție necesar, cerințe pentru îndeplinirea simultană a unui grup de funcții, fiabilitatea rezultatele;
§ o listă și criterii de defecțiuni pentru fiecare funcție pentru care sunt stabilite cerințe de fiabilitate.
2.6.3. În subsecțiunea „Cerințe pentru tipurile de suport”, în funcție de tipul de sistem, sunt date cerințe pentru suportul de sistem matematic, informațional, lingvistic, software, tehnic, metrologic, organizatoric, metodologic și de altă natură.
2.6.3.2. Pentru sprijinul informativ al sistemului, sunt date următoarele cerințe:
1) la componența, structura și metodele de organizare a datelor în sistem;
2) la schimbul de informații între componentele sistemului;
3) compatibilitatea informaţiei cu sistemele aferente;
4) privind aplicarea sistemelor de management al bazelor de date;
5) la structura procesului de colectare, prelucrare, transfer de date în sistem și prezentare a datelor;
6) la protecția datelor;
7) controlul, stocarea, actualizarea și recuperarea datelor;
2.6.3.3. Pentru suportul lingvistic al sistemului, sunt date cerințe pentru utilizarea limbajelor de programare la nivel înalt în sistem, limbaje pentru interacțiunea dintre utilizatori și mijloacele tehnice ale sistemului, precum și cerințe pentru codificarea și decodarea datelor, pentru limbaje de intrare-ieșire a datelor, limbaje de manipulare a datelor, mijloace pentru descrierea domeniului subiectului, pentru metode de organizare a unui dialog.
2.6.3.4. Pentru software-ul sistemului, se oferă o listă de software achiziționat, precum și cerințele:
1) la dependența software-ului de mediul de operare;
2) la calitatea software-ului, precum și la modalitățile de furnizare și control al acestuia;
2.6.3.5. Pentru suportul tehnic al sistemului, sunt date următoarele cerințe:
1) la tipurile de mijloace tehnice, inclusiv la tipurile de complexe de mijloace tehnice, complexe software și hardware și alte componente, admisibile pentru utilizare în sistem;
2) la caracteristicile funcționale, de proiectare și operaționale ale suportului tehnic al sistemului.
2.6.3.6. Cerințele pentru suport metrologic includ:
1) o listă preliminară a canalelor de măsurare;
2) cerințe pentru acuratețea măsurătorilor parametrilor și (sau) pentru caracteristicile metrologice ale canalelor de măsurare;
3) cerințe pentru compatibilitatea metrologică a mijloacelor tehnice ale sistemului;
4) o listă a canalelor de control și de calcul ale sistemului pentru care este necesară evaluarea caracteristicilor de precizie;
5) cerințe pentru suportul metrologic al hardware-ului și software-ului care fac parte din canalele de măsurare ale sistemului, mijloacele, controlul încorporat, adecvarea metrologică a canalelor de măsurare și instrumentele de măsurare utilizate la configurarea și testarea sistemului;
6) tipul de certificare metrologică (de stat sau departamentală) cu indicarea procedurii de implementare a acesteia și a organizațiilor care efectuează certificarea.
2.6.3.7. Pentru sprijinul organizațional, sunt date cerințele:
1) la structura și funcțiile diviziilor care participă la funcționarea sistemului sau care asigură funcționarea;
2) la organizarea funcționării sistemului și a ordinii de interacțiune între personalul SI și personalul obiectului de informatizare;
3) pentru a proteja împotriva acțiunilor eronate ale personalului sistemului.
2.7. Secțiunea „Compoziția și conținutul lucrării privind crearea (dezvoltarea) sistemului” trebuie să conțină o listă a etapelor și etapelor de lucru privind crearea sistemului, momentul implementării acestora, o listă a organizațiilor - executorii lucrării. , link-uri către documente care confirmă acordul acestor organizații de a participa la crearea sistemului, sau o înregistrare care identifică persoana responsabilă (client sau dezvoltator) pentru realizarea acestor lucrări.
V aceasta sectiune citeaza si:
1) o listă a documentelor prezentate la finalul etapelor și etapelor de lucru relevante;
2) tipul și procedura de examinare a documentației tehnice (etapa, etapa, volumul documentației verificate, organizarea de experți);
3) un program de lucru care vizează asigurarea nivelului necesar de fiabilitate a sistemului în curs de dezvoltare (dacă este necesar);
4) o listă a lucrărilor privind suportul metrologic în toate etapele de realizare a sistemului, cu indicarea termenelor limită ale acestora și a organizațiilor de execuție (dacă este cazul).
2.8. În secțiunea „Procedura de control și acceptare a sistemului” indicați:
1) tipurile, compoziția, domeniul de aplicare și metodele de testare ale sistemului și ale componentelor acestuia;
2) cerințe generale pentru recepția lucrărilor pe etape, procedura de coordonare și aprobare a documentației de recepție;
2.9. În secțiunea „Cerințe pentru compoziția și conținutul lucrărilor privind pregătirea obiectului de automatizare pentru punerea în funcțiune a sistemului”, este necesar să se furnizeze o listă a activităților principale și a executanților acestora, care ar trebui efectuate la pregătirea proiectului. pentru punerea în funcţiune a SI.
Lista activităților principale include:
1) aducerea informațiilor care intră în sistem (în conformitate cu cerințele de informare și suport lingvistic);
2) crearea condițiilor de funcționare a proiectului, în care să fie garantată conformitatea sistemului creat cu cerințele cuprinse în TOR;
3) crearea de subdiviziuni și servicii necesare funcționării sistemului;
4) calendarul și procedura pentru personalul și formarea personalului.
2.10. În secțiunea „Cerințe pentru documentare”, sunt date următoarele:
1) o listă de seturi și tipuri de documente care urmează să fie elaborate, agreate de dezvoltatorul și Clientul sistemului;
2) o listă de documente emise pe suportul mașinii;
3) în lipsă standardele de stat care determină cerințele pentru documentarea elementelor sistemului, includ în plus cerințe pentru compoziția și conținutul acestor documente.
2.11. Secțiunea „Surse de dezvoltare” ar trebui să enumere documentele și materialele informative pe baza cărora au fost elaborate TK și care ar trebui utilizate la crearea sistemului.
3. Reguli de proiectare.
3.1. Secțiunile și subsecțiunile din TK ar trebui plasate în ordinea stabilită în secțiune. 2 din acest standard.
3.2. Numerele foilor (paginilor) se pun, începând de la prima foaie care urmează paginii de titlu, în partea de sus a foii (deasupra textului, la mijloc) după desemnarea codului TK pe IP.
3.3. Pagina de titlu conține semnăturile clientului, dezvoltatorului și companiilor de aprobare, care sunt sigilate. Dacă este necesar, pagina de titlu este întocmită pe mai multe pagini. Semnăturile dezvoltatorilor de TK și ale oficialilor care participă la aprobarea și examinarea proiectului de TK pe IP sunt plasate pe ultima foaie.
Forma paginii de titlu a TK este prezentată în Anexa 2. Forma ultimei pagini a TK este dată în Anexa 3.
3.4. Pagina de titlu a suplimentului la TK este întocmită în același mod ca pagina de titlu a sarcinii tehnice. În locul denumirii „Termeni de referință” se scrie „Suplimentul nr. ... la TOR pentru AC ...”.
3.5. Pe foile ulterioare ale adăugării la TK sunt plasate baza modificării, conținutul modificării și link-urile către documente, în conformitate cu care sunt efectuate aceste modificări.
3.6. Atunci când se prezintă textul unui addendum la TK, trebuie indicate numerele clauzelor, subclauzelor, tabelelor principalelor TK etc. și cuvintele „înlocuiește”, „suplimentează”, „exclude”, „reformulat”. " ar trebui folosit.
Procedura pentru dezvoltarea, coordonarea și aprobarea TK pentru IS.
1. Proiectul TK este elaborat de organizația-dezvoltatorul sistemului cu participarea clientului pe baza cerințelor tehnice (aplicații, specificații tactice și tehnice etc.).
În organizarea competitivă a muncii, opțiunile pentru proiectul TK sunt luate în considerare de către client, care fie alege opțiunea preferată, fie pe baza unei analize comparative pregătește, cu participarea viitorului dezvoltator IS, versiunea finală a TK pentru AC.
2. Necesitatea aprobării proiectului de TK cu autoritățile de supraveghere de stat și cu alte organizații interesate este determinată în comun de clientul sistemului și dezvoltatorul proiectului de TK pe IS,
Lucrările privind aprobarea proiectului de TK pentru SI sunt realizate în comun de dezvoltatorul TK și de clientul sistemului, fiecare în organizațiile ministerului său (departamentul).
3. Termenul de aprobare a proiectului de TK în fiecare organizație nu trebuie să depășească 15 zile de la data primirii acestuia. Se recomandă să trimiteți copii ale proiectului TK (copii) simultan către toate organizațiile (departamentele) pentru aprobare.
4. Comentariile cu privire la proiectul de mandat trebuie prezentate cu o justificare tehnică. Deciziile cu privire la comentarii ar trebui luate de către dezvoltatorul proiectului TK și clientul sistemului înainte de aprobarea TK pe IS.
5. Dacă, la acordul asupra proiectului TK, au apărut neînțelegeri între dezvoltator și client (sau alte organizații interesate), atunci se întocmește un protocol de neînțelegeri (formă arbitrară) și se ia o decizie specifică în modul prescris.
6. Aprobarea proiectului de TK este permisă întocmirea unui document separat (scrisoare). În acest caz, la rubrica „De acord” faceți o referire la acest document.
7. Aprobarea TK este efectuată de șefii companiilor dezvoltatorului și clientului sistemului.
8. Copii ale TK-ului aprobat în termen de 10 zile de la aprobare sunt trimise de către dezvoltatorul TK-ului participanților la crearea sistemului.
9. Coordonarea și aprobarea completărilor la TK se realizează în modul prescris pentru TK pe IS.
10. Modificările aduse TK nu pot fi aprobate după depunerea sistemului sau la coada acestuia pentru testele de acceptare.
Baza dezvoltării proiectului tehnic al sistemului este atribuirea tehnică aprobată de client.
Proiectarea tehnică a sistemului este documentația tehnică aprobată în modul prescris, care conține soluții de proiectare la nivelul întregului sistem, un algoritm pentru rezolvarea problemelor, precum și o evaluare a eficienței economice a unui sistem de control automat și o listă de măsuri de pregătire. facilitatea de implementare.
Proiectul tehnic este în curs de elaborare pentru a determina principalele soluții de proiectare pentru realizarea sistemului. În această etapă, se efectuează un complex de cercetări și lucrări experimentale pentru selectarea celor mai bune soluții, se efectuează verificarea experimentală a principalelor soluții de proiectare și calculul eficienței economice a sistemului.
De fapt, proiectul tehnic conține un complex de modele economice, matematice și algoritmice.
Un set complet de proiectare tehnică pentru sistem include 10 documente:
1. Notă explicativă.
2. Structura funcțională și organizatorică a sistemului.
3. Enunțarea problemei și algoritmul de rezolvare.
4. Organizarea bazei de informații.
5. Album de formulare de documente.
6. Sistem software.
7. Principiul construirii unui complex de mijloace tehnice.
8. Calculul randamentului economic al sistemului.
9. Măsuri de pregătire a unității pentru implementarea sistemului.
10. Lista documentelor.
Din lista de mai sus, documentul 3 „Enunțarea sarcinilor și algoritmul de rezolvare” este realizat pentru fiecare sarcină individuală inclusă în EIS, restul documentelor sunt comune pentru întregul sistem. În plus, documentele 1, 2, 5, 8 și 9 pot fi dezvoltate pentru subsisteme individuale.
Toate documentele enumerate pot fi grupate și prezentate sub forma a patru părți principale ale unui proiect tehnic: economico-organizațional, informațional, matematic, tehnic.
Partea economică și organizatorică a proiectului tehnic conține o notă explicativă care justifică dezvoltarea sistemului, o listă a organizațiilor dezvoltatorilor, o scurtă descriere a obiectului care indică principalii indicatori tehnico-economici ai funcționării acestuia și legăturile cu alte obiecte, un scurt informații despre principalele soluții de proiectare pentru părțile funcționale și suport ale sistemului.
In sectiunea proiectului tehnic dedicata organizatoric si structură funcțională sisteme, având în vedere: justificarea subsistemelor alocate, lista și scopul acestora; o listă de sarcini de rezolvat în fiecare subsistem, cu o scurtă descriere a conținutului acestora; o diagramă a legăturilor de informații între subsisteme și între sarcini din cadrul fiecărui subsistem.
Pentru fiecare sarcină inclusă în setul de sarcini prioritare se execută enunțul acesteia și algoritmul de rezolvare a acesteia. Această secțiune a proiectului tehnic include:
§ esența organizatorică și economică a problemei (denumirea, scopul soluției, rezumatul, metoda, frecvența și timpul de rezolvare a problemei, metodele de colectare și transfer de date, legarea problemei cu alte probleme, natura utilizării rezultatelor soluția în care sunt utilizate);
§ modelul economic şi matematic al problemei (forma structurală şi detaliată de prezentare);
§ introducerea informațiilor operaționale (caracteristicile indicatorilor, semnificația acestora și gama de modificare, forme de prezentare);
§ informatii de referinta normative (INS) - continutul si formele de prezentare;
§ informatii stocate pentru comunicarea cu alte sarcini;
§ informatii acumulate pentru solutii ulterioare la aceasta problema;
§ informații privind efectuarea modificărilor (sistem de efectuare a modificărilor și o listă de informații supuse modificărilor);
§ algoritm de rezolvare a problemei (secventa etapelor de calcul, diagrama, formule de calcul);
§ caz de testare (un set de formulare de documente de intrare completate cu date, documente condiționate cu informații acumulate și stocate, formulare de documente de ieșire completate pe baza rezultatelor rezolvării unei probleme economice și tehnice și în conformitate cu algoritmul de calcul elaborat).
Documentul „Calculul eficienței economice a sistemului” conține o estimare sumară a costurilor asociate cu funcționarea sistemelor, calculul eficienței economice anuale, ale căror surse sunt optimizarea structurii de producție a economiei ( asociere), deciziile de conducere.
Documentul „Măsuri de pregătire a instalației pentru implementarea sistemului” conține o listă de măsuri organizatorice pentru îmbunătățirea structurii de management existentă, o listă de lucrări privind implementarea sistemului care trebuie efectuate în etapa de proiectare detaliată, indicând timpul și persoanele responsabile.
Partea informaţională a proiectului tehnic reuneşte documentele 4 şi 5. Documentul „Organizarea bazei informaţionale” reflectă: sursele de informare şi metodele de transmitere a acesteia pentru rezolvarea complexului primar de sarcini funcţionale; un set de indicatori utilizați în sistem; alcătuirea documentelor, termenele și frecvența de primire a acestora; soluții de bază de proiectare pentru organizarea fondului INS; componența INS, inclusiv lista de detalii, definiția acestora, semnificația, gama de modificări și lista documentelor INS; lista seturi de date de date de referință, volumul acestora, ordinea și frecvența corectării informațiilor; propuneri de unificare a documentației, un caz de testare pentru modificarea INS; forma structurală a INS cu o descriere a relației dintre elemente; cerințe pentru tehnologia de creare și menținere a unui fond; metode de stocare, căutare, modificare și control, determinarea volumelor și fluxurilor de informații ale datelor de referință.
„Albumul de formulare de documente” conține forme de date de referință.
Partea matematică a proiectului tehnic conține justificarea structurii software-ului, rațiunea alegerii unui sistem de programare, inclusiv o listă de programe standard.
Partea tehnică a proiectului tehnic include: descrierea și justificarea diagramei procesului de prelucrare a datelor tehnice; justificarea cerințelor pentru dezvoltarea echipamentelor nestandardizate; fundamentarea și alegerea structurii complexului de mijloace tehnice și a grupurilor sale funcționale; un set de măsuri care să asigure fiabilitatea funcționării mijloacelor tehnice.
CONCLUZIE
Dezvoltarea unui sistem informatic, de regulă, se realizează pentru o întreprindere foarte specifică. Specificul activității subiectului întreprinderii, desigur, afectează structura sistemului informațional, dar, în același timp, structurile diferitelor întreprinderi sunt în general similare între ele. Fiecare organizație, indiferent de tipul său de activitate, este formată dintr-un număr de divizii care desfășoară direct unul sau altul tip de activitate a companiei, iar această situație este valabilă pentru aproape toate organizațiile, indiferent de tipul de activitate în care sunt angajate.
Introducerea tehnologiilor informaționale moderne face posibilă reducerea timpului necesar pentru pregătirea proiectelor specifice de marketing și producție, reducerea costurilor neproductive în timpul implementării acestora, eliminarea posibilității erorilor în pregătirea documentației contabile, tehnologice și de altă natură. , care conferă unei societăți comerciale un efect economic direct.
Desigur, pentru a dezvălui toate posibilitățile potențiale pe care le presupune utilizarea computerelor, este necesar să se folosească în munca lor un set de instrumente software și hardware care se potrivesc cel mai bine sarcinilor stabilite. De aceea, in prezent, exista o mare nevoie a societatilor comerciale de programe informatice care sa sustina munca conducerii firmei, precum si de informatii despre modul de utilizare optima a echipamentelor informatice de care dispune firma.
Implementarea designului AIS presupune utilizarea unei anumite tehnologii de proiectare de către proiectanți, corespunzătoare amplorii și caracteristicilor proiectului în curs de dezvoltare.
LISTA LITERATURII UTILIZATE
1. Orientări pentru studiul disciplinei „Sisteme informatice automatizate” [Resursa electronică]. - Moscova, 2006. - Mod de acces:
http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Titlu. de pe ecran.
2. Wikipedia, enciclopedia liberă [Resursa electronică] / Articolul „Sistem informațional” - Mod de acces: http://ru.wikipedia.org/wiki/Sistem informațional.
3. Presa de calculator: revista de internet. - Electron. Dan. - [B.m., 2001]. - Mod de acces: http://compress.ru/article.aspx?id=12282.
4. Vendrov AM, „Proiectare software pentru sisteme informaționale economice” / А.М. Vendra. - M .: „Finanţe şi statistică”, 2000. - 364 p.
5. „Termeni de referință pentru crearea unui sistem automatizat” / - M .: GOST 34.602-89, 1990.
6. Grekul V.I. „Proiectarea sistemelor informatice” / V.I. Grekul, G.N. Denischenko, N.L. Korovkin. - M .: Internet University of Information Technologies, 2008.
Postat pe Allbest.ru
...Documente similare
Dezvoltarea sistemelor informatice. Piața modernă software aplicat financiar și economic. Avantajele și dezavantajele implementării sistemelor informatice automatizate. Metode de proiectare a sistemelor informatice automatizate.
teză, adăugată 22.11.2015
Tipuri de suport pentru sistemele informatice automatizate. Întocmirea specificațiilor tehnice, dezvoltarea unui sistem informațional, pregătirea unui manual de utilizare pentru program. Instrumente de programare pentru sistemele distribuite de procesare a informațiilor.
raport de practică, adăugat 16.04.2017
Ciclul de viață al sistemelor informatice automatizate. Fundamente ale metodologiei de proiectare a sistemelor automatizate bazate pe tehnologii CASE. Faza de analiză și planificare, construcție și implementare a unui sistem automatizat. Model în cascadă și spirală.
lucrare de termen adăugată la 20.11.2010
Conceptul de sistem informatic, tipuri de sisteme informatice. Analiza instrumentelor pentru dezvoltarea sistemelor informatice automatizate. Cerințe pentru program și produsul software. Dezvoltarea formelor de interfață grafică și baze de date.
teză, adăugată 23.06.2015
Principiile organizării unui sistem format din personal și un set de instrumente pentru automatizarea activităților acestora. Proiectarea sistemelor informatice automatizate corporative. Structura, fluxurile de intrare și ieșire, limitări ale sistemelor automate.
prezentare adaugata la 14.10.2013
Conceptul de sistem informatic. Etapele dezvoltării sistemelor informaţionale. Procesele din sistemul informatic. Sistem informatic pentru gasirea niselor de piata, pentru reducerea costurilor de productie. Structura sistemului informatic. Suport tehnic.
rezumat, adăugat 17.11.2011
Organizarea, arhitectura si structura sistemului informatic. Indicatori ai eficacității muncii sale. Scopurile și obiectivele analizei ACS. Componentele sistemelor automate. Descrierea domeniului subiectului, datele de intrare și de ieșire. Construirea unei diagrame de caz de utilizare.
lucrare de termen adăugată 04.11.2014
Crearea si organizarea sistemelor informatice automatizate (AIS). Componentele principale și procese tehnologice AIS. Etapele și etapele creării AIS din poziția de conducere a organizației. Dezvoltarea de complexe de soluții de proiectare pentru un sistem automatizat.
rezumat adăugat la 18.10.2012
Principalii factori care influențează istoria dezvoltării sistemelor informatice automatizate corporative. Caracteristicile generale și clasificarea lor. Compoziția și structura AIS integrat. Sistemele ERP ca tip modern de sistem informatic corporativ.
prezentare adaugata la 14.10.2013
Analiza domeniului, etapele de proiectare a sistemelor informatice automatizate. Sisteme de instrumente de dezvoltare software. Rolul instrumentelor CASE în proiectarea modelului informațional. Modelul logic al bazei de date proiectate.
Politica de confidențialitate a datelor cu caracter personal și condițiile de prelucrare a datelor cu caracter personal
Această Politică de confidențialitate a datelor cu caracter personal se aplică tuturor datelor personale pe care TEKORA le poate primi de la dumneavoastră în timp ce utilizați site-urile web ale companiei.
Prin completarea formularului de pe site-ul http://www.site/ și alte site-uri web ale Companiei TEKORA care colectează date și fac referire la aceste condiții, îți dai consimțământul voluntar Companiei TEKORA pentru a prelucra următoarele date cu caracter personal prin prelucrare automată instrumente sau fără ele: prenume, nume, patronim; locul de muncă, denumirea funcției ocupate; Adresa de email; numar de telefon de contact.
Oferind TEKORA informațiile necesare pentru a iniția interacțiuni ulterioare, sunteți de acord cu utilizarea acesteia în conformitate cu această Politică.
Dacă nu sunteți de acord cu termenii și condițiile stabilite în acest document, vă rugăm să nu utilizați aceste site-uri web și să nu completați formulare de solicitare de informații.
TEKORA înseamnă:
SA „TEKORA”, Adresa juridică: 119285 Moscova, st. Mosfilmovskaya, 22, clădirea 1.
Adresă poștală: 117997, GSP-7, Moscova, st. Profsoyuznaya, 65 de ani, biroul 369.
Prelucrarea datelor cu caracter personal înseamnă acțiunile prevăzute de legislația Federației Ruse, inclusiv Legea federală din 27.07.2006 N 152-FZ „Cu privire la datele cu caracter personal”.
Prin trimiterea datelor dumneavoastră cu caracter personal, sunteți de acord cu prelucrarea acestora, inclusiv culegerea, înregistrarea, sistematizarea, acumularea, stocarea, clarificarea (actualizarea, modificarea), extragerea, utilizarea, transferul, depersonalizarea, ștergerea, distrugerea de către TEKORA în vederea procesării comenzilor dumneavoastră și solicită desfășurarea de activități de promovare a bunurilor, lucrărilor, serviciilor sau obiectelor de proprietate intelectuală pe piață prin luarea de contacte directe cu dumneavoastră folosind mijloace de comunicare, evaluarea și analiza site-ului, analizarea caracteristicilor de achiziție și furnizarea de recomandări personale; informându-vă despre promoții, reduceri și oferte speciale prin corespondență electronică, precum și pentru a vă contacta (prin e-mail și/sau telefon).
Furnizând TEKORA datele dumneavoastră cu caracter personal, puteți fi sigur că acestea nu vor fi furnizate unor terți, cu excepția cazurilor în care este necesar în interesul relațiilor de afaceri dintre dumneavoastră și TEKORA. În unele cazuri, Compania TEKORA este obligată să transfere datele dumneavoastră cu caracter personal către terți în legătură cu cerințele legii aplicabile. De exemplu, acesta poate fi cazul când există motive pentru a suspecta o infracțiune sau utilizarea abuzivă a site-ului web TEKORA.
Puteți renunța la primirea de e-mailuri în orice moment, dar acest lucru nu afectează transmiterea e-mailurilor care sunt necesare pentru relația de afaceri dintre dvs. și TEKORA.
Aceste site-uri web conțin mai multe link-uri către companii cu care TEKORA menține relatie de afaceri... Compania TEKORA nu este responsabilă pentru respectarea cerințelor de protecție a datelor cu caracter personal în legătură cu utilizarea site-urilor web ale partenerilor Companiei TEKORA. Pentru informații despre protecția datelor atunci când vizitați aceste site-uri, vă rugăm să consultați politicile de confidențialitate ale site-urilor respective ale companiilor.
Datele personale colectate de TEKORA sunt stocate pe servere securizate. Accesul este permis doar unui număr limitat de persoane autorizate care au nevoie de el pentru a gestiona site-urile Companiei TEKORA sau pentru a asigura funcționarea corespunzătoare a acestora, în special în ceea ce privește suportul tehnic.
Cu acest consimțământ, confirmați că sunteți subiectul datelor cu caracter personal furnizate și, de asemenea, confirmați acuratețea datelor furnizate.
