IDEF0: ce este și cum se folosește. Construirea diagramelor idef3 (și idef0) - în ce program ar trebui să o fac? Dezvoltarea unui program de calculator în idef0

Ghenadi Vernikov

În prezent, interesul pentru standardele de management general acceptate în Occident a crescut brusc în Rusia, cu toate acestea, în practica reală de management, există un moment foarte semnificativ. Mulți lideri pot fi încă derutați de întrebarea directă a structura organizationala companie sau despre schema proceselor de afaceri existente. Cei mai avansați și care citesc în mod regulat manageri de periodice economice, de regulă, încep să deseneze diagrame ierarhice care pot fi înțelese numai pentru ei, dar în acest proces, de obicei, se opresc rapid. Același lucru este valabil și pentru angajații și șefii diferitelor servicii și unități funcționale. În cele mai multe cazuri, singurul set de reguli declarate conform cărora o întreprindere trebuie să opereze este un set de reglementări separate ș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 lua în considerare costurile - profitul era gigantic. Drept urmare, în ultimii doi ani am văzut o imagine destul de ușor de înțeles: companii mari, care au crescut la începutul anilor 90, își pierd treptat pozițiile, până la o retragere completă de pe piață. 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 simulare diverse zone activități, este posibil să se analizeze eficient „gâturile de sticlă” în management și să se optimizeze schema generală de afaceri. Dar, după cum știți, în orice întreprindere, doar acele proiecte care aduc profit direct au cea mai mare prioritate, așa că de obicei este vorba de examinarea activităților și reorganizarea acesteia doar în timpul unei crize concrete în managementul companiei.

La sfârșitul anilor 1990, când piața a început să devină mai competitivă și profitabilitatea întreprinderilor a început să scadă brusc, managerii au simțit mari dificultăți în a încerca să optimizeze costurile astfel încât produsele să rămână atât profitabile, cât și competitive. Chiar în acel moment s-a manifestat clar nevoia 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 în cadrul unei singure afaceri.

Însuși conceptul de „modelare a proceselor de afaceri” a intrat în viața majorității analiștilor concomitent cu apariția pe piață a complexului. produse software destinate pentru automatizare integrată managementul întreprinderii. Astfel de sisteme implică întotdeauna o adâncime sondaj pre-proiect activitatile companiei. Rezultatul acestui sondaj este o opinie de specialitate, în care se fac recomandări în paragrafe separate pentru eliminarea „gâturilor de sticlă” în managementul activităților. Pe baza acestei concluzii, imediat înainte de implementarea sistemului de automatizare, se realizează așa-numita reorganizare a proceselor de afaceri, uneori destul de gravă și dureroasă pentru companie. Aceasta este, desigur, o echipă care s-a dezvoltat de-a lungul anilor este întotdeauna greu de făcut să „gândească într-un mod nou”. Astfel de anchete cuprinzătoare ale întreprinderilor sunt întotdeauna complexe și diferă semnificativ de la caz la caz. Există metodologii și standarde bine stabilite pentru rezolvarea unor astfel de probleme de modelare a sistemelor complexe. Aceste standarde includ familia de metodologii IDEF. Cu ajutorul lor, puteți afișa și analiza eficient modelele de activitate ale unei game largi de sisteme complexe în diferite secțiuni. În același timp, lărgimea și profunzimea examinării proceselor din sistem este determinată de dezvoltatorul însuși, ceea ce permite să nu supraîncărcați modelul creat cu date inutile. În prezent, următoarele standarde pot fi atribuite familiei IDEF:

IDEF0 este o metodologie de modelare funcțională. Cu ajutorul unui limbaj grafic vizual IDEF0, sistemul studiat le apare dezvoltatorilor și analiștilor ca un set de funcții interdependente (blocuri funcționale – în termeni de IDEF0). De obicei, modelarea IDEF0 este primul pas în învățarea oricărui sistem;

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

IDEF1X (IDEF1 Extended) - o metodologie pentru construirea structurilor relaționale. IDEF1X aparține tipului de metodologie Entity-Relationship (ER) și este utilizat în mod obișnuit pentru a modela baze de date relaționale relevante pentru sistemul în cauză;

IDEF2 este o metodologie pentru modelarea dinamică a evoluției sistemelor. Datorită dificultăţilor foarte grave în analiză sisteme dinamice acest standard a fost practic abandonat, iar dezvoltarea lui a fost suspendată chiar în stadiul inițial. Cu toate acestea, în prezent există algoritmi și a acestora implementari pe calculator, permițându-vă să transformați un 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 cercetare procese tehnologice la intreprinderi. 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 un proces separat folosind instrumentele 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 studiul ontologic al sistemelor complexe. Folosind metodologia IDEF5, ontologia sistemului poate fi descrisă folosind un anumit vocabular 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 optimizați-l.
În cadrul acestui articol, vom lua în considerare cea mai frecventă metodologie de modelare funcțională IDEF0.

Istoria 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, în Rusia a fost publicată o mică ediție a cărții cu același nume, 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 Departamentul Forțelor Aeriene din SUA. Familia de standarde IDEF în sine și-a moștenit denumirea de la numele acestui program (IDEF=ICAM DEFinition). În procesul de implementare practică, participanții la programul ICAM s-au confruntat cu necesitatea dezvoltării de noi metode de analiză a proceselor de interacțiune în sisteme industriale. În același timp, pe lângă un set îmbunătățit de funcții de descriere a proceselor de afaceri, una dintre cerințele noului standard a fost disponibilitatea unei metodologii eficiente de interacțiune în cadrul „analistului-specialist”. Cu alte cuvinte, metoda noua trebuia 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 restrictive, iar ultima sa revizuire a fost lansată în decembrie 1993 de către Institutul Național de Standarde și Tehnologie din SUA (NIST).

Elemente și concepte de bază ale IDEF0

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

Primul dintre acestea este conceptul de cutie de activități. Blocul funcțional este reprezentat grafic ca un dreptunghi (vezi Fig. 1) și reprezintă unele functie specificaîn cadrul sistemului considerat. Conform cerințelor standardului, denumirea fiecărui bloc funcțional trebuie formulată în mod verbal (de exemplu, „a produce servicii” și nu „a produce servicii”).

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

Partea de sus este „Control”;

Partea stângă este „Intrare”;

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

Partea de jos are valoarea „Mecanism” (Mecanism).

Fiecare unitate funcțională din cadrul sistemului unic în cauză trebuie să aibă propriul său număr unic de identificare.

Figura 1. Bloc funcţional.

A doua „balenă” a metodologiei IDEF0 este conceptul de arc de interfață (Arrow). De asemenea, 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 afișată de acest bloc funcțional.

Afișarea grafică a arcului de interfață este o săgeată unidirecțională. Fiecare arc de interfață trebuie să aibă propriul nume unic (Arrow Label). Conform standardului, numele trebuie să fie o cifră de afaceri a unui substantiv.

Cu ajutorul arcurilor 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, vagoane, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).

