The Conceptual Design - PowerPoint Presentation

413 views
Uploaded On 2015-11-11

The Conceptual Design - PPT Presentation

Featuring The Concept Of Operations A Tutorial By Joseph F Iaquinto PE May 14 2012 2012 Joseph F Iaquinto PE 2012 Joseph F Iaquinto PE Introduction 2012 Joseph ID: 190592

joseph 2012 system iaquinto 2012 joseph iaquinto system business product conceptual define operational conops design capabilities problem information roles

Link:

Copy

Embed:

<iframe width="560" height="315" src="https://www.docslides.com/embed/190592" frameborder="0" allowfullscreen></iframe>

Download Presentation from below link

Download Presentation The PPT/PDF document "The Conceptual Design" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.

Presentation Transcript

Slide1

The Conceptual DesignFeaturing The Concept Of Operations

A TutorialByJoseph F Iaquinto, PEMay 14, 2012

Iaquinto

PESlide2

IntroductionSlide3

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 Slide4

Introduction Conceptual design as a useful abstraction

Useful to customer in directing the construction of the artifact

Useful to tradesmen for making detailed implementation decisionsSlide5

Overview of CONOPS TemplatesEssential template

CONOPS

Scope:

Identification

System Overview

Document Overview

Problem Description:

Current Business Situation

Business Problem

Goals / Objectives for Solution

Documents:

Referenced

Operational Scenarios:

Key business events

Anomalies

accounted for

Selected representative

System Concepts:

Intention (Intended use)

Roles Activities

Docs Relationships

Operational Capabilities:

Structure

Behaviors

Functions within BehaviorsSlide6

Introduction

CONOPS

– The Key Concepts

Mission or Intention

Activities

Information

Required

Roles

Operational

Capabilities

RelationshipsSlide7

Introduction Elementary Example – System DefinitionSlide8

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 teamsSlide9

Introduction Conceptual Engineering Fallacies

Architecture as Implementation

OO vs.

Procedural vs. SOA

SystemanticsSlide10

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 ResponsibilitiesSlide11

Introduction Example: Web Provisioning

Specification

Status

ProductSlide12

Introduction Not limited to IT systems!Slide13

Introduction Tutorial Sessions

Introduction

What is a Conceptual Design and Who Cares?

Principles

and fallacies of conceptual design

Process for defining a CONOPS

Example Walkthrough

Toy CONOPS (Homework)Slide14

Introduction Ground Rules

Each Session

Minute formal lecture

Minute

break every hourSlide15

Session 1

What is a conceptual design and who cares?Slide16

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 Slide17

Topics of Session 1What 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)InformationIntroduction to some useful standards and templates

Where the conceptual design fits into the System Engineering ProcessSlide18

Motivation – When is a CONOPS needed We have a problem

System Engineering

Is Too Expensive!Slide19

Motivation – When is a CONOPS needed

This problem has become visible

System Engineering

Fails More Than It Succeeds!Slide20

Motivation – When is a CONOPS needed – Test 1 Is there ambiguity?Slide21

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:Slide22

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.Slide23

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.Slide24

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.Slide25

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 problemSlide26

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 complySlide27

The Role of Conceptual Integrity Example of Conceptual Integrity - Software

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

RickSlide28

The Role of Conceptual Integrity Example of Conceptual Integrity - Hardware

Blowback design ok if:

Use stick powder

Clean Frequently

Need to be cheap(?):

Use ball powder

Never needs cleaningSlide29

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 documentSlide30

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 0-201-83595-9Slide31

Definition of Conceptual Design Foundation for Artifacts

CONOPS

Architecture

System Requirements Specifications

Conceptual DesignSlide32

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 manipulateActivities users can performExposes the relationships between the ConceptsIlluminates 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 2002Slide33

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))Slide34

Definition of Conceptual Design Fundamentals: Example of a Mapping

Movement

Visit Grandma

Grocery shop

Go to workSlide35

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)Slide36

