» »

IDEF0: mis see on ja kuidas seda kasutatakse. Idef3 (ja idef0) diagrammide koostamine – millises programmis peaksin seda tegema? Arvutiprogrammi arendamine in idef0

Gennadi Vernikov

Praegu on Venemaal huvi läänes üldtunnustatud juhtimisstandardite vastu järsult kasvanud, kuid tegelikus juhtimispraktikas on üks väga oluline moment. Paljud juhid võivad endiselt olla hämmingus otsesest küsimusest organisatsiooniline struktuur ettevõtte või olemasolevate äriprotsesside skeemi kohta. Kõige arenenumad ja regulaarselt lugevad majandusajakirjade juhid hakkavad reeglina joonistama ainult neile üksi arusaadavaid hierarhilisi diagramme, kuid selles protsessis jäävad nad tavaliselt kiiresti seisma. Sama kehtib ka erinevate talituste ja funktsionaalüksuste töötajate ja juhtide kohta. Enamasti on ainus sätestatud reeglite kogum, mille alusel ettevõte peab tegutsema, eraldi reeglite kogum ja töökirjeldus. Enamasti on need dokumendid koostatud rohkem kui aasta tagasi, need on halvasti struktureeritud ja üksteisega mitteseotud ning koguvad seetõttu lihtsalt riiulitele tolmu. Esialgu oli selline lähenemine õigustatud, kuna Vene kujunemise ajal turumajandus Konkurentsi mõiste praktiliselt puudus ja kuludega polnud erilist vajadust arvestada - kasum oli hiiglaslik. Selle tulemusena oleme viimase kahe aasta jooksul näinud üsna arusaadavat pilti: suured ettevõtted 90ndate alguses üles kasvanud on järk-järgult oma positsioone kaotamas kuni täieliku turult lahkumiseni. Osaliselt on see tingitud sellest, et ettevõttes ei juurutatud juhtimisstandardeid, puudus täielikult funktsionaalse tegevusmudeli ja missiooni kontseptsioon. Simulatsiooni kaudu erinevaid valdkondi tegevusi, on võimalik tõhusalt analüüsida juhtimise "pudelikaelu" ja optimeerida üldist äriskeemi. Kuid nagu teate, on igas ettevõttes kõige olulisem ainult need projektid, mis toovad otseselt kasumit, nii et tavaliselt on tegemist tegevuste uurimisega ja selle ümberkorraldamisega alles ettevõtte juhtimise käegakatsutava kriisi ajal.

1990. aastate lõpus, kui turg hakkas muutuma konkurentsivõimelisemaks ja ettevõtete kasumlikkus hakkas järsult langema, tundsid juhid suuri raskusi kulude optimeerimisel nii, et tooted püsiksid nii kasumlikud kui ka konkurentsivõimelised. Just sel hetkel avaldus selgelt vajadus omada silme ees ettevõtte tegevuse mudelit, mis kajastaks kõiki ühe äritegevuse erinevate allsüsteemide sidumise mehhanisme ja põhimõtteid.

Mõiste "äriprotsesside modelleerimine" jõudis enamiku analüütikute ellu samaaegselt komplekside turule ilmumisega. tarkvaratooted mõeldud integreeritud automaatika ettevõtte juhtimine. Sellised süsteemid hõlmavad alati sügavat projektieelne küsitlus ettevõtte tegevus. Selle küsitluse tulemuseks on ekspertarvamus, milles on eraldi lõigetes tehtud soovitused tegevuste juhtimise "pudelikaelade" kõrvaldamiseks. Sellest järeldusest lähtuvalt viiakse vahetult enne automatiseerimissüsteemi juurutamist läbi nn äriprotsesside ümberkorraldamine, mis on ettevõtte jaoks kohati üsna tõsine ja valus. See on muidugi meeskond, mis on aastate jooksul arenenud, on alati raske panna "mõtlema uutmoodi". Sellised kõikehõlmavad ettevõtete uuringud on alati keerulised ja erinevad oluliselt. Selliste keerukate süsteemide modelleerimise probleemide lahendamiseks on väljakujunenud metoodikad ja standardid. Need standardid hõlmavad IDEF-i metoodikate perekonda. Nende abiga saate tõhusalt kuvada ja analüüsida mitmesuguste keeruliste süsteemide tegevusmudeleid erinevates jaotistes. Samas määrab protsesside uurimise ulatuse ja sügavuse süsteemis arendaja ise, mis võimaldab loodud mudelit mittevajalike andmetega üle koormata. Praegu saab IDEF-i perekonnale 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 (funktsionaalsete plokkide – IDEF0 mõistes) kogumina. Tavaliselt on IDEF0 modelleerimine esimene samm mis tahes süsteemi õppimisel;

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

IDEF1X (IDEF1 Extended) – relatsioonistruktuuride ehitamise metoodika. IDEF1X kuulub ER (Entity-Relationship) tüüpi metoodikasse ja seda kasutatakse tavaliselt kõnealuse süsteemi jaoks asjakohaste relatsiooniandmebaaside modelleerimiseks;

IDEF2 on süsteemide arengu dünaamilise modelleerimise metoodika. Analüüsi väga tõsiste raskuste tõttu dünaamilised süsteemid sellest standardist praktiliselt loobuti ja selle väljatöötamine peatati juba algfaasis. Praegu on aga olemas algoritmid ja nende arvutirakendused, mis võimaldab muuta staatiliste IDEF0 diagrammide komplekti dünaamilisteks mudeliteks, mis on ehitatud "värviliste Petri võrkude" (CPN – Color Petri Nets) baasil;

IDEF3 on süsteemis toimuvate protsesside dokumenteerimise metoodika, mida kasutatakse näiteks teadustöös tehnoloogilised protsessid ettevõtete juures. IDEF3 kirjeldab iga protsessi stsenaariumi ja toimingute järjestust. IDEF3-l on otsene seos IDEF0 metoodikaga – iga funktsiooni (funktsionaalset plokki) saab IDEF3 tööriistu kasutades esitada eraldi protsessina;

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

IDEF5 on komplekssete süsteemide ontoloogilise uurimise metoodika. IDEF5 metoodikat kasutades saab süsteemi ontoloogiat kirjeldada kindla terminite ja reeglite sõnavara abil, mille alusel saab moodustada usaldusväärseid väiteid vaadeldava süsteemi seisu kohta mingil ajahetkel. Nende väidete põhjal tehakse järeldused umbes edasine areng süsteemi ja seda optimeerida.
Selle artikli raames käsitleme kõige sagedamini kasutatavat IDEF0 funktsionaalse modelleerimise metoodikat.

IDEF0 standardi ajalugu

IDEF0 metoodikat võib pidada järgmiseks etapiks tuntud funktsionaalsüsteemide kirjeldamise graafilise keele SADT (Structured Analysis and Design Teqnique) väljatöötamisel. Paar aastat tagasi ilmus Venemaal väike tiraaž samanimelisest raamatust, mis oli pühendatud SADT diagrammide koostamise põhiprintsiipide kirjeldamisele. Ajalooliselt töötati IDEF0 kui standard välja 1981. aastal ulatusliku automatiseerimisprogrammi osana tööstusettevõtted, mis kandis nimetust ICAM (Integrated Computer Aided Manufacturing) ja mille pakkus välja USA õhujõudude osakond. 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 interaktsiooniprotsesside analüüsimiseks. tööstussüsteemid. Samal ajal, lisaks täiustatud funktsioonide komplektile äriprotsesside kirjeldamiseks, oli uue standardi üheks nõudeks ka tõhusa metoodika olemasolu "analüütiku-spetsialisti" sees suhtlemiseks. Teisisõnu, uus meetod pidi tagama mudeli loomise grupitöö, milles osalevad 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 muudatusi, enamasti piiravaid, ja selle viimase redaktsiooni avaldas 1993. aasta detsembris USA riiklik standardite ja tehnoloogia instituut (NIST).

IDEF0 põhielemendid ja kontseptsioonid

IDEF0 graafiline keel on märkimisväärselt lihtne ja harmooniline. Metoodika põhineb neljal põhikontseptsioonil.

Esimene neist on tegevuskasti kontseptsioon. Funktsionaalplokk on graafiliselt kujutatud ristkülikuna (vt joonis 1) ja kujutab mõnda spetsiifiline funktsioon vaadeldava süsteemi piires. Vastavalt standardi nõuetele peab iga funktsionaalploki nimi olema sõnastatud verbaalses meeleolus (näiteks "teenuseid tootma", mitte "teenuseid tootma").

