CURSO DE ESPECIALIZACION EN INGENIERIA DE SISTEMAS

MODULO: ANALISIS DE SISTEMAS

CODIGO: CEIS - 04

TEMA: INGENIERIA DEL SOFTWARE (NORMAS, CALIDAD Y PRUEBAS)

INTRODUCCION

La calidad de los productos de software y del proceso de desarrollo de stos es un

componente fundamental en el xito de los proyectos de software. Consecuentemente con
lo anterior, este tema se enfoca en tres aspectos cruciales para el logro de tal objetivo: las
Normas, la Calidad y las Pruebas en el proceso de desarrollo de software a travs de la
profundizacin de conceptos y el intercambio de experiencias y buenas prcticas entre los
participantes.

CONTENIDOS MINIMOS

I.- El Producto
II.- El Proceso
III.- Conceptos sobre Gestin de Proyectos
IV.- Mtricas de Proyectos
V.- Planificacin de Proyectos
VI.- Garanta de Calidad del Software
VII.- Tcnicas de Pruebas del Software

OBJETIVO DEL MODULO

Proporcionar a los estudiantes una slida y actualizada formacin en aspectos claves para
el desarrollo exitoso de soluciones de software asegurando la calidad del producto.

PROGRAMA ACADEMICO

I.- El Producto

El software de computadora se ha convertido en el alma mater. Es la mquina que

conduce a la toma de decisiones comerciales. Sirve de base para la investigacin
cientfica moderna y de resolucin de problemas de ingeniera. Es el factor clave que
diferencia los productos y servicios modernos. Est inmerso en sistemas de todo tipo: de
transportes, mdicos, de telecomunicaciones, militares, procesos industriales,
entretenimientos, productos de oficina, etc. la lista es casi interminable. El software es casi
ineludible en un mundo moderno. A medida que nos adentremos ms en el siglo XXI, ser
el que nos conduzca a nuevos avances en todo, desde la educacin elemental a la
ingeniera gentica.

1.1.- La Evolucin del Software

Hoy en da el software tiene un doble papel. Es un producto y al mismo tiempo, el vehculo
para entregarlo. Como producto, hace entrega de la potencia informtica que incorpora el
hardware informtico. Si reside dentro de un telfono celular u opera dentro de una
computadora central, el software es un transformador de informacin, produciendo,
gestionando, adquiriendo, modificando, mostrando o transmitiendo informacin que puede
ser tan simple como un solo bit o tan complejo como una presentacin en multimedia.

Como vehculo utilizado para hacer entrega del producto, el software acta como la base
de control de la computadora (sistemas operativos), la comunicacin de informacin
(redes) y la creacin y control de otros programas (herramientas de software y entornos).

El papel del software informtico ha sufrido un cambio significativo durante un periodo de

tiempo superior a 50 aos. Enormes mejoras en rendimiento del hardware, profundos
cambios de arquitecturas informticas, grandes aumentos de memoria y capacidad de
almacenamiento y una gran variedad de opciones de entrada y salida han conducido a
sistemas ms sofisticados y ms complejos basados en computadora. La sofisticacin y la
complejidad pueden producir resultados deslumbrantes cuando un sistema tiene xito,
pero tambin pueden suponer grandes problemas para aquellos que deben construir
sistemas complejos.

El programador solitario de antao ha sido reemplazado por un equipo de especialistas del

software, cada uno centrado en una parte de la tecnologa requerida para entregar una
aplicacin concreta.

Y de este modo, las cuestiones que se preguntaba el programador solitario son las
mismas cuestiones que nos preguntamos cuando construimos sistemas modernos
basados en computadoras:
Por qu lleva tanto tiempo terminar los programas?
Por qu son tan elevados los costes de desarrollo?
Por qu no podemos encontrar todos los errores antes de entregar el software a
nuestros clientes?
Por qu nos resulta difcil constatar el progreso conforme se desarrolla el
software?

1.2.- El Software
En 1970, menos del uno por ciento de las personas podra haber descrito inteligentemente
lo que significaba software de computadora. Hoy, la mayora de los profesionales y
muchas personas en general piensan en su mayora que comprenden el software. Pero
lo entienden realmente?

Caractersticas del software

Para poder comprender lo que es el software (y consecuentemente la ingeniera del
software), es importante examinar las caractersticas del software que lo diferencian de
otras cosas que los hombres pueden construir.
Cuando se construye hardware, el proceso creativo humano (anlisis, diseo,
construccin, prueba) se traduce finalmente en una forma fsica. Si construimos una nueva
computadora, nuestro boceto inicial, diagramas formales de diseo y prototipo de prueba,
evolucionan hacia un producto fsico (chips, tarjetas de circuitos impresos, fuentes de
potencia, etc.).

El software es un elemento del sistema que es lgico, en lugar de fsico. Por tanto el
software tiene unas caractersticas considerablemente distintas a las del hardware:
1. El software se desarrolla, no se fabrica en un sentido clsico.
2. El software no se estropea.
3. Aunque la industria tiende a ensamblar componentes, la mayora del software se
construye a medida.

Aplicaciones del software

El software puede aplicarse en cualquier situacin en la que se haya definido previamente
un conjunto especfico de pasos procedimentales (es decir, un algoritmo) (excepciones
notables a esta regla son el software de los sistemas expertos y de redes neuronales).

El contenido y el determinismo de la informacin son factores importantes a considerar

