Diagrama Idef0 folosind un joc pe calculator ca exemplu. Reguli pentru denumirea elementelor de control și a blocurilor. A63 Diagrama fluxului de date

Metodologia IDEF0

Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor sistemului. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii sale cu lumea exterioară (diagrama de context), după care se efectuează o descompunere funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris separat (diagrame de descompunere) . Apoi fiecare subsistem este împărțit în altele mai mici și așa mai departe până când se atinge nivelul dorit de detaliu.

Fiecare Diagramele IDEF0A conţine blocuri şi arce. Blocurile descriu funcțiile sistemului modelat. Arcurile leagă blocurile între ele și reprezintă interacțiunile și relațiile dintre ele.

Blocurile funcționale (lucrul) din diagrame sunt reprezentate prin dreptunghiuri, reprezentând procese, funcții sau sarcini numite care apar într-o perioadă de timp și au rezultate recunoscute. Numele lucrării trebuie exprimat ca un substantiv verbal care denotă acțiunea.

IDEF0 necesită ca diagrama să aibă cel puțin trei și nu mai mult de șase blocuri. Aceste constrângeri mențin complexitatea diagramelor și a modelului la un nivel care este lizibil, înțeles și utilizabil.

Fiecare parte a blocului are un scop special, foarte specific. Partea stângă a blocului este pentru intrări, partea de sus este pentru control, dreapta este pentru ieșiri, iar partea de jos este pentru mecanisme. Această desemnare reflectă anumite principii de sistem: intrările sunt convertite în ieșiri, limitele de control sau prescriu condițiile pentru efectuarea transformărilor, mecanismele arată ce și cum funcționează o funcție.

Blocurile din IDEF0 sunt plasate în ordinea importanței, așa cum a înțeles autorul diagramei. Această ordine relativă se numește dominanță. Dominanța este înțeleasă ca influența pe care o are un bloc asupra altor blocuri din diagramă. De exemplu, cel mai dominant bloc al diagramei poate fi fie primul dintr-o succesiune de funcții cerute, fie o funcție de planificare sau control care le influențează pe toate celelalte.

Blocul cel mai dominant este de obicei plasat în colțul din stânga sus al diagramei, iar cel mai puțin dominant este în colțul din dreapta.

Dispunerea blocurilor pe pagină reflectă definiția autorului a dominației. Astfel, topologia diagramei arată care caracteristici au un impact mai mare asupra altora. Pentru a sublinia acest lucru, analistul poate renumerota blocurile în funcție de ordinea lor de dominanță. Ordinea dominantei poate fi indicata printr-un numar plasat in coltul din dreapta jos al fiecarui dreptunghi: 1 ar indica cea mai mare dominatie, 2 urmatorul etc.

Interacțiunea lucrărilor cu lumea exterioară și între ele este descrisă sub formă de săgeți, reprezentate ca linii unice cu săgeți la capete. Săgețile reprezintă unele informații și se numesc substantive.

IDEF0 distinge între cinci tipuri de săgeți.

Intrare- obiecte folosite și transformate prin muncă pentru a obține un rezultat (ieșire). Este permis ca lucrarea să nu aibă o singură săgeată de intrare. Săgeata de intrare este desenată ca intrând în marginea stângă a lucrării.

Control-.informaţii care controlează acţiunile lucrării. De obicei, săgețile de control poartă informații care indică ceea ce ar trebui să facă un loc de muncă. Fiecare job trebuie să aibă cel puțin o săgeată de control, care este descrisă ca intrând în marginea superioară a jobului.

Ieșire- obiecte în care sunt convertite intrările. Fiecare job trebuie să aibă cel puțin o săgeată de ieșire, care este desenată ca emanând din marginea dreaptă a jobului.

Mecanism- resursele care execută munca. Săgeata mecanismului este desenată ca intrând în marginea inferioară a lucrării. La discreția analistului, săgețile mecanismului pot să nu fie reprezentate pe model.

Apel- o săgeată specială care indică un alt model de operare. Săgeata de apel este desenată ca venind din partea de jos a lucrării și este folosită pentru a indica faptul că unele lucrări sunt efectuate în afara sistemului care este modelat.

Orez. 2.1 Tipuri de săgeți

Metodologia IDEF0 necesită doar cinci tipuri de interacțiuni între blocuri pentru a descrie relațiile lor: control, intrare, feedback de control, feedback de intrare, mecanism de ieșire. Conexiunile de control și intrare sunt cele mai simple, deoarece reflectă influențe directe intuitive și foarte simple.

Orez. 2.2. Comunicare de ieșire

Orez. 2.3. Comunicarea managementului

O relație de control apare atunci când ieșirea unui bloc afectează direct blocul mai puțin dominant.

Feedback-ul de control și feedback-ul de intrare sunt mai complexe deoarece implică iterație sau recursivitate. Și anume, rezultatele unui job influențează execuția viitoare a altor joburi, care ulterior afectează jobul inițial.

Feedback-ul de control are loc atunci; când ieșirea unui bloc afectează un bloc cu dominanță mai mare.

Relațiile de ieșire-mecanism sunt rare. Ele reflectă o situație în care rezultatul unei funcții devine un mijloc pentru un scop pentru alta.

Orez. 2.4. Feedback de conectare

Orez. 2.5. Feedback de management

Relațiile producție-mecanism sunt caracteristice alocării surselor de resurse (de exemplu, instrumente necesare, personal instruit, spațiu fizic, echipamente, finanțare, materiale).

În IDEF0, un arc rareori reprezintă un singur obiect. De obicei simbolizează un set de obiecte. Deoarece arcurile reprezintă colecții de obiecte, ele pot avea mai multe puncte de plecare (surse) și puncte de sfârșit (destinații). Prin urmare, arcurile se pot ramifica și se pot conecta în diferite moduri. Întregul arc sau o parte a acestuia se poate extinde de la unul sau mai multe blocuri și se poate termina în unul sau mai multe blocuri.

Arcurile de ramificare, reprezentate ca linii radiante, înseamnă că tot sau o parte din conținutul arcelor poate apărea în fiecare ramură. Un arc este întotdeauna etichetat înaintea unei ramuri pentru a da un nume întregului set. În plus, fiecare ramură a unui arc poate fi sau nu etichetată conform următoarelor reguli:

ramurile neetichetate conțin greutatea obiectelor specificate în eticheta arcului înainte de ramură;

ramurile etichetate după punctul de ramificare conțin toate sau o parte din obiectele specificate în eticheta arcului înainte de ramificare.

Îmbinările arcului în IDEFO, reprezentate ca linii care converg împreună, indică faptul că conținutul fiecărei ramuri formează o etichetă pentru arcul care rezultă din îmbinarea arcurilor originale. După o îmbinare, arcul rezultat este întotdeauna marcat pentru a indica noul set de obiecte rezultat în urma îmbinării. În plus, fiecare ramură poate fi sau nu marcată înainte de fuzionare, conform următoarelor reguli:

Orez. 2.6. Conexiune ieșire-mecanism

ramurile neetichetate conțin greutatea obiectelor specificate în eticheta comună a arcului după îmbinare;

ramurile marcate înainte de îmbinare conțin toate sau unele dintre obiectele enumerate în eticheta comună după îmbinare,

numărul de blocuri pe diagramă - N;

nivel de descompunere a diagramei - L;

echilibrul diagramei - ÎN;

numărul de săgeți care se conectează la bloc - A

Acest set de factori se aplică fiecărei diagrame model. Următoarele vor enumera recomandări cu privire la valorile dorite ale factorilor din diagramă.

Este necesar să ne străduim să ne asigurăm că numărul de blocuri de pe diagramele nivelurilor inferioare este mai mic decât numărul de blocuri de pe diagramele părinte, adică, pe măsură ce nivelul de descompunere crește, coeficientul scade. Astfel, scăderea acestui coeficient indică faptul că. că pe măsură ce modelul este descompus, funcțiile ar trebui simplificate, prin urmare, numărul de blocuri ar trebui să scadă.

Diagramele trebuie să fie echilibrate. Aceasta înseamnă că într-o diagramă nu ar trebui să apară situația prezentată în Fig. 2.7: lucrarea 1 are mult mai multe săgeți de intrare și săgeți de control decât cele care ies. Trebuie remarcat faptul că această recomandare poate să nu fie urmată în modelele care descriu procesele de producție. De exemplu, atunci când descrieți o procedură de asamblare, un bloc poate include multe săgeți care descriu componentele unui produs și o săgeată care iese - produsul finit.

Orez. 2.7. Exemplu de grafic dezechilibrat

Să introducem coeficientul de echilibru al diagramei

Este necesar să ne străduim să Q a fost minim pentru diagramă.

Pe lângă analiza elementelor grafice ale diagramei, este necesar să se ia în considerare denumirile blocurilor. Pentru a evalua numele, este compilat un dicționar de funcții elementare (triviale) ale sistemului modelat. De fapt, acest dicționar ar trebui să includă funcțiile nivelului inferior de descompunere a diagramei. De exemplu, pentru un model de bază de date, funcțiile „găsiți o înregistrare” și „adăugați o înregistrare în baza de date” pot fi elementare, în timp ce funcția „înregistrare utilizator” necesită o descriere suplimentară.

După formarea unui dicționar și compilarea unui pachet de diagrame de sistem, este necesar să se ia în considerare nivelul inferior al modelului. Dacă există potriviri între numele blocurilor de diagramă și cuvintele din dicționar, aceasta înseamnă că a fost atins un nivel suficient de descompunere. Coeficientul care reflectă cantitativ acest criteriu poate fi scris ca L*C- produsul nivelului de model și numărul de potriviri ale numelor de bloc cu cuvintele din dicționar. Cu cât nivelul modelului este mai scăzut (L mai mare), cu atât potrivirile sunt mai valoroase.

Când porniți BPWin, bara de instrumente principală, paleta de instrumente și Model Explorer apar în mod implicit.

La crearea unui model nou, apare un dialog în care trebuie să indicați dacă modelul va fi creat din nou sau va fi deschis din depozitul ModelMart, introduceți numele modelului și selectați metodologia în care va fi construit modelul ( Fig. 2.8).

Fig.2.8 Dialog de creare a modelului

BPWin acceptă trei metodologii - IDEF0, IDEF3 și DFD. În BPWin este posibil să se construiască modele mixte, adică modelul poate conține simultan atât diagrame IDEF0, cât și IDEF3 și DFD. Compoziția paletei de instrumente se schimbă automat când treceți de la o notație la alta.

Un model în BPWin este considerat un set de lucrări, fiecare dintre ele funcționând cu un anumit set de date. Dacă faceți clic pe orice obiect model cu butonul stâng al mouse-ului, apare un meniu contextual pop-up, fiecare articol corespunzător editorului unei proprietăți a obiectului.

Construirea unui model de sistem ar trebui să înceapă cu studierea tuturor documentelor care descriu funcționalitatea acestuia. Unul dintre aceste documente este specificația tehnică, și anume secțiunile „Scopul dezvoltării”, „Scopul și obiectivele sistemului” și „Caracteristicile funcționale ale sistemului”.

După studierea documentelor sursă și intervievarea clienților și utilizatorilor sistemului, este necesar să se formuleze scopul modelării și să se determine punctul de vedere asupra modelului. Să luăm în considerare tehnologia construcției sale folosind exemplul sistemului „Serviciul universitar de ocupare a forței de muncă”, ale cărui capacități principale au fost descrise în munca de laborator nr. 1.

Să formulăm scopul modelării: să descriem funcționarea sistemului, care ar fi de înțeles utilizatorului său, fără a intra în detalii legate de implementare. Vom construi modelul din punctul de vedere al utilizatorilor (elev, profesor, administrator, decanat, companie).

Să începem prin a construi o diagramă de context IDEF0. Conform descrierii sistemului, funcția principală este de a-și servi clienții prin procesarea cererilor primite de la aceștia. Astfel, definim singura sarcină a diagramei de context ca „Servește clientul sistemului”. În continuare, definim datele de intrare și de ieșire, precum și mecanismele și controlul.

Pentru a deservi un client, este necesar să îl înregistrați în sistem, să deschideți accesul la baza de date și să procesați cererea acestuia. Datele de intrare vor fi „nume client”, „parolă client”, „bază de date sursă”, „cerere client”. Executarea unei cereri duce fie la primirea de informații din sistem, fie la modificarea conținutului bazei de date (de exemplu, la compilarea evaluărilor experților), astfel încât datele de ieșire vor fi „rapoarte” și „bază de date modificată”. Procesul de procesare a cererii va fi efectuat de monitorul sistemului sub controlul administratorului.

Astfel, definim diagrama de context a sistemului (Fig. 2.9).

Figura 2.9. Diagrama contextului sistemului

Să descompunăm diagrama de context, descriind secvența serviciului clienți:

Determinarea nivelului de acces la sistem.

Selectarea subsistemului.

Acces la subsistem.

Modificarea bazei de date (dacă este necesar).

Obținem diagrama prezentată în fig. 2.10.

După ce ați finalizat descompunerea diagramei de context, treceți la descompunerea diagramei de nivel următor. În mod obișnuit, atunci când se iau în considerare al treilea și cel mai jos nivel, modelele revin la diagramele părinte și le ajustează.

Orez. 2.10. Descompunerea lucrării „Serviciul, clientul de sistem”

Descompunem secvenţial toate blocurile diagramei rezultate. Primul pas în determinarea nivelului de acces la sistem este determinarea categoriei de utilizatori. Numele clientului este căutat în baza de date a utilizatorilor, determinându-se categoria acestuia. După o anumită categorie sunt determinate puterile acordate utilizatorului sistemului. În continuare, se efectuează procedura de accesare a sistemului, verificând numele și parola de acces. Prin combinarea informațiilor despre autorități și nivelul de acces la sistem, se formează un set de acțiuni permise pentru utilizator. Astfel, determinarea nivelului de acces la sistem va arăta ca în fig. 2.11.

