• “why Programming Is Hard To Manage?”: - Tom Watson, Founder Of Ibm

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

Department of Information Engineering

1

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

Department of Information Engineering

2

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

1 B 1 B 1 [1]

B B B B B

1 B 3

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

Department of Information Engineering

4

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

Department of Information Engineering

5

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 Department of Information Engineering

6

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)

Department of Information Engineering

7

4+1 view model of architecture • RUP’s architecture is represented by 5 views – Like different blueprints represent different aspects of building

Logical View

Implementation View Use-Case View

Process View

Department of Information Engineering

Deployment View

8

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 Department of Information Engineering

9

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 Department of Information Engineering

10

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 Department of Information Engineering

11

RUP Process structure

Department of Information Engineering

12

• 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 Department of Information Engineering

13

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

Department of Information Engineering

14

Milestones

Inception

Elaboration

Lifecycle Objective Milestone

Construction

Lifecycle Architecture Milestone

Department of Information Engineering

Transition

Initial Operational Capability Milestone

Product Release Milestone

15

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?

Department of Information Engineering

16

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 Department of Information Engineering

17

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

Department of Information Engineering

18

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

Department of Information Engineering

19

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

Department of Information Engineering

20

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

Department of Information Engineering

21

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 Department of Information Engineering

22

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

Department of Information Engineering

23

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?

Department of Information Engineering

24

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 Department of Information Engineering

25

Objectives of the Deployment Phase • Objectives – Beta test to validate that user expectations are met – Train users and maintainers to achieve user selfreliability – 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 Department of Information Engineering

26

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?

Department of Information Engineering

27

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

Department of Information Engineering

28

Workflows in an iteration

Department of Information Engineering

29

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 Department of Information Engineering

30

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 Department of Information Engineering

31

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

Department of Information Engineering

32

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 Department of Information Engineering

33

Activities and Artifacts • Activities Plan an iteration Find use cases and actors Review the design Execute a performance test

Role Project Manager System Analyst Design Reviewer Performance Tester

• Examples of Artifacts – Use-case model, design model – Model element: class, use case, subsystem – Document: software architecture document – Source code – Executables Department of Information Engineering

34

Example of artifacts produces

Department of Information Engineering

35

An analyst’s involvement in RUP

Analyst

Department of Information Engineering

36

Notation used in RUP Requirement workflow

Activities

Role

System Analyst

Artifact

Use-Case Model

Use-Case Design

responsible for

Use-case realization

Department of Information Engineering

37

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 Department of Information Engineering

38

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 Department of Information Engineering

39

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 Department of Information Engineering

40

• E.g. allocate tasks to a team of people Resource

Role

Activities

Peter

Designer

Object Design

Paul

Use-case Author

Detail a Use Case

Mary

Use-Case Designer

Use Case Design

Simon

Architect

Architectural Analysis Architectural Design

Department of Information Engineering

41

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 Department of Information Engineering

42

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

Department of Information Engineering

43

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

Department of Information Engineering

44

Role of Project Manager in the Project Management workflow

Department of Information Engineering

45

Workflow in project management

Resemble a UML activity diagram Department of Information Engineering

46

• 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 Department of Information Engineering

47

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

Department of Information Engineering

48

• 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)

Department of Information Engineering

49

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

Department of Information Engineering

50

XP’s main philosophy • Change is the only constant – The requirement changes – The design changes – The business changes – The technology changes – The team changes – The team members change – Everything in software changes

Department of Information Engineering

51

• Risk is not our problem – Accept project risk as the problem to be solved – Develop a style of software development that address these risks • Change is not our problem – Our problem is our inability to cope with change when it comes • XP consists a set of practices and principles which, when taken together, form a lightweight and effective development process that embraces risks Department of Information Engineering

52

XP versus RUP • Uses short iterations – Very short iterations (a day to a few weeks) – Because requirements change, scheduling must be flexible • Continuous integration testing – Once code is ready, do integration test – Very fast development

Department of Information Engineering

