GESTION DE PROYECTOS DE SOFTWARE

INSTITUTO TECNOLOGICO DE TIJUANA

Unidad II.
Gestión de calidad
Guía de Estudio
Facilitador: Martin Camuñas Fausto
Ingeniería en sistemas

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 1 | 20
Índice
CALIDAD DE SOFTWARE____________________________________________________ 3
2.1 La gestión de proyectos usando un marco de calidad ______________________________ 3
2.2 Estándares y Métricas de calidad en la ingeniería de SW ___________________________ 6
MEDICIÓN Y MÉTRICAS DEL SOFTWARE __________________________________________________ 6
LAS MÉTRICAS SON DE CONTROL O DE PREDICCIÓN. ________________________________________ 6
ANÁLISIS DE LAS MEDICIONES __________________________________________________________ 7
PUNTOS CLAVE ______________________________________________________________________ 7

2.2.1 PSP y TSP ________________________________________________________________ 8

PSP ________________________________________________________________________________ 8
TSP ________________________________________________________________________________ 9
Características de los grupos eficaces: ____________________________________________________ 9

2.2.2 CMM __________________________________________________________________ 11

EL MODELO CMM ____________________________________________________________ 12
2.2.3 MOPROSOFT ____________________________________________________________ 14
2.3 Impacto de la calidad en tiempo, costo y alcance del proyecto _____________________ 16
ALCANCES _________________________________________________________________________ 17
GESTIÓN DEL ALCANCE _______________________________________________________________ 17
PLANIFICACIÓN DEL ALCANCE _________________________________________________________ 17
HERRAMIENTAS Y TÉCNICAS __________________________________________________________ 17
VERIFICACIÓN DEL ALCANCE __________________________________________________________ 18
CONTROL DEL ALCANCE ______________________________________________________________ 18
ESTRUCTURA _______________________________________________________________________ 18
ESPECIFICACIONES __________________________________________________________________ 19
TIEMPO, COSTOS Y RECURSOS _________________________________________________________ 19
COSTOS ___________________________________________________________________________ 19
RECURSOS _________________________________________________________________________ 20

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 2 | 20
 CALIDAD DE SOFTWARE

2.1 La gestión de proyectos usando un marco de calidad

La calidad del software es un concepto complejo que no es directamente comparable con la calidad
de la manufactura de productos. En la manufacturación, la noción de calidad viene dada por la similitud
entre el producto desarrollado y su especificación. En un mundo ideal, esta definición debería aplicarse
a todos los productos, pero, para sistemas de software, existen estos problemas:

1. La especificación se orienta hacia las características del producto que el consumidor quiere. Sin
embargo, la organización desarrolladora también tiene requerimientos (como los de
mantenimiento) que no se incluyen en la especificación.
2. No se sabe cómo especificar ciertas características de calidad (por ejemplo, mantenimiento) de
una forma no ambigua.
3. Es muy difícil redactar especificaciones concretas de software. Por lo tanto, aunque un producto
se ajuste a su especificación, los usuarios no lo consideran un producto de alta calidad debido a
que no responde a sus expectativas.
Se deben reconocer estos problemas con la especificación del software y se tienen que diseñar
procedimientos de calidad que no se basen en una especificación perfecta. En concreto, atributos del
software como mantenibilidad, seguridad o eficiencia no pueden ser especificados explícitamente. Sin
embargo, tienen un efecto importante en cómo es percibida la calidad del sistema.

Algunas personas piensan que la calidad puede lograrse definiendo estándares y procedimientos
organizacionales de calidad que comprueban si estos estándares son seguidos por el equipo de
desarrollo. Su argumento es que los estándares deben encapsular las buenas prácticas, las cuales
nos llevan inevitablemente a productos de alta calidad. En la práctica, sin embargo, es más importante
la gestión de la calidad que los estándares y la burocracia asociada para asegurar el seguimiento de
estos estándares.
Los buenos gestores aspiran a desarrollar una «cultura de la calidad» donde todos seamos
responsables de que el desarrollo del producto sea llevado a cabo obteniendo un alto nivel de calidad
en éste. Mientras estándares y procedimientos son las bases de la gestión de la calidad, los gestores
de calidad experimentados reconocen que hay aspectos intangibles en la calidad del software
(elegancia, legibilidad, etc.) que no puede ser incorporada en los estándares. Ellos ayudan a la gente
interesada en estos aspectos intangibles de calidad y fomentan comportamientos profesionales en
todos los miembros del equipo.
La gestión formal de la calidad es particularmente importante para equipos que desarrollan sistemas
grandes y complejos. La documentación de la calidad es un registro de que es hecho por cada
subgrupo en el proyecto.
Esto ayuda a la gente a ver qué tareas importantes no deben ser olvidadas o que una parte del equipo
no haga suposiciones incorrectas acerca de lo que otros miembros han hecho. La documentación de
calidad es también un medio de comunicación sobre el ciclo de vida de un sistema. Ésta permite al
grupo responsabilizarse de la evolución del sistema para saber qué ha hecho el equipo de desarrollo.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 3 | 20
Para sistemas pequeños, la gestión de calidad es importante todavía, pero se debe adoptar una
aproximación más informal. No son tan necesarios los documentos porque el grupo puede
comunicarse informalmente.

