Metodología para la Gestión del Conocimiento para PyMES dedicadas al desarrollo de software utilizando el nivel dos de CMMI

Universidad Nacional Andrés Bello

Facultad de Ingeniería Magister en Ingeniería Informática

METODOLOGÍA CON ELEMENTOS DE GESTIÓN DEL CONOCIMIENTO

CAPTURA Y UTILIZACIÓN PARA PyMES DEDICADAS AL DESARROLLO

DE SOFTWARE UTILIZANDO EL NIVEL DOS DE CMMI

Tesis para optar al título de Magister en Ingeniería Informática

AUTOR: JAIME OMAR ANCHAPAXI GARCÍA

PROFESOR GUÍA: MIROSLAV PAVLOVI

Santiago de Chile 2014

DEDICATORIA

Oye, hijo mío, la instrucción de tu padre, y no desprecies la dirección de tu madre; Porque adorno de gracia serán a tu cabeza, Y collares a tu cuello. Proverbios 1: 8-9

A mis padres e hijo;

Jaime, Eva y Gabriel

I

AGRADECIMIENTOS

Te alabaré con todo mi corazón; delante de los dioses te cantaré salmos.

Me postraré hacia tu santo templo, y alabaré tu nombre por tu misericordia y tu fidelidad; porque has engrandecido tu nombre, y tu palabra sobre todas las cosas.

El día que clamé, me respondiste; me fortaleciste con vigor en mi alma Salmo 138: 1-3

Gracias a Dios, por su fidelidad e inmenso amor. A mis padres, Jaime y Eva, A mi hijo, Gabriel, A mi amada compañera, Mónica, A mi Patria el Ecuador, A mi Profesor guía, Miroslav, A mi Pastor, Daniel, A mis profesores y compañeros de la UNAB.

II

ÍNDICE GENERAL DEDICATORIA ................................................................................................................ I AGRADECIMIENTOS ................................................................................................... II ÍNDICE GENERAL........................................................................................................ III RESUMEN................................................................................................................... VIII CAPÍTULO 1 .................................................................................................................... 1 1.1 Introducción .............................................................................................. 1 1.2 Estructura de la tesis.................................................................................. 3 1.3 Objetivos ................................................................................................... 4 1.3.1 Objetivo General ....................................................................................... 4 1.3.2 Objetivos específicos ................................................................................ 4 1.4 Consideraciones iniciales .......................................................................... 5 1.5 Definición del problema............................................................................ 7 1.6 Preguntas de investigación ........................................................................ 8 1.7 Hipótesis del trabajo .................................................................................. 9 1.8 Metodología .............................................................................................. 9 CAPÍTULO 2 .................................................................................................................. 11 2.1. Marco teórico .......................................................................................... 11 2.2. CMMI versión 1.3 ................................................................................... 11 2.2.1. Áreas del modelo CMMI ........................................................................ 12 2.2.2. Representaciones del modelo CMMI ...................................................... 15 2.2.2.1. Representación continua ....................................................................... 15 2.2.2.2. Representación por etapas ..................................................................... 16 2.3. Niveles de madurez ................................................................................. 16 2.3.1. Nivel de madurez 1: Inicial ..................................................................... 17 2.3.2. Nivel de madurez 2: Gestionado ............................................................. 17 2.3.3. Nivel de madurez 3: Definido ................................................................. 18 2.3.4. Nivel de madurez 4: Gestionado cuantitativamente................................ 19 2.3.5. Nivel de madurez 5: Optimizado ............................................................ 19 2.4. Áreas del nivel 2 de CMMI..................................................................... 20 2.4.1. Requerimientos (REQM) ........................................................................ 21 2.4.2. Planificación del proyecto (PP)............................................................... 21 2.4.3. Monitoreo y control del proyecto (PMC) ............................................... 23 2.4.4. Aseguramiento de la calidad del proceso y del producto (PPQA) .......... 24 2.4.5. Gestión de la configuración (CM)........................................................... 25 2.4.6. Medición y análisis (MA) ....................................................................... 26 2.4.7. Gestión de acuerdos con proveedores (SAM) ......................................... 28 2.5. Estándar de evaluación SCAMPI ............................................................ 29 III

2.5.1. Uso de SCAMPI...................................................................................... 30 2.5.2. Clases de evaluación SCAMPI ............................................................... 30 2.5.2.1. SCAMPI Clase C .................................................................................. 30 2.5.2.2. SCAMPI Clase B .................................................................................. 31 2.5.2.3. SCAMPI Clase A .................................................................................. 31 2.5.3. Los participantes de un SCAMPI A ........................................................ 33 2.5.4. Comparación de clases de SCAMPI ....................................................... 35 2.5.5. Fases del método SCAMPI ..................................................................... 36 2.5.6. Los indicadores de implementación de la práctica (PII) ......................... 37 2.5.6.1. La base de datos de indicadores de implementación (PIIDB) .............. 38 2.5.7. Grupo de procesos de ingeniería de software SEPG............................... 38 2.5.8. El conocimiento ...................................................................................... 39 2.5.9. Dato, información y conocimiento .......................................................... 40 2.5.10. Tipos de conocimiento ............................................................................ 41 2.5.10.1. El conocimiento Tácito ....................................................................... 41 2.5.10.2. El conocimiento Explícito .................................................................. 42 2.5.11. Gestión del Conocimiento (GC) ............................................................. 42 2.5.11.1. Ciclo de la gestión de conocimiento................................................. 44 2.5.11.2. Creación del conocimiento. .............................................................. 45 2.5.11.3. Retención de conocimiento .............................................................. 45 2.5.11.3.1. Memoria Organizativa (MO)............................................................ 46 2.5.11.4. Transferencia del Conocimiento ...................................................... 46 2.5.11.5. Utilización del Conocimiento ........................................................... 47 2.6. Modelo SECI........................................................................................... 48 2.6.1. Socialización ........................................................................................... 49 2.6.2. Externalización ........................................................................................ 49 2.6.3. Combinación ........................................................................................... 50 2.6.4. Internalización ......................................................................................... 50 2.7. Relacionando CMMI con gestión del conocimiento ............................... 51 2.8. Las pequeñas y medianas empresas (PyMES) ........................................ 52 CAPÍTULO 3 .................................................................................................................. 56 3.1. Metodología propuesta ............................................................................ 56 3.2. Ciclo de vida de la metodología .............................................................. 59 3.3. Las 7 etapas de la metodología propuesta ............................................... 60 3.3.1. Definición................................................................................................ 60 3.3.2. Evaluación Inicial.................................................................................... 63 3.3.3. Instrucción ............................................................................................... 66 3.3.4. Difusión ................................................................................................... 69 IV

3.3.5. 3.3.6. 3.3.7. 3.4. 3.5.

Utilización ............................................................................................... 73 Evaluación Cuantitativa .......................................................................... 77 Revisión .................................................................................................. 80 Material complementario de la metodología propuesta .......................... 83 Resultados de evaluaciones obtenidos durante el desarrollo de la metodología ............................................................................................. 84 3.5.1. Resultado global de evaluaciones de las áreas de proceso del nivel dos de CMMI. ..................................................................................................... 84 3.5.2. Resultados de la evaluación del área de proceso Gestión de requerimientos ......................................................................................... 86 3.5.3. Resultados de la evaluación del área de proceso Planificación del proyecto ................................................................................................... 88 3.5.4. Resultados de la evaluación del área de proceso Monitoreo y control del proyecto ................................................................................................... 91 3.5.5. Resultados de la evaluación del área de proceso Aseguramiento de la calidad de proceso y producto ................................................................. 93 3.5.6. Resultados de la evaluación del área de proceso Gestión de la configuración........................................................................................... 95 3.5.7. Resultados de la evaluación del área de proceso Medición y análisis .... 98 CONCLUSIONES ........................................................................................................ 100 BIBLIOGRAFÍA .......................................................................................................... 103 ANEXOS ...................................................................................................................... 108

V

Índice de Figuras Figura 1. Historia de CMM ............................................................................................. 12 Figura 2. Estructura de CMMI. ....................................................................................... 14 Figura 3. Niveles de madurez por etapas del modelo CMMI ......................................... 16 Figura 4. Áreas del nivel dos de CMMI .......................................................................... 20 Figura 5. Estructura CMMI-SCAMPI ............................................................................ 29 Figura 6. Campo de aplicación de cada clase de SCAMPI 20 .......................................... 35 Figura 7. División del capital intelectual de una organización ....................................... 43 Figura 8. Ciclo de gestión del conocimiento ................................................................... 45 Figura 9. Modelo SECI, proceso de generación del conocimiento ................................. 48 Figura 10. Las PyMES y el resto de las empresas en Chile ............................................ 53 Figura 12. Actividades de la etapa Definición. ............................................................... 61 Figura 13. Ejemplo de resultado de SCAMPI clase C .................................................... 63 Figura 14. Actividades de la etapa Evaluación Inicial. ................................................... 65 Figura 15. Actividades de la etapa Instrucción ............................................................... 68 Figura 16. PPQA como proceso de control y cumplimiento ........................................... 70 de las etapas de la metodología. ...................................................................................... 70 Figura 17. Actividades de la etapa Difusión .................................................................... 72 Figura 18. CM como repositorio de conocimiento ......................................................... 74 Figura 19. Actividades de la etapa Utilización ............................................................... 76 Figura 20. Ejemplo de evaluación de las prácticas .......................................................... 77 del área de proceso PPQA .............................................................................................. 77 Figura 21. Actividades de la etapa Evaluación cuantitativa ........................................... 79 Figura 22. Actividades de la etapa Revisión ................................................................... 82 Figura 23. Resultado de evaluaciones áreas de procesos ............................................... 85 Figura 24. Resultado de evaluaciones Gestión de requerimientos ................................. 87 Figura 25. Resultado de evaluaciones Gestión de requerimientos ................................. 90 Figura 26. Resultado de evaluaciones Monitoreo y control ............................................ 92 Figura 27. Resultado de evaluaciones Aseguramiento de la calidad ............................. 94 Figura 28. Resultado de evaluaciones Gestión de la configuración ................................ 97 Figura 29. Resultado de evaluaciones Medición y análisis ............................................. 99

VI

Índice de Tablas

Tabla 1. Áreas y niveles de CMMI ................................................................................. 13 Tabla 2. Niveles de representaciones de CMMI ............................................................. 15 Tabla 3. Metas y prácticas específicas de REQM ........................................................... 21 Tabla 4. Metas y prácticas específicas de PP .................................................................. 23 Tabla 5. Metas y prácticas específicas de PMC .............................................................. 24 Tabla 6. Metas y prácticas específicas de PPQA ............................................................ 25 Tabla 7. Metas y prácticas específicas de CM ................................................................ 26 Tabla 8. Metas y prácticas específicas de MA ................................................................ 27 Tabla 9. Metas y prácticas específicas de SAM .............................................................. 28 Tabla 10. Características de los tipos de SCAMPI ......................................................... 35 Tabla 11. Fases y procesos del método SCAMPI ........................................................... 36 Tabla 12. Ciclos de GC propuestos por varios autores ................................................... 44 Tabla 13. Formas de memoria organizativa su Contenido y Uso ................................... 46 Tabla 14.Proceso de conversión de conocimiento (Nonaka y Takeuchi) ....................... 66 Tabla 15. Resultado global de evaluaciones ................................................................... 84 Tabla 16. Resultado de evaluaciones Gestión de requerimientos .................................. 86 Tabla 17. Resultado de evaluaciones Planificación del proyecto .................................. 89 Tabla 18. Resultado de evaluaciones Monitoreo y control ............................................ 91 Tabla 19. Resultado de evaluaciones Aseguramiento de la calidad ................................ 93 Tabla 20. Resultado de evaluaciones Gestión de la configuración ................................. 95 Tabla 21. Resultado de evaluaciones Medición y análisis .............................................. 98

VII

RESUMEN El conocimiento que poseen los miembros de equipos de trabajo han sido creados y adquiridos durante el paso de los años en la realización de procesos de desarrollo de software, estas cualidades constituyen un activo importante para las organizaciones que quieren mejorar sus prácticas y procesos de desarrollo de software.

En empresas que implementen nivel dos de CMMI se puede aprovechar el proceso de implementación del modelo para determinar la manera y el momento en que los procesos de captura y utilización del conocimiento deben llevarse a cabo.

El presente trabajo propone el diseño de una metodología para la captura y utilización del conocimiento con elementos de gestión del conocimiento para PyMES dedicadas al desarrollo de software, el mismo que será desarrollado mediante un estudio de caso con la implementación del nivel dos de CMMI en cuatro PyMES en donde se realizarán actividades de captura y utilización de conocimiento; en el que cada miembro del equipo aportará conocimiento individual tácito, que posteriormente se convertirá en conocimiento organizacional explicito; cada miembro de equipo utilizará el conocimiento organizacional en el desarrollo o mantención de sus productos los mismos que en una etapa posterior serán seleccionados como proyectos pilotos a ser evaluados mediante el método SCAMPI y de esta manera determinar que aprendió la organización y a la vez intervenir en las oportunidades de mejora detectadas.

VIII

CAPÍTULO 1 1.1. Introducción En general en todos los ambientes organizacionales el conocimiento pasa a ser un activo intangible importante, aunque en muchos casos a éste no se lo reconozca, lo cual representa un problema muy frecuente que suele ocurrir cuando las personas que poseen dicho conocimiento se van de la empresa.

Para las empresas que desarrollan software es aún más evidente el gran valor que aportan los activos intangibles, en principio por la misma naturaleza del proceso de producción: la construcción de software es una actividad cognitiva y fuertemente dependiente del conocimiento.

De esta manera, (Falbo R. et al. 2005), exponen que en el contexto preciso del desarrollo software, la Gestión del Conocimiento puede usarse para gestionar los conocimientos y la experiencia generados durante los procesos software y consideran que si bien cada proyecto es, en cierto sentido, único, experiencias similares pueden ayudar a los desarrolladores en la realización de sus actividades.

El desarrollo de software es una tarea realizada por grupos de personas donde el trabajo en equipo es vital para cumplir con los proyectos; para lograrlo adecuadamente deben existir objetivos claramente definidos, comunicación efectiva, que conduzca generar conocimiento explícito que pueden ser templates, reportes de trabajo, formatos, entre otros y el conocimiento tácito o implícito que es aquel que está en la mente de las personas y en la experiencia, se hace necesario desarrollar, asegurar, distribuir y combinar todo este conocimiento (Jorge Quiroga, 2007).

1

En lo referente a la Gestión del Conocimiento, que en adelante será mencionada como GC, se lo define según (Gupta y Sharma, 2004), GC es la colección de procesos que gobiernan la creación, diseminación, y utilización de conocimiento.

La definición que proporcionan (Quintas P. et al. 1997), sostienen que la GC es cualquier proceso o práctica para crear, adquirir, capturar, compartir y usar conocimiento, cualquiera sea el lugar donde resida, para mejorar el aprendizaje y el desempeño en las organizaciones.

Por su parte, (Handzic M, 2003), sostiene que el principal propósito de la GC es asegurar que las personas correctas tengan el conocimiento correcto en el momento adecuado.

2

1.2. Estructura de la tesis

La estructura del presente trabajo consta de 3 capítulos distribuidos de la siguiente manera:

En el capítulo 1, se desarrolla la introducción general sobre el contenido que se encuentra enmarcado el presente trabajo, la problemática presentada, el objetivo principal y los específicos, las preguntas de investigación y la hipótesis formulada.

En el capítulo 2, se encuentra el marco teórico, principales conceptos de las áreas, representaciones del modelo CMMI, para esta tesis se ha trabajado con la representación por etapas, niveles de CMMI versión Development. 1.3, y específicamente enfocándose al nivel dos del modelo; se aborda además el método de evaluación SCAMPI, se describe lo que es un Grupo de Ingeniería de Procesos de Software (SEPG), el capítulo continua con la temática relacionada al conocimiento y sus tipos, la gestión del conocimiento (GC), el modelo SECI que será la referencia para la trasformación del conocimiento y el desarrollo de la metodología del presente trabajo, finalmente se aborda lo referente a las PyMES. En el capítulo 3, presenta el resultado de la investigación describiendo la metodología desarrollada para gestionar el conocimiento, que ha sido realizada con base en el proceso de implementación del nivel dos de CMMI; la metodología planteada tiene un ciclo de vida compuesto por siete etapas que abarcan procesos de captura, transformación, generación y utilización del conocimiento.

Al final del documento se detallan las conclusiones más importantes que el autor del presente trabajo destaca luego de esta experiencia y se agrupan algunos anexos que han sido aporte para la elaboración de la tesis, los cuales serán de gran ayuda para entender de mejor manera lo expuesto.

3

1.3 Objetivos

1.3.1

Objetivo General

Utilizar el proceso de implementación del nivel dos de CMMI, como herramienta de captura y utilización del conocimiento tácito que se maneja en procesos de desarrollo de software en PyMES dedicadas a dicha actividad, para proponer una metodología para la captura y utilización del conocimiento con elementos de gestión del conocimiento.

1.3.2

Objetivos específicos

1. Realizar la evaluación SCAMPI clase C para conocer el estado actual de los procesos de desarrollo de software en las empresas, y fijar el punto de partida. 2. Identificar a personal que posiblemente sea poseedor de conocimiento tácito. 3. Instruir o enseñar a la organización conforme a las áreas, objetivos y prácticas del nivel dos de CMMI.

4. Elaborar propuestas para capturar el conocimiento tácito individual. 5. Establecer actividades y procedimientos para almacenar el conocimiento capturado. 6. Establecer actividades para transformar el conocimiento individual tácito a conocimiento organizacional explícito. 7. Utilizar el conocimiento que ha sido analizado y considerado contribución importante en la mejorara de las prácticas y procesos de desarrollo de software. 8. Realizar evaluaciones SCAMPI clases B para detectar oportunidades de mejora y medir el progreso de transformación del conocimiento. 9. Entregar retroalimentación para mejorar las prácticas, procesos de desarrollo de software y gestión del conocimiento. 10. Desarrollar metodología para la GC en equipos de desarrollo de software. 11. Validar las hipótesis planteadas.

4

1.4. Consideraciones iniciales En el mundo existe una creciente preocupación por otorgar cada vez más importancia al conocimiento en las organizaciones dándole un valor importante como activo, teniendo en cuenta las nuevas tecnologías de la información y la comunicación, que acompañan a la sociedad de la información y del conocimiento, las cuales están transformando las economías, los mercados y la estructura de la industria, los productos y servicios, los puestos de trabajo y los mercados laborales (Peter Drucker, 1969).

El valor de la riqueza de una organización se centra cada vez más en sus activos intangibles; su gente, el know-how, las marcas, patentes, licencias, relaciones con los clientes, etc. El conocimiento puede tener un precio premium en el mercado que puede aumentar el valor (y por tanto el precio) de los productos y servicios (David Skyrme, 1997).

En el caso de las empresas que desarrollan software según menciona (Yunwen Ye, 2006), es aún más evidente el gran valor que aportan los activos intangibles, en principio por la misma naturaleza del proceso de producción; el desarrollo de software es una actividad cognitiva que requiere de varios dominios diferentes, incluyendo tanto el dominio de la informática y de aplicación, dadas las limitaciones de la memoria humana, la capacidad de aprendizaje y el tiempo dedicado al aprendizaje, pocos desarrolladores tienen todos los conocimientos necesarios en sus propias cabezas.

La ingeniería de software entre otras cosas se ocupa de teorías, métodos y herramientas necesarias para desarrollar software y no de materiales regidos por leyes físicas o por procesos de manufactura. El conocimiento está implícito todo el tiempo en la naturaleza de los procesos y resultados, debido a que el software está compuesto, de manera simplificada, de ideas plasmadas en código, es intangible. (Ian Sommerville, 2007).

5

A continuación se describen varias características del desarrollo de software que resaltan la relación existente con el conocimiento, y por ende la importancia que gestionarlo, para lo cual se ha utilizado lo expuesto por (Dingsoeyr y Conradi, 2002) en “Use of Knowledge Management in Software Engineering” y también se consideró lo expuesto por (Yunwen Ye, 2006) “Supporting Software Development as Knowledge-Intensive and Collaborative Activity”.

1. El conocimiento que se utiliza para construir una aplicación está distribuido entre el desarrollador y el mundo exterior y es necesario aprender a integrar diferentes fuentes de conocimiento para lograr desarrollar la solución (abstracción). 2. El proceso de desarrollo es una conversación continua entre las mentes humanas y la construcción que se va logrando (es un proceso cíclico). 3. El proceso de desarrollo se distribuye a lo largo de un grupo social (incluso a través de barreras geográficas) y a lo largo del tiempo. 4. En el proceso de desarrollo el conocimiento está distribuido en todo el grupo en la medida en que cada desarrollador aporta un poco al grupo para complementar el conocimiento. 5. El conocimiento que un desarrollador genera, por ejemplo al resolver un problema específico, no se dispersa a otros desarrolladores u otros grupos, haciendo que el mismo problema se resuelva una y otra vez desde el comienzo y que se repitan los mismos errores, provocando pérdida de tiempo y recursos en la elaboración de nuevos sistemas 6. Las decisiones que se toman en la etapa de diseño no se registran de manera formal y explícita argumentando con justificaciones claras y concisas. 7. Las decisiones que se toman en la etapa de diseño no se relacionan con los diferentes artefactos generados durante esta etapa (diagramas de diseño, diagramas de clase, casos de uso, diagramas de secuencia, entre otros).

6

Es necesario recalcar que no sólo es el proceso de desarrollo de software el qué depende fuertemente del conocimiento, es también la organización como tal, en dicha virtud es necesario que las PyMES que desarrollan software reconozcan que el conocimiento es su ventaja competitiva y que es la base para la innovación, es por lo tanto uno de sus más valiosos activos.

En el desarrollo de software las personas han sido reconocidas como los poseedores claves de conocimiento valioso y, por lo tanto para (Meliha Handzic, 2003); identificar, localizar y capturar lo que es conocido por los individuos y grupos de desarrolladores de software es de importancia crítica para la sobrevivencia en el negocio del software.

1.5. Definición del problema Con base en los contextos y numerales anteriores (Ítem 1.4. Consideraciones iniciales), se muestran a continuación los principales problemas que se presentan en PyMES dedicadas al desarrollo de software:

a) Inconvenientes al gestionar el conocimiento debido a que dichas organizaciones se dedican a desarrollar software mas no a documentar información por resultar un proceso tedioso. b) Los equipos de trabajo tienen alto porcentaje de poseer conocimiento tácito (numerales 1,2,4) c) Toma de decisiones a juicio de experto sin el análisis adecuado y pérdida de tiempo al no poder reutilizar material de trabajos anteriores (numerales 6,7) d) Existe casos en los cuales se vive una cultura de ocultación de errores e información (numerales 5,3).

El desarrollo de software depende del conocimiento y la creatividad de los individuos que lo realizan; es por eso que situaciones como las descritas podrían llevar al uso inadecuado

7

del talento humano y su conocimiento, afectando de esta manera a las decisiones que se toman en las organizaciones, pérdida de tiempo, pérdidas económicas, perdidas de información e incorrecto uso de recursos en la elaboración de nuevos sistemas.

Utilizar el proceso de implementación de CMMI (Capabbility Maturity Model Integration), en el cual se realizan prácticas de ingeniería de sistemas e ingeniería de software, enfocadas en la capacidad de una organización para desarrollar productos y servicios de alta calidad de manera consistente y predecible, proporcionando una ruta evolutiva para cambiar los procesos improvisados e inmaduros a procesos maduros y disciplinados que permitan una mejor calidad y efectividad.

La implementación de un modelo de mejora de procesos ayuda a que los procesos sean óptimos y repetibles en el desarrollo de software, esto implica un cambio en la forma de pensar y trabajar de los equipos de trabajo. (Patricia Forradellas, 2006).

Por lo expuesto en los contextos anteriores se infiere que en el proceso de implementación de CMMI se realizan

actividades que vinculan el desarrollo de software con el

conocimiento.

Considerando que el conocimiento es un activo importante para las empresas dedicadas al desarrollo de software, se propone utilizar los procesos de implementación de CMMI para elaborar una metodología para la gestión del conocimiento. 1.6. Preguntas de investigación Fundamentado en las consideraciones anteriores, las preguntas de investigación se han planteado según lo enunciado a continuación: ¿Cuál es la relación que existe entre gestión del conocimiento y la implementación de CMMI en PyMES dedicadas al desarrollo de software?

8

¿Cómo pueden ser utilizadas las prácticas o procesos del nivel dos de CMMI para realizar gestión del conocimiento? ¿De qué manera pueden beneficiarse las PyMES al utilizar las prácticas con las cuales cuenta el nivel 2 de CMMI, para capturar y utilizar conocimiento adquirido con la experiencia?

1.7. Hipótesis del trabajo H1. En una organización que implemente el nivel dos de CMMI apoyados en la teoría de gestión del conocimiento se logrará utilizar el proceso de implementación para elaborar o establecer una metodología para la captura y utilización del conocimiento con elementos de gestión del conocimiento.

H2. Al establecer procedimientos para la captura y utilización del conocimiento, se mejorará el proceso de desarrollo de software en PyMES.

1.8. Metodología El tipo de investigación que se efectuará en este trabajo es cuantitativa de tipo experimental, ya que se realizará una investigación de campo en 4 PyMES las cuales implementarán CMMI nivel dos.

Para esto se llevará a cabo reuniones en las empresas para trabajar en la implementación del modelo, de donde se extraerá el conocimiento individual tácito que servirá de ayuda para proponer actividades de almacenamiento y captura del conocimiento.

Posteriormente el conocimiento ya capturado se convierte en conocimiento organizacional explícito, el cual está expuesto para su utilización.

9

Consecuentemente cada miembro de equipo utilizará el conocimiento organizacional en la ejecución de proyectos pilotos, para los cuales se ejecutarán evaluaciones SCAMPI

1

clase B, para saber que aprendió la organización y medir la transformación del conocimiento tácito a organizacional en PyMES, determinando fortalezas y oportunidades de mejora para la gestión del conocimiento y los procesos de desarrollo de software.

Con ayuda de la teoría de gestión del conocimiento, se logrará determinar cuáles prácticas son fundamentales y porque son fundamentales, para proponer una metodología de captura y utilización del conocimiento organizacional.

Finalmente se realizarán revisiones y ajustes a los procesos conforme a los resultados de la evaluación SCAMPI clase B determinando que aprendió la organización.

Por lo expuesto en lo anterior, se considerarán los siguientes tipos de variables:

Variables independientes (áreas del nivel dos de CMMI) 1. Gestión de Requisitos (REQM) 2. Planificación del Proyecto (PP) 3. Monitorización y Control del Proyecto (PMC) 4. Aseguramiento de la Calidad del Proceso y del Producto (PPQA) 5. Gestión de Configuración (CM)

Variables dependientes 1. Creación del conocimiento (SECI) 2 2. Utilización del conocimiento 1 SCAMPI (Standard CMMI Appraisal Method for Process Improvement), evaluación que determina el nivel de madurez o capacidad, que ha alcanzado una organización que aplica CMMI en sus procesos. 2 Modelo sociológico (Socialización, Externalización, Combinación, Internalización) de Nonaka y Takeuchi (1994)

10

CAPÍTULO 2 2.1. Marco teórico El marco teórico que se desarrolla a continuación, permitirá conocer los conceptos necesarios para el entendimiento del desarrollo de esta tesis.

2.2. CMMI versión 1.3 Según el SEI 3, 2010, el modelo CMMI Capability Maturity Model Integration (CMMI para Desarrollo, Versión 1.3, 2010), es una colección de buenas prácticas de desarrollo que centran en actividades para desarrollar productos y servicios de calidad con el fin de cumplir las necesidades de clientes y usuarios finales, y a la vez para alcanzar determinado nivel de madurez de la propia organización o de determinadas áreas de procesos. Está formado por 5 niveles de manera escalonada, empezando por el uno (Inicial), lugar en el cual se encuentran todas las organizaciones en el momento inicial de alcanzar la madurez, donde los procesos son impredecibles, poco controlados y reactivos. En el caso del nivel dos (Gestionado) la organización tiene procesos aplicables en proyectos y es frecuentemente reactivo. El nivel 3 (Definido) presenta un proceso aplicable a toda la organización y reacciona anticipadamente. En el nivel 4 (Gestionado cuantitativamente) los procesos de la organización son predecibles y controlados cuantitativamente. Finalmente en el nivel 5 (Optimización) la organización se enfoca en la mejora del proceso.

3

SEI: Software Engineer Institute

11

Figura 1. Historia de CMM 4

Inicialmente CMMI fue un modelo que combinó tres fuentes de modelo: Capability Maturity Model for Software (SW-CMM) v2.0 draft C, the Systems Engineering Capability Model (SECM) [EIA 2002a], y,

the Integrated Product Development

Capability Maturity Model (IPD-CMM) v0.98. 5

2.2.1. Áreas del modelo CMMI CMMI presenta áreas de procesos en las cuales se va enfocando cada nivel de madurez. Estas áreas se fragmentan de acuerdo con cuatro categorías: Ingeniería, Gestión de proyecto, Gestión de Proceso y Soporte, como se muestra en Tabla 1.

4 EIA 731 SECM is the Electronic Industries Alliance standard 731, or the Systems Engineering Capability Model. INCOSE SECAM is International Council on Systems Engineering Systems Engineering Capability Assessment Model [EIA 2002a]. 5 CMMI® for Development, Version 1.3

12

Nivel de Área de Proceso

Categoría

Gestión de Configuración (CM)

Soporte

Medición y Análisis (MA )

Soporte

Monitorización y Control del Proyecto (PMC)

Gestión de proyectos

Planificación del Proyecto (PP)

Gestión de proyectos

Madurez

2

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

Soporte

Gestión de Requisitos (REQM)

Gestión de proyectos

Gestión de Acuerdos con Proveedores (SAM )

Gestión de proyectos

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

Soporte

Gestión Integrada del Proyecto (IPM)

Gestión de proyectos

Definición de Procesos de la Organización (OPD) Enfoque en Procesos de la Organización (OPF)

Gestión de procesos Gestión de procesos

Formación en la Organización (OT )

Gestión de procesos

Integración del Producto (PI)

Ingeniería

Desarrollo de Requisitos (RD)

Ingeniería

Gestión de Riesgos (RSKM)

Gestión de proyectos

Solución Técnica (TS)

Ingeniería

Validación (VAL )

Ingeniería

Verificación (VER)

Ingeniería

Rendimiento de Procesos de la Organización (OPP)

Gestión de procesos

