Introduccin a RUP

Prcticas, principios y fases

USAC - Anlisis y diseo de sistemas 1
Segundo semestre 2013
Qu es RUP?
There are three central elements that define RUP:
An underlying set of philosophies and principles for
successful software development. These philosophies and
principles are the foundation on which the RUP has been
developed.
A framework of reusable method content and process
building blocks. Defined and improved on an ongoing basis building blocks. Defined and improved on an ongoing basis
by Rational Software, the RUP family of method plug-ins
defines a method framework from which you create your own
method configurations and tailored processes.
The underlying method and process definition language.
Underlying it all is a unified method architecture meta-
model. This model provides a language for describing method
content and processes.
Cundo usar RUP?
RUP can be used right from the start of a new software project, and
can continue to be used in subsequent development cycles long
after the initial project has ended. However, the way in which RUP is
used needs to be varied appropriately to suit your needs. There are a
few considerations that will determine when and how you will use
different parts of RUP:
project lifecycle (number of iterations, length of each phase, project
length)
project business goals, Vision, scope and Risk project business goals, Vision, scope and Risk
size of the Software Development Effort
Prcticas Prcticas
Prcticas
The Rational Unified Process six tried-and-true best practices
have been the basis for the evolution of our Rational's tools
and processes for more than a decade.
Today, as software development is becoming a key business
capability, our best practices are maturing within the larger
context of business-driven development.
The following principles re-articulate our best practices for the
broader lifecycle of continuously evolving systems, in which broader lifecycle of continuously evolving systems, in which
the primary evolving element is software. They are:
Adapt the Process
Balance Competing Stakeholder Priorities
Collaborate Across Teams
Demonstrate Value Iteratively
Elevate Level of Abstraction
Focus Continuously On Quality
Adaptar el proceso
This principle states that it is critical to right-size the
development process to the needs of the project. More is not
better, less is not better: Instead, the amount of ceremony,
precision, and control present in a project must be tailored
according to a variety of factors including the size and
distribution of teams, the amount of externally imposed
constraints, and the phase the project is in
Adaptar el proceso (II)
We need to right-size the process to project needs. As a
project grows in size, becomes more distributed, uses more
complex technology, has larger number of stakeholders, and
needs to adhere to more stringent compliance standards, the
process needs to become more disciplined
A project should adapt process ceremony to lifecycle phase. In
the beginning of the project on the one hand, we are usually
faced with a lot of uncertainty, and we must strongly faced with a lot of uncertainty, and we must strongly
encourage creativity to develop an application that addresses
business needs. More process typically leads to less creativity,
not more; we must therefore minimize process in the early
stages of a project where uncertainty is an every day factor.
Late in the project, on the other hand, we will need to
introduce more control, such as change control boards, to
prevent undesired creativity and associated risk, which often
leads to the late introduction of defects into the product: This
translates to more process.
Adaptar el proceso (III)
An organization should strive to continuously
improve the process. Consider performing an
assessment after each iteration and at project end to
capture lessons learned, and leverage that
knowledge to improve the process.
Finally, it is critical to balance project plans and Finally, it is critical to balance project plans and
associated estimates with the uncertainty of a
project. This means that, early in projects, when
uncertainty is typically large, plans and associated
estimates will focus on big-picture planning and
estimates, rather than aiming at providing high levels
of precision when there is in fact none.
Balancear prioridades en competencia de
los stakeholders
This principle articulates the importance of balancing often conflicting
business and stakeholder needs, as well as balancing custom
development versus asset reuse in the satisfaction of these needs.
Rather than sending programming teams out to attack each element
in a requirements list, we need to understand and prioritize business
and stakeholder needs. This means capturing business processes
and linking them to projects and software capabilities, which enables
us to effectively prioritize projects and requirements, and to modify
our prioritization as our understanding of the application increases our prioritization as our understanding of the application increases
and stakeholder needs evolve. It also means that we need to involve
the customer or customer representative in the project to ensure we
understand what their needs are.
At the same time, we need to center development activities around
stakeholder needs. For example, by leveraging use-case driven
development and user-centered design, our development process
can accommodate the evolution of stakeholder needs over the
course of the project, as a function of changing business and of our
improved understanding of the capabilities that are truly important to
the business and the end users.
Colaborar a lo largo de equipos
This principle stresses the importance of fostering optimal project-
wide communication. This is achieved through proper team
organization and the setting up of effective collaborative
environments
Software is produced by talented and motivated people collaborating
closely. Many complex systems require the collaboration of a number
of stakeholders with varying skills, and the largest projects often
span geographical and temporal boundaries, further adding
complexity to the development process. This is why people issues complexity to the development process. This is why people issues
and collaboration -- what some have referred to as the "soft" element
of software development -- have been a primary focus in the agile
development community . Following this principle requires
answering many questions, including:
How do we motivate people to perform at their best?
How do we collaborate within a co-located versus a distributed software
team?
How do we collaborate across teams responsible for the business,
software development, and IT operations?
Demostrar valor iterativamente
This principle explain why software development greatly
benefits from being iterative. An iterative process makes
it possible to easily accommodate change, to obtain
feedback and factor it into the project, to reduce risk
early, and to adjust the process dynamically.
There are several imperatives underlying this principle. There are several imperatives underlying this principle.
The first one is that we must deliver incremental value to
enable early and continuous feedback. This is done by
dividing our project into a set of iterations. In each
iteration, we perform some requirements, design,
implementation, and testing of our application, thus
producing a deliverable that is one step closer to the final
solution.
Demostrar valor iterativamente (II)
The second imperative is to leverage demonstrations and
feedback to adapt our plans. Rather than relying on
assessing specifications, such as requirements
specifications, design models, or plans, we need instead
to assess how well the code developed thus far actually
works. This means that me must use test results and
demonstrations of working code to stakeholders to demonstrations of working code to stakeholders to
determine how well we are doing.
The third underlying imperative is to embrace and
manage change. Today's applications are too complex for
the requirements, design, implementation, and test to
align perfectly the first time through. Instead, the most
effective application development methods embrace the
inevitability of change.
Demostrar valor iterativamente (III)
The fourth imperative underlying this principle is the
need to drive out key risks early in the lifecycle, as
illustrated in the diagram below.
Elevar el nivel de abstraccin
Complexity is a central issue in software development. Elevating the
level of abstraction helps reduce complexity as well the amount of
documentation required by the project. This can be achieved through
reuse, the use of high-level modeling tools, and stabilizing the
architecture early.
One of the main problems we face in software development is
complexity. We know that reducing complexity has a major impact on
productivity. Working at a higher level of abstraction reduces
complexity and facilitates communication. complexity and facilitates communication.
One effective approach to reducing complexity is reusing existing
assets, such as reusable components, legacy systems, existing
business processes, patterns, or open source software. Two great
examples of reuse that have had a major impact on the software
industry over the last decade are:
The reuse of middleware, such as databases, web servers and portals,
and, more recently,
Open source software that provides many smaller and larger components
that can be leveraged.
Enfocarse continuamente en la calidad
This principle emphasizes that, to achieve quality, it must be addressed throughout the
project lifecycle. An iterative process is particularly adapted to achieving quality since
it offers many measurement and correction opportunities.
Improving quality is not simply "meeting requirements," or producing a product that
meets user needs and expectations. Rather, quality also includes identifying the
measures and criteria that demonstrate its achievement, as well as the
implementation of a process to ensure that the product has achieved the desired
degree of quality, and that this can be repeated and managed.
Ensuring high quality requires more than the participation of the testing team; it
requires that the entire team owns quality. It involves all team members and all parts
of the lifecycle: of the lifecycle:
Analysts are responsible for making sure that requirements are testable, and that we specify
clear requirements for the tests to be performed.
Developers need to design applications with testing in mind, and must be responsible for
testing their code.
Managers needs to ensure that the right test plans are in place, and that the right resources
are in place for building the testware and performing required tests.
Testers are the quality experts. They guide the rest of the team in understanding software
quality issues, and they are responsible all product testing (including functional, system, and
performance).
Principios Principios
1. Vision: Develop a Vision
In particular, developing a clear Vision is key to developing a
product that meets your stakeholders' real needs".
In RUP, the Vision artifact captures very high-level
requirements and design constraints, to give the reader an
understanding of the system to be developed. It provides input
to the project-approval process, and is therefore intimately
related to the Business Case. It communicates the related to the Business Case. It communicates the
fundamental "why and what related to the project and is a
gauge against which all future decisions should be validated.
Developing a clear vision and an understandable set of
requirements is the essence of the Requirements discipline,
and the principle Balance Competing Stakeholder Priorities.
This involves analyzing the problem, understanding
stakeholder needs, defining the system, and managing the
requirements as they change.
2. Plan: Manage to the Plan
"The product is only as good as the plan for the product" ( FIS96 ).
Conceiving a new project; evaluating scope and risk; monitoring and
controlling the project; planning for and evaluating each iteration and
phase - these are the "essence" of the Project Management
discipline.
A Software Development Plan gathers the information required to
manage the project. It is used to plan the project schedule and
resource needs, and to track progress against the schedule. It
addresses such areas as: project organization, schedule, budget, addresses such areas as: project organization, schedule, budget,
and resources. It may also include plans for requirements
management, configuration management, problem resolution, quality
assurance, evaluation and test, and product acceptance.
The format of the planning artifacts are not as important as the
planning activities and the thought that goes into them. It doesn't
matter what the plans look like - or what tools you use to build them.
As Dwight D. Eisenhower said, "The plan is nothing; the planning is
everything."
3. Risks: Mitigate Risks and Track Related
Issues
It is essential to identify and attack the highest risk
items early in the project and track them, along with
other related issues. The Risk List is intended to
capture the perceived risks to the success of the
project. It identifies, in decreasing order of priority,
the events which could lead to a significant negative the events which could lead to a significant negative
outcome.
Along with each risk, should be a plan for mitigating
that risk. This serves as a focal point for planning
project activities, and is the basis around which
iterations are organized.
4. Business Case: Examine the Business
Case
The Business Case provides the necessary information, from a
business standpoint, to determine whether or not this project is worth
investing in.
The main purpose of the Business Case is to develop an economic
plan for realizing the project Vision. Once developed, the Business
Case is used to make an accurate assessment of the return on
investment (ROI) provided by the project. It provides the justification
for the project and establishes its economic constraints. It provides
information to the economic decision makers on the project's worth, information to the economic decision makers on the project's worth,
and is used to determine whether the project should move ahead.
The description should not delve deeply into the specifics of the
problem, but rather it should create a compelling argument why the
product is needed. It must be brief, however, so that it is easy
enough for all project team members to understand and remember.
At critical milestones, the Business Case is re-examined to see if
estimates of expected return and cost are still accurate, and whether
the project should be continued
5. Architecture: Design a Component
Architecture
In the Rational Unified Process (RUP), the architecture of a software system
(at a given point) is the organization or structure of the system's significant
components interacting through interfaces, with components composed of
successively smaller components and interfaces. What are the main pieces?
And how do they fit together? Do we have a framework on which the rest of
the software can be added?
To speak and reason about software architecture, you must first define an
architectural representation, a way of describing important aspects of an
architecture. This description is captured in the Software Architecture
Document, which presents the architecture in multiple views. Document, which presents the architecture in multiple views.
Each architectural view addresses some specific set of concerns, specific to
stakeholders in the development process: users, designers, managers,
system engineers, maintainers, and so on. This serves as a communication
medium between the software architect and other project team members
regarding architecturally significant decisions which have been made on the
project.
Defining a candidate architecture, refining the architecture, analyzing
behavior, and designing components of the system is the "essence" of the
Analysis and Design discipline, and the principle Elevate Level of
Abstraction.
6. Prototype: Incrementally Build and Test
the Product
The RUP is an iterative approach of building, testing,
and evaluating executable versions of the product in
order to flush out the problems and resolve risks and
issues as early as possible.
Incrementally building and testing the components of
the system is the "essence" of the the system is the "essence" of the
Implementation and Test disciplines, and
the principle Demonstrate Value Iteratively.
7. Evaluation: Regularly Assess Results
Continuous open communication with objective data derived directly from
ongoing activities, and the evolving product configurations are important in
any project. Regular status assessments provide a mechanism for
addressing, communicating, and resolving management issues, technical
issues, and project risks. In addition to identifying the issues, each should
be assigned a due date, with a responsible person who is accountable for
the resolution. This should be regularly tracked and updated as necessary.
These project snapshots provide the heartbeat for management attention.
While the period may vary, the forcing function needs to capture the project
history and resolve to remove any roadblocks or bottlenecks that restrict history and resolve to remove any roadblocks or bottlenecks that restrict
progress.
The Iteration Assessment captures the results of an iteration, the degree to
which the evaluation criteria were met, the lessons learned and process
changes to be implemented.
The Iteration Assessment is an essential artifact of the iterative approach.
Depending on the scope and risk of the project and the nature of the
iteration, it may range from a simple record of demonstration and outcomes
to a complete formal test review record.
The key here is to focus on process problems, as well as product problems:
"The sooner you fall behind, the more time you will have to catch up."
8. Change Requests: Manage and Control
Changes
As soon as the first prototype is put before the users (and often even before
that), changes will be requested. (One of those certainties of life!) In order to
control those changes and effectively manage the scope of the project and
expectations of the stakeholders, it is important that all changes to any
development artifacts be proposed through Change Requests and managed
with a consistent process.
Change Requests are used to document and track defects, enhancement
requests and any other type of request for a change to the product. The
benefit of Change Requests is that they provide a record of decisions, and,
due to their assessment process, ensure that impacts of the potential due to their assessment process, ensure that impacts of the potential
change are understood by all project team members. The Change Requests
are essential for managing the scope of the project, as well as assessing the
impact of proposed changes.
Manage and controlling the scope of the project, as changes occur
throughout the project lifecycle, while maintaining the goal of considering all
stakeholder needs and meeting those, to whatever extent possible - this is
the "essence" of the Configuration and Change Management discipline, and
the Supporting Material: Control Changes.
9. User Support: Deploy a Usable Product
The purpose of a process is to produce a usable
product. All aspects of the process should be
tailored with this goal in mind. The product is
typically more than just the software. At a minimum,
there should be a User's Guide, perhaps
implemented through online help. You may also implemented through online help. You may also
include an Installation Guide and Release Notes.
Depending on the complexity of the product, training
materials may also be needed, as well as a bill of
materials along with any product packaging. The
associated activities form the Deployment discipline.
10. Process: Adopt a Process that Fits Your
Project
It is essential that a process be chosen which fits the
type of product you are developing. Even after a
process is chosen, it must not be followed blindly -
common sense and experience must be applied to
configure the process and tools to meet the needs of
the organization and the project. the organization and the project.
Adapting a process for a project is a key part of the
Environment discipline.
Conclusiones
The above "essentials" provide a means of quickly assessing a process and
identifying areas where improvement is most beneficial. It is important to explore what
will happen if any of these essentials is ignored. For example:
No vision? You may lose track of where you are going and may be easily distracted on detours.
No process? Without a common process, the team may have miscommunications and
misunderstandings about who is going to do what - and when.
No plan? You will not be able to track progress.
No risk list? You may be focusing on the wrong issues now and may explode on an
unsuspected mine 5 months from now.
No business case? You risk losing time and money on the project. It may be cancelled or go
bankrupt. bankrupt.
No architecture? You may be unable to handle communication, synchronization, and data
access issues as they arise; there may be problems with scaling and performance.
No product (prototype)? As soon as possible, get a product in front of the customer. Just
accumulating paperwork doesn't assure you or the customer that the product will be successful-
and it maximizes risk of budget and schedule overruns and/or outright failure.
No evaluation? Don't keep your head in the sand. It is important to face the truth. How close are
you really to your deadline? To your goals in quality or budget? Are all issues adequately being
tracked?
No change requests? How do you keep track of requests from your stakeholders? How do you
prioritize them? And keep the lower priority ones from falling through the cracks?
No user support? What happens when a user has a question or can't figure out how to use the
product? How easy is it to get help?
Fases Fases
A Team-Based Definition of Process
A process defines Who is doing What, When, and How, in
order to reach a certain goal.
A Development Process Should:
Define the steps that lead to deliverables and who is responsible for
them.
Help to control the project and reduce confusion.
Help project management to resource, plan, and measure progress.
Reduce risk.
Make software development predictable, repeatable, and Make software development predictable, repeatable, and
measurable.
Not be another process gathering dust.
New or changed
requirements
Software Engineering
Process
New or changed
system
RUP
Contenido
Tiempo
Estructura RUP
Organization along time
Lifecycle structure: phases, iterations
Process enactment: planning, executing
Activity management, project control
Organization based on content
Disciplines, roles, artifacts, activities
Process configuration, process enhancement
Fases del ciclo de vida
From a management perspective, the software lifecycle
of the Rational Unified Process (RUP) is decomposed
over time into four sequential phases, each concluded by
a major milestone; each phase is essentially a span of
time between two major milestones.
At each phase-end an assessment is performed to
determine whether the objectives of the phase have been determine whether the objectives of the phase have been
met.
A satisfactory assessment allows the project to move to
the next phase.
Inception
The overriding goal of the inception phase is to
achieve concurrence among all stakeholders on the
lifecycle objectives for the project.
The inception phase is of significance primarily for
new development efforts, in which there are
significant business and requirements risks which significant business and requirements risks which
must be addressed before the project can proceed.
For projects focused on enhancements to an existing
system, the inception phase is more brief, but is still
focused on ensuring that the project is both worth
doing and possible to do.
Objetivos
Establishing the project's
software scope and
boundary conditions,
including an operational
vision, acceptance criteria
and what is intended to be in
the product and what is not.
Discriminating the critical
use cases of the system, the
primary scenarios of
operation that will drive the
major design tradeoffs.
Exhibiting, and maybe
demonstrating, at least one
candidate architecture
against some of the primary
scenarios
the product and what is not.
Estimating the overall cost
and schedule for the entire
project (and more detailed
estimates for the elaboration
phase)
Estimating potential risks
(the sources of
unpredictability)
Preparing the supporting
environment for the project
Actividades esenciales
Formulating the scope of
the project.
This involves capturing the context
and the most important requirements
and constraints to such an extent
that you can derive acceptance
criteria for the end product.
Planning and preparing a
business case.
Evaluating alternatives for risk
management, staffing, project plan,
and cost/schedule/profitability
tradeoffs.
Synthesizing a candidate
architecture
Evaluating tradeoffs in design, and in
make/buy/reuse, so that cost,
schedule and resources can be
estimated. The aim here is to
demonstrate feasibility through some
kind of proof of concept.
Preparing the environment
for the project,
Assessing the project and the
organization, selecting tools,
deciding which parts of the process
to improve
Lifecycle Objectives Milestone criterios
evaluacin
Stakeholder concurrence on scope
definition and cost/schedule
estimates
Agreement that the right set of
requirements have been captured
and that there is a shared and that there is a shared
understanding of these
requirements.
Agreement that the cost/schedule
estimates, priorities, risks, and
development process are
appropriate.
All risks have been identified and a
mitigation strategy exists for each.
Lifecycle Objectives Milestone estado
artefactos
Essential Artifacts (in
order of importance)
State at milestone
Vision The project's core requirements, key features, and main constraints are
documented.
Business Case Defined and approved.
Risk List Initial project risks identified.
Software Development
Plan
Initial phases, their durations and objectives identified. Resource estimates
(specifically the time, staff, and development environment costs in particular)
in the Software Development Plan must be consistent with the Business
Case. Case.
Iteration Plan Iteration plan for first Elaboration iteration completed and reviewed.
Development Process Adaptations and extensions to the Rational Unified Process, documented and
reviewed. This typically includes project specific guidelines and templates, as
well as a development case for documenting project-specific tailoring
decisions.
Development
Infrastructure
All tools to support the project are selected. The tools necessary for work in
Inception are installed.
In particular, the Configuration Management environment should be set up.
Glossary Important terms defined; glossary reviewed.
Use-Case Model
(Actors, Use Cases)
Important actors and use cases identified and flows of events outlined for
only the most critical use cases.
Elaboration
The goal of the elaboration phase is to baseline the
architecture of the system to provide a stable basis
for the bulk of the design and implementation effort
in the construction phase.
The architecture evolves out of a consideration of
the most significant requirements (those that have a the most significant requirements (those that have a
great impact on the architecture of the system) and
an assessment of risk.
The stability of the architecture is evaluated through
one or more architectural prototypes.
Objetivos
To ensure that the architecture,
requirements and plans are
stable enough, and the risks
sufficiently mitigated to be able to
predictably determine the cost
and schedule for the completion
of the development.
To address all architecturally
significant risks of the project
To establish a baselined
architecture derived from
addressing the architecturally
significant scenarios, which
typically expose the top technical
risks of the project.
To produce an evolutionary
prototype of production-quality
components, as well as possibly
one or more exploratory, throw-
away prototypes to mitigate
specific risks
To demonstrate that the
baselined architecture will
support the requirements of the
system at a reasonable cost and
in a reasonable time.
To establish a supporting
environment.
Actividades esenciales
Defining, validating and
baselining the architecture as
rapidly as practical.
Refining the Vision, based on
new information obtained during
the phase, establishing a solid
understanding of the most critical
use cases that drive the
architectural and planning
decisions.
Creating and baselining detailed
iteration plans for the
construction phase.
Refining the development
process and putting in place the
development environment,
including the process, tools and
automation support required to
support the construction team.
Refining the architecture and
selecting components. Potential
components are evaluated and the
make/buy/reuse decisions
sufficiently understood to determine
the construction phase cost and
schedule with confidence..
Lifecycle Architecture Milestone criterios
de evaluacin
The product Vision and requirements are stable.
The architecture is stable.
The key approaches to be used in test and
evaluation are proven.
Test and evaluation of executable prototypes
have demonstrated that the major risk elements
have been addressed and have been credibly
resolved. resolved.
The iteration plans for the construction phase are
of sufficient detail and fidelity to allow the work to
proceed.
The iteration plans for the construction phase are
supported by credible estimates.
All stakeholders agree that the current vision can
be met if the current plan is executed to develop
the complete system, in the context of the current
architecture.
Actual resource expenditure versus planned
expenditure is acceptable.
Lifecycle Architecture Milestone estado
artefactos
Essential Artifacts (in order of importance) State at milestone
Prototypes
One or more executable architectural prototypes have been created to
explore critical functionality and architecturally significant scenarios. See
the note below on the role of prototyping.
Risk List
Updated and reviewed. New risks are likely to be architectural in nature,
primarily relating to the handling of non-functional requirements.
Development Process
The development process, including any project-specific guidelines and
templates, has been refined based on early project experience, and is
sufficiently defined for the construction phase to proceed.
Development Infrastructure
The development environment for construction is in place, including all
tools and automation support for the process.
Created and baselined, including detailed descriptions for the
Software Architecture Document
Created and baselined, including detailed descriptions for the
architecturally significant use cases (use-case view), identification of key
mechanisms and design elements (logical view), plus definition of the
process view and the deployment view if the system is distributed or
must deal with concurrency issues.
Design Model (and all constituent artifacts)
Defined and baselined. Design use-case realizations for architecturally
significant scenarios have been defined and required behavior has been
allocated to appropriate design elements. Components have been
identified and the make/buy/reuse decisions sufficiently understood to
determine the construction phase cost and schedule with confidence.
The selected architectural components are integrated and assessed
against the primary scenarios.
Data Model
Defined and baselined. Major data model elements (e.g. important
entities, relationships, tables) defined and reviewed.
Lifecycle Architecture Milestone estado
artefactos (II)
Essential Artifacts (in order
of importance)
State at milestone
implementation Model (and all
constituent artifacts, including
Implementation Elements)
Initial structure created and major components prototyped.
Vision
Refined, based on new information obtained during the phase, establishing a solid
understanding of the most critical use cases that drive the architectural and planning
decisions.
Software Development Plan Updated and expanded to cover the Construction and Transition phases.
Iteration Plan Iteration plan for the construction phase completed and reviewed.
A use-case model (approximately 80% complete)-all use cases having been identified
Use-Case Model (Actors, Use
Cases)
A use-case model (approximately 80% complete)-all use cases having been identified
in the use-case model survey, all actors having been identified, and most use-case
descriptions (requirements capture) have been developed.
Supplementary Specifications
Supplementary requirements capturing the non functional requirements are
documented and reviewed.
Test Suite ("smoke test")
Tests implemented and executed to validate the stability of the build for each
executable releases created during the elaboration phase.
Test Automation Architecture
A baselined composition of the various mechanisms and key software elements that
embody the fundamental characteristics of the test automation software system.
Construction
The goal of the construction phase is clarifying the
remaining requirements and completing the
development of the system based upon the
baselined architecture.
The construction phase is in some sense a
manufacturing process, where emphasis is placed manufacturing process, where emphasis is placed
on managing resources and controlling operations to
optimize costs, schedules, and quality.
In this sense the management mindset undergoes a
transition from the development of intellectual
property during inception and elaboration, to the
development of deployable products during
construction and transition.
Objetivos
Minimizing development costs by
optimizing resources and avoiding
unnecessary scrap and rework.
Achieving adequate quality as rapidly
as practical
Achieving useful versions (alpha,
beta, and other test releases) as
rapidly as practical
To iteratively and incrementally
develop a complete product that is
ready to transition to its user
Completing the analysis, design,
development and testing of all
required functionality.
ready to transition to its user
community. This implies describing
the remaining use cases and other
Requirements, fleshing out the
design, completing the
Implementation, and testing the
software.
To decide if the software, the sites,
and the users are all ready for the
application to be deployed.
To achieve some degree of
parallelism in the work of development
teams.
Actividades esenciales
Resource
management, control
and process
optimization
Complete component
development and
testing against the
defined evaluation
criteria
Assessment of
product releases
against acceptance
criteria for the vision.
Initial Operational Capability Milestone
criterios de evaluacin
Is this product release
stable and mature
enough to be deployed in
the user community? the user community?
Are all the stakeholders
ready for the transition
into the user community?
Are actual resource
expenditures versus
planned still acceptable?
Initial Operational Capability Milestone
estado artefactos
Essential Artifacts (in order of importance) State at milestone
"The System" The executable system itself, ready to begin "beta" testing.
Deployment Plan
Initial version developed, reviewed and baselined. On smaller projects,
this may be embedded in the Software Development Plan.
Implementation Model (and all constituent
artifacts, including Implementation Elements)
Expanded from that created during the elaboration phase; all
implementation elements created by the end of the construction phase.
Test Suite ("smoke test")
Tests implemented and executed to validate the stability of the build for
each executable releases created during the construction phase.
User Manuals and other training materials. Preliminary draft, based on
User Support Material
User Manuals and other training materials. Preliminary draft, based on
use cases. May be needed if the system has a strong user interface
aspect.
Iteration Plan Iteration plan for the transition phase completed and reviewed.
Design Model (and all constituent artifacts)
Updated with new design elements identified during the completion of all
requirements.
Development Process
The development process, including the development case and any
project-specific guidelines and templates, has been refined based on
project experience, and is sufficiently defined for the next phase to
proceed.
Development Infrastructure
The development environment for transition is in place, including all tools
and automation support for the process.
Data Model
Updated with all elements needed to support the persistence
implementation (e.g. tables, indexes, object-to-relational mappings, etc.)
Transition
The focus of the Transition Phase is to ensure that
software is available for its users.
The Transition Phase can span several iterations,
and includes testing the product in preparation for
release, and making minor adjustments based on
user feedback. user feedback.
At this point in the lifecycle, user feedback should
focus mainly on fine tuning the product, configuring,
installing and usability issues, all the major structural
issues should have been worked out much earlier in
the project lifecycle.
Objetivos
beta testing to validate the
new system against user
expectations
beta testing and parallel
operation relative to a
legacy system that it's
replacing
converting operational
databases
training of users and
maintainers
deployment-specific
engineering such as tuning activities such as
assessment of the
roll-out to the marketing,
distribution and sales
forces
engineering such as
cutover, commercial
packaging and production,
sales roll-out, field
personnel training
tuning activities such as
bug fixing, enhancement
for performance and
usability
assessment of the
deployment baselines
against the complete
vision and the acceptance
criteria for the product
achieving user self-
supportability
achieving stakeholder
concurrence that
deployment baselines are
complete
achieving stakeholder
concurrence that
deployment baselines are
consistent with the
evaluation criteria of the
vision
Actividades esenciales
executing
deployment plans
finalizing end-
user support
material
testing the
deliverable
product at the
development site
fine-tuning the
creating a
product release
getting user
feedback
fine-tuning the
product based on
feedback
making the
product available
to users
Product Release Milestone criterios de
evaluacin
Is the user
satisfied?
Are actual Are actual
resources
expenditures
versus planned
expenditures
acceptable?
Product Release Milestone estado
artefactos
Essential Artifacts (in
order of importance)
State at milestone
The Product Build
Complete in accordance with the product requirements.
The final product should be useable by the customer.
User Support Material
Materials that assist the end-user in learning, using,
operating and maintaining the product should be complete
in accordance with requirements.
Implementation
Elements
The implementation is complete and baselined, and the
deployable elements have been incorporated in the final
product.
Planeacin de fases
All phases are not identical in terms of schedule and
effort. Although this varies considerably depending
on the project, a typical initial development cycle for
a medium-sized project should anticipate the
following distribution between effort and schedule:
inception elaboration construction transition
Effort ~5 % 20 % 65 % 10%
Schedule 10 % 30 % 50 % 10%
Estrategias de planificacin -
Lifecycle pattern: Incremental
"The incremental strategy determines user needs,
and defines the system requirements, and then
performs the rest of the development in a sequence
of builds. The first build incorporates parts of the
planned capabilities, the next build adds more
capabilities, and so on until the system is complete. capabilities, and so on until the system is complete.
Lifecycle pattern: Incremental (II)
The following iterations are characteristic:
a short Inception iteration to establish scope and vision,
and to define the business case
a single Elaboration iteration, during which requirements
are defined, and the architecture established
several Construction iterations during which the use
cases are realized and the architecture fleshed-out cases are realized and the architecture fleshed-out
several Transition iterations to migrate the product into
the user community
This strategy is appropriate when:
The problem domain is familiar.
Risks are well-understood.
The project team is experienced.
Lifecycle pattern: Evolutionary
"The evolutionary strategy differs from the
incremental in acknowledging that user needs are
not fully understood, and all requirements cannot be
defined up front, they are refined in each successive
build.
Lifecycle pattern: Evolutionary (II)
The following iterations are characteristic:
a short Inception iteration to establish scope and vision,
and to define the business case
several Elaboration iterations, during which requirements
are refined at each iteration
a single Construction iteration, during which the use a single Construction iteration, during which the use
cases are realized and the architecture is expanded
several Transition iterations to migrate the product into
the user community
This strategy is appropriate when:
The problem domain is new or unfamiliar.
The team is inexperienced.
Lifecycle pattern: Incremental Delivery
Some authors have also phased deliveries of
incremental functionality to the customer This may
be required where there are tight time-to-market
pressures, where delivery of certain key features
early can yield significant business benefits.
In terms of the phase-iteration approach, the In terms of the phase-iteration approach, the
transition phase begins early on and has the most
iterations. This strategy requires a very stable
architecture, which is hard to achieve in an initial
development cycle, for an "unprecedented" system.
Lifecycle pattern: Incremental Delivery (II)
The following iterations are characteristic:
a short Inception iteration to establish scope and vision, and to
define the business case
a single Elaboration iteration, during which a stable architecture is
baselined
a single Construction iteration, during which the use cases are
realized and the architecture fleshed-out
several Transition iterations to migrate the product into the user several Transition iterations to migrate the product into the user
community
This strategy is appropriate when:
The problem domain is familiar:
the architecture and requirements can be stabilized early in the
development cycle
there is a low degree of novelty in the problem
The team is experienced.
Incremental releases of functionality have high value to the
customer.
Lifecycle pattern: "Grand Design"
The traditional waterfall approach can be seen as a
degenerated case in which there is only one iteration
in the construction phase. It is called "grand design"
in . In practice, it is hard to avoid additional iterations
in the transition phase.
Lifecycle pattern: "Grand Design (II)
The following iterations are characteristic:
a short Inception iteration to establish scope and vision,
and to define the business case
a single very long Construction iteration, during which the
use cases are realized and the architecture fleshed-out
several Transition iterations to migrate the product into
the user community the user community
This strategy is appropriate when:
a small increment of well-defined functionality is being
added to a very stable product
the new functionality is well-defined and well-understood
The team is experienced, both in the problem domain and
with the existing product