Monografias.com > Sin categoría
Descargar Imprimir Comentar Ver trabajos relacionados

Procesos de software (página 2)



Partes: 1, 2

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

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

 

Monografias.com

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. 

Monografias.com

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.

 Monografias.com

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

Partes: 1, 2
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter