ReQ Resolución Directoraltransparencia.mtc.gob.pe/idm_docs/directivas/1_0_1889_.pdf · RUP)...
Transcript of ReQ Resolución Directoraltransparencia.mtc.gob.pe/idm_docs/directivas/1_0_1889_.pdf · RUP)...
Cakfl
1 COPIA FIEL DEL ORiGINAT
Ministerio de Transportes y ComUfl1Ca01es
Oficina General de Admiflistr1°n
FEL A11 CJFEOATAIO SUPLENTE
• R.M. N° 749 .2013 - MIS 10çFecha ................
ReQ ..........................
—
Resolución DirectoralLima, 13 de Enero de 2014
N000 lO-2014-MTC/10
\ IG
1ng
C)
CONSIDERANDO:
Que, mediante la Resolución Comisión de Reglamentos Técnicos y Comerciales N° 055-2006/1NDECOPI-CRT, publicada el 28 de julio de 2006, se aprobó, entre otras, la- Norma Técnica Peruana"NTP-ISO/IEC 12207: 2006. TECNOLOGÍA DE LA INFORMACIÓN. Procesos del ciclo de vida del software, 2Edición", la cual establece un marco de referencia para losprocesos del ciclo de vida del software en lasentidades de la Administración Pública integrantes del Sistema Nacional de Informática;
Que, el Ministerio de Transportes y Comunicaciones forma parte integrante del Sistema Nacional deInformática, generando información que constituye un activo importante y vital para el adecuadocumplimiento de las acciones que tiene a su cargo;
Que, de conformidad con lo dispuesto en el inciso m) del artículo 390 del Reglamento deOrganización y Funciones del Ministerio de Transportes y Comunicaciones, aprobado por Decreto Supremo N°021-2007-MTC, es función de la Oficina General de Administración, diseñar y ejecutar la estrategiainformática, así como coordinar y supervisar su implementación en el Ministerio, a través de la Oficina deTecnología de Información;
Que, en el marco de la NTP-ISO11EC 12207:2006, la Oficina de Tecnología de Información haelaborado el proyecto de Directiva "Metodología de Desarrollo del Software en el Ministerio de Transportes yComunicaciones", el cual establece la metodología de desarrollo de Software y el marco de trabajo paraestructurar, planificar y controlar el proceso de desarrollo o ciclo de vida del software en la entidad;
Que, por Resolución Secretarial N° 222-2007-MTC/04 del 16 de noviembre de 2007, se asignó a laOficina General de Administración a función de expedir directivas internas sobre los sistemas administrativos asu cargo, de alcance a todos los órganos y unidades orgánicas del Ministerio;
Que, en ese contexto, es necesario expedir el acto administrativo correspondiente;
De conformidad con lo establecido en la Ley N° 29370 - Ley de Organización y Funciones delMinisterio de Transportes y Comunicaciones, el Reglamento de Organización y Funciones del Ministerio deTransportes y Comunicaciones, aprobado por decreto Supremo N° 021-2007-MTC
SE RESUELVE:
Artículo 1.- Aprobarla Directiva N° 002-2014-MTC/10 "Metodología de Desarrollo de Software enel Ministerio de Transportes y Comunicaciones" y su Anexo N° 01, la misma que forma parte integrante de lapresente Resolución.
Artículo 2.- Disponer la publicación de la presente Directiva en la página web institucional(www.mtc.gob.pe), así como en el Registro de Directivas ubicado en la intranet del Ministerio de Transportes .yComunicaciones.
Regístrese y comuníquese
DIRECTOR GEÑAi()fittJ2 General de AdmlflI5tOt
DIRECTIVA N° OO2- - 2014-MTCL1O---- -
"METODOLOGÍA DE DESARROLLO DEL SOFTWARE EN EL MINISTERIO DETRANSPORTES Y COMUNICACIONES"
1. OBJETIVO
Adoptar una metodología para el ciclo de vida del software que la Oficina deTecnología de Información utilice en sus proyectos de desarrollo del software en elMinisterio de Transportes y Comunicaciones.
Establecer un marco de trabajo que permita estructurar, planear y controlar el procesode desarrollo del software, asegurando la calidad en las actividades de desarrollo,mantenimiento y soporte.
II. FINALIDAD
2.1 Garantizar la calidad de los productos y servicios proporcionados durante laejecución de los proyectos de desarrollo del software, dotando de un mayordinamismo a la Oficina de Tecnologías de Información, en relación al tiempo derespuesta de las necesidades de la organización.
2.2 Gestionar de manera eficiente al personal, recursos tecnológicos y los tiemposutilizados en los proyectos, dando mayor cumplimiento de los estándares ybuenas prácticas de la industria para el desarrollo del software.
2.3 Mejorar la productividad en los proyectos de desarrollo del software, optimizandola gestión de requerimientos, a través de una buena definición e integración delos roles participantes en el ciclo de vida del software.
I .\III. ALCANCE4T,er j
': T ) La presente directiva es de aplicación obligatoria por la Oficina de Tecnología deInformación de la Oficina General de Administración del Ministerio de Transportes yComunicaciones.
IV. BASE LEGAL
Ley N° 29370 - Ley de Organización y Funciones del Ministerio de Transportes yComunicaciones.
Decreto Supremo N° 021-2007-MTC - Reglamento de Organización ' y Funcionesdel Ministerio de Transportes y Comunicaciones.
Resolución de Contraloría N° 320-2006-CG - "Normas de Control Interno para elSector Público".
La Norma Técnica Peruana "NTP-lSO/IEC 12207:2006 TECNOLOGÍA DE LAINFORMACIÓN. Procesos del ciclo de vida del software. 2da. Edición".
1
V. DISPOSICIONES GENERALES
•1 y
' / Ü
5.1 Para los efectos de la presente Directiva, se emplearán las siguientesdefiniciones:
a) RUP (Rational Unified Process).- Es una de las metodologías basada enuna administración de requerimientos modelados a través de Casos de Usolos cuales usan el lenguaje UML, está centrado en la arquitectura, y esiterativo e incremental.
b) SCRUM.- Es un marco de trabajo para la gestión y desarrollo del softwarebasada en un proceso iterativo e incremental utilizado comúnmente enentornas basados en el desarrollo ágil del software.
UML.- Es el lenguaje de modelado de sistemas del software paraespecificar o para describir métodos o procesos. Es un lenguaje gráficopara visualizar, especificar, construir y documentar un sistema.
Desarrollador.- Es el responsable de llevar a cabo- las actividades dedesarrollo (incluyendo análisis de los requerimientos, diseño y pruebashasta la aceptación) durante el proceso del ciclo de vida del software.
Proceso.- Conjunto de actividades mutuamente relacionadas o queinteractúan, las cuales transforman elementos de entrada en resultados.
5.2 El Ministerio de Transportes y Comunicaciones utilizará como marco dereferencia la metodología Proceso Unificado Racional (Rational Unified Process -RUP) adaptando los conceptos de la metodología Scrum, a fin de lograr unametodología que se adapte a las necesidades de la institución. Estametodología se describe en el Anexo N° 01 de la presente directiva.
5.3 La Oficina de Tecnología de Información es la unidad orgánica responsable de laejecución de las actividades de desarrollo del software en el Ministerio deTransportes y Comunicaciones.
VI. DISPOSICIONES ESPECÍFICAS
6.1 Procedimiento para los requerimientos de desarrollo del Software
6.1.1 Los requerimientos de desarrollo del software deberán alinearse a losobjetivos y metas institucionales.
61.2 Los requerimientos de desarrollo de nuevos productos del software deberánser solicitados formalmente por el área usuaria del MTC (Vice Ministerio,Oficinas o Direcciones Generales) a la Oficina de Tecnología deInformación. El área usuaria del MTC deberán designar al responsable delrequerimiento y del producto resultante, a quien se le denominará "LíderUsuario".
6.1.3 Los requerimientos de mantenimiento y soporte de los sistemas deinformación existentes serán solicitados a través del procedimiento decontrol de cambios establecido por la Oficina de Tecnología de Información.El Líder Usuario será él responsable de autorizar los requerimientossolicitados.
c)
d)
e)
i 5 Gner ¿?)
2
6.1.4 Los requerimientos de desarrollo de nuevos productos software y demantenimiento y soporte de los sistemas de información existentes,deberán consignar la designación de la contrapartida técnica del áreausuaria, quien será responsable de brindar la conformidad de atención delrequerimiento.
6.1.5 El área usuaria solicitante deberá coordinar con la Oficina de Tecnología deInformación las condiciones, especificaciones y pruebas que deberáncontener los productos software para su validación, verificación y controlesde calidad por la Oficina de Tecnología de Información.
6.2 Evaluación y conformidad del Software
6.2.1 Recibido el requerimiento del área usuaria, la Oficina de Tecnología deInformación procederá a efectuar la evaluación técnica, económica yoperativa, con relación a los lineamientos establecidos por el Ministerio deTransportes y Comunicaciones.
62.2 La Oficina de Tecnología de Información en base a los resultados de laevaluación realizada, planificará el desarrollo del Sistema de Informaciónsolicitado o en su caso elaborará los términos de referencia para que éstesea desarrollado por un tercero.
6.2.3 Todo software desarrollado, que esté reemplazando a uno vigente deberáconsiderar la ejecución en paralelo de ambos hasta la conformidad del áreausuaria.
6.2.4 En el caso de que el desarrollo del software sea realizado por un tercero, laOficina de Tecnología de Información será responsable de dar laconformidad técnica del Sistema de Información desarrollado acorde con1G1-C.— los Términos de Referencia, para lo cual se deberán adoptar los controlesde prueba que garanticen su operatividad de acuerdo a los requisitosespecificados y con las necesidades o expectativas del área usuaria, quienserá la responsable de dar la conformidad funcional del Sistema deInformación.
6.2.5 Los plazos para el inicio o culminación del desarrollo del software se fijaránde común acuerdo con el área usuaria, en base al alcance, prioridad y a losrecursos disponibles. El cronograma será remitido por la Oficina deTecnología de Información al área usuaria para su aprobación.
VII. RESPONSABILIDAD
La Oficina de Tecnología de Información es responsable del cumplimiento de lapresente directiva.
'
3
rT/u cl
Anexo N° 01
1. Marco General de la Metodología de Desarrollo de Software
RUP propone una planeación inicial y posteriormente entra a un ciclo en las etapas dedesarrollo. Donde para cada iteración resulte una versión ejecutable del sistema. Lametodología se basa en una administración de requerimientos modelados a través decasos de uso, los cuales usan el Unified Modeling Language (UML) como lenguaje demodelado. Adicionalmente propone una arquitectura basada en componentes.
RUP comprende 2 flujos de trabajo a través de las cuales se establecen las disciplinas:
Proceso: Las etapas de esta sección son:
• Modelado de negocio• Requerimientos (también llamado Requisitos)• Análisis y Diseño• Implementación• Pruebas• Despliegue (también llamado Implantación)
Soporte: En esta parte nos encontramos con las siguientes etapas:
• Gestión del cambio y de la configuración• Gestión del proyecto• Entorno
La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollofundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases:
• Inicio (también llamado Incepción o Concepción).• Elaboración.• Desarrollo (también llamado Implementación o Construcción).• Cierre (también llamado Transición).
En la figurase muestra cómo varía el esfuerzo asociado a las disciplinas según la fase enla que se encuentre el proyecto.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia lacomprensión del problema y la tecnología, la delimitación del ámbito del proyecto, laeliminación de los riesgos críticos, y al establecimiento de una línea base de laarquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modeladodel negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al refinamiento del modelado delnegocio, los flujos de trabajo de requisitos, análisis, diseño y una parte de implementaciónorientado a la línea base de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del.producto por medio de unaserie de iteraciones.
' 0)1
4t)
i1cdeado del negocio
Requerimientos
Análisis y diseño
irnpIementaci
:Prueas
Despliegue
Gestión del cambio yde la configixración
Gestión del proyecto
Entorno
ItrtQr)ePrImTr2 .
: }
}
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseñoy se procede a su implementación y pruebas. Se realiza una pequeña cascada para cadaciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versióndel producto.
cIüy.e:derns
oRequlsitosk-. La p lanificación dÉla IteraciónEl ánáiis'is de: la iteración
-i Actividades.,espel^ific.as
naisis
/ 1 1
/ /
Diseño
1/ Impiemen-
/ tacidn 1
Prueba e1 ntegraci6ri
LJ
Una iteración"lteraci6n
En la fase de transición se pretende garantizar que se tiene un producto preparado parasu entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendode la fase el esfuerzo dedicado a una disciplina varía.
Di r'\ral
o
Aplicándole Agilidad a la Metodología
Con el objetivo de aplicarle agilidad a la metodología se han extraído los siguienteslineamientos de las metodologías ágiles como SCRUM para cumplir con los objetivospropuestos:
5
• El proyecto deberá ser ejecutado en iteraciones incrementales con una demostracióndel producto al finalizar cada iteración: con esta política, se conocerá el estado delproyecto, evaluando si los requisitos cumplen con las expectativas del cliente, si lacalidad es la esperada, o si hay retrasos; agilizando la toma de decisiones correctivas.
• El proyecto se ejecutará en iteraciones incrementales con una duración determinada deacuerdo a la naturaleza del proyecto. En términos generales se recomienda unaduración de 4 semanas.
• Los requisitos se desarrollarán priorizados por el valor aportado al cliente: Esta políticapermitirá que los objetivos más importantes del proyecto sean atendidos.
• El control y seguimiento del proyecto se basará en los requisitos completados en cadaiteración. Se entiende como un requisito, los entregables asociados a: análisis,desarrollo, pruebas, documentación, etc. e integrados con los entregables de lasiteraciones anteriores.
• Cada requisito debe ser independiente del resto de los requisitos, en la medida de loposible.
• Cada requisito debe ser demostrable, permitiendo cómo comprobar con el cliente queel requisito está completado y que se cumplen sus expectativas.
• El requisito debe ser de un grado de esfuerzo pata ser completado semejante al delresto de requisitos: de manera que la organización y el cliente, puedan realizar unaextrapolación del progreso del proyecto.
• Los componente de software, deberán ser desarrollados y liberados por partes, y noentregados al final del proyecto.
• El desarrollo de los componente de software que conformaran la solución, deberán serliberados en varias iteraciones.
• Cada iteración deberá producir software con calidad de producción, probado, integrado,y documentado (funcional, técnica).
• Cada iteración deberá cumplir con un subconjunto de requerimientos.
• Cada iteración deberá contemplar (análisis, diseño, codificación, pruebas,• documentación, etc.).
• Cada uno de los entregables, deberá contener scripts de pruebas unitarias, integrales,funcionales, etc.; mediante la utilización de frameworks.
• La documentación del proyectos, específicamente: manual de usuario, manual delsistema, documento de arquitectura, documento de requerimientos funcionales,documento de análisis, etc.; deberán ser entregables parciales para cada una de lasiteraciones, es decir, la documentación no se liberará al final del proyecto, sino enentregables parciales.
• Cada uno de los entregables, serán sometidos a un script de calidad, que ejecutará launidad responsable de la calidad, y no serán admitidos como productos del proyectohasta alcanzar un nivel aceptable.
•.4. • Los riesgos serán identificados en la primera iteración, llevándose a cabo también una
valoración inicial de la exposición al riesgo y planes de mitigación y contingencia Encada iteración se revisará y actualizará el documento "Plan de Gestión de Riesgos",añadiendo además la lista de riesgos más importantes actualizada por cada iteración.
Dir
o
6
e Cada uno de los artefactos del proyecto, deberán ser mantenidos bajo un sistema decontrol de versiones.
1.1. Procesos
El Proceso Unificado de Desarrollo de Software está compuesto de 9 procesos, loscuales son descritos en términos de actividades, flujos de trabajo, roles y documentosde trabajo (artefactos). A continuación describimos cada uno de los procesos:
1.1.1 Modelado de negocio
Este proceso tiene los siguientes objetivos:
• Entender la estructura y dinámica de la organización que albergará elsistema.
• Entender los procesos y procedimientos candidatos a automatizar.• Entender los problemas actuales en la organización e identificar posibles
mejoras.• Asegurar que tos clientes, usuarios finales del sistema y los miembros del
equipo de desarrollo tengan una misma visión acerca de la organización y desus procesos.
1.1.2 Requerimientos
Los objetivos de este proceso son:
• 'Establecer y mantener un acuerdo con los clientes y usuarios acerca de loque el 'sistema debería hacer.
• Entender los requerimientos del sistema.• Definir el alcance del proyecto.• Establecer una base para la estimación (iteraciones, coste y tiempo necesario
para desarrollar ersistema).
1.1.3 Análisis y Diseño
Este proceso tiene los siguientes objetivos:
• Transformar los requerimientos en modelos de diseño.• Desarrollar una arquitectura robusta para el sistema.• Adaptar el diseño al entorno de implementación.
1.1.4 Implementación
Los objetivos de este proceso son:
• Implementar tos elementos de diseño.• Test unitarios de los elementos implementados.• Integración de todo el sistema.
frk
Iu DirWt.% Gepral))
1.1.5 Pruebas
Este proceso tiene los siguientes objetivos:
7
• Encontrar y documentar fallos encontrados en el software (Control de
calidad).• Validar que el producto software tiene la funcionalidad diseñada.• Validad que los requerimientos han sido implementados de la forma
apropiada.
1.1.6 Despliegue
Los objetivos de este proceso son:
• Asegurar que el producto final esté listo para su distribución a los usuarios.• Asegurar una aceptación y adaptación sin complicaciones del software por
parte de los usuarios.
1.1.7 Gestión del cambio y de la configuración
Este proceso tiene los siguientes objetivos:
• Mantener la integridad de todos los artefactos que se crean en el proyecto.• Mantener la información del proceso evolutivo que han seguido los artefactos
de proyecto.
1.1.8 Gestión del Proyecto
Los objetivos de este proceso son:
• Conseguir equilibrar y completar los objetivos.• Administrar el riesgo y superar las restricciones para el desarrollo de un
producto acorde a los requisitos de los usuarios.
1.1.9 Ambiente o Entorno
Este proceso tiene los siguientes objetivos:
1.2 Fases
• Dar soporte al proyecto con las adecuadas herramientas, procesos y
métodos.• Definir la instancia concreta del proceso unificado que se va a seguir.
RUP divide el proceso en cuatro fases: inicio, elaboración, desarrollo y cierre dentro delas cuales se realizan varias iteraciones en número variable según el proyecto y en lasque se hace un mayor o menor hincapié en las distintas actividades.
1.2.1 Inicio
En esta fase se genera el alcance, criterios de aceptación, plan general yrecursos del sistema, de igual manera si es necesario se generará un modelo delnegocio. De igual forma, en esta fase se generará el plan de trabajo, iteraciones
y riesgos del proyecto.
8
• .. ...
1.2.2 Elaboración
En esta fase se desarrollan los planes a nivel detalle a seguir por el resto delProyecto, de igual manera se generan los documentos de requerimientos y deanálisis y diseño, los cuales contendrán el diagrama entidad/relación, losdocumentos de análisis y el diagrama de clases. Adicionalmente se actualizaránlos planes de riesgos e iteraciones del proyecto.
1.2.3 Desarrollo
El objetivo principal de esta fase es el desarrollo del sistema, a través de laprogramación orientada a objetos, arquitectura orientada a servicios y losdocumentos de análisis y diseño definidos previamente en la fase deelaboración, cubriendo los requerimientos del proyecto. De igual manera en estafase será ejecutado y documentado el conjunto de pruebas de aseguramiento decalidad y cualquier defecto encontrado será corregido y probado nuevamente.También serán actualizados los planes de riesgos e iteraciones como parte delas actividades de administración de Proyecto.
1.2.4 Cierre
La finalidad de esta fase es la-instalación y la puesta en producción del sistema,incluyendo la capacitación y entrenamiento a usuarios finales. También serealizará las actividades de migración de datos en caso de ser requerida.Finalmente se elabora el plan de despliego y el informe final del proyecto.
1.3 Roles
Los roles que son parte de la metodología se muestran en el cuadro siguiente:
c,'1-21
iJvfrk 1/
jiRECTOR,
Rol Descripción
LPY Líder de Proyecto
ARQ Arquitecto
AF Analista Funcional
AP Analista Programador
AD Analista de Datos
LPR Líder de Pruebas
EPR Ejecutor de Pruebas
LU Líder de Usuarios
USU Usuario
1.4 Artefactos
Los documentos (artefactos) que se deben generar como parte del proceso dedesarrollo del software son:
pir. Genral n
'Q
9
Nombre del Artefacto o Documento Rol Responsable
Acta de Constitución del Proyecto (Project Charter)
Plan de Gestión del Proyecto
Plan de Gestión de las Comunicaciones
Plan de Gestión de RiesgosPlan de Gestión de Tiempos
Plan de Gestión de RRHHPlan de Gestión de la Calidad
Plan de Gestión de AlcancePlan de Gestión de Cambios
Plan de Gestión de la ConfiguraciónDocumento de Requerimientos Funcionales
Documento de Requerimientos No Funcionales
Documento de Análisis
Documento de Arquitectura
Plan General de PruebasModelo de Estimación
Plan de Pruebas x Funcionalidad
Plan de Métricas
Diagrama de ClasesModelo Entidad - Relación
Actas de ReunionesInforme de Estado
Informe de Rendimiento de TrabajoInforme de Rendimiento del Proyecto
Informe de Rendimiento Final del Proyecto
Informe de Métricas del Proyecto
Log de Defectos
Informe de PruebasInforme de Lecciones Aprendidas
Manual de UsuarioManual del Sistema
Manual de InstalaciónDocumento de Pase a ProducciónPlan de Capacitación
Acta de Aceptación del ProyectoRelación de Documentos del Proyecto
Lista de Verificación de Cierre del ProyectoInforme Final del Proyecto
TOR
LPY,LU
LPY
LPY
LPY
LPY
LPY
LPY
LPYAF
LPY
LPY
AF,LU
LU,LP,AF
AFLU
ARO
LPREPR
LPY,AF
LPR,EPR
LPY
AF
AFD
LPY,ARQAFAP,AD,LPR,EPR,LU,USULPY
LPY
LPY
LPY
LPY
LPR,EPR
LPREPR
LPY,ARQ,AF,APAD,LPR,EPR,LU,USU
AP
APARO
APARO
APARO
LPYAP
LPY
LPY
LPY
LPY
f Dtrexo
-'o \
10
Ge ^,
• --.•-
1.5 Herramientas de Soporte
La metodología requiere herramientas para soportar todas sus actividades. Un procesoiterativo tiene requisitos especiales para su desarrollo, tales como una buenaintegración entre los modelos y el código fuente. También se necesita herramientaspara automatizar la documentación, y posiblemente automatizar las pruebas.
Las herramientas que necesitan ser utilizadas son:
• Una herramienta de manejo de requerimientos, para capturar, organizar y prionzartodos los requerimientos.
• Una herramienta de modelamiento visual para desarrollar los diferentes modelos ydiagramas.
e Una herramienta dé documentación, para soportar la documentación del proyecto.
• Una herramienta para la administración del proyecto, su planificación y elseguimiento del proyecto.
e Una herramienta para el control de versiones de los artefactos del proyecto.
e Una herramienta para el diseño de prototipos y codificación del producto.
e Una herramienta para la realización y automatización de pruebas.
e Una herramienta para el soporte y administración de los datos.
2 Descripción Detallada de la Metodología
Se describe las actividades a realizar en cada una de las fases utilizadas según lametodología propuesta. Cada desarrollo de software será considerado en la metodologíacomo un proyecto.
2.1 Fase de Inicio
El principal objetivo en esta fase inicial es alcanzar un acuerdo entre todos losinteresados respecto. a. los objetivos y al ciclo de vida del proyecto. La fase inicial es
muy significativa fundamentalmente en los esfuerzos de nuevos desarrollos, puescontemplan mucho más riesgos que deben abordarse antes de que el proyecto puedacontinuar. Para los proyectos que se centran en las mejoras de un sistema existente, lafase de inicio es más breve, pero sigue centrándose en garantizar que el proyecto esviable.
2.1.1 Actividades de la Fase
Las actividades a realizar en la fase de inicio se representan en el siguiente flujode trabajo:
-
11
o
:;VJ
f Dkk'rGeerl
Las actividades mostradas en la gráfica anterior se describen en el siguiente cuadro:
Nombre de Descripción Rol 1 Artefacto de Artefacto de SalidaActividad i Entrada
Concebir un Esta actividad recoge las necesidades Documento de Acta de Constitución delnuevo proyecto iniciales que justifican el proyecto. Solicitud Proyecto (Project Charter)
LPY (MemorándumEl Líder del Proyecto mediante etc.)entrevistas y consultas crea el Acta deconstitución del Proyecto.
Definir los Se desarrollan los planes del proyecto Acta de Acta de Constitución del
planes del con la participación del Líder de Constitución del Proyecto (Actualizado).
proyecto Usuarios (Cronogramas, con número LPY Proyecto (Project Plan de Gestión delde iteraciones, recursos, lista de AF Charter) Proyectoriesgos entre otros). Plan de Gestión de Riesgos
Plan de Gestión de laDe considerarse necesario (Cuando Calidadhay poco conocimiento de los procesosde negocio o los procesos no están Plan de Gestión de
documentados) debe realizarse un Tiempos
Modelo de Negocios. Plan de Gestión de lasComunicacionesPlan de Gestión de losRRHHPlan de Gestión delAlcance
Supervisar y Esta actividad es continua en el Acta de Plan de Iteracióncontrolar el proyecto, y consiste en el monitoreo del Constitución delproyecto avance del proyecto. LPY Proyecto
Plan de Gestióndel Proyecto
Definir el Mediante técnicas elegidas por el Estructura de Documento desistema Analista de Sistemas (entrevistas, Desglose de Requerimientos
cuestionarios, talleres) se obtienen con AF Trabajo Funcionalesprecisión los requerimientos del Plan de Iteraciónsistema.
Realizar la Se realiza la primera versión del Documento de Documento de Arquitecturasíntesis Documento de Arquitectura en donde Requerimientosarquitectónica se plantea la plataforma tecnológica a ARQ Funcionales
emplear y un esbozo de la arquitecturadel sistema (podrían emplearsediagramas de componentes y dedespliegue)
Definir la misión Se realiza el Plan de Pruebas Documento de Plan General de Pruebasde evaluación conteniendo los tipos de pruebas Requerimientos
necesarios para el tipo de desarrollo, LPR Funcionaleses admisible una versión en borradordel mismo para su posterior revisión.
Planear la Esta actividad crea el plan detallado Plan de Gestión Plan de Gestión delsiguiente para la siguiente iteración de esta fase; del Proyecto Proyecto (Actualizado)iteración de no ser necesaria otra iteración, se LPY .. Plan de Iteración
Plan de lteracionrealiza el plan de la pnmera iteracion (Actualizado)de la fase de elaboración.
13
arr2.1.2 Criterios de aceptación
• Acuerdo entre los interesados sobre el alcance y tiempos estimados delproyecto.
• Acuerdo en que ha sido capturado el conjunto correcto de requerimientos yque hay un entendimiento compartido de estos requerimientos (Documentode Requerimiento Funcionales).
• Acuerdo en que los tiempos estimados, prioridades, riesgos y proceso dedesarrollo son apropiados (Documento de Plan de Gestión de Proyecto).
• Se ha establecido las estrategias de mitigación para cada uno de los riesgos(Documento de Plan de Gestión de Riesgos).
• Revisión y validación (aprobación) por parte de los usuarios acerca de lafactibilidad de continuar con el desarrollo del proyecto.
Di
Fase de Inicio
LPY ARQ AF AP AD LPR EPR Tarea
• I ________
Inicio
Elaborar Acta de• Constitución del
• Proyecto
2 Elaborar Planes delProyecto
Elaborar Documento3 de Requerimientos
Funcional 1s
Elaborar icumentode RequerimientosNo Funcionales
Elaborar Documentode Arquitectura
Elaborar PlanGeneral de Pruebas
• Elaborar Plan deMétricas
Fin
14
LPY
cxniruo¿AP
la efcá
ARO
.AP
2.2 Fase de Elaboración
El propósito de la fase de elaboración es el establecimiento de una línea base para laarquitectura del sistema, la cual pueda soportar los esfuerzos de diseño eimplementación en la fase de desarrollo.
La arquitectura evoluciona a partir de la consideración de los requerimientos mássignificativos (los que tienen un gran impacto en la arquitectura del sistema) y unavaloración de los riesgos.
La estabilidad de la arquitectura se evalúa mediante uno o más prototiposarquitectónicos.
2.2.1 Actividades de la fase
La presente fase se compone de las siguientes actividades:
yY• AM
AF• AP
eedentro
.Tpy
plç*r 1a.sIeite
El detalle de las actividades se describe en la siguiente tabla:
15
Va
Íz
Di
1-,
Nombre de 1 1 Artefacto de
Descripción Rol Artefacto de EntradaActividad Salida
Esta actividad es constante en el LPY Plan de Gestión del Plan de GestiónGestión y soporte proyecto y consiste en la revisión Proyecto del Proyectocontinuos del avance del proyecto. (Actualizado)
Plan de IteraciónDe ser necesario se actualiza elPlan de Gestión del Proyecto.
Se abordan las actividades Documento de Documento deDesarrollar Requerimientos Análisisnecesarias para desarrollar LPY Funcionales (Actualizado)componentes componentes dentro del ámbito
identificado en el plan de ARQ Documento de Documento deiteración, es decir, los
AF Requerimientos no Diseñorequerimientos seleccionados a Funcionales (Actualizado)implementar en la iteración APactual. Plan de Iteración Sistema
Documento de Arquitectura generado
Diagrama Entidad-Relación
Documento de Análisis
Documento de Diseño
Se abordan las actividades AF Componentes Sistema deIntegrar y probar necesarias para integrar y probar pruebas
el producto por completo. AP Documento de AnálisisInforme de
LPR Plan General de PruebasSe efectúan las pruebas pruebasplanificadas para la iteración. EPR Plan de Pruebas por Log de defectosSi la prueba no es satisfactoria, Funcionalidad
se regresa a la actividad"Desarrollar Componentes"
Se especifican los AF Documento de Documento dePerfeccionar la requerimientos. Requerimientos Requerimientosdefinición del
Funcionales FuncionalesAl terminar esta fase, al menos elsistema
(Actualizado)80% de los requerimientosdeberán haberse descrito.
Se especifica la implementación ARQ Documento de Arquitectura Documento dePerfeccionar la de la arquitectura, teniendo Arquitecturaarquitectura presente los siguientes puntos: (Actualizado)
- Identificar los nuevos Prueba de
elementos que puedan Conceptosintegrarse con los elementosexistentes
- Reutilizar los componentesexistentes
Esta actividad crea el plan LPY Plan de Gestión del Plan de GestiónPlanear la detallado para la siguiente Proyecto del Proyectosiguiente iteración iteración de Elaboración; de no (Actualizado)
haber otra, se realiza el plan de la Plan de Iteraciónprimera iteración de Plan de IteraciónConstrucción. (Actualizado)
16
TD
IdÍO
jipy' RO
AF
drtro
Peer j
17
LPY
4
2.2.2 Criterios de aceptación
• El Plan de Gestión del Proyecto y el Documento de RequerimientosFuncionales aprobados.
• La arquitectura es estable (Documento de Arquitectura). Documento dearquitectura aprobado.
• Se ha definido un plan de pruebas (Plan General de Pruebas).
• Se considera que los mayores riesgos han sido mitigados.
e Los planes de iteración (cronograma, recursos) para la fase de construcciónson lo suficientemente detallados (Plan de Iteración - Fase Construcción -Iteración 01)
• Revisión y Validación (aprobación) por parte de los grupos interesados de laparte técnica propuesta por el proyecto.
2.3 Fase de Desarrollo
:. •; El objetivo de la fase de desarrollo es clarificar los requerimientos restantes y completarel desarrollo del sistema basándose en la arquitectura de línea base. La fase dedesarrollo es, de alguna manera, un proceso de fabricación, en el que se pone elénfasis en la gestión de los recursos y el control de las operaciones para optimizar loscostes, la planificación y la calidad. En ese sentido, las intenciones de gestión sufrenuna transición del desarrollo de la propiedad intelectual durante las fases: inicio yelaboración, hasta el desarrollo de productos desplegables durante la construcción y latransición.
2.31 Actividades de la fase
La presente fase se compone de las siguientes actividades:
Integrar y probar
Documento deRequerimientosFuncionales
Plan de IteraciónARQ Documento de
Arquitectura
AF Documento de
Análisis
Documento deDiseño
Manuales delSistema
Documento deAnálisis(Actualizado)
Documento deDiseño(Actualizado)
Sistemagenerado
Manuales delSistema(Actualizado)
LPY
AF Plan General de Informe dePruebas pruebas
Plan de Pruebas por Log de defectosFuncionalidad
El detalle de las actividades de la gráfica anterior se describe en la siguientetabla:
Nombre deActividad
Gestión y soportecontinuos
Descripción
Esta actividad es constanteen el proyecto y consiste enla revisión del avance delproyecto.
De ser necesario seactualizan el Plan de Gestióndel Proyecto.
RolArtefacto de Artefacto de
Entrada Salida
Plan de GestiónLPY Plan de Gestión del del Proyecto
Proyecto (Actualizádo)
Desarrollarcomponentes
Se abordan las actividadesnecesarias para desarrollarcomponentes dentro delámbito identificado en el plande iteración, es decir, losrequerimientos seleccionadospara implementar en laiteración actual.
Se abordan las actividadesnecesarias para integrar yprobar el producto porcompleto.
Se efectúan las pruebasplanificadas para la iteración.Si la prueba no essatisfactoria, se regresa a laactividad "DesarrollarComponentes"
Planear la Esta actividad crea el plansiguiente iteración detallado para la siguiente
iteración de Desarrollo; de nohaber otra, se realiza el plande la primera iteración deCierre.
LPY Plan de Gestión del Plan de GestiónProyecto del Proyecto
(Actualizado)
Plan de IteraciónPlan de Iteración(Actualizado)
1..1 c Di r'(.Get
2.3.2 Criterios de aceptación
• El producto es estable y maduro para ser instalado en un ambiente depruebas (Documento de Informe de pruebas).
• Todos los grupos interesados se encuentran listos para la transición dentro dela comunidad de usuarios (Plan de Capacitación del Sistema).
18
-•k•Ç./
• Resultados de las pruebas efectuadas, evidenciando que los resultadosobtenidos cumplen con los requerimientos funcionales, no funcionales, dearquitectura y diseño de software.
• Resultados de las pruebas efectuadas, evidenciando la no ocurrencia defallas en las pruebas técnicas y funcionales del sistema (Documento deInforme de pruebas).
(eICMjL •J
Fase de Desarrollo
1.; ARO AF: AP 7A LPR EPR
Inicio
1Definir/asignar
• Tareas
2 Elaborar Documentode Requerimiento
• Elaborar Documentode Analisis
--- Elaborar Documento- de Diseno
5 Diseñar Prototipos
+ -1-lmplementar Codigo
7 Realizar Pruebas
Unitarias
Realizar PruebasFuncionales
rElaborar Manuales
: -
Fin
19
2.4 Fase de Cierre
El objetivo de la fase de cierre es garantizar que el software esté disponible para losusuarios.
La fase de cierre puede contemplar varias iteraciones e incluye las pruebas delproducto en preparación para la puesta en producción, así como ajustes menoresbasados en la información de retorno de los usuarios.
En este momento, la información de retorno de los usuarios debe centrarseespecialmente en el ajuste del producto, los temas de configuración, instalación yutilización.
2.4.1 Actividades de ¡a fase
La presente fase se compone de las siguientes actividades:
+ AF
77 1-9
JAter lós Jalectisde tos:
ARO
1 T-41 AF
DesoIlarlos compcnit :restaiíes (déi*o• •darttoJ
AF
E.;.
*pis
1rer.y piob
OWIM y soMneriiiuos
1
• tiñaitsónl • PM
PIÑIénr 10:519~: CIUr. elFoyecto
{Fin :.eciónl ifldpt*1
Las actividades comprendidas en esta fase se describen en la siguiente tabla:
20
Nombre de Actividad Descripción
...,
RolArtefacto de Artefacto de
Entrada Salida
Gestión y soportecontinuos
Esta actividad es constante enel proyecto y consiste en larevisión del avance delproyecto.
De ser necesario se actualizanel Plan de Gestión delProyecto.
Plan de Gestión del Plan de Gestión delProyecto Proyecto
LPY (Actualizado)
Encontrando el sistema en unaetapa de prueba, se
Arreglar los defectos de solucionan los problemas quelos componentes pueden ir presentándose al
momento de probar losusuanos.
Esto sucede en el ambiente delOA.
AF 1 Informe de pruebas 1 Sistema Generado
1 Se abordan las actividades 1 LPY l Documento de 1 Sistema generado
Desarrollar los necesarias para desarrollar los 1 1 Requerimientos 1
1 componentes que quedan por 1 Funcionalescomponentes restantes realizar. ARQ Plan de Iteración
Documento deAF Arquitectura
Plan General de Informe de pruebasPruebas
1 7it Li, r
o
Se abordan las actividades 1 AF
Integrar y probar necesarias para integrar yprobar el producto (en el
1
ambiente de QA) por 1
1
completo.
Se efectúan las pruebasplanificadas para la iteración.
Si la prueba no essatisfactoria, se regresa a laactividad "DesarrollarComponentes"
Planear la siguiente 1 Esta actividad crea el plan J
LPY Plan de Gestión del 1 Plan de Gestión deliteración 1 detallado para la siguiente Proyecto 1 Proyecto
1 iteración de Construcción; de! 1Plan de iteración(Actualizado)
1 no haber otra, se realiza el 1 ¡
11 plan de la primera iteración de Plan de Iteración
1 Transición. 1 ¡ 1
(Actualizado)
Concluir el proyecto 1 En esta actividad, el Líder del 1 LPY 1 Plan de Gestión del 1 Documento de¡ Proyecto prepara el proyecto 1
1 Proyecto Entrega
1 para su conclusión; 1
1 Plan de iteración1 entregando lo pactado al Líder 1
1 de Usuarios 1
te
21
2.4.2 Criterios de aceptación
• La disposición, operación y funcionalidad de la solución y/o sistemadesarrollado en el ambiente de certificación (QA).
• La disposición, operación y funcionalidad de la solución yio sistemadesarrollado en el ambiente de producción.
• Manuales que satisfagan las necesidades de los usuarios y administradoresdel sistema.
• Capacitación y entrenamiento impartido para los diferentes tipos de usuarios.
• Evaluaciones aplicadas para cada curso o taller dictado.
• Informe Final del Proyecto.
2.5 Dependencia en la generación de documentos y artefactos
A continuación se muestran las dependencias existentes entre los principalesartefactos empleados en el proceso: -
(.S G
22
.;-_\ 14•
j" ) \