Universidad Peruana de Ciencias Aplicadas

CMMI Capability Maturity Model Integration

Implementacin de CMMI

Autor:

Tirso Villanueva Ortiz

Lima, 18 de Febrero 2012

Pgina 1

UPC

INDICE
1. 1.1. 1.2. 1.3. 1.4. 1.5. 2. 3. 3.1. 3.2. 4. OBJETO DE ESTUDIO.............................................................................................................. 4 Descripcin de la empresa ................................................................................................ 4 Misin ................................................................................................................................ 4 Visin ................................................................................................................................. 4 Organizacin...................................................................................................................... 4 Objetivos del Negocio ....................................................................................................... 6 ALCANCE DE LA EVALUACION ............................................................................................... 9 FACTIBILIDAD DEL CAMBIO.- ................................................................................................. 9 Resea sobre antecedentes de cambios de procesos: ..................................................... 9 Probables focos de resistencia: ....................................................................................... 11 EVALUACIN DE LA SITUACIN ACTUAL ............................................................................ 12

4.1. Procesos, mecanismos, mtodos, prcticas, etc., que actualmente funcionan bien, y que se deben mantener: ............................................................................................................. 12 4.2. 4.3. 4.4. 4.5. 4.5.1. 4.5.2. 4.5.3. 4.5.4. 4.5.5. 4.5.6. 4.6. 4.6.1. 4.6.2. 5. 5.1. 5.1.1. 5.1.2. 5.1.3. Problemas u oportunidades de mejora conocidos: ........................................................ 13 Factores clave de xito actuales: .................................................................................... 14 Descripcin de las fuentes de informacin utilizadas ..................................................... 15 Evaluacin de cumplimiento de las prcticas especficas ............................................... 17 Evaluacin de cumplimiento de las prcticas especficas en PP ................................. 17 Aplicacin de Metas Genricas en Planeamiento de Proyecto .................................. 19 Evaluacin de cumplimiento de las prcticas especficas en PMC ............................. 21 Aplicacin de Metas Genricas en PMC...................................................................... 23 Evaluacin de cumplimiento de las prcticas especficas en REQM ........................... 24 Aplicacin de Metas Genricas en REQM ................................................................... 25 Presentacin de resultados ............................................................................................. 27 Por cada rea de proceso, % de prcticas cumplidas y no cumplidas ........................ 27 % total de prcticas cumplidas y no cumplidas........................................................... 29

Procesos para la organizacin en estudio ........................................................................... 30 Nuevo proceso establecido para la organizacin............................................................ 30 Nombre del proceso .................................................................................................... 30 Implementacin .......................................................................................................... 30 Propsito del proceso ................................................................................................. 30

Pgina 2

UPC
5.1.4. 5.1.5. 5.1.6. 5.1.7. 5.1.8. 5.1.9. 5.2. 5.2.1. 5.2.2. 5.3. 5.3.1. 5.3.2. 5.4. 5.4.1. 5.4.2. 5.4.3. 5.4.3.1. 5.4.3.2. 5.4.3.3. 5.4.3.4. 6. 6.1. 6.2. 6.3. 6.4. Roles ............................................................................................................................ 30 Alcance del proceso .................................................................................................... 31 Plantillas de documentos a utilizar ............................................................................. 31 Descripcin del proceso .............................................................................................. 32 Flujograma del proceso ............................................................................................... 35 Matriz de Trazabilidad de Procedimientos versus Prcticas Especficas .................... 37 Planificacin de Proyectos .............................................................................................. 38 Situacin problemtica ............................................................................................... 38 Flujo del proceso ......................................................................................................... 39 Gestin de requerimientos ............................................................................................. 49 Situacin problemtica ............................................................................................... 49 Flujo de Proceso .......................................................................................................... 50 Definicin de indicadores de mejora .............................................................................. 55 Propsito y alcance ..................................................................................................... 55 Objetivo ....................................................................................................................... 55 Mtricas propuestas.................................................................................................... 55 Cantidad de defectos en Pruebas en ambiente de pruebas ................................... 55 Cantidad de defectos en Pruebas funcionales en ambiente de produccin........... 55 Lneas de cdigo con errores por programa ........................................................... 56 Lneas de cdigo con errores caso de Uso ............................................................. 56

Conclusiones........................................................................................................................ 56 Conclusiones respecto a la madurez identificada ........................................................... 56 Proceso conveniente para comenzar .............................................................................. 57 Propuesta de indicadores de xito .................................................................................. 57 Otras conclusiones .......................................................................................................... 57

Pgina 3

UPC

1. OBJETO DE ESTUDIO 1.1. Descripcin de la empresa

Minsur S.A. es una empresa peruana dedicada a la explotacin, procesamiento y comercializacin del estao, as como a la exploracin de nuevos yacimientos. Minsur S.A. es una empresa minera altamente rentable y competitiva gracias a su experiencia y a los exigentes estndares 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 tecnologa de vanguardia monitoreada y administrada por un equipo humano comprometido. La empresa cuenta un rea que tiene como misin la definicin, implantacin y administracin de las tecnologas de informacin, asegurndose que estn alineadas con las estrategias del negocio y apoyando al cumplimiento de objetivos de cada rea de MINSUR.

1.2.

Misin

Minsur S.A. se orienta a alcanzar y mantener elevados estndares de calidad en cuanto a proteccin ambiental; establecer relaciones de responsabilidad social con sus trabajadores y comunidades vecinas, innovar constantemente a nivel estructural y tecnolgico y satisfacer a plenitud las exigencias de los mercados internacionales de minerales.

1.3.

Visin

Convertirnos en el mayor productor y exportador de concentrados de estao a nivel mundial, comercializndolos con los precios ms competitivos, a travs de una cadena de abastecimiento que incurra en los mas ptimos costos de produccin.

1.4.

Organizacin

Minsur S.A. cuenta con una estructura organizacional conformada por profesionales distribuidos en el siguiente organigrama:

Pgina 4

Organigrama de Minsur S.A.

Fuente: Minsur S.A.

Pgina 5

1.5.

Objetivos del Negocio

El rea de Sistemas tiene como misin la definicin, implantacin y administracin de las tecnologas de informacin, asegurndose de que estn alineadas con las estrategias del negocio y apoyando al cumplimiento de los objetivos de cada rea de MINSUR. Para cubrir sus necesidades tecnolgicas, la empresa adquiri el ERP SAP ECC 6.0, del cual se ha implementado los mdulos de Finanzas, Logstica, Mantenimiento, Produccin, Proyectos, Business Intelligent y BPC (Business Planning and Consolidation). Adems, cuenta con varios aplicativos industriales para los procesos de produccin, para exploracin minera y proceso de concentracin del mineral (plantas concentradoras).

Si bien es cierto que Minsur S.A. no es una empresa de tecnologa, sino de extraccin y procesamiento de minerales, depende en gran medida del rea de Sistemas para el logro de sus objetivos. Los siguientes son los lineamientos que guan las acciones de esta rea:

Estrategia o Desarrollar, conseguir la aprobacin y mantener el Plan Estratgico de Sistemas, que sea consistente con los planes y objetivos de la empresa, y este en lnea con los Presupuestos de Sistemas y Tecnologa o Mantenerse permanentemente actualizado con la evolucin de las tecnologas de informacin que puedan impactar positiva o negativamente a la empresa

Organizacin o o o Asegurar que el personal del rea tenga las mejores capacidades personales y profesionales necesarias para ejecutar las funciones Desarrollar y mantener profesionales responsables que tengan planes de capacitacin y desarrollo profesional Promover el trabajo en equipo al interior del rea y la empresa

Finanzas o o o o Responsable por la elaboracin de los presupuestos de gastos e inversin en tecnologas de informacin y telecomunicaciones de toda la empresa Monitorear y explicar las desviaciones en los presupuestos Cumplir y hacer cumplir las polticas financieras de la empresa Asegurar el control y seguimiento de los cambios en la infraestructura tecnolgica

Sistemas de Informacin

Pgina 6

UPC
o Responsable por mantener, ampliar, desarrollar o adquirir los sistemas de informacin que satisfagan las necesidades de la empresa, teniendo en cuenta factores de costo-beneficio o o o Definir personal responsable por el soporte a los sistemas de informacin en uso Definir metodologas, estndares y herramientas de desarrollo Controlar y mantener actualizada la documentacin de los sistemas de informacin en uso, particularmente la relacionada al usuario

