The Conceptual Design Including The Concept Of Operations

May 14, 2012

The Conceptual Design

Featuring

The Concept Of Operations

A Tutorial

By

Joseph F Iaquinto, PE

May 14, 2012

© 2012 Joseph F Iaquinto, PE

1

Introduction

May 14, 2012


2

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


3

Introduction

Conceptual design as a u seful abstraction

4

• Useful to customer in directing the construction of the artifact

• Useful to tradesmen for making detailed implementation decisions

May 14, 2012


Overview of CONOPS Templates

Essential template

Scope:

Identification

System Overview

Document Overview

System Concepts:

Intention (Intended use)

Roles Activities

Docs Relationships

CONOPS

Problem Description:

Current Business Situation

Business Problem

Goals / Objectives for Solution

Operational Scenarios:

Key business events

Anomalies accounted for

Selected representative

5

Documents:

Referenced

Operational Capabilities:

Structure

Behaviors

Functions within Behaviors

May 14, 2012


Introduction

CONOPS – The Key Concepts

Mission or

Intention

Roles

Information

Required

6

May 14, 2012

Relationships

Operational Capabilities


Introduction

Elementary Example – System Definition

7

May 14, 2012


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

May 14, 2012

– Management of problem solving teams


8

Introduction

Conceptual Engineering Fallacies

9

•

Architecture as Implementation

•

OO vs. Procedural vs. SOA

•

Systemantics

May 14, 2012


A Process for doing the conceptual design

(CONOPS)

Define the Problem

Define the

Roles and Responsibilities

May 14, 2012

Define the Business Events

Define

Representative Scenarios

Define Structure,

Function, Behavior

Organize Functionality

Into States and Modes


Define


10

Introduction

Example: Web Provisioning

Specification

Status

11

May 14, 2012

Product


Introduction

Not limited to IT systems!

12

May 14, 2012


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)

13

May 14, 2012


Introduction

Ground Rules

• Each Session

– 50 Minute formal lecture

– 10 Minute break every hour

May 14, 2012


14

May 14, 2012

Session 1

What is a conceptual design and who cares?


15


Avoiding Brook’s “law”: “All major mistakes are made on the first day of the project”!

May 14, 2012

Fred Brooks, The Mythical Man Month, ISBN: 0201835959


16

Topics of Session 1


• 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

17

May 14, 2012


Motivation – When is a CONOPS needed

We have a problem

18

May 14, 2012


Motivation – When is a CONOPS needed

This problem has become visible

19

May 14, 2012


Motivation – When is a CONOPS needed – Test 1

20

Is there ambiguity?

May 14, 2012


Motivation – When is a CONOPS needed – Test 2

21

Will the product serve diverse needs?

I want to start my 5 HP

Engine with the push of

SE: a button.

Voltage = 12 V

Capacity = 40 AH

Form Factor =

10x10x10 cm

Battery Engineer:

While camping, I want to be able to read all night by the illumination of a

60 watt bulb.

SE:

Voltage = 12 V

Capacity = 40 AH

Form Factor =

10x5x2 cm

Chemistry?

Internal Construction?

Recharge CONOPS?

May 14, 2012


Motivation – When is a CONOPS needed– Test 3

22

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


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.

23

May 14, 2012



Establish The Goal

The conceptual model is the reference / touchstone that is used to coordinate all technical and political activity on the project.

24

May 14, 2012



Create Coordination

Requires a single mind that conceives, communicates, adjudicates and enforces the fundamental technical and political approach to solving the operational problem

25

May 14, 2012



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

26

May 14, 2012



Example of Conceptual Integrity - Software

Jack

Make

Tracking

Sheet with color code

Joe

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.

27

May 14, 2012

Amanda


Rick


Example of Conceptual Integrity - Hardware

Blowback design ok if:

1.

Use stick powder

2.

Clean Frequently

Need to be cheap(?):

1.

Use ball powder

2.

Never needs cleaning

28

May 14, 2012


Definition of Conceptual Design

From some CONOPS standards

• A useroriented 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

29

May 14, 2012



Some excellent references

Frederick J Brooks, “The Mythical Man-Month:

Essays on Software Engineering, Anniversary