Orez. 2.11. Descompunerea lucrării „Determinarea nivelului de acces la sistem”

După finalizarea procedurii de acces la sistem, monitorul analizează cererea clientului, selectând subsistemul care va procesa cererea. Descompunerea lucrării „Apel la un subsistem” nu corespunde scopului și punctului de vedere al modelului. Utilizatorul sistemului nu este interesat de algoritmii interni ai funcționării acestuia. În acest caz, este important pentru el ca alegerea subsistemului să se facă automat, fără intervenția lui, așa că descompunerea accesului la subsistem nu va face decât să complice modelul.

Descompunem lucrarea „Procesarea unei cereri client”, realizată de subsistemul de procesare a cererilor, determinând categoriile și puterile utilizatorilor. Înainte de a căuta un răspuns la o interogare, trebuie să deschideți baza de date (conectați-vă la ea). În general, baza de date poate fi localizată pe un server la distanță, așa că poate fi necesară stabilirea unei conexiuni la acesta. Să determinăm succesiunea lucrărilor:

Deschiderea bazei de date.

Executarea cererii.

Generarea de rapoarte.

După deschiderea bazei de date, trebuie să informați sistemul că a fost stabilită o conexiune la baza de date, apoi să executați cererea și să generați rapoarte pentru utilizator (Fig. 2.12).

Trebuie remarcat faptul că „Execuția interogărilor” include munca diferitelor subsisteme. De exemplu, dacă cererea include testarea, atunci aceasta va fi executată de subsistemul de teste profesionale și psihologice. În etapa de execuție a interogării, poate fi necesară modificarea conținutului bazei de date, de exemplu, la compilarea evaluărilor experților. Prin urmare, este necesar să se prevadă această posibilitate în diagramă.

Orez. 2.12.

Când se analizează diagrama rezultată, se pune întrebarea: ce reguli sunt folosite pentru a genera rapoarte? Este necesar să existe șabloane pregenerate care vor fi folosite pentru a selecta din baza de date, iar aceste șabloane trebuie să corespundă interogărilor și să fie predefinite. În plus, clientului ar trebui să i se ofere posibilitatea de a alege forma raportului.

Să ajustăm diagrama adăugând săgețile „Șabloane de raport” și „Solicitări de modificare a bazei de date” și săgeata tunel „Client de sistem”. Tunnelarea „Clientului de sistem” este utilizată pentru a nu plasa săgeata pe diagrama de sus, deoarece funcția de selectare a formularului de raport nu este suficient de importantă pentru a fi afișată pe diagrama părinte.

Schimbarea diagramei va avea ca rezultat ajustări la toate diagramele părinte (Fig. 2.13 - 2.15).

Este recomandabil să descompuneți lucrarea „Execuție interogări” folosind o diagramă DFD (lucrare de laborator nr. 3), deoarece metodologia IDEF0 consideră sistemul ca un set de lucrări interconectate, care nu reflectă bine procesele de prelucrare a informațiilor.

Orez. 2.13. Descompunerea lucrării „Prelucrarea cererii unui client”

Orez. 2.14. Descompunerea lucrării „Serviciul pentru clienți de sistem” (opțiunea 2)

Orez. 2.15. Diagrama contextului sistemului (opțiunea 2)

Să trecem la descompunerea ultimului bloc „Schimbarea bazei de date”. Din punctul de vedere al clientului, datele sistemului se află într-o singură bază de date. În realitate, există șase baze de date în sistem:

baza de date a utilizatorilor,

baza de date a studentilor, (opțiunea 2)

baza de date a posturilor vacante,

baza de date a performantelor academice,

baza de date de testare,

DB de evaluări de experți,

CV DB.

Conform scopului modelării, este important ca clientul să înțeleagă că datele primite nu sunt actualizate imediat în sistem, ci trec printr-o etapă suplimentară de prelucrare și control. Algoritmul de schimbare poate fi formulat după cum urmează:

Este determinată baza de date în care vor fi modificate informațiile.

Operatorul generează un set de date temporar și îl furnizează administratorului.

Administratorul controlează datele și le introduce în baza de date.

Acest model poate fi implementat într-un alt mod, oferind posibilitatea de a actualiza baza de date direct la solicitări, ocolind procesul de control al datelor. În acest caz, este necesar să se asigure controlul integrității bazei de date pentru a evita deteriorarea acesteia. În acest caz, diagrama va arăta astfel (Fig. 2.17).

Orez. 2.16. Descompunerea lucrării „Schimbarea bazei de date”

Orez. 2.17. Descompunerea lucrării „Modificarea bazei de date” (opțiunea 2) Pentru prima opțiune, prezentată în Fig. 2.12

Descompunerea ulterioară a „Modificărilor bazei de date” va complica modelul, explicând modul în care se realizează modificarea fizică a bazei de date în sistem. În acest caz, utilizatorul nu va primi informații suplimentare despre funcționarea sistemului de servicii de ocupare a forței de muncă. Este recomandabil să descompuneți această lucrare în timpul procesului de proiectare a unui sistem de baze de date în etapa creării unui model logic al bazei de date.

O descompunere a lucrării de execuție a interogărilor va fi efectuată în laboratorul următor, ilustrând utilizarea diagramelor DFD pentru a descrie procesele de procesare a informațiilor.

Să efectuăm o analiză cantitativă a modelelor prezentate în Fig. 2.12 și 2.13, conform metodei descrise mai sus. Să luăm în considerare comportamentul coeficientului ^ pentru aceste modele. Diagrama părinte „Procesarea unei cereri client” are un coeficient de 4/2 = 2, iar diagrama de descompunere are 3/3 = 1. Valoarea coeficientului scade, ceea ce indică o simplificare a descrierii funcțiilor ca nivelul de modelul scade.

Să luăm în considerare modificarea coeficientului LA b au două opțiuni de model.

pentru a doua varianta

Coeficient LA b nu își modifică valoarea, prin urmare, echilibrul diagramei nu se modifică.

Vom presupune că nivelul de descompunere a diagramelor luate în considerare este suficient pentru a reflecta scopul modelării, iar în diagramele de nivel inferior, funcțiile elementare sunt folosite ca nume de lucrări (din punctul de vedere al utilizatorului de sistem) .

Rezumând exemplul luat în considerare, este necesar să remarcăm importanța luării în considerare a mai multor opțiuni de diagramă la modelarea unui sistem. Asemenea opțiuni pot apărea la ajustarea diagramelor, așa cum sa făcut cu „Procesarea unei cereri de client” sau la crearea unor implementări alternative ale funcțiilor sistemului (descompunerea lucrării „Modificarea bazei de date”). Revizuirea opțiunilor vă permite să o selectați pe cea mai bună și să o includeți într-un pachet de diagrame pentru o analiză suplimentară.

Postat pe http://www.allbest.ru/

Relevanța sarcinii de automatizare a contabilității computerelor și a altor echipamente la o întreprindere crește odată cu prezența unei flote mari de computere, echipamente de birou, echipamente comerciale și alte echipamente. Cea mai mare nevoie de a ști unde și ce unitate este amplasată, de a urmări prompt schimbările legate de echipamente, apare din departamentele IT. 2

Sarcina de automatizare a contabilității echipamentelor este de o importanță deosebită la întreprinderile mari. Prelucrarea unor cantități tot mai mari de informații a devenit posibilă numai prin utilizarea tehnologiilor informatice moderne. 2

Acum este imposibil să organizezi un sistem de înregistrare a echipamentelor la o întreprindere, ținând evidența calculatoarelor și componentelor, fără software suplimentar instalat pe computer. 2

Scopul principal munca de curs este dezvoltarea Sistem informatic pentru contabilitate echipamente informaticeîntreprinderilor, folosind metodologia de modelare funcțională și notația grafică IDEF0, diagramele fluxului de date DFD și standardul de documentare a procesului IDEF3, folosind produsul software Computer Associates AllFusion Process Modeler r7.3. 2

2.1 Analiză produse software 8

INTRODUCERE

Relevanța sarcinii de automatizare a contabilității computerelor și a altor echipamente la o întreprindere crește odată cu prezența unei flote mari de computere, echipamente de birou, echipamente comerciale și alte echipamente. Cea mai mare nevoie de a ști unde și ce unitate este amplasată, de a urmări prompt schimbările legate de echipamente, apare din departamentele IT.

Sarcina de automatizare a contabilității echipamentelor este de o importanță deosebită la întreprinderile mari. Prelucrarea unor cantități tot mai mari de informații a devenit posibilă numai prin utilizarea tehnologiilor informatice moderne.

Acum este imposibil să organizezi un sistem de înregistrare a echipamentelor la o întreprindere, ținând evidența calculatoarelor și componentelor, fără software suplimentar instalat pe computer.

Scopul principal al cursului este dezvoltarea unui sistem informatic pentru contabilitatea echipamentelor informatice ale întreprinderii, folosind metodologia de modelare funcțională și notația grafică IDEF0, diagramele fluxului de date DFD și standardul de documentare a proceselor IDEF3, folosind Computer Associates AllFusion Process Modeler r7. 3 produs software.

Pentru a atinge acest obiectiv, este necesar să rezolvați următoarele sarcini:

Analiza produselor software;

Studiul metodelor de proiectare a sistemelor informatice;

Modelarea funcțională a diagramei de context și a diagramelor de descompunere a proceselor de afaceri (IDEF0) „Contabilitatea echipamentelor informatice ale întreprinderii”;

Proiectarea sistemului informatic folosind diagrame de flux de date (DFD);

Folosind metodologia de modelare și standardul de documentare a proceselor IDEF3.

software de documentare a clinicii de informare

1. METODE DE PROIECTARE A SISTEMELOR INFORMATIALE

În practica modernă de management al modelării și activităților de producție, se obișnuiește să se folosească termenul „proces de afaceri” pentru a desemna obiectele de modelare. Atunci când modelați procesele de afaceri, trebuie acordată atenție mai multor factori:

Stabilirea corectă a obiectivelor;

Conștientizarea adecvată a personalului organizației cu privire la obiectivele și rezultatele proiectului;

Utilizarea eficientă a instrumentelor de modelare;

Disponibilitatea standardelor corporative pentru descrierea și reglementarea proceselor de afaceri.

Mai multe metode diferite sunt utilizate pentru a modela procesele de afaceri. Ele se bazează pe abordări ale modelării atât structurale, cât și orientate pe obiect. Cele mai dezvoltate metode folosesc elemente ale ambelor abordări. Cele mai comune metode includ:

metoda de modelare funcțională SADT (IDEF0);

metoda de modelare a proceselor IDEF3;

Modelarea fluxului de date DFD;

Din punct de vedere al modelării de afaceri, fiecare dintre abordările prezentate are propriile sale avantaje. Abordarea obiect vă permite să construiți un sistem care este mai rezistent la schimbări și potrivește mai bune

structurile existente ale organizaţiei. Modelarea funcțională funcționează bine în cazurile în care structura organizațională este în proces de schimbare sau este în general slab formată. Abordarea funcțiilor îndeplinite este intuitiv mai bine înțeleasă de interpreți atunci când primesc informații de la aceștia despre activitatea lor curentă.

Metoda de modelare funcțională IDEF0 (Function Modeling) – un set de reguli și proceduri concepute pentru a construi model functional obiect al oricărei discipline. Modelul funcțional al unui obiect afișează acțiunile pe care le efectuează și conexiunile dintre ele.

În conformitate cu această metodă, modelul de afaceri ar trebui să arate astfel:

Nivelul superior al modelului ar trebui să reflecte doar contextul sistemului, adică interacțiunea acestuia cu lumea exterioară.

Al doilea nivel al modelului ar trebui să conțină toate activitățile principale ale întreprinderii, cu alte cuvinte, procesele de afaceri grupate tematic ale întreprinderii și interrelațiile dintre acestea.

Detalierea ulterioară a proceselor de afaceri se realizează prin intermediul funcțiilor de afaceri, adică seturi de operațiuni grupate în funcție de anumite caracteristici.

Descrierea operațiunilor elementare de afaceri se realizează prin specificarea unui algoritm pentru executarea acestuia.

Metoda de modelare a fluxului de date DFD (Data Flow Diagrams) - diagrame de flux de date. Instrumentul principal pentru modelarea cerințelor funcționale pentru sistemul proiectat.

Componentele modelului: diagrame; Dicționar de date; specificatiile procesului.

Elementele diagramei: fluxul de date; depozitare; entitate externă.

Fluxul de date este un mecanism folosit pentru a modela și transfera informații de la o parte a unui sistem la alta.

O entitate externă este un obiect/subiect în afara contextului sistemului, adică.

Stocarea este o porțiune de fluxuri de date în timp care conține date care trebuie stocate între procese.

Principalele avantaje:

capacitatea de a identifica în mod unic entitățile externe prin analizarea fluxurilor de informații din interiorul și din exteriorul sistemului;

capacitatea de a proiecta de sus în jos, ceea ce facilitează construirea unui model „cum ar trebui să fie”;

prezența specificațiilor proceselor de nivel inferior, care vă permite să depășiți incompletitudinea logică a modelului funcțional și să construiți o specificație funcțională completă a sistemului în curs de dezvoltare;

modelele au un set foarte bogat de elemente care reflectă în mod adecvat specificul lor;

Există algoritmi pentru conversia automată a ierarhiei DFD în hărți structurale și sunt susținuți de o serie de instrumente CASE, care demonstrează conexiunile inter-sistem, intra-sistem și ierarhia sistemului.

Defecte:

