UNIVERSIDAD TECNOLOGICA PRIVADA DE SANTA CRUZ

FACULTAD DE CIENCIA Y TECNOLOGIA

SISTEMA DE GESTION DE INFORMACION DE CONSULTAS DEL

HOSPITAL GENERAL “SAN JUAN DE DIOS”

Integrantes:
Ronal Inturias Jimenez
Fernando Magne

Santa Cruz – Bolivia

2017
CAPITULO I: ASPECTOS METOLOGICOS

TÍTULO DEL PROYECTO

Sistema de Gestión de información de consultas del Hospital General “San Juan De
Dios”.

INTRODUCCION:
En el presente trabajo se hará un sistema de información para el hospital “San Juan
De Dios” en un plazo determinado, usando la metodología (PUP) para conseguir un
modelado del sistema para la gestión de personas que satisfaga toda sus
necesidades, el trabajo que se pretende desarrollar estará a cargo de un grupo de
analistas conformado por dos personas un programador y un analista en un plazo de
ocho meses. Para conseguir el objetivo planeado se utilizara barios herramientas de
software entre ellos architect, visual studio, SQL server e otros, este proyecto se lo
realizara en la oficina central de la empresa de desarrollo INTU.Srl
DEFINICIÓN DEL PROBLEMA

OBJETIVO GENERAL:
Desarrollar un sistema de información para la gestión de pacientes del hospital
general “San Juan De Dios” siguiendo las directrices de una metodología de
desarrollo de software.

OBJETIVOS ESPECÍFICOS:

 Capturar los requisitos de los procesos del negocio.

 Analizar los requerimientos de los operadores para realizar las tareas
operacionales del hospital.
 Diseñar las especificaciones del análisis.
 Implementar modelos anteriormente diseñados.
 Implementar modelo de prueba (Prueba de caja negra).
 Justificar la metodología a usar para el análisis del proyecto.
 Elaborar la planificación temporal de acuerdo a las fases de la
metodología elegida.
 Elaborar los modelos de casos de uso para expresar las
funcionalidades del sistema.
 Elaborar el diagrama de clase
 Elaborar el modelo de datos relacional
 Diceñar e implementar la interface de usuario
 Diceñar e implementar reportes
 Elaborar modelo de componentes
 Elaborar modelo de despliegue
 Implementar modelos de prueba
PROBLEMA
En un centro hospitalario se desea informar parte de la gestión relativa a pacientes.
Tras el análisis realizado, se establecen los siguientes requerimientos

- Los datos de interés que se desea almacenar el paciente con nro. de

seguridad social, DNI, nombre, apellidos y fecha de nacimiento.
- Un paciente estará asignado a una cama determinada de una planta del
hospital, pudiendo estar a lo largo del tiempo de ingreso en diferentes camas y
plantas, siendo significativa la fecha de la asignación de cama y el número de
esta. Habrá que tener en cuenta que las camas se numera correlativamente
por cada planta, es decir, existirá la cama número 12 de la tercera planta y
también la número 12 de la séptima planta. Las plantas del hospital estarán
identificadas por número de planta, su nombre y nro. de camas que dispone.
- Por cada paciente se entregara hasta máximo de 4 tarjetas de visitas. Estas
tarjetas de visita serán válidas para visitar a un único paciente. La tarjeta de
visita se definirá por nro. de tarjeta de visita y la hora de comienzo y el final en
que se puede visitar al enfermo.
- A un paciente le pueden atender diferentes médicos, siendo significativa por
cada visita médica la fecha y hora de esta. Y un paciente puede tener
diferentes diagnósticos de enfermedad, siendo significativa la fecha de
diagnóstico. Por otra parte, un médico puede tratar diferentes tipos de
diagnósticos y viceversa.
- Los datos de interés de los médicos serán: Código del médico, nombre y
apellidos. Los datos de interés de los diagnósticos serán: Código de
diagnóstico y descripción.
NOTA: Una vez dado de alta el paciente se traslada toda la información relativa a
este a un fichero histórico

