1. MODULO 1.
FUNDAMENTOS PARA EL DESARROLLO DE
PROYECTOS INFORMÁTICOS1
Alejandro Domínguez Torres, jadoming@mail.unitec.mx, www.unitec.mx
INTRODUCCIÓN
La industria de la informática ha desarrollado nuevos métodos para administrar la
creciente complejidad de los proyectos informáticos. En el pasado hubo varias
evoluciones, revoluciones y temas recurrentes de éxito y fracaso.
En el presente, el éxito de los proyectos informáticos depende de encontrar un equilibrio
de cinco componentes principales: Personas, Información, Procesos, Herramientas y
Productos/Servicios. Los cinco componentes son importantes al momento de desarrollar
cualquier proyecto informático. Por varios años, dos de estos elementos han sido
explorados en detalle. Estos dos componentes son: Personas y Procesos.
Las personas y los procesos requieren tener un canal conductor que permita la
comunicación entre varios de sus elementos componentes, así como entre ellos. Sin la
comunicación no existe forma alguna de desarrollar cualquier proyecto informático.
El estudio y descripción de la relación y equilibrio de estos cinco componentes, poniendo
especial atención en las Personas y los Procesos, así como en la comunicación como
integrador del desarrollo de proyectos, son los propósitos de este primer modulo.
La Sección 1 discute el desarrollo de proyectos informáticos como parte de la entrega de
las funciones y los servicios informáticos, presenta a los cinco elementos del desarrollo
de proyectos informáticos como fundamento para la especificación de prácticas y
procedimientos normalizados, y muestra la relación entre los elementos y cómo los
cambios en un elemento afectan a los otros.
La Sección 2 aborda a los componentes Procesos y Personas y discute dos modelos para
el éxito del desarrollo de proyectos. Estos modelos son el “Software Capability Maturity
Model (S-CMM: Modelo de Madurez de la Capacidad de Software)” y “People
Capability Maturity Model (P-CMM: Modelo de Madurez de la Capacidad de las
Personas). Ambos generados por el Software Engineering Institute (SEI).
Finalmente, la Sección 3 discute dos tópicos principales: los elementos de un plan de
comunicación y algunas estrategias de comunicación.
1
Desarrollo y gestión de proyectos informáticos. Curso a distancia. Centro Interamericano de Estudios de
Seguridad Social. Septiembre de 2003.
Página 1 de 39

2. OBJETIVOS
 Analizar los cinco elementos fundamentales para el desarrollo de proyectos
informáticos como fundamento para la especificación de prácticas y
procedimientos normalizados, así como analizar la relación entre los elementos.
 Analizar las dos normas internacionales para el desarrollo de proyectos asociadas
a las Personas y a los Procesos.
 Analizar la importancia de la comunicación en el desarrollo de proyectos.
PALABRAS CLAVE
Desarrollo de proyectos informáticos Nivel de madurez
Personas Capacidad de procesos de software
Información Áreas de procesos clave
Procesos Metas
Herramientas Características comunes
Producto/Servicio Prácticas clave
Modelo de Madurez de la Capacidad de Software Plan de comunicaciones
Modelo de Madurez de la Capacidad de las
Estrategias de comunicación
Personas
CONTENIDO
1. Elementos básicos para el desarrollo de proyectos informáticos
2. Los Modelos de Madurez de la Capacidad
3. El proceso de comunicación dentro de un proyecto informático
ACTIVIDAD DE EVALUACIÓN
Considerar el estado actual de una organización; ésta puede ser en la que se labora o
cualquier otra (esta organización debe desarrollar aplicaciones de software).
Utilizando la Tabla siguiente, evaluar esa organización con el fin de conocer la distancia
que la separa del nivel 2 del S-CMM.
Página 2 de 39

3. KPAs del Nivel Repetible Meta 1 Meta 2 Meta 3 Meta 4
Casilla Casilla
Administración de requerimientos
inválida inválida
Casilla
Planeación del proyecto
inválida
Casilla
Supervisión y vigilancia del proyecto
inválida
Administración de subcontratos de software
Aseguramiento de la calidad del software
Administración de la configuración
Cumplimiento Total No Cumple
No Aplicable No Evaluado
Una vez que se haya analizado la situación de la organización, evaluar cada meta y
redactar (en MSWord) una justificación para cada una. Cada justificación debe ser clara,
concisa y menor o igual a media página.
El documento que se genere debe tener la siguiente estructura:
 Portada o página de presentación, indicando los siguientes datos: nombre
completo, dirección de correo electrónico, ciudad, país, nombre del documento, y
fecha de creación
 Página de resumen (no más de 200 palabras)
 Antecedentes de la organización donde se aplicará la evaluación. Debe contener
información para conocer el tipo de organización que se está evaluando.
 La evaluación y su justificación
 Para cada “No Cumple”, indicar cómo proceder para cambiar ésta a
“cumplimiento total”; es decir, indicar cómo resolver el problema (de nueva
cuenta, la solución para cada “No Cumple” debe ser menor o igual a una media
página)
 Conclusiones (propias y originales)
Página 3 de 39

4. MODULO 1.
FUNDAMENTOS PARA EL DESARROLLO DE
PROYECTOS INFORMÁTICOS
1 ELEMENTOS BÁSICOS PARA EL DESARROLLO DE
PROYECTOS INFORMÁTICOS
RESUMEN
Esta sección presenta algunos lineamientos útiles para desarrollar proyectos informáticos
tal como se muestra en la siguiente Tabla.
Tabla 1. Organización y presentación de los lineamientos para el desarrollo de proyectos.
SUBSECCIÓN RESUMEN DE LA SUBSECCIÓN
1.2 DESARROLLO DE PROYECTOS Discute el desarrollo de proyectos informáticos como parte de la
INFORMÁTICOS entrega de servicios y funciones informáticos
1.3 ELEMENTOS PARA EL Presenta los cinco elementos principales para el desarrollo de
DESARROLLO DE proyectos informáticos como fundamento para la especificación de
PROYECTOS INFORMÁTICOS practicas y procedimientos normalizados
1.4 LA RELACIÓN DE LOS CINCO Muestra la relación entre los elementos y cómo los cambios en un
ELEMENTOS elemento afectan a los otros
1.1 EL DESARROLLO DE PROYECTOS INFORMÁTICOS
La informática está presente en todos los aspectos empresariales. Sin embargo, si las
metas empresariales deben cumplirse, los procesos de selección, diseño e implementación
de las soluciones informáticas tienen que ser desarrolladas por un conjunto
cuidadosamente diseñado de estrategias y procedimientos. Esta es la esencia del
desarrollo de proyectos informáticos.
El desarrollo de proyectos informáticos consiste de un conjunto de procesos estructurados
que sirven para alcanzar una salida específica y única en un periodo de tiempo definido y
acotado. Las salidas exitosas son más frecuentes cuando un proyecto informático está
definido, diseñado, implementado y controlado de forma apropiada.
Los proyectos informáticos pueden ser de diferentes tipos y tamaños, algunos de ellos se
enuncian en la siguiente Tabla.
Página 4 de 39

5. Tabla 2. Algunos proyectos informáticos y su descripción.
TIPO DE PROYECTO
DESCRIPCIÓN
INFORMÁTICO
ESTUDIOS DE La evaluación de la informática y su uso en una organización, incluyendo la
FACTIBILIDAD selección de soluciones informáticas y recomendaciones para estrategias futuras
DESARROLLO DE LA El diseño, pruebas, integración e implementación de aplicaciones informáticas
INFORMÁTICA personalizadas, así como de las plataformas e interfaces relacionadas
ACTUALIZACIÓN DE La actualización de las plataformas, soluciones y productos informáticos
LA INFORMÁTICA existentes
MIGRACIÓN DE LA El reemplazo y/o retiro de plataformas y soluciones informáticas existentes,
INFORMÁTICA frecuentemente reemplazadas por diferentes productos
La participación de la informática como un agente de cambio; así como en
SERVICIOS DE APOYO renovaciones departamentales, reubicaciones, fusiones organizacionales,
programas de capacitación, y reorganizaciones internas
Relacionada con la mejora y entrega del servicio de la informática, incluye
ADMINISTRACIÓN DE
procesos de reingeniería informática, mantenimiento, auditorías de seguridad, y
LA INFORMÁTICA
documentación de proyectos
Sin embargo, la lista no finaliza aquí, ya que cuando una solución informática es
seleccionada e instalada, se le debe dar mantenimiento y soporte técnico. Más aún, la
rápida evolución de los cambios tecnológicos provoca la implementación de ciclos de
mejora, actualización y renovación.
Sin importar que la meta del desarrollo informático sea el diseño, instalación, o
reingeniería, las iniciativas informáticas son a menudo conducidas por fechas fijas y
periodos de cambios frecuentes. Para alcanzar las metas, los recursos deben estar
identificados y asignados, y las actividades deben estar organizadas y estructuradas de
forma apropiada de acuerdo con los requerimientos empresariales e informáticos.
No obstante, considerando la diversidad de soluciones informáticas disponibles, aplicadas
dentro de un rango amplio de entornos empresariales y profesionales, el desarrollo de
proyectos informáticos no es una tarea fácil, por ejemplo:
 A menudo, la funcionalidad informática no es la deseada debido a problemas
técnicos;
 Existe una tolerancia limitada a los tiempos fuera de servicio, la cual puede