53

XP versus RUP • Less emphasis on analysis and design – Requirements change, so spending too much time on analysis and design is costly • Rely on refactoring – Instead of spending much time on initial architecture, rely more on continuous redesign of the code • Emphasize on fast coding – Code, test, system integration in a few hours – Fast coding lead to messy code • Rely on simple design, refactoring and automatic testing Department of Information Engineering

54

XP versus RUP • Less emphasis on documentation – Less ceremony • Reliance on oral communications, tests and source code to communicate system structure and intent – Standup meeting – Pair programming – Workspace has no partition

Department of Information Engineering

55

Cost of Change • Traditional belief – The cost of change rising exponentially over time – Because change is costly, must spend more effect in planning to avoid change Cost of change

Requirements

Analysis Design Implementation

Department of Information Engineering

Testing

Production 56

Cost of Change • XP’s belief – The cost of change may not rise dramatically over time

Cost of change

time

Department of Information Engineering

57

How this is possible? • XP’s belief the code is easy to modify because – Simple design – Redesign continuously – refactoring – Automated tests (make the change, run existing tests, OK, then confident about the change) – Lots of practice in modifying the design • XP embraces change

Department of Information Engineering

58

Example of a XP Development Cycle • You start with a deck of task cards – E.g. the task says “Get the current time” • You remember at this morning’s “stand-up meeting”, I know something about this functionality • You and I form pair programming partners • Write test case for the new function before coding • The existing design a bit clumsy, we do the refactoring (redesign the existing code) Department of Information Engineering

59

Example of a XP Development Cycle • After refactoring, we run the existing tests. They all run. We feel more confident about the change • Write the code, the test case run • While we write the test case, we find new ideas. We write them on the to-do card • Go to the next test case, refactor the code if necessary

Department of Information Engineering

60

Example of a XP Development Cycle • The to-do list is empty • Grab the idling integration machine. Load the latest release. Load our changes • Run all the test cases • One fails. Fix the problem. • All test cases run. Release our code

Department of Information Engineering

61

Notes • Stories – Requirements are gathered in the form of stories (very simple use cases) – Each story is the result of a conversation between the customer and the developers – After sufficient conversation the customer writes the story on an index card – Just enough to remind all the participants about the conversation – A sentence or a paragraph will usually do – Developers may break down a story into tasks Department of Information Engineering

62

Notes • Estimation – The developers mark on the cards the relative cost of each story – Typical unit of estimation is "ideal programming week“ – At the beginning of each iteration, the customer has X story points to ask the developers to implement. – The customer picks stories that add up to X and hands them to the developers

Department of Information Engineering

63

Notes • Re-estimation – The first iteration will probably not complete all X because of poor estimation – However after several iterations, the estimation of the story points improve

Department of Information Engineering

64

Values and Practices • XP preaches 4 values, 4 activities, and 12 practices • Four values – Communication – Simplicity – Feedback – Courage

Department of Information Engineering

65

Four Values • Communication – In XP, the primary means of communication is oral – Written documentation is secondary and is created only if absolutely necessary. – XP aims to keep the right communications by employing many practices that can’t be done without communicating • e.g. emphasize on unit testing, pair programming, and task estimation • Emphasize face-to-face communication rather than documentation • Stand-up meeting, workspace has no partition, pair-programming Department of Information Engineering

66

Four Values • Simplicity – Constantly ask “What is the simplest thing that could possibly work?” – Better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used – XP takes a short-term view towards design compared with RUP

Department of Information Engineering

67

Four Values • Feedback – “Don’t ask me, ask the system” – “Have you written a test case for that yet?” – Feedback works at the scale of minutes and days • Programmers write unit tests • Customers write new “stories” (simple usecases), the programmers immediately estimate them, so customers have concrete feedback about the quality and cost of their stories Department of Information Engineering

68

Four Values • Courage – XP employs short cycle, continuous integration, simple design, very fast development, little time on architectural planning – A major flaw in the architecture may be discovered only at very late stage (risky!) – Have courage to fix and to throw code away – Not afraid to constantly redesign (refactoring)

Department of Information Engineering

69

XP’s activities • Coding • Testing – Software features that cannot be demonstrated by automated tests simply don’t exist • Listening – Listen to what the customer says the business problem is • Designing – Creating a structure that organizes the logic in the system (refactoring)

Department of Information Engineering

70

XP Twelve Practices • The planning game • Small releases • Metaphor • Testing • Simple design • Refactoring • Pair programming • Collective ownership • Continuous integration • On-site customer • Coding standards • Forty-hour week Department of Information Engineering

71

XP Twelve Practices • The planning game – Determine the features in the next release through a combination of prioritized stories and technical estimates – A clear separation of business considerations and technical considerations – Balance of power • Business decisions makes by business people • Technical decisions make by programmers

Department of Information Engineering

72

XP Twelve Practices • Business considerations – Scope • How much of a problem must be solved for the system to be valuable – Priority – Composition of releases • What should be included in the software – Dates of releases • What are the important dates of the software that would make a big difference

Department of Information Engineering

73

XP Twelve Practices • Technical considerations – Estimates • How long will a feature take to implement – Consequences • Business decisions can be made only when informed about the consequences – Process • How will the work and the team be organized – Detailed scheduling • Within a release, which stories will be done first?

Department of Information Engineering

74

XP Twelve Practices • Small releases – Release should be as small as possible, containing the most valuable business requirements • Metaphor – The metaphor is a simple shared story or description of how the system works • Testing – Customers write functional tests to test the stories. Programmers write tests to test anything that can break in the code. Write tests before the code – JUnit by Gamma and Beck Department of Information Engineering

75

XP Twelve Practices • Simple design – Keep the design simple by keeping the code simple. Continually look for complexity in the code and removes it at once • change names to be more appropriate, remove comments by improving code • Has the fewest possible classes and methods – XP believes future is uncertain, and one can cheaply change the mind, so don’t speculate too much

Department of Information Engineering

76

XP Twelve Practices • Refactoring – This is a simplifying technique to remove duplication and complexity from code – Refactoring changes are usually small steps that can be done in a couple of hours, e.g. • Renaming a method • Moving a field from one class to another • Consolidating two similar methods into a superclass – Faced with a big refactoring, take it in small steps • Incremental change Department of Information Engineering

77

XP Twelve Practices • Pair programming – Teams of two programmers share a single computer. One writes the code, while the other reviews the code and asks questions like • Is this approach going to work? • What are the test cases? • Is there some way to simplify the system? – A pair may last for only a few hours • Collective ownership – Everyone owns all of the code. This means everyone has the ability to change any code at any time Department of Information Engineering

78

XP Twelve Practices • Continuous integration – Build and integrate the system several times a day whenever any implementation task is completed • On-site customer – A real customer works in the development environment full-time to help define the system, write tests, and answer questions • Coding standards – The programmers adopt a consistent coding standard Department of Information Engineering

79

XP Twelve Practices • Forty-hour week – To be fresh and eager every morning, and tired and satisfied every night – On Friday, one want to be tired and satisfied enough that one feel good about two days to think about something other than work – Overtime is a symptom of a serious problem on the project – Overtime is never allowed for two consecutive weeks

Department of Information Engineering

80

http://www.extremeprogramming.org • This site is full of useful information, the map below is just one of the example

Department of Information Engineering

81

Why the name “Extreme”? • XP takes commonsense principles and practices to extreme level – If code reviews are good, review code all the time (pair programming) – If testing is good, everybody will test all the time (programmers’ unit testing, customers’ functional testing) – If design is good, refactoring all the time Department of Information Engineering

82

Why the name “Extreme”? – If simplicity is good, always use the simplest design that could possibly work – If architecture is important, refining the architecture all the time (metaphor) – If integration testing is important, integrate and test several times a day (continuous integration) – If short iterations are good, make the iterations really, really short (planning game) Department of Information Engineering

83

Why XP is controversial? • Don’t force team members to specialize and becomes analysts, architects, programmers, testers and integrators – every XP programmers participates in all these activities every day • Don’t conduct complete up-front analysis and design – XP project starts with a quick analysis, and continue to make analysis and design decisions

Department of Information Engineering

84

Why XP is controversial? • Develop infrastructure and frameworks as you develop your application, not up-front – Save money and give better business value ($$$) • Don’t write and maintain implementation documentation – Communication in XP projects occurs face-to-face, or through efficient tests and written code

Department of Information Engineering

85

Summary • RUP vs XP – The Rational approach emphasizes on systematic development, good documentation, with a clear division of labour – The XP advocates the opposite • Fast development, less planning, fixed poor decision later by refactoring, documentation is in the code, no division of labour • Both contain certain truth, for comparison, see – A Comparison of the IBM RUP and XP – John Smith (www3.software.ibm.com/ibmdl/pub/software/rational/web/wh itepapers/2003/TP167.pdf) Department of Information Engineering

86

CMM (Capability Maturity Model) • Purpose of CMM – To evaluate the software process capability of an organization • Process capability – Describes the range of expected results that can be achieved by following a software process. – Predict the most likely outcomes to be expected from the next software project • Why? – To outsource project, how to rate the contractors? – To the contractor, how to improve the maturity of its development process? Department of Information Engineering

87

CMM (Capability Maturity Model) • Maturity level is a measure of the process capability of the organization • Maturity level is a well-defined evolutionary plateau toward achieving a mature software process • CMM rates an organization in five maturity levels – Level 1: Initial (Ad hoc) – Level 2: Repeatable (Disciplined process) – Level 3: Defined (Standard, consistent process) – Level 4: Managed (Predictable process) – Level 5: Optimizing (Continuously improving process) Department of Information Engineering

88

CMM (Capability Maturity Model) • Each maturity level has a number of key process areas (KPA) • Each KPA is described in terms of key practices that help to satisfy the goals of that KPA • CMM has – 5 Levels – 18 KPA – 52 goals • A company reaches a certain maturity level if goals of the KPAs are fulfilled Department of Information Engineering

89

Level 1 – The Initial Level • Ad hoc • The organization does not provide a stable environment for developing software • During a crisis, projects typically abandon planned procedures and revert to coding and testing • Success depends entirely on having an exceptional manager and effective software team • The software process capability is unpredictable because the process is constantly changed

Department of Information Engineering

90

Level 2: The Repeatable Level • Policies for managing a software project and procedures to implement these policies are established • Planning and managing new project is based on experience with similar projects • Objective in achieving Level 2 – To institutionalize management process that allow organizations to repeat successful practices developed on earlier projects

Department of Information Engineering

91

Level 3 - The Defined Level • The organization has a standard software process • The standard process is documented • There is a group that is responsible for standardizing the organization’s software process activities • Organization-wide training program is implemented • Projects are tailored to the standard process • Because the process is well-defined, management has good insight into technical progress, and the project cost, schedule, and functionality are under control Department of Information Engineering

92

Level 4 – The Managed Level • The organization sets quantitative quality goals for both software processes and products • Data is collected and analyzed • The measurements provide the quantitative foundation for evaluating the project’s processes and products – Variation in the process performance can be narrowed to within acceptable quantitative boundaries • The process capability is predictable because the process is measured and operates within boundaries – If limits are exceeded, action is taken to correct the situation Department of Information Engineering

93

Level 5 – The Optimizing Level • Focus on continuous process improvement • Identify weaknesses and strengthen the process proactively • Process is improved by incremental advancements in the existing process and by innovations using new technologies and methods

Department of Information Engineering

94

KPA of Repeatable (level 2) • Requirements management – To establish a common understanding between the customer and requirements that will be addressed by the project • Software project planning – To establish realistic plans for managing the project • Software project tracking and oversight – To establish adequate visibility into actual progress so that management can take effective actions when the project’s performance deviates from the plan • Software subcontract management – To select qualified subcontractors and manage them effectively • Software quality assurance – To provide management with appropriate visibility into the process being used by the project and of the products being built • Software configuration management – To maintain the integrity of the products throughout the life cycle Department of Information Engineering

95

KPA of Defined (level 3) • • • • • • •

Organization process focus – To establish the organization responsibility for process activities that improve the overall software process capability Organization process definition – To develop and maintain a usable set of software process assets that improve process performance Training program – To develop the skills and knowledge of individuals Integrated software management – To integrate the software engineering and management activities into a defined software process that is tailored from the standard process Software product engineering – To consistently perform a well-defined engineering process that produce correct, consistent software projects effectively Intergroup coordination – To establish a means for the engineering group to participate actively with the other groups Peer reviews – To remove defects from the products early and efficiently

Department of Information Engineering

96

KPA of Managed (level 4) • Quantitative process management – To control the process performance of the software project quantitatively • Software quality management – To develop a quantitative understanding of the quality of the project’s software products and achieve specific quality goals

Department of Information Engineering

97

KPA of Optimizing (level 5) • Defect prevention – To identify the causes of defects and prevent them from recurring • Technology change management – To identify beneficial new technologies • Process change management – To continually improve the software processes used in the organization with the intent of improving software quality, increasing productivity and decreasing the time for product development Department of Information Engineering

98

Common Features • Practices in each KPA share a set of common features – Commitment to Perform – Ability to Perform – Activities Perform – Measurement and Analysis – Verifying Implementation • To ensure the activities are in compliance with established process • The common features are attributes that indicate whether the implementation of a KPA is effective, repeatable, and lasting Department of Information Engineering

99

CMM (Capability Maturity Model) • CMM – A set of guidelines that tells organization what to do in general terms, but does not say how to do it • RUP and XP say how • If a company is practicing either RUP or XP, are the practices suggested by RUP or XP compatible with CMM?

Department of Information Engineering

100

Requirements Management KPA (Level 2) • To establish a common understanding between the customer and the software project • Goal-1 – System requirements that are allocated to software are controlled to establish a baseline for software engineering and management use • Goal-2 – Software plans, products, and activities are kept consistent with the system requirements allocated to software

Department of Information Engineering

101

RUP’s perspective on requirement management • The formal baselines correspond to the following milestones – Lifecycle Objectives Milestone (inception) – Lifecycle Architecture Milestone (elaboration) – Initial Operational Capability Milestone (Construction) – Product Release Milestone (transition) • Use-Case Approach – The requirements are flowed down to various visual RUP models to ensure consistency and adherence • Controlled Iterative Development – A risk mitigation approach that uncovers risks early XP’s perspective on requirement management • Use of stories, onsite customer, and continuous integration to achieve a common understanding Department of Information Engineering

102

Software Project Planning KPA • To establish reasonable plans for performing the software engineering and for managing the project • Goal-1 – Software estimates are documented for use in planning and tracking the software project • Goal-2 – Software project activities and commitments are planned and documents • Goal-3 – Affected groups and individuals agree to their commitments related to the software project

Department of Information Engineering

103

RUP’s perspective on project planning • Assessment is documented in Status Assessment Report, which tracks resources, top ten risks, progress, and results • Metrics used – Progress (lines of code, number of classes, …) – Quality (defect discovery rate, …) – Maturity (test hours per failure) – Expenditure profiles on resources (planned vs actuals) • Documents that capture project plans and commitments – Business case, Software development Plan, Measurement Plan, Risk List, Project Plan, Iteration Plan, Iteration Assessment, Status Assessment • Software Development Plan defines the overall plan of the project • Iteration Plan defines what is to be accomplished in an iteration • Iteration Plan Review exposes the plan to all stakeholders, allowing for a consensus to be developed Department of Information Engineering

104

XP’s perspective on project planning • Planning game and small releases • “if you can’t plan well, plan often” – Project plan is not detailed for the project’s whole life cycle – Metaphor does establish a vision for project direction • Team commitment through estimating the effort involved to implement the stories • Two-week (small) releases, estimates are usually accurate • Customer maintains control of business priorities by choosing which stories to implement next Department of Information Engineering

105

Software Project Tracking and Oversight • To establish adequate visibility into actual progress so that management can take effective actions when the project’s performance deviates significantly from plans • Goal-1 – Actual results and performance are tracked against the software plans • Goal-2 – Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans Department of Information Engineering

106

RUP’s perspective on project tracking and oversight • Project plans and Status Assessment Report are used to compare planned versus actual performance – The report is the Project Manager’s responsibility • Milestones have well defined completion criteria • Risk List serves as input to planning and project assessments • Project Manager collects metrics to produce a Status Assessment • Problems identified in the Assessment are dealt with in the Problem Resolution Plan either by the Project Manager or though Change Requests • Each iteration is subjected to an Iteration Assessment and Review, in which corrective actions can be taken through Change Requests XP’s perspective on project tracking and oversight • Project velocity, commitments (stories) for small releases • XP’s commitment process sets clear expectations for both the customer and the XP team Department of Information Engineering

107

Software Subcontract Management • To select qualified software subcontractors and manage them effectively • Goal-1 – The prime contractor selects qualified software subcontractors • Goal-2 – The prime contractor and the software subcontractor agree to their commitments to each other • Goal-3 – The prime contractor and the software subcontractor maintain ongoing communication • Goal-4 – The prime contractor tracks the software subcontractor’s actual results and performance against its commitments • These goals fall outside the current scope of RUP and XP, and are dependent on the organization Department of Information Engineering

108

Software Quality Assurance • To provide management with appropriate visibility into the process being used by the project and the products being built • Goal-1 – Software quality assurance activities are planned • Goal-2 – Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively • Goal-3 – Affected groups and individuals are informed of software quality assurance activities and results • Goal-4 – Noncompliance issues that cannot be resolved within the software project are addressed by senior management Department of Information Engineering

109

RUP’s perspective on quality assurance • RUP’s milestone has specific completion criteria that can serve as a basis for auditing • Each activity within RUP has a separate review activity • Each review has a set of checkpoints that need to be passed • RUP’s metrics – Progress (lines of code, number of classes, …) – Quality (defect discovery rate, …) – Maturity (test hours per failure) – Expenditure profiles on resources (planned vs actual) • Goal-4 falls beyond the scope of RUP XP’s perspective on quality assurance • An independent SQA group is unlikely in XP culture • SQA could be addressed by peer pressure in pair-programming Department of Information Engineering

110

Software Configuration Management • To establish and maintain the integrity of the projects throughout the project’s software lifecycle • Goal-1 – Software configuration management activities are planned • Goal-2 – Selected software work products are identified, controlled, and available • Goal-3 – Changes to identified software work products are controlled • Goal-4 – Affected groups and individuals are informed of the status and content of software baselines Department of Information Engineering

111

RUP’s perspective on configuration management • Configuration Management Plan – Managing software versioning and handling – Managing changes using the change control method • Integration Build Plan – Provides details on configuration items and the order to be integrated in an iteration • Change Control Board to manage and implement change requests XP’s perspective on configuration management • Not completely and explicitly addressed • Implied in XP’s collective ownership, small releases, and continuous integration • Collective ownership might be problematic for large systems Department of Information Engineering

112

Ref • “Key Practices of the CMM Version 1.1”, Paulk et al (almost 500 pages about CMM downloadable) (http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr25.93.pdf)

• Extreme Programming from a CMM Perspective – M.C. Paulk, IEEE Software Nov/Dec 2001 • Reaching CMM Levels 2 and 3 with the RUP (http://www3.software.ibm.com/ibmdl/pub/software/rati onal/web/whitepapers/2003/rupcmm.pdf) • www.azeus.com – The first Chinese Level-5 company based in HK Department of Information Engineering

113