Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 May 14, 2012 The Conceptual Design Featuring The Concept Of Operations A Tutorial By Joseph F Iaquinto, PE May 14, 2012 © 2012 Joseph F Iaquinto, PE.

Similar presentations


Presentation on theme: "1 May 14, 2012 The Conceptual Design Featuring The Concept Of Operations A Tutorial By Joseph F Iaquinto, PE May 14, 2012 © 2012 Joseph F Iaquinto, PE."— Presentation transcript:

1 1 May 14, 2012 The Conceptual Design Featuring The Concept Of Operations A Tutorial By Joseph F Iaquinto, PE May 14, 2012 © 2012 Joseph F Iaquinto, PE

2 2 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction

3 3 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Some Definitions Concept An abstract or generic idea generalized from particular instances Concept An abstract or generic idea generalized from particular instances Design To create, fashion, execute, or construct according to plan Design To create, fashion, execute, or construct according to plan Conceptual Design An abstract construction plan selected and refined to satisfy a specific need that is a member of a generalized class of needs Conceptual Design An abstract construction plan selected and refined to satisfy a specific need that is a member of a generalized class of needs

4 4 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Conceptual design as a u seful abstraction Useful to customer in directing the construction of the artifact Useful to tradesmen for making detailed implementation decisions

5 5 May 14, 2012 © 2012 Joseph F Iaquinto, PE Overview of CONOPS Templates Essential template CONOPS Scope: Identification System Overview Document Overview Scope: Identification System Overview Document Overview Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Documents: Referenced Documents: Referenced Operational Scenarios: Key business events Anomalies accounted for Selected representative Operational Scenarios: Key business events Anomalies accounted for Selected representative System Concepts: Intention (Intended use) RolesActivities DocsRelationships System Concepts: Intention (Intended use) RolesActivities DocsRelationships Operational Capabilities: Structure Behaviors Functions within Behaviors Operational Capabilities: Structure Behaviors Functions within Behaviors

6 6 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction CONOPS – The Key Concepts Mission or Intention Activities Information Required Roles Operational Capabilities Relationships

7 7 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Elementary Example – System Definition

8 8 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Conceptual Engineering Principles Intended “business” use Critical Thinking –Seek the Problem –Postulate an Applicable Solution Stated In Social Terms, Not Technical! Maintain Conceptual Integrity –Management of Domain Complexity –Management of problem solving teams

9 9 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Conceptual Engineering Fallacies Architecture as Implementation OO vs. Procedural vs. SOA Systemantics

10 10 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for doing the conceptual design (CONOPS) Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

11 11 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Example: Web Provisioning Specification Status Product

12 12 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Not limited to IT systems!

13 13 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Tutorial Sessions Introduction 1.What is a Conceptual Design and Who Cares? 2.Principles and fallacies of conceptual design 3.Process for defining a CONOPS 4.Example Walkthrough 5.Toy CONOPS (Homework)

14 14 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction Ground Rules Each Session –50 Minute formal lecture –10 Minute break every hour

15 15 May 14, 2012 © 2012 Joseph F Iaquinto, PE Session 1 What is a conceptual design and who cares?

16 16 May 14, 2012 © 2012 Joseph F Iaquinto, PE What is a conceptual design and who cares? Avoiding Brook’s “law”: “All major mistakes are made on the first day of the project”! Fred Brooks, The Mythical Man Month, ISBN:

17 17 May 14, 2012 © 2012 Joseph F Iaquinto, PE Topics of Session 1 What is a conceptual design and who cares? Motivation – When is a CONOPS needed??? The Role of Conceptual Integrity (A Central One) Definition of Conceptual Design Recipe for a conceptual design –Mission or Intention –The Roles –Activities (Described by representative scenarios) –Information Introduction to some useful standards and templates Where the conceptual design fits into the System Engineering Process

18 18 May 14, 2012 © 2012 Joseph F Iaquinto, PE Motivation – When is a CONOPS needed We have a problem

19 19 May 14, 2012 © 2012 Joseph F Iaquinto, PE Motivation – When is a CONOPS needed This problem has become visible

20 20 May 14, 2012 © 2012 Joseph F Iaquinto, PE Motivation – When is a CONOPS needed – Test 1 Is there ambiguity?

21 21 May 14, 2012 © 2012 Joseph F Iaquinto, PE Motivation – When is a CONOPS needed – Test 2 Will the product serve diverse needs? I want to start my 5 HP Engine with the push of a button. While camping, I want to be able to read all night by the illumination of a 60 watt bulb. Voltage = 12 V Capacity = 40 AH Form Factor = 10x10x10 cm Voltage = 12 V Capacity = 40 AH Form Factor = 10x5x2 cm Chemistry? Internal Construction? Recharge CONOPS? SE: Battery Engineer:

22 22 May 14, 2012 © 2012 Joseph F Iaquinto, PE Motivation – When is a CONOPS needed– Test 3 Is there more than one developer / user? Initiate Conceptual Integrity –“I will contend that conceptual integrity is the most important consideration in system design”.. Fred Brooks Begins with a conceptual model. A conceptual model is the most abstract description of how the business / mission tasks are conducted when the system is available.

23 23 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Role of Conceptual Integrity Establish Discipline Conceptual Integrity is the enforcement of a single conceptual model and the absolute compliance with that model by all development personnel.

24 24 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Role of Conceptual Integrity Establish The Goal The conceptual model is the reference / touchstone that is used to coordinate all technical and political activity on the project.

25 25 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Role of Conceptual Integrity Create Coordination Requires a single mind that conceives, communicates, adjudicates and enforces the fundamental technical and political approach to solving the operational problem

26 26 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Role of Conceptual Integrity Leverage Expertise The conceptual model cannot survive group consensus. It requires a competent boss who has: appropriate experience demonstrated good judgment the courage to be held accountable for the entire project’s success the authority to fire anyone who refuses to comply

27 27 May 14, 2012 The Role of Conceptual Integrity Example of Conceptual Integrity - Software © 2012 Joseph F Iaquinto, PE Make Tracking Sheet with color code I will make color code in column E dependent on value in column B I don’t like the ordering of the columns. I will move them into a more logical order. Jack Joe Amanda Rick

28 28 May 14, 2012 The Role of Conceptual Integrity Example of Conceptual Integrity - Hardware © 2012 Joseph F Iaquinto, PE Blowback design ok if: 1.Use stick powder 2.Clean Frequently Need to be cheap(?): 1.Use ball powder 2.Never needs cleaning

29 29 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design From some CONOPS standards A user-oriented document that describes a system’s operational characteristics from the end user’s viewpoint. Synonym: operational concept description (OCD)…IEEE The Operational Concept Description (OCD) describes a proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used. The OCD is used to obtain consensus among the acquirer, developer, support, and user agencies on the operational concept of a proposed system. Depending on its use, an OCD may focus on communicating the user’s needs to the developer or the developer’s ideas to the user and other interested parties. The term “system” may be interpreted to apply to a portion of a system…MIL-STD-498, DID (CANCELED!) NOT Joint Operation Concepts / Joint Operating Concepts of CJCSI C a procurement document

30 30 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design Some excellent references Johnson & Henderson in “Conceptual Models: Begin by Designing What to Design”, Interactions, January + February 2002 Frederick J Brooks, “The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition”, Addison-Wesley Press, ISBN

31 31 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design Foundation for Artifacts CONOPS Architecture System Requirements Specifications Conceptual Design

32 32 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design Fundamental Principles of Conceptual Design High level description of the proposed business / mission process Forms the basis of how the roles or users conceive of the system –Task domain metaphors and analogies –Task domain activities that users execute –Task domain information users create and manipulate –Activities users can perform Exposes the relationships between the Concepts Illuminates the mappings between the Concepts and the task- domain the system is designed to support Interpretation of: Johnson & Henderson in “Conceptual Models: Begin by Designing What to Design, Interactions, January + February 2002

33 33 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design Fundamentals: Example of a metaphor A purposeful cross domain mapping Can be used to set the conceptual goal or purpose of the system (Mapping: farm (inexpensive (of reliable but inconsistent conformation), frisky workhorse) -> machinery (automobile))

