Definicin

Conjunto de actividades, mtodos, prcticas y transformaciones que la gente usa para desarrollar y mantener software y los productos de trabajo asociados (planes de proyecto, diseo de documentos, cdigo, pruebas y manuales de usuario) (SEI, 1995). Proceso o conjunto de procesos usados por una organizacin o proyecto, para planificar, gestionar, ejecutar, monitorizar, controlar y mejorar sus actividades software relacionadas (ISO, 1998). Conjunto coherente de polticas, estructuras organizacionales, tecnologas, procedimientos y artefactos que son necesarios para concebir, desarrollar, empaquetar y mantener un producto software (Fuggeta, 2000).

Procesos de Desarrollo de Software

Prof. Daniel Riesco

Qu es un Proceso
Define Quin est haciendo Qu, Cuando hacerlo, y Cmo alcanzar la meta.
Proceso de Ingeniera de Software

Naturaleza Especial del Proceso de Desarrollo de (Derniame et al., 1999) SW

Es complejo No es un proceso de produccin tpico Tampoco es un proceso de ingeniera pura No es (completamente) un proceso creativo Est basado en descubrimientos que dependen de la comunicacin, coordinacin y cooperacin dentro de marcos de trabajo predefinidos

Nuevos requerimientos o

Sistema nuevo o Sistema cambiado

cambios en requerimientos

Proceso de SW
Proceso software consiste de dos procesos interrelacionados (Derniame et al., 1999): Proceso de Produccin, relacionado con la construccin y mantenimiento del producto software. Proceso de Gestin, que es el encargado de estimar, planificar y controlar los recursos necesarios (personas, tiempo, tecnologa, ...) para poder llevar a cabo y poder controlar el proceso de produccin.

Elementos relacionados con el Proceso de SW

(Fuggetta , 2000)

Tecnologa de Desarrollo Software, soporte tecnolgico, en forma de herramientas, infraestructuras y entornos. Mtodos y Tcnicas de Desarrollo Software, uso de la tecnologa y realizacin de las actividades. Comportamiento Organizacional, relacionado con los recursos humanos. Economa y Marketing, relacionado con la gestin de proyectos, debido a que el producto software final debe cumplir con unos plazos y costes determinados y debe satisfacer las necesidades del cliente al que va destinado.

Proceso

0HMRUDUH O 3URFHVR

Mtodos de Desarrollo de Software RUP (Rational Unified Process)

Jacobson, Booch, Rumbaugh. The Unified Software Development Process, Addison-WesleyLongman.

OPEN
Graham, Henderson-Sellers, HoumanYounessi, The OPEN Process Specification, AddisonWesley.

'HILQLUHOU 3 RFHVR &Q UOU R W R D HO 3URFHVR 0HGLUHO U VR 3 RFH

QuadCycle
QuadCycle: A full life cycle component based development and deployment m ethodology based on Rational Unified Process and Unisys TeamMethod

DMR Macroscope
DMR Consulting, DMR Macroscope, Version 3.1, 2000.

The Fusion Method

Derek Coleman et al., OOD The Fusion Method, Prentice-Hall, 1994.

Dynamic Systems Development Method

Jennifer Stapleton, DSDMDynamic Systems Development Method, Addison-Wesley, 1998

PMBOK
PMBOK Guide. Project Management Institute, http:// www.pmi.org/

Fujitsus System Development Methodology SDAS

Takeshi Oshima, Kashiwagi, Fukao, Fujitsus System Development Methodology: SDAS. http://www.fujitsu.com

(MHFXWDUHO 3URFHVR

MSF Process Model

MSF Process Model, Microsoft Solutions Framework.

Metodologas giles
XP.
Kent Beck. Proyecto de la Chrysler en 1996. Extreme Programming Explained, 1999.

Ejemplo: Metodologa XP
Prcticas XP
Entregas pequeas Metfora Diseo simple Pruebas Refactoring El juego de la planificacin Programacin en parejas Propiedad colectiva Integracin continua Semana de 40 horas Cliente in situ Estndares de programacin

Scrum.
Ken Schwaber & Mike Beedle. Agile Software Development with SCRUM, 2001.

AMDD Crystal Consolidated agile framework

Mtodos Formales
B-Method Clculo de Procesos (CSP, PiCalculus) VDM
VDM-SL VDM++

Mtodos Formales
In Computer Science and Software Engineering, formal methods are mathematically-based techniques for the specification, development and verification of software and hardware systems. R. W. Butler

Z Notation RAISE

What Development Teams Are Facing Today

Project plan templates Book on J2EE JUnit user guide Wiki on agile development Knowledge base on managing iterative development Lessons learnt from previous project and iteration Latest research on effectiveness of pair programming Article on serialized java beans Website with Configuration mgmt guidelines

What Is the Open Unified Process A process framework united by a set of core
principles
Application of an iterative lifecycle that mitigates risk early and often, and shows results early and often Focus on the collaboration within a development team including the product stakeholders to maximize results Management of requirements in a form that represents stakeholder value and drives the development process Cognizance of architecture as a means to increase quality and technical understandability

Corporate guidelines on compliance

No common languageor terminology between processes - redundancy and inconsistencies Knowledge cannot easily be customized for different projects or new best practices No central communityor communication framework to facilitate convergence of best practices across domains

OpenUP consists of
A base process - OpenUP/Basic Extensions to this base process, such as MDA content
http:// epf.eclipse.org/wikis/openupsp/

What Is OpenUP/Basic?
An iterative software development process that is minimal, complete , and extensible. Minimal - only fundamental content is included Complete - can be manifested as an entire process to build a system Extensible - can be used as a foundation on which process content can be added or tailored as needed
Stakeholder

Analyst

Tester

Developer

Project Manager

penUP
Architect

Analyst

Analyst

Stakeholder

Stakeholder

Tester

Tester

Developer

Developer

Project Manager

penUP
Architect

Project Manager

penUP
Architect

Analyst

Analyst

Stakeholder

Stakeholder

Tester

Tester

Developer

Developer

Project Manager

penUP
Architect

Project Manager

penUP
Architect

Analyst

Stakeholder Tester

Roles OpenUP
Developer Project Manager

penUP
Architect

Roles OpenUP

Core Principles: Iterative Lifecycle

Unified Process Lifecycle Inception, Elaboration, Construction, Transition Work item list a list of all things to potentially work on. Work items references use cases and other artifacts for details. Project plan a high-level plan briefly outlining expected resource needs and results from each iteration. Iteration plan Created at the beginning of each iteration team defines what subset of work items to work on. Status Assessment - At end of each iteration, the team assess what works well, and determines how they can improve.

Core Principle: Collaboration

Collaborative practices
Share the dream (Vision, architecture, ) Buddy up (Adjacent programming) Daily team meetings, collocation, customer representative ,

Core Principle: Requirements Management of

requirements in a form that represents stakeholder value and drives the development process Work item list contains a list of all types of requirements Functional requirements are expressed as Use Cases or Scenarios For iteration planning purposes, requirements need to be narrow enough to map to a few days or weeks work

Tasks performed by multiple roles

primary performer + additional performers Some examples
Assess Results (Project Manager + Stakeholders + team) Initiate Iteration (Project Manager + team)
PM could either assign or ask people to volunteer for work

Expecting more community contributions in this area

Core Principle: Architecture

Architecture promotes re-use and maintenance tasks, enhances intellectual control, and avoids technical risks Architecture must not be an afterthought A key differentiator compared to many other agile processes Architectures needs to be grown, start small and grow it

Niveles de Abstraccin

Ciclo de Vida Bsico

Proceso Dirigidos por los Casos de Uso

El proceso est dirigido por casos de uso
nfasis en cmo se utilizar el sistema. Que se supone que el sistema har (para cada usuario). Dirigen el diseo, la implementacin y el testing. Usuario es alguien o algo que interacta con el sistema.

Se debe trabajar sobre los casos de uso claves. Estos representan entre el 5% y 10% del total de CU. Se debe hacer nfasis en lo que el actor (humano o sistema) quiere y necesita.

 Arquitectura incluye los aspectos estticos y dinmicos del sistema, como percibido por los stakeholder y reflejado en los casos de uso. Influenciado por otros factores (plataforma donde ejecutar el SW, frameworks , requerimientos no funcionales) La arquitectura es parte del diseo (solo las mayores abstracciones). Toma decisiones de cmo se construir el sistema. Beneficios:
Una arq. robusta facilita el desarrollo en paralelo Minimiza la repeticin de trabajos Incrementa la probabilidad de reutilizacin. Encapsula la dependencia entre subsistemas. Mejora la extensibilidad.

Proceso Centrado en la Arquitectura

Todo producto tiene funcin y forma. Se deben desarrollar en paralelo.

Relacin entre Arquitectura y Casos de Uso

Los casos de uso dirigen la arquitectura y la arquitectura influencian sobre los casos de uso. Ambos maduran a medida que el ciclo continua. La funcin casos de uso La forma la arquitectura. Ambos deben balancearse. Los casos de uso deben, cuando son realizados, caer dentro de una arquitectura. Por otro lado, la arquitectura debe soportar las realizaciones de todos los casos de uso requeridos (ahora y en el futuro).

Proceso iterativo
El proceso es iterativo propone
una comprensin incremental del problema a travs de refinamientos sucesivos. Un crecimiento incremental de una solucin efectiva a travs de varios ciclos. Dividir el desarrollo en miniproyectos que deben ser controlados. Cada uno es una iteracin.

Beneficios
Circunscribe los errores a una iteracin. Reduce los riesgo de no cumplir con la planificacin. Mejora el esfuerzo de desarrollo. Resultados claros. Los requerimientos del usuario son refinados en cada iteracin. Integracion continua evitar la integracion big bang al final del proyecto en el modelo en cascada.

Cada ciclo concluye con un release. El proceso soporta tcnicas orientadas a objetos (UML). El proceso es configurable para cubrir las

Funcionalidades y Uso

Ciclo de vida iterativo

Si las caractersticas nunca usadas no fuesen implementadas en primer lugar, el tiempo de desarrollo podra ser acortado en cerca de la mitad.

Lifecycle Phases
Inception Elaboration Construction Transition

Fases
Una fase es el intervalo de tiempo entre dos hitos importantes del proceso. Iniciacin: Se planifica y se determina su alcance.
Los criterios de xito. Evaluacin del riesgo. Estimacin de recursos. Planificacin de los principales hitos. Analizar el dominio del problema. Establecer una base arquitectnica slida. Desarrollar el plan del proyecto. Eliminar los elementos de ms alto riesgo del proyecto. Describir la mayora de los requisitos. Ejecutar los casos de uso ms significativos.

time

Inception Define the scope of the project and develop business case Elaboration Plan project, specify features, and baseline the architecture Construction Build the product Transition Transition the product to its users

Elaboracin. Objetivos:

Fases e Iteraciones
Construccin: se desarrolla de forma iterativa e incremental un producto completo. Implica:
Describir los requisitos restantes Los criterios de aceptacin y pruebas del software. Al final de la esta fase se decide si el SW, los lugares donde se instalar y los usuarios estn preparados para funcionar.
Inception

Major Milestones
Elaboration Construction Transition

time

Transicin:
Una vez que el sistema ha sido puesto en manos de los usuarios finales, aparecen los ajustes, corregir problemas no detectados o finalizar algunas caractersticas propuestas. Esta fase comienza con una versin beta.

Vision

Baseline Architecture

Initial Capability

Product Release

Iteraciones:
Es un ciclo completo de desarrollo que produce una versin (interna o externa) de un producto ejecutable.

Phases and Iterations

Inception Elaboration Construction Transition
Prelim Iteration ... Arch Iteration ... Dev Iteration Dev Iteration ... Trans Iteration ...

Iterations and Workflow

Pha se s C ore Wo rkflow s
Requirements An iteratio n in the ela bora ti on p hase Analysis Incep ti on Ela bora tion Con stru cti on Tr ansi ti on

Design Release Release Release Release Release Release Release Release Implementation

An iteration is a sequence of activities with an established plan and evaluation criteria, resulting in an executable release

Test
P re lim i nary I te rat ion (s) it er. #1 it er. #2 it er. #n i te r. # n+ 1 it er. #n +2 i te r. #m it er. #m +1

Ite r a ti o n s

Flujos de Trabajo
Modelado de Negocio: Describe la estructura y la dinmica de la organizacin. Requisitos: el mtodo basado en casos de uso. Anlisis y Diseo: vistas arquitectnicas. Implementacin: desarrollo. Pruebas: casos de prueba, procedimientos y mtricas para evaluacin de defectos. Despliegue: configuracin del sistema a entregar. Gestin de Configuraciones: controla los cambios y mantiene la integridad de los artefactos del proyecto. Gestin del Proyecto: estrategias de trabajo en un proceso iterativo. Entorno: cubre la infraestructura necesaria para el desarrollo del sistema.

Artefactos
Es un documento, informe o ejecutable que se produce, se manipula o se consume. Actividades son las tareas que se llevan a cabo para crear o modificar los artefactos. Los modelos son el tipo de artefacto ms importante del Proceso. Es una simplificacin de la realidad para comprender mejor el sistema que se est creando. Modelos: del negocio, del dominio, de casos de uso, de anlisis, de diseo, del proceso, de despliegue, de implementacin, de pruebas. Una vista es una proyeccin de un modelo. La arquitectura se captura en cinco vistas que interactan entre si: de diseo, de procesos, de despliegue, de implementacin y de casos de uso.

OpenUP - UML
Unified Modeling Language
OMG standard

Workflows and Models

UML diagrams provide views into each model Requirements Use Case Model

Open Unified Process

Eclipse

Analysis

Analysis Model

Design

Design Model

Depl. Model

Implementation

Impl. Model

Test Each workflow is associated with one or more models.

Test Model

Use Case Model Use Case

Diagrams Class Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams
Use Case Model

Analysis & Design Model

Use Case Diagrams Object Diagrams
Use Case Model

Class Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams

Object Diagrams

Analysis Model

Analysis Model

Incl. subsystems and packages

Design Model

Design Model

Depl. Model Impl. Model

Depl. Model Impl. Model

Test Model

Test Model

Deployment and Implementation Model Use Case Diagrams

Use Case Model

Test ModelUse Case

Diagrams Class Diagrams Component Diagrams Deployment Diagrams Test model refers to all other models and uses corresponding diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams Object Diagrams
Use Case Model

Class Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams

Object Diagrams

Analysis Model

Analysis Model

Design Model

Design Model Incl. active classes and components Depl. Model Impl. Model

Depl. Model Impl. Model

Test Model

Test Model

Use Case Driven

Use Cases Drive Iterations

Drive a number of development activities
Impl. Test

Req.ts

Analysis

Design

Use Cases bind these workflows together

Creation and validation of the systems architecture Definition of test cases and procedures Planning of iterations Creation of user documentation Deployment of system

Synchronize the content of different models

Architecture-Centric
Models are vehicles for visualizing, specifying, constructing, and documenting architecture The Unified Process prescribes the successive refinement of an executable Inception Elaboration Construction Transition architecture
time

Architecture and Models

Use Case Model Analysis Model Design Model Depl. Model Impl. Model Test Model

Models

Views

Architecture

Architecture embodies a collection of views of the models

Function versus Form

The Unified Process is Engineered

A role played by an individual or a team

A unit of work

Activity

Use cases

Architecture

Worker
Analyst Describe a Use Case

Use case specify function; architecture specifies form Use cases and architecture must be balanced

responsible for

Artifact
A piece of information that is produced, modified, or used by a process

Use case

Use case package

Desarrollar un incremento de Solucin

The Unified Process is a Process Framework

There is NO Universal Process! The Unified Process is designed for flexibility and extensibility allows a variety of lifecycle strategies selects what artifacts to produce defines activities and workers models concepts

A Better Approach
Standardize representation and manage libraries of reusable Method Content
Content on agile development Content on managing iterative development Guidance on serialized java beans JUnit user guidance Content on J2EE Configuration mgmt guidelines Corporate guidelines on compliance

Eclipse Process Framework (EPF) Project

Process assets patterns Standard or reference processes Project plan templates

Develop and manage Processes for performing projects

Lessons learnt from previous project and iteration

Provide an open and collaborative ecosystem for evolving software development processes Provide sample practices, process tooling and a metamodel, that can be used as the foundation for a large variety of processes to address IT needs Uses the Eclipse community to gain wide acceptance of the framework

Configure a cohesive process framework customized for my project needs

Create project plan templates for Enactment of process in the context of my project

EPF Ecosystem
EXTENSIONS Project Mgmt. Project Mgmt. Oper. Mgmt. Oper. Mgmt. Systems Mgmt. Systems Mgmt. Open Unified Process (OpenUP) OpenUP/ DSDM OpenUP/ Business Rules Other agile processes XP DSDM Scrum AMDD Tool Tool Extensions Commercial Commercial Process Content Content Plug -ins Plug -ins Inhouse Inhouse Content Content Plug -ins Plug -ins Free Process Free Process Content Content Plug -ins Plug -ins

Who Uses EPF?

Requires: - Realistic consistency - Viable governance

Produces: - Base methods - Plug ins

Process Author Management Desires: - Simplicity - Templates - Examples - Guidance Performs: - Tailoring - Publishing - Support - Training

BasicOpenUP BasicUnified Unified Process Process

Adapted from RUP Adapted from RUP

Provides: - Training - Consulting - Mentoring - Adoption services Professional Service Provider Wants to: - Build tools - Sell tools - Sell services Tool Provider

Process Coach

Extensible, Customizable, Flexible Common Language & Vocabulary Open Source Development

TOOLING (Authoring, Publishing) TOOLING (Authoring, Publishing)

META MODEL (Unified Method Architecture) ECLIPSE

Needs: - Teachable material - Teach process development - Use in student projects - Bring research to mainstream Academia

SPEM 2
SPEM permite definir procesos de desarrollo de software. Est limitado a definir los elementos mnimos de cualquier proceso de desarrollo de software sin indicar aspectos especficos de dominios particulares (por ej. gestin de proyectos). El objetivo es permitir definir un amplio rango de mtodos y procesos con distintos estilos, niveles de formalismos, modelos de ciclos de vida.

Unified Process Structure

Phases Process Workflows
Business Modeling Requirements Analysis & Design Implementation Test Deployment
Inception Elaboration Construction Transition

Supporting Workflows
Configuration Mgmt Management Environment
Preliminary Iter. Iteration(s) #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iter. #m Iter. #m+1

Iterations

Cada Disiplina Contribuye a un conjunto de Modelos

Modelos y Workflows
Each major workflow describes how to create and maintain a particular model Business Modeling
Business Model

Requirements Workflow Analysis Design Workflow

Use-Case Model

realized by

implemented by Design Model

Implementation Workflow Test Workflow

Implementation Model

verified by

Test Model

Framework

De la Visin a los Requerimientos

Trabajo a Realizar Resultado
Listar los Lista de Requerimientos Caractersticas Candidatos Entender el Modelo del Contexto del Dominio / Negocio Sistema Capturar los Modelo de Caso Requerimientos de Uso Funcionales Capturar los Requerimientos Requerimientos No Suplementarios o Funcionales Casos de Uso

Relacin entre el Negocio y el Sistema

Modelo de Negocio
El modelo de negocio establece una abstraccin de la organizacin y permite comprender los procesos de negocio de la organizacin
Entender la estructura y dinmica de la organizaci n. Entender los problemas corrientes e identificar potenciales o posibles mejoras. Asegurar a los clientes, usuarios y desarrolladores que tienen una comprensi n comn de la organizaci n. Derivar los requerimientos del sistema necesarios para soportar la estructura y dinmica de la organizaci n

Proceso de Negocio
Un proceso de negocio es el conjunto completo de actividades necesarias para producir un resultado de valor medible y perceptible a un cliente individual de un negocio. Se formaliza el flujo de control de estas actividades, para hacer ms clara la comprensin de stos, mediante el uso de diagramas de actividades de UML o de BPMN.

Modelo de Negocio: Empresa Agro-ganadera

Modelado de Negocio: Notacin

BPMN: Business Process Modeling Notation. Objetivos: Proveer una notacin entendible para cualquiera desde el analista del negocio, el desarrollador tcnico y hasta la gente propia del negocio. Crear un puente estandarizado entre el diseo de procesos de negocio y su implementacin. Asegurar que los lenguajes para la ejecucin de procesos de negocio puedan ser visualizados con una notacin comn.

Modelado de Negocio: BPMN

Define la notacin y semntica de un BPD (Business Process Diagram ) Provee la capacidad de entender los procedimientos internos en una notacin grafica y da a las organizaciones la habilidad de comunicarlos de una manera estndar. Mejora las capacidades de las notaciones de proceso de negocio tradicionales para manejar inherentemente los conceptos de procesos de negocio B2B.

BPMN: Diagrama de Procesos de Negocio

Es un diagrama diseado para ser usado por las personas que disean y administran procesos de negocio. Las cuatro categoras bsicas de elementos que se pueden encontrar en un Diagrama de Procesos de Negocio son: Objetos de flujo Objetos de conexin Swimlanes Artefactos

BPMN: Proceso de Negocio

Modelo de Negocio: Empresa Agro-ganadera

Lane Lane Lane Personal Cliente Profesional

class Business Process Model

Proceso de Negocio: Reservar Turnos Asesoramiento

Registrado? NO Verifica si es registrado sobre tipo de Ganadero Pide datos Personales Registra Cliente

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered TrialSVersion EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version I Solicita Informacin InformaAgrcola
Asesoramiento EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version cliente

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version
No Reserva Informa EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version Contacta 6.5elUnregistered Trial Version EA 6.5 Unregistered Trial Version Solicita EA con Analiza Horarios Asesoramiento Profesional Adecuado

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version Entrega Datos
Solicitados

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version
Reserva Registra Turno EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version Informa6.5 Unregistered Trial Solicita Datos del 6.5 Unregistered Trial Version EA Horarios Version EA Disponibles Asesoramiento

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version

Las reglas de negocio son declaraciones de

polticas o condiciones que se deberan satisfacer o cmo el negocio debera operar.

Reglas de Negocio

Relacin entre el Negocio y el Sistema

class Business Process Model

Ellas pueden ser leyes y regulaciones impuestas por el negocio, pero tambin expresan la eleccin de una arquitectura del negocio y un estilo. Ellas pueden expresarse en un leguaje natural, semiformal o formal
1- IF un profesional no puede realizar un asesoramiento reservado THEN se le comunicar al cliente y se acordar un nuevo horario. 2- WHEN se vence el plazo de reserva de productos IF el producto no fue retirado THEN se rectifica el estado de la reserva. 3- IT MUST ALWAYS HOLD THAT no se deben superponer los horarios de los turnos de asesoramientos

EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version Registrado? EA
O N Personal C l i e n t e Profesional

EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version
InformaAgrcola Ganadero

S Solicita Informacin I sobre tipo de

EA 6.5 Unregisterede s cliente V e r i f i c a s i Trial Version d e P EA 6.5 Unregistered Trial Version i o s d a t Registra EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA

EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version
NoReserva

EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version Asesoramiento Solicita EA EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA

Profesional Contactaconel

EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version EntregaDatos EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version

EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA

EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version

Informa

EA6.5UnregisteredTrialSolicitaDatosdelEA 6.5 Unregistered Trial Version Horarios Reserva Version RegistraTurno EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version

EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA EA 6.5 Unregistered Trial Version 6.5 Unregistered Trial Version EA

EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version EA6.5UnregisteredTrialVersionEA 6.5 Unregistered Trial Version

Correspondencia CU del Negocio con CU del Sistema

como CU. Los CU especifican una secuencia de acciones, incluyendo variantes, que el sistema debe ejecutar produciendo un resultado de valor observable a un actor particular. Los CU permiten llegar a un acuerdo entre los desarrolladores y los clientes respecto de los requerimientos (condiciones y capacidades). Actores corresponden a trabajadores o actores del negocio en el marco de un proceso de negocio. Cada manera en que el actor usa al sistema es representado como un Caso de Uso. Se utilizan otros diagramas para dar mayor precisin (Diagrama de Estados, Actividades, Secuencia). Una instancia de un caso de uso es una ejecucin.

Captura de Requerimientos como Casos de Uso Los requerimientos funcionales son estructurados

Resumiendo ...
Concepto de Proceso de Desarrollo de SW Proceso Unificado: Framework
Dirigido por Casos de Uso Iterativo e Incremental Centrado en la Arquitectura

Modelado de Negocio
Casos de Uso del Negocio (Diagrama de CU) Procesos de Negocio (BPMN)

Requerimientos derivados del Modelo del Negocio

Mapping (<<trace>>) entre los casos de uso del negocio y los casos de uso del sistema.