Calidad en TI

Universidad Tecnolgica de Puebla
Antologa:
Sistemas de Calidad en Tecnologas de la
Informacin
Versin 1. 0.0
Cuatrimestre: Septiembre Diciembre 2009
Sistemas de Calidad en Tecnologas de la Informacin
Versin: 1.0.0
Pgina 2 de 59
Introduccin
Desde el enfoque tradicional de calidad que haba sido centrarse nicamente en tratar de evitar que se
produjesen fallos durante la fabricacin, se evolucion segn tres etapas: Control de calidad,
Aseguramiento de la calidad, Gestin de la calidad total
I.
Control de Calidad
El control de calidad apareci en los aos 30 y adquiri gran importancia en los 50 y 60. Se
centra en inspeccionar el producto y separar aquel que es aceptable (de acuerdo a unos determinados
estndares) del que no lo es.
Se tiende a considerar como una actividad a posteriori, es decir, que sirve para detectar si se han
alcanzado los niveles de calidad y tomar las medidas oportunas si no ha sido as, pero sin embargo se
pueden realizar controles antes, durante y despus de haber obtenido los resultados instalando sensores
en aquellas fases que se quieren controlar. Lgicamente, cuantos ms controles se instalen ms se
incrementaran en los costes derivados de dicho control.
Figura Representacin esquemtica del proceso de control de calidad
El departamento de control de calidad era el encargado de la de realizar esta tarea, de modo que los
dems miembros de la organizacin no se consideraban directamente responsables de la calidad.
II.
Gestin de la calidad total
En esta etapa el objetivo es proporcionar productos o servicios capaces de satisfacer al cliente, algo que
depende de la diferencia entre sus percepciones y sus expectativas. Esta nueva concepcin de la
calidad presenta importantes implicaciones.
1. Est relacionada con las percepciones del cliente, que en gran medida son subjetivas.
2. Es un concepto dinmico, ya que es preciso adaptarse constantemente a las cambiantes
necesidades de los clientes.
3. Al considerar el valor percibido, el precio se incorpora tambin al concepto de calidad ya que es
un factor que influye tanto en las expectativas que se formar el comprador (se tiende a asociar
instintivamente alto precio y alta calidad) como en su posterior juicio del producto o servicio
(mereci la pena pagar ese precio?)
En esta etapa aparece la necesidad de implicar a todos los miembros de la organizacin en el
compromiso con la calidad, es decir, la calidad debe impregnar a todas las reas de la organizacin.
Ingeniera en Tecnologas de la Informacin y Comunicacin
Versin: 1.0.0
Pgina 3 de 59
Los objetivos que se persiguen con las polticas de gestin de la calidad son:
1. Satisfaccin del cliente. Constituye el objetivo prioritario.
2. Conseguir hacer las cosas bien a la primera.
3. Eliminar todo aquello que no aada valor. Evitar despilfarros.
4. Mejorar la capacidad de reaccin del sistema mediante:
Productos y servicios personalizados.
Desarrollo rpido de nuevos productos y servicios.
Anticipacin a las necesidades del cliente.
Como definicin de Gestin de la Calidad Total (GCT) puede por tanto darse la siguiente: es el
conjunto de actividades extendidas a todas las reas, operaciones, procesos y departamentos de una
organizacin (es decir, extendidas a toda la organizacin) que tiene como objetivo enviar productos o
servicios libres de defectos, en el plazo requerido y que satisfagan plenamente a los clientes, as como
elevar el nivel de calidad de todas las operaciones de la empresa, y que se consigue con un claro
compromiso de la direccin y a travs de una completa participacin de todos los empleados.
Principios de la gestin de la calidad
Existe abundante documentacin que trata sobre los principios que rigen a la gestin de la calidad,
aunque la esencia es la misma en casi todos los autores. Quiz la enumeracin ms conocida sea la de
los catorce puntos de Deming.
Se puede decir que la GCT se sustenta en cuatro pilares fundamentales, que son los siguientes:
1. nfasis en el cliente
2. Participacin de todo el personal. Es el operario quien identifica las fuentes de variacin y
propone mejoras; se hace responsable de su trabajo.
3. Mejora de los procesos. Se identifican y corrigen sistemticamente las fuentes de variacin. Se
ve en la calidad una oportunidad para reducir los costes y, adicionalmente, aumentar la
flexibilidad y disminuir los plazos.
4. Mejora continua. Debe incorporarse a todas las reas de la organizacin
Los dos primeros aspectos estaban ya presentes en la etapa de aseguramiento de la calidad, pero los
dos ltimos son exclusivos de la GCT.
III.
Aseguramiento de la calidad
El aseguramiento de la calidad son todas aquellas acciones, llevadas cabo sistemticamente, que estn
destinadas a obtener un proceso productivo que asegure que el producto o servicio satisfar los
requerimientos de calidad. En definitiva, la filosofa que sustenta esta etapa es que la calidad se
construye en los procesos: si cada proceso se realiza correctamente, no existe ningn motivo para que
aparezcan defectos y, en consecuencia, no ser necesario controlar la calidad del producto obtenido. La
cultura de la empresa incorpora la idea de hacer las cosas bien a la primera.
Un elemento caracterstico del aseguramiento de la calidad es el Manual de Calidad, en el que se
recogen los procedimientos adecuados para realizar cada proceso, y se incluyen todas las actividades
en todas las etapas hasta la obtencin del producto final. Podramos decir que el este manual es la
Biblia del sistema de aseguramiento de la calidad.
Versin: 1.0.0
Pgina 4 de 59
Para que el sistema pueda ser certificado por terceros ha de estar elaborado de acuerdo a normas
establecidas, como la serie ISO 9000. Una vez desarrollado el sistema de acuerdo a alguna de estas
normas, existen autoridades de certificacin que evalan dicho sistema y en caso de cumplir los
requerimientos de calidad necesarios, certifican a la organizacin. El objetivo de la certificacin es doble:
1. Alcanzar y mantener la calidad del producto o servicio para satisfacer al cliente.
2. Proporcionar garantas al cliente de que el producto o servicio que se le ofrece cumple unos
determinados estndares de calidad.
La vigilancia de que el proceso se realice de acuerdo al procedimiento establecido es responsabilidad de
los auditores de calidad.
Pueden distinguirse tres pasos fundamentales que en el aseguramiento de la calidad.
1. Establecer un sistema y evaluar su adecuacin. De esta manera se obtiene el Manual de
Calidad.
2. Auditar el sistema para verificar que las disposiciones se estn implementando.
3. Revisar el sistema de manera continua, de forma que se compruebe que se sigue trabajando del
modo adecuado y que el producto tiene las caractersticas prescritas.
El papel de los especialistas del departamento de calidad se centra en realizar auditoras de calidad
para comprobar que el personal acta de la manera prevista. Aunque el aseguramiento de la calidad
supone algunas mejoras respecto al control de calidad tradicional, siguen existiendo problemas:
1. Sigue sin desarrollarse una actividad de mejora. Dado que existen unos procedimientos
claramente definidos, cualquier cambio supone un riesgo.
2. El tener unos procedimientos formales tan definidos limita de manera considerable la creatividad
del personal.
3. Se da por sentado que el cliente se siente satisfecho por recibir su pedido de acuerdo a lo que
especific, cuando realmente el realizar la entrega conforme a lo pactado es algo que el cliente
suele dar por supuesto, por lo que no contribuye significativamente a su satisfaccin y
fidelizacin.
Control de calidad
Aseguramiento de la
calidad
Aptitud para el uso
Satisfaccin del cliente
Produccin
Cliente
Todos los miembros
Se detecta un error
Al producto
Depto. de calidad +
operarios
Se intenta evitar el error
Al proceso productivo
Actuacin
Corregir el error
Modificar el procedimiento
Hay objetivos
A todos los procesos de la
empresa
Mejora continua
Actitud
Reactiva
Reactiva
Proactiva
Participacin del
personal
Importancia de la
participacin
Generacin de valor
aadido
Materializacin
Slo Depto. de calidad
Toda la empresa
No se espera participacin
Depto. de calidad +
operarios
Importante
No est claro
Si
Si
Plan de inspeccin
Manual de calidad
Sistema de gestin
Arreglo
Prevencin
Mejora
Concepto de calidad
Orientacin de la
empresa
Responsabilidad de la
calidad
Se acta porque...
Aplicacin de la calidad
Filosofa
Conformidad con las

especificaciones
Produccin
Depto. de calidad
GCT
Imprescindible
Versin: 1.0.0
Pgina 5 de 59
Existen entidades internacionales reconocidas, que se preocupan por realizar metodologas, normas,
estndares, modelos y/o directrices, enfocados a los desarrolladores como a los adquisidores de
software. Entre las principales se puede mencionar a: SEI (Software Engineering Institute - Instituto de
Ingeniera de Software), IEEE (Institute of Electrical and Electronics Engineers - Instituto de Ingenieros
Elctricos y Electrnicos), ISO (International Organization for Standarization - Organizacin Internacional
de Estandarizacin) y tambin SPICE (Software Process Improvement and Capability dEtermination
Mejoramiento de procesos de Software y determinacin de capacidad).
La ISO presenta una coleccin de estndares enfocados a la calidad, siendo la ISO 9001 la que esta
orientada al software en lo que se refiere al desarrollo y manutencin, y adicionalmente forma parte de la
serie ISO 9000. La ISO 9000-3 (IBNORCA 1998) del ao 1997 es una gua al aplicar ISO 9001 del ao
1994 para el desarrollo, provisin y mantenimiento de software. Esta experimento nuevas versiones
como es el caso de ISO 90003 del ao 2004 (ISO/IEC 2004) que es la gua de aplicacin de la ISO 9001
del ao 2000 para software de computadora. Otro estndar relacionado al software es la ISO/IEC
12207:1995 (ISO/IEC 1995) que establece un marco de referencia comn para los procesos del ciclo de
vida del software.
Dentro de los desarrollos del SEI podemos describir a SW-CMM (SEI 1993) (Software Capability Maturity
Model - Modelo de Madurez de Capacidad de Software), SA-CMM (SEI 2002a)(Software Acquisition
Capability Maturity Model - Modelo de Madurez de Capacidad para la Adquisicin de Software), CMMI
(SEI 2002b, SEI 2002c) (Capability Maturity Model Integrated - Modelo de Capacidad de Madurez
Integrado) y CMMI AM (SEI 2005) (CMMI Adquisition Module -l Modulo de Adquisicin para CMMI).
El IEEE presenta muchos estndares relacionados o involucrados con la calidad de software como son:
610.12-1990 que es el glosario estndar de terminologa de ingeniera de software, 730-1998 que es el
estndar para planes de seguridad de calidad de software, 829-1998 estndares para documentar la
evaluacin de software, 830-1998 practicas recomendadas para especificacin de requerimientos de
software, 1012-1998 estndar para la verificacin y validacin de software, 1016-1998 practicas
recomendadas para la descripcin de diseo de software, 1062a-1998 practicas recomendadas para la
adquisicin de software y muchas otras ms.
Otro estndar importante es SPICE (Software Process Improvement and Capability dEtermination) que
tambin es conocido como ISO/IEC 15504 es un modelo de madurez de procesos internacional que
proporciona un marco de trabajo para la evaluacin de procesos de software.
Versin: 1.0.0
Pgina 6 de 59
Unidad I
Normas y estndares en proyectos de T.I.
1.1
ISO
1.1.1 ISO 9001

ISO 9001 es un conjunto estndares internacionales para sistemas de calidad.
Diseado para la gestin y aseguramiento de la calidad, especifica los requisitos bsicos para el
desarrollo, produccin, instalacin y servicio a nivel de sistema y a nivel de producto.
Su primera publicacin fue en 1987, revisado en 1994 y actualizado en el ao 2000 (con el compromiso
de hacer una revisin cada 5 aos). La primera versin de 1994 estableca un conjunto bsico de
requisitos para el establecimiento y mantenimiento de la gestin del sistema y aseguramiento de la
calidad de la ingeniera de software. Se concibe como una metodologa de procesos basada en una lista
de comprobaciones o requisitos a cumplir, umbral de calidad, valorado apto o no apto. Y esta simplicidad
es lo que lo ha hecho mundialmente extendido.
La retroalimentacin de los usuarios, el desarrollo de los modelos de evaluacin y mejora continua y las
crticas especializadas hacen que se requiera un estndar que:
Emplee una aproximacin de gestin basada en el proceso.

Sea compatible con otros sistemas de gestin.
Incluya requisitos papa la mejora continua del sistema de calidad.
Coincida con las necesidades de los participantes externos.
Sea amigable al usuario y al cliente.
La nueva familia de estndares es la siguiente:
ISO 9000, Normas para la gestin y garanta de la calidad.

ISO 9001, Modelo para la garanta de la calidad en diseo/desarrollo, produccin, instalacin y
servicio.
ISO 9002, Modelado para garantizar la calidad en produccin y servicios.
ISO 9003, Modelos para garantizar la calidad en inspeccin final y pruebas.
ISO 9004, Elementos y gestin del sistema de calidad, Directrices para la mejora del
rendimiento.
ISO 9011, Directrices para la auditoria de los sistemas de gestin de la calidad y/o ambiental.
ISO 9001 e ISO 9004 se han desarrollado como un par coherente de normas, complementndose.
Mientras ISO 9001 se centra en la eficacia del sistema de gestin de la calidad para dar cumplimiento a
los requisitos del cliente, ISO 9004 se recomienda para organizaciones que persiguen la mejora
continua, sin afn certificador.
El estndar se basa en un conjunto de Principios de Gestin de la Calidad:
Enfoque al cliente, Liderazgo, Implicacin de todo el personal, Enfoque a procesos, Enfoque del sistema
hacia la gestin, Mejora continua, Enfoque objetivo hacia la toma de decisiones y Relaciones
mutuamente beneficiosas con los proveedores.
Versin: 1.0.0
Pgina 7 de 59
Las cinco secciones en que se divide ISO 9001:2000 son:

1. QMS Sistema de Gestin de la Calidad (Requisitos generales y Requisitos de la documentacin)
2. Responsabilidad de la Gestin (Compromiso de la direccin, Enfoque al cliente, Poltica de la
calidad, Planificacin,).
3. Gestin de los Recursos (Provisin de recursos, Recursos humanos, Infraestructura, Ambiente
de trabajo).
4. Realizacin del Producto (Planificacin de la realizacin del producto, Procesos relacionados con
los clientes, Diseo y desarrollo, Compras, Prestacin del servicio).
5. Medicin Anlisis y Mejora (Generalidades, Supervisin y Medicin, Control de servicio noconforme, Anlisis de datos, Mejora).
Cabe mencionar que el enfoque de ISO 9000 est en los procesos de produccin, o sea de desarrollo
en el caso de software. El fin de este tipo de estndar es un mejor proceso, y no un mejor producto,
excepto como consecuencia de mejores procesos.
1.1.2 ISO 9126

