Introduction to Software Engineering Lecture 7-1 May 12, 2015

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. SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Department of Informatics, UC Irvine

Todays lecture Midterm answers More Software Process Models Quiz 4 study guide SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 2 Department of Informatics, UC Irvine

Todays lecture Midterm answers More Software Process Models Quiz 4 study guide SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 3 Department of Informatics, UC Irvine

Todays lecture Midterm answers More Software Process Models Quiz 4 study guide SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 4 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 5 Department of Informatics, UC Irvine

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?) SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 6 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 7 Department of Informatics, UC Irvine

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

Spiral Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 9 Department of Informatics, UC Irvine

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

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 11 Department of Informatics, UC Irvine

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 12 Department of Informatics, UC Irvine

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 13 Department of Informatics, UC Irvine

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 14 Department of Informatics, UC Irvine

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 15 Department of Informatics, UC Irvine

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 16 Department of Informatics, UC Irvine

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 17 Department of Informatics, UC Irvine

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 18 Department of Informatics, UC Irvine

Spiral Risk analysis Risk analysis Risk analysis Risk analysis SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 19 Department of Informatics, UC Irvine

Software Risks: Some of Boehms Top 10 Risk Risk Management Techniques Personnel shortfalls Staff with top talent, job matching, morale building Unrealistic schedules and budgets Detailed cost/schedule estimation, reuse, incremental development Developing the wrong software functions User surveys, prototyping Continuing stream of software changes Information hiding, incremental development Shortfalls in externally furnished components Compatibility analysis Shortfalls in externally performed tasks Reference checking, competitive design or prototyping Adapted from Hans Schaefer s Software Risk Management: A Calculated Gamble SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 20 Department of Informatics, UC Irvine

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

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

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

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 24 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 25 Department of Informatics, UC Irvine

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

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

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

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

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

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) SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 31 Department of Informatics, UC Irvine

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) SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 32 Department of Informatics, UC Irvine

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 email Version control and repositories, bug trackers Scales up amazingly well Where do they find the time? SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 33 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 34 Department of Informatics, UC Irvine

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

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

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) SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 37 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 38 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 39 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 40 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 41 Department of Informatics, UC Irvine

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) SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 42 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 43 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 44 Department of Informatics, UC Irvine

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

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

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

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 48 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 49 Department of Informatics, UC Irvine

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 SDCLCollaboration Laboratory Software Design and sdcl.ics.uci.edu 50 Department of Informatics, UC Irvine