You are on page 1of 30

p 


  



|
Software Process Models
ë Software process models are general
approaches for organizing a project into
activities.
ë Help the project manager and his or her team to
decide:
ë What work should be done;
ë In what sequence to perform the work.
ë The models should be seen as ›    Œ
not rigid prescriptions of the way to do things.
ë ºach project ends up with its own unique plan.
2
The opportunistic approach

First o i Thin o ea
rotot pe Unti or
atis ie pro e ent

« is what occurs when


ë

ë an organization oes not o ow goo engineering practices.

Ñ
What is R P?
ë R P was originally developed by Rational
Software (now part of IBM)
ë It is a software engineering process
ë It enhances team productivity
ë It creates and maintains models
ë It is a guide to effectively use the nified Modeling
Language
ë Its goal is to delivery a high quality product
that the customer actually wants

What is R P?
ë SoŒ this is the most widely known
methodology that embraces ML
ë Created to support the OO design and modeling.
ë Designed to be adaptable
ë Suggests a process framework
ë Adapts to the project needs
ë se-case-driven development
ë Architecture-centric process
ë Iterative and incremental process
r
R P provides
ë Several mechanismsŒ including
ë relatively short-term iterations
ë with well-defined goals
ë go/no-go decision points at the end of each phaseŒ
to provide management visibility into the
development process

ü
Why not use Waterfall instead?
ë The Waterfall method follows a sequential
approach to software development.
ë This limits the ability to react to any change or correct
problems in a timely matter.
ë Assumptions
ë Requirements never change
ë All information is known upfront
ë The customer will be satisfied with the end results
ë Technology will not change when it comes time to
integrate

*
R P Phase Model

ë All phases are iterative (and concurrent) in nature

A
Structure of R P
ë R P is structured in two dimensions
ë Phases
ë which represent the four major stages that a project go through
over timeΠand
ë Disciplines
ë which represent the logical activities that take place throughout
the project
ë It has two aspects
ë Serial aspect is captured in its phases
ë Iterative aspect is captured in its disciplines (?)

ÿ
Iterations and Phases-
º  


  
 
 
 
  
   


2              


   

   
    
    
    
    
    
    
    


ë An iteration is a distinct sequence of activities


ë with an established plan and
ë evaluation criteriaŒ
ë resulting in an executable release.

|
Iterative Lifecycle Graph
  

 



 
  








!
"


"
!


#

||
R P Characteristics (AmblerΠ2 r)

ë Serial in the large


ë The phases are serial in nature over time
ë Much like seasons of a project/year!
ë Iterative in the small
ë R P phases are divided into one or more iterations
ë Reflected in how you approach its Disciplines
ë Delivering incremental releases over time
ë Release |Œ release 2 and so on.
ë ollowing proven best practices
ë se several best practices

|2
R P Phases
ë Inception
ë VisionŒ high level requirementsŒ business case
ë Not detailed requirements
ë ºlaboration
ë Specify requirements in greater detail and define the
architecture for the system
ë Not detailed design
ë Construction
ë The focus here is to develop the application to the point
where it is ready for deploymentΠ(testing is done as well)
ë Transition
ë We can now delivery the system into production
(Stakeholder acceptance) |Ñ
R P Phase |: Inception
ë Inception
ë Customer communication
ë Planning
ë Identify resourcesŒ assess risksŒ defines schedule
ë Business requirements
ë In the form of use cases.
ë Rough architecture
ë A tentative outline of major sub-systemsŒ functions and
features that populate them.
ë Not detailed requirements

|
Inception: Lifecycle Objectives
(LCO) milestone
ë Stakeholders must agreeŒ
ë On the scope of the project
ë That the initial requirements have been identified (although
without much detail)
ë That your software development plan is realistic
ë That the risks have been identified and are being managed
appropriately
ë That the business case for the project makes sense
ë That the development process has been tailored
appropriately

|r
R P Phase 2: ºlaboration
ë ºlaboration
ë Customer communication
ë Modeling activity
ë ºxpands the use cases
ë ºxpands the architecture to:
ë se case modelŒ analysis modelŒ design modelŒ implementation
model and deployment model.
ë Review plan and make modifications
ë ºvaluate scopeŒ risksŒ project delivery dates
ë NOT detailed design


ºlaboration: Lifecycle
Architecture (LCA) milestone
ë Stakeholders must agree that theŒ
ë Project vision has stabilized and is realistic
ë Requirements for the project: still might evolve
ë Architecture is stable and sufficient to satisfy the requirements
ë Risks are continuing to be managed
ë Current expenditures are acceptable and reasonable estimates
have been made for future costs and schedules
ë Project team has a realistic chance to succeed
ë Detailed iteration plans for the next few Construction iterationsŒ
as well as a high-level project planΠare in place

|*
R P Phase Ñ: Construction
ë Construction
ë Develop software components (that make the use
cases operational).
ë Complete the analysis and design models.
ë Implement all functions and features for that
increment.
ë Conduct unit testing for the components
ë Integrate components.

|A
Construction: Initial Operational
Capability (IOC) Review
ë Stakeholders must agree thatŒ
ë Software and supporting documentation are acceptable to
deploy
ë Stakeholders (and the business) are ready for the system to
be deployed
ë Risks are continuing to be managed effectively
ë Current expenditures are acceptable and reasonable
estimates have been made for future costs and schedules
ë Detailed iteration plans for the next few Transition iterationsŒ
as well as a high-level project planΠare in place

|ÿ
R P Phase : Transition
ë Transition
ë Create user manualsŒ guidelinesŒ installation
procedures.
ë Software is given to users for beta testing.
ë Get user feedback
ë The increment is now a useable software release.

2
Transition: Product Release (PR)
Milestone
ë Stakeholders must agree thatŒ
ë SystemŒ including supporting documentation and
trainingΠis ready for deployment
ë Current expenditures are acceptable and
reasonable estimates have been made for future
costs
ë System can be operated once it is in production
ë System can be supported appropriately once it is
in production

2|
R P disciplines (activities in phases)
ë Business Modeling
ë Goal is to understand the business of the organization
ë Requirements
ë Goal is to define Scope: What is and is not to be built
ë Analysis and Design
ë Goal is to analyze the requirements and design the
solution
ë Implementation
ë Goal is to execute the code based on the design

22
R P disciplines (activities in phases)
ë Test
ë The goal is to verify all aspects of the system to ensure
quality
ë Deployment
ë The goal is plan and deliver a working system to the
customer
ë Configuration and change management
ë The goal is to manage access to the project¶s work
products
ë Not only tracking versions over time but also controlling
and managing changes to them


R P disciplines (activities in phases)
ë Project Management
ë The goal is to direct the activities that take place on the
project
ë Includes managing risksŒ directing people and coordinating
with people
ë ºnvironment
ë The goal is to support the rest of the efforts in terms in
ensuring that the proper processΠguidance (standards and
guidelines)Πtools (hardwareΠsoftware) are available to the
team as needed.

2
Best Practices of the R P
ë Adapt the process
ë Adapt R P appropriately based on the
development needs
ë Balance competing stakeholders
ë Balance their priorities when they often change
ë Take an evolutionary approach by keeping
stakeholders as active participants
ë Collaborating Across Teams
ë Keep an open communication process
ë Provide effective tools and working environment
2r
Best Practices of the R P
ë Demonstrate Value Iteratively
ë Organize your project into iterations
ë Deliver working software early and regularly
ë ºlevate the level of Abstraction
ë Adapt modeling toolsŒ
ë reuse existing codeŒ and
ë focus on architecture
ë ocus continuously on Quality
ë This is done by testing at every major part of the project


Disadvantages of R P
ë The process may be
ë too complex to implement
ë Development can get
ë out of control
ë It is a
ë heavyweight process
ë You need
ë an expert to fully adopt this process

2*
Advantages of R P
ë Improved governance
ë True earned valueŒ delivery of high quality software
ë One can easily determine whether R P team is on track or
not
ë Regular feedback from and to stakeholders
ë Can see portions of the system sooner and receive
assurance that they will receive what they want
ë Improved risk management
ë Working incrementally allows higher risks to be addressed
early
ë You implement the actual requirements
ë You can react to any changes as you are developing in small
iterations
2A
Advantages of R P
ë You discover what works early
ë ºlaboration phase ensures that your architecture works early in
your project
ë Developing the skeleton for your system you mitigate much of the
technical risk
ë Developers focus on what matters
ë Developers can find out important issues to work on depending on
the circumstances
ë With traditional approaches a team will often spend months
modelingΠwriting documentationΠreviewing their workΠwaiting for
acceptanceΠreworking things and developing detailed plans

2ÿ
References
ë Rational nified Process: Best Practices for
Software Development Teams
http://www.ibm.com/developerworks/rational/library/conte
nt/ Ñuly/| /|2r|/|2r|bestpracticesTP 2üB.pdf
ë A Manager¶s Introduction to the Rational
nified Process (R P)
http://www.ambysoft.com/downloads/managersIntroToR
P.pdf
ë The Rational nified Process
http://www.menloinnovations.com/freestuff/whitepapers/R
ational%2 nified%2 Process.pdf

You might also like