Procesos

Metodologías, Procesos y Modelos de Madurez en Ingeniería de Software

Esta conferencia es fruto de la combinación entre el estudio académico de
procesos, metodologías y modelos de madurez y la experiencia por más de 12
años de llevar a cabo proyectos de desarrollo limitados en tiempo y presupuesto,
dentro de un contexto para optimizar la calidad del software. En la conferencia
se examinan las siguientes preguntas:
Son los modelos de madurez una forma de evaluar el cumplimiento en
presupuesto, tiempo y calidad en el desarrollo de software? Qué son procesos y
metodologías? Qué relación y diferencia hay entre ellos? Como pueden los
procesos y metodologías ayudar a aumentar la productividad y calidad de un
equipo de desarrollo de software? Cuales son las áreas prácticas que ayudan a
mejorar la calidad del software?

A lo largo de los años, reiteradamente muchos de los proyectos de software son

productos de baja calidad, no cumplen con los plazos de entrega ni con el
presupuesto original, esto sin duda, deriva en cliente insatisfechos. Las causas son
muchas, mala toma de requerimientos, toma de requerimientos incompleta,
subestimación de los tiempos y presupuestos, mala planificación, elección no
adecuada del personal entre otros [1]. Con el propósito de resolver esta
problemática surgió una línea de investigación para adoptar metodologías y
herramientas que permitiesen mejorar los procesos de desarrollo de software y así
formalizar los procesos que se utilizaban y su posterior mantención, todo esto con
el único propósito de lograr un software de alta calidad, alta productividad y bajo
en riesgos [2]. Debido a esto surge un nuevo enfoque conocido como metodologías
predominantes.

Las metodologías tradicionales o predominantes se centran en el proceso de

desarrollo del software para controlarlo y mejorarlo determinando las actividades
críticas de éste, pues asume que al mejorar el proceso esto afectaría directa y
positivamente la calidad del producto final y en consecuencia la satisfacción de los
clientes [3]. En base a esto han surgido distintos modelos como CMM, ISO 9000,
BOOTSTRAP, S:PRIME entre otros, que introducen rigurosidad y control sobre el
proceso transformándolo en una actividad mas predecible y eficiente [4].

A pesar de los esfuerzos los problemas iniciales aún existen y esto ha originado
que se cuestione el aporte de las metodologías predominantes a los proyectos de
desarrollo de software. Esto ha generado el desarrollo de otros enfoques con el
mismo fin: lograr un producto de software de alta calidad, alta productividad y bajo
en riesgos. Es por esto que surgieron las metodologías ágiles que a diferencias de
las metodologías predominantes que se centran en el proceso, éstas proponen
definir un equipo de trabajo que incluye al cliente en una participación activa, en
donde los individuos son parte fundamental e importante dentro del desarrollo del
software incluso más que los procesos y herramientas que se usarán [5]. Las
metodologías ágiles más sobresalientes son XP(eXtreme Programming), SCRUM,
CRYSTAL, DSDM, RUP entre otras.

No obstante el desarrollo de nuevos enfoques, metodologías, modelos y

herramientas no ha logrado un desarrollo de productos de software que satisfagan
completamente o en su totalidad a los clientes/usuarios, esto, pues cada
organización informática debe discriminar entre que enfoque utilizar: metodologías
predominantes o metodologías ágiles por ejemplo. Además suele suceder que se
recurran a expertos o a la propia experiencia de los desarrolladores en proyectos
similares, pero no a datos cuantitativos ni a información empírica que demuestren
la aplicabilidad y usabilidad de una práctica de software. Como consecuencia se
toman decisiones en torno al negocio sin una debida certeza si es la más efectiva y
eficaz, introduciendo riesgo al desarrollo y mantención de productos y proyectos de
software.

Por lo anteriormente expuesto, es importante y una necesidad que se definan

enfoques y métricas para determinar la aplicabilidad y usabilidad de distintas
prácticas de software, a que contexto y proyecto se aplican, y así tomar las
decisiones correctas basado en datos cuantitativos y empíricos en torno a cuales
metodologías utilizar en un proyecto de desarrollo software según el contexto del
negocio. Por consiguiente es ha detectado:
•
La ingeniería de software requiere generar nuevas capacidades de
cuantificación, especialmente en relación con la adopción de prácticas de
desarrollo de software y su impacto sobre el negocio.
•
Se necesita desarrollar instrumentos específicos para gestionar cuantitativa y
cualitativamente la implantación de prácticas de software y para dimensionar
los resultados de estas iniciativas desde una perspectiva de negocios. Estos
instrumentos deben ser aplicables a diversos marcos de trabajo: metodologías
ágiles o metodologías predominantes.
•
El desarrollo de estas capacidades e instrumentos permitirá, a largo plazo,
acumular información cuantitativa y cualitativa sobre las prácticas de software,
lo cuál a su vez aportará información objetiva en relación con su utilidad,
facilidad de uso y aplicabilidad.

De esta problemática surge este trabajo de título que pretende diseñar una fábrica
de software experimental definiendo su organización, roles y responsabilidades.
Esta fábrica debe definir un marco de trabajo para el desarrollo de proyectos de
software, basada en métricas y establecer que metodologías y herramientas
utilizar. De esta manera se podrá observar, evaluar la aplicabilidad y efectividad en
las metodologías aplicadas. Acorde a lo anterior esta fábrica ayudará a recolectar
información que permita responder:
• ¿Cuál es el ámbito de aplicación de una práctica de software?
• ¿Qué factores influyen positiva y negativamente sobre la implantación y uso
de una práctica de software?
• ¿Qué recursos demanda la implantación y uso de una práctica de software?
• ¿Cómo influye una práctica de software en el negocio: proceso, personas y
productos de software?

Reiteradamente muchos de los proyectos de software son productos de baja calidad

y no cumplen con los plazos de entrega y el presupuesto original lo que deriva en
cliente insatisfechos. Las causas son muchas, mala toma de requerimientos o toma
de requerimientos incompleta, subestimación de los tiempos y presupuestos, mala
planificación, elección no adecuada del personal [1]. Para resolver esta
problemática surgió una línea de investigación para adoptar metodologías y
herramientas que permitiesen mejorar los procesos de desarrollo de software y así
formalizar los procesos que se utilizaban y su posterior mantención, todo esto con
el único propósito de lograr un software de alta calidad, alta productividad y bajo
en riesgos [2]. Debido a esto surge un nuevo enfoque conocido como metodologías
predominantes.

Las metodologías tradicionales o predominantes se centran en el proceso de

desarrollo del software para controlarlo y mejorarlo determinando las actividades
críticas de éste, pues asume que al mejorar el proceso esto afectaría directa y
positivamente la calidad del producto final y en consecuencia la satisfacción de los
clientes [3]. En base a esto han surgido distintos modelos como CMM, ISO,
BOOTSTRAP entre otros, que introducen rigurosidad y control sobre el proceso
transformando a éste en una actividad mas predecible y eficiente [4].

A pesar de los esfuerzos los problemas iniciales aún existen y esto ha originado que
se desarrollen otros enfoques con el mismo fin: lograr un producto de software de
alta calidad, alta productividad y bajo en riesgos. Es por esto que surgieron las
metodologías ágiles que a diferencias de las metodologías predominantes que se
centran en el proceso, éstas proponen definir un equipo de trabajo que incluye al
cliente, en donde los individuos son parte fundamental e importante dentro del
desarrollo del software incluso más que los procesos y herramientas que se usarán
[5]. Las metodologías ágiles más sobresalientes son XP(eXtreme Programming),
SCRUM, CRYSTAL, DSDM, RUP entre otras.

No obstante el desarrollo de nuevos enfoques, metodologías, modelos y

herramientas aún no se ha logrado el desarrollo de productos de software que
satisfagan completamente o en su totalidad a los clientes, esto pues cada
organización informática debe discriminar entre que enfoque utilizar: metodologías
predominantes o metodologías ágiles por ejemplo. También suele suceder que se
recurran a expertos o a la propia experiencia de los desarrolladores en proyectos
similares, pero no a datos cuantitativos ni a información empírica que demuestren
la aplicabilidad y usabilidad de una práctica de software.

Por lo anteriormente expuesto, es importante que se definan enfoques y métricas

para determinar la aplicabilidad y usabilidad de distintas prácticas de software y en
que contexto funcionan y en cuales otras no, y así tomar las decisiones correctas en
torno a cuales metodologías utilizar en determinado proyecto de desarrollo software
según el contexto del negocio.

De esta inquietud surge este trabajo de título que pretende diseñar una fábrica
de software que permita definir un marco de trabajo para el desarrollo de software
en un contexto experimental pues, será implantada en las carreras de Ingeniería
Informática Aplicada (IIA) e Ingeniería Civil Informática (ICI) de la Universidad de
Valparaíso, donde los alumnos en conjunto con el profesorado a través del
desarrollo de proyectos de software establecerán que metodologías y herramientas
utilizar según los distintos enfoques que presenta esta fábrica. De esta manera
ellos podrán observar y evaluar la aplicabilidad y efectividad en las metodologías
aplicadas.

Los objetivos generales de este trabajo de título son:

• Apoyar la investigación en el área de Ingeniería en Software a través del
diseño de una fábrica de software, basada en métricas, que permita estudiar
prácticas de software y determinar cuales son los factores que las afectan y
así obtener, difundir e intercambiar constantemente datos válidos y
confiables en relación a estas prácticas. A largo plazo, una medición
objetiva, válida y confiable de las prácticas de software permitirá responder:
o ¿cuál es el ámbito de aplicación de una práctica de software?
o ¿qué factores influyen positiva y negativamente sobre la implantación
y uso de una práctica de software?
o ¿qué recursos demanda la implantación y uso de una práctica de
software?
 o ¿cómo influye una práctica de software en el negocio: proceso,
personas y productos de software?

• Un objetivo implícito de este trabajo de título es fortalecer la formación de

los ingenieros informáticos de la Universidad de Valparaíso, a través del
diseño de una fábrica de software que permita a alumnos de pre-grado
desarrollar proyectos, donde puedan relacionar los conocimientos teóricos y
prácticos, lograr una visión crítica sobre las metodologías utilizadas además
de una visión empresarial desde la perspectiva de negocios.

1. Desarrollo de proyectos

Desde hace cuatro décadas, la ingeniería del software se ha venido consolidando

como una rama importante dentro de la informática en busca de métodos de
desarrollo y técnicas que permitan producir software de gran calidad con recursos
limitados. Según la definición del IEEE, la ingeniería del software es un enfoque
sistemático y cuantificable al desarrollo, operación (funcionamiento) y
mantenimiento del software: es decir, la aplicación de ingeniería al software [IEEE,
1993]1.

A pesar de que la ingeniería del software ha conseguido indudablemente notables

éxitos, también es cierto que ha sucumbido a lo que se ha venido a llamar la crisis
del software. Prueba de ello es que hoy en día todavía sigue sin ser posible
cuantificar con exactitud los plazos, costes, recursos humanos y técnicas que lleven
a un desarrollo exitoso del software, tal y como otras ramas de la ingeniería en
otros campos sí han sido capaces de hacer. Sin embargo, el impacto del software
en nuestra sociedad y en la cultura es cada vez más importante y profundo. Al
mismo tiempo que crece su importancia, la comunidad del software trata
continuamente de desarrollar tecnologías que hagan más sencillo, rápido y menos
costosa la construcción de programas de computadores o software de alta calidad.
La tecnología que comprende un proceso, métodos y un conjunto de herramientas
se llama ingeniería del software.

Para poder comprender lo que es el software y consecuentemente la ingeniería del

software, hay que diferenciar que el software es un elemento del sistema que es
lógico, en lugar de físico como cuando se construye hardware; por esto el software
tiene características considerables: (1) El software se desarrolla, no se fabrica; (2)
El software no se estropea y; (3) Aunque la industria tiende a ensamblar
componentes, la mayoría del software se construye a medida.

Según lo antes expuesto se puede decir que la Ingeniería del software es una
disciplina que integra procesos, métodos y herramientas para el desarrollo del
software; para esto existen diferentes modelos de procesos cada uno con ventajas
y desventajas pero que todos tienen una serie de fases genéticas en común que
contienen principios, conceptos y métodos que le permiten llevar a cabo el proceso.

1.1 Marco general de desarrollos de proyectos

Para determinar y establecer el marco de trabajo para desarrollar este trabajo de

titulo, nos basaremos en el Estándar 12207-1996, Software life Cycles Proceses de
IEEE/EIA que identifica tres clases de procesos: primario, de soporte e institucional,
que pueden ser usados en el desarrollo de sistemas de software.
1 IEEE: Standards Collection: Software Engineering, IEEE Standar 610.12-1190,
IEEE, 1993.
El estándar 12207 define “proceso” como un conjunto de actividades y tareas
interrelacionadas, que en conjunto transforman varias entradas en una salida.
Estas actividades tienen una amplia categoría de acción o grupos de acciones
necesarios para completar el proceso y, las tareas son acciones elementales
necesarias para completar las actividades.

El estándar 12207 define el “proceso primario” como la adquisición del sistema de

software basado en:
• Adquisición o Compra (Acquisition): Es el proceso para definir las actividades
del adquisidor, la organización que adquiere el sistema o producto de
software.
• Proveedor o Suministro (Supply): Es el proceso para definir las actividades
del suministrador, por el cual el producto es provisto por proveedor al
comprador.
• Desarrollo (Development): Es el proceso por el cual el producto es diseñado,
construido y testeado por la organización de desarrollo.
• Operación (Operation): Es el proceso en donde el operador día a día sigue el
uso del producto. Define las actividades del operador, la organización que
proporciona el servicio de operar en su entorno, el sistema o producto de
software, y para los usuarios.
• Manteniemiento (Maintenance): Es el proceso usado para mantener el
producto, incluyendo los cambios en la aplicación, el producto y en el
ambiente de operación. Ese proceso incluye la migración y retirada del
producto de software.

Hay que tener en cuenta que el proveedor es comúnmente el que tiene la

idea de cómo comenzar el desarrollo, pero no siempre es así.

En suma, el proceso primario del estándar 12207 identifica un número de “procesos

de soporte del ciclo de vida” (Supporting Life Cycle Processes) los que deberían ser
aplicados en las actividades de desarrollo del proceso primario (o en el proceso de
soporte o institucional) de ser necesario. El proceso de soporte consta de las
siguientes tareas:
• Documentación (Documentation):Consiste en las actividades usadas para
registrar información específica generada por cualquier proceso durante el
ciclo de vida.
• Administración de la Configuración (Configuration Management):Son las
actividades usadas para capturar y mantener con posterioridad información
y productos producidos durante el proceso.
• Aseguramiento de la Calidad (Quality Assurance): Consiste en las
actividades que objetivamente se usan para que el producto y los procesos
asociados estén en conformidad con los requerimientos, el planes
establecidos y su documentación.
• Verificación (Verification): Define las actividades usadas para verificar el o
los producto(s) de software.
• Validación (Validation): Define las actividades usadas para validar el o los
producto(s) de software.
• Puntos de revisión (Joint Reviews): Define las actividades para evaluar el
estado y las actividades de otros productos. Puede ser usado en dos partes:
la revisada y la revisora.
• Auditoria (Audits): Consiste en las actividades usadas para determinar la
consistencia del proyecto con los requerimientos, planes y contratos. Puede
ser usado en dos partes: la auditoria y la auditada.
 • Resolución de problemas (Problem Resolution): Describe las actividades y
procesos para analizar y eliminar que se han descubierto en los productos
durante la ejecución del proceso de desarrollo, operación, mantención u
otros procesos, sean de cualquier naturaleza y causa.

Es claro que muchos de estos proceso de soporte juegan un rol critico en el

proceso de desarrollo.
Finalmente, el estándar 12207 describe un número de procesos de ciclo de vida
institucional (Organizational Life Cycle Processes) el cual desde un contexto
organizacional local que internamente el proyecto comienza a ejecutar:
• Administración o Gestión (Management): Define las actividades básicas de la
administración de la organización, pero no incluye límites de administración
del proyecto ni como ellos relatan otros procesos de ciclo de vida.
• Infraestructura (Infrastructure): Define las actividades necesarias para
establecer un lugar (infraestructura) de los procesos de ciclo de vida. Esto
incluye no limitar los ítem de capital y costos, como lo son el personal.
• Mejoramiento (Improvement): Define las actividades básicas que una
organización (adquisidor, suministrador, desarrollador, operador,
mantenedor o gestor de otro proceso) lleva a cabo para establecer, medir,
controlar y mejorar el desarrollo de cualquier proceso.
• Entrenamiento (Training): Define las actividades necesarias para entregar el
entrenamiento al personal del proyecto.

Este proceso organizacional pretende comúnmente aplicarse a múltiples proyectos.

En muchas organizaciones maduras (con medidas e indicadores de la madurez del
proceso tal como está definido en los modelos CMM, CMMI o SPICE), existe la
expectación que las organizaciones identifiquen e institucionalicen los procesos que
usan en los programas. Es más, muchas organizaciones maduras han desarrollado
e institucionalizado lo que frecuentemente es referido como “el proceso base
organizacional” el cual es una medida (siguiendo el proceso de documentación y
disciplina) para encontrar los requerimientos y condiciones para especificar los
proyectos y programas. Estas consideraciones impactan en el mejoramiento de
procesos en particular. La Figura 1 muestra un esquema con las interrelaciones
entre los procesos explicados en el Estándar 12207 IEEE/EIA.

1.2 Actividades de Desarrollo

La ingeniería del software es una disciplina que integra procesos, métodos y

herramientas para el desarrollo de proyectos de software. Se han propuestos varios
modelos de procesos de ingeniería del software diferentes, cada uno con ventajas y
desventajas, pero todos tienen una serie de fases genéricas en común, esto con el
propósito de disminuir la complejidad del proceso de producción de software. Esta
descomposición ha recibido el nombre de Ciclo de Vida del Software que cuenta con
las siguientes fases principales:
• Análisis y Definición de Requisitos: El proceso de reunión de requisitos
se intensifica y se centra especialmente en el software. Para comprender la
naturaleza de los programas a construirse, el ingeniero o analista debe
comprender el dominio de información del software, así como la función
requerida, rendimiento e interconexión. Esto se define en determinar e
identificar los requisitos de datos, funciones y comportamientos entregados
por el cliente. Estos son refinados y analizados para verificar su claridad,
completitud y consistencia obteniendo una especificación de requerimientos
que se incorpora al modelo del software y que es validada tanto por los
ingenieros como por los clientes/usuarios.
 Figura 1. Interrelaciones de los procesos del Estándar 12207 IEEE/EIA.

• Diseño: El diseño del software es realmente un proceso de muchos pasos

que se centra en cuatro atributos distintos de programa, estructura de
datos, arquitectura del software, representaciones de interfaz y detalle
procedimental(algoritmo). El proceso de diseño traduce requisitos en una
representación del software donde se pueda evaluar su calidad antes de que
comience la codificación donde se desarrollan, revisan y documentan los
refinamientos progresivos de los atributos ya nombrados dando como
resultado representaciones del software para evaluar la calidad.
• Programación e Implementación: Es el proceso creativo que traduce el
diseño a un lenguaje de programación, donde cada componente de diseño
es codificado como un programa modular, en esta etapa es donde se genera
el software que será entregado posteriormente al cliente con la
documentación (interna y externa) correspondiente.
 • Prueba e instalación: Una vez que se ha generado el código, se diseñan
los casos de pruebas y asignación de responsabilidades con el objetivo de
encontrar errores. El proceso de pruebas se centra en los procesos lógicos
internos del software, asegurando que todas las sentencias se han
comprobado, y en los procesos externos funcionales, es decir, realizar
pruebas para la detección de errores y asegurar que la entrada definida
produce resultados reales de acuerdo con los resultados requeridos y
especificados en las etapas anteriores. Posteriormente se entrega e instala
el software al cliente con un período de marcha blanca generalmente.
• Operación y mantenimiento: El software indudablemente sufrirá cambios
después de ser entregado al cliente, esto debido a que se han encontrado
errores, el software debe adaptarse para acoplarse a los cambios de su
entorno externo o porque el cliente requiere mejores funcionales o de
rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada
una de las fases precedentes a un programa ya existente o a uno nuevo.

1.3 Modelo de Ciclos de Desarrollo

A partir de estas fases descritas anteriormente han surgido distintos paradigmas o

modelos de ingeniería de software según la naturaleza del proyecto y de la
aplicación, los métodos y las herramientas a utilizarse, los controles y las entregas
que se requieren. Cada uno de estos paradigmas se ha caracterizado de forma que
ayudes al control y a la coordinación de un proyecto de software. Algunos de los
modelos más conocidos son:
• Modelo clásico o cascada: sugiere un enfoque2 sistemático secuencial
para el desarrollo del software que comienza en un nivel de sistemas y
progresa con el análisis, diseño, codificación, pruebas y mantenimiento. Este
modelo resulta un enfoque razonable cuando los requisitos se han entendido
correctamente y no cambiaran durante el ciclo de vida del software.
• Modelo de Prototipo: Este modelo comienza con la recolección de
requisitos, el desarrollador y el cliente encuentran y definen los objetivos
globales para el software, identifican los requisitos conocidos y las áreas del
esquema donde es obligatoria mas definición. Así aparece un “diseño rápido”
que se centra en una representación de los aspectos del software que serán
visibles para el cliente/usuario. Este diseño rápido lleva a la construcción de
un prototipo que es evaluado por el cliente/usuario y se utiliza para refinar
los requisitos del software a desarrollar. Este prototipo itera para satisfacer
las necesidades del cliente y permite al desarrollador comprender mejor el
problema. Las principales etapas son: Recolección y refinamiento de
Requerimiento, Rápido diseño, Construcción del prototipo, evaluación del
prototipo, Refinamiento del prototipo y Producto de ingeniería.
• Modelo incremental: Combina elementos del modelo cascada con la
filosofía interactiva de construcción de prototipos. Este modelo aplica
secuencias lineales de forma escalonada mientras progresa el tiempo en el
calendario donde cada secuencia lineal produce un incremento del software.
El modelo incremental entrega el software en partes pequeñas pero
utilizables, llamadas incrementos y donde cada incremento se construye
sobre aquel que ya ha sido entregado.
• Modelo Evolutivo: En este modelo los requerimientos son abarcados en
subconjuntos que se desarrollan hasta lograr un producto operacional en
cada incremento lo que convierte a este modelo en un proceso iterativo.

2Aunque el modelo original en cascada propuesto por Winston Royce hacia

provisiones para “bucles de retroalimentación”, la gran mayoría de las
organizaciones que aplican este modelo de proceso lo hacen como si fuera
estrictamente lineal.
 Este modelo solo trabaja con los requerimientos conocidos y en cada
incremento se pueden incorporar aquellos que no estaban claros en un
comienzo. Esto permite obtener Feedback del cliente y los usuarios
disminuyendo los riesgos del software.
• Modelo Espiral: Es un modelo de proceso de software evolutivo que
conjuga la naturaleza del modelo de prototipos con los aspectos controlados
y sistemáticos del modelo cascada. En este modelo, el software desarrollo
una serie de versiones incrementales que pueden ser un prototipo. Las
actividades que lo componen son: Comunicación con el cliente, Planificación,
Análisis de riesgos, Ingeniería, Construcción y acción y Evaluación del
cliente.
• Modelo DRA (Desarrollo Rápido de Aplicaciones): Este es un modelo de
proceso de desarrollo de software lineal secuencial que enfatiza un ciclo de
desarrollo extremadamente corto. Es una adaptación a “alta velocidad” del
modelo cascada en el que se logra el desarrollo rápido utilizando una
construcción basada en componentes. Si se comprenden bien los requisitos
y se limita el ámbito del proyecto, DRA permite al equipo de desarrollo crear
un sistema completamente funcional dentro de períodos cortos de tiempo.
Este enfoque comprende las siguientes fases: Modelado de gestión,
Modelado de datos, Modelado del proceso, Generación de aplicaciones y
Pruebas y entrega.

1.4 Actividades de Gestión

La técnicas de gestión son necesarias para planificar, organizar, supervisar y

