Theory Lecture Plan 2 Software Configuration Lecture 11 Software Engineering TDDC88/TDDC93 autumn 2008 Department of Computer and Information Science Linköping University, Sweden L1 - Course Introduction and Overview L2 - Project L3 - L4 - Acceptance Testing and Quality Factors L5 - UML L6 Design Patterns L7 System design and architecture L8 - Testing Theory L9 - Testing in Practice L10 - Inspection L11 - Software Configuration L12 - Software Quality L13 - Course Summary, Exam examples, Questions I A Software Life-cycle Model Which part will we talk about today? 3 Agenda - What will you learn today? 4 Validate, Verify Specification Acceptance Test (Release testing) System Design (Architecture, High-level Design) Verify System Design (Integration testing of modules) Module Design (Program Design, Detailed Design) of Units (classes, procedures, functions) Verify Module Design Verify Unit testing Module Testing (Integration testing of units) I Software Configuration Project, Software Quality Assurance (SQA), Supporting Tools, Education I I 1
5 Project vs. Process Project 6 Start and stop Goal An orderer A budget A single-time occurrence Process May contain subprocesses Ordered set of activities Activity 1 Activity 2 Activity 3 Processes are reoccurring I Goal of each activity Each activity has entry/exit criteria and input/output. I Constraints Software life-cycle model (Repetiotion L1) 7 Model of a life-cycle (a Process Model) 8 Software Life-Cycle (Software Engineering Process) Model Idea Stockholm Subway Map Software Product the customer Abstraction Carol A software life-cycle model (Software Engineering Process Model) Very Complex Software Process Diana the developer I I 2
A familiar model? System Design (Architecture, High-level Design) Validate, Verify Specification Verify System Design Acceptance Test (Release testing) 9 (Integration testing of modules) The V-model System Design (Architecture, High-level Design) System Design Validate, Verify Specification Feedback and iterations are possible Acceptance Test (Release testing) Acceptance Test 10 (Integration testing of modules) Module Design (Program Design, Detailed Design) Verify Module Design Verify Module Testing (Integration testing of units) Verify Design Module Design (Program Design, Detailed Design) Program Design Module Testing Integration (Integration testing of units) Testing of Units (classes, procedures, functions) Unit testing of Units (classes, procedures, functions) Unit testing I I Another model... System Design Program Design Integration Testing Acceptance Test 11 The Waterfall model One of the first life-cycle models (Royce, 1970) Very common, very criticized Integration Testing 12 System Design Finish each phase before continue Program Design to next. Why is the waterfall model so criticized? Which are the problems? Can it be useful sometimes? Milestone and deliverable at each step. (Artifacts such as Design Acceptance Test document, Req. Specification. etc.). I I 3
The Waterfall model - some arguments 13 The Waterfall model - some arguments 14 Pros Simple, manageable and easy to understand Fits to common project management practices (milestones, deliverables etc.) Focus on requirements and design at beginning, save money and time at the end Can be suitable for short projects (some weeks) Can be suitable for "stable" projects, where requirements do not change Focus on documents, saves knowledge which can be reused by other people. Widely used, e.g. US Department of Defense Can be suitable for fixed-price contracts Cons Software requirements change, hard to sign-off on a SRS. Early commitment. Changes at the end, large impact. Feedback is needed to understand a phase. E.g. implementation is needed to understand some design. Difficult to estimate time and cost for the phases. Handling risks are not part of the model. Pushes the risks forward. Software "is not" developed in such a way. It evolves when problems are more understood. Little room for problem solving. I I Can we improve the model? 15 Do it twice? 16 Iteration back to previous phase Second round, do it right. The original paper is actually misunderstood! System Design Program Design System Design Program Design (Royce, 1970) includes Iteration of phases "Do it twice" prototype Integration Testing First round, a prototype Integration Testing Danger! E.g. a performance problem can result in a major requirements change. Very expensive rollback... Acceptance Test Input to the phases in the second round Acceptance Test I I 4
Is overlapping phases a solution? 17 Is overlapping phases a solution? 18 When do we "sign-off", e.g. when do we have all requirements? What kind of structure have we actually achieved? No sign-off. How does this help us? requirements What if a major design flaw is discovered at the testing phase? requirements design implementation Release! design implementation Release! test test deployment I I What should be built? 19 Iterative Development 20 The hardest single part of building a software system is deciding precisely what to build (Frederick P. Brooks) When should the releases take place? -boxing - The time period is fixed for each iteration. What should be included in the release? Prioritized functionality - Do the most important parts first. Customer Feedback Customer Feedback How? By delivering several releases? R1 R2 Final Release! design implementation Release! design implementation test deployment Iteration 1 Iteration 2 test Iteration deployment 3 I I 5
Dependent project parameters (revisited) 21 Prioritization - some matrices 22 Calendar time and resources are fixed Customer Benefit Importance Calendar Resources High Sweet Spot High Sweet Spot Project Features Select the most important functions Select quality. E.g. how general should we be? Quality Low Low Avoid Low High Development Effort Avoid Low High Urgency I I Iterative vs. Incremental Development Incremental Development Add a new "part" at each increment Iterative Development Improve a "working system" at each iteration design Working Working Working System v0.1 System v0.2 System v0.3 implementation Iteration 1 Iteration 2 test Iteration deployment 3 I 23 Note. Both concepts are often combined and sometimes misleading called just iterative development. Spiral Model Determine goals, alternatives, and constrains RA = Risk Analysis P1 = Prototype 1 CO = Concepts of operation Plan Next Phase BAC BAC BAC = Budget, Alteranatives, Constraints BAC Req. plan Dev. plan Integration and test plan RA RA RA RA P1 CO SW. req. Validate req. verify design Acceptance test P2 P3 P4 SW. design Detailed Design Code Unit test System test I 24 Evaluate Alternatives and risks Main feature: RISKS Develop and Test 6
Iterative Development - Cons 25 Iterative Development - Pros 26 Is iterative development the silver bullet? design Iteration 1 Customer Feedback R1 implementation Problem with current business contracts, especially fixed-price contracts. With small iterations, can be hard to map customer requirements to iterations. Customer Feedback R2 Iteration 2 test Iteration deployment 3 Final Release! Pros Misunderstandings and inconsistency are made clear early (e.g. between requirement, design, and implementation) Encourage to use feedback -> elicit the real requirements Forced to focus on the most critical issues Continuous testing offers a project assessment Workload is spread out over time (especially test) The team can get "lesson learned" and continuously improve the process Stakeholders gets concrete evidence of progress I I 27 We are using an iterative process! 28 Define a plan with 1..N iterations. We do not have to care about plans... Now, let's hack! Is this a good iterative process? Harry the hacker Of course not. We need some structure! Methodologies and defined Processes I I 7
Processes, Models, Methodologies... Waterfall model Which is the "best" approach? V- model Spiral model Extreme Programming (XP) "what" at a high level of abstaction Prototype model agile methods 29 Processes, Models, Methodologies... Waterfall Prototype model model Question: What V- model is the difference Spiral model between a methodologist and a terrorist? Answer: You can negotiate with a terrorist. Extreme Programming (XP) "what" at a high level of abstaction agile methods 30 Rational Unified Process (RUP) Methodologies and defined Processes Scrum "what" and to a certain level "how" Rational Unified Process (RUP) Methodologies and defined Processes Scrum "what" and to a certain level "how" I I Goals with a software development process 31 What is Rational Unified Process (RUP)? 32 Guidance about order and content of team activities. Specify when and which artifact that should be produced. Direct individual developers' tasks and the team as a whole Give criteria for monitoring and measuring activities and generated products. A software engineering process A disciplined approach to produce high quality software A process product A software (web based) offered by IBM (earlier Rational) OpenUP/Basic, an lightweight open source variant A process framework Adapted and extended to suit a specific organization I I 8
RUP - Elements of the Process 33 Disciplines 34 The "container" for the four elements: roles, activities, artifacts and workflows is assigned to a Business Modeling Activities: the how Roles: the who e.g. system analyst, designer, test designer creates, modifies, controls Core Technical Disciplines Analysis and Design Test Deployment Workflows: the when Core workflow to each discipline Artifact: the what e.g. use-case models, source code, documents (same as deliverable) I Core Supporting Disciplines Change & Config. Mgm. Project Mgm. Environment. I RUP- Phases and Milestones 35 RUP- Phases and Milestones 36 Inception Formulate scope Capture most important requirements Plan, risk, staffing, project plan Synthesize a candidate architecture The project may be cancelled after this phase similar to a "Pre-study" Elaboration Define architecture Specify requirements more precisely Executable architecture prototype Define project plan Phase Life-cycle objective milestone Milestone Life-cycle architecture milestone Inception (10%) Inception (10%) Elaboration (30%) I I 9
RUP- Phases and Milestones 37 RUP- Phases and Milestones 38 Construction Resource management and control Design,, and Testing Output (software + documentation) ready for users. of the product to users Beta-testing Training of users and maintainers Rollout of the product to operational environment Initial Operational Capability milestone (beta-release) Product release milestone Inception (10%) Elaboration (30%) Construction (50%) Inception (10%) Elaboration (30%) Construction (50%) (10%) I I RUP- Phases and Milestones 39 Disciplines and Phases 40 Was not RUP iterative??? Business Modeling Inception Elaboration Construction Internal milestones and releases Iterations within phases Core Technical Disciplines Analysis and Design Test Deployment Inception (10%) I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 Elaboration (30%) Construction (50%) (10%) Core Supporting Disciplines Change & Config. Mgm. Project Mgm. Environment. I I 10
Agile Approaches - Agile Alliance 41 Extreme Programming - Values and Principles 42 Lightweight approaches to satisfy the customers with "early and continuous delivery of valuable software" Manifesto for Agile Software development Favor Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan (http://agilemanifesto.org, 2001) A lightweight methodology for vague or rapidly changing requirements Communication Simplicity Feedback Changes need feedback Courage "If you know what the problem is, do something" Respect Mutual benefit "win-win", automated testing Values Reflection "How" and "why" are we working Principles Redundancy If it fails. E.g. pair programming. Practices Baby steps "What is the least that you can do that can be shown to be in the right direction?" I I Extreme Programming - Some Practices 43 Scrum 44 Pair Programming Focus on task Clarify ideas Rotate frequently Continuous Integration Integrate and test often Automated build system Automated regression tests (e.g. JUnit) Refactoring Behavior preserving transformation Tool support, e.g. Eclipse Stories "requirements", but not mandatory Name + short story On index cards (paper) Test-First Programming Create tests before code Focus on interface and "what is needed" Gets tests for free Approach public in 1996 at OOPSLA (Ken Schwaber, Jeff Sutherland) "Scrum" strategy used in rugby for getting and out-of-play ball back into play. I I 11
Scrum Overview 45 46 Product backlog All requirements Prioritized only by product owner Never finalized Sprint backlog What to do in one sprint Daily Scrum Short (15 min) done since last meeting, todo, problems Pick from sprint backlog I From anyone (users, customers, sales) Sprint planning meeting Sprint 30 - days iteration product increment Plan what to do in the next sprint (sprint = one iteration) Scrum Master Enforce scrum practices Executable Product Increment I I What is configuration management? 47 What is configuration management? 48 Configuration Item Identification Source code modules Test scripts Design documents Build systems SCM File A v.03 File C v.3.3 File B v0.1 Change File A v.03 File C v.3.4 File B v0.1 Change File A v.03 File C v.3.3 File B v0.11 Baseline - a "snap-shot" of configuration items. Normally reviews in some way. How do we control changes? I I 12
What is configuration management? 49 What is configuration management? 50 Configuration Item Identification Source code modules Test scripts Design documents Build systems SCM Change Control Board (CCB) Make change decisions. Only large changes (e.g. new major requirements) Configuration control Only authorized people may make changes Larger changes - change requests I CHANGE REQUEST Project: Classification: Priority: Date: Change Description: Configuration Item Identification Source code modules Test scripts Design documents Build systems Auditing Ensure that the items are complete and consistent. Make sure that the configuration is tested and meets requirements. SCM Configuration control Larger changes - change requests Status accounting I Document and report changes to those involved. SCM tools 51 Version handling example 52 Change Workflow systems Define processes for change requests Change report system Bug-tracking New features Change request (e.g free alternatives: Bugzilla, Trac) Locked checkout / no locks What is a bug / what is a feature? Tool examples: Clear Case, Visual Source safe Perforce, CVS Subversion Development Branch(s) v1.1.24.1 v1.1.24.2 Test Merge Trunk v1.0.23 v1.0.24 v1.0.25 v1.0.26 Commit - add comments Release Branch(s) v1.2.24 History - Find where the fault was added Blame - Who added a certain code line SCM Tools Diff - What has changed between two versions? I I 13
Sync- and Stabilize (e.g. Microsoft) 53 Summary - What have we learned today? 54 Implement new stuff Fail? Success? (Report via e- mail, redlamp etc.) Automatic blame :-) Commit to SCM repository Smoke test (automatic test of system) Daily build (automatic compile and link) Stub-out e.g. user interfaces and databases Waterfall model V-Model Iterative models Spiral model RUP Agile XP Scrum I Software Configuration Identification Control Status accounting Auditing I I Further reading (Books) 55 Further reading (Web) 56 Rational Unified Process (RUP) Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition, ISBN 0321197704, Addison-Wesley Professional, USA, 2003 Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP, ISBN: 0321166094, Addison-Wesley Professional, USA, 2003 Extreme Programming Extreme Programming, a gentle introduction http://www.extremeprogramming.org/ Agile, Extreme Programming, Scrum Kent Beck and Cynthia Andres, Extreme Programming Explained: Embrace Change, Second Edition, ISBN 0321278658, Addison-Wesley Professional, USA, 2004 Ken Schwaber and Mike Beedle, Agile Software Development with Scrum, ISBN 0130676349, Prentice Hall, NJ, USA, 2002 Mary Poppendieck and Tom Poppendieck, Lean Software Development: An Agile Toolkit, ISBN 0321150783, Addison-Wesley Professional, USA, 2003 Configuration Alexis Leon, Handbook, Second Edition, ISBN 1580538827, Artech House Publishers, MA, USA, 2005 I I 14