Biblioteca deschisă - o bibliotecă deschisă de informații educaționale. Ciclul de viață al unui sistem informatic automatizat model în cascadă AIS

Design canonic AIS


Dezvoltare și proiectare AISîncepe cu crearea unui model conceptual de utilizare a sistemului. În primul rând, ar trebui determinată fezabilitatea creării unui sistem, funcțiile sale specifice și sarcinile care urmează să fie automatizate. Ar trebui să se facă o evaluare nu numai a obiectivelor, ci și a posibilităților de creare a unui sistem. În continuare, se efectuează analiza cerințelor pentru AIS, proiectarea detaliată, relația dintre etape, programare și testare, minimizarea pierderilor în timpul trecerii de la un nivel de prezentare a informațiilor la altul, integrarea în sistemul existent, implementarea și suportul.

Există trei clase de metodologii de proiectare AIS:
· modelarea conceptuală a disciplinei;
Identificarea cerințelor și specificației Sistem informatic prin aspectul său;
Arhitectura sistemului instrumente software sprijinit unelte CASE-tehnologii (CASE - Computer Aided Software Engineering - tehnologie pentru crearea și întreținerea software-ului pentru diverse sisteme).

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

  1. Formarea cerințelor pentru AS.
  2. Dezvoltarea conceptului AS.
  3. Sarcina tehnică.
  4. Proiectare preliminară.
  5. Proiect tehnic.
  6. Documentatie de lucru.
  7. Punere in functiune.
  8. Suport AC.
Există trei perioade de creare a sistemului: pre-proiect, proiectare, punere în funcțiune.
Etapele 1, 2, 3 se referă la prima perioadă, etapele 4, 5, 6 - la a doua perioadă, etapele 7, 8 - la a treia.
În perioada pre-proiect, se elaborează un studiu de fezabilitate (FS) și termeni de referință (TOR) pentru proiectarea sistemului. În această perioadă, în etapa formării cerințelor pentru CNE, se desfășoară trei etape de lucru:
  • examinarea obiectului disciplinei și justificarea necesității creării unui sistem;
  • formarea cerințelor utilizatorilor pentru sistem;
  • întocmirea unui raport asupra lucrărilor efectuate şi a unei aplicaţii pentru dezvoltarea sistemului.
În etapa de dezvoltare a conceptului CNE, se desfășoară patru etape de lucru:
  • studiul obiectului;
  • efectuarea de lucrări de cercetare;
  • selectarea unei variante a conceptului de sistem dintre mai multe dezvoltate;
  • întocmirea unui raport asupra lucrărilor efectuate.
La a 3-a etapă se elaborează și se aprobă termenii de referință pentru crearea AS.
Termeni de referință (TOR) - aceasta este o listă a principalelor cerințe operaționale, tehnologice, economice și de altă natură pe care obiectul proiectat trebuie să le îndeplinească în toate etapele existenței sale.După aprobarea TOR începe a doua perioadă de creare a CNE - perioada de sistem. proiecta.
Design - procesul de alegere rezonabilă a caracteristicilor sistemului, formarea modelelor logico-matematice și economico-matematice, dezvoltarea documentației.
La etapa de realizare a unui proiect de proiect, la prima etapă, se elaborează soluții preliminare de proiectare pentru sistem și piesele sale, la a 2-a, documentația pentru CNE și părțile sale.
La a 5-a etapă, la crearea unui proiect tehnic, dezvoltarea se realizează în patru etape:
  • soluții de proiectare pentru sistem și piesele sale;
  • documentația pentru CNE și părțile sale;
  • documentatii pentru furnizarea produselor pentru achizitia centralelor nucleare si specificatii tehnice pentru dezvoltarea acestora;
  • sarcini n# proiectare în părțile adiacente ale proiectului obiectului de automatizare.
A treia perioadă este punerea în funcțiune a CNE. Asigura dezvoltarea echipamentelor, echipamentelor, materialelor, produselor achizitionate non-standard, instalare, punere in functiune, implementare.
La a 7-a etapă, sistemul este pus în funcțiune în opt etape:
  • pregătirea obiectului de automatizare pentru intrarea UA;
  • pregatirea personalului;
  • set complet de software AS, tehnic, medii de informareși produse;
  • lucrari de constructii si montaj;
  • lucrări de punere în funcțiune;
  • teste preliminare;
  • operațiune de probă;
  • teste de acceptare.
Conținutul etapelor de creare a SA în diferite etape
Pentru a îmbunătăți managementul procesului de proiectare, fiecare etapă este detaliată, adică este împărțită în etape.
Etapa creării unui sistem automatizat este parte a etapei de creare a SA, determinată de natura lucrării, rezultatul acesteia sau specializarea interpreților.
Metodologii moderne proiectarea sistemului ar trebui să ofere o descriere a obiectelor de automatizare, o descriere a funcționalității AIS, o specificație de proiect care să garanteze atingerea caracteristicilor specificate ale sistemului, un plan detaliat pentru crearea unui sistem cu o evaluare a timpului de dezvoltare, o descrierea implementării unui anumit sistem.

Ciclu de viață AIS
În centrul creației și utilizării AIS constă conceptul de ciclu de viață (LC).
Ciclul de viață este un model pentru crearea și utilizarea AIS, care reflectă diferitele stări ale sistemului din momentul în care apare într-un anumit set de instrumente până în momentul în care este complet neutilizat.

Pentru AIS, următoarele etape principale ale ciclului lor de viață sunt distinse condiționat:
1. analiza - determinarea a ceea ce ar trebui sa faca sistemul;
2. proiectare - determinarea modului în care va funcționa sistemul: în primul rând, specificarea subsistemelor, componentelor funcționale și modul în care acestea interacționează în sistem;
3. dezvoltare - crearea de componente funcționale și subsisteme individuale, conectarea subsistemelor într-un singur întreg;
4. testare - verificarea conformităţii funcţionale şi parametrice a sistemului cu indicatorii determinaţi în etapa de analiză;
5. implementare - instalarea si punerea in functiune a sistemului;
6. suport - asigurarea procesului regulat de operare a sistemului la intreprinderea clientului.

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

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

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

Etapa modelării fizice ar trebui să asigure la nivel experimental o verificare a performanței reale a modelelor AIS create și a adecvării acestora. Pentru implementarea acestei etape, se dezvoltă un model fizic (natural) al AIS. Modelul fizic al AIS- acesta este un set de structură, metode și mijloace de implementare la scară largă redusă a AIS, concepute pentru a testa performanța unui viitor sistem și adecvarea modelelor acestuia în condiții reale.

Într-o anumită privință, modelul fizic al AIS are proprietățile unui sistem real. Pentru construcția acestuia sunt implicate calculatoare, dispozitive periferice, documente, fișiere, baze de date, programe de prelucrare a datelor și alte componente necesare pentru crearea AIS. Modelul fizic al AIS este redus, i.e. aceasta este o reprezentare redusă a acesteia. Reducerea aici nu este mecanică, nu arbitrară, ci armonizată. Prezintă doar acele proprietăți pe care dezvoltatorii le-au clasificat drept de bază, esențiale.

3. Design AIS

Pe baza principiilor, prevederilor, modelelor, metodelor și instrumentelor elaborate pentru construirea AIS obținute în etapa de cercetare, sistemul este în curs de proiectare.

Etapa de proiectare constă din următorii pași:

1) sondaj subiect (PRO) al IP existent (tradițional);

2) dezvoltare termeni de referinta pentru a crea un sistem;

3) elaborarea unui proiect tehnic pentru realizarea unui sistem;

4) elaborarea unui proiect de lucru pentru crearea sistemului.

Cu condiția ca IS existent să fie automatizat, există două moduri de proiectare: modernizarea AIS existent sau înlocuirea completă a acestuia cu un AIS nou creat. Cu volume relativ mici munca de proiectare pașii 2 și 3 pot fi combinați.

Etapa PRO se realizează în scopul studierii și analizei trăsăturilor obiectului - IS tradițional existent. Se realizează colectarea materialelor pentru proiectare - definirea cerințelor, studiul obiectului de design. Se studiază condițiile de funcționare a viitorului AIS, se stabilesc anumite restricții asupra condițiilor de dezvoltare - calendarul etapelor de proiectare, resursele disponibile și lipsă, proceduri și măsuri pentru asigurarea protecției informațiilor etc. ținând cont de studiile preliminare, se realizează dezvoltarea și selecția variantei conceptului AIS.

Etapa de elaborare a specificațiilor tehnice- o continuare logică a etapei de apărare antirachetă. Materialele obținute în stadiul ABM sunt utilizate pentru elaborarea ToR. Aici se realizează analiza și dezvoltarea cerințelor fundamentale pentru AIS de către un anumit client sau grup de consumatori potențiali. Sunt formulate cerințele pentru componente hardware, software, informații și organizatoric-juridice ale AIS etc.

Pe etapa de proiectare tehnică se efectuează căutarea celor mai acceptabile soluții pentru toate sarcinile de proiectare AIS. Scopul acestei etape de proiectare este de a concretiza cunoștințe generale, uneori neclare, despre cerințele pentru viitorul sistem. Pe această etapă sunt definite:

se mai are în vedere scopul, sarcinile, funcțiile AIS, condițiile externe de funcționare a sistemului, distribuția funcțiilor între componentele acestuia;

Parametrii sistemului AIS - interfețe și distribuție a funcțiilor între operator și sistem;