controlar los proyectos de software desde la fase preliminar a la implementación
operacional, con el único propósito de entregar un producto de alta calidad y
puntualmente al cliente. Para saber que se debe gestionar hay comprender las
“cuatro P”:
• Personal: El personal debe estar organizado para desarrollar el trabajo del
software con efectividad. El personal debe organizarse en equipos eficaces,
coordinados y motivados para hacer un software de alta calidad.
• Producto: La comunicación con el cliente debe ocurrir para que se
comprenda el alcance del producto y los requisitos de éste, para considerar
las posibles soluciones e identificar las dificultades técnicas y de gestión.
• Proceso: Debe seleccionarse el proceso adecuado para el personal y para el
producto según las características del mismo. Además se establece un
número pequeño de actividades que se pueden aplicar a todos los proyectos
de software, sin tener en cuenta tamaño y complejidad. Algunos de estas
actividades pueden ser hitos, productos de trabajo y puntos de garantía de
calidad que permiten adaptarse a las características del proyecto y a su
equipo de desarrollo. Además otras actividades como aseguramiento de
calidad del software (SQA), gestión de la configuración del software (SCM) y
mediciones permiten cubrir el modelo del proceso.
• Proyectos: El proyecto debe planificarse estimando el esfuerzo y el tiempo
para cumplir las tareas, definiendo los productos de trabajo, estableciendo
puntos de control de calidad y estableciendo los mecanismos para controlar
y supervisar el trabajo definido en la planificación. Además se deben
determinar y comprender los factores críticos que conducen a la gestión
correcta del proyecto.

Lo anterior se traduce en un plan de proyecto que se realiza al comienzo de las

actividades de gestión. El plan define el proceso y las actividades que debe realizar
el personal que realizará el trabajo y los mecanismos para evaluar los riesgos,
controlar el cambio y evaluar la calidad del producto final.

En base a lo anterior se pueden definir las actividades básicas en la gestión de

proyectos: Medición y métricas, Estimación, Análisis de Riesgos, Calendarización y,
Seguimiento y control. A continuación se explica cada una brevemente.
• Medición y Métricas: El proceso de software y las métricas del producto
son una medida cuantitativa que permite a la gente del software tener una
visión profunda de la eficacia de los procesos del software y de los proyectos
que dirigen utilizando el proceso como marco de trabajo. Se reúnen los
datos básicos de calidad y productividad que son analizados, comparados y
evaluados para determinar las mejoras en la calidad y productividad. Las
métricas pueden ser usadas para señalar áreas con problemas a través de
una evaluación objetiva de manera de solucionarlas y mejorar el proceso del
software.
Existen cuatro razones para medir los procesos del software, los productos y
los recursos: Caracterizar, Evaluar, Predecir y Mejorar. Caracterizamos para
comprender mejor los procesos, los productos , los recursos y los entornos
de trabajo para establecer las líneas bases para las comparaciones con
evaluaciones futuras. Evaluamos para determinar el estado con respecto al
diseño, las medidas sirven como sensores para saber cuando nuestros
proyectos y procesos no se encuentran bajo control. Predecimos para poder
planificar y aumentar la comprensión de las relaciones entre los procesos y
los productos y así establecer objetivos alcanzables para el coste,
planificación y calidad de manera que se puedan aplicar los recursos
apropiados. Medimos para mejorar al recoger información cuantitativa que
nos ayude a identificar los problemas e ineficiencias y oportunidades para
mejorar la calidad del producto y el rendimiento del proceso. Durante le ciclo
de vida del software se mide la efectividad de SQA, SCM y gestión del
proyecto.
• Estimación: Antes que el proyecto comience el equipo de software debe
realizar una estimación del trabajo a realizar, los recursos necesarios
(humanos, tecnológicos, monetarios) y del tiempo que llevará construir el
software. Los pasos básicos para realizar la estimación comienza con la
descripción del ámbito del producto, mientras este no se delimita no es
posible realizar la estimación. Una vez delimitado el problema se
descompone en un conjunto de problemas de menos tamaño y cada uno de
estos se estima guiándose con datos históricos y con la opinión de expertos
o su propia experiencia. Es aconsejable realizar las estimaciones utilizando
al menos dos métodos diferentes como comprobación. La complejidad y el
riesgo del problema se consideran antes de realizar la estimación final.
Como resultado de la estimación se obtiene una tabla que indica las tareas a
desarrollar, las funciones a implementar, y el coste, esfuerzo y tiempo
necesario para la realización de cada una, además se obtiene una lista con
los recursos necesarios para llevar a cabo el proyecto. Algunas técnicas de
estimación son Puntos de Función (PF) y COCOMO.
• Análisis de Riesgos: El análisis y gestión de riesgos son una serie de pasos
que ayudan al equipo de desarrollo a comprender y gestionar la
incertidumbre. Un riesgo es un problema potencial, que puede ocurrir o no,
y es importante identificarlo, evaluar su probabilidad de ocurrencia, estimar
su impacto y priorizarlos, establecer un plan de contingencia y mitigación
por si ocurre el problema, y en caso de que el riesgo aparezca este debe ser
monitoreado. Los riesgos analizados y gestionados deben derivarse del
estudio del personal, del producto, del proceso y del proyecto. Al realizar el
análisis de riesgos se obtiene un informe de riesgos o un plan de reducción,
supervisión y gestión del Riesgos (RSGR).
 • Calendarización: Aquí se debe asignar los recursos (HH disponibles,
económicos, hardware, software, entre otros) y tiempos considerando el
marco de proceso (process framework) del desarrollo del software
(estimaciones, riesgos, etc.).
• Seguimiento y Control: Esta actividad se encarga de unir las actividades
anteriores ya definidas, es decir, debe crear una red de tareas de ingeniería
de software que le permitan conseguir el trabajo realizado a tiempo. Una
vez creada la red debe asignar responsabilidades para cada tarea,
asegurarse de que se realicen y adaptar la red antes de que los riesgos se
conviertan en realidad. Esto se realiza para comprender la interdependencia
de las tareas y definir cuales se realizan en paralelo y cuando se debe
comenzar una tarea (tarea precedente). Además sirve para evaluar el
progreso del proyecto que sería muy difícil de hacer sin una planificación. En
resumen una panificación adecuada requiere que (1) todas las tareas
aparezcan en la red; (2) el esfuerzo y el tiempo se asigne inteligentemente
a cada tarea; (3) las relaciones entre las tareas estén unduladas
correctamente; (4) los recursos sean asignados al trabajo a realizar; y (5)
los hitos se sitúen rigurosamente espaciados para que se pueda seguir el
progreso.

A continuación se explicará dos de las actividades más importantes de gestión: SQA

y SCM

• Aseguramiento de la Calidad del Software (SQA): Es una actividad de

protección que se aplica a lo largo de todo el proceso del software y su
propósito es entregar a la administración visibilidad adecuada del proceso
utilizado y del producto construido mediante acciones sistemáticas y
planificadas que aseguren la calidad de dichos procesos del software. SQA
engloba: (1) un enfoque de gestión de calidad; (2) tecnología de ingeniería
del software efectiva (métodos y herramientas); (3) revisiones técnicas
formales que se aplican durante el proceso del software; (4) una estrategia
de prueba multiescalada; (5) el control de la documentación del software y
de los cambios realizados; (6) un procedimientos que asegure un ajuste a
los estándares de desarrollo de software (cuando sea posible); y (7)
mecanismos de medición y generación de informes. Para que SQA se lleve a
cabo correctamente primero hay que definir que es “calidad del software”,
luego crear un conjunto de actividades (plan de SQA) que ayuden a
garantizar que todo producto de la ingeniería del software presenta alta
calidad, llevar a cabo las actividades de SQA en cada proyecto y, finalmente
utilizar métricas para desarrollar estrategias que mejoren el proceso de
software; esto se traduce que durante el análisis, diseño, y codificación SQA
genera un breve informe de la revisión de la técnica formal.
La Calidad del Software que utilizaremos se define como: “Concordancia con
los requisitos funcionales y de rendimiento explícitamente establecidos,
con los estándares de desarrollo explícitamente documentados, y con las
características implícitas que se espera de todo software desarrollados
profesionalmente” [1]. De esta definición se puede hacer hincapié en :
o Los requisitos del software son la base de las medidas de calidad. La
falta de concordancia con los requisitos es una falta de calidad.
o Los estándares especificados definen un conjunto de criterios de
desarrollo que guían la forma en que se aplica la ingeniería de
software. Al no seguir los criterios, casi siempre habrá falta de
calidad.
o Existen un conjunto de requisitos implícitos que a menudo no se
mencionan. Si el software se ajusta a los requisitos explícitos pero
falla en alcanzar los requisitos implícitos, la calidad del software no
 es completa.
De la definición podemos nombrar distintas visiones de calidad como:
Trascendental, Del usuario, Del productos, Del producto y Basada en valor.
Cada una de estás con atributos internos, externos, del proceso y del
producto, como por ejemplo correctitud, confiabilidad, robustez,
desempeño, user friendliness, reusabilidad, portabilidad, entre otros.
Se establece un Grupo de SQA que es independiente al equipo de desarrollo
de un proyecto de software, son profesionales especializados en el área de
Aseguramiento de la calidad del software. Este grupo sirve como
“representación” del cliente, es decir, debe mirar el software desde el punto
de vista del cliente y tratan de ayudar al equipo de ingeniería del software
en la consecución de un producto final de calidad. Cabe destacar, que tener
contar un grupo de calidad dedicado no garantiza por sí sola que los
procesos sean seguidos y la calidad se espontáneamente en el producto.
Debe existir un compromiso de toda la organización por orientarse hacia una
cultura de calidad.
Se recomiendan un conjunto actividades para un grupo de SQA:
o Establecimiento de un plan de SQA para un proyecto: El plan
se desarrolla durante la planificación del proyecto y es revisado por
todas las partes interesadas. Las actividades de aseguramiento de
calidad realizadas por el equipo de ingeniería de software y el grupo
de SQA son gobernadas por el plan definido. El plan identifica: (1)
Evaluaciones a realizar; (2) Auditorias y revisiones a realizar; (3)
Estándares que se pueden aplicar al proyecto; (4) Procedimientos
para información y seguimiento de errores; (5) Documentos
producidos por el grupo SQA; y (6) Feedback de información
proporcionada al equipo del proyecto del software.
o Participación en el desarrollo de la descripción del proceso de
software del proyecto: El equipo de ingeniería del software selecciona
un proceso para el trabajo que se va a realizar. El grupo desea revisa
la descripción del proceso para ajustarse a la política de la empresa,
los estándares internos del software, los estándares externos (por
ejemplo: ISO 9000) y a otras partes del plan de proyecto del
software.
o Revisión de las actividades de ingeniería del software para
verificar su ajuste al proceso de software definido: El gripo de SQA
identifica, documenta y sigue la pista de las desviaciones desde el
proceso y verifica que se han hecho las correcciones.
o Auditoria de los productos de software designados para
verificar el ajuste con los definidos como parte del proceso de
software. El grupo de SQA revisa los productos seleccionados;
identifica, documenta y sigue la pista de las desviaciones; verifica
que se han hecho las correcciones, e informa periódicamente de los
resultados de su trabajo al gestor del proyecto.
o Asegurar que las desviaciones del trabajo y los productos del
software se documentan y se manejando acuerdo a un procedimiento
establecido: Las desviaciones se pueden encontrar en el plan del
proyecto, en la descripción de proceso, en los estándares aplicables o
en los productos técnicos.
o Registrar lo que no se ajuste a los requisitos e informar a sus
superiores: Los elementos que no se ajustan a los requisitos están
bajo seguimientos hasta que se resuelven.
Además de estas actividades, el grupo de SQA coordina el control y gestión
de cambios y ayuda a recopilar y a analizarlas métricas del software.
• Gestión de la Configuración del Software (SCM): Es una actividad de
autoprotección que se aplica a lo largo de todo el proceso del software y su
mantención, su propósito es establecer y mantener la integridad de los
productos a través de todo el ciclo de vida del software, proveyendo un
adecuado control de los cambios producidos en los diversos ítems de
configuración. Como el cambio se puede producir en cualquier momento, las
actividades de SCM sirven para: (1) identificar el cambio; (2)controlar el
cambio; (3) garantizar que el cambio se implementa adecuadamente; y (4)
informar del cambio a todos aquellos que puedan estar interesados. Esto se
realiza a través de un plan de Gestión de Configuración del Software, y al
realizar SCM , el proceso de control de cambio del software provoca
peticiones de cambio del software e informes de órdenes de cambios de
ingeniería.
Es importante distinguir claramente entre le mantenimiento del software y
de la gestión de configuración del software. El mantenimiento es un
conjuntos de actividades de ingeniería del software que se producen
después que le software se ha entregado al cliente y está en
funcionamiento. La Gestión de Configuración del Software es un conjunto de
actividades de seguimiento y control que comienzan cuando se inicia el
proyecto de ingeniería del software y termina sólo cuando el software queda
fuera de circulación.
Se debe establecer una unidad de SCM que está compuesta por :
o Oficina de Administración de la Configuración (CMO): Se
define y aplica el plan de SCM, se gestiona y operan las actividades
de SCM y se informa sobre el estado denla configuración.
o Programa de Librería o Biblioteca : Se establece y define la
biblioteca del software donde se almacenan los baselines antiguos y
actuales. Además es el encargado de proveer de copias de los
baselines si estas son solicitadas.
o Control de Configuración de Nivel BOARD(CCB): Sus
actividades son: la declaración de los baselines y sus respectivos
ítems de configuración, se revisan las peticiones de cambios y
evalúan (aprobación o rechazo) de éstas y la conformación de CMO,
jefe de proyecto y los representantes de las áreas afectadas.
SCM se realiza en base a :
o Baselines o Lineas Base: Una o más especificaciones o
productos formalmente revisados y sobre los cuales se ha llegado a
un acuerdo y aprobados en un tiempo específico de ciclo de vos de
los ítem de configuración, y de ahí en adelante sirve como base para
un desarrollo posterior y que puede cambiarse solamente a través de
procedimientos formales de control de cambios[Definición IEEE
610.12-1990]. Un ítem de configuración es cualquier documento o
artefacto que forma parte del software, factible de ser desarrollado y
evaluado independientemente.
o Versión: Instancia de un ítem de configuración que difiere
funcionalmente de otras. Una vez incorporado a un baselines no
puede ser modificado sin dar origen a una nueva versión.
o Release: Versión particular de un producto distribuido fuera
de los límites del desarrollo con un propósito específico.
Cualquier estudio de SCM plantea una serie de preguntas complejas:
¿Cómo identifica y gestiona una organización las diferentes versiones
existentes del software de forma que se puedan introducir cambios
eficientemente?
¿Cómo controla la organización los cambios antes y después de que el
software sea distribuido al cliente?
¿Quién tiene la responsabilidad de aprobar y de asignar prioridades a los
cambios?
¿Cómo podemos garantizar que los cambios se han llevado a cabo
adecuadamente?
¿Qué mecanismo se usa para avisar a otros de los cambios realizados?
De estas interrogantes se definen las actividades o tareas de SCM:
o Identificación de la configuración del software: Se debe
identificar, seleccionar y denominar los Ítem de Configuración (IC) de
cada baselines, y caracterizar funcional y físicamente cada ítem;
Establecer los baselines de cada proyecto; definir mecanismos de
identificación y denominación; y establecer y diseñar la biblioteca del
software para cada proyecto.
o Control de Versiones: Aquí se combinan procedimientos y
herramientas para gestionar las versiones de los objetos
(documentación, programas, etc.) de configuración creados durante
el proceso de desarrollo del software. Cuando se han introducidos
cambios que afectan principalmente la funcionalidad del producto o
versión anterior se genera una nueva versión con los cambios y
modificaciones aprobados. También la gestión de configuración
permite a un usuario especificar configuraciones alternativas del
sistema de software mediante la gestión de atributos en cada versión
del software.
o Control de Cambios: Debe asegurar que lo cambios
identificados sean propuestos, justificados, evaluados, coordinados,
aprobados o rechazados según sea la decisión y documentados e
incorporados a un nuevo baselines si es necesario. Las actividades
que se realizan son: establecer el CCB, recepción y coordinación las
peticiones de cambio, evaluar las peticiones de cambio y monitorear
la implantación de los cambios aprobados.
o Auditorias de la configuración: Su objetivo es establecer que
el producto haya sido construido de acuerdo a los requerimientos y
que el software está realmente representado por la documentación
que le acompañe. Cabe mencionar que la identificación, el control de
revisiones y el control de cambios ayudan al equipo de desarrollo de
software a mantener un orden, pero incluso los mecanismos más
correctos de control de cambios hacen un seguimiento al cambio solo
hasta que se ha generado la orden de cambio e ingeniería (OCI),
entonces como nos aseguramos que el cambio se ha implementado
correctamente. Hay dos formas: (1) Revisiones Técnicas formales
que se centran en la corrección técnica del elemento de configuración
que ha sido modificado, los revisores evalúan el elemento de
configuración del cambio para determinar su consistencia, omisión o
posible efecto secundario; y (2) Una auditoria de configuración del
software complementa la revisión técnica formal al comprobar
características que generalmente no tiene en cuenta la revisión.
o Generación de Informes: Su objetivo es mantener información
sobre la identificación de configuración actual y sobre el estado de los
cambios propuestos, de la implementación de los cambios aprobados
y e los productos entregados. La generación de informes responde a
las siguientes preguntas: ¿Qué pasó?, ¿Quién lo hizo?,¿Cuándo pasó?
Y ¿Qué más se vio afectado?. En esta actividad se debe gestionar la
biblioteca del software y toda la información relacionada además de
la entrega de todo tipo de informes como por ejemplo: el estado de
la configuración, la evolución de la configuración, el estado de los
cambios, la implementación de los cambios, los resultados de las
auditorias, descripción de la versión del software, etc.
1.5 Tendencias

La historia de la ingeniería de software ha evolucionado considerablemente desde

sus inicios, en la actualidad uno de sus principales objetivos se centra
principalmente en minimizar los riesgos, maximizar la calidad de los productos de
software y maximizar la productividad de los procesos[1]. Hoy en día existen
métodos, técnicas y herramientas que ayudan a alcanzar los objetivos de la
ingeniería de software, los cuales ayudan a los desarrolladores a identificar las
actividades importantes y críticas dentro de un proyecto, para poder obtener un
software de calidad. Es por esto que existen principalmente dos grandes grupos de
metodologías: las predominantes y las ágiles.

1.5.1 Metodologías Predominantes

Las metodologías tradicionales o predominantes se centran en el proceso de

desarrollo del software para controlarlo y mejorarlo determinando las actividades
críticas de éste, pues asume que al mejorar el proceso esto afectaría directa y
positivamente la calidad del producto final y en consecuencia la satisfacción de los
clientes [2]. En base a esto han surgido distintos estándares como CMM, ISO,
BOOTSTRAP entre otros, y modelos como el cascada, prototipo, RAD, incremental,
entre otros, donde su principal objetivo es introducir rigurosidad y control sobre el
proceso transformando a éste en una actividad mas predecible y eficiente [3].

La adopción de algunas metodologías y modelos, como las anteriormente

mencionadas, fue una reacción ante la crisis del Software. Esta aproximación era
una respuesta de naturaleza defensiva ante los problemas que se habían detectado
en el desarrollo de software, los cuales se encontraban en la incorrecta estimación
del proyecto y en la compleja ejecución técnicas del proyecto.

Las metodologías tradicionales, proponen solucionarlos definiendo correctamente el

alcance de los proyectos y resolviendo las dificultades técnicas antes de comenzar
la ejecución de un proyecto. Para poder definir el alcance, proponen una detallada
especificación de requerimientos para disminuir su imprecisión. Para eliminar las
dificultades técnicas que se puedan encontrar en el entorno tecnológico cambiante,
en el que se suelen desarrollar los proyectos, proponen una primera fase donde se
detalle la solución técnica que debe ejecutarse, tratando de despejar cualquier duda
tecnológica antes de comenzar.

De cierta forma, las metodologías tradicionales lograron gestionar de manera

óptima y aumentar considerablemente la calidad de los proyectos que se llevaban a
cabo, con la incorporación de SQA y CCM, las cuales eran las encargadas de
gestionar y asegurar la calidad de los proyectos que se desarrollaban.

A continuación se explica brevemente los principales modelos que existen:

• CMM (Capability Maturity Model): El modelo de capacidad de madurez ha
sido un modelo usado por muchas organizaciones para identificar las
mejores prácticas útiles que la ayuden en aumentar la madurez de sus
procesos. Este modelo esta orientado a la mejora de procesos relacionados
con el desarrollo de software, y se ha desarrollado para evaluar las
capacidades de una organización de software e identificar las áreas más
importantes de mejoramiento, tratando el proceso completo de desarrollo
de software como un proceso que puede ser controlado, medido, y mejorado
para obtener una mejor productividad, mejorar sus procesos y calidad. El
modelo de CMM original define cinco nivel de madurez dentro de los cuales
se puede encontrar una organización, cada uno de estos niveles representan
razonablemente las fases históricas de mejoramiento evolutivo de
 organizaciones de software reales, representan una medida de
mejoramiento que es razonable alcanzar desde el nivel previo, sugieren
objetivo de mejoramiento y mediciones de avance intermedios, y hacen
obvio un conjunto de prioridades de mejoramientos inmediato una vez que
el estatus de una organización con respecto a la infraestructura es conocido.
• BOOTSTRAP: BOTSTRAP inicialmente se baso en CMM, al cual se le
añadieron conceptos de calidad de ISO 9000, esta metodología mediante
practicas, herramientas y estándares de calidad internacional, mide, evalúa
y propone mejora el proceso de desarrollo de software. Esta metodología
tiene como principio el reducir los costos y mejorar la calidad de los
productos y su principal objetivo se centra en desarrollar un método para la
evaluación de procesos de desarrollo de software. BOOTSTRAP es un método
para analizar, rediseñar, mejorar los procesos de negocio de desarrollo de
software, los cuales se componen de un modelo, un proceso de evaluación,
una Base de Datos de soporte, un procesos de mejora y los instrumentos de
evaluación. El enfoque de esta metodología es evaluar el procesos, no el
producto, para lo cual se define un conjunto de características para los
procesos, entregando un análisis cuantitativo con vistas analíticas, donde se
hacen evidentes las fortalezas y debilidades, las áreas que hay que mejorar,
proponiendo para ello un plan de implementación.

Además de los modelos CMM y BOOTSTRAP existen otros como SPICE, S:PRIME,
derivaciones de ISO 9000 que también pertenecen a las metodologías
predominantes, si desea ver información de estos y otros modelos favor ver [4].

1.5.2 Metodologías Ágiles

A pesar de la existencia de las metodologías predominantes los problemas iniciales

aún existen y es por esto que se desarrollan otros enfoques con el propósito de
lograr un producto de software de alta calidad, alta productividad y bajo en riesgos.
Esta nueva metodología se conoce como Metodología Ágil y se refieren a un
conjunto de metodologías de desarrollo de software denominadas “livianas”. Estas
proponen una nueva forma de definir procesos de desarrollo rápidos y flexibles, a
diferencia de lo anteriormente visto (Metodologías predominantes), propone definir
un equipo de trabajo incluyendo dentro de este al cliente siendo los individuos parte
fundamental e importante dentro del desarrollo, mucho más incluso que los
procesos y herramientas que se usarán de tal forma que apoye y vea si los avances
obtenidos son los esperados mediante entregas tempranas y continúas, es decir,
los métodos ágiles son orientados a la gente y no orientados al proceso.

En febrero de 2001 en una reunión celebrada en Utha-EEUU se creó The Agile

Alliance, una organización sin fines de lucro, dedicada a promover los conceptos
relacionados con el desarrollo ágil de software y fomentar y ayudar a las
organizaciones que adopten estos conceptos. El objetivo fue esbozar los valores y
principios que deberían permitir a los equipos desarrollar software rápidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto y así ofrecer
una alternativa a los procesos de desarrollo de software tradicionales
(predominantes), caracterizados por ser rígidos y dirigidos por la documentación
que se genera en cada una de las actividades desarrolladas.