Proyectos de Tecnologas de Informacin y Telecomunicaciones o o o Responsable por todos los proyectos del rea de Sistemas y Tecnologa Definir la metodologa, controles y responsables en los distintos proyectos del rea Asegurar la disponibilidad de todos los recursos necesarios para el xito de los proyectos de tecnologas de informacin

Soporte y Operaciones o o Controlar el cumplimiento de objetivos de soporte y operaciones Asegurar la documentacin de los distintos procesos realizados

Seguridad o o o Responsable por mantener la confidencialidad, integridad y disponibilidad de la informacin para la empresa Implementar polticas y estndares de seguridad Asegurar que los equipos y recursos crticos estn cubiertos por un adecuado plan de contingencia

Proveedores o o o o Seleccionar a los distintos proveedores de tecnologa de informacin y comunicaciones calificando costos, reputacin, solidez, y capacidad de soporte Responsable por conseguir el mejor ratio costo-beneficio Asegurar que todos los servicios contratados estn cubiertos por un contrato aprobado por el rea legal de la empresa Asegurar que todos los servicios contratados tienen acuerdos de nivel de servicio.

Pgina 7

Organigrama del rea de Sistemas de Minsur S.A.

Fuente: Minsur S.A.

Pgina 8

2. ALCANCE DE LA EVALUACION
La evaluacin a la organizacin Minsur S.A., en cuanto a la aplicacin de las buenas prcticas indicadas por el modelo CMMi, estar ubicada en el proceso de atencin 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 mdulos funcionales:

Finanzas y Tesorera Recursos Humanos Logstica Costos y Presupuestos SAP Portal (NetWeaver) SAP BPC SAP Basis

Los requerimientos son de cambios en la configuracin, correcciones, actualizacin de informacin y desarrollos, sobre todo de informes.

3. FACTIBILIDAD DEL CAMBIO.3.1. Resea sobre antecedentes de cambios de procesos:

Desde la creacin del rea de Sistemas se han realizado algunos proyectos que han impactado sobre la organizacin y sus procesos, entre los cuales podemos mencionar la implementacin del Sistema de Gestin de Requerimientos.

En el pasado se contaba con un servidor AS/400 y algunos aplicativos hechos en FoxPro, como el de control de la produccin y plantas concentradoras. En el sistema AS/400 se manejaban los sistemas de planillas, logstica, 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 tcnicos de soporte. El jefe entregaba el requerimiento directamente al analista, ste hacia la especificacin tcnica del cambio, y se la entregaba al programador para que lo implemente en el sistema que corresponda.

No exista rea de Testing. No exista gestin de control de cambios.

Pgina 9

UPC
El documento de cambio o de solicitud de algn requerimiento se realizaba por e-mail o documentos fsicos. El proceso era de interpretacin directa del programador, por otro lado no existan ni designaban analistas funcionales que interactuaran directamente con el programador. El paso de los cambios de algn componente en cualquier aplicacin se realizaba directamente en produccin sin realizar pruebas con el usuario sino, nicamente, pruebas unitarias. No existan jefes de proyecto y no haba un responsable que tuviera el control de versiones de las aplicaciones. Tampoco se registraba la aceptacin del cambio por parte del cliente.

En el pasado no se manejaban los proyectos como tales. A partir del ao 2004, el rea de Sistemas comenz a manejar los requerimientos grandes como proyectos, los cuales incluan, adicionalmente a los cronogramas y manejo de recursos, elaboracin de actas de reuniones, actividades de seguimiento, replanificacin de actividades, etc.

Debido a todos estos antecedentes es que se decidi implementar un sistema de registro de requerimientos a travs de una aplicacin desarrollado en Lotus Notes. La implementacin del proyecto demor 7 meses. Como toda organizacin un grupo de personas se mantuvieron resistentes al cambio, donde la principal crtica era que el registro de sus requerimientos en el sistema les demandaba ms tiempo en sus labores.

Antes de la implementacin de este sistema, los requerimientos se solicitaban de manera manual, brindando escuetamente el detalle del requerimiento. Este proceso era engorroso, desordenado y no permita 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 documentacin, antes no exista, o era casi nula. Hoy se documenta parcialmente, y se generan:

Cronogramas de actividades Diseos tcnicos (pero no en todas las ocasiones)

En la actualidad solamente se est archivando los documentos asociados a proyectos, mas no a atencin a los requerimientos. Desde el ao 2010 se cuenta con un File Server donde cada proyecto tiene su repositorio, con permisos para modificar la documentacin. Actualmente, no se est aprovechando esta informacin. Otra deficiencia es que no se documentan las pruebas unitarias ni funcionales.

Pgina 10

UPC
Hoy los procedimientos estn documentados en gran medida, pero no estn completos. Falta definir plantillas, estndares, etc.

Adicionalmente, siempre ha existido la limitante de los recursos en el rea. La Alta Direccin nunca dio pase para contar con un nmero adecuado de personas, evitando la sobrecarga y saturacin en el personal de IT.

3.2.

Probables focos de resistencia:

Los cambios implementados en los ltimos aos en el rea de Sistemas de Minsur, han tenido resistencia proveniente de las siguientes fuentes: Muchas veces la atencin 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 mantenan reacios a realizar sus solicitudes a travs de la aplicacin Sistema de Gestin de Requerimientos. En algunos casos el consultor del rea de Sistemas lo tena que realizar. El motivo de esta resistencia se ha determinado que los usuarios no tienen buena predisposicin a los cambios tecnolgicos que ofrece el rea de Sistemas. Se ha determinado que ante implantaciones de soluciones tecnolgicas, algunos usuarios ponen trabas pues sienten temor en perder sus puestos de trabajo. Algunos analistas funcionales no utilizaban el formulario del Sistema de Gestin de Requerimientos, sino que lo hacan en una plantilla antigua que, por procedimiento, ya ha haba sido dada de baja. Desde hace un tiempo atrs 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 tcnicos y de personas para tener todos los elementos necesarios para dar el soporte a dichos aplicativos, como por ejemplo: manuales, know-how para solucin de problemas, CDs de los programas

instaladores, etc. Algunos usuarios con conocimientos de aplicativos software muy especficos, ponen trabas para dar a conocer al rea de Sistemas las actividades que realizaban cuando se presentaba incidentes con dichos aplicativos.

Pgina 11

UPC

4. EVALUACIN DE LA SITUACIN ACTUAL 4.1. Procesos, mecanismos, mtodos, prcticas, etc., que actualmente funcionan bien, y que se deben mantener:

1) Requerimientos en los aplicativos Se cuenta con un mdulo de ingreso de los requerimientos. Los usuarios colocan directamente sus requerimientos, pero, pasan por una aprobacin 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 solucin coordinando las pruebas y documentacin respectiva. El analista funcional es responsable del paquete de cambios de la solucin que atiende, inclusive si ha sido realizado por otro analista-programador, y se hace responsable de su implementacin, pruebas y puesta en produccin. La puesta en produccin la realiza el administrador del sistema (llamado tcnico SAP Basis). El analista hace el seguimiento de todas las etapas de la atencin del requerimiento dentro de IT. Cada requerimiento atendido tiene que pasar necesariamente por la revisin del rea de Testing. El operador no procesar un pase a produccin si no tiene el visto bueno del rea de Testing, La persona de Testing tambin prueba los entregables en base a una cola de trabajos, supervisados por el Gerente de Sistemas. Despus que se instala el cambio en produccin, el analista responsable constata el funcionamiento correcto con el usuario solicitante. Se est logrando alcanzar trazabilidad en la atencin 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 aos de experiencia dentro de la organizacin, lo cual es positivo en trminos de entendimiento de

Pgina 12

UPC
los procesos de negocio y comprensin rpida e interpretacin de las necesidades de los usuarios.

3) Desarrollo y mantenimiento de aplicaciones Existen ambientes de los sistemas tanto para produccin, desarrollo y pruebas funcionales.

4) Sobre los proyectos

- Se estn manejando como tales desde hace dos aos, aproximadamente. La poltica 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 capacitacin en un 95 % de los cursos ofrecidos.

4.2.

Problemas u oportunidades de mejora conocidos:

Problemas:

El nmero 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 ms. Recin el ao 2011 se contrat la primera persona designada oficialmente para ese cargo.

Cada consultor del ERP atiende exclusivamente un mdulo. Cuando se retira de vacaciones o de viaje se crea un vaco que no es suplido por ningn otro recurso para atender requerimientos o incidentes en ese modulo.

