1. SE 470 Software 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) 1234678910115 Assignments Quizzes Week Memorial Day

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

4. Topic Duration Quiz #140 minutes RUP Overview30 minutes *** Break10 minutes RUP Overview (cont.)45 minutes RUP and Iterative Development60 minutes Today’s agenda

5. Topic Duration Quiz #140 minutes RUP Overview30 minutes *** Break10 minutes RUP Overview (cont.)45 minutes RUP and Iterative Development60 minutes Today’s agenda

6. Topic Duration Quiz #140 minutes RUP Overview35 minutes *** Break10 minutes RUP Overview (cont.)30 minutes RUP and Iterative Development75 minutes Today’s agenda

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. Symptoms and Root Causes 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 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. Rational Objectory Process 4.1 Rational Approach Rational Unified Process 5.5 Rational Unified Process 5.0 Rational Objectory Process 4.1 Rational Unified Process 2000 Objectory Process 3.8 The History of the Rational Unified Process 2000 1999 1998 1997 1996 1995 UML v1.0 UML v1.1 UML v1.3

16. RUP Model Notation A role played by an individual or a team. A unit of work that a worker may perform. 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.  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 Artifacts

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 Rational’s Nomenclature of the Software Engineering Process Requirements User Team (Suppliers) Expectations Features Cost Benefit Delivery Dates Quality Users Team (Customer) Perceptions Features Cost Benefit Delivery Dates Quality Software Engineering Process (Workflows) Software Development Team Processes, Techniques & Tools Performance Measures (Activities) Software is developed in Teams: Workers Artifacts Activities

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

24. Iterative Advantages/Disadvantages 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 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. 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. Components Airplane Private Data Object Operations Airplane Private Data Object Operations Engines Private Data Object Operations Engines Private Data Object Operations Wings Private Data Object Operations Wings Private Data Object Operations Fuselage Private Data Object Operations Fuselage Private Data Object Operations Tail Private Data Object Operations Tail Private Data Object Operations 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. Change Control Process Create Initial Sections Create/Modify Draft Review Draft (V&V) Create Changes to Incorporate Changes Needed In Document Document Approved CreateReviewReviseReview Approved Time... Document in Production and Under Formal Change Control Document Under Development and User Change Control

47. Topic Duration Quiz #140 minutes RUP Overview30 minutes *** Break10 minutes RUP Overview (cont.)45 minutes RUP and Iterative Development60 minutes Today’s agenda

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

49. Anatomy of Terminology Product Development Cycle PhaseIterationActivity

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

51. Core Concepts InceptionElaborationConstructionTransition

52. Core Concepts Iteration n Iteration n+1

53. Core Concepts Development Cycle Phase Iteration n+1 Iteration n R D C T R D C T

54. Core Concepts Each iteration is a mini-waterfall R D C T R D C T R D C T

55. Importance of activities across one development cycle One development cycle

56. Core Concepts Milestones Exit criteria Decide to proceed, abort, or change course Measure progress, e.g., –use cases completed –features completed –performance requirements satisfied –risks eliminated –test cases passed

57. For each phase, one group fills out: Key Question:Deliverables/Outcomes ActivitiesExit Criteria

58. Guidelines Key Question:Deliverables/Outcomes ActivitiesExit Criteria Look at the objectives and distill into one key question that needs to be answered by this phase What are the major artifacts produced? Outcomes achieved? What are the essential activities? Predefined standards that must be met before exiting one development phase and entering another. A team handing work off to another part of the project must fully satisfy their exit criteria, while the receiving team verifies that the work meets their standard entry criteria.

59. Kruchten, Chapters 3, 7, 17 Quiz (end of class): –Kruchten –RUP Topics for April 21

60. Extra Slides

61. Summary Timeline 19601970 1980 19902000 Tech era Mainframe Decentralized Distributed Internet Life cycle model Stage wise Waterfall Iterative/Incremental Meth approach Structured Analysis/Design Information Engineering Object-Oriented A/D Agile Content Updates Data mgmt UI design Bus process reengineering Data/process distribution CASE tools JAD Prototyping Multimedia content mgmt Network design/mgmt Quality Security OLTP

62. Protracted integration and late breakage Conventional application of the waterfall model typically results in late integration and performance showstoppers Development progress (% coded) 100% Late design breakage Original target date Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998). Integration begins