IDEF0 módszertan. Jelölés, modellezési elvek. A szervezetek felmérésének fő módszerei. Szabványos IDEF0 Idef0 modellek alakulnak ki a szerkezeti bomlás folyamatában

Ebben a részben a folyamatok meghatározásának, osztályozásának és azonosításának módszertana (____. fejezet) az IDEF0 funkcionális modellezési módszertan alapján valósul meg.

1. Üzleti folyamatok meghatározása IDEF0 modell formájában

1.1. Üzleti folyamat meghatározása.

A leírás első szakaszában meg kell határozni az üzleti folyamatokat a szervezetben. Az üzleti folyamat meghatározásának kulcseleme a célkimutatás, amely tükrözi az üzleti folyamat modelljének (leírásának) létrehozásának okát és meghatározza annak célját.

Megjegyzések:

1. MEGJEGYZÉS A modell célja egy adott perspektíva megragadása, amelyből egy szervezet tevékenységeit szemléljük és leírjuk. Különböző célokra a látószögek eltérőek lehetnek, és a folyamatmodellek eltérőek lehetnek.

Például egy ruhagyárban zajló folyamatok leírásánál többféle cél is megfogalmazható: a gyár szervezeti felépítésének optimalizálása, minőségirányítási rendszer kialakítása, tevékenységbővítés stb.

2 A jelen dokumentumban szereplő modellek általános célja egy olyan minőségirányítási rendszer létrehozása, amely megfelel az STB ISO 9000-2001, STB ISO 9001-2001 és STB ISO 9004-2001 követelményeknek.

Az üzleti folyamatok azonosításához a következőket kell meghatározni:

a szervezet termékeinek és/vagy szolgáltatásainak fogyasztói;
a szervezetben előállított és a fogyasztóknak szállított termékek és/vagy szolgáltatások;
nyersanyagfajták és beszállítóik.

Megjegyzés - Mert különféle fajták termékek vagy a fogyasztók különböző kategóriái különböző üzleti folyamatoknak tekinthetők.

Például egy ruhagyár női kabátokat gyárt (varr), fogyasztókkal kötött szerződésekkel. A termékek fogyasztói a női ruházati üzletek, valamint a kereskedelmi és közvetítő cégek. A gyár textilipari vállalkozásoktól, valamint kereskedelmi és közvetítő cégektől vásárol alapanyagokat.

A gyár zárt részvénytársaság. A modell felépítésének célja egy minőségirányítási rendszer létrehozása. Ezen információk alapján a ruhagyár tevékenységében egy üzleti folyamat különböztethető meg - „Női kabátok gyártása”. Ennek a folyamatnak a bemenetei: a) külső információk, beleértve a fogyasztók (üzletek és cégek) igényeit; b) nyersanyagok és anyagok; c) források. A folyamat kimenetei: a) fogyasztóknak szánt késztermék-tételek; b) külső fogyasztók tájékoztatása. A folyamatirányítás a gyári gyártási folyamatokat szabályozó normatív dokumentumok alapján történik. Tekintettel arra, hogy minőségirányítási szempontból vagyunk érdekeltek a folyamatban, akkor as külső irányítás figyelembe vesszük az erre a területre vonatkozó szabályozási dokumentumokat, beleértve az STB ISO 9000 követelményeit is. A ruhagyár üzleti folyamatának térképe a 2. ábrán látható. 3.

Rizs. 3 Üzleti folyamat egy ruhagyárban

1.2. Az üzleti folyamat szerkezetének leírása

Az üzleti folyamat meghatározásának második lépése a belső szerkezetének leírása. Ehhez meg kell határoznia:

milyen folyamatokból áll a modellezett üzleti folyamat;
hogyan hatnak ezek a folyamatok egymással.

Az IDEF0 modellezés dekompozíciós mechanizmust használ a folyamat belső szerkezetének leírására.

Az IDEF0 módszertan követelményeinek megfelelően az üzleti folyamat felbontásához szükséges egy gyermekdiagram létrehozása. Ez a diagram bemutatja azokat a folyamatokat, amelyek a minőségirányítási rendszeren (QMS) belüli üzleti folyamatot alkotják.

Tekintsük a „Női kabátok gyártása” üzleti folyamat bomlását (3. ábra).

Figyelembe véve a modellezés céljait - az üzleti folyamatnak az STB ISO 9001 - 2001 követelményeinek való megfelelését, az üzleti folyamat felosztása 4 folyamatblokkot tartalmaz, amelyeket az 1. ábra mutat be. 4.

Az STB ISO 9000 követelményeivel összhangban a „Női kabátok gyártása” üzleti folyamat a következő folyamatokat tartalmazza:

– felismerni a felső vezetés minőségirányítási felelősségét;

– erőforrásokkal gazdálkodni;

- folyamatokat végrehajtani életciklus;

– a QMS mérése, elemzése és fejlesztése.

Megjegyzés – A 4. ábra nem mutatja be a „Női kabát készítése” folyamat lebomlását reprezentáló funkcionális blokkok közötti kölcsönhatásokat 1.3. A folyamatok közötti kölcsönhatások leírása

Az üzleti folyamat meghatározásának harmadik lépése a folyamatok közötti kölcsönhatások leírása. Az IDEF0-ban a folyamatok közötti interakciót interfészívek segítségével írják le, és az anyagok és/vagy információk átvitelét jelöli az egyik folyamat kimeneteitől egy másik folyamat bemeneteihez (vezérlései, mechanizmusai).

Az IDEF0 módszertanban ugyanazon a diagramon belül 5 (öt) típusú interakció érvényes a blokkok között (1. táblázat):

ellenőrzés;
kimenet bemenet;
Visszacsatolás menedzsment;
bemeneti visszacsatolás;
A kimenet egy mechanizmus.

Asztal 1

	Irányítási kapcsolat: egy folyamat kimenete egy másik folyamat végrehajtására hat, azaz. az 1. blokk kimeneti íve a 2. blokk vezérlőíve. Az STB ISO 9001 szabványban ez a kölcsönhatás határozza meg a "menedzsment felelőssége" menedzsment funkciót más folyamatokkal kapcsolatban
	Bemeneti kapcsolat: az egyik folyamat kimenete a másik bemenete, azaz. az 1. blokk kimeneti íve a 2. blokk bemenete. Ez a kölcsönhatás a szervezet bármely folyamatára jellemző, például életciklus-folyamatokra
	Vezérlési visszacsatolás: az egyik folyamat kimenetei befolyásolják más folyamatok végrehajtását, amelyek végrehajtása viszont az eredeti folyamat végrehajtására. Az 1. blokk kimeneti íve a 2. blokk vezérlőíve, a 2. blokk kimeneti íve pedig az 1. blokk vezérlőíve. Az STB ISO 9001 szabványban az ilyen interakció meghatározhatja: - vezetői funkció „a vezetés felelőssége”; – irányítási funkció „életciklus-folyamatok kezelése”; – menedzsment funkció „mérés, elemzés és javítás”
	Bemeneti visszacsatolás: az egyik folyamat kimenete egy másik folyamat bemenete, amelynek kimenete a bemenete, azaz. a 2. blokk kimeneti íve az 1. blokk bemenete, amelynek kimenete a bemenete. Az STB ISO 9001-2001 szabványban az ilyen interakció meghatározhatja az "életciklus-folyamatok menedzselése" menedzsment funkciót.
	Az „output – mechanizmus” kapcsolat: az egyik folyamat kimenete egy másik folyamat mechanizmusa, azaz. az 1. blokk kimeneti íve a 2. blokk mechanizmusíve. Ez a típusú kapcsolat leggyakrabban erőforrás-kihelyezési folyamatokhoz kapcsolódik. Az STB ISO 9001 szabványban az ilyen interakció meghatározhatja az "erőforrás-kezelés" menedzsment funkciót.

A gyakorlat azt mutatja, hogy a felsorolt öt interakciótípus elegendő bármilyen bonyolultságú folyamatok közötti kölcsönhatások meghatározásához.

A folyamat funkcionális modelljének keretein belüli interakciók leírása akkor lesz teljes, ha minden egyes funkcionális blokkra meghatározzuk annak interfész íveit.

Megjegyzés - Az IDEF0 módszertan azt szabályozza, hogy a modell minden blokkjának tartalmaznia kell legalább egy bemenetet, kimenetet, vezérlést és mechanizmusívet. Van egy rövid lista a kivételekről e szabály alól.

Tekintsük a „Női kabátok gyártása” üzleti folyamatot alkotó folyamatok közötti kölcsönhatásokat (5. ábra).

A Realize Top Management Responsibility for Quality Management folyamat az összes többi folyamat irányadó folyamata. Ennek megfelelően ennek a folyamatnak a kimenete - "Politika, célkitűzések, minőségügyi kézikönyv, minőségügyi programok" az összes többi folyamat vezérlő bemenete, amely a diagramon látható (5. ábra).

Az „Erőforrások kezelése” folyamat „output – mechanizmus” kapcsolatban áll az „életciklus-folyamatok megvalósítása” és a „QMS mérése, elemzése és javítása” folyamatokkal.

A diagram egy visszacsatolási hurkot mutat: a „Mérés, elemzés és javítás a minőségirányítási rendszer” folyamat kimenete a „Felső vezetés felelősségének megvalósítása a minőségirányításban” folyamat bemenetével.

Megjegyzés - Az IDEF0 funkcionális modell teljességi szabálya pontosan megfelel az STB ISO 9001 követelményeinek abból a szempontból, hogy minden folyamatot erőforrásokkal kell ellátni (IDEF0 modellben mechanizmusívek), vezérelni (vezérlőívek), kimeneti termékeket (output) kell előállítani. ívek), feldolgozza a bemeneteire érkező anyagokat és/vagy információkat (bemeneti ívek).

5. ábra - A folyamatok közötti kölcsönhatások

A folyamat részletezettségi szintjének számát a modellezés céljai és a modellezett szervezet tevékenységének sajátosságai határozzák meg. E módszertan keretein belül a folyamatmodellezés fő célja a folyamat minőségirányítási rendszer követelményeinek való megfelelőségének elemzése.

Az A0 diagramon (5. ábra) a „Női kabátok gyártása” üzleti folyamatot 4 folyamat formájában mutatjuk be. Az A0 diagram a lebontás első szintje (részlete) ehhez a folyamathoz. A bemutatott 4 folyamat mindegyike felbontható. ábrán A 6. ábra az "Implement Life Cycle Processes" folyamat lebontását mutatja.

Az A3 diagramon (6. ábra) az „Életciklus-folyamatok megvalósítása” folyamat hat folyamatként jelenik meg, beleértve a „Vásárlást”, amely szintén bontható (7. ábra).

Rizs. 6.- Az "Életciklus-folyamatok megvalósítása" folyamat bontása

A folyamatszószedet tartalmazza a folyamatok listáját, a folyamatokon belül kezelt objektumokat és azok definícióit.

A szószedet a kifejezések ábécé sorrendben rendezett listája. A listán szereplő minden kifejezés megfelel egy meghatározásnak vagy a megfelelő meghatározásra való hivatkozásnak, amelyet a szervezet vagy a felsőbb hatóságok szabályozó dokumentumaiban, rendeletekben stb.

Például az A34 diagramnál (7. ábra) a szószedet egy része így fog kinézni.

Egy kép többet ér ezer szónál

népi bölcsesség

Munkám során gyakran nem csak egy bizonyos probléma tanulmányozására és megoldására van szükség, hanem annak helyének meghatározására is általános modell céges munka. Nem elég megérteni, hogy egy bizonyos egység nem működik megfelelően, fontos megérteni, hogyan működik együtt másokkal. Ellenkező esetben lehetetlen mindent felfedni meglévő problémákatés válassza ki a legjobb módszert a probléma megoldására. Ehhez tanulmányoznia kell a vállalat munkáját és fel kell dolgoznia annak funkcionális modelljét.

Természetesen elméletileg a menedzsernek rendelkeznie kell egy funkcionális modellel a cég munkájáról, és ez nem számít kérdéses a raktár munkájának megszervezéséről vagy az informatikai rendszerről az elvezetéstől a megkeresésig. De a valóságban ez szinte soha nem derül ki, ezért az ügyfél által kitűzött feladatra való tanulmányozás és megoldás keresése során elkészítem a vállalat vagy egy bizonyos folyamat (funkció) funkcionális modelljét is. saját.

Néhány szó a grafika előnyeiről

Mint tudják, az IDEF0 funkcionális modellek mindig grafikus sémák. Megvannak a saját jellemzőik és az összeállítás szabályai. Erről egy kicsit később beszélünk. És most szeretnék néhány példát hozni a grafika hatékonyságára. Miért fókuszálok erre? Valószínűleg a vállalati munka funkcionális modelljének szükségességéről szóló kijelentésem után sokan úgy gondolták, hogy erre nincs szükség, és szavakkal is el lehetett magyarázni, hogyan működik ez vagy az a funkció a cégben. Erről szeretnék beszélni.

És kezdésként tegyünk egy rövid kitérőt a történelembe. Térjünk vissza a távoli 1877-be, az orosz-török háború idején. A Sytin nyomtató ekkor használt először grafikát a katonai műveletek leírására. Most már mindez ismerős számunkra, bármilyen csata leírásakor nyilakkal ellátott kártyák jelennek meg a szemünk előtt, amelyek jól mutatják a csata menetét. És akkoriban a katonai műveleteket szavakkal írták le. Minden harchoz - sok-sok szó. És nagyon nehéz volt megérteni a végén, hogy mi történik.

Ezért volt Sytin ötlete valóban forradalmi – elkezdte nyomtatni a térképek litográfiai másolatait az erődítmények és a katonai egységek helyszíneinek megjelölésével. Ezeket a kártyákat „Újságolvasóknak. Haszon". Az ötlet annyira aktuálisnak bizonyult, hogy a „Súgó” legelső példányszáma azonnal elfogyott. És akkor az ilyen alkalmazásokra nagy volt a kereslet. Az ok nyilvánvaló. A grafika segített megérteni azt, amit szinte lehetetlen kitalálni pusztán szavak segítségével.

A verbális leírások tehetetlenségére a saját gyakorlatomból is tudok hasonló példát felhozni. Egyik ügyfelem megkért, hogy vállaljam el cége ERP rendszerének bevezetését. Arra a kérdésre, hogy van-e valamilyen technikai feladatuk, azt a választ kaptam: „Igen, van. De 400 oldala van." Ugyanakkor az ügyfél nagyon panaszkodott, hogy kollégáim, akikkel korábban megkeresett, vagy teljesen visszautasították a projektet, vagy egyértelműen felfújt árakat neveztek. Miután láttam, hogy a feladatkör valóban 400 oldalas, és kizárólag szöveges leírásból áll, megértettem a fejlesztők viselkedésének okait. Egy ilyen kötetnyi szöveg elolvasása, elmélyülése, minden árnyalat megértése csak a feladat megértéséhez és az ár megnevezéséhez valóban nagyon nehéz.

Felajánlottam ezt az ügyfelet Alternatív lehetőség- írjon le mindent, ami lehetséges grafikusan jelölések formájában. Példákat mutatott neki a modellkedésre. Ennek eredményeként most újragondolják kívánságaikat és a feladatmeghatározás kialakítását.

Sok más példát is tudok arra, amikor az üzleti folyamatok grafikus modellezése mind kollégáimnak, üzleti tanácsadóknak és fejlesztőknek, mind maguknak az üzletembereknek segített.

Miért fontos ez a munkám szempontjából

A munkám mindig a változásokhoz kapcsolódik meglévő rendszer. És ahhoz, hogy változtatásokat hajtson végre, és elérje a kívánt eredményt, tanulmányoznia kell a már meglévőket. És nem mindegy, hogy pontosan mit csinálunk – a CRM rendszert a semmiből állítjuk be vagy telepítjük, hatékony ERP rendszert hozunk létre, különféle rendszereket integrálunk, hogy általánosságban növeljük a munka automatizálását. Mindenesetre először meg kell ismerni a meglévő munkarendszert, és csak ezt követően lehet javasolni néhány változtatást, és át kell gondolni a feladat megoldásának lehetőségeit.

A status quo tanulmányozása után, mint bármely más külső szakértő, alkotok ajánlat, amelyben a lehető legrészletesebben feltárom az aktuális helyzetről alkotott elképzelésemet, valamint a feladat megoldásához szükséges tennivalókat, és természetesen a várható eredményt.

Az ilyen munkafelmérési jelentések terjedelmesek, több oldalt is elfoglalnak, ami egyrészt szükséges, másrészt megnehezíti az észlelést. Eleinte, mint sokan mások, azt hittem, jó a terjedelmes beszámoló, mert az ember fizet a munkáért, és minél részletesebb tájékoztatást kell adni neki.

Gyakori hibák

A funkcionális modellezés különféle eszközökkel történik, beleértve azokat is, amelyek nem modellezésre szolgálnak. Ez utóbbi esetben nem kell ellenőrizni a szabvány hibáit és korlátait. A láthatóság növelésének vágya és a tapasztalat hiánya gyakran hibákhoz vezet.

Különböző színek használata

A diagram minden eleme egyformán fontos. A funkcionális modellezésben nincsenek többé-kevésbé fontos elemek. Bármelyik eltűnése a folyamat megszakadásához és gyártási hibához vezet.

Amikor papíron vagy különböző programokban modelleznek, a felhasználók gyakran különböző színek használatával próbálják növelni a láthatóságot. Ez az egyik leggyakoribb hiba. Valójában a többszínű nyilak és blokkok használata csak további zavart okoz, és torzítja a séma észlelését.

A modellnek fekete-fehérben olvashatónak kell lennie, további színséma nélkül. Ez a megközelítés egyszerre segít elkerülni a félreértéseket és fegyelmezi a modell készítőjét, ennek eredményeként növekszik a modell olvashatósága és műveltsége.

Túl sok blokk

A modell összeállításakor gyakran igyekeznek egy lapon megjeleníteni a cég munkájának minden árnyalatát, minden részlettel. Az eredmény nagyon nagyszámú blokkolja nagy mennyiség vezérlő nyilak. Az olvashatóság elveszett.

A legjobb megoldás a probléma megértéséhez elegendő részletezés, és semmi több. Egy-egy folyamat részletes nézetének kiválasztásakor az egyes részlegek vagy akár egy alkalmazott munkájának részletes részletei derülhetnek ki. Ilyen struktúra pedig csak akkor jön létre, ha valóban szükséges a munkához vagy a döntéshozatalhoz.

A szerkezet megsértése beállításkor

Figyelje meg alaposan, hogy elkerülje a zavart vagy a folyamatokat a bejövő, kimenő és egyéb fontos elemek nélkül. Például, ha a fenti példában úgy látom, hogy a nézőpontot áthelyezem a szövegíróra, akkor eltávolítom a szerzőt a sémából. És akkor a vezérlőelemek "a szerző tapasztalata és harmadik féltől származó források”, valamint a kiadási terv is feleslegessé válik. Hiszen a szerző ezeket használja. A szövegíró a hangfájllal dolgozik. És ha bent maradnak általános séma, akkor részletezéskor érthetetlenül hova vezetnek és zavart vezetnek be.

Hasonlóképpen, ha úgy döntök, hogy hozzáadok egy blokkot, fontos megbizonyosodnom arról, hogy az is rendelkezik az összes szükséges attribútummal. Itt nagyon fontos a körültekintés, mert az összetett üzleti folyamatok modellezésekor a modell egyik részének változása egy másikban is változáshoz vezethet. Be kell őket adni.

A vezérlőelemek és blokkok elnevezésének szabályai

Fontos megjegyezni egy egyszerű szabályt: a vezérlő nyilakat főneveknek, a blokkokat igéknek nevezzük. Ezt az IDEF0 szabvány elfogadja, és ez a megközelítés segít elkerülni a félreértéseket és a hibákat.

Leggyakrabban a blokkok elnevezésekor követnek el hibákat. Például a "Cikk létrehozása" helyett azt írják, hogy "Cikket hozzon létre". Ebben a megközelítésben a blokkok cselekvések, ezért mindig igéknek kell lenniük.

Az IDEF0 használatának előnyei

A legelső előny nyilvánvaló – ez a láthatóság.Ön maga kezdi megérteni, hogyan működik ez vagy az a rendszer, és világosan elmagyarázhatja, hol vannak a „vékony foltok” ebben a rendszerben, és hogyan segítenek a megoldások megszabadulni tőlük.
Kölcsönös megértés és a nézeteltérés hiánya. Amikor a funkcionális modellt használó vállalat munkáját tárgyalja, vizuális és intuitív feladatblokkjai vannak vezérlőkkel. Ezenkívül a funkcionális modellezés szükség esetén egy szószedet létrehozását jelenti, amelyben egyezményekés feltételek. Ennek eredményeként Ön és ügyfele, menedzsere és más alkalmazottak ugyanazt a nyelvet beszélik, amikor egy problémáról beszélnek.
A modellkészítés egyszerűsége és nagy sebessége. Természetesen a modellezés megtanulása nem olyan egyszerű, mint amilyennek látszik. Hiszen egy séma valójában egy szupersűrű információ-megjelenítés, ami nagyon jó a megértéshez, de egy ilyen bemutatás megvalósításához speciális megközelítésre van szükség. Az elemző agya ebben az esetben egyrészt nagyon erős présként, másrészt szűrőként működik. De tapasztalattal ez a folyamat nagyon felgyorsul. Ennek eredményeként kap egy eszközt, amely segít kitalálni, hogy mi történik egy adott rendszerben, és egy rövid idő alatt elkészített szemléltetőeszköz segítségével illusztrálja fontos pontokat kollégák vagy ügyfelek.
Fegyelem és semmi hiba. Az IDEF0 szabvány szigorú kereteket és szabályokat feltételez. Ez a szemlélet fegyelmez, a szabvány keretein belüli cselekvés szokása pedig segít elkerülni a figyelmetlenségből fakadó hibákat. A szabvány bármilyen megsértése azonnal észrevehető.

Milyen nehézségeket okoz az IDEF0 használata?

Fontos megérteni, hogy két üzleti elemző csak a legegyszerűbb esetekben hoz létre pontosan ugyanazokat a funkcionális modelleket a vállalat munkájának leírására. Bármely modell tükrözi az elemző tapasztalatait, az általa leírni kívánt üzletág megértésének mélységét, és valamilyen módon az üzletről alkotott személyes álláspontját is. Azok. az ember olyan üzleti modellt alakít ki a vezető szemszögéből, mintha ő lenne a vezető.

Ugyanakkor úgy gondolom, hogy az üzleti elemző nem egészen szakma, minden üzletvezető vagy valamilyen rendszer fejlesztője üzletelemzéssel foglalkozik, aki elemzi az üzletet és a leghatékonyabb rendszer felépítésére törekszik. Ezeknek az embereknek és ezeknek a céloknak a célja az IDEF0 eszköz.

Ezért nagyon fontos, hogy a funkcionális üzleti modell összeállításakor folyamatosan konzultáljon a vállalat vezetőjével, hogy ne kövessen el olyan hibákat, amelyek automatikusan hibákhoz vezetnek a bomlás szakaszaiban. Ezenkívül a későbbi szakaszokban további jóváhagyásokra lehet szükség a strukturális részlegek vezetőitől és az alkalmazottaktól. Csak akkor hajthat végre néhány változtatást és javaslatot, ha „ahogy van” funkcionális modellje valóban tükrözi a dolgok valós állapotát. És ahhoz, hogy az ilyen munkában minőségi eredményeket érjünk el, mindenekelőtt gyakorlati tapasztalatok valamint egy adott típusú vállalkozás jellemzőinek ismerete.

További cikkek ebben a témában.

Ezután fontolja meg szabványos módszerek rendszerszerkezeti elemzés, amelyet egy sor amerikai szövetségi szabvány ír le " Icam definíció", vminek megfelelően . Részletes információk A sorozat összes szabványa megtalálható a http://www.idef.com címen.

Alapértelmezett IDEF0(FIPS183) célja, hogy olyan funkcionális modellt hozzon létre, amely megjeleníti a rendszer felépítését és funkcióit, valamint az ezeket a funkciókat összekapcsoló információáramlásokat és anyagi objektumokat. Ez a dokumentum egy tervezés (amelyet az Egyesült Államok Védelmi Minisztériuma kezdeményezett) a komplex rendszerelemzés technológiai szabványaként SADT(Structured Analysis and Design Technique), amelyet Douglas Ross vezette amerikai elemzők egy csoportja fejlesztett ki 1973-ban.

Az IDEF0 szabvány által javasolt módszer funkcionális modellezésre, azaz egy objektum funkcióinak teljesítményének modellezésére szolgál, egy leíró grafikus modell elkészítésével, amely megmutatja, hogy a vállalkozás keretein belül mit, hogyan és ki csinál. A funkcionális modell egy termelési rendszer vagy környezet funkcióinak, az ezeket a funkciókat összekapcsoló információknak és objektumoknak a strukturált reprezentációja. A modell dekompozíciós módszerrel épül fel: a nagy kompozit szerkezetektől a kisebb, egyszerűbbekig. Az egyes bontási szintek elemei az információ vagy anyagi erőforrások meghatározott feltételek mellett meghatározott mechanizmusok segítségével történő feldolgozására irányuló műveleteket képviselnek. Minden egyes művelet kisebb műveletekre bomlik le, az információ vagy anyagi erőforrások egy bizonyos részének feldolgozására bizonyos feltételek mellett, az adott mechanizmusok egy részének felhasználásával. A műveletek hasonló módon vannak kialakítva. Utolsó lépés A dekompozíciónak olyan modellt kell eredményeznie, amelynek részletességi szintje megfelel a modellkészítési folyamat legelején meghatározott követelményeknek.

Az IDEF0 módszertana a következő feltételezéseken alapul:

1. Rendszer és modell. A modell egy mesterséges objektum, amely egy rendszer és összetevői tükröződését (képét) reprezentálja. M modellek DE, ha M kapcsolatos kérdésekre válaszol DE. Itt M- modell, DE– modellezett objektum (eredeti). A modell a meglévő rekonstrukciójának (újratervezésének), cseréjének, tervezésének megértésére, elemzésére és döntéshozatalára szolgál. új rendszer. A rendszer egymással összefüggő és kölcsönhatásban lévő részek halmaza, amelyek bizonyos részt hajtanak végre hasznos munka. A rendszer részei (elemei) különféle entitások tetszőleges kombinációi lehetnek, beleértve az embereket, információkat, szoftver, berendezések, termékek, nyersanyagok vagy energia. A modell leírja, hogy mi történik a rendszerben, hogyan kezelik, milyen entitásokat alakít át, milyen eszközöket használ a funkcióinak ellátására, és mit termel.

2. Blokkmodellezés és annak grafikus ábrázolás . Az IDEF módszertan fő elvi elve az, hogy bármely vizsgált rendszert kölcsönható és egymással összefüggő blokkok halmazaként ábrázol, amelyek a vizsgált rendszerben előforduló folyamatokat, műveleteket és műveleteket jelenítik meg. Az IDEF0-ban mindent, ami a rendszerben és annak elemeiben történik, függvényeknek nevezzük. Minden funkcióhoz hozzá van rendelve egy blokk. Az IDEF0-diagramon (gyakrabban SADT-diagramnak hívják), amely a rendszerek elemzésének és tervezésének fő dokumentuma, a blokk egy téglalap. Az interfészeket, amelyeken keresztül a blokk kölcsönhatásba lép más blokkokkal vagy a modellezett rendszeren kívüli környezettel, a blokkba belépő vagy kilépő nyilak jelzik. A bejövő nyilak azt mutatják, hogy mely feltételeknek kell egyszerre teljesülniük ahhoz, hogy a blokk által leírt funkció megvalósuljon.

3. Merevség és formalizmus. Az IDEF0 modellek fejlesztése számos szigorú formai szabály betartását igényli, amelyek biztosítják a módszertan előnyeit a komplex többszintű modellek egyedisége, pontossága és integritása tekintetében. Ezeket a szabályokat az alábbiakban a SADT technológia vonatkozásában ismertetjük. Itt csak a legfontosabbat jegyezzük meg: a modell fejlesztésének és javításának minden szakaszát és szakaszát szigorúan, formálisan dokumentálni kell, hogy működése során ne merülhessen fel hiányosság vagy hibás dokumentáció.

4. Iteratív modellezés. A modellfejlesztés az IDEF0-ban egy lépésről lépésre, iteratív folyamat. Az iteráció minden lépésében a fejlesztő javaslatot tesz a modell egy verziójára, amelyet megvitatásnak, áttekintésnek és utólagos szerkesztésnek vetnek alá, majd a ciklus megismétlődik. Ez a munkaszervezés hozzájárul optimális felhasználás az IDEF0 módszertanát és technikáit birtokló rendszerelemző ismerete, valamint a modellező objektum tárgykörébe tartozó szakemberek - szakértők tudása.

5. A "szervezet" elválasztása a "funkcióktól". A modellek kidolgozásakor kerülni kell a vizsgált rendszer funkcióinak kezdeti „kötését” a modellezett objektum (vállalkozás, cég) meglévő szervezeti struktúrájához. Ez segít elkerülni a szervezet és vezetése által kikényszerített szubjektív nézőpontot. A szervezeti struktúra a modell használatának (alkalmazásának) eredménye legyen. Az eredmény összehasonlítása a meglévő struktúrával lehetővé teszi egyrészt a modell megfelelőségének felmérését, másrészt a struktúra javítását célzó megoldási javaslatok megfogalmazását.

Példák az IDEF0 modellezési módszertan alapján megoldott feladatokra:

Üzleti folyamatok elemzése és újratervezése.

Fejlődés tájékoztatási rendszer minőségi adatkezelés.

A termékminőség biztosítását, minőségi adatfeldolgozó rendszerek létrehozását szolgáló előírások és eljárások kidolgozása. A funkcionális modell lehetővé teszi a hagyományos minőségi kézikönyvek leíró szöveges papírdokumentumokkal való helyettesítését szabványosítottra. elektronikus modellek, amelynek integritása és konzisztenciája automatikusan megmarad. Ha szükséges, mindig kaphat tőlük papíralapú jelentést a szokásos formában.

Információs infrastruktúra, eljárások és szabályozások tervezése az információs interakcióhoz.

A kockázatelemzés feladatai az információbiztonság szempontjából.

Tekintsük a munkával összhangban a diagramok SADT technológiával (IDEF0) való felépítésének elveit.

A SADT grafikai nyelve egyszerű és harmonikus. A módszertan négy fő koncepción alapul.

Ezek közül az első a koncepció funkcionális blokk ". A funkcionális blokk grafikusan téglalapként van ábrázolva (lásd a 3.23. ábrát), és a vizsgált rendszeren belül néhány speciális funkciót képvisel. A szabvány követelményei szerint az egyes funkcionális blokkok nevét verbális hangulatban kell megfogalmazni (pl. szolgáltatásokat előállítani", de nem " szolgáltatás termelés"). A funkcionális blokk mind a négy oldalának megvan a maga bizonyos értéket(szerep), míg: a felső oldalon a " ellenőrzés» (folyt r ol); a bal oldal számít" bejárat» ( bemenet); a jobb oldal számít Kimenet» ( Kimenet); az alsó oldal számít" gépezet» ( gépezet). A vizsgált rendszeren belül minden egyes funkcionális egységnek saját egyedi azonosító számmal kell rendelkeznie.

IDEF0 módszertan

IDEF0 módszertan diagramok hierarchikus rendszerének felépítését írja elő - a rendszertöredékek egységes leírását. Először leírják a rendszer egészét és a külvilággal való interakcióját (kontextus diagram), majd egy funkcionális bontást hajtanak végre - a rendszert alrendszerekre osztják, és minden alrendszert külön írnak le (dekompozíciós diagramok). . Ezután az egyes alrendszereket kisebbekre bontjuk, és így tovább, amíg el nem érjük a kívánt részletezési fokot.

Minden egyes IDEF0-diagramoka blokkokat és íveket tartalmaz. A blokkok a szimulált rendszer funkcióit reprezentálják. Az ívek összekapcsolják a blokkokat, és megjelenítik a köztük lévő interakciókat és kapcsolatokat.

