OMSE 551: Week 2 Process Engineering I

36
OMSE 551: Week 2 OMSE 551: Week 2 Process Engineering I Process Engineering I Celsius-Tech Discussion Celsius-Tech Discussion Why study processes? Why study processes? Process improvement Process improvement Process definition and Process definition and modeling modeling Process as product Process as product

description

 

Transcript of OMSE 551: Week 2 Process Engineering I

Page 1: OMSE 551: Week 2 Process Engineering I

OMSE 551: Week 2OMSE 551: Week 2Process Engineering IProcess Engineering I

Celsius-Tech Discussion Celsius-Tech Discussion Why study processes?Why study processes? Process improvementProcess improvement Process definition and modelingProcess definition and modeling Process as productProcess as product

Page 2: OMSE 551: Week 2 Process Engineering I

Review: We Only Look at Part of the Review: We Only Look at Part of the ProblemProblem

Know that choices here– Are affected by prior choices, experience, products– Will affect future capabilities: business, technical

E.g., architecture (architectural business cycle)

Omits critical context information– How do the activities relate to short or long term business

goals?– How do the decisions here affect future products?– Where does information about these issues come from and in

what form?

Factors affecting ability to control the process are outside the scope

– Factors affecting the process are implicit– Factors affected by the process are nowhere evident

SoftwareDesign

System Integrationand Testing

Coding

Deployment andMaintenance

RequirementsAnalysis

Product

Page 3: OMSE 551: Week 2 Process Engineering I

Consequence:Consequence:Merry-Go-Round of Sequential DevelopmentMerry-Go-Round of Sequential Development

Knowledge is not Knowledge is not institutionalized (tacit)institutionalized (tacit)

Doomed to repeat Doomed to repeat lessons of the pastlessons of the pastSoftware

Design

System Integrationand Testing

Coding

Deployment andMaintenance

RequirementsAnalysis

Product

Page 4: OMSE 551: Week 2 Process Engineering I

What is the “Whole Problem?”What is the “Whole Problem?”

Typically treat product development as a Typically treat product development as a distinct concerndistinct concern • Each development is treated relatively independently from other Each development is treated relatively independently from other

developmentsdevelopments• Products and processes developed to meet project-only goalsProducts and processes developed to meet project-only goals

Typically neither is nor should be a distinct concernTypically neither is nor should be a distinct concern• Everything has a context that cannot be ignoredEverything has a context that cannot be ignored• Necessarily acquires people, products, process, organization from contextNecessarily acquires people, products, process, organization from context• Influences organization, process, products downstreamInfluences organization, process, products downstream

SoftwareDesign

System Integrationand Testing

Coding

Deployment andMaintenance

RequirementsAnalysis

Product

SoftwareDesign

System Integrationand Testing

Coding

Deployment andMaintenance

RequirementsAnalysis

ProductProject Goals

Project Process

Project Organization

Legacy Products

Business Goals

Standard Process

OrganizationProject Process

Project Organization

Legacy Products

Page 5: OMSE 551: Week 2 Process Engineering I

What is the “Whole Problem?”What is the “Whole Problem?”

Relationship between inputs and outputs is not controlledRelationship between inputs and outputs is not controlled– Actually a feedback loop over timeActually a feedback loop over time– Result is disconnect between inputs and outputsResult is disconnect between inputs and outputs– Output properties are inconsistent with long term goalsOutput properties are inconsistent with long term goals

Developing strategically requires closing the loop (I.e. exercising Developing strategically requires closing the loop (I.e. exercising control across development cycles)control across development cycles)

SoftwareDesign

System Integrationand Testing

Coding

Deployment andMaintenance

RequirementsAnalysis

Product

SoftwareDesign

System Integrationand Testing

Coding

Deployment andMaintenance

RequirementsAnalysis

ProductProject Goals

Project Process

Project Organization

Legacy Products

Business Goals

Standard Process

OrganizationProject Process

Project Organization

Legacy Products

Page 6: OMSE 551: Week 2 Process Engineering I

Discussion: Lessons from Celsius-TechDiscussion: Lessons from Celsius-Tech

What had to change in their approach?What had to change in their approach?How did the products change?How did the products change?– Kinds of products producedKinds of products produced– Quality measures?Quality measures?

How did the process change?How did the process change?– Inputs? Outputs? Goals? Measures of goodness?Inputs? Outputs? Goals? Measures of goodness?

How did the organization change?How did the organization change?– Roles?Roles?– Organizational structure?Organizational structure?– Relationships?Relationships?

