SE 470 Software Development Processes

1. SE 470Software Development Processes James Nowotarski 14 April 2003

2. Course Map Overview . Introduction . History Content . Rational Unified Process . Extreme Programming Implementation . Tools, Training, Roles . CMM, Metrics . Selection & Evaluation Briefings (Term Papers) 1 2 3 4 5 6 7 8 9 10 11 Week Memorial Day Assignments Quizzes

3. Today’s Objectives • Understand the basics of the Rational Unified Process (RUP) • Structure • Content • Best practices • In particular, understand how RUP enables iterative development

4. Today’s agenda Topic Duration • Quiz #1 40 minutes • RUP Overview 30 minutes • *** Break 10 minutes • RUP Overview (cont.) 45 minutes • RUP and Iterative Development 60 minutes

5. Today’s agenda Topic Duration • Quiz #1 40 minutes • RUP Overview 30 minutes • *** Break 10 minutes • RUP Overview (cont.) 45 minutes • RUP and Iterative Development 60 minutes

6. Today’s agenda Topic Duration • Quiz #1 40 minutes • RUP Overview 35 minutes • *** Break 10 minutes • RUP Overview (cont.) 30 minutes • RUP and Iterative Development 75 minutes

7. Think to yourself how many of the projects you have worked were: On Time?On Budget?High Quality? The Bottom Line: Our Customers are upset with us.

8. The Result is Often Referred to as the Software Crisis • Schedule Overruns • Cost Estimate Overruns • Software Quality Problems • Software does not meet User Expectations • Productivity of Software Developers has not been keeping up with demand

9. Why is This? • Software is dynamic versus static • Software is complex • Software is difficult to conceptualize • Software is difficult to represent • Software is difficult to communicate • Software is difficult to evaluate and measure • Software developers have trouble learning what users want: • Users do not know what they want • Software developers misunderstand the problem • There is a tremendous demand for software

10. Some Symptoms: Requirements in flux Users needs not met Poor quality Schedule slips Projects cancelled Cost over runs Difficulty in maintaining software Software that work in pilot does not work in production Business changes faster than systems can keep up Staff turnover Symptoms and Root Causes • Some Root Causes: • Insufficient and misunderstood requirement • Ambiguous communication • Lack of good software architectures • Undetected inconsistencies • Poor testing • Overwhelming complexity • Uncontrolled changes • Manual practices • Exponentially increasing cost of change

11. Best Practices “An organized and documented set of principles, methods and processes that increase quality and productivity of software development.” Source: Rational - “Principles of Managing Iterative Development v2.0”

12. Rational’s View of Best Practices

13. The Rational Unified Process • Developed through the combined efforts of: • Grady Booch • Ivar Jacobson • James Rumbaugh • Features • Based on the Unified Modeling Language • Iterative • Architecture-centric • Use-case driven • Risk driven

14. Rational Unified Process

15. The History of the Rational Unified Process Rational Unified Process 2000 2000 1999 1998 1997 1996 1995 Rational Unified Process 5.5 Rational Unified Process 5.0 UML v1.3 UML v1.1 Rational Objectory Process 4.1 UML v1.0 Rational Objectory Process 4.1 Rational Approach Objectory Process 3.8

16. RUP Model Notation A unit of work that a worker may perform. A role played by an individual or a team. A piece of information that is produced, modified or used by a process.

17. Workers • A Worker is a role played by an individual or a team. • Example: • Stakeholder • Systems Analyst • Designer • Test Designer • Project Manager

18. Artifacts • A piece of information that is produced, modified or used by a process. • Artifacts are the intangible products of the project • Examples: • A use-case model • A document such as a business case • Source Code • Executable code

19. Artifacts - Examples

20. Activities • An Activity is a unit of work that a worker may perform. • Examples: • Plan an interaction performed by Project Manager • Find use cases and actors • Review the design • Execute a performance test

21. Additional Process Elements • Guidelines - are rules, recommendations, or heuristics that support activities and steps. • Templates - are models or prototypes of artifacts • Ex. Word template for Vision Document • Tool mentors - are a means of providing guidance by showing you how to use a specific software tool (Similar to wizards) • Concepts - Separate material that describe some of the reasons and background on a specific topic

22. Software Product Requirements Rational’s Nomenclature of the Software Engineering Process Workers Performance Measures (Activities) Software is developed in Teams: Workers Artifacts Artifacts Software Engineering Process (Workflows) • User Team • (Suppliers) • Expectations • Features • Cost • Benefit • Delivery Dates • Quality • Users Team • (Customer) • Perceptions • Features • Cost • Benefit • Delivery Dates • Quality Activities Workers Artifacts Software Development Team Processes, Techniques & Tools

23. Rational’s View of Best Practices • Use Iterative Development • Manage Requirements • Use Component Architectures • Model Visually • Continuously Verify Quality • Control Change

24. Advantages Resolves risks before making large investments Enables early user feedback Makes testing and integration continuous Focuses project on short-term objectives Makes partial deployments possible Disadvantages Waterfall life cycle is more familiar since it is similar to hardware life cycle Iterative Life Cycles difficult to estimate and manage. Only recently used on real projects - therefore little track record Iterative Advantages/Disadvantages Iterative life cycle best used for problems that are not well understood.

25. Rational’s View of Best Practices • Use Iterative Development • Manage Requirements • Use Component Architectures • Model Visually • Continuously Verify Quality • Control Change

26. Manage Requirements A systematic approach to • eliciting • organizing • documenting • and managing the changing requirements of the software application

27. What’s the Difference? • Requirements Analysis • Requirements Definition • Requirements Specification • Requirements Management

28. Managing Changing Requirements • Establish a Baseline • Evaluate changes and determine their impact • Track and document tradeoffs and decisions

29. Rational’s View of Best Practices • Use Iterative Development • Manage Requirements • Use Component Architectures • Model Visually • Continuously Verify Quality • Control Change

30. Software Components Definition: A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.

31. Airplane Private Data Object Operations Engines Private Data Object Operations Fuselage Private Data Object Operations Tail Private Data Object Operations Wings Private Data Object Operations Components COMPONENTS - Are objects that are combined into new objects without the use of inheritance

32. Benefits of Component Architectures • Resilient • Meets current and future requirements • Improves extensibility • Enables reuse • Encapsulates system dependencies • Reuse proven solution elements • Reuse or customize components • Select from Commercially-available components • Evolve existing software incrementally

33. Benefits of Architecture • Intellectual control • Manage complexity • Maintain integrity • Basis for reuse • Component reuse • Architecture reuse (patterns) • Basis for project management • Focus on early iterations • Planning • Staffing

34. Rational’s View of Best Practices • Use Iterative Development • Manage Requirements • Use Component Architectures • Model Visually • Continuously Verify Quality • Control Change

35. Model Visually - Use the UML • Capture the structure and behavior of architectures and components • Show how the elements of the system fit together • Maintain consistency between a design and its implementation • Promote unambiguous communication

36. The Unified Modeling Language • Developed through the combined efforts of: • Grady Booch • Ivar Jacobson • James Rumbaugh • Is a language for: • Visualizing • Specifying • Constructing • Documenting the artifacts of a software-intensive system.

37. History of the UML

38. UML Components • Multiple Views • Precise Syntax and semantics • Include • Use-Case Diagrams • Class Diagrams • Object Diagrams • Component Diagrams • Deployment Diagrams • Activity Diagrams • State Chart Diagrams • Collaboration Diagrams • Sequence Diagrams

39. Rational’s View of Best Practices • Use Iterative Development • Manage Requirements • Use Component Architectures • Model Visually • Continuously Verify Quality • Control Change

40. Continuously Verify Quality • In the Rational Unified Process, quality is defined as: "The characteristic identified by the following: • satisfies or exceeds an agreed upon set of requirements, and • assessed using agreed upon measures and criteria, and • produced using an agreed upon process." • Therefore, achieving quality is not simply "meeting requirements" or producing a product that meets user needs, or expectations, etc. • Quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the implementation of a process to ensure that the product created by the process, has achieved the desired degree of quality (and can be repeated and managed).

41. Test Each Iteration • Start testing early • Continuously test • Test each iteration for functionality and performance • Iterative development makes regression testing necessary • Use automated tests whenever possible

42. Rational’s View of Best Practices • Use Iterative Development • Manage Requirements • Use Component Architectures • Model Visually • Continuously Verify Quality • Control Change

43. Control Changes • You must control, track and monitor changes to enable iterative development • Control changes for all software artifacts: • Models • Documents • Source code • Project plans • Establish secure workspaces fore each developer • Automated integration and build management

44. Controlling Parallel Development • Multiple developers • Multiple teams • Multiple sites • Multiple iterations • Multiple releases • Multiple projects • Multiple platforms

45. Configuration Management Configuration Management is the process which controls the changes made to a software system and manages the different versions and releases of the evolving software products • Librarian like function • Manages the version number for each software product • Changes made are controlled by a Change Control Process • Can be managed manually or through the use of a configuration management tool (Difficult to do manually, but it can be done.) • Check In • Check Out • Read only for others

46. Changes Needed In Document Create Changes to Incorporate Create Initial Sections Create/Modify Draft Review Draft (V&V) Document Approved Approved Create Review Revise Review Review ... Time Change Control Process Document Under Development and User Change Control Document in Production and Under Formal Change Control

47. Today’s agenda Topic Duration • Quiz #1 40 minutes • RUP Overview 30 minutes • *** Break 10 minutes • RUP Overview (cont.) 45 minutes • RUP and Iterative Development 60 minutes

48. Version 1 A D I Version 2 A D I Version 3 A D I Core Concepts Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases

49. Development Cycle Phase Iteration Activity Anatomy of Terminology Product

50. Core Concepts Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases Product delivered to users Initial Version 1 Development Cycle Evolution Version 2 Development Cycle Evolution Version 3 Development Cycle