UNIVERSIDAD AGRARIA DEL ECUADOR

INVESTIGACION GRUPAL

INTEGRANTES

Javier Cercado

Gabriela Espinoza

Andrea Guarinda

Jostin Joutex

Curso

6 Semestre A

Docente

Ing. William Bazn

AO LECTIVO

2017-2018
 El PROCESO DE SOFTWARE Y MTRICAS DE PROYECTOS

La medicin es fundamental para cualquier disciplina de ingeniera, y la ingeniera del software

no es una excepcin. La medicin nos permite tener una visin ms profunda proporcionando un
mecanismo para la evaluacin objetiva. Lord Kelvin en una ocasin dijo:
Cuando pueda medir lo que est diciendo y expresarlo con nmeros, ya conoce algo sobre ello;
cuando no pueda medir, cuando no pueda expresar lo que dice con nmeros, su conocimiento es
precario y deficiente: puede ser el comienzo del conocimiento, pero en sus pensamientos, apenas
est avanzando hacia el escenario de la ciencia.
La comunidad de la ingeniera del software ha comenzado finalmente a tomarse en serio las
palabras de Lord Kelvin. Pero no sin frustraciones y s con gran controversia.
Las mtricas del software se refieren a un amplio elenco de mediciones para el software de
computadora. La medicin se puede aplicar al proceso del software con el intento de mejorarlo
sobre una base continua. Se puede utilizar en el proyecto del software para ayudar en la
estimacin, el control de calidad, la evaluacin de productividad y el control de proyectos.
Finalmente, el ingeniero de software puede utilizar la medicin para ayudar a evaluar la calidad
de los resultados de trabajos tcnicos

El Proceso Del Software.

Un proceso de software se puede caracterizar como se muestra en la Figura. Se establece un marco
comn del proceso definiendo un pequeo nmero de actividades del marco de trabajo que son
aplicables a todos los proyectos del software, con independencia de su tamao o complejidad. Un
nmero de conjuntos de tareas -cada uno es una coleccin de tareas de trabajo de ingeniera del
software, hitos de proyectos, productos de trabajo, y puntos de garanta de calidadque permiten
que las actividades del marco de trabajo se adapten a las caractersticas del proyecto del software
y a los requisitos del equipo

Modelos De Proceso De Software.

Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de
ingenieros deben incorporar una estrategia de desarrollo que acompae al proceso, mtodos y
capas de herramientas descritos en la Seccin y las fases genricas discutidas en la Seccin Esta
estrategia a menudo se llama modelo de proceso o paradigma de ingeniera del software.
Se selecciona un modelo de proceso para la ingeniera del software segn la naturaleza del
proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse, y los controles y entregas
que se requieren. En un documento Intrigante sobre la naturaleza del proceso del software, L.B.S.
Raccoon utiliza fractales como base de estudio de la verdadera naturaleza del proceso del
software.
En las secciones siguientes, se tratan diferentes modelos de procesos para la ingeniera del
software. Cada una representa un intento de ordenar una actividad inherentemente catica. Es
importante recordar que cada uno de los modelos se ha caracterizado de forma que ayuden (con
esperanza) al control y a la coordinacin de un proyecto de software real. Y a pesar de eso, en el
fondo, todos los modelos exhiben caractersticas del Modelo del Caos.

Medidas, Mtricas e Indicadores

Aunque los trminos medida, medicin y mtricas se utilizan a menudo indistintamente,
es importante destacar las diferencias sutiles entre ellos. Como los trminos medida y
medicin se pueden utilizar como un nombre o como un verbo, las definiciones de
estos trminos se pueden confundir. Dentro del contexto de la ingeniera del software,
una medida proporciona una indicacin cuantitativa de la extensin, cantidad,
dimensiones, capacidad o tamao de algunos atributos de un proceso o producto. La
medicin es el acto de determinar una medida. El ZEEE Standard Glossary of Software
Engineering Terms [IEEE93] define mtrica como una medida cuantitativa del grado en
que un sistema, componente o proceso posee un atributo dado.
Mtricas en el proceso y dominios del proyecto
La medicin es algo comn en el mundo de la ingeniera. Se mide el consumo de energa,
el peso, las dimensiones fsicas, la temperatura, el voltaje, la relacin seal-ruido.., la lista
es casi interminable. Por desgracia, la medicin es mucho menos comn en el mundo de
la ingeniera del software. Existen problemas para ponerse de acuerdo sobre qu medir y
las medidas de evaluacin de problemas recopilados.
Los indicadores de proyecto permiten al gestor de proyectos del software
1. evaluar el estado del proyecto en curso;
2. seguir la pista de los riesgos potenciales:
3. detectar las reas de problemas antes de que se conviertan en crticas;
4. ajustar el flujo y las tareas del trabajo, y
5. evaluar la habilidad del equipo del proyecto en controlar la calidad de los
productos de trabajo del software.
Mtricas del proceso y mejoras en el proceso del software
La nica forma racional de mejorar cualquier proceso es medir atributos del proceso,
desarrollar un juego de mtricas significativas segn estos atributos y entonces utilizar
las mtricas para proporcionar indicadores que conducirn a una estrategia de mejora.
Pero antes de estudiar las mtricas del software y su impacto en la mejoras de los procesos
del software es importante destacar que el proceso es el nico factor de los controlables
al mejorar la calidad del software y su rendimiento como organizacin

Qu directrices deben aplicarse cuando recogemos mtricas del software?

A medida que una organizacin est ms a gusto con la recopilacin y utiliza mtricas de
proceso, la derivacin de indicadores simples abre el camino hacia un enfoque ms
riguroso llamado mejora estadstica de proceso del software (MEPS). En esencia, MEPS
utiliza el anlisis de fallos del software para recopilar informacin de errores y defectos3
encontrados al desarrollar y utilizar una aplicacin de sistema o producto.
1. Todos los errores y defectos se categorizan por origen (por ejemplo: defectos en
la especificacin, en la lgica, no acorde con los estndares).
2. Se registra tanto el coste de corregir cada error como el del defecto.
3. El nmero de errores y de defectos de cada categora se cuentan y se ordenan en
orden descendente.
4. Se computa el coste global de errores y defectos de cada categora.
5. Los datos resultantes se analizan para detectar las categoras que producen el
coste ms alto para la organizacin.
6. Se desarrollan planes para modificar el proceso con el intento de eliminar (o
reducir la frecuencia de apariciones de) la clase de errores y defectos que sean
ms costosos.
 Mtricas del proyecto
Las mtricas del proceso de software se utilizan para propsitos estratgicos. Las medidas
del proyecto de software son tcticas. Esto es, las mtricas de proyectos y los indicadores
derivados de ellos los utilizan un gestor de proyectos y un equipo de software para adaptar
el flujo del trabajo del proyecto y las actividades tcnicas.
Mtricas Orientadas al Tamao
Las mtricas del software orientadas al tamao provienen de la normalizacin de las
medidas de calidad y/o productividad considerando el tamao del software que se haya
producido. Si una organizacin de software mantiene registros sencillos, se puede crear
una tabla de datos orientados al tamao. La tabla lista cada proyecto de desarrollo de
software de los ltimos aos y las medidas correspondientes de cada proyecto.

Mtricas Orientadas a la Funcin