La filosofía “Ágil” se resume en lo que se conoce como manifiesto Ágil:

a) Valorar a las personas y las interacciones del equipo de desarrollo por sobre
el proceso y las herramientas.
b) Desarrollar software que funciona más que conseguir una buena
documentación.
c) La colaboración con el cliente más que la negociación de un contrato.
d) Responder frente a los cambios, más que seguir estrictamente un plan.
Algunas de las más importantes metodologías se explican a continuación.
• XP (eXtreme Programing): ésta es la más usada y la que ha recibido más
atención. La programación extrema comienza con 4 valores, mucha gente
olvida la importancia de estos valores, que son esenciales para que sus 12
prácticas tengan sentido y puedan ser llevadas a cabo con éxito, éstas son la
Comunicación que se utiliza dentro del equipo de desarrollo, es lo que se
conoce como “comunicación directa” entre personas, es muy importante
entender cuales son las ventajas de comunicarse de esta forma, pues no
sólo entienden las palabras, sino que también los gestos, miradas, etc.;
Retroalimentación o continuo seguimiento a la hora de desarrollar un
entorno ágil de desarrollo que se obtiene del cliente, de los miembros del
equipo y en cuestión de todo el entorno en el que se mueve un equipo de
desarrollo ágil; Simplicidad a la hora de desarrollar el software debido a
que el futuro no se puede predecir y no invertir esfuerzo en hacer un
desarrollo que en un futuro pueda no tener valor; y Coraje de cada
integrante del equipo de desarrollo de exponer sus dudas, miedos,
experiencias sin “arreglar” estas de ninguna de las maneras. Esto es muy
importante ya que un equipo de desarrollo extremo se basa en la confianza
con sus miembros y por ende faltar a ésta es una falta más que grave.
• SCRUM: ésta metodología define un marco para la gestión de proyectos,
especialmente indicada para proyectos que tengan una alta tasa de cambios
en los requerimientos, debido a que esta basada en la iteración, la
incrementalidad y el equipo, de donde sus principales características se
pueden resumir en dos: (1) El desarrollo de software se realiza mediante
iteraciones, denominadas sprints, con una duración de 30 días, el resultado
de cada sprint es un incremento ejecutable que se muestra al cliente y; (2)
otra característica importante son las reuniones a lo largo proyecto, entre
ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para la
coordinación e integración.
Scrum no define ninguna técnica de desarrollo específica para la fase de
implementación, ya que se centra en la forma en que los equipos deben
funcionar para poder producir la flexibilidad requerida en un ambiente que
cambia constantemente, de forma anexa ayuda a mejorar prácticas
existentes de ingeniería.

Además de los modelos XP y SCRUM existen otros como CRYSTAL, DSDM y RUP
entre otros que también pertenecen a las metodologías ágiles, si desea ver
información de algún modelos favor ver [R1][R2][R3][R4].

Metodologías de desarrollo
En Root creemos que hacer software de un modo compatible con la industria del software global
requiere de la aplicación de metodologías, procesos y lenguajes de vanguardia.

En todos nuestros desarrollos aplicamos metodologías específicas y que mejor se recomiendan para
el perfil de cada proyecto. Entre estas metodologías podemos mencionar Team Software Process,
eXtreme Programming y Proceso Unificado. El uso de estas metodologías nos permite garantizar la
calidad del producto, minimizar riesgos y retrasos, y sobre todo entregar un producto que satisfaga al
cien por ciento las espectativas de nuestros clientes.

Las piedras El desarrollo de productos de software tiene tres grandes

angulares: componentes:

• Personal: incluye el conocimiento y experiencia del

 capital humano que crea y sostiene la evolución del
producto. Sin el personal competente y experimentado,
es imposible crear productos competitivos que
satisfagan las necesidades de los clientes.
• Tecnología: incluye la posesión de las tecnologías que
sustentan el producto y las herramientas utilizadas en
su desarrollo
• Proceso: es el saber como utilizar el conocimiento del
personal y la tecnología en forma eficiente para lograr
productos que alta calidad que satisfagan las
necesidades de los clientes, producidos dentro de
costos y plazos aceptables.

La siempre creciente demanda de las empresas productoras

de software ha producido una crisis en la disponibilidad de
ingenieros de software en el mercado laboral. Los recursos
humanos, cada vez más caros y escasos, deben ser
utilizados de manera la manera eficaz y productiva. Si bien es
cierto el costo de las herramientas para producir software
(computadores y software de desarrollo) ha tenido una
tendencia a la baja, la creciente complejidad de la tecnología
que se debe incorporar en los productos se ha encarecido
(e.g. aumento del costo de investigación y desarrollo,
patentes, etc.)
La importancia
del proceso: Siendo las dos primera componentes cada vez más caras y
escasas, la importancia de los procesos de desarrollo de
software se hace más crítica. El proceso representa una
fuerte inversión en recursos y tiempo. La construcción del
procesos implica una larga incubación estrechamente ligada a
la cultura de la organización y un enorme esfuerzo de
experimentación y errores.

Un proceso inadecuado puede tener graves consecuencias y

acarrear costos intolerables, lo cual puede significar la
diferencia entre el éxito y el fracaso en el competitivo mercado
de nuestros días.

¿Qué significa
mejorar el
proceso?: El mejoramiento de procesos se basa en los principios de
mejoramiento continuo. En vez de proponer una reingeniería
radical de los procesos y competencias existentes en la
empresa, habitualmente de enorme costo y alto riesgo, se
parte de la base que existe un interés genuino de los
 ingenieros y gerentes por crear procesos maduros, que
permitan usar adecuadamente sus talentos y los recursos
asignados. Ambos buscan minimizar los problemas evitables
y fortalecer la prosperidad común que resulta del éxito de la
empresa. El mejoramiento de procesos de software usa
metodologías prácticas basadas en la experiencia colectiva
de la industria de software internacional. Uno de los
estándares de facto más importantes es el método de
madurez de capacidades (CMM), creado por el Software
Engineering Institute - Carnegie Mellon University (Pittsburgh,
PA).

El Modelo de Madurez de Capacidades (conocido en inglés como

"Capability Maturity Model" o por su sigla CMM) es un modelo de prácticas
fundamentales que deben ser implementadas por toda organización
interesada en desarrollar y mejorar la calidad de sus productos y su
productividad. Este modelo está basado en conceptos de calidad total y de
mejoramiento continuo; ha sido elaborado por el Software Engineering
Institute (SEI) de la Universidad Carnegie Mellon y ha sido ampliamente
aceptado por la comunidad de ingeniería de software. Rápidamente se ha
convertido en el estándar de facto en los Estados Unidos de América, y
también a nivel internacional, para evaluar la madurez de procesos que
tienen las organizaciones que producen software. Este modelo se puede
utilizar no solamente como un manual de prácticas recomendables, sino
Visión general: que además como referencia para llevar a cabo auditorías y evaluaciones
internas en las organizaciones que desarrollan y mantienen software.

El SEI ha desarrollado algunos métodos de evaluación basados en este

modelo. Uno de estos métodos es la evaluación basada en CMM para el
mejoramiento interno de procesos, generalmente conocido como CBA IPI
("CMM -Based Appraisal for Internal Process Improvement"); aunque su
principal objetivo es permitir a la empresa la determinación de sus
fortalezas y necesidades de mejoramiento, también permite revisar las
prácticas de los proveedores externos, a objeto de que puedan derivar un
plan de mejoramiento adecuado a su organización.

Referencias
oficiales
El modelo de madurez se encuentra descrito en los documentos
siguientes, cuya versión electrónica (en idioma Inglés) se encuentra
disponible en el sitio WEB del SEI-Carnegie Mellon University.

• Capability Maturity Model, versión 1.1 (SEI/CMU-

93-TR24)
• CMM Practices, versión 1.1 (SEI/CMU-93-TR25)

• Overview of the Capability Maturity Model for

software, by Mark C. Paulk, Bill Curtis, Mary Beth Chrissis,
and Charles V. Weber, IEEE Software, Vol. 10, No. 4, July
 1993, pp. 18-27. (está disponible en
http://www.sei.cmu.edu/technology/cmm/cmm.articles.html
)