La clave de la calidad en el desarrollo de sistemas pequeños es el establecimiento de cultura de

calidad y asegurarse de que todos los miembros del equipo hacen una aproximación positiva a la
calidad del software.
La gestión de calidad del software se estructura en tres actividades principales:
 Garantía de la calidad. El establecimiento de un marco de trabajo de procedimientos y
estándares organizacionales que conduce a software de alta calidad.
 Planificación de la calidad. La selección de procedimientos y estándares adecuados a partir de
este marco de trabajo y la adaptación de éstos para un proyecto software específico.
 Control de la calidad. La definición y fomento de los procesos que garanticen que los
procedimientos y estándares para la calidad del proyecto son seguidos por el equipo de
desarrollo de software.
La gestión de la calidad provee una comprobación independiente de los procesos de desarrollo
software. Los procesos de gestión de la calidad comprueban las entregas del proyecto para
asegurarse que concuerdan con los estándares y metas organizacionales. El equipo de garantía de
calidad debe ser independiente del equipo de desarrollo para que puedan tener una visión objetiva
del software. Ellos transmitirán los problemas y las dificultades al gestor principal de la organización.

Un equipo independiente de calidad garantiza que los objetivos organizacionales y la calidad no sean
comprometidos por consideraciones de presupuesto o agenda. Una suposición subyacente de la
gestión de calidad es que la calidad del proceso de desarrollo afecta directamente a la calidad de los
productos derivados. La siguiente figura muestra una aproximación basada en proceso para conseguir
la calidad del producto.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 4 | 20
Hay un vínculo claro entre la calidad del proceso y del producto en producción debido a que el proceso
es relativamente fácil de estandarizar y monitorizar.
El software no se manufactura, sino que se diseña. El desarrollo de software es un proceso más
creativo que mecánico. La calidad del producto, también se ve afectada por factores externos, como
la novedad de una aplicación o la presión comercial para sacar un producto rápidamente.
En el desarrollo software, por lo tanto, la relación entre la calidad del proceso y la calidad del producto
es muy compleja. Es difícil de medir los atributos de la calidad del software, en consecuencia, es difícil
explicar cómo influyen las características del proceso en estos atributos. Además debido al papel del
diseño y la creatividad en el proceso software, no podremos predecir la influencia de los cambios en
el proceso en la calidad del producto.
La calidad del proceso tiene una influencia significativa en la calidad del software. La gestión y mejora
de la calidad del proceso debe minimizar los defectos en el software entregado.
La gestión de la calidad del proceso implica:
 Definir estándares de proceso.
 Supervisar el proceso de desarrollo para asegurar que se sigan los estándares.
 Hacer informes del proceso para el gestor del proyecto y para el comprador del software.

Un problema de la garantía de la calidad basada en el proceso es que el equipo de garantía de la

calidad (QA) insista en unos estándares de proceso independientemente del tipo de software a
desarrollar. El gestor principal debe intervenir para asegurar que el proceso de calidad ayude al
desarrollo del producto en lugar de impedirlo.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 5 | 20
2.2 Estándares y Métricas de calidad en la ingeniería de SW
MEDICIÓN Y MÉTRICAS DEL SOFTWARE

Sería posible acelerar el proceso de revisión utilizando herramientas que procesaran el diseño del
software o el programa, e hiciesen valoraciones automáticas de la calidad del software. Estas
valoraciones permiten comprobar que el software tiene el umbral de calidad requerido, y destacar las
partes en las cuales no se ha alcanzado para revisarlas.

La medición del software se refiere a derivar un valor numérico desde algún atributo del software o
del proceso software. Comparando estos valores entre sí y con los estándares aplicados en la
organización, es posible sacar conclusiones de la calidad del software o de los procesos para
desarrollarlo.

Las mediciones del software pueden utilizarse para:

Hacer predicciones generales acerca del sistema.
Identificar componentes anómalos.

Una métrica de software es cualquier tipo de medida relacionada con un sistema, proceso o
documentación de software. Algunos ejemplos son las medidas que se utilizan para calcular el tamaño
de un producto en líneas de código; el índice de Fig., que mide la claridad de un párrafo en un texto;
el número de fallos encontrados en un producto software entregado; y el número de personas/día
requeridas para desarrollar un componente del sistema.

LAS MÉTRICAS SON DE CONTROL O DE PREDICCIÓN.

Las métricas de control suelen estar asociadas con los procesos, mientras que las métricas de
predicción lo están a los productos. Ejemplos de las métricas de control o de procesos son el esfuerzo
y el tiempo promedio requeridos para reparar los defectos encontrados. Ejemplos de métricas de
predicción son la complejidad ciclomática de un módulo, la longitud media de los identificadores de un
programa, y el número de atributos y operaciones asociadas con los objetos de un diseño.
Frecuentemente, es imposible medir los atributos de calidad del software directamente. Los atributos
de calidad como la mantenibilidad, la comprensión y la usabilidad son atributos externos que nos dicen
cómo ven el software los desarrolladores y los usuarios. Éstos se ven afectados por diversos factores
y no existe un camino simple para medirlos. Más bien es necesario medir atributos internos del
software (como su tamaño) y suponer que existe una relación entre lo que queremos medir y lo que
queremos saber.

Para que la medida del atributo interno sea un indicador útil de la característica externa, se deben
cumplir tres condiciones:
El atributo interno debe medirse de forma precisa
Debe existir una relación entre lo que se puede medir y el atributo de comportamiento externo.
Facilitador: L.I. Martín Camuñas Fausto
P á g i n a 6 | 20
Esta relación se comprende, ha sido validada y se puede expresar en términos de una fórmula o
modelo.
Las métricas del producto se dividen en dos clases:
Las métricas dinámicas, que son recogidas por las mediciones hechas en un programa en ejecución.

Las métricas estáticas, que son recogidas por las mediciones hechas en las representaciones del
sistema como el diseño, el programa o la documentación. Las métricas dinámicas ayudan a valorar la
eficiencia y la fiabilidad de un programa y por lo general están relacionadas de forma cercana con los
atributos de calidad del software. Las métricas estáticas ayudan avalorar la complejidad, la
comprensión y la mantenibilidad de un sistema de software; por lo general están relacionadas de
forma cercana con los atributos de calidad del software.

ANÁLISIS DE LAS MEDICIONES

Uno de los problemas con la recogida de datos cuantitativos en el software y en los proyectos de
software es comprender lo que significan realmente los datos. Es fácil malinterpretar los datos y hacer
inferencias incorrectas. Las mediciones se deben analizar cuidadosamente para comprender lo que
realmente significan.
Los procesos y productos para medir no están aislados de su entorno y los cambios en ese entorno
invalidan las comparaciones de los datos. Los datos cuantitativos de las actividades humanas no
siempre pueden tomar se como valores de entrada.

PUNTOS CLAVE

La gestión de la calidad del software permite señalar si éste tiene un escaso número de defectos y si
alcanza los estándares requeridos de mantenibilidad, fiabilidad, portabilidad, etcétera, las actividades
de la gestión de la calidad comprenden la garantía de la calidad que establece los estándares para el
desarrollo de software, la planificación de la calidad y el control de la calidad que comprueba el
software con respecto a los estándares definidos.
Un manual de calidad organizacional debe documentar un conjunto de procedimientos de garantía de
la calidad. Éste puede basarse en los modelos genéricos sugeridos en los estándares ISO 9000.
Los estándares de software son importantes para garantizar la calidad puesto que representan una
identificación de las «mejores prácticas». El proceso de control de calidad implica comprobar que el
proceso del software y el software a desarrollar concuerdan con estos estándares.
Las revisiones de los productos a entregar por el proceso del software incumben a un equipo de
personas los cuales comprobarán que se han seguido los estándares de calidad, las revisiones son
la técnica más utilizada para valorar la calidad.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 7 | 20
2.2.1 PSP y TSP
PSP

Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la

productividad personal de los programadores o ingenieros de software, en tareas
de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para
emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue
propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de
1997 con el lanzamiento del libro "An introduction to the Personal Software Process"
se dirige ahora a ingenieros juniors.

Se puede considerar como la guía de trabajo personal para ingenieros de software

en organizaciones que emplean un modelo CMMI con nivel de madurez o de
capacidad de procesos que implica la medición cualitativa y mejora de procesos.

Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que
tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP
se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador
cuando trabaja de forma individual.

PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja
sobre 3 niveles de la organización, los otros 2 son CMM y TSP.

El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo

de software, concentrándose en las practicas de trabajo de los ingenieros en una
forma individual, enseñando como manejar la calidad desde el principio de un
producto. PSP son nuestras propias métricas, que permiten estructurar y ordenar
nuestro trabajo del día a día (no solo de desarrollo de software, esto lo voy a explicar
mas adelante). El resultado de nuestro trabajo, además puede ser llevado a un
trabajo en equipo TSP (Team Process Software), el cual es “comandado” por un
sistema de gestión de la configuración y por supuesto, un Jefe de Proyecto quien
evalúa los resultados y avances de los miembros del equipo.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 8 | 20
TSP

Team Software Process (TSP) es un método de establecimiento y mejora del trabajo

en equipo para procesos software.

TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a

planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda
establecer prácticas de ingeniería avanzadas y así obtener productos eficientes,
fiables y de calidad. Está formado por dos componentes primarios que abarcan
distintos aspectos del trabajo en equipo:

Formación del equipo de trabajo.

Gestión del equipo de trabajo.
Existen diferentes metodologías para la mejora de procesos, la mayoría de ellas se
basa en la mejora de los procesos que dan como resultado un servicio o producto.
El TSP busca integrar un equipo que tenga como punto de partida la unificación del
mismo, para poder llevar a cabo todos aquellos procedimientos que puedan realizar
mejora a los procesos que desarrollan.

El Team Software Process (TSP) es un proceso de desarrollo para equipos de

ingenieros basado en CMMI, ayuda a conformar equipos para el desarrollo de
software de calidad. TSP proporciona directrices para ayudar a un equipo a
establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin
de que la organización pueda establecer prácticas de ingeniería avanzadas y así
obtener productos eficientes, fiables y de calidad.

TSP es una solución basada en procesos para resolver problemas de negocio, tales
como:

Predictibilidad de costo y tiempo

Mejora de productividad
Ciclos de desarrollo y mejora de calidad de productos.

Características de los grupos eficaces:

Miembros expertos en papeles de liderazgo y pertenencia.

Relaciones tranquilas y establecidas entre los miembros.
Los miembros se sienten atraídos por el grupo y son fieles.
Los valores y metas del grupo son los de sus integrantes
Los miembros están motivados por hacer lo que puedan por el grupo.
La interacción y toma de decisiones tiene lugar en el ambiente adecuado.
El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar
a cada miembro a adquirir su pleno potencial.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 9 | 20
Cada miembro acepta con gusto y sin resentimiento las metas y normas
establecidas.
Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.
Existe una atmósfera de creatividad.
El grupo conoce el “conformismo constructivo” y se sirve de él.
Existe gran motivación para iniciar y recibir las comunicaciones.
Los miembros son flexibles y adaptables en sus metas y actitudes.
Los miembros se sienten seguros al tomar decisiones que les Los miembros se
sienten seguros al tomar decisiones que les parecen apropiadas al entender la
filosofía de la operación.
Sus orígenes se deben a las limitaciones que el PSP (Personal Software Process,
su antecesor) tenía en el ámbito industrial. PSP resultó muy efectivo para que los
ingenieros pudiesen tener el control de su proceso personal mediante la mejora de
sus habilidades de estimación y la reducción de los defectos introducidos en los
productos sin afectar a su productividad, pero PSP sólo se enfocaba en las fases
de desarrollo de software (diseño y pruebas unitarias); la aplicación que lo
ingenieros hicieron del PSP dentro de las empresas resulto en prácticas no
satisfactorias.

Por tal motivo, Watts Humphrey desarrolló el TSP, el cual consideraba como parte
importante, además de lo previsto por el PSP, los requisitos, las pruebas de
integración, la documentación y otras actividades típicas en todo proyecto de
desarrollo, de igual manera incluía actividades como los roles de equipo,
interrelaciones dentro de la organización y la definición de un proceso de equipo
para ser utilizado dentro de los procesos existentes en la organización.

Los Roles (responsabilidades) en los equipos en STP son:

Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los
procesos y completen su trabajo tal y como se planeó. Realiza los reportes
semanales del avance del equipo.
Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.
Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del
trabajo.
Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del
proceso y a establecer y administrar el plan de calidad. Genera estándares para
obtener un trabajo uniforme. Modera las inspecciones y revisa cada artefacto
generado.
Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de
requerimientos de software y ayuda a dar a conocer la tecnología y en las
necesidades de apoyo administrativo. Administra el plan de configuración

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 10 | 20
Es necesario que los ingenieros que usan TSP estén formados en PSP. Con TSP,
los equipos encuentran y reparan defectos en etapas tempranas del proceso de
desarrollo, esto reduce de manera importante el tiempo de pruebas. Esto reduce de
manera importante el tiempo de pruebas. Con un testing más corto, el ciclo completo
se reduce.