configurarea tuturor subsistemelor AIS care formează structura acestuia - componente documentar-informaționale, tehnice, software-matematice și organizatoric-juridice ale structurii sistemului;

sistem de management al structurii și bazelor de date, instrumente lingvistice, alcătuirea limbilor de regăsire a informațiilor, clasificatoare și codificatoare, metode de indexare a documentelor și interogări;

fișa de configurare a complexului de mijloace tehnice ale AIS și specificația acestora;

compoziția și caracteristicile modelelor matematice, algoritmilor și programelor AIS;

schema de funcționare a AIS, procesul tehnologic de prelucrare a datelor etc.;

instrucțiuni de muncă și de lucru pentru personalul AIS;

studiul de fezabilitate actualizat al proiectului.

Partea principală a intensității muncii de proiectare detaliată este munca de dezvoltare a algoritmilor și a programelor aferente.

Pe etapa de proiectare detaliată se realizează perfecţionarea finală a acelor probleme care la etapa de proiectare tehnică din anumite motive nu au putut fi rezolvate în totalitate. În această etapă, se dezvoltă un set de programe bazate pe algoritmi compilați în etapa de proiectare tehnică. Se precizează structura bazei de date, se ajustează formatele unificate ale documentelor procesate în tehnologia AIS.

În această etapă se testează programele, se analizează o serie de teste de control cu ​​prelucrarea documentelor reale, rezultatele testării și prelucrărilor experimentale, precum și ajustările necesare la programe.

Metode și instrumente pentru proiectarea AIS. Proiectarea AIS poate fi realizată:

dezvoltator terț. Această firmă are un personal de profesioniști cu înaltă calificare. Lucrarea se desfășoară pe baza unui acord între dezvoltator și client;

de catre personalul specialist al companiei client.

De asemenea, este posibilă o soluție de compromis: firma client poate invita un consultant pentru dezvoltarea AIS pe bază de contract.

Alegerea specifică este determinată de mulți factori, în special, starea financiară a companiei client, disponibilitatea specialiștilor cu normă întreagă de profilul și nivelul adecvat, momentul creării AIS, prezența în regiunea dată sau în apropiere. a firmei dezvoltatoare corespunzatoare, consultanti specialisti, regimul de secretizare al societatii etc.

Sunt folosite metode și instrumente adecvate pentru a rezolva problemele de proiectare. Printre acestea, ar trebui să găsim astfel de metode care ar rezolva radical problemele dezvoltării AIS. O astfel de metodă este analiza structurală. Este o metodă de studiere a unui sistem care consideră sistemul ca o structură ierarhică de la nivelul său general până la cel mai de jos necesar.

În etapa studiului pre-proiect, sunt utilizate metode pentru studierea stării reale a IP-ului existent (tradițional):

întrebări orale sau scrise;

sondaj scris;

observare, măsurare și evaluare;

discutarea rezultatelor intermediare;

analiza sarcinilor;

analiza producției, managementului și informației

proceselor.

Metodele de formare a stării specificate sunt asociate cu justificarea teoretică a tuturor componentelor AIS, ținând cont de obiectivele, cerințele și condițiile clientului. Acestea includ:

modelarea proceselor de prelucrare a datelor;

Design structural;

descompunere;

analiza tehnologiei informatiei.

Pentru o reprezentare vizuală a obiectelor și proceselor AIS, se folosesc metode de afișare grafică a stărilor reale și specificate - organigrame, grafice, desene, desene, schițe, diagrame etc.

4. Automatizare de proiectare AIS

Sisteme automatizate design - un mijloc eficient de îmbunătățire a performanței designului AIS. În domeniul proiectării s-a format o direcție specială - ingineria software sau tehnologiile CASE (Software asistat de calculator / Inginerie de sistem - un sistem pentru dezvoltarea de software de calculator). Tehnologiile CASE sunt un set de metode de analiză, proiectare, dezvoltare și implementare a AIS, susținute de un set de instrumente de automatizare interconectate. CASE-technologies este un instrument pentru analiști de sistem, dezvoltatori și programatori care asigură automatizarea proceselor de proiectare AIS de diferite clase și valori.

Scopul principal al tehnologiei CASE este de a automatiza procesul de dezvoltare cât mai mult posibil și de a separa procesul de proiectare de codarea software-ului AIS.

Metode structurale pentru construirea modelelor de întreprindere. Se obișnuiește să se numească o metodă structurală o astfel de metodă de studiere a unui sistem sau proces care începe cu o privire de ansamblu asupra obiectului de studiu și apoi implică detalierea consecventă a acestuia. Metodele structurale au trei caracteristici principale:

Dezmembrare sistem complexîn părți reprezentate ca „cutii negre”, fiecare „cutie neagră” implementează o funcție specifică a sistemului de control;

Ordonarea ierarhică a elementelor selectate ale sistemului cu definirea relațiilor dintre ele;

Utilizarea unei reprezentări grafice a relației elementelor sistemului.

Un model construit folosind metode structurale este un set ierarhic de diagrame care descriu grafic funcțiile îndeplinite de sistem și relațiile dintre ele.

Ca parte a metodologiilor de analiză structurală, cele mai comune includ următoarele:

SADT este o tehnologie de analiză structurală și proiectare, iar subsetul său este standardul IDEFO.

DFD - Diagrame de flux de date.

ERD - diagrame entitate-relație.

STD - diagrame de tranziție de stare.

ÎN Metodologia IDEFO sunt utilizate patru concepte de bază: bloc funcțional, arc de interfață, descompunere, glosar.

Modelul IDEFO începe întotdeauna cu o reprezentare a procesului a unui singur bloc funcțional cu arcuri de interfață care se extind dincolo de zona considerată. Uneori, astfel de diagrame sunt furnizate cu ajutorul contextului.

Scopul evidențiază acele domenii de activitate ale întreprinderii care ar trebui luate în considerare în primul rând. Scopul stabilește direcția și nivelul de descompunere a modelului dezvoltat.

ÎN Metodologia DFD procesul studiat este împărțit în subprocese și prezentat ca o rețea conectată prin fluxuri de date. În exterior, DFD este similar cu SADT, dar diferă în setul de elemente utilizate. Acestea includ procese, fluxuri de date și stocare.

Metodologia ERD folosit pentru a construi modele de baze de date, oferă o modalitate standardizată de a descrie datele și de a defini relațiile dintre acestea. Elementele principale ale metodologiei sunt conceptele de „esență”, „relație” și „relație”. O entitate definește tipuri de informații de bază, iar relațiile specifică modul în care aceste tipuri de date interacționează între ele. Relațiile leagă entitățile și relațiile.

Metodologia STD este cel mai convenabil pentru modelarea anumitor aspecte ale funcționării sistemului, datorită timpului și răspunsului la evenimente, de exemplu, pentru a implementa o solicitare a utilizatorului către AIPS în timp real. Elementele de bază ale STD sunt conceptele de „stare”, „stare inițială”, „tranziție”, „condiție” și „acțiune”. Prin intermediul conceptelor se realizează o descriere a funcționării sistemului în timp și în funcție de evenimente. Modelul STD este imagine grafică- diagrama tranzițiilor sistemului de la o stare la alta.

Metode orientate pe obiect pentru construirea modelelor de sisteme de control. Aceste metode se deosebesc de metodele structurale printr-un nivel superior de abstractizare. Ele se bazează pe reprezentarea sistemului ca un set de obiecte care interacționează între ele prin schimbul de date. Obiecte specifice sau entități abstracte - o comandă, un client etc. pot servi ca obiecte ale domeniului subiectului. Cea mai semnificativă metodă este G. Buch. Aceasta este o tehnică de proiectare a obiectelor cu elemente de analiză a obiectelor, care are patru etape:

1) elaborarea unei diagrame hardware care să prezinte procesele, dispozitivele, rețelele și conexiunile acestora;

2) definirea unei structuri de clasă care descrie relația dintre clase și obiecte;

3) elaborarea de diagrame de obiecte care arată relația unui obiect cu alte obiecte;

4) dezvoltarea arhitecturii software care descrie designul fizic al sistemului creat.

Marea majoritate a metodelor existente de analiză și proiectare orientate pe obiecte includ atât un limbaj de modelare, cât și instrumente pentru descrierea proceselor de modelare.

Abordarea orientată pe obiect nu se opune abordării structurale, ci poate servi drept complement al acesteia.

5. Construirea și implementarea AIS

După finalizarea completă a lucrărilor de proiectare, începe etapa de construire a AIS. Clădirea AIS este un set de măsuri organizatorice și tehnice pentru implementarea proiectului AIS. Printre astfel de măsuri se numără măsuri financiare, informaționale, tehnice, programatice, juridice, organizatorice:

Identificarea surselor de finanțare și alocarea fondurilor pentru achiziții echipamentul necesar furnizat de proiect - „Fișa de specificații echipamente AIS”;

Selectarea furnizorilor si incheierea contractelor de furnizare de echipamente;

Alocarea spațiilor pentru desfășurarea AIS și pregătirea acestuia pentru instalarea echipamentelor;

Amplasarea, asamblarea, instalarea, configurarea echipamentelor AIS în conformitate cu proiectul;

Selectarea, organizarea și pregătirea categoriilor de personal obișnuit AIS pentru a efectua lucrări relevante pentru asigurarea funcționării AIS;

Efectuarea lucrărilor de control al calității echipamentelor (control, testare). Dacă se constată defecte - înregistrarea și prezentarea reclamațiilor către furnizori;

