Software Process Successful Software Production between Extreme Programming and Rational Unified Process Short Version Jörg Hofstetter, HTA Luzern (www.hta.fhz.ch) www.sweed.ch 2002, J. Hofstetter 1
Literature The Rational Unified Process, Philippe Kruchten, Addison Wesley, 2000 The Unified Software Development Process, Ivar Jacobson, Addison Wesley, 1999 Projektmanagement mit dem Rational Unified Process, Gerhard Versteegen, Springer, 2000 Extreme Programming explained, Kent Beck, Addison Wesley, 2000 Feature-Driven Development, Stephen Palmer, Prentice Hall, 2002 Agile Software Development, Alistair Cockburn, addison-wesley, 2002 agile modeling, Scott Ambler, Wiley, 2002 Managing Software Requirements, Dean Leffingwell - Don Widrig, Addison Wesley, 1999 2002, J. Hofstetter 2
Links Firma Rational, RUP: www.rational.com Agile Alliance: http://www.agilealliance.org/home SWEBOK: http://www.swebok.org/ V-Modell: http://www.v-modell.iabg.de/vm97.htm XP: http://www.extremeprogramming.org FDD: http://www.togethercommunity.com/coad-letter/coad- Letter-0070.html FDD: http://www.step-10.com/fdd/index.html FDD: http://www.thecoadletter.com/download/ 2002, J. Hofstetter 3
Overview Module 1: Software Engineering Basics Introduction (p. 6) Process (p. 11) Main Workflows (p. 13) Technical Methods (p. 17) Life-cycle Models (p. 18) Module 2: Concrete Processes Rational Unified Process (p. 24) Extreme Programming (p. 29) Feature Driven Development (p. 47) V-Model (p. 59) Module 3: Agile and Lightweight Processes, Process Improvement, Conclusions (p. 67) 2002, J. Hofstetter 4
Module 1: Software Engineering Basics 2002, J. Hofstetter 5
Introduction Software project failure statistic Type 1: Project successful Type 2: Project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified. Type 3: project canceled Source: The CHAOS Report (1994), Standish Group http://www.standishgroup.com/sa mple_research/chaos_1994_1.php 2002, J. Hofstetter 6
Introduction Risks: The Basic Problems Schedule slips - Project not ready for another 6 months. Project canceled after numerous slips. System goes sour - successfully put into production, but after a couple of years the cost of making changes rises to much. Defect rate to high - System isn t used. Business misunderstood - Software doesn t solve the business problem that was originally posed. Business changes. False features - System has a lot of interesting features, but none of which makes the customer much money. Adapted from: Extreme Programming explained, by kent Beck 2002, J. Hofstetter 7
Introduction What makes a project successful? Importance User Involvement Executive Support Clear Business Objectives Experienced Project Manager Small Milestones Firm Basic Requirements Competent staff Proper Planning Source: The CHAOS Report, Standish Group 2002, J. Hofstetter 8
Introduction The 4 Project Variables Target: 100% Actual: 100% Capability, Scope Target : 4 defects/kloc Actual: 1 defect/kloc Costs this project Quality Target : $70K Actual: $90K Duration, Time Target : 30 wks Actual: 20 wks Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude. 2002, J. Hofstetter 9
Introduction SW-Quality Function Efficiency Reliability User View Usability Quality Security Expandability Maintainability Portability Reusability Developer View 2002, J. Hofstetter 10
Process What is a Software Process? The way we produce software... Technical Methods, Models, Notations (UML) Management: Planning, Control Process-rules, Order of development activities, Life-cycle models 2002, J. Hofstetter 11
Process Software Process Activities Workers, Roles Who is doing What, How and When? Artifacts (Doumnets, SW-product, Models) Workflow, Phase 2002, J. Hofstetter 12
Main Workflows Main Workflows Software Production Requirements: Requirements-Elicitation + -Analysis Design: Architecture+Detail-Design Implementation Test Deployment Project Management Quality Management Configuration Management See also: SWEBOK Software Engineering Body of Knowledge http://www.swebok.org/ 2002, J. Hofstetter 13
Main Workflows Requirements Problem Space Needs Solution Space Features Software-Specifications System-Requirements, Customer-Requirements, (DIN: Lastenheft) Developer-Requirements, (DIN: Pflichtenheft) 2002, J. Hofstetter 14
Main Workflows Types of Requirements Functional requirements the application's functionality Non-functional requirements Performance speed capacity (traffic rates) memory usage Reliability and availability Error handling Inverse requirements: what the application does not do 2002, J. Hofstetter 15
Main Workflows Design Req. System-Design Architecture, System Design, Highlevel Design Detail-Design Object Design 2002, J. Hofstetter 16
Technical methods IEEE-Documents (IEEE Nr.) Quality assurance (730) Configuration (828) Project status (1058) Requirements (830) Design (1016) Code Testing (829) Operation Customeroriented Developeroriented Architecture Detailed Design SQAP software quality assurance plan SCMP software configuration management plan SPMP software project management plan SRS software requirements specifications SDD software design document Source Code STD software test documention User s manual 2002, J. Hofstetter 17
Life-cycle Models Waterfall Model Requirem. Specification (Use Case + Text) Design... UML Diagram + Text... Code + Comment Implementation... Whole Code Integration... Test Report, Error-List Test Milestone 2002, J. Hofstetter 18
Life-cycle Models Spiral Model Step n+1: Design Specification Step n: Requirements Models System Test-Results Step n+2: Implementation Code Step n+3: Testing 2002, J. Hofstetter 19
Life-cycle Models Iterative Development -> cyclic iterations of workflows. R R R D I T D D I T D D I T D Iteration 1 Iteration 2 Iteration 3 Zeit Milestone 2002, J. Hofstetter 20
Life-cycle Models Incremental Development -> iterative & incremental! Functionality of runtime system Build Iteration 1 Iteration 2 Iteration 3 Time Milestone 2002, J. Hofstetter 21
Life-cycle Models Some dangerous Iteration-Patterns Teams not synchronized -> Chaos! First Iteration to long -> Panic! Overlapping iterations 2002, J. Hofstetter 22
Module 2: Concrete Processes - Rational Unified Process (RUP) - V-Model - Extreme Programming (XP) - Feature Driven Design (FDD) 2002, J. Hofstetter 23
RUP Rational Unified Process (RUP) Iterative, incremental Process A Product:Implementing the Rational Unified Process Developed by the company that defined UML Architecture centric Interactive knowledge base accessible from tools Guidelines, templates, tool mentors at your finger tips Manage Requirements Develop Iteratively Model Visually Verify Quality Use Component Architectures Control Changes 2002, J. Hofstetter 24
RUP RUP: Phases Inception Elaboration Construction Transition Lifecycle objectives milestone Lifecycle architecture milestone Initial operational capability milestone time Product release milestone The Rational Unified Process has four phases: Inception - Define the scope of project Elaboration - Plan project, specify features, baseline architecture Construction - Build the product Transition - Transition the product into end user community 2002, J. Hofstetter 25
RUP RUP: Iterations and Phases Releases Inception Elaboration Construction Transition Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external). Adapted from: RUP 2002, J. Hofstetter 26
RUP Bringing It All Together... Process Workflows Supporting Workflows Adapted from: RUP Business Modeling Requirements Analysis & Design Implementation Test Deployment Configuration Mgmt Management Environment Inception Preliminary Iteration(s) Phases Elaboration Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iterations Iter. #n+2 Iter. #m In an iteration, you walk through all workflows Construction Transition Iter. #m+1 2002, J. Hofstetter 27
RUP RUP Overview Widely used in (western) industry Much of literature Document centric, heavy-weight process Product available Not based on metrics Tailoring possible / needed 2002, J. Hofstetter 28
XP Extreme Programming (XP) 2002, J. Hofstetter 29
XP What is XP? Early, continuing feedback from short cycles Incremental planning approach Flexible schedule for changing business needs. Automated tests written by programmers Reliance on oral communication, tests and source code. Evolutionary design (keep it simple, refactoring) 2002, J. Hofstetter 30
XP XP Practices The Planning Game... Small Releases... Metaphor... Simple Design... Testing... Refactoring... Pair Programming... Collective Ownership of Code... Continuous Integration... On-site Customer... 40-hour Week Coding Standards 2002, J. Hofstetter 31
XP User Stories Get the customers to tell stories about how the system will work. Write them on cards Organize topics Classify High, Medium, Low priority Associated Functional Test 2002, J. Hofstetter 32
XP User Stories: FAQ s How many stories do I need? For a typical project of 6-12 months, 50-100 stories would be a good number. How big should a story be? A story should take 1-3 weeks to implement (in engineering time). 2002, J. Hofstetter 33
XP User Stories: Tips User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. Possible in your project? 2002, J. Hofstetter 34
XP Metaphor The Internet is like air-traffic control, with allpowerful master controllers observing everything, telling each packet where to go. The Internet is like spiders crawling on a web - when one way is blocked, they just go another way, always trying to get to their goal. Architecture! 2002, J. Hofstetter 35
XP Simple Design The right design for the software is one that Runs all the tests Has no duplicated logic. States every intention important to the programmers. Has the fewest possible classes and methods Not Most hooks Most abstract Designed for the ages 2002, J. Hofstetter 36
XP Refactoring Before adding - is there a way to change the program to make the addition simple? After adding - is there a way to make the program simpler while still running all the tests? Don t refactor on spec; refactor when the system and process ask you to. 2002, J. Hofstetter 37
XP Testing Any program feature without an automatic test simply does not exist. Unit tests make confidence in the operation of the program part of the program. Owned by developers For all classes Functional tests do the same for customers. Owned by customer Test every story 2002, J. Hofstetter 38
XP Pair Programming All production code is written with two people looking at one machine, with one keyboard and one mouse. One partner (with keyboard and mouse) is thinking about the best to implement this method. Other partner is thinking more strategically: Will this working? What other tests might not work? How can we make this simpler? 2002, J. Hofstetter 39
XP Collective Code Ownership Don t coordinate, just do it; integrate frequently. (Continuous Integration) Anybody who sees an opportunity to add value to any portion of the code is required to do so at any time. Subject to the current requirements, Subject to simple design. Everyone is responsible for the whole of the system. Possible in small project-groups...! 2002, J. Hofstetter 40
XP On-Site Customer A real customer must sit with the team, available to answer questions, resolve disputes, and set small-scale priorities. Can t afford a customer? If the system isn t worth the time of one customer, maybe it s not worth building. What if you make a mass product (e.g. vehicle brake system)? 2002, J. Hofstetter 41
XP Development Simplified Developers Break story into small tasks Select the task they wish to work on to implement a task Write tests for the task Write the code for the task Refactor to clean up design Integrate task into code base 2002, J. Hofstetter 42
XP Planning Game Customer writes user stories for the product. A User story is a short description of the behavior of the product. Customer ranks stories by importance Developers estimate development time per story Using customer ranks & developers estimates, the stories for next iteration are selected 2002, J. Hofstetter 43
XP Release Plan The release plan specifies exactly which user stories are going to be implemented for each system release. The team, in concert, estimates all stories, in terms of Engineering Weeks Estimate resources, estimate velocity Arrange into two- or three-week iterations 2002, J. Hofstetter 44
XP XP Project 2002, J. Hofstetter 45
XP XP Overview Low process overhead. Ideal for changing business needs. Some concepts (e.g. pair programming) can t be applied in every project. Not well suited for big projects. XP-discussion brings new pragmatism in the process discussion. 2002, J. Hofstetter 46
FDD Feature-Driven Development (FDD) 2002, J. Hofstetter 47
FDD FDD Is highly iterative Delivers frequent working results Provides accurate and meaningful progress and status information with the minimum of overhead and disruption for the developers. Is liked by clients, managers and developers 2002, J. Hofstetter 48
FDD FDD and Its Five Parts 1 Develop overall Model 2 Build a Feature List 3 Plan by Feature 4 Design by Feature 5 Build by Feature 2002, J. Hofstetter 49
FDD 1. Develop an Overall Model Form the modeling team Conduct a domain walkthrough, study documents Develop model(s) Refine the overall object model Write model notes Domain Object Modeling(=Analysis Model): Identification of the major classes, important responsibilities and relations between them High-Level Sequence diagrams Notes 2002, J. Hofstetter 50
FDD 2. Build a Features List Form the features-list team Identify features Form features sets Prioritize feature sets and features Divide complex features Inspect; log action items 1 Develop overall Model 2 Build a Feature List 3 Plan by Feature 4 Design by Feature 5 Build by Feature 2002, J. Hofstetter 51
FDD Features: Features are functional Features are small (they can be designed and build in 2 weeks or less) Features are client valued Features use a template <action> <result> <object> 2002, J. Hofstetter 52
FDD 3. Plan by Feature Form the planning team Sequence feature sets and features Assign feature sets and features to chief programmers Assign classes to class owners Inspect; log action items 1 Develop overall Model 2 Build a Feature List 3 Plan by Feature 4 Design by Feature 5 Build by Feature 2002, J. Hofstetter 53
FDD 4. Design by Feature (DBF) Form a Feature Team -> chief programmer: identifies the involved classes and responsible developers for this set of features. Start a new work package for this set of features Feature teams are formed from class owners as needed. Conduct a domain walkthrough,study referenced docs 2002, J. Hofstetter 54
FDD Design by Feature (DBF), cont. Develop sequence diagrams: for each feature being designed Write up: design decisions, requirements clarification, design alternatives. Refine object model, write class and method prologue Design Inspection 1 Develop overall Model 2 Build a Feature List 3 Plan by Feature 4 Design by Feature 5 Build by Feature 2002, J. Hofstetter 55
FDD 5. Build by Feature (BBF) Implement classes Implement unit tests Implement methods Inspect Code; log action items Unit test Check in and promote to build (integration) 1 Develop overall Model 2 Build a Feature List 3 Plan by Feature 4 Design by Feature 5 Build by Feature 2002, J. Hofstetter 56
FDD Percentages components Develop an overall Model Build a Feature List Plan by Feature Design by Feature Build by Feature 10 % initial 4 % on-going 4 % initial 1 % on-going 2 % initial 2 % on-going 77 % Cycletimes every two weeks 2002, J. Hofstetter 57
FDD FDD Overview Low process overhead Ideal for changing business needs Pragmatic process Simple concept for documentation Not very well known 2002, J. Hofstetter 58
V-Model V-Model Development Standard for IT-Systems of the Federal Republic of Germany Document-centric process Tailoring possible Waterfall and iterative 2002, J. Hofstetter 59
V-Model The three levels of standardization Configuration Management Qua lity Assura nc e Syste m De v e lo p m e n t Project Management Procedure Methods Tool Requirements Procedure: What has be done Methods: How is something done Tools: What is to be used for something 2002, J. Hofstetter 60
V-Model System Development Submodel System Development SD 1 System Requirements Analysis SD 2 System Design SD 3 SW/HW Requirements Analysis Products on System Level: User Requirements System Architecture Technical Requirements Interface Description SD 4-SW to SD 7-SW Software Development SD 4-HW to SD 7-HW Hardware Development SD 8 System Integration Upgrade Techn. Req. with regard to SW-Units SD 9 Transition to Utilization System Development Submodel 2002, J. Hofstetter 61
V-Model SD4-SD7 SD 4-SW Preliminary SW Design SD 4.1-SW SW Architecture Design ->Interface Overview SD 4.2-SW Design of Internal and External SW Interfaces -> Interface Description SD 4.3-SW Specification of SW Integration ->Integration Plan SD 5-SW Detailed SW Design SD 5.1-SW Description of SW Component/Module/Database SD 5.2-SW Analysis of Resources and Time Requirements -> SW Design SD 6-SW SW Implementation SD 7-SW SW Integration 2002, J. Hofstetter 62
V-Model Example: SD 4.1 SW Architecture Design Product Flow from to Activity State Product Activity State SD 1 accepted User Requirements SD 2 accepted System Architecture SD 3 accepted Technical Requirements SD 2 b. proc. Interface Overview SD 4.2-SW, SD 5- SW, CM 4.3 submitted SD 3 b. proc. Operational Information SD 4.3-SW b. proc. SW Architecture SD 4.2-SW, SD 4.3- SW, SD 5-SW submitted 2002, J. Hofstetter 63
V-Model V-Model System Requirements Analysis Transition System Design System Integration SW/HW Req. Analysis SW Integration Preliminary SW Design Detailed SW Design SW Implementation 2002, J. Hofstetter 64
V-Model V-Model Overview Generic model, tailoring possible/needed Very formalistic process Heavyweight process Good documentation available ls loosing importance against RUP, XP 2002, J. Hofstetter 65
Module 3: - Agile and Lightweight Processes, - Process Improvement, - Conclusions 2002, J. Hofstetter 66
Agile Lightweight Processes Not document centric. Documents have value only, as they help the team to be successful. Small resources needed. Work is source (1) centric. Individuals are important. Short iteration phases. 2002, J. Hofstetter 67
Agile Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it.through this work 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 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas http://agilemanifesto.org/ 2002, J. Hofstetter 68
Agile Agile Software Development Principles Early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Business people and developers must work together. Build projects around motivated individuals (Support, Trust) Most efficient team-information: face-to-face conversation. Working software is the primary measure of progress. Continuous attention to technical excellence and good design. Simplicity--the art of maximizing the amount of work not done The best architectures, requirements, and designs emerge from self-organizing teams. 2002, J. Hofstetter 69
Conclusions No silver bullet! There is no process for every project, that solves all your problems without customization and own thinking! Never do anything that's a waste of time! You may get dirty hands - Enjoy it! Warning! A fool with a tool is just a fool! If somebody has learned to use a hammer, everything becomes a nail (Booch) 2002, J. Hofstetter 70
Conclusions Process Tailoring There is not a single process guide for every possible project! But there are some generic process models. We have to tailor these process models to our special needs. We eliminate the not needed parts and keep the needed parts. 2002, J. Hofstetter 71