Page 7: OMSE 551: Week 2 Process Engineering I

Means of Production as ProductMeans of Production as Product

A product-line development A product-line development strategy sets out to strategy sets out to maximize reusemaximize reuse over a over a family of similar software family of similar software systems.systems.– Reuse is planned and Reuse is planned and

systematically executedsystematically executed

– Common assets are Common assets are developed as a distinct developed as a distinct productproduct

– The process focuses on The process focuses on developing means of developing means of production before any production before any particular productparticular product

77

Build Applications(Family Members)

Application EngineeringEnvironment

(Means of Production)

Application

Develop Means of Production Design development process

Design production environment Build reusable assets

A Product-Line Process

Page 8: OMSE 551: Week 2 Process Engineering I

Products: Reuse in ContextProducts: Reuse in Context

Success comes from reusing context, not just components“The unit of reuse is a system function, a thread of related functionality that comprises elements from different layers in the architecture.

System functions are pre-integrated—that is, the components they comprise have been assembled, compiled together, tested individually, and tested as a unit.

When the system function is checked out of the asset repository, it is ready for use. In this way, CelsiusTech is not only reusing components, it is also reusing the integration, component test, and unit test effort that would otherwise have to be needlessly repeated for each application.”

Did not require new technology

Page 9: OMSE 551: Week 2 Process Engineering I

CT Project Organization (Original)CT Project Organization (Original)

Page 10: OMSE 551: Week 2 Process Engineering I

Product-Line DevelopmentProduct-Line Development

Page 11: OMSE 551: Week 2 Process Engineering I

Advance P-L OrganizationAdvance P-L Organization

Page 12: OMSE 551: Week 2 Process Engineering I

Abstracted CT ProcessAbstracted CT Process

Commonalty Analysis of Ship Systems

Model/Test application

Architecture & Adaptable Components

Applications

AssetDevelopment

ProductDevelopment

Economic Analysis

Implement Production Environment

Build Ship System

Product Process

Frequent/Low Cost

CustomerSystem Requirements

Market Needs/Business Goals

Infrequent/Higher Cost

Page 13: OMSE 551: Week 2 Process Engineering I

Product-Line Development Over TimeProduct-Line Development Over Time

Adapt Assets

PL Requirements

Reusable Assets& Generators

Time

PL Design

Create Product

Product

Adapt Assets

Create Product

Product

Adapt Assets

Create Product

Product

CustomerRequirements

Page 14: OMSE 551: Week 2 Process Engineering I

All Three Had to ChangeAll Three Had to Change

How must each reflect the others? (pairwise)How must each reflect the others? (pairwise)

How can each impede the others?How can each impede the others?– e.g could the first organization have implemented the e.g could the first organization have implemented the

product line?product line?

Success requires alignment (consistency)Success requires alignment (consistency)

PRODUCTSPROCESS

ORGANIZATION

Page 15: OMSE 551: Week 2 Process Engineering I

Software Process Software Process EngineeringEngineering

Perspectives on current views of software processesPerspectives on current views of software processes Need to specify ideal (“rationale”) processesNeed to specify ideal (“rationale”) processes Need to view processes as productsNeed to view processes as products

Page 16: OMSE 551: Week 2 Process Engineering I

Celsius Tech LessonsCelsius Tech LessonsObserve that PL approach required significant process Observe that PL approach required significant process changeschanges– Q1: What process-related activities were required? Q1: What process-related activities were required?

What processes were created? What processes were created? How were they communicated? Enforced?How were they communicated? Enforced?How are processes evolved to meet changing needs without disrupting the How are processes evolved to meet changing needs without disrupting the PL?PL?

– Q2: What skills or capabilities are needed?Q2: What skills or capabilities are needed?Process development? Verification? Communication?Process development? Verification? Communication?

Implications => Implications => – Strategic software engineering requires process development Strategic software engineering requires process development

skillsskills– Suggests need for different view of processes (process as Suggests need for different view of processes (process as

product)product)

Page 17: OMSE 551: Week 2 Process Engineering I

What is a “software process”?

[Webster’s] – “A series of actions or operations proceeding to an end.”[Paulk, et al] – a set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products…”[Weiss, Lai] – “A process is a sequence of decision-making activities. For any engineering process, the engineers need to know what decisions they can make, when they can make them, what the results mean, and how they should be represented.”†

† We will use this one for 551

Page 18: OMSE 551: Week 2 Process Engineering I

Original Rationale for Process ViewOriginal Rationale for Process View

Developed as a tool for Developed as a tool for gaining and maintaining control gaining and maintaining control over complex software development effortsover complex software development effortsApplication of “divide-and-conquer” to software Application of “divide-and-conquer” to software development activities and productsdevelopment activities and products– Identify distinct phases of development and distinct productsIdentify distinct phases of development and distinct products

E.g., Requirements phase – understand the problem to be solvedE.g., Requirements phase – understand the problem to be solvedProduct – Software Requirements SpecificationProduct – Software Requirements Specification

– Assumption: simpler to address each phase separatelyAssumption: simpler to address each phase separatelyE.g., Elicit, specify, and validate requirements before doing designE.g., Elicit, specify, and validate requirements before doing designTrue to the extent dependencies between phases and products are True to the extent dependencies between phases and products are limited (same as for modules)limited (same as for modules)Since “coupling” between process phases is high, success has been Since “coupling” between process phases is high, success has been limited (e.g., waterfall variations)limited (e.g., waterfall variations)

Page 19: OMSE 551: Week 2 Process Engineering I

Current Focus: “Process Improvement”Current Focus: “Process Improvement”

Why focus on “process improvement”?Why focus on “process improvement”?Software problems characterized by lack of controlSoftware problems characterized by lack of control– Development typically chaotic: unpredictable in budget, Development typically chaotic: unpredictable in budget,

schedule, and resultschedule, and result– Process is poorly definedProcess is poorly defined– Don’t know what to change to improve the resultDon’t know what to change to improve the result

Desire to make software development Desire to make software development systematicsystematic – Thorough, methodical, regular, and predictableThorough, methodical, regular, and predictable– So how do we get from “chaotic” to “systematic”?So how do we get from “chaotic” to “systematic”?

Implied solution: Implied solution: – Must first understand the current process Must first understand the current process – Must determine where it’s going wrongMust determine where it’s going wrong– Then can revise to address problemsThen can revise to address problems

Page 20: OMSE 551: Week 2 Process Engineering I

A Simple Process-Improvement ProcessA Simple Process-Improvement Process

Important PointsImportant PointsQuality goal and Quality goal and iteration test are defined iteration test are defined in terms of the in terms of the productproduct (not the process)(not the process)

Must Must understandunderstand the the process before we can process before we can effectively adjust it.effectively adjust it.

Measurement is done Measurement is done on the on the productproduct (not the (not the process)process)

Define thequality goal

Measure product quality

Understandthe process

Adjustthe process

Use the adjustedprocess

Measurethe results

Compare resultswith the goalIterate

From Introduction to the Personal Software Process, W. Humphrey(borrowed from manufacturing process improvement)

Page 21: OMSE 551: Week 2 Process Engineering I

Process vs. Product ImprovementProcess vs. Product Improvement

Are we trying to improve the process or the product?Are we trying to improve the process or the product?

Role of Role of productproduct is obscured in Capability Maturity Model is obscured in Capability Maturity Model (CMM)(CMM)

““Process maturityProcess maturity is the extent to which a specific is the extent to which a specific process is explicitly defined, managed, measured, and process is explicitly defined, managed, measured, and effective.” [Paulk]effective.” [Paulk]– Improvement defined in terms of predictability, control, and Improvement defined in terms of predictability, control, and

effectivenesseffectiveness– Where Where EffectiveEffective is define as: “practiced, documented, enforced, is define as: “practiced, documented, enforced,

trained, measurable, improvable”trained, measurable, improvable”– Focus of measurement is on the process (Focus of measurement is on the process (notnot product) product)

Page 22: OMSE 551: Week 2 Process Engineering I

Process vs. Product Improvement (2)

Upshot: Process improvement and product improvement are related but distinct concernsWe can improve a product without changing the process– E.g., use better designers and programmers

We can improve a process without changing the product– Produce same product in less time or for less money– Produce same product with process that is better defined,

measured, more predictable, etc.

We can also change a process to improve product quality

Page 23: OMSE 551: Week 2 Process Engineering I

Process vs. Product Improvement (3)Process vs. Product Improvement (3)

Need to be clear on the goal – the goal determines what Need to be clear on the goal – the goal determines what needs to be measuredneeds to be measured– To improve the product, must measure product qualityTo improve the product, must measure product quality– To improve the process, must measure process qualityTo improve the process, must measure process quality

For software, measuring product qualities is (often) For software, measuring product qualities is (often) harder than measuring process qualitiesharder than measuring process qualities– Why? Examples?Why? Examples?– Leads to overemphasis on process definition and measurementLeads to overemphasis on process definition and measurement– Heisenberg applies!Heisenberg applies!– May result in May result in process-improvement-death-spiralprocess-improvement-death-spiral

Some simple truths (oft forgotten)Some simple truths (oft forgotten)– A software development process exists A software development process exists onlyonly to produce a to produce a

software productsoftware product– What you measure is what you getWhat you measure is what you get– If it’s not worth doing, it’s not worth doing well!If it’s not worth doing, it’s not worth doing well!

Improving a process that produces junk just does it more efficientlyImproving a process that produces junk just does it more efficiently

Page 24: OMSE 551: Week 2 Process Engineering I

Relation to SSERelation to SSEBenefits of CMM/Process ImprovementBenefits of CMM/Process Improvement– Previously had Previously had nono mechanism for judging process quality or mechanism for judging process quality or

setting a baseline for process improvementsetting a baseline for process improvement– It is inherently strategic in viewIt is inherently strategic in view

Strategic in looking at process as Strategic in looking at process as institutional assetinstitutional asset Strategic in sense that it spans development cyclesStrategic in sense that it spans development cycles

DrawbacksDrawbacks– Focus on process alone often does not result in product Focus on process alone often does not result in product

improvementimprovement– Assumes a conventional life cycle Assumes a conventional life cycle – Assumes process improvement by increments: Assumes process improvement by increments:

But, we can’t get from tactical view to strategic one by incremental But, we can’t get from tactical view to strategic one by incremental improvementsimprovements

““Process improvement” view is necessary but not Process improvement” view is necessary but not sufficient for SSEsufficient for SSE

Page 25: OMSE 551: Week 2 Process Engineering I

Process Specification and Process Specification and ModelingModeling

Page 26: OMSE 551: Week 2 Process Engineering I

Why Specify Processes?We must first understand a process to improve itRepresenting a process is a necessary step toward understanding (and communicating)– Software processes are complex– Must see it to work with it– Must be communicated to many different stakeholders

Process specification can serves variety of purposes– Provides a standard metric for development progress (a

yardstick)– Provides guidance for enactment (a map)– Provides baseline for process improvement or tailoring– Criterion for contract award (e.g., CMM level)

Page 27: OMSE 551: Week 2 Process Engineering I

ContentsContents of a Process Specification of a Process SpecificationDetails depend on the purpose of the specificationDetails depend on the purpose of the specificationIn general, contents should answer [Parnas &Clements]:In general, contents should answer [Parnas &Clements]:– What product we should work on next?What product we should work on next?

Equivalently – what decision(s) must we make next?Equivalently – what decision(s) must we make next?

– What kind of person should do the work?What kind of person should do the work?– What information is needed to do the work?What information is needed to do the work?– When is the work finished?When is the work finished?– What criteria must the work product satisfy?What criteria must the work product satisfy?

In personal terms, answers the questions:In personal terms, answers the questions:– Is this my job?Is this my job?– What do I do next?What do I do next?– What do I need to do the work?What do I need to do the work?– Am I done yet?Am I done yet?– Did I do a good job?Did I do a good job?

Page 28: OMSE 551: Week 2 Process Engineering I

QualitiesQualities of a Good Process Spec of a Good Process Spec

Think about how it will be usedThink about how it will be used– Guide the processGuide the process– Measure progressMeasure progress– Basis for process improvement, modification, tailoringBasis for process improvement, modification, tailoring

Reasonable analogy to an SRS (or any technical Reasonable analogy to an SRS (or any technical spec)spec)– What properties would you want?What properties would you want?– E.g., if you were going to try to emulate Celsius E.g., if you were going to try to emulate Celsius

Tech’s process in your organization? Tech’s process in your organization?

Page 29: OMSE 551: Week 2 Process Engineering I

Ideal Process DescriptionIdeal: Process is like a program– Can be followed systematically– Result is predictable and inevitable

…but, people aren’t machines– Steps cannot be described with complete precision– Real processes are neither sequential nor deterministic– Things change over time– People make mistakes– People compromise, adjust, make do, fill in, muddle through,

soldier on … where machines fail

Implication: any (useful) process description we write down is the description of an ideal, not a real process.

Page 30: OMSE 551: Week 2 Process Engineering I

Desirability of “Faking it”Desirability of “Faking it”Thesis: It is nonetheless useful to “fake” a rational design Thesis: It is nonetheless useful to “fake” a rational design process [Parnas & Clements]process [Parnas & Clements]– Endevor to describe the ideal process (not the real one)Endevor to describe the ideal process (not the real one)– Follow the ideal process as closely as possibleFollow the ideal process as closely as possible– Write (rewrite) the documentation and other work products as if Write (rewrite) the documentation and other work products as if

