Ce poți găti din calmar: rapid și gustos

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 va vizita șantierul și, dacă este necesar, îl va livra în forță. centru 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. Reparațiile se efectuează cu echipamente speciale, respectând regulile de siguranță. Compania vinde și dispozitive periferice pentru telefoane, tablete și computere. Compania achizitioneaza echipament folosit si defect.

Compania angajeaza specialisti calificati cu multi ani de experienta. 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 implementarea 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 care leagă viitorul proiect cu activitatea în desfășurare a organizației.

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 drept 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 în mod corespunzător 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 furnizate”. (Anexa B)

Primul paragraf al planului de management al proiectului indică denumirea proiectului. Numele proiectului nu poate fi schimbat pe tot parcursul ciclu de viață proiect.

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 profitului, î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 până la nivelul de detaliu 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 cu privire la organizație, personal proceduri de management al riscului de proiect, selectarea metodologiei preferate, surse de date pentru identificarea riscului, interval 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 Evaluare calitativă riscuri - o analiză 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ă a probabilității de apariție și a impactului 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 aferente, precum și a metodelor de acceptare și de gestionare a conținutului. Declarația privind domeniul de aplicare a permis evaluarea rezultatului dorit și a acționat ca bază pentru crearea unei linii de referință a domeniului de aplicare care să fie urmată pentru toată activitatea de proiect.

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 generare a documentelor de bază este partea cea mai importantă managementul proiectului, deoarece afectează calitatea, durata și succesul proiectului.

Metode de proiectare a unui sistem informatic si analiza functionala a activitatilor unei organizatii

INTRODUCERE

Capitolul 1. Analiza metodelor structurale functionale de proiectare a unui sistem informatic

1 Metodologia SADT

2. Metodologia IDEF0

3. Metodologia IDEF1X

4. Metodologia DFD

Capitolul 3. Partea practică

CONCLUZIE

Lista surselor utilizate

INTRODUCERE

Pe toată perioada de utilizare a computerelor și sisteme informatice Există tendința de a crea sisteme de control extrem de fiabile axate pe obținerea și utilizarea resurselor informaționale. Această tendință a fost exprimată în procesul puternic de creare a diferitelor tipuri de sisteme, ca complexe de tehnologie a informației construite în obiecte unice. ÎN în ultima vreme tehnologia de informație au devenit parte integrantă a vieții noastre. Sistemele informaționale legate de furnizarea și prelucrarea informațiilor pentru toate nivelurile de management al facilităților devin deosebit de importante în viața publică. În momentul de față este imposibil să ne imaginăm vreo organizație care să nu folosească tehnologie informatică. Acest lucru se datorează și faptului că agențiile guvernamentale solicită rapoarte obligatorii formular electronic Prin urmare, este nevoie de informații sistematice.

O etapă importantă în dezvoltarea unui sistem informațional este studiul aprofundat al acestui domeniu. Identificarea entităților organizației, ce funcții îndeplinesc, ce atribute sunt incluse în entitate. Determinarea dependențelor dintre entități. Toate acestea creează o reprezentare vizuală a problemei studiate.

Scopul lucrării este de a implementa sistemul informațional al unei organizații folosind exemplul unui dealer personalizat de vânzări. Etapa inițială a creării unui sistem este studiul, analiza și modelarea activităților punct de vânzare pentru o eventuală îmbunătăţire şi optimizare a metodelor de lucru.

Capitolul 1. Analiza metodelor structurale functionale de proiectare a unui sistem informatic

1 Metodologia SADT

Metodologia SADT - metodologie<#"justify">SADT a apărut la sfârșitul anilor 1960 ca parte a revoluției provocate de programarea structurată. Când majoritatea specialiștilor se chinuiau să creeze software, puțini au încercat să rezolve problema mai complexă a creării de sisteme la scară largă care implică atât oameni, cât și mașini și software, similare sistemelor utilizate în comunicațiile telefonice, industrie, guvern și controlul armelor.

Astfel, dezvoltatorii au decis să oficializeze procesul de creare a sistemului, împărțindu-l în următoarele faze:

1) analiza<#"justify">Metodologia SADT se bazează pe două principii principale.

Blocuri SA, pe baza cărora se creează un sistem modular ierarhic cu mai multe niveluri, fiecare nivel reprezintă un sistem complet (bloc), susținut și controlat de sistemul (blocul) situat deasupra acestuia.

Descompunere - utilizarea acestui concept vă permite să împărțiți fiecare bloc, înțeles ca un singur întreg, în componentele sale, descrise într-o diagramă mai detaliată.

Procesul de descompunere se realizează până la atingerea nivelului de detaliu dorit din descriere. Diagrama este limitată la 3-6 blocuri, astfel încât detalierea să fie efectuată treptat. În loc de un model greoi, sunt folosite mai multe modele mici interconectate, ale căror semnificații se completează reciproc, făcând clară structurarea unui obiect complex.