34 34 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design Fundamentals: Example of a Mapping Movement Visit Grandma Grocery shop Go to work

35 35 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design Fundamentals: Example of Relationships To move, the system must be started To start the system, the system must be occupied Movement and Stop are mutually exclusive (These examples are Business Rules)

36 36 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design Fundamentals: User Activities To occupy, the system must support mount and dismount To start means to turn it on or off Movement means to control stopping and going Movement means to control direction

37 37 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design The Operational Viewpoint Expression of the Conceptual Design requires a Viewpoint Technical Viewpoint (how to do it) Political Viewpoint (law, sociology…) Operational Viewpoint (What does it do) Financial Viewpoint (funding, ROIC…) Concept of Production Concept of Deployment Concept of Operations (ConOps) Concept of Support Concept of Disposal IEEE 1471 INCOSE SE Handbook

38 38 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition Of Conceptual Design The Operational Viewpoint By Convention use the Operational Viewpoint Show business or mission context Emphasizes rational for development Places people in context Very suggestive of what the technology must do

39 39 May 14, 2012 © 2012 Joseph F Iaquinto, PE Definition of Conceptual Design The CONOPS The Operational View of the conceptual design is called the “Concept of Operations” or “CONOPS” When documented, it is sometimes called the “Operational Concepts Document” or “OCD”

40 40 May 14, 2012 © 2012 Joseph F Iaquinto, PE Recipe for a CONOPS – The Key Concepts Mission or Intention Activities Information Required Roles Operational Capabilities Relationships

41 41 May 14, 2012 © 2012 Joseph F Iaquinto, PE Recipe for a CONOPS Mission or Intent Client’s goals for the system Why would a person use the system? What are the “Business” processes that the system supports Innate (problem invariant) vs. artifacts of technology How will system earn a profit (why build it?)

42 42 May 14, 2012 © 2012 Joseph F Iaquinto, PE Recipe for a CONOPS The Roles Users Client People who support the system People who are affected by the system

43 43 May 14, 2012 © 2012 Joseph F Iaquinto, PE Recipe for a CONOPS Information Required Analogies Information ( Documents/Forms )

44 44 May 14, 2012 © 2012 Joseph F Iaquinto, PE Recipe for a CONOPS Activities / Scenarios (system engineering, not OOA) Prose not “Geek Speak” Very abstract (conceptual) – BRIEF! Science fiction story Sequential or concurrent As “seen” by the users Where does it “fit” in the business (process)

45 45 May 14, 2012 © 2012 Joseph F Iaquinto, PE Recipe for a CONOPS Deriving the Operational Capabilities + + Intention Role Activities Capabilities

46 46 May 14, 2012 © 2012 Joseph F Iaquinto, PE Receipt for a CONOPS Operational Requirements / Capabilities Abstract / Conceptual Derived from the activities / scenarios In problem / usage (Business / Mission) domain terms If number of them justifies, categorize them (temporally) Generally reactive to business / mission events

47 47 May 14, 2012 © 2012 Joseph F Iaquinto, PE Aside: Engineering Design Process Applies To CONOPS The difference is only a matter of level of abstraction Reformulate to match design heuristics Define the problem Associate, Associate, Associate Sub- problems with known solutions Synthesize the overall solution Refine the solution (test & rebuild) Monitor the solution in full operations Update design heuristics / known solutions

48 48 May 14, 2012 © 2012 Joseph F Iaquinto, PE Introduction to Useful Standards and Templates ANSI / AIAA G –Guide for the Preparation of Operational Concept Documents IEEE P1362 –IEEE Guide for Information Technology-System Definition- Concept of Operations (ConOps) Document MIL-STD-498 / DI-IPSC –Operational Concept Descriptions SPC MC –Operational Concept Document Template NASA-DID-P100 –Concept Data Item Description

49 49 May 14, 2012 © 2012 Joseph F Iaquinto, PE Where Conceptual Design Fits Into System Engineering Process CONOPS System Requirements System Architecture Capabilities Components & Relationships

50 50 May 14, 2012 © 2012 Joseph F Iaquinto, PE Where Conceptual Design Fits Into System Architecture Process (DODAF) Operational Concept Graphic Operational Node Connectivity Diagram Operational Information Exchange Matrix CONOPS

51 51 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Conceptual Design More on mapping CONOPS to DODAF Components Missions / Intentions (OV-1) Roles (OV-4!!) –Skills –Where (Nodes) Needed Information (OV-3 / OV-7?) –Performance Activities (OV-5, SvcV-4) –Performance Relationships Mission to Role (OV-5) Mission to Activity (OV-6) Role to Node (OV-5) Role to Information (OV-2) Role to Role (OV-4) Role to Activity (OV-5) Mapping requires judgment and skill

52 52 May 14, 2012 © 2012 Joseph F Iaquinto, PE Session 2 Principles and Fallacies of Conceptual Design

53 53 May 14, 2012 © 2012 Joseph F Iaquinto, PE Topics of Session 2 Principles and fallacies of conceptual design The Conceptual Problem Think “User Viewpoint” Think Critically Selecting Perspectives (Views) From the Tar Pit: Fred Brooks Common Conceptual Design Fallacies Big Failure Modes - Systemantics

54 54 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Conceptual Problem – A Checklist How do we discover the mission or intent? What roles are required to achieve the intent? What information is needed to achieve the intent? Where are the roles located? What activities do the roles need to perform in order to achieve the intent? What are the important relationships (e.g. role to information)? How can I capitalize upon experience (associate this system with past solutions)?

55 55 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think “User Viewpoint” Intended Use Centric Capture manner of customer’s circumstance –Language –Intentions –Historical Perspective Magellan 750

56 56 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think “User Viewpoint” Establish Foundation Acquire “Domain” (User) Knowledge Acquire “Domain” (User) Experience Judgment

57 57 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think “User Viewpoint” Conceptualize in Customer’s Language Understand the metaphors Understand the technical artifacts Discover the innate principles and activities Look for archetypical concepts (the only basis for reuse)

58 58 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think “User Viewpoint” Conceptualize in Customer’s Language Parts List NOT Aggregation! Kinds of Parts NOT Generalization / Specialization Interconnection NOT Association

59 59 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think “User Viewpoint” A Counter Example – As found System Concepts Enterprise Management System Assurance Dynamic Collaboration Dynamic Resource Allocation Provide Worldwide Access Provide Services “Network” With Co-workers Private Conversations Knowing What is Happening

60 60 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think “User Viewpoint” A Counter Example – The reality System Concepts Enterprise Management System Assurance Dynamic Collaboration Dynamic Resource Allocation Provide Worldwide Access Provide Services “Network” With Co-workers Private Conversations Knowing What is Happening

61 61 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think “User Viewpoint” Be Aware of Implementation Possibilities The operator will have complete control over the direction in which the vehicle moves.

62 62 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think “User Viewpoint” A Most Important Architectural Artifact User Interface (example: screen shot) is important part of Conceptual Design and a legitimate architectural artifact!

63 63 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically – Foundation for Problem / Solutions Basic Principles Clarity Precision Accuracy Relevance Consistency Logical Correctness Completeness Fairness My Favorite Barrier: –Wishful Thinking

64 64 May 14, 2012 Think Critically Be Argumentative © 2012 Joseph F Iaquinto, PE ControversyResolution Issue Claim EvidenceClaim Warrant Inference

65 65 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Be Argumentative COBOL is totally obsolete; thus, we need to code in JAVA We cannot find college trained COBOL programmers; thus, we need to code in JAVA. Where is the Issue: Where is the Evidence (Rationale):

66 66 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Be Argumentative – Another Checklist Is there an issue? Is the issue important (or important enough) and relevant? Is there a rationale? Does the rationale support the conclusion? Is the rationale (hence the conclusion) related to the issue? Does the conclusion indeed resolve the issue?

67 67 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Beware of Conditional Statements If you abstract applications away from the underlying hardware, then resources can be used more efficiently. If you have reusable software services, then you can simplify the development of custom applications, allowing IT to avoid writing code unnecessarily. These are NOT syllogisms!