we had followed the idealwe had followed the ideal

RationaleRationale– Idealized process can provide guidanceIdealized process can provide guidance– Helps come closer to the ideal (emulation)Helps come closer to the ideal (emulation)– Helps standardize the process (provide a common view of how Helps standardize the process (provide a common view of how

to proceed and what to produce)to proceed and what to produce)– Provides a yardstick for assessing progressProvides a yardstick for assessing progress– Provides better products (e.g. final draft not first) Provides better products (e.g. final draft not first)

Page 31: OMSE 551: Week 2 Process Engineering I

Abstraction and ModelingAbstraction and ModelingAn ideal process is an An ideal process is an abstractabstract process process– Recall that abstraction = = one-to-manyRecall that abstraction = = one-to-many– Many possible ways of getting the work done satisfy the idealMany possible ways of getting the work done satisfy the ideal

E.g., different sequencing of activitiesE.g., different sequencing of activities

Another reason for looking at products (process independent)Another reason for looking at products (process independent)

– Abstracting allows us to document and understand what a set of Abstracting allows us to document and understand what a set of related processes have in commonrelated processes have in common

Use the term “modeling” to describe the capability to Use the term “modeling” to describe the capability to construct specifications of abstract processesconstruct specifications of abstract processes– Modeling languages provide constructs for describing the parts Modeling languages provide constructs for describing the parts

of a process (roles, activities, products, sequencing, etc.)of a process (roles, activities, products, sequencing, etc.)– Formalizing the syntax permits tool supportFormalizing the syntax permits tool support– Formalizing the semantics permits analysisFormalizing the semantics permits analysis

Page 32: OMSE 551: Week 2 Process Engineering I

Process as ProductProcess as Product

Page 33: OMSE 551: Week 2 Process Engineering I

Contrasting Views of ProcessContrasting Views of ProcessProcess improvement view (e.g., CMM)Process improvement view (e.g., CMM)– We have a process that we want to improveWe have a process that we want to improve– Must understand it, document it, measure it, then change itMust understand it, document it, measure it, then change it– Result is a more mature process for developing software Result is a more mature process for developing software

productsproducts

Process as product view (SSE)Process as product view (SSE)– Not all developments are alike so not all processes are alikeNot all developments are alike so not all processes are alike

That’s why we have many process models (e.g., XP, SCRUM, That’s why we have many process models (e.g., XP, SCRUM, spiral, waterfall)spiral, waterfall)

– Each development effort needs a process appropriate to its Each development effort needs a process appropriate to its goals and constraints (examples?)goals and constraints (examples?)

Sometimes we can tailor an existing processSometimes we can tailor an existing process

Sometimes we need a new kind of processSometimes we need a new kind of process

– Implication: Implication: Processes are artifacts we produce too!Processes are artifacts we produce too!

Page 34: OMSE 551: Week 2 Process Engineering I

Implications for DevelopersImplications for Developers=> Processes must be treated as => Processes must be treated as first-class productsfirst-class products1.1. We need to be process developers as well as product We need to be process developers as well as product

developersdevelopers2.2. We need skills in creating, specifying, and analyzing We need skills in creating, specifying, and analyzing

processesprocesses3.3. We need a We need a process development processprocess development process4.4. Process development needs the same Process development needs the same organizational organizational

supportsupport as product development as product development– ResourcesResources– ManagementManagement– Requirements, etc.Requirements, etc.

5.5. We may need tool support for tedious, error-prone We may need tool support for tedious, error-prone tasks (specify, analyze, change, tailor, track, etc.)tasks (specify, analyze, change, tailor, track, etc.)

Page 35: OMSE 551: Week 2 Process Engineering I

SummarySummary

To implement strategic software development, To implement strategic software development, need to gain and maintain control over need to gain and maintain control over development of software processes.development of software processes.Current approaches to process improvement are Current approaches to process improvement are inadequateinadequateWriting abstract specifications of processes Writing abstract specifications of processes provides a vehicle to design, verify, represent provides a vehicle to design, verify, represent and communicate process development and communicate process development decisionsdecisions Implies that processes should be treated as Implies that processes should be treated as first-class productsfirst-class products (like code or other core (like code or other core assets)assets)

Page 36: OMSE 551: Week 2 Process Engineering I

Questions?Questions?