În mod obișnuit, metodologia SADT este utilizată în etapele incipiente ale ciclului de viață al unui sistem informațional. Un model este o descriere textuală și grafică exactă, completă și adecvată a unui sistem care are un scop specific, realizată sub forma unui sistem organizat ierarhic. set de diagrame create pe baza unei reprezentări standard de date. Aceasta este o descriere a unui sistem care are un singur subiect, un scop și un singur punct de vedere folosind metodologia SADT. Un astfel de model este o colecție de diagrame ordonate ierarhic și interconectate, organizate într-o structură arborescentă, diagrama de sus fiind cea mai generală, iar diagramele de jos cele mai detaliate.

Modelele SADT folosesc atât limbaje naturale, cât și limbaje grafice. Pentru a transmite informații despre un anumit sistem, sursa limbajului natural este oamenii care descriu sistemul, iar sursa limbajului grafic este metodologia SADT în sine.

Limbajul grafic SADT asigură structura și transmiterea precisă a modelului semantic al limbajului natural, organizează limbajul natural într-un mod foarte specific și lipsit de ambiguitate, datorită căruia permite descrierea unor sisteme care până de curând nu puteau fi reprezentate adecvat.

Din perspectiva SADT, un model se poate concentra fie pe funcțiile unui sistem, fie pe obiectele acestuia. Astfel de modele orientate pe funcție sunt de obicei numite modele funcționale, iar sistemele orientate pe obiecte sunt numite modele de date.

Un model funcțional reprezintă, cu gradul de detaliu necesar, un sistem de funcții, care la rândul lor reflectă relațiile dintre ele prin obiecte de sistem. Modelele de date sunt duale cu cele funcționale și reprezintă o descriere detaliată a obiectelor sistemului legate de funcțiile sistemului. Metodologia completă SADT sprijină crearea mai multor modele pentru a descrie mai precis un sistem complex.

1.2 Metodologia IDEF0

IDEF0 - metodologie<#"justify">Metodologia IDEF0 poate fi utilizată pentru a modela o gamă largă de sisteme și pentru a defini cerințe și funcții, apoi pentru a proiecta un sistem care să satisfacă acele cerințe și să implementeze acele funcții. Pentru sistemele existente, SADT poate fi utilizat pentru a analiza funcțiile îndeplinite de sistem și pentru a indica mecanismele prin care acestea sunt realizate.

În ciuda faptului că în prezent apar zeci de metodologii noi pentru modelarea activității întreprinderii și a opiniilor asupra arhitecturii acesteia, IDEF0 rămâne relevant pentru sarcinile de îmbunătățire a întreprinderilor și organizațiilor.

Avantajele metodologiei IDEF0:

1)istorie îndelungată a utilizării sale pentru a rezolva diverse probleme de guvernare și întreprinderi comerciale;

2)continuă să fie utilizat și recomandat ca standard pentru descrierea activităților unei organizații și întreprinderi;

)informatizarea globală a societății nu face decât să crească cererea pentru oportunitățile oferite de IDEF0;

)concurența și lupta pentru calitatea produselor sporesc nevoile întreprinderilor moderne pentru tehnologia informației, punând astfel sarcini suplimentare pentru analiștii și proiectanții de sistem;

)consecventă şi imbunatatire continua activități, îmbunătățirea, reorganizarea și reinginerirea întreprinderii etc., propune o serie de cerințe de sistem pentru luarea în considerare a mai multor factori: oameni, echipamente, informații, management al întreprinderii și sisteme de management procesele de productie;

)modelarea cu succes a diferitelor aspecte ale activităților unei întreprinderi ne permite să identificăm și să colectăm în mod oficial cerințele pentru sistemul proiectat și apoi să dezvoltăm un sistem care să îndeplinească aceste cerințe;

)pentru un sistem existent, metodologia poate fi utilizată pentru a analiza funcțiile sistemului executat, precum și pentru a documenta mecanismele (mijloacele) prin care acestea sunt realizate;

)Notația IDEF0 vă permite să modelați funcțiile sistemului (lucrări, acțiuni, operațiuni, procese), conexiuni funcționale și date (informații și obiecte), care asigură integrarea complexelor sistemului. Modelele dezvoltate reprezintă o descriere completă și interconectată a activităților unei întreprinderi sau a funcționării unui sistem;

)influența mediului extern al unei întreprinderi sau unui sistem poate face și obiectul modelării și cercetării;

)utilizarea unui singur limbaj pentru a reprezenta activitățile întreprinderii și mediul extern ne permite să obținem modele de proces care reflectă punctul de vedere al consumatorului;

)procedurile existente pentru discutarea modelelor IDEF0 permit analistului și clientului munca de proiectare(consumator industrial) pentru a obține consens și înțelegere.

1.3 Metodologia IDEF1X

Metoda IDEF1, dezvoltată de T. Ramey, se bazează tot pe abordarea lui P. Chen și vă permite să construiți un model de date echivalent cu un model relațional în a treia formă normală.