Gestión Cuantitativa del Proyecto (QPM)

Gestión de proyectos

Análisis Causal y Resolución (CAR )

Soporte

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

Gestión de procesos

3

4

5

Tabla 1. Áreas y niveles de CMMI 6

6

Fuente: Elaboración propia

13

Cada área de proceso de CMMI se divide en objetivos específicos (SG) y objetivos genéricos (GG). A su vez, cada objetivo específico se divide en prácticas específicas y cada objetivo genérico en prácticas genéricas, como se muestra en el siguiente gráfico.

Figura 2. Estructura de CMMI. 7

Los objetivos genéricos son llamados así porque un mismo objetivo puede adaptarse a varias áreas de procesos. Estos objetivos describen las características que debe tener la implementación de los procesos para que estos sean institucionalizados.

Las prácticas genéricas son actividades que aseguran que los procesos asociados con las áreas de procesos sean efectivos, repetibles y durables.

Un objetivo específico describe las características únicas que deben estar presentes para satisfacer el área del proceso.

Una práctica específica es la descripción de una actividad que es considerada importante en el logro del objetivo específico asociado. Las prácticas específicas describen las actividades que son esperadas que resulten en aras del logro de los objetivos específicos del área de proceso.

7

Fuente: CMMI® para Desarrollo, Versión 1.3

14

2.2.2. Representaciones del modelo CMMI

El modelo tiene dos formas para ayudar a la organización a mejorar. Una forma es lograr mejora en un proceso específico o un conjunto de ellos usando la Representación Continua (Continuous Representation) y la otra es la mejora de oda la organización según los procesos definidos usando la Representación Escalonada o por Etapas (Staged Representation). En la tabla 2 se muestran las dos representaciones:

Tabla 2. Niveles de representaciones de CMMI 8

2.2.2.1. Representación continua La representación continua, implica que por cada área de proceso se encuentran definidas metas objetivas, esto puede determinar el volumen o dimensión de los procesos, es decir lo que se debe llevar a cabo como proceso y tarea. Así mismo dentro de la representación continua, permite a una organización la selección de una o más áreas de proceso para su mejoramiento. El progreso en la mejora se mide en términos de niveles de capacidad para cada área de proceso seleccionada, progresando desde un nivel incompleto a uno optimizado a través de la satisfacción de un conjunto definido de prácticas

8

Fuente: Mary Beth Chrissis, Mike Konrad, Sandy Shrum. CMMI® for Development, v1.2, 2006.

15

2.2.2.2. Representación por etapas[MP1] La representación escalonada o por etapas, muestra un enfoque estructurado para el mejoramiento de los procesos paso a paso. Es decir que la pasar por cada etapa, nos asegura que se ha mejorado la anterior y que puede continuarse con la siguiente, permitiendo a una organización seleccionar un conjunto predefinido de áreas de proceso y utiliza niveles de madurez para caracterizar la mejora de procesos. Los procesos avanzan por cinco niveles de madurez, desde el inicial al optimizado.

Para el desarrollo de la metodología, tema del presente trabajo se lo realizó bajo esta representación, ya que las empresas en las cuales se trabajó así lo decidieron.

2.3. Niveles de madurez

A continuación se muestra en la Figura 3 los niveles de madurez, los niveles son una meseta evolutiva definida para la mejora de procesos de la organización. Los niveles de madurez se miden mediante el logro de metas específicas y genéricas asociadas a cada conjunto predefinido de áreas de proceso.

Figura 3. Niveles de madurez por etapas del modelo CMMI 9 9

Fuente: http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf

16

2.3.1. Nivel de madurez 1: Inicial En el nivel de madurez 1, los procesos son generalmente ad hoc (solo para un determinado propósito) y caóticos. La organización generalmente no proporciona un entorno estable para dar soporte a los procesos. El éxito en estas organizaciones depende de la competencia y la heroicidad del personal de la organización y no del uso de procesos probados. A pesar de este caos, las organizaciones de nivel de madurez 1 a menudo producen productos y servicios que funcionan pero, sin embargo, exceden con frecuencia el presupuesto y los plazos planificados.

Las organizaciones de nivel de madurez 1 se caracterizan por una tendencia a comprometerse en exceso, a abandonar sus procesos en momentos de crisis y a no ser capaces de repetir sus éxitos.

2.3.2. Nivel de madurez 2: Gestionado En el nivel de madurez 2, se garantiza que en los proyectos los procesos se planifican y ejecutan de acuerdo con las políticas; los proyectos emplean personal cualificado que dispone de recursos adecuados para producir resultados controlados; se involucra a las partes interesadas relevantes; se monitorizan, controlan y revisan; y se evalúan en cuanto a la adherencia a sus descripciones de proceso. La disciplina de proceso reflejada por el nivel de madurez 2 ayuda a asegurar que las prácticas existentes se mantienen durante periodos bajo presión. Cuando estas prácticas están desplegadas, los proyectos se realizan y gestionan de acuerdo a sus planes documentados.

También en el nivel de madurez 2, el estado de los productos de trabajo es visible para la dirección en puntos definidos, por ejemplo en los hitos principales y al finalizar las tareas principales. Se establecen compromisos entre las partes interesadas relevantes y se modifican, según sea necesario. Los productos de trabajo se controlan de forma apropiada.

17

Los productos de trabajo y servicios satisfacen sus descripciones de proceso, estándares y procedimientos especificados.

2.3.3. Nivel de madurez 3: Definido En el nivel de madurez 3, los procesos están bien caracterizados y comprendidos, y se describen en estándares, procedimientos, herramientas y métodos. El conjunto de procesos estándar de la organización, que es la base del nivel de madurez 3, se establece y se mejora a lo largo del tiempo. Estos procesos estándar se utilizan para establecer la integridad en toda la organización. Los proyectos establecen sus procesos definidos adaptando el conjunto de procesos estándar de la organización de acuerdo a las guías de adaptación Una diferencia crítica entre los niveles de madurez 2 y 3 es el alcance de los estándares, descripciones de proceso y procedimientos.

En el nivel de madurez 2, los estándares, descripciones de proceso y procedimientos pueden ser bastante diferentes en cada instancia específica del proceso, porque cada proyecto puede definir sus procesos. En el nivel de madurez 3, los estándares, descripciones de proceso y procedimientos para un proyecto se adaptan a partir del conjunto de procesos estándar de la organización para adecuarse a un proyecto particular o unidad organizativa y, por tanto, son más consistentes, exceptuando las diferencias permitidas por las guías de adaptación.

En el nivel de madurez 3 la organización mejora, aún más, sus procesos relacionados con las áreas de proceso del nivel de madurez 2. Para lograr el nivel de madurez 3, se aplican las prácticas genéricas asociadas con la meta genérica 3 que no fueron tratadas en el nivel de madurez 2.

18

2.3.4. Nivel de madurez 4: Gestionado cuantitativamente En el nivel de madurez 4, la organización y los proyectos establecen objetivos cuantitativos para la calidad y el rendimiento del proceso, y los utilizan como criterios en la gestión de los proyectos. Los objetivos cuantitativos se basan en las necesidades del cliente, usuarios finales, organización e implementadores del proceso. La calidad y el rendimiento del proceso se interpretan en términos estadísticos y se gestionan durante la vida de los proyectos.

Para los subprocesos seleccionados, se recogen y se analizan estadísticamente medidas específicas del proceso. Cuando se seleccionan subprocesos para su análisis, es crítico comprender las relaciones entre diferentes subprocesos y su impacto en la consecución de los objetivos de calidad y de rendimiento del proceso. Este enfoque ayuda a asegurar que la monitorización de subprocesos usando técnicas estadísticas y otras técnicas cuantitativas se aplica donde tiene más valor global para el negocio. Las líneas base y los modelos de rendimiento del proceso pueden usarse para ayudar a establecer los objetivos de calidad y de rendimiento del proceso que ayuden a lograr los objetivos de negocio.

Una diferencia crítica entre los niveles de madurez 3 y 4 es la predictibilidad del rendimiento del proceso. En el nivel de madurez 4, el rendimiento de los proyectos y de los subprocesos seleccionados se controla utilizando técnicas estadísticas y otras técnicas cuantitativas, y las predicciones se basan, en parte, en el análisis estadístico de los datos detallados de proceso.

2.3.5. Nivel de madurez 5: Optimizado En el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en una comprensión cuantitativa de sus objetivos de negocio y necesidades de

19

rendimiento. La organización utiliza un enfoque cuantitativo para comprender la variación inherente en el proceso y las causas de los resultados del proceso.

El nivel de madurez 5 se centra en mejorar continuamente el rendimiento de los procesos mediante mejoras incrementales e innovadoras de proceso y de tecnología. Los objetivos de calidad y de rendimiento del proceso de la organización se establecen, se modifican continuamente para reflejar cambios en los objetivos del negocio y en el rendimiento de la organización, y se utilizan como criterios para gestionar la mejora de procesos. Los efectos de las mejoras de procesos desplegadas se miden utilizando técnicas estadísticas y otras técnicas cuantitativas, y se comparan con los objetivos de calidad y de rendimiento del proceso. Los procesos definidos del proyecto, el conjunto de procesos estándar de la organización y la tecnología de soporte, son objeto de actividades de mejora medibles. 2.4. Áreas del nivel 2 de CMMI La figura 4, muestra las siete áreas del nivel de madurez dos del modelo CMMI.

Figura 4. Áreas del nivel dos de CMMI 10

10

Fuente: http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf

20

2.4.1. Requerimientos (REQM) El propósito de la Gestión de Requisitos (REQM) es gestionar los requerimientos de los productos y los componentes de producto del proyecto, y asegurar la alineación entre esos requerimientos, y los planes y los productos de trabajo del proyecto.

SG 1 Gestionar los requerimiento SP 1.1 Comprender los requisitos SP 1.2 Obtener el compromiso sobre los requisitos SP 1.3 Gestionar los cambios a los requisitos SP 1.4 Mantener la trazabilidad bidireccional a los requisitos Asegurar el alineamiento entre el trabajo del proyecto y SP 1.5 los requisitos Tabla 3. Metas y prácticas específicas de REQM 11

2.4.2. Planificación del proyecto (PP) El propósito de la Planificación del Proyecto (PP) es establecer y mantener planes que definan las actividades del proyecto.

Una de las claves para gestionar eficazmente un proyecto es la planificación del proyecto. El área de proceso Planificación del Proyecto implica las siguientes actividades:

11

•

Desarrollar el plan de proyecto.

•

Interactuar de forma apropiada con las partes interesadas relevantes.

•

Obtener el compromiso con el plan.

•

Mantener el plan.

Fuente: SEI; CMMI® para Desarrollo, Versión 1.3, 2010

21

La planificación incluye la estimación de los atributos de los productos de trabajo y de las tareas, la determinación de los recursos necesarios, la negociación de los compromisos, la elaboración de un calendario, y la identificación y el análisis de los riesgos del proyecto.

Para establecer el plan de proyecto, puede ser necesario realizar iteraciones de estas actividades. El plan de proyecto proporciona la base para realizar y controlar las actividades del proyecto que abordan los compromisos con el cliente del proyecto.

El plan de proyecto se modifica generalmente a medida que el proyecto progresa, para abordar los cambios en los requisitos y en los compromisos, las estimaciones inexactas, las acciones correctivas y los cambios a los procesos. Esta área de proceso contiene las prácticas específicas que describen tanto la planificación como la re planificación.

SG 1 Establecer las estimaciones SP 1.1

Estimar el alcance del proyecto. Establecer las estimaciones de los atributos de los

SP 1.2

productos de trabajo y de las tareas

SP 1.3

Definir las fases del ciclo de vida del proyecto.

SP 1.4

Estimar esfuerzo y costo

SG 2 Desarrollar un plan de proyecto SP 2.1

Establecer el presupuesto y el calendario.

SP 2.2

Identificar los riesgos del proyecto.

SP 2.3

Planificar la gestión de los datos.

SP 2.4

Planificar los recursos del proyecto.

SP 2.5

Planificar el conocimiento y las habilidades necesarias.

SP 2.6

Planificar la involucración de las partes interesadas.

SP 2.7

Establecer el plan de proyecto.

22

SG 3 Obtener el compromiso con el plan. SP 3.1

Revisar los planes que afectan al proyecto.

SP 3.2

Conciliar los niveles de trabajo y de recursos.

SP 3.3

Obtener el compromiso con el plan. Tabla 4. Metas y prácticas específicas de PP 12

2.4.3. Monitoreo y control del proyecto (PMC) El propósito de la Monitorización y Control del Proyecto (PMC) es proporcionar una comprensión del progreso del proyecto para que se puedan tomar las acciones correctivas apropiadas, cuando el rendimiento del proyecto se desvíe significativamente del plan.

Un plan de proyecto documentado es la base para la monitorización de las actividades, la comunicación del estado y la toma de acciones correctivas. El progreso se determina principalmente comparando los atributos de los productos de trabajo y de las tareas, el esfuerzo, el coste y el calendario reales, con el plan en los hitos o niveles de control establecidos en el calendario del proyecto.

SG 1 Monitorizar el proyecto frente al plan

12

SP 1.1

Monitorizar los parámetros de planificación del proyecto.

SP 1.2

Monitorizar los compromisos.

SP 1.3

Monitorizar los riesgos del proyecto.

SP 1.4

Monitorizar la gestión de los datos.

SP 1.5

Monitorizar la involucración de las partes interesadas.

Fuente: SEI; CMMI® para Desarrollo, Versión 1.3, 2010

23

SP 1.6

Llevar a cabo las revisiones del progreso.

SP 1.7

Llevar a cabo las revisiones de hitos.

SG 2 Gestionar las acciones correctivas hasta su cierre SP 2.1

Analizar las cuestiones.

SP 2.2

Llevar a cabo las acciones correctivas.

SP 2.3

Gestionar las acciones correctivas. Tabla 5. Metas y prácticas específicas de PMC 13

2.4.4. Aseguramiento de la calidad del proceso y del producto (PPQA) El propósito del Aseguramiento de la Calidad del Proceso y del Producto (PPQA) es proporcionar al personal y a la gerencia una visión objetiva de los procesos y de los productos de trabajo asociados.

El área de proceso de Aseguramiento de la Calidad del Proceso y del Producto implica las siguientes actividades:

•

Evaluar objetivamente los procesos realizados y los productos de trabajo frente a las descripciones de proceso, los estándares y los procedimientos aplicables.

•

Identificar y documentar las no conformidades.

•

Proporcionar realimentación al personal del proyecto y a los gerentes sobre los resultados de las actividades de aseguramiento de la calidad.

•

Asegurar que se tratan las no conformidades. El área de proceso de Aseguramiento de la Calidad del Proceso y del Producto da soporte a la entrega de productos de alta calidad, proporcionando al personal del proyecto y a los

13

Fuente: SEI; CMMI® para Desarrollo, Versión 1.3, 2010

24

gerentes, en todos los niveles, la visibilidad apropiada y la realimentación sobre los procesos y los productos de trabajo asociados, durante toda la vida del proyecto.

SG 1 Evaluar objetivamente los procesos y los productos de trabajo SP 1.1

Evaluar objetivamente los procesos.

SP 1.2

Evaluar objetivamente los productos de trabajo.

SG 2 Proporcionar una visión objetiva SP 2.1

Comunicar y resolver las no conformidades.

SP 2.2

Establecer los registros. Tabla 6. Metas y prácticas específicas de PPQA 14

2.4.5. Gestión de la configuración (CM) El propósito de la Gestión de Configuración (CM) es establecer y mantener la integridad de los productos de trabajo utilizando la identificación de la configuración, el control de la configuración, el informe del estado de la configuración y las auditorías de la configuración.

El área de proceso de Gestión de Configuración implica las siguientes actividades: entender

•

Identificar la configuración de los productos de trabajo seleccionados que componen las líneas base en puntos determinados en el tiempo.

•

Controlar los cambios a los elementos de configuración.

14

Fuente: SEI; CMMI® para Desarrollo, Versión 1.3, 2010

25

•

Construir o proporcionar las especificaciones para construir los productos de trabajo a partir del sistema de gestión de configuración.

•

Mantener la integridad de las líneas base.

•

Proporcionar a los desarrolladores, usuarios finales y clientes datos precisos del estado y de la configuración actual.

SG 1 Establecer las líneas base SP 1.1

Identificar los elementos de configuración.

SP 1.2

Establecer un sistema de gestión de configuración.

SP 1.3

Crear o liberar las líneas base.

SG 2 Seguir y controlar los cambios SP 2.1

Seguir las peticiones de cambio.

SP 2.2

Controlar los elementos de configuración.

SG 3 Establecer la integridad SP 3.1

Establecer los registros de gestión de configuración.

SP 3.2

Realizar auditorías de configuración Tabla 7. Metas y prácticas específicas de CM 15

2.4.6. Medición y análisis (MA) El propósito de Medición y Análisis (MA) es desarrollar y mantener la capacidad de medición utilizada para dar soporte a las necesidades de información de la gerencia.

15

Fuente: SEI; CMMI® para Desarrollo, Versión 1.3, 2010

26

El área de proceso Medición y Análisis implica las siguientes actividades:

•

Especificar los objetivos de medición y análisis para alinearlos con las necesidades de información y con los objetivos del proyecto, de la organización o del negocio.

•

Especificar las medidas, las técnicas de análisis y los mecanismos, para la recogida de datos, almacenamiento de datos, difusión y realimentación.

•

Implementar las técnicas de análisis y los mecanismos para la recogida de datos, difusión de datos y realimentación.

•

Proporcionar resultados objetivos que puedan utilizarse en la toma de decisiones informadas y en la toma de acciones correctivas apropiadas.

SG 1 Alinear las actividades de medición y análisis SP 1.1

Establecer los objetivos de medición.

SP 1.2

Especificar las medidas. Especificar los procedimientos de recogida y de

SP 1.3

almacenamiento de datos.

SP 1.4

Especificar los procedimientos de análisis.

SG 2 Proporcionar los resultados de la medición. SP 2.1

Obtener los datos de la medición.

SP 2.2

Analizar los datos de la medición.

SP 2.3

Almacenar los datos y los resultados.

SP 2.4

Comunicar los resultados. Tabla 8. Metas y prácticas específicas de MA 16

16

Fuente: SEI; CMMI® para Desarrollo, Versión 1.3, 2010

27

2.4.7. Gestión de acuerdos con proveedores (SAM) El propósito de la Gestión de Acuerdos con Proveedores (SAM) es gestionar la adquisición de productos y servicios de proveedores.

El alcance de esta área de proceso aborda la adquisición de productos, servicios y componentes de producto y de servicio que pueden ser entregados al cliente del proyecto o incluidos en un producto o sistema de servicios. Estas prácticas del área de proceso también pueden ser utilizadas para otros propósitos que beneficien al proyecto.

SG 1 Establecer acuerdos con proveedores SP 1.1

Determinar el tipo de adquisición.

SP 1.2

Seleccionar a los proveedores.

SP 1.3

Establecer acuerdos con proveedores

SG 2 Satisfacer los acuerdos con los proveedores SP 2.1

Ejecutar el acuerdo con el proveedor.

SP 2.2

Aceptar el producto adquirido.

SP 2.3

Asegurar la transición de los productos. Tabla 9. Metas y prácticas específicas de SAM 17

* Esta área de procesos SAM, es la única que el SEI permite ser excluida en la implementación del modelo, como es el presente caso ya que las empresas no tienen proveedores de software.

17

Fuente: SEI; CMMI® para Desarrollo, Versión 1.3, 2010

28

2.5. Estándar de evaluación SCAMPI SCAMPI (Standard CMMI Appraisal Method for Process Improvement) Método de Evaluación Estándar de CMMI para la Mejora de Procesos.

El método SCAMPI es un proceso diseñado y desarrollado por la Carnegie Mellon-SEI para ofrecer evaluaciones de calidad con relación al modelo CMMI. SCAMPI permite identificar las fortalezas y debilidades de los procesos determinados en 3 aspectos.

•

Desarrollo.

•

Adquisición de los riesgos.

•

Capacidad y nivel de madurez.

SCAMPI se relaciona, directamente con la estructura de CMMI como se muestra en la figura 5, aquí se puede observar que el campo de acción de SCAMPI, se encuentra en la evaluación de las prácticas genéricas como específicas de cada área de procesos.

Figura 5. Estructura CMMI-SCAMPI 18

18

Fuente: http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=7771

29

2.5.1. Uso de SCAMPI SCAMPI se usa para identificar fortalezas y debilidades de los procesos, revelar riesgos de desarrollo, y determinar niveles de capacidad y madurez. Se utiliza ya sea como parte de un proceso o programa de mejoramiento, o para la calificación de posibles proveedores. El método define el proceso de evaluación constando de preparación; las actividades sobre el terreno; observaciones preliminares, conclusiones y valoraciones; presentación de informes y actividades de seguimiento. SCAMPI puede utilizarse de distintos modos como son:

•

Análisis de Brecha: Evaluación inicial para bosquejar un plan de mejora

•

Mini Evaluación: Primera experiencia de entrevistas-intensivas para un nuevo grupo de aprendizaje sobre procesos de mejora y evaluaciones.

•

Monitoreo de Mejora: Evaluación interna de progreso para monitorear la implementación de nuevas prácticas.

2.5.2. Clases de evaluación SCAMPI El SCAMPI incluye tres clases de evaluación. SCAMPI A son evaluaciones que dan lugar a clasificaciones de referencia de calidad (por ejemplo, niveles de madurez) reconocidos oficialmente. SCAMPI B y C evaluaciones son evaluaciones menos rigurosas diseñadas para proporcionar información para la mejora de procesos o el estado de los trabajos de mejora de procesos.

2.5.2.1. SCAMPI Clase C Se basa en el enfoque planeado para satisfacer objetivos de mejora de proceso, es el más rápido, económico y flexible , ayuda a evaluar áreas de riesgo con recolección básica de datos. Es el de menor duración y alcance, y es utilizado para ver el uso de los procesos

30

en la organización y de las iniciativas de mejora con relación al modelo CMMI. Al ser más breve los resultados permiten identificar una tendencia en el uso del proceso. No da un nivel de madurez. Constituye una “toma del pulso” de la organización.

2.5.2.2. SCAMPI Clase B El SCAMPI Clase B se basa en examinar el despliegue de procesos en proyectos seleccionados de la unidad organizacional. Es útil previo a la implantación masiva de nuevos procesos y provee flexibilidad en el alcance del modelo.

Ofrece criterios de muestreo de la organización menos exigentes que la clase A. Permite validar la implementación de los procesos y prácticas definidas, ayudando a comprender el posible despliegue de éstas al resto de la organización. Es de mayor duración que un C. No da un nivel de madurez

2.5.2.3. SCAMPI Clase A Es un método que se basa en la institucionalización de CMMI en una unidad organizacional. Es el método más exhaustivo y riguroso, usado para evaluaciones en profundidad y determinar el nivel de madurez de la organización. Es más riguroso en cuanto a la muestra de proyectos a observar y da un nivel de madurez a la organización.

El SCAMPI A debe ser realizado por una figura denominada Lead Appraiser. El Lead Appraiser es una persona acreditada por el SEI para realizar la evaluación CMMI. Finalmente, es el Lead Appraiser quién emite lo que se conoce como “Appraisal Disclosure Statement”, documento que muestra los resultados de la evaluación.

Cuando se va a realizar una evaluación SCAMPI, normalmente no se evalúan todos los proyectos de la unidad organizacional, sino que se selecciona una muestra de proyectos

31

representativa de la misma. La selección de los proyectos adecuados para la muestra es una tarea importante dentro de una auditoría CMMI, ya que estos deben cubrir todos los factores críticos que se identifiquen dentro de la unidad organizacional.

A la hora de realizar la evaluación, se distinguen tres tipos de proyectos, que pueden formar parte de la muestra19:

Proyecto objetivo: es un proyecto que aporta evidencia objetiva de todas las áreas de proceso del nivel de madurez a evaluar. A la hora de evaluar el proyecto no importa si este ha terminado o no (hay por ejemplo proyectos que están en mantenimiento un gran número de años), solamente se comprueba si proporciona evidencia para cada una de las áreas de proceso definidas en el nivel CMMI a evaluar. Un ejemplo de un proyecto de este tipo puede ser un proyecto de desarrollo para un cliente que se encuentra al final de la fase de pruebas. En el caso de que a lo largo del proyecto se hayan seguido correctamente los procesos definidos en la organización, el proyecto podrá proporcionar evidencia de cada una de las áreas de proceso del nivel de madurez evaluado.

Proyecto no objetivo: es un proyecto que aporta evidencia objetiva de alguna de las áreas de proceso dentro del alcance de la evaluación. Estos proyectos sirven como complemento de los proyectos objetivos, para obtener mayor número de evidencias de la realización de cada una de las prácticas definidas en CMMI. Un ejemplo de un proyecto de este tipo puede ser un proyecto de desarrollo de una Web iniciado en las últimas fases de la implantación de CMMI, y que se encuentra aún en el análisis de requisitos.

Este proyecto puede proporcionar evidencias en algunas áreas de proceso, como en la Gestión de Requerimientos, pero difícilmente podrá proporcionar evidencias para todas las áreas de proceso del nivel de madurez 2.

19 A partir de la versión 1.3 de SCAMPI ya no se distingue entre proyectos objetivos y no objetivos. Además, los proyectos pasan a ser denominados “unidades básicas”.

32

Función de apoyo: función organizativa que aporta evidencia objetiva de las áreas de proceso organizativas, por ejemplo formación, el aseguramiento de la calidad, RRHH, etc.

2.5.3. Los participantes de un SCAMPI A Para poder llevar a cabo una evaluación es necesario un equipo de trabajo que cumpla unos requisitos mínimos. De esta manera se asegura la experiencia, el conocimiento y las habilidades necesarias para participar en la evaluación.

El personal necesario para participar en actividades o realizar tareas en una evaluación SCAMPI A (tanto de la organización a evaluar como de la organización evaluadora) incluye los siguientes roles:

Sponsor. Es el encargado de liderar el proyecto de mejora. Normalmente, se corresponde con un directivo de la organización.

Jefe del equipo de evaluación (Appraisal Team Leader). Responsable de realizar la evaluación. El jefe del equipo de evaluación debe ser un Lead Appraiser, y pertenecer a una empresa partner del SEI para poder realizar la evaluación, así como tener la experiencia y entrenamiento necesario.

Coordinador de la organización (Organizational Unit Coordinator u OUC). Encargado de facilitar la realización de la auditoría. Proporciona la información necesaria al evaluador. Es común que se corresponda con el responsable de calidad de la organización.

Miembros del equipo de evaluación (Appraisal Team Members o ATM). Personal de la organización a auditar y que cumple con los requisitos para formar el equipo de evaluación, y que cuenta con la experiencia y el entrenamiento suficiente.

33

Participantes seleccionados. Encargados de proporcionar la información necesaria. Es común que sean jefes de proyecto de los proyectos evaluados.

La evaluación SCAMPI A debe ser realizada por un equipo evaluador formado por un evaluador líder -SCAMPI Lead Appraiser y 4 integrantes (ATM). Cada uno de estos 4 ATM, debe satisfacer los siguientes requisitos:

•

Debe haber asistido previamente al curso oficial del SEI “Introduction to CMMI .

•

Debe tener disponibilidad completa durante la evaluación. Aproximadamente 5 y 8 días para los niveles de madurez 2 y 3 respectivamente.

•

Debe ser independiente de los proyectos evaluados. No podrá por tanto ser responsable de ninguno de los proyectos seleccionados para la evaluación, ni ser responsables directos o indirectos de aquellas personas que serán entrevistadas durante la evaluación.

•

Cada miembro del equipo evaluador debe tener al menos 6 años de experiencia promedio en el campo de desarrollo software y la suma de experiencias de los miembros del equipo debe ser de al menos 25 años como experiencia total del grupo. Es recomendable que cada miembro del equipo tenga al menos 3 años de experiencia en cada una de las disciplinas que serán parte de la evaluación4.

•

Al menos un miembro del equipo de evaluación deberá tener al menos 6 años de experiencia en la gestión de proyectos software. El equipo evaluador en total deberá tener al menos 10 años de experiencia en dicha gestión.

•

El equipo de evaluación deberá tener unos conocimientos adecuados de las diferentes fases del ciclo de vida de desarrollo de los proyectos y sobre diferentes entornos y dominios de negocio de los proyectos de la organización evaluada. Al menos dos miembros del equipo han de tener experiencia práctica.

•

Es altamente recomendable que los miembros del equipo de evaluación puedan leer documentación técnica en inglés, dado que mucho del material de soporte del

34

método SCAMPI está en este idioma. •

El SCAMPI Lead Appraiser es quien finalmente decide la aceptación o no de los miembros del equipo evaluador y es el responsable de asegurar que sus cualificaciones y su sostenibilidad están acordes con el propósito de la evaluación.

2.5.4. Comparación de clases de SCAMPI

Tabla 10. Características de los tipos de SCAMPI 20

Comparando los tres tipos de clases de evaluación de la familia SCAMPI, se puede denotar que de acuerdo a las características necesarias dentro de la realización de una evaluación, la Clase A es la más completa y estricta, además la única que permite obtener una valoración en cuanto al nivel de madurez de una organización

Figura 6. Campo de aplicación de cada clase de SCAMPI 20

20

Fuente: http://www.spaceminds.com/esp/SCAMPI-Appraisals.aspx

35

Observando el campo de aplicación de cada clase de SCAMPI determinamos que la evaluación clase A, debe utilizarse para determinar el grado institucionalización de los procesos, por tanto estos debieron haber sido implementados completamente en una organización para realizar esta prueba.

2.5.5. Fases del método SCAMPI

Tabla 11. Fases y procesos del método SCAMPI 21

21

Fuente: CMMI-DEV http://www.sei.cmu.edu/pubIications!documents/O6.reports/O6trOO8.htmI

36

2.5.6. Los indicadores de implementación de la práctica (PII) Para comprender qué son los indicadores de implementación de la práctica es necesario conocer primero la estructura de un área de proceso. Las áreas de proceso están compuestas de objetivos, que deben ser alcanzados para cumplir con el área de proceso.

Se distinguen dos tipos de objetivos, los objetivos genéricos (GG), que son comunes a todas las áreas de proceso, y los objetivos específicos (SG), que son definidos por cada área de proceso. (Ver numeral 2.4. capítulo 2).

Estos objetivos se dividen a su vez en prácticas, que son actividades para alcanzar el objetivo del área de proceso. Se distinguen también dos tipos de prácticas, las prácticas genéricas (GP), que son comunes a todas las áreas de proceso, y las prácticas específicas (SP), que son propias de cada área de proceso. (Ver numeral 2.4. capítulo 2).

