Você está na página 1de 33

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

Descripción

RF1

Registrar al paciente

El usuario puede registrar al paciente

RF2

Registrar la asignación de cama o habitación del paciente

El usuario puede asignar la cama y la planta en que el paciente se hospedara o será atendido

RF3

Registrar ingreso del medico

El usuario registra y verifica el ingreso del medico

RF4

Registrar la Categoría de operaciones y cirugías

El usuario puede registrar las categorías de cirugía y operaciones del paciente

RF5

Imprimir el listado de operación o

El usuario puede realizar la impresión en las fechas que

 

cirugía del paciente

requiera (por mes, año)

RF6

Mostrar la operación o cirugía del paciente

El usuario podrá revisar la operación o la cirugía del paciente

RF7

Registrar salida del paciente

El usuario entrega un comprobante detallado al

 
 

paciente al salir del hospital

RF8

Realizar copia de seguridad del sistema

El usuario(preferentemente una persona capacitada) podrá realizar una copia de seguridad

RF9

Registrar Tarjetas de visitas

El usuario registra las tarjetas de visitas (hora fecha)

RF10

Registrar diagnóstico del paciente

El usuario será capaz de dar de alta, modificar el diagnostico resultante de la consulta

RF11

Registrar cita medica

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

Paciente

Administrador de Gestion

Administrador de gestion

Gestion cita Medicas Gestion Diagnostico
Gestion cita Medicas
Gestion Diagnostico
Gestion Paciente Gestion Medico
Gestion Paciente
Gestion Medico
Paciente Administrador de Gestion Administrador de gestion Gestion cita Medicas Gestion Diagnostico Gestion Paciente Gestion Medico
Paciente Administrador de Gestion Administrador de gestion Gestion cita Medicas Gestion Diagnostico Gestion Paciente Gestion Medico
Paciente Administrador de Gestion Administrador de gestion Gestion cita Medicas Gestion Diagnostico Gestion Paciente Gestion Medico

uc Use Case Model

uc Use Case Model de citas
uc Use Case Model de citas

de citas

Paciente Administrador de Gestion Administrador de gestion Gestion cita Medicas Gestion Diagnostico Gestion Paciente Gestion Medico

DESCRIPCION DE LOS ACTORES DEL SISTEMA

ACTOR

Descripción

Administrador de Gestión de pacientes

Gestión de paciente Realiza informes del pacientes registrado

Administrador de Citas medicas

Gestiona la salida y entra del paciente a las 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

1)

EL ACTOR SOLICITA EL INGRESO AL SISTEMA

2)

EL SISTEMA MUESTRA EL FORMULARIO DE GESTIONES

3)

EL ACTOR ELIGE GESTIONAR PACIENTE

4)

EL SISTEMA MUESTRA UN FORMULARIO PARA LLENAR DATOS DEL NUEVO PACIENTE

5)

EL ACTOR INGRESA LOS DATOS CORRESPONDIENTES

6)

EL SISTEMA VALIDA EL NRO Id DEL PACIENTE

7)

EL ACTOR GUARDAR LOS DATOS AGREGADOS

8)

EL SISTEMA VALIDA LOS DATOS INGRESADOS DEL PACIENTE

 

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

1)

EL ACTOR SOLICITA EL INGRESO AL SISTEMA

2)

EL SISTEMA MUESTRA EL FORMULARIO DE GESTION

3)

EL ACTOR ELIGE GESTIONAR MEDICO

4)

EL SISTEMA MUESTRA UN FORMULARIO PARA LLENAR DATOS DEL MEDICO

5)

EL ACTOR INGRESA LOS DATOS CORRESPONDIENTES

6)

EL SISTEMA VALIDA SI ES UN MEDICO ACTIVO O INACTIVO

7)

EL ACTOR GUARDAR LOS DATOS AGREGADOS

8)

EL SISTEMA VALIDA LOS DATOS INGRESADOS DEL MEDICO

 

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

1)

EL ACTOR SOLICITA EL MENU DE LA GESTIONES

2)

EL SISTEMA MUESTRA EL MENU DE OPCIONES DE GESTIONES

3)

EL ACTOR ELIGE GESTIONAR CITA

4)

EL SISTEMA MUESTRA UN FORMULARTIO PARA AGREGAR NUEVA CITA

5)

El ACTOR REGISTRA LA HORA DE LA CITA

6)

EL SISTEMA MUESTRA LOS DOCTORES DISPONIBLES DE TURNO SEGÚN LA HORA ELEGIDA

7)

EL ACTOR REGISTRA EL DESCUENTO

8)

EL SISTEMA CALCULA Y MUESTRA EL TOTAL DE COBRO

9)

EL ACTOR LLENA LOS CAMPOS DEL FORMULARIO

10) EL SISTEMA PROCESA LOS DATOS EN LA BASE DE DATOS

   

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

1)

EL ACTOR SOLICITA EL INGRESO AL SISTEMA

2)

EL SISTEMA MUESTRA UN MENU DE GESTIONES PARA ELEGIR

3)

EL ACTOR ELIGE GESTIONAR DIAGNOSTICO

4)

EL SISTEMA MUESTRA LOS CAMPOS DEL FORMULARIO

5)

EL ACTOR BUSCA LAS CITAS EN ESPERA SEGÚN LA FECHA

6)

EL SISTEMA CARGA LAS CITAS EN ESPERA

7)

EL ACTOR SELECCIONA LA CITA EN ESPERA

8)

EL SISTEMA PROCESA LA ACCION E CARGA LOS DATOS DE REGISTRO DE LA CITA SELECCIONADA

9)

EL ACTOR LLENA LOS CAMPOS

10) EL SISTEMA GUARDA LOS DATOS EN LA BASE DE DATOS

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 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 VISITA (FechaVisita, HoraVisita, Ci, CodMedico)

PK

FK

FK

CAMA (NroCama, NroPlanta)

PK

FK

FK

FK

TARJETAS (NroTarjeta, HoraInicio, HoraSalida, codInternacion)

PK PLANTA (NroPlanta, NombrePlanta, NroCama) PK

FK

DISEÑO DE LA INTERFAZ DE USUARIO

DISEÑO DE LA INTERFAZ DE USUARIO

Diseño de Reportes (

DIAGRAMA DE SECUENCIA

Gestion Medico

 Diseño de Reportes ( DIAGRAMA DE SECUENCIA Gestion Medico *Gestion Pacientes

*Gestion Pacientes

 Diseño de Reportes ( DIAGRAMA DE SECUENCIA Gestion Medico *Gestion Pacientes

*Gestion citas medicas

*Gestion citas medicas

GESTION DIAGNOSTICO

GESTION DIAGNOSTICO

MODELO DE IMPLEMENTACIÓN

DIAGRAMA DE COMPONENTES

MODELO DE IMPLEMENTACIÓN DIAGRAMA DE COMPONENTES
MODELO DE IMPLEMENTACIÓN DIAGRAMA DE COMPONENTES

DIAGRAMA DE DESPLIEGUE

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. Durante la etapa de requerimientos se concluyó satisfactoriamente habiendo capturado los requisitos relacionados con los procesos de gestión de formularios

o

Se Diseñó las especificaciones de los análisis propuestos

Se diseñó modelos UML para este proyecto Esto permitió modelar de manera clara y ordenada los procesos que se da en el sistema

o

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

ANEXOS HISTORIA DEL PROCESO UNIFICADO (P.U.D) Los orígenes de RUP se remontan al modelo espiral original

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.