complicar enormemente la implementación de actualizaciones y migraciones de
plataformas.
De esta forma, las cotas existentes entre los proyectos informáticos y las operaciones
diarias empañan los esfuerzos de desarrollo informático, creando así retos de desarrollo
únicos.
Se pueden utilizar las mejores prácticas para el desarrollo de proyectos informáticos y así
enfrentar estos retos. Considerando la necesidad de calidad consistente y entrega a
tiempo, las prácticas diseñadas para mostrar desempeño y productividad deben ser la
apropiadas, a condición de que las prácticas no sobrepasen el propósito deseado.
Página 5 de 39

6. Como en cualquier otra disciplina, el desarrollo de proyectos informáticos debe ponerse
en la perspectiva organizacional. Para efectuar un desarrollo efectivo de proyectos
informáticos se debe tener:
 Políticas y procedimientos definidos para la selección, definición, diseño y control
de los proyectos;
 Apoyo administrativo comprometido;
 Personal capacitado y comprometido;
 Un entorno que fomente el trabajo en equipo y la cooperación;
 Fuertes capacidades técnicas;
 Una comprensión de las metas y objetivos empresariales;
 Las herramientas informáticas apropiadas que se ajusten a los requerimientos y
capacidades técnicas del proyecto;
 La autoridad para aplicar y actualizar las prácticas de administración de proyectos
informáticos cuando sea necesario.
Muchas organizaciones enfrentan diversos tipos de proyectos informáticos, cada uno con
su propio grado de dificultad, urgencia y prioridad. Las mejores prácticas para el
desarrollo de proyectos informáticos agregan estructura y definición a este caos. Al ser
aplicadas, influyen en las decisiones y actividades. La velocidad, creatividad, e
innovación encuentran un lugar dentro de un ambiente de normas, reglas, formatos y
plantillas.
El éxito del proyecto es más factible cuando los entregables requeridos se producen en
tiempo y dentro de presupuesto. Más aún, para ser verdaderamente exitoso, los proyectos
informáticos deben tener:
 Planes reales y funcionales;
 Fuerte compromiso administrativo;
 Monitoreo y supervisión adecuada;
 Análisis efectivo de riesgos;
 Fuertes justificaciones empresariales;
 Control de costos;
 Diseño técnico y planes de implementación consistentes;
 Expectativas reales;
 Equipos de trabajo sólidos.
Para generar resultados exitosos sobre una base consistente, se deben definir y aplicar
normas y mejores prácticas realistas y funcionales. Estas normas deben estar alineadas
con los requerimientos organizacionales, capacidades internas, y características de los
proyectos.
Página 6 de 39

7. 1.2 LOS ELEMENTOS DEL DESARROLLO DE PROYECTOS
INFORMÁTICOS
Cualquier proyecto informático contiene cinco elementos principales: Personas, Procesos,
Producto/Servicio, Información, y Herramientas. El desarrollo exitoso de proyectos
informáticos requiere que estos elementos estén en equilibrio. Equilibrar los elementos
implica observar quién está tratando de hacer qué, por lo que resulta importante
reflexionar acerca de los elementos desde el inicio del desarrollo del proyecto.
1.2.1 PERSONAS
El elemento primario de cualquier proyecto informático es las Personas:
 Las Personas recolectan requerimientos;
 Las Personas entrevistan a los usuarios (Personas);
 Las Personas diseñan la informática para las Personas;
 Sin Personas no existiría la informática.
Lo mejor que puede ocurrir en cualquier proyecto informático es tener:
 Personas que conozcan lo que estén haciendo y tener la voluntad y la
autodisciplina para hacerlo;
 Personas con conocimiento para hacer lo correcto y evitar lo que no lo está;
 Personas responsables para decir la verdad, aunque otras deseen escuchar algo
diferente;
 Personas disciplinadas para trabajar en los proyectos y no para sabotearlos.
Un desarrollo de proyectos exitoso requiere que el equipo del proyecto participe en el
proceso de diseño y sea responsable del cumplimiento de las tareas.
Es importante definir una organización formal del proyecto y del personal que participa
en él. Esto provee a cada persona una clara comprensión de su compromiso y de la
responsabilidad necesaria para el cumplimiento exitoso de las actividades del proyecto.
Los miembros del equipo del proyecto deben ser responsables del desarrollo efectivo de
sus tareas.
Las estructuras organizacionales del proyecto pueden ser diversas, aunque su impacto
sólo pueda verse durante el desarrollo del proyecto. Por ejemplo:
 En proyectos grandes, las tareas asignadas pueden requerir la totalidad del tiempo
del personal;
 En proyectos pequeños, las tareas asignadas pueden requerir solo una parte del
tiempo del personal, el cual puede tener otras funciones de forma paralela.
El equipo del proyecto debe estar compuesto por personas con diferentes habilidades.
Este equipo debe contener al menos el siguiente personal:
Página 7 de 39

8.  Personal responsable de la implementación de la solución del proyecto (equipo
del proyecto):
o Personal para el desarrollo de los requerimientos;
o Personal para las especificaciones de las reglas de negocios;
o Personal para la administración del proyecto;
o Expertos en áreas propias del proyecto;
o Personal responsable de la documentación de los usuarios y la técnica;
o Personal para capacitar;
o Personal técnico;
o Líderes o tomadores de decisiones;
 Clientes (tanto internos como externos) para el producto/servicio a desarrollar;
 Patrocinador del proyecto;
 Actores en el proyecto.
Los actores en el proyecto son personas y organizaciones que tienen interés en el éxito
del proyecto. La identificación e insumos de los actores ayudan a definir, clarificar,
conducir, cambiar y contribuir en la determinación del alcance del proyecto, y por ende
en su éxito.
Para asegurar el éxito del proyecto, el equipo necesita identificar a los actores desde su
concepción, determinar sus requerimientos y expectativas, y administrar e influenciar
esas expectativas en el curso del proyecto.
El conjunto de actores del proyecto incluye a las siguientes personas (ver Tabla
siguiente):
Tabla 3. Responsabilidades de los actores.
ACTOR RESPONSABILIDAD
ADMINISTRADOR DEL PROYECTO Responsable total del éxito del proyecto
Responsable de hacer ver la necesidad del proyecto y, posiblemente,
PATROCINADOR DEL PROYECTO
de proveer los recursos financieros
ADMINISTRADOR Responsable administrativo del proyecto
MIEMBROS DEL EQUIPO DEL
Responsables de ejecutar las tareas requeridas por el proyecto
PROYECTO
ADMINISTRADORES DE LA Responsables de administrar la configuración del proyecto y
CONFIGURACIÓN mantenerlo dentro de sus fronteras
EQUIPO DE ASEGURAMIENTO DE Responsable de verificar que el producto/servicio cumple con los
LA CALIDAD requerimientos
PERSONAL DE ADQUISICIONES Responsable de adquirir los recursos del proyecto
CLIENTE Responsable de utilizar el producto/servicio del proyecto
Página 8 de 39

9. 1.2.2 PROCESOS
Los procesos son el “cómo” las personas ejecutan las tareas desde el inicio hasta el fin del
proyecto. Todos los proyectos utilizan al menos un proceso. Sin embargo, muchos
administradores de proyectos informáticos no eligen un proceso basado en las personas y
en el producto/servicio del proyecto en cuestión: simplemente utilizan el mismo proceso
que siempre han utilizado sin importar si es el apropiado.
Los procesos siempre deben estar sujetos a mejora y ser los apropiados (ver Tabla):
Tabla 4. Mejora y conveniencia de los procesos.
ENUNCIADO DESCRIPCIÓN
MEJORA DE LOS  Es la clave para incrementar la habilidad para generar el producto/servicio
PROCESOS  Debe existir un proceso previo antes de que exista una mejora
 Existen varios modelos de procesos de gran utilidad
 Dos de estos modelos son el “Software Capability Maturity Model (S-CMM)”
CONVENIENCIA DE y el “Capability Maturity Model for People (P-CMM)”
LOS PROCESOS  El S-CMM y el P-CMM tienen una serie de niveles a través de los cuales una
organización puede progresar de un nivel caótico o inicial (nivel 1) hasta un
nivel optimizado (nivel 5) (ver la Sección 2 para mayores detalles)
1.2.3 PRODUCTO/SERVICIO
El producto/servicio es el resultado del proyecto por lo que debe satisfacer a los clientes.
Sin embargo, algunas veces no lo satisface del todo.
Es importante señalar que el producto/servicio es la razón por la cual se obtienen
remuneraciones económicas, así que es necesario no perderlo de vista, aún cuando el
proceso requiera toda la atención. Si se pierde de vista, el resultado es un
producto/servicio inapropiado, no existencia de recursos económicos, falta de
oportunidades de negocio y despidos del personal.
En lugar de discutir los diferentes tipos de productos/servicios (sistemas de cómputo,
redes de voz y datos, etc.), en lo sucesivo la discusión se centrará en otros dos aspectos de
los productos/servicios:
 La dificultad inherente;
 La calidad interna y externa.
La dificultad del producto/servicio repercute en el proceso requerido para desarrollarlo.
La “dificultad” es subjetiva y depende de la familiaridad de las personas con el
producto/servicio. Por ejemplo, para algunas personas desarrollar un editor de texto es
difícil, mientras que para otras desarrollar un analizador de imágenes es sencillo.
Página 9 de 39

10. Una forma de determinar la “dificultad” de un producto/servicio y el tipo de procesos
requerido es responder a las siguientes preguntas:
 ¿El producto/servicio es conocido o nuevo?
 ¿En novedoso?
 ¿La interfaz del usuario requiere de precisión?
