implementacion de cmmi en una compañia minera

Universidad Peruana de Ciencias Aplicadas

CMMI Capability Maturity Model Integration

Implementación de CMMI

Autor: Tirso Villanueva Ortiz

Lima, 18 de Febrero 2012

UPC

Página 2

INDICE

1. OBJETO DE ESTUDIO .............................................................................................................. 4

1.1. Descripción de la empresa ................................................................................................ 4

1.2. Misión ................................................................................................................................ 4

1.3. Visión ................................................................................................................................. 4

1.4. Organización ...................................................................................................................... 4

1.5. Objetivos del Negocio ....................................................................................................... 6

2. ALCANCE DE LA EVALUACION ............................................................................................... 9

3. FACTIBILIDAD DEL CAMBIO.- ................................................................................................. 9

3.1. Reseña sobre antecedentes de cambios de procesos: ..................................................... 9

3.2. Probables focos de resistencia: ....................................................................................... 11

4. EVALUACIÓN DE LA SITUACIÓN ACTUAL ............................................................................ 12

4.1. Procesos, mecanismos, métodos, prácticas, etc., que actualmente funcionan bien, y

que se deben mantener: ............................................................................................................. 12

4.2. Problemas u oportunidades de mejora conocidos: ........................................................ 13

4.3. Factores clave de éxito actuales: .................................................................................... 14

4.4. Descripción de las fuentes de información utilizadas ..................................................... 15

4.5. Evaluación de cumplimiento de las prácticas específicas ............................................... 17

4.5.1. Evaluación de cumplimiento de las prácticas específicas en PP ................................. 17

4.5.2. Aplicación de Metas Genéricas en Planeamiento de Proyecto .................................. 19

4.5.3. Evaluación de cumplimiento de las prácticas específicas en PMC ............................. 21

4.5.4. Aplicación de Metas Genéricas en PMC ...................................................................... 23

4.5.5. Evaluación de cumplimiento de las prácticas específicas en REQM ........................... 24

4.5.6. Aplicación de Metas Genéricas en REQM ................................................................... 25

4.6. Presentación de resultados ............................................................................................. 27

4.6.1. Por cada área de proceso, % de prácticas cumplidas y no cumplidas ........................ 27

4.6.2. % total de prácticas cumplidas y no cumplidas ........................................................... 29

5. Procesos para la organización en estudio ........................................................................... 30

5.1. Nuevo proceso establecido para la organización............................................................ 30

5.1.1. Nombre del proceso .................................................................................................... 30

5.1.2. Implementación .......................................................................................................... 30

5.1.3. Propósito del proceso ................................................................................................. 30

UPC

Página 3

5.1.4. Roles ............................................................................................................................ 30

5.1.5. Alcance del proceso .................................................................................................... 31

5.1.6. Plantillas de documentos a utilizar ............................................................................. 31

5.1.7. Descripción del proceso .............................................................................................. 32

5.1.8. Flujograma del proceso ............................................................................................... 35

5.1.9. Matriz de Trazabilidad de Procedimientos versus Prácticas Específicas .................... 37

5.2. Planificación de Proyectos .............................................................................................. 38

5.2.1. Situación problemática ............................................................................................... 38

5.2.2. Flujo del proceso ......................................................................................................... 39

5.3. Gestión de requerimientos ............................................................................................. 49

5.3.1. Situación problemática ............................................................................................... 49

5.3.2. Flujo de Proceso .......................................................................................................... 50

5.4. Definición de indicadores de mejora .............................................................................. 55

5.4.1. Propósito y alcance ..................................................................................................... 55

5.4.2. Objetivo ....................................................................................................................... 55

5.4.3. Métricas propuestas.................................................................................................... 55

5.4.3.1. Cantidad de defectos en Pruebas en ambiente de pruebas ................................... 55

5.4.3.2. Cantidad de defectos en Pruebas funcionales en ambiente de producción........... 55

5.4.3.3. Líneas de código con errores por programa ........................................................... 56

5.4.3.4. Líneas de código con errores caso de Uso ............................................................. 56

6. Conclusiones........................................................................................................................ 56

6.1. Conclusiones respecto a la madurez identificada ........................................................... 56

6.2. Proceso conveniente para comenzar .............................................................................. 57

6.3. Propuesta de indicadores de éxito .................................................................................. 57

6.4. Otras conclusiones .......................................................................................................... 57

UPC

Página 4

1. OBJETO DE ESTUDIO

1.1. Descripción de la empresa

Minsur S.A. es una empresa peruana dedicada a la explotación, procesamiento y

comercialización del estaño, así como a la exploración de nuevos yacimientos.

Minsur S.A. es una empresa minera altamente rentable y competitiva gracias a su experiencia y

a los exigentes estándares de calidad que rigen en todo el proceso productivo, desde el alto

grado de ley del mineral hasta el oportuno y satisfactorio abastecimiento de los mercados

nacionales e internacionales, disponiendo a lo largo de todo el proceso de tecnología de

vanguardia monitoreada y administrada por un equipo humano comprometido.

La empresa cuenta un área que tiene como misión la definición, implantación y administración

de las tecnologías de información, asegurándose que estén alineadas con las estrategias del

negocio y apoyando al cumplimiento de objetivos de cada área de MINSUR.

1.2. Misión

“Minsur S.A. se orienta a alcanzar y mantener elevados estándares de calidad en cuanto a

protección ambiental; establecer relaciones de responsabilidad social con sus trabajadores y

comunidades vecinas, innovar constantemente a nivel estructural y tecnológico y satisfacer a

plenitud las exigencias de los mercados internacionales de minerales”.

1.3. Visión

“Convertirnos en el mayor productor y exportador de concentrados de estaño a nivel mundial,

comercializándolos con los precios más competitivos, a través de una cadena de

abastecimiento que incurra en los mas óptimos costos de producción”.

1.4. Organización

Minsur S.A. cuenta con una estructura organizacional conformada por profesionales

distribuidos en el siguiente organigrama:

Organigrama de Minsur S.A.

Fuente: Minsur S.A.

1.5. Objetivos del Negocio

El área de Sistemas tiene como misión la definición, implantación y administración de las

tecnologías de información, asegurándose de que estén alineadas con las estrategias del

negocio y apoyando al cumplimiento de los objetivos de cada área de MINSUR.

Para cubrir sus necesidades tecnológicas, la empresa adquirió el ERP “SAP ECC 6.0”, del cual

se ha implementado los módulos de Finanzas, Logística, Mantenimiento, Producción,

Proyectos, Business Intelligent y BPC (Business Planning and Consolidation). Además, cuenta

con varios aplicativos industriales para los procesos de producción, para exploración minera y

proceso de concentración del mineral (plantas concentradoras).

Si bien es cierto que Minsur S.A. no es una empresa de tecnología, sino de extracción y

procesamiento de minerales, depende en gran medida del Área de Sistemas para el logro de

sus objetivos. Los siguientes son los lineamientos que guían las acciones de esta área:

Estrategia

o Desarrollar, conseguir la aprobación y mantener el Plan Estratégico de Sistemas,

que sea consistente con los planes y objetivos de la empresa, y este en línea con

los Presupuestos de Sistemas y Tecnología

o Mantenerse permanentemente actualizado con la evolución de las tecnologías de

información que puedan impactar positiva o negativamente a la empresa

Organización

o Asegurar que el personal del área tenga las mejores capacidades personales y

profesionales necesarias para ejecutar las funciones

o Desarrollar y mantener profesionales responsables que tengan planes de

capacitación y desarrollo profesional

o Promover el trabajo en equipo al interior del área y la empresa

Finanzas

o Responsable por la elaboración de los presupuestos de gastos e inversión en

tecnologías de información y telecomunicaciones de toda la empresa

o Monitorear y explicar las desviaciones en los presupuestos

o Cumplir y hacer cumplir las políticas financieras de la empresa

o Asegurar el control y seguimiento de los cambios en la infraestructura tecnológica

Sistemas de Información

UPC

Página 7

o Responsable por mantener, ampliar, desarrollar o adquirir los sistemas de

información que satisfagan las necesidades de la empresa, teniendo en cuenta

factores de costo-beneficio

o Definir personal responsable por el soporte a los sistemas de información en uso

o Definir metodologías, estándares y herramientas de desarrollo

o Controlar y mantener actualizada la documentación de los sistemas de información

en uso, particularmente la relacionada al usuario

Proyectos de Tecnologías de Información y Telecomunicaciones

o Responsable por todos los proyectos del área de Sistemas y Tecnología

o Definir la metodología, controles y responsables en los distintos proyectos del área

o Asegurar la disponibilidad de todos los recursos necesarios para el éxito de los

proyectos de tecnologías de información

Soporte y Operaciones

o Controlar el cumplimiento de objetivos de soporte y operaciones

o Asegurar la documentación de los distintos procesos realizados

Seguridad

o Responsable por mantener la confidencialidad, integridad y disponibilidad de la

información para la empresa

o Implementar políticas y estándares de seguridad

o Asegurar que los equipos y recursos críticos estén cubiertos por un adecuado plan

de contingencia

Proveedores

o Seleccionar a los distintos proveedores de tecnología de información y

comunicaciones calificando costos, reputación, solidez, y capacidad de soporte

o Responsable por conseguir el mejor ratio costo-beneficio

o Asegurar que todos los servicios contratados están cubiertos por un contrato

aprobado por el área legal de la empresa

o Asegurar que todos los servicios contratados tienen acuerdos de nivel de servicio.

Organigrama del Área de Sistemas de Minsur S.A.

Fuente: Minsur S.A.

2. ALCANCE DE LA EVALUACION La evaluación a la organización Minsur S.A., en cuanto a la aplicación de las buenas prácticas

indicadas por el modelo CMMi, estará ubicada en el proceso de atención de requerimientos de

los usuarios en el sistema ERP de la empresa. Dicho sistema es el “SAP ECC 6.0”, y se cuenta

con los siguientes módulos funcionales:

- Finanzas y Tesorería

- Recursos Humanos

- Logística

- Costos y Presupuestos

- SAP Portal (NetWeaver)

- SAP BPC

- SAP Basis

Los requerimientos son de cambios en la configuración, correcciones, actualización de

información y desarrollos, sobre todo de informes.

3. FACTIBILIDAD DEL CAMBIO.-

3.1. Reseña sobre antecedentes de cambios de procesos: Desde la creación del área de Sistemas se han realizado algunos proyectos que han impactado

sobre la organización y sus procesos, entre los cuales podemos mencionar la implementación

