Introducere

Teza examinată a fost scrisă pe baza fabricii Donetsk OJSC Donetsk pentru magazinul Cleonelly.

Una dintre activitățile principale ale fabricii Donetsk OJSC produce o gamă largă de articole de îmbrăcăminte, în principal halate de baie, cearșafuri și prosoape. În plus, compania produce fire de bumbac vopsite pentru țesut și tricotat.

Dezvoltarea tehnologiilor informaționale automatizate merge mână în mână cu apariția de noi tipuri de mijloace tehnice pentru procesarea și transmiterea informațiilor, îmbunătățirea formelor organizatorice de utilizare a computerelor, saturarea infrastructurii cu noi mijloace de comunicare. Dezvoltarea relațiilor de piață a condus la apariția de noi tipuri de activitate antreprenorială și, în primul rând, la crearea firmelor angajate în afaceri informaționale, dezvoltarea tehnologiilor informaționale, îmbunătățirea acestora, răspândirea componentelor tehnologiilor informaționale automatizate, în special a produselor software care automatizează informațiile și procesele de calcul. Acestea includ, de asemenea, echipamente de calcul, facilități de comunicații, echipamente de birou și tipuri specifice de servicii - informații, servicii tehnice și de consultanță, instruire etc. Acest lucru a contribuit la diseminarea rapidă și utilizarea eficientă a tehnologiilor informaționale în procesele de management și producție, aproape la utilizarea lor omniprezentă și o mare diversitate.

Întreprinderile angajate în proiectarea și dezvoltarea de dispozitive pentru diverse scopuri utilizează în prezent pe scară largă diverse mijloace atât de proiectare asistată de computer - CAD (CAD), cât și de monitorizare a proceselor de producție - ACS (SCADA / DCS). Cu toate acestea, pentru dispozitivele cu design propriu, este necesar să ne dezvoltăm propriile mijloace de monitorizare a performanțelor acestora și de analiză a calității produsului.

Procesul tehnologic de contabilitate a produselor dintr-un depozit dintr-un magazin Cleanelly include etapa de păstrare a evidenței produselor vândute.

Scopul acestui proiect de diplomă este implementarea unei stații de lucru automatizate (AWP) care permite contabilitatea produselor într-un depozit de magazin.

Pentru a atinge obiectivul de mai sus, este necesar să rezolvați următoarele sarcini:

¾ analiza procesele de afaceri ale magazinului;

¾ explorează fluxurile de informații care apar în etapa de livrare a unui produs în curs de dezvoltare;

¾ dezvolta modele de date conceptuale și logice;

¾ dezvolta software pentru stația de lucru automatizată pentru produse contabile

¾ să evalueze eficiența economică a sistemului informațional.

1 Dezvoltarea cerințelor software

1.1 Analiza soluțiilor existente

În prezent, există o gamă largă de companii care combină atât dezvoltarea directă a produselor, cât și dezvoltarea sistemelor de control pentru aceste produse. Astfel de sisteme sunt dezvoltate de companii bine-cunoscute precum 1: C Enterprise și Zvezda. În astfel de sisteme, se efectuează controlul și contabilitatea materialelor, iar prelucrarea informațiilor primite.

„1C: Enterprise” este un sistem de soluții aplicate construit pe aceleași principii și pe o singură platformă tehnologică. Managerul poate alege o soluție care să răspundă nevoilor actuale ale întreprinderii și se va dezvolta în continuare pe măsură ce întreprinderea crește sau sarcinile de automatizare se extind.

Sistemul software 1C: Enterprise este conceput pentru a rezolva o gamă largă de sarcini de automatizare a contabilității și managementului cu care se confruntă întreprinderile moderne în dezvoltare dinamică. Soluționarea problemelor urgente de contabilitate și management Compoziția programelor sistemului 1C: Enterprise este axată pe nevoile reale ale întreprinderilor. Firma "1C" produce soluții software serializate concepute pentru automatizarea sarcinilor tipice de contabilitate și gestionare la întreprinderi. O caracteristică distinctivă a soluțiilor ediției 1C este studiul amănunțit al compoziției funcționalității incluse în soluțiile standard. Firma „1C” analizează experiența utilizatorilor care utilizează programele sistemului „1C: Enterprise” și monitorizează modificările nevoilor acestora.

Principalele avantaje ale sistemului meu Wholesale Base includ costul relativ scăzut al implementării acestui sistem, precum și o serie de alte avantaje:

¾ Fiabilitatea aplicațiilor create. Pachetul software (PC) trebuie să fie rezistent nu numai la erorile utilizatorilor, ci și la defecțiunile sistemului de comunicații.

¾ Ușurința de utilizare a interfeței;

¾ Nivel ridicat de securitate a sistemului, care implică nu numai controlul asupra disponibilității anumitor resurse de sistem și securitatea informațiilor în toate etapele de funcționare, ci și urmărirea acțiunilor efectuate cu un grad ridicat de fiabilitate.

1.2 Analiza domeniului

Particularitatea analizei subiectului este că vă permite să vedeți întregul set de operațiuni ale organizației.

CASE este conceput pentru a analiza și reorganiza procesele de afaceri. – Toate instrumentele de nivel superior Fusion Process Modeler (BPwin) care acceptă metodologiile IDEF0 (Model funcțional), DFD (Diagrama fluxului de date) și IDEF3 (Diagrama fluxului de lucru). BPwin este un produs software puternic pentru crearea de modele pentru analiza, documentarea și planificarea schimbărilor în procesele complexe de afaceri. BPwin oferă un instrument pentru colectarea tuturor informațiilor relevante despre funcționarea întreprinderii și graficarea acestor informații sub forma unui model coerent și consecvent.

În ceea ce privește funcționalitatea sistemului. În cadrul metodologiei IDEF0 (Integration Definition for Function Modeling), un proces de afaceri este reprezentat ca un set de elemente de lucru care interacționează între ele și sunt prezentate resursele de informații, umane și de producție consumate de fiecare lucrare. Modelul funcțional este conceput pentru a descrie procesele de afaceri existente în întreprindere (așa-numitul model AS-IS) și starea ideală a lucrurilor – la ce să te străduiești (modelul TO-BE). Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame, adică descrieri unice ale fragmentelor de sistem. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii acestuia cu lumea exterioară (diagramă contextuală), după care se efectuează o descompunere funcțională – sistemul este împărțit în subsisteme și fiecare sistem este descris separat (diagrame de descompunere). Apoi, fiecare subsistem este împărțit în altele mai mici și așa mai departe pentru a atinge nivelul de detaliu dorit.

Dacă în procesul de modelare este necesar să evidențiați aspectele specifice ale tehnologiei întreprinderii, BPwin vă permite să treceți la orice ramură a modelului la notația DFD sau IDEF3. Diagramele Diagrama Fluxului de Date (DFD) pot completa ceea ce este deja reflectat în modelul IDEF3, deoarece descriu fluxurile de date, permițându-vă să urmăriți modul în care informațiile sunt schimbate între funcțiile de afaceri din sistem. În același timp, diagramele DFD ignoră interacțiunile dintre funcțiile de afaceri.

În ceea ce privește succesiunea lucrărilor efectuate. Și o imagine și mai precisă poate fi obținută prin completarea modelului cu diagrame IDEF3. Această metodă atrage atenția asupra ordinii în care sunt executate evenimentele. Elementele logice sunt incluse în IDEF3, care vă permite să modelați și să analizați scenarii alternative pentru dezvoltarea unui proces de afaceri.

Pentru a lua în considerare procesele de afaceri care rulează în depozitul magazinului, trebuie utilizate doar două metodologii IDEF0 și DFD. Procesul de modelare a unui sistem în IDEF0 începe cu definirea contextului, adică cel mai abstract nivel de descriere a sistemului sau a proceselor de afaceri în general.

Model IDEF0 ... Pentru a studia procesele de afaceri „Formarea comenzii unui furnizor”, „Primirea mărfurilor”, „Emiterea mărfurilor”, luați în considerare diagramele care sunt prezentate sub forma unei diagrame IDEF0. Sistemul IDEF0 este prezentat ca o colecție de activități sau funcții care interacționează.

Metodologia IDEF0 se bazează pe patru concepte principale.

Primul este conceptul bloc funcțional (Caseta de activitate) ... Un bloc funcțional este reprezentat grafic sub forma unui dreptunghi și personifică o anumită funcție specifică în cadrul sistemului în cauză

Fiecare dintre cele patru laturi ale unui bloc funcțional are propriul său sens specific (rol), în timp ce:

Partea superioară este Control;

Partea stângă este setată la „Intrare”;

Partea dreaptă este setată la Ieșire;

Dezavantajul este „Mecanismul”.

A doua „balenă” a metodologiei IDEF0 este conceptul de arc de interfață (Săgeată). Afișarea grafică a arcului interfeței este o săgeată unidirecțională. Fiecare arc de interfață trebuie să aibă propriul nume (Etichetă săgeată). Cu ajutorul arcurilor de interfață, sunt afișate diverse obiecte, într-un grad sau altul, determinând procesele care au loc în sistem. În acest caz, săgețile, în funcție de care față a dreptunghiului de lucru în care intră sau de ce față pleacă, sunt împărțite în:

Săgețile de intrare (incluse în partea stângă a blocului funcțional) - reprezintă date sau obiecte care sunt modificate în timpul executării lucrului;

Săgețile de control (incluse în fața superioară a blocului funcțional) - descriu regulile și restricțiile din cauza cărora se efectuează munca;

Săgeți de ieșire (ieșire din partea dreaptă a blocului funcțional) - reprezintă date sau obiecte care apar ca urmare a muncii;

Săgețile mecanismului (incluse în marginea inferioară a blocului funcțional) - reprezintă resurse (de exemplu, echipamente, resurse umane).

Al treilea concept de bază al standardului IDEF0 este Descompunerea. Principiul descompunerii se aplică atunci când descompunem un proces complex în funcțiile sale constitutive.

Descompunerea vă permite să reprezentați treptat și structurat modelul de sistem sub forma unei structuri ierarhice a diagramelor individuale, ceea ce îl face mai puțin supraîncărcat și ușor de digerat.

Ultimul dintre conceptele IDEF0 este Glosarul. Pentru fiecare dintre elementele IDEF0: diagrame, blocuri funcționale, arce de interfață, standardul existent presupune crearea și menținerea unui set de definiții adecvate, cuvinte cheie, narațiuni etc. care caracterizează obiectul afișat de acest element. Acest set se numește glosar și este o descriere a esenței acestui element.

Luați în considerare diagramele proceselor de afaceri care apar în depozitul magazinului OJSC DMM, "Cleonelly":

Pentru vizibilitatea generală a sistemului, este necesar să se construiască contextul „Activitatea depozitului întreprinderii” (vezi Figura 1.1).

Figura 1.1 - Diagrama "Activitatea depozitului întreprinderii"

După stabilirea contextului, se efectuează descompunerea, adică construind următoarele diagrame în ierarhie.

Fiecare diagramă ulterioară este o descriere mai detaliată a uneia dintre lucrările din diagrama superioară. Un exemplu de descompunere a muncii contextuale este prezentat în Figura 1.2. Astfel, întregul sistem este împărțit în subsisteme la nivelul dorit de detaliu, acest sistem este împărțit în trei niveluri.

Figura 1.2 - Diagramele de descompunere de primul nivel

Figura 1.3 - Diagrama "Înregistrarea mărfurilor"

Figura 1.4 - Diagrama "Emisiunea mărfurilor"