Definition of Conceptual Design Fundamentals: User Activities

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 Slide37

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 HandbookSlide38

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 doSlide39

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”Slide40

Recipe

for a

CONOPS – The Key Concepts

Mission or Intention

Activities

Information

Required

Roles

Operational

Capabilities

RelationshipsSlide41

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?)Slide42

Recipe for a CONOPS The Roles

Users

Client

People who support the system

People who are affected by the systemSlide43

Recipe for a CONOPS Information Required

Analogies

Information

(

Documents/Forms

)Slide44

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)Slide45

Recipe for a CONOPS Deriving the Operational Capabilities

Intention

Role

Activities

CapabilitiesSlide46

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 eventsSlide47

Aside: Engineering Design Process Applies To CONOPS

The difference

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 solutionsSlide48

Introduction to Useful Standards and TemplatesANSI / AIAA G-043-1992Guide 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-81430

Operational Concept Descriptions

SPC-98071-MC

Operational Concept Document Template

NASA-DID-P100Concept Data Item DescriptionSlide49

Where Conceptual Design Fits Into System Engineering Process

CONOPS

System

Requirements

System

Architecture

Capabilities

Components &

RelationshipsSlide50

Where Conceptual Design Fits Into System Architecture Process (DODAF)

Operational Concept Graphic

Operational Node Connectivity Diagram

Operational Information Exchange Matrix

CONOPSSlide51

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 skillSlide52

Session 2

Principles and Fallacies of Conceptual DesignSlide53

Topics of Session 2Principles and fallacies of conceptual design

The

Conceptual Problem

Think “User

Viewpoint”

Think Critically

Selecting Perspectives

(Views)From the Tar Pit: Fred BrooksCommon Conceptual Design FallaciesBig Failure Modes - SystemanticsSlide54

The Conceptual Problem – A ChecklistHow 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)?Slide55

Think “User

Viewpoint”

Intended Use Centric

Capture manner of customer’s circumstance

Language

Intentions

Historical Perspective

Magellan 750Slide56

Think “User Viewpoint” Establish Foundation

Acquire “Domain” (User) Knowledge

Acquire “Domain” (User) Experience

JudgmentSlide57

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)Slide58

Think “User Viewpoint” Conceptualize in Customer’s Language

Parts List

NOT

Aggregation

Kinds of Parts

NOT

Generalization / Specialization

Interconnection

NOT

AssociationSlide59

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

HappeningSlide60

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

HappeningSlide61

Think “User Viewpoint” Be Aware of Implementation Possibilities

The operator will have complete control over the direction in which the vehicle moves.Slide62

Think “User Viewpoint” A Most Important Architectural Artifact

User Interface (example: screen shot) is important part of Conceptual Design and a legitimate architectural artifact!Slide63

Think Critically – Foundation for Problem / Solutions Basic Principles

Clarity

Precision

Accuracy

Relevance

Consistency

Logical Correctness

CompletenessFairnessMy Favorite Barrier:Wishful ThinkingSlide64

Think Critically Be Argumentative

Controversy

Resolution

Issue

Claim

Evidence

Claim

Warrant

InferenceSlide65

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):Slide66

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?Slide67

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!Slide68

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 ImpactSlide69

Think Critically Use of the Scientific Method

Body of Knowledge

(Always Changing)

Method

(Limited Use)

+Slide70

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 knowledgeSlide71

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!Slide72

Think Critically Use of the Scientific Method - Fallacy

Test Article

Control

Fertilizer Work?

Hole in Ozone Layer?

Test Article

Control???Slide73

Think Critically Usefulness of the Scientific Method

Control on left or Right?

Associate Orders or Not?

Form for Order Entry

Function 1

Function 2

Pizza Order

Soda Order

mSlide74

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 CONOPSSlide75

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 argumentStraw man (striking beside the issue)Red herringEquivocation (I did not have sex with that woman!)

Begging the question

Is the argument advancing?Slide76

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 causeHasty generalization

Slippery slopeWeak analogyInconsistency

Reasons Don’t Support ConclusionSlide77

Think Critically Understand the use of languageVital 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 correctnessSlide78

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 prejudiceSlide79

Think Critically Understand “Common” Beliefs in Customer Domain

Identifying common beliefs

Artifacts of technology

Artifacts of history

Artifacts of personalitySlide80

Think Critically Understand “Common” Beliefs in Customer Domain

Artifacts of technology

Process

Technical constraint vs. innate

Productivity limitation

Documents

Communications (between departments)

Continuity of operationsLimitations

Insufficient productivity

Insufficient communicationsSlide81

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” orderDocuments dictated by philosophyLimitations dictated by social relationships (DOD)Slide82

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 personnelSimilar to foundersSlide83

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 concernSlide84

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

Drawing broad conclusions on basis of single incidentSlide85

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

Focus on one detail and ignoring the big pictureSlide86

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 EngineeringChronological OrderTime or sequence

Central to behavioral modeling

Causal Order

Reasons or cause and effect

Important theme of behavioral modelingSlide87

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 generalAnalogical argument: a specific similarity implies general similarityVery hard to do, requires a mutant

The principle fallacy of the OO

method, Ontologism…Slide88

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 systemSlide89

Selecting Perspectives (Views) Basic Concepts of “Perspective”

Stakerholder

Concern

Viewpoint

Views

Products / Model

Has a

Is addressed by

Represented by specific

Rendered / addressed by specific

Bottom line: products are arguments!Slide90

Selecting Perspectives (Views)First Rule: Keep Views Very Simple – Bad ExampleSlide91

Selecting Perspectives (Views)

First Rule: Keep Views Very Simple–Better Example

JFMCC

JFACC

CSG

Air Related Organizations

Non Air Related Organizations

Carrier Strike Group Organizations

Operational Command / Control

Tactical Control

OV-4 Naval Command Structure Slide92

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 PitsSlide93

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)Slide94

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 semanticsUnity of designSlide95

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 DesignsSlide96

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”.Slide97

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

OntologyReuseSlide98

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 2001Slide99

Common Conceptual Design Fallacies Zachman – “Drowning projects in bubbles and boxes”

36 Categories of information

Planner / owner level all that is applicable

Too distractingSlide100

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/ActorsSlide101

Common Conceptual Design Fallacies Lack of Focus In Illustrations

JFMCC

JFACC

CSG

Air Related Organizations

Non 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 / ChallengeSlide102

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

/ SOA

about relating groups of executables

Procedural

is about characterizing a single executable

OrthogonalSlide103

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 SystemsSlide104

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

VSSlide105

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

VSSlide106

Common Conceptual Design Fallacies Ontology – Another Confusing Concept

Stakerholder

Concern

Viewpoint

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 CONOPSSlide107

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 metaphorsUnderstand the user’s operational modelArchitecture should match this operational model

The user, not the system, brings meaning to the systemSlide108

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 codingSlide109

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 FMEAsDo not panic, its all a joke

Systemantics, The Underground Text of System Lore,

How Systems Really Work and How They Fail,

John Gall,

ISBN:0-9618251-0-3 or –1-1Slide110

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?Slide111

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 systemSlide112

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)Slide113

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

?Slide114

Big Failure Modes – Systemantics Countering them with FMEAs

PESlide115

Session 3

A Process for Defining a CONOPSSlide116

Topics of Session 3The Process for Defining A CONOPS

Develop the Basic ConceptsDefine the ProblemDefine the Roles and ResponsibilitiesDefine the Business Events

Define the Representative Scenarios

Define the Operational Capabilities

Verify and Validate CONOPS

Document CONOPS

Some Useful Heuristics

PESlide117

Develop Basic Concepts Relationships of Fundamental CONOPS Concepts

Intention

Activities

(Scenarios)

System

Under

Definition

Roles

Information

Operational

Capabilities

Causes

Facilitated

Executed By

Utilize

Used

Provides

Business Problem

Leads toSlide118

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 ResponsibilitiesSlide119

Define The Problem In Business Terms

