Idef0 diagrammi loomine. Kursusetöö: Kasvuhoone ettevõtlusmudeli väljatöötamine IDEF0, DFD ja IDEF3 projekteerimismetoodika abil. Lagunemisskeem A3

Sageli palutakse arendajatel mitte ainult tuvastada ja lahendada probleem ettevõtte töös, vaid ka määrata, millist rolli see ettevõtte struktuuris mängib. Sest palju olulisem on mõista, kuidas rikkega üksus teistega suhtleb, kui lihtsalt mõista, miks see korralikult ei tööta. Seetõttu algab iga probleemi tuvastamine ettevõtte töö uurimisest ja selle funktsionaalse mudeli koostamisest.

Sageli palutakse arendajatel mitte ainult tuvastada ja lahendada probleem ettevõtte töös, vaid ka määrata, millist rolli see ettevõtte struktuuris mängib. Sest palju olulisem on mõista, kuidas rikkega üksus teistega suhtleb, kui lihtsalt mõista, miks see korralikult ei tööta. Seetõttu algab iga probleemi tuvastamine ettevõtte töö uurimisest ja selle funktsionaalse mudeli koostamisest.

Ütlete, et juhil peaks olema ettevõtte funktsionaalne mudel, sõltumata sellest, millisest ettevõttest me räägime. Kuid nagu näitab praktika, enamikul juhtudel see mudel puudub.

Graafika eelis

Mis on IDEF0 mudelid? Graafilised skeemid, millel on oma omadused ja nende ehitamise reeglid. Miks just graafika? Sest see on tõhus. Seda võib näha mitmest näitest.

Kujutame ette, et sõjaliste operatsioonide sõjalist plaani selgitati sõnadega, mitte aga nende külge kantud graafiliste sümbolitega kaartide abil. Nüüd tundub see võimatu, kuid kuni 19. sajandi teise pooleni oli see täpselt nii. Graafika aitab mõista, mida seletada, ja sellest tulenevalt mõista, mis on piisavalt raske.

Sama on äriprotsessidega: palju tehnilised ülesanded saab teostada graafiliste märkmete kujul, mis lihtsustab arendajate ülesannet oluliselt ja säästab klientide raha.

IDEF0 eelisedIT-spetsialistid

Arendajate tegevus, olgu see näiteks CRM -i installimine või tõhusa ERP loomine, on seotud juba loodud süsteemi muudatuste tegemisega. Ja selleks, et seda õigesti teha, peate kõigepealt uurima, kuidas see süsteem töötab. Pärast selle uurimist kirjutab arendaja kaubandusliku ettepaneku, milles ta esitab oma nägemuse olukorrast, probleemi lahendamiseks vajalikud toimingud ja oodatava tulemuse. Selline dokument võib võtta rohkem kui tosinat lehekülge. Ühest küljest on see hea, sest klient saab maksimaalselt huvipakkuvat teavet. Teisest küljest võtab pika teksti uurimine aega. edukas ärimees sageli mitte.

Niisiis, kuidas on võimalik olemust edasi anda ilma mahukate tekstide poole pöördumata? Graafika! Just tema võimaldab teil kirjutatut lühendada, näidates selgelt vajalikku teavet. Lõppude lõpuks võib üks pilt asendada sadu sõnu. Ja seoses graafika kasutamisega äriprotsesside kirjeldamisel on see 100% tõsi.

Mõistame kõigepealt, mis on märge ja IDEF0 ning milleks need on mõeldud.

Märge äriprotsesside kirjeldamiseks: mis see on

Märkimine on vorming, milles äriprotsesse esitatakse modelleerimisel kasutatavate graafiliste objektide ja otseselt modelleerivate reeglite kujul. Märkimine on omamoodi graafiline keel, mis võimaldab teil esindada ettevõtte toimimist, näidates osakondade ja osakondade vahelist suhet. See tähendab, et märget võib pidada omamoodi programmeerimiskeeleks ärianalüüsis.

IDEF0 on ...

IDEF0 on funktsionaalne modelleerimismeetod ja graafiline märge, mida kasutatakse äriprotsesside kirjeldamiseks ja vormistamiseks. IDEF0 eripära on see, et see metoodika on keskendunud objektide allutamisele. IDEF0 töötati välja ettevõtte automatiseerimiseks juba 1981. aastal Ameerika Ühendriikides.

Ettevõtte funktsionaalne mudel

Funktsionaalne mudel IDEF0 on plokid, millest igaühel on mitu sisendit ja väljundit. Igal plokil on juhtseadised ja mehhanismid, mis on vajalikul tasemel üksikasjalikud. Kõige olulisem funktsioon asub vasakus ülanurgas. See ühendub ülejäänud noolte ja funktsiooniplokkide kirjeldustega. Igal noolel või tegevusel on oma tähendus. Seetõttu kasutatakse sellist mudelit mis tahes haldus- ja korraldusprotsesside kirjeldamiseks.

Noole tüübid

Sissetulevülesanded on seatud.

Väljuv kuvada tegevuse tulemus.

Juhid(nooled ülevalt alla) on juhtimismehhanismid.

Mehhanismid(nooled alt üles) kasutatakse vajalike tööde teostamiseks.

Funktsionaalse mudeliga töötamisel võetakse vastu järgmised reeglid. Näiteks nimetatakse nooli nimisõnadega (reeglid, plaan jne), plokke - tegusõnadega (pidage arvestust, sõlmige leping).

IDEF0 võimaldab teil teavet vahetada, samas kui selle mitmekülgsuse ja nähtavuse tõttu saavad vahetuses osalejad üksteisest kergesti aru. IDEF0 on hoolikalt välja töötatud ja täiustatud, saate IDEF0 -ga koostööd teha, kasutades erinevaid tööriistu, näiteks ERWIN, VISIO, Bussines stuudio.

IDEF0 -l on ka vaieldamatu eelis. See tehnika töötati välja suhteliselt kaua aega tagasi ja kolme aastakümne jooksul on see põhjalikult lihvitud ja reguleeritud. Seetõttu on võimalik kiiresti ja minimaalse vea tõenäosusega luua ettevõtte funktsionaalne mudel.

Loomulikult on ka teisi metoodikaid, miks me soovitame IDEF0? Metalltoru võib rauaga ära lõigata, kuid näete, veskiga on seda palju lihtsam teha. Sama ka IDEF0 puhul: modelleerimiseks pole funktsionaalsemat tööriista, selle abil saate hõlpsalt ja kiiresti vajaliku tulemuse.

Kuidas luuakse funktsionaalne mudel

Analüüsime funktsionaalse mudeli loomist artikli kirjutamise näitel.

Põhiseade nimetatakse "artiklite kirjutamiseks".

See, mida on vaja artikli kirjutamiseks, kajastub sissetulevad nooled- "Kogemus", "Edasine lugemine".

Juhtnooled artikli kirjutamiseks - "Artikli ülevaade", "Registreerimise nõuded", "Vene keele reeglid".

Mehhanismid on otseselt autor ise, copywriter, toimetaja, tarkvara. Kuidas neid mehhanisme korraldatakse? Autor loob teksti, salvestades selle heliversiooni. Copywriter kannab teksti tekstivormingusse, keskendudes avaldamiskavale, järgides kirjastaja nõudeid ja vene keele reegleid. Seejärel ühendatakse tööga toimetaja, kes kontrollib artiklit, parandab kõne-, õigekirja- ja kirjavahemärke. Tarkvara on programmid ja tööriistad, mida protsessis osalejad artikli loomiseks kasutasid.

Kõik ülaltoodud on ainult üldine töö skeem, seega tuleb seda üksikasjalikult kirjeldada.

Läheme tagasi oma mudeli juurde ja lagundame ühise ploki mitmeks seotud elemendiks.

Seega võib kogu artikli kirjutamise protsessi jagada neljaks etapiks:

  1. Valmistage ette heliversioon.
  2. Valmistage trükitud tekst ette.
  3. Teksti toimetamine ja trükkimiseks ettevalmistamine.
  4. Artikli avaldamine.

Diagramm kajastab teavet selle kohta, millised juhtimisseadmed ja mehhanismid on millises etapis kaasatud. Näiteks kvaliteetse teksti loomiseks kasutab autor oma kogemusi ja teadmisi, juhendina kasutab avaldamiskava ja kirjastaja nõudeid. Copywriter, luues teksti trükitud versiooni ja toimetaja, parandades seda, kasutavad vene keele reegleid. Artikli avaldamiseks näiteks veebiväljaandes on vaja spetsiaalset tarkvara.

Funktsionaalse mudeli koostamisel juhindub esineja selle loomise eesmärgist ja oma vaatenurgast.

Funktsionaalset modelleerimist kasutatakse tõhusalt erinevate juhtimisotsuste tegemisel. Meie näites artikli kirjutamise protsessist on kaks spetsialisti - copywriter ja toimetaja. Ja projekti rahastamise vajaliku optimeerimisega vastavalt skeemile ei ole raske kindlaks teha, kuidas seda teha. Copywriteril ja korrektoril on sarnased töömeetodid, nii et kogu tööd saab copywriterile pakkuda, kuna ta töötab otse helitekstiga, mida toimetaja teha ei saa. Samal ajal võib copywriterile pakkuda seda tööd teha poole summast, mis oli mõeldud toimetajale. Jah, sellest tulenevalt võib teksti kvaliteet kaduda, kuid optimeerimisülesanne täideti edukalt. Ja ilma visuaalse skeemita oleks seda keerulisem teha.

Märkmete loomise protsessIDEF0

Märkmete loomiseks on palju programme. Mõned neist on loodud funktsionaalsete mudelite loomiseks, teised aga võimaldavad teil töötada mis tahes graafiliste objektidega. Ja kellelegi piisab esimeses etapis paberilehest, pliiatsist ja kustutuskummist.

Enne ettevõtte töö kirjeldamise, st otse äriprotsesside märkimise loomist, peaksite uurima ettevõtte toimimise põhimõtteid. Selleks viib intervjuu läbi kolmanda osapoole spetsialist. Esiteks vastab küsimusele ettevõtte juht, seejärel spetsialistid, kes juhendavad teisi tööetappe.

Töö esimese etapi tulemuseks on kaks märget. Üks neist kajastab äriprotsesse nende algsel kujul. See märge luuakse vestluse tulemuste põhjal ning iga detail tuleb kokku leppida ettevõtte juhi ja selle töötajatega. On hädavajalik, et teie arusaam ettevõtte olemasolevatest äriprotsessidest langeks kokku tegelikkusega, see nõuab kinnitust kõigil tasanditel.

Teist märget võib nimetada "nagu peaks". See luuakse esimese põhjal, muutes vastavalt ülesandele.

IDEF0 standard ja selle nõuded

Me rääkisime IDEF0 põhinõuetest veidi eespool.

  1. Peamine element asub vasakus ülanurgas.
  2. Igal elemendil peavad olema sissetulevad ja väljaminevad nooled. Pealegi on sissetulevad nooled vasakul, paremal - väljuvad.
  3. Juhtelemendid asuvad ülaosas, mehhanismid all.
  4. Kui paigutate ühele lehele või ekraanile mitu plokki, asetatakse järgnevad eelmisest paremal allosas.
  5. Skeemid tuleks luua nii, et nooled ristuksid minimaalse arvu kordadega.
Loomulikult on IDEF0 standardil üldtunnustatud normid, nõuded ja tähised. Me ei peatu nendel üksikasjalikult, soovi korral on seda teavet lihtne leida.

Viga IDEF0 -ga töötamisel

Nagu iga tegevuse puhul, esineb ka funktsionaalse modelleerimise teostamisel vigu. Analüüsime kõige tüüpilisemat.

Mitme värvi kasutamine

Oluline on meeles pidada, et funktsionaalses modelleerimises on kõik elemendid olulised, pole ühtegi tähtsamat või vähemtähtsat. Kui modelleerite paberil või ühes arvutiprogrammid kasutajad püüavad diagrammi visuaalsemaks muuta, värvides plokke ja nooli erinevates värvides... Kuid praktikas ei muuda see mitte ainult skeemi visuaalsemaks, vaid põhjustab vastupidi segadust ja asjaolu, et kujutatava tajumine on moonutatud.

Seetõttu on ideaalne võimalus mustvalge skeem ilma täiendavate värvivalikute kasutamiseta. See mitte ainult ei aita kõrvaldada arusaamatusi, vaid distsiplineerib ka mudeli loojat, mis mõjutab soodsalt mudeli loetavust ja selgust.

Suur hulk plokke

Ettevõtte töö funktsionaalse mudeli koostamisel püüavad selle autorid sageli kõike, isegi kõige väiksemaid detaile, kajastada. Selgub diagramm tohutu hulga plokkide ja nooltega. Selle tulemusena väheneb selle loetavus ja selgus.

Selle vea vältimiseks kasutage probleemi mõistmiseks piisavalt üksikasju. Üksikasjalikud üksikasjad koostatakse ainult siis, kui seda on tõesti vaja mõne olulise probleemi lahendamiseks.

Struktuuri muutmine vigade parandamisel