Instalarea software și efectuarea lucrărilor de testare a pachetului software AIS. Sub rezerva detectării defectelor - luarea de măsuri pentru eliminarea acestora;

Completarea bazei de date, rezolvarea cazurilor de testare pentru întreaga gamă de sarcini AIS în conformitate cu proiectul. Dacă se constată deficiențe, se iau măsuri pentru eliminarea acestora. În cazul în care nu se constată deficiențe - pregătirea documentelor pentru punerea în funcțiune a AIS.

Compoziția măsurilor și succesiunea acestora reflectă principalele puncte de control în construcția AIS. Construcția fiecărui sistem specific va avea propriile sale specificități atât în ​​ceea ce privește natura sarcinilor, cât și succesiunea acestora. Caracteristicile de construcție sunt determinate de natura AIS, nivel organizatoric aplicarea AIS, modul de operare, valoarea finanțării etc.

Una dintre condițiile importante pentru eficacitatea AIS este realizarea unui complex de lucrări pentru implementarea acestuia. Introducerea AIS începe cu faptul că șeful firmei client emite un ordin de implementare a sistemului indicând principalele etape, momentul implementării acestora, executanți responsabili, suport de resurse, formularul de prezentare a rezultatelor implementării, persoana responsabilă cu monitorizarea executării comenzii etc. Ordinul poate conține un plan de implementare cu indicarea lucrării în următoarele etape:

1) documentarea rezultatelor punerii în funcțiune a echipamentelor, precum și a testelor de control ale unui set de sarcini ale sistemului;

2) instruirea personalului în tehnologia AIS și studiul secțiunilor relevante documentatia proiectului;

3) efectuarea operațiunii de probă a sistemului, analiza și corectarea erorilor de proiectare și execuția documentației pe baza rezultatelor operațiunii de probă;

4) punerea în funcțiune a AIS cu executarea documentației relevante.

Astfel, în prima etapă, se dezvoltă un program de teste de control al AIS în ansamblu. În a doua etapă, dezvoltatorul și clientul organizează instruire pentru personalul implicat în operarea AIS. În a treia etapă, se realizează operarea pilot a sistemului. În funcție de conținutul și domeniul de aplicare al sarcinilor AIS, operațiunea de probă durează de la trei până la șase luni.

Introducerea AIS este o sarcină destul de dificilă atât din punct de vedere organizațional, cât și din punct de vedere tehnic. Clientul trebuie să pregătească implementarea sistemului. Această condiție necesită anumite eforturi organizatorice, profesionale și psihologice din partea personalului companiei client, într-o oarecare măsură implicat în funcționarea AIS. Administrația companiei trebuie să asigure astfel de condiții în care echipa companiei să aibă o atitudine pozitivă față de implementarea sistemului și să ajute implementarea, dezvoltarea și dezvoltarea acestuia. Atunci se va putea presupune că obiectivul de introducere și operare AIS la întreprindere va fi atins.

6. Metodologia de calcul a eficienței tehnico-economice a prelucrării automate a informațiilor

Una dintre secțiunile principale ale proiectului AIS este studiul de fezabilitate al AIS în general și procesele de prelucrare automată a informațiilor economice în special. Acest lucru necesită calcule adecvate ale eficienței tehnice și economice.

Eficiența economică a prelucrării automate a datelor este asigurată de următorii factori principali:

Viteză mare a operațiunilor de culegere, transmitere, prelucrare și emitere a informațiilor, rapiditatea mijloacelor tehnice;

Reducerea maximă a timpului de efectuare a operațiunilor individuale;

Îmbunătățirea calității prelucrării datelor și a informațiilor primite.

Eficiența globală a soluționării automate a problemelor depinde direct de reducerea costurilor de prelucrare a datelor și este o eficiență economică directă. Obținerea efectului soluțiilor la nivelul întregului sistem de îmbunătățire a calității serviciului de informare a utilizatorilor oferă eficiență economică indirectă.

Indicatorii direcți de eficiență economică sunt determinați prin compararea costurilor procesării datelor pentru mai multe opțiuni de proiectare. În esență, aceasta este o comparație a două opțiuni - de bază și proiectate. Sistemul existent de prelucrare automată sau tradițională (manuală) a datelor este luat ca versiune de bază, iar rezultatul modernizării sistemului existent sau a unui AIS nou dezvoltat este luat ca versiune proiectată.

Indicatorul absolut al eficienței economice a proiectului AIS dezvoltat este reducerea costului anual și costurile forței de muncă privind procesul tehnologic de prelucrare a datelor în comparație cu versiunea de bază a TPOD.

Economisirea costurilor financiare datorită automatizării prelucrării datelor este determinată pe baza calculului diferenței de costuri a opțiunilor de bază și proiectate pentru prelucrarea datelor folosind formula:

C e \u003d C b - C p (1)

unde C e - valoarea reducerii costurilor pentru prelucrarea datelor;

C b - costuri pentru cazul de bază;

C n - costuri pentru opțiunea proiectată.

Indicatorul relativ al eficienței economice a proiectului AIS este raportul de eficiență a costurilor (K e) și indicele de modificare a costurilor (I c).

K e \u003d C e / C b * 100% (2)

Raportul de eficiență a costurilor arată ce parte din costuri va fi economisită cu opțiunea AIS proiectată sau cu câte procente vor fi reduse costurile.

Valoarea indicelui de modificare a costurilor poate fi determinată prin formula:

I s \u003d C e / C b. (3)

Acest index indică de câte ori se va reduce costul procesării datelor în timpul implementării proiectului AIS.

La implementarea unui proiect AIS, este necesar să se ia în considerare costurile de capital suplimentare, a căror valoare (K 3) poate fi determinată prin formula:

K 3 \u003d K p - K b (4)

unde K p și K b - costurile de capital, respectiv, ale sistemelor de prelucrare a datelor proiectate și de bază.

Eficiența cheltuielilor de capital este determinată de perioada de rambursare (T) a cheltuielilor de capital suplimentare pentru modernizarea SI:

T \u003d K 3 / C e (5)

E \u003d C e / K 3 \u003d 1 / T. (6)

Odată cu calculul costurilor de cost, este utilă obținerea unor indicatori ai reducerii costurilor cu forța de muncă pentru prelucrarea datelor. Indicatorul absolut al reducerii costului forței de muncă (t) este diferența dintre costurile anuale ale forței de muncă ale opțiunilor de procesare a datelor de bază și proiectate:

t = T b. – T p (7)

unde T b. și T p - intensitatea anuală de muncă de funcționare, respectiv, a opțiunilor de bază și proiectate pentru prelucrarea datelor.

Valoarea indicatorului relativ de reducere a costului forței de muncă poate fi afișată prin coeficientul de reducere a costului muncii (K):

K t \u003d t / T b. (8)

Indicele de modificare a costurilor forței de muncă (I t) caracterizează creșterea productivității muncii datorită dezvoltării unei versiuni care economisesc mai mult forța de muncă a proiectului de prelucrare a datelor, poate fi determinat prin formula:

I t \u003d T b / T p. (9)

Reducerea absolută a costului forței de muncă (P) este utilizată pentru a determina eliberarea potențială resurse de muncă(interpreți) din sistemul de prelucrare a datelor:

P \u003d (t / T f) * f (10)

unde T f este fondul anual de timp al unui executant angajat în tehnologia de prelucrare a datelor;

f este un coeficient care reflectă posibilitatea unei eliberări complete a lucrătorilor, în detrimentul fondului de timp al căruia s-a calculat valoarea lui t.

Definirea economiilor directe din implementarea sistemului de prelucrare a datelor proiectat (modernizat) se realizează pe baza unei comparații de indicatori care reflectă costurile cu forța de muncă și costurile pentru operațiunile atât ale sistemului tradițional de prelucrare a datelor, cât și ale sistemului proiectat.

Economisirea costurilor forței de muncă (E tz) în procesarea automată a informațiilor despre proiect poate fi determinată prin formula

E tz \u003d To6sch - bufnițe (11)

unde T o6sh este complexitatea prelucrării datelor în mod tradițional cu cazul de bază;

Șuruburi - complexitatea prelucrării automate a datelor în versiunea de design.

Economiile de costuri financiare din implementarea unei opțiuni de procesare a datelor de proiect în comparație cu un caz de bază manual pot fi determinate într-un mod similar.

Colectarea datelor inițiale pentru substituirea în formulele de mai sus și efectuarea calculelor pentru determinarea eficienței economice se realizează prin înregistrarea și măsurarea parametrilor relevanți în etapele procesului tehnologic de prelucrare a datelor. În plus, datele inițiale pentru o perioadă lungă pot fi obținute prin analiza jurnalelor de înregistrare (tehnologice) ale controlorului AIS și a altor forme de înregistrare.

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

model în cascadă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrării în etapa anterioară. Cerințele definite în etapa de formare a cerințelor sunt strict documentate sub formă de termeni de referință și fixate pe întreaga durată a dezvoltării proiectului. Fiecare etapă culminează cu lansarea unui set complet de documentație suficientă pentru ca dezvoltarea să fie continuată de o altă echipă de dezvoltare.

Etape ale proiectului conform modelului cascada:

1. Formarea cerințelor;

2. Design;

3. Dezvoltare;

4. Testare;

5. Introducere;

6. Operare și întreținere.

Avantaje:

-Documentatie completa si agreata la fiecare etapa;

-Ordinea determinată a secvenței de lucru;

