– 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: | – Sin proceso definido. – Sin | |||||
Nivel 2:Repetible | – Administración y control de | |||||
Nivel 3: | – Implementación de | |||||
Nivel 4: | – El foco de este nivel es la | |||||
Nivel 5: | – Prevención de los defectos. |
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 | REPRESENTACIÓN | ||||||
| Nivel de | Nivel de madurez | ||||||
Nivel 0 | Incompleto | – | ||||||
Nivel 1 | Realizado | Inicial | ||||||
Nivel 2 | Manejado | Manejado | ||||||
Nivel 3 | Definido | Definido | ||||||
Nivel 4 | Manejado | Manejado | ||||||
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: | La organización usualmente no | |||
Nivel 2: | En el nivel de madurez 2 se ordena el | |||
Nivel 3: Definido | En el nivel de madurez 3, procesos | |||
Nivel 4: Manejado | En el nivel de madurez 4, la | |||
Nivel 5: | En el nivel de madurez 5, una |
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 | CATEGORÍA | NIVEL DE MADUREZ | |||||
Análisis y Resolución | Soporte | 5 | |||||
Análisis y Resolución | Soporte | 3 | |||||
Aseguramiento de la Calidad de | Soporte | 2 | |||||
Definición de Procesos | Gestión de procesos | 3 | |||||
Desarrollo de Requerimientos | Ingeniería | 3 | |||||
Entrenamiento Organizacional | Gestión de procesos | 3 | |||||
Administración Cuantitativa de | Gestión de | 3 | |||||
Administración de Acuerdos con | Ingeniería | 2 | |||||
Administración de | Gestión de | 3 | |||||
Administración de Riesgos | Soporte | 2 | |||||
Administración de la | Gestión de | 3 | |||||
Administración Integral de | Gestión de | 3 | |||||
Innovación y Despliegue | Gestión de procesos | 5 | |||||
Integración de Producto | Ingeniería | 3 | |||||
Medición y Análisis | Soporte | 2 | |||||
Monitoreo y Control de Proyecto | Gestión de | 2 | |||||
Planificación de Proyecto | Gestión de | 2 | |||||
Procesos Orientados a la | Gestión de procesos | 3 | |||||
Rendimiento de Procesos | Gestión de procesos | 4 | |||||
Solución Técnica | 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 | ||||
Clientes | Un medio para determinar la capacidad – reducir incertidumbre para | ||||
Suministradores | – Un medio para determinar la |
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 | El proceso no está | ||||
Nivel 1. Proceso | El propósito implementado | ||||
Nivel 2.Proceso | El proceso Realizado entrega | ||||
Nivel 3. Proceso | El proceso Gestionado se | ||||
Nivel 4.Proceso | El proceso Establecido se | ||||
Nivel 5. Proceso | El proceso Previsible |
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 | VALOR DE LA INSTANCIA | |||
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 anterior | Volver al principio del trabajo | Página siguiente |