În prezent, pe baza îmbunătățirii metodologiei IDEF1, a fost creat noua versiune- Metodologia IDEF1X. Este conceput pentru a fi ușor de învățat și automatizat. Diagramele IDEF1X sunt utilizate de o serie de instrumente CASE comune (în special, ERwin, Design/IDEF).

O entitate din metodologia IDEF1X este independentă de identificare sau pur și simplu independentă dacă fiecare instanță a entității poate fi identificată în mod unic fără a defini relațiile sale cu alte entități. Se spune că o entitate este dependentă de identificator sau pur și simplu dependentă dacă identificarea unică a unei instanțe a entității depinde de relația acesteia cu o altă entitate.

Fiecare entitate primește un nume și un număr unic, separate printr-o bară oblică „/” și plasate deasupra blocului.

Relația poate fi definită în continuare prin specificarea gradului sau cardinalității (numărul de instanțe ale unei entități copil care poate exista pentru fiecare instanță a unei entități părinte).

Următoarele puteri de legătură pot fi exprimate în IDEF1X:

) fiecare instanță de entitate părinte poate avea zero, una sau mai multe instanțe de entitate copil asociate cu ea;

) fiecare instanță a unei entități-mamă trebuie să aibă cel puțin o instanță a unei entități fii asociate acesteia;

) fiecare instanță a unei entități-mamă trebuie să aibă cel mult o instanță a unei entități fii asociată acesteia;

) fiecare instanță a unei entități-mamă este asociată cu un număr fix de instanțe ale unei entități copil.

Dacă o instanță a unei entități copil este identificată în mod unic prin relația sa cu entitatea părinte, atunci relația se numește identificatoare, în caz contrar se numește neidentificare.

O relație este reprezentată de o linie trasată între o entitate părinte și o entitate copil, cu un punct la sfârșitul liniei la entitatea copil.

Relația de identificare dintre o entitate părinte și o entitate copil este reprezentată ca o linie continuă. O entitate copil într-o relație de identitate este o entitate dependentă de identificator. Entitatea-mamă într-o relație de identificare poate fi fie o entitate independentă, fie o entitate dependentă de identificator (acest lucru este determinat de relațiile sale cu alte entități).

1.4 Metodologia DFD

DFD este o abreviere general acceptată pentru engleză.<#"justify">Notația DFD este un instrument convenabil pentru generarea unei diagrame de context, adică o diagramă care arată AIS dezvoltat în comunicare cu mediul extern. Aceasta este o diagramă nivel superiorîn ierarhia diagramei DFD. Scopul său este de a limita domeniul de aplicare al sistemului, de a determina unde se termină sistemul în curs de dezvoltare și unde începe mediul.

Standardul pentru descrierea proceselor de afaceri DFD - Diagrama fluxului de date este tradus ca o diagramă a fluxului de date și este folosit pentru a descrie procesele de nivel superior și pentru a descrie fluxurile de date care există de fapt într-o organizație.

Modelele create de fluxuri de date organizaționale pot fi utilizate pentru a rezolva probleme precum:

1)identificarea depozitelor de date existente ( documente text, fisiere, sistem de management al bazei de date - DBMS);

2)identificarea și analizarea datelor necesare îndeplinirii fiecărei funcții de proces;

)pregătirea pentru crearea unui model al structurii de date a organizației, așa-numitul model ERD (IDEF1X);

)identificarea proceselor de afaceri principale și auxiliare ale organizației.

Diagramele fluxului de date arată cum fiecare proces își transformă intrările în ieșiri și dezvăluie relațiile dintre aceste procese. DFD reprezintă sistemul modelat ca o rețea de activități conexe.

Când construiți o diagramă DFD a unui proces de afaceri, trebuie să vă amintiți că această diagramă arată fluxul de materiale și fluxuri de informații și în niciun caz nu vorbește despre succesiunea de timp a muncii, deși în cele mai multe cazuri succesiunea de timp a muncii coincide cu direcția. a mișcării fluxurilor în procesul de afaceri.

Capitolul 2. Analiza functionala a activitatilor organizatiei

Obiectul analizei este un dealer de vânzări de catalog. Pentru a construi un sistem informatic optim pentru activitatea sa, este necesar să se țină cont de gama de reglementări din domeniul comerțului și al protecției consumatorilor.

Pe lângă procesul de vânzare în sine, activitățile dealer-ului includ și:

)colaborarea cu furnizorii;

)asigurarea securității resurselor Internet;

)service întreținere a echipamentelor vândute.

Să luăm în considerare diagrama A0 prezentată în Figura 1. Activitatea principală este „vânzarea mărfurilor”. Date de intrare: informații despre clienți, informații despre produs. Informația de control este legea privind drepturile consumatorilor și carta magazinului, mecanismul de control este personalul de service. Datele de ieșire sunt prezentate sub formă de documentație însoțitoare.

Orez. 1. Diagrama A0

Acum să descompunăm diagrama rezultată.

Activitatea „vânzarea unui produs” poate fi reprezentată ca o succesiune a următoarelor acțiuni (Fig. 2):

1)pre-antrenament;

