Modelo de Madurez de la Capacidad (CMM)

Marco estándar de referencia para evaluar el nivel de madurez del desarrollo de sistemas de
información de una organización y sus procesos y productos administrativos. Consiste en cinco
niveles de madurez.

Nivel 1, Inicial. Esto a veces es llamado anarquía o caos. En este nivel, los proyectos de desarrollo
de sistemas no siguen un proceso consistente. Cada equipo de desarrollo utiliza sus propias
herramientas y métodos. El éxito o el fracaso generalmente es una función de la habilidad y
experiencia del equipo. El proceso es impredecible y no es repetible.

Nivel 2, Repetible. En este nivel los procesos y las prácticas de administración de proyectos están
establecidos para rastrear costos, programas y funcionalidad del proyecto. El enfoque está en la
administración del proyecto. Un proceso de desarrollo de sistemas se sigue siempre, pero puede
variar de proyecto a proyecto. El éxito o el fracaso está todavía en función de la habilidad y
experiencia del equipo del proyecto; sin embargo, se hace un esfuerzo concertado por repetir
éxitos de proyectos anteriores.

Nivel 3, Definido. En este nivel se adquiere o se desarrolla un proceso de desarrollo de sistemas

estándar (a veces llamado metodología). Todos los proyectos utilizan una versión personalizada
de este proceso para desarrollar y mantener sistemas de información y software. Como
resultado de utilizar el proceso estandarizado para todos los proyectos, cada proyecto resulta
en documentación y productos consistentes y de alta calidad. El proceso es estable, predecible
y repetible.

Nivel 4, Administrado. En este nivel se establecen metas mensurables para la calidad y la

productividad. Las mediciones detalladas del proceso de desarrollo de sistemas estándar y la
calidad del producto se recolectan y almacenan rutinariamente en una base de datos. Hay un
esfuerzo por mejorar la administración de proyectos individuales basado en estos datos
recopilados.

Nivel 5, Optimizado. En este nivel el proceso de desarrollo del sistema estandarizado es vigilado
continuamente y mejorado con base en medidas y análisis de datos establecidos en el nivel 4.
Esto puede incluir cambiar la tecnología y las mejores prácticas utilizadas para realizar
actividades requeridas en el proceso estándar de desarrollo del sistema, así como ajustar el
proceso mismo.

Ciclo de vida del sistema

El ciclo de vida de un sistema de información se divide en dos etapas: 1) desarrollo de sistemas,

y 2) operación y mantenimiento de sistemas; primero se construye y, luego se usa y se mantiene.
Tarde o temprano el ciclo culmina con el desarrollo de un nuevo sistema.

Principios fundamentales para el desarrollo de sistemas

Principio 1: Hacer participar a los usuarios del sistema

Principio 2: Utilizar un método de solución de problemas

El método clásico de solución de problemas es el siguiente:

1. Estudiar y entender el problema, su contexto y su impacto.

2. Definir los requerimientos que deben satisfacerse para alcanzar una solución.
3. Identificar alternativas de soluciones que satisfagan los requerimientos y elegir la mejor
solución.

4. Diseñar y/o implantar la solución elegida.

5. Observar y evaluar el impacto de la solución y depurarla.

Principio 3: Establecer fases y actividades

Principio 4: Documentar a través del desarrollo

Principio 5: Establecer estándares

Principio 6: Administrar el proceso y los proyectos

Principio 7: Justificar sistemas de información como inversiones de capital

Principio 8: No tema cancelar o revisar el alcance

Principio 9: Divida y vencerá

Principio 10: Diseñar sistemas para crecimiento y cambio

¿De dónde surgen los proyectos de desarrollo de sistemas?

Hay demasiados problemas potenciales de sistemas para listarlos todos en este texto. Sin
embargo, James Wetherbe desarrolló un marco de referencia útil para clasificar problemas. Él
le llama PIECES debido a las letras en inglés de cada una de las seis categorías, que cuando se
unen, deletrean la palabra “pieces” (significa “piezas”). Las categorías son:

P (performance) la necesidad de corregir o mejorar el desempeño

I (information) la necesidad de corregir o mejorar la información (y datos)

E (economics) la necesidad de corregir o mejorar la economía, controlar costos o aumentar las

utilidades.

C (control) la necesidad de corregir o mejorar el control o la seguridad.

E (eficiency) la necesidad de corregir o mejorar la eficiencia de las personas y los procesos.