The Single Most Important ConceptSlide120

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 ResponsibilitiesSlide121

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 roleSlide122

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?Slide123

Define The Roles and Responsibilities

Beware of what people tell you!Slide124

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 ResponsibilitiesSlide125

Define The “Business Event”

Business Events Are Central to Creating A CONOPSSlide126

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 designSlide127

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” transactionsUnderstand the importance of the transactions in running the businessSlide128

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 Slide129

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 literatureSlide130

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)Slide131

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 permitSlide132

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”Slide133

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 readerSlide134

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 shipSlide135

Define the “Business Event”The Description

Change

Business Tempo

New

Information

Demand

A Response

Abstract

Business speakSlide136

Define the “Business Event”Potential sources of business events

External

Customers

Government

Trading Partners

Advisories

InternalUse this category carefully (1000 person company rule)

Analyze decision making resultsTemporalUsually derivable from an External SourceBusiness cycle (end of period accounting)Technical cycle (machinery / production / …)Slide137

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 ResponsibilitiesSlide138

Representative scenarios are carefully selected to represent the “important” activities of the businessScenarios frame the problem or issue being addressed by the development effortScenarios 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 scenariosSlide139

Problem: Select scenarios that permit the identification of all of the operational capabilities of the system.

Define the Representative Scenarios

Problem of defining scenariosSlide140

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 scenariosSlide141

Tightly woven story based upon the interaction of a few critical operational conceptsTool 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 scenarioSlide142

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!Slide143

Write a story in English proseAvoid technical jargonUse business jargonAvoid 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 scenarioSell, sell, sell!Define the Representative ScenariosScenario writing rulesSlide144

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 exampleSlide145

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 ResponsibilitiesSlide146

...

Scenario

Behavioral Requirements

Functional

Requirements

Functional

Requirements

Functional

Requirements

Constraint

Requirements

Define the Operational Capabilities

Operational Capabilities Flow From ScenariosSlide147

Structures

Functions

Behaviors

Define the Operational Capabilities

A Three View Model of Operational CapabilitiesSlide148

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 viewsSlide149

Frequently (and incorrectly) considered the “Architecture”Generally presented as annotated (noun phrase) block diagrams From business viewpointEngineering 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 GuidelinesSlide150

Generally presented as descriptive or prescriptive verb phrasesCan 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 GuidelinesSlide151

Generally presented as conditional phrasesShould 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 GuidelinesSlide152

Behaviors can have namesBehaviors can associate hierarchicallyA named behavior is a ModeA 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 ModesSlide153

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 StatesSlide154

RepelState

Employ

Resources

Allocate Resources

According to Plan

Retrieve Attack

Specific Operations

Plans

Locate Available

Resources

Analyze Impact

Resource Re-Allocation

Re-Assign

Applicable

Resources

Define the Operational Capabilities

An example of States and Modes - FunctionsSlide155

Verify and Validate CONOPSInitial Conceptual Design Always Requires Refinement

Refinements

Conceptual

Analysis

Goals

CONOPS

Some ChecklistsSlide156

Verify and Validate CONOPSBasic Concepts Checklist

Metaphors make sense to users

Language understandable to users

Users believe goals accomplishedSlide157

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 PresentUsers believe they can execute scenarios

Users have walked through each scenario

Users have confirmed proper handling of

business

eventsSlide158

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 consequencesComplete Users can accomplish intended use with these capabilitiesSlide159

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 maintenanceInsure that sufficient legal and accounting scenarios existEnsure complete coverage of all aggregate capabilities

Slide160

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 issuesEnvironmentPublic safetySlide161

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 problemsSlide162

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 ConsequencesDefine severity of Unintended ConsequenceHave them check your workSlide163

Verify and Validate CONOPS Security Checklist

Scenarios

Vulnerability analysis (Conceptual FMEA)

Policy conformance

Operational Capabilities

Certification implications

Structure

FunctionsBehaviorsVulnerability analysis (Design FMEA)Incident response capabilities present and adequateSlide164

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 CapabilitiesDesign FMEADesign Safety Analysis