Cuando se realiza una evaluación SCAMPI, es necesario comprobar que todos los objetivos de cada área de proceso definida en el nivel de madurez a evaluar han sido alcanzados. Para ello, se comprueba que todas las prácticas definidas de cada objetivo han sido satisfechas. Si esto es así, la realización de cada práctica dejará algún tipo de “rastro” (por ejemplo un documento, un acta de reunión, un email, etc.). A estos “rastros” se les conoce como indicadores de implementación de la práctica (Practice Implementation Indicators o PII), que son, por lo tanto, el resultado de la implementación de una práctica y que sirven para comprobar que esta implementación se ha realizado correctamente.

Los PII son utilizados para demostrar que existe evidencia objetiva de la implementación de cada una de las prácticas que van a ser evaluadas. Para que exista evidencia objetiva, el método SCAMPI indica que debe existir un artefacto directo que demuestre el propósito de la práctica y que este a su vez sea corroborado por artefactos directos o afirmaciones7.

37

Por lo tanto, para comprobar que existe evidencia objetiva de la implementación de la práctica.

2.5.6.1. La base de datos de indicadores de implementación (PIIDB) Una Base de Datos de Indicadores de Implementación de la Práctica (Practice Implementation Indicators DataBase o PIIDB) es una base de datos que almacena evidencias de la implementación de las diferentes prácticas (SP y SG) definidas en CMMI.

Las organizaciones pueden proporcionar una PIIDB como entrada a la evaluación (de hecho es muy recomendable trabajar desde el inicio con una PIIDB, para ordenar el trabajo y obtener una evaluación constante). Esta PIIDB mostrará la trazabilidad de las prácticas del modelo a las áreas de proceso correspondientes y a las evidencias objetivas usadas para verificar la implementación de la práctica.

Un ejemplo de una PIIBD se encuentra en el Anexo B.5.

2.5.7. Grupo de procesos de ingeniería de software SEPG SEPG (Software Engineering Process Group), grupo de procesos de ingeniería de software, es el punto focal de una organización para las actividades de mejora del proceso de software. Estos individuos realizan evaluaciones de la capacidad de organización, desarrollar planes para implementar las mejoras necesarias, coordinar la aplicación de esos planes, y medir la eficacia de estos esfuerzos.

Los SEPG requieren conocimientos especializados y conocimientos de muchas áreas exteriores tradicionales de ingeniería de software. (Priscilla; Rifkin, Stanley, 1990)

38

A continuación se presentan las actividades que realiza el grupo de procesos: •

Obtiene y mantiene el apoyo de todos los niveles de gestión.

•

Facilita la evaluación del proceso de software.

•

Funciona con los gerentes de línea, cuyos proyectos se ven afectados por los cambios en la práctica de la ingeniería de software, proporcionando una amplia perspectiva del esfuerzo de mejora y ayuda a establecer las expectativas.

•

Mantiene relaciones de trabajo en colaboración con los ingenieros de software, especialmente para obtener, planificar e instalar nuevas prácticas y tecnologías.

•

Organiza para cualquier entrenamiento o educación continua relacionada con las mejoras de proceso.

•

Temas, monitores, y los informes sobre el estado de los esfuerzos de mejora particulares.

•

Facilita la creación y el mantenimiento de las definiciones de procesos, en colaboración con los directores y el personal de ingeniería.

•

Mantiene una base de datos de procesos.

•

Proporciona consultoría de procesos de proyectos y gestión del desarrollo.

•

También ayuda en la evaluación de nuevas herramientas y tecnologías, y luego recomendar la mejor herramienta / tecnología adecuada para la organización y el consiguiente ahorro de tiempo, esfuerzo y dinero

2.5.8. El conocimiento Existe una literatura muy amplia acerca del conocimiento en las cuales se encuentran variadas definiciones que lo abordan.

Así, para (Davenport y Prusak, 1998) conocimiento es una mezcla fluida de experiencia estructurada, valores, información contextualizada y discernimiento experto que provee un marco de referencia para evaluar e incorporar nuevas experiencias e informaciones.

39

Por su parte (Probst G et al, 2001), definen conocimiento como todo el cúmulo de aprendizajes y habilidades que los individuos utilizan para solucionar problemas. Un enfoque diferente para lograr una mejor aproximación al concepto de conocimiento es establecer la distinción entre conocimiento e información, información y datos.

2.5.9. Dato, información y conocimiento Los tres términos suelen utilizarse indistintamente y esto puede llevar a una interpretación libre del concepto de conocimiento. Quizás la forma más sencilla de diferenciar los términos sea pensar que los datos están localizados en el mundo y el conocimiento está localizado en agentes de cualquier tipo, mientras que la información adopta un papel mediador entre ambos. Por su parte (Wiig K., 1993), menciona que: datos pueden ser números, palabras o imágenes para los cuales no se ha especificado un contexto de significación o una organización. Para que los datos se conviertan en información deben ser presentados en un contexto, con algún propósito y con una organización discernible de modo que tengan relevancia para una situación, problema o

condición. El conocimiento es

subsecuentemente aplicado para interpretar la información disponible sobre una situación en particular y para decidir cómo manejarla. El conocimiento es lo que se usa para determinar el significado de una situación o condición.

Según (Alavi y Leidner, 2001) afirma que el conocimiento es clave para distinguir efectivamente entre información y conocimiento no se encuentra en el contenido, estructura o utilidad de la supuesta información o conocimiento sino que conocimiento es información procesada por las mentes de los individuos; es información personalizada relativa a hechos, procedimientos, conceptos, ideas y juicios.

40

El conocimiento es un recurso que está convirtiéndose en una materia con un enorme potencial para cambiar el mundo debido a los avances de las nuevas tecnologías de la información. En el entorno económico en el que nos encontramos, el conocimiento es un elemento esencial para la economía de la información e implica la creación de herramientas que permitan una gestión correcta de este conocimiento.

El uso del conocimiento para una mejora de las estructuras organizativas y sociales ha dado lugar a un gran abanico de herramientas tecnológicas cuya finalidad es soportar estas estructuras y facilitar los flujos de conocimiento entre los agentes que las componen. Las organizaciones no sólo deben disponer de medios tecnológicos para la generación, síntesis y transmisión del conocimiento, sino que deben existir otros sistemas que faciliten el flujo de conocimiento.

Como consecuencia, las organizaciones que deciden implementar tecnologías relacionadas con la GC deben realizar cambios organizativos y, en muchos casos, cambios de cultura para conseguir que el uso de estas herramientas tecnológicas acompañado de otros sistemas no tecnológicos lleve a una mejora de los procesos de la organización.

Es necesario que los trabajadores poseedores de conocimiento puedan compartir el conocimiento, para ser usado de una forma efectiva y que existan canales para la mejora de la captación del conocimiento, tanto el conocimiento explícito como el implícito o tácito.

2.5.10.

2.5.10.1.

Tipos de conocimiento

El conocimiento Tácito

Se asigna en mayor medida al modelo cognitivo (capacidad de procesar información a través de la percepción) que yace en el interior de las personas, digamos que tiene que ver

41

más con la actitud, habilidades cognitivas, intuición, creatividad, emociones o sabiduría. No puede ser expresado con palabras, frases, números o fórmulas porque a menudo está basado en un contexto específico (propio o peculiar de cada persona y que es utilizado para distinguirlo de otras).

El conocimiento tácito requiere de interacciones más intensas y cercanas, y exige el concurso de canales de comunicación más completos, incluso una vez transferido, el conocimiento más tácito es difícil de retener (Szulanski G, 1996).

2.5.10.2.

El conocimiento Explícito

Es muy diferente al tácito. Es aquel conocimiento que se adquiere de manera técnica o funcional y que es fácil de adquirir. Hace referencia a lo intelectual, como resolución de problemas, teorías, manuales, libros, etc. Puede ser codificado, expresado en un contexto libre, con palabras, frases, números o formulas, y guardado en documentos y transferido a través de tecnologías de la información. Adicionalmente, estos conocimientos pueden ser retenidos en medios electrónicos y conservados para su futura utilización (Hernán Joglar, 2008).

2.5.11.

Gestión del Conocimiento (GC)

La gestión del conocimiento a través de los tiempos se ha manejado de diferentes maneras, pero fundamentalmente siempre se ha tenido en cuenta los siguientes procesos durante su administración (Bergeron Bryan, 2003).

•

Creación / Adquisición:

•

Modificación

•

Uso

•

Archivado

42

•

Transferencia

•

Traducción / Reutilización.

•

Acceso

•

Eliminación

Toda organización cuenta con una herramienta que hace que su plan de gestión de conocimiento sea exitoso y se diferencie de los planes de otras organizaciones, esta herramienta es el capital intelectual. Este capital se encuentra principalmente dividido en tres tal como lo muestra la Figura 7.

Figura 7. División del capital intelectual de una organización 22

Capital Humano: es aquel conocimiento, habilidades y competencias que posee la gente en la organización. El capital humano está compuesto por tres tipos de conocimiento: el conocimiento tácito, implícito y explícito. 22

Fuente: Bergeron, Bryan. Essentials of knowledge Management.

43

Capital del cliente: es aquel capital que es generado a partir de las relaciones con los clientes, incluye lealtad de los clientes, canales de distribución, marcas, franquicias y licencias.

Capital estructural: los procesos, estructuras, sistemas de información y propiedad intelectual que es independiente de los empleados.

2.5.11.1.

Ciclo de la gestión de conocimiento

Según revisión de la literatura (Hernán Joglar, 2008) la gestión efectiva del conocimiento requiere que una organización desarrolle un conjunto de procesos para lograr su evolución controlada desde su generación hasta su aplicación en beneficio del cumplimiento de los objetivos fundamentales de la entidad. Así, el ciclo de la GC puede ser entendido como la ruta que siguen el conocimiento y la información para convertirse en un activo que entregue un valor estratégico a la organización.

En la siguiente tabla se muestran los distintos ciclos de vida de gestión del conocimiento propuestos por varios autores.

Tabla 12. Ciclos de GC propuestos por varios autores 23

23

Fuente: Hernán Joglar (2008).

44

En términos genéricos, el conocimiento en una organización se debe crear o adquirir, capturar, difundir y aplicar en beneficio de los fines organizativos. Éstos son los procesos relacionados con la GC que consideran los diferentes ciclos. Algunos de estos procesos han sido divididos o refundidos según la perspectiva del autor, sin embargo todos contienen, de una u otra forma, estas actividades (Hernán Joglar, 2009).

A continuación se muestra el gráfico que indica las etapas en las cuales el conocimiento es gestionado según (Hernán Joglar, 2009).

Figura 8. Ciclo de gestión del conocimiento 24

2.5.11.2.

Creación del conocimiento.

Esto comprende las actividades asociadas con la entrada de nuevos conocimiento en el sistema, e incluye el desarrollo del conocimiento, el descubrimiento y la captura.

2.5.11.3.

Retención de conocimiento

Esto incluye todas las actividades que preservan el conocimiento y permiten que a permanecer en el sistema una vez introducido. También incluye aquellas actividades que mantienen la viabilidad de los conocimientos dentro del sistema. 24

Fuente: Joglar Hernán et al. (2008).

45

Las organizaciones deben recordar y poner en acción ideas, modelos y nociones aprendidas en el pasado para mejorar paulatinamente sus prácticas y, a la vez, evitar repetir errores del pasado. Estas ideas apuntan a la existencia de una memoria colectiva que permite a los grupos sociales conservar el conocimiento adquirido y emplearlo cuando sea apropiado en el futuro.

2.5.11.3.1. Memoria Organizativa (MO) Conjunto de depósitos de información y conocimiento a través del cual el conocimiento obtenido en el pasado es empleado en las actividades actuales, pudiendo entregar como resultado una mayor o menor efectividad.

Tabla 13. Formas de memoria organizativa su Contenido y Uso 25

2.5.11.4.

Transferencia del Conocimiento

Se refiere a las actividades asociadas con el flujo de conocimiento de una parte a otra. Esto incluye la comunicación, la traducción, la conversión, el filtrado y la representación.

25

Fuente: Joglar Hernán et al. (2008).

46

Es el proceso de diseminación del conocimiento desde un individuo o grupo hacia otro(s) dentro de una organización. El conocimiento explícito, por ser más fácil de articular, es normalmente transferido a través de TI.

El conocimiento tácito, más difícil o imposible de articular, debe ser intercambiado a través de medios intensivos en interacción social. Algunas modalidades: entrenamiento, coaching, comunicación expedita; o bien. TIC’s: groupware, email, otros.

2.5.11.5.

Utilización del Conocimiento

Incluye las actividades y actos relacionados con la aplicación del conocimiento a los procesos de negocio. Mediante la aplicación del conocimiento, las personas son capaces de manejar la ejecución de sus tareas en forma más eficiente y efectiva.

La eficiencia se logra aplicando los conocimientos para: •

Reducir el consumo de recursos, tales como tiempo, suministros y mano de obra.

•

Producir más con los mismos recursos.

•

Aplicar nuevas ideas, nociones o iniciativas para mejorar la calidad del trabajo, reducir la cantidad de errores producidos o mejorar la forma de hacer las cosas (Wiig y Jooste, 2003).

•

Para lograr mejorar la eficiencia y efectividad de una organización el conocimiento debe ser “utilizado”.

•

Pero es de vital importancia que el conocimiento sea “reutilizado”, pues allí se encuentra el camino para ahorrar recursos y mejorar el rendimiento

Agentes que comparten objetivos •

Equipos de trabajo homogéneo

•

Equipos multidisciplinarios

•

Profesionales que hacen el mismo trabajo

47

•

Rol similar en diferentes contextos

•

Comunidades de práctica

2.6. Modelo SECI La dimensión cognitiva que se produce en la conversión de conocimientos, que ayuda significativamente a incrementar el conocimiento basado en la socialización entre el personal de la empresa. La información a la que están expuestos los individuos puede considerarse como conocimiento potencial; según Nonaka y Takeuchi 1994, este conocimiento potencial se transforma en conocimiento tácito cuando se combina la información dentro del contexto y experiencia de los humanos. Esta creación cíclica de conocimiento SECI se muestra en la siguiente figura:

Figura 9. Modelo SECI, proceso de generación del conocimiento 26

El modelo SECI propuesto por Nonaka y Takeuchi enfatiza la creación del conocimiento dentro de las organizaciones, mostrando que es fruto de un ciclo continuo de interacción

26

Fuente: Modelo SECI de Nonaka y Takeuchi, 1994

48

dinámica entre 2 tipos de conocimientos, conocimiento Tácito y el conocimiento Explícito.

El modelo SECI también remarca, que el intercambio de conocimiento no es un proceso asignado a un solo individuo, sino que es un proceso social entre varios individuos. Una de las ventajas de este modelo es que está basado en la dinámica natural de creación o construcción de conocimiento.

Según el estudio de Nonaka y Takeuchi, tanto el conocimiento tácito y el explícito, pueden ser transferidos y convertidos. Y si somos capaces de ver todo el proceso como un proceso de mejora y aprendizaje continuo, aprenderemos que el aprendizaje de la organización está basado y sustentado en una espiral de conocimiento, la cual a medida que va creciendo y aumentando en conocimiento, se va moviendo hacia niveles más y más profundos (Figura 9), funciona como un bucle (Javier Pérez, 2010)

2.6.1. Socialización El proceso de transferir el conocimiento tácito a otra persona es la Socialización (tácito a tácito). En la organización esto tiene lugar con la interacción de la gente desde dentro de la organización, y asimismo con proveedores/clientes de fuera de la organización. Depende de la experiencia compartida (se comparten sentimientos, emociones, experiencias) y como resultado obtenemos capacidades y modelos mentales. Este proceso es primariamente un proceso entre individuos.

2.6.2. Externalización El proceso de transferir el conocimiento tácito en conocimiento explícito es la Externalización (tácito a explícito). Tiene que ver con la articulación de nuestro propio conocimiento tácito, ideas o imágenes en palabras, metáforas o analogías. Otra manera

49

sería traspasando el conocimiento tácito de otros, como puedan ser clientes, proveedores, entre otros en conocimiento explícito. Esto podría tener lugar durante y mediante el diálogo. Mientras nos comunicamos, compartimos creencias y aprendemos como relacionarnos y como intercambiar ideas. La exteriorización es un proceso entre individuos dentro de un grupo.

2.6.3. Combinación Una vez que ya disponemos de conocimiento explícito, lo podemos transmitir a través de la Combinación (explícito a explícito). Puede ser transmitida a través de documentos, educación, mail, cartas, bases de datos, libros e incluso con el uso de las tecnologías de la información. Este proceso tiene lugar entre grupos a través de las organizaciones.

2.6.4. Internalización La Internalización (explícito a tácito), es el proceso de recoger y absorber el conocimiento explícito para generar conocimiento tácito en el individuo. La interiorización es experimental y se basa en la actualización de los conceptos y métodos que ya disponíamos, a partir de la simulación o experimentación en el día a día. Este es un proceso que se transmite de las organizaciones al individuo. Pero, ¿Cuándo y bajo qué condiciones tiene lugar esta espiral de conocimiento? ¿En qué espacios? Según Nonaka esto puede ser de varias maneras:

•

Físicamente: En la oficina.

•

Virtualmente: mail, videoconferencia.

•

Mentalmente: Intercambio de experiencias, ideas, creencias.

•

Relacionalmente: Intercambiando objetivos comunes.

50

De lo expuesto anteriormente se deduce que Nonaka y Takeuchi establecen que el verdadero conocimiento, proviene del compromiso y las creencias, no obstante, la construcción y transporte de conocimiento requiere compartir emociones, sentimientos, modelos de aproximación, experiencias, modelos empíricos; y lo

ideal es que el

conocimiento tácito se transforme en conocimiento explícito para que este se traduzca en herramientas y métodos que ayuden a lograr objetivos y metas, con las que las personas puedan contribuir y alcanzar su objetivos dentro de la organización, como pueden ser llevar a buen término proyectos que mejoren los resultados de la empresa, y que generen una ventaja competitiva respecto a sus competidores.

2.7. Relacionando CMMI con gestión del conocimiento Como se ha revisado varias son las definiciones se pueden encontrar del término conocimiento; y estas dependen del contexto en el cual se utilice.

Según lo describen (Ramanujan y Someswar, 2004), cuando se habla de conocimiento en el contexto de las organizaciones, traspasa la barrera del contexto y su significado llega incluso a diferir entre una organización y otra. En el estudio realizado previamente en la definición y justificación del problema del presente documento, se expuso la fuerte relación que existe entre el conocimiento y las organizaciones relacionadas con la construcción de software. Se mencionó también, cómo diferentes procesos dentro de estas organizaciones están ligadas a la gestión de conocimiento y la gran atención que últimamente este tema ha venido recibiendo y debe recibir en una economía de conocimiento.

Sin embargo, hay que resaltar que el hecho de que la gestión de conocimiento debe abordarse de una manera interdisciplinaria y debe contemplar otros aspectos de la organización como su cultura, la definición de sus procesos, la definición de sus objetivos, su estructura organizacional, entre otros, los cuales con la ayuda de CMMI podrán ser

51

abordados de manera clara que facilite realizar la creación, retención, transferencia y utilización del conocimiento para que esto sea una gran ayuda en el desarrollo de software en las PyMES.

2.8. Las pequeñas y medianas empresas (PyMES) En la literatura económica la importancia de la pequeña empresa se justifica en parte por el rol que tendría este sector en el bienestar de la economía. Esta visión ha sido generalmente aceptada en muchos países, especialmente desde que (David Birch, 1979), demostró la importancia de las empresas pequeñas en la generación de empleo. Generalmente se argumenta que los gobiernos deben promover a las PyMES por los grandes beneficios económicos que generan en comparación a las grandes empresas. Esto en términos de empleo, eficiencia y crecimiento.

La sigla “PYME” significa “Pequeña y Mediana Empresa”. Adicionalmente, la ley hace las siguientes definiciones:

•

Microempresas: Empresas cuyos ingresos anuales por ventas y servicios y otras actividades del giro, no hayan superado las 2.400 UF en el último año calendario.

•

Pequeñas empresas: Empresas cuyos ingresos anuales por ventas y servicios y otras actividades del giro, sean superiores a 2.400 UF, pero inferiores a 25.000 UF en el último año calendario.

•

Medianas empresas: Empresas cuyos ingresos anuales por ventas y servicios y otras actividades del giro, sean superiores a 25.000 UF, pero inferiores a 100.000 UF en el último año calendario.

•

Adicionalmente, para efectos laborales, se hace la siguiente clasificación según

52

número de trabajadores: o Microempresas: Empresas que cuentan con uno a nueve trabajadores. o Pequeñas empresas: Empresas que cuentan con 10 a 49 trabajadores. o Medianas empresas: Empresas que cuentan con 50 a 199 trabajadores.

No pueden ser PyMES las empresas que exploten bienes raíces no agrícolas, realicen negocios inmobiliarios o actividades financieras que no sean las necesarias para el desarrollo de su actividad principal, empresas en cuyo capital participen, en más de un 30%, sociedades que tengan acciones que se coticen en la Bolsa, ni filiales de éstas. La primera dificultad cuando se discute sobre PyMES consiste en determinar de qué tipo de empresa estamos hablando.

Existen varias definiciones de la categoría “pequeña y mediana empresa” que dependen de la variable usada para medir su tamaño (v. g. por ventas, empleo o capital invertido), pero con todas se concluye que existen alrededor de 90.000 pequeñas empresas y 13.000 medianas. Esto las distingue de, por un lado, más de 500.000 microempresas y, por el otro, de 6.000 grandes empresas que existen en Chile, como se muestra en la siguiente figura:

Figura 10. Las PyMES y el resto de las empresas en Chile 27 27

Fuente: La fuente de las exportaciones es la Corfo.

53

Microempresas son aquellas que venden anualmente hasta UF 2.400; las empresas pequeñas venden más de UF 2.400 y hasta UF 25.000; las empresas medianas venden más de UF 25.000 y hasta UF 100.000; las empresas grandes son aquellas que venden más de UF 100.000.

Las definiciones de empresa pequeña y mediana utilizadas normalmente son ad hoc, y se basan ya sea en las ventas anuales o bien en el número de empleados. El problema de estas métricas es su escaso significado económico. El que una empresa venda más o menos, o que contrate un número mayor o menor de trabajadores, no dice mucho sobre cuáles son las características inherentes a este tipo de empresas que las hacen esencialmente distintas. Sin embargo, estos criterios tradicionales sirven para tener una idea de cuán importantes son las PyME en el concierto empresarial.

El Ministerio de Economía de Chile clasifica las empresas de acuerdo al nivel de ventas. Considera que las empresas con ventas anuales de hasta UF 2.400 (aproximadamente $ 3,2 millones mensuales) son microempresas.

Las empresas pequeñas son las que venden entre UF 2.400 y UF 25.000 al año (entre $ 3,2 millones y $ 33,3 millones mensuales). Las empresas medianas venden más de UF 25.000 al año pero menos que UF 100.000 (ventas mensuales entre $ 33,3 millones y $ 133,3 millones). Las empresas con ventas superiores a este monto son consideradas grandes.

Los datos del SII muestran que en el año 2000 existían 648.491 empresas, y de ellas 107.087 eran PyME. Así, las PyME eran el 16,51% del total de empresas del país. Gran parte de ellas eran empresas pequeñas (14,48%) y una proporción menor, medianas (2,03%). Si bien las PyME no son el grupo de empresas más numeroso (las microempresas representan un poco más del 82% del total), tienen una participación importante en las

54

ventas totales. Sus ventas representaron el 20,2% del total, con una participación igualitaria de las empresas pequeñas y medianas. Quizás el rasgo más distintivo de las PyME es su importancia en el empleo agregado. Los datos de Corfo muestran que en 1997 cerca del 48% de la fuerza laboral trabajaba en las PyMES. Estos datos son muy similares a los que se desprenden de la encuesta Casen del año 1996 (ver figura 5).

55

CAPÍTULO 3 Para la solución al problema planteado se desarrolló una metodología con elementos de GC captura y utilización que fue elaborada con base en el proceso de implementación del nivel dos de CMMI.

Para el desarrollo de la metodología se consideraron seis de las siete áreas de dicho nivel, fue excluida el área de Acuerdo con Proveedores SAM, debido a que las 4 PyMES en las cuales se llevó a cabo el presente trabajo no externalizan actividades relacionadas con el desarrollo software con otras empresas, por lo que decidieron dejar fuera dicha área.

La metodología propuesta está formada por siete etapas, las cuales están basadas en capturar y utilizar el conocimiento tácito que poseen y adquieren las personas durante la realización de sus actividades de desarrollo de proyectos; las etapas del método se describen a continuación:

1. Definición 2. Evaluación inicial 3. Instrucción 4. Difusión 5. Utilización 6. Evaluación cuantitativa 7. Revisión

1.9.

Metodología propuesta

La primera etapa es el Definición; en esta etapa se conforma el equipo de trabajo (mencionado en 2.9), llamado Grupo de Procesos de Ingeniería de Software, que en adelante será mencionado como SEPG; cuyas actividades son: mejorar la calidad de los

56

proceso,

evaluar la situación actual, planificar e implementar mejoras, sugerir

herramientas tecnológicas para facilitar la mejora en la práctica; y mientras se realiza la implementación del nivel dos de CMMI, capturar, convertir y utilizar el conocimiento involucrado en el desarrollo de software.

Al SEPG se asignan roles y compromisos para la ejecución de las siguientes etapas de la metodología, además se define la periodicidad de las reuniones de trabajo.

La segunda etapa es la Evaluación inicial, en esta etapa se realiza una evaluación basada en el método SCAMPI clase C, la cual permitirá conocer el cumplimiento de los objetivos y prácticas del nivel dos de CMMI, de los equipos de trabajo y por ende de la empresa, permitiendo con esto determinar el estado de los procesos de desarrollo de software y los procesos de GC, para determinar cómo abordar la situación y establecer las bases para la puesta en marcha de la metodología

A las siguientes tres etapas Instrucción, Difusión y Utilización siguen un ciclo iterativo, debido a que la implementación del nivel dos de CMMI se va realizando paulatinamente, (Ver detalle en 3.3.3. Instrucción, y ver Figura 11).[MP2]

La tercera etapa que es la más extensa, es la Instrucción; se empiezan las reuniones para la implementación de las áreas del nivel dos de CMMI, en esta etapa se revisa y obtiene información de la forma en la cual los equipos de trabajo realizan las actividades relacionadas con las áreas de CMMI, es decir se obtiene el conocimiento individual implícito que poseen los miembros de equipos de trabajo.

En las reuniones se empieza a instruir al SEPG conforme a las prácticas y objetivos del nivel 2 de CMMI; con la finalidad de que el SEPG aprenda a llevar a cabo los procesos de la organización bajo los lineamientos del modelo CMMI, y de esta manera colaborar con la GC.

57

La cuarta etapa es la Difusión; una vez que el SEPG adopta una metodología organizada para gestionar y llevar a cabo de mejor manera los procesos de la empresa, en función de las prácticas y objetivos del nivel 2 de CMMI; el ECG será encargado de enseñar, compartir y difundir lo aprendido al resto del personal, de acuerdo a los roles correspondientes.

Durante esta etapa los miembros de los equipos de desarrollo, en forma individual o colectiva, capturan, analizan y sintetizan los conocimientos y comienzan a delinear las sugerencias y propuestas de mejora de los procesos que posteriormente serán analizadas y discutidas en las reuniones del SEPG.

La quinta etapa es la Utilización; los equipos de desarrollo ponen en marcha lo aprendido en las etapas anteriores a medida que desarrollan las actividades en sus proyectos y a la vez generan propuestas de mejores opciones para realizar las prácticas establecidas por el modelo CMMI.

La sexta etapa es la Evaluación cuantitativa; para llevar a cabo esta etapa se tendrá como referencia el método SCAMPI clase B y será aquí donde se evalúa la aplicación correcta de las prácticas y objetivos de CMMI, y a la vez determina qué y cuanto aprendió la organización; identificando además fortalezas y oportunidades de mejora.

La última etapa Revisión es donde se considera todas las observaciones realizadas en la evaluación cuantitativa para así determinar cuáles fueron los procesos en los que se requiere una revisión para intervenir en ellos y tomar acciones en las oportunidades de mejora detectadas y gestionarlos de la manera correcta para el cumplimiento adecuado de los mismos y así mejorar el proceso de GC en la organización.

58

Una vez concluida la Revisión, se debe realizar una regresión a la etapa de Instrucción y realizar un ciclo iterativo conformado por las fases subsiguientes, para de esta manera ir afinando las prácticas ejecutadas por los equipos de desarrollo y una vez que en la etapa de revisión se obtenga cumplimiento total de las prácticas, se dará por terminado el proceso de GC en los equipos de desarrollo de software. 1.10.

Ciclo de vida de la metodología

Para tener una visión más amplia de la metodología se ha desarrollado un ciclo de vida, mostrado en la Figura 9, el cual cumple con los objetivos específicos definidos para alcanzar la solución propuesta.

El ciclo de vida de la metodología consiste en el desarrollo de las 7 etapas mencionadas en la propuesta de la metodología en los contextos anteriores, donde ocurren dos ciclos iterativos de vital importancia para la GC como se muestra a continuación:

Figura 11. Ciclo de vida de la metodología. 28

28

Fuente: Elaboración propia

59

1.11.

Las 7 etapas de la metodología propuesta

1.12.Definición

Propósito El propósito de la etapa de Definición es establecer las bases para la puesta en marcha de la metodología (cronograma de actividades, plan de difusión), conformar el SEPG; y revisión preliminar de áreas del nivel dos de CMMI.

Objetivos a) Conformar el equipo de trabajo responsable de llevar a cabo el proceso GC, éste equipo será llamado Grupo de procesos de Ingeniería de Software, que en adelante será mencionado como SEPG. b) Analizar las áreas, objetivos y prácticas del nivel dos de CMMI en las que se va a trabajar. c) Asignar roles y compromisos para la ejecución de las siguientes etapas de la metodología. d) Definir la periodicidad de las reuniones de trabajo del SEPG (recomendable una vez por semana)

Criterios de entrada a) Las empresas proyectan una iniciativa para la mejora de sus prácticas y procesos de desarrollo software. b) Las empresas toman conciencia de la importancia de la GC, como forma de apoyar las actividades de mejora del desarrollo de software.

60