- Vă permite să planificați în mod clar calendarul și costurile.

Dezavantaje:

-Întârziere semnificativă în obținerea rezultatelor gata făcute;

-Greșelile la oricare dintre etape sunt detectate în etapele ulterioare, ceea ce duce la necesitatea returnării și reînregistrării documentației de proiect;

- Dificultate în managementul proiectelor.

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

Fiecare iterație - cicluri de dezvoltare finalizate sub forma primei versiuni a AIS.

Pași de iterație:

1.Formarea cerințelor

3.Design

4.Dezvoltare

5.Integrare

La fiecare iterație se evaluează următoarele:

Riscul depășirii termenilor și costului proiectului;

Necesitatea de a efectua o altă iterație;

Gradul de completitudine și acuratețe al înțelegerii cerințelor pentru sistem;

Oportunitatea rezilierii proiectului.

Avantaje:

-Simplifica procesul de modificare a proiectului;

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

- Posibilitatea de a obține un sistem fiabil și stabil, deoarece erori și inconsecvențe sunt găsite la fiecare iterație;

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

Dezavantaje:

-Complexitatea planificarii;

-Mod intens de lucru pentru dezvoltatori;

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

Cerințe pentru tehnologia de proiectare, dezvoltare și întreținere a AIS

Tehnologie de design- definește o combinație de trei componente:



- o procedură pas cu pas care determină succesiunea operațiunilor de proiectare tehnologică;

- regulile utilizate pentru evaluarea rezultatelor operațiunilor tehnologice;

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

Instrucțiunile tehnologice, care alcătuiesc conținutul principal al tehnologiei, ar trebui să includă o descriere a secvenței operațiilor tehnologice, condițiile în funcție de care se efectuează una sau alta operație și descrieri ale operațiunilor în sine.

Tehnologia pentru proiectarea, dezvoltarea și întreținerea IS trebuie să îndeplinească următoarele Cerințe generale:

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

Tehnologia ar trebui să asigure realizarea garantată a obiectivelor dezvoltării SI cu o calitate dată și la un moment dat;

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

Tehnologia ar trebui să prevadă posibilitatea de a gestiona configurația proiectului, menținerea versiunilor de proiect și ale componentelor acestuia, posibilitatea emiterii automate a documentației de proiect și sincronizarea versiunilor acestuia cu versiunile de proiect;

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

- standard de proiectare;

- standard pentru proiectarea documentației de proiect;

- standard de interfață cu utilizatorul.

Cerință de dezvoltare

- Efectuarea de lucrări la crearea de software;

Pregătirea pentru introducerea AIS;



Controlul, testarea principalilor indicatori ai proiectului.

Cerințe însoțitoare

Finalizarea implementării CIS ar trebui să fie însoțită de publicarea sistemului reglementări administrativeȘi descrierea postului definirea ordinii de funcţionare a organizaţiei. Din momentul punerii in functiune a sistemului informatic, functionarea are loc in baza „Regulamentului de functionare a sistemului informatic” si a unei serii de reglementari. Întreținerea sistemului și funcționarea neîntreruptă a acestuia este efectuată de o subdiviziune a organizației autorizată prin ordinul relevant. Finalizarea sistemului informatic după punerea în funcțiune se realizează în conformitate cu proiectele individuale și cu termenii de referință.

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

Introducere

1. Arhitectura sistemelor informatice automatizate si probleme de imbunatatire a acestuia 13

1.1. Modele de arhitectură și componente principale ale AIS 13

1.2. Probleme de dezvoltare AIS 47

1.3. Platforme pentru implementarea noii arhitecturi a AIS UP 53

1.4. Capitolul 1 Concluzii 57

2. Model de arhitectură AIS UE 58

2.1. Cerințe de bază pentru AIS UP 59

2.2. Arhitectură AIS UP 66

2.3. Componente AIS UP 89

2.4. Capitolul 2 Concluzii 102

3. Metode de implementare practică a AIS UE 104

3.1. Instrumente de dezvoltare AIS UP 104

3.2. Experiență în implementarea practică a modelului AIS UP 111

3.3. Capitolul 3 Concluzii 123

4. Concluzie 125

5. Terminologie și abrevieri 128

6. Literatură

Introducere în muncă

Activitatea întreprinderilor moderne este asociată cu deplasarea fluxurilor interdependente și volumetrice de resurse materiale, financiare, de muncă și informaționale. Gestionarea proceselor ciclului de producție și comercial într-un mediu politic și economic în schimbare dinamică necesită luarea rapidă a deciziilor într-un timp scurt. Rezolvarea acestei probleme în condiții moderne este imposibilă fără utilizarea prelucrării automate a informațiilor tehnice și economice.

În ultimii 40 de ani, tehnologiile informaționale automatizate (IT) au fost utilizate în mod activ pentru a rezolva problemele de contabilitate, planificare și analiză. activitate economicăîntreprinderilor diferite forme proprietate, afiliere la industrie, structura organizationalași amploarea activității. În acest timp, un mare experienta practica crearea de sisteme informatice automatizate pentru managementul întreprinderii (AIS UE), au fost dezvoltate metodologii de management și au primit recunoaștere universală, a căror aplicare este imposibilă în afara mediului informatic. Se poate spune cu toată responsabilitatea că AIS UE a devenit o parte integrantă a infrastructurii de afaceri. Problemele teoretice și practice ale automatizării proceselor economice sunt studiate profund în lucrările lui Glushkov V.M., Volkov S.I., Isakov V.I., Ostrovsky O.M., Podolsky V.I., Ratmirov Yu.A., Romanov A.N., Hotyashova EN, Brady R., Zachman J., Cook M., Finkelstein K., Hammer M. și alți autori. Abordările pe care le-au propus au devenit baza utilizării tehnologiei informatice în întreprinderi în rezolvarea problemelor de contabilitate, planificare și analiză a activităților financiare și economice. dar

modelele pe care le-au propus nu au ținut cont de realitățile economiei societății informaționale și de nivelul actual de dezvoltare IT.

Dezvoltarea mijloacelor de comunicare contribuie la o interacțiune din ce în ce mai strânsă între producători și consumatori, furnizori și cumpărători, crește concurența pe piață, extinde granițele piețelor locale către cele naționale și transnaționale și accelerează timpul tranzacțiilor economice și al tranzacțiilor financiare. Introducerea rețelelor globale de calculatoare în procesele economice a condus la apariția unor noi concepte: economia societății informaționale, afaceri electronice (e-business), comerț electronic (e-commerce), comerț electronic podeaua comercială(e-marketplace);

Conceptele existente de organizare AIS UE se bazează pe o abordare funcțională a distribuției sarcinilor între subsistemele sale. Cu toate acestea, AIS, construit ca un complex de subsisteme concentrate pe funcții de management individuale, nu îndeplinește cel mai bine cerințele de continuitate a proceselor de afaceri end-to-end ale unei întreprinderi. Prin urmare, în ultimii ani a devenit din ce în ce mai populară o abordare, în care procesele de afaceri sunt puse în prim plan, și nu funcțiile individuale ale serviciilor sistemului de management care le realizează. Are nevoie de dezvoltare concept nou Arhitectura AIS UE. În același timp, este evident că trecerea la o nouă arhitectură AIS UE nu poate fi realizată deodată, deoarece de-a lungul anilor, întreprinderile și organizațiile au pus în funcțiune un număr mare de instrumente software care implementează soluția unor sarcini importante de management. , a cărui utilizare nu poate fi abandonată imediat. Din păcate, cele mai multe dintre ele sunt axate pe funcționarea autonomă, ceea ce complică semnificativ integrarea complexă a fluxurilor de informații. Multe existente produse software, oferind suport pentru rezolvarea noilor probleme de management al intreprinderii aparute in contextul globalizarii economiei, sunt dezvoltate si fara o elaborare suficienta a interfetelor de interactiune cu complexe software, realizând rezolvarea problemelor conexe. În aceste condiții, sarcina de a sintetiza sistemele integrate de management al întreprinderii prin integrarea componentelor de la terți, soluții personalizate și dezvoltări interne este de o importanță deosebită.

Ideea implementării standardelor de integrare a sistemelor pentru instrumentele software furnizate de diverși producători a fost mult timp discutată în publicațiile oamenilor de știință și practicieni. Progresul instrumentelor de sistem a dus la apariția tehnologiilor de dezvoltare software orientate pe obiecte și componente, care vă permit să construiți sisteme la scară largă din blocuri gata făcute. Furnizori de top de hardware și software de sistem (Intel, Microsoft, Sun, Oracle, IBM etc.), instrumente de comunicare (Cisco, Nortel, Ericsson, Motorola), soluții aplicate (SAP, PeopleSoft, Siebel etc.), stat autoritar, internaţionale, comerciale şi organizatii nonprofitși asociații (ISO, IEEE, ASCII, APICS, RosStandard etc.) au dezvoltat până acum și implementează activ în practică tehnologii de integrare hardware și software care permit crearea de sisteme deschise bazate pe standarde și protocoale pentru schimbul de date și interacțiunea componentelor în un mediu eterogen în modul în timp real.

Cu toate acestea, aceste propuneri oferă doar o platformă la nivelul întregului sistem, care necesită o rafinare semnificativă în raport cu un domeniu specific. În contextul implementării practice a AIS UE, mecanismele de proiectare și dezvoltare a sistemelor informaționale (IS) utilizând arhitecturi componente multi-link bazate pe standarde și protocoale ale sistemelor deschise nu au fost suficient dezvoltate.