A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como

individuos, es disciplinado y ágil, provee beneficios inmediatos y medibles y acelera
las iniciativas de mejora de procesos organizacionales.

En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se
realiza:

Lanzamiento
Estrategia
Plan
Requisitos
Diseño
Implementación
Pruebas
Postmortem

Los objetivos que tiene el TSP son:

Maximizar calidad software, minimizar costos.

Integrar equipos independientes de alto rendimiento que planeen su trabajo,
establezcan metas y sus sueños de sus procesos y planes.
Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como
ayudarlos a alcanzar su máxima productividad.
Acelerar la mejora continua de monitoreo.
Proveer de una guía para eL mejoramiento en organizaciones maduras

Sus entornos son:

CMM- Administración.
TSP- Equipo Ingenieros.
PSP-Ingeniero.

2.2.2 CMM
Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo
de evaluación de los procesos de una organización.
Fue desarrollado inicialmente para los procesos relativos al software por la
Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 11 | 20
El SEI es un centro de investigación y desarrollo patrocinado por el Departamento
de Defensa de los Estados Unidos de América y gestionado por la Universidad
Carnegie-Mellon. "CMM" es una marca registrada del SEI.

EL MODELO CMM

A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los

Estados Unidos de América, desarrolló una primera definición de un modelo de
madurez de procesos en el desarrollo de software, que se publicó en septiembre de
1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya
última versión (v1.1) se publicó en febrero de 1993.
Este modelo establece un conjunto de prácticas o procesos clave agrupados en
Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso
define un conjunto de buenas prácticas que habrán de ser:
Definidas en un procedimiento documentado
Provistas (la organización) de los medios y formación necesarios
Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
Medidas Verificadas

A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de

modo que una organización que tenga institucionalizadas todas las prácticas
incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de
madurez.

Los niveles son:

Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para
el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de
ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los
proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a
menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado
de los proyectos es impredecible.
Repetible. En este nivel las organizaciones disponen de unas prácticas
institucionalizadas de gestión de proyectos, existen unas métricas básicas y un
razonable seguimiento de la calidad. La relación con subcontratistas y clientes está
gestionada sistemáticamente.
Definido. Además de una buena gestión de proyectos, a este nivel las
organizaciones disponen de correctos procedimientos de coordinación entre
grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más
avanzado de métricas en los procesos. Se implementan técnicas de revisión por
pares (peer reviews).

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 12 | 20
Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de
métricas significativas de calidad y productividad, que se usan de modo sistemático
para la toma de decisiones y la gestión de riesgos. El software resultante es de alta
calidad.
Optimizado. La organización completa está volcada en la mejora continua de los
procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de
innovación.
Así es como el modelo CMM establece una medida del progreso, conforme al
avance en niveles de madurez. Cada nivel a su vez cuenta con un número de áreas
de proceso que deben lograrse. El alcanzar estas áreas o estadios se detecta
mediante la satisfacción o insatisfacción de varias metas claras y cuantificables. Con
la excepción del primer nivel, cada uno de los restantes Niveles de Madurez está
compuesto por un cierto número de Áreas Claves de Proceso, conocidas a través
de la documentación del CMM por su sigla inglesa: KPA.
Cada KPA identifica un conjunto de actividades y prácticas interrelacionadas, las
cuales cuando son realizadas en forma colectiva permiten alcanzar las metas
fundamentales del proceso.
Las KPAs pueden clasificarse en 3 tipos de proceso:

Gestión
Organizacional
Ingeniería.

Las prácticas que deben ser realizadas por cada Area Clave de Proceso están
organizadas en 5 Características Comunes, las cuales constituyen propiedades que
indican si la implementación y la institucionalización de un proceso clave es efectivo,
repetible y duradero.
Estas 5 características son:
Compromiso de la realización
La capacidad de realización
Las actividades realizadas
Las mediciones y el análisis
La verificación de la implementación.
Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una
guía útil para orientar sus esfuerzos. Además, el SEI proporciona formación a
evaluadores certificados (Lead Assesors) capacitados para evaluar y certificar el
nivel CMM en el que se encuentra una organización. Esta certificación es requerida
por el Departamento de Defensa de los Estados Unidos, pero también es utilizada
por multitud de organizaciones de todo el mundo para valorar a sus subcontratistas
de software.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 13 | 20
Se considera típico que una organización dedique unos 18 meses para progresar
un nivel, aunque algunas consiguen mejorarlo. En cualquier caso requiere un amplio
esfuerzo y un compromiso intenso de la dirección.
Como consecuencia, muchas organizaciones que realizan funciones de factoría de
software o, en general, outsourcing de procesos de software, adoptan el modelo
CMM y se certifican en alguno de sus niveles. Esto explica que uno de los países
en el que más organizaciones certificadas exista sea India, donde han florecido las
factorías de software que trabajan para clientes estadounidenses y europeos.
A partir de 2001, en que se presentó el modelo CMMI, el SEI ha dejado de
desarrollar el SW-CMM, cesando la formación de los evaluadores en diciembre de
2003, quienes dispondrán hasta fin de 2005 para reciclarse al CMMI. Las
organizaciones que sigan el modelo SW-CMM podrán continuar haciéndolo, pero
ya no podrán ser certificadas a partir de fin de 2005.