Criterios de salida a) Las áreas, objetivos y prácticas del nivel dos de CMMI en las que se va a realizar GC; han sido analizadas. NOTA: Si bien es cierto las áreas, objetivos, y prácticas están definidos por CMMI, en este caso se excluyó al área de SAM debido a que las empresas no externalizan

actividades relacionadas con el desarrollo software a otras empresas. b) El SEPG ha sido conformado, como también la periodicidad de las reuniones de trabajo. c) Los roles y compromisos han sido asignados y aceptados por el personal involucrado. d) Se ha elaborado la carta Gantt para el desarrollo de la metodología.

Diagrama

Conformar el grupo de procesos de ingeniería de software (SEPG)

Analizar áreas, objetivos y prácticas del nivel dos de CMMI, e introducción a la GC

Asignar roles y compromisos

Elaborar cronograma de actividades

Informar a la organización lo que se va a efectuar

Figura 12. Actividades de la etapa Definición. 29

29

Fuente: Elaboración propia

61

Actividades a) Conformar el Equipo de Gestión del Conocimiento (SEPG) b) Revisar y analizar las áreas, objetivos y prácticas del nivel dos de CMMI, para la puesta en marcha de la metodología. c) Elaborar un cronograma de actividades. d) Informar a toda la organización que se va a llevar el proceso de GC, principalmente al personal inmerso en actividades de desarrollo de software.

Estas actividades se muestran con detalle en el Anexo A.1.

62

1.13.Evaluación Inicial En una valuación SCAMPI clase C, generalmente es posible encontrar falencias en los procesos y las prácticas relacionadas al desarrollo de software es por eso que esta evaluación permite conocer el estado actual de los procesos de desarrollo de software en las empresas, y fijar el punto de partida; en la siguiente figura se muestra un ejemplo genérico de resultados de una evaluación SCAMPI clase C.

Figura 13. Ejemplo de resultado de SCAMPI clase C 30

Propósito El propósito de la etapa Evaluación Inicial es el de realizar una evaluación basada en el método SCAMPI clase C, para conocer el estado actual del proceso de gestión de conocimiento y los procesos de desarrollo de software para fijar el punto de partida.

Objetivos a) Evaluar los procesos mediante el método SCAMPI clase C. b) Identificar, evaluar las posibles falencias u oportunidades de mejora en función de los 30

Fuente: Javier Garzas Parra, Guía práctica de supervivencia en una auditoría CMMI

63

conocimientos de los miembros de los equipos de trabajo respecto de las tareas de desarrollo de software. c) Informar los resultados a la empresa. d) Identificar empleados “clave” quienes poseen conocimiento tácito, para involucrarlos en las reuniones de trabajo con el SEPG.

Criterios de entrada a) El SEPG ha sido conformado, como también la periodicidad de las reuniones de trabajo. b) Los roles y compromisos han sido asignados y aceptados por el personal involucrado.

Criterios de salida a) La evaluación con SCAMPI clase C ha sido realizada. b) Las oportunidades de mejora han sido identificadas e informadas. c) Se ha identificado los empleados que poseen conocimiento tácito cuya participación será relevante en las reuniones con el SEPG.

64

Diagrama

Evaluación SCAMPI clase C

Analizar las oportunidades de mejora detectadas

Identificar procesos desarrollados en la organización y cuales no

Identificar a personal que podría poseer conocimiento tácito

Figura 14. Actividades de la etapa Evaluación Inicial. 31

F) Actividades

a)

Ejecutar la evaluación a los procesos de desarrollo de software que se lleva a cabo en la empresa basada en el método SCAMPI para:

b)

Analizar las oportunidades de mejora detectados para los procesos en relación con el nivel dos de CMMI.

c)

Identificar que procesos desarrollan los equipos de trabajo para ajustarlos o introducir nuevos procesos.

d)

Identificar empleados “clave” quienes poseen conocimiento tácito.

Estas actividades se muestran con detalle en el Anexo A.2.

31

Fuente: Elaboración propia

65

1.14.Instrucción A las siguientes tres etapas Instrucción, Difusión y Utilización realizan un ciclo iterativo (ver Figura 11); es decir se instruye, socializa y utiliza primero el área de Gestión de Requerimientos (RQM), para luego hacer lo propio con el área de Planificación del Proyecto (PP) y así de manera sucesiva hasta cumplir con el resto de áreas, debido a que la implementación del nivel dos de CMMI se va realizando paulatinamente.

Para realizar este ciclo iterativo, se ha considerado lo expuesto por (Choudrie y Salamat, 2006), refieren a Meso y Smith, quienes vinculan el aprendizaje con los procesos de conversión de conocimiento propuestos por (Nonaka y Takeuchi, 1996). Para ellos, el conocimiento emana del proceso iterativo de externalización e internalización del conocimiento y explican que la externalización ocurre cuando el conocimiento tácito de un individuo se captura como conocimiento explícito, y la internalización ocurre cuando este conocimiento explícito capturado es luego transformado en conocimiento tácito en otro individuo.

De Tácito

A Tácito

A Explícito

Socialización

Externalización

De Explícito Internalización Combinación Tabla 14.Proceso de conversión de conocimiento (Nonaka y Takeuchi) 32

Para (Gottschalk, P., 2004), el aprender haciendo, el entrenamiento en el trabajo, el aprendizaje por observación y las reuniones cara a cara son algunos procesos de internalización por los cuales las personas adquieren conocimientos.

32

Fuente: Elaboración propia

66

Propósito El propósito de la etapa de Instrucción es empezar las reuniones con el SEPG en la implementación de las áreas del nivel dos de CMMI: Gestión de requerimientos (RQM), Planificación del proyecto (PP), Monitoreo y control del proyectos (PMC), Aseguramiento de la Calidad del Proceso y Producto (PPQA), Gestión de la Configuración (CM), y Medición y Análisis (MA).

En lo referente a Gestión de Acuerdos con Proveedores (SAM), sólo ha de ser implementada si las organizaciones externalizan actividades relacionadas con el desarrollo software a otras empresas, por lo tanto las empresas participantes de este proyecto no consideraron relevante incluir dicha área.

Objetivos a) Instruir a los miembros del SEPG para que conozcan, entrenen y comprendan los procesos a llevar a cabo, de acuerdo al propósito y el contenido las áreas del nivel dos de CMMI.

b) Extraer el conocimiento individual implícito que poseen los miembros de los equipos de trabajo los cuales serán necesarios para mejorar los procesos de desarrollo de software y GC que se llevan a cabo en el la organización.

Criterios de entrada a) Resultados de la evaluación SCAMPI clase C. b) Las oportunidades de mejora han sido identificadas e informadas al SEPG. c) Se ha detectado al personal que posiblemente sea poseedor de conocimiento tácito, cuya participación será relevante en esta etapa en las reuniones con el SEPG.

67

Criterios de salida

a)

La instrucción al SEPG se ha realizado conforme al cronograma de actividades[c3].

b)

El aporte de conocimientos por parte de los miembros de equipos de desarrollo; ha sido realizado.

E) Diagrama

" &

# '

$

%%

! " #

$

Figura 15. Actividades de la etapa Instrucción 33

Actividades a) Instruir en las Áreas del nivel dos de CMMI. b) Analizar y comprender los objetivos y prácticas de cada área del nivel dos de CMMI. c) Extraer el conocimiento individual implícito de los miembros de los equipos.

Estas actividades se muestran con detalle en el Anexo A.3. 33

Fuente: Elaboración propia

68

1.15.Difusión[MP4] Esta etapa intermedia del ciclo iterativo, apunta a que la organización aprenda lo instruido, para lo cual se ha tomado como pauta las definiciones de (Argyris C., 1977) que define el aprendizaje organizacional como un proceso de detección y corrección de errores.

Para (Probst, G. et al, 1997) se trata de la habilidad de una institución como un todo de descubrir errores y corregirlos, y de cambiar los valores y la base de conocimientos de la organización de modo tal de generar nuevas habilidades para la resolución de problemas y nuevas capacidades para la acción.

Para (Huysman, M., 2002), el aprendizaje organizacional es el proceso por medio del cual las organizaciones aprenden, ya sea de su propia experiencia o de la de otros.

Para la comprobar el cumplimiento de las actividades que se han realizado, el Aseguramiento de la Calidad del Proceso y Producto (PPQA) del modelo CMMI; servirá como ayuda para medir lo aprendido, identificando y documentando las actividades que no se están cumpliendo y proporcionar realimentación al personal sobre los resultados

El área de PPQA es un proceso transversal ver Figura 16, cuyo propósito es evaluar objetivamente todos los procesos realizados y los productos de trabajo frente a las descripciones de proceso, los estándares y los procedimientos aplicables.

Figura 16, en la siguiente página…

69

Figura 16. PPQA como proceso de control y cumplimiento de las etapas de la metodología. 34

Propósito Durante la etapa de Difusión, los miembros del SEPG, a medida que desarrollan sus actividades van adoptando o aprendiendo una metodología organizada para gestionar y llevar a cabo de mejor manera los procesos de la empresa, en función de las prácticas y objetivos del nivel 2 de CMMI.

Objetivos a) Enseñar, compartir y difundir a la organización lo aprendido en la etapa de Instrucción, conforme al propósito y al contenido las áreas del nivel dos de CMMI. b) Obtener retroalimentación de parte de los miembros de los equipos de desarrollo. c) Capturar el conocimiento otorgado por los miembros de equipos de desarrollo durante la ejecución de los procesos.

34

Fuente: Elaboración Propia

70

Criterios de entrada

a)

La instrucción al SEPG se ha realizado conforme al cronograma de actividades, se ha analizado y comprendiendo los objetivos y prácticas de CMMI.

b)

Los miembros de los equipos han aportado conocimientos en las reuniones con el SEPG.

Criterios de salida

a)

Los miembros del SEPG conforme al avance de la implementación de las áreas del nivel dos de CMMI van concluyendo paulatinamente las actividades en los procesos de desarrollo de software.

b)

Los miembros de los equipos de desarrollo de software van realizando aportes (ideas) útiles para mejorar los procesos y ayudar a la GC, estos son discutidos y analizados en cada reunión del ECG.

c)

Los aportes (ideas) brindados por miembros de equipos, después de ser analizados y ser considerados contribución importante para la GC; han sido introducidos en las prácticas y procesos de desarrollo de software.

71

Diagrama

" &

(

) '

! "

Figura 17. Actividades de la etapa Difusión35

Actividades a) Enseñar a la organización lo aprendido en la etapa de Instrucción conforme al propósito y al contenido las áreas del nivel dos de CMMI. b) Entrenar lo aprendido acorde a los objetivos y prácticas del nivel dos de CMMI. c) Obtener retroalimentación de los miembros de los equipos de desarrollo.

Estas actividades se muestran con detalle en el Anexo A.4.

35

Fuente: Elaboración propia

72

1.16.Utilización La etapa de utilización, se refiere a utilizar y aplicar los nuevos conocimientos creados o adquiridos en las etapas de Instrucción y Difusión, para los autores (Probst, G. et al, 2001), una de las funciones de la GC es asegurar que la organización utilice su conocimiento puesto que, si no se aplica, el conocimiento no tiene valor, ya que es aquí donde el conocimiento se transforma en resultados concretos.

Para (Desouza, K. et al., 2005), el aprendizaje alrededor de los proyectos software no es una opción, sino una obligación para la sobrevivencia organizacional. Agregan que la reutilización de conocimiento es apropiada en el desarrollo de software, pero que el conocimiento anterior debe reutilizarse para mejorar las operaciones futuras y para no repetir errores cometidos en el pasado.

Para la utilización y aplicación de conocimientos creados o adquiridos en las etapas anteriores y en las posteriores, el área de proceso de CMMI Gestión de la configuración CM será de gran ayuda para mantener el repositorio de conocimiento de la organización y de los procesos de las personas que han trabajado en los proyectos, ya que toda la documentación, artefactos o productos que se realizan en la organización, deben ser almacenado en un repositorio que sea controlado y de este repositorio tomarán las últimas versiones de los procesos, gestionando el conocimiento organizacional.

Un ambiente controlado permite entre otras cosas, saber que se tiene, que ha ocurrido con correcciones o cambios realizados en fechas anteriores, control de versiones, quien tiene o quien aporto con determinada información, resguardar y mantener organizado de mejor manera el conocimiento que es un activo de la empresa.

Esto con la ayuda del Aseguramiento de la calidad en el proceso y producto PPQA que verifica el cumplimiento de las actividades que realizan los empleados, entre las

73

actividades que verifica es el hecho de guardar la información en el repositorio, por otra parte el proceso de seguimiento y control PMC se encarga de controlar el avance en las etapas de la metodología, evaluar y gestionar riesgos que se pueden presentar. La figura 18 muestra como CM es el repositorio de conocimiento y la relación existente entre las etapas de la metodología con las áreas del modelo CMMI.

Figura 18. CM como repositorio de conocimiento 36

Propósito El propósito de la fase de Utilización es la puesta en marcha de lo aprendido en las etapas anteriores y la utilización de las diferentes propuestas de mejora que se presentaron en la etapa de Difusión, todo el conocimiento capturado se encuentra disponible en un ambiente controlado que se rige por el área de Gestión de la configuración de CMMI.

Objetivos

a)

Utilizar el conocimiento capturado que ha sido obtenido durante la ejecución de los procesos de desarrollo a medida que desarrollan las actividades.

36

Fuente: Elaboración propia

74

b)

Utilizar los objetivos y prácticas del nivel dos de CMMI como líneas guía para la GC.

c)

Generar propuestas de mejora para la ejecución de las prácticas establecidas por el modelo CMMI.

d)

Preparar al equipo participe de SCAMPI clase B.

Criterios de entrada

a)

Los miembros del SEPG conforme al avance de la implementación de las áreas del nivel dos de CMMI; han concluyendo paulatinamente las actividades en los procesos de desarrollo de software.

b)

Los aportes (ideas) útiles para mejorar los procesos y ayudar a la GC, realizados por los miembros de equipos de desarrollo; han sido discutidos y analizados en cada reunión del ECG.

c)

Los aportes (ideas) brindados por miembros de equipos, después de ser analizados y considerados contribución importante para la GC; han sido introducidos en las prácticas y procesos de desarrollo de software.

Criterios de salida

a)

La utilización de nuevo conocimiento proveniente de las propuestas de mejora ha sido realizada.

b)

La utilización de los objetivos y prácticas del nivel dos de CMMI como líneas guía para la GC ha sido ejecutada.

c)

La generación de nuevas propuestas para mejorar los procesos y ayudar a la GC, realizados por los miembros de equipos de desarrollo; han sido discutidos y analizados en cada reunión del ECG.

d)

Las propuestas de mejora a los procesos, se han analizado y considerado para ser introducidos en las prácticas y procesos de desarrollo de software.

e)

El equipo y recursos para la evaluación SCAMPI clase B están preparados.

75

Diagrama

* +

* %% "

) "

&

& %%

! "

Figura 19. Actividades de la etapa Utilización 37

Tareas

a)

Utilizar el conocimiento capturado que ha sido obtenido durante la ejecución de los procesos de desarrollo.

b)

Utilizar los objetivos y prácticas del nivel dos de CMMI como líneas guía para la GC. Mediante el proceso de PPQA (revisar 3.3.4, figura 16), se verificará el cumplimiento de actividades lo que ayudará a determinar que está aprendiendo la organización. Ver Anexo B.4.

c)

Generar propuestas de mejora para la ejecución de las prácticas establecidas por el modelo CMMI.

e)

Preparar la PIIDB para la participación del equipo en la evaluación SCAMPI clase B.

Estas actividades se muestran con detalle en el Anexo A.5.

37

Fuente: Elaboración propia

76

1.17.Evaluación Cuantitativa Para que en las empresas el conocimiento pueda ser gestionado de manera correcta y puedan alcanzar cierto nivel de madurez cuando las áreas de proceso sean correctamente implementadas, deben alcanzarse los objetivos definidos, que a su vez se consiguen mediante la implementación de las prácticas de cada objetivo.

La Figura 16 muestra un ejemplo genérico de calificación de las prácticas y las áreas del proceso de Aseguramiento de la calidad de proceso y producto (PPQA), en función de las evidencias encontradas.

Figura 20. Ejemplo de evaluación de las prácticas del área de proceso PPQA 38

Propósito El propósito de la etapa de Evaluación cuantitativa es realizar la evaluación que tendrá como referencia el método SCAMPI clase B y será aquí donde se evalúa la aplicación correcta de las prácticas y objetivos de CMMI, y a la vez determina qué y cuanto aprendió la organización; identificando además fortalezas y oportunidades de mejora, que serán útiles en la posterior y final etapa que es la Evaluación. 38

Fuente: Javier Garzás Parra, Guía práctica de supervivencia en una auditoría CMMI

77

Objetivos

a)

Evaluar los procesos de desarrollo de software que se realizan mediante SCAMPI clase B.

b)

Identificar fortalezas y oportunidades de mejora para la GC.

c)

Informar a la organización cuales han sido fortalezas y oportunidades de mejora para la GC.

Criterios de entrada

a)

El nuevo conocimiento proveniente de las propuestas de mejora ha sido utilizado.

b)

Los objetivos y prácticas del nivel dos de CMMI han sido utilizados como líneas guía para la GC.

c)

El proceso iterativo de las tres etapas (Instrucción, Difusión y Utilización) ha finalizado.

Criterios de salida

a)

La evaluación de los procesos de desarrollo de software mediante SCAMPI clase B ha sido realizada.

b)

Las fortalezas y oportunidades de mejora para la GC, han sido identificadas.

c)

Las fortalezas y oportunidades de mejora para la GC, han sido informadas a la organización.

78

Diagrama

Evaluación SCAMPI clase B

Identificar las fortalezas y las oportunidades de mejora para la GC

Informar a la organización cuales han sido las fortalezas y las oportunidades de mejora

Figura 21. Actividades de la etapa Evaluación cuantitativa 39

Actividades

a)

Evaluar los procesos de desarrollo de software mediante SCAMPI clase B.

b)

Informar a la organización cuales han sido las fortalezas y las oportunidades de mejora.

Estas actividades se muestran con detalle en el Anexo A.6.

39

Fuente: Elaboración propia

79

1.18.Revisión

Propósito El propósito de la etapa de Revisión es de considerar todas y cada una de las observaciones (oportunidades de mejora) realizadas en la etapa de Evaluación Cuantitativa para de esta manera determinar cuáles fueron los procesos en los que se requiere una revisión para intervenir en ellos y tomar acciones para gestionarlos de la manera correcta con la finalidad de cumplir adecuadamente los mismos y así mejorar el proceso de GC en la organización.

Mediante el proceso de PPQA (revisar 3.3.4, figura 16), se verificará el cumplimiento de actividades lo que ayudará a determinar que está aprendiendo la organización.

Objetivos a) Revisar las oportunidades de mejora resultado del SCAMPI clase B. b) Tomar acciones para gestionar de manera correcta los procesos que no cumplieron con la evaluación. c) Considerar la necesidad efectuar una regresión a la etapa de Instrucción y realizar un ciclo iterativo conformado por las fases subsiguientes. d) Analizar el aprendizaje y los nuevos conocimientos logrados por los miembros de los equipos de desarrollo. e) Finalizar el proceso de GC cuando cumpla con todos los objetivos y prácticas del nivel dos de CMMI, considerando que no es necesario realizar una nueva iteración. f) Formular recomendaciones de mejora al propio proceso de GC definido por la metodología.

80

Criterios de entrada

a)

La evaluación de los procesos de desarrollo de software mediante SCAMPI clase B se ha realizado.

b)

Las fortalezas y oportunidades de mejora para la GC, se han identificadas.

c)

Las fortalezas y oportunidades de mejora para la GC, se han informado a la organización.

d)

El análisis comparativo entre los resultados de los SCAMPI C y B, ha sido realizado.

Criterios de salida a) Las acciones tomadas para gestionar de manera correcta los procesos, han sido ejecutadas e informadas. b) La consideración de efectuar o no una regresión a la etapa de Instrucción, se ha efectuado e informado. c) La finalización del proceso de GC cuando cumpla con todos los objetivos y prácticas del nivel dos de CMMI, se ha efectuado e informado. d) Las recomendaciones de mejora al propio proceso de GC, pueden ser realizadas.

81

Diagrama

Analizar las oportunidades de mejora detectadas

Identificar el conocimiento obtenido en el desarrollo de la metodolgia

Considerar la necesidad efectuar una regresión a la etapa de Instrucción

Finalizar el proceso de GC cuando cumpla con todos los objetivos y prácticas del nivel dos de CMMI

Figura 22. Actividades de la etapa Revisión 40

Actividades a) Revisar las oportunidades de mejora resultado del SCAMPI clase B. b) Tomar acciones para gestionar de manera correcta los procesos que no cumplieron con la evaluación. c) Identificar el conocimiento obtenido y aprendieron por miembros de los equipos de desarrollo, y la organización en general. d) Considerar la necesidad efectuar una regresión a la etapa de Instrucción. e) Finalizar el proceso de GC cuando cumpla con todos los objetivos y prácticas del nivel dos de CMMI Estas actividades se muestran con detalle en el Anexo A.7.

40

Fuente: Elaboración propia

82

1.19. Material complementario de la metodología propuesta En la sección de Anexos se encuentran y se exponen los “Templates” pertenecientes a las etapas de la metodología propuesta, que fueron mencionados sin mayor detalle en las descripciones anteriores, estos Templates son:

1. Template de la Etapa 1. Definición (E1D). 2. Template de la Etapa 2. Evaluación Inicial (E2EI). 3. Template de la Etapa 3. Instrucción (E3I). 4. Template de la Etapa 4. Difusión (E4D). 5. Template de la Etapa 5. Utilización (E5U). 6. Template de la Etapa 6. Evaluación cuantitativa (E6EC). 7. Template de la Etapa 7. Revisión (E7R).

Los esquemas de descripción contienen los siguientes elementos: •

Propósito: descripción del propósito de la etapa.

•

Actividades: se presenta un listado de las actividades junto con el gráfico de flujo de las tareas de la etapa. Descripción de la actividad: descripción detalla de la actividad junto con las

•

reseñas teóricas necesarias para una comprensión cabal del proceso. Entradas y Salidas: descripción de todos los insumos y productos de la fase. Descripción de todas las entradas y salidas de la fase. Las entradas son los artefactos necesarios para realizar las actividades de la etapa. Las salidas son los resultados a obtener como consecuencia de las actividades realizadas en la etapa. •

Responsables y Participantes: Personas o grupos encargados de llevar acabo las actividades.

83

1.20.

Resultados obtenidos de las evaluaciones realizadas

A continuación se presenta los resultados de las Evaluaciones Inicial y Cuantitativa (SCAMPI C y B respectivamente) realizadas en cuatro PyMES; dichos resultados fueron procesados mediante cuadros comparativos entre las áreas del nivel dos de CMMI y sus respectivas prácticas específicas. 1.21.Resultado global de evaluaciones de las áreas de proceso del nivel dos de CMMI.

Empresa 1

Empresa 2

Empresa 3

Empresa 4

Áreas de procesos del nivel dos de CMMI

SCAMPI C

SCAMPI B

SCAMPI C

SCAMPI B

SI cumple

SCAMPI B

2

SCAMPI C

Cumple parcial

SCAMPI B

NO cumple

1

SCAMPI C

0

Gestión de requerimientos

1

1

1

1

1

1

1

1

Planificación del proyecto

1

2

1

2

1

2

1

2

Monitoreo y control

0

1

1

2

0

1

1

2

Aseguramiento de la calidad de proceso y de producto

0

2

0

2

0

1

0

2

Gestión de la configuración

1

2

1

2

0

1

1

2

Medición y análisis

0

1

0

1

0

1

0

2

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

Acuerdo con proveedores

Tabla 15. Resultado global de evaluaciones 41

41

Fuente: Elaboración propia

84

Figura 23. Resultado de evaluaciones áreas de procesos

42

85

Fuente: Elaboración propia

42

1.22.Resultados de la evaluación del área de proceso Gestión de requerimientos

0

NO cumple

1

Cumple parcial

2

SI cumple

SP

Prácticas Específicas

SCAMPI B

SCAMPI C

SCAMPI B

SCAMPI C

SCAMPI B

SCAMPI C

SCAMPI B

SG1 Administrar Requerimientos

Metas Genéricas

Empresa Empresa Empresa Empresa 1 2 3 4 SCAMPI C

GESTIÓN DE REQUERIMIENTOS

1.1

Obtener una comprensión de los requerimientos.

2

2

2

2

2

2

2

2

1.2

Obtener compromiso con los requerimientos.

1

1

1

2

1

1

1

1

1

1

1

1

0

1

1

2

0

2

0

1

0

0

0

1

1

1

0

1

0

0

1

1

Administrar los cambios a 1.3 los requerimientos. Mantener Trazabilidad 1.4 bidireccional de los Requerimientos. Identificar inconsistencias 1.5 entre proyectos, trabajos y requerimientos.

Tabla 16. Resultado de evaluaciones Gestión de requerimientos 43

43

Fuente: Elaboración propia

86

Figura 24. Resultado de evaluaciones Gestión de requerimientos 44

44

87

Fuente: Elaboración propia

1.23. Resultados de la evaluación del área de proceso Planificación del proyecto

0

NO cumple

1

Cumple parcial

2

SI cumple

2.2

Plan para Administración de Datos. Plan para recursos del 2.4 proyecto. Plan para conocimiento de 2.5 habilidades necesitadas. Plan para involucrar a 2.6 terceros. 2.3

SG2 Desarrollar un Plan de Proyectos

Identificar riesgos del proyecto.

SCAMPI B

2.1

SCAMPI C

1.4

SCAMPI B

1.3

SCAMPI C

SG1 Establecer Estimaciones

1.2

Definir el ámbito del proyecto. Establecer estimaciones de productos de trabajo y atributos de tareas. Definir el ciclo de vida del proyecto. Determinar estimaciones de tiempo y costo. Establezca el Presupuesto y la Carta Gantt.

SCAMPI B

1.1

Prácticas Específicas

SCAMPI C

SP

SCAMPI B

Metas Genéric as

Empresa Empresa Empresa Empresa 1 2 3 4 SCAMPI C

PLANIFICACIÓN DE PROYECTOS

1

1

1

2

1

1

1

1

1

1

1

1

1

2

1

1

0

1

1

1

1

1

1

2

1

1

1

1

1

1

1

1

2

2

2

1

2

2

2

2

0

0

1

2

0

2

0

2

1

1

1

2

1

1

1

1

0

1

1

1

1

1

1

2

0

0

0

1

0

2

1

2

0

0

1

2

1

1

1

2

88

Establecer plan de proyecto. Revisar otros planes 3.1 que afecten al proyecto. Conciliar trabajos con 3.2 los recursos.

SG3 Obtener compromiso con el

2.7

3.3

Obtener compromiso con el plan.

1

2

1

2

1

2

1

2

0

1

1

1

0

0

1

1

1

1

1

1

0

1

1

1

1

1

1

1

0

1

1

1

Tabla 17. Resultado de evaluaciones Planificación del proyecto 45

45

Fuente: Elaboración propia

89

Figura 25. Resultado de evaluaciones Gestión de requerimientos 46

46

90

Fuente: Elaboración propia

1.24.Resultados de la evaluación del área de proceso Monitoreo y control del proyecto

SG2 Administrar acciones correctivas

1.5

Conducir revisiones de avance Conducir 1.7 Revisiones de hitos. 1.6

2.1 Analizar problemas Tomar acciones correctivas. Administrar 2.3 acciones correctivas. 2.2

SCAMPI C

SCAMPI B

1.4

SCAMPI B

1.3

SCAMPI C

1.2

Monitorear parámetros del plan de proyectos. Monitorear compromisos. Monitorear los Riesgos del Proyecto. Monitorear la Administración de Datos Monitorear involucramiento de terceros.

Empresa 4

SCAMPI B

SG1 Monitorear el proyecto contra el Plan

1.1

Prácticas Específicas

Empresa 3

SCAMPI C

SP

Empresa 2

SCAMPI B

Metas Genéricas

Empresa 1 SCAMPI C

MONITOREO Y CONTROL DEL PROYECTO

1

1

1

1

1

1

1

2

1

1

1

1

1

1

1

2

0

1

1

1

0

1

1

1

1

1

1

2

1

1

0

2

1

1

2

1

1

1

2

1

1

1

2

1

2

0

1

2

2

2

1

1

1

1

2

1

1

1

1

1

1

1

1

1

1

2

1

1

1

1

1

1

1

2

1

Tabla 18. Resultado de evaluaciones Monitoreo y control 47

47

Fuente: Elaboración propia

91

Figura 26. Resultado de evaluaciones Monitoreo y control 48

48

92

Fuente: Elaboración propia

1.25.Resultados de la evaluación del área de proceso Aseguramiento de la calidad de proceso y producto 0

NO cumple

1

Cumple parcial

2

SI cumple

SCAMPI B

SCAMPI C

SCAMPI B

2.2 Establecer Registros.

SCAMPI C

Evaluar el proceso objetivamente. Evaluar objetivamente 1.2 productos de trabajo y servicios Comunicar y asegurar 2.1 resolución de incumplimientos. 1.1

Empresa 4

SCAMPI B

Prácticas Específicas

Empresa 3

SCAMPI C

SP

Empresa 2

SCAMPI B

SG1 SG2 Proveer una Evaluar visión objetiva objetivamente procesos y

Metas Genéricas

Empresa 1 SCAMPI C

ASEGURAMIENTO DE CALIDAD DE PROCESO Y DE PRODUCTO

0

1

0

2

0

1

0

2

0

1

0

2

0

1

0

1

0

2

0

2

0

2}

0

2

0

2

0

2

0

2

0

2

Tabla 19. Resultado de evaluaciones Aseguramiento de la calidad 49

49

Fuente: Elaboración propia

93

Figura 27. Resultado de evaluaciones Aseguramiento de la calidad 50

50

94

Fuente: Elaboración propia

1.26.Resultados de la evaluación del área de proceso Gestión de la configuración

0

NO cumple

1

Cumple parcial

2

SI cumple

SCAMPI B

Controlar ítems de configuración. Establecer registros 3.1 de administración de configuración. Ejecutar auditoria 3.2 de configuración. 2.2

SCAMPI C

Seguir solicitudes de cambio.

SCAMPI B

2.1

SCAMPI C

Identificar ítem de 1.1 administración de configuración. Establecer sistema 1.2 de administración de configuración. Crear o liberar 1.3 líneas bases.

Empresa 4

SCAMPI B

Prácticas Específicas

Empresa 3

SCAMPI C

SP

Empresa 2

SCAMPI B

SG3 Establecer Integridad