Figura 1.5 - Diagrama „Înregistrarea mărfurilor”

DFD. Această metodologie se bazează pe construirea unui model al SI analizat - proiectat sau existent efectiv. În conformitate cu metodologia, modelul de sistem este definit ca o ierarhie a diagramelor de flux de date (DFD), care descrie procesul asincron de transformare a informațiilor de la intrarea sa în sistem la ieșirea sa către utilizator. Diagramele DFD sunt de obicei construite pentru a vizualiza activitatea curentă a sistemului de flux de lucru al unei organizații. Cel mai adesea, diagramele DFD sunt utilizate pentru a completa modelul procesului de afaceri implementat în IDEF0.

Principalele componente ale unei diagrame de flux de date sunt:

Entități externe (reprezentate grafic ca un pătrat) - denotă un obiect material sau individ care este o sursă sau un receptor de informații. De exemplu: clienți, personal, furnizori, clienți, depozit;

Sisteme / subsisteme (arată grafic ca un dreptunghi cu colțuri rotunjite) - funcționează denotând funcții sau procese care procesează și schimbă informațiile;

Dispozitivele de stocare a datelor sunt un dispozitiv abstract pentru stocarea informațiilor care pot fi plasate într-un dispozitiv de stocare în orice moment și după un timp pot fi recuperate și poate exista orice mod de plasare și recuperare. În general, depozitul de date este un prototip al viitoarei baze de date și descrierea datelor stocate în acesta ar trebui să fie legată de modelul informațional;

Fluxuri de date - definește informațiile transmise printr-o conexiune de la sursă la receptor. Fluxul de date din diagramă este reprezentat de o linie care se termină cu o săgeată care indică direcția fluxului.

Luați în considerare Diagrama fluxului de date de problemă (DFD) Figura 1.6. Această diagramă arată mișcarea documentelor atunci când o „cerere de produs” ajunge la o organizație.

Figura 1.6 - Diagrama DFD „Emisiunea mărfurilor”

Luați în considerare următoarea diagramă a fluxului de date „Clearance produs” (a se vedea figura 1.7). Arată procesul de execuție a lucrărilor și mișcarea documentelor în timpul „emiterii de bunuri”.

Figura 1.7 - Diagrama DFD „Eliberarea mărfurilor”

În diagramele de flux de date, toate simbolurile utilizate se adaugă la o imagine de ansamblu, ceea ce oferă o idee clară despre ce date sunt utilizate și ce funcții sunt îndeplinite de sistemul de flux de lucru. În același timp, se dovedește adesea că fluxurile de informații existente, care sunt importante pentru activitățile companiei, nu sunt implementate în mod fiabil și trebuie reorganizate. *******

Structura organizatorică a unei întreprinderi care vinde produse tery este luată în considerare pe exemplul Donetsk Manufactura M, un magazin Cleonelly:

În direcția dezvoltării sistemelor de control și a contabilității materialelor, acestea pot rezolva cu succes problemele:

1. Acesta este controlul asupra bunurilor furnizate și depozitate.

2. Informații despre furnizori și consumatori

3. De asemenea, conține informații despre informații și operațiuni despre produs

4. Conține un jurnal al raportului mărfurilor eliberate

5. Conține un director de bunuri

6. Automatizarea funcțiilor de depozit (primire, cheltuială, radiere, rezervare mărfuri)

7. Înregistrarea și stocarea facturilor pentru bunurile și serviciile achiziționate și vândute, precum și facturarea pentru plata în avans, plata amânată și livrarea bunurilor

8. Crearea facturilor și contabilitatea bunurilor emise

9. Realizarea unui inventar de depozite cu crearea unei declarații de colaționare, un act de penurie și excedent

10. Crearea seturilor de bunuri

După cum sa indicat, principalul domeniu de activitate al acestei întreprinderi este vânzarea de produse din bumbac. Procesul de proiectare include multe etape elaborate cu atenție de către structurile de conducere ale întreprinderilor de proiectare pe parcursul întregii vieți a întreprinderii. Acest proces nu poate fi modificat în același timp, deoarece implică multe departamente ale întreprinderii în sine, subcontractanți externi și clienți ai întreprinderii proiectului. Prin urmare, întreprinderile sunt prudente cu privire la implementarea sistemelor informatice legate de procesele de management al proiectării și dezvoltării. De regulă, întreprinderile rusești își folosesc propriile dezvoltări în acest domeniu.

1.3 Cerințe de colectare

La proiectarea unui sistem informațional (IS) pentru „stația de lucru a magazinului cu ridicata”, a fost necesar să colectăm cerințe care să ajute la crearea unei interfețe în așa fel încât utilizatorul final (angajatul magazinului) să se simtă confortabil să lucreze cu IS dezvoltat.

Dezvoltarea cerințelor este procesul care include activitățile necesare pentru crearea și aprobarea unui document de specificație a cerințelor de sistem.

Pentru a implementa procesul de automatizare a contabilității și controlul materialelor, este necesar ca sistemul informațional să îndeplinească următoarele cerințe funcționale:

¾ documentarea rezultatelor.

¾ Sistemul informațional trebuie implementat ca un program bazat pe mediul integrat Visual Fox Pro.

Programul funcționează în sistemul de operare Windows 2000 / NT / XP.

Există patru etape principale în procesul de dezvoltare a cerințelor (Figura 1.8):

Analiza fezabilității tehnice a creării unui sistem;

Formarea și analiza cerințelor;

Specificarea cerințelor și crearea documentației relevante;

Atestarea cerințelor.

Colectarea cerințelor este o etapă importantă în proiectarea software-ului, deoarece tocmai aici trebuie să fie formulate corect și corect toate cerințele clienților.

1.4 Specificația cerințelor

Determinarea cerințelor corecte este probabil cel mai critic pas într-un proiect software. Este foarte important ca formatul proiectului să corespundă cerințelor software asamblate de echipa de dezvoltare, altfel aceste cerințe nu pot fi acceptate și prezentate în produsul software. Specificația cerințelor software (SRS) este esențială pentru întregul ciclu de viață al dezvoltării software-ului. Nu este doar un document derivat care definește specificațiile unui proiect software, ci și documentul principal utilizat în scopul efectuării testelor de calificare și acceptare. Atestarea este o evaluare a calității muncii managerilor de proiect. Determină gradul de conformitate al unui produs software cu cerințele stabilite. Specificația SRS acționează ca un mecanism de înregistrare a cerințelor sistemului care sunt utilizate ca criterii de atestare.

Pe baza SRS, se ajunge la un acord între clienți și producătorii produsului software. Specificația SRS descrie pe deplin funcțiile pe care trebuie să le îndeplinească produsul software în curs de dezvoltare. Acest lucru permite potențialilor utilizatori să determine gradul în care produsul răspunde nevoilor lor, precum și modalități de modificare a produsului, astfel încât acesta să fie cel mai util în rezolvarea problemelor lor.

Scade timpul de dezvoltare. Diverse grupuri din cadrul organizației clientului sunt implicate în pregătirea specificației SRS. Ei investighează amănunțit toate cerințele chiar înainte de începerea dezvoltării efective a proiectului. Acest lucru reduce probabilitatea de reproiectare, codificare și testare ulterioară.

Examinarea atentă a cerințelor din specificația SRS poate dezvălui neglijări, neînțelegeri și neconcordanțe la începutul ciclului de dezvoltare, când problemele sunt mult mai ușor de remediat decât mai târziu.

Specificația SRS devine baza pentru estimarea și programarea costurilor. Descrierea produsului este baza reală pentru estimarea costului unui proiect. Într-un mediu în care există conceptul unei propuneri formale, SRS este utilizat pentru a aproba estimarea unei propuneri sau a unui preț.

Cu specificații bine scrise, SRS la nivel de organizație pot dezvolta planuri de certificare și audit mult mai productive. Ca parte a contractului de dezvoltare, SRS oferă un punct de referință pentru evaluarea conformității cu specificațiile.

Specificația SRS facilitează transferul produsului software către noii utilizatori, precum și instalarea acestuia pe alte computere. Astfel, devine mai ușor pentru clienți să transfere produsul software către alte departamente ale organizației și pentru dezvoltatori să îl transfere către alți clienți.

Specificația SRS servește ca bază pentru modernizare. Acest document tratează produsul în sine, nu procesul de dezvoltare a proiectului, deci poate fi utilizat pentru extinderea produsului finalizat.

Odată ce procesul de definire și specificare a cerințelor a fost finalizat, este necesar să se valideze cerințele.

Specificația cerințelor pentru proiectul software ar trebui prezentată în Anexa A.

1.5 Atestarea cerințelor

Validarea trebuie să demonstreze că cerințele definesc de fapt sistemul pe care dorește să îl aibă clientul. Validarea cerințelor este importantă deoarece o eroare în specificația cerințelor poate duce la refacerea sistemului și costuri ridicate dacă este descoperită în timpul procesului de dezvoltare a sistemului sau după punerea acestuia în producție.

În timpul procesului de atestare a cerințelor, ar trebui efectuate diferite tipuri de verificări ale documentației cerințelor:

1. Verificarea corectitudinii cerințelor.

2. Verificarea consistenței.

3. Verificați completitudinea.

4. Verificarea fezabilității.

Există o serie de metode de atestare a cerințelor care pot fi utilizate împreună sau fiecare separat:

1. Revizuirea cerințelor.

2. Prototipare.

3. Generarea de scripturi de testare.

4. Analiza automată a consistenței.

Prototiparea este cea mai vizibilă pentru clientul sistemului.

Înainte de a începe prototiparea, puteți crea o diagramă de flux a interfeței cu utilizatorul. Această diagramă este utilizată pentru a studia relațiile dintre elementele principale ale interfeței cu utilizatorul.

Următorul pas în validarea cerințelor este prototiparea directă.

Un prototip software este o implementare parțială sau posibilă a unui produs nou propus. Prototipurile vă permit să îndepliniți trei sarcini principale: clarificarea și finalizarea procesului de formulare a cerințelor, explorarea soluțiilor alternative și crearea produsului final.

Prototipul meniului principal al acestui modul este prezentat în Figura 1.9.

1.6 Alegerea unei metodologii de proiectare a sistemului informațional

Esența abordării structurale a dezvoltării unui SI constă în descompunerea (partiționarea) acestuia în funcții automate: sistemul este împărțit în subsisteme funcționale, care la rândul lor sunt împărțite în subfuncții, subdivizate în sarcini și așa mai departe. Procesul de partiționare continuă până la proceduri specifice. În același timp, sistemul automat păstrează o viziune holistică în care toate componentele componente sunt interconectate.

Toate cele mai comune metodologii de abordare structurală se bazează pe o serie de principii generale. Următoarele principii sunt utilizate ca două principii de bază:

Împărțiți și cuceriți - principiul rezolvării problemelor complexe prin descompunerea lor în multe probleme independente mai mici, ușor de înțeles și de rezolvat;

Principiul ordonării ierarhice este principiul organizării părților constitutive ale unei probleme în structuri arborescente ierarhice cu adăugarea de noi detalii la fiecare nivel.

În analiza structurală, există în principal două grupuri de instrumente care ilustrează funcțiile îndeplinite de sistem și relațiile dintre date. Fiecare grup de fonduri corespunde anumitor tipuri de modele (diagrame), cele mai frecvente, printre care sunt următoarele:

Modele SADT (Analiza structurată și tehnica de proiectare) și diagrame funcționale conexe;

Diagramele fluxului de date DFD (Data Flow Diagrams);

Diagramele entitate-relație ERD (Entity-Relationship Diagrams).

