AD1 2013 RUP PracticasPrincipiosFases

8/13/2019 AD1 2013 RUP PracticasPrincipiosFases

1/62

Introduccin a RUP

Prcticas, principios y fases

USAC - Anlisis y diseo de sistemas 1

Segundo semestre 2013


2/62

Qu es RUP? There are three central elements that define RUP:

An underlying set of philosophies and principles for

successful software development. These philosophies andprinciples are the foundation on which the RUP has been

developed.

A framework of reusable method content and process

u ng oc s. e ne an mprove on an ongo ng as sby 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.


3/62

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 longafter the initial project has ended. However, the way in which RUP isused needs to be varied appropriately to suit your needs. There are afew considerations that will determine when and how you will usedifferent parts of RUP: project lifecycle (number of iterations, length of each phase, project

length)

, ,

size of the Software Development Effort


4/62

Prcticas


5/62

Prcticas The Rational Unified Process six tried-and-true best practices

have been the basis for the evolution of our Rational's toolsand processes for more than a decade.

Today, as software development is becoming a key businesscapability, our best practices are maturing within the largercontext of business-driven development.

The following principles re-articulate our best practices for the,

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


6/62

Adaptar el proceso This principle states that it is critical to right-size the

development process to the needs of the project. More is notbetter, less is not better: Instead, the amount of ceremony,

precision, and control present in a project must be tailoredaccording to a variety of factors including the size anddistribution of teams, the amount of externally imposedconstraints, and the phase the project is in


7/62

Adaptar el proceso (II) We need to right-size the process to project needs. As a

project grows in size, becomes more distributed, uses morecomplex technology, has larger number of stakeholders, and

needs to adhere to more stringent compliance standards, theprocess needs to become more disciplined

A project should adapt process ceremony to lifecycle phase. Inthe beginning of the project on the one hand, we are usuallyfaced with a lot of uncertaint and we must stron l

encourage creativity to develop an application that addressesbusiness needs. More process typically leads to less creativity,not more; we must therefore minimize process in the earlystages 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, toprevent undesired creativity and associated risk, which oftenleads to the late introduction of defects into the product: Thistranslates to more process.


8/62

Adaptar el proceso (III) An organization should strive to continuously

improve the process. Consider performing an

assessment after each iteration and at project end tocapture lessons learned, and leverage that

knowledge to improve the process.

na y, s cr ca o a ance pro ec p ans anassociated 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 andestimates, rather than aiming at providing high levels

of precision when there is in fact none.


9/62

Balancear prioridades en competencia de

los stakeholders This principle articulates the importance of balancing often conflicting

business and stakeholder needs, as well as balancing customdevelopment versus asset reuse in the satisfaction of these needs.

Rather than sending programming teams out to attack each elementin a requirements list, we need to understand and prioritize businessand stakeholder needs. This means capturing business processesand linking them to projects and software capabilities, which enablesus to effectively prioritize projects and requirements, and to modify

and stakeholder needs evolve. It also means that we need to involvethe customer or customer representative in the project to ensure weunderstand what their needs are.

At the same time, we need to center development activities aroundstakeholder needs. For example, by leveraging use-case driven

development and user-centered design, our development processcan accommodate the evolution of stakeholder needs over thecourse of the project, as a function of changing business and of ourimproved understanding of the capabilities that are truly important tothe business and the end users.


10/62

Colaborar a lo largo de equipos This principle stresses the importance of fostering optimal project-

wide communication. This is achieved through proper teamorganization and the setting up of effective collaborativeenvironments

Software is produced by talented and motivated people collaboratingclosely. Many complex systems require the collaboration of a numberof stakeholders with varying skills, and the largest projects oftenspan geographical and temporal boundaries, further adding

.

and collaboration -- what some have referred to as the "soft" elementof software development -- have been a primary focus in the agiledevelopment community . Following this principle requiresanswering many questions, including: How do we motivate people to perform at their best?

How do we collaborate within a co-located versus a distributed softwareteam?

How do we collaborate across teams responsible for the business,software development, and IT operations?


11/62

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 obtainfeedback and factor it into the project, to reduce risk

early, and to adjust the process dynamically.

.

The first one is that we must deliver incremental value toenable 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.


12/62

Demostrar valor iterativamente (II) The second imperative is to leverage demonstrations and

feedback to adapt our plans. Rather than relying onassessing specifications, such as requirementsspecifications, design models, or plans, we need insteadto assess how well the code developed thus far actuallyworks. This means that me must use test results and

determine how well we are doing. The third underlying imperative is to embrace and

manage change. Today's applications are too complex forthe requirements, design, implementation, and test to

align perfectly the first time through. Instead, the mosteffective application development methods embrace theinevitability of change.


13/62

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.


14/62

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 ofdocumentation required by the project. This can be achieved throughreuse, 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 onproductivity. Working at a higher level of abstraction reduces

.

One effective approach to reducing complexity is reusing existingassets, such as reusable components, legacy systems, existingbusiness processes, patterns, or open source software. Two greatexamples of reuse that have had a major impact on the softwareindustry 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 componentsthat can be leveraged.


15/62

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 sinceit offers many measurement and correction opportunities.

Improving quality is not simply "meeting requirements," or producing a product thatmeets user needs and expectations. Rather, quality also includes identifying themeasures and criteria that demonstrate its achievement, as well as theimplementation of a process to ensure that the product has achieved the desireddegree of quality, and that this can be repeated and managed.

Ensuring high quality requires more than the participation of the testing team; itrequires that the entire team owns quality. It involves all team members and all parts

Analysts are responsible for making sure that requirements are testable, and that we specifyclear requirements for the tests to be performed.

Developers need to design applications with testing in mind, and must be responsible fortesting their code.

Managers needs to ensure that the right test plans are in place, and that the right resourcesare in place for building the testware and performing required tests.

Testers are the quality experts. They guide the rest of the team in understanding softwarequality issues, and they are responsible all product testing (including functional, system, andperformance).


16/62

Princi ios


17/62

1. Vision: Develop a Vision In particular, developing a clear Vision is key to developing a

product that meets your stakeholders'realneeds".

In RUP, the Vision artifact captures very high-levelrequirements and design constraints, to give the reader anunderstanding of the system to be developed. It provides inputto the project-approval process, and is therefore intimatelyrelated to the Business Case. It communicates the

fundamental "why and what related to the project and is agauge 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, understandingstakeholder needs, defining the system, and managing therequirements as they change.


18/62

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 andcontrolling the project; planning for and evaluating each iteration andphase - these are the "essence" of the Project Managementdiscipline.

A Software Development Plan gathers the information required tomanage the project. It is used to plan the project schedule andresource needs, and to track progress against the schedule. It

, , ,

and resources. It may also include plans for requirementsmanagement, configuration management, problem resolution, qualityassurance, evaluation and test, and product acceptance.

The format of the planning artifacts are not as important as theplanning 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 iseverything."


19/62

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 tocapture the perceived risks to the success of the

project. It identifies, in decreasing order of priority,

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 whichiterations are organized.


20/62

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 worthinvesting in.

The main purpose of the Business Case is to develop an economicplan for realizing the project Vision. Once developed, the BusinessCase is used to make an accurate assessment of the return oninvestment (ROI) provided by the project. It provides the justificationfor the project and establishes its economic constraints. It provides

' ,

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 theproduct is needed. It must be brief, however, so that it is easyenough for all project team members to understand and remember.

At critical milestones, the Business Case is re-examined to see ifestimates of expected return and cost are still accurate, and whetherthe project should be continued


21/62

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 significantcomponents interacting through interfaces, with components composed ofsuccessively smaller components and interfaces. What are the main pieces?

And how do they fit together? Do we have a framework on which the rest ofthe software can be added?

To speak and reason about software architecture, you must first define anarchitectural representation, a way of describing important aspects of anarchitecture. This description is captured in the Software Architecture

, .

Each architectural view addresses some specific set of concerns, specific tostakeholders in the development process: users, designers, managers,system engineers, maintainers, and so on. This serves as a communicationmedium between the software architect and other project team membersregarding architecturally significant decisions which have been made on theproject.

Defining a candidate architecture, refining the architecture, analyzingbehavior, and designing components of the system is the "essence" of the

Analysis and Design discipline, and the principle Elevate Level ofAbstraction.


22/62

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 andissues as early as possible.

Incrementally building and testing the components of

e sys em s e essence o eImplementation and Test disciplines, and

the principle Demonstrate Value Iteratively.


23/62

7. Evaluation: Regularly Assess Results Continuous open communication with objective data derived directly from

ongoing activities, and the evolving product configurations are important inany project. Regular status assessments provide a mechanism foraddressing, communicating, and resolving management issues, technical

issues, and project risks. In addition to identifying the issues, each shouldbe assigned a due date, with a responsible person who is accountable forthe 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

progress. The Iteration Assessment captures the results of an iteration, the degree to

which the evaluation criteria were met, the lessons learned and processchanges 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 outcomesto 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."


24/62

8. Change Requests: Manage and Control

Changes As soon as the first prototype is put before the users (and often even before

that), changes willbe requested. (One of those certainties of life!) In order tocontrol those changes and effectively manage the scope of the project andexpectations of the stakeholders, it is important that all changes to any

development artifacts be proposed through Change Requests and managedwith a consistent process.

Change Requests are used to document and track defects, enhancementrequests and any other type of request for a change to the product. Thebenefit of Change Requests is that they provide a record of decisions, and,

,

change are understood by all project team members. The Change Requestsare essential for managing the scope of the project, as well as assessing theimpact of proposed changes.

Manage and controlling the scope of the project, as changes occurthroughout the project lifecycle, while maintaining the goal of considering allstakeholder needs and meeting those, to whatever extent possible - this is

the "essence" of the Configuration and Change Management discipline, andthe Supporting Material: Control Changes.


25/62

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 istypically more than just the software. At a minimum,

there should be a User's Guide, perhaps

.

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. Theassociated activities form the Deployment discipline.


26/62

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

.

Adapting a process for a project is a key part of the

Environment discipline.


27/62

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 whatwill 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 anunsuspected mine 5 months from now.

No business case? You risk losing time and money on the project. It may be cancelled or go.

No architecture? You may be unable to handle communication, synchronization, and dataaccess 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. Justaccumulating 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 areyou really to your deadline? To your goals in quality or budget? Are all issues adequately beingtracked?

No change requests? How do you keep track of requests from your stakeholders? How do youprioritize 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 theproduct? How easy is it to get help?


28/62

Fases


29/62

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 forthem. Help to control the project and reduce confusion. Help project management to resource, plan, and measure progress. Reduce risk. a e so ware eve opmen pre c a e, repea a e, an

measurable. Not be another process gathering dust.

New or changed

requirements

Software Engineering

Process

New or changed

system


30/62

RUP

Contenido

Tiempo


31/62

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


32/62

Fases del ciclo de vida From a management perspective, the software lifecycle

of the Rational Unified Process (RUP) is decomposedover time into four sequential phases, each concluded by

a major milestone; each phase is essentially a span oftime between two major milestones.

At each phase-end an assessment is performed to

met. A satisfactory assessment allows the project to move to

the next phase.


33/62

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

s gn can us ness an requ remen s r s s w c

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 worthdoing and possible to do.


34/62

Objetivos

Establishing the project's

software scope andboundary conditions,

including an operationalvision, acceptance criteria

and what is intended to be inthe roduct and what is not.

Discriminating the criticaluse cases of the system, the

primary scenarios ofoperation that will drive the

major design tradeoffs.

Exhibiting, and maybedemonstrating, at least one

candidate architectureagainst some of the primary

scenarios

Estimating the overall costand schedule for the entireproject (and more detailed

estimates for the elaborationphase)

Estimating potential risks(the sources ofunpredictability)

Preparing the supportingenvironment for the project


35/62

Actividades esencialesFormulating the scope ofthe project.

This involves capturing the contextand the most important requirements

and constraints to such an extentthat you can derive acceptancecriteria for the end product.

Planning and preparing abusiness case.

Evaluating alternatives for riskmanagement, staffing, project plan,

and cost/schedule/profitabilitytradeoffs.

Synthesizing a candidatearchitecture

Evaluating tradeoffs in design, and inmake/buy/reuse, so that cost,schedule and resources can beestimated. The aim here is todemonstrate feasibility through somekind of proof of concept.

Preparing the environmentfor the project,

Assessing the project and theorganization, selecting tools,deciding which parts of the processto improve


36/62

Lifecycle Objectives Milestone criterios

evaluacin

Stakeholder concurrence on scope

definition and cost/scheduleestimates

Agreement that the right set of requirements have been captured

understanding of theserequirements.

Agreement that the cost/scheduleestimates, priorities, risks, anddevelopment process are

appropriate. All risks have been identified and amitigation strategy exists for each.


37/62

Lifecycle Objectives Milestone estado

artefactosEssential 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.

Iteration Plan Iteration plan for first Elaboration iteration completed and reviewed.

Development Process Adaptations and extensions to the Rational Unified Process, documented andreviewed. 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.


38/62

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 effortin the construction phase.

The architecture evolves out of a consideration of

e mos s gn can requ remen s ose a ave 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.


39/62

Objetivos

To ensure that the architecture,

requirements and plans arestable enough, and the risks

sufficiently mitigated to be able topredictably determine the cost

and schedule for the completionof the development.

To address all architecturallysignificant risks of the project

To establish a baselinedarchitecture derived fromaddressing the architecturallysignificant scenarios, which

typically expose the top technicalrisks of the project.

To produce an evolutionaryprototype of production-quality

components, as well as possiblyone or more exploratory, throw-

away prototypes to mitigatespecific risks

To demonstrate that thebaselined architecture will

support the requirements of thesystem at a reasonable cost and

in a reasonable time.

To establish a supportingenvironment.


40/62

Actividades esenciales

Defining, validating andbaselining the architecture as

rapidly as practical.

Refining the Vision, based on

new information obtained duringthe phase, establishing a solidunderstanding of the most critical

use cases that drive thearchitectural and planning

decisions.

Creating and baselining detailediteration plans for theconstruction phase.

Refining the developmentprocess and putting in place the

development environment,including the process, tools andautomation support required to

support the construction team.

Refining the architecture andselecting components. Potentialcomponents are evaluated and the

make/buy/reuse decisionssufficiently understood to determine

the construction phase cost and

schedule with confidence..

if l hi il i i


41/62

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 andevaluation are proven.

Test and evaluation of executable prototypeshave demonstrated that the major risk elementshave been addressed and have been crediblyresolved.

The iteration plans for the construction phase are

of sufficient detail and fidelity to allow the work toproceed.

The iteration plans for the construction phase aresupported by credible estimates.

All stakeholders agree that the current vision canbe met if the current plan is executed to develop

the complete system, in the context of the currentarchitecture.

Actual resource expenditure versus plannedexpenditure is acceptable.

Lif l A hit t Mil t t d


42/62

Lifecycle Architecture Milestone estado

artefactosEssential 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 ListUpdated 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 InfrastructureThe development environment for construction is in place, including all

tools and automation support for the process.

Software Architecture Document

rea e an ase ne , nc u ng e a e escr p ons or e

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 ModelDefined and baselined. Major data model elements (e.g. important

entities, relationships, tables) defined and reviewed.

Lif l A hit t Mil t t d


43/62

Lifecycle Architecture Milestone estado

artefactos (II)Essential Artifacts (in orderof 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 solidunderstanding 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.

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 SpecificationsSupplementary 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.


44/62

Construction The goal of the construction phase is clarifying the

remaining requirements and completing thedevelopment of the system based upon the

baselined architecture.

The construction phase is in some sense amanufacturin rocess where em hasis is laced

on managing resources and controlling operations tooptimize costs, schedules, and quality.

In this sense the management mindset undergoes atransition from the development of intellectual

property during inception and elaboration, to thedevelopment of deployable products duringconstruction and transition.


45/62

Objetivos

Minimizing development costs byoptimizing resources and avoiding

unnecessary scrap and rework.

Achieving adequate quality as rapidlyas practical

Achieving useful versions (alpha,beta, and other test releases) as

rapidly as practical

To iteratively and incrementallydevelop a complete product that is

read to transition to its userCompleting the analysis, design,

development and testing of allrequired functionality.

community. This implies describingthe remaining use cases and other

Requirements, fleshing out thedesign, completing the

Implementation, and testing thesoftware.

To decide if the software, the sites,and the users are all ready for the

application to be deployed.

To achieve some degree ofparallelism in the work of development

teams.


46/62

Actividades esencialesResource

management, control

and processoptimization

Complete componentdevelopment andtesting against the

defined evaluationcriteria

Assessment of

product releasesagainst acceptancecriteria for the vision.

Initial Operational Capability Milestone


47/62


criterios de evaluacin

Is this product releasestable and matureenough to be deployed inthe user communit ?

Are all the stakeholdersready for the transitioninto the user community?

Are actual resource

expenditures versusplanned still acceptable?



48/62


estado artefactosEssential Artifacts (in order of importance) State at milestone

"The System" The executable system itself, ready to begin "beta" testing.

Deployment PlanInitial version developed, reviewed and baselined. On smaller projects,

this may be embedded in the Software Development Plan.

Implementation Model (and all constituentartifacts, including Implementation Elements)

Expanded from that created during the elaboration phase; allimplementation 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 Support Material

. ,

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 InfrastructureThe development environment for transition is in place, including all tools

and automation support for the process.

Data ModelUpdated with all elements needed to support the persistence

implementation (e.g. tables, indexes, object-to-relational mappings, etc.)


49/62

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 ee ac .

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 inthe project lifecycle.


50/62

Objetivos

beta testing to validate thenew system against user

expectations

beta testing and paralleloperation relative to a

legacy system that it'sreplacing

converting operational

databases

training of users and

maintainers

deployment-specificassessment of the

roll-out to the marketing,distribution and sales

forces

cutover, commercial

packaging and production,sales roll-out, fieldpersonnel training

bug fixing, enhancement

for performance andusability

deployment baselinesagainst the complete

vision and the acceptancecriteria for the product

achieving user self-

supportability

achieving stakeholderconcurrence that

deployment baselines arecomplete

achieving stakeholderconcurrence that

deployment baselines are

consistent with theevaluation criteria of thevision


51/62

Actividades esencialesexecuting

deployment plans

finalizing end-user support

material

testing thedeliverable

product at thedevelopment site

creating a

product release

getting user

feedback

-product based on

feedback

making theproduct available

to users

Product Release Milestone criterios de


52/62

Product Release Milestone criterios de

evaluacin

Is the user satisfied?

Are actual

resourcesexpendituresversus planned

expendituresacceptable?

Product Release Milestone estado


53/62

Product Release Milestone estado

artefactosEssential 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 thedeployable elements have been incorporated in the final

product.


54/62

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 -


55/62

g p

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

, .


56/62

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 requirementsare defined, and the architecture established

several Construction iterations during which the usecases are rea ze an t e arc tecture es e -out

several Transition iterations to migrate the product intothe user community

This strategy is appropriate when:

The problem domain is familiar. Risks are well-understood.

The project team is experienced.


57/62

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.


58/62

Lifecycle pattern: Evolutionary (II)

The following iterations are characteristic:

a short Inception iteration to establish scope and vision,


several Elaboration iterations, during which requirements

are refined at each iteration

,

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.


59/62

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.

n erms o e p ase- era on approac , e

transition phase begins early on and has the mostiterations. This strategy requires a very stable

architecture, which is hard to achieve in an initial

development cycle, for an "unprecedented" system.


60/62

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 mi rate the roduct into the usercommunity

This strategy is appropriate when: The problem domain is familiar:

the architecture and requirements can be stabilized early in thedevelopment cycle

there is a low degree of novelty in the problem

The team is experienced.

Incremental releases of functionality have high value to thecustomer.


61/62

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.

Lif l "G d D i (II)


62/62

Lifecycle pattern: "Grand Design (II)

The following iterations are characteristic: a short Inception iteration to establish scope and vision,


a single very long Construction iteration, during which theuse cases are realized and the architecture fleshed-out

several Transition iterations to migrate the product intot e user commun ty

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 andwith the existing product

Documents

AD1 2013 RUP PracticasPrincipiosFases