Proiectarea sistemelor informatice este un proces în mai multe etape de creare și/sau modernizare a acestora prin utilizarea unui set ordonat de metodologii și instrumente. Proiectarea (spre deosebire de modelare) presupune lucrul cu un obiect inexistent și are ca scop crearea unui sistem informațional în domeniul:
- prelucrarea obiectelor viitoarei baze de date,
- programe de scriere (inclusiv formulare de raportare și ecran) care asigură executarea interogărilor la date,
- ținând cont de funcționarea unui mediu specific (tehnologie).
Dacă identificăm etapa de proiectare a sistemelor informaționale ca o etapă separată, atunci aceasta poate fi plasată între etapele de analiză și dezvoltare. Cu toate acestea, în practică, o împărțire clară în etape este de obicei dificilă sau imposibilă, deoarece proiectarea, începând formal cu definiția obiectivele proiectului, continuă adesea prin etapele de testare și implementare.
Scopul proiectării sistemului informațional și conceptele aferente
Managerii moderni ai organizațiilor publice și private sunt conștienți de faptul că viteza de procesare a informațiilor, care este în continuă schimbare și crește în volum, este o chestiune de supraviețuire a companiei pe piață și avantaj competitiv. În general, obiectivele proiectelor de creare a sistemelor informaționale se rezumă la furnizarea de condiții care să permită recepționarea, procesarea și utilizarea acestor informații prin crearea unui sistem funcțional, sigur, cu suficiente:
- nivelul de adaptabilitate la condițiile în schimbare,
- debit,
- timpul de răspuns al sistemului la o solicitare,
- nivelul de securitate,
- gradul de ușurință în utilizare.
Un sistem informațional (IS) este o colecție de informații conținute într-o bază de date și tehnologii (precum și instrumente tehnice) care permit prelucrarea informațiilor. ÎN în acest caz,, tehnologiile includ și metode de detectare, colectare, procesare, stocare, distribuire a informațiilor și metodele care permit implementarea acestor metode. Managementul informațiilor aceasta se rezumă la utilizarea acestor metode pentru a controla procesele de planificare, proiectare, operare și analiză a SI. Tehnologia de proiectare se bazează pe metodologia aleasă pentru o anumită sarcină ca un set de principii exprimate într-un singur concept definit.
Organizarea designului IP
Organizarea designului IC este de obicei împărțită în 2 tipuri:
- Designul canonic reflectă caracteristicile tehnologice ale procesului original (individual).
- Designul standard, care se caracterizează printr-o soluție de proiectare standard (TDS), este replicat și potrivit pentru utilizare repetată.
Designul canonic distinge reflexia tehnologie manuală proiectare, implementare la nivel de performer, utilizarea instrumentelor universale de suport informatic.
Designul canonic este utilizat în principal pentru circuite integrate locale și relativ mici, cu utilizarea minimă a soluțiilor standard. Adaptarea soluțiilor de proiectare are loc numai prin reprogramarea modulelor software. 
Proiectarea canonică este organizată folosind un model de ciclu de viață în cascadă. Aceasta presupune împărțirea procesului în următoarele etape și etape:
- Etapa pre-proiect. Se întocmesc și se întocmesc specificațiile tehnice. Adică se formează cerințele pentru sistemul informațional, se dezvoltă conceptul acestuia, se întocmește un studiu de fezabilitate și se scriu specificații tehnice.
- Etapa de proiectare presupune pregătirea proiectelor preliminare și tehnice, elaborarea documentației de lucru.
- Etapa post-proiect demarează activitățile de implementare a SI, instruirea personalului și analiza rezultatelor testelor. O parte a acestei etape este menținerea PI și eliminarea deficiențelor identificate.
Etapele, dacă este necesar, pot fi mărite sau detaliate - combinați etapele succesive, eliminați-le pe cele „inutile”, începeți următoarea etapă înainte de a o finaliza pe cea anterioară.
Metoda de proiectare standard se distinge prin capacitatea de a descompune IS proiectat în componente, care includ module software, subsisteme, seturi de sarcini etc. Pentru a implementa componente, puteți utiliza solutii standard care există deja pe piață și personalizați-le pentru a se potrivi nevoilor unei anumite organizații. În acest caz, proiectarea standard necesită disponibilitatea obligatorie a documentației care descrie în detaliu TPR și procedurile de configurare.
Descompunerea poate avea mai multe niveluri, ceea ce face posibilă distingerea claselor de TPR:
- elemental – pentru o sarcină separată (element),
- subsistem - pentru subsisteme individuale,
- obiect - soluții de proiectare standard ale industriei care conțin întregul set de subsisteme.
Abilitatea de a implementa o abordare modulară este considerată un avantaj al TPR-urilor elementare. Cu toate acestea, dacă elementele diferite sunt incompatibile, procesul de combinare a acestora duce la creșterea costurilor. Subsistemul TPR, pe lângă implementarea unei abordări modulare, face posibilă realizarea unei configurații parametrice pentru obiecte la diferite niveluri de control. Problemele de consolidare apar atunci când este implicat produsul mai multor producători diferiți de software. În plus, adaptabilitatea TPR din punctul de vedere al reinginerării continue a proceselor este considerată insuficientă. TPR-urile obiect, în comparație cu clasele anterioare, au un număr mare de avantaje:
- scalabilitate, care face posibilă utilizarea configurațiilor IS pentru un număr diferit de stații de lucru,
- unitatea metodologică a componentelor,
- compatibilitatea componentelor IC,
- deschiderea arhitecturii - capacitatea de a implementa soluții de proiectare pe platforme de diferite tipuri,
- configurabilitate – capacitatea de a utiliza subsetul dorit de componente IS.
În timpul implementării proiectării standard, sunt utilizate abordări orientate spre parametri și orientate pe model.
Metodologii de bază de proiectare IC
Caracteristicile specifice ale procesului de proiectare fac posibilă distingerea metodologiilor bazate pe principii diferite. Printre principalele metodologii moderne de proiectare IC se numără următoarele:
- SADT. Metodologia de modelare a muncii funcționale, care se bazează pe analiza structurală și reprezentare grafică organizarea ca sistem de funcţii. Aici distingem modele funcționale, informaționale și dinamice. Metodologia este cunoscută în prezent ca notația IDEF0 (standard). Procesul analizat este reprezentat grafic sub forma unui patrulater, unde influențele de reglementare și de control sunt reprezentate în partea de sus, obiectele de control în partea de jos, datele de intrare în stânga și datele de ieșire în dreapta.
- RAD. Metodologie de dezvoltare rapidă a aplicațiilor. În R.A.D. dezvoltare rapidă aplicațiile sunt posibile prin utilizarea designului orientat pe componente. Metodologia este utilizată pentru proiecte cu un buget limitat, cerințe neclare pentru IP și termene scurte de implementare. Este folosit dacă interfața cu utilizatorul poate fi demonstrată într-un prototip, iar proiectul poate fi împărțit în elemente funcționale.
- RUP. Metodologia RUP implementează abordări iterative și incrementale. Sistemul este construit pe baza arhitecturii sistemului informațional, iar planificarea și managementul proiectelor se bazează pe cerințele funcționale ale sistemului informațional. Dezvoltarea unui sistem informatic general are loc în iterații, ca un complex de proiecte individuale mici, cu propriile planuri și sarcini. Ciclul iterativ este caracterizat prin feedback periodic și adaptare la nucleul IS.
Există mai multe clasificări ale metodologiilor: pentru utilizarea TPR, pentru utilizarea instrumentelor de automatizare etc. De exemplu, după gradul de adaptabilitate, reconstrucții (când modulele sunt reprogramate), parametrizare (când modificarea parametrilor presupune generarea unui soluție de proiectare), restructurare (la schimbarea modelului zonei cu probleme) se disting însoțite de generarea automată a unei soluții de proiectare).
Centrul de service este o organizație angajată în furnizarea de servicii de asistență și întreținere a mașinilor, echipamentelor și altor produse. Activitățile centrelor de service includ reparații înainte de vânzare, garanție și postvânzare.
Enterprise IP Mikhailov A.O. efectueaza reparatii si intretinere aparate electrocasniceși electronice, precum și computere, telefoane și tablete pe care clienții le aduc la birou, precum și reumplerea cartușelor și instalarea rețelelor și a PBX-urilor de birou. Dacă nu este posibilă livrarea echipamentului, clientul însuși se va deplasa la șantier și, dacă este necesar, îl va livra de către centrul de service. Când un client contactează centrul de service, dispecerul completează o cerere de acceptare a comenzii. Se efectuează o analiză a obiectului, în urma căreia se concluzionează dacă echipamentul va fi reparat sau nu. Departamentul de inginerie întocmește o listă de prețuri pentru repararea și întreținerea echipamentelor, deoarece lucrează cu furnizorii de piese de schimb și dispozitive pentru repararea echipamentelor. Se efectuează reparații echipamente speciale respectarea regulilor de siguranță. Compania vinde și dispozitive periferice pentru telefoane, tablete și computere. Compania achizitioneaza echipament folosit si defect.
Lucru la întreprindere specialisti calificati cu mulți ani de experiență. Directorul conduce întreaga funcționare a întreprinderii.
Adresa companiei:
Regiunea Perm, Kungur, st. Lenina 66
Mod de operare:
Luni-Vineri: 10 - 19 fără prânz
Soare: închis.
Prin structurarea listei de servicii, o întreprindere își poate crește profiturile, extinde limitele întreprinderii sau deschide un alt centru de servicii în altă locație, se poate îmbunătăți și calitatea serviciilor oferite, iar numărul clienților poate crește.
Analiza domeniului subiectului oferă o descriere completă a domeniului subiect al întreprinderii IP Mikhailov A.O. pentru a crea un sistem informațional funcțional pentru această întreprindere. Este oferită o descriere a activității centrului de servicii, indicând activitatea departamentului de inginerie. De asemenea, a fost creată o structură organizatorică a întreprinderii, care arată interacțiunea dintre director și subordonați.
Formarea documentelor de bază pentru managementul proiectelor sistemului informațional
Un proiect este un set de sarcini sau activități asociate cu atingerea unui scop planificat, care este de obicei de natură unică și nerepetitivă.
Managementul de proiect este utilizarea cunoștințelor, abilităților, metodelor, instrumentelor și tehnologiilor în executarea unui proiect pentru a atinge sau depăși așteptările participanților la proiect.
Pentru a gestiona corect un proiect de sistem informatic, trebuie să creați documente de bază de management de proiect. Documentele de bază vor fi Carta și Planul de Management al Proiectului.
Carta Proiectului
Carta de proiect este un instrument care autorizează în mod oficial proiectul și este legătura de legătură cu viitorul proiect munca curenta organizatii.
Carta Proiectului documentează cerințele inițiale pentru proiect pentru a satisface nevoile și așteptările părților interesate.
Există o carte de proiect.
Acest document reflectă de obicei situația din partea organizației client, este emis de un manager extern proiectului și numește un manager de proiect, dându-i autoritatea de a utiliza resursele organizației în proiect.
Carta proiectului trebuie să conțină următoarele informații:
Cerințe pentru proiect și produsul proiectului, într-o formă destul de generală;
Scopul proiectului;
Informații despre managerul de proiect atribuit și nivelul său de autoritate;
Programul de repere;
Relațiile dintre participanții la proiect;
Organizații funcționale și participarea acestora;
Ipoteze despre organizație și mediu, precum și ipoteze externe;
Constrângeri privind organizarea și mediu, precum și restricții externe;
O situație reală de afaceri care servește drept justificare pentru proiect cu date privind randamentul investiției;
Bugetul proiectului.
O carte de proiect crește probabilitatea de finalizare cu succes a proiectului. Documentează intențiile participanților la proiect chiar de la începutul proiectului și poate servi ca punct fundamental de soluționare a disputelor dintre membrii echipei de proiect și organizația performantă.
La întocmirea cartei proiectului, stabilirea unei carte a regulilor de organizare a muncii la proiect a fost realizată folosind documentația, strategiile, obiectivele, metodologia de management al proiectului, funcțiile de rol și regulile de proiect necesare pentru atingerea obiectivelor de afaceri ale proiectului. Au fost identificați responsabilii de management și implementare.
Elaborarea unei carte necesită timp considerabil. La crearea următorului proiect, carta dezvoltată poate fi folosită ca șablon, astfel încât dezvoltarea charterului să dureze mai puțin. Carta de proiect ajută la managementul proiectului, deoarece unele informații sunt necesare pentru a lucra în MS Project.
Planul de management al proiectului
Plan de management al proiectului - un pachet de documente oficiale aprobate care indică modul în care va fi executat proiectul și cum va fi monitorizat și gestionat proiectul. Planul poate fi rezumat sau detaliat și poate include unul sau mai multe planuri de management de sprijin și alte documente de planificare.
Procesul de dezvoltare a unui plan de management de proiect este procesul de documentare a activităților necesare pentru a identifica, pregăti, integra și coordona toate planurile de sprijin. Un plan de management al proiectului scris corect este sursa principală de informații despre modul în care proiectul va fi planificat, măsurat, controlat și închis. Planul de management al proiectului este actualizat și editat ca parte a procesului de management al schimbărilor integrat al proiectului.
1 Sprijinirea planurilor de management de proiect, care includ:
Planul de management al domeniului proiectului;
Planul de management al programului de proiect;
Planul de management al costurilor proiectului;
Planul de management al calitatii proiectului;
plan de management al resurselor umane;
Planul de management al comunicațiilor proiectului;
Planul de management al riscului de proiect;
Plan de management al configurației.
2 Linia de bază a proiectului constând din:
Programul de bază al proiectului;
Plan de bază la cost;
Planul de bază al calității;
Plan de configurare de bază;
Registrul de risc.
3 Rezultatele analizei efectuate de echipa de proiect cu privire la conținutul, sfera și calendarul proiectului.
A fost creat un plan de management al proiectului pentru proiectul de sistem informatic „Contabilitatea serviciilor prestate”. (Anexa B)
Primul paragraf al planului de management al proiectului indică denumirea proiectului. Numele proiectului nu poate fi schimbat pe parcursul ciclului de viață al proiectului.
Al doilea paragraf definește scopurile și obiectivele proiectului. Obiectivele se formează pe baza cerințelor clienților, care constau în automatizarea principalelor procese de afaceri ale întreprinderii. Au fost stabilite obiective, precum atragerea clienților și creșterea profiturilor, îmbunătățirea calității serviciilor oferite.
Al treilea punct definește cerințele pentru soluția de proiectare și rezultatele proiectului. Această secțiune este un element al conținutului de bază al proiectului. Pentru a oferi o legătură între cerințele clienților și rezultatele proiectului, se recomandă utilizarea funcției de calitate.
Al patrulea punct definește limitele proiectului. Acesta este elementul de bază al conținutului proiectului. Sfera proiectului descrie ceea ce este inclus în proiect pentru a se asigura că un participant la proiect nu consideră în mod eronat un produs, serviciu sau rezultat a fi inclus în proiect.
Al cincilea punct definește instrumentele și tehnologiile pentru implementarea managementului de proiect.
Al șaselea punct conține o structură ierarhică a muncii - un model care dezvăluie proiectul nivel cu nivel la un astfel de nivel de detaliu care este necesar pentru planificarea și controlul eficient al proiectului.
Al șaptelea punct descrie nevoia de resurse. Este determinată de intensitatea muncii reflectată în WBS elaborat anterior.
Al optulea punct al Planului arată o mărire plan calendaristic. Acesta este dezvoltat pe baza reperelor, informații din carta proiectului și informații din metodologia de management de proiect utilizată.
Al nouălea punct este factorii critici de succes. Descrie condițiile, a căror furnizare într-un proiect poate fi cheia succesului.
Al zecelea și al unsprezecelea puncte reflectă ipotezele și restricțiile din partea interpretului. În timpul implementării proiectului, restricțiile pot fi modificate.
Al doisprezecelea punct a formulat inițial riscurile. Sunt indicate riscurile deja cunoscute și principalele categorii de riscuri potențiale.
Managementul riscului reprezintă procesele asociate cu identificarea, analiza riscului și luarea deciziilor, care includ maximizarea efectelor pozitive și minimizarea consecințelor negative ale evenimentelor de risc.
Planificarea managementului riscului este procesul de luare a deciziilor cu privire la aplicarea și planificarea managementului riscului pentru un anumit proiect. Acest proces poate include decizii privind organizația, personalul procedurilor de management al riscului de proiect, selectarea metodologiei preferate, sursele de date pentru identificarea riscurilor și intervalul de timp pentru analiza situației.
Planificarea managementului riscului - selectarea abordărilor și planificarea activităților de management al riscului de proiect.
1 Identificarea riscurilor - identificarea riscurilor care ar putea afecta proiectul și documentarea caracteristicilor acestora.
2 Evaluarea calitativă a riscurilor - analiza calitativă a riscurilor și a condițiilor de apariție a acestora pentru a determina impactul acestora asupra succesului proiectului.
3 Evaluare cantitativă - analiza cantitativă probabilitatea de apariție și impactul consecințelor riscului asupra proiectului.
4 Planificarea răspunsului la risc - identificarea procedurilor și metodelor de atenuare a consecințelor negative ale evenimentelor de risc și de a profita de posibilele beneficii.
5 Monitorizarea și controlul riscurilor - monitorizarea riscurilor, identificarea riscurilor rămase, executarea planului de management al riscului de proiect și evaluarea eficacității acțiunilor de diminuare a riscurilor.
A fost depus un plan de management al riscului. (Anexa B)
Planul de management al proiectului pentru sistemul informatic „Contabilitatea serviciilor prestate” a făcut posibilă crearea de documente și descrierea caracteristicilor și limitelor proiectului, a serviciilor asociate, precum și a metodelor de acceptare și a managementului conținutului. Declarația privind domeniul de aplicare a permis evaluarea rezultatului dorit și a acționat ca bază pentru stabilirea unei linii de referință a domeniului de aplicare care să fie urmată pentru întreaga activitate a proiectului.
Elaborarea documentației de bază pentru managementul de proiect al sistemului informațional „Contabilitatea serviciilor furnizate” a făcut posibilă descrierea unei părți din documente pentru implementarea de înaltă calitate și cu succes a managementului de proiect în MS Project. Cheia succesului este înțelegerea necesității acestor documente în procesul de management al proiectului. Rezultatul acestei lucrări a fost elaborarea unei carte de proiect și a unui plan de management al proiectului, care vor fi utilizate în lucrările ulterioare.
Rezultatul primei secțiuni a fost structurarea proiectului IS „Contabilitatea serviciilor furnizate” pentru întreprinderea IP Mikhailov A.O., și au fost elaborate, de asemenea, carta de proiect și planul de management al proiectului, care au fost utilizate în continuarea lucrărilor de management de proiect. Procesul de creare a documentelor de bază este cea mai importantă parte a managementului proiectului, deoarece afectează calitatea, durata și succesul proiectului.
Introducere
Concluzie
Literatură
Introducere
Dezvoltare diverse domenii activitatea umană pe scena modernă imposibil fără o utilizare pe scară largă tehnologie informatică si crearea de sisteme informatice directii diferite. Procesarea informațiilor în astfel de sisteme a devenit un domeniu științific și tehnic independent.
Dupa faza de constructie model informativîncepe proiectarea sistemului. În această etapă se face o alegere solutii tehnologice, pe baza căruia se va construi sistemul informaţional.
Informații în lumea modernă a devenit una dintre cele mai importante resurse, iar sistemele informaționale (SI) au devenit instrumentul necesarîn aproape toate domeniile de activitate.
În condiții reale, proiectarea este o căutare a unei metode care să satisfacă cerințele funcționalității sistemului folosind tehnologiile disponibile, ținând cont de restricțiile date.
Varietatea problemelor rezolvate cu ajutorul sistemelor informaționale a dus la apariția multor tipuri diferite de sisteme, care diferă în principiile de construcție și regulile de prelucrare a informațiilor încorporate în acestea.
Scop munca de testare este să luăm în considerare pas cu pas procesul de creare a sistemelor informaţionale.
Obiectivele acestei lucrări sunt de a afla scopul principal al proiectării, precum și scopul creării sistemelor informaționale.
1. Proiectare sisteme informatice
Proiectarea sistemelor informatice începe întotdeauna cu definirea scopului proiectului. Sarcina principală a oricărui proiect de succes este de a se asigura că în momentul lansării sistemului și pe toată perioada de funcționare a acestuia:
· funcționalitatea necesară a sistemului și gradul de adaptare la condițiile în schimbare ale funcționării acestuia;
· capacitatea necesară a sistemului;
· timpul necesar de răspuns al sistemului la o solicitare;
· funcționarea fără probleme a sistemului în modul cerut, cu alte cuvinte, disponibilitatea și disponibilitatea sistemului de a procesa cererile utilizatorilor;
· ușurință în operare și suport al sistemului;
· securitatea necesară.
Performanța este principalul factor care determină eficacitatea unui sistem. Designul bun este baza unui sistem de înaltă performanță.
Proiectarea sistemelor informatice acoperă trei domenii principale:
· proiectarea obiectelor de date care vor fi implementate în baza de date;
· proiectarea de programe, formulare de ecran, rapoarte care vor asigura executarea interogarilor de date;
· luarea în considerare a mediului sau tehnologiei specifice, și anume: topologia rețelei, configurația hardware, arhitectura utilizată (fișier-server sau client-server), procesare paralelă, prelucrare distribuită a datelor etc.
Conform metodologiei moderne, procesul de creare a unui SI este un proces de construire și transformare secvențială a unui număr de modele coordonate în toate etapele ciclului de viață al SI (LC). La fiecare etapă a ciclului de viață se creează modele specifice acestuia - organizație, cerințe IS, proiect IS, cerințe aplicație etc. Modelele sunt formate din grupuri de lucru ale echipei de proiect, salvate și acumulate în depozitul de proiect. Crearea modelelor, controlul, transformarea și furnizarea acestora pentru uz colectiv se realizează cu ajutorul instrumentelor software speciale - instrumente CASE.
Procesul de creare a IP este împărțit într-un număr de etape (etape), limitate de un anumit interval de timp și care se termină cu lansarea unui anumit produs (modele, produse software, documentație etc.).
De obicei, se disting următoarele etape ale creării unui IS: formarea cerințelor de sistem, proiectare, implementare, testare, punere în funcțiune, operare și întreținere.
Etapa inițială a procesului de creare a SI este modelarea proceselor de afaceri care au loc într-o organizație și realizarea scopurilor și obiectivelor acesteia. Modelul de organizare, descris în termeni de procese de afaceri și funcții de afaceri, ne permite să formulăm cerințele de bază pentru SI. Această poziție fundamentală a metodologiei asigură obiectivitatea în dezvoltarea cerințelor de proiectare a sistemului. Setul de modele pentru descrierea cerințelor SI este apoi transformat într-un sistem de modele care descriu designul conceptual al SI. Modele de arhitectură IS, cerințe software și suport informativ(IO). Apoi se formează arhitectura software și informațională, se identifică bazele de date corporative și aplicațiile individuale, se formează modele de cerințe ale aplicațiilor și se realizează dezvoltarea, testarea și integrarea acestora.
Scopul etapelor inițiale ale creării unui SI, realizate în etapa de analiză a activităților organizației, este de a formula cerințe pentru SI care să reflecte corect și cu acuratețe scopurile și obiectivele organizației client. Pentru a preciza procesul de creare a unui sistem informațional care să răspundă nevoilor organizației, este necesar să se afle și să se articuleze clar care sunt aceste nevoi. Pentru a face acest lucru, este necesar să se determine cerințele clienților pentru SI și să le mapeze într-un limbaj model în cerințele pentru dezvoltarea unui proiect IS, astfel încât să se asigure conformitatea cu scopurile și obiectivele organizației.
Sarcina de formare a cerințelor pentru sistemele informaționale este una dintre cele mai importante, dificil de formalizat și cea mai costisitoare și dificil de corectat în cazul unei erori. Modern unelteŞi produse software vă permit să creați rapid IP în funcție de cerințe gata făcute. Dar adesea aceste sisteme nu mulțumesc clienții și necesită numeroase modificări, ceea ce duce la o creștere bruscă a costului real al IP. Motivul principal pentru această situație este definirea incorectă, inexactă sau incompletă a cerințelor SI în etapa de analiză.
În etapa de proiectare, modelele de date sunt mai întâi formate. Designerii primesc rezultatele analizei ca informații inițiale. Construirea modelelor de date logice și fizice este o parte fundamentală a proiectării bazei de date. Modelul informațional obținut în timpul procesului de analiză este mai întâi convertit într-un model de date logic și apoi într-un model de date fizic.
În paralel cu proiectarea schemei bazei de date, se realizează proiectarea procesului pentru a obține specificațiile (descrierile) tuturor modulelor IS. Ambele procese de proiectare sunt strâns legate deoarece o parte din logica de afaceri este de obicei implementată în baza de date (constrângeri, declanșatoare, proceduri stocate). Scopul principal al proiectării proceselor este de a mapa funcțiile obținute în timpul fazei de analiză în module ale sistemului informațional. La proiectarea modulelor, se determină interfețele programului: aspectul meniului, aspectul ferestrei, tastele rapide și apelurile aferente.
Produsele finale ale fazei de proiectare sunt:
· diagrama bazei de date (pe baza modelului ER dezvoltat în etapa de analiză);
· un set de specificații ale modulelor de sistem (sunt construite pe baza modelelor funcționale).
În plus, în faza de proiectare, se realizează și dezvoltarea arhitecturii IS, inclusiv selecția platformei (platformelor) și a sistemului de operare ( sisteme de operare). Într-un IS eterogen, mai multe computere pot rula pe platforme hardware diferite și pot rula sisteme de operare diferite. Pe lângă alegerea unei platforme, în etapa de proiectare sunt determinate următoarele caracteristici de arhitectură:
· dacă va fi o arhitectură „fișier-server” sau „client-server”;
· va fi o arhitectură pe 3 niveluri cu următoarele straturi: server, middleware (server de aplicații), software client;
· dacă baza de date va fi centralizată sau distribuită. Dacă baza de date este distribuită, atunci ce mecanisme vor fi utilizate pentru a menține consistența și relevanța datelor;
· dacă baza de date va fi omogenă, adică dacă toate serverele de baze de date vor fi produse ale aceluiași producător (de exemplu, toate serverele sunt numai Oracle sau toate serverele sunt numai DB2 UDB). Dacă baza de date nu este omogenă, atunci ce software va fi folosit pentru schimbul de date între SGBD-uri de la diferiți producători (deja existente sau special dezvoltate în cadrul proiectului);
· dacă serverele de baze de date paralele (de exemplu, Oracle Parallel Server, DB2 UDB) vor fi utilizate pentru a obține o performanță adecvată.
Etapa de proiectare se încheie cu elaborarea unui proiect tehnic al IP. În etapa de implementare, se realizează crearea software documentatie operationala.
După finalizarea dezvoltării unui modul individual de sistem, se efectuează un test de sine stătător, care are două obiective principale:
· detectarea defecțiunilor modulelor (defecțiuni grave);
· conformitatea modulului cu specificația (prezența tuturor funcțiilor necesare, absența funcțiilor inutile).
După ce testul autonom trece cu succes, modulul este inclus în partea dezvoltată a sistemului, iar grupul de module generate trece testele de conectare care ar trebui să urmărească influența lor reciprocă.
Apoi, un grup de module este testat pentru fiabilitatea operațională, adică trec, în primul rând, teste care simulează defecțiuni ale sistemului și, în al doilea rând, teste între defecțiuni. Primul grup de teste arată cât de bine se recuperează sistemul de la defecțiuni software și hardware. Al doilea grup de teste determină gradul de stabilitate a sistemului în timpul funcționării normale și vă permite să estimați timpul de funcționare al sistemului. Suita de teste de robustețe ar trebui să includă teste care simulează sarcina maximă a sistemului.
Apoi, întregul set de module este supus unui test de sistem - un test intern de acceptare a produsului, care arată nivelul calității acestuia. Acestea includ teste de funcționalitate și teste de fiabilitate a sistemului.
Ultimul test al sistemului informatic este testarea de acceptare. Un astfel de test presupune arătarea sistemului informațional către client și trebuie să conțină un grup de teste care simulează procese reale de afaceri pentru a arăta conformitatea implementării cu cerințele clientului.
1Articolul este dedicat problemelor construirii unui sistem informatic destinat analizei proiecte de investitii, care se depun la structurile administrative în vederea obținerii sprijin financiar. Structura unui astfel de sistem este un complex de informații format dintr-un modul extern și sistemul principal. Modulul extern este conceput pentru a pregăti informații inițiale despre proiect și se află la întreprinderea participantă la concurs. Sistemul principal realizează analiza proiectelor și se află în organul de conducere administrativă. Structura sistemului principal are ca scop implementarea caracteristicilor analizei proiectelor de investiții. Lucrarea propune, de asemenea, principiile de bază și metodologia de evaluare a proiectelor de investiții. Pentru a evalua proiectul, mulți indicatori inițiali sunt împărțiți în grupuri care caracterizează părțile individuale starea financiara organizatii. Sunt incluși și indicatori suplimentari importanți pentru dezvoltarea socială, culturală și de altă natură a teritoriului. În acest sens, metodologia prezentată permite, în procesul de luare a deciziei privind alocarea creditelor, să se ierarhească proiectele de investiții nu numai după indicatori financiari, dar să țină cont și de prioritățile administrației structura organizatorica, care nu are legătură directă cu situația financiară a organizației participante la concurs.
sistem informatic
structura
metodologie
proiect de investitii
structura administrativă
1. Brykin I.M., Beklemishev A.V. Evaluarea, selecția și analiza proiectelor de investiții. – M.: International Media Group LLC, 2011. – 47 p.
2. Bailey D.W., Sharp W.F., Alexander G.D. Investiții. – M.: INFRA-M, 2012. – 1028 p.
3. Vilensky P.L., Livshits V.N., Smolyak S.A. Evaluarea eficacității proiectelor de investiții. Teorie și practică: manual. Beneficia. – M.: Delo, 2008. – 888 p.
4. Kravchenko T.K., Presnyakov V.F. Tehnologii de infocomunicație pentru managementul întreprinderilor - M.: Școala Superioară de Științe Economice a Universității de Stat, 2003. - 272 p.
5. Lipsits I.V., Kossov V.V. Analiza investitiilor. Pregatirea si evaluarea investitiilor in active reale. – M.: INFRA-M, 2014. – 320 p.
6. Svetlov N.M., Svetlova G.N. Tehnologia de informație management de proiect - M.: INFRA-M, 2012. - 144 p.
7. Shuremov E. Analiza computerizată a afacerilor. // Lumea PC. – 1998. – Nr. 1. – P. 80–83.
Eficiența adopției decizii de management asigurarea de investiții în domeniul întreprinderilor mici în condiții de piață depinde în mare măsură de instrumentele utilizate pentru analiza activităților financiare și economice ale întreprinderilor. Alegerea instrumentelor de analiză este deosebit de importantă pentru structurile organizatorice administrative, atunci când decizia de finanțare a unui proiect trebuie influențată nu numai de indicatorii financiari ai întreprinderii, ci și de prioritățile entității administrative aflate sub controlul acestei structuri organizatorice.
Problemele cărora le este dedicat articolul sunt legate de dezvoltarea sistemelor de analiză a activității întreprinderii organizatii externeși organele de conducere și control. Scopul sistemelor nu este doar de a evalua starea financiară și economică a întreprinderii, ci și posibilitățile și perspectivele de interacțiune sau de lucru în comun cu aceasta. Baza informativă a analizei este formată din indicatori obținuți într-un fel sau altul din contabilitatea standard, raportare statisticăși surse deschise.
Dintre sistemele de analiză financiară existente, se pot evidenția evoluțiile unor companii precum Expert Systems, Galaktika, INEC, Alt-Invest, însă utilizarea lor efectivă fără modificări de către structurile organizatorice administrative este problematică, întrucât aceste sisteme nu rezolvă problemele de evaluare a proiectului. în legătură cu prioritatea parametrilor pentru structura administrativă, dar nu de natură financiară.
Structura sistemului informatic
Necesitatea și relevanța unei analize calitative a fluxului proiectelor de investiții și diferențele existente în interesul unui investitor obișnuit și al unui investitor sub forma unei structuri organizatorice administrative transferă problema alegerii unui instrument în planul dezvoltării acestuia. În acest caz, este recomandabil să atribuiți soluția următoarelor sarcini sistemului dezvoltat:
Analiza situației financiare a întreprinderii, inclusiv a dinamicii;
Analiza părții financiare a planului de afaceri al proiectului;
Analiza impactului unui împrumut asupra stării financiare a întreprinderii;
Luarea în considerare a priorităților orașului în procesul de analiză a proiectului;
Analiza comparativă a proiectelor mai multor întreprinderi;
Prognoza dezvoltării întreprinderii și rambursării împrumutului.
Pe baza caracteristicilor și naturii sarcinilor, a fost elaborată o diagramă bloc a sistemului de analiză, prezentată în figură.
Modulul extern al sistemului este un program autonom care este conceput pentru a pregăti informațiile inițiale necesare pentru luarea unei decizii privind alocarea unui împrumut pentru finanțarea proiectului propus:
Bilanțul contabil și documentele suplimentare din bilanţ;
Partea financiară a planului de afaceri al proiectului;
Informații suplimentare necesare pentru a lua în considerare prioritățile autorității administrative.
Modulul asigură atât introducerea directă a informațiilor folosind tastatura, cât și operarea în modul de import de date din alte sisteme. În același timp, modulul extern monitorizează corectitudinea introducerii informațiilor pentru a elimina erorile neintenționate.
Structura părții principale a sistemului are ca scop implementarea caracteristicilor analizei proiectelor de investiții.
Rolul cheie îl joacă „Modulul de configurare a mediului de lucru și a sistemului expert”. Acest modul produce diverse scenarii analiză, definiție reguli suplimentareși criterii care reflectă interesele orașului și ale administrației, stabilind valori critice ale ratelor financiare.
„Modulul de calcul al indicatorilor financiari” calculează indicatori financiari.
Schema bloc a sistemului informatic pentru analiza proiectelor de investitii
„Modulul „Analiza proiectului și vizualizarea rezultatelor” prezintă rezultatele analizei în moduri analitice, grafice și tabelare.
„Modulul de generare a rapoartelor” este asociat cu standardul softwareși este destinat pregătirii materialelor de raportare.
Sistemul expert este conceput pentru a ajuta la analiza rezultatelor obținute.
Metodologia de analiza a proiectelor de investitii
Metodologia de analiză a proiectelor de investiţii este analiză cuprinzătoare starea financiară a întreprinderii împreună cu evaluarea proiectului de investiții în sine și determinarea ratingului proiectului pentru luarea deciziilor ulterioare privind alocarea împrumuturilor.
Există mulți indicatori inițiali, care sunt împărțiți în grupuri care caracterizează aspecte individuale ale stării financiare a organizației. Aceste grupuri de indicatori sunt concentrate în documente separate, de exemplu un raport contabil etc.
Astfel, există L-grupuri de indicatori inițiali, unde și L-grupuri de indicatori relativi, unde, l este numărul grupului și kl este numărul de serie al indicatorului din grup.
Pe baza indicatorilor primari, se formează grupuri Q de indicatori secundari, unde q = 1, Q, , iar mq este numărul de serie al indicatorului din grupul q. Vom numi acești indicatori coeficienți.
Pe baza indicatorilor, se formează indicatori ai dinamicii modificărilor lor în unități absolute și relative ale formei
unde j - caracterizează numărul de măsurători ale indicatorului sau coeficientului.
Fiecare indicator și coeficient este înregistrat la un număr de momente. Valorile obținute fac posibilă identificarea dinamicii modificărilor indicatorilor și coeficienților în timp:
Atunci I = J + 1.
Au fost stabilite condiții pentru coeficienți. Corespondența coeficienților cu condițiile arată că starea caracteristicilor generale ale stării financiare a întreprinderii, care este determinată de acest coeficient, este normală.
În procesul de analiză a unui proiect antreprenorial sunt rezolvate cel puțin trei sarcini fundamentale:
a) evaluarea posibilității de rambursare a împrumutului de către întreprinderea în cauză și, prin urmare, decizia de a-l include în lista celor potențial apți pentru creditare;
b) evaluarea posibilității de creditare pe baza priorităților administrației;
Aceste probleme sunt rezolvate în cadrul analizei pe mai multe niveluri a coeficienților și indicatorilor.
Analiza se realizează prin calcularea coeficienților și evaluarea condițiilor. Coeficienții sunt împărțiți în grupuri în subgrupe de mai mult și mai puțin importante. Primul nivel de analiză este asociat cu evaluarea îndeplinirii condițiilor pentru subgrupele selectate de coeficienți și rezolvă în principal problema
a) La al doilea și la nivelul următor sunt analizați alți coeficienți și indicatori, precum și dinamica modificărilor acestora.
Rezultatele analizei sunt prezentate sub formă de documente separate, care oferă caracteristici ale diferitelor aspecte ale activităților întreprinderii și ale proiectului propus.
În următoarea etapă, se formează o evaluare a proiectului în funcție de item
b) Pentru a ține cont de interesele administrației, se introduce un grup suplimentar de indicatori (fh) și condiții (χh), unde h = 1,H. Acești indicatori pot fi calculați sau raportați de întreprindere. Daca societatea nu indeplineste criteriile, este exclusa din grupul potentialilor creditori.
a) se formează opțiuni pentru determinarea ratingului proiectelor de investiții, axate pe evaluarea într-un anumit domeniu, de exemplu în domeniul producției produse alimentare etc. Principalele diferențe dintre opțiuni, sau să le numim scenarii, sunt următoarele:
În grupele de indicatori și coeficienți relativi se identifică elemente individuale care vor fi luate în considerare la determinarea ratingului proiectului într-un scenariu dat, i.e.
unde ζ este numărul scenariului;
Pentru indicatorii și coeficienții selectați se stabilesc ponderi care caracterizează influența acestui indicator asupra ratingului din această grupă, i.e. respectiv
De asemenea, se determină ponderi pentru grupurile de indicatori și coeficienți care participă la rating, i.e. , unde d ζ este numărul grupului și D ζ este numărul total de grupuri care participă la evaluare;
Greutățile sunt mai mici de 1, suma greutăților fiecărui set pe întregul eșantion este egală cu 1.
b) se formează o versiune a celei mai bune întreprinderi pentru grupul de proiecte evaluat. Cea mai bună versiune de întreprindere este un set de indicatori identificați anterior cu cele mai bune valori de pe întregul set, adică. valorile acestor indicatori pot aparține diferitelor întreprinderi. Această versiune nu este asociată cu obiectul real și este folosită în scopuri de evaluare. Toate relațiile ulterioare pentru evaluarea ratingului sunt date numai pentru coeficienți. Formule similare sunt construite pentru parametri și fh.
Astfel, se formează un set de indicatori, unde , dacă cu cât este mai mare, cu atât mai bine și altfel. Aici s este numărul întreprinderii de pe listă și este valoarea coeficientului pentru a-cea întreprindere.
unde, dacă creşterea coeficientului caracterizează o îmbunătăţire a stării financiare a întreprinderii şi
e) cu cât R ζ s este mai mare, cu atât este mai mare ratingul întreprinderii a º-a în scenariul de evaluare ζ-lea.
Normalizând (R ζ s) cu , puteți aranja întreprinderile în ordinea crescătoare sau descrescătoare a ratingului lor. Evaluarea după indicatori și fh pot fi efectuate separat.
Concluzie
Metodologia prezentată permite, în procesul de luare a deciziei privind alocarea creditelor, să ierarhizeze proiectele de investiții nu numai în funcție de indicatorii financiari, ci și să țină cont de prioritățile structurii organizatorice administrative care nu au legătură directă cu cea financiară. starea organizației care participă la concurs.
Astfel, sistemul informatic, atunci când va fi implementat, va fi un instrument puternic care include mecanisme eficiente de sprijinire a procesului decizional în domeniu. activitati de investitiiși a avut ca scop furnizarea de analiză atât a stării financiare a întreprinderilor, cât și a proiectelor de investiții depuse la concurs.
Link bibliografic
Klevtsov S.I., Klevtsova A.B. MODEL DE SISTEM INFORMATIC PENTRU ANALIZA PROIECTELOR DE INVESTITII PENTRU STRUCTURI ADMINISTRATIVE // Cercetare de bază. – 2016. – Nr. 12-1. – P. 58-61;URL: http://fundamental-research.ru/ru/article/view?id=41046 (data acces: 26/04/2019). Vă aducem în atenție reviste apărute la editura „Academia de Științe ale Naturii”
Proiectare sisteme informatice
Partea 1. Etapele dezvoltării proiectului: strategie și analiză
Introducere „Cascada” - diagrama de dezvoltare a proiectului Strategie Analiză Diagramele ER Arcuri Normalizare Diagrame de flux de date Câteva principii pentru verificarea calității și completității unui model de informații Calitatea entității Calitatea atributului Calitatea comunicarii Funcțiile sistemului Clarificarea strategiei
Introducere
Proiectarea sistemelor informatice începe întotdeauna cu definirea scopului proiectului. Sarcina principală a oricărui proiect de succes este să se asigure că în momentul lansării sistemului și pe tot parcursul funcționării acestuia este posibil să se asigure:
funcționalitatea necesară a sistemului și gradul de adaptare la condițiile în schimbare ale funcționării acestuia;
capacitatea necesară a sistemului;
timpul necesar de răspuns al sistemului la o solicitare;
funcționarea fără probleme a sistemului în modul cerut, cu alte cuvinte, disponibilitatea și disponibilitatea sistemului de a procesa cererile utilizatorilor;
ușurință în operare și suport al sistemului;
securitatea necesară.
Performanța este principalul factor care determină eficacitatea unui sistem. Designul bun este baza unui sistem de înaltă performanță.
Proiectarea sistemelor informatice acoperă trei domenii principale:
proiectarea obiectelor de date care vor fi implementate în baza de date;
proiectarea de programe, formulare de ecran, rapoarte care vor asigura executarea interogărilor de date;
ținând cont de un anumit mediu sau tehnologie și anume: topologia rețelei, configurația hardware, arhitectura utilizată (fișier-server sau client-server), procesare paralelă, prelucrare distribuită a datelor etc.
În condiții reale, proiectarea este o căutare a unei metode care să satisfacă cerințele funcționalității sistemului folosind tehnologiile disponibile, ținând cont de restricțiile date.
Orice proiect este supus unui număr de cerințe absolute, de exemplu, timpul maxim de dezvoltare a proiectului, maxim investiții în numerar la proiect etc. Una dintre dificultățile proiectării este că nu este o sarcină atât de structurată precum analiza cerințelor proiectului sau implementarea unei anumite soluții de proiectare.
Se crede că un sistem complex nu poate fi descris în principiu. Acest lucru, în special, se referă la sistemele de management al întreprinderii. Unul dintre argumentele principale este o modificare a condițiilor de funcționare a sistemului, de exemplu, o modificare directivă a anumitor fluxuri de informații de către noua conducere. Un alt argument este volumul specificațiilor tehnice, care pentru un proiect mare poate fi de sute de pagini, în timp ce proiect tehnic poate contine erori. Se pune întrebarea: poate că este mai bine să nu faceți deloc sondaje și să nu faceți niciun proiect tehnic, ci să scrieți sistemul „de la zero” în speranța că va exista o coincidență miraculoasă a dorințelor clientului cu ceea ce au scris programatorii, și, de asemenea, că toate acestea vor funcționa stabil?
Dacă te uiți la el, este într-adevăr dezvoltarea sistemului atât de imprevizibilă și este cu adevărat imposibil să obții informații despre el? Probabil, prin seminarii se poate obține o idee a sistemului în ansamblu și a modalităților de dezvoltare ale acestuia propuse (de conducere). După aceasta, împărțiți sistemul complex în componente mai simple, simplificați conexiunile dintre componente, asigurați independența componentelor și descrieți interfețele dintre ele (astfel încât o schimbare într-o componentă să nu implice automat o schimbare semnificativă a unei alte componente) , precum și posibilitatea extinderii sistemului și „stubs” pentru irealizabile într-o versiune sau alta a sistemului de funcții. Pe baza unor astfel de considerații elementare, descrierea a ceea ce se presupune a fi implementat în sistemul informațional nu mai pare atât de nerealistă. Puteți adera la abordările clasice ale dezvoltării sistemelor informaționale, dintre care una este schema „cascada” ( orez. 1) - descris mai jos. Vor fi, de asemenea, discutate pe scurt și alte abordări ale dezvoltării sistemelor informaționale, unde utilizarea elementelor descrise în diagrama „cascada” este, de asemenea, acceptabilă. Care dintre abordările descrise mai jos să urmați (și dacă are sens să vii cu propria ta abordare) este într-o oarecare măsură o chestiune de gust și circumstanțe.
Orez. 1. Diagrama cascadei
Ciclul de viață al software-ului este modelul creării și utilizării acestuia. Modelul reflectă diferitele sale stări, începând din momentul în care apare necesitatea acestui software și terminând cu momentul în care este complet neutilizat pentru toți utilizatorii. Sunt cunoscute următoarele modele de ciclu de viață:
Model în cascadă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrărilor în etapa anterioară.
Model treptat cu control intermediar. Dezvoltarea software-ului se realizează în iterații cu cicluri feedback
între etape. Ajustările între etape fac posibilă reducerea complexității procesului de dezvoltare în comparație cu modelul în cascadă; Durata de viață a fiecărei etape se extinde pe întreaga perioadă de dezvoltare. se plateste la etapele initiale de dezvoltare - dezvoltarea strategiei, analiza si proiectarea, unde fezabilitatea anumitor solutii tehnice este testata si justificata prin realizarea de prototipuri (layout). Fiecare tură a spiralei implică crearea unei anumite versiuni a produsului sau a oricărei componente ale acestuia, în timp ce caracteristicile și obiectivele proiectului sunt clarificate, calitatea acestuia este determinată și este planificată munca următoarei ture a spiralei.
Mai jos vom analiza câteva scheme de dezvoltare a proiectelor.
Până la început
„Cascada” - diagrama de dezvoltare a proiectului
Foarte des, designul este descris ca o etapă separată a dezvoltării proiectului între analiză și dezvoltare. Cu toate acestea, în realitate, nu există o împărțire clară a etapelor de dezvoltare a proiectului - proiectarea, de regulă, nu are un început și un sfârșit clar definite și continuă adesea în etapele de testare și implementare. Vorbind despre etapa de testare, trebuie remarcat, de asemenea, că atât etapa de analiză, cât și etapa de proiectare conțin elemente ale muncii testatorilor, de exemplu, pentru a obține o justificare experimentală pentru alegerea unei anumite soluții, precum și pentru a evalua criteriile de calitate ale sistemului rezultat. În etapa operațională, este oportun să vorbim despre întreținerea sistemului.
Mai jos ne vom uita la fiecare dintre etape, concentrându-ne mai detaliat pe etapa de proiectare.
Până la început
Strategie
Definirea unei strategii presupune examinarea sistemului. Obiectivul principal al sondajului este de a evalua sfera reală a proiectului, scopurile și obiectivele acestuia, precum și obținerea de definiții la nivel înalt ale entităților și funcțiilor.
În această etapă, sunt atrași analiști de afaceri cu înaltă calificare care au acces constant la managementul companiei; Această etapă implică o interacțiune strânsă cu principalii utilizatori ai sistemului și experți în afaceri. Sarcina principală a interacțiunii este de a obține informații cât mai complete despre sistem (o înțelegere completă și neechivocă a cerințelor clientului) și de a transfera aceste informații într-o formă oficială analiștilor de sistem pentru etapa de analiză ulterioară. De obicei, informațiile despre sistem pot fi obținute prin conversații sau seminarii cu management, experți și utilizatori. În acest fel, se determină esența afacerii, perspectivele de dezvoltare a acesteia și cerințele pentru sistem.
Odată ce faza principală de cercetare a sistemului este finalizată, tehnicienii formulează abordări tehnice plauzibile și estimează costurile pentru hardware, software achiziționat și dezvoltarea de noi software (care este ceea ce presupune de fapt proiectul).
Rezultatul etapei de definire a strategiei este un document care precizează clar ce va primi clientul dacă este de acord să finanțeze proiectul; când va primi produsul finit (program de lucru); cât va costa (pentru proiecte mari, ar trebui întocmit un grafic de finanțare la diferite etape de lucru). Documentul trebuie să reflecte nu numai costurile, ci și beneficiile, de exemplu, timpul de amortizare al proiectului, efectul economic așteptat (dacă poate fi estimat).
Documentul trebuie să descrie:
restricții, riscuri, factori critici care afectează succesul proiectului, de exemplu, timpul de răspuns al sistemului la o solicitare este o limitare dată și nu un factor de dorit;
set de condiții în care se așteaptă să funcționeze viitorul sistem: arhitectura sistemului, hardware și resurse software furnizate sistemului, conditii externe funcționarea acestuia, componența oamenilor și a lucrărilor care asigură funcționarea neîntreruptă a sistemului;
termenele de finalizare a etapelor individuale, forma de livrare a lucrărilor, resursele implicate în procesul de dezvoltare a proiectului, măsurile de protecție a informațiilor;
descrierea funcțiilor îndeplinite de sistem;
cerințele viitoare pentru sistem dacă dezvoltă, de exemplu, capacitatea utilizatorului de a lucra cu sistemul utilizând Internetul etc.;
entități necesare pentru îndeplinirea funcțiilor sistemului;
interfețe și distribuție de funcții între o persoană și sistem;
cerințele pentru software și componentele informatice ale software-ului, cerințele pentru un SGBD (dacă proiectul se presupune a fi implementat pentru mai multe SGBD, atunci cerințele pentru fiecare dintre ele sau cerințe generale la un SGBD abstract și o listă de cele recomandate pentru a acestui proiect SGBD care îndeplinesc condițiile specificate);
care nu vor fi implementate în cadrul proiectului.
Finalizat pe în această etapă Lucrarea ne permite să răspundem la întrebarea dacă acest proiect merită continuat și ce cerințe ale clienților pot fi satisfăcute în anumite condiții. Se poate dovedi că proiectul nu are sens să continue, de exemplu, din cauza faptului că anumite cerințe nu pot fi satisfăcute din anumite motive obiective. Dacă se ia decizia de a continua proiectul, atunci pentru următoarea etapă de analiză există deja o idee despre domeniul de aplicare al proiectului și estimările de costuri.
Trebuie remarcat faptul că în etapa de alegere a unei strategii, și în etapa de analiză și în timpul proiectării, indiferent de metoda utilizată în dezvoltarea proiectului, funcțiile planificate ale sistemului trebuie întotdeauna clasificate după gradul de importanță. Un format posibil pentru prezentarea unei astfel de clasificări, MoSCoW, este propus în Clegg, Dai și Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.
Această abreviere înseamnă: Trebuie să aibă - functii necesare; Ar trebui să aibă - funcții de dorit; Ar putea avea - posibile funcții; Nu va avea - lipsesc funcții.
Implementarea funcțiilor categoriilor a doua și a treia este limitată de timp și cadre financiare: dezvoltăm ceea ce este necesar, precum și numărul maxim posibil de funcții ale categoriilor a doua și a treia în ordinea priorităților.
Până la început
Analiză
Etapa de analiză presupune un studiu detaliat al proceselor de business (funcții definite în etapa de selecție a strategiei) și al informațiilor necesare implementării acestora (entități, atribute și conexiuni (relații) acestora). În această etapă, se creează un model de informații, iar în următoarea etapă de proiectare, se creează un model de date.
Toate informațiile despre sistem colectate în etapa de definire a strategiei sunt formalizate și clarificate în etapa de analiză. O atenție deosebită trebuie acordată completității informațiilor transmise, analizând informațiile pentru a se asigura că nu există contradicții, precum și căutării informațiilor neutilizate sau duplicate. De regulă, clientul nu formulează imediat cerințe pentru sistem în ansamblu, ci formulează cerințe pentru componentele sale individuale. Acordați atenție consistenței acestor componente.
Analiștii colectează și înregistrează informații în două forme interdependente:
funcții - informații despre evenimente și procese care au loc în afaceri;
entități - informații despre lucruri care sunt importante pentru organizație și despre care se știe ceva.
Două rezultate clasice ale analizei sunt:
ierarhia funcțiilor, care descompune procesul de prelucrare în părțile sale componente (ce se face și în ce constă);
Modelul de relații de intrare (model ER), care descrie entitățile, atributele și conexiunile (relațiile) dintre ele.
Aceste rezultate sunt necesare, dar nu suficiente. Rezultatele suficiente includ diagrame de flux de date și cicluri de viață entitati. Destul de des, erorile de analiză apar atunci când se încearcă să arate ciclul de viață al unei entități într-o diagramă ER.
Mai jos ne uităm la cele trei metodologii de analiză structurală cele mai frecvent utilizate:
Diagramele Entitate-Relație (ERD), care servesc la oficializarea informațiilor despre entități și relațiile acestora;
Diagrame de flux de date (DFD), care servesc la oficializarea reprezentării funcțiilor sistemului;
Diagramele de tranziție de stat (STD), care reflectă comportamentul dependent de timp al sistemului; Diagramele ciclului de viață al entităților aparțin acestei clase de diagrame.
Până la început
Diagramele ER
diagrame ER ( orez. 2) sunt utilizate pentru ingineria datelor și reprezintă un mod standard de definire a datelor și a relațiilor dintre acestea. Astfel, se realizează detalierea depozitelor de date. O diagramă ER conține informații despre entitățile sistemului și metodele de interacțiune a acestora, include identificarea obiectelor importante pentru domeniul subiectului (entități), proprietățile acestor obiecte (atribute) și relațiile lor cu alte obiecte (legături). În multe cazuri, modelul informațional este foarte complex și conține multe obiecte.
Orez. 2. Exemplu de diagramă ER
O entitate este reprezentată ca un dreptunghi cu numele entității în partea de sus (de exemplu, TITLURI). Dreptunghiul poate enumera atributele unei entități; Atributele diagramei ER introduse cu caractere aldine sunt cheie (de exemplu, Title Identity este un atribut cheie al entității TITLES, alte atribute nu sunt cheie).
O relație este reprezentată printr-o linie între două entități (linii albastre în figură).
O singură linie pe dreapta ( orez. 3) înseamnă „unul”, „picior de pasăre”, în stânga - „mulți”, iar relația se citește pe linie, cum ar fi „unu la mulți”. O bară verticală înseamnă „obligatoriu”, un cerc înseamnă „opțional”, de exemplu, pentru fiecare publicație în TITLE trebuie să fie indicat editorul din PUBLISHERS, iar un editor din PUBLISHERS poate publica mai multe titluri de publicații în TITLE. De remarcat faptul că conexiunile sunt întotdeauna comentate (inscripția de pe linia care prezintă legătura).
Orez. 3. Element diagramă ER
Să dăm și un exemplu ( orez. 4) imagini ale relației reflexive „angajat”, în care un angajat poate gestiona mai mulți subordonați și așa mai departe în ierarhia posturilor.
Orez. 4. Diagrama ER a atitudinii reflexive
Trebuie menționat că o astfel de relație este întotdeauna opțională, altfel va fi o ierarhie infinită.
Atributele entității pot fi cheie - sunt evidențiate cu caractere aldine; obligatorii - sunt precedate de un semn „*”, adică valoarea lor este întotdeauna cunoscută, opțional (opțional) - sunt precedate de un O, adică valorile acestui atribut pot fi absente sau incerte la unele momente.
Până la început
Arcuri
Dacă o entitate are un set de relații care se exclud reciproc cu alte entități, atunci se spune că astfel de relații sunt într-un arc. De exemplu, un cont bancar poate fi emis fie pentru o persoană juridică, fie pentru individual. Un fragment dintr-o diagramă ER pentru acest tip de relație este prezentat în orez. 5.
Orez. 5. Arc
În acest caz, atributul PROPRIETAR al entității CONT are o semnificație specială pentru această entitate - entitatea este împărțită în tipuri în funcție de categorii: „pentru o persoană fizică” și „pentru persoană juridică". Entitățile rezultate se numesc subtipuri, iar entitatea originală devine un supertip. Pentru a înțelege dacă este necesar sau nu un supertip, este necesar să se stabilească câte proprietăți identice au diferite subtipuri. Trebuie remarcat faptul că abuzul de subtipuri și supertipurile este o greșeală destul de comună. Ele sunt descrise după cum se arată în orez. 6.
Orez. 6. Subtipuri (dreapta) și supertip (stânga)
Până la început
Normalizare
Pentru a preveni anomaliile în timpul procesării datelor, se utilizează normalizarea. Principiile normalizării pentru obiectele modelului de informații sunt exact aceleași ca și pentru modelele de date.
Tipuri acceptabile de conexiuni. O privire mai atentă asupra relației unu-la-unu ( orez. 7) se dovedește aproape întotdeauna că A și B sunt de fapt subseturi diferite ale aceluiași lucru sau puncte de vedere diferite asupra lui, având doar nume diferite și relații și atribute descrise diferit.
Orez. 7. Conexiuni unu-la-unu
Relațiile multi-la-unu sunt prezentate în orez. 8.
Orez. 8. Relații multi-la-unu
I este un construct destul de puternic care implică faptul că o apariție a entității B nu poate fi creată fără a crea simultan cel puțin o apariție asociată a entității A.
II este cea mai comună formă de comunicare. Se presupune că fiecare apariție a entității A poate exista numai în contextul uneia (și numai una) apariție a entității B. La rândul lor, aparițiile lui B pot exista fie cu sau fără apariția lui A.
III - rar folosit. Atât A cât și B pot exista fără nicio legătură între ele.
Relațiile de la multe la multe sunt prezentate în orez. 9.
Orez. 9. Relații multi-la-mulți
I - această construcție apare adesea la începutul etapei de analiză și înseamnă o relație - fie neînțeleasă pe deplin și care necesită o rezoluție suplimentară, fie reflectând o simplă relație colectivă - o listă bidirecțională.
II - rar folosit. Astfel de conexiuni sunt întotdeauna supuse unor detalii suplimentare.
Să luăm acum în considerare conexiunile recursive ( orez. 10).
Orez. 10. Conexiuni recursive
I - rar, dar apare. Reflectă conexiuni de tip alternativ.
II - destul de des folosit pentru a descrie ierarhii cu orice număr de niveluri.
III - apare în stadiile incipiente. Adesea reflectă structura „listei de materiale” (imbricarea reciprocă a componentelor). Exemplu: Fiecare COMPONENT poate fi format dintr-una sau mai multe (alte) COMPONENTE și fiecare COMPONENT poate fi utilizat într-una sau mai multe (alte) COMPONENTE.
Tipuri de conexiune nevalide. Tipurile de relații nevalide includ următoarele: relație obligatorie multi-la-mulți ( orez. 11) și o serie de conexiuni recursive ( orez. 12).
Orez. 11. Relații multi-la-mulți nevalide
Orez. 12. Relații recursive nevalide
O relație obligatorie multi-la-mulți este imposibilă în principiu. O astfel de relație ar însemna că nicio apariție a lui A nu ar putea exista fără B și invers. De fapt, fiecare astfel de construcție se dovedește întotdeauna a fi eronată.
Până la început
Diagrame de flux de date
DFD logic ( orez. 13) arată sursele și receptorii (destinatarii) de date externe sistemului, identifică funcții logice (procese) și grupuri de elemente de date care conectează o funcție la alta (fluxuri) și, de asemenea, identifică depozitele de date (unități) care sunt accesate. Structurile fluxului de date și definițiile componentelor lor sunt stocate și analizate într-un dicționar de date. Fiecare funcție logică (proces) poate fi detaliată folosind un DFD de nivel inferior; când detaliile suplimentare nu mai sunt utile, treceți la exprimarea logicii funcției folosind o specificație de proces (mini-specificație). Conținutul fiecărui depozit este, de asemenea, stocat într-un dicționar de date, iar modelul de date al depozitului este dezvăluit folosind diagrame ER.
Orez. 13. Exemplu DFD
În special, DFD nu arată procesele care controlează fluxul real de date și nu face diferența între căile valide și nevalide. DFD-urile conțin o mulțime de informații utile și, în plus:
vă permit să vă imaginați sistemul din punct de vedere al datelor;
ilustrează mecanismele externe de livrare a datelor care vor necesita interfețe speciale;
vă permit să prezentați atât procesele de sistem automate, cât și manuale;
efectuează partiţionarea centrată pe date a întregului sistem.
Fluxurile de date sunt folosite pentru a modela transferul de informații (sau chiar componente fizice) de la o parte a unui sistem la alta. Fluxurile în diagrame sunt reprezentate prin săgeți numite; Uneori, informațiile se pot mișca într-o singură direcție, pot fi procesate și se pot întoarce la sursă. Această situație poate fi modelată fie prin două fluxuri diferite, fie printr-unul bidirecțional.
Un proces convertește un flux de date de intrare într-un flux de ieșire conform acțiunii specificate de numele procesului. Fiecare proces trebuie să aibă un număr unic pentru referință în diagramă. Acest număr poate fi utilizat împreună cu numărul diagramei pentru a oferi un index unic de proces pentru întregul model.
Stocarea datelor vă permite să definiți datele într-un număr de zone care vor fi stocate în memorie între procese. De fapt, depozitul reprezintă „feții” de fluxuri de date de-a lungul timpului. Informațiile pe care le conține pot fi folosite în orice moment după ce au fost determinate, iar datele pot fi selectate în orice ordine. Numele depozitului trebuie să-și identifice conținutul. În cazul în care un flux de date intră (iese) dintr-un depozit și structura acestuia se potrivește cu structura depozitului, acesta trebuie să aibă același nume, care nu trebuie să fie reflectat în diagramă.
O entitate externă (terminator) reprezintă o entitate în afara contextului sistemului care este sursa sau receptorul datelor de sistem. Numele ei trebuie să conțină un substantiv, cum ar fi „Client”. Obiectele reprezentate de astfel de noduri nu sunt de așteptat să participe la nicio prelucrare.
Până la început
Diagrame de tranziție de stări STD
Ciclul de viață al unei entități aparține clasei de diagrame STD ( orez. 14). Această diagramă arată schimbarea stării unui obiect în timp. De exemplu, luați în considerare starea unui produs într-un depozit: un produs poate fi comandat de la un furnizor, primit la depozit, stocat într-un depozit, supus controlului calității, vândut, respins sau returnat furnizorului. Săgețile de pe diagramă indică schimbări acceptabile de stare.
Fig. 14. Exemplu DFD
Există mai multe opțiuni diferite pentru a reprezenta astfel de diagrame; figura arată doar una dintre ele.
Până la început
Câteva principii pentru verificarea calității și completitudinii unui model informațional (sursa - Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)
Dacă doriți să creați un model de înaltă calitate, va trebui să apelați la ajutorul analiștilor care cunosc fluent tehnologia CASE. Cu toate acestea, acest lucru nu înseamnă că numai analiștii ar trebui să fie implicați în construirea și monitorizarea modelului informațional. Ajutorul colegilor poate fi, de asemenea, de mare ajutor. Implicați-i în verificarea scopului enunțat și într-un studiu detaliat al modelului construit, atât din punct de vedere al logicii, cât și din punctul de vedere al luării în considerare a unor aspecte ale domeniului de studiu. Majoritatea oamenilor consideră că este mai ușor să găsească greșeli în munca altcuiva.
Trimiteți în mod regulat modelul de informații sau părți ale acestuia despre care aveți îngrijorări, pentru aprobarea utilizatorului. Acordați o atenție deosebită excepțiilor și limitărilor.
Până la început
Calitatea entității
Principala garanție a calității unei entități este răspunsul la întrebarea dacă obiectul este într-adevăr o entitate, adică un obiect sau un fenomen important, despre care informații ar trebui stocate în baza de date.
Lista întrebărilor de verificare pentru entitate:
Numele entității reflectă esența acestui obiect?
Există vreo suprapunere cu alte entități?
Există cel puțin două atribute?
Nu există mai mult de opt atribute în total?
Există sinonime/omonime pentru această entitate?
Este entitatea pe deplin definită?
Există un identificator unic?
Există cel puțin o conexiune?
Există cel puțin o funcție pentru crearea, căutarea, editarea, ștergerea, arhivarea și utilizarea unei valori de entitate?
Există un istoric al schimbărilor?
Există respectarea principiilor de normalizare a datelor?
Există aceeași entitate într-un alt sistem de aplicații, poate sub un alt nume?
Este esența prea generală?
Este suficient nivelul de generalizare încorporat în el?
Lista întrebărilor de screening pentru subtip:
Există vreo suprapunere cu alte subtipuri?
Subtipul are atribute și/sau relații?
Toți au propriii identificatori unici sau moștenesc unul pentru toți din supertip?
Există un set cuprinzător de subtipuri?
Nu este un subtip un exemplu de apariție a unei entități?
Cunoașteți atribute, relații sau condiții care disting acest subtip de altele?
Până la început
Calitatea atributului
Este necesar să aflăm dacă acestea sunt cu adevărat atribute, adică dacă descriu această entitate într-un fel sau altul.
Lista întrebărilor de verificare a atributelor:
Numele atributului este un substantiv singular care reflectă esența proprietății notate de atribut?
Numele atributului nu include numele entității (nu ar trebui)?
Un atribut are o singură valoare la un moment dat?
Există valori (sau grupuri) duplicate?
Sunt descrise formatul, lungimea, valorile acceptabile, algoritmul de achiziție etc.?
Acest atribut ar putea fi o entitate lipsă care ar fi utilă pentru un alt sistem de aplicații (existent sau propus)?
Ar putea fi o conexiune ratată?
Este nevoie de un istoric al schimbărilor?
Înțelesul său depinde doar de această entitate?
Dacă valoarea atributului este necesară, este întotdeauna cunoscută?
Este necesar să se creeze un domeniu pentru aceasta și atribute similare?
Valoarea sa depinde doar de o parte a identificatorului unic?
Valoarea acestuia depinde de valorile unor atribute care nu sunt incluse în identificatorul unic?