necesitatea introducerii artificiale a proceselor de control, deoarece acțiunile (fluxurile) de control și procesele de control din punctul de vedere al DFD nu sunt diferite de cele obișnuite;

lipsa conceptului de timp, de ex. lipsa analizei intervalelor de timp la conversia datelor (toate restricțiile de timp trebuie introduse în specificațiile procesului).

Metoda de modelare a proceselor IDEF3 (DEFinition Integrated for Process Description Capture Method) este o metodologie de modelare și un standard pentru documentarea proceselor care au loc în sistem. Metoda de documentare a proceselor oferă un mecanism pentru documentarea și colectarea informațiilor despre procese. IDEF3 arată relațiile cauză-efect dintre situații și evenimente într-o formă care poate fi citită de experți, folosind o metodă structurată de exprimare a cunoștințelor despre modul în care funcționează un sistem, un proces sau o întreprindere.

Tehnica de descriere a setului de date IDEF3 face parte din analiză structurală. Spre deosebire de unele metodologii de descriere a proceselor, IDEF3 nu limitează analistul la o sintaxă prea rigidă, ceea ce poate duce la modele incomplete sau inconsistente.

IDEF3 poate fi folosit și ca metodă de creare a procesului. IDEF3 completează IDEFO și conține tot ceea ce este necesar pentru construirea de modele care pot fi utilizate ulterior pentru analiza de simulare.

2. Proiectarea unui sistem informatic „contabilitatea echipamentelor informatice ale întreprinderii”

2.1 Analiza produselor software

Se efectuează o analiză a unor astfel de sisteme informatice pentru a identifica avantajele și dezavantajele sistemelor, precum și pentru a compara funcționalitatea, interfața, designul și ușurința în utilizare. Următoarele sisteme informatice existente au fost găsite ca:

Software IT Invent (it-invent.ru)

Software Inspector hardware (hwinspector.com)

Configurația 1C: Contabilitatea calculatoarelor și echipamentelor 8.1 (odineskin.ru)

Primul IS, IT Invent, nu este doar o contabilitate a calculatoarelor, imprimantelor, programelor și componentelor. Aceasta include, de asemenea, contabilitatea pentru reparații și întreținere, lucrările de asistență pentru echipamente, comenzile către furnizori, chitanțele și mișcările de echipamente, contabilitatea antreprenorilor, angajaților și multe altele. Forma de bază a programului IT Invent este prezentată în Figura 1.

Figura 1 „IT Invent”

IT Invent este un sistem flexibil și personalizabil care are o interfață intuitivă, care este bine percepută de utilizator în ceea ce privește designul. Programul este destul de multifuncțional. Aș dori să notez următoarele caracteristici cheie ale programului:

Suport pentru baze de date MS Access și MS SQL Server.

Mod de operare cu mai mulți utilizatori - toate ramurile funcționează cu o singură bază de date.

Abilitatea de a crea și configura propriile proprietăți suplimentare de diferite tipuri.

Contabilitatea efectuării muncii de orice fel în cadrul organizației.

Un sistem unic pentru crearea și imprimarea etichetelor de inventar. Suport pentru imprimante de coduri de bare.

Suport pentru lucrul cu un scaner de coduri de bare. Căutați înregistrări în baza de date prin cod de bare.

Menținerea unui istoric al modificărilor aduse echipamentelor.

Contabilitate reparatii si intretinere preventiva a echipamentelor si calculatoarelor.

Conectarea logică a programelor și componentelor cu echipamentele.

Contabilitate pentru consumabile, piese de schimb si rechizite de birou.

Atribuirea unităților de contabilitate angajaților organizației. Acte de acceptare și transfer.

Menținerea unei baze de date cu furnizori, organizații de servicii și alți contractori.

Diferențierea flexibilă a drepturilor de acces pentru utilizatorii sistemului.

Configurarea alertelor prin e-mail pentru evenimentele din program.

Un număr mare de formulare și rapoarte tipărite încorporate cu posibilitatea de a le edita.

Importați și vizualizați datele direct din Active Directory.

Programul IT Invent este bazat pe rețea. Pentru a lucra în rețea cu o singură bază de date, este necesar ca fiecare utilizator al programului să scrie în fișierul „DBPath.ini” calea de conectare la fișierul bazei de date sau să specifice această cale selectând elementul de meniu „Fișier” - > „Selectați baza de date”. În același timp, trebuie să vă amintiți să setați drepturi de citire și scriere în directorul cu baza de date pentru toți utilizatorii programului.

Al doilea IS este programul Hardware Inspector. Programul este conceput pentru contabilitatea automată și inventarierea echipamentelor informatice și a altor echipamente din organizații. Unicitatea programului Hardware Inspector constă în capacitatea de a urmări nu doar starea curentă a parametrilor computerului, ci și întreaga istorie de viață a componentelor individuale. Figura 2 prezintă o reprezentare vizuală a dispozitivelor în arborele spațiului de lucru.

Figura 2 „Inspector hardware”

Interfața este simplă și intuitivă. În ceea ce privește designul, este acceptabil. Programul este multifuncțional. Aș dori să subliniez următoarele caracteristici cheie:

Contabilitatea detaliată a calculatoarelor și software-ului;

Ciclul de viață al obiectelor contabile;

Import de dispozitive, software, stații de lucru și setări de rețea;

Audit automat al locurilor de muncă;

Crossover de rețea;

Contabilitatea si planificarea consumabilelor;

Contabilizarea cererilor de la utilizatori;

Inventarierea obiectelor contabile;

Control de acces flexibil;

Căutați informații;

Peste 30 de rapoarte personalizate încorporate;

Cărți de referință detaliate despre toate aspectele contabilității;

Programul Hardware Inspector, plătit. O licență oferă dreptul de a instala programul pe orice număr de computere, într-o rețea locală, o organizație.

Al treilea IS este configurația 1C: Contabilitatea calculatoarelor și echipamentelor 8.1. Inventarul de echipamente se bazează în primul rând pe coduri de bare, făcând astfel mult mai ușoară orice căutare, selecție sau operare a echipamentelor. Folosind această configurație, este convenabil să se țină cont și să se efectueze inventarierea calculatoarelor, echipamentelor de birou și a oricăror alte bunuri materiale (echipamente, telefoane, mobilier), precum și automatizarea altor domenii de activitate.

Figura 3 prezintă forma de bază a configurației 1C.

Figura 3 „1C: Contabilitatea calculatoarelor și echipamentelor 8.1”

Caracteristici principale ale produsului:

Contabilitatea oricărui echipament, mobilier, software,

Contabilitatea numerelor de serie și de inventar ale echipamentelor,

Import din sistemul de audit hardware Everest (colectare automată a datelor)

Cea mai convenabilă interfață de utilizator

Contabilitatea aplicatiilor catre furnizori

Criteriu		"Inspector hardware"	Configurația 1C
Funcționalitate	Multifuncțional	Multifuncțional	Multifuncțional
Interfață	Intuitiv	Simplu - intuitiv	Maxim convenabil
		Acceptabil	Standard
Ușurința în utilizare		Ușor de folosit	Presetari individuale
Avantaje	Funcționează prin rețea	Funcționează prin rețea locală Actualizat de 2 ori pe lună O licență poate fi instalată pe orice număr de computere, într-o rețea locală, o organizație	Valabil linie gratuită consultări asupra e-mailși ICQ și, dacă este necesar, consultație telefonică.
Defecte	Program plătit	Program plătit	Program plătit

Contabilizarea cererilor utilizatorilor și lucrul cu acestea

Contabilitatea consumabilelor

Căutare automată la scanare

Seturi individuale de setări etc.

Să comparăm sistemele informaționale selectate în Tabelul 1 după următoarele criterii: Funcționalitate, Interfață, Design, Ușurință în utilizare, Avantaje și dezavantaje;

Tabelul 1 - Comparația sistemelor informaționale

Concluzie: Toate sistemele informatice luate în considerare conțin toate funcțiile necesare contabilizării echipamentelor informatice ale unei întreprinderi. Toate sunt multifuncționale, convenabile și ușor de utilizat, cu o interfață intuitivă. Singurul dezavantaj comun al tuturor programelor este că toate sunt plătite.

2.2 Descrierea diagramelor proceselor de afaceri „Contabilitatea echipamentelor informatice ale întreprinderii”

2.2.1 Descrierea diagramei IDEF0

O diagramă IDEF0 a fost folosită pentru a construi un proces de afaceri. Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor sistemului. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii acestuia cu lumea exterioară (diagrama contextului). Au fost construite trei niveluri ale diagramei:

Contextual

Descompunerea functionala

Descompunerea fiecărei lucrări

Figura 1 - Diagrama de context „Contabilitatea echipamentelor informatice ale întreprinderii”

Figura 1 prezintă o diagramă de context a procesului de afaceri „Contabilitatea echipamentelor informatice ale întreprinderii”. Ea reflectă sistemul în ansamblu și interacțiunea acestuia cu principalele fluxuri de informații externe.

Diagrama de context este indicată prin săgeți.

Tipuri de săgeți:

Informații de intrare pentru procesare:

Calculatoare – PC-uri (calculatoare personale) situate în întreprindere

Componente – materiale necesare pentru modernizarea computerelor (plăci video, plăci de bază, procesoare, carcase, surse de alimentare, module de memorie)

Fluxuri de ieșire:

Raport – un raport gata făcut privind contabilitatea echipamentelor informatice ale unei întreprinderi

Comenzi de intrare:

Regulile sunt condiții care trebuie îndeplinite pentru a atinge scopul.

Comenzi - sarcina atribuită întreprinderii (să efectueze contabilitatea echipamentelor informatice la întreprindere folosind anumite sisteme informatice)

Managerii sunt directori și directori șefi ai întreprinderii.

Resurse de intrare:

PC-urile sunt calculatoare folosite pentru a ține înregistrări.

Angajații sunt specialiști care execută instrucțiunile atribuite de conducere. După construirea modelului conceptual, a fost efectuată o descompunere funcțională - sistemul a fost împărțit în subsisteme și fiecare subsistem a fost descris separat (diagrame de descompunere).

Figura 2 prezintă o descompunere funcțională constând din patru locuri de muncă.

Figura 2 - Descompunerea funcțională „Contabilitatea echipamentelor informatice ale unei întreprinderi”

Au fost identificate următoarele tipuri de lucrări:

Înregistrarea livrărilor este un proces în care un id este atribuit unui produs, trimis pentru depozitare, către un depozit, iar informațiile despre produs sunt introduse în program.

Lucrarea de Înregistrare a livrărilor include șapte săgeți de delimitare (intrare, control, mecanism) și o săgeată interioară (conexiune de intrare) ieșiri.

Conexiune sageata la intrarea intre lucrari Inregistrarea livrarilor si intretinerea calculatoarelor (calculator);

Săgețile de intrare, ieșire, control sunt repetate în lucrările ulterioare.

Întreținerea computerelor este procesul de asamblare, reparare și modernizare a computerelor.

Lucrarea de întreținere a computerului include patru săgeți de delimitare (intrare, control, mecanism, ieșire) și mai multe săgeți interne (comunicare de intrare, feedback de intrare).

Arrow management - reguli, ordine, lider;

Conectare săgeată prin introducere între lucrările Întreținere și Amenajare Calculatoare (introducerea datelor în baza de date), între lucrările Întreținere Calculatoare și Creare Raport (introducerea datelor în baza de date);

Aranjarea este un proces în care calculatoarele sunt aranjate în birouri (birouri).

Managementul săgeților - reguli, ordine, lider;

Săgeată mecanism – angajați;

Conexiune săgeată la intrarea dintre Aranjament și Raportare (atribuire id);

Întocmirea raportului este etapa finală a procesului contabil, care constă în rezumarea indicatorilor finali obținuți prin efectuarea datelor contabile curente anterioare.

Fiecare subsistem este apoi defalcat în descompoziții mai mici și așa mai departe, până când este atins nivelul dorit de detaliu.

Figura 3 prezintă o diagramă care arată mai detaliat funcționarea Livrării Livrării.

Ca urmare a detalierii, au fost identificate principalele funcții. Secțiunea „Înregistrarea livrării” include șapte săgeți principale (intrare, ieșire, control, mecanism).

Săgeată de intrare – calculatoare și componente;

Săgețile de control sunt regulile, ordinele și liderul. Săgeți de ramificare;

Săgeți mecanism, ramificare – PC, angajați;

Săgețile de intrare, comenzile, mecanismele sunt repetate în toate lucrările.

Atribuirea unui număr – atribuirea unui număr individual computerelor și componentelor.

Săgeți de intrare – computere și componente. Săgeata computerului se repetă în lucrările ulterioare, cu excepția întocmirii raportului;

Săgeți de control – reguli, ordine și lider;

Săgeți mecanism – PC și angajați;

Conectare săgeată prin introducere între lucrări Atribuire număr și Trimitere mărfuri la depozit (deplasare), între „Atribuire număr” și „Punere la echilibru” (intrare în baza de date);

Trimiterea mărfurilor la depozit – trimiterea mărfurilor cu un număr atribuit către depozit.

Săgeată de ieșire – computer;

Săgețile de control - reguli, ordine și lider.

Conexiune săgeată la intrare între locurile de muncă „Expedierea mărfurilor la depozit” și „Punerea în echilibru” (cantitate);

Echilibrare – introducerea de informații într-un computer.

Săgeți de control – reguli, ordine și lider;

Săgeți mecanism – PC și angajați;

Figura 4 este o diagramă care detaliază întreținerea computerului mai detaliat.

În urma detalierii, au fost identificate principalele funcții îndeplinite în timpul procesului de întreținere a calculatorului.

Lucrarea de întreținere a computerului include 4 săgeți de delimitare (intrare, ieșire, control, mecanism). Săgeți interne (feedback de intrare, comunicare de intrare).

