Software Life Cycles and Configuration Management

Transcription

1 Software Configuration Lecture 11 Software Engineering TDDC88/TDDC93 autumn 2008 Department of Computer and Information Science Linköping University, Sweden Theory Lecture Plan 2 L1 - Course Introduction and Overview L2 - Project L3 - Requirements 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 1

2 A Software Life-cycle Model Which part will we talk about today? Maintenance 3 Requirements Validate Requirements, Verify Specification Acceptance Test (Release testing) System Design (Architecture, High-level Design) Module Design (Program Design, Detailed Design) Verify System Design Verify Module Design Verify Implementation System Testing (Integration testing of modules) Module Testing (Integration testing of units) Implementation of Units (classes, procedures, functions) Unit testing Project, Software Quality Assurance (SQA), Supporting Tools, Education I Agenda - What will you learn today? 4 I Software Configuration I 2

3 5 I 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 Goal of each activity Each activity has entry/exit criteria and input/output. I Constraints 3

4 Software life-cycle model (Repetiotion L1) 7 Software Life-Cycle (Software Engineering Process) Idea Software Product Model Stockholm Subway Map A software life-cycle model (Software Engineering Process Model) Very Complex Software Process I Model of a life-cycle (a Process Model) 8 Carol the customer Abstraction Diana the developer I 4

5 A familiar model? 9 Maintenance Requirements Validate Requirements, Verify Specification Acceptance Test (Release testing) System Design (Architecture, High-level Design) Verify System Design System Testing (Integration testing of modules) Module Design (Program Design, Detailed Design) Verify Module Design Verify Implementation Module Testing (Integration testing of units) Implementation of Units (classes, procedures, functions) Unit testing I The V-model Requirements Requirements System Design (Architecture, High-level Design) System Design Validate Requirements, Verify Specification Feedback and iterations are possible Acceptance Test (Release testing) Acceptance Test 10 Maintenance Maintenance System Testing (Integration testing of modules) System Testing Module Design Verify Design (Program Design, Detailed Design) Program Design Implementation Implementation of Units (classes, procedures, functions) Module Testing Integration Testing Unit testing (Integration testing of units) I 5

6 Another model Maintenance Requirements Acceptance Test System Design System Testing Program Design Integration Testing Implementation I The Waterfall model Requirements 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? Implementation Which are the problems? Can it be useful sometimes? System Testing Milestone and deliverable at each step. (Artifacts such as Design Acceptance Test document, Req. Specification. etc.). Maintenance I 6

7 The Waterfall model - some arguments 13 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 I The Waterfall model - some arguments 14 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 7

8 Can we improve the model? 15 Requirements Iteration back to previous phase System Design Program Design Implementation Integration Testing System Testing Danger! E.g. a performance problem can result in a major requirements change. Very expensive rollback... I Acceptance Test Maintenance Do it twice? 16 Second round, do it right. Requirements System Design Program Design The original paper is actually misunderstood! (Royce, 1970) includes Iteration of phases "Do it twice" prototype First round, a prototype Implementation Integration Testing System Testing Acceptance Test Input to the phases in the second round Maintenance I 8

9 Is overlapping phases a solution? 17 When do we "sign-off", e.g. when do we have all requirements? requirements design implementation What if a major design flaw is discovered at the testing phase? Release! test I Is overlapping phases a solution? 18 What kind of structure have we actually achieved? No sign-off. How does this help us? requirements design implementation Release! test deployment I 9

10 What should be built? 19 The hardest single part of building a software system is deciding precisely what to build (Frederick P. Brooks) How? By delivering several releases? design implementation Release! test deployment I Iterative Development When should the releases take place? -boxing - The time period is fixed for each iteration. Customer Feedback What should be included in the release? Prioritized functionality - Do the most important parts first. Customer Feedback 20 R1 R2 Final Release! design implementation Iteration 1 Iteration 2 test Iteration deployment 3 I 10