Diagrammi koostamisel on oluline, et rohkem kui üks protsess ei jääks ilma sissetulevate, väljaminevate või muude oluliste elementideta. Näiteks kui soovite autori skeemist eemaldada, peate eemaldama kõik temaga otseselt seotud elemendid ja nooled. Kui nad skeemi jäävad, tekivad arusaamatused ja segadus, kuna detailide koostamise ajal ei vii keegi kuhugi.

Sama olukord tekib ploki lisamisega. Kui peate täitma teavet, kontrollige, kas olete nõutud atribuudid esitanud. Seda tuleks tähelepanelikult jälgida, sest keerukate äriprotsesside modelleerimisel toob isegi väike muutus ühes osas kaasa muudatusi teises.

Plokkide ja juhtelementide nimed

Mudelielementide nimetamise reeglid on üsna lihtsad, kuid neid on äärmiselt oluline meeles pidada: juhtnooli nimetatakse nimisõnadeks, plokke tegusõnadeks. See reegel on kirjutatud IDEF0 standardisse ja aitab vältida segadust ja vigu.

IDEF0 kasutamise eelised

Nähtavus. Kujutades ettevõtte tööd diagrammi kujul, saab selgeks, kuidas ettevõte töötab, kus võivad tekkida probleemid ja kuidas neid ennetada.

Vastastikune mõistmine, skeemi valesti tõlgendamise võimaluse välistamine. Funktsionaalse mudeli nähtavus ja ligipääsetavus, mis esindavad ettevõtte tööd plokkide ja juhtelementide kujul, aitavad teid ettevõtte juhtkonnaga arutamisel. Muide, vajadusel luuakse funktsionaalse mudeli jaoks sõnastik, mis sisaldab kõiki termineid ja konventsioone. Seega minimeeritakse teie ja juhi, ettevõtte töötajate vahelise arusaamatuse võimalus.

Lihtsus ja aja kokkuhoid mudeli loomisel. Loomulikult võtab funktsionaalse modelleerimise oskus palju aega. Kõigepealt peate õppima, kuidas esitada tohutul hulgal teavet lakoonilise skeemi kujul, s.t. suutma filtreerida ja tihendada algseid andmeid. Kuid treeningutele kulunud aeg ja vaev tasusid end hiljem ära. Lõppude lõpuks ei võta funktsionaalse mudeli loomine ja juurdepääsetaval viisil esitamine palju aega.

Minimaalne vea tõenäosus. IDEF0 standardi järgi töötamine nõuab selle reeglite ranget järgimist. See distsiplineerib esinejat ja välistab vigade võimaluse. Lisaks muutub iga standardile mittevastavus kohe märgatavaks.

Ja lõpuks

Kahe ärianalüütiku jaoks võivad funktsionaalsed mudelid olla samad ainult siis, kui ettevõtte struktuur on äärmiselt lihtne. Muudel juhtudel erinevad mudelid üksteisest. See on loomulik, sest igal analüütikul on oma kindel kogemus, oma arusaam ettevõtte toimimisest, oma seisukoht, kuidas talle pandud ülesandeid lahendada. Ärianalüütik töötab välja funktsionaalse mudeli juhi seisukohast, kujutab ette, kuidas ta lahendaks määratud ülesandeid.

Meie arvates on IDEF0 tööriist kasulik mitte ainult professionaalsetele ärianalüütikutele, vaid ka neile, kes oma äri otseselt analüüsivad ja püüavad luua tõhusat juhtimissüsteemi.


Õppige nägema ja mõistma oma ettevõtte funktsionaalset struktuuri!

Praegu on Venemaal huvi läänes üldiselt aktsepteeritud juhtimisstandardite vastu järsult suurenenud, kuid tegelikus juhtimispraktikas on üks väga soovituslik hetk. Paljusid juhte võib endiselt hämmeldada otsene küsimus organisatsiooniline struktuur ettevõtte või olemasolevate äriprotsesside skeemi kohta. Kõige arenenumad juhid, kes regulaarselt majandusperioodikat loevad, hakkavad reeglina joonistama hierarhilisi diagramme, mis on arusaadavad ainult neile, kuid selle käigus jõuavad nad tavaliselt kiiresti tupikusse. Sama kehtib erinevate teenuste ja funktsionaalsete üksuste töötajate ja juhtide kohta. Enamasti on ainus reeglite kogum, mille kohaselt ettevõte peaks tegutsema, üksikute sätete kogum ja töökirjeldus... Enamasti koostati need dokumendid rohkem kui aasta tagasi, need on halvasti struktureeritud ja omavahel ühendatud ning koguvad seetõttu lihtsalt riiulitele tolmu. Esialgu oli selline lähenemine õigustatud, kuna Venemaa turumajanduse kujunemise ajal konkurentsi mõiste praktiliselt puudus ja kuludega arvestamiseks erilist vajadust polnud - kasum oli hiiglaslik. Selle tulemusena oleme viimase kahe aasta jooksul näinud täiesti arusaadavat pilti: 90ndate alguses kasvanud suurettevõtted kaotavad järk -järgult oma positsiooni kuni täieliku turult eemaldumiseni. See on osaliselt tingitud asjaolust, et ettevõte ei rakendanud juhtimisstandardeid, funktsionaalse tegevusmudeli ja missiooni kontseptsioon puudus täielikult. Erinevate tegevusvaldkondade modelleerimise abil on võimalik tõhusalt analüüsida juhtimise kitsaskohti ja optimeerida üldist äriskeemi. Kuid nagu teate, on mis tahes ettevõttes esmatähtsad ainult need projektid, mis toovad otseselt kasumit, seetõttu räägime tegevuste ja selle uuringust tavaliselt ainult ettevõtte juhtimise käegakatsutava kriisi ajal. ümberkorraldamine.

90ndate lõpus, kui turg oli piisavalt konkurentsivõimeline ja ettevõtete kasumlikkus hakkas järsult langema, tundsid juhid tohutuid raskusi kulude optimeerimisel, et tooted jääksid nii kasumlikuks kui ka konkurentsivõimeliseks. Just sel hetkel ilmnes selgelt vajadus, et teie silme ees oleks ettevõtte tegevuse mudel, mis kajastaks kõiki mehhanisme ja põhimõtteid erinevate allsüsteemide ühendamiseks ühe ettevõtte raames.

Mõiste "äriprotsesside modelleerimine" tuli enamiku analüütikute igapäevaellu samaaegselt keerukate turule ilmumisega tarkvaratooted mõeldud ettevõtte juhtimise keerukaks automatiseerimiseks. Sellised süsteemid tähendavad alati sügavat projekti eelne küsitlus ettevõtte tegevust. Selle uuringu tulemuseks on ekspertarvamus, kus soovitused kõrvaldamiseks esitatakse eraldi punktide kaupa. " kitsaskohti”Tegevuste juhtimisel. Selle järelduse põhjal viiakse vahetult enne automatiseerimissüsteemi kasutuselevõtmise projekti läbi äriprotsesside niinimetatud ümberkorraldamine, mis on kohati üsna tõsine ja ettevõtte jaoks valus. Seda ja loomulikult aastate jooksul välja kujunenud meeskonda on alati raske sundida “uuel viisil mõtlema”. Sellised keerulised ettevõtete uuringud on alati keerulised ja iga juhtumi puhul oluliselt erinevad ülesanded. Selliste keerukate süsteemide modelleerimise probleemide lahendamiseks on hästi proovitud metoodika ja standardid. Need standardid hõlmavad IDEF perekonna metoodikat. Nende abiga on võimalik erinevates sektsioonides tõhusalt kuvada ja analüüsida paljude erinevate süsteemide tegevuse mudeleid. Samal ajal määrab süsteemi protsesside uurimise laiuse ja sügavuse arendaja ise, mis võimaldab loodud mudelit mitte üle koormata mittevajalike andmetega. V praegu IDEF -i perekonnale võib omistada järgmised standardid:

IDEF0 on funktsionaalse modelleerimise metoodika. Visuaalse graafilise keele IDEF0 abil näib uuritav süsteem arendajatele ja analüütikutele omavahel seotud funktsioonide komplekti kujul (funktsionaalsed plokid - IDEF0 mõttes). Tavaliselt on IDEF0 modelleerimine esimene samm mis tahes süsteemi tundmaõppimisel;

IDEF1 - süsteemisiseste infovoogude modelleerimise metoodika, mis võimaldab kuvada ja analüüsida nende struktuuri ja seoseid;

IDEF1X (IDEF1 Extended) on metoodika relatsioonistruktuuride ehitamiseks. IDEF1X kuulub metoodikatüüpi "Entity-relationship" (ER-Entity-Relationship) ja seda kasutatakse reeglina kõnealuse süsteemiga seotud relatsiooniandmebaaside modelleerimiseks;

IDEF2 on metoodika süsteemide arendamise dünaamiliseks modelleerimiseks. Dünaamiliste süsteemide analüüsimisel tekkivate väga tõsiste raskuste tõttu loobuti sellest standardist praktiliselt ja selle arendamine peatati algusjärgus. Kuid praegu on olemas algoritmid ja nende arvutitehnoloogiad, mis võimaldavad muuta staatiliste IDEF0 diagrammide komplekti dünaamilisteks mudeliteks, mis põhinevad värvilistel Petri -võrkudel (CPN - Color Petri Nets);

IDEF3 on süsteemis toimuvate protsesside dokumenteerimise metoodika, mida kasutatakse näiteks ettevõtete tehnoloogiliste protsesside uurimisel. IDEF3 kirjeldab iga protsessi stsenaariumi ja töövoogu. IDEF3 -l on IDEF0 metoodikaga otsene seos - iga funktsiooni (funktsionaalne plokk) saab IDEF3 abil esitada eraldi protsessina;

IDEF4 on metoodika objektorienteeritud süsteemide loomiseks. IDEF4 tööriistad võimaldavad visuaalselt kuvada objektide struktuuri ja nende interaktsiooni aluspõhimõtteid, võimaldades seeläbi analüüsida ja optimeerida keerukaid objektorienteeritud süsteeme;

IDEF5 on keerukate süsteemide ontoloogilise uurimise metoodika. IDEF5 metoodikat kasutades saab süsteemi ontoloogiat kirjeldada teatud terminite ja reeglite sõnastiku abil, mille põhjal saab moodustada usaldusväärseid väiteid vaadeldava süsteemi seisundi kohta teatud ajahetkel. Nende väidete põhjal tehakse järeldusi edasine areng süsteem ja selle optimeerimine.
Selles artiklis vaatleme kõige sagedamini kasutatavat funktsionaalse modelleerimise metoodikat IDEF0.

IDEF0 standardi ajalugu

IDEF0 metoodikat võib pidada funktsionaalsete süsteemide kirjeldamiseks tuntud graafilise keele arendamise järgmiseks etapiks SADT (Structured Analysis and Design Teqnique). Mitu aastat tagasi ilmus Venemaal samanimelise raamatu väike väljaanne, mis oli pühendatud SADT diagrammide koostamise aluspõhimõtete kirjeldamisele. Ajalooliselt töötati IDEF0 standardina välja 1981. aastal osana ulatuslikust tööstusautomaatika programmist nimega ICAM (Integrated Computer Aided Manufacturing) ja selle pakkus välja USA õhujõud. IDEF -i standardite perekond on pärinud oma nimetuse selle programmi nimest (IDEF = ICAM DEFinition). Praktilise rakendamise käigus seisid ICAM programmis osalejad silmitsi vajadusega töötada välja uued meetodid tööstuslike süsteemide interaktsiooniprotsesside analüüsimiseks. Samal ajal oli lisaks äriprotsesside kirjeldamise täiustatud funktsioonide komplektile üheks uue standardi nõudeks tõhusa suhtlemismetoodika kättesaadavus „analüütik-spetsialist” raames. Teisisõnu pidi uus meetod pakkuma mudeli loomisel rühmatööd, kus osalesid otseselt kõik projektiga seotud analüütikud ja spetsialistid.

Sobivate lahenduste otsimise tulemusena sündis IDEF0 funktsionaalse modelleerimise metoodika. Alates 1981. aastast on IDEF0 standardis tehtud mitmeid väiksemaid, enamasti piiravaid muudatusi ning selle viimase redaktsiooni avaldas USA riiklik standardi- ja tehnoloogiainstituut (NIST) 1993. aasta detsembris.

IDEF0 põhielemendid ja kontseptsioonid

Graafiline keel IDEF0 on üllatavalt lihtne ja harmooniline. Metoodika põhineb neljal põhikontseptsioonil.

Esimene on tegevuskasti kontseptsioon. Funktsionaalne plokk on graafiliselt kujutatud ristküliku kujul (vt joonis 1) ja personifitseerib vaadeldava süsteemi raames mõne kindla funktsiooni. Vastavalt standardi nõuetele tuleb iga funktsionaalse ploki nimi sõnastada tegusõna meeleolus (näiteks „teenuste tootmine”, mitte „teenuste tootmine”).

