Software processes COSC 420 – Software Engineering Brian Toone.

Software Software processesprocessesCOSC 420 – Software EngineeringCOSC 420 – Software Engineering

Brian TooneBrian Toone

Dilbert on Software Dilbert on Software EngineeringEngineering

Software EngineeringSoftware Engineering

Last time…Last time…

A long time ago…A long time ago… IntroductionIntroduction Broad overview of software engineeringBroad overview of software engineering

Review…Review… Software engineering is "[t]he application of a systematic, Software engineering is "[t]he application of a systematic,

disciplined, quantifiable approach to the development, operation, disciplined, quantifiable approach to the development, operation, and maintenance of software".and maintenance of software".11

11 IEEE STD 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.

Very broad disciplineVery broad discipline TechnicalTechnical

Analysis and evaluationAnalysis and evaluation SpecificationSpecification DesignDesign Software evolutionSoftware evolution

Non-technicalNon-technical Management and qualityManagement and quality Novelty and creativityNovelty and creativity StandardsStandards Individual skillsIndividual skills TeamworkTeamwork Professional practice Professional practice

Software processesSoftware processes11

A.k.a. “software lifecycles”A.k.a. “software lifecycles” Why do we need them?Why do we need them?

Complexity of the systemComplexity of the system Requirements will keep changingRequirements will keep changing Mistakes are Mistakes are monumentallymonumentally expensive expensive Humans! Creative, unreliable, sickly, Humans! Creative, unreliable, sickly,

mercenarymercenary

11 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission. Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdfhttp://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

Software processes, Software processes, cont’dcont’d

Core/heart of software engineeringCore/heart of software engineering Recall – Recall – Software engineering is "[t]he application of a Software engineering is "[t]he application of a

systematic, disciplined, quantifiable approach to the systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software".development, operation, and maintenance of software".11

This is a process!This is a process!

11 IEEE STD 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.

Problem Solving ProcessProblem Solving Process22

What is it?What is it? AnalysisAnalysis DesignDesign ImplementationImplementation TestingTesting

Before we talk specifically about softwareBefore we talk specifically about software Let’s talk about chickensLet’s talk about chickens33……

22 Adapted from James Cohoon and Jack Davidson’s slides for “Java 1.5 Program Design”. Adapted from James Cohoon and Jack Davidson’s slides for “Java 1.5 Program Design”.33 Chicken pictures from http://corriehaffly.wordpress.com/ Chicken pictures from http://corriehaffly.wordpress.com/

Problem Solving ProcessProblem Solving Process

Testing

Design

Analysis

Implementation

Determine problem features

Describe objects and methods

Produce the classes and

code

Examine for correctness

Rethink as appropriate

Moving on to software processesMoving on to software processes

Many different software processesMany different software processes We are going to look at a few in detailWe are going to look at a few in detail In practice, most software projects may In practice, most software projects may

use a modified, merged, or use a modified, merged, or mangledmangled version of one or more processesversion of one or more processes

Software Process DiscussionSoftware Process Discussion

Stake holdersStake holders clientclient – person who puts up the bucks – person who puts up the bucks useruser – person who uses the software – person who uses the software developer developer – person(s) who builds the software– person(s) who builds the software

Process DescriptionProcess Description Formal or informal, written down somewhere or notFormal or informal, written down somewhere or not Steps (next slide)Steps (next slide) Intermediate (and final) productsIntermediate (and final) products Controls (management, problems)Controls (management, problems)



Software process stepsSoftware process steps

GoalsGoals – why this step? – why this step? ParticipantsParticipants – who are the players? – who are the players? ProductProduct – what is the output of this step? – what is the output of this step? Issues / ProblemsIssues / Problems – what are the – what are the

common problems or issues that come common problems or issues that come up in this step?up in this step?



The Waterfall ModelThe Waterfall Model



Requirements analysisRequirements analysis GoalsGoals

Answer the question: what are we going to build?Answer the question: what are we going to build? ParticipantsParticipants

UsersUsers EngineersEngineers MarketersMarketers AnalystsAnalysts

Models, tools, methodsModels, tools, methods Use case analysisUse case analysis Focus groupsFocus groups Formal specification languages (Z)Formal specification languages (Z) ScenariosScenarios

ProductsProducts Requirements specification document (understandable, precise, complete)Requirements specification document (understandable, precise, complete)

IssuesIssues Functional / non functional requirementsFunctional / non functional requirements Preparation of user manualPreparation of user manual System test descriptionsSystem test descriptions Details?Details?



High-level designHigh-level design GoalsGoals

Answer the question: how will we structure the system?Answer the question: how will we structure the system? ParticipantsParticipants

ArchitectsArchitects MarketersMarketers Performance expertsPerformance experts

Models, tools, methodsModels, tools, methods Architecture modeling languages (CORBA IDL, Wright, etc...)Architecture modeling languages (CORBA IDL, Wright, etc...) Performance models / analysis toolsPerformance models / analysis tools Boxes, arrows, and picturesBoxes, arrows, and pictures

ProductsProducts High level design document (describes processes, major components, High level design document (describes processes, major components,

dependencies)dependencies) IssuesIssues

Architectural stylesArchitectural styles Trade-offs: flexibility vs. efficiencyTrade-offs: flexibility vs. efficiency Personnel / organizational issuesPersonnel / organizational issues



Low-level designLow-level design

GoalsGoals Answer the question: what modules, objects, frameworks will we build?Answer the question: what modules, objects, frameworks will we build?

ParticipantsParticipants OO DesignersOO Designers ArchitectsArchitects Hotshot programmersHotshot programmers

Models, tools, methodsModels, tools, methods UML, OMT, Rational RoseUML, OMT, Rational Rose Formalized Formalized boxes, pictures, and arrowsboxes, pictures, and arrows

ProductsProducts Low level design documentsLow level design documents C/C++ header filesC/C++ header files

IssuesIssues Styles: design patterns, algorithms, data structuresStyles: design patterns, algorithms, data structures Trade-offs: space vs. timeTrade-offs: space vs. time Reuse of existing frameworks and librariesReuse of existing frameworks and libraries



ImplementationImplementation

GoalsGoals Crank the code, have no life.Crank the code, have no life.

ParticipantsParticipants Coldshot programmers (innocent, recent BS graduates)Coldshot programmers (innocent, recent BS graduates)

Models, tools, methodsModels, tools, methods IDE (Microsot .NET, Borland JBuilder, etc...)IDE (Microsot .NET, Borland JBuilder, etc...)

ProductsProducts CodeCode

IssuesIssues Coding standards and practicesCoding standards and practices Defensive codingDefensive coding



Testing / VerificationTesting / Verification

GoalsGoals Find the bugs in the systemFind the bugs in the system

ParticipantsParticipants Interns, testers, statisticiansInterns, testers, statisticians

Models, tools, methodsModels, tools, methods Coverage testing (e.g., PureCov)Coverage testing (e.g., PureCov) Abstract data flow modelsAbstract data flow models

ProductsProducts A tested systemA tested system Not necessarily bug freeNot necessarily bug free

IssuesIssues Cost of testing vs. releasing product now and fixing laterCost of testing vs. releasing product now and fixing later Testing vs. inspection vs. formal verificationTesting vs. inspection vs. formal verification Black box vs. white box testingBlack box vs. white box testing



The good and the badThe good and the bad

GoodGood Managers keep on top of Managers keep on top of

thingsthings Lots of paper. Lots of paper.

Organizational memoryOrganizational memory Managing and avoiding Managing and avoiding

conflictsconflicts Less risk of the “oops” Less risk of the “oops”

factorfactor

BadBad Rigid, time-consumingRigid, time-consuming May miss time to marketMay miss time to market Could be a down a lot of $Could be a down a lot of $

$$ before revenue starts$$ before revenue starts Information may not be Information may not be

available when neededavailable when needed Things may change!Things may change!

Prototype / Evolutionary ModelPrototype / Evolutionary Model


GoodGood Customers get quick look Customers get quick look

at productat product Possible revenue earlyPossible revenue early Able to start tuning Able to start tuning

product to marketproduct to market More fun for engineersMore fun for engineers Competitors may find out!Competitors may find out!

BadBad Competitors may find out!Competitors may find out! Can be chaoticCan be chaotic How do you build a How do you build a

prototype quickly?prototype quickly? Infrastructure available / Infrastructure available /

expensive?expensive? ““Throw away mentality” Throw away mentality”

might hurt qualitymight hurt quality

Ad Hoc ModelAd Hoc Model

Do stuff

Ship!




GoodGood Less bureaucraticLess bureaucratic Less document intenseLess document intense Easier to conceal from Easier to conceal from

competitorscompetitors

BadBad Only developers involved Only developers involved

in entire product in entire product developmentdevelopment

Very poor quality controlVery poor quality control Difficult to diagnose Difficult to diagnose

problemsproblems Difficult to improveDifficult to improve



Other software processesOther software processes

Build-and-fix modelBuild-and-fix model This is an easy problem. Just DO it.This is an easy problem. Just DO it.

Rapid prototyping modelRapid prototyping model You will throw the first one away anyway.You will throw the first one away anyway.

Incremental modelIncremental model Software is built, no written.Software is built, no written.

Agile modelAgile model Things are going to change, be flexible!Things are going to change, be flexible!

Spiral modelSpiral model Software development is risky. Know the risks.Software development is risky. Know the risks.

Capability maturity modelCapability maturity model Control the development procedure and you control the product.Control the development procedure and you control the product.

ISO-9000ISO-9000 Stress the documentation. Quality product will follow.Stress the documentation. Quality product will follow.

So…which one?So…which one? Which process are we going to use?Which process are we going to use? The contendersThe contenders

WaterfallWaterfall PrototypingPrototyping Ad-hocAd-hoc Build-and-fix modelBuild-and-fix model Rapid prototyping modelRapid prototyping model Incremental modelIncremental model Agile modelAgile model Spiral modelSpiral model Capability maturity modelCapability maturity model ISO-9000ISO-9000

The answer is…The answer is…

Agile!Agile! Specifically, scrumSpecifically, scrum More in a bit…More in a bit…

But first … dangers of But first … dangers of “winging it”“winging it”

““When patents attack”When patents attack”http://www.thisamericanlife.org/play_full.php?play=441

Software processes COSC 420 – Software Engineering Brian Toone.

Documents

maintenance of software

software lifecycleswhy

software processescosc

software projects

ieee std

process stepsgoals

ieee computer society

issues problems