Los productos/servicios difíciles demandan modelos de procesos que permitan
experimentar y aprender. Los productos/servicios fáciles por lo general requieren
modelos sencillos, directos y eficientes. Los productos/servicios difíciles son fáciles si se
cuenta con personas conocedoras de los mismos.
Por otro lado, es importante mantener en mente la calidad externa e interna del
producto/servicio. La calidad externa es lo que el cliente ve. El cliente está satisfecho si
el producto/servicio cumple con todos sus requerimientos funcionales, es fácil de
aprender, se ejecuta de forma rápida y no demanda muchos recursos para operar.
La calidad interna es lo que el desarrollador ve. Una alta calidad interna indica, entre
otras cosas, que el diseño es fácil de comprender y el resultado está acorde a las
especificaciones del cliente. Cuando el cliente solicita cambios en la plataforma
informática, una alta calidad interna permite llevar a cabo los cambios en el
producto/servicio de forma rápida y sencilla.
Estos factores de calidad también influyen en las personas y en los procesos. Por ejemplo,
si la portabilidad (calidad interna) es importante, en el desarrollo deben participar
personas expertas en varias plataformas informáticas. El no contar con estas personas,
elevará el número de riesgos para desarrollar el proyecto.
1.2.4 INFORMACIÓN
La información es esencial para la operación, desarrollo y organización de un proyecto.
Con el propósito de comprender la naturaleza de la información, es importante
comprender los propósitos para los que se provee. Sin embargo, el propósito primario de
la información es ayudar a la toma de decisiones.
La estimación del valor de la información es un área difícil. En algunos casos una medida
cuantitativa puede ser útil si se desea medir la rapidez con que se provee, como en el
control de deudas, o en la reducción de la incertidumbre. Sin embargo, en estos casos el
beneficio es intangible. Es difícil, sino imposible, analizar las contribuciones de una
información más efectiva para una mejor toma de decisiones, o más aún, aislar el impacto
de disponer mayor información para conocer cómo los clientes hacen sus compras. Es un
gran error ignorar los beneficios intangibles y no medibles que provee la información a
una organización.
Finalmente, es importante hacer notar que el desarrollo de proyectos informáticos se basa
en la información disponible, ya sea ésta formal o informal (ver la Tabla y Figura
siguientes):
Página 10 de 39

11. Tabla 5. Información formal e informal.
TIPO DE INFORMACIÓN CARACTERÍSTICAS
Es producida por procedimientos normalizados, es objetiva y por lo general
INFORMACIÓN FORMAL
es considerada como relevante para la toma de decisiones
A menudo es subjetiva, se pasa de boca en boca; y comprende contracciones,
INFORMACIÓN INFORMAL opiniones, interpretaciones, y rumores; además comprende información
explicativa y/o evaluativa
Información formal: cuantitativa,
producida por reglas conocidas, objetiva
Información informal: cualitativa,
no producida por reglas conocidas, subjetiva
Figura 1. Información formal e informal.
1.2.5 HERRAMIENTAS
Las herramientas para el desarrollo de proyectos son los medios por los cuales los
procesos se convierten en realidad. A través del uso de software, plantillas, capacitación y
sistemas de comunicación, se les da forma y fondo a las directivas de los procesos (ver la
siguiente Tabla). Como resultado, estas herramientas son la parte tangible de que los
compromisos de desarrollo del proyecto se pueden llevar a la práctica.
Tabla 6. Herramientas para el desarrollo de proyectos.
HERRAMIENTA PROPÓSITO
SOFTWARE Automatizar las actividades de administración del proyecto
PLANTILLAS Documentar las actividades del proyecto
CAPACITACIÓN Educar a personal y a los usuarios finales
SISTEMAS DE COMUNICACIÓN Compartir el conocimiento, la información y el estado del proyecto
Antes de elegir las herramientas e integrarlas dentro del programa de normas del
proyecto, se deben tomar en cuenta ciertos criterios clave (ver la siguiente Tabla). Estos
criterios forman un conjunto útil para la evaluación y selección de las herramientas para
el desarrollo de los proyectos.
Página 11 de 39

12. Tabla 7. Criterios para la evaluación y selección de herramientas para el desarrollo de los proyectos.
CRITERIO DESCRIPCIÓN
¿Qué es lo que el producto/servicio lleva a cabo y qué papel juegan el
OBJETIVOS DEL DESARROLLO
software, la capacitación, las plantillas y la comunicación en la entrega y
DEL PROYECTO
ejecución del producto/servicio?
Las herramientas de software deben estar acorde a las características y
CARACTERÍSTICAS DEL
requerimientos del proyecto, incluyendo su tamaño, duración,
PROYECTO Y
complejidad de las tareas, reportes, asignación de recursos y necesidad
ORGANIZACIONALES
de administrar varios proyectos en la organización
Se deben considerar las capacidades y características del entorno técnico
actual. Entre las que se encuentran el acceso a Internet, acceso a la
CAPACIDAD TÉCNICA Intranet, poder de computo, acceso a impresoras, conectividad a redes
LAN/WAN, acceso a correo electrónico y la habilidad de compartir
datos con proveedores de servicio externos y teleconmutadores
Para lograr compatibilidad técnica total, es necesario poseer información
COMPATIBILIDAD CON LAS
detallada de las configuraciones de las plataformas, las capacidades y
PLATAFORMAS TECNOLÓGICAS
limitaciones estructurales, así como de los requerimientos respectivos de
ACTUALES
los productos y conjuntos de herramientas a considerar
El desarrollo de proyectos informáticos requiere de cierto
HABILIDADES DEL PERSONAL Y
mantenimiento y administración. Estos requerimientos deben
DISPONIBILIDAD DE RECURSOS
considerarse al evaluar las habilidades y disponibilidad de los recursos
Al seleccionar las herramientas para el desarrollo del proyecto, se deben
COSTOS DE LAS COMPRAS Y EL
tomar en cuenta los costos asociados a las pruebas, la evaluación, la
MANTENIMIENTO
adquisición, el desarrollo, la implementación y el mantenimiento
1.3 LA RELACIÓN ENTRE LOS CINCO ELEMENTOS
Las Figuras 2 a 5 muestran una visión gráfica integral de los cinco elementos. La Figura
2 muestra una situación de equilibrio entre los elementos (pentágono equilátero):
Situación deseable en cualquier desarrollo de proyectos. La región pentagonal muestra la
dificultad del desarrollo de un producto/servicio. Obviamente, es más fácil construir
productos/servicios que se encuentren cerca del centro del pentágono puesto que son
menos complejos. Los productos/servicios sencillos no requieren de toda la capacidad de
los otros cuatro elementos. Si el producto/servicio se aleja del centro, es más complejo y
demanda más recursos de los elementos complementarios.
Personas
Producto/Servicio Información
Herramientas Procesos
Figura 2. Relación de los cinco elementos: Equilibrio.
Página 12 de 39

13. Las Figuras 3 a 5 muestran que la capacidad necesaria para construir un producto más
complejo puede provenir de diversas combinaciones de mejora en las personas. El
producto/servicio en cada una de las tres figuras tiene la misma complejidad. En cada una
de ellas, el producto/servicio la complejidad se mueve de un nivel bajo a uno más alto. En
la Figura 3, la capacidad necesaria proviene de las personas. Esta capacidad extra se
puede lograr agregando algunos expertos o capacitando al personal. La Figura 4 muestra
que la misma cantidad de capacidad extra puede provenir de una mejora de los procesos
en lugar de las personas. Una forma de agregar esta capacidad es utilizar un modelo de
entregas incremental o comprimiendo los calendarios. La Figura 5 muestra que la
capacidad extra puede provenir de la mejora de las personas y los procesos. Esto se puede
lograr si se agrega un consultor de tiempo parcial, se capacita a algunas personas, se
utiliza un desarrollo rápido de prototipos en una de las partes del desarrollo del
producto/servicio, se utiliza un modelo de entregas incremental en otra de las partes, etc.
Personas
Producto/Servicio Información
Herramientas Procesos
Figura 3. Construcción de un producto/servicio más complejo incrementando la capacidad de las
personas.
Personas
Producto/Servicio Información
Herramientas Procesos
Figura 4. Construcción de un producto/servicio más complejo incrementando la capacidad de los
procesos.
Página 13 de 39

14. Personas
Producto/Servicio Información
Herramientas Procesos
Figura 5. Construcción de un producto/servicio más complejo incrementando la capacidad de las
personas y los procesos.
Así, la construcción de un producto/servicio más complejo requiere mayor capacidad de
algún lado, por lo que no se puede desarrollar algo nuevo con las mismas personas y
esperar que algo novedoso ocurra. Se debe mejorar la capacidad de las personas, los
procesos, la información, las herramientas, o todas en su conjunto.
El desarrollo exitoso de proyectos informáticos no es casual. Una forma de incrementar
su frecuencia es lograr la relación apropiada entre los cinco elementos. Dado un
producto/servicio y las personas para construirlo, se deben seleccionar los procesos, la
información y las herramientas apropiadas. De igual forma, dadas las personas con
preferencia por un tipo de procesos y con un cierto tipo de herramientas e información, se
deben construir sólo los productos apropiados.
La capacidad para construir productos/servicios más complejos debe provenir de las
personas, los procesos, la información y las herramientas. Los productos/servicios
específicos requieren de personas con conocimiento en el área de éstos, o hacer algo
diferente con los procesos, la información y las herramientas.
Siempre es recomendable seleccionar personas responsables y disciplinadas que
conozcan el producto/servicio en cuestión y que puedan trabajar en los procesos
utilizando las capacidades de la información y las herramientas. La utilización de un
proceso, información y herramientas permiten a las personas construir el
producto/servicio requerido. Es importante señalar que sólo se deben construir
productos/servicios dentro de las capacidades de las personas, procesos, información y
herramientas.
Por otro lado, no se recomienda utilizar más capacidad de la necesaria para construir un
producto/servicio. Utilizar un experto en redes únicamente para conectar dos
computadoras es un error. Siempre es recomendable pensar en las personas, procesos,
información, herramientas y productos/servicios como algo integral, de forma que se
acoplen unos con los otros. Esto siempre es posible debido a que en desarrollo de un
proyecto siempre existe un cierto nivel de flexibilidad y acoplamiento.
Página 14 de 39

