department of information engineering670 software engineering “why programming is hard to...

1Department of Information Engineering

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


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


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

A B1

A B1

A B1

A B[1]

A B

A B

A B

A B1


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


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


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


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)


4+1 view model of architecture

• RUP’s architecture is represented by 5 views

– Like different blueprints represent different aspects of building

Use-CaseView

LogicalView

ImplementationView

ProcessView

DeploymentView



• 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



• 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


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


RUP Process structure


• 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


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


Milestones

Inception Elaboration Construction Transition

LifecycleObjectiveMilestone

LifecycleArchitectureMilestone

Initial OperationalCapabilityMilestone

ProductReleaseMilestone


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?


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


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


Objectives of the Elaboration Phase

• Key objectives

– Addresses risks

– Builds an early skeleton architecture

– Refine the project plans


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


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


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


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


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?


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


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


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?


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


Workflows in an iteration


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


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


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


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


Activities and Artifacts

• Activities RolePlan an iteration Project ManagerFind use cases and actors System AnalystReview the design Design ReviewerExecute 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


Example of artifacts produces


An analyst’s involvement in RUP

Analyst


Notation used in RUP

RoleRole

ActivitiesActivities

System AnalystUse-CaseModel

Use-CaseDesign

Use-case realization

ArtifactArtifactresponsible for

Requirement workflow


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


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


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


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

Resource

Peter

Paul

Mary

Simon

Role Activities

Designer Object Design

Use-case Author Detail a Use Case

Use-Case Designer Use Case Design

Architect Architectural AnalysisArchitectural Design


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


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


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


Role of Project Manager in the Project Management workflow


Workflow in project management

Resemble a UMLactivity diagram


• 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


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


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


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


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


• 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


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


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


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


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

Requirements Analysis Design Implementation Testing Production

Cost of change


Cost of Change

• XP’s belief

– The cost of change may not rise dramatically over time

time

Cost of change


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


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)



• 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



• 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


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


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


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


Values and Practices

• XP preaches 4 values, 4 activities, and 12 practices

• Four values

– Communication

– Simplicity

– Feedback

– Courage


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


• 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

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 use-cases), the programmers immediately estimate them, so customers have concrete feedback about the quality and cost of their stories

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)

Four Values


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)


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


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


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


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?


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


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


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


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


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


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


http://www.extremeprogramming.org

• This site is full of useful information, the map below is just one of the example


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


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)


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


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


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/whitepapers/2003/TP167.pdf)


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?


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)



• 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


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


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


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


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


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


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


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


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


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


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



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


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


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


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


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


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


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


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


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


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


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


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


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


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/

rational/web/whitepapers/2003/rupcmm.pdf)

• www.azeus.com– The first Chinese Level-5 company based in HK