Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Ingeniera de Software
Autor: Ing. Alexandra Aparicio
Revisado y Editado: Ing. Jairo Martnez
ltima Actualizacin:
Ing. Pilar Alexandra Moreno
Diciembre 2012
Ingeniera de Software
Tabla de Contenido
INTRODUCCIN
PRIMERA UNIDAD. INTRODUCCIN A LA INGENIERA DEL
SOFTWARE
INTRODUCCIN
1. EL PRODUCTO
1.1 El producto
1.2 Evolucin del Software
1.3 El software
1.4 Aplicaciones del Software
1.5 Mitos del Software
2. EL PROCESO
2.1 Definicin de Ingeniera del software
2.2 Esquema de la Ingeniera del Software
2.3 Esencia de la Ingeniera del Software
2.4 Procesos, mtodos y herramientas
2.5 El proceso del software
3. MODELOS DE PROCESO DE SOFTWARE
3.1 Modelo lineal secuencial
3.2 Modelo de construccin de prototipos
3.3 Modelo DRA
3.4 Modelos de procesos evolutivos de software
3.5 Modelo de mtodos formales y Tcnicas de cuarta generacin
SEGUNDA UNIDAD. GESTIN Y PLANIFICACIN DE PROYECTOS
SOFTWARE
INTRODUCCIN
1. CONCEPTOS SOBRE GESTIN DE PROYECTOS
1.1 Gestin de proyectos
1.2 Personal
1.3 El producto
1.4 El proceso
1.5 El proyecto
2. EL PROCESO DE SOFTWARE Y MTRICAS DEL PROYECTO
2.1 Mtricas en el proceso y dominios del proyecto
2.2 Mejora estadstica del proceso del software
2.3 Mtricas del proyecto
2.4 Mediciones del software
2.5 Mtricas para la calidad del software
3. PLANIFICACION DE PROYECTOS DE SOFTWARE
3.1 mbito del software y Recursos
2
Pg.
4
6
6
7
7
8
9
9
11
13
13
15
16
17
19
20
20
22
25
27
31
34
34
35
35
36
38
39
40
42
43
45
48
49
53
58
Pg.
59
Ingeniera de Software
3.2 Estimacin del proyecto de software y Tcnicas de
Descomposicin
3.3 Modelos empricos de Estimacin
3.4 Riesgo del Software
3.5 Planificacin temporal del proyecto
TERCERA UNIDAD. CONTROL DE CALIDAD DEL SOFTWARE
INTRODUCCIN
1. GARANTIA DE CALIDAD DEL SOFTWARE
1.1 Conceptos de calidad
1.2 Tendencia de la calidad
1.3 Garanta y aseguramiento de la calidad del software
1.4 Revisiones del software
1.5 Garanta de calidad estadstica, Fiabilidad y Estndar ISO 9001
2. TECNICAS DE PRUEBA DEL SOFTWARE
2.1 Fundamentos de la prueba del software
2.2 Diseo de casos de prueba, pruebas de la caja blanca y del
camino bsico
2.3 Prueba de la estructura de control
2.4 Prueba de caja negra
2.5 Prueba de entornos especializados, arquitecturas y aplicaciones
3. ESTRATEGIAS DE PRUEBA DEL SOFTWARE
3.1 Enfoque estratgico la prueba del software
3.2 Prueba de unidad
3.3 Pruebas de integracin del sistema
3.4 Mtricas tcnicas del software
3.5 Mtricas del modelo del software
RECURSOS DE SOFTWARE LIBRE PARA INGENIERA DEL
SOFTWARE
RECURSOS BIBLIOTECA VIRTUAL UNAD
BIBLIOGRAFA
61
64
70
80
89
89
90
91
94
96
97
101
109
109
111
114
115
116
119
119
124
126
132
139
147
154
157
Ingeniera de Software
INTRODUCCIN
El curso Ingeniera de Software tiene como objetivo desarrollar habilidades y adquirir
capacidades en la utilizacin de mtodos y tcnicas para desarrollar y mantener
software de calidad.
El curso tiene 3 crditos acadmicos los cuales comprenden el estudio independiente y
el acompaamiento tutorial, con el propsito de:
Ingeniera de Software
La ingeniera de software es el proceso de construir aplicaciones de tamao o alcance
prcticos, en las que predomina el esfuerzo del software y que satisfacen los
requerimientos de funcionalidad y desempeo. La ingeniera de software, ofrece
mtodos y tcnicas para desarrollar, mantener, producir y asegurar software de
calidad.
Por tal razn, este curso terico pretende describir los aspectos tcnicos y de gestin
de la Ingeniera de Software, as como de establecer la importancia de la garanta de
calidad del software.
Ingeniera de Software
UNIDAD 1.
INTRODUCCIN A LA INGENIERA
DEL SOFTWARE
INTRODUCCIN
La ingeniera de software es una disciplina que integra procesos, mtodos y
herramientas para el desarrollo de software. Varios son los modelos de procesos que se
han propuesto para la ingeniera de software, cada uno presenta ventajas y
desventajas, pero todos tienen en comn fases genricas que permiten llevar a cabo el
proceso de la ingeniera de software.
OBJETIVOS
GENERAL
ESPECIFICOS
Ingeniera de Software
ESTRUCTURA TEMTICA
1. EL PRODUCTO
1.1 Definicin del Producto Software.
El software es el producto que disean y construyen los ingenieros del software de
cualquier tamao y arquitectura.
El
Software
es
importante
Porque
El producto obtenido
(software)
Desde
El punto de vista
del Ingeniero del
Software
El punto de vista
del Usuario
es
es
El conjunto de programas,
documentos y los datos que
configuran el software de
computadora
La informacin resultante
que hace el mundo mejor.
Ingeniera de Software
Segunda Era
Primeros Aos
1950
1960
Tercera Era
1970
1980
Primeros Aos
El software estaba en su infancia
El software era un aadido
Existan pocos mtodos para la
programacin
No se tenia una planificacin para el
desarrollo del software
Los programadores trataban de hacer
las cosas bien
El software se diseaba a medida
El software era desarrollado y utilizado
por la misma persona u organizacin
(entorno personalizado)
El diseo de software era realizado en
la mente de alguien y no exista
documentacin
Cuarta Era
1990
2003
Segunda era
Aparece la multiprogramacin y los
sistemas multiusuario
Establecimiento del software como
producto y la llegada de las casas de
software
El software se desarrollaba para ser
comercializado
Se empez a distribuir software para
grandes
computadoras
y
minicomputadores
Comenz a extenderse las bibliotecas
de software
El mantenimiento de software comenz
a absorber recursos en una gran
medida.
Comenz una crisis del software porque
la naturaleza personalizada de los
programas
hizo
imposible
su
mantenimiento.
Tercera era
Cuarta era
Complejidad alta en los sistemas Impacto colectivo del software
informticos
Sistemas
operativos
operativos
Sistemas distribuidos
sofisticados , en redes globales y locales
Incorporacin de inteligencia
Aplicaciones de software avanzadas
Ejecucin de funciones concurrentes
Entorno cliente/cliente servidor
Desarrollo de software para redes y Superautopista de informacin y una
comunicaciones
conexin del ciberespacio
Planificacin en el proceso del desarrollo La industria del software es la cuna de la
de software
economa
Tecnologas orientadas a objetos
Tcnicas de cuarta generacin para el
desarrollo de software
Software de redes neuronales
Sistemas expertos e inteligencia artificial
1
Ingeniera de Software
Programacin de realidad virtual y
sistemas multimedia
Algoritmos genticos
Adopcin de prcticas de Ingeniera del
software
1.3 El Software
El software se ha convertido en el elemento clave de la evolucin de los sistemas y
productos informticos, y por tal razn no se puede tomar como slo el conjunto de
programas, instrucciones y estructuras de datos. A continuacin se presentan algunas
caractersticas que permiten visualizar lo que en realidad es el software.
Ingeniera de Software
Software de ingeniera
y cientfico
Software de tiempo
real
Software empotrado
Software para PC
Software de
inteligencia artificial
10
Ingeniera de Software
1.5 Mitos del software
Los mitos de software propagaron informacin errnea y confusin, lo que conllevo a la
crisis del software durante los primeros aos del desarrollo del software.
Mitos de gestin
Una declaracin general de los objetivos es suficiente para comenzar a escribir los
programas.
Los requisitos del proyecto cambian continuamente, pero los cambios pueden
acomodarse fcilmente, ya que el software es flexible.
Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha
terminado.
Hasta que no tengo el programa ejecutndose, realmente no tengo forma de
comprobar su calidad.
Lo nico que se entrega al terminar el proyecto es el programa funcionando.
11
Ingeniera de Software
ACTIVIDADES COMPLEMENTARIAS
1. Muchos autores han tratado el impacto de la era de la informacin. D varios
ejemplos (positivos y negativos) que indiquen el impacto del software en nuestra
sociedad.
2. Escriba un informe que resuma las ventajas recientes en una de las reas de
aplicaciones de software principales. Entre las selecciones potenciales se
incluyen: aplicaciones avanzadas basadas en Web, realidad virtual, redes
neuronales artificiales, interfaces humanas avanzadas y agentes inteligentes.
3. Analice y describa la Realidad para cada uno de los mitos descritos en el
numeral 1.5.
CONSULTAS WEB
http://books.google.com.co/books?id=ytdKQGJ8f_AC&lpg=PA4&ots=hSqsOPw078&
dq=Software%20Myths&pg=PA5 , encuentra un libro con informacin sobre los
mitos del software.
12
Ingeniera de Software
2. EL PROCESO
Es una serie de pasos a seguir para construir un producto o un sistema. El proceso del
software es importante porque proporciona estabilidad, control y organizacin a una
actividad que puede, si no se controla, volverse catica.
2.1 Ingeniera del Software
Ingeniera de software
es
el conjunto
de
Principios
Mtodos
Tcnicas
para
Mantener
Desarrollar
Software
de
Calidad
A nivel internacional, la Ingeniera de Software empieza a tomar un papel fundamental y
como un rea de la Ingeniera. A continuacin se relacionan algunas definiciones de
Ingeniera del Software:
Ingeniera de Software
IEEE
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.
14
Ingeniera de Software
2.2 Esquema de la Ingeniera del Software
15
Ingeniera de Software
2.3 Esencia de la Ingeniera del Software
Tomada de http://www.um.es/docencia/barzana/IAGP/IAGP2-Metodologias-dedesarrollo.html
Esta figura podra resumir buena parte de la esencia del curso: en el desarrollo de
software (una entidad "compleja") se producen problemas de comunicacin a varios
niveles: entre usuarios y desarrolladores y entre los componentes mismos del equipo de
desarrollo.
Estudiaremos las tcnicas, mtodos y herramientas de ingeniera que puedan hacer
que estos problemas se minimicen, e incluso que desaparezcan.
16
Ingeniera de Software
2.4 Proceso, mtodos y herramientas
La ingeniera del software es una tecnologa multicapa, y que se apoya sobre un
enfoque de calidad.
Herramientas
Mtodos
Proceso
Enfoque de calidad
Enfoque de calidad
Proceso
Mtodos
Herramientas
17
Ingeniera de Software
1
Fase de definicin
Se centra sobre el qu. Identificar qu informacin ha de ser procesada,
que funcin y rendimiento se desea, qu comportamiento del sistema, qu
interfaces van a ser establecidas, qu restricciones de diseo existen, y qu
criterios de validacin se necesitan para definir un sistema correcto.
Identificar los requisitos del sistema y del software.
Las tareas especficas de esta fase son:
oo Ingeniera de Sistemas o de informacin
oo Planificacin del proyecto software
oo Anlisis de requerimientos
Fase de desarrollo
Se centra en el cmo. Definir cmo han de disearse las estructuras de
datos, cmo ha de implementarse la funcin dentro de una arquitectura de
software, cmo ha de implementarse los detalles procedimentales, cmo
han de caracterizarse interfaces, cmo ha de traducirse el diseo en un
lenguaje de programacin y cmo ha de realizarse la prueba.
Las tareas especficas de esta fase son:
oo Diseo del software
oo Generacin de cdigo
oo Prueba del software
Fase de mantenimiento
Se centra en el cambio.
Correccin de errores
Adaptaciones requeridas a medida que evoluciona el entorno del software
Cambios debidos a las mejoras producidas por los requisitos cambiantes
del cliente
Se encuentran cuatro tipos de cambio:
oo Correccin
oo Adaptacin
oo Mejora
oo Prevencin
Ingeniera de Software
Un proceso de software se puede caracterizar as:
Actividades de Proteccin
Permiten que las actividades del
marco de trabajo se adapten a
las caractersticas del proyecto
del software y a los requisitos del
proyecto.
Son
independientes
de
cualquier actividad del marco
de trabajo y aparecen durante
todo el proceso.
19
Ingeniera de Software
3. MODELOS DE PROCESO DEL SOFTWARE
Es importante incorporar estrategias de desarrollo que acompae al proceso, mtodos y
a las herramientas.
Una estrategia a menudo de 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.
Ingeniera
del Sistema
Anlisis
Diseo
Codificacin
Prueba
Utilizacin
Mantenimiento
Ingeniera
Sistema
Ingeniera de Software
Para un sistema nuevo: Se debe analizar cules son los requisitos
funciones del sistema, y luego asignar un subconjunto de estos
requisitos y funciones al software.
Para un sistema ya existente: se debe analizar el funcionamiento
de la organizacin y sus operaciones y se asigna al software
aquellas funciones que se van a automatizar.
Est formado por diagramas y por descripciones en lenguaje
natural.
Anlisis
Diseo
Codificacin
Prueba
Utilizacin
Mantenimiento
Ingeniera de Software
Que, durante la utilizacin, el cliente detecte errores en el
software: los errores latentes.
Que se produzcan cambios en alguno de los componentes del
sistema.
Que el cliente requiera modificaciones funcionales no
contempladas en el proyecto.
Identificar los
requerimientos
conocidos
Desarrollar
modelo que
funcione
Utilizar el
prototipo
Revisar el
prototipo
No
Prototipo
Terminado?
Abandonar la aplicacin
Implantar la aplicacin
Volver a desarrollar la
aplicacin
Comenzar un nuevo
prototipo
Paso
Descripcin
Identificar los Los analistas y los usuarios trabajan juntos para identificar los
requerimientos requerimientos conocidos que tienen que satisfacerse.
conocidos
Se debe: determinar los fines del sistema y el alcance de su
capacidad.
22
Ingeniera de Software
Paso
Descripcin
Desarrollar
Los desarrolladores explican a los usuarios:
modelo
que El mtodo
funcione
Las actividades a realizar
La secuencia en que se llevar a cabo
La responsabilidad de cada participante
El proceso de construccin del prototipo se debe iniciar con el
desarrollo de un plan general que permita conocer el proceso
de desarrollo.
Es importante definir un cronograma para el inicio y fin de la
primera iteracin.
Primera
Iteracin
Debe
describir
23
Ingeniera de Software
Paso
Descripcin
Revisar
el Se realiza la evaluacin y con la informacin obtenida se levantan
prototipo
las caractersticas que debe llevar la siguiente versin del
prototipo.
La evaluacin permite profundizar los rasgos de los usuarios y los
de la organizacin que tienen influencia sobre la aplicacin y en su
implementacin.
Los cambios en el prototipo son planificados con los usuarios antes
de llevarlos a cabo por el analista.
Prototipo
Los pasos anteriores se repiten varias veces (4 o 6 iteraciones)
terminado?
cuando los usuarios y desarrolladores estn de acuerdo en que el
sistema ha evolucionado lo suficiente e incluye todas las
caractersticas necesarias.
Cuando el prototipo est terminado, el paso que sigue a
continuacin es tomar la decisin sobre cmo proceder, para lo
cual existen cuatro opciones:
Abandonar la aplicacin
Se descartan el prototipo y la aplicacin. El desarrollo del prototipo
proporcion informacin a partir de la cual se determin que la
aplicacin o el enfoque seleccionado son inapropiados para
justificar un desarrollo adicional.
Implantar el prototipo
Las caractersticas y funcionamiento del prototipo satisfacen las
necesidades de los usuarios ya sea en forma permanente o para un
futuro.
Volver a desarrollar la aplicacin
El desarrollo del prototipo proporcion suficiente informacin para
determinar las caractersticas necesarias de toda la aplicacin. La
informacin se utiliza como punto de partida para el desarrollo de
la aplicacin en forma tal haga el mejor uso posible de los
recursos.
Comenzar un nuevo prototipo
La informacin ganada con el desarrollo del prototipo inicial
sugiere otras opciones o circunstancia. Se construye un prototipo
diferente para aadir informacin relacionada con los
requerimientos de aplicacin.
24
Ingeniera de Software
Un prototipo puede tener alguna de las tres formas siguientes:
1
DRA
es un
modelo de proceso
del
Enfatiza
un
Ciclo de
desarrollo
corto
25
Ingeniera de Software
El proceso DRA permite al equipo de desarrollo crear un sistema completamente
funcional dentro de periodos cortos de tiempo (de 60 a 90 das). El enfoque DRA
comprende las siguientes fases:
Equipo N. 3
Modelado
de gestin
Equipo N. 2
Equipo N. 1
Modelado
de datos
Modelado
de
procesos
Modelado
de gestin
Modelado
de datos
Modelado
de gestin
Modelado
de datos
Modelado
de
procesos
Generacin
de
aplicaciones
Pruebas y
entrega
Generacin
de
aplicaciones
Pruebas y
entrega
Modelado
de
procesos
Generacin
de
aplicaciones
Pruebas y
entrega
60-90 das
Modelado
gestin
26
Ingeniera de Software
Modelado
datos
Los
modelos
evolutivos
son
iterativos
se
caracterizan
por
desarrollar
versiones
27
cada vez
ms completas
del software
Ingeniera de Software
3.4.1 El modelo incremental
El modelo incremental
combina
el
y la
Construccin de prototipos
para
Entregar el software
en
Partes pequeas
llamadas
Incrementos
28
Ingeniera de Software
Ingeniera de
Sistemas / Informacin
Anlisis
incremento 2
incremento 1
Diseo
Anlisis
Cdigo
Diseo
Cdigo
Anlisis
incremento 3
incremento 4
Entrega
1er. Incremento
Prueba
Prueba
Diseo
Anlisis
Cdigo
Diseo
Entrega
2do. Incremento
Prueba
Cdigo
Entrega
3er. Incremento
Prueba
Entrega
4to. Incremento
Tiempo
Modelo
Espiral
es un
proceso de
software
evolutivo
construccin de prototipos
conjuga
proporciona
Un desarrollo rpido de
versiones incremntales del
software
29
Ingeniera de Software
Comunicacin con el cliente: Se establece comunicacin
entre el desarrollador y el cliente.
Planificacin: Se definen los recursos, el tiempo y otra
informacin relacionados con el proyecto.
Anlisis de riesgos: Se evalan riesgos tcnicos y de gestin
Actividades
del modelo
en espiral
probar,
instalar
30
Ingeniera de Software
El equipo de ingeniera del software gira alrededor de la espiral en la direccin de las
agujas del reloj, comenzando por el centro.
El primer circuito de la espiral puede producir el desarrollo de una especificacin de
productos; los pasos siguientes en la espiral se podran utilizar para desarrollar un
prototipo y progresivamente versiones mas sofisticadas del software. Cada paso por la
regin de planificacin produce ajustes en el plan del proyecto. El costo y la
planificacin se ajustan con la realimentacin ante la evaluacin del cliente. Adems, el
gestor del proyecto ajusta el nmero planificado de iteraciones requeridas para
completar el software.
3.5 Modelo de mtodos formales y Tcnicas de cuarta generacin
El modelo de mtodos formales comprende un conjunto de actividades que conducen a
la especificacin matemtica del software de computadora. Los mtodos formales
permiten que un ingeniero de software especifique, desarrolle y verifique un sistema
basado en computadora aplicando una notacin rigurosa y matemtica.
Este enfoque es llamado ingeniera del software de sala limpia. Cuando se utilizan
mtodos formales se descubren y corrigen ambigedades, inconsistencias y errores.
Las tcnicas de cuarta generacin, abarcan un conjunto de herramientas que facilitan al
ingeniero del software la especificacin de las caractersticas del software a alto nivel.
La herramienta genera automticamente el cdigo fuente basndose en la
especificacin del tcnico. Cuanto mayor sea el nivel en el que se especifique el
software, ms rpido se puede construir el programa.
El paradigma T4G para la ingeniera del software se orienta hacia la posibilidad de
especificar el software usando formas de lenguaje especializado o notaciones grficas
que describa el problema que hay que resolver en trminos que los entienda el cliente.
El paradigma
T4G
incluye
las etapas
Ingeniera de Software
ACTIVIDADES COMPLEMENTARIAS
1. Las capas de la Ingeniera del Software sita las tres capas encima de la capa
titulada enfoque de calidad. Esto implica un programa de calidad tal como
Gestin de Calidad Total. Investigue y desarrolle un esquema de los principios
clave de un programa de Gestin de Calidad Total.
2. Elabore y proporcione una tabla donde se especifiquen las ventajas y
desventajas de los diferentes paradigmas de ingeniera de software.
3. Qu paradigmas de ingeniera del software de los presentados piensa que sera
el ms eficaz? Por que?
4. Qu es ms importante, el producto o el proceso?
32
Ingeniera de Software
BIBLIOGRAFIA
IMPRESA
BRAUDE. Ingeniera de software, una perspectiva orientada a objetos. Mxico. 2003.
Alfaomega grupo editor. S.A.
GRUEGGE, BERND y DUTOIT, Allen H. Ingeniera de software orientado a objetos.
Mxico. 2002. Pearson Educacin.
HUMPHREY, Watts S. Introduccin al proceso de software personal. Pearson Addison
wesley. 2001.
MEYER, Bertrand. Construccin de software orientado a objetos. Segunda edicin.
Madrid. 1999. Prentice Hall.
NORRIS. Ingeniera de software explicada. Grupo Noriega editores de Colombia.
PIATTINI, Mario. VILLALBA, Jos y otros. Mantenimiento del software: modelos,
tcnicas y mtodos para la gestin del cambio. Editorial Alfaomega-Rama.
PRESSMAN, Roger S. Ingeniera del Software. Un enfoque prctico. Quinta edicin.
Espaa. 2002. Editorial McGraw Hill.
PFLEEGER, Shari Lawrence. Ingeniera de software, teora y prctica. 1. Edicin.
Buenos Aires. Pearson educacin. 2002
SOMMERVILLE, Ian. Ingeniera de software. 6. Edicin. Pearson Addison Wesley.
2001
33
Ingeniera de Software
UNIDAD 2.
GESTIN Y PLANIFICACIN DE
PROYECTOS SOFTWARE
INTRODUCCIN
La gestin y planificacin de proyectos es una actividad que empieza antes de iniciar
cualquier actividad tcnica y contina a lo largo de la definicin, del desarrollo y del
mantenimiento del software.
La actividad de gestin del proyecto comprende medicin y mtricas, estimacin,
anlisis de riesgos, planificacin, seguimiento y control.
OBJETIVOS
GENERALES
ESPECIFICOS
34
Ingeniera de Software
ESTRUCTURA TEMTICA
1. CONCEPTOS SOBRE GESTION DE PROYECTOS
1.1 Gestin de proyectos
Gestin de proyectos
implica
Planificacin
Supervisin
Control
de
Personal
Procesos
eventos
mientras
Evoluciona el Software
La gestin de un proyecto de software se centra en:
4 Ps
Personal
Necesidad de
personal para el
desarrollo de
software
Producto
Objetivos y
mbito del
software
35
Proceso
Proyecto
Estructura que
establece un
plan detallado
para el
desarrollo del
software
Proyectos de
software
planificados y
controlados.
Ingeniera de Software
1.2 Personal
Recurso humano que participa y colabora en el proceso del software y su organizacin
para el desarrollo de los proyectos software de manera eficaz.
Participantes
Se clasifican en:
1. Gestores Superiores: se encargan de definir los aspectos
del negocio.
2. Gestores tcnicos del proyecto: se encargan de
planificar, motivar, organizar y controlar a los profesionales
que realizan el trabajo de desarrollo del software.
3. Profesionales: se encargan de proporcionan las
capacidades tcnicas necesarias para la ingeniera de un
producto o aplicacin.
4. Clientes: especifican los requisitos para la ingeniera del
software.
5. Usuarios finales: Se encargan de interactuar con el
software.
Jefes
equipo
Equipo
software
36
Ingeniera de Software
Descentralizado controlado
Este equipo tiene un jefe definido que coordina tareas
especficas y jefes secundarios que tienen responsabilidades
sobre subtareas. La resolucin de problemas sigue siendo una
actividad del grupo, pero la implementacin de soluciones se
reparte entre subgrupos por el jefe de equipo. La comunicacin
entre subgrupos e individuos es horizontal. Tambin hay
comunicacin vertical a lo largo de la jerarqua de control.
Centralizado controlado
El jefe del equipo se encarga de la resolucin de problemas a alto
nivel y la coordinacin interna del equipo. La comunicacin entre
jefe y los miembros del equipo es vertical.
Coordinacin
y
Comunicacin
1.3 Producto
Al inicio de un proyecto, el gestor del proyecto debe examinar el producto y el
problema a resolver. Por lo que se debe establecer el mbito del producto
delimitarlo.
37
Ingeniera de Software
mbito
Se define:
38
Ingeniera de Software
1.4 Proceso
El gestor del proyecto decide qu modelo de proceso es el ms adecuado para:
1. Los clientes que han solicitado el producto y la gente que realizar el trabajo.
2. Las caractersticas del producto.
3. El entorno del proyecto.
Descomposicin
del proceso
Comunicacin
Se establece comunicacin entre el desarrollador y el cliente,
con el propsito de obtener los requisitos del sistema.
Planificacin
Conjunto de tareas con el propsito de definir los recursos y la
planificacin temporal del proyecto.
Anlisis del riesgo
Tareas requeridas para valorar los riesgos tcnicos y de
gestin.
Ingeniera
Tareas requeridas para construir una o ms representaciones
de la aplicacin.
Construccin y entrega
Tareas requeridas para construir, probar, instalar y
proporcionar asistencia al usuario.
Evaluacin del cliente
Tareas requeridas para que el cliente evale las
representaciones de software creadas durante la fase de
ingeniera.
El trabajo del gestor del proyecto es estimar los requisitos de
recursos, poner fechas de inicio y finalizacin de las tareas y los
productos a fabricar.
Las actividades de: comunicacin, planificacin, anlisis de riesgo,
ingeniera, construccin, entrega y evaluacin se adaptan al
modelo o paradigma de desarrollo de software seleccionado.
1.5 Proyecto
Se deben gestionar proyectos software de39
calidad para que tengan xito.
Ingeniera de Software
Se debe:
1
Comprender el problema a
solucionar y establecer los
objetivos.
Mantener el
desarrollo y
incentivos.
ACTIVIDADES COMPLEMENTARIAS
40
equipo de
proporcionar
Ingeniera de Software
1. Se le ha nombrado gestor de proyecto dentro de una organizacin de sistemas
de informacin. Su trabajo es construir una aplicacin que es bastante similar a
otras que ha construido su equipo, aunque sta es mayor y ms compleja. Los
requisitos han sido detalladamente documentados por el cliente. Qu estructura
de equipo elegira y porqu? Qu modelo(s) de proceso de software elegira y
por qu?
2. Se le ha nombrado gestor de proyecto de una pequea compaa de productos
software. Su trabajo consiste en construir un producto innovador que combine
hardware de realidad virtual con software innovador. Puesto que la competencia
por el mercado de entretenimiento casero es intensa, hay cierta presin para
terminar el trabajo rpidamente. Qu estructura de equipo elegira y porqu?
Qu modelo(s) de proceso de software elegira y por qu?
41
Ingeniera de Software
2. EL PROCESO DE SOFTWARE Y MTRICAS DEL PROYECTO
Mtricas del
software
comprende
Una gama
de
Mediciones
se
aplican
al
para el
para
Ayudar en la estimacin, el
control de calidad, la
evaluacin de productividad y
el control de proyectos
Software
Las razones para medir los procesos del software, los productos y los recursos: son:
Caracterizar: para comprender mejor los procesos, los productos, los
recursos y los entornos
Evaluar: para determinar el estado con respecto al diseo
Predecir: para poder planificar
Mejorar: la calidad del producto y el rendimiento del proceso.
42
Ingeniera de Software
2.1 Mtricas en el proceso y dominios del proyecto
Dentro de la Ingeniera del software se manejan los siguientes conceptos:
Medida: Proporciona una
indicacin cuantitativa de la
extensin,
cantidad,
dimensiones,
capacidad
o
tamao de algunos atributos
de un proceso o producto.
Evaluar el
estado del
proyecto
Hacer
seguimiento
a los riesgos
potenciales
Detectar
las
reas problemas
antes de que se
conviertan
en
crticas
Ajustar el
flujo y las
tareas del
trabajo
Evaluar la habilidad
del
equipo
para
controlar la calidad
de los productos
software.
43
Ingeniera de Software
De acuerdo a la figura:
Producto
Caractersticas
del cliente
Condiciones
del negocio
Proceso
Personas
Entorno de
desarrollo
Tecnologa
Defectos detectados
Ingeniera de Software
Tambin se debe incluir mtricas para medir las caractersticas de tareas especficas de
la ingeniera del software.
MEPS
utiliza
Anlisis de fallos
del
Software
para
Recopilar informacin
de
Errores
Defectos
Los datos resultantes se analizan para detectar las categoras que producen un
Ingeniera de Software
Error
Defecto
Para determinar las principales causas que pueden ocasionar defectos en el software y
con base en ello extraer los indicadores que permitan a una organizacin de software
modificar su proceso para reducir la frecuencia de errores y defectos se utiliza el
diagrama de espina.
Causa
potencial No. 1
Q1%
Causa
potencial no. 2
Q2%
Ci, j
Problema
Principal
R%
Ci, j
Causa
potencial n
Qi%
Causa
potencial n+1
Qi%
46
Ingeniera de Software
En un diagrama de espina:
Esta misma notacin se aplica para cada una de las lneas diagonales conectadas a la
lnea central.
Por ejemplo:
Se han encontrado y determinado las siguientes causas y su origen en un proyecto de
software:
Diseo
Cdigo
Causa
Lgica
Manejo de datos
estndares
Especificaciones
Interfaz software
Interfaz hardware
Comprobacin de errores
Interfaz de usuario
%
20
10.9
6.9
25.5
6.0
7.7
10.9
11.7
Incorrecto
Cambios
Cliente consultado
no adecuado
El cliente dio
informacin equivocada
Insuficiente
informacin solicitada
Informacin desactualizada
Defectos de
especificacin
25.5%
Perdido
47
Ambiguo
Ingeniera de Software
Las mtricas del proyecto de software sugieren que los proyectos deben medir:
1
48
Ingeniera de Software
El domino de las mtricas del software se dividen en mtricas de proceso, proyecto y
producto.
LDC
Esfuerzo Costo $
IRIS
18.200
24
Pginas de
Errores Defectos Personas
documentacin
200.000
945
134
86
4
Teniendo en cuenta los datos de la tabla, se pueden derivar otras mtricas para
comparar varios proyectos. Por ejemplo:
Errores por KLDC (miles de lneas de cdigo)
Defectos por KLDC
Pginas de documentacin por KLDC
Errores por persona-mes
LDC por persona-mes
Costo ($) por pgina de documentacin
La medida de la
funcionalidad de
la aplicacin.
Propuestas por
49
Ingeniera de Software
Los puntos de funcin se obtienen utilizando una funcin emprica basado en medidas
cuantitativas del dominio de informacin del software y valoraciones subjetivas de la
complejidad del software.
Los puntos de funcin se calculan utilizando la siguiente tabla:
Parmetros Cuenta
de medicin
Nmero de
entradas de
usuario
Nmero de
salidas
de
usuario
Nmero de
peticiones de
usuario
Nmero de
archivos
Nmero de
interfaces
externas
Factor de ponderacin
Simple Medio Complejo
3
4
6
X
=
4
=
3
X
X
X
=
7
10
15
10
=
=
Cuenta_total
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. Nmero de entradas de usuario: se cuenta cada entrada de usuario que
proporcione al software diferentes datos orientados a la aplicacin.
2. Nmero de salidas de usuario: se cuenta cada salida que proporciona al
usuario informacin orientada a la aplicacin. En este contexto las salidas se refieren
a informes, pantallas, mensajes de error.
3. Nmero de peticiones de usuario: una peticin esta 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.
5. Nmero 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.
50
Ingeniera de Software
Cuando han sido recogidos los datos anteriores, se asocia 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 * (fi)]
PF
Punto de funcin
Cuenta_total Es la suma de todas las entradas obtenidas
fi
Donde i=1 hasta 14. Son valores de ajuste de la complejidad
basados en las respuestas a las cuestiones sealadas de la
siguiente tabla:
Evaluar cada factor en escala 0 a 5
0
No
influencia
Fi :
1
2
3
4
5
6
7
8
9
1
2
3
4
5
Incidental Moderado Medio Significativo Esencial
Ingeniera de Software
10
11
12
13
14
Una vez calculado los puntos de funcin se usan como medida de la productividad,
calidad y otros productos del software.
Productividad = PF / persona-mes
Calidad = Errores / PF
Costo = Dlares / PF
Documentacin = Paginas Documentadas / PF
52
Ingeniera de Software
2.5 Mtricas para la calidad del software
El objetivo de la ingeniera del software es desarrollar y producir software de alta
calidad. Para lograr este objetivo, es fundamental aplicar mtodos y herramientas
efectivos dentro del contexto de un proceso maduro de desarrollo de software.
53
Ingeniera de Software
Integridad
Mide la capacidad del software para resistir ataques.
Se debe tener en cuanta los siguientes atributos:
Amenaza
Seguridad
Se define como:
Integridad = [(1-amenaza) x (1-seguridad)]
Facilidad de uso
Mide la amigabilidad del software con el usuario final.
Se mide
en funcin de:
Habilidad intelectual o fsica para aprender el sistema.
El tiempo requerido para hacer uso eficiente del sistema.
Aumento de la productividad.
Valoracin subjetiva de la disposicin de los usuarios hacia el
sistema.
54
Ingeniera de Software
2.5.2 Eficacia de la eliminacin de defectos
La eficacia de la eliminacin de defectos (EED), es una mtrica que permite medir la
habilidad de filtrar las actividades de la garanta de calidad y de control, ya que es
aplicable a todas las actividades del marco de trabajo del proceso.
Se define de la siguiente forma:
EED = E / (E + D)
E
D
2.5.3 Integracin de las mtricas dentro del proceso de Ingeniera del Software
55
Ingeniera de Software
1
Recopilacin de datos
Requiere una investigacin histrica de los
proyectos para reconstruir los datos requeridos
Medidas
2
Clculo de mtricas
Se hace el clculo de mtricas una vez se han
determinado las medidas. Pueden abarcar una
gran cantidad de mtricas:
LDC y PF
De calidad
Del proyecto
Mtricas
3
Evaluacin de mtricas
Se deben evaluar las mtricas y aplicar
durante: la estimacin, el control de
proyectos y la mejora del proceso.
Los indicadores guan el proyecto o el
proceso.
56
Indicadores
Ingeniera de Software
ACTIVIDADES COMPLEMENTARIAS
1. Describa, con sus propias palabras, la diferencia entre mtricas del proceso y del
proyecto.
2. Elabore un ensayo argumentativo, que de respuesta a la pregunta Por qu
renecesita medir? Por qu son importantes las mtricas dentro de la ingeniera
de Software?
3. Sugiera tres medidas, tres mtricas y los indicadores que se podran utilizar para
evaluar un automvil.
4. Indague con algn desarrollador de software o un equipo de desarrollo de
software qu medidas, mtricas e indicadores utilizan o tienen implementadas.
Elabore un cuadro sinptico.
INVESTIGACIN
1. El Instituto de Ingeniera de Software (The Carnegie Mellon Software Engineering
Institute -SEI) ha desarrollado una gua para establecer un programa de medicin
de software dirigido hacia objetivos. Investigue y elabore un documento sobre
esta gua.
EJERCICIOS
1. Calcule el Punto de Funcin de un proyecto con las siguientes caractersticas del
dominio de informacin:
32
60
24
8
2
57
Ingeniera de Software
3. PLANIFICACIN DE PROYECTOS DE SOFTWARE
Planificacin
implica
determina
Su resultado
Estimacin
El costo
El esfuerzo
Los recursos
El tiempo
La estimacin se inicia con una descripcin del mbito del producto. El problema se
descompone en un conjunto de problemas de menor tamao y cada uno de stos se
estima guindose con datos histricos y con la experiencia.
Recursos
Estimacin del
proyecto
58
Tcnicas de
descomposicin
Modelos de
estimacin
Ingeniera de Software
3.1.1. 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 mas detalles antes del comienzo de la
estimacin.
mbito del software
comprende
Recoleccin de la informacin
Su objetivo es acercar al desarrollador y al cliente para establecer una comunicacin,
para lograr esto, se utiliza una tcnica muy comn que es una reunin o una
entrevista preliminar.
Esta reunin o entrevista debe involucrar los siguientes tipos de preguntas:
1. Preguntas de contexto libre: se centran en el cliente, en los objetivos globales
y en los beneficios. Estas preguntas deben llevar a un entendimiento bsico
del problema, las personas interesadas en la solucin y la solucin que se
desea.
2. Metacuestiones: estas preguntas se centran en la efectividad de la reunin,
involucra preguntas para determinar si la persona es la apropiada para
responder a las preguntas, si son relevantes las preguntas para el problema
en estudio, si las respuestas son oficiales, si existe algo que se debera
preguntar.
Tambin existe otra tcnica que permite la creacin de un equipo compuesto por los
clientes y los desarrolladores para identificar el problema, proponer elementos de
solucin, establecer enfoques y especificar un conjunto preliminar de requisitos
denominada TFEA (Facilitated application specification techniques) Tcnica para
facilitar las especificaciones de la aplicacin.
Viabilidad
Se centra en preguntarse:
Se puede construir el software de acuerdo al mbito definido?
Es factible el proyecto?
59
Ingeniera de Software
Comprende la estimacin de los recursos necesarios para emprender el desarrollo del
software.
Los recursos de desarrollo son:
Humanos
Componentes reutilizables
de software
De entorno
(Hardware / software)
Recurso humano
Se debe establecer el perfil y las habilidades que se necesitan del personal que se
necesita para llevar a cabo el desarrollo del proyecto. Hay que especificar tanto la
posicin dentro de la organizacin como la especialidad.
Gestor
Ingeniero de software
Analista de sistemas
60
Ingeniera de Software
Recursos de entorno
El entorno es donde se apoya el proyecto de software.
Comprende
Hardware y Software
61
Ingeniera de Software
La utilizacin de tcnicas de descomposicin y de modelos empricos, permiten
descomponer el proyecto en funciones principales y en tareas lo que implica que se
pueda realizar una estimacin del costo y del esfuerzo del proyecto de forma
escalonada.
Antes de de realizar la estimacin del proyecto se debe generar una estimacin del
tamao del software a construir.
3.2.1 Tamao del software
Dentro de la planificacin de proyectos, el tamao se refiere a una produccin
cuantificable del proyecto de software.
El tamao se mide en LDC, si se utiliza un enfoque directo
El tamao se representa como PF, si se utiliza un enfoque indirecto.
62
Ingeniera de Software
2
E = (O + 4 * M + P) / 6
63
Ingeniera de Software
3.2.3 Estimacin basada en el proceso
Esta tcnica permite, descomponer el proceso en un conjunto relativamente pequeo
de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de
cada tarea.
Esta estimacin comprende:
1. Delineacin de las funciones del software obtenidas a partir del mbito del
proyecto.
2. Se mezclan las funciones del problema y las actividades del proceso.
3. Se calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de
software.
Modelo COCOMO
Creado por Barry Boehm en 1981. Su nombre significa COnstructive COst MOdel
(Modelo constructivo de costo) y se puede dividir en tres modelos.
64
Ingeniera de Software
COCOMO bsico. Calcula el esfuerzo y el costo del desarrollo en
funcin del tamao del programa estimado en LOC.
Modelos
Los modelos COCOMO estn definidos para tres tipos de proyectos de software:
Orgnicos.
o Proyectos pequeos y sencillos.
o Equipos pequeos con experiencia en la aplicacin.
o Requisitos poco rgidos.
Semiacoplados.
o Proyectos de tamao y complejidad intermedia.
o Equipos con variado niveles de experiencia.
o Requisitos poco o medio rgidos.
Empotrados.
o Proyectos que deben ser desarrollados con un conjunto de requisitos
(hardware y software) muy restringidos.
COCOMO bsico
Las ecuaciones del modelo COCOMO bsico son de la forma:
E = a * KLOCb
D = c * Ed
Donde:
65
Ingeniera de Software
E
D
KLOC
a
2.4
3.0
3.6
b
1.05
1.12
1.20
C
2.5
2.5
2.5
d
0.38
0.35
0.32
E = 2.4 * KLOC1.05
= 2.4 * 7.41.05
= 20 hombre-mes
66
Ingeniera de Software
COCOMO intermedio
En el COCOMO intermedio, la ecuacin para calcular el tiempo de desarrollo es la
misma que la del COCOMO bsico. La ecuacin para calcular el esfuerzo es:
E = a * KLOCb * EAF
Donde,
E
KLOC
es el esfuerzo en hombre-mes
es el nmero estimado de miles de lneas de cdigo
a
3.2
3.0
2.8
b
1.05
1.12
1.20
Y
EAF
67
Ingeniera de Software
EAF
Atributos de personal.
Nivel de habilidades que tiene el personal. Son habilidades
profesionales generales, habilidad de programacin, experiencia
con el medio ambiente de desarrollo y familiaridad con el dominio
del proyecto.
o Capacidad del analista.
o Experiencia en aplicaciones*
o Capacidad del programador.
o Experiencia con la mquina virtual.
o Experiencia con el lenguaje de programacin.
Atributos del proyecto.
Restricciones y condiciones bajo las cuales el proyecto se
desarrolla.
o Prcticas modernas de programacin
o Uso de herramientas de software*
o Calendario de desarrollo requerido.
Nmero
0.75
0.88
1
1.15
1.40
El nmero indica el grado con el que cada factor puede influenciar la productividad. Un
valor menor que 1 indica que el factor puede decrementar el calendario y el esfuerzo.
Un valor mayor que 1 denota un factor que extiende el calendario y el esfuerzo.
Finalmente, un valor igual a 1 no extiende ni decrementa el calendario y el esfuerzo
(esta clase de factor se llama nominal).
Para obtener el EAF se multiplican cada uno de los 15 factores.
Se puede simplificar el clculo del EAF porque hay una tendencia a considerar los
atributos marcados en (*), como los ms relevantes y que deberan ser tomados en
cuenta.
La ecuacin del software
68
Ingeniera de Software
Es de la forma:
E = (LOC * B0.333 / P)3 * (1 / t4)
Donde,
E
t
B
Esfuerzo en hombres-ao.
Duracin del proyecto en aos.
Factor especial de destrezas. Para programas pequeos B vale 0.16,
para programas intermedios vale 0.28, para programas mayores vale
0.39.
Parmetro de productividad, para un software de tiempo real, P vale
2,000, para comunicaciones vale 10,000, para software cientfico vale
12,000 y para aplicaciones comerciales de sistemas vale 28,000.
69
Ingeniera de Software
Aplicando las ecuaciones al ejemplo anterior, obtenemos:
Identificarlo
Evaluar su probabilidad de aparicin,
Estimar su impacto, y ,
Establecer un plan de contingencia por si ocurre el problema.
Ingeniera de Software
Se tienen dos estrategias:
Reactiva
Supervisa el proyecto en previsin de posibles riesgos.
Evaluar las consecuencias del riesgo cuando este ya se ha producido (ya no es
un riesgo)
Actuar en consecuencia
Proactiva
Identifica los riesgos potenciales.
Evaluacin previa y sistemtica de riesgos
Evaluacin de consecuencias
Se establece un plan de contingencia para controlar el riesgo.
Riesgo
implica
Incertidumbre
el acontecimiento que
caracteriza al riesgo
puede o no puede
ocurrir.
Prdida
Si el riesgo se convierte en una
realidad, ocurrirn consecuencias
no deseadas o prdidas.
71
Ingeniera de Software
3.4.2 Categoras de riesgos
Riesgos del proyecto
Pueden amenazar al plan del proyecto, porque puede retrazar el proyecto y aumentar
los costos.
Identifican problemas de:
Presupuesto
Personal
Recursos
Cliente
Requisitos
Riesgos tcnicos
Amenazan la calidad del software y la planificacin temporal del proyecto. La
implementacin puede llegar a ser difcil o imposible.
Identifican problemas de:
Diseo
Implementacin
De interfaz
Verificacin
Mantenimiento
Riesgos del negocio
Amenazan la viabilidad del software a construir. Se pone en riesgo el proyecto y el
producto.
Identifican problemas de:
De mercado
De estrategia
De ventas
De gestin
De presupuesto
72
Ingeniera de Software
3.4.3 Identificacin del riesgo
Existen dos tipos de riesgo:
Riesgos genricos
Riesgos especficos
Representan una amenaza potencial para Implican un conocimiento profundo del
todos los proyectos de software.
proyecto (Entorno, Tecnologa, Personal)
73
Ingeniera de Software
Con el tipo de cliente
Ingeniera de Software
Hay estndares de documentacin de cdigo
Se usan mtodos especficos para el diseo de
pruebas
Se utilizan herramientas para llevar a cabo la
planificacin y control
Con el entorno
desarrollo
Con la tecnologa
Ingeniera de Software
Con la
tcnica
Riesgos
Mayor nmero de usuarios previstos
Categora
TP
Probabilidad Impacto
30%
3
Ingeniera de Software
Tamao del producto (TP)
Impacto en la organizacin (IO)
Tipo de cliente (TC)
Proceso de produccin (PP)
Entorno de desarrollo (ED)
Tecnologa (T)
Experiencia tcnica (ET)
Se pueden utilizar las iniciales que se encuentran entre parntesis o puede
asignar unas especficas.
3. En la columna Probabilidad, se registra la probabilidad de aparicin de cada
riesgo.
4. En la columna Impacto, Se valora y se registra el impacto de cada riesgo as:
77
Ingeniera de Software
1
2
3
4
Catastrfico
Crtico
Marginal
Despreciable
Por ltimo la tabla es ordenada por probabilidad y por impacto. Aquellos riesgos que
presentan alta probabilidad y alto impacto pasan al inicio de la tabla y los que
presentan baja probabilidad e impacto pasan al final de la tabla.
Una vez la tabla ha sido ordenada, el encargado del proyecto debe trazar una lnea
de corte donde los riesgos que se encuentren por encima de sta lnea se les
prestara una mayor atencin.
Donde:
P
C
Esta ecuacin se aplica para calcular la exposicin al riesgo de cada riesgo descrito en
la tabla de riesgos. Estos clculos permiten ajustar los costos finales del proyecto.
Ingeniera de Software
3.4.5 Reduccin, supervisin y gestin del riesgo
El objetivo que debe tener un equipo de software es evitar y tratar un riesgo. Para esto,
es importante que se desarrolle un plan de reduccin del riesgo.
Este plan de reduccin del riesgo involucra para cada riesgo una serie de pasos y
acciones que debe tomar e implementar el equipo de desarrollo del software.
El plan RSGR
Se puede incluir una estrategia de gestin de riesgo en el plan del proyecto de software
o se podran organizar los pasos de gestin del riesgo en un plan diferente de
reduccin, supervisin y gestin del riesgo (Plan RSGR). Todos los documentos del
plan RSGR se llevan a cabo como parte del anlisis de riesgo y son empleados por el
jefe del proyecto como parte del Plan del Proyecto general.
A continuacin se expone un esquema del Plan RSGR:
I. Introduccin
1. Alcance y propsito del documento
2. Visin general de los riesgos principales
3. Responsabilidades
a. Gestin
b. Personal tcnico
II. Tabla de riesgo del proyecto.
1. Descripcin de todos los riesgos por encima
2. Factores que influyen en la probabilidad e impacto
III. Reduccin, supervisin y gestin del riesgo
n. Riesgo # n
a. Reduccin
i.Estrategia general.
ii. Pasos especficos.
b. Supervisin
i. Factores a supervisar
ii. Enfoque de supervisin
c. Gestin
i. Plan de contingencia
ii. Consideraciones especiales.
IV. Planificacin temporal de revisin del Plan RSGR
V. Resumen
79
de
la
lnea
de
corte
Ingeniera de Software
Una vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan
los procedimientos de reduccin y supervisin del riesgo.
La reduccin del riesgo es una actividad para evitar problemas.
La supervisin del riesgo es una actividad de seguimiento del proyecto con tres
objetivos principales:
80
Ingeniera de Software
3.5 Planificacin temporal
La planificacin temporal de un proyecto es una actividad que evoluciona con el tiempo
y que permite identificar, definir y programar las actividades especficas que se
requieren para realizar una actividad.
La planificacin temporal permite:
Asignacin de
tiempo
Validacin de
esfuerzo
Definir
responsabilidades
Definir resultados
Hitos
81
Ingeniera de Software
3.5.2 Herramientas De Planificacin Temporal
1. PERT (Program Evaluation and Review Technique)
El diagrama PERT es una representacin grfica de las relaciones entre las tareas del
proyecto que permite calcular los tiempos del proyecto de forma sencilla.
Caractersticas
Es un grafo, o sea, un conjunto de puntos (nodos) unidos por flechas.
Representa las relaciones entre las tareas del proyecto, no su distribucin
temporal.
Las flechas del grafo corresponden a las tareas del proyecto.
Los nodos del grafo, representado por crculos o rectngulos, corresponden a
instantes del proyecto. Cada nodo puede representar hasta dos instantes
distintos, el inicio mnimo de las tareas que parten del nodo y el final mximo
de las tareas que llegan al mismo.
Es una herramienta de clculo, y una representacin visual de las
dependencias entre las tareas del proyecto.
Tarea Predec. Duracin
A
2
B
A
3
C
2
D
C
3
E
DII+1
2
F
BFI-1
3
G
D, E, F
3
H
GFF
2
82
Ingeniera de Software
Para construir un diagrama PERT se deben tener en cuenta las siguientes reglas
Los nodos representan instantes del proyecto. Cada nodo representa el inicio
mnimo (im) de las tareas que tienen origen en dicho nodo y el final mximo
(FM) de las tareas que llegan al mismo.
Slo puede haber un nodo inicial y un nodo final. O sea, slo puede haber un
nodo al que no llegue ninguna flecha (nodo inicial) y slo puede haber un
nodo del que no salga ninguna flecha (nodo final).
La numeracin de los nodos es arbitraria, si bien se reservan el nmero
menor (generalmente el 0 o el 1) para el nodo inicial y el mayor para el nodo
final.
Las flechas representan tareas y se dibujan de manera que representen las
relaciones de dependencia entre las tareas. Los recorridos posibles a travs
del diagrama desde el nodo inicial al nodo final, siguiendo el sentido de las
flechas, deben corresponder con las secuencias en que deben realizarse las
distintas tareas, o sea, los caminos del proyecto.
No
puede
haber
dos
nodos
unidos
por
ms
de
una
flecha.
83
Ingeniera de Software
84
Ingeniera de Software
2. CPM (Crtical Path Method) Mtodo del camino Crtico
El camino crtico en un proyecto es la sucesin de actividades que dan lugar al mximo
tiempo acumulativo. Determina el tiempo ms corto que podemos tardar en hacer el
proyecto si se dispone de todos los recursos necesarios. Es necesario conocer la
duracin de las actividades.
Este concepto es utilizado por dos mtodos:
Mtodo del tiempo estimado (CPM) La duracin de una actividad es la ms probable
de duracin. Tiempo que se empleara en condiciones normales (m). Situacin
determinista.
Mtodo del tiempo esperado (PERT) Determinacin probabilstica de los tiempos
esperados (Te), en funcin de los siguientes tiempos:
o
Duracin ms corta (a)
o
Duracin ms larga (b)
o
Duracin ms probable (m) (el mismo que en CPM)
o
Duracin esperada: Te = (a + 4m + b) / 6
Clculo del camino crtico
1. Calcular Te m segn el mtodo empleado para cada actividad. Se
coloca en el grafo encima o debajo de cada flecha.
2. Calcular las fechas early -fecha mnima de comienzo de la actividad,
MIC del suceso anterior- y last -fecha mnima de comienzo de la
actividad, MAC del suceso posterior- de las distintas actividades que
configuran el proyecto. (Calcular el MIC y el MAC de todos los sucesos
del proyecto).
3.
Clculo de las holguras.
4.
Identificacin del camino crtico.
Holguras
La holgura de una actividad es el margen suplementario de tiempo que tenemos para
determinar esa actividad. Las actividades crticas no tienen holgura.
Holgura de un suceso Hs:
Holgura
total
actividad Ht:
de
una
Margen suplementario de tiempo para esa actividad sin que se altere el MIC de
cualquier actividad.
85
Ingeniera de Software
Holgura independiente Hi:
86
Ingeniera de Software
Oct 2005
ID
Actividades
Inicio
Fin
Nov 2005
Dec 2005
Duracion
10/2 10/9 10/16 10/23 10/30 11/6 11/13 11/20 11/27 12/4 12/11 12/18
Actividad 1
03/10/2005
04/11/2005
5w
Actividad 2
07/11/2005
09/12/2005
5w
Actividad 3
03/10/2005
25/11/2005
8w
Actividad 4
03/10/2005
27/12/2005
12.40w
Actividad 5
03/10/2005
18/10/2005
2.40w
87
Ingeniera de Software
Los retardos se representan desplazando la tarea dependiente
hacia la derecha en el caso de retardos positivos y hacia la
izquierda en el caso de retardos negativos.
El diagrama de Gantt es un diagrama representativo, que permite visualizar fcilmente la
distribucin temporal del proyecto, pero es poco adecuado para la realizacin de clculos.
ACTIVIDADES COMPLEMENTARIAS
1. Investigue sobre TFEA (Facilitated application specification techniques).
Puede consultar en:
http://www.rspa.com/checklists/risk.html
2. Investigue y profundice sobre el tema: Estimacin del proyecto software. Elabore
un ensayo.
88
Ingeniera de Software
BIBLIOGRAFIA
IMPRESA
BRAUDE. Ingeniera de software, una perspectiva orientada a objetos. Mxico. 2003.
Alfaomega grupo editor. S.A.
GRUEGGE, BERND y DUTOIT, Allen H. Ingeniera de software orientado a objetos.
Mxico. 2002. Pearson Educacin.
HUMPHREY, Watts S. Introduccin al proceso de software personal. Pearson Addison
wesley. 2001.
MEYER, Bertrand. Construccin de software orientado a objetos. Segunda edicin.
Madrid. 1999. Prentice Hall.
NORRIS. Ingeniera de software explicada. Grupo Noriega editores de Colombia.
PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos,
tcnicas y mtodos para la gestin del cambio. Editorial Alfaomega-Rama.
PRESSMAN, Roger S. Ingeniera del Software. Un enfoque prctico. Quinta edicin.
Espaa. 2002. Editorial McGraw Hill.
PFLEEGER, Shari Lawrence. Ingeniera de software, teora y prctica. 1. Edicin.
Buenos Aires. Pearson educacin. 2002
SOMMERVILLE, Ian. Ingeniera de software. 6. Edicin. Pearson Addison Wesley.
2001
ELECTRNICA
http://www.rspa.com
http://www.pmi.org
http://www.4pm.com
http://www.projectmanagement.com
http://www.salud.gob.mx/unidades/dgces/gestion/page/05.html
www.ifpug.org
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
www.qsm.com
www.spr.com
89
Ingeniera de Software
UNIDAD 3.
CONTROL DE CALIDAD DEL SOFTWARE
INTRODUCCIN
La garanta de calidad del software es una actividad de proteccin que se aplica a cada
paso del proceso de software y que comprende: procedimientos, mtodos y
herramientas, revisiones tcnicas formales, tcnicas y estrategias de prueba,
procedimientos de garanta de ajustes y mecanismos de medida e informacin.
OBJETIVOS
GENERALES
Estudiar las tcnicas de gestin de calidad del software.
Determinar las tcnicas de prueba de software con el propsito de encontrar y
corregir errores antes de entregar el programa al cliente.
Definir las estrategias de prueba del software
Determinar y analizar las mtricas tcnicas del software
Determinar y aprender los beneficios de la reutilizacin del software.
ESPECIFICOS
Determinar qu es la calidad del software
Identificar los aspectos de gestin y las actividades especficas del
proceso de calidad del software.
Establecer la importancia de la garant de calidad del software as
como definir las estrategias para los planes de garanta de calidad del
software.
Definir los fundamentos de las pruebas del software.
Determinar que son las pruebas de caja negra, blanca, de camino
bsico y de estructura de control.
Identificar las pruebas de unidad, integracin, validacin y del sistema.
Identificar las mtricas del modelo de anlisis, del modelo de diseo,
del cdigo fuente, para pruebas y del mantenimiento.
Definir los fundamentos de la reutilizacin del software.
Determinar las dificultades para la reutilizacin
Determinar algunas sugerencias para establecer un enfoque de la
reutilizacin.
1. GARANTIA DE CALIDAD DEL SOFTWARE
90
Ingeniera de Software
La garanta de calidad del software (SQA, Software Quality Assurance GCS, Gestin de
calidad del software) es una actividad de proteccin que se aplica a lo largo de todo el
proceso del software.
2
Antes del siglo veinte, la garanta de calidad era responsabilidad nica de la persona
que construa el producto. La primera funcin de control y de garanta de calidad formal
fue introducida por los laboratorios Bell en 1916 y se extendi rpidamente por todo el
mundo de las manufacturas. Hoy en da, cada compaa tiene un mecanismo que
asegura la calidad de sus productos de hecho, durante la pasada dcada, se han usado
ampliamente como tcticas de mercado la declaracin explcita de mensajes que
ponan de manifiesto la calidad ofrecida por las compaas.
La historia de la garanta de calidad en el desarrollo de software ha sido paralela a la
historia en la fabricacin de hardware. Durante los primeros aos de informacin (los 50
y los 60), la calidad era responsabilidad nicamente del programador.
Durante los aos 70 se introdujeron estndares de garanta de calidad para el software
en los contratos militares de desarrollo de software y se han extendido rpidamente en
los desarrollos de software del mundo comercial.
La SQA forma parte de una funcin ms amplia de garanta de calidad y engloba las
siguientes actividades:
1. Un enfoque de gestin de calidad.
2. Mtodos y herramientas
3. Revisiones tcnicas formales
4. Documentacin
La calidad del software es importante porque:
Se reduce la repeticin de actividades o tareas.
Supone costos ms bajos de desarrollo.
Se mejora el proceso del software y por ende el producto.
1.1 Conceptos de calidad
http://www.pcm.gob.pe/portal_ongei/publicaciones/cultura/Lib5042/cap20.htm
91
Ingeniera de Software
1. Calidad
Segn ISO 9000: la calidad es el conjunto de caractersticas de una entidad que le
confieren su aptitud para satisfacer las necesidades expresadas y las implcitas.
Segn Roger Preesman: Calidad se define como una caracterstica o atributo de algo.
Otras definiciones plantean:
Es la medida en que las propiedades de un bien o servicio cumplen con los requisitos
establecidos en la norma o especificaciones tcnicas, as como con las exigencias
del usuario de dicho bien o servicio en cuanto a su funcionalidad, durabilidad y costo.
Aquellas caractersticas del producto que responden a las necesidades del cliente.
El significado histrico de la palabra calidad es el de aptitud o adecuacin al uso.
Se dice que un producto o servicio es de calidad cuando satisface las necesidades y
expectativas del cliente o usuario, en funcin de parmetros como:
o Seguridad que el producto o servicio confieren al cliente.
o Fiabilidad o capacidad que tiene el producto o servicio para cumplir las
funciones especificadas, sin fallo y por un perodo determinado de tiempo.
o Servicio o medida en que el fabricante y distribuidor responden en caso de
fallo del producto o servicio.
La Sociedad Americana para el Control de Calidad (A.S.Q.C.), define la calidad como
el conjunto de caractersticas de un producto, proceso o servicio que le confieren su
aptitud para satisfacer las necesidades del usuario o cliente.
Tipos de calidad
De Diseo
Son las caractersticas que
especifican para un elemento.
Comprende:
Requisitos
Especificaciones
Diseo del sistema
De Concordancia
Es el grado de cumplimiento de las
especificaciones de diseo.
Centrado en:
La implementacin
Debe ser: Alta
se
92
Ingeniera de Software
2. Control de Calidad
A nivel general, se pueden tener las siguientes definiciones:
Segn ISO:
Conjunto de tcnicas y actividades de carcter operativo, utilizadas para verificar los
requerimientos relativos a la calidad del producto o servicio.
En Ingeniera de Software,
Control de Calidad es el conjunto 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.
En el control de calidad:
1. Se deben definir todos los productos y las especificaciones mensurables en las
que se puedan comparar los resultados de cada proceso.
2. Las actividades pueden ser automticas, manuales o combinadas.
3. Existe un feedback (realimentacin)
3. Garanta de Calidad
A nivel General:
La garanta de la calidad o aseguramiento de calidad comprende todas aquellas
actividades de una empresa u organismo para conseguir y demostrar la calidad en
sta. Estas actividades se dividen en tres apartados:
o Evaluacin de la calidad
o Control de calidad
o Correcciones internas
93
Ingeniera de Software
Segn ISO:
Conjunto de acciones planificadas y sistemticas necesarias para proporcionar la
confianza adecuada de que un producto o servicio satisfar los requerimientos dados
sobre calidad.
En Ingeniera de Software,
Segn Roger S. Pressman: Consiste en la auditoria y las funciones de informacin de
la gestin. El objetivo es proporcionar la gestin para informar de los datos
necesarios sobre la calidad del producto, por lo que se va adquiriendo una visin ms
profunda y segura de que la calidad del producto est cumpliendo sus objetivos.
4. Coste de Calidad
Son todos los costos acarreados en la bsqueda de la calidad o en las actividades
relacionadas con la obtencin de la calidad.
Se dividen en:
Costes de prevencin:
Planificacin de la calidad
Revisiones tcnicas formales
Equipo de pruebas
Formacin
Costes de evaluacin:
Inspeccin en el proceso y entre
procesos
Calibrado y mantenimiento del equipo
Pruebas
94
Ingeniera de Software
1.2 La tendencia de la calidad
Se ha desarrollado una tendencia hacia la Gestin Total de Calidad (GTC), el cual
comprende los siguientes cuatro pasos:
1
Kaizen
Se refiere a un sistema de mejora continua en el proceso. El objetivo es
desarrollar un proceso que sea visible, repetible y mensurable.
El objetivo de la actitud Kaizen es el mejoramiento continuo en base a pequeos y
constantes cambios, mediante la eliminacin, reduccin o cambio de las cosas, sistemas,
medidas, etc.; que impiden un adecuado desempeo de las actividades.
En el marco empresarial, se traduce a que todos los miembros de una organizacin estn
comprometidos con la revisin constante de los procesos y la mejora permanente.
KAISEN est basado en las cinco S
SEIRE
SEITON
SEISO
SEIKETSU
SHITSUKE
95
Ingeniera de Software
Kansei
Se centra en el usuario del producto. Examinando la forma en que el usuario
aplica el producto, kansei conduce a la mejora en el producto mismo y
potencialmente al proceso que lo creo.
Kansei es un trmino japons donde la slaba kan significa sensitividad y sei significa
sensibilidad. Se usa para expresar la cualidad de un objeto de despertar placer en su uso.
As, hay objetos con mucho kansei y otros con absolutamente ninguno.
Cada vez ms, se est expresando la necesidad de tener en cuenta los aspectos subjetivos
(emocin, afecto, percepciones, sensaciones...) en la experiencia de uso, yendo ms all
del puro diseo visual.
Las necesidades bsicas que permitirn definir la estructura general del planteamiento
Kansei son como sigue (Nagamachi, 1995):
96
Ingeniera de Software
1.3 Garanta y aseguramiento de la calidad del software
La calidad del software se define como:
La calidad del software es el grado con el que un sistema, componente o proceso
cumple los requerimientos especificados y las necesidades o expectativas del cliente
o usuario. (IEEE, Std. 610-1990).
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 (Pressman, 2002)
Caractersticas
El plan debe involucrar:
Evaluaciones, Auditorias, revisiones, estndares que se
pueden aplicar al proyecto.
Procedimientos para informacin, seguimiento de errores
y realimentacin.
El grupo SQA debe adems documentar la informacin
necesaria.
Actividad
Caractersticas
Proceso de software del Se determina el proceso y se realiza la revisin de la
proyecto
descripcin del proceso para poder establecer los ajustes
de acuerdo a las polticas de la organizacin.
Ajustes al proceso del El grupo SQA se encarga de revisar, documentar y
software
verificar que se han hecho los ajustes al proceso.
Auditoria de los productos El grupo SQA esta en constante revisin del proceso
de software
software e informa peridicamente los resultados al gestor
del proyecto.
Documentacin
de Se debe documentar todas las desviaciones encontradas
productos software
a nivel:
97
Ingeniera de Software
Registro de ajustes
requisitos e informes
De procesos
De estndares y
Tcnicos
a Se realiza seguimiento a los requisitos que no se ajustan
y se elaboran los informes respectivos.
El grupo SQA, adems de tener a cargo el plan SQA, tambin debe coordinar, control y
gestionar los cambios, recopilar y analizar las mtricas del software.
98
Deteccin
Porcentaje de
eficiencia de la
deteccin de errores
Errores
pasados al
siguiente paso
Ingeniera de Software
En cada paso del proceso de desarrollo de software, se presentan errores que
pasan inadvertidos y que producen un mayor nmero de errores si las revisiones
no lo detectan.
Los errores amplificados corresponden, a aquellos errores que pasan inadvertidos
desde pasos anteriores. De igual forma se representa el porcentaje de eficiencia
de la deteccin de errores.
La RTF incluye:
Recorridos
Inspecciones
Revisiones cclicas
Evaluaciones tcnicas del software
Cada RTF debe estar debidamente planificada, controlada y atendida por el grupo
encargado de cada RTF.
Cada reunin debe tener las siguientes caractersticas:
Ingeniera de Software
Quienes participan en la reunin?
Ingeniera de Software
plan.
3. Limitar el debate y las No se debe perder tiempo debatiendo situaciones que
impugnaciones
no presenten unanimidad, es importante registrar el
hecho y dedicar otros tiempos para su debate.
4.
Enunciar
reas La resolucin de problemas se debe programar para
problemas
pero
no otros espacios despus de la reunin de revisin.
intentar
resolver
los
problemas que se pongan
de manifiesto.
5. Tomar notas escritas
Es buena idea utilizar diferentes herramientas para la
toma de notas, por ejemplo, pizarras, tableros,
computador, para que se pueda hacer seguimiento a
la asignacin de prioridades.
6. Limitar el nmero de Se debe limitar el nmero de revisores, los cuales
participantes e insistir en deben estar preparados para cada reunin y participar
la preparacin anticipada activamente en el proceso de revisin.
7. Desarrollar una lista de Se deben desarrollar listas de comprobacin para los
comprobacin para cada documentos de anlisis, diseo, codificacin y
producto que haya de ser pruebas.
revisado.
8. Disponer recursos y Cada RTF debe estar planificada e involucrar
una agenda para las RTF
modificaciones.
9.
Capacitacin
y Todas las personas que participen en el proceso de
entrenamiento
de
los revisin deben recibir un entrenamiento que se debe
revisores
basar en:
El proceso
Psicologa humana
10. Revisar las revisiones Son beneficiosas porque permiten descubrir
anteriores
problemas del proceso de revisin.
101
Ingeniera de Software
1.5 Garanta de calidad estadstica
La garanta de
cuantitativamente.
calidad
estadstica,
permite
establecer
la
calidad
ms
puede
consultar:
4. Una vez que se han identificado los defectos vitales, se acta para corregir los
problemas que han producido los defectos.
Ingeniera de Software
Posteriormente, un inspector revisa y registra los defectos de acuerdo con dichos tipos.
Despus de inspeccionar 942 errores, se obtuvo una tabla como la siguiente:
Error
Especificacin incompleta o errnea
Mala interpretacin de la comunicacin del cliente
Desviacin deliberada de la especificacin
Incumplimiento
de
los
estndares
de
programacin
Error en la representacin de los datos
Interfaz de mdulo inconsistente
Error en la lgica de diseo
Prueba incompleta o errnea
Documentacin imprecisa o incompleta
Error en la traduccin del diseo al lenguaje de
programacin
Interfaz hombre-maquina ambigua o inconsistente
Varios
Total
Frecuencia (No.)
205
156
48
25
130
58
45
95
36
60
28
56
942
Frecuencia
(No.)
205
156
Frec. %
48
5%
25
3%
130
14%
58
45
95
36
6%
5%
10%
4%
60
6%
28
3%
103
22%
17%
Ingeniera de Software
inconsistente
Varios
56
942
Total
6%
100%
El objetivo es determinar cules son los defectos que aparecen con mayor frecuencia.
Para esto se ordenan los datos de la tabla en orden decreciente de frecuencia:
Error
Frecuencia
(No.)
Especificacin incompleta o errnea
205
Mala
interpretacin
de
la
156
comunicacin del cliente
Error en la representacin de los
130
datos
Prueba incompleta o errnea
95
Interfaz de mdulo inconsistente
58
Error en la traduccin del diseo al
60
lenguaje de programacin
Desviacin
deliberada
de
la
48
especificacin
Error en la lgica de diseo
45
Documentacin
imprecisa
o
36
incompleta
Incumplimiento de los estndares de
25
programacin
Interfaz hombre-maquina ambigua o
28
inconsistente
Varios
56
Total
942
Frec. %
22%
17%
14%
10%
6%
6%
5%
5%
4%
3%
3%
6%
100%
De esta forma, resulta evidente cuales son los tipos de defectos ms frecuentes.
Podemos observar que los 4 primeros tipos de defectos representan ms del 60%. Por
el Principio de Pareto, se puede concluir que: La mayor parte de los defectos
encontrados pertenece slo a 4 tipos de defectos, de manera que si se eliminan las
causas que los provocan desaparecera la mayor parte de los defectos.
Fiabilidad del software
104
Ingeniera de Software
La fiabilidad del software es la probabilidad de que en un tiempo y entorno determinado
el software en operacin este libre de fallos.
Donde:
TMDF
TMDR
TMDF
(100%)
TMDF+TMDR
Estos datos pueden ser medidos o estimados mediante datos histricos o de desarrollo.
105
Ingeniera de Software
facilita el cambio internacional de bienes y servicios, y la cooperacin que se desarrolla
en las esferas de la actividad intelectual, la actividad cientfica, tecnolgica y
econmica.
ISO 9001. Quality Systems- Model for Quality Assurance in desing, development,
and
servicing.
Este es un
estndaraque
describe
el sistema
Laproduction,
serie ISO installation
9000 es un
conjunto
de normas
orientadas
ordenar
la gestin
de de
la
calidad
utilizado
para
mantener
el
desarrollo
de
un
producto
que
implique
diseo.
empresa que han ganado reconocimiento y aceptacin internacional debido al mayor
poder que tienen los consumidores y a la alta competencia internacional acentuada
norma
ISO 9001, son
un conjunto de reglas
de carcter
y organizativo
mejorar y potenciar
las
porLa los
procesos
integracionistas.
Algunas
desocial
estas
normaspara
especifican
requisitos
relaciones entre los miembros de una organizacin. Cuyo ltimo resultado, es mejorar las capacidades y
para
sistemas de calidad (ISO 9001, 9002, 9003) y otras dan una gua para ayudar en
rendimiento de la organizacin, y conseguir un aumento por este procedimiento de la calidad final del
la interpretacin
e implementacin del sistema de calidad (ISO 9000-2, ISO 9004-1)
producto.
Los 8 Principios bsicos de la gestin de la calidad o excelencia son:
1.
2.
Para la
3.
4.
5.
6.
7.
8.
106
Ingeniera de Software
ISO 9004-2. Quality Management and Quality System Elements Part 2. Este
ISO
9000-3.
Guidelines las
for Application
of ISOel9001
to the
Supply
and
documento
proporciona
directrices para
servicio
deDevelopment,
facilidades del
software
Maintainance
como soporte of
de Software.
usuarios. Este es un documento especfico que interpreta el ISO
9001 para el desarrollador de software.
La Ttulo:
norma para
"Gestin
de calidad
elementos
del sistema
de calidad. Parte 2: Directrices para servicios"
Normas
de gestin
de la ycalidad
y garanta
de la calidad
constituye
una
de
las
normas
ISO
de
la
serie
9000
relacionadas
conalladesarrollo,
gestin y suministro
el aseguramiento
de la
Parte 3: Orientaciones para la aplicacin de la Norma ISO 9001
y mantenimiento
calidad
en
diferentes
tipos
de
organizaciones.
del software
Norma
internacionalde los clientes, as como el logro y el mantenimiento de la calidad
La Naturaleza:
satisfaccin de
las expectativas
mbito
deseada
por los mismos, son metas deseables para cualquier organizacin. Sin embargo, estos aspectos
Desarrollo
de Sistemas
de Informacin.
tienen un inters
social ms
claro cuando
la organizacin se dedica a la prestacin de servicios.
Procesos del ciclo de vida.
Calidad del software.
Estructura
Caractersticas de los servicios
Campo de aplicacin y alcance: Esta parte de la ISO 9000 contiene orientaciones que facilitan la
Responsabilidad gerencial
Tales orientaciones describen las clases de control y los mtodos sugeridos para la produccin del software,
Proceso de comercializacin
Responsabilidad de la gestin.
Proceso de diseo
Sistema de la calidad.
107
Ingeniera de Software
ACTIVIDADES COMPLEMENTARIAS
108
Ingeniera de Software
1. Investigue y elabore un ensayo argumentativo sobre la evolucin histrica de la
Calidad.
2. Es posible evaluar la calidad del software si el cliente no se pone de acuerdo
sobre lo que se supone que ha de hacer? Justifique su respuesta y argumente.
3. La calidad y la fiabilidad son conceptos relacionados pero son fundamentalmente
diferentes en varias formas. Elabore un cuadro de diferencias.
4. Si se le da la responsabilidad de mejorar la calidad del software en su
organizacin. Qu es lo primero que hara? Qu sera lo siguiente?
5. Una reunin de revisin tcnica formal slo es efectiva si todo el mundo se
prepara por adelantado. Cmo descubrira que uno de los participantes no se
preparado? Qu hara si fuera el jefe de divisin?
6. Investigue y ample la informacin de ISO 9000-3. Elabore un ensayo.
109
Ingeniera de Software
2. TCNICAS DE PRUEBA DEL SOFTWARE
Las pruebas del software comprenden el examen o exploracin final de las
especificaciones del diseo y de la codificacin.
Las pruebas del software son un conjunto de evaluaciones cuyo fin es identificar y
descubrir un error.
Las tcnicas de pruebas del software permiten disear pruebas que:
1. Comprueben la lgica interna de los componentes software
2. Verifiquen los dominios de entrada y salida del programa para descubrir errores
en la funcionalidad, el comportamiento y rendimiento.
Descubrir un error
Mostrar un error no descubierto hasta ese momento
Descubrir un error no detectado hasta ese momento
Las
tienen los siguientes principios:
pruebas
110
Ingeniera de Software
Las pruebas deben tener un seguimiento hasta los requisitos del cliente.
Las pruebas deben planificarse antes de que empiecen.
Es aplicable el principio de Pareto a la prueba del software.
No es posible las pruebas exhaustivas
Las pruebas deben ser realizadas por un equipo independiente
Un software debe ser fcil de probar, para lo cual se puede tener en cuenta las
siguientes caractersticas que propone Pressman:
Caracterstica
Operatividad
Observacin
Cunto mejor funcione, ms eficientemente se puede probar
El sistema tiene pocos errores
Ningn error bloquea la ejecucin de las pruebas
El producto evoluciona en fases funcionales
Observabilidad Lo que se ve es lo que se prueba
Se genera una salida distinta para cada entrada
Todos los factores que afectan a los resultados estn
visibles
Un resultado incorrecto se identifica fcilmente
Los errores internos se detectan automticamente
Se informa automticamente de los errores internos
El cdigo fuente es accesible.
Controlabilidad Cunto mejor se pueda controlar el software, ms se puede
automatizar y optimizar
Todo el cdigo es ejecutable a travs de alguna
combinacin de entrada
El ingeniero de pruebas puede controlar los estados y las
variables del hardware y software
Los formatos de las entradas y los resultados son
consistentes y estructurados
Capacidad de Controlando el mbito de las pruebas, podemos aislar ms
descomposici rpidamente los problemas y llevar a cabo pruebas de regresin
n
El software esta construido con mdulos independientes
Los mdulos de software se pueden probar
independientemente.
Simplicidad
Cunto menos haya que probar, ms rpidamente se puede
probar
Simplicidad funcional
Simplicidad estructural
Simplicidad del cdigo
111
Ingeniera de Software
Caracterstica
Estabilidad
Observacin
Cuanto menos cambios, menos interrupciones a las pruebas
Los cambios del software son infrecuentes
Los cambios del software estn controlados
Los cambios del software no invalidan las pruebas
existentes
El software se recupera bien de los fallos
Facilidad
de Cuanta ms informacin se tenga, ms inteligentes eran las
comprensin
pruebas
El diseo se ha entendido perfectamente
Las dependencias entre los componentes internos,
externos y compartidos se han entendido perfectamente
Se han comunicado los cambios del diseo
La documentacin tcnica es accesible
Caja
blanca
Camino
Bsico
De
estructuras
de control
112
Caja
Negra
De entornos
especializados
Ingeniera de Software
Prueba de caja blanca
Esta prueba se centra en la estructura interna del programa. En este caso la prueba
consiste en probar todos los posibles caminos de ejecucin a travs de las
instrucciones del cdigo, que puedan trazarse.
Salida
Entrada
Complejidad ciclomtica
Es una mtrica que proporciona una medicin cuantitativa de la complejidad lgica de
un programa.
La complejidad ciclomtica est basada en la teora de grafos por lo que es importante
recordar:
1
Nodos
Aristas
2,3
6
7
R3
R2
4,5
R1
9
10
11
113
Region
Ingeniera de Software
Donde:
A
N
Donde:
P
V(G) = A N + 2
Es el nmero de nodos predicado contenidos en el grafo de flujo
G
Entonces,
2,3
6
7
V(G) = P4,5+ 1
Ingeniera de Software
Se centra en la seleccin de caminos de prueba de un programa de acuerdo con la
ubicacin de las definiciones y los usos de las variables del programa.
Esta prueba es til para seleccionar caminos de prueba de un programa que
contenga sentencias if o bucles anidados.
3. Prueba de bucles
Se centra en la validez de las construcciones de bucles. Se definen los siguientes
tipos de bucles:
Bucles Simples
Se debe aplicar:
Pasar por alto totalmente el bucle
Pasar una sola vez por el bucle
Pasar dos veces por el bucle
Hacer m pasos por el bucle con m < n
Hacer n-1, n y n+1 pasos por el bucle
Donde n, es el nmero mximo de pasos permitidos por el bucle.
Bucles Anidados
Se debe:
Comenzar por el bucle ms interior
Llevar a cabo las pruebas de bucles simples para el bucle ms
interior
Progresar hacia fuera, llevando a cabo pruebas para el siguiente
bucle
Continuar hasta cuando se prueben todos los bucles.
115
Ingeniera de Software
Bucles Concatenados
Se pueden probar con el mtodo para buques simples, siempre y
cuando los bucles sean independientes.
Cuando los bucles no son independientes se utiliza el enfoque para
bucles anidados.
Bucles no estructurados
Estos bucles se deben redisear.
Entrada
Salida
Funciones
funciones
Ingeniera de Software
Prueba de interfaces grficas de usuario
Se utilizan listas de chequeo:
Para ventanas:
o Se abren las ventanas mediante rdenes basadas en el teclado o en un
men?
o Se puede ajustar el tamao, mover y desplegar la ventana?
o Se regenera adecuadamente cuando se escribe y se vuelve a abrir?
Para mens emergentes y operaciones con el ratn:
o Se muestra la barra de men apropiada en el contexto apropiado?
o Es correcto el tipo, tamao y formato del texto?
o Si el ratn tiene varios botones, estn apropiadamente reconocidos en el
contexto?
Entrada de datos:
o Se repiten y son introducidos adecuadamente los datos alfanumricos?
o Funcionan adecuadamente los modos grficos de entrada de datos? (p.e.
barra deslizante)
o Se reconocen adecuadamente los datos no vlidos?
o Son inteligibles los mensajes de entrada de datos?
Prueba de arquitectura cliente / servidor
Debido a la complejidad del sistema, sern necesarias varias fases:
o Pruebas de funcionalidad de la aplicacin. Se puede llevar a cabo sobre
mquinas de desarrollo y estaciones de trabajo de forma paralela
o Pruebas de carga del servidor
o Pruebas de integridad de datos: Son especialmente importantes en el caso de
bases de datos distribuidas
o Pruebas transaccionales
o Pruebas de red
Prueba de la documentacin y facilidades de ayudas
Se puede dar en dos sentidos:
Revisin e inspeccin: examina la documentacin para comprobar la claridad de la
misma.
Prueba en vivo: se utiliza la documentacin junto al uso del software.
117
Ingeniera de Software
Prueba de sistemas de tiempo real
Se puede aplicar los siguientes pasos:
Prueba de tareas: Se aplican pruebas de caja blanca y caja negra a cada tarea.
Pretende descubrir errores en la lgica y en el funcionamiento.
Prueba de comportamiento: Se simula el comportamiento del sistema en tiempo
real y se examina el comportamiento como consecuencia de sucesos externos.
Prueba intertareas: Se prueban las tareas asncronas que se comunican con otras,
para determinar si se producen errores de sincronismo entre las tareas.
Prueba del sistema: Se realizan pruebas completas al sistema para descubrir
errores en la interfaz software/hardware.
118
Ingeniera de Software
ACTIVIDADES COMPLEMENTARIAS
1. Investigue y ample la informacin relacionada con:
o
o
o
o
119
Ingeniera de Software
3. 3ESTRATEGIAS DE PRUEBA DEL SOFTWARE
La estrategia proporciona la descripcin de los pasos que hay que llevar a cabo como
parte de la prueba, cundo se deben planificar y realizar esos pasos, y cunto esfuerzo,
tiempo y recursos se van a requerir.
Una estrategia de prueba contiene:
Planificacin de la prueba
Diseo de casos de prueba
Ejecucin de las pruebas
Agrupacin y evaluacin de datos
Las pruebas comienzan a nivel de mdulo (en los sistemas orientados a objetos,
las pruebas empiezan a nivel de clase o de objeto) y trabajan hacia fuera, hacia
la integracin de todo el sistema.
Segn el momento, son apropiadas diferentes tcnicas de prueba
La prueba la lleva a cabo el responsable del desarrollo del software y (para
grandes proyectos) un grupo independiente de pruebas.
La prueba y la depuracin son actividades diferentes, pero la depuracin se debe
incluir en cualquier estrategia de prueba
120
Ingeniera de Software
3.1.1 Verificacin y validacin
Verificacin
Es el conjunto de actividades que aseguran que el software implementa correctamente
una funcin especfica.
Estamos construyendo el producto correctamente?
Validacin
Es el conjunto de actividades diferentes que aseguran que el software construido se
ajusta a los requisitos del cliente.
Estamos construyendo el producto correcto?
121
Ingeniera de Software
3.1.3 Estrategia de prueba del software
Los niveles de la estrategia para la prueba del software se pueden ver en el siguiente
grafico:
Pruebas de validacin
Diseo y construccin de la
arquitectura software
Pruebas de integracin
Prueba de unidad
Estrategia de prueba
122
Ingeniera de Software
Requisitos
Pruebas
de alto nivel
Prueba de
integracin
Diseo
Codificacin
Prueba
De
unidad
Direccin de la prueba
123
Ingeniera de Software
Si se desea implementar una estrategia de software con xito se debe plantea que se
deben abordar los siguientes si se desea implementar con xito una estrategia de
prueba del software se debe tener presente:
Especificar los requisitos del producto de manera cuantificable mucho antes de
que comiencen las pruebas
Tambin se debe evaluar: portabilidad, facilidad de mantenimiento y facilidad de uso
Establecer los objetivos de la prueba de manera explcita
Se debe establecer:
Objetivos especficos de la prueba
Cobertura de la prueba
Tiempo medio de fallo
El coste para encontrar y arreglar errores
Densidad de fallos remanente o frecuencia de ocurrencia
Horas de trabajo por prueba
Comprender qu usuarios van a manejar el software y desarrollar un perfil para
cada categora de usuario
Se debe:
Describir el escenario de interaccin para cada clase de usuario
Desarrollar un plan de prueba que haga hincapi en la prueba de ciclo rpido
El equipo de ingeniera de software, debe aprender a probar en ciclos rpidos y que se
pueda probar sobre el terreno.
Construir un software robusto diseado para probarse a s mismo.
El software debe ser capaz de diagnosticar ciertas clases de errores. Adems, el
diseo debe incluir pruebas automatizadas y pruebas de regresin.
Usar revisiones tcnicas formales efectivas como filtro antes de la prueba
Las revisiones tcnicas formales ayudan a reducir el esfuerzo de prueba necesaria
para la produccin del software.
Llevar a cabo revisiones tcnicas formales para evaluar la estrategia de prueba y
los propios casos de prueba.
Permiten descubrir inconsistencias, omisiones y errores claros en el enfoque de la
prueba.
Ingeniera de Software
Permite usar un enfoque estadstico de control del proceso para la prueba del
software.
Mdulo
~~~~~~
~~~~~~
~~~~~~
~~~~~~
Interfaz
Estructuras de datos locales
Condiciones lmite
Caminos independientes
Caminos de manejo de errores
Casos de
prueba
Figura. Prueba de Unidad. (Fuente: Roger Pressman, 2002)
125
Ingeniera de Software
A continuacin, se ilustra el entorno para la prueba de unidad.
Controlador
Interfaz
Estructuras de datos locales
Condiciones lmite
Caminos independientes
Caminos de manejo de errores
Mdulo que
se va a
probar
Resguardo
Resguardo
Casos de
prueba
RESULTADOS
Para cada mdulo que se va a probar, se crea un controlador (un programa principal)
que permite aceptar los datos del caso de prueba, los pasa al mdulo y luego imprime
los resultados.
126
Ingeniera de Software
3.3 Prueba de integracin del sistema
La prueba de integracin es una tcnica para construir la estructura del programa
mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores
asociados con la interaccin.
M3
M6
M4
M7
M8
Integracin descendente
Ingeniera de Software
3. Se llevan a cabo pruebas cada vez que se integra un nuevo mdulo.
4. Tras terminar cada conjunto de prueba, se reemplaza otro resguardo con el
mdulo real.
5. Se hace la prueba de regresin para asegurarse de que no se han introducido
errores nuevos.
El proceso contina desde el paso dos hasta que se haya construido la estructura del
programa entero.
3.3.2 Integracin ascendente
Empieza la construccin y la prueba con los niveles ms bajos de la estructura del
programa. Dado que los mdulos se integran de abajo hacia arriba, el proceso
requerido de los mdulos subordinados siempre est disponible y se elimina la
necesidad de resguardos.
Se puede implementar una estrategia de integracin ascendente mediante los
siguientes pasos:
1. Se combina los mdulos de bajo nivel en grupos que realicen una subfuncin
especfica del software.
2. se describe un controlador (un programa de control de la prueba) para coordinar
la entrada y la salida de los casos de prueba.
3. Se prueba el grupo.
4. Se eliminan los controladores y se combinan los grupos movindose hacia arriba
por la estructura del programa.
La integracin sigue el esquema de la siguiente figura:
Mc
Ma
D1
Mb
D2
D3
Grupo 3
Grupo 1
Grupo 2
Integracin ascendente
128
Ingeniera de Software
Se combinan los mdulos para formar los grupos 1,2 y 3. Cada uno de los grupos se
somete a prueba mediante un controlador (mostrado como un bloque punteado). Los
mdulos de los grupos 1 y 2 son subordinados Ma. Los controladores D1 y D2 se
eliminan y los grupos interaccionan directamente con Ma. De forma similar, se elimina el
controlador D3 del grupo 3 antes de la integracin con el mdulo M b. Tanto Ma como Mb
se integraran finalmente con el mdulo Mc y as sucesivamente.
3.3.3 Prueba de regresin
La prueba de regresin consiste en volver a ejecutar un subconjunto de pruebas que se
han llevado a cabo anteriormente para asegurarse de que los cambios no han
propagado efectos colaterales no deseados. La prueba de regresin es la actividad que
ayuda a asegurar que los cambios no introducen un comportamiento no deseado o
errores adicionales.
El conjunto de pruebas de regresin contiene tres clases diferentes de casos de prueba:
oo Una muestra representativa de pruebas que ejercite todas las funciones del
software;
oo Pruebas adicionales que se centran en las funciones del software que se van a
ver probablemente afectadas por el cambio;
oo Pruebas que se centran en los componentes del software que han cambiado.
129
Ingeniera de Software
La prueba de humo facilita una serie de beneficios cuando se aplica sobre proyectos de
ingeniera de software complejos y crticos por su duracin:
oo
oo
oo
oo
Prueba Beta
Se lleva a cabo por los usuarios finales del
software en los lugares de trabajo de los
clientes. El desarrollador no est presente
en esta prueba. La prueba beta es una
aplicacin en vivo del software en un
entorno que no puede ser controlado por
el desarrollador. El cliente registra todos
los problemas (reales o imaginarios) que
encuentran durante la prueba e informa al
desarrollador. Como resultado de los
problemas informados durante la prueba
beta, el desarrollador del software lleva a
cabo modificaciones y as prepara una
versin del producto de software para toda
la clase de clientes.
Ingeniera de Software
recuperacin se lleva a cabo apropiadamente.
Prueba de seguridad
Intenta verificar que los mecanismos de proteccin incorporadas en el sistema lo
protegern, de hecho, de accesos impropios.
Prueba de resistencia (stress)
Ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o
volmenes anormales. Por ejemplo:
1. Disear pruebas especiales que generen 10 interrupciones por segundo,
cuando las normales son una o dos;
2. Incrementar las frecuencias de datos de entrada en un orden de magnitud con
el fin de comprobar cmo responden las funciones de entrada.
3. Ejecutar casos de prueba que requieran el mximo de memoria o de otros
recursos.
4. Disear casos de prueba que puedan dar problemas en un sistema operativo
virtual.
5. Disear casos de prueba que produzcan excesivas bsquedas de datos
residentes en disco.
Esencialmente, el responsable de la prueba intenta romper el programa.
Prueba de rendimiento
Permite probar el rendimiento del software en tiempo de ejecucin dentro del contexto
de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del
proceso de la prueba. Para llevar a cabo esta prueba, deben estar integrados
completamente todos elementos del sistema.
3.3.7 Depuracin
La depuracin ocurre como consecuencia de una prueba efectiva. Cuando un caso de
prueba descubre un error, la depuracin es el proceso que provoca la eliminacin del
error.
Casos
de
prueba
Ejecucin de casos
Resultados
Pruebas
adicionales
131
Causas
sospechadas
Pruebas de
Regresin
Depuracin
Correcciones
Causas
Ingeniera de Software
En este ltimo caso, la persona que realiza la depuracin debe sospechar la causa,
disear un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve
hacia atrs a la correccin del error de una forma interactiva.
Durante la depuracin se encuentran errores que van desde lo ligeramente inesperado
hasta lo catastrfico.
La depuracin tiene el objetivo primordial de encontrar y corregir la causa de un error
en el software.
132
Ingeniera de Software
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
.
2
.
3
.
Ingeniera de Software
Podr utilizar alguna parte del utilizarse en otras aplicaciones
software en otra aplicacin?
Interoperabilidad
El esfuerzo necesario para comunicar la aplicacin
Podr comunicarse con otras con otras aplicaciones o sistemas informticos
aplicaciones
o
sistemas
informticos?
134
Ingeniera de Software
Facilidad de mantenimiento
Flexibilidad
Facilidad de prueba
Portabilidad
Reusabilidad
Interoperatividad
Correccin
Fiabilidad
Usabilidad
Integridad
Eficiencia
Ingeniera de Software
identifica los errores que ocurren.
Modularidad
La independencia funcional de componentes de programa.
Operatividad
La facilidad de operacin de un programa
Seguridad
La disponibilidad de mecanismos que controlan o protegen los
programas y los datos.
Autodocumentacin El grado en que el cdigo fuente proporcionan documentacin
significativa
Simplicidad
El grado de facilidad con que se puede entender un programa.
Independencia del El grado de independencia de programa respecto a las
sistema software
caractersticas del lenguaje de programacin no estndar,
caractersticas del sistema operativo y otras restricciones del
entorno.
Trazabilidad
La capacidad de seguir una representacin del diseo o un
componente real del programa hasta los requisitos.
Formacin
El grado en que ayuda el software a manejar el sistema o los
nuevos usuarios.
Facilidad de auditoria
Exactitud
Estandarizacin de comunicaciones
Complexin
Complejidad
Concisin
Consistencia
Estandarizacin de datos
Tolerancia a errores
Eficiencia de ejecucin
Capacidad de expansin
Generalidad
Independencia del hardware
Instrumentacin
Modularidad
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
136
X
X
X
X
X
X
X
X
Usabilidad
Interoperatividad
Portabilidad
Reusabilidad
de
Capacidad
pruebas
Flexibilidad
Integridad
Eficiencia
Fiabilidad
Factor de calidad
Correccin
Mtrica de la calidad
del software
Mantenimiento
A continuacin, se presenta la relacin entre los factores de calidad del software y las
mtricas de la lista anterior.
Ingeniera de Software
Operatividad
Seguridad
Autodocumentacin
Simplicidad
Independencia del sistema
Trazabilidad
Facilidad de formacin
X
X
X
X
X
X
X
X
X
X
3.4.2 FURPS
El modelo de McCall ha servido de base para modelos de calidad posteriores, y este es
el caso del modelo FURPS, producto del desarrollo de Hewlett-Packard. En este
modelo se desarrollan un conjunto de factores de calidad de software, bajo el acrnimo
de FURPS.
F
U
R
P
S
Functionality - funcionalidad
Usability usabilidad facilidad de uso
Reliability - confiabilidad
Performance - desempeo
Supportability - capacidad de soporte
Facilidad de uso
Confiabilidad
Rendimiento
Atributos
Caractersticas y capacidades del programa
Generalidad de las funciones
Seguridad del sistema
Factores humanos
Factores estticos
Consistencia de la interfaz
Documentacin
Frecuencia y severidad de las fallas
Exactitud de las salidas
Tiempo medio de fallos
Capacidad de recuperacin ante fallas
Capacidad de prediccin
Velocidad del procesamiento
Tiempo de respuesta
Consumo de recursos
Rendimiento efectivo total
137
Ingeniera de Software
Capacidad de Soporte
Eficacia
Extensibilidad
Adaptabilidad
Capacidad de pruebas
Capacidad de configuracin
Compatibilidad
Requisitos de instalacin
Confiabilidad
Usabilidad
Eficiencia
Mantenibilidad
Subcaracterstica
Adecuacin
Exactitud
Interoperabilidad
Seguridad
Madurez
Tolerancia a fallas
Recuperabilidad
Entendibilidad
Capacidad de aprendizaje
Operabilidad
Comportamiento en tiempo
Comportamiento de recursos
Analizabilidad
138
Ingeniera de Software
Portabilidad
Modificabilidad
Estabilidad
Capacidad de pruebas
Adaptabilidad
Instalabilidad
Reemplazabilidad
Los principios que se pueden asociar con la formulacin de las mtricas tcnicas son
los siguientes:
oo Los objetivos de la medicin que deben establecerse antes de empezar la
recoleccin de datos.
oo Todas las tcnicas sobre mtricas deben definirse sin ambigedades.
oo Las mtricas deberan obtenerse basndose en una teora vlida para el dominio
de aplicacin.
oo Hay que hacer las mtricas a medida para acomodar mejor los productos y
procesos especficos.
Roche sugiere los siguientes principios para la recoleccin y anlisis de datos:
oo Siempre que sea posible, la recogida de datos y el anlisis debe automatizarse.
139
Ingeniera de Software
oo Se deben aplicar tcnicas estadsticas vlidas para establecer las relaciones
entre los atributos internos del producto y las caractersticas externas de la
calidad.
oo Se deben establecer directrices de interpretacin y recomendaciones para todas
las mtricas.
La mtrica obtenida y las medidas que conducen a ello deben tener las siguientes
caractersticas:
oo
oo
oo
oo
oo
oo
140
Ingeniera de Software
Mtrica Bang
Puede aplicarse para desarrollar una indicacin del tamao del software a implementar
como consecuencia del modelo del anlisis.
Para calcular la mtrica bang, el desarrollador de software evala primero un conjunto
de primitivas. Las primitivas se determinan evaluando el modelo de anlisis y
desarrollando cuentas para los siguientes elementos:
Primitivas funcionales (Pfu)
Elementos de datos (ED)
Objetos (OB)
Relaciones (RE)
Estados (ES)
Transiciones (TR
Primitivas modificadas de Funciones que caen fuera del lmite del sistema y que
funcin manual (PMFu)
deben modificarse para acomodarse al nuevo
sistema.
Elementos de datos de Aquellos elementos de datos que se introducen en el
entrada (EDE)
sistema.
Elementos de datos de Aquellos elementos de datos que se sacan en el
salida (EDS)
sistema.
Elementos
de
datos Aquellos elementos de datos que son retenidos
retenidos (EDR)
(almacenados) por el sistema.
Muestras (tokens) de datos Las muestras de datos que existen en el lmite de la i(TCi)
sima primitiva funcional (evaluada para cada
primitiva).
Conexiones de relacin Las relaciones que conectan el i-simo objeto en el
(Rei)
modelo de datos con otros objetos.
141
Ingeniera de Software
3.5.2 Mtricas del modelo de diseo
Se concentran en las caractersticas de la arquitectura del programa, con nfasis en la
estructura arquitectnica y en la eficiencia de los mdulos.
Estas mtricas son de caja negra en el sentido que no requieren ningn conocimiento
del trabajo interno de un mdulo en particular del sistema.
Card y Glass definen las siguientes tres medidas de complejidad:
Fenton sugiere varias mtricas de morfologa simples que permiten comparar diferentes
arquitecturas mediante un conjunto de dimensiones directas.
Ingeniera de Software
Tamao= n + a. Donde n es el nmero de nodos (mdulos) y a es el nmero de
arcos (lneas de control). Para la arquitectura mostrada se tiene tamao=
17+18=35.
Profundidad= camino ms largo desde el nodo raz a un nodo hoja. Para el
ejemplo Profundidad= 4
Amplitud=nmero mximo de nodos de cualquier nivel de la arquitectura. Para el
ejemplo amplitud= 6
Relacin arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura y
proporciona una indicacin sencilla de acoplamiento de la arquitectura. Para el
ejemplo r=18/17= 1.06
Halste
ad
utiliza medidas primitivas para desarrollar expresiones par la longitud global del
programa; volumen mnimo potencial para un algoritmo; el volumen real (nmero de bits
requeridos para especificar un programa); el nivel del programa (una medida de la
complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y
otras caractersticas tales como el esfuerzo de desarrollo, tiempo de desarrollo e incluso
el nmero esperado de fallos en el software.
Halstead propone las siguientes mtricas:
Longitud N se puede estimar como: N = n1 log2 n1 + n2 log2 n2.
Volumen de programa se define como:
V = N n1 log2(n1 + n2).
Tomando en cuenta que V variar con el lenguaje de programacin y
representa el volumen de informacin (en bits) necesarios para especificar un
programa.
143
Ingeniera de Software
NP = 1/[(n1/2) x (N2/n2)]
(Ec. 1)
El porcentaje del
e = V/NP
(Ec. 2)
pruebas
a
mdulo k se puede estimar utilizando la siguiente relacin:
esfuerzo global de
asignar
a
un
Donde e(k) se calcula para el mdulo k utilizando las ecuaciones (Ec. 1) y (Ec. 2), la
suma en el denominador de la ecuacin (Ec. 3) es la suma del esfuerzo de la ciencia
del
software
Porcentaje
de
esfuerzo
de
pruebas(k)
=
e(k)/e(i)
(Ec.
3)
a
lo
largo de
todos
los
mdulos del sistema.
A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una
indicacin de la complecin de las pruebas:
144
Ingeniera de Software
Medida
de Proporciona una indicacin de cuantos requisitos se han probado
amplitud de las del nmero total de ellos. Indica la complecin del plan de
pruebas.
pruebas.
Profundidad de Medida del porcentaje de los caminos bsicos independientes
las pruebas
probados con relacin al nmero total de estos caminos en el
programa. Se puede calcular una estimacin razonablemente
exacta del nmero de caminos bsicos sumando la complejidad
ciclomtica de todos los mdulos del programa.
Perfiles de fallos
Se emplean para dar prioridad y categorizar los errores. La
prioridad indica la severidad del problema. Las categoras de los
fallos proporcionan una descripcin de un error, de manera que se
puedan llevar a cabo anlisis estadstico de errores.
145
Ingeniera de Software
ACTIVIDADES COMPLEMENTARIAS
146
Ingeniera de Software
Las siguientes herramientas han sido compiladas por Tigris.org, pgina web
http://www.tigris.org/
Tigris.org es una comunidad, de tamao medio, de cdigo abierto enfocado en la
construccin de mejores herramientas para el desarrollo colaborativo de software. La
misind e Tigris.org es construir Herramientas de Ingeniera de Software Open Source o
de cdigo abierto. Tigris.org est alojado por CollabNet, se convierte en el mayor y ms
completo movimiento de cdigo abierto que ha ms atrado desarrolladores de cdigo
abierto de muchas organizaciones.
Uso
Subversion es una versin de cdigo abierto de un sistema de
control. Fundada en 2000 por CollabNet, Inc., el proyecto y
software Subversion han tenido un xito increble en la ltima
dcada. Subversion ha gozado y sigue gozando de amplia
adopcin, tanto en el campo de cdigo abierto como en el
mundo empresarial.
Subversion
http://subversion.apache.org/
Subversion existe para ser universalmente reconocido y
adoptado como un cdigo abierto, sistema centralizado de
control de versin, el cual se caracteriza por su fiabilidad
como un refugio seguro para los datos valiosos, la simplicidad
de su modelo y su uso, y su capacidad para apoyar las
necesidades de una amplia variedad de usuarios y proyectos,
desde particulares a las operaciones empresariales a gran
escala.
Subclipse es un eqipo proveedor de soporte para el plug-in
http://subclipse.tigris.org/
Eclipse, para la subversin dentro de la IDE de Eclipse. El
Subclipse
147
Disponible en:
Ingeniera de Software
software se distribuye bajo la Licencia Pblica Eclipse (EPL)
1.0 Licencia de cdigo abierto. Este software bsicamente
provee herramientas grficas para la organizacin de la
documentacin de cualquier proyecto de software, puede
llevarse al ms mnimo nivel de descripcin detalles del
software como: modificaciones, instalaciones, defectos,
correcciones, soportes, etc.
TortoiseSVN es una herramienta muy fcil de usar para el
control de revisiones / control de versiones / software de
control de cdigo fuente para Windows.
TortoiseSVN No es una integracin de un IDE especfico, por lo que se
http://tortoisesvn.tigris.org/
puede utilizar con herramientas de desarrollo de cualquier
tipo, especialmente propietarias. TortoiseSVN es de uso
gratuito
RapidSVN, es un software con herramientas visuales
RapidSVN especiales y fciles de manejar para clientes, que les permite http://rapidsvn.tigris.org/
un mejor control de revisiones de arquitecturas.
Uso
scarab
bbapi
leo
148
Disponible en:
http://scarab.tigris.org/
http://bbapi.tigris.org/
http://leo.tigris.org/
Ingeniera de Software
phrac
http://phrac.tigris.org/
Uso
Especificaciones de requerimientos para desarrollo de
xmlbasedsrs
software como documentos XML
Herramientas para gestin de requisitos de proyectos
ipmrt
inteligentes
jreq
Sistema para administracin de proyectos flexibles
Herramientas y lenguajes sencillos para ordenamiento, filtrado
reqs
y procesamiento de informacin de proyectos software.
Disponible en:
http://xmlbasedsrs.tigris.org/
http://ipmrt.tigris.org/
http://jreq.tigris.org/
http://reqs.tigris.org/
149
Ingeniera de Software
Herramienta
Uso
argouml
Una herramienta de diseo UML con apoyo cognitivo
argoeclipse PlugIn Eclipse para diseo UML usando ArgoUML
Permite la generacin de vista de impresin de los modelos de
argoprint
ArgoUML
argosoffice Plugin Star/OpenOffice para ArgoUML
Disponible en:
http://argouml.tigris.org/
http://argoeclipse.tigris.org/
http://argoprint.tigris.org/
http://argosoffice.tigris.org/
Disponible en:
http://subetha.tigris.org/
http://eyebrowse.tigris.org/
http://productreviews.tigris.org/
http://cowiki.tigris.org/
Uso
Disponible en:
150
Ingeniera de Software
antelope
frameworx
buildinterceptor
propel
http://antelope.tigris.org/
http://frameworx.tigris.org/
http://buildinterceptor.tigris.org/
http://propel.tigris.org/
151
Disponible en:
http://aut.tigris.org/
http://maxq.tigris.org/
http://perfbase.tigris.org/
http://storyteller.tigris.org/
Ingeniera de Software
CATEGORA: deployment- Tools for deploying and updating software
Enlace: http://deployment.tigris.org//
Herramientas para implementacin y actualizacin de software. Herramientas de
implementacin ayudan a automatizar y gestionar la tarea de entregar versiones
empaquetadas de software para los usuarios finales.
Dentro de esta categora se pueden mencionar las siguientes herramientas:
Herramienta
Uso
autoinst
Sistema controlador de versiones para host UNIX.
carnarvon
Herramienta para anlisis arqueolgico de software.
Herramientas para administracin e implementacin de
current
paquetes open-source
vordos
Plataforma de desarrollo de aplicaciones en internet
Disponible en:
http://deployment.tigris.org/
http://carnarvon.tigris.org/
http://current.tigris.org/
http://vordos.tigris.org/
152
Disponible en:
http://dig.tigris.org/
http://lptools.tigris.org/
http://nteam.tigris.org/
http://readyset.tigris.org/
Ingeniera de Software
Componentes de software reutilizables. Los sistemas actuales de software son cada
vez ms complejos. Sin embargo, el tiempo y esfuerzo disponible para producir estos
sistemas son cada vez ms cortos.
La reutilizacin del software es una de las soluciones ms importantes para el desafo
de construir sistemas complejos. Una reutilizacin efectiva requiere:
Esta categora en tigris.org alberga proyectos de cdigo abierto que estn produciendo
componentes de software reutilizables.
Dentro de esta categora se pueden mencionar las siguientes herramientas:
Herramienta
gef
axion
style
SSTree
Uso
Framework para edicin grfica en Java
Base de datos JAVA
CSS para aplicaciones web
Arbol Super Simple Java Script
Disponible en:
http://gef.tigris.org/
http://axion.tigris.org/
http://style.tigris.org/
http://sstree.tigris.org/
153
Ingeniera de Software
RECURSOS BIBLIOTECA VIRTUAL UNAD
154
Ingeniera de Software
Una vez en la pgina de Biblioteca, se encontrar toda la informacin de buscadores,
accesos, ayudas y apoyo para consulta de texto, libros y dems material bibliogrfico
disponible.
Recurso: elibro
Ttulo:
Planificacin y gestin de proyectos informticos
Autor:
Gutirrez de Mesa, Jos Antonio
Autor Adic./
Pags Arvalo, Carmen
Editor:
Ao:
2008
Informtica. -- unescot
Gestin. -- unescot
Materia:
Management information systems. -- lcsh
Libros electronicos. -- local
ISBN:
9788481387940
Impresor: Servicio de Publicaciones. Universidad de Alcal : , , Espaa
Idioma: es
http://site.ebrary.com/lib/unadsp/docDetail.action?adv.x=1& amp;d=all& amp;f00=all&
Ver Texto amp;f01=& amp;f02=& amp;hitsPerPage=500&
Completo: amp;p00=Ingenier%C3%ADa+del+software& amp;p01=& amp;p02=& amp;page=1&
amp;id=10280334
155
Ingeniera de Software
Recurso:
Ttulo:
Autor:
Autor Adic./
Editor:
Ao:
ebrary
Metrics for Software Conceptual Models
Genero, Marcela
Piattini, Mario
Calero, Coral
2005
Computer software -- Mathematical models.
Materia:
Computers.
ISBN:
9781860946066
Impresor: Imperial College Press : London, , GBR
Idioma: en
http://site.ebrary.com/lib/unad/docDetail.action?adv.x=1& amp;d=all& amp;f00=all&
Ver Texto amp;f01=& amp;f02=& amp;hitsPerPage=500&
Completo: amp;p00=Ingenier%C3%ADa+del+software& amp;p01=& amp;p02=& amp;page=1&
amp;id=10091225
Recurso:
Ttulo:
Cita:
Ao:
Materia:
ISBN:
Fecha Publicacin:
Tipo:
Recurso:
Ttulo:
Cita:
Ao:
Materia:
ISBN:
Fecha Publicacin:
Tipo:
156
Ingeniera de Software
BIBLIOGRAFIA
IMPRESA
BRAUDE. Ingeniera de software, una perspectiva orientada a objetos. Mxico. 2003.
Alfaomega grupo editor. S.A.
GRUEGGE, BERND y DUTOIT, Allen H. Ingeniera de software orientado a objetos.
Mxico. 2002. Pearson Educacin.
HUMPHREY, Watts S. Introduccin al proceso de software personal. Pearson Addison
wesley. 2001.
MEYER, Bertrand. Construccin de software orientado a objetos. Segunda edicin.
Madrid. 1999. Prentice Hall.
NORRIS. Ingeniera de software explicada. Grupo Noriega editores de Colombia.
PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos,
tcnicas y mtodos para la gestin del cambio. Editorial Alfaomega-Rama.
PRESSMAN, Roger S. Ingeniera del Software. Un enfoque prctico. Quinta edicin.
Espaa. 2002. Editorial McGraw Hill.
PFLEEGER, Shari Lawrence. Ingeniera de software, teora y prctica. 1. Edicin.
Buenos Aires. Pearson educacin. 2002
SOMMERVILLE, Ian. Ingeniera de software. 6. Edicin. Pearson Addison Wesley.
2001
ELECTRNICA
http://asqc.org
http://www.gestiopolis.com/recursos/documentos/fulldocs/eco/diagramapareto.htm
http://campus.fortunecity.com/defiant/114/iso9000.htm
http://www.iso.org
http://www.well.com/user/vision/sqa.html
http://www.processimprovement.com/resources/sqa.htm
http://www.softwaretestinginstitute.com/Profession.html
157