Az ábrákon a funkcionális blokkokat (műveket) dobozok ábrázolják, amelyek elnevezett folyamatokat, függvényeket vagy feladatokat jelentenek, amelyek egy bizonyos idő alatt fordulnak elő, és felismerhető eredménnyel járnak. A mű nevét a cselekvést jelző verbális főnévvel kell kifejezni.

IDEF0 megköveteli, hogy egy diagramnak legalább három és legfeljebb hat doboza legyen. Ezek a megszorítások a diagramok és modellek összetettségét olyan szinten tartják, hogy olvasható, érthető és használható legyen.

A blokk minden oldalának meghatározott, jól meghatározott célja van. Bal oldal blokk a bemenetekre, a felső a vezérlésre, a jobb oldali a kimenetekre, az alsó a mechanizmusokra. Az ilyen megjelölés bizonyos rendszerelveket tükröz: a bemeneteket kimenetekké alakítják; a vezérlés korlátozza vagy előírja a transzformációk végrehajtásának feltételeit; a mechanizmusok megmutatják, hogy egy funkció mit és hogyan teljesít.

Az IDEF0-ban lévő blokkok fontossági sorrendben vannak elhelyezve, ahogyan azt a diagram készítője megértette. Ezt a relatív rendet dominanciának nevezzük. A dominancia alatt azt a hatást értjük, amelyet az egyik blokk gyakorol a diagram többi blokkjára. Például a diagram legdominánsabb blokkja lehet a szükséges függvénysorozatok közül az első, vagy egy tervezési vagy vezérlési funkció, amely az összes többit befolyásolja.

A legdominánsabb doboz általában a diagram bal felső sarkába kerül, a legkevésbé domináns doboz pedig a jobb sarokba.

A blokkok elrendezése az oldalon tükrözi a szerző dominancia-definícióját. Így a diagram topológiája megmutatja, hogy mely jellemzők vannak nagyobb hatással a többire. Ennek hangsúlyozására az elemző átszámozhatja a blokkokat a dominancia sorrendjének megfelelően. A dominancia sorrendjét az egyes mezők jobb alsó sarkában elhelyezett szám jelzi: az 1 a legmagasabb dominanciát jelölné, a 2 a következőt stb.

A művek interakcióját a külvilággal és egymás között nyilak formájában írják le, amelyeket egyetlen vonallal ábrázolnak, a végén nyilakkal. A nyilak bizonyos információkat jelentenek, és főneveknek nevezik őket.

Az IDEF0 ötféle nyíltípust különböztet meg.

Bejárat- a munka által eredmény (kimenet) eléréséhez használt és átalakított objektumok. Megengedett, hogy a munkán ne legyen belépő nyíl. A beviteli nyíl a munka bal oldalára kerül.

Ellenőrzés-.a mű cselekvéseit irányító információk. A vezérlő nyilak általában olyan információkat tartalmaznak, amelyek jelzik a feladat elvégzését. Minden jobnak rendelkeznie kell legalább egy vezérlő nyíllal, amely a job felső felületén jelenik meg.

Kimenet- objektumok, amelyekké a bemeneteket átalakítják. Minden jobnak rendelkeznie kell legalább egy kilépési nyíllal, amely a job jobb oldaláról jön.

Gépezet- Erőforrások, amelyek elvégzik a munkát. A mechanizmus nyíl a munka alsó felületére kerül. Az elemző belátása szerint előfordulhat, hogy a mechanizmus nyilai nem jelennek meg a modellen.

Hívás- egy speciális nyíl, amely egy másik munkamodellre mutat. A hívó nyíl a munka aljáról jön, és azt jelzi, hogy bizonyos munka a szimulált rendszeren kívül történik.

Rizs. 2.1 Nyíl típusok

Az IDEF0 módszertanban mindössze ötféle interakció szükséges a blokkok között a kapcsolatuk leírásához: vezérlés, bemenet, vezérlési visszacsatolás, bemeneti visszacsatolás, kimeneti mechanizmus. Az irányítási és belépési kapcsolatok a legegyszerűbbek, mivel olyan közvetlen cselekvéseket tükröznek, amelyek intuitívak és nagyon egyszerűek.

Rizs. 2.2. Kimeneti kommunikáció

Rizs. 2.3. Vezetői kommunikáció

Vezérlési kapcsolat akkor jön létre, ha egy blokk kimenete közvetlenül érint egy kisebb dominanciájú blokkot.

A vezérlő visszacsatolása és a bemeneti visszacsatolás összetettebb, mert iteratív vagy rekurzív. Ugyanis az egyik jobból származó kimenetek befolyásolják a többi job jövőbeli végrehajtását, ami később az eredeti jobra is hatással lesz.

A vezérlés visszacsatolása ekkor következik be; amikor valamilyen blokk kimenete nagyobb dominanciájú blokkot érint.

A kilépési mechanizmus kapcsolatok ritkák. Olyan helyzetet tükröznek, amelyben az egyik funkció kimenete a másik céljának eszközévé válik.

Rizs. 2.4. Bemeneti visszajelzés

Rizs. 2.5. Vezetői visszajelzés

Az output-mechanizmus kapcsolatok az erőforrás-források (pl. szükséges eszközök, képzett személyzet, fizikai tér, felszerelés, finanszírozás, anyagok) elosztására jellemzőek.

Az IDEF0-ban egy ív ritkán ábrázol egyetlen objektumot. Általában tárgyak halmazát szimbolizálja. Mivel az ívek objektumok gyűjteményét képviselik, több kiindulási ponttal (forrással) és végponttal (célállomással) rendelkezhetnek. Ezért az ívek különféle módon elágazhatnak és összekapcsolódhatnak. A teljes ív vagy annak egy része kiléphet egy vagy több blokkból, és egy vagy több blokkban végződhet.

Az ívek szétágazó vonalként ábrázolt elágazása azt jelenti, hogy az ívek tartalmának egésze vagy egy része megjelenhet az egyes ágakban. Egy ív mindig egy elágazás előtt van felcímkézve, hogy a teljes halmaznak nevet adjon. Ezenkívül az ív minden ága felcímkézhető vagy nem a következő szabályok szerint:

a címkézetlen ágak az ív címkéjében megadott tárgyak súlyát tartalmazzák elágazás előtt;

az elágazási pont után címkézett ágak az elágazás előtti ívcímkében megadott objektumok egészét vagy egy részét tartalmazzák.

Az ívösszevonások az IDEFO-ban, amelyek egymáshoz közeledő vonalakként jelennek meg, azt jelzik, hogy az egyes ágak tartalma az eredeti ívek egyesítéséből származó ív címkéjét képezi. Egyesítés után az eredményül kapott ív mindig megjelölésre kerül, hogy jelezze az összevonás után megjelent új jellemzőkészletet. Ezenkívül az egyes ágak megjelölhetők vagy nem megjelölhetők az egyesülés előtt, a következő szabályok szerint:

Rizs. 2.6. Kimeneti-mechanizmus kapcsolat

a címkézetlen ágak az összevonás után az ív közös címkéjében megadott objektumok súlyát tartalmazzák;

az összevonás előtt megjelölt ágak az összevonás utáni közös jelölésben felsorolt objektumok mindegyikét vagy egy részét tartalmazzák,

blokkok száma a diagramon - N;

diagram bontási szint - L;

diagram egyenleg - NÁL NÉL;

a blokkhoz kapcsolódó nyilak száma - DE

Ez a tényezőkészlet minden modelldiagramra vonatkozik. Az alábbiakban felsoroljuk a diagramtényezők kívánt értékére vonatkozó ajánlásokat.

Arra kell törekedni, hogy az alsó szintek diagramjain a blokkok száma kisebb legyen, mint a szülődiagramokon, azaz a dekompozíció szintjének növekedésével az együttható csökkenjen. Így ennek az együtthatónak a csökkenése azt jelzi. hogy a modell felbontásával a függvények egyszerűsödjenek, ezért a blokkok száma csökkenjen.

A diagramoknak kiegyensúlyozottnak kell lenniük. Ez azt jelenti, hogy egy diagram keretein belül az ábrán látható helyzet. 2.7: az 1. feladatnak lényegesen több bejövő és vezérlő nyila van, mint a kimenőnek. Megjegyzendő ezt az ajánlást gyártási folyamatokat leíró modellekben nem végezhető el. Például egy összeszerelési eljárás leírásakor egy blokk sok nyilat tartalmazhat, amelyek leírják a termék összetevőit, és egy nyíl kiléphet - a késztermékből.

Rizs. 2.7. Példa egy kiegyensúlyozatlan diagramra

Vezessük be a diagram egyensúlyi együtthatóját

Arra kell törekedni ky volt a minimum a diagramhoz.

A diagram grafikai elemeinek elemzése mellett figyelembe kell venni a blokkok elnevezését is. A nevek kiértékeléséhez a szimulált rendszer elemi (triviális) függvényeinek szótárát állítjuk össze. Valójában a diagramok alsó, szintű bontásának funkcióinak ebbe a szótárba kell tartozniuk. Például egy adatbázismodellnél a „rekord keresése”, „rekord hozzáadása az adatbázishoz” függvények lehetnek elemiek, míg a „felhasználói regisztráció” függvény további leírást igényel.

A szókincs kialakítása és a rendszerdiagram-csomag összeállítása után figyelembe kell venni a modell alsó szintjét. Ha egyezést mutat a diagramblokkok nevei és a szótárból származó szavak között, akkor ez azt jelzi, hogy megfelelő szintű bontást sikerült elérni. Az ezt a kritériumot mennyiségileg tükröző együtthatót így írhatjuk fel L*C- a modellszint szorzata a szótárból származó blokknevek és szavak egyezéseinek számával. Minél alacsonyabb a modell szintje (magasabb L), annál értékesebbek az egyezések.

A BPWin indításakor alapértelmezés szerint a fő eszköztár, az eszközpaletta és a Model Explorer jelenik meg.

Új modell létrehozásakor egy párbeszédablak jelenik meg, amelyben meg kell adni, hogy a modell újonnan jön-e létre, vagy a ModelMart tárolóból nyílik meg, adja meg a modell nevét, és válassza ki a modell felépítésének módszerét ( 2.8. ábra).

2.8 Modellkészítés párbeszédpanel

A BPWin három módszert támogat – IDEF0, IDEF3 és DFD. A BPWin-ben lehetőség van vegyes modellek felépítésére, azaz egy modell egyszerre tartalmazhat IDEF0, IDEF3 és DFD diagramokat is. Az eszközpaletta összetétele automatikusan megváltozik, amikor egyik jelölésről a másikra váltunk.

A BPWin modelljei tevékenységek gyűjteményének tekinthetők, amelyek mindegyike valamilyen adatkészleten működik. Ha a modell bármely objektumára kattintunk a bal egérgombbal, egy felugró helyi menü jelenik meg, melynek minden eleme az objektum valamely tulajdonságának szerkesztőjének felel meg.

A rendszermodell felépítését az azt leíró összes dokumentum tanulmányozásával kell kezdeni. funkcionalitás. Az egyik ilyen dokumentum a feladatmeghatározás, nevezetesen a „Fejlesztési cél”, „A rendszer céljai és célkitűzései” és „A rendszer működési jellemzői” fejezetek.

A forrásdokumentumok áttanulmányozása, valamint a rendszer vásárlói és felhasználói megkérdezése után szükséges a modellezés céljának megfogalmazása és a modellre vonatkozó nézőpont meghatározása. Tekintsük felépítésének technológiáját a „Foglalkoztatási szolgáltatás az egyetem keretein belül” rendszer példáján, amelynek főbb jellemzőit a laboratóriumi munka № 1.

Fogalmazzuk meg a modellezés célját: a rendszer működésének leírása, amely a felhasználó számára érthető lenne, anélkül, hogy a megvalósítással kapcsolatos részletekbe mennénk. A modellt a felhasználók (hallgató, tanár, adminisztrátor, dékáni hivatal, cég) szemszögéből építjük fel.

Kezdjük egy IDEF0 kontextusdiagram felépítésével. A rendszer leírása szerint a fő funkciója az ügyfelek kiszolgálása a tőlük érkező kérések feldolgozásával. Így a kontextusdiagram egyetlen feladatát a "Rendszer kliensének kiszolgálása"-ként határozzuk meg. Ezután meghatározzuk a bemeneti és kimeneti adatokat, valamint a mechanizmusokat és a vezérlést.

Az ügyfél kiszolgálásához regisztrálni kell a rendszerben, meg kell nyitni az adatbázishoz való hozzáférést és feldolgozni kérését. A bemeneti adatok a következők lesznek: „ügyfél neve”, „kliens jelszó”, „eredeti adatbázis”, „ügyfél kérése”. A kérés teljesítése vagy a rendszerből történő információszerzéshez, vagy az adatbázis tartalmának megváltoztatásához vezet (például szakértői értékelések összeállításakor), így a kimenet „jelentések” és „módosított adatbázis” lesz. A kérésfeldolgozási folyamatot a rendszerfigyelő végzi az adminisztrátor felügyelete mellett.

Így definiáljuk a rendszer kontextusdiagramját (2.9. ábra).

2.9. ábra. Rendszerkontextus diagram

Bontsuk fel a környezeti diagramot az ügyfélszolgálat sorrendjének leírásával:

A rendszerhez való hozzáférés szintjének meghatározása.

Alrendszer kiválasztása.

Hozzáférés egy alrendszerhez.

Adatbázis módosítása (ha szükséges).

ábrán látható diagramot kapjuk. 2.10.

Miután befejezték a kontextusdiagram bontását, folytatják a következő szint diagramjának bontását. Általában a harmadik és az alsó szint figyelembevételekor a modellek visszatérnek a szülődiagramokhoz, és kijavítják azokat.

Rizs. 2.10. A "Szolgáltatás, a rendszer kliense" munka bontása

A kapott diagram összes blokkját egymás után felbontjuk. A rendszerhez való hozzáférés szintjének meghatározásának első lépése a felhasználói kategória meghatározása. A kliens neve alapján keresés történik a felhasználói adatbázisban, meghatározva annak kategóriáját. Egy bizonyos kategória szerint a rendszer használójának adott jogkörök pontosításra kerülnek. Ezután a rendszerhez való hozzáférési eljárást hajtják végre, ellenőrizve a hozzáférési nevet és jelszót. A jogosultságokkal és a rendszerhez való hozzáférés szintjével kapcsolatos információk kombinálásával a felhasználó számára engedélyezett műveletek készlete jön létre. Így a rendszerhez való hozzáférés szintjének meghatározása az ábrán látható módon fog kinézni. 2.11.

Rizs. 2.11."A rendszerhez való hozzáférés szintjének meghatározása" című munka bontása

A rendszer-hozzáférési eljárás végrehajtása után a monitor elemzi az ügyfél kérését, és kiválaszt egy alrendszert, amely feldolgozza a kérést. A „Hivatkozás egy alrendszerre” című mű dekompozíciója nem felel meg a modell céljának és nézőpontjának. A rendszer felhasználóját nem érdeklik a rendszer munkájának belső algoritmusai. Ebben az esetben fontos számára, hogy az alrendszer kiválasztása automatikusan, az ő beavatkozása nélkül történjen, így az alrendszer hívásának dekompozíciója csak bonyolítja a modellt.

Bontsuk fel az alrendszer által a kérések feldolgozására, kategóriák és felhasználói jogosultságok meghatározására elvégzett „Kliens kérésének feldolgozása” munkát. Mielőtt választ keres egy lekérdezésre, meg kell nyitnia az adatbázist (csatlakoznia kell hozzá). Általában az adatbázis a következő helyen található távoli szerver, ezért előfordulhat, hogy kapcsolatot kell létrehoznia vele. Határozzuk meg a munka sorrendjét:

Az adatbázis megnyitása.

Kérés teljesítése.

Jelentéskészítés.

Az adatbázis megnyitása után tájékoztatni kell a rendszert az adatbázishoz való kapcsolódásról, majd végrehajtani a lekérdezést és jelentéseket generálni a felhasználó számára (2.12. ábra).

Meg kell jegyezni, hogy a "Kérés végrehajtása" magában foglalja a különböző alrendszerek munkáját. Például, ha egy kérés tesztelést is tartalmaz, akkor azt a szakmai és pszichológiai tesztek alrendszere hajtja végre. A lekérdezés végrehajtásának szakaszában szükség lehet az adatbázis tartalmának módosítására, például szakértői értékelések összeállításakor. Ezért szükséges egy ilyen lehetőséget biztosítani a diagramon.