del “Sistema de Gestión de Requerimientos”.

En el pasado se contaba con un servidor AS/400 y algunos aplicativos hechos en FoxPro,

como el de control de la producción y plantas concentradoras. En el sistema AS/400 se

manejaban los sistemas de planillas, logística, inventarios. La contabilidad se llevaba en un

aplicativo llamado Zico; éste fue un sistema que tuvo muchas deficiencias. En el pasado se

contaba con un jefe de sistemas, analistas y programadores, y algunos técnicos de soporte. El

jefe entregaba el requerimiento directamente al analista, éste hacia la especificación técnica del

cambio, y se la entregaba al programador para que lo implemente en el sistema que

correspondía.

No existía área de Testing. No existía gestión de control de cambios.

UPC

Página 10

El documento de cambio o de solicitud de algún requerimiento se realizaba por e-mail o

documentos físicos. El proceso era de interpretación directa del programador, por otro lado no

existían ni designaban analistas funcionales que interactuaran directamente con el

programador. El paso de los cambios de algún componente en cualquier aplicación se

realizaba directamente en producción sin realizar pruebas con el usuario sino, únicamente,

pruebas unitarias. No existían jefes de proyecto y no había un responsable que tuviera el

control de versiones de las aplicaciones. Tampoco se registraba la aceptación del cambio por

parte del cliente.

En el pasado no se manejaban los proyectos como tales. A partir del año 2004, el área de

Sistemas comenzó a manejar los requerimientos grandes como proyectos, los cuales incluían,

adicionalmente a los cronogramas y manejo de recursos, elaboración de actas de reuniones,

actividades de seguimiento, replanificación de actividades, etc.

Debido a todos estos antecedentes es que se decidió implementar un sistema de registro de

requerimientos a través de una aplicación desarrollado en Lotus Notes. La implementación del

proyecto demoró 7 meses. Como toda organización un grupo de personas se mantuvieron

resistentes al cambio, donde la principal crítica era que el registro de sus requerimientos en el

sistema les demandaba más tiempo en sus labores.

Antes de la implementación de este sistema, los requerimientos se solicitaban de manera

manual, brindando escuetamente el detalle del requerimiento. Este proceso era engorroso,

desordenado y no permitía monitorear la trazabilidad del requerimiento.

Como en todo cambio importante, de un proceso, un porcentaje de trabajadores no reacciona

favorablemente a los cambios, esto debido a que un cambio de sistema implica cambios en los

procedimientos que no siempre son aceptados desde el inicio.

Con respecto a la documentación, antes no existía, o era casi nula. Hoy se documenta

parcialmente, y se generan:

- Cronogramas de actividades

- Diseños técnicos (pero no en todas las ocasiones)

En la actualidad solamente se está archivando los documentos asociados a proyectos, mas no

a atención a los requerimientos. Desde el año 2010 se cuenta con un File Server donde cada

proyecto tiene su repositorio, con permisos para modificar la documentación. Actualmente, no

se está aprovechando esta información. Otra deficiencia es que no se documentan las pruebas

unitarias ni funcionales.

UPC

Página 11

Hoy los procedimientos están documentados en gran medida, pero no están completos. Falta

definir plantillas, estándares, etc.

Adicionalmente, siempre ha existido la limitante de los recursos en el área. La Alta Dirección

nunca dio pase para contar con un número adecuado de personas, evitando la sobrecarga y

saturación en el personal de IT.

3.2. Probables focos de resistencia:

Los cambios implementados en los últimos años en el área de Sistemas de Minsur, han tenido

resistencia proveniente de las siguientes fuentes:

Muchas veces la atención del requerimiento se extiende en el tiempo porque el

usuario no realiza las pruebas de usuario en el periodo programado. Esto ocurre

muchas veces porque el usuario aduce mucha carga de trabajo, temor al cambio,

por viaje o por vacaciones.

Los usuarios se mantenían reacios a realizar sus solicitudes a través de la

aplicación “Sistema de Gestión de Requerimientos”. En algunos casos el consultor

del área de Sistemas lo tenía que realizar. El motivo de esta resistencia se ha

determinado que los usuarios no tienen buena predisposición a los cambios

tecnológicos que ofrece el Área de Sistemas.

Se ha determinado que ante implantaciones de soluciones tecnológicas, algunos

usuarios ponen trabas pues sienten temor en perder sus puestos de trabajo.

Algunos analistas funcionales no utilizaban el formulario del Sistema de Gestión de

Requerimientos, sino que lo hacían en una plantilla antigua que, por procedimiento,

ya ha había sido dada de baja.

Desde hace un tiempo atrás el Área de Sistemas se ha empoderado, por encargo

de la Gerencia General, de todos los aplicativos de la empresa. Pero en la

actualidad existen inconvenientes técnicos y de personas para tener todos los

elementos necesarios para dar el soporte a dichos aplicativos, como por ejemplo:

manuales, know-how para solución de problemas, CDs de los programas

instaladores, etc. Algunos usuarios con conocimientos de aplicativos software muy

específicos, ponen trabas para dar a conocer al Área de Sistemas las actividades

que realizaban cuando se presentaba incidentes con dichos aplicativos.

UPC

Página 12

4. EVALUACIÓN DE LA SITUACIÓN ACTUAL

4.1. Procesos, mecanismos, métodos, prácticas, etc., que actualmente funcionan bien, y que se deben mantener:

1) Requerimientos en los aplicativos

- Se cuenta con un módulo de ingreso de los requerimientos. Los usuarios

colocan directamente sus requerimientos, pero, pasan por una aprobación

de la jefatura del área.

- Cada analista funcional es responsable de los requerimientos asignados

por el Gerente de Sistemas. Cada uno de ellos maneja su propia cola de

trabajos, y lideran las tareas de Testing de su solución coordinando las

pruebas y documentación respectiva.

- El analista funcional es responsable del paquete de cambios de la solución

que atiende, inclusive si ha sido realizado por otro analista-programador, y

se hace responsable de su implementación, pruebas y puesta en

producción. La puesta en producción la realiza el administrador del sistema

(llamado técnico “SAP Basis”). El analista hace el seguimiento de todas las

etapas de la atención del requerimiento dentro de IT.

- Cada requerimiento atendido tiene que pasar necesariamente por la

revisión del área de Testing. El operador no procesará un pase a

producción si no tiene el visto bueno del área de Testing,

- La persona de Testing también prueba los entregables en base a una cola

de trabajos, supervisados por el Gerente de Sistemas.

- Después que se instala el cambio en producción, el analista responsable

constata el funcionamiento correcto con el usuario solicitante.

- Se está logrando alcanzar trazabilidad en la atención de los

requerimientos, colocando los identificadores necesarios en los diferentes

documentos y fuentes generados o modificados.

2) Soporte funcional a usuarios

- En la mayor parte de casos, cuando un analista funcional atiende un

requerimiento puntual de un usuario (previamente aprobado por el responsable

del área usuaria), le indica a éste que el requerimiento pasa a su cola de

trabajos pendientes.

- La mayor parte de los consultores del ERP tienen algunos años de experiencia

dentro de la organización, lo cual es positivo en términos de entendimiento de

UPC

Página 13

los procesos de negocio y comprensión rápida e interpretación de las

necesidades de los usuarios.

3) Desarrollo y mantenimiento de aplicaciones

- Existen ambientes de los sistemas tanto para producción, desarrollo y pruebas

funcionales.

4) Sobre los proyectos

- Se están manejando como tales desde hace dos años, aproximadamente. La

política es tomar los requerimientos grandes como proyectos. Esto lo decide

directamente el Gerente de Sistemas. Se establecen calendarios y

presupuestos, y se convoca a los participantes.

- Se está obteniendo compromisos de los integrantes para cumplir el plan en

fechas y entregables de calidad.

5) Generales del Área de Sistemas

- Se establece y se cumple el plan anual de capacitación en un 95 % de los

cursos ofrecidos.

4.2. Problemas u oportunidades de mejora conocidos:

Problemas:

El número de personas del área de Sistemas es reducido para la cantidad de

requerimientos de usuario que llegan casi a diario. Aquí debe considerarse que

hay trabajo acumulado del pasado (requerimientos inconclusos, no aprobados,

rechazados por pruebas, etc.). Sobre todo es necesario dar mayor fuerza al

área de Testing contratando, por lo menos, dos personas más. Recién el año

2011 se contrató la primera persona designada oficialmente para ese cargo.

Cada consultor del ERP atiende exclusivamente un módulo. Cuando se retira

de vacaciones o de viaje se crea un vacío que no es suplido por ningún otro

recurso para atender requerimientos o incidentes en ese modulo.

UPC

Página 14

Oportunidades:

El pool de consultores del ERP tiene una buena experiencia con dicho

aplicativo, y están en capacidad de realizar implementaciones tales como

absorción de nuevas unidades de negocio o cambios por un nuevo plan de

cuentas, o nueva tabla de centro de costos, etc.

La empresa financieramente se encuentra bien, pero lamentablemente, la Alta

Dirección no ha brindado la suficiente importancia al área de Tecnologías de la

Información, con lo cual se ha visto relegado muchos proyectos importantes en

el pasado. En los últimos años recién se está brindando un apoyo financiero al

área, tal como contratación de más integrantes, mejorando la infraestructura de

comunicaciones con las unidades mineras, adquiriendo software

complementario, realizando compras con leasing de nuevas estaciones de

trabajo, etc. Aquí hay una excelente oportunidad para satisfacer necesidades

La dirección de Sistemas, tiene una gran oportunidad de presentar un Plan

Estratégico de Sistemas completo a la Gerencia General, mostrando las

ventajas competitivas que podría lograr Minsur, construyendo una plataforma

tecnológica integral que brinde el mejor soporte operacional y de toma de

decisiones para la organización, a la vez que podría reducir costos mejorando

procesos y optimizando tareas.

Lamentablemente, la organización no cuenta con métricas o estadísticas que documenten

estas aseveraciones.

4.3. Factores clave de éxito actuales:

El Gerente de Sistemas ha creado y establecido un plan de capacitación anual para

todo el personal del área, realiza el control y seguimiento del mismo logrando que se

cumpla al 100%, lo cual permite que el personal tenga los conocimientos del negocio y

de los sistemas que se administra.

Los analistas funcionales y técnicos que se dedican a la atención del ERP han

adquirido conocimiento avanzado para la configuración, mantenimiento y tareas

adicionales del mismo. Como muestra de ello, se tiene un máximo de 4% de errores en

el tema de migraciones, originadas por instalación de nuevas versiones del software,

