Procesos de software (página 2)

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:
http://www.scribd.com/doc/3062020/Capitulo-I-HERRAMIENTAS-CASE.
[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.

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.

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.

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.

1.6.3. SPICE

Tabla 1.4. Las áreas de proceso del
modelo CMMI.

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.

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.

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.

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

Autor:

Lic. Rafael Gonzalez Freites Azua de
Compostela

Rep. Dominicana