para determinar la naturaleza de una aplicacin de software. El contenido se refiere al
significado y a la forma de la informacin de entrada y salida. Por ejemplo, muchas
aplicaciones bancarias usan unos datos de entrada muy estructurados (una base de
datos) y producen informes con determinados formatos.

El software que controla una mquina automtica (por ejemplo: un control numrico)
acepta elementos de datos discretos con una estructura limitada y produce rdenes
concretas para la mquina en rpida sucesin.

Algunas veces es difcil establecer categoras genricas para las aplicaciones del software
que sean significativas. Conforme aumenta la complejidad del software, es ms difcil
establecer compartimentos ntidamente separados. Las siguientes reas del software
indican la amplitud de las aplicaciones potenciales:
Software de sistemas.
Software de tiempo real.
Software de gestin.
Software de ingeniera y cientfico.
Software empotrado.
Software de computadoras personales.
Software basado en Web.
Software de inteligencia artificial.

1.3.- La Crisis del Software

Muchos observadores de la industria han caracterizado los problemas asociados con el
desarrollo del software como una crisis. Ms de unos cuantos libros han recogido el
impacto de algunos de los fallos ms importantes que ocurrieron durante la dcada
pasada. No obstante, los mayores xitos conseguidos por la industria del software han
llevado a preguntarse si el trmino (crisis del software) es an apropiado.

Robert Glass, autor de varios libros sobre fallos del software, representa a aquellos que
han sufrido un cambio de pensamiento. Expone: Puedo ver en mis ensayos histricos de
fallos y en mis informes de excepcin, fallos importantes en medio de muchos xitos, una
copa que est [ahora] prcticamente llena.

La palabra crisis se define en el diccionario Webster como un punto decisivo en el curso

de algo, momento, etapa o evento decisivo o crucial. Sin embargo, en trminos de
calidad del software total y de velocidad con la cual son desarrollados los productos y los
sistemas basados en computadoras, no ha habido ningn punto crucial, ningn
momento decisivo, solamente un lento cambio evolutivo, puntualizado por cambios
tecnolgicos explosivos en las disciplinas relacionadas con el software.

Cualquiera que busque la palabra crisis en el diccionario encontrar otra definicin: el

punto decisivo en el curso de una enfermedad, cuando se ve ms claro si el paciente
vivir o morir. Esta definicin puede darnos una pista sobre la verdadera naturaleza de
los problemas que han acosado el desarrollo del software.

Lo que realmente tenemos es una afliccin crnica. La palabra afliccin se define como
algo que causa pena o desastre. Pero la clave de nuestro argumento es la definicin del
adjetivo crnica: muy duradero o que reaparece con frecuencia continuando
indefinidamente. Es bastante ms preciso describir los problemas que hemos estado
aguantando en el negocio del software como una afliccin crnica, en vez de como una
crisis.

Sin tener en cuenta como lo llamemos, el conjunto de problemas encontrados en el

desarrollo del software de computadoras no se limitan al software que no funciona
correctamente. Es ms, el mal abarca los problemas asociados a cmo desarrollar
software, cmo mantener el volumen cada vez mayor de software existente y cmo poder
esperar mantenemos al corriente de la demanda creciente de software.

1.4.- Mitos del Software

Muchas de las causas de la crisis del software se pueden encontrar en una mitologa que
surge durante los primeros aos del desarrollo del software. A diferencia de los mitos
antiguos, que a menudo proporcionaban a los hombres lecciones dignas de tener en
cuenta, los mitos del software propagaron informacin errnea y confusin.

Los mitos del software tienen varios atributos que los hacen insidiosos: por ejemplo,
aparecieron como declaraciones razonables de hechos (algunas veces conteniendo
elementos verdaderos), tuvieron un sentido intuitivo y frecuentemente fueron promulgados
por expertos que estaban al da.

Mitos de gestin.
Mito. Tenemos ya un libro que est lleno de estndares y procedimientos para
construir software, no le proporciona ya a mi gente todo lo que necesita saber?
 Mito. Mi gente dispone de las herramientas de desarrollo de software ms avanzadas,
despus de todo, les compramos las computadoras ms modernas.
Mito. Si fallamos en la planificacin, podemos aadir ms programadores y adelantar
el tiempo perdido (el llamada algunas veces concepto de la horda Mongoliana).
Mitos del Cliente.
Mito. Una declaracin general de los objetivos es suficiente para comenzar a escribir
los programas podemos dar los detalles ms adelante-.
Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden
acomodarse fcilmente, ya que el software es flexible.

Mitos de los desarrolladores.

Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha
terminado.
Mito. Hasta que no tengo el programa ejecutndose, realmente no tengo forma de
comprobar su calidad.
Mito. Lo nico que se entrega al terminar el proyecto es el programa funcionando.

II.- El Proceso

2.1.- La Ingeniera del Software

Aunque cientos de autores han desarrollado definiciones personales de la ingeniera del
software, una definicin propuesta por Fritz Bauer en una conferencia de gran influencia
sobre estos temas va a servir como base de estudio: La ingeniera del software es el
establecimiento y uso de principios robustos de la ingeniera a fin de obtener
econmicamente software que sea fiable y que funcione eficientemente sobre
mquinas reales.

El IEEE ha desarrollado una definicin ms completa: Ingeniera del software: (1) La

aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el
desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de
ingeniera al software.

La Ingeniera del software es una tecnologa multicapa. Cualquier enfoque de ingeniera

(incluida ingeniera del software) debe apoyarse sobre un compromiso de organizacin de
calidad. El fundamento de la ingeniera del software es la capa de proceso. Los mtodos
de la ingeniera del software indican cmo construir tcnicamente el software. Las
herramientas de la Ingeniera del software proporcionan un enfoque automtico o
semiautomtico para el proceso y para los mtodos.

El trabajo que se asocia a la ingeniera del software se puede dividir en tres fases
genricas, con independencia del rea de aplicacin, tamao o complejidad del proyecto.
Cada fase se encuentra con una o varias cuestiones de las destacadas anteriormente.

La fase de definicin se centra sobre el qu. Aunque los mtodos aplicados durante la
fase de definicin variarn dependiendo del paradigma de ingeniera del software (o
combinacin de paradigmas) que se aplique, de alguna manera tendrn lugar tres tareas
principales: ingeniera de sistemas o de informacin, planificacin del proyecto del
software y anlisis de los requisitos.

La fase de desarrollo se centra en el cmo. Los mtodos aplicados durante la fase de

desarrollo variarn, aunque las tres tareas especficas tcnicas deberan ocurrir siempre:
diseo del software, generacin de cdigo y prueba del software.

La fase de mantenimiento se centra en el cambio que va asociado a la correccin de

errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y
a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente.

Durante la fase de mantenimiento se encuentran cuatro tipos de cambios:

Correccin
Adaptacin
Mejora
Prevencin

Adems de estas actividades de mantenimiento, los usuarios de software requieren un

mantenimiento continuo. Los asistentes tcnicos a distancia, telfonos de ayuda y sitios
Web de aplicaciones especficas se implementan frecuentemente como parte de la fase de
mantenimiento.

2.2.- 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
calidad- que permiten que las actividades del marco de trabajo se adapten a las
caractersticas del proyecto del software y a los requisitos del equipo del proyecto.

Finalmente, las actividades de proteccin -tales como garanta de calidad del software,
gestin de configuracin del software y medicin abarcan el modelo de procesos. Las
actividades de proteccin son independientes de cualquier actividad del marco de trabajo y
aparecen durante todo el proceso.

2.3.- Modelos de Proceso del 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, capas de herramientas y las fases genricas discutidas anteriormente. 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.

2.4.- El Producto y el Proceso

Si el proceso es dbil, el producto final va a sufrir indudablemente. Aunque una
dependencia obsesiva en el proceso tambin es peligrosa.

Las personas obtienen tanta satisfaccin (o ms) del proceso creativo que del producto
final. Un artista disfruta con las pinceladas de la misma forma que disfruta del resultado
enmarcado. Un escritor disfruta con la bsqueda de la metfora adecuada al igual que con
el libro final. Un profesional creativo del software debera tambin obtener tanta
satisfaccin de la programacin como del producto final.

El trabajo de los profesionales del software cambiar en los prximos aos. La dualidad de
producto y proceso es un elemento importante para mantener ocupada a la gente creativa
hasta que se finalice la transicin de la programacin a la ingeniera del software.

III.- Conceptos Sobre Gestin de Proyectos

La gestin de proyectos implica la planificacin, supervisin y control del personal, del

proceso y de los eventos que ocurren mientras evoluciona el software desde la fase
preliminar a la implementacin operacional.

Todos gestionamos de algn modo, pero el mbito de las actividades de gestin vara en
funcin de la persona que las realiza. Un Ingeniero de Software gestiona sus actividades
del da a da, planificando, supervisando y controlando las tareas tcnicas. Los Gestores
del Proyecto planifican, supervisan y controlan el trabajo de un equipo de ingenieros de
software. Los gestores expertos coordinan la relacin entre el negocio y los profesionales
del software.
La gestin de proyectos es importante porque el desarrollo de software es una empresa
compleja, particularmente si participa mucha gente trabajando durante un periodo de
tiempo relativamente largo. Esta es la razn por la cual los proyectos de software
necesitan ser gestionados.

3.1.- El mbito de la Gestin

La gestin eficaz de un proyecto de software se centra en las cuatro Ps: personal,
producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el
trabajo de ingeniera del software es un esfuerzo humano intenso nunca tendr xito en la
gestin de proyectos. Un gestor que no fomenta una minuciosa comunicacin con el
cliente al principio de la evolucin del proyecto se arriesga a construir una elegante
solucin para un problema equivocado.

El administrador que presta poca atencin al proceso corre el riesgo de arrojar mtodos
tcnicos y herramientas eficaces al vaco. El gestor que emprende un proyecto sin un plan
slido arriesga el xito del producto

3.2.- Personal
La necesidad de contar con personal para el desarrollo del software altamente preparado y
motivado se viene discutiendo desde los aos 60. De hecho, el factor humano es tan
importante que el Instituto de Ingeniera del Software ha desarrollado un Modelo de
madurez de la capacidad de gestin de personal (MMCGP) para aumentar la preparacin
de organizaciones del software para llevar a cabo las cada vez ms complicadas
aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento
necesario para mejorar su capacidad de desarrollo de software.

El modelo de madurez de gestin de personal define las siguientes reas clave prcticas
para el personal que desarrolla software: reclutamiento, seleccin, gestin de rendimiento,
entrenamiento, retribucin, desarrollo de la carrera, diseo de la organizacin y del trabajo
y desarrollo cultural y de espritu de equipo.

