02-Products/Processes/Stakeholders Why engineer software?

CMPSCI520/620 Fall 2004- Lecture 02-Prods, Procs & Stakes 9/10/04

„ Rick Adrion 2004 [except where noted] 1

UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL ALL 20042004

02-Products/Processes/Stakeholders

ßReadings:ßFundamentals of Software Engineering, Ch. 2, 7

ß[ljO97] Leon J. Osterweil, “Software processes are softwaretoo, revisited: an invited talk on the most influential paper ofICSE 9,” Proceedings of the 19th International conferenceon Software Engineering May 1997


Why engineer software?

ßScope and Impact on SocietyßNew and Expanding Applications

ßSafety

ßSecurity and privacy

ßEconomicsßA trillion dollar a year industry?

ßSlow to get technology to marketßSRI->Xerox->Apple->Microsoft

ßUnix

ßIs the U.S. losing the innovation race?


Why engineer software?

ßQualityßdeliver prototypes &

"leave it to the marketplace"ßunsophisticated consumersßtolerate high failure ratesßThere are many recalls for automobiles; if something is not right,

then it has to be fixed and usually for free.ßA defect in software will be “fixed” in “the next” release (at some

cost to upgrade) or as a part of “maintenance” (also at some cost)

ßOther manifestations of poor quality:ßoptimizing software that is suboptimalßsoftware that is too slow/costs time and moneyßsoftware that is incomprehensibleßsoftware that is more trouble to use than it is worth

Look at what I bought!!


Barriers -- Industry’s short term focus

ß"bottom line orientation"ßemphasis on development, time to market -- not life cycleßcost of capital, return on investment -- see "Made in America”

ßstartups cannot invest in R&D until product established inmarketplaceßwithout the R&D, takes too long for next or improved productßmarket niche strategy driven by investors

ßsoftware housesßintensely competitiveßoften don't use own technologyßkeep development cost down, fix later

ßunsophisticated industriesßlack of technical expertiseßlack of administrative experience

ßoverselling the technology




Past Approaches

ßUse more peopleßcreates chaos, more problems

ßCreate "better" programming languagesßbad programs can be written in any language

ßDesign before writing codeßhow do you get the design right?

ßare you are designing the right program?ßstart by "baselining" requirements

ßbut they inevitably change, what then?

ßTest programs longerßfind more bugs, but is that good?


More Approaches

ßTrain managers betterßbut how do you manage this kind of product?

ßSoftware tools to help people write programs betterßsoftware tools are often bad software

ßpeople don't know how to use them

ßcost of capital issues

ßUse superior software processesßhow do you know when a process is “good”

ßTrain people betterßwhat to teach them?

The silver lining? Struggling with hardtechnological problems can lead to good scienceThe silver lining? Struggling with hardtechnological problems can lead to good science


Our Strategy

ßStart with engineering problemsßLook for deeper scientific questionsße.g., What constitutes quality in software? What is anerror?Can errors be proven to be absent? How canadding more people can make things come out worse?Issoftware based on any science?governed by any laws?

ßHypothesize conceptual foundationsßBase engineering solutions on conceptual foundationsßUse experience with engineering solutions to advancethe science:ßvalidate hypothesesßnew (sub-) hypothesesßrevise hypothesesßsuggest new issues and questions


Products, Processes & Technologies

ßSoftware ProductßThe complete set, or any of the individual items of the set, ofcomputer programs, procedures, and associateddocumentation and data designated for delivery to a customeror end user. [IEEE-STD-610]

ßSoftware ProcessßThe process or set of processes used by an organization orproject to plan, manage, execute, monitor, control andimprove its software related activities. [ISO/IECJTC1/SC7:15504-9]

ßSoftwareTechnologyßThe theory and practice of various sciences (to includecomputer, cognitive, statistical sciences, and others) appliedto software development, operation, understanding, andmaintenance; more specifically, we view software technologyas any concept, process, method, algorithm, or tool, whoseprimary purpose is the development, operation, andmaintenance of software or software-intensive systems.[CMU/SEI-97-HB-00]




Software Products

ßa software “product” is a complex web ofintertwined software objects, connected by amultitude of diverse relations and constraintsßsome types of objects:ßsource codeßdesignsßtest casesßdocumentationßsome types of relationships:ßis invoked byßis derived fromßis consistent withßis a version of


Software Processes

ßActivities related to the development, verification,evolution, evaluation, management, etc. of softwareproducts

ßExamples of high level processes:ßDevelop requirements

ßDo Object Oriented Design

ßFormally verify

ßExamples of low level processesßArchive result of running a test case