Pgina 13

UPC
Oportunidades:

El pool de consultores del ERP tiene una buena experiencia con dicho aplicativo, y estn en capacidad de realizar implementaciones tales como absorcin 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 Direccin no ha brindado la suficiente importancia al rea de Tecnologas de la Informacin, con lo cual se ha visto relegado muchos proyectos importantes en el pasado. En los ltimos aos recin se est brindando un apoyo financiero al rea, tal como contratacin de ms 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 direccin de Sistemas, tiene una gran oportunidad de presentar un Plan Estratgico de Sistemas completo a la Gerencia General, mostrando las ventajas competitivas que podra lograr Minsur, construyendo una plataforma tecnolgica integral que brinde el mejor soporte operacional y de toma de decisiones para la organizacin, a la vez que podra reducir costos mejorando procesos y optimizando tareas.

Lamentablemente, la organizacin no cuenta con mtricas o estadsticas que documenten estas aseveraciones.

4.3.

Factores clave de xito actuales:

El Gerente de Sistemas ha creado y establecido un plan de capacitacin 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 tcnicos que se dedican a la atencin del ERP han

adquirido conocimiento avanzado para la configuracin, mantenimiento y tareas adicionales del mismo. Como muestra de ello, se tiene un mximo de 4% de errores en el tema de migraciones, originadas por instalacin de nuevas versiones del software, aplicacin de paquetes de correctivos (patchs), etc.

Existe buena predisposicin del personal de sistemas para aceptar los cambios que imparte la Gerencia de Sistemas.

Pgina 14

UPC

La empresa est en constante actualizacin tecnolgica, para ello, ha realizado un contrato de leasing con el proveedor de equipos de computacin Lenovo, empresa que efecta la renovacin de los equipos de hardware con la siguiente periodicidad:

Para las laptops la renovacin es cada 2 aos. Para los equipos desktop la renovacin es cada 3 aos.

4.4.

Descripcin de las fuentes de informacin utilizadas

Reuniones y entrevistas

Se coordin reuniones con algunos miembros de los equipos de TI de la empresa, el contacto fue a travs de la gestin 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 especficas. Se ha tomado encuesta al Gerente de Sistemas sobre algunas tareas de gestin de seguimientos al proyecto.

Documentos

Para validar la informacin brindada se ha solicitado nos muestren la documentacin correspondiente que administran.

En Minsur la documentacin es administrada en los repositorios de los servidores archivos, y estn clasificados en 5 grandes tipos. A continuacin se indica dicha clasificacin:

1. Polticas y procedimientos de TI
Estn las polticas de la organizacin y las normativas y/o comunicados que se han realizado hasta la fecha.

2. Documentos de Capacitacin Pgina 15

UPC
Se tiene la documentacin a utilizar para las capacitaciones para SAP, tambin el uso de Lotus Notes para el manejo de cmo realizar las gestiones de requerimientos y las gestiones de reuniones.

3. Informacin General
Documento de inters a todo el personal de TI. Documentos referentes al Symposium Gartner 2009.

4. Documentacin TI
Informacin referente a los recursos de TI, tales como: Aplicaciones Infraestructura Recursos Humanos

Informacin de Servicios que brinda TI, tales como: Administracin de la configuracin. Contratos Controles TI Gestin de proyectos Gestin de servicios TI Mejora continua Servicios de terceros

5. Informacin General TI
Copia de encuestas que se realizan semestralmente, Documentacin de pruebas realizadas. Instaladores y componentes SAP

Pgina 16

UPC

4.5. Evaluacin de cumplimiento de las prcticas especficas 4.5.1. Evaluacin de cumplimiento de las prcticas especficas en PP
[SG1] Establecer estimaciones [SP 1.1] Est descrito en algn lugar cul es el alcance del proyecto, al Estimar el alcance del menos en alto nivel? proyecto 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 tamao de los productos? Se asignan niveles de complejidad a los elementos que se desarrollarn? Se puede conocer cul fue el tamao de los proyectos anteriores? Si, en el Diagrama de Gantt se describen la duracin de las tareas en base a una estimacin. 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 tamao 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. Existe alguna definicin que seale cules son los ciclos de vida posibles? Esta definicin es conocida, y se utiliza para planificar el proyecto? No, solo existe el WBS. No, porque no existe.

[SP 1.3] Definir el Ciclo de Vida del Proyecto

[SP 1.4] Determinar las estimaciones de esfuerzo y coste

Se calcula el estimado utilizando algn procedimiento (adems del juicio de experto)? Se toma en cuenta la informacin histrica? Se conoce bajo qu supuestos se estim? Si, Se aplica la tcnica de estimacin definida en SP 1.2 Tambin, se tomo en cuenta informacin generada en proyectos previos. No siempre se conoce bajo que supuestos se estimo. A veces, el gerente de sistemas es el que define la estimacin 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 estimacin registrada en WBS y se adicionan los costos relacionados a su elaboracin.

Pgina 17

UPC
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 elaboracin 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 algn 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 gestin de los datos Existe un plan de datos del proyecto? Se sabe qu informacin se debe recolectar y cul 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 estn definidos. Solo pueden accesar al repositorio de documentos solo las personas relacionadas al proyecto. No se maneja control de versin en los entregables. [SP 2.4] Planificar los recursos del proyecto Se determinan los recursos humanos, equipamiento, etc., necesarios del proyecto? Dnde 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 capacitacin de los recursos humanos del proyecto? Cmo? En dnde se planifican las acciones de capacitacin necesarias? No siempre se identifican las necesidades de capacitacin 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? Cmo se sabe cules son? Dnde se registra el resultado de la planificacin? Si, los stakeholders son registrados tambin 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 documentacin relacionada a un proyecto.

Pgina 18

UPC
[SG3] Obtener el compromiso con el plan [SP 3.1] Revisar los Se identifican otros planes de los que depende el proyecto? planes que afectan el Dnde se documentan para su posterior seguimiento? proyecto 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? Cmo? Si, a travs de reuniones semanales en donde cada responsable debe informar su avance.

4.5.2. Aplicacin de Metas Genricas en Planeamiento de Proyecto

[GG1] Lograr las metas especficas [GP 1.1] Cumplir las SPs del rea de proceso. Realizar las prcticas especficas

[GG2] Institucionalizar un proceso gestionado [GP 2.1] Establecer el presupuesto y el calendario Existe una poltica que indique cmo se debe realizar la planificacin del proyecto? No,, la empresa no dispone procedimientos establecidos para la planificacin Las personas que realizan la planificacin conocen esta poltica? La utilizan? La planificacin la realizan generalmente basndose en criterios profesionales.

Pgina 19

UPC
[GP 2.2] Planificar el proceso Las actividades que se realizan durante el plan, se encuentran planificadas? Si, estn descritas en el WBS. [GP 2.3] Proporcionar recursos Se asignan recursos para la planificacin? (plantillas, software, etc.) Si, el Project Charter, WBS, y plantillas utilizadas en otros proyectos [GP 2.4] Asignar responsabilidad Est establecido qu roles estn involucrados en el planeamiento del proyecto, y est documentado quines desempean estos roles? Si, se establece los roles de las personas que estn 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 funcin de cada participante antes de iniciar la ejecucin del proceso.

[GP 2.6] Controlar entregables (gestionar configuraciones en la v.1.2) [GP 2.7] Identificar e involucrar a las partes interesadas y relevantes.

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

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. Se utilizan indicadores para controlar el proceso de planeamiento? No se utilizan.

[GP 2.8] Monitorizar y controlar el proceso.

[GP 2.9] Evaluar objetivamente la adherencia

Se revisa la adherencia de las actividades de planificacin ejecutadas versus el proceso establecido en la poltica? No, el cumplimiento de las actividades de planificacin es evaluado por las personas involucradas en la planificacin 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 planificacin de los proyectos? Mediante reuniones planificadas.

Pgina 20

UPC

4.5.3. Evaluacin de cumplimiento de las prcticas especficas en PMC

[SG1] Monitorizar el proyecto frente al plan [SP 1.1] Se hace seguimiento al avance del cronograma, considerando Monitorizar los avance esperado vs real? parmetros de Si, se va adicionando el porcentaje de avance por cada actividad en planificacin del el WBS. proyecto 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 gestin de datos