15. REFERENCIAS BIBLIOGRÁFICAS
Edman, E. G. The project management analysis companion: Creating and implementing
standards for IT project management. Right Track Associates, Inc. www.ittoolkit.com.
USA, 2001-2002.
McConnell, Steve. Desarrollo y gestión de proyectos informáticos. Microsoft Press,
McGraw-Hill. España, 1998.
McConnell, Steve. Software project survival guide. Microsoft Press, McGrah-Hill. USA,
1998.
Phillips, Dwayne. The software project manager’s handbook. IEEE Computer Society
Press. USA, 1998.
Phillips, Dwayne. People, process, and product.
http://members.aol.com/dwaynephil/CutterPapers/ppp/ppp.htm . Visited August 2003.
Página 15 de 39

16. MODULO 1.
FUNDAMENTOS PARA EL DESARROLLO DE
PROYECTOS INFORMÁTICOS
2 LOS MODELOS DE MADUREZ DE LA CAPACIDAD
RESUMEN
Esta Sección presenta las dos normas internacionales para el desarrollo de proyectos
asociados a los componentes de Procesos y Personas discutidos hasta el momento. Estos
son, respectivamente:
 El Modelo de Madurez de la Capacidad del Software (S-CMM: The Software
Capability Maturity Model);
 El Modelo de Madurez de la Capacidad de las Personas (P-CMM: The People
Capability Maturity Model).
Ambos modelos son fundamentales para el éxito en el desarrollo de proyectos puesto que
son el resultado de muchos años de experiencia de diversas organizaciones.
Con el fin de introducir ambos modelos, esta sección inicia estudiando cómo una
organización debe madurar cada uno de los cinco elementos. La discusión continúa
explorando las principales características de ambos modelos de madurez antes indicados.
2.1 ANTECEDENTES
Como se discutió en las Subsecciones 1.3 y 1.4, los cinco elementos son fundamentales
para el desarrollo de cualquier proyecto informático. Estos elementos cambian cada vez
que el elemento producto/servicio cambia. Así, la construcción de un producto/servicio
con mayor complejidad implica un incremento en la capacidad de los otros cuatro.
Incrementar la capacidad de los cinco elementos requiere un incremento en la madurez
para administrar cada uno de ellos. Si al inicio de cada proyecto no existe un acuerdo en
un conjunto de pasos para el desarrollo, entonces la madurez para administrar los
elementos del proyecto se encuentra en su nivel más bajo (nivel inicial de madurez). En
este nivel, probablemente se utilice y comparta una terminología común, mientras que el
éxito del proyecto dependerá de los esfuerzos personales y actos heroicos.
Si cada vez que se desarrolla un proyecto éste se lleva a cabo repitiendo un proceso que
resultó exitoso en el pasado, entonces se genera una reducción de riesgos en el desarrollo
y por lo tanto un incremento en el éxito del proyecto. Debido a esto, el nivel de madurez
asociado es conocido como “nivel de madurez repetitivo”.
Por otro lado, si varias de las actividades de desarrollo y los procesos de administración
se encuentran definidos formalmente, están documentados e integrados, entonces el nivel
de madurez se denomina “nivel de madurez definido”.
Página 16 de 39

17. Más aún, si se hace énfasis en la importancia de medir cuantitativamente la calidad de los
productos/servicios resultado de cada proceso, fijando metas cuantitativas tanto para
productos/servicios como para los procesos, entonces es nivel de madurez se denomina
“nivel de madurez administrado”.
En el quito nivel de madurez, llamado “nivel de madurez optimizado”, la atención es
puesta en la mejora continua de los procesos a través de identificar pro-activamente sus
fortalezas y debilidades, todo con el propósito de prevenir la ocurrencia de defectos. En
este nivel, la mejora continua es obligatoria en el proceso de desarrollo. En lugar de sólo
corregir los defectos cuando éstos aparezcan, el propósito principal en este nivel es el de
prevenir esos defectos a través de la planeación.
La siguiente Figura es una representación gráfica de los niveles de madurez. En ella se
observa que en el nivel inicial los productos/servicios que podrían ser exitosos son
aquellos con una baja complejidad; mientras que en el nivel optimizado, los
productos/servicios podrían tener una complejidad mucho mayor.
Personas Nivel de Madurez Inicial
Nivel de Madurez
Repetitivo
Producto/Servicio Información
Nivel de Madurez Defiido
Nivel de Madurez
Administrado"
Herramientas Procesos
Nivel de Madurez
Optimizado
Figura 6. Representación de los niveles de madurez.
El conjunto de niveles de madurez para los procesos de software en una organización se
conoce como “Modelo de Madurez de la Capacidad del Software (S-CMM)”. Este
modelo ha sido desarrollado por el “Software Engineering Institute (SEI)” y se discute en
la Subsección 2.2. Es importante señalar que el S-CMM ha sido creado únicamente para
proyectos de desarrollo de software y no para proyectos informáticos en general.
De igual forma, el SEI ha desarrollado un marco de trabajo para mejorar la forma en que
una organización administra su capital humano, éste se conoce como “People Capability
Maturity Model (P-CMM)”. Este modelo se discute en la Subsección 2.3.
Página 17 de 39

18. 2.2 EL S-CMM
2.2.1 EL PROCESO DE DESARROLLO DE PROYECTOS DE SOFTWARE
Dentro del contexto de desarrollo de software, el “proceso” define la forma de hacer un
proyecto, los proyectos por lo general producen un producto (software) y un producto es
algo generado para un colega, un empleado, o un cliente.
Esta concepción de “proceso” es de utilidad para alcanzar el éxito del proyecto. Para
lograr este éxito, se deben llevar a cabo los siguientes tres pasos:
 Analizar el proceso actual con el cual la organización ejecuta sus proyectos;
 Determinar las fortalezas y debilidades de el proceso actual;
 Mejorar las fortalezas y remover las debilidades.
Los anteriores, y aparentemente sencillos, pasos han desconcertado a la industria de
software por muchos años. Varias organizaciones de software han adoptado diversas
técnicas para implementarlos con diferentes niveles de éxito. El problema ahora es tratar
de interpretarlos y dominarlos.
La discusión puede ser más puntual si se considera el conjunto de pasos que se sigue al
desarrollar un proyecto de software. En la Tabla siguiente, estos pasos se enuncian y
describen de forma general sin entrar en detalles, ya que estos detalles dependen de la
naturaleza de los proyectos.
Tabla 8. Pasos para desarrollar un proyecto de software.
PASO ACTIVIDADES
 El cliente define un conjunto de requerimientos del producto
 La organización discute estos requerimientos con el cliente
1. REQUERIMIENTOS  La discusión se centra en remover cualquier ambigüedad, conflicto
o problema relacionado con el producto/servicio
 El resultado de esta discusión será, de forma ideal, un conjunto de
funcionalidades bien definidas que el producto debe cumplir
 La organización estima y asigna recursos humanos y materiales
2. PLANEACIÓN (ESTIMADOS DE  Para facilitar el monitoreo del proyecto, se definen diversos hitos
COSTO Y TIEMPO)  Se realizan planes para subrogar (si es necesario) algunas partes
del proyecto
La organización está lista para iniciar el trabajo de desarrollo del
3. DESARROLLO DEL PROYECTO
proyecto
La organización monitorea de forma continua el progreso del proyecto
4. MONITOREO CONTINUO
comparándolo con los hitos definidos en el Paso 2
5. MONITOREO CONTINUO DE Los proveedores (si existe alguno) son monitoreados para asegurar
LOS PROVEEDORES que no existan retrasos debido a falta de comprensión del proyecto
6. ASEGURAMIENTO DE LA La organización debe asegurar que el trabajo se lleva a cabo acorde a
CALIDAD DEL SOFTWARE las normas y a los requerimientos
Página 18 de 39

19.  La organización debe asegurar que todas las partes del proyecto
estén bien coordinadas
7. ADMINISTRACIÓN DE CAMBIOS  La organización debe determinar si un cambio en una parte del
proyecto requiere cambiar otras partes, y si es así, entonces los
cambios deben ser los apropiados (administración de la
configuración)
Obviamente, las actividades anteriores son ejecutadas de alguna forma u otra en casi
todos los proyectos de software; entonces, ¿qué hace diferir una organización de otra? La
respuesta es sencilla: No todas las organizaciones siguen los pasos con igual rigor. Estos
pasos son muy sencillos de comprender pero extremadamente difíciles de ejecutar de
forma efectiva.
El propósito de la discusión anterior fue el de apreciar la necesidad de trazar un camino a
seguir por las organizaciones para producir software de calidad, dentro de presupuesto y
en los tiempos estipulados. Este camino se denomina S-CMM. Este modelo no es fácil de
comprender, ni mucho menos fácil de implementar de forma exitosa.
2.2.2 COMPONENTES DEL S-CMM
El S-CMM es el resultado de décadas de investigación y estudio de proyectos exitosos y
no exitosos. La filosofía principal del S-CMM es muy similar a la vida misma. Cuando
un niño nace está en su nivel “inicial” de madurez. Cuando el niño crece y aprende,
alcanza un nivel de madurez mayor. Este proceso se extiende hasta que se convierte en un
adulto maduro, aunque su proceso de aprendizaje continúa. De acuerdo al S-CMM una
organización de software sigue (o debería seguir) evoluciones similares de madurez. Es
importante señalar que el S-CMM no es un modelo de ciclo de desarrollo de software. Es
una estrategia para mejorar el proceso de software sin importar el modelo de ciclo de vida
utilizado.
En la Tabla siguiente se presenta una breve explicación de los diversos componentes del
S-CMM. Esta explicación ha sido extraída de los documentos oficiales del SEI (ver las
referencias bibliográficas al final de esta Sección).
Tabla 9. Algunos componentes del S-CMM.
COMPONENTE EXPLICACIÓN
NIVEL DE Es una meseta evolutiva bien-definida para lograr un proceso del software maduro.
MADUREZ Los cinco niveles de madurez son la estructura de más alto nivel del S-CMM
CAPACIDAD DEL Describe el rango de resultados esperados y que pueden lograrse siguiendo un
PROCESO DE proceso del software. Es una forma de predecir los resultados esperados en el
SOFTWARE próximo proyecto del software
Cada nivel de madurez está compuesto de sus propias KPAs. Cada una de ellas
ÁREAS DE identifica una serie relacionada de actividades que, cuando se ejecutan de forma
PROCESOS CLAVES colectiva, alcanzan un conjunto de metas consideradas como importantes para
(KPAS) determinar la capacidad del proceso en ese nivel de madurez. Por ejemplo, una KPA
para el nivel 2 es: “Planeación del Proyecto de Software”
Página 19 de 39

20. Las metas resumen las prácticas clave de una KPA y se utilizan para determinar si un
proyecto ha implementado de forma efectiva esta KPA. Las metas definen el alcance,
METAS las fronteras y el propósito de cada KPA. Un ejemplo de una meta para la KPA
“Planeación del Proyecto de Software” es: “Se documentan las estimaciones de
software para ser utilizadas en la planeación y seguimiento del proyecto de software”
Las prácticas clave están divididas en cinco secciones de Características Comunes:
 Compromiso para el Desempeño
 Habilidad para el Desempeño
 Actividades Desempeñadas
CARACTERÍSTICAS  Medición y Análisis
COMUNES  Verificación de la Implementación
Estas características son atributos que indican si la implementación e
institucionalización de una KPA es efectiva, repetible y duradera. La característica
común “Actividades Desempeñadas” describe las actividades de implementación,
mientras que las otras cuatro describen los factores de institucionalización que son
parte de la cultura organizacional
Cada KPA está descrita en términos de las prácticas clave, que al implementarlas
ayudan a satisfacer las metas de esa KPA. Las prácticas clave describen la
PRÁCTICAS CLAVE
infraestructura y actividades que contribuyen a la implementación e
institucionalización efectiva de la KPA.
2.2.3 EL MARCO DE TRABAJO DEL S-CMM
El S-CMM es un marco de trabajo que caracteriza un proceso evolutivo de mejora para
lograr una organización más madura. Una organización puede utilizar el S-CMM para
determinar su estado actual de madurez del proceso de software y entonces establecer
prioridades para la mejora. Los estados de madurez pueden ser categorizados como
Inicial, Repetible, Definido, Administrado y Optimizado. Por lo tanto, el S-CMM define
cinco niveles de madurez, descritos brevemente en las siguientes Tabla y Figura.
Tabla 10. Los niveles del S-CMM.
NIVEL DESCRIPCIÓN
El proceso de software se caracteriza como ad hoc y frecuentemente caótico. Pocos
1. INICIAL
procesos están definidos y el éxito depende de los esfuerzos individuales
Se establecen los procesos fundamentales de la administración de proyectos con el fin
2. REPETIBLE de dar seguimiento a los costos, calendarización y funcionalidad. Se establece una
disciplina para repetir los éxitos pasados en proyectos similares
El proceso de software para las actividades de administración e ingeniería está
documentado, normalizado e integrado en un proceso normalizado organizacional de
3. DEFINIDO
software. Todos los proyectos utilizan un proceso normalizado organizacional
debidamente aprobado e instanciado para desarrollar y dar mantenimiento al software
Existe un conjunto de métricas para el proceso de software y para la calidad del
4. ADMINISTRADO producto. Tanto el proceso como el producto de software se comprenden y controlan
de forma cuantitativa
La mejora continua del proceso se habilita a través de la realimentación cuantitativa
5. OPTIMIZADO
del proceso, de ideas innovadoras y nuevas tecnologías
Página 20 de 39

21. Proceso sometido 5.Optimizado
a mejora continua Enfocado a la
mejora de procesos
4. Administrado
Proceso Administración
Proceso medido
predecible de cambios
Proceso y controlado
normalizado y 3. Definido
Calidad de
consistente Proceso caracterizado
producto y
y bien comprendido
proceso
Proceso 2. Repetible
Puede repetir tareas Proceso
disciplinado
previamente dominadas integrado de
ingeniería
1. Inicial
Administración
Impredecible y
del proyecto
pobremente controlado
Figura 7. Los cinco niveles de la madurez del proceso de software.
Cada nivel de madurez está compuesto por cinco partes. Con la excepción del nivel 1. La
descomposición de cada nivel comprende desde resúmenes de cada nivel hasta su
definición operacional en las prácticas clave, tal como se muestra en la siguiente Figura.
Cada nivel está compuesto por varias KPAs. Cada KPA está organizada en cinco
secciones denominadas Características Comunes. Éstas últimas especifican las prácticas
clave que, de forma colectiva, hacen que se cumplan las metas de la KPA.
Niveles de Madurez
Indica
Capacidad Contiene
de los procesos
Cumplen
Áreas de procesos clave
Organizado por
Metas
Características
Dirigidas a comunes
Implementación o Contiene
institucionalización
Prácticas
Describen clave
Infraestructura o
actividades
Figura 8. Estructura del S-CMM.
La discusión anterior puede causar confusión. El S-CMM es un tema amplio y pocas
líneas no son suficientes para explicarlo del todo. Sin embargo, con el fin de
comprenderlo, el resto de esta Subsección se adentra en los niveles de madurez de
acuerdo a su estructura.
Página 21 de 39

22. 2.2.4 ÁREAS DE PROCESOS CLAVE (KPAS)
Cada nivel ha sido dividido en KPAs. Para que una organización alcance un cierto nivel
de madurez debe cumplir con todas las KPAs. Puesto que cada organización se encuentra
al menos en el nivel 1, no existen KPAs para este nivel. Esto significa que una
organización no requiere hacer algo para alcanzar el nivel 1. Las KPAs pueden
concebirse como una lista de tareas que una organización necesita ejecutar. Una KPA
contiene un grupo de actividades comunes a ejecutar por la organización para cumplir de
forma total con esa KPA. En la Tabla siguiente se muestra la lista de KPAs para cada
nivel de madurez.
Tabla 11. KPAs del S-CMM.
NIVEL ÁREAS DE PROCESOS CLAVE
1. INICIAL Sin KPAs
a. Administración de Requerimientos del Software
b. Planeación del Proyecto de Software
c. Seguimiento y Vigilancia del Proyecto de Software
2. REPETIBLE
d. Administración de los Proveedores de Software
e. Aseguramiento de la Calidad del Software
f. Administración de la Configuración del Software
a. Enfoque al Proceso Organizacional
b. Definición del Proceso Organizacional
c. Programa de Capacitación
3. DEFINIDO d. Administración Integrada del Software
e. Ingeniería del Producto de Software
f. Coordinación Intergrupal
g. Revisión de Pares
a. Administración Cuantitativa del Proceso
4. ADMINISTRADO
b. Administración de la Calidad del Software
a. Prevención de Defectos
5. OPTIMIZADO b. Administración del Cambio Tecnológico
c. Administración del Proceso de Cambio
Por lo tanto, existen 18 KPAs en el S-CMM. Lo que el S-CMM señala acorde a estas
KPAs es: Para que una organización alcance un nivel de madurez óptimo, DEBE cumplir
con las 18 KPAs. No cumplir una o más de ellas implica una inmadurez de la
organización, lo que a su vez resulta en un decremento de la productividad y un
incremento en los riesgos.
Página 22 de 39

23. 2.2.5 METAS
La única forma en que una organización puede estar segura de que ha cumplido
exitosamente una KPA es alcanzar todas las metas asociadas con esa KPA. En la Tabla
siguiente se muestra la lista completa de METAS asociadas a cada una de las 18 KPAs.
Tabla 12. Metas para cada KPA.
NIVEL KPA META
 Meta 1: Se controlan los requerimientos del sistema asignados al
Administración software para establecer una línea base para la ingeniería y
de administración de software en uso
Requerimientos  Meta 2: Existe consistencia entre los planes, productos y
del Software actividades del software con los requerimientos del sistema
asignados al software
 Meta 1: Se documentan las estimaciones de software para