Design Maintainability Analysis

Design Performance Analysis

Maintainability CapabilitiesSlide165

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 CapabilitiesTraditional (As-Is) provisioningWhere does the information resideWhere does the structure resideWhat is the profit to provision operational capabilitiesWhat is the cost of provision operational capabilitiesSlide166

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 professorialSlide167

Document CONOPS Widely Accepted Templates

CJCSI 3170.01 B Appendix A to Enclosure E

DI-IPSC-81430 Operational Concepts Desc. (OCD)

ANSI/AIAA G-043-1992

Guide to preparation of OCD

IEEE Std. 1362-1998

System Definition-ConOps

NASA DI-P100

Concept Data Item Description

DI-MCCR-80023

Concepts of Operations Document

Software Productivity Consortium

SPC-98071-MC, OCD Template

Tenix Defense Systems

Development of Operational Concepts DescriptionsSlide168

Document CONOPS Crude ComparisonSlide169

Document CONOPS Essential template

CONOPS

Scope:

Identification

System Overview

Document Overview

Problem Description:

Current Business Situation

Business Problem

Goals / Objectives for Solution

Documents:

Referenced

Operational Scenarios:

Key business events

Anomalies

accounted for

Selected representative

System Concepts:

Intention (Intended use)

Roles Activities

Docs Relationships

Operational Capabilities:

Structure

Behaviors

Functions within BehaviorsSlide170

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 implementationSlide171

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 modelSlide172

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 participateSlide173

Some Useful Heuristics

Know the business and how it earns profit

Users as a integral part of the CONOPS team

Beware of user inputsSlide174

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 informationSlide175

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 CONOPSSlide176

Engineering is an Associative BehaviorThe Role of Doctrine

MIT

eBusiness

Process Handbook

Microsoft Patterns and Practices

RosettaNet

EDICollaborative Process Patterns for e-Business

Look in the LiteratureSome Useful Heuristics

Your cleverness conditioned by experienceSlide177

Session 4An Example

Illustration of some of the elements of a conceptual designSlide178

Topics For Session 4Example

The CONOPS

The System Requirements Specification

The ArchitectureSlide179

An ExampleWeb Provisioning

Specification

Status

ProductSlide180

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 ResponsibilitiesSlide181

An ExampleDefine 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. Slide182

Intention

Buy neat, affordable stuff that I have a role in ‘designing’

Make neat stuff

Make money

Beat the competitionSlide183

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 ResponsibilitiesSlide184

Roles

Product Requestor

Transaction Modeler

Product Maker

Component Maker

TransporterSlide185

Responsibilities / ActivitiesActivities

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 partsShip productBill for the product Receive the product and insure correctnessPay the bill

Produce research materials (quotes)Slide186

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 ResponsibilitiesSlide187

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 itemSlide188

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 reportSlide189

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 ResponsibilitiesSlide190

Define the Representative ScenariosProduct 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 RequestorSlide191

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 ResponsibilitiesSlide192

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

CapabilitySlide193

Define Operational CapabilitiesModes 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 scheduleSlide194

Define Operational CapabilitiesFragment 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

OptionsSlide195

Define the Operational CapabilitiesOperational 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# jacksReport: 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 productSlide196

Define the Operational CapabilitiesBusiness Information

Defining

Needs

General Product

Search Form

General Product

Availability

Report

General Product

Inventor Including

User Level

Characteristics

Repository of Previous Search RequestsSlide197

Verify and Validate CONOPS

Political Concept Correct?

Acceptable to User?

Acceptable to Business?

Interoperability Accomplished?

Undesirable Consequences Compensated?Slide198

Verify and Validate CONOPSPolitical Concept Correct?

Concept avoids “curse of dimensionality”

Product Maker is “middleman” or coordinator

There is a political problem, can you “see” it? Slide199

Verify and Validate CONOPSAcceptable 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 orderInformation 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 RoleSlide200