Edition”, Addison-Wesley Press, ISBN 0-201-

83595-9

Johnson & Henderson in “Conceptual Models:

Begin by Designing What to Design”,

Interactions, January + February 2002

30

May 14, 2012



Foundation for Artifacts

CONOPS

Architecture

System Requirements Specifications

31

Conceptual Design

May 14, 2012



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

32

Interpretation of: Johnson & Henderson in “Conceptual Models: Begin by Designing

What to Design, Interactions, January + February 2002

May 14, 2012



Fundamentals: Example of a metaphor

33

A purposeful cross domain mapping

Can be used to set the conceptual goal or purpose of the system

May 14, 2012

(Mapping: farm (inexpensive (of reliable but inconsistent conformation), frisky workhorse) -> machinery

(automobile))



Fundamentals: Example of a Mapping

34

May 14, 2012

•Visit Grandma

•Grocery shop

•Go to work


Movement


Fundamentals: Example of Relationships

35

May 14, 2012

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)



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


36


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

IEEE

1471

37

INCOSE

SE Handbook

May 14, 2012

Concept of Production

Concept of Deployment

Concept of Operations (ConOps)

Concept of Support

Concept of Disposal


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

38

May 14, 2012



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


39

Recipe for a CONOPS – The Key Concepts

Mission or

Intention

Roles

Information

Required

40

May 14, 2012

Relationships



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


41


The Roles

Users

People who support the system

42

May 14, 2012

Client


People who are affected by the system


Information Required

May 14, 2012

Analogies

Information

(

Documents/Forms

)


43


Activities / Scenarios (system engineering, not OOA)

44

• 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



Deriving the Operational Capabilities

Intention

+

Role

+

Activities

Capabilities

45

May 14, 2012


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

46

May 14, 2012


Aside:

Engineering Design Process Applies To CONOPS

47

The difference is only a matter of level of abstraction

Define the problem

Reformulate to match design heuristics

Associate,

Associate,

Associate

Synthesize the overall solution

Subproblems with known solutions

May 14, 2012

Refine the solution (test & rebuild)

Monitor the solution in full operations


Update design heuristics / known solutions

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 Definition-

Concept 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

48

May 14, 2012


Where Conceptual Design Fits Into System

Engineering Process

49

Capabilities

System

Requirements

CONOPS

Components &

Relationships

System

Architecture

May 14, 2012


Where Conceptual Design Fits Into System

Architecture Process (DODAF)

CONOPS

50

Operational Information Exchange Matrix

Operational Concept Graphic

May 14, 2012

Operational Node Connectivity Diagram


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)

51

Mapping requires judgment and skill

May 14, 2012


May 14, 2012

Session 2

Principles and Fallacies of Conceptual Design


52


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


53

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

54

May 14, 2012


Think “User Viewpoint”

Intended Use Centric

• Capture manner of customer’s circumstance

– Language

– Intentions

– Historical Perspective

55

May 14, 2012


Magellan 750


Establish Foundation

Acquire “Domain” (User) Knowledge

Acquire “Domain” (User) Experience

May 14, 2012


Judgment

56


Conceptualize in Customer’s Language

57

• 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



Conceptualize in Customer’s Language

58

Parts List

NOT

Aggregation

!

Kinds of Parts

NOT

Generalization /

Specialization

Interconnection

NOT

Association

May 14, 2012



A Counter Example – As found

System

Concepts

Provide

Services

Provide

Worldwide

Access

Dynamic

Collaboration

Enterprise

Management

Dynamic

Resource

Allocation

System

Assurance

59

“Network”

With

Co-workers

Private

Conversations

Knowing

What is

Happening

May 14, 2012



A Counter Example – The reality

System

Concepts

“Network”

With

Co-workers

Private

Conversations

Knowing

What is

Happening

Provide

Services

Provide

Worldwide

Access

Dynamic

Collaboration

Enterprise

Management

Dynamic

Resource

Allocation

System

Assurance

May 14, 2012


60


Be Aware of Implementation Possibilities

61

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

May 14, 2012



A Most Important Architectural Artifact

62

May 14, 2012

User Interface (example: screen shot) is important part of

Conceptual Design and a legitimate architectural artifact!


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


63

Think Critically

Be Argumentative

Controversy

Issue

Issue

Issue

Claim

Claim

Claim

Resolution

Evidence Inference Claim

64

Warrant

May 14, 2012



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


65


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?

66

May 14, 2012



Beware of Conditional Statements

If you abstract applications away from the underlying hardware, then resources can be used more efficiently.

67

May 14, 2012

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!



Consider All Relevant Dimensions

Reusable

Services

Use Rather

Than Code

Restrictive

Association (to services)

Understand

What They Do

Understand How

They Work

68

Component

Change Impact

Test Them Or

Trust Them?

Understanding

Prototypes

May 14, 2012



Use of the Scientific Method

69

May 14, 2012



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

70

May 14, 2012



The Method

•

Problem

•

Hypothesis (Guess)

•

Controlled Experiment

–

Notion of exactly 1 Dependent and exactly 1 Independent Variable!!!!!

–

Control (Independent Variable

Value) Is Mandatory!

71

May 14, 2012



Use of the Scientific Method - Fallacy

Fertilizer Work?

Hole in Ozone Layer?

72

May 14, 2012

Test

Article

Control

Test

Article


Control???


Usefulness of the Scientific Method

Control on left or Right?

Associate Orders or Not?

73

Go

Form for Order Entry

•Function 1

•Function 2

Go

Pizza Order

1 m

Soda Order

May 14, 2012



The Process of Problem Solving

Identify The

Problem

Identify The

Cause

Identify & Remove

Barriers

Gather

Information

Generate

Solutions

Select

Solution

May 14, 2012

Evaluate

Solution

Courage to

Evolve Solution

Genesis of the CONOPS


74


Detect Fallacies – Fallacies of Relevance

75

• 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



Detect Fallacies – Insufficient Evidence

76

• 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



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

77

May 14, 2012



Understand Prejudices Inherent in Customer

78

May 14, 2012

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



Understand “Common” Beliefs in Customer Domain

79

•

Identifying common beliefs

–

Artifacts of technology

–

Artifacts of history

–

Artifacts of personality

May 14, 2012




80

• 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




81

• Artifacts of history

– Law

• Process to accommodate prior laws

• Documents required by prior laws

• Limitations inherited from prior laws

May 14, 2012

– Culture

• Process dictated by religion or “pecking” order

• Documents dictated by philosophy

• Limitations dictated by social relationships (DOD)




82

• 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



Understand Emotional Influences In Customer

83

User

•Fear of job loss

•Fear of prestige loss

•Fear of failure

•Angry at being forced…

•Genuine concern

System Engineer

May 14, 2012



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


84


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


85


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


86


Employ Inductive and Deductive Reasoning

Deductive Thinking • Inductive 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

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

87

May 14, 2012


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


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


89


First Rule: Keep Views Very Simple – Bad Example

90

May 14, 2012



First Rule: Keep Views Very Simple–Better Example

91

JFACC

OV-4 Naval Command Structure

JFMCC

Operational Command / Control

Tactical Control

CSG

May 14, 2012

Air Related Organizations

Carrier Strike Group Organizations

Non Air Related Organizations


From the Tar Pit: Fred Brooks

Basic Concepts

92

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



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

93

Break up the conceptual design effort into parallel teams a BAD IDEA

• Operational (Views)

• System (View)

May 14, 2012



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


94


The Surgical Team

Architect

Administrator

Engineering

Tool Maker

Tech Pubs

•

Maintain Conceptual Integrity

• Multiply Effectiveness of

“Hero”

•

Scales Sufficiently for

Conceptual Designs

May 14, 2012

QA / Test

Domain

Expert


Co-Architect

95


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

96

May 14, 2012


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

97

May 14, 2012



Zachman – “Drowning projects in bubbles and boxes”

98

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



Zachman – “Drowning projects in bubbles and boxes”

99

•

36 Categories of information

•

Planner / owner level all that is applicable

•

Too distracting

May 14, 2012



Instead of Zachman – KEEP IT SIMPLE

100

Conceptual

Design

Intention Information Activities Roles

The

Business

Profit Documents Workflow Personnel

The

Automation

Rationale

May 14, 2012

Data


Capabilities Users/Actors


Lack of Focus In Illustrations

OV-4 Naval Command Structure

JFACC JFMCC

Operational Command / Control

Tactical Control

CSG

101

Air Related Organizations

Carrier Strike Group Organizations

Non Air Related Organizations

What is the point?

Dual Command of Air

Related Operations

Clear Focus On Interoperability Requirement / Challenge

May 14, 2012



OO Versus Procedural Versus SOA…

Orthogonal

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.

102

May 14, 2012

OO / Procedural / SOA are software design methods

OO / SOA is about relating groups of executables

Procedural is about characterizing a single executable



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

103

May 14, 2012



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

VS

• Parts are real, whole has no separate existence

• Concept of whole has no real manifestation

104

May 14, 2012

Further Information:

INCOSE Insight, Volume 7, Issue 2, July 2012, Semantic Dictionary and

Concept Model, Michael Dickerson, David Oliver and Joseph Skipper



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


105


Ontology – Another Confusing Concept

Is addressed by

Stakerholder

Has a

Concern Viewpoint

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


106


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

107

May 14, 2012



Reuse – Is It Worth The Expense?

The Hype of Reuse The Reality 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

108

May 14, 2012


Big

Failure Modes – Systemantics

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

109

May 14, 2012


Big


New Systems Mean New Problems

110

• 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


Big


Systems Tend to Expand to Fill the Known Universe

111

• 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


Big


Complex Systems Exhibit Unexpected Behavior

112

• 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


Big


Systems’ Do Not Naturally Scale

113

• 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


Big Failure Modes – Systemantics

Countering them with FMEAs

114

May 14, 2012


May 14, 2012

Session 3

A Process for Defining a CONOPS


115


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


116

Develop Basic Concepts

Relationships of Fundamental CONOPS Concepts

Business

Problem Leads to

Intention

Executed By

Causes

Activities

(Scenarios)

Roles

Facilitated

By System

Under

Definition

Used

By

Operational

Capabilities

Provides

Utilize

Information

117

May 14, 2012


A Process for defining the CONOPS

Define the Problem

Define the


May 14, 2012


Define







Define


118

Define The Problem In Business Terms

The Single Most Important Concept

119

May 14, 2012



Define the Problem

Define the


May 14, 2012


Define







Define


120

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


121


•

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?

122

May 14, 2012



123

Beware of what people tell you!

May 14, 2012



Define the Problem

Define the


May 14, 2012


Define







Define


124

Define The “Business Event”

Business Events Are Central to Creating

A CONOPS

125

May 14, 2012


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

126

May 14, 2012



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

127

May 14, 2012



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


128


Understanding How Business Reacts to Events

129

Discover the artifact driven reactions

– Interviews (caution)

– “Time and Motion Studies” i.e., observation

– Benchmark (study competitors)

– Read the literature

May 14, 2012



Understanding How Business Reacts to Events

130

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



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

131

May 14, 2012



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”

132

May 14, 2012



Business Event ≠ Technical (system) event – Example 1

133

May 14, 2012

A customer goes to the bank to withdraw money

≠

A customer inserts their

ATM card into the ATM card reader


Define the “Business Event”

Business event ≠ Technical (system) event – Example 2

134

May 14, 2012

A dangerous vessel of unknown intention comes too close to a protected ship

≠

A significant sonar signature occurs on a protected ship



The Description

Abstract Business speak

Change

Business Tempo

New

Information

Demand

A Response

135

May 14, 2012



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


136


Define the Problem

Define the


May 14, 2012


Define







Define


137

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

138

May 14, 2012


Define the Representative Scenarios

Problem of defining scenarios

Problem:

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

139

May 14, 2012



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


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)

141

May 14, 2012


Define the Representative Scenario

Scenario warning – Repeated!

A conceptual scenario is NOT a software

(UML) scenario or use case!

142

• Different Motivation

• Different Level Of Abstraction

• Different Viewpoint

May 14, 2012



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!

143

May 14, 2012



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


144


Define the Problem

Define the


May 14, 2012


Define







Define


145

Define the Operational Capabilities

Operational Capabilities Flow From Scenarios

