Software processes COSC 420 – Software Engineering Brian Toone

Dilbert on Software Engineering

Software Engineering

Last time…  A long time ago…  Introduction  Broad overview of software engineering

Review…  Software engineering is "[t]he application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software" IEEE STD , IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society,  Very broad discipline  Technical  Analysis and evaluation  Specification  Design  Software evolution  Non-technical  Management and quality  Novelty and creativity  Standards  Individual skills  Teamwork  Professional practice

Software processes 1  A.k.a. “software lifecycles”  Why do we need them?  Complexity of the system  Requirements will keep changing  Mistakes are monumentally expensive  Humans! Creative, unreliable, sickly, mercenary 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

Software processes, cont’d  Core/heart of software engineering  Recall – Software engineering is "[t]he application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software". 1  This is a process! 1 1 IEEE STD , IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.

Problem Solving Process 2  What is it?  Analysis  Design  Implementation  Testing  Before we talk specifically about software  Let’s talk about chickens 3 … 2 Adapted from James Cohoon and Jack Davidson’s slides for “Java 1.5 Program Design”. 3 Chicken pictures from

Problem Solving Process

Moving on to software processes  Many different software processes  We are going to look at a few in detail  In practice, most software projects may use a modified, merged, or mangled version of one or more processes

Software Process Discussion  Stake holders  client – person who puts up the bucks  user – person who uses the software  developer – person(s) who builds the software  Process Description  Formal or informal, written down somewhere or not  Steps (next slide)  Intermediate (and final) products  Controls (management, problems) 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

Software process steps  Goals – why this step?  Participants – who are the players?  Product – what is the output of this step?  Issues / Problems – what are the common problems or issues that come up in this step? 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

The Waterfall Model 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

Requirements analysis  Goals  Answer the question: what are we going to build?  Participants  Users  Engineers  Marketers  Analysts  Models, tools, methods  Use case analysis  Focus groups  Formal specification languages (Z)  Scenarios  Products  Requirements specification document (understandable, precise, complete)  Issues  Functional / non functional requirements  Preparation of user manual  System test descriptions  Details? 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

High-level design  Goals  Answer the question: how will we structure the system?  Participants  Architects  Marketers  Performance experts  Models, tools, methods  Architecture modeling languages (CORBA IDL, Wright, etc...)  Performance models / analysis tools  Boxes, arrows, and pictures  Products  High level design document (describes processes, major components, dependencies)  Issues  Architectural styles  Trade-offs: flexibility vs. efficiency  Personnel / organizational issues 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

Low-level design  Goals  Answer the question: what modules, objects, frameworks will we build?  Participants  OO Designers  Architects  Hotshot programmers  Models, tools, methods  UML, OMT, Rational Rose  Formalized boxes, pictures, and arrows  Products  Low level design documents  C/C++ header files  Issues  Styles: design patterns, algorithms, data structures  Trade-offs: space vs. time  Reuse of existing frameworks and libraries 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

Implementation  Goals  Crank the code, have no life.  Participants  Coldshot programmers (innocent, recent BS graduates)  Models, tools, methods  IDE (Microsot.NET, Borland JBuilder, etc...)  Products  Code  Issues  Coding standards and practices  Defensive coding 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

Testing / Verification  Goals  Find the bugs in the system  Participants  Interns, testers, statisticians  Models, tools, methods  Coverage testing (e.g., PureCov)  Abstract data flow models  Products  A tested system  Not necessarily bug free  Issues  Cost of testing vs. releasing product now and fixing later  Testing vs. inspection vs. formal verification  Black box vs. white box testing 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

The good and the bad  Good  Managers keep on top of things  Lots of paper. Organizational memory  Managing and avoiding conflicts  Less risk of the “oops” factor  Bad  Rigid, time-consuming  May miss time to market  Could be a down a lot of $$$ before revenue starts  Information may not be available when needed  Things may change!

Prototype / Evolutionary Model

The good and the bad  Good  Customers get quick look at product  Possible revenue early  Able to start tuning product to market  More fun for engineers  Competitors may find out!  Bad  Competitors may find out!  Can be chaotic  How do you build a prototype quickly?  Infrastructure available / expensive?  “Throw away mentality” might hurt quality

Ad Hoc Model Do stuff Ship! 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

The good and the bad  Good  Less bureaucratic  Less document intense  Easier to conceal from competitors  Bad  Only developers involved in entire product development  Very poor quality control  Difficult to diagnose problems  Difficult to improve 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission.

Other software processes  Build-and-fix model  This is an easy problem. Just DO it.  Rapid prototyping model  You will throw the first one away anyway.  Incremental model  Software is built, no written.  Agile model  Things are going to change, be flexible!  Spiral model  Software development is risky. Know the risks.  Capability maturity model  Control the development procedure and you control the product.  ISO-9000  Stress the documentation. Quality product will follow.

So…which one?  Which process are we going to use?  The contenders  Waterfall  Prototyping  Ad-hoc  Build-and-fix model  Rapid prototyping model  Incremental model  Agile model  Spiral model  Capability maturity model  ISO-9000

The answer is…  Agile!  Specifically, scrum  More in a bit…

But first … dangers of “winging it”

“When patents attack”