La ISO, bajo la norma ISO-9126, ha establecido un estndar internacional para la evaluacin de la
calidad de productos de software el cual fue publicado en 1992 con el nombre de Information tecnology
Software product evaluation: Quality characteristics and guidelines for their use, en el cual se
establecen las caractersticas de calidad para productos de software.
El estndar ISO-9126 establece que cualquier componente de la calidad del software puede ser descrito
en trminos de una o ms de seis caracteristicas bsicas, las cuales son: funcionalidad, con fiabilidad y
portabilidad; cada una de las cuales se detalla a travs de un conjunto de subcaractersticas que
permiten profundizar en la evaluacin de la calidad de productos de software. La tabla 1.1 muestra la
pregunta central de atiende cada una de estas caractersticas.
Caractersticas
Funcionalidad
Confiablidad
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad
Pregunta central
Las funciones y propiedades satisfacen las necesidades explcitas e
implcitas; esto es, el que . . .?
Puede mantener el nivel de rendimiento, bajo ciertas condiciones y
por cierto tiempo?
El software es fcil de usar y de aprender?
Es rpido y minimalista en cuanto al uso de recursos?
Es fcil de modificar y verificar?
Es fcil de transferir de un ambiente a otro?
Tabla 1.1. Caracteristicas de ISO-9126 y aspecto que atiende cada una.
1.1.3 ISO 15540 (SPICE, Software Process Improvement and Capability

Determination)
ISO/IEC 15504 es un emergente estndar internacional de evaluacin y determinacin de la capacidad y
mejora continua de procesos de ingeniera del software, con la filosofa de desarrollar un conjunto de
medidas de capacidad estructuradas para todos los procesos del ciclo de vida y para todos los
participantes. Es el resultado de un esfuerzo internacional de trabajo y colaboracin y tiene la innovacin,
en comparacin con otros modelos, del proceso paralelo de evaluacin emprica del resultado.
En 1991, ISO/IEC JTC1/SC7 aprueba un estudio para investigar la necesidad y los requisitos para un
estndar de evaluacin del proceso software, llegando a la conclusin (1992) de que haba consenso
internacional. El proceso de desarrollo y validacin emprica (proyecto SPICE) se ha alargado diez aos.
En 1998 se publica la primera versin del estndar como Informe Tcnico (en 1995 se publica como
borrador), evolucionando posteriormente hasta Estndar Internacional, con la realizacin de tres fases
Versin: 1.0.0
Pgina 8 de 59
de pruebas, la Fase 1 (1995) con la idea de validar la decisiones de diseo y usabilidad del borrador, la
Fase 2 (1996-1998) que a los objetivos anteriores sumaba proveer de una gua de aplicacin y revisar la
consistencia, validez, adecuacin, usabilidad y portabilidad de SPICE. La Fase 3 (hasta marzo de 2003,
en que se cierra el proyecto SPICE) se realiza con la idea de aportar entradas y publicar el estndar ISO.
Tras los Trials comienza la fase de Benchmarking (actual fase), con la idea de recolectar datos de los
procesos de evaluacin y analizarlos y comienza la publicacin de partes del estndar.
La versin 1.0 inicialmente recoga treinta y cinco procesos agrupados en cinco categoras (ClienteProveedor, Ingeniera, Proyecto, Soporte y Organizacin). Sin embargo, la idea de expandir el mbito de
aplicacin del estndar evitando restringirlo a un determinado ciclo de vida, la compatibilidad con
ISO/IEC 12207 e ISO/IEC 15288 y con cualquier modelo posterior, permite la evolucin del estndar
para aceptar Modelos de Referencia de Procesos (PRMs) eliminando la inicial dimensin de procesos.
La medida de capacidad (vase tabla 1.2), es aplicable a cualquier modelo de procesos plasmado en un
PRM compatible con ISO 12207. Esto le confiere una infraestructura mucho ms abierta, facilitando la
compatibilidad.
2
Id. Nivel de Capacidad Atributos de Proceso y Descripcin
Id
Nivel de
Capacidad
Atributos de Proceso y Descripcin
CL[0]
Incompleto
El proceso no est implementado o falla en alcanzar su propsito. No es fcil

identificar los productos o salidas de los procesos.
CL[1]
Realizado
El propsito del proceso se logra generalmente, aunque no sea rigurosamente

planificado ni llevado a cabo. Hay productos identificables que testifican el alcance
del propsito.
Realizacin del Proceso
PA.1.1
CL[2]
Gestionado
CL[3]
PA.2.1
PA.2.2
Establecido
PA.3.1
PA.3.2
CL[4]
Predecible
PA.4.1
PA.4.2
CL[5]
En
optimizacin
PA.5.1
PA.5.2
El proceso es gestionado y los entregables resultado de procedimientos

especficos, planificados y seguidos, con requisitos de calidad, tiempo y recursos.
Gestin de la Realizacin
Gestin de los Productos del trabajo
Un proceso realizado y gestionado usado un proceso definido, basado en un
principio de buenas prcticas de ingeniera del software.
Definicin del Proceso.
Despliegue del Proceso.
El proceso definido es puesto consistentemente en prctica dentro de lmites de
control establecidos para alcanzar metas del proceso ya definidas. Entendimiento
cuantitativo de la capacidad del proceso y habilidad mejorada de predecir y
gestionar el rendimiento
Medicin del Proceso
Control del Proceso
Realizacin del proceso optimizada en la busqueda de las necesidades actuales y
futuras del negocio. Objetivos cuantitativos de eficiencia y efectividad se establecen
en funcin de los objetivos de la organizacin. Optimizacin puede llevar a estudiar
y adoptar ideas innovadoras o productos tecnolgicos novedosos que incluyan y
modifiquen el proceso definido
Innovacin del Proceso.
Optimizacin del proceso
Tabla 1.2. Modelo de Capacidad de Procesos.
1.2
Versin: 1.0.0
Pgina 9 de 59
CMMI (Modelo de Capacidad de Madurez de Integracin)
Anthony Finkelstein describi que hay organizaciones que no han alcanzado siquiera el nivel 1 de CMM
(en el que aunque sea de modo heroico se llega a producir software), proponiendo que existen niveles
negativos o de inmadurez. Este Modelo de Incapacidad e Inmadurez, que fue refinado posteriormente
por Tom Schorsch, incluye tres niveles de idiotez o Inmadurez:
0 Tonto o Nulo. Organizaciones negligentes. Impiden cualquier desarrollo de software con xito. Su
gran preocupacin es la reutilizacin del software.
1 - Estpido. Organizaciones obstructivas. Imponen procesos contra-productivos para impedir cualquier
avance. Se concentran en desarrollar entornos de desarrollo y repositorios.
2 Luntico o Despectivo. Organizaciones desdeosas. Desprecian cualquier institucionalizacin de
buenas prcticas. Su gran objetivo es la programacin automtica.
3 Sabotaje. Negligencia total, descrdito consciente de los esfuerzos de su propia gente en la mejora
de proceso del software. Falta de recompensa y degradacin de las prestaciones.
A continuacin se presentan algunos puntos clave para poder identificar si una organizacin se
encuentra dentro de un nivel de capacidad de Inmadurez o dentro de un Nivel de Capacidad de
Madurez.
Proceso Inmaduro
Proceso Maduro
Personal.
No est documentado.
No es fcil reproducirlo en nuevos
proyectos.
No hay entrenamiento.
No todo el mundo lo conoce.
No se mide.
Se aplica a veces solamente.
Es percibido como poco eficiente.
No se cumplen los tiempos de entrega.
Se exceden los presupuestos.
Es definido: Sistemtico.
Es documentado, publicado, aprobado y
accesible.
El personal ha sido entrenado: Ingenieros y
gerencia (conocen el proceso).
Es practicado: Se utiliza en forma
cotidiana.
Es
apoyado:
Gerencia
asigna
responsables.
Es mantenido: es revisado para que
cumpla los requisitos.
Es controlado: las actualizaciones son
notificadas a la empresa.
Se verifica: los proyectos siguen el proceso
establecido.
Se valida: el proceso mantiene coherencia
con los requerimientos y estndares.
Se
mide:
utilizacin,
beneficios
y
rendimiento se cuantifican.
Puede mejorarse: existe el mecanismo
para la mejora continua.
Versin: 1.0.0
Pgina 10 de 59
1.2.1 Los Cinco Niveles De Madurez En Los Procesos De Creacin Del Software
El departamento de defensa de los Estados Unidos tena muchos problemas con el software que
encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban ms y
ms. Quin no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de
software? Como esta situacin les pareca intolerable convoc un comit de expertos para que
solucionase estos problemas, en el ao 1983 dicho comit concluy "Tienen que crear un instituto de la
ingeniera del software, dedicado exclusivamente a los problemas del software, y a ayudar al
Departamento de Defensa".
Convocaron un concurso pblico en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que
explicar como van a resolver estos 4 problemas", se presentaron diversos estamentos y la Universidad
Carnegie Mellon gan el concurso en 1985, creando el SEI.
El SEI (Software Engineering Institute) es el instituto que cre y mantiene el modelo de calidad CMM.
El nacimiento de CMM se da en el ao de 1986 cuando el Software Engineering Institute (SEI) junto
con MITRE Corporation, buscaron mejorar el proceso de software y desarrollaron un marco de trabajo
que llamaron proceso de madurez. Este proceso fue desarrollado por Watts S. Humphrey en 1986 y
est basado en el concepto de la administracin de la calidad total Total Quality Management (TQM) por
sus siglas en ingls.
El modelo de capacidad de madurez (CMM), provee a las organizaciones de software una gua de cmo
aumentar el control de sus procesos de desarrollo y mantenimiento de software. Fue diseado para guiar
a las organizaciones de software en la seleccin de estrategias para el mejoramiento de procesos
mediante la determinacin de la madurez de los procesos actuales e identificando los elementos ms
crticos de la calidad de software y del mejoramiento de procesos.
La arquitectura del modelo est compuesta por niveles que describen la madurez de la organizacin y
por reas claves de procesos KPAs (Key Process Areas). Los diferentes niveles permiten medir la
madurez del proceso y evaluar el potencial de l, como tambin ayudan a una organizacin a priorizar
sus esfuerzos de mejoramiento. ste concepto cuenta con cinco etapas evolutivas que se enfocan en la
implementacin de prcticas de calidad. CMM es, en pocas palabras, una aplicacin de TQM para
software
Niveles de
reas Claves
madurez
Nivel 1
Ninguna
Inicial
Nivel 2
Repetible
Nivel 3
Definido
Gestin de configuraciones
Garanta de calidad
Gestin subcontratacin del software
Seguimiento y supervisin del proyecto
Planificacin del proyecto
Gestin de requisitos
Revisiones peridicas
Coordinacin entre grupos
Ingeniera de productos de software
Gestin de integracin del software
Programa de formacin
Definicin de procesos de la organizacin
Versin: 1.0.0
Pgina 11 de 59
Enfoque del proceso de la organizacin

Nivel 4
Gestionado
Nivel 5
Optimizado
Gestin de calidad de software

Gestin cualitativa del proceso
Gestin de cambios del proceso
Gestin de cambios de tecnologa
Prevencin de defectos
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
CMM: un modelo para la mejora de Procesos de Software

Objetivo: Mejorar la calidad de los procesos de desarrollo, gestin y mantenimiento de
software
Para conseguirlo se aplican las bases de la Gestin de la Calidad Total (Total Quality
Management) en la Ingeniera del Software.
Mejora la gestin de la calidad es, en gran medida, responsabilidad de la direccin

La mejora de la calidad debe basarse en mejorar los procesos y no en las
personas
Hay que medir la mejora de la calidad
Se necesitan incentivos para mantener un esfuerzo de mejora
La mejora de la calidad es un proceso continuo
Despus de cuatro aos de experiencia con la madurez del proceso de software, el SEI evolucion la
madurez y public Capability Maturity Model for Software (CMM).En diciembre de 2000, el SEI public un
nuevo modelo, el CMMI o "Modelo de Capacidad y Madurez - Integracin", ste describe un camino
de mejoramiento evolutivo para pasar desde un proceso inmaduro a un proceso maduro y disciplinado,
basado en conocimientos adquiridos de evaluaciones de los procesos de software y extensos feedback.
Por lo tanto, las disposiciones del CMM son definitivamente aplicables a todo aquello que est
directamente relacionado con el desarrollo y mantenimiento de sistemas informticos.
CMMI define un conjunto de reas clave del proceso, que describen las funciones de ingeniera del
software que deben llevarse a cabo para el desarrollo de una buena prctica, agrupadas en cinco niveles
inclusivos. Estos niveles sirven de referencia para el conocimiento del estado de la madurez del proceso
del software en la organizacin. Mediante un amplio conjunto de mtricas se determina la calidad de
cada una de las reas clave, obtenindose una visin precisa del rigor, la eficacia y la eficiencia de la
metodologa de desarrollo de una organizacin productora de software.
Versin: 1.0.0
Pgina 12 de 59
Cada una de las reas est organizada en cinco secciones, denominadas caractersticas comunes. Todo
esto con el objetivo de realizar algunas mejoras respecto al CMMI (SW-CMM)
1.2.2 Caractersticas comunes:
Compromiso de realizacin
Capacidad para llevarla a cabo
Actividades que hay que realizar
Medicin y anlisis
Verificacin de la implementacin
1.3
Versin: 1.0.0
Pgina 13 de 59
IEEE (Instituto de Ingenieros en Electricidad y Electrnica)
Fundado en 1884, el Instituto de Ingenieros en Electricidad y Electrnica, Inc. (IEEE) se ha

dedicado a ayudar a que ms de 320,000 profesionales y estudiantes de Ingeniera desarrollen su
potencial en campos de la ingeniera elctrica. Es una asociacin tcnico-profesional mundial dedicada a
la estandarizacin, entre otras cosas. Es la mayor asociacin internacional sin fines de lucro formada por
profesionales de las nuevas tecnologas.
Objetivos:
Cientficos / Educativos: Promover el avance de las teoras y las prcticas de la electrotecnologa.
Profesionales: Fomentar el progreso y el desarrollo profesional de su membresa.
Con la sociedad: Mejorar la calidad de vida a travs de la aplicacin de la electro tecnologa.
Promover el entendimiento de la electro tecnologa ante el pblico.
Mediante sus actividades de publicacin tcnica, conferencias y estndares basados en consenso, el
IEEE produce ms del 30% de la literatura publicada en el mundo sobre ingeniera elctrica, en
computacin, telecomunicaciones y tecnologa de control, organiza ms de 350 grandes conferencias al
ao en todo el mundo, y posee cerca de 900 estndares activos, con otros 700 ms bajo desarrollo.
Su organizacin se ha hecho de manera regional dividida de la siguiente manera:
10
Regiones
17
Consejos
311
Secciones
34
1,570
217
1,434
382
60
Sub-secciones
Captulos Tcnicos
Grupos Afines
Ramas Estudiantiles
Captulos Tcnicos de Ramas Estudiantiles
Grupos Afines de Ramas Estudiantiles
Dentro de los Captulos Tcnicos ms importantes se encuentran los siguientes:

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Circuitos y Sistemas
Comunicaciones
Computacin
Educacin
Compatibilidad Electromagntica
Dispositivos Electrnicos
Ingeniera en Medicina y Biologa
Gerencia de Ingeniera
Electrnica Industrial
Aplicaciones Industriales
Versin: 1.0.0
Pgina 14 de 59
11. Ingeniera de Potencia

12. Comunicacin Profesional
El IEEE promueve la creatividad, el desarrollo y la integracin, compartir y aplicar los avances en las
tecnologas de la informacin, electrnica y ciencias en general para beneficio de la humanidad y de los
mismos profesionales. Como parte de los Captulos Tcnicos estn los estndares y en software algunos
de estos son:
IEEE Std. 610.12-1990
IEEE Std. 1016-1998
IEEE Std. 1471-2000
IEEE Std. 1012-1998
IEEE Std. 1008-2002
IEEE Std. 1058-1998
IEEE Std. 730-1998
IEEE Std. 830-1998
IEEE Standard Glossary of Software Engineering Terminology

IEEE Recommended Practice for Software Design Descriptions
IEEE Recommended Practice for Architectural Description of Software
Systems
IEEE Standard for Software Verification and Validation
IEEE Standard for Software Unit Testing
IEEE Standard for Software Project Management Plans
IEEE Standard for Software Quality Assurance Plans
IEEE Recommended Practice for Software Requirements Specifications
1.3.1 Planificacin del aseguramiento de la calidad en un proyecto

Siguiendo el estndar IEEE (Std 1074/ 1991, estndar para el desarrollo de software ciclo de procesos),
al iniciar un proyecto software hay que:
1. Seleccionar uno o varios del ciclo de vida, y concretarlo luego en uno determinado para dicho
proyecto.
2. Definir los aspectos relacionados con la financiacin y viabilidad del proyecto
3. Definir las metodologas, tcnicas y herramientas a utilizar
4. Planificar la gestin del proyecto de software
Planificacin de Gestin del Proyecto de incluir y describir:
El da a da del proyecto, con los correspondientes controles de auditoras y revisiones.
La planificacin del aseguramiento de la calidad del software (SQA)
La planificacin de la documentacin del proyecto.
A partir del plan de gestin, se genera el plan de Aseguramiento de la calidad del software.
1.3.2 El plan de Aseguramiento de la calidad del software.

Este plan es especfico para cada proyecto, siguiendo las directrices del MANUAL DE CALIDAD y de sus
procedimientos y las normas requeridas por los clientes. Siguiendo el estndar 730/1984 (Estndar para
planes de aseguramiento de la calidad del software), el plan debe incluir:
Objetivos de la calidad del proyecto y enfoque adaptado para alcanzarlos

Documentacin referenciada en el plan (manual, procedimiento, etc.)
Gestin del aseguramiento de la calidad (organizacin, actividades y responsabilidades).
Documentacin mnima exigida a los desarrolladores tanto del desarrollo del software
(especificaciones, diseo, manuales de usuario, etc.) como de control (planes validacin y
verificacin).
Estndares que se deben aplicar obligatoriamente
Actividades de revisin y auditoria.
Gestin de la configuracin del software (mediante un plan de gestin especfico o describiendo
sus actividades).
Versin: 1.0.0
Pgina 15 de 59
Informes de problemas, especificando la forma de tratar y corregir los problemas y los

responsables que han de hacerlo
Herramientas para apoyar el aseguramiento de la calidad (revisiones, inspecciones, analizadores
de cdigo, generadores de entornos de prueba, etc.), especificando sus objetivos y la manera de
utilizarlas.
Control de cdigo (almacenamiento y versiones), control de acceso a equipos y prevenciones de
seguridad y control de las caractersticas del software de los suministros.
Recogida, almacenamiento y mantenimiento de datos sobre el aseguramiento de la calidad.
Actividades de aseguramiento de la calidad.

Segn el estndar IEEE 1074/1991, las tcnicas para el aseguramiento de la calidad son, principalmente
tres:
1. Mtricas del software para controlar el proyecto
2. Verificacin y validacin del software (incluyendo pruebas y revisiones) en todas las fases del
ciclo de vida
3. Gestin de la configuracin del software.
1.4
PSP (Personal Software Process)
Cmo se desarrollo el PSP?

Despus de que Watts S. Humphrey condujera el desarrollo inicial de CMM para software, se decidi a
aplicar los principios de CMM a los programas pequeos. Posteriormente, mucha gente preguntaba
cmo aplicar CMM a las organizaciones pequeas o al trabajo de los equipos pequeos de software.
Mientras que los principios de CMM se aplicaron a tales grupos, cada vez se volva ms necesaria la
asesora para saber qu hacer. Fue entonces cuando Humphrey decidi personalmente utilizar los
principios de CMM para desarrollar programas modulares para ver si dicho enfoque podra funcionar
para convencer a los ingenieros de software a que adoptaran tales prcticas.
Fue entonces en el desarrollo de estos programas modulares, cuando Humphrey utiliz personalmente
todas las prcticas de CMM para que l subiera poco a poco hasta llegar al nivel 5. Poco despus l
comenz a trabajar en el proyecto tiempo completo en abril de 1989, el Instituto de la Ingeniera de
Software (SEI) hizo a Humphrey un colaborador del SEI, permitindole trabajar tiempo completo en la
investigacin detallada de PSP.
Durante los siguientes tres aos, l desarroll un total de 62 programas y defini cerca de 15 versiones
de PSP. Utiliz los siguientes lenguajes de programacin: PASCAL y C++, para desarrollar cerca de
25.000 lneas de cdigo que ayudaran a darle la forma final a PSP. [SEI; 2002]
De esta experiencia, l concluy que los principios de la administracin de procesos que desarroll
Deming y de Juran eran totalmente aplicables tanto al trabajo de los ingenieros de software de manera
individual como a ingenieros enfocados al trabajo en equipo, el resultado? Proceso en equipo de
software (TSP)
Humphrey despus escribi un libro que les proporcion a varios asociados el material necesario para
ensear cursos de PSP. En septiembre de 1993, Howie Dow ense el primer curso de PSP a cuatro
estudiantes graduados en la Universidad de Massachusetts.
Humphrey tambin ense el curso de PSP durante el semestre del invierno de 1993-1994 en la
universidad de Carnegie Mellon, al igual que Nazim Madhavji en la Universidad McGill y Soheil
Khajanoori lo ense en la Universidad Aeronutica de Embry. De acuerdo con las experiencias y los
Versin: 1.0.0
Pgina 16 de 59
datos que proporcionaron estos cursos, Humphrey realiz la revisin del libro de PSP y public la versin
final a finales de 1994. [HUMPHREY; 95 ]
Casi al mismo tiempo, Jim Over y Neil Reizer del SEI y Robert Powels de la compaa de Servicios
Informativos Avanzados (AIS por sus siglas en ingls) desarrollaron el primer curso para entrenar a los
instructores a ensear el curso de PSP en la industria. Humphrey junto con el SEI han continuado
trabajando en el desarrollo de PSP y as mismo han aplicado los mismos principios al Proceso en Equipo
de Software o TSP.
Qu es el PSP?
Un PSP es un proceso personal desarrollar software que tiene:

1. pasos definidos
2. formularios
3. estndares
Un PSP es un marco de trabajo de medicin y anlisis que te ayuda a caracterizar tu proceso.
Es tambin un procedimiento definido para ayudarte a mejorar tu rendimiento.
1.4.1 Principios PSP
La calidad de un sistema software est condicionada por la calidad del peor de sus
componentes.
La calidad de un componente software est condicionada por el individuo que lo desarroll.
Est condicionada por tu:

1. conocimiento
2. disciplina
3. compromiso
Como todo profesional software deberas conocer tu propio rendimiento.
Deberas medir, seguir y analizar tu trabajo.
Deberas aprender de tus variaciones de tu rendimiento.
Deberas incorporar esas lecciones a tu manera personal de hacer.
El diseo de PSP se basa en los siguientes principios de planeacin y de calidad [HUMPHREY; 95]
Cada ingeniero es esencialmente diferente; para ser ms precisos, los ingenieros deben planear
su trabajo y basar sus planes en sus propios datos personales.
Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente

comprometidos con la calidad de sus productos.
Versin: 1.0.0
Pgina 17 de 59
Para hacer un trabajo de ingeniera de software de la manera correcta, los ingenieros deben
planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un proceso bien
definido para realizar de la mejor manera la planeacin del trabajo.
Para que los desarrolladores lleguen a entender su funcionamiento de manera personal, deben
medir el tiempo que pasan en cada proceso, los defectos que inyectan y remueven de
cada proyecto y finalmente medir los diferentes tamaos de los productos que llegan a
producir.
Finalmente, deben analizar los resultados de cada trabajo y utilizar estos resultados para mejorar
sus procesos personales
1.4.2 Estructura del PSP
El PSP se aplica en tareas personales estructuradas:

1. Desarrollo de mdulos de programas.
2. Definicin de requisitos o procesos.
3. Realizacin de revisiones o pruebas.
4. Escritura de documentacin, etc.
5. El PSP se puede extender al desarrollo de sistemas software de gran tamao.
6. Es un proceso de Nivel 5 para los individuos y es un prerrequisito para el TSP
PSP se introduce con siete pasos compatibles.
Escribes uno o dos pequeos programas en cada paso.
Recoges y analizas los datos de tu trabajo.
Los usas y analizas para mejorar tu trabajo.
Comenzando con los requerimientos, el primer paso en el proceso de PSP es la planificacin.
Existe un script de planificacin que sirve de gua y un resumen del plan para registrar todos los datos
del mismo. Mientras los desarrolladores van siguiendo el lineamiento de trabajo sugerido por los scripts,
deben ir registrando los tiempos dedicados y los datos de defectos en los logs de tiempos y defectos.
Al final de la tarea, durante la fase de postmortem (PM), deben resumir los datos de tiempo y defectos,
medir el tamao del programa, e ingresar esos datos en el formulario de sumario del plan. Al finalizar,
deben entregar el producto finalizado y el formulario de sumario del plan completado.
Versin: 1.0.0
Pgina 18 de 59
Debido a que generalmente ciertos mtodos de PSP no son utilizados por los desarrolladores, los
mtodos de PSP son presentados en una serie de siete versiones de procesos. Estas versiones son
denominadas como PSP0 a PSP3. Cada versin tiene un mismo conjunto de logs, formularios, scripts, y
standards.
Los scripts de proceso definen los pasos de cada parte del proceso, los logs y formularios
proveen templates para registrar y almacenar datos, y los standards guan a los desarrolladores
a mientras hacen el trabajo.
1.4.3 Elementos del proceso
Est construido en un formato simple de utilizar con instrucciones simples y precisas. Si bien los scripts
describen qu hacer, en realidad se parecen ms a checklists que a tutoriales.
Estos no incluyen los materiales instructivos que seran necesarios para usuarios no entrenados. El
propsito de los scripts es el de guiar a los desarrolladores en el uso consistente de los procesos, los
cuales ellos conocen (mediante la asistencia a cursos de capacitacin en PSP o a travs de bibliografa
introductoria en el uso de PSP).
Versin: 1.0.0
Pgina 19 de 59
PSP O. Proceso (punto de partida)
PSP0 es un proceso sencillo, definido y personal.
Utiliza tus mtodos actuales de diseo y desarrollo.
Recoge datos sobre tu trabajo:

1. tiempo gastado por fase
2. defectos encontrados en compilacin y pruebas
Proporciona un informe resumen
El paso inicial en PSP consiste en establecer una base que incluya mediciones y un formato de reportes.
Esto permite medir el progreso y define los cimientos para mejorar. Esencialmente, PSP0 es el proceso
habitual con el que los desarrolladores escriben software, mejorado para proveer mediciones
PSP 0.1
Se pasa a PSP0.1 agregando un estndar de cdigo, mediciones de tamao y el

denominado PIP (Process Improvement Proposal).
El PIP provee una manera estructurada de registrar problemas, experiencias y sugerencias
para mejorar.
PSP0.1 tambin mejora las mediciones para contar separadamente mtodos y
procedimientos.
PSP1 Planeacin personal

PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega estimaciones de
tamao y recursos y un reporte de prueba.
En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto. Los
desarrolladores son enseados a:
Entender la relacin entre el tamao de los programas que escriben y el tiempo que les toma
desarrollarlos.
Aprender a realizar compromisos que puedan cumplir.
Preparar un plan ordenado para realizar su trabajo
Establecer una base para realizar un seguimiento de su trabajo.
Versin: 1.0.0
Pgina 20 de 59
Mientras que la importancia de estas tcnicas en proyectos grandes es comprendida, pocos

desarrolladores las aplican a su trabajo personal. PSP demuestra el valor de estos mtodos en el nivel
personal.
PSP 2. CALIDAD PERSONAL
Un objetivo de PSP es ayudar a los desarrolladores a lidiar de manera realista y objetiva con los defectos
que introducen. Los programadores por lo general se avergenzan de sus errores. El hecho de que la
mayora de los errores sean tipogrficos o errores tontos hace que los desarrolladores sientan que
pueden mejorar haciendo ms esfuerzo.
PSP2 agrega diseo personal y revisiones de cdigo a PSP1. Estas revisiones ayudan a encontrar
defectos de manera temprana y a ver los beneficios que esto proporciona. Los desarrolladores analizan
los defectos que encuentran en los primeros programas y usan estos datos para establecer checklists de
revisin que estn hechos a medida de su experiencia de defectos personales.
El proceso de diseo es contemplado en PSP2.1. El objetivo no es decirle a los desarrolladores como
disear sino orientar el criterio para la finalizacin del diseo, es decir, cuando han terminado que es lo
que deben haber obtenido. Se establece un criterio de completitud de diseo y se examinan varias
tcnicas de verificacin y consistencia de diseo.
PSP3. Proceso cclico personal
Hasta este punto PSP se concentr en el proceso lineal para construccin de pequeos programas.
PSP3 presenta mtodos para ser usados por individuos en la realizacin de programas de gran escala.
De todas formas sigue enfocado en el individuo y no trata los problemas de comunicacin y coordinacin
que son una parte importante del desarrollo de sistemas de gran escala.
Para escalar PSP2 a proyectos ms grandes la estrategia consiste en subdividir el proceso personal de
desarrollo de grandes programas en elementos en la escala de PSP2. Estos programas son entonces
diseados para ser desarrollados en pasos incrementales. La primera construccin consiste en un
mdulo base o kernel que es ampliado en ciclos iterativos. En cada iteracin se utiliza un PSP2
completo, incluyendo diseo, codificacin, compilacin y pruebas.
Versin: 1.0.0
Pgina 21 de 59
El proceso cclico PSP3 puede ser un elemento efectivo en un proceso de desarrollo de gran
escala solo si cada incremento sucesivo de software es de alta calidad.
De esta manera los desarrolladores pueden concentrarse en la verificacin de la calidad del

ltimo incremento sin preocuparse por defectos en ciclos anteriores.
Si un incremento anterior tiene muchos defectos, la prueba ser ms compleja y los beneficios
de escalar PSP se pierden. Esta es una razn para enfatizar revisiones de diseo y cdigo en los
pasos anteriores de PSP.
1.4.4 Planeacin del PSP
Te permiten llegar a acuerdos que t puedas cumplir
Proporcionar las bases para acuerdo en tu trabajo
Gua tu trabajo
Te ayuda a seguir tu progreso
La primera tarea consiste en definir los requerimientos, describiendo el trabajo a realizar en el mayor
detalle posible.
Como la etapa de planificacin es demasiado temprana como para hacer un diseo completo del
producto, los desarrolladores realizan un diseo conceptual, mediante el cual se obtiene un primer
acercamiento de cmo debe basarse el producto a ser construido en la etapa de desarrollo.
La siguiente tarea consiste en la estimacin de tamao y de esfuerzo.
La correlacin entre el tamao de un programa y tiempo de desarrollo es moderadamente buena para
equipos de desarrollo; sin embargo, para un solo desarrollador, la correlacin es generalmente un poco
mayor. Los desarrolladores realizan las estimaciones utilizando datos histricos personales de tamao y
productividad. En PSP, las estimaciones se efectan mediante el mtodo PROBE (PROxy Based
Estimating).
Versin: 1.0.0
Pgina 22 de 59
Una vez que los desarrolladores conocen el tiempo requerido para cada proceso, deben estimar el
tiempo que van a dedicar al trabajo cada da de la semana, conformando entonces el calendario.
Luego, durante la etapa de desarrollo del producto, los desarrolladores efectan el diseo detallado, la
implementacin y las pruebas.
Despus de completar el trabajo, los desarrolladores realizan un anlisis postmortem, en el cual se
actualiza el sumario del plan con los datos reales de tiempos invertidos en cada etapa del desarrollo,
defectos encontrados y removidos, etc, y se comparan los resultados obtenidos con lo planeado.
Finalmente, los desarrolladores registran toda esta informacin en sus bases de datos histricas de
tamao y productividad. Adems se examinan las Propuestas de Mejoras (PIP) para hacer ajustes en los
procesos.
1.4.5 Recoleccin de datos.

En PSP, los desarrolladores utilizan informacin para monitorear su trabajo, la cual los ayuda a hacer
mejores planes. Para esto, deben recolectar datos de los tiempos que dedican a cada fase del proceso,
de los tamaos de los productos que producen, y de la calidad de esos productos.
Las medidas bsicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso, los
defectos introducidos y encontrados en cada fase, y los tamaos de los productos desarrollados en
lneas de cdigo (LOC).
Estos datos se recopilan en cada fase del proceso y se resumen a la terminacin del proyecto. Todos
estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los
ingenieros usan como gua en su trabajo.
Las principales medidas son:
Tamao tiempo de estimacin de errores
Coste de realizacin
Defectos producidos y corregidos por hora
Produccin del proceso
Valoracin y calidad del coste de los fallos (COQ)
Versin: 1.0.0
Pgina 23 de 59
Valoracin del rango de fallos (A/FR)
Elementos
un guin de proceso
un formulario resumen de plan proyecto
un registro tiempo
un registro de defectos
un estndar de tipos defecto
No de
Fase
Propsito
Guiarte en el desarrollo de programas a nivel de mdulo
Entradas
Necesarias
Descripcin del problema Formulario de Resumen del plan del

Proyecto PSPO
Tablas de Registro de Tiempos y Defectos
Cronometro (opcional)
Producir u obtener los requisitos
Estimar las LOC necesarias
Estimar el tiempo de desarrollo necesario
Indicar los datos del plan en el Resumen del Plan de Proyecto
Completar el Log de Registro de Tiempos
Disear el programa
Implementar el diseo
Compilar el programa y corregir todos los defectos encontrados
Completar la Tabla de Registro de Tiempos
Planificacin
Desarrollo
Post-mortem
Criterios de
salida
Planificacin:
Desarrollo:
Post-mortem:
Diseo:
Codificacin:
Compilacin:
Prueba:
Completar el Resumen del plan del Proyecto con los datos actuales
de tiempo,
defectos y tamao
Un programa probado
Un resumen del Plan de Proyectos con los datos estimados y
actuales
Las tablas de Registro de Tiempos y Defectos Rellenos
Estimar tiempo de desarrollo.

Desarrollar el producto utilizando tus mtodos actuales.
Completar el resumen del plan proyecto, con los tiempos gastados y defectos
encontrados e inyectados en cada fase.
Disear el programa, usando tus mtodos de diseo actuales.
Implementa el programa.
Compila hasta que est libre defectos.
Prueba el programa y corrige todos los defectos.
Registra los defectos en el Log de defectos y tiempos por fase en el Log de tiempos.
Versin: 1.0.0
Pgina 24 de 59
Encabezado:
Nombre, fecha, programa, instructor, lenguaje.
Tamao del Programa: Plan. Indica tu mejor estimacin del tiempo total que tendr el desarrollo.
Actual. Indica el tiempo actual en minutos gastado en cada fase.
Tiempo:
A la fecha: Indica el tiempo total gastado en cada fase hasta hoy. Para programa
1A, es el tiempo gastado en el programa 1A.
A la fecha % : Indica el porcentaje del total tiempo hasta hoy que se gasto en
cada fase.
Defectos introducidos
y removidos:
Indicar el nmero actual de defectos inyectados y eliminados en cada fase.
Defectos:
A la fecha: Indica el total de defectos inyectados y eliminados en cada fase hasta
hoy. Para el programa 1A, son los defectos inyectados y eliminados en el
programa 1A.
A la fecha %: Indicar el porcentaje sobre el total defectos inyectados y eliminados
hasta hoy en cada fase.
Logs de Registro de tiempo
Encabezado:
Indicar nombre, fecha, instructor y nmero de programa.
Versin: 1.0.0
Pgina 25 de 59
Indicar la fecha actual.

Indicar el tiempo en minutos cuando empiezas una fase del proyecto
Indicar el tiempo en minutos cuando tu paraste tu trabajo en una fase del
proyecto, aun cuando t no has terminado esa fase.
Tiempo de interrupcin: Indicar el tiempo perdido por interrupciones desde el periodo de arranque a
parada.
Tiempo Delta time:
Indicar el tiempo transcurrido desde el inicio al tiempo de parada descontado el
tiempo de interrupcin.
Fase:
Anotar la fase en la que ests trabajando. / Use el nombre de cada fase.
Comentarios:
Descripcin de la interrupcin. La tarea que ests haciendo. Cualquier aspecto
significativo que afecte a tu trabajo
Fecha:
Inicio:
Fin:
Fecha
Inicio
Fin
9/9
9:00
Tiempo Delta
Actividad
9:50
50
Planeacin
12:40
1:18
38
Diseo
2:45
3:53
10
58
Diseo
Telfono
10/9
11:06
12:19
6+5
62
Codificacin
Bao, tom caf
11/9
9:00
9:50
50
Codificacin
1:15
2:35
3+8
69
Compilacin
Consulta de un libro
4:18
5:11
25
28
Prueba
Reunin con mi jefe
9:00
9:50
50
Prueba
12:33
1:16
38
Postmortem
13/9
Tiempo de
Interrupcin
Comentarios
1.4.6 Tamao
El tiempo en desarrollar un producto se encuentra altamente determinado por el tamao del mismo. En
PSP, los desarrolladores primero estiman el tamao de los productos que planean desarrollar. Luego, al
finalizar el producto, se mide el tamao real obtenido. Esta informacin permite a los desarrolladores
realizar a futuro una estimacin de tamaos ms precisa. Sin embargo, para que esta informacin sea
til, el tamao de las mediciones debe corresponderse con el tiempo de desarrollo del producto. En PSP,
el tamao se mide en Lneas de Cdigo (LOC). Para realizar un seguimiento de la variacin del tamao
de un programa durante el desarrollo, se deben considerar varias categoras de LOC.
Estas son:
Base (son los LOC iniciales del producto original)
Agregadas (es el cdigo agregado a un programa base existente)
Modificadas (es el cdigo base que es modificado en un programa existente)
Eliminadas (es el cdigo base que es eliminado de un programa existente)
Reutilizacin (es el cdigo tomado de una librera u utilizado, sin realizar ninguna modificacin,
en un nuevo programa)
Nueva Reutilizacin (esta medida cuenta los LOC que se agregan a una librera)
Total (es tamao total del programa, independientemente del cdigo fuente).
Versin: 1.0.0
Pgina 26 de 59
Luego, para medir el tamao total de un producto, el clculo es el siguiente:

Total LOC = Base Eliminadas + Agregadas + Reutilizacin
Las LOC modificadas y de nueva reutilizacin no son incluidas en el total; esto se debe a que las LOC
modificadas pueden representarse por LOC eliminadas y agregadas, y las LOC de nuevo reutilizacin
ya se encuentran contabilizadas en las LOC agregadas.
Logs de Registro de defectos
El estndar de tipos de defectos proporciona un conjunto general de categoras de defectos. Aunque t
puedes reemplazar este estndar por el tuyo propio, es deseable que te manejes con estas definiciones
simples de tipos hasta que tengas datos que te puedan guiar en las modificaciones. Estos estndares se
utilizaron para llenar los logs de Registro de defectos. A continuacin se muestra un ejemplo:
Versin: 1.0.0
Pgina 27 de 59
Encabezado: Indicar el nombre, fecha, instructor, y numero de programa.

Fecha:
Indicar la fecha cuando encontraste y corregiste el defecto.
Nmero:
Indicar un nmero nico para este defecto. Comienza cada proyecto con 1.
Tipo:
Indicar el tipo de defecto a partir del estndar de tipos de defectos.
Introducido:
Indicar la fase donde tu juzgas que el defecto fue inyectado o introducido.
Eliminado:
Indicar la fase en la que encontraste y eliminaste el defecto.
Tiempo de Arreglo: Indicar el tiempo que tomaste para corregir el defecto. T puedes dar el tiempo
exacto o usar tu mejor estimacin.
Defecto Arreglado: Si este defecto fue inyectado durante la correccin de otro defecto, indicar el nmero
de ese defecto o una X si lo desconoces.
Nota: Un defecto es cualquier cosa en el programa que debe ser cambiado para que sea desarrollado,
mejorado o utilizado de manera adecuada.
Finalmente, la manera ms eficaz de encontrar y arreglar defectos es repasando el cdigo fuente del
programa personalmente. Mientras esto puede parecer como una manera difcil de limpiar un programa
defectuoso, resulta ser ms rpido y ms eficaz. Un mtodo para realizar revisiones de cdigo es la
utilizacin de guas en las que se determina cuales son los defectos que ms frecuentemente se
inyectan.
1.4.7 METRICAS DEL PSP

Con datos de tamao, tiempo y defectos, existen muchas formas de medir, evaluar, y manejar la calidad
de un programa. PSP provee una serie de mediciones de calidad que ayudan a los desarrolladores a
examinar la calidad de sus programas desde varias perspectivas. Como ninguna medicin por s sola
puede indicar adecuadamente la calidad de un programa, el panorama que provee la utilizacin de todas
estas mediciones es generalmente un indicador confiable de calidad.
Las principales mediciones de calidad son:
1. Densidad de defectos
2. ndice de revisin
3. ndices de tiempo de desarrollo
4. ndices de defectos
5. Rendimiento
6. Defectos por hora
7. Efectividad de remocin de defectos
8. Evaluacin del ndice de fallas
Resumen del registro de Mtricas
Nombre:
Programa
Profesor
Resumen
Minutos/LOC
LOC/Hora
Defectos/KLOC
Rendimiento
A/FR
Tamao Programa (LOC):
Total nuevo & Cambiado
Plan
5,92
10,14
94,79
Fecha: 18/10/96
Programa # 13
Lenguaje: C++
Actual a la Fecha
4,87
5,73
12,32 10,47
106,4 96,90
58
47
258
Tamao Mximo
Tamao Mnimo
Tiempo en fase (min.)
Planing
Diseo
Cdigo
Revisin cdigo
Compilacin
Test
Postmortem
Total
Tiempo Mximo
Tiempo Mnimo
243
Introduccin de defectos
Planing
Diseo
Cdigo
Revisin cdigo
Compilacin
Test
Total
1.5
72
41
Plan
18
35
149
20
24
64
33
343
426
Plan
1
5
Actual
22
24
93
37
4
8
41
229
Para Fecha
88
151
637
111
92
240
160
1479
Actual Para Fecha
4
21
16,0
84,0
25
100,0
Versin: 1.0.0
Pgina 28 de 59
Para Fecha %
6,0
10,2
43,1
7,5
6,2
16,2
10,8
100
Para Fecha % Def/Hora
TSP (Team Software Process)
El resultado final es que incluso aunque un equipo de ingenieros est entrenado en PSP, todava les
queda combinar sus procesos de trabajo personal dentro de un nico proceso de equipo. Esto es para
ellos un problema, incluso en los ms altos niveles de CMMI. Por esta razn se ha desarrollado Team
Software Process SM (TSPSM).
TSP extiende y refina los mtodos CMM y PSP, para guiar a los miembros de los equipos en el trabajo
de mantenimiento y desarrollo. TSP les muestra cmo construir un equipo autodirigido y como ser un
Versin: 1.0.0
Pgina 29 de 59
efectivo miembro del equipo. Tambin les ensea cmo dirigir y soportar estos equipos y como mantener
un medio para obtener un alto nivel de desarrollo.
En resumen, se puede decir que TSP tiene 4 objetivos principales:
1. Construir equipos autodirigidos que planifiquen y realicen un seguimiento de su trabajo,
estableciendo metas adems sus propios procesos y planes.
2. Mostrar a los directores como entrenar y motivar a sus equipos
mantenerles en el ms alto nivel de desarrollo.
y como ayudarles para
3. Acelerar la mejora del proceso software haciendo normal la conducta del Nivel 5 de CMMI
4. Mejorar la direccin para obtener organizaciones de un alto nivel de madurez
La principal ventaja de TSP es que muestra a los ingenieros como producir productos de calidad por
medio de una planificacin de costos. Esto lo hace, ensendoles cmo planificar su propio trabajo y
hacindoles participes de los planes y procesos que se van a llevar a cabo.
TSP proporciona equipos de proyectos con guas explcitas sobre como alcanzar sus objetivos. TSP
conduce al equipo a travs de cuatro fases dentro de un mismo proyecto. Estos proyectos deben
empezar o terminar con alguna fase o pueden ejecutarse desde el principio al final. Antes de cada fase,
el equipo planifica y organiza su trabajo mediante una puesta en marcha completa (launch) o relaunch.
1.5.1 Equipos de Trabajo.

El Software Engineering Institute (SEI) ha desarrollado el TSP para ayudar a equipos de ingenieros de
software a desarrollar productos de software de manera eficiente. Este proceso ataca varios de los
problemas actuales en el desarrollo intenso de productos de software y ensea a equipos de trabajo y
gerencia como resolverlos. El TSP muestra a grupos de ingenieros como aplicar conceptos integrados
en el desarrollo de software, encamina a los ingenieros y a la gerencia en un proceso de 4 das para
establecer los objetivos, definir los roles, atacar los riesgos y producir un plan de trabajo comprensivo.
Siguiendo el lanzamiento el TSP provee un marco de procesos definidos y medibles para administrar,
supervisar y reportar el trabajo en equipo.
Cada equipo puede estar conformado por al menos 2 personas y hasta 15 personas como mximo. Los
miembros del equipo deben trabajar hacia un objetivo comn y tiene roles especficos o
responsabilidades dentro del equipo. Existe una interdependencia entre el trabajo de los miembros del
Versin: 1.0.0
Pgina 30 de 59
equipo que requiere cooperacin para que el equipo sea exitoso y por lo mismo siguen un proceso de
trabajo comn.
Es importante que cada miembro del grupo sepa cul va a ser su funcin y sus responsabilidades, y
debera comprobar si alguno de los miembros del grupo necesita ayuda. Adems cada miembro del
grupo debe proporcionar una copia completa del formulario WEEK para que el jefe del proyecto pueda
planificar la siguiente fase.
Se debe crear un diseo conceptual para cada producto planificado y dividir en ciclos y documentar el
trabajo. Adems se debe de tener una infraestructura para poder realizar estas funciones como por
ejemplo formularios que controlen los errores, el control de la entrada/salida, etc.
Los miembros del grupo deben planificar una fase de implementacin personal utilizando por ejemplo
PSP. Esta planificacin y documentacin debe ser estndar para todos los miembros del grupo y para
ello utilizar los mismos formularios. Se deben especificar los bucles de pruebas, los valores de las
variables que se van a usar y los condiciones de error que se vayan a producir, establecer los lmites de
posibles valores de las variables, los datos ms crticos, etc.
Adems se debe realizar un desarrollo explicito de las pruebas que se vayan a realizar y las revisiones
de cdigo que se vayan a hacer. Todas las pruebas se deben planificar con anticipacin y establecer una
forma estndar de realizarlas y documentarlas para solucionar los posibles problemas y errores que
hayan producido. En la documentacin debe aparecer quien o quienes de los miembros del grupo son
los encargados de realizar las pruebas y quines son los encargados de instalar el producto final.
Al final de cada ciclo y cada grupo debe realizar una memoria de su trabajo y comparar el resultado con
las metas establecidas al principio del ciclo para poder as extraer conclusiones. Esta memoria debera
contener:
1.
2.
3.
4.
5.
6.
7.
El tamao del producto

Las horas de desarrollo
El rango de lneas de cdigo por hora (LOC/Hours)
El rendimiento antes de la compilacin
El rendimiento antes de las pruebas del sistema
El nivel de defectos en la compilacin
El nivel de defectos en todas las fases de pruebas
Adems de todo lo anterior expuesto, los grupos deberan aportar la relacin de inspecciones y
revisiones realizadas y los valores obtenidos en ellas.
1.5.2 Componentes del TSP

Los equipos de TSP estiman proyectos con una aproximacin arriba-abajo, utilizando todo el tamao y
mediante la productividad del equipo, determinar el programa completo. Como se ha descrito
anteriormente, el proyecto se divide en fases y cada una de ellas es estimada y rastreada.
En las puestas en marcha de cada fase, se definen las tareas y para cada tarea se realiza una
estimacin usando mtodos rigurosos de Personal Software Process (PSPSM). Estas estimaciones se
utilizan para generar un plan detallado de valores-ganados, con el cual se identificara el seguimiento y
planificacin de las metas del proyecto, criterios de calidad y riesgos de las puestas en marcha.
TSP requiere entrevistas peridicas donde se comparan los progresos con la planificacin del equipo en
trminos de valores ganados y calidad. Si hay desviaciones con respecto a la planificacin, se pueden
determinar las razones y tomar medidas para que se retorne otra vez a dicha planificacin. Es tambin
Versin: 1.0.0
Pgina 31 de 59
durante estas entrevistas peridicas, donde se revisan los riesgos que se han producido durante la
puesta en marcha.
Las puestas en marcha de TSP no concluyen satisfactoriamente hasta que el equipo y la direccin estn
de acuerdo sobre los requerimientos y el desarrollo. Una vez que se ha determinado el desarrollo, se usa
como base para una medida personal y los valores se rastrean por cada persona y peridicamente por el
equipo.
El TSP tambin requiere replanificacin de un proyecto, o ms tarde actualizacin, cuando las
especificaciones del plan cambian. Esto significa que cuando estas especificaciones cambian a lo largo
del proyecto, el equipo renegocia la planificacin, delibera la funcionalidad y si es necesario el coste.
Finalmente, los problemas con la calidad pueden ser virtualmente eliminados usando TSP, ya que los
mtodos de calidad usados son los mismos que los usados en PSP y que los ingenieros realizan
individualmente cuando llevan a cabo sus revisiones, diseos y codificaciones.
1.5.3 Roles del TSP

La puesta en marcha de un proyecto TSP incluye los siguientes pasos:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Revisar con la direccin los objetivos del proyecto.

Establecer los roles del equipo.
Documentar los objetivos del equipo.
Producir la totalidad de la estrategia de desarrollo.
Definir los procesos de desarrollo del equipo.
Planificar los soportes que se necesitan.
Realizar una planificacin del desarrollo para el proyecto entero.
Realizar una planificacin de la calidad y el conjunto de objetivos de calidad.
Realizar una planificacin detallada para cada ingeniero para la siguiente fase.
Unir las planificaciones individuales dentro de un plan de equipo
Rebalancear el trabajo de equipo para conseguir un mnimo programa.
Calcular los riesgos y asignar responsabilidades para cada clase de riesgo.
Tener una puesta en marcha de postmortem.
Al final de cada puesta en marcha, el equipo revisa los planes y los riesgos del proyecto con la direccin.
Una vez que el proyecto comienza, el equipo realiza semanalmente reuniones y peridicamente informa
de ello a la direccin y al cliente. Despus de establecer estos pasos, TSP produce los siguientes
resultados:
Se han escrito las metas

Se han definido los roles
Cuadro Comparativo de Modelos de Calidad
Caracterstica
Propsito
PSP
Inspecciones
CMM
ISO900
Mejora de la calidad
Mejora del gerenciamiento
Metodologa
Gerenciamiento y mejora de la
calidad
Prescriptiva
Presciptiva
Descriptiva
Gerenciamiento de la
calidad
Descriptiva
Definicin
Exacta
Exacta
Vaga
Vaga
Audiencia
Desarrolladores y gerentes
Desarrolladores
Gerentes
Gerentes
Cobertura
Ciclo de vida del desarrollo
Verificacin y validacin
Gerenciamiento de
proyectos
Aseguramiento de la
Calidad
Versin: 1.0.0
Pgina 32 de 59
Costo
Calidad
Implementacin
Muy bajo
Muy alta
Semanas
Bajo
Alta
Das
Alto
Baja
Aos
Alto
Baja
Aos
Alcance
Integral
Estrecho
Ambiguo
Ambiguo
Cuan Mensurable
es
Muy Alto
Alto
Bajo
Bajo
Por qu PSP nos conduce al CMMI?

El CMMI significa decir que se hace, hacer lo que se dice y medirlo. Adoptando el framework del RUP
(Rational Unified Process ), es posible aplicar el proceso que se convirti en el estndar de ipso de la
industria de desarrollo de software, en una forma sencilla de seguir y aplicar, tal como lo es una interfaz
web.
Es posible agregarle variantes de procesos o prcticas para customizarlo al proceso de la organizacin,
y aun as continuar conformando el acercamiento por RUP. Una vez definido el proceso, se la pone a
disposicin de todos los miembros del equipo en su desktop. Esto hace que el proceso este accesible
para todos, ayudando a asegurar la comunicacin y consistencia y evitando gastar el tiempo
determinado cual es el prximo paso a seguir.
1.6 Administracin de Proyecto

Administrar un programa o proyecto complejo requiere una buena comprensin de las actividades que
deben ser concretadas, sus relaciones con el problema del negocio y un mecanismo para entender el
progreso actual del proyecto comparado contra los milestones del negocio. Combinando el Rational
Unified Process con el Rational Project Console, el equipo puede seguir un proceso definido y luego
reportar el progreso del proyecto referido a dicho proceso.
Ingeniera
La ingeniera de procesos es la base de este largo camino. Las disciplinas de ingeniera de
administracin de requerimientos, anlisis, diseo, implementacin y test son unificadas dentro del
proceso e desarrollo de un sistema o producto.
Rational provee el sistema y el ambiente de desarrollo de software lder del mercado a travs de la
familia de productos de las Suites Rational. Esta solucin para todo ciclo de vida es un conjunto de
herramientas integradas que, cuando son implementadas en un conjunto con las mejores prcticas
definidas en el RUP, ayudan a las organizaciones a adherir al CMMI.
Ambiente de Soporte
El como hacer del rea de Procesos de Configuracin Management del CMMI puede ser alcanzada
usando Unified Change Management ( UCM ), las mejores prcticas de Rational para encarar la
administracin del cambio desde la formulacin del requerimiento al relase. El UCM en conjunto con el
software Rational de configuracin management, Rational ClearCase y Rational ClearQuest, ayuda a
alcanzar la mayora de los requerimientos del CMMI para configuracin management.
PSP (Personal Software Process ) es un marco de procesos propuestos para la disciplina individual del
desarrollador de software, y TSP ( Team Software Process ) esta compuesto por procesos para
pequeos equipos de desarrollo.
Versin: 1.0.0
Pgina 33 de 59
PSP y TSP fueron propuestos por Watts Humphrey, en el SEI/CMU, con el gran objetivo de cambiar la
cultura de desarrollo de software, promoviendo la idea de hacer todo de forma correcta en la primera
vez y desarrollar el software totalmente libre de errores.
PSP y TSP tambin pueden ser utilizados para ayudar y acelerar la implantacin de CMMI, y
directamente relacionados al nivel 5 del CMMI.
Tambin Tiene el objetivo de presentar un abordaje para la implementacin del nivel 4 de CMMI usando
PSP y TSP, en muy pequeas empresas (empresas de una incubadora, con 4 a 10 desarrolladores de
software ). Toda la presentacin est basada en un caso real, conducido en Brasil, con 7 empresas de
incubadoras.
El PSP en comunicacin con el CMMI hace uso de un gran nmero de Formatos, los que son tiles para
hacer un anlisis a fondo del programa a desarrollar. Los Formatos son los siguientes:
Bitcora de Registro de Tiempo Transcurrido

El tiempo empleado en cada fase y los defectos encontrados en cada fase, se calculan de forma
especifica
Bitcora del Registro de Defectos.- es promover la mejora continua cada vez que se haga un
proyecto
Resumen del Plan de Proyecto.- Rene las estimaciones y los datos reales que conforman al
proyecto en toda amplitud para que al final realicen las comparaciones necesarias y exista un
histrico de todos los proyectos realizados.
Versin: 1.0.0
Pgina 34 de 59
Unidad II
Calidad en proyectos de T.I.

2.1
ISO y MOPROSOFT
Introduccin
MoProSoft es un modelo de calidad que permitir a la pequea y mediana empresa de desarrollo de
software, el acceso a las prcticas de Ingeniera de Software de clase mundial.
Moprosoft, tiene por objetivo proporcionar a la industria mexicana, y a las reas internas dedicadas al
desarrollo y mantenimiento de software, un conjunto integrado de las mejores prcticas basadas en los
modelos y estndares reconocidos internacionalmente, tales como ISO 9000:2000, CMM-SW, ISO/ IEC
15504, PMBOK, SWEBOK entre otros. En resumen el objetivo es: Fortalecer a la industria de software
en Mxico
Moprosoft fue desarrollado durante el 2002, como consecuencia de los acuerdos de la mesa de la
Estrategia 6 del Programa para el Desarrollo de la Industria de Software (PDIS- ProSoft) dirigido por la
Secretara de Economa, bajo un convenio con la Facultad de Ciencias de la UNAM.
2.1.1 Estrategias
1.
2.
3.
4.
5.
6.
Promover exportaciones y la atraccin de inversiones

Educacin y formacin de personal competente
Contar con un marco legal promotor de la industria
Desarrollar el mercado interno
Fortalecer a la industria local
Alcanzar niveles internacionales en capacidad de procesos
6.1 Formacin de instituciones de capacitacin y asesora en mejora de procesos.
6.2 Definicin de un modelo de procesos y de evaluacin apropiado para la industria de
software mexicana.
6.3 Apoyo financiero para la capacitacin y la evaluacin de capacidad de procesos.
7. Promover la construccin de infraestructura fsica y de telecomunicaciones
Cul es el primer paso para implementar MoProSoft ?

1.El primer paso, sin lugar a dudas, es sentir la necesidad de cambio, de la mejora continua, de la
competitividad creativa.
2. Expresarlo a la organizacin.
2.1.2 Ventajas
1
2
3
Al tener prcticas integradas, que abarcan desde la gestin de negocio hasta el desarrollo y
mantenimiento de software, las empresas tendran mayor control sobre su desempeo en el
mercado.
El costo de la incorporacin del nuevo personal podra disminuir si se enfocan la educacin y la
capacitacin a un modelo nico.
Las empresas pequeas, al seguir procesos similares, podran asociarse con mayor facilidad para
afrontar proyectos de mayor envergadura.
Versin: 1.0.0
Pgina 35 de 59
La exportacin de servicios de software de las empresas mexicanas sera ms factible. Incluso se

podra disminuir la necesidad de la intermediacin de las empresas trasnacionales, gracias a que
Moprosoft considera las prcticas reconocidas internacionalmente.
2.1.3 Caractersticas:
1
2
3
4
5
Especfico para el desarrollo y mantenimiento de software.

Fcil de entender (comprensible).
Definido como un conjunto de procesos.
Prctico y fcil de aplicar, sobre todo en organizaciones pequeas.
Orientado a mejorar los procesos para contribuir a los objetivos del negocio y no simplemente ser un
marco de referencia de certificacin.
6 Debe de tener un mecanismo de evaluacin o certificacin, que indique un estado real de una
organizacin durante un periodo de vigencia especfico.
7 Aplicable como norma mexicana.
8 No costoso en su adopcin.
9 Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO
9000:2000 [1] o CMM1 V1.1[2].
10 Es un modelo basado en tres categoras de procesos:
10.1
Alta Direccin
10.2
Gestin
10.3
Operacin
2.1.4 Arquitectura
Versin: 1.0.0
Pgina 36 de 59
Actividades de los directivos de la organizacin
Subprocesos de Gestin de Recursos:

1. Recursos Humanos y ambiente de trabajo
2. Bienes, Servicios e Infraestructura.
3. Conocimiento de la organizacin.
Proceso de Administracin de proyectos especficos

Inicio
Planeacin
Realizacin
Evaluacin
Cierre
Proceso de Desarrollo y manto. de software.

Ciclos de Desarrollo
Fases de un ciclo
Actividades de una fase
2.1.5 Patrn del proceso.

Definicin del proceso.
Proceso (Nombre)
Categora (Nombre)
Propsito
Descripcin
Objetivos
Indicadores
Metas cuantitativas
Responsabilidad y autoridad
Versin: 1.0.0
Pgina 37 de 59
Procesos relacionados
Entradas (Nombre, Fuente)
Salidas (Nombre, Descripcin, Destino)
Productos internos (Nombre, Descripcin)
Referencias bibliogrficas (ISO9001:2000, SW-CMM 1.1, ISO 15504, otras)
Prcticas
Roles involucrados y capacitacin

Actividades (Rol, Actividad, Objetivo, Tareas)
Diagrama de flujo de trabajo (actividades de UML)
Verificaciones y validaciones (Actividad, Producto, Rol, Descripcin)
Incorporacin a la Base de Conocimiento (Producto, Forma de aprobacin)
Recursos de Infraestructura (Actividad, Recurso)
Mediciones (Ejemplo de medicin por indicador)
Capacitacin
Situaciones excepcionales
Lecciones aprendidas
Guas de ajuste
Sin invalidar el cumplimiento de los objetivos del proceso
2.1.6 Generalidades
Versin: 1.0.0
Pgina 38 de 59
Versin: 1.0.0
Pgina 39 de 59
2.2 Normas ISO

Las normas de la serie ISO 9000 son estndares internacionales para los sistemas de gestin de la
calidad. Contienen los lineamientos mnimos que debe tener una organizacin para que pueda ser
reconocida mundialmente como gestora del aseguramiento de la calidad.
1.
2.
3.
4.
ISO 9000 2000: Principios Bsicos y Vocabulario

ISO 9001 2000: Requisitos del Sistema de Gestin de Calidad
ISO 9004 2000: Gua para la Gestin de Calidad
ISO 9011 2000: Gua para la Administracin y Conduccin de Auditoras Ambientales y de
Calidad.
Indica como auditar los procesos que constituyen al sistema de gestin de la calidad. Las directrices
tambin abarcan a un sistema de gestin ambiental o segn ISO 14001 / 96
2.2.1 ISO 9126. Calidad del software y mtricas de evaluacin.
ISO 9126 es un estndar internacional para la evaluacin del Software. Est supervisado por el proyecto
SQuaRE, ISO 25000:2005, el cual sigue los mismos conceptos.
La ISO 9126 [basada en el modelo de Mc Call] plantea un modelo normalizado que permite evaluar y
comparar productos sobre la misma base.
Aqu la calidad queda definida a un alto nivel de abstraccin por seis caractersticas:
Versin: 1.0.0
Pgina 40 de 59
Funcionalidad: Atributos que se relacionan con la existencia de un conjunto de funciones y sus

propiedades especficas. Las funciones satisfacen necesidades declaradas o implcitas [ISO
9126: 1991]
Fiabilidad: Capacidad de un sistema para mantener su nivel de rendimiento
Usabilidad: Esfuerzo necesario para el uso y la valoracin individual de tal uso, por parte de un
conjunto de usuarios. [ISO 9126: 1991]
Portabilidad: Es la capacidad de un sistema para ser transferido de un entorno a otro. [ISO
9126: 1991]
Mantenibilidad: Es el esfuerzo necesario para realizar modificaciones especficas. [ISO 9126:
1991]
Eficiencia: Es la relacin entre el nivel de prestaciones de un sistema y el volumen de recursos
utilizados en condiciones declaradas. [ISO 9126: 1991]
Este estndar no proporciona mtricas ni mtodos de medicin, por lo que no son prcticas las
mediciones directas de las caractersticas de calidad.
Para resolver este problema se revis la ISO 9126 y se incluy un nuevo modelo de calidad que
distingue entre tres aproximaciones a la calidad de producto en ISO 14598, a saber:
Parte1. Modelo de Calidad ISO/IEC 9126-1

Parte2. Mtricas Externas ISO/IEC 9126-2
Parte3. Mtricas Internas ISO/IEC 9126-3
Parte4. Mtricas de Calidad en el uso ISO/IEC 9126-4
ISO 9126-1
Este estndar define la usabilidad como la capacidad de un producto software de ser comprendido,
aprendido, usado y de ser atractivo para el usuario, en condiciones especficas de uso.
Esta definicin es pone el nfasis en los atributos internos y externos del producto, los cuales
contribuyen a su usabilidad. Se observa que la usabilidad no depende slo del producto, sino tambin
del usuario. Atributos para poder estudiarla:
Facilidad de aprendizaje
Eficiencia
Recuerdo en el tiempo
Tasa de errores
Satisfaccin
Mtodos de evaluacin de usabilidad

Se pueden considerar dos grupos de UEM [Usability Evaluation Methods]:
Los UEM empricos, donde participan:
Usuarios
Evaluadores
Observadores
Expertos en test
Versin: 1.0.0
Pgina 41 de 59
Los UEM analticos donde no tienen acceso los usuarios, incluyen un equipo de especialistas en
usabilidad. Para el proceso de inspeccin se utilizan directrices o heursticas para realizar el proceso de
inspeccin.
Mtricas de usabilidad
Por medicin se entiende el proceso de atribuir nmeros o smbolos a los atributos de las entidades en
el mundo real. a travs de la medicin es posible juzgar lo que se mide.
Una mtrica es la correspondencia del mundo real, a un mundo formal. Una mtrica es un valor
numrico asignado a algn evento del mundo real, software, sitio web, aplicacin web, etc.
Un atributo es la caracterstica de una entidad de tipo directo o indirecto, por ejemplo, links no
operativos, microcdigo no accesible, etc.
El uso de mtricas no limita la intervencin humana y ofrece una reduccin de la subjetividad en la
evaluacin de calidad de un sitio o aplicacin web, etc.
ISO 9126-2 Capacidad de anlisis y de cambio
Versin: 1.0.0
Pgina 42 de 59
9123-3 Mtricas internas para la evaluacin del software.

ISO/IEC TR 9126-3:2003
Las mtricas internas se pueden son aplicables a:
A un producto de software no ejecutable.

Aplican durante las etapas de su desarrollo.
Permiten medir la calidad de los entregables intermedios.
Permiten predecir la calidad del producto final.
Permiten al usuario iniciar acciones correctivas temprano en el ciclo de desarrollo.
Tablas de Mtricas
Organizadas por caracterstica y subcaracterstica, cada mtrica contiene:
1. Nombre
6. Tipo de escala
2. Propsito
7. Tipo de medida
3. Mtodo de aplicacin
8. Fuente de medicin
4. Medidad, frmula y cmputo de datos
9. Referencia a ISO/IEC 12207 SLCP
5. Interpretacin del valor medido
10. Audiencia
Mtricas de Funcionalidad
1.
2.
3.
4.
5.
Adecuidad
Exactidud
Interoperabilidad
Seguridad
Conformidad de la funcionalidad
Ejemplo de Mtrica de Adecuidad

Nombre:
Completitud de implementacin funcional
Propsito:
Qu tan completa est la implementacin funcional.
Mtodo de
Contar las funciones faltantes detectadas en la evaluacin y comparar con el
aplicacin:
nmero de funciones descritas en la especificacin de requisitos.
Medicin,
frmula:
X=1-A/B
A=nmero de funciones faltantes
B = nmero de funciones descritas en la especificacin de requisitos
Interpretacin:
0<=X<=1
Entre ms cercano a 1, ms completa.
Tipo de escala:
Tipo de medida:
absoluta
X=count/count
A=count
B = count
Fuente de
Especificacin de requisitos
medicin:
Diseo
Cdigo fuente
Informe de revisin
ISO/IEC 12207
SLCP:
Audiencia:
Validacin
Revisin conjunta
Requeridores
Desarrolladores
Mtricas de Fiabilidad
1.
2.
3.
4.
Madurez
Tolerancia a fallos
Recuperabilidad
Conformidad de la fiabilidad
Mtricas de Usabilidad
1.
2.
3.
4.
5.
Entendibilidad
Aprendibilidad
Operatibilidad
Atractivo
Conformidad de la usabilidad
Mtricas de Eficiencia
1. Comportamiento en el tiempo
2. Utilizacin de recursos
3. Conformidad de la eficiencia
Mtricas de Mantenibilidad
1.
2.
3.
4.
5.
Analizabilidad
Cambiabilidad
Estabilidad
Examinabilidad
Conformidad de la mantenibilidad
Mtricas de Portabilidad
1.
2.
3.
4.
5.
Adaptabilidad
Instalabilidad
Coexistencia
Remplazabilidad
Conformidad de la transportabilidad
Versin: 1.0.0
Pgina 43 de 59
Versin: 1.0.0
Pgina 44 de 59
Consideraciones al Utilizar las Mtricas

1. Interpretacin de las mediciones
o Diferencia entre conextos de pruebas y de uso.
o Validez de resultados: procedimientos, fuentes de evaluacin, validacin de datos.
o Equilibrio de recursos de medicin.
o Especificacin correcta.
2. Validacin de las mtricas
o Propiedades deseables: confiable, repetible, reproducible, disponible, indicable, correcta,
con significado.
o Demostracin de validez: correlacin, rastreo, consistencia, predictibilidad,
discriminacin.
o 7 propiedades deseables en las mtricas
o 7 propiedades deseables en las mtricas
3. Uso de mtricas para estimacin y prediccin
4. Deteccin de desviaciones y anomalas
5. Presentacin de resultados de medicin
o Grficas de barras, matriz de desempeo, grficas de Pareto, grficas de correlacin,
etc.
Modelo de Medicin de la Calidad
Actividad 1
Actividad 2 Actividad
Actividad 4
Actividad 5 Actividad 6
3
Fase
Actividad
Actividad 8
Anlisis de
Diseo de
Diseo
Codificacin
Integracin
Integracin
requisitos
arquitectura
detallado
y pruebas de y pruebas
y pruebas
de
software
de software
de sistema
Calidad en
Instalacin
Aceptacin
y apoyo
software
Referencia
Calidad requerida
Calidad en
Calidad en Calidad en
Calidad en
Calidad en
Calidad en
modelo
por el usuario
uso
uso
uso predicha uso
uso
uso
uso medida
9126
Calidad interna
predicha
predicha
Calidad
predicha
predicha
predicha
Calidad
requerida
Calidad
Calidad
externa
Calidad
Calidad
Calidad
externa
Calidad externa
externa
externa
medida
externa
externa
externa
medida
requerida
predicha
predicha
Calidad
medida
medida
medida
Calidad
Calidad
Calidad
externa
Calidad
Calidad
Calidad
interna
interna
interna
predicha
externa
interna
interna
medida
medida
medida
Calidad
predicha
medida
medida
interna
Calidad
medida
interna
medida
Entregables
Requisitos de
clave
Diseo de
Diseo
Cdigo y
Producto y
Sistema
Sistema
Producto
calidad del usuario arquitectura
detallado
resultados
resultados
integrado y
instalado
entregado
Requisitos de
de
de pruebas
de pruebas
resultados
calidad externa
software
Requisitos de
calidad interna
de pruebas
Mtricas
Internas (externas
utilizadas
pueden validar
Internas
Internas
Versin: 1.0.0
Pgina 45 de 59
Internas y
Internas y
Internas y
Internas y
Calidad en
externas
externas
externas
externas
el uso,
especificaciones)
internas y
externas
Pasos Sugeridos
1.
2.
3.
4.
5.
Identificacin de requisitos de calidad

Especificacin de la evaluacin
Diseo de la evaluacin
Ejecucin de la evaluacin
Retroalimentacin a la organizacin
Mtricas Internas Puras
Trazabilidad
Nmero ciclomtico
Complejidad del flujo de
informacin
Modularidad
Tamao del programa
Enunciados condicionales
Referencia unificada de datos

Adecuidad de nombre de variables
Proporcin de acomplamiento entre mdulos por
datos
Enunciados del programa
Tamao promedio de mdulo
Proporcin de acomplamiento entre mdulos por
funciones
9126 -4 Mtricas de evaluacin de calidad

Estas son las mtricas propuestas en el estndar:
Mtricas relacionadas con la efectividad

Mtricas relacionadas con la productividad
Mtricas relacionadas con la seguridad
Mtricas relacionadas con la satisfaccin
2.2.2 ISO 10006

ISO 10006 es una norma para la gestin de proyectos, su equivalente es llamado UNE-66916 (Octubre
del 2003).
La norma ISO 10006:2003, los sistemas de gestin de la calidad - Directrices para la gestin de la
calidad en los proyectos, es una norma internacional elaborada por la Organizacin Internacional de
Normalizacin.
ISO 10006:2003 sirve de gua sobre la aplicacin de gestin de la calidad en los proyectos.
Es aplicable a proyectos de distinta complejidad, la duracin de grandes o pequeos, de corto o largo, en
diferentes ambientes, y con independencia del tipo de producto o proceso en cuestin. Esto puede
requerir cierta adaptacin de la orientacin para adaptarse a un proyecto particular.
Versin: 1.0.0
Pgina 46 de 59
ISO 10006:2003 no es una gua para la "gestin de proyectos" en s. Orientacin sobre la calidad en los
procesos de gestin del proyecto se discute en esta Norma Internacional. Orientacin sobre la calidad en
el producto de un proyecto relacionado con los procesos, y en el "enfoque de proceso", est cubierto en
la norma ISO 9004. Un nuevo "Gestin de proyectos - Gua para la Gestin de Proyectos" es la norma
ISO 21500 en preparacin (2008).
Dado que la norma ISO 10006:2003 es un documento de orientacin, no est destinado a ser utilizado
para propsitos de certificacin / registro.
2.2.3 ISO/IEC 27000

La serie de normas ISO/IEC 27000 son estndares de seguridad publicados por la Organizacin
Internacional para la Estandarizacin (ISO) y la Comisin Electrotcnica Internacional (IEC).
La serie contiene las mejores prcticas recomendadas en Seguridad de la informacin para desarrollar,
implementar y mantener Especificaciones para los Sistemas de Gestin de la Seguridad de la
Informacin (SGSI). La mayora de estas normas se encuentran en preparacin e incluyen:
ISO/IEC 27000 - es un vocabulario estndar para el SGSI. Se encuentra en desarrollo

