The Conceptual Design Including The Concept Of Operations

Report
1
The Conceptual Design
Featuring
The Concept Of Operations
A Tutorial
By
Joseph F Iaquinto, PE
May 14, 2012
May 14, 2012
© 2012 Joseph F Iaquinto, PE
2
Introduction
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Introduction
Some Definitions
Concept
An abstract or generic idea generalized from particular
instances
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
3
Introduction
Conceptual design as a useful abstraction
•Useful to customer in directing the construction of the artifact
•Useful to tradesmen for making detailed implementation decisions
May 14, 2012
© 2012 Joseph F Iaquinto, PE
4
Overview of CONOPS Templates
5
Essential template
CONOPS
Scope:
System Concepts:
Identification
System Overview
Document Overview
Intention (Intended use)
Roles
Activities
Docs
Relationships
Problem Description:
Operational Scenarios:
Current Business Situation
Business Problem
Goals / Objectives for Solution
Key business events
Anomalies accounted for
Selected representative
Documents:
Operational Capabilities:
Referenced
Structure
Behaviors
Functions within Behaviors
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Introduction
CONOPS – The Key Concepts
Mission or
Intention
Roles
Information
Required
Relationships
Operational Capabilities
May 14, 2012
© 2012 Joseph F Iaquinto, PE
6
Introduction
Elementary Example – System Definition
May 14, 2012
© 2012 Joseph F Iaquinto, PE
7
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
8
Introduction
Conceptual Engineering Fallacies
• Architecture as Implementation
• OO vs. Procedural vs. SOA
• Systemantics
May 14, 2012
© 2012 Joseph F Iaquinto, PE
9
A Process for doing the conceptual design
(CONOPS)
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
10
Introduction
Example: Web Provisioning
Specification
Status
Product
May 14, 2012
© 2012 Joseph F Iaquinto, PE
11
Introduction
Not limited to IT systems!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
12
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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
13
Introduction
Ground Rules
14
• Each Session
– 50 Minute formal lecture
– 10 Minute break every hour
May 14, 2012
© 2012 Joseph F Iaquinto, PE
15
Session 1
What is a conceptual design and who cares?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
16
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: 0201835959
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Topics of Session 1
17
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Motivation – When is a CONOPS needed
We have a problem
May 14, 2012
© 2012 Joseph F Iaquinto, PE
18
Motivation – When is a CONOPS needed
This problem has become visible
May 14, 2012
© 2012 Joseph F Iaquinto, PE
19
Motivation – When is a CONOPS needed – Test 1
Is there ambiguity?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
20
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.
SE:
SE:
Voltage = 12 V
Capacity = 40 AH
Form Factor =
10x10x10 cm
Voltage = 12 V
Capacity = 40 AH
Form Factor =
10x5x2 cm
Chemistry?
Battery Engineer:
Internal Construction?
Recharge CONOPS?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
21
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.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
22
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.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
23
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.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
24
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
25
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
26
The Role of Conceptual Integrity
27
Example of Conceptual Integrity - Software
Jack
Make
Tracking
Sheet with
color code
I will make color code
in column E dependent
on value in column B
Joe
I don’t like the ordering
of the columns. I will
move them into a more
logical order.
Amanda
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Rick
The Role of Conceptual Integrity
28
Example of Conceptual Integrity - Hardware
Blowback design ok if:
1. Use stick powder
2. Clean Frequently
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Need to be cheap(?):
1. Use ball powder
2. Never needs cleaning
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 1362-1998
• 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 81430 (CANCELED!)
• NOT Joint Operation Concepts / Joint Operating Concepts of CJCSI
3170.01C a procurement document
May 14, 2012
© 2012 Joseph F Iaquinto, PE
29
Definition of Conceptual Design
Some excellent references
Frederick J Brooks, “The Mythical Man-Month:
Essays on Software Engineering, Anniversary
Edition”, Addison-Wesley Press, ISBN 0-20183595-9
Johnson & Henderson in “Conceptual Models:
Begin by Designing What to Design”,
Interactions, January + February 2002
May 14, 2012
© 2012 Joseph F Iaquinto, PE
30
Definition of Conceptual Design
Foundation for Artifacts
CONOPS
Architecture
System Requirements Specifications
Conceptual Design
May 14, 2012
© 2012 Joseph F Iaquinto, PE
31
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 taskdomain the system is designed to support
Interpretation of: Johnson & Henderson in “Conceptual Models: Begin by Designing
What to Design, Interactions, January + February 2002
May 14, 2012
© 2012 Joseph F Iaquinto, PE
32
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))
May 14, 2012
© 2012 Joseph F Iaquinto, PE
33
Definition of Conceptual Design
34
Fundamentals: Example of a Mapping
•Visit Grandma
•Grocery shop
•Go to work
Movement
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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
35
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
36
Definition of Conceptual Design
37
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…)
INCOSE
SE Handbook
IEEE
1471
Concept of Production
Concept of Deployment
Concept of Operations (ConOps)
Concept of Support
Concept of Disposal
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
38
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”
May 14, 2012
© 2012 Joseph F Iaquinto, PE
39
40
Recipe for a CONOPS – The Key Concepts
Mission or
Intention
Roles
Information
Required
Relationships
Operational Capabilities
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?)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
41
Recipe for a CONOPS
42
The Roles
People who support
the system
Users
People who are
affected by the
system
Client
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Recipe for a CONOPS
Information Required
Analogies
Information
(Documents/Forms)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
43
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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
44
Recipe for a CONOPS
45
Deriving the Operational Capabilities
Intention
+
Role
+
Capabilities
Activities
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
46
Aside:
Engineering Design Process Applies To CONOPS
The difference is only a matter of level of abstraction
Define the
problem
Reformulate to
match design
heuristics
Associate,
Associate,
Associate
Subproblems
with known
solutions
Refine the
solution (test &
rebuild)
Monitor the
solution in full
operations
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Update design
heuristics /
known
solutions
Synthesize the
overall solution
47
48
Introduction to Useful Standards and Templates
• ANSI / AIAA G-043-1992
– Guide for the Preparation of Operational Concept
Documents
• IEEE P1362
– IEEE Guide for Information Technology-System DefinitionConcept of Operations (ConOps) Document
• MIL-STD-498 / DI-IPSC-81430
– Operational Concept Descriptions
• SPC-98071-MC
– Operational Concept Document Template
• NASA-DID-P100
– Concept Data Item Description
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Where Conceptual Design Fits Into System
Engineering Process
CONOPS
Components &
Relationships
Capabilities
System
Requirements
System
Architecture
May 14, 2012
© 2012 Joseph F Iaquinto, PE
49
Where Conceptual Design Fits Into System
Architecture Process (DODAF)
CONOPS
Operational Information Exchange Matrix
Operational Concept Graphic
Operational Node Connectivity Diagram
May 14, 2012
© 2012 Joseph F Iaquinto, PE
50
The Conceptual Design
More on mapping CONOPS to DODAF
Components
•
•
•
•
Relationships
Missions / Intentions (OV-1)
Roles (OV-4!!)
– Skills
– Where (Nodes)
Needed Information (OV-3 /
OV-7?)
– Performance
Activities (OV-5, SvcV-4)
– Performance
•
•
•
•
•
•
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
51
52
Session 2
Principles and Fallacies of Conceptual Design
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Topics of Session 2
53
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
54
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)?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think “User Viewpoint”
Intended Use Centric
•
55
Capture manner of customer’s
circumstance
– Language
– Intentions
– Historical Perspective
Magellan 750
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think “User Viewpoint”
Establish Foundation
Acquire “Domain” (User) Knowledge
Acquire “Domain” (User) Experience
May 14, 2012
© 2012 Joseph F Iaquinto, PE
56
Judgment
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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
57
Think “User Viewpoint”
Conceptualize in Customer’s Language
Parts List NOT Aggregation!
Kinds of Parts NOT Generalization /
Specialization
Interconnection NOT Association
May 14, 2012
© 2012 Joseph F Iaquinto, PE
58
Think “User Viewpoint”
A Counter Example – As found
59
System
Concepts
Provide
Services
Provide
Worldwide
Access
“Network”
With
Co-workers
Dynamic
Collaboration
Enterprise
Management
Private
Conversations
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Dynamic
Resource
Allocation
System
Assurance
Knowing
What is
Happening
Think “User Viewpoint”
A Counter Example – The reality
60
System
Concepts
“Network”
With
Co-workers
Provide
Services
Provide
Worldwide
Access
Knowing
What is
Happening
Private
Conversations
Dynamic
Collaboration
Enterprise
Management
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Dynamic
Resource
Allocation
System
Assurance
Think “User Viewpoint”
Be Aware of Implementation Possibilities
The operator will have complete
control over the direction in which
the vehicle moves.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
61
Think “User Viewpoint”
A Most Important Architectural Artifact
User Interface (example: screen shot) is important part of
Conceptual Design and a legitimate architectural artifact!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
62
Think Critically – Foundation for Problem / Solutions
Basic Principles
•
•
•
•
•
•
•
•
Clarity
Precision
Accuracy
Relevance
Consistency
Logical Correctness
Completeness
Fairness
• My Favorite Barrier:
– Wishful Thinking
May 14, 2012
© 2012 Joseph F Iaquinto, PE
63
Think Critically
Be Argumentative
Controversy
64
Resolution
Issue
Claim
Issue
Claim
Issue
Claim
Evidence
Inference
Warrant
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Claim
Think Critically
Be Argumentative
Where is the Issue:
COBOL is totally obsolete; thus, we need
to code in JAVA
Where is the Evidence (Rationale):
We cannot find college trained COBOL
programmers; thus, we need to code in
JAVA.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
65
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?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
66
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!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
67
Think Critically
Consider All Relevant Dimensions
68
Reusable
Services
Use Rather
Than Code
Restrictive
Association (to
services)
Component
Change Impact
Test Them Or
Trust Them?
Understand
What They Do
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Understand How
They Work
Understanding
Prototypes
Think Critically
Use of the Scientific Method
May 14, 2012
© 2012 Joseph F Iaquinto, PE
69
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
70
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!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
71
Think Critically
Use of the Scientific Method - Fallacy
Fertilizer Work?
Test
Article
Hole in Ozone Layer?
Control
Test
Article
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Control???
72
Think Critically
Usefulness of the Scientific Method
Control on left or Right?
Associate Orders or Not?
Pizza Order
Go
Form for Order Entry
•Function 1
Go
1
•Function 2
m
Soda Order
May 14, 2012
© 2012 Joseph F Iaquinto, PE
73
Think Critically
The Process of Problem Solving
Identify The
Problem
Identify The
Cause
Gather
Information
Generate
Solutions
Evaluate
Solution
74
Identify & Remove
Barriers
Select
Solution
Courage to
Evolve Solution
Genesis of the CONOPS
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
75
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
76
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
77
Think Critically
78
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think Critically
79
Understand “Common” Beliefs in Customer Domain
• Identifying common beliefs
– Artifacts of technology
– Artifacts of history
– Artifacts of personality
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think Critically
80
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think Critically
81
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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think Critically
82
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think Critically
83
Understand Emotional Influences In Customer
User
System Engineer
May 14, 2012
© 2012 Joseph F Iaquinto, PE
•Fear of job loss
•Fear of prestige loss
•Fear of failure
•Angry at being forced…
•Genuine concern
Think Critically
84
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 rebuild our IT infrastructure upon Web Services
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think Critically
85
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think Critically
86
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Think Critically
87
Employ Inductive and Deductive Reasoning
Deductive 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…
From the general to the specific
• Syllogism: premise (reason)
•
and a conclusion that follows
Most natural, everyone is
capable of this kind of thinking
•
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Selecting Perspective (Views)
Useful Concepts
See IEEE 1471-2000 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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
88
Selecting Perspectives (Views)
Basic Concepts of “Perspective”
Is addressed by
Stakerholder
Concern
Viewpoint
Has a
Represented by specific
Views
Rendered / addressed by specific
Products / Model
Bottom line: products are arguments!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
89
Selecting Perspectives (Views)
First Rule: Keep Views Very Simple – Bad Example
May 14, 2012
© 2012 Joseph F Iaquinto, PE
90
Selecting Perspectives (Views)
91
First Rule: Keep Views Very Simple–Better Example
OV-4 Naval Command Structure
JFACC
JFMCC
Operational Command / Control
Tactical Control
CSG
Air Related Organizations
Non Air Related Organizations
Carrier Strike Group Organizations
May 14, 2012
© 2012 Joseph F Iaquinto, PE
From the Tar Pit: Fred Brooks
Basic Concepts
C.R.Knight, Mural of La Brea Tar Pits
•
The Mythical Man Month
•
Conceptual Integrity
•
The Surgical Team
•
Aristocracy, Democracy, and System Design
May 14, 2012
© 2012 Joseph F Iaquinto, PE
92
From the Tar Pit: Fred Brooks
The Mythical Man Month
Training Cost
+
Interaction Cost
• 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
Break up the conceptual design effort into parallel teams a BAD IDEA
•Operational (Views)
•System (View)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
93
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
94
From the Tar Pit: Fred Brooks
The Surgical Team
95
Architect
Co-Architect
Administrator
Tech Pubs
•Maintain Conceptual Integrity
•Multiply Effectiveness of
“Hero”
•Scales Sufficiently for
Conceptual Designs
Engineering
Tool Maker
QA / Test
Domain
Expert
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”.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
96
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
97
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
98
Common Conceptual Design Fallacies
99
Zachman – “Drowning projects in bubbles and boxes”
•36 Categories
of information
•Planner /
owner level all
that is
applicable
•Too
distracting
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Common Conceptual Design Fallacies
Instead of Zachman – KEEP IT SIMPLE
Conceptual
Design
Intention
Information
Activities
Roles
The
Business
Profit
Documents
Workflow
Personnel
The
Automation
Rationale
Data
Capabilities
Users/Actors
May 14, 2012
© 2012 Joseph F Iaquinto, PE
100
Common Conceptual Design Fallacies
101
Lack of Focus In Illustrations
OV-4 Naval Command Structure
JFACC
JFMCC
Operational Command / Control
Tactical Control
CSG
Air Related Organizations
Non Air Related Organizations
Carrier Strike Group Organizations
What is the point?
Dual Command of Air
Related Operations
Clear Focus On Interoperability Requirement / Challenge
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Common Conceptual Design Fallacies
OO Versus Procedural Versus SOA…
Architecture is concerned with user interface
Orthogonal
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
102
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
103
Common Conceptual Design Fallacies
Use of UML Cartoons - Aggregation
Concept of Aggregation is confusing to User / Owner
•
•
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
VS
Further Information:
INCOSE Insight, Volume 7, Issue 2, July 2012, Semantic Dictionary and
Concept Model, Michael Dickerson, David Oliver and Joseph Skipper
May 14, 2012
© 2012 Joseph F Iaquinto, PE
104
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
Concept of Generalization
is also confusing to User /
Owner
•
Real physical things have
properties that result from their
unique construction /
composition
VS
•
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
105
Common Conceptual Design Fallacies
Ontology – Another Confusing Concept
Is addressed by
Stakerholder
Concern
Viewpoint
Has a
Represented by specific
Uses to evaluate CONOPS
Views
Rendered / addressed by specific
Products / Model
Structured, language-independent network of concepts for a
Particular domain and / or its subset
May 14, 2012
© 2012 Joseph F Iaquinto, PE
106
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
107
Common Conceptual Design Fallacies
Reuse – Is It Worth The Expense?
The Reality of Reuse
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
•
•
•
•
•
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
108
Big Failure Modes – Systemantics
109
Defined
Systemantics, The Underground Text of System Lore,
How Systems Really Work and How They Fail, John Gall,
ISBN:0-9618251-0-3 or –1-1
•
•
•
•
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Big Failure Modes – Systemantics
110
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?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Big Failure Modes – Systemantics
111
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Big Failure Modes – Systemantics
112
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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Big Failure Modes – Systemantics
113
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Big Failure Modes – Systemantics
Countering them with FMEAs
May 14, 2012
© 2012 Joseph F Iaquinto, PE
114
115
Session 3
A Process for Defining a CONOPS
May 14, 2012
© 2012 Joseph F Iaquinto, PE
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
116
Develop Basic Concepts
117
Relationships of Fundamental CONOPS Concepts
Business
Problem
Leads to
Causes
Intention
Activities
Facilitated
By
(Scenarios)
Used
By
Executed By
Roles
Utilize
Information
May 14, 2012
© 2012 Joseph F Iaquinto, PE
System
Under
Definition
Operational
Capabilities
Provides
118
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
Define The Problem In Business Terms
The Single Most Important Concept
May 14, 2012
© 2012 Joseph F Iaquinto, PE
119
120
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
121
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?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
122
Define The Roles and Responsibilities
Beware of what people tell you!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
123
124
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
Define The “Business Event”
Business Events Are Central to Creating
A CONOPS
May 14, 2012
© 2012 Joseph F Iaquinto, PE
125
Define the “Business Events”
Exploitation of Business Events and the CONOPS
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
126
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
127
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
128
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
129
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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
130
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
131
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”
May 14, 2012
© 2012 Joseph F Iaquinto, PE
132
Define the “Business Events”
133
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define the “Business Event”
134
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define the “Business Event”
135
The Description
Abstract
Business speak
Change
Business Tempo
New
Information
Demand
A Response
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 / …)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
136
137
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
Define Representative Scenarios
Purpose of scenarios
• 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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
138
Define the Representative Scenarios
Problem of defining scenarios
Problem:
Select scenarios that permit the identification
of all of the operational capabilities of the
system.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
139
Define the Representative Scenarios
The solution to defining scenarios
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
140
Define the Representative Scenario
Characteristics of a good scenario
• 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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
141
Define the Representative Scenario
Scenario warning – Repeated!
A conceptual scenario is NOT a software
(UML) scenario or use case!
• Different Motivation
• Different Level Of Abstraction
• Different Viewpoint
May 14, 2012
© 2012 Joseph F Iaquinto, PE
142
Define the Representative Scenarios
Scenario writing rules
• 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!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
143
Define the Representative Scenarios
Scenario example
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.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
144
145
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
Define the Operational Capabilities
146
Operational Capabilities Flow From Scenarios
Scenario
Behavioral Requirements
Constraint
Requirements
Functional
Requirements
Functional
Requirements
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Functional
Requirements
Define the Operational Capabilities
A Three View Model of Operational Capabilities
Structures
Functions
Behaviors
May 14, 2012
© 2012 Joseph F Iaquinto, PE
147
Define the Operational Capabilities
Definition of the three views
Where are
activities
“physically
implemented?
What does it do?
When and how does it
perform its function?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
148
Define the Operational Capabilities
Operational Capability Structure View Guidelines
Where activities are physically implemented
• 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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
149
Define the Operational Capabilities
Operational Capability Function View Guidelines
What does it do?
• 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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
150
Define the Operational Capabilities
Operational Capability Behavior View Guidelines
When and how does it perform its function?
• 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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
151
Define the Operational Capabilities
Behavior – The Mysteries of States and Modes
Behaviors serve to organize functions by
intended use / business event
•
•
•
•
•
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!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
152
Define the Operational Capabilities
153
Behavior - An example of Modes and States
Command
Communications
System
Normal
Operations
Mode
Attack
Classification
State
Crisis
Operations
Mode
Repel
State
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Disaster
Recovery
Mode
Resource
Recovery
State
Define the Operational Capabilities
154
An example of States and Modes - Functions
Repel
State
Retrieve Attack
Specific Operations
Plans
Locate Available
Resources
Allocate Resources
According to Plan
Analyze Impact
Of
Resource Re-Allocation
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Employ
Resources
Re-Assign
Applicable
Resources
Verify and Validate CONOPS
155
Initial Conceptual Design Always Requires Refinement
Refinements
CONOPS
Conceptual
Analysis
Some Checklists
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
156
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
157
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
158
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
159
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
160
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
161
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
162
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
163
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
164
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
165
166
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Document CONOPS
167
Widely Accepted Templates
CJCSI 3170.01 B Appendix A
to Enclosure E
NASA DI-P100
Concept Data Item Description
DI-IPSC-81430 Operational
Concepts Desc. (OCD)
DI-MCCR-80023
Concepts of Operations Document
ANSI/AIAA G-043-1992
Guide to preparation of OCD
Software Productivity Consortium
SPC-98071-MC, OCD Template
IEEE Std. 1362-1998
System Definition-ConOps
Tenix Defense Systems
Development of Operational
Concepts Descriptions
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Document CONOPS
168
Crude Comparison
C JSC I 3170
G e n e ra l
D e s c rip tio n o f th e
O p e ra tio n a l N e e d
(m is s io n , o p s
s u p p o rt
c o n c e p ts … )
T h re a t
81430
1 . S c o p e (ID , S ys te m
O ve rvie w , D o c u m e n t
O ve rvie w )
3 . C u rre n t S ys te m o r
S itu a tio n (B a c k g ro u n d ,
S h o rtc o m m in g s o f P o lic ie s , d e s c rip tio n ,
P re s e n t S ys te m s u s e rs , s u p p o rt c o n c e p t)
C a p a b ilitie s
R e q u ire d (s ys
p e rf, in fo
e x c h a n g e re q ,
lo g is tic s ,
5 C o n c e p t fo r a n e w o r
e n viro n m e n t)
m o d ifie d s ys te m
P ro g ra m S u p p o rt
F o rc e S tru c tu re
S c h e d u le
P ro g ra m
A ffo rd a b ility
AN SI
IE E E
N ASA
80023
1 . S c o p e (id , d o c u m e n t
o ve rvie w , s ys te m
o ve rvie w )
1 . In tro d u c tio n
4 . U s e r-O rie n te d
O p e ra tio n a l D e s c rip tio n
3 . C u rre n t S ys te m o r
S itu a tio n
3 . D e fin itio n o f:
P u rp o s e , s c o p e ,
g o a ls , d e s c rip tio n ,
p o lic ie s .
3 . S ys te m
J u s tific a tio n
5 . S ys te m O ve rvie w
(s c o p e , u s e rs , in te rfa c e s ,
c a p a b ilite s … )
5 . C o n c e p ts fo r th e
p ro p o s e d s ys te m
5 . C a p a b ilitie s a n d
C h a ra c te ris tic s
4 S ys te m C o n c e p ts
2 . R e fe re n c e d
D o c u m e n ts
4 J u s tific a tio n fo r a n d
n a tu re o f c h a n g e s
2 . R e la te d
D o c u m e n ta tio n
1 . S c o p e (Id , p u rp o s e ,
o ve rvfie w )
1 . In tro d u c tio n
2 B u s in e s s N e e d
7 . S u p p o rt E n viro n m e n t
2 R e fe re n c e d D o c u m e n ts 2 . R e fe re n c e d D o c u m e n ts
4 . J u s tific a tio n fo r a n d
n a tu re o f c h a n g e s
6 O p e ra tio n a l S c e n a rio s
7 S u m m a ry o f im p a c ts
(O p e ra tio n a l,
o rg a n iza tio n a l,
d e ve lo p m e n ta l)
8 A n a lys is o f th e
p ro p o s e d s ys te m
8 O p e ra tio n a l S c e n a rio s
6 B u s in e s s Im p a c ts
6 .O p e ra tio n a l E n viro n m e n t
4 . U s e r D e fin itio n
7 R a tio n a le
8 C o n c e p tu a l M o d e l
May 14, 2012
© 2012 Joseph F Iaquinto, PE
1 Scope
T E N IX
O p e ra tio n a l
O b je c tive s a n d
M is s io n s
3 S ys te m D e s c rip tio n S ys te m D e s c rip tio n
5 S u p p o rt
E n viro n m e n t
S ys te m L ive C yc le
O rg a n iza tio n s
2 R e fe re n c e d
D o c u m e n ts
6 . S a m p le O p e ra tio n a l 5 O p e ra tio n a l
6 O p e ra tio n a l S c e n a rio s S c e n a rio s
S c e n a rio s
7 S u m m a ry o f im p a c ts
8 A n a lys is o f th e
p ro p o s e d s ys te m
SPC
4 O p e ra tio n a l
S c e n a rio s
S c e n a rio s
L e g a c y O p e ra tio n a l
C o n c e p ts
Document CONOPS
169
Essential template
CONOPS
Scope:
System Concepts:
Identification
System Overview
Document Overview
Intention (Intended use)
Roles
Activities
Docs
Relationships
Problem Description:
Operational Scenarios:
Current Business Situation
Business Problem
Goals / Objectives for Solution
Key business events
Anomalies accounted for
Selected representative
Documents:
Operational Capabilities:
Referenced
Structure
Behaviors
Functions within Behaviors
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
170
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
171
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
172
173
Some Useful Heuristics
• Know the business and how it earns profit
• Users as a integral part of the CONOPS team
• Beware of user inputs
May 14, 2012
© 2012 Joseph F Iaquinto, PE
174
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
175
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
176
Some Useful Heuristics
•
•
•
•
•
•
•
•
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
177
Session 4
An Example
Illustration of some of the elements of a conceptual
design
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Topics For Session 4
Example
• The CONOPS
• The System Requirements
Specification
• The Architecture
May 14, 2012
© 2012 Joseph F Iaquinto, PE
178
An Example
179
Web Provisioning
Specification
Status
Product
May 14, 2012
© 2012 Joseph F Iaquinto, PE
180
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
An Example
Define the Problem
181
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.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
182
Intention
Buy neat,
affordable stuff
that I have a role
in ‘designing’
•Make neat stuff
•Make money
•Beat the competition
May 14, 2012
© 2012 Joseph F Iaquinto, PE
183
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
184
Roles
Product Requestor
Transporter
Transaction Modeler
Product Maker
Component Maker
May 14, 2012
© 2012 Joseph F Iaquinto, PE
185
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)
May 14, 2012
© 2012 Joseph F Iaquinto, PE
186
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
187
Define the Business Events
Request Product Options
Product
Requestor
Product Research Results Provided
Request for quote for catalog item
Response to request for quote for catalog item
Component
Maker
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
188
189
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
190
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
191
A Process for defining the CONOPS
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
192
Define Operational Capabilities
Unusual
Capability
Specifies Desired
Product specification
form
Invoice
Role
Standard
Capability
Information
Warning: Study unusual capability rather than be
completely distracted by “standard practice” ones
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
193
Define Operational Capabilities
194
Fragment of Modes and States analysis
Defining
Needs
Investigating
Product
Options
Evaluating
Candidate
Product
Specify
Product
Options
Product Research Mode
Specify
Shipping
Options
Specify
Payment
Options
Order Product Mode
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
195
Define the Operational Capabilities
196
Business Information
Defining
Needs
General Product
Search Form
General Product
Inventor Including
User Level
Characteristics
General Product
Availability
Report
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Repository of
Previous Search
Requests
197
Verify and Validate CONOPS
• Political Concept Correct?
• Acceptable to User?
• Acceptable to Business?
• Interoperability Accomplished?
• Undesirable Consequences Compensated?
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?
May 14, 2012
© 2012 Joseph F Iaquinto, PE
198
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
199
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
200
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!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
201
Verify and Validate
Undesirable Consequences Compensated?
Request Price
Request Component Price
Price Quote = z
Price Quote = x
Payment = z
Invoice = x + Δ
Undesirable Consequence = lose money
Compensation: New Role of “Legal Contractor”
General Rule:
Design Organization of Organizations Before Getting
Systems or Development Engineering Involved!
May 14, 2012
© 2012 Joseph F Iaquinto, PE
202
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
203
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…
May 14, 2012
© 2012 Joseph F Iaquinto, PE
204
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…
May 14, 2012
© 2012 Joseph F Iaquinto, PE
205
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??
May 14, 2012
© 2012 Joseph F Iaquinto, PE
206
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…
May 14, 2012
© 2012 Joseph F Iaquinto, PE
207
Document CONOPS
Topics
• CONOPS Outline
• SRS Outline
• Architectural Artifacts
– OV-1
– OV-2
– OV-3
– OV-4
– OV-5
– OV-6b
– OV-7
May 14, 2012
© 2012 Joseph F Iaquinto, PE
208
Document CONOPS
209
CONOPS Outline Sketch
CONOPS
Scope:
System Concepts:
Identification
System Overview
Document Overview
Intention (Intended use)
Roles
Activities
Docs
Relationships
Problem Description:
Operational Scenarios:
Current Business Situation
Business Problem
Goals / Objectives for Solution
Key business events
Anomalies planned for
Selected representative
Documents:
Operational Capabilities:
Referenced
Reference
Structure
Behaviors
Functions within Behaviors
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
210
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
211
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…
May 14, 2012
© 2012 Joseph F Iaquinto, PE
212
Document CONOPS
CONOPS - References
Documents:
Referenced
•Established Industry Standards
•Established Industry Specific Trade Agreements
Reference
•Architectural Process of the year
May 14, 2012
© 2012 Joseph F Iaquinto, PE
213
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
214
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.
May 14, 2012
© 2012 Joseph F Iaquinto, PE
215
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…
May 14, 2012
© 2012 Joseph F Iaquinto, PE
216
217
THE SYSTEM REQUIREMENTS
SPECIFICATION
May 14, 2012
© 2012 Joseph F Iaquinto, PE
The System Requirements Specification
System Requirements Specification Outline
2. General System
Description
1. Introduction
3. System
Capabilities
4. System
Interfaces
IEEE Std 1233, 1998 Edition
May 14, 2012
© 2012 Joseph F Iaquinto, PE
218
The System Requirements Specification
SRS – Introduction
CONOPS Scope
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
CONOPS Documents
Documents:
Referenced
•Established Industry Standards
•Established Industry Specific Trade Agreements
Reference
•Architectural Process of the year
1.1 System Purpose
1.2 System Scope
1.3 Definitions, Acronyms
1.4 References
1.5 System Overview
May 14, 2012
© 2012 Joseph F Iaquinto, PE
219
The System Requirements Specification
SRS – General System Description
SRS General Sys Desc
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
220
The System Requirements Specification
SRS – System Capabilities, Conditions,…
SRS System Capabilities…
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
Section 3.2 in particular is organized by capability
May 14, 2012
© 2012 Joseph F Iaquinto, PE
221
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
222
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
May 14, 2012
© 2012 Joseph F Iaquinto, PE
223
224
THE ARCHITECTURE
May 14, 2012
© 2012 Joseph F Iaquinto, PE
The Architecture
225
Architecture – OV-1
Specification
Status
Product
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Viewpoint: Mission Intention
The Architecture
226
Architecture – OV-2
•Product
specification
form
•Product
features form
•Price estimate
report
•Product catalog
•Bill of laden
•Shipping
Options Form
•Parts
description
form
•Parts
availability
reports
•Request for
quote
•Parts order
•Shipping
options report
•Shipping cost
form
Viewpoint: Relationship of Role to Information
May 14, 2012
© 2012 Joseph F Iaquinto, PE
The Architecture
227
Architecture – OV-3
Information
Item
Information
Description
Product
Specification
Form
Contains the
customer’s
product
detailed
requirements
Information
Source
Product
Requestor
Information
Designation
Information
Exchange
Attributes
Transaction
Modeler
•HTTPS
•Customer
sensitive
•0.5 second
response
Viewpoint: Information Needed
May 14, 2012
© 2012 Joseph F Iaquinto, PE
The Architecture
228
Architecture – OV-4
Order placement
Order fulfillment
Viewpoint: Role to Role Relationship
May 14, 2012
© 2012 Joseph F Iaquinto, PE
The Architecture
229
Architecture – OV-5
Submit Search
Form in
Context
Request Search
Form
Report Parts
Found
Select Parts
Perform
Search
Accept Order
Viewpoint: Role to Activity and Activities Performed
May 14, 2012
© 2012 Joseph F Iaquinto, PE
The Architecture
230
Architecture – OV-6b
Defining
Needs
Investigating
Product
Options
Evaluating
Candidate
Product
Specify
Product
Options
Product Research Mode
Viewpoint: Mission Driven
Activity Grouping
Specify
Shipping
Options
Specify
Payment
Options
Order Product Mode
May 14, 2012
© 2012 Joseph F Iaquinto, PE
The Architecture
231
Architecture – OV-7
Product
Specification Form
1
Customer specifies general product features
n
1
Product Features
Form
Customer specifies customizable
product features
May 14, 2012
© 2012 Joseph F Iaquinto, PE
1
Price Estimation
Report
Customized product has an
estimated price until purchased
232
Conclusion
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Keep Conceptual Design Abstract
233
Soon Be Able To Implement Directly!
Conceptual
Problem Definition
Concept of
Operations
(CONOPS)
Software
Auto-Generation
Hardware
Fabricator
System
May 14, 2012
© 2012 Joseph F Iaquinto, PE
A Simple process for doing the conceptual design
(CONOPS)
Define
the Problem
Define the
Roles and Responsibilities
Define
the Business Events
Define
Representative Scenarios
Define Structure,
Function, Behavior
Organize Functionality
Into States and Modes
May 14, 2012
© 2012 Joseph F Iaquinto, PE
Define
Operational Capabilities
234
The Toy Example
The Auto-Mower
May 14, 2012
© 2012 Joseph F Iaquinto, PE
235
236
Success!
May 14, 2012
© 2012 Joseph F Iaquinto, PE

similar documents