68 68 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Consider All Relevant Dimensions Reusable Services Understand What They Do Understand How They Work Use Rather Than Code Test Them Or Trust Them? Restrictive Association (to services) Understanding Prototypes Component Change Impact

69 69 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Use of the Scientific Method

70 70 May 14, 2012 © 2012 Joseph F Iaquinto, PE Use of the Scientific Method The Body of Knowledge Established by the Scientific Method Approximate due to limitations of the Scientific Method Useful for Conceptual Designs Beware of: –It an approximation only –It evolves with time –New systems can change the knowledge

71 71 May 14, 2012 © 2012 Joseph F Iaquinto, PE Use of the Scientific Method The Method Problem Hypothesis (Guess) Controlled Experiment –Notion of exactly 1 Dependent and exactly 1 Independent Variable!!!!! –Control (Independent Variable Value) Is Mandatory!

72 72 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Use of the Scientific Method - Fallacy Test Article Control Fertilizer Work?Hole in Ozone Layer? Test Article Control???

73 73 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Usefulness of the Scientific Method Control on left or Right?Associate Orders or Not? Form for Order Entry Function 1 Function 2 Go Pizza Order Soda Order 1 m

74 74 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically The Process of Problem Solving Identify The Cause Identify The Problem Identify & Remove Barriers Gather Information Generate Solutions Select Solution Evaluate Solution Courage to Evolve Solution Genesis of the CONOPS

75 75 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Detect Fallacies – Fallacies of Relevance Personal attack Attacking the motive (turf battle!) Look who’s talking Two wrongs make a right Appeal to force Appeal to pity Bandwagon argument Straw man (striking beside the issue) Red herring Equivocation (I did not have sex with that woman!) Begging the question

76 76 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Detect Fallacies – Insufficient Evidence Inappropriate appeal to authority Appeal to ignorance False alternatives (often result from lack of technical expertise) Loaded question Questionable cause Hasty generalization Slippery slope Weak analogy Inconsistency

77 77 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Understand the use of language Vital to understanding domain and assessing arguments Avoid misunderstanding with precise language –Illustrations –Use dictionary definitions, not jargon Emotive language –Used to slant the truth Avoid euphemisms and political correctness

78 78 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Understand Prejudices Inherent in Customer Setup artillery after Move takes 1 hour Innate problem: Precisely determine location Artifact: Engineers have to survey the new location Conclusion: Artifact of technology causes prejudice

79 79 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Understand “Common” Beliefs in Customer Domain Identifying common beliefs –Artifacts of technology –Artifacts of history –Artifacts of personality

80 80 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Understand “Common” Beliefs in Customer Domain Artifacts of technology –Process Technical constraint vs. innate Productivity limitation –Documents Communications (between departments) Continuity of operations –Limitations Insufficient productivity Insufficient communications

81 81 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Understand “Common” Beliefs in Customer Domain Artifacts of history –Law Process to accommodate prior laws Documents required by prior laws Limitations inherited from prior laws –Culture Process dictated by religion or “pecking” order Documents dictated by philosophy Limitations dictated by social relationships (DOD)

82 82 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Understand “Common” Beliefs in Customer Domain Artifacts of personality –Founders Process defined by founder –Shift into reverse while moving forward Documents defined by founder Limitations of founder’s imagination –Key management personnel Similar to founders

83 83 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Understand Emotional Influences In Customer System Engineer User Fear of job loss Fear of prestige loss Fear of failure Angry at being forced… Genuine concern

84 84 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Avoid Overgeneralizations An airport inspector failed to confiscate a knife -> we have to replace all airport inspectors with personnel with clearances Schools don’t teach COBOL -> we have to replace all COBOL programs with JAVA programs A person drove onto a school playground killing 5 students --> we must ban all private ownership of automobiles We pay too much for sending EDI messages -> we must re- build our IT infrastructure upon Web Services

85 85 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Avoid Selective Abstraction If the Intel Community shared data, 9/11 would never have happened Mainframes cost too much to buy; therefore, we need to switch all of our applications to Unix servers. We don’t understand each other’s architectural artifacts; therefore, we need to define a DODAF We don’t understand each other’s data; therefore, we all need to use the same data model

86 86 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Exploit Natural Orders To Organize Analysis Ordering is central to Conceptual Design Topical Order –Order of place –Central to structural / static modeling Analogical Order –Similarity and metaphorical ordering –Central activity of Engineering Chronological Order –Time or sequence –Central to behavioral modeling Causal Order –Reasons or cause and effect –Important theme of behavioral modeling

87 87 May 14, 2012 © 2012 Joseph F Iaquinto, PE Think Critically Employ Inductive and Deductive Reasoning Deductive Thinking From the general to the specific Syllogism : premise (reason) and a conclusion that follows Most natural, everyone is capable of this kind of thinking Inductive Thinking From the specific to the general Analogical argument: a specific similarity implies general similarity Very hard to do, requires a mutant –The principle fallacy of the OO method, Ontologism…

88 88 May 14, 2012 © 2012 Joseph F Iaquinto, PE Selecting Perspective (Views) Useful Concepts See IEEE Recommended Practice for Architectural Description of Software Intensive Systems DODAF product is one representation of a VIEW A View is a representation of a whole system from the perspective of a related set of concerns. –Usually a model –Has a very specific purpose A Viewpoint is a specification for constructing and using a view. A concern is a stakeholder’s intent in acquiring the system

89 89 May 14, 2012 © 2012 Joseph F Iaquinto, PE Selecting Perspectives (Views) Basic Concepts of “Perspective” StakerholderConcernViewpoint Views Products / Model Has a Is addressed by Represented by specific Rendered / addressed by specific Bottom line: products are arguments!

90 90 May 14, 2012 © 2012 Joseph F Iaquinto, PE Selecting Perspectives (Views) First Rule: Keep Views Very Simple – Bad Example

91 91 May 14, 2012 © 2012 Joseph F Iaquinto, PE Selecting Perspectives (Views) First Rule: Keep Views Very Simple–Better Example JFMCCJFACC CSG Air Related OrganizationsNon Air Related Organizations Carrier Strike Group Organizations Operational Command / Control Tactical Control OV-4 Naval Command Structure

92 92 May 14, 2012 © 2012 Joseph F Iaquinto, PE From the Tar Pit: Fred Brooks Basic Concepts The Mythical Man Month Conceptual Integrity The Surgical Team Aristocracy, Democracy, and System Design C.R.Knight, Mural of La Brea Tar Pits

93 93 May 14, 2012 © 2012 Joseph F Iaquinto, PE From the Tar Pit: Fred Brooks The Mythical Man Month The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth Adding manpower to a late software project make it later Training Cost + Interaction Cost Break up the conceptual design effort into parallel teams a BAD IDEA Operational (Views) System (View)

94 94 May 14, 2012 © 2012 Joseph F Iaquinto, PE From the Tar Pit: Fred Brooks Conceptual Integrity Single most important reason for failure of CONOPS Conceptual design MUST proceed from one mind, or a very small number of agreeing resonant minds –IPTs as advisors, not consenters –Teams as amplifiers, not consenters Every part must reflect the same philosophies Every part must have the same balancing of desiderata Every part must use the same techniques in syntax and analogous notions in semantics Unity of design

95 95 May 14, 2012 © 2012 Joseph F Iaquinto, PE From the Tar Pit: Fred Brooks The Surgical Team Architect Engineering Co-Architect Administrator Tech Pubs Tool Maker QA / Test Domain Expert Maintain Conceptual Integrity Multiply Effectiveness of “Hero” Scales Sufficiently for Conceptual Designs

96 96 May 14, 2012 © 2012 Joseph F Iaquinto, PE From the Tar Pit: Fred Brooks Aristocracy versus Democracy Conceptual integrity is the most important consideration in conceptual design. Conceptual integrity demands that someone control the concepts. Aristocracy needs no apology. Discipline is good for art. Conceptually integrated systems are faster to build and to test. Separate conceptual design from implementation to assure conceptual integrity on large projects. Democracy in conceptual design? Read Homer’s “The Odyssey”.