utilizarse en la planeación y seguimiento del proyecto de
Planeación del software
Proyecto de  Meta 2: Se planean y documentan las actividades y compromisos
Software del proyecto de software
 Meta 3: Se acuerdan los compromisos relacionados al proyecto
de software entre las personas y grupos afectados
 Meta 1: Se comparan los resultados y desempeño reales con
respecto a los planes del software
Seguimiento y
 Meta 2: Se toman y administran acciones correctivas para hacer
Vigilancia del
el cierre cuando los resultados y desempeño se desvían
Proyecto de
significativamente de planes del software
Software
 Meta 3: Se acuerdan los cambios a los compromisos del
REPETIBLE
software entre las personas y los grupos afectados
 Meta 1: El contratista principal selecciona a subcontratistas de
software calificados
 Meta 2: Se acuerdan los compromisos mutuos entre el contratista
Administración principal y los subcontratistas de software
de los
Proveedores de  Meta 3: Se mantienen en comunicación continua el contratista
Software principal y los subcontratistas de software
 Meta 4: Se da seguimiento por el contratista principal a los
resultados y desempeño reales de los subcontratistas de software
comparándolos con los con sus compromisos
 Meta 1: Se planean las actividades de aseguramiento de la
calidad del software
 Meta 2: Se verifica de forma objetiva el apego de los productos
Aseguramiento y actividades del software a las normas, procedimientos y
de la Calidad del requerimientos
Software  Meta 3: Se mantiene informados a las personas y grupos
afectados de las actividades y resultados del aseguramiento de la
calidad del software
 Meta 4: Se asigna al administrador en jefe los puntos sin cumplir
Página 23 de 39

24. y que no pueden ser resueltos dentro del proyecto de software
 Meta 1: Se planean las actividades de administración de la
configuración del software
Administración  Meta 2: Se identifican, controlan y ponen a disposición los
de la productos de trabajo de software seleccionados
Configuración  Meta 3: Se controlan los cambios a los productos de trabajo de
del Software software identificados
 Meta 4: Se informan a las personas y grupos afectados del estado
y contenido de las líneas base del software
 Meta 1: Se coordinan en toda la organización las actividades de
desarrollo y mejora del proceso de software
Enfoque al  Meta 2: Se identifican, con base en un proceso normalizado, las
Proceso fortalezas y debilidades de los procesos de desarrollo de
Organizacional software utilizados
 Meta 3: Se planean las actividades de desarrollo y mejora del
proceso organizacional
 Meta 1: Se desarrolla y da mantenimiento a un proceso de
Definición del software normalizado
Proceso  Meta 2: Se recolecta, revisa y hace disponible la información
Organizacional relacionada a la utilización del proceso de software normalizado
de la organización
 Meta 1: Se planean las actividades de capacitación
 Meta 2: Se capacita para el desarrollo de habilidades y
conocimiento necesarios para desempeñar los puestos técnicos y
Programa de
de administración del software
Capacitación
 Meta 3: Se capacita para que las personas, los grupos de
ingeniería de software y los grupos relacionados al software
desempeñen sus puestos
DEFINIDO
 Meta 1: Se hacen ajustes al proceso de software normalizado de
Administración la organización para definir una versión del proceso de software
Integrada del del proyecto
Software  Meta 2: Se planea y administra el proyecto acorde al proceso de
software definido para el proyecto
 Meta 1: Se define, integra y se lleva a cabo de forma consistente
Ingeniería del las tareas de ingeniería de software para definir el software
Producto del
Software  Meta 2: Se mantienen consistentes entre ellos los productos de
trabajo de software
 Meta 1: Se acuerdan los requerimientos del cliente por todos los
grupos afectados
Coordinación  Meta 2: Se acuerdan los compromisos entre los grupos de
Intergrupal ingeniería por los grupos afectados
 Meta 3: Se identifica, da seguimiento y resuelve los aspectos
intergrupales por los grupos de ingeniería
 Meta 1: Se planean las actividades de revisión por los pares
Revisión de
Pares  Meta 2: Se identifican y remueven los defectos en los productos
de trabajo de software
Página 24 de 39

25.  Meta 1: Se planean las actividades cuantitativas de
administración de procesos
Administración  Meta 2: Se controla cuantitativamente el proceso de desempeño
Cuantitativa del del proceso de software definido para el proyecto
Proceso  Meta 3: Se conoce de forma cuantitativa la capacidad del
proceso del proceso de software normalizado para la
ADMINISTRADO organización
 Meta 1: Se planean las actividades de administración de la
calidad del software del proyecto
Administración
 Meta 2: Se definen metas medibles para la calidad del producto
de la Calidad del
de software y sus prioridades
Software
 Meta 3: Se cuantifica y administra el progreso real a través del
logro de las metas de calidad para los productos de software
 Meta 1: Se planean las actividades de prevención de defectos
Prevención de  Meta 2: Se buscan e identifican las causas comunes de defectos
Defectos  Meta 3: Se priorizan y de forma sistemática se eliminan las
causas comunes de defectos
 Meta 1: Se planea la incorporación de cambios tecnológicos
Administración  Meta 2: Se evalúan las nuevas tecnologías para determinar su
del Cambio efecto en la calidad y la productividad
OPTIMIZADO Tecnológico  Meta 3: Se convierten en practicas normales en la organización
las nuevas tecnologías apropiadas
 Meta 1: Se planea la mejora continua de procesos
 Meta 2: Se participa a lo largo de la organización en las
Administración
actividades de mejora continua del proceso de software
del Proceso de
Cambio  Meta 3 Se mejoran de forma continua los procesos de software
normalizados de la organización y los procesos de software
definidos para el proyecto
2.2.6 CARACTERÍSTICAS COMUNES
Las KPAs están organizadas en Características Comunes. Éstas son atributos que indican
cuando la implementación e institucionalización de una KPA ha sido efectiva, repetible y
duradera. Las cinco características comunes están descritas en la Tabla siguiente.
Tabla 13. Descripción de la Características Comunes.
CARACTERÍSTICAS
DESCRIPCIÓN
COMUNES
Describe las acciones que la organización debe llevar a cabo para asegurar que
COMPROMISO PARA EL
el proceso esté establecido y sea permanente. Implica el establecimiento de
DESEMPEÑO
políticas organizacionales y patrocinio de la administración
Describe las precondiciones que deben existir en el proyecto u organización
HABILIDAD PARA EL
para implementar de forma competente el proceso de software. Requiere de
DESEMPEÑO
recursos, estructuras organizacionales y capacitación
Página 25 de 39

26. Describe los roles y procedimientos necesarios para implementar una KPA.
ACTIVIDADES
Implica el establecimiento de planes y procedimientos, llevar acabo las tareas,
DESEMPEÑADAS
darles seguimiento y tomar acciones correctivas cuando sea necesario
Describe la necesidad de medir el proceso y analizar las mediciones.
MEDICIÓN Y ANÁLISIS Comprende considerar muestras de mediciones para determinar el estado y
efectividad de las actividades desempeñadas
Describe los pasos para asegurar que las actividades se llevan a cabo conforme
VERIFICACIÓN DE LA
al proceso establecido. Implica llevar a cabo revisiones y auditorias
IMPLEMENTACIÓN
administrativas y asegurar la calidad del software
Las prácticas en las Actividades Desempeñadas describen lo que debe implementarse
para establecer una capacidad el proceso. Las otras prácticas, consideradas como un todo,
forman la base para que una organización pueda institucionalizar las prácticas descritas
en las Actividades Desempeñadas.
2.2.7 PRÁCTICAS CLAVE
Cada KPA está descrita en términos de las prácticas clave que contribuyen a satisfacer
sus metas. Las prácticas clave describen la infraestructura y actividades que contribuyen
a la implementación e institucionalización más efectiva de la KPA.
Cada práctica clave consiste de una única oración, a menudo seguida por una descripción
más detallada, que puede incluir algunos ejemplos y mayor detalle. Estas prácticas clave
establecen las políticas, procedimientos y actividades fundamentales para la KPA. Los
componentes de la descripción detallada se les llaman “subprácticas”. La siguiente Figura
muestra un ejemplo de la estructura de una práctica clave para la KPA Planeación del
Proyecto de Software.
Nivel de madurez:
Nivel de madurez:
2, Repetible
2, Repetible
Indica Contiene
Capacidad del proceso: KPA:
KPA:
Proceso disciplinado Planeación del proyecto
Planeación del proyecto
de software
de software
Logra Organizado por
Meta 1:
Se documentan las
estimaciones de software para Característica común:
Característica común:
utilizarse en la planeación y Actividades desarrolladas
Actividades desarrolladas
seguimiento del proyecto
de software Dirigida a Contiene
Práctica clave:
Práctica clave:
Implementación o Actividad 9. Las estimaciones para el tamaño
Actividad 9. Las estimaciones para el tamaño
institucionalización: de los productos del trabajo de software (o cambios
de los productos del trabajo de software (o cambios
Implementación al tamaño de productos del trabajo de software)
al tamaño de productos del trabajo de software)
se derivan según un procedimiento documentado
se derivan según un procedimiento documentado
Describe
Infraestructura o
actividades:
Actividad
Figura 9. Ejemplo de una práctica clave.
Página 26 de 39

