Kroll Rational Easy Made Unified

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 113

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 1 B
– Booth (1st ed.)
A 1 B
– Booth (2nd ed.)
1
– Coad A B
[1]
– Jacobson A B

– Martin/Odell A B
– Shlaer/Mellor A B
– Rumbaugh A B
1 B
– UML A

Department of Information Engineering 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 Implementation
View View
Use-Case
View

Process Deployment
View View

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

Lifecycle Lifecycle Initial Operational Product


Objective Architecture Capability Release
Milestone Milestone Milestone Milestone

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

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 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
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
Activities
Requirement workflow

Role

Use-Case Use-Case
System Analyst Model Design

responsible for
Artifact

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 Testing Production

Department of Information Engineering 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 use-
cases), 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

You might also like