SG2 Seguir y controlar cambios

SG1 Establecer líneas bases

Metas Genéricas

Empresa 1 SCAMPI C

GESTIÓN DE LA CONFIGURACIÓN

0

0

1

1

1

1

2

1

0

1

1

2

0

2

2

2

1

1

1

2

0

1

1

1

1

2

2

2

1

1

1

2

0

0

1

1

1

1

1

2

1

2

0

1

0

2

0

1

0

0

1

1

0

0

0

2

Tabla 20. Resultado de evaluaciones Gestión de la configuración 51

51

Fuente: Elaboración propia

95

96

Figura 28. Resultado de evaluaciones Gestión de la configuración 52

52

97

Fuente: Elaboración propia

1.27.Resultados de la evaluación del área de proceso Medición y análisis

0

NO cumple

1

Cumple parcial

2

SI cumple

SP

Prácticas Específicas

SCAMPI C

SCAMPI B

SCAMPI C

SCAMPI B

Empresa 4

SCAMPI B

Empresa 3

SCAMPI C

Empresa 2

SCAMPI B

SG2 SG1 Proveer resultados de las Alinee actividades de medidas medidas y análisis

Metas Genéricas

Empresa 1 SCAMPI C

MEDICIÓN Y ANÁLISIS

1.1

Establecer objetivos de medidas.

0

1

0

1

0

1

0

2

0

2

0

2

0

2

0

2

0

1

1

2

0

1

0

1

0

1

1

1

0

0

0

2

0

2

1

2

0

1

0

2

1.2 Especificar medidas. Especificar procedimiento de 1.3 recopilación de datos y almacenamiento. Especificar 1.4 procedimiento de análisis. Recopile Datos para 2.1 Medidas. 2.2

Analizar datos de medidas.

0

1

1

2

0

1

0

2

2.3

Almacenar datos y resultados.

0

1

1

2

0

1

0

2

2.4 Comunicar Resultados.

0

1

0

1

0

1

0

1

Tabla 21. Resultado de evaluaciones Medición y análisis 53

53

Fuente: Elaboración propia

98

Figura 29. Resultado de evaluaciones Medición y análisis 54

54

Fuente: Elaboración propia

99

CONCLUSIONES Como resultado de la investigación realizada en el presente trabajo, se puede concluir lo siguiente: •

La metodología propuesta sustenta los diferentes procesos para la gestión del conocimiento, según la definición de (Gupta y Sharma, 2004), quien considera que la GC es una colección de procesos que gobiernan la creación, diseminación, y utilización de conocimiento.

•

La metodología desarrollada, está conformada por siete etapas que respalda las actividades para gestionar el conocimiento; la metodología fue elaborada y basada en el proceso de implementación del nivel dos de CMMI, cumpliendo de esta manera con el objetivo planteado y la hipótesis H1 “En una organización que implemente el nivel dos de CMMI apoyados en la teoría de gestión del conocimiento se logrará utilizar el proceso de implementación para elaborar o establecer una metodología para la captura y utilización del conocimiento con elementos de gestión del conocimiento.”.

•

La metodología propuesta considera los procesos de conversión y creación de conocimiento organizacional, según el modelo SECI de Nonaka y Takeuchi: Socialización (conocimiento tácito a tácito), se muestra en la etapa de Instrucción, en las reuniones con el SEPG donde se comparte e intercambia conocimiento, ideas, opiniones y experiencias, que se han realizado durante la ejecución de actividades de desarrollo de software. Externalización (conocimiento tácito a explícito), se demuestra en la etapa de Instrucción, en las reuniones con el SEPG luego de compartir intercambiar conocimiento, ideas, opiniones y experiencias éstas son plasmadas o capturadas en actas y templates; y también en la etapa de Difusión cuando se realizan propuestas de mejora a los procesos. Combinación (conocimiento explícito a explícito), se presenta en la etapa de 100

Difusión donde se toma el conocimiento que ha sido capturado para compartirlo y transmitirlo a la organización (templates, documentos, material de talleres); y también en la etapa de Utilización cuando se realizan propuestas de mejora, o cuando existe reformulación de conocimiento que debe ser ajustado al nuevo conocimiento que se incorpore' Internalización (conocimiento explícito a tácito), se muestra en la etapa de Utilización cuando los miembros de los equipos de desarrollo empiezan a utilizar los nuevos conocimientos creados o

aprendidos en etapas anteriores en la

ejecución de sus actividades. •

Con base en los resultados de las etapas de la metodología, Evaluación inicial y Cuantitativa, en las cuatro PyMES se evidenció mejoras en todas las áreas de procesos, destacando Medición y análisis y Aseguramiento de la calidad en producto y proceso; de forma particular Gestión de requerimientos no presentó ningún cambio, se mantuvo en el mismo estado (ver detalle en Figura 23).

•

Las cuatro PyMES tuvieron que dar apertura a nuevos procesos y un rol, los procesos que se instituyeron son Medición y análisis y Aseguramiento de la calidad en producto y proceso; y se creó el rol de PPQA, el cual tiene como misión revisar el cumplimiento de las actividades del resto de procesos. La hipótesis H2 “Al establecer procedimientos para la captura y utilización del conocimiento, se mejorará el proceso de desarrollo de software en PyMES”, se da por validada en este punto.

•

El progreso de aprendizaje en las PyMES se refiere a la institucionalización de los procesos, el cual se mide a través del Área de proceso de CMMI, Aseguramiento de la calidad de proceso y de producto PPQA y con las etapas de Evaluación inicial y Cuantitativa de la metodología (SCAMPI C y B).

•

La metodología consta de dos ciclos iterativos donde el primero incluye las etapas de Instrucción, Difusión y Utilización, el segundo será utilizado cuando NO se ha logrado cumplir con todas las prácticas del nivel dos de CMMI, siendo en la etapa de Revisión donde se considera efectuar una nueva iteración.

101

•

La metodología implica cambios en la forma de llevar a cabo las tareas de desarrollo de software lo que puede provocar repercusión o fracaso; por lo que la resistencia al cambio podría ser un riesgo en la implantación de la misma.

•

El tiempo estimado para llevar a cabo la metodología es entre diez y doce meses dependiendo de la organización y la frecuencia con la que desarrollan proyectos de software, pues es necesario contar con al menos tres proyectos para poder realizar la mayoría de actividades, definidas en cada etapa.

•

La PIIDB puede ser considerada como una herramienta útil para realizar el levantamiento del conocimiento individual y organizacional existente en las PyMES dedicadas al desarrollo de software mediante un análisis comparativo de las prácticas del nivel dos de CMMI con relación a la manera de llevar a cabo las prácticas actuales; durante el desarrollo de la metodología se ha logrado determinar ciertos ejemplos de artefactos utilizados para mostrar la trazabilidad de las prácticas del modelo a las áreas de proceso correspondientes y a las evidencias objetivas usadas para verificar la implementación de la práctica. Ver detalle en Anexo B.5.

•

En las PyMES existe multifuncionalidad de roles, motivo por el cual el personal tiene tiempo limitado para realizar sus actividades, dichas particularidades demandan de un verdadero compromiso para llevar a cabo la implantación de la metodología, debido a que se requiere de tiempo lo que implica en algunos casos reasignar las funciones de algunas personas.

102

BIBLIOGRAFÍA

Alavi. M. y Leidner D. (2001). “Knowledge management and knowledge management systems: conceptual foundations and research issues”. MIS Quarter/v. 25 (1). 107-136. Argyris, C.: Double loop learning in organizations, Harvard Business Review, 55 (5), 1977, pp. 115-125. Batista, A. S. (2010), Materiales de Capacitación PMC en la Universidad de las Ciencias Informáticas Bergeron, Bryan. Essentials of knowledge Management. II Serie. Hoboken, New Jersey. John Wiley & Sons, Inc. 2003. 208 p. (Essentials series). Birch, David L. (1979), The Job Generation Process. Cambridge, Program on Neighborhood and Regional Change. Bossen, Claus (2005), Conceptualization and Appropriation: The Evolving Use of a Collaborative Knowledge Management System. Recuperado de: http://dl.acm.org/citation.cfm?doid=1094562.1094574 Brualla, C. R. (2003), CMMI: Mejora del Proceso de Fábricas de Software. 2003. Choudrie, J., Selamat, M.: The consideration of meta abilities in tacit knowledge externalization and organizational learning, Proceedings of the 39th Hawaii International Conference on System Sciences, 2006, p. 149 CMMI® para Desarrollo, Versión 1.3, 2010. Davenport, T., Prusak, L.: Working knowledge. How organizations manage what they know, Boston, Harvard Business School Press, 1998 Dayan, Rony. (2006). Km your way to CMMI. Recuperado de: https://dspace.lib.cranfield.ac.uk/bitstream/1826/1155/3/KM%2520Your%2520Way%2 520to%2520CMMI-2006.pdf Desouza, K., Dingsoyr, T., Awazu Y.: Experiences with conducting project postmortems, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005, p. 233

103

Dingsoeyr, T., & Conradi, R. (2002). A Survey of Case Studies of the Use of Knowledge Management in Software Engineering. International Journal of Software Engineering and Knowledge Engineering, 12 (4), 391-414 Drucker, Peter (1969), La era de la discontinuidad, Recuperado de: http://es.scribd.com/doc/25224659/Peter-Drucker Falbo, R., Pezzin, J., Schwambach,M. (2005), A multiagent system for knowledge delivery in a software engineering environment, 17th International Conference on Software Engineering and Knowledge Engineering. Forradellas, Patricia (NA), El modelo CMM/CMMI - Cómo garantizar el éxito del proceso de mejoras en las organizaciones, superando los conflictos y tensiones generados por su implementación. Recuperado de: http://www.it-mentor.com.ar/pdf/CMMCulturaOrg.pdf Fowler, Priscilla; Rifkin, Stanley (1990). "Software Engineering Process Group Guide". CMU/SEI-90-TR-024. Carnegie Mellon University. Retrieved 2009-09-05. Gottschalk, P.: Strategic knowledge management technology, Harshey, Idea Group, 2004 Gupta, J., Sharma, S.: Creating knowledge-based organizations. Recuperado de: http://books.google.cl/book Handzic, M., (2003), Why it is important to manage knowledge. En Aurum, A. et al.: Managing software engineering knowledge, Berlin, Springer-Verlag Hernández, Fernández y Baptista, 2000 Hernández, R; Fernández C; Baptista P.: “Metodología de la investigación”, Graw-Hill, México, 2000.Graw-Hill, México, 2000 Huysman, M.: Organizational learning and communities of practice. A social constructivist perspective, Proceeding of the 3rd European Conference on Organizational Knowledge, Learning and Capabilities, Athens, Greece, 2002 IEEE Standard Glossary of Software Engineering Terminology. 1990. Garzás Parra, Javier; Emanuel A. Irrazábal; Roberto Santa Escolástica, Guía práctica de supervivencia en una auditoría, 2011. Recuperado de: http://www.etsii.urjc.es/investigacion/archivos/BoletinETSII-2011-002.pdf

104

Joglar, Hernán et al. (2008). “Gestión del conocimiento un resumen teórico orientado a la aplicación en la práctica empresarial” Malvicino, D. S. La gestión del conocimiento y la mejora de los sistemas de gestión integrados. Recuperado de: http://www.gestiopolis.com/administracion-estrategia/gestion-conocimiento-sistemasintegrados.htm Maya, Kaner. (2004). A Capability Maturity Model for Knowledge-Based Decision making. Recuperado de: http://iospress.metapress.com/content/c2n218b46pjybrnn Nonaka, I. y Takeuchi, H. (1995). The Knowledge-Creating Company. University Press Perez, Javier (2010), Liderazgo. Modelo SECI: Gestión del conocimiento. Recuperado de: http://javiersole.com/?p=1612 Pressman 1998] PRESSMAN, Roger. “Ingeniería de Software” México, Mc Graw-Hill, 4ta edición, 1998. Priscilla; Rifkin, Stanley (1990). "Software Engineering Process Group Guide". CMU/SEI-90-TR-024. Carnegie Mellon University. Retrieved 2009-09-05. Probst, G., Raub, S., Romhardt, K., Administre el conocimiento, México, Pearson, 2001 Quintas, P., Lefrere, H., Jones, G., Knowledge management: A strategic agenda, Long Range Planning, Vol. 30, Nº 3, 1997, pp. 385-391 Quiroga, Jorge (2007), Gestión de Conocimiento en Grupos de Desarrollo de Software. Recuperado de: http://paradigma.uniandes.edu.co/media/articulos/jor-quir-1.pdf Ramanujan, Sam (2004). Comparison of knowledge management and CMM / CMMI Implementation. Recuperado de: http://www.umsl.edu/~lacitym/cmm2.pdf Ramirez, Dariena The use of knowledge management and decision making in the project monitoring and control (PMC) process area of CMMI. Recuperado de: http://www.deepdyve.com/lp/ios-press/a-capability-maturity-model-for-knowledgebased-decisionmaking-V02efLwe08

105

Rodríguez, I. O. Origen y actualidad de la gestión del conocimiento. 2011. Recuperado de: http://www.gestiopolis.com/dirgp/adm/gestionconocimiento.htm Salazar, A. A. Modelo de implantación de Gestión del Conocimiento y Tecnologías de Información para la Generación de Ventajas Competitivas. Valparaíso. 2000 Sam Ramanujan; Someswar Kesh; Comparison of Knowledge Management and CMM/CMMI Implementation, Journal of American Academy of Business, Cambridge; Mar 2004; 4, 1/2; ABITNFORM Global Shari, Shang. (2009). Understanding the effectiveness of Capability Maturity Model Integration by examining the knowledge management of software development processes. Recuperado de: http://www.tandfonline.com/doi/abs/10.1080/14783360902863671#.UbZOm_k9-So Skyrme, David J. (1997), Knowledge Management Solutions - The IT Contribution. Recuperado de: http://skyrme.com/kmarticles/acm0398.pdf Sommerville, I (1996), Software Engineering, Addison Wesley. Recuperado de: http://dl.acm.org/citation.cfm?id=211474 Szulanski G. “The process of knowledge transfer: a diachronic analysis of stickiness”. Organizational Behaviour and Human Decision Processes, Vol. 82 (1). 2000, p. 9-27. Szulanski, G. “Exploring Internal Stickiness: Impediments to the transfer of best prectice within the firm”. Strategic Management Journal, Vol. 17. 1996, p. 27-43. Vanegas, I. C. La relevancia y alcance de la gestión del conocimiento, 2009. Recuperado de: http://www.gestiopolis.com/administracion-estrategia/relevancia-y-alcance-de-lagestion-del-conocimiento.htm

106

Wiig KM y Jooste A (2003) Exploiting knowledge for productivity gains. In Handbook on Knowledge Management: Volume 2: Knowledge Directions (HOLSAPPLE CW, Ed), pp 289–308, Springer-Verlag, Berlin/Heidelberg Wiig. K. (1993). Knowledge management foundations, Arlington, Texas, Schema Press, 1993 Yunwen Ye (2006), Supporting Software Development as Knowledge-Intensive and Collaborative Activity. Recuperado de: http://www.irisa.fr/lande/lande/icse-proceedings/wiser/p15.pdf

107

ANEXOS

ANEXO A - Templates de la metodología propuesta........................................................ 1 A.1. Definición ........................................................................................................... 1 A.2. Evaluación Inicial ............................................................................................... 6 A.3. Instrucción ....................................................................................................... 10 A.4. Difusión ............................................................................................................ 15 A.5. Utilización ........................................................................................................ 20 A.6. Evaluación Cuantitativa ................................................................................... 26 A.7. Revisión............................................................................................................ 30 ANEXO B – Documentos para la realización de las actividades .................................... 35 B.1. Template “Acta de reuniones”.......................................................................... 35 B.2. Template “Plan de difusión” ............................................................................ 37 B.3. Template “Cronograma de actividades” ........................................................... 41 B.4. Template “Revisiones de PPQA” ..................................................................... 42 B.5. Template de la “PIIDB” ................................................................................... 43 ANEXO C - Templates de las áreas del nivel dos de CMMI .......................................... 53 C.1. Gestión de requerimientos ................................................................................ 53 C.1. Planificación del proyecto ................................................................................ 65 C.3. Aseguramiento de la calidad en productos y procesos ..................................... 77 C.4. Monitoreo y control del proyecto ..................................................................... 81 C.5. Medición y análisis ........................................................................................... 90 C.6. Administración / Gestión de la configuración .................................................. 95

ANEXO A - Templates de la metodología propuesta

A.1. Definición Definición general de la etapa

Etapa

Etapa 1. Definición (E1D)

Categoría

Definición (equipo de trabajo, punto de partida)

Propósito

El propósito de la etapa de Definición es establecer las bases para la puesta en marcha de la metodología (cronograma de actividades, plan de difusión), conformar el SEPG; y revisión preliminar de áreas del nivel dos de CMMI.

Objetivos

a) Conformar el equipo de trabajo responsable de llevar a cabo el proceso GC, éste equipo será llamado Grupo de procesos de Ingeniería de Software, que en adelante será mencionado como SEPG. b) Analizar las áreas, objetivos y prácticas del nivel dos de CMMI en las que se va a trabajar. c) Asignar roles y compromisos para la ejecución de las siguientes etapas de la metodología. d) Definir la periodicidad de las reuniones de trabajo del SEPG (recomendable una vez por semana)

Responsables

Actividades

•

Gerente

•

SEPG

A1. Conformar el Equipo de Gestión del Conocimiento (SEPG) A2. Revisar y analizar las áreas, objetivos y prácticas del nivel dos de CMMI, para la puesta en marcha de la metodología. A3. Elaborar un cronograma de actividades.

1

A4. Informar a toda la organización que se va a llevar el proceso de GC, principalmente al personal inmerso en actividades de desarrollo de software. Procesos de Nombres de los procesos relacionados.

CMMI relacionados

Descripción de actividades

A1. Conformar el Grupo de Procesos de Ingeniería de Software SEPG Responsable

Gerente o delegado

Participantes Gerente o delegado, representantes de equipos de desarrollo • Documento de Gerencia con la aprobación para el inicio de la metodología. Entradas

• Toda otra documentación que apoye al desarrollo de esta actividad. El SEPG es responsable de la puesta en marcha y ejecución de la metodología; sus miembros serán los encargados de desarrollar planes para implementar las mejoras necesarias, coordinar y controlar la ejecución de esos planes, además de aprender, extraer, enseñar y utilizar

Descripción

el conocimiento entre el personal involucrado en los procesos.

EL SEPG es un equipo multidisciplinario que debe incorporar a personas con habilidades y conocimientos en desarrollo de software como también personas que sepan gestión del conocimiento. Salidas

•

Herramientas •

Documento de “Conformación del SEPG” o Acta de reuniones Template de “Acta de reuniones”

2

A2. Revisar y analizar las áreas, objetivos y prácticas del nivel dos de CMMI Responsable

SEPG

Participantes SEPG, Jefes de proyectos Entradas

•

Modelo CMMI (Nivel 2)

•

Teoría de gestión del conocimiento (introducción)

El objetivo de esta actividad es realizar un pequeña introducción en los temas referentes al modelo CMMI y a gestión del conocimiento con la Descripción

finalidad de que el SEPG conozca de mejor manera lo que se pretenden efectuar, además se asignan roles y compromisos para la ejecución de las siguientes etapas de la metodología.

Salidas

• Template “Acta de reuniones”

Herramientas •

Template de “Acta de reuniones”

•

Modelo CMMI versión1.3

•

Teoría de gestión del conocimiento.

A3. Elaborar cronograma de actividades Responsable

SEPG

Participantes SEPG Entradas

•

Modelo CMMI (Nivel 2)

•

Acta de reuniones donde se establecieron roles y compromisos

El objetivo de esta actividad es establecer las actividades, recursos y tiempos en los cuales se llevará a cabo la implementación de nivel dos Descripción

de CMMI, para establecer una forma ordenada y coordinada de ejecución de las distintas actividades que la implementación involucra (recursos físicos, quien prepara material, equipos a usar, lugar de entrenamientos, etc.)

Salidas

• Template “Cronograma de actividades”

3

Herramientas •

Template de “Acta de reuniones”

•

Modelo CMMI (Nivel 2)

•

Cronograma de actividades

A4. Informar a la organización el inicio de la implementación Responsable

SEPG, Secretarias

Participantes SEPG Entradas

•

Cronograma de actividades.

Informar a toda la organización que se va a llevar a cabo el proceso de implementación de CMMI nivel 2, principalmente al personal inmerso Descripción

en actividades de desarrollo de software. Es importante la inclusión de todo el personal ya que estas actividades serán adoptadas en sus labores habituales de trabajo o de desarrollo de software.

Salidas

• Template “Plan de Difusión”

Herramientas • •

Template de “Acta de reuniones” Cronograma de actividades

4

1.28.Diagrama de flujo de la Etapa 1. Definición

, -& & % .1

./

%% 20

0

, -& , -& ) %%

/

"

./

0

&

&

)

) ./

)

0

./

0

Figura 23. Diagrama de flujo de actividades Etapa 1 Definición

5

A.2. Evaluación Inicial

Definición general de la etapa

Etapa

Etapa 2. Evaluación Inicial (E2EI)

Categoría

Evaluación SCAMPI C

Propósito

El propósito de esta etapa es realizar una evaluación basada en el método SCAMPI clase C, esta evaluación permitirá conocer el cumplimiento de los objetivos y prácticas del nivel dos de CMMI, determinando el estado de los procesos de GC y desarrollo de software, para poder abordar la situación y establecer las bases para la puesta en marcha de la metodología.

Objetivos

a) Evaluar los procesos mediante el método SCAMPI clase C. b) Identificar, evaluar las posibles falencias u oportunidades de mejora en función de los conocimientos de los miembros de los equipos de trabajo respecto de las tareas de desarrollo de software. c) Informar los resultados a la empresa. Identificar empleados “clave” quienes poseen conocimiento tácito, para involucrarlos en las reuniones de trabajo con el SEPG.

Responsables

Actividades

•

Consultor externo

•

SEPG

A1. Conformar el Equipo de Gestión del Conocimiento (SEPG) A2. Revisar y analizar las áreas, objetivos y prácticas del nivel dos de CMMI, para la puesta en marcha de la metodología. A3. Elaborar un cronograma de actividades. A4. Informar a toda la organización que se va a llevar el proceso de GC, principalmente al personal inmerso en actividades de

6

desarrollo de software. Procesos de Nombres de los procesos relacionados.

CMMI relacionados

Descripción de actividades

A1. Ejecutar evaluación SCAMPI clase C Responsable

Consultor externo

Participantes

•

SEPG

•

Jefes de proyectos

•

Desarrolladores.

• Método SCAMPI Entradas La ejecución de la evaluación SCAMPI clase C proporciona un análisis rápido de las deficiencias encontradas en la organización en relación con el nivel dos de CMMI.

Descripción

Determina además el estado de los procesos de GC y de desarrollo de software para las siguientes etapas de la metodología, colaborando de esta manera a establecer las bases para la puesta en marcha de la metodología.

Salidas

•

Resultados de evaluación

•

Informe de oportunidades de mejora

Herramientas • •

Método SCAMPI Modelo CMMI (Nivel 2)

7

A2. Analizar las oportunidades de mejora. Responsable

SEPG

Participantes SEPG Entradas

•

Resultados de evaluación

•

Informe de oportunidades de mejora

•

Modelo CMMI (Nivel dos)

En base al resultado de la evaluación se debe efectuar un análisis de las oportunidades de mejora y la posible falta de conocimiento de los Descripción

miembros de los equipos de desarrollo en relación con los objetivos y prácticas de CMMI.

Salidas

•

Herramientas • •

Observaciones al Informe de oportunidades de mejora Informe de oportunidades de mejora. Modelo CMMI (Nivel 2)

A3. Identificar empleados que aporten con conocimiento tácito. Responsable

SEPG

Participantes SEPG Entradas

•

Modelo CMMI (Nivel 2)

•

Acta de reuniones donde se establecieron roles y compromisos

Con las entrevistas realizadas en la evaluación SCAMPI se puede tener noción de personal que posiblemente posea conocimiento tácito, por la Descripción

tanto la participación de estas personas será un gran aporte en el desarrollo de la metodología para la extracción del conocimiento.

Salidas

• Observaciones al Informe de oportunidades de mejora

Herramientas •

Informe de oportunidades de mejora con observaciones.

8

1.29.Diagrama de flujo de la Etapa 2. Evaluación Inicial

! %3 , %-

% .1

,

4

%-

,

%-

%% 20 '

6

, -&

" 5

Figura 24. Diagrama de flujo de actividades Etapa 2 Evaluación Inicial

9

A.3. Instrucción

Definición general de la etapa

Etapa

Etapa 3. Instrucción (E3EI)

Categoría

Instruir, entrenar y extraer conocimiento.

Propósito

El propósito de la etapa de Instrucción es empezar las reuniones con el SEPG en la implementación de las áreas del nivel dos de CMMI: Gestión de requerimientos (RQM), Planificación del proyecto (PP), Monitoreo y control del proyectos (PMC), Aseguramiento de la Calidad del Proceso y Producto (PPQA), Gestión de la Configuración (CM), y Medición y Análisis (MA).

En esta etapa se da inicio a un ciclo iterativo formado por las etapas de Instrucción, Difusióny Utilización, en este ciclo se extraen, captura, y utiliza el conocimiento. Objetivos

a) Instruir a los miembros del SEPG para que conozcan, entrenen y comprendan los procesos a llevar a cabo, de acuerdo al propósito y el contenido las áreas del nivel dos de CMMI, definidos en la etapa de Definición.

b) Extraer el conocimiento individual implícito que poseen los miembros de los equipos de trabajo los cuales serán necesarios para mejorar los procesos de desarrollo de software y GC que se llevan a cabo en el la organización.

Responsables

•

SEPG y/o Consultor externo

10

• A1. Instruir en las Áreas del nivel dos de CMMI.

Actividades

A2. Analizar y comprender los objetivos y prácticas de cada área del nivel dos de CMMI. A3. Extraer el conocimiento individual implícito de los miembros de los equipos de desarrollo

Procesos de Nombres los procesos relacionados. de

CMMI relacionados

Descripción de actividades

A1. Instruir en las Áreas del nivel dos de CMMI. Responsable

SEPG y/o Consultor externo

Participantes •

Entradas

Jefes de proyecto

•

Desarrolladores

•

Modelo CMMI (Nivel 2)

•

Cronograma de actividades

La finalidad de esta actividad es instruir al personal inmerso en actividades de desarrollo de software de tal manera que aprendan y se entrenen en los procesos conforme al propósito y al contenido las áreas Descripción

del nivel dos de CMMI; esta actividad se ha de realizar mediante cursos o talleres de trabajo, al menos por cada área del nivel dos de CMMI.

Salidas

•

Herramientas • •

Nómina de asistencia Modelo CMMI (Nivel 2) Cualquier herramienta que ayude a la realización de la actividad.

•

11

A2. Analizar y revisar los objetivos y prácticas del nivel dos de CMMI. Responsable

SEPG

Participantes SEPG Entradas

•

Cursos o talleres

•

Modelo CMMI (Nivel dos)

Luego de realizar los cursos o talleres al personal inmerso en actividades de desarrollo de software, el SEPG se reúne para ejecutar Descripción

un análisis detallista de los objetivos y prácticas del nivel dos de CMMI.

Salidas

•

Herramientas • •

Acta de reuniones Template de “Acta de reuniones” Modelo CMMI (Nivel 2)

•

A3. Extraer el conocimiento individual implícito. Responsable

SEPG

Participantes •

Entradas

Jefes de proyecto

•

Desarrolladores

•

Listado de personal

•

Modelo CMMI (Nivel dos)

•

Templates de las áreas de nivel 2 de CMMI

En las reuniones de SEPG junto con el personal posiblemente posea de conocimiento tácito el cual fue identificado en la etapa de Evaluación Cuantitativa, utiliza mecanismos para conocer la manera en la que utilizan conceptos, técnicas y métodos para realizar sus actividades para la gestión de conocimiento y en el desarrollo de software, e identificar

12

qué criterios manejan para determinar cuándo es más adecuada la

Descripción

utilización de cada técnica o método para aportar así a la ejecución de la metodología en la extracción del conocimiento.

Los mecanismos mencionados en el contexto anterior pueden consistir, por ejemplo, en entrevistas, realización de cursos o talleres, utilización de los templates para cada área del nivel dos de CMMI. Salidas

• Templates de las áreas de nivel 2 de CMMI (con observaciones)

Herramientas •

Templates de “Áreas del nivel dos de CMMI” Modelo CMMI (Nivel 2)

• •

1.30.Diagrama de flujo de la Etapa 3. Instrucción

) ./

%

0

%% .1

, -& 7 !

20

1

%%

4

./

%%

, -&'

!0

, -&

5 ! "

/ 6

%%

!

13

Figura 25. Diagrama de flujo de actividades Etapa 3 Instrucción

14

A.4. Difusión

Definición general de la etapa

Etapa

Etapa 4. Difusión (E4D)

Categoría

Socializar, compartir y extraer conocimiento.

Propósito

Esta etapa intermedia del ciclo iterativo formado por las etapas de Instrucción, Difusión y Utilización, apunta a que la organización aprenda lo instruido, donde los miembros del SEPG a medida que desarrollan sus actividades van adoptando, y compartiendo ideas que ayuden a mejorar la gestión de conocimiento y los procesos de desarrollo de software, en función de las prácticas y objetivos del nivel 2 de CMMI, las cuales serán realizadas paulatinamente.

Objetivos

a) Enseñar, compartir y difundir a la organización lo aprendido en la etapa de Instrucción, conforme al propósito y al contenido las áreas del nivel dos de CMMI. b) Obtener retroalimentación de parte de los miembros de los equipos de desarrollo. c) Capturar el conocimiento otorgado por los miembros de equipos de desarrollo durante la ejecución de los procesos.

Responsables Actividades

SEPG A4. Instruir en las Áreas del nivel dos de CMMI. A5. Analizar y comprender los objetivos y prácticas de cada área del nivel dos de CMMI. A6. Extraer el conocimiento individual implícito de los miembros de los equipos de desarrollo

15

Procesos de Nombres de los procesos relacionados.

CMMI relacionados

Descripción de actividades

A1. Enseñar a la organización lo aprendido en la etapa de Instrucción. Responsable

SEPG

Participantes •

Entradas

SEPG

•

Jefes de proyecto

•

Modelo CMMI (Nivel 2)

•

Templates de las áreas de nivel 2 de CMMI

•

