Diagrama Gantt

Diagrama Gantt

Diagrama este numita dupa Henry Gantt (1861-1919), care a proiectat graficul în jurul anilor 1910-1915.

Inițial diagramele Gantt au fost executate de mână; de fiecare dată când un proiect se schimba a fost necesar să se modifice diagrama acest lucru a limitat utilitatea lor, schimbarea continuă ar fi o caracteristică a majorității proiectelor. În zilele noastre, odată cu apariția computerelor și software-ului , diagramele Gantt pot fi create, actualizate și imprimate ușor.

Astăzi, diagramele Gantt sunt cel mai frecvent utilizate. O diagramă Gantt este construită cu o axă orizontală care reprezintă intervalul de timp total al proiectului, structurat în trepte (de exemplu, zile, săptămâni, luni ) și o axă verticală care reprezintă sarcinile care alcătuiesc proiectul. Bara orizontală de diferite lungimi arată secvențe, calendarul, și intervalul de timp pentru fiecare activitate. Deschiderile barelor se pot suprapune, ca, de exemplu, desfasurarea activității de cercetare prin alegerea softwar-ului în același interval de timp. Pe măsură ce proiectul avansează, se pot adăuga bare, vârfuri de săgeți, sau bare secundare întunecate pentru a indica sarcinile finalizate, sau porțiunile de sarcini care au fost finalizate. O linie verticală este folosită pentru a reprezenta data raportului.

Diagramele Automat Gantt stocheaza mai multe informații despre sarcini, cum ar fi persoanele atribuite sarcinilor specifice, și notele cu privire la proceduri. Acestea oferă, de asemenea, avantajul de a fi ușor de a schimba, ceea ce este de ajutor. Diagramele pot fi ajustate în mod frecvent pentru a reflecta starea reală a sarcinilor de proiect deoarece, aproape inevitabil, ele diferă de la planul inițial.

SSADM – "Analiza Sistemelor structurate și metoda de proiectare"

SSADM este o metodă cascadă pentru analiza și proiectarea sistemelor informatice. Numele "Analiza Sistemelor structurate și metoda de proiectare" și "SSADM" sunt mărci înregistrate ale Oficiului Guvernului Comerț (OGC), care este un birou al Trezoreriei Regatului Unit înregistrat.

Cele mai importante trei tehnicicele care sunt utilizate în SSADM sunt după cum urmează:

Modelarea datelor logice

Procesul de identificare, modelare și documentare a cerințelor de date ale sistemului de a fi proiectat. Rezultatul este un model de date care conține entități (lucruri despre care o afacere are nevoie pentru a înregistra informații), atributele (fapte despre entitățile) și relații (asociații între entități).

Modelarea fluxulului de date

Procesul de identificare, modelare și documentare despre modul de mutare a datelor în jurul unui sistem de informare. Modelarea fluxului de date examinează procese (activități care transformă datele de la o formă la alta), depozite de date (domeniile care dețin date), entități externe (ce trimite date într-un sistem sau primesc date de la un sistem), și fluxurile de date (rutele pe care datele le pot curge).

Modelarea entitate Eveniment

Un proces cu două irecuperabile-: Entitate Behavior Modeling, identificarea, modelarea și documentarea evenimentelor care afectează fiecare entitate și secvența (sau antecedente de viata), în care au loc aceste evenimente, și proiectare pentru fiecare eveniment a procesului de coordonare a istoriilor de viață a entitatii .

O abordare metodologică de a studia o afacere (sau o zonă a unei afaceri) dintr-un număr de diferite perspective este mult mai probabil de a oferi o înțelegere mai aprofundată a activității, procesele și datele sale, decât "ad-hoc" abordări care au fost folosite anterior. Acest lucru, la rândul său ar trebui să conducă la sisteme care sunt mai complete și corecte.

ETAPE:

Etapa 0 – Studiul de fezabilitate

Pentru a stabili dacă este sau nu un anumit proiect este fezabil, trebuie să existe o formă de anchetă în obiectivele și implicațiile proiectului. Pentru proiecte la scară foarte mici acest lucru poate să nu fie necesară deloc ca domeniul de aplicare al proiectului este ușor de înțeles. În proiecte mari, fezabilitatea se poate face, dar într-un sens informal, fie pentru că nu există timp pentru un studiu formal sau că proiectul este un "must-have" și va trebui să se facă într-un fel sau altul.

Atunci când un studiu de fezabilitate se realizează, există patru domenii principale care se au în vedere:

Tehnic – este proiectul tehnic posibil?

Financiar – poate afacerea sa permită realizarea proiectului?

Organizațional – noul sistem va fi compatibil cu practicile existente?

Etic – este impactul noului sistem social acceptabil?

Pentru a răspunde la aceste întrebări, studiul de fezabilitate este în mod efectiv o versiune condensată a unei analize a sistemelor. Cerințele și utilizatorii sunt analizate cu o anumită măsură, unele opțiuni de afaceri sunt elaborate și chiar unele detalii de implementare tehnică. Produsul acestei etape este un document oficial al studiului de fezabilitate. SSADM specifică că studiul ar trebui să conțină inclusiv modele preliminare care au fost construite și, de asemenea, detalii despre opțiuni respinse și motivele respingerii lor.

Etapa 1 – Investigarea mediului actual

Dezvoltatorii de SSADM înțeleg că, în aproape toate cazurile există o formă a sistemului , chiar dacă aceasta este compusa în întregime din oameni și hârtie. Printr-o combinație de intervievare a angajaților, chestionare, observații din circulatia documentelor existente, analistul ajunge la înțelegerea deplină a sistemului, deoarece este la începutul proiectului.