2.2.3 MOPROSOFT
Modelo de Procesos para la Industria del Software. Modelo para la mejora y
evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos
de software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería
de Software a través de la Facultad de Ciencias de la Universidad Nacional
Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para
obtener una norma mexicana que resulte apropiada a las características de tamaño
de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de
software. Moprosoft es el nombre del modelo en la comunidad universitaria y
profesional, y la norma técnica a la que da contenido es la NMX-059/01-NYCE-2005
que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicación de
su declaratoria en el Diario oficial de la Federació.

Moprosoft considera que los modelos de evaluación y mejora CMMI e ISO/IEC

15504 no resultan apropiados para empresas pequeñas y medianas de desarrollo y
mantenimiento de software. Sobre las áreas de procesos de los niveles 2 y 3 del
modelo SW-CMM e inspirándose en el marco de ISO/IEC 15504 se ha desarrollado
este modelo.

Criterios empleados

Se han aplicado los siguientes criterios para la elaboración de este modelo de

procesos:

La estructura de procesos resultante debe ser acorde a la estructura generalmente

empleada por las organizaciones de la industria del software (alta dirección, gestión
y operación)

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 14 | 20
La alta dirección tiene un papel importante a través de la planificación estratégica.
Debe actuar como promotor del buen funcionamiento de la organización a través de
su implicación en la revisión y mejora continua del modelo.
El modelo considera a la gestión como proveedora de recursos, procesos y
proyectos; así como responsable de la vigilancia del cumplimiento de los objetivos
estratégicos de la organización.
El modelo considera a la operación como ejecutora de los proyectos de desarrollo
y mantenimiento de software.
El modelo integra con claridad y consistencia los elementos indispensables para la
definición de los procesos y las relaciones entre ellos.
El modelo integra los elementos para realizar la administración de proyectos desde
un sólo proceso.
El modelo integra los elementos para realizar la ingeniería de productos de software
en un único marco que incluya los procesos precisos de soporte (verificación,
validación, documentación y control de la documentación).
El modelo destaca la importancia de la gestión de recursos, con especial relevancia
en aquellos que componen el conocimiento de la organización: productos
generados por proyectos, datos de los proyectos, mediciones, documentación de
procesos y datos cosechados a partir del uso y de las lecciones aprendidas.
Moprosoft se basa en los modelos de procesos ISO 9001:2000, en las áreas de
procesos de los niveles 2 y 3 de CMM-SW: CMM-SW v.1.1., en el marco general
ISO/IEC15504 y en prácticas y conceptos de PMBOK Y SWEBOK.
PROSOFT representa un campo diferente de apoyo a los empresarios de las
tecnologías de la información, es un sector diverso para hacer negocios y generar
fuentes de empleo dignas”

El Plan Nacional de Desarrollo 2001-2006 plantea el fomento a la industria y el

mercado De Tecnologías de la Información (TI) como estrategia para aumentar la
competitividad del País. Dado el gran potencial con que cuenta México para
desarrollar esta industria, la Secretaría de Economía, en coordinación con
organismos empresariales y empresas del Sector, diseñó el PROSOFT.

El Moprosoft se estructura en 3 categorías:

Categoría de Alta Dirección (DIR): Se establecen los lineamientos para los procesos
de la Categoría de Gerencia y se retroalimenta con la información generada por
ellos en apoyo a la estrategia de la organización.
Categoría de Gerencia (GER): Se definen los elementos para el funcionamiento de
los procesos de la Categoría de Operación en función de la estrategia de Dirección,
recibe y evalúa la información generada por éstos y comunica los resultados a la
Categoría de Alta Dirección.
Categoría de Operación (OPE): Se realizan las actividades de acuerdo a los
elementos proporcionados por la Categoría de Gerencia y entrega a ésta la
información y productos generados.
Facilitador: L.I. Martín Camuñas Fausto
P á g i n a 15 | 20
2.3 Impacto de la calidad en tiempo, costo y alcance del proyecto
La gestión deja de ser una tarea aislada para constituirse en una herramienta que
sirve para ejecutar las acciones necesarias que permitan ordenar, disponer y
organizar los recursos de un proyecto, utilizando procedimientos específicos y
optimizando la relación entre recursos y resultados.

Objetivos de la gestión: Conocer y hacer el mejor uso posible de los recursos

disponibles para satisfacer de manera óptima los objetivos perseguidos, teniendo
en cuenta las limitaciones que se puedan presentar.

Niveles de gestión
Las labores de gestión abarcan todos los ámbitos de un proyecto, incluyendo los
administrativos e incluso financieros, el alcance y la trascendencia de las acciones
que se ejecuten. En este ámbito se destacan los siguientes niveles:

Gestión del alcance: Comprende las actividades orientadas a garantizar el

cumplimiento de las tareas necesarias para lograr los objetivos del proyecto.
Gestión técnica o de proceso: Incluye las actividades necesarias para garantizar
que los resultados del proyecto satisfagan las necesidades y requerimientos de los
gestores o inversionistas.
Gestión del Tiempo: Comprende las actividades necesarias para asegurar que el
proyecto se ejecute en el plazo estimado y que los resultados (producción de bienes
o servicios) estén a disposición de los clientes o consumidores.
Gestión de costos: Asegura que las tareas se lleven a cabo dentro de los rangos
económicos impuestos (presupuesto del proyecto o recursos asignados para la
actividad correspondiente).
Gestión de calidad: Tiene que ver con las actividades que aseguran que el proyecto
satisface los requisitos bajo los cuales deben generarse los resultados.
Gestión de los recursos: Para que una empresa cumpla su misión, logre sus
objetivos y le entregue resultados favorables a los propietarios, es necesario que
cuente con recursos suficientes para que contribuyan a una gestión adecuada
incrementando la productividad de la empresa.
Gestión de la comunicación: Permite garantizar que la información formal e informal,
se genere, recopile, almacene y utilice de forma adecuada.
Gestión de compras y adquisiciones: Cuando el proyecto es de cierta complejidad,
se hace necesario definir algunos procedimientos que estén orientados a la correcta
selección y obtención de bienes y servicios que deben ser llevados de fuera de la
empresa o del proyecto.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 16 | 20
ALCANCES

El alcance de un proyecto llamado también alcance del trabajo es el trabajo que

debe hacerse para que el cliente se convenza de que las entregas (las cosas por
hacer), es decir el producto u objetos tangibles que han de suministrarse) cumplan
con los requisitos o criterios de aceptación acordados al comenzar el proyecto. Por
ejemplo, el alcance podría ser el trabajo de limpiar el suelo, de construir una casa,
poner la jardinería ornamental según las especificaciones hechas por el cliente y
aceptadas por el contratista.

GESTIÓN DEL ALCANCE

Comprende las actividades orientadas a garantizar el cumplimiento de las tareas
necesarias para lograr los objetivos del proyecto.
La gestión del alcance del proyecto se relaciona principalmente con la definición y
el control de lo que está y no está incluido en el proyecto.
En el contexto del proyecto, la palabra alcance puede referirse a lo siguiente:
Alcance del producto. Las características y funciones que caracterizan a un
producto, servicio o resultado.
Alcance del proyecto. El trabajo que debe realizarse para entregar un producto,
servicio o resultado con las funciones y características especificadas.

PLANIFICACIÓN DEL ALCANCE

El plan de gestión del alcance del proyecto es una herramienta de planificación que
describe cómo el equipo definirá el alcance del proyecto, desarrollará el enunciado
del alcance del proyecto detallado, definirá y desarrollará la estructura de desglose
del trabajo, verificará y controlará el alcance del proyecto.

HERRAMIENTAS Y TÉCNICAS

Análisis del Producto Técnicas como desglose del producto, análisis de sistemas,
ingeniería de sistemas, ingeniería del valor, análisis del valor y análisis funcional.
Identificación de Alternativas Las más comunes son la tormenta de ideas y el
pensamiento lateral.
Juicio de Expertos
Análisis de los Interesados Identifica la influencia y los intereses de los diversos
interesados y documenta sus necesidades, deseos y expectativas.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 17 | 20
VERIFICACIÓN DEL ALCANCE

La verificación del alcance es el proceso de obtener la aceptación formal por parte

de los interesados del alcance del proyecto completado y los productos entregables
relacionados.

Verificar el alcance del proyecto incluye revisar los productos entregables para
asegurarse de que cada uno se complete satisfactoriamente.

CONTROL DEL ALCANCE

