– Trabaja con los gerentes de línea, cuyos proyectos se ven afectados por cambios en las prácticas de ingeniería de software, proporcionando una amplia perspectiva de los esfuerzos de mejora y ayudarles a fijar las expectativas.
– Mantiene relaciones de colaboración de trabajo con los ingenieros de software, especialmente para obtener, planificar, e instalar nuevas prácticas y tecnologías.
– Los arreglos para cualquier capacitación o educación continua relacionados con mejoras en el proceso.
– Pistas, monitores, y los informes sobre el estado de los esfuerzos de mejora en particular.
– Facilita la creación y mantenimiento de las definiciones de procesos, en colaboración con los directores y el personal de ingeniería.
– Mantiene una base de datos de proceso.
– Proporciona consultoría de procesos para proyectos de desarrollo y de gestión.
1 Software Engineering Institute. Carnegie Mellon. (2010). Software Engineering Process Group Guide. [en línea]. Enlace web: http://www.sei.cmu.edu/library/abstracts/reports/90tr024.cfm. [Leído: 20 de enero 2010, 14.00 h GMT+1].
1.4.2.2. Enfoques SEPG
Cada SEPG tiene un enfoque y misión diferente. A continuación se describen algunos:
– "Trabajo" SEPG de que realmente desarrollar e implementar el proceso como un tipo de equipo de consultores internos.
– "Supervisión" SEPG que supervisará el proceso de La arquitectura, gestión de cambios, y dar prioridad a él (una especie de proceso de CCB).
– "Qué Deliberante" SEPG es el enfoque de proceso de debate y desarrollo de estrategia para un proceso de arquitectura y el despliegue.
– "Virtual" SEPG de que se componen de representantes de toda la organización que dedicar una cierta cantidad de tiempo para el esfuerzo y son responsables de la implementación y la formación de todos los demás en la organización.
1.5. Herramientas CASE y entornos de trabajo
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.
Sistema de software que intenta proporcionar ayuda automatizada a las actividades del proceso de software. Los sistemas CASE a menudo se utilizan como apoyo al método.
1.5.1. Definiciones CASE
Conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.
La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas.
Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.
La realización de un nuevo software requiere que las tareas sean organizadas y completadas en forma correcta y eficiente. Las herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinación de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software.
1.5.2. Herramientas CASE en función de las fases del ciclo de vida
Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:1
– Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
– Herramientas de alto nivel, U-CASE (Upper CASE – CASE superior) o front-end, orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
– Herramientas de bajo nivel, L-CASE (Lower CASE – CASE inferior) o back-end, dirigidas a las últimas fases del desarrollo: construcción e implantación.
– Juegos de herramientas o Tools-Case, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
1 SCRIB. (2009). Ingeniería de Software. [en línea]. Enlace web: (function() { var scribd = document.createElement(«script»); scribd.type = «text/javascript»; scribd.async = true; scribd.src = «https://www.scribd.com/javascripts/embed_code/inject.js»; var s = document.getElementsByTagName(«script»)[0]; s.parentNode.insertBefore(scribd, s); })() [Leído: 6 de enero 2010, 12.00 h GMT+1].
1.5.3. Ventajas de la utilización de herramientas CASE
La mejor razón para la creación de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Por esto, las compañías pudieron desarrollar sistemas sin encarar el problema de tener cambios en las necesidades del negocio, antes de finalizar el proceso de desarrollo. También permite a las compañías competir más efectivamente usando estos sistemas desarrollados nuevamente para compararlos con sus necesidades de negocio actuales. En un mercado altamente competitivo, esto puede hacer la diferencia entre el éxito y el fracaso.
Las herramientas CASE también permiten a los analistas tener más tiempo para el análisis y diseño y minimizar el tiempo para codificar y probar. La introducción de CASE integradas está comenzando a tener un impacto significativo en los negocios y sistemas de información de las organizaciones. Con un CASE integrado, las organizaciones pueden desarrollar rápidamente sistemas de mejor calidad para soportar procesos críticos del negocio y asistir en el desarrollo y promoción intensiva de la información de productos y servicios. La principal ventaja de la utilización de una herramienta CASE, es la mejora de la calidad de los desarrollos realizados y, en segundo término, el aumento de la productividad. Para conseguir estos dos objetivos es conveniente contar con una organización y una metodología de trabajo, además de la propia herramienta.
1.6. Modelos de procesos de software y de mejorar de calidad
A continuación se describen los siguientes modelos de proceso de software y de mejorar de calidad:
– CMM – Capability Maturity Model,
– CMMI – Capability Maturity Model Integration,
– SPICE; y,
– Trillium Model.
1.6.1. CMM – Capability Maturity Model
El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute). El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI.1
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América (en particular del Departamento de Defensa, DoD), desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.
1 SERGIO Fernández. (2003). Ingeniería de Software. [en línea]. Enlace web: http://apuntes-utn.com.ar/apuntes/documento.aspx?IdDocumento=433&bajar=1. [Leído: 6 de enero 2010, 14.00 h GMT+1].
1.6.1.1. KPA – Key Process Area
Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA – Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
– Definidas en un procedimiento documentado.
– Provistas (la organización) de los medios y formación necesarios.
– Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas).
– Medidas.
– Verificadas.
Cada nivel, menos el primero, tiene asociado un conjunto de KPAs (Key Process Areas) que definen un conjunto de objetivos a cumplir. Cada KPA incluye un número de prácticas claves que llevan a cumplir esos objetivos. No es necesario implementar todas las prácticas. Sí es necesario cumplir con todos los objetivos del nivel a acreditar y sus inferiores.
Así es como el modelo CMM establece una medida del progreso, conforme al avance en niveles de madurez. Cada nivel a su vez cuenta con un número de áreas de proceso que deben lograrse. El alcanzar estas áreas o estadios se detecta mediante la satisfacción o insatisfacción de varias metas claras y cuantificables. Con la excepción del primer nivel, cada uno de los restantes niveles de madurez está compuesto por un cierto número de Áreas Claves de Proceso, conocidas a través de la documentación del CMM por su sigla inglesa: KPA.
Cada KPA identifica un conjunto de actividades y prácticas interrelacionadas, las cuales cuando son realizadas en forma colectiva permiten alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: Gestión, Organizacional e Ingeniería.
Las prácticas que deben ser realizadas por cada Área Clave de Proceso están organizadas en 5 características comunes, las cuales constituyen propiedades que indican si la implementación y la institucionalización de un proceso clave es efectivo, repetible y duradero.
Estas 5 características son:
– Compromiso de la realización,
– La capacidad de realización,
– Las actividades realizadas,
– Las mediciones y el análisis,
– La verificación de la implementación.
1.6.1.2. Niveles de Madurez
La mejora continua del proceso está basada en una cantidad de pequeños pasos evolutivos, más que en innovaciones revolucionarias. El CMM provee un marco para organizar estos pasos en cinco niveles de madurez que establecen sucesivas bases para una mejora continua. Estos cinco niveles definen una escala ordinal para medir la madurez del proceso de desarrollo de software de una organización y para evaluar su capacidad de proceso de software. Los niveles también ayudan a una organización a la hora de definir prioridades en sus esfuerzos por mejorar. En la tabla 1.1, se muestra las características de los 5 niveles de madurez
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
Los niveles son:
a) Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.
b) Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
c) Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
d) Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
e) Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
NIVELES | CARACTERÍSTICAS | |||||
Nivel 1: Inicial | – Sin proceso definido. – Sin estándares o si existen son ignorados. – Poca habilidad para estimar. – El éxito está basado en "héroes". – Poca visibilidad. – Deadlines más importantes que calidad. – Proyectos fuera de término y presupuesto. | |||||
Nivel 2:Repetible | – Administración y control de proyectos. – Se crean y documentan los procesos. – Se recolectan métricas y se realiza tracking del progreso. – Mejora la estimación. – Menos desvíos que en el Nivel 1. | |||||
Nivel 3: Definido | – Implementación de estándares, documentación de procesos para el desarrollo y mantenimiento. – Guías para la adecuación de los procesos en un proyecto específico. – Incremento de efectividad y reducción de costos y tiempos. – Se crea el Software Engineering Process Group (SEPG). | |||||
Nivel 4: Administrado | – El foco de este nivel es la medición. Implementación de un plan de métricas para evaluar el proceso de la organización. – La calidad del producto debe ser alta y predecible. | |||||
Nivel 5: Optimizado | – Prevención de los defectos. Seguimiento y análisis. – Mejora continua de los procesos (calidad, productividad y tiempos de ciclos). – Administración de la incorporación de nuevas tecnologías. | |||||
Tabla 1.1. Características de los niveles de madurez
1.6.1.3. Evolución de las organizaciones según CMM
Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una guía útil para orientar sus esfuerzos. Además, el SEI proporciona formación a evaluadores certificados (Lead Assesors) capacitados para evaluar y certificar el nivel CMM en el que se encuentra una organización. Esta certificación es requerida por el Departamento de Defensa de los Estados Unidos, pero también es utilizada por multitud de organizaciones de todo el mundo para valorar a sus subcontratistas de software.
Se considera típico que una organización dedique unos 18 meses para progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso intenso de la dirección.
Como consecuencia, muchas organizaciones que realizan funciones de factoría de software o, en general, outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de los países en el que más organizaciones certificadas existan sea India, donde han florecido las factorías de software que trabajan para clientes estadounidenses y europeos.
1.6.2. CMMI – Capability Maturity Model Integration
CMMI es un modelo de aseguramiento de la calidad que busca la mejora continua de las organizaciones mediante el análisis y re-diseño de los procesos que subyacen en la organización. Fue creado por el SEI (Software Engineering Institute) de la Universidad de Carnegie-Mellon y patrocinado por el Ministerio de Defensa de los Estados Unidos. Con el propósito de lograr la mejora de los procesos, CMMI provee:
– Una forma de integrar los elementos funcionales de una organización.
– Un conjunto de mejores prácticas basadas en casos de éxito probado de organizaciones experimentadas en la mejora de procesos.
– Ayuda para identificar objetivos y prioridades para mejorar los procesos de la organización, dependiendo de las fortalezas y debilidades de la organización que son obtenidas mediante un método de evaluación.
– Un apoyo para que las empresas complejas en actividades productivas puedan coordinar sus actividades en la mejora de los procesos.
– Un punto de referencia para evaluar los procesos actuales de la organización.
1.6.2.1. Antecedentes
CMMI v1.2 corresponde a la tercera versión entregable del modelo CMMI, posterior a las versiones 1.02 (primera versión año 2000) y 1.1 (año 2002). Las versiones previas sirvieron como retroalimentación para que los propios usuarios, evaluadores y evaluados hicieran acotaciones sobre posibles mejoras, las cuales fueron estudiadas, refinadas y algunas incluidas en la versión 1.2. CMMI v1.2 para desarrollo, que corresponde a una de tres constelaciones de prácticas, es una guía que ayuda a manejar, medir y monitorear procesos utilizados en el desarrollo de productos y servicios de una organización, y contiene prácticas ligadas a la administración de proyectos, administración de procesos, ingeniería y soporte. Las otras dos constelaciones son CMMI para Adquisición que provee una guía para liderar la adquisición informada y decisiva, y CMMI para Servicios que proporciona una guía para la entrega de servicios a clientes internos y externos de la organización. Ambas constelaciones se encuentran aún en desarrollo.
Junto con CMMI se desarrolló y publicó el método de evaluación "Assessment Requirements for CMMI (ARC)" en el año 2000, el cual define los requerimientos considerados esenciales para realizar una evaluación de CMMI en una organización y "Standard CMMI Appraisal Method for Process Improvement", (SCAMPI), manual seguido por los evaluadores para medir el nivel de madurez de una organización. Estos dos documentos también se han actualizado como consecuencia de la retroalimentación de la comunidad involucrada en CMMI, generando la última versión 1.2 de SCAMPI y ARC ambas publicadas el año 2006.
1.6.2.2. Representaciones
La representación usada en CMMI entrega una guía para efectuar las actividades de mejora de los procesos y es utilizada en el método de evaluación. Según el modelo se tienen dos formas para mejorar. Una forma es mejorar un proceso específico o un conjunto de ellos usando la "representación continua" (continuous representation) y la otra es la mejora de la organización completa según los procesos definidos y ocupados usando la "representación escalonada" o por "etapas" (Staged Representation). En la tabla 1.2 se muestran los niveles para estos dos tipos de representaciones.
1.6.2.2.1. Representación continua
La representación continua se focaliza en la mejora de un proceso o un conjunto de ellos relacionado(s) estrechamente a un área de proceso en que una organización desea mejorar, por lo tanto una organización puede ser certificada para un área de proceso en cierto nivel de capacidad. Existen seis niveles de capacidad por donde transitan los procesos asociados a un área de proceso y cada nivel es construido sobre el nivel anterior, es decir para que un proceso alcance un nivel de capacidad necesariamente debe haber alcanzado el nivel anterior.
| REPRESENTACIÓN CONTINUA | REPRESENTACIÓN ESCALONADA | ||||||
| Nivel de capacidad | Nivel de madurez | ||||||
Nivel 0 | Incompleto | – | ||||||
Nivel 1 | Realizado | Inicial | ||||||
Nivel 2 | Manejado | Manejado | ||||||
Nivel 3 | Definido | Definido | ||||||
Nivel 4 | Manejado cuantitativamente | Manejado cuantitativamente | ||||||
Nivel 5 | Optimizado | Optimizado | ||||||
Tabla 1.2. Niveles de representación continua y escalonada.
Los niveles de capacidad son:
– Nivel 0 – Incompleto: Un proceso es denominado "proceso incompleto" cuando una o más objetivos específicos del área de proceso no son satisfechos.
– Nivel 1 – Realizado: Un proceso es denominado "proceso realizado" cuando satisface todos los objetivos específicos del área de proceso. Soporta y permite el trabajo necesario para producir artefactos.
– Nivel 2 – Manejado: Un proceso es denominado como "proceso manejado" cuando tiene la infraestructura base para apoyar el proceso. El proceso es planeado y ejecutado en concordancia con la política, emplea gente calificada los cuales tienen recursos adecuados para producir salidas controladas; involucra partes interesadas; es monitoreado, controlado y revisado; y es evaluado según la descripción del proceso.
– Nivel 3 – Definido: Un proceso denominado "proceso definido" es adaptado desde el conjunto de procesos estándares de la organización de acuerdo a las guías de adaptación de la organización, y aporta artefactos, medidas, y otra información de mejora a los activos organizacionales.
– Nivel 4 – Manejado cuantitativamente: Un proceso denominado "proceso manejado cuantitativamente" es controlado usando técnicas estadísticas y otras técnicas cuantitativas. Objetivos cuantitativos para la calidad y realización del proceso son establecidos y usados como criterios para manejar el proceso.
– Nivel 5 – Optimización: Un proceso denominado "proceso optimización" es mejorado basado en el entendimiento de causas comunes de variación del proceso. Un proceso en optimización se focaliza en la mejora continua del proceso realizado a través de mejoras incrementales y usando innovación tecnológica.
1.6.2.2.2. Representación escalonada
En la representación escalonada o por etapas se ofrece un método estructurado y sistemático de mejoramiento de procesos, que implica mejorar por etapas o niveles. Al alcanzar un nivel, la organización se asegura de contar con una infraestructura robusta en términos de procesos para optar a alcanzar el nivel siguiente. Por lo tanto es una organización la que puede ser certificada bajo un nivel, en este caso llamado nivel de madurez. Según esta representación un nivel de madurez está compuesto por áreas de procesos ver tabla 1.3, en donde los objetivos asociados a ese nivel deben ser cumplidos para que la organización pueda certificarse en aquel nivel de madurez. Hay cinco niveles de madurez, los que son descritos a continuación en la tabla 1.3.
NIVELES | CARACTERÍSTICAS | |||
Nivel 1: Iniciado | La organización usualmente no provee un ambiente estable para soportar los procesos. Éxitos en estas organizaciones se debe a la competencia y esfuerzos heróicos de la gente dentro de la organización y no al uso de procesos probados. A pesar de este caos, organizaciones pertenecientes al nivel de madurez 1 con frecuencia producen productos y servicios que funcionan; sin embargo, ellos frecuentemente exceden sus presupuestos y no cumplen sus planes. Estas organizaciones son caracterizadas por la tendencia a no cumplir sus compromisos, al abandono de procesos durante tiempos de crisis, y a la incapacidad para repetir sus éxitos. El Nivel 1 está caracterizado además por la realización de trabajo redundante, por personas que no comparten sus métodos de trabajo a lo largo de la organización y cuando una persona clave en un área de negocio específica dentro de la organización se marcha, su conocimiento se va con ella y se pierde para la organización. Es claro que el Nivel 1 es uno donde ninguna organización quiere estar y donde por lo general la mayoría que no tiene sus procesos definidos se encuentra. | |||
Nivel 2: Manejado | En el nivel de madurez 2 se ordena el caos. En el nivel 2 las organizaciones se enfocan en tareas cotidianas referentes a la administración. Cada proyecto de la organización cuenta con una serie de procesos para llevarlo a cabo, los cuales son planeados y ejecutados de acuerdo con políticas establecidas; los proyectos utilizan gente capacitada quienes disponen de recursos para producir salidas controladas; se involucran a las partes interesadas; son monitoreados, controlados y revisados; y son evaluados según la descripción del proceso.La disciplina del proceso reflejada por el nivel de madurez 2 ayuda a asegurar que existen prácticas y los proyectos son realizados y manejados de acuerdo a los planes documentados. En el nivel de madurez 2 el estado de los artefactos y la entrega de los servicios siguen planes definidos. Acuerdos son establecidos entre partes interesadas y son revisados cuando sea necesario. Los artefactos y servicios son apropiadamente controlados. Estos además satisfacen sus descripciones especificadas, estándares, y procedimientos. | |||
Nivel 3: Definido | En el nivel de madurez 3, procesos son caracterizados y entendidos de buena forma, y son descritos en estándares, procedimientos, herramientas, y métodos. El conjunto de procesos estándares de la organización, los cuales son la base para el nivel de madurez 3, es establecido y mejorado continuamente. Estos procesos estándares son usados para establecer consistencia a través de la organización. Los proyectos establecen sus procesos adaptando el conjunto de procesos estándares de la organización de acuerdo a guías de adaptación.Una diferencia importante entre el nivel 2 y 3 es el alcance de los estándares: la descripción de procesos y los procedimientos. En el nivel de madurez 2, los estándares pueden ser un poco diferentes en cada instancia específica del proceso (por ejemplo sobre un proyecto particular). En el nivel de madurez 3, los estándares, descripción de procesos y procedimientos para un proyecto, son adaptados desde un conjunto de procesos estándares de la organización a un particular proyecto o unidad organizacional y así son más consistentes. Otra distinción crítica es que el nivel de madurez 3, los procesos son típicamente descritos más rigurosamente que en el nivel 2. Un proceso definido claramente plantea el propósito, entradas, criterios de entrada, actividades, roles, medidas, pasos de verificación, salidas y criterios de salida. En el nivel de madurez 3, procesos son manejados más proactivamente entendiendo las interrelaciones de las actividades y medidas detalladas del proceso, sus artefactos y sus servicios. | |||
Nivel 4: Manejado cuantitativamente | En el nivel de madurez 4, la organización y proyectos establecen objetivos cuantitativos para medir la calidad y realización de los procesos y los usa como criterios en el manejo de ellos. Los objetivos cuantitativos son definidos en base a las necesidades de clientes, usuarios finales, organización, y actores de los procesos. La calidad y realización de procesos son entendidos en términos estadísticos y son manejados durante todo el ciclo de vida del proceso. Para subprocesos seleccionados, se recolectan y analizan estadísticamente medidas sobre la realización de procesos. Estas métricas son incorporadas en el repositorio de métricas de la organización para apoyar la toma de decisiones. Causas especiales de variación de procesos son identificadas y, cuando sea necesario, las fuentes de estas causas son corregidas para prevenir futuras ocurrencias. Una diferencia importante entre los niveles 3 y 4 es la capacidad de predicción de la realización del proceso. En el nivel de madurez 4, la realización de procesos es controlada usando técnicas estadísticas y cuantitativas, y el proceso es cuantitativamente predecible, en cambio en el nivel de madurez 3 la realización del proceso es sólo predecible cualitativamente. | |||
Nivel 5: Optimizado | En el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en el conocimiento de las causas comunes de variación inherente en los procesos. El nivel de madurez 5 se focaliza sobre la mejora continua de los procesos a través de mejoras continuas, incrementales y tecnológicas. Los objetivos de mejora cuantitativa de procesos para la organización son establecidos, continuamente revisados para reflejar cambios en los objetivos del negocio y usados como criterio en la mejora de procesos. Los efectos del empleo de las mejoras de procesos son medidos y evaluados contra los objetivos de mejora cuantitativa del proceso. Una diferencia importante entre el nivel de madurez 4 y 5 es el enfoque de la variación de los procesos. En el nivel de madurez 4, la organización está orientada a encontrar causas especiales de variación y proveer una predicción estadística de los resultados. Sin embargo, los resultados pueden ser insuficientes para alcanzar los objetivos establecidos. En el nivel de madurez 5 la organización está enfocada en las causas comunes de variación de procesos y modificar los procesos afectados para mejorar la realización de ellos y alcanzar los objetivos cuantitativos de mejora de procesos.Dado a que la organización con que se trabajará quiere certificarse en forma organizacional en Nivel de madurez 3, en adelante sólo se detallará el modelo según la Representación Escalonada. | |||
Tabla 1.3. Características de los niveles CMMI.
1.6.2.3. Estructura del CMMI
Un área de proceso es un conjunto de prácticas relacionadas que cuando son implementadas colectivamente, satisfacen un conjunto objetivos considerados importantes para mejorar esa área de proceso. Las áreas de proceso del modelo son 22. En la tabla 1.4 se indica los nombres de las áreas de proceso junto con su abreviación. Cada una de ellas es implementada para alcanzar el nivel de madurez correspondiente y se agrupan de acuerdo a cuatro categorías: Administración de Procesos, Administración de Proyectos, Ingeniería y Soporte. Este agrupamiento es realizado para mostrar cómo se relaciona cada área de proceso dentro de una categoría. Sin embargo, áreas de procesos de distintas categorías pueden encontrarse relacionadas, pero dado que en este documento se desarrollarán sólo áreas de procesos de una misma categoría (Ingeniería) estas relaciones se desprecian.
ÁREA DE PROCESO | CATEGORÍA | NIVEL DE MADUREZ | |||||
Análisis y Resolución Causales (CAR) | Soporte | 5 | |||||
Análisis y Resolución de Decisiones (DAR) | Soporte | 3 | |||||
Aseguramiento de la Calidad de Procesos y Productos (PPQA) | Soporte | 2 | |||||
Definición de Procesos Organizacionales +IPPD(OPD +IPPD) | Gestión de procesos | 3 | |||||
Desarrollo de Requerimientos (RD) | Ingeniería | 3 | |||||
Entrenamiento Organizacional (OT) | Gestión de procesos | 3 | |||||
Administración Cuantitativa de Proyectos (QPM) | Gestión de proyectos | 3 | |||||
Administración de Acuerdos con Proveedores (SAM) | Ingeniería | 2 | |||||
Administración de Requerimientos (REQM) | Gestión de proyectos | 3 | |||||
Administración de Riesgos (RSKM) | Soporte | 2 | |||||
Administración de la Configuración (CM) | Gestión de proyectos | 3 | |||||
Administración Integral de Proyecto + IPD (IPM+IPPD) 1 | Gestión de proyectos | 3 | |||||
Innovación y Despliegue Organizacional (OID) | Gestión de procesos | 5 | |||||
Integración de Producto (PI) | Ingeniería | 3 | |||||
Medición y Análisis (MA) | Soporte | 2 | |||||
Monitoreo y Control de Proyecto (PMC) | Gestión de proyectos | 2 | |||||
Planificación de Proyecto (PP) | Gestión de proyectos | 2 | |||||
Procesos Orientados a la Organizacionales (OPF) | Gestión de procesos | 3 | |||||
Rendimiento de Procesos Organizacionales (OPP) | Gestión de procesos | 4 | |||||
Solución Técnica (TS) | Ingeniería | 3 | |||||
Validación (VAL) | Ingeniería | 3 | |||||
Verificación (VER) | Ingeniería | 3 | |||||
Tabla 1.4. Las áreas de proceso del modelo CMMI.
1.6.3. SPICE
Para que una organización mejore la calidad de sus productos debe tener un método probado, consistente y fiable para evaluar el estado de sus procesos y además, unos medios para usar los resultados de la evaluación como parte de un programa de mejora coherente. El proyecto internacional SPICE, llevado a cabo por la organización ISO, ha obtenido en su primera fase del proyecto un Informe Técnico Tipo 2 (ISO 15504) formado por un conjunto de documentos todos ellos bajo el título general de Evaluación del Proceso Software.
1.6.3.1. Necesidades y requerimientos para un estándar de evaluación de procesos de software
En Junio de 1991 el comité ISO/IEC JTC1/SC7 aprobó un estudio para que se investigara las necesidades y requerimientos para un estándar de evaluación de procesos software. Un año más tarde, se obtuvo como conclusión que existía un consenso internacional para dicho estándar. En Junio de 1993 arrancó el proyecto SPICE con los objetivos de:
– Ayudar al proyecto de estandarización, en su etapa preparatoria, para desarrollar los borradores iníciales de trabajo.
– Realizar las pruebas de usuario, obteniendo datos de la experiencia que constituirán la base de la revisión del Estándar antes de emitirlo como International Standard.
– Crear el conocimiento del mercado y evolucionar el estándar.
El proyecto SPICE ha logrado ya el primer objetivo. Se ha obtenido el "Technical Report Type 2" que consta de las partes que muestra la figura 1.5.
El marco proporciona un enfoque estructurado de la evaluación de los procesos software, mediante el cual:
– Se anima a la auto-evaluación;
– Se aborda la idoneidad de la gestión de los procesos evaluados;
– Tiene en cuenta el contexto en el que operan los procesos evaluados;
– Produce un conjunto de valores del proceso (perfil del proceso) en vez de un resultado (válido/no válido).
Este marco es válido para todos los dominios de aplicaciones y tamaños de organización.
Figura 1.5: Informe Técnico: Componentes y las relaciones entre ellos.
El uso de la evaluación del proceso en una organización debería estimular principalmente a:
– Una cultura de mejora constante y al establecimiento de los mecanismos adecuados para soportar y mantener tal cultura;
– La ingeniería de procesos para cumplir los requisitos del negocio;
– La optimización de recursos.
Como resultado se obtendrán organizaciones con alta sensibilidad hacia el cliente y hacia los requisitos del mercado, minimizando los costes de sus productos y logrando una satisfacción del usuario final.
El Informe Técnico ha sido diseñado para satisfacer a tres usuarios diferentes: evaluadores, clientes y suministradores. Se muestra en la tabla 1.5.
USUARIOS | CARACTERÍSTICAS | ||||
Evaluadores | Un marco que define todos los aspectos para dirigir evaluaciones. | ||||
Clientes | Un medio para determinar la capacidad actual y potencial de los procesos software del suministrador. Estos obtendrán los beneficios de: – reducir incertidumbre para seleccionar suministradores software, al conocer los riesgos asociados con el contratista; – dotar de controles adecuados para contener el riesgo; – suministrar una métrica para elegir entre coste estimado del proyecto y capacidad de los suministradores que compiten. | ||||
Suministradores | – Un medio para determinar la capacidad actual y potencial de sus propios procesos software; – un instrumento para definir áreas y prioridades para la mejora del proceso software; – un marco que defina un mapa de caminos para la mejora del proceso software. | ||||
Tabla 1.5. Necesidades a satisfacer de los diferentes usuarios.
1.6.3.2. Beneficios de la estandarización de la evaluación de procesos
Los beneficios principales de un enfoque estandarizado para la evaluación del proceso son:
– Proporcionar un modelo para la mejora del proceso público y compartido;
– Conducir a un entendimiento común del uso de la evaluación del proceso para la mejora del proceso y la evaluación de la capacidad;
– Facilitar la evaluación de la capacidad en un concurso abierto;
– Realizar una revisión regular y controlada sobre la experiencia de la utilización;
– Será cambiado únicamente mediante el consenso internacional;
– Animar la armonización de los esquemas existentes.
1.6.3.3. Visión general
El marco para la evaluación de procesos software se puede utilizar por organizaciones implicadas en la planificación, gestión, monitorización, control y mejora de la adquisición, suministro, desarrollo, operación, evolución y soporte del software.
La evaluación del proceso examina los procesos utilizados por una organización para determinar si son efectivos para conseguir sus objetivos. Los resultados de la evaluación se pueden utilizar para conducir las actividades de mejora o para la determinación de la capacidad del proceso.
1.6.3.4. Elementos principales de SPICE
Los elementos esenciales para comprender SPICE son los siguientes: Los resultados de la evaluación del proceso se describe en un modelo de dos dimensiones: Dimensión del proceso y Dimensión de la capacidad. Esto es lo que se denomina arquitectura del modelo de referencia.
– Dimensión del proceso: que está caracterizado por los objetivos del proceso que constituye los elementos fundamentales a medir;
– Dimensión de la capacidad del proceso: que está caracterizado por una serie de atributos de proceso, aplicables a cualquier proceso, que representan características necesarias para gestionar y mejorar su capacidad de realización.
1.6.3.4.1. Dimensión del proceso
El modelo de referencia agrupa los procesos en categoría de procesos. Estos procesos se corresponden con los definidos en ISO 12207 Software Life-Cycle Process. Ver tabla 1.6. La descripción de cada proceso consta de:
– Una declaración del objetivo del proceso describiendo a un alto nivel los objetivos generales del proceso, y también una descripción en términos genéricos de los probables resultados de una implementación efectiva del proceso; y
– una o más observaciones proporcionando mayor información sobre los procesos y su relación a los procesos definidos en ISO 12207 y a otros procesos en este modelo de referencia.
1.6.3.5. Niveles de capacidad y atributos de proceso
La figura 1.6 sintetiza la dimensión de la capacidad de proceso, indicando los atributos de proceso (PA) de cada nivel de capacidad. A continuación, se describe cada nivel. En la tabla 1.7 se muestra los niveles de capacidad.
Figura 1.6: Dimensión de la Capacidad de Proceso.
NIVELES | CARACTERÍSTICAS | ||||
Nivel 0.Proceso Incompleto | El proceso no está implementado o no logra conseguir su objetivo. No hay atributos en este nivel. | ||||
Nivel 1. Proceso Realizado | El propósito implementado logra su objetivo definido. P.A 1.1: Rendimiento del ProcesoEl proceso emplea un conjunto de prácticas, que son iniciadas por unos productos identificables y produce unos productos identificables, que satisfacen el propósito del proceso. | ||||
Nivel 2.Proceso Gestionado | El proceso Realizado entrega productos con una calidad aceptable en un margen de tiempo y necesidades de recursos definidos. PA 2.1: Gestión del Rendimiento La ejecución del proceso se gestiona para producir productos en un plazo de tiempo y con unos requisitos preestablecidos.PA 2.2: Gestión del Producto La ejecución del proceso se gestiona para producir productos que se documentan y se controlan satisfaciendo sus requisitos funcionales y no funcionales, de acuerdo con los objetivos de calidad del producto del proceso. | ||||
Nivel 3. Proceso Establecido | El proceso Gestionado se realiza utilizando un proceso definido basado en los principios de la ingeniería del software. PA 3.1: Definición del Proceso La ejecución del proceso utiliza una definición de proceso basada en un proceso estándar, que permite contribuir a los objetivos de negocio definidos en la organización. PA 3.2: Recursos del Proceso La ejecución del proceso utiliza eficazmente recursos humanos con las habilidades adecuadas y una infraestructura de proceso que contribuyen a los objetivos de negocio definidos de la organización. | ||||
Nivel 4.Proceso Previsible | El proceso Establecido se realiza constantemente dentro de los límites de control definidos para lograr sus objetivos. PA 4.1: Medición del Proceso La ejecución del proceso se soporta por los objetivos y mediciones que son utilizadas para asegurar que la implementación del proceso contribuye a la consecución de los objetivos. PA 4.2: Control del Proceso La ejecución del proceso se controla a través de la recopilación y análisis de mediciones para controlar y corregir, donde sea necesario, el rendimiento del proceso para lograr fiablemente los objetivos del proceso definidos. | ||||
Nivel 5. Proceso Optimizado | El proceso Previsible optimiza su rendimiento para satisfacer las necesidades de negocio actuales y futuras y logra repetidamente satisfacer sus objetivos de negocio definidos. PA 5.1: Cambio de Proceso Los cambios a la definición, gestión y rendimiento del proceso son controlados mejor para conseguir los objetivos de negocio de la organización. PA 5.2: Mejora Continua Los cambios a los procesos se identifican y se implementan para asegurar la mejora continua en el cumplimiento de los objetivos del negocio definidos de la organización. | ||||
Tabla 1.7. Niveles de capacidad.
1.6.3.6. Atributos del proceso
Un atributo del proceso representa una característica medible de cualquier proceso. Los atributos de capacidad del proceso son los elementos básicos del esquema de evaluación.
Cada atributo se evalúa entre un rango de cuatro puntos:
– N= No conseguido. No hay evidencia de que se consigue el atributo definido.
– P= Conseguido parcialmente. Se ha conseguido algo el atributo definido.
– L= Bastante conseguido. Se ha conseguido significativamente el atributo definido.
– F= Conseguido completamente. Se ha conseguido totalmente el atributo definido el nivel de capacidad se derivará de los valores de los atributos de los procesos.
1.6.3.7. Perfil del proceso
Una evaluación SPICE se realiza con el propósito de obtener un perfil de cada uno de los procesos (o instancias de proceso) dentro del alcance de la evaluación. Este perfil muestra la capacidad de la unidad organizativa para lograr el objetivo del proceso.
La evaluación examina a un número de instancias de proceso con el fin de obtener los datos necesarios para producir un perfil del proceso. Una instancia de proceso es una implementación particular de un proceso. Por ejemplo, para cada vez que se realiza la prueba de un módulo del sistema, habrá una instancia de Realizar Prueba de Unidad. Las instancias de proceso examinadas durante la evaluación tiene que ser cuidadosamente seleccionadas para asegurar que la evaluación alcanzará su propósito y cubrirá su alcance.
Se evalúa cada instancia de proceso examinando sus atributos, y obteniendo como consecuencia un valor. Estos valores son decididos mediante el análisis de los indicadores asociados y juzgando su existencia. Las decisiones sobre la existencia de indicadores están basados en una objetiva evidencia, la cual es registrada para soportar y justificar los resultados de la evaluación.
El resultado básico de la evaluación es un conjunto de valores de los atributos de cada instancia de proceso. Éstos se pueden combinar para producir un nivel de capacidad para la instancia del proceso. Los valores para las distintas instancias del mismo proceso se pueden combinar para producir un perfil del proceso como unidad.
Se realizan dos tipos de juicio durante la evaluación de una instancia de un proceso. El primero es para ver si el proceso se realizó, para ello se examina si las prácticas y los tipos de productos esperados existen. Este juicio es la base del valor del atributo de Rendimiento del Proceso, examinando si la instancia está al nivel No realizado, o a uno de los niveles de mayor de capacidad.
El segundo juicio determina cómo de bien se gestiona ese proceso. Se examina la existencia de diferentes prácticas y productos con objeto de realizar los juicios sobre los diferentes atributos de capacidad. Se registran, para soportar los valores de cada atributo, la evidencia sobre la existencia de las prácticas y de sus características y productos.
Los valores de los atributos se sitúan en una escala de cuatro niveles de consecución: no (N), parcialmente (P), en su mayoría (L), completamente (F). La instancia del proceso se da en uno de estos valores según el logro de cada uno de los nueve atributos. Este conjunto formado por los nueve valores de atributos es el perfil de la instancia del proceso. Ver tabla 1.8 que muestra los perfiles de la instancia del proceso.
NIVEL DE ATRIBUTO | ATRIBUTO | VALOR DE LA INSTANCIA A | VALOR DE LA INSTANCIA B | |||
5 | 5.25.1 | NN | NN | |||
4 | 4.24.1 | PP | NN | |||
3 | 3.23.1 | LL | PP | |||
2 | 2.22.1 | LL | LL | |||
1 | 1.1 | L | F | |||
Nivel de Capacidad = |
| 1 | 2 | |||
Tabla 1.8. Perfil de la Instancia del Proceso.
1.6.3.8. Ventajas y desventajas
SPICE ofrece una base para una evaluación muy detallada del estado actual del proceso de una organización. Por su gran nivel de descomposición de los procesos e indicadores, proporciona evaluaciones objetivas y con resultados repetibles, especialmente cuando es realizada por evaluadores entrenados y cualificados. El European Software Institute (ESI) ya ofrece cursos para ello.
Al disminuir la subjetividad se consigue reducir discordias sobre los resultados de la evaluación y a adoptar actitudes positivas de los equipos hacia la evaluación.
Por contra se requiere un gran esfuerzo para realizar las evaluaciones y por tanto un alto coste. Las evaluaciones se pueden llevar a cabo por personal interno de tal manera que se puedan ver reducidos estos costes. Es importante tener en cuenta que la evaluación no necesita abordarse a toda la organización, las evaluaciones SPICE se puede realizar únicamente en aquellos procesos que sean áreas de problema.
El modelo de referencia SPICE no contiene una estrategia de mejora del proceso. Esto puede verse como positivo o negativo dependiendo de lo que se quiera.
Pero la ventaja principal es que al disponer de un estándar internacional se pueden realizar comparaciones a nivel mundial entre evaluaciones en contextos similares.1
1 DE AMESCUA, Antonio; LLORENS, Juan; GARCÍA, Angel. Knowledge Reuse Group. (2009). SPICE: Un marco para la evaluación de procesos de software. [en línea]. Enlace web: www.ie.inf.uc3m.es/grupo/Investigacion/LineasInvestigacion/Articulos/spice.doc. [Leído: 6 de enero 2010, 15.00 h GMT+1].
1.6.4. Trillium Model
El modelo Trillium es un producto usado por Bell Canada para dar valor al desarrollo de un producto y apoyar las capacidades de proveedores de telecomunicaciones o productos basados en tecnologías de la información existentes o futuros (Trillium, 2000). El modelo ha sido diseñado para ser aplicado a sistemas de software 'empotrados' tales como sistemas de telecomunicaciones, no obstante buena parte del modelo puede ser aplicado a otros segmentos de la industria del software como sería el área de Management Information Systems.
1.6.4.1. Características del Modelo Trillium
Con respecto al CMM, el modelo Trillium, se distingue en que:1
– define roadmaps en lugar de áreas clave; tiene una perspectiva orientada al producto, haciéndolo más general y de amplio uso;
– da amplia cobertura a los aspectos que inciden o impactan en la capacidad del proceso; y,
– se enfoca al cliente en lugar del desarrollo mismo.
Esto consigue que se definan prácticas que guían al proyectista sobre cómo conseguir lo que desea un usuario/cliente donde, en lugar de señalar determinadas metas que se deben alcanzar con ciertas prácticas de diseño, se buscan aquellas prácticas que habiliten la consecución de lo que desea el usuario.
1 ESTAY-NICULCAR, Christian A. Dr. (2009). Fundamentos de Gestión de Proyectos: De la Teoría de Proyectos a la Gestión de Proyectos según el PMBOK. Gestión de Proyectos Informáticos y Cambio. [en línea]. Enlace web: http://www.inf.utfsm.cl/~lhevia/asignaturas/proy_ti/topicos/PMBOK-Apunte.doc. [Leído: 28 de febrero 2010, 15.00 h GMT+1].
1.6.4.2. Niveles de madurez
A semejanza del modelo CMM, el modelo Trillium presenta una escala de cinco niveles de madurez (Trillium, 2000):
– Nivel 1. Desestructurado. En este nivel el proceso de desarrollo es ad-hoc. Los proyectos frecuentemente no pueden satisfacer objetivos de calidad o de programación. El éxito posible se basa más en el trabajo de los individuos que en la propia estructura e infraestructura organizacional.
– Nivel 2. Repetible y orientado al proyecto. El éxito individual del proyecto se consigue a través de una férrea planificación y control de gestión del proyecto, dando especial énfasis a los requerimientos de gestión, técnicas de estimación y configuración del cambio.
– Nivel 3. Definido y orientado al proceso. Aquí los procesos son definidos y utilizados al nivel organizacional, no obstante se acepta que el proyecto sea adaptado a las circunstancias. Los procesos son controlados y mejorados. Se incorporan requerimientos ISO 9001 como procesos de entrenamiento y auditoría interna.
– Nivel 4. Gestionado e integrado. La monitorización y análisis del proceso es usado como mecanismo clave de mejora. Procesos de gestión del cambio y programas de prevención de defectos son integrados. Las herramientas CASE se integran dentro del proceso.
– Nivel 5. Completamente integrado. Metodologías formales son extensivamente usadas. Repositorios organizacionales son usados para soportar y mantener la historia del proceso de desarrollo.
1.6.4.3. Arquitectura Trillium Model
En la figura 1.71 se muestra la arquitectura de Trillium, igualmente plantea una descomposición pero con una diferencia sustancial con el CMM: CMM: no se comienza la descomposición desde los niveles de madurez, sino desde ocho áreas de capacidad (Capability Areas), cada una de las cuales contiene varias roadmaps y estos últimos a su vez contienen prácticas (Practices), usados paulatinamente por niveles de madurez.
De esta forma, la arquitectura de Trillium se caracteriza por poseer (Trillium, 2000):
– Capability Areas (CA), que son áreas centrales de preocupación del modelo Trillium y que encuentran contenidas por prácticas;
– Roadmaps (RM), que son un conjunto de prácticas relacionadas, enfocadas sobre un área o necesidad organizacional, o un elemento específico, dentro del proceso de desarrollo del producto; y,
– Practices, que son las acciones a desarrollar para conseguir una mejor capacidad del proceso, cada una de las cuales se vincula a un nivel de madurez.
Figura 1.7: Arquitectura Modelo Trillium.
1 Trillium, Model Description. [en línea]. (2003). Enlace web: http://www.sqi.gu.edu.au/trillium/t3modc3.html. [Leído: 25 de febrero 2010, 16.00 h GMT+1
Enviado por
Lic. Rafael Gonzalez Freites
Azua de Compostela
Rep. Dominicana
| Página siguiente |