Cronograma de actividades El SEPG será el encargado de enseñar, compartir y difundir lo aprendido en la etapa de Instrucción al resto del personal, de acuerdo a los roles correspondientes.

Descripción A medida que los miembros de los equipos avanzan en la realización de sus actividades, van apareciendo nuevas ideas y dudas; estas reacciones están basadas en la experiencia laboral, ya que están realizando o hubieron realizado esas tareas. Salidas

•

Templates de las áreas de nivel 2 de CMMI, (con propuestas de mejora, sugerencias, observaciones)

Herramientas • •

Modelo CMMI (Nivel 2) Cualquier herramienta que ayude a la realización de la actividad.

16

A2. Entrenar lo aprendido acorde a los objetivos y prácticas del nivel dos de CMMI Responsable

SEPG

Participantes •

Entradas

SEPG

•

Jefes de proyecto

•

Templates de las áreas de nivel 2 de CMMI

•

Modelo CMMI (Nivel dos)

Conforme al avance en la realización de las tareas efectuadas por el SEPG y los equipos de desarrollo de software van entrenándose de Descripción

modo que se genere nuevas habilidades que contribuyan a la GC; y a las prácticas y procesos de desarrollo de software.

Salidas

•

Herramientas • •

Acta de reuniones Template de “Acta de reuniones” Modelo CMMI (Nivel 2)

•

A3. Extraer el conocimiento individual implícito. Responsable

SEPG

Participantes •

Entradas

Jefes de proyecto

•

Desarrolladores

•

Templates de las áreas de nivel 2 de CMMI

•

Lluvia de ideas

•

Entrevistas

•

Focus group

Como parte de una retroalimentación a los procesos para extraer e incrementar el conocimiento organizacional, los miembros de los equipos de desarrollo de proyectos de software pueden incluir ideas y

17

propuestas de mejora a las actividades y procesos que están efectuando en las áreas de nivel dos de CMMI. Descripción Durante esta etapa los miembros de los equipos de desarrollo, en forma individual o colectiva, capturan, analizan y sintetizan los conocimientos y empiezan a delinear sugerencias y propuestas de mejora que posteriormente serán analizadas y discutidas en las reuniones del SEPG, esto puede consistir, por ejemplo, en entrevistas, lluvias de ideas, focus group, templates, enfocados a cada área del nivel dos de CMMI. Salidas

• Templates de las áreas de nivel 2 de CMMI, (con propuestas de mejora, sugerencias, observaciones)

Herramientas • •

Templates de “Áreas del nivel dos de CMMI” Modelo CMMI (Nivel 2)

18

1.31.Diagrama de flujo de la Etapa 4. Difusión

(

) '

, -&

/ %% ./

"#0

6 , ) -

! 5 )

'

"

Figura 26. Diagrama de flujo de actividades Etapa 4 Difusión

19

A.5. Utilización

Definición general de la etapa

Etapa

Etapa 5. Utilización (E5U)

Categoría

Utilizar, extraer y re utilizar conocimiento.

Propósito

La etapa de utilización, se refiere a utilizar y aplicar los nuevos conocimientos creados o adquiridos en las etapas de Instrucción y Difusión, una de las funciones de la GC es asegurar que la organización utilice su conocimiento puesto que, si no se aplica, el conocimiento no tiene valor, ya que es aquí donde el conocimiento se transforma en resultados concretos.

Todo el conocimiento capturado se encuentra disponible en un ambiente controlado que se rige por el área de Gestión de la configuración de CMMI. Objetivos

a) Utilizar el conocimiento capturado que ha sido obtenido durante la ejecución de los procesos de desarrollo a medida que desarrollan las actividades. b) Utilizar los objetivos y prácticas del nivel dos de CMMI como líneas guía para la GC. c) Generar propuestas de mejora para la ejecución de las prácticas establecidas por el modelo CMMI. d) Preparar al equipo participe de SCAMPI clase B. e) Verificar cumplimiento de procesos.

Responsables Actividades

SEPG A1. Utilizar el conocimiento capturado que ha sido obtenido durante la ejecución de los procesos de desarrollo.

20

A2. Utilizar los objetivos y prácticas del nivel dos de CMMI como líneas guía para la GC. A3. Generar propuestas de mejora para la ejecución de las prácticas establecidas por el modelo CMMI. A4. Preparar al equipo participe de SCAMPI clase B. A5. Verificar cumplimiento de procesos, mediante el proceso de PPQA (revisar 3.3.4, figura 16), para determinar que está aprendiendo la organización. Procesos de Nombres de los procesos relacionados.

CMMI relacionados

Descripción de actividades

A1. Utilizar el conocimiento que ha sido obtenido en las etapas anteriores. Responsable

SEPG

Participantes •

Entradas

Jefes de proyecto

•

Desarrolladores

•

Modelo CMMI (Nivel 2)

•

Templates de las áreas de nivel 2 de CMMI El propósito de esta tarea es utilizar el conocimiento capturado que fue adquirido en la implementación de las áreas del nivel dos de CMMI, este conocimiento es aportarte importante por parte de los miembros de equipos durante las etapas de Instrucción y Difusión.

Descripción Salidas

•

Templates de las áreas de nivel 2 de CMMI, (con propuestas de mejora, sugerencias, observaciones)

Herramientas • •

Modelo CMMI (Nivel 2) Templates de “Áreas del nivel dos de CMMI”

21

A2. Utilizar los objetivos y prácticas del nivel dos de CMMI como líneas guía para la GC. Responsable

SEPG

Participantes SEPG Entradas

•

Templates de las áreas de nivel 2 de CMMI

•

Modelo CMMI (Nivel dos)

El propósito de esta tarea es utilizar los objetivos y prácticas del nivel dos de CMMI como líneas guía a ser manejadas en la gestión del Descripción

conocimiento durante la ejecución de las actividades de desarrollo de software.

Mediante el proceso de PPQA, se verificará el cumplimiento de actividades lo que ayudará a determinar qué ha aprendido la organización. Salidas

•

Herramientas • •

Informe de PPQA Template “Informe de PPQA” Modelo CMMI (Nivel 2)

A3. Generar propuestas de mejora para la ejecución de las prácticas establecidas por el modelo CMMI. Responsable

SEPG

Participantes •

Entradas

Jefes de proyecto

•

Desarrolladores

•

Templates de las áreas de nivel 2 de CMMI

•

Lluvia de ideas

•

Entrevistas

•

Focus group

22

Como parte de una retroalimentación a los procesos para extraer e incrementar el conocimiento organizacional, los miembros de los equipos de desarrollo de proyectos de software pueden incluir ideas y propuestas de mejora a las actividades y procesos que están efectuando en las áreas de nivel dos de CMMI. Descripción Durante esta etapa los miembros de los equipos de desarrollo, en forma individual o colectiva, capturan, analizan y sintetizan los conocimientos y empiezan a delinear sugerencias y propuestas de mejora que posteriormente serán analizadas y discutidas en las reuniones del SEPG, esto puede consistir, por ejemplo, en entrevistas, lluvias de ideas, focus group, templates, enfocados a cada área del nivel dos de CMMI. Salidas

•

Templates de las áreas de nivel 2 de CMMI, (con propuestas de mejora, sugerencias, observaciones)

• Template de informe de PPQA Herramientas • •

Templates de “Áreas del nivel dos de CMMI” Modelo CMMI (Nivel 2)

23

A4. Planificar y preparar equipo, material e instalaciones para SCAMPI B. Responsable

SEPG

Participantes SEPG Entradas

•

Templates de las áreas de nivel 2 de CMMI

Planificación y preparación para la evaluación, donde se: analizan los Descripción Salidas

requisitos, evalúan los planes de desempeño, preparación y selección del equipo y obtienen y analizan las evidencias. • Templates de las áreas de nivel 2 de CMMI, (con propuestas de mejora, sugerencias, observaciones) • Indicadores de implementación de la práctica PIID

Herramientas •

Templates de “Áreas del nivel dos de CMMI”

•

Modelo CMMI (Nivel 2)

•

Template “ PIID”

24

1.32.Diagrama de flujo de la Etapa 5. Utilización

, -&

./

--8 $%0

./

$%0

*

*

%%

"

) "

&

/ %% !

5 )

6 , )

'

1 .

0

-

./



%$- 9 $%0

Figura 27. Diagrama de flujo de actividades Etapa 5 Utilización

25

A.6. Evaluación Cuantitativa

Definición general de la etapa

Etapa

Etapa 6. Evaluación Cuantitativa (E6EC)

Categoría

Evaluación SCAMPI B

Propósito

El propósito de la etapa de Evaluación cuantitativa es realizar la evaluación, que tendrá como referencia el método SCAMPI clase B y será aquí donde se evalúa la aplicación correcta de las prácticas y objetivos de CMMI, y a la vez determina qué y cuanto aprendió la organización; identificando además fortalezas y oportunidades de mejora, que serán útiles en la posterior y final etapa que es la Evaluación.

Objetivos

a) Evaluar los procesos de desarrollo de software que se realizan mediante SCAMPI clase B. b) Identificar fortalezas y oportunidades de mejora para la GC. c) Informar a la organización cuales han sido fortalezas y oportunidades de mejora para la GC.

Responsables Actividades

SEPG, consultor externo. A1. Evaluar los procesos de desarrollo de software mediante SCAMPI clase B. A2. Informar a la organización cuales han sido las fortalezas y las oportunidades de mejora.

Procesos de CMMI

Nombres de los procesos relacionados.

relacionados

Descripción de actividades

26

A1. Ejecutar evaluación SCAMPI clase B. Responsable

Consultor externo

Participantes •

Entradas

Jefes de proyecto

•

Desarrolladores

•

Método SCAMPI

•

Indicadores de implementación de la práctica PIID

El método SCAMPI clase B es realizado para determinar qué y cuanto aprendió la organización y valorar la aplicación correcta de las prácticas y objetivos de CMMI; identificando además fortalezas y oportunidades Descripción

de mejora.

La ejecución de la evaluación, incluye la: inducción a los miembros del equipo de evaluación, documentación y verificación de la evidencia, Salidas

validación y evaluación de los resultados. • Resultados de evaluación •

Herramientas • •

Informe de oportunidades de mejora Método SCAMPI Modelo CMMI (Nivel 2)

27

A2. Informar a la organización los resultados de la evaluación. Responsable

Consultor externo

Participantes Toda la organización Entradas

•

Resultados de evaluación (Template “ PIID”)

•

Informe de oportunidades de mejora

Con las entrevistas realizadas en la evaluación SCAMPI se puede tener noción de personal que posiblemente posea conocimiento tácito, por la Descripción

tanto la participación de estas personas será un gran aporte en el desarrollo de la metodología para la extracción del conocimiento.

Salidas

Reporte de resultados, donde se generan los documentos de resultados y se informa a os miembros de la organización. • Observaciones al Informe de oportunidades de mejora

Herramientas •

Template “ PIID”

28

1.33.Diagrama de flujo de la Etapa 6. Evaluación Cuantitativa

/ %% 4

%3 , %-

,

Evaluación SCAMPI clase B

! % .1

%- 9

'

%% 20 Informar a la organización cuales han sido las fortalezas y las oportunidades de mejora

, -&

./

&

0

&

Figura 28. Diagrama de flujo de actividades Etapa 6 Evaluación Cuantitativa

29

A.7. Revisión Definición general de la etapa

Etapa

Etapa 7. Revisión (E7R)

Categoría

Analizar resultados, considerar nueva iteración.

Propósito

El propósito de la etapa de Revisión es de considerar todas y cada una de las observaciones (oportunidades de mejora) realizadas en la etapa de Evaluación Cuantitativa para de esta manera determinar cuáles fueron los procesos en los que se requiere una revisión para intervenir en ellos y tomar acciones para gestionarlos de la manera correcta con la finalidad de cumplir adecuadamente los mismos y así mejorar el proceso de GC en la organización

Objetivos

a) Revisar las oportunidades de mejora resultado del SCAMPI clase B. b) Tomar acciones para gestionar de manera correcta los procesos que no cumplieron con la evaluación. c) Considerar la necesidad efectuar una regresión a la etapa de Instrucción y realizar un ciclo iterativo conformado por las fases subsiguientes. d) Analizar el aprendizaje y los nuevos conocimientos logrados por los miembros de los equipos de desarrollo. e) Finalizar el proceso de GC cuando cumpla con todos los objetivos y prácticas del nivel dos de CMMI, considerando que no es necesario realizar una nueva iteración. f) Formular recomendaciones de mejora al propio proceso de GC definido por la metodología.

Responsables Actividades

Gerente y SEPG A1. Utilizar el conocimiento capturado que ha sido obtenido durante

30

la ejecución de los procesos de desarrollo. A2. Revisar las oportunidades de mejora resultado del SCAMPI clase B. A3. Tomar acciones para gestionar de manera correcta los procesos que no cumplieron con la evaluación. A4. Identificar el conocimiento obtenido y aprendieron por miembros de los equipos de desarrollo, y la organización en general. A5. Considerar la necesidad efectuar una regresión a la etapa de Instrucción. A6. Finalizar el proceso de GC cuando cumpla con todos los objetivos y prácticas del nivel dos de CMMI

Procesos de Nombres de los procesos relacionados.

CMMI relacionados

Descripción de actividades

A1. Analizar las oportunidades de mejora. Responsable

SEPG

Participantes SEPG Entradas

•

Resultados de evaluación

•

Informe de oportunidades de mejora

•

Modelo CMMI (Nivel dos)

En base al resultado de la evaluación se debe efectuar un análisis de las oportunidades de mejora y tomar acciones para gestionar de manera correcta los procesos que no cumplieron con la evaluación, y mejorarlos

31

Descripción

una próxima iteración.

Salidas

•

Herramientas • •

Observaciones al Informe de oportunidades de mejora Informe de oportunidades de mejora. Modelo CMMI (Nivel 2)

A2. Identificar el conocimiento obtenido en el desarrollo de la metodología. Responsable

SEPG

Participantes SEPG Entradas

•

Resultados SCAMPI C

•

Resultados SCAMPI B

•

Informes de oportunidades de mejora

Los resultados del SCAMPI B se los compara con los resultados del SCAMPI A, realizado en la etapa de Evaluación Inicial, de modo de Descripción

poder determinar qué conocimiento se obtuvo y se utilizó, esto para la primera iteración ya que en la segunda los resultados deben ser comparados con el SCAMPI B de la primera iteración.

Salidas

•

Herramientas •

Cuadro comparativo (benchmarking) Informes de oportunidades de mejora con observaciones, de las dos evaluaciones.

•

Modelo CMMI (Nivel 2)

A3. Considerar la necesidad de realizar una nueva iteración. Responsable

SEPG

Participantes • •

SEPG Gerente

32

Entradas

•

Resultados SCAMPI C

•

Resultados SCAMPI B

•

Informes de oportunidades de mejora

Se debe considerar realizar una regresión a la etapa de Instrucción y realizar un ciclo iterativo conformado por las fases subsiguientes, para de esta manera ir perfeccionando las prácticas ejecutadas por los Descripción

equipos de desarrollo y una vez que en la etapa de revisión se obtenga cumplimiento total de las prácticas, se dará por terminado el proceso de GC en los equipos de desarrollo de software.

Salidas

• Acta de reuniones

Herramientas •

Template “Acta de reuniones”

A4. Finalizar el proceso de la metodología para la gestión del conocimiento. Responsable

SEPG

Participantes •

Entradas

SEPG

•

Gerente

•

Acta de reuniones

La finalización del proceso de GC se lo realiza cuando los resultados Descripción

cumplan con todos los objetivos y prácticas del nivel dos de CMMI, dichos resultado serán arrojados cuando se produzca una nueva iteración si ésta ha sido considerada en la tarea anterior.

Salidas

• Acta de reuniones

Herramientas •

Template “Acta de reuniones”

33

1.34.Diagrama de flujo de la Etapa 7. Revisión

4

,

%- 9 , -&

Analizar las oportunidades de mejora detectadas

/ %%

Identificar el conocimiento obtenido en el desarrollo de la metodolgia

2'

,

./

'(0

./

'(0

Considera nueva iteración

16

Finalizar el proceso de la metodología

'(

Figura 29. Diagrama de flujo de actividades Etapa 7 Revisión

34

ANEXO B – Documentos para la realización de las actividades

B.1. Template “Acta de reuniones” ETAPA (1. Definición, 2. Evaluación Inicial, 3. Instrucción, 4. Difusión, 5. Utilización, 6. Evaluación Cuantitativa, 7. Revisión)

Acta N°

Fecha:

Hora inicio:

Lugar:

Hora fin: Objetivo de la reunión:

CONVOCADOS / ASISTENTES Nombres

Cargo – Dependencia

TAREAS / ACTIVIDADES No.

Descripción

1. 2. 3.

35

4. 5. TAREAS / COMPROMISOS FUTUROS No.

Tareas / Compromisos

Responsable

Fecha entrega

1. 2. 3.

PARA CONSTACIA, REVISADO Y APROBADO POR:

Nombres

Firma

Documento elaborado por:

36

B.2. Template “Plan de difusión”

Índice 1

Introducción ........................................................................................................ 38

2

1.1 Definiciones, acrónimos y abreviaciones. .................................................... 38 Objetivos ............................................................................................................. 38

3

Distribución del personal involucrado ................................................................ 38

4

3.1 Estructura Organizacional............................................................................. 38 3.2 Roles y Responsabilidades............................................................................ 39 Plan general de actividades ................................................................................ 39

5

4.1 Cronograma de actividades ........................................................................... 39 4.2 Plan de capacitación...................................................................................... 40 Plan de Administración de Riesgos..................................................................... 40

37

Plan de Difusión, Etapa 1 Definición 1 Introducción [Una descripción breve acerca del propósito de Plan de Difusión. Agregue también una descripción breve de a que se aplica la metodología; que se ve afectado o influenciado por este documento.] Ejemplo: El propósito del presente documento corresponde a la elaboración del Plan de Difusión para promover la Gestión del conocimiento mediante la utilización del nivel dos de CMMI. Como parte de la estrategia, el plan contempla que antes de iniciar su implementación, se precisa de una activa participación de la gerencia así como también personal encargado de desarrollar software; primero, en la oficialización de la metodología y luego, en un ordenamiento técnico administrativo para llevar a acabo lo expuesto.

1.1

Definiciones, acrónimos y abreviaciones. [Párrafo obligatorio si existen términos, definiciones, acrónimos o abreviaciones, adicionales a los descritos] SEPG.- Grupo de procesos de ingeniería de software GC.- Gestión de conocimiento E1D.- Etapa 1 Definición E2EI.- Etapa 2 Evaluación cuantitativa E3I.- Etapa 3 Instrucción E4D.- Etapa 4 Difusión E5U.- Etapa 5 Utilización E6EC.- Etapa6 Evaluación Cuantitativa E7R.- Etapa 7 Revisión

2

Objetivos

[Párrafo obligatorio.] [Describa el objetivo de este Plan de difusión; que actividades están asociados a él y cualquier elemento que se vea afectado o influenciado por este documento.] Ejemplo: Los objetivos generales del Plan de Difusión para el desarrollo de la metodología son los siguientes: • Optimizar el flujo de la información para tener una comunicación eficiente entre el SEPG y el personal encargado del desarrollo de software. • Dar a conocer las actividades a realizar a los involucrados y a toda la organización (correos, intranet, redes sociales, etc). • Informar y comunicar los resultados.

3 3.1

Distribución del personal involucrado

Estructura Organizacional [Párrafo obligatorio.] [Describe la estructura organizacional del Grupo de ingeniería de desarrollo de software SEPG. Se puede reemplazar con una referencia a documento Asignación de Roles (Acta de Reuniones).]

38

3.2

Roles y Responsabilidades [Párrafo obligatorio.] [Identifique las unidades organizacionales que son responsables por cada una de las disciplinas, detalles del flujo de trabajo, y procesos de soporte. Se puede reemplazar con una referencia a documento Asignación de Roles.]

4

Plan general de actividades

[Describe la estructura organizacional del Grupo de ingeniería de desarrollo de software SEPG. Se puede reemplazar con una referencia a documento Asignación de Roles (Acta de reuniones).]

El plan general de actividades es el instrumento a través del cual se planifican las actividades a desarrollar para llevar a cabo la metodología. Este plan permite establecer un orden en la secuencia de acciones a realizar y controlar el curso de ejecución de las mismas. Planificar actividades permite hacer viables los objetivos definidos. Se recomienda que las actividades se presenten en orden cronológico, y agrupadas por fase de la metodología. El plan puede incluir fecha de inicio y fin, tiempos de duración, recursos, costos, prioridades de cada actividad u otras consideraciones que estime relevantes y sean útiles para realizar la administración y el control de las actividades a desarrollar. El producto resultante de esta actividad es el “Template Cronograma de actividades”:

4.1

Cronograma de actividades

REQM

Gestión de requerimientos

PP

Planificación de proyecto

PMC

Seguimiento y control de proyecto

PPQA

Aseguramiento de calidad de proceso y producto

CM

Gestión de la configuración

MA

Medición y Análisis

39

4.2

Plan de capacitación [Párrafo NO obligatorio. Es parte de programa de capacitación de la empresa.] [Liste cualquier tipo de capacitación especial que requieran los miembros del equipo, con fechas objetivo para cuando se debe finalizar esta capacitación..]

5

Plan de Administración de Riesgos

[Párrafo obligatorio.] [Debe Incluirse como una referencia a documento Lista de Riesgos.]

Riesgo (si)

Posible resultado (entonces)

Síntoma

Probabilidad (A/M/B)

Impacto (A/M/B)

Retraso en el proyecto

Media

Alto

Decisiones en las prioridades.

Media

Alto

Respuesta

40

B.3. Template “Cronograma de actividades” Meses 1 DEFINICIÓN

2

3

4

5

6

7

EVALUACIÓN INICIAL

INSTRUCCIÓN, DIFUSIÓN, UTILIZACIÓN

SCAMPI C

ÁREAS DEL NIVEL DOS DE CMMI

8

9 EVALUACIÓN CUANTITATIVA

10

11

12

REVISIÓN

REQM PP PMC PILOTOS PPQA (RQM, PP, PMC) CM MA PPQA (CM, MA) SCAMPI B AJUSTES Seguimiento y control del proyecto

41

B.4. Template “Revisiones de PPQA”

No Existe

Incompleto

Persiste Incumplimiento

Incorrecto

Completo

Cerrado

Nombre del Proyecto Fecha

Etapa

Actividad

Estado

Comentario de la Revisión

Revisado por

Comentarios del Encargado del Proyecto

Fecha de Resolución comprometida

42

B.5. Template de la “PIIDB” Completar o preparar la PIIDB (Practice Implementation Indicators DataBase) es una tarea extensa es por ello que a continuación se describe una guía con ejemplos de artefactos que pueden ser útiles para cada una de las prácticas de las áreas de proceso de nivel dos de CMMI; dichos ejemplos han sido extraídos durante el desarrollo de la metodología por lo que en la implantación que en otras empresas pueden encontrarse otros artefactos, con esto se pretende ayudar al llenado de la PIDB de una manera más entendible en cuanto a los indicadores.

SG1 Gestión Requerimientos

Metas Genéricas

SP

AREA DE PROCESO ADMINISTRACIÓN DE REQUERIMIENTOS

1.1

Obtener una comprensión de los requerimientos.

1.2

Obtener compromiso con los requerimientos.

Administrar los cambios a los requerimientos. 1.3

43

DESCRIPCIÓN DE LO ESPERADO

