Systems Engineering CSC 595_495 Spring 2018 Howard Rosenthal

Transcription

1 Systems Engineering CSC 595_495 Spring 2018 Howard Rosenthal 1

2 Notice This course is based on and includes material from the text: The Engineering Design of Systems: Models and Methods (Wiley Series in Systems Engineering and Management) 3rd Edition Dennis M. Buede, William D. Miller Publisher: Wiley; 3 edition (February 29, 2016) Language: English ISBN-13: It also utilizes information from these two additional books as well as many cited references: Practical Guide to SysML, Third Edition: The Systems Modeling Language (The MK/OMG Press) 3rd Edition Sanford Friedenthal, Alan Moore, Rick Steiner Series: The MK/OMG Press Publisher: Morgan Kaufmann; 3rd edition (November 7, 2014) ISBN-13: System Engineering Analysis, Design, and Development: Concepts, Principles, and Practices (Wiley Series in Systems Engineering and Management) 2nd Edition Charles S. Wasson Series: Wiley Series in Systems Engineering and Management Hardcover: 882 pages Publisher: Wiley; 2 edition (December 2, 2015) Language: English ISBN-13: Other material was used from these web sites:

3 Lesson Goals Understand what an IDEFØ model is Understand how to construct an IDEFØ model Build an IDEFØ model 3

4 4

5 What is IDEF? IDEF, initially abbreviation of ICAM Definition, renamed in 1999 as Integration DEFinition, refers to a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition The IDEF models include IDEFØ: Function modeling IDEF1 : Information modeling IDEF1X : Data modeling IDEF2 : Simulation model design IDEF3 : Process description capture IDEF4 : Object-oriented design IDEF5 : Ontology description capture IDEF6 : Design rationale capture IDEF7 : Information system auditing IDEF8 : User interface modeling IDEF9 : Business constraint discovery IDEF10 : Implementation architecture modeling IDEF11 : Information artifact modeling IDEF12 : Organization modeling IDEF13 : Three schema mapping design IDEF14 : Network design 5

6 IDEFØ Overview IDEFØ is a method designed to model the decisions, actions, and activities of an organization or system IDEFØ was derived from a well-established graphical language, the Structured Analysis and Design Technique (SADT) The United States Air Force commissioned the developers of SADT to develop a function modeling method for analyzing and communicating the functional perspective of a system IDEFØ was not included in SYSML, but it still remains an important and widely used classical modeling tool IDEF0 is definitely not a sufficient modeling representation for the engineering of systems since it is not precise enough to define a unique dynamic representation of the system's design Effective IDEFØ models help to organize the analysis of a system and to promote good communication between the analyst and the customer IDEFØ is useful in establishing the scope of an analysis, especially for a functional analysis As a communication tool, IDEFØ enhances domain expert involvement and consensus decision-making through simplified graphical devices As an analysis tool, IDEFØ assists the modeler in identifying what functions are performed, what is needed to perform those functions, what the current system does right, and what the current system does wrong IDEFØ models are often created as one of the first tasks of a system development effort. 6

7 IDEFØ Concepts (1) Cell Modeling Graphic Representation The "box and arrow" graphics of an IDEFØ diagram show the function as a box and the interfaces to or from the function as arrows entering or leaving the box To express functions, boxes operate simultaneously with other boxes, with the interface arrows "constraining" when and how operations are triggered and controlled. IDEFØ Communications Features Diagrams based on simple box and arrow graphics. English text labels to describe boxes and arrows and glossary and text to define the precise meanings of diagram elements. The gradual exposition of detail featuring a hierarchical structure, with the major functions at the top and with successive levels of subfunctions revealing well-bounded detail breakout. A "node chart" that provides a quick index for locating details within the hierarchic structure of diagrams. The limitation of detail to no more than six subfunctions on each successive function 7

8 IDEFØ Concepts (2) Something (matter, energy, information, system) transformed by the process Something that guides, facilitates, limits, or constrains the process Something that results from the process A means by which the process is performed A reference to another model. 12 The Basic IDEF Structure 8

9 IDEFØ Concepts (3) Rigor and precision rules in IDEFØ Control of the details communicated at each level (three to six function boxes at each level of a decomposition). Bounded Context (no omissions or additional out-of-scope detail). Diagram Interface Connectivity (Node numbers, Box numbers, C- numbers, and Detail Reference Expression). Data Structure Connectivity (ICOM codes and the use of parentheses). Unique Labels and Titles (no duplicated names). Syntax Rules for Graphics (boxes and arrows). Data Arrow Branch Constraint (labels for constraining the data flow on branches). Input versus Control Separation (a rule for determining the role of data). Data Arrow Label Requirements (minimum labeling rules). Minimum Control of Function (all functions require at least one control). Purpose and Viewpoint (all models have a purpose and viewpoint statement) 9

