CMM – CMMI Calidad de Ingeniería del Software

Cuando el responsable del departamento de desarrollo me dijo que íbamos

a implantar un modelo de calidad llamado CMM - CMMI, Me pasó el documento
con el modelo y mis peores pensamientos se confirmaron. Por si alguno de
nosotros no ha visto el modelo de calidad CMM - CMMI el lomo tiene más de
cuatro dedos de grosor, tu pones la mano encima de la mesa y el modelo
CMMI sobresale.

Sin embargo, al final de este camino, la implantación de procesos de

gestión y desarrollo de proyectos ha sido una de las cosas más enriquecedoras
que he podido hacer. Sí, porque al instalar procesos te permite trabajar con
personas, que aunque siempre es difícil, también es muy satisfactorio.

Por aquel entonces lo poco que había oído de modelos de calidad era sobre
la ISO 9000, también había oído la mayoría de las empresas realmente les
importa muy poco la calidad de lo que producen sino más bien tener la
certificación y poner dicho sello en su publicidad. Muchas de ellas siguen
todavía esta filosofía.

Pero como soy muy curioso y confío más en la Web que en los estándares
oficiales para entender las cosas, me puse a investigar (cotillear) por la web.

De mis experiencias en estos 2 años con el modelo CMM - CMMI voy a

intentar explicaros de una forma clara y sencilla en que consiste este modelo
de calidad del software.

El nacimiento de CMM - CMMI

El departamento de defensa de los estados unidos tenía muchos

problemas con el software que encargaba desarrollar a otras empresas, los
presupuestos se disparaban, las fechas alargaban más y más. ¿Quién no se ha
encontrado con este tipo de problemas si ha trabajado con una empresa de
software?

Como esta situación les parecía intolerable convocó un comité de expertos

para que solucionase estos problemas, en el año 1983 dicho comité concluyó
"Tienen que crear un instituto de la ingeniería del software, dedicado
exclusivamente a los problemas del software, y a ayudar al Departamento de
Defensa".

Convocaron un concurso público en el que dijeron: "Cualquiera que quiera

enviar una solicitud tiene que explicar cómo van a resolver estos 4 problemas",
se presentaron diversos estamentos y la Universidad Carnegie Mellon ganó el
concurso en 1985, creando el SEI.

El SEI (Software Engineering Institute) es el instituto que creó y mantiene

el modelo de calidad CMM - CMMI
¿Qué es el CMM - CMMI?

El CMM - CMMI es un modelo de calidad del software que clasifica las

empresas en niveles de madurez. Estos niveles sirven para conocer la madurez
de los procesos que se realizan para producir software.

Niveles CMM - CMMI

Los niveles CMM - CMMI son 5:

 Inicial o Nivel 1 CMM - CMMI. Este es el nivel en donde están todas

las empresas que no tienen procesos. Los presupuestos se disparan, no
es posible entregar el proyecto en fechas, te tienes que quedar durante
noches y fines de semana para terminar un proyecto. No hay control
sobre el estado del proyecto, el desarrollo del proyecto es
completamente opaco, no sabes lo que pasa en él.

Es el típico proyecto en el que se da la siguiente situación:

 ¿Cómo va el proyecto?-->Bien, bien

 Dos semanas después… ¿Cómo va el proyecto? Bien, bien.
 Tres semanas después… El lunes hay que entregar el proyecto.- No
sé por qué pero los proyectos se entregan los lunes.  El lunes !!?.
Todavía falta mucho!!  ¿Cómo? Me dijiste que el proyecto iba
bien!! Arréglatelas como quieras, pero el proyecto tiene que estar
terminado para el lunes.

Si no sabes el tamaño del proyecto y no sabes cuánto llevas hecho,

nunca sabrás cuando vas a terminar.

 Repetible o Nivel 2 CMM - CMMI. Quiere decir que el éxito de los

resultados obtenidos se pueden repetir.

La principal diferencia entre este nivel y el anterior es que el proyecto

es gestionado y controlado durante el desarrollo del mismo.

El desarrollo no es opaco y se puede saber el estado del proyecto en

todo momento.

Los procesos que hay que implantar para alcanzar este nivel son:

o Gestión de requisitos
o Planificación de proyectos
o Seguimiento y control de proyectos
o Gestión de proveedores
o Aseguramiento de la calidad
o Gestión de la configuración
 Definido o Nivel 3 CMM - CMMI. Resumiéndolo alcanzar este nivel
significa que la forma de desarrollar proyectos (gestión e
ingeniería) está definida, por definida quiere decir que está
establecida, documentada y que existen métricas (obtención de datos
objetivos) para la consecución de objetivos concretos.

Los procesos que hay que implantar para alcanzar este nivel son:

o Desarrollo de requisitos
o Solución Técnica
o Integración del producto
o Verificación
o Validación
o Desarrollo y mejora de los procesos de la organización
o Definición de los procesos de la organización
o Planificación de la formación
o Gestión de riesgos
o Análisis y resolución de toma de decisiones

La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es

un nivel que proporciona muchos beneficios y no ven la necesidad de ir
más allá porque tienen cubiertas la mayoría de sus necesidades.

 Cuantitativamente Gestionado o Nivel 4 CMM - CMMI. Los

proyectos usan objetivos medibles para alcanzar las necesidades de los
clientes y la organización. Se usan métricas para gestionar la
organización.

Los procesos que hay que implantar para alcanzar este nivel son:
o Gestión cuantitativa de proyectos
o Mejora de los procesos de la organización.

 Optimizado o Nivel 5 CMM - CMMI. Los procesos de los proyectos y

de la organización están orientados a la mejora de las actividades.

Mejoras incrementales e innovadoras de los procesos que mediante

métricas son identificadas, evaluadas y puestas en práctica.

Los procesos que hay que implantar para alcanzar este nivel son:

o Innovación organizacional
o Análisis y resolución de las causas
 Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo
realizan simultáneamente ya que están muy relacionados.

A grandes rasgos es necesario introducir el modelo de calidad del software

CMM - CMMI para aquella gente que se encuentra por primera vez con él. La
implantación de un modelo de estas características es un proceso largo
y costoso que puede costar varios años de esfuerzo. Aun así el beneficio
obtenido para la empresa es mucho mayor que lo invertido.

"Y a este respecto se debe tener en cuenta hasta qué punto no hay cosa
más difícil de tratar, ni más dudosa de conseguir, ni más peligrosa de conducir,
que hacerse promotor de la implantación de nuevas instituciones.

La causa de tamaña dificultad reside en que el promotor tiene por

enemigos a todos aquellos que sacaban provecho del viejo orden y encuentra
unos defensores tímidos en todos los que se verían beneficiados por el nuevo.

Esta timidez nace en parte al temor de los adversarios, que tienen la ley
de su lado, y en parte también la incredulidad de los hombres, quienes -en
realidad- nunca creen en lo nuevo hasta que adquieren una firme experiencia
en ello.

De ahí nace que, siempre que los enemigos encuentran la ocasión de

atacar, lo hacen con ánimo faccioso, mientras los demás sólo proceden a la
defensa con tibieza, de lo cual resulta un serio peligro para el príncipe y para
ellos."

Si nos interesa profundizar más en el conocimiento de los procesos de

calidad CMM-CMMI, podemos empezar con introduciros en el Nivel 2 de CMM-
CMMI.

http://www.ingenierosoftware.com/calidad/cmm-cmmi.php

Caso específico para la calidad del software

Análisis y Diseño
 Patrones de diseño
 Podredumbre del software
 UML: Diagramas UML. ¿Qué es UML?
 UML: Casos de Uso

Gestión de Equipos
 Liderazgo técnico (MOI)
Motivación, Organización e Innovación
 Comunicación en equipos de software
  Estabilizar una aplicación
mediante reuniones SCRUM
 Control de código fuente
 Gestión de proyectos con SCRUM

Patrones de diseño

Diseño de Software Orientado a Objetos

Patrones de diseño o más comúnmente conocidos como "Design

Patterns". ¿Qué son los patrones de diseño? Son soluciones simples y
elegantes a problemas específicos y comunes del diseño orientado a objetos.
Son soluciones basadas en la experiencia y que se ha demostrado que
funcionan.

Es evidente que a lo largo de multitud de diseños de aplicaciones hay

problemas que se repiten o que son análogos, es decir, que responden a un
cierto patrón. Sería deseable tener una colección de dichos patrones con las
soluciones más óptimas para cada caso. En este artículo presentamos una lista
con los más comunes y conocidos.

Los patrones de diseño no son fáciles de entender, pero una vez entendido
su funcionamiento, los diseños serán mucho más flexibles, modulares y
reutilizables. Han revolucionado el diseño orientado a objetos y todo buen
arquitecto de software debería conocerlos.

A continuación una lista con los patrones de diseño a objetos más

habituales publicados en el libro "Design Patterns ", escrito por los que
comúnmente se conoce como GoF (gang of four, "pandilla de los cuatro").

Patrones de creación

 Abstract Factory. Proporciona una interfaz para crear familias de

objetos o que dependen entre sí, sin especificar sus clases concretas.
 Builder. Separa la construcción de un objeto complejo de su
representación, de forma que el mismo proceso de construcción pueda
crear diferentes representaciones.
 Factory Method. Define una interfaz para crear un objeto, pero deja