Se verifica que se estn produciendo los entregables acordados? Se se verifica que los entregables de entrada estn 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 peridicamente, realizado por el equipo de soporte tcnico.

Pgina 21

UPC
Se toma accin 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 ms pronto posible.

[SP 1.5] Monitorizar la involucracin de las partes interesadas

Se hace seguimiento a la participacin de los stakeholders identificados? Si, en el cronograma estn 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 peridicamente? El equipo de proyecto conoce el estado del proyecto? Si, semanalmente. De cada reunin se genera un acta que incluye a los participantes y acuerdos y es enviado a todos los involucrados va 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 reunin se establecen la conformidad o inconformidad de los entregables, pero no se guarda en el repositorio como documentacin 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 cules 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.

Pgina 22

UPC
Se puede conocer cul es la lista de problemas pendientes de solucionar del proyecto? No se registra.

4.5.4. Aplicacin de Metas Genricas en PMC

[GG1] Lograr las metas especficas [GP 1.1] Cumplir las SPs del rea de proceso. Realizar las prcticas especficas [GG2] Institucionalizar un proceso gestionado [GP 2.1] Establecer una poltica de la organizacin Existe una poltica que indique cmo se debe realizar el control del proyecto? No existe, actualmente se encuentra en proceso de estandarizacin Las personas que realizan el control conocen esta poltica y la utilizan? No, por lo que no existe. [GP 2.2] Planificar el proceso Las actividades que forman parte del control, se encuentran planificadas? Si, en el cronograma de actividades - WBS.

[GP 2.3] Proporcionar recursos

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.

[GP 2.4] Asignar responsabilidad

Est establecido qu roles estn involucrados en el control del proyecto? Est documentado quines desempean estos roles? Si, se establece que rol va a tener cada una de las personas involucradas, pero no se documenta quienes desempearn cada uno.

[GP 2.5] 2.5 Formar (entrenar) al personal

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

Pgina 23

UPC
[GP 2.6] Controlar entregables (gestionar configuraciones en la v.1.2) [GP 2.7] Identificar e involucrar a las partes interesadas y relevantes. [GP 2.8] Monitorizar y controlar el proceso. 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.

[GP 2.9] Evaluar objetivamente la adherencia [SP 2.10] Revisar el estado con el nivel directivo

Se revisa la adherencia de las actividades de control de proyecto ejecutadas versus el proceso establecido en la poltica? No Se entera la Gerencia del progreso y resultados del proyecto? A travs de las reuniones programadas.

4.5.5. Evaluacin de cumplimiento de las prcticas especficas en REQM

[SG1] Gestionar los requerimientos [SP 1.1] Existen criterios para aceptar requerimientos? (ejemplo de criterios: Obtener una plantilla para recibirlos, fuentes autorizadas de requerimientos, comprensin de los trminos a evitar, etc.) requerimientos Si existe un sistema llamado Sistema de Gestin 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 Gestin de requerimientos desarrollado en Lotus Notes. [SP 1.2] Obtener el compromiso sobre los requerimientos Existe algn mecanismo que permita obtener el compromiso de los desarrolladores y testers con los requerimientos? Si, mediante reuniones. Este mecanismo se ejecuta en la prctica? Si, por cada reunin se registra un acta que incluye a los participantes y acuerdos establecidos. (en Lotus Notes).

Pgina 24

UPC
[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 Gestin de Requerimientos. Se evala el impacto? Por todos los posibles afectados? (desarrolladores, analistas, testers) Si, en reuniones Se registra el impacto? Si, en el sistema de Gestin de Requerimientos. Se hace seguimiento a la aplicacin 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 cdigo fuente? Si, existe la especificacin funcional, la documentacin del desarrollo, las observaciones del tester, las observaciones de las pruebas realizadas por el usuario. Todo esto se encuentra en el sistema de Gestin 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 estn siendo considerados en el plan? Se actualiza el cronograma

4.5.6. Aplicacin de Metas Genricas en REQM

[GG1] Lograr las metas especficas [GP 1.1] Cumplir las SPs del rea de proceso. Realizar las prcticas especficas [GG2] Institucionalizar un proceso gestionado [GP 2.1] Establecer una poltica de la organizacin Existe una poltica que indique cmo se debe realizar la gestin de los requerimientos? Si, la empresa cuenta con un documento de procedimiento

Las personas que realizan la gestin de requerimientos conocen esta poltica y la cumplen? Si, la cumplen parcialmente. [GP 2.2] Planificar el proceso Las actividades de gestin de requerimientos, se encuentran planificadas? Si, en el cronograma

Pgina 25

UPC
[GP 2.3] Proporcionar recursos Cules son los recursos que se utilizan para la gestin 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.

[GP 2.4] Asignar responsabilidad

Est establecido qu roles estn involucrados en la gestin de requerimientos? Est documentado quines desempean estos roles? Si, si est establecido.

[GP 2.5] 2.5 Formar (entrenar) al personal

Est establecido qu roles estn involucrados en la gestin de requerimientos? Est documentado quines desempean estos roles? Si, si se recibe capacitacin, pero no est documentado.

[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 la gestin de requerimientos? No, no existen documentos ni otro medio donde se guarden las versiones.

[GP 2.7] Identificar e involucrar a las partes interesadas y relevantes. [GP 2.8] Monitorizar y controlar el proceso.

Se conoce a quienes se debe involucrar en las actividades de gestin de requerimientos? Si, si se conocen. Se utilizan indicadores para controlar la gestin de los requerimientos? No, no existen indicadores por proceso.

[GP 2.9] Evaluar objetivamente la adherencia

Se revisa la adherencia de las actividades de gestin de requerimientos ejecutadas versus el proceso establecido en la poltica? Si, se muestra en el WBS.

[SP 2.10] Revisar el estado con el nivel directivo

Se entera la Gerencia del progreso y resultados de las actividades de la gestin de requerimientos? Mediante reuniones programadas.

Pgina 26

UPC

4.6.

Presentacin de resultados

4.6.1. Por cada rea de proceso, % de prcticas cumplidas y no cumplidas

numero Project Planning Project Monitoring and Control Requirements Management

Cumple porcentaje

No cumple numero porcentaje

17 13 13

68% 62% 81%

8 8 3

32% 38% 19%

El cuadro indica el porcentaje de cumplimiento, y si no se cumple, se especifica porcentaje en la forma como lo trabajan.

Project Planning SG 1 Establecer estimaciones SP 1.1 SP 1.2 SP 1.3 SP 1.4 SP 2.1 SP 2.2 SP 2.3 SP 2.4

Se Cumple? SI SI SI SI SI NO SI NO

% de complimiento/No Cumplimiento 100% 100% 100% 100% 100% 0% 100% 0%

SG 2 Desarrollar un plan de proyecto

Pgina 27

UPC
SP 2.5 SP 2.6 SP 2.7 SG 3 Obtener compromiso con el plan SP 3.1 SP 3.2 SP 3.3 GP 1.1 NO SI NO NO SI SI SI 0% 100% 0% 0% 100% 100% 100%

GG 1 Lograr las metas especficas GG 2 Institucionalizar un proceso gestionado

GP 2.1 GP 2.2 GP 2.3 GP 2.4 GP 2.5 GP 2.6 GP 2.7 GP 2.8 GP 2.9 GP 2.10

SI SI SI SI SI NO SI NO NO SI

100% 100% 100% 100% 100% 0% 100% 0% 0% 100%

Project Monitoring and Control SG 1 Monitorizar el proyecto frente al plan SP 1.1 SP 1.2 SP 1.3 SP 1.4 SP 1.5 SP 1.6 SP 1.7 SP 2.1 SP 2.2 SP 2.3 GG 1 Lograr las metas especficas GG 2 Institucionalizar un proceso gestionado GP 1.1

Se cumple? SI NO SI SI SI SI SI NO NO SI

% de complimiento/No Cumplimiento 100% 0% 100% 100% 100% 100% 100% 0% 0% 100%

SG 2 Gestionar las acciones correctivas hasta su cierre

SI GP 2.1 GP 2.2 GP 2.3 GP 2.4 GP 2.5 GP 2.6 GP 2.7 GP 2.8 GP 2.9 GP 2.10 NO SI NO SI SI NO SI NO NO SI

100% 0% 100% 0% 100% 100% 0% 100% 0% 0% 100%

Requirements Management

Se Cumple?

% de complimiento/No Cumplimiento

Pgina 28

UPC

SG 1 Gestionar los requerimientos

SP 1.1 SP 1.2 SP 1.3 SP 1.4 SP 1.5 GP 1.1

SI SI SI SI SI

100% 100% 100% 100% 100%

GG 1 Lograr las metas especficas GG 2 Institucionalizar un proceso gestionado

SI GP 2.1 GP 2.2 GP 2.3 GP 2.4 GP 2.5 GP 2.6 GP 2.7 GP 2.8 GP 2.9 GP 2.10 SI SI NO SI SI NO SI NO SI SI

100% 100% 100% 0% 100% 100% 0% 100% 0% 100% 100%

4.6.2. % total de prcticas cumplidas y no cumplidas

El nmero total de prcticas cumplidas son 43 y las no cumplidas son 19

Pgina 29

UPC

5. Procesos para la organizacin en estudio 5.1. Nuevo proceso establecido para la organizacin

5.1.1. Nombre del proceso

El nuevo proceso definido para mejorar el desempeo de la organizacin de TI en Minsur S.A. se llama Gestin de Calidad de Software de Minsur. Su orientacin indica que el rea de Sistemas producir entregables de software con un mnimo o cero numero de defectos por requerimiento atendido.

5.1.2. Implementacin
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 sern los analistas de Testing.

5.1.3. Propsito del proceso

El propsito del nuevo proceso Gestin de Calidad de Software de Minsur es reducir al 5% el nmero de errores que se presenten en las atenciones ya instaladas en los ambientes de produccin de los diferentes requerimientos de correcciones, cambios o desarrollos que atienda el rea de Sistemas.

5.1.4. Roles
Los diferentes miembros del equipo atencin de requerimientos, incluyendo las reas de Desarrollo y Testing, trabajarn desempeando alguno de estos roles:

Gestor de Desarrollo y Testing Responsable de Testing Analistas de Testing Desarrollador Usuario Soporte Funcional

Pgina 30

UPC

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 ms en la Hoja de Atencin 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 Atencin de Testing.

5.1.6. Plantillas de documentos a utilizar

Las plantillas de los documentos que sern utilizados en el nuevo proceso definido Gestin 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 trminos de acuerdo entre el rea usuario y el rea de Sistema.

c ) Anlisis Funcional : elaborado por el Analista Funcional, quien integra el equipo de desarrollo. Contiene la especificacin de los nuevos casos de uso de sistema que han sido implementados en las fases siguientes de desarrollo.

d ) Anlisis Tcnico : elaborado por el Desarrollador o por el Analista Tcnico. 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 / Produccin : 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 produccin.

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 Anlisis Tcnico, tiene la finalidad de verificar que los cambios efectivos al software estn acordes con lo indicado en los diversos documentos de anlisis. Asimismo, contiene los resultados de las pruebas de stress realizadas.