10 10

11 IDEFØ General Rules & Guidelines Rules Conservation of inputs, controls, outputs & mechanisms Every function has a control and output Guidelines 3 to 6 functions per page arranged diagonally Control-oriented functions placed at top left Major output functions placed on bottom right Arcs & functions are decomposable Feedback is defined by arcs moving from bottom right to top left 11

12 Box and Arrow Rules (1) Boxes Boxes shall be sufficient in size to insert box name Boxes shall be rectangular in shape, with square corners Boxes shall be drawn with solid lines A box shall be named with an active verb or verb phrase Each side of a function box shall have a standard box/ arrow relationship: Input arrows shall interface with the left side of a box Control arrows shall interface with the top side of a box Output arrows shall interface with the right side of the box Mechanism arrows (except call arrows) shall point upward and shall connect to the bottom side of the box Mechanism call arrows shall point downward, shall connect to the bottom side of the box, and shall be labeled with the reference expression for the box which details the subject box 12

13 Box and Arrow Rules (2) Box/Node numbers Single box in context (A-0) diagram numbered A0 ( Activity 0) Boxes in context diagram s child numbered A1, A2, A3,... [A6] Boxes in A1 s child diagram numbered A11, A12,... Boxes in A2 s child diagram numbered A21, A22,... Boxes in A21 s child diagram numbered A211, A212,... and so on... 13

14 Box and Arrow Rules (3) Arrows Arrows that bend shall be curved using only 90 degree arcs Arrows shall be drawn in solid line segments Arrows shall be drawn vertically or horizontally, not diagonally Arrow ends shall touch the outer perimeter of the function box and shall not cross into the box Arrows shall attach at box sides, not at corners Arrow segments, except for call arrows, shall be labeled with a noun or noun phrase unless a single arrow label clearly applies to the arrow as a whole A squiggle shall be used to link an arrow with its associated label, unless the arrow/label relationship is obvious Arrow labels shall not consist solely of any of the following terms: function, input, control, output, mechanism, or call 14

15 Box and Arrow Rules (4) When drawing interface arrows Think control and constraint, not flow Don t worry about sequence All boxes may be active simultaneously Bundle groups of arrows, when possible Don t clutter with arrows. All boxes must have control arrows, but they don t require input arrows. Give arrows noun or noun phrase names 15

16 There Are Three Feedback Loops In IDEFØ label Control Feedback up & over Input Feedback label down & under Mechanism Feedback down & under label 16

17 The Top-Level Context Diagram In IDEFØ Subject of model represented by single box with bounding arrows Called A-0 ( A minus zero ) Box and arrows are very general Sets model scope or boundary and orientation Should include Purpose Viewpoint 17

18 Sample Context Diagram A-0 Assemble Widgets Purpose: To illustrate IDEF0 modeling for the Work Systems Engineering process. Viewpoint: Industrial/manufacturing engineer

19 Sample Context Diagram Another A-0 Diagram With Additional Materials 19

20 The Child Diagram In IDEFØ The single process in Context Diagram (A-0) may be decomposed into subprocesses and modeled in a child (A0) diagram. Each process in the A0 diagram may be decomposed further into subprocesses and modeled in (grand-) child (A1, A2,... A6) diagrams Each (grand-) child process may be decomposed further into subprocesses and modeling (greatgrand-) child diagrams Remember only 3-6 subprocesses per process 20

21 Diagram Features Arrows As Constraints Connecting output of a box representing a process that is input/ control/mechanism to another box means that the second process is constrained by the first in this A0 diagram 21

22 Diagram Features Concurrent Operations Box order and connections do not necessarily imply sequence! Processes may proceed concurrently Concurrent with A32 and A33 22

23 Diagram Features Branching Arrows A & B 27 23

24 Diagram Features Inter-Box Connections (2) Except for A-0, diagrams contain 3 6 boxes Normally organized on diagonal ( staircase ) Any output of one box may be input, control, or mechanism of another box If box is detailed on child diagram, every arrow connected to the box appears on the child diagram (unless it is tunneled) 24

25 Diagram Features Inter-Box Connections (2) Node A

26 Diagram Features Boundary Arrows: Arrows From Parent box On Parent Diagram Node A3 Coded by prefix and number 31 26

27 IDEFØ Page Structure Page # s Function # s A-1 A-11 A-0 A-12 A-13 A-0 A0 A0 A1 A2 A3 A1, A3 A11 A12 A13 A31 A32 A33 A34 A33 A331 A332 A333 A334 A335 Page Number(s) Page Content A - 1 Ancestor or external system diagram A - 0 Context or system function diagram (contains A0) A0 Level 0 diagram with first tier functions specified A1, A2,... Level 1 diagrams with second tier functions specified A11, A12,..., A21,... Level 2 diagrams with third tier functions specified... Chapter 3 - Modeling and Process Modeling 27

