2003, Northrop Grumman Corporation Fundamentals of SE Objectives After completing this module, you will be able to: Define key Systems Engineering

2003, Northrop Grumman Corporation

Fundamentals of SE Objectives

After completing this module, you will be able to:

Define key Systems Engineering concepts and terms

Explain the role of a Systems Engineer

Explain how Systems Engineering is enabled at TASC

Explain what a life cycle is and approaches to selecting life cycles

Explain the importance and use of tailored processes


What is a System?

System: Integrated set of interrelated components that interact in an organized fashion toward a common objective

Systems Thinking: Taking a “big picture” or holistic view of large-scale and complex problems and their proposed solutions

Systems can be classified by their purpose:

Product-oriented Service-oriented Process-oriented

Can you identify some other examples?


Every System has Subsystems

Because systems are inherently complex, systems can be better understood by organizing their parts into hierarchies and groups based on function

Virtually every system can be broken down into segments, subsystems, components,…

Relationships among the components are what give systems their added value

Since components are related, if one changes it may change other components of the system

Adapted from: INCOSE SE Handbook, pg. 10

System

Segment n

Subsystem nSubsystem 1

Assembly nAssembly 1

Component nComponent

1

Part n

Part 1“The whole is more than the sum of its

parts, the part is more than a fraction of the

whole.” -- Aristotle

Segment 1

Subsystem nSubsystem 1

Assembly nAssembly 1

Component nComponent

1

Part n

Part 1

System Hierarchy


Typical System Composition

System

Hardware Software Personnel Facilities

Data Materials ServicesTechnique

s


System of Systems…The Big Picture Every system is part of a larger system and has boundaries and elements external to

it. The system boundary depends on one’s perspective. System of Systems: Interoperable group of systems sharing a common architecture

Components: The operating parts of the system

Relationships: the links between components, such as the communications and flow between components

Interface: The place at which systems meet and act on or communicate with each other

Subsystem

Subsystem

Subsystem

System A

Subsystem

System B

Subsystem

System of Systems

Environment

Component

Relationship

Interface

Boundary


Every System has Stakeholders

Stakeholder: Individuals, groups, or organizations having: – A vested interest in the system being developed

– Resources (money, people, political clout, etc.) to influence the outcome or end result of the system

Stakeholder influence can be real or perceived

Stakeholder needs can be categorized as current and future “must haves”, “nice to haves”, and “pie in the sky”

Some Examples:

Stakeholders are the primary and most important source of requirements.

Customers OthersUsersDevelopers


Manage Stakeholder Expectations

Stakeholder Attributes include:

Position

Status

Control

Influence

Responsi-bilities

ActionsDislikes/Fears

StakeholdersName and Title

TheirPriorities

LikesAttributes

Stakeholder management must be done throughout the project/program

and reassessed over time

Access to resources

Autonomy

Comfort

Future prospects

Income

Challenges

Opportunity to succeed

Working relationships


Every System has a Life Cycle

Life Cycle: Categorization of systems development activities into distinct, controllable phases

All systems follow a general life cycle from concept definition through development and testing to deployment, operations, and deactivation

You need to have knowledge in the overall approach no matter where you work in the life cycle since you are impacted by previous phases and have impact on following phases. In addition, feedback and iterations between

phases is common.

Adapted from: Systems Engineering, Coping with Complexity, pg. 8

Operations & Maintenance,Deactivation

User’s Needs, Requirementsand Approval

System Requirements

Architectural Design

Component Development

Integration and Verification

Installation and Validation

Change & Feedback

Change & Feedback

Change & Feedback

Change & Feedback

Change & Feedback

ReviewComponent

DeliveryReview ReviewAcceptance

TestSystems

Test

Concept Concept DefinitionDefinition

Development/AcquisitionDevelopment/Acquisition DeploymentDeployment OperationsOperations

Change & Feedback

CAUTIONCAUTION


Constructing Your View of the System

What is in your system? (Hint: look at products, people, decisions, deliverables, etc.)

What are the internal processes? (Hint: What do you and the people you work with do during the day?)

What are the products? (Hint: What do you produce that ends up part of the system?)

Who is the customer for the system? (Hint: who controls the money or wants your product?)

Who are the stakeholders of the system? (Hint: who is also effected by or can affect the system)

What is the environment in which your system is developed and used? (Hint: you are influenced by it but may not have control over it)

How does your system fit into the system of systems? (Hint: what systems are related to or interface with your system, what larger system is your system a part of)


Industry Definitions of Systems Engineering