S (service) la necesidad de corregir o mejorar el servicio a clientes, proveedores, socios,

empleados y demás.

Las fases del proyecto FAST

Definición de alcance La primera fase de un proyecto típico es la DEFINICIÓN DE ALCANCE. El

propósito de la fase de definición de alcance es de dos sentidos. Primero, responde la pregunta,
“¿vale la pena atender este problema?”. Segundo y suponiendo que el problema vale la pena,
establece el tamaño y las fronteras del proyecto, la visión del proyecto, cualquier restricción o
limitación, los participantes requeridos del proyecto y finalmente, el presupuesto y el programa.

Análisis del problema Siempre hay un sistema existente, sin importar si actualmente utiliza
tecnología de la información. La fase del ANÁLISIS DEL PROBLEMA estudia el sistema existente
y analiza los resultados que proporciona al equipo del proyecto con una comprensión más
completa de los problemas que dispararon el proyecto. El analista con frecuencia descubre
nuevos problemas y responde la pregunta más importante, “¿los beneficios de solucionar estos
problemas exceden los costos de construir el sistema para resolver estos problemas?”

Análisis de requerimientos Dada la aprobación del propietario para continuar la fase de análisis
del problema, ahora usted puede diseñar un nuevo sistema, ¿correcto? ¡No, aún no! ¿Qué
capacidades debe proporcionar el nuevo sistema para sus usuarios? ¿Qué datos deben ser
capturados y almacenados? ¿Qué nivel de desempeño se espera? ¡Cuidado! Esto requiere
decisiones acerca de lo que el sistema debe hacer, no cómo debe hacerlo. La fase de ANÁLISIS
DE REQUERIMIENTOS define y prioriza los requerimientos del negocio. Dicho de manera simple,
el analista se aproxima a los usuarios para averiguar lo que necesitan o requieren del nuevo
sistema, al evitar cuidadosamente cualquier discusión de tecnología o implantación técnica. Ésta
es tal vez la fase más importante del desarrollo de sistemas. Errores y omisiones en el análisis
de requerimientos resultarán en la insatisfacción del usuario con el sistema final y
modificaciones costosas.

Diseño lógico Los requerimientos del negocio (antes mencionados) generalmente son
expresados en palabras. Los analistas del sistema han encontrado que es útil traducir esas
palabras en imágenes llamadas modelos de sistemas para validar los requerimientos con el fin
de que estén completos y sean consistentes. (La figura 3.5 es un ejemplo de un modelo de
sistemas común llamado diagrama de flujo de datos.) La elaboración de modelos de sistemas es
un concepto eterno: “Una imagen vale más que mil palabras”.

Análisis de decisión Dados los requerimientos de negocios y los modelos de sistema lógicos,
normalmente hay diversas alternativas para diseñar un nuevo sistema de información que
satisfagan esos requerimientos. Algunas de las preguntas pertinentes incluyen lo siguiente:

• ¿Qué tanto del sistema debe ser automatizado con tecnología de la información?

• ¿Debemos comprar software o construirlo nosotros (llamado decisión de comprar o

desarrollar)?

• ¿Debemos diseñar el sistema para una red interna o debemos diseñar una solución basada en
la Web?

• ¿Qué tecnologías de información (posiblemente en surgimiento) podrían ser útiles para esta
aplicación?

Diseño físico e integración Dada la aprobación de la PROPUESTA DEL SISTEMA de la fase de

análisis de decisión, al fin, usted puede diseñar el nuevo sistema. El propósito de la fase de
DISEÑO FÍSICO E INTEGRACIÓN es transformar los requerimientos de negocios (representados
en parte por los MODELOS LÓGICOS DEL SISTEMA) en las ESPECIFICACIONES DE DISEÑO FÍSICO
que guiarán la construcción del sistema. En otras palabras, el diseño físico aborda con mayor
detalle el cómo la tecnología será utilizada en el nuevo sistema. El diseño será restringido por el
MODELO DE ARQUITECTURA desde la fase anterior. También, el diseño requiere apegarse a
cualquier estándar de diseño técnico interno que asegure que sea completo, útil, confiable, con
buen desempeño y calidad.

Construcción y pruebas Dado algún nivel de MODELOS Y ESPECIFICACIONES DE DISEÑO FÍSICO

(o PROTOTIPOS DE DISEÑO), podemos comenzar a construir y probar los componentes del
sistema para ese diseño. En la figura 3.5 se muestra que el producto primario de la fase de
PRUEBA Y CONSTRUCCIÓN es un SISTEMA FUNCIONAL que está listo para implantación. El
propósito de la construcción y la fase de pruebas es doble: 1) Construir y probar un sistema que
satisfaga los requerimientos de negocios y las especificaciones de diseño físico, y 2) implantar
las interfaces entre el nuevo sistema y los sistemas existentes.

Instalación y entrega ¿Qué queda por hacer? Los nuevos sistemas normalmente representan
un resultado de la forma en que los negocios se hacen hoy, por lo tanto, el analista debe
proporcionar una transición suave del viejo sistema al nuevo y ayudar a los usuarios a lidiar con
los problemas normales de inicio. Por tanto, la fase de INSTALACIÓN Y ENTREGA sirve para
entregar el sistema en operación (a veces llamado producción).

Operación del sistema y mantenimiento Una vez que el sistema esté puesto en operación,
requerirá un soporte del sistema continuo para el resto de su vida útil y productiva. El soporte
de sistemas consiste en las siguientes actividades continuas:

• Ayuda a usuarios. Sin importar qué tan bien hayan sido capacitados los usuarios y qué tan
completa y clara sea la documentación del usuario final, eventualmente los usuarios requerirán
ayuda adicional conforme surjan los problemas no anticipados, se agreguen nuevos usuarios y
demás.

• Arreglar los defectos de software. Los defectos de software son errores que se pasaron por
alto en las pruebas del software. Éstos son inevitables, pero normalmente pueden ser resueltos,
en la mayoría de los casos, con el soporte de un experto.

• Recuperación del sistema. Ocasionalmente, una falla del sistema puede resultar en un
“colapso” de sistema y/o pérdida de datos. Los errores humanos o fallas en el hardware y el
software pueden ocasionar esto. El analista de sistemas o los especialistas de soporte técnico
pueden ser llamados para recuperar el sistema, es decir, restablecerlos archivos y bases de datos
del sistema y reiniciarlo.

• Adaptar el sistema a requerimientos nuevos. Los requerimientos nuevos pueden ser nuevos
problemas de negocios, nuevos requerimientos de negocios, nuevos problemas técnicos o
nuevos requerimientos de tecnología.

Actividades transversales del ciclo de vida

Identificación de hechos Hay muchas ocasiones para una identificación de hechos durante un
proyecto. La identificación de hechos es más crucial para las primeras fases de un proyecto. Es
durante estas fases que el equipo de proyecto aprende acerca del vocabulario del negocio, los
problemas, oportunidades, restricciones, requerimientos y prioridades. Pero la identificación de
hechos también se utiliza durante las fases de análisis de decisión, diseño físico, construcción y
pruebas e instalación y entrega, sólo que a un menor grado. Es durante estas últimas fases que
el equipo de proyecto investiga alternativas técnicas y solicita una retroalimentación acerca de
los diseños técnicos, estándares y componentes de trabajo.

Documentación y presentación Las habilidades de comunicación son esenciales para el

cumplimiento exitoso de cualquier proyecto. De hecho, una mala comunicación con frecuencia
es citada como la principal causa de retrasos de proyectos y repetición del trabajo. Dos formas
de comunicación que son comunes en los proyectos de desarrollo de sistemas son la
documentación y la presentación.

Análisis de factibilidad En consistencia con nuestro enfoque de compromiso ajustado al

desarrollo de sistemas, el análisis de factibilidad es una actividad transversal del ciclo de vida.
Diferentes mediciones de factibilidad son aplicables a distintas fases de la metodología. Estas
mediciones incluyen factibilidad técnica, operacional, económica, de programa y de riesgo,
como se describió cuando presentamos la fase de análisis de decisión. El análisis de factibilidad
requiere buenas técnicas de estimación.

Administración de proyecto y de proceso Recuerde que CMM considera el desarrollo de

sistemas como un proceso que debe ser manejado de proyecto en proyecto. Por ésta y otras
razones, la administración de proceso y la administración de proyecto son actividades continuas,
transversales del ciclo de vida. Ambos tipos de administración se presentaron anteriormente,
pero sus definiciones se repiten en el margen de esta página y en el margen de la página 72 para
su conveniencia. La administración de proceso define la metodología que se utilizará en cada
proyecto, piense en ella como la receta para construir un sistema.