2.

1 GESTION DE PROYECTOS DE SW UTILIZANDO 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 manufacturacin, la nocin de calidad viene dada por la similitud entre
el producto desarrollado y su especificacin. En un mundo ideal, esta definicin debera aplicarse a todos
los productos, pero, para sistemas de software, existen estos problemas:
1. La especificacin se orienta hacia las caractersticas del producto que el consumidor quiere. Sin
embargo, la organizacin desarrolladora tambin tiene requerimientos (como los de mantenimiento) que
no se incluyen en la especificacin.
2. No se sabe cmo especificar ciertas caractersticas de calidad (por ejemplo, mantenimiento) de una
forma no ambigua.
3. Es muy difcil redactar especificaciones concretas de software. Por lo tanto, aunque un producto se
ajuste a su especificacin, 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 especificacin del software y se tienen que disear
procedimientos de calidad que no se basen en una especificacin perfecta. En concreto, atributos del
software como mantenibilidad, seguridad o eficiencia no pueden ser especificados explcitamente. Sin
embargo, tienen un efecto importante en cmo es percibida la calidad del sistema.
Algunas personas piensan que la calidad puede lograrse definiendo estndares y procedimientos
organizacionales de calidad que comprueban si estos estndares son seguidos por el equipo de
desarrollo. Su argumento es que los estndares deben encapsular las buenas prcticas, las cuales nos
llevan inevitablemente a productos de alta calidad. En la prctica, sin embargo, es ms importante la
gestin de la calidad que los estndares y la burocracia asociada para asegurar el seguimiento de estos
estndares.
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
estndares y procedimientos son las bases de la gestin 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 estndares. Ellos ayudan a la gente interesada en
estos aspectos intangibles de calidad y fomentan comportamientos profesionales en todos los miembros
del equipo.
La gestin formal de la calidad es particularmente importante para equipos que desarrollan sistemas
grandes y complejos. La documentacin 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 documentacin de
calidad es tambin un medio de comunicacin sobre el ciclo de vida de un sistema. sta permite al grupo
responsabilizarse de la evolucin del sistema para saber qu ha hecho el equipo de desarrollo.
Para sistemas pequeos, la gestin de calidad es importante todava, pero se debe adoptar una
aproximacin ms informal. No son tan necesarios los documentos porque el grupo puede comunicarse
informalmente.
La clave de la calidad en el desarrollo de sistemas pequeos es el establecimiento de cultura de calidad
y asegurarse de que todos los miembros del equipo hacen una aproximacin positiva a la calidad del
software.

La gestin de calidad del software se estructura en tres actividades principales:

Garanta de la calidad. El establecimiento de un marco de trabajo de procedimientos y

estndares organizacionales que conduce a software de alta calidad.

Planificacin de la calidad. La seleccin de procedimientos y estndares adecuados a partir de

este marco de trabajo y la adaptacin de stos para un proyecto software especfico.

Control de la calidad. La definicin y fomento de los procesos que garanticen que los
procedimientos y estndares para la calidad del proyecto son seguidos por el equipo de
desarrollo de software.

La gestin de la calidad provee una comprobacin independiente de los procesos de desarrollo software.
Los procesos de gestin de la calidad comprueban las entregas del proyecto para asegurarse que
concuerdan con los estndares y metas organizacionales. El equipo de garanta de calidad debe ser
independiente del equipo de desarrollo para que puedan tener una visin objetiva del software. Ellos
transmitirn los problemas y las dificultades al gestor principal de la organizacin.

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

Hay un vnculo claro entre la calidad del proceso y del producto en produccin debido a que el proceso
es relativamente fcil de estandarizar y monitorizar.
El software no se manufactura, sino que se disea. El desarrollo de software es un proceso ms creativo
que mecnico. La calidad del producto, tambin se ve afectada por factores externos, como la novedad
de una aplicacin o la presin comercial para sacar un producto rpidamente.
En el desarrollo software, por lo tanto, la relacin entre la calidad del proceso y la calidad del producto es
muy compleja. Es difcil de medir los atributos de la calidad del software, en consecuencia, es difcil
explicar cmo influyen las caractersticas del proceso en estos atributos. Adems debido al papel del
diseo 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 gestin y mejora de
la calidad del proceso debe minimizar los defectos en el software entregado.
La gestin de la calidad del proceso implica:

Definirestndares de proceso.

Supervisar el proceso de desarrollo para asegurar que se sigan los estndares.

Hacer informes del proceso para el gestor del proyecto y para el comprador del software.

Un problema de la garanta de la calidad basada en el proceso es que el equipo de garanta de la

calidad (QA) insista en unos estndares 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.

2.2 ESTANDARES Y MTRICAS DEL SOFTWARE

Sera posible acelerar el proceso de revisin utilizando herramientas que procesaran el diseo
delsoftware o el programa, e hiciesen valoraciones automticas 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 medicin del software se refiere a derivar un valor numrico desde algn atributo del software o del
proceso software. Comparando estos valores entre s y con los estndares aplicados en la organizacin,
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.

Identificarcomponentesanmalos.

Una mtrica de software es cualquier tipo de medida relacionada con un sistema, proceso o
documentacin de software. Algunos ejemplos son las medidas que se utilizan para calcular el tamao
de un producto en lneas de cdigo; el ndice de Fig., que mide la claridad de un prrafo en un texto; el
nmero de fallos encontrados en un producto software entregado; y el nmero de personas/da
requeridas para desarrollar un componente del sistema.
LAS MTRICAS SON DE CONTROL O DE PREDICCIN.
Las mtricas de control suelen estar asociadas con los procesos, mientras que las mtricas de prediccin
lo estn a los productos. Ejemplos de las mtricas de control o de procesos son el esfuerzo y el tiempo
promedio requeridos para reparar los defectos encontrados. Ejemplos de mtricas de prediccin son la
complejidad ciclomtica de un mdulo, la longitud media de los identificadores de un programa, y el
nmero de atributos y operaciones asociadas con los objetos de un diseo.
Frecuentemente, es imposible medir los atributos de calidad del software directamente. Los atributos de
calidad como la mantenibilidad, la comprensin y la usabilidad son atributos externos que nos dicen
cmo ven el software los desarrolladores y los usuarios. stos se ven afectados por diversos factores y
no existe un camino simple para medirlos. Ms bien es necesario medir atributos internos del software
(como su tamao) y suponer que existe una relacin entre lo que queremos medir y lo que queremos
saber.
Para que la medida del atributo interno sea un indicador til de la caracterstica externa, se deben
cumplir tres condiciones:

El atributo interno debe medirse de forma precisa

Debe existir una relacin entre lo que se puede medir y el atributo de comportamiento externo.

Esta relacin se comprende, ha sido validada y se puede expresar en trminos de una frmula o
modelo.

Las mtricas del producto se dividen en dos clases:

Las mtricas dinmicas, que son recogidas por las mediciones hechas en un programa en
ejecucin.

Las mtricas estticas, que son recogidas por las mediciones hechas en las representaciones
del sistema como el diseo, el programa o la documentacin. Las mtricas dinmicas ayudan a
valorar la eficiencia y la fiabilidad de un programa y por lo general estn relacionadas de forma
cercana con los atributos de calidad del software. Las mtricas estticas ayudan avalorar la
complejidad, la comprensin y la mantenibilidad de un sistema de software; por lo general estn
relacionadas de forma cercana con los atributos de calidad del software.

ANLISIS 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 fcil 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 estn 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 gestin de la calidad del software permite sealar si ste tiene un escaso nmero de defectos
y si alcanza los estndares requeridos de mantenibilidad, fiabilidad, portabilidad, etctera, las
actividades de la gestin de la calidad comprenden la garanta de la calidad que establece los
estndares para el desarrollo de software, la planificacin de la calidad y el control de la calidad
que comprueba el software con respecto a los estndares definidos.