aplicación de paquetes de correctivos (“patchs”), etc.

Existe buena predisposición del personal de sistemas para aceptar los cambios que

imparte la Gerencia de Sistemas.

UPC

Página 15

La empresa está en constante actualización tecnológica, para ello, ha realizado un

contrato de leasing con el proveedor de equipos de computación “Lenovo”, empresa

que efectúa la renovación de los equipos de hardware con la siguiente periodicidad:

Para las laptops la renovación es cada 2 años.

Para los equipos desktop la renovación es cada 3 años.

4.4. Descripción de las fuentes de información utilizadas Reuniones y entrevistas

Se coordinó reuniones con algunos miembros de los equipos de TI de la empresa,

el contacto fue a través de la gestión del miembro de nuestro grupo que labora en

la empresa Minsur. En dichas reuniones se realizó las preguntas del cuestionario

indicado en clases para cada una de las áreas de proceso en estudio.

Se ha solicitado algunos formatos con los cuales trabajan, tanto a analistas y

usuarios finales.

Se ha encuestado a los analistas sobre algunas tareas específicas.

Se ha tomado encuesta al Gerente de Sistemas sobre algunas tareas de gestión

de seguimientos al proyecto.

Documentos

Para validar la información brindada se ha solicitado nos muestren la documentación

correspondiente que administran.

En Minsur la documentación es administrada en los repositorios de los servidores

archivos, y están clasificados en 5 grandes tipos. A continuación se indica dicha

clasificación:

1. Políticas y procedimientos de TI

Están las políticas de la organización y las normativas y/o comunicados que se han

realizado hasta la fecha.

2. Documentos de Capacitación

UPC

Página 16

Se tiene la documentación a utilizar para las capacitaciones para SAP, también el

uso de Lotus Notes para el manejo de cómo realizar las gestiones de

requerimientos y las gestiones de reuniones.

3. Información General

Documento de interés a todo el personal de TI.

Documentos referentes al Symposium Gartner 2009.

4. Documentación TI

Información referente a los recursos de TI, tales como:

- Aplicaciones

- Infraestructura

- Recursos Humanos

Información de Servicios que brinda TI, tales como:

- Administración de la configuración.

- Contratos

- Controles TI

- Gestión de proyectos

- Gestión de servicios TI

- Mejora continua

- Servicios de terceros

5. Información General TI

Copia de encuestas que se realizan semestralmente,

Documentación de pruebas realizadas.

Instaladores y componentes SAP

UPC

Página 17

4.5. Evaluación de cumplimiento de las prácticas específicas

4.5.1. Evaluación de cumplimiento de las prácticas específicas en PP

[SG1] Establecer estimaciones

[SP 1.1] Estimar el alcance del proyecto

¿Está descrito en algún lugar cuál es el alcance del proyecto, al menos en alto nivel? Si, se registra un WBS donde se puede observar el esfuerzo que va a tomar el desarrollo del proyecto.

[SP 1.2] Establecer las estimaciones de los atributos del producto de trabajo y las tareas

¿Se calcula el tamaño de los productos? ¿Se asignan niveles de complejidad a los elementos que se desarrollarán? ¿Se puede conocer cuál fue el tamaño de los proyectos anteriores? Si, en el Diagrama de Gantt se describen la duración de las tareas en base a una estimación. Si, existen niveles de complejidad, indicados en el cronograma de actividades. Cuando las actividades son complejas se solicita apoyo de terceros. Si, se puede conocer el tamaño de los proyectos anteriores, porque, cada vez que se realiza un proyecto se crea un directorio en un servidor asignado donde se guardan los documentos creados en el proyecto.

[SP 1.3] Definir el Ciclo de Vida del Proyecto

¿Existe alguna definición que señale cuáles son los ciclos de vida posibles? ¿Esta definición es conocida, y se utiliza para planificar el proyecto? No, solo existe el WBS. No, porque no existe.

[SP 1.4] Determinar las estimaciones de esfuerzo y coste

¿Se calcula el estimado utilizando algún procedimiento (además del juicio de experto)? ¿Se toma en cuenta la información histórica? ¿Se conoce bajo qué supuestos se estimó?

Si, Se aplica la técnica de estimación definida en SP 1.2 También, se tomo en cuenta información generada en proyectos previos. No siempre se conoce bajo que supuestos se estimo. A veces, el gerente de sistemas es el que define la estimación del esfuerzo de acuerdo al presupuesto asignado.

[SG2] Desarrollar un plan de proyecto

[SP 2.1] Establecer el presupuesto y el calendario

¿Se tiene el presupuesto del proyecto? ¿Se preparó en base al estimado, incluyendo otros costos no asociados al esfuerzo (alquiler de equipos, licencias, etc.)? Si, el presupuesto es asignado de acuerdo a la estimación registrada en WBS y se adicionan los costos relacionados a su elaboración.

UPC

Página 18

¿Se tiene un cronograma elaborado en base al esfuerzo? ¿Contiene todas las actividades del proyecto? ¿Se conocen los hitos, dependencias, y los recursos asignados? Si, la elaboración del WBS se usa MS Project en donde se controla los recursos por fases y se registran los hitos necesarios.

[SP 2.2] Identificar los riesgos del proyecto

¿Se identifican y analizan los riesgos? ¿Se encuentran documentados en algún lugar? No, los riesgos solo algunas veces son identificados. No, a la fecha no existe un registro de riesgos ocurridos en los proyectos.

[SP 2.3] Planificar la gestión de los datos

¿Existe un plan de datos del proyecto? ¿Se sabe qué información se debe recolectar y cuál generar? ¿Se establecen los niveles de acceso? ¿Se tienen niveles de control de cambio (ej. Versionamiento) para los entregables que lo requieran? Si, por cada proyecto que se realice los documentos relacionados se guardan centralizados en un repositorio de un servidor asignado. Si los niveles de acceso están definidos. Solo pueden accesar al repositorio de documentos solo las personas relacionadas al proyecto. No se maneja control de versión en los entregables.

[SP 2.4] Planificar los recursos del proyecto

¿Se determinan los recursos humanos, equipamiento, etc., necesarios del proyecto? ¿Dónde se documenta? No, se determina todo lo que se necesita, existe el WBS donde se detallan los recursos pero no se registra o documenta las necesidades adicionales necesarias para el proyecto. .

[SP 2.5] Planificar el conocimiento y habilidades necesarios

¿Se identifican las necesidades de capacitación de los recursos humanos del proyecto? ¿Cómo? ¿En dónde se planifican las acciones de capacitación necesarias? No siempre se identifican las necesidades de capacitación de los recursos humanos del proyecto, y cuando se hace muchas veces no es suficiente porque no se cuenta con la experiencia necesaria.

[SP 2.6] Planificar el involucramiento de las partes interesadas

¿Se identifican los stakeholders relevantes de todas las fases del proyecto? ¿Cómo se sabe cuáles son? ¿Dónde se registra el resultado de la planificación? Si, los stakeholders son registrados también en el WBS por cada fase.

[SP 2.7] Establecer el Plan del Proyecto

¿Se tiene un plan documentado? No, pero sí se centraliza toda la documentación relacionada a un proyecto.

UPC

Página 19

[SG3] Obtener el compromiso con el plan

[SP 3.1] Revisar los planes que afectan el proyecto

¿Se identifican otros planes de los que depende el proyecto? ¿Dónde se documentan para su posterior seguimiento? No se documentan aunque si se identifican.

[SP 3.2] Reconciliar los niveles de trabajo y de recursos

¿Se reconcilia el plan de proyecto con los recursos realmente asignados? ¿Qué sucede si no se cuenta con los recursos estimados? ¿El plan se modifica para acomodarse a la disponibilidad de los recursos? Si se reconcilia el plan de proyecto con los recursos realmente asignados. Cuando no se cuenta con los recursos asignados, algunas veces el proyecto ha sido ampliado en tiempo y cuando no se puede se ha contratado servicio de terceros. El plan es modificado de acuerdo a la disponibilidad de los recursos actualizando el cronograma.

[SP 3.3] Obtener el compromiso con el plan

¿Se obtiene el compromiso de los miembros del proyecto, con el plan? ¿Cómo? Si, a través de reuniones semanales en donde cada responsable debe informar su avance.

4.5.2. Aplicación de Metas Genéricas en Planeamiento de Proyecto

[GG1] Lograr las metas específicas

[GP 1.1] Realizar las prácticas específicas

Cumplir las SPs del área de proceso.

[GG2] Institucionalizar un proceso gestionado

[GP 2.1] Establecer el presupuesto y el calendario

¿Existe una política que indique cómo se debe realizar la planificación del proyecto? No,, la empresa no dispone procedimientos establecidos para la planificación

¿Las personas que realizan la planificación conocen esta política? ¿La utilizan? La planificación la realizan generalmente basándose en criterios profesionales.

UPC

Página 20

[GP 2.2] Planificar el proceso

Las actividades que se realizan durante el plan, ¿se encuentran planificadas? Si, están descritas en el WBS.

[GP 2.3] Proporcionar recursos

¿Se asignan recursos para la planificación? (plantillas, software, etc.) Si, el Project Charter, WBS, y plantillas utilizadas en otros proyectos

[GP 2.4] Asignar responsabilidad

¿Está establecido qué roles están involucrados en el planeamiento del proyecto, y está documentado quiénes desempeñan estos roles? Si, se establece los roles de las personas que están involucradas en el proyecto, pero no existen documentados en donde se indique que debe realizar cada rol.

[GP 2.5] 2.5 Formar (entrenar) al personal

¿Los roles involucrados en el proceso de planeamiento, han recibido entrenamiento en el proceso establecido? Si, en reuniones se establece la función de cada participante antes de iniciar la ejecución del proceso.

[GP 2.6] Controlar entregables (“gestionar configuraciones” en la v.1.2)

¿Se utilizan mecanismos de control (versionado, control de cambios, etc.), a los entregables producidos durante el planeamiento? No, Se maneja de forma manual.

[GP 2.7] Identificar e involucrar a las partes interesadas y relevantes.

¿Se conoce a quienes se debe involucrar en el planeamiento del proyecto? Sí, de acuerdo al tipo de proyecto se logran identificar a las personas involucradas en el planeamiento del proyecto, pero no se documenta.

[GP 2.8] Monitorizar y controlar el proceso.

¿Se utilizan indicadores para controlar el proceso de planeamiento? No se utilizan.

[GP 2.9] Evaluar objetivamente la adherencia

¿Se revisa la adherencia de las actividades de planificación ejecutadas versus el proceso establecido en la política? No, el cumplimiento de las actividades de planificación es evaluado por las personas involucradas en la planificación del proyecto en reuniones semanales.

[SP 2.10] Revisar el estado con el nivel directivo

¿Se entera la Gerencia del progreso y resultados de la planificación de los proyectos? Mediante reuniones planificadas.

UPC

Página 21

4.5.3. Evaluación de cumplimiento de las prácticas específicas en PMC

[SG1] Monitorizar el proyecto frente al plan

[SP 1.1] Monitorizar los parámetros de planificación del proyecto

¿Se hace seguimiento al avance del cronograma, considerando avance esperado vs real? Si, se va adicionando el porcentaje de avance por cada actividad en el WBS.

¿Se hace seguimiento al costo y esfuerzo del proyecto, considerando los valores esperados vs reales? No, solo se hace al seguimiento del tiempo esperado.

¿Cuando existen desviaciones se toman decisiones? Solo se hace tratamiento a las desviaciones de tiempo. Se modifica el cronograma y se vuelve a programar

¿Se documenta el resultado del seguimiento? Solo a tiempo actualizando el cronograma.

[SP 1.2] Monitorizar los compromisos

¿Se hace seguimiento a los compromisos del proyecto? (considerar aquellos internos y externos) No, solo algunos compromisos pero no a todos.

[SP 1.3] Monitorizar los riesgos del proyecto

¿Se realiza seguimiento a los riesgos identificados? Si, se realiza seguimiento a los riesgos identificados y se monitorean en las reuniones semanales. ¿Se deja evidencia del seguimiento, acciones realizadas y estado de los riesgos en el tiempo? No, se deja evidencia del seguimiento, ni de las acciones realizadas.

[SP 1.4] Monitorizar la gestión de datos

¿Se verifica que se estén produciendo los entregables acordados? ¿Se se verifica que los entregables de entrada están siendo recibidos? Si, Mediante reuniones programadas, en las cuales se verifica que las actividades se cumplan en los plazos establecidos.

¿Se verifica el cumplimiento de las reglas de resguardo (niveles de acceso, backup)? Si, existe un procedimiento para que se realice una copia de resguardo periódicamente, realizado por el equipo de soporte técnico.

UPC

Página 22

¿Se toma acción cuando no se cumple lo establecido? Si, el caso será reportado a la Gerencia por el Jefe de Sistemas y se trata de solucionar el inconveniente lo más pronto posible.

[SP 1.5] Monitorizar la involucración de las partes interesadas

¿Se hace seguimiento a la participación de los stakeholders identificados? Si, en el cronograma están incluidas las actividades de los stakeholders y cuando se analiza el avance se realiza de todas las actividades del WBS.

[SP 1.6] Llevar a cabo revisiones de progreso

¿Se realizan revisiones de progreso del proyecto periódicamente? ¿El equipo de proyecto conoce el estado del proyecto? Si, semanalmente. De cada reunión se genera un acta que incluye a los participantes y acuerdos y es enviado a todos los involucrados vía email.

[SP 1.7] Llevar a cabo revisiones de hitos

¿Se tienen reuniones formales con el cliente y otros stakeholders relevantes para revisar el estado del proyecto en hitos predeterminados? Si, existen reuniones con los clientes y stakeholders al momento de finalizar cada hito del proyecto.

¿Se documenta el resultado? Si, en un acta de reunión se establecen la conformidad o inconformidad de los entregables, pero no se guarda en el repositorio como documentación del proyecto.

[SG2] Gestionar las acciones correctivas hasta su cierre

[SP 2.1] Analizar problemas

¿Se registran los problemas del proyecto? No, se identifican pero se registran los problemas del proyecto.

¿Se registran las acciones correctivas, indicando responsables, fechas, etc.?

No, se registran las acciones correctivas.

[SP 2.2] Llevar a cabo las acciones correctivas

¿Se hace seguimiento a las acciones correctivas establecidas? ¿Se conoce cuáles son? No se registran las acciones correctivas. Solo son conocidas por las personas involucradas.

[SP 2.3] Gestionar las acciones correctivas

¿El jefe de proyecto se asegura que las acciones correctivas se lleven a cabo? ¿Se actualiza el estado de las acciones correctivas y problemas? El jefe del proyecto si da seguimiento para que las acciones correctivas se lleven a cabo, pero no se lleva registro de estas acciones.

UPC

Página 23

¿Se puede conocer cuál es la lista de problemas pendientes de solucionar del proyecto? No se registra.

4.5.4. Aplicación de Metas Genéricas en PMC





[GP 2.1] Establecer una política de la organización

¿Existe una política que indique cómo se debe realizar el control del proyecto? No existe, actualmente se encuentra en proceso de estandarización

¿Las personas que realizan el control conocen esta política y la utilizan? No, por lo que no existe.


Las actividades que forman parte del control, ¿se encuentran planificadas?

Si, en el cronograma de actividades - WBS.


¿Se asignan recursos adecuados para realizar las actividades de control del proyecto? (plantillas, software, etc.) No, existen todos los recursos para documentar el control del proyecto.


¿Está establecido qué roles están involucrados en el control del proyecto? ¿Está documentado quiénes desempeñan estos roles? Si, se establece que rol va a tener cada una de las personas involucradas, pero no se documenta quienes desempeñarán cada uno.


¿Los roles involucrados en el proceso de control de proyecto han recibido entrenamiento en el proceso establecido? Si, en las reuniones se establece que función va a tener cada rol en los procesos establecidos.

UPC

Página 24


¿Se utilizan mecanismos de control (versionado, control de cambios, etc.), en los entregables producidos o utilizados durante el control del proyecto? No, el procedimiento es manual


¿Se conoce a quienes se debe involucrar en el control del proyecto? Si se encuentran registrados en el WBS.


¿Se utilizan indicadores para el control del progreso del proyecto? No, solo se usa el WBS.


¿Se revisa la adherencia de las actividades de control de proyecto ejecutadas versus el proceso establecido en la política? No


¿Se entera la Gerencia del progreso y resultados del proyecto? A través de las reuniones programadas.

4.5.5. Evaluación de cumplimiento de las prácticas específicas en REQM

[SG1] Gestionar los requerimientos

[SP 1.1] Obtener una comprensión de los requerimientos

¿Existen criterios para aceptar requerimientos? (ejemplo de criterios: plantilla para recibirlos, fuentes autorizadas de requerimientos, términos a evitar, etc.) Si existe un sistema llamado “Sistema de Gestión de Requerimientos donde se registran todos los datos relacionados.

¿Se revisan y aprueban los requerimientos? Sí, todos los requerimientos son aprobados por los jefes de áreas y luego recibidos y analizados en el funcional correspondiente.

¿Se mantiene una lista con los requerimientos autorizados? Si, en el sistema “Gestión de requerimientos” desarrollado en Lotus Notes.

[SP 1.2] Obtener el compromiso sobre los requerimientos

¿Existe algún mecanismo que permita obtener el compromiso de los desarrolladores y testers con los requerimientos? Si, mediante reuniones.

¿Este mecanismo se ejecuta en la práctica? Si, por cada reunión se registra un acta que incluye a los participantes y acuerdos establecidos. (en Lotus Notes).

UPC

Página 25

[SP 1.3] Gestionar los cambios de los requerimientos

¿Se registran los cambios a la lista acordada de requerimientos? Si, se registran el detalle de los cambios en el sistema “Gestión de Requerimientos”.

¿Se evalúa el impacto? ¿Por todos los posibles afectados? (desarrolladores, analistas, testers) Si, en reuniones

¿Se registra el impacto? Si, en el sistema de “Gestión de Requerimientos”.