28 Example Of The IDEFØ Page Structure Node List A-0: Assemble widgets A0: Assemble widgets A1: Restock parts A2: Get widget parts A3: Assemble parts A31: Hold widget base A32: Position parts in place A33: Secure parts to base A34: Release assembled widget A4: Inspect widgets 28

29 The IDEFØ Page Structure Is A Hierarchical Structure Widgets A0 Assemble Widgets A1 A2 A3 A4 Restock Parts Get Widget Parts Assemble Part Inspect Widgets A31 Hold Widget Base A32 Position Parts In One Place A33 Secure Parts To Base A34 Release Assembled Widget 29

30 Explanatory Materials Used With IDEFØ (1) Text and Glossary Associated textual information used to clarify model. Glossary includes definitions of Processes (activities, functions) Inputs Controls Outputs Mechanisms Examples in the glossary might include Get widget parts (process) The process of getting widget parts from the stock areas so that widgets may be assembled Parts for widgets (output) Parts retrieved from the workstation stock areas and ready to be used in assembly 30

31 Explanatory Materials Used With IDEFØ (2) For Exposition Only Diagram (FEO) Provides supplementary information to help reader understand model Need not comply with IDEFØ rules An example is a flowchart to describe a procedure (action/decision sequence) that can be used to perform the process All of this additional material that exists outside the model is one of the reasons that IDEFØ is not in SYSML IDEFØ was developed when people were just starting to use modeling tools, and long before MBSE came into play 31

32 32

33 A Step By Step IDEFØ Tutorial (1) 1. Identify the system or process to be described. a. Use a name that clearly indicates what it is, possibly adding further description of what is and what is not included. 2. Identify the purpose or objectives of describing the process. a. This will help to determine whether IDEFØ is an appropriate tool, and will also help when making other decisions, for example whether to decompose the system further at lower levels. 3. Decide on the viewpoint from which the process is to be described. a. For example, a sales manager might have a broader view of a sales process than a sales person, as the sales manager includes the clerical activities in the sales office as well as the customer-salesperson process. b. The objectives from step 2 will help with this decision. For example, if the objective is to improve the amount of direct sales, then the viewpoint of the salesperson may be most appropriate. 4. Identify the decomposition strategy to be used. a. This is the set of rules to use when deciding how to break down activities into sub-activities, and may depend on the type of system being described and the objectives from step 2. Possible strategies include: 1) Functional decomposition breaks down activities according to what is done, rather than how it is done, and is probably the most common strategy. 2) Role decomposition breaks down things according to who does what. It can be an easy and useful starting point, but is likely to constrain improvements if it is maintained. 3) Subsystems decomposition divides systems first by major subsystem. This is useful when these subsystems are largely independent of one another. Lifecycle decomposition breaks down a system first by the phases of activity. Again, this is most useful when these phases are clearly defined and relatively independent. 33

34 A Step By Step IDEFØ Tutorial (2) 5. Before starting to draw diagrams, gather information about the system. a. This may start with reading of existing documents or observing the process in action, but the most useful activity is likely to be formal interviews with selected people. This not only is the best source of information, but it will also help to gain involvement and acceptance in any later improvements. Use the following process for interviews: 1) In the initial interview, aim first to agree the purpose and viewpoint, then find sufficient details to be able to draw the first two levels only (A-0 and A0). 2) Before each interview, review existing information and identify the scope of what is to be identified. 3) In interviews, work to acquire the most useful information, asking open questions, probing in key areas and checking the validity of assumptions. First, find out what is produced by and used within the process, including inputs, controls, outputs and mechanisms. This can be helped by asking questions of the process, starting with outputs (What is produced?) and work backwards (What is needed to produce this?). This will result in a list of items (often called the data list) that will form the arrows in the diagram. 4) Next, use the data list to identify the list of activities within the process, asking how items are used or produced. 5) Then explore how activities and data items relate to one another and how they group together. The notes may look like the figure on the next slide. 34

35 A Step By Step IDEFØ Tutorial (3) 35