În acest sens, problema dezvoltării unei platforme teoretice și dezvoltării sfaturi practice care vizează construirea AIS UE, oferind automatizarea completă a tuturor procedurilor de informare pentru gestionarea întreprinderilor și organizațiilor.

Necesitatea dezvoltării unei abordări holistice pentru rezolvarea problemelor de integrare a sistemelor AIS PM și de automatizare end-to-end a proceselor microeconomice bazate pe IT-ul modern a determinat alegerea subiectului și a direcției. acest studiu.

Scopul studiului este de a dezvolta un model al arhitecturii AIS UE care oferă automatizare cuprinzătoare și suport informațional pentru procesele de afaceri end-to-end și de a fundamenta alegerea instrumentelor pentru integrarea sa în sistem din punctul de vedere al tehnologiilor informaționale moderne.

Pe baza scopului urmărit, au fost stabilite și rezolvate următoarele sarcini științifice și practice:

Să analizeze și să generalizeze abordările existente pentru proiectarea, dezvoltarea și implementarea software-ului AIS UP;

Clasificarea tipurilor de software utilizate în practica managementului întreprinderii;

Explorează tehnologiile și standardele existente care asigură integrarea instrumentelor software eterogene;

Să identifice problemele care apar în timpul integrării instrumentelor software utilizate în AIS UE;

Sistematizarea cerințelor stabilite de întreprinderi pentru software-ul AIS UE pentru a oferi suport informațional pentru procesele economice end-to-end;

Dezvoltarea unui model de arhitectură AIS UE și evidențierea componentelor sale principale;

Dezvoltarea principiilor de interacțiune și schimb de date ale componentelor AIS UE;

Obiectul cercetării îl constituie metodele și instrumentele de dezvoltare a sistemelor informaționale economice.

Obiectul studiului este managementul întreprinderii IS.

Metodologia cercetării se bazează pe aplicații specifice ale metodologiei cunoașterii științifice în domeniile aplicative ale informaticii și matematicii.

Scopurile și obiectivele studiului au fost formulate în conformitate cu direcția principală de lucru privind dezvoltarea și îmbunătățirea ulterioară metode matematiceși tehnologia informatică utilizată în domeniile economice.

Alături de o abordare științifică generală bazată pe teoria sistemelor, disertația rezumă experiența de dezvoltare, implementare și operare a instrumentelor software ale producătorilor autohtoni și străini, metode

implementarea standardelor internaționale deschise pentru construirea de sisteme informatice. Pe această bază, sunt propuse un set de recomandări metodologice și practice care au fost testate la întreprinderi rusești și străine.

Lucrarea folosește prevederile teoretice ale lucrărilor autorilor autohtoni și străini în domeniul:

Prelucrarea automată a informațiilor economice și modelarea proceselor economice;

metodologii de planificare şi Managementul operational producție și stocuri;

Reproiectare și proiectare computerizată a proceselor de afaceri;

Standarde moderne în tehnologia informației.

Studiul a analizat și utilizat evoluțiile realizate de echipe de cercetare și oameni de știință individuali de la Academia Financiară din cadrul Guvernului Federației Ruse, Institutul de corespondență din întreaga Rusie de finanțe și economie, Universitatea de Stat de Economie, Statistică și Informatică din Moscova, Universitatea din Sankt Petersburg. de Economie și Finanțe. Voznesensky, Institutul Financiar de Cercetare și alte organizații.

Baza de informații a studiului a constat din produse software ale producătorilor ruși și străini, publicații în publicații economice și informatice, cercetări efectuate de grupuri internaționale de cercetare Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest etc., materiale metodologice de la consultanță națională și internațională de top. și companii de audit, rezultatele cercetării Asociației dezvoltatorilor de software în domeniul economiei,

cercetarea pieței de software din Rusia și țările CSI TSIES „Business-Programs-Service” .

Noutatea științifică a disertației constă în dezvoltarea unui model de arhitectură AIS UE axat pe automatizarea integrată a proceselor de afaceri end-to-end, și propuneri pentru implementarea acestuia prin integrarea în sistem a instrumentelor software eterogene într-un mediu de rețea eterogen distribuit, bazat pe tehnologii obiect şi componente.

Noutatea științifică conține următoarele rezultate obținute în disertație:

Definirea și clasificarea cerințelor pentru funcționalitatea software-ului de management organizațional și economic al întreprinderilor;

Model de arhitectură AIS UE axat pe automatizarea integrată a proceselor de afaceri end-to-end;

Principii de integrare a instrumentelor software pentru rezolvarea problemelor serviciilor funcționale ale unei întreprinderi cu software de bază pentru gestionarea proceselor de afaceri, schimbul de date și managementul documentelor;

Propuneri de organizare a unui singur spațiu de informare al întreprinderii, la dispoziția angajaților și partenerilor întreprinderii prin portalul web corporativ;

Propuneri de implementare a unui sistem unificat de formare și clasificare a raportării folosind instrumente analitice;

Principii pentru implementarea interacțiunii subsistemelor AIS UE bazate pe tehnologii orientate pe obiect și componente și interacțiunea componentelor software într-o rețea distribuită

mediu în conformitate cu standardele industriei și protocoalele Internet;

Mecanismul de implementare a proprietăților adaptive ale modelului de arhitectură al software-ului AIS UE în conformitate cu cerințele unei anumite întreprinderi, bazat pe capacitatea de a configura subsistemele de bază la procesele de lucru existente și proiectate.

Semnificația practică a lucrării de disertație este că implementarea propunerilor propuse vă permite să creați AIS UE, oferind suport eficient pentru procedurile de informare pentru gestionarea activităților unei întreprinderi în contextul unei economii globalizate și al formării unei societăți informaționale.

Modelul de arhitectură AIS UE propus și recomandările pentru aplicarea acestuia au suficientă flexibilitate și versatilitate, ceea ce asigură aplicabilitatea lor în construirea managementului SI a întreprinderilor de diferite forme de proprietate, specificul industriei și scara de activitate.

Valoarea practică independentă are:

Propuneri pentru selectarea și aplicarea standardelor, protocoalelor și altor mecanisme utilizate în integrarea sistemelor AIS UE;

Oferte pt automatizare integrată procese de afaceri și flux de lucru end-to-end;

Propuneri pentru crearea unui spațiu informațional unic al întreprinderii folosind mecanismul portalurilor web;

Propuneri de adaptare a abordării spiral-iterative în dezvoltarea și implementarea software-ului AIS UP.

Semnificația practică a lucrării a fost evaluată în proiecte specifice pentru implementarea modelului propus, orientat spre probleme, al unui sistem de automatizare a întreprinderii:

Sistemul integrat de management al întreprinderii „Flagman” al companiei „Infosoft”,

sisteme de management al relațiilor cu clienții eRelationship ale Pivotal Software Corporation (Canada),

Sistemele de raportare corporative Monarch ES ale companiei DataWatch (SUA),

Proiectul de integrare a sistemelor informatice ale companiilor Sovintel si Tele Ross.