¿Se hace seguimiento a la aplicación del cambio? (¿Se conoce la lista de cambios pendientes de implementar? Si, los requerimientos tienen un atributo de estado.

[SP 1.4] Mantener la trazabilidad bidireccional de los requerimientos

¿Se puede relacionar los requerimientos cono los planes, especificaciones funcionales, casos de prueba y cambios al código fuente? Si, existe la especificación funcional, la documentación del desarrollo, las observaciones del tester, las observaciones de las pruebas realizadas por el usuario. Todo esto se encuentra en el sistema de “Gestión de Requerimiento”.

[SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos

¿Se tienen actividades que permitan asegurar que los cambios aceptados están siendo considerados en el plan? Se actualiza el cronograma

4.5.6. Aplicación de Metas Genéricas en REQM





[GP 2.1] Establecer una política de la organización

¿Existe una política que indique cómo se debe realizar la gestión de los requerimientos? Si, la empresa cuenta con un documento de procedimiento

¿Las personas que realizan la gestión de requerimientos conocen esta política y la cumplen? Si, la cumplen parcialmente.


Las actividades de gestión de requerimientos, ¿se encuentran planificadas? Si, en el cronograma

UPC

Página 26


¿Cuáles son los recursos que se utilizan para la gestión de requerimientos? ¿Son adecuados y suficientes? ¿Los utilizan? Manual de procedimiento, plantillas. Sin embargo, no lo utilizan en tu totalidad debido a que son considerados inadecuados por algunos analistas funcionales.


¿Está establecido qué roles están involucrados en la gestión de requerimientos? ¿Está documentado quiénes desempeñan estos roles? Si, si está establecido.


¿Está establecido qué roles están involucrados en la gestión de requerimientos? ¿Está documentado quiénes desempeñan estos roles? Si, si se recibe capacitación, pero no está documentado.


¿Se utilizan mecanismos de control (versionado, control de cambios, etc.), a los entregables producidos durante la gestión de requerimientos? No, no existen documentos ni otro medio donde se guarden las versiones.


¿Se conoce a quienes se debe involucrar en las actividades de gestión de requerimientos? Si, si se conocen.


¿Se utilizan indicadores para controlar la gestión de los requerimientos? No, no existen indicadores por proceso.


¿Se revisa la adherencia de las actividades de gestión de requerimientos ejecutadas versus el proceso establecido en la política? Si, se muestra en el WBS.


¿Se entera la Gerencia del progreso y resultados de las actividades de la gestión de requerimientos? Mediante reuniones programadas.

UPC

Página 27

4.6. Presentación de resultados

4.6.1. Por cada área de proceso, % de prácticas cumplidas y no cumplidas

Cumple No cumple

numero porcentaje numero porcentaje

Project Planning 17 68% 8 32% Project Monitoring and Control

13 62% 8 38%

Requirements Management

13 81% 3 19%

El cuadro indica el porcentaje de cumplimiento, y si no se cumple, se especifica

porcentaje en la forma como lo trabajan.

Project Planning ¿Se Cumple? % de complimiento/No

Cumplimiento

SG 1 Establecer estimaciones

SP 1.1 SI 100%

SP 1.2 SI 100%

SP 1.3 SI 100%

SP 1.4 SI 100%

SG 2 Desarrollar un plan de proyecto

SP 2.1 SI 100%

SP 2.2 NO 0%

SP 2.3 SI 100%

SP 2.4 NO 0%

UPC

Página 28

SP 2.5 NO 0%

SP 2.6 SI 100%

SP 2.7 NO 0%

SG 3 Obtener compromiso con el plan

SP 3.1 NO 0%

SP 3.2 SI 100%

SP 3.3 SI 100%

GG 1 Lograr las metas específicas

GP 1.1 SI 100%

GG 2 Institucionalizar un proceso gestionado

GP 2.1 SI 100%

GP 2.2 SI 100%

GP 2.3 SI 100%

GP 2.4 SI 100%

GP 2.5 SI 100%

GP 2.6 NO 0%

GP 2.7 SI 100%

GP 2.8 NO 0%

GP 2.9 NO 0%

GP 2.10 SI 100%

Project Monitoring and Control ¿Se cumple? % de complimiento/No

Cumplimiento

SG 1 Monitorizar el proyecto frente al plan

SP 1.1 SI 100%

SP 1.2 NO 0%

SP 1.3 SI 100%

SP 1.4 SI 100%

SP 1.5 SI 100%

SP 1.6 SI 100%

SP 1.7 SI 100%

SG 2 Gestionar las acciones correctivas hasta su cierre

SP 2.1 NO 0%

SP 2.2 NO 0%

SP 2.3 SI 100%


GP 1.1 SI 100%


GP 2.1 NO 0%

GP 2.2 SI 100%

GP 2.3 NO 0%

GP 2.4 SI 100%

GP 2.5 SI 100%

GP 2.6 NO 0%

GP 2.7 SI 100%

GP 2.8 NO 0%

GP 2.9 NO 0%

GP 2.10 SI 100%

Requirements Management ¿Se Cumple? % de complimiento/No

Cumplimiento

UPC

Página 29

SG 1 Gestionar los requerimientos

SP 1.1 SI 100%

SP 1.2 SI 100%

SP 1.3 SI 100%

SP 1.4 SI 100%

SP 1.5 SI 100%


GP 1.1 SI 100%


GP 2.1 SI 100%

GP 2.2 SI 100%

GP 2.3 NO 0%

GP 2.4 SI 100%

GP 2.5 SI 100%

GP 2.6 NO 0%

GP 2.7 SI 100%

GP 2.8 NO 0%

GP 2.9 SI 100%

GP 2.10 SI 100%

4.6.2. % total de prácticas cumplidas y no cumplidas El número total de prácticas cumplidas son 43 y las no cumplidas son 19

UPC

Página 30

5. Procesos para la organización en estudio

5.1. Nuevo proceso establecido para la organización

5.1.1. Nombre del proceso El nuevo proceso definido para mejorar el desempeño de la organización de TI en Minsur S.A.

se llama “Gestión de Calidad de Software de Minsur”. Su orientación indica que el Área de

Sistemas producirá entregables de software con un mínimo o cero numero de defectos por

requerimiento atendido.

5.1.2. Implementación A rasgos generales, se define que Minsur deberá implementar un Departamento de Testing,

conformado por al menos 4 personas: una responsable del área, y tres personas que serán los

analistas de Testing.

5.1.3. Propósito del proceso El propósito del nuevo proceso “Gestión de Calidad de Software de Minsur” es reducir al 5%

el número de errores que se presenten en las atenciones ya instaladas en los ambientes de

producción de los diferentes requerimientos de correcciones, cambios o desarrollos que

atienda el Área de Sistemas.

5.1.4. Roles Los diferentes miembros del equipo atención de requerimientos, incluyendo las áreas de

Desarrollo y Testing, trabajarán desempeñando alguno de estos roles:

- Gestor de Desarrollo y Testing

- Responsable de Testing

- Analistas de Testing

- Desarrollador

- Usuario

- Soporte Funcional

UPC

Página 31

5.1.5. Alcance del proceso El proceso debe ser ejecutado para todos los requerimientos de solicitud de software.

El procesi inicio: el proceso se inicia cuando el Gestor de Desarrollo y Testing adiciona un

registro más en la Hoja de Atención de Testing que indica que un nuevo requerimiento se está

planificando que ingresará a ser trabajado en el departamento de Testing en el futuro cercano.

Final: el proceso finaliza cuando el Responsable de Testing habilita el estado de “Cerrado” en

el registro de control del requerimiento en la Hoja de Atención de Testing.

5.1.6. Plantillas de documentos a utilizar Las plantillas de los documentos que serán utilizados en el nuevo proceso definido “Gestión de

la Calidad de Software de Minsur” son los siguientes:

a ) Hoja de Control de Requerimientos Aprobados: elaborado y mantenida por el Analista de

Negocio. Es ingreso para el Gestor de Desarrollo y Testing.

b ) Alcance del requerimiento : elaborado por el Analista de Negocio. Es el resultado de lo

indicado directamente por el usuario, pero plasmado en términos de acuerdo entre el área

usuario y el área de Sistema.

c ) Análisis Funcional : elaborado por el Analista Funcional, quien integra el equipo de

desarrollo. Contiene la especificación de los nuevos casos de uso de sistema que han sido

implementados en las fases siguientes de desarrollo.

d ) Análisis Técnico : elaborado por el Desarrollador o por el Analista Técnico. Contiene las

especificaciones detalladas de los cambios o construcciones en el software de la empresa,

atendiendo los casos de uso de sistema y el alcance del requerimiento, para satisfacer los

mismos.

e ) Documento de Pase a Testing / Producción : elaborado por el Desarrollador y contiene los

instructivos para poder implantar el Paquete de Cambios tanto en los ambientes de pruebas

como en el ambiente de producción.

f ) Casos de pruebas de Testing: documento elaborado por el Analista de Testing, plasma los

pasos y resultados de las pruebas realizadas en los diferentes escenarios planteados en el

Análisis Técnico, tiene la finalidad de verificar que los cambios efectivos al software estén

acordes con lo indicado en los diversos documentos de análisis. Asimismo, contiene los

resultados de las pruebas de stress realizadas.

UPC

Página 32

g ) Hoja de Atención de Testing : documento que es actualizado solamente por el Gestor de

Desarrollo y Testing, el Responsable de Testing y los Analistas de Testing. Contiene el listado

de todos los trabajos anteriores, actuales y futuros que han sido, son y serán atendidos por el

equipo de Testing. Así mismo, contiene los checklists de las diferentes fases de atención de los

requerimientos por parte del equipo de Testing.

h) Acta de Conformidad de Requerimiento Atendido en Ambiente de Pruebas: documento

llenado por el Analista de Testing y firmado por el usuario dando su conformidad que el

requerimiento instalado y probado en ambiente simulado está acorde a lo solicitado.

i) Acta de Conformidad de Requerimiento Atendido en Ambiente de Producción: documento

llenado por el Analista de Testing y firmado por el usuario dando su conformidad que el

requerimiento instalado y probado en el ambiente de producción está acorde a lo solicitado.

Estas plantillas se muestran en el acápite “Anexos”.

5.1.7. Descripción del proceso A continuación se presenta la descripción de cada uno de los procedimientos que conforman el

nuevo proceso mencionado:

1. Planificar y registrar nuevo requerimiento para atención de Testing

El Gestor de Desarrollo y Testing realiza todas las actividades necesarias para estimar el

alcance del requerimiento, define el ciclo de vida del proyecto, obtiene y contrasta las

estimaciones de esfuerzo, establece el calendario tentativo de actividades, involucra y

compromete a las partes interesadas, establece el plan de trabajo y qué otros planes pueden

afectar el actual. Asimismo, informa al departamento de Testing los nuevos requerimientos que

deberán ser atendidos en el futuro inmediato. Gestiona los cambios en el desarrollo de los

requerimientos y detecta las inconsistencias de los requerimientos versus el trabajo de de

desarrollo del requerimiento.

2. Estima tiempos, identifica riesgos, según planificación y alcance del requerimiento.

El Responsable de Testing ejecuta todas las actividades que estén relacionadas con las

estimaciones de los atributos del producto de trabajo y las tareas del equipo de Testing e

identifica los riesgos en la atención del requerimiento según la planificación y el alcance dados.

Verifica que estén completos los documentos que deben ingresar al equipo de Testing como

fuente del conocimiento para la atención del requerimiento:

UPC

Página 33

- Alcance del requerimiento

- Análisis Funcional

- Análisis Técnico

- Pase a Testing / Producción

3. Planifica recursos según la disponibilidad y conocimientos de los miembros

El Responsable de Testing atiende todas las tareas relacionadas con la planificación de los

recursos a asignar a la atención del requerimiento, teniendo en cuenta los niveles de

conocimientos y habilidades necesarias en los miembros candidatos teniendo en cuenta la

carga de trabajo y los niveles de conocimiento de los integrantes candidatos a asignar a la

atención del requerimiento.

4. Ejecuta casos de pruebas y actualiza estadísticas de defectos

El Analista de Testing realiza las pruebas efectivas al paquete de cambios entregado por

Desarrollo, realizando una planificación de baterías de pruebas. Previamente se deberá haber

obtenido una comprensión cabal del requerimiento en tratamiento leyendo exhaustivamente la

documentación recibida de las fases anteriores.

5. Corregir defectos y enviar nuevo paquete de cambios.

Si es que el Analista de Testing reporta defectos, el Desarrollador corregirá los mismos y

volverá a actualizar la documentación técnica si fuera el caso, y enviará un nuevo Paquete de

Cambios al Analista de Testing.

6. Ejecución de las pruebas funcionales con el usuario

El Analista de Testing verifica con el usuario que los cambios desarrollados y que están siendo

probados se ajustan a lo solicitado por el mismo, y que está plasmado en los documentos de

alcance del requerimiento.

7. Cerrar actividades de Testing en ambiente de pruebas

El Analista de Testing da por concluidas las pruebas realizadas a la implementación de los

cambios o construcciones elaboradas para atender el requerimiento en curso, registrando dicha

información en la Hoja de Atención de Testing.

8. Firmar el acta de conformidad de los cambios instalados y probados en ambiente de

pruebas

UPC

Página 34

El equipo de Testing asegura, a través de la firma del Acta de Conformidad en Ambiente de