“An interdisciplinary approach and means to enable the realization of successful systems.” – INCOSE

“The interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a product solution and support that solution throughout the product’s life cycle.” – CMMI

“Creating effective solutions to problems and managing the technical complexity of the resulting developments.” – Coping with Complexity

“An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability” – IEEE 1220


Systems Engineering Focus

Defining customer needs and required functionality early in the development cycle

Developing and managing requirements and interfaces

Synthesizing designs and validating system

Considering the complete problem to be solved, including:

– Acquisition Approach and Management

– External environment/influences

– Stakeholders

– Requirements

– Performance

– Cost and Schedule

Considering both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs

– Technology

– Manufacturing

– Test

– Training and Support

– Operations and Maintenance

– Disposal

SE is an overarching discipline, to achieve the best overall product and/or service that meets requirements and does so within budget

and schedule constraints.


Systems Engineering Processes

Systems Engineering Processes: Logical, systematic, comprehensive, iterative problem solving activities tailored and used to accomplish systems engineering tasks and generate work products

Risk Management

Scheduling

Decision Analysis

System Architecture

Quality

Configuration Management

Information Management

Cost Estimation

Requirements Development & Management

Integrated System Security

Measurement & Analysis

Integration, Verification, Validation, & Transition


What is a Systems Engineer?

Systems Engineer: Defines, develops, and deploys solutions using systems engineering processes

Role of the Systems Engineer:

– Is involved in developing the system from day one on

– The level of systems engineering effort applied depends on our role with the customer and contract

• If the developing contractor, we employ systems engineering techniques

• If in a role supporting a customer organization (SETA), we provide SE oversight and SE management

– In either role we drive decision making through quantitative and qualitative formulation, analysis, and interpretation of the impacts of alternatives

Systems engineering is not just a role for a specialist group of people, but a part of the work of every individual working in the system

development.


Systems Engineer Responsibilities

Serve as Chief Communicator and

Honest BrokerLead Proactively

Guarantor of Success of the Entire System and Maintainer

of System Perspective

Provide factual Provide factual recommendations recommendations

that support that support decision makingdecision making

Provide factual Provide factual recommendations recommendations

that support that support decision makingdecision making

Enforce Enforce the Program the Program

Decision Making Decision Making DisciplineDiscipline

Enforce Enforce the Program the Program

Decision Making Decision Making DisciplineDiscipline


Class Discussion: How do you know a good Systems Engineer when you see them?

People skills– Communicator

– Team player

– Perceptive

– Diplomat

– Referee

Technical Domain skills– Big picture and long term thinker

– Analyst/Technologist

– Commercial standards and trends

Environmental knowledge skills– Program Office environment factors

– Stakeholders

Management skills– Objective decision maker

– Risk management

– Configuration management

The job is challenging.

P

T E

M

– Intellectually curious– Sales person– Listener– Negotiator– Customer focused

– Requirements management

– Integrated schedule management


When SE Processes are NOT Effectively Managed…

Only 16% of all Information Technology (computer and software) projects complete on time and on budget

31% are cancelled before completion

The remaining 53% are late and over budget, with the typical cost growth exceeding the original budget by more the 89%

– Average overrun of project budgets was 189%

– The average schedule overrun for projects that were in difficulty was 222%

Of the IT projects that are completed, the final product contains only 61% of the originally specified features

If no formal systems engineering effort is included, projects run the risk of 50% to 100% development cost overruns

“Charting the Seas of Technology: The CHAOS Study”

Report of the Defense Science Board Task Force on Defense Software, November 2000, INCOSE Systems Engineering Handbook


As you recall, every System has a Life Cycle

Life Cycle: Categorization of systems development activities into distinct, controllable phases

All systems follow a general life cycle from concept definition through development and testing to deployment, operation, and deactivation

Adapted from Systems Engineering, Coping with Complexity, p. 8



System Requirements





Change & Feedback

Change & Feedback

Change & Feedback

Change & Feedback

Change & Feedback

ReviewComponent

DeliveryReview ReviewAcceptance

TestSystems

Test

Concept Concept DefinitionDefinition Development/AcquisitionDevelopment/Acquisition DeploymentDeployment OperationsOperations

Change & Feedback

Simple Life Cycle


Selecting a Life Cycle Model

Basic models can be enhanced or combined to accommodate different situations and needs

Selection considerations include:

– Solution development approach

– Timeline for deployment

– Status of requirements

Some common life cycle models in use are:

– V-diagram

