Professional Documents
Culture Documents
MODULO
Ingeniera del
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
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
software
Tcnicas
de
59
61
Pg.
64
70
80
89
89
90
91
94
96
97
101
109
109
111
114
115
116
119
119
124
126
132
139
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
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.
Primeros Aos
1950
1Primeros
1960
Tercera Era
1970
Aos
1980
Cuarta Era
1990
2003
Segunda era
Aparece la multiprogramacin y los sistemas
multiusuario
Tercera era
Cuarta era
El
software
Software empotrado
Software para PC
Software de
inteligencia artificial
10
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
CONSULTAS WEB
12
el conjunto
de
Principios
Mtodos
Tcnicas
para
Mantener
Desarrollar
Software
de
Calidad
13
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
15
16
Herramientas
Mtodos
Proceso
Enfoque de calidad
Enfoque de calidad
Proceso
Mtodos
Herramientas
17
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
18
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
del Sistema
Anlisis
Diseo
Codificacin
Prueba
Utilizacin
Mantenimiento
20
Anlisis
Diseo
Codificacin
Prueba
Identificar los
requerimientos
conocidos
Desarrollar
modelo que
funcione
Utilizar el
prototipo
Revisar el
prototipo
No
Prototipo
Terminado?
22
Abandonar la aplicacin
Implantar la aplicacin
Volver a desarrollar la
aplicacin
Comenzar un nuevo
prototipo
Primera
Iteracin
Debe
describir
24
DRA
es un
modelo de proceso
del
Enfatiza
un
Ciclo de
desarrollo
corto
25
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
Los
modelos
evolutivos
son
iterativos
se
caracterizan
po
r
desarrollar
versiones
27
cada vez
ms completas
del software
El modelo incremental
combina
el
y la
Construccin de prototipos
para
Entregar el software
en
Partes pequeas
llamadas
Incrementos
28
Ingeniera de
Sistemas / Informacin
Anlisis
incremento 2
incremento 1
Diseo
Cdigo
Anlisis
incremento 3
Diseo
Cdigo
Anlisis
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
probar,
instalar
30
El paradigma
T4G
incluye
las etapas
32
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
ELECTRNICA
http://www.pressman5.com
http://www.wiley.com/college/braude
http://www.minerva.uevora.pt/simposio/comunicacoes/rigomezmarino.html
http://apuntes.rincondelvago.com/trabajos_global/informatica/9/
http://www.info-ab.uclm.es/asignaturas/42551/enlaces.htm
http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/PDF/SEGlossary.pdf
http://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.php
http://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppt
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html
http://www.monografias.com/trabajos5/inso/inso.shtml
http://www.sistemas.unam.mx/software.html
http://www.ii.uam.es/~jlara/docencia/is1.2003/recursos.html
33
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
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
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.
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
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 Se establecen mecanismos de comunicacin para coordinar al equipo
y
de trabajo. Se deben tener:
Comunicacin
Comunicacin formal: se lleva a cabo por escrito, con
reuniones organizadas y otros canales de comunicacin.
Incluye documentos de ingeniera de software, memorandos
tcnicos, documentacin, informes de seguimiento.
Comunicacin informal: es ms personal. Incluye
reuniones de grupo para la divulgacin de informacin y para
la resolucin de problemas.
Comunicacin electrnica: se leva a cabo por correos
electrnicos, boletines, audioconferencias, videoconferencias.
37
mbito
Se define:
38
Descomposicin
del proceso
Comprender el problema a
solucionar y establecer los
objetivos.
Mantener el
desarrollo y
incentivos.
40
equipo de
proporcionar
41
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
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
De acuerdo a la figura:
Producto
Caractersticas
del cliente
Condiciones
del negocio
Proceso
Personas
Entorno de
desarrollo
Tecnologa
Defectos detectados
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
costo alto para la organizacin
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.
46
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%
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:
Origen de errores / defectos
Especificacin / requisitos
Diseo
Causa
Lgica
Manejo de datos
estndares
Especificaciones
47
%
20
10.9
6.9
25.5
Interfaz software
Interfaz hardware
Comprobacin de errores
Interfaz de usuario
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
Ambiguo
Las mtricas del proyecto de software sugieren que los proyectos deben medir:
48
LDC
Esfuerzo
Costo $
IRIS
18.200
24
200.000
Pginas de
documentacin
945
49
Errores
Defectos
Personas
134
86
permiten
La medida de la
funcionalidad de
la aplicacin.
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
de
medicin
Nmero de entradas
de usuario
Nmero de salidas de
usuario
Nmero de peticiones
de usuario
Nmero de archivos
Nmero de interfaces
externas
Cuenta
X
X
X
X
X
Factor de ponderacin
Simple Medio Complejo
3
4
6
4
7
5
10
7
15
10
=
=
=
=
=
Cuenta_total
50
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
Cuenta_total
fi
Punto de funcin
Es la suma de todas las entradas obtenidas
Donde i=1 hasta 14. Son valores de ajuste de la
complejidad basados en las respuestas a las cuestiones
sealadas de la siguiente tabla:
51
1
Incidental
2
Moderado
3
Medio
4
Significativo
5
Esencial
Fi :
1
2
3
4
5
6
7
8
9
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
53
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
55
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
de
de
de
de
de
entrada de usuario
salida de usuario
peticiones de usuario
archivos
interfaces externos
32
60
24
8
2
57
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.
El objetivo primordial es hacer estimaciones razonables de recursos, costos y una
planificacin temporal.
Las estimaciones involucran un periodo de tiempo y deben ser actualizadas a medida
que avanza el proyecto.
Planificacin
involucra
mbito del
software
Recursos
Estimacin del
proyecto
58
Tcnicas de
descomposicin
Modelos de
estimacin
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 sin 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?
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
Recursos de entorno
El entorno es donde se apoya el proyecto de software.
Comprende
Hardware y Software
61
62
63
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
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
65
E
D
KLOC
2.4
3.0
3.6
E = 2.4 * KLOC1.05
= 2.4 * 7.41.05
= 20 hombre-mes
66
es el esfuerzo en hombre-mes
es el nmero estimado de miles de lneas de cdigo
3.2
3.0
2.8
1.05
1.12
1.20
Y
EAF
67
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.
68
Es de la forma:
E = (LOC * B0.333 / P)3 * (1 / t4)
Donde,
E
t
B
P
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
Identificarlo
Evaluar su probabilidad de aparicin,
Estimar su impacto, y ,
Establecer un plan de contingencia por si ocurre el problema.
70
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
72
Con el impacto en
organizacin
desarrollar.
Tamao estimado del proyecto (LOC/PF)
Confianza en la estimacin
Numero de programas, archivos y transacciones
Tamao relativo al resto de proyectos
Tamao de la base de datos
Nmero de usuarios
Nmero de cambios de requerimientos previstos antes y
despus de la entrega
Cantidad de software reutilizado
la Asociados con las limitaciones impuestas por la gestin.
Efecto del producto en la cifra de ventas
Visibilidad desde la direccin de la organizacin
Fecha lmite de entrega razonable
Nmero de clientes que usarn el producto
Numero de productos con los que deber interaccionar
Sofisticacin del usuario final
Cantidad y calidad de la documentacin a entregar al cliente
Lmites legales y gubernamentales
Costos asociados al retraso en la entrega
Costos asociados a errores en el producto
73
experto informtico
74
del software
Hay herramientas de gestin de proyectos
Hay herramientas de gestin del proceso de desarrollo
Hay herramientas de anlisis y diseo
Hay generadores de cdigo apropiados para la aplicacin
Hay herramientas de prueba apropiadas
Hay herramientas de gestin de configuracin apropiadas
Se hace uso de una base de datos o repositorio centralizado
Estn todas las herramientas de desarrollo integradas
Se ha proporcionado formacin a todos los miembros del
equipo de desarrollo
Hay expertos a los cuales solicitar ayuda acerca de las
herramientas
Hay ayuda en lnea y documentacin disponible
Asociados con la tecnologa a utilizar y la complejidad del sistema
Con la tecnologa
Se trata de una tecnologa nueva en la organizacin
Se requieren nuevos algoritmos o tecnologa de I/O
Se debe interactuar con hardware nuevo
Se debe interactuar con software que no ha sido probado
Se debe interactuar con un B.D. cuya funcionalidad y
rendimiento no ha sido probada
Es requerido un interface de usuario especializado
Se necesitan componentes de programa radicalmente
diferentes a los hasta ahora desarrollados
Se deben utilizar mtodos nuevos de anlisis, diseo o pruebas
Se deben utilizar mtodos de desarrollo no habituales, tales
como mtodos formales, Inteligencia Artificial o redes
neuronales
Se aplican requisitos de rendimiento especialmente estrictos
Existen dudas de que el proyecto sea realizable
Con
la
experiencia Asociados a la experiencia de los ingenieros de desarrollo de
software.
tcnica
Es el mejor personal disponible
Tienen los miembros las tcnicas apropiadas
Hay suficiente gente disponible
Est el personal comprometido en toda la duracin del
proyecto
Habr parte del personal dedicado solamente en parte al
proyecto
Tiene el personal las expectativas correctas del trabajo
Tiene el personal la necesaria formacin
Puede la rotacin del personal perjudicar el proceso de
desarrollo
75
Riesgos
Mayor nmero de usuarios previstos
Categora
TP
Probabilidad Impacto
30%
3
76
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.
Evaluacin del impacto del riesgo
La exposicin al riesgo est dada por la ecuacin:
ER = P x C
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.
Evaluacin del riesgo
Se establece un punto en el que se decide cundo desistir y finalizar el proyecto. Para
esto se debe:
Definir un punto de referencia
Marcar la relacin entre cada factor de riesgo enumerado y el punto de referencia
Definir el rea de incertidumbre, donde ser tan vlido continuar como interrumpir el
trabajo
77
78
de
la
lnea
de
corte
79
Validacin de
esfuerzo
Definir
responsabilidades
Definir resultados
Hitos
Asignacin de tiempo
80
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
81
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.
82
83
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 de una actividad Ht:
Margen suplementario de tiempo de esa actividad sin que se altere el MIC de ninguna actividad crtica.
Holgura libre de unaHi:
Margen suplementario de tiempo para esa actividad sin que se altere el MIC de cualquier actividad.
Holgura independiente Hi:
Margen suplementario de tiempo que existe en una actividad si las actividades precedentes terminaran lo ms
tarde posible, y las actividades posteriores empezaran lo antes posible.
84
85
Oct 2005
ID
Actividades
Inicio
Fin
Duracion
Nov 2005
Dec 2005
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
86
87
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.cis.ohio-state.edu/hypertext/faq/usenet/proj-planfaq/faq.html
http://www.rspa.com
http://www.pmi.org
http://www.4pm.com
http://www.projectmanagement.com
www.minas.unalmed.edu.co/facultad/publicaciones/dyna/143/ALINEACI%D3N%20ENTRE%20METAS.pdf
http://www.calidad.org/s/causa.pdf
http://www.salud.gob.mx/unidades/dgces/gestion/page/05.html
http://www.minas.unalmed.edu.co/facultad/publicaciones/dyna/143/ALINEACI%D3N%20ENTRE%20METAS.pdf
www.ifpug.org
sunset.usc.edu/COCOMOII/cocomo.html
www.qsm.com
www.spr.com
88
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.
89
http://www.pcm.gob.pe/portal_ongei/publicaciones/cultura/Lib5042/cap20.htm
90
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
91
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
92
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
93
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
94
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):
95
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.
96
Deteccin
97
Porcentaje de eficiencia de la
deteccin de errores
Errores
pasados al
siguiente paso
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.
98
99
100
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.
101
Error
Frecuencia (No.)
205
156
48
25
130
58
45
95
36
60
28
56
942
Total
El siguiente paso es utilizar la frecuencia porcentual es decir, el porcentaje de errores en cada tipo de
defecto:
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
Frec. %
48
25
5%
3%
130
58
45
95
36
60
14%
6%
5%
10%
4%
6%
28
3%
56
942
6%
100%
22%
17%
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:
102
Frecuencia
(No.)
205
Frec. %
156
17%
130
14%
95
58
10%
6%
60
6%
48
45
5%
5%
de
36
25
4%
3%
28
3%
56
6%
942
100%
Total
22%
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.
103
Disponibilidad
TMDF
(100%)
TMDF+TMDR
Estos datos pueden ser medidos o estimados mediante datos histricos o de desarrollo.
El estndar de calidad ISO 9001
La Organizacin Internacional para la Estandarizacin (ISO) es una federacin mundial
de cuerpos de normas nacionales de aproximadamente 140 pases. ISO es una
organizacin establecida en 1947, cuya misin es promover el desarrollo de la
estandarizacin y de las actividades relacionadas en el mundo, con la idea de que
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.
La serie ISO 9000 es un conjunto de normas orientadas a ordenar la gestin de la
empresa que han ganado reconocimiento y aceptacin internacional debido al mayor
poder que tienen los consumidores y a la alta competencia internacional acentuada por
los procesos integracionistas. Algunas de estas normas especifican requisitos para
sistemas de calidad (ISO 9001, 9002, 9003) y otras dan una gua para ayudar en la
interpretacin e implementacin del sistema de calidad (ISO 9000-2, ISO 9004-1)
104
3.
4.
5.
6.
7.
8.
105
106
Responsabilidad gerencial
Proceso de comercializacin
Proceso de diseo
107
108
Descubrir un error
Mostrar un error no descubierto hasta ese momento
Descubrir un error no detectado hasta ese momento
109
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
descomposicin rpidamente los problemas y llevar a cabo pruebas de regresin
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
110
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 pruebas
comprensin
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
111
Caja
Negra
De entornos
especializados
Salida
Entrada
112
Nodos
2,3
6
7
R3
R2
4,5
Region
R1
9
10
11
Entonces,
2,3
6
7
4,5
113
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.
114
Bucles no estructurados
Estos bucles se deben redisear.
Entrada
Salida
Funciones
funciones
115
Entrada de datos:
o
o
o
o
116
117
Prueba
Prueba
Prueba
Prueba
de
de
de
de
118
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
119
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?
3.1.2 Organizacin para las pruebas del software
Toda prueba de software debe tener la coordinacin de actividades:
El responsable del desarrollo del software es el responsable de probar las unidades
del programa y a veces se encarga tambin de la prueba de integracin.
Cuando se tiene una arquitectura completa de software, los encargados de la prueba
es un Grupo Independiente de Prueba (GIP), permitiendo que se tenga
independencia.
Grupo Independiente de prueba
Este grupo tiene como objetivo identificar y encontrar errores. Este grupo trabaja
conjuntamente con el responsable del desarrollo de software para asegurar que se
realizan pruebas exhaustivas. Mientras se realiza la prueba, el desarrollador debe estar
disponible para corregir los errores que se van descubriendo.
120
Pruebas de validacin
Diseo y construccin de la
arquitectura software
Pruebas de integracin
Prueba de unidad
Estrategia de prueba
Si se considera el proceso desde el punto de vista procedimental, la prueba, en el
contexto de la ingeniera del software, realmente es una serie de cuatro pasos que se
llevan a cabo secuencialmente.
121
Requisitos
Pruebas
de alto nivel
Prueba de
integracin
Diseo
Codificacin
Prueba
De
unidad
Direccin de la prueba
122
123
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)
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.
125
M2
M5
M3
M6
M4
M7
M8
Integracin descendente
127
Mb
D2
D3
Grupo 3
Grupo 1
Grupo 2
Integracin ascendente
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 Mb. 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.
128
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
129
130
Casos
de
prueba
Ejecucin de casos
Resultados
Pruebas
adicionales
Causas
sospechadas
Pruebas de
Regresin
Depuracin
Correcciones
Causas
identificadas
El proceso de depuracin
131
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.
2
.
3
.
132
133
Portabilidad
Reusabilidad
Interoperatividad
Correccin
Fiabilidad
Usabilidad
Integridad
Eficiencia
134
Facilidad de auditoria
Estandarizacin de comunicaciones
X
X
Complejidad
Concisin
Consistencia
X
X
X
X
X
Estandarizacin de datos
Tolerancia a errores
X
X
Eficiencia de ejecucin
X
X
Capacidad de expansin
Generalidad
Independencia del hardware
Instrumentacin
Modularidad
Usabilidad
Exactitud
Complexin
Interoperatividad
Reusabilidad
Portabilidad
Flexibilidad
Mantenimiento
Integridad
Eficiencia
Fiabilidad
Factor de calidad
Correccin
Mtrica de la calidad
del software
Capacidad de pruebas
A continuacin, se presenta la relacin entre los factores de calidad del software y las
mtricas de la lista anterior.
X
X
Operatividad
135
X
X
X
X
X
X
X
X
X
X
Seguridad
Autodocumentacin
Simplicidad
Independencia del sistema
X
X
X
X
X
X
Trazabilidad
Facilidad de formacin
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
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
136
Eficacia
Extensibilidad
Adaptabilidad
Capacidad de pruebas
Capacidad de configuracin
Compatibilidad
Requisitos de instalacin
El modelo FURPS incluye, adems de los factores de calidad y los atributos, restricciones
de diseo y requerimientos de implementacin, fsicos y de interfaz. Las restricciones de
diseo especifican o restringen el diseo del sistema. Los requerimientos de
implementacin especifican o restringen la codificacin o construccin de un sistema
(por ejemplo, estndares requeridos, lenguajes, polticas). Por su parte, los
requerimientos de interfaz especifican el comportamiento de los elementos externos con
los que el sistema debe interactuar. Por ltimo, los requerimientos fsicos especifican
ciertas propiedades que el sistema debe poseer, en trminos de materiales, forma,
peso, tamao (por ejemplo, requisitos de hardware, configuracin de red).
Factores de calidad ISO 9126
El estndar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos
clave de calidad para un producto de software (Pressman, 2002). Este estndar es una
simplificacin del Modelo de McCall, e identifica seis caractersticas bsicas de calidad
que pueden estar presentes en cualquier producto de software. El estndar provee una
descomposicin de las caractersticas en subcaractersticas, que se muestran en la
siguiente tabla:
Caracterstica
Funcionalidad
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
137
Portabilidad
Modificabilidad
Estabilidad
Capacidad de pruebas
Adaptabilidad
Instalabilidad
Reemplazabilidad
138
139
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.
140
Fenton sugiere varias mtricas de morfologa simples que permiten comparar diferentes
arquitecturas mediante un conjunto de dimensiones directas.
141
142
(Ec. 1)
(Ec. 2)
(Ec. 3)
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 a lo largo de todos los mdulos del sistema.
143
145
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://comp.software-eng
http://asqc.org
http://www.qualitytree.com/links/links.htm
http://www.gestiopolis.com/recursos/documentos/fulldocs/eco/diagramapareto.htm
http://campus.fortunecity.com/defiant/114/iso9000.htm
http://www.iso.org
http://www.iso.org/iso/en/iso9000-14000
http://www.well.com/user/vision/sqa.html
http://www.processimprovement.com/resources/sqa.htm
http://www.softwaretestinginstitute.com/Profession.html
146