Pruebas, que el usuario he verificado que los desarrollos están correctos y se ajustan a lo

indicado en el alcance.

9. Indicar instalación del paquete de cambios en el ambiente de producción

El Analista de Testing solicita al Soporte Funcional que instale en el ambiente de producción el

paquete de cambios generado por Desarrollo, y que ya ha sido probado y aprobado por

Testing.

10. Ejecutar pruebas funcionales y de integración adicionales

El Soporte Funcional ejecuta las últimas pruebas de funcionales y de integración para detectar

inconsistencias o errores detectados en última instancia, previo a la instalación en el ambiente

de producción. Usualmente aquí se detectan errores o inconsistencias en el documento “Pase

a Testing / Producción”.

11. Instalar paquete de cambios en ambiente de producción

La persona de Soporte Funcional instala el paquete de cambios en el ambiente de producción.

12. Pruebas funcionales en ambiente de producción con el usuario

El Analista de Testing realiza las pruebas funcionales de los cambios o desarrollos instalados

ya en producción, atendiendo el requerimiento en tratamiento.

13. Firmar el acta de conformidad en ambiente de producción

El equipo de Testing asegura, a través de la firma del Acta de Conformidad en Ambiente de

Producción, que el usuario he verificado que los desarrollos están correctos y se ajustan a lo

indicado en el alcance.

14. Enviar solicitud de atención de errores en producción a Soporte Funcional

El Analista de Testing, en caso encontrara errores después de haberse instalado el paquete de

cambios en producción, coloca un Registro de Incidente en producción para dar cuenta al

encargado (Soporte Funcional) la atención de dicho error.

15. Cierra documentación y avisa cerrar el requerimiento

El Analista de Testing cierra la documentación del requerimiento en caso la funcionalidad

solicitada está operando correcta y completamente en el ambiente de producción, después de

UPC

Página 35

haberlo constatado con el usuario. Avisa al Responsable de Testing el cierre de dicho

requerimiento.

16. Cierra la atención del requerimiento

El Responsable de Testing cierra la atención del requerimiento después de haber constatado

que todos los documentos, actas e indicadores del requerimiento hayan sido actualizados.

5.1.8. Flujograma del proceso

UPC

Página 36

FLUJOGRAMA DEL NUEVO PROCESO ORGANIZACIONAL “ GESTION DE CALIDAD DE

SOFTWARE DE MINSUR S.A.”

5.1.9. Matriz de Trazabilidad de Procedimientos versus Prácticas Específicas

Procedimiento PP - Project Planning REQM

1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 3.3 1.1 1.2 1.3 1.4 1.5

1 Planificar y registrar nuevo requerimiento para atención de Testing

X X X X X X X X X X X

2 Estimar tiempos, identifica riesgos, según planificación y alcance del requerimiento

X X

3 Planificar recursos según la disponibilidad y conocimientos de los miembros

X X X

4 Ejecutar casos de pruebas y actualiza estadísticas de defectos X X

5 Corregir defectos y enviar nuevo paquete de cambios X X

6 Ejecución de las pruebas funcionales con el usuario X X X

7 Cerrar actividades de Testing en el ambiente de pruebas X X X

8 Firmar el acta de conformidad de los cambios instalados y probados en ambiente de pruebas

X

9 Indicar instalación del paquete de cambios en el ambiente de producción

X X

10 Ejecutar pruebas funcionales y de integración adicionales X X X

11 Instalar paquete de cambios en ambiente de producción X X

12 Pruebas funcionales en ambiente de producción con el usuario X X

13 Firmar el acta de conformidad en ambiente de producción X X

14 Enviar solicitud de atención de errores en producción a Soporte Funcional

X

15 Cierra documentación y avisa cerrar el requerimiento X

16 Cierra la atención del requerimiento X

5.2. Planificación de Proyectos

5.2.1. Situación problemática El área de Sistemas de TI de Minsur no tiene definido la planificación de Gestión de Calidad de Software, actualmente

este proceso lo realizan aplicando juicio de expertos y de acuerdo a prácticas adquiridas. Los principales

inconvenientes y limitaciones que se presentaron se detallan a continuación.

No tienen definido los roles para la gestión de Calidad

Se duplican esfuerzos

Brechas entre los requerimientos de usuario y lo desarrollado

No se manejan contingencias ante imprevistos y cambios de programación

Pruebas duplicadas con los usuarios

No existe programación para preparar el ambiente de test

Situación Problemática Problema a Resolver

No tienen definido los roles para la gestión de Calidad

1. Los analista no tienen documentado y

desconocen el alcance de su rol

Se duplican esfuerzos

2. Las pruebas unitarias y las pruebas con el usuario

se duplican

Brechas entre los requerimientos de usuario y lo desarrollado

3. No existe un documento que especifique los

requerimientos finales vs el desarrollo en el

software.

No se manejan contingencias ante imprevistos y cambios de programación

4. El cronograma no contempla tiempos de holgura

que permitan replanificar alguna actividad de de

control de calidad.

Pruebas duplicadas con los usuarios

5. Los usuarios se quejan porque prueban funciones

repetidas veces

No existe programación para preparar el ambiente de test

6. Muchas veces el ambiente de testing no se

encuentra preparado y las solicitudes están

pendientes de prueba.

UPC

Página 39

5.2.2. Flujo del proceso

El nuevo proceso definido para mejorar el desempeño de la organización se llama “Gestión de

Calidad de Software de Minsur”. Su orientación indica que el Área de Sistemas producirá

entregables de software con un mínimo o cero numero de defectos por requerimiento atendido. A

continuación la descripción de cada uno de los procedimientos que conforman el proceso

mencionado.

A rasgos generales, se define que Minsur deberá implementar un Departamento de Testing,

conformado por al menos 4 personas: una responsable del área, y tres personas más que serán los

analistas de Testing.

Formatos de los procedimientos:

1) Planificar y registrar nuevo requerimiento para atención de Testing

Propósito Realizar todas las actividades necesarias para estimar el alcance del requerimiento, definir

el ciclo de vida del proyecto, obtener y contrastar las estimaciones de esfuerzo, establecer

el calendario tentativo de actividades, involucra y compromete a las partes interesadas,

establece el plan y que otros planes afectan. Asimismo, informa al departamento de

Testing los nuevos requerimientos que deberán ser atendidos. Gestionar los cambios en el

desarrollo de los requerimientos y detectar las inconsistencias de los requerimientos

versus el trabajo del proyecto.

Roles involucrados Gestor de Desarrollo y Testing

Entregables de Entrada Hoja de control de requerimientos aprobados

Actividades

Descripción de la actividad Herramienta Rol Responsable

Adiciona nuevo registro de requerimiento

que deberá ser atendido por Testing

Hoja de cálculo Gestor de Desarrollo y

Testing

Entregable de salida

Hoja de Atención de Testing

Trazabilidad

Project Planning:

PP [SP 1.1] : Estimar el alcance del proyecto

PP [SP 1.3] : Definir el Ciclo de Vida del Proyecto

PP [SP 1.4] : Determinar las estimaciones de esfuerzo y coste

PP [SP 2.1] : Establecer el presupuesto y el calendario

PP [SP 2.6] : Planificar el involucramiento de las partes interesadas

PP [SP 2.7] : Establecer el Plan del Proyecto

PP [SP 3.1] : Revisar los planes que afectan el proyecto

UPC

Página 40

PP [SP 3.3] : Obtener el compromiso con el plan

RequirementsPlanning:

REQM [SP 1.2] : Obtener el compromiso sobre los requerimientos

REQM [SP 1.3] : Gestionar los cambios de los requerimientos

REQM [SP 1.5] : Identificar las inconsistencias entre el trabajo del proyecto y los

requerimientos

2) Estima tiempos, identifica riesgos, según planificación y alcance del

requerimiento.

Propósito

Ejecutar todas las actividades que estén relacionadas con las estimaciones de los

atributos del producto de trabajo y las tareas, identificación de los riesgos en la atención

del requerimiento por parte de Testing, según la planificación y el alcance.

Roles involucrados

Responsable de Testing

Entregables de Entrada


Actividades


Estimar tiempos, identificar riesgos dentro

del área de Testing, según la

planificación y el alcance del

requerimiento recibido.

Hoja de cálculo Responsable de

Testing

Entregables de Salida


Trazabilidad

Project Planning:

[SP 1.2] Establecer las estimaciones de los atributos del producto de trabajo y las tareas

[SP 2.2] Identificar los riesgos del proyecto

3) Planifica recursos según la disponibilidad y conocimientos de los miembros

Propósito

Atender todas las tareas relacionadas con la planificación de los recursos a asignar a la

atención del requerimiento, teniendo en cuenta los niveles de conocimientos y habilidades

necesarias en los miembros candidatos y reconciliar la carga de trabajo de recursos y los

niveles de trabajo.

UPC

Página 41

Roles involucrados




Actividades


Planifica recursos según la disponibilidad

y conocimientos de los miembros.

Hoja de cálculo Responsable de

Testing



Project de control de requerimientos

Trazabilidad

Project Planning:

[SP 2.4] Planificar los recursos del proyecto

[SP 2.5] Planificar el conocimiento y habilidades necesarios

[SP 3.2] Reconciliar los niveles de trabajo y de recursos

4) Ejecuta casos de pruebas y actualiza estadísticas de defectos

Propósito

Realizar las pruebas respectivas al paquete de cambios entregado por Desarrollo,

realizando una planificación de baterías de pruebas. Previamente se deberá haber

obtenido una comprensión cabal del requerimiento en tratamiento.

Roles involucrados

Analista de Testing



Actividades


Generar ambientes de pruebas No aplica Analista de Testing

Ejecutar los casos de pruebas intensivos No aplica Analista de Testing

Documentar los resultados de los casos

de pruebas realizados

Hoja de cálculo Analista de Testing


Casos de Pruebas de Testing

Estadísticas de defectos de desarrollo

Trazabilidad

UPC

Página 42

Project Planning:




5) Corregir defectos y enviar nuevo paquete de cambios.

Propósito

Obtener un paquete de cambios con los errores reportados por quien corresponda, ya

subsanados.

Roles involucrados

Desarrollador


Casos de pruebas de Testing

Actividades


Analizar el defecto reportado No aplica Desarrollador

Realizar las correcciones o

construcciones efectivas en el software

No aplica Desarrollador

Realizar los casos de pruebas unitarias No aplica Desarrollador

Armar y enviar nuevo paquete de

cambios

No aplica Desarrollador


Paquete de cambios en el software

Trazabilidad