2)înregistrare;

)primirea;

)serviciul poștal

Orez. 2. Descompunerea diagramei A0

Să efectuăm o descompunere ulterioară. Activitatea de „pregătire” include următoarele acțiuni (Fig. 3):

1)consultare;

2)selecția produselor;

)verificarea disponibilitatii stocului.

Orez. 3. Descompunerea activităților de „pre-pregătire”.

Să realizăm „proiectarea” de descompunere. Activitatea de „proiectare” include următoarele acțiuni (Fig. 4):

1)plată;

2)cerere depozit;

)pregătirea documentației.

Orez. 4. Descompunerea activității de „proiectare”.

„Recepția” include funcții (Figura 5):

1)transfer de bunuri;

2)înregistrarea unei garanții;

)eliberarea documentației de însoțire.

Orez. 5. Descompunerea activității de „recepție”.

„Serviciul post” include funcții (Fig. 6):

)verificarea defecțiunilor;

2)efectuarea de reparații;

)verificarea garantiei;

)livrarea mărfurilor.

Orez. 6. Descompunerea activităților post-servicii.

După construirea modelului informațional, vom forma un arbore de obiective (Fig. 7):

Orez. 7. Arborele obiectivelor sistemului informatic.

Capitolul 3. Partea practică

Dezvoltarea unui model logic și fizic începe cu desfășurarea unui proces de modelare a sistemului pentru domeniul de studiu utilizând lanțul de instrumente CA Erwin Process Modeler.

Procesul de construire a unui model de informare constă din următorii pași:

1)definiția entității;

2)definirea atributelor entității;

)setarea cheilor primare și alternative;

)definirea dependențelor între entități;

)aducerea modelului la nivelul cerut de formă normală;

)trecerea la descrierea fizică a modelului: atribuirea corespondențelor nume entitate - nume tabel, atribut entitate - atribut tabel; stabilirea declanșatorilor, procedurilor și restricțiilor;

)generarea bazei de date.

CA Erwin Process Modeler creează o reprezentare vizuală (model de date) pentru problema rezolvată. Această vizualizare poate fi utilizată pentru analiză detaliată, rafinare și diseminare ca parte a documentației necesare în ciclul de dezvoltare. Cu toate acestea, CA Erwin Process Modeler este departe de a fi doar un instrument de desen. CA Erwin Process Modeler creează automat baza de date (tabele, indecși, proceduri stocate, declanșatoare de integritate referențială și alte obiecte necesare pentru gestionarea datelor).

Componentele principale ale unei diagrame CA Erwin Process Modeler sunt entitățile, atributele și relațiile. Fiecare entitate este un set de obiecte individuale similare numite instanțe. Fiecare copie este individuală și trebuie să fie diferită de toate celelalte copii. Construirea unui model de date implică definirea de entități și atribute.

O entitate poate fi definită ca un obiect, eveniment sau concept despre care trebuie stocată informația. Entitățile trebuie să aibă un nume cu un sens semantic clar, să fie numite un substantiv singular, să nu aibă nume „tehnice” și să fie suficient de importante pentru a fi modelate. Numirea entității la singular face ca modelul să fie mai ușor de citit mai târziu. De fapt, numele unei entități este dat de numele instanței sale.

O entitate trebuie să aibă un anumit set de atribute. Atributele sunt fapte care servesc la identificarea, clasificarea, reprezentarea numerică sau descrierea în alt mod a stării unei instanțe de entitate. Atributele formează grupuri logice care descriu fiecare instanță a unei entități. O instanță specifică a unui atribut este o valoare.

O relație este o relație logică între entități. Fiecare relație ar trebui să fie numită verb sau expresie verbală. Numele relației exprimă o constrângere sau o regulă de afaceri și face diagrama mai ușor de citit.

În modelul de dealer de vânzări de produse, am identificat următoarele entități și atribute:

1)„Informații despre produs” cu atribute: cod produs, cost, denumire, caracteristici, perioada de garanție, echipament, disponibilitate în depozit.

2)„Factură” cu atribute: numărul facturii, codul produsului, data, numele casieriei, furnizorul, cantitatea de mărfuri.

)„Informații despre cumpărător” cu atribute: codul cumpărătorului, numele complet al cumpărătorului, datele pașaportului, adresa.

)„Card de garanție” cu atribute: numărul de cupon, codul cumpărătorului, numele vânzătorului, numele complet al cumpărătorului, producătorul produsului, perioada de garanție.

)„Chitanță” cu atribute: numărul bonului, codul produsului, cantitatea produsului, cantitatea, data.

Figura 8 - Model logic al unui dealer IP pentru vânzarea mărfurilor.

CONCLUZIE

În acest proiect de curs, a fost implementat un sistem de organizare folosind exemplul unui dealer care vinde bunuri folosind instrumentele CA Erwin Process Modeler și AllFusion Process Modeler. Sistemul dezvoltat permite funcționarea completă atât a unui dealer individual, cât și a unei întregi rețele. Dezvoltarea sistemului informaţional a fost împărţită în pașii următori:

1)studiul aprofundat al domeniului subiectului,

)crearea unui model logic și fizic al sistemului informațional.

Scopul sistemului informatic este de a căuta și analiza informații, al căror utilizator final este o persoană. Baza algoritmilor unui astfel de sistem sunt programele logice de procesare a datelor. Traficul total al sistemelor de acest fel este în general mic, dar este destul de stabil în ceea ce privește valorile datelor, deci dezvoltarea lor este firească.

Scopul principal al unui sistem informatic este de a crea o infrastructură modernă pentru gestionarea unei întreprinderi, organizații sau instituții.

Astfel, se poate concluziona că dezvoltarea sistemului informațional al unei organizații este necesară pentru o eventuală îmbunătățire și optimizare a metodelor de lucru.

LISTA SURSELOR UTILIZATE

1.Balabanov I.T. Modelare modernă./ I.T. Balabanov - Sankt Petersburg: Peter, 2002. - 120 p.: ill. - (serie Bazele ).

2.Venchkovsky L.B. Dezvoltarea de produse software complexe. - versiune electronică.

3.Vendrov A.M. Proiectare software pentru sisteme informatice economice: Tutorial. - M.: Finanţe şi Statistică, versiunea electronică 2002

4.Revista Opensys nr. 11, 2008 - „Managementul organizației”

5.Pakhchanyan A. Revizuirea sistemelor informatice // Director serviciul de informare. - 2001.

6.CA Erwin Process Modeler [Resursa electronică]:[fișa informativă]. - Erwin, 2011. - Mod de acces:

7.CA Erwin Process Modeler [Resursa electronică]:[fișa informativă]. - Sisteme informaţionale, 2011. - Mod de acces: http:// www.v8.1c.ru

8.ITru [Resursa electronica]:[fisa informativa]. - IP Modeling, 2011. - Mod de acces: http:// www.it.ru /

9.INTERFATA [Resursa electronica]:[fisa informativa]. - Modelarea afacerilor și arhitectura sistemului informațional, 2011. - Mod de acces: http://www.interface.ru /

Optima WorkFlow [Resursă electronică]: [fișă informativă]. - OPTIMA, 2011. - Mod de acces:

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 obiectivele 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;

necesar debitului sisteme;

timpul necesar de răspuns al sistemului la o solicitare;

funcționarea fără probleme a sistemului în modul necesar, cu alte cuvinte, disponibilitatea și disponibilitatea sistemului de a procesa cererile utilizatorilor;

ușurința î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, investiția monetară maximă în 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 proiectul tehnic poate conține erori. Se pune întrebarea: poate este mai bine să nu faceți deloc examinări și să nu faceți nimic proiect tehnic, dar scrieți un sistem „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 „stub-urilor” 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ă veniți cu propria abordare) este într-o oarecare măsură o chestiune de gust și circumstanțe.

Orez. 1. Diagrama cascada

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 bucle de 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.

Model în spirală. O atenție deosebită este acordată etapelor inițiale de dezvoltare - elaborarea strategiei, analiză și proiectare, unde fezabilitatea anumitor soluții tehnice este testată și justificată prin realizarea de prototipuri (layout-uri). 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

Strategie

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. 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. despre sistem (înțelegerea completă și neechivocă a cerințelor clienților) și transferați 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 ar trebui 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;

ansamblu de condiții în care se intenționează să funcționeze viitorul sistem: arhitectura sistemului, resursele hardware și software furnizate sistemului, condițiile externe de funcționare a 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 SGBD-uri recomandate pentru acest proiect care îndeplinesc condițiile specificate);

care nu vor fi implementate în cadrul proiectului.

Lucrările finalizate în această etapă ne permit 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ă - funcții necesare; Ar trebui să aibă - funcții de dorit; Ar putea avea - funcții posibile; 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.

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 este creat 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 diagramele fluxului de date și diagramele ciclului de viață al entităților. 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.

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 lista 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.

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)

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ă.

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;

ilustra mecanisme externe transmiterea 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ă identifice conținutul acestuia. Î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.

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

Sunt mai multe diverse opțiuni imagini cu diagrame similare, doar una dintre ele este prezentată în figură.

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.

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?

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.?

Ar putea acest atribut să fie 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?

Orice întreprindere, firmă, organizație are propria sa structură organizatorică. Această structură este multidimensională și poate fi împărțită în mai multe substructuri interconectate și interdependente, care pot fi considerate structuri independente: structura de management al producției, structura personalului, marketing, financiar și economic, structuri informaționale.

Toate sunt în strânsă interacțiune și combinația lor este cea care va crea structura organizatoricaîntreprinderilor. Unul dintre cele mai importante locuri Sistemul informaţional ocupă această structură. În principiu, orice sistem de management poate fi reprezentat ca un sistem informaţional cu diverse fluxuri informaţionale sub formă de documente, comenzi, solicitări adresate în cadrul organizaţiei, emanate din sau care intră din mediul extern.