Se obtiene un entendimiento de los requerimientos que van a ser desarrollados en el proyecto (por ej: que estén completos, que estén todos, si son factibles, claros, consistentes, testeables. Se obtiene un compromiso con el cliente y los participantes del proyecto de los requerimientos que serán desarrollados en el proyecto. Los cambios a los requerimientos son administrados durante el proyecto.

ARTEFACTOS

PRODUCTO A OBTENER

Aplicación de un listado de criterios definidos para la evaluación y la aceptación de los requisitos. Resultados del análisis de los requisitos frente a los criterios de aceptación.

Correos electrónicos o actas de reuniones en las cuales se evidencia el entendimiento, negociación o cambio de requisitos.

Documento de requisitos aceptado. Acta de reunión donde se aceptan los requisitos.

Histórico de requisitos cuyo estado pasa a ser aceptado.

Peticiones de cambio asociadas con requisitos. Requerimientos versionados. Tareas para cada petición de cambio: trazabilidad de la

Histórico de requisitos cuyo estado haya pasado a “abierto” tras haber sido “cerrado”. Estimación de las tareas

Mantener Trazabilidad bidireccional de los Requerimientos. 1.4

1.5

SG1 Establecer Estimaciones

Metas Genéricas

Identificar inconsistencias entre proyectos, trabajos y requerimientos.

SP

1.1

1.2

Se mantiene la trazabilidad bidireccional entre los requerimientos y productos de trabajo. Se identifican inconsistencias entre los planes de proyecto, productos de trabajo y los requerimientos.

petición de cambio con las tareas.

asociadas al cambio en un requisito.

Matriz de trazabilidad entre requisitos y los demás elementos que componen el producto software (ej. diseño, casos de prueba, código fuente, etc.).

Análisis de cambio donde se ha utilizado la matriz de trazabilidad para valorar el impacto.

Informe de pruebas. Listado de inconsistencias.

Acciones correctivas asociadas a las inconsistencias encontradas entre el proyecto y los requisitos.

AREA DE PROCESO PLANIFICACIÓN DE PROYECTOS

Definir el ámbito del proyecto.

Establecer un WBS (Work Breakdown Structure) de alto nivel para estimar el ámbito del proyecto

Establecer estimaciones de productos de trabajo y atributos de tareas.

Se establecen y mantienen estimaciones de los atributos de los productos de trabajo y tareas.

Oferta o plan de proyecto donde se indican el alcance del sistema. Descripción de las tareas a realizar durante el proyecto. Diagrama de Gantt en el que se describen la duración de las tareas, en base a una estimación por analogía. Planificación del sprint backlog. Informe con los resultados de la estimación.

Horas imputadas a la tarea de estimación del alcance, oferta inicial, estudio de viabilidad, etc. Horas imputadas a la realización de la estimación por analogía, punto función, puntos póker, etc.

44

1.3

SG2 Desarrollar un Plan de Proyectos

1.4

2.1

2.2

2.3

Definir el ciclo de vida del proyecto.

Definir las fases del ciclo de vida del proyecto en las cuales se distribuirá el esfuerzo

Determinar estimaciones de tiempo y costo.

Estime el esfuerzo y el costo del proyecto para los productos de trabajo y las tareas basados en la estimación razonada.

Una sección, usualmente incorporada al plan de proyecto donde se describen las fases que contendrá el proyecto (análisis, diseño, despliegue, iteraciones, etc.), la relación entre estas fases y su ordenación temporal (cascada, iterativo, incremental, etc.). Informe en el que se representan los resultados de la estimación del esfuerzo necesario y el método usado. Hoja de costes para el proyecto y el procedimiento de cálculo. Definición de recursos necesarios (memoria, capacidad de red, etc.) para la realización del proyecto. Sección de presupuesto del documento del plan de Proyecto. Diagrama de PERT en el que se identifican las distintas tareas y sus dependencias.

Establezca el Presupuesto y la Carta Gantt.

Se establece y mantiene el presupuesto y la agenda del proyecto.

Identificar riesgos del proyecto.

Se identifican y analizan riesgo del proyecto

Matriz de riesgos identificados para el proyecto. Checklist que evalúa los riesgos para el proyecto.

Plan para la administración de datos del proyecto.

Listado de los datos gestionados en el proyecto, con la descripción del formato, requisitos de privacidad y seguridad. Descripción del sistema de

Plan para Administración de Datos.

Hitos definidos en un diagrama de Gantt.

Horas imputadas a la tarea de estimación. Herramienta de cálculo de esfuerzo y coste completada.

Horas imputadas a la tarea de elaboración del presupuesto y calendario. Herramienta de cálculo de esfuerzo y coste completada. Catálogo genérico de riesgos. Horas imputadas a la tarea de identificación de riesgos. Estructura de carpetas y permisos para controlar datos confidenciales. Logs de backups realizados para el proyecto.

45

Backup. Datos que requieren confidencialidad.

2.4

2.5

2.6

Plan para recursos del proyecto.

Plan para recursos necesarios del proyecto.

Plan para conocimiento de habilidades necesitadas.

Hacer una planificación para adquirir los conocimientos y habilidades necesitadas en la ejecución del proyecto

Plan para involucrar a terceros.

Plan para involucramiento de terceros es identificado.

Listado de equipamiento, instalaciones y software asociado con el proyecto. Listado de recursos humanos necesarios Listado de habilidades necesarias por parte de los miembros del equipo. Plan de personal y de nuevas contrataciones. Listado de los participantes del proyecto y rol que juegan en el mismo. Comunicación formal a las personas que participarán en el proyecto (cliente, desarrolladores, equipo de pruebas, etc.). Plan de comunicación y relaciones entre los participantes. Comunicación formal a las personas que participarán en el proyecto (cliente, desarrolladores, equipo de pruebas, etc.). Plan de comunicación y relaciones entre los participantes.

Orden de compra de equipamiento. Acta de reunión interna de arranque. Actividades de formación para los perfiles del proyecto. Material de formación.

Acta de reunión de arranque del proyecto en la que participan tanto el cliente como los principales involucrados en el proyecto y se explica el plan de comunicación.

46

2.7

SG3 Obtener compromiso con el Plan

3.1

3.2

3.3

SG1 Monitorear el proyecto contra el Plan

Metas Genéricas

Establecer plan de proyecto.

Se establece y mantiene el contenido total del plan de proyecto.

Revisar otros planes que afecten al proyecto.

Repase todos los planes que afecten el proyecto para entender compromisos del proyecto

Conciliar trabajos con los recursos.

Reconcilie el plan del proyecto para reflejar recursos disponibles y estimados.

Obtener compromiso con el plan.

Obtener el compromiso de los terceros relevantes responsables de realizar y de apoyar la ejecución del plan.

SP

Plan de proyecto. Matriz de relaciones entre proyectos, planificación de proyectos y recursos asignados en la unidad organizacional. Documento con la ocupación de recursos de la organización. Presupuestos renegociados. Control de la asignación y capacidad de los recursos Reestimación de las tareas de los implicados que tengan una dedicación que no sea aceptable. Revisión en herramienta de gestión de personal y control de horas, así como el ajuste de recursos y tareas.

Horas imputadas a la tarea de planificación. Plantilla de plan de proyecto. Registro de resolución de conflictos (correo, acta, etc.).

Revisión en herramienta de gestión de personal y control de horas, así como el ajuste de recursos y tareas. Revisión en herramienta de gestión de personal y control de horas, así como el ajuste de recursos y tareas.

AREA DE PROCESO MONITOREO Y CONTROL DEL PROYECTO

1.1

Monitorear parámetros del plan de proyectos.

Monitoree los valores reales del proyecto contra los parámetros estimados en el plan del proyecto

1.2

Monitorear compromisos.

Se monitorean los compromisos obtenidos para el proyecto.

Actas de las reuniones de seguimiento llevadas a cabo. Herramienta de seguimiento (por ejemplo Gantt de seguimiento, Trac, etc.). Identificación de desviaciones en el proyecto.

Registro de la revisión de las horas imputadas al proyecto.

Actas de reunión de seguimiento, informes de

Horas imputadas al seguimiento del proyecto.

47

1.3

Monitorear los Riesgos del Proyecto.

1.4

Monitorear la Administración de Datos

1.5

Monitorear Actas de reunión de entrega de involucramiento de terceros hitos intermedios. contra el plan de proyectos.

Conducir revisiones de avance

Revisar periódicamente los avances del proyectos, desempeño y problemas

Informes de avance del seguimiento. Actas de reunión de seguimiento.

Conducir Revisiones de hitos.

Revisar la completitud y resultados del proyecto en hitos seleccionados del proyecto

Actas de reunión de entrega intermedia, reuniones intermedias de chequeo con el cliente. Acta de reunión de final de un Sprint.

2.1

Analizar problemas

Recolecte y analice los problemas y determine las acciones correctivas necesarias para corregir el problema.

Incidencias registradas y analizadas.

2.2

Tomar acciones correctivas.

Acciones correctivas son tomadas para los problemas encontrados.

Documento o registro de acciones correctivas.

1.6

1.7

SG2 Administrar acciones correctivas

Monitorear involucramiento de terceros.

avance, de cumplimiento de hitos, etc. Histórico de cambios en los Monitorear riesgos contra riesgos. los identificados en el plan Identificación de nuevos riesgos de proyecto. a lo largo del proyecto. Monitorear los datos de Servidor de integración administración del proyecto continua. contra los identificados en Registro de tareas de gestión de el Plan. datos.

Acta de reunión de seguimiento en la que se tratan explícitamente los riesgos del proyecto Logs del sistema de backups. Histórico de revisiones en gestor de configuración. Correos o notificaciones entre los implicados. Horas imputadas por parte del equipo a tareas del proyecto. Impedimentos detectados durante las reuniones de seguimiento. Histórico de entregables. Histórico de incidencias. Riesgos del proyecto revisados durante la realización del hito. Peticiones de cambio asociadas. Planificación modificada incluyendo las incidencias y su estimación. Incidencias resueltas. Histórico de cambios de estado de las incidencias

48

2.3

Metas Genéricas

SP

SG1 Alinee actividades de medidas y análisis

1.1

SG2 Proveer resultad os de las medidas

Administrar acciones correctivas.

1.2

Administre acciones correctivas hasta su cierre.

Histórico de acciones correctivas, participantes, planes derivados, etc.

Acta de reunión al final del hito en la que se incluye la revisión de las incidencias y las acciones correctivas asociadas.

AREA DE PROCESO MEDIDAS Y ANÁLISIS

Establecer objetivos de medidas.

Especificar medidas.

Establecer y mantener los objetivos de la medida que se derivan de necesidades de información y de objetivos identificados.

Documento con los objetivos de medición, donde se indican los objetivos de negocio y su relación con los indicadores de medición.

Correos de sugerencias de indicadores. Histórico de indicadores.

Especificar las medidas en concordancia con los objetivos de medida (básicas y derivadas)

Descripción de los indicadores de medición: unidades de medida, mecanismo de recogida, periodicidad de la recolección, objetivo de la medición, etc.

Actas de reunión para la definición de los indicadores. Histórico de resultados de las mediciones. Catálogo genérico de métricas.

1.3

Especificar procedimiento de recopilación de datos y almacenamiento.

Se especifica como las medidas pueden ser obtenidas, almacenadas, analizadas e informadas

1.4

Especificar procedimiento de análisis.

Se especifica como los datos de medidas son analizados e informados.

Descripción de los indicadores de medición: unidades de medida, mecanismo de recogida, etc. Sección en la documentación donde se indica cómo se almacenan Descripción de los indicadores de medición, umbrales y análisis a realizar.

2.1

Recopile Datos para Medidas.

Se Obtienen datos de medidas específicas.

Informe que contenga los datos extraídos de la medición.

Procedimiento de medición y análisis desarrollado. Logs de las herramientas de recolección automática de datos. Plantilla de los informes de indicadores. Horas imputadas a realizar el informe. Logs de las herramientas

49

2.2

2.3

2.4

SG1 Evaluar objetivamente procesos y productos

Metas Genéricas

SP

de recolección automática de datos. Acta de reunión de análisis de datos. Acciones correctivas asociadas con el análisis.

Analizar datos de medidas.

Se Analizan e interpretar los datos de medidas

Informe de análisis de los datos obtenidos.

Almacenar datos y resultados.

Se administran y almacenan los datos de medidas, especificaciones de medidas y resultados de los análisis.

BBDD de indicadores, con los resultados de las mediciones anteriores y actuales

Horas imputadas al análisis y almacenamiento de los resultados.

Comunicar Resultados.

Se administran y almacenan los datos de medidas, especificaciones de medidas y resultados de los análisis.

Correo electrónico, acta, etc. donde se evidencie la comunicación de los resultados

Contestaciones a las comunicaciones de los resultados. Acciones correctivas identificadas en base a los resultados

AREA DE PROCESO ASEGURAMIENTO DE CALIDAD DE PROCESO Y DE PRODUCTO

1.1

Evaluar el proceso objetivamente.

1.2

Evaluar objetivamente productos de trabajo y servicios

Evaluar objetivamente los procesos ejecutados seleccionados contra las descripciones, los estándares, y los procedimientos de proceso definidos para la organización. Evaluar objetivamente los productos de trabajo y los servicios seleccionados contra las descripciones, los estándares, y los procedimientos de proceso

Informe de auditoría interna o externa. No conformidades detectadas durante la auditoría.

Registro de auditoría.

Informes de pruebas de los productos y servicios. Informes de auditoría interna o externa realizada al proyecto.

Histórico de casos de prueba. Horas imputadas a las auditorías

50

SG2 Proveer una visión objetiva

definidos para la organización.

SG1 Establecer líneas bases

Metas Genéricas

2.1

2.2

Comunicar y asegurar resolución de incumplimientos.

Establecer Registros.

SP

1.1

1.2

Comunicar y asegurar la resolución de los incumplimientos con el equipo de trabajo y el administrador. Se establece y mantiene un registro de todas las actividades de aseguramiento de calidad.

No conformidades detectadas durante la auditoría comunicadas a los proyectos y asignadas al responsable de la resolución. Plan de calidad e informes de auditoría. Almacenamiento de las no conformidades identificadas en las auditorías

Acciones correctivas asociadas a las no conformidades.

Horas imputadas a las auditorías.

AREA DE PROCESO ADMINISTRACIÓN DE CONFIGURACIÓN

Identificar ítem de administración de configuración.

Identificar los ítems de la configuración, los componentes, y los productos de trabajo que será colocado bajo administración de configuración.

Establecer sistema de administración de configuración.

Establezca y mantenga una administración de configuración y controle los cambios en los productos de trabajo con el sistema administrador.

Documento o herramienta donde se identifican los elementos de configuración de las líneas base. Pueden ser productos que se entregan al cliente, herramientas, diseños, planes de pruebas, prototipos, resultados de pruebas, documentos, etc.

Tiempo dedicado a su elaboración, horas, actas, etc.

Herramienta de gestión de la configuración (SVN, CVS, etc.).

Histórico de revisiones y roles de acceso al sistema de gestión de la configuración. Logs de herramientas de gestión de configuración.

51

SG3 Establecer Integridad

SG2 Seguir y controlar cambios

1.3

2.1

2.2

Crear o liberar líneas bases.

La creación y liberación de productos de la línea base es controlada.

Descripción de las entregas formales a realizar durante el proyecto, tanto de productos software como de documentación, describiendo los elementos que contiene.

Seguir solicitudes de cambio.

Solicitudes de cambios para todos los ítems/unidades de configuración son iniciadas, registradas, revisadas, aprobadas, y seguidas.

Peticiones de cambio realizadas durante el proyecto.

Registro con la aprobación o denegación de un cambio en el sistema.

Controlar cambios de los ítems de configuración.

Servidor de integración continua que integra periódicamente el código realizado hasta ese momento, identificando errores o conflictos. No conformidades identificadas durante las auditorías internas y externas.

Logs de ejecuciones del servidor de integración continua. Registros de auditoría interna o externa.

Revisiones de las tareas de gestión de configuración Revisiones de los cambios implementados entre dos versiones de la línea base. No conformidades extraídas de la realización de la auditoría.

Controlar ítems de configuración.

3.1

Establecer registros de administración de configuración.

Se establecen y mantienen registros que describen los ítems de configuración.

Revisiones de las tareas de gestión de configuración Revisiones de los cambios implementados entre dos versiones de la línea base.

3.2

Ejecutar auditoria de configuración.

Ejecutar las auditorias de configuración para mantener la integridad de las líneas bases.

Informe de auditoría interna o externa.

Histórico de entregas formales realizadas.

52

ANEXO C - Templates de las áreas del nivel dos de CMMI

C.1. Gestión de requerimientos

Versión

53

Descripción General Propósito Administrar los requerimientos de los productos del proyecto y los componentes de los mismos e identificar las inconsistencias entre esos requerimientos y los planes del proyecto y productos de trabajo. Objetivos Administrar los requerimientos e identificar las inconsistencias de éstos con el plan de proyecto y los productos de trabajo. Notas Introductorias Para determinar el estado de las actividades de Administración de Requerimientos se debe medir y analizar: El esfuerzo y tiempo utilizados por cada tarea de Administración de Requerimientos. El estado de los requerimientos asignados.

El número de nuevos requerimientos y cambios generados durante el proyecto. Diagrama General

Figura 1. Área de Procesos: Administración de Requerimientos.

Actividades y Tareas 1. Actividad: Comprender Requerimientos

54

Figura 2. Actividad: Comprender Requerimientos.

1.1. Tarea: Identificar Contraparte

Descripció Es necesario identificar tempranamente quién, por el lado del Cliente, será el n responsable de definir qué requerimientos deben ser llevados a cabo. A su vez, este individuo o grupo debe ser responsable de aprobar los cambios a realizar sobre los requerimientos. También se debe identificar quién será el contacto dentro del proyecto para canalizar requerimientos y solicitudes de cambios a los mismos; es decir, a quién debe dirigirse el Cliente en estos casos, usualmente es el Gerente de proyectos o el Jefe de proyecto. Entradas Salidas Roles

Todos estos roles deben documentarse en los artefactos “Plan de proyecto” y “Asignación de roles”. Plan de proyecto, Asignación de roles Gerente de proyectos, Jefe de proyecto

55

1.2. Tarea: Revisar Requerimientos

Descripció Todo requerimiento, ya sea un requerimiento inicial, una modificación o un n nuevo requerimiento, debe estar documentado y completo, para permitir una estimación adecuada de los mismos. También debe ser consistente con los otros requerimientos y además debe ser concreto, es decir, no tener ambigüedades. En el “Plan de revisiones” se debe documentar qué técnicas se aplicarán para hacer la revisión de los requerimientos y definir quiénes y en qué momento las harán.

Entradas Salidas Roles

Los requerimientos son típicamente tomados desde los artefactos “Especificación de Requerimientos de Software (ERS)”, “Modelo de casos de uso” y “Análisis preliminar”. Luego cada requerimiento es revisado y Especificación de Requerimientos de Software (ERS), Modelo de casos de uso, Análisis preliminar ERS, Modelo de casos de uso, Análisis preliminar, Plan de revisiones, Planilla de administración de requerimientos Jefe de proyecto, Gerente de proyectos

1.3. Tarea: Asegurar Entendimiento Común de Requerimientos

Descripció n Entradas Salidas Roles

Los requerimientos son revisados y consensuados con la contraparte para verificar un adecuado entendimiento de los mismos por parte del Equipo de ERS ERS Jefe de proyecto, Equipo de proyecto

56

2. Actividad: Comprometer Requerimientos

Figura 3. Actividad: Comprometer Requerimientos.

2.1. Tarea: Evaluar Impacto y Factibilidad

Descripció Se evalúa el impacto de los requerimientos sobre los compromisos, así como n su factibilidad técnica. Para evaluar el impacto el Jefe de proyecto podría requerir la ayuda del Equipo del proyecto. Esta evaluación TEC (Tiempo/Esfuerzo/Costo) es revisada por Área comercial, quien es responsable de la generación de la “Orden de servicio”. Entradas Análisis preliminar Salidas Planilla de Tiempo, Esfuerzo y Costo (TEC), Orden de servicio Roles Jefe de proyecto, Área comercial, Equipo de proyecto 2.2. Tarea: Negociar y Registrar Compromisos

Descripció Los compromisos sobre los requerimientos, ya sea para requerimientos n iniciales, modificaciones o nuevos requerimientos, son negociados por las partes y registrados en la “Planilla de administración de requerimientos”. Entradas Plan TEC, Orden de servicio Salidas Planilla de administración de requerimientos Roles Jefe de proyecto, Área comercial, Equipo de proyecto 3. Seguir Requerimientos

57

Figura 4. Actividad: Seguir Requerimientos. 3.1. Tarea: Revisar Consistencia de Requerimientos

Descripció Periódicamente se revisa la consistencia de los requerimientos en relación a n los planes, productos de trabajo y actividades del proyecto. Entradas Planilla de administración de requerimientos, Plan de revisiones, Plan de proyecto, Carta Gantt de proyecto Salidas Roles Jefe de proyecto

58

3.2. Tarea: Analizar Inconsistencia de Requerimientos

Descripció n Entradas Salidas Roles

Se identifica la fuente y el motivo de la(s) inconsistencia(s), es decir, cómo y porqué surgieron. Planilla de administración de requerimientos Jefe de proyecto

3.3. Tarea: Identificar Cambios en Planes

Descripció Se deben identificar los cambios que es necesario hacer sobre los productos n de trabajo y planes. Entradas Salidas Roles

Plan de proyecto, carta Gantt, planilla de administración de requerimientos. Jefe de proyecto

3.4. Tarea: Iniciar Acciones Correctivas

Descripció Se inician las acciones correctivas de acuerdo a las inconsistencias n identificadas. Entradas Salidas Plan de proyecto, Carta Gantt de proyecto, Planilla de administración de requerimientos Roles Jefe de proyecto

59

4. Administrar Cambios

Figura 5. Actividad: Administrar Cambios.

4.1. Tarea: Recepcionar Cambio de Requerimiento

Descripció El Jefe de proyecto recepciona las solicitudes de cambio de requerimientos n por parte del Cliente durante reuniones de seguimiento u otra instancia.

Entradas Salidas Roles

Esta solicitud puede registrarse en primera instancia en una minuta de reunión o inclusive en un e-mail, pero luego debe ser formalizada en el artefacto “Solicitud de requerimientos”. Solicitud de requerimientos, Minuta de reunión Solicitud de requerimientos Jefe de proyecto, Cliente

60

4.2. Tarea: Analizar Cambios

Descripció n Entradas Salidas Roles

Realizar el estudio de impacto del o los cambios solicitados. En base al impacto generar una estimación que este tiene en términos de esfuerzo, costo, Solicitud de requerimientos, Planilla de administración de requerimientos Solicitud de requerimientos Jefe de proyecto, Analista

4.3. Tarea: Estimar Cambios

Descripció El Jefe de proyecto estima el cambio solicitado en base al esfuerzo n indicado en la actividad previa. En caso de que el costo del cambio supere al margen de seguridad (este es el margen que un proyecto puede extenderse en esfuerzos y costos pero que sigue siendo asumido por la Organización) de la “Planilla de Tiempo, Esfuerzo y Costo (TEC)” inicial se genera una “Planilla TEC” y una “Orden de servicio” adicional. Todos los cambios deben quedar registrados en la “Planilla de administración de Entradas Solicitud de requerimientos, Planilla de Tiempo, Esfuerzo y Costo (TEC) Salidas Solicitud de requerimientos, Planilla administración de requerimientos, Orden de servicio Roles Jefe de proyecto, Área comercial 4.4. Tarea: Aprobar Cambios (1)

Descripció n Entradas Salidas Roles

El Gerente de proyectos revisa la solicitud de cambio y aprueba la solicitud. Solicitud de requerimientos Solicitud de requerimientos Gerente de proyectos

4.5. Tarea: Aprobar Cambios (2)

Descripció n Entradas Salidas Roles

El Cliente aprueba la ejecución del cambio de requerimientos bajo las condiciones indicadas en la “Solicitud de requerimientos”. Solicitud de requerimientos Solicitud de requerimientos Cliente

61

4.6. Tarea: Aprobar Órdenes de Servicio Adicionales

Descripció n Entradas Salidas Roles

El Cliente aprueba la “Orden de servicio” adicional en caso de que el costo del cambio supere el margen de seguridad de la “Planilla TEC”. Orden de servicio Orden de servicio Cliente

4.7. Tarea: Actualizar Línea Base de Requerimientos

Descripció Se actualiza la línea base de requerimientos incorporando los cambios n aprobados, permitiendo la disponibilidad de los datos a todo el Equipo de proyecto. Entradas Solicitud de requerimientos Salidas Planilla de administración de requerimientos Roles Jefe de proyecto 4.8. Tarea: Actualizar Planes y otros Artefactos

Descripció El Jefe de proyecto actualiza los planes que se vean afectados por los cambios n y gestiona la actualización de otros artefactos administrativos que pudiesen verse afectados, permitiendo la disponibilidad de los datos a todo el Equipo del proyecto. Entradas Solicitud de requerimientos, Planilla de administración de requerimientos Salidas Plan de proyecto Roles Jefe de proyecto

62

Artefactos y Roles Actividad/Tarea 1

Entradas Salidas Comprender Requerimientos

1.1

Identificar Contraparte

1.2

Revisar Requerimientos

ERS Modelo de casos de uso Análisis preliminar

1.3

Asegurar Entendimiento Común de Requerimiento

ERS

2 2.1

2.2

Plan de proyecto Asignación de roles

ERS Modelo de casos de uso Análisis preliminar Plan de revisiones Planilla de administración de ERS

Comprometer Requerimientos Evaluar Impacto y Análisis Planilla TEC Orden Factibilidad preliminar de servicio

Negociar y Registrar Compromisos

3 3.1

Revisar Consistencia de Requerimientos

3.2

Analizar Inconsistencia de Requerimientos

Planilla TEC Orden de servicio

Planilla de administración de requerimientos

Seguir Requerimientos Planilla de administración de requerimientos Plan de revisiones Plan de proyecto Carta Gantt de proyecto Planilla de administración de requerimientos

Roles

Gerente de proyectos Jefe de proyecto Jefe de proyecto Gerente de proyectos

Jefe de proyecto Equipo de proyecto Jefe de proyecto Área comercial Equipo de proyecto Jefe de proyecto Área comercial Equipo de proyecto Jefe de proyecto

Jefe de proyecto

63

3.3

3.4

4 4.1

4.2

4.3

4.4 4.5 4.6 4.7

4.8

Identificar Cambios Plan de en Planes proyecto Carta Gantt de proyecto Planilla de administración Iniciar Acciones Correctivas

Plan de proyecto Carta Gantt de proyecto Planilla de administración de requerimientos Administrar Cambios Recepcionar Solicitud de Solicitud de Cambio de requerimientos requerimientos Requerimiento Minuta de reunión Analizar Cambios Solicitud de Solicitud de requerimientos requerimientos Planilla de administración de requerimientos Estimar Cambios Solicitud de Solicitud de requerimientos requerimientos Planilla TEC Planilla administración de requerimientos Orden Aprobar Cambios Solicitud de Solicitud de (1) requerimientos requerimientos Aprobar Cambios Solicitud de Solicitud de (2) requerimientos requerimientos Orden de servicio Aprobar Ordenes de Orden de Servicio adicionales servicio Actualizar Línea Solicitud de Planilla de Base de requerimientos administración de Requerimientos requerimientos Actualizar Planes y Solicitud de Plan de proyecto otros Artefactos requerimientos Planilla de administración de requerimientos

Jefe de proyecto

Jefe de proyecto

Jefe de proyecto Cliente Jefe de proyecto Analista

Jefe de proyecto Área comercial

Gerente de proyectos Cliente Cliente Jefe de proyecto Jefe de proyecto

Tabla 1. Artefactos y Roles de Administración de Requerimientos.

64

C.1. Planificación del proyecto

Versión

65

Planificación del Proyecto 1.

Descripción General

Propósito Establecer planes razonables para ejecutar las tareas por parte del grupo de trabajo y la administración del proyecto, estimando los recursos necesarios, estableciendo los compromisos y definiendo el plan para realizar el trabajo. Objetivos Establecer y mantener parámetros de planificación del proyecto. Establecer y mantener un plan de proyectos como la base para administrar el proyecto Establecer y mantener compromisos con el plan de proyecto Notas Introductorias Para determinar el estado de las actividades de planificación, se deberá medir y analizar los tiempos y esfuerzos utilizados en las actividades de planificación. Dentro de planificación del proyecto se establece un plan para la actualización, distribución y el control de todos los documentos del proyecto. Además se establece el método para identificar, recopilar, codificar, clasificar, acceder, archivar, almacenar, disponer y mantener al día todos los registros del proyecto.

66

Diagrama General

Figura 6. Área de Procesos: Planificación del Proyecto

67

Actividades y Tareas 1.

Actividad: Preparar la Propuesta

Figura 7. Actividad: Preparar la Propuesta.

68

1.1.

Tarea: Generar Estructura de Directorio del Proyecto

Descripción

Se genera en el repositorio de proyectos un directorio con estructura definida, con el fin de otorgar privilegios y permisos a los miembros de la Organización de acuerdo a sus roles. Este directorio será utilizado para almacenar toda la información del proyecto, sea esta entregable o no. Las decisiones al respecto deben documentarse en el artefacto “Plan de administración de configuraciones”. Se puede usar el artefacto “Plantilla de estructura de directorio” como modelo de estructura. Para conocer artefactos relacionados con la mantención de la información del proyecto y sus privilegios y permisos, refiérase a tarea Generar Plan de Administración de Configuraciones del área de procesos Administración de Configuraciones.

Entradas Salidas

Plan de administración de configuraciones

Roles

Jefe de proyecto, Administrador de configuraciones

1.2.

Tarea: Generar Lista de Riesgos Preliminar

Descripción

Tiene por finalidad determinar los riesgos del proyecto que se está cotizando. La misma deberá ser desarrollada en función de experiencia en proyecto similares o bien de riesgos que sean fácilmente detectables a raíz de la documentación entregada por el Cliente.

Entradas

Solicitud de cotización

Salidas

Lista de riesgos

Roles

Gerente de proyectos, Grupo de ingeniería de software

1.3.

Tarea: Desarrollar Planilla de Tiempo, Esfuerzo y Costo (TEC)

Descripción Entradas

Estimar con detalles el tiempo, esfuerzo y costo de los requerimientos levantados en el artefacto “Análisis preliminar”. Análisis preliminar, Especificación de ambientes, Lista de riesgos

Salidas

Planilla de Tiempo, Esfuerzo y Costo (TEC)

Roles

Gerente de proyectos, Grupo de ingeniería de software, Área comercial

69

1.4.

Tarea: Generar Asignación de Roles Preliminar

Descripción

Definir los responsables de ejercer cada uno de los roles del proyecto. Esta primera versión de la asignación de roles permite identificar la brecha de habilidades y conocimientos necesarios para el desarrollo del proyecto, los que serán incorporados en el “Plan del proyecto” e informados a los responsable de las capacitaciones (Grupo de ingeniería de procesos) para que se planifiquen las actividades de capacitación requeridas. Además se identifica, por parte del Cliente, quienes serán los participantes del proyecto y sus responsabilidades.

Entradas

Planilla TEC

Salidas

Asignación de roles, Plan de proyecto, Lista de necesidades de entrenamiento

Roles

Gerente de proyectos

1.5.

Tarea: Generar Carta Gantt Preliminar

Descripción

Definir la “Carta Gantt de proyecto” identificando fechas de inicio y término de cada fase y las tareas macro de cada una de estas.

Entradas

Planilla TEC, Asignación de roles, Lista de riesgos

Salidas Roles

Carta Gantt de proyecto

1.6.

Gerente de proyectos, Grupo de ingeniería de software

Tarea: Generar Configuración de Proceso

Descripción

La configuración de proceso depende del tipo y tamaño del proyecto, y de la experiencia del Jefe del proyecto. Se identifican los artefactos que se deben desarrollar y en qué fase se elaborarán. Adicionalmente se debe preparar la primera versión del “Glosario” del proyecto.

Entradas Salidas

Planilla de configuración de proceso, Glosario

Roles

Gerente de proyectos, Grupo de Ingeniería de Software

1.7.

Tarea: Generar Propuesta

Descripción

Basándose en el Planilla TEC, Carta Gantt de proyecto y otros artefactos desarrollados se debe generar un documento de “Propuesta” para el Cliente.

Entradas

Planilla TEC, Asignación de roles, Carta Gantt de Proyecto, Lista de riesgos

Salidas

Propuesta

Roles

Área comercial, Administración y finanzas

70

1.8.

Tarea: Revisar Propuesta

Descripción

2.

Entradas

Revisar la “Propuesta” antes de enviarla al Cliente para evitar errores de forma y de fondo. Propuesta, Plan de revisiones

Salidas

Propuesta

Roles

Gerente de proyectos

Actividad: Planificar el Proyecto

Figura 8. Actividad: Planificar el Proyecto.

71

2.1.

Tarea: Generar Plan de Proyecto

Descripción

De acuerdo al tamaño del proyecto se debe generar el documento “Plan de proyecto”, registrando en él las actividades a realizar. El “Plan de proyecto” permite hacer referencia a todos los artefactos utilizados para la administración del proyecto.

Entradas Salidas

Propuesta, Lista de riesgos, Asignación de roles, Carta Gantt de proyecto, Planilla de Plan de proyecto

Roles

Jefe de proyecto

2.2.

Tarea: Actualizar Asignación de Roles

Descripción

Asignar el personal definitivo al proyecto. Se define y registra quién desempeña qué rol en el proyecto, de esta forma todo el equipo del proyecto conoce tempranamente sus responsabilidades en el mismo. También se debe actualizar, de ser necesario, las responsabilidades de la contraparte, es decir, del Cliente.

Entradas

Asignación de roles

Salidas Roles

Asignación de roles

2.3.

Gerente de proyectos, Jefe de proyecto

Tarea: Desarrollar Carta Gantt con Actividades, Plazos y Recursos

Descripción

Actualizar la “Carta Gantt de proyecto” y realizar la “Carta Gantt de Iteración”. Estas definen qué actividades deben cumplirse y quiénes son los responsables de las mismas.

Entradas

Carta Gantt de proyecto, Planilla de Tiempo, Esfuerzo y Costo (TEC), Análisis preliminar, Plan de proyecto, Asignación de roles

Salidas

Carta Gantt de proyecto, Carta Gantt de iteración

Roles

Jefe de proyecto, Grupo de ingeniería de software, Grupo de ingeniería de sistemas

2.4.

Tarea: Actualizar Riesgos

Descripción

Actualizar la “Lista de riesgos” del proyecto para la iteración que se realizará.

Entradas

Lista de riesgos

Salidas

Lista de riesgos

Roles

Jefe de proyecto

72

2.5.

Tarea: Revisar Plan de Proyecto

Descripción

El Gerente de proyectos revisa el “Plan de proyecto” y los artefactos asociados a la planificación

Entradas

Plan de proyecto, Asignación de roles, Planilla de configuración de proceso, Carta Gantt de proyecto, Carta Gantt de iteración

Salidas

Plan de proyecto

Roles

Gerente de proyectos

2.6.

Tarea: Generar Documento de Lanzamiento del Proyecto

Descripción

A partir de la documentación generada se confecciona el artefacto “Presentación de lanzamiento del Proyecto”, el cual presenta los aspectos más importantes del proyecto. Este documento puede contener las expectativas, riesgos y criterios de éxito identificados en el artefacto “Análisis de entrevistas a involucrados”.

Entradas

Análisis preliminar, Análisis de entrevistas a involucrados, Asignación de roles, Lista de riesgos, Carta Gantt de proyecto

Salidas

Presentación de lanzamiento de proyecto

Roles

Jefe de proyecto, Gerente de proyectos

2.7.

Tarea: Hacer Reunión de Lanzamiento del Proyecto

Descripción

Reunión con todos los involucrados en el proyecto: Equipo de proyecto, Cliente y/o Proveedor (si aplica), más Involucrados relevantes. En esta se da a conocer la visión sobre el proyecto, se muestran las diferencias entre las expectativas y los requerimientos. Se presentan los riesgos, equipos y los principales hitos. Con esta reunión también se pretende comprometer a los involucrados en el proyecto tempranamente, estableciendo y acordando compromisos que permitan cumplir con los objetivos del proyecto.

Entradas

Presentación de lanzamiento de proyecto

Salidas

Minuta de reunión

Roles

Gerente de proyectos, Jefe de proyecto, Equipo de proyecto, Involucrados

73

3.

Actividad: Planificar la Siguiente Iteración

Figura 9. Actividad: Planificar la Siguiente Iteración. 3.1.

Tarea: Generar Carta Gantt de la Siguiente Iteración

Descripción

En todas las iteraciones, excepto la última, es necesario definir las fechas de las actividades de la próxima iteración. Se actualiza el “Plan de proyecto” y todos los artefactos relacionados con éste.

Entradas

Plan de proyecto

Salidas

Carta Gantt de iteración, Plan de proyecto

Roles

Jefe de proyecto

74

1.

Artefactos y Roles

Actividad/Tarea Entradas Salidas Roles 1 Preparar la Propuesta Plan de administración Jefe de proyecto 1.1 Generar Estructura de de configuraciones Administrador de Directorio del configuraciones Proyecto Solicitud de cotización Lista de riesgos Gerente de proyectos 1.2 Generar Lista de Riesgos Preliminar Grupo de ingeniería de software 1.3 Desarrollar Planilla de Análisis preliminar Tiempo, Esfuerzo y Especificación de Costo (TEC) ambientes Lista de riesgos

Planilla TEC

Gerente de proyectos Grupo de ingeniería de software Área comercial

1.4 Generar Asignación de Planilla TEC Roles Preliminar

Asignación de roles Plan de proyecto Lista de necesidades de entrenamiento

Gerente de proyectos

1.5 Generar Carta Gantt General Preliminar

Carta Gantt de proyecto

Gerente de proyectos, Grupo de ingeniería de software

Planilla de configuración de proceso

Gerente de proyectos, Grupo de ingeniería de software

Planilla TEC Asignación de roles Lista de riesgos

1.6 Generar Configuración de Proceso

1.7 Generar Propuesta

Planilla TEC Propuesta Asignación de roles Carta Gantt de Proyecto Lista de riesgos

Área comercial Administración y finanzas

1.8 Revisar Propuesta

Propuesta Propuesta Plan de revisiones Planificar el Proyecto Propuesta Plan de proyecto Lista de riesgos Asignación de roles Carta Gantt de proyecto Planilla de configuración de proceso

Gerente de proyectos

2 2.1 Generar Plan de Proyecto

2.2 Actualizar Asignación Asignación de roles de Roles

Asignación de roles

Jefe de proyecto

Gerente de proyectos Jefe de proyecto

75

2.3 Desarrollar Carta Carta Gantt de Gantt con proyecto Planilla Actividades, Plazos y TEC Recursos Análisis preliminar Plan de proyecto Asignación de roles

Carta Gantt de proyecto Carta Gantt de iteración

Jefe de proyecto Grupo de ingeniería de software Grupo de ingeniería de sistemas

2.4 Actualizar Riesgos 2.5 Revisar Plan de Proyecto

Lista de riesgos Plan de proyecto Asignación de roles Planilla de configuración de proceso Carta Gantt de proyecto Carta Gantt de iteración

Lista de riesgos Plan de proyecto

Jefe de proyecto Gerente de proyectos

2.6 Generar Documentos de Lanzamiento del Proyecto

Análisis preliminar Presentación de Análisis de entrevistas a lanzamiento de proyecto involucrados Asignación de roles Lista de Riesgos Carta Gantt de proyecto

Jefe de proyecto Gerente de proyectos

2.7 Reunión de Lanzamiento del Proyecto

Presentación de Minuta de reunión lanzamiento de proyecto

Gerente de proyectos Jefe de proyecto Equipo de proyecto Involucrados

3 3.1 Generar Carta Gantt de la Siguiente Iteración

Planificar la Siguiente Iteración Carta Gantt de Plan de proyecto iteración Plan de proyecto

Jefe de proyecto

Tabla 2. Artefactos y Roles de Planificación del Proyecto.

76

C.3. Aseguramiento de la calidad en productos y procesos

Versión

77

Aseguramiento de Calidad de Procesos y Productos Descripción General Propósito Proveer al personal y a los administradores (o la gerencia) de una visión objetiva del proceso y los productos de trabajo asociados, revisando y auditando los productos y actividades para verificar el cumplimiento con los procedimientos y estándares e informando de los resultados de las revisiones y auditorias. Objetivos • Evaluar objetivamente procesos y productos de trabajo y servicios. • Comunicar y asegurar resolución de incumplimientos y establecer registros. Notas Introductorias Para determinar el estado de las actividades de garantía de calidad se deben medir y analizar: •

El tiempo y esfuerzo utilizado en las actividades de garantía de calidad.

•

El número de problemas no resueltos con relación a los problemas reportados

78

Diagrama General

Figura 18. Área de Procesos: Aseguramiento de Calidad de Procesos y Productos.

Actividades y Tareas 1.

Tarea: Desarrollar Plan de Aseguramiento de Calidad

Descripción

Definir los artefactos que serán revisados durante el proyecto y las excepciones al proceso que deben ser consideradas. Establecer un calendario de revisiones.

Entradas Salidas

Plan de proyecto

Roles

Analista de calidad

Plan de aseguramiento de calidad de procesos y productos, Planilla de verificación de proceso

79

2.

Tarea: Revisar Procesos y Productos

Descripción

Se revisan los artefactos y actividades definidos en el “Plan de aseguramiento de calidad de procesos y productos” y aquellos con observaciones debido a revisiones previas, si es que se han realizado. El proceso es revisado de acuerdo a la “Planilla de configuración de proceso” descrita por el Jefe de proyecto. Todas las observaciones quedan registradas en la “Planilla de verificación de proceso”.

Entradas

Planilla de configuración de proceso, Plan de aseguramiento de calidad de procesos y productos

Salidas

Planilla de verificación de proceso

Roles

Analista de calidad

3.

Tarea: Seguir No Cumplimientos Previos

Descripción

Entradas

Los no cumplimientos son revisados periódicamente de acuerdo a la fecha de resolución comprometida por el Jefe de proyecto. En caso de mantenerse el incumplimiento se notifica al Gerente de proyectos. Planilla de verificación de proceso

Salidas

Planilla de verificación de proceso

Roles

Analista de calidad

4.

Tarea: Monitorear el Plan de Aseguramiento de Calidad

Descripción

El Analista de calidad monitorea que se estén llevando a cabo las actividades definidas en el “Plan de aseguramiento de calidad de procesos y productos”. Si existen re-planificaciones en el “Plan de proyecto” o si fuese necesario, el Analista de calidad actualiza el “Plan de aseguramiento de calidad de procesos y productos”.

Entradas

Plan de proyecto, Plan de aseguramiento de calidad de procesos y productos

Salidas

Plan de aseguramiento de calidad de procesos y productos

Roles

Analista de calidad

5.

Tarea: Comunicar Resultados de No Cumplimientos

Descripción

Los no cumplimientos detectados son comunicados al Jefe de proyecto para su revisión. Este deberá definir, dentro de los 3 días hábiles siguientes a la revisión, una fecha de resolución para los problemas detectados o argumentar por qué no aplica la observación realizada por el Analista de calidad. El Analista de calidad revisa las observaciones y fechas comprometidas por el Jefe de proyecto y comunica la revisión al Gerente de proyectos.

Entradas Salidas Roles

Analista de calidad, Jefe de proyecto.

80

C.4. Monitoreo y control del proyecto

Versión

81

Monitoreo y Control del Proyecto Descripción General Propósito Otorgar una adecuada visibilidad respecto al avance del proyecto de forma tal de permitir tomar acciones correctivas cuando el proyecto se desvía significativamente de los planes. Objetivos Monitorear el rendimiento real y el avance del proyecto contra el plan del proyecto. Gestionar acciones correctivas cuando el rendimiento del proyecto o los resultados se desvían significativamente del plan. Diagrama General

Figura 10. Área de Procesos: Monitoreo y Control de Proyecto.

82

Actividades y Tareas 1. Actividad: Monitorear y Controlar el Proyecto

Figura 11. Actividad: Monitorear y Controlar el Proyecto.

83

1.1.

Tarea: Hacer Seguimiento de Actividades Planificadas

Descripción

Se realizan seguimientos de las actividades planificadas contra el avance real del proyecto. Se re planifican actividades y se establecen acciones correctivas y preventivas en función de los resultados del seguimiento. La periodicidad de las reuniones de proyecto se establece en el “Plan de proyecto”. El Jefe de proyecto se asegura que el cronograma refleja el avance de las tareas. Los miembros del Equipo de proyecto reportan en forma habitual el grado de avance y el esfuerzo gastado, en el artefacto “Planilla de registro de horas”. Como parte del seguimiento habitual, el Jefe de proyecto compila o produce métricas e indicadores que indican el estado de la administración del proyecto y/o del producto. Estas métricas son utilizadas para oportunamente controlar el avance e informar a la dirección sobre el estado del proyecto.

Entradas

Plan de proyecto, Carta Gantt de proyecto, de registro de horas

Salidas

Plan de proyecto, Carta Gantt de proyecto, Carta Gantt de iteración

Roles

Jefe de proyecto, Equipo de proyecto

1.2.

Carta Gantt de iteración, Planilla

Tarea: Revisar Reportes de Aseguramiento de Calidad de Producto y Proceso

Descripción

Tras cada revisión realizada por el Analista de calidad, según el “Plan de aseguramiento de calidad de procesos y productos” y registrada en la “Planilla de verificación de proceso”, el Jefe de proyecto deberá revisar las observaciones de este reporte y especificar fecha de resolución de los problemas encontrados o argumentar disconformidades con la revisión.

Entradas

Plan de aseguramiento de calidad de procesos y productos, Planilla de verificación de proceso

Salidas

Planilla de verificación de proceso

Roles

Jefe de proyecto

1.3.

Tarea: Hacer Seguimiento de Riesgos del Proyecto

Descripción

El Jefe de proyecto realiza seguimiento de riesgos en forma habitual, tomando acción o escalándolos cuando su probabilidad o impacto se eleve. Al final de cada iteración (o fase) o ante cambios relevantes del proyecto se revisa la “Lista de riesgos”, se actualiza en función de cómo se ven los riesgos ya levantados y se incorporan nuevos riesgos detectados.

Entradas

Lista de riesgos

Salidas

Lista de riesgos

Roles

Jefe de proyecto, Equipo de proyecto

84

1.4.

Tarea: Hacer Reunión de Seguimiento

Descripción

Reunión de seguimiento para discutir con el Cliente los avances del proyecto. En base a los resultados de la reunión el Jefe de proyecto deberá actualizar los artefactos que se vean afectados por las decisiones tomadas.

Entradas

Plan de proyecto, Lista de riesgos, Carta Gantt de proyecto

Salidas

Minuta de reunión

Roles

Jefe de proyecto, Cliente

1.5.

Tarea: Evaluar Estado

Descripción

Al finalizar cada fase y ante eventos especiales del proyecto se realizará una presentación al Cliente e involucrados relevantes el estado del proyecto en un momento dado, normalmente al final de cada fase o iteración. Con esto se pretende comprometer a los involucrados en el monitoreo y control del proyecto.

Entradas Salidas

Planilla de administración de requerimientos, Lista de riesgos, Asignación de roles, Plan de proyecto, Carta Gantt de proyecto, Carta Gantt de iteración Planilla de evaluación de estado, Presentación de estado de avance

Roles

Jefe de proyecto, Gerente de proyectos, Cliente, Involucrados

1.6.

Tarea: Actualizar Trazabilidad

Descripción

Cada vez que se cumpla un hito de configuración de piezas de software (ej. versiones alfa, entregas internas o al Cliente), se debe actualizar la “Planilla de administración de requerimientos” de manera de mantener la trazabilidad actualizada con los nuevos entregables del proyecto. Para más detalles refiérase al área de procesos Administración de Requerimientos.

Entradas

Planilla de administración de requerimientos

Salidas

Planilla de administración de requerimientos

Roles

Jefe de proyecto, Grupo de ingeniería de sistemas, Grupo de ingeniería de software

1.7.

Tarea: Comunicar Cambios a los Afectados

Descripción

Comunicar al equipo del proyecto cualquier cambio realizado en la planificación del proyecto para la ejecución de las acciones correctivas y preventivas establecidas.

Entradas

Plan de proyecto, Lista de riesgos, Carta Gantt de proyecto, Minuta de reunión

Salidas Roles

Jefe de proyecto, Gerente de proyectos, Cliente, Involucrados

85

2.

Actividad: Cerrar el Proyecto

Figura 12. Actividad: Cerrar el Proyecto.

2.1.

Tarea: Resolver Temas Pendientes de Aseguramiento de Calidad de Proceso y Producto

Descripción

El Gerente de proyectos debe revisar los temas pendientes de calidad con el Jefe de proyecto y el Equipo de proyecto ser necesario, para tomar decisiones que permitan resolver las observaciones recibidas. Se completan las acciones que sean necesarias, tales como poner al día documentación.

Entradas

Planilla de verificación de proceso

Salidas Roles 2.2.

Gerente de proyectos, Jefe de proyecto, Equipo de proyecto Tarea: Recolectar Métricas del Proyecto

Descripción Entradas

A partir de la “Planilla de registro de horas” recolectar los datos planificados versus reales. Planilla de registro de horas

Salidas

Planilla de evaluación de estado

Roles

Jefe de proyecto

86

2.3.

Tarea: Generar y Enviar Acta de Entrega

Descripción

Producir una lista detallada de los materiales entregados al Cliente, incluyendo las versiones de software, configuraciones de hardware que pudieran aplicar y versiones de la documentación entregada. Redactar el “Acta de entrega” del proyecto adjuntando la documentación generada por el proyecto y definida como entregable. Enviar el “Acta de entrega” junto con la “Encuesta de satisfacción del cliente” al Cliente para ser retirados durante el cierre del proyecto.

Entradas Salidas

Acta de entrega, Encuesta de satisfacción del cliente

Roles

Jefe de proyecto

2.4.

Tarea: Realizar Cierre del Proyecto

Descripción

Realizar una sesión de lecciones aprendidas con el Equipo de proyecto y Proveedores de ser necesario, para identificar lo que trabajó bien o dio inconvenientes durante el proyecto. Completar el documento de “Presentación de cierre del proyecto” y presentarlo al Cliente para obtener retroalimentación de éste con respecto al proyecto finalizado. Asegurarse que hay una transferencia adecuada de repositorios, información y configuraciones de los archivos, de manera que se garantice el mantenimiento y reutilización del producto. Se debe poner atención a aspectos de seguridad, confidencialidad y propiedad intelectual que sean pertinentes.

Entradas

Plan de proyecto, Planilla de evaluación de estado

Salidas

Presentación de cierre del proyecto, Acta de entrega

Roles

Gerente de proyectos, Equipo del proyecto, Cliente, Involucrados, Proveedores

87

Artefactos y Roles Actividad/Tarea 1

Entradas Salidas Monitorear y Controlar el Proyecto

1.1 Hacer Seguimiento de Actividades Planificadas

Roles

Plan de proyecto Carta Plan de proyecto Carta Jefe de proyecto Gantt de proyecto Gantt de proyecto Equipo de proyecto Carta Gantt de iteración Carta Gantt de iteración Planilla de registro de horas

Plan de aseguramiento Planilla de verificación Jefe de proyecto 1.2 Revisar Reportes de Aseguramiento de Calidad de calidad de procesos de proceso de Producto y Proceso y productos Planilla de verificación de proceso

1.3 Hacer Seguimiento de Riesgos del Proyecto 1.4 Hacer Reunión de Seguimiento

Lista de riesgos

Lista de riesgos

Plan de proyecto Lista de riesgos Carta Gantt de proyecto

Minuta de reunión

1.5 Evaluar Estado

Planilla de Planilla de evaluación administración de de estado Presentación requerimientos Lista de de estado de avance Riesgos Asignación de roles Plan de proyecto Carta Gantt de proyecto Carta Gantt de iteración

Jefe de proyecto Gerente de proyectos Cliente Involucrados

1.6 Actualizar Trazabilidad

Planilla de administración de requerimientos

Jefe de proyecto Grupo de ingeniería de sistemas Grupo de ingeniería de software

Planilla de administración de requerimientos

Jefe de proyecto Equipo de proyecto Jefe de proyecto Cliente

Tabla 3. Artefactos y Roles de Monitoreo y Control del Proyecto

88

Actividad/Tarea 1.7 Comunicar Cambios a los Afectados

2

Entradas Plan de proyecto Lista de riesgos Carta Gantt de proyecto Minuta de reunión

Salidas

Cerrar el Proyecto 2.1 Resolver Temas Pendientes Planilla de verificación de Aseguramiento de de proceso Calidad de Proceso y Producto 2.2 Recolectar Métricas del Proyecto

Planilla de registro de horas

Gerente de proyectos Jefe de proyecto Equipo de proyecto

Jefe de proyecto

Acta de entrega Jefe de proyecto Encuesta de satisfacción del cliente

2.3 Generar y Enviar Acta de Entrega

2.4 Realizar Cierre del Proyecto

Planilla de evaluación de estado

Roles Jefe de proyecto Gerente de proyectos Cliente Involucrados

Plan de proyecto Planilla de evaluación de estado

Presentación de cierre del proyecto Acta de entrega

Gerente de proyectos Equipo del proyecto Cliente Involucrados Proveedores

89

C.5. Medición y análisis

Versión

90

Descripción General Propósito Desarrollar y mantener una capacidad de medición para dar soporte a la administración de información necesaria, y así contar con datos relevantes a la hora de tomar decisiones. Objetivos Alinear los objetivos y actividades de medición con las necesidades y objetivos identificados de información. Proveer resultados de las mediciones que se enfoquen en las necesidades y objetivos de información. Diagrama General

Figura 15. Área de Procesos: Medición y Análisis.

91

Actividades y Tareas 1. Actividad: Definir Objetivos de la Medición

Figura 16. Actividad: Definir Objetivos de la Medición 1.1.

Tarea: Establecer Objetivos de la Medición

Descripción

Se establecen cuáles son las necesidades de información cuantificable del proyecto. Esta información provee un “Listado de objetivos” que deben documentarse en el “Plan de mediciones” del artefacto “Plan de proyecto”.

Entradas Salidas

Plan de proyecto

Roles

Jefe de proyecto, Gerente de proyectos, Grupo de ingeniería de procesos

92

1.2.

Tarea: Especificar Métricas

Descripción

Se definen las métricas para cada objetivo de medición. Se definen métricas base que se obtienen directamente de la medición y métricas derivadas que son el resultado de la combinación de dos o más métricas base. Ambos tipos de métricas se registran en el “Plan de mediciones” del artefacto “Plan de proyecto”.

Entradas

Plan de proyecto

Salidas

Plan de proyecto

Roles

Grupo de ingeniería de procesos

1.3.

Tarea: Especificar Procedimientos de Recolección y Almacenamiento de Datos

Descripción

Entradas

Se definen los métodos para recolectar datos, para asegurar que están siendo obtenidos apropiadamente. También se definen los procedimientos de almacenamiento de los datos y cómo estos podrían ser recuperados para asegurar que estén disponibles y accesibles para un uso futuro. Esta información se registra en el “Plan de mediciones” del artefacto “Plan de proyecto”. Plan de proyecto

Salidas

Plan de proyecto

Roles

Grupo de ingeniería de procesos

1.4.

Tarea: Especificar Procedimientos de Análisis

Descripción Entradas

Se define cómo los datos de las mediciones serán analizados, además se seleccionan los datos, métodos y herramientas adecuados para el análisis. Plan de proyecto

Salidas

Plan de proyecto

Roles

Grupo de ingeniería de procesos

1.5.

Tarea: Informar Métricas Definidas a Involucrados

Descripción

Se informa acerca de las definiciones de métricas a los interesados.

Entradas

Plan de proyecto

Salidas Roles

Jefe de proyecto

93

Artefactos y Roles Actividad/Tarea 1 Desarrollar Plan de Aseguramiento de Calidad

Entradas Plan de proyecto

Salidas Roles Plan de aseguramiento Analista de calidad de calidad de procesos y productos Planilla de verificación de proceso

2 Revisar Procesos y Productos

Planilla de configuración de proceso Plan de aseguramiento de calidad de procesos y productos

Planilla de verificación Analista de calidad de proceso

3 Seguir No Cumplimientos Previos

Planilla de verificación Planilla de verificación Analista de calidad de proceso de proceso

4 Monitorear el Plan de Aseguramiento de Calidad

Plan de proyecto Plan de aseguramiento de calidad de procesos y productos

5 Comunicar Resultados de No Cumplimientos

Plan de aseguramiento de calidad de procesos y productos

Analista de calidad

Analista de calidad Jefe de proyecto

Tabla 6. Artefactos y Roles de Aseguramiento de Calidad de Procesos y Productos.

94

C.6. Administración / Gestión de la configuración

Versión

95

Descripción General Propósito Establecer y mantener la integridad de los productos de trabajo usando identificación de configuración, control de configuración, control de estado de la configuración y auditoria de configuración. Objetivos •

Identificar las líneas base y establecer los productos de trabajo.

•

Seguir y controlar los cambios a los productos de trabajo bajo administración de configuración.

•

Establecer y mantener la integridad de las líneas base.

Notas Introductorias Una línea base es un conjunto de especificaciones o productos de trabajo que han sido formalmente revisados y aceptados, y que sirve como base para futuros desarrollos. Puede ser modificada sólo a través del procedimiento de actualización de línea base. Para determinar el estado de las actividades de configuraciones y versiones es preciso medir y analizar los tiempos y esfuerzos utilizados en la administración de configuraciones y versiones.

96

Diagrama General

Figura 19. Área de Procesos: Administración de Configuraciones.

97

Actividades y Tareas 1.

Tarea: Realizar Auditorias

Descripción

El Analista de calidad planifica las auditorías del repositorio del proyecto en el “Plan de aseguramiento de calidad de procesos y productos” y las ejecuta de acuerdo a las fechas establecidas en el “Plan de proyecto”, para verificar la integridad de las líneas base (por ej. revisar si la línea base satisface algún estándar requerido, revisar la correctitud y completitud de los Ítems de Configuración (ICs)). El Administrador de configuraciones deberá apoyar en esta actividad.

Entradas

Plan de aseguramiento de calidad de procesos y productos

Salidas

Planilla de verificación de proceso

Roles

Analista de calidad, Administrador de configuraciones

2.

Actividad: Generar Línea Base Inicial

Figura 20. Actividad: Generar Línea Base Inicial. 2.1.

Tarea: Generar Plan de Administración de Configuraciones

98

Descripción

Se debe generar un “Plan de administración de configuraciones” para cada proyecto, donde se identifican responsables, se describen el sistema de administración de la configuración definido para el proyecto, los procedimientos para administrar las configuraciones, se identifican los ítems de configuración (incluyendo la planificación de versiones e hitos de configuración) y las herramientas de apoyo (software y hardware) a la gestión de configuración. Este artefacto debe sincronizarse además con el “Plan de documentación” contenido en el artefacto “Plan de proyecto”.

Entradas

Plan de proyecto

Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

2.2.

Tarea: Obtener Línea Base Inicial

Descripción

Se solicita al Cliente los artefactos requeridos para iniciar el desarrollo

Entradas Salidas Roles 2.3.

Administrador de configuraciones Tarea: Categorizar Línea Base

Descripción

Se deben definir los ítems de configuración e indicar para cada uno de los artefactos su versión y categoría (código fuente, bases de datos, documentación). La definición de los ítems de configuración queda registrada en el “Plan de administración de configuraciones”.

Entradas Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

2.4.

Tarea: Ingresar Artefactos a la Base de Datos de Administración de Configuraciones (BDAC)

Descripción

Ingresar los artefactos catalogados a la BDAC generando la primera línea base del proyecto. El repositorio del proyecto puede elaborarse de varias formas. Entre las más frecuentes se encuentran: 1) una instancia separada de repositorio durante el desarrollo, desde el cual se suben líneas bases a otro repositorio formal que contiene versiones liberadas por el proyecto. 2) un desarrollo en un medio de trabajo que hace promociones en la misma biblioteca según hitos (por ej. en SVN es trunk, branches, tags).