97 97 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Typical Misuses Of Technical Concepts Zachman / Architecture As Implementation Lack of Focus In Illustrations (keep drawing simple and to the point) OO Versus Procedural Versus SOA… Use of UML Cartoons Ontology Reuse

98 98 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Zachman – “Drowning projects in bubbles and boxes” Zachman's Definition of Architecture: A set of design artifacts, or descriptive representations, that are related for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change). “A Practical Guide to Federal Enterprise Architecture”, Chief Information Officer Council, GAO, February 2001

99 99 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Zachman – “Drowning projects in bubbles and boxes” 36 Categories of information Planner / owner level all that is applicable Too distracting

100 100 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Instead of Zachman – KEEP IT SIMPLE Conceptual Design IntentionInformationActivitiesRoles The Business ProfitDocumentsWorkflowPersonnel The Automation RationaleDataCapabilitiesUsers/Actors

101 101 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Lack of Focus In Illustrations JFMCCJFACC CSG Air Related OrganizationsNon Air Related Organizations Carrier Strike Group Organizations Operational Command / Control Tactical Control OV-4 Naval Command Structure What is the point? Dual Command of Air Related Operations Clear Focus On Interoperability Requirement / Challenge

102 102 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies OO Versus Procedural Versus SOA… Architecture is concerned with user interface Conceptual Design is concerned with the user’s cognitive view of his business and automation’s role in it. OO / Procedural / SOA are software design methods OO / SOA is about relating groups of executables Procedural is about characterizing a single executable Orthogonal

103 103 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Use of UML Cartoons UML seduces SE into too much detail UML seduces SE into jargon to make the user feel stupid Software IS NOT Systems

104 104 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Use of UML Cartoons - Aggregation Part is contained in whole Concept of whole is embodied in real code Parts are real, whole has no separate existence Concept of whole has no real manifestation Further Information: INCOSE Insight, Volume 7, Issue 2, July 2012, Semantic Dictionary and Concept Model, Michael Dickerson, David Oliver and Joseph Skipper Concept of Aggregation is confusing to User / Owner VS

105 105 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Use of UML Cartoons - Generalization Classes have attributes (data) and methods (executable code) Notion of Inheritance means copy attributes and methods = shared data and code Real physical things have properties that result from their unique construction / composition Kind of does not mean inheritance. A real thing’s structure and behavior could be a result of significantly different design than a thing it is a kind of (airplane vs. car for example). Further Information: INCOSE Insight, Volume 7, Issue 2, July 2012, Semantic Dictionary and Concept Model, Michael Dickerson, David Oliver and Joseph Skipper Concept of Generalization is also confusing to User / Owner VS

106 106 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Ontology – Another Confusing Concept StakerholderConcernViewpoint Views Products / Model Has a Is addressed by Represented by specific Rendered / addressed by specific Structured, language-independent network of concepts for a Particular domain and / or its subset Uses to evaluate CONOPS

107 107 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Ontology – Another Confusing Concept Arcane way to define user interface and behavior Another fancy word to make users feel stupid Systems don’t do semantics, they can only poorly simulate semantics Concentrate on the users’ operational model of the problem domain and related metaphors Understand the user’s operational model Architecture should match this operational model The user, not the system, brings meaning to the system

108 108 May 14, 2012 © 2012 Joseph F Iaquinto, PE Common Conceptual Design Fallacies Reuse – Is It Worth The Expense? The Reality of Reuse Reuse is more expensive –Using = understanding complexity –Making = building generality Can you trust a reused concept? Reuse requires extensive study, fixing misunderstanding Reuse should be large scale only: JTF, GIG… Otherwise too costly. Yes, conceptual design should include development system implications. Line by line is no longer necessary The Hype of Reuse Reuse is cheaper Reuse reduces testing Reuse is easier than building your own Reuse can be: –Fine grained –Medium grained –Large scale Reuse is consistent with line by line coding

109 109 May 14, 2012 © 2012 Joseph F Iaquinto, PE Big Failure Modes – Systemantics Defined Motivation Recognize when a problem is a manifestation of the incumbent system and not innate How to do no harm – Oh Yea? Thought provoker when doing system level FMEAs Do not panic, its all a joke Systemantics, The Underground Text of System Lore, How Systems Really Work and How They Fail, John Gall, ISBN: or –1-1

110 110 May 14, 2012 © 2012 Joseph F Iaquinto, PE Big Failure Modes – Systemantics New Systems Mean New Problems New system means a new entity to be dealt with –Maintenance –Energy supply… Existing systems feel the impact and require different attention System of systems: what if our trading partner sends us bad data?

111 111 May 14, 2012 © 2012 Joseph F Iaquinto, PE Big Failure Modes – Systemantics Systems Tend to Expand to Fill the Known Universe All engineers are optimists; thus, they underestimate the concept If a system is useful, it must be “enhanced” to add forgotten and new capability Systems expand and encroach (IRS example) Once institutionalized it is hard to terminate a system

112 112 May 14, 2012 © 2012 Joseph F Iaquinto, PE Big Failure Modes – Systemantics Complex Systems Exhibit Unexpected Behavior Systems display antics This effect is compounded by multiple “designers” and “users” Unexpected ways to fail (Unintended consequence) Unexpected ways to operate (functions not designed in but require maintenance and extension)

113 113 May 14, 2012 © 2012 Joseph F Iaquinto, PE Big Failure Modes – Systemantics Systems’ Do Not Naturally Scale A Large System, Produced by Expanding The Dimensions of a Smaller System, Does Not behave Like the Smaller System Adding more system resources to overcome performance problems frequently makes problem worst Hardware is cheap is a major trap to the unwary engineer

114 114 May 14, 2012 Big Failure Modes – Systemantics Countering them with FMEAs © 2012 Joseph F Iaquinto, PE

115 115 May 14, 2012 © 2012 Joseph F Iaquinto, PE Session 3 A Process for Defining a CONOPS

116 116 May 14, 2012 Topics of Session 3 The Process for Defining A CONOPS Develop the Basic Concepts Define the Problem Define the Roles and Responsibilities Define the Business Events Define the Representative Scenarios Define the Operational Capabilities Verify and Validate CONOPS Document CONOPS Some Useful Heuristics © 2012 Joseph F Iaquinto, PE

117 117 May 14, 2012 Develop Basic Concepts Relationships of Fundamental CONOPS Concepts © 2012 Joseph F Iaquinto, PE Intention Activities (Scenarios) System Under Definition Roles Information Operational Capabilities Causes Facilitated By Executed By Utilize Used By Provides Business Problem Leads to

118 118 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

119 119 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define The Problem In Business Terms The Single Most Important Concept

120 120 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

121 121 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define The Roles and Responsibilities How is the business organized? What are the roles that categorized what the people do? What are the business activities executed by the people? What skills are implicit (or explicit) for each role

122 122 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define The Roles and Responsibilities What is the relationship between the tasks and the activities? What is the World View / Concepts of the business and how the system works from the viewpoint of each role? What are the relationships among roles and locations?

123 123 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define The Roles and Responsibilities Beware of what people tell you!

124 124 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

125 125 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define The “Business Event” Business Events Are Central to Creating A CONOPS

126 126 May 14, 2012 Define the “Business Events” Exploitation of Business Events and the CONOPS © 2012 Joseph F Iaquinto, PE People live in the business world and respond to business events, not the technical world Business events being the initiator of business processes can serve as a conceptual anchor Business events require an understanding of the intention of the business before the business reaction can be understood Business events are the wellspring of the concepts needed for the conceptual design

127 127 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Events” Definition What are the business events –Identify the business transactions –Look for transaction “initiators” –Remember to include all “exceptions” –Induce “representative” transactions –Understand the importance of the transactions in running the business

128 128 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Events” Use Business Language to Name Events How are they conceptualized by the business execution folks –Language Nomenclature Metaphors –Relationship to division of labor –Relationship to information –Relationship to location

129 129 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Events” Understanding How Business Reacts to Events Discover the artifact driven reactions –Interviews (caution) –“Time and Motion Studies” i.e., observation –Benchmark (study competitors) –Read the literature