Rizs. 2.12.

A kapott diagram elemzésekor felvetődik a kérdés, hogy milyen szabályok szerint készülnek a jelentések? Előre formált sablonokra van szükség, amelyek az adatbázisból történő kiválasztáshoz fognak használni, és ezeknek a sablonoknak meg kell felelniük a lekérdezéseknek és előre definiáltaknak kell lenniük. Ezenkívül lehetőséget kell biztosítani az ügyfélnek a jelentés formájának megválasztására.

Javítsuk ki a diagramot a „Jelentéssablonok” és „Az adatbázis módosítására vonatkozó kérelmek” és a „Rendszerkliens” alagútnyilak hozzáadásával. A „Rendszerkliens” alagútkezelését azért alkalmaztuk, hogy a nyíl ne kerüljön a felső diagramra, mivel a jelentés űrlap kiválasztásának funkciója nem elég fontos ahhoz, hogy a szülő diagramon megjelenjen.

A diagram megváltoztatása az összes szülődiagram beállítását vonja maga után (2.13 - 2.15 ábra).

Célszerű a „Lekérdezés végrehajtása” munkát a DFD diagram segítségével bontani (3. számú laboratóriumi munka), mivel az IDEF0 módszertana a rendszert egymással összefüggő munkák halmazának tekinti, amely rosszul tükrözi az információfeldolgozási folyamatokat.

Rizs. 2.13. Az „Ügyfél kérésének feldolgozása” című munka bontása

Rizs. 2.14. A „Rendszer kliensének kiszolgálása” munka bontása (2. lehetőség)

Rizs. 2.15. Rendszerkörnyezet-diagram (2. lehetőség)

Térjünk át az utolsó blokk "Az adatbázis megváltoztatása" felbontására. A kliens szempontjából ezek a rendszerek egy adatbázisban helyezkednek el. Valójában hat adatbázis van a rendszerben:

felhasználói adatbázis,

tanulói adatbázis, (2. lehetőség)

üres álláshelyek adatbázisa,

haladás adatbázis,

teszt adatbázis,

szakértői értékelések DB,

DB összefoglaló.

A modellezés célja szerint fontos, hogy az ügyfél megértse, hogy a kapott adatok nem frissülnek azonnal a rendszerben, hanem egy további feldolgozási és ellenőrzési szakaszon esnek át. A változtatási algoritmus a következőképpen fogalmazható meg:

Meg van határozva az adatbázis, amelyben az információ megváltozik.

Az üzemeltető ideiglenes adatsort képez, és azt az adminisztrátor rendelkezésére bocsátja.

Az adminisztrátor kezeli az adatokat, és beviszi azokat az adatbázisba.

Ez a modell más módon is megvalósítható, lehetővé téve az adatbázis közvetlen kérésre történő frissítését, az adatkezelési folyamat megkerülésével. Ebben az esetben biztosítani kell az adatbázis sértetlenségét, hogy elkerüljük az adatbázis károsodását. Ebben az esetben a diagram így fog kinézni (2.17. ábra).

Rizs. 2.16. Az "Adatbázis módosítása" című munka bontása

Rizs. 2.17. Az "Adatbázis módosítása" (2. opció) munka bontása Az ábrán látható első lehetőséghez. 2.12

A „Változások az adatbázisban” további dekompozíció végrehajtása bonyolítja a modellt, elmagyarázva, hogyan történik az adatbázis fizikai megváltoztatása a rendszerben. Ebben az esetben a felhasználó nem kap semmit további információ a foglalkoztatási szolgálati rendszer munkájáról. Ennek a munkának a bontását az adatbázisrendszer tervezésének folyamatában kell elvégezni, a logikai adatbázismodell létrehozásának szakaszában.

A Lekérdezés-végrehajtási munka bontását a következő laborban végezzük el, bemutatva a DFD diagramok használatát az információfeldolgozási folyamatok leírására.

Végezzük el az 1-1. ábrán bemutatott modellek kvantitatív elemzését. 2.12 és 2.13, a fent leírt módszer szerint. Tekintsük a ^ együttható viselkedését ezeknél a modelleknél. Az "Ügyfél kérésének feldolgozása" szülődiagram együtthatója 4/2 = 2, a dekompozíciós diagramok pedig 3/3 = 1. Az együttható értéke csökken, ami a funkciók leírásának egyszerűsödését jelzi a szint csökkenésével. a modellről.

Vegye figyelembe az együttható változását Nak nek b két modellben.

a második lehetőséghez

Együttható Nak nek b értéke nem változik, ezért a diagram egyensúlya nem változik.

Feltételezzük, hogy a vizsgált diagramok dekompozíciós szintje elegendő ahhoz, hogy tükrözze a modellezés célját, és az alsó szint diagramjain a művek neveként elemi függvényeket használunk (a rendszerhasználó szemszögéből) .

Összegezve a vizsgált példát, meg kell jegyezni annak fontosságát, hogy egy rendszer modellezésekor több diagramot is figyelembe vegyünk. Ilyen lehetőségek merülhetnek fel a diagramok módosításakor, mint ahogyan az "Ügyfél kérésének feldolgozása" vagy a rendszerfunkciók alternatív megvalósításainak létrehozásakor (az "Adatbázis módosítása" munka bontása) során. Az opciók mérlegelése lehetővé teszi, hogy kiválassza a legjobbat, és további mérlegelés céljából belefoglalja a diagramcsomagba.

Célkitűzés:

az IDEF0 módszertan alapelveinek tanulmányozása,
új projekt létrehozása a BPWinben,
kontextusdiagram kialakítása,
kapcsolatok létrehozása.

A rendszer IDEF0 használatával történő leírását funkcionális modellnek nevezzük. A funkcionális modell célja a meglévő üzleti folyamatok leírása, amelyek természetes és grafikus nyelveket egyaránt használnak. Információ átviteléhez arról konkrét rendszer forrás grafikus nyelv maga az IDEF0 módszertan.

Minden egyes IDEF0-diagramok a blokkokat és íveket tartalmaz. A blokkok a szimulált rendszer funkcióit reprezentálják. Az ívek összekapcsolják a blokkokat, és megjelenítik a köztük lévő interakciókat és kapcsolatokat.

A blokk minden oldalának meghatározott, jól meghatározott célja van. A blokk bal oldala a bemeneteket, a felső a vezérlést, a jobb oldali a kimeneteket, az alsó a mechanizmusokat szolgálja. Az ilyen megjelölés bizonyos rendszerelveket tükröz: a bemeneteket kimenetekké alakítják; a vezérlés korlátozza vagy előírja a transzformációk végrehajtásának feltételeit; a mechanizmusok megmutatják, hogy egy funkció mit és hogyan teljesít.

A legdominánsabb doboz általában a diagram bal felső sarkában, míg a legkevésbé domináns doboz a jobb sarokba kerül.

Nyíl típusok

Az IDEF0 ötféle nyíltípust különböztet meg.

Kimenet- objektumok, amelyekké a bemeneteket átalakítják. Minden jobnak rendelkeznie kell legalább egy kilépési nyíllal, amely a job jobb oldaláról jön.

Hívás- egy speciális nyíl, amely egy másik munkamodellre mutat. A hívó nyíl a munka aljáról jön, és azt jelzi, hogy bizonyos munka a szimulált rendszeren kívül történik.

Rizs. 2.1 Nyíl típusok

Rizs. 2.2. Kimeneti kommunikáció

Rizs. 2.3. Vezetői kommunikáció

Vezérlési kapcsolat akkor jön létre, ha egy blokk kimenete közvetlenül érint egy kisebb dominanciájú blokkot.

A vezérlés visszacsatolása ekkor következik be; amikor valamilyen blokk kimenete nagyobb dominanciájú blokkot érint.

A kilépési mechanizmus kapcsolatok ritkák. Olyan helyzetet tükröznek, amelyben az egyik funkció kimenete a másik céljának eszközévé válik.

Rizs. 2.4. Bemeneti visszajelzés

Rizs. 2.5. Vezetői visszajelzés

