Tesis final entrega - Javeriana, Cali

DEFINICIÓN DEL PROCESO DE RENDIMIENTO ORGANIZACIONAL EN EL ÁREA DE DESARROLLO DE SOFTWARE EN LA EMPRESA EXPERT INFORMATION SAS

PARA LA VALORACIÓN DE CMMI DEV 1.3 NIVEL CINCO

MARÍA CAMILA ORTEGÓN HERRERA

PONTIFICIA UNIVERSIDAD JAVERIANA CALI

DEPARTAMENTO DE INGENIERÍA CIVIL E INDUSTRIAL

FACTULTAD DE INGENIERÍA

SANTIAGO DE CALI

2017

DEFINICIÓN DEL PROCESO DE RENDIMIENTO ORGANIZACIONAL EN EL ÁREA DE DESARROLLO DE SOFTWARE EN LA EMPRESA EXPERT INFORMATION SAS

PARA LA VALORACIÓN DE CMMI DEV 1.3 NIVEL CINCO

MARÍA CAMILA ORTEGÓN HERRERA

Director:

MANUEL JOSE OSPINA OSPINA

Trabajo de grado como requisito parcial para obtener el título de ingeniera industrial

PONTIFICIA UNIVERSIDAD JAVERIANA CALI

DEPARTAMENTO DE INGENIERÍA CIVIL E INDUSTRIAL

FACTULTAD DE INGENIERÍA

SANTIAGO DE CALI

2017

Dedicatoria

Quiero dedicar este trabajo a Dios, por su amor y apoyo incondicional en todo momento,

por brindarme la fortaleza necesaria para perseverar ante la adversidad, por alentarme a seguir

mis sueños y no desfallecer hasta alcanzarlos.

A mis padres por creer siempre en mí, por sus palabras de aliento en los momentos

difíciles, por su esfuerzo y lucha constante que me han permitido alcanzar mis metas e

impulsado a seguir persiguiendo nuevos sueños, por su valentía para acompañarme a lo largo

de estos cinco años y su amor incondicional.

Índice general

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

2. Planteamiento del problema de investigación ..................................................................... 2

3. Objetivos .............................................................................................................................. 3

3.1 Objetivo General .......................................................................................................... 3

3.2 Objetivos específicos.................................................................................................... 3

4. Justificación ......................................................................................................................... 4

5. Alcance ................................................................................................................................ 5

6. Marco referencial ................................................................................................................. 6

6.1 Marco teórico ............................................................................................................... 6

CMMI .................................................................................................................. 6

Gerencia de proyectos .......................................................................................... 9

Ciclos de vida del software ................................................................................ 10

6.2 Antecedentes .............................................................................................................. 11

7. Realización de un análisis preliminar que permite comparar los procesos actuales de la compañía contra el proceso de Rendimiento Organizacional del modelo CMMI DEV 1.3 nivel 4 13

7.1 Revisión de los procesos documentados por la compañía ......................................... 13

7.2 Revisión documental de las auditorias de cumplimiento de procesos ....................... 13

7.3 Documentación de los hallazgos encontrados en la revisión de los procesos actuales de la compañía ........................................................................................................................... 13

Diagrama de flujo genérico ................................................................................ 13

Roles .................................................................................................................. 15

Procesos transversales ........................................................................................ 18

Fases ................................................................................................................... 26

7.4 Comparación de los hallazgos encontrados contra los procesos documentados con el modelo de Rendimiento Organizacional propuesto en el CMMI DEV 1.3 .......................... 55

7.5 Definición de la prioridad de los hallazgos encontrados............................................ 56

7.6 Realización del plan de acción ................................................................................... 56

Definición de actividades específicas ................................................................ 57

Definición del cronograma del plan de acción .................................................. 57

8. Caracterización y definición de los procesos organizacionales, que son susceptibles de estandarización y mantenimiento según el proceso de Rendimiento Organizacional del modelo CMMI DEV 1.3 nivel 4. .............................................................................................. 58

8.1 Identificación de los procesos susceptibles de estandarización y mantenimiento con base en los hallazgos y en las reuniones de trabajo propuestas en el objetivo específico 1 . 58

8.2 Caracterización y documentación de los procesos susceptibles de estandarización y mantenimiento ....................................................................................................................... 58

Fase de requerimientos ...................................................................................... 59

Fase de diseño .................................................................................................... 59

Fase de implementación ..................................................................................... 59

9. Definición de indicadores de rendimiento para los diferentes procesos de la organización con base en el proceso de Rendimiento Organizacional del modelo CMMI DEV 1.3 nivel 4 60

9.1 Fase de requerimientos ............................................................................................... 60

Identificación de los puntos de control y medición en los procesos de acuerdo al proceso de Rendimiento Organizacional propuesto en el modelo CMMI DEV 1.3 ........ 60

Definición de las métricas .................................................................................. 60

Definición de los requerimientos de información histórica para el establecimiento de las métricas y los indicadores de rendimiento ............................................................. 61

Definición del procedimiento de medición y toma de datos de los indicadores 61

Establecimiento de los valores de tolerancia ..................................................... 72

9.2 Fase de diseño ............................................................................................................ 72






9.3 Fase de implementación ............................................................................................. 82






Índice global de productividad del proyecto (IGP)............................................ 94

10. Conclusiones ...................................................................................................................... 96

11. Recomendaciones .............................................................................................................. 97

12. Referencias ........................................................................................................................ 98

13. Anexos ............................................................................................................................. 100

Lista de Anexos

Representación por etapas y representación continua. Fuente: Díaz (2009). ....... 100

Proceso de desarrollo de software. ........................................................................ 100

Organigrama. ........................................................................................................ 101

Inspección por recorrido. ...................................................................................... 102

Monitoreo del proyecto. ........................................................................................ 103

Plan de administración de la configuración. ......................................................... 104

Planeación de actividades cortas. .......................................................................... 105

Revisiones mayores .............................................................................................. 106

Selección de alternativas. ...................................................................................... 107

Fase de pre-análisis. .............................................................................................. 108

Pre-análisis. ........................................................................................................... 109

Selección de equipo de trabajo. ............................................................................ 110

Estimación inicial de proyectos. ........................................................................... 111

Fase de planeación. ............................................................................................... 112

Proceso de planeación del proyecto. ..................................................................... 113

Plan de aseguramiento de la calidad. .................................................................... 114

Análisis de riesgos. ............................................................................................... 114

Desarrollo de software. ......................................................................................... 115

Análisis de decisiones y resolución. ..................................................................... 116

Fase de requerimientos. ........................................................................................ 117

Requerimientos. .................................................................................................... 117

Formato de casos de uso. ...................................................................................... 118

Fase de diseño. ...................................................................................................... 119

Diseño. .................................................................................................................. 120

Fase de implementación. ....................................................................................... 120

Implementación..................................................................................................... 121

Fase de implantación............................................................................................. 122

Pruebas de despliegue. .......................................................................................... 123

Proceso despliegue a ambiente de pruebas. .......................................................... 124

Pruebas de integración y funcionales. ................................................................... 125

Pruebas de sistema. ............................................................................................... 126

Cierre del proyecto ................................................................................................ 127

Cronograma de trabajo. ......................................................................................... 128

Proceso seleccionado para realizar las mediciones. .............................................. 129

Subprocesos seleccionados para medición en la fase de requerimientos. ............ 129

Pantalla de ingreso de datos. ................................................................................. 130


Subprocesos seleccionados para medición en la fase de diseño. .......................... 131


Subprocesos seleccionados para medición en la fase de implementación. ........... 132

Balanced Scorecard. .............................................................................................. 135

Glosario

Cliente: El PMBOK (2013) define este concepto como “El cliente es la(s) persona(s) u organización(es) que pagará(n) por el producto, servicio o resultado del proyecto. Los clientes pueden ser internos o externos a la organización ejecutante” (p.532).

Comité de control de cambios (CCB): El PMBOK (2013) define el concepto de comité de control de cambios como “Un grupo formalmente constituido responsable de revisar, evaluar, aprobar, retrasar o rechazar los cambios en el proyecto, así como de registrar y comunicar dichas decisiones” (p.533).

Diseño de alto nivel: Es la relación entre los elementos estructurales principales del software, los patrones de diseño que se pueden utilizar para lograr los requisitos que se han definido para el sistema, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de diseño arquitectónico (Pressman, 2011, p.220).

Enterprise architect: Sparx Systems (2017) señala que “enterprise Architect es una herramienta de análisis y diseño UML para UML, SysML, BPMN y muchas otras tecnologías. Cubriendo el desarrollo de software desde la recolección de requerimientos hasta las etapas de análisis, modelos de diseño, pruebas y mantenimiento”.

Especificación de diseño de alto nivel (HLD): Roger S. Fressman afirma: “la especificación de diseño aborda diferentes aspectos del modelo de diseño y se completa a medida que el diseñador refina su propia representación del software” (p. 233).

ICEBERG: Es un sistema de información de gestión de proyectos desarrollado al interior de la compañía Expert Information SAS (Expert Information SAS, 2016).

Identificación y priorización de atributos de calidad (IPAC): Roger S. Pressman, define los atributos de calidad como aquellos atributos que se exhiben ante los ojos de los usuarios para lograr que la aplicación sea buena y al mismo tiempo cumpla con las características técnicas de calidad que permitan al ingeniero corregir, adaptar, mejorar y soportar la aplicación a largo plazo (Pressman, 2011, p.523).

Línea base: El PMBOK (2013) define el concepto de línea base como “La versión aprobada de un producto de trabajo que sólo puede cambiarse mediante procedimientos formales de control de cambios y que se usa como base de comparación” (p.551).

Listas de verificación: El PMBOK (2013) define el concepto de listas de verificación como “Una herramienta estructurada utilizada para verificar que se haya llevado a cabo un conjunto de pasos necesarios” (p.552).

LOC: En ingeniería de software, las líneas de código producidas (LOC) se utilizan como una medida directa del producto desarrollado (Pressman, 2011, p. 58).

Matriz de habilidades: Organiza de forma matricial los miembros del equipo de trabajo y los conocimientos que estos poseen. De tal forma que se puedan escoger los miembros del equipo del proyecto acorde a las habilidades que este requiere (Expert Information SAS, 2016).

Matriz de métricas: Es una herramienta resumen donde se muestra un resumen de las métricas de los proyectos (Expert Information SAS, 2016).

Matriz de trazabilidad: Es una matriz donde se muestran las relaciones de todos los artefactos del proceso completo de desarrollo con los requerimientos (Expert Information SAS, 2016).

Propuestas de mejora al proceso (PIPs): Los integrantes del equipo pueden hacer propuestas de mejoras en herramientas, técnicas o procesos, esto lo hacen por medio del sistema ICEBERG (Expert Information SAS, 2016).

Power designer: SAP Sybase Power Designer es la solución de gestión de metadatos y procesos de negocio líder en la industria para la arquitectura de datos, la arquitectura de la información y la arquitectura empresarial. Power Designer ofrece un potente análisis de impacto, gestión del cambio en tiempo de diseño y técnicas de gestión de metadatos a su empresa. Combinando técnicas de gestión de metadatos y modelado líderes en la industria, Power Designer está equipado de manera única para soportar todos los entornos arquitectónicos (PowerDesigner, 2016).

Producto: El PMBOK (2013) define el concepto de producto como “Un artículo producido, que es cuantificable y que puede ser un elemento terminado o un componente. Otras palabras para hacer referencia a los productos son materiales y bienes” (p.559).

Product Backlog Item: Se refiere a la “lista de requisitos de usuario, que a partir de la visión inicial crece y evoluciona durante el desarrollo” (Scrum Manager, p. 21).

Requerimientos funcionales: Se definen como declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer (Sommerville, 2005, p.109).

Requerimientos no funcionales: Ian Sommerville los define como “restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares” (p.109).

Revisión por pares: Es una revisión de los procesos que efectúa un integrante del equipo por medio de otro integrante que tenga las mismas competencias (Expert Information SAS, 2016).

Riesgo: El PMBOK (2013) define el concepto de riesgo como “Un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo en uno o más de los objetivos de un proyecto” (p.562).

Sprints: Se define como el periodo de tiempo acotado de duración máxima de 4 semanas, durante el que se construye un incremento del producto. El incremento realizado durante el sprint debe estar terminado, esto es: completamente operativo y útil para el cliente, en condiciones de ser desplegado o distribuido (Scrum Manager, p. 26).

Stakeholders: El PMBOK (2013) define el concepto de stakeholder como “Un individuo, grupo u organización que puede afectar, verse afectado o percibirse a sí mismo como posible afectado por una decisión, actividad o resultado de un proyecto (p.550).

TeamSystem: Es una herramienta de desarrollo de software en colaboración que permite a un equipo interdisciplinar trabajar en conjunto de manera eficiente, integrar, liberar y controlar las versiones del código escrito, aun en proyectos de gran tamaño. Su IDE integrado permite trabajar en varios lenguajes diferentes, y también es compatible con diferentes editores de código (Microsoft, 2017).

WEMMOD: Es una metodología creada dentro de Expert Information SAS con el fin de realizar la estimación de esfuerzo en los proyectos (Expert Information SAS, 2016).

Resumen

El presente trabajo de grado forma parte de un macro proyecto que se está desarrollando actualmente en la empresa Expert Information SAS, el cual tiene como finalidad la obtención de la valoración CMMI DEV 1.3 nivel 5. En este documento se reporta todo lo concerniente al proceso de Rendimiento Organizacional, el cual es el primer proceso a implementar por la organización para la obtención de dicha valoración.

El CMMI DEV 1.3 es un modelo de evaluación de los procesos de una organización, el cual permite conocer la madurez y la capacidad de las empresas desarrolladoras de software. Este modelo describe los procesos que las empresas deben implementar para mejorar su calidad y rendimiento, sin embargo, no detalla la forma en que estas deben implementarlo, esto con el fin de que las empresas puedan lograr una adaptación al modelo en base a sus necesidades. Este modelo cuenta con veintidós procesos, dieciocho de los cuales ya han sido implementados por la organización anteriormente, dado que ya han sido validados en CMMI DEV 1.3 nivel 3.

El trabajo contiene la descripción de la propuesta de diseño para el proceso de Rendimiento Organizacional, esta propuesta es una adaptación de las métricas con las cuales debe contar la empresa según el CMMI DEV 1.3. Para el desarrollo de esta, se realizó un análisis de los procesos que actualmente desempeña la compañía y una evaluación de dónde es imprescindible y trascendental medir el rendimiento de estos. Donde se encontró que lo mejor era enfocar la propuesta en tres procesos específicos: requerimientos, diseño e implementación. Estos procesos fueron sometidos a un análisis por medio del cual se decidió qué indicadores era pertinente implementar y en qué partes específicas del proceso estos deberían ser implementados. Posteriormente, se realizó la documentación de los indicadores con toda la información necesaria para realizar la implementación de estos.

Palabras clave: CMMI, mejora continua, Rendimiento Organizacional.

Abstract

The present degree project is part of a macro project that is currently being developed in the enterprise Expert Information SAS, whose purpose is the obtaining of the valuation CMMI DEV 1.3 level 5. This document reports everything concerning the process Organizational Performance, which is the first process to be implemented by the organization in order to obtain this valuation.

The CMMI DEV 1.3 is an evaluation model of the processes of an organization, which allows to know the maturity and the capacity of the companies developing software. This model describes the processes that companies must implement to improve their quality and performance, however, it does not detail how they should implement it, so that companies can achieve an adaptation to the model based on their needs. This model has twenty-two processes, eighteen of which have already been implemented by the organization previously, since they have already been validated in CMMI DEV 1.3 level 3.

The work contains the description of the design proposal for the Organizational Performance process, this proposal is an adaptation of the metrics with which the company must count according to the CMMI. For the development of this, an analysis of the processes currently performed by the company and an evaluation of where it is essential and transcendental to measure the performance of the processes was made. Where it was found that it was best to focus the proposal on three specific processes: requirements, design and implementation. These processes were subjected to an analysis whereby it was decided which indicators were relevant to implement and in which specific parts of the process they should be implemented. Subsequently, the documentation of the indicators was made with all the necessary information to carry out the implementation of these indicators.

Key words: CMMI, continuous improvement, Organizational Performance.

1

1. Introducción

En los últimos años la industria del desarrollo de software en Colombia ha crecido exponencialmente, gracias a la necesidad que ha surgido en los diferentes sectores industriales, comerciales, económicos, entre otros, por utilizar nuevas tecnologías que les permitan facilitar, agilizar y garantizar la calidad de su información. A raíz de la expansión de este sector, nació la necesidad en las empresas desarrolladoras de software colombianas por mejorar la calidad de sus procesos, de tal forma que estas pudiesen expandir su mercado sin afectar la calidad de sus productos.

Dentro de esta industria existen algunos modelos que les permiten a las empresas desarrolladoras medir su calidad, eficiencia y madurez de sus procesos, uno de estos modelos es el CMMI DEV 1.3. Según el Instituto de Desarrollo de Software este modelo establece una guía de las actividades que se deben desarrollar para obtener una alta calidad y rendimiento en los procesos para la creación de software (Instituto de Desarrollo de Software, 2010).

A raíz de los beneficios que otorga el CMMI, la empresa Expert Information SAS, la cual es una compañía perteneciente al sector del desarrollo de software y cuenta con 12 años de experiencia en este mercado, hace aproximadamente 2 años, decidió validarse en el modelo CMMI DEV 1.3 y en agosto del año 2015 obtuvieron un nivel de madurez 3 en esta valoración. Actualmente, la empresa está trabajando por alcanzar el nivel de madurez 5 del mismo modelo, por lo cual en este trabajo de grado se desarrollará el primer proceso del nivel de madurez 4, el cual recibe el nombre de Rendimiento Organizacional. Este es el primer proceso a abordar para obtener la valoración CMMI DEV 1.3 nivel 5, que es la valoración más alta en dicho modelo.

En el presente documento se encuentra la propuesta de diseño del proceso de Rendimiento Organizacional, en la empresa Expert Information SAS, la cual se desarrolló mediante un análisis preliminar, una caracterización de los procesos y finalmente el establecimiento de indicadores y métricas.

2

2. Planteamiento del problema de investigación

En Colombia en los últimos años la industria de desarrollo de software se ha expandido y las empresas se han enfrentado a un entorno más competitivo, razón por la cual las empresas han visto la necesidad de capacitarse en procesos de mejor calidad y rendimiento, los cuales les permitan minimizar las perdidas, aprovechar mejor sus recursos y maximizar las ganancias.

Expert Information S.A.S es una empresa perteneciente al sector de desarrollo de software hace 12 años, la cual ha desarrollado sus procesos en base a las experiencias que han adquirido en el desarrollo de proyectos y al conocimiento que sus gerentes poseen en dirección y prestación de servicios. Adicionalmente, la compañía se ha enfrentado a un crecimiento que no fue previsto inicialmente, por esta razón ha tenido problemas de calidad en sus procesos, los cuales han repercutido en tiempos tardíos de entrega, pérdidas de dinero, reprocesos, pérdida de imagen y por consiguiente pérdida de competitividad y de clientes.

Hace aproximadamente 2 años la empresa Expert tomó la decisión de enmarcar sus procesos dentro de un modelo que respaldara la calidad y eficiencia de sus servicios, de ahí que empezaran el proceso para obtener la validación CMMI DEV 1.3, y en agosto del año 2015 la empresa obtuvo la validación de nivel de madurez 3 de los 5 propuestos por el CMMI; sin embargo, existen aún dificultades con la baja eficiencia de los procesos organizacionales, estas deficiencias se dan a raíz de la falta de madurez en los procesos que desarrollan; es por ello que se decidió plantear como pregunta de investigación: ¿Cómo establecer el Rendimiento Organizacional de la empresa Expert Information S.A.S a partir del modelo CMMI DEV 1.3 para el nivel de madurez 4?

3

3. Objetivos

Los objetivos general y específicos dentro de los cuales se enmarcó este estudio son:

3.1 Objetivo General

Proponer el diseño del proceso Rendimiento Organizacional dirigido a satisfacer las metas genéricas y específicas planteados por el modelo CMMI DEV 1.3 para el nivel 4 en la empresa Expert Information S.A.S.

3.2 Objetivos específicos

Realizar un análisis preliminar que permita comparar los procesos actuales de la compañía contra el proceso de Rendimiento Organizacional del modelo CMMI DEV 1.3 nivel 4.

Caracterizar y definir los procesos organizacionales, que sean susceptibles de estandarización y mantenimiento según el proceso de Rendimiento Organizacional del modelo CMMI DEV 1.3 nivel 4.

Definir indicadores de rendimiento para los diferentes procesos de la organización con base en el proceso de Rendimiento Organizacional del modelo CMMI DEV 1.3 nivel 4.

4

4. Justificación

Expert Information S.A.S es una compañía que ofrece servicios de desarrollo de software y consultoría en Ingeniería de software. Se especializa en el análisis, diseño, construcción e implantación de soluciones informáticas construidas a la medida de las necesidades de sus clientes en diversos sectores comerciales (Expert Information SAS, 2016).

La empresa inicialmente se valoró en el modelo CMMI DEV 1.3 nivel 3 cumpliendo con todas las metas genéricas y objetivos específicos determinados para dicho nivel, obteniendo resultados óptimos que cumplieron todas las expectativas que se tenían, por lo cual decidieron valorarse hasta el nivel 5 en este mismo modelo.

Según MINTIC1 en Colombia solo 12 empresas presentan madurez nivel 5 en el modelo CMMI (MINTIC, 2015), por lo cual la empresa alcanzando este nivel de madurez podrá ser más productiva, disminuirá los reprocesos, los tiempos de desarrollo y será un punto de referencia en la industria (Software Engineering Institute, 2010).

El proyecto de grado se enfocó en un proceso específico del nivel 4, el cual hace referencia al rendimiento organizacional de la compañía; por medio de la definición y diseño de este proceso se espera repercutir en la mejora de la planeación, rendimiento, calidad en los procesos de desarrollo de software, a la vez que le puede permitir a la empresa captar más clientes, aumentar sus ingresos y emplear a más personas en la realización de sus proyectos.

1 Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia.

5

5. Alcance

El proyecto comprende la definición y diseño del proceso de Rendimiento Organizacional para la empresa Expert Information S.A.S con base en el modelo CMMI DEV 1.3 nivel 4.

Para la definición y diseño de este proceso se realizó un análisis preliminar que permitió comparar los procesos actuales de la compañía contra el proceso de Rendimiento Organizacional del modelo CMMI DEV 1.3 nivel 4; se caracterizaron y definieron los procesos organizacionales susceptibles de estandarización y mantenimiento y posteriormente se definieron indicadores que permiten medir el estado de las variables que conforman dicho proceso.

En este proyecto no se implementó la propuesta de diseño para el proceso de Rendimiento Organizacional dentro de la empresa Expert Information S.A.S. La implementación de este, será responsabilidad de los directivos de la empresa.

Como resultado del proyecto se entregó un informe a la empresa, el cual contenía:

− Documentación de los hallazgos encontrados en la revisión de los procesos actuales de la compañía contra los procesos propuestos por el modelo CMMI DEV 1.3.

− Documentación de la definición y el diseño de los procesos que debe implementar la compañía para obtener la calidad y estándar del proceso de Rendimiento Organizacional propuesto por el modelo CMMI DEV 1.3 nivel 4.

− Documentación de los indicadores de rendimiento para los procesos organizacionales con sus respectivas métricas y valores de tolerancia.

6

6. Marco referencial

En esta sección se realizó una recopilación de conceptos, teorías, definiciones y antecedentes relacionados directa o indirectamente con la temática, lo cual permitió definir una base teórica sobre la cual se desarrolló el proyecto de grado.

6.1 Marco teórico

A continuación, se describe el modelo CMMI, con un énfasis especial en el nivel de madurez 4, dado que es en el cual se desarrolló la propuesta del proceso de Rendimiento Organizacional.

CMMI

El CMM es un modelo creado por el Instituto de Desarrollo de Software (SEI) de la universidad de Carnegie Mellon, en el año 1995. Este diseño se creó con la finalidad de mejorar la calidad, la madurez y la eficiencia de los procesos que se desarrollaban en las organizaciones. Sin embargo, el SEI descubrió que con la aplicación de diversos CMMs enfocados en diferentes procesos de la organización no se obtenían los resultados esperados, puesto que estos diseños no estaban siendo vinculados unos con otros en su aplicación (Software Engineering Institute, 2010).

En el año 2000, el Instituto de Desarrollo de Software de la universidad de Carnegie Mellon reestructuró los modelos de CMMs creando así el modelo CMMI, el cual integró los diferentes modelos CMMs y permitió alcanzar los resultados de mejora inicialmente previstos. Dos años más tarde se publicó la versión CMMI 1.1 y cuatro años después la versión CMMI 1.2 para el desarrollo. Actualmente, existen tres modelos de CMMI (Software Engineering Institute, 2010).

6.1.1.1 CMMI DEV 1.3 para desarrollo

Es un modelo de referencia propuesto por el CMMI dirigido a las empresas desarrolladoras de software, este modelo incluye una guía de las áreas de proceso y los procesos con los cuales las empresas deben de contar para prestar un servicio a tiempo y con alta calidad. El modelo CMMI cuenta con veintidós procesos clasificados dentro de cinco áreas, y la implementación de estos se puede realizar desde dos representaciones o enfoques: la representación por etapas o la representación continua.

La representación por etapas está asociada con los niveles de madurez los cuales permiten a las empresas mejorar grupos de procesos relacionados, abordando de forma secuencial las áreas de proceso. La representación continua está asociada con los niveles de capacidad los cuales permiten mejorar de forma incremental los procesos pertenecientes a una o varias áreas de proceso. Ver Anexo 1.

7

El modelo CMMI permite encontrar las debilidades que las diferentes empresas desarrolladoras de software presentan. Sin embargo, el cómo convertir esas debilidades en fortalezas queda a criterio y decisión de las empresas.

6.1.1.2 Nivel de capacidad

Los niveles de capacidad son la base para realizar la mejora de los procesos individuales en las organizaciones para un área o grupo de áreas determinadas. Los niveles de capacidad se numeran de 0 a 3, donde 0 representa un nivel incompleto, 1 un nivel realizado, 2 un nivel gestionado y 3 un nivel definido. Para alcanzar cada nivel se deben cumplir las metas genéricas (metas que aplican a diversas áreas de proceso) que tiene cada uno de estos.

Nivel de capacidad 0 - Incompleto: Es un proceso que no se ejecuta o no realiza en su totalidad.

Nivel de capacidad 1 - Realizado: Es un proceso en el cual se realizan todos los procedimientos necesarios para alcanzar las metas específicas de un proceso.

Nivel de capacidad 2 - Gestionado: Es un proceso que se ejecuta de acuerdo a una planificación basada en políticas empresariales y se obtienen resultados controlados

Nivel de capacidad 3 – Definido: Es un proceso adaptado a partir de los estándares y guías de la organización, describe detalladamente las entradas, herramientas, técnicas y salidas del proceso.

6.1.1.3 Nivel de madurez

Cada nivel de madurez cuenta con unas prácticas específicas y genéricas definidas previamente, las cuales hacen referencia a un área de proceso, teniendo como objetivo la mejora continua de la calidad en los procesos y la culminación de las metas genéricas y específicas propuestas para cada proceso, logrando de esta manera caracterizar el rendimiento de la organización.

Cada uno de estos niveles de madurez cuenta con unas actividades las cuales se encargan de guiar el camino que debe llevar la organización para lograr la mejora de sus procesos. Si la organización logra cumplir todas las metas tanto genéricas como específicas de cada proceso en cada nivel, esta logrará obtener la valoración CMMI para el nivel al cual aplique.

Nivel de madurez 1: Inicial

Los procesos son desordenados y caóticos. La organización no presenta un entorno idóneo para el desarrollo de este nivel, por lo cual logra producir sus productos de trabajo, pero la fabricación de estos excede los costos de producción y los tiempos de entrega, por lo cual no se respeta el calendario de proyectos ni el presupuesto establecido. Conforme a esto se obtienen procesos de menor calidad y alto riesgo, generando pérdidas e incertidumbre para la

8

organización. Cuando se está en nivel 1 predomina en las organizaciones el deseo de desistir de la realización de ciertos procesos en el momento en que se encuentran en un entorno desfavorable.

Nivel de madurez 2: Administrado

El nivel 2 brinda las pautas básicas para la gestión de proyectos, de esta manera la organización logra cumplir todas las metas genéricas y específicas del área de proceso, logrando una adecuada administración de requisitos, una planificación del proyecto acorde a las metas propuestas, un programa de monitoreo y control, la gestión de acuerdo al proveedor, los procesos para llevar a cabo el producto y la garantía de calidad de este. La conducta que se maneja en este nivel propende a garantizar la mejora en los procesos a largo plazo, logrando estandarizarlos de manera clara.

Nivel de madurez 3: Definida

El nivel 3 se caracteriza por cumplir todas las metas y objetivos genéricos y específicos de las áreas de los procesos 2 y 3. En este nivel se especifican de manera detallada los procesos que se deben realizar continuamente en la organización, los cuales se gestionan desde una perspectiva más analítica y lógica, logrando comprender la relación entre los procesos y el producto final que desarrolla la organización. De esta manera se integra toda la red de procesos para este nivel.

Los procesos tienen que ser definidos adecuadamente y comprendidos por toda la organización mediante la estandarización, procedimientos, herramientas y métodos, obteniendo como resultado final una calidad y un riesgo medio.

Algunas de las áreas de proceso dentro de este nivel son: desarrollo de requisitos, solución técnica, integración de productos, verificación, validación, enfoque del proceso organizacional, definición del proceso organizacional, capacitación en materia de organización, gestión integrada de proyectos (IPPD extras), gestión de riesgos, análisis de decisión y resolución, entre otros.

Nivel de madurez 4: Administrado cuantitativamente

Para llegar al nivel 4 se deben de alcanzar previamente las metas genéricas y objetivos específicos asignados a los niveles 2, 3 y 4. En el nivel 4 se logra identificar unos sub-procesos los cuales pertenecen a los procesos más significativos de la empresa favoreciendo el rendimiento del proceso general, estos se controlan bajo técnicas estadísticas y análisis de datos, entre otras herramientas cuantitativas.

Los objetivos cuantitativos en este nivel tienen como meta desarrollar métodos que tengan en cuenta las necesidades del cliente y a la organización responsable de los procesos, esto con el fin de mejorar la calidad y el rendimiento de cada proceso que conlleve al resultado final.

9

Para estos sub-procesos se recogen datos y se analizan estadísticamente las causas de la variación entre los procesos, identificando los posibles problemas y previniéndolos en un futuro.

El rendimiento en este nivel es previsible cuantitativamente ya que como se mencionó anteriormente, los procesos de este son controlados estadísticamente por la organización, por lo tanto, se pueden corregir las fallas de los procesos anteriores para prevenir las próximas. A pesar de que en este nivel los procesos generan resultados previsibles, estos resultados en ocasiones no son capaces de alcanzar los objetivos establecidos.

Nivel de madurez 5: Optimizado

En este nivel la organización ha alcanzado todas las metas específicas del proceso a zonas asignadas a los niveles de madurez anteriores, los objetivos genéricos asignados a los niveles 2 y 3, las metas y objetivos de los niveles anteriores.

Para comprender la variación en el proceso y determinar las posibles causas de los resultados, la organización debe tener una dirección cuantitativa del proceso, es decir mediante el análisis de datos se debe medir y evaluar los procesos definidos y la integración de estos ya estandarizados, mediante la implementación de mejoras tecnológicas para seguir con el progreso continuo, el aumento de calidad y el rendimiento de los procesos.

Por lo tanto, el objetivo principal del nivel cinco es la mejora continua del rendimiento y la calidad de los procesos, utilizando herramientas tecnológicas y modificando los objetivos progresivamente para obtener resultados significativos que perduren en la organización. En este nivel, los procesos se encargan del cambio por medio del rendimiento de los procesos para desarrollar un producto, manteniendo al mismo tiempo estadísticas para anticiparse a los malos resultados y con esto alcanzar los objetivos cuantitativos de mejora de procesos.

Gerencia de proyectos

Según el PMI (Project Management Institute) un proyecto es un esfuerzo de carácter temporal llevado a cabo con objeto de crear un producto o servicio único (PMBOK 2000). La gerencia de proyectos se enfoca en la organización y administración de recursos, mediante la aplicación de conceptos, técnicas y herramientas, las cuales son utilizadas para llevar a cabo un proyecto, obteniendo resultados óptimos, con excelente calidad y rendimiento (Project Management Institute, 2013).

La gerencia de proyectos tiene una amplia gama de aplicaciones en las empresas de desarrollo de software, dado que la planificación de cada proyecto abarca la monitorización y control de cada uno de estos, generando de esta manera metodologías para el desarrollo de un proyecto (PMBOK 2000).

En el modelo CMMI existen siete áreas de proceso de gestión de proyectos:

Gestión Integrada del Proyecto (IPM).

10

Monitorización y Control del Proyecto (PMC). Planificación del Proyecto (PP). Gestión Cuantitativa del Proyecto (QPM). Gestión de Requisitos (REQM). Gestión de Riesgos (RSKM). Gestión de Acuerdos con Proveedores (SAM).

Para obtener la valoración de CMMI del nivel al que se desea aplicar es necesario indagar en ciertas áreas de proceso básicas en la gestión de proyectos, las cuales buscan establecer el progreso frente al plan que se va desarrollar, además de la gestión con los proveedores y las correctivas que se deben realizar para alcanzar la valoración.

Ciclos de vida del software

Los modelos de ciclos de vida del desarrollo de software suministran a los ingenieros una guía en forma de fases o actividades secuenciales por las cuales un producto debe transitar para llegar a su resultado final. Los modelos de ciclos de vida permiten crear un marco para el desarrollo, administración, monitoreo y control de los proyectos de desarrollo de software a la vez que permiten realizar una pronta detección de errores, de tal forma que los desarrolladores pueden enfocarse en la calidad del producto (Pressman, 2011).

Existen diferentes modelos de ciclos de vida, destinados para diferentes actividades y procesos del desarrollo de software. Actualmente existen ciclos de vida que proponen un desarrollo de software más rápido por medio de un conjunto de metodologías agiles que permiten generar prototipos rápidos, entre los más reconocidos están la programación eXtrema y el SCRUM.

6.1.3.1 Metodologías agiles

En la actualidad el concepto de metodologías agiles ha tenido un auge muy importante sobre la gestión de proyectos, ya que estas favorecen el desarrollo y rendimiento de los procesos dentro de una organización. El enfoque principal de las metodologías ágiles es la capacidad organizacional para responder ante un problema y adaptarse rápidamente al cambio, esto por encima de la planificación de una serie de procesos y actividades. Las metodologías agiles proveen a la empresa la capacidad de adaptarse al cambio rápidamente, disminuir los errores, reducir los costos por correcciones y alcanzar un desarrollo adecuado y exitoso de los proyectos que realiza (Beck et al., 2001).

Scrum

Scrum es un método interactivo de desarrollo ágil el cual se enfoca en adoptar estrategias y valores de gerencia de proyectos. Este se basa en la calidad del resultado final en conocimientos tácticos de los integrantes del equipo en vez de la planificación y la realización

11

consumada del producto. El scrum proporciona herramientas y roles que facilitan ver el progreso y los resultados de los proyectos (Palacio, 2014).

Para desarrollar un proyecto utilizando la metodología del scrum en la mayoría de las veces se empieza utilizando el Product Backlog, el cual le permite a la organización identificar todos los requerimientos funcionales y no funcionales que deberá cumplir al momento de construir el sistema. Posteriormente a esto se definirán las iteraciones o Sprint en las cuales se evolucionará la aplicación del Scrum.

6.2 Antecedentes

En esta sección se describen los antecedentes teóricos, metodológicos y experimentales que otros investigadores han utilizado para fundamentar y desarrollar un planteamiento del problema similar al abordado en este proyecto de grado.

Sanz (2009) analizó la viabilidad de la implementación del modelo CMMI DEV 1.2 nivel 2 en una empresa desarrolladora de software por medio de la implementación de algunos procesos propuestos por este modelo. El autor inició realizando un reconocimiento del estado inicial de la empresa respecto a las normas de CMMI DEV 1.2, a partir de los resultados obtenidos definió los procesos que se debían de implementar y posteriormente implemento algunos de estos, con el fin de medir la viabilidad económica y temporal de las mejoras. El autor concluyó que el modelo CMMI DEV 1.2 es una forma progresiva de desarrollar la madurez de la organización nivel a nivel, sin embargo, los procesos a realizar para alcanzar esta validación son muy costosos e implican una gran inversión de tiempo.

De la misma forma, Paolini (2013) diseñó e implementó un proceso de gestión de riesgos en McAfee, orientado a satisfacer la meta genérica y las prácticas específicas para el área de proceso de gestión de riesgos del nivel de capacidad 2 adoptando prácticas ágiles. La metodología a seguir fue el análisis de las prácticas genéricas del nivel de capacidad 2 de CMMI DEV 1.3, después se definieron las prácticas ágiles y métodos alternativos a utilizar. Finalmente, se analizaron los resultados de la aplicación de estas prácticas y se encontró que no se logró la estandarización de los procesos de gestión de riesgos en las áreas de proceso donde se mejoró la calidad.

Equiparablemente, Díaz (2013) realizó la adaptación de los procesos correspondientes a los niveles 2 y 3 del modelo CMMI DEV 1.3 en la empresa MOSKitt4ME con la finalidad de obtener procesos definidos y caracterizados. Para la implementación de los niveles 2 y 3 se realizó inicialmente una valoración de la situación actual de la empresa, después se definió la adaptación de los procesos a la organización, se realizó la documentación de las mejoras, se socializó el plan con los involucrados y se capacitaron en los nuevos procesos. Finalmente, el autor concluyó que es pertinente crear una gestión del cambio para tener un control sobre las modificaciones futuras que se puedan realizar en la organización.

12

Al mismo tiempo, Yepéz et al. (2013) realizaron un diagnóstico para describir la situación actual del proceso de planificación de proyectos en el desarrollo de software de la organización objeto de estudio, considerando como guía las prácticas estipuladas por el CMMI DEV 1.3. Con los resultados obtenidos se elaboró un plan de mejoras específico para la EDS en estudio con acciones para atender las debilidades observadas en el proceso de planificación de proyectos. En los resultados correspondientes a las prácticas de planificación de proyectos definidos por el modelo CMMI DEV 1.3 se evidenció que el 83% de los ítems evaluados no se cumplieron; un 12% fueron parcialmente cumplidos, mientras que sólo el 5% restante se cumplieron, correspondiendo estás últimas a actividades indispensables para llevar a cabo cada proyecto.

Por su parte, Sánchez (2014) realizó una investigación en la cual elaboró una metodología para el desarrollo de software de gestión, integrando las prácticas ágiles y el modelo CMMI DEV 1.3. Para lograr el objetivo planteado el autor realizó cuatro pasos los cuales consistieron en: elaborar un marco teórico, definir un modelo de desarrollo de software de gestión, definir actividades que conformasen una metodología de desarrollo de software y validar la metodología propuesta a través de los resultados. Al aplicar la metodología desarrollada en seis proyectos reales se concluyó que la investigación favoreció al control en los proyectos y agilizó la documentación y el tratamiento oportuno de información.

Recientemente, Gallardo (2016) realizó la definición de los procesos de planificación del proyecto, gestión de riesgo, análisis de decisión y resolución para la valoración CMMI DEV 1.3 en la empresa Expert SAS. El desarrollo del problema se basó en cinco etapas, inicialmente se realizó una sensibilización organizacional alrededor de los cambios que se iban a generar, después de realizó el diagnóstico inicial de la empresa, se realizó toda la documentación requerida, se socializaron los cambios y se capacitó el personal para preservar los cambios generados. Con este estudio, se concluyó que la clave para las implementaciones del modelo CMMI es realizar una adecuada adaptación del modelo en base a las características especiales de la empresa.

13

7. Realización de un análisis preliminar que permite comparar los procesos actuales de la compañía contra el proceso de Rendimiento Organizacional del modelo CMMI DEV

1.3 nivel 4

En esta sección se realiza la descripción de todas las actividades concernientes al desarrollo del primer objetivo específico.

7.1 Revisión de los procesos documentados por la compañía

Se realizó la revisión de los procesos documentados por la compañía Expert Information SAS hasta el momento. Donde se encontró que la organización desarrolla seis grandes fases, las cuales están compuestas de diversos procesos. Estos serán explicados en la sección 7.3.

7.2 Revisión documental de las auditorias de cumplimiento de procesos

Se realizó la inspección de las auditorias de cumplimiento de procesos de la empresa y se encontró que hasta el momento la empresa no ha realizado ninguna auditoría. Las únicas auditorías que se han realizado fueron antes de la valoración CMMI DEV 1.3 nivel 3.

7.3 Documentación de los hallazgos encontrados en la revisión de los procesos actuales de la compañía

En esta sección se realiza la descripción de la documentación existente de los procesos que actualmente desarrolla la empresa Expert Information SAS. Para ello, se utilizaron diagramas de flujo y diagramas cruzados, los cuales están acompañados de la definición de cada proceso y subproceso.

Diagrama de flujo genérico

A continuación, se ilustra el diagrama de flujo genérico del proceso de desarrollo de software de la compañía. Además, se realiza la descripción de las seis fases que lo conforman. Ver Anexo 2.

7.3.1.1 Fase de pre-análisis

En esta fase la compañía entabla un dialogo con el cliente, por medio del cual se realiza una primera toma de las necesidades de este. Después, dichas necesidades son transformadas en características técnicas, las cuales son evaluadas cuantitativamente, y a partir de las cuales, se obtiene la estimación del tiempo que le tomaría a la empresa desarrollar el proyecto y el costo que este tendría para el cliente. En esta fase, también se define el equipo de trabajo que desarrollará el proyecto y se realiza la planeación de actividades cortas o próximas a la fecha de inicio de este (Expert Information SAS, 2016).

14

7.3.1.2 Fase de planeación

En esta fase la compañía define el plan de aseguramiento de la calidad, mediante el cual se realiza la definición del cronograma de trabajo, se eligen los formatos que se utilizaran para documentar el desarrollo del proyecto y se establecen las fechas en las cuales se realizaran los controles de calidad. También se realiza un plan de administración de la configuración, este plan es particular de las empresas desarrolladoras de software, dado que define como se van a unificar las versiones o partes creadas por cada desarrollador. Así mismo, se realiza un plan de análisis de riesgos, mediante el cual se definen los riesgos a los cuales esta o podría estar expuesto el proyecto y las acciones que se deberán tomar si en algún momento los riesgos se materializan.

También se realiza una inspección por recorrido, mediante la cual un tercero revisa el desarrollo del proyecto. Igualmente, se realiza la planeación del desarrollo de software mediante la cual se definen los módulos del proyecto, el orden en el que serán desarrollados y que personas se encargarán de desarrollarlos. Simultáneamente a todos los planes mencionados anteriormente, se realiza el plan de análisis de decisiones y resolución, por medio del cual se definen los aspectos técnicos del desarrollo del proyecto (Expert Information SAS, 2016).

7.3.1.3 Fase de requerimientos

En esta fase se realiza la toma de requerimientos formal, mediante la cual se indaga exhaustivamente por las necesidades específicas del cliente, de tal forma que se detalle exactamente lo que el cliente desea obtener en cada requerimiento (Expert Information SAS, 2016).

7.3.1.4 Fase de diseño

En esta fase se realiza el diseño del sistema que el cliente desea obtener, para ello se realiza el diseño o el modelo de bases de datos, tablas, gráficos, entre otros. Estos diseños, son posteriormente entregados a un grupo de desarrolladores los cuales se encargarán de realizar la programación (Expert Information SAS, 2016).

7.3.1.5 Fase de implementación

En esta fase se realiza el desarrollo del proyecto en lo concerniente a la programación, esta fase es realizada por los desarrolladores (Expert Information SAS, 2016).

7.3.1.6 Fase de implantación

En esta fase se realizan una serie de pruebas al programa realizado en la fase de implementación, estas pruebas son realizadas por los desarrolladores y por el cliente, de tal forma que se evalué si el programa cumple satisfactoriamente con todos los requerimientos presentados. De lo contrario, se realiza la corrección y se prueba nuevamente que el programa

15

funcione correctamente. Finalmente, al culminar las pruebas y las correcciones se realiza el cierre del proyecto (Expert Information SAS, 2016).

Roles

En esta sección se realiza la descripción de los roles definidos actualmente por la compañía y las funciones y responsabilidades que estos tienen en el proceso de desarrollo de software. En el Anexo 3 se puede observar el organigrama de la compañía.

7.3.2.1 Administrador de la configuración

Es la persona encargada de identificar, relacionar, almacenar, y trabajar con los productos de trabajo. Entendiendo por productos de trabajo todo lo que se genera en el ciclo del desarrollo de software (Expert Information SAS, 2016).

7.3.2.2 Analista de calidad

Es la persona encargada de realizar el control de calidad a las entregas (Expert Information SAS, 2016).

7.3.2.3 Analista funcional

Es equivalente a un ingeniero de procesos, el cual se encarga de realizar el levantamiento de la información de los requerimientos y especificaciones de software de los clientes (Expert Information SAS, 2016).

7.3.2.4 Arquitecto de software

Es la persona encargada de desarrollar los requerimientos técnicos del software, así como su diseño y construcción, además de realizar las pruebas de calidad y liberación el producto final (Expert Information SAS, 2016).

7.3.2.5 Cliente

Es la persona o las personas que solicitan el servicio de desarrollo de un producto a la compañía (Expert Information SAS, 2016).

7.3.2.6 Comité de control de cambios (CCB)

Es el grupo de personas encargadas de realizar la evaluación de los cambios propuestos a los elementos de configuración, además deciden si los cambios son aprobados o rechazados. Si los cambios son aprobados, estos se aseguran de que estos sean implementados (Expert Information SAS, 2016).

16

7.3.2.7 Desarrollador

Son las personas responsables de crear el código del producto con la finalidad de materializarlo según los requerimientos del cliente (Expert Information SAS, 2016).

7.3.2.8 Documentador técnico

Es el encargado de generar todos los manuales, tanto de usuario como de administración de cada uno de los sistemas de información desarrollados (Expert Information SAS, 2016).

7.3.2.9 Equipo de desarrollo

Este equipo es el encargado de desarrollar todas las actividades concernientes a la creación del código que permite materializar el producto. Este equipo está conformado por los roles de líder de desarrollo y desarrolladores (Expert Information SAS, 2016).

7.3.2.10 Equipo de diseño

Este equipo es el encargado de desarrollar todas las actividades concernientes al diseño del producto. Está conformado por los roles de arquitecto de software, líder de desarrollo y desarrolladores asignados (Expert Information SAS, 2016).

7.3.2.11 Equipo de estimación

Este equipo es el encargado de realizar todas las actividades concernientes a la estimación de un proyecto de desarrollo de software. Está conformado principalmente por los roles de gerente del proyecto, líder de desarrollo y líder funcional (Expert Information SAS, 2016).

7.3.2.12 Equipo de pruebas

Este equipo es el encargado de desarrollar y aplicar todas las pruebas que permiten constatar si el producto o componente cumple con los requisitos mínimos de calidad. Está conformado por los roles de líder de calidad y analistas de calidad (Expert Information SAS, 2016).

7.3.2.13 Equipo de requerimientos

Este equipo es el encargado de realizar todas las actividades concernientes a la toma de requerimientos. Está conformado por los roles de líder funcional y analistas funcionales (Expert Information SAS, 2016).

7.3.2.14 Equipo pre-análisis

Este equipo es el encargado de realizar todas las actividades relacionadas con la fase de pre-análisis. Está conformado principalmente por los roles de gerente comercial y el auxiliar administrativo, entre otros que participan en su desarrollo (Expert Information SAS, 2016).

17

7.3.2.15 Estimador

Es el rol encargado de realizar la estimación del valor que le costaría al cliente desarrollar su producto con los requerimientos dados por este (Expert Information SAS, 2016).

7.3.2.16 Gerente comercial

Es la persona encargada de realizar la planificación de las actividades desarrolladas por el equipo comercial, así como liderar al mismo y supervisar que este cumpla con las actividades planteadas (Expert Information SAS, 2016).

7.3.2.17 Gerente del proyecto

Es la persona responsable de un proyecto dado y del producto creado en este. De tal forma, que debe realizar la planeación y supervisar el desarrollo del proyecto y a los empleados involucrados en este (Expert Information SAS, 2016).

7.3.2.18 Gerente desarrollo

Es el equivalente a un jefe de producción de una compañía de cualquier sector. Es el encargado de gestionar toda la planta de desarrollo, calidad y análisis dentro del ciclo de vida del desarrollo de software (Expert Information SAS, 2016).

7.3.2.19 Inspector

El rol del inspector desarrolla las revisiones del producto, la persona que está a cargo de este rol debe ser diferente a la persona que desarrolla el rol del productor. Es importante resaltar, que para las inspecciones se debe contar con mínimo dos inspectores (Expert Information SAS, 2016).

7.3.2.20 Líder de calidad

Es la persona encargada de analizar si las actividades de control de calidad son suficientes para cumplir con los requerimientos del producto, además, debe supervisar si el control de calidad se realiza de forma adecuada y en los tiempos planteados por el cronograma (Expert Information SAS, 2016).

7.3.2.21 Líder de desarrollo

Es la persona encargada de liderar al equipo de desarrollo, y vigilar que se cumplan las tareas planteadas dentro de la planeación del proyecto (Expert Information SAS, 2016).

7.3.2.22 Líder funcional

Es similar al analista funcional, pero tiene más conocimiento y una visión global sobre los procesos que se van a sistematizar en un cliente dado (Expert Information SAS, 2016).

18

7.3.2.23 Productor

Este rol representa a la persona que ha realizado un producto, el cual puede ser un documento o código (Expert Information SAS, 2016).

Procesos transversales

A continuación, se realizará la descripción de los procesos que son transversales a las fases del proceso de desarrollo de software de la organización Expert Information SAS.

7.3.3.1 Inspección por recorrido

Este proceso tiene el objetivo de ayudarle al equipo de trabajo en la creación de productos de alta calidad y la identificación de productos de baja calidad para realizar correcciones o el redesarrollo de estos. El proceso es desarrollado por los inspectores y el productor; los cuales para la realización de las inspecciones utilizan un sistema implementado anteriormente, este se conoce como ICEBERG (Expert Information SAS, 2016).

En el Anexo 4, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de inspección por recorrido se encuentran cinco subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

Preparación de la inspección

En este proceso el productor prepara la documentación del producto, y especifica los puntos en los que el inspector debe centrar su atención, en caso de requerirlo. Así mismo, el inspector se encarga de tener a disposición los elementos requeridos para la inspección al momento de la misma (sala, proyector, etc.) (Expert Information SAS, 2016).

Recorrido del producto

En este proceso se selecciona al controlador de tiempo y secretario. El productor explica cada sección del producto, indicando los puntos de especial atención a los inspectores. Luego, los inspectores describen los defectos encontrados en cada sección, revisan el Checklist del producto y plantean sus preguntas. El productor finalmente responde a las dudas de los inspectores y se registran los defectos encontrados en el sistema ICEBERG. Cabe destacar que, si alguno de los inspectores no se encuentra preparado, se debe reprogramar la junta (Expert Information SAS, 2016).

Conclusión

En este paso, los inspectores deciden como se deben verificar las correcciones a los defectos encontrados y completar el formulario de inspección en el sistema ICEBERG, además de registrar los tiempos en el formato de inspección (Expert Information SAS, 2016).

19

Corrección

El productor hace las correcciones y actualiza la documentación y el código. Posteriormente, este realiza las re-revisiones y re-inspecciones necesarias, y verifica las correcciones hechas por los inspectores en la conclusión (Expert Information SAS, 2016).

Aprobación del producto

El productor entrega a los inspectores el producto corregido y estos hacen la aprobación (Expert Information SAS, 2016).

7.3.3.2 Monitoreo del proyecto

Este proceso tiene como finalidad la planeación y conducción adecuada del monitoreo del proyecto. Los roles responsables de llevar a cabo este proceso son el gerente del proyecto y el equipo asignado. Para la realización de este proceso se utiliza una matriz de métricas definida previamente por la empresa (Expert Information SAS, 2016).

En el Anexo 5, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de monitoreo del proyecto se encuentran cinco subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

Revisión de acciones correctivas

Semanalmente el gerente del proyecto inspecciona la aplicación de las acciones correctivas planeadas y la efectividad de estas con respecto al problema identificado. Posteriormente se actualiza el resumen de acciones correctivas del proyecto (Expert Information SAS, 2016).

Monitoreo del proyecto

Diariamente el gerente del proyecto por medio de una reunión informal realiza seguimiento al avance de las actividades diarias de cada recurso asignado al proyecto y semanalmente revisa el estado del avance del cronograma del proyecto, del plan de administración de la configuración; del plan de aseguramiento de la calidad; de las adaptaciones al proceso estándar; del plan de soporte; del plan de conocimientos y habilidades; del plan de administración de riesgos; del plan de análisis formal de decisiones; de la lista de productos comprados o subcontratados; de la administración de la información del proyecto; la participación de involucrados de acuerdo a lo planeado; y de los compromisos con involucrados relevantes (Expert Information SAS, 2016).

20

Definición de acciones correctivas

El gerente del proyecto define y registra las acciones correctivas con respecto a desviaciones significativas en los planes del proyecto, tales como: negociaciones requeridas de compromisos con involucrados relevantes y proyectos relacionados, incluyendo compromisos de interfaces de terceros o para terceros, diferencias entre recursos planeados y recursos disponibles, desempeño de los miembros del equipo con respecto a sus expectativas, entre otros problemas significativos identificados (Expert Information SAS, 2016).

Reporte de estatus

El gerente del proyecto envía por correo electrónico el resultado de las métricas a los interesados registrados en la matriz de métricas; con la información obtenida de las métricas del sistema ICEBERG prepara y envía por correo electrónico el reporte de monitoreo del proyecto al gerente general; con la autorización del gerente general actualiza el cronograma de trabajo para observar las diferencias entre los recursos planteados y los recursos disponibles; presenta el informe del proyecto al cliente, en el formato establecido y actualiza el resumen de acciones correctivas del proyecto (Expert Information SAS, 2016).

Administración de la configuración

El equipo asignado realiza las actividades de generación de línea base para los productos de monitoreo del proyecto, esto lo realiza en base a lo establecido en el plan de administración de la configuración del proyecto (Expert Information SAS, 2016).

7.3.3.3 Plan de administración de la configuración

El objetivo de este proceso es facilitar la planeación de las actividades en proyectos de desarrollo y mantenimiento de software. El responsable de la ejecución de este es el gerente del proyecto, no obstante, el equipo asignado al proyecto también está involucrado en su desarrollo (Expert Information SAS, 2016).

Este proceso utiliza como herramienta el servicio TortoiseSVN, el cual ayuda en el control de versiones las cuales se almacenan en un repositorio central, este repositorio almacena los archivos y los cambios realizados sobre estos, permitiéndole al usuario recuperar versiones anteriores (TortoiseSVN, s.f).

En el Anexo 6, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de plan de administración de la configuración se encuentran cuatro subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

21

Plan de Administración de la configuración

El gerente del proyecto debe generar el plan de administración de la configuración teniendo en cuenta los siguientes pasos y utilizando un formato establecido definido previamente por la organización (Expert Information SAS, 2016).

Identificación de tareas de involucrados

En este proceso el gerente del proyecto identifica las responsabilidades de los involucrados en actividades de administración de la configuración (Expert Information SAS, 2016).

Identificación de elementos de configuración y líneas base

En este proceso el gerente del proyecto identifica los elementos de configuración para el proyecto, y cuando se crean las líneas base de los mismos, considerando así mismo el mecanismo de verificación que se aplicará.

Para todos los casos no se generan líneas base, y algunos elementos de configuración se manejan por medio de gestión de versiones del documento. La gestión de versiones consiste en registrar los cambios realizados al documento, con el fin de llevar un histórico de estos. Los documentos que requieren este tipo de administración de la configuración son los que deben ser modificados una gran cantidad de veces durante el proyecto, por lo que llevar una línea base no es eficiente.

Se deben identificar como elementos de la configuración los entregables al cliente, los productos adquiridos, las herramientas y otros activos esenciales del entorno de trabajo, y los productos de trabajo que son críticos para el proyecto.

Entre los productos de trabajo que son críticos para el proyecto se deben incluir elementos de la configuración como: el plan general del proyecto, cuya línea base se genera una vez aprobados todos los planes; el pre-análisis, cuya línea base se genera una vez aprobado el documento por parte del cliente; los requerimientos, cuya línea base se genera una vez aprobados por parte del cliente; la matriz de trazabilidad, en cuya línea base se incluyen los cambios sobre requerimiento y diseño; el diseño, cuya línea base se genera una vez aprobada la inspección por recorrido; el código, cuya línea base se genera una vez aprobada la revisión por pares y una vez finalizada la fase de pruebas, en el caso del código fuente; y por último las pruebas funcionales y de integración, de sistemas y otro tipo de pruebas, cuyas líneas base se generan una vez finalizada la fase de pruebas. Así mismo, se incluyen elementos de la configuración manejados por gestión de versiones como el monitoreo y control del proyecto, cuyas versiones se actualizan una vez realizado un cambio en el documento (Expert Information SAS, 2016).

22

Definir Procedimientos de administración de la configuración

En este proceso, los elementos de configuración deben ser etiquetados indicando la versión del elemento de la configuración. La numeración de las versiones se realiza en dos niveles, indicados por un número entero y uno decimal, en donde el número entero indica versiones aprobadas (1: Aprobada, 0: No aprobada) y el decimal indica versiones intermedias no aprobadas (1: Primer borrador, 2: Primera revisión, etc.).

Para cada elemento de la configuración se debe establecer el mecanismo para administrar la configuración, el cual autoriza la creación, liberación y actualización de líneas base. Los mecanismos posibles son: el de creación, controlado por el autor, quien aprueba los cambios al elemento; el de ingeniería, en la cual se notifica a las partes interesadas cuando se realizan cambios; el de desarrollo, en la cual se notifica a los líderes para que aprueben cambios a elementos; y el formal, en el que el gerente del proyecto y los clientes aprueban los cambios al proyecto.

De acuerdo con el elemento de la configuración se establece el mecanismo de administración de la siguiente manera: para el plan del proyecto, la propuesta técnica y los requerimientos se usa el mecanismo formal, para la matriz de trazabilidad, pruebas del sistema, y monitoreo y control de proyecto se utiliza el mecanismo de ingeniería, y para el diseño, código y pruebas de integración y funcionales se utiliza el mecanismo de desarrollo.

Cada proyecto maneja dos repositorios en la herramienta de administración de configuración: un repositorio diario en el que se almacenan los productos de trabajo que se almacenan diariamente y sus versiones; y un repositorio de líneas base, en el que se guardan los documentos aprobados en su última versión. A los repositorios se les realiza una copia de seguridad de manera diaria.

El registro de administración de la configuración se realiza mediante la herramienta tortoiseSVN, y es responsabilidad de cada integrante del grupo realizar dicho registro.

Los cambios de líneas base que representen un cambio importante en tiempo, alcance o costo, deberán ser solicitados, evaluados y documentados. Estas solicitudes se almacenan en el repositorio de administración de la configuración del proyecto y se deben identificar las personas indicadas para evaluar el impacto de los cambios. Los cambios aceptados que impliquen cambios en compromisos o alcances deben ser documentados; la documentación se almacena en el repositorio de administración de la configuración del proyecto. El control y seguimiento a estas solicitudes es responsabilidad del gerente del proyecto.

Para la administración de la información del proyecto se establece la seguridad de los repositorios de información del proyecto, a quien se le da acceso, a qué información y el tipo de acceso (lectura, edición y creación) (Expert Information SAS, 2016).

23

7.3.3.4 Planeación de actividades cortas

El propósito de este proceso es ayudar al equipo a establecer las actividades a realizar prontamente e identificar la disponibilidad de los miembros del equipo para realizarlas. Los responsables de este proceso son el gerente y el equipo de trabajo asignado a esta tarea. En el desarrollo de este proceso se utilizan como herramientas TeamSystem e ICEBERG (Expert Information SAS, 2016).

En el Anexo 7, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de planeación de actividades cortas se encuentran cinco subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

Definición de Product Backlog Items

Las actividades a realizar se pueden establecer por medio de una lluvia de ideas. Posteriormente se analizan las ideas y se corrigen o eliminan las actividades que no tienen como finalidad completar la tarea. Las actividades deben de ser claras para obtener una mejor ejecución del plan, además no se pueden dedicar más de diez horas a cada tarea. Finalmente, se crea en el TeamSystem los Product Backlog Item del proyecto (Expert Information SAS, 2016).

Disponibilidad por recurso

El gerente del proyecto debe determinar qué porcentaje de disponibilidad tiene el equipo de trabajo y la cantidad de horas que han sido asignadas al plan de actividades cortas. A partir de ello, analizando la disponibilidad presentada por semana se determina la asignación de nuevas tareas (Expert Information SAS, 2016).

Asignación de Product Backlog Items

En ICEBERG por medio del módulo de control de actividades y servicios/asignación de actividades, el gerente del proyecto asigna los Product Backlog Items a cada recurso y las horas dedicadas a cada uno de ellos. Es importante resaltar, que las actividades deben ser balanceadas semanalmente, tomando en cuenta la disponibilidad de los recursos y la cantidad de horas invertidas a la semana para el plan de actividades cortas (Expert Information SAS, 2016).

Definición de actividades al Product Backlog Item

En ICEBERG por medio del módulo de control de actividades y servicios/creación y edición de actividades el equipo de trabajo se crean todas las actividades que deben llevar a cabo los Product Backlog Item del proyecto (Expert Information SAS, 2016).

24

Generar reporte

El gerente del proyecto podrá realizar la generación del reporte de actividades por medio del sistema ICEBERG con la finalidad de identificar la asignación de las actividades, el tiempo asignado, las horas laboradas y la disponibilidad de cada recurso asignado al proyecto. El reporte de actividades debe contener el proyecto, los recursos asignados, las actividades asignadas a cada recurso, la fecha de inicio y de fin de cada actividad asignada a cada recurso y el total de horas asignadas y disponibles por recurso (Expert Information SAS, 2016).

7.3.3.5 Revisiones mayores

La finalidad de este proceso es guiar al gerente y al equipo del proyecto en las revisiones mayores de puntos específicos determinados a lo largo del proyecto de acuerdo al plan de trabajo. Como herramienta en el desarrollo de este proceso, se utiliza el sistema ICEBERG (Expert Information SAS, 2016).

En el Anexo 8, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y el rol encargado de realizarlo. Dentro del proceso de revisiones mayores se encuentran cinco subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.


El gerente del proyecto sigue el procedimiento establecido de monitoreo de proyecto, generando las métricas en el sistema ICEBERG y el reporte del monitoreo del proyecto para la empresa y para el cliente. En el repositorio de activos de procesos de la organización se almacena el resumen de acciones correctivas y los reportes de monitoreo (Expert Information SAS, 2016).

Evaluación de la línea base

El gerente del proyecto junto con el equipo de proyecto evalúa que tan adecuado ha sido el proceso de administración de la configuración, línea base del sistema y ambiente de desarrollo. Finalmente, se actualiza el reporte de monitoreo del proyecto (Expert Information SAS, 2016).

Evaluación del plan

El gerente del proyecto junto con el equipo de proyecto evalúa el desempeño del equipo, en lo concerniente a tamaño estimado del proyecto, recursos planeados y tiempo planeado vs datos reales. Finalmente, se actualiza el reporte de monitoreo del proyecto (Expert Information SAS, 2016).

25

Desempeño de la calidad

El gerente del proyecto junto con el equipo de proyecto evalúa el desempeño del equipo, en lo relacionado a la calidad de los productos generados. Finalmente, se actualiza el reporte de monitoreo del proyecto (Expert Information SAS, 2016).

Evaluación del proceso

El gerente del proyecto junto con el equipo de proyecto identifica los problemas o inconvenientes presentados en los procesos aplicados al proyecto, sugiere mejoras al proceso y las registra en el sistema ICEBERG. Finalmente, si se identifican mejores prácticas y lecciones aprendidas, estas deben de ser documentadas (Expert Information SAS, 2016).

7.3.3.6 Selección de alternativas

Este proceso le permite al equipo asignado al proyecto junto con la ayuda del gerente del proyecto tomar decisiones a partir de la evaluación entre varias alternativas de solución (Expert Information SAS, 2016).

En el Anexo 9, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y el rol encargado de realizarlo. Dentro del proceso de selección de alternativas se encuentran cuatro subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

Definición de criterios de selección

El equipo asignado al proyecto identifica y documenta los criterios de selección que usará para evaluar las diferentes alternativas de solución, esto lo realiza teniendo en cuenta las decisiones documentadas que se han tomado en proyectos anteriores y que les permiten identificar otros criterios de selección (Expert Information SAS, 2016).

Se identifican y registran criterios que permiten medir de forma objetiva, también se identifican y registran criterios subjetivos que apliquen, los cuales deben de ser evaluados por una persona o grupo de personas. Luego se determina la importancia relativa entre criterios objetivos y subjetivos, asignándoles un porcentaje a cada uno de ellos, siendo la suma total 100%. Después, se determina la importancia relativa de cada criterio subjetivo, asignándole un porcentaje a cada uno de ellos, cuya suma sea 100% y finalmente se determina la importancia relativa de los criterios objetivos, asignándole un porcentaje a cada uno de ellos, la suma del porcentaje de estos debe ser 100% (Expert Information SAS, 2016).

Selección de métodos de evaluación

El equipo asignado al proyecto selecciona y documenta la forma en que se evaluaran los criterios objetivos y subjetivos teniendo en cuenta: para los criterios objetivos se deben aplicar métodos directos de medición y para los criterios subjetivos se debe determinar la forma en la

26

que se decretara la calificación de estos, además, se deben de identificar las personas que van a participar en la evaluación de las alternativas y documentarlas (Expert Information SAS, 2016).

Identificación de alternativas

El equipo asignado debe identificar alternativas de solución que apliquen a la decisión, en algunos momentos cuando el equipo lo considere necesario pueden realizar una lluvia de ideas para identificar las alternativas de solución, estas deben ser al menos tres y deberán de ser documentadas (Expert Information SAS, 2016).

Selección de solución

El equipo asignado debe aplicar los métodos de evaluación a cada una de las alternativas identificadas. Si son criterios objetivos se identifica el valor obtenido para cada criterio en cada alternativa y si son criterios subjetivos se genera una calificación entre uno y diez para cada criterio en cada alternativa. Posteriormente, se elige la alternativa con mayor calificación final y se genera la línea base. Finalmente, los formatos que documentan la selección son almacenados en el repositorio de activos de procesos de la empresa, para futuras referencias en otros proyectos. Cabe resaltar que, si en algún caso se identifica algún riesgo asociado a la solución, debe de incluirse en el plan de riesgos del proyecto (Expert Information SAS, 2016).

Fases

En esta sección se realiza la descripción de los procesos, subprocesos y procedimientos que componen las seis fases del proceso de desarrollo de software de la empresa Expert Information SAS.

7.3.4.1 Fase de pre-análisis

Como se explicó anteriormente en la sección 7.3.1, en esta fase se realiza el análisis preliminar del proyecto. Para ello la empresa realiza seis procesos, los cuales se muestran en el Anexo 10. A continuación, se realiza la descripción de cada proceso que compone la fase de pre-análisis.

Pre-análisis

Este proceso tiene el objetivo de guiar a los responsables asignados, en la realización del pre-análisis de los requerimientos del sistema. Los roles responsables de ejecutarlo son el gerente comercial y el equipo pre-análisis (Gerente comercial y líder técnico) junto con la colaboración del cliente. En el desarrollo de este, se utiliza un modelo de estimación llamado WEMMOD y se realizan inspecciones, ambas herramientas han sido implementadas previamente en el sistema ICEBERG (Expert Information SAS, 2016).

En el Anexo 11, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de pre-análisis se encuentran

27

siete subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Selección de equipo de trabajo

El gerente comercial selecciona el equipo de trabajo que realizará el pre-análisis, de acuerdo a un procedimiento establecido previamente por la organización (Expert Information SAS, 2016).

2. Planeación del pre-análisis

El equipo de pre-análisis, realiza un plan para realizar el pre-análisis, de acuerdo al procedimiento definido para la planeación de actividades cortas (Expert Information SAS, 2016).

3. Levantamiento de requerimientos generales

Se realizan reuniones con el cliente, con el objetivo de identificar los requerimientos funcionales y no funcionales generales para el sistema. Es importante resaltar que, algunas de las preguntas genéricas que se realizan durante la reunión, están previamente definidas en un formato de entrevista con el cliente que ha creado la empresa (Expert Information SAS, 2016).

4. Resolución de dudas

El equipo de pre-análisis debe identificar las dudas que surgen con respecto a los requerimientos y resolverlas durante las reuniones con el cliente. No obstante, hay aspectos que el equipo debe estar seguro de cubrir, tales como: la identificación de los “stakeholders”, la identificación de aspectos funcionales del sistema y las restricciones (Expert Information SAS, 2016).

5. Documentar pre-análisis

El equipo de pre-análisis genera el documento con la propuesta técnica o de servicio, en esta se incluye la estimación de tamaño y esfuerzo, además de la propuesta de plan de trabajo. El documento es revisado de acuerdo al procedimiento de revisión por pares y se registran los hallazgos en el sistema ICEBERG (Expert Information SAS, 2016).

6. Revisión del cliente y ajuste de hallazgos

La propuesta técnica es enviada al cliente por correo electrónico y por este mismo medio se reciben los comentarios u observaciones sobre esta y con base en ellos se realizan los ajustes pertinentes (Expert Information SAS, 2016).

7. Aprobación del cliente

El cliente revisa el documento con los ajustes realizados y aprueba el documento de propuesta técnica (Expert Information SAS, 2016).

28

Selección de equipo de trabajo

El líder del proyecto (Gerente comercial o gerente de proyectos) junto con los integrantes de la fábrica de software y la oficina de recursos humanos son los encargados de realizar la selección del equipo de trabajo que ejecutará una actividad específica o un proyecto (Expert Information SAS, 2016).

En el Anexo 12, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y el rol encargado de realizarlo. Dentro del proceso de selección de equipo de trabajo se encuentran tres subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Evaluación de características del equipo

Se identifican las habilidades requeridas por el equipo y la cantidad de personas y tiempo de asignación, durante las diferentes etapas de una actividad o proyecto (Expert Information SAS, 2016).

2. Revisión de disponibilidad de recursos

El gerente de proyecto se encarga de realizar la matriz de habilidades y la disponibilidad actual o cercana de des-asignación de los integrantes de la fábrica de software con las habilidades requeridas. También, de acuerdo al número de integrantes requerido, habilidades y disponibilidad, el gerente asigna al personal que se liberará en las fechas estipuladas; solicita a recursos humanos la contratación de personas con las habilidades requeridas para las fechas esperadas; evalúa la asignación de personas asignadas a otros proyectos y la sustitución de estos en los proyectos en los cuales estaban asignados; evalúa la inclusión de personas que no cumplan con todas las habilidades, pero cuyas habilidades faltantes puedan ser adquiridas en un tiempo corto por medio de una capacitación (Expert Information SAS, 2016).

3. Asignación de recursos

El gerente del proyecto realiza la asignación de los recursos por el tiempo requerido a la actividad o proyecto (Expert Information SAS, 2016).

Selección de alternativas

Este proceso hace parte del conjunto de procesos que son transversales a las fases del proceso de desarrollo de software de la empresa Expert Information SAS. Por lo cual, este ha sido explicado previamente en la sección 7.3.3.6.

Planeación de actividades cortas


29

Inspección por recorrido


Estimación inicial de proyectos

La finalidad de este proceso es guiar al gerente comercial y al equipo de estimación, con base en el pre-análisis de los requerimientos del sistema a realizar la estimación inicial del proyecto, esto con la colaboración del cliente (Expert Information SAS, 2016).

En el Anexo 13, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de estimación inicial de proyectos se encuentran siete subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Asignar responsable

El gerente comercial o gerente de desarrollo elige al responsable de realizar la estimación (Expert Information SAS, 2016).

2. Preparar estimación

El administrador comercial planea los requerimientos para la reunión (sala, equipos, proyector, entre otros) y envía al encargado de la estimación la información con respecto al producto a estimar. Por otro lado, el encargado de la estimación estudia la documentación recibida previa a la reunión (Expert Information SAS, 2016).

3. Inicio de la reunión

El gerente comercial comienza la reunión explicando el producto que se va a estimar y sus detalles, por su parte, el encargado de la estimación identifica y discute aspectos y suposiciones relacionadas con el producto (Expert Information SAS, 2016).

4. Definición de actividades de análisis del sistema

La persona encargada de realizar la estimación descompone el producto en partes funcionales más pequeñas que faciliten la estimación de este. La descomposición funcional queda relacionada en la propuesta técnica o de servicios y se documenta en el sistema ICEBERG cuando se vaya a realizar la estimación de tiempos (Expert Information SAS, 2016).

5. Definición de actividades de estimación

El administrador comercial realiza la definición de las restricciones temporales, las cuales deben de ser cumplidas por el proyecto en desarrollo; las restricciones de costo, las cuales especifican el límite presupuestal que ha definido el cliente para el proyecto; y la rentabilidad del

30

proyecto, el cual es un rango porcentual dentro del cual está el valor de rentabilidad para la empresa (Expert Information SAS, 2016).

6. Aplicar modelo de estimación

El estimador aplica el modelo de estimación WEMMOD mediante el sistema ICEBERG, este da como resultado la cantidad de horas hombre que requiere el proyecto para ser desarrollado (Expert Information SAS, 2016).

7. Documentar estimación

El estimador documenta en la propuesta técnica la cantidad de horas hombre requerida en cada funcionalidad y también el esfuerzo de la gerencia del proyecto, de análisis-diseño, de arquitectura de software, de aseguramiento de calidad, del ingeniero de servicios y documentación. Después de esto, se genera la versión final de la propuesta técnica, la cual es almacenada en el repositorio de los activos de procesos de la organización (Expert Information SAS, 2016).

7.3.4.2 Fase de planeación

De acuerdo a lo explicado en la sección 7.3.1, en esta fase se realizan todas las actividades necesarias para definir la planeación del proyecto. Para ello la empresa realiza once procesos, los cuales se muestran en el Anexo 14. A continuación, se realiza la descripción de cada proceso que compone la fase de planeación.

Planeación del proyecto

Este proceso tiene el objetivo de guiar al gerente de desarrollo, el gerente del proyecto y el líder de proyectos en la planeación de un proyecto de software (Proyectos de desarrollo y mantenimiento) (Expert Information SAS, 2016).

En el Anexo 15, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de planeación del proyecto se encuentran dieciocho subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Preparación de la planeación

El gerente comercial entrega al gerente del proyecto la documentación existente sobre el producto y la propuesta técnica (Expert Information SAS, 2016).

2. Revisión de la estimación

El gerente del proyecto inspecciona la estimación y el plan de trabajo de la propuesta técnica. Si este identifica elementos que no han sido considerados en la estimación o considera que la misma no es adecuada, debe negociar con el gerente comercial los recursos y el tiempo

31

planeado del proyecto. Finalmente se actualiza la propuesta técnica con los cambios realizados y en base a esta se genera el documento de alcance propuesta técnica (Expert Information SAS, 2016).

3. Selección de equipo de trabajo

Cuando el cliente aprueba la propuesta técnica, el gerente del proyecto está habilitado para seleccionar el equipo de trabajo que participará en el proyecto. En algunas ocasiones se pueden encontrar otros involucrados que tienen una participación ocasional, estos pueden ser externos o de la compañía y también deben de ser identificados y documentados como involucrados en el proyecto (Expert Information SAS, 2016).

4. Identificación de involucrados relevantes

El gerente del proyecto debe identificar los involucrados relevantes (Dentro y fuera de la compañía); las tareas en las que estos se deben de involucrar; si hay o no compromisos con los involucrados relevantes, en el caso de tenerlos, se deben identificar cuáles son. También debe de identificar a los responsables de definir los requerimientos del proyecto y los involucrados relevantes en el diseño e implementación del producto (Expert Information SAS, 2016).

5. Integración del comité de control de cambios

El gerente del proyecto selecciona los integrantes del comité de control de cambios (CCB), al director de este y los documenta en el formato establecido. Generalmente, en este comité también se encuentran los responsables del diseño, implementación y de las pruebas (Expert Information SAS, 2016).

6. Calendario

El gerente del proyecto en base a los ciclos de vida estándares que propone la organización, identifica y documenta el ciclo de vida aplicable al proyecto. Posteriormente, acorde al ciclo de vida identificado establece el cronograma detallado del proyecto, este cronograma debe de coincidir con la estimación de esfuerzo previamente realizada y aprobada por el cliente en la propuesta técnica.

El calendario también debe de incluir la generación de los productos de planeación del proyecto, tales como:

o Planes obligatorios: Plan de aseguramiento de la calidad, plan de administración de la configuración, adaptaciones al proceso estándar, plan de administración de riesgos y plan de análisis formal de decisiones.

o Planes no obligatorios: Plan de soporte, plan de conocimientos y habilidades y lista de productos comprados o sub-contratados. Si bien estos planes no son obligatorios, si ayudan a identificar que se apliquen las condiciones descritas en las actividades correspondientes.

32

El calendario debe de incluir la fecha de inicio, duración, fecha de terminación, recursos asignados a cada actividad y dependencias entre actividades y tareas. Dichas dependencias deben ser establecidas para: las actividades periódicas de seguimiento del proyecto y reporte periódico al gerente general y al cliente; actividades periódicas de generación de métricas del proyecto; puntos de revisiones mayores, en los que se harán revisiones detalladas del estatus del proyecto; actividades de verificación de productos; actividades de pruebas de productos, incluyendo pruebas de unidad, funcionales, de integración y de sistema; actividades de integración del producto; actividades de aseguramiento de la calidad de acuerdo al plan de aseguramiento de la calidad y actividades de capacitación de acuerdo al plan de conocimientos y habilidades.

Cuando se finalice la definición del calendario, este debe de ser revisado y aprobado por el gerente general. Además, se debe realizar una reunión en la cual se presenta el cronograma del proyecto a todo el equipo de trabajo y se establece la frecuencia de la generación de los reportes de estado al gerente general y al cliente. Si surgen propuestas de cambios, estas serán evaluadas y en el caso de ser aprobadas se realizarán los cambios pertinentes y la presentación del cronograma nuevamente.

Se deben realizar revisiones semanales del cumplimiento del calendario y revisiones diarias de las actividades del equipo, estas están a cargo del gerente del proyecto (Expert Information SAS, 2016).

7. Ambiente de trabajo

El gerente del proyecto con la ayuda del equipo asignado al proyecto y basándose en los ambientes de trabajo estándar definidos previamente por la organización, identifica las variaciones o adiciones sobre las herramientas e instalaciones de desarrollo y soporte que sean necesarias en el proyecto, tales como: ayudas de requerimientos y diseño; editores, compiladores, ayudas de depuración, herramientas de prueba; seguimiento de defectos, administración de configuración, seguimiento de asuntos pendientes y conteo de LOC, de diferencias y análisis de datos (Expert Information SAS, 2016).

8. Plan de aseguramiento de la calidad

El líder de calidad define el plan de aseguramiento de calidad de acuerdo al procedimiento establecido previamente por la organización (Expert Information SAS, 2016).

9. Plan de administración de la configuración

El gerente del proyecto define el plan de administración de la configuración de acuerdo al procedimiento establecido previamente por la organización (Expert Information SAS, 2016).

33

10. Adaptaciones al proceso

El gerente del proyecto debe realizar la adaptación del proceso de desarrollo de software, de acuerdo a las características del proyecto y al estándar de ciclos de vida. Las adaptaciones al proceso deben de ser documentadas al inicio del proyecto (Expert Information SAS, 2016).

11. Plan de soporte

El gerente del proyecto define el plan de soporte (si aplica). En el caso que aplique, identifica los equipos y herramientas requeridas, tales como: ayudas de requerimientos y diseño; editores, compiladores, ayudas de depuración y herramientas de prueba; seguimiento de defectos, administración de configuración, seguimiento de asuntos pendientes y análisis de datos (Expert Information SAS, 2016).

12. Plan de conocimientos y habilidades

El gerente del proyecto identifica las habilidades y conocimientos necesarios para desarrollar el proyecto y revisa en la matriz de habilidades si se cuenta con estos. En el caso de que los miembros del equipo de trabajo no cuenten con todas las habilidades o conocimientos requeridos, el gerente del proyecto debe de planear las posibles soluciones para adquirirlos, tales como, capacitaciones, autoestudio o nuevas contrataciones (Expert Information SAS, 2016).

13. Plan de administración de riesgos

El gerente del proyecto realiza la definición del plan de administración de riesgos de acuerdo a un procedimiento definido anteriormente por la organización (Expert Information SAS, 2016).

14. Plan de análisis formal de decisiones

El gerente del proyecto debe de identificar situaciones donde se requiera un análisis formal para la toma de decisiones, acorde a los criterios definidos en el proceso de análisis de decisiones (Expert Information SAS, 2016).

15. Plan de sub-contratación

El gerente del proyecto identifica y documenta los productos que serán comprados o sub-contratados (Expert Information SAS, 2016).

16. Aprobación de los planes

El gerente del proyecto revisa los planes previamente documentados con el gerente general, esta revisión la realizan en base a un procedimiento establecido previamente por la organización. De ahí, se obtiene la aprobación para los recursos definidos en los planes. Cabe resaltar, que se debe de documentar la fecha de aprobación de estos planes en cada uno de ellos (Expert Information SAS, 2016).

34

17. Administración de la configuración

El gerente del proyecto solicita la creación de la línea base del plan general del proyecto, este debe contener el cronograma del proyecto, el plan de aseguramiento de la calidad, el plan de administración de la configuración, las adaptaciones al proceso estándar, el plan de soporte, el plan de conocimientos y habilidades, el plan de administración de riesgos, el plan de análisis formal de decisiones, la lista de los productos comprados o sub-contratados y el alcance de la propuesta técnica (Expert Information SAS, 2016).

18. Lecciones aprendidas

El gerente del proyecto junto con el apoyo del equipo asignado evalúan el proceso de planeación con el objetivo de identificar problemas o inconvenientes que surgieron durante el proceso de planeación, sugerir mejoras al proceso y completar las propuestas de mejora realizadas previamente, identificar y documentar las lecciones aprendidas y mejores prácticas e incluir en el repositorio de activos de procesos de la organización las adaptaciones realizadas al proceso estándar (Expert Information SAS, 2016).

Plan de aseguramiento de la calidad

Este procedimiento ayuda al líder de calidad en la planeación de las actividades de aseguramiento de la calidad. Dichas actividades les permiten realizar una evaluación objetiva de los procesos realizados y productos de trabajo. Lo anterior, lo llevan a cabo por medio de la comparación entre los procesos y productos obtenidos frente a procesos, estándares y procedimientos definidos aplicables a proyectos de desarrollo de software (Expert Information SAS, 2016).

En el Anexo 16, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de plan de aseguramiento de la calidad se encuentran cuatro subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Plan de aseguramiento de la calidad

El líder de calidad debe generar el plan de aseguramiento de la calidad, teniendo en cuenta los pasos previamente definidos por la organización (Expert Information SAS, 2016).

2. Identificación de responsables

El líder de calidad identifica las obligaciones, responsabilidades y tareas del equipo asignado al proyecto en las actividades de aseguramiento de la calidad. Como mínimo, se debe establecer que: el gerente del proyecto es el responsable de garantizar que se establezcan planes de corrección de los hallazgos detectados en auditorias de aseguramiento de la calidad y de dar seguimiento a los mismos; cada miembro del equipo del proyecto es responsable de establecer

35

planes de corrección para los hallazgos detectados que se le asignen, así como de asistir a las auditorías programadas del proyecto (Expert Information SAS, 2016).

3. Plan de auditorías de proceso

El líder de calidad es el encargado de establecer los procesos que serán auditados y el momento en el que las auditorias serán realizadas. En el caso de tener productos o componentes sub-contratados, se deben determinar los procesos críticos del proveedor que deben de ser monitoreados y posteriormente incluirlos en el plan de auditorías.

El plan de auditorías es realizado por el líder de calidad del proyecto y revisado por el gerente de este (Expert Information SAS, 2016).

4. Plan de auditorías de producto

El líder de calidad es el encargado de establecer los productos que serán auditados y el momento en el que las auditorias serán realizadas. Los productos pueden generarse en un volumen amplio de los mismos en los proyectos, es por esto, que se auditará solo una muestra y el tamaño de esta será determinado por el grupo de aseguramiento de la calidad. Es importante resaltar, que se deben auditar los productos antes de ser entregados al cliente (Expert Information SAS, 2016).

Plan de administración de la configuración




Análisis de riesgos

La finalidad de este proceso es guiar al equipo asignado en la realización del análisis de riesgos de todo el proyecto (Expert Information SAS, 2016).

En el Anexo 17, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de análisis de riesgos se encuentran cuatro subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

36

1. Identificación de riesgos

El equipo asignado a esta actividad identifica los riesgos asociados al proyecto con la información de: estado actual del riesgo, fecha de identificación, fase, riesgo, fuente, descripción, categoría e impacto. En el caso que se identifique una categoría adicional, esta deberá de ser incluida (Expert Information SAS, 2016).

2. Análisis cualitativo del riesgo

El equipo asignado a esta actividad realiza el registro del análisis cualitativo del riesgo, el cual debe de incluir: la exposición, la cual indica que tan frecuente es la exposición a situaciones en las cuales se presentan fallas en los controles preventivos y por lo tanto es factible que se presente el riesgo; la probabilidad, la cual indica que tan probable es que el riesgo se materialice; la severidad, la cual indica el impacto que podría causar la materialización del riesgo; la aceptabilidad, la cual indica el nivel hasta el cual se tolera la existencia de algo que no afecta significativamente las condiciones de la operación. Cabe resaltar, que este análisis debe de ser realizado para cada riesgo identificado (Expert Information SAS, 2016).

3. Plan de seguimiento y repuesta

El equipo asignado debe realizar el plan de seguimiento y respuesta al riesgo, este debe de contener: la estrategia de respuesta, la cual muestra la estrategia a implementar como respuesta al riesgo (aceptar, mitigar, evitar o trasferir); descripción de la estrategia de respuesta, la cual describe la forma en la cual se tratará el riesgo; el responsable, el cual es el encargado de supervisar el riesgo; la fecha de seguimiento y la fecha de actualización (Expert Information SAS, 2016).

4. Almacenar plan administración de riesgos

Una vez aprobado el plan de administración de riesgos por el gerente general, este pasa a incluirse en el repositorio de activos de procesos de la organización (Expert Information SAS, 2016).

Desarrollo de software

Este proceso tiene como objeto guiar el proceso de desarrollo de software, en procesos que por su tamaño implican la conformación de un equipo de trabajo. Las actividades de este proceso serán realizadas por el gerente de proyectos, el arquitecto de software, los líderes de proyectos, los ingenieros de software y los ingenieros de pruebas. Además, se utilizarán las herramientas de TeamSystem e ICEBERG (Expert Information SAS, 2016).

En el Anexo 18, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de desarrollo de software se encuentran doce subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

37

1. Entrega de documentación inicial

El gerente comercial informa al administrador comercial, sobre la solicitud de propuesta del cliente y le entrega la información inicial de esta (Expert Information SAS, 2016).

2. Pre-análisis

La fábrica de software identifica los requerimientos generales del sistema, realiza la estimación de tamaño, esfuerzo, propuesta calendario y genera la propuesta técnica. Lo anterior, lo realizan con un procedimiento establecido previamente por la organización (Expert Information SAS, 2016).

3. Selección del gerente del proyecto

Posterior a la aprobación de la propuesta del cliente, el gerente general por medio de su criterio de experto selecciona al gerente del proyecto (Expert Information SAS, 2016).

4. Planeación del proyecto

El equipo asignado debe: revisar la estimación y el plan de trabajo de la propuesta técnica; generar el plan del proyecto y el plan detallado de la fase de requerimientos; y deben de evaluar los riesgos y amenazas del proyecto (Expert Information SAS, 2016).

5. Requerimientos

El equipo asignado debe: documentar, revisar y validar los requerimientos; desarrollar e inspeccionar las especificaciones de estos y definir las pruebas de sistema y generar un bosquejo del manual de usuario (Expert Information SAS, 2016).

6. Diseño

El equipo asignado debe generar e inspeccionar el diseño de alto nivel y producir las especificaciones de desempeño e integración (Expert Information SAS, 2016).

7. Implementación

El equipo asignado debe diseñar, codificar, inspeccionar y probar cada componente del producto. También, deben de producir las especificaciones de cada prueba, de cada producto y documentarlo (Expert Information SAS, 2016).

8. Pruebas de despliegue

El equipo asignado debe: desarrollar materiales y datos de pruebas; construir el producto integrado; ejecutar las pruebas de integración, funcionales y de sistema; devolver los componentes defectuosos para su respectivo reajuste y re-aplicación de pruebas y producir y revisar la documentación final (Expert Information SAS, 2016).

38

9. Pruebas de aceptación

El cliente realiza unas pruebas de aceptación de acuerdo a sus procesos internos y realiza una prueba piloto con el producto (Expert Information SAS, 2016).

10. Corrección de defectos de pruebas de aceptación

En el caso de la detección de defectos, estos se corrigen y se ejecutan nuevamente las pruebas de despliegue que sean requeridas por el componente. Después de realizar las pruebas de despliegue, el producto es enviado nuevamente a donde el cliente para que este realice sus pruebas de aceptación (Expert Information SAS, 2016).

11. Liberación a producción

El producto final es instalado en el ambiente de producción de acuerdo a los procesos y políticas definidos por el cliente. Se realiza el acta de liberación del proyecto, de acuerdo al formato establecido por la organización, y es firmada por el cliente y por un representante de la compañía (Expert Information SAS, 2016).

12. Cierre del proyecto

Se realizan las actividades de fin de proyecto de acuerdo al procedimiento establecido por la organización (Expert Information SAS, 2016).

Análisis de decisiones y resolución