Pgina 31

UPC

g ) Hoja de Atencin 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 sern atendidos por el equipo de Testing. As mismo, contiene los checklists de las diferentes fases de atencin 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 Produccin: 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 produccin est acorde a lo solicitado. Estas plantillas se muestran en el acpite Anexos.

5.1.7. Descripcin del proceso

A continuacin se presenta la descripcin de cada uno de los procedimientos que conforman el nuevo proceso mencionado:

1. Planificar y registrar nuevo requerimiento para atencin 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 debern 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, segn planificacin y alcance del requerimiento. El Responsable de Testing ejecuta todas las actividades que estn relacionadas con las estimaciones de los atributos del producto de trabajo y las tareas del equipo de Testing e identifica los riesgos en la atencin del requerimiento segn la planificacin y el alcance dados.

Verifica que estn completos los documentos que deben ingresar al equipo de Testing como fuente del conocimiento para la atencin del requerimiento:

Pgina 32

UPC

Alcance del requerimiento Anlisis Funcional Anlisis Tcnico Pase a Testing / Produccin

3. Planifica recursos segn la disponibilidad y conocimientos de los miembros El Responsable de Testing atiende todas las tareas relacionadas con la planificacin de los recursos a asignar a la atencin 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 atencin del requerimiento.

4. Ejecuta casos de pruebas y actualiza estadsticas de defectos El Analista de Testing realiza las pruebas efectivas al paquete de cambios entregado por Desarrollo, realizando una planificacin de bateras de pruebas. Previamente se deber haber obtenido una comprensin cabal del requerimiento en tratamiento leyendo exhaustivamente la documentacin 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 documentacin tcnica si fuera el caso, y enviar un nuevo Paquete de Cambios al Analista de Testing.

6. Ejecucin de las pruebas funcionales con el usuario El Analista de Testing verifica con el usuario que los cambios desarrollados y que estn 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 implementacin de los cambios o construcciones elaboradas para atender el requerimiento en curso, registrando dicha informacin en la Hoja de Atencin de Testing.

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

Pgina 33

UPC
El equipo de Testing asegura, a travs de la firma del Acta de Conformidad en Ambiente de Pruebas, que el usuario he verificado que los desarrollos estn correctos y se ajustan a lo indicado en el alcance.

9. Indicar instalacin del paquete de cambios en el ambiente de produccin El Analista de Testing solicita al Soporte Funcional que instale en el ambiente de produccin el paquete de cambios generado por Desarrollo, y que ya ha sido probado y aprobado por Testing.

10. Ejecutar pruebas funcionales y de integracin adicionales El Soporte Funcional ejecuta las ltimas pruebas de funcionales y de integracin para detectar inconsistencias o errores detectados en ltima instancia, previo a la instalacin en el ambiente de produccin. Usualmente aqu se detectan errores o inconsistencias en el documento Pase a Testing / Produccin.

11. Instalar paquete de cambios en ambiente de produccin La persona de Soporte Funcional instala el paquete de cambios en el ambiente de produccin.

12. Pruebas funcionales en ambiente de produccin con el usuario El Analista de Testing realiza las pruebas funcionales de los cambios o desarrollos instalados ya en produccin, atendiendo el requerimiento en tratamiento.

13. Firmar el acta de conformidad en ambiente de produccin El equipo de Testing asegura, a travs de la firma del Acta de Conformidad en Ambiente de Produccin, que el usuario he verificado que los desarrollos estn correctos y se ajustan a lo indicado en el alcance.

14. Enviar solicitud de atencin de errores en produccin a Soporte Funcional El Analista de Testing, en caso encontrara errores despus de haberse instalado el paquete de cambios en produccin, coloca un Registro de Incidente en produccin para dar cuenta al encargado (Soporte Funcional) la atencin de dicho error.

15. Cierra documentacin y avisa cerrar el requerimiento El Analista de Testing cierra la documentacin del requerimiento en caso la funcionalidad solicitada est operando correcta y completamente en el ambiente de produccin, despus de

Pgina 34

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

16. Cierra la atencin del requerimiento El Responsable de Testing cierra la atencin del requerimiento despus de haber constatado que todos los documentos, actas e indicadores del requerimiento hayan sido actualizados.

5.1.8. Flujograma del proceso

Pgina 35

UPC
FLUJOGRAMA DEL NUEVO PROCESO ORGANIZACIONAL GESTION DE CALIDAD DE SOFTWARE DE MINSUR S.A.

Pgina 36

5.1.9. Matriz de Trazabilidad de Procedimientos versus Prcticas Especficas

Procedimiento 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Planificar y registrar nuevo requerimiento para atencin de Testing Estimar tiempos, identifica riesgos, segn planificacin y alcance del requerimiento Planificar recursos segn la disponibilidad y conocimientos de los miembros Ejecutar casos de pruebas y actualiza estadsticas de defectos Corregir defectos y enviar nuevo paquete de cambios Ejecucin de las pruebas funcionales con el usuario Cerrar actividades de Testing en el ambiente de pruebas Firmar el acta de conformidad de los cambios instalados y probados en ambiente de pruebas Indicar instalacin del paquete de cambios en el ambiente de produccin Ejecutar pruebas funcionales y de integracin adicionales Instalar paquete de cambios en ambiente de produccin Pruebas funcionales en ambiente de produccin con el usuario Firmar el acta de conformidad en ambiente de produccin Enviar solicitud de atencin de errores en produccin a Soporte Funcional

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 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

X X X

15 Cierra documentacin y avisa cerrar el requerimiento 16 Cierra la atencin del requerimiento

Pgina 37

5.2.

Planificacin de Proyectos

5.2.1. Situacin problemtica