ßCompile a piece of code

ßTend to be concurrent (coordination of people, systems)

ßUsually (regrettably) informal or undefined


fi Requirements

Typical products and processes

ßCustomer needs

ßConstraints

ßRequired Domain Knowledge

ßPreliminary design

ßDetailed design

ßConstruction

ßMaintenance & Evolution

ßWhich are products and which are processes?


Stakes & Stakeholders

ßStakeholders may include: customer; “innocent bystander;”end user; end users’ management; system administrator;developer; regulators/monitors; etcßStakes: ease of use; training; cost; cost/benefits; schedule;meets specs; optimizes business practices; does no harm;etc.

ßA central concern of SE is to manage the creation andmaintenance of a software product that satisfies allneeds of all stakeholdersßImplies understanding who stakeholders are; whatquestions they need answered; to what degree ofthoroughness




Design

Hi Level

Lowlevel

Products & Relations

Requirements Specification

Functional

Safety

Performance

Robustness

Accuracy

Source

Object

executables

parse trees

instrumented source

relations tolow leveldesign

TestPlan

InputsOutputs

Timing

Setup

Knockdown

relations totest cases

test casesthat are

used to testfor

satisfactionof this

requirement


Products & Stakeholders

Design

HiLevel

Lowlevel


Functional

Safety

Performance

Robustness

Accuracy

Source

Object

executables

parse trees

instrumented source

TestPlan

InputsOutputs

Timing

Setup

Knockdown

?

UserDeveloperCustomerInnocent Bystander

?

?

?

?

?

? ?

?

?

?

??

?


Product Template

PRODUCT

OBJECT

MANUALS

PROCESSEXECUTIONDATA

QUALITYCONTROLDATA

PROCESSDOCUMENTATION

Design

Hi Level

Lowlevel


Functional

Safety

Performance

Robustness

Accuracy

Source

Object

executables

parse trees

instrumented source

TestPlan

InputsOutputs

Timing

Setup

Knockdown


Product Template

PRODUCT

OBJECT

MANUALS


QUALITYCONTROLDATA


PROCESSEXECUTORS

USER

EXECUTORINPUT

OUTPUTTO

EXECUTORS

PRODUCT INSTANCE

OTHER INSTANCESOF THE PRODUCTPRODUCT INSTANCE

PRODUCT INSTANCE

PRODUCT INSTANCE

PRODUCT INSTANCE




Software Process Instantiation

USERSoftwarePractioner

OTHER INSTANCESOF THE APPL

PRODUCT INSTANCE

PRODUCT INSTANCE

PRODUCT INSTANCE

PRODUCT INSTANCE

APPL INSTANCE

process____________________________code

sw product

template SoftwareProcess

Developer

PRODUCT

OBJECT

MANUALS


QUALITYCONTROLDATA


OTHER INSTANCESOF THE PRODUCT


There are products that share some of itscharacteristicsThere are products that share some of itscharacteristics

Software Is not unique

ßStudying such analogs can be useful:ßHelp us learn about computer software

ßFind points of similarity

ßSuggest successful approaches to beemulated

ßAvoid known mistakes


Problem: Create aproduct thatprovides shelter,sanitation, foodpreparationfacilities, recreation

Solution Medium:Dwelling unit

Problem: Create aproduct thatprovides shelter,sanitation, foodpreparationfacilities, recreation

Solution Medium:Dwelling unit

Lots ofinterconnectionand interactionamong thesecomponents


Analogy 1: Custom Home Building

ßProduct ComponentsßCustomer needsß number, type and size of rooms, location,

style,ß what else?

ßConstraintsß zoning, covenants, regulations

ßPreliminary designß architect sketchesß plans from book

ßDetailed designß blueprints

ßConstructionß Carpenters, plumbers, other skilled

craftspeopleßMaintenance & Evolutionß instructions, manualsß additions/ remodeling as needed

RequiredDomain

knowledge?


Strengths of Analogy 1

ßproblem solving to meet real-world needßsingle solution mediumßcompleted house is not whole solution, butonly a component thatßis constrained(zoning, etc.)ßmust "fit in" with utilities, neighbors, customerlifestyleßmust evolve with resident (user) needs andchanging environment




Weakness of Analogy 1

ß Customer familiarity withßSolution medium

ßDescriptive terms

ßTangibility and Visibility of theßintermediate productsßChanges are not always costly

ßfinal product

ß“well understood” application domain

ßToo specific:ßCustom: one need, one house; few stakeholders


Problem: Create aproduct to meet needsof citizens or solveproblems, such asCommon defense,domestic tranquility,establish justice

Solution Medium:Congress, ExecutiveAgencies, Petition,





Analogy 2: Legislation

ßProduct Componentsß “Customer” needsßMedia, polls, reaction to political

platforms, hearings, public opinion,reaction to legal decisionsß what else?

ßConstraintsß Constitution, Legislative Authority,

previous legislation, court decisionsßPreliminary designß Congressional staff draftsß Agency inputß (sub) committee hearings

ßDetailed designß Congressional staff (re-) draftsß Legislative plan or blueprintßMore Agency inputßMore (sub) committee hearings

RequiredDomain

knowledge?


Analogy 2: Legislation

ßProduct ComponentsßConstructionßProposed Bill/LawßAmendmentsßFinal Congressional & Executiveapproval

ßMaintenance & Evolution

ß Implementing bureaucracy

ßAmendments

ßCourt decisions









ßProblem solving to meet real-world needßSingle solution mediumßLaws/agencies are not the solution, but only acomponent thatßmust "fit in" with existing laws & regulations;court decisions, agency implementationßmust evolve with societal (user) needs andchanging environmentßerrors must be corrected by amendment,substitution, promulgation, courts





ßInadequacy of notation, representationßNatural (although stylized) languageßInterpretation varies: implementers (bureaucracies);courts

ßMany stakeholdersßeffected citizens & (public, private) sectors; (federal,state & local) agencies & legislatures

ßComplexityßStakeholders unfamiliar with detailsßSide effects; unexpected outcomesßSo called “wicked problem”ßSeldom independentßChanges must be carefully plannedßAssumed context for implementation


Weakness? of Analogy 2

ßLook at two simple examples:ßFY05 State budget (funding, outside sections)ßGovernorßHouse Ways & MeansßHouse 1 (amended)ßSenateßConferenceßGovernor’s vetosßLegislative overrides

ßSocial Security “Windfall Elimination”ßWhat are other analogies?ßPlays and Movies? Recipes? Driving instructions (eg.rallyes)

Products?

Process?

Products?

Process?

RequiredDomain

knowledge?


Example

University of Massachusetts For the operation of the University of Massachusetts;provided, that notwithstanding any general or special law to the contrary, the universitymay establish and organize auxiliary organizations, subject to policies, rules andregulations adopted by the board, to provide essential functions which are integral to theeducational mission of the university; provided further, that notwithstanding any general orspecial law to the contrary, the university may enter into leases of real property withoutprior approval of the division of capital asset management and maintenance; providedfurther, …; provided further, that no funds appropriated in this item may be used for theissuance or renewal of student or employee identification cards which display a student oremployee’s social security number; provided further …; and provided further.. .......................................................... $337,864,464

SECTION 242. Section 633 of chapter 26 of the Acts of 2003 is hereby amended by strikingout the second and third paragraphs and inserting in place thereof the following paragraphs:- Notwithstanding any general or special law to the contrary, the board of trustees for theuniversity of Massachusetts system and the president of the university are hereby authorizedand directed to establish a two year pilot program for out of state tuition retention at theflagship campus of the university at Amherst. The board shall promulgate…Notwithstanding any general or special law to the contrary, for employees of public highereducation institutions who are paid from tuition retained pursuant to this section, fringebenefits shall be funded as if those employees’ salaries were supported by stateappropriations. …


Another example

SECTION 1. WINDFALL ELIMINATION PROVISION RESTRICTED TO TOTAL MONTHLYAMOUNTS IN EXCESS OF $2,000. (a) IN GENERAL- Section 215(a)(7) of the SocialSecurity Act (42 U.S.C. 415(a)(7)) is amended-- (1) in subparagraph (A), by inserting after `service'),' the following: `if the sum of theindividual's primary insurance amount under paragraph (1) of this subsection and the portionof the monthly periodic payment which is attributable to noncovered service performed after1956 (with such attribution being based on the proportionate number of years of suchnoncovered service) is greater than $2,000, then'; (2) in the second sentence of subparagraph (B)(i), by striking `(with such attribution beingbased on the proportionate number of years of such noncovered service)' and inserting `(asdetermined under subparagraph (A))';(3) in the last sentence of subparagraph (B)(i), by striking `the larger of' and all that followsthrough `subsection (i))' and inserting the following: `the primary insurance amountdetermined under paragraph (1), reduced (before the application of subsection (i)) by theapplicable percentage specified in clause (iii) of the excess of such amount over the larger ofthe two amounts computed under the preceding two sentences,'; and(4) by adding at the end of subparagraph (B) the following new clause: `(iii) For purposes ofclause (i), the applicable percentage in connection with any individual shall be thepercentage specified in connection with such individual in the following table:




Quality

measurement

qualityconcept

measurablecharacteristic

abstraction

metric

applicationof metric


Quality - expanded

measurablecharacteristic

applicationof metric

purpose

concept

attribute

metric

measurement

qualityconcept

use

factors

criteria


Need for metrics

ßmost "ilities" are qualitative, not quantitative

ßhow to determineßmeasurement ¤ experimental

ßanalysis ¤ theoretical

ßsimulation ¤ compute/model


Software Qualities

ßExternal product qualitiesßvisible to the user of the system

ßreliability, robustness, performance (efficiency,usability, user-friendliness (human factors)),scalability

ßInternal product qualitiesßaffect the developers and maintainers

ßcorrectness (verifiability), maintainability(extensibility, repairability, reusability) portability(understandability, interoperability)




Software Qualities

ßProcess qualitiesßaffect activities

ßproductivity, timeliness, visibility

Process qualities fi Internal qualities fi External qualities


most manufacturing fi responsible for reliabilitysoftware industry fi waive responsibility

External Product Software Qualities

ßreliabilityß"performs as expected" "depend on it"

ßtoo often release products with known "bugs"

ßSDI argumentsßcan't build correct system that complex -- DaveParnas

ßdoesn't have to be correct to be reliable -- DannyCohen


External Product Software Qualities

ßrobustnessßperforms "satisfactorily" even whenenvironment & events unanticipated

ßcorrectness

Functional requirements specification

software

equivalence

testing -- experimentalproof -- analytical


Reliability, Robustness & Correctness

ßcorrectßdoes exactly what it is defined/specified to do

ßreliableßdoes exactly what the user wants (expects?) itto do (under "normal" conditions)

ßrobustßdoes exactly what the user wants (expects?) itto do (under "abnormal" conditions)

ßcan apply to products and processes




Correctness as an Internal ProductSoftware Quality

VerifiabilityVerification ¤ CorrectnessValidation ¤ Reliability (+ safety, security, etc.)Certification ¤ Legal & Contractual

spec. code design

validation

verification

verification


More External Product SW Qualities

ßPerformanceßefficientßproduces results in an acceptable amountof time

ßusable -- end uses find it easy to useßeasy to learn

ßeasy to install

ßeasy to operate

ßeasy to advance


More External Product SW Qualities

ßUser-friendlyßall of the above is provided with an easyto user interface

ßScalabiltyßhandle expansion in the parameters ofthe application


Internal Product Software Qualities

ßmaintainability = repairability + evolvabilityßcan be modified and revalidated easily

ßenhanced by abstraction, modularity,discipline, standards, and good taste

ßmaintenance is 60% of the lifecycle costs

ßunderstandabilityßsome products are inherently morecomplex than others





ßReusabilityßcan be used to construct another product

ßneed to plan for reuse

ßcan involve any artifact or process

ßdifficultßReusability factorsßmodularity

ßgranularity (e.g., Unix, X windows)

ßtrend is for plug-and-play components



ßInteroperabilityßcan co-exist and cooperate with other systemsßeasy to integrateßopen system & layered architecturesßwell-defined, standard interfacesßcollection of independently written applications thatcooperate and function as an integrated system

ßPortabilityßcan run on different environments (hardware orsoftware platform) with little effortßenhanced by using only standard capabilitieswhenever possible and by isolating non-standardcapabilities


Process Qualities

ßProductivityßmeasures the performance of the developmentand maintenance activities

ßVisibilityßallows access to status of both the process andproductsßfacilitates management

ßfacilitates teamwork


needrecognized

init. productdelivered

meets orig.requirements

redesign toimprove

new release

functionality

time

Process Qualities

ßTimeliness -- measures the ability to deliversoftware on time




High-level Goals of SE

ßimprove productivity

ßreduce resourcesße.g., time, cost, personnel

ßimprove predictability

ßimprove maintainability

ßimprove quality


Success of a system

ßA system is judged not by properties of thehardware and software, but by the effects ofthe system in the worldßyou don’t care how Caller ID works, just that itworks

ßpilots love TCAS (on the whole) because ithelps them fly more safely and easily—notbecause it has great data structures or afascinating specification


Process

ßNeed a process for:ßOrder of activities

ßProduct delivery (what, when)

ßAssignment to developers

ßMonitoring fi Measuring fi Planning

ßCannot be (easily) codified or standardized

ßIterative and incremental


What are the key(sub-)processesit must support

What are the key(sub-)processesit must support