11 Dependent project parameters (revisited) 21 Calendar time and resources are fixed Calendar Resources Project Features Select the most important functions Select quality. E.g. how general should we be? Quality I Prioritization - some matrices 22 Customer Benefit Importance High Sweet Spot High Sweet Spot Low Avoid Low Avoid Low High Development Effort Low High Urgency I 11

12 Iterative vs. Incremental Development Incremental Development Add a new "part" at each increment 23 Iterative Development Improve a "working system" at each iteration Note. Both concepts are often combined and sometimes misleading called just iterative development. design Working Working Working System v0.1 System v0.2 System v0.3 implementation Iteration 1 Iteration 2 test Iteration deployment 3 I Spiral Model 24 Determine goals, alternatives, and constrains BAC RA RA Evaluate Alternatives and risks BAC BAC RA RA P1 P2 P3 P4 Main feature: RISKS RA = Risk Analysis P1 = Prototype 1 CO = Concepts of operation BAC = Budget, Alteranatives, Constraints Plan Next Phase Req. plan Dev. plan Integration and test plan CO Validate req. verify design Acceptance test SW. req. SW. design Detailed Design Code Unit test System test Develop and Test I 12

13 Iterative Development - Cons Is iterative development the silver bullet? 25 Problem with current business contracts, especially fixed-price contracts. With small iterations, can be hard to map customer requirements to iterations. Customer Feedback Customer Feedback R1 R2 Final Release! design Iteration 1 implementation Iteration 2 test Iteration deployment 3 I Iterative Development - Pros 26 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 13

14 27 I 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! Harry the hacker Is this a good iterative process? Of course not. We need some structure! Methodologies and defined Processes I 14

15 Processes, Models, Methodologies... Waterfall model V- model Spiral model "what" at a high level of abstaction Prototype model 29 Which is the "best" approach? Rational Unified Process (RUP) Extreme Programming (XP) Methodologies and defined Processes Scrum agile methods "what" and to a certain level "how" I Processes, Models, Methodologies... "what" at a high level of abstaction Waterfall Prototype model model Question: What V- model is the difference Spiral model between a methodologist and a terrorist? 30 Answer: You can negotiate with a terrorist. Extreme Programming (XP) agile methods Rational Unified Process (RUP) Methodologies and defined Processes Scrum "what" and to a certain level "how" I 15

16 Goals with a software development process 31 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. I What is Rational Unified Process (RUP)? 32 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 16

17 RUP - Elements of the Process 33 is assigned to a Roles: the who Activities: the how e.g. system analyst, designer, test designer Receive Order creates, modifies, controls Get item from stock Send Invoice [priotized] [else] Express Delivery Delivery via mail Receive Payement Close Order Workflows: the when Core workflow to each discipline Artifact: the what e.g. use-case models, source code, documents (same as deliverable) I Disciplines 34 The "container" for the four elements: roles, activities, artifacts and workflows Business Modeling Core Technical Disciplines Requirements Analysis and Design Implementation Core Supporting Disciplines Test Deployment Change & Config. Mgm. Project Mgm. Environment. I 17

18 RUP- Phases and Milestones 35 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" Phase Inception (10%) Life-cycle objective milestone Milestone Transition I RUP- Phases and Milestones 36 Elaboration Define architecture Specify requirements more precisely Executable architecture prototype Define project plan Life-cycle architecture milestone Inception (10%) Elaboration (30%) Transition I 18

19 RUP- Phases and Milestones 37 Construction Resource management and control Design, Implementation, and Testing Output (software + documentation) ready for users. Initial Operational Capability milestone (beta-release) Inception (10%) Elaboration (30%) Construction (50%) Transition I RUP- Phases and Milestones 38 Transition Transition of the product to users Beta-testing Training of users and maintainers Rollout of the product to operational environment Product release milestone Inception (10%) Elaboration (30%) Construction (50%) Transition Transition (10%) I 19

20 RUP- Phases and Milestones 39 Was not RUP iterative??? Internal milestones and releases Iterations within phases I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 Inception (10%) Elaboration (30%) Construction (50%) Transition Transition (10%) I Disciplines and Phases 40 Inception Elaboration Construction Transition Business Modeling Core Technical Disciplines Requirements Analysis and Design Implementation Test Core Supporting Disciplines Deployment Change & Config. Mgm. Project Mgm. Environment. I 20