La finalidad de este proceso es realizar el análisis de posibles decisiones, utilizando un proceso de evaluación formal que permite evaluar las alternativas identificadas frente a criterios establecidos (Expert Information SAS, 2016).

En el Anexo 19, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y el rol encargado de realizarlo. Dentro del proceso de análisis de decisiones y resolución se encuentran tres subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Identificación de decisiones que requieren análisis formal

El equipo de trabajo debe identificar las decisiones que requieren de un análisis formal. La identificación de estas se hace en base a los siguientes criterios: decisiones que pueden afectar el cumplimiento de los objetivos definidos para el proyecto; decisiones referentes a obligaciones legales; decisiones técnicas que tengan un efecto significativo en la calidad, desempeño y seguridad del producto. Si en el transcurso del proyecto se encuentran nuevas decisiones que deban analizarse formalmente, estas deben de ser documentadas (Expert Information SAS, 2016).

39

2. Selección de alternativas

El equipo de trabajo debe establecer los criterios de evaluación, identificar las alternativas, seleccionar los métodos de evaluación y seleccionar la solución de acuerdo al procedimiento establecido por la organización. Finalmente debe de documentar la selección realizada (Expert Information SAS, 2016).


El equipo de trabajo debe aplicar el procedimiento de administración de la configuración a la selección de alternativas cada vez que se obtenga una versión aprobada (Expert Information SAS, 2016).



7.3.4.3 Fase de requerimientos

Como se explicó anteriormente en la sección 7.3.1, en esta fase se realizan todas las actividades concernientes a la toma de requerimientos para el desarrollo del proyecto. Para ello la empresa realiza seis procesos, los cuales se muestran en el Anexo 20. A continuación, se realiza la descripción de cada proceso que compone la fase de requerimientos.

Requerimientos

Este proceso tiene como objetivo guiar al equipo de trabajo en la producción de una especificación de requerimientos de sistema (SRS) completa, valida y exacta (Expert Information SAS, 2016).

En el Anexo 21, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de requerimientos se encuentran once subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Plan de recolección de requerimientos

El equipo de requerimientos revisa el documento de alcance de propuesta técnica con el fin de identificar errores, omisiones y clarificar preguntas. Además, el líder funcional produce un plan de reuniones para recolectar los requerimientos y preguntas detalladas, usando el procedimiento establecido en la planeación de actividades cortas, y organiza con el cliente las fechas para las reuniones. Por su parte el equipo de requerimientos realiza una doble revisión y corrección de las suposiciones hechas en los requerimientos, en el caso de ser necesario (Expert Information SAS, 2016).

40

2. Obtención de los requerimientos

El analista funcional realiza reuniones con el cliente, mediante estas obtiene los requerimientos del cliente o usuario, además realiza la documentación de los requerimientos y los resultados obtenidos en cada reunión (Expert Information SAS, 2016).

3. Identificación y priorización de atributos de calidad (IPAC)

El equipo del proyecto por medio de una reunión con los stakeholders (Cliente) y moderadores (Expert: Arquitecto de software y líder de desarrollo) identifican los atributos de calidad del proyecto por medio de algunas actividades. Inicialmente los moderadores realizan una presentación e introducción del IPAC; después, los stakeholders realizan la presentación del contexto del negocio y plan de arquitectura (Plan con la descripción de los artefactos teóricos detallados de alto nivel que se tienen del sistema); mientras tanto, los moderadores identifican la información necesaria y relevante del contexto del negocio y sistema; posteriormente, los stakeholders realizan una lluvia de ideas de los posibles escenarios para el producto; más tarde, los moderadores revisan y consolidan los escenarios; inmediatamente los stakeholders priorizan los escenarios y los detallan acorde a la priorización obtenida; y finalmente los moderadores realizan un acta de reunión consolidando los resultados de la reunión (Expert Information SAS, 2016).

4. Especificación de requerimientos

El analista funcional debe producir la especificación de requerimientos de sistema, donde incluye: el comportamiento y desempeño normal, anormal y de recuperación del sistema; las interfaces operacionales y de usuarios; el desempeño esperado del software; las interfaces con otros sistemas o hardware y cada dependencia entre requerimientos del SRS y prototipos de pantalla y/o casos de uso (Expert Information SAS, 2016). Ver formato de casos de uso en el Anexo 22.

5. Inspección del SRS

El analista funcional y el líder funcional inspeccionan el SRS, los prototipos de pantalla y la matriz de trazabilidad, mediante el procedimiento de revisión por pares. Si también se realizaron especificaciones de los casos de uso, estas deberán de ser inspeccionadas usando el mismo procedimiento de revisión por pares. Además, el líder funcional debe de registrar los datos de la inspección (Tamaño, tiempo, defectos) en el sistema ICEBERG. Por su parte los analistas funcionales deben de corregir los defectos encontrados, solucionar las situaciones y actualizar los formatos SRS, prototipos de pantalla y casos de uso (Expert Information SAS, 2016).

41

6. Solicitar aprobación del cliente

El analista funcional le entrega al cliente la documentación de la especificación de los requerimientos del sistema, prototipos de pantalla y/o casos de uso, de tal forma que este puede revisarlos y dar su aprobación (Expert Information SAS, 2016).

7. Correcciones

El analista funcional realiza las correcciones mencionadas por el cliente sobre los documentos de especificación de los requerimientos del sistema, prototipos de pantalla y/o casos de uso. Posteriormente, los documentos corregidos son nuevamente entregados al cliente, de tal forma que este pueda aprobarlos (Expert Information SAS, 2016).

8. Plan de pruebas

El líder de calidad debe definir las pruebas de verificación de los sistemas y productos en base a las especificaciones, se debe incluir: la identificación de componentes a probar; el ambiente de pruebas; la secuencia de pruebas, dependencias y casos de prueba; las interfaces, funciones y desempeño normal y anormal; y las condiciones de seguridad, confiabilidad y recuperación. Dado el caso, si el líder de pruebas no puede generar el plan de pruebas, este puede ser generado por el líder funcional.

Los tipos de prueba que se van a desarrollar dentro del plan de prueba son: pruebas de integración y funcionales, pruebas unitarias y otros tipos de pruebas requeridas en el proyecto (Expert Information SAS, 2016).

9. Inspección plan de pruebas

El gerente de proyectos debe de inspeccionar el plan de pruebas usando un procedimiento establecido previamente por la organización, debe de registrar en el sistema ICEBERG los datos de tamaño, tiempos y defectos encontrados en la revisión. Además, debe de corregir los defectos encontrados, resolver todas las situaciones y actualizar el formato de plan de pruebas (Expert Information SAS, 2016).

10. Línea base de requerimientos

Cuando el documento SRS, prototipos de pantalla y casos de uso (si aplica) tengan una nueva versión aprobada el gerente del proyecto le notifica al administrador de la configuración. Este último, toma los documentos del repositorio diario y los sube al repositorio línea base del proyecto y notifica al gerente (Expert Information SAS, 2016).

11. Fin de ciclo

El equipo de requerimientos continua con el proceso de revisiones mayores, de tal forma que puedan identificar propuestas de mejora y se generen los PIPs (Expert Information SAS, 2016).

42

Planeación actividades cortas


Revisiones mayores








7.3.4.4 Fase de diseño

Acorde a lo explicado en la sección 7.3.1, en esta fase se realizan todas las actividades relacionadas al diseño del proyecto. Para ello la empresa realiza seis procesos, los cuales se muestran en el Anexo 23. A continuación, se realiza la descripción de cada proceso que compone la fase de diseño.

Diseño

El fin de este proceso es ayudar al equipo de diseño en la generación de una especificación de diseño de alto nivel (HLD) completa, valida y exacta. Para ello, el equipo de diseño hace uso de herramientas tales como, power designer, Enterprise architect e inspecciones implementadas en el sistema ICEBERG (Expert Information SAS, 2016).

En el Anexo 24, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de diseño se encuentran ocho

43

subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Diseño estructural

En este proceso se produce el diseño conceptual general del producto incluyendo el marco de trabajo arquitectónico del proyecto y los componentes del producto, funciones principales e interfaces. El líder de desarrollo debe documentar el diseño conceptual generado en el formato establecido, para lo cual debe identificar alternativas aplicables, evaluarlas usando el procedimiento de selección establecido previamente por la organización y documentarlas (Expert Information SAS, 2016).

2. Primera etapa del diseño

Para este procedimiento el equipo de diseño debe revisar la especificación de requerimientos y casos de uso (si están definidos). En el primer ciclo de diseño de alto nivel, se requiere producir las definiciones de requerimientos y módulos, diagrama de casos de uso, diagrama de actividades y de secuencias, siempre y cuando sea requerido; y diagrama de distribución.

Si se identifica una decisión que requiera evaluación de alternativas para diseño de alto nivel, se identifican las alternativas aplicables, se evalúan usando el procedimiento de selección establecido y se documentan.

Para los componentes del producto se selecciona entre las alternativas de construir, comprar o reutilizar, usando el procedimiento de selección establecido y se documenta en el formato correspondiente (Expert Information SAS, 2016).

3. Pasos de diseño subsecuentes

En este proceso el equipo de diseño evaluan las situaciones de diseño de ciclos anteriores y se revisa el diseño actual contra los requerimientos. Del mismo modo se definen las decisiones de las clases, relaciones y diagramas de secuencia, siempre y cuando sea requerido. Además, se debe revaluar el diseño y volver a definir si es necesario.

Cuando se identifique una decisión que requiera la evaluación de alternativas para cada ciclo del diseño, se deben identificar las alternativas aplicables y evaluarlas usando el procedimiento establecido por la organización y nuevamente se documentan en el formato correspondiente.

Al igual que en la primera etapa de diseño, los componentes del producto se deben seleccionar entre alternativas de construir, comprar o reutilizar; usando el procedimiento establecido, y se documentan estas en el formato correspondiente (Expert Information SAS, 2016).

44

4. Especificaciones de diseño del sistema

El líder de desarrollo documenta las especificaciones de diseño de acuerdo al formato establecido incluyendo: diseño conceptual (Definiciones de requerimientos y módulos, diagramas de casos de uso, diagrama de actividades y diagrama de secuencia, si se requiere), especificaciones de diseño (estilo de arquitectura, vista global, representación arquitectónica, vista funcional o lógica, vista física, vista de implementación, vista de casos de uso y vista de despliegue), diagrama de distribución y decisiones de diseño.

Al elaborar el diseño de alto nivel se debe considerar que este sea modular, claro, simple, mantenible, seguro, escalable, y consistente con los requerimientos. Para cada elemento del diseño de alto nivel se debe tener una referencia a su fuente en la especificación de requerimientos o casos de uso en la matriz de trazabilidad (Expert Information SAS, 2016).

5. Estrategia de integración

En este proceso el líder de desarrollo debe definir la secuencia de integración del producto y dependencias entre los componentes de acuerdo al formato establecido (Expert Information SAS, 2016).

6. Inspección al diseño de alto nivel

Para este proceso se conduce una inspección al diseño de alto nivel de acuerdo al procedimiento establecido, para lo cual el equipo de diseño se encarga de inspeccionar todos los materiales de diseño y la estrategia de integración. Para la inspección de los formatos se deben utilizar las listas de verificación definidas para cada uno.

El arquitecto de software es el encargado de registrar los datos de la inspección en el sistema ICEBERG, entre los cuales están datos de tamaño de producto, tiempo de inspección y defectos encontrados. Así mismo, el arquitecto o el líder de desarrollo se encarga de corregir los defectos encontrados, clarificar y resolver todas las situaciones, actualizar el formato de diseño de alto nivel y la estrategia de integración.

El líder de desarrollo se encargará de inspeccionar la matriz de trazabilidad, usando el procedimiento de revisión por pares, y registrará los datos de tamaño, tiempo y defectos, en el sistema ICEBERG (Expert Information SAS, 2016).

7. Línea base del diseño

En este proceso el gerente del proyecto da aviso al administrador de la configuración cuando el diseño de alto nivel, la estrategia de integración y la matriz de trazabilidad, tengan una nueva versión aprobada. El administrador de la configuración toma documentos del repositorio diario y los sube al repositorio en línea base del proyecto, y notifica al gerente de este (Expert Information SAS, 2016).

45

8. Fin de ciclo

Seguir el procedimiento de revisiones mayores, identificando propuestas de mejora y generando los PIPs (Expert Information SAS, 2016).



Revisiones mayores








7.3.4.5 Fase de implementación

Como se explicó anteriormente en la sección 7.3.1, en esta fase se realizan todas las actividades relacionadas a la programación e implementación del proyecto. Para ello la empresa realiza seis procesos, los cuales se muestran en el Anexo 25. A continuación, se realiza la descripción de cada proceso que compone la fase de implementación.

46

Implementación

El objetivo de este proceso es guiar al ingeniero de software en la producción de componentes de alta calidad del sistema. Para ello, este utiliza las inspecciones, implementadas previamente en el sistema ICEBERG (Expert Information SAS, 2016).

En el Anexo 26, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de implementación se encuentran nueve subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Identificación de componentes y sus actividades

Los desarrolladores deben revisar detalladamente los documentos de requerimientos (SRS), casos de uso (si el documento fue generado) y diseño de alto nivel (HLD). Con base en ellos, se genera la estimación del componente, basado en métricas y datos históricos disponibles. Además, se determinan los componentes (conjunto de clases y desglose de actividades) y se registran en el sistema ICEBERG (Expert Information SAS, 2016).

2. Diseño detallado

Los desarrolladores deben de documentar el diseño detallado y registrar la referencia del diseño detallado de cada función en la matriz de trazabilidad para los componentes o productos. Cuando aplique, para el diseño detallado identifica alternativas aplicables, las evalúa y las documenta. En el caso del componente, debe de seleccionar entre construir, comprar o reutilizar, utilizando el procedimiento de selección diseñado previamente por la organización y debe de documentar la decisión tomada (Expert Information SAS, 2016).

3. Inspección del diseño detallado

El líder de desarrollo realiza la inspección del diseño detallado del producto acorde a un procedimiento de revisión establecido previamente por la organización. Los resultados obtenidos de la inspección deben de ser registrados en el sistema ICEBERG. Además, el desarrollador corregirá los defectos encontrados y actualizará el formato de diseño detallado del producto (Expert Information SAS, 2016).

4. Codificación

Los desarrolladores deben de producir el código fuente de los componentes y compilar el código hasta que este compile sin errores (Expert Information SAS, 2016).

5. Pruebas unitarias

Los desarrolladores deben realizar las pruebas utilizando una lista de verificación previamente definida por la organización, con el objetivo de garantizar el funcionamiento correcto con el cual el código debe de cumplir para ser liberado (Expert Information SAS, 2016).

47

6. Inspección de código

El líder de desarrollo debe de realizar la inspección general del código, registrar en el sistema ICEBERG las funcionalidades criticas detectadas para el proyecto, realizarle una re-inspección a las funcionalidades críticas que fueron detectadas y registrar nuevamente los resultados encontrados. Por su parte, el desarrollador será el encargado de corregir los defectos encontrados por el líder de desarrollo (Expert Information SAS, 2016).

7. Entrega de componentes o módulos completos

El equipo de desarrollo entregará el módulo a la persona encargada de este cuando se finalice la implementación del componente; además introducirán los componentes o módulos en el sistema de administración de la configuración y el administrador de la configuración se encargará de desplegarlos en ambiente de pruebas (Expert Information SAS, 2016).

8. Línea base del código

Cuando el diseño detallado del producto tenga una nueva versión aprobada el gerente del proyecto notifica al administrador de la configuración. Por otro lado, el líder de desarrollo notifica al administrador de la configuración cuando los componentes desarrollados tienen una nueva versión para liberar a pruebas de aceptación (Expert Information SAS, 2016).

9. Fin de ciclo

Los desarrolladores continúan con el proceso de revisiones mayores, de tal forma que puedan identificar propuestas de mejora, generando los PIPs y conduciendo un cierre para asegurar que todo el trabajo ha sido concluido y todos los datos registrados de forma apropiada (Expert Information SAS, 2016).



Revisiones mayores




48





7.3.4.6 Fase de implantación

De acuerdo a lo explicado anteriormente en la sección 7.3.1, en esta fase se realizan todas las actividades concernientes a las pruebas, implantación y cierre del proyecto. Para ello la empresa realiza veintidós procesos, los cuales se muestran en el Anexo 27. A continuación, se realiza la descripción de cada proceso que compone la fase de implantación.

Pruebas de despliegue

Este proceso tiene como objetivo verificar que el despliegue de los componentes del producto funcione correctamente en el ambiente de prueba de la organización y en el ambiente del cliente. Este proceso es desarrollado por el equipo de desarrollo y equipo de pruebas.

En el Anexo 28, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de despliegue se encuentran cinco subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Despliegue a ambiente de pruebas

Este se realiza cuando los desarrolladores hayan realizado las pruebas unitarias y revisado por medio de la lista la verificación que el código funcione correctamente y cumpla con los requerimientos mínimos antes de ser liberado. Para el despliegue a ambiente de pruebas se debe aplicar el procedimiento establecido para: actualizar la estrategia de integración, crear los procedimientos de instalación e integrar los componentes en un sistema funcional para pruebas (Expert Information SAS, 2016).

2. Pruebas de integración y pruebas funcionales

El equipo de pruebas aplica el procedimiento establecido para: actualizar el plan de pruebas y hacer las correcciones necesarias; asegurar que la integración y las funcionalidades estén completas y correctas; aplicar las pruebas de integración y pruebas funcionales; devolver a desarrollo los productos defectuosos; y entregar el producto integrado a pruebas de sistema.

49

Así mismo, este procedimiento solo se realiza en caso de que se haya especificado dentro del plan de pruebas. Adicionalmente se debe considerar si la funcionalidad que se desea probar involucra pruebas de componentes previas a la prueba de esta (Expert Information SAS, 2016).

3. Pruebas de sistema

El equipo de pruebas debe aplicar el procedimiento establecido para: actualizar el plan de pruebas de sistemas y hacer las correcciones necesarias; aplicar las pruebas al sistema; devolver a desarrollo los productos defectuosos y entregar el sistema probado para uso y aceptación del usuario. Este procedimiento se realiza siempre y cuando se halla especificado en el plan de pruebas (Expert Information SAS, 2016).


El equipo de pruebas actualiza el sistema de administración de la configuración con la documentación generada en la ejecución de las pruebas de integración, funcionales y de sistema (Expert Information SAS, 2016).

5. Fin de ciclo

En este último proceso el equipo de pruebas y el de desarrollo se encargan de seguir el procedimiento de revisiones mayores, identificando propuestas de mejora y generando los PIPs (Expert Information SAS, 2016).

Despliegue a ambiente de pruebas

Este proceso tiene como propósito renovar las estrategias de integración, establecer procedimientos de instalación, integrar diferentes componentes en un sistema funcional para la realización de pruebas, desarrollar el despliegue del producto en un ambiente de pruebas o en un ambiente requerido por el cliente y actualizar el ambiente del producto cuando se realicen cambios o correcciones sobre este. Dentro de este proceso se desarrollan inspecciones que se enmarcan en el sistema ICEBERG (Expert Information SAS, 2016).

En el Anexo 29, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de despliegue a ambiente de pruebas se encuentran seis subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Inspección de estrategia de integración

El equipo de desarrollo verifica si todos los componentes del producto han sido incluidos, validar si la secuencia de integración es correcta y actualizar la estrategia de integración a medida que se corrigen defectos y se realizan cambios sobre esta. Para realizar la inspección se utiliza una lista de verificación definida previamente por el equipo de trabajo (Expert Information SAS, 2016).

50

2. Manual de instalación

Permite desarrollar los procedimientos necesarios para la instalación de un producto, tomando en cuenta: versiones de productos requeridos, pre-requisitos de instalación, procedimiento detallado de instalación y procedimientos en caso de encontrarse con fallas en la instalación. La documentación de este proceso es realizada por el líder de desarrollo (Expert Information SAS, 2016).

3. Inspección manual de instalación

El arquitecto de software realiza la inspección del manual de instalación de acuerdo a un procedimiento de revisión establecido previamente y se registran los resultados de la revisión en el sistema ICEBERG (Expert Information SAS, 2016).

4. Integración

Para desarrollar este proceso el equipo de desarrollo se asegura de que todos los componentes de un producto sean entregados de acuerdo a la secuencia de integración establecida en la estrategia de integración que ha sido previamente definida; luego se garantiza que los componentes sean revisados y probados antes de ser enviados a integración; posterior a ello se recompilan los componentes a partir de la línea base del producto; se valida que el ambiente de integración esté disponible; se completa el formato de verificación previo a integración y finalmente se realiza la integración de los componentes en el producto de acuerdo a la estrategia de integración (Expert Information SAS, 2016).

5. Despliegue a ambiente de pruebas

Inicialmente el administrador de la configuración revisa el formato de verificación previo a la integración, genera versión de la aplicación con los componentes especificados en el formato y aplica la versión de la aplicación en el ambiente de pruebas (Expert Information SAS, 2016).

6. Inspección de la integración

El líder de desarrollo realiza una prueba de integración, de tal forma, que se garantice que los componentes desplegados e integrados en la aplicación están funcionando correctamente. Esto con el fin de validar que durante la integración no se hayan cometido errores y que todos los componentes hayan sido incluidos. En el caso en el que se encuentren defectos que no se salen del alcance del líder de desarrollo este los corrige, de lo contrario, el defecto se le entrega al equipo de desarrollo para ser corregido. Además, los errores detectados deberán ser enviados por correo electrónico a los interesados y si es necesario se debe actualizar la estrategia de integración, el despliegue a ambiente de pruebas y el repositorio con el nuevo producto integrado (Expert Information SAS, 2016).

51

Pruebas de integración

La finalidad de este proceso es actualizar el plan de pruebas de integración y realizar las correcciones pertinentes; asegurar que la integración se haya realizado completamente; aplicar las pruebas de integración; devolver a desarrollo los productos defectuosos; y finalmente, entregar el producto integrado a pruebas de sistema (Expert Information SAS, 2016).

En el Anexo 30, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de pruebas de integración y funcionales se encuentran nueve subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Diseño de casos de prueba

Para este procedimiento, el equipo de pruebas, una vez elaborado y aprobado el plan de pruebas, debe iniciar con las siguientes actividades: analizar toda la documentación del sistema, tal como especificaciones de requisitos, especificaciones de casos de uso, arquitectura del sistema, diseños, manuales de usuario y manuales técnicos si estos existen; realizar la creación de cada caso de prueba por medio de la herramienta TeamSystem como se encuentra explicado en el estándar manual de creación y ejecución de casos de prueba (Expert Information SAS, 2016).

2. Ejecución pruebas de integración y pruebas funcionales

En este procedimiento el equipo de pruebas debe definir los datos de prueba y seguir el plan de pruebas y los casos de prueba definidos. Luego, estos deben registrar los resultados de cada caso de prueba en el TeamSystem, como se encuentra en el estándar establecido (Expert Information SAS, 2016).

3. Corrección de no conformidades

Durante este proceso, el equipo de desarrollo se encarga de corregir las no conformidades encontradas en las pruebas de integración y funcionales, y deben volver a realizar los pasos 4, 5 y 6 del procedimiento de despliegue a ambiente de pruebas (Expert Information SAS, 2016).

4. Pruebas de Re-Testing

En este proceso, el equipo de pruebas ejecuta las pruebas de re-testing a las correcciones de las no conformidades encontradas. De este modo, se registran los resultados en cada caso de prueba en el TeamSystem, como se explica en el estándar establecido. Así mismo, se deben registrar en el TeamSystem las nuevas no conformidades encontradas, como se explica en el estándar establecido por la organización (Expert Information SAS, 2016).

52

5. Pruebas de regresión

Para este proceso el equipo de pruebas se encarga de ejecutar las pruebas de regresión, en las cuales los defectos encontrados se registran en el TeamSystem, como se explica en el estándar establecido, y una vez solucionados dichos problemas se debe volver a realizar el proceso de corrección de no conformidades. Una vez las pruebas de regresión se realicen de manera satisfactoria, se debe proseguir al siguiente proceso (Expert Information SAS, 2016).

6. Resumen de datos de las pruebas

En este proceso los analistas de pruebas se encargan de completar el registro de las no conformidades y el líder de calidad se encarga de hacer los informes de prueba con el formato establecido, al finalizar la última iteración de pruebas de cada uno de los Sprints (Expert Information SAS, 2016).

7. Manual de usuario

En este paso, el documentador técnico y/o los analistas de calidad se encargan de realizar el manual de usuarios para el cliente de acuerdo al formato definido para este.

El manual de usuario será realizado una vez terminada la última iteración de pruebas de cada uno de los Sprints (Expert Information SAS, 2016).

8. Inspección manual de usuario

Para este proceso el líder de calidad se encarga de inspeccionar el manual de usuario usando el procedimiento de revisión establecido. Luego, los datos de la inspección se registran en el sistema ICEBERG, y el documentador técnico o analistas de calidad se encargan de corregir los defectos encontrados (Expert Information SAS, 2016).

9. Entrega al cliente del producto probado

Finalmente, el líder de calidad genera el paquete de entrega al cliente, de acuerdo a la plataforma de desarrollo. Luego, se debe actualizar el sistema de administración de la configuración, lo que incluye etiquetas de versión, números de control y ubicaciones de los cambios, y datos de componentes integrados. Posteriormente, se debe confirmar la recepción e instalación adecuada del paquete entregado y, por último, se debe entregar el manual de usuarios, certificado de calidad y garantía de calidad (Expert Information SAS, 2016).

Pruebas de sistema

El propósito de este proceso es ayudarle al equipo de pruebas junto con el equipo de desarrollo a actualizar el plan de pruebas y realizar las correcciones pertinentes; aplicar las pruebas de sistema; devolver a desarrollo los productos defectuosos; y entregar el sistema probado para la aceptación y utilización del cliente. Este proceso se realiza por medio del uso de

53

Team System y las inspecciones implementadas en el sistema ICEBERG (Expert Information SAS, 2016).

En el Anexo 31, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de pruebas de sistema se encuentran seis subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

1. Ejecución de pruebas de sistema

Para este paso, el equipo de pruebas selecciona los casos de pruebas que van a ser ejecutados de los diseños generados previamente. Luego, estos se encargan de definir los datos de pruebas. Se debe entonces seguir el plan de pruebas y los casos de pruebas definidos, y se debe registrar los resultados obtenidos por cada caso de pruebas en el TeamSystem, como se explica en el estándar establecido. Finalmente, se procede a reportar las no conformidades encontradas en el TeamSystem, como se explica en el estándar establecido (Expert Information SAS, 2016).

2. Corrección de no conformidades

En este paso el equipo de desarrollo se encarga de corregir las no conformidades encontradas en las pruebas del sistema y se debe volver a realizar el procedimiento de despliegue de ambiente de pruebas (Expert Information SAS, 2016).

3. Pruebas de Re-Testing

Durante este paso, el equipo de pruebas ejecuta las pruebas de re-testing a las correcciones de las no conformidades que se encontraron. Luego, se registran los resultados en cada caso de prueba en el TeamSystem, como se explica en el estándar establecido. Así mismo, se registran las nuevas no conformidades en el TeamSystem, tal como se encuentra en el estándar establecido (Expert Information SAS, 2016).

4. Pruebas de regresión

Para este proceso, el equipo de pruebas ejecuta las pruebas de regresión, y se reportan los defectos encontrados en el TeamSystem, tal como se explica en el estándar establecido. Una vez solucionados estos defectos, se volverá a realizar el paso de re-testing. Y posteriormente, cuando las pruebas de regresión se completan satisfactoriamente, se continua al siguiente paso (Expert Information SAS, 2016).

5. Resumen de datos de las pruebas

Para este paso, los analistas de la calidad se encargan de completar el registro de las no conformidades y el líder de calidad se encarga de generar los informes de pruebas en el formato establecido, al finalizar la última iteración de pruebas de cada uno de los Sprints.

54

Si no se cumple con las métricas de calidad establecidas para que el cliente reciba el producto, se deberá definir una estrategia de pruebas donde se defina que pruebas se realizarán nuevamente (Expert Information SAS, 2016).

6. Entrega al cliente del producto probado

Para este proceso, el líder de calidad se encarga de generar el paquete de entrega al cliente, de acuerdo a la plataforma de desarrollo. Luego, se debe actualizar el sistema de administración de la configuración, lo que incluye etiquetas de versión, números de control, ubicaciones de los cambios, y datos de componentes integrados. Posteriormente, se debe confirmar la recepción e instalación adecuada del paquete entregado y, por último, se debe entregar el manual de usuario, certificado de calidad y garantía de calidad (Expert Information SAS, 2016).

Revisiones mayores






Cierre del proyecto

Este proceso tiene como finalidad guiar al gerente del proyecto en el cierre del proyecto. Para ello se hace uso del sistema ICEBERG en donde se documentan las propuestas de mejora, las mejores prácticas y lecciones aprendidas (Expert Information SAS, 2016).

En el Anexo 32, se detalla por medio de un diagrama de funciones cruzadas los sub-procesos y los roles encargados de realizarlos. Dentro del proceso de cierre del proyecto se encuentran cinco subprocesos que a su vez contienen un procedimiento para realizarse. La descripción de cada sub-proceso será detallada a continuación.

55

1. Evaluación de la línea base

Durante este paso, el gerente del proyecto, con el apoyo del equipo del proyecto, evalúan que tan adecuado fue el proceso de administración, línea base del sistema y ambiente de desarrollo (Expert Information SAS, 2016).

2. Evaluación del plan

El gerente del proyecto junto con el equipo del proyecto, evalúan el desempeño del equipo, en lo que refiere a tamaño estimado del proyecto, recursos planeados y tiempo planeado vs real (Expert Information SAS, 2016).

3. Desempeño de la calidad

En este proceso el gerente del proyecto, junto con el equipo del proyecto, evalúan el desempeño del equipo en lo referente a calidad de productos generados. En particular, se revisa la eficacia de las inspecciones y pruebas (número de defectos, tiempo y tamaño del producto) (Expert Information SAS, 2016).

4. Evaluación del proceso

Para este proceso el gerente de proyecto, junto con el equipo asignado, evalúa los procesos usados en el proyecto, con el fin de: identificar problemas e inconvenientes de los procesos aplicados, sugerir mejoras y registrarlas en el sistema ICEBERG, e identificar y documentar las lecciones aprendidas y mejoras prácticas (Expert Information SAS, 2016).

5. Inspección final

Finalmente, el gerente del proyecto diligencia el formato establecido para comprobar que todos los aspectos se encuentran en conformidad (Expert Information SAS, 2016).

7.4 Comparación de los hallazgos encontrados contra los procesos documentados con el modelo de Rendimiento Organizacional propuesto en el CMMI DEV 1.3

Utilizando los hallazgos encontrados en la sección 7.3 se realizó la comparación de los procesos que actualmente desempeña la compañía contra el modelo CMMI DEV 1.3 para nivel 4, concretamente con la meta y prácticas específicas del proceso de rendimiento organizacional.

Por medio de este análisis comparativo, se encontró que la empresa actualmente no tiene definidos los objetivos de rendimiento de calidad, ni los objetivos de rendimiento de los procesos. Es por ello, que se encuentra que la empresa no cumple con la práctica de establecimiento de objetivos de rendimiento de calidad y procesos planteada por el CMMI DEV 1.3 en el proceso de rendimiento organizacional.

Igualmente, se halló que la organización no ha definido los procesos sobre los cuales se deben desarrollar las actividades de rendimiento organizacional. Es decir, que la organización no

56

cumple con la práctica de selección de procesos planteada por el CMMI DEV 1.3 para el proceso de rendimiento organizacional.

Así mismo, se evidenció que la compañía no ha establecido las medidas de rendimiento de los procesos los cuales, como se mencionó anteriormente, aún no han sido seleccionados. Por lo cual se puede afirmar, que la compañía no cuenta con la práctica de establecimiento de medidas del rendimiento del proceso planteada por el CMMI DEV 1.3 para el proceso de rendimiento organizacional.

Del mismo modo, se encontró que la firma no ha realizado el análisis y establecimiento de las líneas base del desempeño de los procesos. A partir de ello, se puede deducir que la empresa no cumple con la práctica de análisis y establecimiento de líneas base para el desempeño del proceso planteada por el CMMI DEV 1.3 para el proceso de rendimiento organizacional.

Finalmente, después de todos los hallazgos mencionados, se llega a la conclusión que la empresa no cuenta con la práctica de establecimiento de modelos de desempeño del proceso, puesto que para contar con esta, se deben de realizar las cuatro prácticas mencionadas anteriormente y al no contar con ninguna de las anteriores, se concluye que hasta el momento la empresa no ha desarrollado actividades que le permitan contar con el proceso de rendimiento organizacional planteado por el CMMI DEV 1.3 y, por lo tanto, todos los procedimientos concernientes a este, serán desarrollados a lo largo de este documento.

7.5 Definición de la prioridad de los hallazgos encontrados

A partir de los hallazgos encontrados en el análisis comparativo realizado en la sección 7.4 se realiza la definición de prioridad de los mismos. Dado que se concluyó que la empresa no ha realizado actividades para la implementación del proceso de rendimiento organizacional, se decidió seguir las prácticas específicas planteadas por el CMMI DEV 1.3 para este proceso, pero en un orden alterno.

Por lo anterior, la primera práctica a implementar será la selección de procesos, sobre los cuales se desarrollará el proceso de rendimiento organizacional. Después, se realizará el establecimiento de las medidas del rendimiento del proceso. Seguida a esta práctica, se realizará el establecimiento de objetivos de rendimiento de calidad y procesos. Luego, se desarrollará el análisis y establecimiento de líneas base para el desempeño del proceso y todo lo anterior, permitirá realizar la definición del proceso de rendimiento organizacional con el establecimiento de modelos de desempeño del proceso.

7.6 Realización del plan de acción

En esta sección se realiza la descripción de las actividades que fueron desarrolladas para realizar la propuesta del proceso de rendimiento organizacional, además, se especifica la secuencia en la cual fueron realizadas, con sus respectivos alcances y cronograma.

57

Definición de actividades específicas

A partir del análisis de la situación actual de la compañía, documentado en la sección 7.3, se decidieron realizar siete actividades específicas, las cuales se describen y ordenan a continuación.

1. Revisión de las prácticas de acuerdo con la literatura de CMMI DEV 1.3 para el proceso de rendimiento organizacional.

2. Revisión de documentación de implementaciones del proceso de rendimiento organizacional en otras empresas.

3. Definición de los procesos y actividades que se deben implementar para cumplir con las prácticas faltantes.

4. Presentación de procesos ante la gerencia de Expert Information SAS. 5. Modificación en los procesos acorde a las sugerencias de la gerencia de Expert Information

SAS. 6. Presentación a los empleados de las áreas involucradas en los nuevos procesos. 7. Entrega de documentación final para implementación.

Definición del cronograma del plan de acción

A partir de la definición de las actividades específicas, realizado previamente en la sección 7.6.1, se propuso el cronograma de trabajo. Ver Anexo 33.

58

8. Caracterización y definición de los procesos organizacionales, que son susceptibles de estandarización y mantenimiento según el proceso de Rendimiento Organizacional del

modelo CMMI DEV 1.3 nivel 4.

En esta sección se realiza la descripción de todas las actividades concernientes al desarrollo del segundo objetivo específico.

8.1 Identificación de los procesos susceptibles de estandarización y mantenimiento con base en los hallazgos y en las reuniones de trabajo propuestas en el objetivo específico 1

En una reunión realizada con la gerencia de Expert Information SAS y con los líderes de los proyectos que estaban en vigencia en la compañía en ese momento se realizó una evaluación general de las seis fases que actualmente conforman el desarrollo de un producto de software. Dicha evaluación se llevó a cabo por medio del juicio de expertos (Gerentes de la compañía y líderes de los proyectos). A partir de esta se generó la priorización de los procesos en los cuales es de mayor importancia medir el desempeño y como consecuencia, se decidió que los indicadores de rendimiento organizacional se desarrollarán dentro de los procesos de requerimientos, diseño e implementación, descritos anteriormente en la sección 7.3.1.

En la compañía Expert Information SAS existen tres ambientes en la ejecución de todos los proyectos de desarrollo de software.

1. Ambiente de desarrollo: Es donde se trabaja la implementación y el análisis de los sistemas de información.

2. Ambiente de pruebas: Es donde el equipo de calidad hace las pruebas por inspección.

3. Ambiente pre productivo: Es el ambiente donde el cliente hace las pruebas de aceptación antes de llevarse el producto a sus propios ambientes.

Las etapas seleccionadas para la implementación de los indicadores de medición se desenvuelven en el ambiente de desarrollo.

8.2 Caracterización y documentación de los procesos susceptibles de estandarización y mantenimiento

Como se mencionó anteriormente en la sección 8.1 se seleccionaron las fases de requerimientos, diseño e implementación para realizar las mediciones de rendimiento organizacional. A continuación, se realiza una breve descripción de cada fase.

59

Fase de requerimientos

En esta fase se realiza la toma de requerimientos al cliente, con el objetivo de conocer detalladamente las características del producto y lo que se desea obtener de este. Para más información sobre esta fase, revisar la sección 7.3.4.3.

Fase de diseño

En esta fase se desarrolla el diseño del producto, en lo concerniente a la parte técnica y al aspecto de la interfaz del usuario detallado por el cliente en la fase de requerimientos. Para más información sobre esta fase, revisar la sección 7.3.4.4.

Fase de implementación

En esta fase el equipo de desarrolladores se encarga de realizar la programación del producto solicitado por el cliente. Así como las pruebas necesarias, para comprobar que este funcione correctamente. Para más información sobre esta fase, revisar la sección 7.3.4.5.

60

9. Definición de indicadores de rendimiento para los diferentes procesos de la organización con base en el proceso de Rendimiento Organizacional del modelo CMMI

DEV 1.3 nivel 4

En esta sección se realiza la descripción de todas las actividades concernientes al desarrollo del tercer objetivo específico.

9.1 Fase de requerimientos

Como se mencionó anteriormente, la fase de requerimientos fue seleccionada para realizar la definición y diseño de los indicadores de rendimiento. Esta fase se compone de seis procesos, los cuales fueron estudiados junto con la gerencia de Expert Information SAS, con el fin de encontrar aquellos donde es más relevante medir el desempeño del proyecto.

Identificación de los puntos de control y medición en los procesos de acuerdo con el proceso de Rendimiento Organizacional propuesto en el modelo CMMI DEV 1.3

En reunión con la gerencia de Expert Information SAS se encontró que, en comparación con los otros procesos, hay un mayor interés por medir el rendimiento en el proceso de requerimientos. Lo anterior debido a que, este proceso es la base en el desarrollo de un proyecto de software y es aquí donde se presentan comúnmente una mayor cantidad de errores en el momento de realizar las especificaciones de requerimientos que satisfagan las necesidades de los clientes. Además, se espera que al realizar las mediciones de rendimiento en este proceso se detecten y corrijan los errores a tiempo, de tal forma que las actividades desarrolladas en los procesos siguientes a este se desenvuelvan sin la necesidad de volver al proceso de requerimientos a corregir errores pasados. En el Anexo 34 se señala el proceso seleccionado.

Definición de las métricas

Se realizó una revisión documental de diversas fuentes bibliográficas, con el fin de encontrar métricas de rendimiento aplicables a la fase de requerimientos. Así mismo, se propusieron algunas métricas que se consideran significativas dentro de dicha fase. Dentro de las métricas encontradas y las propuestas, se seleccionaron las más significativas, ocho en total, las cuales tienen mayor impacto en el desempeño de la fase de requerimientos.

En el Anexo 35, se indican los subprocesos en los cuales se van a desarrollar las mediciones de los indicadores de rendimiento dentro del proceso de requerimientos. A continuación, se explican las abreviaturas utilizadas en dicho gráfico:

• R.1: Tiempo empleado en entrevistas con el cliente/ Cantidad de requerimientos.

• R.2: Tiempo empleado en documentar los requerimientos/ Cantidad de pasos en los guiones de casos de uso detallados.

61

• R.3: Esfuerzo de evaluación/ Páginas del documento.

• R.4: Esfuerzo de preparación.

• R.5: Errores mayores detectados/ Cantidad de requerimientos.

• R.6: Conformidad con los requerimientos.

• R.7: Esfuerzo de repetición/ Cantidad de correcciones.

• R.8: Densidad del error.

Definición de los requerimientos de información histórica para el establecimiento de las métricas y los indicadores de rendimiento

Dentro de la fase de requerimientos, específicamente en el proceso de requerimientos, se desarrollaron ocho indicadores para medir el rendimiento de este. Para establecer las líneas base de estos indicadores se requiere la información histórica del último año, sin embargo, la compañía no ha almacenado suficiente información para establecer las bases de los indicadores; razón por la cual para el establecimiento de estos valores se realizó una reunión con los líderes (Gerentes y líderes de proyectos) de la compañía y por medio de esta se llegó a un acuerdo de los niveles de aceptación iniciales para los indicadores. Se espera posteriormente con la información recabada ir ajustando los indicadores de acuerdo al desempeño obtenido en el tiempo con las nuevas mediciones.

Para desarrollar los indicadores de rendimiento se requiere la siguiente información sobre la fase de requerimientos: tiempos empleados en entrevistas con clientes, cantidades de requerimientos tomados en entrevistas, tiempos empleados en documentar los requerimientos, cantidades de pasos escritos en los guiones de los casos de uso detallados, cantidades de horas-hombre empleadas en revisiones, cantidades de páginas revisadas durante inspecciones, cantidades de horas-hombre empleadas en revisión de documentos como preparación para reuniones, cantidades de errores mayores detectados, cantidades de requerimientos documentados, cantidad de requerimientos desaprobados por el cliente, cantidades de horas-hombre empleadas en correcciones.

Definición del procedimiento de medición y toma de datos de los indicadores

Se realizó un análisis del proceso de requerimientos y de los indicadores que se proponen implementar en este. Lo anterior, permitió identificar el procedimiento de medición y toma de datos para el cálculo de los indicadores, estos son descritos a continuación.

9.1.4.1 R1: Tiempo empleado en entrevistas con el cliente/ Cantidad de

requerimientos

Este indicador corresponde al cociente entre el tiempo empleado en entrevistas con el cliente y la cantidad de requerimientos (sobre el producto que se va a desarrollar) recogidos durante las entrevistas. Por tanto, este indicador permite ver el rendimiento del trabajo desarrollado por el analista funcional en la parte de recolección de los requerimientos, dado que

62

permite obtener el tiempo promedio que le toma al analista concertar uno de los requerimientos del cliente y de este modo saber cuan efectiva es la comunicación entre estos y como se aprovecha el tiempo durante las entrevistas.

Este indicador se medirá durante la ejecución del subproceso de obtención de los requerimientos, como se puede observar en el Anexo 35. Para medir este indicador, el analista funcional deberá revisar la hora de inicio y fin de la entrevista en el dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros) y posteriormente deberá consignar estos datos junto con la cantidad de requerimientos recolectados durante la reunión en el sistema ICEBERG, el cual se encargará de realizar el cálculo del indicador de la sesión.

Dentro del sistema ICEBERG se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan realizar las comparaciones pertinentes. Un prototipo de la pantalla de ingreso de los datos se puede observar en el Anexo 36.

Este indicador se medirá por reunión, con el objetivo de analizar el rendimiento del analista funcional en cada sesión, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.1.4.2 R.2: Tiempo empleado en documentar los requerimientos/ Cantidad de pasos

en los guiones de casos de uso detallados

Este indicador corresponde al cociente entre el tiempo empleado en documentar los requerimientos y la cantidad de pasos descritos en todos los guiones2 de los casos de uso detallados documentados para cada requerimiento. Este indicador permite analizar el rendimiento del trabajo desarrollado por el analista funcional durante el proceso de escritura de los requerimientos. Dicho cociente permite conocer la velocidad a la que el analista funcional documenta todo lo concerniente a los requerimientos extraídos durante las reuniones con el cliente, esta actividad es de gran importancia debido a que sin dicho documento no es posible desarrollar los subprocesos posteriores al proceso de requerimientos.

Este indicador se toma durante el desarrollo del subproceso de especificación de los requerimientos, tal como se puede observar en el Anexo 35 y para su medición, el analista funcional deberá tomar el tiempo durante cada una de las sesiones de documentación de requerimientos, sesiones que se desarrollan posterior a las reuniones con el cliente destinadas a la toma de requerimientos. Durante dichas sesiones, el analista funcional debe consignar toda la información extraída al cliente en lo referente a los requerimientos del producto en el formato de

2 Según Pressman (2011), un guion se define como “una secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación” (p.579).

63

casos de uso detallados, y se debe de llenar uno de estos formatos por cada uno de los requerimientos especificados.

Al inicio de cada sesión de documentación, el analista funcional deberá registrar la hora de inicio, observando esta en cualquier dispositivo que tenga a su alcance (reloj, teléfono, computador, entre otros), y así mismo debe registrar la hora de finalización de la sesión junto con el número de pasos documentados en todos los casos de uso detallados. Finalmente, el analista deberá ingresar dichos datos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador de la sesión.

Dentro del sistema ICEBERG se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan realizar las comparaciones pertinentes.

Este indicador se medirá por sesión, con el objetivo de analizar el rendimiento del analista funcional en cada sesión, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.1.4.3 R.3: Esfuerzo de evaluación/Páginas del documento

Este indicador corresponde al cociente entre la cantidad de horas empleadas en la revisión de un documento por parte del encargado de dicha tarea y la cantidad de páginas revisadas durante dicho tiempo. A través de este indicador se puede saber la velocidad a la que el encargado de la inspección realiza la tarea de revisión del documento. De este modo, se puede conocer el tiempo dedicado a la revisión durante el desarrollo del proceso de requerimientos, y así mismo se puede medir el desempeño del encargado de la revisión.

Este indicador se mide en los subprocesos de inspección del SRS e inspección del plan de pruebas, como se puede observar en el Anexo 35, y los encargados de la revisión son el líder funcional y el gerente del proyecto, respectivamente. En el caso del subproceso de inspección del SRS, el líder funcional realizará una sesión de revisión del documento del SRS, una vez que este haya sido culminado por el analista funcional durante el subproceso de especificación de requerimientos. Para su medición, el analista funcional deberá consignar la hora de inicio de la sesión de revisión, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberá consignar el tiempo de culminación de la sesión de revisión y el número de páginas del documento revisado. Si la sesión de revisión se divide en varias partes, el líder funcional deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de revisión calculado como la suma de todos los tiempos de las sesiones individuales y este será dividido por el número de páginas del documento revisado.

64

En el caso del subproceso de inspección del plan de pruebas, el gerente del proyecto deberá seguir un procedimiento similar al seguido por el líder funcional, registrando el tiempo de inicio y fin de la inspección, y la cantidad de páginas que contiene el documento sometido a revisión. Cabe aclarar, como se mencionó anteriormente, si la sesión de revisión se divide en varias partes, el líder funcional deberá consignar el tiempo de inicio y fin de cada una de las sesiones, entonces el esfuerzo de revisión será calculado como la suma de todos los tiempos obtenidos en las sesiones individuales. La sesión de revisión para el gerente del proyecto se realiza una vez que el documento del plan de pruebas este completamente finalizado por el líder de calidad durante el subproceso de plan de pruebas.

En todos los casos anteriores, los encargados de la revisión deben registrar los datos obtenidos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador. Dentro de este sistema, se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan realizar las comparaciones pertinentes.

Este indicador se medirá por documento (SRS y plan de pruebas), con el objetivo de analizar el rendimiento del inspector en cada revisión, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.1.4.4 R.4: Esfuerzo de preparación

Este indicador mide la cantidad de horas empleadas por el equipo de requerimientos en la planeación, preparación y revisión de todos los documentos necesarios antes de que se lleven a cabo las reuniones con el cliente para la discusión de los requerimientos del producto. Este indicador permite saber cuánto tiempo utiliza el equipo de requerimientos en preparar todo lo pertinente para dar inicio a la recolección de los requerimientos del proyecto, por lo que conocerlo le permite saber a la compañía si se ha mejorado el rendimiento respecto a proyectos pasados.

Este indicador se toma al finalizar el subproceso de plan de recolección de requerimientos, y debido a que este procedimiento se realiza de igual forma para todos los proyectos de la compañía, no es necesario operarlo con otros datos de la fase, como se ha hecho con algunos indicadores anteriores, sino que es posible comparar directamente los esfuerzos de preparación para distintos proyectos, por lo que tener un mayor o menor valor para este indicador da una idea de cómo se aprovecha el tiempo antes de pasar al subproceso de obtención de los requerimientos.

Para medir este indicador, se pedirá al equipo de requerimientos tomar el tiempo de inicio durante cada una de sus sesiones de trabajo, para lo cual deberán observar el tiempo en cualquier

65

dispositivo que tengan a su disposición (reloj, teléfono, computador, entre otros), y del mismo modo deberán registrar la hora de finalización de la sesión. Posteriormente, un miembro del equipo deberá registrar estos datos en el sistema ICEBERG, de tal forma que el indicador será la suma de la duración de las sesiones. Si algún miembro del equipo desarrolla una sesión individual, también deberá agregar la duración de la sesión en el sistema ICEBERG, para que este compute la información con el indicador.

Dentro del sistema ICEBERG se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el cual es la suma de los tiempos de cada sesión de trabajo, ya sea del equipo o individual, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan y realizar las comparaciones pertinentes.

Este indicador como se mencionó anteriormente, se medirá al finalizar el subproceso de plan de recolección de requerimientos, como se puede observar en el Anexo 35, con el objetivo de analizar el rendimiento del equipo de requerimientos en cada proyecto, de tal forma que se puedan tomar acciones correctivas en futuros proyectos, en base al resultado obtenido en el desarrollo de los proyectos actuales y de esta forma mejorar el rendimiento.

9.1.4.5 R.5: Errores mayores detectados/Cantidad de requerimientos

Este indicador corresponde al cociente entre la cantidad de errores encontrados en la revisión del documento del SRS y la cantidad de requerimientos documentados en este. A través de este indicador, es posible medir el desempeño del analista funcional, quien es responsable en todo momento de escribir, modificar y realizar correcciones al documento del SRS, por lo que un alto número de errores indica una falencia en las habilidades del analista funcional, ya sea esta falencia en la manera en que este interpreta los requerimientos obtenidos del cliente, o en la manera en que este redacta el documento del SRS. En cualquiera de los casos anteriores, la existencia de errores produce un retraso en la ejecución del proceso de requerimientos, dado que es necesario una nueva revisión y corrección de los errores, así como una nueva solicitud de aprobación del cliente al nuevo documento redactado, por lo que en todo momento se desea que el número de errores encontrados en el documento sea cero.

La empresa clasifica los errores encontrados en el documento, en dos tipos: errores mayores y errores menores. Los errores menores son errores pequeños dentro del texto, que no afectan drásticamente al proyecto y por lo tanto su corrección no requiere mucho tiempo. Por otro lado, los errores mayores son errores que afectan significativamente el desarrollo del proyecto y su corrección demanda una cantidad de tiempo significativa, que puede retrasar la ejecución de procesos posteriores.

66

En este documento no se planteará la medición de los errores menores, puesto que estos son de bajo impacto y no afectan significativamente el desarrollo de procesos posteriores, razón por la cual la empresa ha decidido implementar su medición en una fase posterior y utilizando otra metodología. Por lo anterior, este indicador se utilizará solo para realizar mediciones de la cantidad de errores mayores por cantidad de requerimientos.

Este indicador se mide al finalizar los subprocesos de inspección del SRS y correcciones, los responsables de realizar la medición son el líder funcional y el analista funcional, respectivamente, como se observa en el Anexo 35. En el primer caso, el líder funcional recibe la primera versión del documento del SRS completamente redactado por parte del analista funcional en el subproceso de especificación de los requerimientos, y debe inspeccionar este documento con el fin de detectar los errores en el mismo. Para realizar la medición, se pedirá al líder funcional consignar la cantidad de errores mayores encontrados en el documento del SRS en el sistema ICEBERG, una vez que haya concluido la revisión. Posteriormente, el documento deberá ser corregido por el analista funcional, y enviado al subproceso de solicitar aprobación del cliente.

En el segundo caso, el analista funcional debe corregir nuevamente el documento del SRS de acuerdo a los errores resaltados por el cliente durante el subproceso de solicitar la aprobación de este, y antes de realizar estas correcciones, se debe encontrar cuales de los errores resaltados corresponden a errores mayores. Una vez identificados los errores, el analista funcional consignará la cantidad de errores mayores encontrados en el documento en el sistema ICEBERG, y procederá posteriormente con la corrección de los errores del documento. Este procedimiento se realizará en cada una de las sesiones de corrección, para todas las veces que el documento no haya sido aceptado por el cliente durante el subproceso de consultar aprobación del cliente. Una vez que el documento haya sido aceptado por el cliente, el sistema ICEBERG calcula el indicador de errores mayores, registrados anteriormente por el inspector. El indicador se calcula como la suma de todos los errores mayores encontrados durante cada una de las sesiones de corrección del documento dividido sobre la cantidad de requerimientos documentados.

Dentro del sistema ICEBERG se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema, a la plantilla del Balanced Scorecard, de tal forma que se puedan realizar las comparaciones pertinentes.

Errores menores

En todos los casos anteriores, se pedirá al líder funcional y al analista funcional que consideren como errores menores aquellos que se consignan a continuación:

67

Requerimiento incompleto: Se define como aquel requerimiento cuya descripción es pobre o poco precisa, y es necesario ampliar los detalles de su redacción con el fin de proporcionar la información suficiente para su comprensión. Se considera este como un error menor debido a que su corrección solo requiere ampliar la información ya escrita en el documento, lo que corresponde en agregar o cambiar algunas líneas en este.

Requerimiento poco conciso: Se entiende como aquel requerimiento que es poco preciso en su redacción en tanto es muy extenso, difícil de leer, o difícil de interpretar. Se considera este como un error menor debido a que su corrección solo requiere resumir un poco el texto ya escrito o reescribirlo de una manera más clara, y no representa esto una pérdida del tiempo invertido en la escritura.

Requerimiento no modificable: Se define como aquel requerimiento cuya redacción no posibilita una posterior modificación por parte del cliente, en caso de que este desee cambiar las características del producto que desea. Con lo anterior se hace referencia a los casos en los que la forma en la que describe el requerimiento hace que sea imposible cambiar algún detalle de este, pues se incurriría en un error grave, ya sea esto debido a que se volvería contradictorio con otros requerimientos, o perdería su sentido o se volvería redundante. Se considera este como un error menor pues su corrección solo requiere cambiar la forma en la que está redactado el requerimiento y su descripción, y así mismo, no representa esto una pérdida del tiempo invertido en la escritura de este.

Requerimiento poco específico: Se entiende como aquel requerimiento que es poco específico en cuanto encierra varias funciones del sistema que deberían ser descritas como requerimientos distintos del proyecto. Un requerimiento poco específico no es detallado en su descripción, porque para explicarlo con más precisión es necesario dividirlo en partes cuya sola descripción corresponde con un requerimiento. Se considera este como un error menor pues su corrección requiere una ampliación del documento ya existente, y no representa un cambio muy drástico en la estructura del SRS.

Requerimiento no priorizado: Se define como aquel requerimiento del cual no se puede inferir su importancia dentro del proyecto, es decir, no se puede inferir si este es crítico, deseado u opcional dentro de la ejecución del proyecto. Este tipo de errores se considera como errores menores pues para su corrección basta con especificar con mayor detalle esta característica del proyecto.

Requerimiento no verificable: Se entiende como aquel requerimiento del cual no es posible inferir una regla para determinar cuando este se ha cumplido o no. Dentro de la descripción del requerimiento debe ser posible determinar los criterios de aceptación de este, para de este modo conocer el momento en que este se ha realizado. Este tipo de errores se consideran como menores debido a que es necesario revisar detalladamente la visión del proyecto para entender cuáles son los criterios de verificación, que posibiliten verificarlo ya sea por inspección, prueba o demostración.

68

Documento con errores de puntuación, ortografía u otro relacionado con la estructura del texto: Este tipo de errores son comunes y se resuelven en poco tiempo, por lo que se considera como errores menores. Cabe aclarar que errores en la estructura se refiere a títulos faltantes, palabras faltantes, y falta de coherencia en algunas frases que se pueden corregir fácilmente.

Errores mayores

En todos los casos anteriores, se pedirá al líder funcional y al analista funcional que consideren como errores mayores aquellos que se consignan a continuación:

Requerimiento innecesario: Se define como aquel requerimiento que es redundante o que no presenta una justificación clara acerca de por qué debe ser incluido dentro de la especificación del proyecto. Por tanto, si se elimina de la especificación de los requerimientos no se verá un cambio significativo en el funcionamiento del proyecto, de acuerdo a lo demandado por el cliente. Se considera este como un error mayor debido a que, aunque realizar su corrección no requiere de mucho tiempo, en tanto solo es necesario eliminarlo del documento del SRS, representa una pérdida del tiempo invertido en la redacción del requerimiento y ello afecta significativamente el rendimiento del proceso.

Requerimiento inconsistente: Se entiende como aquel requerimiento cuya realización entra en conflicto con otro requerimiento. Resolver este tipo de requerimientos demanda que se cambie la interpretación que se tiene del requerimiento para que este sea consistente con lo expresado por el cliente para su producto. Este error se considera como un error mayor debido a que requiere una modificación importante del documento del SRS en tanto es necesario modificar completamente la descripción de todo el requerimiento y esto afectaría significativamente el rendimiento del proceso.

Requerimiento no factible: Se define como aquel requerimiento que no es realizable pues no se cuenta con los recursos para llevarlo a cabo, ya sean estos de tiempo, presupuesto, u otras restricciones. Resolver este tipo de errores requiere una investigación profunda sobre la complejidad del requerimiento, y así mismo, una revisión extensiva del sistema, de modo que se pueda replantear el requerimiento. Por lo anterior, se consideran este tipo de errores como errores mayores pues su corrección demanda una cantidad de tiempo importante y por lo tanto afecta el rendimiento del proceso.

Requerimiento incorrecto: Se entiende como aquel requerimiento que no está acuerde a lo solicitado por el cliente para su producto. Este tipo de requerimientos representan una pérdida de tiempo en la redacción del documento, y su corrección consiste en eliminar completamente el requerimiento del documento del SRS. Debido a lo anterior, se considera este tipo de errores como errores mayores, puesto que el tiempo invertido en su redacción es improductivo y termina afectando el rendimiento del proceso.

Requerimiento ambiguo: Se define como aquel requerimiento que puede llevar a diferentes interpretaciones para distintos lectores. Este tipo de errores se deben a una mala

69

redacción del documento, por lo que se debe revisar la forma en la que está escrita la descripción del requerimiento y confrontarla con lo interpretado acerca de las necesidades del cliente para corregirlo. Se considera a estos errores como mayores debido a que conllevan un cambio en la especificación del requerimiento.

Requerimiento no rastreable: Se entiende como aquel requerimiento al que no se le puede asignar una función específica dentro del sistema. La especificación de los requerimientos debe estar organizada de tal forma que para cada función del sistema sea posible encontrar el conjunto de requerimientos que describen esta función. Cuando el documento no cumple esta característica se dice que contiene un requerimiento no rastreable, por lo que para su corrección es necesario cambiar toda la estructura del documento del SRS. Debido a lo anterior, se considera a este tipo de errores como errores mayores.

Documento incompleto: Se dice que el documento se encuentra incompleto en el sentido de los requerimientos, si a partir de todos los requerimientos que se encuentran en él especificados, no es posible inferir una visión global del sistema, visualizando entradas, salidas y todo su comportamiento para diferentes combinaciones de las entradas. Para corregir este tipo de errores es necesario replantear la visión general de toda la descripción, y encontrar los puntos débiles del documento, en lo que no se ha sido lo suficientemente específico o se han dejado vacíos que no permiten tener una idea general del sistema. Debido al extenso análisis que esto conlleva, se considera a este tipo de errores como errores mayores.

9.1.4.6 R.6: Conformidad con los requerimientos

Este indicador corresponde al cociente entre la cantidad de requerimientos corregidos por desaprobación del cliente y la cantidad de requerimientos totales documentados. Por lo tanto, este indicador permite ver el rendimiento del trabajo desarrollado por el analista funcional en la parte de obtención de requerimientos, puesto que permite analizar el porcentaje de requerimientos a los cuales se les realizó algún cambio dado que no fueron aprobados por el cliente. A continuación, se expresa el indicador:

�� =�� ó� ��

��

Este indicador se medirá después de finalizar el subproceso de correcciones, según se puede observar en el Anexo 35. Para medir este indicador el analista funcional deberá ingresar en el sistema ICEBERG la cantidad de requerimientos corregidos por desaprobación del cliente en el subproceso de corrección. Por otro lado, para el cálculo de la cantidad de requerimientos totales, se tomará la información registrada por el analista funcional, previamente para el cálculo de los indicadores descritos en la sección 9.1.4.5 (errores mayores detectados/Cantidad de requerimientos). De tal forma que se puede observar que porcentaje de los requerimientos planteados por el analista funcional en el proceso de especificación de requerimientos, han sido desaprobados por el cliente en el proceso de solicitar aprobación del cliente.

70

Dentro del sistema ICEBERG se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, con los datos ingresados por el analista funcional, el sistema ICEBERG procederá a realizar el cálculo del indicador y el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan realizar las comparaciones pertinentes. Cabe aclarar, que si al solicitar la aprobación del cliente, este no aprueba el documento en más de una ocasión, este indicador será calculado en repetidas ocasiones, hasta que el cliente apruebe el producto.

9.1.4.7 R.7: Esfuerzo de repetición/Cantidad de correcciones

Este indicador corresponde al cociente entre la cantidad de horas empleadas en la corrección de errores mayores por el encargado de dicha tarea y la cantidad de correcciones totales de errores mayores realizadas en el proceso. Este indicador permite observar la cantidad de tiempo promedio empleado en la corrección de un error mayor. De esta forma, se puede evaluar la velocidad y el rendimiento de la persona encargada en realizar las correcciones.

Este indicador se mide al finalizar los subprocesos de inspección del SRS, correcciones e inspección del plan de pruebas, como se puede observar en el Anexo 35, el encargado de realizar las correcciones en los procesos de inspección del SRS y correcciones es el analista funcional, por su parte el gerente del proyecto es el encargado de realizar las correcciones en el proceso de inspección del plan de pruebas.

En el caso del subproceso de inspección del SRS, el analista funcional realizará las correcciones de los errores mayores detectados por el líder funcional en el documento de SRS. Para la medición de este indicador, se tomará la información sobre la cantidad de errores mayores encontrados por el líder funcional durante la revisión del documento y registrados anteriormente por este, tal como se detalla en la sección 9.1.4.5. Por otro lado, el analista funcional deberá registrar dentro del sistema ICEBERG la hora de inicio de la sesión de corrección, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberá consignar el tiempo de culminación de la sesión de corrección dentro del sistema ICEBERG. Si la sesión de corrección se divide en varias partes, el analista funcional deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de corrección calculado como la suma de todos los tiempos de las sesiones individuales de corrección de errores mayores y este será dividido por el número de correcciones totales realizadas, el cual es igual a la cantidad de errores mayores detectados.

En el caso del subproceso de correcciones, el analista funcional realizará las correcciones de los errores mayores detectados por el cliente en el subproceso de solicitar aprobación del cliente. Para la medición de este indicador, se tomará la información sobre la cantidad de errores mayores registrados por el analista funcional previo a la corrección de los errores señalados por

71

el cliente durante el proceso de solicitar aprobación al cliente, el detalle de cómo se registraron estos datos fue descrito en la sección 9.1.4.5. De tal forma que la cantidad de correcciones totales que el analista funcional debe realizar en el proceso de correcciones es igual a la cantidad de errores mayores registrados por el analista funcional previo al inicio de este proceso. Por otro lado, el analista funcional deberá registrar dentro del sistema ICEBERG la hora de inicio de la sesión de corrección, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberá consignar el tiempo de culminación de la sesión de corrección dentro del sistema ICEBERG. Si la sesión de corrección se divide en varias partes, el analista funcional deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de corrección calculado como la suma de todos los tiempos de las sesiones individuales de corrección de errores mayores y este será dividido por el número de correcciones totales realizadas, el cual es igual a la cantidad de errores mayores detectados.

En el caso del subproceso de inspección plan de pruebas, el gerente del proyecto realizará las correcciones de los errores detectados por él, en el documento de plan de pruebas. Para la medición de este indicador, el gerente de proyectos debe registrar dentro del sistema ICEBERG la cantidad total de errores mayores detectados en el documento de plan de pruebas durante el proceso de inspección plan de pruebas. También, deberá registrar dentro del sistema ICEBERG la hora de inicio de la sesión de corrección de los errores identificados previamente por él, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberá consignar el tiempo de culminación de la sesión de corrección dentro del sistema ICEBERG. Si la sesión de corrección se divide en varias partes, el analista funcional deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de corrección calculado como la suma de todos los tiempos de las sesiones individuales de corrección de errores mayores y este será dividido por el número de correcciones de errores mayores totales realizadas, el cual es igual a la cantidad de errores mayores detectados.

En todos los casos anteriores, los encargados de las correcciones deben registrar los datos obtenidos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador. Dentro de este sistema, se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan y realizar las comparaciones pertinentes, estas fueron descritas anteriormente.

9.1.4.8 R.8: Densidad del error

Este indicador corresponde al cociente entre los errores mayores totales encontrados durante las inspecciones al documento SRS y el tamaño del producto de trabajo (TPT). Por otro

72

lado, el tamaño del producto de trabajo se define como la cantidad total de pasos documentados en los guiones del documento SRS. Este indicador permite analizar el rendimiento del analista funcional, puesto que muestra la cantidad de errores mayores presentes por guion descrito en el SRS.

Este indicador se toma después del desarrollo del subproceso de inspección del SRS, tal como se puede observar en el Anexo 35. Para la medición de este indicador, el sistema ICEBERG tomará los datos registrados por el líder funcional para el indicador descrito previamente en la sección 9.1.4.5 (errores mayores detectados/Cantidad de requerimientos). Por otro lado, el sistema ICEBERG tomará los datos registrados por el analista funcional para el indicador descrito previamente en la sección 9.1.4.2 (Tiempo empleado en escribir los requerimientos/ Cantidad de pasos en el guion de casos de uso detallados), los cuales muestran la cantidad de pasos dentro de todos los guiones contenidos dentro de todos los casos de uso desarrollados en el SRS. De esta forma, al obtener la suma de todos los pasos descritos en los guiones del SRS, se obtiene el tamaño del sistema (TPT). Así pues, el sistema ICEBERG procede a calcular el indicador, de la siguiente forma:

�� =��

��


Establecimiento de los valores de tolerancia

Los valores de tolerancia de los indicadores presentados anteriormente en la sección 9.1.4 fueron determinados por medio de un juicio de expertos, a través del cual se llegó a un acuerdo de los niveles de aceptación iniciales para los indicadores. Estos se pueden observar posteriormente en el Anexo 41.

9.2 Fase de diseño

Como se mencionó anteriormente, la fase de diseño fue seleccionada para realizar la definición y diseño de los indicadores de rendimiento. Esta fase se compone de seis procesos, los cuales fueron estudiados junto con la gerencia de Expert Information SAS, con el fin de encontrar aquellos donde es más relevante medir el desempeño del proyecto.

73

Identificación de los puntos de control y medición en los procesos de acuerdo al proceso de Rendimiento Organizacional propuesto en el modelo CMMI DEV 1.3

En reunión con la gerencia de Expert Information SAS se encontró que, en comparación con los otros procesos, hay un mayor interés por medir el rendimiento en el proceso de diseño. Lo anterior se debe a que el proceso de diseño es de vital importancia dentro del ciclo del desarrollo de software, y un error en este proceso es crítico pues desembocaría en una implementación inadecuada del dispositivo, que no corresponde a lo requerido por el cliente. De este modo, la corrección de errores de diseño que se han propagado a fases posteriores resulta mucho más difícil, por lo que se espera que al realizar las mediciones de rendimiento en este proceso se detecten y corrijan los errores a tiempo. En el Anexo 37 se señala el proceso seleccionado.


Se realizó una revisión documental de diversas fuentes bibliográficas, con el fin de encontrar métricas de rendimiento aplicables a la fase de diseño. Así mismo, se propusieron algunas métricas que se consideran significativas dentro de dicha fase. Dentro de las métricas encontradas y las propuestas, se seleccionaron las más significativas, cinco en total, las cuales tienen mayor impacto en el desempeño de la fase de diseño.

En el Anexo 38, se indican los subprocesos en los cuales se van a desarrollar las mediciones de los indicadores de rendimiento dentro del proceso de diseño. A continuación, se explican las abreviaturas utilizadas en dicho gráfico:

• D.1: Tiempo empleado en documentación/Cantidad de páginas documentadas.

• D.2: Esfuerzo de evaluación/Páginas del documento revisado.

• D.3: Errores mayores detectados/Cantidad de artefactos inspeccionados.

• D.4: Esfuerzo de repetición/Cantidad de correcciones.

• D.5: Productividad individual por artefacto.


Dentro de la fase de diseño, específicamente en el proceso de diseño, se desarrollaron cinco indicadores para medir el rendimiento de este. Para establecer las líneas base de estos indicadores se requiere la información histórica del último año, sin embargo, la compañía no ha almacenado suficiente información para establecer las bases de los indicadores; razón por la cual para el establecimiento de estos valores se realizó una reunión con los líderes (Gerentes y líderes de proyectos) de la compañía y por medio de esta se llegó a un acuerdo de los niveles de aceptación iniciales para los indicadores. Se espera posteriormente con la información recabada

74

ir ajustando los indicadores de acuerdo al desempeño obtenido en el tiempo con las nuevas mediciones.

Para desarrollar los indicadores de rendimiento se requiere la siguiente información sobre la fase de diseño: tiempos empleados en la documentación, cantidades de páginas documentadas, cantidades de horas-hombre empleadas en revisiones, cantidades de páginas de los documentos revisados, cantidades de errores mayores detectados en las revisiones, cantidad de artefactos inspeccionados, cantidades de horas-hombre empleadas en correcciones, tiempo empleado en el desarrollo de los artefactos del proyecto.


Se realizó un análisis del proceso de diseño y de los indicadores que se proponen implementar en este. Lo anterior, permitió identificar el procedimiento de medición y toma de datos para el cálculo de los indicadores, estos son descritos a continuación.

9.2.4.1 D.1: Tiempo empleado en documentación/Cantidad de páginas documentadas

Este indicador corresponde al cociente entre el tiempo empleado en documentación y la cantidad de páginas documentadas, tomados en cada una de las sesiones de documentación realizadas durante el proceso de diseño. Este indicador permite analizar el rendimiento del trabajo realizado por el líder de desarrollo y cada miembro del equipo de diseño, quienes son en todo momento los responsables de realizar la documentación necesaria durante el proceso de diseño del proyecto. Dicho cociente permite conocer la velocidad a la que estos documentan todo lo concerniente a los subprocesos de diseño estructural, primera etapa de diseño, pasos de diseño subsecuentes y especificación de diseño del sistema, que son los subprocesos en los cuales se requiere de la escritura de un documento, sin lo cual no es posible seguir a los pasos de diseño posteriores.

Este indicador se toma durante los subprocesos ya mencionados, de diseño estructural, primera etapa de diseño y pasos de diseño subsecuentes, siendo el equipo de diseño los encargados de la medición. También se mide este indicador durante el subproceso de especificación de diseño del sistema, siendo aquí el líder de desarrollo el encargado de documentar lo desarrollado en este subproceso, tal como se puede observar en el Anexo 38. En los tres primeros casos (diseño estructural, primera etapa de diseño y pasos de diseño subsecuentes), cada integrante del equipo de diseño deberá tomar el tiempo durante cada una de las sesiones de documentación, sesiones que se desarrollan a lo largo de cada subproceso involucrado. Al inicio de cada sesión de documentación, cada miembro del equipo de diseño deberá registrar la hora de inicio, observando esta en cualquier dispositivo que tenga a su alcance (reloj, teléfono, computador, entre otros), y así mismo deberán registrar la hora de finalización de la sesión junto con el número de páginas del documento escritas en ese tiempo.

75

Del mismo modo, en el segundo caso el líder de desarrollo se encargará de llevar el tiempo dedicado a la documentación en cada una de sus respectivas sesiones, para lo cual tomará el tiempo de inicio y finalización de las sesiones, tal como se especificó anteriormente. Finalmente, en cada uno de los casos anteriores se deberán ingresar los datos de tiempos de inicio y fin, y número de páginas documentadas durante la sesión en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador de la sesión.

Dentro del sistema ICEBERG se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan realizar las comparaciones pertinentes, estas fueron descritas anteriormente.

Este indicador se medirá por sesión y por persona, con el objetivo de analizar el rendimiento de cada integrante del equipo de diseño y del líder de desarrollo en cada sesión, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.2.4.2 D.2: Esfuerzo de evaluación/Páginas del documento revisado

Este indicador corresponde al cociente entre la cantidad de horas empleadas en la revisión de un documento por parte del encargado de dicha tarea y la cantidad de páginas revisadas durante dicho tiempo. A través de este indicador se puede saber la velocidad a la que el encargado de la inspección realiza la tarea de revisión del documento. De este modo, se puede conocer el tiempo dedicado a la revisión durante el desarrollo del proceso de diseño, y así mismo se puede medir el desempeño del encargado de la revisión.

Este indicador se mide en los subprocesos de pasos de diseño subsecuentes e inspección al diseño de alto nivel, como se puede observar en el Anexo 38, y el encargado de la revisión es el equipo de diseño. En el caso del subproceso de pasos de diseño subsecuentes, los integrantes del equipo de diseño realizarán una sesión de revisión a los documentos correspondientes a ciclos de diseño anteriores y los confrontarán contra los requerimientos del sistema. Para su medición, cada integrante del equipo de diseño deberá consignar la hora de inicio de la sesión de revisión, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberán consignar en el sistema ICEBERG el tiempo de culminación de la sesión de revisión y el número de páginas del documento revisado. Si la sesión de revisión se divide en varias partes, el equipo de diseño deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de evaluación calculado como la suma de todos los tiempos de las sesiones individuales de una misma persona y este será dividido por el número de páginas del documento revisado.

76

En el caso del subproceso de inspección al diseño de alto nivel, cada integrante del equipo de diseño deberá seguir un procedimiento similar al descrito anteriormente, registrando en el sistema ICEBERG el tiempo de inicio y fin de cada sesión de inspección, y la cantidad de páginas que contiene el documento sometido a revisión. Cabe aclarar, como se mencionó anteriormente, si la sesión de revisión se divide en varias partes, los miembros del equipo de diseño deberán consignar el tiempo de inicio y fin de cada una de las sesiones, entonces el esfuerzo de evaluación será calculado como la suma de todos los tiempos obtenidos en las sesiones individuales de una misma persona. La sesión de revisión en este caso se realiza una vez que el subproceso de estrategia de integración ha finalizado, y durante esta revisión los integrantes del equipo de diseño deberán inspeccionar todo el material de diseño y la estrategia de integración trazada con el fin de encontrar errores en los documentos o en el procedimiento seguido. El indicador será entonces, el esfuerzo de evaluación calculado como la suma de todos los tiempos de las sesiones individuales de una misma persona y este será dividido por el número de páginas del documento revisado.

Como se mencionó anteriormente, los encargados de la revisión deben registrar los datos obtenidos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador. Dentro de este sistema, se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan y realizar las comparaciones pertinentes, estas fueron descritas anteriormente.

Este indicador se medirá por documento y por persona, con el objetivo de analizar el rendimiento de cada integrante del equipo de diseño en cada revisión, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.2.4.3 D.3: Errores mayores detectados/Cantidad de artefactos inspeccionados

Este indicador corresponde al cociente entre la cantidad de errores encontrados durante las sesiones de revisión de documentos y la cantidad de artefactos inspeccionados en dichas sesiones. A través de este indicador, es posible medir el desempeño del equipo de diseño, quienes se encargan de realizar todo el proceso de diseño con su correspondiente documentación. Es importante resaltar, que la existencia de errores produce un retraso en la ejecución del proceso, dado que es necesario una nueva revisión y corrección de los errores, por lo que en todo momento se desea que el número de errores encontrados en los documentos sea cero.

La empresa clasifica los errores encontrados en el documento, en dos tipos: errores mayores y errores menores. Los errores menores son errores pequeños dentro del texto, que no afectan drásticamente al proyecto y por lo tanto su corrección no requiere mucho tiempo. Por otro lado, los errores mayores son errores que afectan significativamente el desarrollo del

77

proyecto y su corrección demanda una cantidad de tiempo significativa, que puede retrasar la ejecución de procesos posteriores.

En este documento no se planteará la medición de los errores menores, puesto que estos son de bajo impacto y no afectan significativamente el desarrollo de procesos posteriores, razón por la cual la empresa ha decidido implementar su medición en una fase posterior y utilizando otra metodología. Por lo anterior, este indicador se utilizará solo para realizar mediciones de la cantidad de errores mayores por cantidad de requerimientos.

Este indicador se mide al finalizar los subprocesos de pasos de diseño subsecuentes e inspección al diseño de alto nivel, y los responsables de realizar la medición son los miembros del equipo de diseño y el arquitecto de software respectivamente. En el primer caso, se le pedirá al equipo de diseño (subproceso de pasos de diseño subsecuentes) consignar en el sistema ICEBERG, la cantidad de errores mayores encontrados durante cada una de las sesiones de revisión realizadas a los materiales de diseño y posteriormente, el documento deberá ser corregido, por el equipo de diseño. El documento deberá entonces pasar por un nuevo proceso de revisión en el cual se determinará si es posible continuar con el siguiente subproceso dentro del proceso de diseño. Una vez que el documento haya sido aprobado, el sistema ICEBERG calculará el indicador de errores mayores registrados anteriormente por el equipo de diseño. El indicador se calculará como el total de todos los errores mayores encontrados durante cada una de las sesiones de corrección del documento dividido sobre la cantidad de artefactos inspeccionados.

En el segundo caso, se le pedirá al arquitecto de software (subproceso de inspección al diseño de alto nivel) consignar en el sistema ICEBERG la cantidad de errores mayores encontrados por el equipo de diseño durante cada una de las sesiones de revisión realizadas a los materiales de diseño y posteriormente, el documento deberá ser corregido por el arquitecto de software o líder de desarrollo. El documento deberá entonces pasar por un nuevo proceso de revisión en el cual se determinará si es posible continuar con el siguiente subproceso dentro del proceso de diseño. Una vez que el documento haya sido aprobado, el sistema ICEBERG calculará el indicador de errores mayores registrados anteriormente por el inspector. El indicador se calculará como el total de todos los errores mayores encontrados durante cada una de las sesiones de corrección del documento dividido sobre la cantidad de artefactos inspeccionados.

Dentro del sistema ICEBERG se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema, a la plantilla del Balanced Scorecard, de tal forma que se puedan realizar las comparaciones pertinentes, estas fueron descritas anteriormente.

78

Errores menores detectados/Cantidad de requerimientos

En todos los casos anteriores, se pedirá al equipo de diseño y arquitecto de software que consideren como errores menores aquellos que se consignan a continuación:

Artefacto incompleto: Se define como aquel artefacto cuya descripción es pobre y carece del detalle suficiente para modelar adecuadamente la función del sistema a la que responde. Se considera este como un error menor debido a que su corrección solo requiere ampliar la información y aumentar el grado de detalle del artefacto, lo que corresponde en agregar o cambiar algunos aspectos de este y del documento.

Artefacto poco conciso: Se entiende como aquel artefacto que es poco preciso en su redacción (siempre que este la requiera) en tanto es muy extenso, difícil de leer, o difícil de interpretar. Se considera este como un error menor debido a que su corrección solo requiere resumir un poco el texto ya escrito o representar el artefacto de una manera más clara, y no representa esto una pérdida del tiempo invertido en la escritura.

Artefacto no modificable: Se define como aquel artefacto cuya construcción no posibilita una posterior modificación por parte del equipo de diseño o eventualmente, del cliente, en caso de que se deseen cambiar las características del sistema. Con lo anterior se hace referencia a los casos en los que la forma en la que describe el artefacto hace que sea muy difícil o casi imposible cambiar algún detalle de este, pues se incurriría en un error grave, ya sea esto debido a que se violaría algún requerimiento, o perdería su sentido o se volvería redundante. Se considera este como un error menor pues su corrección solo requiere cambiar la forma en la que está representado el artefacto y su descripción, y así mismo, no representa esto una pérdida del tiempo invertido en la escritura de este.

Artefacto poco específico: Se entiende como aquel artefacto que es poco específico en cuanto encierra varias funciones del sistema que deberían ser descritas como artefactos distintos del proyecto. Un artefacto poco específico no es detallado en su descripción, y es necesario dividirlo en partes cuya sola descripción corresponde con un requerimiento o función del sistema. Se considera este como un error menor pues su corrección requiere una ampliación del documento ya existente.


Errores mayores detectados/Cantidad de requerimientos

En todos los casos anteriores, se pedirá al equipo de diseño y al arquitecto de software que consideren como errores mayores aquellos que se consignan a continuación:

79

Diseño incorrecto: Se entiende como aquel artefacto que no está acorde a lo solicitado por el cliente para su producto, es decir, no cumple con los requerimientos especificados por el cliente. Este tipo de artefactos representan una pérdida de tiempo en la redacción del documento, y su corrección consiste en eliminar y replantear completamente el artefacto en cuestión. Debido a lo anterior, se considera este tipo de errores como errores mayores, puesto que el tiempo invertido en su elaboración y redacción es improductivo y termina afectando el rendimiento del proceso.

Diseño no rastreable: Se entiende como aquel artefacto al que no se le puede asignar una función específica dentro del sistema. El diseño de cada artefacto debe estar organizado de tal forma que para cada función y conjunto de requerimientos del sistema sea posible encontrar el conjunto de artefactos que pretenden modelar el funcionamiento del sistema en este aspecto. Cuando el documento no cumple esta característica se dice que contiene un artefacto no rastreable, por lo que para su corrección es necesario cambiar toda la estructura del documento y, posiblemente, replantear el diseño del artefacto. Debido a lo anterior, se considera a este tipo de errores como errores mayores.

Diseño incompleto: Se dice que el documento se encuentra incompleto en el sentido del diseño, si a partir de todos los artefactos que se encuentran en él especificados, no es posible inferir una visión global del sistema, visualizando entradas, salidas y todo su comportamiento para diferentes combinaciones de las entradas. Es decir, no se ha logrado obtener una descripción completa del sistema con todos los artefactos diseñados hasta el momento. Para corregir este tipo de errores es necesario replantear la visión general de toda la descripción, y encontrar los puntos débiles del documento, en lo que no se ha sido lo suficientemente específico o se han dejado vacíos que no permiten tener una idea general del sistema. Debido al extenso análisis que esto conlleva, se considera a este tipo de errores como errores mayores.

9.2.4.4 D.4: Esfuerzo de repetición/Cantidad de correcciones

Este indicador corresponde al cociente entre la cantidad de horas empleadas en la corrección de errores mayores por el encargado de dicha tarea y la cantidad de correcciones totales de errores mayores realizadas en el proceso. Este indicador permite observar la cantidad de tiempo promedio empleado en la corrección de un error mayor. De esta forma, se puede evaluar la velocidad y el rendimiento de la persona encargada de realizar las correcciones.

Este indicador se mide al finalizar los subprocesos de pasos de diseño subsecuentes e inspección al diseño de alto nivel, como se puede observar en el Anexo 38, el encargado de realizar las correcciones en el proceso de pasos de diseño subsecuentes es el equipo de diseño, por su parte el arquitecto de software es el encargado de realizar las correcciones en el proceso de inspección al diseño de alto nivel.

En el caso del subproceso de pasos de diseño subsecuentes, el equipo de diseño realizará las correcciones de los errores mayores detectados por ellos mismos durante la revisión del

80

diseño. Para la medición de este indicador, se tomará la información sobre la cantidad de errores mayores, encontrados por el equipo de diseño durante la revisión de los documentos, y registrados anteriormente por estos, tal como se detallada en la sección 9.2.4.3. Por otro lado, cada integrante del equipo de diseño deberá registrar dentro del sistema ICEBERG la hora de inicio de la sesión de corrección, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberán consignar el tiempo de culminación de la sesión de corrección dentro del sistema ICEBERG. Si la sesión de corrección se divide en varias partes, el equipo de diseño deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de corrección calculado como la suma de todos los tiempos de las sesiones individuales de corrección de errores mayores de cada persona y este será dividido por el número de correcciones totales realizadas, el cual es igual a la cantidad de errores mayores corregidos por persona. Como se mencionó anteriormente, vale la pena aclarar que este indicador se calcula de manera individual para cada integrante del equipo de diseño.

En el caso del subproceso de inspección al diseño de alto nivel, el arquitecto de software realizará las correcciones de los errores mayores detectados por el equipo de diseño durante la revisión de los documentos. Para la medición de este indicador, se tomará la información sobre la cantidad de errores mayores, encontrados por el equipo de diseño durante la revisión del diseño, y registrados anteriormente por estos, tal como se detalla en la sección 9.2.4.3. Por otro lado, el arquitecto de software deberá registrar dentro del sistema ICEBERG la hora de inicio de la sesión de corrección, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberá consignar el tiempo de culminación de la sesión de corrección dentro del sistema ICEBERG. Si la sesión de corrección se divide en varias partes, el arquitecto de software deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de corrección calculado como la suma de todos los tiempos de las sesiones individuales de corrección de errores mayores y este será dividido por el número de correcciones totales realizadas, el cual es igual a la cantidad de errores mayores detectados.

En todos los casos anteriores, los encargados de las correcciones deben registrar los datos obtenidos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador. Dentro de este sistema, se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan y realizar las comparaciones pertinentes.

81

9.2.4.5 D.5: Productividad individual por artefacto

Este indicador mide la cantidad de horas hombre invertidas en la construcción de uno de los artefactos de diseño, y se mide como la cantidad de horas invertidas en el diseño de los artefactos dividido entre el número de artefactos diseñados, tomado para cada uno de los miembros del equipo de diseño. Esta métrica pretende medir el desempeño de los miembros del equipo de diseño, y tener un control periódico de la productividad individual de cada uno de los miembros del equipo.

�� =��

��

Este indicador se toma durante tres subprocesos del proceso de diseño, los cuales son el diseño estructural, la primera etapa del diseño y los pasos de diseño subsecuentes. En estos, se requiere medir la productividad de los miembros del equipo de diseño, quienes son los responsables de llevar a cabo todo el proceso del diseño del sistema. Para su medición, se pedirá a cada uno de los miembros que registren en el sistema ICEBERG el tiempo invertido en diseño de artefactos, entendiendo por artefactos todas las definiciones, módulos, diagramas, vistas, representaciones, etc. referentes a alguna funcionalidad o característica del sistema que se está diseñando. Por tanto, cada miembro del equipo de diseño deberá tomar el tiempo de inicio y fin de la sesión de trabajo, observando este en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y al finalizar cada sesión deberán registrar dichos datos, junto con el número de artefactos desarrollados en el sistema ICEBERG, el cual realizará el cálculo del indicador de productividad semanalmente, con el fin de llevar un registro periódico de la productividad. Del mismo modo, cada miembro deberá consignar una descripción de los artefactos desarrollados, lo que permitirá tener una idea tanto de la productividad como de la complejidad de lo desarrollado en dicho tiempo.


Este indicador se medirá semanalmente, con el objetivo de analizar el rendimiento de cada integrante del equipo de diseño periódicamente, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.


Los valores de tolerancia de los indicadores presentados anteriormente en la sección 9.2.4 fueron determinados por medio de un juicio de expertos, a través del cual se llegó a un acuerdo

82

de los niveles de aceptación iniciales para los indicadores. Estos se pueden observar posteriormente en el Anexo 41.

9.3 Fase de implementación

Como se mencionó anteriormente, la fase de implementación fue seleccionada para realizar la definición y diseño de los indicadores de rendimiento. Esta fase se compone de seis procesos, los cuales fueron estudiados junto con la gerencia de Expert Information SAS, con el fin de encontrar aquellos donde es más relevante medir el desempeño del proyecto.

Identificación de los puntos de control y medición en los procesos de acuerdo al proceso de Rendimiento Organizacional propuesto en el modelo CMMI DEV 1.3

En reunión con la gerencia de Expert Information SAS se encontró que, en comparación con los otros procesos, hay un mayor interés por medir el rendimiento en el proceso de implementación. Lo anterior se debe a que, en comparación con otros procesos, en este proceso se presentan una mayor cantidad de errores. Del mismo modo, es de vital importancia que la implementación se desarrolle con la menor cantidad de errores posibles, de modo que el tiempo empleado en pruebas del sistema se minimice, ya que no se harán pruebas y correcciones innecesarias. Del mismo modo, la empresa espera que al realizar las mediciones de rendimiento en este proceso se detecten y corrijan los errores a tiempo, de modo que en procesos posteriores no sea necesario volver a los procesos de implementación a corregir errores pasados. En el Anexo 39 se señala el proceso seleccionado.


Se realizó una revisión documental de diversas fuentes bibliográficas, con el fin de encontrar métricas de rendimiento aplicables a la fase de implementación. Así mismo, se propusieron algunas métricas que se consideran significativas dentro de dicha fase. Dentro de las métricas encontradas y las propuestas, se seleccionaron las más significativas, diez en total, las cuales tienen mayor impacto en el desempeño de la fase de diseño.

En el Anexo 40, se indican los subprocesos en los cuales se van a desarrollar las mediciones de los indicadores de rendimiento dentro del proceso de implementación. A continuación, se explican las abreviaturas utilizadas en dicho gráfico:

• I.1: Tiempo empleado en documentación/Cantidad de páginas documentadas.

• I.2: Esfuerzo de evaluación/Cantidad de páginas evaluadas.

• I.3: Errores mayores/Cantidad de páginas revisadas.

• I.4: Esfuerzo de repetición/Cantidad de errores identificados.

• I.5: Errores escritos en el código por persona/KLOC.

• I.6: Tiempo de depuración del código/KLOC.

83

• I.7: Productividad individual.

• I.8: Efectividad de la inspección.

• I.9: Eficiencia de corrección de errores.

• I.10: Progreso del testeo.


