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