Az output-mechanizmus kapcsolatok az erőforrás-források (pl. szükséges eszközök, képzett személyzet, fizikai tér, felszerelés, finanszírozás, anyagok) elosztására jellemzőek.

Az IDEF0-ban egy ív ritkán ábrázol egyetlen objektumot. Általában tárgyak halmazát szimbolizálja. Mivel az ívek objektumok gyűjteményét képviselik, több kiindulási ponttal (forrással) és végponttal (célállomással) rendelkezhetnek. Ezért az ívek elágazhatnak és összekapcsolódhatnak különböző utak. A teljes ív vagy annak egy része kiléphet egy vagy több blokkból, és egy vagy több blokkban végződhet.

a címkézetlen ágak az ív címkéjében megadott tárgyak súlyát tartalmazzák elágazás előtt;
az elágazási pont után címkézett ágak az elágazás előtti ívcímkében megadott objektumok egészét vagy egy részét tartalmazzák.

Rizs. 2.6. Kimeneti-mechanizmus kapcsolat

a címkézetlen ágak az egyesítés után a közös ívcímkében megadott objektumok súlyát tartalmazzák;
az összevonás előtt megjelölt ágak az összevonás utáni közös jelölésben felsorolt objektumok mindegyikét vagy egy részét tartalmazzák,

Kvantitatív diagram elemzés

A diagramok kvantitatív elemzéséhez felsoroljuk a modell indikátorait:

blokkok száma a diagramon - N;
diagram bontási szint - L;
diagram egyenleg - NÁL NÉL;
a blokkhoz kapcsolódó nyilak száma - DE

Ez a tényezőkészlet minden modelldiagramra vonatkozik. Az alábbiakban felsoroljuk a diagramtényezők kívánt értékére vonatkozó ajánlásokat.

A diagramoknak kiegyensúlyozottnak kell lenniük. Ez azt jelenti, hogy egy diagram keretein belül az ábrán látható helyzet. 2.7: az 1. feladatnak lényegesen több bejövő és vezérlő nyila van, mint a kimenőnek. Meg kell jegyezni, hogy ez az ajánlás nem feltétlenül alkalmazható a gyártási folyamatokat leíró modellekben. Például egy összeszerelési eljárás leírásakor egy blokk sok nyilat tartalmazhat, amelyek leírják a termék összetevőit, és egy nyíl kiléphet - a késztermékből.

Rizs. 2.7. Példa egy kiegyensúlyozatlan diagramra

Vezessük be a diagram egyensúlyi együtthatóját

Arra kell törekedni ky volt a minimum a diagramhoz.

BPWin Toolkit

A BPWin indításakor alapértelmezés szerint a fő eszköztár, az eszközpaletta és a Model Explorer jelenik meg.

2.8 Modellkészítés párbeszédpanel

A BPWin modelljei tevékenységek gyűjteményének tekinthetők, amelyek mindegyike valamilyen adatkészleten működik. Ha bármelyik modellobjektumra kattint a bal egérgombbal, megjelenik egy felugró ablak. helyi menü, melynek minden eleme az objektum valamely tulajdonságának szerkesztőjének felel meg.

Példa

A rendszermodell felépítését a működését leíró összes dokumentum tanulmányozásával kell kezdeni. Az egyik ilyen dokumentum a feladatmeghatározás, nevezetesen a „Fejlesztési cél”, „A rendszer céljai és célkitűzései” és „A rendszer működési jellemzői” fejezetek.

Kezdjük egy IDEF0 kontextusdiagram felépítésével, melynek fő feladata a rendszer leírása szerint az ügyfelek kiszolgálása a tőlük érkező kérések feldolgozásával. Így a kontextusdiagram egyetlen feladatát a "Rendszer kliensének kiszolgálása"-ként határozzuk meg. Ezután meghatározzuk a bemeneti és kimeneti adatokat, valamint a mechanizmusokat és a vezérlést.

Kontextus diagram

Így definiáljuk a rendszer kontextusdiagramját (2.9. ábra).

2.9. ábra. Rendszerkontextus diagram

Bontsuk fel a környezeti diagramot az ügyfélszolgálat sorrendjének leírásával:

A rendszerhez való hozzáférés szintjének meghatározása.
Alrendszer kiválasztása.
Hozzáférés egy alrendszerhez.
Adatbázis módosítása (ha szükséges).

ábrán látható diagramot kapjuk. 2.10.

Rizs. 2.10. A "Szolgáltatás, a rendszer kliense" munka bontása

Rizs. 2.11."A rendszerhez való hozzáférés szintjének meghatározása" című munka bontása

Bontsuk fel az alrendszer által a kérések feldolgozására, kategóriák és felhasználói jogosultságok meghatározására elvégzett „Kliens kérésének feldolgozása” munkát. Mielőtt választ keres egy lekérdezésre, meg kell nyitnia az adatbázist (csatlakoznia kell hozzá). Általánosságban elmondható, hogy az adatbázis egy távoli szerveren található, ezért szükséges lehet kapcsolatot létesíteni vele. Határozzuk meg a munka sorrendjét:

Az adatbázis megnyitása.
Kérés teljesítése.
Jelentéskészítés.

Rizs. 2.12.

Diagram beállítás

A diagram megváltoztatása az összes szülődiagram beállítását vonja maga után (2.13 - 2.15 ábra).

Rizs. 2.13. Az „Ügyfél kérésének feldolgozása” című munka bontása

Rizs. 2.14. A „Rendszer kliensének kiszolgálása” munka bontása (2. lehetőség)

Rizs. 2.15. Rendszerkörnyezet-diagram (2. lehetőség)

felhasználói adatbázis,
tanulói adatbázis, (2. lehetőség)
üres álláshelyek adatbázisa,
haladás adatbázis,
teszt adatbázis,
szakértői értékelések DB,
DB összefoglaló.

Meg van határozva az adatbázis, amelyben az információ megváltozik.
Az üzemeltető ideiglenes adatsort képez, és azt az adminisztrátor rendelkezésére bocsátja.
Az adminisztrátor kezeli az adatokat, és beviszi azokat az adatbázisba.

Rizs. 2.16. Az "Adatbázis módosítása" című munka bontása

Rizs. 2.17. Az "Adatbázis módosítása" (2. opció) munka bontása Az ábrán látható első lehetőséghez. 2.12

A „Változások az adatbázisban” további dekompozíció végrehajtása bonyolítja a modellt, elmagyarázva, hogyan történik az adatbázis fizikai megváltoztatása a rendszerben. Ebben az esetben a felhasználó nem kap további tájékoztatást a foglalkoztatási szolgálati rendszer működéséről. Ennek a munkának a bontását az adatbázis-rendszer tervezésének folyamatában kell elvégezni a létrehozás szakaszában logikai modell DB.

A Lekérdezés-végrehajtási munka bontását a következő laborban végezzük el, bemutatva a DFD diagramok használatát az információfeldolgozási folyamatok leírására.

Vegye figyelembe az együttható változását K b két modellben.

a második lehetőséghez

Együttható K bértéke nem változik, ezért a diagram egyensúlya nem változik.

tesztkérdések

Lista Biztonsági kérdések:

Mi az a modell az IDEF0 jelölésben?
Mit jelentenek az állások az IDEF0-ban?
Mi a művek elnevezési sorrendje?
Hány állásnak kell szerepelnie egy diagramon?
Mi a dominancia sorrendje?
Hogyan rendeződnek a munkakörök a dominancia elve szerint?
Mi a célja a diagramokon szereplő munkatéglalapok oldalainak?
Sorolja fel a nyilak típusait!
Nevezze meg a kapcsolatok típusait!
Mik azok a határnyilak?
Ismertesse az elágazó és összevonó nyilak elnevezésének elvét!
Milyen módszereket támogat a BPWin?
Sorolja fel a BPWin főablakának fő elemeit.
Ismertesse az új modell létrehozásának folyamatát a BPWinben.
Hogyan lehet összekapcsolni a munkákat?
Hogyan állítsuk be a munka nevét.
Ismertesse a munkabontás folyamatát!
Hogyan adjunk munkát a diagramhoz?
Hogyan lehet megoldani az alagútban lévő nyilakat?
Tartalmazhat-e egy BPWin modell több módszertani diagramot?