3.3.- Producto
Antes de poder planificar un proyecto, se deberan establecer los objetivos y el mbito del
producto, se deberan considerar soluciones alternativas e identificar las dificultades
tcnicas y de gestin. Sin esta informacin, es imposible definir unas estimaciones
razonables (y exactas) del coste; una valoracin efectiva del riesgo, una subdivisin
realista de las tareas del proyecto o una planificacin del proyecto asequible que
proporcione una indicacin fiable del progreso.

El desarrollador de software y el cliente deben reunirse para definir los objetivos del
producto y su mbito. En muchos casos, esta actividad empieza como parte del proceso
de ingeniera del sistema o del negocio y contina como el primer paso en el anlisis de
los requisitos del software. Los objetivos identifican las metas generales del proyecto sin
considerar cmo se conseguirn (desde el punto de vista del cliente).

El mbito identifica los datos primarios, funciones y comportamientos que caracterizan al

producto, y, ms importante, intenta abordar estas caractersticas de una manera
cuantitativa. Una vez que se han entendido los objetivos y el mbito del producto, se
consideran soluciones alternativas.

3.4.- Proceso
Un proceso de software proporciona la estructura desde la que se puede establecer un
detallado plan para el desarrollo del software. Un pequeo nmero de actividades
estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su
tamao o complejidad. Diferentes conjuntos de tareas -tareas, hitos, productos del trabajo
y puntos de garanta de calidad- permiten a las actividades estructurales adaptarse a las
caractersticas del proyecto de software y a los requisitos del equipo del proyecto.

Finalmente, las actividades protectoras -tales como garanta de calidad del software,
gestin de la configuracin del software y medicin cubren el modelo de proceso. Las
actividades protectoras son independientes de las estructurales y tienen lugar a lo largo
del proceso.

3.5.- Proyecto
Dirigimos los proyectos de software planificados y controlados por una razn principal -es
la nica manera conocida de gestionar la complejidad-. Y todava seguimos
esforzndonos.

En 1998, los datos de la industria del software indicaron que el 26 por 100 de proyectos de
software fallaron completamente y que el 46 por 100 experimentaron un desbordamiento
en la planificacin y en el coste. Aunque la proporcin de xito para los proyectos de
software ha mejorado un poco, nuestra proporcin de fracaso de proyecto permanece ms
alto del que debera ser.

Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de
software que construyeron el producto deben eludir un conjunto de seales de peligro
comunes; comprender los factores del xito crticos que conducen a la gestin correcta del
proyecto y desarrollar un enfoque de sentido comn para planificar, supervisar y controlar
el proyecto.

IV.- 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 y para ayudar en la toma de decisiones
tctica a medida que el proyecto evoluciona.

El proceso del software y las mtricas del producto son una medida cuantitativa que
permite a la gente del software tener una visin profunda de la eficacia del proceso del
software y de los proyectos que dirigen utilizando el proceso como un marco de trabajo.
Se renen los datos bsicos de calidad y productividad. Estos datos son entonces
analizados, comparados con promedios anteriores y evaluados para determinar las
mejoras en la calidad y productividad. Las mtricas son tambin utilizadas para sealar
reas con problemas de manera que se puedan desarrollar los remedios y mejorar el
proceso de software.

4.1.- 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 IEEE Standard Glossary of Software

Engineering Terms define mtrica como una medida cuantitativa del grado en que un
sistema, componente o proceso posee un atributo dado.

Cuando, simplemente, se ha recopilado un solo aspecto de los datos (por ejemplo: el

nmero de errores descubiertos en la revisin de un mdulo), se ha establecido una
medida. La medicin aparece como resultado de la recopilacin de uno o varios aspectos
de los datos (por ejemplo: se investiga un nmero de revisiones de mdulos para recopilar
medidas del nmero de errores encontrados durante cada revisin).

Una mtrica del software relata de alguna forma las medidas individuales sobre algn
aspecto (por ejemplo: el nmero medio de errores encontrados por revisin o el nmero
medio de errores encontrados por persona y hora en revisiones).
Un ingeniero del software recopila medidas y desarrolla mtricas para obtener indicadores.
Un indicador es una mtrica o una combinacin de mtricas que proporcionan una visin
profunda del proceso del software, del proyecto de software o del producto en s. Un
indicador proporciona una visin profunda que permite al gestor de proyectos o a los
ingenieros de software ajustar el producto, el proyecto o el proceso para que las cosas
salgan mejor.

Por ejemplo, cuatro equipos de software estn trabajando en un proyecto grande de

software. Cada equipo debe conducir revisiones del diseo, pero puede seleccionar el tipo
de revisin que realice.

Sobre el examen de la mtrica, errores encontrados por persona- hora consumidas, el

gestor del proyecto notifica que dos equipos que utilizan mtodos de revisin ms
formales presentan un 40 por 100 ms de errores encontrados por persona hora
consumidas que otros equipos.

Suponiendo que todos los parmetros son iguales, esto proporciona al gestor del proyecto
un indicador en el que los mtodos de revisin ms formales pueden proporcionar un
ahorro mayor en inversin de tiempo que otras revisiones con un enfoque menos formal.
Esto puede sugerir que todos los equipos utilicen el enfoque ms formal. La mtrica
proporciona al gestor una visin ms profunda. Y adems le llevar a una toma de
decisiones ms fundamentada.

4.2.- Mtricas en el Proceso y en el Dominio 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.

Se deberan recopilar mtricas para que los indicadores del proceso y del producto
puedan ser ciertos. Los indicadores de proceso permiten a una organizacin de ingeniera
del software tener una visin profunda de la eficacia de un proceso ya existente (por
ejemplo: el paradigma, las tareas de ingeniera del software, productos de trabajo e hitos).

Tambin permiten que los gestores evalen lo que funciona y lo que no. Las mtricas del
proceso se recopilan de todos los proyectos y durante un largo perodo de tiempo. Su
intento es proporcionar indicadores que lleven a mejoras de los procesos de soft ware a
largo plazo.

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.

En algunos casos, se pueden utilizar las mismas mtricas del software para determinar
tanto el proyecto como los indicadores del proceso. En realidad, las medidas que recopila
un equipo de proyecto y las convierte en mtricas para utilizarse durante un proyecto
tambin pueden transmitirse a los que tienen la responsabilidad de mejorar el proceso del
software. Por esta razn, se utilizan muchas de las mismas mtricas tanto en el dominio
del proceso como en el del proyecto.
4.3.- Mediciones del Software
Las mediciones del mundo fsico se pueden categorizar de dos maneras; medidas directas
(por ejemplo: la longitud de un tomillo) y medidas indirectas (por ejemplo: la calidad de
los tomillos producidos, medidos contando los artculos defectuosos). Las mtricas del
software se pueden categorizar de forma similar.

Entre las medidas directas del proceso de la ingeniera del software se incluyen el coste y
el esfuerzo aplicados. Entre las medidas directas del producto se incluyen las lneas de
cdigo (LDC) producidas, velocidad de ejecucin, tamao de memoria, y los defectos
informados durante un perodo de tiempo establecido.

Entre las medidas indirectas se incluyen la funcionalidad, calidad, complejidad, eficiencia,

fiabilidad, facilidad de mantenimiento y muchas otras capacidades.

El coste y el esfuerzo requerido para construir el software, el nmero de lneas de cdigo

producidas y otras medidas directas son relativamente fciles de reunir, mientras que los
convenios especficos para la medicin se establecen ms adelante. Sin embargo, la
calidad y funcionalidad del software, o su eficiencia o mantenimiento son ms difciles de
evaluar y slo pueden ser medidas indirectamente.

El dominio de las mtricas del software se divide en mtricas de proceso, proyecto y

producto.

Tambin se acaba de destacar que las mtricas de producto que son privadas para un
individuo a menudo se combinan para desarrollar mtricas del proyecto que sean pbli cas
para un equipo de software.

Las mtricas del proyecto se consolidan para crear mtricas de proceso que sean pblicas
para toda la organizacin del software. Pero cmo combina una organizacin mtricas
que provengan de particulares o proyectos?

Para ilustrarlo, se va a tener en consideracin un ejemplo sencillo. Personas de dos

equipos de proyecto diferentes registran y categorizan todos los errores que se encuentran
durante el proceso del software. Las medidas de las personas se combinan entonces para
desarrollar medidas de equipo. El equipo A encontr 342 errores durante el proceso del
software antes de su realizacin. El equipo B encontr 184.

Considerando que en el resto los equipos son iguales, qu equipo es ms efectivo en

detectar errores durante el proceso? Como no se conoce el tamao o la complejidad de
los proyectos, no se puede responder a esta pregunta.

Sin embargo, si se normalizan las medidas, es posible crear mtricas de software que
permitan comparar medidas ms amplias de otras organizaciones.
Mtricas Orientadas al Tamao
 Mtricas Orientadas a la Funcin
Mtricas ampliadas de punto de funcin

4.4.- Mtricas para la Calidad del Software

El objetivo primordial de la ingeniera del software es producir un sistema, aplicacin o
producto de alta calidad. Para lograr este objetivo, los ingenieros del software deben
aplicar mtodos efectivos junto con herramientas modernas dentro del contexto de un
proceso maduro de desarrollo de software. Adems, un buen ingeniero del software (y
buenos gestores de la ingeniera del software) deben medir si la alta calidad se va a llevar
a cabo.

La calidad de un sistema, aplicacin o producto es tan buena como los requisitos que
describen el problema, el diseo que modela la solucin, el cdigo que conduce a un
programa ejecutable, y las pruebas que ejercitan el software para detectar errores.

Un buen ingeniero del software utiliza mediciones que evalan la calidad del anlisis y los
modelos de diseo, el cdigo fuente, y los casos de prueba que se han creado al aplicar la
ingeniera del software. Para lograr esta evaluacin de la calidad en tiempo real, el
ingeniero debe utilizar medidas tcnicas que evalan la calidad con objetividad, no con
subjetividad. El gestor de proyectos tambin debe evaluar la calidad objetivamente, y no
subjetivamente. A medida que el proyecto progresa el gestor del proyecto tambin debe
evaluar la calidad.

Las mtricas privadas recopiladas por ingenieros del software particulares se asimilan
para proporcionar resultados en los proyectos. Aunque se pueden recopilar muchas
medidas de calidad, el primer objetivo en el proyecto es medir errores y defectos. Las
mtricas que provienen de estas medidas proporcionan una indicacin de la efectividad de
las actividades de control y de la garanta de calidad en grupos o en particulares.

