Professional Documents
Culture Documents
|
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
Ñ
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
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-
º
|
Iterative Lifecycle Graph
!
"
"
!
#
||
R P Characteristics (Ambler 2 r)
|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
2Ñ
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
2ü
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