May 14, 2012

Scenario

Behavioral Requirements

Constraint

Requirements

Functional

Requirements

Functional

Requirements

Functional

Requirements


146


A Three View Model of Operational Capabilities

147

May 14, 2012

Structures

Functions Behaviors



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


148


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

149

May 14, 2012



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)


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

150

May 14, 2012



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)


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

151

May 14, 2012



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!

152

May 14, 2012



Behavior - An example of Modes and States

Command

Communications

System

Normal

Operations

Mode

Crisis

Operations

Mode

Disaster

Recovery

Mode

153

Attack

Classification

State

Repel

State

Resource

Recovery

State

May 14, 2012



An example of States and Modes - Functions

Repel

State

Retrieve Attack

Specific Operations

Plans

Allocate Resources

According to Plan

Employ

Resources

154

Locate Available

Resources

Analyze Impact

Of

Resource Re-Allocation

Re-Assign

Applicable

Resources

May 14, 2012


Verify and Validate CONOPS

Initial Conceptual Design Always Requires Refinement

155

May 14, 2012

Refinements CONOPS

Conceptual

Analysis

Some Checklists



Basic Concepts Checklist

Metaphors make sense to users

Language understandable to users

Users believe goals accomplished

156

May 14, 2012



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


157


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

158

May 14, 2012



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

159

May 14, 2012



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

– Sociopolitical “profit”

• Popular social issues

• Environment

• Public safety

May 14, 2012


160


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

161

May 14, 2012



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

162

May 14, 2012



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

163

May 14, 2012



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)


– Design FMEA

– Design Safety Analysis

– Design Maintainability Analysis

– Design Performance Analysis

– Maintainability Capabilities

164

May 14, 2012



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


– 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


165

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

166

May 14, 2012


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 Descriptions

167

May 14, 2012


Document CONOPS

Crude Comparison

CJSCI 3170

General

Description of the

Operational Need

(mission, ops support concepts…)

Threat

1. Scope (ID, System

Overview, Document

Overview)

81430

3. Current System or

Situation (Background,

Shortcommings of Policies, description,

Present Systems

Capabilities users, support concept)

Required (sys perf, info exchange req, logistics, environment)

5 Concept for a new or modified system

ANSI

1. Scope (Id, purpose, overvfiew)

4. User-Oriented

Operational Description

5. System Overview

(scope, users, interfaces, capabilites…)

IEEE

1. Scope (id, document overview, system overview)

3. Current System or

Situation

5. Concepts for the proposed system

3. Definition of:

Purpose, scope, goals, description, policies.

NASA

1. Introduction

5. Capabilities and

Characteristics

6 Operational Scenarios 8 Operational Scenarios

7 Summary of impacts

(Operational, organizational, developmental)

8 Analysis of the proposed system

7 Summary of impacts

8 Analysis of the proposed system

80023

1. Introduction

2 Business Need

3. System

Justification

Operational

Objectives and

Missions

4 System Concepts 3 System Description System Description

5 Support

Program Support

Force Structure

Schedule

Program

Affordability

7. Support Environment

2 Referenced Documents 2. Referenced Documents

4. Justification for and nature of changes

2. Referenced

Documents

4 Justification for and nature of changes

2. Related

Documentation

6 Operational Scenarios

6. Sample Operational 5 Operational

Scenarios Scenarios

Environment

2 Referenced

Documents

4 Operational

Scenarios

System Live Cycle

Organizations

Scenarios

6 Business Impacts

1 Scope

SPC TENIX

Legacy Operational

Concepts

6.Operational Environment

4. User Definition

7 Rationale

8 Conceptual Model

May 14, 2012


168

Document CONOPS

Essential template

Scope:

Identification

System Overview

Document Overview

CONOPS



Business Problem


Documents:

Referenced



Roles Activities

Docs Relationships


Key business events

Anomalies accounted for



Structure

Behaviors


169

May 14, 2012


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

170

May 14, 2012


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


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

172

May 14, 2012


Some Useful Heuristics

• Know the business and how it earns profit

• Users as a integral part of the CONOPS team

• Beware of user inputs

173

May 14, 2012



• 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


174


• 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


175


• 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

176