Un manual de calidad organizacional debe documentar un conjunto de procedimientos de

garanta de la calidad. ste puede basarse en los modelos genricos sugeridos en los
estndares ISO 9000.

Los estndares de software son importantes para garantizar la calidad puesto que representan
una identificacin de las mejores prcticas. El proceso de control de calidad implica comprobar
que el proceso del software y el software a desarrollar concuerdan con estos estndares.

Las revisiones de los productos a entregar por el proceso del software incumben a un equipo de
personas los cuales comprobarn que se han seguido los estndares de calidad, las revisiones
son la tcnica ms utilizada para valorar la calidad.

2.2.1 PSP y TSP

PSP
Es un conjunto de prcticas disciplinadas para la gestin 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 diseado 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 "Anintroduction to the Personal Software Process" se
dirige ahora a ingenieros juniors.
Se puede considerar como la gua 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 medicin 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 obsesin por la toma de datos y elaboracin 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 vrtices donde descansa un proceso de mejora que trabaja sobre 3 niveles de
la organizacin, 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,
concentrndose en las practicas de trabajo de los ingenieros en una forma individual, enseando
como manejar la calidad desde el principio de un producto. PSP son nuestras propias mtricas, que

permiten estructurar y ordenar nuestro trabajo del da a da (no solo de desarrollo de software, esto
lo voy a explicar mas adelante). El resultado de nuestro trabajo, adems puede ser llevado a un
trabajo en equipo TSP (TeamProcess Software), el cual es comandado por un sistema de gestin
de la configuracin y por supuesto, un Jefe de Proyecto quien evala los resultados y avances de los
miembros del equipo.
TSP
Team Software Process (TSP) es un mtodo 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 organizacin pueda establecer prcticas de
ingeniera avanzadas y as obtener productos eficientes, fiables y de calidad. Est formado por dos
componentes primarios que abarcan distintos aspectos del trabajo en equipo:

Formacin del equipo de trabajo.

Gestin del equipo de trabajo.

Existen diferentes metodologas para la mejora de procesos, la mayora 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 unificacin 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 organizacin pueda establecer prcticas de ingeniera avanzadas y as obtener productos
eficientes, fiables y de calidad.
TSP es una solucin 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.

Caractersticas de los grupos eficaces:

Miembros expertos en papeles de liderazgo y pertenencia.

Relaciones tranquilas y establecidas entre los miembros.

Los miembros se sienten atrados por el grupo y son fieles.

Los valores y metas del grupo son los de sus integrantes

Los miembros estn motivados por hacer lo que puedan por el grupo.

La interaccin 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.

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 atmsfera de creatividad.

El grupo conoce el conformismo constructivo y se sirve de l.

Existe gran motivacin 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 filosofa de la operacin.

Sus orgenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tena 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 estimacin y la reduccin de los defectos
introducidos en los productos sin afectar a su productividad, pero PSP slo se enfocaba en las fases de
desarrollo de software (diseo y pruebas unitarias); la aplicacin que lo ingenieros hicieron del PSP
dentro de las empresas resulto en prcticas no satisfactorias.
Por tal motivo, Watts Humphrey desarroll el TSP, el cual consideraba como parte importante, adems
de lo previsto por el PSP, los requisitos, las pruebas de integracin, la documentacin y otras actividades
tpicas en todo proyecto de desarrollo, de igual manera inclua actividades como los roles de equipo,
interrelaciones dentro de la organizacin y la definicin de un proceso de equipo para ser utilizado dentro
de los procesos existentes en la organizacin.
Los Roles (responsabilidades) en los equipos en STP son:

Lder 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 reportessemanalesdelavance del equipo.

Gestor de desarrollo: Gua al equipo en el diseo y desarrollo del producto.

