IDEF0 Activity Modeling

Size: px

Start display at page:

Download "IDEF0 Activity Modeling"

Neil Hodges
6 years ago
Views:

1 IDEF0 Activity Modeling

2 What is an Activity Model? A representation of the activities and the relationships between and among those activities in an existing or planned system. A collection of diagrams, glossary, and text along with the context, viewpoint, and purpose statements.

3 Benefits of Activity Modeling Document current activities for standardization and provide guidelines for new activity users to reduce the learning curve. Capture and analyze AS-IS activities. Design/Redesign activities for TO-BE scenarios.

4 What is IDEF0? An activity modeling method. Supports descriptions at any desired level of detail through Decompositions. Provides both a process and a language for constructing a model of the activities and their interrelationships.

5 Generic Activity Modeling Tool? Automates the IDEF0 method. Adheres to the method standard. Provides background quality checking and advisory support. Employs a SmartDraw capability.

6 Why Develop An Activity Model? To identify, document, and communicate what an enterprise does. To facilitate the collection of data needed to perform functional analysis. To identify value added and non-valued added activities. To identify if activities i i or functions that need to be improved.

7 What IDEF0 Represents Functions - Decisions, Actions, or Activities of the domain Objects - Physical or conceptual of the domain Roles that objects stand-in relative to functions Rl Relations between functions formed dby objects Relations between functions formed by the composition relationship

8 IDEF0 Provides... Needs Customer Expectations Establish Requirements A1 Understanding of Customer Requirements Requirements both a Procedure and a Language for Constructing a Model of the Decisions, Actions, and Activities in an Organization. Alternative Technologies Knowledge of Previous Design Design System A2 Contract for Tradeoff Decisions Design Raw Material Build System A3 Product Analysis Methods Design Methods Fabrication Methods

9 Components Context, Purpose, & Viewpoint

10 Establishing the Model Objectives Viewpoint Determines what can be seen and from what slant. Purpose Establishes the goal of the communication intended by the model. Defines why the model is being developed. Specifies how the model will be used. Context Establishes the scope of a model. Establishes the subject as part of a larger whole. Creates a boundary with the environment.

11 Context The context defines the boundaries of your model or what you will include in the model. Employee/ Position Data comes from outside the model. Applicant Data Customer Request Employee/Position Data Personnel Regulations Department Policy Supervisor Instructions Manning Conditions i Perform Personnel Action Personnel Actions Reports Supplies & Equipment Personnel Office Staff Information System

12 Context Scopes the model and defines the boundaries. If the scope is too big, the model becomes too complex and resource-intensive. If the scope is too small, the model becomes trivial. Determining the context is the most critical step in Activity Modeling.

13 Purpose The purpose p defines the reason to develop this particular activity model. Purpose: To document the activities associated with managing Personnel Actions and identify if non-value added activities that might be eliminated. Applicant Data Customer Request Employee/Position Data Personnel Regulations Department Policy Supervisor Instructions Manning Conditions i Perform Personnel Action Personnel Actions Reports Supplies & Equipment Personnel Office Staff Information System

14 Viewpoint The viewpoint describes the perspective p of the person or group developing the model. Purpose: To document the activities associated with managing Personnel Actions and Applicant Data Customer Request Employee/Position Data Personnel Regulations Department Policy Supervisor Instructions Manning Conditions i Perform Personnel identify if non-value added Actions activities that might be eliminated. Personnel Action Reports Viewpoint: Personnel Officer Supplies & Equipment Personnel Office Staff Information System

15 Purpose & Viewpoint Interaction Different purpose p and viewpoint result in different models. Non-value added Personnel Actions Purpose Non-value added Separation Actions Personnel Officer all personnel actions accomplished by multiple activities a single type of personnel action and multiple activities Viewpoint Personnel Clerk a few personnel actions accomplished by multiple activities a single type of personnel action and a small set of activities

16 IDEF0 Graphical Modeling Language

17 Diagram Syntax Controls Inputs Function or Outputs Activity (Verb Phrase) Mechanisms