În ultimele decenii, volumul informației în societate în general și a informațiilor utilizate în întreprindere în special a crescut brusc. Acest lucru se datorează ritmului tot mai mare de dezvoltare a științei și tehnologiei, apariției noilor tehnologii și înlocuirii lor rapide. Pe piețele de materii prime și produse s-au dezvoltat condiții care necesită o monitorizare constantă a stării pieței, a schimbărilor acesteia, a tendințelor în dezvoltarea acesteia este necesar să se poată anticipa dezvoltare ulterioară situație și fiți pregătiți să schimbați strategia, stilul de operare și tehnologia de producție pentru a vă adapta rapid la noile condiții externe. Toate acestea conduc la faptul că conditii moderne Managerii de afaceri trebuie să se ocupe de atât de multe informații, acestea se schimbă atât de repede, încât adesea devine pur și simplu imposibil de procesat manual. În plus, în întreprinderile mari cu cifră de afaceri mare de produse și număr de angajați, este necesar să se țină seama și să controleze un volum mare de resurse financiare, de producție, de personal, de achiziții și de vânzări, informatii de marketing. În acest sens, este nevoie de a crea sisteme automatizate colectarea, prelucrarea, stocarea informațiilor. Acestea ar trebui să faciliteze procesul de lucru cu informațiile care circulă în întreprindere.

Aspect echipamente informatice vă permite să creați sisteme similare. Pe intreprinderi moderne Aproape toate lucrările cu informații sunt automate, există programe speciale care vă permit să efectuați contabilitate, fluxul de documente; cercetare de marketing, face prognoze și planificare strategică, precum și multe altele. Dar, pe lângă automatizare, problema construcției competente a structurii sistemului informațional, optimizarea fluxurilor de informații, filtrarea informațiilor inutile, simplificarea căutării și obținerea informațiilor necesare va rămâne relevantă. Prezența unui sistem informatic automatizat care funcționează bine la o întreprindere simplifică foarte mult procesul de management al întreprinderii. Vă permite să colectați, să sortați, să procesați în timp util. informatiile necesare si ia decizia corecta. Uneori, o decizie luată la momentul nepotrivit, din cauza lipsei sau a primirii intempestive a informațiilor, poate duce la moartea unei întreprinderi. Prin urmare, este necesar să se acorde o mare atenție creării și menținerii funcționării eficiente a sistemului informațional al întreprinderii.

Principalele concepte utilizate în teoria sistemelor informaționale și a sistemelor informatice automatizate sunt informații, sistem, sistem de regăsire a informațiilor, sistem de control automatizat, locul de munca. Informații - din lat. Clarificarea informațională, prezentarea inițial a informațiilor transmise de oameni oral, în scris sau în alte moduri încă de la mijlocul secolului XX, un concept științific general care include schimbul de informații între oameni, o persoană și un automat, un automat și un automat. Un sistem este un grup de multe elemente ordonate în mod specific și interconectate care au unitate stabilă, integritate internă și autonomie de existență în mediu extern. Sistemul de regăsire a informațiilor IPS este un ansamblu de instrumente pentru stocarea, căutarea și emiterea la cerere a informațiilor necesare pentru plasarea informațiilor în IPS se realizează manual sau folosind un computer conform anumitor reguli și în conformitate cu limbajul informațional acceptat; Sistem de control automat ACS, un set de metode matematice, mijloace tehnice Calculatoare, comunicații și complexe organizaționale care asigură managementul rațional al unui obiect de proces complex în conformitate cu un scop dat. Stație de lucru automatizată a unui operator, dispecer, proiectant, tehnolog, echipată cu tehnologie computerizată pentru automatizarea procesului de prelucrare și afișarea informațiilor necesare pentru finalizarea unei sarcini de producție. Recent, a crescut rolul informației utilizate în întreprinderi și în diverse organizații. Putem spune că este una dintre resursele utilizate în activitățile întreprinderii. Cu toate acestea, resursele informaționale diferă în proprietățile lor de resurse în conceptul tradițional de material, energie și tehnologic.

Diverși cercetători au sugerat diverse moduri clasificarea suportului informaţional. Deci, din punctul de vedere al interacțiunii întreprinderii unei organizații cu mediul înconjurător, toate informațiile, în principal documentare, sunt de obicei împărțite în intrare și ieșire. În funcție de perioada de păstrare, se face distincția între permanent, semipermanent, uneori actualizat și variabil, în schimbare regulată. Informațiile sunt, de asemenea, împărțite în niveluri de management: fabrică, în fabrică, atelier și intra-magazin. Natura activității este de design și tehnologic. contabilitate, contabilitate si raportare, planificare, marketing, personal, productie. În sistemele automate, suportul informațional este împărțit în computer, în memoria computerului și non-mașină. Aceste clasificări în diferite combinații sunt utilizate la indexarea diferitelor documente de scrisori, ordine, instrucțiuni și alte documente utilizate de întreprinderi și organizații în activitati practice. Istoria dezvoltării. În istoria creării sistemelor informatice automatizate, două direcții s-au dezvoltat relativ independent: 1. dezvoltarea sistemelor informatice automatizate AIS ca sisteme de control automate pentru sistemele de control automatizate 2. dezvoltarea sistemelor automatizate informatii stiintifice si tehnice ASNT. Lucrările la crearea lor au început aproape simultan în anii 60.