Gestor de Planificacin: Apoya y gua al equipo en la planificacin 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 estndares 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 tecnologa y en las necesidades de apoyo administrativo.
Administra el plan de configuracin

Es necesario que los ingenieros que usan TSP estn 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 ms corto, el ciclo completo se reduce.
A diferencia de otros mtodos, TSP mejora el desempeo 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 nmero de ciclos. Dentro de cada ciclo se realiza:

Lanzamiento

Estrategia

Plan

Requisitos

Diseo

Implementacin

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
san sueos de sus procesos y planes.

Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a
alcanzar su mxima productividad.

Acelerar la mejora continua de monitoreo.

Proveer de una gua para e mejoramiento en organizaciones maduras

Susentornos son:

CMM- Administracin.

TSP- EquipoIngenieros.

PSP-Ingeniero

Modelo de Capacidad y Madurez o CMM (CapabilityMaturityModel), es un modelo de evaluacin de los

procesos de una organizacin.
Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie-Mellon
para el SEI (Software EngineeringInstitute). El SEI es un centro de investigacin y desarrollo patrocinado
por el Departamento de Defensa de los Estados Unidos de Amrica y gestionado por la Universidad
Carnegie-Mellon. "CMM" es una marca registrada del SEI.

2.2.2 EL MODELO CMM

A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de
Amrica, desarroll una primera definicin 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 SWCMM(CMM for Software), cuya ltima versin (v1.1) se public en febrero de 1993.
Este modelo establece un conjunto de prcticas o procesos clave agrupados en reas Clave de Proceso
(KPA - Key ProcessArea). Para cada rea de proceso define un conjunto de buenas prcticas que habrn
de ser:

Definidas en un procedimientodocumentado

Provistas (la organizacin) de los medios y formacin necesarios

Ejecutadas de un modo sistemtico, universal y uniforme (institucionalizadas)

Medidas

Verificadas

A su vez estas reas de Proceso se agrupan en cinco "niveles de madurez", de modo que una
organizacin que tenga institucionalizadas todas las prcticas 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 tcnicas correctas de ingeniera, los esfuerzos se
ven minados por falta de planificacin. El xito de los proyectos se basa la mayora de las veces
en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y
sobrecostes. El resultado de los proyectosesimpredecible.

Repetible. En este nivel las organizaciones disponen de unas prcticas institucionalizadas de

gestin de proyectos, existen unas mtricas bsicas y un razonable seguimiento de la calidad. La
relacin con subcontratistas y clientesestgestionadasistemticamente.

Definido. Adems de una buena gestin de proyectos, a este nivel las organizaciones disponen
de correctos procedimientos de coordinacin entre grupos, formacin del personal, tcnicas de
ingeniera ms detallada y un nivel ms avanzado de mtricas en los procesos. Se
implementantcnicas de revisinpor pares (peer reviews).

Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de mtricas

significativas de calidad y productividad, que se usan de modo sistemtico para la toma de
decisiones y la gestin de riesgos. El software resultantees de altacalidad.

Optimizado. La organizacin completa est volcada en la mejora continua de los procesos. Se

hace uso intensivo de las mtricas y se gestiona el proceso de innovacin.

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 nmero de reas de proceso que deben lograrse. El
alcanzar estas reas o estadios se detecta mediante la satisfaccin o insatisfaccin de varias metas
claras y cuantificables. Con la excepcin del primer nivel, cada uno de los restantes Niveles de Madurez
est compuesto por un cierto nmero de reas Claves de Proceso, conocidas a travs de la
documentacin del CMM por su sigla inglesa: KPA.
Cada KPA identifica un conjunto de actividades y prcticas interrelacionadas, las cuales cuando son
realizadas en forma colectiva permiten alcanzar las metas fundamentales del proceso. Las KPAs
puedenclasificarse en 3 tipos de proceso:

Gestin

Organizacional

Ingeniera.

Las prcticas que deben ser realizadas por cada Area Clave de Proceso estn organizadas en 5
Caractersticas Comunes, las cuales constituyen propiedades que indican si la implementacin y la
institucionalizacin de un proceso clave es efectivo, repetible y duradero.
Estas 5 caractersticas son:

Compromiso de la realizacin

La capacidad de realizacin

Las actividadesrealizadas

Las mediciones y el anlisis

La verificacin de la implementacin.

Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una gua til para orientar
sus esfuerzos. Adems, el SEI proporciona formacin a evaluadores certificados (Lead Assesors)
capacitados para evaluar y certificar el nivel CMM en el que se encuentra una organizacin. Esta
certificacin es requerida por el Departamento de Defensa de los Estados Unidos, pero tambin es
utilizada por multitud de organizaciones de todo el mundo para valorar a sus subcontratistas de
software.
Se considera tpico que una organizacin 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 direccin.
Como consecuencia, muchas organizaciones que realizan funciones de factora 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 pases en el que ms organizaciones certificadas exista sea India,
donde han florecido las factoras 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 formacin de los evaluadores en diciembre de 2003, quienes dispondrn hasta fin de 2005
para reciclarse al CMMI. Las organizaciones que sigan el modelo SW-CMM podrn continuar hacindolo,
pero ya no podrn 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 evaluacin de los procesos
de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la Asociacin
Mexicana para la Calidad en Ingeniera de Software a travs de la Facultad de Ciencias de la
Universidad Nacional Autnoma de Mxico (UNAM) y a solicitud de la Secretara de Economa para
obtener una norma mexicana que resulte apropiada a las caractersticas de tamao de la gran mayora
de empresas mexicanas de desarrollo y mantenimiento de software. Moprosoft es el nombre del modelo
en la comunidad universitaria y profesional, y la norma tcnica a la que da contenido es la NMX-059/01NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicacin de su
declaratoria en el Diario Oficial de la Federacin.
Moprosoft considera que los modelos de evaluacin y mejora CMMI e ISO/IEC 15504 no resultan
apropiados para empresas pequeas y medianas de desarrollo y mantenimiento de software. Sobre las
reas de procesos de los niveles 2 y 3 del modelo SW-CMM e inspirndose en el marco de ISO/IEC
15504 se ha desarrollado este modelo.
Criterios empleados
Se han aplicado los siguientes criterios para la elaboracin 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 direccin, gestin y operacin)

La alta direccin tiene un papel importante a travs de la planificacin estratgica. Debe actuar
como promotor del buen funcionamiento de la organizacin a travs de su implicacin en la
revisin y mejora continua del modelo.

El modelo considera a la gestin como proveedora de recursos, procesos y proyectos; as como

responsable de la vigilancia del cumplimiento de los objetivos estratgicos de la organizacin.

El modelo considera a la operacin como ejecutora de los proyectos de desarrollo y

mantenimiento de software.

El modelo integra con claridad y consistencia los elementos indispensables para la definicin de
los procesos y las relaciones entre ellos.

El modelo integra los elementos para realizar la administracin de proyectos desde un slo
proceso.

El modelo integra los elementos para realizar la ingeniera de productos de software en un nico
marco que incluya los procesos precisos de soporte (verificacin, validacin, documentacin y
control de la documentacin).

El modelo destaca la importancia de la gestin de recursos, con especial relevancia en aquellos

que componen el conocimiento de la organizacin: productos generados por proyectos, datos de
los proyectos, mediciones, documentacin 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 prcticas y
conceptos de PMBOK Y SWEBOK.

PROSOFT representa un campo diferente de apoyo a los empresarios de las tecnologas de la

informacin, 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 Tecnologas

de la Informacin (TI) como estrategia para aumentar la competitividad del Pas. Dado el gran potencial
con que cuenta Mxico para desarrollar esta industria, la Secretara de Economa, en coordinacin con
organismos empresariales y empresas del Sector, dise el PROSOFT.
El Moprosoft se estructura en 3 categoras:

Categora de Alta Direccin (DIR): Se establecen los lineamientos para los procesos de la
Categora de Gerencia y se retroalimenta con la informacin generada por ellos en apoyo a
la estrategia de la organizacin.

Categora de Gerencia (GER): Se denen los elementos para el funcionamiento de los procesos
de la Categora de Operacin en funcin de la estrategia de Direccin, recibe y evala la
informacin generada por stos y comunica los resultados a la Categora de Alta Direccin.

Categora de Operacin (OPE): Se realizan las actividades de acuerdo a los elementos

proporcionados por la Categora de Gerencia y entrega a sta la informacin y
productos generados

2.3 Impacto de la calidad en tiempo, costo y alcance

del proyecto
La gestin 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 especficos y optimizando la relacin entre recursos y resultados.
Objetivos de la gestin: 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 gestin
Las labores de gestin 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:

Gestin del alcance: Comprende las actividades orientadas a garantizar el cumplimiento de las
tareas necesarias para lograr los objetivos del proyecto.

Gestin tcnica o de proceso: Incluye las actividades necesarias para garantizar que los
resultados del proyecto satisfagan las necesidades y requerimientos de los gestores o
inversionistas.

Gestin del Tiempo: Comprende las actividades necesarias para asegurar que el proyecto se
ejecute en el plazo estimado y que los resultados (produccin de bienes o servicios) estn a
disposicin de los clientes o consumidores.

Gestin de costos: Asegura que las tareas se lleven a cabo dentro de los rangos econmicos
impuestos (presupuesto del proyecto o recursos asignados para la actividad correspondiente).

Gestin de calidad: Tiene que ver con las actividades que aseguran que el proyecto satisface los
requisitos bajo los cuales deben generarse los resultados.

Gestin de los recursos: Para que una empresa cumpla su misin, logre sus objetivos y le
entregue resultados favorables a los propietarios, es necesario que cuente con recursos
suficientes para que contribuyan a una gestin adecuada incrementando la productividad de la
empresa.

Gestin de la comunicacin: Permite garantizar que la informacin formal e informal, se genere,

recopile, almacene y utilice de forma adecuada.

Gestin de compras y adquisiciones: Cuando el proyecto es de cierta complejidad, se hace

necesario definir algunos procedimientos que estn orientados a la correcta seleccin y
obtencin de bienes y servicios que deben ser llevados de fuera de la empresa o del proyecto.

ALCANCES
El alcance de un proyecto llamado tambin 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 aceptacin acordados al comenzar el
proyecto. Por ejemplo, el alcance podra ser el trabajo de limpiar el suelo, de construir una casa, poner la
jardinera ornamental segn las especificaciones hechas por el cliente y aceptadas por el contratista.
GESTIN DEL ALCANCE

Comprende las actividades orientadas a garantizar el cumplimiento de las tareas necesarias para
lograr los objetivos del proyecto.

La gestin del alcance del proyecto se relaciona principalmente con la definicin 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:

1. Alcance del producto. Las caractersticas y funciones que caracterizan a un producto, servicio o
resultado.
2. Alcance del proyecto. El trabajo que debe realizarse para entregar un producto, servicio o
resultado con las funciones y caractersticas especificadas.

PLANIFICACIN DEL ALCANCE

El plan de gestin del alcance del proyecto es una herramienta de planificacin que describe cmo 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 TCNICAS

Anlisis del Producto Tcnicas como desglose del producto, anlisis de sistemas, ingeniera de
sistemas, ingeniera del valor, anlisis del valor y anlisis funcional.

Identificacin de Alternativas Las ms comunes son la tormenta de ideas y el pensamiento

lateral.

Juicio de Expertos

Anlisis de los Interesados Identifica la influencia y los intereses de los diversos interesados y
documenta sus necesidades, deseos y expectativas.

VERIFICACIN DEL ALCANCE

