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
2Department of Information Engineering
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
3Department of Information Engineering
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
4Department of Information Engineering
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
5Department of Information Engineering
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
6Department of Information Engineering
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
7Department of Information Engineering
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)
8Department of Information Engineering
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
9Department of Information Engineering
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
10Department of Information Engineering
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
11Department of Information Engineering
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
13Department of Information Engineering
• 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
14Department of Information Engineering
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
15Department of Information Engineering
Milestones
Inception Elaboration Construction Transition
LifecycleObjectiveMilestone
LifecycleArchitectureMilestone
Initial OperationalCapabilityMilestone
ProductReleaseMilestone
16Department of Information Engineering
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?
17Department of Information Engineering
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
18Department of Information Engineering
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
19Department of Information Engineering
Objectives of the Elaboration Phase
• Key objectives
– Addresses risks
– Builds an early skeleton architecture
– Refine the project plans
20Department of Information Engineering
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
21Department of Information Engineering
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
22Department of Information Engineering
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
23Department of Information Engineering
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
24Department of Information Engineering
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?
25Department of Information Engineering
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
26Department of Information Engineering
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
27Department of Information Engineering
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?
28Department of Information Engineering
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
30Department of Information Engineering
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
31Department of Information Engineering
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
32Department of Information Engineering
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
33Department of Information Engineering
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
34Department of Information Engineering
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
37Department of Information Engineering
Notation used in RUP
RoleRole
ActivitiesActivities
System AnalystUse-CaseModel
Use-CaseDesign
Use-case realization
ArtifactArtifactresponsible for
Requirement workflow
38Department of Information Engineering
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
39Department of Information Engineering
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
40Department of Information Engineering
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
41Department of Information Engineering
• 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
42Department of Information Engineering
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
43Department of Information Engineering
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
44Department of Information Engineering
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
46Department of Information Engineering
Workflow in project management
Resemble a UMLactivity diagram
47Department of Information Engineering
• 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
48Department of Information Engineering
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
49Department of Information Engineering
• 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)
50Department of Information Engineering
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
51Department of Information Engineering
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
52Department of Information Engineering
• 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
53Department of Information Engineering
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
54Department of Information Engineering
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
55Department of Information Engineering
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
56Department of Information Engineering
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
57Department of Information Engineering
Cost of Change
• XP’s belief
– The cost of change may not rise dramatically over time
time
Cost of change
58Department of Information Engineering
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
59Department of Information Engineering
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)
60Department of Information Engineering
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
61Department of Information Engineering
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
62Department of Information Engineering
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
63Department of Information Engineering
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
64Department of Information Engineering
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
65Department of Information Engineering
Values and Practices
• XP preaches 4 values, 4 activities, and 12 practices
• Four values
– Communication
– Simplicity
– Feedback
– Courage
66Department of Information Engineering
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
67Department of Information Engineering
• 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
68Department of Information Engineering
• 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
69Department of Information Engineering
• 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
70Department of Information Engineering
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)
71Department of Information Engineering
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
72Department of Information Engineering
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
73Department of Information Engineering
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
74Department of Information Engineering
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?
75Department of Information Engineering
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
76Department of Information Engineering
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
77Department of Information Engineering
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
78Department of Information Engineering
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
79Department of Information Engineering
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
80Department of Information Engineering
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
81Department of Information Engineering
http://www.extremeprogramming.org
• This site is full of useful information, the map below is just one of the example
82Department of Information Engineering
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
83Department of Information Engineering
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)
84Department of Information Engineering
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
85Department of Information Engineering
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
86Department of Information Engineering
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)
87Department of Information Engineering
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?
88Department of Information Engineering
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)
89Department of Information Engineering
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
90Department of Information Engineering
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
91Department of Information Engineering
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
92Department of Information Engineering
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
93Department of Information Engineering
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
94Department of Information Engineering
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
95Department of Information Engineering
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
96Department of Information Engineering
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
97Department of Information Engineering
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
98Department of Information Engineering
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
99Department of Information Engineering
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
100Department of Information Engineering
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?
101Department of Information Engineering
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
102Department of Information Engineering
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
103Department of Information Engineering
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
104Department of Information Engineering
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
105Department of Information Engineering
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
106Department of Information Engineering
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
107Department of Information Engineering
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
108Department of Information Engineering
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
109Department of Information Engineering
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
110Department of Information Engineering
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
111Department of Information Engineering
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
112Department of Information Engineering
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
113Department of Information Engineering
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
Top Related