1. Software processes COSC 420 – Software Engineering Brian Toone

2. Dilbert on Software Engineering

3. Software Engineering

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

5. Review…  Software engineering is "[t]he application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software". 1 1 1 IEEE STD 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.  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

6. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

7. 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 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.

8. 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 http://corriehaffly.wordpress.com/

9. Problem Solving Process

10. 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

11. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

12. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

13. The Waterfall Model 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

14. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

15. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

16. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

17. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

18. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

19. 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!

20. Prototype / Evolutionary Model

21. 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

22. Ad Hoc Model Do stuff Ship! 1 Adapted from Premkumar Devanbu’s “Software Process” lecture. Used with permission. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

23. 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. http://www.cs.ucdavis.edu/%7Edevanbu/teaching/160/l3.pdf

24. 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.

25. 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

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

27. But first … dangers of “winging it”

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