JUSTIFICACIÓN METODOLÓGICA (PUD)

Para la necesidad del sistema del cliente hemos decidido optar por la metodología de Proceso
Unificado de Desarrollo de Software (PUD) ya que este sistema presente es complejo, además
La razón de haber elegido el uso es porque reduce la dificultad de organizar las diferentes fases de
trabajo, para el desarrollo del proyecto se conoce que es un proyecto de tamaño grande donde es
necesario delimitar el alcance de manera arquitectónica para lograr comprender correctamente
los requisitos del hospital

Uso de P.U.D

Esta metodología por su amplitud es más apropiada para proyectos grandes, de largo plazo y sobre
todo cuando se trabaja con equipos de desarrollo con numerosas personas y dispersos en cuanto a
ubicación geográfica
PLANIFICACION TEMPORAL
CAPITULO II MARCO
TEORICO:MARCO TEORICO:
EL PROCESO UNIFICADO DE DESARROLLO DE SOFWARE. (PUD)

Es un conjunto de actividades necesarias para transformar los requisitos de usuario en un producto

software. Es una metodología, paradigma que transforma las entradas o requerimientos a través de
un proceso sistemático disciplinado y cuantificable en soluciones del problema.

Proceso unificado
Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases

denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez
dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos
grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que
añade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las
definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y
Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de
esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.

Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para
definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de
uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño,
implementación, prueba, etc.

Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema.
Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un
sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos
planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.

Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos
en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de
Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son
considerados primero.

El Proceso Unificado de desarrollo puede ser dividido en cuatro fases para su mejor desarrollo. Estas
fases ayudando tanto a la elaboración como a la resolución de problemas
Iniciación
En la fase de inicio se define el negocio: facilidad de realizar el proyecto, se presenta un modelo,
visión, metas, deseos del usuario, plazos, costos y viabilidad.
Elaboración
En esta fase se obtiene la visión refinada del proyecto a realizar, la implementación iterativa del
núcleo de la aplicación, la resolución de riesgos altos, nuevos requisitos y se ajustan las estimaciones.
Construcción
Esta abarca la evolución hasta convertirse en producto listo incluyendo requisitos mínimos. Aquí se
afinan los detalles menores como los diferentes tipos de casos o los riesgos menores.
Transición
En esta fase final, el programa debe estar listo para ser probado, instalado y utilizado por el cliente sin
ningún problema. Una vez finalizada esta fase, se debe comenzar a pensar en futuras
novedades para la misma
CAPITULO III: INGENIERIA DEL PROYECTO
MODELO DE REQUISITOS
Nro. Requerimiento
RF1 Registrar al paciente
RF2 Registrar la asignación de cama o
habitación del paciente
RF3 Registrar ingreso del medico
RF4 Registrar la Categoría de
operaciones y cirugías
RF5 Imprimir el listado de operación o
cirugía del paciente
RF6 Mostrar la operación o cirugía del
paciente
RF7 Registrar salida del paciente
RF8 Realizar copia de seguridad del
sistema
RF9 Registrar Tarjetas de visitas
RF10 Registrar diagnóstico del paciente
RF11 Registrar cita medica
Descripción
El usuario puede registrar al paciente
El usuario puede asignar la cama y la planta en que el
paciente se hospedara o será atendido
El usuario registra y verifica el ingreso del medico
El usuario puede registrar las categorías de cirugía y
operaciones del paciente
El usuario puede realizar la impresión en las fechas que
requiera (por mes, año)
El usuario podrá revisar la operación o la cirugía del
paciente
El usuario entrega un comprobante detallado al
paciente al salir del hospital
El usuario(preferentemente una persona capacitada)
podrá realizar una copia de seguridad
El usuario registra las tarjetas de visitas (hora – fecha)
El usuario será capaz de dar de alta, modificar el
diagnostico resultante de la consulta
El usuario será capaz de programar los pacientes que
requieren de citas medicas
REQUISITOS NO FUNCIONALES
Se requiere requisitos mínimos de hardware como ser:

 Procesador Intel(R) Core(TM) i3 CPU @ 1.60GHz.

 Memoria RAM 4 Gb para mejor rendimiento.
 Mínimo 100mb de disco duro para el software, se recomienda más espacio a