La etapa de proiectare a IS, modelele sunt extinse, rafinate și completate cu diagrame care reflectă structura software-ului: arhitectură software, diagrame bloc de programe și diagrame de ecran.

Modelele enumerate împreună oferă o descriere completă a IP-ului, indiferent dacă acesta este existent sau nou dezvoltat. Compoziția diagramelor în fiecare caz specific depinde de caracterul complet necesar al descrierii sistemului.

2 PROIECTAREA SISTEMULUI DE INFORMAȚIE

2.1 Proiectare arhitecturală

La crearea oricărui sistem informațional complex, arhitectura acestuia este un aspect critic, în care reprezintă o viziune conceptuală a structurii viitoarelor procese funcționale și tehnologii la nivel de sistem și în interconectare. De obicei, sistemele de informații complexe ale organizațiilor sunt concepute ca o compoziție de componente de interacțiune la nivel înalt, care pot fi ele însele sisteme. Arhitectura sistemului informațional al unei organizații face sistemul mai ușor de înțeles prin definirea funcționalității și structurii sale într-un mod care dezvăluie deciziile de proiectare și permite observatorului să pună întrebări despre îndeplinirea cerințelor de proiectare, alocarea funcționalității și implementarea componentelor.

Arhitectura sistemului informațional al unei organizații este un model al modului în care tehnologia informației va susține principalele obiective și strategia de dezvoltare a unui obiect automat. Vă permite să gândiți critic și să articulați o viziune asupra modului în care ar trebui structurate seturile integrate de sisteme de informații pentru a atinge aceste obiective. Arhitectura sistemului informațional descrie modul în care sistemele informaționale, aplicațiile și oamenii funcționează în întreaga organizație într-un mod uniform și unificat.

Astfel, arhitectura unui sistem informațional include un set general acceptat de componente care furnizează „elementele de bază” ale unui sistem informațional. Aceste „elemente de bază” și caracteristicile lor sunt definite la un nivel adecvat de detaliu pentru a satisface nevoile deciziilor de planificare.

La proiectarea sistemelor informatice moderne ale organizațiilor, arhitectura acestora ar trebui dezvoltată ținând seama de numeroase părți interesate, ar trebui să fie ușor de înțeles de către utilizatori, să permită dezvoltatorilor să facă un plan și planificări ale sistemului, să permită definirea interfețelor cheie, funcțiilor și tehnologiilor și, de asemenea, să permită estimarea programului și a bugetului proiectului. Acest lucru necesită responsabilitatea arhitecților sistemelor informatice moderne de a crea un concept satisfăcător și funcțional al sistemului în cea mai timpurie etapă a dezvoltării sale, de a menține integritatea acestui concept pe tot parcursul dezvoltării și de a determina adecvarea sistemului rezultat pentru utilizarea de către client. Arhitectura sistemului informațional, pe de altă parte, este procesul de descriere a arhitecturilor sistemului informațional în detaliu suficient pentru a le face mai utile pentru proiectarea sistemului informațional.

Studiul experienței străine arată că în țările dezvoltate, atunci când se dezvoltă o arhitectură a sistemului informațional, trebuie îndeplinite următoarele condiții:

¾ concentrarea asupra misiunii organizației;

¾ concentrarea pe cerințe;

¾ accent pe dezvoltare;

¾ capacitatea de adaptare;

¾ nevoia de flexibilitate.

Respectarea tuturor acestor condiții permite dezvoltarea arhitecturii sistemului informațional al organizației mai perfect și mai eficient.

Principalele arhitecturi software în curs de implementare sunt:

¾ server de fișiere;

¾ client-server;

¾ multi-nivel.

Server de fișiere ... Această arhitectură a bazelor de date centralizate cu acces la rețea implică desemnarea unuia dintre computerele din rețea ca un server dedicat care va stoca fișierele bazei de date centralizate. În conformitate cu cererile utilizatorilor, fișierele de pe serverul de fișiere sunt transferate către stațiile de lucru ale utilizatorilor, unde se efectuează cea mai mare parte a procesării datelor. Serverul central îndeplinește în principal doar rolul de stocare a fișierelor, neparticipând la prelucrarea datelor în sine. După finalizarea lucrării, utilizatorii copiază fișierele cu datele procesate înapoi pe server, de unde pot fi preluate și procesate de alți utilizatori. Această organizare a întreținerii datelor are o serie de dezavantaje, de exemplu, atunci când mulți utilizatori accesează aceleași date în același timp, performanța de lucru scade brusc, deoarece este necesar să așteptați până când utilizatorul care lucrează cu datele își termină activitatea. În caz contrar, modificările făcute de unii utilizatori pot fi suprascrise de modificările făcute de alți utilizatori.

Client server ... Acest concept se bazează pe ideea că, pe lângă stocarea fișierelor bazei de date, serverul central trebuie să facă cea mai mare parte a procesării datelor. Utilizatorii accesează serverul central utilizând un limbaj special de interogare structurat (SQL, Structured Query Language), care descrie lista sarcinilor efectuate de server. Cererile utilizatorilor sunt primite de server și generează procese de procesare a datelor în acesta. Ca răspuns, utilizatorul primește un set de date deja procesat. Nu întregul set de date este transferat între client și server, așa cum se întâmplă în tehnologia server-fișier, ci doar datele de care clientul are nevoie. O interogare a utilizatorului care are doar câteva linii poate genera prelucrarea datelor care implică multe tabele și milioane de rânduri. Ca răspuns, clientul poate primi doar câteva numere. Tehnologia client-server evită transmiterea unor cantități uriașe de informații prin rețea prin mutarea tuturor procesării datelor către un server central. În plus, abordarea luată în considerare permite evitarea conflictelor de modificări ale acelorași date de către mai mulți utilizatori, care sunt tipice pentru tehnologia serverului de fișiere. Tehnologia client-server implementează modificarea consecventă a datelor de către mai mulți clienți, asigurând integritatea automată a datelor. Acestea și câteva alte avantaje au făcut ca tehnologia client-server să fie foarte populară. Dezavantajele acestei tehnologii includ cerințe de performanță ridicate pentru serverul central. Cu cât accesează serverul mai mulți clienți și cu cât este mai mare cantitatea de date procesate, cu atât serverul central trebuie să fie mai puternic.

Pe baza acestor considerații, la proiectarea arhitecturii AWS, tehnologia client-server a fost luată ca bază. Diagramele de aspect arată relațiile fizice dintre componentele software și hardware ale unui sistem.)

2.2 Proiectarea interfeței sistemului informațional

Interfața cu utilizatorul este adesea înțeleasă doar ca aspectul programului. Cu toate acestea, în realitate, utilizatorul percepe întregul sistem ca un întreg prin el, ceea ce înseamnă că o astfel de înțelegere a lui este prea îngustă. În realitate, interfața cu utilizatorul include toate aspectele proiectării care afectează interacțiunea dintre utilizator și sistem. Utilizatorul nu vede doar ecranul. Interfața cu utilizatorul este formată din mai multe componente, cum ar fi:

un set de sarcini ale utilizatorului pe care le rezolvă folosind sistemul;

controale de sistem;

navigare între blocuri de sistem;

proiectarea vizuală a ecranelor de programe.

Iată câteva dintre cele mai semnificative avantaje de afaceri ale unei bune interfețe cu utilizatorul:

reducerea numărului de erori ale utilizatorilor;

reducerea costurilor de întreținere a sistemului;

reducerea pierderilor de productivitate a angajaților în timpul implementării sistemului și recuperarea mai rapidă a productivității pierdute;

îmbunătățirea moralului personalului;

reducerea costului schimbării interfeței cu utilizatorul la cererea utilizatorilor;

disponibilitatea funcționalității sistemului pentru numărul maxim de utilizatori.

Baza angro AWP este dezvoltată ca o aplicație utilizând tehnologia client-server.

2.2.1 Interfața cu utilizatorul programului de control

Modulul principal al „AWP Wholesale Base” este modulul Luck.exe, care oferă implementarea funcționalității principale a diagramei de caz de utilizare prezentată în Figura 1.9 din Secțiunea 1.4.

Când dezvoltați un sistem informațional, una dintre principalele sarcini este crearea celei mai simple și neîncărcate interfețe. Este interfața produsului software care îi ajută pe utilizatori să „comunice” cu sistemul informațional, acționând ca un dialog între utilizator și sistem.

Interfața programului, partea administrativă:

1. forma de pornire a programului. Acest formular este lansat la lansarea produsului software, formând astfel începutul unui dialog al utilizatorului cu sistemul (Figura 2.3);

2. formular de administrare. În acest formular, se efectuează gestionarea completă a sistemului informațional, adică adăugarea, ștergerea, schimbarea datelor din baza de date, precum și, dacă este necesar, vizualizarea și tipărirea rapoartelor (Figura 2.4);

3. Formularul „Clienți”, datorită acestui formular, puteți vedea informații complete despre clienții întreprinderii (Figura 2.7);

4. Formularul „Furnizori”, datorită acestui formular, puteți vedea informații complete despre clienții întreprinderii (Figura 2.8).

Interfața cu utilizatorul programului:

În fereastra pentru sosirea mărfurilor, înregistrarea mărfurilor este în curs. Atunci când alegeți această filă a formularului, utilizatorul trebuie mai întâi

În meniul de cheltuieli, există operațiuni efectuate de angajatul depozitului pentru eliberarea și vânzarea mărfurilor.

În balanțele meniului, mărfurile sunt numărate, numele articolelor stocate în depozit.

În meniul pentru casierie, informații despre comenzile de credit și comenzile de ieșire de numerar sunt stocate aici. (Capturi de ecran)

2.2.2 Interfețe utilizator ale componentelor de control

Fig 2.0 Meniul principal al programului

