Un model de ciclu de viață este o structură care definește secvența de execuție și relațiile dintre procese, acțiuni și sarcini efectuate de-a lungul ciclului de viață.
Cele mai utilizate sunt două modele principale de ciclu de viață:
· model în cascadă (70-85);
· model în spirală (86-90).
Model în cascadă
Metoda în cascadă este împărțirea întregii dezvoltări în etape, iar trecerea de la o etapă la alta are loc numai după ce lucrarea la cea actuală este complet finalizată (Fig. 2).
Aspecte pozitive ale utilizării abordării în cascadă:
· la fiecare etapă se formează un set complet documentatia proiectului, îndeplinind criteriile de completitudine și coerență;
· etapele de lucru efectuate într-o succesiune logică ne permit să planificăm timpul de finalizare a tuturor lucrărilor și costurile corespunzătoare.
Abordarea în cascadă s-a dovedit bine în construcția sistemelor informaționale, pentru care toate cerințele pot fi formulate destul de precis și complet chiar la începutul dezvoltării. Sistemele complexe de calcul, sistemele în timp real și alte sarcini similare se încadrează în această categorie.
Fig.2 Schema abordării în cascadă
Cu toate acestea, în realitate, în procesul de creare a unui IP, există o nevoie constantă de a reveni la etapele anterioare, de a clarifica sau de a revizui mai devreme deciziile luate. Procesul propriu-zis de creație sistem informatic ia următoarea formă (fig. 3):
Fig.3 Procesul real de creare a unui IP bazat pe modelul cascadă
Unul dintre denumirile folosite în literatura occidentală pentru o astfel de schemă de organizare a muncii este „model în cascadă”.
Principalul dezavantaj al abordării în cascadă este întârzierea semnificativă în obținerea rezultatelor. Modelele (atât funcționale, cât și informaționale) ale obiectului automatizat pot deveni învechite simultan cu aprobarea lor. Un alt dezavantaj este că o astfel de proiectare a unui sistem informațional duce la automatizarea primitivă (în esență „mecanizarea”) activităților de producție existente ale muncitorilor.
Modelul ciclului de viață în spirală (Fig. 4) pune accent pe etapele inițiale ale ciclului de viață: analiză și proiectare. Fezabilitatea soluțiilor tehnice este testată prin crearea de prototipuri.
Fig 4.
Fiecare tură a spiralei corespunde creării unui nou fragment sau versiune a sistemului informațional, se clarifică obiectivele și caracteristicile proiectului, se determină calitatea acestuia și se planifică activitatea următoarei ture a spiralei. În acest caz, o tură a spiralei reprezintă un ciclu complet de proiect similar cu o schemă în cascadă. Această abordare a mai fost numită și „Continuing Design”. Ulterior, ciclul proiectului a început să includă în plus etapele de dezvoltare și testare a unui sistem prototip. Aceasta a fost numită: „prototipare rapidă”, abordare de prototipare rapidă sau „fast-track”.
Cu toate acestea, utilizarea unor astfel de metode, împreună cu un efect rapid, reduce capacitatea de gestionare a proiectului în ansamblu și interconectivitatea diferitelor fragmente ale sistemului informațional. Principala problemă a ciclului spirală este determinarea momentului de tranziție la etapa următoare. Tranziția decurge conform planului, chiar dacă nu toate lucrările planificate sunt finalizate. Planul se întocmește pe baza datelor statistice obținute în proiectele anterioare și experiență personală dezvoltatori.
Modele de ciclu de viață AIS - O structură care definește implementarea secvențială a proceselor, acțiunilor, sarcinilor efectuate de-a lungul ciclului de viață și relațiile dintre aceste procese.
Model în cascadă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrărilor în etapa anterioară. Cerințele determinate în etapa formării cerințelor sunt strict documentate sub formă de specificații tehnice și sunt înregistrate pentru întreaga dezvoltare a proiectului. Fiecare etapă culminează cu lansarea unui set complet de documentație suficientă pentru a permite continuarea dezvoltării de către o altă echipă de dezvoltare.
Etape ale proiectului conform modelului cascada:
1. Formarea cerințelor;
2. Design;
3. Dezvoltare;
4. Testare;
5. Implementare;
6. Operare și întreținere.
Avantaje:
-Documentația completă și agreată la fiecare etapă;
-O anumită ordine a secvenței de lucru;
-Vă permite să planificați clar termenele limită și costurile.
Defecte:
-Întârziere semnificativă în obținerea rezultatelor finale;
-Erorile în orice etapă sunt identificate în etapele ulterioare, ceea ce duce la necesitatea returnării și reînregistrării documentației de proiect;
- Complexitatea managementului de proiect.
Model în spirală. Fiecare iterație corespunde creării unui fragment sau a unei versiuni a software-ului, la care se clarifică obiectivele și caracteristicile proiectului, se evaluează calitatea rezultatelor obținute și se planifică activitatea următoarei iterații.
Fiecare iterație este un ciclu de dezvoltare finalizat sub forma primei versiuni a AIS.
Etape de iterație:
1. Formarea cerințelor
3.Design
4.Dezvoltare
5.Integrare
La fiecare iterație sunt evaluate următoarele:
Risc de depășire a termenelor și costurilor proiectului;
Necesitatea de a efectua o altă iterație;
Gradul de completitudine și acuratețe de înțelegere a cerințelor sistemului;
Fezabilitatea rezilierii proiectului.
Avantaje:
-Se simplifică procesul de efectuare a modificărilor în proiect;
- Oferă o mai mare flexibilitate în managementul proiectelor;
-Capacitatea de a obține un sistem fiabil și stabil, deoarece erorile și inconsecvențele sunt detectate la fiecare iterație;
-Influența clientului asupra lucrării în timpul procesului de verificare a fiecărei iterații.
Defecte:
-Dificultate de planificare;
-Program de lucru intens pentru dezvoltatori;
-Planificarea muncii se realizează pe baza experienței existente și nu există suficiente metrici pentru a măsura calitatea fiecărei versiuni.
Cerințe pentru tehnologia de proiectare, dezvoltare și suport AIS
Tehnologia de proiectare- definește o combinație de trei componente:
-procedura pas cu pas, care determină succesiunea operațiunilor de proiectare tehnologică;
-reguli utilizate pentru evaluarea rezultatelor operațiunilor tehnologice;
-performanţă dezvoltarea designului pentru examinare și aprobare.
Instructiuni tehnologice, constituind 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țiune și descrieri ale operațiunilor în sine.
Tehnologia de proiectare, dezvoltare și întreținere IS trebuie să satisfacă următoarele cerințe generale:
Tehnologia trebuie să suporte întregul ciclu de viață al software-ului;
Tehnologia trebuie să asigure realizarea garantată a obiectivelor de dezvoltare SI cu o calitate dată și într-un timp stabilit;
Tehnologia ar trebui să ofere capacitatea de a efectua lucrări de proiectare a subsistemelor individuale în grupuri mici (3-7 persoane). Acest lucru se datorează principiilor managementului echipei și creșterii productivității prin minimizarea numărului relaţiile externe;
Tehnologia ar trebui să ofere capacitatea de a gestiona configurația proiectului, de a menține versiunile proiectului și ale componentelor acestuia, abilitatea de a elibera automat documentația proiectului și de a sincroniza versiunile acestuia cu versiunile de proiect;
Utilizarea oricărei tehnologii pentru proiectarea, dezvoltarea și întreținerea sistemelor informaționale într-o anumită organizație și un anumit proiect este imposibilă fără dezvoltarea unui număr de standarde (reguli, acorduri) care trebuie respectate de toți participanții la proiect. La asa ceva standardele includ următoarele:
-standard de proiectare;
- standard pentru documentația de proiectare;
-standard de interfață cu utilizatorul.
Cerința de dezvoltare
- Efectuarea lucrărilor de creație software;
Pregătirea pentru implementarea AIS;
Monitorizarea și testarea indicatorilor cheie de proiect.
Cerințe de întreținere
Finalizarea implementării CIS trebuie să fie însoțită de publicarea sistemului reglementări administrativeŞi fișele postului, definind ordinea de functionare a organizatiei. Din momentul punerii în funcțiune a sistemului informațional, funcționarea are loc în baza „Regulamentului de funcționare a sistemului informațional” și a unui număr de reglementări. Întreținerea sistemului și funcționarea neîntreruptă a acestuia este efectuată de o divizie a organizației autorizată prin ordinul relevant. Rafinarea sistemului informatic după punerea în funcțiune se realizează în conformitate cu proiectele individuale și specificațiile tehnice.
În procesul de menținere a unui CSI, sarcina este de a menține viabilitatea acestuia. Viabilitatea SIC este în mare măsură determinată de cât de bine corespunde sarcinilor și nevoilor reale ale universității, care se schimbă pe parcursul ciclului de viață al SIC.
Descrierea prezentării Etapele creării unui model de ciclu de viață AIS AIS pe diapozitive
Ciclu de viață AIS este un set de etape prin care AIS parcurge în dezvoltarea sa din momentul în care se ia decizia de a crea un sistem până în momentul în care acesta încetează să mai funcționeze.
Etapele ciclului de viață 1 Planificare și analiză (etapa de pre-proiectare) - determinarea a ceea ce ar trebui să facă sistemul. Întocmirea unui studiu de fezabilitate (TES) și a specificațiilor tehnice (TOR).
2 Proiectare (proiectare tehnică și logică) - determinarea modului în care va funcționa sistemul (specificarea* subsistemelor, componentelor funcționale și modalităților de interacțiune a acestora). Pregatirea proiectului tehnic. * Specificație - o descriere precisă, completă și clar formulată a cerințelor pentru o anumită sarcină.
3. Implementare (proiectare detaliată, programare) - Crearea componentelor funcționale și a subsistemelor individuale, conectarea subsistemelor într-un singur întreg. Completarea bazei de date. Crearea de instrucțiuni pentru personal. Înregistrarea unui proiect de lucru
4 Implementare (testare, operare de probă) – instalarea și punerea în funcțiune a sistemului, depanarea subsistemelor, instruirea personalului. Întocmirea unui raport de testare de recepție.
Note 1. Etapele 2 și 3 pot fi combinate într-una singură: proiectare tehnică de lucru sau sinteza sistemului. 2. În fiecare etapă a ciclului de viață se utilizează un anumit set de soluții tehnice și documente relevante
3. Pentru fiecare etapă, documentele și deciziile luate la etapa precedentă constituie punctele de plecare. 4. Modelele ciclului de viață determină ordinea de execuție a etapelor în procesul de creare a unui sistem și criteriile de trecere de la etapă la etapă.
Modelul ciclului de viață este un model al creării și utilizării unui AIS, care reflectă diferitele stări ale sistemului de la începutul său până în momentul învechirii sale complete.
Modele de bază ale ciclului de viață în cascadă – implică o tranziție la etapa următoare după finalizarea completă a lucrării celei anterioare. Acest model este utilizat în construcția sistemelor informatice automatizate pentru care toate cerințele sunt formulate precis și complet încă de la început. Dezavantaje: schema rigida - imposibilitatea revenirii la etapele anterioare si utilizare pentru sisteme complexe.
Model iterativ pas cu pas Presupune prezența feedbackîntre cicluri. Avantajul este că ajustările între etape oferă o mai mare flexibilitate și mai puțin efort. Dezavantajul este că durata de viață a fiecărei etape se poate extinde pe întreaga perioadă de creare a sistemului Dificultăți și dezavantaje ale modelului ciclului de viață în spirală Principala problemă este determinarea tranziției la următoarea etapă: pentru a rezolva aceasta, se introduc restricții de timp pentru fiecare. a etapelor. Tranziția se realizează în conformitate cu un plan întocmit pe baza datelor statistice din proiectele anterioare și a experienței dezvoltatorilor. Dezavantaje: Greșelile făcute în timpul etapelor de analiză și proiectare pot duce la probleme în etapele ulterioare și eșecul întregului proiect.
Rolul de utilizator AIS este creat pentru a satisface nevoile de informații ale unui anumit utilizator. El este implicat direct în activitatea sa. .
Utilizatorul participă la formularea problemei și efectuează operațiuni de probă, în timpul căreia poate detecta deficiențe în formulare, poate ajusta informațiile de intrare și de ieșire, formulare pentru emiterea rezultatelor și documente.
Participarea utilizatorilor la crearea sistemelor informatice automatizate asigură soluții prompte și de înaltă calitate la probleme și reduce timpul de introducere a noilor tehnologii.
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 a 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. Arhitectura AIS UP 66
2.3. Componentele AIS UP 89
2.4. Capitolul 2 Concluzii 102
3. Metode de implementare practică a AIS UE 104
3.1. Instrumente de dezvoltare AIS UP 104
3.2. Experiență în implementarea practică a modelului AIS UP 111
3.3. Capitolul 3 Concluzii 123
4. Concluzie 125
5. Terminologie și abrevieri 128
6. Literatură
Introducere în lucrare
Activitate intreprinderi moderne asociat cu mișcarea fluxurilor interdependente și voluminoase de materiale, financiare, de muncă și resurse 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ă este conditii moderne imposibil fără utilizarea fondurilor prelucrare automată informatii tehnice si economice.
În ultimii 40 de ani, tehnologiile informaționale automatizate (IT) au fost utilizate în mod activ pentru a rezolva probleme de contabilitate, planificare și analiză. activitate economicăîntreprinderi cu diferite forme de proprietate, afilierea industriei, structura organizatoricași amploarea activității. În acest timp, s-a acumulat o vastă experiență practică în crearea sistemelor informatice automate de management al întreprinderii (AIS EM), iar metodologiile de management au fost dezvoltate și au primit recunoaștere universală, a căror utilizare este imposibilă în afara unui mediu informatic. Se poate afirma cu toată responsabilitatea că AIS UE au devenit o componentă integrală 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., Khotashova E.N., Brady J., Brady J. , Cook M., Finkelstein K., Hammer M. și alți autori. Abordările pe care le-au propus au devenit baza pentru utilizarea tehnologiei informatice în întreprinderi la rezolvarea problemelor de contabilitate, planificare și analiză a activităților financiare și economice. Cu toate acestea
modelele propuse de ei nu țineau cont de realitățile economiei societate informaţionalăși nivelul actual de dezvoltare IT.
Dezvoltarea mijloacelor de comunicare promovează interacțiunea din ce în ce mai strânsă între producători și consumatori, furnizori și cumpărători, crește concurența pe piață, extinde granițele piețelor locale către cele naționale și transnaționale și accelerează timpul tranzacțiilor economice și al tranzacțiilor financiare. Introducerea rețelelor globale de calculatoare în procesele economice a condus la apariția unor noi concepte: economia societății informaționale, afacerile electronice (e-business), e-commerce(comerț electronic), electronic platforma de tranzactionare(e-marketplace), etc. Tendințele de globalizare a economiei se reflectă într-o nouă metodologie de organizare a afacerilor, în care problemele creșterii flexibilității construirii proceselor de afaceri și eficiența relațiilor cu clienții și furnizorii vin în prim-plan. .
Conceptele existente pentru organizarea AIS CP se bazează pe o abordare funcțională a distribuției sarcinilor între subsistemele sale. Cu toate acestea, AIS, construit ca un complex de subsisteme concentrate pe funcții de management individuale, nu îndeplinește cel mai bine cerințele de continuitate a proceselor de afaceri end-to-end ale unei întreprinderi. Prin urmare, în ultimii ani O abordare care pune procesele de afaceri în prim plan, mai degrabă decât funcțiile individuale ale serviciilor sistemului de management care le realizează, devine din ce în ce mai populară. Acest lucru necesită dezvoltarea unui nou concept pentru arhitectura AIS UE. În același timp, este evident că trecerea la o nouă arhitectură AIS CP nu poate fi efectuată peste noapte, deoarece de-a lungul multor ani întreprinderile și organizațiile au pus în funcțiune un număr mare de instrumente software care implementează soluția unor probleme importante de management, a căror utilizare nu poate fi abandonată imediat. Din păcate, cele mai multe dintre ele sunt concentrate pe funcționarea autonomă, ceea ce complică semnificativ integrarea cuprinzătoare a fluxurilor de informații. Multe existente produse software, oferind suport pentru rezolvarea noilor probleme de management al întreprinderii care au apărut în contextul globalizării economiei, au fost dezvoltate și fără o dezvoltare suficientă a interfețelor de interacțiune cu sisteme software, implementând rezolvarea problemelor conexe. În aceste condiţii, sarcina de sinteză capătă o importanţă deosebită. sisteme complexe managementul întreprinderii prin integrarea de componente gata făcute de la producători terți, soluții personalizate și dezvoltări interne.
Ideea de implementare a standardelor a fost mult timp discutată în publicațiile oamenilor de știință și practicieni integrarea sistemului software furnizat de diverși producători. Progresul instrumentelor de sistem a dus la apariția tehnologiilor de dezvoltare software orientate pe obiecte și bazate pe componente, care fac posibilă construirea de 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 de aplicații (SAP, PeopleSoft, Siebel etc.), guvern de renume, internaţionale, comerciale şi organizatii non-profitși asociații (ISO, IEEE, ASCII, APICS, RosStandard etc.) au dezvoltat și pun activ în practică tehnologii de integrare hardware și software, permițând crearea de sisteme deschise bazate pe standarde și protocoale pentru schimbul de date și interacțiunea componentelor într-un mediu eterogen în timp real.
Cu toate acestea, aceste propuneri oferă doar o platformă la nivelul întregului sistem, care necesită clarificări semnificative în legătură cu un domeniu specific. În contextul implementării practice a AIS CP, mecanisme pentru proiectarea și dezvoltarea sistemelor informaționale (IS) folosind arhitecturi componente multi-nivel bazate pe standarde și protocoale sisteme deschise insuficient dezvoltat.
În acest sens, problema dezvoltării unei platforme teoretice și dezvoltării recomandări practice, care vizează construirea unui sistem automat de management al informațiilor care oferă automatizarea completă a tuturor procedurilor informaționale pentru gestionarea întreprinderilor și organizațiilor.
Necesitatea dezvoltării unei abordări holistice pentru rezolvarea problemelor de integrare a sistemelor AIS PM și de automatizare end-to-end a proceselor microeconomice bazate pe IT-ul modern a determinat alegerea subiectului și a direcției. acest studiu.
Scopul studiului este de a dezvolta un model al arhitecturii AIS CP care să ofere automatizare cuprinzătoare și suport informațional pentru procesele de afaceri end-to-end și să justifice alegerea instrumentelor pentru integrarea sistemului său din punct de vedere modern. tehnologia de informație.
Pe baza scopului urmărit, au fost stabilite și rezolvate următoarele sarcini științifice și practice:
Analizați și rezumați abordările existente pentru proiectarea, dezvoltarea și implementarea software-ului AIS CP;
Clasificarea tipurilor de software utilizate în practica de management al întreprinderii;
Cercetarea tehnologiilor și standardelor existente care asigură integrarea diverselor instrumente software;
Identificați problemele care apar la integrarea software-ului utilizat în AIS CP;
Sistematizarea cerințelor pentru software-ul AIS pentru întreprinderi pentru a oferi suport informațional pentru procesele economice end-to-end;
Dezvoltarea unui model al arhitecturii 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 reprezintă metodele și instrumentele de dezvoltare a sistemelor informaționale economice.
Obiectul studiului îl reprezintă sistemele informaționale de management al întreprinderii.
Metodologia cercetării se bazează pe aplicații specifice ale metodologiei cunoașterii științifice în domenii aplicate ale informaticii și matematicii.
Scopurile și obiectivele studiului au fost formulate în conformitate cu direcția principală de lucru dezvoltare ulterioarăși îmbunătățirea metodelor matematice și a tehnologiei informatice utilizate în domeniile economice.
Alături de abordarea științifică generală bazată pe teoria sistemelor, disertația rezumă experiența dezvoltării, implementării și exploatării instrumentelor software de uz casnic și producatori straini, metode
implementarea standardelor internaționale deschise pentru construirea de sisteme informatice. Pe această bază, se propune un set de recomandări metodologice și practice care au fost testate la întreprinderi rusești și străine.
Lucrarea folosește prevederi 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 asistată de calculator a proceselor de afaceri;
Standarde moderne în tehnologia informației.
Cercetarea a analizat și utilizat evoluțiile realizate de echipe de cercetare și oameni de știință individuali de la Academia Financiară din cadrul Guvernului Federației Ruse, Institutul de corespondență din întreaga Rusie de finanțe și economie, Universitatea de Stat de Economie, Statistică și Informatică din Moscova, Universitatea St. Universitatea de Economie și Finanțe din Petersburg. Voznesensky, Cercetare științifică institutie financiarași alte organizații.
Baza de informații a studiului a inclus 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 CIES „Business Programs-Service”.
Noutatea științifică a disertației constă în dezvoltarea unui model de arhitectură AIS CP axat pe automatizarea complexă a proceselor de afaceri end-to-end, și propuneri pentru implementarea acestuia prin integrarea în sistem a software-ului eterogen într-un mediu de rețea eterogen distribuit bazat pe obiect. și tehnologii ale componentelor.
Noutatea științifică este cuprinsă în următoarele rezultate obținute în disertație:
Determinarea și clasificarea cerințelor pentru funcționalitatea software-ului pentru managementul organizațional și economic al întreprinderilor;
Model de arhitectură AIS UP, axat pe automatizarea completă a proceselor de afaceri end-to-end;
Principii de integrare a software-ului de rezolvare a problemelor servicii functionaleîntreprinderi cu software de bază pentru gestionarea proceselor de afaceri, schimbul de date și fluxul de documente;
Propuneri de organizare a unui spațiu informațional unificat al întreprinderii, accesibil angajaților și partenerilor întreprinderii prin portalul web corporativ;
Sugestii de implementare sistem unificat generarea și clasificarea raportărilor folosind instrumente analitice;
Principii de implementare a interacțiunii subsistemelor AIS CP bazate pe tehnologii orientate 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 adaptive ale modelului de arhitectură software AIS CP în conformitate cu cerințele unei întreprinderi specifice, bazat pe capacitatea de a configura subsisteme de bază la procesele de lucru existente și proiectate.
Semnificația practică a lucrării de disertație constă în faptul că implementarea propunerilor propuse face posibilă crearea unor sisteme automate de management al informațiilor care să ofere sprijin eficient proceduri de informare pentru gestionarea activităților unei întreprinderi în contextul globalizării economice și al formării unei societăți informaționale.
Modelul arhitecturii AIS CP propus în lucrare și recomandările de utilizare au suficientă flexibilitate și versatilitate, ceea ce asigură aplicabilitatea acestora în construcția de sisteme informaționale de management pentru întreprinderi de diferite forme de proprietate, specificul industriei și scări de activitate.
Independent semnificație practică au:
Propuneri pentru selectarea și aplicarea standardelor, protocoalelor și altor mecanisme utilizate în integrarea sistemelor AIS UE;
Propuneri pentru automatizarea completă a proceselor de afaceri end-to-end și a fluxului de documente;
Propuneri pentru crearea unui spațiu informațional unificat pentru întreprindere folosind mecanismul portalurilor web;
Propuneri de adaptare a abordării spiral-iterative în dezvoltarea și implementarea software-ului AIS CP.
Semnificația practică a lucrării este evaluată în proiecte specifice pentru implementarea modelului propus orientat spre probleme al unui sistem de automatizare a întreprinderii:
Sistemul integrat de management al întreprinderii „Flagman” al companiei Infosoft,
sisteme de management al relațiilor cu clienții „eRelationship” de la Pivotal Software Corporation (Canada),
Sisteme de raportare corporative „Monarch ES” de la DataWatch (SUA),
Proiect de integrare a sistemelor informatice ale companiilor Sovintel si Tele Ross.
Centrul de formare al companiei Vest-MetaTechnology folosește materiale pregătite de autor pe baza abordării propuse în cursul acestei cercetări atunci când desfășoară cursuri privind dezvoltarea sistemelor informaționale de management al întreprinderii (vezi http://www.vest.msk.ru ).
Materialele de cercetare a disertației sunt utilizate în cercetarea științifică și activitati practice organele executive Asociația Dezvoltatorilor de Software în Domeniul Economiei (AREP) și membrii săi.
Principalele prevederi ale lucrării au fost raportate și discutate la:
Conferința „Soluții IBM în domeniul integrării afacerilor pentru companiile de telecomunicații”, Reprezentanța IBM în Europa de Est (Moscova, 18 iunie 2002);
Simpozion „Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management” (Moscova, martie 2002);
Conferinta dezvoltatorilor de sisteme informatice bazata pe instrumente de la Centura Software Corp. (Berlin, Germania, 17-19 noiembrie 1999);
Conferința „InfoCity: practică și probleme ale informatizării urbane” (Moscova, octombrie 1999);
Conferințe științifice și practice ale companiei „Infosoft” (Moscova, 1995-1999);
Conferinta specialistilor in domeniul sistemelor automate de control si sistemelor informatice informatice " 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ă „Corporate Databases 98” (Moscova, 31 martie-3 aprilie 1998 și 26-29 martie 1996, organizată de Centrul de Tehnologia Informației cu participarea Editurii Open Systems);
Conferința „Tekhnikom-97” (Moscova, 24-26 noiembrie 1997, organizatori: compania SoftService, Asociația Rusă a Utilizatorilor Oracle, reprezentanțe companiile Microsoft, Borland, Computer Associates, Lucent Software).
Probleme ale dezvoltării AIS
Introducerea tehnologiei informației în economie, pătrunderea instrumentelor informatice și de comunicare în managementul întreprinderilor la toate nivelurile și interesul tot mai mare pentru interacțiunea companiilor prin intermediul internetului necesită schimbări conceptuale în abordarea construcției sistemelor informatice de management automatizate. Aceasta se referă nu numai la problemele pur tehnologice de creare și operare a sistemelor informaționale, ci și abordări ale managementului afacerilor în economia societății informaționale.
AIS UP trebuie să răspundă nevoilor de automatizare și informare în întreaga organizație, ceea ce pune următoarele sarcini dezvoltatorilor de software: dezvoltarea unei platforme capabile 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 sistem informatic automat ar trebui să ofere suport pentru: procese de afaceri end-to-end; interfață de utilizator unificată (portal); spațiu informațional comun.
În opinia noastră, esența problemelor puse constă nu atât în aspectele tehnice ale implementării, cât în necesitatea utilizării unui model fundamental nou de arhitectură AIS CP.
Să rezumăm avantajele și dezavantajele diferitelor opțiuni de arhitectură IS din punctul de vedere al posibilităților de construire a unei soluții integrate.
Centralizarea prelucrării datelor impune cerințe mari asupra serverelor. Pe măsură ce numărul de utilizatori concurenți crește (ceea ce este inevitabil atunci când se automatizează procesele într-o întreprindere), sarcina devine excesivă pentru platforma hardware și software-ul utilizat. Folosind diverse soluții hardware (clustering, multiprocesare și alte forme de combinare a resurselor de calcul), precum și procesare distribuită folosind monitoare de tranzacții, servere de aplicații și SGBD-uri industriale puternice, este posibil să se creeze soluții cu adevărat scalabile, ușurând nodurile centrale nu numai prin creșterea puterea hardware-ului, dar și datorită construcției adecvate a componentelor software ale sistemului.
Cu toate acestea, chiar dacă serverul central de baze de date este capabil să ofere performanța necesară, cu o astfel de construcție IS, inevitabil apar probleme în menținerea unei structuri unificate a unei baze de date comune dacă componentele individuale ale software-ului IS sunt dezvoltate de companii diferite sau chiar de echipe de dezvoltare din cadrul aceeași organizație. Instalarea unei baze de date comune cu acces din programe de rezolvare a diverselor probleme aplicate ne permite sa oferim un spatiu informatic comun tehnologiile enumerate mai sus permit accesul la baza de date a unui numar mare de utilizatori, dar acest lucru nu ofera o garantie; funcționare corectă cu date partajate. Problema integrității datelor logice rămâne. Atunci când se utilizează programe de la diferiți producători, devine inevitabil să se separe datele în subsisteme, eventual prin denormalizarea acestora și crearea unor structuri redundante. Arhitectura cu o bază comună este prezentată schematic în figura următoare (Figura 1-14). După cum reiese din diagrama de mai sus, modulele nu interacționează, adică nu există niciun apel de la un modul la altul în timp real, nu există suport operațional pentru procesul end-to-end. Datele sunt stocate în baza de date, din care sunt disponibile altor module care trebuie să conțină funcții de urmărire a modificărilor din aceasta, iar relevanța datelor depinde de frecvența verificării actualizărilor. Un exemplu de proces end-to-end ar fi emiterea unei facturi de către un reprezentant de vânzări. Dacă folosește un sistem CRM pentru aceasta, factura generată în paralel cu extrasul trebuie procesată în modulul logistic al sistemului ERP pentru rezervarea bunurilor, iar imediat după aceea - modul financiar pentru a mări datoria cumpărătorului. Pentru a face acest lucru, modulele relevante trebuie să verifice prezența unui cont nou. 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 proiectate inițial având în vedere o structură de date specifică sau să utilizeze un mecanism de metadate consistent (depozitar).
Când se utilizează o arhitectură diferită, când bazele de date eterogene sunt menținute pe computere diferite (și, eventual, pe rețele diferite) și sunt utilizate de module autonome (Figura 1-15), menținerea integrității logice a datelor este o muncă și mai intensă. sarcină. În acest caz, este necesar să se reglementeze și să implementeze replicarea datelor (sincronizare), unificarea directoarelor, regulile de codificare și clasificare și 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 (exemplu cu emiterea unei facturi).
Platforme pentru implementarea noii arhitecturi AIS UE
LA începutul lui XXI secolului în industria IT au fost dezvoltate și stăpânite la nivel industrial următoarele soluții, asigurând implementarea 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 enunțul sarcinii și executantul acesteia, adică angajații serviciilor funcționale ale întreprinderii sunt capabili să efectueze proceduri de informare în cadrul lor. competență de utilizare a computerelor fără implicarea sau cu sprijinul minim al personalului tehnic însoțitor;
mijloace de suport automatizat pentru colaborarea coordonată a unui grup („echipă”) de lucrători pe un singur proiect, document, sarcină etc.;
mecanism de comunicații electronice, care în multe cazuri a făcut posibilă eliminarea nevoii de transmitere documente pe hârtie, minimizați nevoia de întâlniri, ceea ce este deosebit de important atunci când participanții la un anumit proces de afaceri sunt îndepărtați geografic.
Datorită acestor soluții, a devenit posibilă automatizarea majorității proceselor de lucru care au loc atât în cadrul întreprinderii în activitățile sale financiare, economice, de producție și comerciale, cât și legate de funcții externe. Combinarea software-ului și hardware-ului care automatizează diverse funcții și locuri de muncă face posibilă conectarea proceselor tehnologice (pe baza echipamentelor și dispozitivelor tehnice) și de lucru (cu participarea angajaților din toate departamentele întreprinderii) î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 și de separare a 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 de la producătorii de software de sistem de top: 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 program și regulile de modificare și extindere a acestora (limbaj IDL).
Pentru a lucra într-un mediu eterogen distribuit, cum ar fi Internetul, sunt dezvoltate în mod activ specificațiile pentru serviciile web, fiecare dintre acestea putând implementa una sau mai multe proceduri sau funcții de afaceri. OASIS, BPMI și IBM, Microsoft și BEA au publicat Business Process Execution Language pentru Web Services (BPEL4WS), XLANG și WSFL (Web Services Flow Language) și coaliția WfML - XPDL (XML Process Definition Language).
Tendința este de a combina componente cu interfețe deschise de servicii web în subsisteme care realizează cicluri complete logic de procese de afaceri. Î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, capacitatea de a înlocui componente sau de a le muta în rețea fără a pierde compatibilitatea, este posibilă construirea unui sistem informatic automat care să mențină un echilibru între centralizare și descentralizare în managementul întreprinderii.
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 atunci când acces competitiv zeci de mii de utilizatori în timp real și, de asemenea, garantează toleranța la erori și recuperarea după defecțiuni.
O realizare importantă a industriei IT o reprezintă standardele care au devenit răspândite și recunoscute de producătorii de software de top: protocoale de interacțiune a componentelor (COM/DCOM, CORBA, Java RMI) și formatele de schimb de date (EDI, XML, ).
Standardul EDI și variantele sale industriale (EDIFACT, XI2, HIPAA etc.) au fost utilizate în sectoarele financiare și industriale din America de Nord și Europa încă de la mijlocul anilor '70 și domină astăzi în întreaga lume. Odată cu popularitatea tot mai mare a XML pe Internet, EDI a fost transferat în XML.
Pe baza XML (DTD și XDR), datele sunt dezvoltate, structurate și formatate în diverse sfere 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 Manufacturing and Inventory Management 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 o factură. Natura de auto-documentare a XML asigură că datele pot fi înțelese clar atât de oameni, cât și de programe.
Arhitectura AIS UP
Pentru a construi un model al arhitecturii AIS UE, vom considera întreprinderea ca un set de resurse de muncă, financiare, materiale și informaționale implicate în procesele de afaceri pentru atingerea obiectivelor de afaceri ale întreprinderii. Aici, termenul de obiective de afaceri se referă la obiectivele strategice pe termen lung stabilite de proprietari și manageri conducerea superioară, precum și sarcinile curente atribuite de managerii de top și de mijloc. Un proces de afaceri sau un proces de afaceri este succesiunea de acțiuni ale angajaților, operațiuni la locurile de muncă, precum și funcții efectuate de software și mijloace tehniceîn modul automat. Să numim fiecare acțiune sau secvența lor o etapă a procesului. Operațiile și procedurile pot fi, de asemenea, sinonime pentru acțiuni. Dacă o etapă necesită acțiunile unui angajat (grup de rol, reprezentant sau șef al unui departament, precum și o persoană care deține o funcție), atunci se mai numește și sarcină, iar angajatul este numit interpret. Secvența de acțiuni într-un proces de afaceri poate fi ambiguă, adică descrierea procesului sub forma unui grafic direcționat poate include ramificarea cu condiții pentru trecerea de la o etapă la alta. Lanțurile tipice de etape pot fi împărțite în subprocese. Deplasarea sarcinilor prin 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 pe stadiul actual, atunci acest caz se numește rutare gratuită.
AIS CP ar trebui să permită descrierea formală a proceselor de afaceri în formă grafică sub forma unui grafic direcționat (digraf), ale cărui vârfuri sunt etape, iar marginile sunt tranziții între etape. Într-un caz particular, graficul procesului de afaceri arată ca diagrama rețelei, unde vârfurile indică lucrările indicând durata acestora, iar marginile orientate (săgeți) arată secvența lucrărilor. În conformitate cu descrierea procesului, numită hartă a procesului, sistemul informatic automatizat pentru management 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 lansa proceduri automate.
Parametrii la scară întreprindere afectează organizarea managementului la întreprindere specifică, care se reflectă în cerințele pentru AIS UE. Pe de altă parte, AIS UP afectează amploarea întreprinderii, de exemplu, promovând creșterea afacerii. Modificarea unuia dintre parametri presupune actualizarea AIS, la fel cum introducerea unui AIS poate schimba organizarea managementului.
Scopul concentrării asupra proceselor de afaceri la construirea unui CP AIS 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 software managementul 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” de la pagina 34). Acestea includ: Workflow - un subsistem pentru gestionarea lucrătorilor și procese tehnologice, oferind 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 este un subsistem pentru susținerea funcțiilor de atribuire promptă a sarcinilor și de rutare gratuită (ad-hoc) a sarcinilor între membrii unui grup de executanți; Flux de date - rutare de date, pachete de date, mesaje între aplicații.
Spre deosebire de practica acceptată de utilizare autonomă a sistemelor de acest fel, presupunem aici prezența harta generala proces, un modul general pentru procesarea etapelor procesului, un mecanism general de atribuire a executanților și de rutare a sarcinilor și datelor.
Astfel, datele tehnologice generate dispozitive tehnice, datele factuale introduse în IS de către utilizatori la locurile lor de muncă (inclusiv documentele primare), precum și datele generate de aplicațiile software, vor fi introduse în AIS UP și vor fi disponibile consumatorilor de informații în timp real.
Schematic, ciclul de viață al prelucrării datelor în AIS UE este prezentat în figura următoare (Figura 2-2). Datele introduse manual sau primite de la componentele software sunt formatate ca document, care este procesat în continuare de modulul de flux de documente în conformitate cu harta procesului. De-a lungul rutei de procesare (dacă configurația sistemului o cere), subsistemul de gestionare a documentelor apelează module de subsisteme funcționale pentru procesarea tranzacțiilor financiare, de afaceri și de alt tip. Ca rezultat, acreditările sunt stocate în baze de date structurate. La rândul lor, documentele în sine sunt stocate într-o bază de date de stocare sau nestructurată. Toate aceste baze de date trebuie să fie accesibile modulelor analitice ale subsistemului de raportare pentru a genera rapoartele necesare.
Experiență în implementarea practică a modelului AIS UE
Din 1995 până în 1999, sub îndrumarea autorului disertației, a fost dezvoltat un sistem integrat de automatizare pentru managementul întreprinderii „Flagman” al companiei Infosoft, care momentul actual implementate în peste o sută de întreprinderi mari și mijlocii industriale, de construcții, 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 „Flagman” este modulul de bază „Flux de documente”, care este responsabil pentru introducerea, procesarea, rutarea și tipărirea tuturor documentelor primare. Alte module de bază sunt Administrarea și Instrumentele, care sunt 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 introducerea unică a documentelor primare, generarea conturiîn subsisteme funcționale bazate pe aceste documente, unificarea lucrărilor cu documentele primare.
Dezvoltarea rapidă a subsistemelor și lipsa standardizării interacțiunii lor au condus la faptul că integrarea s-a realizat în jurul unei baze de date centrale și tabele generale. Dacă nu luăm în considerare arhitectura cu două niveluri, a cărei alegere a fost determinată de nivelul de dezvoltare a instrumentelor de dezvoltare în 1995, atunci dependența încrucișată a modulelor a devenit principala problemă pentru dezvoltarea sistemului. Primele sale implementări au scos la iveală insuficiența funcțiilor de automatizare a fluxului de lucru al documentelor doar prin rutarea documentelor și au ridicat problema necesității implementării unui modul de management al proceselor (flux de lucru).
Dacă ne uităm la implementare mai detaliat, modulul de gestionare a documentelor este o bibliotecă de obiecte care este inclusă în toate subsistemele și este, de asemenea, compilată ca 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 crearea registrelor şi jurnalelor de documente .
Operațiile cu documente își schimbă starea și apelează, de asemenea, funcții ale subsistemelor de aplicații. Lista de funcții este inclusă î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 calculele de salarizare, totuși, pentru implementarea completă, rămâne nevoie de un limbaj de scripting (script).
Sistemul are încorporat un generator de rapoarte, 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 de apartenența la modul. Rapoartele sunt clasificate într-o structură ierarhică, fiecare aspect de raport conține un șablon pentru previzualizare și tipărire și interogări SQL pentru generarea setului de date rezultat. Rapoartele generate pot fi prelucrate ulterior ca documente.
De asemenea, trebuie remarcat faptul că sistemul Flagman implementează un sistem unificat aspect subsisteme Un modul comun pentru administrarea elementelor de interfață cu utilizatorul și a funcțiilor AWS, inclusiv meniuri și bare de instrumente, vă permite să personalizați uniform aspectul.
Pe în 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 flux de documente într-un sistem de management al procesului complet funcțional. De asemenea, este necesar să se dezvolte mecanisme de integrare a aplicațiilor externe, deoarece sistemul dispune doar de instrumente de import și export de date.
Cu toate acestea, numeroase exemple de implementare cu succes și operare industriala sistemul „Flagman”, creșterea numărului vânzărilor sale în 2001-2002 indică eficienta economica soluții pentru automatizarea întreprinderilor diverse domenii activități, industrii și scară.
În februarie 1999, sistemul „Flagman” al companiei Infosoft, creat sub conducerea autorului, a fost recunoscut drept cel mai bun Dezvoltarea Rusiei pe instrumentele Centura Team Developer de la Centura Software Corp. (SUA) și compania Interface (Rusia). În 1999, 2000 și 2001 CIS „Flagman” a fost certificat ca sistem informatic la scară întreprindere de către experții juriului concursului „Business-Soft” susținut de Asociația Dezvoltatorilor de Software în Domeniul Economiei (AREP), CIES „Business Programs-Service”, revista „Contabilitate” și „Ziar financiar” „
Abordarea în cascadă s-a dovedit bine în construcția sistemelor informaționale, pentru care chiar la începutul dezvoltării este posibil să se formuleze toate cerințele destul de precis și complet pentru a oferi dezvoltatorilor libertatea de a le implementa tehnic cât mai bine posibil. . Această categorie include sisteme complexe cu un număr mare de sarcini de calcul, sisteme în timp real etc.
Modelul ciclului de viață AIS este o structură care descrie procesele, acțiunile și sarcinile care sunt efectuate în timpul dezvoltării, exploatării și întreținerii de-a lungul întregului ciclu de viață al sistemului.
Alegerea unui model de ciclu de viață depinde de specificul, scara, complexitatea proiectului și setul de condiții în care este creat și funcționează AIS.
Modelul ciclului de viață AIS include:
Rezultatele muncii în fiecare etapă;
Evenimente cheie sau puncte de finalizare a lucrărilor și luarea deciziilor.
În conformitate cu modelele de ciclu de viață cunoscute, software-ul determină modelele de ciclu de viață AIS - cascadă, iterativă, spirală.
I. Model în cascadă descrie abordarea clasică a dezvoltării sistemelor în orice domeniu; utilizat pe scară largă în anii 1970 și 80.
Modelul în cascadă oferă o organizare secvențială a muncii, iar principala caracteristică a modelului este împărțirea tuturor lucrărilor în etape. Trecerea de la etapa anterioară la următoarea are loc numai după finalizarea completă a tuturor lucrărilor precedentei.
Evidențiați cinci etape de dezvoltare durabilă, practic independente de domeniul de studiu
Pe primulÎn această etapă, se efectuează un studiu al zonei cu probleme și se formulează cerințele clientului. Rezultatul această etapă este o specificație tehnică (sarcina de dezvoltare) convenită cu toate părțile interesate.
În timpul doilea etapa, conform cerintelor caietului de sarcini, sunt dezvoltate anumite solutii de proiectare. Rezultatul este un set de documentație de proiectare.
Treilea etapa - implementarea proiectului; În esență, dezvoltarea (codarea) software-ului în conformitate cu deciziile de proiectare din etapa anterioară. Metodele de implementare nu au o importanță fundamentală în acest caz. Rezultatul acestei etape este un produs software finit.
Pe patruleaÎn această etapă, software-ul rezultat este verificat pentru conformitatea cu cerințele prevăzute în specificațiile tehnice. Funcționarea de probă face posibilă identificarea diferitelor tipuri de deficiențe ascunse care apar în condițiile reale de funcționare ale AIS.
Ultima etapă este livrarea proiect finalizat, iar principalul lucru aici este să convingi clientul că toate cerințele sale sunt pe deplin îndeplinite.
Fig. 1.1 Modelul în cascadă al ciclului de viață AIS
Etapele de lucru din cadrul modelului cascadă sunt adesea numite părți ciclu de proiect AIS, deoarece etapele constau în multe proceduri iterative pentru clarificarea cerințelor sistemului și a opțiunilor de proiectare. Ciclul de viață al unui AIS este semnificativ mai complex și mai lung: poate include un număr arbitrar de cicluri de clarificare, modificări și completări la deciziile de proiectare deja adoptate și implementate. În aceste cicluri, AIS este dezvoltat și componentele sale individuale sunt modernizate.
Avantajele modelului în cascadă:
1) la fiecare etapă, se generează un set complet de documentație de proiectare care îndeplinește criteriile de completitudine și coerență. În etapele finale, este elaborată documentația utilizatorului, care acoperă toate tipurile de suport AIS prevăzute de standarde (organizațional, informațional, software, tehnic etc.);
2) implementarea secvențială a etapelor de lucru vă permite să planificați datele de finalizare și costurile corespunzătoare.
Modelul în cascadă a fost dezvoltat inițial pentru a rezolva diferite tipuri de probleme de inginerie și nu și-a pierdut importanța pentru domeniul aplicat până în prezent. În plus, abordarea cascadă este ideală pentru dezvoltarea AIS, deoarece chiar la începutul dezvoltării este posibil să se formuleze destul de precis și complet toate cerințele pentru a oferi dezvoltatorilor libertatea de implementare tehnică. Astfel de AIS, în special, includ sisteme complexe de calcul și sisteme în timp real.
Dezavantajele modelului în cascadă:
Întârziere semnificativă în obținerea rezultatelor;
Erorile și deficiențele în orice etapă apar, de regulă, în etapele ulterioare de lucru, ceea ce duce la necesitatea unei retururi;
Dificultatea lucrului paralel la proiect;
Suprasaturarea excesivă de informații a fiecărei etape;
Complexitatea managementului de proiect;
Nivel înalt riscul și nefiabilitatea investițiilor.
Întârziere în primirea rezultatelor se manifestă prin faptul că o abordare consecventă a rezultatelor dezvoltării sunt convenite cu părțile interesate numai după finalizarea următoarei etape de lucru. Ca urmare, se poate dovedi că AIS în curs de dezvoltare nu îndeplinește cerințele și astfel de inconsecvențe pot apărea în orice stadiu de dezvoltare; în plus, erorile pot fi introduse neintenționat atât de către designeri-analiști, cât și de către programatori, deoarece nu li se cere să aibă o bună înțelegere a domeniilor pentru care este dezvoltat AIS.
Reveniți la etapele anterioare. Acest dezavantaj este o manifestare a celui precedent: lucrul secvenţial pas cu pas asupra unui proiect poate duce la faptul că erorile făcute în etapele anterioare sunt descoperite doar în etapele ulterioare. Drept urmare, proiectul este revenit la etapa anterioară, reluat și abia apoi transferat la lucrările ulterioare. Acest lucru poate cauza întreruperi de program și poate complica relațiile dintre echipele de dezvoltare care efectuează etapele individuale.
Cea mai proastă opțiune este atunci când deficiențele etapei anterioare sunt descoperite nu în etapa următoare, ci mai târziu. De exemplu, în etapa de operare de probă, pot apărea erori în descrierea domeniului subiectului. Aceasta înseamnă că o parte din proiect trebuie să fie readusă la stadiul inițial de lucru.
Dificultate în munca paralelă este asociată cu necesitatea de a coordona diferite părți ale proiectului. Cu cât este mai puternică interconectarea părților individuale ale proiectului, cu atât mai des și mai atent trebuie efectuată sincronizarea, cu atât echipele de dezvoltare sunt mai dependente unele de altele. Ca urmare, avantajele muncii paralele se pierd pur și simplu; Lipsa paralelismului afectează negativ și organizarea muncii a întregii echipe.
Problemă suprasaturarea informatiei apare din cauza dependențelor puternice dintre diferitele grupuri de dezvoltare. Faptul este că atunci când se fac modificări la una dintre părțile proiectului, este necesar să se anunțe acei dezvoltatori care l-au folosit (ar putea folosi) în munca lor. Dacă există un număr mare de subsisteme interconectate, sincronizarea documentației interne devine separată cea mai importantă sarcină: Dezvoltatorii trebuie să devină în mod constant conștienți de schimbări și să evalueze modul în care aceste modificări le vor afecta rezultatele.
Complexitatea managementului de proiect se datorează în principal secvenței stricte a etapelor de dezvoltare și prezenței unor relații complexe între diferitele părți ale proiectului. Secvența reglementată de lucru duce la faptul că unele grupuri de dezvoltare trebuie să aștepte rezultatele muncii altor echipe, astfel încât este necesară intervenția administrativă pentru a conveni asupra calendarului și componenței documentației transferate.
Dacă în lucrare sunt detectate erori, este necesar să revenim la etapele anterioare; munca curenta cei care gresesc sunt intrerupti. Consecința acestui lucru este de obicei un termen limită ratat atât pentru proiectele reparate, cât și pentru cele noi.
Este posibil să se simplifice interacțiunea dintre dezvoltatori și să se reducă suprasaturarea de informații a documentației prin reducerea numărului de conexiuni între părțile individuale ale proiectului, dar nu fiecare AIS poate fi împărțit în subsisteme slab conectate.
Nivel ridicat de risc. Cum proiect mai complex, cu cât durează mai mult fiecare etapă de dezvoltare și cu atât relațiile dintre părțile individuale ale proiectului sunt mai complexe, al căror număr este și el în creștere. În plus, rezultatele dezvoltării pot fi văzute și evaluate cu adevărat numai în etapa de testare, adică după finalizarea analizei, proiectării și dezvoltării - etape a căror implementare necesită timp și bani semnificativi.
Evaluarea tardivă creează probleme serioase în identificarea erorilor de analiză și proiectare - este necesară revenirea la etapele anterioare și repetarea procesului de dezvoltare. Cu toate acestea, revenirea la etapele anterioare poate fi asociată nu numai cu erori, ci și cu schimbări care au avut loc în domeniul subiectului sau în cerințele clienților în timpul dezvoltării. În același timp, nimeni nu garantează că subiectul nu se va schimba din nou până când următoarea versiune a proiectului este gata. De fapt, aceasta înseamnă că există posibilitatea unei „ciclări” a procesului de dezvoltare: costurile proiectului vor crește constant, iar data de livrare a produsului finit va fi întârziată în mod constant.
II. Model iterativ (Model treptat cu control intermediar) constă dintr-o serie de cicluri (pași) scurte de planificare, implementare, studiu, acțiune.
Crearea de sisteme informatice automatizate complexe presupune aprobarea solutiilor de proiectare obtinute in timpul implementarii sarcinilor individuale. Abordarea „de jos în sus” a proiectării necesită astfel de iterații ale returnărilor, atunci când soluțiile de proiectare pentru sarcini individuale sunt combinate în cele generale de sistem. În același timp, este necesar să se revizuiască cerințele formate anterior.
Avantaj Modelul iterativ este că ajustările între etape asigură o intensitate mai mică a muncii de dezvoltare în comparație cu modelul în cascadă.
Defecte model de iterație:
· durata de viață a fiecărei etape se extinde pe întreaga perioadă de lucru;
· din cauza unui număr mare de iterații, apar discrepanțe în implementarea deciziilor de proiectare și a documentației;
· complexitatea arhitecturii;
· dificultățile în utilizarea documentației de proiectare în etapele de implementare și exploatare necesită reproiectarea întregului sistem.
III. Model în spirală, spre deosebire de cel în cascadă, dar similar celui precedent, presupune un proces iterativ de dezvoltare a unui AIS. În același timp, crește importanța etapelor inițiale, precum analiza și proiectarea, la care se verifică și se justifică fezabilitatea soluțiilor tehnice prin realizarea de prototipuri.
Fiecare iterație reprezintă un ciclu complet de dezvoltare, care are ca rezultat lansarea unei versiuni interne sau externe a unui produs (sau a unui subset al produsului final) care este îmbunătățită de la iterație la iterație pentru a deveni un sistem complet (Figura 1.2).
Orez. 1.2. Model în spirală al ciclului de viață AIS
Astfel, fiecare tură a spiralei corespunde creării unui fragment sau a unei versiuni a unui produs software, obiectivele și caracteristicile proiectului sunt clarificate, calitatea acestuia este determinată și lucrul este planificat pentru următoarea tură a spiralei. Fiecare iterație servește la aprofundarea și specificarea consecventă a detaliilor proiectului, în urma căruia este selectată o opțiune rezonabilă pentru implementarea finală.
Utilizarea modelului în spirală vă permite să treceți la următoarea etapă a proiectului fără a aștepta ca cea actuală să fie complet finalizată - lucrul neterminat poate fi finalizat la următoarea iterație. Sarcina principală fiecare iterație - pentru a crea un produs funcțional pe care să-l demonstreze utilizatorilor cât mai repede posibil. Astfel, procesul de realizare a clarificărilor și completărilor la proiect este simplificat semnificativ.
Abordarea spirală a dezvoltării software depășește majoritatea dezavantajelor modelului cascadă, în plus, oferă o serie de caracteristici suplimentare, făcând procesul de dezvoltare mai flexibil.
Avantaje abordare iterativă:
Dezvoltarea iterativă simplifică semnificativ efectuarea de modificări la proiect atunci când cerințele clienților se modifică;
Când se utilizează modelul în spirală, elementele individuale ale AIS sunt integrate treptat într-un singur întreg. Deoarece integrarea începe cu mai puține elemente, există mult mai puține probleme în timpul integrării;
Reducerea nivelului riscurilor (o consecință a avantajului anterior, deoarece riscurile sunt descoperite tocmai în timpul integrării). Nivelul de risc este maxim la începutul dezvoltării proiectului și scade pe măsură ce dezvoltarea progresează;
Dezvoltarea iterativă oferă o mai mare flexibilitate în managementul proiectelor, făcând posibilă efectuarea de modificări tactice la produsul dezvoltat. Astfel, puteți reduce timpul de dezvoltare prin reducerea funcționalității sistemului sau puteți utiliza produse de la terți ca componente în locul propriilor dezvoltări (relevant atunci când economie de piata când este necesar să reziste promovării produselor concurenților);
Abordarea iterativă facilitează reutilizarea componentelor deoarece este mult mai ușor să identifici părți comune ale unui proiect atunci când acestea sunt deja parțial dezvoltate decât să încerci să le izolezi chiar la începutul proiectului. Analizând designul după câteva iterații inițiale dezvăluie componente comune, reutilizabile, care vor fi îmbunătățite în iterațiile ulterioare;
Modelul în spirală permite un sistem mai fiabil și mai stabil. Acest lucru se datorează faptului că pe măsură ce sistemul evoluează, erorile și punctele slabe sunt descoperite și corectate la fiecare iterație. În același timp, sunt ajustați parametrii critici de eficiență, care în cazul modelului în cascadă sunt disponibili numai înainte de implementarea sistemului;
Abordarea iterativă permite îmbunătățirea procesului
dezvoltare - ca rezultat al analizei la finalul fiecărei iterații, se evaluează schimbările în organizarea dezvoltării; se îmbunătățește în următoarea iterație.
Problema principală a ciclului spiral- dificultatea de a determina momentul trecerii la etapa urmatoare. Pentru a o rezolva, este necesar să se introducă restricții de timp pentru fiecare etapă a ciclului de viață. În caz contrar, procesul de dezvoltare se poate transforma într-o îmbunătățire nesfârșită a ceea ce a fost deja făcut.
Implicarea utilizatorilor în procesul de proiectare și copiere a aplicației vă permite să primiți comentarii și completări la cerințe direct în timpul procesului de proiectare a aplicației, reducând timpul de dezvoltare. Reprezentanții clienților au posibilitatea de a controla procesul de creare a sistemului și de a influența conținutul funcțional al acestuia. Rezultatul este punerea în funcțiune a unui sistem care ține cont de majoritatea nevoilor clienților.
Modelul ciclului de viață și tehnologia de proiectare
Mai devreme spuneam că tehnologia de proiectare stabilește succesiunea de acțiuni necesare obținerii unui proiect IP. Evident, implementarea fiecăreia dintre aceste acțiuni înseamnă o tranziție a sistemului informațional de la o stare la alta. Astfel, orice tehnologie de proiectare descrie în mod unic un anumit model de ciclu de viață. Pe de altă parte, prin construirea unui model de ciclu de viață al unui sistem informațional, adică prin definirea:
· sarcini, alcătuirea și succesiunea lucrărilor efectuate;
· rezultatele obținute în urma fiecărei acțiuni efectuate;
· metode și mijloace necesare pentru efectuarea lucrării;
· rolurile și responsabilitățile participanților;
· alte informații necesare pentru planificarea, organizarea și gestionarea dezvoltării colective a PI,
vom primi o descriere clară a tehnologiei de proiectare pe care am ales-o. Astfel, modelul ciclului de viață este o parte integrantă și cea mai importantă 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, ori de câte ori este posibil, pe terminologia GOST-urilor interne. Etapa de proiectare vom numi o parte a procesului de creare a unui IP, limitată de un anumit interval de timp și care se încheie cu lansarea unui anumit produs (model, documentație, text program etc.). Pe baza obiectivelor comune, etapele de proiectare pot fi combinate în etape. De exemplu, scena Proiect tehnic”, etapa „Implementare”, etc.
Conform datelor publicate, fiecare etapă a dezvoltării AIS necesită o anumită perioadă de timp. În cea mai mare parte (45-50%) timpul este alocat codării, testării complexe și offline. În medie, dezvoltarea unui AIS ocupă o treime din întregul ciclu de viață al sistemului.
Orez. Distribuția timpului în timpul dezvoltării AIS
Etapele creării unui AIS (ISO/IEC 15288)
Standardul ISO/IEC 12207 definește o structură a ciclului de viață care conține procesele, activitățile și sarcinile care trebuie efectuate în timpul creării unui sistem informațional.
