Plan de Desarrollo de Software
Odontomdica S.A.
OndontoSysPlan de Desarrollo de SoftwareVersin 1.0Historial de
RevisionesFechaVersinDescripcinAutor
13/03/20130.1Versin preliminar como propuesta de
desarrollo.Jorge Maidana
Milca Coronel
20/03/20130.3Versin propuesta para aprobacin al final de la fase
de inicio.Jorge Maidana
10/05/20130.5Versin lista para ser revisada al final de la fase
de elaboracin.Jorge Maidana
Milca Coronel
14/05/20130.6Versin revisada por el Stakeholder al final de la
fase de elaboracin.Jorge Maidana
Milca Coronel
11/06/20130.8Versin revisada en la primera iteracin de la fase
de construccinJorge MaidanaMilca Coronel
20/06/20130.9Versin revisada en la segunda iteracin de la fase
de construccin, pendiente de revisin del StakeholderJorge
Maidana
Milca Coronel
22/06/20131.0Versin revisada en la segunda iteracin de la fase
de construccin, pendiente de aprobacin del StakeholderJorge
Maidana
Milca Coronel
Tabla de Contenidos
41.Introduccin
1.1Propsito41.2Alcance41.3Resumen42.Vista General del
Proyecto42.1Propsito, Alcance y Objetivos42.2Suposiciones y
Restricciones52.3Entregables del proyecto52.4Evolucin del Plan de
Desarrollo del Software73.Organizacin del Proyecto73.1Participantes
en el Proyecto73.2Interfaces Externas73.3Roles y
Responsabilidades74.Gestin del Proceso84.1Estimaciones del
Proyecto84.2Plan del Proyecto84.2.1Plan de las
Fases84.2.2Calendario del Proyecto104.3Seguimiento y Control del
Proyecto135.Referencias13
Plan de Desarrollo del Software1. Introduccin
Este Plan de Desarrollo del Software es una versin preliminar
preparada para ser incluida en la propuesta elaborada como
respuesta al proyecto de grado de la materia Proyecto 1 de la
carrera de Lic. Ciencias Informticas de la Facultad Politcnica -
UNA. Este documento provee una visin global del enfoque de
desarrollo propuesto.
El proyecto ha sido ofertado por Jorge Maidana basado en una
metodologa de Rational Unified Process - RUP en la que nicamente se
proceder a cumplir con las tres primeras fases que marca la
metodologa, constando nicamente en la tercera fase de dos
iteraciones. Es importante destacar esto puesto que utilizaremos la
terminologa RUP en este documento. Se incluir el detalle para las
fases de Inicio y Elaboracin y adicionalmente se esbozarn las fases
posteriores de Construccin y Transicin para dar una visin global de
todo el proceso.
El enfoque desarrollo propuesto constituye en una configuracin
del proceso RUP de acuerdo a las caractersticas del proyecto,
seleccionando los roles de los participantes, las actividades a
realizar y los artefactos (entregables) que sern generados. Este
documento es a su vez uno de los artefactos de RUP.
1.1 Propsito
El propsito del Plan de Desarrollo de Software es proporcionar
la informacin necesaria para controlar el desarrollo del proyecto.
En l se describe el enfoque de desarrollo del software.
Los usuarios del Plan de Desarrollo del Software son:
El jefe del proyecto lo utiliza para organizar la agenda y
necesidades de recursos, y para realizar su seguimiento.
Los miembros del equipo de desarrollo lo usan para entender lo
qu deben hacer, cundo deben hacerlo y qu otras actividades dependen
de ello.
1.2 Alcance
El Plan de Desarrollo del Software describe el plan usado para
el desarrollo del Sistema para Gestin de Pacientes y Facturacin
OdontoSys. El detalle de las iteraciones individuales se describe
en los planes de cada iteracin, documentos que se aportan en forma
separada. Durante el proceso de desarrollo en el artefacto Visin se
definen las caractersticas del producto a desarrollar, lo cual
constituye la base para la planificacin de las iteraciones. Para la
versin 1.0 del Plan de Desarrollo del Software, nos hemos basado en
la captura de requisitos por medio del stakeholder (representante
de la empresa) para hacer una estimacin aproximada, una vez
comenzado el proyecto y durante la fase de Inicio se generar la
primera versin del artefacto Visin, el cual se utilizar para
refinar este documento. Posteriormente, el avance del proyecto y el
seguimiento en cada una de las iteraciones ocasionar el ajuste de
este documento produciendo nuevas versiones actualizadas.1.3
Resumen
Despus de esta introduccin, el resto del documento est
organizado en las siguientes secciones:
Vista General del Proyecto proporciona una descripcin del
propsito, alcance y objetivos del proyecto, estableciendo los
artefactos que sern producidos y utilizados durante el
proyecto..
Organizacin del Proyecto describe la estructura organizacional
del equipo de desarrollo.
Gestin del Proceso explica los costos y planificacin estimada,
define las fases e hitos del proyecto y describe cmo se realizar su
seguimiento.
Planes y Guas de aplicacin proporciona una vista global del
proceso de desarrollo de software, incluyendo mtodos, herramientas
y tcnicas que sern utilizadas.
2. Vista General del Proyecto
2.1 Propsito, Alcance y Objetivos
La informacin que a continuacin se incluye ha sido extrada de
las diferentes reuniones que se han celebrado con el stakeholder de
la empresa desde el inicio del proyecto.
Odontomdica S.R.L. presta los servicios de odontologa a sus
variados pacientes. La entrada en un mercado competitivo como en el
que encuentra inmersa la firma lo lleva a una previsible adaptacin
de nuevos sistemas de gestin y facturacin informatizada. Por ello,
se considera necesario el desarrollo de un nuevo sistema de gestin
de los pacientes de la odontologa, manteniendo as una base de datos
de los clientes y los servicios realizados, por tanto los
solicitantes demandan una gestin ms rpida, automtica y eficiente de
las gestiones de Registro de Clientes y facturacin de los servicios
prestados
El Sistema OdontoSys se divide principalmente en tres grandes
bloques:
a) Gestin de Pacientes, incluyendo:
Agregar nuevos clientes.
Modificar o Eliminar registro de Clientes.
Establecer tratamiento
Mantener una Hoja de servicios prestados.
Gestionar una agenda de consultas
b) Registro de Servicios prestados, incluyendo:
Especificacin del tipo de servicio.
Almacenamiento del servicio prestado en la base de datos.
Procedimiento de facturacin del servicio.
c) Control de Compras, incluye:
Manejar un estado de cuenta de proveedores
Gestionar compras
2.2 Suposiciones y Restricciones
Las suposiciones y restricciones respecto del sistema, y que se
derivan directamente de las entrevistas con el stakeholder de la
empresa son:
a) Debe contemplarse las implicaciones de los siguientes puntos
crticos:
La base de datos a utilizar ser de licencia libre o versiones
bsicas o gratuitas de las versiones pago.
Sistemas seguros: proteccin de informacin mediante usuario y
contrasea para el ingreso al Sistema y base de datos.
Gestin de flujos de trabajo, seguridad de transacciones e
intercambio de informacin.
Los datos de clientes y los servicios prestados estarn
completamente en la base de datos, para una eventual copia de
seguridad o reinstalacin del sistema.
b) La Facturacin de los servicios debe ajustarse a la legislacin
vigente y considerar los requisitos para que cumplir con lo
establecido por la ley.
c) El mdulo de Gestin de Clientes constar de una planilla de los
tratamientos realizados al paciente, con lo cual se llevar un
registro del tipo de tratamiento y las fechas de las mismas.
Como es natural, la lista de suposiciones y restricciones se
incrementar durante el desarrollo del proyecto, particularmente una
vez establecido el artefacto Visin.2.3 Entregables del proyecto
A continuacin se indican y describen cada uno de los artefactos
que sern generados y utilizados por el proyecto y que constituyen
los entregables. Esta lista constituye la configuracin de RUP desde
la perspectiva de artefactos, y que proponemos para este
proyecto.
Es preciso destacar que de acuerdo a la filosofa de RUP (y de
todo proceso iterativo e incremental), todos los artefactos son
objeto de modificaciones a lo largo del proceso de desarrollo, con
lo cual, slo al trmino del proceso podramos tener una versin
definitiva y completa de cada uno de ellos. Sin embargo, el
resultado de cada iteracin y los hitos del proyecto estn enfocados
a conseguir un cierto grado de completitud y estabilidad de los
artefactos. Esto ser indicado ms adelante cuando se presenten los
objetivos de cada iteracin.
1) Plan de Desarrollo del Software
Es el presente documento.
2) Modelo de Casos de Uso del Negocio
Es un modelo de las funciones de negocio vistas desde la
perspectiva de los actores externos (Agentes de registro,
solicitantes finales, otros sistemas etc.). Permite situar al
sistema en el contexto organizacional haciendo nfasis en los
objetivos en este mbito. Este modelo se representa con un Diagrama
de Casos de Uso usando estereotipos especficos para este modelo.3)
Modelo de Objetos del Negocio
Es un modelo que describe la realizacin de cada caso de uso del
negocio, estableciendo los actores internos, la informacin que en
trminos generales manipulan y los flujos de trabajo (workflows)
asociados al caso de uso del negocio. Para la representacin de este
modelo se utilizan Diagramas de Colaboracin (para mostrar actores
externos, internos y las entidades (informacin) que manipulan, un
Diagrama de Clases para mostrar grficamente las entidades del
sistema y sus relaciones, y Diagramas de Actividad para mostrar los
flujos de trabajo.
4) Glosario
Es un documento que define los principales trminos usados en el
proyecto. Permite establecer una terminologa consensuada.5) Modelo
de Casos de Uso
El modelo de Casos de Uso presenta las funciones del sistema y
los actores que hacen uso de ellas. Se representa mediante
Diagramas de Casos de Uso.
6) Visin
Este documento define la visin del producto desde la perspectiva
del cliente, especificando las necesidades y caractersticas del
producto. Constituye una base de acuerdo en cuanto a los requisitos
del sistema.
7) Especificaciones de Casos de Uso
Para los casos de uso que lo requieran (cuya funcionalidad no
sea evidente o que no baste con una simple descripcin narrativa) se
realiza una descripcin detallada utilizando una plantilla de
documento, donde se incluyen: precondiciones, post-condiciones,
flujo de eventos, requisitos no-funcionales asociados. Tambin, para
casos de uso cuyo flujo de eventos sea complejo podr adjuntarse una
representacin grfica mediante un Diagrama de Actividad.
8) Prototipos de Interfaces de Usuario
Se trata de prototipos que permiten al usuario hacerse una idea
ms o menos precisa de las interfaces que proveer el sistema y as,
conseguir retroalimentacin de su parte respecto a los requisitos
del sistema. Estos prototipos se realizarn como: dibujos a mano en
papel, dibujos con alguna herramienta grfica o prototipos
ejecutables interactivos, siguiendo ese orden de acuerdo al avance
del proyecto. Slo los de este ltimo tipo sern entregados al final
de la fase de Elaboracin, los otros sern desechados. Asimismo, este
artefacto, ser desechado en la fase de Construccin en la medida que
el resultado de las iteraciones vayan desarrollando el producto
final.
9) Modelo de Datos
Previendo que la persistencia de la informacin del sistema ser
soportada por una base de datos relacional, este modelo describe la
representacin lgica de los datos persistentes, de acuerdo con el
enfoque para modelado relacional de datos. Para expresar este
modelo se utiliza un Diagrama de Clases (donde se utiliza un
profile UML para Modelado de Datos, para conseguir la representacin
de tablas, claves, etc.)
10) Modelo de Implementacin
Este modelo es una coleccin de componentes y los subsistemas que
los contienen. Estos componentes incluyen: ficheros ejecutables,
ficheros de cdigo fuente, y todo otro tipo de ficheros necesarios
para la implantacin y despliegue del sistema. (Este modelo es slo
una versin preliminar al final de la fase de Elaboracin,
posteriormente tiene bastante refinamiento).
11) Modelo de Despliegue
Este modelo muestra el despliegue la configuracin de tipos de
nodos del sistema, en los cuales se har el despliegue de los
componentes.
12) Casos de Prueba
Cada prueba es especificada mediante un documento que establece
las condiciones de ejecucin, las entradas de la prueba, y los
resultados esperados. Estos casos de prueba son aplicados como
pruebas de regresin en cada iteracin. Cada caso de prueba llevar
asociado un procedimiento de prueba con las instrucciones para
realizar la prueba, y dependiendo del tipo de prueba dicho
procedimiento podr ser automatizable mediante un script de
prueba.
13) Solicitud de Cambio
Los cambios propuestos para los artefactos se formalizan
mediante este documento. Mediante este documento se hace un
seguimiento de los defectos detectados, solicitud de mejoras o
cambios en los requisitos del producto. As se provee un registro de
decisiones de cambios, de su evaluacin e impacto, y se asegura que
stos sean conocidos por el equipo de desarrollo. Los cambios se
establecen respecto de la ltima baseline (el estado del conjunto de
los artefactos en un momento determinado del proyecto) establecida.
En nuestro caso al final de cada iteracin se establecer una
baseline.
14) Plan de Iteracin
Es un conjunto de actividades y tareas ordenadas temporalmente,
con recursos asignados, dependencias entre ellas. Se realiza para
cada iteracin, y para todas las fases.
15) Evaluacin de Iteracin
Este documento incluye le evaluacin de los resultados de cada
iteracin, el grado en el cual se han conseguido los objetivos de la
iteracin, las lecciones aprendidas y los cambios a ser
realizados.
16) Lista de Riesgos
Este documento incluye una lista de los riesgos conocidos y
vigentes en el proyecto, ordenados en orden decreciente de
importancia y con acciones especficas de contingencia o para su
mitigacin.
17) Manual de Instalacin
Este documento incluye las instrucciones para realizar la
instalacin del producto.
18) Material de Apoyo al Usuario Final
Corresponde a un conjunto de documentos y facilidades de uso del
sistema, incluyendo: Guas del Usuario, Guas de Operacin, Guas de
Mantenimiento y Sistema de Ayuda en Lnea
19) Producto
Los ficheros del producto empaquetados y almacenadas en un CD
con los mecanismos apropiados para facilitar su instalacin. El
producto, a partir de la primera iteracin de la fase de Construccin
es desarrollado incremental e iterativamente, obtenindose una nueva
release al final de cada iteracin.
Los artefactos 17, 18 y 19 se generarn a partir de la fase de
Construccin, con lo cual se han incluido aqu slo para dar una visin
global de todos los artefactos que se generarn en el proceso de
desarrollo.
2.4 Evolucin del Plan de Desarrollo del Software
El Plan de Desarrollo del Software se revisar semanalmente y se
refinar antes del comienzo de cada iteracin.
3. Organizacin del Proyecto
3.1 Participantes en el ProyectoJefe de Proyecto.
Labor de Jorge Maidana, principal gestor y punto de contacto con
el stakeholder, analista y programador; alumno del ltimo ao de la
carrera Lic. en Ciencias Informticas en la Facultad Politcnica -
UNA.
Analistas - Programadores. Jorge Maidana, analista y
programador; alumno del ltimo ao de la carrera Lic. en Ciencias
Informticas en la Facultad Politcnica - UNA. Con conocimientos de
las metodologas de desarrollo, herramientas CASE y notaciones, en
particular la notacin UML y el proceso de desarrollo RUP, . Milca
Coronel, encargada de los anlisis y realizacin en conjunto de los
distintos Diagramas del Sistema y parte del a programacin; alumna
del ltimo ao de la carrera Lic. en Ciencias Informticas en la
Facultad Politcnica - UNA. Con conocimientos de las metodologas de
desarrollo, herramientas CASE y notaciones, en particular la
notacin UML y el proceso de desarrollo RUP.3.2 Interfaces
Externas
OdontoSys ofrecer, a travs de una interfaz amigable, las
funcionalidades:
Gestin de Pacientes
Gestin de Facturacin
Gestin de Compras
3.3 Roles y Responsabilidades
A continuacin se describen las principales responsabilidades de
cada uno de los puestos en el equipo de desarrollo durante las
fases de Inicio y Elaboracin, de acuerdo con los roles que
desempean en RUP.
PuestoResponsabilidad
Jefe de ProyectoEl jefe de proyecto asigna los recursos,
gestiona las prioridades, coordina las interacciones con los
clientes y usuarios, y mantiene al equipo del proyecto enfocado en
los objetivos. El jefe de proyecto tambin establece un conjunto de
prcticas que aseguran la integridad y calidad de los artefactos del
proyecto. Adems, el jefe de proyecto se encargar de supervisar el
establecimiento de la arquitectura del sistema. Gestin de riesgos.
Planificacin y control del proyecto.
Analista de SistemasCaptura, especificacin y validacin de
requisitos, interactuando con el cliente y los usuarios mediante
entrevistas. Elaboracin del Modelo de Anlisis y Diseo. Colaboracin
en la elaboracin de las pruebas funcionales y el modelo de
datos.
ProgramadorConstruccin de prototipos. Colaboracin en la
elaboracin de las pruebas funcionales, modelo de datos y en las
validaciones con el usuario
4. Gestin del Proceso
4.1 Estimaciones del Proyecto
El presupuesto del proyecto y los recursos involucrados se
adjuntan en un documento separado.
4.2 Plan del Proyecto
En esta seccin se presenta la organizacin en fases e iteraciones
y el calendario del proyecto.4.2.1 Plan de las Fases
El desarrollo se llevar a cabo en base a fases con una o ms
iteraciones en cada una de ellas. La siguiente tabla muestra la
distribucin aproximada de tiempos y nmero de iteraciones de cada
fase.FaseNro.
IteracionesDuracin
Fase de Inicio12 semanas
Fase de Elaboracin12 semanas
Fase de Construccin26 semanas
Fase de Transicin--
Los hitos que marcan el final de cada fase se describen en la
siguiente tabla.
DescripcinHito
Fase de InicioEn esta fase desarrollar los requisitos del
producto desde la perspectiva del usuario, los cuales sern
establecidos en el artefacto Visin. Los principales casos de uso
sern identificados y se har un refinamiento del Plan de Desarrollo
del Proyecto. La aceptacin del cliente / usuario del artefacto
Visin y el Plan de Desarrollo marcan el final de esta fase.
Fase de ElaboracinEn esta fase se analizan los requisitos y se
desarrolla un prototipo de arquitectura (incluyendo las partes ms
relevantes y / o crticas del sistema). Al final de esta fase, todos
los casos de uso correspondientes a requisitos que sern
implementados en la primera release de la fase de Construccin deben
estar analizados y diseados (en el Modelo de Anlisis / Diseo). La
revisin y aceptacin del prototipo de la arquitectura del sistema
marca el final de esta fase. En nuestro caso particular, por no
incluirse las fases siguientes, la revisin y entrega de todos los
artefactos hasta este punto de desarrollo tambin se incluye como
hito. La primera iteracin tendr como objetivo la identificacin y
especificacin de los principales casos de uso, as como su
realizacin preliminar en el Modelo de Anlisis / Diseo, tambin
permitir hacer una revisin general del estado de los artefactos
hasta este punto y ajustar si es necesario la planificacin para
asegurar el cumplimiento de los objetivos. Ambas iteraciones tendrn
una duracin de una semana.
Fase de ConstruccinDurante la fase de construccin se terminan de
analizar y disear todos los casos de uso, refinando el Modelo de
Anlisis / Diseo. El producto se construye en base a 2 iteraciones,
cada una produciendo una release a la cual se le aplican las
pruebas y se valida con el cliente / usuario. Se comienza la
elaboracin de material de apoyo al usuario. El hito que marca el
fin de esta fase es la versin de la release 3.0, con la capacidad
operacional parcial del producto que se haya considerado como
crtica, lista para ser entregada a los usuarios para pruebas
beta.
Fase de TransicinEn esta fase se prepararn dos releases para
distribucin, asegurando una implantacin y cambio del sistema previo
de manera adecuada, incluyendo el entrenamiento de los usuarios. El
hito que marca el fin de esta fase incluye, la entrega de toda la
documentacin del proyecto con los manuales de instalacin y todo el
material de apoyo al usuario, la finalizacin del entrenamiento de
los usuarios y el empaquetamiento del producto.
4.2.2 Calendario del Proyecto
A continuacin se presenta un calendario de las principales
tareas del proyecto incluyendo slo las fases de Inicio y
Elaboracin. Como se ha comentado, el proceso iterativo e
incremental de RUP est caracterizado por la realizacin en paralelo
de todas las disciplinas de desarrollo a lo largo del proyecto, con
lo cual la mayora de los artefactos son generados muy tempranamente
en el proyecto pero van desarrollndose en mayor o menor grado de
acuerdo a la fase e iteracin del proyecto. La siguiente figura
ilustra este enfoque, en ella lo ensombrecido marca el nfasis de
cada disciplina (workflow) en un momento determinado del
desarrollo.
Para este proyecto se ha establecido el siguiente calendario. La
fecha de aprobacin indica cundo el artefacto en cuestin tiene un
estado de completitud suficiente para someterse a revisin y
aprobacin, pero esto no quita la posibilidad de su posterior
refinamiento y cambios.
Disciplinas / Artefactos generados o modificados
durante la Fase de InicioComienzoAprobacin
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo de Objetos del
NegocioSemana 1
14/10 20/04Semana 3
28/05 3/05
Requisitos
GlosarioSemana 1
14/10 20/04Semana 3
28/10 3/05
VisinSemana 2
21/05 27/04Semana 3
28/10 3/05
Modelo de Casos de UsoSemana 3
28/04 3/05siguiente fase
Especificacin de Casos de UsoSemana 3
28/04 3/05siguiente fase
Especificaciones AdicionalesSemana 3
28/04 3/05siguiente fase
Anlisis / Diseo
Modelo de Anlisis / DiseoSemana 2
21/04 27/04siguiente fase
Modelo de DatosSemana 2
21/04 27/04siguiente fase
Implementacin
Prototipos de Interfaces de UsuarioSemana 3
28/04 3/05siguiente fase
Modelo de ImplementacinSemana 3
28/04 3/05siguiente fase
Pruebas
Casos de Pruebas FuncionalesSemana 3
28/04 3/05siguiente fase
Despliegue
Modelo de DespliegueSemana 3
28/04 3/05siguiente fase
Gestin de Cambios y ConfiguracinDurante todo el proyecto
Gestin del proyecto
Plan de Desarrollo del Software en su versin 1.0 y planes de las
IteracionesSemana 1
14/04 20/05Semana 3
28/04 3/05
AmbienteDurante todo el proyecto
Disciplinas / Artefactos
generados o modificados durante la
Fase de ElaboracinComienzoAprobacin
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo de Objetos del
NegocioSemana 1
14/04 20/04aprobado
Requisitos
GlosarioSemana 1
14/04 20/04aprobado
VisinSemana 2
21/04 27/04aprobado
Modelo de Casos de UsoSemana 3
28/04 3/05Semana 5
11/06 17/06
Especificacin de Casos de UsoSemana 3
28/04 3/05Semana 5
11/06 17/06
Especificaciones AdicionalesSemana 3
28/04 3/05Semana 5
11/06 17/06
Anlisis / Diseo
Modelo de Anlisis / DiseoSemana 2
21/04 27/04Revisar en cada iteracin
Modelo de DatosSemana 2
21/04 27/04Revisar en cada iteracin
Implementacin
Prototipos de Interfaces de UsuarioSemana 3
28/04 3/05Revisar en cada iteracin
Modelo de ImplementacinSemana 3
28/04 3/05Revisar en cada iteracin
Pruebas
Casos de Pruebas FuncionalesSemana 3
28/04 3/05Revisar en cada iteracin
Despliegue
Modelo de DespliegueSemana 3
28/04 3/05Revisar en cada iteracin
Gestin de Cambios y ConfiguracinDurante todo el proyecto
Gestin del proyecto
Plan de Desarrollo del Software en su versin 2.0 y planes de las
IteracionesSemana 4
4/05 10/05Revisar en cada iteracin
AmbienteDurante todo el proyecto
4.3 Seguimiento y Control del Proyecto
Gestin de Requisitos
Los requisitos del sistema son especificados en el artefacto
Visin. Cada requisito tendr una serie de atributos tales como
importancia, estado, iteracin donde se implementa, etc. Estos
atributos permitirn realizar un efectivo seguimiento de cada
requisito. Los cambios en los requisitos sern gestionados mediante
una Solicitud de Cambio, las cuales sern evaluadas y distribuidas
para asegurar la integridad del sistema y el correcto proceso de
gestin de configuracin y cambios. Control de Plazos
El calendario del proyecto tendr un seguimiento y evaluacin
semanal por el jefe de proyecto y por el Comit de Seguimiento y
Control.Control de Calidad
Los defectos detectados en las revisiones y formalizados tambin
en una Solicitud de Cambio tendrn un seguimiento para asegurar la
conformidad respecto de la solucin de dichas deficiencias. Para la
revisin de cada artefacto y su correspondiente garanta de calidad
se utilizarn las guas de revisin y checklist (listas de
verificacin) incluidas en RUP.Gestin de Riesgos
A partir de la fase de Inicio se mantendr una lista de riesgos
asociados al proyecto y de las acciones establecidas como
estrategia para mitigarlos o acciones de contingencia. Esta lista
ser evaluada al menos una vez en cada iteracin. Gestin de
Configuracin
Se realizar una gestin de configuracin para llevar un registro
de los artefactos generados y sus versiones. Tambin se incluir la
gestin de las Solicitudes de Cambio y de las modificaciones que
stas produzcan, informando y publicando dichos cambios para que
sean accesibles a todo los participantes en el proyecto. Al final
de cada iteracin se establecer una baseline (un registro del estado
de cada artefacto, estableciendo una versin), la cual podr ser
modificada slo por una Solicitud de Cambio aprobada. 5.
Referencias
Pliego de Clusulas Tcnicas para la Definicin y Anlisis de los
Procedimientos del ES-NIC.
Desarrollo de una aplicacin informtica para el clculo del
personal necesario para la fabricacin de carroceras, utilizando la
metodologa RUP. P.F.C. de Ponz Lillo, Daniel. Visual Modeling with
Rational Rose and UML, Terry Quatrani. - Addison-Wesley.
Documentacin de Rational Unified Process, manuals de ayuda,
tutoriales, etc.
Odontomdica S.A.2013Pgina 3 de 13
