CAPÍTULO 11
COMPETISOFT: MEJORA DE PROCESOS SOFTWARE PARA PEQUEÑAS ORGANIZACIONES
Hanna Oktaba Mario Piattini Francisco J. Pino Félix García Tomás Martínez Claudia Alquicira Francisco Ruiz
1. INTRODUCCIÓN
La industria de software representa una actividad económica de suma importancia para muchos países del mundo, siendo una oportunidad que los países en vía de desarrollo ven viable y desean aprovechar. Esta industria a nivel mundial está formada en mayor medida por micro, pequeña y medianas empresas desarrolladoras de software – PyMEs– que suponen cerca del 90% de los negocios formales y generan entre el 40 y el
50 por ciento del empleo total. Sin embargo, estas empresas de software tienen serios problemas de madurez en sus procesos de desarrollo y en la mayoría de los casos la operación de sus procesos es caótica, lo que afecta a toda la organización (Batista et al., 2000). Esta situación es especialmente crítica ya que conlleva problemas asociados como falta de competitividad y consecuentemente limitaciones de crecimiento.
Desde hace varios años la comunidad de Ingeniería del Software a nivel mundial ha expresado especial interés en la mejora de procesos software (Software Process Improvement –SPI–) en PyMEs. Pero sólo recientemente han aparecido estándares y propuestas relacionadas con SPI para PyMEs, como por ejemplo: Impact (Scott et al., 2001), Processus (Horvat et al., 2000), Adept (McCaffery et al., 2006), Rapid (Cater- Steel et al., 2005), MoProSoft (NYCE, 2005), EvalProSoft (NYCE, 2006), MPS.BR (Weber et al., 2005), Agile SPI (Hurtado et al., 2006), MARES (Anacleto et al., 2004), MesoPyME (Calvo-Manzano, 1999).
Las PyMEs han intentando asegurar la calidad de sus productos software a través de la mejora de la capacidad de sus procesos, debido a dos razones fundamentales:
Por imagen, un factor clave en los objetivos de mantener el mercado local y tratar de establecer una posición en el mercado global con el fin de exportar software, y
Por necesidad, para poder hacer de sus proyectos unidades administrativas eficaces y eficientes.
Muchas PyMEs pueden plantearse asegurar la calidad de sus productos a través de la mejora del proceso y la acreditación en modelos de calidad de organismos tales como el Software Engineering Institute –SEI– y ella International Organization for Standardization –ISO– (Mayer&Bunge, 2004). Sin embargo, la preparación previa a la acreditación en estos estándares es larga y costosa, porque los modelos de mejora, proceso y evaluación como los propuestos por el SEI ey la ISO están estructurados (y han sido construidos) para ser aplicables a grandes empresas (Saiedian et al., 1997).
Diversos estudios presentan que la aplicación de éstos es difícil para las PyMEs debido a que un proyecto de mejora siguiendo modelos orientados a grandes organizaciones supone una gran inversión en dinero, tiempo y recursos, además las recomendaciones son complejas de aplicar y el retorno de la inversión se produce a largo plazo (Batista et al., 2000; Calvo-Manzano, 1999; Hareton et al., 2001; Saiedian et al., 1997). Además, en las PyMEs la aplicación de estos modelos se agrava aún más ya que existe un problema
“cultural” importante cuando se quiere “importar” y adoptar, sin más, modelos creados para otro tipo de organizaciones, ya que, como señala Zahran en (Zahran, 1998) si el proceso no “casa” con la cultura de la organización será rechazado por el “cuerpo”
organizacional como sucede en los transplantes de órganos. Un problema parecido, se expone en la investigación de Dyba (Dyba, 2005), en el que se destaca las importantes diferencias culturales en el éxito de la mejora de procesos software entre las empresas de EEUU y de Europa.
En el presente capítulo se presenta el proyecto COMPETISOFT1, el cual es una iniciativa integradora de diferentes propuestas de mejora de procesos software para micro, pequeñas y medianas empresas desarrolladoras de software, teniendo en cuenta para su desarrollo las características propias de este tipo de organizaciones. Este proyecto también tiene en cuenta algunos elementos de los estándares internacionales creados por instituciones como el SEI e ISO, entre los cuales se destacan CMMI (SEI, 2002), ISO/IEC 12207 (ISO_12207, 2004), ISO/IEC 15504 (ISO_15504-2, 2004). El proyecto COMPETISOFT es financiado por CYTED2 con el objetivo de incrementar el nivel de competitividad de las PyMEs Iberoamericanas productoras de software mediante la creación y difusión de un marco metodológico común que, ajustado a sus necesidades específicas, pueda llegar a ser la base sobre la cual establecer un mecanismo de evaluación y certificación de la industria del software.
Además de esta introducción, el capítulo presenta en la sección 2 los trabajos previos relacionados. En la sección 3 se da una visión general del método de investigación utilizado, y en la sección 4 se presenta el marco metodológico del proyecto COMPETISOFT. Finalmente, la sección 5 muestra las conclusiones y futuros trabajos.
2. TRABAJOS RELACIONADOS
En (Pino et al., 2006) se presenta un estado del arte de la literatura acerca de los esfuerzos SPI llevados a cabo en PyMEs, con el objetivo de conocer qué se ha realizado y logrado sobre mejora de procesos software en este tipo de empresas. Además, existen diferentes trabajos sobre estándares y propuestas relacionadas con SPI para PyMEs, algunas de las cuales se presentan a continuación:
La Secretaría de Economía de México creó el Programa para el Desarrollo de la Industria del Software (PROSOFT) que ha dado origen al Modelo de Procesos para la Industria de Software (MoProSoft (NYCE, 2005)) y al Método de Evaluación de Procesos para la Industria de Software (EvalProsoft (NYCE, 2006)). El objetivo es la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software que resulte apropiada a las características de las empresas mexicanas de desarrollo y mantenimiento de software que en su gran mayoría son PyMEs. MoProSoft pretende proporcionar un modelo basado en las mejores prácticas internacionales, fácil de entender, fácil de aplicar y no costoso en su adopción, para apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora continua; elevando la capacidad de sus procesos para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. MoProSoft define tres categorías de procesos: Alta Dirección –DIR–, Gestión –GES– y Operación –OPE–. Para cada uno de los procesos especifica tres partes: definición general del proceso, prácticas y guías de ajuste. Basa su estrategia de mejora en que la organización debe
1 Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica
2 Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo
establecer la disciplina de implantación de los procesos definidos por el modelo. Los procesos deben evolucionar con base en las sugerencias de mejora alcanzando los objetivos del plan estratégico de la organización con metas cada vez más ambiciosas. De esta manera la organización puede ir logrando la madurez a través de la mejora continua de sus procesos.
El gobierno de Brasil financió la implementación del programa PBQP- Software (Productivity and Quality Software Program) (Bedini et al., 2005) y se ha desarrollado el proyecto “MPS.BR” (melhoria do processo de software brasileiro) (Weber et al., 2005), cuyo objetivo principal es definir e implementar un modelo para la mejora de procesos de software orientado a las micro, pequeñas y medianas empresas de forma que estas obtengan un nivel de madurez 2 o 3 de CMMI a un costo accesible. El proyecto propone tres modelos para la mejora del proceso software: un Modelo de Referencia (MR-MPS), un Método de Evaluación (MA-MPS) y un Modelo de Negocio (MN-MPS). El modelo de negocio define los elementos e interacciones involucrados para la certificación de la empresa a través de la implementación del modelo de referencia de dos maneras: personalizada para una empresa o conjunta entre un grupo de empresas (logrando así costos más accesibles para las PyMEs). El modelo de referencia MR-MPS contiene los requisitos que los procesos de las unidades de la organización deben cumplir para estar en conformidad con el modelo propuesto, e incluye también las definiciones de los niveles de capacidad, procesos y atributos del proceso. La guía de evaluación contiene el proceso, y el método de evaluación MA-MPS y los requisitos para los evaluadores e instituciones evaluadoras. El proceso y el método de evaluación MA-MPS siguen la norma ISO/IEC 15504-2.
En Colombia se llevó a cabo el proyecto SIMEP-SW financiado por Colciencias3 y la Universidad del Cauca con el fin de crear, aplicar y probar un sistema de mejora que integrara elementos de modelos de calidad, mejora y evaluación reconocidos internacionalmente, adaptados a las características propias de la industria del software colombiana. Se pretende que los proyectos de mejora que realicen las empresas de Colombia sigan un modelo nacional coherente a las características propias de la idiosincrasia y aterrizadas al contexto socio-económico del país. El principal resultado de este proyecto es el marco de trabajo Agile SPI (Hurtado et al., 2006), con la premisa esencial que los modelos utilizados son ligeros y basados en estándares internacionales. Básicamente se estructura a partir de los componentes primarios de un programa de mejora:
una guía de mejora y unos modelos de soporte. Para el caso de Agile SPI, los modelos de soporte son: Light Quality Model (el modelo de referencia de proceso), Light Evaluation Model (el modelo de evaluación de procesos), y Light Metrics Model (el modelo de medidas de proceso).
Además hay dos elementos integradores de toda la estructura: Framework PDS (el modelo conceptual de soporte) y Agile SPI Process (la guía de
3 Instituto colombiano para el desarrollo de la Ciencia y la Tecnología
mejora que integra de manera dinámica los componentes). Agile SPI basa su estrategia de mejora en proporcionar a las PyMEs un proceso ágil que guía un programa SPI acorde a sus necesidades, el cual cuenta con los elementos básicos para hacer posible que se pueda llevar a cabo esfuerzos de mejora en este tipo de organizaciones.
En Europa se han impulsado iniciativas como ESSI (European Software and System Initiative) que han promovido diferentes proyectos para fortalecer SPI en PyMEs, como por ejemplo SPIRE (Software Process Improvement in Regions of Europe)(SPIRE, 1993) y TOPS (Toward Organised Software Processes in SMEs) (Esprit_Project, 1999). También se han desarrollado trabajos relacionados como PROCESSUS (Horvat et al., 2000) y Adept (McCaffery et al., 2006), entre otros y se han realizado investigaciones en donde se realizan ajustes de modelos de mejora como IDEAL para ser aplicados a PyMEs como muestra el estudio presentado en (Casey et al., 2004). También MesoPyME (Calvo-Manzano, 1999) ha sido creado en España para guiar la mejora en pequeñas empresas.
En Australia el proyecto IMPACT (Scott et al., 2001) y el método Rapid (Cater-Steel et al., 2005) también persiguen este objetivo.
Por otro lado las organizaciones internacionales como el SEI e ISO comienzan a realizar esfuerzos con miras a que sus estándares de mejora de procesos software (o adaptaciones de éstos) puedan ser aplicados a micro y pequeñas empresas desarrolladoras de software. Es así como el SEI se ha interesado en el área de mejora de procesos para
“Small Settings” (Improving Processes in Small Settings –IPSS–) (SEI, 2006), donde.
Eel término Small Settings hace referencia a equipos pequeños, proyectos pequeños, organizaciones pequeñas y/o pequeñas empresas pequeñas.
También ISO trabaja en este sentido y ha conformando el grupo de trabajo SC7- WG24 con el objetivo de establecer un marco común para describir perfiles evaluables del ciclo de vida de software para ser usados en Very Small Enterprises –VSEs–
(ISO_WG_24, 2006). Definiéndose una VSE como una organización de menos de 25 empleados. El producto inicial será centrado en procesos software con extensiones para los procesos de ingeniería de sistemas. Se planea producir un estándar y dos guías que ayuden a las VSEs a producir productos software de una manera disciplinada y profesional.
Siguiendo esta filosofía el proyecto COMPETISOFT ha puesto en marcha una iniciativa integradora de diferentes propuestas relacionadas con la mejora de procesos software para micro, pequeñas y medianas empresas desarrolladoras de software. La estructura del marco metodológico desarrollado permite que pueda ser utilizado por cualquier PyME, que considere este marco adecuado para su programa de mejora de procesos. Además el proyecto COMPETISOFT sigue la estrategia de brindar a las PyMEs la definición de modelos que faciliten la adopción e implantación de diferentes estándares creados por proyectos u organizaciones nacionales ó internacionales. El proyecto COMPETISOFT no pretende ser una “competencia” de los modelos
internacionales del SEI o ISO, sino un apoyo para que las PyMEs, en el futuro, puedan iniciar y abordar programas de mejora de procesos con miras a obtener posteriormente certificaciones en este tipo de estándares.
3. MÉTODO DE INVESTIGACIÓN
El método de investigación empleado en la definición, refinamiento y aplicación de los modelos de COMPETISOFT se denomina Investigación-Acción (I-A).
Investigación-Acción es una forma de investigar de carácter colaborativo que busca unir la teoría y la práctica entre investigadores y profesionales mediante un proceso de naturaleza cíclica. Este método está orientado a la producción de nuevo conocimiento útil en la práctica, que se obtiene mediante el cambio y/o búsqueda de soluciones a situaciones reales (Avison et al., 1999). Los resultados de esta experiencia deben ser beneficiosos tanto para el investigador como para los profesionales. Una premisa fundamental en esta forma de investigar es que los procesos sociales complejos (y el uso de tecnologías de la información en organizaciones es de este tipo) pueden ser estudiados mejor introduciendo cambios en dichos procesos y observando los efectos que se producen (Baskerville, 1999). En la figura 11.1 se muestra un esquema representativo de I-A en el proyecto COMPETISOFT.
Figura 11.1. Aplicación del método Investigación-Acción al proyecto COMPETISOFT.
Los participantes involucrados en el proyecto se dividen en dos grupos: el primero está compuesto por investigadores de distintas universidades y el segundo, denominado
grupo de consulta critica, engloba a los profesionales informáticos de PyMEs desarrolladoras de software y organismos de estandarización.
4. MARCO METODOLÓGICO DE COMPETISOFT
Debido a que en algunos países de Iberoamérica se han desarrollado estrategias nacionales para abordar la mejora de procesos en PyMEs, COMPETISOFT parte de los resultados de estas diferentes iniciativas (véase figura 11.2), entre las que se puede destacar: (i) MoProSoft y EvalProSoft, desarrollados al interior del programa mexicano PROSOFT; (ii) Agile SPI desarrollado dentro del proyecto colombiano SIMEP-SW; (iii) MPS.BR desarrollado y coordinado en Brasil, (iv) MARES desarrollada en Brasil, la cual es una guía para conducir evaluaciones de procesos software conforme a ISO/IEC 15504-2 enfocada en PyMEs; y (v) las metodologías españolas MANTEMA [24](Polo et al., 2002) y METRICA v34. Esto permite que el proyecto se fortalezca con la experiencia de estos trabajos desarrollados previamente, ya que en los grupos participantes del proyecto COMPETISOFT se cuenta con personas que han trabajado en el desarrollo de estas iniciativas.
Figura 11.2. Enfoque general del proyecto COMPETISOFT.
Desde esta perspectiva, el Modelo de Referencia de Procesos de COMPETISOFT es una evolución y refinamiento del modelo de procesos propuesto en MoProSoft, al cual se le añaden elementos de la metodología de mantenimiento de software MANTEMA.
El Modelo de Evaluación de COMPETISOFT es un ajuste de EvalProSoft a las
4 http://www.csi.map.es/csi/metrica3/
necesidades del proyecto, teniendo en cuenta también elementos de los modelos de evaluación de MPS.BR y MARES. El Modelo de Mejora de COMPETISOFT parte y propone una adecuación del modelo y proceso de mejora de Agile SPI. Estos tres modelos serán desarrollados y adaptados según las necesidades de la industria software a partir de la experiencia que proporcionan los investigadores, las PyMEs y las unidades gubernamentales que participanse involucran en el proyecto.
4.1 Modelo de Referencia de Procesos
El Modelo de Referencia de Procesos de COMPETISOFT, está basado en MoProSoft (NYCE, 2005) y agrupa los procesos en tres categorías principales: Alta dirección, Gestión y Operación. Esta división de procesos se ajusta a la organización funcional de una empresa. En la figura 11.3 se muestra las categorías de procesos de COMPETISOFT junto con los procesos que engloba cada una de ellas, en un diagrama de paquetes UML.
Figura 11.3. Categorías y nombres de los procesos del Modelo de Referencia de COMPETISOFT.
4.1.1 CATEGORÍA DE ALTA DIRECCIÓN
Dentro de la categoría de Alta dirección (DIR) se incluye únicamente el proceso de Gestión de Negocio (DIR.1) que engloba todas las prácticas relacionadas con la gestión de la empresa. Así establece los objetivos y las condiciones necesarias para lograrlos en función de las necesidades de los clientes y de los cambios que, propuestos a raíz de la evaluación de los resultados obtenidos, permitan alcanzar la mejora continua.
También debe capacitar a la organización para enfrentarse a un ambiente de cambio, a sus miembros para trabajar en función de los objetivos establecidos, e incluir la gestión de empresa virtual y la conectividad inter-compañía como una oportunidad de negocio en la industria del software actual. Estos últimos son puntos a tener en cuenta por compañías que participan en clusters o redes virtuales y son requisitos clave para garantizar la supervivencia de las PyMEs en el mercado actual. Este proceso desarrolla
tres actividades fundamentales: Planificación Estratégica, Preparación para la Realización de una Estrategia, y Valoración y Mejora Continua de la Organización.
4.1.2 CATEGORÍA DE GERENCIA
La Categoría de Gerencia (GER) está compuesta por cinco procesos, en los que se incluyen las prácticas necesarias para la gestión de procesos, proyectos y recursos en función de las directrices establecidas desde la Alta Dirección. Asimismo, se configura como punto de unión entre ésta y los procesos de la Categoría de Operación, a los cuales les proporciona los elementos necesarios para su funcionamiento y de los que sintetiza todos los resultados generados para comunicarlos a la dirección de la organización. Una descripción general de los procesos de ésta categoría se presenta a continuación:
El proceso de Gestión de Procesos (GES.1) se encarga de establecer los procesos de la organización en función de las necesidades recogidas en el Plan Estratégico. Asimismo, está encargado de definir planificar e implantar las actividades de mejora en los procesos, de los mecanismos de aseguramiento de calidad y las validaciones, tanto internas como externas.
Las actividades contempladas en este proceso son: la Planificación de Procesos, la Preparación a la Implantación y la Evaluación y Control de Procesos. Dentro de Gestión de Procesos se define un sub-proceso de evaluaciones internas (valoraciones) con el objetivo de generar datos de alta calidad que identifiquen las fortalezas, debilidades y riesgos de los procesos software y así brindar información que sirva de base para tomar decisiones al interior de la empresa en los aspectos que realmente la empresa debe mejorar. Además se ha defineido un cuestionario de valoración cuya finalidad es ayudar a las PyMEs en su primer contacto con la evaluación y mejora de la capacidad de sus procesos.
El segundo proceso de la Categoría de Gerencia es Gestión de Proyectos (GES.2). Todos los proyectos aprobados precisan de una planificación general, asignación de recursos y un seguimiento y evaluación de su ejecución. Además, hay que evaluar las alternativas de realización en el caso de los proyectos internos, y la generación, presentación de la propuesta, firma de contrato y cierre para las oportunidades de proyecto. El proceso de Gestión de Proyectos está orientado a asegurar que los proyectos, tanto internos, externos como las oportunidades de proyecto, contribuyan al cumplimiento de los objetivos y estrategias de la organización. También se aborda las técnicas de estimación de mejora, una necesidad fundamental para las PyMEs pero difícil de entender y llevar a cabo en este tipo de organizaciones. Este proceso incluye varias actividades: Planificación, Realización, y Evaluación y Control. Además se definen dos actividades más de apoyo en el caso de proyectos muy novedosos o con un nivel de riesgo elevado, estas son Concertación y Conceptualización.
El proceso de Gestión de Recursos Humanos (GES.3) tiene la finalidad de
proporcionar a la organización los recursos humanos necesarios para cubrir los roles establecidos, además de evaluar el ambiente de trabajo en el que éstos se desenvuelven para garantizar que se cumplen los objetivos marcados en el Plan Estratégico. Se pueden diferenciar tres actividades de este proceso: Preparación, Instrumentalización y Generación de Reportes, realizadas en función del Plan Estratégico, de los Planes de Adquisición y Capacitación y de las Acciones Correctivas de los proyectos y procesos.
El cuarto proceso de esta categoría es Gestión de Bienes, Servicios e Infraestructura (GES.4). La función principal de este proceso es proporcionar proveedores de estos tres elementos que satisfagan los requisitos de los procesos y proyectos, garantizando que se cumplen los objetivos del Plan Estratégico. Este proceso se divide en cuatro actividades, Preparación, Instrumentalización, Generación de Informes e Investigación de Tendencias Tecnológicas.
El último de los procesos de la Categoría de Gestión es Gestión de Conocimiento (GES.5). Este proceso tiene como cometido la administración de la base de conocimiento, un repositorio en el que se guarda la información y los productos generados por todos los procesos implementados en la organización. Se debe enfatizar la importancia de la reusabilidad que se puede alcanzar por medio del desarrollo de la base de conocimiento en la cual se almacenan todas las experiencias obtenidas. Con este propósito se deben considerar otras propuestas como la presentada en (Kurniawati et al., 2006). COMPETISOFT da gran importancia a la base de experiencia desde el principio y en todos los niveles organizacionales, sin tener en cuenta la calidad de los componentes almacenados en la base, puesto que todos pueden ser útiles. También se reconoce la importancia de un método más formal aunque ligero de captura de experiencias, apropiado para una pequeña organización, proporcionando una guía y estructura para ayudar a los usuarios en la creación de más experiencias para la base de conocimiento. Otras cuestiones importantes a abordar son la gestión de la documentación y gestión de la configuración.
4.1.3 CATEGORÍA DE OPERACIÓN
En la Categoría de Operación (OPE) se incluyen las prácticas de los proyectos de desarrollo y mantenimiento de software agrupadas en tres procesos. La Categoría de Operación se sitúa por debajo de la Categoría de Gerencia, por lo que realiza sus actividades de acuerdo a las directrices marcadas por ésta (en consonancia con los objetivos de la organización) y a la que entrega toda la información y productos generados. A continuación se muestra una descripción general de los procesos que integran ésta categoría:
El proceso de Administración de un Proyecto Específico (OPE.1) está encaminado a establecer y ejecutar de forma sistemática las actividades que permiten cumplir con los objetivos de un determinado proyecto en el
tiempo y costes planificados. Este proceso incluye cuatro actividades, Planificación, Realización, Evaluación y Control, y Cierre. En todas ellas se aplican los conocimientos, técnicas habilidades y herramientas disponibles dentro de la organización.
El segundo de los procesos que integra esta categoría es Desarrollo de Software (OPE.2), que se encarga de realizar sistemáticamente las actividades necesarias para crear productos software. Está compuesto por uno o más ciclos de desarrollo integrados por las actividades de Inicio, Requisitos, Análisis, Diseño, Construcción, Integración, Pruebas y Cierre.
Previa a la realización de todas estas fases, se realizan las actividades de Distribución de Tareas entre los miembros del Equipo de Trabajo, Verificación y Validación de los productos generados y la generación de un Informe de Actividades.
El proceso de Mantenimiento de Software (OPE.3) de COMPETISOFT se basa en la metodología para el Mantenimiento del Software MANTEMA (Polo et al., 2002). Da cobertura a todo el proceso que involucra el mantenimiento y modificación de productos software.
Los procesos presentados anteriormente se estructuran en un patrón de procesos, con el objetivo de que sea más intuitivo y fácil de usar por las PyMEs. El metamodelo del patrón de los procesos de referencia se presenta en la figura 11.4.
También se ha definido un conjunto de plantillas para la descripción de todos los productos que se crean en los distintos procesos, de esta forma se ayuda a los usuarios a estructurar, clasificar y entender la información generada usando los modelos desarrollados por el proyecto.
Además, con el fin de reducir costes en las PyMEs, se incorpora el uso y desarrollo de herramientas de código abierto y el desarrollo de técnicas específicas para la aplicación del proceso de usabilidad del software en este tipo de organizaciones.
En el Anexo A, se describe el proceso de Gestión de Negocio (Categoría de Alta Dirección) de COMPETISOFT versión 0.2, usando el patrón de procesos definido.
Figura 11.4. Metamodelo del patrón de procesos de COMPETISOFT.
4.2 Modelo de Evaluación
El modelo de evaluación de COMPETISOFT, que se basa en el método de evaluación EvalProSoft (NYCE, 2006) y ha sido diseñado en consonancia con la norma internacional ISO/IEC 15504 (ver figura 11.5), define cinco niveles de madurez para la organización: Realizado, Gestionado, Establecido, Predecible y Optimizado.
El modelo de capacidad de COMPETISOFT evalúa la capacidad de de los procesos en una escala de 0 a 5, donde cero específica que no hay procesos definidos y cinco que la organización ha alcanzado un nivel de mejora continua de sus procesos.
Cada uno de estos niveles de capacidad se divide en uno o dos atributos de capacidad de proceso. Cada atributo mide un aspecto particular del proceso, como se puede ver en la tabla 11.1.
Figura 11.5. Estructura del Modelo de Evaluación de COMPETISOFT.
Nivel Descripción y Atributos
0
Incompleto El proceso no está implantado o no alcanza sus objetivos.
1
Realizado
El proceso está implantado y realiza su propósito.
o AP 1.1 Atributo de realización del proceso.
2
Gestionado
El proceso se implanta de manera administrada y sus productos de trabajo están establecidos, controlados y mantenidos.
o AP 2.1 Atributo de Gestión de la Realización
o AP 2.2 Atributo de Gestión del Producto de Trabajo.
3
Establecido
El proceso se implanta mediante un proceso definido, que es capaz de alcanzar los resultados del proceso.
o AP 3.1 Atributo de Definición del Proceso
o AP 3.2 Atributo de Implantación del Proceso
4
Predecible
El proceso opera dentro de unos límites para alcanzar el objetivo marcado.
o AP 4.1 Atributo de Medición del Proceso
o AP 4.2 Atributo de Control del Proceso
5
Optimizado
El proceso es continuamente mejorado par lograr las metas de negocio actuales y futuras.
o AP 5.1 Atributo de Innovación del proceso
o AP 5.2 Atributo de Optimización del Proceso.
Tabla 11.1. Niveles de capacidad de los procesos y sus atributos asociados Cada uno de los elementos descritos anteriormente tienen una escala específica para su medición, es así que para los atributos de proceso y sus correspondientes
prácticas de gestión los valores se reflejan en una escala discreta compuesta por los siguientes elementos: (i) C: completamente alcanzados, entre 86% y 100 %; (ii) A:
ampliamente alcanzados, entre 51% y 85%; (iii) P: parcialmente alcanzados, entre 16% y 50%; y (iv) N: no alcanzados, entre 0% y 15%.
En función de la calificación de los atributos del proceso, se obtiene el nivel de capacidad de un proceso. A partir de los niveles de capacidad de los procesos que están dentro del alcance de la evaluación se determina el perfil del nivel de capacidad de los procesos de la empresa. Cuando el alcance de evaluación incluye a todos los procesos de la organización, se le asigna a éesta un nivel de madurez, que corresponde con el máximo nivel de capacidad alcanzado por todos los procesos. En la tabla 11.2 se puede ver que el nivel de capacidad de un proceso es aquel cuyos atributos son, al menos, ampliamente alcanzados (A) y el cumplimiento de todos los atributos de niveles inferiores es completamente alcanzados (C).
Nivel Alcanzado
Evaluación de los Atributos
AP 1.1 AP 2.1 AP 2.2 AP 3.1 AP 3.2 AP 4.1 AP 4.2 AP 5.1 AP 5.2
Realizado A
Gestionado C A A
Establecido C C C A A
Predecible C C C C C A A
Optimizado C C C C C C C A A
Tabla 11.2. Calificación del nivel de capacidad de un proceso.
El modelo de evaluación define un proceso de evaluación conforme al patrón de procesos del modelo de referencia de COMPETISOFT. Esto permite que el proceso de evaluación se integre como un proceso más dentro de la organización. El modelo de evaluación soporta tres usos:
Evaluación para la acreditación de capacidades: permite a un evaluador certificado evaluar el perfil del nivel de capacidad de los procesos implantados en una organización y determinar el nivel de madurez de ésta. Los resultados obtenidos pueden emplearse para iniciar un ciclo de mejora usando el modelo de mejora de COMPETISOFT. El nivel de madurez se puede usar para realizar una comparativa entre organizaciones.
Evaluación de capacidades de un proveedor: permite que los clientes de una organización soliciten a un evaluador certificado una evaluación para obtener el perfil de capacidad de ésta, de cara a contratar un servicio o seleccionar un proveedor. El cliente elige los procesos a evaluar en función del servicio requerido.
Autoevaluación de capacidades de un proceso: permite a una organización realizar una evaluación por su propio personal, sin que éestos sean evaluadores
certificados, para obtener el perfil del nivel de capacidad de cada uno de lospor procesos.
Este resultado se puede emplear para iniciar un ciclo de mejora.
El proceso de evaluación es un elemento integrador de algunos de los modelos desarrollados en COMPETISOFT como se muestra en la figura 11.6. Este proceso debe guiar las actividades de evaluación a lo largo de todo el proyecto de mejora.
Figura 11.6. Entidades de la evaluación de procesos software
En el proyecto COMPETISOFT se ha desarrollado un conjunto de medidas para medir el rendimiento y la capacidad de los procesos software basados en el modelo de evaluación descrito:
El primer tipo de medidas está relacionado con la dimensión de la capacidad, y su objetivo es medir la capacidad de un proceso teniendo en cuenta los atributos de proceso de los niveles de capacidad definidos por el método de evaluación. Por cada atributo de proceso, la “medida de capacidad” se basa en la medición de los indicadores de: (i) las prácticas genéricas realizadas, (ii) los recursos genéricos utilizados y (iii) los productos de trabajo genéricos obtenidos en el proceso.
El segundo tipo se relaciona con la dimensión del proceso, y su objetivo es medir el rendimiento de un proceso teniendo en cuenta las características de los procesos definidos por el modelo de referencia de procesos de COMPETISOFT. Para cada proceso la “medida de rendimiento” se basa en la medición de los indicadores de: (i) las prácticas software realizadas y (ii) los productos de trabajo obtenidos en el proceso.
Tras la ejecución de la evaluación, se obtienen el Informe de Resultados y el Informe Estadístico. El primero contiene el perfil del nivel de capacidad de procesos y el nivel de madurez de la organización, además de un resumen de los hallazgos significativos encontrados. El segundo de los informes contiene datos relativos a la evaluación realizada.
4.3 Modelo de Mejora
El modelo de mejora de COMPETISOFT está basado en Agile SPI (Hurtado et al., 2006). Se caracteriza por ser un modelo ligero con el fin de facilitar su aplicabilidad en las PyMEs desarrolladoras de software. El modelo de mejora presenta un proceso, iterativo e incremental, organizado a través de pequeños ciclosproyectos de mejora que abarcan diferentes casos de mejora dentro del proyectoograma global de mejora de la organización. Un caso de mejora es una oportunidadunidad atómica de mejora en las áreas de procesos que la empresa ha seleccionado dependiendo de sus objetivos de negocio y el Plan Estratégico. El objetivo de esta estructuración es obtener resultados rápidos de mejora, con el fin de mantener la motivación sobre el proyecto de mejora en la organización.
Dentro del modelo de mejora se plantea satisfacer los siguientes propósitos:
Entrega temprana y continua de mejoras. La generación de resultados visibles a corto plazo implica que los usuarios involucrados en el proceso de mejora observen los frutos de su trabajo de manera temprana e incrementen así su nivel de motivación.
Diagnóstico continuo. Diagnosticar continuamente los procesos de la organización y el proyecto de mejora, con el fin de verificar si el proyecto de mejora es útil en la inclusión de mejoras en los procesos de la organización. Incluye llevar a cabo actividades de medición de procesos.
Colaboración entre grupos. Establecer una comunicación y colaboración efectiva entre los diferentes actores involucrados en el proyecto de mejora de procesos software.
Individuos motivados. Construir proyectos individuales, grupales y organizacionales en torno a individuos motivados hacia la mejora de procesos.
Además, el modelo de mejora de COMPETISOFT para el éxito del proyecto SPI promueve: (i) el desarrollo sostenido del proyecto de mejora, a través del trabajo continuo; (ii) una infraestructura técnica y de gestión, adecuada para soportar la mejora de procesos; y (iii) el aprendizaje continuo como una disciplina clave para el éxito. El modelo de mejora de COMPETISOFT define un conjunto de fases y disciplinas como muestra la figura 11.7:
Figura 11.7. Fases y disciplinas del Modelo de Mejora de COMPETISOFT El modelo de mejora de COMPETISOFT describe un proceso que guía la mejora de procesos de software en cinco fases, a continuación se explica brevemente cada una de ellas:
Instalación. Esta es la actividad de partida para el proyecto SPI. Debe existir una motivación por parte de la empresa para emprender un proyecto de mejora de sus procesos. Se crea una propuesta de mejora basada en las necesidades del negocio, que guíe a la organización a través de cada una de las actividades siguientes, esta propuesta debe ser aprobada por la alta dirección para garantizar la asignación de los recursos necesarios involucrados en el proyecto SPI. Se definen los objetivos de mejora, los cuales son establecidos a partir de las necesidades de la empresa. También se debe estructurar una infraestructura de gestión, la cual describe la manera en la cual se organizan las personas comprometidas dentro del proyecto SPI. Esta infraestructura organiza el proyecto SPI teniendo en cuenta un equipo de gestión – EG –, un equipo de tecnología de procesos – ETP – y equipos de mejora – EM –.
Diagnóstico. En esta actividad ya se ha iniciado un proyecto SPI. Se realizan tareas de valoración de procesos software para saber cuál es el estado general de los procesos de la empresa. Además, se realiza un análisis de los resultados de la valoración con el fin de establecer la prioridad de los casos de mejora. Este análisis sirve para crear el plan general de mejora.
Formulación. En esta actividad se toman los casos de mejora de mayor prioridad, según los resultados arrojados por la valoración de procesos hecha en la actividad de diagnóstico y se realiza la planificación de una primera (o nueva) iteración de mejora, el objetivo en un principio es
realizar una medida del esfuerzo que sirva de base para la estimación del esfuerzo que tomará llevar a cabo el resto del proyecto de mejora.
Mejora. En esta actividad se ejecuta los casos de mejora, basados en la estimación hecha en la fase anterior, y se gestiona todo el esfuerzo involucrado en éstos. Se realizan las planificaciones correspondientes a las diferentes iteraciones que pueden resultar con cada uno de los casos de mejora definidos. Se genera un documento donde se registra la ejecución de los pilotos de prueba, la evaluación de la mejora por la introducción de los nuevos procesos y por el perfeccionamiento de los procesos ya existentes.
Si los planes piloto se han desarrollado satisfactoriamente se definen planes de aceptación e institucionalización de los nuevos procesos en la empresa.
Revisión del programa. En esta actividad se hace un análisis postmortem del cicloaso de mejora ejecutado antes de volver a comenzar la fase de inicio de un nuevo cicloaso de mejora. En esta fase todas las lecciones aprendidas y las métricas desarrolladas para medir el cumplimiento de los objetivos sirven como base de conocimiento o fuente de información para las personas involucradas en el siguiente ciclo de mejora. Con toda la información recolectada se debe evaluar el trabajo realizado y se deben corregir o ajustar todos los elementos relacionados con la ejecución del proyecto SPI, como la infraestructura establecida, los métodos utilizados y los canales de comunicación, entre otros.
El modelo de mejora incluye un conjunto de disciplinas que pueden ser aplicadas en menor o mayor medida dependiendo de la fase en la que se aplique y de las prioridades del proyecto de mejora. Una disciplina de mejora es un cuerpo de conocimiento altamente cohesivo asociado a un objetivo dentro del programa de mejora, tal como evaluar procesos, diseñar procesos, analizar procesos, aprender, entre otros. Las disciplinas definidas para el modelo de mejora son: Gestión del programa, Evaluación, Análisis de resultados, Diseño, Implementación, Gestión de la configuración, Aprendizaje y Entrenamiento.
5. CONCLUSIONES Y TRABAJO FUTURO
En el presente capitulo se ha presentado el proyecto COMPETISOFT, una iniciativa integradora de las diferentes propuestas de mejora de procesos software para micro, pequeñas y medianas empresas desarrolladoras de software, teniendo en cuenta para su desarrollo las características propias de este tipo de organizaciones.
La evaluación y mejora de procesos software hecha a la medida de las características especiales de las PyMEs es el principal reto hacia el que se dirige COMPETISOFT, ya que empresas de este tipo necesitan sobrevivir en un mercado global cada vez más competitivo pero no tienen suficientes recursos económicos para aplicar métodos pesados. Para culminar con éxito este objetivo, el proyecto COMPETISOFT cuenta con la participación activa de profesionales e investigadores pertenecientes a diferentes universidades, PyMEs y organizaciones gubernamentales de 13 países.
La próxima versión del marco COMPETISOFT será creada en 2008 e incluirá la realimentación y las lecciones aprendidas de la aplicación de los modelos de referencia de procesos, evaluación y mejora que se están llevando a cabo en diferentes empresas participantes en el proyecto.
6. AGRADECIMIENTOS
El presente trabajo está enmarcado dentro de los proyectos: COMPETISOFT (Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo – CYTED –, 506AC0287) y MECENAS (Junta de Comunidades de Castilla-La Mancha, Consejería de Educación y Ciencia, PBI06-0024).
7. BIBLIOGRAFÍA
Anacleto, A., C.G.v. Wangenheim, C.F. Salviano, y R. Savi. A Method for Process Assessment in Small Software Companies. 2004. 4th International SPICE Conference on Process Assessment and Improvement (SPICE 04). Portugal. pp. 69-76.
Avison, D., F. Lan, M. Myers, y A. Nielsen, Action Research. Communications of the ACM, 1999. Vol. 42(1) pp. 94-97.
Baskerville, R., Investigating Information Systems with Action Research.
Communications of the Association for Information Systems, 1999. Vol. 2(19).
Batista, J. y A. Figueiredo, SPI in a very small team: a case with CMM. Software Process: Improvement and Practice, 2000. Vol. 5(4) pp. 243-250.
Bedini, A., A. Llamosa, M. Pavlovic, y K. Steembecker. Quality Software Map of South America. 2005. Proceedings of the First International Research Workshop for Process Improvement in Small Settings. Pittsburgh. pp. 216-227.
Calvo-Manzano, J.A., Métodos de mejora del proceso de desarrollo de sistemas de información en la pequeña y mediana empresa. 1999, Universidad de Vigo.
Casey, V.e I. Richardson, A practical application of the IDEAL model. Software Process: Improvement and Practice, 2004. Vol. 9(3) pp. 123-132.
Cater-Steel, A.P., M. Toleman, y T. Rout, Process improvement for small firms: An evaluation of the RAPID assessment-based method. Information and Software Technology, 2005.pp. 1-12.
Dyba, T., An Empirical Investigation of the Key Factors for Success in Software Process Improvement. IEEE Transactions on Software Engineering, 2005. Vol. 31(5) pp. 410- 424.
Esprit_Project. Toward Organised Software Processes in SMEs. Esprit Project 27977 - TOPS. 1999. Disponible en: http://www.cordis.lu/esprit/src/27977.htm. 2006.
Fuggetta, A. Software process: a roadmap. 2000. International Conference on Software Engineering (ICSE). ACM Press. pp. 25-34.
Hareton, L. e Y. Terence, A process framework for small projects. Software Process:
Improvement and Practice, 2001. Vol. 6(2) pp. 67-83.
Horvat, R.V., I. Rozman, y J. Györkös, Managing the complexity of SPI in small companies. Software Process: Improvement and Practice., 2000. Vol. 5(1) pp. 45-54.
Hurtado, J., F. Pino, y J. Vidal. Software Process Improvement Integral Model: Agile SPI. Technical Report SIMEP-SW-O&A-RT-6-V1.0. 2005. Universidad del Cauca - Colciencias. Popayán, Colombia. 2006.
ISO_12207. ISO/IEC 12207:2002/FDAM 2. Information technology - Software life cycle processes. International Organization for Standardization. Ginebra. 2004.
ISO_15504-2. ISO/IEC 15504-2:2003/Cor.1:2004(E). Information technology - Process assessment - Part 2: Performing an assessment. International Organization for Standardization. Ginebra. 2004.
ISO_WG_24. ISO/IEC JTC1/SC7 Working Group 24. 2006. Disponible en: http://iso- iec-sc7wg24.gelog.etsmtl.ca/Webpage/iso-iec-sc7wg24_english.html.
Kurniawati, F. y R. Jeffery, The use and effects of an electronic process guide and experience repository: a longitudinal study. Information and Software Technology, 2006. Vol. 48(7) pp. 566-577.
Mayer&Bunge. Panorama de la Industria del Software en Latinoamérica. Mayer &
Bunge Informática LTDA. Brasil. 2004. Available on:
www.mbi.com.br/200409_panorama_industria_software_america_latina.pdf
McCaffery, F., I. Richardson, y G. Coleman. Adept – A Software Process Appraisal Method for Small to Medium-sized Irish Software Development Organisations. 2006.
European Systems & Software Process Improvement and Innovation (EuroSPI 2006).Joensuu, Finland. pp. 7.12-7.21.
NYCE. Modelo de Procesos para la Industria de Software - MoproSoft - Versión 1.3, Agosto de 2005. NMX-059/01-NYCE-2005. Organismo nacional de normalización y evaluación de la conformidad - NYCE. Ciudad de México. 2005.
NYCE. Método de Evaluación de procesos para la industria de software - EvalProSoft - Versión 1.1, Marzo de 2004. NMX-I-006/(01 al 04)-NYCE-2004. Organismo nacional de normalización y evaluación de la conformidad - NYCE. Ciudad de México. 2006.
Pino, F., F. Garcia, y M. Piattini, Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software (REICIS), 2006. Vol. 2(1) pp. 6-23.
Polo, M., M. Piattini, y F. Ruiz, Using a qualitative research method for building a software maintenance methodology. Software Practice and Experience, 2002. Vol.
32(13) pp. 1239-1260.
Saiedian, H. y N. Carr Characterizing a software process maturity model for small organizations. ACM SIGICE Bulletin, 1997. Vol. 23(1) pp. 2-11.
Scott, L., R. Jeffery, L. Carvalho, J. D'Ambra, y P. Rutherford. Practical Software Process Improvement -The IMPACT Project. 2001. Proceedings of the Australian Software Engineering Conference. pp. 182-189.
SEI. CMMI for Systems Engineering/Software Engineering, Version 1.1. Software Engineering Institute (SEI). Pittsburgh. 2002.
SEI. Improving Processes in Small Settings (IPSS Project). 2006. Disponible en:
http://www.sei.cmu.edu/iprc/ipssbackground.html.
SPIRE. Software Process Improvement in Regions of Europe (SPIRE). European Commission ESPRIT/ESSI Programme. 1993. Disponible en:
http://www.cse.dcu.ie/spire/.
Weber, K., E. Araújo, A. Rocha, Machado, D. Scalet, y C. Salviano, Brazilian Software Process Reference Model and Assessment Method, in Computer and Information Sciences. 2005, Springer Berlin / Heidelberg. p. 402-411.
Zahran, S., Software Process Improvement: Practical Guidelines for Business Success.
1998, Harlow, United Kingdom, Addison-Wesley.
ANEXO A: PROCESO DE GESTIÓN DE NEGOCIO
DEFINICIÓN GENERAL DEL PROCESO
Proceso DIR.1 Gestión de Negocio
Categoría Alta Dirección (DIR)
Propósito El propósito de Gestión de Negocio es establecer la razón de ser de la organización, sus objetivos y las condiciones para lograrlos, para lo cual es necesario considerar las necesidades de los clientes, así como evaluar los resultados para poder proponer cambios que permitan la mejora continua.
Adicionalmente habilita a la organización para responder a un ambiente de cambio y a sus miembros para trabajar en función de los objetivos establecidos.
Descripción El proceso de Gestión de Negocio se compone de la planificación estratégica, la preparación para la realización de la estrategia, y la valoración y mejora continua de la organización.
Planificación Estratégica: Establece las decisiones sobre qué es lo más importante para lograr el éxito de la organización, definiendo un Plan Estratégico, con los siguientes elementos:
- La Misión, Visión y Valores.
- Los Objetivos de la organización, incluyendo los objetivos de calidad, así como la forma de alcanzar éstos por medio de la definición de Estrategias.
- Análisis del Entorno para obtener un diagnóstico preciso de la organización que nos permita crear o reajustar una estrategia de negocios y, en función de ello, tomar decisiones acordes con los objetivos y políticas formulados. Este diagnóstico debe incluir: a) Diagrama de Flujo Situacional de los problemas asociados con el logro de los objetivos; b) Análisis de los Actores del entorno asociados con el logro de los objetivos y la realización del negocio/servicio, en términos de recursos, intereses, actitudes, motivaciones, etc.
- La forma de medir el logro de los Objetivos, por medio de la definición de Indicadores y Metas Cuantitativas asociadas a dichos Objetivos.
- Los Procesos Requeridos con sus indicadores y metas.
- La Cartera de Proyectos que habilite la ejecución de las Estrategias.
- La Estructura Organizacional y Estrategia de Recursos que soporten la implantación de los procesos y la ejecución de los proyectos definidos, considerando los elementos de la Base de Conocimiento necesarios para el almacenamiento y consulta de la información generada en la organización.
- El Presupuesto, el cual incluye los gastos e ingresos esperados.
- Periodicidad de Valoración del Plan Estratégico.
- Plan de Comunicación con el Cliente, incluye los mecanismos de comunicación con el cliente para su atención.
Preparación para la Realización: Se define el Plan de Comunicación e Implantación del Plan Estratégico que permite difundir éste a los miembros de la organización, asegurando que lo consideran el vehículo para lograr la satisfacción de las necesidades del cliente. En este plan también se establecen las condiciones adecuadas en el ambiente de la organización para la realización de los proyectos e implantación de los procesos.S
Valoración y Mejora Continua: Analiza los Reportes Cuantitativos y Cualitativos de los procesos y proyectos, Reporte de Acciones Correctivas o Preventivas Relacionadas con Clientes, Reportes Financieros, Propuestas Tecnológicas y considera los Factores Externos a la organización. A partir de los resultados del análisis se generan Propuestas de Mejoras al Plan Estratégico. Adicionalmente con base en Plan de Mediciones de Procesos que recibe de Gestión de Procesos genera el Reporte de Mediciones y Sugerencias de Mejora.
Una vez que el Plan Estratégico ha sido valorado y se han detectado Propuestas de Mejora, será necesario revisar los elementos del plan que son afectados y realizar los cambios necesarios a éstos.
Objetivos O1 Lograr una planificación estratégica exitosa mediante el cumplimiento del
Plan Estratégico.
O2 Lograr que la organización trabaje en función del Plan Estratégico mediante la correcta comunicación e implantación del mismo.
O3 Mejorar el Plan Estratégico mediante la implementación de la Propuesta de Mejoras.
Indicadores I1 (O1) El desempeño de los Indicadores de los Objetivos del Plan Estratégico es satisfactorio.
I2 (O2) Los miembros de la organización conocen el Plan Estratégico y trabajan en función del mismo.
I3 (O3) Las propuestas de mejora están definidas en función del Reporte de Valoración.
I4 (O3) Se realizan modificaciones al Plan Estratégico según las Propuestas de Mejoras.
Metas cuantitativas Valor numérico o rango de satisfacción por indicador.
Responsabilidad y autoridad Responsable:
Responsable de Gestión de Negocio Autoridad:
Grupo Directivo
Subprocesos (opcional) Lista de procesos de los cuales se compone el proceso en cuestión.
Procesos relacionados Gestión de Procesos Gestión de Proyectos Gestión de Recursos Gestión de Conocimiento
Administración de un Proyecto Específico
ENTRADAS
Nombre Fuente
Reporte Cuantitativo y Cualitativo de procesos y proyectos. Gestión de Procesos Gestión de Proyectos Gestión de Recursos Plan de Procesos
Plan de Mediciones de Procesos
Gestión de Procesos Reporte de Acciones Correctivas o Preventivas Relacionadas
con Clientes Gestión de Proyectos
Propuestas Tecnológicas Gestión de Recursos
Factores Externos (tendencias tecnológicas, clientes y competidores)
Diagrama de Flujo Situacional
Análisis de los Actores del Entorno
Externo
Reportes Financieros Organización
SALIDAS
Nombre Descripción Destino Plantilla Soporte Forma de
aprobación Plan Estratégico Misión: Razón de ser de la
organización.
Visión: Posición deseada de la organización en el mercado.
….
Gestión de Procesos Gestión de Proyectos Gestión de Recursos
Plan Estratégico Ver1 Val1
Plan de
Comunicación e Implantación
Mecanismos para dar a conocer el Plan Estratégico a toda la organización, haciendo énfasis en la satisfacción de las necesidades del cliente.
…..
Gestión de Proyectos Gestión de Recursos Administración de un Proyecto Específico
Plan de Comunicación e Implantación Val2
Reporte de
Mediciones y
Sugerencias de Mejora
Registro que contiene:
* Mediciones de los indicadores del proceso de Gestión de Negocio (ver Mediciones).
…..
Gestión de Procesos Reporte de
Seguimiento Ninguna
Plan de
Adquisiciones y Capacitación
Solicitudes con los requisitos de adquisición de recursos. Incluye personal capacitado, proveedores,
infraestructura y herramientas ...
Gestión de Recursos Plan de Adquisiciones
y Capacitación Ninguna
Lecciones
Aprendidas Registro de mejores prácticas, problemas recurrentes y experiencias exitosas, durante la implantación de este proceso.
Gestión de
Conocimiento Lecciones Aprendidas Ninguna
PRODUCTOS INTERNOS
Nombre Descripción Plantilla Soporte Forma de aprobación
Propuesta de
Mejoras Descripción de las sugerencias de mejora de los elementos del Plan Estratégico.
Propuesta de Mejoras Val3
Reporte de
Valoración Documento que contiene el registro de los resultados de la actividad A3.1.
Análisis de la información y evaluación del desempeño.
Reporte de Seguimiento Ninguna
Nombre Descripción Plantilla Soporte Forma de aprobación Reporte(s) de
Verificación Registro de participantes, fecha, lugar,
duración y defectos encontrados. Reporte de Verificación Ninguna
Reporte(s) de Validación
Registro de participantes, fecha, lugar, duración y defectos encontrados.
Reporte de Validación Ninguna
PRÁCTICAS
Roles involucrados y competencias
Identificación de roles involucrados y competencias requeridas.
Abreviatura Rol Competencias
GD Grupo Directivo Conocimiento del esfuerzo requerido para llevar a cabo la planificación estratégica, y sobre todo estar comprometido con éste.
RGN Responsable de
Gestión de Negocio Conocimiento de las actividades necesarias para definir e implantar exitosamente el proceso de Gestión de Negocio.
GG Grupo de
Gestión Conocimiento para administrar los proyectos e implantar los procesos definidos.
ACTIVIDADES
Se asocian a los objetivos y describen las tareas y roles responsables.
Rol Descripción
A1. Planificación Estratégica (O1)
Entradas Reporte Cuantitativo y Cualitativo de procesos y proyectos Factores Externos
Plan Estratégico anterior Reportes Financieros
GD A1.1. Articular, documentar o actualizar la Misión, Visión y Valores.
RGN A1.2. Entender la situación actual.
Análisis del entorno – identificación de oportunidades y amenazas con base en:
necesidades de los clientes, información sobre competidores, tendencias tecnológicas, etc.
….
RGN A1.3. Desarrollar o actualizar Objetivos y Estrategias, considerando las Propuestas de Mejora, en caso de existir.
Definir o actualizar los Objetivos, y las Estrategias que especifiquen el medio para alcanzar estos objetivos.
...
RGN
GG A1.4. Definir o actualizar los procesos y proyectos, considerando las Propuestas de Mejora en caso de existir.
Identificar los Procesos Requeridos.
…
RGN A1.5. Definir o actualizar la Estructura de la Organización adecuada para la implantación del plan, para lo cual es necesario considerar las Propuestas de Mejora en caso de existir.
RGN A1.6. Definir o actualizar la Estrategia de Recursos, considerando las Propuestas de Mejora en caso de existir, que permita:
Identificar y distribuir los recursos necesarios para la implantación del plan.
…
RGN
GD A1.7. Calcular el presupuesto requerido (gastos e ingresos esperados) para lograr la implantación del Plan Estratégico, y determinar el periodo para el que aplicará.
RGN
GD A1.8. Definir o actualizar la Periodicidad de Valoración del Plan Estratégico, considerando las Propuestas de Mejora, en caso de existir.
RGN
GD A1.9. Definir los mecanismos de comunicación con el cliente para su atención y documentarlos en el Plan de Comunicación con el Cliente.
RGN A1.10. Integrar y documentar el Plan Estratégico.
RGN A1.11. Verificar el Plan Estratégico (Ver1).
RGN A1.12. Corregir los defectos encontrados en el Plan Estratégico con base en el Reporte de Verificación y obtener la aprobación de las correcciones.
GD A1.13. Validar el Plan Estratégico (Val1).
RGN A1.14. Corregir los defectos encontrados en el Plan Estratégico con base en el Reporte de Validación y obtener la aprobación de las correcciones.
RGN A1.15. Elaborar el Plan de Adquisiciones y Capacitación para el proceso de Gestión de Negocio.
Salidas Plan Estratégico
Plan de Adquisiciones y Capacitación A2. Preparación para la Realización (O2) Entradas Plan Estratégico
RGNGD A2.1. Preparar el ambiente adecuado para la implantación del Plan Estratégico.
RGN
GD A2.2. Definir y ejecutar el Plan de Comunicación e Implantación del Plan Estratégico, en este se deberán identificar.:
Las líneas y medios de comunicación, que permitan la divulgación efectiva del Plan Estratégico.
A2.3.…
GD A2.4. Validar el Plan de Comunicación e Implantación (Val2).
RGN A2.5. Corregir los defectos encontrados en el Plan de Comunicación e Implantación con base en el Reporte de Validación y obtener la aprobación de las correcciones.
Salidas Plan de Comunicación e Implantación A3. Valoración y Mejora Continua (O3)
Entradas Reportes Cuantitativos y Cualitativos de procesos y proyectos
Reporte de Acciones Correctivas o Preventivas Relacionadas con Clientes Propuestas Tecnológicas
Reportes Financieros Factores Externos
RGN, GD A3.1. Análisis de la información y evaluación del desempeño.:
Análisis de los Reportes Cuantitativos y Cualitativos de procesos y proyectos para comparar resultados con metas planteadas.
A3.2.…
RGN A3.3. Generación de Reporte de Valoración en donde se registran los detalles de la tarea A3.1
RGN, GG, GD
A3.4. Generación de Propuesta de Mejoras al Plan Estratégico actual.
GD A3.5. Validar la Propuesta de Mejoras (Val3).
RGN A3.6. Corregir los defectos encontrados en la Propuesta de Mejoras con base en el Reporte de Validación y obtener la aprobación de las correcciones.
RGN A3.7. Generar el Reporte de Mediciones y Sugerencias de Mejora de este proceso, de acuerdo al Plan de Mediciones de Procesos.
RGN A3.8. Identificar las Lecciones Aprendidas e integrarlas a la Base de Conocimiento. Como ejemplo, se pueden considerar las mejores prácticas, experiencias exitosas de manejo de riesgos, problemas recurrentes, entre otras.
Salidas Reporte de Mediciones y Sugerencias de Mejora Lecciones Aprendidas
Diagrama de flujo de
trabajo Diagrama de actividades de UML, donde se especifican las actividades del flujo de trabajo y los roles (utilizando carriles)