27. 2.2.8 S-CMM EN LAS ORGANIZACIONES
Muchas organizaciones han implementado exitosamente el S-CMM y han reportado
mejoras considerables en casi todos los aspectos del ciclo de vida del software. Algunas
de estas organizaciones son: Bull HN, GTE Government Systems, Hewlett Packard,
Hughes Aircraft Co., Loral Federal Systems (anteriormente IBM Federal Systems
Company), Lockheed Sanders, Motorola, Northrop, Schlumberger, Siemens Stromberg-
Carlson, Texas Instruments, United States Air Force Oklahoma City Air Logistics Centre,
United States Navy Fleet Combat Direction Systems Support Activity.
S-CMM ayuda a una organización en dos formas:
 S-CMM implementa prácticas que resultan en un incremento en la productividad;
 Trae consigo un cambio inmediato en la cultura y mentalidad de la organización,
lo que implica poder escalar los niveles del S-CMM.
De entre las más de 900 organizaciones que han sido evaluadas por el SEI, la mayoría de
ellas se encuentran dentro de los niveles 1 (34.9%) y 2 (38.2%).
Sin embargo, el recorrido para alcanzar un nivel superior de la madurez del proceso
requiere una cantidad considerable de tiempo y esfuerzo. Los esfuerzos para instrumentar
el S-CMM iniciaron en 1992 y la experiencia ha mostrado que el tiempo requerido para
ascender de un nivel a otro es como sigue:
 Del nivel 1 al nivel 2: 25 meses;
 Del nivel 2 a nivel 3: 22 meses;
 Del nivel 3 al nivel 4: 36.5 meses.
La Tabla siguiente muestra el número de organizaciones que han obtenido los niveles 4 y
5 hasta octubre de 2002.
Tabla 14. Organizaciones en el nivel 4 y 5 del S-CMM.
NÚMERO DE ORGANIZACIONES EN EL NIVEL NÚMERO DE ORGANIZACIONES EN EL NIVEL
PAÍS
4 DEL S-CMM 5 DEL S-CMM
AUSTRALIA 2
CANADÁ 1
CHINA 2
FRANCIA 1
INDIA 27 50
IRLANDA 1
ISRAEL 1
RUSIA 1
SINGAPUR 1
USA 39 20
Página 27 de 39

28. Las ventajas de escalar los niveles del S-CMM son evidentes en un gran número de
organizaciones. Alcanzar un nivel superior implica una mejora en el desempeño
organizacional. Algunos de los beneficios principales que trae consigo el S-CMM son:
 Migración de una administración reactiva a una preactiva;
 Ayuda a construir una fuerza de trabajo hábil y motivada;
 Reducción en los costos en el desarrollo y mantenimiento de los sistemas;
 Reducción en los tiempos de entrega y mejora en la entrega de los requerimientos;
 Mayor satisfacción al cliente;
 Mejora la calidad de los productos de software;
 Induce el robustecimiento;
 Mejora la administración de toma de decisiones;
 Introduce nueva tecnología para crear ventajas competitivas.
Los niveles del S-CMM son como las prescripciones dadas por un médico. De igual
forma que el cumplimiento de las normas sociales son de ayuda para mejorar la calidad
de vida, los criterios de los procesos clave del S-CMM ayudan a la organización a
mejorar sus niveles de madurez. El ascenso de los diferentes niveles hace que se mejore
de forma significativa el desempeño y competencia de la organización.
El S-CMM ayuda a mejorar los procesos de ingeniería de software desde un nivel ad hoc
hasta niveles disciplinados y administrados, ambos apoyados por tecnología actual. Esto
permite que la organización alcance los niveles de madurez desde un punto de vista de
negocios.
De acuerdo a las estadísticas del SEI, cuando el S-CMM se aplica de forma apropiada,
puede (ver también la siguiente Tabla):
 Mejorar la productividad;
 Mejorar los tiempos de puesta en el mercado del producto hasta en un 70%;
 Decremento en los defectos de los productos hasta en un 90%.
Tabla 15. Porcentaje de mejora comparado con los resultados de los niveles previos.
CRITERIOS NIVELES 1 - 2 NIVELES 2 - 3 NIVELES 3 - 4
REDUCCIÓN DE DEFECTOS 12% 40% 85%
REDUCCIÓN EN LOS CICLOS 10% 38% 63%
REDUCCIÓN EN EL COSTO 8% 35% 75%
VARIANZA DE LA CALENDARIZACIÓN 145% 24% 15%
Página 28 de 39

29. El S-CMM por si mismo no garantiza que el trabajo realizado sea exitoso. Lo que asegura
es que el trabajo organizacional realizado de una forma ordenada permita predecir los
resultados de este trabajo.
A través de la práctica de los procesos del S-CMM, una organización puede alcanzar
nuevas metas y un incremento en sus perspectivas y alcances.
2.2.9 CONCLUSIÓN
Se puede concluir que el S-CMM ayuda en evaluar los procesos de software de una
organización, así como a identificar los prerrequisitos necesarios para alcanzar un nivel
de madurez de esos procesos. Adicionalmente, traza una ruta que permite mejorar la
administración y desarrollo de los productos de software de una forma ordenada y
disciplinada. Si se aplica de forma adecuada, el S-CMM es un sistema poderoso que
puede ayudar a la transformar a la organización y ayuda a alcanzar su máximo nivel de
desempeño.
2.3 CMM PARA PERSONAS
2.3.1 ANTECEDENTES
Cada empleado de una organización tiene un impacto en la calidad del producto/servicio.
Es imperativo que el nivel de desarrollo del empleado refleje las expectativas de calidad
requeridas. Puesto que los empleados bien capacitados y competentes son una ventaja
estratégica para una organización, ésta debe ver a las actividades de capacitación como
tal.
El Modelo de Madurez de la Capacidad para Personas (P-CMM) también fue
desarrollado por el SEI de la Carnegie-Mellon University en Pennsylvania. El SEI tuvo la
colaboración de representantes de la industria, gobierno, milicia y organizaciones
académicas para diseñar un modelo evolutivo para desarrollar y optimizar la capacitación
y competencia del personal de una organización.
2.3.2 TEMAS
El P-CMM define el éxito en términos de la madurez de una organización. La estructura
del P-CMM demuestra cómo las organizaciones pueden progresar de forma secuencial a
través de niveles de madurez crecientes hasta alcanzar un nivel óptimo de desempeño.
Existen 5 niveles de madurez en el P-CMM, descritos brevemente en la siguiente Tabla.
Tabla 16. Niveles del P-CMM.
NIVEL DESCRIPCIÓN
1. INICIAL No aplica ningún proceso
Los procesos están enfocados a establecer las prácticas fundamentales para la fuerza
2. REPETIBLE de trabajo y eliminar los problemas que tienden a minimizar el desempeño del trabajo.
El propósito es implementar una disciplina en las actividades de la fuerza de trabajo
Página 29 de 39

30. Los procesos se enfocan a los aspectos organizacionales, ajustando las prácticas de la
fuerza de trabajo a las competencias fundamentales definidas por el entorno. El
3. DEFINIDO
propósito es identificar las competencias primarias y alinear las actividades de la
fuerza de trabajo con estas competencias
Los procesos se enfocan en la construcción de competencias basadas en equipos y en
el establecimiento de tendencias para el desarrollo de conocimientos y habilidades,
asó como en la alineación del desempeño a lo largo de los diferentes niveles
4. ADMINISTRADO
organizacionales. El propósito es administrar de forma cuantitativa el crecimiento
organizacional de las capacidades de la fuerza de trabajo y establecer competencias
basadas en equipos
Los procesos cubren aspectos que las personas y las organizaciones deben tomar en
cuenta para implementar la mejora continua en sus capacidades. El propósito es
5. OPTIMIZADO
mejora de forma continua los métodos para el desarrollo del personal y la
competencia organizacional
Existen relaciones que vinculan los niveles de madurez de forma que el progreso pueda
ocurrir siguiendo un conjunto de relaciones. A través de estas relaciones o Temas, la
implementación de los procesos en un nivel de madurez hace que éstos puedan servir
como un fundamento para las prácticas y capacidades en niveles superiores. Los temas
del P-CMM se describen en la Tabla siguiente:
Tabla 17. Temas del P-CMM.
TEMAS DESCRIPCIÓN
La tendencia inicia con la identificación de las necesidades reales de capacitación
CAPACIDADES EN dentro de una unidad, avanza hacia la identificación de las competencias
EL DESARROLLO fundamentales y evoluciona a tener individuos que les sea posible establecer sus
propios programas de desarrollo profesional
CONSTRUCCIÓN DE La tendencia inicia con el establecimiento de las habilidades de comunicación
EQUIPOS Y básica, continua con el desarrollo de una cultura basada en la participación y avanza
CULTURA hacia la construcción formal de equipos y la mejora continua de sus capacidades
La tendencia inicia con el establecimiento de prácticas de administración y
MOTIVACIÓN Y compensación del desempeño, continua con la mejora de estas prácticas
ADMINISTRACIÓN adaptándolas al desarrollo de las competencias y a la construcción de equipos. A
DEL DESEMPEÑO partir de este nivel, la tendencia busca optimizar a través de la búsqueda de fuentes
de innovación
La tendencia inicia con el establecimiento de prácticas básicas en el personal.
MOLDEO DE LA
Continua con el desarrollo de planes para el desarrollo de la fuerza de trabajo,
FUERZA DE
establece y da seguimiento a los objetivos para desarrollar competencias en la
TRABAJO
fuerza de trabajo, y entonces busca fuentes de innovación
2.3.3 ÁREAS DE PROCESOS CLAVES (KPAS)
Las KPAs se refieren a tareas y actividades particulares que deben completarse con el fin
de que una organización madure y progrese en la optimización de sus iniciativas de
capacitación. La siguiente Tabla identifica las KPAs apropiadas para cada uno de los
cuatro Temas.
Página 30 de 39

