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


• 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


• 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


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


• 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


• 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


• 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


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

LFY

AF

(j)

- VI

Gen nal

L AF

De& el sIsexna AF lirsiín ieeICn

~Ir la tbg^qerée

RrL4et6rÍCa

• •.

12

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


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


• 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


+ 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


• 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" ) \

ReQ Resolución Directoraltransparencia.mtc.gob.pe/idm_docs/directivas/1_0_1889_.pdf · RUP)...

Documents

Transcript of ReQ Resolución Directoraltransparencia.mtc.gob.pe/idm_docs/directivas/1_0_1889_.pdf · RUP)...