Modalidad a Distancia

ura: Gestin de Proyectos de S

Actividad: 5, 2.1 Gestion de Proyectos usando Marco de Calidad.
No. De control: 12380905

Contenido
Contenido.................................................................................................... 1
2.1. La gestin de proyectos usando un marco de calidad.............................2
2.2 Estndares y Mtricas de calidad en la ingeniera de SW......................10
1.

ISO 9000.-........................................................................................... 10

2.

CMMI - CMM........................................................................................ 11

3.

SPICE.................................................................................................. 12

MTRICAS.................................................................................................. 13
MTRICAS PARA LA CALIDAD DEL SOFTWARE...........................................13
EFICACIA DE LA ELIMINACIN DE DEFECTOS............................................14
2.2.1 PSP y TSP............................................................................................ 15
PSP............................................................................................................ 15
TSP............................................................................................................ 16
2.2.2 CMM.................................................................................................... 18
EL MODELO CMM....................................................................................... 18
2.2.3 MOPROSOFT........................................................................................ 20
Bibliografa................................................................................................... 22

2.1. La gestin de proyectos usando un marco de

calidad
La calidad es un concepto complejo y con diferentes facetas, y en
consecuencia debe ser estudiado en diferentes perspectivas (D.
Garvin, 1982).
Tras analizar campos diferentes como la filosofa, la economa o el
marketing, existen 5 perspectivas desde la cuales la calidad puede
ser definida y entendida segn Garvin, estas son:
1. Visin trascendental de la calidad. Tambin denominada
calidad relativa. Hace referencia el hecho de que la calidad es
fcil de percibir y reconocer, pero difcil de definir. Segn esta
perspectiva, todos tenemos un concepto similar de lo que es la
calidad del software, algo as como un ideal que habra de
alcanzar. No obstante, que es difcil que el software, una vez
construido, tenga la perfeccin de un software ideal que
sirviese al mismo fin.
2. Perspectiva del usuario. Segn esta perspectiva, la calidad
se entiende como conformidad con aquello que el cliente
espera recibir y que fue establecido en las especificaciones del
software. A diferencia de la perspectiva anterior, la perspectiva
del usuario permite medir la calidad en trminos concretos:
cuanto mayor sea el grado de cercana entre las necesidades
del usuario y las caractersticas proporcionadas por el software,
mayor ser su calidad.
3. Perspectiva de la produccin. Identifica la calidad del
producto con la calidad de los procesos de produccin y postventa. Segn esta perspectiva, todo producto fabricado de
acuerdo con estndares regulados de calidad podr ser
considerado un producto de calidad, posiblemente mejor que
otros que no hayan sido fabricados segn este tipo de criterios.
sta es la visi0n de la calidad del estndar ISO 9001 y del
modelo de madurez CMM.
4. Perspectiva del producto. Esta perspectiva, relaciona la
calidad con ciertas caractersticas de este, tales como la
facilidad de mantenimiento, la funcionalidad o su fiabilidad. A
diferencia de las anteriores que observan la calidad del software
y como es percibida exteriormente, esta perspectiva apunta a la
calidad interna del software. Es la perspectiva que recoge, por
ejemplo, el estndar IEEE 1061-1992, donde se enuncia un
conjunto de atributos a estudiar en el software construido.

5. La perspectiva del valor. Establece una relacin entre la

calidad del dinero que el cliente est dispuesto a pagar y la
calidad del producto. Se trata de una forma pragmtica de
entender la calidad, pues llegando a un punto donde existe un
conflicto entre lo que el cliente est dispuesto a pagar y el costo
real de lo que solicita, los gestores del desarrollo tendrn que
decidir qu nivel de calidad puede implementarse para
satisfacer las necesidades del cliente, pero teniendo en
cuenta que dicho cliente no est dispuesto a asumir los
costos de la mejor de las implementaciones posibles.
Los clientes o el departamento de marketing tienen una perspectiva
de la calidad ms inclinada a la perspectiva del usuario la cual busca
que el software abarque sus necesidades y expectativas, que no
implique mucho esfuerzo para aprender a utilizarlo, fcil de usar y
que en cuestin de fallos incurra en lo mnimo.
Un desarrollador se inclina ms por la perspectiva del producto:
cantidad y tipo de errores, bajo impacto de las modificaciones y
facilidad para la comprensin de su cdigo, son algunos de los puntos
ms importantes desde sta perspectiva.
En cuanto a la visin de un comprador es centrada hacia la
perspectiva de valor: ms relacionado hacia la calidad y precio
bsicamente.
Todo esto hace que en numerosas ocasiones surjan conflictos
entre los diferentes actores por cuestiones relacionadas con la
calidad, ya que cada uno tiene, como se ha visto, diferentes
perspectivas de la misma.