Asamblare calculatoare – configurarea calculatoarelor conform comenzilor individuale ale managerilor.

Săgeată de intrare – calculatoare;

Săgeți de control – reguli, ordine și lider;

Săgețile mecanismului – Angajații;

Conexiune săgeată la intrarea dintre lucrări: „Asamblare calculatoare” și „Reparare computere” (calculator);

Reparație calculatoare – montaj de calculatoare aprobat pentru îmbunătățire.

Săgeată de intrare – calculatoare;

Săgeată de ieșire – intrarea în baza de date;

Săgeți de control – reguli, ordine și lider;

Săgețile mecanismului – Angajații;

Săgețile pentru intrare, ieșire, control și mecanism se ramifică;

Conexiune săgeată la intrarea dintre lucrări: „Reparație computer” și „Upgrade” (componente);

Upgrade - îmbunătățirea, îmbunătățirea, actualizarea unui computer.

Săgeată de ieșire – intrarea în baza de date;

Săgeți de control – reguli, ordine și lider;

Săgețile mecanismului – Angajații;

Săgețile de control și mecanismul sunt ramificate;

Figura 5 prezintă diagrama „Scrierea raportului” mai detaliat. Descompunerea lucrării Întocmirea raportului include 4 săgeți de delimitare (intrare, ieșire, control, mecanisme). Săgeți interne (feedback de intrare, comunicare de intrare).

În urma lucrărilor, au fost derivate următoarele funcții:

Colectarea datelor – colectarea de informații pentru analiză și luare a deciziilor.

Săgeată de intrare – atribuire id;

Săgeți de control – reguli, ordine și lider;

Săgețile pentru intrare, control și mecanism sunt ramificate;

Conexiune săgeată prin intrare între lucrări: Colectarea datelor și verificarea datelor (înregistrări);

Verificarea datelor – verificarea informațiilor și trimiterea acestora spre raportare.

Săgeată de autentificare – atribuirea unui id, introducerea datelor în baza de date;

Săgeată de ieșire – Raport;

Săgeți de control – reguli, ordine și lider;

Săgeți mecanism – Angajați, PC;

Săgețile pentru intrare (atribuirea id-ului), control și mecanism sunt ramificate;

Săgeată de feedback pentru a introduce de la „Verificarea datelor” la „Colectarea datelor” (reverificarea).

Învață să vezi și să înțelegi structură funcțională treaba ta!

În prezent, în Rusia sa înregistrat o creștere accentuată a interesului pentru standardele de management general acceptate în Occident, însă, în practică reală management există un moment foarte important. Mulți manageri pot fi încă nedumeriți de o întrebare directă despre structura organizationala companie sau despre schema proceselor de afaceri existente. Cei mai avansați manageri care citesc periodic periodice economice, de regulă, încep să deseneze diagrame ierarhice pe care numai ei le pot înțelege, dar în acest proces ajung de obicei rapid într-o fundătură. Același lucru este valabil și pentru angajații și managerii diferitelor servicii și departamente funcționale. În cele mai multe cazuri, singurul set de reguli declarate în temeiul căruia o întreprindere trebuie să funcționeze este un set de reglementări individuale și descrierea postului. Cel mai adesea, aceste documente au fost întocmite cu mai bine de un an în urmă, sunt prost structurate și nu au legătură între ele și, ca urmare, pur și simplu adună praf pe rafturi. Deocamdată, o astfel de abordare a fost justificată, deoarece în timpul formării rusului economie de piata conceptul de concurență era practic absent și nu era nevoie în mod special de a calcula costurile - profiturile erau gigantice. Ca urmare a acestui fapt, în ultimii doi ani am văzut o imagine complet de înțeles: companii mari, care au crescut la începutul anilor '90, își pierd treptat pozițiile, până la părăsirea completă a pieței. Acest lucru se datorează parțial faptului că standardele de management nu au fost introduse în întreprindere; conceptul de model funcțional de activitate și misiune a fost complet absent. Prin modelarea diferitelor domenii de activitate, puteți analiza destul de eficient blocajele în management și puteți optimiza schema generală de afaceri. Dar, după cum știți, în orice întreprindere, numai acele proiecte care aduc profit direct au cea mai mare prioritate, așa că problema examinării activităților și reorganizării acestora vine de obicei doar în timpul unei crize semnificative în managementul companiei.

La sfârșitul anilor 1990, când piața a devenit mai competitivă și profitabilitatea întreprinderilor a început să scadă brusc, managerii au întâmpinat dificultăți enorme în încercarea de a optimiza costurile astfel încât produsele să rămână atât profitabile, cât și competitive. În acest moment a devenit absolut clară necesitatea de a avea în fața ochilor un model al activității întreprinderii care să reflecte toate mecanismele și principiile de interconectare a diferitelor subsisteme din cadrul unei singure afaceri.

Însuși conceptul de „modelare a proceselor de afaceri” a intrat în viața de zi cu zi a majorității analiștilor odată cu apariția pe piață a unor produse software complexe concepute pentru automatizarea complexă a managementului întreprinderii. Astfel de sisteme implică întotdeauna o examinare aprofundată înainte de proiect a activităților companiei. Rezultatul acestei examinări este o opinie de specialitate, în care punctele individuale fac recomandări pentru eliminarea „gâturilor de sticlă” în managementul activității. Pe baza acestei concluzii, imediat înaintea proiectului de implementare a unui sistem de automatizare, se realizează o așa-zisă reorganizare a proceselor de afaceri, uneori destul de gravă și dureroasă pentru companie. Acest lucru este firesc; este întotdeauna dificil să forțezi o echipă care s-a format de-a lungul anilor să „gândească într-un mod nou”. Astfel de anchete cuprinzătoare ale întreprinderilor sunt întotdeauna complexe și variază semnificativ de la caz la caz. Pentru a rezolva astfel de probleme de modelare a sistemelor complexe, există metodologii și standarde bine testate. Aceste standarde includ familia de metodologii IDEF. Cu ajutorul lor, puteți afișa și analiza în mod eficient modelele de activitate ale unei game largi de sisteme complexe în diverse contexte. În același timp, lărgimea și profunzimea examinării proceselor din sistem sunt determinate de către dezvoltator însuși, ceea ce face posibilă să nu supraîncărcați modelul creat cu date inutile. În prezent, familia IDEF include următoarele standarde:

IDEF0 - metodologia de modelare funcțională. Folosind limbajul grafic vizual IDEF0, sistemul studiat se prezintă dezvoltatorilor și analiștilor sub forma unui set de funcții interdependente (blocuri funcționale – în termeni IDEF0). De regulă, modelarea IDEF0 este primul pas în studierea oricărui sistem;

IDEF1 este o metodologie de modelare a fluxurilor de informații în cadrul unui sistem, permițându-vă să afișați și să analizați structura și relațiile acestora;

IDEF1X (IDEF1 Extended) – metodologie de construire a structurilor relaționale. IDEF1X aparține tipului de metodologie Entitate-Relație (ER) și este utilizat în mod obișnuit pentru modelarea bazelor de date relaționale relevante pentru sistemul în cauză;

IDEF2 este o metodologie pentru modelarea dinamică a dezvoltării sistemelor. Datorită dificultăţilor foarte grave de analiză sisteme dinamice acest standard a fost practic abandonat, iar dezvoltarea lui s-a oprit chiar de la început stadiul inițial. Cu toate acestea, în prezent există algoritmi și implementările lor pe computer care fac posibilă transformarea unui set de diagrame IDEF0 statice în modele dinamice construite pe baza „rețelelor Petri colorate” (CPN - Color Petri Nets);

IDEF3 este o metodologie de documentare a proceselor care au loc într-un sistem, care este utilizată, de exemplu, în studiul proceselor tehnologice din întreprinderi. IDEF3 descrie scenariul și secvența operațiunilor pentru fiecare proces. IDEF3 are o relație directă cu metodologia IDEF0 - fiecare funcție (bloc funcțional) poate fi reprezentată ca proces separat folosind IDEF3;

IDEF4 este o metodologie pentru construirea de sisteme orientate pe obiecte. Instrumentele IDEF4 vă permit să afișați vizual structura obiectelor și principiile de bază ale interacțiunii lor, permițându-vă astfel să analizați și să optimizați sisteme complexe orientate pe obiecte;

IDEF5 este o metodologie pentru cercetarea ontologică a sistemelor complexe. Folosind metodologia IDEF5, ontologia unui sistem poate fi descrisă folosind un dicționar specific de termeni și reguli, pe baza căruia se pot forma declarații de încredere despre starea sistemului luat în considerare la un moment dat. Pe baza acestor afirmații se trag concluzii despre dezvoltare ulterioară sistem și se realizează optimizarea acestuia.
În acest articol, ne vom uita la metodologia de modelare funcțională cea mai frecvent utilizată, IDEF0.

Istoricul standardului IDEF0

Metodologia IDEF0 poate fi considerată următoarea etapă în dezvoltarea cunoscutului limbaj grafic pentru descrierea sistemelor funcționale SADT (Structured Analysis and Design Teqnique). În urmă cu câțiva ani, o carte cu același nume a fost publicată în Rusia într-o ediție mică, dedicată descrierii principiilor de bază ale construirii diagramelor SADT. Din punct de vedere istoric, IDEF0 ca standard a fost dezvoltat în 1981 ca parte a unui program extins de automatizare întreprinderile industriale, care purta denumirea ICAM (Integrated Computer Aided Manufacturing) și a fost propus de departament Forțele Aeriene STATELE UNITE ALE AMERICII. De fapt, familia de standarde IDEF și-a moștenit denumirea de la numele acestui program (IDEF=ICAM DEFinition). În curs implementare practică, participanții la programul ICAM s-au confruntat cu nevoia de a dezvolta noi metode de analiză a proceselor de interacțiune în sistemele industriale. În plus, pe lângă un set îmbunătățit de funcții pentru descrierea proceselor de afaceri, una dintre cerințele noului standard a fost prezența unei metodologii eficiente de interacțiune în cadrul „analist-specialist”. Cu alte cuvinte, metoda noua ar fi trebuit să asigure lucrul de grup la crearea modelului, cu participarea directă a tuturor analiștilor și specialiștilor implicați în proiect.

Ca urmare a căutării soluțiilor adecvate, a luat naștere metodologia de modelare funcțională IDEF0. Din 1981, standardul IDEF0 a suferit mai multe modificări minore, majoritatea de natură restrictivă, iar cea mai recentă ediție a fost lansată în decembrie 1993 de Institutul Național de Standarde și Tehnologie din SUA (NIST).

Elemente de bază și concepte ale IDEF0

Limbajul grafic IDEF0 este surprinzător de simplu și armonios. Metodologia se bazează pe patru concepte principale.

Primul dintre acestea este conceptul de bloc funcțional (Activity Box). Un bloc funcțional este reprezentat grafic ca un dreptunghi (vezi Fig. 1) și reprezintă o funcție specifică în cadrul sistemului luat în considerare. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în mod verbal (de exemplu, „produce servicii”, nu „produce servicii”).

Fiecare dintre cele patru laturi ale blocului funcțional are propriul său sens specific (rol) și:

Partea de sus este setată la „Control”;

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

Partea dreaptă este setată la „Ieșire”;

Partea de jos are semnificația „Mecanism”.

Fiecare bloc funcțional dintr-un singur sistem luat în considerare trebuie să aibă propriul său număr de identificare unic.

Figura 1. Bloc funcţional.

Al doilea pilon al metodologiei IDEF0 este conceptul de arc de interfață (Arrow). Arcurile de interfață sunt adesea numite fluxuri sau săgeți. Un arc de interfață reprezintă un element de sistem care este procesat de un bloc funcțional sau afectează în alt mod funcția reprezentată de acel bloc funcțional.

Reprezentarea grafică a unui arc de interfață este o săgeată unidirecțională. Fiecare arc de interfață trebuie să aibă propriul nume unic (Arrow Label). După cum prevede standardul, numele trebuie să fie o formă a unui substantiv.

Cu ajutorul arcelor de interfață sunt afișate diverse obiecte care, într-o măsură sau alta, determină procesele care au loc în sistem. Astfel de obiecte pot fi elemente ale lumii reale (piese, mașini, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).

În funcție de ce parte se apropie acest arc de interfață, se numește „incoming”, „outgoing” sau „controlling”. În plus, „sursa” (începutul) și „chiuveta” (sfârșitul) fiecărui arc funcțional pot fi numai blocuri funcționale, în timp ce „sursa” poate fi doar partea de ieșire a blocului, iar „chiuveta” poate fi orice dintre cele trei rămase.

Trebuie remarcat faptul că orice bloc funcțional, conform cerințelor standardului, trebuie să aibă cel puțin un arc de interfață de control și unul de ieșire. Acest lucru este de înțeles - fiecare proces trebuie să aibă loc conform unor reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel luarea în considerare a acestuia nu are sens.

Când construiți diagrame IDEF0, este important să separați corect arcurile interfeței de intrare de arcele de control, ceea ce este adesea dificil. De exemplu, Figura 2 prezintă blocul funcțional „Procesează piesa de prelucrat”.

În procesul real, lucrătorului care efectuează prelucrarea i se oferă o piesă de prelucrat și instrucțiuni tehnologice pentru prelucrare (sau reguli de siguranță atunci când lucrează cu mașina). Poate părea în mod eronat că atât piesa de prelucrat, cât și documentul cu instrucțiuni tehnologice sunt obiecte primite, dar nu este cazul. De fapt, în acest proces, piesa de prelucrat este prelucrată conform regulilor reflectate în instrucțiunile tehnologice, care ar trebui, respectiv, reprezentate de arcul interfeței de control.

Figura 2.