Verify and Validate CONOPSAcceptable 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 GoalsOops – Missing Role: Government RegulatorsComplies with regulationsMaximizes Tax, etc. revenueSlide201

Verify and ValidateInteroperability 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!Slide202

Verify and ValidateUndesirable 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!Slide203

Verify and Validate CONOPSLet’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 profitSlide204

Verify and Validate

CONOPS

Customer

finds features they want – Information Check

Results

Required Information:

Product specification form

Product features form

Product availability / options report

Repeat analysis for intention, roles, activities, relationships…Slide205

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…Slide206

Verify and Validate CONOPSLet’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??Slide207

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…Slide208

Document CONOPSTopics

CONOPS Outline

SRS Outline

Architectural Artifacts

OV-1

OV-2

OV-3OV-4

OV-5OV-6bOV-7Slide209

Document CONOPSCONOPS Outline Sketch

CONOPS

Scope:

Identification

System Overview

Document Overview

Problem Description:

Current Business Situation

Business Problem

Goals / Objectives for Solution

Documents:

Referenced

Reference

Operational Scenarios:

Key business events

Anomalies planned for

Selected representative

System Concepts:

Intention (Intended use)

Roles Activities

Docs Relationships

Operational Capabilities:

Structure

Behaviors

Functions within BehaviorsSlide210

Document CONOPSCONOPS - 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 purposeSlide211

Document CONOPSCONOPS - 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 customerPartners more easily interact with usSlide212

Document CONOPSCONOPS - 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…Slide213

Document CONOPSCONOPS - References

Documents:

Referenced

Established Industry Standards

Established Industry Specific Trade Agreements

Reference

Architectural Process of the yearSlide214

Document CONOPSCONOPS - 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 Slide215

Document CONOPSCONOPS - 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.Slide216

Document CONOPSCONOPS - 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

Report…Slide217

The System Requirements Specification

The System Requirements SpecificationSystem Requirements Specification Outline

1. Introduction

4. System Interfaces

3. System Capabilities

2. General System Description

IEEE Std 1233, 1998 EditionSlide219

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

CONOPS Scope

Documents:

Referenced

Established Industry Standards

Established Industry Specific Trade Agreements

Reference

Architectural Process of the year

CONOPS DocumentsSlide220

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 Constraints2.6 User Characteristics

2.7 Assumptions and Dependencies

2.8 Operational Scenarios

SRS General Sys Desc

System Concepts

Operational Capabilities

Representative Operational ScenairosSlide221

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 SustainmentSRS System Capabilities…

Operational Capabilities

Representative Operational Scenairos

Section 3.2 in particular is organized by capabilitySlide222

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

Package system requirements by operational capability!Slide223

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

Package system requirements by operational capability!Slide224

The Architecture

The ArchitectureArchitecture – OV-1

Specification

Status

Product

Viewpoint: Mission IntentionSlide226

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 formSlide227

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 responseSlide228

The Architecture Architecture – OV-4

Viewpoint: Role to Role Relationship

Order placement

Order fulfillmentSlide229

The Architecture Architecture – OV-5

Request Search Form

Submit Search Form in Context

Perform Search

Report Parts Found

Select Parts

Accept Order

Viewpoint: Role to Activity and Activities PerformedSlide230

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 GroupingSlide231

The Architecture Architecture – OV-7

Product Specification Form

Product Features Form

Price Estimation Report

Customer specifies general product features

Customer specifies customizable

product features

Customized product has an

estimated price until purchasedSlide232

Conclusion

System Engineering

Can Be AffordableSlide233

Keep Conceptual Design AbstractSoon Be Able To Implement Directly!

Conceptual

Problem Definition

Concept of

Operations

(CONOPS)

Software

Auto-Generation

Hardware

Fabricator

SystemSlide234

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 ResponsibilitiesSlide235

2012

Joseph F Iaquinto,

The Toy Example

The

Auto-MowerSlide236

Success!

The Conceptual Design - PowerPoint Presentation

The Conceptual Design - PPT Presentation

Share:

Link:

Embed:

Related Contents