Calidad del producto.

La calidad del producto apunta a los atributos internos del
software
como
fuente
de
calidad,
a diferencia de otras
perspectivas que evalan la calidad desde un punto de vista externo,
midiendo la calidad en funcin de cmo sta se percibe sin
evaluar las interioridades del producto en s.
Se denomina calidad del software el grado en que un software
posee una combinacin de atributos deseables.

Esta definicin de calidad, orientada a la cuantificacin y

medida de la misma, coincide con la nocin de calidad de los
modelos ms clsicos como el de McCall, el de Bohm o el que define
el estndar de calidad ISO/IEC 9126. A continuacin se estudian estos
modelos.

Modelo de calidad de McCall

Reconociendo la naturaleza intangible y hasta cierto punto
abstracta de la calidad, muchos autores han publicado modelos
que tratan de caracterizar el software de modo que resulte ms fcil
evaluar y medir los costos y beneficios de la calidad del software. El
modelo de McCall (1977) fue creado para las fuerzas areas
norteamericanas con la intencin de acercar las visiones de
calidad de los desarrolladores y usuarios. Es de especial
importancia por ser histricamente el primero y la base de
esfuerzos posteriores, y se organiza en torno a tres tipos de
caractersticas de calidad:
1. Factores de calidad, que permite especificar cmo ven el
software sus usuarios desde el exterior.
2. Criterios de calidad, que identifica cmo debe construirse
internamente el software desde la perspectiva del desarrollador.
3. Mtricas de calidad, que indican cmo controlar y medir la
calidad.
Tal y como se muestra en la siguiente figura, este modelo define tres
perspectivas desde las que deben estudiarse los once factores que
en total se computan en la medida de la calidad de un producto
de software. Estas perspectivas son:

Revisin del producto. Esta perspectiva estudia la capacidad del

producto para adaptarse a los cambios. Se tiene en cuenta
aquellos factores que influyen en la capacidad de adaptacin del

producto, tales como la facilidad de mantenimiento (disposicin para

ser modificado para ser corregido, adaptado o ampliado), la
flexibilidad (capacidad para introducir cambios en funcin de las
necesidades de negocio) y la facilidad de evaluacin (capacidad para
validar los requisitos establecidos para el software).
Transicin del producto. Esta perspectiva identifica los factores de
calidad que influye en la capacidad que tiene un cierto software
para adaptarse a distintos contextos de operacin. As, tiene en
cuenta factores tales como la reusabilidad, portabilidad o la
interoperabilidad.
Operacin del producto. Esta perspectiva identifica aquellos
factores de calidad que tienen que ver con la forma en que el
software lleva a cabo sus funcionalidades, y en la medida en que
cumple con sus especificaciones. As, tiene en cuenta la correccin
(que las funcionalidades solicitadas en su especificacin se
encuentren disponibles), la fiabilidad (qu fallos tiene el sistema en
operacin), la
eficiencia
en trminos de uso de recursos, la
integridad (proteccin contra accesos no autorizados a la informacin)
y la usabilidad.
En suma, los once factores de calidad apuntados por McCall
estn organizados en las tres perspectivas anteriores. Para
evaluar la calidad de un software, ser necesario medir dichos
factores, para lo cual el modelo establece el siguiente proceso:

1. Especificar los requisitos de calidad del producto software

a desarrollar, seleccionando aquellos aspectos que tengan
relacin con la calidad deseada.
2. Establecer los factores de calidad (de entre los once
descritos) sobre los que aplicar los requisitos de calidad
establecidos para el proyecto.
3. Evaluar los factores seleccionados mediante criterios que el
mtodo proporciona para cada factor.
As por ejemplo, si en la evaluacin de la calidad de un cierto
software hemos seleccionado la facilidad de mantenimiento como
factor de calidad, evaluaremos dicho factor mediante los criterios
especficos para el mismo.
En el caso de la facilidad de
mantenimiento
dichos
criterios
son
la
modularidad,
la
simplicidad, la concisin, y la auto descripcin.