Funktsionaalploki igal neljal küljel on oma konkreetne tähendus (roll), samas kui:

  • Ülemine pool on "Juht";
  • Vasak pool on "Sisend";
  • Parem pool on seatud "Väljund";
  • Alumisel küljel on väärtus "Mehhanism" (Mehhanism).

    • Igal vaadeldava süsteemi funktsionaalsel üksusel peab olema oma kordumatu identifitseerimisnumber.

    Joonis 1. Funktsiooniplokk.

    IDEF0 metoodika teine ​​"vaal" on liidese kaare (nool) kontseptsioon. Samuti nimetatakse liidesekaari sageli voogudeks või noolteks. Liidesekaar tähistab süsteemi elementi, mida töötleb funktsiooniplokk või mis muul viisil mõjutab selle funktsiooniploki kuvatavat funktsiooni.

    Liidese kaare graafiline kuva on ühesuunaline nool. Igal liidesekaarel peab olema oma kordumatu nimi (Arrow Label). Standardi järgi peab nimi olema nimisõna käive.

    Liideskaarte 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, vagunid, töötajad jne) või andme- ja infovood (dokumendid, andmed, juhised jne).

    Sõltuvalt sellest, kummale poole antud liidesekaar läheneb, nimetatakse seda "sissetulevaks", "väljuvaks" või "juhtivaks". Lisaks võivad iga funktsionaalse kaare "allikas" (algus) ja "vastuvõtja" (lõpp) olla ainult funktsionaalsed plokid, samas kui "allikas" võib olla ainult ploki väljundkülg ja "vastuvõtja" võib olla ükskõik milline. ülejäänud kolmest.

    Tuleb märkida, et igal funktsionaalplokil peab vastavalt standardi nõuetele olema vähemalt üks juhtliidese kaar ja üks väljaminev. See on arusaadav – iga protsess peab toimuma vastavalt teatud reeglitele (kuvatakse juhtkaarega) ja andma mingi tulemuse (väljaminev kaar), vastasel juhul pole selle arvestamisel mingit mõtet.

    IDEF0 - diagrammide koostamisel on oluline õigesti eraldada sissetulevad liidese kaared juhtkaartidest, mis pole sageli lihtne. Näiteks joonisel 2 on näidatud funktsiooniplokk "Tooriku töötlemine".

    Reaalses protsessis antakse töötlemist teostavale töötajale töödeldav detail ja tehnoloogilised juhised (või ohutusnõuded masinaga töötamisel). Ekslikult võib tunduda, et nii toorik kui ka tehnoloogiliste juhistega dokument on sissetulevad objektid, kuid see pole nii. Tegelikult töödeldakse selles protsessis töödeldavat detaili vastavalt tehnoloogilistes juhistes kajastatud reeglitele, mida peaks vastavalt kujutama juhtliidese kaar.


    Joonis 2.

    Teine asi on see, kui tehnoloogilisi juhiseid töötleb peatehnoloog ja neis tehakse muudatusi (joon. 3). Sellisel juhul kuvatakse need juba sissetuleva liidese kaare poolt ja juhtimisobjektiks on näiteks uued tööstusstandardid, millest lähtuvalt need muudatused tehakse.


    Joonis 3

    Ülaltoodud näited rõhutavad sissetulevate ja kontrollivate liideste kaare näiliselt sarnast olemust, kuid sama klassi süsteemide puhul on alati teatud erinevusi. Näiteks ettevõtete ja organisatsioonide kaalumisel eristatakse viit peamist objektitüüpi: materjalivood (osad, kaubad, tooraine jne), rahavood (sularaha ja mittesularaha, investeeringud jne), dokument vood (äri-, finants- ja organisatsioonidokumendid), infovood (teave, tahteandmed, suulised korraldused jne) ja ressursid (töötajad, masinad, masinad jne). Sellisel juhul saavad sissetulevad ja väljaminevad liidesekaared erinevatel juhtudel kuvada igat tüüpi objekte, mis haldavad ainult dokumentide ja teabe liikumisega seotud objekte ning kaarmehhanismidena saab kuvada ainult ressursse.

    Juhtliidese kaare kohustuslik olemasolu on üks peamisi erinevusi IDEF0 standardi ja teiste DFD (Data Flow Diagram) ja WFD (Work Flow Diagram) klasside metoodikate vahel.

    IDEF0 standardi kolmas põhikontseptsioon on lagunemine. Dekomponeerimise põhimõtet rakendatakse siis, kui keeruline protsess jaotatakse selle koostisosadeks. Sel juhul määrab protsessi detailsuse taseme otse mudeli arendaja.

    Dekomponeerimine võimaldab järk-järgult ja struktureeritult esitada süsteemimudelit üksikute diagrammide hierarhilise struktuuri kujul, mis muudab selle vähem ülekoormatuks ja kergesti seeditavaks.

    IDEF0 mudel algab alati süsteemi kui terviku vaatega - ühest funktsionaalsest plokist, mille liidese kaared ulatuvad väljapoole vaadeldavat piirkonda. Sellist ühe funktsiooniplokiga diagrammi nimetatakse kontekstdiagrammiks ja seda tähistatakse identifikaatoriga "A-0".

    Kontekstiskeemi selgitavas tekstis vormis diagrammi koostamise eesmärk (Eesmärk) Lühike kirjeldus ja fikseeritud vaatepunkt (Viewpoint).

    IDEF0 arengueesmärgi määratlemine ja vormistamine - mudelid on äärmiselt oluline punkt. Tegelikult määrab eesmärk uuritavas süsteemis asjakohased valdkonnad, millele tuleb esmalt keskenduda. Näiteks kui modelleerime ettevõtte tegevust, et selle mudeli alusel tulevikus ehitada infosüsteem, siis erineb see mudel oluliselt sellest, mille töötaksime välja samale ettevõttele, kuid tarneahelate optimeerimise eesmärgil.

    Vaatepunkt määrab mudeli arendamise põhisuuna ja nõutava detailsuse taseme. Vaatepunkti selge fikseerimine võimaldab mudelit maha laadida, keeldudes üksikasjadest ja üksikute elementide uurimisest, mis pole vajalikud, lähtudes süsteemi valitud vaatepunktist. Näiteks sama ettevõtte funktsionaalsed mudelid peatehnoloogi vaatenurgast ja finantsjuht erinevad oluliselt nende detailistamise suunas. Selle põhjuseks on asjaolu, et lõppkokkuvõttes ei huvita finantsdirektorit tooraine töötlemise aspektid tootmismasinatel ja peatehnoloogi ei huvita joonistatud rahavoogude skeemid. Õige valik vaatenurgast vähendab oluliselt lõpliku mudeli ehitamisele kuluvat aega.

    Lagundamise protsessis on funktsionaalplokk, mis kontekstidiagrammis kuvab süsteemi tervikuna, üksikasjalikult teises diagrammis. Saadud teise taseme diagramm sisaldab funktsionaalplokke, mis kuvavad kontekstiskeemi funktsionaalploki põhilisi alamfunktsioone ja mida nimetatakse selle suhtes alamdiagrammiks (Child diagram) (iga alamdiagrammi kuuluv funktsionaalplokk on vastavalt nimetatakse lapseplokiks – Child Box). Funktsionaalplokki - esivanemat nimetatakse omakorda alamdiagrammi suhtes vanemplokiks (Parent Box) ja diagrammi, kuhu see kuulub - vanemdiagrammi (Parent Diagram). Iga alamdiagrammi alamfunktsiooni saab üksikasjalikumalt kirjeldada vastava funktsionaalploki sarnase dekomponeerimisega. Oluline on märkida, et funktsionaalploki igal lagunemisel fikseeritakse kõik sellesse plokki kuuluvad või sellest väljuvad liidesekaared alamdiagrammile. Sellega saavutatakse IDEF0 mudeli struktuurne terviklikkus. Dekomponeerimise põhimõte on selgelt näidatud joonisel 4. Tähelepanu tuleks pöörata funktsionaalplokkide nummerdamise ja diagrammide vahelisele seosele - igal plokil on diagrammil oma kordumatu seerianumber (arv ristküliku alumises paremas nurgas) ja paremas nurgas olev tähistus näitab selle ploki alamdiagrammi numbrit. Selle tähise puudumine näitab, et selle ploki lagunemine puudub.

    Sageli on juhtumeid, kus ei ole mõtet alamdiagrammides jätkata üksikute liideste kaare arvestamist hierarhia teatud tasemest madalamal või vastupidi - üksikutel kaaretel pole teatud tasemest kõrgemal praktilist mõtet. Näiteks liidesekaar, mis kujutab funktsiooniploki "Protsess sees" sisendis olevat "detaili". treipink" ei ole mõtet mõtiskleda kõrgema taseme diagrammide üle – see ainult koormab diagramme üle ja muudab nende lugemise raskeks. Teisest küljest võib osutuda vajalikuks vabaneda üksikutest "kontseptuaalsetest" liidesekaartidest ja mitte neid üksikasjalikult kirjeldada sügavamal kui teatud tase. Selliste probleemide lahendamiseks on IDEF0 standard näeb ette tunneldamise kontseptsiooni.Liidese kaare alguses oleva kahe sulu kujul olev märge "tunnel" (Arrow Tunnel) näitab, et see kaar ei olnud päritud. funktsionaalsest vanemplokist ja ilmus ("tunnelist") ainult sellel diagrammil. pööre, sama tähistus liidese kaare otsa (nool) ümber vastuvõtja ploki vahetus läheduses tähendab asjaolu, et see kaar ei tööta kuvatakse ja võetakse arvesse selle ploki alamdiagrammis. Liidese kaare ei võeta arvesse mõnel hierarhia vahepealsel tasemel – sellisel juhul nad esmalt "sukelduvad tunnelisse" ja seejärel vajadusel "naasevad tunnelist" .

    Viimane IDEF0 mõistetest on sõnastik. Iga IDEF0 elemendi jaoks: diagrammid, funktsiooniplokid, liidesekaared eeldab olemasolev standard sobivate määratluste komplekti loomist ja hooldamist, märksõnad, jutustavad väited jne, mis iseloomustavad selle elemendiga kuvatavat objekti. Seda komplekti nimetatakse sõnastikuks ja see kirjeldab selle elemendi olemust. Näiteks juhtimisliidese kaare "maksekorraldus" jaoks võib sõnastik sisaldada dokumendi kaarele vastavate väljade loendit, nõutavat viisade komplekti jne. Sõnastik täiendab harmooniliselt visuaalset graafilist keelt, pakkudes diagramme vajaliku lisateabega.


    Joonis 4. Funktsionaalplokkide lagunemine.

    IDEF0 diagrammide keerukuse piiramise põhimõtted

    Tavaliselt kannavad IDEF0 mudelid keerulist ja kontsentreeritud teavet ning nende ülekoormuse piiramiseks ja loetavaks muutmiseks võetakse vastavas standardis vastu vastavad keerukuspiirangud:

    Funktsiooniplokkide arvu piiramine diagrammil kolmele kuni kuuele. Ülemine piir (kuus) sunnib kujundajat kasutama keeruliste ainete kirjeldamisel hierarhiaid ning alumine piir (kolm) tagab, et vastaval diagrammil on piisavalt detaili, et selle loomist õigustada;

    Ühele funktsionaalplokile lähenevate (ühe funktsionaalploki jätmise) liidesekaare arvu piiramine neljani.
    Loomulikult pole neid piiranguid vaja rangelt järgida, kuid nagu kogemus näitab, on need reaalses töös väga praktilised.

    IDEF0 mudeli väljatöötamise rühmatöö distsipliin

    IDEF0 standard sisaldab protseduuride kogumit, mis võimaldab mudelit välja töötada ja heaks kiita suurel hulgal modelleeritava süsteemi erinevatesse tegevusvaldkondadesse kuuluvaid inimesi. Tavaliselt on arendusprotsess iteratiivne ja koosneb järgmistest tingimuslikest etappidest:

    Mudeli loomine seotud spetsialistide rühma poolt erinevaid valdkondi ettevõtlik tegevus. Seda rühma nimetatakse IDEF0 terminites autoriteks. Esialgse mudeli koostamine on dünaamiline protsess, mille käigus autorid küsivad struktuuri kohta pädevatelt isikutelt erinevaid protsesse. Olemasolevate sätete, dokumentide ja uuringutulemuste põhjal koostatakse mudeli kavand (Model Draft).

    Eelnõu läbivaatamiseks, kooskõlastamiseks ja kommenteerimiseks jagamine. Selles etapis arutatakse mudeli kavandit ettevõttes paljude pädevate isikutega (IDEF0 lugejate osas). Samal ajal kritiseeritakse ja kommenteeritakse kirjalikult iga kavandi skeemi ning antakse seejärel üle autorile. Autor omakorda nõustub kriitikaga ka kirjalikult või lükkab selle otsuse loogika väitega tagasi ja tagastab parandatud eelnõu uuesti edasiseks läbivaatamiseks. See tsükkel jätkub, kuni autorid ja lugejad jõuavad üksmeelele.

    Mudeli kinnitus. Heakskiidetud mudeli kinnitab töörühma juht juhuks, kui mudeli autoritel ja lugejatel selle adekvaatsuse osas lahkarvamusi ei teki. Lõplik mudel on järjekindel vaade ettevõttele (süsteemile) antud vaatenurgast ja etteantud eesmärgist lähtudes.
    IDEF0 graafilise keele nähtavus muudab mudeli üsna loetavaks inimestele, kes selle loomise projektis ei osalenud, samuti tõhusaks demonstratsioonideks ja esitlusteks. Edaspidi saab konstrueeritud mudeli alusel korraldada uusi projekte, mille eesmärk on teha muudatusi ettevõttes (süsteemis).

    IDEF0 tööriistade abil funktsionaalse modelleerimise riikliku praktika tunnused

    Viimastel aastatel on Venemaa huvi IDEF-i perekonna metoodikate vastu pidevalt kasvanud. Jälgin seda pidevalt, kui vaatan oma isikliku veebilehe (http://www.vernikov.ru) tabamuste statistikat, mis kirjeldab lühidalt nende standardite põhiprintsiipe. Samas nimetaksin huvi selliste standardite vastu nagu IDEF3-5 teoreetiliseks ja IDEF0 puhul on see üsna praktiliselt põhjendatud. Tegelikult ilmusid esimesed Case-tööriistad, mis võimaldavad koostada DFD ja IDEF0 diagramme, Venemaa turule juba 1996. aastal, samal ajal kui ilmus populaarne raamat SADT-standardites modelleerimise põhimõtete kohta.

    Enamik juhte peab modelleerimise praktilist rakendamist IDEF-i standardites siiski pigem austusavalduseks moele kui tõhus viis optimeerimine olemasolev süsteemärijuhtimine. Tõenäoliselt on see tingitud teabe puudumisest praktilise rakendamise nendest metoodikatest ja enamiku väljaannete vältimatu tarkvara kallutatusega.

    Pole saladus, et peaaegu kõik uuringu- ja analüüsiprojektid finants- ja majanduslik tegevus Venemaa ettevõtted on praegu ehitusega ühel või teisel viisil seotud automatiseeritud süsteemid juhtimine. Tänu sellele on IDEF-i standardid enamuse arusaamises muutunud tinglikult juurutamisest lahutamatuks infotehnoloogiad, kuigi nende abiga on mõnikord võimalik tõhusalt lahendada isegi väikseid kohalikke probleeme, sõna otseses mõttes pliiatsi ja paberiga.

    Komplekssete ettevõtete uuringuprojektide läbiviimisel võimaldab IDEF0 standardi mudelite väljatöötamine kuvada visuaalselt ja efektiivselt kogu ettevõtte tegevuse mehhanismi õiges kontekstis. Kõige olulisem on aga koostöövõime, mida IDEF0 pakub. Minu praktiline tegevus oli päris palju juhtumeid, kui mudel valmis erinevate osakondade töötajate otsesel kaasabil. Samas konsultant piisavalt lühikest aega selgitas neile IDEF0 põhitõdesid ja õpetas töötama vastava rakendusega tarkvara. Selle tulemusena koostasid erinevate osakondade töötajad oma funktsionaalse üksuse tegevuse IDEF-skeemid, mis pidid vastama järgmistele küsimustele:

    Mis siseneb üksusesse "sissepääsu juures"?

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

    Kes vastutab iga funktsiooni eest?

    Mis juhib täitjat iga funktsiooni täitmisel?

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

    Pärast kavandite diagrammide kooskõlastamist igas konkreetses üksuses paneb konsultant need kokku ettevõtte mudeli kavandiks, milles on ühendatud kõik sisend- ja väljundelemendid. Selles etapis fikseeritakse kõik üksikute diagrammide ebakõlad ja nende vastuolulised kohad. Lisaks läbib see mudel uuesti funktsionaalseid osakondi edasiseks koordineerimiseks ja vajalike kohanduste tegemiseks. Selle tulemusena üsna lühikese ajaga ja minimaalselt kaasates inimressursid konsultatsioonifirma poolt (ja need ressursid, nagu teate, on väga kallid), saadakse ettevõtte IDEF0 mudel põhimõttel "nagu on" ja mis kõige tähtsam, see esindab ettevõtet töötajad, kes selles töötavad ja tunnevad põhjalikult kõiki nüansse, sealhulgas mitteametlikke. Tulevikus viiakse see mudel analüüsimiseks ja töötlemiseks ärianalüütikutele, kes otsivad ettevõtte juhtimises "pudelikaelu" ja optimeerivad põhiprotsesse, muutes mudeli "Nii nagu on" vastavaks "Nii nagu peab olema". "esindus. Nende muudatuste põhjal tehakse lõppjäreldus, mis sisaldab soovitusi juhtimissüsteemi ümberkorraldamiseks.

    Loomulikult nõuab selline lähenemine mitmeid organisatsioonilisi meetmeid, eelkõige uuritava ettevõtte juhtkonna poolt. See on tingitud asjaolust, et see tehnika hõlmab mõnele töötajale pealesurumist täiendavad kohustused uute metoodikate väljatöötamise ja praktilise rakendamise kohta. Lõppkokkuvõttes on see aga õigustatud, kuna üksikute töötajate üks või kaks tundi täiendavalt mitme päeva jooksul võib oluliselt säästa raha kolmanda osapoole ettevõtte konsultatsiooniteenuste eest tasumisel (mis igal juhul katkestab ettevõtte töö samad töötajad ankeetide ja küsimustega). Mis puudutab ettevõtte töötajaid, siis ühel või teisel viisil ei ole ma oma praktikas nende poolt ühtegi selgesõnalist vastuseisu kohanud.

    Sellest kõigest võib teha järgmise järelduse: absoluutselt pole vaja iga kord tüüpprobleemidele lahendusi välja mõelda. Iga kord, kui seisate silmitsi vajadusega analüüsida konkreetset funktsionaalset süsteemi (disainisüsteemist kosmoselaev, enne kompleksse õhtusöögi valmistamise protsessi) – kasutage aastate jooksul katsetatud meetodeid. Üks neist meetoditest on IDEF0, mis võimaldab kasutada oma lihtsat ja arusaadavat tööriistakomplekti keeruliste eluprobleemide lahendamiseks.

    Vene Föderatsiooni haridus- ja teadusministeerium

    Föderaalne Haridusagentuur

    osariik haridusasutus erialane kõrgharidus

    Kursuse töö

    "Süsteemi modelleerimine"

    "Kasvuhooneettevõtte mudeli väljatöötamine IDEF0, DFD ja IDEF3 projekteerimismetoodikatega"

    1. Töö eesmärk

    2. Teoreetiline sissejuhatus

    3. Kirjeldus ainevaldkond

    4. BPwini kirjeldus

    4.1 IDEF0 mudeli ehitamise põhimõte

    4.2 DFD mudeli koostamise põhimõte

    4.3 IDEF3 mudeli loomise põhimõte

    5. Simulatsioon

    5.1 Kasvuhoone mudel

    5.2 Matemaatiline mudel

    6. Võrdlusuuringud

    6.1 Metoodikad

    6.2 Tööriistade võrdlus

    Kirjandus

    1. Töö eesmärk

    Selle kursusetöö eesmärgid olid:

    ettevõtte projektieelse uuringu meetodite rakendamine;

    saadud materjalide analüüs järgnevaks modelleerimiseks;

    protsessimudeli väljatöötamine IDEF0 standardis;

    töövoo ja infotöötluse kirjeldus DFD standardis;

    protsesside kirjeldused IDEF3 standardis;

    segaprotsesside kirjeldamise mudeli väljatöötamine IDEFO, DFD ja IDEF3 standardite alusel.

    stsenaariumide loomine ettevõtte toimimiseks;

    ettevõtte struktuuriskeemi koostamine;

    selle ettevõtte matemaatilise mudeli loomine.

    võrdlev analüüs

    2. Teoreetiline sissejuhatus

    Automatiseeritud juhtimissüsteemide väljatöötamisel kodeerimise ja testimise etappides ilmneb suur hulk vigu, mille parandamisega kaasneb drastiline muutus kogu arendatavas süsteemis. Selliseid vigu arvestatakse modelleerimisel ja sügaval, üksikasjalikul analüüsil. loodud projekte. Modelleerimine võimaldab projekti "näha" arendusprotsessis ja luua eeldused süsteemi käitumise analüüsimiseks sõltuvalt algtingimustest.

    Simuleeritud juhtimissüsteemis toimuvate protsesside korrektseks koordineerimiseks on vaja luua struktuur, s.o. protsesside tõhustamine. Infosüsteemi toimimise modelleerimine on eriti oluline selle loomise algfaasis. Kuna selles etapis tehtud vigade parandamine on kõige kulukam, on probleemi analüüsi etapis ja selle lahendamiseks loogilise mudeli väljatöötamisest saadav kasu märkimisväärne.

    Sellega seoses on vaja uurida ja arendada ainevaldkonda, nimelt kasvuhoonetööstuse tööd. Selleks peate mõistma selle valdkonna terminoloogiat, koguma vajalikke regulatiivseid ja juriidilised dokumendid, uurige selle ettevõtte dokumentide näidiseid ja jälgige nende liikumist nii ettevõtte sees kui ka väljaspool seda.

    Järgmine arendusetapp on projekteerimise etapp. Enne projekteerimise ja juurutamise alustamist peate täpselt ja üksikasjalikult aru saama nõuetest kõrge tase. Lisaks on väga kasulik omada nõuete struktuuri, mida saab kasutada süsteemi moodustamisel sisendina. Kõik see saavutatakse analüüsi ja modelleerimisega.

    Modelleerimise ja projekteerimisetapis töötamise käigus on vaja hankida süsteemiprojekt, mis sisaldab selle rakendamiseks piisavalt teavet. Samuti on vaja analüüsida kasvuhoonetööstuse tööd, mille tulemusel saab hinnata iga osakonna töökoormuse määra, mida on vaja eelkõige automatiseerida ja milliste vahenditega.

    Modelleerimise peamised eesmärgid projektide väljatöötamisel on:

    ettevõtte tegevuse ja selles kasutusele võetud tehnoloogiate kujutamine diagrammide hierarhia kujul, mis tagab nende kuvamise nähtavuse ja täielikkuse;

    moodustamine organisatsiooni- ja juhtimisstruktuuri ümberkorraldamise ettepanekute analüüsi alusel;

    infovoogude (sh töövoo) sujuvamaks muutmine ettevõttes;

    ettevõtete infosüsteemide nõuete analüüs ja spetsifikatsioonide kujundamine.

    3. Ainevaldkonna kirjeldus

    Sellega arvestamiseks referaat võeti kasvuhoonete töö aluseks. See ettevõte on spetsialiseerunud põllukultuuride kasvatamisele. Toodete müük toimub kliendi soovil.

    Töö korraldamine toimub vastavalt järgmisele skeemile:

    See diagramm näitab ettevõtte osakondi, nende funktsioone ja omavahelisi seoseid. Mõnda osakonda saab automatiseerida.

    Kogu ettevõtte eesotsas on juhtkond, keda esindavad pealik ja tema asetäitja. Nende peamine ülesanne on kontrollida ettevõtte tegevust.

    Töökaitseteenistus, mille põhifunktsiooniks on personali koolitamine;

    Raamatupidamine tegeleb dokumendihaldusega;

    Tootmiskontrolli teenus teostab täielikku kontrolli kõigis tootmisetappides;

    Sektor Hooldus remonditöödega tegelenud.

    Selle ettevõtte osakonnad, teenused ja töökohad on toodud tabelis nr 1:

    tabel number 1

    Meie kasvuhoonetööstuse ülesanded ja funktsioonid on toodud tabelis nr 2:

    Tabel number 2

    Dokumentatsioon on esitatud tabelites nr 3:

    tabel number 3

    Organisatsioonide kataloog on toodud tabelis nr 4:

    tabel number 4

    Järgnev on diagramm, mis kirjeldab ettevõtte stsenaariumi koos vastavate järeldustega iga etapi kohta: klient saab müügijuhile taotluse teatud kasvuhoonetoodete tarnimiseks. Müügijuht töötleb seda taotlust ja teeb otsuse. Paralleelselt arvutab raamatupidaja teenuste osutamise maksumuse. Kui kõik need etapid on läbitud, algab lepingu sõlmimise protsess. Müügijuht arutab kliendiga läbi lepingu tingimused ja sõlmib selle. Pärast seda teeb klient makse. Kontroll makse üle on raamatupidamisosakonna ülesanne. Raamatupidaja saab pangast väljavõtte ja vormistab tellimuse täitmise alustamiseks korralduse, mis edastatakse tehnoloogile. Tehnoloog koostab omakorda plaani - töögraafiku ja peab arvestust vajalike vahendite üle. Peale plaani - tööde graafiku koostamist antakse aednikule korraldus maatööde teostamiseks. Aednik teeb maatöid ja koristab. Koristatud saak saadetakse kliendile. Tee peal tootmistsükkel ettevõtte juht saab aruandeid müügijuhi, raamatupidaja ja tehnoloogi tegevuse kohta. Juhataja kontrollib kogu ettevõtte protsessi ja vajadusel kommenteerib oma töötajate tööd, et parandada tootmisprotsessi ja kogu ettevõtte tööd tervikuna.

    Ettevõtte stsenaariumi skeem

    4. BPwini kirjeldus

    BPwin on väike integreeritud modelleerimistööriist, mis toetab mitut tüüpi mudeleid ja meetodeid.

    Äriprotsesside analüüsimiseks ja ümberkorraldamiseks pakub Logic Works tipptasemel CASE tööriista - BPwin, mis toetab IDEF0 metoodikaid ( funktsionaalne mudel), IDEF3 (töövoo diagramm) ja DFD (andmevoo diagramm). Peamine kolmest metoodikast on IDEF0. BPwinil on üsna lihtne ja intuitiivne kasutajaliides, mis võimaldab analüütikul luua keerulisi mudeleid minimaalse vaevaga.

    BPwin automatiseerib arendusmudelite ehitamisega seotud ülesandeid, pakkudes õigete ja järjepidevate tulemuste tagamiseks vajalikku semantilist rangust. See saavutatakse, kasutades BPwinis järgmisi metoodikaid: IDEF0, DFD ja IDEF3.

    Kuid enne selle keerukama ülesandega tegelemist on tõesti vaja kõik ettevõtte elemendid vähemalt "ümber arvutada", st luua ettevõtte organisatsiooniline struktuur. Järgmine samm on püüda graafiliselt kujutada seoseid eelnevalt määratletud struktuuri erinevate elementide vahel.

    BPwinis on võimalik ehitada segamudeleid, st mudel võib sisaldada korraga nii IDEFO, IDEF3 kui ka DFD diagramme. BPwini mudelit vaadeldakse tegevuste kogumina, millest igaüks töötab teatud andmekogumi alusel. Tööd kuvatakse ristkülikutena, andmed nooltena.

    Kõik mudeli tööd on nummerdatud. Number koosneb eesliitest ja numbrist. Kasutada võib mis tahes pikkusega eesliidet, kuid tavaliselt kasutatakse eesliidet A. Puu konteksti (juur)tehte on nummerdatud A0. Lagundamise töö A0 on nummerdatud Al, A2, A3 jne. Madalama astme dekomponeerimistöödel on algteose number ja järgmine järjekorranumber, näiteks dekompositsiooni A3 töödel on numbrid A3.1 A3.2, AZ.3, A3.4 jne.

    Diagrammide, IDEFO diagrammide, DFD ja IDEF3 lisamise tulemusena saab luua segamudeli, mis kirjeldab kõige paremini ettevõtte kõiki aspekte. Segamudeli tööhierarhiat saab näha Model Exploreri aknas. Kujutatud on IDEFO noodikirjas teosed rohelises, DFD - sinine.

    BPwin, nagu ka kohalikud integreeritud süsteemid, praktiliselt ei võimalda teha terviklikku süsteemide analüüsi, mis on enam-vähem vajalik väikese, keskmise ja suure PMIS-i loomiseks. Nende abiga saate arendada kohalikke IS-i või väikeseid alamsüsteeme, mis on loodud üksikute äriahelate automatiseerimiseks, st siis, kui selleks puudub vajadus kompleksne analüüs ettevõtetele. Tüüpiline väikeste integreeritud tööriistade kasutamise valdkond on ettevõtte niinimetatud "tükikaupa" automatiseerimise probleemide lahendamine.

    4.1 IDEFO mudeli koostamise põhimõte

    IDEFO metoodika aluseks on graafiline keel äriprotsesside kirjeldamiseks. IDEFO tähistuses olev mudel on hierarhiliselt järjestatud ja omavahel seotud diagrammide kogum. Iga diagramm on süsteemi kirjelduse ühik ja asub eraldi lehel.

    IDEFO mudel eeldab ühe modelleerimisobjekti ja ühe vaatenurga selgelt määratletud eesmärgi olemasolu.

    Mudel võib sisaldada nelja tüüpi diagramme:

    kontekstdiagramm (igal mudelil võib olla ainult üks kontekstdiagramm);

    lagunemise diagrammid;

    sõlmepuu diagrammid;

    ainult kokkupuutega diagrammid (FEO).

    Kontekstidiagramm on diagrammide puustruktuuri tipp ning kõige üldisem kirjeldus süsteemist ja selle interaktsioonist väliskeskkonnaga.

    Seda protsessi nimetatakse funktsionaalseks lagunemiseks ja diagramme, mis kirjeldavad iga fragmenti ja fragmentide koostoimet, nimetatakse lagunemisdiagrammideks.

    IDEF0 tähistus ja metoodika põhineb "ploki" kontseptsioonil, see tähendab ristkülikul, mis väljendab mõnda ärifunktsiooni. Nagu teate, on ristkülikul neli külge. IDEF0-s on kõigi osapoolte rollid (funktsionaalsed tähendused) erinevad:

    ülemisel poolel on tähendus "kontroll";

    vasak - "sissepääs";

    paremale - "väljapääs";

    madalam - "mehhanism".

    Metoodika ja tähistuse teine ​​element on "voog" (standardis nimega "liidese kaar") - element, mis kirjeldab andmeid, mitteametlikku juhtimist või kõike muud, mis "mõjutab" ploki poolt esindatud funktsiooni. Sõltuvalt sellest, millisele ploki poolele voog suunatakse, nimetatakse seda vastavalt "sisend", "väljund", "juhtimine".

    Ikooniline element, mis tähistab "voogu", on nool.

    Juhtimine - see on see, mis juhib büroo tegevust, selles väljatöötatavas mudelis - need on üksikute PU seadused.

    "Sisend" nooled tutvustavad sisendandmete funktsioone, kontekstidiagrammis on need töötaja isikuandmed.

    Nooled "exit" - väljastavad andmed. Kontekstidiagrammis on see mitmesugune teave, mis esitatakse Vene Föderatsiooni pensionifondile.

    "Mehhanismi" nool on protsesse mõjutavad andmed. Diagrammil on need töötajad ja arvuti.

    Pärast kontekstidiagrammi dekomponeerimist lammutatakse süsteemi iga suur fragment väiksemateks, igale fragmendile antakse nimi ja nii edasi, kuni saavutatakse soovitud kirjeldustase.

    Pärast iga lagunemissessiooni peetakse eksamisessioonid - aineeksperdid näitavad loodud diagrammidele tegelike äriprotsesside vastavust.

    Leitud ebakõlad parandatakse ja alles pärast eksami sooritamist ilma kommentaarideta saate liikuda järgmisele lagunemisseansile. Nii saavutatakse vastavus.

    Kõik skeemi ristmikud on nummerdatud, igal numbril on eesliide J. Ristmiku atribuute saate muuta definitsiooniredaktori dialoogi abil.

    4.2 DFD mudeli koostamise põhimõte

    Andmevoo diagrammid (DFD) on projekteeritava süsteemi funktsionaalsete nõuete modelleerimise peamine vahend. Nende abiga jaotatakse need nõuded funktsionaalseteks komponentideks (protsessideks) ja esitatakse andmevoogudega ühendatud võrguna. peamine eesmärk selliste vahendite eesmärk on näidata, kuidas iga protsess muudab oma sisendid väljunditeks, ja tuvastada nende protsesside vahelisi seoseid.

    DFD-de kujutamiseks kasutatakse traditsiooniliselt kahte erinevat tähistust: Yodan (Yourdon) ja Gane-Sarson (Gane-Sarson). Lisaks kasutatakse näidete koostamisel Yodani tähistust, kõik erandid täpsustatakse eelnevalt.

    See metoodika (Gane/Sarsoni metoodika) põhineb analüüsitava IS-i mudeli konstrueerimisel – kavandatud või tegelikult olemasolevast. Vastavalt metoodikale on süsteemimudel määratletud kui andmevooskeemide (DFD või DFD) hierarhia, mis kirjeldavad teabe asünkroonset teisendamise protsessi alates selle sisestamisest süsteemi kuni selle kasutajale väljastamiseni. Hierarhia ülemiste tasandite skeemid (kontekstidiagrammid) määratlevad IS-i põhiprotsessid või alamsüsteemid väliste sisendite ja väljunditega. Need on üksikasjalikud madalama taseme diagrammide abil. See lagunemine jätkub, luues diagrammide mitmetasandilise hierarhia, kuni saavutatakse lagunemise tase, kus protsessid muutuvad elementaarseks ja neid on võimatu üksikasjalikumalt kirjeldada.

    Infoallikad (välised olemid) genereerivad infovooge (andmevoogusid), mis edastavad informatsiooni alamsüsteemidesse või protsessidesse. Need omakorda muudavad teavet ja genereerivad uusi vooge, mis edastavad teavet teistele protsessidele või alamsüsteemidele, andmesalvestusele või välistele üksustele - teabe tarbijatele. Seega on andmevooskeemide peamised komponendid:

    välised üksused;

    süsteemid/allsüsteemid;

    protsessid;

    andmesalvestusseadmed;

    andmevoogusid.

    4.3 IDEF3 mudeli loomise põhimõte

    IDEF3 saab kasutada ka protsessi loomise meetodina. IDEF3 täiendab IDEFO-t ja sisaldab kõike, mida vajate mudelite loomiseks, mida saab hiljem kasutada simulatsioonianalüüsiks.

    Iga IDEF3 töö kirjeldab äriprotsessi stsenaariumi ja võib olla osa teisest tööst. Kuna stsenaarium kirjeldab mudeli eesmärki ja ulatust, siis on oluline, et teostele viidataks tegevusprotsessi tähistav verbaalne nimisõna või seda nimisõna sisaldav fraas.

    Mudeli vaatenurk peab olema dokumenteeritud. Tavaliselt on see töö kui terviku eest vastutava isiku seisukoht. Samuti on vaja dokumenteerida mudeli eesmärk – küsimused, millele mudel on mõeldud vastama.

    Risttee.Ühe töö lõpetamine võib anda märku mitme töö algusest või üks töö võib oodata mitme töö valmimise algust. Ristteid kasutatakse selleks, et kuvada loogika selle kohta, kuidas nooled ühendamisel ja hargnemisel interakteeruvad, või sündmuste kogumi kuvamiseks, mida saab või tuleb enne järgmise töö alustamist lõpetada. Ristmike tüübid on toodud tabelis:

    Ristmike tüübid

    Määramine Nimi Tähendus noolte ühendamisel (Fan-in Junction)

    Tähendus juhul

    nooleühendused (Fan-out Junction)
    ||& Asünkroonne JA Kõik eelnevad protsessid tuleb lõpule viia Kõik järgmised protsessid peavad töötama
    ||&|| Sünkroonne JA Kõik eelnevad protsessid lõpetati samal ajal Kõik järgmised protsessid töötavad samal ajal
    ||O Asünkroonne VÕI Üks või mitu eelnevat protsessi tuleb lõpetada Üks või mitu järgmistest protsessidest peavad töötama
    ||O|| Sünkroonne VÕI Üks või mitu eelkäija protsessi lõpetati samal ajal Üks või mitu järgmistest protsessidest käivituvad samal ajal
    ||X Ainult üks eelnev protsess on lõpetatud Käivitatakse ainult üks järgmine protsess

    Kõik skeemi ristmikud on nummerdatud, igal numbril on eesliide J. Ristmiku atribuute saate muuta definitsiooniredaktori dialoogi abil. Erinevalt IDEFO-st ja DFD-st saavad IDEF3-s nooled ühineda ja hargneda ainult ristmike kaudu.

    Lingi objekt. IDEF3 lingiobjekt väljendab mõnda ideed, kontseptsiooni või andmeid, mida ei saa seostada noole, ristmiku või tööga. Lingiobjekti lisamiseks kasutage |R| – (lisage diagrammile võrdlusobjekt - Referent) tööriistapaletis. Lingiobjekt joonistatakse töö ristkülikuga sarnase ristkülikuna. Võrdlusobjekti nimi määratakse Referentsi dialoogis (nimeredaktori hüpikmenüü element), nimena saab kasutada mõne muu diagrammi noole nime või andmemudeli olemi nime. Võrdlusobjektid peavad olema punktiirjoontega seotud tööüksuste või ristumiskohtadega. Ametlik IDEF3 spetsifikatsioon eristab kolme võrdlusobjekti stiili: tingimusteta, sünkroonne ja asünkroonne. BPwin toetab ainult tingimusteta lingiobjekte. Objekti oleku ülemineku diagrammides kasutatavaid sünkroonseid ja asünkroonseid võrdlusobjekte ei toetata.

    5. Simulatsioon

    5.1 Kasvuhoone mudel

    Mudelinavigaator – mudeliuurija

    Konteksti skeem:

    A0 lagunemise diagramm:

    Lagunemisskeem A1:

    Diagramm IDEF3 A11.1:

    Andmevoo diagramm A12:

    Lagunemisskeem A2:

    IDEF3 A21.1 diagramm:

    Lagunemisskeem A3:

    A4 lagunemisskeem:

    Lagunemisskeem A5:

    Lagunemisskeem A6:

    A63 andmevoo skeem:

    5.2 Matemaatiline mudel

    Lisateabe saamiseks Täpsem kirjeldus Kasvuhoonemajanduse töö puhul on vaja koostada ettevõtte tegevusprodukti matemaatiline mudel.

    See matemaatiline mudel kirjeldab kaubaühiku hinna arvutamist erinevates tingimustes.

    e - kaubaühiku maksumus, mille määrab tootja, see sisaldab kõiki kaubaühiku valmistamisega seotud kulusid, põhiosa sellest näitajast moodustab seemnete ostuhind;

    v - seemnete ostuhind, see on hind, millega ettevõte ostis tarnijalt seemneid (jaotis "seemnete ostmine");

    a - tööjõukulu palk ja muud ettevõttesisesed kulud);

    g - kütused ja määrdeained (kütus ja määrdeained);

    n - maksud (tarbija osa) kehtestab riik ja on fikseeritud määraga;

    k - käibemaks, käibemaks, samuti fikseeritud määraga;

    r - jaehind, see on rahasumma, mille eest tootja müüb turul ühiku oma toodet, reeglina määrab jaehinna omahind teatud protsendiga juurdehindlusest;

    s - ettevõtte juurdehindlus kaubaühiku kohta, reeglina määrab iga ettevõtja selle summa individuaalselt, sel juhul on see 40% maksumusest, s.o (e * 40) / 100

    o - hulgimüügihind, see on pakutav rahasumma kaubaühiku kohta, ostes alates 100 ühikust, on sel juhul 10% allahindlus jaehinnast;

    os – allahindlus hulgiostmisel (os

    Matemaatiline mudel toodetud kaubaühiku maksumuse arvutamiseks:

    Matemaatiline mudel valmistatud kauba ühiku jaehinna arvutamiseks:

    Matemaatiline mudel toodetud kauba ühiku hulgimüügihinna arvutamiseks:

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

    o=r - (r*10)/100

    Ettevõttes "Kasvuhoonemajandus" toodete maksumuse arvutab raamatupidamine, mis kontrollib dokumendivoogu, võtab arvesse ettevõtte tulusid ja kulusid, peab raamatupidamisraamatuid ja väljastab tõendeid. Nende ettevõtte matemaatilises mudelis saadud valemite alusel saab raamatupidaja arvutada kaupade hinna nii jae- kui hulgimüügis.

    6. Võrdlusuuringud

    Oma ettevõtte modelleerimiseks kasutasime 5 metoodikat: Dragon, UML, IDEF0, IDEF3, DFD. Meie hinnangul on UML-i metoodika parim viis meie ettevõtte mudeli esitlemiseks, kuna see kajastab selgemalt ja täpsemalt kasvuhoonetööstuse põhiaspekte.

    UML-diagramme on suhteliselt lihtne lugeda.

    Näiteks skeem "Kasutusjuhtum", mida kasutati kasvuhoone juurutussüsteemi disainimise tulemusena, võimaldab kliendil, lõppkasutajal ja arendajal koos arutada süsteemi funktsionaalsuse ja käitumise üle. "Klassiskeem" võimaldab teil kirjeldada süsteemi struktuuri, see näitab süsteemi klasse, nende atribuute, meetodeid ja klassidevahelisi sõltuvusi, mis võib üksikasjalikult paljastada ettevõtte stsenaariumi ja korralduse.

    Dragon metoodika on samuti väga selge ülesehitusega, kuid ei oma nii laialdasi võimalusi erinevate süsteemide modelleerimiseks.

    Visio on lihtsaim ja ligipääsetavaim protsesside modelleerimise tööriist. Sellel tootel on standardne, kõigile MS Office'i stiilis juhtpaneelidele tuttav ja hõlpsasti integreeritav selle paketi mis tahes rakendusega, mis teeb sellega töötamise kogenematute kasutajate jaoks lihtsamaks. Aja- või kuluanalüüs nõuab aga aruannete väljatöötamist, mis raskendab oluliselt selle toote kasutamist. Tüüpilistest aruannetest äriprotsesside analüüsimiseks ilmselgelt ei piisa. Vaatamata sellele on Visio levinud tööriist äriprotsesside kirjeldamiseks nii Venemaal kui ka välismaal. Visio toetab äriprotsesside kirjeldamiseks IDEF- ja UML-vorminguid. Samuti on võimalik vorminguid iseseisvalt välja töötada.

    BPWIN - asub vahepealsel kohal, eristub oma lihtsuse ja suurepäraste analüüsivõimaluste poolest. BPWIN-i funktsionaalsus ei ole ainult diagrammide joonistamine, vaid ka mudeli terviklikkuse ja järjepidevuse kontrollimine. BPWIN annab loogilise selguse diagrammi elementide määratlemisel ja kirjeldamisel, samuti diagrammide vaheliste seoste terviklikkuse kontrolli. Tööriist võimaldab parandada enamlevinud vigu modelleerimisel. Lisaks toetab BPWIN kohandatud atribuute, mida rakendatakse diagrammielementidele, et kirjeldada selle elemendi spetsiifilisi omadusi. Selle süsteemi peamiseks piiranguks on selle aluseks olev IDEF-standard, mille puhul on mudelite ehitamisel ranged piirangud. See lihtsustab lihtsate protseduuride kirjeldamise ülesannet, kuid raskendab suurte protsesside kirjeldamist. 1DEF-skeemid hakkavad keeruliste protsesside kirjeldamisel esitama lugematul hulgal omavahel seotud skeeme, mis on välimuselt väga sarnased, mistõttu protsessi kui terviku mõistmine on keeruline.

    7. Järeldus:

    Selle kursusetöö käigus said kõik meie eesmärgid täidetud.

    Sellega seoses uurisime arendatavat ainevaldkonda, nimelt kasvuhoonetööstuse tööd. Selleks oli vaja mõista selle valdkonna terminoloogiat, koguda kokku vajalikud normatiiv- ja juriidilised dokumendid, uurida meie ettevõtte dokumentide näidiseid ning jälgida nende liikumist nii ettevõtte sees kui ka väljaspool seda.

    Nende sündmuste tulemusena saadi informatsioon, mille põhjal viidi läbi esialgne analüüs ja koostati projekteeritava mudeli skeem.

    Järgmine arendusetapp on projekteerimise etapp. Enne projekteerimise ja juurutamise alustamist peab teil olema täpne ja üksikasjalik arusaam nõuetest kõrgel tasemel. Lisaks on väga kasulik omada nõuete struktuuri, mida saab kasutada süsteemi moodustamisel sisendina. Kõik see saavutatakse analüüsi ja modelleerimisega. Analüüsi ja modelleerimisega saavutasime ülesannete lahususe, mille projektieelses olekus valmistasime ette ja lihtsustasime järgnevateks projekteerimis- ja teostustegevusteks. Teeme vahet probleemidel, mida tuleb lahendada, ja otsuseid, mida tuleb teha, et nendega toime tulla.

    Modelleerimise ja projekteerimise etapis tehtud töö tulemusena saime süsteemiprojekti, mis sisaldas selle rakendamiseks piisavalt teavet.

    Kasvuhoonetööstuse töö analüüsimise järel saame hinnata iga osakonna töökoormuse määra, mida ja milliste vahenditega on vaja eelkõige automatiseerida.

    Töö hõlbustamiseks on võimalik juurutada uusi tehnoloogiaid, mis hõlbustavad tööd meie farmis.

    Kirjandus:

    Rogozov Yu.I., Stukotiy L.N., Sviridov A.S. "Süsteemide modelleerimine" TRTU, 2004.

    S.V. Maklakov “CASE-tööriistad infosüsteemide arendamiseks. BPwin ja Erwin "-M.: DialogMifi, 2001.

    Maklakov S. "Struktuurse ja objektilise lähenemisviisi kombineerimine uue põlvkonna Computer Associates CASE tööriistades" // Koolitus- ja konsultatsioonikeskus. 2002.

    Üks pilt on väärt tuhat sõna

    rahvatarkus

    Loomulikult peaks teoreetiliselt juhil olema ettevõtte töö funktsionaalne mudel ja pole vahet, kas räägime lao või IT-süsteemi korraldusest (vihtest päringuni). Kuid tegelikkuses ei selgu see peaaegu kunagi ja seetõttu koostan kliendi püstitatud ülesandele uurimise ja lahenduse otsimise käigus ka ettevõtte funktsionaalse mudeli või teatud protsessi (funktsiooni) Minu enda.

    Paar sõna graafika eeliste kohta

    Nagu teate, on IDEF0 funktsionaalsed mudelid alati graafilised diagrammid. Neil on oma omadused ja koostamise reeglid. Sellest räägime veidi hiljem. Ja nüüd tahaksin tuua paar näidet graafika efektiivsusest. Miks ma sellele keskendun? Tõenäoliselt arvasid paljud inimesed pärast minu väidet ettevõtte töö funktsionaalse mudeli vajaduse kohta, et see pole vajalik, ja oli võimalik sõnadega selgitada, kuidas see või teine ​​funktsioon ettevõttes töötab. Sellest tahan ma rääkida.

    Ja alustuseks teeme väikese kõrvalepõike ajalukku. Tuleme tagasi kaugesse 1877. aastasse, Vene-Türgi sõja ajal. Just siis kasutas printer Sytin esimest korda sõjaliste operatsioonide kirjeldamisel graafikat. Nüüd on see kõik meile tuttav, mis tahes lahingut kirjeldades ilmuvad meie silme ette nooltega kaardid, mis näitavad selgelt lahingu kulgu. Ja neil päevil kirjeldati sõjalisi operatsioone sõnadega. Iga võitluse jaoks - palju, palju sõnu. Ja väga raske oli lõpuks aru saada, mis toimub.

    Seetõttu oli Sytini idee tõeliselt revolutsiooniline – ta hakkas trükkima kaartide litograafilisi koopiaid, millel olid märgitud kaitserajatised ja sõjaväeosade asukohad. Need kaardid kandsid nimetust „Ajalehelugejatele. Kasu". Idee osutus nii aktuaalseks, et "Abi" esimene tiraaž müüdi silmapilkselt läbi. Ja siis oli selliste rakenduste järele suur nõudlus. Põhjus on ilmne. Graafika aitas mõista seda, mida oli peaaegu võimatu välja mõelda ainult sõnade abil.

    Sarnase näite verbaalsete kirjelduste abitusest võin tuua ka enda praktikast. Üks mu klient palus mul võtta enda peale ERM-i süsteemi juurutamine tema ettevõttes. Kui küsisin, kas neil on mingi tehniline ülesanne, sain vastuseks: “Jah, on küll. Kuid sellel on 400 lehekülge. Samas kurtis klient väga, et minu kolleegid, kellega ta varem ühendust võttis, kas keeldusid projektist üldse või nimetasid selgelt paisutatud hindu. Pärast seda, kui nägin, et lähteülesanne oli tõepoolest 400 lehekülge pikk ja koosnes ainult tekstilisest kirjeldusest, sain aru arendajate käitumise põhjustest. Sellise tekstimahu lugemine, sellesse süvenemine, kõikidest nüanssidest aru saamine ainuüksi ülesande mõistmiseks ja hinna nimetamiseks on tõesti väga raske.

    Pakkusin sellele kliendile alternatiivse võimaluse - kirjeldada kõike, mis võimalik, graafiliselt märgete kujul. Näitas talle modellitöö näiteid. Seetõttu mõtlevad nad nüüd oma soovid ja lähteülesande kujunduse ümber.

    Tean ka palju muid näiteid, kui äriprotsesside graafiline modelleerimine aitas nii minu kolleege, ärikonsultante ja arendajaid kui ka ärimehi endid

    Miks see minu töö jaoks oluline on?

    Minu töö on alati seotud olemasolevas süsteemis muudatuste tegemisega. Ja selleks, et teha muudatusi ja saada soovitud tulemust, tuleb uurida, mis on juba olemas. Ja pole vahet, mida me täpselt teeme – seadistame või paigaldame CRM-süsteemi nullist, loome tõhusa ERP-süsteemi, integreerime erinevaid süsteeme, et suurendada töö automatiseerimist üldiselt. Igal juhul on alustuseks vaja saada ettekujutus olemasolevast tööskeemist ja alles pärast seda on võimalik välja pakkuda mõned muudatused ja mõelda ülesande lahendamise võimalustele.

    Pärast asjade hetkeseisuga tutvumist koostan nagu iga teine ​​​​kolmanda osa spetsialist ärilise ettepaneku, milles avaldan võimalikult üksikasjalikult oma nägemuse hetkeolukorrast ja toimingutest, mida tuleb teha lahendada ülesanne ja loomulikult oodatav tulemus.

    Sellised tööülevaate aruanded on mahukad, hõivates rohkem kui ühe lehekülje, mis ühest küljest on vajalik, kuid teisalt raskendab tajumist. Alguses, nagu paljud teised, arvasin, et mahukad aruanded on head, sest inimene maksab töö eest ja sa pead talle andma võimalikult üksikasjalikku teavet.

    Tegelikult on oluline mitte anda volüümi, vaid anda olemus võimalikult kiiresti ja täielikult edasi. Suured tekstimahud nõuavad aega, mida ärimeestel on sageli väga vähe. Ja graafika võimaldab mul oma ettepaneku mahtu vähendada ja selgelt, arusaadaval kujul näidata lahendust. Selle tulemusena vähenesid minu ettepanekud oluliselt, neisse ilmus graafika ja koostöö alustamise otsuseid hakati kiiremini vastu võtma.

    Sel põhjusel kasutan visuaalseid mudeleid. Nagu teate, on üks pilt väärt tuhat sõna. Ja äriprotsesside ja ettevõtte töö kaasajastamise võimaluste kirjeldamise puhul on see tõsi. Ja IDEF0 tähistused sobivad siia väga hästi.

    Kuid kõigepealt mõistame põhimõisteid, mis on tähistused, miks neid vaja on, mis on IDEF0, millised on selle meetodi omadused ja eelised.

    Mis on äriprotsesside kirjelduse märge

    Märkus on äriprotsessi kirjeldamise formaat, mis kujutab endast modelleerimisel kasutatavate graafiliste objektide ja modelleerimisreeglite kogumit.

    Tegelikult on notatsioonid spetsiaalne graafiline keel, mis võimaldab kirjeldada ettevõtte tööd, visuaalselt demonstreerida erinevate osakondade omavahelist suhtlust, s.t. kirjeldada äriprotsesse. Märgistusi saab kasutada protsesside või funktsionaalse modelleerimise jaoks.

    Üldiselt võib tähistusi ärianalüüsis nimetada programmeerimiskeeleks.

    Mis on IDEF0?

    IDEF0 on funktsionaalse modelleerimise metoodika ja graafiline tähistus, mis on loodud äriprotsesside vormistamiseks ja kirjeldamiseks. IDEF0 eripäraks on selle rõhuasetus objektide alluvusele. IDEF0 arvestab tööde vahelisi loogilisi seoseid, mitte nende ajalist järjestust (töövoogu). Vikipeedia

    IDEF0 standardi töötas 1981. aastal välja USA õhujõudude osakond tööstusautomaatika jaoks. Tarkvaraarenduse käigus seisavad arendajad silmitsi vajadusega töötada välja uued meetodid äriprotsesside analüüsimiseks. Selle tulemusena ilmus IDEF0 funktsionaalse modelleerimise metoodika, milles analüüsimiseks kasutatakse spetsiaalseid IDEF0 tähistusi.

    Ettevõtte funktsionaalne mudel

    IDEF0 funktsionaalne mudel on plokkide komplekt, millest igaüks on "must kast", mille sisendid ja väljundid, juhtelemendid ja mehhanismid on üksikasjalikult (dekomponeeritud) vajalikul tasemel. Kõige olulisem funktsioon asub vasakus ülanurgas. Ja funktsioonid on omavahel ühendatud noolte ja funktsionaalplokkide kirjelduste abil. Pealegi on igal nooletüübil või tegevusel oma tähendus. See mudel võimaldab kirjeldada kõiki peamisi protsesse, nii haldus- kui ka organisatsioonilisi.

    Nooled võivad olla:

    • Postkast - sissejuhatav, mis seab konkreetse ülesande.
    • Väljuv – tegevuse tulemuse kuvamine.
    • Juhid (ülevalt alla) - juhtimismehhanismid (positsioonid, juhised jne).
    • Mehhanismid (alt üles) – mida kasutatakse vajaliku töö tegemiseks.

    Sissetulevaid ja väljuvaid nooli oleks täpsem nimetada sisendiks ja väljundiks, kuna inglise keeles nimetatakse neid vastavalt Input ja Output. Kuid tõlke omadused ja tavalised nimed näevad juba välja sellised, nagu neil on. Ja siiski, mõistete õigeks mõistmiseks on oluline nende tähendust sel juhul meeles pidada. Seda kinnitab ka tõsiasi, et see tähistus on loodud eelkõige tarkvaraarenduse tarbeks ning õigem on termineid sellest vaatenurgast tõlkida.

    Nooltele märgitakse nimisõnu (kogemus, plaan, reeglid) ja plokke verbide abil, st. need kirjeldavad tehtavaid toiminguid (toote loomine, lepingu sõlmimine, saadetise koostamine).

    IDEF0 on väga lihtne ja samas visuaalne keel äriprotsesside kirjeldamiseks. Selle standardi abil on võimalik info edastamine arendajate, konsultantide ja kasutajate vahel. Standard töötati välja väga hoolikalt, see on disaini jaoks mugav, universaalne. Sellega töötamiseks on palju tööriistu, näiteks VISIO, BPWIN, ERWIN, Bussines studio jne.

    Lisaks pole IDEF0 kasutamine ärimudelite loomiseks mitte ainult mugav, vaid ka õige. See tööriist on loodud äriteabe jaoks, see on läbinud pika ja põhjaliku silumise ja poleerimise. Seetõttu on IDEF0 kasutamine funktsionaalse mudeli loomiseks ilma vigadeta palju lihtsam kui seda standardit kasutamata.

    Nagu teate, on kõige parem naelu haamriga lüüa. Muidugi võib selleks kasutada ka muid tööriistu, aga haamer on kõige funktsionaalsem ja sellega on kõige lihtsam naela korralikult ja täpselt kokku lüüa. Nii et IDEF0 kasutamisega - see tööriist loodi funktsionaalseks modelleerimiseks ja selle abil saate soovitud tulemuse palju kiiremini ja täpsemalt.

    Näide IDEF0 funktsionaalse mudeli loomisest

    Funktsionaalse modelleerimisega töötamise mõistmiseks toon näite artikli kirjutamise protsessist.

    Peamine plokk on "Kirjutage artikkel".

    Sissetulevad nooled - "Kogemus", "Teave kolmandate osapoolte allikatest". Need on sisendid, mida vajate alustamiseks.

    Artikli kirjutamise juhendid on “Avaldamisplaan”, “Nõuded väljaandjale”, “Vene keele reeglid”.

    Ja "Mehhanismide" rollis on autor, copywriter, korrektor ja tarkvara. Sel juhul loob autor helimaterjali, kuhu kogub kõik mõtted ja ideed, mis peaksid artiklis kajastuma. Copywriter on isik, kes loob selle materjali põhjal, juhindudes väljaandja nõuetest, avaldamisplaanist ja vene keele reeglitest, artikli valmisteksti. Korrektor kontrollib materjali vigade suhtes. Ja tarkvara on tööriistad, mida kõik protsessis osalejad oma töös kasutavad.

    Seega panin paika nii protsessi põhiparameetrid, selle sisendi, väljundi kui ka kõik vajaliku protsessi edukaks elluviimiseks. Kuid see on ainult protsessi põhiraamistik. See kirjeldab ettevõtte üldist skeemi tervikuna.

    Tegelikult saab ja peaks artikli loomise protsess, nagu iga äriprotsess, olema üksikasjalik. Selleks lagundan üldise “kirjuta artikkel” ploki omavahel seotud elementideks.

    Meie puhul on töö jagatud 4 põhietappi:

    1. Valmistage heli ette.
    2. Valmistage tekst ette
    3. Valmistage tekst ette avaldamiseks.
    4. Asetage artikkel väljaandesse.

    Diagramm näitab selgelt, millises etapis millised juhtelemendid ja mehhanismid on seotud.

    Seega kasutab autor heli loomisel oma teadmisi ja kogemusi, juhindudes samas avaldamisplaanist ja kirjastuse nõuetest. Copywriter saab sisendiks helisalvestise, millest ta vene keele reeglitest juhindudes teksti loob. Korrektor võtab teksti vastu ja kontrollib seda, juhindudes ka vene keele reeglitest. Artikli väljaandesse paigutamiseks on vaja spetsiaalset tarkvara.

    Funktsionaalse mudeli loomisel on võtmeparameetriteks eesmärk ja vaatenurk. Nende põhjal võib samade protsesside modelleerimine näida mõnevõrra erinev. Näiteks minu puhul on eesmärk "rääkida artikli kirjutamise protsessist". Ja copywriteri vaatenurk on "artikli kirjutamine ja avaldamine protsessijuhi vaatenurgast".

    Seega, kui sama protsessi kirjeldataks copywriteri vaatevinklist, siis oleks sisendiks kogemus ja helifail autorilt. Pealegi tähendaks kogemus antud juhul copywriteri, aga mitte juhi ega autori kogemust. Seetõttu tuleb äriprotsessi mudeli loomisel esimese asjana kindlaks määrata vaatenurk ja selgelt sõnastada eesmärk.

    Selline modelleerimine pole mitte ainult visuaalne, vaid ka väga mugav tõhusate juhtimisotsuste tegemiseks. Näiteks ülalkirjeldatud äriprotsessis on kaks eraldi spetsialisti – copywriter ja korrektor. Kui seadsin ülesandeks projektide finantseerimise optimeerimise, siis tänu skeemile näen kohe, kus see on ja kuidas saab. Niisiis kasutavad tekstikirjutaja ja korrektor ligikaudu samu reegleid, kuid tekstikirjutaja võtab vastu heli ja annab tulemuse teksti kujul, korrektor aga nii aktsepteerib kui annab teksti. Ja seetõttu võin vajadusel, ütleme, poole korrektori töökulude eest pakkuda tekstikirjutajat. Nii hoian kokku raha ja aega erinevate spetsialistide suhtlemisel. Muidugi mõistan kõiki korrektorite eeliseid ja seda, miks on parem teha koostööd üksikute spetsialistidega. Kuid tuletan teile meelde, et mul on ülesanne: kulude optimeerimine.

    Ilma sellise visuaalse tööriistata oleks keerulisem kindlaks teha, milliseid plokke saab eemaldada ja seeläbi tööd optimeerida.

    Kuidas luua IDEF0 tähistusi

    Märkmete loomiseks saab kasutada palju erinevaid tarkvaratooteid. Mõned on mõeldud spetsiaalselt funktsionaalseks modelleerimiseks, teised on mõeldud mis tahes graafiliste elementidega tööks. See, kus ja kuidas neid mudeleid ehitada, on teie otsustada.

    Ma ise arvan, et esimesel etapil pole midagi paremat kui tavaline paber, lihtne pliiats ja kustutuskumm, mida vigade korral kohandada.

    Selleks, et luua märge olemasolevatele äriprotsessidele, s.o. kirjeldamaks, kuidas ettevõte praegu töötab, on vaja uurida tööpõhimõtteid. Kolmanda osapoole spetsialist (konsultant, arendaja) viib selleks läbi intervjuu. Esimeses etapis vastab küsimustele ettevõtte juht, seejärel viiakse märkuse täpsustamise käigus läbi intervjuud erinevate tööetappide eest vastutavate töötajatega.

    Oluline on mõista, et selle tulemusena on vaja 2 märget. Esimene kuvab äriprotsesse nii, nagu need on. Lood selle intervjuu põhjal ning kooskõlastad iga detaili ettevõtte töötajate ja juhiga. On väga oluline, et teie nägemus olemasolevatest protsessidest ühtiks tegelikkusega ja see nõuab kinnitust kõigil tasanditel.

    Teine märge on "nagu peab". See luuakse esimeste ja nende muudatuste põhjal, mida pakute töö struktuuris teha, et optimeerida ja automatiseerida ettevõtte tööd ülesande osana.

    IDEF0 nõuded

    IDEF0 standardi põhinõudeid kirjeldasin põhimõtteliselt eespool ja näitasin näitega.

    1. Ülemises vasakus nurgas on alati peamine element.
    2. Kõigil elementidel peavad olema sissetulevad ja väljuvad nooled, kuna täitmiseks on vaja midagi sisendis (tellimus, ülesanne) vastu võtta ja pärast väljundis töötlemist on vaja valmistoode üle kanda. Sissetulevad nooled on alati vasakul, väljaminevad nooled on alati paremal.
    3. Eespool on juhtelemendid, allpool on protsessi lõpuleviimiseks vajalikud mehhanismid.
    4. Kui ühel lehel (ekraanil) on mitu plokki, asub iga järgmine plokk eelmisest paremal ja all.
    5. Tuleb püüda luua skeeme nii, et noolte ristumiskoht väheneks vajaliku miinimumini.

    Levinud vead

    Funktsionaalne modelleerimine viiakse läbi mitmesuguste vahenditega, sealhulgas nendega, mis ei ole modelleerimiseks ette nähtud. Viimasel juhul ei kontrollita vigu ja standardi piiranguid. Nähtavuse suurendamise soov ja kogemuste puudumine lõppevad sageli vigadega.

    Erinevate värvide kasutamine

    Kõik diagrammi elemendid on võrdselt olulised. Funktsionaalses modelleerimises ei ole enam ega vähem olulisi elemente. Nende kadumine põhjustab protsessi katkemise ja tootmisdefekti.

    Sageli paberil või erinevates programmides modelleerides püüavad kasutajad erinevate värvide abil nähtavust suurendada. See on üks levinumaid vigu. Tegelikult tekitab mitmevärviliste noolte ja klotside kasutamine ainult täiendavat segadust ja moonutab ka skeemi tajumist.

    Teie mudel peaks olema must-valgelt loetav ilma täiendavate värviskeemideta. Selline lähenemine aitab ühtaegu vältida arusaamatusi ja distsiplineerib mudeli loojat, mille tulemusena suureneb mudeli loetavus ja kirjaoskus.

    Liiga palju plokke

    Mudeli koostamisel püütakse sageli ühel lehel kuvada kõik ettevõtte töö nüansid koos kõigi detailidega. Tulemuseks on väga suur hulk plokke suure hulga juhtnooltega. Loetavus on kadunud.

    Parim valik on probleemi mõistmiseks piisavalt üksikasjalik teave ja mitte midagi muud. Iga osakonna või isegi töötaja töö üksikasjad võivad ilmneda konkreetse protsessi üksikasjaliku vaate valimisel. Ja selline struktuur luuakse ainult siis, kui see on tööks või otsustamiseks tõesti vajalik.

    Konstruktsiooni rikkumine kohanduste tegemisel

    Jälgige hoolikalt, et vältida segadust või protsesse ilma sissetulevate, väljaminevate ja muude oluliste elementideta. Näiteks kui ülaltoodud näite puhul pean sobivaks nihutada vaatenurk copywriterile, eemaldan autori skeemist. Ja siis muutuvad tarbetuks kontrollid "autori ja kolmandate osapoolte allikate kogemus", samuti avaldamisplaan. Autor ju kasutab neid. Copywriter töötab helifailiga. Ja kui need jäävad üldskeemi, siis viivad detailides arusaamatult kuhu ja tekitavad segadust.

    Samuti, kui otsustan ploki lisada, on oluline veenduda, et sellel on ka kõik nõutavad atribuudid. Ettevaatlikkus on siinkohal väga oluline, sest keerukate äriprotsesside modelleerimisel võivad muudatused ühes mudeli osas kaasa tuua muutusi teises. Need tuleb sisestada.

    Juhtelementide ja plokkide nimetamise reeglid

    Oluline on meeles pidada lihtsat reeglit: juhtnooli nimetatakse nimisõnadeks, plokke tegusõnadeks. See on IDEF0 standardis aktsepteeritud ning see lähenemine aitab vältida segadust ja vigu.

    Kõige sagedamini tehakse vigu plokkide nimetamisel. Näiteks kirjutavad nad sõna "Loo artikkel" asemel "Loo artikkel". Selle lähenemisviisi puhul on plokid tegevused ja seetõttu peaksid need alati olema tegusõnad.

    IDEF0 kasutamise eelised

    • Kõige esimene eelis on ilmne – see on nähtavus. Hakkate ise mõistma, kuidas see või teine ​​süsteem töötab, ja saate ka selgelt selgitada, kus selles süsteemis on "õhukesed kohad" ja kuidas teie lahendused aitavad neist lahti saada.
    • Vastastikune mõistmine ja lahkarvamuste puudumine. Funktsionaalmudelit kasutava ettevõtte töö arutamisel on teil visuaalsed ja intuitiivsed juhtelementidega ülesandeplokid. Lisaks hõlmab funktsionaalne modelleerimine vajadusel sõnastiku loomist, milles kuvatakse sümbolid ja terminid. Seetõttu räägite probleemi arutamisel sama keelt nii teie kui teie klient, juht ja teised töötajad.
    • Mudeli loomise lihtsus ja suur kiirus. Muidugi pole modellinduse õppimine nii lihtne, kui tundub. Skeem on ju tegelikult ülitihe info esitlus, millest on väga hea aru saada, kuid sellise esitluse rakendamiseks on vaja erilist lähenemist. Analüütiku aju toimib sel juhul ühelt poolt väga võimsa pressina ja teiselt poolt filtrina. Kuid kogemustega muutub see protsess väga kiireks. Selle tulemusena saate tööriista, mis aitab teil ise aru saada, mis konkreetses süsteemis toimub, ning lühikese ajaga loodud visuaalse abivahendi abil illustreerida olulisi punkte kolleegidele või klientidele.
    • Distsipliin ja ilma vigadeta. IDEF0 standard eeldab rangeid raamistikke ja reegleid. Selline lähenemine distsiplineerib ning harjumus tegutseda standardi raames aitab vältida tähelepanematusest tulenevaid vigu. Igasugune standardi rikkumine on koheselt märgatav.

    Mis on IDEF0 kasutamise raskus

    Oluline on mõista, et ainult kõige lihtsamatel juhtudel loovad kaks ärianalüütikut ettevõtte töö kirjeldamiseks täpselt samad funktsionaalsed mudelid. Iga mudel peegeldab analüütiku kogemust, selle ettevõtte mõistmise sügavust, mida ta soovib kirjeldada, ja mingil moel ka tema isiklikku seisukohta selle ettevõtte kohta. Need. inimene arendab ärimudelit juhi vaatenurgast, justkui oleks ta juht.

    Samas usun, et ärianalüütik pole päris elukutse, ärianalüütikaga tegeleb iga ärijuht või mõne süsteemi arendaja, kes analüüsib äri ja püüab üles ehitada võimalikult efektiivset süsteemi. IDEF0 tööriist on mõeldud just neile inimestele ja nendel eesmärkidel.

    Seetõttu on väga oluline funktsionaalse ärimudeli "nagu on" koostamisel pidevalt konsulteerida ettevõtte juhiga, et mitte teha vigu, mis lagunemisetappides automaatselt kaasa toovad vigu. Samuti võidakse järgmistel etappidel nõuda täiendavaid kooskõlastusi struktuuriüksuste juhtidelt ja töötajatelt. Ainult siis, kui teie funktsionaalne mudel "nagu on", peegeldab tõesti asjade tegelikku seisu, saate teha mõningaid muudatusi ja soovitusi. Ja sellises töös kvaliteetsete tulemuste saavutamiseks on kõigepealt vaja praktilisi kogemusi ja teadmisi konkreetset tüüpi ettevõtte omadustest.

    Lihtsaim ja kiireim viis diagrammide loomiseks idef0 ja idef3 graafiliste tähiste abil on kasutada diagrammide, vooskeemide, võrgudiagrammide, UML-diagrammide ja muude kurjade vaimude jaoks vabalt levitatavat platvormidevahelist redaktorit nimega "Dia". Programm on tõlgitud paljudesse keeltesse, sealhulgas vene keelde.

    Programmi saate alla laadida selle ametlikult veebisaidilt: http://projects.gnome.org/dia/. Selle kirjutamise ajal oli Dia programmi uusim versioon 0.97.1 – ja see on olnud nii peaaegu kaks aastat. Sellest hoolimata on rakenduse funktsionaalsus suurepärane.

    IDEF0 diagrammide ehitamine

    diagrammide loomiseks graafilises tähistuses idef0 piisab, kui valida Dia elementide standardteegi nimega "SADT / IDEF0":

    Kui puutute kokku esimest korda idef0-ga, soovitan teil esmalt lugeda seda metoodikat käsitlevad artiklid:

    1. Kaasaegsed metoodikad äriprotsesside kirjeldamiseks. IDEF0 metoodika – Kovaljov Valeri Mihhailovitš (ajakiri "Consultant Director", nr 12, juuni 2004)
    2. IDEF0 kui protsessi modelleerimise tööriist – Andrey Dvornikov (Avant Partner Magazine, nr 22(79), august 2005)
    3. IDEF0 standardi kasutamise kogemus - Sergei Rubtsov

    IDEF3 diagrammide ehitamine

    Idef3 puhul on see natuke keerulisem. Dia ei paku idef3 graafilises tähises diagrammi koostamiseks standardset elementide komplekti, kuid programmis on olemas kõik vajalikud plokid. Need tuleb lihtsalt käsitsi rühmitada. Selleks klõpsake menüüs: "Fail -> kategooriad ja objektid". Avanevas aknas klõpsake nuppu "Loo". Avaneb teine ​​aken, kus valime üksuse "Kategooria nimi" ja sisestame sinna "idef3". Kategooria loomise protsess näeb välja umbes selline:

    Kuna lõite just selle kategooria, on see loomulikult tühi. Peame sellesse teisaldama skeemide vajalikud elemendid. Sellepärast:


    Klõpsake nuppu "Rakenda", "Sulge" aken ja oletegi valmis! Läheme "muud elementide teegid" ja valime seal meie poolt loodud graafilise märge "idef3" (see asub tähestikulises järjekorras). Muide, plokkidena kirjutamiseks on mugav kasutada klahvi F2. Loomulikult pole see täiuslik tööriist, kuid see meetod võimaldab luua IDEF3 diagramme, mis on võimalikult lähedal nende täpsele graafilisele tähistusele.

    Kui teate muid tasuta IDEF3 graafilisi diagrammitööriistu, siis jagage seda kõigiga kommentaarides.


    IDEF0 rakendamise töötuba CAD-tarkvara funktsionaalkirjelduse jaoks

    IDEF0 rakendamise töötuba tarkvara funktsionaalseks kirjeldamiseks
    1. osa.

    Kui analüüsida tarkvaraarendusega tegelevate firmade töötajate palkamise kuulutusi, siis viimasel ajal on tekkinud terav puudus projektijuhtidest, kes oskaksid asjatundlikult ülesandeid paika panna. Probleem ei ole selles, et nad ei oska probleemi sõnastada, vaid selles, et nad ei suuda dokumentatsiooni korralikult dokumenteerida, võttes arvesse tänapäevaseid projekteerimisstandardeid. Klient jubaei piisa, kui anda paar Wordis trükitud lehte. Ta soovib dokumentatsiooni, mis on kujundatud BPWinis, ErWinis, S-Designeris, Power Designeris, Rational Rose'is jne. Kõigi nende CASE-tööriistade taga on standard. See artikkel on pühendatud ühele neist - IDEF0.

    Sissejuhatus. Iga projektijuht peab dokumentatsiooni koostamisel "au-asjaks" välja mõelda midagi "oma" – oma ideede esitlemise "superformaati". Projektide keerukus kasvab, projekti dokumentatsiooni maht kasvab, dokumentatsioon läheb töögrupist kaugemale ... ja siis selgub, et dokumentatsioon ei sobi tellijale ega projekti lõpetavale arendajate grupile ja selle säilitamine.

    Tavaliselt on projektijuhiks kas klassi programmeerija (teema – projekti juhtprogrammeerija) või isik, kes valdab hästi võõrkeelt ja tunneb programmeerimist. Need on peamised valikukriteeriumid projektijuhi ametikohale. See on probleemi juur. Võite olla suurepärane programmeerija või lihtsalt hea töötaja, kuid sellel pole dokumentatsiooniga mingit pistmist.

    Tavaliselt taandub iga halduritüübi spetsifikatsioon kas programmi enda mudeli kirjelduseks (moodulite arhitektuur, klassid, DLL, andmebaasi struktuur ja selle kasutamine jne) või kasutaja funktsioonide kirjelduseni (mida need teevad). peaks tegema, millised vormid peaksid programmis olema jne).

    Ideaalne variant on siis, kui klient seab ülesande. Sel juhul saab elada põhimõttel "klient tahab" ja kuni ta on rahul, saate kliendilt raha. Kuid üha rohkem projekte luuakse iga organisatsiooni sügavuses ja pakutakse seejärel kliendile. Ja sel juhul tuleb esiplaanile dokumentatsiooni kvaliteet, mida olete teinud ja mida kavatsete teha. Dokumentatsioon on sel juhul kõik ...

    IDEF0 (Integrated Definition Function Modeling) standard on mõeldud funktsionaalseks modelleerimiseks ja on vastu võetud USA föderaalstandardina. IDEF0 standard on üks standardite rühmast, mida kasutatakse laialdaselt mis tahes äriprotsessi kirjeldamiseks. Selle kasutamine tarkvaraprojektide kirjeldamisel on väga noor suund, kuid IDEF0 kasutamine tagab, et teie partnerid võtavad teid tõsiselt ...

    IDEF grupi standardite (IDEF0, IDEF1 jne) rakendamine on tegelik tingimus ISO9000, ISO9001 nõuetele vastava organisatsiooni staatuse saamiseks. Need organisatsiooni standardid on võimalus suurendada toodete müüki, võimalus tõestada, et see on "laine harjal".

    Paljud programmeerijad kasutavad CASE ErWini laialdaselt, teadmata, et see põhineb IDEF1 standardil. See ei ole ainult see, mis teile meeldib või mis teie klientidele meeldib. See on standard – ja see ütleb kõik.

    IDEF0 standardi lühipõhimõtted. IDEF0 standard põhineb funktsiooni kontseptsioonil. Funktsioon on kontrollitud toiming sisendandmetele, mille tulemuseks on väljundandmed, kasutades mõnda mehhanismi, mille kaudu see toiming viiakse läbi.

    IDEF0 standard põhineb kolmel põhiprintsiibil:

    1. funktsionaalse dekomponeerimise põhimõte - mis tahes funktsiooni saab lagundada (detaileerida, laotada) lihtsamateks funktsioonideks;

    2. keerukuse piiramise põhimõte - plokkide arv diagrammil peaks olema 2...6 (loetavustingimus);

    3. Konteksti põhimõte - äriprotsesside modelleerimine algab konteksti diagrammi koostamisega, mis kuvab ainult ühe ploki - modelleerimissüsteemi põhifunktsiooni, mis piirab modelleerimissüsteemi piiriala (reguleerib mudeli ehitamise algetapp).

    IDEF0 diagrammid koostatakse plokkide abil. Iga plokk kirjeldab mõnda lõpetatud toimingut (funktsiooni).

    Ploki neljal küljel on erinevad eesmärgid. Sisendandmed kuvatakse vasakul, väljundandmed kuvatakse paremal, juhtimine kuvatakse ülal, mehhanism kuvatakse all.

    Sisendandmed - lähteressursid ploki poolt kirjeldatud funktsiooni jaoks (alginfo, materjalid).

    Väljundandmed - ploki poolt kirjeldatud funktsiooni täitmise tulemusena saadud ressursid (väljundinformatsioon, töödeldud lähtematerjalid).

    Juhtimine on see, mis mõjutab ploki poolt kirjeldatud funktsiooni täitmise protsessi ja võimaldab mõjutada tegevuse tulemust (juhtseadmed, andurid, inimesed).

    Mehhanism on see, mille abil antud tegevus sooritatakse (masinad, seadmed, inimressursid, tarkvara).

    Plokkidevahelised vastasmõjud kuvatakse kaarena (noolena). Mõnikord nimetatakse ploki külgi suundadeks ja nooli vooludeks. Nooltele saab allkirja anda. Allkirjad seotakse vastava noolega siksaki (piksenool) abil.

    IDEF0-skeemi ploki rakendamise üldvaade on näidatud joonisel 1.

    Joonis 1. IDEF0 diagrammides kasutatava ploki realiseerimine.

    Funktsiooni dekomponeerimisel (detailimisel) kuvatakse vastloodud diagrammil kõik sissetulevad ja väljaminevad nooled (kaared, vood), mis on seotud dekomponeeritud funktsiooniga. Noolte arv diagrammi mis tahes tasemel ja mis tahes suunas ei ole piiratud. Diagrammi nimetatakse katkiseks plokiks (funktsiooniks). Diagrammil sisalduva funktsiooni nimega kattub ainult diagrammikonteksti (DC) nimi.

    Sisuliselt moodustavad diagrammid puu. Iga diagramm toimib aluseks olevate diagrammide suhtes alalisvooluna.

    Vaatleme näiteks mõnda abstraktset funktsiooni. Sellel funktsioonil on sisendandmed, kaks heterogeenset tüüpi väljundandmeid, seda juhib väline mõju ja seda rakendavad mehhanismid A ja B. Põhikonteksti diagrammi näide on näidatud joonisel 2 ja selle üksikasjalik (lagundatud) versioon see funktsioon, mis koosneb kahest funktsioonist (elementaarsemad toimingud), on näidatud joonisel 3. Funktsioonid 1 ja 2 võivad omakorda olla ka detailsed (dekomponeeritud).

    Joonis 2. Põhidiagrammi näide.

    Joonis 3. Näide põhifunktsiooni lagunemisest.

    Diagramm asub spetsiaalsel vormil, mis sisaldab funktsiooni nime, selle graafilist pilti, diagrammi tähistust pesastustasemega, linke teistele funktsioonidele, eriteavet autori, organisatsiooni ja kirjeldatud projekti kohta.

    Ühendused. Nooled või kaared näitavad plokkide vahelisi seoseid. Tavaliselt märgivad nooled. Noolesildid on valitud nimisõnadeks. Mugavuse huvides on nooled ühendatud allkirjadega välgunooltega. IDEF0 diagrammi loetavuse huvides on soovitatav paigutada sildid kas noole kohale või noolest paremale.

    Tavaliselt algab juhtmestik andmetega. Sisend on funktsiooni täitmiseks vajalikud andmed. Küsimusi tekib selles suunas harva. Väljund on andmed, mis on funktsiooni täitmise tulemus. Lihtsaim olukord on siis, kui väljund on teise ploki sisend. Kas see on alati nii? Kui sisendteavet töötlev funktsioon moodustab juhtkäsu, on see juhtimine. Ligikaudu sama olukord andmevormingu funktsiooni moodustamisel. Andmevorming on teabe edastamise mehhanism.

    Väljundinformatsiooni alusel moodustatud diagrammil olevad plokkidevahelised põhiliigid on näidatud joonisel 1.

    Joonis 4. Plokkidevaheliste ühenduste tüübid diagrammil. Vastavalt sellele a) andmeside, b) juhtside, c) mehhanismside, d) tagasiside.

    Tagasiside on link, mis moodustab rõnga andmeplokkide, juhtelemendi või vormingu vahel. Sellise ühenduse näide on näidatud joonisel 2.d. Kui selline ühendus ilmub, kontrollige, kas teie diagramm on taandatud algoritmi vooskeemiks. Sellise ühenduse olemasolu ei ole märk veast.

    Blokeeri prioriteet ja nummerdamine. Kõigil plokkidel on prioriteet. Plokkide prioriteetsus sõltub nende täitmise järjekorrast. Vasakul ja ülal asuvatel plokkidel on kõrgeim prioriteet. Domineeriv on horisontaalne asend.

    Plokkide nummerdamine (skeemil plokiindeks) skeemil määratakse prioriteedi alusel. Nummerdamine algab ühest. Diagrammi kood koosneb tähest "A" ja numbrist. DC-l on kood A-0. Täht "A" tähendab aktiivset tegevust (inglise keelest active). Diagrammil, mis on alalisvoolu lagunenud versioon, on kood A0. Iga element A0 diagrammil kodeeritakse vastavalt prioriteedile vahemikus A1 kuni A6. Ühe ploki A1...A6 dekomponeerimisel omakorda koosnevad äsja dekomponeeritud diagrammi plokkide koodid dekomponeeritud diagrammi koodist pluss valitud ploki indeksist. Diagrammi plokkide koode ei korrata kogu diagrammi ulatuses.

    Diagrammi koodi numbrite arvu järgi saate määrata diagrammi taseme - alalisvoolu lagunemise taseme. Põhitasemeks on tavaks pidada DC-d ja kõike muud esimesest lagunemistasemest ja kõrgemalt.

    Toimingute järjestuse tüübid. Andmeid saab töödelda järjestikku või paralleelselt.

    Järjestikuse töötlemise näide on aadressiraamatu täitmine (kahte aadressi ei saa ju sinna korraga kirjutada). Igas plokis töödeldakse alati ainult ühte andmete eksemplari, mis muutuvad järjestikku pärast iga töötlemist. Plokid on paigutatud kas järjestikku horisontaalselt või kaldu ülemisest vasakust nurgast alumisse parempoolsesse.

    Näide paralleelsest töötlemisest - saate samal ajal televiisorit vaadata ja õuna süüa. Sel juhul tehakse kaks toimingut korraga. Need toimingud ei ole omavahel seotud. Sellised plokid diagrammil on paigutatud vertikaalselt üksteise kohale.

    Sageli on diagrammil rühm toiminguid (plokke), millest sõltuvalt mõnest tingimusest täidetakse ainult üks. Selliseid toiminguid nimetatakse alternatiivseteks. Tingimust tuleks sellistele plokkidele rakendada juhttoiminguna (tegevuse valik). Diagrammi on soovitatav lisada spetsiaalne plokk, mis käsitleb alternatiivse toimingu (ploki) valimise tingimust. See plokk genereerib iga ploki jaoks eraldi valitud käsud.

    Isiku roll IDEF0 diagrammides. Kes ta on: juhtimine või mehhanism? Teie otsustate, milliseid funktsioone inimene kirjeldatud ülesandes täidab. Kui plokis sisalduvat tegevust juhib inimene, siis kontrolli. Kui toimingu teeb inimene, siis mehhanism. Kõik sõltub teie probleemi esituse abstraktsiooniastmest.

    On juhtumeid, kui inimene (sealhulgas sama) toimib ühe ploki jaoks mehhanismi ja kontrollina. SEE JUHTUB. Näiteks kirjutab inimene kirja. Selle on kirjutanud see inimene ja see isik haldab selle kirja sisu.

    kontrolli andmed. Juhtkond on meeskond. Kui käsk sisaldab informatiivset osa (nimed, tingimused, tähtajad jne), siis on käsu informatiivne osa sisendandmed.

    Lihtsaim lahendus on jagada algne nool kaheks: juhtseade ja andmed. Need nooled viivad ploki vastavatele külgedele. Mõlemad poolitatud nooled peavad olema vastavalt märgistatud.


    Sergei Sokolov (Minsk, BSUIR)
    Meil: