Download - 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
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
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
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
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
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?
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
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
CT Project Organization (Original)CT Project Organization (Original)
Product-Line DevelopmentProduct-Line Development
Advance P-L OrganizationAdvance P-L Organization
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
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
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
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
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)
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
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)
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
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)
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)
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
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
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
Process Specification and Process Specification and ModelingModeling
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)
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?
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?
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.
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)
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
Process as ProductProcess as Product
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!
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.)
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)
Questions?Questions?