36 A Step By Step IDEFØ Tutorial (4) 6. From the information gained in step 5, draw a set of diagrams. Draw the A0 diagram first, as illustrated, then summarize this in the A-0 diagram. When drawing a diagram, use the following sequence of actions: a. Use the decomposition strategy from step 4 to identify between three and six activities that will be shown on the diagram (around four is often best). It can be useful to try several different decompositions before settling on one. b. Sort these activities into the order of dominance. The more dominant of a pair of activities is one which has the greatest influence over the other. For example 'produce plan' has higher dominance than 'build product'. c. Place the activity boxes on the diagram, using the general layout strategy of putting most dominant activity in the top left, with subsequent activities along the diagonal, such that the least dominant activity ends up in the bottom right corner. When positioning the activities, try to think ahead to where arrows will go. Put the name of each activity in its box. d. Draw the arrows for each data item, starting with inputs and outputs, then adding controls then mechanisms. 1) Combine and split lines to help simplify the diagram. 2) When the lines are drawn, write in the labels for each line, being careful that the label cannot mistakenly be confused with another item. 3) If a label is not clearly associated with a single line, draw a short squiggly line between it and the line. e. Add parentheses ('tunnel' marks) to the end of any line which will not be shown in its parent or child diagram, as illustrated. Tunnel items that will not add useful information elsewhere. f. Identify the diagram with a node name, title and C-number, as illustrated on next slide. 1) It may also be useful to add other data, such as the date and the status of the diagram (e.g. initial, draft, final). Use a log, as illustrated, to ensure that all C-numbers are unique. g. Review the completed diagram for correctness, consistency, completeness and clarity. Check it against the purpose (step 2), viewpoint (step 3), decomposition strategy (step 4) and available information (step 5). Revise and repeat the above steps as necessary. 36

37 A Step By Step IDEFØ Tutorial (5) A-0 Diagram 37

38 A Step By Step IDEFØ Tutorial (6) 7. For each diagram, it is useful to write a Glossary page that further describes each data item, as illustrated. This can contain any text that will help the understanding of individual items or the overall system, although it should be kept brief, to avoid an 'information overload'. 38

39 A Step By Step IDEFØ Tutorial (7) 8. Decide whether to review the pages produced so far. a. It is useful to review early, when the A-0 and A0 diagrams (and possibly the level below) are completed, and subsequently when significant changes have been made. 1) If you do hold a review until all pages are completed, then this can result in significant extra effort being spent in rework. b. When holding a review, first create a kit, consisting of all pages requiring review, together with a cover page, and send it to appropriate contributing experts for review. 1) The cover page details the reviewer list, the contents of the kit and what is expected of the reviewers, including when to return it and any other special instructions. c. The reviewers read the pages in the kit and write corrections, in red directly on the pages of the kit, before returning it to the author. Specific items to review include: 1) The detail of each diagram, including the title and node name, all activities and arrows, additional glossaries and other material. 2) The overall system, and how the diagrams fit together, including use of the stated breakdown strategy. 3) How well the stated viewpoint is represented. d. The author then examines the reviewer's corrections and writes comments in blue ink (thus differentiating from the reviewer's corrections). 1) Agreement with reviewer corrections are shown with ticks and other comments are written alongside. e. The author and each reviewer then meet and discuss the comments and corrections. They agree to actual changes which the author then implements. 1) Make sure that when an item is changed, all other diagrams affected by the change are also updated. 39

40 A Step By Step IDEFØ Tutorial (8) 9. For each box which has not yet been decomposed, decide whether it is worth taking this step, or whether sufficient detail exists at this point. Considerations of whether to stop decomposition include: a. The final set of diagrams (or 'model') should contain sufficient detail to satisfy the stated purpose from step 2. b. A good point to stop is when boxes start saying 'how' instead of 'what', or where the viewpoint changes. c. Boxes should describe activities that are solid and unique functions, not trivial items nor duplicates of other boxes. d. For boxes that are to be decomposed further, the above process of interview, create and review is repeated as required. 1) Generally, the process experts should be fully involved, but they should not be worn down with too many interviews and reviews, as this is likely to cause them to become annoyed and disinterested, with consequent damage to the model and its use. 40

41 IDEFØ Class Exercise Consider the A-0 Process for System Level Design as defined below. Draw the A0 diagram of this process. Design Function Major Inputs Major Outputs Develop Operational Concept Define System Boundary with External Systems Diagram Develop System Objectives Hierarchy Develop, Analyze and Refine Requirements (Stakeholders and System) Ensure Requirements Feasibility Define the Test System Requirements Obtain Approval of System Documentation Stakeholders Inputs Objective Hierarchy & Value Parameters for Meta-System Recommended Concept Operational Concept Operational Concept Stakeholders Inputs Operational Concept System Boundary, Inputs & Outputs Objectives Hierarchy Stakeholders Inputs Stakeholders & Systems Requirements SE Team s Inputs Stakeholders & Systems Requirements Stakeholders Inputs Stakeholders & Systems Requirements Operational Concept System Concept Input-output traces Meta-system MOEs System Boundary, System s Inputs and Outputs System-level Objectives Hierarchy Stakeholders & Systems Requirements Design Feasibility Test System Requirements Stakeholder & System Requirements Documents 41

42 Full Example See IDEFØ For Widgets.pdf in references 42