Centrul de instruire Vest-MetaTechnology folosește materiale pregătite de autor pe baza abordării propuse în cursul acestui studiu atunci când desfășoară cursuri privind dezvoltarea sistemelor informaționale de management al întreprinderii (a se vedea http://www.vest.msk.ru).

Materialele de cercetare ale disertației sunt utilizate în activități de cercetare și practice organele executive Asociația Dezvoltatorilor de Software în Economie (AREP) și membrii săi.

Principalele prevederi ale lucrării au fost raportate și discutate la:

Conferința „Soluții IBM în domeniul integrării afacerilor pentru companiile de telecomunicații”, reprezentanța IBM în Europa de Est(Moscova, 18 iunie 2002);

Simpozion „Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management” (Moscova, martie 2002);

Conferințe ale dezvoltatorilor de sisteme informatice bazate pe instrumentele corporației Centura Software Corp. (Berlin, Germania, 17-19 noiembrie 1999);

Conferința „InfoCity: practică și probleme de informatizare a orașelor” (Moscova, octombrie 1999);

Conferințe științifice și practice ale companiei „Infosoft” (Moscova, 1995-1999);

Conferința specialiștilor în domeniul ACS și CIS " Sisteme de întreprindere„(Moscova, aprilie 1998 și 28-30 aprilie 1997, organizatori: firma SoftService și reprezentanțe ale Oracle, Informix, Sybase, Borland și Centura);

A 3-a conferință anuală „Baze de date corporative 98” (Moscova, 31 martie-3 aprilie 1998 și 26-29 martie 1996, organizată de Centrul pentru Tehnologii Informaționale cu participarea Editurii Sisteme Deschise);

Conferința „Tekhnikom-97” (Moscova, 24-26 noiembrie 1997, organizatori: SoftService, Asociația Rusă a Utilizatorilor Oracle, reprezentanțele Microsoft, Borland, Computer Associates, Lucent Software).

Probleme de dezvoltare AIS

Introducerea tehnologiilor informaționale în economie, pătrunderea instrumentelor informatice și de comunicare în managementul întreprinderii la toate nivelurile, interesul tot mai mare pentru interacțiunea companiilor prin intermediul internetului necesită schimbări conceptuale în abordările de construire a AIS UE. Aceasta se referă nu numai la problemele pur tehnologice ale creării și exploatării SI, ci și abordări ale managementului afacerilor în economia societății informaționale.

AIS UP ar trebui să răspundă nevoilor de automatizare și informatizare la nivelul întregii organizații, ceea ce stabilește dezvoltatorilor de software sarcina de a: dezvolta o platformă capabilă să susțină munca unui număr mare de utilizatori; suport pentru instrumente de comunicare și standarde industriale pentru schimbul de date și protocoale de interacțiune a componentelor; integrarea dezvoltărilor existente într-un singur sistem.

Integrarea aplicațiilor eterogene într-un singur AIS ar trebui să ofere suport pentru: procese de afaceri end-to-end; interfață cu utilizator unică (portal); spațiu informațional comun.

În opinia noastră, esența problemelor puse nu constă atât în ​​aspectele tehnice ale implementării, cât în ​​necesitatea utilizării unui model fundamental nou de arhitectură AIS UE.

Să rezumăm avantajele și dezavantajele diferitelor opțiuni de arhitectură IS în ceea ce privește posibilitățile de construire a unei soluții integrate.

Centralizarea prelucrării datelor impune solicitări mari asupra serverelor. Odată cu creșterea numărului de utilizatori concurenți (ceea ce este inevitabil atunci când se automatizează procesele în întreaga întreprindere), încărcările devin excesive pentru platforma hardware și software-ul utilizat. Folosind diverse soluții hardware (clustering, multiprocesare și alte forme de combinare a resurselor de calcul), precum și procesare distribuită folosind monitoare de tranzacții, servere de aplicații și SGBD industriale puternice, puteți crea soluții cu adevărat scalabile, descarcând nodurile centrale nu numai prin creșterea puterii hardware, dar și datorită construcției adecvate a componentelor software ale sistemului.

Cu toate acestea, chiar dacă serverul central de baze de date este capabil să ofere performanța necesară, cu o astfel de construcție IS, inevitabil apar probleme în menținerea unei structuri unice a unei baze de date comune dacă componentele individuale ale software-ului IS sunt dezvoltate de companii diferite sau chiar de echipe de dezvoltare din cadrul aceeași organizație. Instalarea unei baze de date comune cu acces din programe pentru rezolvarea diverselor sarcini aplicate vă permite să oferiți un spațiu informațional comun, tehnologiile enumerate mai sus vă permit să accesați baza de date pentru un număr mare de utilizatori, dar acest lucru nu garantează funcţionare corectă cu date partajate. Rămâne problema integrității datelor logice. Atunci când se utilizează programe de la diferiți producători, devine inevitabil să se separe datele în subsisteme, eventual prin denormalizarea acestora și crearea unor structuri redundante. Arhitectura de bază comună este prezentată schematic în figura următoare (Figura 1-14). După cum reiese din diagrama de mai sus, modulele nu interacționează, adică nu există niciun apel de la un modul la altul în timp real, nu există suport operațional pentru un proces end-to-end. Datele sunt stocate în baza de date, din care sunt disponibile altor module care trebuie să conțină funcțiile de urmărire a modificărilor în ea, iar relevanța datelor depinde de frecvența verificării actualizărilor. Un exemplu de proces end-to-end ar fi o facturare de către un angajat al departamentului de vânzări. Daca foloseste un sistem CRM pentru asta, factura generata trebuie procesata in paralel cu declaratia in modulul logistic al sistemului ERP pentru rezervarea marfii, iar imediat dupa aceea - in modulul financiar pentru a mari datoria cumparatorului. Pentru a face acest lucru, modulele relevante trebuie să verifice existența unui nou cont. Dacă acest lucru nu se face în timp util, se poate emite o factură pentru articolul rezervat efectiv.

Pentru ca diferite module să funcționeze structura de ansamblu DB, acestea trebuie să fie proiectate inițial având în vedere o anumită structură de date sau să utilizeze un mecanism de metadate agreat (depozitar).

Când se utilizează o arhitectură diferită, când baze de date eterogene sunt menținute pe computere diferite (și, eventual, pe rețele diferite) și utilizate de module autonome (Figura 1-15), menținerea integrității logice a datelor este o sarcină și mai consumatoare de timp. . În acest caz, este necesar să se reglementeze și să implementeze replicarea datelor (sincronizare), unificarea directoarelor, regulile de codificare și clasificare, dezvoltarea sau implementarea mecanismului de replicare în sine. Toate acestea necesită măsuri organizatorice pentru sincronizarea bazei de date. Rămâne problema continuării automate a procesului (un exemplu cu o factură).

Platforme pentru implementarea noii arhitecturi AIS UE

Până la începutul secolului XXI au fost dezvoltate și stăpânite următoarele soluții la nivel industrial în industria IT, ceea ce a asigurat introducerea pe scară largă a IT în procesele economice:

instrument de calcul personal, constând în faptul că în multe tipuri de muncă a dispărut nevoia de intermediari între declarația de sarcină și executantul acesteia, adică angajații serviciilor funcționale ale întreprinderii sunt capabili să efectueze proceduri de informare în limita competenței lor folosind calculatoare fără a implica sau cu sprijin minim al personalului tehnic însoțitor;

mijloace de sprijin automat pentru munca comună coordonată a unui grup („echipă”) de angajați pe un singur proiect, document, sarcină etc.;

mecanism de comunicații electronice, care în multe cazuri a făcut posibilă eliminarea necesității de a transfera documente pe hârtie, pentru a minimiza nevoia de întâlniri, ceea ce este deosebit de important atunci când participanții la un anumit proces de afaceri sunt îndepărtați geografic.

Datorită acestor soluții, a devenit posibilă automatizarea majorității proceselor de lucru care au loc atât în ​​cadrul întreprinderii în activitățile sale financiare, economice, de producție și comerciale, cât și legate de funcțiile externe. Combinația de instrumente software și hardware care automatizează diverse funcții și locuri de muncă face posibilă conectarea proceselor tehnologice (pe baza echipamentelor și dispozitivelor tehnice) și a proceselor de lucru (cu participarea angajaților din toate departamentele întreprinderilor) în procesele de afaceri end-to-end. . Astfel, există o posibilitate fundamentală de rezolvare a problemei izolării punctelor de origine a datelor de centrele de stocare și prelucrare a acestora, separarea locurilor de muncă unele de altele.

Rezolvarea problemei integrării modulelor AIS și alegerea unei abordări centralizate sau descentralizate pentru organizarea interacțiunii lor este posibilă și datorită celor mai recente dezvoltări ale producătorilor de top de software de sistem: sisteme de operare, servere web, servere de aplicații, platforme DBMS și middleware. Integrarea aplicațiilor este posibilă prin utilizarea tehnologiei de dezvoltare orientată pe obiecte și a arhitecturii multi-nivel bazate pe componente. Principiul cheie aici este conceptul de interfețe de programare și regulile de modificare și extindere a acestora (IDL).

Pentru a lucra într-un mediu eterogen distribuit, cum ar fi Internetul, sunt dezvoltate în mod activ specificațiile serviciilor web, fiecare dintre acestea putând implementa una sau mai multe proceduri sau funcții de afaceri (proceduri de afaceri, funcții). OASIS, BPMI și IBM, Microsoft și BEA au publicat specificațiile de reglementare a fluxului de lucru BPEL4WS (Business Process Execution Language for Web Services), XLANG și WSFL (Web Services Flow Language) și coaliția WfML - XPDL (XML Process Definition Language) .

Tendința este de a combina componente cu interfețe deschise de servicii web în subsisteme care execută cicluri de procese de afaceri complete logic. În acest caz, componentele pot fi localizate pe diverse servere de aplicații distribuite în rețea și pot lucra cu una sau mai multe baze de date. Variind numărul și relațiile componentelor, numărul și locația serverelor de rețea, posibilitatea de a înlocui componente sau de a le muta în rețea fără pierderea compatibilității, este posibilă construirea unui AIS care să mențină un echilibru între centralizare și descentralizare în întreprindere. management.

Nu există obstacole tehnice în calea implementării unei astfel de arhitecturi. Serverele de aplicații industriale moderne (de exemplu, MTS / COM + / .Net, ONE sau J2EE / EJB) vă permit să construiți sisteme cu mai multe niveluri, să oferiți o platformă comună pentru accesarea diferitelor servicii web, să asigurați integritatea tranzacțională a operațiunilor, echilibrarea sarcinii cu acces competitiv a zeci de mii de utilizatori în timp real, precum și garantarea toleranței la erori și recuperarea după defecțiuni.

O realizare importantă a industriei IT sunt standardele care au devenit larg răspândite și recunoscute de producătorii de software de top: protocoalele de interacțiune a componentelor (COM/DCOM, CORBA, Java RMI) și formatele de schimb de date (EDI, XML,).

Standardul EDI și variantele sale industriale (EDIFACT, XI2, HIPAA etc.) sunt utilizate în sectoarele financiare și industriale America de Nordși Europa de la mijlocul anilor 1970 și domină astăzi în întreaga lume. Odată cu popularitatea tot mai mare a XML pe Internet, EDI a fost tradus în XML.

Pe baza XML (DTD și XDR), datele au fost dezvoltate, structurate și formatate în diferite domenii economice sub formă de așa-numite dicționare de subiecte sau tipuri de documente, de exemplu, WIDL, OFX, FpML, IFX, XBRL, CRML și multe altele în Occident, precum și CommerceML.ru și XML Partnership/ARB în Rusia. Societatea Americană pentru Managementul Producției și Inventarului APICS, care certifică sistemele de clasă ERP/MRP, publică specificații entitati economiceîn format XML, de exemplu, structura și formatul datelor clienților sau ale facturii. Auto-documentarea XML oferă o înțelegere clară a datelor atât de către oameni, cât și de către programe.

Arhitectura AIS UE

Pentru a construi un model de arhitectură AIS UE, vom considera o întreprindere ca un set de resurse de muncă, financiare, materiale și informaționale implicate în procesele de afaceri pentru a atinge obiectivele de afaceri ale unei întreprinderi. Aici, termenul de obiective de afaceri se referă la obiectivele strategice pe termen lung stabilite de proprietari și managerii de top, precum și obiectivele actuale atribuite de managerii de top și de mijloc. Un proces de afaceri sau un proces de afaceri este o secvență de acțiuni ale angajaților, operațiuni la locurile de muncă, precum și funcții efectuate de software și mijloace tehniceîn mod automat. Să numim fiecare acțiune sau secvența lor o etapă a procesului. Sinonime pentru acțiuni pot fi și operațiuni, proceduri. Dacă o etapă necesită acțiunile unui angajat (un grup de rol, un reprezentant sau șef al unui departament, precum și o persoană care deține o funcție oficială), atunci se mai numește și sarcină, iar angajatul este numit executor. Secvența de acțiuni într-un proces de afaceri poate fi ambiguă, adică o descriere a procesului sub forma unui grafic direcționat poate include ramificarea cu condiții pentru trecerea de la o etapă la alta. Lanțurile tipice de etape pot fi împărțite în subprocese. Deplasarea sarcinilor pe etapele specificate ale procesului se numește rută. Dacă procesul nu poate fi descris din cauza tranzițiilor arbitrare între etape, decizia despre care este luată de executant în timpul executării sarcinii în etapa curentă, atunci acest caz se numește rutare liberă.

AIS PM ar trebui să permită descrierea formală a proceselor de afaceri într-o formă grafică sub forma unui grafic direcționat (digraf), ale cărui vârfuri sunt etapele, iar marginile sunt tranzițiile dintre etape. Într-un caz particular, graficul procesului de afaceri arată ca un grafic de rețea, unde vârfurile reprezintă locurile de muncă cu durata lor, iar marginile orientate (săgețile) arată secvența lucrărilor. În conformitate cu descrierea procesului, numită hartă a procesului, AIS UE trebuie să gestioneze resursele (sau, mai precis, să ajute managerii întreprinderii să le gestioneze), să atribuie sarcini și executanții acestora și, de asemenea, să apeleze (active) software și hardware pentru a rula proceduri automate.

Parametrii de scară a întreprinderii afectează organizarea managementului la o anumită întreprindere, ceea ce se reflectă în cerințele pentru AIS UE. Pe de altă parte, AIS UE afectează amploarea întreprinderii, de exemplu, contribuind la creșterea afacerii. Modificarea unuia dintre parametri presupune actualizarea AIS în același mod în care introducerea AIS poate modifica organizarea managementului.

Scopul concentrării pe procesele de afaceri la construirea AIS UE este de a găsi o platformă comună pe baza căreia să fie posibilă modificarea adecvată a AIS fără a necesita o reorganizare completă a sistemului. Această platformă este modelarea proceselor de afaceri prin software de management al proceselor.

Ca nucleu al AIS PM, este necesar să se dezvolte un sistem care să combine mai multe funcții discutate în revizuirea sistemelor de management al proceselor (paragrafele „1.1.7 Sisteme de management al documentelor” la pagina 31 și „1.1.8 Sisteme de management al proceselor” la pagina 34). Printre acestea: Workflow - un subsistem pentru gestionarea proceselor de lucru și tehnologice care asigură rutarea predefinită și gratuită a sarcinilor între executanți; Docflow - un subsistem pentru gestionarea fluxului de documente și rutarea documentelor cu urmărirea stărilor acestora; Groupware - un subsistem pentru susținerea funcțiilor de atribuire operațională a sarcinilor și de rutare gratuită (ad-hoc) a sarcinilor între membrii unui grup de executanți; Flux de date - date de rutare, pachete de date, mesaje între aplicații.

Spre deosebire de practica acceptată de utilizare autonomă a sistemelor de acest fel, presupunem aici prezența unei hărți comune a proceselor, a unui modul comun pentru procesarea etapelor procesului, a unui mecanism comun de atribuire a executanților și a sarcinilor și datelor de rutare.

Astfel, datele tehnologice generate de dispozitivele tehnice, datele faptice introduse în IS de către utilizatori la locurile de muncă (inclusiv documentele primare), precum și datele generate de aplicații software, vor fi introduse în AIS UE și disponibile consumatorilor de informații în timp real. .

Schematic, ciclul de viață al procesării datelor în AIS UE este prezentat în figura următoare (Figura 2-2). Datele introduse manual sau primite de la componentele software sunt formalizate ca document, care este prelucrat în continuare de modulul de flux de lucru în conformitate cu harta procesului. De-a lungul rutei de procesare (dacă setarea sistemului o cere), subsistemul de gestionare a documentelor apelează modulele subsistemelor funcționale pentru procesarea tranzacțiilor financiare, de afaceri și de alt tip. Ca rezultat, acreditările sunt stocate în baze de date structurate. La rândul lor, documentele în sine sunt stocate într-o bază de date de stocare sau nestructurată. Toate aceste baze de date trebuie să fie disponibile modulelor analitice ale subsistemului de raportare pentru a genera rapoartele necesare.

Experiență în implementarea practică a modelului AIS UE

Din 1995 până în 1999, sub îndrumarea autorului disertației, a fost dezvoltat un sistem de automatizare integrată a managementului întreprinderii „Flagman” al companiei „Infosoft”, care acest moment implementat în peste o sută de întreprinderi mari și mijlocii industriale, de construcții, comerciale, agricole și organizații bugetare din Rusia și țările CSI. Sistemul continuă să se dezvolte pe baza nucleului dezvoltat de autor, iar până în 2002 „Flagship” include mai mult de zece subsisteme principale, prezentate în figura următoare (Figura 3-2):

Baza sistemului „Flagship” este modulul de bază „Gestionarea documentelor”, care este responsabil pentru introducerea, procesarea, rutarea și tipărirea tuturor documentelor primare. Alte module de bază sunt „Administrare” și „Instrumente”, comune tuturor modulelor funcționale. Acestea vă permit să configurați grupuri de roluri și drepturi de acces, stații de lucru până la elemente de meniu, machete de documente și șabloane de rapoarte.

Avantajele modelului implementat au fost o singură intrare a documentelor primare, generarea conturiîn subsisteme funcționale bazate pe aceste documente, unificarea lucrărilor cu documentele primare.

Dezvoltarea rapidă a subsistemelor și lipsa de standardizare a interacțiunii lor a dus la faptul că integrarea s-a realizat în jurul unei baze de date centrale și a unor tabele comune. Dacă nu luăm în considerare arhitectura cu două niveluri, a cărei alegere a fost determinată de nivelul de dezvoltare a instrumentelor de dezvoltare în 1995, atunci dependența încrucișată a modulelor a devenit principala problemă pentru dezvoltarea sistemului. Primele sale implementări au scos la iveală insuficiența funcțiilor de automatizare a fluxului de lucru doar prin rutarea documentelor și au ridicat problema necesității implementării unui modul de management al proceselor (flux de lucru).

Dacă luăm în considerare implementarea mai detaliat, atunci modulul de gestionare a documentelor este o bibliotecă de obiecte incluse în toate subsistemele și, de asemenea, compilat ca un modul de sine stătător. Biblioteca include instrumente pentru setarea tipurilor și variantelor de documente, alcătuirea câmpurilor, formulare de introducere și editare, o listă de stări, combinații posibile de tranziții de la stare la stare, o listă de operații cu referire la module funcționale, șabloane și tipărire. formulare, precum și reguli pentru formarea registrelor și jurnalelor de documente.

Operațiunile cu documente își schimbă starea și apelează și funcțiile subsistemelor de aplicații. Lista de funcții este încorporată în fiecare subsistem și este specifică acestuia. Pentru programatorii însoțitori implicați în configurarea sistemului, sunt disponibile parametrii funcției și capacitatea de a lega câmpurile de document la aceștia folosind formule. Acest lucru vă permite să automatizați majoritatea tranzacțiilor financiare, precum și funcțiile logistice, evidența personaluluiși salarizare, dar implementarea completă necesită încă un limbaj de scripting.

Sistemul are un generator de rapoarte încorporat comun tuturor subsistemelor. Deoarece sistemul se bazează pe principiul integrării în jurul unei baze de date centrale, generatorul are acces la toate datele, indiferent dacă acestea aparțin modulelor. Rapoartele sunt clasificate într-o structură ierarhică, fiecare dintre aspectele de raport conține un șablon pentru previzualizare și tipărire și interogări SQL pentru generarea setului de date rezultat. Rapoartele generate pot fi prelucrate ulterior ca documente.

De asemenea, trebuie remarcat faptul că sistemul Flagship implementează un sistem unificat aspect subsisteme. Modulul de administrare generală pentru elementele interfeței cu utilizatorul, funcțiile AWP, inclusiv meniurile și barele de instrumente, vă permite să personalizați aspectul într-un mod uniform.

În prezent, dezvoltarea IT necesită actualizarea platformei sistemului Flagman. În primul rând, este necesar să îl transferați într-o arhitectură cu trei niveluri și să dezvoltați modulul de gestionare a documentelor într-un sistem de management al proceselor complet funcțional. De asemenea, este necesar să se dezvolte mecanisme de integrare a aplicațiilor externe, deoarece sistemul dispune doar de mijloacele de import și export de date.

Cu toate acestea, numeroase exemple de implementare și exploatare industrială cu succes a sistemului Flagman, creșterea numărului vânzărilor acestuia în perioada 2001-2002 mărturisesc eficiența economică a soluției de automatizare a întreprinderilor din diverse domenii de activitate, industrii și scară.

În februarie 1999, sistemul „Flagman” al companiei „Infosoft”, creat sub îndrumarea autorului, a fost recunoscut drept cea mai bună dezvoltare rusă din setul de instrumente Centura Team Developer de către Centura Software Corp. (SUA) și compania „Interfață” (Rusia). În 1999, 2000 și 2001 CIS „Flagman” a fost certificat ca sistem informatic la nivel de întreprindere de către experții juriului competiției „Business-Soft”, susținut de Asociația Dezvoltatorilor de Software în Domeniul Economiei (AREP), TSIES „Serviciul Programe de Afaceri”. ”, jurnalul „Contabilitatea” și „Ziarul financiar”.

În aproape fiecare domeniu, oamenii folosesc un fel de model (matematic, fizic sau computer) pentru a obține o imagine mai clară a ceea ce se întâmplă în procesele din viața reală.

Există 2 moduri de a descrie modelele:

1) static, având în vedere structura modelului, ᴛ.ᴇ. astfel de aspecte ale acestuia în care timpul poate fi neglijat;

2) dinamică, având în vedere fluxul evenimentelor, ᴛ.ᴇ. modificarea în timp a fenomenelor simulate, care nu poate fi neglijată din punct de vedere al sarcinilor în curs de rezolvare.

Orice companie și activitățile sale pot fi privite din punctul de vedere al diferitelor persoane: operator, director executiv, client, acționar, partener, vânzător etc. Fiecare categorie de oameni are nevoie de modele de afaceri diferite.

Director executiv ar trebui să aibă o imagine de ansamblu: procese, produse, finanțe, perspective etc., ᴛ.ᴇ. imagine integrată în ansamblu. Pentru ca personalul de conducere să ia deciziile corecte în orice situație, este extrem de important să existe un set de modele care să descrie diferite aspecte ale activităților companiei și ale relațiilor dintre acestea. În modelele utilizate la nivelul superior de management, cel mai important lucru este ϶ᴛᴏ concizia și claritatea. Ar trebui să sublinieze punctele principale, iar detaliile sunt ascunse.

Unul dintre cele mai importante modele este în prezent modelul de afaceri, care definește funcțiile firmei în lumea exterioară.

Figura 1 - Modelul unei companii organizate ierarhic

Modelele de ciclu de viață existente determină ordinea de execuție a etapelor în procesul de creare a unui sistem, precum și criteriile de trecere de la o etapă la alta. Următoarele trei modele sunt cele mai utilizate pe scară largă.

Printre modelele binecunoscute ale ciclului de viață AIS, pot fi distinse modele în cascadă, iterative și spirale.

Model în cascadă (până la 70 ᴦ.ᴦ.) implică trecerea la următoarea etapă după finalizarea lucrărilor etapei precedente. Acest model este utilizat în construcția AIS, pentru care, la începutul dezvoltării, toate cerințele pot fi formulate destul de precis și complet. Acest lucru oferă dezvoltatorilor libertatea de a le implementa cât mai bine din punct de vedere tehnic. Această categorie include sisteme complexe de decontare, sisteme în timp real și altele.

Figura 2 - Schema modelului în cascadă

Avantaje model cascada:

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

2) etapele de lucru efectuate într-o succesiune logică vă permit să planificați momentul finalizării acestora și costurile corespunzătoare.

dezavantaje model cascada:

1) întârziere în obținerea rezultatelor;

2) importanța extremă a revenirii la etapele anterioare.

Modelul în cascadă al ciclului de viață AIS este caracterizat prin automatizarea sarcinilor individuale nelegate care nu necesită integrarea și compatibilitatea informațiilor, software, interfață tehnică și organizațională. Ca parte a rezolvării sarcinilor individuale, modelul în cascadă al ciclului de viață s-a justificat în termeni de timp de dezvoltare și fiabilitate. Aplicarea modelului în cascadă a ciclului de viață AIS la proiecte mari și complexe datorită duratei lungi a procesului de proiectare și variabilității cerințelor în acest timp poate duce la infezabilitatea practică.

Model iterativ pas cu pas. Acest model de creare a AIS presupune prezența buclelor de feedback între etape. Avantajul unui astfel de model este, în esență, că ajustările între etape oferă mai multă flexibilitate și mai puțin efort decât modelul în cascadă. În același timp, durata de viață a fiecărei etape poate fi prelungită pentru întreaga perioadă de creare a sistemului.

Figura 3 - Schema unei etape model iterativ

Dezavantaje: De regulă, din cauza unui număr mare de iterații, apar discrepanțe în deciziile de proiectare și documentația finalizate. Complexitatea arhitecturii funcționale și de sistem a AIS creat, dificultatea de utilizare a documentației de proiectare provoacă imediat importanța extremă a reproiectării întregului sistem în etapele de implementare și operare. Ciclul lung de viață al dezvoltării AIS se încheie cu etapa de implementare, după care începe ciclul de viață al creării unui nou AIS.

model în spirală(80-90 ᴦ.ᴦ.) - pe baza etapelor inițiale ale ciclului de viață: analiză, proiectare preliminară și detaliată.

Fiecare tură a spiralei corespunde unui model pas cu pas pentru crearea unui fragment sau a unei versiuni a sistemului, pe care obiectivele și caracteristicile proiectului sunt clarificate, calitatea acestuia este determinată și munca următoarei ture a sistemului. este planificată spirală. Problema principală este determinarea momentului de tranziție la etapa următoare. Pentru a o rezolva, este extrem de important să se introducă limite de timp pentru fiecare dintre etapele ciclului de viață. Tranziția se realizează în conformitate cu planul, care este întocmit pe baza datelor statistice obținute în proiectele anterioare și a experienței personale a dezvoltatorilor. Dezavantajul acestei abordări îl reprezintă problemele nerezolvate și erorile făcute în etapele de analiză și proiectare. Οʜᴎ poate duce în etapele ulterioare la probleme și chiar la eșecul întregului proiect. Din acest motiv, analiza și proiectarea trebuie efectuate cu o grijă deosebită.

Figura 4 - Schema modelului spiralat

Modelul ciclului de viață în spirală se bazează pe utilizarea tehnologiei prototip sau a tehnologiei RAD ( Dezvoltarea rapidă a aplicațiilor - tehnologii de dezvoltare rapidă a aplicațiilor). Conform acestei tehnologii, AIS este dezvoltat prin extinderea prototipurilor software, urmând calea de la specificarea cerințelor la specificarea codului programului. Desigur, cu această tehnologie, numărul de iterații este redus și există mai puține erori și inconsecvențe care sunt extrem de important de corectat în iterațiile ulterioare. În același timp, proiectarea AIS merge mai rapid, iar crearea documentației de proiectare este simplificată. Pentru a se potrivi mai exact cu documentația de proiectare dezvoltată de AIS, se acordă din ce în ce mai multă importanță menținerii unui depozit la nivelul întregului sistem și utilizării tehnologiilor CASE.

Ciclul de viață atunci când se utilizează tehnologia RAD presupune participarea activă a utilizatorilor finali ai viitorului sistem la toate etapele de dezvoltare și include 3 etape principale de reinginiere a informațiilor:

1) analiza si planificarea strategie de informare : utilizatorii, împreună cu dezvoltatori specialiști, participă la identificarea zonei cu probleme;

2) proiecta : utilizatorii participă la proiectarea tehnică sub îndrumarea unor dezvoltatori specialiști;

3) implementare : Dezvoltatorii instruiesc utilizatorii să lucreze în noul mediu AIS.

Dezvoltarea și proiectarea AIS începe cu crearea unui model conceptual pentru utilizarea sistemului. În primul rând, ar trebui determinată fezabilitatea creării unui sistem, funcțiile sale specifice și sarcinile care urmează să fie automatizate. Trebuie făcută o evaluare nu numai a obiectivelor, ci și a posibilităților de creare a unui sistem. În continuare, se efectuează analiza cerințelor pentru AIS, proiectarea detaliată, relația dintre etape, programare și testare, minimizarea pierderilor în timpul trecerii de la un nivel de prezentare a informațiilor la altul, integrarea în sistemul existent, implementarea și suportul.

Există trei clase de metodologii de proiectare AIS:

Modelarea conceptuală a disciplinei;

Identificarea cerințelor și specificarea unui sistem informațional prin prototiparea acestuia;

Arhitectura de sistem a instrumentelor software suportate de instrumentele tehnologice CASE (CASE - Computer Aided Software Engineering - tehnologie pentru crearea și întreținerea software-ului pentru diverse sisteme).

Metodologiile moderne de proiectare a sistemului ar trebui să ofere o descriere a obiectelor de automatizare, o descriere a funcționalității AIS, o specificație de proiect care să garanteze atingerea caracteristicilor specificate ale sistemului, un plan detaliat pentru crearea unui sistem cu o evaluare a timpului de dezvoltare și o descriere a implementării unui anumit sistem.

Specificație - o descriere precisă, completă și articulată a cerințelor pentru o anumită sarcină.

 

Ar putea fi util să citiți: