Antologia

Universidad Tecnolgica de Puebla
Tecnologas de la Informacin y Comunicacin
Manual de Asignatura
Basado en Competencias Profesionales
Calidad en el Desarrollo de Software
Enero 2012
ELABOR: UNIVERSIDAD TECNOLGICA

AUTORES: M.A. OSVALDO CASTAEDA
HERNANDEZ V2.0
APROB:
COMISION NACIONAL ACADMICA
DE TIC
REVIS: UNIVERSIDAD(ES) TECNOLGICA(S)

REVISORES:
FECHA DE ENTRADA EN VIGOR:
CALIDAD EN EL DESARROLLO DE SOFTWARE

TECNOLOGAS DE LA INFORMACIN Y COMUNICACIN
INTRODUCCIN ..............................................................................................................................................4
UNIDAD TEMTICA I INTRODUCCIN A LA CALIDAD DE SOFTWARE. ...............................................................................5
CONTROL DE CALIDAD ..........................................................................................................................................6
GESTIN DE LA CALIDAD TOTAL ..............................................................................................................................6
ASEGURAMIENTO DE LA CALIDAD ............................................................................................................................7
GENERALIDADES DE LA CALIDAD ....................................................................................................................9
INSTITUTOS QUE REGULAN LA CALIDAD .......................................................................................................11
CONCEPTOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE ........................................................................12
EVALUACIN DEL PRODUCTO SOFTWARE: ISO 14598 ...................................................................................13
ALCANCE DE LA NORMA ISO 14598 ...................................................................................................................14
I. ISO/IEC 14598 - PARTE 1: VISIN GENERAL .....................................................................................................14
II. ISO/IEC 14598 - PARTE 2: PLANIFICACIN Y GESTIN ........................................................................................15
III. ISO/IEC 14598 - PARTE 3: EL PROCESO PARA DESARROLLADORES .......................................................................15
IV. ISO/IEC 14598 - PARTE 4: EL PROCESO PARA COMPRADORES.............................................................................16
V. ISO/IEC 14598 - PARTE 5: EL PROCESO PARA EVALUADORES ...............................................................................17
VI. ISO/IEC 14598 - PARTE 6: DOCUMENTACIN DE LOS MDULOS DE EVALUACIN ...................................................18
UNIDAD TEMTICA MTRICAS DE SOFTWARE.........................................................................................................21
2.1 CONCEPTO DE MTRICA ..............................................................................................................................22
TIPOS DE MTRICAS DE CALIDAD DE SOFTWARE .......................................................................................................22
2.- MTRICAS ORIENTADAS A LA FUNCIN ..............................................................................................................27
ESTIMACIN.................................................................................................................................................29
PLANEACIN DEL PROYECTO ........................................................................................................................29
ERRORES CLASICOS EN UN PROYECTO DE SOFTWARE ...................................................................................32
UNIDAD TEMTICA III PROCESO PERSONAL DE DESARROLLO DE SOFTWARE ..................................................................33
ELEMENTOS DEL PROCESO PERSONAL DE SOFTWARE (PSP) ........................................................................................34
QU ES EL PSP?..............................................................................................................................................34
PRINCIPIOS PSP ...............................................................................................................................................34
ESTRUCTURA DEL PSP ........................................................................................................................................34
PSP O. PROCESO (PUNTO DE PARTIDA)..................................................................................................................36
PSP 2. CALIDAD PERSONAL ...........................................................................................................................37
3.2 PLANTILLAS PSP .......................................................................................................................................38
LOGS DE REGISTRO DE TIEMPO .............................................................................................................................40

METRICAS DEL PSP .......................................................................................................................................42

RESUMEN DEL REGISTRO DE MTRICAS...................................................................................................................43
4.1 PUNTOS DE FUNCIN ..................................................................................................................................45
CARACTERSTICAS DE LA FUNCIONALIDAD ..........................................................................................................46
4.2 PUNTOS DE CASOS DE USO ..........................................................................................................................51
1. FACTOR DE PESO DE LOS ACTORES SIN AJUSTAR (UAW) .........................................................................................52
2. FACTOR DE PESO DE LOS CASOS DE USO SIN AJUSTAR (UUCW)................................................................................52
TABLA 3: PESO DE LAS CLASES DE ANLISIS..............................................................................................................53
FACTORES DE COMPLEJIDAD TCNICA .....................................................................................................................53
FACTORES AMBIENTALES .....................................................................................................................................54
4. ESFUERZO HORAS-HOMBRE (E) ........................................................................................................................54
5.1 MOPROSOFT .........................................................................................................................................57
MODELO MOPROSOFT ...................................................................................................................................57
GESTIN DE NEGOCIO (DIR) ...............................................................................................................................58
GESTIN DE PROCESOS (GES) .............................................................................................................................60
GESTIN DE RECURSOS (GES) .............................................................................................................................62
ADMINISTRACIN DE PROYECTOS ESPECFICOS (OPE) ................................................................................................63
DESARROLLO Y MANTENIMIENTO DE SOFTWARE (OPE) .............................................................................................64
5.2 CMMI....................................................................................................................................................65
5.2.1 LOS CINCO NIVELES DE MADUREZ EN LOS PROCESOS DE CREACIN DEL SOFTWARE ...............................................66
5.2.2 CARACTERSTICAS COMUNES: ......................................................................................................................69
MODELO DE DESARROLLO DE SOFTWARE ...............................................................................................................70
GLOSARIO DE TRMINOS .....................................................................................................................................72

INTRODUCCIN
El siguiente documento integra informacin acerca temas relacionados con la asignatura Calidad en el Desarrollo de
Software. El objetivo principal del documento es brindar al alumno informacin que le permita al alumno
identificar, analizar, disear y valorar distintos problemas relacionados a la gestin de trabajos de software a travs
de diversos problemas o planteamientos de realizacin (individual o grupal).Adems de propiciar la realizacin de
trabajos futuros aplicados a su entorno, permitindoles solucionar problemas en funcin de los conocimientos
adquiridos de automatizacin de sistemas. Adems de motivar en l, el autoestudio, la investigacin y la auto
prctica.
Con la finalidad de que el alumno pueda aplicar algunos de los conocimientos adquiridos durante el desarrollo de la
asignatura, en este manual se integran prcticas (casos) que le permitirn comprender conceptos y procesos de
realizacin de un sistema bajo cierta normatividad de gestin (reglas o normas).
DESARROLLO
El manual est compuesto por 5 unidades temticas:
I.
II.
III.
IV.
V.
Introduccin a la Calidad en el Desarrollo de Software.

Mtricas de Software
Proceso Personal de Desarrollo de Software
Tcnicas de Estimacin
Modelos para el Aseguramiento de la Calidad de Software
Cada uno de estas unidades cuenta con informacin que sustenta cada uno de los temas contenido en la unidad.
Esta informacin en su mayora ha sido colectada de libros, sitios de internet, para brindar al alumno informacin
seria y de calidad. Se integran prcticas a los temas para fortalecer el aprendizaje significativo del alumno.

Unidad Temtica I Introduccin a la Calidad de Software.

Objetivo:El alumno identificar los conceptos generales de calidad y los especficos en el rea de desarrollo de
software, para reconocer la importancia del aseguramiento de la calidad.
Temas
Saber
Saber hacer
Ser
Generalidades de la Identificar
conceptos
de
Calidad
calidad, normas, estndares,
procesos, modelos e institutos
que regulan la calidad.
Proactivo
Organizado
Autodidacta
Sistemtico
Conceptos de Calidad Identificar los factores y Determinar la calidad de un

en el Desarrollo de caractersticas que determinan proyecto de software con
Software
la calidad del software, como: base en los factores y
caractersticas
que
lo
- Funcionalidad
definan.
- Correccin
- Confiabilidad
- Eficiencia
- Usabilidad
- Mantenibilidad
- Portabilidad
- Robustez
- Compatibilidad
- Oportunidad
Proactivo
Organizado
Autodidacta
Analtico
Sistemtico
Resultado de aprendizaje:
El participante podr elaborar un cuadro sinptico, un ensayo de los conceptos de calidad enfocada hacia
el desarrollo de software involucrando cada una de los factores que conformen su gestin.

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.
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
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.
Est relacionada con las percepciones del cliente, que en gran medida son subjetivas.
Es un concepto dinmico, ya que es preciso adaptarse constantemente a las cambiantes necesidades de los
clientes.
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.
Los objetivos que se persiguen con las polticas de gestin de la calidad son:
Satisfaccin del cliente. Constituye el objetivo prioritario.

Conseguir hacer las cosas bien a la primera.

Eliminar todo aquello que no aada valor. Evitar despilfarros.
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.
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.
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:
Alcanzar y mantener la calidad del producto o servicio para satisfacer al cliente.
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.
Pasos fundamentales en el aseguramiento de la calidad:
Establecer un sistema y evaluar su adecuacin. De esta manera se obtiene el Manual de Calidad.
Auditar el sistema para verificar que las disposiciones se estn implementando.
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:
Sigue sin desarrollarse una actividad de mejora. Dado que existen unos procedimientos claramente definidos,
cualquier cambio supone un riesgo.
El tener unos procedimientos formales tan definidos limita de manera considerable la creatividad del personal.
Se da por sentado que el cliente se siente satisfecho por recibir su pedido de acuerdo a lo que especific, cuando
realmente l 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
Concepto de calidad
Orientacin de
la
empresa
Responsabilidad de la
calidad
Se acta porque...
Conformidad con las

especificaciones
Produccin
Depto. de calidad
Se detecta un error
Aplicacin de la calidad
Al producto
Actuacin
Corregir el error
Actitud
Reactiva
Participacin
del
personal
Importancia
de
la
participacin
Generacin de valor
aadido
Materializacin
Slo Depto. de calidad
Filosofa
Aseguramiento de la
calidad
Aptitud para el uso
GCT
Produccin
Cliente
Depto. de calidad +
operarios
Se intenta evitar el
error
Al proceso productivo
Todos los miembros
Modificar
procedimiento
Reactiva
el
Satisfaccin del cliente
Hay objetivos
A todos los procesos de
la empresa
Mejora continua
Proactiva
Depto. de calidad +
operarios
Importante
Toda la empresa
Si
Si
Plan de inspeccin
Manual de calidad
Sistema de gestin
Arreglo
Prevencin
Mejora
No
se
participacin
No est claro
espera
Imprescindible
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).
Se conoce como software al equipamiento lgico o soporte lgico de una computadora digital; comprende el
conjunto de los componentes lgicos necesarios que hacen posible la realizacin de tareas especficas, en
contraposicin a los componentes fsicos del sistema, llamados hardware.

Los componentes lgicos incluyen, entre muchos otros, aplicaciones informticas; tales como el procesador de
textos, que permite al usuario realizar todas las tareas concernientes a la edicin de textos; o el software de
sistema, tal como el sistema operativo, que, bsicamente, permite al resto de los programas funcionar
adecuadamente, facilitando la interaccin con los componentes fsicos y con el resto de las aplicaciones,
proporcionando tambin una interfaz para el usuario.
GENERALIDADES DE LA CALIDAD
Algunos DEFINICIONES que nos dan una idea de la aplicacin de CALIDAD se dan a continuacin:
Calidad.- Es asegurarse de que un producto o servicio sea consistente (no variable), confiable (que haga las
cosas de forma fiable todo el tiempo) y est libre de errores y defectos.
Calidad de diseo.- Caractersticas que especifican los ingenieros de Software para el elemento. El grado
de materiales, tolerancia, y las especificaciones del rendimiento.
Calidad de concordancia.- Es el grado de cumplimiento de las especificaciones del diseo durante su
realizacin
Control de calidad.- Serie de inspecciones revisiones y pruebas utilizados a lo largo del proceso de
Software para asegurarse de que cumple con los requisitos que le han sido asignados.
Garanta de calidad.- Consiste en una auditoria cuyo objetivo es proporcionar la gestin para informar de
los datos necesarios sobre la calidad del producto.
Calidad de Software.- Existe una constante preocupacin de los investigadores tecnolgicos en lo
referente a la calidad de sus productos. Es necesario que cuenten con lineamientos y herramientas de
apoyo necesarios para disminuir este problema y as poder liberar sus trabajos sin ninguna preocupacin.
Por qu es necesaria la calidad? Porque la competencia es cada mayor, por eso necesario que las
empresas se preocupen por dar un mejor producto, pero la calidad de un producto no solo se mide al
terminarlo. Hoy en da las necesidades de buscar una solucin a problemas complejos en el software ha
ocasionado que las empresas dedicadas al desarrollo o mantenimiento de software sean rebasadas, es
decir que no sean capaces de desarrollar o entregar un software confiable, a tiempo y apegado al
presupuesto acordado con el cliente y de que el cliente confi que todo lo anterior se cumplir. Por esto
las organizaciones deben buscar una norma, estndar o modelo que pueda ayudarlas a ser competitivas o
llegar a la calidad.
1. Normas.- Las normas son un modelo, un patrn, ejemplo o criterio a seguir. Una norma es una frmula que tiene
valor de regla y tiene por finalidad definir las caractersticas que debe poseer un objeto y los productos que han de
tener una compatibilidad para ser usados a nivel internacional. Por ejemplo, el problema que ocasiona a muchos
usuarios los distintos modelos de enchufes que existen a escala internacional para poder acoplar pequeas
mquinas de uso personal: secadores de cabello, mquinas de afeitar, etc. cuando se viaja. La incompatibilidad
repercute en muchos campos. La normalizacin de los productos es, pues, importante.
2. Estndares.- El significado primario moderno que le sigui fue "lo que es establecido por la autoridad, la
costumbre o el consentimiento general". En este sentido se utiliza como sinnimo de norma. Son normas y
protocolos internacionales que deben cumplir productos de cualquier ndole para su distribucin y consumo por el
cliente final.

Beneficios de los Estndares

Buenas prcticas de diseo.
Prcticas que han funcionado tanto para el desarrollador como para el usuario.
Mejoras del proceso de diseo.
Reduccin del proceso de diseo mediante prueba y error.
Utilizacin de los Estndares

Elegir qu estndar se va a seguir o a utilizar.
Planificar un proceso de desarrollo adaptando los diferentes estndares elegidos.
Aplicar las recomendaciones de los estndares.
Revisar el proceso de desarrollo para observar si cumple los estndares adaptados.
Refinar la adaptacin de los estndares:
Si no se cumplen las recomendaciones del estndar
Si el refinamiento del estndar elegido no es suficiente para desarrolladores y diseadores
Si no se ha creado una versin del estndar adaptada al proyecto en desarrollo.
3. Procesos.- Conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa
o simultneamente) con un fin determinado. Este trmino tiene significados diferentes segn la rama de la ciencia o
la tcnica en que se utilice.
En la siguiente tabla se presenta algunos MODELOS QUE REGULAN LA CALIDAD
10

Caracterstica
PSP
Inspecciones
CMM
Propsito
Gerenciamiento
y
mejora de la calidad
Prescriptiva
Exacta
Desarrolladores
y
gerentes
Ciclo de vida del
desarrollo
Muy bajo
Muy alta
Semanas
Integral
Muy Alto
Mejora de la calidad
Mejora
gerenciamiento
Descriptiva
Vaga
Gerentes
del
Gerenciamiento de
la calidad
Descriptiva
Vaga
Gerentes
Gerenciamiento
proyectos
Alto
Baja
Aos
Ambiguo
Bajo
de
Aseguramiento de
la Calidad
Alto
Baja
Aos
Ambiguo
Bajo
Metodologa
Definicin
Audiencia
Cobertura
Costo
Calidad
Implementacin
Alcance
Cuan
Mensurable es
Presciptiva
Exacta
Desarrolladores
Verificacin
validacin
Bajo
Alta
Das
Estrecho
Alto
ISO 9000
INSTITUTOS QUE REGULAN LA CALIDAD

La Organizacin Internacional para la Estandarizacin o ISO (del griego, (isos), 'igual'), nacida tras la Segunda
Guerra Mundial (23 de febrero de 1947), es el organismo encargado de promover el desarrollo de normas
internacionales de fabricacin, comercio y comunicacin para todas las ramas industriales a excepcin de la
elctrica y la electrnica. Su funcin principal es la de buscar la estandarizacin de normas de productos y seguridad
para las empresas u organizaciones a nivel internacional.
La ISO es una red de los institutos de normas nacionales de 163 pases, sobre la base de un miembro por pas, con
una Secretara Central en Ginebra (Suiza) que coordina el sistema. La Organizacin Internacional de Normalizacin
(ISO), con sede en Ginebra, est compuesta por delegaciones gubernamentales y no gubernamentales subdivididos
en una serie de subcomits encargados de desarrollar las guas que contribuirn al mejoramiento ambiental.
Las normas desarrolladas por ISO son voluntarias, comprendiendo que ISO es un organismo no gubernamental y no
depende de ningn otro organismo internacional, por lo tanto, no tiene autoridad para imponer sus normas a
ningn pas. Est compuesta por representantes de los organismos de normalizacin (ON) nacionales, que produce
normas internacionales industriales y comerciales. Dichas normas se conocen como normas ISO y su finalidad es la
coordinacin de las normas nacionales, en consonancia con el Acta Final de la Organizacin Mundial del Comercio,
con el propsito de facilitar el comercio, el intercambio de informacin y contribuir con normas comunes al
desarrollo y a la transferencia de tecnologas.
De forma concreta, algunas Instituciones para el desarrollo de estndares son:
Internacionales
ISO (http://www.iso.org)
IEC International Electrotechnical Commision (http://www.iec.ch)
Otros
ANSI (http://www.ansi.org) - USA
HFES (http://www.hfes.org) - USA
UNI (http://www.unicei.it/uni) - Italia
11

CONCEPTOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE

Mantener un proceso de desarrollo controlado es la clave para generar un producto de software de calidad. En
adicin a los costos de la falta de calidad y lo beneficios de tenerla.
Cuando se habla de calidad, se refiere a los atributos mensurables de un producto.
En el caso del software lo que se pretende es controlar la variacin del proceso que se aplica para el desarrollo del
mismo, los recursos que consumimos y los atributos de calidad del producto final. Para ello nos basamos en tres
ejes:
1.
2.
3.
Concordancia con los requerimientos.

Cumplir con estndares especificados.
Requisitos implcitos.
Costos de la calidad:
Prevencin de futuros problemas.
Planificar.
Revisiones.
Capacitacin.
Recursos Humanos.
Costos de la no calidad:
Costos de correccin de errores.
Resolucin de quejas.
Devolucin.
Imagen.
Soporte.
Algunos FACTORES y/o caractersticas que determinan la calidad del software son:
1.
2.
3.
4.
5.
6.
7.
8.
FUNCIONALIDAD.- (Puedo probarlo?). El esfuerzo requerido para probar un programa con el fin de
asegurar que realiza su funcin requerida.
CORRECCIN.- (Hace lo que quiero?). El grado en que un programa satisface sus especificaciones y
consigue los objetivos de la misin encomendada por el cliente.
CONFIABILIDAD.- (Lo hace de forma fiable todo el tiempo?). El grado en que un programa lleva a cabo sus
funciones esperadas con la precisin requerida.
EFICIENCIA.- (Se ejecutar en mi hardware lo mejor que pueda?). La cantidad de recursos de
computadora y de cdigo requeridos por un programa para llevar a cabo sus funciones.
USABILIDAD.- (Podr reusar alguna parte del software?). El grado en que un programa (o parte de un
programa) se puede reusar en otras aplicaciones. Esto va relacionado con el empaquetamiento y el alcance
de las funciones que realiza el programa.
MANTENIBILIDAD.- (Puedo corregirlo?). El esfuerzo requerido para localizar y arreglar un error en un
programa.
PORTABILIDAD.- (Podr usarlo en otra mquina?). El esfuerzo requerido para transferir el programa
desde un hardware y/o entorno de sistemas de software a otro).
ROBUSTEZ.- (Es muy grande el programa?). Tamao del programa.
12

9.
COMPATIBILIDAD.- (Podr hacerlo interactuar con otro sistema?). El esfuerzo requerido para acoplar un
sistema a otro.
Estos factores con los que cuenta la calidad en el desarrollo de software se encuentran dispersos en muchas normas
y estndares, segn sea la especialidad aplicada al software. A continuacin se trata una NORMA conocida como:
EVALUACIN DEL PRODUCTO SOFTWARE: ISO 14598

Introduccin
Muchas empresas de desarrollo de software han reconocido la necesidad de mejorar el producto software. La
evaluacin independiente del producto software viene a ser insuficiente porque su calidad depende en gran medida
del proceso empleado para su desarrollo. De esta manera, dichas empresas buscan la evaluacin de sus procesos y
productos de software. El estndar ISO/IEC 14598 es actualmente usado como base metodolgica para la
evaluacin del producto software. Este artculo presenta una exploracin sobre el mismo.
Los productos de software son solo una parte de la historia. Tambin es necesario considerar mediciones en el
proceso empleado para disear, desarrollar, probar y controlar el producto. En esto juega un papel relevante la
ISO/IEC 14598. La ISO/IEC 14598 ofrece una visin general, explica la relacin entre su serie y el modelo de calidad
de la ISO/IEC 9126, define los trminos tcnicos utilizados, contiene requisitos generales para la especificacin y
evaluacin de la calidad del software, y clarifica los conceptos generales. Adems, provee un marco de trabajo para
evaluar la calidad de todos los tipos de productos de software y establece requisitos para mtodos de medicin y
evaluacin de los productos de software.
Figura. La ISO/IEC 14598 y el proceso para evaluar software (D. A. R.)

Es importante sealar que, la serie de normas ISO/IEC 14598 proporciona un marco de trabajo para evaluar la
calidad de todos los tipos de productos de software e indica los requisitos para los mtodos de medicin y para el
proceso de evaluacin. Se ver enseguida que la ISO/IEC 14598 consta de seis partes que describen los requisitos
del proceso de evaluacin en tres situaciones diferentes:
Requisitos para desarrolladores (parte 3).

Requisitos para compradores (parte 4).
13

Requisitos para evaluadores (parte 5).
La ISO/IEC 14598-1 est prevista para que se use conjuntamente con la ISO/IEC 9126-1.
Audiencia destino para la NORMA ISO 14598

Proveedores de productos de software.
Compradores de productos de software.
Organizaciones encargadas de las evaluaciones del producto de software.
Usuarios del producto y gente que hace su mantenimiento.
Alcance de la NORMA ISO 14598

El propsito de la evaluacin de la calidad del software es hacer que tanto el desarrollo y la adquisicin del software
cumplan las expectativas y necesidades del usuario. Esta norma 14598 define el proceso de evaluacin y provee los
requerimientos y las guas que conducen a evaluaciones de calidad, a travs de las siguientes 6 partes:
I. ISO/IEC 14598 - Parte 1: Visin General

Bsicamente, provee una visin general de las otras cinco partes y explica la relacin entre la evaluacin del
producto software y el modelo de calidad definido en la ISO/IEC 9126. Adicionalmente, hace la presentacin del
proceso de evaluacin desglosado en los siguientes pasos:
1.
2.
3.
4.
5.
Establecer los requerimientos de evaluacin.

Especificar la evaluacin.
Planear la evaluacin.
Ejecutar la evaluacin.
Vase la ilustracin de a continuacin
14

Figura ISO/IEC 14598 - Parte 1: Visin General (D. A. R.)
II. ISO/IEC 14598 - Parte 2: Planificacin y Gestin

Esta parte contiene los requerimientos y las guas para las funciones de soporte tales como el planeamiento y
gestin para la evaluacin del producto del software. Fundamentalmente, en esta parte, se planifican las
mediciones y las actividades de evaluacin. Especficamente, se incluye:
Preparacin de las polticas.

Definicin de objetivos organizacionales y de mejora.
Identificacin de la tecnologa.
Asignacin de responsabilidades.
Identificacin e implementacin de tcnicas de evaluacin para software desarrollado y adquirido.
Entrenamiento en tecnologa, recopilacin de datos y herramientas.
Comparacin y administracin de mejoras dentro la organizacin.
III. ISO/IEC 14598 - Parte 3: El Proceso para Desarrolladores

Esta parte provee los requerimientos y las recomendaciones para la evaluacin del producto software cuando la
evaluacin es conducida en paralelo con el desarrollo y llevada a cabo por el desarrollador. Se enfoca en el uso de
indicadores que pueden predecir la calidad final del producto midiendo los productos intermedios que se
15

desarrollan durante el ciclo de vida. Esta parte cubre el planeamiento y evaluacin de mediciones internas y
externas con el fin de asegurar de que la calidad del producto sea incorporada en la fase de desarrollo.
Entonces, una vez identificadas las caractersticas fundamentales de calidad y el marco de trabajo de mediciones,
deben ser definidas las etapas siguientes:
Organizacin
Los aspectos organizacionales de desarrollo y de soporte deben formar parte de todo el sistema de calidad y del
plan de mediciones. Vase la ISO/IEC 14598 - Parte 2.
Planeamiento del Proyecto y Requerimientos de Calidad
El desarrollo y el ciclo de vida de soporte deben ser establecidos y documentados durante el plan de calidad o en
otros documentos. Es de vital importancia verificar que el productor y las medidas de control requeridas sean
tcnicamente factibles, razonables y alcanzables (dentro de los lmites de tiempo).
Especificaciones
En esta fase, el desarrollador realiza un mapeo de los requerimientos internos y externos de calidad, con relacin a
las especificaciones.
Los requerimientos de mediciones resultantes de esta fase deben ser un tipo de mapeo entre las especificaciones
de requerimientos, requerimientos externos de calidad, requerimientos internos correspondientes de calidad y
atributos especificados junto a sus escalas de medicin y valores objetivos que contribuyan a la cuantificacin de la
calidad del software. Todo esto puede enfocarse por proyecto o por producto.
Diseo y Planeamiento
Los procedimientos requeridos para el anlisis y recopilacin de datos necesitan ser definidos. De esta manera, el
plan incluir: cronogramas, designacin de responsabilidades, uso de herramientas, bases de datos y
entrenamiento especializado requerido. La precisin de las mediciones y tcnicas estadsticas deben ser
especificadas (vase la ISO/IEC 14598 - Parte 6). En esta fase tambin deber considerarse cmo los resultados de
las mediciones impactarn en el desarrollo; por lo tanto, acciones de contingencia y de mejora, deben ser
consideradas.
Montaje (Build) y Pruebas
Durante la etapa de montaje y pruebas, las mediciones actuales son recolectadas, se realizan anlisis apropiados y
se toman acciones necesarias. En cada fase del desarrollo debe procurarse lograr un montaje primeramente
enfocado a las caractersticas internas y externas de calidad que definan la calidad global del producto y que
puedan ser validadas por los resultados de las pruebas y la experiencia del usuario.
Y como etapa final del proyecto, deber ser conducida una revisin general para determinar la efectividad global
del ejercicio de recoleccin, para identificar costos versus costos, establecer la validez de las mtricas usadas e
identificar puntos en los cuales podran obtenerse beneficios para proyectos futuros. El resultado de esta revisin
podra retroalimentar directamente el lanzamiento de futuros productos.
IV. ISO/IEC 14598 - Parte 4: El Proceso para Compradores

Esta parte provee los requerimientos y las recomendaciones para que la evaluacin del producto software sea
conducida en funcin a los compradores que planean adquirir o re-usar un producto de software existente o predesarrollado.
16

Los que adquieren el producto pueden comprar paquetes completos ya sea desarrollados segn ciertas
especificaciones o pre-desarrollados para un mercado ms general. Los compradores tambin podran ser
desarrolladores que desean integrar productos estndar en sus propios diseos de software, o tratarse de
desarrolladores buscando herramientas especficas de software. Al respecto, cuatro etapas son necesarias:
Establecimiento de los Requerimientos
El alcance de la evaluacin necesita ser establecido. Los requerimientos para la calidad del software definidos en la
ISO/IEC 9126 pueden ser usados como punto de partida pero otros aspectos como el costo y el de cumplimiento a
regulaciones debern ser tambin considerados. El tiempo de la evaluacin necesita ser consistente con los
objetivos; enfoques muy tempranos podran no proporcionar una figura adecuada de la situacin mientras que
enfoques muy tardos podran ser muy limitados en su uso.
Especificacin de la Evaluacin
Durante la redaccin de las especificaciones, debe considerarse:
Los requerimientos de calidad a ser evaluados correlacionados con la calidad en uso y

Mtricas externas con prioridades adems de un umbral de aceptacin definido.
El alcance y lo que cubren los casos de prueba donde sean aplicables referencias a mdulos
de evaluacin.
Mtodos de recoleccin de mediciones, informacin requerida y mtodos de anlisis.
Diseo de la Evaluacin
El tipo de evaluacin depende del tipo de software que est siendo evaluado. Software bajo desarrollo
puede ser abordado en puntos discretos durante el desarrollo o cuando est completo. Un plan de
evaluacin necesita considerar:
Necesidades de acceso a la documentacin del producto, herramientas de desarrollo y personal.

Requerimientos en costos y conocimientos.
Cronograma de evaluacin y arreglos de contingencia, hitos claves y criterio para decisiones de evaluacin.
Mtodos y herramientas de reporte, procedimientos para la validacin y estandarizacin sobre proyectos futuros.
Ejecucin de la Evaluacin
Aunque esta etapa podra ser simplemente un registro en un libro de seguimiento, podra tenerse la necesidad de
incluir:
Los resultados mismos y la trazabilidad del producto as como informacin de configuracin.
Registros de anlisis, resultados y decisiones.
Problemas, limitaciones en las mediciones y cualquier compromiso con relacin a los objetivos
originales
Conclusiones sobre los resultados de la evaluacin pero tambin sobre los mtodos
empleados.
V. ISO/IEC 14598 - Parte 5: El Proceso para Evaluadores

Esta parte provee los requerimientos y recomendaciones para la evaluacin del producto software cuando la
evaluacin es conducida por evaluadores independientes. En esta parte, tienen un rol importante los
requerimientos de evaluacin, las especificaciones de evaluacin, el diseo de la evaluacin, las actividades de
evaluacin y el reporte de evaluacin. Estas etapas son resumidas a continuacin:
17

Requerimientos de Evaluacin
Los requerimientos deberan adicionalmente definir:
1.
2.
3.
4.
La extensin del la cobertura (o el alcance).

Los objetivos de evaluacin y mtodos de reporte.
Las calificaciones e independencia requeridas de un evaluador.
Especificacin de la Evaluacin
Las especificaciones adicionalmente deberan cubrir:
Definicin del alcance y formato en las mtricas empleadas identificando como debern ser derivadas a
partir de los requerimientos del producto.
La identificacin de mediciones no determinsticas para asegurar que ciertos niveles de Frecuentabilidad y
objetividad requeridos sean obtenidos.
La identificacin de mtodos de correlacin con relacin a los resultados de las mediciones.
Se tienen identificadas tres sub-actividades con relacin a la especificacin de la evaluacin:
El anlisis de la descripcin del producto.
La especificacin de las mediciones a ser realizadas.
La verificacin de la especificacin resultante frente a los requerimientos de evaluacin.
VI. ISO/IEC 14598 - Parte 6: Documentacin de los Mdulos de Evaluacin

Esta parte provee las guas para la documentacin del mdulo de evaluacin. Estos mdulos representan la
especificacin del modelo de calidad y las correspondientes mtricas internas y externas que sern aplicadas a una
evaluacin en particular. Incluye mtodos y tcnicas de evaluacin ms las mediciones actuales resultantes de su
aplicacin. En esta parte tambin se considera la administracin efectiva de complejidades inherentes a las
cuestiones de medicin.
Las actividades de medicin coordinadas son una caracterstica para una evaluacin efectiva y un plan necesita
proveer un cronograma de evaluacin que provea al mismo tiempo informacin ptima cuando la evaluacin sea
conducida durante el desarrollo.
Los mdulos de la evaluacin son componentes claves de la ISO/IEC 14598-6 y son usados para proveer un formato
consistente y repetible de reporte. Dichos mdulos proveen:
Visibilidad de la informacin necesitada para cuadrar con requerimientos especficos de calidad.
Documentacin de las interfaces necesarias con herramientas de medicin.
La ISO/IEC 14598-6 trata tambin sobre los requerimientos de la documentacin y divide a los Mdulos de
evaluacin en los seis componentes siguientes:
Introduccin Cubre el control del documento, las relaciones con otros documentos, los Requerimientos tcnicos y
una razn para el mdulo.
Alcance Se relaciona con la caractersticas de calidad o sub-caractersticas que debern ser alcanzadas, el nivel de
la evaluacin (tomando en cuenta la importancia de la caracterstica, la tcnica de evaluacin usada incluyendo
cualquier teora necesaria) y la aplicabilidad del mdulo.
18

Referencias y Definiciones requeridas.

Entradas requeridas Datos a ser recopilados y mtricas a ser calculadas.
Informacin sobre la interpretacin de los resultados.
Resultados de la Evaluacin
En esta etapa se tiene la generacin del reporte de evaluacin incluyendo una revisin independiente de los
resultados de la evaluacin. Normalmente, el reporte final ser precedido por un borrador de tal manera que el
personal involucrado con el producto pueda proveer una retroalimentacin sobre la evaluacin.
Instrucciones
Desarrollar un mapa conceptual, resumen y presentacin del tema: Calidad del Desarrollo del Software
deber incluir todos los conceptos vistos en clase.
Indicador
o
variable
FORMA
Datos generales
Ortografa y
redaccin
Presentacin
Aspectos
generales
CONTENIDO
Presentacin
Desarrollo
Representacin
TOTAL
Descripcin
Cumple
S
No
Porcentaje
Asignatura, Unidad temtica, Nombre de la

actividad, Nombre del alumno(os), matrcula,
nombre del profesor, fecha.
Ortografa sin errores.
Legible
Portada con los datos generales, encabezado y
pie de pgina a partir de la segunda pgina
especificando el nombre de la carrera y nombre
de la actividad.
De igual manera, se le pide que considere la
siguiente forma de entrega:
Elabore el documento en un archivo de Word
estructurado de la siguiente manera:
Portada
Desarrollo
Conclusin
5
10
Presenta todos los conceptos vistos en clase

Organiza su informacin para tener la correcta
relacin de los conceptos
Representa de manera correcta los conceptos
40
20
10
10
100
19

Lista de Cotejo Prctica 1

Indicador
o
Descripcin
variable
ACTITUD (SER)
Puntualidad
Entrega del trabajo tiempo y forma establecida
El alumno participa activamente en su equipo
Trabajo
en
aportando propuestas para la realizacin del
equipo
trabajo.
CONOCIMIENTO (SABER)
Requisitos de Identifica correctamente todos los instrumentos
Informacin
para obtener informacin.
Identific el instrumento ms viable dependiendo
Requisitos de
del problema que se le planteo.
Informacin
Cumple
Si
No
HABILIDAD (SABER HACER)

El instrumento generado tiene el orden
Estructura
coherente para obtener la informacin necesaria
El instrumento generado le permiti obtener toda
Presentacin
la informacin necesaria para establecer sus
requerimientos de informacin
TOTAL
Evaluacin: La ausencia parcial o total de algn inciso tendr una penalizacin acorde a
sealada en cada inciso
Observacin:
Evaluador
(Nombre
Firma)
Porcentaje
5
5
20
20
20
30
100
la puntuacin
20

Unidad Temtica Mtricas de Software.

Objetivo: El alumno identificar el concepto y los tipos de mtricas, para distinguir las que aplican al rea de
desarrollo del software
Temas
Saber
Concepto de mtrica.
Identificar
mtrica.
Saber hacer
el
concepto
de
Tipos de mtricas de Identificar los tipos de Seleccionar las mtricas

calidad de software.
mtricas asociadas a los para asegurar la calidad en
factores y caractersticas que el desarrollo de software
determinan la calidad del en
un
contexto
software.
determinado
Ser
P Autodidacta
Analtico
Habilidad
para
la
comunicacin oral y escrita
Habilidad para el trabajo en
equipo
Proactivo
Organizado
Autodidacta
Analtico
Sistemtico
Habilidad
para
la
comunicacin oral y escrita
Habilidad para el trabajo en
equipo
Elaborar un documento que contenga una tabla en donde relacione lo siguiente:
Factores y caractersticas que determinan la calidad en el desarrollo de software.
Mtricas para cada uno de los factores anteriores.
Explicar la forma en que inciden.
21

2.1
Concepto de Mtrica
Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por
medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus
procesos para aumentar su calidad.
En la mayora de los desafos tcnicos, las mtricas nos ayudan a entender tanto el proceso tcnico que se utiliza
para desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo, el producto se mide
para intentar aumentar su calidad.
Razones para medir un producto:
1. Indicar la calidad del producto.
2. Evaluar la productividad de la gente que desarrolla el producto.
3. Evaluar los beneficios en trminos de productividad y de calidad, derivados del uso de nuevos mtodos y
herramientas de la ingeniera de software.
4. Establecer una lnea de base para la estimacin
5. Ayudar a justificar el uso de nuevas herramientas o de formacin adicional.
Tipos de Mtricas de Calidad de Software

Las mediciones del mundo fsico pueden englobarse en dos categoras: medidas directas y medidas indirectas:
Medidas Directas. En el proceso de ingeniera se encuentran el costo, y el esfuerzo aplicado, las lneas de
cdigo producidas, velocidad de ejecucin, el tamao de memoria y los defectos observados en un
determinado periodo de tiempo.
Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de
mantenimiento, etc.
LAS MTRICAS DEL SOFTWARE son las que estn relacionadas con el desarrollo del software como
funcionalidad, complejidad, eficiencia, y se explican a continuacin:
MTRICAS TCNICAS: Se centran en las caractersticas de software por ejemplo: la complejidad lgica, el
grado de modularidad. Mide la estructura del sistema, el cmo est hecho.
MTRICAS DE CALIDAD: proporcionan una indicacin de cmo se ajusta el software a los requisitos
implcitos y explcitos del cliente. Es decir cmo voy a medir para que mi sistema se adapte a los requisitos
que me pide el cliente.
MTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniera del software. Es
decir que tan productivo va a ser el software que voy a disear.
MTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e informacin sobre la forma que la gente
desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las
herramientas y mtodos. Son las medidas que voy a hacer de mi personal que va har el sistema.
MTRICAS ORIENTADAS AL TAMAO. Es para saber en qu tiempo voy a terminar el software y cuantas
personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una
organizacin de software mantiene registros sencillos, se puede crear una tabla de datos orientados al
tamao como se muestra en la siguiente figura:
22

La tabla lista cada proyecto del desarrollo del software de los ltimos aos correspondientes, datos orientados al
tamao de c/u. Refirindonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12.1 KLDC (miles de
lneas de cdigo) con un esfuerzo de 24 personas mes y un costo de 168 mil dlares. Debe tenerse en cuenta que el
esfuerzo y el costo registrados en la tabla incluyen todas las actividades de la ingeniera de software como son
anlisis, diseo, codificacin y prueba. Otra informacin del proyecto 222-01 indica que se desarrollaron 365
pginas mientras que se encontraron 29 errores tras entregrselo al cliente, dentro del primer ao de utilizacin
tambin sabemos que trabajaron 3 personas en el desarrollo del proyecto.
En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puede desarrollar, para cada
proyecto un conjunto de mtricas sencillas de productividad y calidad orientadas al tamao. Se obtienen las
siguientes formulas:
Productividad = KLDC/persona-mes
Calidad = errores/KLDC
Documentacin = pags. Doc/ KLDC
Costo = $/KLDC
NOTA.- persona-mes es el esfuerzo
MTRICAS ORIENTADAS A LA FUNCIN. Son medidas indirectas del software y del proceso por el cual se desarrolla.
En lugar de calcularlas las LDC, las mtricas orientadas a la funcin se centran en la funcionalidad o utilidad del
programa.
Las mtricas orientadas a la funcin fueron el principio propuestas por Albercht quien sugiri un acercamiento a la
medida de la productividad denominado mtodo del punto de funcin. Los puntos de funcin que obtienen
utilizando una funcin emprica basando en medidas cuantitativas del dominio de informacin del software y
valoraciones subjetivos de la complejidad del software.
Los puntos de funcin se calculan rellenando la tabla como se muestra en la siguiente figura:
Calculo de mtricas de punto de funcin
23

Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la posicin apropiada de la
tabla. Los valores del mbito de informacin estn definidos de la siguiente manera.
1. Nmeros de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes
datos orientados a la aplicacin. Las entradas deben ser distinguidas de las peticiones que se contabilizan por
separado.
2. Nmero de salida del usuario: se encuentra cada salida que proporciona al usuario informacin orientada a la
aplicacin. En este contexto las salidas se refieren a informes, pantalla, mensajes de error. Los elementos de
datos individuales dentro de un informe se encuentran por separado.
3. Nmeros de peticiones al usuario: una peticin est definida como una entrada interactiva que resulta de la
generacin de algn tipo de respuesta en forma de salida interactiva. Se cuenta cada peticin por separado.
4. Nmero de archivos: se cuenta cada archivo maestro lgico, o sea una agrupacin lgica de datos que puede
ser una parte en una gran base de datos o un archivo independiente.
5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos
de datos, en cinta o discos que son utilizados para transmitir informacin a otro sistema.
Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. Las
organizaciones que utilizan mtodos de puntos de funcin desarrollan criterios para determinar si una entrada es
denominada simple, media o compleja. No obstante la determinacin de la complejidad es algo subjetivo.
Para calcular los puntos de funcin se utiliza la siguiente relacin:
PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]
Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior.
Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las respuestas a las
cuestiones sealadas de la siguiente tabla.
Evaluar cada factor en escala 0 a 5.
24

Los valores constantes de la ecuacin anterior y los factores de peso aplicados en las encuestas de los mbitos de
informacin han sido determinados empricamente.
Una vez calculado los puntos de funcin se usan de forma analgica a las LDC como medida de la productividad,
calidad y otros productos del software.
Productividad = PF / persona-mes
Calidad = Errores / PF
Costo = Dlares / PF
Documentacin = Pags. Doc / PF
La medida de puntos de funcin se diseo originalmente para ser utilizadas en aplicacin de sistemas de
informacin de gestin. Sin embargo, algunas aplicaciones se les denomina puntos de caractersticas.
La medida del punto de caracterstica da cabida a aplicaciones cuya complejidad algortmica es alta. Las aplicaciones
de software de tiempo real de control de procesos y de sistemas que encontrados tienden a tener una complejidad
algortmica alta y por tanto fcilmente tratables por puntos de caractersticas.
25

Para calcular los puntos de caractersticas, nuevamente se cuentan y ponderan los valores del mbito de
informacin, como se describi anteriormente. Adems, las mtricas de punto de caracterstica tienen en cuenta
otra caracterstica del software, los algoritmos.
Un algoritmo se define como un problema de complejidad computacional limitada que se incluye dentro de un
determinado programa de computadora. La inversin de una matriz, la decodificacin de una cadena de bits o el
manejo de una interrupcin son todo ellos ejemplos de algoritmos.
Para calcular los puntos de caracterstica, se utiliza la siguiente tabla.
Se usa un nico valor de peso para cada uno de los parmetros de medida y se calcula el valor del punto
caracterstica global mediante la ecuacin.
PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]
Debe tenerse en cuenta que los puntos de caracterstica y los puntos de funcin representan lo mismo.
"funcionalidad o utilidad" en forma de software.
EJERCICIOS
1.- Mtricas orientadas al tamao
26

Calcular:
a) Productividad = KLDC/esfuerzo
_ Hopital = ?
_ farmacia = ?
b) Calidad = Errores/KLDC
_ Hospital = ?
_ Farmacia = ?
c) Costo = $/KLDC
_ Hospital = ?
_ Farmacia = ?
d) Documentacin = Pags. doc/KLDC
_ Hospital=?
_ Farmacia=?
2.- Mtricas orientadas a la funcin

Se tiene un sistema el cual cuenta con 3 entradas de catlogo productos, proveedores y clientes. Una pantalla de la
elaboracin de facturas, 4 tipos de reportes proporcionados tanto en pantalla como en papel. Estas
representaciones son: factura, lista de inventario, estado de cuenta de los clientes y estado de cuenta con los
proveedores. Adems la entrada de factura tiene alrededor de 30 peticiones, el sistema genera alrededor de 30
archivos adems de estar conectado a un lector ptico y una impresora. Calcula los puntos de funcin.
27

Contestacin de las preguntas basada en la complejidad media:

1=0; 2=5; 3=3; 4=5; 5=5;
6=5; 7=1; 8=5; 9=2; 10=2;
11=4; 12=0; 13=0; 14=4
Fi =?
PF = ?
Productividad = ?
Calidad = ?
Costo = ?
Documentacin = ?
Nombre de la Prctica:
Elaboracin de Formatos para Mtricas
Unidad Temtica:
I. Mtricas de software
Tema:
Mtricas de Software
Objetivo de la prctica:
El alumno, realizar diversos tipos de formatos con los cuales podr

hacer una estimacin de la mtrica de los software desarrollados o a
desarrollar para poder dar una estimacin de tiempo y dinero para la
gestin de este..
3 Hrs
Fecha:
Tiempo de la Prctica:
Descripcin:
El alumno deber disear y construir un instrumento que permita medir la cantidad de cdigo de cada
uno de los procesos involucrados en el diseo y/o desarrollo de un sistema.
Antecedentes
En base a los diagramas mostrados anteriormente, disear un instrumento en el cual pueda englobar o
presentar todas y cada una de las caractersticas que este lleva.
Entregue una impresin de su formato con la descripcin de cada uno de los campos que conforman a
su formato asi como presentar un ejemplo del llenado del mismo.
Materiales y Equipos:
Computadora
28

Procedimiento:
Organizarse en equipos de 3 personas, mximo 5
Analice y determine los requerimientos de informacin necesarios para la conformacin del nuevo
formato para determina la mtrica de un sistema.
Cuestionario
Referencias
ESTIMACIN
Es una pequea planeacin sobre qu es lo que va a ser mi proyecto. Una de las actividades cruciales del proceso de
gestin del proyecto del software es la planificacin. Cuando se planifica un proyecto de software se tiene que
obtener estimaciones de esfuerzo humano requerido, de la duracin cronolgica del esfuerzo humano requerido,
de la duracin cronolgica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen
valindose de la experiencia pasada como nica gua. Si un proyecto es bastante similar en tamao y funciona un
proyecto es bastante similar en tamao y funciona un proyecto pasado es probable que el nuevo proyecto requiera
aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior.
Pero qu pasa si el proyecto es totalmente distinto entonces puede que la experiencia obtenida no sea lo
suficiente.
Se han desarrollado varias tcnicas de estimacin para el desarrollo de software, aunque cada una tiene sus puntos
fuertes y sus puntos dbiles, todas tienen en comn los siguientes atributos.
1. Se han de establecer de antemano el mbito del proyecto.
2. Como bases para la realizacin de estimaciones se usan mtricas del software de proyectos pasados.
3. El proyecto se desglosa en partes ms pequeas que se estiman individualmente.
PLANEACIN DEL PROYECTO

La planeacin efectiva de un proyecto de software depende de la planeacin detallada de su avance, anticipado
problemas que puedan surgir y preparando con anticipacin soluciones tentativas a ellos. Se supondr que el
administrador del proyecto es responsable de la planeacin desde la definicin de requisitos hasta la entrega del
sistema terminado. No se analizara la planeacin que implica a la estimacin de la necesidad de un sistema de
software y la habilidad de producir tal sistema, la asignacin de prioridad al proceso de su produccin.
Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programacin, sin
embargo estos puntos son vlidos tambin para sistemas pequeos.
1.
2.
Panorama. Hace una descripcin general del proyecto detalle de la organizacin del plan y resume el resto
del documento.
Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: anlisis de requisitos, fase de diseo
de alto nivel, fase de diseo de bajo nivel, etc. Asociada con cada fase debe de haber una fecha que
29

especifique cuando se debe terminar estas fases y una indicacin de como se pueden solapar las distintas
fases del proyecto.
3. Plan de organizacin. Se definen las responsabilidades especficas de los grupos que intervienen en el
proyecto.
4. Plan de pruebas. Se hace un esbozo general de las pruebas y de las herramientas, procedimientos y
responsabilidades para realizar las pruebas del sistema.
5. Plan de control de modificaciones. Se establece un mecanismo para aplicar las modificaciones que se
requieran a medida que se desarrolle el sistema.
6. Plan de documentacin. Su funcin es definir y controlar la documentacin asociada con el proyecto.
7. Plan de capacitacin. Se describe la preparacin de los programadores que participan en el proyecto y las
instrucciones a los usuarios para la utilizacin del sistema que se les entregue.
8. Plan de revisin e informes. Se analiza cmo se informa del estado del proyecto y se definen las revisiones
formales asociadas con el avance de proyecto.
9. Plan de instalacin y operacin. Se describe el procedimiento para instalar el sistema en la localidad del
usuario.
10. Plan de recursos y entregas. Se resume los detalles crticos del proyecto como fechas programadas,
marcas de logros y todos los artculos que deben entrar bajo contrato.
11. ndice. Se muestra en donde encontrar las cosas dentro del plan.
12. Plan de mantenimiento. Se establece un bosquejo de los posibles tipos de mantenimiento que se tienen
que dar para futuras versiones del sistema.
30

Nombre de la Prctica:
Elaboracin de un plan de trabajo (grfica de gant)
Unidad Temtica:
I. Mtricas de software
Tema:
Planeacin de proyectos
Objetivo de la prctica:
El alumno, realizar un diagrama de grant (planeador) en el cual

represente todas y cada una de las tareas que estn involucradas en
el proyecto.
2 Hrs
Fecha:
Tiempo de la Prctica:
Descripcin:
El alumno deber disear y construir un planeador de actividades en la cual muestre cada una de las
tareas involucradas en su proyecto o en cualquier proyecto haciendo hincapi a las fechas de inicio y
culminacin de las actividades as como las herramientas necesarias para el desarrollo de las mismas y el
encargado o responsable de quien realiza dicha tarea..
Antecedentes
Realizar una lista de actividades que se deben de desarrollar para la gestin de un programa u otra
actividad.
Dividir en sub-actividades cada una de las tareas o actividades primarias indicando o marcando intervalos
de tiempo especficos a estas
Una vez hecho lo anterior debern de nombrar a un responsable el cual tenga el control y sepa la
direccin de proyecto a emprender o desarrollar.
Entregue una impresin de su formato con la las diferentes tareas principales y sub tareas que estn
involucradas marcando o delimitando fechas de inicio, fechas finales y responsable de esa tarea.
Materiales y Equipos:
Computadora
Ms Office 97,2003,2007,2010
Procedimiento:
Organizarse en equipos de 3 personas, mximo 5
En base a su proyecto, discernir las distintas tareas o actividades que se deben de desarrollar en su
proyecto, plasmarlas en una hoja de Excel y llevar acabo las anotaciones necesarias.
Cuestionario
Referencias
31

ERRORES CLASICOS EN UN PROYECTO DE SOFTWARE

1. Mal anlisis en los requerimientos.
2. Una mala planeacin.
3. No tener una negociacin (documento, contrato) con el cliente.
4. No hacer un anlisis costo beneficio.
5. Desconocer el ambiente de trabajo de los usuarios.
6. Desconocer los usuarios que trabajan con el sistema.
7. Mala eleccin de recursos (hardware, software, humanos).
32

Unidad Temtica III Proceso Personal de Desarrollo de Software

Objetivo:El alumno identificar el Proceso Personal de Software, para medir su desempeo.
Temas
Saber
Saber hacer
Ser
Elementos
del Identificar los elementos del
Proceso Personal de PSP.
Software (PSP)
Organizado
Sistemtico
Plantillas PSP
Organizado
Analtico
Sistemtico
Disciplinado
Identificar los formatos y Determinar

su
nivel
procedimientos
para la personal de desarrollo al
medicin del PSP.
medir sus tiempos, tipificar
sus defectos y comparar su
desempeo
con
su
estimacin inicial.
Elaborar un documento que contenga las plantillas del PSP Nivel 0 para al menos 3 casos de estudio.
33

Elementos del Proceso Personal de Software (PSP)

Qu es el PSP?
Un PSP es un proceso personal desarrollar software que tiene:
pasos definidos
formularios
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.
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
4. Como todo profesional software deberas conocer tu propio rendimiento.
5. Deberas medir, seguir y analizar tu trabajo.
6. Deberas aprender de tus variaciones de tu rendimiento.
7. 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.
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
Estructura del PSP

El PSP se aplica en tareas personales estructuradas:
1. Desarrollo de mdulos de programas.
34

2.
3.
4.
5.
6.
7.
8.
9.
10.
Definicin de requisitos o procesos.

Realizacin de revisiones o pruebas.
Escritura de documentacin, etc.
El PSP se puede extender al desarrollo de sistemas software de gran tamao.
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.
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.
Elementos del proceso
35

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).
PSP 3 Proceso
Desarr Personal
PSP 2
Calidad
Cclico
ollo Personal
Revisin
del 1cdigo
PSP
Cclico
Revisin Planificaci
Estimacin
del diseo n Personal
del Tamao
PSP
0 de Medicin
Informe
Personal
pruebas
Proces
PSP O. Proceso (punto de partida)
o
PSP0 es un proceso sencillo, definido y personal.

1. Utiliza tus mtodos actuales de diseo y desarrollo.
2. Recoge datos sobre tu trabajo:
3. tiempo gastado por fase
4. defectos encontrados en compilacin y pruebas
5. Proporciona un informe resumen
36

6.
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.
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.
37

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.
Especific
aciones
Requerimi
entos
Y
Planificaci
Diseo
n de
Alto nivel
Repaso al
Diseo
De
Alto nivel
Desarrollo
Cclico
Postmorte
m
Ciclo especfico
Diseo detallado
Y
Repaso del
diseo
Desarrollo de las
pruebas
Y repaso
Implementacin
Y Repaso del
cdigo
Compilacin
Pruebas
Integraci
n
Pruebas
del
sistema
Uso
Valorar de nuevo
Y Reciclar
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.
3.2
Plantillas PSP
En esta seccin se observan algunos formatos y procedimientos para la medicin del PSP.
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).
38

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)
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
salida
de
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
39

Planificacin:
Estimar tiempo de desarrollo.
Desarrollo:
Desarrollar el producto utilizando tus mtodos actuales.
Post-mortem: Completar el resumen del plan proyecto, con los tiempos gastados y defectos
encontrados e inyectados en cada fase.
Diseo: Disear el programa, usando tus mtodos de diseo actuales.
Codificacin:
Implementa el programa.
Compilacin:
Compila hasta que est libre defectos.
Prueba: 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.
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.
Fecha:
Indicar la fecha actual.
Inicio:
Indicar el tiempo en minutos cuando empiezas una fase del proyecto
Fin:
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.
40

Comentarios: Descripcin de la interrupcin. La tarea que ests haciendo. Cualquier aspecto

significativo que afecte a tu trabajo
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).
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:
41

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.
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
42

6.
7.
8.
Defectos por hora

Efectividad de remocin de defectos
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
Tamao Mximo
Tamao Mnimo
Tiempo en fase (min.)
Planing
Diseo
Cdigo
Revisin cdigo
Compilacin
Test
Postmortem
Total
Tiempo Mximo
Tiempo Mnimo
Introduccin de defectos
Planing
Diseo
Cdigo
Revisin cdigo
Compilacin
Test
Total
Fecha: 18/10/96
Programa # 13
Lenguaje: C++
Plan
Actual a la Fecha
5,92
4,87
5,73
10,14 12,32 10,47
94,79 106,4 96,90
58
72
41
426
243
Plan
47
258
Plan
18
35
149
20
24
64
33
343
Actual
22
24
93
37
4
8
41
229
Para Fecha
88
151
637
111
92
240
160
1479
Actual Para Fecha
Para Fecha %
6,0
10,2
43,1
7,5
6,2
16,2
10,8
100
Para Fecha %
1
5
4
21
16,0
84,0
25
100,0
Def/Hora
43

Unidad Temtica IV Tcnicas de Estimacin

Objetivo: El alumno emplear las tcnicas de estimacin para determinar el tamao del software y el esfuerzo
requerido.
Temas
Puntos de funcin
Saber
Saber hacer
Ser
Identificar el procedimiento Calcular la cuenta ajustada Organizado

para la estimacin de los de puntos de funcin para Analtico
puntos de funcin
estimar el tamao del Sistemtico
software.
Puntos de caso de Identificar el procedimiento Calcular

el
esfuerzo Organizado
uso
para la estimacin de esfuerzo requerido para el desarrollo Analtico
utilizando casos de uso
de software con base en Sistemtico
casos de uso.
Elaborar un documento con base en un caso de estudio que contenga lo siguiente:
Estimacin de la complejidad por puntos de funcin.
Estimacin del esfuerzo por casos de uso.
44

Mxico tiene un nivel de gasto en tecnologas de la informacin y comunicaciones (TIC) de 3.2 del PIB, ubicndose
en el lugar 50 a nivel mundial. Este rezago es an mayor en trminos de gasto en software, que es 6 veces inferior al
promedio mundial y 9 veces menos que el de EUA. Con estos niveles no es de extraarnos que a nivel industria
tengamos poco avance en temas como las mtricas para SW.
Es conocido que grandes proyectos han fracasado al no estar a tiempo o dentro de presupuesto por una mala
estimacin de esfuerzo o duracin, o de las capacidades requeridas de los ingenieros y de la empresa.
En la vida real estimamos todo el da, por ejemplo:
Cuando elegimos cunto dinero llevaremos para las actividades de ese da.
Estimamos el tiempo que necesitamos si vamos en nuestro auto, en taxi o en colectivo, dependiendo del
lugar a dnde vayamos.
Estimamos cuando cruzamos la calle, si nos da tiempo o no, hasta comparamos la velocidad del auto
contra la velocidad de nosotros.
Si voy manejando, estimo si freno o no.
Cuando como estimo si con esa comida voy a engordar o no.
NOTA.- Diariamente usamos una gran cantidad de operaciones, en automtico, es decir, q no nos damos cuenta.
Tradicionalmente se ha medido el tamao del software mediante distintas mtricas: recuento de las lneas de
cdigo (LOC), nmero de programas fuente, o tcnicas similares, que no resultan aceptables como una buena
prctica profesional, porque:
Su resultado depende fuertemente del entorno tcnico y el lenguaje de programacin utilizado.
Vara en funcin de la pericia de cada programador y del uso de normas y metodologas.
No resultan significativas al usuario ni a la direccin.
Cuando se trata de establecer mtricas de productividad y calidad en la construccin de software, o realizar
estimaciones de coste y duracin, es imprescindible disponer de una medida fiable y comprensible del tamao de lo
que se construye.
ALGUNAS TCNICAS de estimacin se presentan a continuacin:
Por rangos.- En lugar de elegir un valor, elige varios de referencia.

Por analoga.- Los procesos se comparan contra otros proyectos.
Por recomposicin.- La tarea se descompone en procesos ms pequeos.
Calibracin de procesos.- Por ejemplo Nmero de bytes, LOC y casos de uso.
Juicio de los expertos.- Da su opinin gente con ms experiencia.
4.1 Puntos de Funcin

Lo relevante es la funcionalidad, como en cualquier inversin, a las empresas lo que les interesa es la capacidad de
hacer algo con lo que compran. Por ejemplo, si se compra un camin, de alguna forma se adquiri la capacidad de
transportar mercancas y con un tamao de metros cbicos por viaje. En primera instancia lo relevante es qu tanto
requiero transportar por viaje. En otro ejemplo, si se compra un edificio, entonces se adquiri la capacidad de
45

disponer de un espacio de X metros cuadrados distribuido en pisos; lo relevante es cunto espacio necesita la
empresa o institucin.
En SW no tiene por qu ser distinto; al adquirir un paquete o al desarrollar una aplicacin, lo primero que debe
evaluarse es qu nuevas capacidades estoy adquiriendo.
Estas capacidades o funcionalidad estarn en trminos de qu transacciones puedo realizar de forma automatizada
y qu grupos de datos puedo guardar.
A continuacin se presentan algunos TIPS para comprender este tema:
Se debe cumplir con medidas y evitar desviaciones en una estimacin.
Los parmetros y acotaciones se toman como referencia para que una serie sea considerada vlida.
TOLERANCIA.- Es un aspecto importante definida como la desviacin mxima permitida en una pieza o proceso.
Depende del fin para lo que fue diseada la pieza o el proceso. A mayor CALIDAD menor tolerancia.
Las mtricas o tcnicas aseguran que todas las piezas cumplan con parmetros de un plano u hoja de procesos.
Algunos ejemplos de las herramientas usadas para medir son: pie de rey, micrmetro de interiores, micrmetro de
exteriores, sonda de profundidad, etc.
Los dos principales determinantes para estimar el esfuerzo son: el tamao de lo que se requiere y la productividad
de quien lo va a hacer.
El Costo de producir software es entre el 20 y 25% del costo total de la aplicacin del software
La mtrica del punto funcin es un mtodo utilizado en ingeniera del software para medir el tamao del software.
Fue definida por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario
independientemente de la tecnologa utilizada para la construccin y explotacin del software, y tambin ser til en
cualquiera de las fases de vida del software, desde el diseo inicial hasta la explotacin y mantenimiento.
Vindolo de otro punto de vista: Los Puntos de Funcin son una mtrica que permite traducir en un nmero el
tamao de la funcionalidad que brinda un producto de software desde el punto de vista del usuario, a travs de una
suma ponderada de las caractersticas del producto.
CARACTERSTICAS de la funcionalidad
1.
2.
INDEPENDIENTE DE LA TECNOLOGA. Si nos basamos en lneas de cdigo (en la tecnologa) vamos a

obtener resultados no comparables. Pero ms que eso, tal vez lo relevante de esta caracterstica es que
una vez establecida la funcionalidad que requiero, debo escoger la tecnologa que me haga ms productivo
para obtener tal funcionalidad.
SIMPLE. Desde su concepcin, este tipo de mtrica se plante que no requiriera grandes esfuerzos para
obtener una medida. Una ventaja es que puedo establecer el tamao de un SW que tal vez llegue a tener
miles de lneas de cdigo en pocas horas. Sin embargo, el costo de esta simplicidad es que la mtrica no es
muy sensible a consideraciones muy detalladas, como lo sera por ejemplo, la complejidad de frmulas
matemticas.
46

3.
4.
5.
ENFOQUE EN LA FUNCIONALIDAD PROPORCIONADA. Ver qu nuevas capacidades voy a obtener con el

nuevo SW, antes de cualquier evaluacin tcnica.
BASADA EN LOS REQUERIMIENTOS DEL USUARIO. Esta caracterstica ayuda a que el usuario pueda
entender el significado e implicaciones del tamao del SW, sin tener que ser un experto en sistemas. Otro
punto muy importante con esta caracterstica es que puedo establecer un tamao desde que tengo los
requerimientos y no necesito esperar a terminar el proyecto para saber de qu tamao va a ser.
CONSISTENCIA. Los resultados obtenidos entre diferentes personas o en proyectos distintos deben ser
consistentes.
No es suficiente contar con una mtrica, sino que sea estndar para as poderla usar entre empresas o para tener
indicadores a nivel industria que todos puedan entender y operar. Por lo que se cre: ISO/IEC 14143 Information
Technology Software Measurement Functional Size Measurement. Este estndar define los conceptos de una
mtrica de tamao basada en la funcionalidad y las caractersticas que debe cumplir un mtodo para poder estar
homologado al estndar y ser considerado una medida del tamao de la funcionalidad.
El mtodo se basa principalmente en la identificacin de los componentes del sistema informtico en trminos de
transacciones y grupos de datos lgicos que son relevantes para el usuario en su negocio. A cada uno de estos
componentes les asigna un nmero de puntos por funcin basndose en el tipo de componente y su complejidad; y
la sumatoria de esto nos da los puntos de funcin sin ajustar. El ajuste es un paso final basndose en las
caractersticas generales de todo el sistema informtico que se est contando.
Se puede identificar el procedimiento para la estimacin de los puntos de funcin de la siguiente manera:
Paso 1. Determinar el tipo de conteo
Este paso consiste en definir el tipo de conteo entre desarrollo, mantenimiento o de una aplicacin ya instalada.
Esta es una forma de determinar el objetivo del conteo.
Paso 2. Identificar los alcances de la medicin y los lmites de la aplicacin.

El propsito de una medicin consiste en dar una respuesta a un problema de negocio. El alcance de la medicin
define la funcionalidad que va a ser incluida en una medicin especfica y puede abarcar ms de una aplicacin.
47

Componentes:
EI: Procesos en los que se introducen datos y que suponen la actualizacin de cualquier archivo interno.
EO: Procesos en los que se enva datos al exterior de la aplicacin.
EQ: Procesos consistentes en la combinacin de una entrada y una salida, en el que la entrada no produce ningn
cambio en ningn archivo y la salida no contiene informacin derivada.
ILF: Grupos de datos relacionados entre s internos al sistema.
EIF: Grupos de datos que se mantienen externamente.
Paso 3. Contar las funciones de datos
Este paso consiste en identificar y contar la capacidad de almacenamiento de los datos. Se distinguen dos tipos de
funciones de datos:
Archivo Lgico Interno es un grupo de datos relacionados que el usuario identifica, cuyo propsito principal es
almacenar datos mantenidos a travs de alguna transaccin que se est considerando en el conteo.
Archivo de Interfaz Externo - es un grupo de datos relacionados y referenciados pero no mantenido por alguna
transaccin dentro del conteo.
A cada componente identificado se le asigna una complejidad (bajo, medio o alto) considerando principalmente el
nmero de datos.
Paso 4. Contar las funciones transaccionales.
Este paso consiste en identificar y contar la capacidad de realizar operaciones.
Se distinguen tres tipos de funciones transaccionales:
Entrada Externa es un proceso cuyo propsito principal es mantener uno ms archivos lgicos internos.
Salida Externa es un proceso cuyo propsito principal es presentar informacin al usuario mediante un proceso
lgico diferente al de slo recuperar los datos.
Consulta Externa es un proceso cuyo propsito principal es presentar informacin al usuario leda de uno o ms
grupos de datos.
48

A cada componente identificado se le asigna una complejidad (bajo, medio o alto) considerando el nmero de datos
utilizado en el proceso y los archivos referenciados. Estos 5 componentes lgicos bsicos son con los que se
describe la funcionalidad de una aplicacin y los podemos representar grficamente de la siguiente forma:
Proceso de Estimacin Mediante PF No. Entradas al Sistema (EI) No. Salidas del Sistema (EO) No. Consultas BD (EQ)
No. Ficheros (ILF - EIF) Factor Correccin por Complejidad: No. Atributos de Entradas x Factor Correccin por
Complejidad: No. Atributos de Salidas x Factor... x Factor Correccin por Complejidad: No. Atributos de Ficheros x +
Puntos de Funcin Sin Ajustar Puntos de Funcin Ajustados Ajuste de Complejidad Tcnica Estimacin del Esfuerzo
Estimacin del Tiempo de Desarrollo Datos de Productividad del Equipo Escala de 14 Factores de Complejidad
Estimacin del Presupuesto.
Calcular No. Elementos y su Complejidad Contar los Elementos de cada Componente y su Complejidad 3
Componentes Identificados Salidas Entradas Consultas Ficheros Lgicos Internos Ficheros Externos Cantidad
Complejidad Cantidad Complejidad
Definicin de los Componentes del Sistema Salidas: 9 salidas de complejidad alta y 1 de complejidad media para el
subsistema mostrador, 3 salidas de complejidad alta y 1 de complejidad baja para el subsistema cocina, 2 salidas de
complejidad baja, 4 salidas de complejidad media y 3 salidas de complejidad alta para el subsistema administracin
y slo una salida de complejidad baja para el subsistema configuracin. Entradas: 9 entradas de complejidad alta
para el subsistema mostrador, 3 entradas de complejidad alta para el subsistema cocina, 2 entradas de complejidad
baja y 4 entradas de complejidad media para el subsistema administracin y 4 entradas de complejidad baja para el
subsistema configuracin. Consultas: 2 consultas de complejidad baja para el subsistema mostrador, 3 consultas de
complejidad baja para el subsistema cocina, 1 consulta de complejidad baja y 3 de complejidad alta para el
subsistema administracin y finalmente una consulta de complejidad baja para el subsistema configuracin.
Ficheros Lgicos Internos: 8 almacenes intermedios de datos de complejidad alta. Ficheros Externos: No se
utilizaron almacenes externos de datos.
Paso 5. Determinar los puntos de funcin no ajustados.
Este paso consiste en sumar el nmero de componentes de cada tipo conforme a la complejidad asignada y utilizar
la siguiente tabla para obtener el total.
49

Clculo de los Puntos de Funcin Sin Ajustar Por tanto los PFSA (Puntos de Funcin Sin Ajustar) se calculan como la
suma de los productos de cada componente por su peso determinado en la tabla correspondiente. PFSA = PFTe +
PFTo + PFTq + PFTif + PFTef Componente Bajo Medio Alto Total EI Eb * 3 = _ Em * 4 = _ Ea * 6 = _ PFTe EO Ob * 4 =
_ Om * 5 = _ Oa * 7 = _ PFTo EQ Qb * 3 = _ Qm * 4 = _ Qa * 6 = _ PFTq ILF IFb * 7 = _ IFm * 10 = _ IFa * 15 = _ PFTif
EIF EFb * 5 = _ EFm * 7 = _ EFa * 10 = _ PFTef PFSA.
Paso 6. Determinar el valor del factor de ajuste.
El factor de ajuste se obtiene sumando 0.65 a la sumatoria de los grados de influencia de las 14 caractersticas
generales del sistema, multiplicado por 0.01. Dentro de las caractersticas hay criterios como: complejidad del
proceso, facilidad de instalacin, entrada de datos en lnea, etc.
Paso 7. Determinar los puntos funcin ajustados.
Para determinar los puntos funcin ajustados se consideran los puntos funcin no ajustados por el factor de ajuste
Obtener los PF Ajustados 5 Componentes Identificados Entradas PFSA = 306 PFA=PFSA* [0.65+[0.01*ACT]]
Obtencin ACT Puntaje Factor de Ajuste Min Max Comunicacin de Datos 0 5 Proceso Distribuido 0 5 Objetivos de
Rendimiento 0 5 Configuracin de Explotacin Compartida 0 4 Tasa de transacciones 0 5 Entrada de Datos en Lnea
0 5 Eficiencia con el Usuario Final 0 5 Actualizaciones en Lnea
NOTA.- Obtener Informacin del Sistema requiere conocimiento global del sistema y construir un Modelo de
entidades primarias.
Clculo de los Puntos de Funcin Sin Ajustar PFSA = PFTe + PFTo + PFTq + PFTif + PFTef PFSA = 106 + 146 + 39 + 15 +
0 = 306 PF Componente Bajo Medio Alto Total EI 6 * 3 = 18 4 * 4 = 16 12 * 6 = 72 106 EO 4 * 4 = 16 5 * 5 = 25 15 * 7
= 105 146 EQ 7 * 3 = 21 0 * 4 = 0 3 * 6 = 18 39 ILF 0 * 7 = 0 0 * 10 = 0 1 * 15 = 15 15 EIF 0 * 5 = 0 0 * 7 = 0 0 * 10 = 0
0 306
Obtener los PF Ajustados Obtener Ajuste de la Complejidad Tcnica 5 El sistema para determinar la valoracin de
uno de los Factores de Ajuste: Ej: Comunicacin de Datos: Los datos usados en el sistema se envan o reciben por
lneas de comunicaciones. La valoracin para este factor se determina a travs de la eleccin de las siguientes
alternativas: a) 0 = Sistema Aislado del exterior (slo usuarios directos) b) 1 = Aplicacin batch con entrada de datos
remota o (exclusiva) utilizacin de perifricos de salida remotos. c) 2 = Aplicacin batch con entrada de datos
remota y utilizacin de perifricos de salida remotos. d) 3 = Aplicacin de captura de datos En-Lnea o hay un
sistema de teleproceso que pasa los datos a la aplicacin batch o sistema de consulta. e) 4 = Varios teleprocesos
pero con el mismo protocolo de comunicaciones. (para el presente caso) f) 5 = Hay teleproceso con varios
protocolos de comunicacin. Sistema Abierto y con interfaces de todo tipo al exterior. NOTA: (la sumatoria de las
valoraciones de los 14 factores dar el valor para el ACT N de Factor N de Factor Valor 0..5 1 Comunicacin de
Datos 4 2 Proceso Distribuido 4 3 Objetivos de Rendimiento 1 4 Configuracin de Explotacin Compartida 1 5 Tasa
de transacciones 3 6 Entrada de Datos en Lnea 5 7 Eficiencia con el Usuario Final 2 8 Actualizaciones en Lnea 3 9
Lgica de Proceso Interno Compleja 1 10 Reusabilidad del Cdigo 1 11 Conversin e Instalacin contempladas 0 12
Facilidad de Operacin 1 13 Instalaciones Mltiples 2 14 Facilidad de Cambios 4 Ajuste de Complejidad Tcnica
(ACT) 32
50

Clculo del Esfuerzo Clculo del Esfuerzo 6 PFA = 296.82 Esfuerzo horas/persona = PFA / [1 / 8 persona / hora)] =
296.82 / 0.125 = 2374.5 horas/persona LNEAS DE CDIGO = PFA * (LINEAS POR PF) Cambiar horas/efectivas por
horas productivas estimadas Esfuerzo Entorno y Lenguaje Lneas de Cdigo por PF Horas por PF Lenguajes 2GL:
Ensamblador, C, 300 20 a 30 Lenguajes 3GL: Cobol 100 10 a 20 Lenguajes 4GL: VisualXX 20 5 a 10
Clculo de la Duracin del Proyecto Clculo de la Duracin del Proyecto 7 DURACIN DEL PROYECTO EN HORAS =
2374.5 horas/persona / 5 personas = 474.91 horas por miembro DURACIN EN MESES = 474.91 horas / 100
horas/mes = 4 meses 15 dias HORAS POR PERSONA = 2374.5 Horas/mes productivas estimadas en el proyecto
Calculadas de 20 das laborables y De 5 horas productivas estimadas de las 8 de la jornada laboral normal diaria Se
asigna la cantidad de participantes en el proyecto
Clculo del Presupuesto del Proyecto Clculo del Presupuesto del Proyecto 8 Costo Total del Proyecto = sueldos 1
participante del proyecto * 5 participantes * 5 meses + Otros costos necesarios durante la realizacin del proyecto =
2000 * 5 * 5 = 50000 DURACIN DEL PROYECTO EN MESES = 5 meses Participante 1: Sueldo Participante 2: Sueldo
Participante n: Sueldo En la prctica se deben especificar Otros costos de operacin para determinar el presupuesto
total del proyecto
Desventaja:
Se le ha criticado a las mtricas funcionales que requieren que alguien identifique la funcionalidad y evale la
complejidad basndose en los criterios y reglas establecidas; no puedo hacer un programa que cuente
automticamente. Debido a esto, distintas personas podran llegar a un conteo diferente. Para resolver esto, se han
venido depurando las reglas de conteo para eliminar posibles ambigedades y cada vez hay ms material de apoyo
con ejemplos
NOTA: Cualquier mtrica tiene un mbito de accin y alcance definido que hay que entender para usarla
correctamente. As por ejemplo, el metro lineal no es lo mejor para medir grandes distancias en el mar. En nuestro
caso, Puntos Funcin, est enfocado a medir sistemas informticos completos, no programas. En este sentido no
tiene un nivel de precisin suficiente para medir el tamao de programas individuales.
4.2
Puntos de Casos de Uso
Puntos de caso de uso es un mtodo de estimacin de esfuerzo para proyectos de software, a partir de sus casos de
uso. Fue desarrollado por Gustav Karner en 1993, basndose en el mtodo de punto de funcin, y supervisado por
Ivar Jacobson. Ha sido analizado posteriormente en otros estudios.
El mtodo utiliza los actores y casos de uso relevados para calcular el esfuerzo que significar desarrollarlos. A los
casos de uso se les asigna una complejidad basada en transacciones, entendidas como una interaccin entre el
usuario y el sistema, mientras que a los actores se les asigna una complejidad basada en su tipo, es decir, si son
interfaces con usuarios u otros sistemas. Tambin se utilizan factores de entorno y de complejidad tcnica para
ajustar el resultado.
Al inicio de un proyecto de software, cuando apenas se conocen los casos de uso y sus actores asociados, se puede
proyectar una breve descripcin de cada caso de uso, en el cual se describe de forma breve la funcionalidad que
ste debe brindar.
El UUCP son los puntos de casos de uso sin ajustar, esto nos puede servir para tener una idea un poco ms precisa
de la dificultad de los casos de uso e interfaces, tomando en cuenta los pesos de los actores (UAW) y los pesos de
los casos de uso (UUCW). UUCP = UAW + UUCW
Estas siglas significan:
UUCP: Puntos de casos de uso sin ajustar.
UAW: Factor de peso de los actores sin ajustar.
UUCW: Factor de peso de los casos de uso sin ajustar.
51

Aplicando el anlisis de puntos de funcin a estos casos de uso, se puede obtener una estimacin trivial del tamao
y a partir de ella una estimacin del esfuerzo.
MTODO
El mtodo de punto de casos de uso consta de cuatro etapas, en las que se desarrollan los siguientes clculos:
1. Factor de peso de los actores sin ajustar (UAW)
2. Factor de peso de los casos de uso sin ajustar (UUCW)
3. Puntos de caso de uso ajustados (UCP)
4. Esfuerzo horas-hombre
1. Factor de peso de los actores sin ajustar (UAW)

Consiste en la evaluacin de la complejidad de los actores con los que tendr que interactuar el sistema. Este
puntaje se calcula determinando si cada actor es una persona u otro sistema, adems evala la forma en la que este
interacta con el caso de uso, y la cantidad de actores de cada tipo.
Tipo
actor
de
Descripcin
Factor
Simple
Otro sistema que interacta con el sistema a desarrollar mediante una interfaz de
1
programacin (API).
Medio
Otro sistema interactuando a travs de un protocolo (ej. TCP/IP) o una persona interactuando a
2
travs de una interfaz en modo texto.
Complejo Una persona que interacta con el sistema mediante una interfaz grfica (GUI).
3
Tabla 1: Peso de los actores sin ajustar.
La frmula sera: UAW = Sum(cantidadDeUnTipoDeActor*Factor)
Para realizar esta operacin sera necesario contar cuntos actores de cada tipo existen en el sistema, este
representara el valor cantidadDeUnTipoDeActor en la frmula y se tiene que multiplicar por el valor que tenga su
factor correspondiente, para obtener el resultado por cada tipo de actor. Una vez terminado esto se procede a
sumar cada producto para obtener el UAW.
2. Factor de peso de los casos de uso sin ajustar (UUCW)

Este punto funciona muy similar al anterior, pero para determinar el nivel de complejidad se puede realizar
mediante dos mtodos: basado en transacciones o basado en clases de anlisis.
Una transaccin es un conjunto de actividades atmicas, lo que quiere decir que se ejecutan todas o no se ejecuta
ninguna.
Basado en transacciones: Toma en cuenta el nmero de transacciones que se pueden realizar en un caso de uso y
lo evala segn la siguiente tabla:
Tipo de caso de uso Descripcin
Factor
Simple
3 transacciones o menos 5
Medio
4 a 7 transacciones
10
Complejo
Ms de 7 transacciones 15
Tabla 2: Peso de las transacciones.
Basado en clases de anlisis.
Toma en cuenta el nmero de clases que tiene un caso de uso y lo evala segn la siguiente tabla:
Tipo de caso de uso Descripcin
Factor
Simple
Menos de 5 clases 5
Medio
5 a 10 clases
Complejo
Ms de 10 clases 15
10
52

Tabla 3: Peso de las clases de anlisis.

Ahora independientemente del camino utilizado para determinar el tipo de caso de uso, la frmula es la misma y se
presenta a continuacin: La frmula sera: UUCW = Sum (CantidadDeUnTipoDeCasoUso*Factor). Para realizar esta
operacin se debe contar cuntos casos de uso de cada tipo hay en el sistema y esta cantidad se sustituira en el
campo nombrado como Cantidad De Un Tipo De Caso Uso y se multiplica por el valor que tenga su factor
correspondiente, para obtener el resultado por cada tipo de caso de uso. Una vez hecho esto se suma cada
producto para obtener el factor de peso de los casos de uso sin ajustar (UUCW).
Esta estimacin es bastante imprecisa debido principalmente a la escasa informacin que se tiene, pero permitir
obtener una idea del esfuerzo necesario para llevar adelante el mismo, y podr ser refinada a medida que se
obtenga ms informacin.
3. Puntos de caso de uso ajustados (UCP)
Para esto se utilizan las siglas UCP y se obtiene al multiplicar el UUCP el TCF y el EF quedando la operacin de la
siguiente forma:
UCP = UUCP x TCF x EF
UCP: Puntos de casos de uso ajustados.
UUCP: Puntos de casos de uso sin ajustar.
TCF: Factores tcnicos.
EF: Factores ambientales.
Factores de complejidad tcnica

Este se compone de 13 puntos que evalan la complejidad de los mdulos del sistema que se desarrolla, cada uno
de estos factores tienen un peso definido con los cuales se obtendr puntos ponderados por cada uno de ellos,
segn la valoracin que se le asigne. Para una mejor comprensin, a continuacin se mostrar una tabla con los
tems:
Factor Descripcin
Peso
T1
Sistema distribuido.
T2
Objetivos de performance o tiempo de respuesta.
T3
Eficiencia del usuario final.
T4
Procesamiento interno complejo.
T5
El cdigo debe ser reutilizable.
T6
Facilidad de instalacin.
0.5
T7
Facilidad de uso.
0.5
T8
Portabilidad.
T9
Facilidad de cambio.
T10
Concurrencia.
T11
Incluye objetivos especiales de seguridad.
T12
Provee acceso directo a terceras partes.
T13 Se requiere facilidades especiales de entrenamiento a usuario. 1

Tabla 4: Peso de los factores de complejidad tcnica.
Cada uno de estos puntos se debe evaluar segn la siguiente escala:
Descripcin Valor
Irrelevante De 0 a 2.
Medio
De 3 a 4.
53

Esencial
5
Tabla 5: Escala de los factores de complejidad tcnica.
Las frmulas para este punto son:
TFactor = Sum (Valor*Peso)
TCF = 0.6 + (0.01 * TFactor)
Para realizar este clculo, se debe evaluar cada factor, asignndole un valor como se menciona anteriormente,
despus se multiplican y se suma cada producto para obtener el TFactor. Luego, se debe seguir la segunda frmula
multiplicando el TFactor por 0.01 y sumar el resultado a 0.6, esto nos va a dar el TCF.
Factores ambientales
Los factores sobre los cuales se realiza la evaluacin son 8 puntos, que estn relacionados con las habilidades y
experiencia del grupo de personas involucradas con el desarrollo del proyecto. Estos factores se muestran a
continuacin:
Factor Descripcin
Peso
E1
Familiaridad con el modelo de proyecto utilizado. 1.5
E2
Experiencia en la aplicacin.
0.5
E3
Experiencia en orientacin a objetos.
E4
Capacidad del analista lder.
0.5
E5
Motivacin.
E6
Estabilidad de los requerimientos
E7
Personal part-time
-1
E8
Dificultad del lenguaje de programacin
-1
Tabla 6: Peso de los factores ambientales.
Cada uno de estos factores se debe calificar con un valor de 0 a 5.
Las frmulas para este punto son:
EFactor = Sum(Valor * Peso)
EF = 1.4 + (-0.03 * EFactor)
Para obtener el EFactor se debe sumar todos los productos obtenidos al multiplicar el peso de cada punto por el
valor asignado, despus se multiplica por -0.03 y se le suma el 1.4. As, se obtiene el peso de los factores
ambientales (EF).
4. Esfuerzo horas-hombre (E)

Este clculo se realiza con el fin de tener una aproximacin del esfuerzo, pensando solo en el desarrollo segn las
funcionalidades de los casos de uso. Anteriormente, se sugera utilizar 20 horas persona por UCP, pero a travs del
tiempo se ha ido mejorando. Est basado en los factores ambientales y se calcula de la siguiente manera:
Primero se debe contar la cantidad de factores ambientales del E1 al E6 que tienen una puntuacin menor a 3,
tambin contar la cantidad de estos mismos del E7 y E8 que son mayores que 3.
Factor
Filtro
De E1 a E6 Factor < 3
De E7 a E8 Factor > 3
Tabla 7: Factor de el esfuerzo horas-persona.
Para evaluar el resultado o la cantidad total segn la siguiente tabla:
Horas-Persona (CF) Descripcin
20
Si el valor es<=2
54

28
36
Tabla 8: Cantidad de horas-persona segn el valor.
El esfuerzo en horas-persona viene dado por:
E = UCP x CF
E: Esfuerzo estimado en horas-persona.
UCP: Puntos de Casos de Uso ajustados.
CF: Horas-Persona.
Si el valor es<=4
Si el valor es>=5
Al realizar la multiplicacin del UCP por las horas- persona, se consigue un esfuerzo estimado, que representa una
parte del total del esfuerzo de todo el proyecto, generalmente un 40%. Este 40% se refiere al esfuerzo total para el
desarrollo de las funcionalidades especificadas en los Casos de Uso.
En la siguiente tabla se detallan la distribucin en porcentaje, para el esfuerzo total en el desarrollo del proyecto:
Actividad
Porcentaje
Anlisis
10%
Diseo
20%
Programacin 40%
Pruebas
15%
Sobrecarga
15%
Se puede identificar el procedimiento para la estimacin de esfuerzo utilizando casos de uso de la siguiente
manera:
Identificar los Componentes del Sistema a partir de:
Diagramas de Casos de Uso (UML)
Diagramas de Contexto o DFD (P. Estructurada)
Componentes a Identificar: Salidas Entradas Consultas Ficheros Lgicos Internos Ficheros Externos
55

Unidad Temtica V Modelos para el aseguramiento de

la calidad del software
Objetivo: El alumno identificar el uso de los principales Modelos para asegurar la calidad en la Industria del
Desarrollo de Software.
Temas
Saber
Saber hacer
MOPROSOFT
Identificar la estructura del

modelo de proceso y de
evaluacin para la industria
mexicana de software.
CMMI
Identificar la estructura del Determinar el alcance de Organizado

modelo integrado de madurez los componentes de las Analtico
y capacidad (CMMI).
reas claves del proceso en Sistemtico
el nivel 2 de CMMI.
Ser
Determinar el alcance de Organizado

los componentes de las Analtico
reas
claves
de Sistemtico
MOPROSOFT.
Elaborar un documento que contenga lo siguiente:
Tabla comparativa entre los modelos MOPROSOFT y CMMI que incluya ventajas, desventajas y ejemplos
de empresas que los utilizan.
56

Tareas de aseguramiento de Calidad (SQA):
Establecer un plan SQA.

Descripcin del proceso de desarrollo.
Revisin de Actividades de Ing. Software.
Asegurar que las desviaciones se documenten.
Feedback para mejora continua.
Un EJEMPLO claro de los beneficios de tener un buen sistema de SQA es poder detectar los errores de un programa
antes de su entrega e implementacin, ya que resulta mucho ms caro corregir el error una vez implementado y a
la vez que se pierde la imagen de la organizacin al presentar productos que tenga fallas notables.
Resulta muy claro que los costos de la falta de calidad son mucho mayores a los que se requieren para implementar
un buen sistema de aseguramiento de la calidad.
5.1 MOPROSOFT
Para identificar la estructura del modelo de proceso y de evaluacin para la industria mexicana de software se
puede observar lo siguiente:
En 2002 la Secretara de Economa (SE) inici el Programa para el Desarrollo de la Industria de Software (PROSOFT),
que tiene como objetivo Fortalecer a la Industria de Software en Mxico.
Las estrategias del PROSOFT son:
1.
2.
3.
4.
5.
6.
7.
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
Promover la construccin de infraestructura fsica y de telecomunicaciones
La Secretaria de Economa encarg a la Dra. Hanna Oktaba de la UNAM y a un grupo de colaboradores investigar
que procesos podan utilizarse en la industria mexicana para el desarrollo de software, en su mayora PyMES
(Pequea y Mediana empresa), concluyndose en el estudio que no haba un modelo de procesos y evaluacin que
se adaptara 100% a las empresas mexicanas.
Por lo que se propuso desarrollar un modelo de procesos y un mtodo de evaluacin a la medida de nuestra
industria. Por supuesto que no se trataba de inventar el hilo negro. El compromiso era cubrir por lo menos las
prcticas del modelo CMM-SW nivel 3 e ISO9000:2000, en el caso del modelo de procesos, y cumplir con los
lineamientos de ISO15504, con respecto al mtodo de evaluacin
Modelo MOPROSOFT
En Junio de 2003 se hizo pblico el MoProSoft (el Modelo de Procesos para la Industria de Software) como
documento base para la norma mexicana.
57

Tambin se trabaj con un equipo de trabajo para definir el mtodo de evaluacin basado en MoProSoft como
modelo de procesos, as se desarroll EvalProSoft (el mtodo de Evaluacin de Procesos de Software)
En julio de 2004 se realiz el proceso de seleccin de cuatro empresas a las cuales se les aplic una evaluacin
inicial para conocer sus niveles de capacidades con respecto al modelo de MoProSoft. Posteriormente, entre agosto
y diciembre, con el apoyo de una consultora un da a la semana, las empresas adecuaron los procesos de MoProSoft
a sus necesidades, definieron las plantillas de los productos y empezaron a implementar los procesos. El objetivo de
las pruebas controladas fue demostrar que, en un lapso de tiempo relativamente corto, las empresas pueden elevar
sus niveles de capacidad y no morir en el intento.
En 2005 todos los esfuerzos se centraron en convertir los dos modelos en la norma mexicana. El trabajo se realiz
dentro del Subcomit de Software del NYCE (Normalizacin Y Certificacin en Electrnica), La norma fue aprobada
por el NYCE el 5 de julio y el 15 de agosto publicada en el Diario Oficial de la Federacin. Su nombre completo es:
NMX-I-059/04-NYCE-2005 Tecnologa de la Informacin-Software-Modelos de procesos y evaluacin para desarrollo
y mantenimiento de software:
Parte 01: Definicin de conceptos y productos
Parte 02: Requisitos de procesos (MoProSoft)
Parte 03: Gua de implantacin de procesos
Parte 04: Directrices para la evaluacin (EvalProSoft)
MOPROSOFT clasifica a sus procesos en 3 categoras que son:
Categora
Alta Direccin (DIR)
Gestin (GES)
Operacin (OPE)
Alta direccin, Gestin y operacin
Proceso
Gestin de Negocio
Gestin de Procesos
Gestin de Proyectos
Gestin de Recursos
Administracin de Proyectos Especficos
Desarrollo y Mantenimiento de Software
Gestin de Negocio (DIR)

Propsito:
Establecer la razn de ser de la organizacin, sus objetivos y las condiciones para lograrlos, para lo cual es
necesario considerar las necesidades de los clientes, as como evaluar los resultados para poder proponer cambios
que permitan la mejora continua.
Adicionalmente habilita a la organizacin para responder a un ambiente de cambio y a sus miembros para
trabajar en funcin de los objetivos establecidos
58

Tareas a realizar en esta categora:

Plan estratgico de la organizacin:
Misin, Visin, Valores, Objetivos, Estrategias, Procesos requeridos, Cartera de proyectos, Estructura de la
organizacin, Estrategia de recursos, Presupuesto, Plan de comunicacin con el cliente
Necesidad de mejora
59

Gestin de Procesos (GES)

Propsito:
Establecer los procesos de la organizacin, en funcin de los Procesos Requeridos identificados en el Plan
Estratgico. As como definir, planear, e implantar las actividades de mejora en los mismos.
Capacitar a los encargados de los procesos en Moprosoft
Definir el catlogo de procesos de la organizacin
Identificar los procesos
Documentar los procesos.
Realizar una plantilla para documentar los procesos.
Capacitar en el uso de la plantilla para documentarlos
Usar diagramas de actividades de UML
Producto
PLANTILLA PARA DOCUMENTAR LOS PROCESOS

Proceso.
Propsito.
Descripcin.
Indicadores.
Responsable y autoridad.
Nombre del proceso.

Objetivos generales y resultados esperados de la
ejecucin del proceso.
Describir las actividades ms generales del proceso.
Definir las formas de evaluar la efectividad en el
cumplimiento de los objetivos del proceso.
Indicar quien es el responsable principal de la ejecucin
60

de este proceso. Autoridad es quien comprueba la

ejecucin y el cumplimiento del propsito del proceso.
Lista de procesos de los cuales se compone el proceso en
cuestin.
Subprocesos.
Procesos relacionados.
Entradas.
Otros procesos con los cuales se tiene relacin.

Definir los documentos o productos que sirven de base
para este proceso.
Definir los documentos o productos resultados de este
proceso.
Definir los documentos o productos que se utilizan en
este proceso.
Cargos de las personas involucradas en este proceso.
Tareas que se llevan a cabo en este proceso. Esta
descripcin puede acompaarse de un diagrama de
actividades.
Salidas.
Productos internos.
Roles.
Actividades.
Gestin de Proyectos (GES)

Propsito
Asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organizacin.
61

Definir el proyecto.
Registrar el proyecto.
Describir el proyecto.
Responsable del proyecto.
Contrato.
Metas cuantitativas del proyecto.
Gestin de Recursos (GES)

Propsito:
Conseguir y dotar a la organizacin de los recursos humanos, infraestructura, ambiente de trabajo y proveedores.
Crear y mantener la Base de Conocimiento de la organizacin.
La finalidad es apoyar el cumplimiento de los objetivos del Plan Estratgico de la organizacin.

1.
2.
3.
4.
Capacitar a los encargados de los involucrados en Moprosoft

Crear el Plan operativo de Bienes, Servicios e Infraestructura
Crear el Plan operativo de Recursos Humanos y Ambiente de trabajo
Crear el Plan operativo de Conocimiento de la organizacin
62

Administracin de proyectos especficos (OPE)

Propsito:
Establecer y llevar a cabo sistemticamente las actividades que permitan cumplir con los objetivos de un proyecto
en tiempo y costo esperados.
Estudiante: _Juan
Lus
Guerra_____
____
Fecha:
_09/10/06__
Programa:_Raz
Cuadrada___
__________
Programa
#: _1A
Instructor:
Fecha
Inicio
Fin
Tiempo de
_XX________
Interrupcin
___________
____
9/9
9:00
9:50
Lenguaje:
___C____
12:40
1:18
Tamao
del
programa
2:45
3:53
10
(LOC)
Planeacin
Plan
10/9
11:06
12:19
6+5
1. Definir el proceso especfico con base en la Descripcin
Actual del Proyecto y el proceso de Desarrollo y
11/9
9:00
9:50
Total
Mantenimiento del Software
(Nuevas&Mo
1:15
2:35
3+8
2. Definir el Protocolo de Entrega al Cliente
dificadas) 50
3. Definir ciclos y actividades
33
4:18
5:11
25
Tiempo en Fase
4. Establecer el Equipo de trabajo
13/9
9:00
9:50
(minutos)
5. Establecer calendario de actividades
Plan
12:33
1:16
Actual A
6. Documentar el Plan del Proyecto
la Fecha A
7. Documentar el Plan de Desarrollo
la Fecha%
8. Formalizar el inicio de un nuevo ciclo
Planeacin
2
2
1.6
Diseo
Realizacin
0
0
1. Acordar las tareas del equipo de trabajo.
0
2. Acordar la distribucin de la informacin al equipo
de trabajo.
Codificacin
53de trabajo.
3. Recolectar los reportes de actividades, mediciones y productos
53
4. Revisar los productos terminados.
44.2
5. Revisar las solicitudes de cambio del cliente.Compilacin
20 reportar los avances y tomar acuerdos.
6. Realizar reuniones con el equipo de trabajo y con el cliente para
20
16.7
63
Prueba
25
25
20.8
Postmortem
20
20
16.7
Estudiante:
_________
_________
__
Fecha:
_________
_
Instructor:_
_________
_________
___
Progra
ma
#:
______
Tiemp
50
38
58
62
50
69
28
50
38

Evaluacin y control
1. Evaluar el cumplimiento del Plan del Proyecto y Plan de Desarrollo
2. Generar el Protocolo de entrega y terminacin del ciclo.
Entradas:
1. Descripcin del proyecto (Gestin de proyectos)
2. Documentacin del proceso (Gestin de proyectos)
Salidas:
1. Plan de Proyecto
2. Plan de Desarrollo
Lecciones aprendidas
1. Reporte de mediciones y Sugerencias de Mejora
2. Reporte de seguimiento
Desarrollo y Mantenimiento de software (OPE)

Propsito:
Es la realizacin sistemtica de las actividades de anlisis, diseo, construccin, integracin y pruebas de
productos de software nuevos o modificados cumpliendo con los requerimientos especificados.
Proceso de desarrollo y mantenimiento de software (OPE)
Incluye: Ciclos de Desarrollo, Fases de un Ciclo, Actividades de una Fase
Fases:
Para cada fase se describen los productos a generar y/o las actividades a realizar
1. Inicio
2. Armar el equipo
3. Socializacin de conocimientos
4. Requerimientos
5. Los requerimientos se recolectan y se validan con el cliente
6. Texto con el problema
7. Casos de uso generales y detallados
8. Glosario de trminos
9. Prototipo (si aplica)
10. Anlisis y diseo
11. Diagramas de clases
12. Diagrama de la base de datos
13. Arquitectura y diagrama de paquetes principales del sistema
14. Diagrama de componentes por paquete
64

15. Construccin
La construccin se har en cada subgrupo y se probar en cada subgrupo

1. Cdigo
2. Pruebas e integracin
3. Pruebas de integracin
4. Prueba del sistema
Cierre
1.
2.
Evaluacin del proceso y producto

Documentar las Lecciones aprendidas
Experiencias al aplicar el modelo de procesos de software en la empresa:

Toda la organizacin debe saber que se est aplicando Moprosoft.
Se debe empezar por documentar lo mas general
Se puede aplicar Moprosoft de manera que se avance en la madurez de la organizacin.
Avanzar paso a paso, no correr, pues abruma la cantidad de tareas a realizar y documentar.
Las organizaciones no siempre tienen claro cuales son sus procesos.
Se confunde procesos con estructura.
Muchas empresas tienen un proceso implcito de desarrollo, hay que documentarlo.
Capacitar en las tcnicas necesarias para el modelado del negocio y del desarrollo.
5.2
CMMI
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.
65

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.
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.
5.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.
66

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
madurez
Nivel 1
Inicial
Nivel 2
Repetible
Nivel 3
Definido
Nivel 4
Gestionado
Nivel 5
Optimizado
de
reas Claves
Ninguna
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
Enfoque del proceso de la organizacin
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
67

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.
68

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).
5.2.2 Caractersticas comunes:
Compromiso de realizacin
Capacidad para llevarla a cabo
Actividades que hay que realizar
Medicin y anlisis
Verificacin de la implementacin
69

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
Investigacin de Tendenc
Tecnolgicas
Planificacin
Planificacin de Recursos
Valoracin y Mejora
Continua
Seguimiento y Control
P
l
a
Preparacin para n
la Realizacin
i
Preparacin a la
f
Implantacin
R
i
P
e
c
l
a
a
a
l
c
n
i
i
i
z
f
a
Evaluacin y Control
n
i
Planificacin
c
c
Estratgica
i
E
a
v
c
n
a
i
l
u
n
a
c
70

a tres niveles (tomados del modelo CMMI), los cuales son: Inicial, Definido y Optimizado.
71

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.
Indicador: Es un signo o medicin de un fenmeno.
ndice: Es la relacin cuantitativa entre dos cantidades relacionadas con un mismo fenmeno.
72

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. Corresponde a las necesidades
propias de una organizacin para satisfacer los objetivos de calidad propuesto
73

Antologia

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Antologia

Загружено:

Авторское право:

Доступные форматы

Universidad Tecnolgica de Puebla

Tecnologas de la Informacin y Comunicacin

Calidad en el Desarrollo de Software

ELABOR: UNIVERSIDAD TECNOLGICA

REVIS: UNIVERSIDAD(ES) TECNOLGICA(S)

CALIDAD EN EL DESARROLLO DE SOFTWARE

CALIDAD EN EL DESARROLLO DE SOFTWARE

METRICAS DEL PSP .......................................................................................................................................42

CALIDAD EN EL DESARROLLO DE SOFTWARE

Introduccin a la Calidad en el Desarrollo de Software.

CALIDAD EN EL DESARROLLO DE SOFTWARE

Unidad Temtica I Introduccin a la Calidad de Software.

Conceptos de Calidad Identificar los factores y Determinar la calidad de un

CALIDAD EN EL DESARROLLO DE SOFTWARE

Figura Representacin esquemtica del proceso de control de calidad

Gestin de la calidad total

Satisfaccin del cliente. Constituye el objetivo prioritario.

CALIDAD EN EL DESARROLLO DE SOFTWARE

Conseguir hacer las cosas bien a la primera.

CALIDAD EN EL DESARROLLO DE SOFTWARE

Conformidad con las

Slo Depto. de calidad

Todos los miembros

Satisfaccin del cliente

CALIDAD EN EL DESARROLLO DE SOFTWARE

CALIDAD EN EL DESARROLLO DE SOFTWARE

Beneficios de los Estndares

Utilizacin de los Estndares

CALIDAD EN EL DESARROLLO DE SOFTWARE

INSTITUTOS QUE REGULAN LA CALIDAD

CALIDAD EN EL DESARROLLO DE SOFTWARE

CONCEPTOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE

Concordancia con los requerimientos.

Prevencin de futuros problemas.

Costos de correccin de errores.

CALIDAD EN EL DESARROLLO DE SOFTWARE

EVALUACIN DEL PRODUCTO SOFTWARE: ISO 14598

Figura. La ISO/IEC 14598 y el proceso para evaluar software (D. A. R.)

Requisitos para desarrolladores (parte 3).

CALIDAD EN EL DESARROLLO DE SOFTWARE

Requisitos para evaluadores (parte 5).

Audiencia destino para la NORMA ISO 14598

Alcance de la NORMA ISO 14598

I. ISO/IEC 14598 - Parte 1: Visin General

Establecer los requerimientos de evaluacin.

CALIDAD EN EL DESARROLLO DE SOFTWARE

Figura ISO/IEC 14598 - Parte 1: Visin General (D. A. R.)

II. ISO/IEC 14598 - Parte 2: Planificacin y Gestin

Preparacin de las polticas.

III. ISO/IEC 14598 - Parte 3: El Proceso para Desarrolladores

CALIDAD EN EL DESARROLLO DE SOFTWARE

IV. ISO/IEC 14598 - Parte 4: El Proceso para Compradores

CALIDAD EN EL DESARROLLO DE SOFTWARE

Los requerimientos de calidad a ser evaluados correlacionados con la calidad en uso y

Necesidades de acceso a la documentacin del producto, herramientas de desarrollo y personal.

V. ISO/IEC 14598 - Parte 5: El Proceso para Evaluadores

CALIDAD EN EL DESARROLLO DE SOFTWARE

La extensin del la cobertura (o el alcance).

Las especificaciones adicionalmente deberan cubrir:

VI. ISO/IEC 14598 - Parte 6: Documentacin de los Mdulos de Evaluacin

CALIDAD EN EL DESARROLLO DE SOFTWARE

Referencias y Definiciones requeridas.

Asignatura, Unidad temtica, Nombre de la