que sean las subclases quienes decidan qué clase instanciar. Permite
que una clase delegue en sus subclases la creación de objetos.
 Prototype. Especifica los tipos de objetos a crear por medio de una
instancia prototípica, y crear nuevos objetos copiando este prototipo.
 Singleton. Garantiza que una clase sólo tenga una instancia, y
proporciona un punto de acceso global a ella.
Patrones estructurales

 Adapter. Convierte la interfaz de una clase en otra distinta que es la

que esperan los clientes. Permiten que cooperen clases que de otra
manera no podrían por tener interfaces incompatibles.
 Bridge. Desvincula una abstracción de su implementación, de manera
que ambas puedan variar de forma independiente.
 Composite. Combina objetos en estructuras de árbol para representar
jerarquías de parte-todo. Permite que los clientes traten de manera
uniforme a los objetos individuales y a los compuestos.
 Decorator. Añade dinámicamente nuevas responsabilidades a un
objeto, proporcionando una alternativa flexible a la herencia para
extender la funcionalidad.
 Facade. Proporciona una interfaz unificada para un conjunto de
interfaces de un subsistema. Define una interfaz de alto nivel que hace
que el subsistema se más fácil de usar.
 Flyweight. Usa el compartimiento para permitir un gran número de
objetos de grano fino de forma eficiente.
 Proxy. Proporciona un sustituto o representante de otro objeto para
controlar el acceso a éste.

Patrones de comportamiento

 Chain of Responsibility. Evita acoplar el emisor de una petición a su

receptor, al dar a más de un objeto la posibilidad de responder a la
petición. Crea una cadena con los objetos receptores y pasa la petición a
través de la cadena hasta que esta sea tratada por algún objeto.
 Command. Encapsula una petición en un objeto, permitiendo así
parametrizar a los clientes con distintas peticiones, encolar o llevar un
registro de las peticiones y poder deshacer la operaciones.
 Interpreter. Dado un lenguaje, define una representación de su
gramática junto con un intérprete que usa dicha representación para
interpretar las sentencias del lenguaje.
 Iterator. Proporciona un modo de acceder secuencialmente a los
elementos de un objeto agregado sin exponer su representación interna.
 Mediator. Define un objeto que encapsula cómo interactúan un
conjunto de objetos. Promueve un bajo acoplamiento al evitar que los
objetos se refieran unos a otros explícitamente, y permite variar la
interacción entre ellos de forma independiente.
 Memento. Representa y externaliza el estado interno de un objeto sin
violar la encapsulación, de forma que éste puede volver a dicho estado
más tarde.
 Observer. Define una dependencia de uno-a-muchos entre objetos, de
forma que cuando un objeto cambia de estado se notifica y actualizan
automáticamente todos los objetos.
  State. Permite que un objeto modifique su comportamiento cada vez
que cambia su estado interno. Parecerá que cambia la clase del objeto.
 Strategy. Define una familia de algoritmos, encapsula uno de ellos y los
hace intercambiables. Permite que un algoritmo varíe
independientemente de los clientes que lo usan.
 Template Method. Define en una operación el esqueleto de un
algoritmo, delegando en las subclases algunos de sus pasos. Permite
que las subclases redefinan ciertos pasos del algoritmo sin cambiar su
estructura.
 Visitor. Representa una operación sobre los elementos de una
estructura de objetos. Permite definir una nueva operación sin cambiar
las clases de los elementos sobre los que opera.

Podredumbre del software

¿Qué le pasa al software? El diseño de muchas aplicaciones comienza con

una imagen clara en la mente del diseñador. En este estado el diseño es claro,
conciso y elegante. Diseñadores y programadores desean verlo funcionar.
Algunos de estos proyectos mantienen esta pureza de diseño hasta la primera
versión.

Pero algo comienza a pasar. Al principio apenas es perceptible. Un parche

por aquí, una ñapa por allá, aunque el diseño todavía mantiene la filosofía
inicial. El software comienza a pudrirse. Las ñapas continúan y poco a poco el
software se corrompe más y más hasta llegar un punto en el que afecta a toda
la aplicación. El programa se convierte en una ingente masa de código que
cada vez es más difícil de mantener. Entonces el esfuerzo requerido para hacer
el más simple de los cambios es tal que los responsables de producto se
plantean hacer un rediseño de la aplicación.

Los rediseños normalmente no fructifican. Aunque las intenciones de los

diseñadores son buenas se dan cuenta de que es una tarea imposible. El
sistema continúa evolucionando, cambiando y el nuevo rediseño nunca
termina. Un día la cantidad de problemas vuelve a ser tal que se los
diseñadores lloran por otro rediseño.

Síntomas de un mal diseño