– Sequential/Waterfall

– Incremental

Different models offer advantages and disadvantages

– Risk sensitivity

– Complexity of the system

– Stability of environment

– Evolutionary

– Spiral

Life Cycle Models are used to define different frameworks for phasing systems development or project activities.


V-diagram form of Simple Life Cycle

The Simple Life Cycle can be reorganized as a V-diagram to emphasize:– Verification between phases, checking what has been built against its

requirements

– Validation as end-to-end verification ensuring that the complete system meets the users needs

– Decomposition and definition of what is to be built

– Integrating and verifying what has been built

Integrated ComponentsIntegrated

ComponentsComponent

DevelopmentComponent

Development

Integrated Subsystems Integrated

Subsystems

Verification

Validation

Verification



Operational Capability

Operational Capability

System Requirements

System Requirements

Integrated System

Integrated System



Verification

Adapted from Systems Engineering, Coping with Complexity, pp. 8, 160

Inte

grat

ion

&

Ver

ifica

tion

Inst

alla

tion

& V

alid

atio

n

Defining what is to be built

Integrating, verifying, & validating what has been built

Verification

Verification

VerificationSystems Engineering

Development and Fabrication


Sequential/Waterfall Model

Project activity flows from top to bottom in discrete, sequential, linear phases

Original model did not allow for feedback loops; once the requirements are written, changes would be an unplanned activity

Later modifications incorporated feedback loops

Best used when:• Simple system with small number of alternatives

and low risks• Requirements are known and well defined at the

beginning• Cost, technical, and schedule baselines are stable • Delivery is of one single product at one time

Component DevelopmentComponent

Development



System Requirements

System Requirements



Change & Feedback

Change & Feedback

Change & Feedback



Integration & Verification


Installation & Validation


Change & Feedback

Change & Feedback

Change & Feedback



Incremental Model

Architecture and requirements of system are well defined and remain fixed throughout

Design is implemented in increments

Each increment provides useful operational capability with successive increments contributing ever greater functionality

Partial solution might cover:

– Part of the functionality

– All functionality with limited performance

– Implementation at a limited number of operational locations

Best used when:• System is well defined from the beginning• Full finance is not immediately available and time to market is important• There is a smaller initial demand• System has multiple deliveries where each adds incrementally more functionality



Part 1


Part 1



System Requirements

System Requirements

Operations

1

Operations

1


Part 1


Part 1


Part 1


Part 1

Operational System

Time


Part 2


Part 2Operations

2

Operations

2


Part 2


Part 2


Part 2


Part 2


Part 3


Part 3Operations

3

Operations

3


Part 3


Part 3


Part 3


Part 3




Evolutionary Model

Best used when:• Requirements are not completely known or defined at the beginning• Users need to see some early version of system to better understand requirements• System is first of a kind, has complex interfaces, or is part of a rapidly changing environment• Successive product deliveries with increasing capability over time

The final design is not necessarily well-defined early in the process

Basic life cycle is repeated to deliver successive versions and ever-increasing functionality of the product with an operational period to review them and gain feedback

First versions are small and get product into use

System is gradually evolved to a final design

Allows for evolution in technology, requirements, and environment



Development

System Reqs

System Reqs


Integration & Verification Installation

& ValidationInstallation & Validation

Operational System

Time

Arch DesignArch

DesignOperations

3

Operations

3

User Reqs

User Reqs


Development

System Reqs

System Reqs




Arch DesignArch

Design

Operations

2

Operations

2

User Reqs

User Reqs

Feedback from system 2


Development

System Reqs

System Reqs




Arch DesignArch

Design

User Reqs

User Reqs

Operations

1

Operations

1



Spiral Model Combines the evolutionary model with

risk assessment

Philosophy is “system development is risky, know the risks”

Incorporates prototyping as a risk reduction strategy

The spiral repeats a basic 5 step iterative sequence:

1. Identify the objectives, alternative, constraints and requirements

2. Evaluate and assessment alternatives, identify and resolve risks

3. Design, develop and verify the product

4. Plan the next cycle

5. Review the results of the current cycle

Plan next phases

Review

Boehm, Barry, “Spiral Development: Experience, Principles, and Refinements” Special Report, CMU/SEI-2000-SR-008, 2000, p. 2, http://www.sei.cmu.edu/cbs/spiral2000/february2000/SR08.pdf

Best used when:• Program or product contains high risks• Incremental capability levels are specified• Multiple product deliveries over time

Develop, verify next

level product

Evaluate alternatives;

identify, resolve risk

Determine objectives,

alternatives, constraints

Focus on Risk Management


Life Cycle Model Pros & Cons

Models Pros Cons

Sequential/

Waterfall

Good visibility and control; fully documented; structured process

Serial activities; inter-step dependency increases risk; risk management is minimal; requires large amounts of documentation; problems identified late are expensive to fix

Incremental

When requirements are well known allows early delivery of partial capability; mitigates risk through incremental development; allows some “fine tuning” of requirements

Requires architecture and requirements to be well defined from the beginning; requires efficient CM to control multiple deliveries.

Evolutionary

When requirements are not well know allows early delivery of partial capability; early realistic feedback; early error detection at lower cost; allows for evolution and incorporation of changes in technology, requirements, and environment

Downstream changes can be expensive to retrofit to earlier products; relies on high levels of stakeholder feedback; limited planning horizon; requires efficient CM to control multiple deliveries

Spiral

Handles volatile baselines; employs continuous risk management

Less visibility and control; Need skillful practitioners; the many steps involved can cause cost and schedule problems; hard to tell when finished


Nesting and Combination of Life Cycles

For large systems, multiple models can be used for different components, or during different phases, or combined into hybrid models

Project A Project B

Project C

System Life CycleSystem Life Cycle

Project D





System Requirements

System Requirements



Change & Feedback

Change & Feedback

Change & Feedback







Change & Feedback

Change & Feedback

Change & Feedback


Part 1


Part 1



System Requirements

System Requirements

Operations

1

Operations

1


Part 1


Part 1Installation &

Validation

Part 1


Part 1

Operational System


Part 2


Part 2Operations

2

Operations

2


Part 2



Validation

Part 2


Part 2


Part 3


Part 3Operations

3

Operations

3


Part 3



Validation

Part 3


Part 3





System Reqs

System Reqs



& Validation


Operational System

Arch Design

Arch Design

Operations

3

Operations

3

User Reqs

User Reqs



System Reqs

System Reqs


Integration & Verification Installation &

Validation


Arch Design

Arch Design

Operations

2

Operations

2

User Reqs

User Reqs




System Reqs

System Reqs



& Validation


Arch Design

Arch Design

User Reqs

User Reqs

Operations

1

Operations

1



Exercise:

Life Cycle Models


Life Cycles, Reviews, and Control Gates

System development progresses from an abstract need to a product with form and function

A life cycle model identifies phases and activities

Each phase ends with a review and/or control gate

Reviews and control gates are the checks and balances

– Reviews: examine the deliverable work products and determines if program ready to move to the next phase

– Control gates: provide a go/no go decision point based on transition criteria

Provides management a decision point to proceed to the next phase or return to the previous one to resolve issues


Example Life Cycle Reviews and Control Gates



Systems Requirements





System Requirements

Review(SRR)

Contract Implementation

Review(CIR)

Operations Transition

Review(OTR)

Segment Requirements

Review(SRR)

Test Readiness

Review(TRR)

Critical Design Review(CDR)

Preliminary Design Review

(PDR)

Pre-Ship Review(PSR)

Operational Readiness Review

(ORR)

Formal Qualification

Review(FQR)

Installation Status Review

(ISR)

Test Readiness

Review(TRR)

Tailoring of the life cycle reviews and control gates depends on program size, complexity and scope

Concept Concept DefinitionDefinition Development/AcquisitionDevelopment/Acquisition DeploymentDeployment OperationsOperations



References

TASC ISM Web Page

– http://www.corp.tasc.com/processes/ism/index.shtml

TASC Life Cycle Readiness Process Resource Package

– http://www.corp.tasc.com/processes/ism/lcr/index.shtml

TASC INCOSE Links

– http://myweb.corp.tasc.com/INCOSE/

International Council on Systems Engineering (INCOSE) Web Page

– http://www.incose.org/

Capability Maturity Model-- Software Engineering Institute

– www.sei.cmu.edu

NGIT OWD

– http://inside.it.northgrum.com/owd/

Life Cycle Models

– http://www.cs.ualberta.ca/~sorenson/cmput401/lectures/SWLifeCycle/

– http://www.cs.qub.ac.uk/~J.Campbell/myweb/misd/node3.html

– http://www.levela.com/software_life_cycles_swdoc.htm

– http://www.sei.cmu.edu/cbs/spiral2000/

Documents

2003, Northrop Grumman Corporation Fundamentals of SE Objectives After completing this module, you will be able to: Define key Systems Engineering