MODELO DE BOHM
El modelo de Bohm (1978) es otro modelo de calidad basado
en la identificacin de un cierto nmero de caractersticas de
calidad para el software. Posterior al modelo de McCall, su
aportacin fundamental es la definicin de lo que Bohm
denomina utilidades principales, un reconocimiento explcito de que
para ser considerado de calidad, un sistema de software debe ser
fundamentalmente til.
A partir de este concepto de utilidad, Bohm plantea un modelo
jerrquico en el que se definen tres utilidades de alto nivel, que seran
los requisitos bsicos del software. Dichas utilidades son las
siguientes:

Utilidad tal y como est, que representa hasta qu

software (tal y como est en este momento) es fcil
fiable y eficiente.
Facilidad de mantenimiento, que se concreta en la
para identificar qu es necesario modificar, as

punto el
de usar,
facilidad
como la

facilidad de modificacin o de ejecucin de las pruebas sobre el

elemento modificado.
Portabilidad, esto es, la facilidad para utilizar el software en un
nuevo entorno, distinto a aquel en que se est utilizando en
este momento.

Estos tres usos principales representan el primer nivel de la jerarqua

del modelo de Bohm. En el segundo nivel, se identifican siete
factores de calidad que se asocian con los tres usos del primer nivel.
Estos factores son los siguientes:
1. Portabilidad, representa la facilidad para utilizar el software en
nuevos entornos (sistemas operativos, bases de datos, etc.).
2. Fiabilidad, que viene indicada como la ausencia de defectos.
3. Eficiencia, es decir, mnimo uso de recursos mediante el
correcto funcionamiento del sistema.
4. Usabilidad, entendida desde el punto de vista de la
ingeniera humana y la ergonoma, aunque comnmente se
resume como la facilidad de uso del software.
5. Facilidad de evaluacin, en concreto, la validacin de
que el software cumple con los requisitos establecidos.
6. Comprensibilidad, o facilidad para entender el propsito y
estructura del software.
7. Flexibilidad, esto es, facilidad para modificar el software ante
cambios en los requisitos o aparicin de otros nuevos.

Estos factores de calidad se descomponen a su vez en elementos

primitivos que pueden ser medidos. As por ejemplo, y tal y como se

muestra en la figura anterior, la portabilidad puede medirse en

funcin de dos elementos, su independencia con respecto al
dispositivo y el grado en que dicho software est autocontenido. Al
igual que en el modelo de McCall, el objetivo final es medir la calidad
desde los elementos de ms bajo nivel del modelo, y utilizar estas
medidas para mejorar los productos desarrollados.

El modelo de calidad ISO/IEC 9126

El estndar ISO/IEC 9126, parcialmente basado en esfuerzos
anteriores como el modelo de McCall y el de Bohm, es un estndar
internacional para la evaluacin de la calidad del software. Su
objetivo principal es proporcionar tanto una especificacin de la
calidad de productos software y un modelo para su evaluacin. Define
para ello un lenguaje comn que permite a los usuarios especificar
sus requisitos de calidad y a los desarrolladores y evaluadores
entender dichos requisitos, para posteriormente tratar de
incorporarlos al software en desarrollo. ISO/IEC 9126 aspira a
establecer
medidas
objetivas
de
calidad, huyendo
deliberadamente de lo opinable y eliminando en lo posible toda
subjetividad. Tambin pretende conseguir que la evaluacin de la
calidad
sea
reproducible
y sistemtica,
de
modo
que
evaluaciones de un mismo software realizadas por personas
diferentes en momentos distintos deberan dar el mismo resultado
si el software no ha sufrido modificacin alguna entre ambas
evaluaciones como lo muestra la siguiente figura.

El estndar ISO/IEC 9126 se divide en cuatro partes:

1. Modelo de calidad (ISO/IEC 9126-1:2001). Describe el marco
del modelo de calidad y las relaciones entre los diferentes

enfoques
de
la
misma,
e
identifica
las
distintas
caractersticas de calidad de los productos de software.
2. Mtricas externas (ISO/IEC TR 9126-2:2003). Proporciona un
conjunto de mtricas que permiten medir las caractersticas
de calidad externas definidas en el modelo de calidad
descrito en ISO/IEC 9126-1:2001.
3. Mtricas internas (ISO/IEC TR 9126-3:2003). Describe
mtricas para medir aquellas caractersticas internas de
calidad definidas en el modelo descrito en ISO/IEC 9126-1.
4. Calidad en las mtricas en uso (ISO/IEC TR 9126-4:2004).
Identifica las mtricas que permitirn medir la calidad desde el
punto de vista del usuario.