El rea de Sistemas de TI de Minsur no tiene definido la planificacin de Gestin de Calidad de Software, actualmente este proceso lo realizan aplicando juicio de expertos y de acuerdo a prcticas adquiridas. Los principales inconvenientes y limitaciones que se presentaron se detallan a continuacin.

No tienen definido los roles para la gestin de Calidad Se duplican esfuerzos Brechas entre los requerimientos de usuario y lo desarrollado No se manejan contingencias ante imprevistos y cambios de programacin Pruebas duplicadas con los usuarios No existe programacin para preparar el ambiente de test Problema a Resolver 1. Los analista

Situacin Problemtica No tienen definido los roles para la gestin de Calidad Se duplican esfuerzos

no

tienen

documentado

desconocen el alcance de su rol 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 programacin Pruebas duplicadas con los usuarios

4.

El cronograma no contempla tiempos de holgura que permitan replanificar alguna actividad de de control de calidad.

5.

Los usuarios se quejan porque prueban funciones repetidas veces

No existe programacin para preparar el ambiente de test

6.

Muchas veces el ambiente de testing no se encuentra preparado y las solicitudes estn pendientes de prueba.

Pgina 38

UPC

5.2.2. Flujo del proceso

El nuevo proceso definido para mejorar el desempeo de la organizacin se llama Gestin de Calidad de Software de Minsur. Su orientacin indica que el rea de Sistemas producir entregables de software con un mnimo o cero numero de defectos por requerimiento atendido. A continuacin la descripcin 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 ms que sern los analistas de Testing. Formatos de los procedimientos: 1) Planificar y registrar nuevo requerimiento para atencin de Testing Propsito 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 debern 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 Descripcin de la actividad Adiciona nuevo registro de requerimiento que deber ser atendido por Testing Entregable de salida Hoja de Atencin 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 Herramienta Hoja de clculo Rol Responsable Gestor de Desarrollo y Testing

Pgina 39

UPC
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, segn planificacin y alcance del requerimiento. Propsito Ejecutar todas las actividades que estn relacionadas con las estimaciones de los atributos del producto de trabajo y las tareas, identificacin de los riesgos en la atencin del requerimiento por parte de Testing, segn la planificacin y el alcance. Roles involucrados Responsable de Testing Entregables de Entrada Hoja de Atencin de Testing Actividades Descripcin de la actividad Estimar tiempos, identificar riesgos dentro del rea de Testing, segn la planificacin y el alcance del requerimiento recibido. Entregables de Salida Hoja de Atencin de Testing 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 Herramienta Hoja de clculo Rol Responsable Responsable de Testing

3) Planifica recursos segn la disponibilidad y conocimientos de los miembros Propsito Atender todas las tareas relacionadas con la planificacin de los recursos a asignar a la atencin 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.

Pgina 40

UPC
Roles involucrados Responsable de Testing Entregables de Entrada Hoja de Atencin de Testing Actividades Descripcin de la actividad Planifica recursos segn la disponibilidad y conocimientos de los miembros. Entregables de Salida Hoja de Atencin 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 Herramienta Hoja de clculo Rol Responsable Responsable de Testing

4) Ejecuta casos de pruebas y actualiza estadsticas de defectos Propsito Realizar las pruebas respectivas al paquete de cambios entregado por Desarrollo, realizando una planificacin de bateras de pruebas. Previamente se deber haber obtenido una comprensin cabal del requerimiento en tratamiento. Roles involucrados Analista de Testing Entregables de Entrada Hoja de Atencin de Testing Actividades Descripcin de la actividad Generar ambientes de pruebas Ejecutar los casos de pruebas intensivos Herramienta No aplica No aplica Rol Responsable Analista de Testing Analista de Testing

Documentar los resultados de los casos de pruebas realizados Entregables de Salida Casos de Pruebas de Testing Estadsticas de defectos de desarrollo Trazabilidad

Hoja de clculo

Analista de Testing

Pgina 41

UPC
Project Planning: [SP 2.3] Planificar la gestin de los datos RequirementsPlanning: [SP 1.1] Obtener una comprensin de los requerimientos

5) Corregir defectos y enviar nuevo paquete de cambios. Propsito Obtener un paquete de cambios con los errores reportados por quien corresponda, ya subsanados. Roles involucrados Desarrollador Entregables de Entrada Casos de pruebas de Testing Actividades Descripcin de la actividad Analizar el defecto reportado Realizar las correcciones o construcciones efectivas en el software Realizar los casos de pruebas unitarias No aplica Desarrollador Herramienta No aplica No aplica Rol Responsable Desarrollador Desarrollador

Armar y enviar nuevo paquete de cambios Entregables de Salida Paquete de cambios en el software Trazabilidad RequirementsPlanning:

No aplica

Desarrollador

[SP 1.1] Obtener una comprensin de los requerimientos [SP 1.4] Mantener la trazabilidad bidireccional de los requerimientos

6) Ejecucin de las pruebas funcionales con el usuario Propsito Verificar con el usuario que los cambios desarrollados y que estn siendo probados se ajustan a lo solicitado por el mismo, y que est plasmado en los documentos de alcance del requerimiento.

Pgina 42

UPC
Roles involucrados Analista de Testing Usuario Entregables de Entrada Hoja de Atencin de Testing Paquete de Cambios Actividades Descripcin de la actividad Generar ambientes de pruebas Ejecutar los casos de pruebas Herramienta No aplica No aplica Rol Responsable Analista de Testing Analista de Testing

Documentar los resultados de los casos de pruebas realizados Entregables de Salida Hoja de Atencin de Testing Trazabilidad Project Planning: [SP 2.3] Planificar la gestin de los datos RequirementsPlanning:

Hoja de clculo

Analista de Testing

[SP 1.1] Obtener una comprensin de los requerimientos [SP 1.4] Mantener la trazabilidad bidireccional de los requerimientos

7) Cerrar actividades de Testing en el ambiente de pruebas Propsito Dar por concluidas las pruebas realizadas a la implementacin de los cambios o desarrollos implementados para atender el requerimiento en curso, registrando dicha informacin en la Hoja de Atencin de Testing. Roles involucrados Analista de Testing

Entregables de Entrada Hoja de Atencin de Testing Actividades Descripcin de la actividad Registrar las actividades de cierre de testing en el ambiente de pruebas Entregables de Salida Herramienta Hoja de clculo Rol Responsable Analista de Testing

Pgina 43

UPC
Hoja de Atencin de Testing Trazabilidad RequirementsPlanning: [SP 1.1] Obtener una comprensin de los requerimientos [SP 1.3] Gestionar los cambios de los requerimientos [SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos

8) Firmar el acta de conformidad de los cambios instalados y probados en ambiente de pruebas Propsito Asegurar, a travs de la firma del Acta de Conformidad en Ambiente de Pruebas, que el usuario ha verificado que los desarrollos estn correctos y se ajustan a lo indicado en el alcance. Roles involucrados Usuario Analista de Testing

Entregables de Entrada Acta de Conformidad en Ambiente de Pruebas (sin firmar) Actividades Descripcin de la actividad Firmar el acta de conformidad de los cambios instalados y probados en ambiente de pruebas Entregables de Salida Acta de Conformidad en Ambiente de Pruebas (firmada por el usuario) Trazabilidad RequirementsPlanning: [SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos Herramienta Formato impreso Rol Responsable Usuario

9) Indicar instalacin del paquete de cambios en el ambiente de produccin Propsito 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 produccin. Roles involucrados Analista de Testing

Pgina 44

UPC
Soporte Funcional

Entregables de Entrada Casos de pruebas de testing Acta de Conformidad en Ambiente de Pruebas firmada Actividades Descripcin de la actividad Solicitar instalacin del paquete de cambios en el ambiente de produccin Entregables de Salida Hoja de Atencin de Testing Trazabilidad RequirementsPlanning: [SP 1.3] Gestionar los cambios de los requerimientos [SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos Herramienta Correo electrnico Rol Responsable Analista de Testing

10) Ejecutar pruebas funcionales y de integracin adicionales Propsito Se ejecutan las ltimas pruebas de funcionales y de integracin por parte de la persona con el rol Soporte Funcional para detectar inconsistencias o errores, previo a la instalacin en el ambiente de produccin. Roles involucrados Soporte Funcional