130 130 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Events” Understanding How Business Reacts to Events Discover the innate reactions –Analysis (Critical Thinking) of artifact driven reactions –Inductive reasoning based on Benchmarks –Interview domain experts –Historical analysis (how was it done in the past)

131 131 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Events” Examples A business event is something that happens in life that forces the business to respond (stimulus / response) –Wind tears a house’s siding off –A UFO enters protected airspace –A grocery shopper arrives at the checkout station with a basket of groceries –The F16 will not start –A teenager arrives at the DMV counter seeking a driver’s permit

132 132 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Events” Relationship of Business Events to Roles & Information People live in the business world and respond to business events, not the technical world –The business events and business responses are people’s areas of expertise –The business events and business responses tend to be innate (NOT ALWAYS) –The people who respond to the business event define the CONOPS “roles” –The information used by the people who respond to business events define the CONOPS “information”

133 133 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Events” Business Event ≠ Technical (system) event – Example 1 A customer goes to the bank to withdraw money ≠ A customer inserts their ATM card into the ATM card reader

134 134 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Event” Business event ≠ Technical (system) event – Example 2 A dangerous vessel of unknown intention comes too close to a protected ship ≠ A significant sonar signature occurs on a protected ship

135 135 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Event” The Description Change Business Tempo New Information Demand A Response AbstractBusiness speak

136 136 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the “Business Event” Potential sources of business events External –Customers –Government –Trading Partners –Advisories Internal –Use this category carefully (1000 person company rule) –Analyze decision making results Temporal –Usually derivable from an External Source –Business cycle (end of period accounting) –Technical cycle (machinery / production / …)

137 137 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

138 138 May 14, 2012 © 2012 Joseph F Iaquinto, PE Representative scenarios are carefully selected to represent the “important” activities of the business Scenarios frame the problem or issue being addressed by the development effort Scenarios permit us to explore alternative “futures / solutions” Scenarios are conceptual -> can be used to challenge currently held concepts Scenarios draw the “stakeholders” into both the problem definition and the proposed solution Define Representative Scenarios Purpose of scenarios

139 139 May 14, 2012 © 2012 Joseph F Iaquinto, PE Problem: Select scenarios that permit the identification of all of the operational capabilities of the system. Define the Representative Scenarios Problem of defining scenarios

140 140 May 14, 2012 © 2012 Joseph F Iaquinto, PE Solution: Define a scenario for each Business Event. When sequences of Business Events are important, include in the definition of the scenario the accommodation of these sequences. Remember rainy day business events and sequences of business events Insure all roles, activities and information elements of the CONOPS are addressed Define the Representative Scenarios The solution to defining scenarios

141 141 May 14, 2012 © 2012 Joseph F Iaquinto, PE Tightly woven story based upon the interaction of a few critical operational concepts Tool to allows business domain experts to express / envision how the business will change as a result of the system’s existence Tool to allow business “roles” to rehearse their jobs in the proposed future (while it is still very malleable) Define the Representative Scenario Characteristics of a good scenario

142 142 May 14, 2012 © 2012 Joseph F Iaquinto, PE A conceptual scenario is NOT a software (UML) scenario or use case! Different Motivation Different Level Of Abstraction Different Viewpoint Define the Representative Scenario Scenario warning – Repeated!

143 143 May 14, 2012 © 2012 Joseph F Iaquinto, PE Write a story in English prose –Avoid technical jargon –Use business jargon –Avoid technical specification - ese Write the story about the business, but highlight the execution of the business –Keep the owner’s perspective –Describe the business tasks, roles and responsibilities –Provide necessary background information Keep your discussion of the system abstract and in business execution and profitability terms Don’t forget the rainy day aspects of the scenario Sell, sell, sell! Define the Representative Scenarios Scenario writing rules

144 144 May 14, 2012 © 2012 Joseph F Iaquinto, PE Automotive Radio System The modern automotive driver has a challenging workload. Usually faced with heavy traffic, the driver has to be alert to many threats and continuously deal with them. When navigating to a new location, the driver has the additional task of identifying waypoints and taking appropriate action at each. The operation of the vehicle’s entertainment system compounds this workload problem. Each year, thousands of deaths and injuries together with millions of dollars in property damage is directly attributable to the consequence of this workload on the driver. To address this situation, an entertainment system remote control system is proposed. While operating the vehicle the driver can make mode selections, station selections, volume adjustments, and quality of sound adjustments without removing his hands from the vehicle’s controls or his eyes from the road. In addition, these entertainment operations will require no more than a single hand or finger motion for each adjustment. This system is not intended for a deaf driver or one who suffers from numbness of the fingers or hands. Define the Representative Scenarios Scenario example

145 145 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

146 146 May 14, 2012 © 2012 Joseph F Iaquinto, PE Scenario Behavioral Requirements Functional Requirements Functional Requirements Functional Requirements Constraint Requirements Define the Operational Capabilities Operational Capabilities Flow From Scenarios

147 147 May 14, 2012 © 2012 Joseph F Iaquinto, PE Structures FunctionsBehaviors Define the Operational Capabilities A Three View Model of Operational Capabilities

148 148 May 14, 2012 © 2012 Joseph F Iaquinto, PE Where are activities “physically implemented? What does it do? When and how does it perform its function? Define the Operational Capabilities Definition of the three views

149 149 May 14, 2012 © 2012 Joseph F Iaquinto, PE Frequently (and incorrectly) considered the “Architecture” Generally presented as annotated (noun phrase) block diagrams From business viewpoint –Engineering Planning Department vs. Map Server –Accounts Payable vs. Oracle Server Express structure only to define or explain basic concepts Where activities are physically implemented Define the Operational Capabilities Operational Capability Structure View Guidelines

150 150 May 14, 2012 © 2012 Joseph F Iaquinto, PE Generally presented as descriptive or prescriptive verb phrases Can be supported by block diagrams to show functional relationships (usually temporal or combinatorial) From business viewpoint –Retrieve Map vs. Query Map Database –Identify customer vs. Enter Customer Query Functions are highly conceptual for a CONOPS Part of DODAF Architecture Model (OV-5, SV-4, SV-5) What does it do? Define the Operational Capabilities Operational Capability Function View Guidelines

151 151 May 14, 2012 © 2012 Joseph F Iaquinto, PE Generally presented as conditional phrases Should be supported by specialized block diagrams (state charts and state transition diagrams) From business viewpoint –When beginning an Operations Plan vs. When the Ops Plan button is pressed –When the customer asks to place an order vs. When the customer order entry from is submitted Behaviors are expressed as business concepts for a CONOPS Behaviors serve to organize functions by intended use / business event Part of DODAF Architecture Model (OV-6, SV-10) When and how does it perform its function? Define the Operational Capabilities Operational Capability Behavior View Guidelines

152 152 May 14, 2012 © 2012 Joseph F Iaquinto, PE Behaviors can have names Behaviors can associate hierarchically A named behavior is a Mode A named child or sub behavior is a State This 2 level hierarchy is sufficient for any CONOPS! Behaviors serve to organize functions by intended use / business event Define the Operational Capabilities Behavior – The Mysteries of States and Modes

153 153 May 14, 2012 © 2012 Joseph F Iaquinto, PE Command Communications System Disaster Recovery Mode Crisis Operations Mode Normal Operations Mode Attack Classification State Repel State Resource Recovery State Define the Operational Capabilities Behavior - An example of Modes and States

154 154 May 14, 2012 © 2012 Joseph F Iaquinto, PE Repel State Employ Resources Allocate Resources According to Plan Retrieve Attack Specific Operations Plans Locate Available Resources Analyze Impact Of Resource Re-Allocation Re-Assign Applicable Resources Define the Operational Capabilities An example of States and Modes - Functions

155 155 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Initial Conceptual Design Always Requires Refinement Refinements Conceptual Analysis CONOPS Some Checklists

156 156 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Basic Concepts Checklist Metaphors make sense to users Language understandable to users Users believe goals accomplished

157 157 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Representative Scenarios Checklist Correct Each scenario is acceptable to users Inappropriate artifacts eliminated Innate characteristics are consented to Complete set All Business Events Handled All Applicable Scenarios Present Users believe they can execute scenarios Users have walked through each scenario Users have confirmed proper handling of business events

158 158 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Operational Capabilities Checklist Understandable Users understand what, where and how new business process will work Users understand capabilities metaphors Correct Users understand how system works Users agree that capabilities benefit process No unacceptable unintended consequences Complete Users can accomplish intended use with these capabilities

159 159 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Checklist to insure topical coverage Emergent capabilities analysis –System capabilities stated in business terms –Analyze combinations of interconnected system capabilities (Aggregate Business Objects identified) –Analyze new capabilities and their relationship to the interconnected system capabilities (Data Transformation) –Analyze correctness of description of individual behavioral contribution to expected aggregate behavior –Insure that sufficient maintenance scenarios exist to avoid system failures that result from subsystem maintenance –Insure that sufficient legal and accounting scenarios exist –Ensure complete coverage of all aggregate capabilities

160 160 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Problem Solution Checklist 1 Compare As-Is with To-Be –Select significant business events –Select interesting anomalies Quantify process improvement and compare to goals –ROI Computations –Socio-political “profit” Popular social issues Environment Public safety

161 161 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Problem Solution Checklist 2 Provide adequate justification for process changes? –Operational Capabilities defined sufficiently to prove process improvements –Discussion of cost of Operational Capabilities as appropriate Solve the business problem –Do the Operational Capabilities still solve the business problem –Have they introduced new business problems

162 162 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Unintended Consequences Checklist Check for them with process FMEA –Define Unintended Consequences to avoid –Search top down for them –Search traditional bottom up for them –Eliminate them with process re-engineering Leverage experienced users to detect them –Solicit history of Unintended Consequences –Define severity of Unintended Consequence –Have them check your work

163 163 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Security Checklist Scenarios –Vulnerability analysis (Conceptual FMEA) –Policy conformance Operational Capabilities –Certification implications Structure Functions Behaviors –Vulnerability analysis (Design FMEA) –Incident response capabilities present and adequate

164 164 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Reliability, Availability, Safety, Maintainability Checklist Scenarios –Reliability Threads –Performance Metric Definition Business process oriented – NOT technology oriented –System level FMEAs Reliability / Availability / Maintainability –System level Safety Analysis (cousin to FMEA) Operational Capabilities –Design FMEA –Design Safety Analysis –Design Maintainability Analysis –Design Performance Analysis –Maintainability Capabilities

165 165 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Political Concept Checklist Scenarios –Clarify Roles and Responsibilities (OV-4) Understand traditional (As-Is) situation Understand required political changes –Share with all affected organizations –Respect, record and address turf / NIH / power issues Operational Capabilities –Traditional (As-Is) provisioning –Where does the information reside –Where does the structure reside –What is the profit to provision operational capabilities –What is the cost of provision operational capabilities

166 166 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS Remember that the design has been completed, your job now is to present the results to both the business and development communities Your role in this is professorial

167 167 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS Widely Accepted Templates CJCSI B Appendix A to Enclosure E DI-IPSC Operational Concepts Desc. (OCD) ANSI/AIAA G Guide to preparation of OCD IEEE Std System Definition-ConOps NASA DI-P100 Concept Data Item Description DI-MCCR Concepts of Operations Document Software Productivity Consortium SPC MC, OCD Template Tenix Defense Systems Development of Operational Concepts Descriptions

168 168 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS Crude Comparison

169 169 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS Essential template CONOPS Scope: Identification System Overview Document Overview Scope: Identification System Overview Document Overview Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Documents: Referenced Documents: Referenced Operational Scenarios: Key business events Anomalies accounted for Selected representative Operational Scenarios: Key business events Anomalies accounted for Selected representative System Concepts: Intention (Intended use) RolesActivities DocsRelationships System Concepts: Intention (Intended use) RolesActivities DocsRelationships Operational Capabilities: Structure Behaviors Functions within Behaviors Operational Capabilities: Structure Behaviors Functions within Behaviors

170 170 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS Use of UML Methods and Graphics UML, a collection of legacy graphics – BAD IDEA –UML is intended for a lower level of abstraction –UML is software centric (see Session 3) –Legacy graphics can be used with appropriate abstraction; however, too easy to be seduced into design –UML best used to flow down from CONOPS / Architecture / System Requirements Specification to implementation

171 171 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS Use DODAF Graphics DODAF is a collection of more legacy graphics – USE WITH GREAT CAUTION –Architecture is role / user “interface” –DODAF Views include implementation (Avoid SVs, TVs) –AVs can address intention, present basic concepts –OVs are usually safe OV-1 the high level operational concept graphic (Intention) OV-2 operational node connectivity (Roles and Relationships) OV-3 Information Exchange (Information / Documents) OV-4 Command Relationships Chart (Roles) OV-5 Activity Model (Activities) OV-6 Behavioral Models (Activities / Operational Capabilities) OV-7 Logical Data Model: Subvert it into information model

172 172 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS Alternatives to Paper Documents Of all requirements documents, CONOPS is most suitable to prose Automation is essential to productively employ system engineering to most projects given the cost of system engineering Storyboards and full movies are now a practical way to express CONOPS (Demo) Executable specifications provide support for verification and validation The business roles (executors) must be able to participate

173 173 May 14, 2012 © 2012 Joseph F Iaquinto, PE Some Useful Heuristics Know the business and how it earns profit Users as a integral part of the CONOPS team Beware of user inputs

174 174 May 14, 2012 © 2012 Joseph F Iaquinto, PE Some Useful Heuristics Bring order to chaos (Conceptualize!!) –Unique and important performance requirements which will shape system design –Major business concepts which will affect system design –Attitude toward initial budget and its influence on structure of system –Implications of change / growth on long range performance of system –Genius is in finding and discarding irrelevant or trivial information

175 175 May 14, 2012 © 2012 Joseph F Iaquinto, PE Some Useful Heuristics Take your time and play with the problem Don’t just think happy path Investigate alternative concepts with critical thinking Use judgment & experience to organize instead of paralyze Maintain conceptual integrity Verify and validate the CONOPS

176 176 May 14, 2012 © 2012 Joseph F Iaquinto, PE Engineering is an Associative Behavior The Role of Doctrine MIT eBusiness Process Handbook Microsoft Patterns and Practices RosettaNet EDI Collaborative Process Patterns for e-Business Look in the Literature Some Useful Heuristics

177 177 May 14, 2012 © 2012 Joseph F Iaquinto, PE Session 4 An Example Illustration of some of the elements of a conceptual design

178 178 May 14, 2012 © 2012 Joseph F Iaquinto, PE Topics For Session 4 Example The CONOPS The System Requirements Specification The Architecture

179 179 May 14, 2012 © 2012 Joseph F Iaquinto, PE An Example Web Provisioning Specification Status Product

180 180 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

181 181 May 14, 2012 © 2012 Joseph F Iaquinto, PE An Example Define the Problem A manufacturer of semi-custom goods (computers, watches, automobiles…) wishes to provide a custom order service. The customer can express their requirements for the product and receive in real time a cost and availability date. Thus, they can tailor the product to suit their needs, budget and expected delivery date. In turn, the company is an assembler of parts fabricated by other supplier companies.

182 182 May 14, 2012 © 2012 Joseph F Iaquinto, PE Intention Buy neat, affordable stuff that I have a role in ‘designing’ Make neat stuff Make money Beat the competition

183 183 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

184 184 May 14, 2012 © 2012 Joseph F Iaquinto, PE Roles Product Requestor Transaction Modeler Product Maker Component Maker Transporter

185 185 May 14, 2012 © 2012 Joseph F Iaquinto, PE Responsibilities / Activities Activities –Determine what you want - intend –Research the product options –Select the set of options desired –Check for price / availability –Order product –Assemble product –Fabricate product parts –Ship product –Bill for the product –Receive the product and insure correctness –Pay the bill –Produce research materials (quotes)

186 186 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

187 187 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the Business Events Product Requestor Request Product Options Product Research Results Provided Component Maker Request for quote for catalog item Response to request for quote for catalog item