Las mtricas del software orientadas a la funcin utilizan una medida de la funcionalidad
entregada por la aplicacin como un valor de normalizacin. Ya que la funcionalidad>>
no se puede medir directamente, se debe derivar indirectamente mediante otras medidas
directas. Las mtricas orientadas a la funcin fueron propuestas por primera vez por
Albretch, quien sugiri una medida llamada punto defuncin. Los puntos de funcin se
derivan con una relacin emprica
Mtricas ampliadas de punto de funcin
La medida de punto de funcin se dise originalmente para aplicarse a aplicaciones de
sistemas de informacin de gestin. Para acomodar estas aplicaciones, se enfatiz la
dimensin de datos (los valores de dominios de informacin tratados anteriormente) para
la exclusin de dimensiones (control) funcionales y de comportamiento. Por esta razn,
la medida del punto de funcin era inadecuada para muchos sistemas de ingeniera y
sistemas empotrados (que enfatizan funcin y control). Para remediar esta situacin se ha
propuesto un nmero de extensiones a la mtrica del punto de funcin bsica.
 PLANIFICACIN DE PROYECTOS DE SOFTWARE

La gestin de un proyecto de software comienza con un conjunto de actividades que

globalmente se denominan planificacin del proyecto. Antes de que el proyecto
comience, el gestor y el equipo de software deben realizar una estimacin del trabajo a
realizar, de los recursos necesarios y del tiempo que transcurrir desde el comienzo hasta
el final de su realizacin. Siempre que estimamos, estamos mirando hacia el futuro y
aceptamos resignados cierto grado de incertidumbre.
Aunque la estimacin es ms un arte que una ciencia, es una actividad importante que no
debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin del
esfuerzo y del tiempo. Las mtricas del proyecto y del proceso proporcionan una
perspectiva histrica y una potente introduccin para generar estimaciones cuantitativas.
La experiencia anterior (de todas las personas involucradas) puede ayudar en gran medida
al desarrollo y revisin de las estimaciones. Y, dado que la estimacin es la base de todas
las dems actividades de planificacin del proyecto, y que sirve como gua para una buena
ingeniera del software, no es en absoluto aconsejable embarcarse sin ella.
Observacin sobre la estimacin

A un destacado ejecutivo se le pregunt una vez por la caracterstica ms importante

que debe tener un gestor de proyectos. Respondi: <<... una persona con la habilidad de
saber qu es lo que va a ir mal antes de que ocurra.... Debemos aadir: <<...y con el
coraje para hacer estimaciones cuando el futuro no est claro....
La estimacin de recursos, costes y planificacin temporal de un esfuerzo en el desarrollo
de software requiere experiencia, acceder a una buena informacin histrica y el coraje
de confiar en predicciones (medidas) cuantitativas cuando todo lo que existe son datos
cualitativos. La estimacin conlleva un riesgo inherente' y es este riesgo el que lleva a la
incertidumbre.
La complejidad del proyecto tiene un gran efecto en la incertidumbre, que es inherente en
la planificacin. Sin embargo, la complejidad es una medida relativa que se ve afectada
por la familiaridad con esfuerzos anteriores. Se podra considerar una aplicacin
sofisticada de comercio electrnico como excesivamente compleja para un
desarrollador que haya realizado su primera aplicacin. Sin embargo para un equipo de
software que desarrolle su ensimo sitio web de comercio electrnico podra considerarse
sumamente fcil (una de tantas).
El tamao del proyecto es otro factor importante que puede afectar a la precisin y a la
eficiencia de las estimaciones. A medida que el tamao aumenta, crece rpidamente* la
interdependencia entre varios elementos del software. El problema de la descomposicin,
un enfoque importante hacia la estimacin, se hace ms difcil porque los elementos
descompuestos pueden ser todava excesivamente grandes. Parafraseando la ley de
Murphy: <<lo que puede ir mal ir mal, y si hay ms cosas que puedan fallar, ms cosas
fallarn.
 Objetivos de la planificacin del proyecto
El objetivo de la planificacin del proyecto de software es proporcionar un marco de
trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y
planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo
limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente a
medida que progresa el proyecto. Adems, las estimaciones deberan definir los
escenarios del mejor caso y peor caso de forma que los resultados del proyecto puedan
limitarse.
mbito del software
El mbito del software describe el control y los datos a procesar, la funcin, el
rendimiento, las restricciones, las interfaces y la fiabilidad. Se evalan las funciones
descritas en la declaracin del mbito, y en algunos casos se refinan para dar ms detalles
antes del comienzo de la estimacin. Dado que las estimaciones del coste y de la
planificacin temporal estn orientadas a la funcin, muchas veces es til llegar a un
cierto grado de descomposicin. Las consideraciones de rendimiento abarcan los
requisitos de tiempo de respuesta y de procesamiento. Las restricciones identifican los
lmites del software originados por el hardware externo, por la memoria disponible y por
otros sistemas existentes.
Obtencin de la informacin necesaria
La tcnica utilizada con ms frecuencia para acercar al cliente y al desarrollador, y para
hacer que comience el proceso de comunicacin es establecer una reunin o una entrevista
preliminar. La primera reunin entre un ingeniero de software (el analista) y el cliente
puede compararse a la primera cita entre adolescentes.
Ninguna persona sabe lo que decir o preguntar; ambos estn preocupados por si lo que
dicen es mal interpretado; ambos estn pensando hasta dnde podran llegar
(probablemente los dos tienen aqu diferentes expectativas); ambos quieren quitrselo
pronto de encima; pero al mismo tiempo quieren que salga bien.

Recursos
La segunda tarea de la planificacin del desarrollo de software es la estimacin de los
recursos requeridos para acometer el esfuerzo de desarrollo de software. La Figura ilustra
los recursos de desarrollo en forma de pirmide. En la base de la pirmide de recursos se
encuentra el entorno de desarrollo -herramientas de hardware y software- que proporciona
la infraestructura de soporte al esfuerzo de desarrollo. En un nivel ms alto se encuentran
los componentes de software reutilizables-los bloques
de software que pueden reducir drsticamente los
costes de desarrollo y acelerar la entrega-.
En la parte ms alta de la pirmide est el recurso
primario -el personal-. Cada recurso queda
especificado mediante cuatro caractersticas:
descripcin del recurso, informe de disponibilidad,
fecha cronolgica en la que se requiere el recurso,
tiempo durante el que ser aplicado el recurso. Las dos
ltimas caractersticas pueden verse como una ventana temporal. La disponibilidad del
recurso para una ventana especfica tiene que establecerse lo ms pronto posible.
Recursos humanos
El encargado de la planificacin comienza elevando el mbito y seleccionando las
habilidades que se requieren para llevar a cabo el desarrollo. Hay que especificar tanto la
posicin dentro de la organizacin (por ejemplo: gestor, ingeniero de software
experimentado, etc.) como la especialidad (por ejemplo: telecomunicaciones, bases de
datos, cliente/servidor). Para proyectos relativamente pequeos (una persona-ao o
menos) una sola persona puede llevar a cabo todos los pasos de ingeniera del software,
consultando con especialistas siempre que sea necesario.
Recursos de entorno
El entorno es donde se apoya el proyecto de software, llamado a menudo entorno de
ingeniera del software (ElS), incorpora hardware y software. El hardware proporciona
una plataforma con las herramientas (software) requeridas para producir los productos
que son el resultado de una buena prctica de la ingeniera del software7
. Como la mayora de las organizaciones de software tienen muchos aspectos que
requieren acceso a EIS, un planificador de proyecto debe determinar la ventana temporal
requerida para el hardware y el software, y verificar que estos recursos estarn
disponibles.

Herramientas Automticas de Estimacin