Este o altă chestiune când instrucțiunile tehnologice sunt procesate de tehnologul șef și le sunt aduse modificări (Fig. 3). În acest caz, ele sunt afișate printr-un arc de interfață deja primit, iar obiectul de control este, de exemplu, noi standarde industriale, pe baza cărora se fac aceste modificări.

Figura 3.

Exemplele de mai sus evidențiază natura superficial similară a arcurilor de interfață de intrare și control, cu toate acestea, pentru sistemele din aceeași clasă există întotdeauna anumite distincții. De exemplu, atunci când luăm în considerare întreprinderi și organizații, există cinci tipuri principale de obiecte: fluxurile de materiale(piese, mărfuri, materii prime etc.), fluxuri financiare (numerar și fără numerar, investiții etc.), fluxuri de documente (documente comerciale, financiare și organizatorice), fluxuri de informații (informații, date despre intenții, comenzi orale etc.); .) și resurse (angajați, mașini, mașini etc.). Mai mult, în diverse cazuri, toate tipurile de obiecte pot fi afișate prin arcuri de interfață de intrare și de ieșire, gestionându-le doar pe cele legate de fluxul de documente și informații și numai resurse prin mecanisme arc.

Prezența obligatorie a arcurilor de interfață de control este una dintre principalele diferențe între standardul IDEF0 și alte metodologii ale claselor DFD (Diagrama fluxului de date) și WFD (Diagrama fluxului de lucru).

Al treilea concept de bază al standardului IDEF0 este Descompunerea. Principiul descompunerii este utilizat atunci când un proces complex este împărțit în funcțiile sale componente. În acest caz, nivelul de detaliu al procesului este determinat direct de dezvoltatorul modelului.

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

Modelul IDEF0 începe întotdeauna cu o vedere a sistemului ca un întreg – o unitate funcțională cu arcuri de interfață care se extind dincolo de domeniul luat în considerare. O astfel de diagramă cu un bloc funcțional se numește diagramă de context și este desemnată prin identificatorul „A-0”.

Textul explicativ pentru diagrama de context trebuie să indice Scopul construirii diagramei în formular descriere scurta iar punctul de vedere este fix.

Definirea și formalizarea obiectivului dezvoltării modelului IDEF0 este un punct extrem de important. De fapt, obiectivul definește zonele relevante din sistemul studiat pe care trebuie să se concentreze mai întâi. De exemplu, dacă modelăm activitățile unei întreprinderi cu scopul de a construi un sistem informațional bazat pe acest model în viitor, atunci acest model va fi semnificativ diferit de cel pe care l-am dezvolta pentru aceeași întreprindere, dar cu scopul de optimizare a lanţurilor de aprovizionare.

Punctul de vedere determină direcția principală de dezvoltare a modelului și nivelul de detaliu necesar. O fixare clară a punctului de vedere vă permite să descărcați modelul refuzând detalierea și studierea elementelor individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului. De exemplu, modelele funcționale ale aceleiași întreprinderi din punctul de vedere al tehnologului șef și al directorului financiar vor diferi semnificativ în direcția detalierii lor. Acest lucru se datorează faptului că, în cele din urmă, directorul financiar nu este interesat de aspectele prelucrării materiilor prime pe mașinile de producție, iar tehnologul șef nu are nevoie de diagrame desenate. fluxurilor financiare. Alegerea potrivita punct de vedere reduce semnificativ timpul petrecut pentru construirea modelului final.

În timpul procesului de descompunere, un bloc funcțional care reprezintă sistemul ca întreg într-o diagramă de context este detaliat într-o altă diagramă. Diagrama de al doilea nivel rezultată conține blocuri funcționale care afișează principalele subfuncții ale blocului funcțional al diagramei de context și se numește diagramă Child în raport cu aceasta (fiecare dintre blocurile funcționale aparținând diagramei copil este denumit în mod corespunzător o Cutie Child). La rândul său, blocul funcțional strămoș se numește bloc părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține se numește diagramă părinte (Parent Diagram). Fiecare dintre subfuncțiile unei diagrame copil poate fi detaliată în continuare printr-o descompunere similară a blocului său funcțional corespunzător. Este important de reținut că în fiecare caz de descompunere a unui bloc funcțional, toate arcurile de interfață care intră sau emană din acest bloc sunt fixate pe diagrama copil. Acest lucru realizează integritatea structurală a modelului IDEF0. Principiul descompunerii este prezentat clar în Figura 4. Ar trebui să acordați atenție relației dintre numerotarea blocurilor funcționale și diagramele - fiecare bloc are propriul său număr de serie unic pe diagramă (numărul din colțul din dreapta jos al dreptunghiului) , iar denumirea din colțul din dreapta indică numărul diagramei copil pentru acest bloc . Absența acestei desemnări indică faptul că nu există nicio descompunere pentru acest bloc.

Există adesea cazuri în care arcele individuale de interfață nu au sens să fie luate în considerare în continuare în diagramele copil sub un anumit nivel în ierarhie sau invers - arcele individuale nu au sens practic peste un anumit nivel. De exemplu, nu are sens să afișați un arc de interfață care ilustrează o „piesă” la intrarea în blocul funcțional „Proces pe strung” pe diagramele de niveluri superioare - acest lucru va supraîncărca diagramele și le va face dificil de înțeles. Pe de altă parte, este nevoie de a scăpa de arcuri individuale de interfață „conceptuale” și de a nu le detalia peste un anumit nivel. Pentru a rezolva astfel de probleme, standardul IDEF0 oferă conceptul de tunel. Desemnarea Arrow Tunnel a două paranteze în jurul începutului unui arc de interfață indică faptul că arcul nu a fost moștenit de la un bloc părinte funcțional și apare (din „tunel”) doar în această diagramă. La rândul său, aceeași denumire în jurul capătului (săgeata) arcului de interfață în imediata apropiere a blocului receptor înseamnă faptul că acest arc nu va fi afișat și luat în considerare în diagrama copil a acestui bloc. Cel mai adesea, se întâmplă ca obiectele individuale și arcurile lor de interfață corespunzătoare să nu fie luate în considerare la unele niveluri intermediare ale ierarhiei - în acest caz, ele sunt mai întâi „cufundate în tunel”, apoi, dacă este necesar, „întors din tunel” .

Ultimul dintre conceptele IDEF0 este Glosarul. Pentru fiecare dintre elementele IDEF0: diagrame, blocuri funcționale, arcuri de interfață, standardul existent presupune crearea și menținerea unui set de definiții corespunzătoare, cuvinte cheie, enunțuri narative etc., care caracterizează obiectul afișat de acest element. Acest set se numește glosar și este o descriere a esenței unui element dat. De exemplu, pentru interfața de control arc „ordin de plată”, glosarul poate conține o listă de câmpuri ale documentului corespunzătoare arcului, setul necesar de vize etc. Glosarul completează armonios limbajul grafic vizual, oferind diagramelor informațiile suplimentare necesare.

Figura 4. Descompunerea blocurilor funcționale.

Principii pentru limitarea complexității diagramelor IDEF0

De obicei, modelele IDEF0 conțin informații complexe și concentrate, iar pentru a le limita aglomerația și a le face lizibile, limitele de complexitate corespunzătoare sunt adoptate în standardul corespunzător:

Limitați numărul de blocuri funcționale din diagramă la trei până la șase. Limita superioară (șase) obligă proiectantul să folosească ierarhii atunci când descrie obiecte complexe, iar limita inferioară (trei) asigură că diagrama corespunzătoare are suficiente detalii pentru a justifica crearea acesteia;

Limitarea numărului de arcuri de interfață potrivite pentru un bloc funcțional (ieșind dintr-un bloc funcțional) la patru.
Desigur, nu este deloc necesar să urmați cu strictețe aceste restricții, cu toate acestea, după cum arată experiența, ele sunt foarte practice în munca reală.

Disciplina muncii de grup privind dezvoltarea modelului IDEF0

Standardul IDEF0 conține un set de proceduri care permit dezvoltarea și convenirea unui model de către un grup mare de persoane aparținând diferitelor domenii de activitate ale sistemului modelat. De obicei, procesul de dezvoltare este iterativ și constă din următoarele etape convenționale:

Crearea unui model de către un grup de specialiști în legătură cu diverse domenii ale întreprinderii. Acest grup se numește Autori în termenii IDEF0. Construirea modelului inițial este un proces dinamic în timpul căruia autorii intervievează indivizi competenți cu privire la structura diferitelor procese. Pe baza reglementărilor existente, a documentelor și a rezultatelor sondajului, este creată o schiță de model a modelului.

Distribuirea proiectului pentru revizuire, aprobare și comentariu. În această etapă, proiectul de model este discutat cu o gamă largă de persoane competente (în ceea ce privește cititorii IDEF0) din întreprindere. În acest caz, fiecare dintre diagramele proiectului de model este criticată și comentată în scris, apoi transferată autorului. Autorul, la rândul său, este de acord și în scris cu critica sau o respinge, conturând logica deciziei și returnează proiectul revizuit pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.

Aprobarea oficială a modelului. Modelul aprobat este aprobat de manager grup de lucruîn cazul în care autorii modelului și cititorii nu au niciun dezacord cu privire la adecvarea acestuia. Modelul final este o vedere coerentă asupra întreprinderii (sistemului) dintr-un punct de vedere dat și pentru un scop dat.
Claritatea limbajului grafic IDEF0 face ca modelul să fie complet lizibil chiar și pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru expoziții și prezentări. Pe viitor, pe baza modelului construit, pot fi organizate noi proiecte menite să facă schimbări în întreprindere (în sistem).

Caracteristici ale practicii naționale de utilizare a modelării funcționale folosind IDEF0