Hay cuatro indicios principales que nos indican que el software se está
pudriendo. No son independientes y están relacionados unos con otros, son:
rigidez, fragilidad, inmovilidad y viscosidad.

Rigidez. Es la tendencia del software a ser difícil de cambiar, incluso en

las cosas más sencillas. Cada cambio produce una cascada de cambios en
módulos dependientes. Lo que parecía un cambio de dos días en un módulo
resulta ser varias semanas de cambios de módulos tirando del hilo a través de
la aplicación.

Cuando el software toma este camino, los gestores temen decir a los
programadores que arreglen pequeños problemas que no son críticos. Esto
ocurre porque ellos no saben con seguridad cuando acabaran los
programadores. Todo el mundo hace "check-in" y nadie hace "check-out".

El miedo del gestor puede llegar a ser tan agudo que se niegue a realizar
modificaciones en la aplicación. De manera que, lo que empezó siendo un
diseño ineficiente acaba siendo una mala política de gestión.

Fragilidad. Muy relacionada con la

rigidez está la fragilidad. La fragilidad es la
tendencia que tiene el software a
romperse por muchos sitios cada vez que
se cambia algo. Muchas de las roturas
ocurren en sitios que no están
relacionados conceptualmente con el área
que se está cambiando. Cada vez que los
gestores autorizan un cambio tienen
miedo de que el programa se rompa por
algún lugar inesperado.

Conforme la fragilidad empeora, la

probabilidad de que el software se rompa
incrementa con el tiempo, acercándose
cada vez más a 1. Este software es
imposible de mantener. Cada arreglo lo
hace peor, introduciendo más problemas
de los que son solucionados.

Este software causa que los gestores

y los clientes tengan la impresión de que
los desarrolladores han perdido el control del software, perdiéndose así la
credibilidad de los desarrolladores. Y frases como "Rompes más de lo que
arreglas", comienzan a ser habituales.

Inmovilidad. La inmovilidad es la resistencia del software a ser

reutilizado en otros proyectos o parte de otros proyectos. Pasa muchas veces
que un programador descubre que necesita un módulo que es muy parecido a
otro que ha desarrollado otro programador. Sin embargo, también pasa
muchas veces que el módulo en cuestión depende demasiado de la aplicación
en la que está integrado. Después de mucho trabajo los desarrolladores
descubren que el trabajo necesario para separar las partes reutilizables de las
partes no reutilizables es demasiado alto. Y entonces el software simplemente
se rescribe en vez de ser reutilizado.
 Viscosidad. La viscosidad de diseño es la dificultad de mantener la
filosofía del diseño original. Cuando se afronta un cambio los programadores
encuentran normalmente más de una manera de realizarlo. Algunas de estas
formas preservan la filosofía del diseño y otras no. Cuando las formas de
implementar el cambio preservando el diseño son más difíciles de realizar que
las que no lo preservan, entonces la viscosidad del diseño es alta. Es fácil
hacerlo mal y difícil hacerlo bien.

Estos cuatro síntomas son reveladores de un diseño de

arquitectura pobre. Cualquier aplicación que muestra estos síntomas adolece
de un diseño pobre.

¿Qué causa que el diseño se deteriore?

Requisitos cambiantes
La causa de la degradación del diseño es muy conocida. Los requisitos han
ido cambiando de manera que no estaba previsto en el diseño inicial. A
menudo los cambios necesitan hacerse rápidamente y hechos por
programadores que no están familiarizados con el diseño original. Entonces,
aunque los cambios funcionan, violan el diseño original. Poco a poco los
cambios continúan y las violaciones se acumulan hasta que el diseño se rompe.

Aun así no podemos echar la culpa a que los requisitos cambian y

cruzarnos de brazos. Como desarrolladores, todos sabemos que los requisitos
van a cambiar. Así que debemos realizar un diseño que soporte modificaciones
sin que este pierda su consistencia.

Control de dependencias
¿Qué tipos de cambios hacen que un diseño se pudra? Los cambios que
introducen nuevas e imprevistas dependencias. Cada una de las cuatro causas
mencionadas anteriormente está relacionada directa o indirectamente con
dependencias entre módulos del software. Son las dependencias de la
arquitectura lo que se degrada y con ellas el mantenimiento del software.

Para anticiparse a la degradación de las dependencias del diseño de la

arquitectura, deben ser controladas las dependencias entre módulos de una
aplicación. Este control consiste en la creación de "cortafuegos" de
dependencias. A través de estos cortafuegos las dependencias no se propagan.

El diseño orientado a objetos está repleto de principios y técnicas que nos

permiten construir estos cortafuegos y controlar estas dependencias.

En posteriores artículos examinaremos estos principios y técnicas

(patrones de diseño) que ayudan a controlar las dependencias de la
arquitectura.