Mejora de procesos software para pequeñas organizaciones

(1)

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*

° Facultad de Ciencias

Universidad Nacional Autónoma de México (UNAM) Ciudad Universitaria, 04510 México D.F., México

[email protected], [email protected]

* Grupo de Investigación ALARCOS

Departamento de Tecnologías y Sistemas de Información Universidad de Castilla-La Mancha

Paseo de la Universidad, 4 – 13071 Ciudad Real, España

{Mario.Piattin, Félix.García, Tomas.Martinez, Francisco.RuizG}@uclm.es

+ Grupo de Investigación IDIS

Facultad de Ingeniería Electrónica y Telecomunicaciones Universidad del Cauca

Calle 5 # 4 – 70, Popayán, Colombia.

[email protected]

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

(2)

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 la 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 y 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.

(3)

En el presente capítulo se presenta el proyecto COMPETISOFT¹, 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 CYTED² 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

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

(4)

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 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 Colciencias³ 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

3 Instituto colombiano para el desarrollo de la Ciencia y la Tecnología

(5)

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 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). El término Small Settings hace referencia a equipos pequeños, proyectos pequeños, organizaciones pequeñas y/o pequeñas empresas.

(6)

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 1 se muestra un esquema representativo de I-A en el proyecto COMPETISOFT.

(7)

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

Grupos de Investigación participantes en el proyecto

(investigadores)

Mejora de Procesos Software de las PyMEs (Objeto investigado) PyMEs

(stakeholders)

Compañías y organizaciones Participantes en el proyecto

Grupo de consulta crítica Propuesta

Resultados Perfeccionados Resultado de la

Investigación

Aplicación de los Resultados

Deliverables (normas, modelos, métodos, herramientas, libros, etc.)

(8)

[24](Polo et al., 2002) y METRICA v3⁴. 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 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 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 se involucran en el proyecto.

4 http://www.csi.map.es/csi/metrica3/

(9)

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

(10)

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

(11)

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

(12)

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.

(13)

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 4.

Figura 4. Metamodelo del patrón de procesos de COMPETISOFT.

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.

(14)

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.

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 5), define cinco niveles de madurez para la organización: Realizado, Gestionado, Establecido, Predecible y Optimizado.

Nivel 5: Optimización (2 atributos) Nivel 4: Predecible (2 atributos) Nivel 3: Establecido (2 atributos) Nivel 2: Administrado (2 atributos) Nivel 1: Realizado (1 atributo) Nivel 0: Incompleto

Método de Evaluación de COMPETISOFT

Gestión de Negocio ALTA DIRECCIÓN

(DIR)

Categoría

Gestión de Procesos Gestión de Proyectos Gestión de Recursos Humanos Gestión de Bienes, Servicios e Infraestructura

Gestión de Conocimiento GERENCIA

(GER)

Categoría

Administración de un Proyecto Específico Desarrollo de Software

Mantenimiento de Software OPERACIÓN

(OPE)

Categoría

Dimensión de CAPACIDAD

Dimensión de PROCESO

Modelo de Referencia COMPETISOFT

Proceso de Valoración de la Capacidad (Nivel 1 a 5) basado en los Indicadores de Atributo de Proceso (PAI) - GP: Práctica Genérica

- GR: Recurso Genérico

- GWP: Producto de Trabajo Genérico Para cada atributo AP 1.1 a AP 5.2

Nivel 1

Elementos (de COMPETISOFT) para la valoración de la ejecución del proceso basados en:

•Propósito

•Descripción

•Objetivos

•Indicadores

•…

Nivel 5: Optimización (2 atributos) Nivel 4: Predecible (2 atributos) Nivel 3: Establecido (2 atributos) Nivel 2: Administrado (2 atributos) Nivel 1: Realizado (1 atributo) Nivel 0: Incompleto

Método de Evaluación de COMPETISOFT

(DIR)

Categoría

(GER)

Categoría

(OPE)

Categoría

(DIR)

Categoría

(DIR)

Categoría

(GER)

Categoría

(GER)

Categoría

(OPE)

Categoría

(OPE)

Categoría

Dimensión de CAPACIDAD

Dimensión de PROCESO

Modelo de Referencia COMPETISOFT

Proceso de Valoración de la Capacidad (Nivel 1 a 5) basado en los Indicadores de Atributo de Proceso (PAI) - GP: Práctica Genérica

- GR: Recurso Genérico

- GWP: Producto de Trabajo Genérico Para cada atributo AP 1.1 a AP 5.2

Nivel 1

Elementos (de COMPETISOFT) para la valoración de la ejecución del proceso basados en:

•Propósito

•Descripción

•Objetivos

•Indicadores

•…

Figura 5: Estructura del Modelo de Evaluación de COMPETISOFT.

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 1.

(15)

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 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 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).

(16)

Evaluación de los Atributos Nivel

Alcanzado _{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 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 por proceso. 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 6. Este proceso debe guiar las actividades de evaluación a lo largo de todo el proyecto de mejora.

(17)

Figura 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.

(18)

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 proyectos de mejora que abarcan diferentes casos de mejora dentro del programa global de mejora de la organización. Un caso de mejora es una unidad 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.

• 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 7:

(19)

5 Revisión 4

Mejora 3

Formulación 2

Diagnóstico 1

Instalación

5 Revisión 4

Mejora 3

Formulación 2

Diagnóstico 1

Instalación

8. Entrenamiento 7. Aprendizaje 6. Gestión de la

Configuración 5. Implantación 4. Diseño 3. Análisis de

Resultados 2. Evaluación 1. Gestión del

Programa

8. Entrenamiento 7. Aprendizaje 6. Gestión de la

Configuración 5. Implantación 4. Diseño 3. Análisis de

Resultados 2. Evaluación 1. Gestión del

Programa Fases Disciplinas

Figura 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

(20)

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 caso de mejora ejecutado antes de volver a comenzar la fase de inicio de un nuevo caso 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.

(21)

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.

(22)

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.

(23)

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.

(24)

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.

(25)

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.

(26)

• 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

(27)

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

(28)

Nombre Descripción Destino Plantilla Soporte

Forma de aprobación 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

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.