Prima direcție - dezvoltarea AIS și ACS - a fost inițiată de progresul științific și tehnologic și de problemele care au apărut în legătură cu aceasta. management organizatoric creșterea cantității de informații, dificultăți în procesarea manuală. Practică străină a urmat calea dezvoltării procedurilor software individuale, de exemplu, pentru contabilitate, contabilitatea activelor materiale, iar activitatea principală a fost efectuată în direcția cercetării și îmbunătățirii capacităților tehnologiei informatice, dezvoltarea instrumentelor care asigură cea mai rațională organizare a informațiilor. matrice, o interfață ușor de utilizat și creșterea memoriei computerului. La noi, problema furnizării de informații angajaților din conducere a fost imediat pusă sistematic. A fost elaborată o clasificare a sistemelor de control automatizate, care a evidențiat în primul rând sistemele de control automatizate diferite niveluri sisteme de management - la nivelul intreprinderilor si organizatiilor, industriei, republican si sistem automatizat regional si national.

La fel și la nivelul întreprinderilor, și mai ales cele create în anii 70. asociații științifice și de producție OBNL, în structura sistemelor automatizate de control sau sistemelor integrate de control automatizat al asociațiilor, s-au distins niveluri de strat - sisteme de control automatizate ale asociației, sisteme de control automatizat al întreprinderilor și organizațiilor institutelor de cercetare științifică, birouri de proiectare incluse în asociații științifice și de producție, sisteme automate de control al producției, complexe de ateliere, sisteme automate de control al atelierelor și secțiilor. La nivelul atelierelor și secțiilor, sistemele de control automatizate au fost inițial împărțite în sisteme de control automatizate procese tehnologice, ACS tehnic și pregătire tehnologică producție, sistem de control automat pentru organizarea producției. Lucrările la crearea sistemelor naționale centralizate de control automatizat și ASTI au fost suspendate din cauza transformărilor din 19-91. Cu toate acestea, în timpul tranziției la o economie de piață, la un stat de drept, rolul unui alt tip important de informații crește - normativ-juridic și normativ-metodologic, reglementând activitățile întreprinderilor, oferindu-le în același timp o mai mare independență și reducând. documentația organizatorică și administrativă a comenzilor și instrucțiunilor curente care auditează metodele de comandă și management administrativ. În viitor, pe măsură ce întreprinderile și sistemele lor automatizate de control se dezvoltă, mai ales în condițiile acordării unei mai mari independențe producției și atelierelor și redistribuirii functii de managementîntre administrația întreprinderii și directorii de producție și ateliere, a devenit, de asemenea, mai convenabil să se prezinte structura sistemului de control automatizat ca pe mai multe niveluri, stratificată. Împărțirea sistemului de control automatizat în părți funcționale și suport, iar acestea din urmă în suport informațional, tehnic, organizatoric, software și alte tipuri de suport, a făcut posibilă atragerea de specialiști în aceste domenii pentru a clarifica tipurile relevante de suport. Această abordare a organizării dezvoltării sistemelor de control automate a ajutat să facă față complexității sistemului și să accelereze dezvoltarea sistemelor de control automatizate prin muncă paralelă de analiză și selecție a structurii. specii individuale dispoziţie. Cu toate acestea, dacă dezvoltați proiecte separate, atunci după dezvoltare există destul de multe sarcină dificilă coordonarea acestora, interconectarea structurilor acceptate ale acestor tipuri de suport, criterii luate în considerare pe parcursul dezvoltării lor etc. Prin urmare, la o anumită etapă a dezvoltării lucrărilor de creare a unui sistem de control automat, a fost chiar formulat ca principale tipuri de suport un principiu special al unității suportului informațional, hardware și software. În prezent, există un număr mare de produse software gata făcute. Prin urmare, atunci când se creează un sistem automatizat la o întreprindere, nu este nevoie să se angajeze în dezvoltarea de software independentă. Evaluarea eficacității resurselor informaționale. Având în vedere varietatea tipurilor și formelor de resurse informaționale, problema evaluării acestora pare aproape insolubilă.

Într-adevăr, cum să compar diverse tipuri informații Ce informații trebuie furnizate managerilor, managerilor, oamenilor de știință, designerilor, tehnologilor și altor angajați ai întreprinderii Cum să determinați care stocare și regăsire a informațiilor este mai important să automatizăm mai întâi Cum să determinați în general eficiența utilizării resurselor informaționale.

Creșterea volumelor de producție, frecvența actualizării gamei de produse și tehnologii și complexitatea gestionării regiunilor, sistemelor de producție și sferelor neindustriale în dezvoltare rapidă au condus la creșterea și complexitatea fluxurilor de informații. În aceste condiții, a devenit necesară evaluarea costurilor resurselor informaționale și determinarea contribuției acestora la eficiența sistemelor de producție, educaționale și de altă natură.