Las tcnicas de descomposicin y los modelos empricos de estimacin descritos en las
secciones anteriores se pueden implementar con software. Las herramientas automticas
de estimacin permiten al planificador estimar costes y esfuerzos, as como llevar a cabo
anlisis del tipo qu pasa si con importantes variables del proyecto, tales como la fecha
de entrega o la seleccin de persona. Aunque existen muchas herramientas automticas
de estimacin, todas exhiben las mismas caractersticas generales y todas realizan las seis
funciones genricas mostradas a continuacin:
1. Dimensionamiento de las entregas del proyecto. Se estima el tamao de uno o
ms productos de software. Los productos incluyen la representacin externa del
software (por ejemplo, pantallas, informes), el software en s (por ejemplo, KLDC), su
funcionalidad (por ejemplo, puntos de funcin), Y la informacin descriptiva (por
ejemplo, documentos).
2. Seleccin de las actividades del proyecto. Se selecciona el marco de trabajo del
proceso adecuado
3. Prediccin de los niveles de la plantilla. Se especifica el nmero de personas
disponibles para realizar el trabajo. Esto es muy importante, puesto que la relacin entre
las personas disponibles y el trabajo (esfuerzo previsto) no son muy lineal.
4. Prediccin del esfuerzo del software. Las herramientas de estimacin utilizan uno o
ms modelos que relacionan el tamao de las entregas del proyecto con el esfuerzo
necesario para producirlas.
5. Prediccin del coste del software. Dado los resultados del paso 4, los costes pueden
calcularse asignando proporciones del trabajo a las actividades del proyecto sealadas
en el paso 2.
6. Prediccin de la planificacin del software. Cuando se conoce el esfuerzo, los
niveles de la plantilla y las actividades del proyecto, se puede realizar un borrador de la
planificacin asignando el trabajo a travs

GESTIN DEL RIESGO

Estrategias de riesgo proactivas vs. Reactivas
Las estrategias se han denominado humorsticamente Escuela de gestin del riesgo de
Indiana Jones. En las pelculas, Indiana Jones, cuando se enfrentaba a una dificultad
insuperable, siempre deca, No te preocupes, pensar en algo!. Nunca se preocupaba
de los problemas hasta que ocurran, entonces Indy reaccionaba de alguna manera
heroica.
Una estrategia considerablemente ms inteligente para el control del riesgo es ser
proactivo. La estrategia proactiva empieza mucho antes de que comiencen los trabajos
tcnicos. Se identifican los riesgos potenciales, se evala su probabilidad y su impacto y
se establece una prioridad segn su importancia. Despus, el equipo de Software establece
un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se
pueden evitar todos los riesgos, el equipo trabaja para desarrollar un plan de contingencia
que le permita responder de una manera eficaz y controlada.
Aunque ha habido amplios debates sobre la definicin adecuada para riesgo de software,
hay acuerdo comn en que el riesgo siempre implica dos caractersticas:
Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede
ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de probabilidad'.
Prdida: si el riesgo se convierte en una realidad, ocurrirn consecuencias no
deseadas o prdidas. Cuando se analizan los riesgos es importante cuantificar el
nivel de incertidumbre y el grado de prdidas asociado con cada riesgo. Para
hacerlo, se consideran diferentes categoras de riesgos.
Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del
proyecto se hacen realidad, es probable que la planificacin temporal del proyecto se
retrase y que los costes aumenten. Los riesgos del proyecto identifican los problemas
potenciales de presupuesto, planificacin temporal, personal (asignacin y organizacin),
recursos, cliente y requisitos y su impacto en un proyecto de software. La complejidad
del proyecto, tamao y el grado de incertidumbre estructural fueron tambin definidos
como factores (y estimados) de riesgo del proyecto.
Los riesgos tcnicos amenazan la calidad y la planificacin temporal del software que hay
que producir. Si un riesgo tcnico se convierte en realidad, la implementacin puede
llegar a ser difcil o imposible. Los riesgos tcnicos identifican problemas potenciales de
diseo, implementacin, de interfaz, verificacin y de mantenimiento.
Los riesgos del negocio amenazan la viabilidad del software a construir. Los riesgos del
negocio a menudo ponen en peligro el proyecto o el producto. Los candidatos para los
cinco principales riesgos del negocio son:
1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo
de mercado);
2. Construir un producto que no encaja en la estrategia comercial general de la
compaa (riesgo estratgico);
3. Construir un producto que el departamento de ventas no sabe cmo vender;
4. perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios
de personal (riesgo de direccin);
5. perder presupuesto o personal asignado (riesgos de presupuesto).

Identificacin del riesgo

La identificacin del riesgo es un intento sistemtico para especificar las amenazas al plan
del proyecto (estimaciones, planificacin temporal, carga de recursos, etc.). Identificando
los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para
evitarlos cuando sea posible y controlarlos cuando sea necesario.
Un mtodo para identificar riesgos es crear una lista de comprobacin de elementos de
riesgo. La lista de comprobacin se puede utilizar para identificar riesgos y se centra en
un subconjunto de riesgos conocidos y predecibles en las siguientes subcategoras
genricas:
Tamao del producto: riesgos asociados con el tamao general del software a
construir o a modificar.
Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la
gestin o por el mercado.
Caractersticas del cliente: riesgos asociados con la sofisticacin del cliente y la
habilidad del desarrollador para comunicarse con el cliente en los momentos
oportunos.
Definicin del proceso: riesgos asociados con el grado de definicin del proceso
del software y su seguimiento por la organizacin de desarrollo.
Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las
herramientas que se van a emplear en la construccin del producto.
Tecnologa a construir: riesgos asociados con la complejidad del sistema a
construir y la tecnologa punta que contiene el sistema.
Tamao y experiencia de la plantilla: riesgos asociados con la experiencia
tcnica y de proyectos de los ingenieros del software que van a realizar el trabajo.
 Proyeccin del riesgo
La proyeccin del riesgo, tambin denominada estimacin del riesgo, intenta medir cada
riesgo de dos maneras -la probabilidad de que el riesgo sea real y las consecuencias de
los problemas asociados con el riesgo, si ocurriera-. El jefe del proyecto, junto con otros
gestores y personal tcnico, realiza cuatro actividades de una de riesgo de proyeccin del
riesgo:
(1) establecer una escala que refleje la probabilidad percibida del riesgo;
(2) definir las consecuencias del riesgo;
(3) estimar el impacto del riesgo en el proyecto y en el producto, y
(4) apuntar la exactitud general de la proyeccin del riesgo de manera que no haya
confusiones.

Evaluacin del impacto del .riesgo

Tres factores afectan a las consecuencias probables de un riesgo si ocurre: su naturaleza,
su alcance y cuando ocurre. La naturaleza del riesgo indica los problemas probables que
aparecern si ocurre. Por ejemplo, una interfaz externa mal definida para el hardware del
cliente (un riesgo tcnico) impedir un diseo y pruebas tempranas y probablemente lleve
a problemas de integracin ms adelante en el proyecto. El alcance de un riesgo combina
la severidad (cmo de serio es el problema?) con su distribucin general (qu
proporcin del proyecto se ver afectado y cuantos clientes se vern perjudicados?).
Finalmente, la temporizacin de un riesgo considera cundo y por cunto tiempo se dejar
sentir el impacto. En la mayora de los casos, un jefe de proyecto prefiere las malas
noticias cuanto antes, pero en algunos casos, cuanto ms tarden, mejor.
 PLANIFICACIN TEMPORAL Y SEGUIMIENTO DEL PROYECTO.
Aunque hay muchas razones por las que el software se entrega tarde, la mayora
pertenecen a una o ms de las siguientes causas:
Una fecha lmite de entrega poco realista, establecida por alguien que no pertenece
al grupo de ingeniera del software e impuesta a los gestores y profesionales del
grupo.
Cambio de los requisitos del cliente que no se reflejan en los cambios de la
planificacin temporal.
Una subestimacin honesta de la cantidad de esfuerzo y/o el nmero de recursos que
sern necesarios para hacer el trabajo.
Riesgos predecibles y no predecibles que no se consideraron cuando comenz el
proyecto.
Dificultades tcnicas que no pudieron ser previstas por adelantado.
Dificultades humanas que no pudieron ser previstas por adelantado.
Falta de comunicacin entre la plantilla del proyecto que causa retrasos.
Falta de reconocimiento por parte de la gestin del proyecto de su retraso y falta de
medidas para corregir el problema.
Las fechas lmite de entrega agresivas (lase poco realistas), son un hecho consumado
en el mundo del software. Algunas veces estas fechas lmite se piden por motivos
legtimos desde el punto de vista de la persona que las establece, pero el sentido comn
tambin dice que la legitimidad debe ser percibida por las personas que hacen el trabajo.