medida que crezca los datos de la base de datos.
 Impresora para imprimir reportes del programa.

Requerimientos de Performance

Para el desarrollo de este sistema se requiere distintas herramientas como ser:

 Visual Studio 2015

 Microsoft Office 2010 o Superior

 Net Framework 3.5 o superior

 Virtual Box para realizar pruebas en diferentes S.O

 La aplicación debe desarrollarse en .NET utilizando, Entity framework, Visual C#.Net, y

derivados de SQL con T/SQL para el motor de base de datos SQL Server 2008 como
mínimo.
 Se necesita hacer una gestión de riesgos para tener planes ante contingencias
Planes de Backus
DIAGRAMA GENERAL DEL CASO DE USO

uc Use Case Model

Gestion Paciente

Gestion Medico

Administrador de Gestion
Paciente
Administrador de gestion
de citas Gestion cita Medicas

Gestion Diagnostico
DESCRIPCION DE LOS ACTORES DEL SISTEMA

ACTOR Descripción

Gestión de paciente
Administrador de Gestión de Realiza informes del
pacientes pacientes registrado

Gestiona la salida y
Administrador de Citas entra del paciente a las
medicas citas medicas
MODELOS DE ANALISIS (casos de uso)

ESPECIFICACION DE CASOS DE USO

Casos de usos - Gestionar paciente

GESTIONAR PACIENTE

CASO DE USO (GESTIONAR PACIENTE)

ACTOR PRINCIPAL OPERADOR DE ADMINISTRACION DE GESTION DE PACIENTE
DESCRIPCION El usuario ingresa los datos necesarios para ingresar un nuevo
paciente al sistema
FLUJO NORMAL
ACTOR SISTEMA
2) EL SISTEMA MUESTRA EL FORMULARIO DE
1) EL ACTOR SOLICITA EL
GESTIONES
INGRESO AL SISTEMA
4) EL SISTEMA MUESTRA UN FORMULARIO PARA
3) EL ACTOR ELIGE
LLENAR DATOS DEL NUEVO PACIENTE
GESTIONAR PACIENTE
6) EL SISTEMA VALIDA EL NRO Id DEL PACIENTE
5) EL ACTOR INGRESA LOS
DATOS
CORRESPONDIENTES
8) EL SISTEMA VALIDA LOS DATOS INGRESADOS DEL
7) EL ACTOR GUARDAR LOS
PACIENTE
DATOS AGREGADOS
9) EL SISTEMA AGREGA AL PACIENTE EN LA BASE DE
DATOS

FLUJO ALTERNO: EL SISTEMA MUESTRA UN MENSAJE DE ERROR SI EL ACTOR INGRESA SU ID QUE

EXITE EN LA BD REPLICADO EL SISTEMA MUESTRA UN MENSAJE DE ERROR CON ID YA EXITE EN LA
BD
EL SISTEMA MOSTRARA UN MENSAJE DE ERROR SI EL ACTOR INGRESA INCORRECTAMENTE LOS
DATOS EN EL FORMULARIO DE PACIENTE Y VOLVERA A SOLICITAR A LLENAR EL FORM EN EL CAMPO
FALTANTE
Caso de uso - GESTIONAR MEDICO

GESTIONAR MEDICO

CASO DE USO (GESTIONAR MEDICO)

ACTOR PRINCIPAL OPERADOR DE ADMINISTRACION DE GESTION DE PACIENTE
DESCRIPCION El usuario ingresa los datos necesarios para ingresar un
medico al sistema
FLUJO NORMAL
ACTOR SISTEMA
2) EL SISTEMA MUESTRA EL FORMULARIO DE GESTION
1) EL ACTOR SOLICITA EL
INGRESO AL SISTEMA
4) EL SISTEMA MUESTRA UN FORMULARIO PARA
3) EL ACTOR ELIGE
LLENAR DATOS DEL MEDICO
GESTIONAR MEDICO
6) EL SISTEMA VALIDA SI ES UN MEDICO ACTIVO O
5) EL ACTOR INGRESA LOS
INACTIVO
DATOS
CORRESPONDIENTES
8) EL SISTEMA VALIDA LOS DATOS INGRESADOS DEL
7) EL ACTOR GUARDAR LOS
MEDICO
DATOS AGREGADOS
9) EL SISTEMA AGREGA AL MEDICO EN LA BASE DE
DATOS

FLUJO ALTERNO: EL SISTEMA MUESTRA UN MENSAJE DE ERROR SI EL ACTOR NO INGRESA LOS

CAMPOS QUE EL SISTEMA REQUIERE Y MANDO UN MENSAJE CON LLENAR TODO LOS CAMPOS
REQUERIDOS ANTES DE GUARDAR EN LA BD
EL SISTEMA MOSTRARA UN MENSAJE DE ERROR SI EL ACTOR INGRESA INCORRECTAMENTE LOS
DATOS EN EL FORMULARIO DE MEDICO Y VOLVERA A SOLICITAR A LLENAR EL FORM EN EL CAMPO
FALTANTE
Caso de uso - GESTIONAR CITA

GESTIONAR CITA

CASO DE USO (GESTIONAR CITA)

ACTOR PRINCIPAL OPERADOR DE ADMINISTRACION DE CITAS MEDICAS
DESCRIPCION El actor ingresa los datos necesarios para asigna una nueva
cita
FLUJO NORMAL
ACTOR SISTEMA
2) EL SISTEMA MUESTRA EL MENU DE OPCIONES DE
1) EL ACTOR SOLICITA EL
GESTIONES
MENU DE LA GESTIONES
4) EL SISTEMA MUESTRA UN FORMULARTIO PARA
3) EL ACTOR ELIGE
AGREGAR NUEVA CITA
GESTIONAR CITA
6) EL SISTEMA MUESTRA LOS DOCTORES DISPONIBLES
5) El ACTOR REGISTRA LA
DE TURNO SEGÚN LA HORA ELEGIDA
HORA DE LA CITA
8) EL SISTEMA CALCULA Y MUESTRA EL TOTAL DE
7) EL ACTOR REGISTRA EL
COBRO
DESCUENTO
10) EL SISTEMA PROCESA LOS DATOS EN LA BASE DE
9) EL ACTOR LLENA LOS
DATOS
CAMPOS DEL
FORMULARIO
11)EL SISTEMA CARGA LOS DATOS DE LA BD Y
MUESTRA LAS CITAS REGISTRADOS EN EL
FORMULARIO
11) EL SISTEMA PRESENTA PANTALLA DE OPERACION
EXITOSA

FLUJO ALTERNO: EL SISTEMAMUESTRA UN ALERTA SI EL ACTOR NO INGRESA LA HORA DE LA CITA

MEDICA
2.- EN EL PUNTO 7 SI EL ACTOR NO INGRESA LOS DATOS CORRECTOS EN EL FORMULARIO EL SISTEMA
MOSTRARA UN MENSAJE DE ERROR SOLICITANDO QUE VUELVA A INGRESAR LOS DATOS.
Caso de uso - GESTIONAR DIAGNOSTICO

GESTIONAR DIAGNOSTICO

CASO DE USO GESTIONAR DIAGNOSTICO

ACTOR PRINCIPAL OPERADOR DE ADMINISTRACION DE GESTION DE Citas
DESCRIPCION El usuario será capaz de dar de alta el diagnóstico del paciente
FLUJO NORMAL
ACTOR SISTEMA
2) EL SISTEMA MUESTRA UN MENU DE GESTIONES PARA
1) EL ACTOR SOLICITA EL
ELEGIR
INGRESO AL SISTEMA
4) EL SISTEMA MUESTRA LOS CAMPOS DEL
3) EL ACTOR ELIGE
FORMULARIO
GESTIONAR
DIAGNOSTICO
6) EL SISTEMA CARGA LAS CITAS EN ESPERA
5) EL ACTOR BUSCA LAS
CITAS EN ESPERA
SEGÚN LA FECHA
8) EL SISTEMA PROCESA LA ACCION E CARGA LOS DATOS
7) EL ACTOR SELECCIONA
DE REGISTRO DE LA CITA SELECCIONADA
LA CITA EN ESPERA
10) EL SISTEMA GUARDA LOS DATOS EN LA BASE DE
9) EL ACTOR LLENA LOS
DATOS
CAMPOS
FLUJOS ALTERNOS: EL SISTEMA MOSTRARA UNA ALERTA CUANDO NO SE HAYA INTRODUCIDO
NINGUN DATO EN LOS CAMPOS PRINCIPALES
MODELO DE DISEÑO

DIAGRAMA DE CLASES CONCEPTUALES

MODELO DE DATOS RELACIONAL (MAPEO)
PACIENTE(Ci,NroSeguro,NomPaciente,ApePaciente,FechaNacimiento,Peso,Tamaño,TipSangre,Genero)
PK
MEDICO(CodMedico,NomMedico,ApeMedico,CiMedico,Especialidad,Turno,FechaNac,Estado)
PK

CITAMEDICA (CodCita,FechaCita,HoraCita,Descripcion,Estado,Cobro,Ci,CodMedico )
PK FK FK

DIAGNOSTICO (CodDiag,NomEnfermeda,Descripcion,tratamiento ,CodCita)

PK FK

ENFERMEDAD (CodEnfermedad,NombreEnf,Descripcion)
PK
DETALLEENFERMEDAD (CodDiag,CodEnfermedad ,observación)
FK FK