În funcție de ce parte se apropie arcul de interfață dat, acesta se numește „incoming”, „outgoing” sau „controlling”. În plus, „sursa” (începutul) și „receptorul” (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 „receptorul” poate fi orice din restul de trei.

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 IDEF0 - diagrame, este important să separați corect arcurile interfeței de intrare de cele de control, ceea ce adesea nu este ușor. De exemplu, Figura 2 prezintă blocul funcțional „Procesează piesa de prelucrat”.

Într-un proces real, lucrătorului care efectuează prelucrarea i se oferă o piesă de prelucrat și instrucțiuni tehnologice pentru prelucrare (sau reglementări 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 așa. 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.

Un alt lucru este atunci când instrucțiunile tehnologice sunt procesate de tehnologul șef și le sunt aduse modificări (Fig. 3). În acest caz, ele sunt deja afișate de arcul de interfață de intrare, 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 subliniază natura aparent similară a arcurilor de interfață de intrare și de control, dar există întotdeauna anumite distincții pentru sistemele din aceeași clasă. De exemplu, în cazul luării în considerare a întreprinderilor și organizațiilor, există cinci tipuri principale de obiecte: fluxuri de materiale (piese, mărfuri, materii prime etc.), fluxuri financiare (numerar și non-numerar, investiții etc.), document fluxuri (documente comerciale, financiare și organizaționale), fluxuri de informații (informații, date de intenție, comenzi verbale etc.) și resurse (angajați, mașini, mașini etc.). În acest caz, în diverse cazuri, arcurile de interfață de intrare și de ieșire pot afișa toate tipurile de obiecte care le gestionează doar pe cele legate de fluxul de documente și informații, și doar resursele pot fi afișate ca arcuri-mecanisme.

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 se aplică atunci când un proces complex este defalcat în funcțiile sale constitutive. În acest caz, nivelul de detaliu al procesului este determinat direct de dezvoltatorul modelului.

Descompunerea vă permite să reprezentaț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 ușor de digerat.

Modelul IDEF0 începe întotdeauna cu o vedere a sistemului ca întreg - un singur bloc funcțional cu arcuri de interfață care se extind dincolo de zona considerată. O astfel de diagramă cu un bloc funcțional se numește diagramă de context și este notă cu identificatorul "A-0".

În textul explicativ pentru diagrama de context, scopul (Scopul) construcției diagramei în formă scurta descriereși punct de vedere fix (Viewpoint).

Definirea și formalizarea obiectivului de dezvoltare IDEF0 - modele este extrem de punct important. De fapt, scopul determină zonele relevante din sistemul studiat, care trebuie concentrate mai întâi. De exemplu, dacă modelăm activitățile unei întreprinderi pentru a construi în viitor pe baza acestui model Sistem informatic, atunci acest model va diferi semnificativ de cel pe care l-am dezvolta pentru aceeași întreprindere, dar cu scopul de a optimiza lanțurile 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 să detaliați și să studiați elementele individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului. De exemplu, modele funcționale ale aceleiași întreprinderi din punctul de vedere al tehnologului șef și director financiar vor diferi semnificativ în direcția detalierii lor. Acest lucru se datorează faptului că, în final, directorul financiar nu este interesat de aspectele procesării materiilor prime pe mașini de producție, iar tehnologul șef nu este interesat de schemele trasate ale fluxurilor financiare. Alegerea potrivita punct de vedere reduce semnificativ timpul petrecut pentru construirea modelului final.

În procesul de descompunere, blocul funcțional, care în diagrama de context afișează sistemul ca întreg, este detaliat într-o altă diagramă. Diagrama rezultată a celui de-al doilea nivel conține blocuri funcționale care afișează principalele subfuncții ale blocului funcțional al diagramei de context și se numește diagramă copil (Diagrama copil) în raport cu aceasta (fiecare dintre blocurile funcționale aparținând diagramei copil este respectiv numit bloc copil - Child Box). La rândul său, blocul funcțional - strămoșul se numește blocul părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține - diagrama părinte (Parent Diagram). Fiecare dintre subfuncțiile diagramei copil poate fi detaliată în continuare printr-o descompunere similară a blocului său funcțional corespunzător. Este important de menționat că, în fiecare caz de descompunere a unui bloc funcțional, toate arcurile de interfață incluse în acest bloc sau care ies din acesta 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.

Adesea există cazuri în care nu are sens să se ia în considerare în continuare arcurile individuale de interfață în diagramele copil sub un anumit nivel în ierarhie sau invers - arcuri individuale nu au sens practic peste un anumit nivel. De exemplu, un arc de interfață care ilustrează un „detaliu” la intrarea în blocul funcțional „Procesează pornit”. strung" nu are sens să reflectăm asupra diagramelor de niveluri superioare - acest lucru va supraîncărca diagramele și le va face dificil de citit. Pe de altă parte, poate fi necesar să scăpați de arcuri de interfață „conceptuale” individuale și să nu le detaliați. mai adânc decât un anumit nivel.Pentru a rezolva astfel de probleme în Standardul IDEF0 prevede conceptul de tunel.Notația „tunnel” (Arrow Tunnel) sub forma a două paranteze în jurul începutului arcului de interfață indică faptul că acest arc nu a fost moștenit din blocul părinte funcțional și a apărut (din „tunel”) doar pe această diagramă.întoarce, aceeași denumire în jurul capătului (săgeata) arcului de interfață în imediata vecinătate a blocului receptor înseamnă faptul că acest arc nu va să fie afișate și luate în considerare în diagrama copil a acestui bloc.arcurile de interfață nu sunt luate în considerare la unele niveluri intermediare ale ierarhiei - în acest caz, mai întâi „se scufundă în tunel”, apoi, dacă este necesar, „întoarce 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 adecvate, 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 acestui element. De exemplu, pentru interfața de control arc „ordin de plată”, glosarul poate conține o listă de câmpuri corespunzătoare arcului documentului, 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 transportă informații complexe și concentrate, iar pentru a limita aglomerația lor și a le face lizibile, restricțiile de complexitate corespunzătoare sunt adoptate în standardul corespunzător:

Limitarea numărului de blocuri funcționale din diagramă la trei până la șase. Limita superioară (șase) obligă proiectantul să folosească ierarhii atunci când descrie subiecte 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ță care se apropie de un bloc funcțional (lăsând 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 în grup privind dezvoltarea unui model IDEF0

Standardul IDEF0 conține un set de proceduri care permit elaborarea și aprobarea unui model de către un grup mare de persoane aparținând diferitelor domenii de activitate ale sistemului care se modelează. De obicei, procesul de dezvoltare este iterativ și constă din următorii pași condiționati:

Realizarea unui model de către un grup de specialişti în legătură cu diverse zone activitati intreprinderi. Acest grup se numește Autori în termenii IDEF0. Construirea modelului inițial este un proces dinamic în timpul căruia autorii întreabă persoane competente despre structură diverse procese. Pe baza prevederilor existente, a documentelor și a rezultatelor sondajului, se creează o schiță (Model Draft) a modelului.

Distribuirea proiectului spre examinare, aprobări și comentarii. Î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 același timp, fiecare dintre diagramele proiectului de model este criticată și comentată în scris, apoi transferată autorului. Autorul, la rândul său, este de acord cu critica în scris sau o respinge cu o declarație a logicii deciziei și returnează din nou proiectul corectat pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.

Aprobare model. Modelul aprobat este aprobat de șeful grupului de lucru în cazul în care autorii modelului și cititorii nu au dezacorduri cu privire la adecvarea acestuia. Modelul final este o vedere consistentă a întreprinderii (sistemului) dintr-un punct de vedere dat și pentru un scop dat.
Vizibilitatea limbajului grafic IDEF0 face ca modelul să fie destul de lizibil pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru demonstraț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 instrumente IDEF0

În ultimii ani, interesul față de Rusia față de metodologiile familiei 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 astfel de standarde precum IDEF3-5 teoretic, iar în IDEF0 este destul de practic justificat. De fapt, primele Case-tools 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 cale eficientă optimizare sistem existent administrare afaceri. Acest lucru se datorează cel mai probabil unei lipse pronunțate de informații despre aplicație practică a acestor metodologii și cu o părtinire software indispensabilă a marii majorități a publicațiilor.

Nu este un secret pentru nimeni faptul că aproape toate proiectele de anchetă și analiză financiară și activitate economicăîntreprinderile din Rusia sunt acum legate într-un fel sau altul de construcție sisteme automatizate management. Datorită acestui fapt, standardele IDEF în înțelegerea majorității au devenit condiționat inseparabile de implementare tehnologia Informatiei, deși cu ajutorul lor este uneori posibil să se rezolve eficient chiar și mici probleme locale, literalmente cu un 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 vizual și eficient întregul mecanism al activităților unei întreprinderi în contextul potrivit. Cel mai important, însă, este capacitatea de colaborare pe care o oferă IDEF0. In al meu activitati practice au fost destul de multe cazuri când modelul a fost construit cu ajutorul direct al angajaților din diverse departamente. În același timp, consultantul pentru suficient un timp scurt le-a explicat principiile de bază ale IDEF0 și i-a învățat cum să lucreze cu aplicația corespunzătoare software. 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 intră în unitate „la intrare”?

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

Cine este responsabil pentru fiecare funcție?

Ce ghidează executantul în îndeplinirea fiecărei funcții?

Care este rezultatul muncii (ieșirii) unității?

După coordonarea schițelor de diagrame în cadrul fiecărei unități specifice, acestea sunt asamblate de către un consultant într-un proiect de model de întreprindere, în care toate elementele de intrare și ieșire sunt legate. În această etapă, toate inconsecvențele diagramelor individuale și locurile lor controversate sunt remediate. În plus, acest model trece din nou prin departamentele funcționale pentru coordonarea ulterioară și efectuarea ajustărilor necesare. Ca urmare, într-un timp destul de scurt și cu implicarea unui minim resurse umane din partea unei companii de consultanță (și aceste resurse, după cum știți, sunt foarte scumpe), se obține un model IDEF0 al întreprinderii conform principiului „Așa cum este” și, important, reprezintă întreprinderea din poziția de angajații care lucrează în el ș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 „bloc-urile” în managementul companiei și vor optimiza procesele principale, transformând modelul „Așa cum este” în modelul „Așa cum ar trebui să fie” corespunzător. „reprezentare. Pe baza acestor modificări se face 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 impunerea unor angajați responsabilități suplimentare privind dezvoltarea și aplicarea practică a noilor 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ță de la o companie terță (care, în orice caz, va întrerupe activitatea de aceiași angajați cu chestionare și întrebări). Cât despre angajații întreprinderii înșiși, într-un fel sau altul, nu am întâlnit nicio opoziție exprimată din partea acestora în practica mea.

Concluzia din toate acestea se poate trage după cum urmează: nu este absolut necesar să se vină cu soluții pentru problemele standard de fiecare dată. Ori de câte ori vă confruntați cu necesitatea de a analiza un anumit sistem funcțional (din sistemul de proiectare nava spatiala, înainte de procesul de pregătire a unei cine complexe) - folosiți metode care au fost încercate și testate de-a lungul anilor. Una dintre aceste metode este IDEF0, care permite utilizarea setului său de instrumente simplu și ușor de înțeles pentru a rezolva probleme complexe de viață.

Ministerul Educației și Științei al Federației Ruse

Agenția Federală pentru Educație

Stat instituție educațională studii profesionale superioare

Lucrări de curs

„Modelare de sistem”

„Dezvoltarea unui model de întreprindere cu efect de seră folosind metodologiile de proiectare IDEF0, DFD și IDEF3”

1. Scopul lucrării

2. Introducere teoretică

3. Descriere domeniul subiectului

4. Descrierea BPwin

4.1 Principiul construirii unui model IDEF0

4.2 Principiul construirii unui model DFD

4.3 Principiul de construire a modelului IDEF3

5. Simulare

5.1 Model de seră

5.2 Model matematic

6. Benchmarking

6.1 Metodologii

6.2 Compararea instrumentelor

Literatură

1. Scopul lucrării

Obiectivele acestui curs au fost:

aplicarea metodelor de cercetare pre-proiect a întreprinderii;

analiza materialelor obtinute pentru modelarea ulterioara;

dezvoltarea unui model de proces în standardul IDEF0;

descrierea fluxului de lucru și a procesării informațiilor în standardul DFD;

descrieri ale proceselor din standardul IDEF3;

dezvoltarea unui model mixt de descriere a proceselor bazat pe standardele IDEFO, DFD și IDEF3.

crearea de scenarii pentru funcționarea întreprinderii;

construirea schemei structurale a întreprinderii;

crearea unui model matematic al acestei întreprinderi.

analiza comparativa

2. Introducere teoretică

La dezvoltarea sistemelor de control automatizate în etapele de codificare și testare, sunt relevate un număr mare de erori, a căror corectare presupune schimbare drasticăîn întregul sistem în curs de dezvoltare. Astfel de erori sunt luate în considerare în modelare și analize profunde și detaliate. proiecte create. Modelarea vă permite să „vedeți” proiectul în procesul de dezvoltare și să creați condiții preliminare pentru analizarea comportamentului sistemului în funcție de condițiile inițiale.

Pentru o coordonare adecvată a proceselor care au loc în sistemul de control simulat, este necesară crearea unei structuri, de ex. eficientizați procesele. Modelarea funcționării unui sistem informațional este deosebit de importantă în fazele incipiente ale creării acestuia. Întrucât corectarea erorilor făcute în această etapă este cea mai costisitoare, beneficiile la etapa analizei problemei și dezvoltarea unui model logic pentru soluționarea acesteia sunt semnificative.

În acest sens, este necesar să se studieze și să se dezvolte domeniul de studiu, și anume activitatea industriei de sere. Pentru a face acest lucru, trebuie să înțelegeți terminologia acestei zone, să colectați reglementările necesare și documente legale, studiază mostrele de documente ale acestei întreprinderi și urmărește mișcarea acestora atât în ​​interiorul întreprinderii, cât și în afara acesteia.

Următoarea etapă de dezvoltare este etapa de proiectare. Înainte de a începe proiectarea și implementarea, trebuie să aveți o înțelegere precisă și detaliată a cerințelor pentru nivel inalt. În plus, este foarte util să existe o structură de cerințe care să poată fi folosită ca intrare pentru a forma sistemul. Toate acestea se realizează prin analiză și modelare.

În cursul lucrărilor la etapele de modelare și proiectare, este necesar să obțineți un proiect de sistem care să conțină suficiente informații pentru implementarea acestuia. De asemenea, este necesar să se analizeze activitatea industriei cu efect de seră, în urma căreia este posibil să se judece gradul de volum de muncă al fiecărui departament, ce trebuie automatizat în primul rând și prin ce mijloace.

Principalele obiective ale modelării în dezvoltarea proiectelor sunt:

reprezentarea activităților întreprinderii și a tehnologiilor adoptate în aceasta sub forma unei ierarhii de diagrame care asigură vizibilitatea și completitudinea afișajului acestora;

formarea pe baza analizei propunerilor de reorganizare a structurii organizatorice si manageriale;

eficientizarea fluxurilor de informații (inclusiv fluxul de lucru) în cadrul întreprinderii;

analiza cerințelor și proiectarea specificațiilor sistemelor informaționale corporative.

3. Descrierea domeniului subiectului

Pentru luare în considerare în acest sens termen de hârtie a fost luată ca bază pentru lucrul serelor. Această întreprindere este specializată în cultivarea culturilor agricole. Vanzarea produselor se realizeaza la cererea clientului.

Organizarea muncii se realizează după următoarea schemă:

Această diagramă prezintă departamentele întreprinderii, funcțiile și interrelațiile acestora. Unele dintre departamente pot fi automatizate.

În fruntea întregii întreprinderi se află conducerea, reprezentată de șef și adjunctul acestuia. Funcția lor principală este de a controla activitățile întreprinderii.

Serviciul de protecție a muncii, a cărui funcție principală este pregătirea personalului;

Departamentul de contabilitate este angajat în managementul documentelor;

Serviciul de control al producției efectuează controlul deplin în toate etapele producției;

Sector întreținere angajat în lucrări de reparații.

Departamentele, serviciile și locurile de muncă ale acestei întreprinderi sunt prezentate în tabelul nr. 1:

tabelul numarul 1

Sarcinile și funcțiile industriei noastre de sere sunt prezentate în tabelul nr. 2:

Tabelul numărul 2

Documentația este prezentată în tabelele nr. 3:

tabelul numarul 3

Directorul organizațiilor este prezentat în tabelul nr. 4:

tabelul numarul 4

Mai jos este o diagramă care descrie scenariul întreprinderii cu concluziile corespunzătoare pentru fiecare dintre etape: clientul primește o cerere pentru furnizarea anumitor produse cu efect de seră către managerul de vânzări. Managerul de vânzări procesează această cerere și ia o decizie. În paralel, contabilul calculează costul prestării serviciilor. Odată finalizate toate aceste etape, începe procesul de încheiere a unui contract. Managerul de vânzări discută termenii contractului cu clientul și îl încheie. După aceea, clientul efectuează o plată. Controlul asupra plății este responsabilitatea departamentului de contabilitate. Contabilul primește un extras de la bancă și formează un ordin de începere a executării comenzii, care este transferat tehnologului. Tehnologul, la rândul său, întocmește un plan - un program de lucru și ține evidența fondurilor necesare. După întocmirea unui plan - un program de lucru, grădinarului i se dă ordin să efectueze lucrări de teren. Grădinarul efectuează lucrări de pământ și recolte. Recolta recoltată este trimisă clientului. Pe parcurs ciclu de producțieșeful întreprinderii primește rapoarte privind activitățile directorului de vânzări, contabilului și tehnologului. Șeful controlează întregul proces al întreprinderii și, dacă este necesar, face comentarii asupra muncii personalului său pentru a îmbunătăți procesul de producție și munca întregii întreprinderi în ansamblu.

Schema scenariului întreprinderii

4. Descrierea BPwin

BPwin este un mic instrument integrat de modelare care acceptă mai multe tipuri de modele și metode.

Pentru a analiza și reorganiza procesele de afaceri, Logic Works oferă un instrument CASE de nivel superior - BPwin, care acceptă metodologiile IDEF0 ( model functional), IDEF3 (WorkFlow Diagram) și DFD (DataFlow Diagram). Principala dintre cele trei metodologii este IDEF0. BPwin are o interfață de utilizator destul de simplă și intuitivă, permițând analistului să creeze modele complexe cu efort minim.

BPwin automatizează sarcinile asociate modelelor de dezvoltare a clădirilor, oferind rigoarea semantică necesară pentru a asigura rezultate corecte și consecvente. Acest lucru se realizează prin utilizarea următoarelor metodologii în BPwin: IDEF0, DFD și IDEF3.

Dar înainte de a ne angaja în această sarcină mai complexă, este cu adevărat necesar să măcar „recalculam” toate elementele afacerii, adică să creăm o structură organizatorică a companiei. Următorul pas este să încercăm să descriem grafic relațiile dintre diferitele elemente ale structurii definite anterior.

Este posibil să construiți modele mixte în BPwin, adică un model poate conține atât diagrame IDEFO, IDEF3 și DFD în același timp. Un model în BPwin este privit ca un set de activități, fiecare dintre ele funcționând pe un anumit set de date. Lucrarea este afișată ca dreptunghiuri, datele ca săgeți.

Toate lucrările modelului sunt numerotate. Numărul este format dintr-un prefix și un număr. Poate fi folosit un prefix de orice lungime, dar de obicei se folosește prefixul A. Operația contextului (rădăcină) a arborelui este numerotată A0. Lucrarea de descompunere A0 se numerotează Al, A2, A3 etc. Lucrările de descompunere a nivelului inferior au numărul lucrării părinte și următorul număr de serie, de exemplu, lucrările de descompunere A3 vor avea numerele A3.1 A3.2, AZ.3, A3.4 etc.

Ca urmare a adăugării de diagrame, diagrame IDEFO, DFD și IDEF3, poate fi creat un model mixt care descrie cel mai bine toate aspectele întreprinderii. Ierarhia joburilor de model mixt poate fi văzută în fereastra Model Explorer. Sunt prezentate lucrări în notație IDEFO în verde, DFD - albastru.

BPwin, precum și sistemele integrate locale, practic nu vă permit să efectuați o analiză cuprinzătoare a sistemelor, care este mai mult sau mai puțin necesară pentru a crea PMIS mici, medii și mari. Cu ajutorul lor, puteți dezvolta IS local sau subsisteme mici concepute pentru a automatiza lanțurile de afaceri individuale, adică atunci când nu este nevoie de analiză complexăîntreprinderilor. O zonă tipică de utilizare a instrumentelor integrate mici este rezolvarea problemelor așa-numitei automatizări „pe bucăți” a unei întreprinderi.

4.1 Principiul construirii unui model IDEFO

Baza metodologiei IDEFO este un limbaj grafic pentru descrierea proceselor de afaceri. Un model în notație IDEFO 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 IDEFO presupune prezența unui obiectiv clar definit al unui singur subiect de modelare și al unui punct de vedere.

Un model poate conține patru tipuri de diagrame:

diagramă de context (fiecare model poate avea o singură diagramă de context);

diagrame de descompunere;

diagramele arborelui nodurilor;

diagrame numai pentru expunere (FEO).

Diagrama de context este partea de sus a structurii arborescente a diagramelor și este cea mai generală descriere a sistemului și a interacțiunii acestuia cu mediul extern.

Acest proces se numește descompunere funcțională, iar diagramele care descriu fiecare fragment și interacțiunea fragmentelor se numesc diagrame de descompunere.

Notația și metodologia IDEF0 se bazează pe conceptul de „bloc”, adică un dreptunghi care exprimă o anumită funcție de business. După cum știți, un dreptunghi are patru laturi. În IDEF0, rolurile (sensurile funcționale) ale tuturor părților sunt diferite:

partea de sus are sensul de „control”;

stânga - „intrare”;

dreapta - „ieșire”;

inferior - „mecanism”.

Al doilea element al metodologiei și notației este „fluxul” (în standard numit „arc de interfață”) – un element care descrie date, control informal sau orice altceva care „influențează” funcția reprezentată de bloc. În funcție de ce parte a blocului este direcționat fluxul, acesta, respectiv, se numește „intrare”, „ieșire”, „control”.

Elementul iconic care reprezintă „fluxul” este o săgeată.

Management - asta controlează activitățile biroului, în acest model fiind dezvoltat - acestea sunt legile privind PU individual.

Săgețile „intrare” introduc funcțiile datelor de intrare; în diagrama de context, acestea sunt datele personale ale angajatului.

Săgeți „ieșire” - date de ieșire. În diagrama de context, acestea sunt diverse informații care sunt transmise Fondului de pensii al Federației Ruse.

Săgeata „mecanism” reprezintă datele care influențează procesele. În diagramă, acestea sunt personal și PC.

După descompunerea diagramei de context, fiecare fragment mare al sistemului este descompus în altele mai mici, fiecare fragment având un nume și așa mai departe, până când se atinge nivelul dorit de descriere.

După fiecare sesiune de descompunere, au loc sesiuni de examinare - experții în materie indică corespondența proceselor reale de afaceri cu diagramele create.

Neconcordanțele găsite sunt corectate și numai după ce ați trecut examenul fără comentarii, puteți trece la următoarea sesiune de descompunere. Așa se obține conformitatea.

Toate intersecțiile de pe diagramă sunt numerotate, fiecare număr are un prefix J. Puteți edita proprietățile intersecției folosind dialogul Editor de definiții.

4.2 Principiul construirii unui model DFD

Diagramele de flux de date (DFD) sunt mijloacele principale de modelare a cerințelor funcționale ale unui sistem proiectat. Cu ajutorul lor, aceste cerințe sunt defalcate în componente funcționale (procese) și prezentate ca o rețea conectată prin fluxuri de date. obiectivul principal astfel de instrumente trebuie să demonstreze modul în care fiecare proces își transformă intrările în ieșiri și să identifice relațiile dintre aceste procese.

Două notații diferite sunt folosite în mod tradițional pentru a descrie DFD: Yodan (Yourdon) și Gane-Sarson (Gane-Sarson). În plus, la construirea exemplelor, se va folosi notația Yodan, toate excepțiile vor fi specificate preliminar.

Această metodologie (metodologia Gane/Sarson) se bazează pe construirea unui model al SI analizat – proiectat sau existent efectiv. În conformitate cu metodologia, modelul de sistem este definit ca o ierarhie de diagrame de flux de date (DFD sau DFD) care descriu procesul asincron de transformare a informațiilor de la intrarea acesteia în sistem până la emiterea acesteia către utilizator. Diagramele nivelurilor superioare ale ierarhiei (diagramele de context) definesc principalele procese sau subsisteme ale SI cu intrări și ieșiri externe. Acestea sunt detaliate folosind diagrame de nivel inferior. Această descompunere continuă, creând o ierarhie pe mai multe niveluri de diagrame, până când se ajunge la un nivel de descompunere la care procesele devin elementare și este imposibil să le detaliem mai departe.

Sursele de informații (entități externe) generează fluxuri de informații (fluxuri de date) care transferă informații către subsisteme sau procese. Aceștia, la rândul lor, transformă informațiile și generează noi fluxuri care transferă informații către alte procese sau subsisteme, stocarea datelor sau entități externe – consumatori de informații. Astfel, principalele componente ale diagramelor de flux de date sunt:

entitati externe;

sisteme/subsisteme;

procese;

dispozitive de stocare a datelor;

fluxuri de date.

4.3 Principiul de construire a modelului IDEF3

IDEF3 poate fi folosit și ca metodă de creare a procesului. IDEF3 completează IDEFO și conține tot ce aveți nevoie pentru a construi modele care pot fi folosite ulterior pentru analiza de simulare.

Fiecare job din IDEF3 descrie un scenariu de proces de afaceri și poate face parte dintr-un alt job. Deoarece scenariul descrie scopul și domeniul de aplicare al modelului, este important ca lucrările să fie menționate printr-un substantiv verbal care denotă procesul de acțiune sau o frază care conține un astfel de substantiv.

Punctul de vedere al modelului trebuie documentat. De obicei, acesta este punctul de vedere al persoanei responsabile de lucrare în ansamblu. De asemenea, este necesar să se documenteze scopul modelului - întrebările la care modelul este destinat să răspundă.

Răscruce de drumuri. Finalizarea unei lucrări poate semnala începutul mai multor lucrări sau o lucrare poate aștepta finalizarea mai multor lucrări. Încrucișările sunt folosite pentru a afișa logica modului în care săgețile interacționează la îmbinare și ramificare sau pentru a afișa un set de evenimente care pot sau trebuie să fie finalizate înainte de a începe următoarea lucrare. Tipurile de intersecții sunt prezentate în tabel:

Tipuri de intersectii

Desemnare	Nume	Semnificație în cazul îmbinării săgeților (Fan-in Jonction)	Adică în caz joncțiuni cu săgeți (Ieșire în evantai)
||&	SI asincron	Toate procesele precedente trebuie finalizate	Toate procesele următoare trebuie să ruleze
||&||	SI sincron	Toate procesele precedente au fost finalizate în același timp	Toate procesele următoare rulează în același timp
||O	SAU asincron	Unul sau mai multe procese antecedente trebuie să fie încheiate	Trebuie să ruleze unul sau mai multe dintre următoarele procese
||O||	SAU sincron	Unul sau mai multe procese predecesoare finalizate în același timp	Unul sau mai multe dintre următoarele procese rulează în același timp
||X		S-a încheiat un singur proces antecedent	Este început doar un proces următor

Toate intersecțiile de pe diagramă sunt numerotate, fiecare număr are un prefix J. Puteți edita proprietățile intersecției folosind dialogul Editor de definiții. Spre deosebire de IDEFO și DFD, în IDEF3 săgețile pot fuziona și ramificați numai prin intersecții.

Link obiect. Un obiect de legătură în IDEF3 exprimă o idee, concept sau date care nu pot fi asociate cu o săgeată, intersecție sau job. Pentru a adăuga un obiect link utilizați |R| – (adăugați un obiect de referință la diagramă - Referent) în paleta de instrumente. Obiectul de legătură este desenat ca un dreptunghi similar dreptunghiului de lucru. Numele obiectului de referință este setat în dialogul Referent (articol de meniu pop-up editor de nume), ca nume, puteți folosi numele unei săgeți din alte diagrame sau numele unei entități din modelul de date. Obiectele de referință trebuie să fie legate de unități de lucru sau de intersecții cu linii punctate. Specificația oficială IDEF3 distinge trei stiluri de obiecte de referință: necondiționat, sincron și asincron. BPwin acceptă numai obiecte link necondiționat. Obiectele de referință sincrone și asincrone utilizate în diagramele de tranziție a stării obiectelor nu sunt acceptate.

5. Simulare

5.1 Model de seră

Model Navigator - Model Explorer

Diagrama contextului:

Diagrama de descompunere A0:

Diagrama de descompunere A1:

Diagrama IDEF3 A11.1:

Diagrama fluxului de date A12:

Diagrama de descompunere A2:

Diagrama IDEF3 A21.1:

Diagrama de descompunere A3:

Diagrama de descompunere A4:

Diagrama de descompunere A5:

Diagrama de descompunere A6:

Diagrama fluxului de date A63:

5.2 Model matematic

Pentru mai mult descriere detaliata munca economiei cu efect de seră, este necesară elaborarea unui model matematic pentru produsul activității întreprinderii.

Acest model matematic va descrie calculul prețului pe unitate de marfă în diferite condiții.

e - costul unei unități de mărfuri, determinat de producător, include toate costurile asociate cu producția unei unități de mărfuri, partea principală a acestei cifre este prețul de achiziție al semințelor;

v - prețul de achiziție al semințelor, acesta este prețul la care întreprinderea a achiziționat semințe de la furnizor (secțiunea „achiziționarea semințelor”);

a - costul muncii salariuși alte cheltuieli în cadrul întreprinderii);

g - combustibili si lubrifianti (combustibil si lubrifianti);

n - impozitele (partea consumatorului) sunt stabilite de stat și au cotă fixă;

k - TVA, taxa pe valoarea adăugată, are și o cotă fixă;

r - prețul de vânzare cu amănuntul, aceasta este suma de bani pentru care producătorul vinde o unitate a produsului său pe piață, de regulă, prețul de vânzare cu amănuntul este determinat de prețul de cost cu un anumit procent de markup;

s - markup-ul companiei pe unitatea de marfă, de regulă, fiecare antreprenor își determină individual suma, în acest caz este de 40% din cost, adică (e * 40) / 100

o - pretul angro, aceasta este suma de bani oferita pe unitatea de marfa, la cumpararea de la 100 de unitati, in acest caz existand o reducere de 10% din pretul cu amanuntul;

os – reducere pentru achiziția în vrac (os

Model matematic pentru calcularea costului pe unitatea de marfă produsă:

Model matematic pentru calcularea prețului de vânzare cu amănuntul pe unitatea de produse fabricate:

Model matematic pentru calcularea prețului cu ridicata pe unitatea de produse fabricate:

o=v+a+g+n+k+s - os

o=r - (r*10)/100

Calculul costului produselor la întreprinderea „Economia cu efect de seră” este efectuat de departamentul de contabilitate, care controlează fluxul documentelor, ia în considerare veniturile și cheltuielile întreprinderii, ține registrele contabile și eliberează certificate. Pe baza acestor formule obținute în modelul matematic al întreprinderii, contabilul poate calcula prețul mărfurilor, atât cu amănuntul, cât și cu ridicata.

6. Benchmarking

Pentru a modela întreprinderea noastră, am folosit 5 metodologii: Dragon, UML, IDEF0, IDEF3, DFD. În opinia noastră, metodologia UML este cea mai bună modalitate de a prezenta modelul întreprinderii noastre, deoarece reflectă mai clar și mai precis principalele aspecte ale industriei de sere.

Diagramele UML sunt relativ ușor de citit.

De exemplu, diagrama „Use Case”, care a fost folosită ca rezultat al proiectării sistemului de implementare Greenhouse, permite clientului, utilizatorului final și dezvoltatorului să discute împreună funcționalitatea și comportamentul sistemului. „Diagrama de clasă” vă permite să descrieți structura sistemului, arată clasele sistemului, atributele acestora, metodele și dependențele dintre clase, care pot dezvălui în detaliu scenariul și organizarea întreprinderii.

Metodologia Dragon are, de asemenea, o structură foarte clară, dar nu are posibilități atât de mari de modelare a diverselor sisteme.

Visio este cel mai simplu și mai accesibil instrument de modelare a proceselor. Acest produs are standard, familiar pentru toate panourile de control în stilul MS Office și este ușor de integrat cu orice aplicație a acestui pachet, ceea ce facilitează lucrul cu acesta pentru utilizatorii fără experiență. Cu toate acestea, analiza timpului sau a costurilor necesită elaborarea de rapoarte, ceea ce complică foarte mult utilizarea acestui produs. Rapoartele tipice nu sunt în mod clar suficiente pentru analiza proceselor de afaceri. În ciuda acestui fapt, Visio este un instrument comun pentru descrierea proceselor de afaceri atât în ​​Rusia, cât și în străinătate. Visio acceptă formatele IDEF și UML pentru descrierea proceselor de afaceri. De asemenea, este posibil să se dezvolte independent formate.

BPWIN - ocupă un loc intermediar, remarcandu-se prin simplitatea și marile capacități de analiză. Funcționalitatea BPWIN nu este doar de a desena diagrame, ci și de a verifica integritatea și consistența modelului. BPWIN oferă claritate logică în definirea și descrierea elementelor diagramei, precum și verificarea integrității relațiilor dintre diagrame. Instrumentul oferă corectarea celor mai frecvente erori în modelare. În plus, BPWIN acceptă proprietăți personalizate care sunt aplicate elementelor diagramei pentru a descrie proprietăți specifice specifice acelui element. Principala limitare a acestui sistem este standardul IDEF care stă la baza acestuia, în care există restricții severe la construirea modelelor. Acest lucru simplifică sarcina de a descrie proceduri simple, dar complică descrierea proceselor mari. Schemele 1DEF, atunci când descriu procese complexe, încep să prezinte nenumărate scheme interconectate care sunt foarte asemănătoare ca aspect, ceea ce face dificilă înțelegerea procesului ca întreg.

7. Concluzie:

În cursul acestui curs, toate obiectivele noastre au fost atinse.

În acest sens, am studiat tematica în curs de dezvoltare și anume activitatea industriei de sere. Pentru a face acest lucru, a fost necesar să înțelegem terminologia acestui domeniu, să colectăm documentele de reglementare și legale necesare, să studiem mostrele de documente ale întreprinderii noastre și să urmărim mișcarea acestora atât în ​​interiorul întreprinderii, cât și în afara acesteia.

În urma acestor activități s-au obținut informații, pe baza cărora s-a efectuat o analiză inițială și s-a întocmit o schiță a modelului proiectat.

Următoarea etapă de dezvoltare este etapa de proiectare. Înainte de a începe proiectarea și implementarea, trebuie să aveți o înțelegere precisă și detaliată a cerințelor la un nivel înalt. În plus, este foarte util să existe o structură de cerințe care să poată fi folosită ca intrare pentru a forma sistemul. Toate acestea se realizează prin analiză și modelare. Efectuând analize și modelări, am realizat o separare a sarcinilor, pe care în stadiul de pre-proiect le-am pregătit și simplificat pentru activitățile ulterioare de proiectare și implementare. Facem distincție între problemele care trebuie rezolvate și deciziile care trebuie luate pentru a le face față.

Ca urmare a lucrărilor din etapele de modelare și proiectare, am primit un proiect de sistem care conține suficiente informații pentru implementarea acestuia.

După analizarea activității industriei de sere, putem judeca gradul de încărcare a fiecărui departament, ce trebuie automatizat în primul rând și prin ce mijloace.

Pentru a facilita munca, este posibilă introducerea de noi tehnologii care vor facilita munca în ferma noastră.

Literatură:

Rogozov Yu.I., Stukotiy L.N., Sviridov A.S. „Modelarea sistemelor” TRTU, 2004.

S.V. Maklakov „CASE-instrumente pentru dezvoltarea sistemelor informaționale. BPwin și Erwin "-M.: DialogMifi, 2001.

Maklakov S. „Combinând abordarea structurală și de obiect în noua generație de instrumente CASE Computer Associates” // Centrul de instruire și consultanță. 2002.

O imagine valorează cât o mie de cuvinte

înțelepciunea populară

Desigur, în teorie, managerul ar trebui să aibă un model funcțional al activității companiei și nu contează dacă vorbim despre organizarea depozitului sau a sistemului IT (de la lead la cerere). Dar, în realitate, aproape niciodată nu se dovedește a fi și, prin urmare, în procesul de studiu și căutare a unei soluții la sarcina stabilită de client, creez și un model funcțional al companiei sau un anumit proces (funcție) pe a mea.

Câteva cuvinte despre beneficiile graficii

După cum știți, modelele funcționale IDEF0 sunt întotdeauna diagrame grafice. Au propriile caracteristici și reguli de compilare. Vom vorbi despre asta puțin mai târziu. Și 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ă acest lucru nu este necesar și a fost posibil să explic în cuvinte cum funcționează cutare sau cutare funcție în companie. Despre asta vreau să vorbesc.

Și, pentru început, să facem o scurtă digresiune în istorie. Să ne întoarcem la îndepărtatul 1877, în timpul războiului ruso-turc. Atunci imprimanta Sytin a folosit pentru prima dată grafica în descrierea operațiunilor 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, operațiunile militare erau descrise în cuvinte. Pentru fiecare luptă - multe, multe cuvinte. Și a fost foarte greu de înțeles până la urmă ce se întâmplă.

Acesta este motivul pentru care ideea lui Sytin a fost cu adevărat revoluționară - a început să imprime copii litografice ale hărților cu desemnarea fortificațiilor și a locațiilor unităților militare. Aceste carduri au fost numite „Pentru cititorii de ziare. Beneficiu". Ideea s-a dovedit a fi atât de relevantă încât primul tiraj al „Help” s-a epuizat 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 deslușit doar cu ajutorul cuvintelor.

De asemenea, pot cita un exemplu similar de neputință a descrierilor verbale din propria mea practică. Unul dintre clienții mei mi-a cerut să îmi asum implementarea unui sistem ERM pentru compania sa. Când am întrebat dacă au un fel de sarcină tehnică, am primit răspunsul: „Da, au. Dar are 400 de pagini.” În același timp, clientul s-a plâns foarte mult că colegii mei, pe care i-a contactat mai devreme, fie au refuzat cu totul proiectul, fie au cerut prețuri vădit umflate. După ce am văzut că termenii de referință erau într-adevăr de 400 de pagini și constau doar dintr-o descriere textuală, 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 o variantă alternativă - să 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 termenilor de referință.

Cunosc și multe alte exemple când 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 este întotdeauna legată de modificarea 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ă exact ce facem – instalăm sau instalăm un sistem CRM de la zero, creăm un sistem ERP eficient, integrăm diverse sisteme pentru a crește automatizarea muncii în general. În orice caz, pentru început, este necesar să vă faceți o idee despre schema de lucru existentă și numai după aceea este posibil să propuneți unele modificări și să vă gândiți la opțiuni pentru rezolvarea sarcinii.

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 întreprinse pentru rezolva sarcina și, desigur, rezultatul așteptat.

Astfel de rapoarte de anchetă de muncă sunt voluminoase, ocupând 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.

De fapt, este important să nu oferiți volum, ci să transmiteți esența cât mai rapid și complet posibil. Volumele mari de text necesită timp, pe care oamenii de afaceri îl au adesea foarte puțin. Iar grafica îmi permite să reduc volumul propunerii mele și să arăt clar, într-o formă de înțeles, soluția. Drept urmare, propunerile mele au fost reduse semnificativ, grafica a apărut în ele și deciziile privind începutul cooperării au început să fie luate mai rapid.

Din acest motiv folosesc modele vizuale. După cum știți, o imagine valorează cât o mie de cuvinte. Și în cazul descrierii proceselor de afaceri și a opțiunilor de modernizare a activității unei afaceri, acest lucru este adevărat. Și notațiile IDEF0 sunt foarte potrivite aici.

Dar mai întâi, să înțelegem conceptele de bază despre ce sunt notațiile, de ce sunt necesare, ce este IDEF0, care sunt caracteristicile și avantajele acestei metode.

Ce este notația de descriere a procesului de afaceri

O notație este un format pentru descrierea unui proces de afaceri, care este un set de obiecte grafice utilizate în modelare, precum și reguli de modelare.

De fapt, notațiile sunt un limbaj grafic special care vă permite să descrieți activitatea unei companii, să demonstrați vizual interacțiunea dintre diferite departamente, de exemplu. descrie procesele de afaceri. Notațiile pot fi folosite pentru modelarea proceselor sau funcționale.

În general, notațiile pot fi numite un limbaj de programare în analiza de afaceri.

Ce este IDEF0?

IDEF0 este o metodologie de modelare funcțională și o notație grafică concepută pentru a formaliza și descrie procesele de afaceri. O caracteristică distinctivă a IDEF0 este accentul pus pe subordonarea obiectelor. IDEF0 ia în considerare relațiile logice dintre joburi, nu secvența lor temporală (fluxul de lucru). Wikipedia

Standardul IDEF0 a fost dezvoltat în 1981 de Departamentul Forțelor Aeriene din SUA pentru automatizarea industrială. În procesul de dezvoltare a software-ului, dezvoltatorii se confruntă cu nevoia de a dezvolta noi metode de analiză a proceselor de afaceri. Ca urmare, a apărut metodologia de modelare funcțională IDEF0, în care se folosesc notații speciale IDEF0 pentru analiză.

Modelul funcțional al companiei

Modelul funcțional IDEF0 este un set de blocuri, fiecare dintre acestea fiind o „cutie neagră” cu intrări și ieșiri, controale și mecanisme care sunt detaliate (descompuse) la nivelul necesar. Cea mai importantă funcție este situată în colțul din stânga sus. Și funcțiile sunt conectate între ele cu ajutorul săgeților și descrierilor blocurilor funcționale. Mai mult, fiecare tip de săgeată sau activitate are propriul său sens. Acest model vă permite să descrieți toate tipurile principale de procese, atât administrative, cât și organizatorice.

Săgețile pot fi:

• Inbox - introductiv, care stabilește o anumită sarcină.
• Outgoing - afișarea rezultatului activității.
• Managerii (de sus în jos) - mecanisme de control (poziții, instrucțiuni etc.).
• Mecanisme (de jos în sus) - ceea ce este folosit pentru a produce munca necesară.

Ar fi mai corect să apelați la intrare și la ieșire săgețile de intrare și de ieșire, deoarece în engleză se numesc Input și, respectiv, Output. Dar caracteristicile traducerii și denumirile obișnuite arată deja așa cum au. Și totuși, pentru o înțelegere corectă a termenilor, este important să ne amintim sensul lor în acest caz. Acest lucru este confirmat și de faptul că această notație a fost creată în primul rând pentru dezvoltarea de software și este mai corect să traducem termenii din acest punct de vedere.

Săgețile sunt semnate folosind substantive (experiență, plan, reguli), iar blocurile sunt semnate folosind verbe, de ex. ele descriu acțiunile care sunt efectuate (crearea unui produs, încheierea unui contract, efectuarea unei expedieri).

IDEF0 este un limbaj foarte simplu și în același timp vizual pentru descrierea proceselor de afaceri. Cu ajutorul acestui standard este posibil transferul de informații între dezvoltatori, consultanți și utilizatori. Standardul a fost dezvoltat foarte atent, este convenabil pentru design, universal. Există multe instrumente pentru a lucra cu el, de exemplu, VISIO, BPWIN, ERWIN, Bussines studio etc.

În plus, utilizarea IDEF0 pentru a crea modele de afaceri nu este doar convenabilă, ci este și corectă. Acest instrument a fost conceput pentru business intelligence, a suferit o lungă și minuțioasă depanare și lustruire. Prin urmare, utilizarea IDEF0 pentru a crea un model funcțional fără erori este mult mai ușoară decât fără utilizarea acestui standard.

După cum știți, cel mai bine este să bateți cuiele cu un ciocan. Desigur, puteți folosi și alte unelte pentru aceasta, dar un ciocan este cel mai funcțional și cel mai ușor este să bateți un cui frumos și precis cu el. Deci, cu utilizarea IDEF0 - acest instrument a fost creat pentru modelarea funcțională, iar cu ajutorul lui puteți obține rezultatul dorit mult mai rapid și mai precis.

Un exemplu de creare a unui model funcțional IDEF0

Pentru a înțelege cum să lucrați cu modelarea funcțională, voi da un exemplu al procesului de scriere a unui articol.

Blocul principal este „Scrieți un articol”.

Săgețile primite - „Experiență”, „Informații din surse terțe”. Acestea sunt intrările de care aveți nevoie pentru a începe.

Ghidurile pentru scrierea unui articol sunt „Planul de publicare”, „Cerințele editorilor”, „Regulile limbii ruse”.

Iar în rolul de „Mecanisme” se află autorul, redactorul, corectorul și software-ul. În acest caz, autorul creează un material audio în care adună toate gândurile și ideile care ar trebui să se reflecte în articol. Un copywriter este o persoană care creează, pe baza acestui material, ghidată de cerințele editorului, planul de publicare și regulile limbii ruse, textul final al articolului. Correctorul verifică materialul pentru erori. Iar software-ul este instrumentele pe care toți participanții la proces le folosesc în munca lor.

Astfel, am stabilit principalii parametri ai procesului, intrarea, ieșirea acestuia, precum și tot ceea ce este necesar pentru implementarea cu succes a procesului. Dar acesta este doar cadrul de bază al procesului. Aceasta descrie schema generală a companiei în ansamblu.

De fapt, procesul de creare a unui articol, ca orice proces de afaceri, poate și ar trebui să fie detaliat. Pentru a face acest lucru, descompun blocul general „scrieți un articol” în elemente interconectate.

În cazul nostru, munca este împărțită în 4 etape principale:

1. Pregătiți audio.
2. Pregătiți textul
3. Pregătiți textul pentru publicare.
4. Plasați un articol într-o publicație.

Diagrama arată clar în ce etapă ce elemente de control și ce mecanisme sunt implicate.

Deci, atunci când creează audio, autorul își folosește cunoștințele și experiența, fiind ghidat de planul de publicare și de cerințele editorului. Copywriterul primește o înregistrare audio ca intrare, din care, ghidat de regulile limbii ruse, creează un text. Correctorul primește textul și îl verifică, ghidându-se tot de regulile limbii ruse. Pentru a plasa un articol într-o publicație, este necesar un software special.

Atunci când se creează un model funcțional, parametrii cheie sunt scopul și punctul de vedere. Pe baza acestora, modelarea acelorași procese poate arăta oarecum diferită. De exemplu, în cazul meu, scopul este „să vorbesc despre procesul de scriere a unui articol”. Iar punctul de vedere al copywriter-ului este „scrierea și publicarea unui articol din punctul de vedere al managerului de proces”.

Deci, dacă același proces ar fi descris din punctul de vedere al unui copywriter, atunci intrarea ar fi o experiență și un fișier audio de la autor. Mai mult, în acest caz, Experiență ar însemna experiența unui copywriter, dar nu a unui lider sau autor. Prin urmare, primul lucru pe care trebuie să îl determinați atunci când creați un model de proces de afaceri este să alegeți un punct de vedere și să articulați clar scopul.

O astfel de modelare nu este doar vizuală, ci și foarte convenabilă pentru a lua decizii eficiente de management. De exemplu, în procesul de afaceri descris mai sus, există doi specialiști separați - un redactor și un corector. Dacă îmi stabilesc sarcina de a optimiza finanțarea proiectelor, atunci datorită schemei, voi vedea imediat unde este și cum se poate face. Deci, un redactor și un corector folosesc aproximativ aceleași reguli, dar redactorul primește audio și dă rezultatul sub formă de text, în timp ce corectorul acceptă și dă text. Și, prin urmare, dacă este necesar, pot, să zicem, pentru jumătate din costul sarcinilor unui corector, să ofer un copywriter. Așa că voi economisi bani și timp pe interacțiunea diferiților specialiști. Desigur, înțeleg toate meritele corectorilor și de ce este mai bine să lucrezi cu specialiști individuali. Dar vă reamintesc că am o sarcină: optimizarea costurilor.

Fără un astfel de instrument vizual, ar fi mai dificil să se determine care dintre blocuri poate fi îndepărtat și astfel să se optimizeze munca.

Cum se creează notații IDEF0

Există multe produse software diferite care pot fi folosite pentru a crea notații. Unele sunt concepute special pentru modelare funcțională, altele sunt concepute pentru orice lucrare cu elemente grafice. Unde și cum construiți aceste modele depinde de dvs.

Personal cred că la prima etapă nu există nimic mai bun decât hârtia obișnuită, un simplu creion și o radieră pentru a face ajustări în caz de greșeli.

Pentru a crea o notație pentru procesele de afaceri existente, de ex. pentru a descrie cum funcționează compania acum, este necesar să se studieze principiile muncii. Un specialist terță parte (consultant, dezvoltator) efectuează un interviu pentru aceasta. În prima etapă, șeful companiei răspunde întrebărilor, apoi, în procesul de detaliere a notării, se desfășoară interviuri cu angajații responsabili pentru diferite etape de lucru.

Este important să înțelegeți că, ca urmare, vor fi necesare 2 notații. Primul va afișa procesele de afaceri așa cum sunt. Îl creezi pe baza unui interviu și coordonezi fiecare detaliu cu angajații companiei și managerul. Este foarte important ca viziunea ta asupra proceselor existente să coincidă cu realitatea, iar aceasta este ceea ce necesită confirmare la toate nivelurile.

A doua notație este „cum ar trebui să fie”. Este creat pe baza primei și a acelor modificări pe care vă propuneți să le aduceți structurii de lucru pentru a optimiza și automatiza activitatea companiei ca parte a sarcinii.

Cerințele IDEF0

Cerințele de bază ale standardului IDEF0, în principiu, le-am descris mai sus și le-am arătat cu un exemplu.

1. În colțul din stânga sus este întotdeauna elementul principal.
2. Toate elementele trebuie să aibă săgeți de intrare și de ieșire, deoarece pentru execuție este necesar să primiți ceva la intrare (comandă, sarcină), iar după procesare la ieșire, este necesar să transferați produsul finit. Săgețile de intrare sunt întotdeauna în stânga, săgețile de ieșire sunt întotdeauna în dreapta.
3. Mai sus sunt elementele de control, mai jos sunt mecanismele necesare finalizarii procesului.
4. Dacă există mai multe blocuri pe o foaie (ecran), fiecare bloc următor este situat în dreapta și sub cel anterior.
5. Este necesar să ne străduim să creați scheme în așa fel încât intersecția săgeților să fie redusă la minimum necesar.

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 pentru erori și limitări ale standardului. Dorința de a crește vizibilitatea și lipsa de experiență se termină adesea în erori.

Utilizarea diferitelor culori

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

Adesea, atunci când modelează pe hârtie sau în diferite 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 introduce doar confuzie suplimentară și, de asemenea, distorsionează percepția schemei.

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, ca urmare, lizibilitatea și alfabetizarea modelului cresc.

Prea multe blocuri

Atunci când alcătuiesc 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. Lizibilitatea este pierdută.

Cea mai bună opțiune este detalierea suficientă pentru a înțelege problema și nimic mai mult. Detaliile detaliate ale activității fiecărui departament sau chiar ale unui 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 luarea deciziilor.

Încălcarea structurii la efectuarea ajustărilor

Urmăriți cu atenție pentru a evita confuzia sau procesele fără elemente de intrare, de ieșire și alte elemente importante. De exemplu, dacă în exemplul de mai sus, consider de cuviință să schimb punctul de vedere la copywriter, voi elimina autorul din schemă. Și atunci controalele „experiența autorului și a surselor terțe”, precum și planul de publicare devin inutile. La urma urmei, autorul le folosește. Copywriter-ul lucrează cu fișierul audio. Și dacă rămân în schema generală, atunci când vor detalia, vor duce de neînțeles unde și vor introduce confuzie.

La fel, dacă decid să adaug un bloc, este important să mă asigur că are și toate atributele necesare. Atenția 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. Ele trebuie introduse.

Reguli pentru denumirea controalelor și 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 „Creează un articol” se scrie „Creează un 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 - este vizibilitatea. Tu însuți începi să înțelegi cum funcționează acest sau acel sistem și, de asemenea, poți explica clar unde există „puncte subțiri” în acest sistem și cum soluțiile tale vor ajuta să scapi de ele.
• Înțelegere reciprocă și lipsă de dezacord. Când discutați despre munca companiei folosind modelul funcțional, aveți blocuri de sarcini vizuale și intuitive cu controale. În plus, modelarea funcțională presupune crearea, dacă este necesar, a unui glosar în care sunt dezvăluite simboluri și termeni. 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 schemă este, de fapt, o prezentare super-densă a informațiilor, care este foarte bună pentru înțelegere, dar este necesară o abordare specială pentru a implementa o astfel de prezentare. 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 ajutor vizual creat într-un timp scurt, să ilustrați puncte importante colegilor sau clienților.
• Disciplina si fara greseli. Standardul IDEF0 presupune cadre și reguli stricte. Această abordare disciplinează, 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, a profunzimii de înțelegere a 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 liderului, de parcă ar fi liderul.

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

Prin urmare, este foarte important să se consulte în mod constant cu șeful companiei atunci când se elaborează un model de afaceri funcțional „ca atare”, pentru a nu face greșeli care vor atrage automat erori în etapele de descompunere. De asemenea, în etapele ulterioare, pot fi necesare aprobări suplimentare din partea șefilor diviziilor structurale și a angajaților. Numai dacă modelul tău funcțional „ca atare” va reflecta cu adevărat starea reală a lucrurilor, poți face câteva modificări și sugestii. Și pentru a obține rezultate de înaltă calitate într-o astfel de muncă, în primul rând, este necesară experiența practică și cunoașterea caracteristicilor unui anumit tip de afacere.

Cel mai simplu și rapid mod de a crea diagrame folosind notațiile grafice idef0 și idef3 este să utilizați editorul multiplatformă distribuit gratuit pentru diagrame, diagrame de flux, diagrame de rețea, diagrame UML și alte spirite rele numite „Dia”. Programul a fost tradus în multe limbi, inclusiv rusă.

Puteți descărca programul de pe site-ul său oficial: http://projects.gnome.org/dia/. La momentul scrierii acestui articol, cea mai recentă versiune a programului Dia era numerotată 0.97.1 - și așa este de aproape doi ani. În ciuda acestui fapt, funcționalitatea aplicației este excelentă.

Construirea de diagrame IDEF0

pentru a crea diagrame în notația grafică idef0, este suficient să selectați biblioteca standard de elemente Dia numită "SADT / IDEF0":

Dacă este prima dată când întâlniți idef0, atunci vă recomand să citiți mai întâi aceste articole despre această metodologie:

1. Metodologii moderne pentru descrierea proceselor de afaceri. Metodologia IDEF0 - Kovalev Valery Mikhailovich (Revista „Director consultant”, nr. 12, iunie 2004)
2. IDEF0 ca instrument de modelare a proceselor - Andrey Dvornikov (Avant Partner Magazine, nr. 22(79), august 2005)
3. Experiență în utilizarea standardului IDEF0 - Sergey Rubtsov

Construirea de diagrame IDEF3

Cu idef3, e ceva mai complicat. Dia nu oferă un set standard de elemente pentru construirea unei diagrame în notația grafică idef3, dar programul are toate blocurile necesare. Trebuie doar grupate manual. Pentru a face acest lucru, faceți clic pe meniul: „Fișier -> categorii și obiecte”. În fereastra care se deschide, faceți clic pe butonul „Creați”. Se va deschide o altă fereastră, în care selectăm elementul „Nume categorie” și introducem acolo „idef3”. Procesul de creare a unei categorii arată cam așa:

Deoarece tocmai ați creat această categorie, desigur, este goală. Trebuie să mutăm elementele necesare ale schemelor în el. De aceea:

Faceți clic pe butonul „Aplicați”, „Închideți” fereastra și gata! Mergem la „alte biblioteci de elemente” și selectăm acolo notația grafică „idef3” creată de noi (este localizată în locul ei alfabetic). Apropo, pentru a scrie în blocuri, este convenabil să folosiți tasta F2. Desigur, acesta nu este un instrument perfect, dar această metodă vă permite să creați diagrame IDEF3 cât mai aproape posibil de notația lor grafică exactă.

Dacă cunoașteți alte instrumente gratuite de grafică IDEF3, atunci împărtășiți-le tuturor în comentarii.

Workshop privind aplicarea IDEF0 pentru descrierea funcțională a software-ului CAD

Workshop privind aplicarea IDEF0 pentru descrierea funcțională a software-ului
Partea 1.

Dacă analizăm anunțurile pentru angajarea angajaților firmelor implicate în dezvoltarea de software, atunci recent a existat o lipsă acută de manageri de proiect care să poată îndeplini cu competență stabilirea sarcinilor. Problema nu este că nu pot formula problema, ci că nu pot documenta în mod corespunzător documentația, ținând cont de standardele moderne de proiectare. Clientul dejanu este suficient să dai câteva frunze tastate în Word. El vrea documentație proiectată în BPWin, ErWin, S-Designer, Power Designer, Rational Rose etc. În spatele fiecăruia dintre aceste instrumente CASE se află un standard. Acest articol este dedicat uneia dintre ele - IDEF0.

Introducere. La compilarea documentației, fiecare manager de proiect consideră că este „o onoare” să vină cu ceva „al lui” – propriul „super format” de prezentare a ideilor sale. Complexitatea proiectelor este în creștere, volumul documentației pentru proiect crește, documentația depășește grupul de lucru... și atunci devine clar că documentația nu se potrivește clientului sau grupului de dezvoltatori care finalizează proiectul si mentinerea acestuia.

De obicei, managerul de proiect este fie un programator de clasă (programatorul principal al subiectului - proiectul), fie o persoană care vorbește bine o limbă străină și este familiarizată cu programarea. Acestea sunt principalele criterii de selecție pentru postul de manager de proiect. Aceasta este rădăcina problemei. Poți fi un programator grozav sau doar un angajat bun, dar asta nu are nimic de-a face cu documentația.

De obicei, specificațiile pentru fiecare tip de manager se reduc fie la o descriere a modelului programului în sine (arhitectura modulelor, clase, DLL, structura bazei de date și utilizarea acesteia etc.), fie la o descriere a funcțiilor utilizatorului (ceea ce acestea ar trebui să facă, ce forme ar trebui să fie în program etc.).

Opțiunea ideală este atunci când clientul stabilește sarcina. În acest caz, poți trăi după principiul „clientul dorește”, iar atâta timp cât este mulțumit, primești bani de la client. Dar tot mai multe proiecte sunt create în profunzimea oricărei organizații și apoi oferite clientului. Și în acest caz, calitatea documentației, ceea ce ați făcut și ce intenționați să faceți, iese în prim-plan. Documentația în acest caz este totul...

Standardul IDEF0 (Integrated Definition Function Modeling) este conceput pentru modelarea funcțională și a fost adoptat ca standard federal din SUA. Standardul IDEF0 este unul dintr-un grup de standarde utilizate pe scară largă pentru a descrie orice proces de afaceri. Utilizarea sa pentru descrierea proiectelor software este o direcție foarte tânără, dar utilizarea IDEF0 garantează că partenerii dvs. vă iau în serios...

Aplicarea standardelor grupului IDEF (IDEF0, IDEF1 etc.) este condiția efectivă pentru obținerea statutului de organizație care îndeplinește ISO9000, ISO9001. Aceste standarde pentru o organizație sunt o oportunitate de a crește vânzările de produse, o oportunitate de a demonstra că aceasta se află „pe creasta unui val”.

Mulți programatori folosesc CASE ErWin pe scară largă fără să știe că se bazează pe standardul IDEF1. Nu este doar ceea ce îți place sau ce le place clienților tăi. Acesta este standardul - și asta spune totul.

Scurte concepte de bază ale standardului IDEF0. Standardul IDEF0 se bazează pe conceptul de funcție. O funcție este o acțiune controlată asupra datelor de intrare care are ca rezultat date de ieșire, folosind un mecanism prin care se realizează această acțiune.

Standardul IDEF0 se bazează pe trei principii de bază:

1. principiul descompunerii functionale - orice functie poate fi descompusa (detaliata, defalcata) in functii mai simple;

2. principiul limitării complexității - numărul de blocuri din diagramă trebuie să fie 2...6 (condiția de lizibilitate);

3. Principiul contextului - modelarea procesului de afaceri începe cu construirea unei diagrame de context, care afișează un singur bloc - funcția principală a sistemului de modelare, care limitează zona limită a sistemului de modelare (reglementează etapa inițială a construirii modelului).

Diagramele IDEF0 sunt construite folosind blocuri. Fiecare bloc descrie o acțiune (funcție) finalizată.

Cele patru laturi ale blocului au scopuri diferite. Datele de intrare sunt afișate în stânga, datele de ieșire sunt afișate în dreapta, controlul este afișat în partea de sus, mecanismul este afișat în partea de jos.

Date de intrare - resurse inițiale pentru funcția descrisă de bloc (informații inițiale, materiale).

Date de ieșire - resursele rezultate obținute ca urmare a execuției funcției descrise de bloc (informații de ieșire, materiale sursă prelucrate).

Controlul este ceea ce afectează procesul de îndeplinire a funcției descrise de bloc și vă permite să influențați rezultatul acțiunii (comenzi, senzori, oameni).

Mecanismul este acela prin care se realizează acțiunea dată (mașini, dispozitive, resurse umane, software).

Interacțiunea dintre blocuri este afișată ca arce (săgeți). Uneori, părțile laterale ale blocului se numesc direcții, iar săgețile se numesc fluxuri. Săgețile pot fi semnate. Semnăturile sunt asociate cu săgeata corespunzătoare folosind un zigzag (fulger).

Vederea generală a implementării blocului IDEF0-diagramă este prezentată în Fig.1.

Fig.1. Implementarea blocului utilizat în diagramele IDEF0.

Când descompuneți (detaliați) o funcție, diagrama nou formată afișează toate săgețile de intrare și de ieșire (arcuri, fluxuri) asociate cu funcția descompusă. Numărul de săgeți la orice nivel al diagramei și în orice direcție nu este limitat. Diagrama se numește blocul rupt (funcția). Doar numele diagramei-context (DC) coincide cu numele funcției conținute în diagramă.

În esență, diagramele formează un arbore. Orice diagramă acționează ca un DC în raport cu cele subiacente.

Ca exemplu, luați în considerare o funcție abstractă. Această funcție are date de intrare, două tipuri eterogene de date de ieșire, este controlată de o influență externă și este implementată de mecanismele A și B. Un exemplu de diagramă de context principal este prezentat în Fig. 2 și o versiune detaliată (descompusă) a această funcție, constând din două funcții (acțiuni mai elementare), prezentată în Fig.3. La rândul lor, funcțiile 1 și 2 pot fi de asemenea detaliate (descompuse).

Fig.2. Un exemplu de diagramă de bază.

Fig.3. Un exemplu de descompunere a funcției principale.

Diagrama se află pe un formular special, care conține numele funcției, imaginea sa grafică, desemnarea diagramei cu nivelul de imbricare, link-uri către alte funcții, informații speciale despre autor, organizare și proiectul descris.

Conexiuni. Săgețile sau arcurile arată relațiile dintre blocuri. Săgețile semnează de obicei. Etichetele săgeților sunt selectate ca substantive. Pentru comoditate, săgețile sunt conectate la semnături cu fulgere. Pentru lizibilitatea diagramei IDEF0, se recomandă ca etichetele să fie plasate fie deasupra săgeții, fie în dreapta săgeții.

De obicei, cablarea începe cu date. Intrarea sunt datele necesare pentru a executa funcția. Rareori apar întrebări în această direcție. Ieșirea sunt datele care sunt rezultatul executării funcției. Cea mai simplă situație este atunci când ieșirea este intrarea către alt bloc. Este întotdeauna așa? Dacă funcția, care procesează informațiile de intrare, formează o comandă de control, acesta este control. Aproximativ aceeași situație la formarea funcției de format de date. Un format de date este un mecanism de transmitere a informațiilor.

Principalele tipuri de conexiuni între blocurile din diagramă, formate pe baza informațiilor de ieșire, sunt prezentate în Fig.1.

Fig.4. Tipuri de conexiuni între blocuri din diagramă. În consecință, a) comunicarea de date, b) comunicarea de control, c) comunicarea mecanismului, d) feedback-ul.

Feedback-ul este o legătură care formează un inel între blocuri de date, control sau format. Un exemplu de astfel de conexiune este prezentat în Fig. 2.d. Când apare o astfel de conexiune, verificați dacă diagrama dvs. este redusă la o organigramă a algoritmului. Prezența unei astfel de conexiuni nu este un semn al unei erori.

Blocare prioritate și numerotare. Toate blocurile au prioritate. Prioritatea blocurilor depinde de ordinea în care sunt executate. Blocurile situate în stânga și în partea de sus au cea mai mare prioritate. Dominanta este pozitia orizontala.

Numerotarea blocurilor (indexul blocurilor pe diagramă) din diagramă este determinată în funcție de prioritate. Numerotarea începe de la unu. Codul diagramei este format din litera „A” și un număr. DC are codul A-0. Litera „A” înseamnă acțiune activă (din engleză activ). Diagrama, care este o versiune descompusă a DC, va avea codul A0. Fiecare element din diagrama A0 va fi codificat de la A1 la A6 în funcție de prioritate. La rândul său, la descompunerea unuia dintre blocurile A1...A6, codurile blocurilor din diagrama nou descompusă vor consta din codul diagramei descompuse plus indexul blocului selectat. Codurile blocurilor de diagramă nu se repetă pe întreaga diagramă.