La primera parte ISO/IEC 9126-1:2001 establece el modelo de

calidad. Similar a los modelos de McCall, Bohm, FURPS y
otros que veremos ms adelante, se basa hasta cierto punto en
las ideas aportadas por dichos modelos. As, define 6
caractersticas
de calidad externas del software que son las
siguientes: funcionalidad, fiabilidad, usabilidad, eficiencia, facilidad de
mantenimiento y portabilidad. Cada una de estas caractersticas se
divide a su vez en varias sub-caractersticas (atributos tanto
externos como internos) que pueden ser medidos con mtricas
especficas segn se muestra en la tabla siguiente:

Las mtricas externas de la segunda parte ISO/IEC TR 9126-2:2003

miden el comportamiento del sistema computacional en su conjunto,
lo que incluye el software pero no se limita nicamente al mismo. Las
mtricas internas de la tercera parte del modelo ISO/IEC TR 91263:2003, por el contrario, miden el propio software. Las mtricas
de calidad en uso ISO/IEC TR 9126-4:2004, por ltimo, miden los
efectos del software en un contexto especfico de utilizacin. Esta
parte del estndar, la calidad en uso, especifica cuatro caractersticas
que son efectividad, productividad, seguridad y satisfaccin,
las cuales son tomadas como indicadores de la calidad tal y
como se percibe en funcin del cumplimiento de las caractersticas
de calidad de las otras tres partes.
Teniendo en cuenta todo lo anterior, la calidad de un software puede
evaluarse, en el modelo de calidad del estndar ISO/IEC 9126,
bien midiendo los atributos de calidad internos mediante
medidas estticas de productos intermedios, no del software en
ejecucin, o bien midiendo los atributos de calidad externos a
travs de medidas del cdigo cuando se ejecuta, o bien
midiendo los atributos de la calidad en uso sobre el software

cuando ste se ejecuta en el entorno final de usuario y trabaja en

condiciones reales tal y como vemos en la figura siguiente:

En definitiva, el modelo definido por el estndar ISO/IEC 9126

presupone que una mayor calidad interna/externa del producto
software incidir de manera positiva en la percepcin que el usuario
tiene acerca de la calidad de la aplicacin, y reconoce que el modelo
propuesto puede necesitar adaptarse a las caractersticas especficas
de ciertas aplicaciones.

2.2 Estndares y Mtricas de calidad en la ingeniera

de SW
ESTNDARES
Los estndares de calidad de software son normas emitidas por
organismos especficos, que sirven para sentar un marco con el que
comparar si un proceso de desarrollo es o no de calidad. Las normas

de calidad del software ms conocidas han sido desarrolladas por

ISO, y son la serie ISO-9000.

1. ISO 9000.- Es una norma sobre calidad y gestin continua de

calidad, se pueden aplicar a cualquier tipo de organizacin o
actividad sistemtica orientada a la produccin de bienes o
servicios. Se componen de estndares y guas relacionados con
sistemas de gestin y de herramientas especficas, como los
mtodos de auditora.
Ventajas:
Monitorear los principales procesos asegurando
que sean efectivos.
Mantener registros apropiados de la gestin, de los
procesos y de los procedimientos.
Mejorar la satisfaccin de los clientes o los
usuarios.
Mejorar
continuamente
los
procesos,
tanto
operacionales como de calidad.
Reducir los rechazos e incidencias en la produccin
o prestacin del servicio mediante un monitoreo y
la existencia de procedimientos para la correccin
de los problemas.
2. CMMI - CMM (Capability Maturity Model) es un modelo de
calidad del software que clasifica las empresas en niveles de
madurez. Estos niveles sirven para conocer la madurez de los
procesos que se realizan para producir software.
Este modelo de procesos tiene dos representaciones: continua y
por etapas, siendo la diferencia entre stas la evaluacin por
niveles de la capacidad de procesos o de la madurez de la
organizacin, respectivamente.

Nivel 1.- Las organizaciones en este nivel no disponen de un

ambiente adecuado para el desarrollo de software. Aunque se
utilicen tcnicas correctas de ingeniera, los esfuerzos se ven
minados por falta de planificacin.
Nivel 2.- En este nivel se definen claramente puntos de control
en cada etapa principal del proyecto, esto obviamente permite
tener un mayor control del proyecto. Lo importante a resaltar es
que cada etapa es an una caja negra es decir no podemos
saber con precisin como se desenvuelve el proyecto dentro de
cada etapa.
Nivel 3.- Los procesos comunes para desarrollo y
mantenimiento del software estn documentados de manera
suficiente en una biblioteca accesible a los equipos de
desarrollo. Las personas han recibido la formacin necesaria
para comprender los procesos.
Nivel 4.- Estas mtricas no son subjetivas si no que se
establecen con criterios cuantitativos formalmente definidos.
Con el tiempo estos controles nos brindarn mejor informacin
sobre la calidad y estado del proyecto permitindonos
compararlo con otros proyectos similares y notar cualquier
desviacin tempranamente parar poder corregirlo.
Nivel 5.- En este nivel cada proceso es analizado y controlado
permanentemente con l intencin de que sea mejorado en todo
momento, los controles permiten la mejora continua y se tienen
implementadas todas las reas clave de proceso recomendadas
por el modelo.

3. SPICE (Software Process Improvement and Capability

Determination). Se conforma como el estndar emergente
orientado a la mejora continua del proceso de desarrollo de
software. Es un estndar internacional cuyo objetivo es simular
circuitos electrnicos analgicos compuestos por resistencias,
condensadores, diodos, transistores, etc. Para ello hay que
describir los componentes, describir el circuito y luego elegir el
tipo de simulacin.
Etapas:
Preparacin.- En esta etapa se ve el alcance del estudio,
metas del negocio, los procesos a evaluar y las instancias
de los procesos.
Recoleccin de datos.Los expertos realizan
entrevistas, discusiones, anlisis de documentos y uso de
herramientas. En las entrevistas los evaluadores
entrevistan o discuten con gente interesada en el proceso
de acreditacin en SPICE.
Recopilacin
de
anlisis
de
documentos
relevantes.- En la recopilacin de los documentos se
pueden utilizar herramientas automatizadas en lugar de
un asesor y/o evaluador para recopilar los datos.

MTRICAS
Las Mtricas de Calidad proporcionan una indicacin de cmo se
ajusta el software, a los requerimientos implcitos y explcitos del
cliente.
El objetivo principal de la ingeniera del software es producir un
producto de alta calidad. Para lograr este objetivo, los ingenieros del
software deben utilizar mediciones que evalen la calidad del anlisis
y los modelos de desafo, el cdigo fuente, y los casos de prueba que
se han creado al aplicar la ingeniera del software. Para lograr esta
evaluacin de la calidad en tiempo real, el ingeniero debe utilizar
medidas tcnicas que evalan la calidad con objetividad, no con
subjetividad.
El primer objetivo del equipo de proyecto es medir errores y defectos.
Las mtricas que provienen de estas medidas proporcionan una

indicacin de la efectividad de las actividades de control y de la

garanta de calidad.

MTRICAS PARA LA CALIDAD DEL SOFTWARE

Desarrollando y analizando una lnea base de mtricas de calidad,
una organizacin puede actuar con objeto de corregir esas reas de
proceso del software que son la causa de los defectos del software.
Con la creacin de estas mtricas los ingenieros del software pueden
obtener una visin ms profunda del trabajo que realizan y
del producto que elaboran.

VISIN GENERAL DE LOS FACTORES QUE AFECTAN A LA

CALIDAD
Se han definido un conjunto de factores de calidad, estos factores
evalan el software desde tres puntos de vista distintos:

Operacin del producto (utilizndolo).

Revisin del producto (cambindolo).
Transicin del producto (modificndolo para que funcione en un
entorno diferente).

Proporciona un mecanismo para que el gestor del proyecto identifique

lo que considera importante y un medio de evaluar cuantitativamente
lo bien que va progresando el desarrollo en relacin con los objetivos
de calidad establecidos.

MEDIDA DE LA CALIDAD
La correccin, facilidad de mantenimiento, integridad, y facilidad de
uso son medidas de calidad que proporcionan indicadores tiles para
el equipo del proyecto.

Correccin: La correccin es el grado en el que el software

lleva a cabo su funcin requerida.
Facilidad de mantenimiento: Es la facilidad con la que se
puede corregir un programa si se encuentra un error, se puede
adaptar si su entono cambia, o mejorar si el cliente desea un

carnio de requisitos. Esta actividad cuenta con ms esfuerzo