CONTROL DE CALIDAD DEL SOFTWARE

Concepto del Calidad
Se dice que dos copos de nieve no son iguales. Ciertamente cuando se observa caer la
nieve, es difcil imaginar que son totalmente diferentes, por no mencionar que cada copo
posee una estructura nica. Para observar las diferencias entre los copos de nieve,
debemos examinar los especmenes muy de cerca, y quiz con un cristal de aumento. En
efecto, cuanta ms cerca los observemos, ms diferencias podremos detectar.
Este fenmeno, variacin entre muestras, se aplica a todos los productos del hombre as
como a la creacin natural. Por ejemplo, si dos tarjetas de circuito idnticas se
examinan muy de cerca, podremos observar que las lneas de cobre sobre las tarjetas
difieren ligeramente en la geometra, colocacin y grosor. Adems, la localizacin y el
dimetro de los orificios de las tarjetas tambin varan.

Calidad
El American HeritageDictionary, define la calidad como una caracterstica o atributo de
algo. Como un atributo de un elemento, la calidad se refiere a las caractersticas
mensurables C0S3S que se pueden comparar con estndares conocidos como longitud,
color, propiedades elctricas, maleabilidad, etc.. Sin embargo, el software en su gran
extensin, como entidad intelectual, es ms difcil de caracterizar que los objetos fsicos.
No obstante, si existen las medidas de caractersticas de un programa. Entre estas
propiedades se incluyen complejidad ciclomtica. Cohesin, nmero de puntos de
funcin, lneas de cdigo y muchas otras estudiadas en los Captulos 19y 24. Cuando se
examina un elemento segn sus caractersticas mensurables, se pueden encontrar dos
tipos de calidad: calidad del diseo y calidad de concordancia.

Control de calidad
El control de cambios puede equipararse al control de calidad. Pero, cmo se logra el
control de calidad? El control de calidad es una serie de inspecciones, revisiones y pruebas
utilizadas a lo largo del proceso del software para asegurar que cada producto cumple con
los requisitos que le han sido asignados. El control de calidad incluye un bucle de
realimentacin (feedback) del proceso que cre el producto. La combinacin de medicin
y realimentacin permite afinar el proceso cuando los productos de trabajo creados fallan
al cumplir sus especificaciones. Este enfoque ve el control de calidad como parte del
proceso de fabricacin.

Coste de calidad
El coste de calidad incluye todos los costes acarreados en la bsqueda de la calidad o en
las actividades relacionadas en la obtencin de la calidad. Se realizan estudios sobre el
coste de calidad para proporcionar una lnea base del coste actual de calidad, para
identificar oportunidades de reducir este coste, y para proporcionar una base normalizada
de comparacin. La base de normalizacin siempre tiene un precio. Una vez que se han
normalizado los costes de calidad sobre un precio base, tenemos los datos necesarios para
evaluar el lugar en donde hay oportunidades de mejorar nuestros procesos. Es ms,
podemos evaluar cmo afectan los cambios en trminos de dinero.

Los costes de calidad se pueden dividir en costes asociados con la prevencin, la

evaluacin y los fallos. Entre los costes de prevencin se incluyen:

Planificacin de la calidad,
Revisiones tcnicas formales,
Equipo de pruebas,
Formacin.

Bibliografa
o Libro:
Ingeniera De Software / Un Enfoque Prctico/ Roger S. Pressman
o Biblioteca Virtual:
http://site.ebrary.com/lib/uagrariaecsp/detail.action?docID=10646149&p00
http://site.ebrary.com/lib/uagrariaecsp/detail.action?docID=10853350&p00