188 188 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the Business Events: Define the Required Information Product specification form Product features form Price estimate report Shipping estimate report Available features / price report(s) Order form Invoice report Parts description form Request for quote form Parts availability report

189 189 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

190 190 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the Representative Scenarios Product Requestor researches available products and determines what they want, can afford and can wait to order Component Maker provides catalog (component specifications)to the Product Maker Product Requestor places a specific order for a product Transporter transports product to Product Requestor Product Requestor receives product Product Maker provides desired component specifications (new or changed) to the Component Maker Transaction Modeler issue invoice to the Product Requestor

191 191 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Process for defining the CONOPS Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

192 192 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define Operational Capabilities Role Product specification form Specifies Desired Information Invoice Verifies and Pays Warning: Study unusual capability rather than be completely distracted by “standard practice” ones Standard Capability Unusual Capability

193 193 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define Operational Capabilities Modes and States Product Research Mode –When Product Requestor is discovering the available product / features, costs and delivery schedule AND comparing them to their requirements as they refine these requirements Defining Needs State –When Product Requestor is formulating their needs for the product and refining these needs in response to what they find is available as product options Investigating Product Options State –When Product Requestor is interacting with the system to determine what product features are available and at what cost, delivery schedule

194 194 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define Operational Capabilities Fragment of Modes and States analysis Product Research Mode Defining Needs Investigating Product Options Evaluating Candidate Product Order Product Mode Specify Product Options Specify Shipping Options Specify Payment Options

195 195 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the Operational Capabilities Operational Functions Defining Needs State –Search: Form: request classes of products by general operational characteristics – show all 3000# jacks –Report: show class of products with salient operational characteristics organized to best suit Product Requestor –Select specific product from calls that is most suitable for the intended use of the product Investigating Product Options State –Select: Form: request list of options for the selected product, perhaps by class – show all saddle options for 3000# jacks –Report: show list of options for a particular product with cost and delivery indicators –Select specific option from the options that is most suitable for the intended use of the product

196 196 May 14, 2012 © 2012 Joseph F Iaquinto, PE Define the Operational Capabilities Business Information Defining Needs General Product Search Form General Product Availability Report General Product Inventor Including User Level Characteristics Repository of Previous Search Requests

197 197 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Political Concept Correct? Acceptable to User? Acceptable to Business? Interoperability Accomplished? Undesirable Consequences Compensated?

198 198 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Political Concept Correct? Concept avoids “curse of dimensionality” Product Maker is “middleman” or coordinator There is a political problem, can you “see” it?

199 199 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Acceptable to User? Role Acceptable?: Product Requester for Example (need address all roles) Activities Assigned to Role Acceptable? –Determine intent (requirements) –Research what is available based –Evaluate what is available and determine suitability –Place order –Pay for order Information Related to Role Understandable and Acceptable? –Product specification form –Product features available report… Business Events Related to Role Acceptable? –Product Research Result Provided (Timely, consistent with process?) Scenarios cover all those important to each Role

200 200 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Acceptable to the Business Evaluate Conceptual Design Against Intention Intention of All Roles –Product Requestor: Affordable, Available Custom Product (Minimum time / effort to complete order?) –Component and Product Makers Profitable Market Share Missions and Goals Oops – Missing Role: Government Regulators –Complies with regulations –Maximizes Tax, etc. revenue

201 201 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate Interoperability Accomplished All Business Events Identified to Permit Scenario Execution? All Information Items Identified to Permit Scenario Execution? Information Items Consistent with Individual System Capabilities? DO NOT CONSIDER TECHNICAL INTERFACE!

202 202 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate Undesirable Consequences Compensated? Price Quote = x Request Price Payment = z Price Quote = z Invoice = x + Δ Request Component Price Undesirable Consequence = lose money Compensation: New Role of “Legal Contractor” General Rule: Design Organization of Organizations Before Getting Systems or Development Engineering Involved! General Rule: Design Organization of Organizations Before Getting Systems or Development Engineering Involved!

203 203 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Let’s try the Happy Path first Customer finds features they want Customer specifies the product Customer orders the product Customer receives the product Customer pays for the product We make a profit

204 204 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Customer finds features they want – Information Check Search Results Required Information: Product specification form Product features form  Product availability / options report Repeat analysis for intention, roles, activities, relationships…

205 205 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Customer specifies the product – Role Check Specification Status Required Roles: Product Requestor Transaction Modeler Product Maker Component Maker Repeat analysis for information, intention, activities, relationships…

206 206 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS Let’s try a Rainy Day Customer finds some features Customer specifies a set of features that cannot be built Customer orders the product Customer expects receipt of the product  What do we do with this transaction??

207 207 May 14, 2012 © 2012 Joseph F Iaquinto, PE Verify and Validate CONOPS What do we do with this transaction? - Information Invalid Order Placed Assisted Order Help Required Information: Order Entry Form  Order Form Error Report  Product Specification Detailed Error Report  Product Specification Assisted Form  Online Chat Multi-Form Repeat analysis for intention, roles, activities, relationships…

208 208 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS Topics CONOPS Outline SRS Outline Architectural Artifacts –OV-1 –OV-2 –OV-3 –OV-4 –OV-5 –OV-6b –OV-7

209 209 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS CONOPS Outline Sketch CONOPS Scope: Identification System Overview Document Overview Scope: Identification System Overview Document Overview Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Documents: Referenced Reference Documents: Referenced Reference Operational Scenarios: Key business events Anomalies planned for Selected representative Operational Scenarios: Key business events Anomalies planned for Selected representative System Concepts: Intention (Intended use) RolesActivities DocsRelationships System Concepts: Intention (Intended use) RolesActivities DocsRelationships Operational Capabilities: Structure Behaviors Functions within Behaviors Operational Capabilities: Structure Behaviors Functions within Behaviors

210 210 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS CONOPS - Scope Scope: Identification Acme Custom Self-Serve Order System System Overview  Purpose –To offer customers custom products at least cost  Approach – Web to interface to customer and partners (main scenario)  Legal – contracts with partners to provide fixed firm quotes Document Overview Name each section and state its purpose Scope: Identification Acme Custom Self-Serve Order System System Overview  Purpose –To offer customers custom products at least cost  Approach – Web to interface to customer and partners (main scenario)  Legal – contracts with partners to provide fixed firm quotes Document Overview Name each section and state its purpose

211 211 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS CONOPS - Problem Description Competition moves to custom products Customers like control of what they order Offer custom products at standard product costs Do so by superior process –Reduced labor (saved pay) –Reduced order fulfillment time (saved interest) –Ease of order entry to customer –Partners more easily interact with us

212 212 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS CONOPS - Problem Description Problem Description: Current Business Situation What does the company now offer customers (Standard products from a catalog) What is the company’s competitive advantage (Low cost due to standardization) How profitable is the company (Cash cow) How does the company currently interact with partners and customers Business Problem What is the competition doing (Flexible manufacturing upgrade to plants) How does this effect our profit, R&D, and market share (Customers migrating) Goals / Objectives for Solution This is a good place to put a formal, tailored decision making process description Customer service / market share goals (Custom products at standard products price) Profit goals (Better processes to keep profits high) Reduce need for clerical labor Customer self service Partner catalog / quote function fully automated… Problem Description: Current Business Situation What does the company now offer customers (Standard products from a catalog) What is the company’s competitive advantage (Low cost due to standardization) How profitable is the company (Cash cow) How does the company currently interact with partners and customers Business Problem What is the competition doing (Flexible manufacturing upgrade to plants) How does this effect our profit, R&D, and market share (Customers migrating) Goals / Objectives for Solution This is a good place to put a formal, tailored decision making process description Customer service / market share goals (Custom products at standard products price) Profit goals (Better processes to keep profits high) Reduce need for clerical labor Customer self service Partner catalog / quote function fully automated…

213 213 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS CONOPS - References Documents: Referenced Established Industry Standards Established Industry Specific Trade Agreements Reference Architectural Process of the year Documents: Referenced Established Industry Standards Established Industry Specific Trade Agreements Reference Architectural Process of the year