que cualquier otra actividad de ingeniera del software.
Integridad: Mide la capacidad de un sistema para resistir
ataques (tanto accidentales como intencionados) contra su
seguridad. El ataque se puede realizar en cualquiera de los tres
componentes del software: programas, datos y documentos.
Para medir la integridad, se tienen que definir dos atributos
adicionales: amenaza y seguridad. Amenaza es la probabilidad
de que un ataque de un tipo determinado ocurra en un tiempo
determinado. La seguridad es la probabilidad de que se pueda
repeler el ataque de un tipo determinado. La integridad del
sistema se puede definir corno: Integridad = C [(l - amenaza) x
(1 - seguridad)] Donde se suman la amenaza y la seguridad
para cada tipo de ataque.

Facilidad de uso: La facilidad de uso es un intento de

cuantificar lo amigable que puede ser el programa con el
usuario. Se puede medir en funcin de cuatro caractersticas:
Habilidad intelectual y/o fsica requerida para aprender el
sistema. El tiempo requerido para llegar a ser moderadamente
eficiente en el uso del sistema. Aumento neto en productividad,
medida cuando alguien utiliza el sistema moderadamente y
eficientemente. Valoracin subjetiva de la disposicin de 1os
usuarios hacia el sistema, a veces obtenida mediante un
cuestionario.

EFICACIA DE LA ELIMINACIN DE DEFECTOS

Proporciona beneficios tanto a nivel del proyecto como del proceso, es
una medida para filtrar las actividades de la garanta de calidad y de
control al aplicarse a todas las actividades del marco de trabajo del
proceso.
La Eficacia de la Eliminacin de Defectos (EED) se define de la forma
siguiente: EED=E / (E+D) Donde E es el nmero de errores
encontrados antes de la entrega del software al usuario final y D es el
nmero de defectos encontrados despus de la entrega. Cuando el
valor de EED es 1 significa que no se han encontrado defectos en el
software, D ser mayor que cero. Cuando E aumenta (para un valor
de D dado), el valor total de EED empieza a aproximarse a 1. De
hecho, a medida que E aumenta, es probable que el valor final de D
disminuya (los errores se filtran antes de que se conviertan en
defectos). Si se utilizan como una mtrica que proporciona un

indicador de la habilidad de filtrar las actividades de la garanta de la

calidad y del control, EED anima a que el equipo del proyecto de
software instituya tcnicas para encontrar todos los errores posibles
antes de su entrega.
EED tambin se puede utilizar dentro del proyecto para evaluar la
habilidad de un equipo en encontrar errores antes de que pasen a la
siguiente tarea de ingeniera del software. Se vuelve a definir como:
EEDi = Ei / (Ei + Ei +1)
Donde Ei es el nmero de errores encontrado durante la actividad
de ingeniera del software i y Ei+1, es el nmero de errores
encontrado durante la actividad de ingeniera del software i + 1 que
se puede seguir para llegar a errores que no se detectaron en la
actividad de la ingeniera del software i.

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 "An introduction 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 ms
adelante). El resultado de nuestro trabajo, adems puede ser llevado
a un trabajo en equipo TSP (Team Process 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 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 el mejoramiento en organizaciones
maduras

2.2.2 CMM
Modelo de Capacidad y Madurez o CMM (Capability Maturity
Model), 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 Engineering Institute).
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.

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 SW-CMM (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 Process Area).
Para cada rea de proceso define un conjunto de buenas prcticas
que habrn de ser:

Definidas en un procedimiento documentado

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
proyectos es impredecible.
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
clientes
est
gestionada
sistemticamente.
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 implementan tcnicas de revisin por 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 resultante es de alta calidad.
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.

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 actividades realizadas
Las mediciones y el anlisis
La verificacin de la implementacin.

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/01-NYCE-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 definen 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

Bibliografa
Annimo. (01 Diciembre 2009). Estndares ISO,
SPICE y CMM. 19 de Noviembre del 2015, de
slideshare.com
Sitio
web:
http://es.slideshare.net/guest8e0579/estandaresisospice-y-cmm-y-empresas
S.Pressman,
Rogger.
(s.f.).
Ingenieria
Softaware. Un enfoque prctico (5ta ed.).

de

A/A. (S/A). MOPROSOFT. 19 de Noviembre del

2015,
de
sites.google
Sitio
web:
https://sites.google.com/site/gestiondeproyectoss
oftware/unidad-2-calidad-de-software/2-2-3moprosoft