IDEF0 metodik

Den huvudsakliga av de tre metoder som stöds av BPwin är IDEF0. IDEF0, syftar på IDEF-familjen, som dök upp i slutet av sextiotalet under namnet SADT (Structured Analysis and Design Technique). IDEF0 kan användas för att modellera ett brett utbud av system. För nya system syftar användningen av IDEF0 till att definiera krav och specificera funktioner för den efterföljande utvecklingen av ett system som uppfyller kraven och implementerar de valda funktionerna. Med avseende på redan existerande system kan IDEF0 användas för att analysera de funktioner som utförs av systemet och visa mekanismerna genom vilka dessa funktioner utförs. Resultatet av att tillämpa IDEF0 på ett system är en modell av det systemet, bestående av en hierarkiskt ordnad uppsättning diagram, dokumentationstext och ordböcker länkade till varandra genom korsreferenser. De två viktigaste byggstenarna i IDEF0-diagram är affärsfunktionerna eller aktiviteterna (representerade i diagrammen som rutor) och de data och objekten (representerade som pilar) som länkar samman aktiviteterna. I det här fallet är pilarna, beroende på vilken sida av arbetsrektangeln de går in i eller vilken sida de lämnar, indelade i fem typer:

· Ingångspilar (ingår i verkets vänstra sida) - visar data eller objekt som ändras under utförandet av arbetet.

· Kontrollpilar (ingår i verkets övre gräns) - visar reglerna och begränsningarna enligt vilka arbetet utförs.

· Utgångspilar (gå ut från höger sida av verket) - avbildar data eller objekt som dyker upp som ett resultat av arbetet.

Mekanismpilar (ingår i den nedre kanten av arbetet) - visar de resurser som krävs för att slutföra arbetet, men ändras inte under arbetet (till exempel utrustning, mänskliga resurser ...)

· Anropspilar (gå ut från botten av verket) - visar förhållandet mellan olika diagram eller modeller, pekar på något diagram, där detta arbete övervägs mer i detalj.

Alla jobb och pilar måste namnges. Det första diagrammet i IDEF0-diagramhierarkin visar alltid hur systemet fungerar som helhet. Sådana diagram kallas kontextdiagram. Kontexten innehåller en beskrivning av syftet med modelleringen, omfattning (beskrivning av vad som kommer att betraktas som en komponent i systemet och vad som en extern påverkan), och synvinkel (positionen från vilken modellen kommer att byggas). Vanligtvis väljs synvinkeln för den person eller objekt som ansvarar för driften av det simulerade systemet som helhet som synvinkel.

Figur 7.1. Funktionsblock och gränssnittsbågar

Aktiviteterna i diagrammen visas som rektanglar (funktionella block). Varje jobb skildrar en funktion eller uppgift och hänvisas till med ett verb eller en verbfras som betecknar en handling, till exempel "Göra en produkt", "Kundservice" etc. Pilarna är markerade med ett substantiv och representerar föremål eller information som länkar verken till varandra och till omvärlden.

Efter beskrivningen av sammanhanget genomförs en funktionell nedbrytning - systemet är uppdelat i delsystem och varje delsystem beskrivs i samma syntax som systemet som helhet. Sedan delas varje delsystem in i mindre och så vidare tills önskad detaljnivå nås. Som ett resultat av en sådan partition avbildas varje fragment av systemet på ett separat nedbrytningsdiagram.

Efter att sammanhanget har beskrivits utförs konstruktionen av följande diagram i hierarkin. Varje efterföljande diagram är en mer detaljerad beskrivning (nedbrytning) av ett av verken i diagrammet ovan. Ett exempel på kontextarbetesuppdelning visas i Fig.7.2 och Fig.7.4. Beskrivningen av varje delsystem utförs av en analytiker tillsammans med en expert inom ämnesområdet. Vanligtvis är experten den person som är ansvarig för detta delsystem och som därför grundligt känner till alla dess funktioner. Alltså delas hela systemet upp i delsystem till önskad detaljnivå och en modell erhålls som approximerar systemet med en given noggrannhetsnivå. Efter att ha fått en modell som adekvat speglar de nuvarande affärsprocesserna (den så kallade AS IS-modellen) kan analytikern enkelt se alla de mest utsatta platserna i systemet. Efter det, med hänsyn till de identifierade bristerna, är det möjligt att bygga en modell för en ny organisation av affärsprocesser (TO BE-modellen).

