SPI 98 Monte Carlo · 2012. 12. 20. · Oerlikon Development and Integration Issues Aerospace SPI...

Development and Integration Issues about Software Engineering, Systems Engineering and Project Management

Processes

Claude Y. Laporte - Process Engineering

SPI 98Monte Carlo

Development and Integration IssuesDevelopment and Integration IssuesOerlikonOerlikonAerospaceAerospace

SPI 98 Monte CarloSPI 98 Monte Carlo

� AGENDA

� Introduction

� Engineering Process Development

� Support Process Development

� Integration Facilitators

� Lessons Learned

� Conclusion



Turn Over OBH19963.6 Billion SFr (US$3.0 B)(15,543 Emloyees)

Oerlikon-Bührle Holding AG, Zürich/CH

Oerlikon-

Contraves

Defence

BallyShoes & Accessories

Balzers & LeyboldVacuum & Coating

Technology

PilatusAircraft & components

ImmobilienReal Estate

Various

Oerlikon

Contraves AGZurich, CH

Air Defense Systems

Fire Control Systems

20-35 mm Cannons

UAVs, Simulators

O-C Pyrotec

AGZurich, CH

20-35 mm Ammunition

Oerlikon

Contraves

S.p.A.Rome, IT

Fire Control Systems

RADARS

Oerlikon

Aerospace Inc.Montreal, CA

ADATS Missile System/

Surface-based Weapon

Systems



�� OERLIKON AEROSPACE OERLIKON AEROSPACE

� System Integrator of an Air Defense System

� Certified as Level 2 - Software Engineering Institute in 1997

�Has also met 8 of the 17 Level 3 Goals

� Peer Review

� Software Product Engineering

� ISO 9001 since 1993

� NATO Secret Organization

� Over 120 Systems and Software Engineers





Need for

Assessment

Fall 92

SeniorManagementCommitment

Fall 92

Preparationfor

AssessmentWinter 93

AssessmentSpring 93

Formulation ofRecommendations

and Action Plansummer and

Fall 93

Implementationof Action Plan(Process Def.)

Winter 94

Pilot Projects1995

SoftwareSoftware ProcessProcess

EngineeringEngineering

Re-Assessment

1999Formal Assessment

Winter 1997



� FIRST LEVEL OF THE PLANNING AND TRACKING PROCESS

Software ProjectPlanning

Process for Proposal(Including Negotiation

Phase)

Software ProjectPlanning

Process (after ContractAward)

Software ProjectTracking Process



� SECOND LEVEL OF THE PLANNING AND TRACKING PROCESS

TO SPP 200

REVIEW PROPOSAL,

RISK ANALYSIS,

ESTIMATES ANDSCHEDULE

SPP-100

PLAN THE PROPOSALACTIVITIES

SPP-110

GENERATE PROJECT

WBS/OBS

SPP-120

PREPARE PROJECT

ESTIMATES ANDSCHEDULE

SPP-130

PERFORM RISK

ASSESSMENT/ABATEMENT

SPP-140

PREPARE PROPOSAL

SPP-150

CONDUCTPROPOSAL

LESSONS LEARNEDREVIEW

After Contract Award

SPP-160



� THIRD LEVEL OF THE PLANNING AND

TRACKING PROCESS

STEP 120 - Prepare Estimates and Schedule

SDP Outputs (RTM)

Cost Data

Proposal leader and functionalManagement approval

Outputs

SPP-110

Inputs

RFP/SOW/SOR

Project WBS/OBS

Historical Data

Procedure for Estimates

Assumptions

Resource Availability

Assumptions forEstimates

Updated HistoricalDatabase

Estimates

Schedule

List ofAlternatives

EntryCriteria

Measures

Effort

Exit

Criteria

SPP-130Approved project WBS/OBS

ActivitiesActivities



Need for

Assessment

Fall 95

Senior

ManagementCommitment

Fall 95

SystemsSystems EngineeringEngineering

ProcessProcess

Self-Assessment

Fall 95 Action PlanWinter 96

Process DefinitionTechnical Steps

Spring 96

Assessment

Fall 99

Process Definition

Management Steps

Fall 96

Pilot Projects1997

Final Processand Training

Summer 97



� SYSTEMS ENGINEERING PROCESS

� Adapted from SPC’s Generic Systems Engineering

Process (GSEP)

� Process integrates both technical and engineering

management activities

� Tailorable process

� Supports incremental development



� SYSTEMS ENGINEERING PROCESS

Manage

Development

Effort

Define

System

Increment

System ContextTechnical RiskTechnical BaselineSystem Status

System Definition

Increment

Plan

Estimateof the

Situation

SystemDefinition



�� MANAGEMENT ACTIVITIES OF SEPMANAGEMENT ACTIVITIES OF SEP

Understand

Context

Step 110

Analyse

Risk

Step 120

PlanIncrement

Development

Step 130

TrackIncrement

Development

Step 140

DevelopSystem

Plan

Step 150

I9

System Context

Estimate of the Situation ( Approved )

I1External System

Definition

I3UserReq.

I4Tech.

Base

I6Increment

Status

I7Tech.

Baseline

I8Tech.

Risk

I2Subsystem/

Components

Status

I5System

Implementation

Status

System Status O2

O5

RiskManagement

Plan ( Approved )

Increment

Plan( Approved )

Increment

Plan( Updated )

Increment Plan

( Approved / Updated )O3

System Definition

( Approved )O4

Incr.

Plan

(Enacted)Increment

Status Report System Plan

( Approved )O1

Management Development Effort



STEP 140

Track Increment

Development

STEP 120

Analyze

Risk

STEP 130

Plan Increment

Development

STEP 110

Understand

Context

STEP 150

Perform Increment

Closure

MANAGEMENT ACTIVITIES OF SEPMANAGEMENT ACTIVITIES OF SEP



�� STEP 120 - Analyze RiskSEP 121

Perform

Risk Analysis

SEP 122

Review

Risk Analysis

SEP 123

Plan

Risk Aversion

SEP 124

Commit

to Strategies



�� Step 120 - Analyze Risks

�� Risk Management PlanRisk Management Plan

�� Risk Descriptions and Impacts Risk Descriptions and Impacts

�� Budget overrun, schedule delays, integration risks due Budget overrun, schedule delays, integration risks due

to concurrency, new technologiesto concurrency, new technologies

�� Documented, updated and stored in a databaseDocumented, updated and stored in a database

�� Mitigation StrategiesMitigation Strategies

�� Pilot projects, engineering models, mockPilot projects, engineering models, mock--upsups

�� AnalysesAnalyses

�� Component and subsystem modelingComponent and subsystem modeling

�� TrainingTraining

�� Reviews with stakeholdersReviews with stakeholders



�� TECHNICAL ACTIVITIES OF SEPTECHNICAL ACTIVITIES OF SEP

Analyse

Needs

Step 210

Define

Requi.

Step 220

Define

Functional

Architecture

Step 230

Synthetize

Allocated

Architectures

Step 240

Evaluate

Alternatives

Step 250

Verify and

Validate

Work

Products

Step 260

Control

Tech.

Baseline

Step 270

Define System Increment

I1

Estimate ofthe Situation

I3

UserRequi.

I4

Techno.

Base

I2

External

System

Definition

I5

SystemDefinition /

Process

Requi.

Technical Baseline O2

Increment Status O1

Technical Risk O3

System Context O4

Sys. Requi.

Derived

Req.

Alternative

Functional

Architectures

PerformanceRequirements

AlternativeAllocated

Architecture

System

Solution

(Prefered)

EvaluationResults

Allocated

Req &

Perf.

Estimates

EvaluationDocumentation

(Baselined)

V & V Test

Procedures

Verification &Validation

Results

SystemDefinition

( Interim )

SystemDefinition

(Interim

Updated)

ConfigurationControl /

Constraints

Technical

Performance

Measurements

Informal

functionalHierarchy

(With Tech.

Meas.)



STEP 240

Synthesize Allocated

Architecture

STEP 220

Define

Requirements

STEP 260

Verify and Validate

Work Products

STEP 210

Analyze

Needs

STEP 250

Evaluate

Alternatives

STEP 230

Define functional

Architecture

STEP 270

Control Tech.

Baseline

�� TECHNICAL ACTIVITIES OF SEP



SEP-100 Manage Development Effort

UnderstandContext

SEP-200 Define System Increment

AnalyzeRisk

Plan IncrementDevelopment

Track Increment Development

Develop System Plan

Analyze Needs

Define Requirements

Define Functional Architecture

Synthetize Allocated Architecture

Evaluate Alternatives

Validate and Verify Solution

Control Technical Baseline

Not to Scale

� A SEP INCREMENT (THE REAL LIFE)



�� INTEGRATED SYSTEMS AND SOFTWARE INTEGRATED SYSTEMS AND SOFTWARE

ENGINEERING PROCESS ENGINEERING PROCESS �� Model developed by the SPCModel developed by the SPC

�� Addresses the problem of large, complex systemsAddresses the problem of large, complex systems

�� Decomposes the system such that parts can be Decomposes the system such that parts can be

independently developed and integratedindependently developed and integrated

�� System Level (includes segment and subsystem System Level (includes segment and subsystem

parts)parts)

�� Configuration Items (include software and Configuration Items (include software and hardware hardware

parts)parts)

�� ComponentsComponents



Implement

(Produce)

System

Develop SW

Configuration

Item Develop HW

Configuration

Item

Manage

Development

Effort

Define

System

Increment

System ContextTechnical RiskTechnical BaselineSystem Status

Configuration ItemCI Baseline / Plan /Status

System Development Plan / Status

System Definition

Increment

Plan

System

Estimateof the

Situation

SystemDefinition

�� INTEGRATION of PROCESSESINTEGRATION of PROCESSES



Need for

Management Process

Spring 97

SeniorManagementCommitment

Fall 97

ProjectProject ManagementManagement

ProcessProcess

Working GroupKickoff

Winter 97

Pilot Projects

Summer 98Process Guides

1998

ProcessTraining

Summer 98

Mandate

Approved

Winter 97

Mandate

Approved

Winter 97

Process Definition

Summer 97

Process Definition

Summer 97

Brainstorm

Problems

Spring 97

Brainstorm

Problems

Spring 97



� PROJECT MANAGEMENT PROCESS

� Adapted from the Project Management Institute

PLAN PROJECTACTIVITIES

PMP 200

INITIATE

PROJECTACTIVITIES

PMP 100

CLOSE PROJECT

ACTIVITIES

PMP 500

CONTROL PROJECTACTIVITIES

PMP 400

EXECUTEPROJECT

ACTIVITIES

PMP 300



pp

�� PROJECT MANAGEMENT AND ENGINEERINGPROJECT MANAGEMENT AND ENGINEERING

Implement

(Produce)

System

Implement

(Produce)

System

Develop SW

Configuration

Item Develop HW

Configuration

Item

Develop HW

Configuration

Item

Manage

Development

Effort

Define

System

IncrementSystem ContextTechnical RiskTechnical BaselineSystem Status

Configuration ItemCI Baseline / Plan /Status

System Development Plan / Status

System Definition

Increment

Plan

System

Estimateof the

Situation

SystemDefinition

Project Management

Process



� INTEGRATION FACILITATORS

� Common Process Development Approach

� Define a process and bring it under management control.

� Support the process with engineering methodsappropriate to the application.

� Support the process and engineering methods with tools integrated into a consistent environment.

� Train personnel to use these processes, methods, and tools.



� Integration Facilitators Processes

� Common Process Description

� Policies, Standards and Procedures

� Inputs and Outputs

� Entry and Exit Criteria

� Activities

� Specified Roles

� Measurements

� Templates and Checklists




� Common Process Notation

� ETVX

� Common Vocabulary

� e.g. prototype

� Common Processes

� Documentation Management

� Quality Assurance (Audits)

� Configuration Management

� Performance Management




� Organizational Process Oversight

� Process Action and Coordination Team (PACT)

– Functions

• Establish objectives for organizational processes

• Liaise with other executives

• Provide support for process improvement activities

• Review results of audits or assessments

• Charter working groups

• Monitor process performance

– Members

• Vice-Presidents (Project, Finance & Contract, HR)

• Quality Assurance Manager

• Process Coordinator




� Organizational Process Oversight

� Process Owners

– Focal point for process improvement activities

– Review project plan tailoring

• If conflict between process owner and project manager, a senior manager or an executive will take decision

– Prepare Annual Process Improvement Plans

– Report progress to Process Action and Coordination Team



�� INTEGRATION FACILITATORSINTEGRATION FACILITATORS

�� Common MethodsCommon Methods

�� Structured Analysis and Design (SADT)Structured Analysis and Design (SADT)

�� Common ToolsCommon Tools

�� CORECORE

�� Software through Pictures (Software through Pictures (StPStP))

�� RTMRTM



�� Integration FacilitatorsIntegration Facilitators

�� PROCESS ASSET LIBRARYPROCESS ASSET LIBRARY� Policies� Process Descriptions� Guides, Forms and Templates� Examples of Documents Produced

�Business Cases�Proposals�Engineering Plans�Specifications

� Tailored Processes� Lessons Learned� Charter of Process Engineering Groups� Training Material� Metrics (Process and Product)� Historical Data



� INTEGRATION ISSUES

� Activities performed differently in different

processes

� e.g. risk management, development plans (e.g. software, system and project plans)

� Activities mandated by different frameworks

� e.g. subcontractor management

– SW-CMM

– SE-CMM

– Body of Knowledge - Project Management Institute

� Processes called by other Processes

� Need well defined interfaces between processes



� PEOPLE ISSUES

� To facilitate adoption

� Process developed by future users

� Process developed by multi disciplinary teams

� Training of all users and people affected by a process

– e.g. for Systems Engineering Process

• system engineers, software engineers, design engineers, logistic support, quality assurance and configuration management

� To facilitate utilization

� Integration of people in a multi disciplinary team (IPT)



� PEOPLE ISSUES

� To facilitate collaboration

� Development of project charters

– Common Vision

– Common Objectives

– Common Methods

– Known Responsibilities

� Performance Management Process

– Behaviors are promoted and rewarded

� Team development Approach

– Combination of work product development and “soft skills”

development



CREATING STAGES SUSTAINING STAGES

1.

Orientation

Why

am I here?

2.

Trust

Building

WHO

are you?

7.

Renewal

WHY

continue?

Resolved

• Purpose

• Personal fit

• Membership

Resolved

• Mutual regard

• Forthrightness

• Spontaneous

interactionResolved

• Explicit assumptions

• Clear, integrated

goals

• Identified roles

Resolved

• Clear processes

• Alignment

• Disciplined

execution

Resolved

• Flexibility

• Intuitive communications

• Synergy

Resolved

• Recognition

• Change mastery

• Staying power

Resolved

• Shared vision

• Allocated

resources

• Organizational

decisions

Unresolved

• Disorientation

• Uncertainty

• Fear

Unresolved

• Caution

• Mistrust

• Facade

Unresolved

• Apathy

• Skepticism

• Irrelevant

competition Unresolved

• Dependence

• Resistance

Unresolved

• Conflict/confusion

• Nonalignment

• Missed deadlines

Unresolved

• Overload

• Disharmony5.

Implemen-

tation

WHO does WHAT,

WHEN, WHERE?

4.

Commit-

ment

HOW

will we do it?

3.

Goal/Role

Clarification

WHAT

are we doing?

6.

High

Performance

WOW!

Drexler/Sibbet

Team Performance

Model

Drexler/Sibbet

Team Performance

Model



� PEOPLE ISSUES

� Team Development Workshops

� Why am I on this team ?

� Why are we on this team ?

� How do I contribute ?

� Who are our stakeholders and what are their needs and expectations

� How do we work together ?

� Who does what ?

� How do we prepare for success ?



Gameplan

TARGET

TEAM

CHALLENGES

SUCCESS

FACTORS

STAGES / TASKS

Name of TeamDate (YY-MM-DD)



� PEOPLE ISSUES

� Transition Plans to Facilitate Technology Deployment

� Establish a Transition Team

� Describe the Desired State

� Baseline the Current State

� Analyze the Gap

� Develop a Transition Management plan

� Roll Out the Solution(s)

� Analyze Lessons Learned



Many of the problems or dysfunctions stem from

operating out of the assumptions that parts, people

or departments are separate and unrelated.

Many of the problems or dysfunctions stem from

operating out of the assumptions that parts, people

or departments are separate and unrelated.




� A System View of the Organization

Legend: Input-output flow of materials,

energy, information

Strategic

SubsystemTechnological

Subsystem

Human/Cultural

Subsystem

Structural

Subsystem

Inputs:

• Human

• Financial

• Technological

• Material

Outputs:

• Products

• Services

Managerial

Subsystem




� A System Perspective of the Organization



� LESSONS LEARNED

� Create common Vision for Management and Practitioners

� Reduce Cycle Time

� Increase Quality and Productivity

� Develop a Process Improvement Plan

� Link Between Project Requirements and Process Activities

� Multi-Year Plan to show long term commitment

� Use Pilot Projects

� Members of Pilots have a Safety Net for ¨mistakes¨

� Success of Pilots facilitates adoption of technologies



� LESSONS LEARNED

� Fix the Process not the People

� Focusing on Process allows Practitioners to learn while using the new Process, Method or Tool.

� Mistakes are Acceptable If we learn from them

� The Management of the “Soft Issues” are as important as the

“Hard Issues”

� It is 25% SW, 25% HW & 50% ”Peopleware”



� LESSONS LEARNED

� If Possible Start from the Top Level Processes

� Integration of Processes should be planned for at the beginning of a process initiative

� Organizational Culture is like a “sleeping lion”. As soon as you start tampering with him, the lion will wake up and may start “showing his crows” to the challengers.



� NEXT STEPS� Integrating Engineering Processes with Project Management Process

� Electronic Process Asset Library on Local Area Network (INTRANET)

� Migration towards Integrated Product Teams

� Modify Organizational Structure

� Clarification of Roles and Responsibilities

� Modification of Performance Management Process

– e.g. moving from individual performance evaluation

to team performance evaluation and reward



� CONCLUSION

� OUR Organization is making substantial effort to define and improve

both Engineering and Management Processes

� Significant Progress in Process Improvement also implies a Cultural

Change in the organization:

� A Shift From the NIH (Not Invented Here) to the NRH (Not Re-invented Here) resulting in mission-oriented teams.

� Systems and Software Engineering Processes need to be defined

and integrated for EFFICIENCY and EFFECTIVENESS to get the

“BANG FOR THE BUCK”

SPI 98 Monte Carlo · 2012. 12. 20. · Oerlikon Development and Integration Issues Aerospace SPI...

Documents

Transcript of SPI 98 Monte Carlo · 2012. 12. 20. · Oerlikon Development and Integration Issues Aerospace SPI...