ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/20010/1/CD-9450.pdf · De...

ESCUELA POLITÉCNICA NACIONAL

FACULTAD DE INGENIERÍA DE SISTEMAS

ASEGURAMIENTO DE CALIDAD BASADO EN CMMI EN LOS PROCESOS DE MANTENIMIENTO DE SOFTWARE PARA LA UNIDAD DE ANÁLISIS FINANCIERO

Y ECONÓMICO

TRABAJO DE TITULACION PREVIO A LA OBTENCIÓN DEL GRADO DE MAGISTER EN SOFTWARE MENCIÓN CALIDAD

MENDOZA COLIMBA XIMENA DE LOS ANGELES [email protected]

DIRECTOR: PhD. EDISON FERNANDO LOZA AGUIRRE [email protected]

QUITO, NOVIEMBRE 2018

I

CERTIFICACIÓN

Certifico que el presente trabajo fue desarrollado por Ximena de los Ángeles Mendoza

Colimba bajo mi supervisión.

________________________ PhD. Edison Loza Aguirre

DIRECTOR DE PROYECTO

II

DECLARACIÓN

Yo, Ximena de los Ángeles Mendoza Colimba, declaro bajo juramento que el

trabajo aquí descrito es de mi autoría; que no ha sido previamente presentada

para ningún grado o calificación profesional; y, que he consultado las referencias

bibliográficas que se incluyen en este documento.

A través de la presente declaración cedo mis derechos de propiedad intelectual

correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo

establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la

normatividad institucional vigente.

_________________________________________

Ing. Ximena de los Ángeles Mendoza Colimba

III

DEDICATORIA

A mi madre,

Porque con su ejemplo y

Enseñanzas me ha impulsado a seguir siempre adelante.

No le ha importado lo lejos o cerca que este de su lado

Sino que abra mis alas y vuele más alto.

Ximena Mendoza

IV

AGRADECIMIENTO

A Dios, por darme la maravillosa familia y permitirme llegar a cumplir una meta

más en mi vida.

A mi hermano que es mi ángel de la guarda porque siempre permanecerá vivo en

mi corazón.

A mis hermanos que me han enseñado que nunca uno deja de aprender.

A mis sobrinos porque con sus sonrisas me demuestran las cosas maravillosas

que tiene la vida, aunque conseguir un nuevo logro siempre significa un sacrificio.

A mis amigos, quienes me han inspirado a seguirme preparando, por los fueron y

los que son.

A todas esas personas que han dejado una enseñanza en mi camino.

Al PhD. Edison Loza, mi director de tesis, por el valioso tiempo dedicado y apoyo

durante el desarrollo de la misma.

A la Escuela Politécnica Nacional, por abrirme las puertas para compartir y

aprender las enseñanzas de cada uno de mis docentes, quienes han aportado

nuevos conocimientos y han despertado las ganas de investigar cada vez más.

A la Unidad de Análisis Financiero por permitirme realizar mi proyecto de

desarrollo.

A mis compañeros por sus comentarios e ideas.

V

No sé si este es el final de un reto o el inicio de otro, lo que si se es que cada día

Dios nos regala la oportunidad de seguir aprendiendo y ser cada día mejores

personas y profesionales.

Ximena Mendoza

VI

Contenido

1 Introducción ............................................................................................................................. 12

1.1 Antecedentes .................................................................................................................. 12

1.1.1 Descripción de la Empresa ....................................................................................... 12

1.1.2 Misión y Visión ............................................................................................................ 12

1.1.3 Valores ......................................................................................................................... 13

1.2 Planteamiento del Problema ......................................................................................... 15

1.3 Objetivos .......................................................................................................................... 16

1.3.1 Objetivo General ......................................................................................................... 16

1.3.2 Objetivos Específicos ................................................................................................. 16

1.4 Marco Teórico ................................................................................................................. 17

1.4.1 CMMI ............................................................................................................................ 17

1.4.2 SCAMPI........................................................................................................................ 23

1.4.3 Mantenimiento de Software ...................................................................................... 24

2 Metodología ............................................................................................................................. 27

2.1 Ciencia del Diseño ............................................................................................................... 27

2.1.1 Ciclo de Relevancia...................................................................................................... 28

2.1.2 Ciclo de Rigor ................................................................................................................ 28

2.1.3 Ciclo de Diseño ............................................................................................................. 29

2.2 Diagnóstico ........................................................................................................................... 30

2.3 Elaboración de la Propuesta .............................................................................................. 33

2.4 Evaluación ............................................................................................................................. 41

3 Resultados y Discusión ......................................................................................................... 44

4 Conclusiones y Recomendaciones ...................................................................................... 50

4.1 Conclusiones ........................................................................................................................ 50

4.2 Recomendaciones ............................................................................................................... 51

5 Referencias Bibliográficas ......................................................................................................... 52

6 Anexos .......................................................................................................................................... 55

ANEXO I: ENTREVISTAS REALIZADAS .................................................................................. 55

ANEXO II: GUIA DE CODIFICACION DE ENTREVISTAS ..................................................... 55

ANEXO III: REQUERIMIENTOS Y AREAS DEL PROCESO CMMI ..................................... 55

VII

ANEXO IV: PROCESO DE GESTIÓN DE LA CONFIGURACIÓN ........................................ 56

ANEXO V: PROCESO DE MEDICIÓN Y ANALISIS ................................................................ 85

ANEXO VII: PLAN DEL PROYECTO ....................................................................................... 111

ANEXO VIII: PROCESO DE GESTIÓN DE REQUERIMIENTOS ........................................... 5

ANEXO IX: PLAN DE FORMACION ........................................................................................... 20

ANEXO X: PROCESO DE MANTENIMIENTO ......................................................................... 31

ANEXO XI: PROCESO DE ASEGURAMIENTO DE CALIDAD.............................................. 43

ANEXO XII: ENTREVISTA DE EVALUACION ............................. ¡Error! Marcador no definido.

VIII

INDICE DE TABLAS

Tabla 1 Representaciones - Niveles................................................................................................... 22

Tabla 2 Guía de Codificación ............................................................................................................. 32

Tabla 3 Resumen Entrevistas ............................................................................................................ 33

Tabla 4 Puntos Importantes SISLAFT ................................................................................................. 34

Tabla 5 Matriz de impacto - Proceso de Mantenimiento ................................................................. 35

Tabla 6 Matriz de Impacto – Sistema ................................................................................................ 36

IX

INDICE DE FIGURAS

Fig. 1 Estructura Institucional [4] .................................................................................................. 14

Fig. 2 Evolución de CMMI [6]........................................................................................................ 18

Fig. 3 Componentes del modelo CMMI [10] ............................................................................... 20

Fig. 4 Tres Dimensiones Críticas [10] ......................................................................................... 21

Fig. 5 Estructura de las Representaciones [10] ......................................................................... 22

Fig. 6 CMMI Representaciones y Niveles[10] ............................................................................ 22

Fig. 7 Fases del Mantenimiento [13] ........................................................................................... 26

Fig. 8 Ciclos de la Ciencia del Diseño [16] ................................................................................. 27

Fig. 9 Modelo de Aceptación de Tecnologías TAM [28] .................................................................... 43

X

RESUMEN

El proyecto de desarrollo contiene la propuesta del catálogo de procesos basados en

CMMI para asegurar la calidad en las tareas de mantenimiento de software de la UAFE,

que permite a los desarrolladores tener una línea base de los procesos que se deben

llevar en el mantenimiento de software para cumplir estándares de calidad del producto y

del proceso precautelando el deterioro del software.

En este proyecto se aplicó la metodología Ciencia del Diseño, con la cual fue posible

llegar a establecer la propuesta planteada. Lo que primero se realizó fue establecer el

diagnóstico del proceso de mantenimiento apoyado en entrevistas, y en base a esto se

estableció las necesidades y se desarrolló la propuesta, la misma que fue evaluada por el

grupo focal seleccionado.

El presente proyecto se resume de la siguiente forma:

Capítulo I: Contiene la introducción del proyecto de desarrollo, definición y áreas de

proceso de CMMI, modelo de evaluación SCAMPI, los fundamentos del mantenimiento de

Software, factores claves, técnicas, estándares, metodologías y tipos de mantenimiento

que existen.

Capítulo II: Contiene la metodología con la cual se ha realizado el proyecto de desarrollo,

con la descripción de cada uno de los ciclos de la Ciencia del Diseño y la elaboración de

la propuesta.

Capítulo III: Contiene el análisis y discusiones de los resultados una vez presentada la

propuesta.

Capítulo IV: Este capítulo contiene las Conclusiones y Recomendaciones obtenidas en el

desarrollo del proyecto.

Palabras clave: proceso de mantenimiento de software, cmmi, áreas de proceso cmmi, calidad del producto, aseguramiento de calidad.

XI

ABSTRACT

The development project contains the proposal of the catalog of processes based on

CMMI to ensure the quality of software maintenance tasks of the UAFE, which allows

developers to have a baseline of the processes that must be carried out in software

maintenance to meet product and process quality standards by taking care of software

deterioration.

In this project, the Science of Design methodology was applied, with which it was possible

to establish the proposed proposal. The first steps to establish the diagnostic of the

maintenance process was supported by interviews, and based on this the needs were

established and the proposal was developed, which was evaluated by the selected focus

group.

The present project is summarized as follows:

Chapter I: This chapter contains the introduction of the development project, definition and

process areas of CMMI, SCAMPI evaluation model, the fundamentals of software

maintenance, key factors, techniques, standards, methodologies; and types of

maintenance that exist.

Chapter II: This chapter contains the methodology with which the development project has

been carried out, with the description of each one of the cycles of the Science of Design

and the elaboration of the proposal.

Chapter III: This chapter contains the analysis and discussions of the results once the

proposal was presented.

Chapter IV: This chapter contains the Conclusions and Recommendations obtained in the

development of the project.

Keywords: software maintenance process, cmmi, cmmi process areas, product quality,

quality assurance.

12

1 Introducción

1.1 Antecedentes

1.1.1 Descripción de la Empresa

La Unidad de Análisis Financiero y Económico (UAFE) es la institución del estado

ecuatoriano responsable de la recopilación de información, elaboración de reportes, ejecución

de las políticas y estrategias nacionales de prevención y erradicación del lavado de activos y

financiamiento de delitos [1].

De acuerdo al artículo 12 de la Ley Orgánica de Prevención, Detección y Erradicación del

Delito de Lavado de Activos y del Financiamiento de Delitos, la UAFE tiene entre sus funciones

más importantes [2]:

· Planificar programas y ejecutar acciones que permitan detectar aquellas operaciones y

transacciones inusuales e injustificadas que pueden ser producto de un delito

precedente1 y terminar siendo un caso de lavado de activos o financiamiento del

terrorismo.

· Agregar nuevos sectores económicos considerados vulnerables en los cuales el lavador

puede ingresar dinero producto del lavado de activos o terrorismo y blanquearlo.

· Enviar a la Fiscalía General del Estado, aquellos casos que se determinen como

operaciones inusuales e injustificadas e información necesaria.

· La información recopilada es de carácter reservado

· Expedir la normativa correspondiente con el fin de cumplir lo atribuido a la UAFE por

ley.

1.1.2 Misión y Visión

Así la misión de la UAFE ha sido definida como sigue:

1 Delito precedente. – Se define a aquella conducta criminal subyacente que genera el producto susceptible de ser lavado.

13

“Liderar la lucha coordinada contra el lavado de activos y el financiamiento del terrorismo,

mediante la formulación de políticas y generación de reportes de análisis financiero confiables,

reservados y oportunos, para contribuir al fortalecimiento y transparencia del sistema

económico social sostenible y a construir un Estado democrático para el Buen Vivir [3].”

Mientras que la visión se establece como:

“Ser una institución altamente especializada y competitiva, reconocida a nivel nacional e

internacional, en permanente innovación tecnológica, basada en análisis de riesgos contra el

lavado de activos y el financiamiento del terrorismo [3].”

1.1.3 Valores

· Transparencia.- Decir siempre la verdad.

· Honestidad.- Hacer las cosas a conciencia.

· Profesionalismo.- Principios profesionales y prácticas óptimas.

· Responsabilidad.- Cumplir con nuestro trabajo de forma oportuna, garantizando el bien común.

La UAFE se encuentra estructurada, como se ilustra en la figura 1.

14

Fig. 1 Estructura Institucional [4]

Dentro de los procesos sustantivos bajo la Coordinación Técnica de Prevención, Análisis de

Operaciones y Seguridad de la Información – CTPOSI, se encuentran las siguientes

direcciones:

15

• Dirección de Análisis de Operaciones (DAO). - Se encarga del análisis de la

información proporcionada por los sujetos obligados y las unidades complementarias,

para detectar posibles casos de lavado de activos, así como generar reportes de

carácter reservado para ser remitidos a la Fiscalía General del Estado.

• Dirección de Prevención (DP). - Se encarga de la administración de sujetos obligados,

es decir, creación de códigos de registro, registro y actualización de oficiales de

cumplimiento, asesoramiento a los sujetos obligados en lavado de activos e

información a reportar de cada sector, entre otros temas relacionados con el lavado de

dinero y terrorismo.

• Dirección de Seguridad de la Información y Administración de Tecnologías (DSIT). -

Se encarga de la gestión de los sistemas institucionales para garantizar el correcto

funcionamiento de los mismos.

Para que la UAFE cumpla con las atribuciones entregadas mediante mandato se apoya con el

Sistema Para la Prevención de Lavado de Activos y Financiamiento de Delitos – SISLAFT.

Este software permite la recopilación de información entregada por los sujetos obligados2, la

misma que es analizada por los analistas de la UAFE.

1.2 Planteamiento del Problema

Como se menciona en los antecedentes, la UAFE es la entidad estatal responsable de la

recopilación de información, realización de reportes, ejecución de las políticas y estrategias

nacionales de prevención y erradicación del lavado de activos y financiamiento de delitos.

Para cumplir con la misión de la institución y las funciones atribuidas a ésta por mandato legal,

la Dirección de Seguridad de la Información y Administración de Tecnologías es la encargada

dentro de la UAFE de la gestión de los sistemas de la información, así como de las tareas de

desarrollo y mantenimiento de software. En este sentido, el proceso de mantenimiento de

software constituye un pilar fundamental para el desarrollo institucional de la UAFE, ya que el

2 Sujetos Obligados.- Se considera a todos los sectores económicos obligados a informar mensualmente a la Unidad de Análisis Financiero y Económico (UAFE) como lo señala la Ley de Prevención, Detección y Erradicación del Delito de Lavado de Activos y del Financiamiento de Delitos.

16

software al cuál se le da mantenimiento es indispensable para que la UAFE pueda cumplir con

las obligaciones que tiene atribuidas.

No obstante, mediante conversaciones previas con el área de desarrollo y las áreas requirentes

se desprende que hoy, las actividades de mantenimiento de software de la UAFE no tienen

procesos establecidos ni documentados, lo que genera demora e inexactitud en la definición de

nuevos requerimientos, falla de priorización y requerimientos cambiantes por parte de las

diferentes áreas, lo cual se evidencia en las entrevistas en el Anexo I.

El presente proyecto busca solucionar este problema mediante la definición de los procesos

necesarios para garantizar que el mantenimiento de software cumpla su función dentro de la

UAFE. Los procesos por proponerse se basarán en el modelo CMMI con el objetivo de

asegurar la entrega de versiones del software con calidad, lo cual representará un ahorro en

tiempo y recursos a la institución, además de una mejora constante en el proceso. También, se

espera que el desarrollo de esta propuesta permita a la UAFE garantizar mejoras en la

disponibilidad en sus sistemas y extender el ciclo de vida de los mismos.

1.3 Objetivos

1.3.1 Objetivo General

Proponer un catálogo de procesos basados en CMMI para asegurar la calidad en las tareas de

mantenimiento de software de la UAFE.

1.3.2 Objetivos Específicos

Identificar los requerimientos de mantenimiento de software de la UAFE.

Identificar las recomendaciones existentes en la literatura y que permitan desarrollar procesos

de mantenimiento de calidad.

Elaborar una propuesta de los procesos de mantenimiento basados en el modelo CMMI

17

Realizar un análisis sobre la validez de los procesos en función de los requerimientos de la

UAFE.

1.4 Marco Teórico

El presente proyecto está enfocado en el aseguramiento de la calidad de los procesos de

mantenimiento basados en el Modelo de Madurez de Capacidades de Integración (CMMI).

Para lo cual es importante definir conceptos como: CMMI, el proceso de mantenimiento, y el

método de evaluación de CMMI SCAMPI.

1.4.1 CMMI

CMMI es una evolución de CMM, que nace debido a la necesidad de integrar los modelos de

madurez para la capacidad de software, ingeniería de sistemas y desarrollo integrado de

programas. El objetivo principal de este modelo es ayudar a las instituciones a mejorar los

procesos en la entrega de productos de calidad a sus clientes. [10]

Como se ilustra en la figura 2 CMMI ha evolucionado hasta llegar a proponer buenas prácticas

mediante modelos para diferentes finalidades:

· CMMI-DEV. - Proporciona una guía para aplicar buenas prácticas en una organización

de desarrollo. Se centra en las actividades relacionadas con el desarrollo de productos y

servicios de calidad que cubran las necesidades de sus clientes y usuarios finales.

· CMMI-SVC. - Proporciona guías para aplicar las buenas prácticas en una organización

cuya finalidad sea el proveer servicios. Las buenas prácticas de este modelo se enfocan

en las actividades para proveer servicios de calidad a clientes y usuarios finales.

· CMMI-ACQ. - Es una guía que describe prácticas que se utilizan para la adquisición de

productos o servicios.

18

Fig. 2 Evolución de CMMI [6]

Con base en los conceptos analizados anteriormente, la UAFE se adapta al Modelo de

Madurez y Capacidad CMMI-DEV. Si bien la institución no es una empresa de desarrollo de

software, pero cuenta con un sistema para la Prevención de Lavado de Activos y

Financiamiento de Delitos - SISLAFT, el mismo que fue desarrollado a la medida de las

necesidades institucionales. Dicho software cuenta con información confidencial y reservada,

por lo cual requiere que la institución cuente con un proceso de mantenimiento de calidad que

cumpla con las normas y estándares para este fin.

Áreas de Procesos

El Software Engineering Institute (SEI), ha identificado varias dimensiones en las que una

organización puede centrarse para mejorar su actividad. La figura 4 - muestra las tres

dimensiones críticas: las personas, los métodos y procedimientos, y el equipamiento y

herramientas. Cada una de estas dimensiones representa a las diferentes partes

fundamentales de las empresas, y todas son importantes, ya que en caso de que falte alguna

de estas tres puede ocasionar el incumplimiento de los objetivos planteados [10].

Las 22 áreas de proceso que tiene CMMI se encuentran distribuidas de la siguiente forma:

· 16 áreas de proceso base.- Estas áreas se aplican a cualquiera de los tres modelos

(adquisición, servicio o desarrollo),

o Análisis Causal y Resolución (CAR).

o Gestión de Configuración (CM).

o Análisis de Decisiones y Resolución (DAR).

o Gestión Integrada del Proyecto (IPM).

19

o Medición y Análisis (MA).

o Definición de Procesos de la Organización (OPD).

o Enfoque en Procesos de la Organización (OPF).

o Gestión del Rendimiento de la Organización (OPM).

o Rendimiento de Procesos de la Organización (OPP).

o Formación en la Organización (OT).

o Monitorización y Control del Proyecto (PMC).

o Planificación del Proyecto (PP).

o Aseguramiento de la Calidad del Proceso y del Producto (PPQA).

o Gestión Cuantitativa del Proyecto (QPM).

o Gestión de Requisitos (REQM).

o Gestión de Riesgos (RSKM).

· 1 área de proceso compartida con CMMI-SCV

o Gestión de Acuerdos con Proveedores (SAM).

· 5 áreas de proceso específicas de desarrollo.

o Desarrollo de Requisitos (RD).

o Solución Técnica (TS).

o Validación (VAL).

o Verificación (VER).

o Integración del Producto (PI).

Todas las prácticas del modelo CMMI-DEV se centran en las actividades de la institución

desarrolladora. Cinco áreas de proceso se centran en las prácticas específicas del desarrollo y

mantenimiento: tratando desarrollo de requisitos, solución técnica, integración del producto,

verificación y validación [8].

CMMI contiene tres tipos de componentes:

20

Fig. 3 Componentes del modelo CMMI [10]

Cada una de las áreas de proceso contiene un propósito, notas introductorias, áreas de

procesos relacionados, metas específicas, metas genéricas, prácticas específicas y prácticas

genéricas, las mismas que se describen a continuación.

Componentes Requeridos

• Necesarios para lograr la mejora en el proceso. Son las metas específicas y genéricas.

Componentes Esperados

• Importantes para lograr un componente CMMI. Son las prácticas específicas y genéricas.

Componentes Informativos

• Ayudan a los usuarios del modelo a comprender los componentes CMMI requeridos y esperados. Estos componentes pueden ser ejemplos en un recuadro, explicaciones detalladas u otras informaciones útiles.

21

Componentes Informativos:

· Propósito. - Describe la finalidad del área del proceso.

· Notas introductorias. - Describe los conceptos principales cubiertos por el área de

proceso.

· Áreas de proceso relacionadas. - Enumera las áreas de proceso relacionadas y

refleja las relaciones de alto nivel entre las áreas de proceso.

· Metas específicas. - Describe las características únicas que deben estar presentes

para satisfacer el área de proceso.

Fig. 4 Tres Dimensiones Críticas [10]

Componentes Requeridos

· Metas genéricas. - Describe las características que deben estar presentes para

institucionalizar los procesos que implementan un área de proceso. Estas metas se

aplican a múltiples áreas de proceso. Se utiliza en las evaluaciones para determinar si

se satisface un área de proceso.

Componentes Esperados

· Prácticas específicas. - Es la descripción de una actividad importante para lograr la

meta específica asociada. Las prácticas específicas describen las actividades que se

espera que produzcan el logro de las metas específicas de un área de proceso.

· Subprácticas. - Proporciona orientación de forma detallada para interpretar e

implementar una práctica específica o genérica.

· Prácticas genéricas. - La misma práctica se aplica a múltiples áreas de proceso. Las

prácticas genéricas asociadas con una meta genérica describen las actividades que se

22

consideran importantes para lograr la meta genérica y contribuir a la institucionalización

de los procesos asociados con un área de proceso.

La implementación de CMMI puede ser llevada a cabo mediante dos aproximaciones conocidas

también como representación. La representación continua corresponde a una aproximación

que involucra un área de proceso individual. La representación por etapas que corresponden a

Niveles de madurez caracteriza el estado global de los procesos de la organización con

respecto al modelo como un todo. Ambas representaciones se muestra en la figura 5.

Estructuras de las representaciones continua y por etapas

Representación Continua Representación por etapas

Fig. 5 Estructura de las Representaciones [10]

Ambas representaciones conducen a, un fin común [SEI, 2006] [Piattini, 2007].

En la tabla 1 se presenta estos dos tipos de representaciones con el nivel correspondiente a

cada una de ellas:

Tabla 1 Representaciones - Niveles

Nivel Representación Continua Representación por Etapas

0 1 2 3 4 5

Incompleto Se realiza Gestionado Definido Gestión Cuantitativa Optimizado

No Aplicable Inicial Gestionado Definido Gestión Cuantitativa Optimizado

Fig. 6 CMMI Representaciones y Niveles [10]

23

1.4.2 SCAMPI

SCAMPI es el método de evaluación oficial para CMMI. SCAMPI tiene varias clases de

evaluaciones: SCAMPI clase A, B y C. La clase A se utiliza para liberar resultados y niveles, las

clases B y C son menos rigurosas y generalmente se utilizan para diagnósticos iniciales y de

seguimiento [9].

Para realizar una evaluación basada en CMMI se debe considerar lo siguiente:

• Selección del Modelo CMMI.

• Definición del alcance de la evaluación, el mismo que debe incluir la unidad o área de

la organización a evaluar, las áreas de proceso de CMMI y el nivel de madurez o niveles

de capacidad a evaluar.

• Método de evaluación.

• Líder del equipo de evaluación y miembros del equipo.

• Participantes de la evaluación a entrevistar seleccionados de las entidades de la

evaluación.

• Resultados de la evaluación (p. ej., calificaciones, hallazgos específicos de la

instanciación).

• Restricciones de la evaluación (p. ej., tiempo dedicado in situ).

El documento de definición del método (MDD) de SCAMPI permite la selección de opciones

previamente establecidas para utilizar en una evaluación. Estas opciones de evaluación están

creadas para ayudar a las instituciones las necesidades de negocio y objetivos con CMMI.

Los planes y los resultados de la evaluación de CMMI deberían incluir una descripción de las

opciones de evaluación, del alcance del modelo y del alcance seleccionado de la organización.

Esta documentación confirma si una evaluación cumple con los requisitos para el

benchmarking [10].

Para organizaciones que deseen evaluar varias funciones o grupos, el enfoque integrado de

CMMI permite la formación en el modelo y en la evaluación. Un método de evaluación puede

proporcionar resultados separados o combinados para varias funciones [10].

24

Al seguir una evaluación para CMMI es necesario tener los siguientes principios [10]:

• Patrocinio de la alta dirección.

• Enfoque en los objetivos de negocio de la organización.

• Confidencialidad para los entrevistados.

• Utilización de un método documentado de evaluación.

• Utilización de un modelo de referencia de procesos (p. ej., un modelo CMMI).

• Enfoque de equipo colaborativo.

• Enfoque en acciones para la mejora de procesos.

Una evaluación mediante CMMI permitirá a la institución detectar posibles riesgos en el equipo

de desarrollo, así como las debilidades y fortalezas con lo cual se puede mejorar cada uno de

los procesos [10].

1.4.3 Mantenimiento de Software

Software.- Es el conjunto de los programas de cómputo, procedimientos, reglas,

documentación y datos asociados que forman parte de las operaciones de un sistema de

computación (extraído del estándar 729 del IEEE) [11].

Todo software, en su creación y desarrollo, cumple etapas, conocidas como las fases del ciclo

de vida del software, dentro de la ingeniería del software. El objetivo de la ingeniería del

software es proporcionar un marco de trabajo para construir software con mayor calidad. El

término “ciclo de vida del software” describe el desarrollo del mismo, desde la fase de inicio

hasta la fase de fin. El propósito de este modelo es definir las distintas fases intermedias que

se requieren para la validación del desarrollo de la aplicación, es decir que garantice que el

software cumpla los requisitos del mismo definidos por el cliente y la verificación de los

procedimientos de desarrollo asegurando que los métodos utilizados sean los adecuados. [12]

Este proceso inicia de la definición de necesidades y el análisis de las especificaciones del

software que se va a crear. Si en estas fases previas se comete algún error y es detectado a

tiempo puede ser corregido en las siguientes fases, caso contrario puede ocasionar

inconvenientes, puesto que los errores mientras más tiempo tomen en identificarse son más

costosos de rectificar. El ciclo de vida permite que los errores se detecten lo antes posible y,

por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos

de implementación y en los costes asociados [12].

25

Una vez entregado el producto puede requerir cambios, por lo cual es necesario el

mantenimiento del software. El proceso de mantenimiento contiene las actividades y tareas del

mantenimiento. La IEEE1219 define mantenimiento de software como “la modificación de un

producto de software después de colocarlo en producción para corregir fallas, mejorar el

rendimiento u otros atributos, o para adaptar el producto a una modificación del medio

ambiente” [13].

El proceso de mantenimiento se encuentra dividido en fases, es iterativo y en cascada, con

una gran semejanza al ciclo de vida del desarrollo clásico, como se ilustra en la figura. 7.

Existen varios estándares que tratan el mantenimiento del software como son el ISO/IEC 14764

o el IEEE 1219. Con base en estos estándares se definen varios tipos de mantenimiento del

software [13] [14]:

Mantenimiento adaptativo.- Este tipo de mantenimiento se lo utiliza cuando es

necesaria la modificación del software para ampliar sus funciones o adaptarse a las

nuevas necesidades del cliente. Muchos de estos cambios se dan debido a cambios

tecnológicos, dentro de la institución puede darse este tipo de mantenimiento debido a

los cambios en las leyes.

Mantenimiento reactivo o correctivo.- Este tipo de mantenimiento aplica en caso de

detectarse fallos, analizarlos y solventarlos. Los tipos de fallos que pueden presentarse

en este tipo de mantenimiento son errores funcionales, el software no realiza lo que el

usuario espera, otros fallos son fallos técnicos o estructurales debidos a un fallo de

diseño o a una mala programación.

Mantenimiento preventivo o planificado.- Este tipo de mantenimiento se realiza