May 14, 2012


May 14, 2012

Session 4

An Example

Illustration of some of the elements of a conceptual design


177

Topics For Session 4

Example

•

The CONOPS

•

The System Requirements

Specification

•

The Architecture

178

May 14, 2012


An Example

Web Provisioning

Specification

Status

May 14, 2012

Product


179


Define the Problem

Define the


May 14, 2012


Define







Define


180

An Example

Define the Problem

A manufacturer of semi-custom goods (computers, watches, automobiles…) wishes to provide a custom order service.

The customer can express their requirements for the product and receive in real time a cost and availability date. Thus, they can tailor the product to suit their needs, budget and expected delivery date.

181

In turn, the company is an assembler of parts fabricated by other supplier companies.

May 14, 2012


Intention

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

May 14, 2012

•Make neat stuff

•Make money

•Beat the competition


182


Define the Problem

Define the


May 14, 2012


Define







Define


183

Roles

May 14, 2012

Product Requestor

Transporter

Transaction Modeler

Component Maker


Product Maker

184

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


185


Define the Problem

Define the


May 14, 2012


Define







Define


186

Define the Business Events

Product

Requestor

Request Product Options

Product Research Results Provided

Request for quote for catalog item

Response to request for quote for catalog item

May 14, 2012

Component

Maker


187

Define the Business Events:

Define the Required Information

May 14, 2012

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


188


Define the Problem

Define the


May 14, 2012


Define







Define


189


• 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

190

May 14, 2012



Define the Problem

Define the


May 14, 2012


Define







Define


191

Define Operational Capabilities

Unusual

Capability

Specifies Desired

Product specification form

Role Invoice

Standard

Capability

Information

May 14, 2012

Warning: Study unusual capability rather than be completely distracted by “standard practice” ones


192


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

193

May 14, 2012



Fragment of Modes and States analysis

May 14, 2012

Defining

Needs

Investigating

Product

Options

Evaluating

Candidate

Product

Product Research Mode

Specify

Product

Options

Specify

Shipping

Options

Specify

Payment

Options

Order Product Mode


194


Operational Functions


– 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

195

May 14, 2012



Business Information

Defining

Needs

General Product

Search Form

General Product

Inventor Including

User Level

Characteristics

General Product

Availability

Report

Repository of

Previous Search

Requests

196

May 14, 2012



• Political Concept Correct?

• Acceptable to User?

• Acceptable to Business?

• Interoperability Accomplished?

• Undesirable Consequences Compensated?

197

May 14, 2012



Political Concept Correct?

198

May 14, 2012

•Concept avoids “curse of dimensionality”

•Product Maker is “middleman” or coordinator

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



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

199

May 14, 2012



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

200

May 14, 2012


Verify and Validate

Interoperability Accomplished

201

May 14, 2012

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


Verify and Validate

Undesirable Consequences Compensated?

May 14, 2012

Request Price

Price Quote = z

Payment = z

Request Component Price

Price Quote = x

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!


202


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

203



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


204


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


205


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

206

May 14, 2012



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


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


208

Document CONOPS

CONOPS Outline Sketch

Scope:

Identification

System Overview

Document Overview

CONOPS



Business Problem


Documents:

Referenced

Reference



Roles Activities

Docs Relationships


Key business events

Anomalies planned for



Structure

Behaviors


209

May 14, 2012


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

210

May 14, 2012


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

211

May 14, 2012


Document CONOPS

CONOPS - Problem Description

May 14, 2012



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


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


212

Document CONOPS

CONOPS - References

Documents:

Referenced

•Established Industry Standards

•Established Industry Specific Trade Agreements

Reference

•Architectural Process of the year

May 14, 2012


213

Document CONOPS

CONOPS - System Concepts



•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


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.


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

215

May 14, 2012


Document CONOPS

CONOPS - 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


•Defining needs

•Search

•Report…

May 14, 2012


216

THE SYSTEM REQUIREMENTS

SPECIFICATION

May 14, 2012


217

The System Requirements Specification

System Requirements Specification Outline

1. Introduction

2. General System

Description

218

May 14, 2012

3. System

Capabilities

IEEE Std 1233, 1998 Edition


4. System

Interfaces


SRS – Introduction

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

CONOPS Documents

Documents:

Referenced

•Established Industry Standards

•Established Industry Specific Trade Agreements

Reference

•Architectural Process of the year

SRS Introduction

1.1 System Purpose

1.2 System Scope

1.3 Definitions, Acronyms

1.4 References

1.5 System Overview

219

May 14, 2012



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

220

May 14, 2012



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

221

May 14, 2012



SRS – 3.2 System Performance Characteristic


– 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

222

May 14, 2012



SRS – 3.3 System Security


– 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

223

May 14, 2012


THE ARCHITECTURE

May 14, 2012


224


Architecture – OV-1

Specification

Status

May 14, 2012

Product

Viewpoint: Mission Intention


225



•Product specification form

•Product features form

•Bill of laden

•Shipping

Options Form

•Price estimate report

•Product catalog

May 14, 2012

•Parts description form

•Parts availability reports

•Request for quote

•Parts order

•Shipping options report

•Shipping cost form

Viewpoint: Relationship of Role to Information


226



Information

Item

Information

Description

Information

Source

Product

Specification

Form

Contains the customer’s product detailed requirements

Product

Requestor

Information

Designation

Transaction

Modeler

Information

Exchange

Attributes

•

HTTPS

• Customer sensitive

•

0.5 second response

227

May 14, 2012

Viewpoint: Information Needed




Order placement

Order fulfillment

228

May 14, 2012

Viewpoint: Role to Role Relationship




Request Search

Form

Submit Search

Form in

Context

Perform

Search

May 14, 2012

Report Parts

Found

Select Parts Accept Order

Viewpoint: Role to Activity and Activities Performed


229


Architecture – OV-6b

Defining

Needs

Investigating

Product

Options

Evaluating

Candidate

Product

Specify

Product

Options

Specify

Shipping

Options

Product Research Mode

Specify

Payment

Options

Viewpoint: Mission Driven

Activity Grouping

May 14, 2012

Order Product Mode


230



Product

Specification Form

1

Customer specifies general product features n

Product Features

Form

1 1

Price Estimation

Report

Customer specifies customizable product features

May 14, 2012


Customized product has an estimated price until purchased

231

Conclusion

May 14, 2012


232

Keep Conceptual Design Abstract

Soon Be Able To Implement Directly!

Conceptual

Problem Definition

Concept of

Operations

(CONOPS)

Software

Auto-Generation

Hardware

Fabricator

System

May 14, 2012


233

A Simple process for doing the conceptual design

234

(CONOPS)

Define the Problem

Define the


May 14, 2012


Define







Define


The Toy Example

The Auto-Mower

235

May 14, 2012


Success!

May 14, 2012


236

The Conceptual Design Including The Concept Of Operations

Introduction

Introduction

Conceptual Engineering Principles

Introduction

Conceptual Engineering Fallacies

Architecture as Implementation

OO vs. Procedural vs. SOA

Systemantics

Introduction

Example: Web Provisioning

Session 1

Initiate Conceptual Integrity

Session 2

The Conceptual Problem

•

Parts List

Aggregation

Kinds of Parts

Generalization /

Specialization

Interconnection

Association

Problem

Hypothesis (Guess)

Controlled Experiment

Notion of exactly 1 Dependent and exactly 1 Independent Variable!!!!!

Control (Independent Variable

Value) Is Mandatory!

Identifying common beliefs

Artifacts of technology

Artifacts of history

Artifacts of personality

Failure Modes – Systemantics

Failure Modes – Systemantics

Failure Modes – Systemantics

Failure Modes – Systemantics

Failure Modes – Systemantics

Session 3

Topics of Session 3

Develop Basic Concepts

Define The Problem In Business Terms

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

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?

Beware of what people tell you!

Business Events Are Central to Creating

A CONOPS

≠

≠

A conceptual scenario is NOT a software

(UML) scenario or use case!

Your role in this is professorial

Session 4

The CONOPS

The System Requirements

Specification

The Architecture

An Example

THE SYSTEM REQUIREMENTS

SPECIFICATION

THE ARCHITECTURE

The Toy Example

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib

**Define The Problem In Business Terms**