21 Agile Approaches - Agile Alliance 41 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 ( 2001) I Extreme Programming - Values and Principles 42 A lightweight methodology for vague or rapidly changing requirements Communication Simplicity Reflection Mutual benefit "How" and "why" "win-win", automated are we testing working Redundancy If it fails. E.g. pair programming. Feedback Changes need feedback Values Principles Practices Courage "If you know what the problem is, do something" Respect Baby steps "What is the least that you can do that can be shown to be in the right direction?" I 21

22 Extreme Programming - Some Practices 43 Pair Programming Focus on task Clarify ideas Rotate frequently Stories "requirements", but not mandatory Name + short story On index cards (paper) Refactoring Behavior preserving transformation Tool support, e.g. Eclipse Continuous Integration Integrate and test often Automated build system Automated regression tests (e.g. JUnit) Test-First Programming Create tests before code Focus on interface and "what is needed" Gets tests for free I Scrum 44 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 22

23 Scrum Overview 45 Product backlog All requirements Prioritized only by product owner Never finalized From anyone (users, customers, sales) Sprint backlog What to do in one sprint Sprint planning meeting Plan what to do in the next sprint (sprint = one iteration) Daily Scrum Short (15 min) done since last meeting, todo, problems Pick from sprint backlog Sprint 30 - days iteration product increment Scrum Master Enforce scrum practices Executable Product Increment I 46 I I 23

24 What is configuration management? 47 Configuration Item Identification Source code modules Test scripts Design documents Build systems SCM I What is configuration management? 48 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 24

25 What is configuration management? 49 Configuration Item Identification Source code modules Test scripts Design documents Build systems SCM Configuration control Only authorized people may make changes Larger changes - change requests CHANGE REQUEST Project: Classification: Priority: Date: Change Control Board (CCB) Make change decisions. Only large changes (e.g. new major requirements) I Change Description: What is configuration management? 50 Configuration Item Identification Source code modules Test scripts Design documents Build systems SCM Configuration control Larger changes - change requests Auditing Ensure that the items are complete and consistent. Make sure that the configuration is tested and meets requirements. Status accounting I Document and report changes to those involved. 25

26 SCM tools 51 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 Commit - add comments What is a bug / what is a feature? Tool examples: Clear Case, Visual Source safe Perforce, CVS Subversion History - Find where the fault was added Blame - Who added a certain code line SCM Tools Diff - What has changed between two versions? I Version handling example 52 Development Branch(s) v v Test Merge Trunk v v v v Release Branch(s) v I 26

27 Sync- and Stabilize (e.g. Microsoft) 53 Commit to SCM repository Implement new stuff Daily build (automatic compile and link) Fail? Success? (Report via e- mail, redlamp etc.) Automatic blame :-) Smoke test (automatic test of system) Stub-out e.g. user interfaces and databases I Summary - What have we learned today? 54 Waterfall model V-Model Iterative models Spiral model RUP Agile XP Scrum I Software Configuration Identification Control Status accounting Auditing I 27

28 Further reading (Books) 55 Rational Unified Process (RUP) Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition, ISBN , Addison-Wesley Professional, USA, 2003 Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP, ISBN: , Addison-Wesley Professional, USA, 2003 Agile, Extreme Programming, Scrum Kent Beck and Cynthia Andres, Extreme Programming Explained: Embrace Change, Second Edition, ISBN , Addison-Wesley Professional, USA, 2004 Ken Schwaber and Mike Beedle, Agile Software Development with Scrum, ISBN , Prentice Hall, NJ, USA, 2002 Mary Poppendieck and Tom Poppendieck, Lean Software Development: An Agile Toolkit, ISBN , Addison-Wesley Professional, USA, 2003 Configuration Alexis Leon, Handbook, Second Edition, ISBN , Artech House Publishers, MA, USA, 2005 I Further reading (Web) 56 Extreme Programming Extreme Programming, a gentle introduction I 28