6) Ejecución de las pruebas funcionales con el usuario

Propósito

Verificar con el usuario que los cambios desarrollados y que están siendo probados se

ajustan a lo solicitado por el mismo, y que está plasmado en los documentos de alcance

del requerimiento.

UPC

Página 43

Roles involucrados

Analista de Testing

Usuario



Paquete de Cambios

Actividades


Generar ambientes de pruebas No aplica Analista de Testing

Ejecutar los casos de pruebas No aplica Analista de Testing

Documentar los resultados de los casos

de pruebas realizados




Trazabilidad

Project Planning:





7) Cerrar actividades de Testing en el ambiente de pruebas

Propósito

Dar por concluidas las pruebas realizadas a la implementación de los cambios o

desarrollos implementados para atender el requerimiento en curso, registrando dicha

información en la Hoja de Atención de Testing.

Roles involucrados

Analista de Testing



Actividades


Registrar las actividades de cierre de

testing en el ambiente de pruebas



UPC

Página 44


Trazabilidad





8) Firmar el acta de conformidad de los cambios instalados y probados en

ambiente de pruebas

Propósito

Asegurar, a través de la firma del Acta de Conformidad en Ambiente de Pruebas, que el

usuario ha verificado que los desarrollos están correctos y se ajustan a lo indicado en el

alcance.

Roles involucrados

Usuario

Analista de Testing


Acta de Conformidad en Ambiente de Pruebas (sin firmar)

Actividades


Firmar el acta de conformidad de los

cambios instalados y probados en

ambiente de pruebas

Formato impreso Usuario


Acta de Conformidad en Ambiente de Pruebas (firmada por el usuario)

Trazabilidad



9) Indicar instalación del paquete de cambios en el ambiente de producción

Propósito

Solicitar al Soporte Funcional que instale el paquete de cambios generado por Desarrollo,

y que ya ha sido probado y aprobado por Testing, en el ambiente de producción.

Roles involucrados

Analista de Testing

UPC

Página 45

Soporte Funcional


Casos de pruebas de testing

Acta de Conformidad en Ambiente de Pruebas firmada

Actividades


Solicitar instalación del paquete de

cambios en el ambiente de producción

Correo electrónico Analista de Testing



Trazabilidad




10) Ejecutar pruebas funcionales y de integración adicionales

Propósito

Se ejecutan las últimas pruebas de funcionales y de integración por parte de la persona

con el rol “Soporte Funcional” para detectar inconsistencias o errores, previo a la

instalación en el ambiente de producción.

Roles involucrados

Soporte Funcional


Toda la documentación que está generando el requerimiento

Actividades


Ejecutarlas pruebas funcionales y de

integración adicionales

No aplica Soporte Funcional


Correo electrónico dirigido al Analista de Testing indicando pruebas exitosas

Casos de prueba de Soporte Funcional

Trazabilidad





UPC

Página 46

11) Instalar paquete de cambios en ambiente de producción

Propósito

Se instala el paquete de cambios en el ambiente de producción.

Roles involucrados

Soporte Funcional



Actividades


Instalar paquete de cambios en ambiente

de producción

No aplica Soporte Funcional


Correo electrónico dirigido al Analista de Testing indicando que el paquete de cambios ha

sido instalado en producción.

Trazabilidad


[SP 1.2] Obtener el compromiso sobre los requerimientos


12) Pruebas funcionales en ambiente de producción con el usuario

Propósito

Se realiza las pruebas funcionales de los cambios o desarrollos instalados ya en

producción, atendiendo el requerimiento en tratamiento.

Roles involucrados

Analista de Testing

Usuario


Paquete de cambios instalado en el ambiente de producción


Actividades


Se ejecutan las pruebas funcionales en el

ambiente de producción con el usuario

No aplica Analista de Testing

UPC

Página 47



Trazabilidad




13) Firmar el acta de conformidad en ambiente de producción

Propósito

Asegurar, a través de la firma del Acta de Conformidad en Ambiente de Producción, que el

usuario ha verificado que los desarrollos están correctos y se ajustan a lo indicado en el

alcance.

Roles involucrados

Usuario


Acta de Conformidad en Ambiente de Producción (sin firmar)

Actividades


Firmarel acta de conformidad en

ambiente de producción

No aplica Usuario


Acta de Conformidad en Ambiente de Producción (firmada)

Trazabilidad




14) Enviar solicitud de atención de errores en producción a Soporte Funcional

Propósito

Al haberse encontrado errores después de haber instalado el paquete de cambios en

producción, el Analista de Testing coloca un Registro de Incidente en producción para dar

cuenta al encargado (Soporte Funcional) la atención de dicho error.

Roles involucrados

Analista de Testing


UPC

Página 48



Actividades


Enviar solicitud de atención de errores en

producción a Soporte Funcional



Registro de Incidentes en ambiente de producción

Trazabilidad

Project Planning:

PP [SP 1.4] : Determinar las estimaciones de esfuerzo y coste

15) Cierra documentación y avisa cerrar el requerimiento

Propósito

Si la funcionalidad solicitada con el requerimiento en atención está funcionando correcta y

completamente en el ambiente de producción, entonces el Analista de Testing cierra la

documentación del mismo, y da aviso al Responsable de Testing el cierre del mismo.

Roles involucrados

Analista de Testing




Estadísticas actualizadas de Defectos de Desarrollo

Acta de Conformidad en Ambiente de Pruebas firmada por el usuario

Acta de Conformidad en Ambiente de Producción firmada por el usuario

Actividades


Cierra documentación y avisa cerrar el

requerimiento



Hoja de Atención de Testing con indicadores elaborados

Trazabilidad



UPC

Página 49

16) Cierra la atención del requerimiento

Propósito

Si todos los pasos necesarios para probar e instalar en producción un requerimiento, y

verificando que toda la documentación esté actualizada y cerrada, el Responsable de

Testing cierra el requerimiento actualizando la Hoja de Atención de Testing.

Roles involucrados





Estadísticas actualizadas de Defectos de Desarrollo

Acta de Conformidad en Ambiente de Pruebas firmada por el usuario

Acta de Conformidad en Ambiente de Producción firmada por el usuario

Actividades


Cerrar la atención del requerimiento Hoja de cálculo Responsable de

Testing


Hoja de Atención de Testing con el indicador de “Requerimiento cerrado”

Trazabilidad