214 214 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS CONOPS - System Concepts System Concepts: Intention (Intended use) Leapfrog flexible manufacturing to custom products at standard product cost Effective customer self service Effective partner self service Roles Product Requestor Transaction Modeler Etc. Activities Product Requestor Activities Determine what you want Research the product options Etc. Information (Docs) Relationships System Concepts: Intention (Intended use) Leapfrog flexible manufacturing to custom products at standard product cost Effective customer self service Effective partner self service Roles Product Requestor Transaction Modeler Etc. Activities Product Requestor Activities Determine what you want Research the product options Etc. Information (Docs) Relationships

215 215 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS CONOPS - Operational Scenarios Representative Operational Scenarios: Key business events Emergent key business events Key business events of the Customer orders product scenario Key business events of the Partner initially provides catalog of parts Etc. Selected representative Customer orders product Partner initially provides catalog of parts Partner updates catalog of parts Customer order is fulfilled Anomalies planned for Partner’s provided catalog data does not match actual part specifications (e.g. price) Customer places an invalid order (parts are incompatible) Etc. Representative Operational Scenarios: Key business events Emergent key business events Key business events of the Customer orders product scenario Key business events of the Partner initially provides catalog of parts Etc. Selected representative Customer orders product Partner initially provides catalog of parts Partner updates catalog of parts Customer order is fulfilled Anomalies planned for Partner’s provided catalog data does not match actual part specifications (e.g. price) Customer places an invalid order (parts are incompatible) Etc.

216 216 May 14, 2012 © 2012 Joseph F Iaquinto, PE Document CONOPS CONOPS - Operational Capabilities Operational Capabilities: Structure Product Requestor’s Web Browser Transaction Modeler’s Transaction Monitoring, Order Entry… System Product Maker’s CAM (Computer Aided Manufacturing) System Component Maker’s Supply Chain System Transporter’s Dispatching and Tracking System Behaviors Product Research Mode Defining Needs Investigating Product Options Evaluating Candidate Product Functions within Behaviors Defining needs Search Report… Operational Capabilities: Structure Product Requestor’s Web Browser Transaction Modeler’s Transaction Monitoring, Order Entry… System Product Maker’s CAM (Computer Aided Manufacturing) System Component Maker’s Supply Chain System Transporter’s Dispatching and Tracking System Behaviors Product Research Mode Defining Needs Investigating Product Options Evaluating Candidate Product Functions within Behaviors Defining needs Search Report…

217 217 May 14, 2012 THE SYSTEM REQUIREMENTS SPECIFICATION © 2012 Joseph F Iaquinto, PE

218 218 May 14, 2012 © 2012 Joseph F Iaquinto, PE The System Requirements Specification System Requirements Specification Outline 1. Introduction 4. System Interfaces 3. System Capabilities 2. General System Description IEEE Std 1233, 1998 Edition

219 219 May 14, 2012 © 2012 Joseph F Iaquinto, PE The System Requirements Specification SRS – Introduction 1.1 System Purpose 1.2 System Scope 1.3 Definitions, Acronyms 1.4 References 1.5 System Overview SRS Introduction Scope: Identification Acme Custom Self-Serve Order System System Overview  Purpose –To offer customers custom products at least cost  Approach – Web to interface to customer and partners (main scenario)  Legal – contracts with partners to provide fixed firm quotes Document Overview Name each section and state its purpose Scope: Identification Acme Custom Self-Serve Order System System Overview  Purpose –To offer customers custom products at least cost  Approach – Web to interface to customer and partners (main scenario)  Legal – contracts with partners to provide fixed firm quotes Document Overview Name each section and state its purpose CONOPS Scope Documents: Referenced Established Industry Standards Established Industry Specific Trade Agreements Reference Architectural Process of the year Documents: Referenced Established Industry Standards Established Industry Specific Trade Agreements Reference Architectural Process of the year CONOPS Documents

220 220 May 14, 2012 © 2012 Joseph F Iaquinto, PE The System Requirements Specification SRS – General System Description 2.1 System Context 2.2 System modes and states 2.3 Major System Capabilities 2.4 Major System Conditions 2.5 Major System Constraints 2.6 User Characteristics 2.7 Assumptions and Dependencies 2.8 Operational Scenarios SRS General Sys Desc

221 221 May 14, 2012 © 2012 Joseph F Iaquinto, PE The System Requirements Specification SRS – System Capabilities, Conditions,… 3.1 Physical 3.2 System Performance Characteristics 3.3 System Security 3.4 Information Management 3.5 System Operations 3.6 Policy and Regulation 3.7 System Life Cycle Sustainment SRS System Capabilities… Section 3.2 in particular is organized by capability

222 222 May 14, 2012 © 2012 Joseph F Iaquinto, PE The System Requirements Specification SRS – 3.2 System Performance Characteristic Defining Needs State –Search Capability The system shall tag products and parts by a general operational characteristic indicative of use The system shall store products by general operational characteristics The customer shall be presented with a search form which contains a list of available general operational characteristics from which the user can select The shall retrieve products and parts by Boolean combinations of product and part characteristics, including general operational characteristic

223 223 May 14, 2012 © 2012 Joseph F Iaquinto, PE The System Requirements Specification SRS – 3.3 System Security Defining Needs State –Search Capability The system shall retain all “sold” product and parts and their characteristics for a period of 10 years The system shall restrict access to product and part operational characteristics by customer and service level purchased The system shall not lose any partially configured products The system shall restrict access to partially configured products to the customer who originally created the partial configuration

224 224 May 14, 2012 THE ARCHITECTURE © 2012 Joseph F Iaquinto, PE

225 225 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Architecture Architecture – OV-1 Specification Status Product Viewpoint: Mission Intention

226 226 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Architecture Architecture – OV-2 Viewpoint: Relationship of Role to Information Product specification form Product features form Price estimate report Product catalog Request for quote Parts order Parts description form Parts availability reports Bill of laden Shipping Options Form Shipping options report Shipping cost form

227 227 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Architecture Architecture – OV-3 Viewpoint: Information Needed Information Item Information Description Information Source Information Designation Information Exchange Attributes Product Specification Form Contains the customer’s product detailed requirements Product Requestor Transaction Modeler HTTPS Customer sensitive 0.5 second response

228 228 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Architecture Architecture – OV-4 Viewpoint: Role to Role Relationship Order placement Order fulfillment

229 229 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Architecture Architecture – OV-5 Request Search Form Submit Search Form in Context Perform Search Report Parts Found Select PartsAccept Order Viewpoint: Role to Activity and Activities Performed

230 230 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Architecture Architecture – OV-6b Product Research Mode Defining Needs Investigating Product Options Evaluating Candidate Product Order Product Mode Specify Product Options Specify Shipping Options Specify Payment Options Viewpoint: Mission Driven Activity Grouping

231 231 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Architecture Architecture – OV-7 Product Specification Form Product Features Form 1 n Price Estimation Report 11 Customer specifies general product features Customer specifies customizable product features Customized product has an estimated price until purchased

232 232 May 14, 2012 © 2012 Joseph F Iaquinto, PE Conclusion

233 233 May 14, 2012 © 2012 Joseph F Iaquinto, PE Keep Conceptual Design Abstract Soon Be Able To Implement Directly! Conceptual Problem Definition Concept of Operations (CONOPS) Software Auto-Generation Hardware Fabricator System

234 234 May 14, 2012 © 2012 Joseph F Iaquinto, PE A Simple process for doing the conceptual design (CONOPS) Define the Business Events Define Representative Scenarios Define Operational Capabilities Define Structure, Function, Behavior Organize Functionality Into States and Modes Define the Problem Define the Roles and Responsibilities

235 235 May 14, 2012 © 2012 Joseph F Iaquinto, PE The Toy Example The Auto-Mower

236 236 May 14, 2012 © 2012 Joseph F Iaquinto, PE Success!


Download ppt "1 May 14, 2012 The Conceptual Design Featuring The Concept Of Operations A Tutorial By Joseph F Iaquinto, PE May 14, 2012 © 2012 Joseph F Iaquinto, PE."

Similar presentations


Ads by Google