ESCUELA:

PONENTE:

BIMESTRE:

SISTEMAS II

CICLO:

CIENCIAS DE LA COMPUTACIÓN

I BIMESTRE

Ing. Fausto Loja

ABRIL – AGOSTO 2007

Proceso Unificado de Desarrollo

Características del RUP

Problemática de Captura de requisitos

Captura de requisitos como casos de Uso

Un proceso de desarrollo es un conjunto de actividades necesarias para transformar un requisito de un usuario en software.

Requisitos nuevos

o modificados

Sistema nuevo

o modificadoProceso de Desarrollo

de Software

En general Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.

• Pruebas funcionales• Pruebas de desempeño• Gestión de requisitos• Gestión de cambios y

configuración• Ingeniería de Negocio• Ingeniería de datos• Diseño de interfaces

Rational Unified Process1998

Rational Objectory Process1996-1997

Objectory Process1987-1995

Enfoque Ericsson

UML

Dirigido por casos de uso Centrado en la arquitectura Iterativo e Incremental Desarrollo basado en componentes

RequisitosCapturar, definir y validar los casos de uso

Realizar los casos de uso

Verificar que se satisfacen los casos de uso

Implementación

Pruebas

Casos de Usointegran eltrabajo

Análisis & Diseño

Caso de Uso Realización de Análisis Realización de Diseño

Caso de Prueba

X

«trace» «trace»

«trace»«trace»

Pruebas Funcionales

PruebasUnitarias

Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteración

Análisis

Diseño

Codific.

Pruebas eIntegración

n veces

Cada iteración comprende: Planificar la iteración (estudio de riesgos) Análisis de los Casos de Uso y escenarios Diseño de opciones arquitectónicas Codificación y pruebas. La integración del nuevo

código con el existente de iteraciones anteriores se hace gradualmente durante la construcción

Evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos)

Preparación de la entrega (documentación e instalación del prototipo)

Modelo Cascada

La arquitectura, nos da la visión general del sistema. Define la solución global. Abarca lo siguiente:

Organización del sistema de software Elementos de estructura, interfaces.

Uso, funcionalidad, rendimiento, flexibilidad, reutilización.

Architecture

Inception Elaboration Construction Transition

Conexi ﾗn ExternaRed Local

IIS

Estaciones de trabajo

SQLEXPRESSEstaciones de trabajo

FK_EST_REG__REFERENCE_NOM BRESD FK_EST_REG__REFERENCE_UBICACIOFK_EST_REG__REFERENCE_ACTORESIFK_EST_REG__REFERENCE_TIPODOCU

FK_EST_INDI_REFERENCE_EST_ESTA

FK_EST_ESTA_REFERENCE_EST_OBJE

FK_EST_OBJE_REFERENCE_EST_SUBC

FK_EST_SUBC_REFERENCE_EST_CRIT

FK_EST_CRIT_REFERENCE_EST_PROG

FK_EST_ESCA_REFERENCE_EST_PROG

FK_EST_VERS_REFERENCE_EST_REG_

FK_EST_REF__REFERENCE_EST_INDI

FK_EST_REF__REFERENCE_EST_REG_

FK_EST_PROG_REFERENCE_EST_INST

EST_INSTITUCION

INS_ID

INS_NOM BREINS_M ODALIDADINS_LENGUAJE

integer

characte r(30)cha racte r(30)i nteger

<pk>

EST_PROGRAM AS

PRO_IDINS_IDPRO_NOM BRE

PRO_TIPOUS_IDPRO_FECHA

integeri ntege rcharacte r(50)

i ntege ri ntege rdatetim e

<pk><fk>

EST_ESCALA

ESC_IDPRO_ID

ESC_NUM EROESC_PORCENTAJEESC_TEXTO

integeri nteger

i ntegeri ntegeri nteger

<pk><fk>

ActoresIn fo rm an tes

IdActo r

Nom breActor

i ntege r

characte r(20)

<pk>

Ub icaciones

idUb icacionNom breUb icacion

in tegercharacter(20 )

<pk>

EST_CRITERIOS

CRI_ID

PRO_IDCRI_CODIGOCRI_NOM BRE

CRI_PONDERACIONCRI_INTRODUCCION

in teger

in tege rcharacter(1 )cha racter(50)

in tege rcharacter(300)

<pk>

<fk>

EST_SUBCRITERIOS

SUB_ID

CRI_IDSUB_CODIGOSUB_NOM BRE

SUB_PONDERACION

in teger

in tege rcharacter(3 )cha racter(50)

in tege r

<pk>

<fk>

EST_OBJETIVOS

OBJ_IDSUB_ID

OBJ_CODIGOOBJ_NOM BRE

integeri nteger

characte r(5 )cha racte r(50)

<pk><fk>

EST_ESTANDARES

EST_IDOBJ_ ID

EST_CODIGOEST_NOM BREEST_PONDERACION

EST_VALORACIONEST_SUGERENCIASEST_COM ENTARIOS

US_ID

in tegerin tege r

character(7 )cha racter(50)in tege r

in tege rcharacter(300)character(300)

in tege r

<pk><fk>

EST_INDICADORES

IND_IDEST_IDIND_NUM ERAL

IND_DETALLEUS_ID

integeri ntege ri ntege r

characte r(300)i ntege r

<pk><fk>

EST_REG_DOCUM ENTOS

REG_ID

DOC_IDUBI_IDACT_IDTDC_ID

REG_CODIGO_DOC

in teger

in tegerin tegerin tegerin teger

characte r(10 )

<pk>

<fk1><fk2><fk3><fk4>

Nom bresDoc

idNom breDoc

nom breDoc

integer

characte r(20)

<pk>

TipoDocum ento

idTipoDocum entodescripcionTipoDocum ento

integercharacter(20)

<pk>

EST_VERSIONES

VER_IDREG_ID

VER_DETALLEVER_REFERENCIA_DOCVER_DESCRIPCION_DOC

VER_PATH_DOCVER_FECHAVER_NOM BRE_DOC

US_ID

in tegerin tege r

character(10 )character(25 )character(50 )

character(50 )date tim echaracter(50 )

in tege r

<pk><fk>

EST_REF_DOCUM ENTOS

REF_ID

IND_IDREG_ID

integer

integerinteger

<pk>

<fk1><fk2>

Establecer oportunidad y alcance del proyecto Encontrar los casos de uso críticos del sistema,

describir en detalle algunos de ellos Definir una arquitectura candidata para los

escenarios principales Estimar el costo en recursos y tiempo de todo el

proyecto Definir los criterios de éxito Identificar los riesgos.

Analizar el dominio del problema Establecer una arquitectura de base sólida Desarrollar un plan del proyecto Eliminar los elementos de mayor riesgo para el

desarrollo exitoso.

Minimizar los costos de desarrollo mediante la optimización de recursos y evitando rehacer trabajos.

Conseguir una calidad adecuada tan rápido como sea práctico

Obtener las versiones fundamentales alfa, beta y otras.

Obtener autosuficiencia por parte de los usuarios Concordancia en los logros del producto de parte de

las personas involucradas Lograr el consenso cuanto antes para liberar el

producto al mercado.

Inicio Elaboración Construcción Transición

Esfuerzo 5 % 20 % 65 % 10%

Tiempo Dedicado 10 % 30 % 50 % 10%

Se crea código para otras personas Los usuarios son una fuente imperfecta para la

recolección de requisitos. Los usuarios no conocen los requisitos y/o les cuesta

especificarlos de manera precisa Los requisitos cambian Las condiciones en las que se especifican los requisitos

varían Existen usuarios diferentes que aportan criterios

diversos.

Tarea Artefactos (Productos)

Enumerar requisitos candidatos Lista de características.

Entender el contexto del sistema

Modelo de negocio o de dominio.

Capturar requisitos funcionales Modelo de casos de uso.

Capturar requisitos no funcionales

Requisitos suplementarios o casos individuales.

Definicion Planes Estudio (Actual )

ConesupConsejo Superior

Comite Profesores

DGADirector Escuela

Inicio

Propuestade carrera

Definir Planes Estuido

Elaborar Plan

Redactar Informe de plan de

estudios

Revisar Plan de

estudios

Aprobado

Redefinicion de plan

de estudios

No

Oficializa plan de

estudios

Si

Documentacion necesaria para que el conesup

aprueba el plan de estudios

Validar Plan de Estudio

Aprobar

Reporte de cambios

No

Reporte de

cambios

Reporte de cambios

1

2 Si

Establecer y mantener un acuerdo con los clientes y otros interesados en lo que debe hacer el sistema.

Proveer a los desarrolladores del sistema una mejor comprensión de los requerimientos.

Definir los límites del sistema.

Proporciona una base para planear el contenido técnico de las iteraciones.

Proporciona una base para estimar costes y tiempos de desarrollo del sistema.

Definir interfaces de usuario para el sistema, centrándose en las necesidades y metas de los usuarios.

Representación Significado Definición

Trabajador

(Quién)

Define el comportamiento

y las habilidades de un

individuo

Artefactos

(Resultados)

Es un término general

para cualquier tipo de

descripción o información

creada, producida,

cambiada o utilizada por

los trabajadores durante

su trabajo con el sistema.

Actividades(Qué)Es una unidad de trabajo que se

asignada aun trabajador.

Flujos de trabajoEs una secuencia de actividades que

produce un resultado valioso.

Trabajadores y artefactos