În ultimii ani, interesul față de Rusia față de familia de metodologii IDEF a crescut constant. Observ în mod constant acest lucru când mă uit la statisticile accesărilor pe pagina mea web personală (http://www.vernikov.ru), care descrie pe scurt principiile de bază ale acestor standarde. În același timp, aș numi interesul pentru standarde precum IDEF3-5 teoretic, iar pentru IDEF0 destul de practic justificat. De altfel, primele instrumente Case care permit construirea diagramelor DFD și IDEF0 au apărut pe piața rusă în 1996, simultan cu lansarea unei cărți populare despre principiile modelării în standardele SADT.

Cu toate acestea, majoritatea managerilor încă consideră aplicarea practică a modelării în standardele IDEF mai mult ca un tribut adus modei decât ca o modalitate eficientă de optimizare a sistemului existent de management al afacerii. Cel mai probabil, acest lucru se datorează unei lipse pronunțate de informații despre aplicație practică aceste metodologii și cu o părtinire software indispensabilă pentru marea majoritate a publicațiilor.

Nu este un secret pentru nimeni că aproape toate proiectele de sondare și analiză a activităților financiare și economice ale întreprinderilor aflate acum în Rusia sunt legate într-un fel sau altul de construcția de sisteme de management automatizate. Datorită acestui fapt, standardele IDEF, după înțelegerea majorității, au devenit condiționat inseparabile de implementare. tehnologia Informatiei, deși cu ajutorul lor uneori puteți rezolva eficient chiar și mici probleme locale, literalmente cu ajutorul unui creion și hârtie.

Atunci când desfășurați proiecte complexe de anchetă de întreprinderi, dezvoltarea modelelor în standardul IDEF0 vă permite să afișați clar și eficient întregul mecanism al activităților întreprinderii în contextul necesar. Cu toate acestea, cel mai important lucru sunt capabilitățile de colaborare pe care IDEF0 le oferă. În munca mea practică, au fost destul de multe cazuri când construirea unui model a fost realizată cu ajutorul direct al angajaților din diferite departamente. În același timp, consultantul le-a explicat principiile de bază ale IDEF0 și i-a învățat cum să lucreze cu aplicația software corespunzătoare într-un timp destul de scurt. Drept urmare, angajații diferitelor departamente au creat diagrame IDEF ale activităților unității lor funcționale, care trebuiau să răspundă la următoarele întrebări:

Ce primește departamentul ca input?

Ce funcții și în ce ordine sunt îndeplinite în cadrul departamentului?

Cine este responsabil pentru îndeplinirea fiecărei funcții?

După ce se ghidează interpretul atunci când îndeplinește fiecare dintre funcții?

Care este rezultatul muncii departamentului (ieșire)?

După ce s-au convenit asupra schițelor de diagrame în cadrul fiecărui departament specific, acestea sunt asamblate de către consultant într-un model de proiect al întreprinderii, care leagă toate elementele de intrare și de ieșire. În această etapă, sunt înregistrate toate discrepanțele din diagramele individuale și zonele lor controversate. În continuare, acest model trece din nou prin departamente funcționale pentru coordonarea ulterioară și efectuarea ajustărilor necesare. Ca urmare, într-un timp destul de scurt și cu implicarea unui minim de resurse umane din partea companiei de consultanță (și aceste resurse, după cum știm, sunt foarte scumpe), se obține un model IDEF0 al întreprinderii pe „As este” principiul și, cel mai important, reprezintă întreprinderea cu funcții de angajați care lucrează în ea și cunosc temeinic toate nuanțele, inclusiv cele informale. În viitor, acest model va fi transferat pentru analiză și procesare către analiștii de afaceri, care vor căuta „gâtele de sticlă” în managementul companiei și vor optimiza procesele principale, transformând modelul „Așa cum este” în cel corespunzător „Așa cum ar trebui”. Fii” reprezentare. Pe baza acestor modificări se emite o concluzie finală, care conține recomandări pentru reorganizarea sistemului de management.

Desigur, o astfel de abordare necesită o serie de măsuri organizatorice, în primul rând din partea conducerii întreprinderii chestionate. Acest lucru se datorează faptului că această tehnică presupune atribuirea unor responsabilități suplimentare unor angajați pentru a stăpâni și aplica practic noi metodologii. Cu toate acestea, în cele din urmă, acest lucru se justifică de la sine, deoarece încă una sau două ore de muncă de către angajații individuali pe parcursul mai multor zile poate economisi în mod semnificativ bani pentru plata serviciilor de consultanță către o companie terță (care, în orice caz, va distrage atenția acelorași angajați din lucru cu chestionare și întrebări). În ceea ce privește angajații întreprinderii înșiși, nu am întâlnit niciodată o opoziție exprimată din partea lor în practica mea.

Concluzia din toate acestea se poate trage după cum urmează: nu este deloc necesar să veniți singur cu soluții la problemele standard de fiecare dată. Ori de câte ori te confrunți cu nevoia de a analiza unul sau altul sistem functional(de la sistemul de proiectare a navei spațiale până la procesul de pregătire a unei cine complexe) - folosiți metode dovedite și dovedite de-a lungul anilor. Una dintre aceste metode este IDEF0, care vă permite să rezolvați probleme complexe de viață folosind instrumentele sale simple și ușor de înțeles.

O imagine valorează cât o mie de cuvinte

Înțelepciunea populară

Adesea, în munca mea, este nevoie nu doar de a studia și de a rezolva o anumită problemă, ci de a identifica locația acesteia în modelul general de funcționare al companiei. Nu este suficient să înțelegeți că o anumită unitate nu funcționează corect, este important să înțelegeți cum interacționează cu ceilalți. În caz contrar, este imposibil să identifici toate problemele existente și să le selectezi metoda optima rezolvarea problemei. Și pentru aceasta trebuie să studiați activitatea companiei și să elaborați modelul funcțional al acesteia.

Desigur, în teorie, managerul ar trebui să aibă un model funcțional al activității companiei și nu contează dacă vorbim despre organizarea muncii unui depozit sau a unui sistem IT de la lead la aplicație. Dar, în realitate, aproape niciodată nu se dovedește a fi și, prin urmare, în procesul de studiu și de a găsi o soluție la problema pusă de client, creez și un model funcțional al activității companiei sau un anumit proces(funcţionează) în mod independent.

Câteva cuvinte despre avantajele graficii

După cum știți, modelele funcționale IDEF0 sunt întotdeauna diagrame grafice. Au propriile lor caracteristici și reguli de compunere. Vom vorbi despre asta puțin mai târziu. Acum aș dori să dau câteva exemple despre eficiența graficii. De ce mă concentrez pe asta? Cel mai probabil, după declarația mea despre necesitatea unui model funcțional al activității companiei, mulți oameni au crezut că toate acestea nu sunt necesare, ar putea explica în cuvinte cum funcționează cutare sau cutare funcție în companie. Despre asta vreau să vorbesc.

Să începem cu o scurtă excursie în istorie. Să ne întoarcem la îndepărtatul an 1877, în timpul războiului ruso-turc. Atunci imprimanta Sytin a folosit pentru prima dată grafica pentru a descrie operațiunile militare. Acum toate acestea ne sunt familiare; atunci când descriem orice bătălie, în fața ochilor noștri apar cărți cu săgeți, care arată clar cursul bătăliei. Și în acele zile, acțiunile militare erau descrise în cuvinte. Pentru fiecare bătălie sunt multe, multe cuvinte. Și până la urmă a fost foarte greu de înțeles ce se întâmplă.

Prin urmare, ideea lui Sytin a fost cu adevărat revoluționară - a început să imprime copii litografice ale hărților care indică fortificațiile și locațiile unităților militare. Aceste carduri au fost numite „Pentru cititorii de ziare. Alocație.” Ideea s-a dovedit a fi atât de relevantă încât prima ediție a „Beneficiilor” s-a vândut instantaneu. Și atunci astfel de aplicații au fost la mare căutare. Motivul este evident. Grafica a ajutat la înțelegerea a ceea ce era aproape imposibil de înțeles doar cu cuvinte.

De asemenea, pot da un exemplu similar de neputință a descrierilor verbale din propria mea practică. Unul dintre clienții mei mi-a cerut cu adevărat să îmi asum implementarea unui sistem ERP pentru compania sa. Când am întrebat dacă au specificații tehnice, am primit răspunsul: „Da, au. Dar sunt 400 de pagini.” În același timp, clientul s-a plâns foarte mult că colegii mei, pe care i-a contactat anterior, fie au refuzat cu totul proiectul, fie au cotat prețuri vădit umflate. După ce am văzut că specificația tehnică avea de fapt 400 de pagini și consta doar dintr-o descriere text, am înțeles motivele comportamentului dezvoltatorilor. Citirea unui astfel de volum de text, adâncirea în el, înțelegerea tuturor nuanțelor doar pentru a înțelege sarcina și a numi prețul este într-adevăr foarte dificilă.

I-am oferit acestui client Opțiune alternativă- descrie tot ceea ce este posibil grafic sub formă de notații. I-a arătat exemple de modeling. Drept urmare, acum își regândesc dorințele și designul specificațiilor tehnice.

Cunosc și multe alte exemple în care modelarea grafică a proceselor de afaceri i-a ajutat atât pe colegii mei, consultanții și dezvoltatorii de afaceri, cât și pe oamenii de afaceri înșiși.

De ce este acest lucru important pentru munca mea?

Munca mea implică întotdeauna schimbarea sistemului existent. Și pentru a face modificări și a obține rezultatul dorit, trebuie să studiați ceea ce există deja. Și nu contează ce facem exact - configurarea sau instalarea unui sistem CRM de la zero, crearea unui sistem ERP eficient, integrarea diferitelor sisteme pentru a crește automatizarea muncii în general. În orice caz, mai întâi trebuie să vă faceți o idee schema existenta de lucru și abia după aceea puteți propune unele modificări și vă puteți gândi la opțiuni pentru rezolvarea problemei.

După ce am studiat starea actuală, eu, ca orice alt specialist terț, creez o propunere comercială în care îmi dezvălui cât mai detaliat viziunea asupra situației actuale, precum și acțiunile care trebuie efectuate pentru rezolva problema și, bineînțeles, rezultatul așteptat.

Astfel de rapoarte de anchetă de muncă sunt voluminoase și ocupă mai mult de o pagină, ceea ce, pe de o parte, este necesar, dar, pe de altă parte, complică percepția. La început, la fel ca mulți alții, am crezut că rapoartele voluminoase sunt bune, pentru că o persoană plătește pentru muncă și trebuie să îi oferi cât mai multe informații detaliate.

Greșeli comune

Modelarea funcțională se realizează folosind o varietate de instrumente, inclusiv cele care nu sunt destinate modelării. În acest din urmă caz, nu există nicio verificare a erorilor și nicio restricție standard. Dorința de a crește vizibilitatea și lipsa de experiență duc adesea la greșeli.

Folosind culori diferite

Toate elementele din diagramă sunt la fel de importante. În modelarea funcțională nu există mai mult sau mai puțin elemente importante. Dispariția oricăruia va duce la întreruperea procesului și la defecte de fabricație.

Adesea, atunci când modelează pe hârtie sau în diverse programe, utilizatorii încearcă să mărească vizibilitatea folosind culori diferite. Aceasta este una dintre cele mai frecvente greșeli. De fapt, utilizarea de săgeți și blocuri multicolore adaugă doar confuzie suplimentară și, de asemenea, distorsionează percepția diagramei.

Modelul dvs. ar trebui să poată fi citit în alb și negru, fără alte scheme de culori. Această abordare ajută simultan la evitarea neînțelegerilor și disciplinează creatorul modelului, rezultând o lizibilitate și alfabetizare crescute a modelului.

Prea multe blocuri

Când elaborează un model, ei încearcă adesea să afișeze pe o singură foaie toate nuanțele muncii companiei cu toate detaliile. Rezultatul este un număr foarte mare de blocuri cu un număr mare de săgeți de control. În acest caz, lizibilitatea este pierdută.

Cea mai bună opțiune sunt suficiente detalii pentru a înțelege problema și nimic mai mult. Detaliile detaliate ale activității fiecărui departament sau chiar angajat pot fi dezvăluite atunci când alegeți o vizualizare detaliată a unui anumit proces. Și o astfel de structură este creată numai dacă este cu adevărat necesară pentru muncă sau pentru luarea deciziilor.

Încălcarea structurii la efectuarea ajustărilor

Aveți grijă să vă asigurați că nu există confuzii sau procese fără elemente de intrare, ieșire sau alte elemente importante. De exemplu, dacă în exemplul de mai sus, consider că este necesar să mut punctul de vedere la copywriter, voi elimina autorul din schemă. Și apoi elementele de control „experiența autorului și sursele terțe”, precum și planul de publicare, devin inutile. La urma urmei, autorul le folosește. Un copywriter lucrează cu un fișier audio. Și dacă rămân înăuntru schema generala, apoi la detaliere va duce la o direcție neclară și va provoca confuzie.

La fel, dacă decid să adaug un bloc, este important să mă asigur că are și toate atributele necesare. Grija este foarte importantă aici, deoarece atunci când modelați procese complexe de afaceri, modificările într-o parte a modelului pot duce la schimbări în alta. Cu siguranță trebuie incluse.

Reguli pentru denumirea elementelor de control și a blocurilor

Este important să rețineți o regulă simplă: săgețile de control sunt numite substantive, blocurile sunt numite verbe. Acest lucru este acceptat în standardul IDEF0 și această abordare ajută la evitarea confuziei și erorilor.

Cel mai adesea, greșelile sunt făcute la denumirea blocurilor. De exemplu, în loc de „Creați un articol”, ei scriu „Crearea unui articol”. Blocurile din această abordare sunt acțiuni și, prin urmare, ar trebui să fie întotdeauna verbe.

Beneficiile utilizării IDEF0

• Primul beneficiu este evident – ​​vizibilitatea.Începeți să înțelegeți cum funcționează acest sau acel sistem și, de asemenea, puteți explica clar unde sunt „punctele subțiri” din acest sistem și cum soluțiile dvs. vă vor ajuta să scăpați de ele.
• Înțelegerea reciprocă și absența discrepanțelor. Când discutați despre munca unei companii folosind un model funcțional, aveți blocuri vizuale și intuitive de sarcini cu elemente de control. În plus, modelarea funcțională presupune crearea, dacă este necesar, a unui glosar în care sunt dezvăluite convențiile și termenii. Drept urmare, dumneavoastră și clientul, managerul și alți angajați vorbiți aceeași limbă atunci când discutați o problemă.
• Simplitate și viteză mare de creare a modelului. Desigur, să înveți să modelezi nu este atât de ușor pe cât pare. La urma urmei, o diagramă este, în esență, o prezentare super-densă a informațiilor, care este foarte bună pentru înțelegere, dar pentru a implementa o astfel de prezentare este nevoie de abordare specială. Creierul analistului acționează în acest caz ca o presă foarte puternică, pe de o parte, și ca un filtru, pe de altă parte. Dar, cu experiență, acest proces devine foarte rapid. Drept urmare, obțineți un instrument care vă va ajuta să vă dați seama ce se întâmplă într-un anumit sistem și cu ajutorul unui instrument creat într-un timp scurt. ajutor vizual ilustra Puncte importante colegi sau clienți.
• Disciplina si fara greseli. Standardul IDEF0 presupune limite stricte si reguli. Această abordare creează disciplină, iar obiceiul de a acționa în cadrul standardului ajută la evitarea greșelilor datorate neatenției. Orice încălcare a standardului devine imediat vizibilă.

Care este dificultatea utilizării IDEF0

Este important de înțeles că doar în cele mai simple cazuri doi analiști de afaceri vor crea exact aceleași modele funcționale pentru a descrie activitatea companiei. Orice model este o reflectare a experienței analistului, profundă a înțelegerii afacerii pe care încearcă să o descrie și, de asemenea, într-un fel, punctul său de vedere personal asupra acestei afaceri. Acestea. o persoană dezvoltă un model de afaceri din punctul de vedere al unui manager, de parcă acesta ar fi managerul.

În același timp, cred că un analist de afaceri nu este tocmai o profesie; fiecare manager de afaceri sau dezvoltator al unor sisteme care analizează afacerea și se străduiește să construiască cel mai eficient sistem este angajat în analiza de afaceri. Pentru acești oameni și în aceste scopuri este conceput instrumentul IDEF0.

Prin urmare, atunci când se elaborează un model de business funcțional „așa cum este”, este foarte important să se consulte în permanență cu șeful companiei pentru a nu face greșeli care vor atrage automat erori în fazele de descompunere. De asemenea, în etapele ulterioare, pot fi necesare aprobări suplimentare de la șefii de departamente și angajați. Numai dacă modelul tău funcțional „ca atare” reflectă cu adevărat starea reală a lucrurilor, poți face orice modificări și sugestii. Și pentru a obține rezultate de înaltă calitate într-o astfel de muncă, în primul rând, sunt necesare experiență practică și cunoașterea caracteristicilor unui anumit tip de afacere.

Mai multe articole pe acest subiect.

6.2. Scopul și componența metodologiei SADT (IDEF0)

Metodologia SADT (Tehnica de analiză și proiectare structurată - metodologie de analiză și proiectare structurală) este un set de metode, reguli și proceduri concepute pentru a construi un model funcțional al unui sistem.

Dezvoltarea acestei metodologii a început cu Douglas Ross (SUA) la mijlocul anilor '60. secolul XX De atunci, analiștii de sistem de la SofTech, Inc. a îmbunătățit SADT și l-a folosit pentru a rezolva o gamă largă de probleme. Software de retea telefonica, diagnosticare, pe termen lung si planificare strategica, fabricarea și proiectarea asistate de calculator, configurarea sistemelor informatice, pregătirea personalului, managementul financiar și logistic sunt câteva dintre domenii. aplicare eficientă SADT. Gamă largă zonele indică versatilitatea și puterea metodologiei SADT. Programul Integrated Computer Aided Manufacturing (ICAM) al Departamentului de Apărare al SUA a recunoscut utilitatea SADT. Acest lucru a dus la publicarea unei părți a acestuia în 1981, numită IDEF0 (Icam DEFinition), ca standard federal pentru dezvoltarea de software. Sub acest nume, SADT a început să fie folosit de mii de specialiști din organizații militare și industriale. Ultima editie Standardul IDEF0 a fost lansat în decembrie 1993. Institutul Național de Standarde și Tehnologie (NIST).

Această metodologie concurează cu metodele orientate pe fluxul de date (DFD) atunci când descrie aspectul funcțional al unui sistem informațional. În schimb, IDEF0 permite:

Descrieți orice sisteme, nu doar sisteme informatice (DFD este destinat să descrie software);

Creați o descriere a sistemului și a mediului său extern înainte de a determina cerințele finale pentru acesta. Cu alte cuvinte, folosind această metodologie, puteți construi și analiza treptat un sistem chiar și atunci când este încă dificil să vă imaginați implementarea lui.

Astfel, IDEF0 poate fi utilizat în etapele incipiente ale construirii unei game largi de sisteme. În același timp, poate fi folosit pentru analiza funcției sistemele existenteși dezvoltarea de soluții pentru a le îmbunătăți.

Baza metodologiei IDEF0 este un limbaj grafic pentru descrierea proceselor. Un model în notația IDEF0 este o colecție de diagrame ordonate ierarhic și interconectate. Fiecare diagramă este o unitate de descriere a sistemului și se află pe o foaie separată.

Modelul (AS-IS, TO-BE sau SHOULD-FI) poate conține 4 tipuri de diagrame [ , ]:

Diagrama de context;

Diagrame de descompunere;

Diagramele arborelui nodurilor;

Diagrame numai pentru expunere (FEO).

Diagrama de context (diagrama de nivel superior), fiind vârful structurii arborescente a diagramelor, arată scopul sistemului (funcția principală) și interacțiunea acestuia cu mediul extern. Fiecare model poate avea o singură diagramă de context. După descrierea funcției principale, se realizează descompunerea funcțională, adică se determină funcțiile care o compun pe cea principală.

În continuare, funcțiile sunt împărțite în subfuncții și așa mai departe până la atingerea nivelului de detaliu necesar al sistemului studiat. Sunt numite diagrame care descriu fiecare astfel de fragment al sistemului diagrame de descompunere . După fiecare sesiune de descompunere, se desfășoară sesiuni de examinare - experții în materie indică corespondența proceselor reale cu diagramele create. Inconsecvențele găsite sunt eliminate, după care începe detalierea ulterioară a proceselor.

Diagrama arborelui nodului arată dependența ierarhică a funcțiilor (lucrărilor), dar nu și conexiunile dintre ele. Pot fi mai multe dintre ele, deoarece arborele poate fi construit la o adâncime arbitrară și dintr-un nod arbitrar.

Diagrame de expunere sunt construite pentru a ilustra fragmente individuale ale modelului pentru a afișa un punct de vedere alternativ asupra proceselor care au loc în sistem (de exemplu, din punctul de vedere al managementului organizației).

6.3. Elemente de notație grafică IDEF0

Metodologia IDEF0 a găsit o largă acceptare și aplicare, în primul rând datorită notației grafice simple utilizate pentru construirea modelului. Componentele principale ale modelului sunt diagramele. Acestea afișează funcțiile sistemului sub formă de dreptunghiuri, precum și conexiunile dintre acestea și mediul extern prin săgeți. Folosind doar două primitive grafice (dreptunghi și săgeată) puteți explica rapid regulile și principiile diagramei IDEF0 persoanelor care nu sunt familiarizate cu această metodologie. Acest avantaj vă permite să conectați și să activați activitățile clientului în descrierea proceselor de afaceri folosind un limbaj grafic formal și vizual.

Figura următoare prezintă principalele elemente ale notației grafice IDEF0.

Orez. 6.1. Elemente de notație grafică IDEF0

Dreptunghiul reprezintă muncă (proces, activitate, funcție sau sarcină) , care are un scop fix și duce la un rezultat final. Numele lucrării ar trebui să exprime acțiunea (de exemplu, „Fabricarea unei piese”, „Calculul vitezelor admise”, „Crearea unei declarații a centrului de lucru nr. 3”).

Interacțiunea lucrărilor dintre ele și lumea exterioară este descrisă sub formă de săgeți. IDEF0 distinge 5 tipuri de săgeți :

- Intrare (Intrare în engleză) - material sau informație care este folosită și transformată prin muncă pentru a obține un rezultat (ieșire). Intrarea răspunde la întrebarea „Ce se procesează?” Intrarea poate fi fie un obiect material (materii prime, piesă, carnet de examen) fie unul care nu are contururi fizice clare (o interogare în baza de date, întrebarea unui profesor). Este permis ca lucrarea să nu aibă o singură săgeată de intrare. Săgețile de intrare sunt întotdeauna desenate intrând pe marginea stângă a lucrării;

- Control (English control) – date de control, reglementare și normative care ghidează munca. Conducerea răspunde la întrebarea „În conformitate cu ce lucrare se desfășoară?” Managementul influențează munca, dar nu este transformat de ea, adică. actioneaza ca o limitare. Managementul poate include reguli, standarde, reglementări, prețuri sau instrucțiuni verbale. Săgețile de control sunt desenate intrând în marginea de sus a lucrării. Dacă, atunci când construiți o diagramă, apare întrebarea despre cum să desenați corect o săgeată de sus sau la stânga, atunci se recomandă să o desenați ca intrare (săgeata din stânga);

- Ieșire (ieșire în limba engleză) – material sau informații care reprezintă rezultatul muncii. Rezultatul răspunde la întrebarea „Care este rezultatul muncii?” Ieșirea poate fi fie un obiect material (piesă, mașină, documente de plată, extras) fie un obiect intangibil (eșantionarea datelor dintr-o bază de date, răspunsul la o întrebare, instrucțiuni verbale). Sunt desenate săgeți de ieșire emanând din marginea dreaptă a lucrării;

- mecanism (mecanismul englez) – resurse care fac treaba. Mecanismul răspunde la întrebarea „Cine lucrează sau prin ce?” Mecanismul poate fi personalul întreprinderii, un student, o mașină, un echipament sau un program. Săgețile mecanismului sunt trase intrând în marginea inferioară a lucrării;

- apel (apel în limba engleză) - săgeata indică faptul că o parte a lucrării este efectuată în afara blocului în cauză. Săgețile de ieșire sunt desenate care emană de la marginea de jos a lucrării.

6.4. Tipuri de conexiuni între locuri de muncă

După determinarea compoziției funcțiilor și a relațiilor dintre ele, se pune întrebarea despre alcătuirea corectă a acestora (combinarea) în module (subsisteme). Aceasta înseamnă că fiecare funcție individuală trebuie să rezolve o sarcină strict definită. În caz contrar, este necesară descompunerea sau separarea ulterioară a funcțiilor.

Atunci când combinați funcții în subsisteme, este necesar să faceți eforturi pentru a vă asigura că conectivitatea internă (între funcțiile dintr-un modul) este cât mai puternică posibil, iar conectivitatea externă (între funcțiile incluse în diferite module) este cât mai slabă posibil. Pe baza semanticii conexiunilor a metodologiei, vom introduce o clasificare a conexiunilor dintre functii (lucrari). Această clasificare este o extensie. Tipurile de legături sunt date în ordinea descrescătoare a semnificației lor (tăria de legare). În exemplele date, liniile groase evidențiază funcții între care există tipul de conexiune luat în considerare.

1. Conexiune ierarhică (relație „parte” - „întreg”) are loc între o funcţie şi subfuncţiile din care este compusă.

Orez. 6.2. Relație ierarhică

2. Conexiune de reglementare (control, subordonat). reflectă dependența unei funcții de alta, atunci când rezultatul unei lucrări este direcționat pentru a controla alta. Funcția din care provine managementul ar trebui considerată de reglementare sau control, iar funcția în care este inclusă ar trebui considerată subordonată. Distinge comunicare directă cu conducerea , când controlul este transferat de la un loc de muncă superior la unul inferior (Fig. 6.3) și feedback-ul managementului când controlul este transferat de la inferior la superior (Fig. 6.4).

3. Conexiune funcțională (tehnologică). apare atunci când ieșirea unei funcții servește ca intrare pentru următoarea funcție. Din punct de vedere al curgerii obiectelor materiale această legătură arată tehnologia (secvența de lucru) pentru prelucrarea acestor obiecte. Distinge conexiune directă de intrare , când ieșirea este transferată de la o operațiune superioară la una inferioară (Fig. 6.5) și feedback de conectare , când ieșirea este transmisă de la cea inferioară la cea superioară (Fig. 6.6).

Orez. 6.5. Conexiune directă prin intrare	Orez. 6.6. Feedback de conectare

4. Comunicarea Consumatorului apare atunci când ieșirea unei funcții servește ca mecanism pentru următoarea funcție. Astfel, o funcție consumă resurse produse de alta.

Orez. 6.7. Comunicarea Consumatorului

5. Conexiune logică observate între funcţii omogene din punct de vedere logic. Astfel de funcții, de regulă, îndeplinesc aceeași muncă, dar în moduri diferite (alternative) sau folosind date de intrare diferite (materiale).

Orez. 6.8. Conexiune logică

6. Comunicare colegială (metodologică). apare între funcțiile al căror algoritm de funcționare este determinat de același control. Un analog al unei astfel de comunicări este munca comună a angajaților unui departament (colegi), subordonați șefului, care dă instrucțiuni și ordine (semnale de control). O astfel de conexiune apare și atunci când algoritmii pentru funcționarea acestor funcții sunt determinați de același suport metodologic (SNIP, GOST, materiale de reglementare oficiale etc.), care servește drept control.

Orez. 6.9. Legătura metodică

7. Conexiune la resurse apare între funcțiile care folosesc aceleași resurse pentru munca lor. Funcțiile dependente de resurse, în general, nu pot fi executate simultan.

Orez. 6.10. Conexiune la resurse

8. Comunicarea informațională apare între funcțiile care folosesc aceleași informații ca și intrare.

Orez. 6.11. Comunicarea informațională

9. Conexiune temporară apare între funcții care trebuie executate simultan înainte sau simultan după altă funcție.

Pe lângă cazurile indicate în figură, această legătură apare și între alte combinații de control, intrare și mecanism care intră în aceeași funcție.

Orez. 6.12. Conexiune temporară

10. Conexiune aleatorie apare atunci când există puțină sau deloc o legătură specifică între funcții.

Orez. 6.13. Conexiune aleatorie

Dintre tipurile de conexiuni de mai sus, cea mai puternică este conexiunea ierarhică, care, în esență, determină combinarea funcțiilor în module (subsisteme). Legăturile de reglementare, funcționale și de consum sunt oarecum mai slabe. Funcțiile cu aceste relații sunt de obicei implementate într-un singur subsistem. Conexiunile logice, colegiale, de resurse și informații sunt printre cele mai slabe. Funcțiile care le au, de regulă, sunt implementate în diferite subsisteme, cu excepția funcțiilor omogene din punct de vedere logic (funcții conectate printr-o conexiune logică). Comunicarea temporală indică o dependență slabă a funcțiilor unele față de altele și necesită implementarea lor în module separate.

Astfel, atunci când combinați funcții în module, primele cinci tipuri de conexiuni sunt cele mai de dorit. Este mai bine să implementați funcții conectate prin ultimele cinci legături în module separate.

IDEF0 are convenții (reguli și linii directoare) pentru crearea diagramelor care sunt concepute pentru a face modelul mai ușor de citit și examinat [ , ]. Unele dintre aceste reguli sunt acceptate automat de instrumentele CASE, în timp ce altele trebuie aplicate manual.

1. Înainte de a construi un model, este necesar să decideți ce model(e) de sistem va fi construit. Aceasta presupune determinarea tipului acestuia AS-IS, TO-BE sau SHOULD-BE, precum și determinarea poziției din punctul de vedere al cărui model este construit. Un „punct de vedere” este cel mai bine gândit ca locul (poziția) unei persoane sau obiect în care trebuie să stați pentru a vedea un sistem în acțiune. De exemplu, la construirea unui model de funcționare a unui magazin alimentar, puteți alege un vânzător, casier, contabil sau director dintre posibilii candidați din punctul de vedere al cărui sistem este luat în considerare. De obicei, este selectat un punct de vedere care acoperă cel mai complet toate nuanțele funcționării sistemului și, dacă este necesar, pentru unele diagrame de descompunere, se construiesc diagrame FEO care afișează un punct de vedere alternativ.

2. Diagrama de context afișează un bloc care arată scopul sistemului. Se recomandă afișarea a 2-4 săgeți care intră și ies pe fiecare parte.

3. Numărul de blocuri de pe diagramele de descompunere este recomandat în intervalul 3–6. Dacă o diagramă de descompunere are două blocuri, atunci de obicei nu are sens. În prezența cantitate mare diagrama bloc devine suprasaturată și greu de citit.

4. Blocurile dintr-o diagramă de descompunere trebuie aranjate de la stânga la dreapta și de sus în jos. Acest aranjament vă permite să reflectați mai clar logica și succesiunea muncii. În plus, traseele săgeților vor fi mai puțin confuze și vor avea un număr minim de intersecții.

5. Absența atât a săgeților de control, cât și a săgeților de intrare pentru o funcție nu este permisă. Aceasta înseamnă că lansarea acestei funcții nu este controlată și poate avea loc în orice moment arbitrar sau niciodată deloc.

Orez. 6.14. Funcție fără control și intrare

Un bloc cu doar control poate fi considerat ca un apel într-un program la o funcție (procedură) fără parametri. Dacă un bloc are o intrare, atunci este echivalent cu apelarea unei funcții cu parametri în program. Astfel, un bloc fără control și intrare este echivalent cu o funcție care nu este niciodată chemată pentru execuție în program.

În fig. 6.7–6.12, afișând fragmente de diagrame IDEF0, există blocuri fără intrare și control. Aceasta nu ar trebui considerată o eroare, deoarece una dintre aceste săgeți este destinată să fie acolo.

6. Fiecare bloc trebuie să aibă cel puțin o ieșire.

Orez. 6.15. Funcție fără ieșire

Munca fără rezultate nu are sens și nu trebuie modelată. Excepție fac lucrările afișate în modelul AS-IS. Prezența lor indică ineficiența și imperfecțiunea proceselor tehnologice. În modelul TO-BE, aceste activități ar trebui să lipsească.

7. Când construiți diagrame, ar trebui să minimizați numărul de intersecții, bucle și viraje ale săgeților.

8. Feedback-urile și iterațiile (acțiunile ciclice) pot fi descrise folosind arce inverse. Feedback-ul de intrare este desenat ca o buclă „inferioară”, feedback-ul de control ca o buclă „superioară” (vezi Figurile 6.4 și 6.6).

9. Fiecare bloc și fiecare săgeată de pe diagrame trebuie să aibă un nume. Este permisă utilizarea ramificării (descompunere) sau îmbinării (compoziției) săgeților. Acest lucru se datorează faptului că aceleași date sau obiecte generate de un job pot fi utilizate în mai multe alte joburi simultan. În schimb, aceleași sau omogene date și obiecte generate de diferite joburi pot fi folosite în același loc.

Orez. 6.16. Săgeți ramificate

În acest caz, este posibil să atribuiți nume de calificare diferitelor ramuri ale săgeții după ramificare (înainte de îmbinare). Dacă vreo ramură nu este numită după ramură, atunci numele ei este considerat a corespunde cu numele săgeții scrise înainte de ramură.

Deci, în fig. 6.16, controalele incluse în blocurile „Fabricarea pieselor” și „Asamblarea produsului” au semnificații clarificatoare și fac parte integrantă din controlul mai general „Desene”. Toate desenele sunt folosite pentru a opera blocul de control al calității.

Nu este permis să desenați săgeți pe diagramă atunci când acestea nu sunt denumite înainte și după ramură. În fig. 6.17 săgeata inclusă în blocul „Generare de instrucțiuni standard” nu are un nume înainte și după ramură, ceea ce este o eroare.

Orez. 6.17. Denumirea incorectă a săgeților

10. La construirea diagramelor, mecanismul de tunel cu săgeți poate fi folosit pentru o mai bună lizibilitate. De exemplu, pentru a nu aglomera diagramele de nivel superior (părinte) cu detalii inutile, în diagramele de descompunere începutul arcului este plasat într-un tunel.

Orez. 6.18. Tunnel cu săgeți

În acest exemplu, la construirea unui model de conducere Petrecerea de Anul Nou mecanismul „două axe” nu va fi afișat pe diagramele nivelurilor superioare, la citirea căreia poate apărea o întrebare corectă: „De ce sunt necesare două axe la petrecerea de Anul Nou?”

În mod similar, puteți face un tunel cu scopul opus de a preveni apariția săgeții pe diagrame niveluri inferioare. În acest caz, parantezele sunt plasate la capătul săgeții. În diagrama de context (vezi Fig. 6.21), mecanismul „Track Service Engineer”, inclus în blocul „Determinarea vitezelor admisibile”, este tunelizat. Această decizie a fost luată deoarece inginerul este direct implicat în toate lucrările afișate pe diagrama de descompunere a acestui bloc (vezi Fig. 6.22). Pentru a evita afișarea acestei conexiuni și pentru a evita aglomerarea diagramei de descompunere, săgeata a fost tunelată.

11. Toate săgețile care intră și ies din bloc, atunci când se construiește o diagramă de descompunere pentru acesta, trebuie să fie afișate pe acesta. Excepția sunt săgețile tunelizate. Numele săgeților transferate în diagrama de descompunere trebuie să se potrivească cu numele indicate pe diagrama de nivel superior.

12. Dacă două săgeți sunt paralele (începând de la aceeași față a unei lucrări și terminând pe aceeași față a altei lucrări), atunci, dacă este posibil, acestea ar trebui combinate și numite un singur termen.

Orez. 6.19. Îmbinarea conexiunilor

13. Fiecare bloc de pe diagrame trebuie să aibă propriul său număr. Numerele diagramelor sunt folosite pentru a indica poziția oricărei diagrame sau bloc în ierarhie. Un bloc dintr-o diagramă de nivel superior este desemnat cu 0, blocurile din diagramele de al doilea nivel cu numere de la 1 la 9 (1, 2, ..., 9), blocurile de pe al treilea nivel cu două numere, primul dintre care indică numărul blocului detaliat din diagrama părinte și al doilea număr al blocului în ordine pe diagrama curentă (11, 12, 25, 63), etc. Diagrama de context are denumirea „A - 0”, diagrama de descompunere al primului nivel este „A0”, diagramele de descompunere ale nivelurilor următoare sunt marcate cu litera „A” urmată de numărul blocului care se descompune (de exemplu, „A11”, „A12”, „A25”, „ A63"). Figura prezintă o diagramă arborescentă tipică (diagrama arborescentă a nodurilor) cu numerotare.

Orez. 6.20. Ierarhia diagramei

În instrumentele moderne CASE, mecanismele de numerotare a lucrărilor sunt acceptate automat. Instrumentele CASE oferă, de asemenea, construcția automată a diagramelor arbore de noduri care conțin doar relații ierarhice. Vârful unei astfel de diagrame poate fi orice nod (bloc) și poate fi construit la orice adâncime.

6.6. Un exemplu de construire a unui model IDEF0 pentru un sistem de determinare a vitezelor admisibile

Calcularea vitezei admise a trenului este o sarcină de inginerie care necesită multă muncă. Când un tren trece prin orice secțiune, viteza reală a trenului nu trebuie să depășească viteza maximă admisă. Această viteză maximă admisă este stabilită pe baza experienței de operare și a testelor special efectuate privind dinamica mișcării și impactul asupra căii de rulare a materialului rulant. Nedepășirea acestei viteze garantează siguranța circulației trenurilor, condiții confortabile de circulație pentru pasageri etc. Acestea sunt determinate în funcție de tipul materialului rulant (marca locomotivei și tipul vagoanelor), parametrii structurii superioare a căii de cale (tipul de șine, balast, diagramă traversă) și plan (curbe de rază, curbe de tranziție, cote exterioare șine etc.). De regulă, pentru a stabili viteze admise, este necesar să se determine cel puțin două (pe linii drepte) și cinci (în curbe), dintre care viteza finală admisă este selectată ca cea mai mică dintre toate cele calculate. Calculul acestor viteze este reglementat de Ordinul Ministerului Căilor Ferate din Rusia nr. 41 din 12 noiembrie 2001 „Norme pentru vitezele admise ale materialului rulant pe căile ferate cu ecartament de 1520 (1524) mm ale Transportului Feroviar Federal”.

După cum sa menționat, construcția modelului IDEF0 începe cu reprezentarea întregului sistem sub forma unei componente simple (diagrama de context). Această diagramă afișează scopul (funcția principală) a sistemului și datele necesare de intrare și ieșire, informații de control și de reglementare, precum și mecanisme.

Diagrama de context pentru problema determinării vitezelor admisibile este prezentată în Fig. 6.21. Pentru construirea modelului a fost folosit produsul BPwin 4.0 de la Computer Associates.

Orez. 6.21. Diagrama de context a sistemului de determinare a vitezelor admisibile (metodologia IDEF0)

La fel de informații generale, pe baza cărora se determină vitezele admise, se folosesc următoarele:

Datele proiectului pentru o linie nouă sau proiect de reconstrucție (conțin toate informațiile necesare implementării proiectului, și anume kilometraj, axele punctelor separate, planul liniei etc.);

Profil longitudinal detaliat (conține informații similare cu cele discutate mai sus);

Pașaportul distanței pistei (conține informații similare cu cele discutate mai sus, precum și informații despre suprastructura pistei (VSP));

Date privind rezultatele studierii planului căii utilizând o mașină de măsurare a căii;

Lista cotelor șinelor exterioare în curbe (conține informații despre planul căii).

Unele dintre informațiile de bază pot fi preluate din diferite surse. În special, informațiile despre plan (parametrii curbei) pot fi preluate din proiectarea unei linii noi sau a unui proiect de reconstrucție, un profil longitudinal detaliat, un certificat de distanță de cale, etc.

Date de control sunt:

Instrucțiuni de la șeful serviciului de cale rutieră sau Departamentul de Căi și Structuri al JSC Căile Ferate Ruse pentru calcul;

Ordinul nr. 41, cuprinzând informații de reglementare și de referință, proceduri și formule pentru determinarea vitezelor admisibile;

Informații despre traficul trenurilor curent sau planificat (date despre mărcile de locomotive în circulație și tipurile de vagoane utilizate);

Informații despre reparațiile planificate ale căii, reconstrucția și reconstrucția structurilor și dispozitivelor.

Rezultatul funcționarea sistemului ar trebui să fie:

Liste de viteze admise, care conțin toate tipurile de viteze calculate și care să permită stabilirea motivului limitării acestora;

Fișe ale Ordinului șefului de drum privind stabilirea vitezelor admise pe porțiuni și puncte separate (Ordinul „N”) în conformitate cu formularul acceptat pe drum. Ordinul „N” aprobat stabilește oficial vitezele admise ale trenului;

Formularele standard nr. 1, 1a și 2, care conțin viteze admise planificate pentru elaborarea orarelor trenurilor.

Vitezele cuprinse în Ordinul „N” și formularele standard pot diferi de cele calculate și prezentate în foile de viteză admise. Acest lucru se datorează faptului că ele reflectă limitele de viteză nu numai asupra proiectării materialului rulant, parametrilor și curbelor VSP, ci și asupra stării dispozitivelor și structurilor (deformarea patului drumului, dezalinierea suporturilor rețelei aeriene de contact etc. ). În plus, acestea sunt ajustate ținând cont de reparațiile planificate ale căii, reconstrucția și reconstrucția structurilor și dispozitivelor etc.

Odată construită, diagrama de context este detaliată folosind o diagramă de descompunere de prim nivel. Această diagramă afișează funcțiile sistemului care trebuie implementate în cadrul funcției de bază. Se numește diagrama pentru care s-a efectuat descompunerea, în raport cu diagramele care o detaliază părintească . O diagramă de descompunere în raport cu părintele ei se numește filială .

Diagrama de descompunere a primului nivel pentru problema luată în considerare este prezentată în Fig. 6.22. De regulă, atunci când se construiește o diagramă de descompunere, funcția originală (descompusă) este împărțită în 3-8 subfuncții (blocuri). În acest caz, se recomandă aranjarea blocurilor pe diagrama de descompunere de la stânga la dreapta, de sus în jos, astfel încât succesiunea și logica interacțiunii subfuncțiilor să fie mai bine vizibile.

Orez. 6.22. Diagrama de descompunere la primul nivel (metodologia IDEF0)

Ordinea de execuție a funcțiilor pentru rezolvarea problemei luate în considerare este următoarea:

Introducerea și ajustarea informațiilor și datelor de reglementare și de referință privind tronsoanele de drum (blocurile 1 și 2);

Pregătirea unei sarcini de calcul (blocul 3). Indică pentru ce secțiune și cale, precum și marca de locomotivă și tipul de vagoane, trebuie efectuat calculul;

Calculul vitezelor admisibile în conformitate cu procedura și formulele specificate în Ordinul nr. 41 (blocul 4). Informațiile inițiale sunt date privind traseul tronsonului (planul, suprastructura pistei etc.) și standardele selectate pe baza sarcinii de calcul;

Formarea listelor de viteze admise (blocul 5). Pe baza rezultatelor calculului, sunt create mai multe tipuri de documente de ieșire, care, pe de o parte, permit identificarea cauzei restricțiilor de viteză, pe de altă parte, acționează ca bază pentru întocmirea documentelor reglementate;

Formarea și pregătirea proiectului de Ordin „N” și a declarațiilor tip (blocurile 6 și 7).

După construirea diagramei de descompunere de nivel întâi, se construiesc diagrame separate pentru funcțiile indicate pe aceasta (diagrame de descompunere de nivel doi). Apoi procesul de descompunere (diagramare) continuă până când detaliile suplimentare ale funcțiilor devin lipsite de sens. Pentru fiecare funcție atomică care descrie o operație elementară (adică o funcție care nu are o diagramă de descompunere), este compilată o specificație detaliată care îi definește caracteristicile și algoritmul de implementare. Diagramele algoritmice pot fi utilizate ca supliment la specificație. Astfel, procesul de modelare funcțională constă în construirea treptată a unei ierarhii de funcții.

6.7. coduri ICOM

Săgețile care intră și ies dintr-o cutie dintr-o diagramă de nivel superior sunt aceleași cu săgețile care intră și ies dintr-o diagramă de nivel inferior, deoarece caseta și diagrama reprezintă aceeași parte a sistemului (vezi Figura 1) . Și ). În consecință, limitele unei funcții de nivel superior sunt aceleași cu limitele unei diagrame de descompunere.

coduri ICOM (un acronim pentru Input, Control, Output and Mechanism) au scopul de a identifica săgețile de delimitare. Codul ICOM conține un prefix corespunzător tipului de săgeată (I, C, O sau M) și un număr de serie (vezi figura).