31. Tabla 18. KPAs necesarias para cada uno de los cuatro Temas del P-CMM.
NIVELES DE TEMA 2: TEMA 3: TEMA 4:
TEMA 1:
MADUREZ CONSTRUCCIÓN MOTIVACIÓN Y MOLDEO DE LA
CAPACIDADES DE
TEMAS DE EQUIPOS Y ADMINISTRACIÓN FUERZA DE
DESARROLLO
DEL P-CMM CULTURA DEL DESEMPEÑO TRABAJO
Entrenamiento
NIVEL DE
MADUREZ 5: Desarrollo de Innovación Continua de la Fuerza de Trabajo
Competencias del
OPTIMIZADO
Personal
Alineación del
NIVEL DE Desempeño Administración
MADUREZ 4:
Construcción de Organizacional de la
Tutelaje
equipos Competencia
ADMINISTRADO Prácticas Basadas Organizacional
en los Equipos
Desarrollo de
Prácticas Basadas
NIVEL DE competencias Planeación de la
Cultura en la Competencia
MADUREZ 3: Análisis de Fuerza de
participativa Desarrollo
DEFINIDO conocimiento y Trabajo
Profesional
habilidades
Compensación
NIVEL DE
Capacitación Administración del Adquisición de
MADUREZ 2: Comunicación
Comunicación Desempeño Personal
REPETIBLE
Entorno Laboral
NIVEL DE
MADUREZ 1: Ninguno
INICIAL
2.3.4 IMPLEMENTACIÓN
La implementación del P-CMM requiere del apoyo y aprobación de las diversas unidades
de la organización. Este modelo no será efectivo si es impuesto o forzado en esas
unidades. Puesto que el modelo es genérico, tiene que ser interpretado e instanciado con
el fin de hacerlo adecuado a la naturaleza de la organización.
Este modelo fue diseñado para proveer de beneficios en cada nivel de madurez, por lo
que no es recomendable saltarse un nivel o desatender las características de los procesos
de un nivel previo. Las salidas de cada nivel sirven de fundamento para las prácticas de
los niveles de madurez subsecuentes, las cuales están descritas en los cuatro Temas del
modelo.
Para ayudar en la interpretación e implementación de este modelo en una organización, el
P-CMM ha identificado los siguientes criterios de aceptación para cada KPA:
 Metas;
 Compromiso para el Desempeño;
 Habilidad para el Desempeño;
Página 31 de 39

32.  Actividades Desempeñadas;
 Medición y Análisis;
 Verificación e Implementación.
Como un ejemplo, la siguiente Tabla es la partición para la KPA: Capacitación
Tabla 19. Ejemplo para la KPA: Capacitación.
COMPROMISO HABILIDAD VERIFICACIÓN DE
ACTIVIDADES MEDICIÓN
METAS PARA EL PARA EL LA
DESEMPEÑADAS Y ANÁLISIS
DESEMPEÑO DESEMPEÑO IMPLEMENTACIÓN
Dentro de Se asigna a un
cada unidad responsable para
La
Proveer de Dentro de cada se hacen verificar que las
organización En cada unidad
capacitación unidad, se asigna mediciones actividades de
sigue una se identifican
en las a un responsable para capacitación sean
política las habilidades
habilidades de asegurar que determinar conducidas acorde
documentada para
críticas las actividades de el estado de a los planes de la
para estas desempeñar las
requeridas en capacitación se las unidad y a las
actividades de tareas críticas
cada unidad lleven a cabo actividades políticas
capacitación
de documentadas de
capacitación la organización
La Se Los directivos
capacitación Se asigna un recolectan revisan
Se provee de de
se lleva a responsable y se dan a periódicamente las
recursos y Se identifican
cabo en los para ayudar y conocer las actividades de
financiamiento las actividades
tiempos colaborar con mediciones capacitación de la
para implementar de capacitación
adecuados de las unidades del estado organización para
las actividades de para cada
forma que se en las de la determinar si
capacitación unidad
puedan actividades de capacitación cumplen con las
planeadas
desempeñar capacitación de cada políticas
las tareas unidad documentadas
Las Se destinan
Cada unidad
oportunidades tiempos para la
desarrolla y da
de capacitación a
mantenimiento
capacitación todo el personal
a un plan para
están acordes a las
satisfacer sus
disponibles políticas de
necesidades de
para todo el capacitación de
capacitación
personal la organización
Las personas
responsables de Las personas
identificar las y/o grupos
necesidades de reciben la
capacitación se capacitación
capacitan en necesaria para
métodos llevar a cabo las
relevantes a sus tareas asignadas
responsabilidades
Los instructores Se identifican y
tienen la hace
capacitación y/o disponibles las
requeridas para oportunidades
Página 32 de 39

33. desempeñar sus de capacitación
responsabilidades relevantes para
apoyar el
desarrollo del
personal
Se le da
seguimiento a la
capacitación en
base al plan de
capacitación de
la unidad
Con el fin de ayudar a la interpretación e implementación, el P-CMM provee
descripciones similares detalladas para cada KPA. La aplicación de este sistema pretende
ser una guía para las organizaciones.
El desarrollo del personal en los activos productivos y estratégicos es una iniciativa que
puede dar grandes beneficios a una organización. Para obtener estos beneficios, una
organización debe examinar los diversos procesos y actividades indicadas en el P-CMM,
y determina una estrategia aplicable y apropiada para optimizar el desempeño del
personal.
2.4 REFERENCIAS BIBLIOGRÁFICAS
Bardoloi, Sabyasachi. Quality: A Health Capsule to Retain Growth. Pinnacle Systems,
Inc. ftp://projectperfect.com.au/CMM.pdf. Visited August 2003.
Curtis, Bill, William E. Hefley, and Sally A. Miller. People Capability Maturity Model®
(P-CMM®), Version 2.0. CMU/SEI-2001-MM-01. July 2001. www.sei.cmu.edu. Visited
August 2003.
Hefley, William E. Where Does Team Building Fit As A Component of Mature Software
Development Processes? http://hsb.baylor.edu/ramsower/ais.ac.96/papers/hefley2.htm.
Visited August 2003.
Manzoor, Kashif. CMM – an introduction.
http://homepages.com.pk/kashman/CMMIntro.htm. Visited August 2003.
Paulk, Mark C. Using the Software CMM in small organizations. 1998.
www.sei.cmu.edu. Visited August 2003.
Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. Capability
Maturity Model for Software, Version 1.1. Technical Report CMU/SEI-93-TR-024 ESC-
TR-93-177. www.sei.cmu.edu. February 1993.
Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. The Capability
Maturity Model for Software. www.sei.cmu.edu. February 1993.
Zrymiak, Dan. People - Capability Maturity Model. http://www.msi.ms/MSJ/People-
Capability_Maturity_Model.htm. Visited August 2003.
Página 33 de 39

34. MODULO 1.
FUNDAMENTOS PARA EL DESARROLLO DE
PROYECTOS INFORMÁTICOS
3 EL PROCESO DE COMUNICACIÓN EN UN PROYECTO
INFORMÁTICO
RESUMEN
La comunicación es la pieza angular de cómo el trabajo se realiza por las diversas partes
dentro de un proyecto. La comunicación no es una tarea fácil y requiere de un gran
esfuerzo de la partes para lograrla.
Con el fin de conocer cómo administrar las comunicaciones en el desarrollo de un
proyecto informático, en lo que sigue se desarrollan dos temas principales: los elementos
de un plan de comunicación y algunas estrategias de comunicación.
3.1 ELEMENTOS DE UN PLAN DE COMUNICACIÓN
Los proyectos informáticos exitosos se obtienen a través de una combinación de acciones
y estrategias efectivas y en momento adecuado. Muy rara vez los proyectos son
completados por una única persona. Muchos de los proyectos informáticos son
completados por un equipo de personas con diferentes roles y responsabilidades.
Dependiendo del tamaño y naturaleza de los proyectos, estos equipos están compuestos,
por una combinación de (ver Sección 1.2.1):
 El equipo del proyecto;
 Los clientes (tanto internos como externos) de los productos/servicios creados;
 Los patrocinadores del proyecto;
 Los actores en el proyecto.
Cada miembro del equipo del proyecto puede tener diferentes niveles de experiencia
técnica y en administración de proyectos. De igual forma, puede tener diferentes actitudes
y opiniones sobre la dirección y metas del proyecto. Mantener a este equipo
completamente informado y trabajando como una unidad es un reto que sólo se puede
cumplir utilizando un conjunto de estrategias de comunicación creativas y prácticas.
Cuando estas estrategias pasan a ser parte de una política y acciones determinadas, se
convierten en un Plan de Comunicaciones del Proyecto, de forma que para lograr
finalizar el proyecto y por obtener el éxito, este plan debe estar presente en proyecto
desde el primer hasta el último día.
Mientras que los detalles de cualquier Plan de Comunicaciones del Proyecto pueden
variar acorde a la complejidad, tamaño y duración, cada plan debe contener al menos tres
elementos fundamentales (ver Tabla siguiente).
Página 34 de 39