UNDERSTANDING

USAGE

UNDERSTANDING, EVALUATION, STRESS TESTING

DEVELOPMENT

MODIFICATION

EVOLUTION

Software Processes

ßWhat do people want to do with (to) a product?ßFind out what it does (quickly, easily):

ßGet it to do what is needed (quickly, easily):

ßNot worry about it:

ßBuild it (quickly, easily, at low risk):

ßChange it as needed (quickly, easily)

ßImprove it (quickly, easily):




Process

ßCurrent Strong Emphasis on ProcessßProcess and Product complement each other

ßMore past focus on product

ßProcess focus has been less technicalßMore managerial


Traditional process models

ßCode & test

ßWaterfall

ßPrototyping

ßTransformational

ßSpiral


Early waterfall model

ßEarliest design and test FixFixCodeCode

SystemTestingSystemTesting

IntegrationTesting

IntegrationTesting

Code &Unit TestCode &Unit Test

DetailedDesignDetailedDesign

Preliminary Design

Preliminary Design

FeasibilityFeasibility

SpecificationSpecification

ArchitectureArchitecture

RequirementsRequirements

What’swrong

with this?

ßorder -- "what shall we do next?”

ßtransition criteria -- "how long shall we do it?"

What’swrong

with this?


1970’s

ßRecognition of feedback loopsßConfined to successive stages

ß“Build it twice”ßEarly prototyping


IntegrationTesting

IntegrationTesting



Preliminary Design

Preliminary Design





What’swrong

with this?




Reuse model

Repository

technical issues• create/recognize reusable component• cataloging & representation• Composition

management issues• NIH syndrome• development under T&M• granularity• CM across many reuses• ownership


IntegrationTesting

IntegrationTesting



Preliminary Design

Preliminary Design





What’swrong

with this?


"Throwaway" prototyping• technical issues

• rapid prototyping may create very different artifacts at each stage

• draw on many reuse repositories• management issues

• when to stop throwing away -- whenis a prototype not a prototype

• how to get the prototype back fromthe customer


IntegrationTesting

IntegrationTesting



Preliminary Design

Preliminary Design





PrototypesPrototypes









What’swrong

with this?


Evolutionary prototyping• technical issues

• "ILITY" at each level• documentation• timeliness• risk management, e.g., "feature

creep"• temporary "work arounds" become

permanent• management issues

• risk• when to stop• CM for this many artifacts

SystemTestingSystem

Testing

IntegrationTestingIntegration

Testing

Code &Unit TestCode &

Unit Test

DetailedDesignDetailed

Design

Preliminary DesignPreliminary

Design





SystemTestingSystem

Testing


Testing


Unit Test


Design


Design



SystemTestingSystem

Testing


Testing


Unit Test


Design


Design



What’swrong

with this?


Transformational Model

"Transformational" model

validation

optimizationConcrete

source code

tuning

formal repr.formal spec

maintenance

req.anal.

Repository

rationaledecisions,

informal specreq.anal. concretesource code

"code"

prototypevalidation

codeinformalreqmnts

validation

test

tuning

maintenance(variation of) Traditional Life Cycle

What’swrong

with this?




develop & verify

Boehm's Spiral Model

objectives

cost (cumulative)

risk analysisdetermine, elaborate

plan next phase

proto I

Conceptsof

operationsLC plan

anal

proto II

risk

models

design

design V&V

proto III

integration

test plan

riskanal

models

plan

begin

riskanal

CW

rqmnts

rqmnts

validation

riskanal

proto IV

design

unittest

benchmarks

test

code

acceptance


Boehm's Spiral Model

application rqmnts = low riskbudget, schedule = high risk

stable appl. rqmts & budgeterrors = high risk

application rqmnts = high riskbudget, schedule = low risk

SW

SystemTesting

IntegrationTesting

Code &Unit Test

DetailedDesign

PreliminaryDesign

Feasibility


SW Requirements

validation

optimization

Concretesource code

tuning

formal repr.

formal spec

maintenance

req.anal.

Repository

rationaledecisions,

SW

SW

SW


IBM-SSDGTESafeguardBoehm Sm

TRW80

20

80

20

1000

500

200

100

50

20

10

5

2

1

80

20

80

20

80

20

80

20

Rqmnts Design Code Devel. Test Accept. Test Operation

Phase in which error was detected & corrected

Barry Boehm SoftwareEngineering Economics

Increase in cost

•to fix or change throughout lifecycle

02-Products/Processes/Stakeholders Why engineer software?

Documents

Transcript of 02-Products/Processes/Stakeholders Why engineer software?