La verificacin del alcance es el proceso de obtener la aceptacin 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 tambin se usa para gestionar los cambios reales cuando se
producen, y est integrado con los dems procesos de control. Los cambios no controlados a
menudo se denominan corrupcin del alcance del proyecto. Los cambios son inevitables, con lo
cual se impone algn tipo de proceso de control de cambios.

ESTRUCTURA

Por estructuracin se entiende la facilidad con que las funciones pueden ser compartidas y la
naturaleza jerrquica de la informacin a tratar. A medida que el grado de estructuracin
aumenta, la posibilidad de estimar con precisin mejora y, por consiguiente, el riesgo disminuye.

Bajo el concepto de la administracin 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 gua funcional experta y control administrativo del gerente de
departamento. El equipoincluye al siguiente personal clave:

1. Gerente de Proyectos
2. Ingeniero de Proyectos
3. Gerente de Construccin del proyecto
4. Coordinador de construccin del proyecto

5. Ingeniero de puesta en marcha del proyecto

6. Ingeniero de aseguramiento de la calidad del proyecto
7. Supervisor de costo y programas del proyecto
8. Administrador del proyecto
9. Gerente de aprovisionamiento del proyecto
10. Asistente del controlador del proyecto

ESPECIFICACIONES

El concepto en la preparacin de planos y especificaciones es que los planos del proyecto

definen la geometra incluyendo dimensiones, forma y detalles mientras que las especificaciones
complementen esto definiendo aspectos generales, materiales y la ejecucin necesaria.

Muchos profesionales de la construccin confan en que los planos contienen lo necesario para
ejecutar su proyecto de infraestructura.

En el momento en que se requiere ms informacin o cuando surgen discrepancias, entonces

buscan ms detalles en las especificaciones. Es entonces donde muchas veces aparecen
problemas porque las especificaciones no son adecuadas y, en vez de aclarar la intencin del
diseador, crean complicaciones adicionales.

TIEMPO, COSTOS Y RECURSOS

La estimacin del tiempo forma parte del proceso de Gestin del Tiempo de la Administracin de
Proyectos.
La Gestin del Tiempo del Proyecto incluye los procesos necesarios para lograr la conclusin del
proyecto a tiempo. Los procesos de Gestin del Tiempo del Proyecto incluyen lo siguiente:

Definicin de las Actividades: identifica las actividades especficas 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.

Estimacin de Recursos de las Actividades: estima el tipo y las cantidades de recursos

necesarios para realizar cada actividad del cronograma.

Estimacin de la Duracin de las Actividades: estima la cantidad de perodos laborables que

sern necesarios para completar cada actividad del cronograma.

Desarrollo del Cronograma: analiza las secuencias de las actividades, la duracin 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 estimacin de costos de una actividad es una evaluacin cuantitativa de los costes probables
de los recursos necesarios para completar las actividades del cronograma del proyecto. Este tipo
de estimacin puede presentarse en forma de resumen o en detalle.

Los costos se estiman para todos los recursos que se aplican a la estimacin de costos de la
actividad. Esto incluye, entre otros, la mano de obra, los materiales, los equipos, los servicios, las
instalaciones, la tecnologa de la informacin, y categoras especiales como una asignacin por
inflacin o una reserva para contingencias de costo.

RECURSOS

La estimacin de recursos y costes es una actividad importante que debe llevarse a cabo con el
mayor detalle posible, porque permite al comprador establecer una aproximacin al coste total y
plazos del desarrollo del sistema.

Para ello se requiere experiencia, acceso a una buena informacin histrica y determinacin
para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.

Factores que afectan a esta estimacin:

La complejidad del proyecto, cuantificando la misma en funcin de:

Nmero de mdulos y nivel de interrelacin entre los mismos.

Nmero y tipo de las interfaces externas con otros sistemas, programas o datos.

Grado de distribucin y heterogeneidad del entorno de implantacin.

Grado de sofisticacin de las herramientas de desarrollo.

Naturaleza de los algoritmos que se deben disear y programar.