Visin general de los factores que afectan la calidad de un producto

Hace 25 aos, McCall y Cavano definieron un juego de factores de calidad como los
primeros pasos hacia el desarrollo de mtricas de la calidad del software. Estos factores
evalan el software desde tres puntos de vista distintos: (1) operacin del producto
(utilizndolo), (2) revisin del producto (cambindolo), y (3) transicin del producto
(modificndolo para que funcione en un entorno diferente, por ejemplo, portndolo).

Medida de la calidad
Correccin.
Facilidad de mantenimiento.
Integridad.
Facilidad de uso.

V.- Planificacin de Proyectos

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.

5.1.- Objetivos de la Planificacin

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.

5.2.- mbito del Software

La primera actividad de la planificacin del proyecto de software es determinar el mbito
del software. Se deben evaluar la funcin y el rendimiento que se asignaron al software
durante la ingeniera del sistema de computadora, para establecer un mbito de proyecto
que no sea ambiguo, ni incomprensible para directivos y tcnicos. Se debe delimitar la
declaracin del 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.
5.3.- 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.

5.4.- Estimacin del Proyecto de Software

Al principio, el coste del software constitua un pequeo porcentaje del coste total de los
sistemas basados en computadora. Un error considerable en las estimaciones del coste
del software tena relativamente poco impacto.

Hoy en da, el software es el elemento ms caro de la mayora de los sistemas

informticos. Para sistemas complejos, personalizados, un gran error en la estimacin del
coste puede ser lo que marque la diferencia entre beneficios y prdidas. Sobrepasarse en
el coste puede ser desastroso para el desarrollador.

La estimacin del coste y del esfuerzo del software nunca ser una ciencia exacta. Son
demasiadas las variables humanas, tcnicas, de entorno, polticas- que pueden afectar al
coste final del software y al esfuerzo aplicado para desarrollarlo.
Sin embargo, la estimacin del proyecto de software puede dejar de ser un oscuro arte
para convertirse en una serie de pasos sistemticos que proporcionen estimaciones con
un grado de riesgo aceptable.

5.5.- Tcnicas de Descomposicin

La estimacin de proyectos de software es una forma de resolucin de problemas y, en la
mayora de los casos, el problema a resolver (es decir, desarrollar estimaciones de coste y
de esfuerzo para un proyecto de software) es demasiado complejo para considerarlo como
un todo. Por esta razn, descomponemos el problema, volvindolo a definir como un
conjunto de pequeos problemas (esperando que sean ms manejables).

Anteriormente se estudi el enfoque de descomposicin desde dos puntos de vista

diferentes: descomposicin del problema y descomposicin del proceso. La estimacin
hace uso de una o ambas formas de particionamiento. Pero antes de hacer una
estimacin, el planificador del proyecto debe comprender el mbito del software a construir
y generar una estimacin de su tamao.

5.6.- Modelos Empricos de Estimacin

Un modelo de estimacin para el software de computadora utiliza frmulas derivadas
empricamente para predecir el esfuerzo como una funcin de LDC o PF. Los datos
empricos que soportan la mayora de los modelos de estimacin se obtienen de una
muestra limitada de proyectos. Por esta razn, el modelo de estimacin no es adecuado
para todas las clases de software y en todos los entornos de desarrollo. Por consiguiente,
dos resultados obtenidos de dichos modelos se deben utilizar con prudencia.

5.7.- La Decisin de Desarrollar-Comprar

En muchas reas de aplicacin del software, a menudo es ms rentable adquirir el
software de computadora que desarrollarlo. Los gestores de ingeniera del software se
enfrentan con una decisin desarrollar o comprar que se puede complicar an ms con las
opciones de adquisicin: (1) el software se puede comprar (con licencia) ya desarrollado;
(2) se pueden adquirir componentes de software totalmente experimentado o
parcialmente experimentado

5.8.- 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 personal. 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.
2. Seleccin de las actividades del proyecto.
3. Prediccin de los niveles de la plantilla.
4. Prediccin del esfuerzo del software.
5. Prediccin del coste del software.
6. Prediccin de la planificacin del software.
VI.- Garanta de Calidad del Software

Todas las metodologas y herramientas tienen un nico fin: producir software de gran
calidad
Definiciones de calidad del software
o Concordancia con los requisitos funcionales y de rendimiento explcitamente
establecidos con los estndares de desarrollo explcitamente documentados
y con las caractersticas implcitas que se espera de todo software
desarrollado profesionalmente
o El conjunto de caractersticas de una entidad que le confieren su aptitud
para satisfacer las necesidades expresadas y las implcitas
Conclusiones Sobre las Definiciones:
o Los requisitos del software son la base de las medidas de calidad. La falta de
concordancia con los requisitos es una falta de calidad
o Los estndares o metodologas definen un conjunto de criterios de desarrollo
que guan la forma en que se aplica la ingeniera del software. Si no se sigue
ninguna metodologa siempre habr falta de calidad
o Existen algunos requisitos implcitos o expectativas que a menudo no se
mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de
un buen mantenimiento) que tambin pueden implicar una falta de calidad.

No basta con definir el concepto de calidad del software. Tambin es importante:

Crear un conjunto de actividades que ayuden a garantizar (asegurar) que todo
producto de la ingeniera del software presenta alta calidad.
Llevar a cabo (gestin) las actividades antes definidas para garantizar la calidad
del software.
Llevar a cabo una serie de inspecciones, revisiones y pruebas a lo largo del
proceso del software para asegurar que cada producto cumple con los requisitos
que le han sido asignados (control).