18 Activity An action, function, or operation. Represented by a box and labeled as a verb phrase. Activity (Verb Phrase)

19 Input Any real object or data needed to perform an activity. Transformed through the completion of the activity. Input Activity (Verb Phrase)

20 Output Results from the completion of the activity. Input Activity (Verb Phrase) Output

21 Control Directs,,g guides, or initiates the activity. May also combine in some way with input(s) to result in an output. Control Input Activity (Verb Phrase) Output

22 Mechanism Indicates how the activity is accomplished. Control Input Activity (Verb Phrase) Output Mechanism

23 Minimal Requirements Control Activity (Verb Phrase) Output

24 Functional Decomposition

25 Functional Decomposition Further defines an activity by dividing it into its sub-activities. Ensures the gradual, systematic exposition of detail required to understand and communicate what activities are being performed.

26 Decomposition A1 A2 A-O A-O A0 More General (Parent) A3 A4 A0 2 A41 3 A-O 4 A42 A43 More Detailed (Child) A4

27 Functional Decomposition Each activity is composed of distinguishable sub- activities. A parent activity is decomposed into three to six child activities. Each child can become a parent and be further sub-divided.

28 Functional Decomposition Each activity in the model is unique and not represented multiple times. The Sales Dept., Accounting Dept., and Engineering Dept. may all submit Monthly Expense Reports......but in the activity model there is only one activity called Create Monthly Expense Reports.

29 Decomposition Company guidelines Budget guidelines Purchase request Maintain Accounts Payable A0 Correct ledger Payment Accounting staff

30 Decomposition Company guidelines Purchase request Process request Process guidelines Order A1 Invoice guidelines Invoice Process invoice Payment A2 Ledger guidelines Apply purchase to books A3 Correct ledger Accounting staff

31 Activity Hierarchy Each activity in a model is uniquely identified with an Activity Number (A0, A1, A12, etc.). Each activity can be uniquely placed within a model according to its relative decomposition number. An activity is depicted only once in an activity model.

32 Activity Hierarchy within a Model A0 A1 A2 A3 A4 A5 A11 A21 A31 A41 A51 A12 A22 A32 A42 A52 A13 A23 A33 A43 A53 A24 A44 A54 Node Tree A0 Perform Personnel Actions A1 Hire People A11 Review Applicant Information A12 Verify Past Employment A13 Interview Applicant A2 Fire People A21 Review Work History A22 Create Dismissal Documents A23 Counsel Employee A3 Promote People A31 Create Awards Package A32 Arrange Ceremony A33 Submit Paperwork A34 Insure Raise Action Completed Indented List An activity is depicted ed only once in an activity model.

33 Diagram Numbering A0 A A1 A2 A3 A0 2 4 A11 3 A-O A0 A12 4 A A31 3 A32 A-O 4 A33 A1 A3

34 Concept Hierarchy within a Model Concepts (inputs, controls, outputs, and mechanisms) are not uniquely identified within a model, but are identified between parent and child activities. Each concept is identified by a letter and number combination that specifies the concept s relative position on the parent diagram.

35 Concept Hierarchy within a Model C1 Company guidelines Purchase request I1 Process request A1 Process guidelines Order Invoice guidelines Invoice Process invoice A2 Payment Ledger guidelines O2 These designations are called ICOM codes. M1 Accounting staff Apply purchase to books A3 Correct ledger O1

36 Tunneling Tunneled concepts... Are intended to simplify a diagram. Communicate functional relationships between activities without cluttering every diagram in- between. Are not intended to be used as a means of li eliminating i i unnecessary concepts from a model. dl