Diverse științe ale informației au încercat să o măsoare. Pentru a evalua satisfacerea nevoilor de informare în teoria informației științifice și tehnice au fost introduse măsuri de relevanță și persistență. Relevanța se referă la corespondența ieșirii cu cererea; relevanța se referă la corespondența ieșirii cu nevoile utilizatorului. În practică, atunci când se evaluează semnificația matricelor de informații ale sistemelor de control automatizate, uneori sunt utilizate estimări indirecte, cum ar fi frecvența de acces la matrice, numărul de documente pregătite pe baza acesteia, numărul de departamente deservite, volumul matricelor. , etc.caracteristici cantitative indirecte. Pentru a rezolva anumite probleme, metodele luate în considerare de evaluare a informațiilor dau uneori rezultate destul de satisfăcătoare. Totuși, în cazul evaluării întregului set de resurse informaționale, este de dorit să se poată compara diferite tipuri de informații, să se obțină, dacă nu o singură măsură, atunci estimări cel puțin comparabile ale utilității diferitelor resurse de informații pentru o producție sau alt sistem, pentru a aloca mai rațional fonduri pentru sprijinul informațional. Este aproape imposibil să se utilizeze o măsură tradițională a costurilor pentru a evalua eficiența resurselor informaționale. Poți, desigur, să apreciezi eficienta economicași perioada de rambursare pentru automatizarea stocării și regăsării anumitor tipuri de suport pentru informații. Cu toate acestea, pe baza acestor evaluări, nu se poate aprecia importanța informațiilor pentru îmbunătățirea producției sau a sistemului de management organizațional sau utilitatea informațiilor pentru cercetarea stiintifica, soluție de proiectare. Pornind de la ideea de bază a utilizării conceptelor de sistem la organizarea unor examinări complexe, ne putem pune sarcina de a evalua eficacitatea resurselor informaționale, ca sarcină de evaluare a gradului de influență a acestora asupra implementării circuitelor de sistem.

Cu această formulare a problemei trebuie rezolvate două probleme: 1 să se formeze o structură de obiective pentru principalele direcții de dezvoltare a sistemului care determină activitățile acestuia în perioada corespunzătoare de existență 2 să se aleagă o abordare a evaluării gradului; de influenţă a informaţiilor asupra atingerii scopurilor. Pentru a asigura o analiză completă a activităților unei întreprinderi, o organizație atunci când formează o structură de obiective ar trebui să utilizeze metode de structurare a scopurilor și funcțiilor, a căror alegere este determinată de un concept dezvoltat anterior al dezvoltării sale. Pentru a evalua gradul de conformitate cu obiectivul, puteți utiliza o măsură probabilistică, adică evaluați probabilitatea ca o anumită resursă de informații să fie utilizată pentru a atinge un subscop. Astfel de evaluări pot fi obținute ca aprecieri ale importanței relative, a contribuției relative a unei resurse informaționale la implementarea subscopului corespunzător, dar acest lucru ridică problema că aceeași informație poate influența mai mult de un subscop. Puteți utiliza o măsură informațională a gradului de influență a unei resurse asupra implementării sub-obiectivelor, care vă permite să luați în considerare nu numai probabilitatea de a atinge subobiectivul p, ci și probabilitatea q ca această informație să fie utilizată de către factor de decizie la implementarea subscopului. Evaluarea potențialului de informare H este mai convenabilă decât evaluările de importanță relativă pot fi rezumate, dar și q pot fi luate în considerare mai bine de către lucrătorii din management; În condiții reale, se pot folosi metode mai complexe.

Introducere

Concluzie

Literatură

Introducere

Dezvoltarea diferitelor domenii activitatea umanăîn stadiul actual este imposibil fără utilizarea pe scară largă a tehnologiei informatice și crearea de sisteme informaționale de diferite direcții. Procesarea informațiilor în astfel de sisteme a devenit un domeniu științific și tehnic independent.

După etapa de construire a unui model de informații, î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 instrument 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 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 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 de aplicație etc. Modelele sunt formate din grupurile de lucru ale echipei de proiect, salvate și acumulate în depozitul de proiect. Crearea modelelor, controlul, transformarea și furnizarea acestora pentru utilizare 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.

Scop etapele inițiale crearea SI, realizată în etapa de analiză a activităților organizației, este formarea de cerințe pentru SI care reflectă 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 mapam î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 a forma cerințe pentru sistemele informaționale este una dintre cele mai importante, greu de formalizat și cea mai costisitoare și dificil de corectat în cazul unei erori. Instrumente moderne și produse software vă permit să creați rapid IP în funcție de cerințe gata făcute. Dar adesea aceste sisteme nu satisfac 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 proiectarea procesului constă în maparea funcţiilor obţinute în etapa 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 este creat un software pentru documentația operațională.

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.