Software engineering

1. Software engineering • “Why programming is hard to manage?” - Tom Watson, Founder of IBM • This question is addressed by software development methodology, which describes the best practices used in a software development process

2. Software Life Cycle • Life Cycle models the software development process • Activity-centered life cycle • Focus on the activities • Entity-centered life cycle • Focus on the artifacts produced by the activities • We’ll look at Rational Unified Process, currently the most well known life cycle process

3. Before 1994 • Many different methodologies • Many different modeling notations • “A is associated with one B” • Booth (1st ed.) • Booth (2nd ed.) • Coad • Jacobson • Martin/Odell • Shlaer/Mellor • Rumbaugh • UML 1 A B 1 A B 1 A B [1] A B A B A B A B 1 A B

4. The unified process • 1994-95 • Booch, Rambaugh, and Jacobson (the three amigos) joined Rational Software (now part of IBM) and started the unification process • Results • UML (Unified Modeling Language) • An open standard for the modeling notations • RUP (Rational Unified Process) • A proprietary methodology by Rational

5. RUP • Central theme • RUP is a risk-driven process • How to mitigate risks (find out risk earlier) • How to cope with risks • Key concepts • Use-case driven • Iterative and Incremental process • Architecture-centric

6. Key concepts in RUP • Use-case Driven • Use cases are used to generate the requirement, analysis, design, implementation and test model • Iterative and Incremental • Plan a little • Specify, design, and implement a little • Integrate, test, and run each iteration a little • Each iteration follows a pattern similar to waterfall approach • Advantages • Know the critical and significant risks early • Provide feedback to clients

7. Key concepts in RUP • Architecture-centric • Models of complex system can be very large • Select only the 10-20% of the system that is absolute essential in understanding the system • Architecture is what remains when you cannot take away any more things and still understand the system and explain how it works (Philippe Kruchten)

8. Implementation View Logical View Use-Case View Process View Deployment View 4+1 view model of architecture • RUP’s architecture is represented by 5 views • Like different blueprints represent different aspects of building

9. 4+1 view model of architecture • Logical View • Describes the functional requirements of the system • An abstraction of the design model, identifies major design packages, subsystems, and classes • Implementation View • Describes the organization of software modules • Source code, data files, components, executables • Process View • Describes the concurrent aspects of the system • Addresses issues like concurrency, system startup and shutdown, fault tolerance, and object distribution

10. 4+1 view model of architecture • Deployment View • Shows how the executables and components are mapped to the platforms and nodes • Addresses issues such as deployment, installation, and performance • Use-Case View • Contains a few key scenarios and use cases • Initially used to drive the discovery and design of architecture in the inception and elaboration phases • Later used to validate the different views

11. RUP development is divided into four phases • Inception • the good idea: specifying the end-product vision and its business case, defining the scope of the project • Elaboration • planning the necessary activities and required resources; specifying the features and designing the architecture • Construction • building the product and evolving the vision, the architecture, and the plans until the product is ready for transfer to its users` community • Transition • making the transition from the product to its user’s community, which includes manufacturing, delivering, training, supporting, maintaining the project

12. RUP Process structure

13. Each phase is divided into iterations • Each iteration has 9 workflows • Business Modeling • Requirements • Analysis and Design • Implementation • Test • Deployment • Configuration and Change Management • Project Management • Environment

14. Milestones • Each phase ends with a milestone • Milestone documents the success we have with the objective of each phase • If the milestone cannot be met, ABORT the development • Again risk-driven, want to find out the risk early • If the project is not feasible or unworthy, drop it as soon as possible

15. Milestones Inception Construction Transition Elaboration Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release Milestone

16. The objectives of the four phases • Inception Are the business risks mitigated? Financially worthy? • Elaboration Are the technical risks mitigated? Detailed plan for the project? • Construction Are the logistical risks mitigated? Is the system usable? Ready to ship a beta version? • Transition Ready to ship the product?

17. Objectives of the Inception Phase • Understand what to build • Agree on a high-level vision • Mile-wide, inch-deep description • Detail key actors and use cases • Identify key system functionality • Determine at least one possible solution • Understand the costs, schedule, risks of the project • Decide what process to follow and what tools to use

18. Project Review: Lifecycle Objective Milestones • What’s in the milestones • Stakeholders agree on scope definition and cost/schedule estimate • Agree and understand the requirements • Agreement on initial risks and the coping strategy • ABORT the project if the milestone cannot be meet

19. Objectives of the Elaboration Phase • Key objectives • Addresses risks • Builds an early skeleton architecture • Refine the project plans

20. Objectives of the Elaboration Phase • Detailed objectives • Get a more detailed understanding of the requirements • Design, implement, validate, and baseline the architecture; design critical use cases (baseline is an item that has been formally reviewed and agreed by the stakeholders) • Mitigate essential risks, and produce more accurate schedule and cost estimates • Refine the development case and put the development environment in place

21. Project Review: Lifecycle Architecture Milestone • A stable product Vision and requirements • A stable architecture • A proven testing and evaluation approaches • Iteration plans for Construction • Estimates of the Construction plans • An agreement of stakeholders on the Vision • An acceptable resource expenditures and planned expenditures

22. Objectives of the Construction Phase • Most time-consuming phase, about cost-effective development of a complete product • Objectives • Minimize development costs and achieve some degree of parallelism • Configuration management to keep track with the development • Iteratively develop a complete product that is ready to transition to its user community • Describe the remaining use cases, design the database, implement unit-test code, integrate and system testing, early deployment and feedback, prepare for beta and final deployment

23. Configuration Management • For controlling and monitoring change by • Identifying the configuration items • Manage change through a change request • Analyze the request and accept if consistent with the goals of the project • Record information of each version of each configuration item and its dependencies

24. Project Review: Initial Operational Capacity Milestone • Is the produce release stable and mature enough to be deployed? • Are all the stakeholders ready for the transition into the user community? • Are actual resource expenditures versus planned expenditures still acceptable?

25. Objectives of the Deployment Phase • To ensure the software fully addresses the needs of its users • Test the product and make minor adjustments based on user feedback • Traditionally waterfall approach • Big bang • Integrate subsystems together and start testing • Major breakage is common • Iterative approach • Less of a problem because the construction phase already produces a reasonably stable, integrated and tested system

26. Objectives of the Deployment Phase • Objectives • Beta test to validate that user expectations are met • Train users and maintainers to achieve user self-reliability • Prepare deployment site and convert operational databases • Prepare for launch-packaging, production, and marketing rollout; release to distribution and sales forces; field personnel training • Achieve stakeholder concurrence that deployment baselines are complete and consistent with the vision • Improve future project performance though lessons learned

27. Project Review: Product Release Milestone • Are the users satisfied? • Are actual resource expenditures versus planned expenditures acceptable? If not, what actions can be taken in future projects?

28. How to model the process? • Each phase is divided into iterations • e.g. for medium size project, we have • 1 iteration for inception • 1-2 iterations for elaboration • 2-4 iterations for construction • 1-2 iterations for deployment • Within each iteration, the work is divided into 9 tasks called disciplines or workflows in RUP

29. Workflows in an iteration

30. How to model the process? • Each workflow is accomplished collaboratively by a number of Workers (also known as Roles) • Roles carries out Activities and produces Artifacts • Four key modeling elements • Roles: the who • Activities: the how • Artifacts: the what • Workflows: the when • Less important modeling elements • guidelines, templates, tool mentors, concepts

31. The key modeling Elements • Role • Describe the responsibilities of an individual • Activities • The work performs by the role • Artifacts • Entities that the role creates, modifies, or controls • Workflow • A sequence of activities supported by the interaction of roles that produces a result of observable value

32. Summary • A development process is divided into 4 phases • Each phases has 9 workflows • Each workflow is carried out by a number of roles, that performed some activities, and produced some artifacts

33. Roles • RUP defines a total of 30 roles (!) , e.g. • System analyst • Requirements elicitation, use-case modeling • Designer • Defines the responsibilities, operations, attributes, and relationships of classes • Test Designer • Planning, design, implementation, and evaluation of tests • Project manager • Planning and staffing the project, map individual to act as several workers

34. Activities and Artifacts • Activities Role Plan an iteration Project Manager Find use cases and actors System Analyst Review the design Design Reviewer Execute a performance test Performance Tester • Examples of Artifacts • Use-case model, design model • Model element: class, use case, subsystem • Document: software architecture document • Source code • Executables

35. Example of artifacts produces

36. An analyst’s involvement in RUP Analyst

37. Notation used in RUP Activities Requirement workflow Role Use-Case Design Use-Case Model System Analyst responsible for Artifact Use-case realization

38. Workflow • Each workflow is supported by a number of Roles • System analyst • Business modeling workflow • Requirements workflow • Design and analysis workflow • Project manager • All of the workflows • RUP provides guidelines and templates for workflows, roles, activities, and artifacts

39. Example - Project Management Workflow • Purposes of the workflow • To provide a framework for managing software project • To provide guidelines for planning, staffing, executing and monitoring projects • To provide a framework for managing risk • Focuses of the workflow • Planning an iterative project • Risk management • Monitoring the progress of the iterative project

40. Planning an iterative project • The questions • How many iterations do I need? • How long should they be? • How do I determine the contents and objectives of an iteration? • How do I track the progress of an iteration? • The objectives • To allocate tasks and responsibilities to a team of people • To monitor progress and to detect potential problems as the project is rolled out

41. E.g. allocate tasks to a team of people Role Activities Designer Object Design Use-case Author Detail a Use Case Use-Case Designer Use Case Design Architect Architectural Analysis Architectural Design Resource Peter Paul Mary Simon

42. Two Levels of Plans • Phase Plan (coarse-grained plan) • Dates of major milestones after end of inception, elaboration, construction and transition • Staffing profile • Dates of the minor milestones: end of each iteration • Iteration Plan (fine-grained plan) • The current iteration plan • The next iteration plan • Gantt charts (a time-line chart) to define the tasks and their allocation to team members

43. Risk Management • What is risk? • Whatever that stands in our way to success • Currently unknown or uncertain • How to cope with risks • Don’t wait passively until something happen • Decide in advance what to do

44. Strategies • Risk avoidance: e.g. reorganize the project • Risk transfer: pass the risk to someone else • Risk acceptance: live with the risk and decide what to do if the risk materializes, e.g. • mitigate the risk: reduce the probability or impact of the risk • Define a contingency plan

45. Role of Project Manager in the Project Management workflow

46. Workflow in project management Resemble a UML activity diagram

47. RUP has • 9 core workflows • 30 roles • Over 100 artifacts • RUP is a very large process framework • Like having a buffet, you don’t eat all the food • Tailor the process to produce a development case that suit your need with as little ceremony as possible • Rational sells tools that support the RUP process

48. Reference: • www.rational.com • Two popular books on RUP are • “The Rational Unified Procss an Introduction (2nd Ed)” by Kruchten (Addison-Wesley) • Talk about the nine workflows • “The Rational Unified Process Made Easy” by Kroll and Kruchten (Addison Wesley) • Explain how to use the RUP

49. RUP • A systematic approach, emphasizes on architectural design • Extreme Programming (XP) • A lightweight and efficient approach, emphasizes on “continuous integration, relentless testing” • Ref: • “Extreme Programming Explained” by Kent Beck (Addison-Wesley, 2000)

50. XP’s main philosophy • Risk is the basic problem in software development • Schedule slips • Project canceled • System goes sour • Defect rate • Business misunderstood • Business changes • False feature rich • Staff turnover