Fereastra principală a programului este prezentată în Fig. 1.9. După cum puteți vedea din figură, pe lângă meniul principal, descris deja mai sus, acesta va conține și un panou de control (butoanele „Venit”, „Consum”, „Acces”, „Solduri”, „Casier”, „Reevaluare”, „Analitică”, „ Directoare "," Serviciu "și" Ieșiți din program ").

Figura 2.1 Fereastra meniului de primire sau primire către depozit.

Figura 2.2 Fereastra meniului Consum

Figura 2.2 Fereastra meniului care reglementează drepturile de acces la program.

Figura 2.3 Fereastra meniului pentru restul mărfurilor.

Figura 2.4 Fereastra meniului casei de marcat.

Figura 2.4 Fereastra meniului de reevaluare.

2.3 Proiectarea bazei de date

ERwin 4.0 de la Computer Associates Int a fost utilizat pentru proiectarea bazei de date.

ERwin este un instrument puternic și ușor de utilizat de proiectare a bazelor de date care a câștigat o largă acceptare și popularitate. Oferă cea mai mare productivitate la dezvoltarea și întreținerea aplicațiilor de baze de date. De-a lungul întregului proces - de la modelarea logică a cerințelor de informații și a regulilor de afaceri care definesc baza de date, până la optimizarea modelului fizic în conformitate cu caracteristicile specificate - ERwin vă permite să afișați vizual structura și elementele de bază ale bazei de date.

ERwin nu este doar cel mai bun instrument de proiectare a bazelor de date, ci și un instrument pentru a crea unul rapid. ERwin optimizează modelul în funcție de caracteristicile fizice ale bazei de date țintă. Spre deosebire de alte instrumente, ERwin menține automat consistența schemei logice și fizice și traduce construcții logice, cum ar fi relațiile de la mulți la mulți, în implementări fizice. Facilitează proiectarea bazelor de date. Pentru a face acest lucru, este suficient să creați un model grafic E-R (relație obiect) care să îndeplinească toate cerințele de date și să introduceți reguli de afaceri pentru a crea un model logic care afișează toate elementele, atributele, relațiile și grupările. Erwin are două niveluri de prezentare a modelului - logic și fizic. Stratul logic este o vedere abstractă a datelor, pe acesta datele sunt prezentate așa cum arată în lumea reală și pot fi numite așa cum se numește în lumea reală, de exemplu, „Client fidel”, „Departament” sau „Numele de familie al angajatului”. Obiectele model care sunt reprezentate la nivel logic se numesc entități și atribute. Nivelul logic al modelului de date este universal și nu are nimic de-a face cu o implementare specifică a SGBD. Există trei subnivele ale nivelului logic al modelului de date, care diferă prin profunzimea prezentării informațiilor despre date:

Diagrama relațiilor cu entitățile (ERD);

Model bazat pe cheie (KB);

Model complet atribuit (FA).

Diagrama entității - Relația include entități și relații care reflectă regulile de bază ale domeniului. O astfel de diagramă nu este prea detaliată, include principalele entități și relațiile dintre ele care îndeplinesc cerințele de bază. Diagrama entității - O relație poate include relații de la mai mulți la mulți și nu include descrieri cheie. De obicei, ERD este utilizat pentru prezentări și discuții cu structuri de date cu experți din domeniu. Un model de date bazat pe cheie este o vedere mai detaliată a datelor. Acesta include o descriere a tuturor entităților și cheilor primare și este destinat să reprezinte structura datelor și cheile care corespund domeniului subiect.

Un model logic este cea mai detaliată reprezentare a unei structuri de date: reprezintă date în a treia formă normală și include toate entitățile, atributele și relațiile (vezi Anexa B).

Model de date fizice dimpotrivă, depinde de SGBD specific, fiind de fapt o afișare a catalogului sistemului. Stratul fizic al modelului conține informații despre toate obiectele din baza de date. Deoarece nu există standarde pentru obiectele bazei de date (de exemplu, nu există standard pentru tipurile de date), stratul fizic al modelului depinde de implementarea specifică a SGBD. În consecință, mai multe niveluri fizice diferite ale diferitelor modele pot corespunde aceluiași nivel logic al unui model. Dacă la nivelul logic al modelului nu contează prea mult ce tip de date specific al atributului (deși tipurile de date abstracte sunt acceptate), atunci la nivelul fizic al modelului este important să descrieți toate informațiile despre obiecte fizice specifice - tabele, coloane, indici, proceduri etc. ... Împărțirea modelului de date în niveluri logice și fizice vă permite să rezolvați mai multe probleme importante.

Modelul de date fizice este prezentat în Anexa B.

2.4 Temeiul alegerii unei platforme pentru crearea unui sistem informațional

Visual FoxPro este un mediu de dezvoltare vizuală pentru sistemele de gestionare a bazelor de date relaționale disponibile în prezent de la Microsoft. Cea mai recentă versiune este 9.0. Folosește limbajul de programare FoxPro. Versiunea de sistem 7.0 poate rula pe sisteme de operare Windows 9x și nuclee NT, versiunile 8.0 și 9.0 - numai în Windows XP, 2000, 2003.

FoxPro (Fox-pro?) Este unul dintre dialectele limbajului de programare xBase. Este utilizat în principal pentru dezvoltarea SGBD relațional, deși este posibil să-l utilizați pentru dezvoltarea altor clase de programe. După cum sa menționat mai sus, limbajul VFP este un limbaj xBase puternic mărit și extins. În Visual FoxPro, un limbaj de programare, adică construcția de bază a unui limbaj este conceptul de clasă. Versiunea originală a xBase este cel mai pur limbaj structural, cu un concept de bază de proceduri și funcții. Astfel, limbajul de programare modern Visual FoxPro vă permite să combinați atât programarea „de modă veche” descriind o masă de proceduri, cât și în stilul OOP, creând o ierarhie complexă de clase.

Am ales acest limbaj de programare deoarece conține mai multe dintre următoarele avantaje:

¾ Un format de tabel de bază de date bine cunoscut care facilitează organizarea schimbului de informații cu alte aplicații Microsoft Windows.

Organizarea modernă a bazelor de date relaționale, care vă permite să stocați informații despre tabelele bazei de date, proprietățile, indexurile și relațiile acestora, să setați condiții de integritate referențială, să creați vizualizări locale și la distanță, conexiuni la server, proceduri stocate executate atunci când apar peste 50 de tipuri diferite de evenimente (VFP 7.0-9.0).

Viteză mare de lucru cu baze de date mari.

Vizibilitate ridicată a lucrului cu baze de date: fereastra multifuncțională de sesiune de date vă permite să vedeți lista tabelelor de baze de date deschise, relațiile acestora, filtrele, ordinea indexului, modurile de tamponare, trecerea la modurile de modificare a structurii, pentru a lucra cu informații de tabel etc.

Viteză mare de dezvoltare a aplicațiilor folosind Wizards, Designer, Builders, modul de sugestii IntelliSense atunci când scrieți programe, depanați și testați programe.

Capacitatea de a dezvolta aplicații client-server cu date găzduite pe serverele de baze de date Oracle și Microsoft SQL Server și cu alte aplicații Microsoft Windows utilizând ODBC și OLE

Sistemul VFP este destinat utilizării de către programatori profesioniști, deci nu are rost să rusifice meniul și limba - pentru orice programator, sintaxa engleză a unui limbaj algoritmic este mai familiară decât rusa.

2.5 Proiectarea modulelor

Să ne gândim mai detaliat la proiectarea unuia dintre modulele programului și să luăm în considerare, folosind exemplul său, pașii necesari pentru a crea un proiect.

De exemplu, voi lua în considerare proiectarea unui modul care implementează cazul de utilizare „Emite o cerere de admitere”.

În primul rând, să descriem fluxurile de evenimente care apar în acest caz de utilizare.

O condiție prealabilă pentru un caz de utilizare este primirea unei cereri de la un client.

5. Cazul de utilizare începe atunci când clientul trimite cererea.

6. Managerul deschide formularul de venit.

7. Managerul stabilește data cererii.

8. Managerul pune numele produsului.

9. Managerul introduce cantitatea de bunuri primite.

10. Managerul introduce suma cererii.

11. Managerul închide formularul.

12. Cazul de utilizare se termină.

Condiția ulterioară a cazului de utilizare este înregistrarea unei aplicații în sistem și apariția unui nou client în jurnalul formularului principal.

Luați în considerare o diagramă de secvență pentru acest caz de utilizare. După cum puteți vedea din această diagramă, managerul, deschizând formularul Sosire, face ca mai multe acțiuni să fie efectuate - automat (din punctul de vedere al managerului) se completează data cererii. Când plasați o cerere, lista clienților este completată de la bază cu informații primare. După aceea, managerul introduce toate datele necesare și face clic pe butonul „Accept”. În acest caz, se efectuează următoarele acțiuni. Toate datele sunt transmise procedurii stocate.

3 Implementarea și validarea sistemului informațional

3.1 Implementarea aplicației

Implementarea aplicației, în esența sa, este una dintre etapele laborioase pentru dezvoltatorul sistemului informațional, deoarece cerințele pe care le prezintă clientul trebuie să fie integrate în mod clar și corect în sistem. Până în prezent nu există produse software care s-ar putea „adapta” la cerințele așa-numitului client și să ofere un anumit set de funcții pentru implementarea sistemului care ar îndeplini aceste cerințe. Prin urmare, fiecare dezvoltator trebuie să aleagă mediul optim pentru dezvoltarea sistemului, dar trebuie remarcat faptul că, atunci când implementați o aplicație, nu puteți face fără a scrie codul programului. Atunci când scrieți codul programului, vor fi implementate anumite funcții pe care sistemul trebuie să le îndeplinească. În funcție de mediul de implementare al sistemului selectat, codul programului va arăta diferit, într-un mediu precum Microsoft Visual FoxPro va exista un cod de program, în Visual Basic altul etc.

În acest caz, aplicația a fost implementată în Microsoft Visual FoxPro.

Funcțiile principale ale sistemului vor fi descrise mai jos:

1. Forma de pornire a sistemului. Acest formular este un formular de buton și, în consecință, fiecare buton își îndeplinește funcția. Butonul de înregistrare a administratorului este prezentat în Figura 3.1 Acest buton va îndeplini funcția care deschide panoul de administrator dacă utilizatorul are astfel de drepturi asupra acestui sistem.

2. Sosire buton meniu. Acest buton vă permite să urmăriți bunurile primite în depozitul magazinului Figura 3.2.

3. În butonul meniului, cheltuielile sunt păstrate în evidența bunurilor eliberate din depozit Figura 3.3.

4. În butonul meniului de acces, drepturile de utilizare a acestui program sunt reglementate Figura 3.4.

5. În butonul meniului „resturi” sunt stocate informații despre materialele stocate în depozitul magazinului Fig. 3.5.

6. Butonul de meniu al casei de marcat stochează informații despre comenzile de numerar primite și comenzile de numerar de ieșire Figura 3.6.

7. În reevaluarea butonului meniului, modificările de preț pentru noul preț al mărfurilor sunt efectuate Fig.3.7.

Figura 3.1 - Formular de pornire a sistemului

Figura 3.2 - Forma de contabilitate a încasărilor de bunuri către depozit.

Figura 3.3– Forma de contabilitate a mărfurilor eliberate.

Figura 3.4– Formular care reglementează drepturile de acces la program.

Figura 3.5– Forma resturilor de mărfuri din depozit.

Figura 3.5 - Formular despre încasările și încasările de numerar.

Figura 3.6 - Forma operațiunilor asupra mărfurilor.

Testarea aplicației

Testarea este procesul de executare a unui program pentru detectarea erorilor. Testarea oferă:

Eroare detectata;

Demonstrarea conformității funcțiilor programului cu scopul său;

Demonstrarea implementării cerințelor pentru caracteristicile programului;

Afișarea fiabilității ca indicator al calității programului.

Figura 3.2 prezintă fluxurile de informații ale procesului de testare.

Există trei fluxuri la intrarea procesului de testare:

Textul programului;

Date inițiale pentru începerea programului;

Rezultate asteptate.

Se efectuează teste și se evaluează toate rezultatele obținute. Aceasta înseamnă că rezultatele efective ale testului sunt comparate cu rezultatele așteptate. Când se constată o nepotrivire, se înregistrează o eroare și începe depanarea.

După colectarea și evaluarea rezultatelor testului, începe afișarea calității și fiabilității software-ului. Dacă sunt întâmpinate în mod regulat erori grave care necesită modificări de proiectare, atunci calitatea și fiabilitatea software-ului sunt suspecte și este menționată necesitatea consolidării testelor.

Rezultatele acumulate în timpul testării pot fi evaluate într-un mod mai formal. Pentru aceasta, se folosesc modele de fiabilitate software care prezic fiabilitatea pe baza datelor reale privind rata de eroare.

Există 2 principii de testare software:

Testarea funcțională (testarea cutiei negre);

Testarea structurală (testarea cutiei albe).

La testarea metodei „cutiei albe”, structura internă a programului este cunoscută. Obiectul testării aici nu este comportamentul extern, ci comportamentul intern al programului. Sunt verificate corectitudinea construcției tuturor elementelor programului și corectitudinea interacțiunii lor între ele.

Testarea cutiei negre (testarea funcțională) vă permite să obțineți combinații de date de intrare care oferă o verificare completă a tuturor cerințelor funcționale pentru program //. Un produs software este considerat aici ca o „cutie neagră” al cărei comportament poate fi determinat doar prin examinarea intrărilor sale și a ieșirilor corespunzătoare.

Principiul „cutiei negre” nu este o alternativă la principiul „cutiei albe”. Mai degrabă, este o abordare complementară care detectează o clasă diferită de erori.

Testarea casetei negre caută următoarele categorii de erori:

Caracteristici incorecte sau lipsă;

Erori de interfață;

Erori în structurile de date externe sau în accesarea unei baze de date externe;

Erori caracteristice (capacitatea de memorie necesară etc.);

Erori de inițializare și finalizare.

Spre deosebire de testarea cutiei albe, care se face la începutul procesului de testare, testarea cutiei albe este utilizată în etapele ulterioare ale testării. La testarea casetei negre, structura de control a programului este neglijată. Aici accentul se pune pe domeniul informațiilor din definiția sistemului software. Testarea în această fază se concentrează pe adecvarea soluției pentru un mediu de producție live. Accentul este pus pe remedierea erorilor și identificarea severității acestora și pregătirea produsului pentru lansare.

În etapa de testare, sunt rezolvate două sarcini principale:

Testarea soluției - Planurile de testare create în faza de planificare și extinse și testate în faza de dezvoltare sunt executate;

Operațiune pilot - implementarea soluției într-un mediu de testare și testare cu implicarea viitorilor utilizatori și implementarea unor scenarii reale de utilizare a sistemului. Această sarcină este finalizată înainte de începerea fazei de implementare.

Scopul fazei de testare este de a reduce riscul care apare atunci când soluția este pusă în funcțiune comercială.

Pentru ca faza de testare să aibă succes, trebuie să existe o schimbare de atitudine față de proiect, iar dezvoltatorul trece de la dezvoltarea de noi caracteristici la asigurarea calității adecvate a soluției.

În acest stadiu de dezvoltare a sistemului informațional, trebuie efectuate următoarele tipuri de teste:

Testarea de bază este testarea tehnică la nivel scăzut. Acesta este realizat de dezvoltatorul însuși în procesul de scriere a codului programului. Se folosește metoda „cutiei albe”, cu risc ridicat de erori.

Testare de utilizare - Testare la nivel înalt efectuată de tester și de viitorii utilizatori ai produsului. Se aplică metoda „cutiei negre”.

Testarea alfa și beta - În termeni MSF, codul alfa este practic tot codul sursă care a fost creat în faza de dezvoltare a modelului de proces MSF, iar codul beta este codul care a fost testat în timpul fazei de testare. Prin urmare, codul alfa este testat în timpul fazei de dezvoltare a modelului de proces MSF, iar codul beta este testat în timpul fazei de testare.

Testarea compatibilității - Soluția dezvoltată necesită integrare și interoperabilitate cu sistemele și soluțiile software existente. Această formă de testare este axată pe testarea integrabilității și capacității soluției dezvoltate de a interacționa cu sistemele existente. În acest caz particular, corectitudinea aplicației va fi verificată pe echipamentul utilizatorului și pe software-ul utilizat de acesta.

Testarea performanței - axată pe verificarea dacă aplicația îndeplinește cerințele de performanță și nivelul de confort în ceea ce privește viteza.

Documentarea și testarea sistemului de asistență - sunt testate toate documentele de sprijin și sistemele de ajutor dezvoltate.

Operațiunea pilot testează o soluție într-un mediu industrial. Scopul principal al operației pilot este de a demonstra că soluția este capabilă să funcționeze stabil în condiții industriale și să îndeplinească cerințele comerciale. În timpul operației pilot, soluția este testată în condiții reale. Operarea pilot permite utilizatorilor să ofere feedback cu privire la performanța produsului. Ghidat de această opinie, dezvoltatorul elimină toate problemele posibile sau creează un plan de acțiune în caz de circumstanțe neprevăzute. În cele din urmă, operația pilot vă permite să decideți dacă începeți o implementare la scară completă sau amânați până când se rezolvă orice probleme care ar putea perturba implementarea.

Planul procesului de operare pilot pentru sistemul de informații dezvoltat este prezentat în Tabelul 3.2.

Tabelul 3.2 - Planul de operare pilot

act		Descriere
1. Alegerea criteriilor de succes		Dezvoltatorul și testatorii definesc criteriile de succes și sunt de acord cu ele
2. Alegerea utilizatorilor și locația de instalare		Se formează o echipă de participanți la testarea pilot din partea utilizatorilor și a dezvoltatorilor. Se determină locația desfășurării procesului pilot.
3. Pregătirea utilizatorilor și a site-urilor de instalare		Instruirea utilizatorilor - participanții la proces se desfășoară. Site-ul de instalare este în curs de pregătire.
4. Implementarea unei versiuni de dezvoltare		O versiune experimentală este instalată și inclusă în lucrare.
5. Suport și monitorizare a versiunii de dezvoltare		Monitorizarea activității utilizatorilor și a sistemului, oferirea de asistență în exploatare, colectarea informațiilor despre funcționarea sistemului
6. Feedback-ul utilizatorilor și evaluarea rezultatelor		Utilizatorii își exprimă opinia despre funcționarea sistemului, evidențiază deficiențe și erori.
7. Introducerea modificărilor și completărilor	Bug-urile sunt remediate, se fac modificări de proiectare sau de proces. Rezultatele corectate sunt oferite utilizatorilor pentru a lucra și a evalua.
8. Deciziile de implementare	Dacă rezultatele testului pilot satisfac utilizatorii, se ia decizia de a implementa sistemul.

3.2 Metodologia de implementare a aplicației

În această etapă, dezvoltatorul (sau echipa) implementează tehnologiile și componentele necesare soluției, proiectul trece la stadiul de întreținere și asistență, iar clientul îl aprobă în cele din urmă. După implementare, echipa evaluează proiectul și analizează utilizatorii pentru a-și determina satisfacția.

Obiective ale fazei de implementare:

¾  transferați soluția într-un mediu industrial;

¾  confirmarea de către client a finalizării proiectului.

Implementarea componentelor specifice site-ului constă în mai multe etape: pregătire, instalare, instruire și aprobare formală.

Rezultatele etapei de implementare a sistemului sunt sistemele de întreținere și suport, un depozit de documente unde se află toate versiunile de documente și cod dezvoltate în timpul proiectului.

Pentru a implementa sistemul în curs de dezvoltare, a fost întocmit un plan de acțiune, care este prezentat în Tabelul 3.1.

Tabelul 3.1 - Planul de implementare a aplicației

act	Descrierea acțiunii
1. Backup	Datele utilizatorului sunt copiate cu participarea și aprobarea sa prin transferul de informații pe suporturi amovibile (CD, DVD)
2. Instalarea componentelor de bază ale soluției	Utilizarea tehnologiilor care asigură funcționarea soluției. În acest caz, instalarea componentei Visual FoxPro
3. Instalarea aplicației client	Transfer pe computerul utilizatorului și instalarea versiunii finale a IS și a bazei de date dezvoltate
4. Instruire	Utilizatorii sunt instruiți să lucreze cu sistemul, dezvoltatorul este convins de corectitudinea și înțelegerea activității IP de către clienți
5. Transferul bazei de cunoștințe a proiectului către client	Toată documentația proiectului este predată clientului
6. Închiderea proiectului	Este pregătit un raport de închidere a proiectului. Clientul semnează certificatul de acceptare.

Pentru funcționarea normală a AWP, este necesar sistemul de operare Microsoft WindowsXP.

4 Managementul proiectului informațional

4.1 Alegerea unui ciclu de viață de dezvoltare

Unul dintre conceptele de bază ale metodologiei de proiectare IS este conceptul ciclului de viață al software-ului său (software-ul ciclului de viață). Software-ul pentru ciclul de viață este un proces continuu care începe din momentul în care se ia o decizie cu privire la necesitatea creării sale și se termină în momentul retragerii sale complete din serviciu.

Principalul document de reglementare care reglementează ciclul de viață al software-ului este standardul internațional ISO / IEC 12207 (ISO - Organizația Internațională de Standardizare - Organizația Internațională de Standardizare, IEC - Comisia Electrotehnică Internațională - Comisia Internațională de Inginerie Electrică). Acesta definește structura ciclului de viață, conținând procesele, acțiunile și sarcinile care trebuie efectuate în timpul creării software-ului.

ISO / IEC 12207 nu oferă un model specific al ciclului de viață și metode de dezvoltare software. Modelul ciclului de viață poate fi înțeles ca o structură care determină succesiunea execuției și interrelarea proceselor, acțiunilor și sarcinilor efectuate în timpul ciclului de viață. Modelul ciclului de viață depinde de specificul SI și de specificul condițiilor în care este creat și funcționează.

Astăzi există multe modele ale ciclului de viață al software-ului, dar cele mai populare și răspândite sunt două modele:

Model spiralat (vezi figura 4.1);

Model iterativ.

Figura 4.1 - Model spiralat al ciclului de viață al software-ului

Pentru a crea un sistem informațional, adică A fost ales „Locul de muncă automatizat al bazei angro a angajaților din depozit”, iterativ. O trăsătură distinctivă a modelului iterativ este că este o metodă formală, constă din faze independente, efectuate secvențial și este supusă unei revizuiri frecvente (Figura 4.2). Abordarea iterativă a funcționat bine pentru construirea IS-urilor, pentru care, chiar la începutul dezvoltării, toate cerințele pot fi formulate suficient de exact și complet pentru a le oferi dezvoltatorilor libertatea de a le implementa cât mai bine posibil din punct de vedere tehnic.

Avantajele modelului iterativ:

modelul este bine cunoscut consumatorilor non-software și utilizatorilor finali.

Confort și ușurință în utilizare, deoarece toate lucrările se execută în etape (în faze ale modelului);

Stabilitatea cerințelor;

Modelul este de înțeles;

Chiar și personalul slab instruit (utilizator neexperimentat) poate fi ghidat de structura modelului;

Modelul gestionează complexitatea într-o manieră ordonată și funcționează bine pentru proiecte care sunt rezonabil de înțeles;

Modelul facilitează implementarea unui control strict al managementului de proiect;

Facilitează sarcina managerului de proiect să planifice și să asambleze echipa de dezvoltare.

Figura 4.2 - Model iterativ al ciclului de viață al software-ului

Fazele modelului:

În etapa de analiză, acestea definesc funcțiile pe care ar trebui să le îndeplinească sistemul, evidențiază cele mai prioritare care necesită elaborarea în primul rând, descriu nevoile de informații;

În etapa de proiectare, procesele sistemului sunt luate în considerare mai detaliat. Modelul funcțional este analizat și, dacă este necesar, corectat. Se construiesc prototipuri de sistem;

Sistemul este dezvoltat în etapa de implementare;

În etapa de implementare, produsul finit este introdus în sistemul existent al organizației. Pregătirea utilizatorilor este în curs;

În etapa de întreținere, produsul software este întreținut (orice adăugare sau modificare pentru o funcționare mai funcțională a produsului).

Alegerea unui model de ciclu de viață de dezvoltare software este un pas important. Prin urmare, pentru un proiect, alegerea unui model de ciclu de viață al dezvoltării software-ului poate fi efectuată în timpul utilizării următoarelor procese.

Analiza categoriilor distinctive ale proiectului, plasate în tabele.

Răspundeți la întrebările pentru fiecare categorie, evidențiind cuvintele „da” și „nu”.

Clasificați în funcție de importanță categoriile sau întrebările legate de fiecare categorie în raport cu proiectul pentru care este selectat un model acceptabil.

Echipă de dezvoltare ... Pe baza posibilităților, selectarea personalului pentru echipa de dezvoltare are loc chiar înainte de momentul în care este ales modelul ciclului de viață al dezvoltării software-ului. Caracteristicile unei astfel de echipe (vezi Anexa G, Tabelul G.1) joacă un rol important în procesul de alegere a unui model de ciclu de viață, ceea ce înseamnă că echipa poate oferi asistență semnificativă în alegerea unui model de ciclu de viață al produsului software, deoarece este responsabilă pentru implementarea cu succes a modelului dezvoltat al ciclului de viață. ...

Echipa de utilizatori ... În etapele inițiale ale proiectului, puteți obține o imagine completă a echipei de utilizatori (a se vedea Anexa ȘI Tabelul I.1) care va lucra cu software-ul dezvoltat și relația sa viitoare cu echipa de dezvoltare pe tot parcursul proiectului. O astfel de viziune ajută la alegerea unui model adecvat, deoarece unele modele necesită o participare sporită a utilizatorului la dezvoltarea și studiul proiectului, deoarece cerințele pot fi ușor modificate de utilizator în timpul procesului de dezvoltare, atunci dezvoltatorul trebuie să cunoască aceste schimbări și cum să reprezinte aceste schimbări în software.

4.2 Determinarea scopului și sferei de aplicare a proiectului software

Produsul software dezvoltat pentru contabilitatea mărfurilor din depozit va automatiza procesul de primire, structurare și stocare a datelor despre mărfurile din depozit, precum și va simplifica procesul de emitere a rapoartelor.

Obiectivele proiectului software vor fi - crearea și implementarea unui sistem de contabilitate a mărfurilor. Acest sistem este destinat utilizării interne de către personalul Cleonelly, majoritatea angajați ai depozitului companiei.

Pentru a determina domeniul de aplicare al produsului software, va fi descris mai jos ce ar trebui sau nu un proiect software.

Proiectul software trebuie să fie:

Pentru uz intern într-o organizație;

Un proiect pentru implementarea accesului multi-utilizator;

Un proiect care are capacitatea de a introduce, modifica și stoca informații despre produsul companiei;

Un proiect care are capacitatea de a introduce, modifica și stoca informații despre utilizatorii sistemului;

Un proiect care are capacitatea de a introduce, modifica și stoca informații despre clienții și furnizorii organizației care fac obiectul tranzacțiilor care urmează să fie încheiate;

Un proiect care va realiza formarea raportării externe.

4.3 Crearea structurii listei de lucrări pas cu pas

Pentru a crea un produs sau serviciu unic (rezultatul proiectului), trebuie să efectuați o anumită secvență de lucru. Sarcina planificării proiectului este de a estima cu exactitate calendarul și costul acestor lucrări. Cu cât evaluarea este mai precisă, cu atât este mai bună calitatea planului de proiect. Pentru a oferi o evaluare exactă, trebuie să aveți o bună înțelegere a scopului proiectului, adică să știți ce fel de muncă trebuie efectuată pentru a obține rezultatul acestuia. Doar după întocmirea listei lucrărilor de proiectare, se estimează durata fiecăreia dintre ele și se alocă resursele necesare implementării lor. Și numai atunci puteți estima costul și calendarul fiecărei sarcini și, ca urmare a adăugării, costul total și durata proiectului. Acesta este motivul pentru care definirea sferei de lucru este primul pas în planificarea proiectului. Determinarea sferei lucrărilor de proiectare începe cu definirea etapelor (sau fazelor) proiectului. De exemplu, în proiectul de creare a unui sistem „Contabilitatea bunurilor în stoc” pot fi evidențiate următoarele faze:

Dezvoltarea cerințelor software;

Proiectare sistem informatic;

Implementarea și certificarea sistemului informațional;

Implementarea sistemului.

După ce sunt determinate compoziția fazelor și rezultatele acestora, este necesar să se determine succesiunea acestor faze una față de cealaltă și termenele limită pentru implementarea lor. Apoi, trebuie să determinați în ce lucrări constă fazele, în ce secvență sunt efectuate aceste lucrări și în ce termene trebuie să vă îndepliniți când sunt finalizate.

Lista de lucru pas cu pas (Figura 4.3) a fost concepută folosind un produs software, cum ar fi MS Project 2003.

Figura 4.3 - Lista pas cu pas a lucrărilor

4.4 Estimarea duratei și costului dezvoltării software-ului

Estimarea duratei. Se determină după construirea unei liste pas cu pas a lucrărilor (Figura 4.3, paragraful 4.3). Această durată estimată poate fi văzută folosind graficul Gantt (Anexa K).

Diagramele sunt un mijloc grafic de afișare a informațiilor conținute într-un fișier de proiect. Din diagrame, puteți obține o idee vizuală despre succesiunea sarcinilor, durata relativă a acestora și durata proiectului în ansamblu.

Diagrama Gantt este una dintre cele mai populare modalități de a reprezenta grafic un plan de proiect și este utilizată în multe programe de management de proiect.

În MS Project, graficul Gantt este principalul instrument de vizualizare pentru planul de proiect. Acest grafic este un grafic cu o cronologie orizontală și o listă verticală de sarcini. În acest caz, lungimea segmentelor care denotă sarcini este proporțională cu durata sarcinilor.

Pe graficul Gantt, informații suplimentare pot fi afișate lângă bare (lângă sarcini, sunt afișate numele resurselor implicate în acestea și încărcarea lor la finalizarea sarcinii).

Estimarea costurilor

Proiectul constă din sarcini , adică activități care vizează obținerea unui anumit rezultat. Pentru ca sarcina să fie finalizată, resurse .

O proprietate importantă a resurselor este costul (Cost) utilizării lor în proiect. Există două tipuri de costuri ale resurselor în MS Project: rata bazată pe timp și costul pe utilizare.

Rata bazată pe timp (Rata) este exprimată în costul utilizării resursei pe unitate de timp, de exemplu, 100 de ruble pe oră sau 1000 de ruble pe zi. În acest caz, costul participării resursei la proiect va fi timpul în care funcționează în proiect, înmulțit cu rata orară.

În acest caz, a fost utilizată rata bazată pe timp (Figura 4.4). Costul total al utilizării resurselor poate fi văzut în Figura 4.5.

Figura 4.4 - Rata de timp în utilizarea resurselor

În această figură, puteți vedea că dezvoltatorul de sistem primește 50 de ruble pe oră la executarea unui proiect; un analist de afaceri primește 45 de ruble pe oră, un tester 38 de ruble pe oră. Tarifele pentru ore suplimentare nu sunt incluse.

Figura 4.5 - Costurile totale ale utilizării resurselor proiectului

4.5 Alocarea resurselor proiectului

Un fragment al distribuției resurselor pentru sistemul „Contabilitate de inventar” poate fi văzut în Figura 4.6

Figura 4.6 - Un fragment al distribuției resurselor proiectului

Pentru fiecare lucrare efectuată în proiect, este asociată o resursă care va efectua această lucrare. Figura arată cantitatea totală de muncă pentru fiecare resursă și numărul specific de ore petrecute într-o anumită zi.

4.6 Evaluarea eficienței economice a proiectului

Calculul eficienței economice a proiectului este un pas important. Aici va fi calculată eficiența economică a proiectului. Acest calcul va arăta cât de profitabil este un proiect sau un proiect complet neprofitabil. La calcularea eficienței economice a proiectului, va fi necesar să se calculeze perioada de rambursare a proiectului. Perioada de rambursare va arăta perioada în care proiectul se va achita.

Date de intrare.

Profit suplimentar din implementarea proiectului (DP) \u003d 38.000 de ruble. Profitul suplimentar a fost prezis de experții companiei.

Investiția inițială (IC) \u003d 39396,47 ruble. Investițiile inițiale corespund costurilor totale ale utilizării resurselor proiectului (Figura 4.5, clauza 4.6)

Rata de reducere (i) \u003d 12%.

Perioada pentru care este proiectat proiectul (n) \u003d 2 ani.

Profit suplimentar din implementarea proiectului (DP) \u003d 38.000 de ruble.

Costuri anuale de implementare a proiectului (Z 1) \u003d 15.000 de ruble.

Costuri anuale de implementare a proiectului (Z 2) \u003d 10.000 de ruble.

Încasări anuale de numerar (R 1) \u003d 23.000 ruble.

Încasări anuale de numerar (R 2) \u003d 28.000 de ruble.

La evaluarea proiectelor de investiții, se utilizează metoda de calcul a valorii actuale nete, care prevede actualizarea fluxurilor de numerar: toate veniturile și costurile sunt aduse la un moment dat.

Indicatorul central al metodei luate în considerare este VAN (valoarea actuală netă) - valoarea actualizată a fluxurilor de numerar. Acesta este un rezultat final generalizat al activității de investiții în termeni absoluți.

Un punct important este alegerea ratei de actualizare, care ar trebui să reflecte rata medie de creditare așteptată pe piața financiară.

Valoarea actuală netă (VAN) este calculată utilizând formula 4.2

(4.2)

R k - încasări anuale de numerar pentru n ani.

k - numărul de ani pentru cât timp este proiectat proiectul.

IC - investiție inițială.

i - rata de reducere.

Conform calculelor acestei formule VAN \u003d 3.460,67 RUB

VAN este o creștere absolută, deoarece estimează cât de mult se suprapune venitul actual cu costurile actuale. Din moment ce NPV\u003e 0, proiectul ar trebui acceptat.

Rentabilitatea investiției (ROI) este calculată utilizând formula 4.3

(4.3)

Calculat (ROI) \u003d 108,78%

Tabelul 4.1 table Tabelul auxiliar pentru calcularea perioadei de rambursare a proiectului

= 1,84

Perioada de rambursare n ok \u003d 1,84 ani (1 an și 11 luni)

Din moment ce ROI \u003d\u003e 100% (și anume \u003d 108,78%), proiectul este considerat profitabil.

(4.4)

Astfel, indicele de rentabilitate este (PI) \u003d 1,2

Figura: 6.2.

(Sistem de informații pentru întreprinderi)

Externalizarea sistemelor informatice corporative

Externalizarea funcțiilor de producție și a proceselor de afaceri bazate pe sisteme de informații corporative permite utilizarea celor mai recente realizări și „cele mai bune practici” ale managementului modern. Implementarea sistemelor informatice corporative se află în centrul reingineriei proceselor de afaceri (Procesul de afaceri...
(Outsourcing și outstaffing: tehnologii de înaltă gestionare)

Modele de integrare a sistemelor informatice corporative

Modelele de integrare a sistemelor informatice reprezintă nivelul superior al clasificării modelelor de proiectare. În mod similar cu modelele nivelurilor inferioare de clasificare, un grup de modele structurale se distinge între modelele de integrare. Modelele structurale descriu principalele componente ale unui singur integrat ...
(Introducere în arhitectura software)

SARCINI FUNCȚIONALE ALE SISTEMULUI DE INFORMAȚIE AL ÎNTREPRINDERII ȘI MODULURILE DE BAZĂ A SISTEMELOR DE INFORMAȚIE MODERNE A ÎNTREPRINDERII. INTEGRAREA MODULELOR

Semnificația semnificativă a conceptului de modul presupune o comparație a subsistemelor funcționale, sarcini funcționale cu o abordare funcțională bazată pe sarcini cu principalele module ale modernului Figura: 6.2. Compararea sarcinilor funcționale cu principalele module ale sistemelor informatice moderne ICISP ale unei întreprinderi, ...
(Sistem de informații pentru întreprinderi)

CONCEPTUL, ISTORIA DEZVOLTĂRII ȘI CLASIFICAREA SISTEMELOR DE INFORMAȚIE A ÎNTREPRINDERII. SISTEME INTEGRATE DE INFORMAȚIE CORPORATIVĂ A ÎNTREPRINDERII

Conceptul și clasificarea sistemelor informaționale se schimbă pe parcursul dezvoltării lor istorice. Cu toate acestea, obiectivul rămâne constant și este asociat cu realizarea eficienței managementului întreprinderii. Eficiența managementului întreprinderii depinde de interacțiunea multor factori, printre care: filozofici, istorici, ...
(Sistem de informații pentru întreprinderi)

CARACTERISTICILE TEHNOLOGIILOR DE INFORMARE MODERNE ÎN SISTEMELE DE INFORMAȚIE A ÎNTREPRINDERII

TEHNOLOGII MODERNE DE ORGANIZARE A INTRĂRII DE DATE ÎN SISTEME DE INFORMARE CORPORATIVE Informațiile despre tranzacțiile comerciale trebuie introduse în timp util în baza de date operațională din orice sursă de origine. Acest lucru va organiza în mod eficient prelucrarea datelor în informații ...
(Sistem de informații pentru întreprinderi)

Pe baza scopului sistemului informațional în curs de dezvoltare, vom proiecta în continuare structura modulară a aplicației. Pentru a defini structura modulară, vom folosi diagrama componentă de notație UML 2.0 (Figura 3.4).

Figura: 3.4

Sistemul informațional este format din trei componente:

• 1. Interfață. Implementarea interacțiunii utilizatorului cu sistemul informațional. Conține următoarele module:
  • · Intrare / ieșire - organizarea intrării și ieșirii informațiilor atunci când se lucrează cu IS;
  • · Raportare - organizarea raportării în conformitate cu formele de documentare stabilite pentru diverse domenii ale agenției de personal;
  • · Căutare - organizarea căutării candidaților și posturilor vacante în funcție de parametrii specificați;
• 2. Prelucrarea datelor. Implementarea funcțiilor de prelucrare a informațiilor: căutarea datelor într-o bază de date, un model matematic pentru sarcina de analiză primară a documentelor etc;
• 3. DB. O implementare a unui magazin de date care conține informații despre clienți.

Proiectarea structurii bazei de date

După cum sa menționat anterior, în sistemul informațional, toate informațiile sunt stocate într-o singură bază de date. Metodologia IDEF1x a fost aplicată pentru a modela structura logică a bazei de date. Conform acestei metodologii, procesul de construire a unui model informațional constă din următorii pași:

• · Definiția entităților; definirea dependențelor între entități;
• · Alocarea cheilor primare și alternative;
• · Definirea atributelor entităților;
• · Aducerea modelului la nivelul necesar de formă normală;
• · Trecerea la descrierea fizică a modelului: atribuirea corespondențelor nume entitate - nume tabel, atribut entitate - atribut tabel;
• · Alocarea declanșatorilor, procedurilor și restricțiilor;
• · Generarea bazei de date.

Diagrama entitate-relație care descrie baza de date în termeni de IDEF1.x este construită din trei blocuri principale - entități, atribute și relații. Dacă considerăm diagrama ca o reprezentare grafică a regulilor domeniului, atunci entitățile și atributele sunt substantive, iar legăturile sunt verbe.

Deoarece viitorul IS pentru această bază de date va căuta, următoarele au fost selectate ca atribute principale pentru document:

• - numele documentului;
• - data primirii documentului în arhivă (firmele de avocatură care furnizează servicii de arhivare monitorizează perioada de stocare a documentației. Fiecare document are propria perioadă de stocare. Multe valori mobiliare își pierd relevanța în timp, iar valoarea lor este redusă la zero. Astfel de documente ar trebui distruse. Selecția la timp a acestor hârtii și distrugerea documentelor este inclusă în pachetul de servicii de arhivare furnizate de firmele de avocatură. La acceptarea pentru depozitare, fiecare document, după o examinare specială, este determinat de perioada de depozitare. După această perioadă, documentul este supus distrugerii);
• - identitatea (tipul) documentului (întrucât toate documentele au fost împărțite în 7 tipuri, pentru care clasarea a fost făcută în funcție de importanță);
• -număr coloană;
• - numărul raftului;
• - numărul de sanie (acești 3 parametri sunt necesari pentru a determina locația documentului în arhivă);
• - prezența unui document în celula sa (trebuie să știți dacă documentul este în arhivă sau a fost emis solicitantului).

Rezultatul unei interogări pentru selectarea tuturor documentelor aparținând unui singur client ar trebui să arate după cum urmează, a se vedea Figura 3.5. În exemplul prezentat, numărul de documente a fost limitat în mod intenționat la 20.

Acum să analizăm mai detaliat modelul de date logice al sistemului informațional în curs de dezvoltare, prezentat în Figura 3.6.

Figura: 3.5

Figura: 3.6

Din modelul de date prezentat, se poate vedea că conține trei entități, fiecare cu propriul set de atribute, iar două dintre ele sunt dependente, iar una nu.

Entitatea „Angajat”, care este o entitate independentă, are următoarele atribute:

• · Numărul de identificare a angajaților - este cheia principală a acestei entități;
• · Numele complet al angajatului;
• · Domeniul de specializare;
• · Evaluare;
• · Informatii suplimentare.

Entitatea Client este o entitate dependentă de entitatea Angajat, ceea ce înseamnă că fiecare angajat poate deservi mulți clienți. Entitatea client are atribute:

• · Seria și numărul pașaportului - este cheia principală a acestei entități;
• · Numărul de identificare a angajaților - este cheia secundară a acestei entități;
• · Numele complet al angajatului;
• · Domeniul de specializare;
• · Evaluare;
• · Informatii suplimentare.

Entitatea „Document” este o entitate dependentă de entitatea „Client”, ceea ce înseamnă că fiecare client poate stoca multe documente diferite în arhivă. Entitatea document are atribute:

• · Identificatorul documentului - este cheia principală a acestei entități;
• · Seria și numărul pașaportului - este cheia secundară a acestei entități;
• · Numele documentului;
• · Data primirii;
• · Apartenența la un grup;
• · Număr coloană;
• · Numărul raftului;
• · Numărul de sanie;
• · Prezența documentului în celulă.

Elementele care asigură funcționarea IS în orice scop sunt enumerate în definiție. Unele dintre ele - mijloace, metode și personal - asigură funcționarea IS, în timp ce altele - stocarea, prelucrarea și emiterea informațiilor - indică caracteristici funcționale, adică stabiliți din ce procese informaționale este alcătuită funcționarea SI. Prin urmare, structura SI este considerată în două moduri diferite: structura funcțională și structura SI ca un set de subsisteme suport.

În conformitate cu definiția, elementele funcționale ale IS sunt următoarele grupuri (blocuri) de procese:

introducerea de informații din surse externe sau interne;

prelucrarea informațiilor de intrare și prezentarea acestora într-o formă convenabilă;

ieșirea de informații pentru prezentare către consumatori sau transfer către un alt SI;

feedback-ul este informație procesată de oamenii unei organizații date pentru a corecta informațiile de intrare.

Structură funcțională sistemul informațional este prezentat sub forma unei diagrame bloc (Fig. 1), în care fiecare element al sistemului este reprezentat sub forma unui bloc (în Fig. - un dreptunghi), iar legăturile și direcțiile lor sunt indicate prin săgeți.

Părțile individuale (blocuri de sistem) se numesc subsisteme.

În fiecare caz specific, setul și relațiile dintre subsistemele funcționale depind de aria subiectului și de specificul întreprinderii, a cărei activitate este asigurată de sistemul informațional.

Structura SI poate fi reprezentată și ca un complex de subsisteme de susținere (Fig. 2).

Fig. 1. Diagrama bloc IC funcțional generalizată.

Cu toate acestea, pentru AIS, care diferă prin natura și tipurile de procesare a informațiilor, diagrama funcțională diferă într-un set de subsisteme de procesare. De exemplu, AIPS (bibliotecă, muzeu, referință legală etc.) produce introducere, sistematizare, stocare, căutare și livrare de informații la cererea utilizatorului fără transformări complexe de date. Sisteme decisive pentru informații: ASOD, ACS, DSS - procesează informațiile bazei de date în conformitate cu un anumit algoritm, totuși, ele diferă și prin compoziția subsistemelor de procesare a informațiilor. Un sistem CAD specializat în automatizarea proiectării are în structura sa subsisteme speciale: documentație tehnică, formarea sarcinilor, simulare, calcul și, în unele, poate exista un sistem expert (vezi diagrama bloc din Fig. 2).

Fig. 2. Diagrama bloc CAD

Luați în considerare un alt tip de structură IS: ca un complex de subsisteme de susținere (Fig. 3).

Structura unui sistem informațional poate fi considerată ca un set de subsisteme, indiferent de domeniul de aplicare. Un subsistem este o parte a unui sistem care se distinge în funcție de un anumit atribut. În acest caz, vorbim despre o trăsătură structurală a clasificării, iar subsistemele sunt numite furnizare.

Astfel, structura oricărui sistem informațional poate fi reprezentată de un set de subsisteme suport.

Fig. 3. Structura IS după tipul de subsisteme suport.

Informațiile, asistența tehnică, matematică, software, organizațională și juridică se disting de obicei între subsistemele de sprijin.

Suport informațional - un set de seturi de date informaționale, un sistem unificat de clasificare și codificare a informațiilor, sisteme unificate de documentare, scheme de fluxuri de informații care circulă într-o organizație, precum și o metodologie pentru construirea bazelor de date. Scopul subsistemului de asistență a informațiilor este formarea și furnizarea la timp a informațiilor fiabile pentru luarea deciziilor manageriale.

Sisteme de documentare unificate sunt create la nivel de stat, republican, sectorial și regional. Scopul principal este de a asigura comparabilitatea indicatorilor diferitelor sfere ale producției sociale. Au fost elaborate standarde acolo unde sunt stabilite cerințele:

la sisteme de documentare unificate;

la forme unificate de documente de diferite niveluri de management;

la compoziția și structura detaliilor și indicatorilor;

la procedura de implementare, întreținere și înregistrare a formularelor unificate de documente.

În ciuda existenței unui sistem de documentare unificat, un sondaj al majorității organizațiilor relevă un set întreg de neajunsuri tipice:

volum extrem de mare de documente pentru prelucrarea manuală;

aceiași indicatori sunt adesea duplicați în documente diferite;

lucrul cu un număr mare de documente distrage atenția specialiștilor de la rezolvarea problemelor imediate;

există indicatori care sunt creați dar nu utilizați etc.

Eliminarea acestor neajunsuri este una dintre sarcinile cu care se confruntă crearea suportului informațional.

Diagramele fluxului informațional reflectă rutele de mișcare a informațiilor, volumele sale, locurile de origine ale informațiilor primare și utilizarea informațiilor rezultate. Analizând structura unor astfel de scheme, este posibil să se dezvolte măsuri pentru îmbunătățirea întregului sistem de management.

Construcția și analiza detaliată a schemelor de flux de informații care permit identificarea rutelor și volumelor de informații, duplicarea indicatorilor și procesele de procesare a acestora, oferă:

eliminarea informațiilor duplicate și neutilizate;

clasificarea și prezentarea rațională a informațiilor.

Metodologia construirii bazei de date pe baza fundamentelor teoretice ale proiectării lor.

Concepte de bază ale metodologiei:

o înțelegere clară a obiectivelor, obiectivelor, funcțiilor întregului sistem de management al organizației;

identificarea mișcării informațiilor din momentul originii sale până la utilizarea sa la diferite niveluri de management, prezentate pentru analiză sub formă de scheme de flux de informații;

îmbunătățirea sistemului de gestionare a documentelor;

disponibilitatea și utilizarea unui sistem de clasificare și codificare;

cunoașterea metodologiei de creare a unor modele logice informaționale conceptuale care reflectă relația informației;

crearea de matrice de informații pe suporturi informatice, care necesită suport tehnic modern.

Acest concept este practic implementat în două etape.

Prima etapă - examinarea tuturor diviziilor funcționale ale companiei pentru a:

să înțeleagă specificul și structura activităților sale;

construiți o diagramă a fluxurilor de informații;

analizează sistemul de gestionare a documentelor existent;

să definească obiectele informaționale și compoziția corespunzătoare a atributelor (parametri, caracteristici) care descriu proprietățile și scopul acestora.

Etapa a 2-a - construirea unui model conceptual de date logice de informații bazat pe rezultatele sondajului etapei 1. În acest model, toate conexiunile dintre obiecte și atributele acestora trebuie stabilite și optimizate. Modelul informațional-logic este fundamentul pe care va fi creată baza de date.

Suport tehnic - un set de mijloace tehnice destinate funcționării sistemului informațional, precum și documentația corespunzătoare pentru aceste mijloace și procese tehnologice

Complexul de mijloace tehnice constă din:

calculatoare de orice model;

dispozitive pentru colectarea, acumularea, procesarea, transmiterea și difuzarea informațiilor;

dispozitive de transmisie de date și linii de comunicații;

echipamente de birou și dispozitive pentru regăsirea automată a informațiilor;

materiale de operare etc.

Documentația oficializează selectarea preliminară a mijloacelor tehnice, organizarea funcționării acestora, procesul tehnologic de prelucrare a datelor, echipamentele tehnologice. Documentația poate fi aproximativ împărțită în trei grupe:

la nivel de sistem, inclusiv standarde de stat și de industrie pentru asistență tehnică;

specializate, care conțin un set de metode pentru toate etapele de dezvoltare a suportului tehnic;

referință normativă, utilizată la efectuarea calculelor pentru asistență tehnică.

Până în prezent, există două forme principale de organizare a suportului tehnic (forme de utilizare a mijloacelor tehnice): centralizat și parțial sau complet descentralizat.

Asistența tehnică centralizată se bazează pe utilizarea computerelor mari și a centrelor de calcul în sistemul informațional. Această formă de organizare facilitează gestionarea și implementarea standardizării, dar reduce responsabilitatea și inițiativa personalului.

Descentralizarea mijloacelor tehnice implică implementarea subsistemelor funcționale pe computerele personale direct la locurile de muncă. În acest caz, este necesară o responsabilitate personală mai mare din partea personalului, managementul este mai dificil să implementeze standardizarea.

În prezent, o abordare parțial descentralizată este mai răspândită - organizarea suportului tehnic bazat pe rețele distribuite formate din computere personale și un mainframe pentru stocarea bazelor de date comune oricărui subsistem funcțional.

Matematică și software - un set de metode matematice, modele, algoritmi și programe pentru implementarea obiectivelor și obiectivelor sistemului informațional, precum și funcționarea normală a complexului de mijloace tehnice.

La fonduri software raporta:

instrumente pentru modelarea proceselor de management;

sarcini tipice de management;

metode de programare matematică, statistici matematice, teoria cozilor etc.

Parte software include produse software la nivel de sistem și speciale, precum și documentație tehnică.

LA software la nivel de sistem include complexe de programe destinate utilizatorilor și concepute pentru a rezolva problemele tipice de prelucrare a informațiilor. Acestea servesc la extinderea funcționalității computerelor, controlul și gestionarea procesului de prelucrare a datelor.

Software special este un set de programe dezvoltate la crearea unui sistem informațional specific. Include pachete de aplicații software (APP) care implementează modele dezvoltate de diferite grade de adecvare, reflectând funcționarea unui obiect real.

Documentația tehnică pentru dezvoltarea software-ului ar trebui să conțină o descriere a sarcinilor, sarcina de algoritmizare, modelul economic și matematic al problemei, exemple de testare.

Sprijin organizațional Este un set de metode și mijloace care reglementează interacțiunea lucrătorilor cu mijloacele tehnice și între ei în procesul de dezvoltare și operare a SI.

Suportul organizațional implementează următoarele funcții:

analiza sistemului de management existent al organizației, unde va fi utilizat IS, și identificarea sarcinilor care vor fi automatizate;

pregătirea sarcinilor pentru rezolvarea pe computer, inclusiv specificații tehnice pentru proiectarea SI și un studiu de fezabilitate a eficacității acestuia;

elaborarea deciziilor de management privind compoziția și structura organizației, metodologia de rezolvare a problemelor care vizează îmbunătățirea eficienței sistemului de management.

Sprijinul organizațional este creat în conformitate cu rezultatele sondajului de pre-proiect, în prima etapă a construirii bazei de date.

Sprijin legal - un set de norme juridice care determină crearea, statutul juridic și funcționarea sistemelor informaționale, care reglementează procedura de obținere, transformare și utilizare a informațiilor.

Scopul principal al sprijinului legal este consolidarea statului de drept. Cadrul legal include legi, decrete, decizii ale autorităților de stat, ordine, instrucțiuni și alte documente normative ale ministerelor, departamentelor, organizațiilor, autorităților locale. În sprijinul juridic, se poate distinge o parte generală care reglementează funcționarea oricărui sistem informațional și o parte locală care reglementează funcționarea unui sistem specific.

Sprijinul juridic al etapelor de dezvoltare a unui sistem informațional include reglementări legate de relația contractuală dintre dezvoltator și client și reglementarea legală a abaterilor de la contract.

Asistența juridică a etapelor funcționării sistemului informațional include:

starea sistemului informațional;

drepturile, îndatoririle și responsabilitățile personalului;

procedura de creare și utilizare a informațiilor etc.

Acest set de subsisteme este general pentru aproape toate tipurile de AIS. Cu toate acestea, structura și complexitatea subsistemelor de sprijin depind de tipul AIS, domeniul de aplicare și alți factori. Deci, subsistemul de asistență matematică are loc în AIS al dezvoltării software originale - în AIS cu software standard, este absent. Subsistemul de asistență juridică poate fi absent în AIS în scopuri intra-companie - în acest caz, este posibil să ne limităm la subsistemul de asistență organizațională, în care, printre altele, sunt rezolvate problemele asistenței juridice; AIS în scopuri independente, de exemplu, sistemele de servicii de informații, poate avea un subsistem de asistență juridică. AIS, care au o bază de date reală, au doar un subsistem de suport informațional, în care poate fi necesar să se rezolve anumite probleme lingvistice. Documentele AIPS au un subsistem dezvoltat de suport lingvistic, deoarece aceste sisteme rezolvă probleme complexe de asigurare a relevanței semantice a cererilor utilizatorilor față de conținutul documentelor emise. Și aceasta, de regulă, nu este doar module software de analiză morfologică, ci și un set de dicționare și reguli pentru întreținerea lor.

Obiectivele creării și implementării IP.

Ce se poate aștepta de la implementarea sistemelor informatice?

Implementarea sistemelor informatice poate contribui la:

1. eliberarea lucrătorilor de munca de rutină și accelerarea acesteia datorită automatizării;

2. înlocuirea suporturilor de date pe hârtie cu discuri magnetice sau benzi, ceea ce duce la o scădere a volumului de documente pe hârtie și, prin urmare, posibilitatea unei organizări mai raționale a procesării informațiilor pe un computer;

3. îmbunătățirea structurii fluxurilor de informații și a sistemului de gestionare a documentelor din companie datorită efectului coerenței: introducere unică de date - utilizare multiplă și multifuncțională ";

4. obținerea unor opțiuni mai raționale pentru rezolvarea problemelor de management (prin introducerea de metode matematice și sisteme inteligente etc.):

găsirea de noi nișe de piață;

optimizarea costurilor pentru producția de produse și / sau servicii;

optimizarea relațiilor cu clienții și furnizorii.

Etapele dezvoltării sistemelor informatice

Istoria dezvoltării IP este împărțită în etape (Tabelul 2), care corespund aproximativ numerotării acceptate a obiectivelor - abordarea utilizării IP se schimbă.

Tabelul 2. Etapele dezvoltării IP.

Perioada de timp	Conceptul de utilizare a informațiilor	Tipul sistemelor informaționale	Scopul utilizării
1950 - 1960	Fluxul de hârtie al documentelor de decontare	Sisteme informatice pentru prelucrarea documentelor de decontare pe aparatele de contabilitate electromecanică	Creșterea vitezei de procesare a documentelor Prelucrarea simplificată a facturilor și prelucrarea salarizării
1960 - 1970	Ajutor de bază în pregătirea rapoartelor	Sisteme informaționale de management pentru informații de producție	Accelerarea procesului de raportare
1970 - 1980	Controlul managementului implementării (vânzări)	Sisteme de susținere a deciziilor Sisteme pentru conducerea superioară	Selectarea celei mai raționale soluții
1980 - 2000	Informația este o resursă strategică care oferă un avantaj competitiv	Sisteme strategice de informare Birouri automate	Supraviețuire fermă și prosperitate

Primele sisteme informaționale au apărut la mijlocul secolului trecut. În anii 1950, au fost concepute pentru procesarea facturilor și calcularea salariilor și au fost implementate pe mașini de contabilitate electromecanică. Acest lucru a dus la o oarecare reducere a costurilor și a timpului pentru pregătirea documentelor pe hârtie.

Anii '60 sunt marcate de o schimbare de atitudine față de sistemele informaționale. Informațiile obținute de la acestea au început să fie utilizate pentru raportarea periodică în multe moduri. În acea zi, organizațiile aveau nevoie de echipamente informatice de uz general capabile să îndeplinească mai multe funcții și nu doar să proceseze facturi și să calculeze salariile, așa cum era înainte.

În anii '70 - începutul anilor '80. sistemele informaționale încep să fie utilizate pe scară largă ca mijloc de control al managementului care susține și accelerează procesul decizional.

Până la sfârșitul anilor 80. conceptul de utilizare a sistemelor informatice se schimbă din nou. Devin o sursă strategică de informații și sunt utilizate la toate nivelurile unei organizații de orice profil. Sistemele informaționale din această perioadă, oferind informațiile necesare la timp, ajută organizația să obțină succes în activitățile sale, să creeze noi produse și servicii, să găsească noi piețe de vânzare, să ofere parteneri demni pentru sine, să organizeze lansarea produselor la un preț scăzut și multe altele.

Înțelegerea modernă a sistemului informațional implică utilizarea unui computer personal ca principal mijloc tehnic de prelucrare a informațiilor. În organizațiile mari, împreună cu un computer personal, baza tehnică a unui sistem informațional poate include un mainframe sau un supercomputer. În plus, implementarea tehnică a sistemului informațional în sine nu va însemna nimic dacă nu se ia în considerare rolul persoanei căreia îi sunt destinate informațiile și fără de care este imposibil să le primească și să le prezinte.