En av de viktigaste egenskaperna hos SADT-metoden är det gradvisa införandet av ökande detaljnivåer allteftersom diagrammen som representerar modellen skapas.

Figur 7.2, som visar de tre diagrammen och deras samband, visar strukturen för IDEF0.-modellen. Varje komponent i modellen kan delas upp i ett annat diagram. Varje diagram illustrerar den "interna strukturen" av ett block i det överordnade diagrammet.

Figur 7.2 - Ett exempel på ett kontextdiagram

Som du kan se i figur 7.2 låter BPwin dig markera aktiviteter och pilar med olika färger, samt länka pilnamn till själva pilarna (en pil som heter "Rapportering"), vilket ökar diagrammets synlighet och läsbarhet.

Figur 7.3 - Ett exempel på ett nedbrytningsdiagram

Figur 7.4 - Ett exempel på ett kontextdiagram

Figur 7.5 - Nedbrytningsdiagram Exempel

Diagramhierarki

Konstruktionen av en IDEF0-modell börjar med representationen av hela systemet i form av den enklaste komponenten - ett block och bågar som representerar gränssnitt med funktioner utanför systemet. Eftersom ett enda block representerar hela systemet som helhet är namnet som ges i blocket generiskt. Detta gäller även för gränssnittsbågar - de representerar också hela uppsättningen externa gränssnitt för systemet som helhet.

Sedan beskrivs blocket som representerar systemet som en enda modul i ett annat diagram med flera block sammankopplade med gränssnittsbågar. Dessa block representerar huvudunderfunktionerna i den ursprungliga funktionen. Denna nedbrytning avslöjar en komplett uppsättning underfunktioner, som var och en representeras som ett block, vars gränser definieras av gränssnittsbågar. Var och en av dessa underfunktioner kan dekomponeras på liknande sätt för en mer detaljerad vy.

I alla fall kan varje underfunktion endast innehålla de element som ingår i den ursprungliga funktionen. Modellen kan inte heller utelämna några element, det vill säga, som noterat, föräldrablocket och dess gränssnitt tillhandahåller sammanhang. Ingenting kan läggas till den, och ingenting kan tas bort från den.

De bågar som går in i och ut ur ett block i ett diagram på översta nivån är exakt desamma som de bågar som går in i och lämnar ett diagram på lägre nivå, eftersom blocket och diagrammet representerar samma del av systemet.

Figur 7.6 - SADT-modellens struktur. Diagramnedbrytning

Figur 7.7 - Efterlevnaden måste vara fullständig och konsekvent

Vissa bågar är fästa vid diagramrutorna i båda ändarna, medan andra har ena änden kvar obunden. Oanslutna ljusbågar motsvarar ingångarna, kontrollerna och utgångarna på föräldrablocket. Källan eller destinationen för dessa gränsbågar kan endast hittas i det överordnade diagrammet. De obundna ändarna måste matcha bågarna i originaldiagrammet. Alla gränsbågar måste fortsätta på det överordnade diagrammet för att det ska vara komplett och konsekvent.

Som nämnts visar mekanismerna (bågar på undersidan) hur funktionerna utförs. Mekanismen kan vara en människa, en dator eller någon annan enhet som hjälper till med denna funktion (figur 7.8).

Ris. 7.8. Exempel på mekanism

Varje block i diagrammet har sitt eget nummer. Ett block av vilket diagram som helst kan beskrivas ytterligare med ett diagram på lägre nivå, som i sin tur kan detaljeras ytterligare med det erforderliga antalet diagram. Således bildas en hierarki av diagram.

För att indikera positionen för valfritt diagram eller block i hierarkin används diagramnummer. Till exempel är A21 ett diagram som beskriver ruta 1 i diagram A2. På liknande sätt beskriver A2 ruta 2 i diagram A0, som är modellens översta diagram. Figur 7.9 visar ett typiskt diagramträd.

Figur 7.9 - Hierarki av diagram