După numărul de cifre din codul diagramei, puteți determina nivelul diagramei - nivelul de descompunere a DC. Se obișnuiește să se considere DC ca nivel principal, iar restul de la primul nivel de descompunere și mai sus.

Tipuri de secvențe de acțiuni. Datele pot fi procesate secvenţial sau în paralel.

Un exemplu de procesare secvențială este completarea unei agende de adrese (la urma urmei, două adrese nu pot fi scrise în ea în același timp). Doar o singură instanță de date este întotdeauna procesată în fiecare bloc, modificându-se secvenţial după fiecare procesare. Blocurile sunt aranjate fie secvenţial orizontal, fie oblic din colţul din stânga sus spre dreapta jos.

Un exemplu de procesare paralelă - poți să te uiți la televizor și să mănânci un măr în același timp. În acest caz, două acțiuni sunt efectuate simultan. Aceste acțiuni nu au legătură. Astfel de blocuri din diagramă sunt aranjate vertical unul deasupra celuilalt.

Adesea există un grup de acțiuni (blocuri) pe diagramă, dintre care doar unul este executat, în funcție de o anumită condiție. Astfel de acțiuni se numesc alternative. Condiția ar trebui aplicată unor astfel de blocuri ca o acțiune de control (alegerea acțiunii). Se recomandă introducerea unui bloc special în diagramă care gestionează condiția de selectare a unei acțiuni alternative (bloc). Acest bloc generează comenzi separate la alegere pentru fiecare bloc.

Rolul unei persoane în diagramele IDEF0. Cine este el: management sau mecanism? Tu decizi ce funcții îndeplinește o persoană în sarcina descrisă. Dacă acțiunea conținută în bloc este controlată de o persoană, atunci control. Dacă acțiunea este efectuată de o persoană, atunci mecanismul. Totul depinde de gradul de abstractizare al reprezentării problemei tale.

Există cazuri când o persoană (inclusiv aceeași) pentru un bloc va acționa ca mecanism și control. ASTA SE INTAMPLA. De exemplu, o persoană scrie o scrisoare. Este scris de această persoană, iar această persoană gestionează conținutul acestei scrisori.

date de control. Managementul este o echipă. Dacă comanda conține o parte informativă (nume, condiții, termene limită etc.), atunci partea informativă a comenzii este datele de intrare.

Cea mai simplă soluție este să împărțiți săgeata inițială în două: control și date. Aceste săgeți conduc la părțile corespunzătoare ale blocului. Ambele săgeți divizate trebuie să fie etichetate corespunzător.

Serghei Sokolov (Minsk, BSUIR)
E-mail: