Balita

Paglalarawan ng pagbuo ng idef0 diagram. IDEF0. Panimula sa notasyon at halimbawa ng paggamit. Mga pakinabang ng paggamit ng IDEF0

Ang IDEF0 ay isang graphical modeling notation na ginagamit upang lumikha ng isang functional na modelo na naglalarawan sa istruktura at mga function ng isang system, pati na rin ang mga daloy ng impormasyon at materyal na mga bagay na nag-uugnay sa mga function na ito. Ang IDEF0 notation ay isa sa pinakasikat na business process modeling notation.

Ang layunin ng pamamaraan ay bumuo ng isang functional diagram ng system na pinag-aaralan, na naglalarawan sa lahat ng kinakailangang proseso na may sapat na katumpakan para sa hindi malabo na pagmomodelo ng aktibidad ng system.

Ang pamamaraan ay batay sa apat na pangunahing konsepto: functional block, interface arc, decomposition, glossary.

Block ng function(Kahon ng Aktibidad) ay kumakatawan sa ilang partikular function sa loob ng sistemang isinasaalang-alang. Ayon sa mga kinakailangan ng pamantayan, ang pangalan ng bawat functional block ay dapat mabalangkas sa pandiwang mood (halimbawa, "gumawa ng mga serbisyo"). Sa diagram, ang functional block ay inilalarawan bilang isang parihaba (Larawan 3.).

Ang bawat isa sa apat na panig ng functional block ay may sariling tiyak na kahulugan (role), at:

Ang tuktok na bahagi ay nakatakda sa "Kontrol";

Ang kaliwang bahagi ay nakatakda sa "Input";

Ang kanang bahagi ay nakatakda sa Output;

Ang ilalim na bahagi ay may kahulugang "Mekanismo".

Interface arc(Arrow) ay nagpapakita ng isang elemento ng system na pinoproseso ng isang function block o kung hindi man ay nakakaapekto function, na kinakatawan ng function block na ito. Ang mga arko ng interface ay madalas na tinatawag na mga daloy o arrow.

kanin. 3. - Function block

Gamit ang mga interface arc, ipinapakita ang iba't ibang mga bagay na, sa isang antas o iba pa, tinutukoy ang mga prosesong nagaganap sa system. Ang mga naturang bagay ay maaaring mga elemento ng totoong mundo (mga bahagi, kotse, empleyado, atbp.) o mga daloy ng data at impormasyon (mga dokumento, data, mga tagubilin, atbp.).

Depende sa kung aling bahagi ng functional block ang interface arc na ito ay magkasya, ito ay tinatawag na "incoming", "outgoing" o "control".

Dapat tandaan na ang anumang functional block, ayon sa mga kinakailangan ng pamantayan, ay dapat magkaroon ng hindi bababa sa isang control interface arc at isang papalabas na isa. Ito ay nauunawaan - ang bawat proseso ay dapat maganap ayon sa ilang mga patakaran (ipinapakita ng control arc) at dapat na makagawa ng ilang resulta (papalabas na arko), kung hindi, ang pagsasaalang-alang nito ay walang kahulugan.

Ang ipinag-uutos na presensya ng mga control interface arc ay isa sa mga pangunahing pagkakaiba sa pagitan ng pamantayan ng IDEF0 at iba pang mga pamamaraan ng mga klase ng DFD (Data Flow Diagram) at WFD (Work Flow Diagram).

Pagkabulok Ang (Decomposition) ay isang pangunahing konsepto ng pamantayan ng IDEF0. Ang prinsipyo ng agnas ay ginagamit kapag sinira ang isang kumplikadong proseso sa mga bahagi nito mga function. Sa kasong ito, ang antas ng detalye ng proseso ay direktang tinutukoy ng developer ng modelo.

Binibigyang-daan ka ng decomposition na unti-unti at maayos na kumatawan sa modelo ng system sa form hierarchical na istraktura hiwalay na mga diagram, na ginagawang hindi gaanong na-overload at madaling natutunaw (Fig. 4.).

Ang pinakahuli sa mga konsepto ng IDEF0 ay ang Glossary. Para sa bawat isa sa mga elemento ng IDEF0 - mga diagram, mga bloke ng pag-andar, mga arko ng interface - ang umiiral na pamantayan ay nagpapahiwatig ng paglikha at pagpapanatili ng isang hanay ng mga kaukulang kahulugan, mga keyword, mga salaysay na pahayag, atbp., na nagpapakilala sa bagay na ipinapakita ng elementong ito. Ang set na ito ay tinatawag na isang glossary at isang paglalarawan ng entity ng elementong ito. Ang glossary ay magkakasuwato na umaakma sa visual na graphic na wika, na nagbibigay sa mga diagram ng kinakailangang karagdagang impormasyon.

Palaging nagsisimula ang modelong IDEF0 sa isang view ng system bilang isang buo - isang functional block na may mga interface arc na lumalampas sa domain na isinasaalang-alang. Ang ganitong diagram na may isang functional block ay tinatawag diagram ng konteksto.

Dapat ipahiwatig ng tekstong nagpapaliwanag para sa diagram ng konteksto target(Layunin) upang makabuo ng isang diagram sa anyo maikling paglalarawan at naayos pananaw.

kanin. 4. - Scheme ng decomposition ng functional blocks ng modelo

Tinutukoy ng punto ng view ang pangunahing direksyon ng pag-unlad ng modelo at ang antas ng kinakailangang detalye.

Ang isang malinaw na pag-aayos ng punto ng view ay nagbibigay-daan sa iyo upang i-unload ang modelo sa pamamagitan ng pagtanggi sa detalye at pag-aralan ang mga indibidwal na elemento na hindi kinakailangan, batay sa napiling punto ng view sa system. Tamang pagpipilian Ang punto ng view ay makabuluhang binabawasan ang oras na ginugol sa pagbuo ng panghuling modelo.

Pagpili mga subprocess. Sa panahon ng proseso ng agnas, ang isang functional block na kumakatawan sa system sa kabuuan sa isang context diagram ay nakadetalye sa isa pang diagram. Ang resultang second-level diagram ay naglalaman ng mga functional block na nagpapakita ng mga pangunahing subfunction ng functional block ng context diagram, at tinatawag na Child Diagram kaugnay nito (bawat isa sa mga functional block na kabilang sa child diagram ay naaayon na tinatawag na Child Box) .

Sa turn, ang ancestor functional block ay tinatawag na parent block na may kaugnayan sa child diagram (Parent Box), at ang diagram kung saan ito nabibilang ay tinatawag na parent diagram (Parent Diagram). Ang bawat isa sa mga subfunction ng isang child diagram ay maaaring mas detalyado sa pamamagitan ng isang katulad na agnas ng katumbas nitong functional block. Sa bawat kaso ng decomposition ng isang functional block, lahat ng interface arc ay kasama sa block na ito o nagmumula dito ay nakunan sa child diagram. Nakakamit nito ang integridad ng istruktura ng modelong IDEF0.

Minsan hindi makatuwiran na patuloy na isaalang-alang ang mga indibidwal na arko ng interface ng mas mataas na antas sa mga diagram ng mas mababang antas, o kabaligtaran - ang mga indibidwal na arko ng mas mababang antas ay makikita sa mga diagram nang higit pa mataas na antas- ito ay mag-overload lamang sa mga diagram at magpapahirap sa kanila na maunawaan. Upang malutas ang mga naturang problema, ang pamantayan ng IDEF0 ay nagbibigay ng konsepto ng tunneling. Ang pagtatalaga ng "Arrow Tunnel" ng dalawang panaklong sa paligid ng simula ng isang interface arc ay nagpapahiwatig na ang arko ay hindi minana mula sa functional parent block at lalabas (mula sa "tunnel") lamang sa diagram na ito.

Sa turn, ang parehong pagtatalaga sa paligid ng dulo (arrow) ng interface arc sa agarang paligid ng block ng receiver ay nangangahulugan na ang arc na ito ay hindi ipapakita o isasaalang-alang sa child diagram ng block na ito. Kadalasan, nangyayari na ang mga indibidwal na bagay at ang kanilang kaukulang mga arko ng interface ay hindi isinasaalang-alang sa ilang mga intermediate na antas ng hierarchy - sa kasong ito, sila ay unang "ilubog sa tunel", at pagkatapos, kung kinakailangan, "bumalik mula sa tunel" .

Karaniwan, ang mga modelo ng IDEF0 ay naglalaman ng kumplikado at puro impormasyon, at upang limitahan ang kanilang kasikipan at gawing nababasa ang mga ito, ang pamantayan ay gumagamit ng naaangkop na mga paghihigpit sa pagiging kumplikado.

Inirerekomenda na kumatawan mula tatlo hanggang anim na functional block sa diagram, habang ang bilang ng mga interface arc na angkop para sa isang functional block (lumalabas sa isang functional block) ay ipinapalagay na hindi hihigit sa apat.

Ang pamantayan ng IDEF0 ay naglalaman ng isang hanay ng mga pamamaraan na nagpapahintulot sa isang modelo na mabuo at mapagkasunduan ng isang malaking grupo ng mga tao na kabilang sa iba't ibang mga lugar ng aktibidad ng system na ginagaya.

Karaniwan, ang proseso ng pagbuo ay umuulit at binubuo ng mga sumusunod na karaniwang yugto: Paglikha ng isang modelo ng isang pangkat ng mga espesyalista na nauugnay sa iba't ibang mga lugar ng negosyo. Ang pangkat na ito ay tinatawag na Mga May-akda sa mga termino ng IDEF0. Ang pagbuo ng paunang modelo ay isang dinamikong proseso kung saan ang mga may-akda ay nakikipagpanayam sa mga karampatang indibidwal tungkol sa istruktura ng iba't ibang mga proseso, na lumilikha ng mga modelo ng mga aktibidad ng departamento.

Interesado sila sa mga sagot sa mga sumusunod na tanong:

Ano ang natatanggap ng departamento bilang input?

Alin mga function at sa anong pagkakasunud-sunod ang mga ito ay ginaganap sa loob ng departamento?

Sino ang may pananagutan sa pagpapatupad ng bawat isa sa mga function?

Ano ang gumagabay sa gumaganap sa pagganap ng bawat isa sa mga function?

Ano ang resulta ng trabaho (output) ng departamento?

Batay sa mga umiiral na regulasyon, dokumento at resulta ng survey, isang Model Draft ng modelo ang ginawa.

Pamamahagi ng draft para sa pagsusuri, pag-apruba at komento. Sa yugtong ito, ang draft na modelo ay tinatalakay sa isang malawak na hanay ng mga karampatang tao (sa mga termino ng IDEF0 - mga mambabasa) sa negosyo. Sa kasong ito, ang bawat isa sa mga diagram ng draft na modelo ay pinupuna at binibigyang komento sa pamamagitan ng pagsulat, at pagkatapos ay inilipat sa may-akda. Ang may-akda, naman, ay sumasang-ayon din sa pamamagitan ng pagsulat sa kritisismo o tinatanggihan ito, na binabalangkas ang lohika ng desisyon, at ibinalik ang binagong draft para sa karagdagang pagsasaalang-alang. Ang cycle na ito ay nagpapatuloy hanggang ang mga may-akda at mga mambabasa ay maabot ang isang pinagkasunduan.

Opisyal na pag-apruba ng modelo. Ang inaprubahang modelo ay inaprubahan ng manager grupong nagtatrabaho sa kaganapan na ang mga may-akda ng modelo at mga mambabasa ay walang hindi pagkakasundo tungkol sa kasapatan nito. Ang pangwakas na modelo ay isang magkakaugnay na pagtingin sa negosyo (system) mula sa isang naibigay na punto ng view at para sa isang tiyak na layunin.

Ang kalinawan ng graphic na wika ng IDEF0 ay ginagawang ganap na nababasa ang modelo kahit para sa mga taong hindi nakibahagi sa proyekto ng paglikha nito, pati na rin epektibo para sa mga palabas at presentasyon. Sa hinaharap, batay sa itinayong modelo, maaaring ayusin ang mga bagong proyekto na naglalayong gumawa ng mga pagbabago sa modelo.

Ang modelo ng IDEF0 ay inirerekomenda para sa paggamit sa isang enterprise kapag naglalarawan ng mga proseso ng negosyo sa pinakamataas na antas. Kapag gumuhit ng isang functional na modelo ng isang proseso ng negosyo (IDEF0), ang mga function na ginanap at ang input at output na daloy ng materyal, Pinagkukuhanan ng salapi at impormasyon (mga dokumento, mga file).

Ang mga simbolo ng format ng IDEF0 ay ipinakita sa mga talahanayan 2 at 3.

Talahanayan 2. - Mga graphic na simbolo ng IDEF0 notation

Simbolo	Imahe	Paglalarawan
I-block		Inilalarawan ng bloke ang proseso. Ang isang tipikal na bloke ay ipinapakita sa Fig. 1. Sa loob ng bawat bloke ay nakalagay ang pangalan at numero nito. Ang pangalan ay dapat na isang aktibong pandiwa, pariralang pandiwa, o pandiwang pangngalan. Ang block number ay matatagpuan sa kanang sulok sa ibaba. Ginagamit ang mga block number para sa pagkakakilanlan sa diagram at nauugnay na teksto.
Palaso		Ang mga arrow ay kumakatawan sa mga bagay (data) na pumapasok at umaalis sa proseso. Ang bawat panig ng isang function block ay may karaniwang kahulugan sa mga tuntunin ng block-arrow na koneksyon, ang gilid ng bloke kung saan ang arrow ay katangi-tanging tumutukoy sa papel nito. Ang mga arrow na pumapasok sa kaliwang bahagi ng bloke ay mga pasukan. Ang mga arrow na pumapasok sa block mula sa itaas ay mga kontrol. Ang mga arrow na umaalis sa proseso sa kanan ay mga labasan, i.e. data o materyal na bagay na ginawa ng isang proseso. Ang mga arrow na konektado sa ilalim ng bloke ay kumakatawan sa mga mekanismo.
Tunneled arrow		Isinasaad ng mga tunneled arrow na ang data na kinakatawan ng mga arrow ay hindi isinasaalang-alang sa parent chart at/o child chart. Ang isang arrow na inilagay sa tunnel kung saan ito sumasali sa isang bloke ay nangangahulugan na ang data na ipinahayag ng arrow na iyon ay hindi kinakailangan sa susunod na antas ng agnas. Ang isang arrow na inilagay sa isang tunnel sa libreng dulo ay nangangahulugan na ang data na kinakatawan nito ay wala sa parent diagram.
Panlabas na sanggunian		Panlabas na sanggunian - isang lugar, entity o paksa na nasa labas ng mga hangganan ng system na ginagaya. Ginagamit upang ipahiwatig ang pinagmulan o patutunguhan ng mga arrow sa labas ng modelo. Sa mga diagram, ang isang Panlabas na Link ay inilalarawan bilang isang parisukat, sa tabi kung saan ipinapakita ang pangalan ng Panlabas na Link.
Interchart link		Isang elemento na kumakatawan sa isa pang diagram. Nagsisilbing ipahiwatig ang paglipat ng mga arrow sa isang diagram ng isa pang proseso ng negosyo nang hindi nagpapakita ng isang arrow sa nakapatong na diagram (kapag gumagamit ng mga hierarchical na modelo).

Talahanayan 3. - Mga graphic na simbolo ng IDEF0 notation

Workshop sa paggamit ng IDEF0 para sa functional na paglalarawan ng CAD software

Workshop sa paggamit ng IDEF0 para sa functional na paglalarawan ng software
Bahagi 1.

Kung susuriin natin ang mga patalastas para sa pagkuha ng mga empleyado mula sa mga kumpanyang kasangkot sa pagbuo ng software, kamakailan lamang ay nagkaroon ng matinding kakulangan ng mga tagapamahala ng proyekto na may kakayahang magtakda ng mga gawain nang may kakayahan. Ang problema ay hindi na hindi nila mabuo ang gawain, ngunit hindi nila maisasaalang-alang nang tama ang dokumentasyon modernong mga pamantayan disenyo. Ang customer ay mayroon naHindi sapat na magbigay ng ilang mga sheet ng papel na nai-type sa Word. Gusto niya ang dokumentasyong naka-format sa BPWin, ErWin, S-Designer, Power Designer, Rational Rose, atbp. Sa likod ng bawat isa sa mga tool na ito ng CASE ay isang pamantayan. Ang artikulong ito ay nakatuon sa isa sa kanila - IDEF0.

Panimula. Kapag nag-compile ng dokumentasyon, itinuturing ng bawat tagapamahala ng proyekto na isang "karangalan" na makabuo ng isang bagay na "kanyang sarili" - ang kanyang sariling "super format" para sa paglalahad ng kanyang mga ideya. Ang pagiging kumplikado ng mga proyekto ay lumalaki, ang dami ng dokumentasyon para sa proyekto ay lumalaki, ang dokumentasyon ay lampas sa nagtatrabaho na grupo... at pagkatapos ay nagiging malinaw na ang dokumentasyon ay hindi angkop sa customer o sa grupo ng mga developer na nagsasagawa ng finalization ng proyekto at suporta nito.

Karaniwan, ang tagapamahala ng proyekto ay alinman sa isang mahusay na programmer (nangunguna sa programmer ng paksa ng proyekto), o may mahusay na utos ng Wikang banyaga isang taong pamilyar sa programming. Ito ang mga pangunahing pamantayan sa pagpili para sa posisyon ng tagapamahala ng proyekto. Ito ang ugat ng problema. Maaari kang maging isang mahusay na programmer o lamang mabuting empleyado, ngunit wala itong kinalaman sa paghahanda ng dokumentasyon.

Karaniwan, ang detalye para sa bawat uri ng manager ay bumababa sa isang paglalarawan ng modelo ng mismong programa (ang arkitektura ng mga module, klase, DLL, istraktura ng database at paggamit nito, atbp.) o sa isang paglalarawan ng user function (kung ano ang dapat nilang gawin, anong mga form ang dapat nasa programa, atbp.).

Ang perpektong opsyon ay kapag ang gawain ay itinakda ng customer. Sa kasong ito, maaari mong ipamuhay ang prinsipyong "gusto ng kostumer", at hangga't nasiyahan siya, makakatanggap ka ng pera mula sa customer. Pero yun lang mas maraming proyekto ay nilikha sa kaibuturan ng anumang organisasyon, at pagkatapos ay inaalok sa customer. At sa kasong ito, ang kalidad ng dokumentasyon, kung ano ang iyong ginawa at kung ano ang balak mong gawin, ay nauuna. Sa kasong ito, ang dokumentasyon ay lahat...

Ang pamantayan ng IDEF0 (Integrated Definition Function Modeling) ay inilaan para sa functional modeling at pinagtibay bilang isang pederal na pamantayan ng US. Ang pamantayan ng IDEF0 ay isa sa isang pangkat ng mga pamantayan na malawakang ginagamit upang ilarawan ang anumang mga proseso ng negosyo. Ang paggamit nito para sa paglalarawan ng mga proyekto ng software ay napakabata pa, ngunit ang paggamit ng IDEF0 ay ginagarantiyahan na sineseryoso ka ng iyong mga kasosyo...

Ang aplikasyon ng mga pamantayan ng grupo ng IDEF (IDEF0, IDEF1, atbp.) ay ang aktwal na kondisyon para sa pagkuha ng katayuan ng isang organisasyon na nakakatugon sa ISO9000, ISO9001. Ang mga pamantayang ito para sa isang organisasyon ay isang pagkakataon upang mapataas ang mga benta ng produkto, isang pagkakataon upang patunayan na ito ay "nasa tuktok ng isang alon."

Maraming programmer ang malawakang gumagamit ng CASE ErWin, nang hindi nalalaman na ito ay batay sa pamantayan ng IDEF1. Hindi lang kung ano ang gusto mo o kung ano ang gusto ng iyong mga customer. Ito ang pamantayan - at iyon na.

Maikling pangunahing konsepto ng pamantayan ng IDEF0. Ang pamantayan ng IDEF0 ay batay sa konsepto ng function. Ang isang function ay isang kinokontrol na aksyon sa input data, ang resulta kung saan ay output data, habang gumagamit ng isang tiyak na mekanismo kung saan ang aksyon na ito ay isinasagawa.

Ang pamantayan ng IDEF0 ay batay sa tatlong pangunahing prinsipyo:

1. prinsipyo ng functional decomposition - anumang function ay maaaring decomposed (detalyadong, pinaghiwa-hiwalay) sa mas simpleng mga function;

2. prinsipyo ng paglilimita sa pagiging kumplikado - ang bilang ng mga bloke sa diagram ay dapat na 2...6 (kondisyon sa pagiging madaling mabasa);

3. prinsipyo ng konteksto - nagsisimula ang pagmomodelo ng proseso ng negosyo sa pagbuo ng isang diagram ng konteksto, na nagpapakita lamang ng isang bloke - pangunahing tungkulin sistema ng pagmomolde, nililimitahan ang lugar ng hangganan ng sistema ng pagmomolde (kinokontrol ang paunang yugto ng pagtatayo ng modelo).

Ang mga diagram ng IDEF0 ay binuo gamit ang mga bloke. Ang bawat bloke ay naglalarawan ng isang nakumpletong aksyon (function).

Ang apat na panig ng bloke ay may iba't ibang layunin. Ang input data ay ipinapakita sa kaliwa, ang output data sa kanan, ang kontrol sa itaas, at ang mekanismo sa ibaba.

Input data - mga paunang mapagkukunan para sa function na inilarawan ng block (paunang impormasyon, mga materyales).

Output data - ang mga nagresultang mapagkukunan na nakuha bilang isang resulta ng pagpapatupad ng function na inilarawan ng block (impormasyon ng output, naprosesong mapagkukunan na materyales).

Ang kontrol ay kung ano ang nakakaimpluwensya sa proseso ng pagsasagawa ng function na inilarawan ng block at nagbibigay-daan sa iyong maimpluwensyahan ang resulta ng aksyon (mga kontrol, sensor, tao).

Ang mekanismo ay kung saan ang isang naibigay na aksyon ay isinasagawa (mga makina, instrumento, mapagkukunan ng tao, software).

Ang pakikipag-ugnayan sa pagitan ng mga bloke ay ipinapakita bilang mga arko (mga arrow). Minsan ang mga gilid ng bloke ay tinatawag na mga direksyon, at ang mga arrow ay tinatawag na mga daloy. Maaaring pirmahan ang mga arrow. Ang mga lagda ay konektado sa kaukulang arrow gamit ang isang zigzag (lightning bolt).

Ang pangkalahatang view ng pagpapatupad ng IDEF0 diagram block ay ipinapakita sa Fig. 1.

Fig.1. Pagpapatupad ng isang bloke na ginamit sa mga diagram ng IDEF0.

Kapag nabubulok (nagdedetalye) ng isang function, ipinapakita ng bagong nabuong diagram ang lahat ng papasok at papalabas na arrow (mga arko, daloy) na nauugnay sa function na pinaghiwa-hiwalay. Ang bilang ng mga arrow sa anumang antas ng diagram at sa anumang direksyon ay walang limitasyon. Ang diagram ay tinatawag na split block (function). Tanging ang pangalan ng context diagram (DC) ay kasabay ng pangalan ng function na nakapaloob sa diagram.

Sa esensya, ang mga diagram ay bumubuo ng isang puno. Ang anumang diagram ay gumaganap bilang isang DC na may kaugnayan sa mga pinagbabatayan.

Bilang halimbawa, isaalang-alang ang ilang abstract function. Ang function na ito ay may input data, dalawang heterogenous na uri ng output data, ay kinokontrol ng mga panlabas na impluwensya at ipinapatupad ng mga mekanismo A at B. Ang isang halimbawa ng pangunahing diagram ng konteksto ay ipinapakita sa Fig. 2, at isang detalyadong (decomposed) na bersyon nito function, na binubuo ng dalawang function (mas elementary actions ), na ipinapakita sa Fig. 3. Sa turn, ang mga function 1 at 2 ay maaari ding i-detalye (decomposed).

Fig.2. Halimbawa ng pangunahing diagram.

Fig.3. Halimbawa ng decomposition ng isang pangunahing function.

Ang diagram ay matatagpuan sa isang espesyal na form, na naglalaman ng pangalan ng function, ang graphical na representasyon nito, ang pagtatalaga ng diagram na may antas ng nesting, mga koneksyon sa iba pang mga function, espesyal na impormasyon tungkol sa may-akda, organisasyon at ang proyektong inilarawan.

Mga koneksyon Ang mga arrow o arc ay nagpapakita ng mga ugnayan sa pagitan ng mga bloke. Ang mga arrow ay karaniwang nilagdaan. Ang mga pirma ng arrow ay pinipili bilang mga pangngalan. Para sa kaginhawahan, ang mga arrow ay konektado sa mga lagda na may mga zipper. Para sa pagiging madaling mabasa ng diagram ng IDEF0, inirerekumenda na ilagay ang mga label sa itaas ng arrow o sa kanan ng arrow.

Karaniwan, ang mga kable ay nagsisimula sa data. Ang mga input ay ang data na kailangan upang maisagawa ang isang function. Ang mga tanong ay bihirang lumabas sa direksyong ito. Ang output ay ang data na resulta ng pagsasagawa ng isang function. Ang pinakasimpleng sitwasyon ay kapag ang output data ay ang input data para sa isa pang block. Ganito ba palagi? Kung ang isang function, pagproseso ng impormasyon ng input, ay bumubuo ng isang control command, ito ay control. Ang sitwasyon ay halos pareho kapag ang isang function ay bumubuo ng isang format ng data. Ang format ng data ay isang mekanismo para sa pagpapadala ng impormasyon.

Ang mga pangunahing uri ng mga koneksyon sa pagitan ng mga bloke sa diagram, na nabuo batay sa impormasyon ng output, ay ipinapakita sa Fig. 1.

Fig.4. Mga uri ng koneksyon sa pagitan ng mga bloke sa diagram. Alinsunod dito, a) komunikasyon sa pamamagitan ng data, b) komunikasyon sa pamamagitan ng kontrol, c) komunikasyon sa pamamagitan ng mekanismo, d) feedback.

Ang feedback ay isang koneksyon na bumubuo ng singsing sa pagitan ng mga bloke ayon sa data, kontrol o format. Ang isang halimbawa ng naturang koneksyon ay ipinapakita sa Fig. 2.d. Kapag lumitaw ang koneksyon na ito, suriin upang makita kung ang iyong diagram ay mababawasan sa isang flowchart ng algorithm. Ang pagkakaroon ng naturang koneksyon ay hindi isang tanda ng isang error.

Priyoridad at bilang ng mga bloke. Ang lahat ng mga bloke ay may priyoridad. Ang priyoridad ng mga bloke ay nakasalalay sa pagkakasunud-sunod ng kanilang pagpapatupad. Ang mga bloke na matatagpuan sa kaliwa at itaas ay may pinakamataas na priyoridad. Ang nangingibabaw na posisyon ay pahalang.

Ang block numbering (block index sa diagram) sa diagram ay tinutukoy batay sa priyoridad. Ang pagnunumero ay nagsisimula sa isa. Ang diagram code ay binubuo ng letrang "A" at isang numero. Ang DK ay may code A-0. Ang titik na "A" ay nagpapahiwatig ng aktibong pagkilos. Ang diagram, na isang decomposed na bersyon ng DC, ay magkakaroon ng code A0. Ang bawat elemento sa A0 diagram ay iko-code A1 hanggang A6 ayon sa priyoridad. Sa turn, kapag nabubulok ang isa sa mga bloke A1...A6, ang mga block code ng bagong decomposed na diagram ay bubuuin ng code ng decomposed diagram kasama ang index ng napiling block. Ang mga block code ng chart ay hindi inuulit sa buong chart.

Sa pamamagitan ng bilang ng mga digit sa diagram code, maaari mong matukoy ang antas ng diagram - ang antas ng agnas ng DC. Karaniwang tinatanggap na ang DC ang pangunahing antas, at lahat ng iba ay mula sa unang antas ng agnas at mas mataas.

Mga uri ng pagkakasunud-sunod ng mga aksyon. Maaaring iproseso ang data nang sunud-sunod o kahanay.

Ang isang halimbawa ng sunud-sunod na pagproseso ay ang pagpuno sa address book (pagkatapos ng lahat, hindi ka maaaring sumulat ng dalawang address dito nang sabay). Sa bawat bloke, isang instance lang ng data ang palaging pinoproseso, sunud-sunod na binago pagkatapos ng bawat pagproseso. Ang mga bloke ay nakaayos alinman sa sunud-sunod na pahalang o pahilig mula sa kaliwang itaas hanggang sa kanang ibaba.

Ang isang halimbawa ng parallel processing ay maaari kang manood ng TV at kumain ng mansanas nang sabay. Sa kasong ito, ang dalawang aksyon ay isinasagawa nang sabay-sabay. Ang mga pagkilos na ito ay hindi nauugnay sa isa't isa. Ang ganitong mga bloke sa diagram ay matatagpuan patayo sa itaas ng isa.

Kadalasan sa isang diagram mayroong isang pangkat ng mga aksyon (mga bloke), kung saan isa lamang ang ginagawa, depende sa ilang kondisyon. Ang ganitong mga aksyon ay tinatawag na alternatibo. Para sa mga naturang bloke, dapat ilapat ang kundisyon bilang kontrol na aksyon (pagpipilian ng aksyon). Inirerekomenda na magpasok ng isang espesyal na bloke sa diagram na nagpoproseso ng kundisyon para sa pagpili ng alternatibong aksyon (block). Ang bloke na ito ay bumubuo ng hiwalay na mga command sa pagpili para sa bawat bloke.

Ang papel ng mga tao sa mga diagram ng IDEF0. Ano ito: kontrol o mekanismo? Ikaw ang magpapasya para sa iyong sarili kung anong mga tungkulin ang ginagawa ng isang tao sa gawaing inilalarawan. Kung ang aksyon na nakapaloob sa block ay kinokontrol ng isang tao, pagkatapos ay kontrolin. Kung ang aksyon ay ginanap sa pamamagitan ng isang tao, kung gayon ito ay isang mekanismo. Ang lahat ay nakasalalay sa antas ng abstraction ng iyong representasyon ng problema.

May mga kaso kapag ang isang tao (kabilang ang pareho) ay kikilos bilang isang mekanismo at kontrol para sa isang bloke. NANGYARI YAN. Halimbawa, ang isang tao ay nagsusulat ng isang liham. Ito ay isinulat sa pamamagitan ng taong ito, at ang taong ito rin ang kumokontrol sa nilalaman ng liham na ito.

Kontrolin ang data. Ang pamamahala ay isang pangkat. Kung ang command ay naglalaman ng isang nagbibigay-kaalaman na bahagi (mga pangalan, kundisyon, mga deadline, atbp.), kung gayon ang impormasyong bahagi ng command ay ang input data.

Ang pinakasimpleng solusyon ay hatiin ang orihinal na arrow sa dalawa: kontrol at data. Ang mga arrow na ito ay konektado sa mga kaukulang panig ng bloke. Ang parehong nahahati na mga arrow ay dapat may naaangkop na mga inskripsiyon.

Sergey Sokolov (Minsk, BSUIR)
Email:

Layunin ng gawain:

pag-aaral ng mga pangunahing prinsipyo ng pamamaraan ng IDEF0,
paggawa ng bagong proyekto sa BPWin,
pagbuo ng diagram ng konteksto,
paggawa ng mga koneksyon.

Ang paglalarawan ng isang sistema gamit ang IDEF0 ay tinatawag na isang functional na modelo. Ang functional na modelo ay idinisenyo upang ilarawan ang mga kasalukuyang proseso ng negosyo, na gumagamit ng parehong natural at graphical na mga wika. Upang maghatid ng impormasyon tungkol sa isang partikular na sistema, ang pinagmulan ng graphical na wika ay ang mismong pamamaraan ng IDEF0.

Pamamaraan ng IDEF0 inireseta ang pagbuo ng isang hierarchical system ng mga diagram - solong paglalarawan ng mga fragment ng system. Una, ang isang paglalarawan ng system sa kabuuan at ang pakikipag-ugnayan nito sa labas ng mundo ay isinasagawa (diagram ng konteksto), pagkatapos ay isinasagawa ang isang functional decomposition - ang sistema ay nahahati sa mga subsystem at ang bawat subsystem ay inilarawan nang hiwalay (mga decomposition diagram) . Pagkatapos ang bawat subsystem ay nahahati sa mas maliit, at iba pa hanggang sa makamit ang nais na antas ng detalye.

Ang bawat isa Mga diagram ng IDEF0 a ay naglalaman ng mga bloke at arko. Ang mga bloke ay naglalarawan ng mga pag-andar ng modelong sistema. Ang mga arko ay nag-uugnay sa mga bloke nang magkasama at kumakatawan sa mga pakikipag-ugnayan at relasyon sa pagitan nila.

Ang mga functional na bloke (trabaho) sa mga diagram ay kinakatawan ng mga parihaba, na kumakatawan sa mga pinangalanang proseso, function, o gawain na nagaganap sa loob ng isang yugto ng panahon at may mga nakikilalang resulta. Ang pangalan ng akda ay dapat ipahayag bilang isang pandiwang pangngalan na nagsasaad ng aksyon.

IDEF0 nangangailangan na ang diagram ay may hindi bababa sa tatlo at hindi hihigit sa anim na bloke. Ang mga hadlang na ito ay nagpapanatili sa pagiging kumplikado ng mga diagram at modelo sa isang antas na nababasa, naiintindihan, at magagamit.

Ang bawat panig ng bloke ay may espesyal, napaka tiyak na layunin. Ang kaliwang bahagi ng block ay para sa mga input, ang tuktok ay para sa kontrol, ang kanan ay para sa mga output, at ang ibaba ay para sa mga mekanismo. Ang pagtatalaga na ito ay sumasalamin sa ilang mga prinsipyo ng system: ang mga input ay na-convert sa mga output, nagkokontrol ng mga limitasyon o nagrereseta ng mga kondisyon para sa pagsasagawa ng mga pagbabago, ipinapakita ng mga mekanismo kung ano at paano gumaganap ang isang function.

Ang mga bloke sa IDEF0 ay inilalagay sa pagkakasunud-sunod ng kahalagahan, ayon sa pagkakaunawa ng may-akda ng diagram. Ang relatibong ayos na ito ay tinatawag na dominasyon. Ang dominasyon ay nauunawaan bilang ang impluwensya ng isang bloke sa iba pang mga bloke sa diagram. Halimbawa, ang pinaka nangingibabaw na bloke ng diagram ay maaaring ang una sa isang kinakailangang pagkakasunod-sunod ng mga function, o isang pagpaplano o pagkontrol ng function na nakakaimpluwensya sa lahat ng iba pa.

Ang pinaka nangingibabaw na bloke ay karaniwang inilalagay sa itaas na kaliwang sulok ng diagram, at ang hindi bababa sa nangingibabaw ay nasa kanang sulok.

Ang pagsasaayos ng mga bloke sa pahina ay sumasalamin sa kahulugan ng may-akda ng pangingibabaw. Kaya, ang topology ng diagram ay nagpapakita kung aling mga tampok ang may mas malaking epekto sa iba. Upang bigyang-diin ito, maaaring muling bilangin ng analyst ang mga bloke ayon sa kanilang pagkakasunud-sunod ng pangingibabaw. Ang pagkakasunud-sunod ng pangingibabaw ay maaaring ipahiwatig ng isang numero na nakalagay sa kanang sulok sa ibaba ng bawat parihaba: 1 ay magsasaad ng pinakamalaking dominasyon, 2 sa susunod, atbp.

Pakikipag-ugnayan ng mga gawa sa labas ng mundo at inilalarawan sa kanilang mga sarili sa anyo ng mga arrow, na inilalarawan bilang mga solong linya na may mga arrow sa mga dulo. Ang mga arrow ay kumakatawan sa ilang impormasyon at tinatawag na mga pangngalan.

Mga uri ng arrow

Tinutukoy ng IDEF0 ang limang uri ng mga arrow.

Pagpasok- mga bagay na ginamit at binago ng trabaho upang makakuha ng resulta (output). Pinapayagan na ang trabaho ay maaaring walang isang entry na arrow. Ang entry arrow ay iginuhit bilang pagpasok sa kaliwang gilid ng trabaho.

Kontrol-.impormasyon na kumokontrol sa mga aksyon ng gawain. Karaniwan, ang mga control arrow ay nagdadala ng impormasyon na nagpapahiwatig kung ano ang dapat gawin ng isang trabaho. Ang bawat trabaho ay dapat magkaroon ng hindi bababa sa isang control arrow, na ipinapakita bilang pagpasok sa tuktok na gilid ng trabaho.

Lumabas- mga bagay kung saan na-convert ang mga input. Ang bawat trabaho ay dapat magkaroon ng hindi bababa sa isang exit arrow, na iginuhit bilang nagmumula sa kanang gilid ng trabaho.

Mekanismo- mga mapagkukunan na gumaganap ng gawain. Ang arrow ng mekanismo ay iginuhit habang pumapasok sa ibabang gilid ng trabaho. Sa pagpapasya ng analyst, ang mga arrow ng mekanismo ay maaaring hindi ilarawan sa modelo.

Tumawag- isang espesyal na arrow na tumuturo sa ibang operating model. Ang call arrow ay iginuhit bilang nagmumula sa ibaba ng trabaho at ginagamit upang ipahiwatig na ang ilang trabaho ay ginagawa sa labas ng system na ginagampanan.

kanin. 2.1 Mga uri ng arrow

Ang pamamaraan ng IDEF0 ay nangangailangan lamang ng limang uri ng mga pakikipag-ugnayan sa pagitan ng mga bloke upang ilarawan ang kanilang mga relasyon: kontrol, input, kontrol feedback, input feedback, output-mekanismo. Ang mga kontrol at input na koneksyon ay ang pinakasimpleng dahil ang mga ito ay nagpapakita ng mga direktang impluwensya na madaling maunawaan at napakasimple.

kanin. 2.2. Komunikasyon sa output

kanin. 2.3. Komunikasyon sa Pamamahala

Ang isang kontrol na relasyon ay nangyayari kapag ang output ng isang bloke ay direktang nakakaapekto sa hindi gaanong nangingibabaw na bloke.

Ang kontrol ng feedback at input ng feedback ay mas kumplikado dahil ang mga ito ay nagsasangkot ng pag-ulit o recursion. Ibig sabihin, ang mga output mula sa isang trabaho ay nakakaimpluwensya sa hinaharap na pagpapatupad ng iba pang mga trabaho, na pagkatapos ay nakakaapekto sa orihinal na trabaho.

Ang kontrol ng feedback ay nangyayari pagkatapos; kapag ang output ng ilang bloke ay nakakaapekto sa isang bloke na may higit na pangingibabaw.

Ang mga relasyon sa output-mekanismo ay bihira. Sinasalamin nila ang isang sitwasyon kung saan ang output ng isang function ay nagiging isang paraan sa isang layunin para sa isa pa.

kanin. 2.4. Feedback sa pag-login

kanin. 2.5. Feedback ng Pamamahala

Ang mga relasyon sa output-mekanismo ay katangian ng paglalaan ng mga pinagmumulan ng mapagkukunan (hal., mga kinakailangang kasangkapan, sinanay na tauhan, pisikal na espasyo, kagamitan, pondo, materyales).

Sa IDEF0, ang isang arko ay bihirang kumakatawan sa isang bagay. Karaniwan itong sumasagisag sa isang hanay ng mga bagay. Dahil ang mga arko ay kumakatawan sa mga koleksyon ng mga bagay, maaari silang magkaroon ng maraming panimulang punto (mga mapagkukunan) at mga punto ng pagtatapos (mga destinasyon). Samakatuwid, ang mga arko ay maaaring sumanga at kumonekta iba't ibang paraan. Ang buong arko o bahagi nito ay maaaring umabot mula sa isa o higit pang mga bloke at magtatapos sa isa o higit pang mga bloke.

Ang mga sumasanga na arko, na inilalarawan bilang mga nagliliwanag na linya, ay nangangahulugan na ang lahat o bahagi ng mga nilalaman ng mga arko ay maaaring lumitaw sa bawat sangay. Ang isang arko ay palaging may label bago ang isang sangay upang bigyan ng pangalan ang buong hanay. Bukod pa rito, ang bawat sangay ng isang arko ay maaaring may label o hindi ayon sa mga sumusunod na panuntunan:

ang mga walang label na sanga ay naglalaman ng bigat ng mga bagay na tinukoy sa arc label bago ang sangay;
ang mga sanga na may label pagkatapos ng branch point ay naglalaman ng lahat o bahagi ng mga bagay na tinukoy sa arc label bago ang branch.

Ang pagsasama ng arko sa IDEFO, na inilalarawan bilang mga linyang nagtatagpo, ay nagpapahiwatig na ang mga nilalaman ng bawat sangay ay napupunta upang bumuo ng isang label para sa arko na nagreresulta mula sa pagsasama ng orihinal na mga arko. Pagkatapos ng isang pagsasama, ang nagreresultang arko ay palaging minarkahan upang ipahiwatig ang bagong hanay ng mga bagay na nagreresulta mula sa pagsasama. Bukod pa rito, maaaring markahan o hindi ang bawat sangay bago pagsamahin, ayon sa mga sumusunod na panuntunan:

kanin. 2.6. Koneksyon ng output-mekanismo

ang mga sanga na walang label ay naglalaman ng bigat ng mga bagay na tinukoy sa nakabahaging etiketa ng arko pagkatapos ng pagsasama;
ang mga sanga na minarkahan bago pagsamahin ay naglalaman ng lahat o ilan sa mga bagay na nakalista sa karaniwang label pagkatapos ng pagsasama,

Quantitative chart analysis

Upang magsagawa ng quantitative analysis ng mga diagram, inilista namin ang mga indicator ng modelo:

bilang ng mga bloke sa diagram - N;
antas ng pagkabulok ng diagram - L;
balanse ng diagram - SA;
bilang ng mga arrow na kumokonekta sa block - A

Nalalapat ang hanay ng mga salik na ito sa bawat diagram ng modelo. Ang mga sumusunod ay maglilista ng mga rekomendasyon sa mga nais na halaga ng mga kadahilanan sa diagram.

Kinakailangan na magsikap upang matiyak na ang bilang ng mga bloke sa mga diagram ng mas mababang antas ay mas mababa kaysa sa bilang ng mga bloke sa mga diagram ng magulang, ibig sabihin, habang tumataas ang antas ng agnas, bumababa ang koepisyent. Kaya, ang pagbaba ng koepisyent na ito ay nagpapahiwatig na. na habang ang modelo ay nabubulok, ang mga pag-andar ay dapat na gawing simple, samakatuwid, ang bilang ng mga bloke ay dapat bumaba.

Dapat balanse ang mga diagram. Nangangahulugan ito na sa loob ng isang diagram ang sitwasyon na ipinapakita sa Fig. 1 ay hindi dapat mangyari. 2.7: ang trabaho 1 ay may mas maraming paparating na arrow at control arrow kaysa sa mga papalabas na arrow. Dapat ito ay nabanggit na rekomendasyong ito maaaring hindi matupad sa mga modelong naglalarawan mga proseso ng produksyon. Halimbawa, kapag naglalarawan ng isang pamamaraan ng pagpupulong, ang isang bloke ay maaaring magsama ng maraming mga arrow na naglalarawan sa mga bahagi ng isang produkto, at isang arrow na lumalabas - ang tapos na produkto.

kanin. 2.7. Halimbawa ng hindi balanseng tsart

Ipakilala natin ang koepisyent ng balanse ng diagram

Ito ay kinakailangan upang magsikap Q ay minimal para sa tsart.

Bilang karagdagan sa pag-aaral ng mga graphic na elemento ng diagram, kinakailangang isaalang-alang ang mga pangalan ng mga bloke. Upang suriin ang mga pangalan, isang diksyunaryo ng elementarya (walang halaga) na mga function ng modelong sistema ay pinagsama-sama. Sa katunayan, dapat isama ng diksyunaryong ito ang mga function ng mas mababang antas ng decomposition ng diagram. Halimbawa, para sa isang modelo ng database, ang mga function na "hanapin ang isang talaan" at "magdagdag ng isang tala sa database" ay maaaring elementarya, habang ang function na "pagrehistro ng gumagamit" ay nangangailangan ng karagdagang paglalarawan.

Pagkatapos bumuo ng isang diksyunaryo at pag-compile ng isang pakete ng mga diagram ng system, kinakailangang isaalang-alang ang mas mababang antas ng modelo. Kung may mga tugma sa pagitan ng mga pangalan ng mga bloke ng diagram at mga salita mula sa diksyunaryo, nangangahulugan ito na nakamit na ang sapat na antas ng pagkabulok. Ang coefficient na quantitatively na sumasalamin sa criterion na ito ay maaaring isulat bilang L*C- produkto ng antas ng modelo at ang bilang ng mga tugma ng mga pangalan ng block na may mga salita mula sa diksyunaryo. Kung mas mababa ang antas ng modelo (mas malaking L), mas mahalaga ang mga tugma.

Toolkit ng BPWin

Kapag sinimulan mo ang BPWin, ang pangunahing toolbar, tool palette, at Model Explorer ay lilitaw bilang default.

Kapag lumilikha ng isang bagong modelo, lilitaw ang isang dialog kung saan dapat mong ipahiwatig kung ang modelo ay gagawing muli, o ito ay bubuksan mula sa imbakan ng ModelMart, ipasok ang pangalan ng modelo at piliin ang pamamaraan kung saan itatayo ang modelo ( Larawan 2.8).

Fig.2.8 Dialog ng paglikha ng modelo

Sinusuportahan ng BPWin ang tatlong pamamaraan - IDEF0, IDEF3 at DFD. Sa BPWin posible na bumuo ng mga halo-halong modelo, ibig sabihin, ang modelo ay maaaring sabay na maglaman ng parehong IDEF0 at IDEF3 diagram at DFD. Ang komposisyon ng tool palette ay awtomatikong nagbabago kapag lumipat ka mula sa isang notasyon patungo sa isa pa.

Ang isang modelo sa BPWin ay itinuturing bilang isang hanay ng mga gawa, na ang bawat isa ay gumagana sa isang tiyak na hanay ng data. Kung nag-click ka sa anumang object ng modelo gamit ang kaliwang pindutan ng mouse, lilitaw ang isang pop-up menu ng konteksto, ang bawat item ay tumutugma sa editor ng isang property ng object.

Halimbawa

Ang pagbuo ng isang modelo ng system ay dapat magsimula sa pag-aaral ng lahat ng mga dokumentong naglalarawan sa paggana nito. Ang isa sa mga dokumentong ito ay ang teknikal na detalye, lalo na ang mga seksyon na "Layunin ng pag-unlad", "Mga layunin at layunin ng system" at "Mga functional na katangian ng system".

Pagkatapos pag-aralan ang mga pinagmumulan ng dokumento at pakikipanayam sa mga customer at user ng system, kinakailangan na bumalangkas ng layunin ng pagmomodelo at matukoy ang punto ng view sa modelo. Isaalang-alang natin ang teknolohiya ng pagtatayo nito gamit ang halimbawa ng sistema ng "University Employment Service", ang mga pangunahing kakayahan na inilarawan sa gawaing laboratoryo No.

Bumuo tayo ng layunin ng pagmomodelo: upang ilarawan ang paggana ng system, na mauunawaan ng gumagamit nito, nang hindi naglalagay ng mga detalye na nauugnay sa pagpapatupad. Bubuo kami ng modelo mula sa pananaw ng mga gumagamit (mag-aaral, guro, tagapangasiwa, tanggapan ng dean, kumpanya).

Magsimula tayo sa pamamagitan ng pagbuo ng diagram ng IDEF0 ng konteksto Ayon sa paglalarawan ng system, ang pangunahing tungkulin ay ang pagsilbihan ang mga kliyente nito sa pamamagitan ng pagproseso ng mga kahilingan mula sa kanila. Kaya, tinukoy namin ang tanging trabaho ng diagram ng konteksto bilang "Paglingkuran ang kliyente ng system." Susunod, tinutukoy namin ang data ng input at output, pati na rin ang mga mekanismo at kontrol.

Upang makapaglingkod sa isang kliyente, kinakailangan na irehistro siya sa system, buksan ang access sa database at iproseso ang kanyang kahilingan. Ang input data ay magiging "pangalan ng kliyente", "password ng kliyente", "database ng pinagmulan", "kahilingan ng kliyente". Ang pagpapatupad ng isang kahilingan ay humahantong sa alinman sa pagtanggap ng impormasyon mula sa system o sa pagbabago ng mga nilalaman ng database (halimbawa, kapag nagko-compile ng mga pagsusuri ng eksperto), kaya ang output data ay magiging "mga ulat" at "binagong database". Ang proseso ng pagpoproseso ng kahilingan ay isasagawa ng system monitor sa ilalim ng kontrol ng administrator.

Diagram ng konteksto

Kaya, tinutukoy namin ang diagram ng konteksto ng system (Larawan 2.9).

Larawan 2.9. System Context Diagram

I-decompose natin ang context diagram, na naglalarawan sa sequence ng customer service:

Pagtukoy sa antas ng pag-access sa system.
Pagpili ng subsystem.
Pag-access sa subsystem.
Pagbabago ng database (kung kinakailangan).

Nakukuha namin ang diagram na ipinapakita sa Fig. 2.10.

Matapos makumpleto ang decomposition ng context diagram, magpatuloy sa decomposition ng susunod na level diagram. Karaniwan, kapag isinasaalang-alang ang pangatlo at mas mababang antas, ang mga modelo ay bumalik sa mga diagram ng magulang at ayusin ang mga ito.

kanin. 2.10. Pagkabulok ng gawaing "Serbisyo, system client"

Binubulok namin nang sunud-sunod ang lahat ng mga bloke ng nagresultang diagram. Ang unang hakbang sa pagtukoy ng antas ng pag-access sa system ay upang matukoy ang kategorya ng user. Hinahanap ang pangalan ng kliyente sa database ng gumagamit, na tinutukoy ang kategorya nito. Ayon sa isang tiyak na kategorya, ang mga kapangyarihan na ipinagkaloob sa gumagamit ng system ay tinutukoy. Susunod, ang pamamaraan para sa pag-access sa system ay isinasagawa, pagsuri sa pangalan ng pag-access at password. Sa pamamagitan ng pagsasama-sama ng impormasyon tungkol sa mga awtoridad at antas ng pag-access sa system, nabuo ang isang hanay ng mga pinapayagang aksyon para sa user. Kaya, ang pagtukoy sa antas ng pag-access sa system ay magmumukhang ipinapakita sa Fig. 2.11.

kanin. 2.11. Pagkabulok ng gawain "Pagtukoy sa antas ng pag-access sa system"

Matapos makumpleto ang pamamaraan ng pag-access ng system, sinusuri ng monitor ang kahilingan ng kliyente, pinipili ang subsystem na magpoproseso ng kahilingan. Ang agnas ng gawaing "Apela sa isang subsystem" ay hindi tumutugma sa layunin at punto ng view ng modelo. Ang gumagamit ng system ay hindi interesado sa mga panloob na algorithm ng operasyon nito. SA sa kasong ito Mahalaga para sa kanya na ang pagpili ng subsystem ay awtomatikong gagawin, nang wala ang kanyang interbensyon, kaya ang agnas ng pag-access sa subsystem ay magpapalubha lamang sa modelo.

Binubulok namin ang gawaing "Pagproseso ng kahilingan ng kliyente", na isinagawa ng subsystem para sa pagproseso ng mga kahilingan, pagtukoy sa mga kategorya at kapangyarihan ng mga user. Bago maghanap ng sagot sa isang query, dapat mong buksan ang database (kumonekta dito). Sa pangkalahatan, ang database ay maaaring matatagpuan sa isang malayong server, kaya maaaring kailanganin na magtatag ng isang koneksyon dito. Tukuyin natin ang pagkakasunud-sunod ng trabaho:

Pagbubukas ng database.
Isinasagawa ang kahilingan.
Pagbuo ng mga ulat.

Pagkatapos buksan ang database, kailangan mong ipaalam sa system na ang isang koneksyon sa database ay naitatag, pagkatapos ay isagawa ang kahilingan at bumuo ng mga ulat para sa user (Larawan 2.12).

Dapat tandaan na ang "Query Execution" ay kinabibilangan ng gawain ng iba't ibang mga subsystem. Halimbawa, kung ang kahilingan ay may kasamang pagsubok, ito ay isasagawa ng propesyonal at mga pagsusulit sa sikolohikal. Sa yugto ng pagpapatupad ng query, maaaring kailanganin na baguhin ang mga nilalaman ng database, halimbawa, kapag nag-compile ng mga pagtatasa ng eksperto. Samakatuwid, kinakailangang ibigay ang posibilidad na ito sa diagram.

kanin. 2.12.

Pagsasaayos ng tsart

Kapag sinusuri ang nagresultang diagram, ang tanong ay lumitaw: anong mga patakaran ang ginagamit upang makabuo ng mga ulat? Kinakailangan na magkaroon ng mga paunang nabuong template na gagamitin upang pumili mula sa database, at ang mga template na ito ay dapat tumutugma sa mga query at dapat na paunang natukoy. Bilang karagdagan, ang kliyente ay dapat bigyan ng pagkakataon na pumili ng anyo ng ulat.

Ayusin natin ang diagram sa pamamagitan ng pagdaragdag ng mga arrow na "Mga Template ng Ulat" at "Mga Kahilingan sa Pagbabago sa Database" at ang "System Client" na tunnel arrow. Ang tunneling ng "System Client" ay ginagamit upang hindi ilagay ang arrow sa tuktok na diagram, dahil ang function ng pagpili ng form ng ulat ay hindi sapat na mahalaga upang maipakita sa parent diagram.

Ang pagpapalit ng diagram ay magreresulta sa mga pagsasaayos sa lahat ng parent diagram (Fig. 2.13 - 2.15).

Maipapayo na i-decompose ang gawaing "Query Execution" gamit ang isang DFD diagram (laboratory work No. 3), dahil ang pamamaraan ng IDEF0 ay isinasaalang-alang ang system bilang isang hanay ng mga magkakaugnay na gawain, na hindi sumasalamin nang maayos sa mga proseso ng pagproseso ng impormasyon.

kanin. 2.13. Pagkabulok ng gawaing "Pagproseso ng kahilingan ng kliyente"

kanin. 2.14. Decomposition ng trabaho "System client service" (opsyon 2)

kanin. 2.15. System context diagram (opsyon 2)

Lumipat tayo sa decomposition ng huling bloke na "Pagbabago ng Database". Mula sa pananaw ng kliyente, ang data ng system ay matatagpuan sa isang database. Sa katotohanan, mayroong anim na database sa system:

database ng gumagamit,
database ng mag-aaral, (opsyon 2)
database ng bakante,
database ng pagganap ng akademiko,
Pagsubok sa database,
DB ng mga pagtatasa ng eksperto,
resume ng DB.

Ayon sa layunin ng pagmomodelo, mahalagang maunawaan ng kliyente na ang natanggap na data ay hindi agad na-update sa system, ngunit dumadaan sa karagdagang yugto ng pagproseso at kontrol. Maaaring buuin ang algorithm ng pagbabago sa sumusunod na paraan:

Ang database kung saan babaguhin ang impormasyon ay tinutukoy.
Ang operator ay bumubuo ng isang pansamantalang set ng data at ibinibigay ito sa administrator.
Kinokontrol ng administrator ang data at ipinapasok ito sa database.

Ang modelong ito ay maaaring ipatupad sa ibang paraan, sa pamamagitan ng pagbibigay ng kakayahang direktang i-update ang database kapag hiniling, na lampasan ang proseso ng kontrol ng data. Sa kasong ito, kinakailangan upang matiyak ang integridad ng database upang maiwasan ang pinsala. Sa kasong ito, magiging ganito ang diagram (Larawan 2.17).

kanin. 2.16. Pagkabulok ng gawaing "Pagbabago ng database"

kanin. 2.17. Pagkabulok ng gawaing "Pagbabago ng database" (opsyon 2) Para sa unang opsyon, ipinapakita sa Fig. 2.12

Ang pagsasagawa ng karagdagang decomposition ng "Mga Pagbabago sa Database" ay magpapalubha sa modelo, na nagpapaliwanag kung paano isinasagawa ang pisikal na pagbabago ng database sa system. Sa kasong ito, ang gumagamit ay hindi makakatanggap ng anumang karagdagang impormasyon tungkol sa pagpapatakbo ng sistema ng serbisyo sa pagtatrabaho. Maipapayo na mabulok ang gawaing ito sa panahon ng proseso ng disenyo ng isang database system sa yugto ng paglikha ng isang lohikal na modelo ng database.

Isasagawa ang isang decomposition ng Query Execution work sa susunod na lab, na naglalarawan ng paggamit ng mga DFD diagram upang ilarawan ang mga proseso sa pagproseso ng impormasyon.

Magsagawa tayo ng quantitative analysis ng mga modelong ipinapakita sa Fig. 2.12 at 2.13, ayon sa pamamaraang inilarawan sa itaas. Isaalang-alang natin ang pag-uugali ng coefficient ^ para sa mga modelong ito. Ang parent diagram na "Pagproseso ng kahilingan ng kliyente" ay may coefficient na 4/2 = 2, at ang decomposition diagram ay may 3/3 = 1. Bumababa ang halaga ng coefficient, na nagpapahiwatig ng pagpapasimple ng paglalarawan ng mga function bilang antas ng bumababa ang modelo.

Isaalang-alang natin ang pagbabago sa koepisyent K b sa dalawang variant ng modelo.

para sa pangalawang opsyon

Coefficient K b hindi nagbabago ang halaga nito, samakatuwid, ang balanse ng diagram ay hindi nagbabago.

Ipagpalagay namin na ang antas ng agnas ng mga diagram na isinasaalang-alang ay sapat upang ipakita ang layunin ng pagmomodelo, at sa mga diagram ng mas mababang Antas, ang mga elementarya na pag-andar ay ginagamit bilang mga pangalan ng trabaho (mula sa punto ng view ng gumagamit ng system) .

Ang pagbubuod ng isinasaalang-alang na halimbawa, kinakailangang tandaan ang kahalagahan ng pagsasaalang-alang ng ilang mga opsyon sa diagram kapag nagmomodelo ng isang sistema. Ang ganitong mga opsyon ay maaaring lumitaw kapag nag-aayos ng mga diagram, tulad ng ginawa sa "Pagproseso ng isang Kahilingan ng Kliyente" o kapag lumilikha ng mga alternatibong pagpapatupad ng mga function ng system (pagbubulok ng gawaing "Pagbabago ng Database"). Ang pagrepaso sa mga opsyon ay nagbibigay-daan sa iyong piliin ang pinakamahusay at isama ito sa isang pakete ng mga diagram para sa karagdagang pagsasaalang-alang.

Kontrolin ang mga tanong

Listahan Mga tanong sa seguridad:

Ano ang isang modelo sa notasyon ng IDEF0?
Ano ang ibig sabihin ng mga trabaho sa IDEF0?
Ano ang pagkakasunud-sunod ng pagbibigay ng pangalan sa mga gawa?
Ilang mga gawa ang dapat na nasa isang diagram?
Ano ang pagkakasunod-sunod ng pangingibabaw?
Paano inayos ang mga akda ayon sa prinsipyo ng pangingibabaw?
Ano ang layunin ng mga gilid ng trabahong mga parihaba sa mga diagram?
Ilista ang mga uri ng mga arrow.
Pangalanan ang mga uri ng relasyon.
Ano ang tawag sa mga boundary arrow?
Ipaliwanag ang prinsipyo ng pagpapangalan ng sumasanga at pagsasama-sama ng mga arrow.
Anong mga pamamaraan ang sinusuportahan ng BPWin?
Ilista ang mga pangunahing elemento ng pangunahing window ng BPWin.
Ilarawan ang proseso ng paglikha ng bagong modelo sa BPWin.
Paano gumawa ng mga koneksyon sa pagitan ng mga gawa?
Paano magtakda ng pangalan ng trabaho.
Ilarawan ang proseso ng pagkasira ng trabaho.
Paano magdagdag ng trabaho sa isang diagram?
Paano lutasin ang mga tunneled arrow?
Maaari bang maglaman ang isang modelo ng BPWin ng mga diagram ng maraming pamamaraan?

Gennady Vernikov

Sa kasalukuyan, sa Russia mayroong isang matalim na pagtaas sa interes sa mga pamantayan ng pamamahala na karaniwang tinatanggap sa Kanluran, gayunpaman, sa aktwal na kasanayan sa pamamahala mayroong isang napakahalagang punto. Maraming mga tagapamahala ang maaari pa ring maguluhan sa isang direktang tanong tungkol sa istraktura ng organisasyon kumpanya o tungkol sa scheme ng mga kasalukuyang proseso ng negosyo. Ang pinaka-advanced na mga tagapamahala na regular na nagbabasa ng mga pang-ekonomiyang peryodiko, bilang isang panuntunan, ay nagsisimulang gumuhit ng mga hierarchical na diagram na sila lamang ang nakakaintindi, ngunit sa prosesong ito ay kadalasang mabilis nilang naaabot ang isang dead end. Ang parehong naaangkop sa mga empleyado at tagapamahala ng iba't ibang mga serbisyo at functional na departamento. Sa karamihan ng mga kaso, ang tanging hanay ng mga nakasaad na panuntunan kung saan dapat gumana ang isang negosyo ay isang hanay ng mga indibidwal na regulasyon at mga paglalarawan ng trabaho. Kadalasan, ang mga dokumentong ito ay pinagsama-sama higit sa isang taon na ang nakalilipas, ay hindi maganda ang pagkakaayos at hindi nauugnay sa isa't isa at, bilang isang resulta, nagtitipon lamang ng alikabok sa mga istante. Sa ngayon, ang gayong diskarte ay nabigyang-katwiran, dahil sa panahon ng pagbuo ng Russian Ekonomiya ng merkado ang konsepto ng kumpetisyon ay halos wala, at walang partikular na pangangailangan upang kalkulahin ang mga gastos - ang mga kita ay napakalaki. Bilang resulta nito, sa nakalipas na dalawang taon nakita namin ang isang ganap na nauunawaan na larawan: malalaking kumpanya, na lumago noong unang bahagi ng 90s, ay unti-unting nawawalan ng kanilang mga posisyon, hanggang sa ganap na umalis sa merkado. Ito ay bahagyang dahil sa ang katunayan na ang mga pamantayan ng pamamahala ay hindi ipinakilala sa negosyo ang konsepto ng isang functional na modelo ng aktibidad at misyon ay ganap na wala. Sa pamamagitan ng pagmomodelo ng iba't ibang bahagi ng aktibidad, maaari mong lubos na masuri ang mga bottleneck sa pamamahala at i-optimize ang pangkalahatang scheme ng negosyo. Ngunit, tulad ng alam mo, sa anumang negosyo, tanging ang mga proyektong direktang nagdadala ng kita ang may pinakamataas na priyoridad, kaya ang tanong ng pagsusuri sa mga aktibidad at muling pag-aayos ng mga ito ay kadalasang dumarating lamang sa panahon ng isang makabuluhang krisis sa pamamahala ng kumpanya.

Sa pagtatapos ng 1990s, nang ang merkado ay naging mas mapagkumpitensya at ang kakayahang kumita ng mga negosyo ay nagsimulang bumagsak nang husto, ang mga tagapamahala ay nakaranas ng napakalaking kahirapan sa pagsisikap na i-optimize ang mga gastos upang ang mga produkto ay nanatiling parehong kumikita at mapagkumpitensya. Sa sandaling ito na ang pangangailangan na magkaroon sa harap ng iyong mga mata ng isang modelo ng aktibidad ng negosyo na magpapakita ng lahat ng mga mekanismo at prinsipyo ng pagkakaugnay ng iba't ibang mga subsystem sa loob ng isang negosyo ay naging ganap na malinaw.

Ang mismong konsepto ng "pagmomodelo ng proseso ng negosyo" ay dumating sa pang-araw-araw na buhay ng karamihan sa mga analyst nang sabay-sabay sa paglitaw sa merkado ng mga kumplikadong produkto ng software na idinisenyo para sa kumplikadong automation ng pamamahala ng negosyo. Ang ganitong mga sistema ay palaging nagpapahiwatig ng isang malalim na pagsusuri bago ang proyekto ng mga aktibidad ng kumpanya. Ang resulta ng pagsusulit na ito ay opinyon ng eksperto, kung saan, sa magkahiwalay na mga talata, ang mga rekomendasyon ay ginawa upang alisin ang mga bottleneck sa pamamahala ng aktibidad. Batay sa konklusyon na ito, kaagad bago ang proyekto ng pagpapatupad ng isang sistema ng automation, ang isang tinatawag na muling pag-aayos ng mga proseso ng negosyo ay isinasagawa, kung minsan ay medyo seryoso at masakit para sa kumpanya. Ito ay natural; ito ay palaging mahirap na pilitin ang isang koponan na nabuo sa mga nakaraang taon na "mag-isip sa isang bagong paraan." Ang ganitong mga komprehensibong survey ng mga negosyo ay palaging kumplikado at malaki ang pagkakaiba-iba sa bawat kaso. Upang malutas ang mga naturang problema ng pagmomodelo ng mga kumplikadong sistema, may mga mahusay na nasubok na mga pamamaraan at pamantayan. Kasama sa mga pamantayang ito ang pamilya ng mga pamamaraan ng IDEF. Sa tulong nila, mabisa mong maipapakita at masuri ang mga pattern ng aktibidad ng isang malawak na hanay ng mga kumplikadong system sa iba't ibang konteksto. Kasabay nito, ang lawak at lalim ng pagsusuri ng mga proseso sa system ay tinutukoy ng nag-develop mismo, na ginagawang posible na hindi ma-overload ang nilikha na modelo na may hindi kinakailangang data. Sa kasalukuyan, kasama sa pamilya ng IDEF ang mga sumusunod na pamantayan:

IDEF0 - functional modeling methodology. Gamit ang visual na graphic na wika na IDEF0, lumilitaw ang system na pinag-aaralan sa mga developer at analyst sa anyo ng isang hanay ng mga magkakaugnay na function (mga functional block - sa mga termino ng IDEF0). Bilang isang tuntunin, ang pagmomodelo ng IDEF0 ay ang unang hakbang sa pag-aaral ng anumang sistema;

Ang IDEF1 ay isang pamamaraan para sa pagmomodelo ng mga daloy ng impormasyon sa loob ng isang system, na nagbibigay-daan sa iyong ipakita at suriin ang kanilang istraktura at mga relasyon;

IDEF1X (IDEF1 Extended) - pamamaraan para sa pagbuo ng mga relational na istruktura. Ang IDEF1X ay kabilang sa uri ng Entity-Relationship ng mga pamamaraan at karaniwang ginagamit upang magmodelo ng mga relational database na nauugnay sa system na pinag-uusapan;

Ang IDEF2 ay isang pamamaraan para sa dynamic na pagmomodelo ng mga system development. Dahil sa napakaseryosong paghihirap sa pagsusuri ng mga dinamikong sistema, ang pamantayang ito ay halos inabandona, at ang pag-unlad nito ay tumigil sa simula pa lamang. paunang yugto. Gayunpaman, sa kasalukuyan ay may mga algorithm at ang kanilang mga pagpapatupad sa computer na ginagawang posible na baguhin ang isang hanay ng mga static na IDEF0 diagram sa mga dynamic na modelo na binuo batay sa "kulay na Petri nets" (CPN - Color Petri Nets);

Ang IDEF3 ay isang pamamaraan para sa pagdodokumento ng mga prosesong nagaganap sa isang sistema, na ginagamit, halimbawa, sa pananaliksik teknolohikal na proseso sa mga negosyo. Inilalarawan ng IDEF3 ang senaryo at pagkakasunud-sunod ng mga operasyon para sa bawat proseso. Ang IDEF3 ay may direktang kaugnayan sa pamamaraan ng IDEF0 - ang bawat function (functional block) ay maaaring katawanin bilang isang hiwalay na proseso gamit ang IDEF3;

Ang IDEF4 ay isang pamamaraan para sa pagbuo ng mga object-oriented system. Binibigyang-daan ka ng mga tool ng IDEF4 na biswal na ipakita ang istruktura ng mga bagay at ang pinagbabatayan na mga prinsipyo ng kanilang pakikipag-ugnayan, sa gayon ay nagbibigay-daan sa iyong pag-aralan at i-optimize ang mga kumplikadong object-oriented system;

Ang IDEF5 ay isang pamamaraan para sa ontological na pananaliksik ng mga kumplikadong sistema. Gamit ang pamamaraan ng IDEF5, ang ontology ng isang system ay maaaring ilarawan gamit ang isang tiyak na diksyunaryo ng mga termino at panuntunan, batay sa kung saan ang mga maaasahang pahayag tungkol sa estado ng system na isinasaalang-alang sa isang punto ng oras ay maaaring mabuo. Batay sa mga pahayag na ito, iginuhit ang mga konklusyon karagdagang pag-unlad system at ang pag-optimize nito ay isinasagawa.
Sa artikulong ito, titingnan natin ang pinakakaraniwang ginagamit na functional modeling methodology, IDEF0.

Kasaysayan ng pamantayan ng IDEF0

Ang pamamaraan ng IDEF0 ay maaaring ituring na susunod na yugto sa pagbuo ng kilalang graphical na wika para sa paglalarawan ng mga functional system na SADT (Structured Analysis and Design Teqnique). Ilang taon na ang nakalilipas, isang libro na may parehong pangalan ang inilathala sa Russia sa isang maliit na edisyon, na nakatuon sa paglalarawan ng mga pangunahing prinsipyo ng pagbuo ng mga diagram ng SADT. Sa kasaysayan, ang IDEF0 bilang isang pamantayan ay binuo noong 1981 bilang bahagi ng isang malawak na programa ng automation mga negosyong pang-industriya, na may pangalang ICAM (Integrated Computer Aided Manufacturing) at iminungkahi ng Department of the US Air Force. Sa totoo lang, minana ng pamilya ng mga pamantayan ng IDEF ang pagtatalaga nito mula sa pangalan ng programang ito (IDEF=ICAM DEFinition). Sa proseso ng praktikal na pagpapatupad, ang mga kalahok sa programa ng ICAM ay nahaharap sa pangangailangan na bumuo ng mga bagong pamamaraan para sa pagsusuri ng mga proseso ng pakikipag-ugnayan sa mga sistemang pang-industriya. Bukod dito, bilang karagdagan sa isang pinahusay na hanay ng mga pag-andar para sa paglalarawan ng mga proseso ng negosyo, ang isa sa mga kinakailangan para sa bagong pamantayan ay ang pagkakaroon ng isang epektibong pamamaraan para sa pakikipag-ugnayan sa loob ng balangkas ng "analyst-specialist". Sa madaling salita, ang bagong pamamaraan ay dapat na payagan ang pangkatang gawain na lumikha ng isang modelo, na may direktang pakikilahok lahat ng analyst at espesyalista na kasangkot sa proyekto.

Bilang resulta ng paghahanap para sa mga naaangkop na solusyon, ipinanganak ang IDEF0 functional modeling methodology. Mula noong 1981, ang pamantayan ng IDEF0 ay sumailalim sa ilang maliliit na pagbabago, karamihan ay may likas na paghihigpit, at ang pinakabagong edisyon nito ay inilabas noong Disyembre 1993 ng US National Institute of Standards and Technology (NIST).

Mga Pangunahing Elemento at Konsepto ng IDEF0

Ang graphic na wika ng IDEF0 ay nakakagulat na simple at magkatugma. Ang pamamaraan ay batay sa apat na pangunahing konsepto.

Ang una sa mga ito ay ang konsepto ng isang functional block (Kahon ng Aktibidad). Ang isang functional block ay graphic na inilalarawan bilang isang parihaba (tingnan ang Fig. 1) at kumakatawan sa isang partikular na function sa loob ng system na isinasaalang-alang. Ayon sa mga kinakailangan ng pamantayan, ang pangalan ng bawat functional block ay dapat mabalangkas sa pandiwang mood (halimbawa, "gumawa ng mga serbisyo" at hindi "gumawa ng mga serbisyo").

Ang bawat isa sa apat na panig ng functional block ay may sariling tiyak na kahulugan (role), at:

Ang tuktok na bahagi ay nakatakda sa "Kontrol";

Ang kaliwang bahagi ay nakatakda sa "Input";

Ang kanang bahagi ay nakatakda sa Output;

Ang ilalim na bahagi ay may kahulugang "Mekanismo".

Ang bawat functional block sa loob ng isang sistemang isinasaalang-alang ay dapat magkaroon ng sarili nitong natatanging numero ng pagkakakilanlan.

Figure 1. Function block.

Ang pangalawang haligi ng pamamaraan ng IDEF0 ay ang konsepto ng isang interface arc (Arrow). Ang mga arko ng interface ay madalas ding tinatawag na mga daloy o arrow. Ang isang interface arc ay kumakatawan sa isang elemento ng system na pinoproseso ng isang function block o kung hindi man ay nakakaapekto sa function na kinakatawan ng function na block.

Ang graphical na representasyon ng isang interface arc ay isang unidirectional arrow. Ang bawat interface arc ay dapat may sariling natatanging pangalan (Arrow Label). Kung kinakailangan ng pamantayan, ang pangalan ay dapat na isang anyo ng isang pangngalan.

Depende sa kung aling bahagi lumalapit ang interface arc na ito, ito ay tinatawag na "incoming", "outgoing" o "controlling". Bilang karagdagan, ang "source" (simula) at "sink" (end) ng bawat functional arc ay maaari lamang maging functional blocks, habang ang "source" ay maaari lamang maging output side ng block, at ang "sink" ay maaaring maging anuman. sa natitirang tatlo.

Kapag gumagawa ng mga diagram ng IDEF0, mahalagang ihiwalay nang tama ang mga papasok na interface arc mula sa mga control arc, na kadalasang mahirap. Halimbawa, ipinapakita ng Figure 2 ang bloke ng function na "Process workpiece".

Sa totoong proseso, ang manggagawa na nagsasagawa ng pagproseso ay binibigyan ng workpiece at mga teknolohikal na tagubilin para sa pagproseso (o mga panuntunan sa kaligtasan kapag nagtatrabaho sa makina). Maaaring magkamali na tila ang workpiece at ang dokumento na may mga teknolohikal na tagubilin ay mga papasok na bagay, ngunit hindi ito ang kaso. Sa katunayan, sa prosesong ito, ang workpiece ay naproseso ayon sa mga patakaran na makikita sa mga teknolohikal na tagubilin, na dapat ay kinakatawan ng control interface arc ayon sa pagkakabanggit.

Figure 2.

Isa pang usapin kapag ang mga teknolohikal na tagubilin ay pinoproseso ng punong technologist at ang mga pagbabago ay ginawa sa kanila (Larawan 3). Sa kasong ito, ipinapakita ang mga ito ng isang papasok na arc ng interface, at ang control object ay, halimbawa, mga bagong pamantayang pang-industriya, batay sa kung saan ginawa ang mga pagbabagong ito.

Larawan 3.

Itinatampok ng mga halimbawa sa itaas ang mababaw na katulad na katangian ng mga papasok at kontrol na mga arko ng interface, gayunpaman, para sa mga sistema ng parehong klase ay palaging may ilang mga pagkakaiba. Halimbawa, kapag isinasaalang-alang ang mga negosyo at organisasyon, mayroong limang pangunahing uri ng mga bagay: mga daloy ng materyal (mga bahagi, kalakal, hilaw na materyales, atbp.), Mga daloy ng pananalapi (cash at non-cash, pamumuhunan, atbp.), Mga daloy ng dokumento (komersyal , mga dokumentong pinansyal at organisasyonal), mga daloy ng impormasyon (impormasyon, data sa mga intensyon, mga utos sa salita, atbp.) at mga mapagkukunan (mga empleyado, makina, makina, atbp.). Bukod dito, sa iba't ibang mga kaso, ang lahat ng mga uri ng mga bagay ay maaaring ipakita sa pamamagitan ng papasok at papalabas na mga arko ng interface, pamamahala lamang sa mga nauugnay sa daloy ng mga dokumento at impormasyon, at mga mapagkukunan lamang sa pamamagitan ng mga mekanismo ng arko.

Ang ikatlong pangunahing konsepto ng pamantayan ng IDEF0 ay Decomposition. Ang prinsipyo ng agnas ay ginagamit kapag pinaghiwa-hiwalay ang isang kumplikadong proseso sa mga function ng bahagi nito. Sa kasong ito, ang antas ng detalye ng proseso ay direktang tinutukoy ng developer ng modelo.

Binibigyang-daan ka ng decomposition na unti-unti at nakabalangkas na kumatawan sa modelo ng system sa anyo ng isang hierarchical na istraktura ng mga indibidwal na diagram, na ginagawang mas mababa ang overload at mas madaling matunaw.

Palaging nagsisimula ang modelong IDEF0 sa isang view ng system bilang isang buo - isang functional block na may mga interface arc na lumalampas sa domain na isinasaalang-alang. Ang nasabing diagram na may isang functional block ay tinatawag na context diagram, at itinalaga ng identifier na "A-0".

Ang tekstong nagpapaliwanag para sa diagram ng konteksto ay dapat magpahiwatig ng Layunin ng pagbuo ng diagram sa anyo ng isang maikling paglalarawan at itala ang Pananaw.

Ang pagtukoy at pagpormal sa layunin ng pagbuo ng modelong IDEF0 ay isang napakahalagang punto. Sa epekto, tinutukoy ng layunin ang mga nauugnay na lugar sa sistemang pinag-aaralan na kailangang pagtuunan muna. Halimbawa, kung imodelo natin ang mga aktibidad ng isang negosyo na may layuning bumuo sa hinaharap batay sa modelong ito sistema ng impormasyon, kung gayon ang modelong ito ay magiging kapansin-pansing naiiba mula sa isa na gagawin namin para sa parehong negosyo, ngunit may layuning i-optimize ang mga supply chain.

Tinutukoy ng punto ng view ang pangunahing direksyon ng pag-unlad ng modelo at ang antas ng kinakailangang detalye. Ang isang malinaw na pag-aayos ng punto ng view ay nagbibigay-daan sa iyo upang i-unload ang modelo sa pamamagitan ng pagtanggi sa detalye at pag-aralan ang mga indibidwal na elemento na hindi kinakailangan, batay sa napiling punto ng view sa system. Halimbawa, ang mga functional na modelo ng parehong negosyo mula sa punto ng view ng punong technologist at direktor ng pananalapi ay mag-iiba nang malaki sa direksyon ng kanilang pagdedetalye. Ito ay dahil sa ang katunayan na, sa huli, ang direktor sa pananalapi ay hindi interesado sa mga aspeto ng pagproseso ng mga hilaw na materyales sa mga makina ng produksyon, at ang punong technologist ay hindi nangangailangan ng mga iginuhit na diagram ng mga daloy ng pananalapi. Ang tamang pagpili ng punto ng view ay makabuluhang binabawasan ang oras na ginugol sa pagbuo ng panghuling modelo.

Sa panahon ng proseso ng agnas, ang isang functional block na kumakatawan sa system sa kabuuan sa isang context diagram ay nakadetalye sa isa pang diagram. Ang resultang second-level diagram ay naglalaman ng mga functional block na nagpapakita ng mga pangunahing subfunction ng functional block ng context diagram at tinatawag na Child diagram kaugnay nito (bawat isa sa mga functional block na kabilang sa child diagram ay naaayon na tinatawag na Child Box) . Sa turn, ang ancestor functional block ay tinatawag na parent block na may kaugnayan sa child diagram (Parent Box), at ang diagram kung saan ito nabibilang ay tinatawag na parent diagram (Parent Diagram). Ang bawat isa sa mga subfunction ng isang child diagram ay maaaring mas detalyado sa pamamagitan ng isang katulad na agnas ng katumbas nitong functional block. Mahalagang tandaan na sa bawat kaso ng agnas ng isang functional block, lahat ng interface arc na pumapasok o nagmumula sa block na ito ay nakatakda sa child diagram. Nakakamit nito ang integridad ng istruktura ng modelong IDEF0. Ang prinsipyo ng agnas ay malinaw na ipinakita sa Figure 4. Dapat mong bigyang-pansin ang kaugnayan sa pagitan ng pag-numero ng mga functional na bloke at mga diagram - bawat bloke ay may sariling natatanging serial number sa diagram (ang numero sa ibabang kanang sulok ng rektanggulo) , at ang pagtatalaga sa kanang sulok ay nagpapahiwatig ng bilang ng child diagram para sa block na ito. Ang kawalan ng pagtatalaga na ito ay nagpapahiwatig na walang agnas para sa bloke na ito.

Mayroong madalas na mga kaso kapag ang mga indibidwal na arko ng interface ay walang saysay na patuloy na maisaalang-alang sa mga diagram ng bata sa ibaba ng isang partikular na antas sa hierarchy, o kabaligtaran - ang mga indibidwal na arko ay walang praktikal na kahulugan sa itaas ng isang partikular na antas. Halimbawa, isang interface arc na naglalarawan ng isang "bahagi" sa pasukan sa "Proseso sa" functional block makinang panlalik"Walang saysay na pag-isipan ang mga diagram ng mas matataas na antas - mapapabigat lamang nito ang mga diagram at magpapahirap sa mga ito na maunawaan. Sa kabilang banda, kailangang alisin ang mga indibidwal na "konseptual" na mga arko ng interface at hindi idetalye ang mga ito nang mas malalim. kaysa sa isang tiyak na antas. functional parent block at lumitaw (mula sa "tunnel") lamang sa diagram na ito Sa turn, ang parehong pagtatalaga sa paligid ng dulo (arrow) ng interface arc sa agarang paligid ng receiver block ay nangangahulugan ng katotohanan na sa child diagram ng. ang block na ito ay hindi ipapakita o isasaalang-alang ang arc na ito Kadalasan, nangyayari na ang mga indibidwal na bagay at ang kanilang mga kaugnay na mga arko ay hindi isinasaalang-alang sa ilang mga intermediate na antas ng hierarchy - sa kasong ito, ang mga ito ay unang "isawsaw sa tunnel". at pagkatapos, kung kinakailangan, "bumalik mula sa lagusan".

Ang pinakahuli sa mga konsepto ng IDEF0 ay ang Glossary. Para sa bawat isa sa mga elemento ng IDEF0: mga diagram, mga bloke ng pag-andar, mga arko ng interface, ang umiiral na pamantayan ay nagpapahiwatig ng paglikha at pagpapanatili ng isang hanay ng mga katumbas na kahulugan, mga keyword, mga pahayag sa pagsasalaysay, atbp. na nagpapakilala sa bagay na ipinapakita ng elementong ito. Ang set na ito ay tinatawag na isang glossary at isang paglalarawan ng kakanyahan ng isang ibinigay na elemento. Halimbawa, para sa control interface arc na "order ng pagbabayad," ang glossary ay maaaring maglaman ng isang listahan ng mga field ng dokumento na naaayon sa arc, ang kinakailangang hanay ng mga visa, atbp. Ang glossary ay magkakasuwato na umaakma sa visual na graphic na wika, na nagbibigay sa mga diagram ng kinakailangang karagdagang impormasyon.

Figure 4. Decomposition ng functional blocks.

Mga prinsipyo para sa paglilimita sa pagiging kumplikado ng mga diagram ng IDEF0

Karaniwan, ang mga modelo ng IDEF0 ay naglalaman ng kumplikado at puro impormasyon, at upang limitahan ang kanilang kasikipan at gawin itong nababasa, ang mga kaukulang limitasyon sa pagiging kumplikado ay pinagtibay sa kaukulang pamantayan:

Limitahan ang bilang ng mga functional block sa diagram sa tatlo hanggang anim. Pinipilit ng itaas na limitasyon (anim) ang taga-disenyo na gumamit ng mga hierarchy kapag naglalarawan ng mga kumplikadong bagay, at ang mas mababang limitasyon (tatlo) ay nagsisiguro na ang kaukulang diagram ay may sapat na detalye upang bigyang-katwiran ang paglikha nito;

Nililimitahan ang bilang ng mga interface arc na angkop para sa isang functional block (lumalabas sa isang functional block) sa apat.
Siyempre, hindi kinakailangan na mahigpit na sundin ang mga paghihigpit na ito, gayunpaman, tulad ng ipinapakita ng karanasan, ang mga ito ay napaka-praktikal sa totoong trabaho.

Disiplina ng pangkatang gawain sa pagbuo ng modelong IDEF0

Paglikha ng isang modelo ng isang pangkat ng mga espesyalista na nauugnay sa iba't ibang mga lugar ng negosyo. Ang pangkat na ito ay tinatawag na Mga May-akda sa mga termino ng IDEF0. Ang pagbuo ng paunang modelo ay isang dinamikong proseso kung saan ang mga may-akda ay nakikipagpanayam sa mga karampatang indibidwal tungkol sa istruktura ng iba't ibang mga proseso. Batay sa mga umiiral na regulasyon, dokumento at resulta ng survey, isang Model Draft ng modelo ang ginawa.

Pamamahagi ng draft para sa pagsusuri, pag-apruba at komento. Sa yugtong ito, ang draft na modelo ay tinatalakay sa isang malawak na hanay ng mga karampatang tao (sa mga tuntunin ng mga mambabasa ng IDEF0) sa negosyo. Sa kasong ito, ang bawat isa sa mga diagram ng draft na modelo ay pinupuna at binibigyang komento sa pamamagitan ng pagsulat, at pagkatapos ay inilipat sa may-akda. Ang may-akda, naman, ay sumasang-ayon din sa pamamagitan ng pagsulat sa kritisismo o tinatanggihan ito, na binabalangkas ang lohika ng desisyon, at ibinalik ang itinamang draft para sa karagdagang pagsasaalang-alang. Ang cycle na ito ay nagpapatuloy hanggang ang mga may-akda at mga mambabasa ay maabot ang isang pinagkasunduan.

Opisyal na pag-apruba ng modelo. Ang napagkasunduang modelo ay inaprubahan ng pinuno ng nagtatrabaho na grupo kung ang mga may-akda ng modelo at mga mambabasa ay walang hindi pagkakasundo tungkol sa kasapatan nito. Ang pangwakas na modelo ay isang magkakaugnay na pagtingin sa negosyo (system) mula sa isang naibigay na punto ng view at para sa isang tiyak na layunin.
Ang kalinawan ng graphic na wika ng IDEF0 ay ginagawang ganap na nababasa ang modelo kahit para sa mga taong hindi nakibahagi sa proyekto ng paglikha nito, pati na rin epektibo para sa mga palabas at presentasyon. Sa hinaharap, batay sa itinayong modelo, ang mga bagong proyekto ay maaaring ayusin na naglalayong gumawa ng mga pagbabago sa negosyo (sa sistema).

Mga tampok ng pambansang kasanayan ng paggamit ng functional modeling gamit ang IDEF0

Sa mga nagdaang taon, ang interes sa Russia sa pamilya ng mga pamamaraan ng IDEF ay patuloy na lumalaki. Palagi kong inoobserbahan ito kapag tinitingnan ang mga istatistika ng mga hit sa aking personal na web page (http://www.vernikov.ru), na maikling inilalarawan ang mga pangunahing prinsipyo ng mga pamantayang ito. Kasabay nito, tatawagin ko ang interes sa mga pamantayan tulad ng IDEF3-5 na teoretikal, at sa IDEF0 ay halos makatwiran. Sa katunayan, ang unang mga tool ng Case na nagpapahintulot sa pagbuo ng mga diagram ng DFD at IDEF0 ay lumitaw sa merkado ng Russia noong 1996, kasabay ng paglabas ng isang sikat na libro sa mga prinsipyo ng pagmomodelo sa mga pamantayan ng SADT.

Gayunpaman, itinuturing pa rin ng karamihan sa mga tagapamahala ang praktikal na aplikasyon ng pagmomodelo sa mga pamantayan ng IDEF bilang isang pagpupugay sa fashion kaysa bilang isang epektibong paraan upang ma-optimize ang umiiral na sistema ng pamamahala ng negosyo. Malamang na ito ay dahil sa isang malinaw na kakulangan ng impormasyon sa praktikal na aplikasyon ang mga pamamaraang ito at may isang kailangang-kailangan na bias ng software para sa karamihan ng mga publikasyon.

Hindi lihim na halos lahat ng mga proyekto ng survey at pagsusuri ng pananalapi at aktibidad sa ekonomiya ang mga negosyo ngayon sa Russia ay sa isang paraan o iba pang konektado sa konstruksiyon mga awtomatikong sistema pamamahala. Salamat dito, ang mga pamantayan ng IDEF, sa pag-unawa ng karamihan, ay naging kondisyon na hindi mapaghihiwalay mula sa pagpapatupad teknolohiya ng impormasyon, kahit na sa kanilang tulong kung minsan maaari mong epektibong malutas ang kahit na maliliit na lokal na problema, literal sa tulong ng isang lapis at papel.

Kapag nagsasagawa ng mga kumplikadong proyekto ng survey ng enterprise, ang pagbuo ng mga modelo sa pamantayan ng IDEF0 ay nagbibigay-daan sa iyo upang malinaw at epektibong ipakita ang buong mekanismo ng mga aktibidad ng negosyo sa kinakailangang konteksto. Gayunpaman, ang pinakamahalagang bagay ay ang mga kakayahan sa pakikipagtulungan na ibinibigay ng IDEF0. Sa aking praktikal na gawain Mayroong maraming mga kaso kapag ang pagtatayo ng modelo ay isinasagawa sa direktang tulong ng mga empleyado ng iba't ibang mga departamento. Kasabay nito, ipinaliwanag sa kanila ng consultant ang mga pangunahing prinsipyo ng IDEF0 at itinuro sa kanila kung paano magtrabaho kasama ang kaukulang software ng application sa medyo maikling panahon. Bilang isang resulta, ang mga empleyado ng iba't ibang mga departamento ay lumikha ng mga diagram ng IDEF ng mga aktibidad ng kanilang functional unit, na dapat na sagutin ang mga sumusunod na katanungan:

Ano ang natatanggap ng departamento bilang input?

Anong mga function at sa anong pagkakasunud-sunod ang ginagawa sa loob ng departamento?

Sino ang may pananagutan sa pagsasagawa ng bawat tungkulin?

Ano ang ginagabayan ng tagapalabas kapag ginagawa ang bawat isa sa mga tungkulin?

Ano ang resulta ng trabaho (output) ng departamento?

Pagkatapos sumang-ayon sa draft na mga diagram sa loob ng bawat partikular na departamento, sila ay tipunin ng consultant sa isang draft na modelo ng enterprise, na nag-uugnay sa lahat ng input at output na elemento. Sa yugtong ito, ang lahat ng mga pagkakaiba sa mga indibidwal na diagram at ang kanilang mga kontrobersyal na lugar ay naitala. Susunod, ang modelong ito ay muling dumadaan sa mga functional na departamento para sa karagdagang koordinasyon at paggawa ng mga kinakailangang pagsasaayos. Bilang isang resulta, sa isang medyo maikling panahon at may kaunting pamumuhunan yamang tao mula sa panig ng kumpanya ng pagkonsulta (at ang mga mapagkukunang ito, tulad ng alam natin, ay napakamahal), ang modelo ng IDEF0 ng negosyo ay nakuha sa prinsipyong "As is", at, mahalaga, kinakatawan nito ang negosyo mula sa posisyon ng mga empleyado na nagtatrabaho dito at lubusang alam ang lahat ng mga nuances, kabilang ang mga impormal. Sa hinaharap, ang modelong ito ay ililipat para sa pagsusuri at pagproseso sa mga analyst ng negosyo, na maghahanap ng mga bottleneck sa pamamahala ng kumpanya at i-optimize ang mga pangunahing proseso, na binabago ang modelong "As Is" sa kaukulang "As It Should Be" representasyon. Batay sa mga pagbabagong ito, ang isang pangwakas na konklusyon ay inisyu, na naglalaman ng mga rekomendasyon para sa muling pag-aayos ng sistema ng pamamahala.

Siyempre, ang ganitong diskarte ay nangangailangan ng isang bilang ng mga hakbang sa organisasyon, lalo na sa bahagi ng pamamahala ng negosyo na sinusuri. Ito ay dahil ang diskarteng ito ay nagsasangkot ng pagtatalaga ng ilang empleyado karagdagang mga responsibilidad sa pagbuo at praktikal na aplikasyon ng mga bagong pamamaraan. Gayunpaman, sa huli, binibigyang-katwiran nito ang sarili nito, dahil ang karagdagang isa o dalawang oras na trabaho ng mga indibidwal na empleyado sa loob ng ilang araw ay maaaring makabuluhang makatipid ng pera sa pagbabayad para sa mga serbisyo sa pagkonsulta sa isang third-party na kumpanya (na sa anumang kaso ay makagambala sa parehong mga empleyado mula sa trabaho na may mga questionnaire at mga tanong). Tulad ng para sa mga empleyado mismo ng negosyo, hindi pa ako nakatagpo ng anumang ipinahayag na pagtutol mula sa kanila sa aking pagsasanay.

Ang konklusyon mula sa lahat ng ito ay maaaring iguhit tulad ng sumusunod: hindi kinakailangan na gumawa ng mga solusyon sa mga karaniwang problema sa iyong sarili sa bawat oras. Sa tuwing nahaharap ka sa pangangailangang pag-aralan ang isa o isa pa functional na sistema(mula sa sistema ng disenyo ng sasakyang pangalangaang hanggang sa proseso ng paghahanda ng isang kumplikadong hapunan) - gumamit ng mga napatunayan at napatunayang pamamaraan sa paglipas ng mga taon. Ang isa sa mga pamamaraang ito ay ang IDEF0, na nagbibigay-daan sa iyong lutasin ang mga kumplikadong problema sa buhay gamit ang mga simple at nauunawaang kasangkapan nito.

Ang isang larawan ay nagkakahalaga ng isang libong salita

Katutubong karunungan

Siyempre, sa teorya, ang tagapamahala ay dapat magkaroon ng isang functional na modelo ng trabaho ng kumpanya, at hindi mahalaga pinag-uusapan natin tungkol sa organisasyon ng warehouse work o tungkol sa IT system (mula sa lead hanggang application). Ngunit sa katotohanan halos hindi ito naging, at samakatuwid, sa proseso ng pag-aaral at paghahanap ng solusyon sa problema ng kliyente, lumikha din ako ng isang functional na modelo ng trabaho ng kumpanya o isang tiyak na proseso (function) sa aking sarili.

Ang ilang mga salita tungkol sa mga pakinabang ng graphics

Tulad ng alam mo, ang mga functional na modelo ng IDEF0 ay palaging mga graphical na diagram. Mayroon silang sariling mga katangian at panuntunan ng komposisyon. Pag-uusapan natin ito sa ibang pagkakataon. Ngayon ay nais kong magbigay ng ilang mga halimbawa ng pagiging epektibo ng mga graphics. Bakit ako nakatutok dito? Malamang, pagkatapos ng aking pahayag tungkol sa pangangailangan para sa isang functional na modelo ng trabaho ng kumpanya, maraming tao ang nag-isip na ang lahat ng ito ay hindi kinakailangan, maaari nilang ipaliwanag sa mga salita kung paano ito o ang function na iyon ay gumagana sa kumpanya. Ito ang gusto kong pag-usapan.

Magsimula tayo sa isang maikling iskursiyon sa kasaysayan. Bumalik tayo sa malayong taon 1877, sa panahon ng Digmaang Ruso-Turkish. Noon ang printer na si Sytin ay unang gumamit ng mga graphics upang ilarawan ang mga operasyong militar. Ngayon ang lahat ng ito ay pamilyar sa amin kapag naglalarawan ng anumang labanan, ang mga card na may mga arrow ay lilitaw sa harap ng aming mga mata, na malinaw na nagpapakita ng kurso ng labanan. At noong mga panahong iyon, ang mga aksyong militar ay inilarawan sa mga salita. Para sa bawat labanan mayroong maraming, maraming mga salita. At sa huli napakahirap intindihin ang nangyayari.

Samakatuwid, ang ideya ni Sytin ay tunay na rebolusyonaryo - nagsimula siyang mag-print ng mga lithographic na kopya ng mga mapa na nagpapahiwatig ng mga kuta at lokasyon ng mga yunit ng militar. Ang mga kard na ito ay tinawag na “Para sa mga Mambabasa ng Pahayagan. Allowance.” Ang ideya ay naging napaka-kaugnay na ang unang edisyon ng "Mga Benepisyo" ay agad na nabili. At pagkatapos ay ang mga naturang aplikasyon ay may malaking pangangailangan. Ang dahilan ay malinaw. Nakatulong ang mga graphic na maunawaan kung ano ang halos imposibleng maunawaan sa mga salita lamang.

Maaari rin akong magbigay ng katulad na halimbawa ng kawalan ng kakayahan ng mga pandiwang paglalarawan mula sa aking sariling kasanayan. Talagang hiniling sa akin ng isa sa aking mga customer na gawin ang pagpapatupad ng isang ERM system para sa kanyang kumpanya. Nang tanungin ko kung mayroon silang anumang mga teknikal na detalye, natanggap ko ang sagot: "Oo, mayroon sila. Ngunit ito ay 400 mga pahina." Kasabay nito, labis na nagreklamo ang kliyente na ang aking mga kasamahan, na nakipag-ugnayan sa kanya kanina, ay maaaring tumanggi sa proyekto nang buo o nag-quote ng malinaw na pagtaas ng mga presyo. Matapos kong makita iyon sa tuntunin ng sanggunian talagang 400 na pahina, at ito ay binubuo lamang ng isang paglalarawan ng teksto, naunawaan ko ang mga dahilan para sa pag-uugali ng mga developer. Ang pagbabasa ng ganoong dami ng teksto, pag-alam dito, pag-unawa sa lahat ng mga nuances para lamang maunawaan ang gawain at pangalanan ang presyo ay talagang napakahirap.

Inalok ko ang kliyenteng ito ng alternatibong opsyon - upang ilarawan ang lahat ng posibleng graphical sa anyo ng mga notasyon. Nagpakita sa kanya ng mga halimbawa ng pagmomodelo. Bilang resulta, muli nilang pinag-iisipan ang kanilang mga kagustuhan at ang disenyo ng mga teknikal na pagtutukoy.

Alam ko rin ang maraming iba pang mga halimbawa kung saan ang graphical na pagmomodelo ng mga proseso ng negosyo ay nakatulong sa aking mga kasamahan, business consultant at developer, at mga negosyante mismo.

Bakit ito mahalaga sa aking trabaho?

Ang aking trabaho ay palaging nagsasangkot ng paggawa ng mga pagbabago sa umiiral na sistema. At upang makagawa ng mga pagbabago at makuha ang ninanais na resulta, kailangan mong pag-aralan kung ano ang mayroon na. At hindi mahalaga kung ano ang eksaktong ginagawa namin - pag-set up o pag-install ng isang CRM system mula sa simula, paglikha ng isang epektibong ERP system, pagsasama ng iba't ibang mga system upang mapataas ang automation ng trabaho sa pangkalahatan. Sa anumang kaso, una, kailangan mong makakuha ng isang ideya ng umiiral na scheme ng trabaho, at pagkatapos lamang nito maaari kang magmungkahi ng ilang mga pagbabago at mag-isip sa mga pagpipilian para sa paglutas ng problema.

Matapos pag-aralan ang kasalukuyang estado ng mga gawain, ako, tulad ng iba pang espesyalista sa labas, ay lumikha Komersyal na alok, kung saan ibinubunyag ko sa mas maraming detalye hangga't maaari ang aking pananaw sa kasalukuyang sitwasyon, pati na rin ang mga aksyon na kailangang gawin upang malutas ang gawain, at, siyempre, ang inaasahang resulta.

Ang ganitong mga ulat sa survey sa trabaho ay napakalaki at tumatagal ng higit sa isang pahina, na, sa isang banda, ay kinakailangan, ngunit sa kabilang banda, nagpapalubha ng pang-unawa. Sa una, tulad ng marami pang iba, naisip ko na ang mga malalaking ulat ay mabuti, dahil ang isang tao ay nagbabayad para sa trabaho at kailangan mong bigyan siya ng mas detalyadong impormasyon hangga't maaari.

Sa katunayan, mahalaga na huwag magbigay ng lakas ng tunog, ngunit upang maihatid ang kakanyahan nang mabilis at ganap hangga't maaari. Ang malalaking volume ng text ay nangangailangan ng oras, na kadalasang kakaunti ng mga negosyante. At pinahihintulutan ako ng mga graphics na bawasan ang dami ng aking panukala at ipakita ang solusyon nang malinaw at sa isang naiintindihan na anyo. Bilang resulta, ang aking mga panukala ay makabuluhang nabawasan, lumitaw ang mga graphics sa kanila, at ang mga pagpapasya upang simulan ang pakikipagtulungan ay nagsimulang gawin nang mas mabilis.

Ito ang dahilan kung bakit gumagamit ako ng mga visual na modelo. Tulad ng alam natin, ang isang larawan ay nagkakahalaga ng isang libong salita. At sa kaso ng paglalarawan ng mga proseso ng negosyo at mga opsyon para sa paggawa ng makabago ng mga pagpapatakbo ng negosyo, totoo nga ito. At ang mga notasyon ng IDEF0 ay angkop na angkop dito.

Ngunit una, maunawaan natin ang mga pangunahing konsepto, kung ano ang mga notasyon, kung bakit kailangan ang mga ito, kung ano ang IDEF0, ano ang mga tampok at bentahe ng pamamaraang ito.

Ano ang notasyon sa paglalarawan ng proseso ng negosyo?

Ang notasyon ay isang format para sa paglalarawan ng proseso ng negosyo, na isang hanay ng mga graphical na bagay na ginagamit sa pagmomodelo, pati na rin ang mga panuntunan sa pagmomodelo.

Sa katunayan, ang mga notasyon ay isang espesyal na graphic na wika na nagbibigay-daan sa iyo upang ilarawan ang gawain ng isang kumpanya at malinaw na ipakita ang pakikipag-ugnayan sa pagitan ng iba't ibang mga departamento, i.e. ilarawan ang mga proseso ng negosyo. Maaaring gamitin ang mga notasyon para sa proseso o functional na pagmomodelo.

Sa pangkalahatan, ang mga notasyon ay maaaring tawaging isang programming language para sa pagtatasa ng negosyo

Ano ang IDEF0?

Ang IDEF0 ay isang functional modeling methodology at graphical notation na idinisenyo upang gawing pormal at ilarawan ang mga proseso ng negosyo. Natatanging tampok Ang IDEF0 ay ang pagbibigay-diin nito sa subordination ng mga bagay. Isinasaalang-alang ng IDEF0 ang mga lohikal na relasyon sa pagitan ng mga trabaho, sa halip na ang kanilang temporal na pagkakasunud-sunod (daloy ng trabaho). Wikipedia

Ang pamantayan ng IDEF0 ay binuo noong 1981 sa USA ng Kagawaran ng Air Force para sa automation ng mga pang-industriyang negosyo. Sa panahon ng proseso ng pagbuo ng software, ang mga developer ay nahaharap sa pangangailangan na bumuo ng mga bagong pamamaraan para sa pagsusuri ng mga proseso ng negosyo. Ang resulta ay ang IDEF0 functional modeling methodology, na gumagamit ng mga espesyal na IDEF0 notation para sa pagsusuri.

Functional na modelo ng kumpanya

Ang functional model ng IDEF0 ay isang hanay ng mga bloke, na ang bawat isa ay isang "itim na kahon" na may mga input at output, mga kontrol at mekanismo na detalyado (nabubulok) sa kinakailangang antas. Ang pinakamahalagang function ay matatagpuan sa itaas na kaliwang sulok. At ang mga function ay konektado sa isa't isa gamit ang mga arrow at paglalarawan ng mga functional block. Bukod dito, ang bawat uri ng arrow o aktibidad ay may sariling kahulugan. Ang modelong ito ay nagpapahintulot sa amin na ilarawan ang lahat ng mga pangunahing uri ng mga proseso, parehong administratibo at organisasyon.

Ang mga arrow ay maaaring:

Papasok – input na nagtatakda ng isang partikular na gawain.
Outgoing – paglabas ng resulta ng aktibidad.
Mga tagapamahala (mula sa itaas hanggang sa ibaba) - mga mekanismo ng kontrol (mga probisyon, tagubilin, atbp.).
Mga mekanismo (mula sa ibaba hanggang sa itaas) - kung ano ang ginagamit upang maisagawa ang kinakailangang gawain.

Magiging mas tumpak na tawagan ang mga papasok at papalabas na arrow na mga papasok at papalabas na arrow, dahil sa Ingles ang mga ito ay tinatawag na Input at Output, ayon sa pagkakabanggit. Ngunit ang mga tampok ng pagsasalin at ang karaniwang mga pangalan ay nakikita na ang mga ito. Gayunpaman, para sa isang tamang pag-unawa sa mga termino, mahalagang tandaan ang kanilang kahulugan sa kasong ito. Kinumpirma rin ito ng katotohanan na ang notasyong ito ay pangunahing nilikha para sa pagbuo ng software, at mas tama na isalin ang mga termino mula sa puntong ito ng view.

Ang mga arrow ay nilalagdaan gamit ang mga pangngalan (karanasan, plano, mga panuntunan), at ang mga bloke ay nilagdaan gamit ang mga pandiwa, i.e. inilalarawan nila ang mga aksyon na isinagawa (lumikha ng isang produkto, magtapos ng isang kasunduan, gumawa ng isang kargamento).

Ang IDEF0 ay isang napaka-simple at kasabay na visual na wika para sa paglalarawan ng mga proseso ng negosyo. Gamit ang pamantayang ito, posibleng maglipat ng impormasyon sa pagitan ng mga developer, consultant at user. Ang pamantayan ay binuo nang maingat, ito ay maginhawa para sa disenyo, at unibersal. Maraming mga tool para sa pagtatrabaho dito, halimbawa, VISIO, BPWIN, ERWIN, Bussines studio, atbp.

Bilang karagdagan, ang paggamit ng IDEF0 upang lumikha ng mga modelo ng negosyo ay hindi lamang maginhawa, ito rin ay tama. Idinisenyo ang tool na ito para sa analytics ng negosyo at sumailalim sa malawak at masusing pag-debug at pag-polish. Samakatuwid, gamit ang IDEF0, ang paglikha ng isang functional na modelo na walang mga error ay mas madali kaysa sa hindi gumagamit ng pamantayang ito.

Tulad ng alam mo, pinakamahusay na martilyo ang mga kuko gamit ang martilyo. Siyempre, maaari kang gumamit ng iba pang mga tool para dito, ngunit ang martilyo ay ang pinaka-functional at ang pinakamadaling martilyo ng isang pako nang tumpak at tumpak. Kaya ito ay sa paggamit ng IDEF0 - ang tool na ito ay nilikha para sa functional modeling, at sa tulong nito maaari mong makuha ang nais na resulta nang mas mabilis at mas tumpak.

Halimbawa ng paglikha ng isang functional na modelong IDEF0

Upang maunawaan kung paano gumana sa functional modeling, magbibigay ako ng isang halimbawa ng proseso ng pagsulat ng isang artikulo.

Ang pangunahing bloke ay "Sumulat ng isang artikulo."

Mga papasok na arrow - "Karanasan", "Impormasyon mula sa mga mapagkukunan ng third-party". Ito ang mga panimulang tala na kailangan mo upang makapagsimula.

Ang mga patnubay para sa pagsulat ng isang artikulo ay ang "Plano ng Publikasyon", "Mga Kinakailangan ng Tagapaglathala", "Mga Panuntunan ng Wikang Ruso".

At ang papel ng "Mekanismo" ay ginampanan ng may-akda, copywriter, proofreader at software. Sa kasong ito, lumilikha ang may-akda ng audio na materyal kung saan kinokolekta niya ang lahat ng mga kaisipan at ideya na dapat ipakita sa artikulo. Ang isang copywriter ay isang tao na lumilikha, batay sa materyal na ito, na ginagabayan ng mga kinakailangan ng publisher, ang plano ng publikasyon at ang mga patakaran ng wikang Ruso, ang natapos na teksto ng isang artikulo. Sinusuri ng proofreader ang materyal para sa mga pagkakamali. At ang software ay ang mga tool na ginagamit ng lahat ng kalahok sa proseso sa kanilang trabaho.

Kaya, itinakda ko ang mga pangunahing parameter ng proseso, ang input nito, output, pati na rin ang lahat ng kailangan para sa matagumpay na pagpapatupad ng proseso. Ngunit ito lamang ang pangunahing balangkas ng proseso. Inilalarawan nito ang pangkalahatang pamamaraan ng kumpanya sa kabuuan.

Sa katunayan, ang proseso ng paglikha ng isang artikulo, tulad ng anumang proseso ng negosyo, ay maaari at dapat na detalyado. Upang gawin ito, i-decompose ko ang pangkalahatang bloke na "magsulat ng isang artikulo" sa mga kaugnay na elemento.

Sa aming kaso, ang gawain ay nahahati sa 4 pangunahing yugto:

Maghanda ng audio.
Maghanda ng teksto
Maghanda ng teksto para sa publikasyon.
Magsumite ng isang artikulo sa isang publikasyon.

Ang diagram ay malinaw na nagpapakita sa kung anong yugto kung aling mga elemento ng kontrol at kung aling mga mekanismo ang kasangkot.

Kaya, kapag lumilikha ng audio, ginagamit ng may-akda ang kanyang kaalaman at karanasan, habang ginagabayan ng plano ng publikasyon at mga kinakailangan ng publisher. Ang copywriter ay tumatanggap ng isang audio recording bilang input, kung saan, ginagabayan ng mga patakaran ng wikang Ruso, lumilikha siya ng isang teksto. Ang proofreader ay tumatanggap ng teksto at sinusuri ito, na ginagabayan din ng mga patakaran ng wikang Ruso. Upang mag-publish ng isang artikulo sa isang publikasyon, kinakailangan ang espesyal na software.

Kapag lumilikha ng isang functional na modelo, ang mga pangunahing parameter ay layunin at punto ng view. Batay sa kanila, ang pagmomodelo ng parehong mga proseso ay maaaring magmukhang bahagyang naiiba. Halimbawa, sa aking kaso, ang layunin ay "pag-usapan ang proseso ng pagsulat ng isang artikulo." At ang pananaw ng copywriter ay "pagsusulat at pag-publish ng isang artikulo mula sa punto ng view ng tagapamahala ng proseso."

Kaya, kung ang parehong proseso ay inilarawan mula sa punto ng view ng isang copywriter, kung gayon ang input ay magiging karanasan at isang audio file mula sa may-akda. Bukod dito, sa kasong ito, ang Karanasan ay mangangahulugan ng karanasan ng isang copywriter, ngunit hindi isang manager o may-akda. Samakatuwid, ang unang bagay na kailangang matukoy kapag lumilikha ng isang modelo ng proseso ng negosyo ay ang pumili ng isang punto ng view at malinaw na bumalangkas ng isang layunin.

Ang ganitong pagmomodelo ay hindi lamang visual, ngunit napaka-maginhawa para sa paggawa ng epektibo mga desisyon sa pamamahala. Halimbawa, sa proseso ng negosyo na inilarawan sa itaas, mayroong dalawang magkahiwalay na espesyalista - isang copywriter at isang proofreader. Kung itinakda ko ang gawain ng pag-optimize ng financing ng isang proyekto, pagkatapos salamat sa diagram ay makikita ko kaagad kung saan ito maaaring gawin at kung paano ito magagawa. Kaya, ang isang copywriter at isang proofreader ay gumagamit ng humigit-kumulang sa parehong mga panuntunan, ngunit ang copywriter ay tumatanggap ng audio at gumagawa ng resulta sa anyo ng teksto, habang ang proofreader ay parehong tumatanggap at naghahatid ng teksto. Samakatuwid, kung kinakailangan, maaari kong, sabihin, mag-alok ng mga tungkulin ng isang proofreader sa isang copywriter para sa kalahati ng gastos. Sa ganitong paraan makakatipid ako ng pera at oras sa pakikipag-ugnayan sa pagitan ng iba't ibang mga espesyalista. Siyempre, naiintindihan ko ang lahat ng mga merito ng mga proofreader at kung bakit mas mahusay na makipagtulungan sa mga indibidwal na espesyalista. Ngunit ipinapaalala ko sa iyo na mayroon akong gawain: pag-optimize ng gastos.

Kung wala ang gayong visual na tool, magiging mas mahirap matukoy kung aling mga bloke ang maaaring alisin at sa gayon ay ma-optimize ang trabaho.

Paano Gumawa ng IDEF0 Notations

Mayroong maraming iba't ibang mga produkto ng software na maaaring magamit upang lumikha ng mga notasyon. Ang ilan ay partikular na nilikha para sa functional modeling, ang iba ay idinisenyo para sa anumang gawaing may mga graphic na elemento. Nasa sa iyo kung saan at paano mo binuo ang mga modelong ito.

Personal kong iniisip na sa unang yugto ay walang mas mahusay kaysa sa simpleng papel, isang lapis at isang pambura upang gumawa ng mga pagsasaayos kung sakaling magkamali.

Upang lumikha ng isang notasyon ng mga umiiral na proseso ng negosyo, i.e. Upang ilarawan kung paano gumagana ang kumpanya ngayon, kinakailangan na pag-aralan ang mga prinsipyo ng pagpapatakbo. Ang isang third-party na espesyalista (consultant, developer) ay nagsasagawa ng panayam para sa layuning ito. Sa unang yugto, sinasagot ng pinuno ng kumpanya ang mga tanong, pagkatapos, sa proseso ng pagdedetalye ng notasyon, ang mga panayam ay isinasagawa sa mga empleyado na responsable para sa iba't ibang yugto ng trabaho.

Mahalagang maunawaan na bilang resulta, 2 notation ang kakailanganin. Ang una ay magpapakita ng mga proseso ng negosyo sa isang "as is" na form. Ginagawa mo ito batay sa mga panayam at ikoordina ang bawat detalye sa mga empleyado ng kumpanya at sa manager. Napakahalaga na ang iyong pananaw sa mga kasalukuyang proseso ay tumutugma sa katotohanan; ito ang dahilan kung bakit kinakailangan ang kumpirmasyon sa lahat ng antas.

Ang pangalawang notasyon ay "gaya ng nararapat." Nilikha ito batay sa una at sa mga pagbabagong iminumungkahi mong gawin sa istruktura ng trabaho upang i-optimize at i-automate ang trabaho ng kumpanya sa loob ng balangkas ng pagkumpleto ng nakatalagang gawain.

Mga pamantayang kinakailangan ng IDEF0

Sa prinsipyo, inilarawan ko ang mga pangunahing kinakailangan ng pamantayan ng IDEF0 sa itaas at ipinakita sa kanila ang isang halimbawa.

Ang pangunahing elemento ay palaging nasa itaas na kaliwang sulok.
Ang lahat ng mga elemento ay dapat magkaroon ng mga papasok at papalabas na mga arrow, dahil para sa pagpapatupad kinakailangan na makatanggap ng isang bagay sa input (isang order, isang gawain), at pagkatapos ng pagproseso sa output kinakailangan na ilipat tapos na produkto. Ang mga paparating na arrow ay palaging nasa kaliwa, ang mga papalabas na arrow ay palaging nasa kanan.
Sa itaas ay ang mga elemento ng kontrol, sa ibaba ay ang mga mekanismo na kinakailangan upang makumpleto ang proseso.
Kung mayroong ilang mga bloke sa isang sheet (screen), ang bawat kasunod ay matatagpuan sa kanan at sa ibaba ng nauna.
Kinakailangan na magsikap na lumikha ng mga diagram sa paraang ang intersection ng mga arrow ay nabawasan sa kinakailangang minimum.

Mga karaniwang pagkakamali

Isinasagawa ang functional modeling gamit ang iba't ibang tool, kabilang ang mga hindi nilayon para sa pagmomodelo. Sa huling kaso, walang error checking at walang standard restrictions. Ang pagnanais na madagdagan ang kakayahang makita at kakulangan ng karanasan ay madalas na nagtatapos sa mga pagkakamali.

Gamit ang iba't ibang kulay

Ang lahat ng mga elemento sa diagram ay pantay na mahalaga. Sa functional modeling, walang higit pa o hindi gaanong mahahalagang elemento. Ang pagkawala ng anuman ay hahantong sa pagkagambala sa proseso at mga depekto sa pagmamanupaktura.

Kadalasan kapag nagmomodelo sa papel o sa iba't ibang mga programa, sinusubukan ng mga user na pataasin ang visibility sa pamamagitan ng paggamit ng iba't ibang kulay. Ito ay isa sa mga pinakakaraniwang pagkakamali. Sa katunayan, ang paggamit ng maraming kulay na mga arrow at mga bloke ay nagdaragdag lamang ng karagdagang pagkalito at din distorts ang perception ng diagram.

Ang iyong modelo ay dapat na nababasa sa itim at puti, nang walang anumang karagdagang mga scheme ng kulay. Ang diskarteng ito ay sabay-sabay na nakakatulong upang maiwasan ang mga hindi pagkakaunawaan at disiplinahin ang tagalikha ng modelo, na nagreresulta sa pagtaas ng pagiging madaling mabasa at literacy ng modelo.

Masyadong maraming block

Kapag gumuhit ng isang modelo, madalas nilang sinusubukan na ipakita sa isang sheet ang lahat ng mga nuances ng trabaho ng kumpanya kasama ang lahat ng mga detalye. Ang resulta ay napaka malaking bilang ng mga bloke na may malaking bilang ng mga control arrow. Sa kasong ito, nawala ang pagiging madaling mabasa.

Ang pinakamagandang opsyon ay sapat na detalye para maunawaan ang isyu, at wala nang iba pa. Ang mga detalyadong detalye ng gawain ng bawat departamento o kahit na empleyado ay maaaring ibunyag kapag pumipili ng isang detalyadong pagtingin sa isang partikular na proseso. At ang gayong istraktura ay nilikha lamang kung ito ay talagang kinakailangan para sa trabaho o paggawa ng desisyon.

Paglabag sa istraktura kapag gumagawa ng mga pagsasaayos

Mag-ingat upang matiyak na walang kalituhan o proseso nang walang papasok, papalabas, o iba pang mahahalagang elemento. Halimbawa, kung sa halimbawa sa itaas, nakita kong kinakailangan na ilipat ang punto ng view sa copywriter, aalisin ko ang may-akda mula sa scheme. At pagkatapos ay ang mga elemento ng kontrol na "karanasan ng may-akda at mga mapagkukunan ng third-party", pati na rin ang plano sa paglalathala, ay nagiging hindi kailangan. Pagkatapos ng lahat, ginagamit sila ng may-akda. Gumagana ang isang copywriter sa isang audio file. At kung mananatili sila pangkalahatang pamamaraan, at kapag nagdedetalye ito ay hahantong sa hindi malinaw na direksyon at magdudulot ng kalituhan.

Gayundin, kung magpasya akong magdagdag ng isang bloke, mahalagang tiyaking mayroon din itong lahat ng kinakailangang katangian. Napakahalaga ng pangangalaga dito, dahil kapag nagmomodelo ng mga kumplikadong proseso ng negosyo, ang mga pagbabago sa isang bahagi ng modelo ay maaaring humantong sa mga pagbabago sa isa pa. Tiyak na kailangan nilang isama.

Mga panuntunan para sa pagbibigay ng pangalan sa mga elemento ng kontrol at mga bloke

Mahalagang tandaan ang isang simpleng panuntunan: ang mga control arrow ay tinatawag na mga pangngalan, ang mga bloke ay tinatawag na mga pandiwa. Ito ay tinatanggap sa pamantayan ng IDEF0, at ang pamamaraang ito ay nakakatulong upang maiwasan ang pagkalito at mga pagkakamali.

Kadalasan, nagkakamali kapag pinangalanan ang mga bloke. Halimbawa, sa halip na "Gumawa ng isang artikulo," isinusulat nila ang "Paggawa ng isang artikulo." Hinaharang diskarteng ito- ito ay mga aksyon, at samakatuwid dapat silang palaging mga pandiwa.

Mga pakinabang ng paggamit ng IDEF0

Ang pinakaunang benepisyo ay halata – visibility. Ikaw mismo ang magsisimulang maunawaan kung paano gumagana ito o ang sistemang iyon, at maaari mo ring malinaw na ipaliwanag kung nasaan ang "mga manipis na batik" sa sistemang ito at kung paano makakatulong ang iyong mga solusyon na maalis ang mga ito.
Mutual na pag-unawa at kawalan ng mga pagkakaiba. Kapag tinatalakay ang gawain ng isang kumpanya gamit ang isang functional na modelo, mayroon kang visual at intuitive na mga bloke ng mga gawain na may mga elemento ng kontrol. Bilang karagdagan, ang functional modeling ay kinabibilangan ng paglikha, kung kinakailangan, ng isang glossary na nagpapakita mga simbolo at mga tuntunin. Bilang resulta, ikaw at ang kliyente, manager, at iba pang mga empleyado ay nagsasalita ng parehong wika kapag tinatalakay ang isang problema.
Ang pagiging simple at mataas na bilis paglikha ng isang modelo. Siyempre, ang pag-aaral sa modelo ay hindi kasingdali ng tila. Pagkatapos ng lahat, ang isang diagram ay, sa esensya, isang sobrang siksik na presentasyon ng impormasyon, na napakahusay para sa pag-unawa, ngunit ang pagpapatupad ng gayong pagtatanghal ay nangangailangan ng isang espesyal na diskarte. Ang utak ng analyst ay kumikilos sa kasong ito bilang isang napakalakas na pindutin sa isang banda, at isang filter sa kabilang banda. Ngunit sa karanasan, ang prosesong ito ay nagiging napakabilis. Bilang resulta, makakakuha ka ng isang tool na makakatulong sa iyong malaman para sa iyong sarili kung ano ang nangyayari sa isang partikular na system, at gamit ang software na nilikha sa maikling oras visual aid upang ilarawan mahahalagang puntos mga kasamahan o mga customer.
Disiplina at walang pagkakamali. Ang pamantayan ng IDEF0 ay nagbibigay ng mahigpit na mga balangkas at panuntunan. Ang pamamaraang ito ay lumilikha ng disiplina, at ang ugali ng pagkilos sa loob ng pamantayan ay nakakatulong upang maiwasan ang mga pagkakamali dahil sa kawalan ng pansin. Ang anumang paglabag sa pamantayan ay agad na napapansin.

Ano ang hirap ng paggamit ng IDEF0

Mahalagang maunawaan iyon lamang sa karamihan mga simpleng kaso dalawang business analyst ang gagawa ng eksaktong parehong functional na mga modelo upang ilarawan ang trabaho ng kumpanya. Ang anumang modelo ay salamin ng karanasan ng analyst, lalim ng pag-unawa sa negosyong nais niyang ilarawan, at gayundin, sa ilang paraan, ang kanyang personal na pananaw sa negosyong ito. Yung. ang isang tao ay bumuo ng isang modelo ng negosyo mula sa punto ng view ng isang manager, na parang siya ang manager.

Kasabay nito, naniniwala ako na ang isang business analyst ay hindi eksaktong isang propesyon; bawat business manager o developer ng ilang system na nagsusuri sa negosyo at nagsusumikap na bumuo ng pinaka-epektibong system ay nakikibahagi sa business analytics. Para sa mga taong ito at para sa mga layuning ito na idinisenyo ang tool na IDEF0.

Samakatuwid, kapag gumuhit ng isang functional na "as is" na modelo ng negosyo, napakahalaga na patuloy na kumunsulta sa pinuno ng kumpanya upang hindi makagawa ng mga pagkakamali na awtomatikong magsasama ng mga pagkakamali sa mga yugto ng agnas. Gayundin, sa mga susunod na yugto, maaaring kailanganin ang mga karagdagang pag-apruba sa mga tagapamahala. mga istrukturang dibisyon at mga empleyado. Kung ang iyong "as is" na functional na modelo ay tunay na sumasalamin sa totoong kalagayan ng mga bagay maaari kang gumawa ng anumang mga pagbabago at mungkahi. At upang makamit ang mataas na kalidad na mga resulta sa naturang gawain, una sa lahat, kinakailangan ang praktikal na karanasan at kaalaman sa mga katangian ng isang partikular na uri ng negosyo.