3.1 Definirea unui model de ciclu de viață AIS
sub model ciclu de viață Dezvoltarea produsului software este înțeleasă ca o structură care determină succesiunea execuției și relația proceselor, acțiunilor și sarcinilor efectuate de-a lungul ciclului de viață al dezvoltării produsului software. Următoarele modele de ciclu de viață de dezvoltare a produselor software sunt cele mai utilizate pe scară largă (Tabelul 1. Scurte caracteristici Modele de ciclu de viață AIS): model cascadă sau cascadă (model cascadă); model în formă de v (model în formă de v); model de prototipare (model de prototip); modelul de dezvoltare rapidă a aplicațiilor sau modelul RAD (modelul de dezvoltare rapidă a aplicațiilor RAD), modelul cu mai multe treceri (modelul incremental); model în spirală.
Tabelul 1. Scurte caracteristici ale fiecăruia dintre modelele enumerate
| Nume | caracteristici |
| Model în cascadă | Simplu și ușor de utilizat. Este necesar un control strict constant asupra progresului lucrării. Software-ul dezvoltat nu este disponibil pentru modificare |
| model în formă de v | Ușor de folosit. Se pune accent pe testarea și compararea rezultatelor fazelor de testare și proiectare |
| Model de prototip | O implementare parțială „rapidă” a sistemului este creată înainte de elaborarea cerințelor finale. Prevăzut Părereîntre utilizatori și dezvoltatori pe parcursul unui proiect. Cerințele utilizate nu sunt complete |
| Model de dezvoltare rapidă a aplicațiilor | Echipe de proiect mici (3 ... 7 persoane) și sunt formate din specialiști de înaltă calificare. Durata ciclului de dezvoltare redusă (până la 3 luni) și performanță îmbunătățită. Reutilizarea codului și automatizarea procesului de dezvoltare |
| Model cu mai multe treceri | Un sistem de lucru este rapid creat. Reduce posibilitatea de a face modificări în timpul procesului de dezvoltare. Migrarea de la implementarea curentă la o versiune nouă nu este posibilă în timp ce implementarea parțială actuală este în curs de construire |
| model în spirală | Acoperă modelul cascadă. Desparte fazele în părți mai mici. Permite un design flexibil. Analizează și gestionează riscurile. Utilizatorii cunoaște produsul software într-un stadiu mai devreme datorită prototipurilor |
3.2 Modelul în cascadă
În omogen sisteme de informareÎn anii 1970 și 1980, produsele software pentru aplicații erau o singură entitate. Pentru a dezvolta acest tip de produs software, a fost folosit un model în cascadă sau „cascada”.
Modelul în cascadă al unui produs software este similar cu modelul unui sistem de control automat (vezi Capitolul 1, Fig. 1).
Acest proces este, de regulă, de natură iterativă: rezultatele etapei următoare provoacă adesea schimbări în deciziile de proiectare dezvoltate în etapele anterioare. Astfel, există o nevoie constantă de a reveni la etapele anterioare și de a clarifica sau revizui mai devreme deciziile luate. Ca rezultat, procesul real de dezvoltare ia o formă diferită (vezi Capitolul 1, Figura 2)
3.3 V-model
Acest model (Fig. 5) a fost dezvoltat ca o variație a modelului cascadei, în care Atentie speciala se acordă verificării și certificării produsului software. Modelul arată că testarea produsului este discutată, proiectată și planificată la începutul ciclului de viață al dezvoltării.
Din modelul în cascadă, modelul în formă de V a moștenit o structură secvențială, conform căreia fiecare fază ulterioară începe numai după finalizarea cu succes a fazei anterioare.
Acest model se bazează pe o abordare sistematică a problemei, pentru care sunt definiți patru pași de bază: analiză, proiectare, dezvoltare și revizuire. Analiza implică planificarea și cerințele proiectului. Designul este împărțit în nivel înalt și detaliat (nivel scăzut). Dezvoltarea include codificare, revizuire - tipuri diferite testarea.
Modelul arată clar relația dintre fazele analitice și fazele de proiectare care preced codificarea și testarea. Săgețile întrerupte arată că aceste faze ar trebui luate în considerare în paralel.
Modelul include următoarele faze:
Redactarea cerințelor și planificarea proiectului - se determină cerințele de sistem și se realizează planificarea lucrărilor;
Pregătirea cerințelor pentru produs și analiza acestora - se întocmește o specificație completă a cerințelor pentru produsul software;
Design la nivel înalt - structura este definită software, relația dintre principalele sale componente și funcțiile pe care le implementează;
Proiectare detaliată - se determină algoritmul de funcționare al fiecărei componente;
Codare - se realizează transformarea algoritmilor în software finit;
Testare unitară - fiecare componentă sau modul al produsului software este testat;
Testare de integrare - se realizează integrarea produsului software și testarea acestuia;
Testarea sistemului - se verifică funcționarea produsului software după ce acesta este plasat în mediul hardware în conformitate cu specificația cerințelor;
Operare și întreținere - lansarea unui produs software în producție. În această fază, produsul software poate fi modificat și actualizat.
Fig.5 Model în formă de V
Avantajele modelului în formă de V:
1) Un mare rol este acordat verificării și certificării produsului software, începând din fazele incipiente ale dezvoltării acestuia, toate acțiunile sunt planificate;
2) Se presupune atestarea și verificarea nu numai a produsului software în sine, ci și a tuturor datelor interne și externe primite;
3) Progresul lucrării poate fi urmărit cu ușurință, deoarece finalizarea fiecărei etape este o piatră de hotar.
Pe lângă aceste avantaje, modelul are și o serie de dezavantaje:
iterațiile dintre faze nu sunt luate în considerare; este imposibil să faci schimbări în diferite etape ale ciclului de viață; testarea cerințelor are loc prea târziu, așa că efectuarea de modificări afectează programul.
Este oportun să folosiți acest model în dezvoltarea de produse software, principala cerință pentru care este fiabilitatea ridicată.
Produsul și crearea de carduri convenabile pentru completarea atributelor bazei de date: simplitatea creării de legături și modernizarea acestora. Capitolul II. Dezvoltarea unui program de automatizare a activităților flotei de taxiuri 2.1 Analiza cerințelor clienților Program Automatizat la locul de muncă dispeceratul taxi este dezvoltat după modelul spiral al ciclului de viață al sistemelor informatice automatizate. La fiecare etapă a creației...
Sisteme. Principal documente normative, care reglementează procesul de creare a oricărui proiect IS și IT, sunt GOST-uri și complexele lor pentru crearea și documentarea tehnologia de informație, sisteme automatizate, software-ul, organizarea și prelucrarea datelor, precum și documentele de conducere ale Comisiei Tehnice de Stat a Rusiei privind dezvoltarea, fabricarea și operarea software-ului și ...
Abordarea în cascadă s-a dovedit în construcția SI, pentru care chiar la începutul dezvoltării este posibil să se formuleze toate cerințele destul de precis și complet pentru a oferi dezvoltatorilor libertatea de a le implementa din punct de vedere tehnic cât mai bine posibil. Această categorie include sisteme complexe cu un număr mare de sarcini de natură computațională a unui sistem în timp real etc.
Modelul ciclului de viață AIS- este o structură care descrie procesele, activitățile și sarcinile care se desfășoară în timpul dezvoltării, exploatării și întreținerii de-a lungul întregului ciclu de viață al sistemului.
Alegerea unui model de ciclu de viață depinde de specificul, scara, complexitatea proiectului și setul de condiții în care este creat și funcționează AIS.
Modelul ciclului de viață AIS include:
Rezultatele muncii în fiecare etapă;
Evenimente cheie sau puncte de finalizare și luare a deciziilor.
În conformitate cu modelele de ciclu de viață a software-ului bine-cunoscute, modelele de ciclu de viață AIS sunt determinate - cascadă, iterativă, spirală.
I. Modelul în cascadă descrie abordarea clasică a dezvoltării sistemelor în orice domeniu; a fost utilizat pe scară largă în anii 1970 și 80.
Modelul în cascadă oferă o organizare secvențială a muncii, iar principala caracteristică a modelului este împărțirea tuturor lucrărilor în etape. Trecerea de la etapa anterioară la următoarea are loc numai după finalizarea completă a tuturor lucrărilor precedentei.
Aloca cinci stadii de dezvoltare stabile, practic independente de domeniul de studiu
Pe primul La etapa se studiaza zona problematica, se formuleaza cerintele clientului. Rezultatul acestei etape sunt termenii de referință (sarcina de dezvoltare), conveniți cu toate părțile interesate.
Pe parcursul al doilea etapă, conform cerințelor termeni de referinta, se dezvoltă anumite soluții de proiectare. Rezultatul este un set de documentație de proiect.
Al treilea etapa - implementarea proiectului; în esență, dezvoltarea software-ului (codarea) în conformitate cu deciziile de proiectare din etapa anterioară. Metodele de implementare nu au o importanță fundamentală. Rezultatul etapei este un produs software finit.
Pe Al patrulea La etapa, software-ul primit este verificat pentru conformitatea cu cerințele prevăzute în termenii de referință. Operarea de probă face posibilă dezvăluirea diferitelor tipuri de deficiențe ascunse care se manifestă în condiții reale de funcționare AIS.
Ultimul pas este capitularea proiect finalizat, iar principalul lucru aici este să convingi clientul că toate cerințele sale sunt îndeplinite pe deplin.
Fig. 1.1 Modelul în cascadă AIS LC
Etapele de lucru din cadrul modelului cascadă sunt adesea menționate ca părți ale ciclului proiectului AIS, deoarece etapele constau în multe proceduri iterative pentru rafinarea cerințelor sistemului și a opțiunilor de proiectare. Ciclul de viață al AIS este mult mai complicat și mai lung: poate include un număr arbitrar de cicluri de rafinare, modificări și completări la deciziile de proiectare deja adoptate și implementate. În aceste cicluri are loc dezvoltarea AIS și modernizarea componentelor sale individuale.
Avantajele modelului de cascadă:
1) la fiecare etapă, se formează un set complet de documentație de proiectare care îndeplinește criteriile de completitudine și coerență. În etapele finale, este elaborată documentația utilizatorului, care acoperă toate tipurile de suport AIS prevăzute de standarde (organizațional, informațional, software, tehnic etc.);
2) execuția secvențială a etapelor de lucru vă permite să planificați timpul de finalizare și costurile corespunzătoare.
Modelul în cascadă a fost dezvoltat inițial pentru a rezolva diferite tipuri de probleme de inginerie și nu și-a pierdut 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 destul de precis 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 oricare dintre etape apar, de regulă, în etapele ulterioare de lucru, ceea ce duce la necesitatea unei retururi;
Complexitatea lucrărilor paralele la proiect;
Supraîncărcare excesivă de informații a fiecărei etape;
Complexitatea managementului de proiect;
Nivel ridicat de risc și nefiabilitatea investițiilor.
Întârziere în obținerea rezultatelor Se manifestă prin faptul că într-o abordare consecventă a dezvoltării, rezultatele sunt convenite cu părțile interesate numai după finalizarea următoarei etape de lucru. Ca urmare, se poate dovedi că AIS dezvoltat nu îndeplinește cerințele, iar astfel de inconsecvențe pot apărea în orice stadiu de dezvoltare; în plus, erorile pot fi introduse neintenționat atât de către analiști, cât și de către programatori, deoarece nu trebuie să fie bine versați în domeniile pentru care este dezvoltat AIS.
Reveniți la etapele anterioare. Acest dezavantaj este o manifestare a celui precedent: lucrul în faze secvenţiale asupra proiectului poate duce la faptul că erorile făcute în etapele anterioare sunt detectate doar în etapele ulterioare. Drept urmare, proiectul revine la etapa anterioară, este procesat și abia apoi transferat la lucrările ulterioare. Acest lucru poate provoca o întrerupere a programului și poate complica relația dintre echipele de dezvoltare care efectuează etapele individuale.
Cea mai proastă opțiune este atunci când defectele etapei anterioare sunt găsite nu în etapa următoare, ci mai târziu. De exemplu, în etapa de operare de probă, pot apărea erori în descrierea domeniului subiectului. Aceasta înseamnă că o parte din proiect trebuie să fie readusă la stadiul inițial de lucru.
Complexitatea muncii paralele legat de necesitatea de a coordona diferitele 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 atent trebuie efectuată sincronizarea, cu atât mai dependente unele de celelalte echipe de dezvoltare. Ca urmare, avantajele muncii paralele se pierd pur și simplu; lipsa paralelismului afectează negativ organizarea muncii întregii echipe.
Problemă supraîncărcare informațională apare din dependența puternică dintre diferitele grupuri de dezvoltatori. Faptul este că atunci când se efectuează modificări la una dintre părțile proiectului, este necesar să se informeze acei dezvoltatori care l-au folosit (au putut folosi) în munca lor. Cu un număr mare de subsisteme interconectate, sincronizarea documentației interne devine o sarcină majoră separată: dezvoltatorii trebuie să se familiarizeze constant cu modificările și să evalueze modul în care aceste modificări vor afecta rezultatele obținute.
Complexitatea managementului de proiectî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 compoziției documentației transferate.
In cazul depistarii unor erori in lucrare este necesara revenirea la etapele anterioare; munca curentă a celor care au greșit este întreruptă. Consecința acestui lucru este de obicei o întârziere în implementarea proiectelor corectate și a noilor proiecte.
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 legături î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 durează mai mult fiecare etapă de dezvoltare și cu atât relația dintre părțile individuale ale proiectului este mai complexă, numărul cărora crește și el. Mai mult, rezultatele dezvoltării pot fi de fapt văzute și evaluate doar în etapa de testare, adică după finalizarea etapelor de analiză, proiectare și dezvoltare, a căror implementare necesită timp și bani considerabil.
O evaluare întârziată creează probleme serioase în identificarea erorilor de analiză și proiectare - este necesară o revenire la etapele anterioare și o repetare a procesului de dezvoltare. Cu toate acestea, o revenire la etapele anterioare poate fi asociată nu numai cu erori, ci și cu schimbări care au avut loc în domeniul subiectului sau în cerințele clienților în timpul dezvoltării. În același timp, nimeni nu garantează că subiectul nu se va schimba din nou până când următoarea versiune a proiectului este gata. De fapt, aceasta înseamnă că există posibilitatea unui „ciclu” al procesului de dezvoltare: costurile proiectului vor crește constant, iar termenele limită pentru livrarea produsului finit vor fi întârziate în mod constant.
II. Model iterativ (Model treptat cu control intermediar) este o serie de cicluri (pași) scurte de planificare, implementare, studiu, acțiune.
Crearea unui AIS complex implică coordonarea soluțiilor de proiectare obținute în timpul implementării sarcinilor individuale. Abordarea de proiectare „de jos în sus” necesită astfel de iterații ale returnărilor, atunci când soluțiile de proiectare pentru sarcini individuale sunt combinate în soluții de sistem comune. În acest caz, este necesar să se revizuiască cerințele formate anterior.
Avantaj al modelului iterativ este că ajustările între etape asigură o intensitate mai mică a muncii de dezvoltare în comparație cu modelul în cascadă.
Defecte model iterativ:
· durata de viață a fiecărei etape este prelungită pe întreaga perioadă de lucru;
· datorită numărului mare de iterații, există discrepanțe în implementarea deciziilor de proiectare și a documentației;
subtilități ale arhitecturii
· Dificultăţile în utilizarea documentaţiei de proiect î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 a AIS. În același timp, crește importanța etapelor inițiale, precum analiza și proiectarea, care verifică și justifică fezabilitatea soluțiilor tehnice prin realizarea de prototipuri.
Fiecare iterație este un ciclu complet de dezvoltare care duce la lansarea unei versiuni interne sau externe a unui produs (sau a unui subset al produsului final) care este îmbunătățită de la iterație la iterație pentru a deveni un sistem complet (Figura 1.2).
Orez. 1.2. Model în spirală al ciclului de viață AIS
Astfel, fiecare tură a spiralei corespunde creării unui fragment sau a unei versiuni a unui produs software, specifică scopurile și caracteristicile proiectului, determină calitatea acestuia și planifică munca la următoarea tură a spiralei. Fiecare iterație servește la aprofundarea și specificarea consecventă a detaliilor proiectului, în urma căruia este selectată o opțiune rezonabilă pentru implementarea finală.
Utilizarea modelului în spirală vă permite să treceți la următoarea etapă a proiectului fără a aștepta finalizarea celei curente - lucrarea neterminată poate fi făcută la următoarea iterație. Sarcina principală a fiecărei iterații este de a crea un produs funcțional pentru demonstrarea utilizatorilor cât mai repede posibil. Astfel, procesul de introducere a clarificărilor și completărilor în proiect este mult simplificat.
Abordarea spirală a dezvoltării software depășește majoritatea deficiențelor modelului cascadă, în plus, oferă o serie de caracteristici suplimentare făcând procesul de dezvoltare mai flexibil.
Avantaje abordare iterativă:
Dezvoltarea iterativă simplifică foarte mult introducerea modificărilor în proiect atunci când se schimbă cerințele clienților;
Când se utilizează modelul în spirală, elementele individuale ale AIS sunt integrate treptat într-un singur întreg. Deoarece integrarea începe cu mai puține elemente, există mult mai puține probleme în timpul implementării sale;
Reducerea nivelului riscurilor (o consecință a avantajului anterior, deoarece riscurile sunt detectate î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 să se facă modificări tactice produsului în curs de dezvoltare. Deci, este posibil să reduceți timpul de dezvoltare prin reducerea funcționalității sistemului sau să utilizați produse terțe ca componente în locul propriilor dezvoltări (relevant atunci când economie de piata când este necesar să reziste promovării unui produs al unui concurent);
Abordarea 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 designului după mai multe iterații inițiale relevă componente comune reutilizabile care vor fi îmbunătățite în iterațiile ulterioare;
Modelul în spirală vă permite să obțineți un sistem mai fiabil și mai stabil. Acest lucru se datorează faptului că pe măsură ce sistemul evoluează, erorile și punctele slabe sunt găsite și remediate la fiecare iterație. În același timp, sunt ajustați parametrii critici de performanță, care în cazul unui model în cascadă este disponibil doar înainte de implementarea sistemului;
O abordare iterativă permite îmbunătățirea procesului
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 dintre etapele 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 clientului au posibilitatea de a controla procesul de creare a sistemului și de a influența conținutul funcțional al acestuia. Rezultatul este punerea în funcțiune a unui sistem care ține cont de majoritatea nevoilor clienților.
Modelul ciclului de viață și tehnologia de proiectare
Mai devreme spuneam că tehnologia de proiectare stabilește succesiunea de acțiuni necesare obținerii unui proiect IP. Evident, executarea fiecăreia dintre aceste acțiuni înseamnă trecerea sistemului informațional de la o stare la alta. Astfel, orice tehnologie de proiectare descrie fără ambiguitate un model de ciclu de viață. Pe de altă parte, prin construirea unui model de ciclu de viață al sistemului informațional, adică prin definirea:
sarcini, alcătuirea și succesiunea lucrărilor efectuate;
· rezultatele fiecărei acțiuni efectuate;
Metode și mijloace necesare pentru efectuarea muncii;
rolurile și responsabilitățile participanților;
alte informații necesare pentru planificarea, organizarea și gestionarea dezvoltării colective a PI,
vom obține o descriere fără ambiguitate a tehnologiei de proiectare pe care am ales-o. Astfel, modelul ciclului de viață este o parte integrantă și esențială a tehnologiei de proiectare a sistemelor informaționale.
Etape și etape de proiectare
Conceptele de „etapă” și „etapă” de proiectare sunt adesea confundate. Uneori vorbesc despre etape sau faze ciclu de viață, trepte proiecta. Apare întrebarea: care este calea corectă?
Trebuie amintit că în diferit standarde internaționale terminologia utilizată poate varia. Ne vom concentra, dacă este posibil, pe terminologia GOST-urilor interne. Etapa de proiectare vom numi partea procesului de creare a unui IS, limitată de un anumit interval de timp și care se termină cu lansarea unui anumit produs (model, documentație, text program etc.).În funcție de comunitatea obiectivelor, etapele de proiectare pot fi combinate în etape. De exemplu, etapa „Proiectare tehnică”, etapa „Implementare” etc.
Conform datelor publicate, fiecare etapă a dezvoltării AIS necesită o anumită perioadă de timp. Majoritatea timpului (45-50%) este cheltuit pentru codificare, testare complexă și de sine stătătoare. În medie, dezvoltarea AIS ocupă o treime din întregul ciclu de viață al sistemului.
Orez. Distribuția timpului în dezvoltarea AIS
Etapele creării AIS (ISO/IEC 15288)
Standardul ISO/IEC 12207 definește un cadru ciclului de viață care conține procesele, activitățile și sarcinile care trebuie efectuate în timpul creării unui sistem informațional.
AIS există, de regulă, pentru o perioadă lungă de timp, trecând succesiv prin mai multe etape de dezvoltare combinată în dezvoltarea lor. ciclu de viață sisteme (LC):
1) sondaj (sau analiză) înainte de proiect a organizației,
2) design AIS,
3) implementarea AIS,
4) introducerea AIS,
5) funcționare (funcționare, utilizare)
6) escortă AIS,
7) modernizarea proiectului AIS.
Ciclul de viață - perioada de creare și utilizare a unui sistem informațional, acoperind diferitele sale stări, începând din momentul în care apare necesitatea acestui sistem informațional și terminând cu momentul ieșirii sale complete din funcționare.
Trebuie remarcat faptul că AIS este un produs al producției de informații, la fel cum o mașină este un produs al producției de mașini, un cârnați este un produs al producției de alimente etc., prin urmare, etapele ciclului de viață AIS cu 1 până la 5 sunt similare cu etapele ciclului de viață al oricărui produs.
Ciclul de viață AIS, ca o mașină, poate se încheie ca urmare a uzurii fizice, dacăîn ciclul de viață faza de suport nu a fost rezolvată, adică repararea și întreținerea, de exemplu, a computerelor și a programelor care fac parte din AIS (fără suport, sistemul nu va funcționa nici măcar șase luni). Cu escortă calificată, AIS poate exista mult timp, dar există o amenințare încetarea ciclului de viață AIS din cauza învechirii, învechirea AIS, dacă nu există o etapă de upgrade AIS (fără modernizare, sistemul nu va funcționa mai mult de 2 ani).
Deprecierea fizică a AIS este incapacitatea de a îndeplini cerințele organizației pentru AIS din cauza defecțiunii, defecțiunii sau defecțiunii componentelor sistemului.
Învechirea AIS - încetarea îndeplinirii cerințelor organizației și ale angajaților săi pentru AIS, ca urmare a utilizării de automate învechite. tehnologia Informatieiși lipsa suportului pentru noile cerințe ale utilizatorilor.
Dacă organizația dvs. a abordat automatizarea în mod responsabil și cuprinzător, a organizat toate etapele și etapele în consecință, atunci Ciclul de viață AIS limitează numai durata de viață a organizației dvs, ceea ce înseamnă că fondurile cheltuite pe AIS nu vor fi aruncate la gunoi împreună cu AIS învechit din punct de vedere fizic sau moral.
Toate etapele ciclului de viață AIS au fost enumerate mai sus, dar unele dintre ele rulează în paralel, deci se alocă numai 5 etape din ciclul de viață AIS(fig.35):
La prima etapă" Sondaj înainte de proiect» (Fig. 33) se obișnuiește să se distingă două sub-etape principale și o sub-etapă suplimentară:
1.1. dirijarea sondaj pre-proiectși colectarea materialelor de anchetă;
1.2. analiza materialelor de anchetă și dezvoltarea pe baza analizei unui studiu de fezabilitate (FS) și a termenilor de referință (TOR);
1.3. selectarea și dezvoltarea unei variante a conceptului de sistem.
Obiectivele etapei de anchetă pre-proiect sunt următoarele:
· să formuleze nevoile unui nou AIS, i.е. identifica toate deficiențele SI existente;
· alegeți direcția și determinați fezabilitatea economică a proiectării AIS.
Activitatea de sondaj începe cu analiza cerințelor primare și planificarea muncii, care durează de la 2 zile la 4 săptămâni. În continuare, se efectuează ancheta în sine a întreprinderii (durata sondajului este de 1-2 săptămâni.)
În primul rând, se creează o descriere și se analizează funcționarea întreprinderii sau organizației în cauză în conformitate cu cerințele (obiectivele) care i se aplică. Sunt determinate structurile organizatorice si topologice ale intreprinderii. Sunt identificate activitățile funcționale ale fiecăreia dintre diviziile întreprinderii și interacțiunile funcționale dintre acestea, fluxurile de informații în cadrul diviziilor și între acestea, obiectele externe întreprinderii și interacțiunile informaționale externe. Se stabilește o listă de sarcini (funcții) țintă ale întreprinderii și se efectuează o analiză a distribuției funcțiilor pe departamente și angajați.
Se stabilește lista mijloacelor de automatizare utilizate la întreprindere.
În continuare, sunt procesate rezultatele sondajului și sunt construite următoarele două tipuri de modele de activitate a întreprinderii (rețineți că construcția fiecăruia dintre modelele solicitate necesită o muncă intensă a 6-7 analiști de sistem calificați în decurs de 2-4 luni).
1. În construcție modelul „ca atare”. care este un „instantaneu” al stării de fapt la întreprindere (structură organizațională, interacțiuni între departamente, tehnologii adoptate, procese de afaceri automatizate și neautomatizate etc.) la momentul sondajului și vă permite să înțelegeți ce este această întreprindere face și cum funcționează din punct de vedere al analizei sistemului, precum și, pe baza verificării automate, să identifice o serie de erori și blocaje și să formuleze o serie de propuneri pentru îmbunătățirea situației.
2. Format Modelul „cum ar trebui”. integrarea propunerilor promițătoare ale conducerii și angajaților întreprinderii, experților și analiștilor de sistem și permițând formarea unei viziuni asupra noilor tehnologii raționale pentru funcționarea întreprinderii. Ea reprezintă conceptul viitorului AIS.
Crearea conceptului viitorului sistem include următoarele lucrări:
Studiu detaliat al obiectului de automatizare;
Lucrări de cercetare necesare (C&D) legate de găsirea modalităților și evaluarea posibilității de implementare a cerințelor utilizatorilor;
Dezvoltarea de opțiuni alternative pentru conceptul AIS creat și planuri pentru implementarea acestora;
Nota resursele necesare pentru implementarea și funcționarea acestora;
Evaluarea avantajelor și dezavantajelor fiecărei opțiuni;
Compararea cerințelor utilizatorului și a caracteristicilor sistemului propus și selecție cea mai bună opțiune;
Determinarea procedurii de evaluare a calitatii si conditiilor de acceptare a sistemului;
Evaluarea efectelor primite de la sistem;
Intocmirea unui raport care sa contina o descriere a lucrarilor efectuate;
Descrierea și justificarea versiunii propuse a conceptului de sistem.
Pe baza conceptului construit al sistemului și a rezultatelor sondajului întreprinderii în ceea ce privește identificarea cerințelor pentru viitorul sistem, se formează un proiect de sistem. (modelul cerințelor), care este prima fază a dezvoltării sistemului de automatizare în sine (și anume faza de analiză a cerințelor pentru sistem), pe care sunt specificate, formalizate și documentate cerințele clientului
De fapt, în această etapă, se dă un răspuns la întrebarea: „Ce ar trebui să facă viitorul sistem?”. Aici se află cheia succesului întregului proiect de automatizare. În practica creării de sisteme software mari, există multe exemple de implementare nereușită tocmai din cauza caracterului incomplet și a definiției neclare a cerințelor de sistem.
În această etapă se determină următoarele:
§ arhitectura sistemului, funcțiile acestuia, condițiile externe de funcționare a acestuia, distribuția funcțiilor între părțile hardware și software;
§ interfeţe şi distribuţie a funcţiilor între o persoană şi un sistem;
§ cerințe pentru componentele software și informaționale ale sistemului, resursele hardware necesare, cerințele bazei de date, caracteristicile fizice ale componentelor sistemului, interfețele acestora;
§ componența persoanelor și a locurilor de muncă aferente sistemului;
§ limitări în procesul de dezvoltare (termene directive pentru parcurgerea etapelor individuale, resurse disponibile);
§ proceduri organizatorice care asigura protectia informatiilor.
Ca parte a proiectării sistemului, se realizează următoarele:
Determinarea compoziției, structurii și caracteristicilor sarcinilor funcționale în cadrul activităților diviziilor structurale;
Determinarea compoziției și structurii software-ului de automatizare pentru tehnologia de rezolvare a problemelor, ținând cont de instrumentele existente în diviziuni structurale;
Determinarea structurii și caracteristicilor tehnologiei suport informațional pentru rezolvarea problemelor;
Dezvoltarea de solutii tehnice pentru construirea suportului informatic (structuri de baze de date logice, structuri de clasificatoare);
§ dezvoltarea compoziției procedurilor de flux de lucru automatizate.
Proiect de sistem ar trebui să includă:
un model funcțional complet al cerințelor pentru viitorul sistem;
Comentarii asupra modelului funcțional (specificații de proces de nivel inferior sub formă de text);
un pachet de rapoarte și documente privind un model funcțional, inclusiv o descriere a obiectului de modelare, o listă de subsisteme, cerințe pentru metode și mijloace de comunicare pentru schimbul de informații între componente, cerințe pentru caracteristicile interconexiunilor sistemului cu sistemele adiacente, cerințe pentru funcțiile sistemului;
· modelul conceptual al bazei de date integrate (pachet de diagrame);
arhitectura sistemului cu referire la modelul conceptual;
· propuneri pentru structura organizatorică care să susțină sistemul.
Astfel, proiectul de sistem conține modele funcționale, informaționale și, eventual, de evenimente ale cerințelor pentru viitorul sistem. Tipurile și succesiunea lucrărilor în construcția acestor modele de cerințe sunt similare cu lucrările corespunzătoare privind construcția modelelor de activitate. În plus, proiectul de sistem include termeni de referință pentru crearea unui sistem automatizat.
Este necesar să rețineți următorul avantaj al proiectului de sistem. Dezvoltarea tradițională se caracterizează prin implementarea etapelor inițiale în moduri artizanale neformalizate. Ca rezultat, clienții și utilizatorii pot vedea sistemul pentru prima dată după ce acesta a fost deja implementat în mare măsură. Desigur, acest sistem este diferit de ceea ce se așteptau să vadă. Prin urmare, urmează mai multe iterații ale dezvoltării sau modificării sale, ceea ce necesită costuri suplimentare (și semnificative) de bani și timp. Cheia pentru rezolvarea acestei probleme este proiectul de sistem, care permite:
Descrieți, „vedeți” și corectați viitorul sistem înainte ca acesta să fie implementat fizic;
Reducerea costurilor de dezvoltare și implementare a sistemului;
Evaluează evoluția în termeni de timp și rezultate;
Realizarea înțelegerii reciproce între toți participanții la lucru (clienți, utilizatori, dezvoltatori, programatori etc.);
Pentru a îmbunătăți calitatea sistemului dezvoltat și anume: pentru a crea o structură optimă a unei baze de date integrate, pentru a realiza o descompunere funcțională a modulelor tipice.
Un proiect de sistem este complet independent și separabil de anumiți dezvoltatori, nu necesită întreținere din partea creatorilor săi și poate fi transferat fără durere altor persoane. Mai mult decât atât, dacă dintr-un motiv oarecare întreprinderea nu este pregătită să implementeze sistemul bazat pe proiect, acesta poate fi pus „la raft” până când este nevoie. În plus, poate fi folosit pentru dezvoltarea independentă sau corectarea instrumentelor software deja implementate pe baza sa de către programatorii departamentului de automatizare a întreprinderii.
Scopul dezvoltării „Studiului de fezabilitate” al proiectului AIS este acela de a evalua principalii parametri care limitează proiectul, de a justifica alegerea și de a evalua principalele decizii de proiectare pentru componentele individuale ale proiectului. Totodată, există parametri organizatorici care caracterizează modalitățile de organizare a proceselor de transformare a informațiilor în sistem, parametri informaționali și economici care caracterizează costurile de creare și exploatare a sistemului, economii din funcționarea acestuia. Obiectele principale de parametrizare în sistem sunt sarcinile, complexele de sarcini, indicatori economici, procesele de prelucrare a informațiilor. După ce s-a luat o decizie cu privire la lucrările ulterioare, o serie de măsuri organizatorice, de exemplu, trebuie emise comenzi de lucru adecvate; Ar trebui să fie numiți responsabili pentru zone etc.
Fără un astfel de sprijin din partea conducerii întreprinderii, este inutil să începeți un proiect.
Figura 33. Secvența de lucru în etapa de pre-proiectare a ciclului de viață AIS.
În continuare, este creat un termeni de referință (TOR) pentru proiect, care reflectă specificațiiși cerințele pentru viitorul AIS, precum și restricții privind resursele de proiectare. Dacă proiectul necesită un studiu științific al componentelor, atunci conceptul viitorului AIS este dezvoltat pe baza TOR.
Ca parte a formării TOR, propunerile de automatizare sunt elaborate pe baza cerințelor identificate și convenite, care includ:
Întocmirea unei liste de locuri de muncă automatizate ale întreprinderii și modalități de interacțiune între acestea;
Analiza aplicabilității sistemelor de management al întreprinderii existente (în primul rând clasele MRP și ERP) pentru rezolvarea sarcinilor necesare și formarea de recomandări pentru alegerea unui astfel de sistem;
Luarea deciziilor în comun cu clientul alegerea unui anumit sistem de management al întreprinderii sau dezvoltarea propriului dumneavoastră sisteme.
Elaborarea de propuneri de mijloace tehnice;
Elaborare de propuneri de software;
Dezvoltarea topologiei, compoziției și structurii rețelei locale;
Elaborarea de propuneri pentru etapele și termenii de automatizare.
Dacă s-a decis să se aleagă un anumit sistem de control, atunci se omite unii pași.
Faza a doua" Proiecta» (Fig. 34) efectuează următoarele subpași:
1) anteproiectare: clarificarea cerințelor TOR, execuția și aprobarea anteproiectului;
2) proiectare tehnică: selecția soluțiilor de proiectare pentru toate aspectele dezvoltării AIS, descrierea tuturor componentelor AIS, execuția și aprobarea unui proiect tehnic;
3) proiectare detaliată: selectarea și dezvoltarea metodelor matematice și a algoritmilor programului, ajustarea structurii bazelor de date (DB), crearea documentației pentru furnizarea și dezvoltarea produselor software, selectarea unui set de hardware AIS, crearea documentației pentru furnizarea și instalarea hardware-ului, elaborarea unui proiect de lucru al AIS.
Obiectivele acestei faze sunt:
· dezvoltarea unei arhitecturi funcționale a AIS, care să reflecte structura și compoziția subsistemelor funcționale, pentru sprijinirea automată a anumitor funcții de management ale organizației;
· să dezvolte arhitectura de sistem a variantei AIS selectate, adică alcătuirea subsistemelor suport.
Pentru AIS complexe mari, automatizare întreprindere mare, exploatare, corpuri puterea statului etc., în sub-etapa 1 " Proiectare preliminară» se formulează soluții preliminare pentru viitorul AIS în ansamblu și componentele sale, drept urmare proiectare preliminară(EP). Dezvoltarea soluțiilor de proiectare preliminară pentru sistem și părțile sale include:
Definirea funcției AIS;
Definirea funcției subsistemelor, a scopurilor și efectelor acestora;
Determinarea compoziției complexelor de sarcini și sarcinilor individuale;
Definirea conceptului de baza de informatii, structura sa extinsa;
Definirea functiilor sistemului de management al bazei de date;
Determinarea compoziției sistemului informatic;
Definirea funcției și parametrilor principalelor instrumente software.
Elaborarea documentației pentru această parte a proiectului.
Dacă proiectul în curs de dezvoltare nu este foarte complex, să presupunem că o întreprindere mică este automatizată, atunci etapa de lucru este omisă.
La sub-pasul 2. Proiectare inginerească » lucrul la dezvoltarea logica si selectia cele mai bune opțiuni decizii de proiectare, în urma cărora se creează un proiect tehnic (TP). Ca parte a realizării unui proiect tehnic, se realizează următoarele:
- transformarea unui proiect de sistem într-un proiect tehnic(model de implementare), care include următoarele acțiuni: rafinarea modelului logic (dezvoltarea unei logici detaliate pentru fiecare proces folosind diagrame de flux de date și specificații de proces), proiectarea unei baze de date fizice, construirea unei ierarhii a funcțiilor modulului de programat, estimarea costurilor de implementare.
Lucrările enumerate ar trebui să fie efectuate de analiști consultanți împreună cu proiectanții de sistem - aici se află granița care separă consultanța și dezvoltarea. Cu toate acestea, este de dorit ca, în etapa de implementare a sistemului, consultantul să acționeze și în interesul clientului, și anume: sistem software sistemic şi proiecte tehnice, și, de asemenea, a participat la lucrările de extindere și modificare a acestuia, tk. extinderile ar trebui planificate pe baza modelului de cerințe.
- lucrari de proiectare tehnica:
Dezvoltarea de soluții generale pentru sistem și părțile sale,
Dezvoltarea de soluții generale pentru funcțional-algoritmic structura sistemului,
Elaborarea deciziilor comune privind funcțiile de personal și structura organizatorică,
Dezvoltarea de soluții comune pentru structura mijloacelor tehnice,
Dezvoltarea de soluții generale pentru algoritmi de rezolvare a problemelor și limbaje utilizate,
Dezvoltarea de soluții comune pentru organizarea și menținerea unei baze de informații,
Dezvoltarea de soluții comune pentru sistemul de clasificare și codificare a informațiilor,
Dezvoltarea de soluții software comune;
Efectuează elaborarea, execuția documentației pentru toate părțile proiectului, inclusiv documentul „Formularea problemei”,
Elaborarea și execuția documentației pentru furnizarea produselor pentru achiziționarea AIS și/sau cerinte tehnice(specificații tehnice) pentru dezvoltarea acestora;
Dezvoltarea sarcinilor de proiectare în părțile adiacente ale proiectului obiectului de automatizare.
Subetapa 3." Design de lucru » asociat cu implementarea fizică a opțiunii de proiect selectate și primirea documentației detaliate de proiectare (DP).
Această subetapă se realizează:
Elaborarea și execuția documentației de lucru care să conțină toate informațiile necesare și suficiente pentru a asigura implementarea lucrărilor privind punerea în funcțiune a AIS și funcționarea acestuia, precum și pentru menținerea nivelului caracteristicilor operaționale (calității) sistemului în conformitate cu prevederile adoptate. deciziile de proiectare și coordonarea și aprobarea acestei documentații;
Dezvoltarea de programe și instrumente software ale sistemului, precum și selectarea, adaptarea și/sau legarea instrumentelor software achiziționate,
Dezvoltarea documentației software.
Organizare de licitatii pentru furnizarea de componente AIS (software si hardware, sisteme software si hardware, produse informatice).
Figura 34. Secvența de lucru în etapa de proiectare a ciclului de viață AIS.
În prezența experienței de proiectare și a unei mici complexități a proiectului, toate cele trei subetape sunt combinate într-una singură, în urma căreia se obține un singur proiect tehno-lucrător (TDP). În acest caz, proiectul este consecvent, pe măsură ce subetapele sunt finalizate, transformat dintr-un proiect într-un proiect detaliat.
A treia etapă Implementarea» (Fig. 35) este proiectarea fizică a sistemului în următoarea secvență:
1) primirea și montarea mijloacelor tehnice;
2) codificarea, testarea și dezvoltarea programelor;
3) obținerea și instalarea de software;
4) crearea suportului informaţional, inclusiv completarea bazelor de date;
5) elaborarea de instrucțiuni pentru funcționarea software-ului și hardware-ului, precum și descrierea postului pentru personal.
Aceste lucrări pot fi efectuate practic în paralel.
La a patra etapă a ciclului de viață AIS " Implementarea» există următorii sub-etași:
1) implementare pilot:
punerea în funcțiune a echipamentelor tehnice,
punerea în funcțiune a instrumentelor software, efectuarea operațiunii de probă a tuturor componentelor și sistemelor în ansamblu,
· instruirea și certificarea personalului.
Implementarea pilot constă în verificarea operabilității elementelor și modulelor proiectului, eliminarea erorilor la nivelul elementelor și a legăturilor dintre acestea.
În această etapă se lucrează la pregătire organizatorică obiect de automatizare pentru a pune în funcțiune AIS, inclusiv:
Implementarea deciziilor de proiectare asupra structurii organizatorice a AIS;
Furnizarea unităților obiectului de control cu materiale instructive și metodologice;
Introducerea clasificatoarelor de informații;
Instruire,
Verificarea capacității acestuia de a asigura funcționarea AIS.
În aceeași etapă, AIS este completat cu produsele furnizate (software și mijloace tehnice, complexe software și hardware, produse informatice), precum și construcție și instalare, punere în funcțiune, teste preliminare:
Efectuează teste ale AIS pentru performanță și conformitate cu termenii de referință în conformitate cu programul și metodologia de teste preliminare pregătite în prealabil;
Depanarea și îmbunătățirea (dacă este necesar) a software-ului, efectuarea de modificări la documentația AIS, inclusiv documentația operațională în conformitate cu protocolul de testare.
Lucrările de implementare pilot se încheie la întocmirea unui act privind finalizarea operaţiunii de probă.
2) implementare industrială (punerea în funcțiune comercială):
punere in functiune,
Semnarea actelor de recepție și livrare a lucrărilor.
Punere in functiune constă în organizarea unei verificări a proiectului la nivel de funcții și monitorizarea respectării cerințelor acestuia formulate în etapa de sondaj pre-proiect, adică:
Efectuează un test de conformitate cu termenii de referință în conformitate cu programul și metodologia testelor de acceptare pregătite în prealabil;
Analiza rezultatelor testelor AIS și eliminarea deficiențelor identificate în timpul testelor.
Terminarea lucrărilor la întocmirea unui act privind acceptarea AIS pentru operare permanentă.
În ultima a cincea etapă a ciclului de viață AIS, exploatare, întreținere și modernizare software, hardware și întregul proiect.
escortă AIS se află în efectuarea lucrărilor în conformitate cu obligațiile de garanție, implementarea lucrărilor pentru eliminarea deficiențelor identificate în timpul funcționării AIS în perioada de garanție stabilită și în executarea lucrărilor pentru a face modificările necesare în documentația pentru AIS.
Serviciul post-garanție constă în:
În implementarea lucrărilor de analiză a funcționării sistemului;
În identificarea abaterilor caracteristicilor operaționale efective ale AIS de la valorile de proiectare;
În stabilirea cauzelor acestor abateri;
În eliminarea deficiențelor identificate și asigurarea stabilității caracteristicilor operaționale ale AIS;
În efectuarea modificărilor necesare în documentația pentru AIS.
În funcție de specificul AIS creat și de condițiile pentru crearea acestora, este permisă efectuarea unor etape individuale de lucru înainte de finalizarea etapelor anterioare, execuția în paralel a etapelor de lucru în timp, includerea de noi etape de lucru.
Figura 35. Etapele ciclului de viață AIS.
Ciclul de viață este de obicei iterativ: etape finalizate Ciclurile de viață, începând de la cele mai timpurii, se repetă ciclic în conformitate cu noile cerințe și modificări ale condițiilor externe. La fiecare etapă a ciclului de viață se formează un set de documente și soluții tehnice, care constituie punctele de plecare pentru deciziile ulterioare.
Cel mai răspândit trei modele de ciclu de viață:
model în cascadă (până în anii 70) - o tranziție secvențială la următoarea etapă după finalizarea celei anterioare;
· model iterativ (anii 70 - 80) - cu reveniri iterative la etapele anterioare după finalizarea etapei următoare;
· model în spirală (anii 80-90) - un model prototip, care presupune o extindere treptată a prototipului AIS.
Pentru modelul ciclului de viață în cascadă este tipică automatizarea sarcinilor separate fără legătură, care nu necesită integrarea și compatibilitatea informațiilor, software, interfață tehnică și organizațională. Ca parte a soluționării problemelor individuale, modelul în cascadă s-a justificat în ceea ce privește timpul de dezvoltare și fiabilitatea. Aplicarea acestui model de ciclu de viață la proiecte mari și complexe, datorită duratei lungi a procesului de proiectare și variabilității cerințelor în acest timp, duce la irealizabilitatea lor practică.
Model iterativ de ciclu de viață. Crearea unui AIS complex implică conectarea soluțiilor de proiectare obținute în implementarea sarcinilor individuale. Abordarea de proiectare „de jos în sus” necesită astfel de returnări iterative, atunci când soluțiile de proiectare pentru sarcini individuale sunt completate în soluții generale de sistem și, în același timp, este nevoie de revizuirea cerințelor formulate anterior. De regulă, din cauza unui număr mare de iterații, apar discrepanțe în deciziile de proiectare și documentația finalizate. Confuzia dintre funcționale și Arhitectura sistemului creat de AIS, dificultatea de utilizare a documentației de proiectare determină necesitatea reproiectării întregului sistem în etapele de implementare și exploatare. Ciclul lung de viață al dezvoltării unui sistem informațional se încheie cu etapa de implementare, urmată de ciclul de viață al creării unui nou AIS.
Modelul ciclului de viață în spirală. Este utilizată o abordare de sus în jos a organizării designului AIS, atunci când este mai întâi determinată compoziția subsistemelor funcționale și apoi stabilirea sarcinilor individuale. În consecință, sunt dezvoltate mai întâi probleme la nivelul întregului sistem, cum ar fi organizarea unei baze de date integrate, tehnologia de colectare, transmitere și acumulare a informațiilor și apoi tehnologia pentru rezolvarea unor probleme specifice. În cadrul complexelor de sarcini, programarea se realizează în direcția de la modulele principale de program la modulele care îndeplinesc funcții individuale. În același timp, problemele de interacțiune între interfețele modulelor de program între ele și cu baza de date vin în prim-plan, iar implementarea algoritmilor trece pe plan secund.
Fiecare tură a spiralei corespunde unui model pas cu pas pentru crearea unui fragment AIS. El clarifică obiectivele și caracteristicile proiectului, determină calitatea acestuia și planifică activitatea următoarei ture a spiralei. Are loc o aprofundare și concretizare consecventă a detaliilor proiectului, se formează varianta fundamentată a acestuia, care se aduce la implementare.
Modelul în spirală al ciclului de viață se bazează pe utilizarea tehnologiei prototip sau a tehnologiei RAD (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 tehnologia prototipului, numărul de iterații este redus și există mai puține erori și inconsecvențe care trebuie corectate la iterațiile ulterioare, iar proiectarea în sine este realizată într-un ritm mai rapid, iar crearea documentației de proiect este simplificată. Pentru a se potrivi mai strâns 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 automatizării designului, în special, utilizării tehnologiilor CASE (Computers Aids System Engineering).
Când utilizați modelul în spirală:
· există o acumulare și reutilizare de soluții de proiectare, instrumente de proiectare, modele și prototipuri de AIS și tehnologii informaționale;
· Orientarea se realizează asupra dezvoltării și modificării sistemului și tehnologiilor în procesul de proiectare a acestora;
· în procesul de proiectare a sistemului se efectuează o analiză a riscurilor și costurilor.
O interfață este o pereche de părți de software și hardware, date, o tehnologie de comunicare între o persoană și un computer, în care toate informațiile, parametrii logici, fizici și electrici îndeplinesc standardele stabilite.
Prototip - versiunea minimă a sistemului utilizată pentru a genera sau dezvolta versiunea completă
Depozitul conține informații despre obiectele AIS proiectate și relațiile dintre acestea, toate subsistemele fac schimb de date cu acesta.
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.
Defecte:
-Întârziere semnificativă în obținerea rezultatelor gata făcute;
-Greșelile în 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, la care sunt specificate obiectivele și caracteristicile proiectului, este evaluată calitatea rezultatelor obținute și este planificată munca următoarei iterații.
Fiecare iterație - cicluri de dezvoltare finalizate sub forma primei versiuni a AIS.
Etape 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.
Defecte:
-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:
- procedura 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.
Instructiuni tehnologice, care alcătuiesc conținutul principal al tehnologiei, ar trebui să conțină o descriere a succesiunii 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 link-uri externe;
Tehnologia ar trebui să prevadă posibilitatea de a gestiona configurația proiectului, menținerea versiunilor proiectului ș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 unui sistem de reglementări administrative și a fișelor posturilor care determină funcționarea organizației. Din momentul punerii in functiune a sistemului informatic, functionarea se desfasoara pe 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 dezvoltarea 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. Soluția la această problemă în conditii moderne imposibil fără utilizarea prelucrării automate a datelor tehnice informatii 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ăîntreprinderi de diferite forme de proprietate, afiliere la industrie, structura organizationalași amploarea activității. În acest timp, s-a acumulat multă experiență practică în crearea sistemelor 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 deplină responsabilitate 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 E.N., Brady R., Zachman J. , Cook M., Finkelstein K., Hammer M. și alți autori. Abordările propuse de aceștia au devenit baza utilizării tehnologiei informatice în întreprinderi în rezolvarea problemelor de contabilitate, planificare și analiză a activităților financiare și economice. in orice caz
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 instrumentelor 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 pentru tranzacțiile economice și tranzacțiile financiare. Implementarea globală retele de calculatoareîn procesele economice a condus la apariția unor noi concepte: economia societății informaționale, e-business(e-business), comerț electronic(comerț electronic), electronic podeaua comercială(e-marketplace), etc. Tendințele de globalizare a economiei se reflectă în noua metodologie de organizare a afacerilor, în care problema creșterii flexibilității construirii proceselor de afaceri și a eficacității relațiilor cu clienții și furnizorii iese în prim-plan.
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 anul trecut Devine 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 efectuată deodată, deoarece de mulți ani î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 produse software existente care oferă suport pentru rezolvarea noilor probleme de management al întreprinderilor apărute în contextul globalizării economiei sunt dezvoltate și fără o elaborare suficientă a interfețelor pentru interacțiunea cu sistemele software care implementează soluționarea 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ă.
În publicațiile oamenilor de știință și practicienilor, ideea de implementare a standardelor pentru integrarea în sistem a instrumentelor software furnizate de diverși producători a fost mult timp discutată. 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 legătură 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 de recomandări practice care vizează construirea AIS UE, care asigură automatizarea completă a tuturor procedurilor de informare pentru gestionarea întreprinderilor și organizațiilor, devine una urgentă.
Necesitatea dezvoltării unei abordări holistice a soluționării problemelor de integrare a sistemelor AIS PM și de automatizare end-to-end a proceselor microeconomice bazate pe IT-ul modern a determinat alegerea temei și direcției acestui studiu.
Scopul studiului este de a dezvolta un model de arhitectură 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 sistemului 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 ca software-ul AIS UE să le asigure suport informativ prin procese economice;
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ă a metodelor matematice și a tehnologiei informatice utilizate î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 management operațional al producției și al stocurilor;
Reproiectare și proiectare computerizată a proceselor de afaceri;
Standarde moderne în tehnologia informației.
Pe parcursul studiului, evoluțiile realizate de echipele de cercetare și de 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, Moscova universitate de stat Economie, Statistică și Informatică, Universitatea de Economie și Finanțe din Sankt Petersburg. Voznesensky, Institutul Financiar de Cercetare și alte organizații.
Baza de informații a studiului a fost formată din produse software ale producătorilor ruși și străini, publicații în publicații economice și informatice, cercetări ale grupurilor internaționale de cercetare Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest etc. materiale didactice companii de consultanță și audit naționale și internaționale de top, 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ă a AIS UE, axat pe automatizarea integrată a proceselor de afaceri end-to-end, și propuneri pentru implementarea acestuia prin integrarea în sistem a software-ului eterogene într-un mediu de rețea eterogen distribuit bazat pe asupra tehnologiilor obiectelor și componentelor.
Noutatea științifică conține următoarele rezultate obținute în disertație:
Definirea și clasificarea cerințelor pentru funcţionalitate Software pentru managementul organizatoric si economic al intreprinderilor;
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, disponibil pentru angajații și partenerii î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;
Un mecanism pentru implementarea proprietăților adaptative 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 globalizării economice ș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 managementul clădirilor IS pentru întreprinderi cu diverse 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”,
Sistemele 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 pentru disertație sunt utilizate în cercetare și activitati practice organele executive ale Asociației Dezvoltatorilor de Software în Economie (AREP) și ale membrilor 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: practica și problemele informatizării 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 CSI " 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 PM. Acest lucru se aplică nu numai pur probleme tehnologice crearea și funcționarea SI, dar și abordări ale managementului afacerilor în condițiile economiei 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 face cerințe ridicate la servere. 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 procesarea 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 corespunzătoare 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ă sunt dezvoltate componente individuale de software IS. diferite companii sau chiar echipe de dezvoltare din cadrul aceleiași organizații. Instalarea unei baze de date comune cu acces din programe pentru rezolvarea diverselor probleme aplicate face posibilă asigurarea unui spațiu informațional comun, tehnologiile enumerate mai sus permit accesul unui număr mare de utilizatori la baza de date, dar acest lucru nu garantează funcționarea corectă cu datele 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. Arhitectură schematică cu bază comună prezentată î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 cu o structură comună a bazei de date, acestea trebuie să fie inițial dezvoltate în vederea unei structuri de date specifice sau să utilizeze un mecanism de metadate agreat (depozitar).
Când se utilizează o arhitectură diferită, când bazele de date eterogene sunt menținute pe computere diferite (și posibil 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:
un instrument de calcul personal, constând în faptul că în multe tipuri de muncă a dispărut nevoia de intermediari între formularea sarcinii și executantul acesteia, adică angajații serviciilor funcționale ale întreprinderii sunt capabili să efectueze proceduri de informare în cadrul competența lor în utilizarea computerelor fără implicarea sau cu sprijinul minim al personalului tehnic însoțitor;
mijloace de suport automatizat pentru coordonat munca în comun grupuri („echipe”) de lucrători 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, reducerea la minimum a nevoii de întâlniri, ceea ce este deosebit de important atunci când participanții unuia sau altuia proces de afaceri.
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 de servicii web deschise î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 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 specifice industriei (EDIFACT, XI2, HIPAA etc.) au fost utilizate în sectoarele financiare și industriale din 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 despre clienți sau facturi. 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 succesiune de acțiuni ale angajaților, operațiuni la locurile de muncă, precum și funcții efectuate de software și hardware în modul 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 dintr-un proces de afaceri poate fi ambiguă, adică o descriere a procesului sub forma unui grafic direcționat poate include ramificarea cu condiții de tranziție 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 diagrama rețelei, unde vârfurile desemnează lucrări cu indicarea duratei lor, iar marginile orientate (săgeți) 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 dimensiunii î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 schimba 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 lucrătorilor și procese tehnologice, care oferă 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 de proces, un modul comun pentru procesarea etapelor procesului, un mecanism comun de atribuire a executanților și a sarcinilor și datelor de rutare.
Astfel, datele tehnologice generate dispozitive 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, va fi introdus în AIS UE și disponibil pentru consumatorii 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ă natură. 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 sistemul de automatizare integrată a managementului întreprinderii „Flagman” al companiei „Infosoft”, care este implementat în prezent în peste o sută de întreprinderi mari și mijlocii industriale. , construcții, întreprinderi comerciale, agricole și organizatii bugetare 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 următoarea figură (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 de conturi în subsisteme funcționale pe baza acestor documente și unificarea lucrărilor cu documentele primare.
Dezvoltarea rapidă a subsistemelor și lipsa de standardizare a interacțiunii lor a condus 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 relevat 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, compoziția 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țiuni legate de module funcționale, șabloane și formulare de tipărire. , 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 imprimare ș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.
Pe acest moment 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 operare comercială cu succes a sistemului Flagman, creșterea numărului vânzărilor sale în perioada 2001-2002 mărturisesc eficiență economică soluții 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 „Interface” (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 „Contabilitate” și „Ziar financiar”.
Doar îndrăgostiții vor supraviețui
Caracteristici ale reclamei destinate copiilor
retuşarea fotografiilor vechi în photoshop retuşarea fotografiilor vechi
Ce este un NPO: decodare, definirea scopurilor, tipuri de activități Are o organizație non-profit dreptul
Prim-adjunct Gleb Nikitin