antes de cualquier fallo o avería del software, bajo condiciones controladas, es decir son

ejecutados mediante un plan de mantenimiento previamente establecido.

26

Fig. 7 Fases del Mantenimiento [13]

Mantenimiento emergente.- Este tipo de mantenimiento aplica cuando se tiene que

ejecutar actividades de forma inmediata, debido a que alguna falla no permite el

funcionamiento correcto del software por lo cual se debe actuar en forma emergente y

en el mejor de los casos bajo un plan de contingencia.

Identificación del Problema

Análisis

Diseño

Implementación

Pruebas del Sistema

Puesta en Producción

27

2 Metodología

2.1 Ciencia del Diseño

Para el desarrollo del presente proyecto se utilizará la metodología de investigación Ciencia

del Diseño, aplicada sobre un estudio de caso único. El principio fundamental de investigación

de la Ciencia del diseño es que tanto el conocimiento y la comprensión de un problema de

diseño, como la solución del problema en sí, se adquieren mediante la construcción de un

artefacto [15] [16] [17].

Fig. 8 Ciclos de la Ciencia del Diseño [16]

La figura 8 muestra una aproximación de la Ciencia del Diseño [16] supone un enfoque en

tres ciclos de investigación inherentes. El ciclo de relevancia

enlaza el entorno contextual del proyecto de investigación con las tareas de la ciencia del

diseño. El Ciclo de rigor enlaza las actividades científicas de diseño con la

base de conocimientos de fundamentos científicos y experiencia que

informa el proyecto de investigación. El ciclo de diseño central itera entre

actividades centrales de construcción y evaluación de artefactos de diseño y procesos de la

investigación. Estos tres ciclos deben estar presentes y claramente identificables en un

proyecto de investigación de ciencia del diseño. A continuación se detalla cada uno de los

ciclos de la ciencia del diseño.

28

2.1.1 Ciclo de Relevancia

La investigación enmarcada en la Ciencia del Diseño está determinada por el deseo de

mejorar un contexto mediante la aplicación de los procesos para construir estos artefactos

[18]. Dentro del ciclo de relevancia se define el dominio de aplicación de la investigación,

mismo que consiste en personas, sistemas organizacionales y sistemas técnicos que trabajan

en conjunto por un objetivo en común. La investigación ciencia del diseño comienza

regularmente identificando y representando oportunidades y problemas en un entorno de

aplicación real.

Por lo tanto, el ciclo de relevancia inicia la investigación con un entendimiento del contexto

que no solo proporciona los requisitos para la investigación como entradas, sino también

define los criterios de aceptación para la evaluación final de los resultados de la investigación.

El resultado de la investigación ciencia del diseño debe devolverse al entorno para estudio y

evaluación en el dominio de la aplicación. El estudio de campo del artefacto puede ser

ejecutado por medio de métodos apropiados de transferencia de tecnología como la

investigación-acción [19] [20].

Es así como el artefacto generado puede presentar problemas en cuanto a su

funcionamiento o sus características esenciales (por ejemplo, rendimiento, facilidad de uso)

que puede limitar su utilidad en la práctica. El resultado de las pruebas de campo puede

evidenciar la definición de requerimiento de entrada incompleta o mal definido, con lo cual el

artefacto no lograría satisfacer las necesidades o cubrir los problemas presentados [21].

Producto de esto se debería realizar una nueva iteración, la misma que empieza con

comentarios del entorno de las pruebas de campo y un nuevo planteamiento de los

requerimientos encontrados a partir de la experiencia real [21].

2.1.2 Ciclo de Rigor

29

La Ciencia del Diseño está fundamenta en una extensa base de conocimientos como son

teorías científicas y métodos de ingeniería, los mismos que aportan las bases para una

investigación rigurosa. La base de conocimiento contiene dos tipos de conocimiento:

• Experiencia y experticia que establecen el estado del arte en el dominio de

aplicación de la investigación.

• Meta artefactos (Diseño de productos y procesos) encontrados en el dominio de la

aplicación.

El ciclo de rigor facilita conocimientos previos al proyecto de investigación para garantizar su

innovación. Es contingente para los investigadores buscar y referenciar en detalle la base de

conocimiento de tal forma que los diseños producidos contribuyan a la investigación y no solo

sean diseños de rutina basados en la aplicación de procesos bien conocidos [19]. Como Juhani

señala: "Es el rigor de construir artefactos de TI que distinguen a los Sistemas de Información

como ciencia del diseño de la práctica de construir artefactos de TI”.

El rigor de la investigación en la ciencia del diseño se basa en la habilidad del investigador en

la selección y aplicación de las teorías y métodos adecuados para la construcción y evaluación

del artefacto [18].

Lo adicional a la base de conocimiento resultado de la investigación se puede considerar

cualquier extensión a las teorías y métodos originales utilizados durante la investigación. Esto

incluye los nuevos meta-artefactos (productos de diseño y procesos) y todas las experiencias

obtenidas de la realización de la investigación y las pruebas de campo del artefacto en el

entorno de aplicación [18].

2.1.3 Ciclo de Diseño

El ciclo de diseño es la parte fundamental de cualquier proyecto de investigación de ciencia del

diseño.

Este ciclo de actividades de investigación itera rápidamente entre la construcción de un

artefacto, su evaluación y los comentarios posteriores para perfeccionar el diseño. Simon [18]

describe la naturaleza de este ciclo como generador de diseño de alternativas y evaluar las

alternativas contra los requisitos hasta que el diseño se obtiene. Como se discutió

30

anteriormente, los requisitos son de entrada del ciclo de relevancia y las teorías y métodos de

diseño y evaluación se extraen del ciclo de rigor.

Durante la ejecución del ciclo de diseño, es importante mantener un equilibrio entre los

esfuerzos invertidos en la construcción y evaluación de la evolución del artefacto de diseño.

Ambas actividades deben basarse de manera convincente en la relevancia y rigor. Si se tiene

un fuerte argumento fundamentado para la construcción del artefacto, esto no es suficiente si la

evaluación posterior es débil. "La esencia de los sistemas de información como ciencia del

diseño radica en la evaluación científica de los artefactos” [22].

Partiendo de los conceptos de la metodología de investigación ciencia del diseño para el

proyecto de desarrollo es necesario conocer el diagnóstico de la institución.

2.2 Diagnóstico

Para cumplir con la misión de la institución y las funciones atribuidas a la UAFE por mandato

legal, la Dirección de Seguridad de la Información y Administración de Tecnologías es la

encargada dentro de la UAFE de la gestión de los sistemas de la información, así como de las

tareas de desarrollo y mantenimiento de software. En este sentido, el proceso de

mantenimiento de software constituye un pilar fundamental para el desarrollo institucional de la

UAFE, ya que el software al cuál se le da mantenimiento es el núcleo de la institución debido a

que es indispensable para que la UAFE pueda cumplir con las obligaciones que tiene

atribuidas.

No obstante, mediante conversaciones previas con el área de desarrollo y las áreas

requirentes, hoy, las actividades de mantenimiento de software de la UAFE no tienen procesos

establecidos ni documentados, lo que genera demora e inexactitud en la definición de nuevos

requerimientos, falla de priorización y requerimientos cambiantes por parte de las diferentes

áreas, lo cual se evidencia en las entrevistas en el Anexo I.

La ciencia del diseño parte por el ciclo de relevancia, como se mencionó anteriormente. En este

ciclo es necesario conocer el estado actual de lo que se va a investigar, para lo cual dentro del

proyecto de desarrollo se realizaron dos tipos de entrevistas:

· Entrevista 1.- Enfocada a establecer la situación del proceso de mantenimiento

31

· Entrevista 2.- Enfocada en recopilar requerimientos del sistema Core de la institución.

La Entrevista 1 fue realizada a los funcionarios de la Dirección de Seguridad de la Información

y Administración de Tecnologías debido a que dentro de sus atribuciones está el proporcionar

sistemas que permita cumplir con la prevención del lavado de activos y financiamiento de

delitos. Las entrevistas no solo estuvieron orientadas a funcionarios operativos sino a nivel

jerárquico superior (directivos).

Esta encuesta contenía las siguientes preguntas:

1.- ¿Está documentado el proceso de mantenimiento?

2.- ¿Cómo se lleva el proceso de mantenimiento?

3.- ¿Qué opina sobre estándares, normas o modelos de calidad de software?

4.- ¿Considera usted que un proceso de calidad de software es útil para la organización?

5.- ¿Considera que el implementar algún modelo de calidad puede mejorar el proceso de

mantenimiento?

6.- ¿Cuáles considera usted dentro de los procesos de mantenimiento que pueden mejorarse?

7.- ¿Han recibido entrenamiento en: calidad de procesos, mejora continua, calidad en el

mantenimiento de software?

En el ANEXO I se puede consultar las entrevistas con toda la información recopilada.

Entrevista 2 fue realizada a los funcionarios de las áreas de Prevención y Análisis de

Operaciones quienes son parte de los usuarios finales del sistema Core de la institución, así

como también a los funcionarios de la Dirección de Seguridad de la Información y

Administración de Tecnologías ya que desde esta dirección se da soporte técnico a los sujetos

obligados. Las entrevistas no solo estuvieron orientadas a funcionarios operativos sino a nivel

jerárquico superior (directivos).

Esta encuesta contenía las siguientes preguntas:

1.- ¿Cuáles son los procesos que usted realiza con el software Sistema para la Prevención de

Lavado de Activos y Financiamiento - SISLAFT?

2.- ¿Tiene inconvenientes en los procesos realizados con el software SISLAFT?

32

3.- ¿Cuáles son las cosas que encuentra más difícil?

4.- ¿Qué problemas le gustaría resolver que se puede implementar en el SISLAFT?

5.- ¿Qué mejoras se pueden implementar en el sistema SISLAFT?

6.- ¿Considera que el software que dispone es útil?

7.- ¿Considera que el software es fácil de utilizar?

8.- ¿Cuáles de sus actividades manuales pueden automatizarse dentro del SISLAFT?

9.- ¿Ha tenido inconvenientes luego de la implementación de actualizaciones del SISLAFT?

10.- ¿Considera que antes de una actualización del SISLAFT usted ha recibido entrenamiento

a la información adecuado?

En el ANEXO 1 se puede consultar las entrevistas con toda la información recopilada.

Para la entrevista se realizó una pequeña introducción del modelo CMMI y el objetivo de la

propuesta para poder recopilar las necesidades y determinar los procesos mediante el análisis

de la información proporcionada por cada una de las personas entrevistadas.

Una vez realizada las entrevistas se procedió a la base de la codificación de las respuestas en

base a la guía de codificación la cual se presenta en la tabla 2. La guía de codificación se

encuentra distribuida en dos temas principales: el proceso de mantenimiento y el sistema, a los

cuales se asignó un código. Dentro de estos temas principales se creó dos categorías, las

mismas que permiten tener una visión general de los temas tratados durante las entrevistas.

Tabla 2 Guía de Codificación

Código Tema Código1 Tema 1

PM-001 Proceso de

mantenimiento

PM-DOC-01 Documentación

PM-CON-01 Conocimiento

PM-CAP-01 Capacitación

PM-EST-01 Estándares

PM-UTI-01 Utilidad

SIS-001 Sistema SIS-PRO-01 Procesos

33

SIS-PRB-01 Problemas

SIS-SOL-01 Soluciones

SIS-MEJ-01 Mejoras

SIS-USU-01 Usabilidad

En el ANEXO II se puede consultar guía de codificación detallada.

En la tabla 3 se presenta un resumen de las entrevistas con su respectivo número de verbatims

en base al número de personas entrevistadas.

Tabla 3 Resumen Entrevistas

Tema Subtema Verbatim

Proceso de Mantenimiento

Documentación 4

Conocimiento 4

Capacitación 4

Estándares 4

Utilidad 4

Sistema

Procesos 9

Problemas 9

Soluciones 9

Mejoras 9

Usabilidad 9

2.3 Elaboración de la Propuesta

Producto del análisis de la entrevista 1, enfocada al proceso de mantenimiento se estableció

como puntos importantes lo siguiente:

· Es necesario documentar el proceso de mantenimiento e institucionalizarlo.

· Es necesario capacitar a los funcionarios de la DSIT en temas de calidad de software.

· Es importante la utilización de normas y estándares de calidad de software.

· Se requiere de un manejo de documentación centralizada.

34

· Es necesario la automatización del versionamiento.

· Se debe mejorar el control de tiempos.

Producto del análisis de la entrevista 2 enfocada a los requerimientos de las áreas funcionales

respecto al sistema se estableció como puntos importantes los mencionados en la tabla 4:

Tabla 4 Puntos Importantes SISLAFT

Área Procesos Puntos importantes

DAO

Análisis de la Información

entregada por parte de los

sujetos obligados

· Capacitación insuficiente en la utilización

de la herramienta.

· Problemas en las búsquedas de

información en algunos casos es tedioso.

· Cambios en cuanto a reportes que maneja

el área.

· Lentitud en la generación de los reportes.

· Consolidación de reportes.

· Mejor control en cuanto a requerimientos

de instituciones externas a la unidad.

· El software es útil pero debe mejorarse.

Área Procesos Puntos importantes

DSIT

Soporte Técnico a

usuarios internos y

externos

· Capacitación insuficiente en la utilización de la

herramienta.

· El software es útil, pero sí se presentan

inconvenientes en las actualizaciones.

· El soporte es a veces complicado debido a la

identificación exacta en las estructuras de carga.

· Se requieren mejoras en el diseño de interfaz.

DP Administración de

Sujetos Obligados

· Problemas en la creación de usuarios para los sujetos

obligados y en la asignación de roles.

· Problemas con saturación del sistema en fecha

35

límites de reportes.

· Se requieren mejoras en cuanto a los problemas

indicados y mejora en las notificaciones del proceso

de aprobación y creación de código de registro y

oficiales de cumplimiento.

· Desconocimiento de actualizaciones en el SISLAFT,

por lo que puede ocasionar inconvenientes a los

sujetos obligados.

· No existe una capacitación adecuada ya que las

personas de la misma área se capacitan.

· Falta de reportes acordes a sus necesidades.

CTPOSI

Coordinación de las

áreas agregadoras de

valor DAO, Prevención y

DSIT

· Automatización del manejo y control de los

requerimientos externos a la unidad.

· Implementación de Reportes gerenciales.

· Se menciona la utilidad del software en sus

actividades.

La siguiente fase dentro de la ciencia del diseño es el Ciclo de Diseño, en esta fase se

encamina de acuerdo a las necesidades recopiladas durante las entrevistas a la generación del

artefacto.

En la tabla 5 se presenta las necesidades recopiladas en la Entrevista 1 – Proceso de

Mantenimiento respecto de las áreas de proceso del modelo de madurez y capacidad integrado

CMMI.

Tabla 5 Matriz de impacto - Proceso de Mantenimiento

ID Necesidades Áreas de Proceso

CM PMC PP PPQA MA OPD OT

Req1 Documentar el proceso de mantenimiento e institucionalizarlo

x

Req2 Capacitar a los funcionarios de la DSIT en temas de calidad de software

x

Req3 Importancia de la utilización de normas y estándares de calidad de software.

x

36

Req4 Manejo de documentación centralizada x

Req5 Control del Tiempo x x x

En la tabla 6 se presenta las necesidades recopiladas en la Entrevista 2 – Necesidades del

SISLAFT respecto de las áreas de proceso del modelo de madurez y capacidad integrado

CMMI.

Tabla 6 Matriz de Impacto – Sistema

Id Necesidades Áreas de Proceso

CM PP REQM OT

Req6 Capacitación insuficiente en la utilización de la

herramienta. x

Req7 Mejoras en los criterios de búsqueda

x

Req8 Lentitud en la generación de los reportes y fecha

límites. x

Req9 Mejoras en el diseño de interfaz y mensajes de error

x

Req10 Problemas en la Administración de sujetos obligados

x

Req11 Mejoras en notificaciones desde el sistema SISLAFT

x

Req12 Desconocimiento de actualizaciones en el SISLAFT. x x

Req13 Falta de reportes acordes a sus necesidades

x

Req14 Manejo y control de los requerimientos externos a la

unidad. x

En el ANEXO III se encuentra especificada cada una de las áreas del proceso CMMI.

Una vez presentado el resultado de las entrevistas de acuerdo a las necesidades frente a las

áreas del proceso del modelo CMMI se detectaron las siguientes áreas del proceso, que deben

ser atendidas en la UAFE. Las mismas que se detallan a continuación:

Gestión de Configuración (CM).- Es un elemento esencial para garantizar la satisfacción del

cliente, el desarrollo y mantenimiento de un producto de calidad. Es responsable de mantener

la integridad y consistencia del producto, con relación a los requisitos, diseño e información

durante el ciclo de vida. Para lo cual la propuesta incluye:

· El Proceso de Gestión de Configuración contiene:

37

o Objetivo.- Se detalla el objetivo del documento

o Definiciones.- Se detalla los conceptos generales y específicos que serán

utilizados durante todo el documento.

o Relaciones del proceso con el modelo CMMI.- Se detalla la relación que

existe entre el ciclo de vida del mantenimiento de software con el área de

proceso de gestión de la configuración.

o Descripción del Proceso.- Se detalla todo el proceso de gestión de la

configuración como: creación del proyecto, auditorias de la configuración y

liberación a producción.

Adicionalmente como parte de este documento se proporciona lo siguiente:

a) Estandarización de Documentación de Proyectos

b) Estandarización de Código Fuente de proyectos

c) Plantilla de administración de usuarios en el SVN

d) Lista de verificación de auditorías de configuración

e) Documento de liberación de versiones

Para ver en detalle el documento ver Anexo IV, adaptado de [23].

Medición y Análisis (MA).- La finalidad de esta área es desarrollar y apoyar la capacidad de

medición con lo que permita dar soporte a las necesidades de información de la dirección.

Para lo cual la propuesta incluye:

· El Proceso de Medición y Análisis contiene:


o Definiciones.- Se detalla los conceptos generales y específicos que serán

utilizados durante todo el documento.



proceso de medición y análisis.

o Descripción del Proceso.- Se detalla todo el proceso de medición y análisis.

Adicionalmente como parte de este documento se proporciona lo siguiente:

a) Formulario de generación de indicadores

b) Lista de indicadores

Para ver en detalle el documento ver Anexo V, adaptado de [23].

38

Monitorización y Control del Proyecto (PMC).- Permite identificar el progreso del proyecto de

tal forma que permita tomar las acciones correctivas apropiadas, cuando el rendimiento del

proyecto se desvíe significativamente del plan.


· El Proceso de Monitorización y Control contiene:


o Definiciones.- Se detalla los conceptos generales que serán utilizados durante

todo el documento.



proceso de monitorización y control.

o Descripción del Proceso.- En esta sección se detalla el flujo las actividades del

proceso de monitorización y control incluyendo los productos de trabajo

generados durante el proceso.

Como parte del documento se incluye las plantillas y documentos que permiten

gestionar este proceso:

a) Reporte de seguimiento semanal

b) Reporte semanal de revisiones personalizadas

c) Matriz de riesgos

Para ver en detalle el documento ver Anexo VI, adaptado de [23].

Planificación del Proyecto (PP).- Tiene como propósito establecer y mantener planes que

definan las actividades del proyecto.


· El Proceso de Planificación del Proyecto contiene:


o Definiciones.- Se detalla los conceptos generales que serán utilizados durante

todo el documento.



proceso de planificación del proyecto.

39

o Descripción del Proceso.- En esta sección se detalla el flujo actividades del

proceso de planificación del proyecto incluyendo los productos de trabajo

generados durante el proceso.



d) Plan del Proyecto de acuerdo al PMP Book

Se propone la plantilla del plan del proyecto debido a que tanto para medición y análisis así

como para el seguimiento y control son parte fundamental, para evaluar el estado del proyecto

y tomar decisiones en el caso de un retraso en la entrega.

Para ver en detalle el documento ver Anexo VII.

Gestión de Requerimientos (REQM).- Administra los requerimientos del proyecto, tanto

técnicos como no técnicos (aquí podemos considerar costo y calendario). Esta área se

encarga de garantizar que todos en el proyecto trabajen con requerimientos debidamente

formalizados.


• Proceso de Gestión de Requerimientos


o Definiciones.- Se detalla los términos generales que serán utilizados durante

todo el documento.



proceso de gestión de requerimientos.

o Descripción del Proceso.- En esta sección se detalla el flujo de información

entre las actividades del proceso de gestión de requerimientos incluyendo los

productos de trabajo generados durante el proceso.



a) Solicitud de Modificación

b) Bitácora de requerimientos

Para ver en detalle el documento ver Anexo VIII, adaptado de [23].

40

Formación de la Organización (OT).- Tiene como propósito desarrollar las habilidades y el

conocimiento de las personas para que puedan realizar sus roles eficaz y eficientemente.


• Proceso de Formación de la Organización


o Definiciones.- Se detalla los términos generales que serán utilizados durante

todo el documento.



proceso de formación de la organización.

o Descripción del Proceso.- En esta sección se detalla el flujo de información

entre las actividades del proceso de gestión de requerimientos incluyendo los

productos de trabajo generados durante el proceso.



a) Plan de Formación

La propuesta incluye un plan de formación de la organización en base a las necesidades

detectadas en las entrevistas, con lo cual se llegaría a solventar la necesidad de formación

hacia los funcionarios.

Para ver en detalle el documento ver Anexo IX.

Definición de Procesos de la Organización (OPD).- Tiene como propósito establecer y

mantener un conjunto útil de activos de proceso de la organización y de estándares del entorno

de trabajo. Su función principal es acumular y gestionar el conocimiento de la organización en

beneficio de los proyectos futuros.

Con base en las demás áreas del proceso se han elaborado los siguientes procesos que serían

parte de los activos de la organización como:

· Proceso de Gestión de la Configuración

· Proceso de Medición y Análisis

· Proceso de Gestión o Administración de Requerimientos

· Proceso de Aseguramiento de la Calidad

41

· Proceso de Mantenimiento ver Anexo X

Aseguramiento de la Calidad del Proceso y del Producto (PPQA).- La función de

aseguramiento de calidad es vital para lograr el cumplimiento de las prácticas y el

establecimiento de la cultura de procesos en la organización. Es importante lograr la una

revisión objetiva y un criterio garantizado.


· Proceso de Aseguramiento de Calidad que, como se ha mencionado, los puntos que

contiene y las plantilla que incluye para cumplir con el propósito de este proceso como

son:

a) Lista Verificación de Gestión de la Configuración

b) Lista de Verificación de Administración de Requisitos

c) Lista de Verificación de Medición y Análisis.

Para ver en detalle el documento ver Anexo XI, adaptado de [23].

Todo proceso es susceptible a cambios y mejoras, los mismos que deben estar apoyando a

cumplir los objetivos institucionales. La UAFE tiene muchos requerimientos cambiantes por lo

cual es necesario reducir el tiempo para lanzar un nuevo requerimiento. El objetivo de mejora

de procesos se enfoca en mejorar la gestión del proyecto para asegurar la entrega a tiempo.

Esas mejoras se apoyan en las mejores prácticas dentro de las áreas de proceso en conjunto.

Una vez presentada la propuesta que corresponde al artefacto en la ciencia del diseño, esta

deber ser evaluada por la institución.

2.4 Evaluación

Para la evaluación de la propuesta se utilizó un método basado en un grupo focal. Un grupo

focal, es un grupo de personas previamente seleccionadas por el investigador con el fin de

discutir y comentar, desde el punto de vista del entrevistado, el tema presentado por el

investigador [24]

El grupo focal se centra en el análisis de la intervención activa de los participantes dentro del

grupo y sus reacciones frente al tema propuesto por el investigador [25].

42

Los participantes que integrarán el grupo focal pertenecen a la Dirección de Seguridad de la

Información y Administración de Tecnologías, debido a que esta dirección es quien está a

cargo del proceso de mantenimiento.

La propuesta presentada anteriormente está enfocada en 8 áreas del proceso de CMMI. Por

esta razón se presentará al grupo focal cada una de las áreas para ser analizadas y poder

conocer la percepción de cada uno de los participantes.

La propuesta fue presentada y validada primeramente con el Director de Seguridad de la

Información y posteriormente presentada a los demás miembros del grupo focal, la misma que

fue realizada el día viernes 26 de noviembre de 2018.

La evaluación final emplea un enfoque basado en el modelo de aceptación de tecnología (TAM)

para examinar la experiencia de la propuesta presentada.

El modelo TAM trata de predecir la aceptación tecnológica basada en dos variables principales

[26]:

· Percepción de Utilidad.- grado en que una persona cree que el uso de un determinado

artefacto mejora el rendimiento del trabajo.

· Percepción de facilidad de uso.- grado en que una persona cree que utilizando un

determinado artefacto, podrá liberarse del esfuerzo que le conlleva realizar un trabajo.

Es decir, el modelo sugiere que cuando a los usuarios se les presenta una nueva tecnología,

una serie de factores influyen en su decisión sobre cómo y cuándo la van a utilizar. Según

Davis et al. (1989), el propósito primario del TAM es explicar las causas de aceptación de las

tecnologías por los usuarios. Por lo tanto, el modelo propone que las percepciones de un

individuo en la utilidad percibida y la facilidad de uso percibida de una tecnología, sean

concluyentes para determinar su intención de usarla [27].

43

Fig. 9 Modelo de Aceptación de Tecnologías TAM [28]

Así, se utilizó una encuesta enfocada a la percepción de utilidad y a la percepción facilidad de

uso, la misma que contiene las siguientes preguntas:

1.- ¿Considera usted que la propuesta presentada es sencilla de manejar?

2.- ¿Considera usted que la propuesta es adecuada para la institución?

3.- ¿Considera usted que la propuesta es clara?

4.- ¿Considera usted que la propuesta es útil?

5.- ¿Considera usted que la propuesta ayuda a mejorar la productividad?

6.- ¿Considera usted que la propuesta cumple con el objetivo propuesto?

7.- ¿Considera usted que la propuesta mejorará el trabajo del área?

44

3 Resultados y Discusión

En este capítulo se presentan los resultados obtenidos de la propuesta elaborada en el

Capítulo 2. Se analizará además las respuestas obtenidas en la fase de evaluación.

Como se menciona en el Capítulo 2, la metodología de evaluación de la propuesta fue

mediante el modelo de aceptación de tecnologías TAM a través de un grupo focal. Para ellos

se realizó la presentación de la propuesta al grupo focal seleccionado, la misma que incluyó la

revisión de cada una de las áreas de proceso CMMI propuesto.

Durante la presentación de cada una de las áreas se mostraron puntos importantes a

considerarse una vez que se empiece con la aplicación de cada una de ellas, los cuales se

detallan a continuación:

· Aplicar cada uno de los procesos propuestos a proyectos pequeños para que se pueda

evaluar el funcionamiento de forma adecuada.

· Dentro del área de formación se plantea que las capacitaciones sean hacia los dos

lados, tanto del área del negocio como del área de TI y viceversa, ya que la Dirección

de Seguridad de la Información y Administración de Tecnologías al ser parte de las

áreas agregadoras de valor deben conocer el negocio para plantear proyectos que

beneficien a las otras áreas.

· Dentro de área de gestión de requerimientos se debería contemplar el solicitar al menos

dos representantes del área del negocio con poder de decisión para que se verifique los

requerimientos levantados.

· Dentro del proceso de mantenimiento se debe considerar la parte de seguridad de la

información, y hacer referencia al EGSI.

· Se recomienda la socialización de las áreas.

Posterior a la presentación se entregó unas encuestas escritas cuyas respuestas más

representativas se presentan a continuación:

45

Tabla 7 Resultados de la Evaluación

Encuesta a detalle Anexo XII Pregunta Respuestas Conclusiones

1.- ¿Considera usted que la propuesta presentada es sencilla de manejar?

· “No se considera a la propuesta sencilla, ya que depende del ámbito y objetivos a cumplir.”

· “No, creo que los procesos tienen su grado de complejidad que ameritan aprendizaje continuo.”

· “No del todo, se requiere seguir un orden secuencial de manejo de información, tanto precedente como actual. La información debe ser determinante para enfocar todos los niveles que se pretende cubrir.”

· “Sí facilita la gestión de TI. De acuerdo a lo planteado la propuesta es sencilla y fácil de manejar, pero también se debe tomar en cuenta las directrices que acompañaran a la propuesta.”

· “Sí porque CMMI es una metodología bien definida.”

· “Sí la propuesta es sencilla y entendible.”

La propuesta es considerada por el 50% sencilla y el otro 50% considera que no es sencilla debido al grado de complejidad y aprendizaje continuo que requiere cada proceso.

46

Pregunta Respuestas Conclusión

2.- ¿Considera usted que la propuesta es adecuada para la institución?

· “Sí es adecuada, permite mejorar procesos en el mantenimiento de los aplicativos. La propuesta está acorde a las necesidades institucionales.

· “Definitivamente sí. En el software hoy en día, por necesidad debemos saber los ciclos por los que ha evolucionado el mismo, por ello es necesario tener identificados todos los procesos de madurez en otras palabras, es la IDENTIDAD con todos los calificativos y cualidades que caracterizan el software referido.”

· “Sí, se requiere y es de mucha importancia.”

· “La propuesta es adecuada y necesaria ya que no se encuentra implementado ningún proceso similar al mencionado.”

· “Sí, porque permitirá coordinar de mejor forma el trabajo con las áreas del negocio, brindando un servicio eficiente.”

· “Sí me parece muy bien que la propuesta realizada sea implementada en la institución. Ya que la misma podrá contar con una guía estandarizada“.

Se establece que la propuesta es adecuada ya que no existen procesos similares definidos, esto permitirá coordinar de mejor forma el trabajo.

47


3.- ¿Considera usted que la propuesta es clara?

· “En general si, falta indicar metas y alcance.”

· “Sí, se tiene claro los procedimientos a ejecutarse de acuerdo a las necesidades de la institución.”

· “Sí.” · “Sí, esta detallada en varios

módulos.” · “Sí, ya que es un objetivo

claro de cómo se debe llevar estos procesos.”

· “Sí, sin embargo si se va a implementar en la institución debe mejorarse el enfoque de seguridad con base a lo que establece el EGSI.”

· “Me pareció súper clara la propuesta.”

Se establece que la propuesta es clara, pero debe considerarse el tema de seguridad de acuerdo a lo que indica el EGSI.


4.- ¿Considera usted que la propuesta es útil?

· “Sí, es útil.” · “Sí, estamos seguros que

dicha propuesta será de mucha utilidad a la actualidad para nuestra institución.”

· “Sí, por lo expuesto en el punto dos.”

· “Sí, ayudará con el cumplimiento del EGSI.”

· “Sí, porque de esta manera se lleva un registro de todos los cambios y procedimientos que se debe llevar dentro de la institución.”

· “Sí, porque nos permite mejorar la productividad, transparentar los procesos, cumplir la normativa de las entidades de control y balancear la carga de trabajo en el área siempre y cuando se tenga roles definidos y se tenga backups para cada proceso crítico.”

· “Sí, ya que la institución será la beneficiada.”

Se considera que la propuesta es útil ya que se llevara un control más ordenado de los procesos, logrando una distribución de trabajo más equitativa.

48


5.- ¿Considera usted que la propuesta ayuda a mejorar la productividad?

· “Sí, creemos que la productividad será notable en nuestra organización.”

· “Sí. Es importante como todo, saber sobre que terreno pisar. Sumamente necesario para dar a conocer efectivamente avances.”

· “Si, ayuda a generar documentación de todo. La productividad es uno de los factores primordiales para el avance y crecimiento de una empresa. Creo que una vez implementado estos procesos nos ayudara el mantener la documentación actualizada y de calidad.”

· “Sí, porque nos permite tener roles definido y de esta forma no duplicamos esfuerzos.”

· “Sí, ya que la metodología aplicada servirá de guía para los productos que genera la institución.”

Se considera que la propuesta sí mejorará la productividad.


6.- ¿Considera usted que la propuesta cumple con el objetivo propuesto?

· “Sí, cumple a cabalidad el objetivo de aplicar nuevos procesos a la organización de información de nuestra organización.”

· “Sí. Enumera todas las fases en sintonía con los procesos de negocio.”

· “Sí, la seguridad y la gestión. Creo que la propuesta dará buenos resultados una vez implementada.”

· “Sí; siempre y cuando sea socializada y que cada quien adopte ese cambio de cultura organizacional.”

· “Si, se logra cumplir con los objetivos planteados.”

La propuesta cumple con el objetivo fijado, pero debe ser socializada y se debe adoptar un cambio de cultura organizacional.

49


7.- ¿Considera usted que la propuesta mejorará el trabajo del área?

· “Sí, una vez implementado estamos convencidos que aportará eficazmente en la forma como resolvemos los problemas con notable eficiencia en nuestra área.”

· “Sí es la base de todo. En desarrollo sino se conoce que sistemas tienes, que sistema se desarrolló o que sistema se pretende desarrollar, se pueden definir directrices claras para evolucionar.”

· “Sí, los proyectos tendrán una mejor ejecución. Ayudará en un gran porcentaje a los analistas que trabajamos en el área, ya que estará definidos procesos, documentación actualizada y a la mano para cumplir nuestras funciones en la institución.”

· “Sí; porque nos permitirá tener un control del trabajo realizado; gestionando de mejor forma las tareas en el uso de indicadores de seguimiento.”

· “La propuesta es clara, cumple con los objetivos planteados y acorde las necesidades institucionales será muy útil para mejorar la productividad a nivel de Dirección de Tecnológica. “

Se considera que la propuesta sí mejorará la productividad.

Como se indica en la tabla 7 con base en las respuestas obtenidas luego de la presentación de

la propuesta, podemos concluir que la misma ha generado una buena expectativa y una gran

aceptación por parte de los funcionarios de la Dirección de Seguridad de la Información y

Administración de Tecnologías, ya que la consideran de gran utilidad para cubrir las

necesidades de la institución.

50

4 Conclusiones y Recomendaciones

4.1 Conclusiones

A través de la entrevista fue posible identificar los requerimientos en cuanto al Sistema

para la Prevención de Lavado de Activos y Financiamiento del Terrorismo, así como los

problemas en cuanto al proceso de mantenimiento, los mismos que con la

implementación del modelo CMMI irán mejorando.

Con base a la investigación realizada en el desarrollo de este proyecto fue posible

identificar recomendaciones y actualizar conocimientos en cuanto al proceso de

mantenimiento para poderlos realizar en la práctica con estándares de calidad.

Con la entrevista a los funcionarios involucrados en este proceso e investigación acerca

del modelo CMMI fue posible la elaboración de una propuesta de los procesos de

mantenimiento basados en dicho modelo y se puedo establecer que el Modelo CMMI es

adecuado y aplicable para el proceso de mantenimiento de software, en instituciones

públicas y privadas.

La definición de procesos dentro de las instituciones públicas permite un mejor control

por parte de los funcionarios que trabajan con estos procesos.

Si bien es cierto el modelo de madurez CMMI es un proceso que abarca varias áreas,

siempre es necesario empezar por una de las áreas la que la institución considera como

prioritaria, para de esta forma ir incrementando las áreas de proceso de CMMI hasta

logar tener al menos un nivel intermedio de madurez, con lo cual tanto el proceso de

mantenimiento como los procesos de cada área cumplan con estándares de calidad.

El desarrollo de este proyecto ha permitido tener una visión más clara de lo que los

funcionarios del área de TI queremos en los procesos de mantenimiento de software.

Mediante la presentación de la propuesta a los funcionarios involucrados fue posible

establecer la aceptación de la misma con ciertas observaciones las mismas que serán

acogidas una vez que se vaya a empezar con la implementación de las áreas de

proceso identificadas.

51

4.2 Recomendaciones

· La propuesta contiene: proceso de gestión de la configuración, proceso de

medición y análisis, proceso de seguimiento y control, proceso de gestión de

requerimientos, plan del proyecto, plan de formación, proceso de mantenimiento,

proceso de aseguramiento de calidad de las áreas del proceso del modelo de

madurez CMMI, las cuales se recomienda que sean implementadas para

posteriormente ir incluyendo nuevas áreas una vez que estén claros cada uno

de los procesos.

· La adaptación de este modelo de madurez CMMI es un proceso continuo, por lo

cual se recomienda que se lo aplique y se lo institucionalice.

· Es necesario que la institución mantenga un responsable que monitoree

continuamente los procesos CMMI y que vigile su cumplimiento.

Para el proceso de implantación se recomienda:

Capacitación a los funcionarios sobre el desarrollo de los nuevos procesos,

procedimientos y formatos, la misma que debe replicarse hacia los funcionarios

nuevos.

Definir una política en la cual se dé la importancia de seguir las prácticas de

CMMI y la generación de las evidencias de cumplimiento.

Verificar permanentemente el cumplimiento de los procesos por parte de

todos los funcionarios hasta que esto se vuelva una práctica.

52

5 Referencias Bibliográficas

[1]"LA INSTITUCION – Unidad de Análisis Financiero y Económico", Uafe.gob.ec, 2018.

[Online]. Available: http://www.uafe.gob.ec/la-institucion/. [Accedido: 01 -Ago- 2018].

[2]Ley Orgánica de Prevención, Detección y Erradicación del Delito de Lavado de Activos y del

Financiamiento de Delitos. Quito, 2017.

[3]"Misión | Visión | Valores – Unidad de Análisis Financiero y Económico", Uafe.gob.ec, 2018.

[Online]. Available: http://www.uafe.gob.ec/valores-mision-vision/. [Accedido: 02- Ago- 2018].

[4]Estatuto Orgánico De Gestión Organizacional Por Procesos de la Unidad de Análisis

Financiero y Económico. Quito: Unidad de Análisis Financiero y Económico, 2017.

[5]Díaz, Polo, Daynel. Definición de un proceso de desarrollo de software en un entorno

universitario, D - Instituto Superior Politécnico José Antonio Echeverría. CUJAE, 2011.

[6] "Evolución de CMMI timeline.", Timetoast, 2018. [Online]. Available:

https://www.timetoast.com/timelines/evolucion-de-cmmi. [Accessed: 02- Ago- 2018].

[7] Moreno, Pérez, Juan Carlos, and Pérez, Arturo Francisco Ramos. Administración de

software de un sistema informático, RA-MA Editorial, 2014.

[8] M. Chrissis, M. Konrad and S. Shrum, CMMI® para desarrollo. Madrid: Editorial Universitaria

Ramón Areces, 2012.

[9] Álvarez, Rodríguez, Javier, et al. Interpretación del Modelo de Madurez de Capacidades

(CMM): para pequeñas industrias de software, Universidad Autónoma de Aguascalientes, 2008.

[10] S. E. Institute, CMMI para Desarrollo v1.3, 2010.

[11] Software. - IEEE Std, IEEE Software Engineering Standard: Glossary of Software

Engineering Terminology. IEEE Computer Society Press, 1993.

[12] Pérez, Carvajal, Rafael Jesús. Mantenimiento del software (UF1894), IC Editorial, 2014.

[13] IEEE standard for software maintenance, IEEE std 1219-1998. In: IEEE

Standards Software Engineering, Volume Two: Process Standards. New York:

IEEE Press, 1999. v. 2.

53

[14] International Standard ISO/IEC/IEEE 14764 Software Engineering - Software

Life Cycle Processes - Maintenance. Piscataway, EUA, 2006

[15] March S. T., Smith G. F. (1995) Design and natural science research on information

technology, Decision Support Systems, 15, 251-266.

[16] Hevner A. R., March, S. T., Park, J., Ram, S. (2004) Design Science in Information

Systems Research, MIS Quarterly, 28(1), 75-105.

[17] Gregor S., Hevner A. R. (2013) Positioning and presenting Design Science Research for

maximum impact, MIS Quarterly, 37(2), 337-355.

[18] Simon, H. (1996) The Sciences of Artificial, 3rd edn., MIT Press, Cambridge, MA.

[19] Cole, R., S. Purao, M. Rossi, and M. Sein (2005), Being proactive: where action research

meets design research, in Proceedings of the Twenty-Sixth International Conference on

Information Systems, Las Vegas, pp. 325–336.

[20] Jarvinen, P. (2007) Action research is similar to design science, Quality & Quantity 41, pp.

37–54.

[21] Hevner, Alan R. (2007) "A Three Cycle View of Design Science Research," Scandinavian

Journal of Information Systems: Vol. 19 : Iss. 2 ,

[22] Iivari, J., “A Paradigmatic Analysis of Information Systems as a Design Science,

Scandinavian Journal of Information Systems, 19(2), 2007.

[23] "Procesos Transversales", Icesi.edu.co, 2018. [Online]. Available:

https://www.icesi.edu.co/i2t/driso/process/proceso_desarrollo_sw/index.php/procesos-

transversales. [Accessed: 15- Ago- 2018].

[24] Powell, R. y Single, H. (1996). Focus groups. International Journal for Quality in Health

Care, 8(5), 499-509. Tomado el 15 de febrero del 2009, de Base de datos Celsius.

[25] Morgan, D. L. (1997). Focus groups as qualitative research (2.a ed.). Thousand Oaks, CA,

EE. UU.:Sage.

[26] Gefen D, Karahanna E, Straub DW (2003) Inexperience and experience with online stores:

the importance of TAM and trust. IEEE Trans Eng Manag 50(3):307–321

54

[27] DAVIS, F. D. (1989) Perceived usefulness, perceived ease of use and user acceptance of

information, MIS Quarterly, 13:3, pp. 319-342.

[28] E. Loza y B. Alex, “Qualitative assessment of user acceptance within Action Design Research and Action Research: two case studies,” Latin American Journal of Computing , vol. 1, nº 1, 2014.

55

6 Anexos

Los anexos que se enumeran a continuación se encuentran en el disco adjunto.

ANEXO I: ENTREVISTAS REALIZADAS

ANEXO II: GUIA DE CODIFICACION DE ENTREVISTAS

ANEXO III: REQUERIMIENTOS Y AREAS DEL PROCESO CMMI

ANEXO XII: ENTREVISTA DE EVALUACION

56

ANEXO IV: PROCESO DE GESTIÓN DE LA CONFIGURACIÓN

PROCESO

DE GESTIÓN DE CONFIGURACIÓN

V1.0

57

Historial de Versiones

Fecha

Creación

Descripción Autor Versión

08/09/2018 Proceso de Gestión de

la Configuración

Ximena Mendoza 1.0

58

Contenido

1. Descripción Técnica ............................................................................................................................ 60

Introducción ........................................................................................................................................... 60

Objetivo .................................................................................................................................................. 60

Importancia ............................................................................................................................................ 60

2. Definiciones .......................................................................................................................................... 60

Conceptos Generales .......................................................................................................................... 60

Conceptos Específicos ........................................................................................................................ 60

3. Relación del proceso con el modelo CMMI ..................................................................................... 61

4. Descripción del Proceso ..................................................................................................................... 62

4.1. Caracterización del Proceso ....................................................................................................... 64

4.1.1. Configuración del Proyecto.................................................................................................. 64

4.1.1.1. Crear proyecto en el SVN ................................................................................................. 64

4.1.1.2. Asignar permisos de usuario en el SVN ........................................................................ 64

4.1.1.3. Almacenar elementos en el SVN según estándares .................................................... 65

4.1.1.4. Actualizar los componentes del proyecto....................................................................... 66

4.1.2. Auditorías de Configuración ................................................................................................ 67

4.1.2.1 Definir plan de auditorías de configuración..................................................................... 67

4.1.2.2. Realizar auditorías de configuración .............................................................................. 68

4.1.2.3. Proceder según resultados de auditoria ........................................................................ 69

4.1.3. Liberación de Versiones del Producto ............................................................................... 69

4.1.3.1. Actividad: Liberar versiones del producto ...................................................................... 69

4.1.3.2. Establecer línea base del producto ................................................................................. 70

4.2 Descripción de los Roles .............................................................................................................. 70

4.3. Descripción de Productos ........................................................................................................... 71

4.4. Descripción de Artefactos ........................................................................................................... 71

5. Formatos, Documentos y Herramientas .......................................................................................... 72

Estandarización de Documentación de Proyectos ......................................................................... 72

Estandarización de Código Fuente de proyectos ........................................................................... 76

Documento de administración de usuarios en el SVN ................................................................... 80

59

Lista de verificación de auditorías de configuración ....................................................................... 81

Plan de auditorías de configuración .................................................................................................. 82

Documento de auditoría de configuración........................................................................................ 83

Documento de liberación de versiones ............................................................................................. 83

Herramientas......................................................................................................................................... 84

Bibliografía ..................................................................................................... ¡Error! Marcador no definido.

60

1. Descripción Técnica

Introducción

El documento contiene un conjunto de artefactos desarrollados para facilitar la implementación de procesos en una institución que cuenta con un área de desarrollo de software. Los elementos característicos son: descripción de procesos, actividades, tareas, roles plantillas y herramientas.

Objetivo

Proporcionar una guía que permita gestionar la configuración del proyecto de forma adecuada, considerando: la gestión de usuarios, administración de ítems de configuración, administración de elementos en el SVN, liberación de versiones y auditorias de configuración, durante la ejecución de proyectos de desarrollo y mantenimiento de software ejecutados en periodos cortos de acuerdo a la necesidad institucional.

Importancia

La importancia del proceso de gestión de configuración radica en tener claro los lineamientos que permitan la gestión de forma simple y que el equipo de desarrollo pueda guiarse para desarrollar un producto de software o dar mantenimiento conociendo como está la documentación necesaria del proyecto, para con esto garantizar que se de mantenimiento sobre la misma línea base y la curva de aprendizaje incremente de forma más rápida.

2. Definiciones

Esta sección contiene la definición de conceptos generales y específicos que se utilizan en el proceso.

Conceptos Generales

· Proceso: conjunto de actividades que se ejecutan durante el proceso de desarrollo o mantenimiento, las cuales transforman entradas en salidas. [ISO/IEC 12207].

· Actividad: un conjunto de tareas de un proceso. [ISO/IEC 12207].

· Tarea: Acción permisible que pretende contribuir al cumplimiento de una o más metas de un proceso. [ISO/IEC 12207].

· Paso: una tarea se descompone en una secuencia de pasos.

· Rol: una función definida para ser realizada por un miembro del equipo de desarrollo del proyecto. [ISO/IEC 24765]

· Producto: entregable tangible o intangible que puede ser por una o varias tareas.

· Artefacto: información que apoya al proceso durante la ejecución de un proyecto.

Conceptos Específicos

· Control de Versiones: Es la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. En algunos contextos, un producto de trabajo individual puede tener su propia línea de base y un nivel de control menor puede ser suficiente.

61

· Identificación de Configuración: Corresponde a los ítems de configuración para un proceso o proyecto, colocando un identificador único y registra las particularidades en la documentación técnica.

· Producto de Trabajo: documentos generados por los diferentes procesos del proyecto o proyectos de la institución.

· Ítem de Configuración: producto de trabajo considerado parte del control de configuración para controlar los cambios producidos sobre este.

3. Relación del proceso con el modelo CMMI

En esta sección se detalla las actividades relacionadas al proceso de gestión de configuración para proyectos de desarrollo y mantenimiento de software. El área de proceso Gestión de la Configuración (CM) del modelo CMMI-DEV versión 1.3 (Capability Maturity Model Integration) tiene un grupo de prácticas que orientan y garantiza que este proceso sea llevado de forma correcta en los proyectos de desarrollo y mantenimiento de software.

Este proceso aplica para proyectos de desarrollo y mantenimiento de software a la medida, de complejidad media de duración corta. El proceso de gestión de configuración se apoya mediante formatos, documentos y actas que permiten el registro de las actividades del proceso. En la figura 1 se presenta la ubicación del proceso de Gestión de Configuración dentro de los procesos del ciclo de vida de desarrollo de software.

Fig. 10 Ciclo de Vida de Desarrollo de Software

En la figura 2 se presenta la ubicación del proceso de Gestión de Configuración dentro del ciclo

de vida de mantenimiento de software.

62

Fig. 11 Fases del Proceso de Mantenimiento de Software (IEEE 1219-1999)

4. Descripción del Proceso

En esta sección se detalla el proceso con las respectivas actividades de cada uno de los

subprocesos del proceso de gestión de configuración incluyendo los productos de trabajo

generados durante los subprocesos.

En la figura 3 se muestra el diagrama de la configuración del proyecto, que forma parte de la

gestión de la configuración:

Figura 3 — Configuración del proyecto

63

En la figura 4 se muestra el diagrama del subproceso de Administración de auditorías de configuración del proyecto:

Figura 4 — Auditorias de Configuración

En la figura 5 se muestra el diagrama del subproceso de Liberación de versiones del producto:

Figura 5 — Liberación de Versiones

64

4.1. Caracterización del Proceso

4.1.1. Configuración del Proyecto

4.1.1.1. Crear proyecto en el SVN

Permite crear el repositorio del proyecto, tanto para documentación como para código fuente. Es obligación crear la estructura del proyecto en el SVN según el documento de estandarización de documentación de proyectos y estandarización de código fuente de proyectos previamente establecidos.

Crear proyecto en el SVN Objetivo: Crear el repositorio para el almacenamiento de la documentación y el

código fuente del proyecto. Justificación: Disponer de un repositorio para el almacenamiento de la documentación

y el código fuente de los proyectos, que facilite la gestión de las versiones de los productos de trabajo.

Roles: Equipo de desarrollo del proyecto

Artefactos: Estandarización de documentación de proyectos Estandarización de código fuente de proyectos

Pasos: Paso 1: Revisar los documentos previamente establecidos de estandarización de documentación y código fuente. Paso 2: Crear el proyecto en el SVN según los estándares anteriormente revisados.

Detalle de los Pasos:

Paso 1: Revisar los documentos previamente establecidos de estandarización de documentación y código fuente El equipo de desarrollo del proyecto debe revisar los documentos previamente establecidos de estandarización de documentación y código fuente, como premisa para la creación del proyecto en el SVN. Paso 2: Crear el proyecto en el SVN según los estándares anteriormente revisados El proyecto SVN que se crea debe definir dos estructuras de almacenamiento: una para documentación y otra para código fuente. Es obligación crear las estructuras del proyecto tal como se especifican en los estándares establecidos.

4.1.1.2. Asignar permisos de usuario en el SVN

Permite controlar el acceso de los usuarios a la documentación y código fuente del proyecto almacenado en el SVN, considerando la confidencialidad de lo que se maneja dentro de la institución. Para definir el acceso a la documentación y código fuente se debe tener establecido cual es el rol que tiene cada miembro del equipo con las funciones establecidas y su nivel de responsabilidad dentro del mismo.

65

Asignar permisos de usuario en el SVN Objetivos: Controlar el acceso de los usuarios a la documentación y código fuente

del proyecto Justificación: Garantiza la confidencialidad de lo que representa el tener acceso a la

documentación y código fuente de un proyecto dentro de la institución. Roles: Equipo de desarrollo del proyecto

Artefactos: Documento de administración de usuarios en el SVN Pasos: Paso 1: Entregar el formulario de creación de usuarios en el SVN

Paso 2: Revisar el formulario previamente llenado por el miembro del equipo. Paso 3: Asignar permisos a los miembros del equipo de desarrollo según lo establecido en el formulario Paso 4: Notificar la creación del usuario vía correo electrónico.


Paso 1: Entregar el formulario de creación de usuarios en el SVN El líder de aplicaciones o responsable designado cuando exista una persona que necesite el acceso a la documentación o código fuente de la aplicación deberá entregar el formulario de creación de usuario de SVN. Paso 2: Revisar el formulario previamente llenado por el miembro del equipo. El líder de aplicaciones o responsable designado deberá verificar que el formulario entregado este llenado correctamente y completo. Paso 3: Asignar permisos a los usuarios del proyecto en el SVN según el formulario de creación de usuarios en el SVN Después de revisado el documento de administración de usuarios, la persona encargada de la administración asigna los permisos a los usuarios. Esta persona debe administrar los usuarios durante la ejecución del proyecto. Paso 4: Notificar la creación del usuario vía correo electrónico El líder de aplicaciones o responsable designado deberá notificar mediante correo electrónico la creación del mismo.

4.1.1.3. Almacenar elementos en el SVN según estándares

Permite el almacenamiento de la documentación y el código fuente del proyecto en su respectiva ubicación según los estándares establecidos.

Almacenar componentes en el SVN según estándares

Objetivos: Almacenar la documentación y el código fuente del proyecto en su respectiva ubicación según los estándares establecidos.

Justificación: Permite una gestión adecuada de los componentes del proyecto almacenados en el SVN, facilitando los cambios y actualizaciones requeridos.

66


Artefactos:

Pasos: Paso 1: Almacenar los componentes del proyecto en el SVN


Paso 1: Almacenar los elementos del proyecto en el SVN El equipo de desarrollo debe almacenar los componentes del proyecto en el SVN, considerando los permisos asignados sobre el proyecto y la ubicación definida para cada elemento.

4.1.1.4. Actualizar los componentes del proyecto

Permite garantizar la seguridad e integridad de los productos de trabajo generados durante el proyecto.

Actualizar los componentes del proyecto Objetivos: Garantizar la seguridad e integridad de los productos de trabajo

generados durante el desarrollo y mantenimiento del proyecto. Justificación: Permite mantener la última versión de los ítems de configuración del

proyecto. Roles: Equipo de desarrollo del proyecto Artefactos: Documento de actualización de componentes del proyecto Pasos: Paso 1: Actualizar los componentes del proyecto. Detalle de los Pasos:

Paso 1: Actualizar los componentes del proyecto Cuando se actualiza los componentes mediante el svn, la herramienta SVN chequea la existencia de lo que se encuentra en el repositorio versus lo que se quiere actualizar y se actualiza lo nuevo, pueden existir casos de inconsistencia. En caso de presentarse inconsistencias, proceder de la siguiente manera:

· Identificar los ítems de configuración con problemas. Para cada uno de estos ítems identificar las líneas que generan el problema, la revisión a la que pertenecen y el autor de la revisión.

· Generar una copia de respaldo del ítem en conflicto.

· Reversar los cambios aplicados sobre el ítem. · Actualizar el ítem de configuración para la última versión en el

repositorio. · Reconstruir el cambio realizado. · Sincronizar la copia de trabajo con la versión del repositorio para

que los cambios realizados sean aplicados correctamente. Para Sincronizar la copia de seguridad y la versión del Repositorio:

· Antes de sincronizar los cambios realizados sobre la copia de trabajo, el usuario deberá garantizar que ha ejecutado la

67

“Importación de la copia de trabajo” y que no se presentan problemas entre las versiones.

· Cuando el usuario realiza un commit a un ítem de configuración debe colocar una descripción breve de la razón del cambio. Todos los cambios realizados deben estar hecho commit. Al terminar la sincronización, el usuario deberá anota el número de revisión generado por el SVN para posterior seguimiento y soporte.

· Es de carácter obligatorio cumplir el estándar de especificación para los mensajes que describen el cambio aplicado en el SVN.

Formato de los mensajes de Commit/Check-In [Nombre Proyecto]: [REQ-No. Requerimiento -Justificación de la revisión. El equipo de desarrollo del proyecto debe garantizar que se realice la copia de trabajo del proyecto diariamente. En el proceso de administración de copias de trabajo participan todos y cada uno de los roles habilitados para acceder al SVN.

4.1.2. Auditorías de Configuración

4.1.2.1 Definir plan de auditorías de configuración

Permite la planificación de las auditorías que se deben efectuar a la configuración del proyecto,

para garantizar que se estén cumpliendo los estándares de configuración establecidos.

Definir plan de auditorías de configuración

Objetivo: Planificar las auditorías que se deben realizar a la configuración del proyecto, para garantizar que se estén cumpliendo los estándares de configuración establecidos.

Justificación: Permite la planificación de las auditorías de configuración que se deben realizar durante el desarrollo del proyecto, garantizando que se incluya todo lo requerido para que la auditoría tenga resultados positivos.


Artefactos: Plan de auditorías de configuración Lista de verificación de auditorías de configuración

Pasos: Paso 1: Revisar la lista de verificación de auditorías de configuración

Paso 2: Elaborar plan de auditorías de configuración


Paso 1: Revisar la lista de verificación de auditorías de configuración

El equipo de desarrollo del proyecto debe revisar la lista de verificación de auditorías de configuración diseñada para garantizar que se incluya

68

todo lo requerido para una auditoria adecuada.

Paso 2: Elaborar plan de auditorías de configuración

6.1. Después de revisar la lista de verificación de configuración el equipo de desarrollo del proyecto debe realizar el plan de las auditorías de configuración que se efectuarán durante la ejecución del proyecto, determinando responsable, fecha y entregable de las auditorias. Esto debe verse reflejado en el documento de plan de auditorías de configuración.

4.1.2.2. Realizar auditorías de configuración

Permite llevar a cabo la ejecución del plan de auditorías de configuración definido previamente, para verificar que se estén cumpliendo los estándares establecidos para la ejecución del proyecto.

Definir plan de auditorías de configuración Objetivo: Ejecutar el plan de auditorías de configuración definido previamente, para

verificar que se estén cumpliendo los estándares definidos para la ejecución del proyecto.

Justificación: Garantizar que se cumplan la estandarización de documentación y código fuente definidos para la configuración del proyecto.

Roles: Equipo de desarrollo del proyecto Artefactos: Lista de verificación de auditorías de configuración

Documento de auditorías de configuración Pasos: Paso 1: Revisar el plan de auditorías de configuración

Paso 2: Realizar auditoría de configuración Detalle de los Pasos:

Paso 1: Revisar el plan de auditorías de configuración El equipo de desarrollo del proyecto debe revisar el plan de auditorías de configuración como premisa para realizar la auditoria de configuración. Paso 2: Realizar auditoría de configuración Se efectúan las auditorías de configuración definidas en el plan de auditorías de configuración. Se sigue la lista de verificación en donde se detallan los criterios de verificación de cumplimiento de los procedimientos definidos referente al control de la configuración. En una auditoria de configuración se tiene en cuenta:

· Roles de Acceso al sistema · Estructura de almacenamiento · Definición de carpetas y archivos

· Items de configuración cumplidos 6.2. 6.3. El administrador del sistema de control de versiones debe ejecutar la

auditoria según la lista de verificación previamente establecida, y elaborar

69

el documento de auditoría en el cual se ingresa las oportunidades de mejora en la configuración del proyecto. Además, debe hacer seguimiento a la solución de las no conformidades detectadas durante las auditorías y garantizar su resolución.

4.1.2.3. Proceder según resultados de auditoria

Permite corregir las observaciones registradas durante la auditoria.

Proceder según resultados de auditoria Objetivos: Aplicar las acciones correctivas a la configuración del sistema,

resultantes de las auditorias de configuración. Justificación: Aporta a mantener la calidad de la configuración del sistema, teniendo en

cuenta las observaciones de las auditorías de configuración realizadas durante la ejecución del proyecto.

Roles: Equipo de desarrollo del proyecto Artefactos: Pasos: Paso 1: Revisar el documento de auditorías de configuración

Paso 2: Proceder según resultados a la configuración del sistema Detalle de los Pasos:

Paso 1: Revisar el documento de auditorías de configuración El equipo de desarrollo del proyecto debe revisar el documento de auditorías de configuración como premisa para ejecutar acciones a las observaciones encontradas durante la auditoria. Paso 2: Proceder según resultados a la configuración del sistema Se efectúa las modificaciones a la configuración del sistema, para solventar las observaciones producto de las auditorías de configuración.

4.1.3. Liberación de Versiones del Producto

4.1.3.1. Actividad: Liberar versiones del producto

Permite generar una versión del producto, después de concluir con los procesos necesarios para generar una versión.

Liberar versiones del producto Objetivo: Liberar correctamente las versiones del producto desarrollado Justificación: Permite conservar la calidad de las versiones del producto Roles: Equipo de desarrollo del proyecto Artefactos: Documento de liberación de versiones Pasos: Paso 1: Realizar las tareas requeridas para la liberación de una versión

del producto Detalle de los Pasos:

Paso 1: Realizar las tareas requeridas para la liberación de una versión del producto

6.4. El equipo de desarrollo del proyecto debe garantizar la correcta liberación

70

de las versiones del producto, según el siguiente proceso: Los analistas de calidad del proyecto deben generar los casos de prueba para verificar el funcionamiento de la aplicación. La verificación se ejecutará una vez que se haya integrado los componentes de producto y ejecutado las pruebas de integración. La liberación a pruebas se hace según la lista de verificación de liberación de versiones. El proceso de verificación se ejecuta hasta que las no conformidades en pruebas hayan sido solventadas, posterior a eso se genera un release, para liberación, se empaqueta y se publica en el ambiente de producción. Puede darse casos en que no se llega a completar la resolución de todas las no conformidades por lo cual se debe establecer un porcentaje de tolerancia de NC con el que se puede generar el reléase, previamente acordado con el cliente, en este momento se realiza el respectivo empaquetamiento y publica en el ambiente de producción.

4.1.3.2. Establecer línea base del producto

Permite obtener una versión del producto en un determinado estado la cual deberá ser controlada ya que cualquier cambio que se presente deberá seguir el procedimiento de control de cambios definido.

Establecer línea base del producto

Objetivo: Obtener una versión del producto en un determinado estado, lo cual garantiza un correcto manejo de cambios.

Justificación: Permite controlar los cambios que se presenten sobre la versión del producto liberada.


Artefactos:

Pasos: Paso 1: Establecer línea base del producto


Paso 1: Establecer línea base del producto 6.5. Se define la línea base del producto posterior a la liberación de la versión

del producto, después de haber cumplido con los procesos de calidad requeridos.

4.2 Descripción de los Roles

Las actividades del proceso de Gestión de Configuración serán efectuadas por cualquier integrante del equipo de desarrollo del proyecto, siempre que conozca lo necesario.

Rol Abreviatura Competencias

71

Cliente CLI Conocimiento del negocio de acuerdo a su área. Habilidad para explicar los requerimientos del cliente. Poder de decisión. Conocimiento en el software.

Administrador del sistema de gestión de configuración

AGC Capacidad de monitorear y vigilar la integridad y mantenibilidad del sistema completo, la aplicación de las políticas definidas y de las auditorias de todos los ítems de configuración. Conocimiento y experiencia para seguir los procedimientos definidos para el control de la configuración.

4.3. Descripción de Productos

Nombre Descripción

Estandarización de

Documentación de

Proyectos

Documento que estable la distribución de almacenamiento de la documentación del proyecto, en la herramienta SVN.

Estandarización de

Código Fuente de

proyectos

Documento que establece la distribución de almacenamiento del código fuente del proyecto, en la herramienta SNV.

Documento de

actualización de copias

de trabajo

Documento que contiene los pasos que se deben seguir para mantener actualizada la copia de trabajo local de los ítems de configuración a través de la herramienta SVN.

Documento de liberación

de versiones

Documento que contiene las prácticas necesarias para la liberación de tags de versión para verificación de calidad y/o entrega al cliente.

4.4. Descripción de Artefactos

Artefactos Definición

Formulario de creación de

usuarios en el SVN

Formulario con el cual se crea el acceso a los usuarios sobre los elementos del proyecto.

Lista de verificación de

auditorías de configuración

Documento que contiene los aspectos requeridos para realizar las auditorias de configuración.

Plan de auditorías de

configuración

Documento que contiene el plan de las auditorías para el proyecto, teniendo en cuenta la configuración del sistema. Debe contener responsable, fecha y entregable de las auditorías.

Documento de auditoría de

configuración

Documento en el que se registran los resultados de las auditorias de configuración.

72

5. Formatos, Documentos y Herramientas

En esta sección se presenta los formularios y documentos necesarios para el proceso de gestión de la configuración.

Estandarización de Documentación de Proyectos

INTRODUCCIÓN

Este documento constituye una guía para el manejo de la documentación de un proyecto, en algunos casos esa estructura puede cambiar dependiendo de la complejidad del proyecto, en caso de proyectos para mantenimiento, si la estructura no cumple se debe tratar de adaptar a este documento.

1. Objetivo

Administrar de forma centralizada un repositorio donde se almacene la documentación que se genera en el proceso de desarrollo y mantenimiento de software durante las fases del proyecto y poder controlar versiones y cambios en documentos.

2. Responsable

Líder de Aplicaciones

3. Documentación

La documentación digital del proyecto debe ser almacenada mediante la herramienta control de versión SVN, creada para este fin, la documentación física se debe llevar de forma ordena en un mismo lugar y debe ser administrada por el líder del aplicaciones o por quien el designe.

3.1. Repositorio para los proyectos

Los proyectos nuevos deben ser creados con la misma estructura para la gestión de los proyectos, la misma que debe estar de la siguiente forma:

Carpeta Digital: Proyecto

73

3.1.

1 P

RO

YE

CT

OS

JA

VA

Fig

. 12

Est

ruct

ura

de

la d

ocu

men

taci

ón

de

pro

yect

os

Pro

yect

o

<<N

om

bre

Pro

yect

o>

>

Dia

gno

stic

o

Solic

itu

des

Req

uer

imie

nto

s

Mo

del

os

Act

a d

e C

on

stit

uci

ón

d

el P

roye

cto

Do

cum

ento

s

An

ális

is d

e R

equ

erim

ien

to

Req

uer

imie

nto

s

Cas

os

de

Uso

Dia

gram

as

Do

cum

ento

s

Dis

eño

Do

cum

ento

de

Dis

eño

Dia

gram

as

Do

cum

ento

s

Imp

lem

enta

ció

n

Pru

ebas U

nid

ad

Inte

grac

ión

Do

cum

ento

s

Pru

ebas

Pla

n d

e P

rueb

as

Info

rmes

Ret

iro Info

rmes

Pro

ceso

s

Cam

bio

sC

hec

klis

tC

on

figu

raci

ón

Co

nfi

gura

ció

n d

el

Pro

yect

o

Au

dit

orí

as d

e C

on

figu

raci

ón

Lib

erac

ión

de

Ver

sio

nes

Ind

icad

ore

sSe

guim

ien

toD

ocu

men

tos

74

Proyecto: Carpeta principal del repositorio. <<Nombre del Proyecto>>: Corresponde al nombre del proyecto y que contendrá la documentación de todas las fases durante el ciclo de vida del desarrollo o mantenimiento del software. Diagnostico.- Contiene la documentación referente a la fase de diagnóstico del proyecto.

· Solicitudes: Repositorio donde se almacena las actas de reunión de levantamiento de información de solicitudes de usuario.

· Requerimientos: Repositorio donde se almacena la documentación de requerimientos de usuario.

· Modelos: Repositorio donde se almacena los modelos que se realizan durante la fase de diagnóstico.

· Acta de Constitución del Proyecto: Repositorio donde se almacena los modelos el contrato o notificación de adjudicación cuando se adquiere horas de soporte.

· Documentos: Repositorio donde se almacena los modelos la documentación asociada con la fase de diagnóstico del proyecto.

Análisis de requerimientos.- Contiene la documentación referente a la fase de análisis de requerimientos del proyecto.

· Requerimientos: Repositorio donde se almacena el listado y descripción de requerimientos funcionales y no funcionales.

· Casos de uso: Repositorio donde se almacena la especificación de casos de uso.

· Diagramas: Repositorio donde se almacena los diagramas de estados, actividades y casos de uso.

· Documentos: Repositorio donde se almacena la documentación asociados a la fase de análisis de requerimientos.

· Diseño.- Contiene la documentación referente a la fase de diseño del proyecto

· Documento de Diseño: Repositorio donde se almacena los documentos de diseño.

· Diagramas: Repositorio donde se almacena los diagramas de clases, secuencia, modelo relacional de datos, MER.

· Documentos: Repositorio donde se almacena la documentación asociada con la fase de Diseño del proyecto.

Implementación.- Contiene la documentación referente a la implementación del proyecto

§ Pruebas: Repositorio donde se almacena la documentación de pruebas.

· Unidad: Repositorio donde se almacena la documentación de pruebas de unidad.

75

· Integración: Repositorio donde se almacena la documentación de pruebas de integración.

§ Documentos: Repositorio donde se almacena la documentación asociada a la fase de Desarrollo del proyecto, como el manual técnico.

Pruebas.- Contiene la documentación referente a las pruebas realizadas al sistema.

· Plan de Pruebas: Repositorio donde se almacena los planes de pruebas.

· Matriz de Requerimientos: Repositorio donde se almacena la matriz de requerimientos de pruebas.

· Informes: Repositorio donde se almacena los informes parciales de pruebas funcionales e informe final de pruebas.

· Documentos: Repositorio donde se almacena la documentación asociada con la fase Pruebas del proyecto.

Procesos.- Contiene la documentación referente a la ejecución de procesos transversales durante el proyecto

· Cambios: Repositorio donde se almacena la documentación generada para la gestión de cambios del proyecto.

· Lista de Verificación: Repositorio donde se almacena la documentación de las evidencias de las revisiones de procesos y productos de trabajo, realizadas durante el proyecto.

· Configuración: Repositorio donde se almacena la documentación relacionada con la gestión de la configuración del proyecto.

· Configuración del Proyecto: Repositorio donde se almacena la documentación referente con la configuración del proyecto, como documentación de administración de usuarios en el SVN

· Auditorias de Configuración: Repositorio donde se almacena la documentación relacionada con las auditorias de configuración del proyecto, como planes de auditorías.

· Liberación de Versiones: Repositorio donde se almacena la documentación relacionada con el proceso de liberación de versiones del producto.

· Indicadores: Repositorio donde se almacena la documentación relacionada con la gestión de los indicadores del proyecto, como lista de indicadores y las fichas técnicas de los indicadores.

· Nombre Proceso: Repositorio donde se almacena la documentación propia del proceso en el que se está trabajando.

· Seguimiento: Repositorio donde se almacena la documentación referente con el proceso de seguimiento y control del proyecto es decir los reportes de seguimiento semanales y la matriz de riesgos.

· Documentos: Repositorio donde se almacena la documentación relacionada con los procesos transversales del proyecto, que no se incluyen en los demás repositorios.

76

3.2. Nomenclatura de los productos de trabajo A continuación se detalla las nomenclaturas de la documentación generada generados en el proceso:

Producto de trabajo Abreviación Solicitud de modificación SOL_MOD Lista de requerimientos funcionales y no funcionales

LIS_REQ

Requerimientos REQ Casos de uso CAS_USO Lista de Verificación LIV Manual técnico MAN_TEC Pruebas de unidad e integración PUI Documento de diseño DOC_DIS Acta de reunión ACR Cronograma CRO Administración de usuarios svn ADM_USU Documento de auditorías de configuración DAC Plan de auditorías de configuración PAC Listado de indicadores LIS_IND Ficha técnica de indicadores FIC_TEC_IND Detalle de requerimientos de usuario DET_REQ_USU Acta de Constitución ACT_CON Matriz de requerimientos de pruebas MRP Informe parcial de pruebas IPP Informe final de pruebas IFP Matriz de riesgos MAT_RIE Reporte de seguimiento semanal RSS Reporte semanal de revisiones personalizadas RRP Diagrama de estados DIA_EST Diagrama de actividades DIA_ACT Diagrama de clases DIA_CLA Diagrama de secuencia DIA_SEC Modelo Entidad Relación MRD Diagrama de casos de usos DCU

Estandarización de Código Fuente de proyectos

INTRODUCCIÓN

Este documento constituye una guía para el manejo estándar de la codificación de un proyecto, en algunos casos esa estructura puede cambiar dependiendo de la complejidad

77

del proyecto, en caso de proyectos para mantenimiento, si la estructura no cumple se debe tratar de adaptar a este documento.

1. Objetivo

Establecer una estructura estandarizada para el código fuente generada así como el estándar para paquetes y clase generados en los proyectos de java durante el ciclo de vida del proyecto. 2. Responsable


3. Contenido

El código fuente del software con el que cuenta la institución, deberá ser almacenado y gestionado mediante una herramienta de control de versiones SVN, la misma que debe permitir la compartición y actualización de los cambios en los diferentes módulos, esto no debe afectar, a lo que ya se encuentra desarrollado, a menos que sea una solicitud de cambio sobre algo establecido.

Para proyectos nuevos el líder de aplicaciones o responsable deberá crear el repositorio en el SVN, en caso de mantenimiento a un software existente se deberá dar acceso a las personas que intervendrá en este proceso, para que se proceda con la descarga actualizada.

3.1 Repositorio para los proyectos:

El repositorio donde se almacena el código fuente del software deberá contener está estructura.

Repositorio SVN: Proyecto

3.1.1. PROYECTOS JAVA

3.1.1.1. Estructura

78

Fig. 13 Estructura de Código Fuente

Proyecto: Repositorio que almacena el código fuente del proyecto, como es un proyecto en svn se crea con esta estructura:

· trunk.- Rama principal que contiene el código fuente desde el inicio hasta el momento actual del proyecto.

· tags.- Es una rama que contiene un punto en el tiempo de la rama principal, aquí se debe almacenar para mantener una versión principal del software, ya sea alfa, beta, RC o RTM, o un punto más estable del software antes de que se aplicaran las principales revisiones en la rama principal.

· Brunches.- Es una rama derivada de la principal en un punto para aplicar cambios sin afectar a la integridad del código principal y una vez verificado debe integrarse a la rama principal.

<<Nombre del proyecto>>: Nombre del software El proyecto es una aplicación empresarial que contiene varios aplicativos como son:

ü prjMensajeria.- Maneja la mensajería a nivel del aplicativo ü prjUtilitarios.- Maneja la conexión a nivel de hibernate ü prjApp.- Maneja las clases mapeadas de la base de datos ü prjWeb.- Maneja la vista del aplicativo. ü prjSeguridad.-Maneja el nivel de seguridad. Cada uno de estos aplicativos contiene los diferentes módulos.

3.1.1.2. Definición de nombres de proyectos

Proyecto

trunk

prjMensajeria

ec.gob.uafe.modulo

prjUtilitario

ec.gob.uafe.modulo

prjApp

ec.gob.uafe.modulo

prjWeb

ec.gob.uafe.modulo

prjSeguridad

ec.gob.uafe.modulo

tags brunches

79

Los nombres de los proyectos deben escribirse en lowerCamelCase3 con la siguiente estructura: <<abreviatura>>«nombre del proyecto»

<<abreviatura>>: La abreviatura corresponde proyecto prj

<<nombredelproyecto>>: El nombre del proyecto debe permitir identificar cual es la

funcionalidad. Ej:prjMensajeria 3.1.1.3. Definición de nombres de paquetes Los nombres de los paquetes deben escribirse en minúsculas sin espacios ni guiones deben tener la siguiente estructura:uafe.gob.ec.«nombre de la aplicación».«nombre del

paquete»

Ej: uafe.gob.ec.prjMensajeria.dto 3.1.1.4. Definición de nombres de objetos de negocio Las Clases deben tener nombres claros, palabras completas referenciados a una tabla de la base de datos dependiendo de su función pueden ser DAO, Service, Impl, el nombre deben escribirse en UpperCamelCase1. Las abreviaturas pueden ser utilizadas en el nombre de la clase únicamente cuando sean ampliamente utilizadas. La apertura de la clase se identifica con llaves, la llave de inicio debe estar en la siguiente línea y la llave de fin debe estar alineada. Ej: Nombre de la tabla Institución Clase: InstitucionServiceImpl

· Las excepciones deben tener el sufijo Exception. Ej: ElementoNoExisteException

3.1.1.5. Definición de nombres de Interfaces para objetos de negocio Las interfaces definidas deben ser declaradas según el nombre de la tabla dentro del paquete correspondiente a interfaces. Ej: Nombre de la tabla capacitación Interfaz: CapacitacionGestor 3.1.1.6. Definición de nombres de métodos Los nombres de los métodos deben ser claros e identificar la funcionalidad deben ser verbos y se escriben en lowerCamelCase4. El detalle del método debe estar correctamente indentado. Las llaves de apertura y cierre deben estar en líneas separadas. Métodos declarados en interfaces o clases abstractas no deben llevar espacio entre el paréntesis derecho y el punto y coma. Ej: uploadArchivoExcel()

3UpperCamelCase es un nombre compuesto por varias palabras donde estas están unidas sin espacios y cada letra inicial de una palabra está en mayúscula. 4lowerCamelCase es un nombre compuesto por varias palabras donde estas están unidas sin espacios, la letra inicial de la primera palabra está en minúscula y las demás letras iniciales de las siguientes palabra están en mayúscula

80

getNombreInstitucion(); guardarArchivoExcel() { } 3.1.1.7. Definición de nombres de variables Las variables no deben iniciar con ningún símbolo o número. Los nombres deben ser cortos pero claros, es decir, deben indicar la finalidad de su uso. Las variables no pueden ser de un solo carácter. Las variables de elementos de la GUI deben tener como prefijo el tipo de elemento. Ej.: Cliente cliente; int resultado ButtonbuttonEditar 3.1.1.8. Definición de constantes Las constantes se escribirse en letra MAYÚSCULA. Cuando se compongan por más de una palabra deben ser separadas por guion bajo Ej: final static int PI=3.141516 3.1.1.9. Definición de operadores Los operadores deben ir separados por un espacio a excepción del punto y el corchete de apertura. Ej: unidad.getContenido(); resultado = 1; arreglo[0]; 3.1.1.10. Definición de sentencias Una sentencia debe ser colocada en cada línea, la misma que concluye con punto y coma (;), se debe colocar indentada Ej: institución.getRazonSocial(); if (42 == a) {

... } 3.1.1.11. Definición de comentarios del código fuente Los métodos deben tener un comentario que permita entender la funcionalidad del mismo, estos deben ir antes de la sentencia a la que se hace referencia. El equipo de trabajo debe tener conocimientos en cuando a codificación estándar java se refiere, para mayor detalle sobre este tema puede consultar en el siguiente enlace: http://javafoundations.blogspot.com/2010/07/java-estandares-de-programacion.html

Documento de administración de usuarios en el SVN

ADMINISTRACION DE USUARIOS DE SVN

81

Proyecto: Nombre del proyecto

Líder de Proyecto:

Nombre del líder del proyecto

Fecha: Fecha de solicitud

Tipo de solicitud

Usuario Acceso Ítem de

Configuración Ambiente

Creación,

Actualización

Se

ingresa

el

nombre

del

usuario a

crear o

gestionar

Valores:

Consulta,

Actualización,

Eliminación

Se relaciona el

o los ítems de

configuración

sobre los

cuales se van

a gestionar los

permisos

Valores:

Desarrollo,

Pruebas,

Producción

Fecha de Atención:

Atendido por:

Observaciones:

Solicitante

Jefe Inmediato

Autorizado por Coordinador

Lista de verificación de auditorías de configuración

82

Pla

n d

e au

dit

orí

as d

e co

nfi

gu

raci

ón

PL

AN

DE

AU

DIT

OR

IAS

DE

CO

NF

IGU

RA

CIO

N

Pro

yect

o:

Nom

bre

del p

royecto

Líd

er d

e P

roye

cto

: N

om

bre

del líder

del pro

yecto

Fec

ha:

F

echa d

e e

labora

ció

n d

el p

lan

Id

enti

fica

do

r F

ech

a R

esp

on

sab

le

En

treg

able

s

Ro

l d

el

Par

tici

pan

tes

Par

tici

pan

te(s

) O

bse

rvac

ion

es

Num

ero

de

identificador

de

la a

uditoria

Fecha

pro

gra

mada

para

la

realiz

ació

n

de

auditorí

as

de

configura

ció

n

del p

royecto

Nom

bre

del

responsable

de

realiz

ar

las

auditorí

as

Pro

ducto

s

pre

via

mente

definid

os

com

o

entr

egable

s p

ara

cada

auditoria

de c

onfigura

ció

n

Rol(es)

de

la

pers

ona(s

) que

part

icip

a

en

la

auditorí

a

Nom

bre

(s)

de l

a(s

)

pers

ona(s

) que

part

icip

an

en

las

auditorí

as

Indiq

ue

las

observ

acio

nes

a

consid

era

rse

en

la

auditoria

83

Documento de auditoría de configuración


Líder de Proyecto: Nombre del líder del proyecto o de la persona que elabora el plan

Fecha: Fecha de elaboración del documento

Identificador: Número identificador de la auditoria

Responsable: Nombre de la persona que realizó la auditoría

Participante(s): Nombre(s) de las persona(s) que participaron en la auditoría

Entregables Auditados:

Entregables que fueron auditados durante la auditoría de

configuración

Resultados: Describa los hallazgos de la auditoria, considerando los listados de

chequeo de auditorías de configuración definida. Además describa

cualquier aspecto importante a considerar para administrar

adecuadamente la configuración del sistema.

Observaciones: Registre los comentarios u observaciones que pudieran

presentarse en la auditoria.

Documento de liberación de versiones

INTRODUCCIÓN

Este documento constituye una guía para el manejo de liberación de versiones estándar de la codificación de un proyecto.

Objetivo:

Establecer el proceso de liberación de versiones para la respectiva verificación por parte de los analistas de calidad y/o área requiriente.

Objetivos Específicos:

· Establecer las tareas para la generar de tag de versión.

· Establecer las tareas para la entrega del tag de versión. Responsable: El analista encargado de generar el tag de versión debe recopilar la información del tag de versión, agregar la documentación adicional requerida y entregar el tag de versión al solicitante (analistas de calidad o área requiriente). Descripción General:

84

Los miembros del equipo de desarrollo del proyecto deben determinar el momento en que se requiere generar un tag de versión. Para la generación de tags de versión el responsable debe garantizar que la revisión que se incluirá esté funcionando completamente para evitar la generación de release incompletos.

Para la generación de versiones realizamos posterior a que todos los cambios se hayan realizado commit dentro de las ramas respectivas.

Esta versión si pasa a la revisión por parte de los analistas de calidad debe ser cargada en el ambiente correspondiente.

Ante cualquier reconstrucción, regeneración o actualización de la versión, el responsable deberá notificar al Líder de aplicaciones y al funcionario que corresponde sobre la nueva versión disponible.

Se debe considerar lo siguiente:

· El proyecto cambia de versión ante cambios de alcance del mismo, es decir incorporación o eliminación de requerimientos.

· El proyecto no cambia de versión si lo implementado corresponde al mejoramiento de algún requerimiento previamente implementado.

Cuando se genere una nueva versión se debe considerar:

· Librerías adicionales · Esquema de datos de prueba.

· Valores de configuración y parámetros de la aplicación · Documentación adicional

Para la generación de compilados o copias de distribución se deberá utilizar un equipo previamente configurado con las librerías y sistema operativo determinados en la especificación funcional del proyecto.

Herramientas Para realizar la administración de la configuración del sistema se definió como herramienta de soporte SVN.

85

ANEXO V: PROCESO DE MEDICIÓN Y ANALISIS

PROCESO

DE MEDICIÓN Y ANALISIS

V1.0

86


Fecha Creación Descripción Autor Versión

15/09/2018 Proceso Medición y

Análisis

Ximena Mendoza 1.0

87

Contenido

1. Descripción Técnica .................................................................................................................. 88

Introducción ................................................................................................................................. 88

Objetivo del documento ............................................................................................................. 88

Importancia .................................................................................................................................. 88

2. Definiciones ................................................................................................................................. 88

Conceptos Generales ................................................................................................................ 88

Conceptos Específicos .............................................................................................................. 88

3. Relación del proceso con el modelo CMMI ........................................................................... 89

4. Descripción del Proceso ........................................................................................................... 90

4.1. Actividades ........................................................................................................................... 91

4.1.1. Establecer objetivos y métricas de medición .......................................................... 91

4.1.2. Realizar el formulario de los indicadores ................................................................. 92

Realizar el formulario de los indicadores ............................................................................ 92

4.1.3. Recopilación de datos para medición de indicadores ........................................... 92

4.1.4. Realizar la medición y análisis de los indicadores ................................................ 93

4.1.5. Establecer acciones correctivas ................................................................................ 93

4.2 Descripción de los Roles .................................................................................................... 94

4.3. Descripción de Productos.................................................................................................. 94

4.4. Descripción de Artefactos.................................................................................................. 95

5. Formatos ..................................................................................................................................... 95

· Lista de Indicadores ........................................................................................................... 95

· Formulario del Indicador .................................................................................................... 96

88


Introducción

El documento contiene un conjunto de artefactos desarrollados para facilitar la implementación del proceso Medición y Análisis en una institución que cuenta con un área de desarrollo de software. Los elementos característicos son: descripción de procesos, actividades, tareas, roles plantillas y herramientas.

Objetivo del documento

Proporcionar los lineamientos para realizar el proceso de Medición y Análisis dentro de los proyectos de desarrollo y mantenimiento de software.

Importancia

El proceso de medición y análisis es importante ya que se establece indicadores de medición, los cuáles se implementarán en los proyectos de desarrollo y mantenimiento de software, los mismos con los que se medirá el grado de adaptación del proyecto a los procesos establecidos para su ejecución y poder tomar acciones correctivas necesarias para minimizar los errores y garantizar la calidad del producto final.

2. Definiciones


Conceptos Generales









· Indicador: medida que permite el monitoreo del parámetro de avance en el

cumplimiento de objetivos y metas, el que proporciona un medio y refleja los cambios vinculados con una intervención o ayudar a evaluar los resultados.

89

· Acción Correctiva: es aquella que se lleva a cabo para eliminar la causa de un problema. Las correcciones atacan los problemas, las acciones correctivas sus causas.


En esta sección se detalla las actividades relacionadas al proceso de medición y análisis para proyectos de desarrollo y mantenimiento de software. El área del proceso Medición y Análisis (MA) del modelo CMMI-Dev versión 1.3 (Capability Maturity Model Integration reúne un conjunto de prácticas que guían y garantizan la correcta definición, administración y aplicación de los indicadores de medición durante la implementación de un proyecto de desarrollo y mantenimiento de software. Este proceso aplica para proyectos de desarrollo y mantenimiento de software a la medida, de complejidad media de duración corta. Para realizar el proceso de medición y análisis se elaboraron unos formularios y documentos que permite cumplir con este proceso. En la figura 1 se presenta la ubicación del proceso de Medición y Análisis dentro de los procesos del ciclo de vida del desarrollo de software.


En la figura 2 se presenta la ubicación del proceso de Gestión de Configuración dentro del ciclo de vida de mantenimiento de software.

90



En esta sección se describe el proceso de Medición y Análisis con las actividades necesarias para su ejecución. En la figura 3 muestra el diagrama que contiene las actividades que se ejecutan dentro proceso de medición y análisis incluyendo los productos de trabajo generados durante el proceso.

Diseño

Implementacion

Prueba del

Sistema

Prueba de Aceptacion

Liberacion

Clasificacion e Identificacion

Analisis

Medición y Análisis

91

Figura 4 — Proceso de Medición y Análisis

4.1. Actividades

El proceso de Medición y Análisis (MA) tiene las siguientes actividades que se detallan a continuación.

4.1.1. Establecer objetivos y métricas de medición

Garantiza que el proceso de medición y análisis se realice de forma correcta, puesto que permite identificar los indicadores que incrementan valor al proyecto, teniendo en cuenta los objetivos del mismo.

Establecer objetivos y métricas de medición Objetivo: Establecer los objetivos y métricas que permitirán controlar el

proyecto versus los procesos establecidos para su ejecución. Justificación: Permite verificar la adaptación de los proyectos a los procesos

definidos para su ejecución, determinando que continúen y se utilicen los artefactos definidos en cada fase del proyecto.

Roles: Equipo de desarrollo del proyecto Artefactos: Lista de Indicadores Pasos: Paso 1:Revisar el documento estándar de la lista de indicadores

Paso 2: Establecer los objetivos y métricas de medición Detalle de Pasos:

Paso 1: Revisar el estándar de la lista de indicadores El equipo de desarrollo del proyecto debe revisar el documento estándar de la lista de indicadores como premisa para la selección y definición de los objetivos de medición del proyecto.

92

Paso 2: Establecer los objetivos y métricas de medición El equipo de desarrollo del proyecto debe seleccionar los indicadores a utilizarse en el proyecto, según el entorno y a partir de los indicadores seleccionados definir los objetivos y la métrica de medición de cada indicador.

4.1.2. Realizar el formulario de los indicadores

Permite la consolidación de información de cada indicador en un solo documento y establecer la administración de los indicadores durante la ejecución del proyecto.

Realizar el formulario de los indicadores Objetivos: Consolidar la información de cada indicador en un solo documento y

establecer la administración de los indicadores durante la ejecución del proyecto.

Justificación: Permite una correcta administración de indicadores de medición del proyecto de forma adecuada.

Roles: Equipo de desarrollo del proyecto Artefactos: Formulario de indicadores Pasos: Paso 1: Establecer el formulario de cada indicador de medición

Paso 2: Revisar con el equipo el formulario de los indicadores Detalle de los Pasos:

Paso 1: Establecer el formulario de cada indicador de medición El equipo de desarrollo del proyecto debe establecer el formulario de cada indicador, la cual debe incluir la siguiente información: responsables de la medición y del análisis, objetivos del indicador, formula, valores límite que el indicador puede tomar, meta y fuente de datos para la medición, periodicidad y repositorio de la información. Paso 2: Revisar con el equipo de desarrollo el formulario de los indicadores Una vez establecido el formulario del indicador se debe validar este documento con el equipo, para lograr el compromiso para este sea aplicado al proyecto.

4.1.3. Recopilación de datos para medición de indicadores

Permite recolectar los datos necesarios para realizar la medición de los indicadores

establecidos. Debe garantizar que los datos recopilados son correctos para que no altere

el resultado de las mediciones.

Recopilación de datos para medición de indicadores Objetivo: Recopilar los datos necesarios para realizar la medición de los

indicadores establecidos. Justificación: Permite contar con los datos requeridos para la medición de los

indicadores establecidos.

93

Roles: Equipo de desarrollo del proyecto Artefactos: Pasos: Paso 1: Revisar el formulario de indicadores

Paso 2: Recopilar datos para los indicadores de medición Detalle de Pasos:

Paso 1: Revisar el formulario de los indicadores El equipo de desarrollo del proyecto debe revisar el formulario de indicadores como premisa para la búsqueda y recopilación de los datos requeridos para las mediciones. Paso 2: Recopilar datos para los indicadores de medición El responsable de cada indicador deberá indagar y recopilar la información requerida para la medición de cada indicador, garantizando que los datos sean válidos y no alteren el resultado de las mediciones.

4.1.4. Realizar la medición y análisis de los indicadores

Permite elaborar la métrica de medición de cada indicador y analizar los resultados obtenidos en la medición.

Realizar la medición y análisis de los indicadores Objetivo: Realizar la medición de los indicadores y analizar los resultados

obtenidos en la medición. Justificación: Permite tener un control del proyecto considerando los procesos

establecidos para su ejecución. Roles: Equipo de desarrollo del proyecto Artefactos: Formulario de indicadores Pasos: Paso 1: Revisar los datos recopilados para las mediciones

Paso 2: Realizar la medición de los indicadores y analizar los resultados de medición

Descripción de Pasos:

Paso 1: Revisar los datos recopilados para las mediciones El responsable debe verificar y detectar cualquier inconsistencia en los datos, si esto ocurre se debe volver a recopilar datos hasta que sea confiable. Paso 2: Realizar la medición de los indicadores y analizar los resultados de medición Se realiza la medición y análisis de los resultados obtenidos en cada medición, se debe realizar el informe que contenga la interpretación y causas del resultado del indicador con el cual se establecen las acciones a implementar cuando sea necesario.

4.1.5. Establecer acciones correctivas

Establecer las acciones correctivas permite identificar las actividades que se deben realizar cuando el resultado de las mediciones de los indicadores ha estado por debajo de la meta esperada del indicador.

94

Establecer acciones correctivas Objetivos: Determinar las actividades que deben realizarse cuando el

resultado de las mediciones está por debajo de lo que puede ser aceptado.

Justificación: Tomar medidas cuando el proyecto tiene alguna desviación detectada con la medición de los indicadores.

Roles: Equipo de desarrollo del proyecto Artefactos: Cronograma del proyecto Pasos: Paso 1: Revisar análisis de los resultados de las mediciones de los

indicadores Paso 2: Establecer las acciones correctivas

Detalle de Pasos:

Paso 1: Revisar el análisis de los resultados de la medición de los indicadores El equipo de desarrollo del proyecto debe revisar los resultados de las mediciones de los indicadores para establecer las acciones para solucionar los problemas encontrados. Paso 2: Establecer acciones correctivas Se realiza plan de acciones correctivas considerando el análisis de los resultados de las mediciones y las acciones a implementar definidas en el formulario de los indicadores. Establecer responsable, tiempo y fecha para efectuar cada acción correctiva. Las acciones correctivas se registran en el cronograma del proyecto. Se debe detallar el mecanismo de seguimiento que se realizará a las acciones correctivas, hasta el cierre de los problemas reportados. Esto se debe considerar en el proceso de Seguimiento y Control.


Las actividades del proceso de Medición y Análisis serán efectuadas por cualquier miembro del equipo de desarrollo del equipo del proyecto. Rol Abreviatura Competencias


LA Capacidad para liderar y motivar a los miembros del equipo del proyecto. Buenas relaciones y habilidades de comunicación. Persona proactiva y organizada.


Nombre Descripción Cronograma del

proyecto

Documento en el cual se deben agregar las acciones correctivas resultantes de la medición de los indicadores.

95



Lista de Indicadores Lista de indicadores estándar, que contiene el nombre, objetivo y formula del indicador y el proceso relacionado.

Formulario del indicador Documento que contiene la información de cada indicador: responsables de la medición y del análisis, objetivos del indicador, formula, valores límite que el indicador puede tomar, meta y fuente de datos para la medición, periodicidad y repositorio.

· Fuente de información, de donde va a obtener los datos.

· Periodicidad, cada cuanto va a recolectar los datos. · Repositorio, donde se van a almacenar los datos para

realizar la medición.

5. Formatos

En esta sección se mencionan algunos de los formatos necesarios para este proceso, los

mismos deben ser ajustados de acuerdo a la realidad de cada proyecto.

· Lista de Indicadores

LISTA DE INDICADORES

ID Indicador Propósito Indicador

Fórmula Proceso

Relacionado Observaciones

1

Porcentaje de cumplimiento del proyecto en alcance

Conocer el porcentaje de cumplimiento de las actividades en base al alcance del proyecto

(Cantidad de requerimientos desarrollados) / (Cantidad de requerimientos definidos para desarrollar)*100

Análisis de Requerimientos Gestión de Requerimientos

2

Porcentaje de cumplimiento del proyecto en tiempo

Conocer el porcentaje de cumplimiento de las actividades en base cronograma planificado

(Cantidad de actividades terminadas a la fecha de la medición) / (Cantidad de actividades que deben estar terminadas a la

Diagnóstico Seguimiento y Control

96

fecha de la medición)*100

· Formulario del Indicador

FORMULARIO INDICADOR

“Nombre del Indicador”

DETALLE DEL INDICADOR

Proceso: Nombre del proceso en el cual se requiere hacer la medición

Responsable Medición:

Nombre de la persona responsable de realizar la medición

Responsable Análisis:

Nombre de la persona responsable de realizar el análisis

Indicador: Nombre del indicador

Objetivo Indicador:

Objetivo del indicador

Fórmula: Fórmula para calcular el indicador

Meta: Resultado estimado de la medición del indicador

Datos a recopilar:

Datos que se necesitan recopilar para la medición del indicador

Límite Inferior: Límite inferior del resultado de la medición del indicador

Límite Superior:

Límite superior del resultado de la medición del indicador

RECOPILACIÓN DE DATOS Fuente de información:

Fuente que se utilizara para recolectar los datos para la medición

Frecuencia: Frecuencia para la recopilación de datos

Procedimiento de recopilación:

Procedimiento para recopilar los datos de medición

Repositorio: Directorio del SVN en la cual se almacenan los datos de medición

recolectados

ANALISIS

Frecuencia: Frecuencia de los resultados del análisis de la medición

Fecha de elaboración:

Fecha de elaboración del análisis

Periodo evaluado:

Periodo que se analiza con la medición del indicador

Resultado: Resultado adquirido de la medición del indicador

97

Gráfica Gráfica con los resultados de la medición, se debe seguir el formato de

gráfica presentado a continuación:

Análisis

Cumplimiento Acción a

tomar Responsable

M=Malo R=Regular B=Bueno MB=Muy Bueno

Acción a

tomar

dependiendo

del nivel de

cumplimiento

Responsable de

ejecutar la

acción

registrada

Causas del resultado

Causas del resultado de la medición del indicador

Acciones a implementar

Actividades que se deben realizar para corregir los problemas

presentados en el proceso que se analiza con la medición del indicador.

Esto aplica cuando el resultado de la medición del indicador es malo o

regular.

0%

2000%

4000%

6000%

8000%

10000%

12000%

0 1 2 3

Act

ivid

ade

s

Semanas

DebajoLimiteMínimoLimiteMínimo

LimiteMáximo

EncimaLimiteMáximo

98

ANEXO VI: PROCESO DE SEGUIMIENTO Y CONTROL

PROCESO

DE SEGUIMIENTO Y CONTROL

V1.0

99


Fecha

Creación


15/09/2018 Proceso de Seguimiento

y Control

Ximena Mendoza 1.0

100

Contenido

1. Descripción Técnica ................................................................................................................ 101

Introducción ............................................................................................................................... 101

Objetivo del documento ........................................................................................................... 101

Importancia del proceso de Seguimiento y Control ............................................................ 101

2. Definiciones ............................................................................................................................... 101

Conceptos Generales .............................................................................................................. 101

Conceptos Específicos ............................................................................................................ 101

3. Relación del proceso con el modelo CMMI ......................................................................... 102

4. Descripción del Proceso ......................................................................................................... 103

4.1. Actividades ......................................................................................................................... 103

4.1.1. Realizar reunión semanal de seguimiento ............................................................ 104

4.1.2. Efectuar el reporte de seguimiento semanal ......................................................... 104

4.1.3. Efectuar revisiones personalizadas ........................................................................ 105

4.1.4. Efectuar reporte semanal de revisiones personalizadas .................................... 106

4.1.5. Efectuar análisis de riesgos al finalizar cada iteración ........................................ 106

4.2 Descripción de los Roles .................................................................................................. 107

4.3. Descripción de Productos................................................................................................ 107

4.4. Descripción de Artefactos................................................................................................ 108

5. Formatos ................................................................................................................................... 108

Reporte de seguimiento semanal .......................................................................................... 108

Reporte semanal de revisiones personalizadas .................................................................. 110

Matriz de riesgos ...................................................................................................................... 110

101

1. Descripción Técnica Introducción El documento contiene un conjunto de artefactos desarrollados para facilitar la implementación de procesos en una institución que cuenta con un área de desarrollo de software. Los elementos característicos son: descripción de procesos, actividades, tareas, roles plantillas y herramientas.

Objetivo del documento Proporcionar la línea base para realizar el proceso de Seguimiento y Control dentro de los proyectos de desarrollo y mantenimiento de software, en proyectos ejecutados en periodos cortos de tiempo. Importancia del proceso de Seguimiento y Control El proceso de seguimiento y control es importante porque define los mecanismos de seguimiento con los cuales se controlarán las actividades del proyecto, para garantizar su ejecución dentro del alcance, tiempo y costo definidos.

2. Definiciones Esta sección contiene la definición de conceptos generales y específicos que se utilizan en el proceso.

Conceptos Generales


· Actividad: un conjunto de tareas de un proceso. [ISO/IEC 12207]. · Tarea: Acción permisible que pretende contribuir al cumplimiento de una o más

metas de un proceso. [ISO/IEC 12207].

· Paso: una tarea se descompone en una secuencia de pasos. · Rol: una función definida para ser realizada por un miembro del equipo de

desarrollo del proyecto. [ISO/IEC 24765]

· Producto: entregable tangible o intangible que puede ser por una o varias tareas. · Artefacto: información que apoya al proceso durante la ejecución de un proyecto.


· Acción Correctiva: Se ejecuta una vez presentado el incidente, el mismo que debe ser solventado.

· Acción Preventiva: Se ejecuta con la finalidad de que no ocurra un incidente. Evita los problemas identificando los riesgos. El riego se disminuye siempre que se ejecuta una acción preventiva.

102


En esta sección se describe las actividades relacionadas al proceso de seguimiento y control para proyectos de desarrollo y mantenimiento de software. El área de proceso Monitorización y Control del proyecto (PMC) del modelo CMMI

Development versión 1.3 (Capability Maturity Model Integration) reúne un conjunto de prácticas que orientan y garantizan la correcta definición y ejecución de las actividades de seguimiento durante la ejecución de un proyecto de desarrollo y mantenimiento de software. Este proceso aplica para proyectos de desarrollo y mantenimiento de software a la medida, de complejidad media de duración corta. Para realizar el proceso de seguimiento y control se elaboraron una serie formatos y documentos que permiten el registro de las actividades del proceso. En la figura 1 se muestra donde se ubica el proceso de seguimiento y control dentro de los procesos del ciclo de vida del desarrollo de software.


En la figura 2 se presenta la ubicación del proceso de Seguimiento y control dentro del

ciclo de vida de mantenimiento de software.

DiagnósticoAnálisis de

RequerimientosDiseño Implementación Pruebas

Administración de

Requerimiento

Gestión de

Configuración

Medición y

Análisis

Aseguramiento de

Calidad

Seguimiento y

Control

103



En esta sección se describe cómo funciona el proceso de seguimiento y control, las actividades que involucra y los productos de trabajo que se generan durante este proceso.

Figura 3 — Proceso de Seguimiento y Control

4.1. Actividades El proceso de Seguimiento y Control (SC) tiene las siguientes actividades que se detallan a continuación.

Diseño

Implementacion

Prueba del

Sistema


Liberacion


Analisis

SEGUIMIENTO Y CONTROL

104

4.1.1. Realizar reunión semanal de seguimiento Facilita información acerca del estado del proyecto, considerando el porcentaje de avance de las actividades establecidas en el plan del proyecto.

Realizar reunión semanal de seguimiento Objetivo: Facilitar información importante acerca el estado del proyecto,

considerando el porcentaje de avance de las actividades establecidas en el plan del proyecto.

Justificación: Permite conocer el avance del proyecto y monitorear que se cumplan los hitos del proyecto.

Roles: Equipo de desarrollo del proyecto Artefactos: Cronograma del proyecto

Acta de Reunión Pasos: Paso 1: Revisar el cronograma del proyecto

Paso 2: Realizar reunión de seguimiento semanal Detalle de Pasos:

Paso 1: Revisar el cronograma del proyecto El responsable designado por el equipo de desarrollo del proyecto revisará el cronograma del proyecto e identificar el porcentaje de avance planificado antes de la reunión de seguimiento. Paso 2: Realizar reunión de seguimiento semanal Se lleva a cabo la reunión de seguimiento semanal y se revisa el porcentaje de avance de las actividades establecidas en el plan del proyecto y se estableces las medidas correctivas cuando el avance real es menor que el avance estimado del proyecto. Durante esta reunión de debe elaborar el acta de la reunión y los compromisos de los miembros del equipo de desarrollo del proyecto para la próxima reunión.

4.1.2. Efectuar el reporte de seguimiento semanal

Permite formalizar en un documento los resultados obtenidos de la reunión de seguimiento. Este documento corresponde al entregable que se hace al Director de SIT para evidenciar el estado del proyecto.

Efectuar el reporte de seguimiento semanal Objetivo: Formalizar en un documento los resultados de la reunión de

seguimiento semanal. Justificación: Permite consolidar los resultados de las reuniones de seguimiento

semanales, que se ejecutan para conocer el estado del proyecto semanalmente.

Roles: Equipo de desarrollo del proyecto Artefactos: Reporte de seguimiento semanal Pasos: Paso 1: Revisar el acta de la reunión de seguimiento semanal de

actividades

105

Paso 2: Elaborar el reporte de seguimiento semanal Detalle de los Pasos:

Paso 1: Revisar el acta de la reunión de seguimiento semanal de actividades El responsable de ejecutar el seguimiento del proyecto debe revisar el acta de la reunión de seguimiento, como premisa para la elaboración del reporte de seguimiento en el formato establecido para ese fin. Paso 2: Elaborar el reporte de seguimiento semanal El responsable de ejecutar el seguimiento del proyecto debe elaborar el reporte de seguimiento del proyecto, considerando el avance estimado y el avance real en el formato establecido para tal fin. El reporte debe contener las acciones correctivas requeridas.

4.1.3. Efectuar revisiones personalizadas

Efectuar revisiones personalizadas proporciona información acerca del trabajo de cada miembro del equipo de desarrollo del proyecto, considerando el porcentaje de avance de las actividades asignadas.

Efectuar revisiones personalizadas Objetivos: Facilitar información sobre el desempeño de cada uno de los

miembros del equipo de desarrollo del proyecto, considerando el porcentaje de avance de las actividades asignadas.

Justificación: Dar a conocer el estado y calidad del trabajo realizado por cada miembro del equipo de desarrollo del proyecto y ayuda a evitar duplicidad y control cuando se presenta un problema en el proyecto.

Roles: Equipo de desarrollo del proyecto Artefactos: Cronograma del proyecto Pasos: Paso 1: Revisar el cronograma del proyecto

Paso 2: Ejecutar revisión a cada miembro del equipo de desarrollo del proyecto

Detalle de Pasos:

Paso 1: Revisar el cronograma del proyecto El responsable designado por los miembros del equipo de desarrollo del proyecto revisará el cronograma e identificar el porcentaje de avance estimado de las actividades, antes de realizar las revisiones personalizadas. Paso 2: Ejecutar revisión a cada miembro del equipo del proyecto Se revisa el trabajo realizado por cada miembro del equipo de desarrollo del proyecto, en la que se evidencia el porcentaje de avance y la calidad de las actividades realizadas y se definen las acciones correctivas cuando el avance real es menor que el avance estimado.

106

4.1.4. Efectuar reporte semanal de revisiones personalizadas Permite formalizar en un documento los resultados de las revisiones de las actividades de cada miembro del equipo de desarrollo del proyecto realizadas semanalmente.

Efectuar reporte semanal de revisiones personalizadas Objetivos: Formalizar en un documento los resultados de las revisiones de

las actividades asignadas a cada miembro del equipo. Justificación: Dar a conocer los resultados de las revisiones de las actividades

de cada miembro del equipo de desarrollo del proyecto realizadas semanalmente, las cuales permiten conocer el avance y calidad de las actividades realizadas.

Roles: Equipo de desarrollo del proyecto Artefactos: Reporte semanal de revisiones personalizadas Pasos: Paso 1: Elaborar el reporte semanal de revisiones personalizadas Detalle de Pasos:

Paso 1: Elaborar el reporte semanal de revisiones personalizadas El responsable de realizar el seguimiento del proyecto debe elaborar el reporte semanal de revisiones personalizadas, considerando el avance estimado, el avance real y la calidad de las actividades realizadas por cada miembro del equipo de desarrollo del proyecto, el mismo que debe ser creado en el formato para ese fin.

4.1.5. Efectuar análisis de riesgos al finalizar cada iteración Permite realizar al final de cada iteración el análisis de los riesgos del proyecto, el cual determinará las actividades a realizar en la siguiente iteración del proyecto.

Efectuar análisis de riesgos al finalizar cada iteración Objetivo: Realizar el análisis de los riesgos del proyecto al finalizar cada

iteración. Justificación: Determina las actividades a realizar en cada iteración del proyecto. Roles: Equipo de desarrollo del proyecto Artefactos: Matriz de riesgos Pasos: Paso 1: Revisar los riesgos identificados en la etapa de Análisis de

Requerimientos Paso 2: Realizar el análisis de los riesgos identificados

Detalle de Pasos:

Paso 1: Revisar los riesgos identificados en la etapa de Análisis de Requerimiento El equipo de desarrollo del proyecto debe revisar los riesgos identificados en la fase de análisis de requerimientos como premisa para realizar el análisis de riesgos.

107

Paso 2: Realizar el análisis de los riesgos identificados Se registra la información requerida en la matriz de riesgos. Una vez concluido el análisis de riesgos se debe actualizar el plan del proyecto, con las acciones correctivas y preventivas identificadas durante el seguimiento y análisis de riesgos.

4.2 Descripción de los Roles Las actividades del proceso de seguimiento y control serán realizadas por cualquier integrante del equipo de desarrollo del proyecto.

Rol Abreviatura Competencias Desarrollador DES Conocimientos en la herramienta de desarrollo y la

arquitectura del software


LP Capacidad para liderar y motivar a los miembros del equipo del proyecto. Buenas relaciones y habilidades de comunicación. Persona proactiva y organizada.

4.3. Descripción de Productos Nombre Descripción Reporte de

seguimiento semanal

Documento que contiene el estado del proyecto, según la información revisada en la reunión de seguimiento. Contiene:

· Avance estimado del proyecto · Avance real del proyecto

· Problemas · Acciones futuras · Acciones pendientes

· Acciones correctivas Reporte semanal de

revisiones

personalizadas

Documento que contiene el porcentaje de avance y la calidad de las actividades realizadas por cada miembro del equipo del proyecto. Contiene:

· Avance estimado de actividades

· Avance real de actividades · Revisión de código de una funcionalidad · Acciones futuras

· Acciones pendientes · Acciones correctivas

Matriz de riesgos Documento que contiene el análisis de los riesgos del proyecto. Contiene:

· Impacto

· Probabilidad de ocurrencia

108

· Acción correctiva · Acción preventiva · Análisis cualitativo

4.4. Descripción de Artefactos Artefactos Definición

Cronograma del proyecto Documento que contiene la información de las actividades a llevarse a cabo en un periodo de tiempo

Acta de reunión semanal

de seguimiento de

actividades

Documento que contiene el seguimiento semanal de actividades el cual debe incluir los compromisos de cada miembro del equipo de desarrollo del proyecto.

5. Formatos En esta sección se presentan los formatos que se utilizan para el desarrollo de este proceso, los mismos que deben ser ajustados a la realidad de cada proyecto.

Reporte de seguimiento semanal Proyecto: Nombre del proyecto

Responsable: Nombre de la persona responsable del seguimiento

Semana: Número de la semana en la que se realiza el seguimiento

Fecha: Fecha en la que se realiza el seguimiento.

NOMBRE CARGO/ROL

Nombres de las personas que participaron en la

reunión de seguimiento

Rol dentro del proyecto o cargo en

la institución

1. Resumen

Detalle resumido del seguimiento de las actividades ejecutadas durante la semana. La información proviene de las actas de reunión de seguimiento, de las revisiones semanales personalizadas o del informe entregado por el miembro del equipo de desarrollo.

2. Logro

Detalle de las actividades concluidas en la semana que se realizó el seguimiento.

109

3. Objetivos de próxima semana

Detalle de las actividades que se realizarán para la próxima semana, las mismas que deben concordar con el cronograma del proyecto.

110

Reporte semanal de revisiones personalizadas


Responsable: Nombre de la persona responsable con la que se realiza el

seguimiento

Semana: Numero de semana que se realiza el seguimiento

Fecha: Fecha de seguimiento.

Nro. Actividad Inicio

Fin Problemas

Acciones

Nueva Fecha Fin

Númer

o de

activida

d

Detalle de

las

actividades

asignadas

al

responsabl

e.

Fecha de

inicio

estimada.

DD/MM/AA

AA

Fecha de fin

estimada.

DD/MM/AA

AA

Detalle de

los

problemas

presentad

os en el

desarrollo

de las

actividade

s

asignadas

Acciones

a realizar

para

soluciona

r los

problema

s y

concluir

las

actividad

es

Fecha de

fin

estimada,

consideran

do las

actividades

definidas

para

solución de

problemas

Matriz de riesgos MATRIZ DE RIESGOS


Líder del proyecto: Nombre del líder del proyecto

Fecha: Fecha de Creación de la matriz

Responsable Nombre del responsable de la matriz de riegos

Riesgo Probabilid

ad Impact

o Prioridad

Acciones Responsable Preventi

va Correcti

va Riesgo a

presentarse o

Probabilid

ad de que

Determi

ne el

Multiplica

r el

Describa

las

Describa

las

Nombre de la

persona

111

que se presentó

, considerando

los riesgos

identificados en

la fase de

diagnostico

ocurra el

riesgo.

Esperado,

Poco

Probable

nivel de

impacto

en caso

de que

ocurra

el

riesgo:

Alto,

Medio,

Bajo

impacto y

la

probabilid

ad

acciones

preventiv

as para

evitar

que el

riesgo

ocurra

acciones

correctiv

as a

seguir

en caso

de que

el riesgo

ocurra.

encargada de

realizar la acción

preventiva/corre

ctiva

ANEXO VII: PROCESO DE PLANIFICACIÓN DEL PROYECTO

PROCESO

DE PLANIFICACIÓN DEL PROYECTO

V1.0

112


Fecha

Creación


10/09/2018 Proceso de Planificación

del Proyecto

Ximena Mendoza 1.0

113

Contenido

1. Descripción Técnica ................................................................................................................ 113

Introducción ............................................................................................................................... 115

Objetivo ...................................................................................................................................... 115

Importancia ................................................................................................................................ 115

2. Definiciones ............................................................................................................................... 115

Conceptos Generales .............................................................................................................. 115

Conceptos Específicos ............................................................................................................ 115

3. Relación del proceso con el modelo CMMI ......................................................................... 116

4. Descripción del Proceso ......................................................................................................... 117

4.1 Caracterización del proceso ................................................................................................. 117

4.3. Descripción de Productos................................................................................................ 118

4.4. Descripción de Artefactos................................................................................................ 118

5. Formatos, Documentos y Herramientas ............................................................................... 118

Introducción ................................................................................................................................... 120

Propósito del Plan .................................................................................................................... 120

Antecedentes del proyecto...................................................................................................... 120

Enfoque del proyecto ............................................................................................................... 120

Metas y objetivos .......................................................................................................................... 120

Metas y objetivos del negocio ................................................................................................ 120

Metas y Objetivos del Proyecto .............................................................................................. 120

Alcance........................................................................................................................................... 120

Definición del alcance .............................................................................................................. 120

Costos, beneficios y riesgos ................................................................................................... 121

Productos del proyecto / Lista de entregables ......................................................................... 122

Hitos .................................................................................................................................................... 1

Áreas del negocio impactadas ....................................................................................................... 1

Suposiciones ..................................................................................................................................... 1

Supuestos del proyecto ............................................................................................................... 1

Restricciones ..................................................................................................................................... 1

Limitaciones del proyecto ............................................................................................................ 1

Proyectos relacionados ............................................................................................................... 1

114

Dependencias críticas ................................................................................................................. 1

Enfoque de gestión de calidad ....................................................................................................... 1

Revisiones de actividad ............................................................................................................... 1

Enfoque de prueba ........................................................................................................................... 2

Estándares de rendimiento / calidad ......................................................................................... 2

Formación ...................................................................................................................................... 2

Enfoque de gestión de proyectos .................................................................................................. 2

Estructura de desglose de trabajo (WBS) Diagrama de Gantt ................................................. 2

Base de estimaciones ...................................................................................................................... 3

Estimación del esfuerzo del proyecto ............................................................................................ 3

Estándares de proyectos ................................................................................................................. 3

Roles y responsabilidades del proyecto ....................................................................................... 3

Enfoque de gestión de cambio y emisión ..................................................................................... 4

Enfoque de comunicaciones y control .......................................................................................... 4

Aprobaciones .................................................................................................................................... 4

115


Introducción

El documento contiene un conjunto de artefactos desarrollados para facilitar la planificación de proyecto en una institución que cuenta con un área de desarrollo de software. Los elementos característicos son: descripción de procesos, actividades, tareas, roles, plantillas y herramientas.

Objetivo

Proporcionar una guía que permita llevar de forma adecuada la planificación del proyecto cumpliendo con los pasos necesarios y considerando los demás procesos con la finalidad de llegar a concluirse en los tiempos establecidos.

Importancia

La importancia del proceso de planificación del proyecto radica en establecer los lineamientos que permitan de forma simple la planificar el proyecto para desarrollar un producto de software o dar mantenimiento conociendo como está la documentación necesaria del proyecto, para con esto garantizar que se de mantenimiento sobre la misma línea base y la curva de aprendizaje incremente de forma más rápida.

2. Definiciones


Conceptos Generales



· Producto: entregable tangible o intangible que puede ser por una o varias tareas. · Artefacto: información que apoya al proceso durante la planificación de un

proyecto.


· Proyecto: conjunto de actividades para alcanzar un objetivo específico.


metas de un proceso. [ISO/IEC 12207]. · Paso: una tarea se descompone en una secuencia de pasos.

116


En esta sección se detalla las actividades relacionadas al proceso de planificación del proyecto de los proyectos de desarrollo y mantenimiento de software. El área de planificación del proyecto del modelo CMMI-DEV versión 1.3 (Capability Maturity Model Integration) tiene un grupo de prácticas que orientan y garantiza que este proceso sea llevado de forma correcta en los proyectos de desarrollo y mantenimiento de software.

En la figura 1 se presenta la ubicación del proceso de Planificación del Proyecto dentro de los procesos del ciclo de vida de desarrollo de software.

CmxGraphM odel%3E%3Croot%3E%3C mxCell %20id%3D %220%22%2F%3E%3C mxC ell%20i d%3D%221%22%20parent%3D %220%22%2F%3E%3C mxC ell%20i d%3D%222%22%20styl e%3D%22edgeStyle%3D orthog onalEdgeStyl e%3Br ounded%3D 0% 3Bhtml%3D 1%3BexitX%3D1%3BexitY%3D 0.5%3Bexi tD x%3D0%3BexitD y%3D 0%3Bentr yX%3D0%3BentryY%3D 0.5%3Bentr yD x%3D 0%3Bentr yD y%3D 0%3Bj ett ySize%3D auto%3Borthogonal Loop%3D1%3B%22%20edge%3D%221%22%20source%3D%223%22%20target%3D%225%22%20parent%3D%221%22%3E%3C mxGeometr y%2 0rel ati ve%3D%221%22%20as%3D %22geometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%223%22%20value%3D%22Di agn%26lt%3Bspan%20l ang %3D %26quot%3BES-DO%26quot%3B%26gt%3B%C3%B3stico%26lt%3B%2Fspan%26gt%3B%26lt%3Bbr%26gt%3B%22%20styl e%3D%22r ounded%3D 1%3BwhiteSpace%3D wr ap%3Bht ml%3D1%3B%22%20vertex%3D %221%22%20parent%3D%221%22%3E%3C mxGeometr y%20x%3D%2280%22%20y%3D %2280%22%20width%3D%2290%22%20heig ht%3D %2260%22%20as%3D %22geometr y%22%2F%3E%3C %2FmxC ell%3E%3C mxCell%20id%3D %224%22%20styl e%3D%22edgeStyl e%3D orthogonal Edg eStyle %3Brounded%3D0%3Bhtml%3D1%3Bexi tX%3D1%3BexitY%3D0.5%3BexitD x%3D 0%3BexitD y%3D0%3BentryX%3D 0%3Bentr yY%3D 0.5%3Bentr yD x%3D 0%3Bentr yD y%3D 0%3BjettySize%3D auto%3BorthogonalLoop%3D 1%3B%22%20edge%3D %221%22%20source%3D%225%22%20target%3D %227%22%20parent%3D%221%22%3E%3C mxGeometr y%20r elati ve%3D%221%22%20as%3D%22g eometr y%22%2F%3E%3C %2FmxCell%3E%3C mxC ell%20id%3D %225%22%20value%3D%22An%C 3%A1lisis%20%26l t%3Bbr%26gt%3Bde%20R equeri mientos%22%20styl e%3D%22r ounded%3D 1%3BwhiteSpace%3D wr ap%3Bhtml%3D 1%3B%22%20vertex%3D %221%22%20par ent%3D%221%22%3E%3C mxGeometr y%20x%3D%22200%22%20y%3D %2280%22%20width%3D %2290%22%20height%3D%2260%22%20as%3D%22g eometr y%22%2F%3E%3C%2FmxCell %3E%3C mxC ell%20id%3D%226%22%20style%3D %22edg eStyle%3D orthogonalEdgeStyl e%3Br ounded%3D0%3Bhtml%3D 1%3BexitX%3D1%3Bexi tY%3D 0.5%3BexitD x%3D 0%3Bexi tD y%3D0%3Bentr yX%3D 0%3Bentr yY%3D0.5%3Bentr yD x%3D0%3Bentr yD y%3D0%3BjettySize%3D auto%3Borthog onalLoop%3D 1%3B%22%20edge%3D %221%22%20source%3D %227%22%20target%3D %229%22%20par ent%3D%221%22%3E%3C mxGeometr y%20rel ati ve%3D%221%22%20as%3D % 22geometr y%22%2F%3E%3C %2FmxCell%3E%3C mxCell %20id%3D %227%22%20value%3D%22Dise%26lt%3Bspan%26gt%3B%C 3%B1o%26lt%3B%2Fspan%26gt%3B%22%20style%3D %22r ounded%3D1%3BwhiteSpace%3D wr ap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D %221%22%3E%3C mxGeometr y%20x%3D%223 20%22%20y%3D%2280%22%20width%3D %2280%22%20height%3D %2260%22%20as%3D %22geometr y%22%2F%3E%3C %2FmxCell%3E%3C mxCell%20id%3D %228%22%20styl e%3D %22edgeStyl e%3D orthogonalEdgeStyle%3Brounded%3D0%3Bhtml%3D1%3BexitX%3D 1%3Bexi tY%3D 0.5%3BexitD x%3D 0%3BexitD y%3D0%3BjettySize%3D auto%3Borthog onalLoop%3D 1%3B%22%20edge%3D%221%22%20source%3D %229%22%20par ent%3D%221%22%3E%3C mxGeometr y%20rel ati ve%3D%221%22%20as%3D %22geometr y%22%3E%3C mxPoi nt%20x%3D%22560%22%20y%3D%22110%22%20as%3D %22targetPoint%22%2F%3E%3C%2FmxGeometr y%3E%3C %2FmxCell%3E%3C mxCell %20id%3D %229%22%20value%3D%22Implementaci %26lt%3Bspan%20l ang%3D %26quot%3BES-DO%26quot%3B%26gt%3B%C3%B3%26lt%3B%2Fspan%26gt%3Bn%22%20styl e%3D%22rounded%3D 1%3BwhiteSpace%3D wrap%3Bhtml %3D 1%3B%22%20vertex%3D%221%22%20par ent%3D%221%22%3E%3C mxGeom etr y%20x%3D %22430%22%20y%3D %2280%22%20wi dth%3D%22100%22%20height%3D%2260%22%20as%3D%22g eometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%2210%22%20styl e%3D %22edgeStyl e%3D orthogonal Edg eStyle%3Brounded%3D0%3Bhtml%3D1%3Bexi tX%3D 1%3Bexi tY%3D 0.5%3Bexi tD x%3D0%3Be xitD y%3D 0%3Bentr yX%3D0%3Bentr yY%3D 0.5%3Bentr yD x%3D 0%3Bentr yD y%3D 0%3Bj ettySize%3Dauto%3Borthogonal Loop%3D1%3B%22%20edg e%3D%221 %22%20source%3D%2211%22%20target%3D %2212%22%20parent%3D %221%22%3E%3CmxGeometr y%20r elati ve%3D %221%22%20as%3D%22geometr y%22%2F%3E%3C% 2FmxC ell%3E%3C mxC ell%20i d%3D%2211%22%20value%3D%22Pr uebas%22%20style%3D%22r ounded%3D 1%3BwhiteSpace%3D wr ap%3Bhtml%3D1%3B%22%20vertex%3D %221%22%20parent%3D %221%22%3E%3C mxGeometr y%20x%3D%22562.5%22%20y%3D%2280%22%20wi dth%3D%2285%22%20height%3D%2260%22%20as%3D%22g eometr y%22%2F%3E%3C %2FmxCell %3E%3C mxC ell%20id%3D %2212%22%20value%3D%22Pues ta%20en%20Producci%26lt%3Bspan%20lang%3D %26quot %3BES-DO%26quot%3B%26gt%3B%C3%B3n%26lt%3B%2Fspan%26gt%3B%22%20styl e%3D%22rounded%3D 1%3BwhiteSpace%3D wrap%3Bhtml %3D 1%3B%22%20vertex% 3D%221%22%20par ent%3D%221%22%3E%3C mxGeometr y%20x%3D %22680%22%20y%3D %2280%22%20wi dth%3D%2280%22%20heig ht%3D%2260%22%20as%3D %22geometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%2213%22%20style%3D %22edg eStyle%3D orthog onalEdgeStyl e%3Br ounded%3D 0%3Bhtml%3D 1%3Be xitX%3D1%3BexitY%3D0.5%3Bexi tD x%3D0%3BexitD y%3D 0%3Bentr yX%3D0%3Bentr yY%3D 0.5%3Bentr yD x%3D 0%3Bentr yD y%3D 0%3Bj ettySize%3Dauto%3Borthogonal Loop%3D1%3B%22%20edg e%3D%221%22%20source%3D%2214%22%20target%3D %2216%22%20parent%3D %221%22%3E%3CmxGeometr y%20r elati ve%3D %221%22%20as%3D%22geometr y%22%2F%3E%3C%2F mxC ell%3E%3C mxC ell%20i d%3D%2214%22%20value%3D%22Adminis traci%26lt%3Bspan%20l ang%3D%26quot%3BES-EC%26q uot%3B%26gt%3B%C3%B3n%20de%20R equerimi entos%26lt%3B%2Fspan%26gt%3B%22%20styl e%3D%22rounded%3D 1%3BwhiteSpace%3D wrap%3Bht ml %3D 1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3C mxGeometr y%20x%3D %2280%22%20y%3D %22170%22%20wi dth%3D%2290%22%20height%3D%2260%22%20as%3D%22geometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%2215%22%20style%3D %22edg eStyl e%3D orthogonalEdgeStyl e%3Br ounded%3D0%3Bhtml%3D1%3BexitX%3D 1%3BexitY%3D 0.5%3BexitD x%3D 0%3Bexi tD y%3D0%3Bentr yX%3D 0%3Bentr yY%3D0.5%3Bentr yD x%3D0%3Bentr yD y%3D0%3BjettySize%3D auto%3BorthogonalLoop%3D 1%3B%22%20edge%3D %221%22%20source%3D%2216%22%20target%3D%2218%22%20parent%3D %221%22%3E%3C mxGeometr y%20r elati ve%3D %221%22%20as%3D%22geometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%2216%22%20val ue%3D%22Gesti%26l t%3Bspan%20lang%3D%26q uot%3BES- EC%26q uot%3B%26gt%3B%C 3%B3n%20%26lt%3Bbr%26gt%3Bde%20%26lt%3Bbr%26gt%3BConfigur aci%26l t%3B%2Fspan%26gt%3B%26l t%3Bspan%20lang% 3D%26q uot%3BES-EC%26q uot%3B%26gt%3B%C3%B3n%26lt%3B%2Fspan%26gt%3B%22%20styl e%3D%22rounded%3D 1%3BwhiteSpace%3D wrap%3Bhtml %3D 1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3C mxGeometr y%20x%3D %22200%22%20y%3D %22170%22%20width%3D %2290%22%20height%3D%2260%22%20as%3D%22g eometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%2217%22%20styl e%3D %22edgeStyl e%3D orthogo nal Edg eStyle%3Brounded%3D0%3Bhtml%3D1%3Bexi tX%3D 1%3Bexi tY%3D 0.5%3Bexi tD x%3D0%3BexitD y%3D 0%3Bentr yX%3D0%3Bentr yY%3D 0.5%3Bentr yD x%3D 0%3Bentr yD y%3D 0%3Bj ettySize%3Dauto%3Borthogonal Loop%3D1%3B%22%20edg e%3D%221%22%20source%3D%2218%22%20target%3D %2220%22%20parent%3D %221%22%3E%3CmxGeometr y%20r elati ve%3D %221%22%20as%3D%22geometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%2218%22%20value%3D%22Pl ani ficaci%26lt%3Bspan%20l ang%3D%26quot%3BES-EC%26q uot%3B%26gt%3B%C3%B3n%20%26lt%3Bbr %26gt%3Bdel%20%26lt%3Bbr%26gt%3BProyec to%26lt% 3B%2Fspan%26gt%3B%22%20styl e%3D%22r ounded%3D 1%3BwhiteSpace%3D wr ap%3Bhtml%3D1%3B%22%20vertex%3D %221%22%20par ent%3D%221%22%3E%3C mxGeometr y%20x%3D%22310%22%20y%3D%22170%22%20wi dth%3D%2280%22%20height%3D%2260%22%20as%3D%22g eometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%2219%22%20styl e%3D %22edgeStyl e%3D orthogonalEdgeStyle%3Brounded%3D 0%3Bhtml %3D 1%3BexitX%3D 1%3BexitY%3D 0.5%3BexitD x%3D 0%3Bexi tD y%3D0%3Bentr yX%3D 0%3Bentr yY%3D0.5%3Bentr yD x%3D0%3Bentr yD y%3D0%3BjettySize%3D auto%3BorthogonalLoop%3D 1%3B%22%20edge %3D %221%22%20source%3D %2220%22%20target%3D%2222%22%20par ent%3D%221%22%3E%3C mxGeometr y%20rel ati ve%3D%221%22%20as%3D %22geometr y%22%2F %3E%3C%2FmxC ell%3E%3C mxCell %20id%3D %2220%22%20val ue%3D%22M edici%26lt%3Bspan%20lang%3D %26quot%3BES-EC%26q uot%3B%26gt%3B%C3%B3n%20%26lt%3Bbr %26gt%3By%20%26lt%3Bbr %26gt%3BAn%26lt%3B%2Fspan%26gt%3B%26lt%3Bspan%26gt%3B%C3%A1lisis%26l t%3B%2Fspan%26gt%3B%22%20styl e%3D %22rounded%3D1%3Bwhi teSpace%3D wrap%3Bhtml %3D1%3B%22%20ver tex%3D %221%22%20par ent%3D%221%22%3E%3C mxGeometr y%20x%3D%22430%22%20y%3D %22170%22%20wi dth%3D%22100%22%20height%3D %2260%22%20as%3D%22geometr y%22%2F%3E%3C %2FmxCell%3E%3C mxCell %20id%3D %2221%22%20styl e%3D%22edgeStyl e%3Dorthogonal EdgeStyl e%3Brounded%3D 0%3Bhtml %3D 1%3Bexi tX%3D 1%3BexitY%3D 0.5%3BexitD x%3D 0%3Bexi tD y%3D0%3Bentr yX %3D 0%3Bentr yY%3D0.5%3Bentr yD x%3D0%3Bentr yD y%3D0%3BjettySize%3D auto%3Borthogonal Loop%3D1%3B%22%20edg e%3D%221%22%20source%3D%2222%22%20target%3D %2223%22%20parent%3D %221%22%3E%3C mxGeometr y%20r elati ve%3D %221%22%20as%3D %22geometr y%22%2F%3E%3C%2FmxC ell%3E%3C mxC ell%20i d%3D%2222%22%20val ue%3D %22Aseg uramiento%26lt%3Bbr%26gt%3Bde%20l a%26lt%3Bbr%26gt%3BCali dad%26lt%3Bbr%26gt%3B%22%20styl e%3D%22r ounded%3D 1%3BwhiteSpace%3D wrap%3Bhtml %3D 1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3C mxGeometr y%20x%3D %22560%22%20y%3D% 22170%22%20wi dth%3D%2290%22%20height%3D%2260%22%20as%3D %22geometr y%22%2F%3E%3C %2FmxC ell%3E%3C mxC ell%20i d%3D%2223%22%20value%3D%22Segui miento%20%26l t%3Bbr%26gt%3By%20%26lt%3Bbr%26gt%3BContr ol%22%20styl e%3D %22rounded%3D 1%3Bwhi teSpace%3D wrap%3Bhtml %3D 1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3C mxGeometr y%20x%3D%22680%22%20y%3D%22170%22%20width%3D %2280%22%20height%3D %2260%22%20as%3 D%22geometr y%22%2F%3E%3C %2FmxCell%3E%3C mxC ell%20i d%3D%2224%22%20value%3D%22%22%20s tyle%3D %22endArr ow%3Dclassic%3Bhtml%3D 1%3B%22%20edge%3D %221%22%20par ent%3D%221%22%3E%3C mxGeometr y%20width%3D %2250%22%20height%3D %2250%22%20relati ve%3D%221%22%20as%3D %22geometr y%22%3E%3C mxPoint%20x%3D %22300%22%20y%3D %22200%22%20as%3D %22sourcePoi nt%22%2F%3E%3C mxPoint%20x%3D %22300%22%20y%3D%22110%22%2 0as%3D %22targetPoint%22%2F%3E%3C%2FmxGeometr y%3E%3C %2FmxC ell%3E%3C mxC ell%20i d%3D%2225%22%20val ue%3D %22%22%20style%3D%22endArrow%3Dcl assic%3Bhtml %3D 1%3B%22%20edge%3D%221%22%20par ent%3D%221%22%3E%3C mxGeometr y%20width%3D %2250%22%20height%3D%2250%22%20rel ati ve%3D%221%22%20as%3D %22geometr y%22%3E%3C mxPoi nt%20x%3D%22410%22%20y%3D %22200%22%20as%3D%22sourcePoint%22%2F%3E%3C mxPoi nt%20x%3D%22410%22%20y%3D%22110%22%20as%3D%22targetPoi nt%22%2F%3E%3C %2FmxGeometr y%3E%3C%2FmxC ell%3E%3C %2Fr oot%3E%3C %2FmxGraphModel%3E


En la figura 2 se presenta la ubicación del proceso de Planificación del Proyecto dentro

del ciclo de vida de mantenimiento de software.


117



subprocesos del proceso de Planificación del Proyecto incluyendo los productos de

trabajo generados durante los subprocesos.

4.1 Caracterización del proceso 4.1.1 Análisis de los Requerimientos

El análisis de requerimientos permite analizar las necesidades de las áreas requirentes y es el paso

inicial para la planificación del proyecto.

De acuerdo a la necesidad institucional se definen los requerimientos y se establecen las

prioridades una vez que el requerimiento se encuentra bien definido de levanta el documento de

requerimientos, con el cual el líder de aplicaciones hace el respectivo análisis.

4.1.2 Establecer los objetivos

Se debe definir los objetivos del proyecto y del negocio

4.1.3 Definir los recursos

Se debe definir los recursos sean materiales o humanos.

4.1.4 Definir los costos

Se debe establecer los costos del proyecto, el mismo que dependerá de los recursos con los cuales

cuente para el proyecto y el tiempo de implementación del mismo.

4.1.5 Definir el cronograma

Se debe definir las actividades a realizarse durante el proyecto, así como en los costos depende del

personal y del tiempo que conlleve cada una de las actividades.

118


Nombre Descripción

Plan del Proyecto Documento del plan del proyecto que contiene los objetivos, recursos y actividades.



Documento de

Requerimientos

Formulario con el cual empieza la ejecución del proyecto.


En esta sección se presenta los formularios y documentos necesarios para el proceso de planificación del proyecto.

119

Plan del Proyecto

<<Nombre del Proyecto>

V1.0

120

Introducción Propósito del Plan Contiene el propósito del plan del proyecto.

Antecedentes del proyecto Contiene el historial del Proyecto, el mismo que debe incluir la justificación.

Enfoque del proyecto Contiene la metodología de desarrollo aplicarse para llevar a cabo el proyecto de forma exitosa.

Metas y objetivos

Metas y objetivos del negocio

Se debe detallar que es lo que se espera alcanzar en cuanto al negocio con el desarrollo del proyecto.

Entre los objetivos del negocio pueden estar

· Reducción de costos · Reducción de tiempos, etc.

Metas y Objetivos del Proyecto

Se debe detallar que es lo que se espera alcanzar como resultado de la implementación del proyecto. Debe detallar la finalidad o lo que se espera que logre la institución.

Alcance

El alcance debe describir desde una perspectiva cuantitativa lo que se debe obtener. Su objetivo principal es ayudar a establecer planes de trabajo, presupuestos, cronogramas y expectativas realistas. En caso de aparezca algún trabajo fuera del alcance definido, el Líder de Aplicaciones debe considerarlo como fuera del alcance y rezagar, o ampliar el alcance del proyecto para incluir el trabajo. En este caso conlleva cambios formales en el plan de trabajo, asignación de recursos, presupuesto y / o el cronograma.

Definición del alcance

Se debe definir de forma detallada el trabajo que se realizará y qué partes de la institución se incluirán o no en el proyecto. Si el desarrollo del proyecto se considera en etapas, puede contener entregables de las etapas anteriores.

La definición del alcance debe establecer:

121

• Diseño de la arquitectura

•Áreas involucradas parte del desarrollo del proyecto

• Los tipos de manejo de información y sus tecnologías asociadas

Costos, beneficios y riesgos

Se debe identificar los costos y beneficios asociados con el proyecto, el mismo que debe incluir una referencia al Informe de presupuesto del proyecto y / o al Informe de análisis de costo beneficio, dicho documento debe ir dentro de los anexos del plan del proyecto.

En los costos se debe incluir costos administrativos, reuniones y el tiempo de la tarea de administración del proyecto.

En el caso de proyectos a desarrollarse por proveedores externos, se verifica las adquisiciones de servicio y se calcula en base a esos costos un valor estimado, para proyectos a desarrollarse de forma interna no existe un costo monetario sino en tiempo.

Se debe identificar los riesgos que pueden presentarse en el desarrollo del proyecto, para identificar el riesgo se utilizara la tabla 1.

Riesgo Costo Probabilidad Estrategia de Mitigación

Tabla 7 Detalle de Riesgos

El riesgo va a depender del tipo de proyecto, si el proyecto se desarrolla de forma interna o externa.

Si el proyecto se desarrolla a nivel interna no tiene un costo monetario pero si en cuanto a tiempos.

122

P

rod

uct

os

del

pro

yect

o /

Lis

ta d

e en

treg

able

s E

n e

sta h

oja s

e deb

e d

etalla

r lo

s ent

reg

abl

es

del

pro

yect

o,

la f

ase

del

cic

lo d

e vi

da

del

pro

yect

o e

n el

que

deb

e e

ntre

gar

se,

el

cale

ndar

io d

e ent

reg

as

y el

est

ado.

Se d

ebe

def

inir

a l

a p

erso

na p

ara c

rear

el

ent

reg

abl

e o

ase

gur

ars

e d

e q

ue

se

com

ple

te.

Eta

pa

E

ntr

egab

le

Des

crip

ció

n

Cri

teri

o d

e A

cep

taci

ón

A

sig

nad

o a

E

n

Pro

ceso

(F

ech

a)

Rev

isió

n

de

Cal

idad

(F

ech

a)

En

treg

able

(F

ech

a)

Ac

epta

do

(F

ech

a)

Inic

io

Pla

nea

ció

n

An

ális

is d

e R

equ

erim

ien

to

Dis

eño

Imp

lem

enta

ció

n

Pu

esta

en

P

rod

ucc

ión

Cie

rre

Tab

la 8

Lis

ta d

e E

ntr

egab

les

del

Pro

yect

o

1

Hitos

Un hito es un alcance temporal del proyecto, aquí se debe detallar los logros más significativos del proyecto, esto permite tener un control para identificar el avance del proyecto. Un hito se produce cuando una o varias actividades generan un producto o resultado visible.

Áreas del negocio impactadas

Se debe identificar qué áreas se verán afectadas durante el desarrollo del proyecto o finalización del mismo. Por ejemplo puede ser que dentro del desarrollo del proyecto existan áreas que hasta que se encuentre implementado el proyecto tendrá que realizar ese proceso de forma manual. Si un área de negocio no puede funcionar durante el desarrollo del proyecto, el tiempo del proyecto debe ser de alta prioridad.

Suposiciones

Supuestos del proyecto

Describa brevemente cualquier suposición sobre el proyecto relacionada con los recursos, el alcance, las expectativas, los horarios, etc.

Restricciones

Limitaciones del proyecto Describa las limitaciones principales bajo las cuales se debe conducir el proyecto, en relación con el entorno o los parámetros del proyecto (plazo, financiación, niveles de habilidades, disponibilidad de recursos, etc.). Proyectos relacionados Enumere cualquier otro proyecto que se vea afectado por el proyecto descrito en el Plan. El líder de aplicaciones debe mantenerse en el ciclo de comunicación en todos los asuntos relacionados con este proyecto. Dependencias críticas Es importante que se detallen las dependencias críticas que pueden presentarse en el desarrollo del proyecto, de tal forma que no puedan causar inconvenientes en el desarrollo del mismo. Esto se puede detallar mediante PERT.

Enfoque de gestión de calidad

Revisiones de actividad Se debe definir las revisiones que se realizaran en el desarrollo del proyecto. Incluir elementos como planes de prueba, scripts, etc. Se debe especificar cuándo se realizaran

2

las revisiones en relación con otras tareas. Herramientas y Técnicas Se debe definir qué herramientas y técnicas se utilizarán en el proyecto para garantizar la calidad. Las herramientas pueden incluir paquetes de software específicos para la programación de proyectos, pruebas, etc.

Enfoque de prueba Se debe detallar de forma breve el enfoque que se utilizará para probar los resultados del proyecto antes de ponerlos en producción. Todos los productos desarrollados como resultado del proyecto deben ser probados. Estándares de rendimiento / calidad Se debe identificar los estándares de calidad que debe cumplir después de la aprobación de los resultados finales del proyecto. Esto puede incluir criterios de aceptación para el producto de trabajo final. Roles de gestión de calidad Se debe detallar los roles específicos de la gestión de la calidad y las responsabilidades que tiene cada uno de los roles para garantizar la calidad en el proyecto. Dichas responsabilidades deben incluir la revisión de los productos de trabajo producidos Formación Se debe detallar la forma como se llevará a cabo la capacitación y evaluación de la capacitación.

Enfoque de gestión de proyectos

Estructura de desglose de trabajo (WBS) Diagrama de Gantt Se debe definir las etapas y tareas principales de alto nivel como por ejemplo en la figura 1.

Fig. 20 WBS

3

Base de estimaciones Se debe indicar como se generaron las estimaciones métricas en el WBS. Detalle si algún criterio especial, como la capacitación en el proyecto, afecta las métricas. Estimación del esfuerzo del proyecto Se debe detallar mediante un enfoque general para estimar los recursos, esto debe incluir las siguientes categorías: • Miembros del equipo del proyecto / Soporte administrativo: generalmente describen los tipos de recursos que se utilizarán, la cantidad de trabajo requerido de cada recurso para cada actividad y la lógica de cómo se asigna su tiempo. • Proyectos, instalaciones y equipos: describa cómo se pondrán a disposición estos recursos (existentes, de alquiler, de compra) y, en general, describa el calendario de los desembolsos. • Gestión del usuario final: describa en qué medida estos recursos estarán relacionados con los grupos de referencia, revisiones de proyectos, etc. Los requisitos de recursos, incluida una contabilidad del uso de los recursos a lo largo del tiempo, deben incluirse en el plan de trabajo.

Estándares de proyectos

Se debe definir las normas para el desarrollo del proyecto, las cuales se acuerdan con el equipo de desarrollo. Dichos estándares incluyen normas de comportamiento del equipo, informes de estado, reuniones de personal, criterios de aceptación de revisión de productos, etc. Detalle los estándares existentes y que se acoplan al proyecto. Roles y responsabilidades del proyecto Se debe identificar los recursos necesarios para el proyecto, disponibilidad de los recursos, el personal necesario. La selección de personas para el equipo de proyecto depende de: • Requisitos de roles • Disponibilidad del recurso • Metodología y conocimiento del proceso • Conocimiento de tecnología • Conocimiento de sistemas actuales • Conocimiento del negocio, procesos de negocio y procedimientos • Conocimiento de los estados anteriores del proyecto • Experiencia en el tema

Roles Responsabilidades

Miembros del Equipo del Proyecto

Tabla. 21 Definición de Roles y Responsabilidades

4

Enfoque de gestión de cambio y emisión Incluya una descripción del enfoque de gestión de problemas que se utilizará en el proyecto. Los problemas deben monitorearse para todos los elementos que surgen durante el proyecto pero que están fuera del plan del proyecto.

Defina el enfoque que se utilizará para gestionar cualquier cambio en el alcance del proyecto, el cronograma, el presupuesto o los recursos que debe aprobar el Patrocinador Ejecutivo antes de incorporarse al Plan del Proyecto. Incluya una copia de un Informe de Impacto del Proyecto en el Apéndice del Plan del Proyecto.

Enfoque de comunicaciones y control

Describa los roles y las responsabilidades de cada miembro del equipo junto con el plan de comunicación para garantizar que los miembros del equipo comprendan lo que se espera de ellos. Describa el mecanismo para comunicar las responsabilidades en todo el equipo del proyecto y dentro de la organización en general (en la medida en que sea necesario).

Aprobaciones

Hoja de aprobación

He leído el Plan del proyecto anterior y cumpliré sus términos y condiciones, y prometo mi pleno compromiso y apoyo para el proyecto.

Coordinador: Fecha: Director de SIT: Fecha: Líder de Aplicaciones: Fecha:

5

ANEXO VIII: PROCESO DE GESTIÓN DE REQUERIMIENTOS

PROCESO

DE GESTIÓN

DE REQUERIMIENTOS

V1.0

6



08/09/2018 Proceso de Gestión

Requerimientos

Ximena Mendoza 1.0

7

Contenido

1. Descripción Técnica ......................................................................................................................... 8

Introducción .................................................................................................................................... 8

Objetivo ........................................................................................................................................... 8

Importancia ..................................................................................................................................... 8

2. Definiciones ..................................................................................................................................... 8

Conceptos Generales ...................................................................................................................... 8

Conceptos Específicos ..................................................................................................................... 8

3. Relación del proceso con el modelo CMMI ..................................................................................... 9

4. Descripción del Proceso ................................................................................................................ 10

4.1. Actividades ............................................................................................................................. 11

4.1.1. Confirmar línea base de requerimientos ....................................................................... 11

4.1.2. Registrar cambios de requerimientos en la línea base ................................................... 12

4.1.3. Revisar y aprobar análisis de impacto e implementación del cambio ............................ 13

4.1.4. Revisar análisis de impacto de cambios y aprobar la implementación .......................... 13

4.1.5. Realizar plan de implementación de cambios ................................................................ 14

4.1.6. Controlar trazabilidad de los requerimientos ................................................................ 15

4.2 Descripción de los Roles .......................................................................................................... 15

4.3. Descripción de Productos ....................................................................................................... 16

4.4. Descripción de Artefactos ...................................................................................................... 16

5. Formatos ....................................................................................................................................... 16

Solicitud de Modificación .............................................................................................................. 16

· Listado de línea base de requerimientos ............................................................................. 19

· Acta de reunión ..................................................................................................................... 19

· Cronograma del proyecto ..................................................................................................... 19

8


Introducción

El documento contiene un conjunto de artefactos desarrollados para facilitar la implementación

del proceso de gestión de requisitos en una institución que cuenta con un área de desarrollo de

software. Los elementos característicos son: descripción de procesos, actividades, tareas, roles

plantillas y herramientas.

Objetivo

El propósito de este documento es proporcionar los lineamientos para administrar correctamente

los requerimientos durante el ciclo de vida del desarrollo y mantenimiento de software, cuando se

realizan proyectos ejecutados en periodos cortos de tiempo.

Importancia

La importancia del proceso de gestión o administración de requisitos radica en tener claro los

lineamientos y guías para administrar o gestionar los requerimientos de un sistema de forma

sencilla y consistente, para garantizar el mantenimiento de la trazabilidad y control de los cambios

de los mismos durante la ejecución del ciclo de vida de desarrollo y mantenimiento del software.

2. Definiciones

Esta sección contiene la definición de conceptos generales y específicos que se utilizan en el

proceso.

Conceptos Generales







· Artefacto: información que apoya al proceso durante la ejecución de un proyecto. Conceptos Específicos

Requerimiento: En el glosario de la IEEE (1) Una condición o necesidad de un usuario para resolver

un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un

sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro

documento formal. (3) Una representación documentada de una condición o capacidad como en

(1) o (2).

9

Línea Base: Son los requerimientos ya establecidos e implementados, la misma que puede ser

cambiada mediante un proceso adecuado de control de cambios.

Cambio: cualquier modificación o solicitud de cambio por el equipo de desarrollo que afecte

aspectos del software como: requerimientos funcionales, no funcionales, costo y tiempo.

Trazabilidad de Requerimientos: una visión de lo que ha ocurrido con los requerimientos

definidos.


En esta sección se detalla las actividades relacionadas al proceso de gestión de requisitos para

proyectos de desarrollo y mantenimiento de software.

El área de procesos dentro de CMMI (Capability Maturity Model Integration) versión 1.3 que se

encarga de la base para la definición del proceso de gestión de requerimientos es el área de

procesos Requirements Management (REQM), que recoge un grupo de prácticas, las cuales

permiten la orientación para garantizar la correcta administración de los requerimientos durante

la ejecución de un proyecto de desarrollo y mantenimiento de software.

Este proceso aplica para proyectos de desarrollo y mantenimiento de software a la medida, de

complejidad media y de duración corta.

El proceso de gestión de requerimientos se apoya mediante formatos, documentos y actas que

permiten el registro de las actividades del proceso.

En la figura 1 se presenta la ubicación del proceso de Gestión de requerimientos dentro de los

procesos del ciclo de vida de desarrollo de software.


En la figura 2 se presenta la ubicación del proceso de Gestion de Requisitos dentro del ciclo de vida

de mantenimiento de software.

Gestión de

Requerimientos

Gestión de

Configuración

Medición y

Análisis

Aseguramiento

de Calidad

Seguimiento

y Control

10




subprocesos del proceso de gestión de requerimientos incluyendo los productos de trabajo


En la figura 3 se muestra el proceso de Gestión de Requerimientos con las respectivas actividades

a realizarse:

Diseño

Implementacion

Prueba del

Sistema


Liberacion


Analisis

GESTION DE

REQUERIMIENTOS

11

Figura 3 — Proceso de Gestión de Requerimientos

4.1. Actividades

El proceso de Gestión de Requerimientos (REQM) tiene las siguientes actividades que se detallan a

continuación:

4.1.1. Confirmar línea base de requerimientos

Permite que se garantice el conocimiento y aprobación de los requerimientos tanto por el cliente

como por el equipo de desarrollo del proyecto, permitiendo la responsabilidad en el desarrollo

del mismo.

Confirmar línea base de requerimientos

Objetivo: Validar el cliente y el equipo de desarrollo los requerimientos que establecen la

línea base de requerimientos, la misma que establece el compromiso de

desarrollo del proyecto.

Justificación: Permite tener el compromiso para la implementación del proyecto, con lo cual en

caso de presentarse modificaciones, las mismas sean evaluadas con proceso de

control de cambios.


Artefactos: · Listado de línea base de requerimientos

· Acta de reunión

Pasos: Paso 1: Establecer la reunión para definir el requerimiento.

12

Paso 2: Llenar del documento de solicitud de requerimiento

Paso 3: Validar el documento con el equipo de desarrollo

Paso 4: Aprobar el documento de solicitud de modificación

Detalle de

Pasos:

Paso 1: Establecer la reunión para definir el requerimiento.

Un miembro del equipo de desarrollo en conjunto con el área requiriente

(cliente) se reúne para conocer la necesidad de su requerimiento.

Paso2: Llenar el documento solicitud de requerimiento

El área requiriente llena documento de solicitud de requerimiento, para una

revisión posterior con el equipo de desarrollo

Paso 2: Realizar reunión de validación de línea base de requerimientos

Durante este paso se realiza la reunión de validación de la línea base de

requerimientos con el cliente, los resultados de la reunión deben quedar

consignados en un acta la cual debe ser revisada y firmada por los participantes

de la validación.

Paso 3: Validar el documento con el equipo de desarrollo

Una vez que el área requiriente envía el documento se verifica que se encuentre

bien definido el requerimiento y que toda la información ahí proporcionada este

consiste, sino existe mayores observaciones que el documento listo.

Paso 4: Aprobar el documento de solicitud de modificación

Una vez que el requerimiento ha sido revisado por el área requiriente y el equipo

de desarrollo, el documento es firmado.

En caso de existir un cambio que afecte a lo ya establecido se debe utilizar una

solicitud de modificación.

4.1.2. Registrar cambios de requerimientos en la línea base

Permite revisar y controlar los cambios que se presenten en los requerimientos durante la

ejecución del proyecto, aplicando el proceso de control de cambios definido.

Registrar cambios de requerimientos de línea base

Objetivo: Registrar y controlar los cambios que se presentan en los requerimientos

definidos durante la ejecución del proyecto.

Justificación: Permite un adecuado control en los cambios de los requerimientos

permitiendo que se implementes de forma correcta


Artefactos: Documento de Solicitud de Requerimientos

Documento de Solicitud de Modificación

Pasos: Paso 1: Descubrir y comprender los cambios en los requerimientos

Paso 2: Documentar los cambios de los requerimientos

13

Detalle de Pasos: Paso 1: Descubrir y comprender los cambios en los requerimientos

El equipo de desarrollo debe estar pendiente para descubrir cualquier

cambio en los requerimientos, sea solicitado por el cliente o descubierto

por el equipo. Se debe tener claro cuando una solicitud es un cambio en

los requerimientos.

Paso 2: Documentar los cambios de los requerimientos

Una vez descubiertos y comprendidos los cambios en los requerimientos,

estos deben ser documentados en la solicitud de modificación

documentación del cambio.

4.1.3. Revisar y aprobar análisis de impacto e implementación del cambio

Ayuda a conocer lo que representa el impacto en la implementación. El impacto puede variar

dependiendo del estado del proyecto.

Revisar y aprobar análisis de impacto e implementación del cambio

Objetivo: Determinar el impacto de la implementación del cambio solicitado.

Justificación: Permite conocer mediante un análisis bien detallado sobre el impacto que

representa la implementación del cambio.


Artefactos: Solicitud de cambios

Pasos: Paso 1: Analizar la solicitud de modificación

Paso 2: Realizar la documentación sobre el análisis de impacto del cambio

Detalle de Pasos: Paso 1: Analizar la solicitud de modificación

El equipo de desarrollo debe analizar la documentación de las solicitudes de

modificación y entender para preparar el análisis de impacto.

Paso 2: Realizar la documentación sobre el análisis de impacto del cambio

Cuando ya se entendió el cambio se debe establecer lo que representa la

implementación en cuanto a costo y tiempo.

4.1.4. Revisar análisis de impacto de cambios y aprobar la implementación

Ayuda tanto al cliente como al equipo de desarrollo si los cambios solicitados serán

implementados.

Se debe considerar que cualquier cambio impacta una de las tres restricciones del proyecto:

alcance, tiempo o costo. No se puede incluir un cambio dentro del proyecto sin que afecte al

menos una de estas variables.

14

Revisar análisis de impacto de cambios y aprobar la implementación

Objetivo: Establecer si los cambios solicitados se implementan considerando el

impacto de su implementación sobre el proyecto.

Justificación: Permite llevar un adecuado control sobre el alcance del proyecto en

cuanto tiempo y costo de implementación.

Roles: Miembros del equipo del proyecto

Artefactos: Solicitud de Modificación

Pasos: Paso 1: Revisar la solicitud de modificación.

Paso 2: Definir la implementación de los cambios de los requerimientos

Detalle de Pasos: Paso 1: Revisar la solicitud de cambios

El equipo de desarrollo del proyecto debe revisar la solicitud de

modificación y revisar el análisis de impacto de los cambios los mismos

que son registrados en la solicitud de modificación.

Paso 2: Definir la implementación de los cambios de los requerimientos

Se establece la implementación de los cambios de los requerimientos,

considerando el impacto para el proyecto esta decisión.

4.1.5. Realizar plan de implementación de cambios

Permite establecer las actividades a realizarse para la implementación del cambio solicitado. Se

debe considerar las actividades que afectan a todo el proyecto.

Realizar plan de implementación de cambios

Objetivo: Establecer las actividades a realizarse para la implementación de los

cambios.

Justificación: Permite que se establezca todas las actividades necesarias para la

implementación del cambio, considerando todas las fases del proyecto.


Artefactos: Cronograma del proyecto

Pasos: Paso 1: Revisar los cambios de los requerimientos aprobados para

implementación

Paso 2: Elaborar plan de implementación de cambios

Detalle de Pasos: Paso 1: Revisar los cambios de los requerimientos aprobados para

implementación

El equipo de desarrollo debe identificar las actividades a realizarse para

la implementación de los cambios aprobados.

Paso 2: Elaborar plan de implementación de cambios

Se debe elaborar el plan de implementación de los cambios,

15

considerando las actividades identificadas en el cronograma del

proyecto, responsable y tiempo para realizar cada actividad.

4.1.6. Controlar trazabilidad de los requerimientos

Ayuda en mantener la consistencia entre todos los productos de trabajo que muestran los

requerimientos del proyecto. Todo cambio en un requerimiento debe mostrarse en todos los

productos de trabajo asociados.

Controlar trazabilidad de los requerimientos

Objetivo: Controlar la trazabilidad de los requerimientos del software.

Justificación: Permite mantener la consistencia entre todos los productos de trabajo

que muestran los requerimientos del proyecto.


Artefactos:

Pasos: Paso 1: Revisar el plan de implementación de cambios definido

previamente

Paso 2: Ejecutar los cambios en los productos de trabajo asociados con el

cambio en el requerimiento

Descripción de

Pasos:

Paso 1: Revisar el plan de implementación de cambios definido

previamente

El equipo de desarrollo debe revisar el plan de implementación de

cambios para organizar el desarrollo de las actividades definidas.

Paso 2: Ejecutar los cambios en los productos de trabajo asociados con

el requerimiento impactado por el cambio

Se ejecutan las actividades definidas en el plan de implementación de

cambios.


Las actividades del proceso de gestión de requerimientos pueden realizadas por cualquier

miembro del equipo de desarrollo del proyecto.


Cliente (Área

requiriente)

CLI Conocimiento del negocio.

Autoridad para aprobar los requerimientos y sus cambios.

Conocimiento y experiencia en al dominio de aplicación.

Analista de

requerimientos

AREQ Capacidad de abstracción y análisis de información.

Buena comunicación oral y escrita.

16


Nombre Descripción

Cronograma del

proyecto

Este documento contiene las actividades del proyecto y las que se deben

agregar producto de la solicitud de modificación.



Solicitud de Modificación Este documento contiene el detalle de los cambios solicitados en

el transcurso de ejecución del proyecto.

Los campos del documento son:

· Solicitud

· Análisis de Impacto

· Decisión de implementación

Listado de línea base de

requerimientos

Este documento contiene en detalle los requerimientos que

constituyen la línea base de los requerimientos.

5. Formatos

En esta sección se detallan los documentos necesarios para este proceso, los mismos que se

adaptan a la realidad de cada proyecto.

Solicitud de Modificación


Id. Cambio: Número de solitud de cambio

Modulo: Nombre del módulo con el cual se asocia el requerimiento (opcional)

Requerimiento: Id del requerimiento al cual se le va a aplicar el cambio

Versión del

requerimiento: Versión del requerimiento

Solicitado por: Nombre de la persona que hizo la solicitud

Tipo solicitud: Tipo de solicitud (Nueva, Error, etc.)

Fecha solicitud

(DD/MM/AAAA): Fecha de la solicitud del cambio.

Tipo de cambio: Especificar si el cambio es interno o externo. Funcional, no funcional,

cambio de términos.

Fase: Indicar en qué fase se encuentra el proyecto (Análisis, Diseño,

Implementación, Pruebas)

Detalle del cambio: Detalle del cambio

Elementos que afecta: Detalle los elementos que se afectan por el cambio.

17

Documentos anexos: Especifique los documentos adicionales relacionados con el cambio.

ANALISIS DE IMPACTO

Considerando la lista de verificación establezca las actividades a realizarse según el cambio

propuesto:

LISTA DE VERIFICACION - ANALISIS DE IMPACTO DE CAMBIOS

Alcances del Cambio Propuesto Si o No

(Especifique Cuales)

Identificar en la línea base de requerimientos los que tengan

problema con el cambio propuesto.

Ejemplo: Req_001,

Req_005

Identificar requerimientos pendientes que tengan problemas con el

cambio propuesto

¿Qué consecuencias conlleva no implementar el cambio?

¿Afecta negativamente la implementación del cambio al rendimiento

o calidad?

¿Es factible el cambio propuesto dentro de las restricciones técnicas

conocidas y las habilidades actuales del personal?

¿Es necesaria la adquisición de herramientas para implementar y

probar los cambios?

¿Los cambios propuestos afectarán en el cronograma a alguna tarea

existente en el plan del proyecto?

¿Es necesario los prototipos o información del usuario para verificar

el cambio propuesto?

¿Cuánto esfuerzo invertido en el proyecto se perderá si el cambio es

aceptado?

¿El cambio implementado afectará los planes de capacitación o

soporte a los usuarios?

Elementos de Software Afectados por el Cambio Propuesto Si o No

(Especifique cuáles)

Identificar cualquier cambio, adición o eliminación requerido en

interfaces de usuario

Identificar cualquier cambio, adición o eliminación requerido en

reportes, bases de datos o archivo de datos

Identificar los componentes de diseño que deben ser creados,

modificados o eliminados

Identificar los componentes de hardware que deben ser adicionados,

18

alterados o eliminados

Identificar los archivos de código fuente que deben ser creados,

modificados o eliminados

Identificar cualquier cambio requerido en los archivos construidos

Identificar casos de prueba de unidad, integración o funcionales

existentes que deben ser modificados o eliminados

Estimar el número de casos de prueba de unidad, integración, o

funcionales nuevos que serán requeridos

Identificar cualquier ayuda de pantalla, manual de usuario, material

de entrenamiento u otra documentación que debe ser creada o

modificada

Identificar cualquier otro sistema, aplicación, librería, o componente

de hardware afectado por el cambio

Identificar cualquier componente de software de terceros que deba

ser adquirido

Identificar cualquier impacto del cambio propuesto sobre el acta de

constitución del proyecto, el plan de aseguramiento de calidad, el

plan de administración de la configuración o cualquier otro plan

Cuantificar el efecto del cambio propuesto sobre el tiempo real del

cronograma, el presupuesto y los recursos del proyecto.

Estimación del esfuerzo para un cambio de requerimiento Esfuerzo Estimado

(Horas)

Actualizar la base de datos de requerimientos con el nuevo requerimiento

Crear los nuevos componentes del diseño

Modificar los componentes existentes del diseño

Desarrollar nuevos componentes de interfaz de usuario

Modificar los componentes de interfaz de usuario existentes

Desarrollar nuevas ayudas de pantalla

Modificar ayudas de pantalla existentes

Desarrollar nuevo código Fuente

Modificar código fuente existente

Adquirir e integrar software de terceros

Modificar archivos construidos

Desarrollar nuevas pruebas de unidad y de integración

Modificar las pruebas de unidad y de integración existentes

19

Realizar pruebas de unidad y de integración después de la implementación

Elaborar nuevos casos de pruebas funcionales

Modificar los casos de pruebas funcionales existentes

Desarrollar nuevos reportes

Modificar los reportes existentes

Desarrollar nuevos elementos de bases de datos y archivo de datos

Modificar los elementos de bases de datos y archivo de datos existentes

Modificar los planes del proyecto

Actualizar otra documentación

Revisar los productos de trabajo modificados

Realizar reproceso después de ejecutar las revisiones y pruebas

Otras tareas adicionales necesarias para realizar el cambio propuesto

TOTAL ESFUERZO ESTIMADO 0

· Listado de línea base de requerimientos

· Acta de reunión

· Cronograma del proyecto

20

ANEXO IX: PROCESO DE FORMACIÓN DE LA ORGANIZACIÓN

PROCESO

DE FORMACIÓN DE LA ORGANIZACIÓN

V1.0

21


Fecha

Creación


08/09/2018 Proceso de Formación

de la Organización

Ximena Mendoza 1.0

22

Contenido

1. Descripción Técnica .................................................................................................................. 23

Introducción ................................................................................................................................. 23

Objetivo ........................................................................................................................................ 23

Importancia .................................................................................................................................. 23

2. Definiciones ................................................................................................................................. 23

Conceptos Generales ................................................................................................................ 23

Conceptos Específicos .............................................................................................................. 23

3. Relación del proceso con el modelo CMMI ........................................................................... 23

4. Descripción del Proceso ........................................................................................................... 25

4.2. Descripción de Productos.................................................................................................. 26

4.3. Descripción de Artefactos.................................................................................................. 26

5. Formatos, Documentos y Herramientas ................................................................................. 26

Descripción ...................................................................................................................................... 29

Objetivo del documento ............................................................................................................. 29

Alcance......................................................................................................................................... 29

Importancia del plan de Formación ......................................................................................... 29

Perfiles ............................................................................................................................................. 29

Necesidades de formación............................................................................................................ 29

Planificación de la Formación ....................................................................................................... 29

Metodología ..................................................................................................................................... 30

23


Introducción

El documento contiene un conjunto de artefactos desarrollados para facilitar la implementación de procesos en una institución que cuenta con un área de desarrollo de software. Los elementos característicos son: descripción de procesos, actividades, tareas, roles, plantillas y herramientas.

Objetivo

Proporcionar una guía que permita gestionar la formación de la organización de forma adecuada considerando las necesidades de la institución.

Importancia

La importancia del proceso de formación de la organización radica en considerar a la formación como una inversión ya que mientras mayor capacitación tengan los funcionarios mayores aportes pueden dar a la organización.

2. Definiciones


Conceptos Generales



metas de un proceso. [ISO/IEC 12207]. · Paso: una tarea se descompone en una secuencia de pasos. · Rol: una función definida para ser realizada por un miembro del equipo de

desarrollo del proyecto. [ISO/IEC 24765] · Producto: entregable tangible o intangible que puede ser por una o varias tareas. · Artefacto: información que apoya al proceso durante la ejecución de un proyecto.


· Plan: modelo sistemático que se elabora antes de realizar una acción, con el objetivo de dirigir y guiar.


En esta sección se detalla las actividades relacionadas al proceso de Formación de la Organización para proyectos de desarrollo y mantenimiento de software.

24

El área de proceso de Formación de la Organización (FO) del modelo CMMI-DEV versión 1.3 (Capability Maturity Model Integration) tiene un grupo de prácticas que orientan y garantiza que este proceso sea llevado de forma correcta en los proyectos de desarrollo y mantenimiento de software.

El proceso de Formación de la Organización se apoya mediante formatos, documentos y actas que permiten el registro de las actividades del proceso. En la figura 1 se presenta la ubicación del proceso de Formación de la Organización dentro de los procesos del ciclo de vida de desarrollo de software.


En la figura 2 se presenta la ubicación del proceso de Formación de la Organización

dentro del ciclo de vida de mantenimiento de software.


Proceso de

Formación

25


En esta sección se detalla el proceso con las respectivas actividades del proceso de

Formación de la Organización incluyendo los productos de trabajo generados durante

dichas actividades.

En la figura 3 se muestra el diagrama del proceso de Formación de la Organización

Fig. 26 Formación de la Organización

4.1 Caracterización del Proceso

4.1.1 Análisis de la situación actual.- Lo primero que se debe realizar es un diagnóstico

para determinar las necesidades o falencias en cuando a conocimientos de los

funcionarios, se debe analizar en base a factores internos y externos, los cuales deben

ser considerados a corto y medio plazo. Aquí se evalúa los obstáculos que pueden

presentarse en el desarrollo del plan.

4.1.2 Diseño del Plan de Formación

Para el diseño ya se debe haber identificado las necesidades así como la forma para

poder solucionar los problemas presentados. El plan debe diseñarse en base a lo que

requiere cada una de las áreas agregadoras de valor.

El diseño consiste en tres fases:

· Identificar.- Se debe plantear el tipo de necesidad y porque ocurre.

· Determinar las competencias.- Se debe establecer las habilidades y competencias

necesarias para cubrir con lo que requiere la institución.

· Establecer un objetivo.- Se debe establecer los objetivos del plan de formación.

26

4.1.3 Gestión y Ejecución de la Capacitación

Para planificar la formación se debe considerar los siguientes aspectos:

· Contenido.- En base a las necesidades establecidas en los pasos anteriores

· Destinatarios.- Seleccionar a las personas que va direccionada la formación.

· Número de Personas.- Establecer el número de participantes a quien va destinada

la formación, ya que depende de las competencias y del número para determinar

si hay un número considerable se debe dividir en grupos.

· Cronograma.- Establecer los periodos para la formación

· Duración.- Tiempo que tomara la formación.

· Horario.- Cual es el horario más adecuado.

La formación debe estar respalda por cada uno de los directores para contar con mayor predisposición por parte de los funcionarios.

4.1.4 Evaluación de Resultados

Una vez impartida la formación es necesario realizar una evaluación con el cual se pueda establecer como fue receptada la formación y si fue cumplido o no los objetivos, adicionalmente se puede obtener otras necesidades posteriores.

4.1.5 Resultado y seguimiento

Una vez obtenido los resultados se debe considerar las necesidades expresadas para planes de formación futuros y las mejoras en el plan de formación de ser necesarias.


Nombre Descripción

Plan de Formación Documento que el lineamiento a seguirse para realizar las capacitaciones necesarias para los funcionarios.



Entrevista Entrevista para determinar las necesidades.


En esta sección se presenta los formularios y documentos necesarios para el proceso de gestión de la configuración.

- Plan de Formación

27

PLAN DE FORMACION

V1.0

Proyecto:<<Nombre del Proyecto>>

28


Fecha Creación


08/09/2018 Plan de Formación Ximena Mendoza 1.0

29

Descripción

Objetivo del documento Proporcionar un documento en el cual se especifique que permita proveer los conocimientos y habilidades necesarios para que los funcionarios pueda desempeñar sus roles eficaz y eficientemente, y así facilitar el cumplimiento de los objetivos estratégicos de la organización y las necesidades tácticas de los proyectos y áreas de soporte.

Alcance Este documento está dirigido a las áreas agregadoras de valor, las mismas que utilizan el software SISLAFT para el desempeño de su trabajo.

Importancia del plan de Formación El proceso de formación de la organización es importante porque permite proporcionar al personal capacidades y habilidades para cumplir con el desempeño de sus funciones.

Perfiles

Perfil Descripción

Analista DAO Funcionarios que realizan el análisis de la información recopilada

Analista DSIT Soporte a los sujetos obligados

Analista Prevención Administración de sujetos obligados

Necesidades de formación

Perfil Necesidades

Analista DAO Capacitación del Sistema Sislaft

Analista DSIT Capacitación del Sistema Sislaft / Proceso de Mantenimiento

Analista Prevención Capacitación del Sistema Sislaft

Planificación de la Formación Una vez detectadas las necesidades formativas en cada perfil, se hace necesario planificar la formación a medio-largo plazo. Hay diversas maneras de hacerlo. Para simplificar al máximo el proceso, proponemos una plantilla de programación como la siguiente:

DESTINATARIO AMBITOS NECESIDAD OBJETIVO

CONTENIDOS

ACCIONES FORMATIVAS

Analista DAO Análisis de Información Capacitación

Sislaft

Formar a los analista en el sistema Sislaft para mejorar

Generación de Reportes Estructuras de Sectores

30

el desempeño en su área

Económicos Informes Automatizados

Analista de Prevención

Administración de Sujetos Obligados

Capacitación Sislaft

Formar a los analista en el sistema Sislaft para mejorar el desempeño en su área

Solicitud de Código de Registro Estructuras de Sectores Económicos UAFI

Analista de DSIT

Soporte a Sujetos Obligados

Capacitación Sislaft

Formar a los analista en el sistema Sislaft para mejorar el desempeño en su área

Sistema Sislaft UAFI

Área de Desarrollo

Mantenimiento de Aplicaciones

Capacitación Proceso de Mantenimiento Procesos de Calidad

Poner en conocimiento el documento del Proceso y la documentación del sistema

Proceso de Mantenimiento Manejo de Formularios

Es muy importante que ninguno de los perfiles de las personas que trabajan en nuestra institución quede fuera de este análisis. También es importante reseñar en este apartado, que las necesidades detectadas variarán –y por tanto pueden ser estructuradas- en función de que las personas estén en procesos de formación inicial o permanente. Se estima que debe generarse al menos dos capacitaciones al año y al momento en que se ingresa un nuevo funcionario.

Metodología La metodología propuesta para la formación de la organización puede ser un factor de éxito clave. Los procesos de formación deben ser entendidos como tales procesos y no como acciones puntuales. Normalmente cubrir una necesidad formativa requiere de un trabajo constante y sostenido en el tiempo. Todas las instituciones públicas anualmente solicitan un plan de formación anual de acuerdo a la necesidad institucional cuyo objetivo es transformar y mejorar nuestra práctica. Por tanto, cualquier acción formativa debe tener prevista la forma de que los funcionarios puedan adquirir nuevas herramientas y competencias que la mejoren.

31

ANEXO X: PROCESO DE MANTENIMIENTO

PROCESO DE MANTENIMIENTO

V1.0

32



08/09/2018 Proceso de Mantenimiento Ximena Mendoza 1.0

33

Contenido

PROCESO DE MANTENIMIENTO ....................................................................................................... 31

1. Descripción Técnica ............................................................................................................... 34

Objetivo ........................................................................................................................................ 34

Importancia .................................................................................................................................. 34

2. Definiciones ............................................................................................................................. 34

Mantenimiento de Software ...................................................................................................... 34

Tipos de mantenimiento ............................................................................................................ 34

Actores y Roles en el proceso de Mantenimiento ................................................................. 35

3. Relación con el proceso CMMI ............................................................................................ 35

4. Descripción del Proceso ........................................................................................................ 35

34


Objetivo El objetivo del Proceso de Mantenimiento es modificar un producto software existente preservando su integridad es decir alargar la vida útil del software y adaptarse a nuevas necesidades de los clientes.

Importancia Es importante definir el proceso de Mantenimiento de Software debido a que permite que otros miembros del equipo de desarrollo se integren sin mayores dificultades y se aliñen a lo establecido dentro de los procesos relacionados con el mantenimiento de software.

2. Definiciones

Mantenimiento de Software IEEE, define el Mantenimiento del Software como la modificación de un producto de software después de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno. Sin embargo, y aunque no se aprecia a lo largo del estándar IEEE 1219, el proceso de Mantenimiento del Software comienza con las primeras fases del ciclo de vida, puesto que el coste de Mantenimiento va a estar tremendamente influido por las decisiones que se tomen en cada una de estas fases.

Tipos de mantenimiento

Fig. 27 Clasificación de las solicitudes y Tipos de Mantenimiento

Existen diversos tipos de Mantenimiento del Software dependiendo de las demandas de los usuarios del producto Software a mantener:

· Adaptativo: Modificación de un producto software, después de su entrega, para adaptarse a nuevas necesidades del cliente.

Solicitud de Modificación

Correción

Mantenimiento Preventivo

Mantenimiento Correctivo

Mejora

Mantenimiento Adaptativo

Mantenimiento Perfectivo

35

· Correctivo: Modificación de un producto software, después de su entrega, para corregir defectos detectados, mismo que no fueron detectados en la fase de pruebas

· Perfectivo: Modificación de un producto software, después de su entrega, para mejorar su rendimiento o su mantenibilidad.

· Preventivo: Modificación de un producto software, después de su entrega, para detectar y corregir defectos latentes antes de que produzca fallos efectivos.

En ocasiones, el mantenimiento puede estar relacionado con problemas que deben solucionarse de manera urgente. Los cambios urgentes pueden darse por tres razones:

· SÍ ocurre un defecto que afecte al funcionamiento normal del sistema.

· Si los cambios en el entorno del sistema operativo tienen efectos inesperados que impiden el funcionamiento normal.

· Si hay cambios no anticipados en las instituciones que utilizan el sistema, cambios en las leyes.

En estos casos, se realiza una reparación de emergencia en el sistema para resolver el problema de forma inmediata.

Actores y Roles en el proceso de Mantenimiento Los actores y los roles que participan durante el proceso de mantenimiento pueden variar considerablemente dependiendo de cada institución. Los cuatro roles principales que se deben definir en un proceso de mantenimiento de software [1]:

1. Solicitante del mantenimiento: Presenta las solicitudes de modificación y establece los requerimientos necesarios para su implementación.

2. Gestor de peticiones: Responsable de aceptar o rechazar las peticiones de modificación y decidir el tipo de mantenimiento que se debe aplicar. Además, es el encargado de planificar la cola de peticiones de modificación aceptadas.

3. Responsable de mantenimiento: Encargado de preparar el proceso de mantenimiento, establecer las normas y procedimientos necesarios para aplicar la guía. Es quien interactúa con el solicitante y trabaja a la par con el equipo de mantenimiento.

4. Equipo de mantenimiento: Es el grupo de personas que implementan los cambios presentados en la solicitud de modificación y realizan todas las tareas indicadas por el Responsable de mantenimiento.

3. Relación con el proceso CMMI Definición de Procesos de la Organización es “El propósito de la Definición de Procesos de la Organización (OPD) es establecer y mantener un conjunto utilizable de activos de procesos de la organización, estándares del entorno de trabajo, y reglas y guías para los equipos”.

4. Descripción del Proceso El proceso de mantenimiento de software cuenta con varios estándares definidos para llevar a cabo el proceso. Entre los estándares más conocidos están los definidos por la

36

ISO/IEC 12207 y la IEEE - 1219. Y a partir de estos estándares, empezaron a surgir, metodologías para mantenimiento de software. Si bien los estándares son una guía, dichos estándares deben adaptarse a las necesidades institucionales, por lo cual debido al giro institucional se debe hacer un match entre estos dos estándares.

Fig. 28 Fases del Proceso de Mantenimiento de Software (IEEE 1219)

Fuente: J.A. Martínez Párraga, Planificación y Gestión de Sistemas de Información, Estándar IEEE 1219 de Mantenimiento de Software, 1999

Como se mencionó anteriormente pueden presentarse diferentes tipos de mantenimiento y cada uno de estos tipos tiene diferentes fases en algunos casos en común. Cuando el mantenimiento es por un proveedor externo o un desarrollador nuevo es necesario que se revise la documentación del proyecto, la cual se detalla en la Plantilla 1 Inventario de Documentación de Proyectos 1: Identificación, clasificación y priorización del problema.

Fig. 29 Fase 1 Proceso Mantenimiento

Diseño

Implementacion

Prueba del

Sistema


Liberacion


Analisis

37

En esta fase se identifica el problema o la necesidad, se clasifica el tipo de mantenimiento y se asigna prioridad para dependiendo de esto agregarle al plan de mantenimiento. Las actividades que se deben realizar en esta fase se muestran en la Fig. 3. En caso de ser emergente el mantenimiento se le da la mayor prioridad al incidente presentado, ya que se debe dar una respuesta inmediata. En esta fase posterior a la solicitud de modificación es necesario llevar un registro de los requerimientos para lo cual utilizaremos la plantilla 2. 2: Análisis

Fig. 30 Fase 2 Proceso de mantenimiento En esta fase se analiza la viabilidad de la solicitud de modificación, considerando impacto, tiempo, costos, soluciones alternativas, estrategias de implementación entre otras. Dentro de esta fase se debe utilizar la plantilla 3. 3: Diseño

Fig. 31 Fase 3 Proceso de Mantenimiento de Software En esta fase con base en la documentación generada, código fuente, base de datos y otra se diseña la modificación, en esta fase se realiza las actividades mostradas en la Fig. 5. 4: Implementación

Fig. 32 Fase 4 Proceso de Mantenimiento En esta fase se realiza la implementación de los cambios validados en la fase de análisis, se ejecutan pruebas de unidad, integración y regresión, para verificar que lo implementado está funcionando correctamente.

38

Posteriormente en esta fase se obtiene una nueva versión del software, la misma que debe estar bajo la Gestión de Configuración, con toda la documentación generada o modificada. 5: Pruebas del sistema

Fig. 33 Fase 5 Proceso de Mantenimiento En esta fase se verifica que el software este funcionado de forma integral, esto se logra mediante la realización de pruebas de funcionalidad, integración y regresión, con esto se logra que no existas errores que antes de la ejecución del mantenimiento no existían. 6: Pruebas de aceptación En esta fase se debe efectuar las pruebas con el área requiriente ya sobre el software completamente integrado, en esta fase interviene el cliente y el usuario final. Las actividades que se realizan en esta fase se muestran en la Fig. 8.

Fig. 34 Fase 6 Proceso de Mantenimiento 7: Liberación En esta fase se coloca en producción la nueva versión del software, para ello se debe realizar un plan de implementación.

Fig. 35 Fase 7 Proceso Mantenimiento 8: Retirada del software

39

El software puede retirarse en algunos casos porque ya cumplió su vida útil, es decir el software esta implementado en tecnologías obsoletas, o el mantenimiento del sistema ya no es manejable, esto dependerá del dueño del producto. Para retirar el software debe existir un análisis que permita ayudar a tomar la decisión antes de retirar el producto software. Este análisis debe ser incluido en el plan de retiro. Para retirar un producto software, el mantenedor debe determinar las acciones necesarias para el retiro y con base en esto, se debe desarrollar y documentar los pasos necesarios para realizar el retiro, las actividades se muestran en la fig.

Fig. 36 Fase 8 Proceso de Mantenimiento Además de las actividades indicadas, el estándar define una serie de elementos de entrada y salida, así como algunos controles para cada una de estas fases. En la Tabla 1 se presentan estos elementos.

Tabla 9 Entradas, controles y salidas de las distintas etapas del proceso de mantenimiento del

software (IEEE 1219-1999)

ETAPA ENTRADA CONTROLES SALIDAS

Identificación del problema

Solicitud de modificación.

Identificador único de la solicitud Entrada de la solicitud de modificación al repositorio

Solicitud de modificación validada Proceso determinado

Análisis

Documentos del proyecto o sistema Solicitud de modificación validada

Revisión técnica Verificación de estrategias de prueba y documentación actualizada Identificación de aspectos de seguridad

Reporte de factibilidad Reporte de análisis detallado Requerimientos actualizados Lista de modificaciones preliminares Plan de implementación Estrategia de pruebas

40

Diseño

Documentación del sistema Código Fuente Bases de datos Salida de la etapa de análisis

Revisión e inspección del software Verificación del diseño

Lista de modificaciones revisadas Análisis detallado revisado Plan de implementación revisado Línea base del diseño actualizada Plan de pruebas actualizado

Implementación

Código fuente Documentación del sistema Resultados de la etapa de diseño

Revisión e inspección del software Verificación del control de la administración de configuración Verificación de la trazabilidad del diseño

Software actualizado Documentos del diseño actualizados Documentos de pruebas actualizados Documentos de usuario actualizados Material de entrenamiento actualizado Reporte de la preparación de pruebas actualizado

Pruebas del sistema

Documentación actualizada del software Reporte de la preparación de pruebas Sistema actualizado

Control de la administración de configuración de: código, listados, SM, documentación de pruebas

Sistema probado Reporte de pruebas

Pruebas de aceptación

Reporte de la preparación de pruebas Sistema totalmente integrado Planes, casos y procedimientos de las pruebas de aceptación

Pruebas de aceptación Auditoría funcional Establecimiento del sistema base

Nueva línea de base del sistema Reporte de pruebas de aceptación Reporte de la auditoría de configuración

41

funcional

Liberación Sistema probado y aceptado

Auditoría de configuración física Documento de la descripción de versión

Reporte de auditoría de configuración física Documento de la descripción de versión

Fuente: J.A. Martínez Párraga, Planificación y Gestión de Sistemas de Información, Estándar IEEE

1219 de Mantenimiento de Software, 1999

5. Formatos

En esta sección se detalla todos los formatos y documentos necesarios para realizar este proceso.

· Inventario de Documentación

INVENTARIO DE DOCUMENTACION DE PROYECTOS UAFE

IdDocumento Documento Etapa de Mantenimiento Versión Observaciones Proyecto

· Registro de Requerimientos

Proyecto: Nombre del Proyecto

Líder de Aplicaciones:

Nombre del líder de aplicaciones

IdSolicitud

Fecha Solicitud

Descripción Responsable Estado

Observaciones

Área Requiriente

Motivo

42

Número de Identificación de la Solicitud

Fecha de la Solicitud

Defina el requerimiento solicitado

Nombre del responsable del requerimiento

Estado del Requerimiento: Solicitado, En Proceso, Concluido

Describa alguna observación al requerimiento

· Definición del impacto del cambio

Proyecto: Nombre del Proyecto

Líder de Aplicaciones: Nombre del líder de aplicaciones

Id Requerimiento Requerimiento

Módulo a modificar

Elemento del módulo a modificar

Detalle de la modificación Observaciones

Numero de requerimiento

Detalle del requerimiento

Detalle del módulo a modificar

Detalle de la clase, documento, interfaz a modificar

Detalle de la modificación a realizarse en el elemento

Detalle si existe alguna observación

· Plan de Pruebas

· Formulario de Paso a producción

43

ANEXO XI: PROCESO DE ASEGURAMIENTO DE CALIDAD

PROCESO

DE ASEGURAMIENTO DE CALIDAD

V1.0

44



15/09/2018 Proceso de Aseguramiento

de Calidad

Ximena Mendoza 1.0

45

Contenido

1. Descripción Técnica .......................................................................... ¡Error! Marcador no definido.

Introducción ..................................................................................... ¡Error! Marcador no definido.

Objetivo ............................................................................................ ¡Error! Marcador no definido.

Importancia ...................................................................................... ¡Error! Marcador no definido.

2. Definiciones ...................................................................................... ¡Error! Marcador no definido.

Términos Genéricos ......................................................................... ¡Error! Marcador no definido.

Términos Específicos ........................................................................ ¡Error! Marcador no definido.

3. Relación del proceso con el modelo CMMI ...................................... ¡Error! Marcador no definido.

4. Descripción del Proceso ................................................................... ¡Error! Marcador no definido.

4.1. Actividades ................................................................................ ¡Error! Marcador no definido.

4.1.1. Actividad: AC.1 Establecer los productos y procesos a verificar ........ ¡Error! Marcador no

definido.

4.1.2. Actividad: AC.2 Elaborar listas de verificación para verificación de procesos y productos

...................................................................................................... ¡Error! Marcador no definido.

4.1.3. Actividad: AC.3 Efectuar las verificaciones de procesos y productos establecidos . ¡Error!

Marcador no definido.

4.1.4. Actividad: AC.4 Efectuar adaptaciones según las verificaciones realizadas ............ ¡Error!

Marcador no definido.

4.2 Descripción de los Roles ............................................................. ¡Error! Marcador no definido.

4.3. Descripción de Productos .......................................................... ¡Error! Marcador no definido.

5. Formatos .......................................................................................... ¡Error! Marcador no definido.

46


Introducción

El documento contiene un conjunto de artefactos desarrollados para facilitar la implementación

de procesos en una institución que cuenta con un área de desarrollo de software. Los elementos

característicos son: descripción de procesos, actividades, tareas, roles plantillas y herramientas.

Objetivo

El propósito de este documento es proporcionar los lineamientos para realizar el proceso de

Aseguramiento de Calidad dentro de los proyectos de desarrollo y mantenimiento de software, en

proyectos ejecutados en periodos cortos de tiempo.

Importancia

El proceso de aseguramiento de calidad es importante porque garantiza que los procesos y los

productos de trabajo, se realicen según los estándares establecidos, contribuyendo a la correcta

ejecución del proyecto.

2. Definiciones

Esta sección contiene la definición de conceptos generales y específicos que se utilizan en el

proceso.

Conceptos Generales









· Lista de Verificación: Permite apoyar los procesos establecidos, presentando

recordatorios de los puntos claves en la ejecución de cada proceso, para evitar duplicidad

de actividades durante el proyecto.

· Producto de Trabajo: Es el resultado producto de un proceso. Este resultado puede incluir

archivos, documentos, productos, servicios, descripciones de procesos, especificaciones,

etc.

47


En esta sección de proceso cubre las actividades relacionadas al proceso de aseguramiento de

calidad para proyectos de desarrollo y mantenimiento de software.

CMMI-DEV v1.3 tiene una área de proceso que se encarga del aseguramiento de la misma que

contiene un conjunto de prácticas que guían y avalan la calidad en proyectos de desarrollo y

mantenimiento de software.

Este proceso aplica para proyectos de desarrollo y mantenimiento de software a la medida, de

complejidad media de duración corta.

El proceso de aseguramiento de calidad se apoya mediante formatos, documentos y actas que

permiten el registro de las actividades del proceso.

En la figura 1 se presenta la ubicación del proceso de aseguramiento de calidad dentro de los

procesos del ciclo de vida del desarrollo de software.


En la figura 2 se presenta la ubicación del proceso de Aseguramiento de Calidad dentro del ciclo de

vida de mantenimiento de software.

Gestión de

Configuración

Gestión de

Requerimientos

Medición y

Análisis

Aseguramiento

de Calidad

Seguimiento y

Control

48




subprocesos del proceso de aseguramiento de calidad incluyendo los productos de trabajo


En la figura 3 se muestra el diagrama de la configuración del proyecto, que forma parte del

aseguramiento de calidad:

Figura 3 — Proceso de Aseguramiento de Calidad

4.1. Actividades

Diseño

Implementacion

Prueba del

Sistema


Liberacion


Analisis

49

El proceso de Aseguramiento de Calidad (AC) tiene las siguientes actividades que se detallan a

continuación:

4.1.1. Establecer los productos y procesos a verificar

Permite identificar los procesos y productos de trabajo que se deben verificar mientras se ejecuta

el proyecto para avalar el cumplimiento de estándares y procesos establecidos para proyectos de

desarrollo y mantenimiento de software.

Establecer los productos y procesos a verificar

Objetivo: Identificar los procesos y productos de trabajo que deben verificarse

mientras se ejecute el proyecto.

Justificación: Avala el cumplimiento de los estándares y procesos establecidos para

proyectos de desarrollo y mantenimiento de software.


Artefactos: Procesos y productos de trabajo generados durante la ejecución del

proyecto

Acta de Constitución del proyecto

Pasos: Paso 1: Revisar los procesos y productos de trabajo producto de la

ejecución del proyecto

Paso 2: Identificar los procesos y productos de trabajo que deben seguir

el proceso de verificación

Detalle de Pasos: Paso 1: Revisar los procesos y productos de trabajo generados durante

la ejecución del proyecto

El equipo de desarrollo del proyecto debe analizar los procesos

realizados durante la ejecución del proyecto y los productos de trabajo

que deben ser verificados bajo el proceso de calidad establecido.

Paso 2: Identificar los procesos y productos de trabajo que deben

seguir el proceso de verificación

Se identifica los procesos y productos de trabajo que deben ser

verificados para avalar que se cumplen con los estándares establecidos

para minimizar o evitar duplicidad de actividades mientras el proyecto se

ejecute.

4.1.2. Elaborar listas de verificación para verificación de procesos y productos

Permite establecer que información será analizada en los procesos y productos de trabajo para

determinar el nivel de acoplamiento del proyecto a los procesos establecidos para su ejecución.

Elaborar listas de verificación para verificación de procesos y productos

Objetivo: Establecer que información será analizada en los procesos y productos

de trabajo para determinar el nivel de acoplamiento con los procesos

establecidos

50

Justificación: Identificar el nivel de acoplamiento del proyecto a los procesos

organizacionales definidos para la ejecución del proyecto.


Artefactos: Listas de verificación de procesos y productos de trabajo

Pasos: Paso 1: Revisar el plan de aseguramiento de calidad

Paso 2: Revisar las listas de chequeo estándar establecidas para la

calidad de los proyectos

Paso 3: Elegir o construir las listas de chequeo que permiten verificar

procesos y productos de trabajo

Detalle de Pasos: Paso 1: Revisar el plan de aseguramiento de calidad

El plan de aseguramiento de calidad debe ser analizado por el equipo de

desarrollo del proyecto establecido anteriormente para construir las

listas de verificación que apoyan en el proceso de calidad del proyecto.

Paso 2: Revisar las listas de chequeo estándar establecidas para la

calidad de los proyectos

Las listas de verificación estándar deben ser revisadas para la calidad del

proyecto e identificar las listas de acuerdo al proceso que se va a

verificar.

Paso 3: Elegir o construir las listas de verificación que permiten verificar

procesos y productos de trabajo

Se debe elegir o construir las listas de verificación en caso de que no

exista para el proceso que se va a verificar.

4.1.3. Efectuar las verificaciones de procesos y productos establecidos

Permite tener identificado el nivel de acoplamiento del proyecto con los procesos y estándares

establecidos para la ejecución.

Efectuar las verificaciones de procesos y productos establecidos

Objetivo: Conocer el nivel de acoplamiento del proyecto a los procesos y

estándares establecidos para su ejecución.

Justificación: Permite una ejecución del proyecto que cumple con procesos y

estándares establecidos.


Artefactos: Listas de verificación

Pasos: Paso 1: Realizar las verificaciones de los procesos y productos

establecidas en el plan de aseguramiento de calidad

Detalle de Pasos: Paso 1: Efectuar las verificaciones de los procesos y productos

establecidas en el plan de aseguramiento de calidad

La verificación del proceso o producto establecido en el plan de

aseguramiento de calidad lo realiza el equipo de desarrollo del proyecto

y debe resolver la lista de verificación adecuada.

51

4.1.4. Efectuar adaptaciones según las verificaciones realizadas

Permite adaptar como se ejecutan los proyectos y productos de trabajo creados, cuando exista

inconsistencias o errores en los proyectos de desarrollo de software.

Efectuar adaptaciones según las verificaciones realizadas

Objetivo: Adaptar como se ejecutan los proyectos y productos de trabajo creados,

cuando existan inconsistencias o errores en los proyectos de desarrollo de

software.

Justificación: Se garantiza que el proyecto cumple con los estándares de calidad


Artefactos: N/A

Pasos: Paso 1: Revisar los resultados de las verificaciones realizadas

Paso 2: Efectuar adaptaciones en los procesos y productos de trabajo del

proyecto

Detalle de Pasos: Paso 1: Revisar los resultados de las verificaciones realizadas

Los miembros del equipo del proyecto deben revisar los resultados de las verificaciones realizadas para programar los ajustes que sean necesarios en los procesos y productos de trabajo.

Paso 2: Efectuar adaptaciones en los procesos y productos de trabajo del

proyecto

Con base en las revisiones realizadas se debe ajustar los procesos o productos de trabajo.


Las actividades del proceso de aseguramiento de calidad serán realizadas por cualquier integrante

del equipo del proyecto.


Equipo de

Calidad

QA Conocimiento en estándares de calidad

Conocimiento en el negocio.

Líder de

proyecto

LP Proactividad

Capacidad de liderazgo

Trabajo en equipo


Nombre Descripción

Acta de Constitución

del proyecto

Documento que se elabora en la fase de diagnóstico del proyecto y debe

ser actualizado con el plan de aseguramiento de calidad definido durante

52

la actividad “Definir los productos y procesos a verificar”.

Listas de verificación

estándar

Documentos que permiten guían la verificación de los procesos y

productos de trabajo del proyecto. A continuación las listas de

verificación estándar:

· Lista de chequeo de reunión de levantamiento de información

· Lista de verificación de validación de productos

· Lista de verificación de validación de línea base de

requerimientos

· Lista de verificación de auditorías de configuración

5. Formatos

En esta sección se detalla los formatos y documentos necesarios para realizar este proceso.

· Acta de Constitución del Proyecto

· Listas de Verificación

o Reunión De Levantamiento De Información

o Validación De Productos

o Validación De Línea Base De Requerimientos

o Auditorias De Configuración

o Diagnostico

o Análisis De Requerimientos

o Diseño

o Pruebas

o Administración De Requerimientos

o Gestión De Configuración

o Medición Y Análisis

o Seguimiento Y Control

LISTA DE VERIFICACION DE LA GESTION DE LA CONFIGURACION


Líder de Proyecto: Nombre del líder del proyecto

Fecha: Fecha de realización del proceso de aseguramiento de calidad

Fase:

Fase en la que se encuentra el proyecto al momento del aseguramiento

de calidad

Responsable: Nombre de la persona que realiza la verificación

LISTA DE VERIFICACION SI/NO Observaciones

¿El proyecto en el SVN fue creado en base al estándar

establecido?

¿Para la administración de usuario se utilizó el documento

53

correspondiente?

¿Se encuentran en los repositorios los productos de trabajo de

los diferentes procesos?

¿Se actualizó diariamente el proyecto en el SVN?

¿E l plan de auditorías de configuración del proyecto fue

establecido y se utilizó el documento de plan de auditorías de

configuración?

¿Las auditorías de configuración fueron realizadas en base al plan

establecido?

¿Fueron solventados los problemas reportados durante las

auditorias de configuración?

¿La liberación de las versiones del producto fue con base en el

documento para este fin, cuando fue requerido?

¿En la primera versión del producto se estableció la línea base

del producto?

LISTA DE VERIFICACION DE LA MEDICION Y ANALISIS



Fecha: Fecha en la que se realiza la actividad de aseguramiento de calidad

Fase:

Fase en la que se encuentra el proyecto cuando se realiza la actividad

de aseguramiento de calidad

Responsable: Nombre de la persona que realiza el chequeo

LISTA DE VERIFICACION SI/NO OBSERVACIONES

¿La lista de indicadores estándar fue revisada?

¿Se eligieron los indicadores para el proyecto?

¿Se establecieron los objetivos y la métrica de medición de cada

indicador elegido?

¿Se elaboró el formulario de cada indicador, siguiendo el

formato establecido?

¿Se recopilaron los datos necesarios para las mediciones

establecidas?

¿Se efectuaron las mediciones de los indicadores establecidos?

¿Existió el análisis de las mediciones, según el formulario del

indicador?

¿Fueron ejecutadas las acciones correctivas cuando fue

necesario?

¿Se verificó la aplicación de las acciones correctivas

54

implementadas?

¿Se almaceno la documentación en el repositorio SVN?

LISTA DE VERIFICACION GESTION DE REQUERIMIENTOS




Fase:

Fase en la que se encuentra el proyecto cuando se realiza la actividad

de aseguramiento de calidad



¿La línea base de requerimientos establecidos fue validada

durante el proceso de análisis de requerimientos, con el equipo

o cliente?

¿Los cambios presentados fueron controlados durante el

proyecto, siguiendo el proceso de control de cambios definido?

¿Los cambios fueron realizados utilizando el formato de

solicitud de cambios?

¿El análisis del impacto del cambio fue realizado en el proyecto,

utilizando el formato de solicitud de cambios?

¿Los cambios fueron aprobados antes de ser implementados?

¿El plan de implementación de cambios fue realizado después

de su aprobación?

¿Los productos de trabajo relacionados con los requerimientos

asociados fueron actualizados cuando se presentaron cambios

en el proyecto?

¿Se colocó la documentación en el SVN?

LISTA DE VERIFICACION DE SEGUIMIENTO Y CONTROL




Fase:

Fase en la que se encuentra el proyecto cuando se realiza la actividad de

aseguramiento de calidad


55


¿Las reuniones semanales de seguimiento de actividades fueron

realizadas?

¿El reporte de seguimiento semanal se realizó siguiendo el

formato?

¿Las revisiones de actividades personalizadas fueron realizadas?

¿Se realizaron los reportes de las revisiones semanales

personalizadas, siguiendo el formato establecido?

¿Se realizaron las reuniones de análisis de riesgos definidas en

el Project chárter?

¿Se actualizo la matriz de riesgos cada vez que fue necesario?

¿Se cuenta con la documentación respectiva?

ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/20010/1/CD-9450.pdf · De...

Documents

Transcript of ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/20010/1/CD-9450.pdf · De...