6.1.- Aseguramiento de la Calidad del Software

El aseguramiento de calidad del software es el conjunto de actividades planificadas y
sistemticas necesarias para aportar la confianza en que el producto (software) satisfar
los requisitos dados de calidad.

El aseguramiento de calidad del software se disea para cada aplicacin antes de

comenzar a desarrollarla no despus.
Algunos autores prefieren decir garanta de calidad en vez de aseguramiento.
Garanta, puede confundir con garanta de productos
Aseguramiento pretende dar confianza en que el producto tiene calidad

El aseguramiento de calidad del software est presente en:

Mtodos y herramientas de anlisis, diseo, programacin y prueba
Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo del
software
Estrategias de prueba multiescala
Control de la documentacin del software y de los cambios realizados
Procedimientos para ajustarse a los estndares (y dejar claro cuando se est fuera
de ellos)
Mecanismos de medida (mtricas)
Registro de auditoras y realizacin de informes

Actividades para el aseguramiento de calidad del software:

Mtricas de software para el control del proyecto
Verificacin y validacin del software a lo largo del ciclo de vida, que incluye las
pruebas y los procesos de revisin e inspeccin
La gestin de la configuracin del software

6.2.- Gestin de la Calidad del Software

Definicin: Gestin de la calidad (ISO 9000)
Conjunto de actividades de la funcin general de la direccin que determina la
calidad, los objetivos y las responsabilidades y se implanta por medios tales como
la planificacin de la calidad, el control de la calidad, el aseguramiento (garanta) de
la calidad y la mejora de la calidad, en el marco del sistema de calidad.

Definicin: Poltica de calidad (ISO 9000)

Directrices y objetivos generales de una organizacin, relativos a la calidad, tal
como se expresan formalmente por la alta direccin

La gestin de la calidad se aplica normalmente a nivel de empresa. Tambin puede haber

una gestin de calidad dentro de la gestin de cada proyecto

6.3.- Control de la Calidad del Software

Son las tcnicas y actividades de carcter operativo, utilizadas para satisfacer los
requisitos relativos a la calidad, centradas en dos objetivos fundamentales:
Mantener bajo control un proceso
Eliminar las causas de los defectos en las diferentes fases del ciclo de vida

En general son las actividades para evaluar la calidad de los productos desarrollados
6.4.- Sistema de Calidad
Definicin:
Estructura organizativa, procedimientos, procesos y recursos necesarios para
implantar la gestin de calidad

El sistema de calidad se debe adecuar a los objetivos de calidad de la empresa. La

direccin de la empresa es la responsable de fijar la poltica de calidad y las decisiones
relativas a iniciar, desarrollar, implantar y actualizar el sistema de calidad.

Un sistema de calidad consta de varias partes

Documentacin: Manual de calidad. Es el documento principal para establecer e
implantar un sistema de calidad. Puede haber manuales a nivel de empresa,
departamento, producto, especficos (compras, proyectos,)
Parte fsica: locales, herramientas ordenadores, etc.
Aspectos humanos:
o Formacin de personal
o Creacin y coordinacin de equipos de trabajo
Normativas
o ISO
ISO 9000: Gestin y aseguramiento de calidad (conceptos y
directrices generales)
Recomendaciones externas para aseguramiento de la calidad (ISO
9001, ISO 9002, ISO 9003)
Recomendaciones internas para aseguramiento de la calidad (ISO
9004)
o MALCOM BALDRIGE NATIONAL QUALITY AWARD
o Software Engineering Institute (SEI)
o Capability Maturity Model (CMM) for software

6.5.- Certificacin de la Calidad

Un sistema de certificacin de calidad permite una valoracin independiente que debe
demostrar que la organizacin es capaz de desarrollar productos y servicios de calidad.

Los pilares bsicos de la certificacin de calidad son tres:

Una metodologa adecuada.
Un medio de valoracin de la metodologa.
La metodologa utilizada y el medio de valoracin de la metodologa deben estar
reconocidos ampliamente por la industria.
6.6.- Factores que Determinan la Calidad del Software
Se clasifican en cuatro grupos:

Operaciones del producto: caractersticas operativas

o Correccin (Hace lo que se le pide?).- El grado en que una aplicacin
satisface sus especificaciones y consigue los objetivos encomendados por el
cliente.
o Fiabilidad (Lo hace de forma fiable todo el tiempo?).- El grado que se puede
esperar de una aplicacin lleve a cabo las operaciones especificadas y con
la precisin requerida.
o Eficiencia (Qu recursos hardware y software necesito?).- La cantidad de
recursos hardware y software que necesita una aplicacin para realizar las
operaciones con los tiempos de respuesta adecuados

Operaciones del producto: caractersticas operativas

o Integridad (Puedo controlar su uso?).- El grado con que puede controlarse
el acceso al software o a los datos a personal no autorizado
o Facilidad de uso (Es fcil y cmodo de manejar?).- El esfuerzo requerido
para aprender el manejo de una aplicacin, trabajar con ella, introducir datos
y conseguir resultados

Revisin del producto: capacidad para soportar cambios

o Facilidad de mantenimiento (Puedo localizar los fallos?).- El esfuerzo
requerido para localizar y reparar errores.
o Flexibilidad (Puedo aadir nuevas opciones?).- El esfuerzo requerido para
modificar una aplicacin en funcionamiento.
o Facilidad de prueba (Puedo probar todas las opciones?).- El esfuerzo
requerido para probar una aplicacin de forma que cumpla con lo
especificado en los requisitos

Transicin del producto: adaptabilidad a nuevos entornos

o Portabilidad (Podr usarlo en otra mquina?).- El esfuerzo requerido para
transferir la aplicacin a otro hardware o sistema operativo.
o Reusabilidad (Podr utilizar alguna parte del software en otra aplicacin?).-
Grado en que partes de una aplicacin pueden utilizarse en otras
aplicaciones.
o Interoperabilidad (Podr comunicarse con otras aplicaciones o sistemas
informticos?.- El esfuerzo necesario para comunicar la aplicacin con otras
aplicaciones o sistemas informticos.
6.7.- Mtricas para la Calidad del Software
Es difcil y en algunos casos, imposible desarrollar medidas directas de los factores de
calidad del software

Mtricas para determinar los factores de calidad:

Facilidad de auditoria
Exactitud
Normalizacin de las comunicaciones
Completitud
Concisin
Consistencia
Estandarizacin de los datos
Tolerancia de errores
Eficiencia de la ejecucin
Facilidad de expansin
Generalidad
Independencia del hardware
Instrumentacin
Modularidad
Facilidad de operacin
Seguridad
Auto documentacin
Simplicidad
Independencia del sistema software
Facilidad de traza
Formacin

VII.- Tcnicas de Pruebas del Software

Definiciones.-
Ejecucin de un programa con la intencin de descubrir un error.
Tcnica experimental para la bsqueda de errores en los programas.

Observaciones sobre las definiciones.-

Imposibilidad de pruebas exhaustivas
Impracticable, demasiado costos
Imposible garantizar la ausencia de defectos

7.1.- Tipos de pruebas

Requisitos
 Diseo
Unidad
Integracin
Verificacin / Validacin
Sistema

7.2.- Pruebas segn el Proceso

7.3.- Prueba de Requisitos

Pretende comprobar los tres principales atributos de calidad de los requisitos, con el fin
detectar tantos errores como sea posible y cuanto antes:
Correccin.- Carencia de Ambigedades
Complecin.- Especificacin completa y clara del problema
Consistencia.- Que no haya requisitos contradictorios.

Se propone documentar con una matriz de pruebas de requisitos en la que se lista cada
requisito junto a sus casos de uso y casos de prueba:

Requisito Caso de Uso Casos de Id. Del Validado con

Prueba Prototipo en el Usuario?
que se incluye

7.4.- Pruebas de Diseo

La fase de diseo tiene como objetivo generar un conjunto de especificaciones completas
del sistema que se va a implementar, transformando los requisitos en un plan de
implementacin.

Las pruebas de diseo deben comprobar:

Consistencia
Complecin
Correccin
Factibilidad (Es decir, que el diseo sea realizable)
Trazabilidad (Es decir que podamos navegar desde un requisito hasta el
fragmento del diseo en que ste se encuentra)

7.5.- Pruebas de Unidad

Se prueba cada modulo buscando errores de:
Interfaces de Entrada / Salida
Estructuras de Datos Locales
Clculos
Flujos de Control

7.6.- Pruebas de Integracin

Se prueba la integracin de los mdulos buscando errores:
Comunicacin (Argumentos)
Estructuras de Datos Globales
Tiempos de Respuesta
Efectos Colaterales

Se las puede realizar de forma ascendente o descendente.

7.7.- Pruebas de Validacin/Verificacin

Validacin: Su objetivo es determinar si los requisitos y el sistema final cumplen los
objetivos para los que se construyo el producto, respondiendo as a la pregunta El
producto es Correcto?
Se usan las mismas tcnicas pero con otro objetivo
No hay programas de pruebas, sino solo el cdigo final de la aplicacin
Se prueba el programa completo
Se prueba tambin el rendimiento, capacidad, etc.
Pruebas alfa (desarrolladores), pruebas beta (usuarios)
Verificacin: Su objetivo es determinar si los productos de software de una actividad se
ajustan a los requisitos o a las condiciones impuestas en actividades anteriores. De este
modo, la pregunta a la que responde este proceso es Se est construyendo el producto
correctamente?

7.8.- Pruebas de Sistema

Se aplican para probar:
 Recuperacin del sistema en casos de cadas
Seguridad
Resistencia
Rendimiento

7.9.- Tcnicas de Pruebas

Ayudan de definir conjuntos de casos de pruebas aplicando un cierto criterio. Los casos de
pruebas quedaran determinados por los valores a asignar a las entradas en su ejecucin:
Tcnicas de Caja Blanca.- Criterios basados en el contenido de los mdulos.
Tcnicas de Caja Negra.- Criterios basados en las interfaces y las especificaciones
de los mdulos.

7.10.- Tcnicas de Caja Blanca/Caja Negra

Caja Blanca: El criterio de seleccin de casos de prueba buscar cierta cobertura de:
Caminos independientes
Valores de las condiciones
Bucles dentro y fuera de sus lmites operacionales
Estructuras de datos
Caja Negra: Permiten detectar:
Funcionamiento incorrecto o incompleto
Errores de interface
Errores de acceso a estructura de datos externas
Problemas de rendimiento
Errores de inicio y terminacin