37 Tunneling ( ) ( ) ( ) ( ) ) ( ) ( ) ( ) ( A concept tunneled at the unconnected end dindicates that the concept will not be shown at a higher level. A concept tunneled at the connected end indicates that the concept will not be shown at a lower level.

38 Tunneling Purchase request Company guidelines Budget guidelines C1 () Company guidelines Maintain Accounts Payable A0 Accounting staff Correct ledger Payment Process request A1 Process guidelines Order Invoice guidelines ( ) ( ) Invoice Process invoice A2 Payment Ledger guidelines O2 Apply purchase to books A3 Correct ledger O1 M1 Accounting staff

39 Tunneling

40 Bundling & Unbundling Bundling allows us to group several concepts into a larger set of concepts. Unbundling allows us to decompose a general concept into its component concepts.

41 Bundling & Unbundling Company guidelines Process request Process guidelines A1 Invoice guidelines Purchase request Company guidelines Budget guidelines ( ) A2 Maintain Accounts Payable A0 Correct ledger Payment Accounting staff Process invoice Ledger guidelines Apply purchase to books A3

42 Bundling & Unbundling

43 Bundling & Unbundling

44 Bundling & Unbundling

45 Bundling & Unbundling

46 Bunary and Internal Arrows

47 Bundary and Arrows Correspondence

48 Control feedbacks

49 Input feedbacks

50 Mechanism feedbacks

51 Components Glossary... New Student: An employee of the company that has been directed, or volunteered, to participate in training Instructor & Textbooks: The person responsible for teaching students and the documents, books, or other printed material used during the class documents the definition or characterization of one of the IDEF0 components of your effort. Each component in your model must have a glossary entry! What exactly do you mean by New Student? It s defined d in the glossary.

52 Components Text Elaboration... The input personnel folder is not an input to the A134 activity Monitor o Supply Consumption because this group of information is not transformed in any way, or needed by these activities. is associated with a diagram. It describes the things that may not be apparent, but are necessary, to know to understand a diagram. Why are these inputs only on boxes 1 and 2, but not 3?

53 Some Basic Rules Excluding the A-0 diagram, which has only one activity box, all other diagrams should have no less than three and no more than six Activity boxes. Each activity box must have at least one control and one output, but no more than six of each type of concept. Every diagram in a model must adhere to the model s overall viewpoint, purpose, and context.

54 Model Development

55 Development Process Establish and refine CV&P Collect information and artifacts Identify candidate functions Identify candidate objects Group functions into clusters and hierarchies Group objects into kind hierarchies Refine upwards and downwards Apply results Maintain

56 Establish and refine CV&P What are the boundaries? Determine what is in and out. Define the A-0. What is visible and what is not? What are the completion criteria? What decisions need to be made? You won t get it right the first time. You ll refine it during the course of doing the model.

57 Collect information and artifacts Identify sources and expert reviewers. Identify stake-holders. Interview. Go through all levels in the organization. Listen carefully. Take detailed notes. Collect as much as you can carry. Organize source material. Perform author-reader review cycle.

58 The Author-Reader Cycle Library Coordinator 1. Kit Model Author Expert Reviewer 2. Kit with Reviewer Comments 3. Kit with Comments and Author Response

59 Identify Candidate Activities Pick out Decisions, Actions, Activities. Behind each organization there must be an activity performed. Choose activity names carefully. Use common semantics. Remember the we rule. Consider name coining an art rather than a science. Organize into lists. By name similarity. By common objects involved. Validate with reviewer cycle.

60 Identify Candidate Objects Pick out object references. Name coining key activity for many objects. Definite descriptors need to be converted to names. Nouns or noun phrases. Be careful of state descriptors. Organize the lists. By kind. By part-of relations. By subsumption relations. Validate with reviewer cycle.

61 Clusters and Hierarchies Collect activities into composition hierarchies. Collect activities together that work on the same objects. Avoid (where possible) type hierarchies. Name the group of activities i i (if necessary). Strive for at least 3 activities per group and not more than 6. Identify missing members of the group (where y g g p( possible).

62 Part-of and Kind Hierarchies Solidify name references. Harmonize terminology. Simplify diagrams. Guide modeler in identification of missing activities. iii Construct new names for the super-kinds or compositions. Validate with experts.

63 Define Cells Associate objects with functions. Identify roles that objects play relative to a function. Input Output Control Mechanism Check object association on the next level of detail. Check object relevance on the same level.

64 Construct Diagrams Build what diagrams you can from the composition relationships. Look for inconsistent or incoherent or incomplete statements. Analyze for key missing relations. Complete the story as best able from source material. il Validate with experts.

65 Refine Upwards and Downwards Arrange diagrams in hierarchy. Check consistency of interfaces. Is the boundary clearly defined? Refine upwards. Do the leaf nodes contain information i required to address the modeling purpose? Refine downwards. Validate with experts.

66 Model Merge Combines separate models into a single overall model. Handles automatically duplicate model information according to user-specified criteria. Merges models from the same or different projects. Provides a valuable aid for group modeling projects.

67 Model Division Divides modeling tasks for a team modeling effort. Reduces excessively large models into submodels of a more manageable scope. Allows for placing sub-model into same or different projects.

68 Apply Results Arrange periodic review with stakeholders and model users. Get sign-off from both groups. Document model application. Gather requirements for additional i model definition. Gather requirements for model application. Requirements definition Data collection / organization i Training / Orientation

69 Maintain Shelf life of models is directly yproportional p to the use of the models. Models need to be maintained to continue to be useful. The reading of a model does not generally communicate all the understanding that the team acquired in the development of the model. Members of the team giving model walk-throughs Review of fthe source material and model evolution process

70 Successful Activity Modeling

71 Understanding IDEFØ Diagrams Reading is done top-down. Functions show what must be accomplished hence should be labeled with an active verb phrase. Arrows with one end unconnected indicate that the concepts are supplied, consumed, or used outside the scope of the diagram.

72 Understanding IDEFØ Diagrams Cll Call arrows idi indicate a system tht that completely ltl performs the function. Relationships: an output that is used as an I,C, or M by another function indicates that the latest function is dependent on the former but not how or when. Multiple ICOMS do not indicate conjunction; this is true as well for functions in a diagram.

73 Best Practice Guidelines Think control and constraint, not flow. The diagram structure must show relationships that hold regardless of sequence. Diagrams should say the right thing regardless of what steps are taken first. When a diagram is cluttered, it is often an indication that you put pieces of information that are at different levels of details. Leave out questionable concepts.

74 Best Practice Guidelines A solid abstraction is both clearer and more powerful than premature detail. A concept tis a control unless it obviously serves as an input (is it modified?) If in doubt, make it a control. Input/output: what is done. Control: why. Mechanism: how.

75 Modeling Checklist In Facilitating Business Engineering, g, did it: Define What Activities are Performed? Define What is Needed to Perform those Activities? Determine What the Current System Does Right? Determine What the Current System Does Wrong? Define Activity Interfaces (Objects & Data)? Capture the Costs Related to the Activities?

76 Modeling Checklist In Facilitating Communication, did it: Enhance Domain Expert Understanding? Facilitate Consensus Decision-Making? Promote Effective Team Activity?

77 Model Quality Checklist Completeness Are all field-entries, labels, descriptions, purpose, and viewpoint present? Conciseness Is the terminology used appropriate for the target audience? Are some of the model elements redundant? Are all elements clearly distinct from one another?

78 Model Quality Checklist Consistency Is the terminology uniform throughout the model? Are the model elements traceable to the system being modeled? Correctness Is the model an accurate description of the system being modeled? Are implied relations and constraints traceable to system constraints and relations?

79 Model Quality Checklist Complexity/Understandability y Is the model clear to the reviewer? Is the information intended to be conveyed by the Is the information intended to be conveyed by the model accurately depicted via the syntax?

80 Conclusion IDEF0 documents what the studied system does. IDEF0 identifies where the unreasonable expenses are and where non-value added activities exist. IDEF0 concentrates upon functional dependencies, not organizational, sequential, or cause-effect relationships.

81 Review & Questions IDEF0 Activity Modeling

Information Technology Audit & Cyber Security

Information Technology Audit & Cyber Security Use Cases Systems & Infrastructure Lifecycle Management OBJECTIVES Understand the process used to identify business processes and use cases. Understand the