actualmente.
ISO/IEC 27001 - es la certificacin que deben obtener las organizaciones. Norma que especifica
los requisitos para la implantacin del SGSI. Es la norma ms importante de la familia. Adopta un
enfoque de gestin de riesgos y promueve la mejora continua de los procesos. Fue publicada
como estandar internacional en octubre 2005. ISO/IEC 27002 - Information technology - Security
techniques - Code of practice for information security management. Previamente BS 7799 Parte
1 y la norma ISO/IEC 17799. Es cdigo de buenas prcticas para la gestin de seguridad de la
informacin. Fue publicada en julio de 2005 como ISO 17799:2005 y recibi su nombre oficial
ISO/IEC 27002:2005 el 01 de julio de 2007.
ISO/IEC 27003 - son directrices para la implementacin de un SGSI. Es el soporte de la norma
ISO/IEC 27001. Se encuentra preparacin y probablemente sea publicada en 2009.
ISO/IEC 27004 - son mtricas para la gestin de seguridad de la informacin. Es la que
proporciona recomendaciones de quin, cundo y cmo realizar mediciones de seguridad de la
informacin. Se encuentra preparacin y probablemente sea publicada en 2009.
ISO/IEC 27005 - trata la gestin de riesgos en seguridad de la informacin. Es la que
proporciona recomendaciones y lineamientos de mtodos y tcnicas de evaluacin de riesgos de
Seguridad en la Informacin, en soporte del proceso de gestin de riesgos de la norma ISO/IEC
27001. Es la ms relacionada a la actual British Standard BS 7799 parte 3. Publicada en Junio
de 2008.
ISO/IEC 27006:2007 - Requisitos para la acreditacin de las organizaciones que proporcionan la
certificacin de los sistemas de gestin de la seguridad de la informacin. Esta norma especfica
requisitos especficos para la certificacin de SGSI y es usada en conjunto con la norma 170211, la norma genrica de acreditacin. * ISO/IEC 27007 - Es una gua para auditar al SGSI. Se
encuentra en preparacin.
ISO/IEC 27799:2008 - Es una gua para implementar ISO/IEC 27002 en la industria de la salud.
2.2
Versin: 1.0.0
Pgina 47 de 59
Estndares para documentacin de proyectos.
2.2.1 ISO/IEC,26514:2008
La documentacin puede ser la primera cosa concreta que el usuario ve y por lo tanto influye en las
primeras impresiones de los usuarios del producto de software. Si la informacin se suministra en forma
prctica y es fcil de encontrar y entender, el usuario rpidamente puede ser competente para utilizar el
producto. Por lo tanto, una buena documentacin no slo ayuda al usuario a reducir el costo de
formacin y apoyo, sino que tambin mejora la reputacin del producto, su fabricante y sus proveedores.
La documentacin a menudo es considerada como algo que se hace despus de que el software ha sido
implementado. Sin embargo, para documentacin de alta calidad del software, su desarrollo debe ser
considerado como una parte integral del software (ciclo de vida).
Las normas desarrolladas para ayudar a los usuarios con esta situacin son:
ISO / IEC 15288:2008, sistemas y software de ingeniera - procesos del ciclo de vida del sistema.
ISO / IEC 12207:2008, Sistemas y de ingeniera de software -- Procesos del ciclo de vida del software, el
diseo y desarrollo de documentacin como parte del ciclo de vida del software procesos. Se define el
proceso de documentacin desde el punto de vista del desarrollador de Documentacin.
NOTA: otras normas internacionales en la familia ISO / IEC 265NN estn en preparacin o en proyecto
para abordar la documentacin y los procesos de gestin de la informacin de los puntos de vista de los
directivos, asesores y evaluadores, y de compradores y proveedores. Adems de definir un proceso
estndar, esta norma Internacional tambin incluye la documentacin del producto. Esta norma
internacional especifica la estructura, contenido y formato de la documentacin, y tambin proporciona
informativas de orientacin para el estilo de documentacin del usuario.
Sistemas e ingeniera de software - Requisitos para los diseadores y desarrolladores de documentacin
de usuario
mbito de aplicacin.
Se define el alcance, propsito, la organizacin, utilizando candidatos de esta norma internacional. Esta
Norma Internacional apoya el inters de los usuarios de software realizar documentacin coherente,
completa, exacta, y til.
La primera parte de esta norma internacional abarca el proceso de documentacin del usuario para los
diseadores y los desarrolladores de la documentacin. En l se describe la forma de establecer la
informacin que los usuarios necesitan, determina cmo preparar, presentar y asegurarse que la
informacin est disponible a los usuarios. No se limita al diseo y desarrollo de la fase del ciclo de vida,
sino que incluye actividades de toda la gestin de informacin y los procesos de documentacin.
La segunda parte de esta norma internacional establece los requisitos mnimos para la estructura, el
contenido y formato de la documentacin de usuario. Se aplica a los manuales de usuario impreso,
ayuda en lnea, tutoriales y documentacin de referencia del usuario, estos pueden ser electrnicos o
impresos.
Esta Norma Internacional puede ser til para el desarrollo de los siguientes tipos de documentacin,
aunque no cubre todos los aspectos de ellos:
1. Documentacin de otros productos de software;
2. Sistemas multimedia con animaciones de video y sonido;
3. Capacitacin basada en computadora (CBT) y los paquetes de materiales de los cursos
especializados destinados principalmente para uso en programas de capacitacin formal;
Versin: 1.0.0
Pgina 48 de 59
4. Documentacin producida para los instaladores, operadores de computadoras, o el sistema de

administradores.
Documentacin de mantenimiento.
5. Describir el funcionamiento interno de sistemas de software.
6. Documentacin incorporada en la interfaz del usuario.
Esta Norma Internacional tambin es aplicable a una variedad de especialistas:
1. Especialistas en usabilidad y analistas de negocio que se identifican las tareas que los usuarios
previstos llevar a cabo con el software.
2. Personas que desarrollan y editar el contenido escrito de la documentacin del usuario.
3. Diseadores grficos con experiencia en medios de comunicacin electrnicos.
4. Diseadores de la interfaz de usuario y la ergonoma, expertos que trabajan juntos para disear
la presentacin de la documentacin sobre la pantalla.
El orden de las clusulas en esta norma no implica que la documentacin debe ser
desarrollada o presentada al usuario en este orden.
En el anexo A podemos observar una plantilla general para cubrir los apartados ms importantes de la
norma.
2.2.2 IEEE 830.

Un buen Documento de requisitos, pese a no ser obligatorio que siga estrictamente la organizacin y el
formato dados en el estndar 830, s debera incluir, de una forma o de otra, toda la informacin
presentada en dicho estndar. El estndar de IEEE 830 no est libre de defectos por ello ha sido
criticado por mltiples autores, llegndose a cuestionar incluso si es realmente un estndar en el sentido
habitual que tiene el trmino en otras ingenieras. Con propsitos fundamentalmente docentes, se
presenta cmo se organizara un Documento de Requisitos segn el estndar IEEE 830.
Plantilla para IEEE 830
1. Introduccin
En esta seccin se proporcionar una introduccin a todo el documento de Especificacin de Requisitos
Software (ERS). Consta de varias subsecciones que se revisan a continuacin.
1.1 Propsito. Se define el propsito del documento ERS y se especificar a quin va dirigido el
documento.
1.2 mbito del Sistema. Se determinan los siguientes datos:
Nombre al futuro sistema (p.ej. MiSistema)

Explicar lo que el sistema har y lo que no har.
Se describirn los beneficios, objetivos y metas que se espera alcanzar con el futuro
sistema.
Se referencian todos aquellos documentos de nivel superior (p.ej. Ingeniera de
Sistemas, que incluyen Hardware y Software, se debe mantener la consistencia con el
documento de especificacin de requisitos globales del sistema, si existe).
1.3 Definiciones, Acrnimos y Abreviaturas: En esta subseccin se definen todos los trminos,
acrnimos y abreviaturas utilizadas en la ERS.
1.4 Referencias. Mostr una lista completa de todos los documentos referenciados en la ERS.
Versin: 1.0.0
Pgina 49 de 59
2. Descripcin General
En esta seccin se describen todos aquellos factores que afectan al producto y a sus requisitos. No se
describen los requisitos, sino su contexto. Esto permite definir con detalle los requisitos en la seccin 3,
haciendo que sean ms fciles de entender.
2.1 Perspectiva del Producto. Se debe relacionar el futuro sistema (producto software) con otros
productos. Si el producto es totalmente independiente de otros productos, tambin debe
especificarse aqu. Si la ERS define un producto que es parte de un sistema mayor, esta
subseccin relaciona los requisitos del sistema mayor con la funcionalidad del producto
descrito en la ERS, y se identifican las interfaces entre el producto mayor y el producto aqu
descrito. Se recomienda utilizar diagramas de bloques.
2.2 Funciones del Producto. Se muestra un resumen a grandes rasgos, de las funciones del
futuro sistema. Por ejemplo, en una ERS para un programa de contabilidad, esta subseccin
mostrara que el sistema soportar el mantenimiento de cuentas, el estado de las cuentas y
facilitar la facturacin, sin mencionar el enorme detalle que cada una de estas funciones
requiere. Las funciones deben mostrarse de forma organizada, y pueden utilizarse grficos,
siempre y cuando dichos grficos reflejen las relaciones entre funciones y el diseo del
sistema.
2.3 Caractersticas de los Usuarios. Se deben describir las caractersticas generales de los
usuarios del producto, incluyendo nivel educacional, experiencia y experiencia tcnica.
2.4 Restricciones. Describir las limitaciones que se imponen sobre los desarrolladores del
producto. Polticas de la empresa
Limitaciones del hardware.
Interfaces con otras aplicaciones.
Operaciones paralelas.
Funciones de auditora.
Funciones de control Lenguaje(s) de programacin.
Protocolos de comunicacin.
Requisitos de habilidad
Criticalidad de la aplicacin.
Consideraciones acerca de la seguridad
2.5 Suposiciones y Dependencias. Describir aquellos factores que, si cambian, pueden afectar
a los requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organizacin de
ciertas unidades de la empresa, o pueden presuponer que el sistema correr sobre cierto
sistema operativo. Si cambian dichos detalles en la organizacin de la empresa, o si cambian
ciertos detalles tcnicos, como el sistema operativo, puede ser necesario revisar y cambiar
los requisitos.
2.6 Requisitos Futuros. Esta subseccin esboza futuras mejoras al sistema, que podrn
analizarse e implementarse en un futuro.
Versin: 1.0.0
Pgina 50 de 59
3. Requisitos especficos.
Contiene los requisitos a un nivel de detalle; permitir planificar y realizar las pruebas que demuestren si
el sistema satisface, o no, los requisitos. Todo requisito aqu especificado describir comportamientos
externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la
seccin ms larga e importante de la ERS. Se debern aplicar los siguientes principios:
El documento deber ser perfectamente entendible por personas de muy distintas formaciones e
intereses.
Se referencian aquellos documentos relevantes que poseen alguna relacin sobre los requisitos.
Todo requisito deber ser unvocamente identificable mediante un cdigo o sistema de
numeracin.
Lo ideal, aunque en la prctica no siempre realizable, es que los requisitos posean las siguientes
caractersticas:
No ambiguos: Cada requisito tiene una sola interpretacin. Para eliminar la ambigedad
inherente a los requisitos expresados en lenguaje natural, se debern utilizar grficos o
notaciones formales. En el caso de utilizar trminos que, habitualmente, poseen ms de
una interpretacin, se definirn con precisin en el glosario.
Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene
incluir todas las posibles respuestas del sistema a los datos de entrada, tanto valido
como no valido.
Consistentes: Los requisitos no pueden ser contradictorios.
Clasificados: Los requisitos pueden clasificarse por importancias (esenciales,
condicionales u opcionales) o por estabilidad (cambios que se espera que afecten al
requisito). Esto sirve, ante todo, para no emplear excesivos recursos en implementar
requisitos no esenciales.
Verificables: La ERS es verificable si todos sus requisitos son verificables. Un requisito
es verificable (testeable) si existe un proceso finito y no costoso para demostrar que el
sistema cumple con el requisito. Un requisito ambiguo no es, en general, verificable.
Expresiones como a veces, bien, adecuado, etc. introducen ambigedad en los
requisitos.
Modificables: La ERS es modificable si se encuentra estructurada de forma que los
cambios a los requisitos pueden realizarse de forma fcil, completa y consistente.
Trazables: La trazabilidad hacia atrs indica el origen (documento, persona, etc.) de cada
requisito. La trazabilidad hacia delante de un requisito R indica qu componentes del
sistema son los que realizan el requisito R.
3.1 Interfaces Externas. Se describen los requisitos que afecten a la interfaz de usuario, interfaz
con otros sistemas (hardware y software) e interfaces de comunicaciones.
3.2 Funciones. Se especifican las acciones que deber llevar a cabo el software (quiz es la
seccin ms larga e importante del documento).
2.2.3 PMBOK.
The Project Management Body of Knowledge (PMBOK) es un trmino que describe la suma de
conocimientos dentro de la gestin de proyectos. El PMBOK incluye conocimiento de las prcticas
tradicionales que se aplican ampliamente, as como conocimiento de las prcticas innovadoras y
avanzadas que han visto un uso ms limitado. El PMBOK, cuya referencia en espaol es Gua de
Fundamentos de la Direccin de Proyectos, es una publicacin del Instituto de Direccin de Proyectos
(PMI) que es una organizacin sin fines de lucro de origen estadounidense y de presencia actual mundial
Versin: 1.0.0
Pgina 51 de 59
Las operaciones y proyectos difieren principalmente en que las operaciones estn en curso y repetitivas
mientras que los proyectos son temporales y nicos. Un proyecto as puede definirse en trminos de sus
caractersticas distintivas de un proyecto es un esfuerzo temporal emprendido para crear un producto o
servicio nicos. Los proyectos son a menudo componentes crticos de la estrategia de negocio de la
organizacin ejecutante. Por ejemplos:
Desarrollar un nuevo producto o servicio.

Efectuar un cambio en la estructura, la dotacin de personal, el estilo de una organizacin.
La creacin o adquisicin de un sistema de informacin nueva o modificada.
La construccin de un edificio o instalacin.
Ejecucin de una campaa para un cargo poltico.
Aplicacin de un procedimiento nuevo negocio o proceso
PMBOK define proyecto como un esfuerzo temporal tomado para crear un producto, servicio o resultado
nico. Para enfocar el anlisis de la gestin plantea la idea de la restriccin desde tres perspectivas:
Alcance: Describe claramente el objetivo del proyecto.

Tiempo: Enfoca el tiempo asignado al proyecto.
Costo: Observa el costo involucrado.
Las reas de conocimiento en la gestin de proyectos son:

1.
2.
3.
4.
5.
6.
7.
8.
9.
Alcance
Tiempos
Costos
Calidad
Recursos Humanos
Comunicaciones
Riesgos
Adquisiciones
Integracin
Las reas de dominio requerido por el equipo de proyecto son:
Habilidades Interpersonales
Conocimiento y Habilidades de Gestin
Entendimiento del Entorno del Proyecto
Conocimiento aplicado en el rea, Estndares y Regulaciones
Versin: 1.0.0
Pgina 52 de 59
Fig. Relacin entre Grupos de procesos y reas del Conocimiento
2.2.3.1 Estructura de la gua del PMBOK

La traduccin del sta metodologa del ingls al espaol se realiz como una gua base, dividida en
secciones y captulos.
Seccin I: Marco contextual de la direccin de Proyectos.
Proporcionando una estructura bsica para entender la direccin de proyectos.
Captulo 1, Introduccin. Define los trminos clave y proporciona una descripcin general del
resto de la gua.
Captulo 2, Ciclo de vida del proyecto y Organizacin. Se refiere al entorno en el cual operan
los proyectos.
Seccin II: Norma para la direccin de proyectos.
Especifica todos los procesos de direccin de proyectos que usa l equipo del proyecto para gestionar un
proyecto.
Captulo 3, Procesos de Direccin de proyectos. Describe los 5 grupos de procesos de
direcciones de proyectos aplicables a cualquier proyecto y los procesos de direccin de
proyectos que componen tales grupos.
Seccin III: reas de conocimiento de la direccin de proyectos.
Organiza los 44 procesos de direccin de proyectos de los grupos de procesos de direccin de
proyectos, en 9 reas de conocimiento.
Captulo 4, Integracin del proyecto. Procesos y actividades que forman parte de los diversos
elementos de la direccin de proyectos, que identifican, definen, combinan, unen y coordinan
dentro de los grupos de procesos de direcciones de proyectos. Se compone de los proceso de
direccin de proyectos.
Captulo 5, Alcance del Proyecto. Describe los procesos necesarios para asegurarse de que el
proyecto incluya todo el trabajo requerido para completar el proyecto satisfactoriamente.
Versin: 1.0.0
Pgina 53 de 59
Captulo 6, Tiempo del proyecto. Procesos relativos a la puntualidad en la conclusin del

proyecto.
Captulo 7, Costos del proyecto. Procesos involucrados en la planificacin, estimacin,
presupuesto y control de costos de forma que el proyecto se complete dentro del presupuesto
asignado.
Captulo 8, Calidad del proyecto. Aseguramiento del cumplimiento de los objetivos para los
cuales el proyecto fue emprendido.
Capitulo 9, Recursos Humanos. Describe los procesos que organizan y dirigen el equipo del
proyecto.
Captulo 10, Comunicaciones del proyecto. Generacin,
almacenamiento y destino de la informacin en tiempo y forma.
recoleccin,
distribucin,
Captulo 11, Riesgos del proyecto. Desarrollo de gestin de riesgos de un proyecto.

Captulo 12, Adquisiciones del proyecto. Procesos para comprar o adquirir productos, servicios
o resultados, as como para contratar procesos de direccin.
2.3 CMMI
CMMI propone 5 distintos modelos de madurez de las organizaciones:
1. Inicial - Estado inicial donde el desarrollo se basa en la heroicidad y responsabilidad de los
individuos.
o Los procedimientos son inexistentes o localizados a reas concretas.
o No existen plantillas definidas a nivel corporativo.
2. Gestionado - Se normalizan las buenas prcticas en el desarrollo de proyectos (en base a la
experiencia y al mtodo).
o En este nivel consolidado, las buenas prcticas se mantienen en los momentos de
estrs.
o Estn definidos los productos a realizar.
o Se definen hitos para la revisin de los productos.
3. Definido - La organizacin entera participa en el proceso eficiente de proyecto software.
o Se conoce de antemano los procesos de construccin de software.
o Existen mtodos y plantillas bien definidas y documentados.
o Los procesos no solo afectan a los equipos de desarrollo sino a toda la organizacin
relacionada.
o Los proyectos se pueden definir cualitativamente.
4. Cuantitativamente Gestionado
o Se puede seguir con indicadores numricos (estadsticos) la evolucin de los proyectos.
o Las estadsticas son almacenadas para aprovechar su aportacin en siguientes
proyectos.
o Los proyectos se pueden pedir cuantitativamente.
5. Optimizado
o En base a criterios cuantitativos se pueden determinar las desviaciones ms comunes y
optimizar procesos.
Versin: 1.0.0
Pgina 54 de 59
En los siguientes proyectos se produce una reduccin de costes gracias a la anticipacin

de problemas y la continua revisin de procesos conflictivos.
reas de procesos
Conjunto de prcticas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de
objetivos
Las reas de proceso que ayuda a mejorar o evaluar CMMI son 25
Se agrupan en 4 categoras segn su finalidad:

Gestin de proyectos
Ingeniera
Gestin de procesos
Soporte a las otras categoras.
reas de proceso de CMMI (Capability Maturity Model Integration)

rea de proceso
Categora
Nivel de
madurez
Monitorizacin y control de proyecto
Gestin de proyectos
Planificacin de proyecto
Gestin de proyectos
Gestin y acuerdo con proveedores
Gestin de proyectos
Gestin de requisitos
Ingeniera
Gestin de la configuracin
Soporte
Medicin y anlisis
Soporte
Gestin calidad procesos y productos
Soporte
Definicin de procesos
Gestin de procesos
Procesos orientados a la organizacin
Gestin de procesos
Formacin
Gestin de procesos
Gestin integral de proyecto
Gestin de proyectos
Gestin integral de proveedores
Gestin de proyectos
Gestin de equipos
Gestin de proyectos
Gestin de riesgos
Gestin de proyectos
Integracin de producto
Ingeniera
Desarrollo de requisitos
Ingeniera
Versin: 1.0.0
Pgina 55 de 59
Solucin tcnica
Ingeniera
Validacin
Ingeniera
Verificacin
Ingeniera
Anlisis y resolucin de decisiones
Soporte
Entorno organizativo para integracin
Soporte
Rendimiento de los procesos de la org.
Gestin de procesos
Gestin cuantitativa de proyectos
Gestin de proyectos
Innovacin y desarrollo
Gestin de procesos
Anlisis y resolucin de problemas
Soporte
Modelo de Desarrollo de Software

PROPUESTA DE ESTNDAR (Proyecto)
El siguiente estndar est basado en los modelos ISO 15504 / SPICE, I SO 9000 3 y
CMMI con el objetivo de proveer las especificaciones para el desarrollo de software,
que permitan mostrar los niveles de madurez de los procesos para producir software.
El estndar se basa en la dimensin del proceso (tomada del modelo ISO
15504/SPICE), ajustando dicha dimensin a tres niveles (tomados del modelo CMMI),
los cuales son: Inicial, Definido y Optimizado.
Versin: 1.0.0
Pgina 56 de 59
Versin: 1.0.0
Pgina 57 de 59
Glosario de trminos
Calidad
Si buscamos el significado etimolgico de la palabra Calidad, la encontraremos en el Griego Kalos:
Bueno, Hermoso, Apto, Favorable y en el Latn Qualitatem: Propiedad.
Hablando de calidad podemos resaltar sus caractersticas estas pueden ser: Un requisito fsico o
qumico, una dimensin, una temperatura, una presin o cualquier otro requerimiento que se use para
establecer la naturaleza de un producto o servicio. La calidad no tiene un significado popular de lo mejor
en el sentido absoluto, industrialmente quiere decir, mejor dentro de ciertas condiciones del consumidor,
ya que es l, quien en ltima instancia determina la clase y la calidad del producto que desea.
Teniendo en cuenta lo anterior la calidad de un producto puede definirse como:
La resultante de una combinacin de caractersticas de ingeniera y fabricacin, determinante del grado
de satisfaccin que el producto proporcione al consumidor, durante su uso.
Cumplir con las necesidades del cliente y exceder las expectativas en forma constante (siempre).
Es lo que el cliente dice que necesita ms lo que realmente necesita
Suministrar bienes o servicios que no regresan, a clientes que si lo hacen
"Es el conjunto de cualidades de una persona o cosa", "Cualidad" es lo que hace que una persona o
cosa sea lo que es, por su propiedad, atributo, caractersticas, don, virtud, etc.
Esta definicin nos lleva a pensar en trminos como confiable, servicial y durable, trminos que en
realidad son caractersticas individuales que en conjunto constituyen la calidad del producto. Al
establecer lo que entendemos por calidad se exige un equilibrio entre estas caractersticas.
Se establecen para llevar a cabo la gestin de la calidad las siguientes definiciones para llegar
comprender los conceptos relacionados a la Calidad en una empresa.
Anlisis: Consiste en la interpretacin del desempeo de los procesos para su control y mejora. De esta
actividad deriva el conocimiento y aprendizaje organizacional.
Auditoria de calidad: Consiste en la verificacin del cumplimiento de las normas, metodologa y
procedimientos de los sistemas y procesos de calidad
Documentacin: Es el registro cotidiano del desempeo de los procesos y sistemas. Constituye el
acervo de conocimientos de la organizacin y permite evaluar y mantener vigente la tecnologa
operativa.
Estndar: Norma, medida de desempeo esperado, utilizado para evaluar o comparar acciones
realizadas
Efectividad: Se refiere a la capacidad para entregar resultados planeados.
Eficiencia: Se refiere al logro de objetivos y al aprovechamiento de los recursos disponibles.
Versin: 1.0.0
Pgina 58 de 59
Indicador: Es un signo o medicin de un fenmeno.

ndice: Es la relacin cuantitativa entre dos cantidades relacionadas con un mismo fenmeno.
Modelo de calidad: Es una descripcin de la interaccin de los componentes de los principales
elementos del sistema de administracin de la organizacin. Se refiere al esquema predeterminado de
referencia que define los sistemas y prcticas de calidad de la organizacin, congruentes con los
Principios y Valores de Calidad.
Sistema: Es un conjunto de elementos con un fin comn, que se interrelacionan entre s, formando un
todo dinmico.
Sistema de medicin: Es el medio a travs del cual se obtiene informacin sobre el desempeo de la
organizacin, sus productos y servicios. Se integra por diversos elementos, entre los que se incluyen:
Indicadores de control, efectividad, eficiencia y adaptabilidad/flexibilidad
Mtodos de muestreo, frecuencias y responsables, medicin, de calibracin.
Poltica de calidad: Directrices y objetivos generales de una empresa relativos a la calidad, expresados
formalmente por la direccin general. (Forma parte de las polticas generales de una organizacin.
Aseguramiento de Calidad: Consiste en tener y seguir un conjunto de acciones planificadas y
sistemticas, implantadas dentro del Sistema de Calidad de la empresa. Estas acciones deben ser
demostrables para proporcionar la confianza adecuada (tanto a la propia empresa como a los clientes)
de que se cumplen los requisitos del Sistema de la Calidad. Cubre dos aspectos fundamentales y
diferenciados, uno es el decidir la combinacin de ingredientes que dar gusto apropiado (Ingeniera de
la calidad), y otro el asegurar que nuestra produccin tenga la combinacin de ingredientes que
considere apropiados (Control de calidad).
La gestin de calidad: Tiene que ver con la organizacin interna que ejerce la determinacin de los
procesos productivos y de las caractersticas y cualidades de los productos, es decir es la gerencia o el
manejo de los proceso productivos enfocada al mejoramiento continuo. Es el aspecto de la funcin
general de la gestin que determina y aplica la poltica de la calidad, que incluye la planeacin
estratgica, la asignacin de recursos y otras acciones sistemticas en el campo de la calidad, tales
como la planeacin de la calidad, el desarrollo de actividades operacionales y de evaluacin relativas a
la calidad
Control de Calidad: Realiza o participa en la caracterizacin de los nuevos productos en sus diferentes
fases de desarrollo y en el establecimiento de las especificaciones de calidad de los mismos. Desarrolla,
ejecuta o coordina la ejecucin de los mtodos de ensayo para determinar las caractersticas de calidad
de las materias primas, materiales, productos intermedios y productos finales
Disea y realiza los estudios de estabilidad de los productos intermedios.

Participa en el desarrollo, ejecucin y perfeccionamiento del Sistema de Calidad.
Tcnicas y actividades de carcter operativo utilizadas para satisfacer los requisitos relativos a la
calidad.
En la terminologa industrial Control, es el acto de delimitar responsabilidad y autoridad con el fin de

liberar la gerencia de detalles innecesarios, conservando los medios para asegurarse de que los
resultados sean satisfactorios.
Sistema de calidad: Es el conjunto de la estructura de organizacin de responsabilidades, de
Procedimientos, de procesos y de recursos que se establecen para llevar a cabo la gestin de calidad.
Versin: 1.0.0
Pgina 59 de 59
Corresponde a las necesidades propias de una organizacin para satisfacer los objetivos de calidad
propuesto

Calidad en TI

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Calidad en TI

Hochgeladen von

Copyright:

Verfügbare Formate

Universidad Tecnolgica de Puebla

Sistemas de Calidad en Tecnologas de la Informacin

Figura Representacin esquemtica del proceso de control de calidad

Gestin de la calidad total

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Satisfaccin del cliente

Slo Depto. de calidad

Conformidad con las

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

1.1.1 ISO 9001

Emplee una aproximacin de gestin basada en el proceso.

La nueva familia de estndares es la siguiente:

ISO 9000, Normas para la gestin y garanta de la calidad.

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Las cinco secciones en que se divide ISO 9001:2000 son:

1.1.2 ISO 9126

Tabla 1.1. Caracteristicas de ISO-9126 y aspecto que atiende cada una.

1.1.3 ISO 15540 (SPICE, Software Process Improvement and Capability

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Id. Nivel de Capacidad Atributos de Proceso y Descripcin

Atributos de Proceso y Descripcin

El proceso no est implementado o falla en alcanzar su propsito. No es fcil

El propsito del proceso se logra generalmente, aunque no sea rigurosamente

El proceso es gestionado y los entregables resultado de procedimientos

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

CMMI (Modelo de Capacidad de Madurez de Integracin)

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Enfoque del proceso de la organizacin

Gestin de calidad de software

Definidas en un procedimiento documentado

CMM: un modelo para la mejora de Procesos de Software

Mejora la gestin de la calidad es, en gran medida, responsabilidad de la direccin

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Capacidad para llevarla a cabo

Actividades que hay que realizar

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

IEEE (Instituto de Ingenieros en Electricidad y Electrnica)

Fundado en 1884, el Instituto de Ingenieros en Electricidad y Electrnica, Inc. (IEEE) se ha

Dentro de los Captulos Tcnicos ms importantes se encuentran los siguientes:

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

11. Ingeniera de Potencia

IEEE Standard Glossary of Software Engineering Terminology

1.3.1 Planificacin del aseguramiento de la calidad en un proyecto

1.3.2 El plan de Aseguramiento de la calidad del software.

Objetivos de la calidad del proyecto y enfoque adaptado para alcanzarlos

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Informes de problemas, especificando la forma de tratar y corregir los problemas y los

Actividades de aseguramiento de la calidad.