Etapa 2 – Opțiunile sistemului de afaceri

După investigarea sistemului actual, analistul trebuie să se decidă cu privire la proiectul de ansamblu al noului sistem. Pentru a face acest lucru, el sau ea, folosind rezultatele etapei anterioare, dezvoltă un set de opțiuni ale sistemului de afaceri. Acestea sunt moduri diferite în care noul sistem ar putea fi produs variind de la a face nimic pentru a arunca vechiul sistem în întregime și construirea unuia cu totul nou. Analistul poate organiza o sesiune de brainstorming, astfel încât cât sa poata fi generate cat mai multe idei diferite.

Ideile sunt apoi colectate de opțiuni care sunt prezentate utilizatorului. Opțiunile pot lua în considerare următoarele:

gradul de automatizare

granița dintre sistem și utilizatori

distribuția sistemului

cost / beneficiu

Impactul noului system

În cazul în care este necesar, opțiunea va fi documentată cu o structură de date logică și o diagramă de nivel 1 a fluxului de date.

Utilizatorii și analistul împreună aleg o opțiune de afaceri unică. Aceasta poate fi una dintre cele deja definite sau poate fi o sinteză a diferitelor aspecte ale opțiunilor existente. Ieșirea din această etapă este opțiunea de afaceri unică selectate împreună cu toate rezultatele etapei de fezabilitate.

Etapa 3 – Cerințe specifice

Aceasta este, probabil, etapa cea mai complexă în SSADM. Utilizând cerințele elaborate în etapa 1 și de lucru, în cadrul opțiunii de afaceri selectate, analistul trebuie să dezvolte o specificație logica deplină a ceea ce noul sistem trebuie să facă. Specificația trebuie să fie lipsită de erori, ambiguitate și inconsecvență. Logic se înțelege că specificațiile nu spun cum va fi implementat sistemul, ci descrie ceea ce va face sistemul.

Pentru a produce caietul de sarcini logic, analistul construieste modele logice necesare atât pentru diagramele de flux de date (DFDS) si modelul de date logice (LDM), format din structura de date logice (menționată la alte metode ca diagrame de relații entitate) și descrieri complete ale datelor și relațiile sale. Acestea sunt folosite pentru a produce definiții pentru fiecare functie pe care utilizatorii o vor necesita în sistemul, entitatea Life-Istorii (ELHs), care descrie toate evenimentele din viața unei entități, și effect-Corespondența diagramei (ECDs), care descriu modul în care fiecare eveniment interacționează cu toate entitățile relevante. Acestea sunt continuu comparate cu cerințele și, după caz, cerințele sunt adăugate și completate.

Produsul acestei etape este un document complet care este alcătuit din:

Catalogul actualizat de date

Catalogul actualizat cerințe

caietul de sarcini de prelucrare care la rândul său este alcătuit din

Rolul de utilizator / matrice funcție

Definitii funcții

modelul de date logic necesar

istoriile de viață- entitate

diagrame effect-corespondență

Etapa 4 – opțiunile sistemului tehnic

Această etapă este prima către o implementare fizică a noului sistem. Ca și Opțiuni de sistem de afaceri, în acest stadiu sunt generate un număr mare de opțiuni pentru punerea în aplicare a noului sistem. Acest lucru este redus până la două sau trei pentru a prezenta utilizatorului care opțiune finală este aleasă sau sintetizata.

Cu toate acestea, considerațiile sunt destul de diferite fiind:

arhitecturile hardware

software-ul pentru a utiliza

Costul implementării

personalul necesar

limite fizice

Toate aceste aspecte trebuie, de asemenea, să respecte orice constrângeri impuse de afaceri, cum ar fi standardizarea hardware și software.

Etapa 5 – construcție ergonomică

Deși nivelul anterior precizează detaliile implementării, rezultatele acestei etape sunt de punere în aplicare independenta și să se concentreze pe cerințele pentru interfața calculatorului uman. Construcție ergonomică specifică principalele metode de interacțiune în ceea ce privește structurile de meniu și structurile de comandă.

Un domeniu de activitate este definiția dialogurilor utilizatorilor. Acestea sunt principalele interfețe cu care utilizatorii vor interacționa cu sistemul. Alte activități, sunt preocupați de analiza efectelor evenimentelor în actualizarea sistemului și necesitatea de a face anchete cu privire la datele de pe sistem. Ambele folosesc evenimente, descrieri de funcții și diagramele effect-corespondență produse în etapa 3 a determinarii cu exactitate cum să actualizeze și să citească datele într-un mod consistent și sigur.

Produsul acestei etape este de proiectare ergonomică care este alcătuit din:

Catalog de date

Stresul si momentul de îndoire.

Etapa 6 – proiectare fizică

Aceasta este etapa finală în care toate specificațiile logice ale sistemului sunt convertite în descrieri ale sistemului din punct de vedere de la Real hardware și software. Aceasta este o etapă foarte tehnica și cu o privire de ansamblu prezentata simplu aici.

Structura de date logică este transformată într-o arhitectură fizică a structurilor de baze de date. Este specificată structura exactă a funcțiilor și modul în care acestea sunt puse în aplicare. Structura de date fizică este optimizata în cazul în care este necesar pentru a îndeplini dimensiunea și performanța cerințelor.

Produsul este un design fizic complet, care ar putea spune inginerilor de software cum să construiască sistemul detalii specifice de hardware și software la standardele corespunzătoare.