Dentro de la fase de implementación, específicamente en el proceso de implementación, se desarrollaron diez indicadores para medir el rendimiento de este. Para establecer las líneas base de estos indicadores se requiere la información histórica del último año, sin embargo, la compañía no ha almacenado suficiente información para establecer las bases de los indicadores; razón por la cual para el establecimiento de estos valores se realizó una reunión con los líderes (Gerentes y líderes de proyectos) de la compañía y por medio de esta se llegó a un acuerdo de los niveles de aceptación iniciales para los indicadores. Se espera posteriormente con la información recabada ir ajustando los indicadores de acuerdo al desempeño obtenido en el tiempo con las nuevas mediciones.

Para desarrollar los indicadores de rendimiento se requiere la siguiente información sobre la fase de implementación: tiempos empleados en la documentación, cantidades de páginas documentadas, cantidades de horas-hombre empleadas en revisiones, cantidades de páginas de los documentos inspeccionados, cantidades de errores mayores detectados en las revisiones, cantidades de horas-hombre empleadas en correcciones, cantidades de errores en el código por persona, cantidades de líneas de código escritas por módulo por persona, tiempos empleados en depuración del código por módulo, cantidades de horas por persona empleados en codificación, cantidades de líneas de código escritas diariamente por persona, cantidades de horas empleadas en revisión del código, cantidades de líneas de código revisadas por día, cantidades de defectos resueltos por sesión, cantidades de pruebas realizadas a cada módulo en el tiempo.


Se realizó un análisis del proceso de implementación y de los indicadores que se proponen implementar en este. Lo anterior, permitió identificar el procedimiento de medición y toma de datos para el cálculo de los indicadores, estos son descritos a continuación.

9.3.4.1 I.1: Tiempo empleado en documentación/Cantidad de páginas documentadas

Este indicador corresponde al cociente entre el tiempo empleado en documentación y la cantidad de páginas documentadas, tomados en cada una de las sesiones de documentación realizadas durante el proceso de implementación. Dicho cociente permite conocer la velocidad a la que los desarrolladores documentan todo lo concerniente al subproceso de diseño detallado, que es donde se requiere de la escritura de un documento y sin lo cual no es posible seguir a los pasos de diseño posteriores.

84

Este indicador se toma durante el proceso de diseño detallado, como se mencionó anteriormente y los desarrolladores que realicen la documentación de este serán los encargados de realizar las respectivas mediciones, tal como se puede observar en el Anexo 40. Para ello, los desarrolladores que realicen actividades de documentación del diseño detallado deberán tomar el tiempo durante cada una de las sesiones de documentación, sesiones que se desarrollan a lo largo del subproceso involucrado. Al inicio de cada sesión de documentación, cada desarrollador deberá registrar la hora de inicio, observando esta en cualquier dispositivo que tengan a su alcance (reloj, teléfono, computador, entre otros), y así mismo deberán registrar la hora de finalización de la sesión junto con el número de páginas del documento escritas en ese tiempo. Posteriormente, se deberán ingresar los datos de tiempos de inicio y fin, y número de páginas documentadas durante la sesión en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador de la sesión.


Este indicador se medirá por sesión y por persona, con el objetivo de analizar el rendimiento en documentación de los desarrolladores en cada sesión, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.3.4.2 I.2: Esfuerzo de evaluación/Cantidad de páginas evaluadas

Este indicador corresponde al cociente entre la cantidad de horas empleadas en la revisión de un documento por parte del líder de desarrollo y la cantidad de páginas revisadas durante dicho tiempo. A través de este indicador se puede saber la velocidad a la que el líder de desarrollo realiza la tarea de revisión del documento. De este modo, se puede conocer el tiempo dedicado a la revisión durante el desarrollo del proceso de implementación, y así mismo se puede medir el desempeño del encargado de la revisión.

Este indicador se mide al finalizar el subproceso inspección del diseño detallado, como se puede observar en el Anexo 40. Para ello, el líder de desarrollo, quien es el encargado de realizar la revisión en este proceso, realizará una sesión de revisión del documento del diseño detallado, una vez que este haya sido culminado por los desarrolladores durante el subproceso de diseño detallado. Para su medición, el líder de desarrollo deberá consignar la hora de inicio de la sesión de revisión, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberá consignar el tiempo de culminación de la sesión de revisión y el número de páginas del documento revisado. Si la sesión de revisión se divide en varias partes, el líder de desarrollo deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de revisión calculado como la suma

85

de todos los tiempos de las sesiones individuales y este será dividido por el número de páginas del documento revisado.

Posteriormente, el encargado de la revisión debe registrar los datos obtenidos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador. Dentro de este sistema, se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan y realizar las comparaciones pertinentes.

Este indicador se medirá por documento, con el objetivo de analizar el rendimiento del inspector en cada revisión, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.3.4.3 I.3: Errores mayores/Cantidad de páginas revisadas

Este indicador corresponde al cociente entre la cantidad de errores encontrados durante la sesión de revisión de documentos y la cantidad de páginas inspeccionadas en dichas sesiones. A través de este indicador, es posible medir el desempeño de los desarrolladores encargados de realizar el diseño detallado del proyecto. Es importante resaltar, que la existencia de errores produce un retraso en la ejecución del proceso, dado que es necesario una nueva revisión y corrección de los errores, por lo que en todo momento se desea que el número de errores encontrados en los documentos sea cero.

La empresa clasifica los errores encontrados en el documento, en dos tipos: errores mayores y errores menores. Los errores menores son errores pequeños dentro del texto, que no afectan drásticamente al proyecto y por lo tanto su corrección no requiere mucho tiempo. Por otro lado, los errores mayores son errores que afectan significativamente el desarrollo del proyecto y su corrección demanda una cantidad de tiempo significativa, que puede retrasar la ejecución de procesos posteriores.

En este documento no se planteará la medición de los errores menores, puesto que estos son de bajo impacto y no afectan significativamente el desarrollo de procesos posteriores, razón por la cual la empresa ha decidido implementar su medición en una fase posterior y utilizando otra metodología. Por lo anterior, este indicador se utilizará solo para realizar mediciones de la cantidad de errores mayores por cantidad de páginas revisadas.

Este indicador se mide al finalizar el subproceso de inspección del diseño detallado, y el responsable de realizar la medición es el líder de desarrollo. En este caso, se le pedirá al líder de desarrollo consignar en el sistema ICEBERG, la cantidad de errores mayores encontrados durante cada una de las sesiones de revisión realizadas a los materiales de diseño y posteriormente, el documento deberá ser corregido por el grupo de desarrolladores que se

86

encargó de documentarlo. El documento deberá entonces pasar por un nuevo proceso de revisión en el cual se determinará si es posible continuar con el subproceso de codificación dentro del proceso de implementación. Una vez que el documento haya sido aprobado, el sistema ICEBERG calculará el indicador de errores mayores registrados anteriormente por el líder de desarrollo. El indicador se calculará como el total de todos los errores mayores encontrados durante cada una de las sesiones de corrección del documento dividido sobre la cantidad de páginas del documento inspeccionados.


Errores menores detectados/Cantidad de requerimientos

Se pedirá al líder de desarrollo que considere como errores menores aquellos que se consignan a continuación:

Diseño incompleto: Se define como aquel diseño cuya descripción es pobre y carece del detalle suficiente para modelar adecuadamente la función del sistema a la que responde. Se considera este como un error menor debido a que su corrección solo requiere ampliar la información y aumentar el grado de detalle, lo que corresponde en agregar o cambiar algunos aspectos de este y del documento.

Diseño poco conciso: Se entiende como aquel diseño que es poco preciso en su redacción (siempre que este la requiera) en tanto es muy extenso, difícil de leer, o difícil de interpretar. Se considera este como un error menor debido a que su corrección solo requiere resumir un poco el texto ya escrito o representar el diseño de una manera más clara, y no representa esto una pérdida del tiempo invertido en la escritura.

Diseño no modificable: Se define como aquel diseño cuya construcción no posibilita una posterior modificación por parte del equipo de diseño o eventualmente, del cliente, en caso de que se deseen cambiar las características del sistema. Con lo anterior se hace referencia a los casos en los que la forma en la que describe el diseño hace que sea muy difícil o casi imposible cambiar algún detalle de este, pues se incurriría en un error grave, ya sea esto debido a que se violaría algún requerimiento, o perdería su sentido o se volvería redundante. Se considera este como un error menor pues su corrección solo requiere cambiar la forma en la que está representado y su descripción, y así mismo, no representa esto una pérdida del tiempo invertido en la escritura de este.

Diseño poco específico: Se entiende como aquel diseño que es poco específico en cuanto encierra varias funciones del sistema que deberían ser descritas como artefactos distintos

87

del proyecto. Un artefacto poco específico no es detallado en su descripción, y es necesario dividirlo en partes cuya sola descripción corresponde con un requerimiento o función del sistema. Se considera este como un error menor pues su corrección requiere una ampliación del documento ya existente.


Errores mayores detectados/Cantidad de requerimientos

Se pedirá al líder de desarrollo que considere como errores mayores aquellos que se consignan a continuación:

Diseño incorrecto: Se entiende como aquel diseño que no está acorde a lo solicitado por el cliente para su producto, es decir, no cumple con los requerimientos especificados por el cliente. Este tipo de diseños representan una pérdida de tiempo en la redacción del documento, y su corrección consiste en eliminarlo y replantearlo por completo nuevamente. Debido a lo anterior, se considera este tipo de errores como errores mayores, puesto que el tiempo invertido en su elaboración y redacción es improductivo y termina afectando el rendimiento del proceso.

Diseño no rastreable: Se entiende como aquel diseño al que no se le puede asignar una función específica dentro del sistema. El diseño de cada artefacto debe estar organizado de tal forma que para cada función y conjunto de requerimientos del sistema sea posible encontrar el conjunto de artefactos que pretenden modelar el funcionamiento del sistema en este aspecto. Cuando el documento no cumple esta característica se dice que contiene un artefacto no rastreable, por lo que para su corrección es necesario cambiar toda la estructura del documento y, posiblemente, replantear el diseño del artefacto. Debido a lo anterior, se considera a este tipo de errores como errores mayores.

Diseño incompleto: Se dice que el documento se encuentra incompleto en el sentido del diseño, si a partir de todos los artefactos que se encuentran en él especificados, no es posible inferir una visión global del sistema, visualizando entradas, salidas y todo su comportamiento para diferentes combinaciones de las entradas. Es decir, no se ha logrado obtener una descripción completa del sistema con todos los artefactos diseñados hasta el momento. Para corregir este tipo de errores es necesario replantear la visión general de toda la descripción, y encontrar los puntos débiles del documento, en lo que no se ha sido lo suficientemente específico o se han dejado vacíos que no permiten tener una idea general del sistema. Debido al extenso análisis que esto conlleva, se considera a este tipo de errores como errores mayores.

88

9.3.4.4 I.4: Esfuerzo de repetición/Cantidad de errores identificados

Este indicador corresponde al cociente entre la cantidad de horas empleadas en la corrección de errores mayores por el encargado de dicha tarea y la cantidad de correcciones totales de errores mayores realizadas en el proceso. Este indicador permite observar la cantidad de tiempo promedio empleado en la corrección de un error mayor. De esta forma, se puede evaluar la velocidad y el rendimiento de la persona encargada en realizar las correcciones.

Este indicador se mide al finalizar el subproceso inspección del diseño detallado, como se puede observar en el Anexo 40, los encargados de realizar las correcciones, de los errores mayores detectados por el líder de desarrollo, son los desarrolladores designados para esta tarea. Para la medición de este indicador, se tomará la información sobre la cantidad de errores mayores, encontrados por el líder de desarrollo durante la revisión de los documentos, y registrados anteriormente por este, tal como se detallada en la sección 9.3.4.3. Por otro lado, los desarrolladores que realicen correcciones deberán registrar dentro del sistema ICEBERG la hora de inicio de la sesión de corrección, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberán consignar el tiempo de culminación de la sesión de corrección dentro del sistema ICEBERG. Si la sesión de corrección se divide en varias partes, cada desarrollador deberá consignar el tiempo de inicio y fin de cada una de las sesiones. El indicador será entonces, el esfuerzo de corrección calculado como la suma de todos los tiempos de las sesiones individuales de corrección de errores mayores de cada persona y este será dividido por el número de correcciones totales realizadas, el cual es igual a la cantidad de errores mayores corregidos por persona. Como ya fue mencionado, que este indicador se calculará de forma individual para cada desarrollador.

Como se mencionó anteriormente, los encargados de las correcciones deben registrar los datos obtenidos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador. Dentro de este sistema, se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan y realizar las comparaciones pertinentes.

9.3.4.5 I.5: Errores escritos en el código por persona/KLOC

Este indicador corresponde a la cantidad de errores escritos en el código, tomado por cada persona del grupo de desarrolladores, y por cada KLOC (miles de líneas de código). Este indicador permite medir el rendimiento de las personas encargadas de desarrollar el código del proyecto, pues permite estar al tanto de la cantidad de errores de cada desarrollador, y así mismo permite observar cuales desarrolladores presentan mayores dificultades en la escritura del código. Cabe resaltar que es importante medir la cantidad de errores por desarrollador, pues la

89

presencia de errores lleva a que se deba dedicar cierto tiempo a depurar y corregir el código, lo que se traduce en retardos en la entrega de los componentes y módulos codificados.

Este indicador se mide durante la ejecución del subproceso de codificación, durante el cual el grupo de desarrolladores se encarga de implementar el proyecto producto de las etapas de diseño anteriores. De este modo, el grupo de desarrolladores codifica el módulo o función que ha quedado a su cargo, y posteriormente deberán compilar el código hasta que este no presente errores. Se pedirá a cada uno que, después de terminar el módulo o función que se le ha sido asignado, y una vez que se encuentren en la fase de depuración del código, consignen en el sistema ICEBERG la cantidad de errores encontrados a la hora de compilar el código y la cantidad de líneas de código del módulo que se encuentran desarrollando, lo cual se realizará al finalizar la jornada, de manera diaria, con lo que se podrá tener un control diario del subproceso de codificación.


9.3.4.6 I.6: Tiempo de depuración del código/KLOC

Este indicador corresponde a la cantidad de tiempo usado en cada sesión de depuración del código, dividido entre la cantidad de KLOC (miles de líneas de código). Este indicador permite medir el rendimiento de los miembros del grupo de desarrollo quienes son los encargados en todo momento de depurar el código correspondiente a los módulos y funciones del proyecto. De este modo, es posible conocer el tiempo invertido por cada desarrollador en depurar su código, y así saber quiénes presentan un tiempo muy alto o cuales son los tiempos más críticos en caso de un eventual retraso de la entrega de algún módulo.

Este indicador se mide durante la ejecución de tres subprocesos, los cuales son: codificación, pruebas unitarias e inspección del código. En cada uno de los casos, los responsables de la medición serán los desarrolladores encargados de realizar la depuración. En el primer caso, durante el subproceso de codificación, los desarrolladores se encargan de codificar cada uno de los módulos en los que se ha dividido el proyecto. Al final del proceso de codificación, se pasará a la primera etapa de depuración, durante la cual, cada desarrollador tendrá que corregir los errores presentes en el código, hasta que este compile sin errores. Se pedirá entonces a cada desarrollador que, de manera diaria, consigne los tiempos invertidos por estos en depurar el código, junto con la cantidad de líneas del código que se encuentran depurando. Para esto, los desarrolladores deberán observar el tiempo de inicio y fin de la sesión de depuración en cualquier dispositivo que tengan a su alcance (reloj, teléfono, computador,

90

entre otros), y deberán consignar estos en el sistema ICEBERG, junto con el número de líneas de código. Si estos realizan más de una sesión de depuración al día (por ejemplo, una en la mañana y otra en la tarde), deberán sumar los tiempos de cada sesión e ingresar dichos valores. El sistema ICEBERG se encargará de realizar el cálculo diario del indicador, de manera que es posible monitorear periódicamente el desempeño de los desarrolladores.

En el segundo caso, durante el subproceso de pruebas unitarias, el desarrollador debe verificar el correcto funcionamiento del código, utilizando las listas de verificación previamente definidas por la organización. Siempre que el código no pase las pruebas unitarias, deberá ser depurado nuevamente por el desarrollador, con lo que se entrará en una segunda etapa de depuración. Durante esta etapa se pedirá a cada desarrollador, al igual que en el caso anterior, que consignen el tiempo invertido en depurar el código en el sistema ICEBERG, para lo cual, deberán nuevamente tomar los tiempos de inicio y fin de las sesiones de depuración, y esto se realizará de manera diaria. Al final deberán consignar los tiempos obtenidos junto con la cantidad de líneas de código en el sistema ICEBERG el cual se encargará de realizar el cálculo del indicador.

En el último caso, durante el subproceso de inspección del código, el líder de desarrollo se encargará de realizar una última inspección al código correspondiente a cada uno de los módulos desarrollados por los desarrolladores. Durante esta revisión, éste resaltará todos los puntos críticos, y así mismo, los errores en caso de que estos existan. Si hay errores, el código deberá ser corregido por el desarrollador encargado del módulo, con lo que se entrará en una tercera etapa de depuración del código. En este caso, al igual que en los casos anteriores, cada desarrollador deberá consignar el tiempo invertido en depuración del código en el sistema ICEBERG, para lo cual deberá observar los tiempos de inicio y fin, y así mismo la cantidad de líneas del código que están siendo depuradas, y esto deberá ser realizado de manera diaria. El sistema ICEBERG se encargará de realizar el cálculo del indicador, con el fin de monitorear periódicamente el desempeño de los desarrolladores.


9.3.4.7 I.7: Productividad individual por KLOC

Este indicador mide la cantidad de horas hombre invertidas en la escritura del código del producto, y se mide como la cantidad de horas invertidas en el desarrollo del código dividido entre el número de miles de líneas de código (KLOC) escritas. Esta métrica pretende medir el desempeño de los desarrolladores, y tener un control periódico de la productividad individual de cada uno.

91

�� =�� ó�

�� !� � ��

Este indicador se toma en el subproceso de codificación, como se observa en el Anexo 40, con el fin de medir el desempeño de los desarrolladores, quienes son los responsables de crear el código del producto. Para su medición, se pedirá a cada desarrollador que registre en el sistema ICEBERG el tiempo invertido en generación del código. Por tanto, cada desarrollador deberá tomar el tiempo de inicio y fin de la sesión de trabajo, observando este en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y al finalizar cada sesión deberá registrar dichos datos, junto con el número de KLOC escritas en el sistema ICEBERG, el cual realizará el cálculo del indicador de productividad diariamente, con el fin de llevar un registro periódico de la productividad.


Este indicador se medirá diariamente y por persona, con el objetivo de analizar el rendimiento en la generación de código de los desarrolladores, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.3.4.8 I.8: Efectividad de la inspección

Este indicador corresponde al cociente entre la cantidad de horas empleadas en la revisión del código por parte del líder de desarrollo y la cantidad de KLOC (Miles de líneas de código) revisadas. A través de este indicador se puede saber la velocidad a la que el líder de desarrollo realiza la tarea de revisión de las líneas de código. De este modo, se puede conocer el tiempo dedicado a la revisión durante el desarrollo del proceso de implementación, y así mismo se puede medir el desempeño del encargado de la revisión.

�� ó� =�� ó� �� ó��

�� !� ��

Este indicador se mide en el proceso inspección de código, como se puede observar en el Anexo 40. Para ello, el líder de desarrollo, quien es el encargado de realizar la revisión en este proceso, realizará una sesión de revisión del código, una vez que este haya sido testeado por los desarrolladores durante el subproceso de pruebas unitarias. Para su medición, el líder de desarrollo deberá consignar la hora de inicio de la sesión de revisión, tomando el tiempo en cualquier dispositivo que tenga a su disposición (reloj, teléfono, computador, entre otros), y así mismo, deberá consignar el tiempo de culminación de la sesión de revisión y el número de

92

KLOC revisadas. Si la sesión de revisión se divide en varias partes, el líder de desarrollo deberá consignar el tiempo de inicio y fin de cada una de las sesiones.

Posteriormente, el encargado de la revisión debe registrar los datos obtenidos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador. Dentro de este sistema, se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan y realizar las comparaciones pertinentes, estas fueron descritas anteriormente.

Este indicador se medirá diariamente, en el proceso de inspección de código, con el objetivo de analizar el rendimiento del inspector en cada revisión, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.3.4.9 I.9: Eficiencia de corrección de errores

Este indicador corresponde al cociente entre la cantidad de defectos resueltos por el desarrollador y la cantidad de defectos totales detectados por el líder de desarrollo. Este indicador permite observar el porcentaje de los errores que han sido resueltos al momento de la medición. De esta forma, se puede evaluar el rendimiento de la persona encargada en realizar las correcciones.

�� ó� �� =��

��

Este indicador se mide al finalizar el subproceso inspección de código, como se puede observar en el Anexo 40, los encargados de realizar las correcciones de los errores detectados por el líder de desarrollo son los desarrolladores designados para esta tarea. Para la medición de este indicador, se le pedirá el líder de desarrollo ingresar la cantidad total de defectos encontrados durante la revisión del código y se les solicitará a los desarrolladores que realicen las correcciones, registrar dentro del sistema ICEBERG la cantidad de errores resueltos por sesión.

Como se mencionó anteriormente, los encargados de las correcciones deben registrar los datos obtenidos en el sistema ICEBERG y este se encargará de realizar el cálculo del indicador. Dentro de este sistema, se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan y realizar las comparaciones pertinentes.

93

Este indicador se medirá por sesión y para cada desarrollador, con el objetivo de analizar el rendimiento en la resolución de los errores en el código, de tal forma que se puedan tomar acciones correctivas a tiempo, en el caso que el rendimiento no sea el esperado.

9.3.4.10 I.10: Progreso del testeo

Este indicador consiste en la cantidad de pruebas unitarias que han sido satisfactoriamente concluidas en el tiempo. Durante el subproceso de pruebas unitarias, se requiere que cada uno de los módulos en los que se ha dividido el proyecto pase por pruebas que verifiquen el correcto funcionamiento del código. En total, la cantidad de pruebas satisfactorias que es necesario alcanzar corresponde con el número de módulo o componentes del proyecto (es necesario que cada módulo cumpla con los requisitos propuestos en las listas de verificación previamente definidas por la compañía), y con el fin de medir el rendimiento de este subproceso en conjunto, se implementará este indicador, en el cual se medirá semanalmente la cantidad de pruebas (o módulos) que han concluido satisfactoriamente.

Con el fin de que esta medición sea comparable, es decir, que se pueda extraer información de esta, se definirá un gráfico de control que permitirá entender el estado del proceso de testeo. Dicho gráfico incluirá los límites de control superior e inferior de la cantidad de pruebas satisfactorias que se quisiera tener para cada semana, hasta un número máximo de semanas que se considerará como el plazo máximo para entregar todos los módulos funcionales sin retrasar la entrega del proyecto.

Los límites superior e inferior que estarán en el gráfico de control, correspondientes a la cantidad de pruebas satisfactorias máximas y mínimas esperadas por semana, se obtendrán en base a valores históricos de pruebas unitarias de proyectos similares pasados. La idea de este indicador es que el número de pruebas satisfactorias para cada semana se encuentre siempre entre el valor máximo y mínimo definidos por el gráfico de control para esa semana, y en caso de que esto no suceda, se apliquen medidas correctivas inmediatas (por ejemplo, observando en los tiempos de depuración de cada desarrollador los valores críticos) de modo que la fecha estipulada para la conclusión del proyecto no se retrase.

Para la medición de este indicador, se pedirá a cada uno de los desarrolladores encargados de realizar las pruebas unitarias que consignen en el sistema ICEBERG el momento en el que el módulo o componente se encuentre listo, en el sentido de que ha concluido las pruebas unitarias satisfactoriamente. El sistema ICEBERG se encargará entonces de contar el número de módulos listos, y así mismo, de entregar de manera semanal el gráfico del progreso de testeo.

Dentro del sistema ICEBERG se implementará una tarjeta de Balanced Scorecard, la cual incluirá los detalles y características de este indicador. A partir de la cual se realizará la comparación de cómo es la medición actual con respecto a los rangos y criterios. Por lo tanto, cuando el sistema ICEBERG realice el cálculo del indicador, el resultado será agregado

94

automáticamente por el sistema a la plantilla del Balanced Scorecard, de tal forma que se puedan realizar las comparaciones pertinentes.


Los valores de tolerancia de los indicadores presentados anteriormente en la sección 9.3.4 fueron determinados por medio de un juicio de expertos, a través del cual se llegó a un acuerdo de los niveles de aceptación iniciales para los indicadores. Estos se pueden observar posteriormente en el Anexo 41.

Índice global de productividad del proyecto (IGP)

Este indicador permite conocer el estado general de la productividad de un proyecto. Su medición consiste en la suma de las ponderaciones de las fases y se mide en una escala que va desde 1, que corresponde a una baja productividad, hasta 10, que corresponde a una alta productividad.

Como se mencionó anteriormente cuando los encargados de realizar las mediciones para obtener los distintos indicadores ingresan la información tomada al sistema ICEBERG, este realiza el cálculo del indicador y agrega dicha información a la plantilla del Balanced Scorecard. De inmediato el sistema le muestra al usuario el resultado del indicador, el cual es evaluado en una escala de 1 a 10, donde 1 hace referencia a una baja productividad y 10 a una alta productividad. Para el cálculo del rendimiento de los indicadores se creó una matriz de unificación por medio de la cual se pueden unificar los valores de estos para obtener el IGP, puesto que los indicadores no tienen la misma unidad de medida.

Posteriormente, el sistema ICEBERG agrega el valor obtenido para cada indicador según la escala de evaluación a la columna ponderación. En los casos donde se calculan indicadores semanalmente o por sesión, al finalizar los subprocesos, el sistema ICEBERG calcula el promedio de los indicadores parciales obtenidos y agrega dicha información en la columna ponderación. Es importante mencionar que, la columna ponderación se compone de dos elementos: casillas amarillas y verdes. Las primeras contienen los valores estándar del peso que tiene cada indicador en los subprocesos. Las segundas casillas son completadas automáticamente por el sistema ICEBERG con la información final obtenida de los indicadores, como se explicó anteriormente.

Al finalizar cada proceso (requerimientos, diseño o implementación), el sistema ICEBRG procede a realizar el cálculo de la calificación, el cual consiste en multiplicar el valor obtenido en la escala de evaluación de cada indicador por el peso que tiene el mismo en el proceso, de tal forma que se pueda proceder a realizar la suma ponderada de todos los indicadores para cada proceso. Es importante resaltar que el valor obtenido en la calificación representa el rendimiento general del proceso, este se evalúa de igual forma que el IGP, en una escala de 1 a 10. Así pues, la empresa podrá conocer el rendimiento general de cada proceso (requerimientos, diseño o

95

implementación) sometido a evaluación, inmediatamente después de finalizar las actividades que contiene cada uno.

Cuando los tres procesos han sido totalmente finalizados el sistema ICEBERG procede a realizar el cálculo de la ponderada, el cual consiste en multiplicar el valor obtenido previamente en la calificación de cada indicador, por el porcentaje que ha sido asignado a cada proceso, dicho porcentaje representa el peso que tiene cada proceso en el rendimiento general de un proyecto. Posteriormente, al obtener las ponderadas de los tres procesos, se realiza el cálculo del IGP, el cual consiste en realizar la suma de las tres ponderadas. Así pues, este indicador le permitirá conocer a la empresa como fue el rendimiento general de un proyecto, en base a los indicadores calculados en cada proceso.

En el Anexo 41 se puede observar el Balanced Scorecard diseñado para la empresa Expert Information SAS, en base a la información planteada en las secciones anteriores.

96

10. Conclusiones

Se realizó un análisis preliminar de los procesos que realiza actualmente la compañía Expert Information SAS y se encontró que esta no sigue el proceso de Rendimiento Organizacional planteado por el modelo CMMI DEV 1.3 nivel de madurez 4. Por a lo anterior, este trabajo de grado se dedicó a desarrollar todas las actividades descritas por el modelo CMMI DEV 1.3 para el proceso de Rendimiento Organizacional, con el fin de generar una propuesta de implementación de este proceso acorde a las necesidades de la compañía.

Se encontró que los procesos ideales para la implementación de los indicadores de rendimiento son los procesos de requerimientos, diseño e implementación, enfocándose en los subprocesos de estos que llevan el mismo nombre. Lo anterior, se debe a que, por medio de un juicio de expertos, donde participaron los gerentes y los líderes de proyectos de la compañía, se concluyó que eran estos procesos los que mayor relevancia tenían en el desempeño de los proyectos.

A partir de un análisis detallado que se realizó a los subprocesos considerados para la implementación del modelo de rendimiento organizacional, se definieron indicadores relevantes para cada subproceso considerado, ocho, cinco y diez para requerimientos, diseño e implementación respectivamente y se planteó un indicador general IGP para medir el rendimiento general del proyecto. Se realizó una investigación de los indicadores de rendimiento propuestos por diversos autores y en reuniones con la gerencia de Expert Information SAS se definió cuáles de estos eran los más significativos para cada subproceso. Este modelo fue presentado ante la gerencia de la compañía en una reunión, durante la cual se socializaron los indicadores y la metodología utilizada para su medición, socialización en la cual la empresa se mostró de acuerdo con la propuesta presentada.

Se espera obtener mejoras en el rendimiento de la compañía en una real implementación de la propuesta de diseño del Rendimiento Organizacional, dado que esta fue basada en las necesidades actuales de la compañía. Se espera que con este modelo la empresa pueda detectar a tiempo fallas de rendimiento dentro del proceso, de tal forma que su corrección sea temprana y no genere retrasos en los tiempos de desarrollo de los proyectos. Es importante resaltar, que si la empresa realiza cambios en sus procesos esta propuesta deberá ser analizada nuevamente, dado que al cambiar los procesos de la compañía pueden cambiar los puntos críticos de rendimiento en esta.

Finalmente, se destaca la importancia de esta tesis para los ingenieros industriales e ingenieros de sistemas, ya que es una referencia de cómo se definen los procesos en una industria de desarrollo de software, como se determinan indicadores que permiten medir el desempeño organizacional y como se realiza la unificación de multicriterios con diferentes escalas de medición.

97

11. Recomendaciones

En base al trabajo elaborado con la organización y a la propuesta realizada para mejorar el rendimiento de la empresa, a continuación, se realiza la descripción de algunas recomendaciones con la finalidad de realizar una adecuada implementación de la propuesta del rendimiento organizacional y preservar las implementaciones realizadas previamente por la compañía del modelo CMMI DEV 1.3.

Realizar capacitaciones a los empleados en un cambio de mentalidad, puesto que la presente propuesta de implementación está basada en la confianza al empleado, es importante que estos comprendan que la empresa no los va a despedir por obtener un mal rendimiento de vez en cuando, por el contrario, la empresa quiere conocer donde están fallando sus empleados para generar estrategias de mejora continua y que de esta forma puedan mejorar su rendimiento.

Capacitar a los empleados en los procesos del modelo CMMI DEV 1.3, de tal forma que con el tiempo este se impregne en la cultura organizacional de la compañía, perdure en el tiempo y se puedan obtener los resultados esperados de las implementaciones realizadas.

Actualizar semestralmente o anualmente los valores medios y varianza de los indicadores definidos en la presente investigación con la finalidad de conocer la evolución en el rendimiento general de la compañía y generar estrategias de mejora continua.

Continuar el trabajo de mejora continua que se ha venido realizando en la organización con el proceso siguiente de CMMI DEV 1.3 nivel de madurez 4 (gestión cuantitativa de proyectos) de tal forma que se complete la mejora de los procesos en lo concerniente al nivel de madurez 4: Administrado cuantitativamente.

Reunir por lo menos un año de toma de métricas para los indicadores definidos en la presente investigación de tal forma que se cuente con datos históricos suficientes para determinar los modelos de optimización que se requieren en los procesos de CMMI DEV 1.3 nivel de madurez 5.

98

12. Referencias

Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D. (2001). Manifiesto Ágil para el desarrollo de software. Utah, Estados Unidos. Recuperado de: http://www.agilemanifesto.org/iso/es/

Díaz, Y. (2009). Estudio sobre la correspondencia entre prácticas ágiles y su aplicación en PYMES (Tesis de Magister). Universidad Politécnica de Madrid, Madrid.

Expert Information S.A.S (2016). Expert: Nosotros. Cali: Expert Information SAS. Recuperado de http://expertla.com.co/quienes-somos/

Expert Information SAS. (2016). Documentos privados de la empresa. Cali, Colombia.

Gallardo (2016). Documentación e implementación de las áreas de procesos PP (Planificación del proyecto), RSKM (Gestión de riesgo) y DAR (Análisis de decisión y resolución) para la valoración de Expert Information SAS en CMMI DEV 1.3 nivel 3 (Tesis de pregrado). Universidad Javeriana Cali, Cali.

Microsoft. (2017). Team Foundation Server. Recuperado de: https://www.visualstudio.com/es/tfs/

MINTIC (2015). MINTIC: Colombia líder en la región en la producción de software de calidad. Bogotá: Ministerio de Tecnologías de la Información y las Comunicaciones. Recuperado de: http://www.mintic.gov.co/portal/604/w3-article-8571.html

Palacio, J. (2014). Gestión de proyectos Scrum Manager. Editorial: RIGHTS INFO. Recuperado de: http://www.scrummanager.net/files/sm_proyecto.pdf

Paolini, A. (2013). Implementación de área de proceso de gestión de riesgos de CMMI v.1.3 Utilizando metodologías de la información (Tesis de Magister). Universidad de Chile, Chile.

PowerDesigner. (2016). SAP Sybase PowerDesigner 16.6. Recuperado de: http://powerdesigner.de/en/

Pressman, R. S. (2011). Ingeniería del software, un enfoque práctico. Madrid, España: Mc Graw Hill.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK Guide). Pensilvania, EE.UU: Project Management Institute.

Sánchez, A. (2014). Modelo de prácticas esenciales de la metodología DAC integrando los métodos ágiles, PMBOK y CMMI DEV. IUSH, 12.

99

Sanz, S (2009). Implementación de CMMI en pequeñas empresas de desarrollo de software (Tesis de Magister). Universidad Politécnica de Valencia, Valencia.

Scrummanager. (2016). Scrum Manager v.2.6. Recuperado de: http://www.scrummanager.net/files/scrum_manager.pdf

Software Engineering Institute. (2010). Desempeño de los procesos en la Organización CMMI® para Desarrollo. V1.3, Pittsburgh, Estados Unidos: Carnegie Mello.

Sommerville, I. (2005). Ingeniería de software, séptima edición. Madrid, España: Editorial Pearson.

Sparxsystems. (2017). Enterprise Architect. Recuperado de: http://www.sparxsystems.eu/start/home/

Yépez, W., Primera, C., y Torres, M. Journal Compendium. (2013). Mejoras al proceso de planificación de proyectos de software usando el modelo de madurez de capacidad integrado (CMMI), Vol. 16 Issue 30, pp 27-47. 21p. Recuperado de: http://bdbib.javerianacali.edu.co:2275/ehost/pdfviewer/pdfviewer?sid=44f3a2fa-8128-47b3-be65-e1c430a92635%40sessionmgr4002&vid=1&hid=4206

13. Anexos

Representación por etapas y representación continua. Fuente: Díaz (2009).

Proceso de desarrollo de software.

Organigrama.

Inspección por recorridoInspección por recorrido

ProductorProductor InspectorInspector

Inicio

Preparación de la

inspección

Recorrido del producto

Conclusión

CorrecciónAprobación del producto

Fin

Inspección por recorrido.


Equipo asignadoGerente del proyecto

Inicio

Revisión de acciones

correctivas


Definición de acciones

correctivas

Reporte de estatus

Administración de la

configuración

Fin

Monitoreo del proyecto.


Equipo del proyectoGerente del proyecto

Inicio


Identificación de tareas de

involucrados

Identificación de elementos de

configuración y líneas base

Definir procedimientos de

administración de la configuración

Fin

Plan de administración de la configuración.

Planeación de actividades cortas

Equipo de trabajoGerente del proyecto

Inicio

Definición de product backlog

items

Disponibilidad por recurso

Asignación de product backlog

items

Definición de actividades al

product backlog item

Generar reporte

Fin

Planeación de actividades cortas.

Revisiones mayores

Gerente del proyecto

Inicio


Evaluación de la línea

base




Fin

Revisiones mayores


Equipo asignado al proyecto

Inicio

Definición de criterios de selección

Selección de métodos de evaluación

Identificación de

alternativas

Fin

Selección de solución

Selección de alternativas.

Fase de pre-análisis.

Pre-análisisPre-análisis

Gerente comercialGerente comercial Equipo pre-análisisEquipo pre-análisis ClienteCliente

Inicio

Selección de equipo de

trabajo

Planeación del pre-análisis

Levantamiento de

requerimientos generales

Resolución de dudas

Documentar pre-análisis

Revisión del cliente y ajuste de hallazgos

Aprobación del cliente

Fin

Pre-análisis.



Gerente del proyectoGerente del proyecto

Inicio

Evaluación de características

del equipo

Revisión de disponibilidad

de recursos

Asignación de recursos

Fin

Selección de equipo de trabajo.

Estimación inicial de proyectosEstimación inicial de proyectos

Gerente comercial/ Gerente desarrolloGerente comercial/ Gerente desarrollo

Administrador comercial

Administrador comercial

EstimadorEstimador

Inicio

Asignar responsable

Preparar estimación

Inicio de la reunión

Fin

Definición de actividades de

análisis del sistema

Definición de actividades de

estimación

Aplicar modelo de estimación

Documentar estimación

Estimación inicial de proyectos.

Fase de planeación.

Planeación del proyectoPlaneación del proyecto

Gerente comercialGerente comercial Gerente del proyectoGerente del proyecto Líder de calidadLíder de calidad

Inicio

Preparación de la planeación

Fin

Revisión de la estimación

Selección de equipo de

trabajo

Identificación de involucrados

relevantes

Integración del comité de control de cambios

Calendario

Ambiente de trabajo


Plan de administración

de la configuración

Adaptaciones al proceso

Plan de soporte

Plan de conocimientos y habilidades

Plan de administración

de riesgos

Plan de análisis formal de decisiones

Plan de sub-contratación

Aprobación de los planes


configuración

Lecciones aprendidas

Proceso de planeación del proyecto.



Líder de calidadLíder de calidad

Inicio


Identificación de responsables

Plan de auditorias de

proceso

Plan de auditorias de

producto

Fin

Plan de aseguramiento de la calidad.

Análisis de riesgosAnálisis de riesgos

Equipo asignadoEquipo asignado Gerente generalGerente general

Inicio

Identificación de riesgos

Análisis cualitativo del

riesgo

Plan de seguimiento y

respuesta

Almacenar plan administración

de riesgos

Fin

Análisis de riesgos.

Desarrollo de softwareDesarrollo de software

Gerente comercialGerente comercial Fábrica de softwareFábrica de software ClienteCliente

Inicio

Entrega de documentación

inicialPre-análisis

Selección del gerente del proyecto

Planeación del proyecto

Requerimientos

Diseño

Implementación

Pruebas de despliegue

Pruebas de aceptación

Corrección de defectos de pruebas de aceptación

Liberación a producción

Cierre del proyecto

Fin

Desarrollo de software.



Equipo de trabajoEquipo de trabajo

Inicio

Identificación de decisiones que requieren análisis formal



configuración

Fin

Análisis de decisiones y resolución.

Fase de requerimientos.

RequerimientosRequerimientos

Equipo de requerimientos

Equipo de requerimientos

Analista funcionalAnalista funcional Equipo del proyectoEquipo del proyecto Líder funcionalLíder funcional Líder de calidadLíder de calidad Gerente de proyectosGerente de proyectosAdministrador de la

configuraciónAdministrador de la

configuración

Inicio

Plan de recolección de requerimientos

Obtención de los

requerimientos

Identificación y priorización de

atributos de calidad (IPAC)

Especificación de

requerimientos

Inspección del SRS

Solicitar aprobación del

cliente

Correcciones Plan de pruebasInspección plan

de pruebasLínea base de requerimientos

Fin de ciclo

Fin

Requerimientos.

No.

Nombre

Descripción

Actores

Guion Actor Sistema

Excepciones

Casos de uso

relacionados

Documentos

Relacionados

Requerimiento

Fuente

Autor

Revisado por

Fecha

Creación

Fecha de

Ultima

Modificación

Formato de casos de uso.

Fase de diseño.

DiseñoDiseño

Equipo de diseñoEquipo de diseño Líder de desarrolloLíder de desarrollo Arquitecto de softwareArquitecto de softwareAdministrador de la

configuraciónAdministrador de la

configuración

Inicio

Diseño estructural

Primera etapa del diseño

Pasos de diseño subsecuentes

Especificación de diseño del

sistema

Estrategia de integración

Inspección al diseño de alto

nivel

Fin

Línea base del diseño

Fin de ciclo

Diseño.

Fase de implementación.

ImplementaciónImplementación

DesarrolladoresDesarrolladores Líder de desarrolloLíder de desarrollo Equipo de desarrolloEquipo de desarrollo Gerente del proyectoGerente del proyecto

Inicio

Identificación de

componentes y sus actividades

Diseño detallado

Inspección del diseño

detallado

Codificación

Pruebas unitarias

Inspección de código

Fin

Entrega de componentes o

módulos completos

Línea base del código

Fin de ciclo

Implementación.

Fase de implantación

Pruebas de desplieguePruebas de despliegue

Equipo de desarrolloEquipo de desarrollo Equipo de pruebasEquipo de pruebas

Inicio

Despliegue a ambiente de

pruebas

Pruebas de integración y

pruebas funcionales

Pruebas de sistema


configuración

Fin

Fin de ciclo

Pruebas de despliegue.

Despliegue a ambiente de pruebas

Líder de DesarrolloEquipo de Desarrollo Arquitecto de SoftwareAdministrador de la

configuración

Inicio

Inspección de estrategia de integración

Manual de instalación

Inspección manual de instalación

IntegraciónDespliegue a ambiente de

pruebas

Inspección de la integración

Fin

Proceso despliegue a ambiente de pruebas.

Pruebas de integración y funcionalesPruebas de integración y funcionales

Equipo de pruebasEquipo de pruebas Equipo de desarrolloEquipo de desarrollo Líder de calidadLíder de calidadDocumentador técnico y/o analista de calidadDocumentador técnico y/o analista de calidad

Inicio

Diseño de casos de prueba

Ejecución pruebas de

integración y pruebas

funcionales

Corrección de no

conformidades

Pruebas de Re-Testing

Fin

Pruebas de regresión

Resumen de datos de las

pruebas

Manual de usuario

Inspección manual de

usuario

Entrega al cliente del producto probado

Pruebas de integración y funcionales.

Pruebas de sistemaPruebas de sistema

Equipo de pruebasEquipo de pruebas Equipo de desarrolloEquipo de desarrollo Líder de calidadLíder de calidad

Inicio

Ejecución de pruebas de

sistema

Corrección de no

conformidades

Pruebas de Re-Testing

Fin

Pruebas de regresión

Resumen de datos de las

pruebas

Entrega al cliente del producto probado

Pruebas de sistema.

Cierre del proyectoCierre del proyecto

Gerente del proyectoGerente del proyecto

Inicio

Evaluación de la línea base


Fin



Inspección final

Cierre del proyecto

Cronograma de trabajo.

Proceso seleccionado para realizar las mediciones.

Subprocesos seleccionados para medición en la fase de requerimientos.

Proceso seleccionado

para medición

Pantalla de ingreso de datos.



para medición

Subprocesos seleccionados para medición en la fase de diseño.



para medición

Subprocesos seleccionados para medición en la fase de implementación.

Calificación 0 Ponderada 0

Valor Medio Desviación Ponderación

Se toma el tiempo desde el inicio de la reunión con el cliente, hasta la

finalización de la misma.10 6 5 3 1 0,05

Se cuenta la totalidad de los requerimientos recolectados en la

reunión.1 1,3 1,5 1,7 2

Se toma el tiempo desde el inicio de la sesión de documentación, hasta la


Se cuenta la totalidad de los requerimientos documentados

totalmente en la sesión.0,5 0,7 1 1,3 1,5

Se toma el tiempo total que le toma al encargado realizar la revisión del

respectivo documento.10 6 5 3 1 0,1

Se cuentan las páginas totales que tiene el documento sometido a

revisión.0,2 0,3 0,4 0,7 1

Se toma el tiempo total que le toma al encargado realizar la revisión del

respectivo documento.10 6 5 3 1 0,1

Se cuentan las páginas totales que tiene el documento sometido a

revisión.0,2 0,3 0,4 0,7 1

10 6 5 3 1 0,05

1 1,3 1,5 1,7 2

Se toman la cantidad de errores mayores identificados en el

documento.10 6 5 3 1 0,1

Se cuentan la cantidad de requerimientos que contiene el

documento.0,1 0,13 0,15 0,17 0,2

Se toman la cantidad de errores mayores identificados en el

documento.10 6 5 3 1 0,1


documento.0,1 0,13 0,15 0,17 0,2

Se cuentan la cantidad de requerimientos desaprobados por el

cliente.10 6 5 3 1 0,1


documento previo al proceso de correcciones.

0,95 0,9 0,8 0,7 0,5

Se cuenta el tiempo total que emplea el analista funcional en la corrección

de los errores detectados.10 6 5 3 1 0,05

Se cálcula como la cantidad de errores mayores y errores menores

registrada en el proceso de inspección del SRS.

1 1,3 1,5 1,7 2

Se cuenta el tiempo total que emplea el analista funcional en la corrección

de los errores detectados.10 6 5 3 1 0,05

Se cálcula como la cantidad de errores mayores y errores menores

registrada previo al inicio del proceso de correcciones.

1 1,3 1,5 1,7 2

Se cuenta el tiempo total que emplea el gerente del proyecto en la

corrección de los errores detectados.10 6 5 3 1 0,1

Se cálcula como la cantidad de errores registrados en el proceso de

inspección plan de pruebas.1 1,3 1,5 1,7 2

Se cuentan los errores mayores totales encontrados en la inspección

del SRS.10 6 5 3 1 0,1

Se cuentan la totalidad de pasos escritos dentro de los guiones de los

casos de uso detallados documentados en el SRS.

0,1 0,13 0,15 0,17 0,2

1 hora 0,5 horas

Fase

de

requ

erim

ento

s

Proceso de correcciones.

Mejorar el rendimiento del analista funcional en

las correcciones de errores detectados.

Esfuerzo de repetición/Cantidad de

correcciones.Tiempo Analista funcional.

Se medirá cada vez que se realicen correcciones de los

errores detectados por el cliente en el proceso de solicitar aprobación del cliente.

R.7.3Proceso de

inspección plan de pruebas.

Mejorar el rendimiento del gerente del proyecto en las correcciones de

errores detectados.


correcciones.Tiempo Gerente del proyecto.


errores detectados en el proceso de inspección plan de

pruebas.

ResultadoObjetivo

Conformidad de los requerimientos.

Mejorar el rendimiento del análista funcional durante el proceso de

obtención de los requerimientos.

Esfuerzo de evaluación/Páginas del

documento.

0,1 0,05Líder funcional

Análista funcional

Se realizará esta medicion cada vez que el líder funcional

realice la inspección del SRS.

Se medirá este indicador cada vez que se le solicite al cliente la aprobación del documento de

requerimientos.

0,5 horas

Indicador Unidad de medida Explicación/ Justificación

Proceso de inspección del

SRS.

1 hora 0,5 horas


errores detectados en el proceso de inspección del SRS.

Proceso de inspección del

SRS.

Mejorar el rendimiento del analista funcional en

las correcciones de errores detectados.


correcciones.Tiempo Analista funcional.

Se realizará el cálculo de este indicador cada vez que se

revise un documento.0,2 horas 0,1 horas

Esfuerzo de evaluación/Páginas del

documento.Tiempo

Se realizará el cálculo de este indicador cada vez que se

revise un documento.

Mejorar el rendimiento del análista funcional en

las inspecciones.Líder funcional

Gerente del proyecto.Mejorar el rendimiento

del gerente de proyectos en las inspecciones.

Tiempo

0,1 0,05

Responsable de la medición

Periodicidad

0,5 horas 0,1 horas

Se realizará el cálculo de este indicador en cada reunión con

el cliente para la toma de requerimientos.

Proceso obtención de

requerimientos.

Mejorar el rendimiento del análista funcional en

la obtención de los requerimientos.

Tiempo empleado en entrevistas con el

cliente/Cantidad de requerimientos.

Tiempo Analista funcional.

Se realizará el cálculo de este indicador en cada sesión de

documentación de requerimientos.

Mejorar el rendimiento del análista funcional en ela documentación de los

requerimientos.

Proceso especificación

de requerimientos.

Tiempo empleado en documentar los

requerimientos/Cantidad de pasos en los guiones de casos

de uso detallados.

Tiempo Analista funcional

1 hora 0,5 horas

R.5.2Proceso de

correcciones.

Mejorar el rendimiento del análista funcional durante el proceso de específicación de los

requerimientos.

Errores mayores detectados/Cantidad de

requerimientos.Adimensional

R.5.1 AdimensionalProceso de

inspección del SRS.


requerimientos.

Mejorar el rendimiento del análista funcional durante el proceso de específicación de los

requerimientos.

R.8Proceso de

inspección del SRS.

Mejorar el rendimiento del análista funcional durante el proceso de

especificación de requerimientos.

Densidad del error Adimensional Analista funcionalSe medirá cada vez que se

realice el proceso de inspección del SRS.

0,1 0,05

R.6 0,95 0,05Proceso de

correcciones.Analista funcional

Se medirá cada vez que se realicen correcciones por desaprobación del cliente.

Porcentaje

R.7.1

1 hora 0,5 horas

R.7.2

Ponderación total 30%

R.4

Proceso de plan de recolección

de requerimientos.

Mejorar el rendimiento del equipo de

requerimientos en las actividades previas a la

toma de los requerimientos.

Esfuerzo de preparación. Tiempo

Se toma el tiempo que emplea el equipo de requerimientos en

desarrollar las actividades previas a la toma de requerimientos.

Equipo de requerimientos.

Se realizará el cálculo de este indicador una vez, al finalizar el proceso de plan de recolección

de requerimientos

1 hora

EscalaAbreviatura

R.1

R.2

R.3.1

R.3.2 0,2 horas 0,1 horasProceso de

inspección plan de pruebas.

Dónde se mide?Rangos y criterios

Calificaciòn 0 Ponderada 0

Valor medio Variación Ponderación

Se toma el tiempo desde el inicio de la sesión de documentación hasta la


Se cuenta la cantidad de páginas documentadas en la sesión.

3 3,5 4 4,3 4,5




3 3,5 4 4,3 4,5




2 2,5 3 3,3 3,5




3 3,5 4 4,3 4,5

El tiempo total empleado en la revisión de un documento.

10 6 5 3 1 0,05

Cantidad de páginas que contiene el documento.

2 2,5 3 3,3 3,5


10 6 5 3 1 0,1


2 2,5 3 3,3 3,5

Se toman en cuenta la cantidad total de los errores mayores detectados.

10 6 5 3 1 0,05

Se toman en cuenta la cantidad total de artefactos inspeccionados.

0,1 0,15 0,2 0,3 0,4


10 6 5 3 1 0,1

Se toman en cuenta la cantidad total de artefactos inspeccionados.

0,1 0,15 0,2 0,3 0,4

Se toma en cuenta la cantidad total de tiempo empleado por persona en realizar correcciones de errores

mayores.

10 6 5 3 1 0,1

Se toma en cuenta la cantidad total de errores mayores detectados.

2 2,5 3 3,3 3,5

Se toma en cuenta la cantidad total de tiempo empleado para realizar la corrección de errores mayores.

10 6 5 3 1 0,1


2 2,5 3 3,3 3,5

Se toma el tiempo desde el inicio de la sesión de desarrollo de artefactos

hasta la finalización de la misma.10 6 5 3 1 0,05

Se cuenta la cantidad de artefactos realizados.

3 3,5 4 4,3 4,5




3 3,5 4 4,3 4,5




3 3,5 4 4,3 4,5

Fase

de

dise

ño

Adimensional.

Tiempo.

Tiempo.

Tiempo.

Tiempo.

Tiempo.

Tiempo.

1 hora

1 hora

0,05

1 hora

D.5.3Proceso de los

pasos de diseño subsecuentes.

Mejorar la productividad de los miembros del

equipo de diseño.

Horas hombre reales/Cantidad de artefactos desarrollados.

Cada miembro del equipo de diseño.

Semanalmente. 3 horas 1 hora

Tiempo.D.5.2Proceso de la

primera etapa de diseño.


equipo de diseño.



Semanalmente. 3 horas

Tiempo.

D.5.1Proceso de

diseño estructural.


equipo de diseño.



Semanalmente. 3 horas 1 hora

D.4.2

Proceso de inspección al diseño de alto

nivel.

Mejorar el rendimiento del arquitecto de software

en la corrección de los errores mayores.


correcciones.Arquitecto de software

Se realizará al finalizar el proceso de inspección al diseño

de alto nivel.2 horas

D.4.1Proceso de


Mejorar el rendimiento del equipo de diseño en

la corrección de los errores mayores.


correcciones.


Se realizará al finalizar el proceso de pasos de diseño

subsecuentes.2 horas 1 hora

D.3.2


nivel.

Mejorar el rendimiento del equipo de diseño en el la documentación y desarrollo del diseño.


artefactos inspeccionados.Arquitecto de software

Se realizará el cálculo de este indicador al finalizar el proceso de inspección al diseño de alto

nivel.

0,1

D.3.1Proceso de


Mejorar el rendimiento del equipo de diseño en el la documentación y desarrollo del diseño.


artefactos inspeccionados.Equipo de diseño.

Se realizará el cálculo de este indicador al finalizar el proceso

de pasos de diseño subsecuentes.

0,1 0,05Adimensional.

D.2.2


nivel.

Mejorar el rendimiento de cada integrante del equipo de diseño en la

revisión de la documentación.

Esfuerzo de evaluación/Páginas del documento revisado.


Se realizará el cálculo de este indicador al finalilzar la

revisión de un documento.2 horas

1 hora

D.2.1Proceso de



revisión de la documentación.

Esfuerzo de evaluación/Páginas del documento revisado.


Se realizará el cálculo de este indicador al finalizar la

revisión de un documento.2 horas 1 hora

D.1.4

Proceso de especificación de diseño del

sistema.

Mejorar el rendimiento del líder de desarrollo en

la documentación.

Tiempo empleado en documentación/Cantidad de

páginas documentadas.Líder de desarrollo.


generación de documentación.3 horas

1 hora

D.1.3Proceso de



documentación.


páginas documentadas.



generación de documentación.2 horas 1 hora

Tiempo.D.1.2Proceso de

primera etapa de diseño.


documentación.





generación de documentación.3 horas

Tiempo.

D.1.1Proceso de

diseño estructural.


documentación.





generación de documentación.3 horas 1 hora

PeriodicidadRangos y criterios

ResultadoPonderación total 30%

Escala

Tiempo.

Abreviatura Dónde se mide? Objetivo Indicador Unidad de medida Explicación/ JustificaciónResponsable de la

medición

Balanced Scorecard.

Calificaciòn 0 Ponderada 0

Valor Medio Variación Ponderación




3 3,5 4 4,3 4,5


10 6 5 3 1 0,05


3 3,5 4 4,3 4,5


10 6 5 3 1 0,05

Se toman en cuenta la cantidad total de páginas revisadas.

0,1 0,12 0,15 0,17 0,2

Se toma en cuenta la cantidad total de tiempo empleado para realizar la corrección de errores mayores.

10 6 5 3 1 0,05


0,5 0,6 0,7 0,8 1

Se toma en cuenta la cantidad de errores escritos en el código por

persona.10 6 5 3 1 0,05

Se cuentan las miles de líneas de código escritas por el desarrollador

en el módulo.0,01 0,012 0,015 0,017 0,02

Se toma en cuenta el tiempo que tarda en depurar un módulo.

10 6 5 3 1 0,05

Se cuentan las miles de líneas de código escritas por el desarrollador, las cuales se encuentran depurando.

0,5 0,6 0,7 0,8 1

Se toma en cuenta el tiempo que tarda en depurar un módulo.

10 6 5 3 1 0,05


0,5 0,6 0,7 0,8 1

Se toma en cuenta el tiempo que tarda en depurar un código.

10 6 5 3 1 0,05


0,5 0,6 0,7 0,8 1

Se cuenta el tiempo empleado en generar el código.

10 6 5 3 1 0,05

Se cuentan las miles de líneas de código escritas por desarrollador.

0,5 0,6 0,7 0,8 1

Se toma en cuenta el tiempo utilizado en revisar el código en la sesión.

10 6 5 3 1 0,05

Se cuentan las miles de líneas de código revisadas.

0,5 0,6 0,7 0,8 1

Se cuentan la cantidad de defectos resueltos por el desarrollador.

10 6 5 3 1 0,05

Cantidad total de defectos encontrados.

0,95 0,9 0,8 0,85 0,7

10 6 5 3 1 0,05

100% 00

Fas

e de

impl

emen

taci

ón

IGP: 0

I.10Proceso de

pruebas unitarias.

Mejorar la productividad de los desarrolladores.

Progreso del testeo Adimensional.Cantidad de pruebas

satisfactoriamente concluidas en el tiempo.

Cada desarrollador. Semanalmente. 100%

I.9Proceso de

inspección de código.

Mejorar la productividad de los desarrolladores en

la corrección de los errores detectados.

Eficiencia de corrección de errores.

Porcentaje Cada desarrollador.

Se realizará el cálculo de este indicador por sesión de

corrección de errores en el código.

0,95 0,01

I.8Proceso de

inspección de código.

Mejorar la productividad del líder de desarrollo en

la revisión del código.Efectividad de la inspección. Tiempo. Líder de desarrollo.

Diariamente al finalizar la jornada laboral.

0,5 horas 0,01 horas

I.7Proceso de

codificación.

Mejorar la productividad de los desarrolladores en la generación del código.

Productividad individual por KLOC

Tiempo. Cada desarrollador.Diariamente al finalizar la

jornada laboral.0,5 horas 0,01 horas

I.6.3Proceso de

inspección del código.

Mejorar el rendimiento de los desarrolladores en la depuración del código.

Tiempo de depuración del código/KLOC.



I.6.2Proceso de

pruebas unitarias.





I.6.1Proceso de

codificación.





I.5Proceso de

codificación.

Mejorar el rendimiento de los desarrolladores en la generación del código.

Errores escritos en el código por persona/KLOC

Adimensional. Cada desarrollador.Diariamente al finalizar la

jornada laboral. 0,01 0,005

I.4Proceso de

inspección del diseño detallado.

Mejorar el rendimiento de los desarrolladores en

la corrección de los errores mayores

detectados por el líder de desarrollo.

Esfuerzo de repetición/Cantidad de errores

identificados.Tiempo. Cada desarrollador.

Se realizará el cálculo de este indicador cada vez que los desarrolladores le realicen

correcciones de errores mayores al diseño detallado.

0,5 horas 0,01 horas

I.3Proceso de


Mejorar el rendimiento de los desarrolladores en el desarrollo del diseño

detallado.

Errores mayores/Cantidad de páginas revisadas.

Adimensional. Líder de desarrollo.

Se realizará el cálculo de este indicador cada vez que se le

realice una inspección al diseño detallado.

0,1 0,05

I.2Proceso de


Mejorar el rendimiento del líder de desarrollo en

la revisión.

Esfuerzo de evaluación/Cantidad de

páginas evaluadas.Tiempo Líder de desarrollo.

Se realizará el cálculo de este indicador al finalizar la

revisión de un documento.1 hora 0,5 horas

Ponderación total 40%Escala

I.1Proceso de

diseño detallado.

Mejorar el rendimiento del desarrollador en la

documentación.

Tiempo empleado en documentación/Páginas

documentadas.Tiempo Cada desarrollador.

Cada vez que se realice el diseño detallado de un

proyecto.1 hora 0,5 horas

Abreviatura Dónde se mide? Objetivo Indicador Unidad de medida Explicación/ JustificaciónResponsable de la

mediciónPeriodicidad

Rangos y criteriosResultado

Documents

Tesis final entrega - Javeriana, Cali