Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering Lecture 7-1 May 12, 2015 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 2 Today’s lecture Midterm answers More Software Process Models Quiz 4 study guide

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 3 Today’s lecture Midterm answers More Software Process Models Quiz 4 study guide

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 4 Today’s lecture Midterm answers More Software Process Models Quiz 4 study guide

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 5 Processes as a Remedy Software is engineered via a defined process – Cover all steps from initial idea and requirements to delivery, maintenance, and final retirement – Make sure we do the right things/we do things right – Make sure we do not forget to do anything – Different processes for different kinds of software Not a silver bullet [Brooks “No Silver Bullet”] – Software is still intrinsically difficult to deal with – Processes help, but cannot guarantee anything Remember: People + Processes + Tools  Product

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 6 Processes Elements – Activities (“Phases”) – Artifacts E.g., requirements document, design document, code, test cases… Can include process specifications – Resources People (their time and their cost) Tools (their time and their cost) Relationships between the elements – Precedence, requires, provides, refines to, … Constraints – Time – Cost – Qualities (repeatable process?)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 7 Software Life Cycle Models Build-and-fix Waterfall Rapid prototyping Incremental Spiral Rational Unified Process (RUP) Open Source Software (OSS) Extreme Programming (XP) Agile A software life cycle model is a high-level process

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 8 Software Life Cycle Models Build-and-fix Waterfall Rapid prototyping Incremental Spiral Rational Unified Process (RUP) Open Source Software (OSS) Extreme Programming (XP) Agile A software life cycle model is a high-level process Covered in Lecture 5-2

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 9 Spiral Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 10 Each loop through the spiral… Identify a high-risk sub-problem or aspect Resolve the risk (as far as possible) Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 11 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 12 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 13 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 14 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 15 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 16 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 17 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 18 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 19 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 20 Software Risks: Some of Boehm’s Top 10 RiskRisk Management Techniques Personnel shortfallsStaff with top talent, job matching, morale building Unrealistic schedules and budgetsDetailed cost/schedule estimation, reuse, incremental development Developing the wrong software functionsUser surveys, prototyping Continuing stream of software changesInformation hiding, incremental development Shortfalls in externally furnished components Compatibility analysis Shortfalls in externally performed tasksReference checking, competitive design or prototyping Adapted from Hans Schaefer’s “Software Risk Management: A Calculated Gamble”

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 21 Full Spiral

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 22 So… What is it good for? (strengths) What is it bad for? (weaknesses)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 23 So… What is it good for? (strengths) – Large, expensive, complicated projects – New projects with uncertain, complex requirements What is it bad for? (weaknesses)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 24 So… What is it good for? (strengths) – Large, expensive, complicated projects – New projects with uncertain, complex requirements What is it bad for? (weaknesses) – Small projects – Developers have to be competent at risk analysis

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 25 Rational Unified Process Influential, best practices of its time (1990s, Object-Oriented SE) More realistic depiction of – The non-discrete nature of SE – The need to have flexibility/adaptability in the process itself – The interplay of Processes Time Various SE activities over time – Much more… Workflows, Activities, Artifacts, Workers… Makes more sense if you are a project manager…

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 26 The RUP Model Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements ElaborationTransitionInceptionConstruction Workflows group activities logically In an iteration, you walk through all workflows

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 27 RUP Workflow: Architectural Analysis

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 28 RUP Activity: Use Case Analysis

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 29 The steps of use-case-analysis

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 30 So… What is it good for? (strengths) What is it bad for? (weaknesses)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 31 So… What is it good for? (strengths) – Risk-driven, incremental – Lots of tool support – Provides a lot of guidance What is it bad for? (weaknesses)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 32 So… What is it good for? (strengths) – Risk-driven, incremental – Lots of tool support – Provides a lot of guidance What is it bad for? (weaknesses) – Complicated (need a process expert to implement it)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 33 Open-Source Software (OSS) Source code is freely available and (usually) re-distributable Many contributors working in a distributed manner – Coders – Bug finders – Documenters – Project leadership – Often volunteers Heavy reliance on software tools – The web and – Version control and repositories, bug trackers Scales up amazingly well Where do they find the time?

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 34 OSS: Only Two Phases First, develop the initial version – Usually one or a small number of developers Second, maintain (evolve!) – Users become co-developers (co-maintainers!) – Report and correct defects Corrective maintenance – Enhance and add new functionality Perfective maintenance – Port to a different environment Adaptive maintenance

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 35 OSS Success Stories Operating systems – Linux Web browser – Firefox Compiler – gcc Web server – Apache Database – MySQL Healthcare – Mirth

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 36 So… What is it good for? (strengths) What is it bad for? (weaknesses)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 37 So… What is it good for? (strengths) – Software that benefits developers (oftentimes extends to the public at large) – Some of the greatest minds, motivated and working together to solve hard problems can result in huge advances What is it bad for? (weaknesses)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 38 So… What is it good for? (strengths) – Software that benefits developers (oftentimes extends to the public at large) – Some of the greatest minds, motivated and working together to solve hard problems can result in huge advances What is it bad for? (weaknesses) – Proprietary software – Software with strict requirements and/or tight deadlines

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 39 Extreme Programming (XP) More “extreme” reaction to Waterfall, other heavyweights… Kent Beck (also Ron Jeffries) – Software engineering consists of Listening, Testing, Coding, Designing – Based on Values of Simplicity, Communication, Feedback, Courage – Works by Simple practices, such as bringing/keeping the team together Just enough feedback to know where you are Just enough (and just in time) “heavier” activities More “programmer welfare” than other process models…

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 40 XP Practices and Principles (I) Whole team – Customer on site, part of the team Planning game – Once per iteration Small releases Customer tests Simple design – “Simple is best” – Refactoring encouraged Pair programming Test-driven development Design improvement – Refactor whenever, wherever possible

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 41 XP Practices and Principles (II) Continuous integration – Everyone works on the most recent version of the code Collective code ownership – Anyone can change any part of code – All team members work on all development activities Coding standards – Promotes shared understanding Metaphor – A “story” about the system Sustainable pace – 40-hour work weeks – short iterations Open space – Especially for pair programming

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 42 XP Process Steps Determine the desired features (stories) – Estimate time/cost (effort) per feature – Client can help determine order of development Story prioritization Stories further refined into development tasks Implement/deliver each task – Typically using… Test-driven development Pair programming Follow values and principles – (See previous slides)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 43 XP Philosophies (I) Rapid, fine feedback – Frequent testing – On-site customer – Pair programming Continuous process – Continuous integration – Merciless refactoring – Small, frequent releases From Glenn Vanderburg, Delphi Consultants

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 44 XP Philosophies (II) Shared understanding – Planning game – Simple design – System metaphor – Collective code ownership – Coding conventions Developer welfare – Forty hour week From Glenn Vanderburg, Delphi Consultants

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 45 XP in Action

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 46 Test-Driven Development

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 47 SimSE XP Demo

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 48 From XP to Agile Agile includes and evolved from – Extreme Programming – SCRUM, Crystal, others The Agile Manifesto (2001) – “We have come to value…” – Individuals and interactions Over processes and tools – Working software Over comprehensive documentation – Customer collaboration Over contract negotiation – Responding to change Over following a plan

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 49 Some Agile Principles Satisfy the customer – Through early and continuous delivery of valuable software Welcome change in requirements – Even late in development – Harness change for competitive advantage Deliver working software frequently – In weeks or a couple of months Timeboxing Sprints

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 50 More Agile Principles Business people and developers work together daily throughout the project – Stand-up meetings Build projects around motivated individuals – Give them the environment and support they need Best method of conveying information during development is face-to-face conversation – Informal communication – Stand-up meetings Documentation is just a means to an end – Do only the necessary amount – Source code is the biggest part of the documentation

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 51 So… What is it good for? (strengths) What is it bad for? (weaknesses)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 52 So… What is it good for? (strengths) – Customer satisfaction – Adaptable to changing circumstances – Good for projects with unclear, changing requirements – Good for small teams What is it bad for? (weaknesses)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 53 So… What is it good for? (strengths) – Customer satisfaction – Adaptable to changing circumstances – Good for projects with unclear, changing requirements – Good for small teams What is it bad for? (weaknesses) – Lack of documentation – Unstable requirements – Bad for projects with large teams – Bad for projects in which customer involvement is not possible

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 54 A Comparison of Life Cycle Models ModelStrengthsWeaknesses Build-and-FixFine for small programs that do not require much maintenance Totally unsatisfactorily for nontrivial programs WaterfallDisciplined approach Document driven Delivered product may not meet client’s needs Rapid Prototyping Ensures that delivered product meets client’s needs A need to build twice Cannot always be used IncrementalMaximizes early return on investmentRequires open architecture May degenerate into build-and-fix XPCustomer involvement and frequent releases promote customer satisfaction Cannot be used for large teams Requires large time commitment by customer SpiralIncorporates features of all the above models Developers have to be competent at risk- analysis RUPRisk-driven, incremental, lots of guidance Complicated, requires a process expert

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 55 Some real life examples

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 56 Today’s lecture Midterm answers More Software Process Models Quiz 4 study guide

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 57 Quiz 4 Textbook: – Section 4.1 Discussion: – SimSE exercise Lecture: – Know characteristics, strengths, and weaknesses of Spiral Rational Unified Process (RUP) Open Source Software (OSS) Extreme Programming (XP) Agile

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 58 Reminder Homework 2A due tonight, 11:55pm – No late assignments accepted except for extenuating circumstances as described in first lecture – Don’t forget your github username at the top of your document