Entradas Salidas Roles

Administrador de configuraciones

99

3.

Actividad: Administrar Ítems de Configuración

Figura 21. Actividad: Administrar Ítems de Configuración. 3.1.

Tarea: Distribuir Ítems de Configuración

Descripción

El Administrador de configuraciones envía al Equipo de proyecto y/o Proveedores involucrados los ICs (ítems de configuración) requeridos por cada uno de ellos, dejando registro de la versión de IC enviada a cada uno en el “Plan de administración de configuraciones”.

Entradas Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

100

3.2.

Tarea: Recibir Ítems de Configuración e Ingresarlos a la Base de Datos de Administración de Configuraciones (BDAC)

Descripción

El Administrador de configuraciones recibe los ICs actualizados y recatalogados además de los nuevos ICs a ser incorporados a la BDAC.

Entradas Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

3.3.

Tarea: Distribuir Ítems de Configuración a Integradores

Descripción

El Administrador de configuraciones envía a los Integradores de sistemas los ICs requeridos, dejando registro de la versión de IC enviada en el “Plan de administración de configuraciones”.

Entradas Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

3.4. Tarea: Recibir Ítems de Configuración de Integradores e Ingresarlos a la Base Datos de Administración de Configuraciones (BDAC) Descripción

de

El Administrador de configuraciones recibe los ICs actualizados y recatalogados además de los nuevos ICs a ser incorporados a la BDAC

Entradas Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

3.5.

Tarea: Distribuir Ítems de Configuración para Pruebas

Descripción

El Administrador de configuraciones envía a los Testeadores los ICs requeridos, dejando registro de la versión de IC enviada en el “Plan de administración de configuraciones”.

Entradas Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

3.6.

Tarea: Recibir Ítems de Configuración de Testeadores e Ingresarlas a la Base de Datos de Administración de Configuraciones (BDAC)

Descripción

El Administrador de configuraciones recibe los ICs actualizados y recatalogados además de los nuevos ICs a ser incorporados a la BDAC. En este punto debe generarse una nueva línea base, según el procedimiento descrito en el “Plan de administración de configuraciones”.

Entradas Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

101

4.

Actividad: Actualizar Línea Base

Figura 22. Actividad: Actualizar Línea Base. 4.1.

Tarea: Autorizar Nueva Línea Base

Descripción

El Jefe de proyecto autoriza la publicación de una nueva línea base. Esta nueva línea base puede deberse a cambios en los ICs (ítems de configuración) enviados por el Cliente o por la incorporación de nuevas funcionalidades producto del proyecto.

Entradas Salidas

Plan de administración de configuraciones

Roles

Jefe de proyecto

4.2.

Tarea: Publicar Nueva Línea Base

Descripción

El Administrador de configuraciones verifica que todos los ICs se encuentren catalogados correctamente para su promoción y genera la nueva línea base.

Entradas Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

4.3.

Tarea: Notificar a los Afectados sobre Línea Base

Descripción

El administrador de configuraciones notifica a todos los involucrados que correspondan sobre la nueva Línea Base (Jefe de proyecto, Equipo de proyecto, etc.).

Entradas Salidas Roles

Administrador de configuraciones

102

5.

Actividad: Seguir y Controlar Cambios

Figura 23. Actividad: Seguir y Controlar Cambios. 5.1.

Tarea: Analizar y Documentar Solicitudes de Cambio

Descripción

Si por motivos externos al Equipo de proyecto se hace necesario realizar cambios en la línea base, debe registrarse como solicitud y el impacto de este tipo de cambios es evaluado para asegurar que sean consistentes con los requerimientos del proyecto. Este tipo de cambios deben ser evaluados al igual que un cambio de requerimientos (Refiérase al área de procesos Administración de Requerimientos para mayor detalle).

Entradas Salidas

Solicitud de requerimientos

Roles

Administrador de configuraciones

5.2.

Tarea: Revisar y Seguir el Estado de las Solicitudes de Cambio

Descripción

Como todo cambio de requerimiento, la solicitud de cambio sobre la línea base debe ser aprobada por el Jefe de proyecto, el Administrador de configuraciones, el Gerente de proyectos y por el Cliente, esta actividad puede ser realizada en una reunión o a través de un e-mail destacando los acuerdos que el cambio implica.

Entradas

Solicitud de requerimiento

Salidas

Minuta de Reunión

Roles

Administrador de configuraciones, Gerente de proyectos, Jefe de proyecto, Cliente

103

5.3. Descripción

Tarea: Controlar los Ítems de Configuración (ICs) Los cambios a los ICs son controlados a lo largo del ciclo de vida del proyecto, también se debe buscar una autorización apropiada (si se requiere) antes que los cambios sean ingresados al sistema de administración de configuraciones.

Entradas Salidas Roles

Administrador de configuraciones 5.4.

Tarea: Revisar y Documentar Cambios de los ICs

Descripción

Se registran y verifican los ICs desde el sistema de administración de configuraciones de modo de mantener su correctitud e integridad. Se realizan revisiones para asegurar que todas las versiones se encuentran en el repositorio de administración de configuraciones del proyecto.

Entradas

Plan de administración de configuraciones

Salidas

Plan de administración de configuraciones

Roles

Administrador de configuraciones

104

Artefactos y Roles Actividad/Tarea 1 Realizar Auditorias

Entradas Plan de aseguramiento de calidad de procesos y productos

Salidas Planilla de verificación de proceso

2

Generar Línea Base Inicial Plan de Plan de proyecto administración de configuraciones

Roles Analista de calidad Administrador de configuraciones

2.1

Generar Plan de Administración de Configuraciones

2.2

Obtener Línea Base Inicial

2.3

Categorizar Línea Base

2.4

Ingresar Artefactos a la Base de Datos de Administración de Configuraciones (BDAC)

3.1

Distribuir Ítems de Configuración

3.2

Recibir Ítems de Configuración e Ingresarlos a la Base de Datos de Administración de Configuraciones (BDAC) Distribuir Ítems de Configuración a Integradores

Plan de administración de configuraciones

Administrador de configuraciones

Plan de administración de configuraciones

Administrador de configuraciones

Recibir Ítems de Configuración de Integradores e Ingresarlos a la Base de Datos de Administración de Configuraciones (BDAC) Distribuir Ítems de Configuración para Pruebas

Plan de administración de configuraciones

Administrador de configuraciones

Plan de administración de configuraciones

Administrador de configuraciones

3

3.3

3.4

3.5

Plan de administración de configuraciones

Administrador de configuraciones

Administrador de configuraciones Administrador de configuraciones

Administrador de configuraciones

Administrar Ítems de Configuración Plan de administración de configuraciones

Administrador de configuraciones

105

Actividad/Tarea 3.6 Recibir Ítems de Configuración de Testeadores e Ingresarlas a la Base de Datos de Administración de Configuraciones (BDAC)

4 4.1 Autorizar Nueva Línea Base

Entradas

Salidas Roles Plan de administración Administrador de configuraciones de configuraciones

Actualizar Línea Base Plan de administración Jefe de proyecto de configuraciones

4.2 Publicar Nueva Línea Base

Plan de administración Administrador de de configuraciones configuraciones

4.3 Notificar a los Afectados sobre Línea Base 5 5.1 Analizar y Documentar Solicitudes de Cambio 5.2 Revisar y Seguir el Estado de las Solicitudes de Cambio

Administrador de configuraciones Seguir y Controlar Cambios Solicitud de requerimientos Solicitud de Minuta de Reunión requerimientos

5.3 Controlar los Ítems de Configuración (ICs) 5.4 Revisar y Documentar Cambios de los ICs

Administrador de configuraciones Administrador de configuraciones Gerente de Proyectos Jefe de proyecto Cliente Administrador de configuraciones

Plan de administración de configuraciones

Plan de administración de configuraciones

Administrador de configuraciones

Tabla 7. Artefactos y Roles de Administración de Configuraciones.

106