Entregables de Entrada Toda la documentacin que est generando el requerimiento Actividades Descripcin de la actividad Ejecutarlas pruebas funcionales y de integracin adicionales Entregables de Salida Correo electrnico dirigido al Analista de Testing indicando pruebas exitosas Casos de prueba de Soporte Funcional Trazabilidad RequirementsPlanning: [SP 1.3] Gestionar los cambios de los requerimientos [SP 1.4] Mantener la trazabilidad bidireccional de los requerimientos [SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos Herramienta No aplica Rol Responsable Soporte Funcional

Pgina 45

UPC

11) Instalar paquete de cambios en ambiente de produccin Propsito Se instala el paquete de cambios en el ambiente de produccin. Roles involucrados Soporte Funcional

Entregables de Entrada Casos de prueba de Soporte Funcional Actividades Descripcin de la actividad Instalar paquete de cambios en ambiente de produccin Entregables de Salida Correo electrnico dirigido al Analista de Testing indicando que el paquete de cambios ha sido instalado en produccin. Trazabilidad RequirementsPlanning: [SP 1.2] Obtener el compromiso sobre los requerimientos [SP 1.3] Gestionar los cambios de los requerimientos Herramienta No aplica Rol Responsable Soporte Funcional

12) Pruebas funcionales en ambiente de produccin con el usuario Propsito Se realiza las pruebas funcionales de los cambios o desarrollos instalados ya en produccin, atendiendo el requerimiento en tratamiento. Roles involucrados Analista de Testing Usuario

Entregables de Entrada Paquete de cambios instalado en el ambiente de produccin Casos de prueba de Soporte Funcional Actividades Descripcin de la actividad Se ejecutan las pruebas funcionales en el ambiente de produccin con el usuario Herramienta No aplica Rol Responsable Analista de Testing

Pgina 46

UPC
Entregables de Salida Hoja de Atencin de Testing Trazabilidad RequirementsPlanning: [SP 1.3] Gestionar los cambios de los requerimientos [SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos

13) Firmar el acta de conformidad en ambiente de produccin Propsito Asegurar, a travs de la firma del Acta de Conformidad en Ambiente de Produccin, que el usuario ha verificado que los desarrollos estn correctos y se ajustan a lo indicado en el alcance. Roles involucrados Usuario

Entregables de Entrada Acta de Conformidad en Ambiente de Produccin (sin firmar) Actividades Descripcin de la actividad Firmarel acta de conformidad en ambiente de produccin Entregables de Salida Acta de Conformidad en Ambiente de Produccin (firmada) Trazabilidad RequirementsPlanning: [SP 1.3] Gestionar los cambios de los requerimientos [SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos Herramienta No aplica Rol Responsable Usuario

14) Enviar solicitud de atencin de errores en produccin a Soporte Funcional Propsito Al haberse encontrado errores despus de haber instalado el paquete de cambios en produccin, el Analista de Testing coloca un Registro de Incidente en produccin para dar cuenta al encargado (Soporte Funcional) la atencin de dicho error. Roles involucrados Analista de Testing Entregables de Entrada

Pgina 47

UPC
Hoja de Atencin de Testing Paquete de cambios instalado en el ambiente de produccin Actividades Descripcin de la actividad Enviar solicitud de atencin de errores en produccin a Soporte Funcional Entregables de Salida Registro de Incidentes en ambiente de produccin Trazabilidad Project Planning: PP [SP 1.4] : Determinar las estimaciones de esfuerzo y coste Herramienta Hoja de clculo Rol Responsable Analista de Testing

15) Cierra documentacin y avisa cerrar el requerimiento Propsito Si la funcionalidad solicitada con el requerimiento en atencin est funcionando correcta y completamente en el ambiente de produccin, entonces el Analista de Testing cierra la documentacin del mismo, y da aviso al Responsable de Testing el cierre del mismo. Roles involucrados Analista de Testing Entregables de Entrada Hoja de Atencin de Testing Paquete de cambios instalado en el ambiente de produccin Estadsticas actualizadas de Defectos de Desarrollo Acta de Conformidad en Ambiente de Pruebas firmada por el usuario Acta de Conformidad en Ambiente de Produccin firmada por el usuario Actividades Descripcin de la actividad Cierra documentacin y avisa cerrar el requerimiento Entregables de Salida Hoja de Atencin de Testing con indicadores elaborados Trazabilidad RequirementsPlanning: [SP 1.5] Identificar las inconsistencias entre el trabajo del proyecto y los requerimientos Herramienta Hoja de clculo Rol Responsable Analista de Testing

Pgina 48

UPC
16) Cierra la atencin del requerimiento Propsito Si todos los pasos necesarios para probar e instalar en produccin un requerimiento, y verificando que toda la documentacin est actualizada y cerrada, el Responsable de Testing cierra el requerimiento actualizando la Hoja de Atencin de Testing. Roles involucrados Responsable de Testing Entregables de Entrada Hoja de Atencin de Testing Paquete de cambios instalado en el ambiente de produccin Estadsticas actualizadas de Defectos de Desarrollo Acta de Conformidad en Ambiente de Pruebas firmada por el usuario Acta de Conformidad en Ambiente de Produccin firmada por el usuario Actividades Descripcin de la actividad Cerrar la atencin del requerimiento Herramienta Hoja de clculo Rol Responsable Responsable de Testing Entregables de Salida Hoja de Atencin 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.

Gestin de requerimientos

Gestin 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 gestin de requerimientos, hoy en da muy pocas empresas toman en cuenta el proceso de testing, cuya intencin 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. Situacin problemtica

Actualmente, el rea de Sistemas de Minsur S.A. se dedica exclusivamente a la atencin de mltiples requerimientos generados por las reas usuarias, el cual desborda la capacidad de atencin por la falta de personal. Adems, la horizontalidad en el proceso de canalizacin de

Pgina 49

UPC
requerimientos dificulta el adecuado control de los mismos, as como la deficiente gestin hacia su atencin (Anlisis, Diseo, Desarrollo e Implementacin). Actualmente, por la falta de personal en el rea de Sistemas no se realiza el proceso de testing adecuada y completamente.

Situacin Problemtica Canalizacin de requerimientos deficiente

Problema a Resolver 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 priorizacin de requerimientos 6. 7. 8. Dificultad en control de testing 9. 5. Cambios constantes en la priorizacin de los requerimientos. Saturacin de canales de atencin. Incumplimiento de plazos. Deficiente utilizacin de recursos. 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 Gestin de Requerimientos consideramos los siguientes procesos: a. Recepcin y asignacin de desarrollo de requerimiento. b. Registro de la solucin y validacin con el Usuario. c. Puesta en Produccin.

Formatos de los procedimientos: 1. Recepcin y asignacin de desarrollo de requerimiento. Propsito El Responsable de Testing debe coordinar con el Analista de testing la ejecucin de los casos de pruebas y registrar estadsticas de defectos. Esta tarea tiene como propsito el de realizar la recepcin del requerimiento, por parte del Gestor de Desarrollo y Testing, quien deber coordinar con el Responsable de Testing para que

Pgina 50

UPC
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. Entregables de Entrada a. Requerimiento, Alcance y Anlisis Funcional. Criterios de Entrada Se encuentra registrado el requerimiento, el alcance del requerimiento y el anlisis funcional. Entregables de Salida a. Hoja de atencin de testing b. Hoja de control de requerimientos aprobados c. Project de control de proyectos actualizado d. Casos de pruebas de testing e. Estadsticas de pruebas de desarrollo.

Criterios de Salida Finaliza cuando se ha terminado validado el requerimiento con el usuario.

Actividades Descripcin de Actividad Herramienta / Plantilla Rol Responsable

- Gestor de desarrollo y testing solicita al responsable de testing que identifica tiempos y recursos para la atencin del requerimiento. - El responsable de testing planifica recursos de acuerdo a

- Hoja de atencin de testing - Hoja de control de requerimientos aprobados - Project de control de proyectos actualizado

- Gestor de Desarrollo y Testing. - Responsable de Testing Analista de Testing Desarrollador

disponibilidad de recursos. - El analista de testing realiza las pruebas recibido despus una de haber

- Casos de pruebas de testing - Estadsticas de pruebas de desarrollo

notificacin

indicndole que ya puede realizar las pruebas necesarias. - El analista de testing valida y registra posibles errores que

Pgina 51

UPC
existan en el desarrollo. - Si el analista de testing encontrara errores, los registra en las

estadsticas de defectos y solicita la modificacin necesaria al

desarrollador. Trazabilidad REQM ( SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5) .

2. Registro de la solucin y validacin con el Usuario. Propsito Esta tarea tiene como propsito 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. Entregables de Entrada a. Casos de Prueba de Testing, b. Registro de paquete de cambios Criterios de Entrada Se encuentran registrados los casos de Prueba de Testing y paquetes con cambios. Entregables de Salida a. Hoja de Atencin de testing. b. Acta de conformidad en ambiente de pruebas. c. Actualizacin de hoja de atencin de testing. Criterios de Salida Finaliza cuando se ha terminado de realizar las pruebas con el usuario y no existen ms errores y se ha firmado el acta de conformidad en ambiente de pruebas. Actividades Descripcin de Actividad Herramienta / Plantilla Rol Responsable

- El usuario recibe una notificacin

Hoja de Atencin de - Analista de

Pgina 52

UPC
para realizar las pruebas testing. Acta de conformidad en ambiente de pruebas. Hoja de atencin de testing. Testing - Desarrollador

pertinentes al desarrollo. - El usuario ejecuta las pruebas con el Analista de Testing y en caso de encontrar errores solicita las al

modificaciones

necesarias

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. Trazabilidad REQM (SP 1.2, SP 1.3, SP 1.4, SP 1.5)

3. Puesta en Produccin. Propsito Esta tarea tiene como propsito el de realizar los pases de los requerimientos a produccin y realizar la ltima prueba por parte del usuario en produccin y si todo est correctamente, cerrar el requerimiento definitivamente. En caso de existir errores, que deberan ser en menor proporcin se deben de realizar las modificaciones antes de cerrar el requerimiento. Roles involucrados Analista de Testing, Desarrollador, Soporte Funcional. Entregables de Entrada a. Firma de acta de conformidad en ambiente de pruebas. b. Paquete de cambios c. Hoja de atencin de testing. Criterios de Entrada Se encuentra aceptada el acta de conformidad en ambiente de pruebas y se encuentra actualizado el paquete de cambios realizados. Entregables de Salida a. Hoja de atencin de testing de pruebas funcionales

Pgina 53

UPC
b. Acta de conformidad en ambiente de produccin c. Registro de incidencias en ambiente de produccin Criterios de Salida Finaliza cuando se han realizado el transporte a produccin y las pruebas han sido exitosas. Actividades Descripcin de Actividad Herramienta / Plantilla Rol Responsable

- El

Soporte

funcional

realiza

Acta de conformidad en ambiente de produccin. - Analista de Testing

pruebas funcionales adicionales y si encontrara errores, solicita al desarrollador las modificaciones necesarias, previo registro en el registro de incidencias en -

Hoja de atencin de testing. Registro de incidencias en produccin.

- Desarrollador - Soporte Funcional

produccin. - El Soporte Funcional realiza la instalacin cambios. - El analista de testing y el usuario realizan las pruebas finales en ambiente de produccin. En caso de existir errores, estos son del paquete de

registrados en los registros de incidencias en produccin 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 atencin de testing. Trazabilidad REQM (SP 1.1, 1.2, SP 1.3, SP 1.4, SP 1.5)

Pgina 54

UPC

5.4.

Definicin de indicadores de mejora

5.4.1. Propsito y alcance

El Gerente de Sistemas de Minsur S.A. trata de identificar algunas mtricas que de alguna forma le ayuden a mejorar la gestin de este proceso. Las mtricas sern usadas para representar tendencias y realizar diversos anlisis que sirvan para proponer mejoras futuras de funcionamiento y/o tomar acciones correctivas ante algunas desviaciones que se puedan presentar. El anlisis se realizar en base a la informacin que se vaya almacenando, ya que este proceso ser reestructurado totalmente de acuerdo a la propuesta, despus de haber realizado la evaluacin del cumplimiento de las prcticas especficas de REQM.

5.4.2. Objetivo
La generacin de mtricas, deben ser definidas, almacenadas y analizadas. Las mtricas deben ser generadas mensualmente y colocadas en un repositorio indicado por el plan de gestin de datos. El equipo asignado realizara el anlisis comparativo y ser el responsable de detectar desvos e identificar posibles mejoras al proceso.

5.4.3. Mtricas propuestas 5.4.3.1. Cantidad de defectos en Pruebas en ambiente de pruebas

Mtrica 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 estadsticas de defectos en ambiente de pruebas, en un formato estndar y almacenarse en un repositorio indicado en el plan de gestin de datos.

5.4.3.2. Cantidad de defectos en Pruebas funcionales en ambiente de produccin

Mtrica 02: Hace referencia a la cantidad total de defectos encontrados en la etapa de pruebas funcionales en el ambiente de produccin. Esto debe ser registrado por el registro de incidencias en ambiente de produccin en un formato estndar y almacenarse en un repositorio indicado en el plan de gestin de datos.

Pgina 55

UPC

5.4.3.3.

Lneas de cdigo con errores por programa

Mtrica 03: Hace referencia a la cantidad de errores del lneas de cdigo por programa. Esto debe ser registrado por el archivo de estadsticas de defectos en ambiente de pruebas, en un formato estndar y almacenarse en un repositorio indicado en el plan de gestin de datos.

5.4.3.4.

Lneas de cdigo con errores caso de Uso

Mtrica 04: Hace referencia a la cantidad de errores de lneas de cdigo por caso de Uso. Esto debe ser registrado por el archivo de estadsticas de defectos en ambiente de pruebas, en un formato estndar y almacenarse en un repositorio indicado en el plan de gestin de datos.

6. Conclusiones 6.1. Conclusiones respecto a la madurez identificada

Despus de realizar una evaluacin inicial de los procesos que recomienda CMMi en la organizacin Minsur S.A. se puede apreciar resultados que indican que la gestin de los procesos IT est en una etapa caracterizada por un pobre nivel de madurez. La informacin recogida de primera mano a partir de entrevistas a algunos miembros de TI, indican que recin en los ltimos aos, a raz de la implantacin ERP SAP ECC 6.0 se ha tenido que alinear, casi por mandato, muchos de los procesos y procedimientos de atencin del rea de Sistemas, de cara al usuario.

A pesar que siguen habiendo muchos vacos, e improvisaciones, los ltimos 5 aos se ha tomado un raudo camino de mejora en cuanto a establecer ciertos mecanismos de atencin a los usuarios, y evitar sobrecargas o retrabajos en los miembros de los equipos de Sistemas. Esto se manifiesta en el ordenamiento que ha trado 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 estn destacados en las unidades mineras (en el interior del pas).

A pesar del avance logrado, la organizacin 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 improvisacin, sobrecarga de trabajo y hroes las cuales son caractersticas negativas en una organizacin IT. Sin embargo, se aprecia que en el camino recorrido se ha conseguido logros, y

Pgina 56

UPC
definitivamente se debe reconocer que es un buen momento para aplicar el modelo CMMi en el rea de Sistemas de Minsur.

Estas prcticas mejoraran sustancialmente las plataformas informticas y su mantenimiento, lo que conllevar a aprovechar la inversin realizada por la empresa, as como a apoyar y solucionar todo requerimiento de cambio, correccin o desarrollo que requieran los usuarios para el normal desempeo de las actividades de la organizacin.

6.2.

Proceso conveniente para comenzar

Para la implantacin del modelo CMMi en el rea de Sistemas de la organizacin 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 permitira 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 atencin de los requerimientos y asegurar que se brindara la solucin ms ptima, incrementando el porcentaje de calidad.

Indicador de desviacin 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 solucin y aseguramiento de calidad.

6.4.

Otras conclusiones

El presente entregable comprende el diagnstico de las prcticas de desarrollo de software actual para el rea de Sistemas de la compaa minera Minsur S.A. Al revisar los procesos y actividades que se realizan en el rea de TI logramos entender el contexto, prcticas, actividades y logramos

Pgina 57

UPC
identificar qu reas de proceso vamos a evaluar para que se obtenga mejoras de algn proceso de gestin interna.

Para cada punto evaluado hemos tratado de enfocarnos lo ms cercano posible a la realidad, por tanto las calificaciones obtenidas reflejan la situacin actual de la empresa en cuanto a desarrollo de software.

Segn las calificaciones obtenidas tenemos que la empresa seleccionada cumple parcialmente con las prcticas 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 implementacin 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 introduccin de nuevas tecnologas, tcnicas y herramientas de desarrollo.

Pgina 58