RequirementsPlanning: [SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto

y los requerimientos

5.3. Gestión de requerimientos

Gestión de Requerimientos (REQM) permite gestionar los requerimientos de los productos y

componentes de un determinado proyecto e identificar inconsistencias entre esos requerimientos, los

planes y productos del trabajo de un proyecto.

En la gestión de requerimientos, hoy en día muy pocas empresas toman en cuenta el proceso de

testing, cuya intención es evaluar el proceso o componente para verificar si se satisface los requisitos

esperados, o para identificar diferencias entre los resultados esperados y los reales.

5.3.1. Situación problemática

Actualmente, el área de Sistemas de Minsur S.A. se dedica exclusivamente a la atención de

múltiples requerimientos generados por las áreas usuarias, el cual desborda la capacidad de

atención por la falta de personal. Además, la horizontalidad en el proceso de canalización de

UPC

Página 50

requerimientos dificulta el adecuado control de los mismos, así como la deficiente gestión hacia su

atención (Análisis, Diseño, Desarrollo e Implementación). Actualmente, por la falta de personal en el

Área de Sistemas no se realiza el proceso de testing adecuada y completamente.

Situación Problemática Problema a Resolver

Canalización de

requerimientos deficiente

1. Alinear requerimientos a objetivos

2. Falta de Enfoque de requerimientos a optimizar

procesos.

3. La cantidad de requerimientos supera

capacidad operativa.

4. Adicionar nuevas posiciones con nuevos roles

para cubrir las necesidades y realizar un optimo

trabajo en el proceso de testing.

Dificultad para la priorización

de requerimientos

5. Cambios constantes en la priorización de los

requerimientos.

6. Saturación de canales de atención.

7. Incumplimiento de plazos.

8. Deficiente utilización de recursos.

Dificultad en control de

testing

9. Las pruebas realizadas por el responsable de

testing no son realmente suficientes.

Modificando el proceso se llevará un mejor

control en la calidad del desarrollo de los

requerimientos y se reducirá costos.

5.3.2. Flujo de Proceso

En la etapa de testing del área de proceso de Gestión de Requerimientos consideramos los

siguientes procesos:

a. Recepción y asignación de desarrollo de requerimiento.

b. Registro de la solución y validación con el Usuario.

c. Puesta en Producción.

Formatos de los procedimientos:

1. Recepción y asignación de desarrollo de requerimiento.

Propósito

El Responsable de Testing debe coordinar con el Analista de testing la ejecución de

los casos de pruebas y registrar estadísticas de defectos. Esta tarea tiene como

propósito el de realizar la recepción del requerimiento, por parte del Gestor de

Desarrollo y Testing, quien deberá coordinar con el Responsable de Testing para que

UPC

Página 51

asigne fecha de inicio y tiempos de acuerdo a la disponibilidad de recursos y

necesidad del usuario.

Roles involucrados

Gestor de Desarrollo y Testing, Responsable de Testing, Analista de Testing,

Desarrollador.


a. Requerimiento, Alcance y Análisis Funcional.

Criterios de Entrada

- Se encuentra registrado el requerimiento, el alcance del requerimiento y el

análisis funcional.


a. Hoja de atención de testing

b. Hoja de control de requerimientos aprobados

c. Project de control de proyectos actualizado

d. Casos de pruebas de testing

e. Estadísticas de pruebas de desarrollo.

Criterios de Salida

- Finaliza cuando se ha terminado validado el requerimiento con el usuario.

Actividades

Descripción de Actividad Herramienta / Plantilla Rol

Responsable

- Gestor de desarrollo y testing

solicita al responsable de testing

que identifica tiempos y recursos

para la atención del requerimiento.

- El responsable de testing planifica

recursos de acuerdo a

disponibilidad de recursos.

- El analista de testing realiza las

pruebas después de haber

recibido una notificación

indicándole que ya puede realizar

las pruebas necesarias.

- El analista de testing valida y

registra posibles errores que

- Hoja de atención de

testing

- Hoja de control de

requerimientos aprobados

- Project de control de

proyectos actualizado

- Casos de pruebas de

testing

- Estadísticas de pruebas de

desarrollo

- Gestor de

Desarrollo y

Testing.

- Responsable

de Testing

- Analista de

Testing

- Desarrollador

UPC

Página 52

existan en el desarrollo.

- Si el analista de testing encontrara

errores, los registra en las

estadísticas de defectos y solicita

la modificación necesaria al

desarrollador.

Trazabilidad

REQM ( SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5)

.

2. Registro de la solución y validación con el Usuario.

Propósito

Esta tarea tiene como propósito el de realizar el control final del desarrollo solicitado

en el requerimiento por parte del desarrollador y realizar las pruebas con el usuario.

Roles involucrados

Analista de Testing, Desarrollador y Usuario.


a. Casos de Prueba de Testing,

b. Registro de paquete de cambios


- Se encuentran registrados los casos de Prueba de Testing y paquetes con

cambios.


a. Hoja de Atención de testing.

b. Acta de conformidad en ambiente de pruebas.

c. Actualización de hoja de atención de testing.

Criterios de Salida

- Finaliza cuando se ha terminado de realizar las pruebas con el usuario y no

existen más errores y se ha firmado el acta de conformidad en ambiente de

pruebas.

Actividades


Responsable

- El usuario recibe una notificación

- Hoja de Atención de

- Analista de

UPC

Página 53

para realizar las pruebas

pertinentes al desarrollo.

- El usuario ejecuta las pruebas con

el Analista de Testing y en caso de

encontrar errores solicita las

modificaciones necesarias al

desarrollador, caso contrario firma

el acta de conformidad en

ambiente de pruebas.

- En el caso de que existieran

errores, estos son corregidos por

el desarrollador y en el paquete de

cambios y nuevamente el usuario

realiza las pruebas con el Analista

de Testing.

testing.

- Acta de conformidad en

ambiente de pruebas.


testing.

Testing

- Desarrollador

Trazabilidad

REQM (SP 1.2, SP 1.3, SP 1.4, SP 1.5)

3. Puesta en Producción.

Propósito

Esta tarea tiene como propósito el de realizar los pases de los requerimientos a

producción y realizar la última prueba por parte del usuario en producción y si todo

está correctamente, cerrar el requerimiento definitivamente. En caso de existir

errores, que deberían ser en menor proporción se deben de realizar las

modificaciones antes de cerrar el requerimiento.

Roles involucrados

Analista de Testing, Desarrollador, Soporte Funcional.


a. Firma de acta de conformidad en ambiente de pruebas.

b. Paquete de cambios

c. Hoja de atención de testing.


- Se encuentra aceptada el acta de conformidad en ambiente de pruebas y se

encuentra actualizado el paquete de cambios realizados.


a. Hoja de atención de testing de pruebas funcionales

UPC

Página 54

b. Acta de conformidad en ambiente de producción

c. Registro de incidencias en ambiente de producción

Criterios de Salida

- Finaliza cuando se han realizado el transporte a producción y las pruebas han

sido exitosas.

Actividades


Responsable

- El Soporte funcional realiza

pruebas funcionales adicionales y

si encontrara errores, solicita al

desarrollador las modificaciones

necesarias, previo registro en el

registro de incidencias en

producción.

- El Soporte Funcional realiza la

instalación del paquete de

cambios.

- El analista de testing y el usuario

realizan las pruebas finales en

ambiente de producción. En caso

de existir errores, estos son

registrados en los registros de

incidencias en producción y se

solicita al desarrollador las

modificaciones para solucionar el

error.

- Finalmente, si todo es correcto se

cierra el requerimiento. Se debe

actualizar la hoja de atención de

testing.

- Acta de conformidad en

ambiente de producción.


testing.

- Registro de incidencias

en producción.

- Analista de

Testing

- Desarrollador

- Soporte

Funcional

Trazabilidad

REQM (SP 1.1, 1.2, SP 1.3, SP 1.4, SP 1.5)

UPC

Página 55

5.4. Definición de indicadores de mejora

5.4.1. Propósito y alcance

El Gerente de Sistemas de Minsur S.A. trata de identificar algunas métricas que de alguna forma le

ayuden a mejorar la gestión de este proceso. Las métricas serán usadas para representar

tendencias y realizar diversos análisis que sirvan para proponer mejoras futuras de funcionamiento

y/o tomar acciones correctivas ante algunas desviaciones que se puedan presentar. El análisis se

realizará en base a la información que se vaya almacenando, ya que este proceso será

reestructurado totalmente de acuerdo a la propuesta, después de haber realizado la evaluación del

cumplimiento de las prácticas específicas de REQM.

5.4.2. Objetivo

La generación de métricas, deben ser definidas, almacenadas y analizadas. Las métricas deben ser

generadas mensualmente y colocadas en un repositorio indicado por el plan de gestión de datos. El

equipo asignado realizara el análisis comparativo y será el responsable de detectar desvíos e

identificar posibles mejoras al proceso.

5.4.3. Métricas propuestas

5.4.3.1. Cantidad de defectos en Pruebas en ambiente de pruebas

Métrica 01: Hace referencia a la cantidad total de defectos encontrados en la etapa de

pruebas internas, ya sean unitarias o integrales, en el ambiente de pruebas. Esto debe ser

registrado por el archivo de estadísticas de defectos en ambiente de pruebas, en un formato

estándar y almacenarse en un repositorio indicado en el plan de gestión de datos.

5.4.3.2. Cantidad de defectos en Pruebas funcionales en ambiente de producción

Métrica 02: Hace referencia a la cantidad total de defectos encontrados en la etapa de

pruebas funcionales en el ambiente de producción. Esto debe ser registrado por el registro

de incidencias en ambiente de producción en un formato estándar y almacenarse en un

repositorio indicado en el plan de gestión de datos.

UPC

Página 56

5.4.3.3. Líneas de código con errores por programa

Métrica 03: Hace referencia a la cantidad de errores del líneas de código por programa. Esto

debe ser registrado por el archivo de estadísticas de defectos en ambiente de pruebas, en

un formato estándar y almacenarse en un repositorio indicado en el plan de gestión de

datos.

5.4.3.4. Líneas de código con errores caso de Uso

Métrica 04: Hace referencia a la cantidad de errores de líneas de código por caso de Uso.

Esto debe ser registrado por el archivo de estadísticas de defectos en ambiente de pruebas,

en un formato estándar y almacenarse en un repositorio indicado en el plan de gestión de

datos.

6. Conclusiones

6.1. Conclusiones respecto a la madurez identificada

Después de realizar una evaluación inicial de los procesos que recomienda CMMi en la

organización “Minsur S.A.” se puede apreciar resultados que indican que la gestión de los procesos

IT está en una etapa caracterizada por un pobre nivel de madurez. La información recogida de

primera mano a partir de entrevistas a algunos miembros de TI, indican que recién en los últimos

años, a raíz de la implantación ERP “SAP ECC 6.0” se ha tenido que alinear, casi por mandato,

muchos de los procesos y procedimientos de atención del área de Sistemas, de cara al usuario.

A pesar que siguen habiendo muchos vacíos, e improvisaciones, los últimos 5 años se ha tomado

un raudo camino de mejora en cuanto a establecer ciertos mecanismos de atención a los usuarios,

y evitar sobrecargas o retrabajos en los miembros de los equipos de Sistemas. Esto se manifiesta

en el ordenamiento que ha traído el Gerente actual de Sistemas, lo cual, a pesar de los cambios

que impone el negocio, ha sabido cohesionar personas y equipos, ha logrado establecer funciones

y responsabilidades, incluyendo al personal de Sistemas que están destacados en las unidades

mineras (en el interior del país).

A pesar del avance logrado, la organización IT sigue estando lejos de tener procesos maduros que

permitan lograr eficiencia en las funciones que le competen. En el pasado se ha apelado a la

improvisación, sobrecarga de trabajo y “héroes” las cuales son características negativas en una

organización IT. Sin embargo, se aprecia que en el camino recorrido se ha conseguido logros, y

UPC

Página 57

definitivamente se debe reconocer que es un buen momento para aplicar el modelo CMMi en el

Área de Sistemas de Minsur.

Estas prácticas mejoraran sustancialmente las plataformas informáticas y su mantenimiento, lo que

conllevará a aprovechar la inversión realizada por la empresa, así como a apoyar y solucionar todo

requerimiento de cambio, corrección o desarrollo que requieran los usuarios para el normal

desempeño de las actividades de la organización.

6.2. Proceso conveniente para comenzar

Para la implantación del modelo CMMi en el Área de Sistemas de la organización Minsur S.A. es

recomendable comenzar por el proceso “PP”, Project Planning.

6.3. Propuesta de indicadores de éxito

Indicador de complejidad de los requerimientos.

Este indicador permitiría conocer el porcentaje por cada nivel de complejidad de los requerimientos, lo cual,

permitirá poder asignar y capacitar a los analistas del nivel con mayor porcentaje de complejidad. Logrando

así tener un mejor control de la atención de los requerimientos y asegurar que se brindara la solución más

óptima, incrementando el porcentaje de calidad.

Indicador de desviación de esfuerzo.

Este indicador permitirá conocer el porcentaje del tiempo que se consume en otras actividades diferentes a

la del proyecto. Se busca disminuir este porcentaje para lograr los objetivos en los tiempos pactados.

Indicador de requerimientos no comunes.

Este permitirá identificar el porcentaje de casos inusuales que se presentan de forma diaria, de esta manera

asignarle al analista un tiempo mayor en el tiempo de solución y aseguramiento de calidad.

6.4. Otras conclusiones

El presente entregable comprende el diagnóstico de las prácticas de desarrollo de software actual

para el Área de Sistemas de la compañía minera Minsur S.A. Al revisar los procesos y actividades

que se realizan en el área de TI logramos entender el contexto, prácticas, actividades y logramos

UPC

Página 58

identificar qué áreas de proceso vamos a evaluar para que se obtenga mejoras de algún proceso de

gestión interna.

Para cada punto evaluado hemos tratado de enfocarnos lo más cercano posible a la realidad, por

tanto las calificaciones obtenidas reflejan la situación actual de la empresa en cuanto a desarrollo de

software.

Según las calificaciones obtenidas tenemos que la empresa seleccionada cumple parcialmente con

las prácticas recomendadas y que debe mejorar el proceso de tal manera que permitan obtener

eficiencia en el proceso logrando un óptimo producto de software.

Concluimos que la implementación del CMMI permitirá a la empresa optimizar su proceso de

desarrollo de software optimizando recursos, evitando retrabajos, reduciendo y planificando el

tiempo asignado a los proyectos así como tener la visibilidad de evaluar y decidir la introducción de

nuevas tecnologías, técnicas y herramientas de desarrollo.

implementacion de cmmi en una compañia minera

Documents