El control del alcance del proyecto se encarga de influir sobre los factores que crean
cambios en el alcance del proyecto y de controlar el impacto de dichos cambios.
El control del alcance del proyecto también se usa para gestionar los cambios reales
cuando se producen, y está integrado con los demás procesos de control. Los
cambios no controlados a menudo se denominan corrupción del alcance del
proyecto. Los cambios son inevitables, con lo cual se impone algún tipo de proceso
de control de cambios.

ESTRUCTURA

Por estructuración se entiende la facilidad con que las funciones pueden ser
compartidas y la naturaleza jerárquica de la información a tratar. A medida que el
grado de estructuración aumenta, la posibilidad de estimar con precisión mejora y,
por consiguiente, el riesgo disminuye.
Bajo el concepto de la administración de proyectos, se asignan representantes de
cada uno de los departamentos funcionales de las divisiones al equipo asignado al
proyecto. Cada miembro del equipo deriva una guía funcional experta y control
administrativo del gerente de departamento. El equipo incluye al siguiente personal
clave:
Gerente de Proyectos
Ingeniero de Proyectos
Gerente de Construcción del proyecto
Coordinador de construcción del proyecto
Ingeniero de puesta en marcha del proyecto
Ingeniero de aseguramiento de la calidad del proyecto
Supervisor de costo y programas del proyecto
Administrador del proyecto
Gerente de aprovisionamiento del proyecto
Asistente del controlador del proyecto

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 18 | 20
ESPECIFICACIONES

El concepto en la preparación de planos y especificaciones es que los planos del

proyecto definen la geometría incluyendo dimensiones, forma y detalles mientras
que las especificaciones complementen esto definiendo aspectos generales,
materiales y la ejecución necesaria.
Muchos profesionales de la construcción confían en que los planos contienen lo
necesario para ejecutar su proyecto de infraestructura.
En el momento en que se requiere más información o cuando surgen discrepancias,
entonces buscan más detalles en las especificaciones. Es entonces donde muchas
veces aparecen problemas porque las especificaciones no son adecuadas y, en vez
de aclarar la intención del diseñador, crean complicaciones adicionales.

TIEMPO, COSTOS Y RECURSOS

La estimación del tiempo forma parte del proceso de Gestión del Tiempo de la
Administración de Proyectos.
La Gestión del Tiempo del Proyecto incluye los procesos necesarios para lograr la
conclusión del proyecto a tiempo. Los procesos de Gestión del Tiempo del Proyecto
incluyen lo siguiente:
Definición de las Actividades: identifica las actividades específicas del cronograma
que deben ser realizadas para producir los diferentes productos entregables del
proyecto.
Establecimiento de la Secuencia de las Actividades: identifica y documenta las
dependencias entre las actividades del cronograma.
Estimación de Recursos de las Actividades: estima el tipo y las cantidades de
recursos necesarios para realizar cada actividad del cronograma.
Estimación de la Duración de las Actividades: estima la cantidad de períodos
laborables que serán necesarios para completar cada actividad del cronograma.
Desarrollo del Cronograma: analiza las secuencias de las actividades, la duración
de las actividades, los requisitos de recursos y las restricciones del cronograma para
crear el cronograma del proyecto.
Control del Cronograma: controla los cambios del cronograma del proyecto.

COSTOS
La estimación de costos de una actividad es una evaluación cuantitativa de los
costes probables de los recursos necesarios para completar las actividades del
cronograma del proyecto. Este tipo de estimación puede presentarse en forma de
resumen o en detalle.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 19 | 20
Los costos se estiman para todos los recursos que se aplican a la estimación de
costos de la actividad. Esto incluye, entre otros, la mano de obra, los materiales, los
equipos, los servicios, las instalaciones, la tecnología de la información, y categorías
especiales como una asignación por inflación o una reserva para contingencias de
costo.

RECURSOS

La estimación de recursos y costes es una actividad importante que debe llevarse

a cabo con el mayor detalle posible, porque permite al comprador establecer una
aproximación al coste total y plazos del desarrollo del sistema.
Para ello se requiere experiencia, acceso a una buena información histórica y
determinación para confiar en medidas cuantitativas cuando todo lo que existe son
datos cualitativos.

Factores que afectan a esta estimación:

 La complejidad del proyecto, cuantificando la misma en función de:
 Número de módulos y nivel de interrelación entre los mismos.
 Número y tipo de las interfaces externas con otros sistemas, programas o
datos.
 Grado de distribución y heterogeneidad del entorno de implantación.
 Grado de sofisticación de las herramientas de desarrollo.
 Naturaleza de los algoritmos que se deben diseñar y programar.

Facilitador: L.I. Martín Camuñas Fausto

P á g i n a 20 | 20