La única traducción oficial de los materiales originales del CMM que está
disponible es al Francés (ver http://www.crim.ca).

Hace un tiempo atrás, cuando yo trabajaba para ASEC-CRIM, intentamos

llevar a cabo un proyecto de traducción oficial al Castellano.
Lamentablemente no hubo apoyo financiero suficiente (o quizás falta de
Traducciones interés) ni de empresas ni de gobiernos de países hispano hablantes para
del CMM del cubrir los costos básicos de la traducción y la validación. Por el momento
Inglés a otros nuestros ingenieros de software tendrán que utilizar la versión original en
idiomas Inglés, hasta que un futuro patrocinador esté dispuesto a invertir en una
versión Castellana.

La empresa de traducciones Belimex (belimex@videotron.ca)

de Montreal, Canada, especialista en traducciones Inglés-
Castellano de temas de ingeniería de software, ha contribuido
amablemente a traducir mi versión personal (no oficial) del
CMM, la cual aparece en este sitio.

Qué significa Significa medir el estado actual de los procesos de desarrollos de la

evaluar el organización (ya sea algunos proyectos o toda la organización), de
proceso de manera de conocer las fortalezas, riesgos y debilidades. Los resultados
desarrollo de del diagnóstico harán posible la generación de un plan de mejoramiento
software? adecuado. Midiendo y localizando los problemas reales permitirá asignar
los recursos a aquellas áreas de mejoras más urgentes, o donde la
inversión será más efectiva.

La evaluación de los procesos de desarrollo puede tener los siguientes

objetivos, dependiendo de las necesidades de la empresa o los proyectos
participantes:

• Identificar los puntos fuertes y las debilidades

para iniciar un programa de mejoramiento
• Constatar el progreso alcanzado por las
iniciativas de mejoramiento de procesos en curso
Objetivos de (habitualmente iniciadas como producto de una
una evaluación evaluación anterior)
• Demostrar a una tercera parte (clientes, socios
potenciales, corporación) la madurez de procesos de la
organización (como medio para aumentar las
posibilidades de nuevos negocios)

• Verificar la implementación de los procesos de

desarrollo de software con respecto a un estándar de la
industria, tal como el Modelo de Madurez de Capacidades
(SW-CMM) del SEI, el ISO 9001, el ISO 15504, u otro
similar.
 La evaluación es el resultado final de un proceso que comienza cuando la
gerencia comprende la incidencia que tiene el proceso de desarrollo en la
producción de productos de mejor calidad. Este entendimiento motiva a la
gerencia para decidir el establecimiento de una iniciativa de mejoramiento
Condiciones de procesos. Esto implica el compromiso para asignar los recursos
previas de una adecuados y mantener los objetivos durante el tiempo necesario para
evaluación completar la iniciativa.

Si la gerencia no está convencida de la importancia de un proceso

maduro, existe un elevado riesgo que la iniciativa no prosperará en el
largo plazo.

A menos que se cuente dentro de la organización con un evaluador

experto, conviene obtener los servicios de un especialista externo que
cuente con las calificaciones necesarias y quién, además cuente con una
extensa experiencia en la industria de desarrollo de software. La
evaluación es en sí un proceso de entrenamiento, transferencia
¿Quién realiza tecnológica y motivación del personal. La elección del evaluador es por lo
la evaluación? tanto crítica.

El evaluador debe contar con el apoyo de personal representativo de los

distintos grupos de la organización. Son finalmente ellos, que bajo la
dirección del experto externo, quienes identificarán la realidad de la
organización.

El proceso de la evaluación de procesos tiene las siguientes etapas:

• Decisión de la gerencia para iniciar un

programa de mejoramiento
• Decidir las referencias, modelos o
estándares a seguir
• Decidir los objetivos de la evaluación
Los pasos de la • Seleccionar a un evaluador competente
evaluación • Planear la evaluación
• Instruir a los participantes
• Realizar la evaluación misma (colección y
análisis de información)
• Identificar las fortalezas y debilidades
• Calificar el proceso en relación al estándar
de referencia

• Documentar los hallazgos, conclusiones y

recomendaciones
Algunos de los
métodos
disponibles Entre las opciones que existen para evaluar el proceso de desarrollo de
software, puedo recomendar aquellas con las cuales he tenido experiencia
directa:

• CBA-IPI
• ISO 9001 aplicada al desarrollo de
 software
• ISO 15504 (SPICE)

• S:PRIME

Durante los últimos años la industria del software ha ido experimentado

una crisis creciente de problemas, más o menos comunes a las distintas
categorías de software.

Las principales tendencias de la llamada crisis del software son:

• Calidad insuficiente del producto final

La crisis: • Estimaciones de duración de proyectos y
asignación de recursos inexactas
• Retrasos para entregar los productos terminados
• Costos de desarrollo y mantención de productos
fuera de control
• Escasez de personal calificado en un mercado
laboral de alta demanda

• Tendencia al crecimiento del volumen y

complejidad de los productos

Una solución a esta crisis ha sido la introducción de métodos de ingeniería

en el desarrollo de proyectos de software.

La ingeniería de software es la aplicación de conceptos de ingeniería y

administración al proceso de crear programas de software.

Estos elementos aplicados incluyen:

• principios de ciencias de la computación

• administración de proyectos
• estadísticas
Arte versus • sistemas de administración de la calidad
Ingeniería: • métodos de ingeniería de procesos
• principios de marketing
• técnicas auxiliares (e.g. documentación, control de
inventarios, etc.)

Las metas de la ingeniería de software son las siguientes:

• Lograr el éxito del producto final que se entrega al

cliente y/o al mercado
• Asegurar la eficiencia del proceso de desarrollo y
mantenimiento del producto

Ambas metas consideran los aspectos humanos, manejo de recursos y

construcción del producto.
Elementos de la
Ingeniería de
 La ingeniería de software está compuesta de actividades (también
referidos como paradigmas) que aplican metodologías, herramientas y
procesos a las necesidades de desarrollo del proyecto:

Metodología

Incluye la identificación de necesidades, planificación y estimación de

proyectos, sistemas de calidad, análisis de requerimientos, métodos de
diseño, de codificación y de pruebas, asimismo como métodos de
mantención de productos

Herramientas

Son sistemas automáticos que apoyan la aplicación de las metodologías

Software de la ingeniería de software en el desarrollo del producto. Incluyen
herramientas tales como las llamadas CASE (Computer-Aided Software
Engineering), control automático de configuración, ensayo automático de
software, bibliotecas de módulos reutilizables, bases de datos de registro y
seguimiento de defectos, etc.

Procesos

Definen la secuencia en que las metodologías deben ser aplicadas, la

documentación de cada una de las fases de desarrollo, los controles que
aseguren la calidad de procesos y productos a lo largo del proyecto,
asimismo como la verificación de hitos y progreso durante el desarrollo del
proyecto.

Algunos de los paradigmas más importantes (de entre una larga lista) son
la definición del ciclo de vida del producto, los sistemas de calidad
aplicados al software y el perfeccionamiento de procesos.

Es una disciplina de la ingeniería de software se especializa en la

aplicación de procesos de calidad a lo largo del proyecto de software.

¿Qué es la Su misión no se limita a actividades de verificación, sino que además

Garantía de asume un rol de liderazgo en la gestión de la calidad durante el
Calidad del proceso de creación y diseño del producto. La garantía de calidad no
Software?: debe confundirse con la técnica específica de control de calidad, cuyo
objetivo es verificar el producto.

Una concepción errónea que aún persiste en la industria, es limitar su

acción al aseguramiento de la calidad del producto y a constatar
adherencia a estándares.
Responsabilidades
de la la Garantía de
Calidad : La garantía de calidad toma responsabilidad por los siguientes
procesos:

• gestión de los procesos de ingeniería

de software
• iniciativas de mejoramiento de
procesos a lo largo de la organización,
 • integración de los procesos de calidad
de ingeniería y servicios a la clientela

El liderazgo de la garantía de calidad puede ser asumida en

organizaciones pequeñas o muy jóvenes por el jefe del proyecto,
siendo el grupo de desarrollo el responsable de su ejecución. Estos
individuos pueden provenir de organizaciones más maduras donde
hayan adquirido el "know-how" en procesos de calidad, o pueden
hacerse asesorar por consultores externos que los ayuden a definir
sus sistema de calidad.

A medida que las organizaciones crecen y se estabilizan, tiene mucho

más sentido dedicar un grupo de ingenieros de software a la gestión
de la calidad. El primer beneficio es liberar a gerentes y personal
experto de una tarea accesoria a sus funciones principales. Un grupo
especializado garantiza que la experiencia queda permanentemente
en la compañía, independientemente de la partida de los individuos.
La garantía de calidad es una especialidad compleja y abundante en
El grupo de metodologías, que hace necesaria la especialización de sus
Garantía de profesionales. Su énfasis es en procesos y no en creación de
productos. A medida que la madurez de una organización crece, se
Calidad del hace evidente la necesidad de asignar la gestión de la calidad a
Software: ingenieros de calidad especializados.

Una condición básica para que exista una garantía de calidad eficaz
es que el grupo responsable sea independiente de la gerencia del
proyecto, a objeto de garantizar su objetividad y permitirle la libertad
necesaria para señalar problemas. Usualmente este grupo depende
directamente de la vicepresidencia de la compañía. En caso de
conflicto de interpretación de una situación específica con el
responsable del proyecto, el grupo de calidad puede escalar su
informe a una autoridad superior para arbitraje.

Los beneficios
de la Garantía de El beneficio principal de un programa de garantía de calidad de
software es asegurar a la gerencia del proyecto que los procesos
Calidad del establecidos se han ejecutado cabalmente. Esta evaluación es hecha
Software: por un grupo independiente, especializado en métodos de calidad, con
un criterio objetivo y con visión de contexto.
Actividades
principales dela La garantía de calidad se asegura de lo siguiente:
a Garantía de
Calidad del • Se usa la metodología de desarrollo
Software: apropiada
• Las actividades de desarrollo han sido
debidamente planeadas
• Se han definido estándares y
procedimientos para al proyecto
• El personal ha sido debidamente
entrenado en los procesos de calidad
aplicables
• Se llevan a cabo regularmente
revisiones y auditorías independientes
• El desarrollo es documentado
adecuadamente para facilitar la mantención y
la reutilización
 • La documentación se produce
oportunamente y no después que el desarrollo
ha sido completado
• Los cambios introducidos han sido
debidamente controlados
• Las pruebas efectuadas son eficaces
para detectar defectos, especialmente en
aquellas áreas de mayor riesgo
• Las actividades se llevan a cabo de
acuerdo a los plazos y en los términos
planeados
• Las desviaciones a los estándares se
identifican rápidamente
• El proyecto está en condiciones para
ser sometido a auditorías externas, si
corresponde
• La calidad es verificada con respecto a
criterios preestablecidos
• La gerencia es oportunamente
informada de problemas y riesgos relativos a
la calidad

• Los problemas de calidad se analizan

y las causas se comunican al proyecto para
tomar medidas preventivas que eviten su
repetición

Los aspectos de La calidad en el software tiene 3 dimensiones:

la Garantía de
• El sistema de calidad
Calidad del • La aplicacion adecuada del proceso
Software:
• La actividades que aseguran la calidad del
producto
Sistemas de El sistema de calidad ISO 9001 se aplica también al desarollo y
Calidad del mantenieniento del software. Si desea más detalles, siga este
Software: vínculo.

Ciclo de Vida El CVPS es el conjunto de procesos sistemáticos que tienen lugar durante
del Producto de la existencia del producto, desde su concepción inicial hasta que la
organización decide no continuar manteniéndolo.
Software
(CVPS): La vida de un producto de software, independientemente del modelo
elegido, está compuesta por tres fases genéricas: Definición, Desarrollo y
Mantenimiento

¿Qué es es el EL SEI ha propuesto un ciclo de mejoramiento de procesos

modelo IDEAL?: conocido como IDEALSM, el cual proporciona un conjunto de
actividades coherentes para sustentar la adopción de las
prácticas recomendadas por el CMM.
 Cuando no se cuenta con los recursos internos (e.g. personal
que haya implantado CMM previamente) es conveniente
recurrir a ayuda experta externa, que proporcione guía en la
evaluación de las necesidades y en la preparación del plan de
acción, como mínimo. Como parte de la solución viene la
preparación de recursos internos (e.g. mediante trasferencia
¿Cómo aplicar el tecnológica, cursos), quienes serán finalmente los
modelo IDEAL?: responsables de la implantación. Se recomienda asignar un
equipo experto para que conduzca el proyecto de
mejoramiento, así como capacitar suficientemente a todos los
niveles organizacionales involucrados en los objetivos del
programa y las prácticas que se desea implementar.

Se pueden encontrar las publicaciones originales sobre este

modelo en el sitio WEB del SEI-CMU.
¿Dónde puedo
hallar más El propósito y las actividades principales de cada etapa se
información sobre resumen a continuación en el siguiente paper en Castellano:
el modelo IDEAL?: El modelo IDEAL

Las 5 fases principales que componen el modelo de

mejoramiento de procesos propuesto por el SEI, conocido
como ciclo IDEALSM (sigla formada con las primeras letras de
Las fases del
modelo IDEAL: las palabras inglesas que identifican las fases), son Iniciar
(Initiating), Diagnósticar (Diagnosing), Establecer
(Establishing), Actuar (Acting), y Difundir (Leveraging)
Es establecer los fundamentos básicos para garantizar que la
iniciativa de mejoramiento de procesos.
Iniciar:

Es evaluar mediante un método formal las fortalezas y

debilidades del proceso seguido por los proyectos.
Diagnósticar:

Es realizar la planificación específica de los mejoramientos

que se desea alcanzar.

Establecer: Se desarrolla un plan detallado que sirve como plan de

proyecto.

Actuar: Es simplemente implementar el mejoramiento de procesos

llevando a cabo el plan de acción
 Aquí se introducen o mejoran los procesos (e.g.
modelamiento, introducción de nuevas metodología, etc.), se
entrena a los respectivos niveles de personal, se miden los
avances/beneficios logrados, se realizan proyectos pilotos, se
implanta los procesos mejorados en los proyectos nuevos o
existentes, se hacen mini-evaluaciones para constatar la
evolución del plan, etc.

Es aprender de la experiencia del ciclo recién realizado y

aumentar la habilidad de la empresa u organización para
Difundir: mejorar los procesos en forma continua.

Traducción en Término CMM Significado

Castellano en Inglés

Actividad Activity Los procedimientos

necesarios para
implementar un ár
clave de proceso.
Comprende el
establecimiento de
planes y
procedimientos, la
ejecución del traba
el seguimiento del
mismo, el control d
las salidas del
proceso, y las
acciones correctiva
que deben tomarse
según sea necesar

ACTUAR ACTING Etapa del ciclo IDE

en que se introduc
o mejoran los
procesos (e.g.
modelamiento,
introducción de
nuevas metodologí
etc.), se entrena a
respectivos niveles
 personal, se miden
los
avances/beneficios
logrados, se realiza
proyectos pilotos, s
implanta los proces
mejorados en los
proyectos nuevos o
existentes, se hace
mini-evaluaciones
para constatar la
evolución del plan,
etc.

Area de Proceso Clave Key Process Area Identifica una

agrupación de
actividades y
prácticas
relacionadas, las
cuales cuando son
realizadas en form
colectiva permiten
lograr alcanzar las
metas fundamenta
del proceso. Puede
clasificarse en 3 tip
de proceso: Gestió
Organizacional e
Ingeniería

-C-

Traducción en Castellano Término CMM en Inglés Significado

Capacidad de realización Ability to perform Describe las condiciones

previas que debe existir e
el proyecto o la organizac
para poder aplicar el
proceso de software en
forma efectiva.
Normalmente enfocan los
recursos, las estructuras d
la organización, el
entrenamiento y las
condiciones previas que

Característica común
Ciclo de vida del software
Comité de control de la
configuración del software
Compromiso de realización
Control cuantitativo
Control de la configuración
Coordinación Intergrupal
Cuadro de Evaluación del
CMM
Cuestionario de madurez
Cuestionario del proyecto
deben existir
Common feature Atributos que indican si l
implementatción y la
institucionalización de un
proceso clave es efectivo
repetible y duradero
Software life cycle El conjunto de procesos
sistemáticos que tienen
lugar durante la existenc
del producto, desde su
concepción inicial hasta q
la organización decide no
continuar manteniéndolo
Software Configuration Grupo representativo de
Control Board distintos departamentos
que tiene autoridad para
decidir los componentes
cada una de las versione
del producto de software
así como autorizar su
entrega a los clientes
Commitment to perform El compromiso para
realización describe las
acciones que la
organización debe tomar
para asegurar que el
proceso se establezca y s
permanente. Normalmen
abarcan el establecimien
de políticas y liderazgo a
nivel de la organización
Quantitative control
Configuration control
Intergroup Coordination
CMM Appaisal Framework
(CAF)
Maturity questionnaire
Project Questionnaire
-D-

Traducción en Castellano Término CMM en Inglés Significado

Debilidad, Oportunidad para Weakness Desviación o

mejorar implementación insuficie
de prácticas de ingeniería
de software en la
organización

Definición del Proceso de la Organizational Process

Organización Definition

DIAGNOSTICAR DIAGNOSING Etapa del ciclo IDEAL en

que se evalúa mediante
método formal las
fortalezas y debilidades d
proceso seguido por los
proyectos

DIFUNDIR LEVERAGING Etapa del ciclo IDEAL en

que se aprende de la
experiencia del ciclo reci
realizado y aumentar la
habilidad de la empresa
organización para mejora
los procesos en forma
continua

-E-

Traducción en Castellano Término CMM en Inglés Significado

Enfoque en el Proceso de la Organizational Process

Organización Focus

Equipo de evaluación Assessment team

ESTABLECER ESTABLISHING Etapa del ciclo IDEAL en

que se realiza la
planificación específica d
los mejoramientos que se
desea alcanzar
Evaluación Appraisal, Assessment Es la determinación de la
manera en que las prácti
de ingeniería de software
han sido implementadas
por la organización,
habitualmente usando el
CMM como referencia.
Puede ser realizada por
evaluadores externos o
internos, dependiendo si
propósito es determinar
competencia o mejorar
internamente

Evaluación de la Capacidad Software Capability Método de evaluación

del Software Evaluation (SCE) creado por el SEI para
evaluar la capacidad de
procesos de una compañ
mediante un equipo de
evaluadores externos (se
usa habitualmente para
seleccionar o supervisar
subcontratistas

Evaluación del Proceso de CBA-IPI Método de evaluación

Software Basada en el CMM creado por el SEI para
para Mejoramiento Interno evaluar la capacidad de
del Proceso (CBA-IPI) procesos de una
organización mediante u
equipo de evaluadores
internos dirigidos por un
asesor Líder CBA-IPI
debidamente autorizado
el SEI

-G-

Traducción en Castellano Término CMM en Inglés Significado

Garantía de Calidad del Software Quality Assurance

Software (SQA)

Gestión Cuantitativa del Quantitative Process

Proceso Management

Gestión de Cambios de Technology Change

Tecnología
Gestión de la Configuración
Gestión de Requerimientos
Gestión de riesgos
Gestión de Software
Integrado
Gestión del Cambio del
Proceso
Gestión del Subcontrato de
Software
Grupo de Gestión de la
Configuración del Software
Grupo de Ingeniería de
Software
Grupo de Proceso de
Ingeniería de Software
-I-
Traducción en Castellano
Implantación
Implementación
Management
Configuration management
Requirements Management
Risk management
Integrated Software
Management
Process Change
Management
Software Subcontract
Management
Software Configuration
Management Group
Software Engineering Group Es el equipo de
profesionales y gestionar
que posee la competenci
experiencia necesaria pa
crear o mantener produc
de software. Comprende
analistas, arquitectos,
programadores, personal
pruebas, etc.
Software Engineering Grupo altamente calificad
Process Group (SEPG) responsable por introduc
gestionar y dirigir el
proyecto de mejoramient
de procesos en la
organización
Término CMM en Inglés Significado
Implementation Adopción y utilización de
una práctica de ingenierí
de software en los
proyectos u organización
INICIAR INITIATING Etapa del ciclo IDEAL en
que se establecen los
fundamentos básicos par
garantizar que la iniciativ
de mejoramiento de
procesos.

Institucionalización Institutionalization El uso generalizado de un

proceso a lo largo de los
proyectos. Comprende la
documentación de dicho
proceso, el entrenamient
la medición de su eficacia
su evolución
(mantenimiento)

-L-

Traducción en Castellano Término CMM en Inglés Significado

Líder de evaluación Authorized Lead Assessor Un CBA-IPI Lead Assessor

autorizado debidamente calificado p
el SEI para dirigir al equip
que realizará la evaluació
de procesos

-M-

Traducción en Castellano Término CMM en Inglés Significado

Mantenimiento Maintenance Proceso de corregir

problemas y agregar
nuevas capacidades a un
programa de software
después de su entrega a
usuarios

Medición Measurement Valor que indica el

rendimiento de un proces

Medición y Análisis Measurement and Analysis Describen la necesidad d

medir el proceso y analiz
las mediciones resultante
Mejoramiento Improvement Evolución del proceso pa
hacerlo más eficiente par
satisfacer las necesidade
de la empresa y los
individuos que lo utilizan

Mejoramiento Interno del Internal Process Proyecto emprendido por

Proceso Improvement organización para
incorporar nuevos proces
o hacer más eficaces los
existentes, a objeto de
aumentar su capacidad
para producir software

Miembro del equipo de Assessment team member Personal experimentado

evaluación la organización,
debidamente entrenado,
que realiza la evaluación
los procesos bajo la
dirección de un asesor líd
CBA-IPI

Modelo de Madurez de Capability Maturity Model Conjunto de prácticas de

Capacidades (CMM) ingeniería de software
recomendadas por el SEI
CMU en la versión 1.1 de
SW-CMM

-N-

Traducción en Castellano Término CMM en Inglés Significado

Nivel de madurez Maturity level

Nivel de Optimización Optimizing Level

Nivel Repetible Repeatable Level

Nivel Definide Defined Level

Nivel Inicial o Caótico Initial or Ad-hoc Level

Nivel Gestionado Managed Level

-P-

Traducción en Castellano Término CMM en Inglés Significado

Patrocinador Sponsor Ejecutivos de la gerencia

superior que apadrinan la
iniciativa de mejoramien
(o la evaluación CBA-IPI)
que tienen la capacidad d
proveer los recursos
necesarios para su
ejecución

Plan de Acción Action Plan Es el plan que identifica l

actividades del proyecto
mejoramiento de proceso
Identifica recursos,
entrenamiento, calendar
riesgos, etc.

Plan de Desarrollo del Software Development Plan

Proyecto de Software

Plan de mejoramiento del Software Process

proceso de software Improvement Plan

Planeamiento del Proyecto Software Project Planning

de Software

Prácticas Clave Key Practices

Proceso bien definido Well-defined process

Producto de trabajo de Software work product

software

Programa de Capacitación Training Program

-R-

Traducción en Castellano Término CMM en Inglés Significado

Requisito, Requerimiento Requirement

Requisitos del sistema System requirements

asignados al software allocated to software

Revisión de Pares Peer Review

Riesgo Risk

-S-

Traducción en Castellano Término CMM en Inglés Significado

Seguimiento y Supervisión Software Project Tracking

del Proyecto de Software and Oversight

Qué es el ISO   
9000?
La serie ISO 9000 es un conjunto de estándares internacionales 
para gestión de la calidad desarrollada por la International 
Organization for Standardization (ISO), basada en Ginebra, 
Suiza. 

Establece las requerimientos básicos de un sistema de calidad 
que garantice productos de calidad consistente. Parte del 
supuesto que el producto bajo desarrollo es el resultado de un 
contrato entre un cliente y un proveedor, quien está obligado 
a que su sistema de calidad sea compatible con la norma ISO 
9000.

La norma requiere que el proveedor asegure a su cliente que 
mantiene un sistema de calidad efectivo, que asegure que los 
productos van a ser entregados de acuerdo a las 
especificaciones y a un criterio de calidad. Esta garantía se 
confirma mediante un registro formal y evaluaciones 
periódicas por una entidad externa debidamente acreditado.

El estándar hace énfasis en los procesos de desarrollo y en la 
responsabilidad de la gerencia asociada con dicho proceso. Su 
aplicación a la industria del software se enfoca en establecer, 
documentar y seguir un proceso controlado y auditible, el cual 
es constantemente sometido a verificación, revisado y 
perfeccionado. Debe considerarse más como una guía que 
como un estándar obligatorio.
 I

ISO mantiene un sitio (en idiomas Ingles y Francés) en: 
http://www.iso.ch . Allí hay disponible alguna información 
básica. Cada país tiene una organización oficial que vende los 
¿Dónde  estándares, generalmente traducidos al idioma nacional. Estos 
obtener más  estándares no están disponibles gratuitamente. 
informaciones  Si se desea comparar CMM y ISO 9000, hay un estudio de 
sobre el ISO  comparación (matriz de trazabilidad) publicado por Mark 
9002? Paulk, la cual esta disponible gratuitamente en el sitio del 
Software Engineering Institute, de la Universidad Carnegie 
Mellon. Se puede obtener desde el sitio WEBdel SEI­CMU: 
http://www.sei.cmu.edu 
¿Componentes 
del ISO 9000?
La serie de estándares ISO 9000 está compuesta por las 
siguientes secciones:

• ISO 9001
 • ISO 9002
• ISO 9003

• ISO 9004
Modelo para garantía de calidad en:

• Diseño
¿Qué es el ISO  • Desarrollo
9001? • Producción
• Instalación 

• Servicio
Modelo para garantía de calidad en:

¿Qué es el ISO  • Producción
9002? • Instalación

• Servicio
Modelo para garantía de calidad en:
¿Qué es el ISO 
• Inspección Final
9003?
• Pruebas
Guía de interpretación de los modelos:

¿Qué es el ISO  • ISO 9001
9000? • ISO 9002

• ISO 9003
 Esta guía facilita la aplicación de la norma ISO 9001 en 
organizaciones dedicadas a desarrollar, suministrar y 
mantener software. 

Está basada en la premisa que el proyecto ha adoptado un 
¿La guía de  modelo de ciclo de vida compuesto por fases. Deja amplia 
interpretación  libertad para elegir variantes del CVPS que se ajusten a la 
ISO 9000­3  naturaleza de la organización.
para software?
Su intención es sugerir controles y procesos que garanticen al 
comprador que el software va a cumplir con los 
requerimientos establecidos. Esto se logra previniendo las 
faltas de conformidad a los procedimientos de calidad a lo 
largo del Ciclo de Vida del producto de software.

Consiste en 22 cláusulas que no corresponden necesariamente 
con los 20 elementos de ISO 9001, las cuales están agrupadas 
en tres secciones:

• Marco: agrupa a las actividades generales 
¿En qué  que no están relacionadas con un proyecto 
consiste la  específico o con una fase en particular
norma ISO  • Ciclo de vida: agrupa a la actividades 
9000? dependientes de una fase de desarrollo o de un 
proyecto en particular

• Actividades de apoyo: consiste de las 
actividades auxiliares que se llevan a cabo a lo 
largo del proyecto
Los procesos  La guía proporciona criterios para asegurar la conformidad al 
mínimos de  ISO 9001 de los siguientes aspectos del proceso de desarrollo:
software 
• Política de calidad
cubiertos por  • Gestión de la Calidad
ISO 9000 • Manual de Calidad
• Procesos documentados y procedimientos 
• Plan de desarrollo de proyectos
• Plan de Configuración
• Plan de Pruebas
• Plan de Servicio
• Archivos de Calidad
• Archivos de entrenamiento
• Sistema de auditorías de calidad interna
• Sistema de control de bibliotecas de 
software
 4.1 Responsabilidad de la gerencia

4.2. Sistema de calidad

4.3. Revisión de contratos

4.4. Control de diseño

4.5. Control de documentos

4.6. Adquisición

4.7. Producto suministrado al comprador

4.8. Identificación y trazabilidad del producto

4.9. Control de proceso

Los 20  4.10. Inspección y testing
elementos del 
ISO 9001 4.11. Equipo de inspección, medición y test

4.12. Estado de inspección y test

4.13. Control de productos no conformantes

4.14. Acciones correctivas

4.15. Manejo, almacenamiento, empaque y entrega

4.16. Archivos de calidad

4.17. Auditorías internas de calidad

4.18. Entrenamiento

4.19. Servicio

4.20. Técnicas estadísticas
 No está enfocado directamente a ninguno de los siguientes 
aspectos:

prácticas de gestión
¿Qué cosas no 
estilos de gestión
cubre el ISO 
9001? producto final
satisfacción del cliente
comparación con la competencia

El Modelo de Madurez de Capacidades (conocido en inglés como

"Capability Maturity Model" o por su sigla CMM) es un modelo de prácticas
fundamentales que deben ser implementadas por toda organización
interesada en desarrollar y mejorar la calidad de sus productos y su
productividad. Este modelo está basado en conceptos de calidad total y de
mejoramiento continuo; ha sido elaborado por el Software Engineering
Institute (SEI) de la Universidad Carnegie Mellon y ha sido ampliamente
aceptado por la comunidad de ingeniería de software. Rápidamente se ha
convertido en el estándar de facto en los Estados Unidos de América, y
también a nivel internacional, para evaluar la madurez de procesos que
tienen las organizaciones que producen software. Este modelo se puede
utilizar no solamente como un manual de prácticas recomendables, sino
Visión general: que además como referencia para llevar a cabo auditorías y evaluaciones
internas en las organizaciones que desarrollan y mantienen software.

El SEI ha desarrollado algunos métodos de evaluación basados en este

modelo. Uno de estos métodos es la evaluación basada en CMM para el
mejoramiento interno de procesos, generalmente conocido como CBA IPI
("CMM -Based Appraisal for Internal Process Improvement"); aunque su
principal objetivo es permitir a la empresa la determinación de sus
fortalezas y necesidades de mejoramiento, también permite revisar las
prácticas de los proveedores externos, a objeto de que puedan derivar un
plan de mejoramiento adecuado a su organización.

Referencias
oficiales
El modelo de madurez se encuentra descrito en los documentos
siguientes, cuya versión electrónica (en idioma Inglés) se encuentra
disponible en el sitio WEB del SEI-Carnegie Mellon University.

• Capability Maturity Model, versión 1.1 (SEI/CMU-

93-TR24)
• CMM Practices, versión 1.1 (SEI/CMU-93-TR25)

• Overview of the Capability Maturity Model for

software, by Mark C. Paulk, Bill Curtis, Mary Beth Chrissis,
 and Charles V. Weber, IEEE Software, Vol. 10, No. 4, July
1993, pp. 18-27. (está disponible en
http://www.sei.cmu.edu/technology/cmm/cmm.articles.html
)

El Modelo de Madurez de Capacidades define el nivel de madurez como la

Niveles de capacidad de los procesos de ingeniería de software y de administración
madurez de proyectos usados en una organización de desarrollo de software.
identificados
por el CMM El CMM identifica los niveles de madurez de procesos siguientes:

Los niveles de madures de proceso identificados en la sección anterior

constituyen la estructura de más alto nivel del CMM. Deben ser
interpretados como estadios evolutivos, los cuales se sustentan en la
implementación de los niveles más bajos.

Estructura del Con excepción del Nivel 1, cada uno de estos Niveles de Madurez está
Modelo de compuesto por un cierto número de Areas Claves de Proceso, conocidas
a través de la documentación del CMM por su sigla inglesa: KPA. Cada
Madurez de
KPA identifica una agrupación de actividades y prácticas relacionadas, las
Capacidades cuales cuando son realizadas en forma colectiva permiten lograr 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 Area Clave de Proceso
están organizadas en 5 Características Comunes, las cuales constituyen
atributos que indican si la implementatción y la institucionalización de un
proceso clave es efectivo, repetible y duradero.

Nivel inicial o
nivel de
inmadurez El nivel 1 o inicial es el estado primario en la evolución de las
organizaciones que desarrollan software.

Una definición amplia es que en este nivel se encuentran todas las

empresas que no han logrado implementar las
prácticas básicas de gestión de proyectos e
ingeniería de software definidas a partir del nivel
2 o superiores. Una empresa está en el nivel
caótico cuando sus gerentes y personal afirmen
que los proyectos no se pueden planear, que los
requerimientos no se pueden tener bajo control,
que no esté siempre en condiciones de controlar
las versiones de producto, donde la calidad sea
percibida como una burocracia innecesaria,
cuando se acepte que los procesos son una cosa
personal, cuando no se pueda verificar ni validar
el producto, y sobre todo, cuando sus gerentes y
 personal vivan bajo condiciones de stress y frustración permanentes.

En este tipo de empresas, el software es virtualmente producto del arte

más que de la ingeniería. Cada "artista" crea su propio proceso personal,
el cual es parte de su sello personal. La gerencia ocupa una parte
significativa de su tiempo en paliar problemas y enfrentar clientes
insatisfechos. Ante una situación de crisis permanente, se les hace difícil
destinar recursos para definir o documentar procesos, lo que lleva a un
círculo sin salida.

Cuando el proyecto se termina, la inversión hecha en desarrollar el

proceso es raramente reutilizada en nuevos proyectos. Los
desarrolladores de software generalmente tienen que trabajar largas horas
y paliar problemas en forma cotidiana, lo cual les disminuye su creatividad
Heroismo, caos y productividad netas. El éxito descansa en los hombros de estos héroes,
y emergencia tal como en una película de acción americana. Su nivel de frustración es
elevado y es muy frecuente que, como cualquier "diva", decidan explorar
permanente caminos en otras empresas con menor nivel de
stress. El proceso, que no está documentado ni
a sido compartido, se va con ellos, dentro de
sus cerebros. Los reemplazantes heredan
problemas y dificultades, pero son raramente
capaces de recuperar los procesos de
desarrollo. Esto obliga a reinventar la rueda, a
un alto costo y retrasando los proyectos. He
conocido un par de empresas que han llegado
a la conclusión que es demasiado caro o difícil
tratar de adivinar lo que el empleado anterior
hizo, que les sale más a cuenta echar a la
basura el desarrollo anterior y empezar todo de nuevo. En casos extremos
hay que simplemente terminar el producto para no seguir perdiendo dinero
o prestigio frente a los clientes.

En los orígenes de la industria de software el caos predominó y las

empresas que sobrevivieron la selección natural llegaron al mercado de
Futuro probable nuestros días. La mayoría se extinguió en la gloria del triunfo efímero.
Muchos de los actores actuales están predestinados a desaparecer en un
futuro próximo. A pesar del talento de su personal y el despliegue de
tecnología que puedan sustentar, derrochan su éxito debido a la debilidad
de sus procesos de desarrollo.

El proyecto
planificado
El nivel 2 o Repetible hace posible la implementación de prácticas
mínimas de administración de proyecto, de control de requerimientos,
versiones de producto y de proyectos realizados por subcontratistas. El
grupo o equipo humano que realizó el proyecto puede aprovechar su
experiencia e inversión en procesos para aplicarla en un nuevo proyecto.

Este nivel no garantiza que todos los proyectos dentro de la empresa

estén necesariamente al mismo nivel de madurez. Algunos pueden estar
todavía en el nivel inicial. He visto algunos casos en la práctica y en todos
ellos estos proyectos fueron ineficientes con respecto a los de mayor
madurez, malgastando el éxito de estos últimos. Eventualmente algunos
invertieron los esfuerzos necesarios para ponerse a tono, otros
 simplemente fueron cerrados con un elevado costo de frustración y
descalabro de carreras profesionales.

El mayor beneficio obtenido de la

implementación del nivel 2 por la
empresa en la cual me desempeño
actualmente, es la planificación realista
de los proyectos. Antes los cronogramas
de proyecto expresaban más los deseos
de la gerencia que la realidad. Este
Beneficios de principio (el mismo en la cual se basa la
implantar el magia) conducía una situación de buscar
culpables y generar excusas,
Nivel 2 del CMM produciendo al mismo tiempo frustración
y desconfianza entre clientes y
empleados. Actualmente los
cronogramas son cada día más
confiables, y mejora a medida que se acumula más información en las
bases de datos de los proyectos pasados. El uso generalizado de métodos
de estimación permite al personal del proyecto de justificar plazos y
recursos. Aún el "olfato profesional" y la experiencia personal juegan un
papel importante en la generación de planes de proyecto, pero ahora son
decisiones informadas en vez de simples adivinanzas como en el pasado.

Este nivel todavía permite la proliferación y definición insuficiente de los

procesos de ingeniería de software. Los proyectos comparten
principalmente sus experiencias en materia de administración de
Los pasos proyectos, pero sus métodos técnicos pueden diferir. Aún existe
siguientes incomunicación entre proyectos, grupos y entre personal y gerencia.

Este nivel identifica prácticas de sentido común que son aplicables en todo
tipo de organizaciones de desarrollo de software, independientemente de
su rubro, tamaño o ambiente de desarrollo. La ausencia de cualquiera de
sus prácticas simplemente pone en peligro el éxito de la empresa.

Las 6 prácticas
de proceso
clave del Nivel 2

El proceso
generalizado en
todos los La empresa ha definido un conjunto de procesos,
metodologías y herramientas comunes a todos
 los proyectos iniciados por la corporación. El proceso común está
suficientemente documentado en una biblioteca accesible a todo los
desarrolladores. Todo el personal ha recibido el entrenamiento necesario
proyectos para entender el proceso estándar. Existen pautas y criterios definidos
para adaptar dicho proceso a las necesidades y características propias de
cada proyecto. El nivel de definición es detallado y completo. La
dependencia (o el riesgo de depender) en individuos irreemplazables es
baja.

La base de datos que reúne estadísticas

de los proyectos pasados y en curso,
permite planificar y comparar el
rendimiento. Existen mecanismos de
comunicación entre proyectos y
departamentos, lo que garantiza una
visión común del producto y una rápida
acción para enfrentar los problemas. He
conocido unas pocas empresas a este
Beneficios de nivel y la cosa que más me resaltó fue la
implantar el satisfacción del personal. En empresas
Nivel 3 del CMM de nivel 1 habitualmente se escuchan
quejas y acusaciones. A nivel 3 los
empleados tienen una alta valoración de
los procesos y entienden claramente la
manera en que afectan su desempeño habitual. Los gerentes pueden
realizar sus verdadera función, administrar.

El hecho de realizar revisiones tempranas en forma regular mejora

visiblemente la calidad de los productos y minimiza las reiteraciones
innecesarias. Curiosamente muchas organizaciones de nivel 1 realizan
revisiones de pares, pero lo hacen de manera inconsistente y al primer
signo de pánico las suspenden.

Los pasos El nivel 3 ya es un estado avanzado y es percibido por algunos gerentes

siguientes como un lujo. Sin embargo, lo recomiendo sin embargos. Si no todas, al
menos unas cuantas de sus áreas claves de procesos deben ser
implementadas.

Las 7 prácticas
de proceso
clave del Nivel 3

La calidad
 En este nivel la corporación mide la calidad del producto y del proceso de
planificada y software. Ambos, producto y proceso, son seguidos en forma cuantitativa
y se controlan mediante métricas detalladas. La capacidad de rendimiento
confiable del proceso es previsible. Las mediciones permiten detectar cuando las
variaciones del rendimiento se salen de los rangos aceptables, de manera
de poder tomar medidas correctivas para asegurar la calidad.

La empresa es capaz de proponerse metas cuantitativas para la calidad

de los producto y de los procesos de software. Es posible medir la
productividad y calidad de los procesos de software a través de todo el
proyecto.

Los proyectos pueden controlar la variación del rendimiento de sus

productos y procesos para
mantenerla dentro de fronteras
cuantitativas aceptables. Es
posible discriminar las
Beneficios de variaciones significativas en el
implantar el rendimiento del proceso de la
Nivel 4 del CMM variación (ruido) al azar,
particularmente dentro de líneas
de productos establecidas.

Es necesario aclarar que el

hecho de contar con un sistema de métricas de software no significa que
se esté en el nivel 4. He conocido muchas empresas de nivel 1 que miden
cuidadosamente el número de defectos detectados durante las pruebas o
tests (no es casualidad que les interese tanto!). Es una virtual señal de
alarma que les dice cuán graves son sus problemas, pero la inmadurez de
sus procesos no les permite hacer nada efectivo, excepto tal vez abortar el
producto para evitar un daño mayor que puede resultar de distribuirlo a los
clientes.

Los pasos Son muy raras las empresas que han decido implementar este nivel. No
son muchos especialistas de procesos que realmente tengan experiencia
siguientes
práctica, o incluso que entiendan bien las áreas claves de proceso del
nivel 4. Son solamente 2 prácticas, pero imposibles de alcanzar si no se
ha implemnetado firmemente los 2 niveles de madures anteriores.

Las 2 prácticas
de proceso
clave del Nivel 4

La calidad
planificada y
confiable En el Nivel Optimizado, la característica principal es el mejoramiento
continuo del proceso, en base a la realimentación cuantitativa y al ensayo
 de ideas y tecnologías innovadoras.

La organización entera se aboca al

mejoramiento continuo del proceso. La
corporación cuenta con los medios para
identificar las debilidades y reforzar en
forma proactiva el proceso, con objeto
de prevenir la ocurrencia de defectos.
Beneficios de Los datos relativos a la eficacia del
proceso de software se usan para
implantar el
analizar el costo y el beneficio de usar
Nivel 5 del CMM nuevas tecnologías y de implementar
cambios al proceso de software.

Los proyectos de software analizan los

defectos para determinar sus causas.
Los proceso de software se evalúan para
prevenir que los defectos conocidos
vuelvan a ocurrir, asimismo las lecciones
aprendidas son difundidas a otros proyectos.

No existen más de 10 empresas en el mundo que estén a este nivel (no

Los pasos hay ninguna en países hispano-hablantes). Y las pocas que lo han logrado
no divulgan sus secretos para mantener su ventaja competitiva. Este nivel
siguientes
es un estado ideal, una especie de Paraíso o Nirvana, que probablemente
nunca será alcanzado por la mayoría de las empresas productoras de
software. Personalmente creo que es una hermosa utopía, pero
inalcanzable en el mundo normal.

Las 3 prácticas
de proceso
clave del Nivel 5

Cinco
características
comunes: Las prácticas que deben ser realizadas por cada Area Clave de Proceso
están organizadas en 5 Características Comunes, las cuales constituyen
atributos que indican si la implementatción y la institucionalización de un
proceso clave es efectivo, repetible y duradero.

Las prácticas identificadas en la característica común de las Actividades

Realizadas describen qué se debe implementar para establecer una
capacidad de proceso. El resto de las otras prácticas, tomadas en
conjunto, forman la base mediante la cual una organización puede
 institucionalizar las prácticas descritas en la característica común de las
Actividades Realizadas.

1. El
El compromiso para realización describe las acciones que la organización
compromiso
debe tomar para asegurar que el proceso se establezca y sea
para realización permanente. Normalmente abarcan el establecimiento de políticas y
liderazgo a nivel de la organización. .
La capacidad de realización describe las condiciones previas que debe
existir en el proyecto o la organización para poder aplicar el proceso de
2. La capacidad
software en forma efectiva. Normalmente enfocan los recursos, las
de realización estructuras de la organización, el entrenamiento y las condiciones previas
que deben existir.

3. Las Las actividades realizadas describen los papeles y los procedimientos

actividades necesarios para implementar un área clave de proceso. Normalmente
realizadas abarcan el establecimiento de planes y procedimientos, la ejecución del
trabajo, el seguimiento del mismo, el control de las salidas del proceso, y
las acciones correctivas que deben tomarse según sea necesario.

4. Las
Las Mediciones y Análisis describen la necesidad de medir el proceso y
Mediciones y
analizar las mediciones resultantes. Normalmente incluye ejemplos de las
análisis mediciones que se podrían tomar para determinar la estado y la eficacia
de las actividades realizadas.

5. La
Verificación de La Verificación de la implementación describe los pasos que se deben
seguir para asegurar que las actividades se llevan a cabo de acuerdo con
la el proceso establecido. Típicamente abarca las revisiones y las auditorías
implementación efectuadas por la alta gerencia, los jefes de proyecto y el grupo encargado
dela garantía de calidad de software.

Es fundamentalmente personal, no está

documentado, es difícil compartirlo con otros
Características del miembros del equipo, no es fácil reproducirlo
proceso inmaduro: en nuevos proyectos, no hay entrenamiento,
no todo el mundo lo conoce, no se mide, se
aplica a veces solamente, es percibido como
poco eficiente, es interpretado de manera
distinta, etc.
 Un proceso puede considerarse maduro si cumple
con los siguientes criterios:

El proceso es claro, sistemático y suficientemente detallado. Además existe

Está definido acuerdo entre el personal, la gerencia y los proyectos respecto al proceso
que se va a utilizar.
Esta escrito en un procedimiento publicado, aprobado y fácilmente
Esta documentado accesible. Una de las mejores maneras es a través de una Intranet para
apoyar los proyectos de desarrollo (ver página detallada)
El personal ha sido Los ingenieros de software y la gerencia han recibido cursos y
entrenado en el entrenamiento en cada proceso que aplica a su trabajo
proceso
El proceso definido debe ser usado en las tareas habituales llevadas a cabo
Es practicado por los proyectos. El entrenamiento y la adaptación del proceso a la realidad
de la empresa debieran garantizar su aplicación en la vida real
La gerencia no sólo debe firmar y promover los procesos definidos, sino que
Es apoyado además debe asignar responsabilidad al personal y al los jefes de proyecto
por su cumplimiento
El proceso es revisado regularmente, para asegurarse que está adaptado
Es mantenido para satisfacer las necesidades reales de los proyectos
Los cambios y puestas al día del proceso son revisados, aprobados y
Está controlado comunicados oportunamente a todos los usuarios
La gerencia mantiene mecanismos para asegurarse que todos los proyectos
Se verifica siguen el proceso vigente
Se asegura que el proceso mantiene concordancia con los requerimientos y
Se valida estándares aplicables
La utilización, los beneficios y el rendimiento resultante del proceso se
Se mide miden regularmente
Existen mecanismos y apoyo de la gerencia para revisar e introducir
Puede mejorarse cambios en el proceso, de manera de mejorar su eficacia e incorporar
nuevas metodologías

Qué es
DSDM?

06.06.2006
DSDM es el acrónimo que da nombre a un modelo de procesos para el
desarrollo de sistemas de software, desarrollado y concebido por el
denominado DSDM Consortium, que se fundó en Inglaterra en 1994, y que
actualmente tiene presencia en Inglaterra, EE.UU. Benelux, Dinamarca,
Francia y Suiza; y con interés y contactos para futuras representaciones en
Australia, India y China [...]

Es un modelo que estuvo representado en la firma del Manifiesto Ágil. Arie van Bennekum, firmante
del manifiesto, era miembro del consorcio en Benelux, consultor y formador de DSDM.
En 2001, año del Manifiesto Ágil, DSDM publicó la versión 4.1 de su modelo, y se consideró una
metodología ágil; y aunque mantuvo las siglas, cambió la denominación original (Dynamis Systems
Development Method) por Framework for Business Centred Development.

El modelo es propiedad del DSDM Consortium y solo sus miembros pueden emplearlo con fines
comerciales.

Origen

Tomando como fuente las bases teóricas y las experiencias de RAD (Rapad Application Development)
el consorcio se fundó en enero de 1994 con la finalidad de desarrollar un modelo de desarrollo
independiente de herramientas y que fuera de dominio público.
Ed Holt, presidente del consorcio en sus dos primeros años, afirmó que el uso de herramientas RAD
estaba necesitando un marco de procesos.
La primera versión del modelo se publicó a principios de 1995, junto con un programa de adopción
temprana para obtener retro-información de las primeras organizaciones que lo adoptaran.
Con la información y experiencia que el consorcio iba obteniendo se publicó la versión 2 en
noviembre de 1995, y la 3 en agosto de 1997.

Principios
En su versión actual (4.2) el marco de procesos DSDM se basa en 9 principios.

• La implicación activa de los usuarios es imprescindible.

• Los miembros de los equipos de desarrollo DSDM deben tener la autonomía y potestad
necesarias para tomar decisiones.
• Entrega frecuente de incrementos operativos del producto.
• El principal criterio de prioridad, desarrollo y validación de las entregas incrementales es el
objetivos y la salud del negocio.
• El desarrollo iterativo o incremental hace posible obtener la solución más adecuada a las
necesidades del negocio.
• Todos los cambios realizados en el desarrollo son reversibles.
• Los requisitos se establecen a un nivel general
• Las pruebas forman parte del ciclo de desarrollo
• Es imprescindible trabajar con espíritu de colaboración con todos los agentes implicados en
el sistema que se desarrolla.

Procesos del ciclo de desarrollo DSDM

El ciclo de desarrollo de DSDM está compuesto de 5 fases, precedidas de un pre-proyecto y un post-

proyecto.

1. Pre-proyecto
2. Estudio de viabilidad
3. Estudio de negocio
4. Iteración de modelado funcional
5. Iteración de diseño y desarrollo
6. Implementación
7. Post-desarrollo
Los cinco procesos centrales se suelen representar con el siguiente gráfico, familiarmente denominado "de las 3
prizzas y el queso".

Es frecuente que DSDM se implante en combinación con Exteme Programming o de Prince2

¿Requisitos cerrados, o
evolutivos?

Valoración del artículo: /1

Valorar
Malo Bueno

03.10.2006

“Para que un esfuerzo de desarrollo de software tenga éxito, es esencial

comprender perfectamente los requisitos del software. Independientemente
de lo bien diseñado o codificado que esté un programa, si se ha analizado y
especificado pobremente, decepcionará al usuario y desprestigiará al que lo
ha desarrollado”.

Roger S. Pressman. Ingeniería del Software. Mc Graw Hill 1995.

Parece lógico suponer que antes de empezar a construir algo, lo mejor es conocer con detalle qué
es lo que vamos a hacer.

Una constructora, por ejemplo, podría levantar el edificio que espera su cliente, de forma evolutiva
e incremental, a través de ciclos sucesivos de: “construcción – validación con el cliente – demolición
de lo erróneo”. Pero contar con un proyecto detallado antes de empezar la construcción es un
modelo de desarrollo mucho más adecuado.

En el desarrollo de software, el razonamiento que implica esta comparación es un punto de

discordia importante entre defensores de modelos procesos, y de modelos ágiles.

Para los modelos de procesos (CMMI, ISO15504...) y para el marco de gestión de proyectos predictivo
(PMI, IPMA...) es obvio y axiomático que:

• Para saber el tiempo y el precio que costará el proyecto, hay que tener una planificación
detallada.
• Para elaborar un plan detallado hay que saber con detalle, qué es lo que se va a construir.
• La gestión de proyectos es la profesión que comprende las áreas de conocimiento necesarias
para planificar, gestionar la ejecución del trabajo planificado, detectar y corregir las
desviaciones.

Sin embargo para la gestión de proyectos adaptable o ágil, las fases no son fases, sino actividades
que se desarrollan durante todo el ciclo de vida, a demanda según las circunstancias. El diseño, por
ejemplo no es la fase que se realiza después de los requisitos. El diseño, como el descubrimiento de
los requisitos, o la codificación y pruebas son actividades que se ejecutan según se van necesitando,
a lo largo de iteraciones cortas.
Los requisitos no se conocen de forma detallada al comenzar. La comunicación con el cliente, el
análisis y la interacción con los resultados de cada iteración los irán descubriendo.
Las fechas no son resultado de una planificación, sino restricciones de negocio. La garantía del
resultado no se confía a los procesos sino a la excelencia técnica y a la responsabilidad del equipo.

La exsistencia de estos dos enfoques para la gestión de proyectos ocasiona:

• Discusiones de caracter fundamentalista entre defensores de ambos "bandos".

• Despistes y desaguisados al aplicarlos en las organizaciones y en los proyectos que por
simpatías, corazonadas o asesoramientos poco objetivos adoptan tal cual modelos poco
apropiados.

Algunas cuestiones que ayudan a dar una perspectiva objetiva sobre la utilidad, y ámbito de cada
marco:
El software no resulta comparable a la materia prima de otras ingenierías.
El software no es físico, y los sistemas de soft, a diferencia de los artefactos físicos son muy
maleables. Por eso es tendencioso presuponer una "talla única" de gestión válida para cualquier
sistema y establecer un paralelismo transitivo de métodos que por ser apropiados para la
construcción de edificios o aviones también , también lo son para desarrollar software.

A nadie se le ocurre comenzar la construcción de un edificio sin saber cuál será exactamente el nº
de plantas, o la superficie de éstas; o desarrollar una embarcación básica, e ir ampliando y
modificando sus características, a medida que por el uso las van descubriendo los usuarios.
Sin embargo con el software esto es posible.

La capacidad de fertilización que sobre el concepto inicial del producto da el ver, tocar y jugar con
un prototipo, con un fragmento de la obra, descubre posibilidades valiosas para el producto, que de
otra forma difícilmente podrían haber sido incluidas en una descripción inicial.
La cuestión es: ¿cómo de caro resulta construir poco a poco, realizando "prototipos" que retro-
enriquecen la visión del producto?.
Si puedo:

• Poner en contacto directo a desarrolladores y usuarios.

• Conseguir que formen un equipo excelente y motivado.
• Conseguir que toquen, interactúen y vean partes operativas del producto en fases
tempranas, y enriquezcan el concepto y valor del producto.

Entonces puedo lograr productos con mayor innovación y con un valor superior al que el que habría
conseguido a través de una obtención detallada de requisitos inicial y cerrada.

"Preferimos el software que funciona a la documentación exhaustiva" (agilemanifesto.org)

• La cuestión no es decidir cuál es el mejor modelo para los sistemas de software, sino para
"este" sistema de software, con sus características determinadas:
 • Grado de incertidumbre del escenario tecnológico sobre el que se desarrolla.
• Grado de inestabilidad del entorno de mercado del cliente.
• Nitidez de la visión del producto.
• Nivel de valor que por innovación necesita el cliente.
• Estructura y factores sociales de las organizaciones adquirientes y suministradora.
• etc.

Si de lo que se trata es del programa para la gestión de un producto bancario, archiconocido, del
que se pueden saber extraer y analizar todos sus requisitos al comenzar el proyecto, y para el que el
cliente no espera un valor de innovación, sino eficiencia y predecibilidad de desarrollo; por muy
software que sea, lo más acertado será conducir el proyecto con un modelo de gestión clásico co
predictivo.

Los cuatro principios del

manifiesto ágil

01.06.2006

En marzo de 2001, 17 críticos de los modelos de mejora basados en procesos,

convocados por Kent Beck, que había publicado un par de años antes el libro
"Extreme Programming Explained" en el que exponía una nueva metodología
denominada Extreme Programming, se reunieron en Salt Lake City para
discutir sobre el desarrollo de software.
En la reunión se acuñó el término “Métodos Ágiles” para definir a los que
estaban surgiendo como alternativa a las metodologías formales, (CMM-SW, PMI, SPICE) a las que
consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de
planificaciones detalladas, previas al desarrollo.

Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto
Ágil”, que son los principios sobre los que se basan estos métodos.
Hasta 2005, entre los defensores de los modelos de procesos y los de modelos ágiles han sido frecuentes las
posturas radicales, quizá más ocupadas en descalificar al otro que en estudiar sus métodos y conocerlos para
mejorar los propios.

Manifiesto Ágil

(http://www.agilemanifesto.org)

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a
que lo hagan. Con este trabajo hemos llegado a valorar:

• A los individuos y su interacción, por encima de los procesos y las herramientas.

• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimietno de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda

Firmado por:
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor,
Ken Schwaber, Jeff Sutherland, Dave Thomas.

Valoramos más a los individuos y su interacción que a los procesos y las herramientas.
Este es posiblemente el principio más importante del manifiesto.

Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la
eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados.
Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los
años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha dado a éstos más relevancia
de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que
las realizan.

Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los
equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se
pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es
peligroso cuando los trabajos necesitan creatividad e innovación.

Valoramos más el software que funciona que la documentación exhaustiva.

Poder ver anticipadamente como se comportan las funcionalidades que se esperan sobre prototipos o sobre
partes ya elaboradas del sistema final ofrece un "feedback" muy estimulante y enriquecedor que genera ideas y
posibilidades imposibles de concebir en un primer momento, y dificilmente se podrían incluir al redactar un
documento de requisitos detallados antes de comenzar el proyecto.

El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la
transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son
obligatorios, pero se resalta que son menos importantes que los productos que funcional. Menos trascendentales
para aportar valor al producto.

Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la
comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea
posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no
aporta un valor directo al producto.
Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la
interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre
departamentos o entre personas.

Valoramos más la colaboración con el cliente que la negociación contractual.

Las prácticas ágiles están especialmetne indicadas para productos difíciles de definir con detalle en el principio,
o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información
continua durante el desarrollo. También para los casos también en los que los requisitos van a ser muy inestables
por la velocidad del entorno de negocio.

Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a
procesos, sino de haber sido implementado directamente sobre el producto.

Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre
responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo.
Los modelos de contrato por obra no encajan.

Valoramos más la respuesta al cambio que el seguimiento de un plan

Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente al cambio y la
evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y
aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la
adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones
sobre el plan.

Sinopsis de los modelos

CMM y CMMI

01.05.2006

CMMI, y el predecesor CMM, pueden emplearse como:

1.- Guía para mejorar los procesos que intervienen en el desarrollo y mantenimiento del
software.
2.- Criterio para determinar el nivel de madurez de una organización que desarrolla o
mantiene software en base a la capacidad de las áreas de procesos definidas en estos modelos.

Artículo en formato pdf

SW-CMM (CMM for Software)

Historia y evolución
1984 El Congreso del Gobierno Americano aprobó la creación de un organismo de investigación para el
desarrollo de modelos de mejora para los problemas en el desarrollo de los sistemas de software, y evaluar la
capacidad de respuesta y fiabilidad de las compañías que suministran software al Departamento de Defensa.

Creación del SEI (Instituto de Ingeniería del Software), fundado por el Departamento de Defensa Americano y la
Universidad Carnegie Mellon.

1985 SEI empieza a trabajar en un marco de madurez de procesos que permita evaluar a las empresas
productoras de software.
La investigación evoluciona hacia el “Modelo de Madurez de las Capacidades (CMM)”.

1991 En agosto SEI publica la versión 1.0 del Modelo de Madurez de las Capacidades para el Software (SW-CMM,
Capability Maturity Model for Software).

1993 SEI publica la versión 1.1 de SW-CMM

1997 Publicación de la versión 1.2

2000 SW-CMM fue integrado y relevado por el nuevo modelo CMMI.

Principios y conceptos
El marco de madurez de los procesos parte de la premisa de gestión:

La calidad de un producto o de un sistema es en su mayor parte consecuencia de la calidad de los procesos

empleados en su desarrollo y mantenimiento.

Madurez
Atributo de las organizaciones que desarrollan o mantienen los sistemas de software.
En la medida que éstas llevan a cabo su trabajo siguiendo procesos, y en la que éstos se encuentran
homogéneamente implantados, definidos con mayor o menor rigor; conocidos y ejecutados por todos los equipos
de la empresa; y medidos y mejorados de forma constante, las organizaciones serán más o menos “maduras”.

Modelo escalonado.
SW-CMM es un modelo escalonado sobre el concepto de madurez, que define 5 niveles o escalones para calificar
la madurez de una organización.

Niveles de madurez
El “escalonado” CMM define 5 niveles posibles de madurez para las organizaciones que desarrollan y mantienen
software:

Nivel 1: Inicial
Los resultados de calidad obtenidos son consecuencia de las personas y de las herramientas que emplean. No de
los procesos, porque o no los hay o no se emplean.

Nivel 2: Repetible
.Se considera un nivel 2 de madurez cuando se llevan a cabo prácticas básicas de gestión de proyectos, de
gestión de requisitos, control de versiones y de los trabajos realizados por subcontratistas. Los equipos de los
proyectos pueden aprovechar las prácticas realizadas para aplicarlas en nuevos proyectos.

Nivel 3: Definido
Los procesos comunes para desarrollo y mantenimiento del software están documentados de manera suficiente
en una biblioteca accesible a los equipos de desarrollo. Las personas han recibido la formación necesaria para
comprender los procesos.

Nivel 4: Gestionado
La organización mide la calidad del producto y del proceso de forma cuantitativa en base a métricas
establecidas.
La capacidad de los procesos empleados es previsible, y el sistema de medición permite detectar si las
variaciones de capacidad exceden los rangos aceptables para adoptar medidas correctivas.

Nivel 5: Optimizado
La mejora continua de los procesos afecta a toda la organización, que cuenta con medios para identificar las
debilidades y reforzar la prevención de defectos. Se analizan de forma sistemática datos relativos a la eficacia de
los procesos de software para analizar el coste y el beneficio de las adaptaciones y las mejoras.

Se analizan los defectos de los proyectos para determinar las causas, y su mapeado sobre los procesos.
Estructura del modelo SW-CMM

Áreas clave de proceso

Nivel 2

• <!--[if !supportLists]-->Gestión de Requisitos

• <!--[if !supportLists]--> <!--[endif]-->Planificación del proyecto de software
• <!--[if !supportLists]--> <!--[endif]-->Seguimiento y Supervisión del proyecto
• <!--[if !supportLists]--> <!--[endif]-->Gestión de subcontratos de software
• <!--[if !supportLists]--><!--[endif]-->Garantía de calidad de software
• <!--[if !supportLists]--> <!--[endif]-->Gestión de la configuración del software

Nivel 3

• <!--[if !supportLists]--> <!--[endif]-->Enfoque en el proceso de la organización

 • <!--[if !supportLists]--> <!--[endif]-->Definición del proceso de la organización
• <!--[if !supportLists]--> <!--[endif]-->Programa de formación
• <!--[if !supportLists]--> <!--[endif]-->Gestión integrada del software
• <!--[if !supportLists]--> <!--[endif]-->Ingeniería de software del producto
• <!--[if !supportLists]--> <!--[endif]-->Coordinación entre grupos
• <!--[if !supportLists]--> <!--[endif]-->Revisión de pares

Nivel 4

• <!--[if !supportLists]--> <!--[endif]-->Gestión cuantitativa del proceso

• <!--[if !supportLists]--> <!--[endif]-->Gestión de la calidad del software

Nivel 5

• <!--[if !supportLists]--> <!--[endif]-->Prevención de defectos

• <!--[if !supportLists]--> <!--[endif]-->Gestión del cambio de tecnología
• <!--[if !supportLists]--> <!--[endif]-->Gestión del cambio del proceso

Evolución de modelos CMM

Tras la publicación del modelo CMM for Software, se comenzaron a desarrollar modelos para mejorar la madurez
de las capacidades en otras áreas y ámbitos:

• <!--[if !supportLists]--> <!--[endif]-->P-CMM: People CMM.

• <!--[if !supportLists]--> <!--[endif]-->SA-CMM: Software Acquisition CMM.
• <!--[if !supportLists]--> <!--[endif]-->SSE-CMM: Security Systems Engineering CMM.
• <!--[if !supportLists]--> <!--[endif]-->T-CMM: Trusted CMM
• <!--[if !supportLists]--> <!--[endif]-->SE-CMM: Systems Engineering CMM.
• <!--[if !supportLists]--> <!--[endif]-->IPD-CMM: Integrated Product Development CMM.

CMMI
A finales de los 90 algunas organizaciones llevaban a cabo planes de calidad que integraban de forma simultánea
varios modelos CMM.
Para facilitar la incorporación de varios CMM’s, SEI desarrolla y publica en 2001 el modelo CMMI que integra:

• CMM-SW
• SE-CMM
• IPD-CMM

Desde entonces estos tres modelos ya no evolucionan de forma separada.

Principios y conceptos
CMMI se asienta en el mismo principio expuesto para CMM:

La calidad de un producto o de un sistema es en su mayor parte consecuencia de la calidad de los procesos

empleados en su desarrollo y mantenimiento.

Madurez
Atributo de las organizaciones que desarrollan o mantienen los sistemas de software.
En la medida que éstas llevan a cabo su trabajo siguiendo procesos, y en la que éstos se encuentran
homogéneamente implantados, definidos con mayor o menor rigor; conocidos y ejecutados por todos los equipos
de la empresa; y medidos y mejorados de forma constante, las organizaciones serán más o menos “maduras”.

Capacidad
Atributo de los procesos. El nivel de capacidad de un proceso indica si sólo se ejecuta, o si también se planifica
se encuentra organizativa y formalmente definido, se mide y se mejora de forma sistemática.

Niveles de capacidad.
Los 6 niveles definidos en CMMI para medir la capacidad de los procesos son:

0.- Incompleto
El proceso no se realiza, o no se consiguen sus objetivos.
1.- Ejecutado
El proceso se ejecuta y se logra su objetivo.
2.- Gestionado.
Además de ejecutarse, el proceso se planifica, se revisa y se evalúa para comprobar que cumple los requisitos.
3.- Definido
Además de ser un proceso “gestionado” se ajusta a la política de procesos que existe en la organización, alineada
con las directivas de la empresa.
4.- Cuantitativamente gestionado.
Además de ser un proceso definido se controla utilizando técnicas cuantitativas.
5.- Optimizado
Además de ser un proceso cuantitativamente gestionado, de forma sistemática se revisa y modifica para
adaptarlo a los objetivos del negocio.

Niveles de madurez.
Son los mismos 5 que los descritos en el modelo SW-CMM, si bien se les han revisado los nombres a los niveles 2 y
4.
Nivel 1: Inicial
Nivel 2: Gestionado
Nivel 3: Definido
Nivel 4: Gestionado cuantitativamente
Nivel 5: Optimizado
Representaciones Continua y Escalonada
Los modelos de calidad que centran su foco en la madurez de la organización, presentan un modelo de mejora y
evaluación “escalonado”.
Los que enfocan las actividades de mejora y evaluación en la capacidad de los diferentes procesos presentan un
modelo “continuo”.

• CMMI nació integrando tres modelos diferentes, con representaciones diferentes:

• <!--[if !supportLists]--> <!--[endif]-->CMM-SW: representación escalonada.
• <!--[if !supportLists]--> <!--[endif]-->SE-CMM: representación continua.
• <!--[if !supportLists]--> <!--[endif]-->IPD-CMM: modelo mixto.

En el equipo de desarrollo de CMMI había defensores de ambos tipos de representaciones. El resultado fue la
publicación del modelo con dos representaciones: continua y escalonada.
Son equivalentes, y cada organización puede optar por adoptar la que se adapte a sus características y
prioridades de mejora.

La visión continua de una organización mostrará la representación de nivel de capacidad de cada una de las áreas
de proceso del modelo.

La visión escalonada definirá a la organización dándole en su conjunto un nivel de madurez del 1 al 5.

Áreas de proceso.
CMMI identifica 25 áreas de procesos (22 en la versión que no integra IPD).

Vistas desde la representación continua del modelo, se agrupan en 4 categorías según su finalidad: Gestión de
proyectos, Ingeniería, Gestión de procesos y Soporte a las otras categorías.
Vistas desde la representación escalonada, se clasifican en los 5 niveles de madurez. Al nivel de madurez 2
pertenecen las áreas de proceso cuyos objetivos debe lograr la organización para alcanzarlo, idem con el 3, 4 y
5.

Área de proceso Cate N.

gorí m
a ad
.
Gestión y procesos en empresas
de software

Valoración del artículo: / 18

Valorar
Malo Bueno

11.12.2005

Como apunta el post Modelos de procesos: no auto-medicarse, el panorama actual de modelos y

prácticas desorienta a empresas y directivos del desarrollo de software

Es frecuente abordar planes para la incorporación de alguno de estos modelos, elegidos más por la
casualidad y la fe, que por el rigor y conocimiento previo de las características de la propia empresa y
de sus proyectos.

Este trabajo expone el marco general de los modelos de procesos y prácticas de nuestra industria: CMMI, ISO 15504, Scrum,
Extreme Programming, DSDM, MSF, RUP, PMI, etc. y una visión ejecutiva que muestra las características y situación de
cada uno sobre un mapa de situación general; junto con consejos sobre la idoneidad de cada modelo.

• Descargar artículo en formato PDF

GESTIÓN Y PROCESOS EN EMPRESAS DE

SOFTWARE
Juan Palacio
jpalacio[arroba]navegapolis.net
Rev. Nov - 2005

SINOPSIS

Las empresas que desarrollan software no pueden ignorar que su negocio es un negocio de software, y que el modelo que
cada una adopte para las actividades de desarrollo y mantenimiento tiene implicaciones relevantes en la eficiencia general
del negocio.

El problema que pueden encontrar quienes deciden implantar métodos más eficientes, es caer en la desorientación ante el
abanico de modelos de calidad, de procesos y de técnicas de trabajo desplegado en la última década; o abrazar al primero
que se presenta en la puerta de la organización como “solución” de eficiencia y calidad

Este artículo dibuja un mapa de situación general como orientación para directores técnicos, respon-sables de
departamentos informáticos y personal directivo de organizaciones de software.

La visión general que ofrece, muestra cómo en su totalidad un entorno de producción es un entorno sistémico, en cuyo diseño
global los componentes tienen que encajar y funcionar armónicamente, alineados con las características, cultura y estrategia
de la organización.

Amenaza u oportunidad

Según como afrontan las organizaciones el desarrollo del software, éste puede comportarse como factor de riesgo o amenaza
para el negocio; o por el contrario como una poderosa oportunidad de negocio.

Todas las empresas quieren producir más rápido, mejor y con menores costes, y sin duda esto es posible porque la naturaleza
del software no es origen de riesgos y problemas, sino una fuente de oportunidades.

Cada vez más directivos están comprendiendo que la forma de gestión del desarrollo de software, puede hacer de la materia
prima de su negocio un material arisco de resultados impredecibles, o una ventaja competitiva.

La evolución hacia entornos de ingeniería del software requiere cambios severos en la organización, así como el
convencimiento, implicación y empuje de la dirección. Pero sobre todo el diseño de un modelo de producción propio que sepa
aprovechar la personalidad de la organización, y responder a las particularidades de su negocio.

El software ha estado generando los mismos problemas en los últimos 40 años, y quien no cambia la forma de hacer las cosas,
sigue tropezando en ellos.

El problema que pueden encontrar quienes deciden implantar métodos más eficientes es caer en la desorientación ante el
abanico de modelos de calidad, de procesos y de técnicas de trabajo desplegado en la última década, o abrazar al primero que
se presenta en la puerta de la organización como “solución” de eficiencia y calidad.

Trabajar sin ningún método es una opción, pero no una metodología

Las organizaciones que desarrollan o mantienen software pueden optar por trabajar "a la buena de Dios", o por seguir una
metodología. Hacerlo a la buena de Dios no es tan raro. Es la primera forma que se empleó para desarrollar programas:

"Aquí tenemos unos ordenadores, aquí unos señores a los que les encanta leer los manuales de programación, y se trata
sencillamente de conseguir que estas máquinas terminen imprimiendo facturas (o haciendo lo que sea)".

En realidad, cuando en la segunda mitad del siglo pasado la industria del hardware puso en la calle máquinas que se podían
programar, poco más se podía hacer; y los pioneros de nuestra profesión, atraídos por el encanto de diseñar y construir
artefactos útiles, y verlos funcionar, fueron los primeros en remangarse frente al teclado y decir a su cliente con una
sonrisa:"en un par de meses esto estará funcionando".

Fueron también los primeros en pasar noches en vela programando, prometiendo una y otra vez que "tan sólo es cuestión de un
par de días más."

Aunque las cinco décadas de vida del software ya han sido suficientes para experimentar los excesos y los errores de la
infancia y la juventud, la resistencia al cambio es el mejor aliado de la inercia, y por eso se produce una cierta
impermeabilidad a la experiencia.

En cualquier caso es una opción: trabajar sin ninguna metodología.

SEI, (Software Engineering Institute) por el rigor de su documentación y la circunspección de su imagen no puede llamar a
esta forma de producir como "a la buena de Dios", y en su lugar afirma que es la forma propia de organizaciones "poco
maduras".

En la escala que de 1 a 5 emplea para determinar el grado de madurez de una organización, y en consecuencia el nivel de
garantía que ofrece en cuanto a calidad, predictibilidad en los resultados y eficiencia en el desarrollo de software, este tipo de
organizaciones se quedan, lógicamente, en el 1.

Que, ¡ojo cuidado! no quiere decir que necesariamente van a producir mal software, de forma ineficiente y con retraso, sino
que las probabilidades de cumplir las tres facetas es baja.

Hay equipos que lo consiguen, pero son pocos. La razón es sencilla, los resultados en estos casos son tan buenos como las
personas que los desarrollan, y lo cierto es que los buenos programadores escasean.
A este modo de producción se le ha venido a llamar "programación heroica", porque todo el peso del resultado descansa sobre
el "saber-hacer" de los programadores.

El éxito o fracaso de las organizaciones que trabajan sin metodologías depende del conocimiento tácito de su personal, pero
teniendo en cuenta que se trata del conocimiento que cada uno traía ya de la calle, o del que adquiere motu proprio, porque
estamos hablando de "ninguna metodología", lo que implica que como mucho los procesos de formación de la empresa llegan
al "ahí tienes manuales y libros, por si hubiera algo que no sabes".

Este es sin duda el modelo con el que empiezan muchas empresas "start-up": un equipo de empren-dedores con talento,
capaces de construir sistemas de software con calidad.

Los resultados serán tan buenos como ellos los sepan hacer. El cumplimiento de agendas dependerá de su capacidad de
previsión y organización. Pero no hay que engañarse; en este caso no se trata de empresas que saben hacer software, sino de
personas que saben hacer software.

Y esta situación dibuja el guión común a todas las pequeñas empresas de desarrollo de soft que surgen de cero, impulsadas tan
sólo por el empuje de sus emprendedores: pueden llegar todo lo lejos que la combinación del talento y de la capacidad de
marketing de sus creadores les permitan.

O sea, en ocasiones acabarán cerrando, y en otras alcanzarán un nivel de estabilidad tan mediocre o tan brillante como dicha
combinación les permita. Y si una vez logrado ese nivel de equilibrio desean proyectar mayor crecimiento a su organización se
enfrentan a un reto importante:

pasar de personas que saben hacer software a empresa que sabe hacer software. Salto que supone que no van a ser ya ellos,
sino su empresa quien deberá producir de forma eficiente y repetible en todos sus proyectos, resultados de calidad. Y esta es
otra aventura en la que muchos fracasan teniendo que regresar a la casilla de salida, o si el "roto" del intento ha sido muy
grave, terminar cerrando, o como mal menor dejándose adquirir por algún competidor más o menos grande del sector.

La teoría de la gestión empresarial recomienda para esta travesía tomar como medio de transporte la gestión por procesos.

Sí, no es nada nuevo, y leerlo a estas alturas puede dar la sensación de estar desayunando con el periódico del día anterior.

Aparte de las excelencias recogidas en el manual del consultor sobre la transversalidad de los procesos, que atravesando a toda
la organización dibuja modelos organizacionales sin rigideces departamentales, y alinea con sus flujogramas a toda la empresa
en el mismo sentido con visión centrada en el cliente, y bla, bla, bla.

Lo cierto es que la gestión por procesos encierra cuatro factores que hacen posible pasar de grupo de emprendedores a
empresa:

• Repetibilidad de resultados. Al conseguir que la calidad del resultado sea consecuencia del proceso, producir aplicando
el mismo proceso garantiza la homogeneidad de los resultados.
• Escalabilidad. Es una consecuencia de la repe-tibilidad. No sólo un equipo consigue resultados homogéneos en todos los
proyectos, sino que los obtienen todos los equipos.
• Mejora continua. Al aplicar meta-procesos que trabajan sobre los propios procesos de producción, midiendo y
analizando los resultados se obtienen los criterios de gestión necesarios para aplicar medidas que mejoran de forma
continua la eficiencia y calidad de los procesos base, y por tanto de los resultados.
• Un know-how propio, consiguiendo finalmente una empresa que sabe hacer, porque su modelo de procesos termina
conteniendo un activo valioso de la organización: la clave para hacer las cosas bien, con eficiencia y de forma
homogénea.•

No sólo son procesos

Los procesos marcan pautas para realizar el trabajo, pero sin las personas y las herramientas (tecnología) necesarias, lo que se
puede producir con ellos es más bien poco.

Las únicas combinaciones válidas para formar sistemas capaces de producir resultados son:

Personas + Producción
tecnología heroica
Personas + Producción
procesos + basada en
tecnología procesos

Figura 1

Un ejemplo que seguro todos hemos realizado alguna ves, y que ilustra las diferencias entre ambos sistemas de producción es
el montaje de un mueble en kit.

Para enfrentarnos a esta tarea tenemos, por un lado a las personas: nosotros. Y por otro la tecnología: el destornillador (manual
o eléctrico), los tornillos, pasadores, la cola de montaje, etc. Y si dejamos el proceso a un lado (el manual con las instrucciones
de cómo proceder) tendremos un sistema perfecto de producción heroica: personas + tecnología; del que cabrá esperar los
resultados propios de estos entornos.

La productividad y la calidad no son homogéneas. Hay quien ensambla la estantería o el mueble, en cuestión de minutos, y
quien necesita toda una tarde.

Algunos obtienen estanterías robustas y perfectas, y otros terminan el montaje con peor fortuna, afirmando que la estantería
está bien montada pero que las piezas venían mal cortadas de fábrica, o que quien diseñó ese mueble era un perfecto inútil, o
que los tornillos son de mala calidad, o quizá sin ni siquiera percatarse de los defectos con los que ha dejado el mueble.

En definitiva esta forma de trabajo produce resultados, y puede resultar más o menos apropiada para realizar hobbys o
bricolajes domésticos, pero para una empresa de montaje de muebles no resultaría viable un sistema de producción que no
pudiera garantizar eficiencia en los costes, y resultados con una calidad homogénea.

Hay dos formas de evitar estos problemas:

• Introducir un tercer elemento en el sistema de producción: los procesos.

• Trabajar sólo con personas y tecnología, pero empleando sólo a los mejores ebanistas, y proporcionándoles las mejores
 herramientas.
•

Como veremos a continuación generalmente la mejor solución no suele consistir en adoptar una u otra opción, sino una mezcla
de ambas, con mayor o menor peso específico en una u otra, en función de las características del negocio.

Al añadir procesos al sistema se consigue que todas las personas ejecuten el trabajo siguiendo las mismas pautas, y que los
parámetros de ejecución y los resultados puedan ser medidos de forma homogénea en toda la organización.

De esta forma se reduce drásticamente la hetero-geneidad de los resultados, tanto en la eficiencia de los tiempos invertidos,
como en la calidad obtenida, que empieza a ser proporcional a la capacidad de los procesos que se hayan diseñado.

Pero no hay que dejarse deslumbrar por los procesos y olvidarse de los otros componentes.

Basar una empresa sobre un sistema de producción de dos elementos: personas y tecnología plantea limitaciones; pero basarlo
en un entorno exclusivo de procesos, o de procesos y tecnología, simplemente no es posible.

La realidad de los procesos es cierta, pero en el triángulo personas - procesos - tecnología cada elemento actúa con un peso
específico, diferente en función del tipo de producción, e incluso de las características de personalidad de cada empresa.

Por eso, llegados a este punto, el ámbito de la teoría generalista se acaba, y cada sector y cada empresa, más que importar una
metodología estándar sacada del manual del perfecto consultor, debe comenzar por el gnosce te ipsum, y a partir de ahí
analizar y descubrir la potencia de cada uno de los tres elementos de la producción para componer el diseño de un sistema de
producción a su medida.

Los gestores o consultores "estándar" no existen; bueno, perdón, sí que existen, pero obtienen los resultados estándar que todos
conocemos.

Relevancia del capital estructural y del capital humano

El capital estructural está formado por los bienes que quedan en la empresa cuando las personas se van a sus casas: patentes,
licencias, cartera de clientes, equipos, maquinaria, vehículos, etc.

El capital humano es el compuesto por el valor que la empresa emplea en su negocio y que resulta inseparable de las personas.

Todas las industrias necesitan ambos tipos de capitales para elaborar los productos o servicios de su negocio, pero la
relevancia con la que cada uno de ellos puede influir en el resultado final es muy diferente de unas empresas a otras.

Es frecuente que para las empresas dedicadas a la fabricación de productos el componente estructural sea más crítico que para
las dedicadas a los servicios, en las que el elemento humano tiene más relevancia.

Pero este no es un principio universal, y dentro de la misma industria o del mismo sector, la estrategia y la táctica de cada
empresa también influyen en los niveles de relevancia que van a tener el capital humano y el estructural.

Veámoslo con un ejemplo, comparando la relevancia de ambos en dos empresas del mismo sector: hostelería.

Por un lado pensemos en un exquisito restaurante de cocina vasca (por ejemplo), y por el otro en un establecimiento de
PhonoPizza (también por ejemplo).

Al margen de consideraciones gastronómicas, ambos negocios tienen perfectamente claros su identidad, personalidad y
segmento; ambos tienen también su propio patrón de atributos de calidad sobre el que medirse.

En el segundo modelo la empresa tiene una serie de procedimientos para garantizar de forma continua la calidad de sus
resultados (calidad y repetibilidad), por lo que éstos dependen mucho menos del conocimiento tácito de sus cocineros, y en su
mayor parte se deben a los procesos y la tecnología empleada.
Los hornos regulan automáticamente el tiempo y la temperatura, los ingredientes se producen también en base a unos
procesos, y se distribuyen de forma masiva a todos los establecimientos en estuches, ambientes frigoríficos y medios de
transporte en base a unos procesos que son los principales responsables de los resultados.

Por esta razón resulta mucho más fácil, o en lenguaje empresarial, menos costoso, reemplazar al personal de cocina de un
establecimiento de PhonoPizza que al de un restaurante de cocina vasca.

Figura 2

Las barras de color azul de la figura 2 representan de forma gráfica el valor, que para una empresa determinada, aporta cada
elemento a su sistema de producción.

Las combinaciones posibles para cada negocio son muchas, y factores como la innovación en la tecnología, en los procesos o
la formación del personal pueden abrir la horquilla de potencial de cada elemento.

La homogeneidad y calidad de los resultados, y la eficiencia del sistema en su conjunto serán consecuencia del equilibrio
logrado.

Por supuesto una franquicia de hamburguesas y comida rápida podría incluir, además de tecnología y procesos eficientes, la
contratación o formación de gourmets de alta cocina.; pero de esta forma su sistema de producción no estaría aprovechando la
naturaleza de su producto como ventaja competitiva.

La obsesión por la excelencia mal entendida, o la desorientación sobre las funciones del propio puesto lleva a muchos gestores
a centrar sus esfuerzos en la incorporación de modelos o técnicas, bien de procesos, bien de recursos humanos o de innovación
tecnológica; o de todos a la vez, por razones como que “es lo último en gestión”, o lo estudiado en el último seminario, o lo
que con tanta vehemencia le ha “vendido” el último pseudo-consultor que visitó su empresa, o lo leído en ese libro de gestión
tan interesante.

Esta es al fin y al cabo, la razón del escepticismo y las críticas que finalmente verterán sobre modelos, métodos o técnicas
contrastadas y eficaces; cuya debilidad no radica en ellas sino en una interpretación incorrecta, o en una implementación en un
grado incorrecto, o sobre sistemas para los que no resultan apropiadas.

Figura 3

Conseguir que el sistema de procesos, tecnología y personas formen una ventaja competitiva frente a la competencia, y no un
reto más del negocio, no es fácil, ni puede importarse con la implantación “prêt-à porter” de un modelo estándar.

Como refleja la figura 3, la clave del éxito radica en conseguir que cada factor pueda aportar el mayor valor hasta el límite de
su mejor relación eficiencia / calidad.

En esta tarea nunca está dicha la última palabra, y la labor de innovación constante en procesos y tecnología puede ir
ampliando los límites de valor a un factor para conseguir un nuevo equilibrio con mejores parámetros de eficiencia y calidad
en el sistema.

Gnosce te ipsum

“No hay mayor inmoralidad que ejercer un oficio que no se conoce”

Napoleón

Lo cierto es que un gestor o un directivo necesita combinar los conocimientos de management con los del propio negocio,
sector e industria en la que se mueve.
Quien se sienta en el puente de mando de una embarcación, por su puesto debe ser un buen “gestor” y contar con las
habilidades y conocimientos para gobernar una nave, pero para realizar la travesía necesitará conocer las características de la
propia nave, de la ruta y de las condiciones de la mar.

Muchas veces los problemas que desde los puestos directivos se transmiten a la organización tienen su origen en la carencia de
alguna de estas habilidades:

• Decisiones más o menos fundadas en principios de gestión, que han ignorado las características de la empresa, o las
particularidades del sector.
• Decisiones de conocedores del negocio sin experiencia en management.

En cierto modo es como poner a los mandos de una embarcación a un capitán que desconoce cómo es el barco que tripula y las
características de la ruta que va a seguir; o como apostar al timón a un tripulante veterano del navío, sin conocimientos de
pilotaje.

Según las características y dimensiones de la embarcación, y las vicisitudes que presente la travesía, alcanzar puerto puede ser
un reto sin solución.

Conocer la empresa

Los aspectos de la empresa que se deben conocer son, en general, comunes en todos los sectores, y poco puede aportar este
artículo a un gestor, que él no conozca ya:

Para conseguir eficiencia en su estrategia de pro-ducción esta deberá ser consecuente y estar alineada

Con:

La visión: Qué quiere llegar a ser la organización y cuál es su meta.

Estrategia:, foco y plan de negocio, contemplando el mercado, las fortalezas y debilidades propias, etc. Cuál es la ruta que se
ha perfilado para alcanzar esa meta.

Sin saber adónde se va, difícilmente se puede diseñar la estrategia para lograr el objetivo, y sin estrategia también es difícil que
un gestor pueda ejecutar la táctica adecuada, que es la que deberá incluir, entre otras cosas, el modelo de producción
empleado.

Por supuesto se puede zarpar y navegar a la deriva para ver en qué puerto se acaba, pero si no se es amante de las emociones
fuertes; y si se siente respeto por el capital de los accionistas, y el trabajo de toda la tripulación, es mejor considerar que la
lotería no es una inversión, sino un juego de azar.

Industria del software

Para todas las industrias hay marcos de trabajo com-puestos por normativas y estándares más o menos estables y
consensuados, que en forma de modelos ayudan a mejora o evaluar la calidad de sus sistemas de producción.

Al mismo tiempo cada ingeniería tiene delimitadas sus áreas de conocimiento, y reguladas las técnicas de trabajo para ofrecer
las garantías necesarias en la construcción de sus respectivos artefactos.

Así por ejemplo, una empresa de arquitectura, o de ingeniería aero-espacial, naval o nuclear . tiene estándares y conocimientos
estables, que si aplica sistemáticamente aportan garantías contrastadas a la robustez de las estructuras de sus edificios o de las
naves que construye.

Estos conocimientos, que sirven de referencia y ayuda a los entornos de desarrollo, provienen de dos áreas:
1.- Currículo de técnicas y conocimientos de las respectivas ingenierías.

2.- Modelos, normas y estándares de calidad y procesos aplicables a cada industria.

Una diferencia importante entre la industria del software y otras industrias de ingeniería es la falta de consenso o inmadurez en
los dos puntos anteriores, que deja a las empresas de nuestro sector en un cierto grado de orfandad a la hora de buscar ayuda en
modelos, técnicas o patrones de referencia.

Por la relativa juventud del software en nuestra industria no hay un consenso acerca de cómo éste dee ser producido. El
siguiente texto extraído del artículo “Criticism of software engineering” de wikipedia expone con acierto la situación actual:

“En la ingeniería tradicional hay un claro consenso de cómo deben construirse las cosas, cuáles son los estándares que deben
seguirse y qué riesgos deben tratarse: si un ingeniero no sigue estas prácticas y algo falla, puede ser demandado. Sin
embargo no hay un consenso similar en la ingeniería del software. Cada uno promueve sus propios métodos, proclamando
grandes beneficios en la productividad, que generalmente no respalda con evidencias científicas imparciales.”

El problema en este momento no es la falta de estándares, modelos o técnicas, sino la abundancia de ellos, por lo que resulta
aconsejable tomar un apunte del plano general para saber por dónde nos movemos.

Fig. 4

Modelos y estándares de calidad

La figura 4 es un mapa de situación simplificado con la foto de los principales marcos y modelos de procesos que pueden
servir de referencia a las organizaciones de software; y las principales referencias de sus orígenes y evolución.

Los procesos de fabricación de los años 50 hicieron necesaria la normalización de los procesos de produc-ción para garantizar
la consistencia de los resultados sobre unos parámetros o requisitos previamente determinados.

La norma que se considera como punto de arranque de los posteriores estándares, marcos y modelos que se han extendido a
todas las industrias es la desarrollada por EE.UU. en 1959: “Quality Program Requirements” MIL-Q-9858, que, inicialmente
diseñada para el ámbito militar, estableció un esquema auditable (a través de la norma de inspección MIL-I.45208) de los
requisitos que los proveedores debían cumplir.

El uso de esta norma se fue generalizando, pero de forma paralela diferentes países y organizaciones comenzaron a desarrollar
las suyas propias. Así por ejemplo la OTAN en 1968 adoptó las especificaciones AQAP “Allied Quality Assurance
Procedures”).

El estándar británico BS5750, adoptado en el Reino Unido en 1979 fue el siguiente hito relevante en el camino de las
normalizaciones, al lograr gran reconocimiento en varios países.

Esta normativa fue en realidad la precursora de ISO 9000.

Las normas y estándares que fueron surgiendo de los años 60 a los 90 dieron respuesta a las garantías de homogeneidad,
calidad y predectibilidad que los entornos de fabricación, y especialmente el desarrollo de sistemas complejos requería al
agrupar en proyectos la construcción de artefactos que imbricaban tecno-logías e ingenierías diferentes: mecánica, aero-
espacial, naval, atómica, etc.

En estos sistemas se requería la integración, cada vez con mayor protagonismo, de una ingeniería que en base al conocimiento
que había desplegado en esos años, no podía considerarse aún ni asentada ni consensuada: la ingeniería del software.

Algunos de los fiascos que se produjeron en determinados sistemas por la introducción del software sin que éste pudiera dar
garantías de resultados a la altura de ingenierías más maduras, son ya parte de la historia de nuestra profesión.

Esbozar este marco histórico resulta necesario, porque es la causa de la actual sopa de letras capaz de marear al gestor más
dispuesto con sólo ennumerarla: ISO 900-3, TicIT, ISO 12207, CMM-SW, ISO 15504, CMMI, ASD, XP, SCRUM, DSDM,
PP, MSF…

Tomando un poco de perspectiva (tan sólo 3 décadas), al software se le ha juntado la necesidad de encajar en marcos de
calidad para ofrecer garantías de perfección, eficiencia y consistencia en los resultados; con la creación de su propia base de
conocimientos técnicos para desarrollar y mantener software (requisitos, codificación, pruebas, diseño, etc.)

En este punto es interesante diferenciar entre marco o modelo de procesos y técnica o base de conocimiento técnico.

La primera línea tiene como objetivo fijar qué es lo que hay que hacer para ofrecer garantías en los proyectos, y la segunda
cómo debe realizarse.

Un marco de procesos determinará, por ejemplo, la necesidad de gestionar adecuadamente las modif.-caciones de requisitos, o
de realizar un diseño detallado antes de comenzar la codificación. El valor de los modelos de procesos radica en el
conocimiento que aportan al señalar las actividades cuya omisión incrementa las posibilidades de fracaso en los proyectos.

Sin embargo el marco de procesos no dirá, por ejemplo, que deba emplearse un sistema basado en documentos o en base de
datos para la gestión de los requisitos; o si el diseño debe realizarse con diagramas IDEF o UML.

Este es el campo de la técnica de la ingeniería del software.

En la línea de los modelos de procesos (qué cosas hay que hacer) a partir de finales de los 80 se comenzaron a desarrollar
marcos específicos para el software, para dar la cobertura necesaria a las particularidades de nuestro producto, donde las
normas generales se quedaban cortas.

En esta línea ISO 9000 desarrolló una norma específica para el software: ISO 9000-3, y la BSI (British Standards Institution)
hizo lo propio desarrollando TickIT.
En esta primera aparición de estándares surgieron también, aunque con menor repercusión: Trillium y Bootstrap.

El primero desarrollado por la empresa Bell Canadá, que liberó sus derechos, haciéndolo de dominio público.

Bootstrap es una metodología para la evaluación, medición y mejora de los procesos de software. Su desarrollo lo llevó a cabo
una comisión del ESPRIT (European Strategic Program for Research).

Sin embargo las dos líneas que surgieron a principios de los 90 y que continúan como referentes en la actualidad son. CMM, y
las normalizaciones de ISO 12207 y 15504.

CMM

SEI (Software Engineering Institute), un auténtico peso pesado en la normalización de los procesos del software, desarrolló su
línea de trabajo sobre el concepto de “madurez” de las organizaciones para producir software.

Por madurez se entiende la capacidad que tiene la organización para asegurar la calidad de sus proyectos (fecha, coste y
funcionalidad), la homogeneidad (siempre y en todos sus proyectos) y la capacidad de aprendizaje de sus propia experiencia y
su aplicación en la mejora continua.

Como resultado de estas líneas de trabajo, en 1990 publicó el modelo de madurez de la capacidad para el desarrollo de
software (CMM-SW), que tras más de una década de existencia ha demostrado que en muchas organizaciones ha resultado
eficaz.

Este modelo crea una escala de cinco niveles para determinar la madurez de una organización.

• Nivel 1.- INICIAL

Pertenecen a él las empresas que no basan el desarrollo en procesos definidos, y no aplican técnicas de gestión de
proyectos.

El modelo se refiere a entornos de producción caóticos con técnicas de programación heroica cuyos resultados no son
predecibles y dependen exclusivamente de la valía de las personas.

• Nivel 2.- REPETIBLE.

Define a las organizaciones que aplican técnicas de gestión de proyectos, aunque no dispongan de procesos definidos.

• Nivel 3.- DEFINIDO

Pertenecen a él las organizaciones que disponen de procesos definidos con precisión y ejecutados de forma regular. Las
empresas con este nivel de madurez examinan la experiencia de los proyectos que realizan y emplean las lecciones
aprendidas para mejorar sus procesos.

• Nivel 4.- GESTIONADO

En el cuarto nivel de madurez se sitúan las organizaciones que han depurado el análisis de los proyectos realizados, hasta
institucionalizarlo como procesos que miden cuantitativamente la capacidad de los procesos de desarrollo, de forma que
pueden predecir de forma cuantificable los resultados, y evaluar las mejoras con mediciones objetivas.

• Nivel 5.- OPTIMIZADO

 Las organizaciones con un nivel 5 de madurez tienen definidos, y practican de forma institucionalizada, procesos de
mejora continua que se nutren con la información cuantificada de los procesos del nivel 4.

Tras el desarrollo del modelo SW-CMM, surgieron otros para la medición y mejora de la capacidad de los procesos, todos
ellos centrados en áreas relacionadas con el foco original del SW-CMM: el desarrollo de software:

• Systems Engineering Capability Maturity Model (SE-CMM)

• Integrated Product Development Capability Maturity Model (IPD-CMM)
• People Capability Maturity Model (P-CMM)
• Software Acquisition Capability Maturity Model (SA-CMM)

En 2000 el modelo SW-CMM se actualizó en otro que facilitaba su implantación de forma conjunta y simultánea con otros
modelos (SE-CMM o IPD-CMM). Fue el nuevo modelo CMMI (Capability Maturity Model Integration).

En la actualidad hay varios modelos CMMI, en función de las áreas que integran

• CMMI-SE/SW/IPPD/SS (Systems Engineering, Software Engineering, Integrated Product and Process Development,
Supplier Sourcing).
• CMMI-SE/SW/IPPD (Systems Engineering, Software Engineering, Integrated Product and Process Development).
• CMMI-SE/SE (Systems Engineering, Software Engineering)

Además de la integración de varias disciplinas, los modelos CMMI introdujeron otra novedad que afectaba a su implantación:

CMMI al igual que CMM tiene dos utilidades. Puede servir tanto como guía para la mejora en una organización, o como
criterio para evaluar su nivel; pero mientras CMM centraba estas dos finalidades en la dimensión de la madurez de la
organización, CMMI introduce una segunda dimensión, también válida para guiar las actividades de mejora y para evaluar a
las organizaciones: la capacidad de los procesos.

CMMI establece 6 niveles para determinar la capacidad de un proceso:

• Nivel 0.- INCOMPLETO

El proceso no se realiza.

• Nivel 1.- REALIZADO

Se lleva a cabo el proceso, consiguiendo transformar elementos de entrada identificados, en productos de salida.

• Nivel 2.- GESTIONADO

El proceso se ejecuta siempre de la misma manera, de una forma gestionada.

• Nivel 3.- DEFINIDO

El proceso está definido en la organización y se ejecuta siempre.

• Nivel 4
 CUANTIFICADAMENTE GESTIONADO

La ejecución del proceso tiene institucionalizado en la organización un sistema de medición objetivo y cuantificable de su
capacidad.

• Nivel 5.- OPTIMIZADO

El proceso, que se ejecuta siempre, está definido en la organización, se mide y está integrado en un plan, también
institucionalizado, de mejora continua basada en las mediciones de los procesos.

De esta forma los modelos CMMI presentan 2 versiones:

• Versión escalonada. Guía a la organización sobre las áreas de procesos que debe ir abordando, las prácticas que debe
implantar y los objetivos que debe alcanzar para ir consiguiendo los sucesivos niveles de madurez.
• Versión continua. Permite cierta libertad a la organización sobre las áreas de proceso que desea mejorar, y le orienta para
ir elevando su nivel de capacidad.

Consecuentemente al evaluar a una organización se puede hacer sobre la dimensión de su madurez, estableciendo cuál es el
nivel que ha alcanzado, o sobre la dimensión de la capacidad, reflejando cuál es el nivel de cada una de las áreas de proceso
contempladas por el modelo.

Mientras SEI publicaba y comenzaba a definir su modelo CMM, ISO emprendía los otros dos proyectos que hoy forman los
principales puntos de referencia en el ámbito de la calidad para nuestra industria: ISO 12207 e ISO 15504.

ISO/IEC 12207

Es el estándar internacional que ha determinado cuál es el ciclo de vida de un proyecto de software, y cuáles los procesos y
tareas que intervienen en cada una de sus fases.
 Figura 5

A grandes rasgos, 12207 concluyó considerando que el ciclo de vida de un sistema de software comienza en el momento que
se concibe su idea o necesidad.

Momento en el que ya es necesario comenzar a actuar de manera ortodoxa para describir el ámbito del problema, las
soluciones posibles, etc.

El ciclo de vida comprende también el desarrollo, mantenimiento y operación y no concluye hasta que el sistema deja de
utilizarse y es definitivamente retirado.

SPICE – ISO/IEC STD. 15504.

En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo para el desarrollo de un modelo que fuera la base
de un futuro estándar internacional para la evaluación de los procesos del ciclo de vida del software.

Este trabajo recibió el nombre de proyecto SPICE (Software Process Improvement and Capability dEtermination), y en junio
de 1995, con la publicación de su primer borrador, desde ISO fueron invitadas diferentes organizaciones para aplicarlo y
valorar sus resultados.

En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pasó a la fase de informe técnico con la
denominación ISO/IEC TR 15504.

La instrucción técnica consta de 9 apartados, recogidos en volúmenes independientes, que se han ido publicando como
redacción definitiva del estándar internacional ISO/IEC 15504 durante el periodo 2003-2005.

Aunque ISO comenzó con el proyecto SPICE algo más tarde que SEI con el modelo CMM, durante su evolución han ido
convergiendo, y ambas instituciones vienen trabajando de forma conjunta desde 1998 para lograr la compatibilidad que
finalmente han garantizado entre el modelo CMMI y el estándar 15504, de forma que la conformidad con uno de ellos implica
la también conformidad con el otro.

El estándar está recogido en 9 documentos.

1.- (informativo) Conceptos y guía de introducción.

2.- (normativo) Modelo de referencia de los procesos y de su capacidad.

3.- (normativo) Ejecución de las auditorías.

4.- (informativo) Guía para la realización de auditorías.

5.- (informativo) Modelo de asesoría e indicadores.

6.- (informativo) Guía de formación de consultores.

7.- (informativo) Guía para usar en los procesos de mejora.

8.- (informativo) Guía para determinar la capacidad de los procesos del proveedor.

9.- (normativo) Vocabulario.

ISO/IEC 15504, al igual que CMMI es un modelo para evaluar los procesos de la organización y determinar si resultan
efectivos para conseguir los objetivo. También es un modelo para guiar las acciones de mejora de los procesos.

15504 tiene gran similitud con la representación continua de CMMI. Al igual que este último centra el foco en la capacidad de
los procesos, y permite trabajar sólo con una parte de ellos en lugar de hacerlo con todos los de la organización.

ISO 15504 agrupa los procesos de las organizaciones de software en cinco categorías:

• Cliente – proveedor
• Ingeniería
• Soporte
• Gestión
• Organización

Y para la medición de cada proceso define una escala de 6 niveles

• 0 Proceso incompleto
• 1 Proceso realizado
• 2 Proceso gestionado
• 3 Proceso establecido
• 4 Proceso predecible
• 5 Proceso optimizado.
ISO 15504 y CMMI son los referentes de las metodologías formales. Para ambos el centro de su desarrollo son los procesos,
no sólo para el desarrollo, mantenimiento y operación de los sistemas de software, sino también para mejorar la capacidad de
los propios procesos y la madurez de las organizaciones.

Modelos nuevos sobre una profesión recién estrenada

El uso de modelos de procesos y calidad para asegurar la eficiencia, aptitud y consistencia en los resultados, y para asentar
pautas de mejora continua, es relati-vamente novedoso, y lo habitual es aplicar estos marcos sobre entornos de fabricación, con
conoci-mientos profesionales ya maduros.

El software, sin embargo, es una industria que trabaja con un conocimiento profesional escasamente asentado. Y a la aparición
de marcos y modelos de calidad se suma el movimiento paralelo de propuestas de currículos profesionales.

La profesionalización exige:

• Disponer de una base de conocimiento, desarrollada con metodología científica, y contrastada con la experiencia.
• Consenso y aceptación por la comunidad que ejerce la profesión.
• Desarrollo de de currículos profesionales, que gracias al consenso resulten homogéneos sobre centros de formación,
universidades y países diferentes.
• Desarrollo de las organizaciones académicas y profesionales de autorregulación.

Con este esquema se podrá estar más o menos de acuerdo, pero es el que emplea la sociedad para dar el rango de profesión a
los trabajos no regulados. Para cambiar el título de curandero por el de médico, el de sacamuelas por odontólogo, o el de
alquimista por el de químico.

Fig. 6
(Gary Ford y Norman Gibbs 1996)

En esta línea han estado trabajando un buen número de organizaciones profesionales, agrupados en el proyecto SWEBOK
(Software Engineering Body Of Knowledge http://www.swebok.org)
Su objetivo ha sido asentar de forma consensuada la base de conocimiento necesaria para el currículo de un ingeniero de
software. Primer paso para lograr un entorno profesional, socialmente reconocido.

El trabajo de este proyecto comenzó en 1998, y la publicación de la primera versión, consensuada por todos los participantes,
se produjo en Febrero de 2004.

Esto da una idea de lo tierna que está la profesión. O mejor dicho, de que se trata de una profesión no asentada.

La heterodoxia: métodos ágiles

Ya hemos visto que a la relativa novedad de gestión por procesos, en nuestra industria se suma como dificultad adicional el
producirse de forma simultánea al asentamiento de la profesión.

Y para conseguir el “más difícil todavía”, hay que contar con una tercera tendencia de normalización. O, quizá habría que
llamarla de des-normalización:

Los métodos ágiles.

A finales de los 90, reputados profesionales con renombre y eco en diferentes foros técnicos, comenzaron a cuestionar las
metodologías formales, que representadas por CMM e ISO 15504, y respaldadas por la autoridad y los medios de sus
respectivas organizaciones, estaban configurando una ingeniería del software basada en los procesos.

En marzo de 2001, 17 críticos de estos modelos, convocados por Kent Beck, que acababa de definir una nueva metodología
denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre los modelos de desarrollo de software.

En la reunión se acuñó el término “Métodos Ágiles” para definir a aquellos que estaban surgiendo como alternativa a las
metodologías formales, a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte
dependencia de planificaciones detalladas, previas al desarrollo.

Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto Ágil”, que
compendia el espíritu en el que se basan estos métodos:

Estamos poniendo al descubierto mejores

métodos para desarrollar software,
haciéndolo y ayudando a otros a que lo
hagan. Con este trabajo hemos llegado a
valorar:

• A los individuos y su interacción por

encima de los procesos y las
herramientas

• El software que funciona, por encima de

la documentación exhaustiva.

• La colaboración con el cliente, por

encima de la negociación contractual.
 • La respuesta al cambio, por encima del
seguimiento de un plan.

Aunque hay valor en los elementos de la

derecha, valoramos más los de la izquierda.

Manifiesto Ágil

Los firmantes afirman que los puntos de su manifiesto se sustentan en 12 principios:

1.- Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.

2.- Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio
como ventaja competitiva para el cliente.

3.- Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en
los periodos breves.

4.- Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.

5.- Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y
procurándoles confianza para que realicen la tarea.

6.- La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante
la conversación cara a cara.

7.- El software que funciona es la principal medida del progreso.

8.- Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un
ritmo constante de forma indefinida.

9.- La atención continua a la excelencia técnica enaltece la agilidad.

10.- La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial.

11.- Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.

12.- En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
 Fig. 7

El manifiesto ágil surgió con espíritu de respuesta desafiante y beligerante contra los métodos basados en
procesos.
Los propios integrantes del manifiesto se auto-califican como “anarquistas organizacionales”, y en estos años,
desde uno y otro lado se han lanzado argumentos punzantes buscando más la descalificación ajena que la
justificación propia.

Los principales métodos ágiles son

DSDM (Dynamic Systems Development Method)

Es la metodología más veterana de las auto-denominadas ágiles. Surgió en 1994 de los trabajos de Jennifer
Stapleton, la actual directora del DSDM Consortium.
DSDM es la metodología ágil más próxima a los métodos formales, de hecho la implantación de un modelo
DSDM en una organización la lleva a alcanzar lo que CMM consideraría un nivel 2 de madurez.
Sin embargo los aspectos que DSDM reprocha a CMM son:

• Aunque es cierto que se ha desarrollado con éxito en algunas organizaciones, lo que funciona bien en unos
entornos no tiene por qué servir para todos.
• CMM no le da al diseño la importancia que debería tener.
• CMM plantea un foco excesivo en los procesos, olvidando la importancia que en nuestra industria tiene el
talento de las personas.
• El tener procesos claramente definidos no es sinónimo de tener buenos procesos.
En común con los métodos ágiles, DSDM considera imprescindible una implicación y una relación estrecha con
el cliente durante el desarrollo, así como la necesidad de trabajar con métodos de desarrollo incremental y
entregas evolutivas.
DSDM cubre los aspectos de gestión de proyectos, desarrollo de los sistemas, soporte y mantenimiento y se
autodefine como un marco de trabajo para desarrollo rápido más que como un método específico para el
desarrollo de sistemas.

Extreme Programming
Este es el método que más popularidad ha alcanzado entre las metodologías ágiles, y posiblemente sea
también el más transgresor de la ortodoxia basada en procesos.
Su creador, Kent Beck fue el alma mater del Manifiesto Ágil.
Extreme Programming (XP) se irgue sobre la suposición de que es posible desarrollar software de gran calidad a
pesar, o incluso como consecuencia del cambio continuo. Su principal asunción es que con un poco de
planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino
acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde.

Cuatro son los valores que lo inspiran: simplicidad, feedback, coraje y comunicación.
XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12 prácticas que se
complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en los
cuatro valores citados:
Comunicación
XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente se integra en el equipo
para establecer prioridades y resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la
agenda y las funcionalidades de forma consecuente.
Feedback rápido y continuo
Una metodología basada en el desarrollo incremental de pequeñas partes, con entregas y pruebas frecuentes y
continuas, proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones.
De esta forma fallos se localizan muy pronto.
La planificación no puede evitar algunos errores, que sólo se evidencian al desarrollar el sistema.
La retro-información es la herramienta que permite reajustar la agenda y los planes.
Simplicidad
La simplicidad consiste en desarrollar sólo el sistema que realmente se necesita. Implica resolver en cada
momento sólo las necesidades actuales.
“Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar
al futuro.”
Con este principio de simplicidad, junto con la comunicación y el feedback resulta más fácil conocer las
necesidades reales.

Coraje
El coraje implica saber tomar decisiones difíciles. Reparar un error cuando se detecta. Mejorar el código
siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora.
Tratar rápidamente con el cliente los desajustes de agendas para decidir qué partes y cuándo se van a
entregar.

Las 12 prácticas que aplicadas sobre esta cultura conforman Extreme Programming son:
PRÁCTICAS DE CODIFICACIÓN
1.- Simplicidad de código y de diseño para producir software fácil de modificar.
2.- Reingeniería continua para lograr que el código tenga un diseño óptimo.
3.- Desarrollar estándares de codificación, para comunicar ideas con claridad a través del código.
4.- Desarrollar un vocabulario común, para comunicar las ideas sobre el código con claridad.
PRÁCTICAS DE DESARROLLO
1.- Adoptar un método de desarrollo basado en las pruebas para asegurar que el código se comporta según lo
esperado.
2.- Programación por parejas, para incrementar el conocimiento, la experiencia y las ideas.
3.- Asumir la propiedad colectiva del código, para que todo el equipo sea responsable de él.
4.- Integración continua, para reducir el impacto de la incorporación de nuevas funcionalidades.
PRÁCTICAS DE NEGOCIO
1.- Integración de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del
sistema de forma directa, sin retrasos o pérdidas por intermediación.
2.- Adoptar el juego de la planificación para centrar en la agenda el trabajo más importante.
3.- Entregas regulares y frecuentes para satisfacer la inversión del cliente.
4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.

SCRUM
No es propiamente un método o metodología de desarrollo, e implantarlo como tal resulta insuficiente.
Scrum define métodos de gestión y control para complementar la aplicación de otros métodos ágiles como XP
que, centrados en prácticas de tipo técnico, carecen de ellas.
Los principios de Scrum son:
• Equipos autogestionados.
• Una vez dimensionadas las tareas no es posible agregarles trabajo extra.
• Reuniones diarias en las que los miembros del equipo se plantean 3 cuestiones:

 ¿Qué has hecho desde la última revisión?

 ¿Qué obstáculos te impiden cumplir la meta?
 ¿Qué vas a hacer antes de la próxima reunión?

• Iteraciones de desarrollo de frecuencia inferior a un mes, al final de las cuales se presenta el resultado a
los externos del equipo de desarrollo, y se realiza una planificación de la siguiente iteración, guiada por
cliente.

OTROS MÉTODOS ÁGILES

Familia de métodos Crystal
La familia de metodologías Crystal ofrece diferentes métodos para seleccionar el más apropiado para cada
proyecto.
Crystal identifica con colores diferentes cada método, y su elección debe ser consecuencia del tamaño y
criticidad del proyecto, de forma que los de mayor tamaño, o aquellos en los que la presencia de errores o
desbordamiento de agendas implique consecuencias graves, deben adoptar metodologías más pesadas.
Los métodos Crystal no prescriben prácticas concretas, y se pueden combinar con técnicas como XP.
ASD (Adaptative Software Development)
Método que como alternativa a los procedimientos formales, aborda el desarrollo de grandes sistemas con el
uso de técnicas propias de las metodologías ágiles.
No se trata de una metodología, sino de la implantación de una cultura en la empresa, basada en la
adaptabilidad.
PP (Pragmatic Programming)
Pragmatic Programming es la colección de 70 prácticas de programación, comunes a otros métodos ágiles, cuya
aplicación resulta útil para solucionar los problemas cotidianos.
AM (Agile Modeling)
Agile Modeling es la presentación de un nuevo enfoque para realizar el modelado de sistemas,(diseño) y basado
en los principios de los métodos ágiles remarca la conveniencia de reducir el volumen de la documentación.
ISD (Internet-Speed Development)
Es el más reciente de los métodos ágiles, surgido como respuesta para las situaciones que requieren ciclos de
desarrollo muy breves con entregas rápidas.
Se centra en el talento de las personas sobre los procesos.
ISD es un entorno de gestión orientado al negocio.
FDD (Feature Driven Development)
Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas.
El punto de referencia son las características que debe reunir el software, y se centra en las fases de diseño e
implementación del sistema.

MÉTODOS DE PROPIEDAD COMERCIAL

MSF (Microsoft Solutions Framework)
MSF es la metodología empleada por Microsoft para el desarrollo de software.
Hasta su versión 3 (principios de 2005) MSF se definía como un marco de desarrollo flexible para adaptarse a
las necesidades de cada proyecto, en oposición a lo que sería una metodología prescriptiva; porque parte de la
base de que no hay una estructura de procesos óptima para las necesidades de todos los entornos de desarrollo
posibles.
El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entorno de
desarrollo:

• Fomento de la comunicación abierta.

• Trabajo en torno a una visión compartida.
• Apoderar a los integrantes del equipo (“empowerment”)
• Establecimiento de responsabilidades claras y compartidas.
• Centrar el objetivo en la entrega de valor para el negocio.
• Permanecer ágiles y esperar e cambio.
• Invertir en calidad.
• Aprender de la experiencia.
Para la aplicación de estos principios en los procesos y en las personas, MSF define un Modelo de Equipo y un
Modelo de Procesos.
Sobre los Modelos, y trabajando con la cultura de sus Principios Fundamentales, las Disciplinas que
establece para el desarrollo del software son:

• Gestión de proyectos.
• Gestión de riesgos.
• Gestión de la mejora del talento.
Si bien, MSF despliega la gestión de proyectos y la gestión de riesgos con algunas diferencias sobre las visiones
clásicas de estas áreas.
El marco de desarrollo incluye también Conceptos Clave, Prácticas Contrastadas y Recomendaciones para
la ejecución de las tareas concretas en el desarrollo de software.
En 2005, el desarrollo del nuevo producto de Microsoft “Visual Studio 2005 Team System” ha ganerado la
evolución de MSF hacia la nueva versión 4.0 con dos líneas paralelas:

• Microsoft Solutions Framework (MSF) for Agile Software Development.

• Microsoft Solutions Framework (MSF) for CMMI Process Improvement.

RUP (Racional Unified Process)

Es un proceso de Ingeniería del Software que proporciona una visión disciplinada para la asignación de tareas y
responsabilidades en las organizaciones de desarrollo de software.
RUP es un “modelo-producto” desarrollado y mantenido por Racional Software, integrado en su conjunto de
herramientas de desarrollo, y distribuido por IBM.
RUP integra un conjunto de “buenas prácticas” para el desarrollo de software en un marco de procesos válido
para un rango amplio de tipos de proyectos y organizaciones.
Las principales buenas prácticas cubiertas son:

• Desarrollo iterativo.
• Gestión de requisitos.
• Uso de arquitecturas basadas en componentes.
• Uso de técnicas de modelado visual.
• Verificación continua de la calidad.
• Gestión y control de cambios.
En su visión estática, el modelo RUP está compuesto por:

• Roles: analista de sistemas, diseñador, diseñador de pruebas, roles de gestión y roles de administración.
• Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto
debe tener un propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de
horas o de algunos días; y son elementos base de planificación y progreso.
• Artefactos: Son los elementos de entrada y salida de las actividades. Son productos tangibles del proyecto.
Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, código,
ejecutables…)
• Disciplinas: son “contenedores” empleados para organizar las actividades del proceso. RUP comprende 6
disciplinas técnicas y 3 de soporte.
Técnicas: modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo.
Soprte: gestión de proyecto, gestión de configuración y cambio, y entorno.
• Flujos de trabajo: son el “pegamento”de los roles, actividades, artefactos y disciplinas, y constituyen la
secuencia de actividades que producen resultados visibles.

En su visión dinámica, la visión de la estructura del ciclo de vida RUP se basa en un desarrollo iterativo,
jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo.
Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP:
1.- Inicio. Es la fase de la idea, de la visión inicial de producto, su alcance. El esbozo de una arquitectura
posible y las primeras estimaciones. Concluye con el “hito de objetivo”.
2.- Elaboración. Comprende la planificación de las actividades y del equipo necesario. La especificación de las
necesidades y el diseño de la arquitectura. Termina con el “hito de Arquitectura”.
3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios.
Termina con el “hito del inicio de la capacidad operativa”.
4.- Transición. Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el
mantenimiento hasta lograr la satisfacción de los usuarios. Termina con el “hito de entrega del producto”.

Métodos ortodoxos y métodos ágiles

Se dice que hay dos formas de abordar los proyectos:

1.- Dedicar escaso tiempo a la preparación y planificación, e invertir la mayor parte del tiempo en el
desarrollo, probando y rectificando hasta conseguir el resultado adecuado.
2.- Invertir mucho tiempo y esfuerzo en la preparación y planificación para conseguir que el desarrollo se
ejecute en el menor tiempo y con los menores incidentes posibles.
Aunque sin duda esta es una visión simplificada, refleja las diferencias entre los modelos ortodoxos, o basados
en procesos, y las metodologías ágiles; así como las razones de su desencuentro.
Los métodos formales (CMMI, ISO15504) abogan por el segundo modelo y basan el éxito del proyecto en la
planificación y el rigor normativo en los procesos de su desarrollo.
Hacen especial hincapié en la importancia de los requisitos para conocer con el mayor detalle el sistema antes
de comenzar a construirlo, y en las prácticas formales de la gestión de proyectos, para trabajar sobre una
planificación previa, y controlar su seguimiento.
Para estos modelos, se alcanza mayor nivel de madurez, cuantas más actividades del ciclo de vida del sistema
de software se realicen según los procesos previamente diseñados e implantados en la organización.
Por otra parte, y con mayor o menor proximidad al extremo contrario, se encuentran las denominadas
metodologías ágiles, que tienen como común denominador un modelo de desarrollo incremental para producir
tempranamente pequeñas entregas en ciclos rápidos, y predisposición para el cambio y la adaptación continua;
según sea la conformidad o no de lo producido, y las modificaciones propuestas por los usuarios.
Aparte de esta base común, también comparten menor rigidez en los procesos, aunque las diferencias en este
punto son significativas entre cada método.
Considerar que hay dos formas de realizar los proyectos es una visión simplificada, pero refleja el hecho de
que en la realidad, cada técnica se define en uno u otro bando, y con mayor o menor proximidad del extremo.
Los métodos formales llevados hasta su máximo nivel de madurez se situarían en el extremo de la ortodoxia,
(lado izquierdo de la fig. 8) si bien es cierto que las representaciones continuas de estos modelos permiten
adoptar sólo las prácticas para determinadas áreas de procesos, y llevarlos hasta el nivel de capacidad que se
estime oportuno, por lo que un conocedor del modelo puede emplearlo como guía para realizar una
implantación relativamente ágil, más o menos adecuada a las características de la organización.

Fig. 8

Los métodos ágiles se sitúan más o menos cerca del extremo opuesto. Los más extremistas (quizá PP o XP) por
la no utilización o incluso aversión a los procesos, se encuentran más en la categoría de prácticas de
programación, o técnicas de trabajo (cómo hacer las cosas) que en la de modelos de procesos (qué cosas hay
que hacer)
La circunstancia más o menos marcada en cada caso de “oposición” entre métodos ágiles y métodos formales,
puede inducir al error de considerar a todos ágiles como similares o equivalentes.
En el lado opuesto sí que ocurre, y las similitudes entre CMMI e ISO 15504 son notables, pero con los ágiles
ocurre sin embargo que los niveles de reconocimiento y rigor alcanzan diferencias notables entre ellos, así
como la cobertura que llegan a alcanzar sobre determinadas áreas de procesos.

El oficio del gestor

Con lo visto hasta ahora tenemos ya el mapa de situación.

No es que sea importante conocerlo. Es necesario para no andar desorientados entre los árboles, y tener la
visión del bosque en su conjunto.
Ya solo queda trazar la ruta y guiar el camino. ¡Casi nada!. Pero nadie ha dicho que la gestión de entornos de
desarrollo de software sea fácil. Basta con echar un vistazo a nuestro alrededor.
El mayor o menor grado de éxito en la calidad y eficiencia en el desarrollo de software depende del equilibrio
que se consiga al conjugar los siguientes factores:

• Características de los proyectos de software gestionados.

• Visión de la organización.
• Cultura de la organización.
• Diseño y gestión del equilibrio productivo personas-procesos-tecnología.
Características de los proyectos de software.
El concepto sistema de software es muy amplio, y tan sistema de software es el integrado en un teléfono
celular, como el desarrollado en un proyecto Open Source por iniciativa del propio grupo de desarrolladores; o
el diseñado para asistir el pilotaje de un avión comercial.

En algunos casos se tratará de gestionar una normativa contable u otro negocio o entorno suficientemente
conocido en el que un proceso formal de requisitos inicial puede capturar con bastante detalle todas las
funcionalidades esperadas.
En otros, la novedad o complejidad del entorno en el que se integrará el sistema, hacen difícil, si no imposible
descubrir qué debe hacer el software si no es a través de prototipado o desarrollo evolutivo.

El tamaño también importa. Un sistema puede requerir el esfuerzo de un programador durante un par de
meses, o de un equipo de varias decenas de personas durante un par de años.
Por las características del proyecto quizá la funcionalidad alcanzada en cada versión, así como la precisión en
el cumplimiento de las fechas puede ser poco trascendente o vital para el negocio del cliente.
En este aspecto, la diferencia de criticidad entre el desarrollo de un sistema open-source sin ánimo de lucro, o
de un sistema de gestión para una empresa que depende de él para abrir su negocio, es muy diferente.
El nivel de integridad del sistema, o daño que pueden producir los fallos del sistema, también determina el
rigor de los procesos que deben aplicarse en su desarrollo. Un error en el aplicativo de una entidad bancaria
puede suponer pérdidas económicas o de imagen que comprometan la continuidad de su negocio. Errores en
otros sistemas pueden producir pérdidas humanas. La presencia de errores en la página web de un pequeño
comercio tiene repercusiones de menor alcance.

Visión, misión y negocio de la organización.

Las preguntas relativas a la organización que ayudan a diseñar el aludido equilibrio son:
¿Para qué desarrolla software la organización?
¿Es una empresa con un producto definido que debe dar beneficios?
¿Es el departamento de sistemas de una entidad bancaria que centra su misión en la seguridad?
¿Es una asociación de ingenieros para el desarrollo de un proyecto Open-Source?
Para alcanzar su misión, ¿Qué papel juega la innovación y vanguardia tecnológica?.
¿Se dedican a mantener operativos sistemas ya desarrollados?.
¿Programan sistemas poco innovadores, sobre plataformas contrastadas, para negocios y entornos conocidos?.
¿Apuesta por la innovación, implementación sobre dispositivos nuevos, o diseñan soluciones para entornos
novedosos?.

Cultura de la organización
¿Se trata de una organización con niveles jerárquicos y funciones claramente definidos?
¿Cuáles son los niveles de confianza, delegación, empowerment y responsabilidad?.
¿Clima laboral, motivación?

Diseño y gestión del equilibrio productivo personas-procesos-tecnología

La estrategia productiva.
¿Qué tecnología emplea para el desarrollo?. Equipos, red, sistemas de pruebas, plataformas operativas,
plataformas de desarrollo, pruebas, herramientas CAD…?

¿Qué porcentaje o peso del conocimiento necesario para la ejecución de los proyectos lo garantizan la
ejecución de los procesos, y cuánto las personas?.
¿Son coherentes las políticas o procesos de formación, contratación, planes de carrera, diseño del modelo de
procesos, calidad y mejora…?

El éxito: ¿Gestión o azar?

“Para todo problema complejo hay siempre una solución simple, que es errónea”
George Bernard Shaw
Cuando se desconocen las variables que actúan sobre un sistema, y su influencia, se habla de que presenta un
comportamiento aleatorio (“caótico”).
Por definición, no es posible predecir cuáles serán los resultados al actuar sobre un entorno caótico.
La acción externa modificará algunas variables, pero al no saber cuántas más están actuando, y cuál es su
repercusión, no se pueden predecir los resultados.
Cuantas más variables se conocen, éste se va tornando más predecible y menos caótico, como ha ido
ocurriendo, por ejemplo, en las últimas décadas con la predicción meteorológica.
La diferencia entre un sistema caótico y un sistema complejo es que en el primero son tantas las fuerzas que
actúan que resulta materialmente imposible predecir su resultado (Ej: comportamiento de las bolas en un
bombo).
En sistemas complejos, aunque son varias las fuerzas, sí que resulta posible su conocimiento, o el conocimiento
de las más relevantes, y actuar con probabilidades de certidumbre muy altas sobre las consecuencias.
Desde este punto de vista, un entorno de desarrollo de software es un sistema complejo en el que se pueden
combinar y poner en interacción múltiples elementos, y con diferentes pesos y formas de gestión (Véanse en el
artículo los modelos y técnicas que pueden conjugarse, y los factores que apuntan las preguntas del apartado
anterior).

Aunque sobre los sistemas complejos, a diferencia de los aleatorios, sí es posible actuar con factores de
predictibilidad elevados, si desconocemos su ecuación de fuerzas, se presentan de comportamiento tan
aleatorio como los sistemas caóticos.
Para ser más exactos en esta apreciación, lo cierto es que un sistema complejo parece caótico, a quien
desconoce cuáles son sus variables y su relación, pero esto no es muy frecuente que ocurra, ya que si alguien
sabe que hay variables aprehensibles y que conociéndolas podrá actuar con mayor seguridad, no es normal que
continúe jugando al azar.
El hombre, por su naturaleza necesita seguridad, y si sabe que las reacciones de un sistema responden a un
mecanismo más o menos complejo, no es normal que prefiera ignorarlo.

Por eso el error más habitual consiste en actuar bajo el fenómeno de la “superstición”, tomando como
referencia variables falsas, o creyendo que son tan sólo una o dos las fuerzas que deciden el comportamiento
del sistema.
De esta forma, al igual que el jugador de ruleta supersticioso se aferra a su camisa de la suerte, por la razón
de que le dio un par de noches afortunadas, un gestor se puede aferrar a determinadas prácticas de gestión,
porque una vez funcionaron con éxito, o porque el último libro de management las considera “mano de santo”.

Por este camino también puede acabarse maldiciendo la ruleta, perdón, la gestión; cayendo en el escepticismo
sobre los consultores, las teorías de management, de comportamiento organizacional, los modelos de calidad,
etc.
Porque claro, uno siempre hace las cosas bien. Por eso si los resultados salen mal el problema está fuera de él.

Conclusiones

Para diseñar y gestionar entornos de producción eficientes se debe trabajar con pensamiento sistémico,
comprendiendo que todos los factores implicados en la producción de software componen un sistema
interrelacionado, imbricado y alineado con la misión de la organización.
Lo contrario, y probablemente más habitual consiste en actuar desde una visión fáctica e inmediata, buscando
relaciones lineales causa–efecto, sin apreciar la relación y armonía del sistema, que las integra y les da sentido
(y que no se ciñe al área de desarrollo, sino a la organización en su conjunto).
No se trata por tanto de conocer cuál es la mejor metodología para el diseño de bases de datos, cuál el mejor
modelo de procesos o cuáles las mejores técnicas de gestión de recursos humanos.
La multiplicidad de técnicas, modelos, herramientas, modos de gestión, es consecuencia de la diversidad de
organizaciones y tipos de proyectos posibles.

Evitar la gestión lineal

El error habitual es trabajar con gestión lineal y a-sistémica, administrando soluciones sintomáticas para cada
situación.
La gestión lineal, carece de la perspectiva necesaria, y responde de forma azuzada a la presión del día a día.
Sin esa perspectiva no se ve el sistema, y el marco de trabajo se presenta como un campo de batalla
desordenado que requiere actuaciones en cada uno de los frentes que presenta.
Si los proyectos se retrasan será preciso sugerir, animar o presionar a las personas (allá cada cual con el estilo
de gestión que aplique) para que alarguen sus jornadas de trabajo, o restrinjan los tiempos de café…
Si programamos con mayores costes que nuestra competencia, habrá que contener los salarios, o contratar más
barato, o aplicar procesos de calidad para reducir los tiempos, o… (también aquí cada cual sintonizará mejor
con unas u otras decisiones.).
Etcétera.

Para cada necesidad se abre el botiquín, y se busca un apaciguador de síntomas.

Las soluciones obvias no funcionan. En el mejor de los casos introducen mejoras en el corto plazo que
terminarán por empeorar la situación.
La presión del día a día ofrece dos atajos muy tentadores que se deben evitar:
• Aplicar soluciones enfocadas en resultados en el corto plazo.
• Obtener mediciones y datos que demuestren un buen comportamiento.

Con carácter general, las soluciones a corto, hipotecan el futuro. son sintomáticas, y generan resistencia, de
forma que la próxima vez que se vuelva a generar un problema similar, el remedio sintomático tendrá menos
eficacia.
Cerrar rápido un proyecto, hará más duro su mantenimiento (sistema peor diseñado, mayor densidad de
errores…).
Presionar a los programadores para cumplir fechas es también una solución a corto, que no ofrece soluciones a
largo. Si se mantiene la presión como una norma, generará desmotivación y degradación en la calidad de lo
producido.
Las mediciones sobre los procesos son una herramienta útil para comprender el funcionamiento general del
sistema y trabajar en su mejora. Emplearlas como justificación ante instancias superiores, es también una
búsqueda de la solución a corto, interesada en que las cosas pinten bien. De esta forma las organizaciones
pueden llegar a agonizar con una apariencia de salud envidiable.

Gestión sistémica
La eficiencia es el resultado de la idoneidad y equilibrio de todos los componentes de la producción.
¿Cuál es el mejor modelo de procesos para el desarrollo de software?.
¿La cultura de empresa más adecuada?
¿Las mejores técnicas de gestión de RR.HH:?
¿Las mejores plataformas de progrmación?
Para la gestión de las personas, los procesos y la tecnología, no hay métodos simples, absolutos con resultados
inmediatos.

Un modelo de procesos CMMI con nivel 5 de madurez puede garantizar resultados en línea con la misión de una
gran empresa integradora de grandes sistemas críticos, pero resulta excesivamente pesado para una “Start-up”
de diseño web.
El modelo “bueno” no es Scrum, o CMMI o XP, sino el que mejor encaje en su sistema.
Las técnicas empleadas, los modelos de calidad, la tecnología, la cultura de la empresa, la gestión de las
personas… deben guardar coherencia, de forma que se potencien, y no se contrarresten.
Un “know-how” adecuado, basado en el conocimiento tácito de las personas, compaginado con equipos
desmotivados no es una buena combinación.
Un método ágil puede resultar idóneo para el tamaño de equipos y de empresa, pero si sus procesos no cubren
las facetas contractuales de la adquisición, generará problemas en la validación del producto.
A modo de síntesis, las claves para conseguir organizaciones eficientes de desarrollo de software son:

• Personalidad de la organización.
Esta es la referencia final con la que deben alinearse y sincronizarse todas las variables que operan juntas
para lograr los objetivos. Cuanto más nítida sea la visión, misión, estrategia, segmento y objetivos de la
organización, con mayor atino y precisión se podrán imbricar los componentes del sistema y orientar la
 gestión de su funcionamiento.

• Conocimiento de la propia empresa.

Sus objetivos, debilidades y fortalezas. Relevancia del capital estructural y del capital humano. Cuál es su
configuración actual y cuál la óptima para la personalidad de la organización.
Este es el conocimiento que orientará el diseño y la gestión del sistema de desarrollo (en realidad de todos
los subsistemas de la organización).

• Conocimiento de la industria.
Características del producto del negocio: el software. Las áreas de conocimiento implicadas en su
desarrollo, las técnicas de construcción, los métodos y procesos posibles para su desarrollo y
mantenimiento (ISO, CMM, Métodos Ágiles…)
Es la información de referencia, con el conocimiento acumulado por nuestra industria. Su comprensión y
visión general ayuda a seleccionar las prácticas más adecuadas para la organización, o da el conocimiento
de causa necesario para el diseño de modelos híbridos propios.

• Gestión sistémica.
Guiar las decisiones de gestión desde la perspectiva general del sistema que compone la organización.
Huir de las soluciones sintomáticas, y evaluar sus idoneidad más allá del corto plazo, y su coherencia con el
sistema en su conjunto.

• Revisión y adaptación.
El mercado, el entorno tecnológico, la misma base de conocimiento de nuestra industria, están en continua
evolución.
Es necesaria una tarea de vigilancia del entorno para investigar, desarrollar e innovar, tanto en productos
como en los propios procesos y formas de trabajo.

Modelos y prácticas de producción o de calidad hay muchos: EFQM, Six Sigma, CMMI, ISO 15504, ISO 9000,
DSDM, MSF, XP, PP, etc.
Teorías y técnicas para la gestión de las personas hay muchas: evaluaciones de desempeño, gestión por
competencias, coaching, Maslow, Taylorismo, Herzberg, Mc Gregor, Vroom, Shein, etc.
La tecnología ofrece múltiples herramientas CAD de ayuda en la ingeniería del software (Requisite Pro, Visio,
Subversión, CVS, MSTS, Racional Rose, etc) así como plataformas de desarrollo, operativas, lenguajes,
compiladores....
Aquí hay de todo, como en botica; pero con el mismo criterio que las medicinas, hay que considerar que
aunque todos los remedios son buenos, ni todos sirven para todos, ni deben combinarse al azar.
El conocimiento general de la naturaleza del software y del marco de nuestra industria son ingredientes
necesarios tanto para abordar el diseño de procesos con recursos propios, como para evaluar con acierto a una
asesoría externa que pueda ofrecer una orientación objetiva; porque a la consultoría le ocurre lo que a nuestra
profesión, que no está normalizada, y en el peor de los casos uno puede terminar con un curandero o un
traumatólogo, cuando lo que necesita, a lo mejor es un alergólogo.

Bibliografía
JENNIFER STAPLETON, DSDM Business Focused Development, DSDM Consortium, 2003
KEN SCHWABER y MIKE BEEDLE, Agile Software Development with Scrum, Prentice Hall, 2002
JIM HIGHSMITH, Agile Project Management, Addison Wesley, 2004.
KEN SCHABER, Agile Project Management with Scrum, Microsoft, 2004
GARY POLLICE, LIZ AUGUSTINE, CHRIS LOWE y JAS MADHUR, Software Development for Small Teams a RUP-
Centric Approach, Addison Wesley, 2004
BARRY BOEHM y RICHARD TURNER, Balancing Agility and Discipline, Addison Wesley, 2004
GARY FORD y NORMAN GIBBS, Mature Profession of Software Engineering, SEI, 1996
ROBERT L. GLASS, Facts and Fallacies of Software Engineering, Addison Wesley, 2002
CARNEGIE-MELLON UNIVERSITY CMMI for Software Engineering, 1.1, 2002
 IEEE COMPUTER SOCIETY Guide to the Software Engineering Body of Knowledge, 2004
DENNIS M. AHERN, AARON CLOUSE y RICHARD TURNER, CMMI Distilled: A Practical Introduction to Integrated
Process Improvement, Addison Wesley, 2003
MARY BETH CHRISSIS, MIKE KONRAD y SANDY SHRUMI, CMMI Guidelines for Process Integration and Product,
Addison Wesley, 2003
HAN VAN LOON, Process Assessment and ISO/IEC 15504 A Reference Book, Springer, 2004