INTERNACION (CodInternacion,FechaInicio,FechaFinal,ci,NroCama)
PK FK FK
VISITA (FechaVisita, HoraVisita, Ci, CodMedico)
PK FK FK
CAMA (NroCama, NroPlanta)
PK FK
TARJETAS (NroTarjeta, HoraInicio, HoraSalida, codInternacion)
PK FK
PLANTA (NroPlanta, NombrePlanta, NroCama)
PK
DISEÑO DE LA INTERFAZ DE USUARIO
  Diseño de Reportes (

DIAGRAMA DE SECUENCIA
Gestion Medico

*Gestion Pacientes
*Gestion citas medicas
GESTION DIAGNOSTICO
MODELO DE IMPLEMENTACIÓN

DIAGRAMA DE COMPONENTES
DIAGRAMA DE DESPLIEGUE
  MODELO DE PRUEBAS
Prueba de caja negra
La fase de prueba del sistema, tiene como objetivo la verificación de los diversos procesos para
comprobar si estos cumplieron con sus requisitos, en esta fase se desarrollaran pruebas de caja negra

Procedimiento de prueba Gestionar Paciente

Para esta prueba tiene que haber iniciado el sistema y entrar al menú Gestionar paciente.

Se utilizara la sesión del usuario “Admin” Correspondiente al usuario administrador del sistema.

1.- Clic en botón agregar del menú agregar paciente / Se habilitan las entradas / Ingresar los datos /
Llenar formulario y salvar

2.- Clic en botón modificar del menú modificar paciente / se habilitan las entradas / Modificar los
parámetros correspondientes

3.- Clic en Botón eliminar del menú eliminar paciente / Se habilitan las entrada/ buscar paciente/
eliminar
CONCLUSIONES
Luego de haber realizado el Análisis, diseño, implementación de los requerimientos
funcionales del sistema, se afirma que los objetivos planteados al inicio del estudio
del proyecto fueron alcanzados:

- Se analizó los requerimientos de los operadores del hospital general “San

Juan De Dios” para que así pueda realizar las tareas operacionales del
hospital.
o Durante la etapa de requerimientos se concluyó satisfactoriamente
habiendo capturado los requisitos relacionados con los procesos de
gestión de formularios
- Se Diseñó las especificaciones de los análisis propuestos
- Se diseñó modelos UML para este proyecto
o Esto permitió modelar de manera clara y ordenada los procesos que se
da en el sistema
- Se Implementó los modelos anteriormente diseñados.
- Se justificó satisfactoriamente la metodología usada para el análisis del
proyecto.
- Se Elaboró la planificación temporal de acuerdo a las fases de la metodologia
elegida.
- Se implementó los modelos de casos de uso para expresar las
funcionalidades del sistema.
- Se utilizó un modelo de prueba caja negra.
- Se elaboró e analizo el diagrama de clase
- Se implementó el modelo de datos relacional
- Se implementó y diseño las interfaces de usuario
- Se diseñó e implemento reportes
- Se elaboró correctamente los modelo de componentes
- Se elaboró correctamente el modelo de despliegue
- Se utilizó un modelo de prueba caja negra
-

RECOMENDACIONES
Las recomendaciones para el sistema de gestión de información del Hospital “San Juan De Dios” se
describen a continuación para que sirvan a futuras modificaciones del software.

Recomendaciones Generales.

El software presenta toda la documentación necesaria sobre el negocio, requerimientos, el esquema

de la base de datos e implementación de casos de uso permitiendo la implementación de los demás
modelos y funcionalidades.

Se recomienda hacer una copia de seguridad “Backup” diario para evitar multiples perdidas de
información de datos

Recomendaciones para el usuario

Se puede planificar una capacitación previa con los caso de uso implementados para familiarizar y
capacitar a los usuarios con una nueva forma de trabajo en el nuevo sistema

Recomendaciones de mantenimiento perfectivo

EL proceso unificado de desarrollo que se está utilizando (PUD), permite que el software se siga
desarrollando en nuevos ciclos por lo cual se recomienda ampliar el desarrollo del mismo.

Siguiendo el proceso de desarrollo de software adoptado para este proyecto, sistema lo cual
permite la implementación de todas estas recomendaciones

BIBLIOGRAFIA
Guevara, G. A. (2009). Sistema de informacion para gestion de citas medicas.

Kroenke, D., & Auer, D. (2009). Database Concepts. New Jersey: Prentice Hall.

Roca, E. S. (2013). Gestión de la Configuración del Software- Sistema de documentación y linea base.
Santa Cruz.

Roca, E. S. (s.f.). Sistema de información parar la gestión de ventas de productos.

Soto, E. R. (2010). Analisis de sistemas Guia MAP . Santa Cruz - Bolivia: UTEPSA.

Stair, R., & Reynolds, G. (2001). Principles of Information Systems. Boston: Course Technology.

Sitios Web

Quintero, J. (2010). es.slideshare.net. Obtenido de http://es.slideshare.net/jaquintero775/caja-

negra-2522077
ANEXOS

HISTORIA DEL PROCESO UNIFICADO (P.U.D)

Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los
contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational Software
compró una compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber
incorporado los casos de uso a los métodos de desarrollo orientados a objetos.

El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el
proceso de la empresa Objectory AB). El primer resultado de esta fusión fue el Rational Objectory
Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe
Philippe Kruchten.
PRINCIPALES ELEMENTOS

Como RUP es un proceso, en su modelación define como sus principales elementos:

Trabajadores (“quién”): Define el comportamiento y responsabilidades (rol) de un individuo, grupo

de individuos, sistema automatizado o máquina, que trabajan en conjunto como un equipo. Ellos
realizan las actividades y son propietarios de elementos.

Actividades (“cómo”): Es una tarea que tiene un propósito claro, es realizada por un trabajador y
manipula elementos.

Artefactos (“qué”): Productos tangibles del proyecto que son producidos, modificados y usados por
las actividades. Pueden ser modelos, elementos dentro del modelo, código fuente y ejecutables.

Flujo de actividades (“cuándo”): Secuencia de actividades realizadas por trabajadores y que produce
un resultado de valor observable.

PRINCIPALES VENTAJAS

 Coste del riesgo a un solo incremento.

 Reduce el riesgo de no sacar el producto en el calendario previsto.
 Acelera el ritmo de desarrollo.
 Se adapta mejor a las necesidades del cliente.