Funktsionaalse ploki kõigil neljal küljel on oma spetsiifiline tähendus (roll), samas kui:

  • Ülemine külg on Control;
  • Vasak külg on seatud asendisse “Sisend”;
  • Parem pool on seatud valikule „Väljund”;
  • Alumine külg on "mehhanism".
  • Igal funktsionaalsel plokil ühe kaalutud süsteemi raames peab olema oma unikaalne identifitseerimisnumber.

    Joonis 1. Funktsionaalne plokk.

    IDEF0 metoodika teine ​​“vaal” on liidesekaare mõiste (nool). Samuti nimetatakse liidesekaareid sageli voogudeks või noolteks. Liidesekaar kuvab süsteemielemendi, mida töötleb funktsiooniplokk või mis muul viisil mõjutab selle funktsiooniploki kuvatavat funktsiooni.

    Liidesekaare graafiline kuvamine on ühesuunaline nool. Igal liidesekaarel peab olema oma unikaalne nimi (noole silt). Nagu standard nõuab, peab nimi olema nimisõna käive.

    Liidesekaarte abil kuvatakse erinevaid objekte, mis ühel või teisel määral määravad süsteemis toimuvad protsessid. Sellised objektid võivad olla reaalse maailma elemendid (osad, autod, töötajad jne) või andme- ja infovoogud (dokumendid, andmed, juhised jne).

    Sõltuvalt sellest, kummale poolele see liidesekaar sobib, nimetatakse seda “sissetulevaks”, “väljaminevaks” või “juhtimiseks”. Lisaks võivad iga funktsionaalse kaare „allikas” (algus) ja „valamu” (lõpp) olla ainult funktsionaalsed plokid, samas kui „allikas” võib olla ainult ploki väljundpool ja „valamu” võib olla ükskõik milline ülejäänud kolmest.

    Tuleb märkida, et mis tahes funktsionaalsel plokil peab vastavalt standardi nõuetele olema vähemalt üks juhtliidese kaar ja üks väljuv. See on arusaadav - iga protsess peab järgima mõningaid reegleid (kuvatakse kontrollkaarega) ja peab andma mingi tulemuse (väljaminev kaar), vastasel juhul pole mõtet seda kaaluda.

    IDEF0 diagrammide koostamisel on oluline sissetulevad liidesekaared õigesti juhtkaartest eraldada, mis pole sageli lihtne. Näiteks joonisel 2 on näidatud funktsiooniplokk “Töötle töödeldavat detaili”.

    Reaalses protsessis antakse töötlevale töötajale töödeldav detail ja tehnoloogilised juhised töötlemiseks (või ohutusreeglid masinaga töötamisel). Ekslikult võib tunduda, et nii toorik kui ka dokument koos tehnoloogiliste juhistega on sissetulevad objektid, kuid see pole nii. Tegelikult töödeldakse selles protsessis toorikut vastavalt tehnoloogilistes juhistes kajastatud reeglitele, mida peaks vastavalt juhtliidese kaar kuvama.


    Joonis 2.

    Teine asi on see, kui tehnoloogilisi juhiseid töötleb peatehnoloog ja neis tehakse muudatusi (joonis 3). Sellisel juhul kuvatakse need juba sissetuleva liidese kaarena ja juhtimisobjektiks on näiteks uued tööstusstandardid, mille alusel need muudatused tehakse.


    Joonis 3.

    Ülaltoodud näited rõhutavad sissetulevate ja väljaminevate liidesekaarte näiliselt sarnast olemust, kuid sama klassi süsteemide puhul on alati teatud erinevused. Näiteks ettevõtete ja organisatsioonide kaalumisel on viis peamist tüüpi objekte: materjalivood (osad, kaubad, toorained jne), rahavood (raha ja muu raha, investeeringud jne), dokument voogude (kaubandus-, finants- ja korraldusdokumendid), infovoogude (teave, kavatsuste andmed, suulised juhised jne) ja ressursside (töötajad, masinad, masinad jne). Sel juhul saab erinevatel juhtudel kuvada igat tüüpi objekte sissetulevate ja väljaminevate liidesekaarte abil, mis juhivad ainult neid, mis on seotud dokumentide ja teabevoogudega, ning ainult ressursse saab kuvada kaarmehhanismide abil.

    Juhtliidese kaaride kohustuslik olemasolu on IDEF0 standardi üks peamisi erinevusi teistest klasside DFD (Data Flow Diagram) ja WFD (Work Flow Diagram) metoodikatest.

    IDEF0 standardi kolmas põhimõiste on lagunemine. Lagunemisprintsiipi kasutatakse keerulise protsessi osadeks jaotamisel. Sellisel juhul määrab protsessi üksikasjalikkuse taseme otse mudeli arendaja.

    Lagunemine võimaldab teil järk -järgult ja struktureeritult kujutada süsteemimudelit üksikute diagrammide hierarhilise struktuurina, mis muudab selle vähem ülekoormatuks ja kergesti seeditavaks.

    IDEF0 mudel algab alati süsteemi kui terviku esitlemisega - üks funktsionaalne plokk, mille liidesekaared ulatuvad vaadeldavast piirkonnast kaugemale. Sellist ühe funktsionaalse plokiga skeemi nimetatakse kontekstiskeemiks ja seda tähistatakse identifikaatoriga “A-0”.

    Kontekstdiagrammi selgitav tekst peab näitama diagrammi koostamise eesmärki lühikirjelduse kujul ja fikseerima vaatepunkti (vaatepunkt).

    IDEF0 mudeli väljatöötamise eesmärgi kindlaksmääramine ja vormistamine on äärmiselt oluline punkt. Tegelikult määrab eesmärk kindlaks uuritava süsteemi asjakohased valdkonnad, millele tuleks kõigepealt keskenduda. Näiteks kui me modelleerime ettevõtte tegevust, et selle mudeli alusel tulevikus ehitada infosüsteem, siis see mudel erineb oluliselt mudelist, mille arendaksime sama ettevõtte jaoks, kuid eesmärgiga optimeerida tarneahelaid.

    Vaatenurk määratleb mudeli peamise arengusuuna ja nõutava detailsuse. Vaatepunkti selge fikseerimine võimaldab teil mudeli maha laadida, loobudes mittevajalike üksikute elementide üksikasjalikust kirjeldamisest ja uurimisest, lähtudes süsteemi valitud vaatenurgast. Näiteks sama ettevõtte funktsionaalsed mudelid peatehnoloogi ja finantsdirektori seisukohast erinevad üksteisest üksikasjalikult. See on tingitud asjaolust, et lõpuks pole finantsjuhti huvitatud tootmismasinate tooraine töötlemise aspektidest ja peatehnoloog ei vaja joonistatud skeeme. rahavood... Vaatenurga õige valik vähendab oluliselt lõpliku mudeli loomiseks kuluvat aega.

    Lagunemisprotsessis puuritakse funktsionaalne plokk, mis kontekstiskeemil kuvab süsteemi tervikuna, teisele skeemile. Saadud teise taseme diagramm sisaldab funktsionaalseid plokke, mis kuvavad kontekstidiagrammi funktsionaalse ploki peamisi alamfunktsioone ja mida selle suhtes nimetatakse alamdiagrammiks (iga alamdiagrammi kuuluvaid funktsionaalseid plokke nimetatakse vastavalt alamkastiks) ). Vanemfunktsiooniplokki nimetatakse omakorda alamdiagrammi suhtes vanemplokiks (Parent Box) ja diagrammi, kuhu see kuulub, nimetatakse vanemdiagrammiks (Parent Diagram). Iga alamdiagrammi alamfunktsiooni saab üksikasjalikumalt kirjeldada vastava funktsionaalse ploki sarnase lagundamisega. Oluline on märkida, et iga funktsionaalse ploki lagunemise korral on kõik sellesse plokki kuuluvad või sellest väljuvad liidesekaared fikseeritud alamdiagrammil. Sellega saavutatakse IDEF0 mudeli struktuurne terviklikkus. Lagunemise põhimõte on selgelt näidatud joonisel 4. Peaksite pöörama tähelepanu funktsionaalsete plokkide numeratsiooni ja diagrammide vahelisele seosele - igal plokil on diagrammil oma unikaalne seerianumber (number ristküliku paremas alanurgas) , ja tähis õige nurga all näitab selle ploki alamdiagrammi numbrit ... Selle tähise puudumine tähendab, et selle ploki puhul pole lagunemist.

    Sageli on juhtumeid, kus üksikute liidesekaartega ei ole mõtet jätkata alamdiagrammides arvestamist allapoole hierarhia teatud taset või vastupidi - üksikutel kaartel pole praktilist tähendust üle teatud taseme. Näiteks liidese kaar, mis kujutab „detaili” funktsiooniploki „Protsess sisse treipink”Kõrgemate tasandite diagrammide üle mõtiskleda pole mõtet - see koormab diagramme ainult üle ja raskendab nende mõistmist. Teisest küljest on vaja vabaneda eraldi „kontseptuaalsetest” liidesekaartest ja mitte neid üksikasjalikumalt määratleda. Selliste probleemide lahendamiseks näeb IDEF0 standard ette tunnelite kontseptsiooni. Noolitunneli tähis kahe sulgu kujul liidese kaare alguses tähistab, et see kaar ei päritud funktsionaalsest algplokist ja see ilmus ("tunnelist") ainult selles diagrammis. Sama tähis liidese kaare lõpus (nool) ümber vastuvõtjaploki vahetus läheduses tähendab asjaolu, et selle ploki alamdiagrammis seda kaare ei kuvata ja seda ei arvestata. Kõige sagedamini juhtub, et üksikuid objekte ja neile vastavaid liidesekaared ei võeta arvesse mõnel hierarhia vaheastmel - sel juhul “sukelduvad nad esmalt tunnelisse” ja seejärel vajadusel “tunnelist tagasi”.

    Viimane IDEF0 kontseptsioonidest on sõnastik. Iga IDEF0 elemendi puhul: diagrammid, funktsionaalsed plokid, liidesekaared eeldab olemasolev standard selle elemendi kuvatavat objekti iseloomustavate asjakohaste määratluste, märksõnade, narratiivide jms komplekti loomist ja hooldamist. Seda komplekti nimetatakse sõnastikuks ja see on selle elemendi olemuse kirjeldus. Näiteks juhtliidese kaare „maksekorraldus“ puhul võib sõnastik sisaldada kaarele vastavate dokumendi väljade loendit, nõutavat viisakomplekti jne. Sõnastik täiendab harmooniliselt graafilist keelt, pakkudes diagrammidele vajalikku lisateavet.


    Joonis 4. Funktsionaalsete plokkide lagunemine.

    IDEF0 diagrammide keerukuse piiramise põhimõtted

    Tavaliselt kannavad IDEF0 mudelid keerukat ja kontsentreeritud teavet ning nende ummikute piiramiseks ja loetavaks muutmiseks võetakse vastavas standardis vastu vastavad keerukuse piirid:

    Funktsionaalsete plokkide arvu piiramine diagrammil kuni kolm kuni kuus. Ülemine piir (kuus) sunnib disainerit kasutama keeruliste esemete kirjeldamisel hierarhiaid ja alumine piir (kolm) tagab, et vastaval diagrammil on selle loomise õigustamiseks piisavalt detaile;

    Ühele funktsionaalsele plokile sobivate liidesekaarte arvu piiramine (ühe funktsionaalse ploki jätmine) neljale.
    Loomulikult ei ole neid piiranguid rangelt vaja järgida, kuid nagu kogemus näitab, on need reaalses töös väga praktilised.

    Rühmatöö distsipliin IDEF0 mudeli väljatöötamisel

    IDEF0 standard sisaldab protseduuride komplekti, mis võimaldab suurel hulgal inimesi modelleeritud süsteemi erinevatest piirkondadest mudeli välja töötada ja selles kokku leppida. Tavaliselt on arendusprotsess korduv ja koosneb järgmistest tingimuslikest etappidest:

    Ettevõtte erinevate valdkondadega seotud spetsialistide rühma poolt mudeli loomine. Seda rühma nimetatakse IDEF0 poolest autoriteks. Esialgse mudeli loomine on dünaamiline protsess, mille käigus autorid küsivad pädevatelt inimestelt erinevate protsesside struktuuri. Olemasolevate sätete, dokumentide ja uuringutulemuste põhjal luuakse mudeli mustand (Model Draft).

    Eelnõu levitamine läbivaatamiseks, heakskiitmiseks ja kommentaarideks. Praeguses etapis arutatakse mudeli kavandi üle paljude pädevate isikutega (IDEF0 lugejate osas) ettevõttes. Sel juhul kritiseeritakse mustandi kõiki skeeme ja kommenteeritakse neid kirjalikult ning edastatakse seejärel autorile. Autor omakorda nõustub kriitikaga ka kirjalikult või lükkab selle tagasi, visandades otsuste tegemise loogika ja tagastab muudetud eelnõu edasiseks kaalumiseks. See tsükkel kestab seni, kuni autorid ja lugejad jõuavad üksmeelele.

    Mudeli kinnitamine. Heakskiidetud mudeli kinnitab töörühma juht juhuks, kui mudeli autoritel ja lugejatel pole selle adekvaatsuse osas erimeelsusi. Lõplik mudel on ettevõtte (süsteemi) järjekindel vaade antud vaatenurgast ja teatud eesmärgil.
    IDEF0 graafilise keele nähtavus muudab mudeli üsna loetavaks isikutele, kes selle loomise projektis ei osalenud, ning on tõhus ka näituste ja esitluste korraldamiseks. Tulevikus saab konstrueeritud mudeli alusel korraldada uusi projekte, mille eesmärk on teha muudatusi ettevõttes (süsteemis).

    IDEF0 abil funktsionaalse modelleerimise kasutamise riikliku praktika tunnused

    V viimased aastad huvi IDEF perekonna metoodikate vastu kasvab Venemaal pidevalt. Jälgin seda pidevalt, vaadates oma isiklikule veebilehele (http://www.vernikov.ru) tehtud kõnede statistikat, mis kirjeldab lühidalt nende standardite põhiprintsiipe. Samas nimetaksin huvi selliste standardite vastu nagu IDEF3-5 teoreetiliseks ja IDEF0 vastu üsna praktiliselt õigustatuks. Tegelikult ilmusid esimesed DFD ja IDEF0 diagramme koostada võimaldavad Case-tööriistad Venemaa turule juba 1996. aastal, samal ajal kui ilmus populaarne raamat modelleerimispõhimõtete kohta SADT standardites.

    Sellest hoolimata peab enamik juhte endiselt modelleerimise praktilist rakendamist IDEF -i standardites pigem moeavalduseks kui tõhusaks viisiks olemasoleva ärijuhtimissüsteemi optimeerimiseks. Suure tõenäosusega on selle põhjuseks teabe puudulik väljendus nende metoodikate praktilise rakendamise kohta ja valdava enamuse väljaannete vältimatu tarkvaraline eelarvamus.

    Pole saladus, et peaaegu kõik projektid uurimiseks ja analüüsimiseks finants- ja majanduslik tegevus Venemaal asuvad ettevõtted on ühel või teisel viisil ehitusega seotud automatiseeritud süsteemid juhtimine. Tänu sellele on IDEFi standardid enamuse arusaamades muutunud rakendamisest tinglikult lahutamatuks infotehnoloogiaid, kuigi nende abiga on mõnikord võimalik tõhusalt lahendada isegi väikeseid kohalikke probleeme, sõna otseses mõttes pliiatsi ja paberi abil.

    Ettevõtte keeruliste uuringuprojektide läbiviimisel võimaldab IDEF0 standardite mudelite väljatöötamine teil visuaalselt ja tõhusalt kuvada kogu ettevõtte tegevuse mehhanismi soovitud kontekstis. Kõige olulisem on aga koostöö, mida pakub IDEF0. Minu praktikas oli üsna palju juhtumeid, kui mudeli ehitamine viidi läbi erinevate osakondade töötajate otsese abiga. Samas selgitas konsultant neile üsna lühikese aja jooksul IDEF0 põhiprintsiipe ja õpetas töötama vastava rakendustarkvaraga. Selle tulemusena lõid erinevate osakondade töötajad oma funktsionaalse üksuse tegevuse IDEF -skeemid, mis pidid vastama järgmistele küsimustele:

    Mis läheb üksusele "sissepääsu juures"?

    Milliseid funktsioone ja millises järjekorras üksuses täidetakse?

    Kes vastutab iga funktsiooni eest?

    Millest juhib täitja iga funktsiooni täitmisel?

    Mis on üksuse töö tulemus (väljund)?

    Pärast iga konkreetse osakonna skeemide mustandite kokkuleppimist koondab konsultant need ettevõtte mudeli mustandiks, milles on kõik sisendi ja väljundi elemendid ühendatud. Selles etapis registreeritakse kõik üksikute diagrammide ja nende vastuoluliste kohtade lahknevused. Lisaks läbib see mudel uuesti funktsionaalsed osakonnad edasiseks koordineerimiseks ja vajalike kohanduste tegemiseks. Selle tulemusena saadakse üsna lühikese aja jooksul ja nõustamisfirma minimaalsete inimressursside kaasamisega (ja need ressursid, nagu teate, on väga kallid), saadakse ettevõtte IDEF0 mudel vastavalt „ Põhimõtteliselt ja mis veelgi tähtsam - see esindab ettevõtet, mille töötajad on selles ametis ja teavad põhjalikult kõiki nüansse, sealhulgas mitteametlikke. Tulevikus antakse see mudel analüüsimiseks ja töötlemiseks üle ärianalüütikutele, kes otsivad kitsaskohti ettevõtte juhtimises ja optimeerivad võtmeprotsesse, muutes mudeli "nagu on" vastavaks "nagu peaks". Nende muudatuste põhjal tehakse lõplik järeldus, mis sisaldab soovitusi juhtimissüsteemi ümberkorraldamiseks.

    Loomulikult nõuab selline lähenemine mitmeid organisatsioonilisi meetmeid, peamiselt küsitletud ettevõtte juhtkonna poolt. See on tingitud asjaolust, et see tehnika hõlmab mõne töötaja määramist lisakohustusi uute metoodikate väljatöötamise ja praktilise rakendamise kohta. Lõppkokkuvõttes tasub see aga end ära, sest üks või kaks täiendavat töötundi mitme päeva jooksul võivad oluliselt säästa raha kolmanda osapoole ettevõttele nõustamisteenuste eest tasumisel (mis igal juhul töö ära rebib) samade töötajate küsimustike ja küsimustega). Mis puudutab ettevõtte töötajaid endid, siis ühel või teisel viisil ei ole ma nende poolt väljendatud vastuseisu kohanud.

    Sellest kõigest saab järeldada järgmiselt: sugugi ei ole vaja iga kord standardprobleemidele lahendusi välja pakkuda. Alati, kui teil on vaja analüüsida konkreetset funktsionaalset süsteemi (kosmoselaevade projekteerimissüsteemist kuni keeruka õhtusöögi valmistamise protsessini), kasutage aastate jooksul katsetatud meetodeid. Üks neist meetoditest on IDEF0, mis võimaldab lahendada keerulisi eluprobleeme oma lihtsate ja arusaadavate tööriistade abil.

    Tänapäeval mitte ainult kitsastes ringides tuntud lühend IDEF0 on esimene metoodika äriprotsessidega seotud töö standardiseerimiseks. See töötati välja eelmise sajandi keskel Ameerika Ühendriikide lennundusprojekti raames ja olles näidanud oma tõhusust, on sellest saanud föderaalne standard. Meie riigis koostati 2000. aastal dokument " Funktsionaalse modelleerimise metoodika IDEF0. Juhenddokument Funktsionaalse modelleerimise metoodika IDEF0 juhenddokument. Ametlik väljaanne. Gosstandart Venemaa RD IDEF0 - 2000. Arendanud uurimiskeskus CALS - Technologies "Applied Logistics". Vastu võetud ja jõustatud Moskva Venemaa Gosstandart 2000 resolutsiooniga”, Kuid standardina ei kiidetud seda kunagi heaks. Kuigi see ei takistanud seda metoodikat muutumast üheks populaarsemaks tööriistaks äriprotsesside graafiliseks modelleerimiseks meie riigis. Selles artiklis kutsun teid üle vaatama IDEF0 mudelit ja hindama selle lähenemisviisi praegust asjakohasust.

    Põhimõisted ja lühendid

    Mõistame veidi metoodika põhielementide nimetusi. IDEF0 graafiline standard on osa SADT (Structured Analysis and Design Technique) metoodikast. IDEF on lühend lühendist ICAM Definition ja ICAM on tuletatud integreeritud arvutipõhisest tootmisest, mis tähendab tootmise integreeritud arvutistamist. SADT metoodika on terve 15 erinevast mudelist koosnev perekond, mis koos pidid võimaldama uurida tootmistehniliste ja organisatsioonimajanduslike süsteemide struktuuri, parameetreid ja omadusi.

    IDEF0 on funktsionaalne mudel, mis on kõigi teiste struktuuride tuum, see ühendab omavahel teabe- ja materjalivoogud, organisatsioonilise struktuuri, kontrollitoimingud ja ettevõtte tegevuse. Protsesside modelleerimise graafilist standardit nimetatakse ka märkimiseks. See tähendab, et märkimine on nõuete ja reeglite süsteem tegevusmudeli ühel või teisel kujul konstrueerimiseks. Seetõttu on asjakohane nimetada IDEF0 märkeks, mis on osa SADT metoodikast.

    IDEF0 märge on üsna range tehnika, mis algselt töötati välja nagu tehnilised disainistandardid käsitsi modelleerimiseks. Seetõttu sisaldab see nõudeid noolte paigutusele, kõigi elementide vormingule, IDEF0 diagrammi inforaami sisule jne. Kuna ettevõtte tegevus on keeruline mitmetasandiline toimingute süsteem, on skeeme alati palju, samuti on vaja üheselt süstematiseerida ja navigeerida mudeli kõigi elementide kaudu. Nüüd teevad seda peamiselt arvutisüsteemid, mis toetavad selles märgistuses modelleerimist. Venemaa territooriumil on tänapäeval kõige kuulsamad ja kättesaadavamad süsteemid AllFusion Process Modeler ja Business Studio. Kavatsen pühendada nende süsteemide ülevaatamisele eraldi artiklid.

    Funktsionaalne plokk

    IDEF0 mudeli keskseks elemendiks on funktsioon, mis kuvatakse diagrammil funktsionaalne plokk- ristkülik, mille sees on tegevus märgitud verbaalse nimisõna kujul. Tegevus võib olla mastaabis väga erinev - ettevõtte tegevusest üldiselt ja konkreetsete manipulatsioonideni. Näited: "Keraamiliste lauanõude tootmine ja müük" ja "Toonile joonistamine".

    Kohustuslikud funktsiooniploki elemendid IDEF0 -s

    Sõltumata toimingute skaalast kuvatakse kõik funktsioonid ühtlaselt ja sisaldavad tingimata 4 võtmevoogu, mis on jäigalt määratud funktsionaalse ploki külgedele:

    • vasakul - funktsiooni täitmiseks kasutatud sisendid või ressursid;
    • paremal - funktsiooni täitmise väljundid või tulemused;
    • peale selle - kontrollimeetmed, mis määravad, kuidas ja kui palju tulemusi tuleks anda;
    • allpool - mehhanismid, mis kajastavad, kes ja mille abil seda tööd tegema peaks.

    See lähenemisviis võimaldab teil diagrammidel selgituste pealt veidi kokku hoida ja saavutada voogude kuvamisel ühemõttelisust, mis muudab kogu mudeli saledaks.

    Funktsionaalse mudeli koostamiseks nõuab IDEF0 metoodika järgimist järgmiste reeglite järgi.

    1. Sisendid on ressursid, mis annavad oma väärtuse täielikult väljunditele üle, see tähendab, et need kulutatakse tulemuse loomiseks täielikult ja mehhanismid on ressursid, mis kannavad oma väärtust üle vaid osaliselt (seadmed amortisatsiooni kaudu ja inimesed palga kaudu).
    2. Juhtimine on mudeli vajalik element, kuna see seob kõik toimingud ettevõtte eeskirjade süsteemiga, näidates selgelt, milliseid reegleid ja nõudeid tuleb funktsiooni täitmisel järgida. Sageli käsitletakse seda voogu formaalselt, kuid skeem kaotab oma ranguse ja mõnikord isegi tähenduse.
    3. Iga funktsionaalse ploki mõlemal küljel peab olema vähemalt üks nool (kuna ilma ressursside ja tulemusteta ei saa tööd teha ning ilma täitja või juhiseta käsk on puudulik).

    Kaalutud skeem on IDEF0 lähenemisviisi „ehitusplokk”. Funktsionaalne modelleerimine hõlmab järkjärgulist üleminekut üldiselt konkreetsele lagunemise kaudu. Lagunemine on „süvenemine“ vaadeldavasse funktsiooni, jagades selle väiksemateks funktsioonideks. Pealegi, kui tipptasemel funktsioon esitatakse üldistatult ja pärast selle lagundamist, on asjakohane seda nimetada protsessiks.

    Kontekstdiagramm

    Kõige kõrgemal tasemel esitatakse ettevõtet kui "musta kasti", milles toimub teatud tegevus, mis tähendab sissepääsude väljapääsu. Seda taset nimetatakse tavaliselt "", see tähendab diagrammi, mis kirjeldab ettevõtte tegevuse konteksti. Lisaks näitab kontekstidiagramm kogu mudeli põhiomadusi.

    1. Eesmärk on mudeli eesmärgi konkreetne sõnastus, mille abil saab tulevikus kontrollida mudeli konstruktsiooni täpsust.
    2. Vaatenurk - kelle näole mudel on ehitatud, kuna mudel sõltub alati selle autorist ja tähelepanu keskpunktist. Kui me ehitame ettevõtte üldmudeli, siis seda esitatakse tavaliselt selle direktori seisukohast.
    3. Mudeli tüüp näitab, millist teavet diagrammidel kuvatakse. Siin võib olla kaks peamist võimalust: NAGU ("nagu on") või OLLA ("nagu saab"). See eraldamine on vajalik, kuna saame luua mudeleid nii tegevuste analüüsimiseks kui ka nende muutmiseks. Peame olema selgelt teadlikud oma tegemistest ja edastama seda teavet ka teistele.

    Seega sisaldab kontekstidiagramm kõige üldisemal kujul ettevõtte tegevuse kirjeldust, mida läbivad voogud, mis ühendavad ettevõtet välismaailmaga. Arvan, et peaksime neil ka üksikasjalikumalt peatuma.

    Peamised voolud

    Kogemused on näidanud, et vaatamata selle taseme näilisele lihtsusele ja formaalsusele on sageli vaja sellel pikalt peatuda, kuna kõik tulemused, mis on omaniku ja turu jaoks olulised, peavad siin kajastuma. Viga võib viia mudelite loomiseni, mis ei täida ettevõttele seatud ülesandeid. Oluliste voogude kajastamise kontrollimiseks veenduge, et kõik neli peamist voolutüüpi oleksid teie diagrammil olemas.

    1. Materjal: materjalid ja komponendid sissepääsu juures ja valmistooted väljapääsu juures.
    2. Klient: potentsiaalne klient sissepääsu juures ja rahulolev klient väljapääsu juures.
    3. Finants: sissepääsu juures on need tavaliselt investeeringud, klientide maksed (tulud), laenud ja muud tulud; väljund on maksed tarnijatele, maksud, laenumaksed ja kasum.
    4. Informatiivne: sisendina on need kõik väliskeskkonna (turutingimused, konkurentide käitumine, tehnoloogiline innovatsioon jne) ja väljundiks on teabevoog, mida ettevõte enda kohta maailmale edastab (kogu reklaamiteave, samuti igat liiki aruandlus reguleerivatele asutustele).

    Pange tähele, et ettevõte on avatud süsteem ja selles ei ilmu ega kao midagi. Ettevõte suudab sissetulevad voogud muuta ainult väljaminevateks voogudeks ja kui see teeb seda hästi, siis täiendavat rahavool(kasum), mis peegeldab teatud mõttes kogu süsteemi kvaliteeti.

    (suurendamiseks klõpsake)

    On hea, kui tõstate esile kõik seda tüüpi voogud oma värviga, et saaksite hõlpsasti eristada ressursside liikumist ja mitte vahele jääda olulised punktid... Näiteks on sageli võimalik jälgida kliendi puudumist ettevõtte voogudes, seetõttu põhineb temaga töötamine ülejäägi põhimõttel - klient tunneb end sageli takistuseks ettevõtte töötajatele, kelle ülesanded on keskendunud dokumentide voog.

    Juhtnooli saab tähistada ainult 1 liiki vooga - infovoog, mille saab jagada 2 alamliigiks. Esimene neist on sellised dokumendid nagu:

    • seadused ja määrused;
    • tellimused, tellimused;
    • juhised ja määrused;
    • plaanid;
    • projekteerimisdokumentatsioon jne.

    Teine on dokumenteerimata teave, mis sisaldab kõige sagedamini omanike nõudeid.

    Ja lõpuks, mehhanismid - vooge on ainult kahte tüüpi: seadmed (materjal) ja esinejad (osakonnad ja inimesed). Siin ei saa olla dokumente, nagu ka inimesi kontrollpunktides!

    Mudel pakub navigeerimiseks pidevat nummerdamist. Kontekstdiagramm on nummerdatud "A-0". Tulevikus saab iga funktsionaalne plokk oma numbri, olenemata sellest, kui sügav on lagunemine.

    Lagunemine

    Pärast kontekstiskeemi voogude väljatöötamist võime jätkata lagunemist. Liikudes allapoole, justkui "musta kasti" avades, näeme kõigepealt tühja lehte nooltega, mis on funktsionaalse ploki külge kinnitatud.

    (suurendamiseks klõpsake)

    Ja siit algab tegelik funktsionaalne modelleerimine - peame mõistma, milline toimingute kogum neid voogusid ühendab ja tagama kõigi nõuete täitmise. Raskus seisneb selles, et ettevõttes on palju toiminguid ja skeemil on meil õigus kuvada mitte rohkem kui 9 funktsiooni, vastasel juhul muutub diagramm loetamatuks ja seega kasutuks.

    Alati pole lihtne korraldada keerulisi tegevusi nii, et need jääksid visuaalseks, loetavaks ja samal ajal terviklikuks. Kõige sagedamini jagavad nad mitmesuguseid protsesse suurteks suurteks plokkideks, millest kõige olulisemad on järgmised.

    1. Toote loomine (tulemus).
    2. Edendamine ja müük - töötades koos kliendivooga.
    3. Toetus toodete loomisel on teisejärgulised protsessid, mis on vajalikud valitsuse nõuete täitmiseks või töö mugavuse tagamiseks (personal ja raamatupidamine, transporditeenused, ruumide koristamine jne).
    4. Juhtimisvoogude loomine - juhtimislahenduste väljatöötamise tegevus, mis määrab kindlaks nõuded ettevõtte kõikidele protsessidele.

    Alloleval joonisel on näidatud meie näite lagunemisskeem.

    (suurendamiseks klõpsake)

    Diagrammil tuleks protsessid paigutada diagonaalselt - seda nimetatakse domineerimise põhimõte, mis tähendab funktsionaalsete plokkide paigutamist vasakult paremale ja ülevalt alla - tähtsuse järjekorras või kronoloogilises järjekorras. Plokkide numeratsioon on sama.

    Edasine töö mudeli kallal on sarnane esimese sammuga - iga esimese taseme funktsionaalne plokk lagundatakse. Plokkide numeratsioon sisaldab esimese taseme numbrit: A1.1… A1n, A2.1… A2.n jne.

    Järeldused märke asjakohasuse kohta

    Selle artikli raames oli võimalik kuvada ainult IDEF0-märkimise põhimõisteid, kasutades IDEF0 lühinäidet, mille järgi on muidugi raske hinnata metoodikat tervikuna. Kuid üsna palju kogemusi selle märke praktikas kasutamisel võimaldab mul teha järgmised järeldused.

    1. Mudelil on hea visualiseerimispotentsiaal, kuid minu arvates on selle suurem tähtsus distsiplineeriv mõju. Metoodikasse kaasatud reeglid ja piirangud sunnivad meid kujundama mudelitesse süstemaatilist ja ranget suhtumist, mis mõjutab lõpptulemuse kvaliteeti väga hästi.
    2. Mudel võimaldab teil luua suhtlusvooge näiliselt mitte tugevalt seotud asjade vahel: ühendada esi- ja tagakontori allsüsteemid juhtimisega, mis on teiste märgete puhul palju hullem.
    3. Lähenemisviis on lihtne ja arusaadav enamiku projektis osalejate jaoks. Selle märke skeemide koostamist ja lugemist piirab ainult soov süveneda ärivoogude keerukustesse.

    Mõned ülaltoodud argumendid panevad arvama, et see lähenemine on tegevuste täielikuks modelleerimiseks parim ja ainus. Kuid ärge unustage, et funktsionaalne mudel on mõeldud ainult modelleerimise ülemisele tasemele. Märgise IDEF0 kasutamine esinejate tasemel töö kavandamisel toob kaasa asjaolu, et skeemid on puhtalt illustratiivsed ja nende põhjal on võimatu luua mõistlikku regulatsiooni, kuna need ei sisalda:

    • protsessi käivitamise ja peatamise sündmuste konkretiseerimine;
    • ühelt meetmelt teisele ülemineku tingimused;
    • võimalus visuaalselt kuvada kõiki ressursse ja esinejaid ilma diagrammi nooltega üle koormamata.

    Seega, kui kasutate seda märget ülesannete jaoks, mille jaoks see on ette nähtud (tipptasemel tegevuste struktureerimine), siis on IDEF0 praktiliselt ainus tänane märge, mis võimaldab teil seda sisukalt ja täpselt teha.

    V projekti juht see modelleerimisstandard on kõige sobivam seal, kus peate erinevaid projekte või protsesse visuaalsete voogudega siduma. Samal ajal võimaldab graafiline mudel vastutust ja ressursse ratsionaalsemalt jaotada ülesannete kaupa. Diagrammidel kajastatud projekti ülesannete loogika aitab valmistada paremat kvaliteeti kalendriplaan Gantti diagrammi kujul.

    6.2. SADT metoodika eesmärk ja koostis (IDEF0)

    SADT metoodika (Structured Analysis and Design Technique - struktuurianalüüsi ja projekteerimise metoodika) on meetodite, reeglite ja protseduuride kogum, mis on loodud süsteemi funktsionaalse mudeli loomiseks.

    Selle metoodika väljatöötamise algatas Douglas Ross (USA) 60ndate keskel. XX sajand. Sellest ajast alates on süsteemianalüütikud ettevõttest SofTech, Inc. täiustas SADT -i ja kasutas seda paljude probleemide lahendamiseks. Telefonivõrgu tarkvara, diagnostika, pikaajaline ja strateegiline planeerimine, automatiseeritud tootmine ning projekteerimine, arvutisüsteemi konfigureerimine, personali koolitamine, finants- ja hankejuhtimine on mõned valdkonnad, kus SADTi saab tõhusalt kasutada. Lai valdkondade valik näitab SADT metoodika mitmekülgsust ja võimsust. Programmis "Arvuti ja tööstuslikud tehnoloogiad SADT on tunnistanud kasulikuks USA kaitseministeeriumi integreeritud arvutipõhise tootmise (ICAM). See tõi kaasa selle osa avaldamise 1981. aastal nimega IDEF0 (Icam DEFinition), nagu föderaalne standard arendama tarkvara... Selle nime all on SADTi kasutanud tuhanded sõjaväe- ja tööstusorganisatsioonide spetsialistid. IDEF0 standardi viimane versioon ilmus 1993. aasta detsembris. Riiklik standardi- ja tehnoloogiainstituut (NIST).

    See metoodika konkureerib infosüsteemi funktsionaalse aspekti kirjeldamisel andmevoole orienteeritud (DFD) meetoditega. Seevastu IDEF0 võimaldab:

    Kirjeldage mis tahes süsteeme, mitte ainult infosüsteeme (DFD on mõeldud tarkvara kirjeldamiseks);

    Enne selle lõplike nõuete määratlemist looge süsteemi ja selle väliskeskkonna kirjeldus. Teisisõnu, selle metoodika abil saab süsteemi järk -järgult üles ehitada ja analüüsida isegi siis, kui selle rakendamist on veel raske ette kujutada.

    Seega saab IDEF0 -d rakendada paljude süsteemide ehitamise algusjärgus. Samal ajal saab seda kasutada funktsioonide analüüsimiseks olemasolevaid süsteeme ja arendada lahendusi nende parandamiseks.

    IDEF0 metoodika aluseks on graafiline keel protsesside kirjeldamiseks. IDEF0 märkimismudel on hierarhiliselt järjestatud ja omavahel ühendatud diagrammide kogum. Iga diagramm on süsteemi kirjelduse ühik ja see asub eraldi lehel.

    Mudel (NAGU, TO-BE või PEAB-olema) võib sisaldada 4 tüüpi graafikuid [ , ]:

    Kontekstdiagramm;

    Lagunemisskeemid;

    Sõlmepuude diagrammid;

    Ainult ekspositsiooni diagrammid (FEO).

    Kontekstdiagramm (tipptasemel diagramm), olles diagrammide puustruktuuri tipp, näitab süsteemi eesmärki (põhifunktsioon) ja selle koostoimet väliskeskkonnaga. Igal mudelil võib olla ainult üks kontekstidiagramm. Pärast põhifunktsiooni kirjeldust viiakse läbi funktsionaalne lagunemine, st määratakse kindlaks funktsioonid, millest põhifunktsioon koosneb.

    Lisaks on funktsioonid jagatud alamfunktsioonideks ja nii edasi, kuni uuritava süsteemi nõutav detailsus on saavutatud. Diagramme, mis kirjeldavad iga sellist süsteemi fragmenti, nimetatakse lagunemisskeemid ... Pärast igat lagunemissessiooni toimuvad eksamisessioonid - valdkonnaeksperdid näitavad reaalsete protsesside vastavust loodud skeemidele. Leitud ebakõlad kõrvaldatakse, seejärel jätkatakse protsesside üksikasjalikumat kirjeldamist.

    Sõlmepuu skeem näitab funktsioonide (teoste) hierarhilist sõltuvust, kuid mitte nendevahelist suhet. Neid võib olla mitu, kuna puu saab ehitada suvalisele sügavusele ja suvalisest sõlmest.

    Kokkupuute graafikud on loodud mudeli üksikute fragmentide illustreerimiseks, et kuvada süsteemis toimuvate protsesside alternatiivne vaatenurk (näiteks organisatsiooni juhtimise seisukohast).

    6.3. Graafilise märke IDEF0 elemendid

    IDEF0 metoodika on leidnud laialdast heakskiitu ja rakendust, peamiselt mudeli koostamisel kasutatud lihtsa graafilise tähise tõttu. Mudeli põhikomponendid on diagrammid. Need näitavad noole abil süsteemi funktsioone ristkülikute kujul, samuti nende ja väliskeskkonna vahelisi seoseid. Ainult kahe graafilise primitiivi (ristkülik ja nool) kasutamine võimaldab teil kiiresti selgitada IDEF0 diagrammide koostamise reegleid ja põhimõtteid inimestele, kes pole selle metoodikaga kursis. See eelis võimaldab ühendada ja aktiveerida kliendi tegevuse äriprotsesside kirjeldamisel, kasutades ametlikku ja visuaalset graafilist keelt.

    Järgmine joonis näitab IDEF0 graafilise märke põhielemente.

    Riis. 6.1. Graafilise märke IDEF0 elemendid

    Ristkülik tähistab töö (protsess, tegevus, funktsioon või ülesanne) , millel on kindel eesmärk ja mis viib mõne lõpptulemuseni. Töö nimi peab väljendama toimingut (näiteks "Osa valmistamine", "Lubatud kiiruste arvutamine", "Tsentraliseeritud maja number 3 nimekirja moodustamine").

    Teoste koostoimet nende ja välismaailma vahel kirjeldatakse noolte kujul. IDEF0 eristab 5 tüüpi nooli :

    - sissepääs (Ingliskeelne sisend) - materjal või teave, mida töö tulemuse (väljundi) saamiseks kasutab ja muudab. Sisselogimine vastab küsimusele "Mida töödelda?" Sisend võib olla kas materiaalne objekt (tooraine, osa, eksamipilet) või see, millel pole selgeid füüsilisi kontuure (päring andmebaasi, õpetaja küsimus). Eeldatakse, et teosel ei pruugi olla ühtegi sisenemisnoolt. Sisestusnooled joonistatakse alati töö vasakule poole sisenevana;

    - kontroll (Inglise keelne kontroll) - kontrolli, regulatiivseid ja regulatiivseid andmeid, mis juhivad tööd. Osakond vastab küsimusele "Kooskõlas sellega, mida tööd tehakse?" Juhtimine mõjutab tööd, kuid ei muutu sellega, s.t. toimib piiranguna. Juhtkonnana võivad olla reeglid, standardid, eeskirjad, hinnad, suulised juhised. Juhtnooled joonistatakse töö ülemise osa osana. Kui diagrammi koostamisel tekib küsimus, kuidas õigesti noolt ülalt või vasakult joonistada, siis on soovitatav see joonistada sisendina (nool vasakul);

    - väljund (Ingliskeelne väljund) - materjal või teave, mis esindab töö tulemust. Väljund vastab küsimusele "Mis on töö tulemus?" Väljundiks võib olla kas materiaalne objekt (osa, auto, maksedokumendid, väljavõte) või immateriaalne (andmeproovide võtmine andmebaasist, vastus küsimusele, suuline märge). Väljapääsu nooled tõmmatakse töö paremalt küljelt välja;

    - mehhanism (ing. mehhanism) - ressursid, mis teostavad tööd. Mehhanism vastab küsimusele "Kes teeb tööd või milliste vahenditega?" Mehhanismiks võivad olla ettevõtte töötajad, õpilane, masin, seadmed, programm. Mehhanismi nooled on joonistatud töö alumisse serva sisenemisel;

    - helistama (Ingliskeelne kõne) - nool näitab, et osa töid tehakse väljaspool kõnealust plokki. Väljapääsu nooled tõmmatakse töö alumisest servast välja.

    6.4. Töökohtade vaheliste seoste tüübid

    Pärast funktsioonide koosseisu ja nendevaheliste suhete määramist tekib küsimus nende õige koostise (assotsiatsiooni) kohta mooduliteks (alamsüsteemideks). See tähendab, et iga eraldi funktsioon peab rangelt lahendama ühe konkreetne ülesanne... Vastasel juhul on vaja funktsioone veelgi lagundada või lahutada.

    Funktsioonide liitmisel allsüsteemidesse tuleb püüelda selle poole, et sisemine ühenduvus (mooduli funktsioonide vahel) oleks võimalikult tugev ja väline (erinevatesse moodulitesse kuuluvate funktsioonide vahel) võimalikult nõrk. Metoodika linkide semantikale tuginedes tutvustame funktsioonide (teoste) vaheliste seoste klassifikatsiooni. See klassifikatsioon on laiendus. Võlakirjade tüübid on loetletud tähtsuse vähenemise järjekorras (siduvus). Viidatud näidetes rõhutavad paksendatud jooned funktsioone, mille vahel on kaalutud ühenduse tüüp.

    1. Hierarhiline suhe (suhe "osa" - "tervik") toimub funktsiooni ja selle alamfunktsioonide vahel, millest see koosneb.

    Riis. 6.2. Hierarhiline suhe

    2. Reguleeriv (kontroll, alluv) suhtlus peegeldab ühe funktsiooni sõltuvust teisest, kui ühe töö väljund saadetakse teise juhtimiseks. Funktsiooni, millest kontroll lahkub, tuleks pidada regulatiivseks või kontrollivaks ning millesse see siseneb - alluv. Eristama otsene juhtimise link kui juhtimine viiakse üle kõrgema taseme töölt madalamale (joonis 6.3) ja juhtkonna tagasiside kui juhtimine kantakse allavoolult ülesvoolu (joonis 6.4).

    3. Funktsionaalne (tehnoloogiline) kommunikatsioon tekib siis, kui ühe funktsiooni väljund toimib järgmise funktsiooni sisendina. Materiaalsete objektide voo seisukohast näitab see seos nende objektide töötlemise tehnoloogiat (tööde järjestust). Eristama otseühendus sissepääsu juures kui väljund viiakse üle kõrgema taseme tööst madalama tasemega (joonis 6.5) ja sisend tagasiside kui väljund kantakse allavoolust ülesvoolu (joonis 6.6).



    Riis. 6.5. Otseühendus sissepääsu juures Riis. 6.6. Sisendite tagasiside

    4. Tarbija suhtlemine tekib siis, kui ühe funktsiooni väljund toimib järgmise funktsiooni mehhanismina. Seega kulutab üks funktsioon teise loodud ressursse.

    Riis. 6.7. Tarbija suhtlemine

    5. Loogiline link loogiliselt homogeensete funktsioonide vahel. Sellised funktsioonid täidavad reeglina sama tööd, kuid erineval (alternatiivsel) viisil või kasutades erinevaid lähteandmeid (materjale).

    Riis. 6.8. Loogiline link

    6. Kollegiaalne (metoodiline) suhtlus toimub funktsioonide vahel, mille tööalgoritmi määrab sama juhtelement. Sellise suhtluse analoog on ühe osakonna töötajate (kolleegide) ühine töö, alluv ülemusele, kes annab juhiseid ja korraldusi (kontrollsignaale). Selline seos tekib ka siis, kui nende funktsioonide toimimise algoritmid määrab sama metoodiline tugi (SNIP, GOST, ametlikud regulatiivmaterjalid jne), mis toimib kontrollina.

    Riis. 6.9. Metoodiline ühendus

    7. Ressursside ühendus esineb funktsioonide vahel, mis kasutavad oma tööks samu ressursse. Ressurssõltuvaid funktsioone ei saa tavaliselt samaaegselt käitada.

    Riis. 6.10. Allika link

    8. Infokommunikatsioon toimub funktsioonide vahel, mis kasutavad sisendina sama teavet.

    Riis. 6.11. Infokommunikatsioon

    9. Ajutine ühendus esineb funktsioonide vahel, mida tuleb täita samaaegselt enne või samaaegselt pärast mõnda muud funktsiooni.

    Lisaks joonisel näidatud juhtumitele toimub see ühendus ka teiste juhtimis-, sisend- ja mehhanismikombinatsioonide vahel, mis sisenevad ühte funktsiooni.

    Riis. 6.12. Ajutine ühendus

    10. Juhuslik ühendus tekib siis, kui funktsioonide vahel on vähe või üldse mitte mingit seost.

    Riis. 6.13. Juhuslik ühendus

    Ülaltoodud linkide tüüpidest on tugevaim hierarhiline link, mis tegelikult määrab funktsioonide kombineerimise mooduliteks (alamsüsteemideks). Regulatiivsed, funktsionaalsed ja tarbijate sidemed on mõnevõrra nõrgemad. Nende linkidega funktsioone rakendatakse tavaliselt ühes alamsüsteemis. Loogilised, kollegiaalsed, ressursside ja informatsiooni seosed on nõrgemate hulgas. Funktsioone, millel neid on, rakendatakse reeglina erinevates alamsüsteemides, välja arvatud loogiliselt homogeensed funktsioonid (funktsioonid, mis on ühendatud loogilise ühendusega). Ajutine ühendus näitab funktsioonide nõrka sõltuvust üksteisest ja nõuab nende rakendamist eraldi moodulites.

    Seega on funktsioonide mooduliteks kombineerimisel kõige soovitavamad viis esimest tüüpi linke. Viimase viie lingiga seotud funktsioone on kõige parem rakendada eraldi moodulites.

    IDEF0 -l on kokkulepped (reeglid ja juhised) diagrammide loomiseks, et hõlbustada mudeli [,] lugemist ja uurimist. Mõnda neist reeglitest käsitlevad CASE tööriistad automaatselt, samas kui teisi tuleb jõustada käsitsi.

    1. Enne mudeli ehitamist on vaja otsustada, milline süsteemi mudel (id) ehitatakse. See tähendab selle tüübi määratlemist AS-IS, TO-BE või PEAB-BE, samuti positsiooni määratlemist selle seisukohast, millest mudel on üles ehitatud. "Vaatenurgast" võib kõige paremini mõelda kui inimese või objekti kohast (positsioonist), milles peab seisma, et näha süsteemi toimimas. Näiteks toidupoe käitamise mudeli ehitamisel saate valida võimalike taotlejate hulgast müüja, kassapidaja, raamatupidaja või direktori, kelle seisukohast süsteemi kaalutakse. Tavaliselt valitakse üks vaatenurk, mis katab kõige paremini süsteemi toimimise kõik nüansid, ja vajadusel koostatakse mõne lagunemisskeemi jaoks FEO diagrammid, mis kuvavad alternatiivse vaatenurga.

    2. Kontekstdiagramm näitab ühte plokki, mis näitab süsteemi eesmärki. Soovitatav on kuvada 2–4 ​​noolt, mis lähevad sisse ja välja mõlemalt poolt.

    3. Lahustamisskeemidel on plokkide arv soovitatav vahemikus 3–6. Kui lagunemisskeemil on kaks plokki, siis tavaliselt pole sellel mõtet. Suure hulga plokkide korral muutub diagramm üleküllastatuks ja seda on raske lugeda.

    4. Lahustamisskeemi plokid tuleks paigutada vasakult paremale ja ülevalt alla. See paigutus võimaldab teil töö loogikat ja järjestust selgemalt kajastada. Lisaks on noolega marsruudid vähem segadusseajavad ja neil on minimaalne ristmike arv.

    5. Funktsiooni jaoks ei ole lubatud nii juht- kui ka sisestusnoolte puudumine. See tähendab, et selle funktsiooni käivitamist ei kontrollita ja see võib toimuda suvalisel ajahetkel või üldse mitte.

    Riis. 6.14. Funktsioon ilma juhtimiseta ja sisendita

    Ainult juhtimisega plokki saab vaadelda kui funktsiooni (protseduuri) programmi parameetriteta kõnet. Kui plokil on sisend, on see samaväärne programmi parameetritega funktsiooni kutsumisega. Seega on ilma juhtimiseta ja sisendita plokk samaväärne funktsiooniga, mida programmis kunagi täitmiseks ei kutsuta.

    Joonisel fig. 6.7–6.12, näidates IDEF0 diagrammide fragmente, on plokid ilma sisendi ja juhtimiseta. Seda ei tohiks käsitada veana, kuna see tähendab, et üks neist nooltest peab olema.

    6. Igas plokis peab olema vähemalt üks väljalaskeava.

    Riis. 6.15. Väljumisfunktsioon puudub

    Tulemusteta tööd on mõttetud ja neid ei tohiks modelleerida. Erandiks on AS-IS mudelis kuvatud töö. Nende olemasolu näitab tehnoloogiliste protsesside ebaefektiivsust ja ebatäiuslikkust. TO-BE mudelis peaksid need tööd puuduma.

    7. Diagrammide koostamisel peaksite minimeerima ristmike, silmuste ja noolte pöörete arvu.

    8. Tagasisidet ja iteratsioone (tsüklilisi toiminguid) saab kujutada tagurpidi kaare abil. Tagasisidet sisendile tõmbab "alumine" silmus, juhtnuppu - "ülemine" (vt joonised 6.4 ja 6.6).

    9. Diagrammide igal plokil ja igal noolel peab olema nimi. Lubatud on kasutada hargnevaid (lagunemise) või ühendavaid (kompositsiooni) nooli. See on tingitud asjaolust, et ühe tööga genereeritud samu andmeid või objekte saab korraga kasutada ka mitmes teises töös. Ja vastupidi, ühesuguseid või homogeenseid andmeid ja erinevate tööde abil loodud objekte saab kasutada ühes kohas.

    Riis. 6.16. Hargnevad nooled

    Sellisel juhul on pärast hargnemist (enne ühendamist) lubatud noole erinevatele harudele määrata kvalifitseerivad nimed. Kui mõnda haru järel asuvat haru ei nimetata, loetakse selle nimi vastavaks enne filiaali registreeritud noole nimele.

    Niisiis, joonisel fig. 6.16 plokkides "Osade tootmine" ja "Toote kokkupanek" sisalduvatel juhtelementidel on selgitav tähendus ja need on osa rohkem üldjuhtimine"Joonised". Kõiki jooniseid kasutatakse ploki "Kvaliteedikontroll" toimimiseks.

    Diagrammil ei ole lubatud joonistada nooli, kui neid ei nimetata enne ja pärast hargnemist. Joonisel fig. 6.17 plokis "Tavaliste loendite genereerimine" sisalduval noolel pole nime enne ja pärast hargnemist, mis on viga.

    Riis. 6.17. Noolte vale nimetamine

    10. Diagrammide koostamisel parema loetavuse huvides võib kasutada noolega tunnelite mehhanismi. Näiteks selleks, et mitte segada ülemiste tasandite (vanem) diagramme mittevajalike detailidega, paigutatakse kaare algus tunnelisse lagunemisskeemides.

    Riis. 6.18. Tunneli nooled

    V see näide dirigeerimismudeli koostamisel Uusaasta pidu mehhanismi "kaks telge" ei kuvata ülemiste tasandite skeemidel, lugedes võib tekkida õiglane küsimus: "Miks on uusaastapeol vaja kahte telge?"

    Samuti saate tunnelida vastupidise eesmärgiga - mitte lubada noole ilmumist madalama taseme diagrammidele. Sel juhul pannakse sulg noole lõppu. Kontekstdiagrammil (vt joonis 6.21) tunnelitakse mehhanism "Path Service Engineer", mis sisaldub plokis "Lubatud kiiruste määramine". See otsus tehti, kuna insener on otseselt seotud kogu tööga, mis on näidatud selle ploki lagunemisskeemil (vt joonis 6.22). Et seda seost mitte näidata ja mitte lagunemisdiagrammi segi ajada, nool tunneliti.

    11. Sellele lagunemisskeemi koostamisel tuleks kuvada kõik plokki sisenevad ja sealt lahkuvad nooled. Erandiks on tunnelitud nooled. Lagunemisskeemile tõmmatud noolte nimed peavad ühtima ülatasandil näidatud nimedega.

    12. Kui kaks noolt kulgevad paralleelselt (algavad ühe töö samast aspektist ja lõpevad teise töö sama tahuga), siis tuleks need võimaluse korral kombineerida ja nimetada üheks terminiks.

    Riis. 6.19. Lingide ühendamine

    13. Diagrammide igal plokil peab olema oma number. Diagrammide numbreid kasutatakse mis tahes diagrammi või ploki positsiooni tähistamiseks hierarhias. Ülemise taseme diagrammi plokki tähistatakse 0 -ga, teise taseme diagrammide plokke - numbritega 1 kuni 9 (1, 2, ..., 9), kolmanda taseme plokke - kahe numbriga , millest esimene näitab lähteskeemi üksikasjaliku ploki numbrit ja teine ​​ploki number järjekorras praegusel skeemil (11, 12, 25, 63) jne. Kontekstdiagrammil on tähis "A - 0 ", esimese astme lagunemisskeem on" A0 ", järgmiste tasandite lagunemisskeemid koosnevad tähest" A ", millele järgneb lagundatava ploki number (näiteks" A11 "," A12 "," A25 " "," A63 "). Joonisel on kujutatud tüüpiline diagrammipuu (sõlmepuu diagramm) koos numeratsiooniga.

    Riis. 6.20. Graafikute hierarhia

    Kaasaegsetes CASE-tööriistades toetatakse tööde nummerdamismehhanisme automaatselt. CASE tööriistad pakuvad ka sõlmpuude diagrammide automaatset koostamist, mis sisaldavad ainult hierarhilisi linke. Sellise diagrammi ülaosa võib olla mis tahes sõlm (plokk) ja selle saab joonistada mis tahes sügavusele.

    6.6. Näide IDEF0 mudeli koostamisest lubatud kiiruste määramise süsteemi jaoks

    Lubatud rongikiiruste arvutamine on töömahukas inseneritöö. Kui rong läbib mis tahes lõigu tegelik kiirus rongi liikumine ei tohiks ületada suurimat lubatud piiri. See suurim lubatud kiirus määratakse kasutuskogemuse ja spetsiaalselt läbi viidud liikumiste dünaamika ja veeremi rööbasteele tehtavate katsete põhjal. Selle kiiruse ületamine tagab rongiliikluse ohutuse, reisijatele mugavad tingimused jne. Need määratakse sõltuvalt veeremi tüübist (veduri mark ja vagunitüüp), pealisehitise parameetritest (näiteks rööpad, liiteseadis, liiprid) ) ja plaan (raadiuse kõverad, üleminekukõverad, välise rööpa tõus jne). Lubatud kiiruste kindlaksmääramiseks on reeglina vaja määrata vähemalt kaks (sirgjoonel) ja viis (kurvides) kiirust, mille hulgast valitakse lõplik lubatud kiirus, mis on arvutatud madalaim. Nende kiiruste arvutamist reguleerib Venemaa Raudteeministeeriumi 12. novembri 2001. aasta korraldus nr 41 "Föderaalse raudteetranspordi 1520 (1524) mm rööpmelaiusega raudtee raudteeveeremi lubatud kiiruste standardid".

    Nagu märgitud, algab IDEF0 mudeli loomine kogu süsteemi kujutamisega lihtsa komponendina (kontekstiskeem). See diagramm näitab süsteemi eesmärki (põhifunktsiooni) ning nõutavaid sisend- ja väljundandmeid, kontrolli- ja regulatiivteavet ning mehhanisme.

    Lubatud kiiruste määramise probleemi kontekstiskeem on näidatud joonisel 6.21. Mudeli ehitamiseks kasutati Computer Associates BPwin 4.0 toodet.


    Riis. 6.21. Lubatud kiiruste määramise süsteemi kontekstiskeem (metoodika IDEF0)

    Nagu taustainfo, mille alusel määratakse lubatud kiirused, kasutatakse:

    Uue liini projekti või rekonstrueerimisprojekti andmed (sisaldab kogu projekti elluviimiseks vajalikku teavet, nimelt läbisõit, eraldi punktide teljed, liiniplaan jne);

    Üksikasjalik pikiprofiil (sisaldab ülalkirjeldatuga sarnast teavet);

    Rööbastee pass (sisaldab ülalkirjeldatuga sarnast teavet, samuti teavet raja ülemise struktuuri (VSP) kohta);

    Andmed rajaplaani uuringu tulemuste kohta rajamõõtmisauto poolt;

    Välise rööpa tõusude loetelu kurvides (sisaldab teavet rööbastee plaani kohta).

    Osa algsest teabest saab võtta erinevad allikad... Eelkõige saab teavet plaani (kõverate parameetrite) kohta võtta uue liini projektist või rekonstrueerimisprojektist, üksikasjalikust pikiprofiilist, rööbastee passist jne.

    Kontrolliandmed on:

    Maantee rööbastee juhi või Vene raudtee rööbaste ja rajatiste osakonna juhised arvutamiseks;

    Korraldus nr 41, mis sisaldab normatiivset ja viiteteavet, menetlust ja valede lubatavate kiiruste määramist;

    Teave praeguse või kavandatava rongiliikluse kohta (andmed ringlevate vedurite kaubamärkide ja kasutatud vagunite tüüpide kohta);

    Teave kavandatava raja remondi, ehitiste ja seadmete rekonstrueerimise ja ümberkorraldamise kohta.

    Tulemus Süsteemi töö peaks olema järgmine:

    Lubatud kiiruste lehed, mis sisaldavad igat tüüpi arvutatud kiirusi ja võimaldavad teil kindlaks teha nende piiramise põhjused;

    Teepea bülletään lubatud kiiruste kehtestamise kohta rööbastel ja eraldi punktides (tellimus "N") vastavalt teel vastu võetud vormile. Kinnitatud korraldus "N" fikseerib ametlikult rongi lubatud kiirused;

    Standardvormid nr 1, 1a ja 2, mis sisaldavad rongide sõiduplaani koostamiseks kavandatud lubatud kiirusi.

    Tellimuses "H" ja standardvormides sisalduvad kiirused võivad erineda lubatud kiiruste lehtedel arvutatud ja näidatud kiirustest. Selle põhjuseks on asjaolu, et need ei kajasta kiirusepiiranguid mitte ainult veeremi konstruktsiooni, VSP parameetrite ja kõverate järgi, vaid ka seadmete ja konstruktsioonide oleku tõttu (teepeenra deformatsioon, kontaktvõrgu tugede viltusus jne). .). Lisaks kohandatakse neid, võttes arvesse plaanitavat raja remonti, ehitiste ja seadmete rekonstrueerimist ja ümberkorraldamist jne.

    Kontekstdiagramm on pärast ehitamist üksikasjalik, kasutades esmatasandi lagunemisskeemi. See diagramm näitab süsteemi funktsioone, mida tuleb põhifunktsiooni raames rakendada. Diagrammi, mille jaoks lagunemine on läbi viidud, seda kirjeldavate diagrammide suhtes nimetatakse lapsevanem ... Lagunemisskeemi vanema suhtes nimetatakse tütarettevõte .

    Vaadeldava probleemi esimese taseme lagunemisskeem on näidatud joonisel 6.22. Reeglina on lagunemisskeemi koostamisel algne funktsioon (lagundatav) jagatud 3–8 alamfunktsiooniks (plokiks). Sel juhul soovitatakse lagunemisskeemi plokid paigutada vasakult paremale, ülevalt alla, nii et alamfunktsioonide interaktsiooni jada ja loogika oleksid paremini nähtavad.


    Riis. 6.22. 1. taseme lagunemisskeem (IDEF0 metoodika)

    Vaadeldava probleemi lahendamise funktsioonide täitmise järjekord on järgmine:

    Võrdlusteabe ja teelõikude andmete sisestamine ja parandamine (plokid 1 ja 2);

    Ülesande ettevalmistamine arvutamiseks (plokk 3). See näitab, millise lõigu ja rööbastee jaoks, samuti veduri kaubamärgi ja vagunite tüübi kohta tuleks arvutus läbi viia;

    Lubatud kiiruste arvutamine vastavalt korraldusele nr 41 (plokk 4) määratud korrale ja valemitele. Esialgne teave on andmed lõigu teel (plaan, raja ülemine struktuur jne) ja arvutuse ülesande alusel valitud standardid;

    Lubatud kiiruste nimekirjade koostamine (plokk 5). Arvutamistulemuste põhjal luuakse mitut tüüpi väljunddokumente, mis ühelt poolt võimaldavad tuvastada kiirusepiirangute põhjuse, teisalt on aluseks reguleeritud dokumentide koostamisele;

    Määruse "N" eelnõu ja standardlehtede (lahtrid 6 ja 7) vormistamine ja koostamine.

    Pärast esimese astme lagunemisskeemi koostamist koostatakse sellel näidatud funktsioonide jaoks eraldi skeemid (teise astme lagunemisskeemid). Seejärel jätkub lagunemisprotsess (diagrammide koostamine), kuni funktsioonide edasine täpsustamine kaotab oma tähenduse. Iga elementaarset toimingut kirjeldava aatomifunktsiooni (st funktsiooni, millel puudub lagunemisskeem) kohta koostatakse üksikasjalik spetsifikatsioon, mis määratleb selle omadused ja rakendusalgoritmi. Spetsifikatsiooni täiendamiseks võib kasutada algoritmide vooskeeme. Seega seisneb funktsionaalse modelleerimise protsess funktsioonide hierarhia järkjärgulises koostamises.

    6.7. ICOM -koodid

    Ülemise taseme diagrammi plokki sisenevad ja sealt väljuvad nooled on samad, mis alumise taseme diagrammi sisenevad ja sealt väljuvad, kuna plokk ja diagramm esindavad sama süsteemi osa (vt joonis ja ). Sellest tulenevalt on tipptasemel funktsiooni piirid samad kui lagunemisskeemi piirid.

    ICOM -koodid (lühend sisendist, juhtimisest, väljundist ja mehhanismist) on piirinoolte tuvastamiseks. ICOM -kood sisaldab noole tüübile vastavat eesliidet (I, C, O või M) ja järjekorranumbrit (vt joonis).

    Äriprotsesside skeemide "Ettevõtte arvutiseadmete arvestus" kirjeldus

    IDEF0 diagrammi kirjeldus

    Äriprotsessi ülesehitamiseks kasutati IDEF0 diagrammi. IDEF0 metoodika näeb ette diagrammide hierarhilise süsteemi ülesehituse - süsteemi fragmentide üksikud kirjeldused. Esiteks kirjeldatakse süsteemi tervikuna ja selle koostoimet välismaailmaga (kontekstiskeem). Diagrammil ehitati kolm taset:

    1. Kontekstuaalne

    2. Funktsionaalne lagunemine

    Joonis 1 - Kontekstdiagramm "Ettevõtte arvutiseadmete arvestus"

    Joonisel 1 on kujutatud äriprotsessi "Ettevõtte arvutiseadmete arvestus" kontekstiskeem. See kuvab süsteemi tervikuna ja selle koostoimet peamiste väliste infovoogudega.

    Nooled on näidatud kontekstiskeemil.

    Noole tüübid:

    Sisend (sisendmaterjalid: arvutid ja tarvikud)

    Väljund (väljund on aruanne)

    Juhtnool on dokumendid ja haldurid

    Mehhanismide nooled on töötajad ja seadmed

    Sisendteave töötlemiseks:

    Arvutid - ettevõttes asuvad personaalarvutid

    Komponendid - arvutite moderniseerimiseks vajalikud materjalid (videokaardid, emaplaadid, protsessorid, ümbrised, toiteallikad, mälumoodulid)

    Väljundvoogud:

    Aruanne - valmis aruanne ettevõtte arvutiseadmete raamatupidamise kohta

    Sisendi juhtnupud:

    Reeglid - tingimused, mis peavad olema täidetud eesmärgi saavutamiseks.

    Tellimused - ettevõttele pandud ülesanne (teatud arvutisüsteemide abil ettevõtte arvutite üle arvestuse pidamine)

    Juhid on ettevõtte direktorid ja üldjuhid.

    Sisendressursid:

    PC - arvutid, mille abil toimub raamatupidamine.

    Töötajad on spetsialistid, kes täidavad juhtkonna antud juhiseid. Pärast kontseptuaalse mudeli koostamist viidi läbi funktsionaalne lagundamine - süsteem jagatakse alamsüsteemideks ja iga alamsüsteemi kirjeldatakse eraldi (lagunemisskeemid).

    Joonis 2 näitab nelja töö funktsionaalset lagunemist.


    Joonis 2 - Funktsionaalne lagunemine "Ettevõtte arvutiseadmete arvestus"

    Tuvastati järgmist tüüpi tööd:

    1) Tarnete registreerimine - protsess, mille käigus tootele määratakse id, saadetakse lattu, lattu ja teave toote kohta sisestatakse programmi.

    Töö Varude registreerimine sisaldab seitset piirnoolt (sissepääs, juhtseade, mehhanism) ja sisemist noolelehte (ühendus sissepääsu kaudu).

    Tööde vaheline sissepääsu juures asuv noolega side Tarnete registreerimine ja arvuti (arvuti) hooldus;

    Järgmistes töödes korratakse sisenemise, väljumise, juhtimise nooli.

    2) Arvutite hooldus - protsess, mille käigus toimub arvutite kokkupanek, remont ja kaasajastamine.

    Arvuti hooldustöö hõlmab nelja piirinoolt (sisend, juhtimine, mehhanism, väljund) ja mitut sisemist noolt (sisendkommunikatsioon, sisendi tagasiside).

    Noolikontroll - reeglid, käsud, juht;

    Nooleühendus sissepääsu juures töökohtade vahel Arvuti hooldus ja paigutus (andmete sisestamine andmebaasi), tööde vahel Arvutihooldus ja aruandlus (andmete sisestamine andmebaasi);

    3) Paigutamine - protsess, mille käigus toimub arvutite paigutamine kontoritesse (kontoritesse).

    Nooled kontrollivad - reeglid, käsud, juht;

    Noolemehhanism - töötajad;

    Noole link levitamise ja aruandluse vahel (ID määramine);

    4) Aruande koostamine - raamatupidamisprotsessi viimane etapp, mis koosneb jooksva raamatupidamise varasemate andmete täitmisel saadud kogusummade kokkuvõtmisest.

    Seejärel jaotatakse iga alamsüsteem väiksemateks lagundusteks ja nii edasi, kuni soovitud detailsusaste on saavutatud.


    Joonis 3 on diagramm, mis näitab hangete tööd üksikasjalikumalt.

    Detailimise tulemusena toodi esile peamised funktsioonid. Jaotis "Varude registreerimine" sisaldab seitset peamist noolt (sisenemine, väljumine, juhtimine, mehhanism).

    Noole sisestus - arvutid ja tarvikud;

    Kontrollnool on reeglid, käsud ja juht. Kahvliga nooled;

    Mehhanismi nooled, hargnemine - PC, töötajad;

    Sisenemise, juhtimise, mehhanismide nooled korduvad kõikides töödes.

    1) Numbri määramine - arvutitele ja lisaseadmetele individuaalse numbri määramine.

    Sisestusnooled - arvutid ja tarvikud. Noolearvuteid korratakse järgmistes töödes, välja arvatud aruande koostamine;

    Juhtnooled - reeglid, käsud ja juht;

    Mehhanismi nooled - arvuti ja töötajad;

    Noolilink sissepääsu juures tööde vahel Numbri määramine ja kauba saatmine lattu (üleandmine), numbri määramise ja tasakaalu panemise vahel (baasi sisenemine);

    2) Kauba saatmine lattu - määratud numbriga kauba saatmine lattu.

    Väljumisnool - arvuti;

    Juhtnool - reeglid, käsud ja juht.

    Noole link sissepääsu juures tööde "Kauba saatmine lattu" ja "Bilansis seadistamine" vahel (kogus);

    3) Tasakaalustamine - teabe sisestamine arvutisse.

    Juhtnooled - reeglid, käsud ja juht;

    Mehhanismi nooled - arvuti ja töötajad;


    Joonis 4 on diagramm, mis kirjeldab üksikasjalikumalt arvuti hooldust.

    Detailimise tulemusena toodi esile arvuti hoolduse käigus täidetud põhifunktsioonid.

    Arvuti hooldustöö sisaldab 4 piirinoolt (sisend, väljund, juhtimine, mehhanism). Sisemised nooled (sisendi tagasiside, sisendkommunikatsioon).

    1) Arvutite kokkupanek - arvutite konfigureerimine juhtide individuaalsete tellimuste jaoks.

    Sisselogimisnool - arvutid;

    Juhtnooled - reeglid, käsud ja juht;

    Mehhanismi nooled - töötajad;

    Noole link sissepääsu juures tööde vahel: "Arvutite kokkupanek" ja "Arvutite remont" (arvuti);

    2) Arvutite remont - täiustamiseks heaks kiidetud arvutite kokkupanek.

    Sisselogimisnool - arvutid;

    Väljumisnool - sisenemine baasi;

    Juhtnooled - reeglid, käsud ja juht;

    Mehhanismi nooled - töötajad;

    Sisenemise, väljumise, juhtimise, mehhanismi nooled hargnevad;

    Noole link sissepääsu juures tööde vahel: "Arvutite remont" ja "Uuendamine" (tarvikud);

    3) Uuendamine - arvuti täiustamine, täiustamine, täiendamine.

    Väljumisnool - sisenemine baasi;

    Juhtnooled - reeglid, käsud ja juht;

    Mehhanismi nooled - töötajad;

    Juhtimisnooled, mehhanism hargnevad;


    Joonis 5 näitab aruandlusgraafikut üksikasjalikumalt. Töö lagunemine Aruandlus sisaldab 4 piirinoolt (sisend, väljund, juhtimine, mehhanismid). Sisemised nooled (sisendi tagasiside, sisendkommunikatsioon).

    Töö tulemusena saadi järgmised funktsioonid:

    1) Andmete kogumine - teabe kogumine analüüsimiseks ja otsuste tegemiseks.

    Sisesta nool - määramise ID;

    Juhtnooled - reeglid, käsud ja juht;

    Sisenemise, juhtimise, mehhanismi nooled hargnevad;

    Noole link tööde sissepääsu juures: Andmete kogumine ja andmete valideerimine (kirjed);

    2) Andmete kontrollimine - teabe kontrollimine ja selle saatmine aruande koostamiseks.

    Noolekanne - ID määramine, andmete sisestamine andmebaasi;

    Väljumisnool - aruanne;

    Juhtnooled - reeglid, käsud ja juht;

    Mehhanismi nooled - töötajad, arvuti;

    Sisenemisnool (ID määramine), juhtimine, mehhanism hargnevad;

    Sisestage tagasiside nool „Andmekontrollilt” „Andmete hankimisele” (korduv kontroll).

    DFD diagrammi kirjeldus

    Arvutihooldustööde lagundamine Joonis 1 määratleb neli sisemist tegevust, kaks välist olemit ja kaks andmesalvestust.


    Joonis 1 - Arvuti hooldus

    1) Arvuti kokkupanek - arvuti kokkupanek olemasolevatest komponentidest.

    2) Aruande koostamine - protsess, mis koosneb jooksva raamatupidamise töö tegemisel saadud lõppnäitajate kokkuvõtmisest.

    3) Diagnostika - jõudluse kontroll

    4) Uuendamine - arvuti täiustamine, täiustamine, täiendamine.

    Välised üksused: arvutid ja komponendid

    Andmesalved:

    1) Ladu - koht, kus hoitakse kokkupandud ja täiendatud arvuteid.

    2) DB - andmebaas, mis salvestab kõik aruanded ja kogu teabe tehtud töö kohta.

    Kogume teavet arvuti kohta ja valime selle kokkupanekuks komponendid. Seejärel paneme arvuti kokku ja saadame selle lattu ladustamiseks, kuid peale selle saame selle pärast kokkupanekut esmalt saata diagnostikaks, kontrollida töökorras olekut ja alles siis lattu. Pärast kokkupandud arvuti diagnoosimist saadame andmed tehtud töö kohta aruande koostamiseks ja sisestame teabe andmebaasi.

    Meil on ka teine ​​väline olem, see on arvuti. Saadame selle moderniseerimiseks, seejärel diagnostikaks, et kontrollida selle toimivust, seejärel koostame aruande ja sisestame andmebaasi tehtud töö kohta teabe. Või pärast moderniseerimist saadame kauba lattu ja seejärel viime läbi diagnostika, koostame aruande ja sisestame teabe andmebaasi.

    Tööde lagundamise "Aruandlus" Joonis 2 määratleb kolm sisemist tegevust, kolm välist olemit ja kaks andmesalvestust.

    1) Andmete kogumine - teabe kogumine arvutite ja komponentide kohta.

    2) Valideerimine - andmete täpsuse kontrollimine.

    3) Aruanne - aruande kirjutamine tehtud töö kohta.

    Välised üksused: komponendid, arvutid, haldur.

    Andmeladu - andmed arvutite ja komponentide kohta, aruannete andmed.


    Arvutite ja tarvikute kohta teabe kogumine, seejärel nende salvestamiseks saatmine. Pärast seda kontrollime andmete õigsust, koostame aruande ja saadame need tagasi esimesse andmelattu (joonis 2) või saadame aruande andmed teise andmelattu (joonis 2) ja saadame need seejärel kontrollige.

    Juht kontrollib, teeb märkmeid, parandusi ja saadab uuesti kontrollimiseks. Pärast seda saadetakse aruanne säilitamiseks kuni halduri uuesti kontrollimiseni.

    IDEF3 diagrammi kirjeldus

    Tööde lagundamisel Arvuti hooldus (joonis 1) on määratletud mitu ristmikku, mis ühendavad ühte või mitut tööd, mitut sisemist tööd.


    1) Remont - arvuti kokkupanek kokkupandavate komponentidega

    2) Kokkupanek - arvuti normaalseks taastamine

    3) Upgrade - arvuti uuendamine

    4) Arvutid - toode pärast kokkupanekut ja moderniseerimist

    5) Saatke lattu - saatke pärast täiustamist (kokkupanekut) lattu

    6) Diagnostika - jõudluse kontroll.

    7) Aruanne - teave tehtud töö kohta.

    Ristmikud - pistikud:

    1) J2 - kõik toimingud algavad samal ajal.

    2) J6 - Ühinemiskoht. Sõlm, mis kogub palju nooli ühte, mis näitab protsessi jätkamiseks tingimust, mis nõuab noolte tööallikate lõpuleviimist.

    3) J7 - näidatakse, et neid tingimusi ei saa üheaegselt täita.

    4) J9 - need toimingud lõpevad samal ajal, pärast mida koostatakse tehtud töö kohta aruanne.

    IDEF3 diagramm näitab, et ristmikul J2 on kaks hargnevat noolt töö (ehitamiseks ja täiendamiseks), mis algavad samal ajal. Alles pärast nende tööde lõpetamist väljub valmistoode (arvuti), ühendab ristmiku J6. Pärast seda on ristmikul J7 ühendus, mis näitab, et kahte tööd (kauba saatmine lattu ja diagnostika) ei saa teha korraga. Pärast eelmise töö lõpetamist on käimas tööde aruande koostamise protsess, mida ühendab ristmik J9.