REVISIONES ESTRUCTURADAS (WALKTROUG)

Anuncio
REVISIONES ESTRUCTURADAS (WALKTROUG)
Es un nombre dado a una serie de revisiones, cada una de ellas con diferentes objetivos, hechas durante las
distintas fases del desarrollo de un programa.
Pueden llevarse a cabo durante la siguientes fases :
− Después del desarrollo de las especificaciones.
− Después del diseño del programa.
− Después de que el test de prueba y sus datos estén
preparados.
Clases de
− Especificaciones
− Diseño
− Test de prueba y test de datos
− Instrucciones para usuario
Desarrollo_de_una_Revisión_estructurada
1º Inicio. Cuando el programador está preparado.
2º Invitación: de 2 a 6 compañeros, se trabaja en grupo
no individualmente.
3º Guía: 48 horas antes se entrega a los participantes
una guía con los datos necesarios.
___________________________________________
|
Cabecera | Fecha Autor programa.Fecha de reunión,lu−
Información | gar, nombre−programa,tipo Walktroug(Dise−
| ño).
|
Materiales | Especificaciones,VTOC,Entradas/Salidas
1
Adjuntos | IPOS
|
Objetivos | Completen PSS de logic,nombres significa−
| tivos y consistentes
|
Participan− |
tes |
|________________________________________
4º Copias: Entregar todo el material a revisar
5º No personal directivo. Intentamos encontrar errores
no evaluar
6º Reunión: Lista de errores encontrados
No búsqueda solución
Solución posterior por el autor
Lista de acciones
7º Reunión
− Se selecciona un componente como moderador y a otro
(o el mismo) como secretario.
− Se persigue detectar, no corregir errores. El autor
puede dar una pequeña introducción de su trabajo.
− Cuando se encuentre un punto conflictivo el programa−
dor debe explicarlo y comprobar si es un error.
− No se discutirán los errores triviales.
− Todos los miembros habrán buscado antes de la reunión
los puntos conflictivos
Después
2
− El programador responde a los problemas, proporcionando
las soluciones a los problemas.
− Si hay un error mayor habrá que rehacer el material y
convocará una nueva reunión.
− Cada vez que se haga un Walktroug, se enviará una
notificación al personal directivo a cargo del
proyecto.
Puntos a tener en consideración para que el Walktroug sea e−
fectivo
1º Personal directivo no presente
2º Sólo detección de errores
3º Dos horas de tiempo limite
4º Participantes adecuados (reales y potenciales)
5º Máximo interés en la participación (conocimiento del
sistema)
6º Dar a conocer los resultados (aprendizaje)
7º No usar para evaluar programador.
Lista_de_acciones
¿Es el nombre del módulo 120 Cambio de 'Proceso regis−
significativo? tro ventas' a 'Producir
línea Salida'
Inconsistencia en el uso de Cambiar todo a TRAN
TR y TRAN
Las_revisiones_periódicas_son_necesarias_para:
− Punto actual VS plan establecido.
− Control áreas especificas.
3
− Se posponen por rechazo a la revisión (efecto
psicológico)
− No diseñados para sustituir las revisiones necesarias
para un proyecto
− Diseñadas para:
− Complementar: pasar controles de calidad periodi−
camente
− Herramienta de trabajo para:
Analista −−−−> Jefe de programación: debe
conocer al personal al que se adjudican los trabajos
Programadores −−−−> aprenden
Personal directivo: supone que el proyecto va
bien.
Primer_impacto_de_la_revisión
− No son bien acogidas
− Pérdida de tiempo. Explicar el trabajo a gente
inexperta.
− Sirve de evaluación: se cree que ponen nota
Una_revisión_estructurada_para_las_organizaciones
1.− Motivación positiva para el equipo que realiza el
proyecto
− Todos saben
− Proyecto de todos VS actitud egoísta. Todos los
módulos deben funcionar bien,no importa quien
lo haya hecho, tiene que funcionar todo bien.
− Capitalización (individual y organización).Mis
4
conocimientos están al servicio de la organiza−
ción
2º.− Aprendizaje y excelente manera de ganar experiencia
3º.− Herramienta para analizar el diseño funcional del
sistema
4º.− Medio de descubrir errores lógicos en el diseño. In−
cluso de omisión.
5º.− Manera de eliminar errores de codificación antes de
que entren en el sistema.
6º.− estructura para implementar una estrategia de che−
queo
PROYECTO INFORMATICO
Informática no sólo es hacer programas. Actividades que
reunen unas características especiales como:
− Volumen considerable
− Transcendencia. Importancia
− Riesgo acentuado para la organización.Coste
económico.
− Falta de habitualidad
− Necesidad de integrar diferentes especificacio
nes. En función de la fase que se encuentre
determinaremos los recursos humanos.
Frente a:
" Tareas( actividades) rutinarias"
Que suelen afectar al trabajo del día a día, pues
tienen un carácter más urgente.
5
− Se impone frente a proyectos (+ Importantes −
urgentes)
− Consumen tiempo y recursos (70%). Personas paradas
en mantener los programas.
− Por ellas los proyectos se retrasan y aumentan los
costes:
− Calendario
− costes
− Efectos psicológicos: son más cómodas y reposadas
Mayor riesgo y dureza
Activo_del_CPD
− Horas humanas.Recursos, las horas que se pierden
no se recuperan
− Recursos técnicos. Ordenadores y metodologías,etc.
− Software desarrollado.
Se deduce:
Programación: último eslabón de la cadena
Que hay antes
− Análisis de requerimientos
− Diseño del Software
− Programación
Después:
− Pruebas
− Estrategias
Un_sistema_informatico.Concepto de Sistemas
− Se usa en muchas disciplinas/áreas
6
− Hay muchas definiciones
− Todas tienen cualidades comunes
− Elementos
− Entornos
− Iteración entre sus elementos y el entorno
− Tiene objetivos que alcanzar.
Una definición de sistemas:
Un conjunto organizado de
− Personas
− Maquinas
− Procedimientos
− Documentos
− Datos
− Otras cosas (entes)
Interactivados unos con otros, así como con el en−
torno para alcanzar unos objetivos predefinidos
Definición de subsistema:
Parte de un sistema mayor, que se denomina suprasistema.
Cosas fundamentales dentro del sistema
Datos (100)
Información (100º)
Conocimientos (el agua hierve a 100º)
Mensaje:
Un grupo de caracteres que son almacenados, procesados
y transmitidos en un sistema de información de una organiza−
ción
7
Así pues los mensajes en una organización tienen diferente significado según lleven : datos, información o
conocimiento.
Un sistema de información: debe proporcionar información,
dónde y cuando y a que nivel debe dar información
Un sistema de Información debe estar en consonancia con los objetivos de la organización
S.I.: conjunto interrelacionado lógicamente de procesos de Negocios para alcanzar los objetivos de la
organización
Requerimientos y características de la Información en un SI
Requerimientos
1.− Entendida por el receptor en el marco de referen−
cia adecuados
2.− Relevante para las necesidades( Proceso toma
decisiones)
3.− Nueva
4.− Conduce a toma de decisiones (no ación)
Atributos
− Correcta entrada
− Seguridad de integridad
− Flexibilidad
− Dar satisfacción al usuario
La Información debe estar asociada a tres niveles, que dan
lugar a tres tipos básicos de operaciones:
− Proceso de transacciones
− Control
− Planificación estratégica
Considerada esta relación el S.I. se puede subdividir en 2
subsistemas
8
/|\
Ejecutivo Planificación |
________________________________ |
|
Control |
______________________ Control Nivel actividades
|
Superior |
Control operacional |
____________________________________ _________\|/_________
||
Operaciones |Transacciones| Niveles operativos
Personales |____________|
− MIS: Subsitema relativo al manejo (gestión) de decisiones
para propósitos de control y planificación estratégica
− OIS: Subsistema referido al proceso de las transacciones,se
conoce como CPD.
El MIS se divide en
MIS
DSS
Tema: 1 −− INGENIERIA DEL SOFTWARE
Características de lo que ha motivado la aparición de la
INGENIERIA DEL SOFTWARE, razones
− Los ordenadores datan de los años 50, se veían como
algo grande y extraño, se compraban por prestigio, y
se ejecutaban procesos muy específicos: clasificacio−
9
nes, listados, es decir funciones muy concretas y se
hacía el programa para ese problema
− El Hardware ha ido bajando de precio, lo que aumentó
la demanda de informáticos
− El coste de hoy en día es de 80% Software y 20% de Har−
dware, en un sistema
− Nos encontramos rigidez frente a la informalidad
− Los programas para sistemas: debido a la rigidez de es−
tos, se tarda a veces en confeccionar el programa más
que para un PC aislado
− Cuanto mas complejo es el sistema, más difícil su com−
prensión intelectual
− Los sistemas son dinámicos y evolucionan en el tiempo
− Los grandes sistemas necesitan técnicas mas formales
de especificación y diseño
Un programa sigue las siguientes fases:
− Especificar
− Diseñar
− Instrumental (No siempre necesaria, pues se puede pro−
bar sin instrumentalización)
− Pruebas
Especificación: El análisis de las necesidades del cliente.
Las especificaciones es un contrato entre el usuario y
el técnico, un documento único.
Cuando se especifica ya se empieza a trabajar en las
pruebas del sistema, sin que el sistema esté construido.
10
La construcción de grandes sistemas ,por no utilizar metodo−
logía adecuada nos lleva:
− Grandes retrasos ( Curva−aprendizaje)
− Altos Costes: no quiere decir que haya que haber
grandes−retrasos, o que grandes retrasos den grandes
costes
− Escasa fiabilidad
− Escaso rendimiento
− Gastos de mantenimiento: valen más que el sistema,
por el dinamismo y evolución del sistema
Por tanto:
Nuevas técnicas
Nuevas Metodologías
IS (BOTTEM): incluye la aplicación práctica del conocimiento
científico en el diseño y construcción de programas para
computadoras y la documentación asociada requerida para desa−
rrolarlos, operarlos y mantenerlos.
El diseño debe incluir A.R. y rediseño durante modifica−
ción
IS (IEE83 Standard Glossary of Sotfware engineering):
Como el enfoque sistemático para el desarrollo, opera−
ción, mantenimiento y eliminación del software.
Definiendo Software como :
Aquellos programas, procedimientos, reglas y documen−
tación posible asociada con la computación, así como los da−
tos pertenecientes a la operación de un sistema de computa−
11
ción
Las metas son
− Aumento calidad productos
− Aumento productividad
− Satisfacción profesional
Que abarca el término Software
− Programas
− Documentación
− Instalar |
|
− Usar | Para un amplio espectro
>
− Desarrollar | (usuarios)
|
− Mantener |
(Componentes ejecutables y no ejecutable)
Grandes sistemas
− Programas y documentación reparten esfuerzos
Cualidades del Ingeniero del Software
− Técnicas
− Técnicas de computación
− No técnicas
| Usuarios
− Comunicación <
| Técnicos
− Oral
12
− Escrita
− Administrativo (Control)
− Tiempo
− Costes
Así pues la diferencia entre la ingeniería del Software y la
programación tradicional consiste en la utilización de técni−
cas de ingeniería, para
− Especificar
− Diseñar
− Instrumentar
− Validar
− Mantener
En tiempo y coste para un proyecto, así como la inciden−
cia en aspectos administrativos.
Producto de programación incluye
− Código fuente
− Manuales asociados
− Documentación propia del producto
− Manual de requisitos
− Especificaciones de diseño
− Código fuente
− Planes de prueba
Aproximación_al_ciclo_de_vida_del_software
Los grandes sistemas tienen un denominador común:
− Necesitan mucho tiempo para su desarrollo
− Funcionaran mucho más tiempo
13
Hay muchos modelos. Un marco sería
− Análisis y definición de necesidades
− Objetivos, rendimientos y restricciones del usuario
− Diseño del sistema y del Software
− Necesidades de Wardware y software
− Representación de funciones
− Aplicación y pruebas de Unidades
− D.S. como conjunto de programas
− Pruebas de los programas
− Pruebas del sistema
− Integración y pruebas del sistema, asegura cubrir
necesidades
− Operación y mantenimiento
− Pueden ser las mas largas
− Corregir, mejorar,aumentar
Convine diferenciar
Ciclo desarrollo Sotfware
Ciclo vida Software
Verificación : se esta construyendo correctamente
Validación : se esta construyendo el producto correcto
Hablemos_de_costes
|
| _________________________________
COSTE |
|
|___________________________________
14
Sistemas comerciales * BOEHM (75) (81)
RESTO
Necesidades/diseño ..... 44% 44% 46%
Aplicación ............. 28% 26% 20%
Pruebas ................ 28% 30% 34%
CIENTÍFICO DE
CONTROL
SOFTWARE
* Sin operación y mantenimiento (éste supera el coste
al desarrollo)
Mantenimiento puede ser
− Aumentativo
− Adaptativo
Para reducir mantenimiento y como consecuencia reducir el cos−
te del ciclo de vida es necesario una mejor (óptima) defini−
ción de necesidades
Porque hay que mantener el software
− Porque los sistemas son dinámicos:
− Por entorno y la comprensión del medio, los cuales
son dinámicos en el tiempo
Las reglas de la evolución del sistema
− Cambio continuo: o se cambia el sistema o cada vez es
mas antiguo
− Complejidad creciente : la evolución del software im−
plica estructuras mas complejas, si no se aplican téc
nicas nuevas, estamos a base de parches
15
EVOLUCION DEL SOFTWARE
Grandes sistemas son dinámicos
− Entorno |
> Evolutivos
− Comprensión del medio |
La evolución del sistema esta sujeta a leyes determinadas por
observación experimental (LEHMAN 76)
1.− Cambio continuo: cambio útil
2.− Complejidad creciente
− Evolución Software implica estructuras más com−
plejas o se evita.
3.− Evolución del programa
− Proceso autorregulador
− Medición de atributos del sistema
− Tamaño
− Tiempo entre versiones
− Nº de errores
4.− Conservación de la estabilidad organizativa
− Desarrollo casi constante e independiente
La evolución del software esta ligada a la del Hardware
Un mejor rendimiento del Hardware, un tamaño mas pequeño y un
coste mas bajo, han dado lugar a sistemas informáticos mas so−
fisticados.
La evolución del Hardware se ha denominado como "la nueva re−
volución industrial" que dará paso a " La sociedad de la in−
formación
16
4 etapas en la evolución del Software
primeros años La segunda era La tercera era La cuarta era
*Orientación *Multi−usuario *Sistemas dis− *Sistemas ex−
por lotes *Tiempo−real tribuidos pertos
*Distribución *Bases de datos *Inteligencia *Máquinas de
limitada *Producción de edmpotrada Int. Artif.
*Software a Software *Hardware de *Arquitecturas
medida bajo coste paralelas
*Impacto en el
consumidor
_____________________________________________________________
1.950 1.960 1.970 1.980 1.990 2.000
1ª Etapa
− EL Hardware sufrió continuos cambio, mientras que el sof−
tware se veía simplemente como un añadido
− La programación de computadoras era un arte de andar por
casa: No existen métodos,herramientas, técnicas, planifi−
ción, control.
− El software se realizaba prácticamente sin ninguna plani−
ficación, aunque empiezan a aparecer algunos deslices en
los costes o planificación.
− Se utiliza en la mayoría de los sistemas una orientación
por lotes
− La mayor parte del Hardware se dedicaba a la ejecución de
un único programa que a su vez se dedicaba a una aplica−
ción específica.
17
− El software se diseñaba a medida para cada aplicación y
tenía una distribución relativamente pequeña
− La mayoría del software se desarrollaba y utilizaba por
la misma persona u organización.
− Debido a esto la misma persona lo escribía, lo ejecutaba
y si fallaba lo depuraba
− Debido a que la movilidad en el trabajo era baja, los eje
cutivos estaban seguros de que esa persona estaría allí
cuando se encontrara algún error
− Debido e este entorno personalizado del software, el dise
ño era un proceso implícito, ejecutado en la cabeza de al
guien y la documentación no existía normalmente
2ª Etapa
− La multiprogramación, los sistemas multiusuarios, introdu
jeron nuevos conceptos de interacción hombre−máquina
− La técnicas interactivas abrieron un nuevo mundo de apli−
caciones y nuevos niveles de sofisticación del hardware y
software.
− Los avances en los dispositivos de almacenamiento en lí−
nea, condujeron a la primera generación de sistemas de
gestión de base de datos.
− Se caracterizó por el uso del software como producto y
llegada de las "casas de software"
− Conforme creció el número de sistemas informáticos, comen
zaron a extenderse las bibliotecas de Software de computa
doras
18
− Los productos software comprados al exterior añadieron
cientos de miles de nuevas sentencias
− Todas estas sentencias fuente, tenían que ser corregidas
cuando se detectaban fallos, se modificaban por cambios
en los requerimientos del usuario o se adaptaban a un
nuevo hardware que se había comprado.
− Estas actividades se llamaron colectivamente mantenimien−
to del software.
− El esfuerzo gastado en el mantenimiento del Software comen
zo a absorber recursos en una medida alarmante
− La naturaleza personalizada de muchos programas los hacía
virtualmente imposibles de mantener
− Había comenzado una crisis del software
3ª Etapa
− Comenzó a mediados de los 70 y continua hoy
− El sistema distribuido incrementó notablemente la comple−
jidad de los sistemas informáticos
− La creciente demanda de acceso instantáneo a los datos,
supusieron una fuerte presión sobre los desarrolladores
de software
− Se caracterizó también por la llegada y amplio uso de los
microprocesadores y computadores personales
− El microprocesador, es una parte integral de un amplio
espectro de productos: automóviles, hornos microondas,ro−
bots industriales etc.
− Las computadoras personales han sido la catálisis para el
19
crecimiento de muchas compañías de software.
− Distribución de software en cientos de miles
− El Hardware se ha convertido en las computadoras persona−
les en un producto, mientras el software marca la dife−
rencia.
4ª Etapa
− Está ahora comenzando
− Técnicas de la cuarta generación para el desarrollo de
software
− Los sistemas expertos y el software de inteligencia arti−
ficial se han trasladado del laboratorio a aplicaciones
prácticas
− Conforme nos movemos en la cuarta era, continua intensi−
ficándose la crisis del Software.
− Ahora podemos describirla como
1: La sofisticación del hardware ha dejado atrás nues
tra capacidad de construir software que pueda ex−
plotar el potencial del hardware
2: Nuestra capacidad de construir nuevos programas no
puede descansar, debido a la demanda de nuevos pro
gramas.
3: Nuestra capacidad de mantener los programas exis−
tentes está amenazada por el mal diseño y el uso
de recursos inadecuados
− Como respuesta a la crisis del software aparece la Inge−
niería del software.
20
CARACTERISTICAS DEL SOFTWARE
Cuando se construye el hardware el proceso creativo humano se
traduce finalmente en una forma física
El Software es un elemento lógico en vez de físico del siste−
ma., luego tiene características considerablemente distintas
de las del hardware
− El software es desarrollado , no es fabricado en el
sentido clásico. Existen algunas similitudes entre
el desarrollo del software y la construcción del
hardwarrje, pero las dos actividades son fundamental
diferentes
En ambas, la buena calidad se adquiere median−
te un buen diseño, pero la fase de construcción del
hardware puede producir problemas de calidad que no
existen o son fácilmente corregibles en el Software
Ambas actividades, requieren la construcción
de un producto, pero los métodos son diferentes.
− Los costes del software se concentran en la ingenie−
ría. Esto significa que los proyectos no pueden ser
gestionados como si fueran proyectos de fabricación.
El concepto de fábrica de software recomienda el uso de herramientas automáticas para el desarrollo del
software
− El Software no se deteriora
Propor− /|\
|
ción de | Mortandaz
| infantil Deterioro
21
fallos |
|
|________________________________________\
tiempo /
La figura representa la proporción de fallos
como una función del tiempo , para el Hardware.
La relación se llama frecuentemente, la curva
de bañera, e indica que el hardware exhibe relati−
vamente muchos fallos al principio de su vida. Estos
fallos son atribuidos frecuentemente a defectos de
diseño o de fabricación.
Cuando se corrigen los defectos, caen los fallos
hasta su nivel más bajo, en donde permanecen estacio
narios durante un cierto periodo de tiempo
Sin embargo , conforme pasa el tiempo, los fa−
llos vuelven a presentarse conforme las componentes
hardware sufren los efectos de los males externos y
comienza a deteriorarse
El software no es susceptible de males del entor−
no como los que hacen que el hardware se deteriore,
por lo tanto, en teoría la curva de fallos del Soft−
ware tendrá la forma:
Propor− /|\
| Continua en la misma
cion de | proporción hasta que
| queda obsoleto.
22
fallos |
|
|________________________________________\
tiempo /
Los defectos no descubiertos harán que falle du−
rante las primeras etapas de la vida del programa
Una vez que estos se corrigen, suponiendo que no
introduzcan nuevos errores, la curva se aplanará.
Esta figura es una gran simplificación de los
modelos reales de fallos del Software. Sin embargo
el software no se rompe, pero se deteriora.
Esta contradicción puede comprenderse mejor con−
siderando la figura
Propor− /|\
|
ción de | curva real
|
fallos |
|
|
| curva ideal
|
|_________________________________________\
tiempo /
Durante su vida el software sufre cambios(mante−
nimiento). Conforme se hacen cambios, es probable
23
que se introduzcan nuevos defectos, haciendo que la
curva de fallos tenga picos
Antes de que la curva pueda volver al estado
estacionario original, se solicita otro cambio,
haciendo que de nuevo se cree otro pico.
Lentamente el nivel mínimo de fallos comienza a
a crecer, el software se va deteriorando debido a
los cambios.
− Cuando una componente hardware se deteriora, se sus−
tituye por una pieza de repuesto. No hay piezas de
repuesto para el software
Cada fallo en el software indica un error en el
diseño o en el proceso mediante el que se tradujo el
diseño en Código máquina ejecutable
Por tanto el mantenimiento del software supone una complejidad considerablemente mayor que el
mante−
nimiento del hardware.
− La mayor parte del Software se construye a medida,en
vez de ensamblar componentes existentes.
Ingeniería del software para
− Mejorar rendimiento
− Mejorar pruebas
− Satisfacción del cliente
COMPONENTES DEL SOFTWARE
El software de computadora es información que existe en dos
formas básicas
− Componentes no ejecutables en la máquina
24
− Componentes ejecutables en la máquina
Todas las componentes del software contienen una configura−
ción
El diseño del software se traduce a
− Un lenguaje que especifica la estructura de datos
del software
− Los atributos procedimentales
− Los requerimientos relacionados
Todos los lenguajes de programación son lenguajes artificia−
les
Las clases de lenguajes que son componentes del software se
caracterizan como
− Lenguajes a nivel máquina
− Lenguajes a alto nivel
− Lenguajes no procedimentales
APLICACIONES DEL SOFTWARE
El software puede aplicarse en cualquier situación en la que
se haya definido previamente un conjunto especifico de pasos
procedimentales (es decir un algoritmo).
Los factores importantes para determinar la naturaleza de una
aplicación software son:
− La determinación de la información
− El contenido de la información
El contenido se refiere al significado y la forma de la infor
mación de llegada y salida.
La determinación de la información se refiere a la necesidad
25
de predecir el orden y tiempo de llegada de los datos
Así hay aplicaciones determinadas e indeterminadas siendo es−
tas últimas aquellas que tienen como características:
− Acepta entradas que tienen un contenido variado y
se producen en un tiempo arbitrario
− Ejecuta algoritmos que pueden ser interrumpidos por
condiciones externas
− Produce una salida que depende de una función del
entorno y del tiempo
Una aplicación determinada
− Acepta datos que están en un orden predefinido
− Ejecuta un algoritmo sin interrupciones
− Produce datos resultantes en formato predefinido
Las siguientes áreas del software indican la amplitud de las
potenciales aplicaciones
1º Software de sistemas
− Es una colección de programas escritos para servir
a otros programas
− El área del software de sistemas se caracteriza
por:
− La fuerte interacción con el hardware de la
computadora
− Su gran utilización por múltiples usuarios
− La operación concurrente que requiere plani−
ficación
− Compartimentación de recursos
26
− Sofisticada gestión de procesos
− Estructura de datos complejas
− Múltiples interfaces externas
2º Software de tiempo real
− El Software que mide, analiza, controla sucesos
del mundo real conforme ocurren, se llama de
tiempo real
− Los elementos del software de tiempo real inclu−
yen:
− Una componente de acumulación de datos
que recolecta y formatea la información de
un entorno externo
− Una componente de análisis que transforma
la información según requiera la aplicación
− Una componente de control/salida que respon
da al entorno externo
− Una componente de monitorización que coor−
dina a todas las demás componentes de forma
que puedan mantener la respuesta en tiempo
real (tipicamente en el rango de 1 milise−
gundo a 1 minuto).
3º Software de gestión
− Referido al procesamiento de la información co−
mercial.
− Los sistemas discretos han evolucionado hacia el
software de sistemas de información de gestión,
27
que acceda a una o mas bases de datos grandes
que contienen la información comercial
− Características de las aplicaciones en esta área:
− Restructuran los datos existentes en orden
a facilitar las operaciones comerciales o
gestionar la toma de decisiones
− Realizan cálculo interactivo
4º Software de ingeniería y científico
− Se ha caracterizado por los algoritmos de manejo
de números
− Las nuevas aplicaciones del área de ingeniería/
científica se han alejado de los algoritmos
convencionales numéricos.
− El diseño asistido por computadora, la simulación
de sistemas y otras aplicaciones interactivas,
han comenzado a tomar caracteristicas del softwa−
re de tiempo real e incluso de sistemas
5º Software empotrado
− Se utiliza para controlar productos y sistemas
de los mercados industriales y de consumidores
− Características
− Reside en memoria de sólo lectura
− Puede ejecutar funciones muy limitadas y
esotéricas (eje. control de teclas de un
horno)
− Suministrar una función significativa
28
− Capacidad de control
6º Software de computadoras personales
− Es uno de los diseños del software más innovati−
vos en el campo del software.
− Entre sus múltiples aplicaciones esta
− Tratamiento de textos
− Hojas de calculo
− Gráficos
− Entretenimientos
− Gestión de base de datos
− Aplicaciones financieras,comerciales y per−
sonales
− Redes externas o acceso a base de datos
7º Software de inteligencia artificial
− Hace uso de algoritmos no numéricos para resolver
problemas complejos que no son adecuados para el
el cálculo o análisis directo
− Actualmente el área mas activa es la de los sis−
temas expertos, también llamados sistemas
basados en el conocimiento
− Otras áreas de aplicación
− Reconocimiento de patrones
− Prueba de teoremas
− Juegos
FACTORES DE TAMAÑO
Esfuerzo_dedicado_al_software
29
Dinero dedicado a computación (U.S.A.)
AÑO 80 5% PNB
AÑO 2,3% PNB
AÑO 90 12,2% PNB
Hardware Software
AÑO 60 80% 20%
AÑO 80 20% 80%
AÑO 90 10% 90%
|
|
| Desarrollo productos P.
|
|
|
| Mantenimiento Productos
| Programación
|___________________________________________________
1.955 1.978 1.985
Distribución del esfuerzo (Desarrollo−Mantenimiento)
Producto Software 1 a 3 años desarrollo 5−15 de vida
|
| _________
| | 36% |
|||
|_____ _______ | |
| 16% | | 16% |________| |_________
30
| |________| | 12% | | 12% |
| | 8% | | | | |
|_____|________|_____|________|_______|________|____
/|\ /|\
|_____Mantenimiento(60%)__|
Deducciones
1º.− Las actividades de mantenimiento gastan más
recursos que actualmente el desarrollo
2º.− Gran parte del esfuerzo gastado es la mejora
del producto
3º.− La actividad de prueba equivale al 50% fase de
desarrollo
4º.− Actividad de prueba ,mejora,adaptación equiva−
le al 75% ciclo de vida producto
Conclusión
Objetivo del análisis, diseño, intrumentación sera
aliviar las tareas de pruebas y mantenimiento
Clasificación_en_base_al_tamaño
El tamaño determina
− Nivel de control administrativo
− Tipo de herramientas
− Técnicas necesarias
Según YOUR DON 75
CATEGORIA Nº_PROGRAMADORES DURACION TAMAÑO PRODUCTO
TRIVIAL 1 1−4 S 500 L/C
10 − 20 Subpro.
31
− No requiere excesiva formalidad en análisis,
documentación, diseño, pruebas,aunque se me−
jora aplicando técnicas
PEQUEÑO 1 1−6 M 1K − 2K
25 − 50 Subpro.
− Normalmente no tiene iteración con otros pro−
gramas
− Poca interación entre programadores
− Poca interación entre programadores y cliente
CATEGORIA Nº_PROGRAMADORES DURACION TAMAÑO PRODUCTO
MEDIANOS 2 − 5 1− 2 A 5K − 50K
250−1000 Sub
− Son la mayoría de los proyectos
− Interacción entre los programadores
− Interacción entre los programadores y cliente
− Formalidad en
− Planificación
− Análisis y diseño
− Documentación
− Revisión del producto
CATEGORIA Nº_PROGRAMADORES DURACION TAMAÑO PRODUCTO
GRANDE 5 − 50 2 − 3 A 50K − 100K
− Comprenden varios subsistemas
− Mucha iteración con otros subsistemas
− Problemas de comunicación entre programadores
/gestores/clientes
32
− Pude ser necesario varios grupos de progra−
madores
− Posibilidad de alta rotación en personal
− Es esencial
− Procedimientos sistematizados
− Documentación estandard
− Revisiones formales
CATEGORIA Nº_PROGRAMADORES DURACION TAMAÑO PRODUCTO
MUY GRANDES 100 − 1.000 4− 5 A 1 M
− Varios susbsistemas y cada uno implica un pro−
yecto grande
− Subsistemas interrelacionados complejamente
entre ellos y con otros subsistemas
− Formalidad estructura
EXTREMADAMENTE 2.000−5.000 5−10 A 1M − 10M
GRANDES
− Implican igual que los muy grandes
− Tiempo real
− Comunicaciones
− Multitareas y procesos distribuidos
− Frecuentemente requisitos de confiabilidad
Utilización_del_Tiempo_de_los_programadores
Estructuras de programas( 135 y 17% del tiempo del día)
Lectura de manuales y programas
Comunicaciones de trabajo
Usos personales
33
Varios
Entrenamiento
Correo
La_productividad_se_puede_medir
− Lineas Código/mes
− Páginas documentación por programa/mes
− Casos prueba escritos y ejecutados programa/mes
Factores_de_calidad_y_productividad
− Se aumenta al mejorar los procesos (actividades)
− Necesarias para el desarrollo y mantenimiento de los
productos
− Implican la necesidad de actividades sistemáticas:
− Capacidades individuales
− Comunicaciones en el grupo
− Complejidad del producto
− Notaciones apropiadas
− Enfoques sistemáticos
− Control de cambios
− Nivel tecnológico
− Tiempo disponible
− Nivel confiabilidad
− Especialización requerida
− Facilidades y recursos
− Entretenimiento adecuado
− Habilidades gerenciales
− Metas apropiadas
34
− Expectativa creciente
− Otros factores
− Control de Cambios ; comisión que determina cuando se debe
realizar un cambio, y evaluar estos.
Conceptos_sobre_administración_de_productos
− Tanto las actividades técnicas como las gerenciales son
necesarias para el éxito de un proyecto
− El Gerente controla los recursos y actividades técnicas,
son los últimos responsables de que el producto se
entregue:
− Coste previo
− Funcionabilidad y calidad que exige el cliente
− Tiempo
− Actividades del gerente
− Contratación de proyectos
− Contratación de personal
− Confección plan de trabajo
− Desarrollo de estrategias de mercado
− Gerente se encarga de la administración y comprende:
− Organización
− Seguimiento del proyecto
− Estimación de costes
− Control del presupuesto
− Definición de logros del proyecto
− Determinación del avance del proyecto
− Reasignación de recursos
35
− Ajuste del calendario del proyecto
− Establecer procedimientos de control de calidad
− Comunicación entre miembros del proyecto
− Acuerdos contractuales con los clientes
− Observancia términos legales y contractuales
LA CRISIS DEL SOFTWARE
− Se refiere a los problemas encontrados en el desarrollo del
software de computadoras
− Los problemas no están limitados al software que no funcio−
na
− Sino que la crisis del software abarca los problemas aso−
ciados con:
− Como desarrollar el software
− Técnicas
− Herramientas
− Métodos
− Como mantener un volumen creciente de Software
existente
− Como podemos esperar satisfacer la demanda crecien−
te de software
− Hay muchos problemas, los más importantes:
(1) La planificación y estimación de costes es fre−
cuentemente muy imprecisa
(2) La productividad de la gente del Software no co−
rresponde con la demanda de sus servicios
(3) La calidad del software no llega a ser a veces ni
36
adecuada
− Estos problemas son debidos a:
− Se ha sufrido el sobrepasar los costes en orden de
magnitud
− Se ha errado en la planificación en meses o años
− Se ha hecho muy poco para mejorar la productividad
de los trabajadores en software
− Los errores de los nuevos programadores producen en
los clientes insatisfacción y falta de confianza
− Tales problemas son sólo las manifestaciones mas visibles
de otras dificultades del Software:
− No tenemos tiempo de recoger datos sobre el proce−
so de desarrollo del software
− Sin datos históricos como guía, la estima−
ción no ha sido buena y los resultados pre−
dichos muy pobres
− Sin una indicación sólida de productividad
no podemos evaluar con precisión la eficien−
cia de las nuevas herramientas,técnicas o
estandares.
− La Insatisfacción del cliente con el sistema termi−
nado se produce demasiado frecuentemente:
− Los proyectos se acomenten frecuentemente con
solo una vaga indicación de los requerimien−
tos del cliente
− Normalmente la comunicación entre el cliente
37
y el que desarrolla el software es muy escasa
− La calidad del software es normalmente cuestionable
− Se ha empezado a comprender recientemente la
importancia de la prueba sistemática y tecni−
camente completa del software.
− Están comenzando a emerger conceptos cuanti−
tativos solidos sobre la fiabilidad del Soft−
ware y garantías de calidad.
− El software existente puede ser muy difícil de man−
tener
− Las tareas de mantenimiento del software se
llevan la mayor parte de los dólares invertidos
en software
− El mantenimiento no se ha considerado un crite−
rio importante en la aceptación del software
− No documentación, aspecto en el que influyen
todas las contingencias del proyecto
Las causas
− Los problemas asociados con la crisis del software
se han producido por el carácter del propio soft−
are y los errores de las personas encargadas de
de su desarrollo
− El software es un elemento lógico en vez de físico
Por tanto,el éxito se mide por la calidad de una
única entidad
− EL software no se rompe
38
Si se encuentran fallos,existe una alta probabi−
lidad de que se introduzcan inadvertidamente durante
el desarrollo y no se detectaran en la prueba
− El mantenimiento incluye normalmente la corrección
o modificación del diseño
− El desafio intelectual del desarrollo del software
es seguramente una de las causas de la crisis del
software
− El gestor de comunicarse con todos los componentes
implicados en el desarrollo del software:
− Clientes
− Realizadores del Software
− Equipos de soporte
− Otros
La comunicación puede romperse debido
− A las caracteristicas especiales del soft−
ware.
− Los problemas particulares asociados con su
desarrollo son mas comprendidos
Cuando ocurre esto, los problemas asociados con la
crisis del software se multiplican
− Los trabajadores del software han tenido muy poco en−
trenamiento formal en las nuevas técnicas de desarro
llo de software.
− Malos hábitos que dan como resultado una
pobre calidad y mantenimiento del software
39
− Resistencia al cambio.Probablemente la causa real de
la crisis del software sea que:
Mientras el potencial de calculo (hardware)
experimenta enormes cambios, la gente del Software
responsables de aprovechar dicho potencial, se o−
ponga normalmente a los cambios cuando se discuten
y se resistan al cambio cuando se introduce
MITOS DEL SOFTWARE
− Muchas de las causas de la crisis del software pueden ser
encontradas en una mitología que surge durante los primeros
años del desarrollo del software
− Los mitos del software propagaron información errónea y con
fusión
− Los mitos del software tienen varios atributos que los
hacen insidiosos:
− Aparecen como declaraciones responsables de hechos
− Tuvieron un sentido intuitivo
− Frecuentemente fueron promulgados por expertos que
" estaban al día "
− Surgen en los primeros años del desarrollo
Mitos_de_Gestión
− Los gestores están normalmente bajo la presión de cumplir
presupuestos, hacer que no se retrase el proyecto y mejorar
la calidad. El gestor se agarra a un mito del software aun−
que tal creencia sólo disminuya la presión temporalmente
Mito: ¿Porqué debemos cambiar nuestra forma de desarro−
40
llar el Software?
Estamos haciendo el mismo tipo de programación a−
hora que hace diez años
Realidad: Aunque el dominio de la aplicación puede ser el
mismo, la demanda de una mayor productividad y
calidad, y el papel critico del software en obje−
tivos comerciales estratégicos, ha aumentado sus−
tancialmente
Mito : Tenemos un libro que está lleno de estandares y
procedimientos para construir software
Realidad: ¿Pero se usa?,¿conocen los trabajadores su
existencia?,¿refleja las practicas modernas en
desarrollo del software?,¿es completo?. En muchos
casos la respuesta a todas estas preguntas es no
Mito : Nuestra gente dispone de las herramientas de
desarrollo de software más avanzadas, después de
todo les compramos las computadoras mas nuevas
Realidad: Se necesita mucho más que el último modelo de
computadora, herramientas de software, las cua−
les son mucho mas importantes que el hardware para
conseguir buena calidad y productividad.
Mito: Si fallamos en la planificación podemos añadir más
programadores y adelantar el tiempo perdido
Realidad: El desarrollo de software no es un proceso mecá−
nico como la fabricación . Añadir gente a un pro−
yecto software retrasado lo retrasa aun mas.
41
Cuando se añaden nuevas personas,la necesidad de
aprender y comunicarse con el equipo puede y hace
que se reduzca la cantidad de tiempo gastado en el
desarrollo del producto
Puede añadirse gente, pero sólo de una manera
planificada y bien conocida
Mitos_del_cliente
− Un cliente que solicita una aplicación software puede
ser interno a la compañía o una compañía exterior
− El cliente cree en los mitos que existen sobre el soft−
ware debido a que los gestores y trabajadores responsa−
sables hacen muy poco para corregir la mala Información
− Los mitos conducen a que el cliente se cree una falsa
expectativa y finalmente, quede insatisfecho con el de−
sarrollo del software
Mito: Una declaración general de los objetivos es sufi−
ciente para comenzar a escribir los programas, po−
demos dar los detalles más adelante
Realidad: Una mala definición inicial es la principal causa
del trabajo baldío en software. Una descripción for−
mal y detallada del dominio de la información,
funciones,rendimiento,interfaces, ligaduras de dise−
ño y criterios de Validación es esencial. Estas
caracteristicas pueden determinarse sólo después de
una exhaustiva comunicación entre el cliente y el
analista
42
Mito: Los requerimientos del proyecto cambian continuamen−
te, pero los cambios pueden acomodarse fácilmente ya
que el software es flexible
Realidad: El impacto del cambio varia según el tiempo en
que se introduzca
_____________
|||
Coste | | |
|||
del | | 60 − |
| __________ | |
Cam− | ___________ | | | 100x |
bio | | 1x | | 1,5−6x | | |
|__|_________|__|________|____|___________|_______
Definición Desarrollo Mantenimiento
Si se pone atención en dar la definición inicial,los
cambios solicitados pueden pronto acomodarse facil−
ente, con relativamente poco coste
Cuando los cambios se solicitan durante el diseño
diseño del software, el impacto en el coste crece
rápidamente.
Cuando se solicita al final de un proyecto, los cam−
bios pueden producir un orden de magnitud más caro
que el mismo cambio pedido al principio.
Mitos_de_los_realizadores
− Los mitos en los que aún creen muchos programadores
43
se han fomentado durante cuatro décadas de cultura
Informática
− Las viejas formas y actitudes tardan en morir
Mito: No hay realmente ningún metodo para el análisis,dise−
ño y prueba que funcione bien, yo simplemente me voy
a mi terminal y comienzo a codificar
Realidad: Existen en la industria métodos comprobados para
el diseño,análisis y prueba, ninguno es infali−
ble, pero el uso de una metodología para el de−
sarrollo del software está implícito en todos
ellos
Mito: Una vez que escribimos el programa y hacemos que fun−
cione, nuestro trabajo ha terminado.
Realidad: Mientras más pronto se comience a escribir código
más se tarda en terminarlo
El desarrollo del software abarca tres actividades
− Definición
− Desarrollo
− Mantenimiento
Además los datos industriales indican que entre el
50% y 70% de todo el esfuerzo dedicado a un programa
se realizara después de que se le haya entregado al
cliente por primera vez.
Mito: Hasta que no tengo el programa ejecutándose,
realmente no tengo forma de establecer calidad
Realidad: Uno de los mecanismos mas efectivos para garanti−
44
zar la calidad del software puede aplicarse desde el
principio de un proyecto, la revisión estructurada
(Walktroug). La revisión del software es filtro de
calidad que se ha comprobado que es más efectivo
que la prueba, para encontrar ciertas clases de
defectos en el software
Mito: Lo único que se entrega al terminar el proyecto es el
programa funcionando
Realidad: El programa es solo una parte de una configura−
cion del software, que incluye
Estructuras
/ de datos \
/\
/\
Plan => Especificación => Diseño => Listado => Programa
requerimientos \ funcionando
\/
\ Especifica− /
cion de Pruebas
La documentación
− Base para un buen desarrollo
− Base para tareas de mantenimiento
Mito: Una vez que el Software se está usando, el manteni−
miento es mínimo y puede manejarse sobre la base de
hacerlo como se pueda
Realidad: La mitad de un presupuesto se gasta en manteni−
45
miento, por tanto el mantenimiento del software
debe de
− organizarse
− Planificarse
− Controlarse
Como si fuera un cliente
PARADIGMAS DE LA INGENIERIA DEL SOFTWARE
− Son diferentes enfoques o aproximaciones para la solución de
la crisis del software
− Aunque hay que ser conscientes, que debido a las propias
características del software y a las personas que en el
trabajan (diferentes problemas,diferentes procedencias y
y formación) esta no desaparezca de un día para otro
− Según Fritz Bauer la ingeniería del software es:
El establecimiento y uso de principios de ingenieria ro−
bustos, orientados a obtener económicamente software que
sea fiable y funcione eficientemente sobre máquina
− La ingeniería del Software abarca un conjunto de tres
elementos claves
− Métodos
− Herramientas
− Procedimientos
− Los métodos suministran el cómo construir teóricamente el
el software. Abarcan una serie de tareas que incluyen
− Planificación y estimación de proyectos
− Análisis de los requerimientos del sistema y
46
del software
− Diseño de estructuras de datos, arquitectura
de programas y procedimientos algorítmicos
− Codificación
− Prueba
− Mantenimiento
− Las herramientas de la ingeniería del software suministran
un soporte automático o semiautomático para los métodos.
Existen herramientas para soportar cada uno de los métodos.
Cuando se integran las herramientas de forma que la infor−
mación creada por una herramienta pueda ser usada por otra
se establece un sistema para el soporte del desarrollo del
software, llamado ingeniería del software asistida por
computadora
− Los procedimientos de la ingeniería del software son la
cola que pega a los métodos las herramientas y facilita el
desarrollo racional y oportuno del software de la
computadora
− Los procedimientos definen
− La secuencia en la que se aplican los métodos
− Las entregas que se requieren (documentos,informes,
formas etc.)
− Los controles que ayudan a asegurar la calidad y
coordinar los cambios
− Las guías que facilitan a los gestores del software
establecer su desarrollo
47
− La ingeniería del software está compuesta de pasos que
abarcan los métodos, herramientas y procedimientos.
Estos pasos se denominan frecuentemente paradigmas de la
ingeniería del software
− Un paradigma para la ingeniería del software se elige:
− basándose en la naturaleza del proyecto y de la
aplicación
− Los métodos y herramientas a usar
− Los Controles y entregas requeridos
El_ciclo_de_vida_clásico
____________
| |_____
|Ingeniería| |
| de | |
|Sistemas__|___\|/_____
|________| |____
/|\ | Análisis __|__\|/___
| |__________| |______
| /|\ |Diseño __|____\|/______
| | |_______| |______
| | /|\ |Codificación _|____\|/___
| | | |_____________| |____
| | | /|\ |Pruebas __|__\|/__
| | | | |________| |
| | | | | |Manteni |
| | | | | |miento |
48
| | | | | |________|
||||||
||||||
|_________\|/_______\|/_______\|/__________\|/_______|
Ingeniería y análisis de sistemas
− Comprende los requerimientos globales a nivel sistema
− Contiene una pequeña cantidad de análisis y diseño a
nivel superior.
− Asigna un subconjunto de los requerimientos al software
Ingeniería de sistemas
− Ingeniería Hardware
− Ingeniería Software
− Define un papel para cada elemento del sistema informa−
tico, lo que implica el papel del software.
Análisis de los requerimientos del software
− Comprende la recogida de los requerimientos de los
usuarios para la construcción del sistema
− Comprende entre otros
− Dominio de la información
− Función
− Rendimiento
− Interfaces
− Que deben ser documentados y revisados por el cliente
para su aprobación
Diseño
− Consiste en trasladar los requerimientos del software
49
a una representación, para garantizar la calidad antes
de acometer la codificación
− Se basa en un proceso multipaso que se enfoca sobre
tres atributos distintos del programa:
− Estructura de datos
− Arquitectura del software
− Detalle procidimental
− Se documenta y forma parte de la configuración del
software
Codificación
− Representa la traslación del diseño a una forma
legible para la máquina
− Si el diseño se realiza de una forma detallada, puede
realizarse mecanicamente.
Pruebas
− Consiste en confirmar que el sistema funciona
correctamente y produce los resultados esperados
− Hay diferentes tipos de pruebas según el objetivo per−
seguido
Mantenimiento
− Consiste en la modificación del sistema para su
correcto funcionamiento en función de los requeri−
mientos del momento
− Se realiza una vez que el sistema pasa a explotación
− Los cambios ocurrirán debido:
− A que se ha encontrado errores
50
− A que el software debe adaptarse por cambios del
entorno externo
− A que el cliente requiere aumentos funcionales o
del rendimiento
− El mantenimiento del software se aplica a cada uno
de los pasos del ciclo de vida, del un programa
existente en vez de a uno nuevo
− El ciclo de vida clásico es el mas viejo y mas ampliamente
usado de los paradigmas en la ingeniería del software.Fue
definido en el 70 por Royce.
− Entre los problemas que presenta algunas veces, cuando se
aplica el paradigma del ciclo de vida clásico se encuentran
1.− Los proyectos reales raramente siguen el flujo
secuencial que propone el modelo. Siempre ocurren
iteraciones y se crean problemas en la aplicación
del paradigma
2.− Normalmente es difícil para el cliente establecer
explícitamente al principio todos los requerimien−
tos.Es necesario la duplicidad para acomodar para
acomodar posibles incertidumbres.
3.− El cliente debe tener paciencia. El producto sólo se
ve al final de las etapas del desarrollo del proyecto
Un error importante no detectado hasta que el progra−
ma esté funcionando puede ser desastroso.
Construcción_de_prototipos
− La construcción del prototipo es un proceso que facilita
51
al programador la creación de un modelo de software a
construir
− El modelo tomará una de las tres formas siguientes
− Prototipo en papel que describa la iteración
hombre máquina de forma que facilite al usuario
la comprensión de como se produce la iteración
− Prototipo que funcione que implementa algunos
subconjuntos de la función requerida al software
deseado
− Un programa existente que ejecute parte o toda la
función deseada, pero que tenga otras característi−
cas que deban ser mejoradas en el nuevo trabajo de
desarrollo
− La secuencia de sucesos para el paradigma de Construcción
de prototipos:
_____________
|Recolección|___
|de requeri−|_\|/_______
|mientos_| Diseño__|__\|/______________
/|\ /|\|_Rápido| Construir___|_____\|/______
| | /|\ |_Prototipo| Evaluar y |______
| | | | | refinar los __|____\|/___
| |____|_________| |requerimientos| Producto |
| | /|\ |_Construido|
||||
|___________________________| |____________|
52
− Pasos de la construcción
− Comienza con la recolección de los requerimientos,
reunión entre el técnico y el cliente
− Luego se produce el diseño rápido:
− Se enfoca sobre la representación de los aspec−
tos del software, visibles para el usuario
− conduce a la construcción del prototipo
− Construcción del prototipo
− Evaluación del prototipo por el usuario /cliente
El prototipo es utilizado
− Refinar requerimientos de software a desarrollar
− Se produce un proceso interactivo para que el
prototipo satisfaga las necesidades del cliente
− Facilita al ingeniero una idea clara de que hay
que construir
− Mecanismo para identificar los requerimientos
del software
− La construcción de prototipos como paradigma para la inge−
niería del software puede ser problemático por:
1.− El cliente ve funcionando lo que parece ser una
versión del software ,ignorando que el prototipo
se ha hecho con chicle y alambres, ignora que por
las prisas, no se han considerado los aspectos de
calidad y mantenimiento. El usuario lo quiere de−
finido.
2.− El ingeniero adopta compromisos técnicos para su
53
rápida implantación.Cuando hay que construirlo
de verdad se siguen respetando dichos compromisos
Técnicas_de_cuarta_generación
− El término Técnicas de cuarta generación abarca un amplio
espectro de herramientas software que tienen una cosa en
común: todas facilitan al que desarrolla el software espe−
cificar algunas características del software a alto nivel
− El paradigma T4G se orienta hacia la habilidad de especi−
ficar software a un nivel que sea próximo al lenguaje na−
tural o en una notación que proporcione funciones signi−
ficativas
− Actualmente un entorno para el desarrollo del software
que soporte el paradigma de T4G incluye algunas o todas
de las siguientes herramientas
− Lenguajes no procedimentales para :
− La consulta a bases de datos
− Generación de informes
− Manipulación de datos
− interacción y definición de pantallas
− Generación de código
− Capacidades gráficas de alto nivel
− Capacidad de hoja de calculo
− Pasos del paradigma
___________________
| |_____
|Recolección de___|___\|/_____
54
|Requerimientos| |_____
|______________| Estrategia__|___\|/____
/|\ | de diseño |Implemen− |____
| |___________|tación u−__|__\|/__
| /|\ |sando T4G| |
| | |_________|Producto|
| | /|\ |________|
||||
|______________|___________|________|
− Empieza con la recolección de requerimientos
− En aplicaciones pequeñas,puede ser posible ir di−
rectamente desde el paso de establecimiento de re−
querimientos, a la implementación , usando un len−
guaje de cuarta generación no procedimental
− El diseño es fundamental para grandes proyectos
− La implementación usando Técnicas de 4G facilita al
que desarrolla el software, la descripción de los
resultados deseados, los cuales se traducen
automáticamente en código fuente para producir los
resultados
− Para transformar la implementación T4G en un
producto debe:
− Dirigir una prueba completa
− Desarrollar una documentación con sentido
− Ejecutar todas las otras actividades de tran−
sición requeridas para los demás paradigmas
55
− Los problemas que plantea la aplicación de T4G son entre
otros
1.− Con muy pocas excepciones, el dominio de aplicación
actual de loas T4G está limitado a las aplicaciones
de sistemas de información comerciales, especifica−
mente, el análisis de información y la obtención de
informes en grandes bases de datos
2.− La recolección de datos preliminares que acompaña al
al uso de T4G parece indicar que el tiempo requerido
para producir software, se reduce mucho para aplica−
ciones pequeñas y de tamaño medio y que la cantidad
de análisis y diseño para las aplicaciones pequeñas
también se reduce
3.− Sin embargo el uso de T4G para grandes trabajos de
desarrollo de software, exige el mismo o más tiempo
de análisis, diseño y prueba, perdiéndose así un
tiempo sustancial que se ahorra mediante la eli−
minación de la codificación.Produciéndose efectos
negativos de poca calidad y de indiferencia del
cliente.
Los paradigmas vistos hasta ahora, no son sólo métodos alter−
nativos, si no que también pueden ser métodos complementarios
Otros_paradigmas:
Desarrollo_incremental
Consiste en la construcción del software para satisfa−
cer pocos requerimientos inicialmente.
56
La construcción se realiza de forma que facilite la
incorporación de nuevos requerimientos, alcanzando así ( el
sistema) una más alta adaptabilidad.
1.− Reduce el tiempo inicial de desarrollo porque tie−
ne un reducido nivel de funcionalidad
2.− El software puede ser aumentado más fácilmente y por
un periodo mayor de tiempo.
Prototipos_evolucionados
Es una extensión del desarrollo incremental
El número y frecuencia de los prototipos operacionales
se incrementa.
El énfasis se hace en evolucionar a una solución de un
modo continuo en vez de la construcción de un número discre−
to de sistemas
En este enfoque se crea rápidamente un prototipo demos−
trando la funcionalidad donde los requerimientos son bien
conocidos.
Cada prototipo sucesivo explora una nueva área de las
necesidades del usuario, consiguiendo así que la solución
(final) se acerque mucho más a las necesidades del usuario.
UNA VISION GENERICA DE LA INGENIERIA DEL SOFTWARE
− El proceso de desarrollo del software contiene tres fases
genéricas, independientemente del paradigma de ingeniería
elegido:
− Definición
− Desarrollo
57
− Mantenimiento
− Definición
− Se enfoca sobre el que hay que hacer independientemente
de como hay que hacerlo.
− Durante esta fase,el desarrollador debe identificar
para definir un sistema correcto:
− Información que ha de ser procesada
− Función
− Rendimiento
− Interfaces a establecer
− Ligaduras de diseño que existen
− Criterios de validación que se necesitan
− Por tanto han de identificarse los requerimientos
claves del sistema y del software
− En la fase de definición independientemente del para−
digma empleado se producen tres pasos específicos
− Análisis del sistema
− Define el papel de cada elemento de un sistema
informático, asignando finalmente el papel que
jugara el software
− Planificación del proyecto software
− Una vez asignado el ámbito del software, se a−
signan los recursos, se estiman los costes y
se definen las tareas y planificación del
trabajo
− Análisis de requerimientos
58
− El ámbito definido para el software de la
dirección, pero antes de comenzar a trabajar,
es necesario disponer de una información más
detallada del dominio de la información y de
la función del software
− La fase de Desarrollo
− Se centra en el como hay que hacerlo
− Intenta descubrir
− Como han de diseñarse las estructuras de datos y
y arquitectura del software
− Como han de implementarse los detalles procedi−
mentales
− Como ha de trasladarse el diseño a un lenguaje de
programación
− Como ha de realizarse la prueba
− Se producirán tres pasos concretos:
− diseño del software
Traslada los requerimientos del software a
un conjunto de representaciones que describen
la estructura de datos, arquitectura y procedi−
miento algorítmico
− Codificación
Las representaciones del diseño deben de
trasladarse a un lenguaje artificial que da como
resultado unas instrucciones ejecutables en la
computadora
59
− Prueba del software
Una vez que el software se ha implementado
en una forma ejecutable por la maquina, debe ser
probado para descubrir los defectos que pueden
existir en la función, lógica e implementación
− Fase de mantenimiento
− Se enfoca sobre el cambio que va asociado con una
corrección de errores, adaptaciones requeridas por la
evolución del entorno del software y modificaciones
debidas a los cambios de los requerimientos del
cliente para reforzar o aumentar el sistema.
− Durante la fase de mantenimiento se encuentran tres
tipos de cambios
− corrección
El mantenimiento correctivo cambia el software
para corregir los errores
− Adaptación
El mantenimiento adaptativo se traduce en modi−
ficaciones del software para acomodarlo a los
cambios de su entorno externo
− Aumento
El mantenimiento perfectivo aumenta el software
más allá de sus requerimientos funcionales origi−
nales
− Otras actividades que inciden en la calidad y fiabilidad
del software, que complementan a las fases y subfases
60
vistas son:
− Revisiones
Se realizan durante cada subfase para asegurar
que se mantiene la calidad
− Documentación
Se desarrolla y controla para asegurar que toda
la información sobre el sistema esta disponible
para un uso posterior
− El control de los cambios
Se instituye de forma que los potenciales
cambios sean mejorados y registrados
− Analiza el impacto del cambio
− Lo registra
− Controla la evolución del sistema
Tema 2 −− PLANIFICACION DE UN PROYECTO SOFTWARE
− La crisis del software nace para solucionar que los proyec−
tos:
− Aumentan los costes
− Retrasos de tiempos
− Poca calidad y fiabilidad
− Aumento coste del mantenimiento
− La razón principal es la falta de planificación
− La planificación debe aplicarse tanto en el desarrollo como
a la operación del sistema
− La planificación proporciona una guía para el desarrollo
del software y debe proporcionar
61
− Alcance del software
− Las actividades a realizar
− Las referencias a considerar
− El coste del producto
− Agenda a seguir
− Esto se realiza con dos actividades
− Investigación : que proporciona a partir de la
especialización del sistema (alcance), la fun−
ción, el rendimiento y las interfaces del sis−
tema así como su fiabilidad.
− Una vez consumida la etapa de investigación,
conocido el alcance del software y conocidas
las actividades a realizar, se realiza la se−
gunda actividad
− Estimación: que proporciona los recursos a u−
tilizar y el coste del producto
Observaciones_sobre_la_estimación
− La estimación es mas un arte que una ciencia
− Par la estimación es necesario un nivel de experiencia
(Función del proyecto), hay técnicas para la estimación
de costes, recursos y agenda
− Un gran problema a la hora de la estimación, es la fal−
ta de información histórica. Esta falta obliga a reali−
zar la estimación en base a datos cualitativos en de
cuantitativos
− 3 factores cuya incidencia en la estimación es muy im−
62
portante
− Complejidad del proyecto
− El tamaño del proyecto
− El grado de estructuración
− La complejidad del proyecto
− Medida relativa, condicionada por la familiaridad
− La incertidumbre de la estimación es directamente
proporcional a la complejidad
− Se han propuesto ciertas medidas cuantitativas de
complejidad del software. Tales medidas se a−
plican en el diseño o a nivel de Código y son por
tanto difíciles de usar durante la planificación
del software
− Sin embargo, se puede establecer otras evaluacio−
nes mas objetivas de la complejidad al principio
del proceso de la planificación
− El Tamaño del proyecto
− Puede afectar la precisión y eficacia de las es−
timaciones
− A medida que crece el tamaño aumenta la interde−
pendencia entre las partes del software.
− Es necesario aplicar partición del problema, para
la estimación, pero se hace mas difícil dado que
las partes pueden ser aún grandes.
− El grado de estructuración
− Referido a la facilidad de compartimentalizar las
63
funciones(partición) a procesar y de la estructura
jerárquica de las informaciones a procesar
− La incertidumbre es inversamente proporcional al
grado de estructuración.
− La disponibilidad de información histórica también de−
termina el riesgo de la estimación
− No se dispone de ella debido a las propias carac−
terísticas del software.
− Todos los proyectos son diferentes
− Dificultad de la categorización de los proyectos
− El riesgo se mide por el grado de incertidumbre en las
estimaciones cuantitativas establecidas para los
recursos, costes y métodos
Objetivos_de_la_planificación
− Después de todo esto podemos decir que el objetivo de
la planificación es realizar estimaciones responsables
de los recursos,costes y métodos a través de un proceso
de descubrimiento de la Información (investigación).
− Decíamos que la planificación debe proporcionar
− Alcance del software (investigación)
− Estimación de los recursos
Entre otras cosas
Alcance_del−software
− La primera actividad en la planificación del proyecto
del software es determinar el alcance del software
− Utiliza como documento la especificación del sistema,
64
donde está asignado al software una función y un ren−
dimiento, que deberán evaluarse para que el alcance no
sea ambiguo ni incomprensible tanto para los técnicos
como para los directivos.
− La declararación del alcance del software debe estar
delimitada. Por tanto:
− Los datos cuantitativos estarán explicitamen−
te establecidos(numero usuarios simultáneos)
− Las restricciones y/o limitaciones han de ser
señaladas(coste restringe tamaño memoria)
− Los factores de mitigación han de ser descri−
tos (los algoritmos deseados)
− Los aspectos que abarca el alcance del software son:
− Función
− Rendimiento
− Una misma función con diferentes rendimientos, puede
variar considerablemente el esfuerzo (Recurso) y coste
− La función y el rendimiento deben ser evaluados a la
vez
− Pueden ser refinadas para la aportación de mayores de
talles, dado que la estimación se realiza con una
orientación funcional
− INTERFACES
− Corresponde a las interrelaciones del software
con el resto de los elementos que componen el
sistema
65
− El interfaz pueden tener repercusión en:
− Recursos
− Costes
− Métodos de desarrollo
− Por lo que es necesario analizar tanto su natu−
raleza como su complejidad
− El software puede tener interfaz con
− Hardware que ejecutan el software y dispo−
sitivos controlados indirectamente por el
software
− Software ya existente o no que debe ser en
lazado con el nuevo software
− Gente que hace uso del software por medio
de terminales u otros medios de entrada/
salida
− Procedimientos que preceden o suceden al
software como una serie secuencial de ope−
raciones
− El aspecto menos preciso del alcance del software es
la discusión de su fiabilidad
− Aspecto difícil de cuantificar
− " Capacidad de un programa para realizar una función requerida bajo ciertas condiciones
durante un periodo determinado "
− Sistemas con valor humano véase control de
operación (tráfico aéreo o de transporte espa−
cial) no tiene qué fallar o se perderían vidas
66
humanas, luego tienen que tener consideraciones
especiales para asegurar la fiabilidad. Un sis−
tema de control de inventario no debería
fallar, pero el impacto del fallo es conside−
rablemente menos dramático.
Recursos
− La segunda tarea de la planificación del desarrollo
del software es la estimación de los recursos reque−
ridos para acometer el esfuerzo de desarrollo de soft−
ware.
− Dos tipos de recursos contemplados
− Humanos
− Técnicos
− La evaluación de cada recurso se realiza en base a 4
características
− Descripción recursos Técnicos/ habilidad requerida
recursos humanos
− Disponibilidad general
− Intervalo de Utilización de los recursos
− fecha de emisión de los recursos técnicos/ fecha
de comienzo de los recursos humanos
− Las dos ultimas caracteristicas es lo que se denomina
" ventana temporal" que representa la disponibilidad
de un recurso para un proyecto especifico, que debe
ser fijada lo antes posible para una buena planifica−
ción de los recursos( Colisión de intereses)
67
Recursos humanos
− Representan los recursos primarios para el desarrollo
del software
− Los buenos recursos humanos escasean lo que implica
gran incidencia en la crisis del software
− El planificador comienza evaluando el alcance(investi−
gación) y seleccionando las técnicas requeridas para
completar el desarrollo
− Dado que el recurso humano es el primero en especifi−
carse, el perfil del mismo se define en base
− Alcance del Software
− Técnicas especiales
− En base a las caracteristicas que definen un recurso
− Habilidad requerida
− La posición en la organización
− La especialidad
− Disponibilidad general
− Para proyectos relativamente pequeños, una
sola persona puede llevar a cabo todos los
pasos del software, consultando con especia−
listas siempre que lo requiera
− Para amplios proyectos, la participación varia
a lo largo del ciclo de vida
− Duración
− Tiempo estimado de uso del recurso
− Fecha de comienzo
68
− Fecha de inicio recurso
− El número de recursos humanos a asignar a un proyecto
sólo se puede determinar después de estimado el es−
fuerzo de desarrollo
− Decíamos que las 2 ultimas características eran una
ventana temporal, efectivamente los recursos humanos
no se aplican linealmente durante el desarrollo ,sien−
do esta la razón.
− La participación de la dirección se da al principio del
ciclo de vida, disminuye a niveles mas bajos durante
los pasos centrales de la fase de desarrollo y crece a
medida que se acerca la conclusión del proyecto
− El personal técnico senior también participa
activamente durante la planificación del proyecto, el
análisis de requerimientos, el diseño y las etapas de
pruebas finales
− El personal júnior esta más involucrado durante las
últimas etapas de diseño, de codificación y los pasos
de pruebas finales
Recursos Técnicos
Pueden ser de dos tipos
− Recursos Hardware
− considerados herramientas para el desarrollo
del software
− Existen tres tipos o categorías de hardware du−
rante la planificación del proyecto de software:
69
− El de desarrollo
− La maquina objetivo
− Otros elementos de hardware de nuevo sistema
− El sistema de desarrollo ( también llamado siste
ma anfitrión)
− Hardware para desarrollar software
− Acceso a un hardware efectivo
− Sistema o máquina objetivo
− Hardware para instalación del software
− En la mayoría de las aplicaciones de mini−
computadoras y de grandes sistemas, la má−
quina objetivo y el sistema de desarrollo
son idénticos
− Otros elementos del hardware
− Elementos hardware que facilitan funciones
especificas durante el desarrollo
− Recursos Software
− Son recursos (software) que facilitan el desa−
rrollo del proyecto
− La primera aplicación del software para el de−
sarrollo de software fue la reconstrucción
− Hoy se disponen de amplia serie de herramientas
de software.La figura muestra una jerarquía de
las herramientas de software que están
disponibles hoy (herramientas actuales) o que
estarán disponibles en corto plazo (futuras)
70
herramientas)
− herramientas orientadas al Código: son a menudo
las únicas disponibles: compiladores, editores
lanzadores y cargadores
− Herramientas de metodologia
− dan soporte a la planificación del proyecto, al
análisis de los requerimientos, al diseño, a las
pruebas, a la gestión de configuraciones, al man−
tenimiento y otras actividades
− Herramientas de 4 Generación
− Lenguajes de petición de bases de datos
− Generadores de Código
− Paradigmas de 4G
− Dentro de los recursos Software, hay un concepto
fundamental: "La reusabilidad" que representa la
facilidad de la Utilización de un software(en explo−
tación o no) para la construcción de uno nuevo.
− La reusabilidad minimiza el esfuerzo de desarrollo
− Existen pocas bibliotecas de software reutilizables
debido a:
− Escasez de técnicas sistemáticas para hacer
adiciones a una biblioteca
− Difícil tipificación
− Dificultad de imponer interfaces
estandard para software reutilizable
− Pobreza para alcanzar los objetivos de
71
− Calidad
− Fiabilidad
− Mantenimiento
− La gente que desarrolla desconoce la existen
cia de dichas bibliotecas.
− Si existe software reutilizable como recurso, el
planificador debe considerar:
1 − Si el software existente satisface los re−
querimientos,comprarlo.El coste de la adqui−
sición del software existente será casi
siempre menor que el coste del desarrollo de
software equivalente
2.− Si el Software existente requiere alguna modi
ficación antes de que pueda ser propiamente
integrado en el sistema, pensarlo y evaluar−
lo. El coste de modificar software existente
puede a veces ser mayor que el coste de
desarrollo de software equivalente
− Normalmente nos encontramos en el segundo caso
− Problema: muchas veces no se hace una buena especi−
ficación de los requerimientos software (demasiado
General) lo que implica:
− Difícil tomar decisiones de compra
− Difícil evaluación en el supuesto de modi−
ficación
En ambos casos no sabemos se ajustan a nuestras
72
necesidades
− Resumiendo el software como recurso puede estar en
estas tres formas:
− Existente en la organización
− Existente fuera de la organización, y es ne−
cesario adquirirlo
− No existente y tiene que ser desarrollado
− El primer caso ya visto en el contexto de la reusabi
lidad
− El tercer caso implica un desarrollo en la organiza−
ción
− El segundo caso es el analizamos y se refiere a la
adquisición (compra de software)
Adquisición_del_software
− Representa la toma de decisión de Hacer−comprar
software, para el desarrollo de un proyecto
− Las alternativas son varias:
− El Software se compra/alquila ya adecuado
(se ajusta a las especificaciones)
− El software puede ser comprado y luego modi−
ficado para ajustarse a las especificaciones
− El software puede ser contratado para su de−
sarrollo por un consultor externo de modo que
se ajuste a las especificaciones
− El coste de oportunidad dentro de las organizaciones
es decir, el coste que me va a salir hacerlo,o encar
73
garlo
− Una vez vistas las alternativas, la decisión final
de hacer−comprar se basará en las condiciones:
− Fecha entrega externa menor fecha fin desarro−
llo
− Coste compra externa menor coste desarrollo
interno
− Coste soporte externo(mantenimiento) menor
coste soporte interno
− Volviendo nuevamente a las tres alternativas, para
la adquisición, la 1 y 2 (compra y compra con modi−
ficaciones) están referidas a paquetes externos
− Un procedimiento de evaluación de dichos paquetes
sería
1.− Desarrollo especificación función y rendi−
miento software deseado
2.− Definir el mayor nº de características medi−
bles
3.− Evaluar coste desarrollo interno y fecha fin
4.− Selección de paquetes candidatos que se
ajusten a la especificación
5.− Desarrollo matriz comparación funciones clave
6.− Pruebas estandarizadas de comparación de pa−
quetes seleccionados
7.− Evaluación de cada paquete basandose en:
− Calidad de productos anteriores
74
− Soporte Post−venta
− Reputación organización
− Etc.
8.− recabar información de otros usuarios
− La 3º alternativa (desarrollo interno) exige por
parte de la organización constantemente:
− Exigir aplicación de ingeniería
− Exigir aplicación de estandares
− Definir configuraciones
− Implementar controles que aseguren el al−
cance de los requerimientos
− Definición de documentación
− En cualquiera de las tres alternativas, un factor
importantísimo es la disponibilidad de recursos
− Humanos
− Técnicos/hardware
Por parte de la organización contratante
PLANIFICACION Y ESTRUCTURA ORGANIZACIONAL
DE UN PROYECTO DE SOFTWARE
− Para realizar la planificación lo primero es definir el
ciclo de vida del producto que incluye todas las
actividades requeridas para
− Definirla
− Desarrollarlo
− Probarlo
− Implementarlo
75
− Utilizarlo
− Mantenerlo
− Una vez elegido el ciclo de vida, hay dos formas de
realizar la planificación en base al tiempo
1.− Fecha final de lanzamiento cerrada, lo cual
implica la distribución del esfuerzo, en el
intervalo definido, en base a las actividades
a realizar
2.− Fecha final de lanzamiento estimada, lo cual
implica que la distribución del esfuerzo se
realiza en base a optimización de recursos,
pudiendo implicar el retraso de la fecha final
− Cuando comenzamos a hablar de planificación, entre otras
cosas Decíamos que debe proporcionar la estimación de
recursos:
− Humanos
− Técnicos
− Humanos: los recursos humanos están directamente relacio−
nados con las actividades a realizar. Implica que la asig−
nación de recursos a actividades en un proyecto involucra
muchos recursos humanos.
− Existe la creencia (mito) que cuando un proyecto se
retrasa, es suficiente añadir más personas para terminarlo
a tiempo. Falso por
− Los recursos humanos y el tiempo sólo son intercam−
biables si la tarea puede ser subdividida entre va−
76
rios trabajadores incomunicados entre si.
− Añadir más recursos humanos a un proyecto lo retra−
saría más (probablemente) debido al efecto de la
curva de aprendizaje, lo que implica un incremento
de comunicaciones [N(N−1)/2] que implica que la re−
lación del nº de personas trabajando en un proyecto
y la productividad global no es lineal.
− Curva de aprendizaje: intervalo de tiempo transcurrido que
necesita un nuevo miembro para aprender y convertirse en
un miembro adaptado al proyecto.
− Después de lo visto los grupos de trabajo son malos:
No: si la comunicación sirve para mejorar tanto la ca−
lidad como la facilidad de mantenimiento
− Otra de las cosas que debe proporcionar la planificación
son:
− Actividades a realizar
− Agenda a seguir
− Las actividades son las tareas que debemos realizar, y la
agenda nos determina cuando y en que orden
− La pregunta a formular es: ¿cabe el paralelismo en las
actividades o el desarrollo es lineal?
Respuesta: paralelismo
− La figura representa la naturaleza concurrente de las acti−
vidades en la ingeniería del software
− Descripción de la figura
− El análisis y revisión de los requerimientos son las
77
primeras tareas a realizar y dan la base del
paralelismo para las tareas siguientes.
− Una vez que los requerimientos han sido identificados
y examinados, las actividades del diseño preliminar y
planificación de pruebas comienzan en paralelo
− La naturaleza modular del software bien diseñado le
lleva a si mismo a seguir un desarrollo paralelo del
diseño detallado, la codificación y las pruebas de
unidad.
− Cuando se terminan las componentes del software,
comienza la tarea de la prueba de integración
− Por ultimo, la prueba de validación prepara el soft−
ware para ser entregado al cliente
− Las referencias están situadas a intervalos Regulares
a lo largo del proceso de ingenieria del software,
proporcionado al gestor una indicación regular del
proyecto
− Cada referencia se alcanza una vez que la documen−
tación producida como parte de la tarea de ingenie−
ria del software ha sido revisada satisfactoriamen−
te.
− La naturaleza concurrente de las actividades de la
ingeniería del software conducen a un importante numero de
requerimientos de planificación.
− Debido a que las tareas paralelas se suceden de forma
asíncrona, el planificador debe determinar la dependencia
78
entre las tareas para asegurar el progreso continuo hasta
la terminación
− Además el director del proyecto debe ser consciente de las
tareas que están en el camino crítico, es decir, tareas que
tienen que completarse a tiempo si el proyecto en conjunto
ha de ser terminado a tiempo
Distribución de esfuerzos
A) con ingenieria
− se le suele llamar la regla 40−20−40
− Dentro del 40% de análisis y diseño
− 2−3% en planificación
− Análisis de requerimientos 10−20%
− Diseño 20−30%
− La codificación del 10−20 %
− Las pruebas y posterior depuración 30−50%
B) Sin ingeniería
− Planificacion , análisis y diseño 10%
− Codificación 50%
− Pruebas programadores y pruebas globales 40%
Métodos de Planificación
− Existen muchos métodos para la planificación
− Existen muchos métodos disponibles en PC,s ejemplos:
− La técnica de revisión y evaluación del programa(PERT)
− El método del paso critico (CPM)
− Ambas técnicas desarrollan una descripción de la red de
tareas del proyecto, es decir una representación gráfica
79
o tabular de las tareas que deben acometerse desde el
principio al fin del proyecto
− La red de tareas se obtiene:
− Desarrollando una lista de todas las tareas asocia−
das con el proyecto especifico
− y una lista de ordenamientos que indica en que orden
deben acometerse las tareas
− Ambos tipos proporcionan herramientas cuantitativas que
permiten al planificador del software:
− Determinar el camino: la cadena de tareas que de−
termina la duración del proyecto
− Establecer las estimaciones de tiempo más probable
para las tareas individuales
− calcular tiempos límites que definen una ventana
temporal de tiempo para una tarea particular
− El calculo de los tiempos límites incluye
− camino critico implica que si me retraso en las
tareas de él retraso otras tareas y por tanto re−
traso el proyecto
− Lo antes que puede comenzar una tarea cuando todas
las tareas precedentes se completan en el mínimo
tiempo disponible
− Lo mas tarde que se puede iniciar la tarea antes de
que se retrase el tiempo mínimo para la finaliza−
cion del proyecto
− El Final mas temprano = suma del comienzo mas tem−
80
prano y la duración de la tarea
− El final mas tardío = el mas tardío comienzo sumado
a la duración de la tarea
− La franja total = cantidad de tiempo sobrante o
margen permitido en la planificación de tareas de
forma que el camino de la red se mantenga en el
plan
− Los cálculos de tiempo limite llevan a la determinación
del camino critico y proporcionan al gestor un modelo
cuantitativo para la evaluación del progreso al terminar
las tareas
Planificacion organizativa de un proyecto software
− Hay tantas estructuras organizativas como organizaciones
− Estructura genérica
− Recursos libres
− Asignación de tareas
− Se dispone de las siguientes opciones para la aplicación
de recursos humanos a un proyecto que requerirá n
personas trabajando k años
1. n personas son asignados a m diferentes tareas
funcionales, con:
− Relativamente poco trabajo combinado − La coordinación es responsabilidad del
gestor del software, el cual puede tener
mas proyectos que tratar
2. n personas son asignadas a m diferentes tareas
funcionales (m<n)
81
− Se establecen equipos informales
− Puede elegirse un lider por equipo
− La coordinación responsabilidad del gestor
del software
3. n personas se organizan en t equipos
− A cada equipo se le asigna una o mas tareas
funcionales
− Cada equipo tiene una organización especi−
fica
− La coordinación se controla tanto por el
equipo como por el gestor del software
Estructura del proyecto
− Se corresponden( normalmente) con estructuras organicio
nales
1. Formato de proyecto
− Un grupo realiza todo el proyecto
− Algunos miembros permanecen durante instalación y
prueba
− Otros se van (a otros proyectos) pero siguen
responsables del mantenimiento
− Todos los miembros, cuando acaba el proyecto se
se asignan a otros nuevos
2. Formato funcional
− Varios grupos intervienen
− Cada uno realiza una fase
− Cada equipo entrega la documentación de la fase
82
al siguiente
Variante
− 3 Grupos
− Análisis
− Diseño e instrumentación
− Pruebas y mantenimiento
− Grupo de apoyo
− Documentación
− Mantenimiento e instalación
− Formación usuario
− Los miembros de los equipos rotan (formación,
evita tedio, superespecialización)
− requiere mas comunicación
− Requiere muy buena documentación
3 Formato matricial
− Cada función tiene su propia organización y
gente dedicada a esa función
− Cada grupo funcional participa en cada proyecto
− Cada proyecto tiene su jefe
− Cada persona tiene 2 Jefes( concretamente uno
funcional y otro orgánico)
− Mejor control del proyecto
− Superespecialización
− Mejor optimización de los recursos
Estructura de los equipos de programación
− Todo equipo de programación debe tener una organización
83
interna
− Esta depende del proyecto
− Existen tres estructuras básicas
− Grupos democráticos
− Grupos con jefes
− Grupos bajo jerarquía administrativa
− Grupos democráticos
Características
− Equipos sin egoísmo
Mi programa Nuestro programa
− Metas y decisiones por consenso
− Liderazgo rotativo en función de tareas y capaci−
dades
− Los productos son discutidos por todos los miembros
Ventajas
− Cada miembro contribuye a las decisiones
− Aprenden unos de los otros
− Gran comunicación
− No presión, si para todo el equipo
Inconvenientes
− La cantidad de comunicación para todas las
decisiones
− Necesidad de que todos trabajen juntos
− Falta de actividad y responsabilidad
− menor iniciativa
Adecuados: para proyectos investigación, así como para
84
desarrollos largos y difíciles
− Grupos con jefe
Caracteristicas
− Son grupos muy estructurados
− Hay liderazgo
− Funciones claras
Ventajas
− Decisiones centralizadas
− Reducción de las comunicaciones
− Sirven para capacitar
Inconvenientes
− Visiones parciales
− Sensibles a las capacidades técnicas y administra−
tivas del jefe
Son adecuados
− Aplicaciones de procesamiento de datos: Paque−
tes (tipo financiero) que pueden desarrollarse:
− Jefe experimentado
− Programadores poco calificados
− Capacitaciones en ambientes reales
En estos grupos las funciones son:
− Jefe : Planifica
Coordina
Revisa actividades técnicas
Diseña el producto
Instrumenta partes críticas
85
Toma decisiones importantes
Asigna trabajo programadores
− Respaldo/Copia de seguridad
Ayuda al jefe en sus actividades
Lo reemplaza cuando sea necesario
Realiza tareas en general bajo supervisión del
jefe
− Técnicos: 2 a 5
Codificar
Depuran
Documentan
Prueban
− Bibliotecario
− Actua como controlador y coordinador de la confi−
guración del software
Documentación
Listados fuentes
Datos
Cataloga e índexa módulos
Ayuda miembros equipos:
Investigar
Evaluar
Preparar documentos
− en un proyecto debe existir un bibliotecario, pues
el controla la documentación, y la coordinación de
los programadores
86
Grupos bajo jerarquía administrativa
Características
− Ocupa posición intermedia entre los dos anteriores
− Hay un lider del proyecto
− Funciones claras
− Requiere mucha administración/coordinación
Ventajas
− Semidescentraliza la toma de decisiones
− Flexibilidad en la comunicación
Inconvenientes
− Proyección de buenos programadores(técnicos) a
puestos administrativos
Buen técnico no implica buen administrativo
o Comunicación −−−−−−−> o
/\/\
o o <−−−−− Estructura o −−−− o
/|\ /|\ / | \ / | \
o o o o o o o −|−o o−|−−o
\ | / \| /
oo
El_plan_del_proyecto_de_software
− Cada paso del proceso de la ingeniería del software debe
producir algo a entregar que pueda ser revisado y que pueda
servir de base para los pasos posteriores.
− El plan del proyecto de software se produce como culmina−
ción de la etapa de planificación.
87
− Proporciona una línea base de información de costes y de
planificación temporal que se utilizara a lo largo del ci−
clo de vida del software.
− El plan del proyecto de software es un documento relativa−
mente breve que se dirige a una diversa audiencia.
− Debe :
1.− Comunicar el alcance y recursos a los gestores del
Software
2.− Definir el coste y el plan temporal de la revisión
de la gestión
3.− Proporcionar una aproximación global al desarrollo
del software para toda la gente involucrada en el
proyecto
− Se puede usar como guía el siguiente esquema de documento
1. Alcance
a. Objetivos del proyecto
b. Funciones principales
c. Otras características
d. Un escenario de desarrollo
2. Recursos
a. Recursos humanos
b. Recursos hardware
c. Recursos de software
d. Ventanas de disponibilidad
3. Coste
a. Desgloses
88
4. Plan Temporal
a. Red Tareas
b. Diagrama Gantt
c. Tablas Recursos/tareas
− Su propósito es ayudar a establecer la viabilidad del
esfuerzo de desarrollo del software
− El plan se centra en establecer de forma general el qué
y en informar especificamente del cuánto y cómo de largo
de una forma general.
Tema 4 −− ANÁLISIS Y ESPECIFICACIÓN DE LOS
REQUERIMIENTOS
Problemas_en_proyectos_informáticos
− Sobre el desarrollo de grandes aplicaciones software(+ 50K)
se dispone de la siguiente estadística:
− Más del 25% de los proyectos son cancelados antes
de su terminación
− Más del 60% de los proyectos terminados, lo hacen
con un enorme retraso y con un significativo
incremento del coste ( el promedio es un año de
retraso y una duplicación del coste estimado)
− Mas del 75% de los proyectos terminados presentan
posteriormente dificultades de explotación y altos
costes de mantenimiento
− Solo el 1% de los proyectos se terminan dentro del
plazo y costes previstos y cumpliendo requisitos
− El problema que se plantea es el problema de la comunica−
89
ción, es decir de comprensión del interlocutor(cliente).
Generalidades
− Objetivo
Especificar total y consistentemente los requerimien−
tos del producto de una manera concisa y sin ambigüedades,
utilizando para ello una notación formal
− Representa la última fase de la etapa de definición (análisis
de sistemas y planificación) y es esencial para la siguien−
te etapa de desarrollo
− Esta fase se centra:
Que es el producto a construir, sin importar
Como es dicho producto.
− Aunque parece una fase sencilla es todo lo contrario, debido
al alto grado de comunicación requerida entre
/ Usuario \
/|\
Documentación −−−−−−−−−−−−−−− Gerente
\|/
\ Técnicos/
así como las propiedades que debe tener la especificación ,
siendo esta la representación formal de los requerimientos
para un posterior diseño.
− la documentación de entrada de esta fase la proporciona:
− La Especificación del sistema (Análisis del sistema)
− Asigna la función software al sistema
− El plan de Proyecto ( planificación)
90
− define actividades
− Define tiempos
− Define recursos
− Sin un buen análisis y Especificación de requerimientos no
es posible realizar un buen desarrollo del software.
− Para efectuar la especificación de los requerimientos se
realiza el análisis de los requerimientos
− Para realizar la Función del análisis se han desarrollado
diversos métodos. Cada uno de ellos aborda la tarea desde
diferentes ópticas, pero todos ellos están sustentados en
una serie de principios, que permiten el enfoque sistemáti−
co del problema
Principios
1.− Dominio de la información
− Referido a la información (DATOS) que va a proce−
sar el sistema.
− Asociado a este D.I. esta el dominio Funcional que
representa a los procesos ( funciones) que trans−
forman la información
− Ambos Dominios tienen que ser bien comprendidos y
representados
− El dominio de la información contempla 3 visiones so−
bre los datos que procesaran las funciones (programa)
− Flujo de la información que muestra la forma en
que los datos se transforman a medida que pasan
a través del sistema
91
Las transformaciones sobre los datos están
realizadas por las funciones o subfunciones que
el programa debe de ejecutar
El flujo de datos entre 2 transformaciones
definen la inerface de cada función
− El contenido de la información , referida al
contenido de la información de cada elemento de
datos individuales. La agrupación de datos indi−
viduales componen otros elementos mayores de In−
formación
− La estructura de la información que representa
la organización lógica de los distintos elemen−
tos de datos
Es decir como debe organizarse los datos
para un mejor procesado
La Estructura de la Información no implica
la estructura de datos, que representa el
diseño e implementación de la estructura de
Información con el Software
2.− Partición
− Consiste en la subdivisión del problema con el fin de
hacerlo manejable intelectualmente, subdividiendo, ca−
da parte se hace más comprensible y todas las partes
juntas dan como resultado la función global.
− Tanto el dominio de la Información como el dominio funcional pueden ser particionados
− la partición en el dominio funcional lleva a una primera visión de los procesos (contienen las funciones) a
realizar (vision de alto nivel)
92
− La partición del dominio de la información en una pri−
mera fase viene dado por el flujo de la información y
y la temporabilidad
− Existen 2 aproximaciones para la partición una vez establecida una representación jerárquica bien de la
función o de la información:
a) Incrementando los detalles, moviendonos verti−
calmente en la jerarquía
b) Descomponiendo funcionalmente el problema,
moviendose horizontalmente en la jerarquía
3.− Visiones lógicas y físicas de los requerimientos
− La lógica representa tanto las funciones que han de
realizarse como la información que ha de procesarse
independientemente a los detalles de implementación
− La física presenta una manifestación del mundo real
de las funciones de procesamiento y las estructuras
información
Tareas_durante_el_análisis_de_requerimientos
1) Reconocimiento del problema
− Consiste en reconocer los elementos básicos del
sistema tal y como los ve el usuario
− Para ello se cuenta con:
− La Especificación del sistema (análisis del sis
tema)
− Plan de proyecto ( Planificación)
− Que nos permitirán conocer el contexto del sistema
así como el entorno usado para generar las estima−
ciones
93
− En esta tarea se estudia los procesos asociados
2) Evaluación y síntesis
− Esta tarea proporciona el enfoque para la resolución
global del problema
− En ella el ingeniero del software:
− Evalúa el flujo y estructura de la informa−
ción
− Refina al detalle las funciones
− Establece las características de las inter−
faces
− Descubre/ligaduras de diseño
− Delimita la información tanto de entrada co−
mo de salida
− Comienza a plantear diferentes soluciones
para el problema
3) Especificación
− Esta tarea sirve para especificar los requerimientos
del software desde una perspectiva del usuario
− Representa el producto a producir en la fase de ana−
lisis de requerimientos, e incluye los criterios de
de validación
4) Revisión
− Es la última tarea del análisis
− Es realizada por el cliente y el técnico
− Produce redefiniciones de los aspectos estudiados
− También se revisa el plan de proyecto para determinar
94
si las estimaciones siguen siendo validas después de
conocer en detalle que es el sistema
− Una vez que se ha completado la revisión se señalan
como terminadas tanto por el cliente como por el téc−
nico la Especificación de requerimientos de software.
La Especificación se convierte en un contrato para el
que se desarrolla el programa
Problemas_en_la_realización_del_análisis
− Los problemas que se plantean están determinados por las
caracteristicas de esta fase : la comunicación
− Los principales problemas son:
− Adquisición de la información, que se realiza en las 2
Primeras Tareas de la función del análisis de Requeri−
mientos.
Los problemas se centran en
− ¿que información debe recogerse y cómo de−
de representarse?
− ¿quien suministra las distintas partes de la
información
− ¿que herramientas y técnicas están dispòni−
bles para facilitar la recogida de informa−
ción?
− Manejo de la complejidad del problema
− El problema es un conjunto de partes interrelaciona−
das.
− La introducción de nuevos elementos, ligaduras, etc,
95
como influye, era uno de los aspectos que influían
en la estimación
− Los problemas se centran
− ¿cómo podemos eliminar la inconsistencia cuan−
do se especifican grandes sistemas?
− ¿es posible detectar las omisiones?
− ¿Puede un problema grande ser subdividido con
efectividad de forma que se haga mas manejable
intelectualmente
− Acomodación de los cambios, antes y después del
análisis. En todo sistema los cambios se producirán
− Los cambios aludidos son cambios de requerimientos
− Los problemas se centran
− ¿como se coordinan los cambios de otros
elementos del sistema con los requerimientos
del software?
− ¿como establecer el impacto de un cambio sobre
otras partes,aparentemente no relacionadas,del
software?
− Como corregir los errores en la especificación
de forma que no se agreguen efectos laterales?
− Existen muchas causas que producen los problemas descritos
anteriormente, entre otras:
1− Pobre Comunicación que hace difícil la Adquisición de
Información
2− técnicas y herramientas inadecuadas que producen
96
especificaciones inadecuadas o imprecisas
3− Tendencia a acortar el análisis de requerimientos,
conduciendo a un análisis inestable
4− Un fallo en considerar alternativas antes de la
Especificación del software
"A_quien"_y_"que"_facilita_el_análisis_de_requerimientos
A Quien Que
Ingeniero de sistema − Especificar función y rendimiento
− Interfaces otros elementos del
sistema
− Establecer las ligaduras de dise−
ño que debe cumplir el sistema
Ingeniero de Software − Redefinir la asignación del soft−
ware
− Representa el dominio de la infor
nación que será tratada
Al diseñador (I.S) − Representación de
− Información
− Funciones
− Que puede traducirse
− Estructura de datos
− Arquitectura del software
− Diseño procedimental
Técnico y cliente − Medios para valorar la calidad
del sistema una vez construido
(criterios válidos)
97
Caso_particular_del_análisis_de_requerimientos_:_construcción
de_prototipos
− Se aborda en general cuando
− No es factible realizar una especificación detallada de
los requerimientos por parte del usuario (No sabe lo
que quiere)
− El Ingeniero del software tiene dudas del usuario
− Pasos para la construcción de un prototipo:
PASO 1 Evaluar la Partición del software y determinar si
el programa a desarrollar es buen candidato para
construir un prototipo
− Las variables que intervienen:
− Área de aplicación
− Complejidad de la aplicación
− Caracteristicas del cliente
− Caracteristicas del proyecto
− Debido a que el cliente debe interaccionar con
el prototipo en los últimos pasos,es esencial:
− que el cliente participe en la evaluación y
refinamiento del prototipo
− el cliente sea capaz de tomar decisiones de
requerimientos de forma oportuna
PASO 2 Dado un proyecto candidato aceptable, el analista
desarrolla una representación abreviada de los
requerimientos
− Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar
98
− los dominios funcionales y de Información del programa
− Desarrollar un metodo razonable de Partición
PASO 3 Después de que se haya revisado la representación
de los requerimientos, se crea un conjunto de es−
pecificaciones de diseño abreviadas para el pro−
totipo
− El diseño se enfoca hacia
− la arquitectura
− los datos
− en vez de
− hacia el diseño procedimental detallado
PASO 4 El software del prototipo se crea,prueba y refina
− Usuario (C,R)
− constructor (C,P,R)
PASO 5 Una vez que el prototipo ha sido probado, se pre−
senta al cliente, el cual conduce la prueba de la
aplicación y sugiere modificaciones
− Este paso es el núcleo del método de construc−
cion del prototipo
− Es aquí donde el cliente
− Puede examinar una representación implementa−
da de los requerimientos del programa
− Puede sugerir modificaciones
PASO 6 Los pasos 4 y 5 se repiten iterativamente hasta
que todos los requerimientos están formalizados o
hasta que el prototipo haya evolucionado hacia un
99
sistema de producción
Un_paradigma_de_ingenieria_del_software_automatizada
___________________
| Recolección| |
| de requeri−|___\|/____________
| mientos | Representación| |
|_________| en lenguaje___|___\|/___________
/|\ | formal | Generación | |
| |____________| automática_|_____\|/_______/___
| | prototipo| Optimización |\ |
| |__________| y ____|__\|/___
| Verificación | | afinamiento| Software |
| y modificación | |____________| completo |
|_______________________| |___________|
Consideraciones_sobre_la_construcción_del_prototipo
− Cuando se construye un prototipo se realiza un Manual de
Usuario preliminar, siendo este un borrador del definitivo
con el fin de:
− Al analista: que asuma el punto de vista del
usuario del software
− Al cliente: revisar el Software desde una pers−
pectiva de ingeniería humana
− así mismo cuando se construye un prototipo existen 2 fina−
lidades:
A) Establecer un conjunto de requerimientos formales
para después ser traducidos para la producción de
100
programas, mediante el uso de técnicas y métodos
de ingeniería
B) A partir del prototipo como base, construir el
proyecto mediante un desarrollo evolutivo
− Así pues, la construcción de prototipos esta orientada, des
de una perspectiva de usuario, a conocer tanto cuales son
los requisitos del sistema como a evaluar como afectara al
trabajo la existencia del nuevo sistema
− Las ventajas de la utilización de prototipos durante la
fase de análisis de requerimientos son
− Los malentendidos entre usuarios y desarrolladores
pueden identificarse a medida que se muestran las
funciones del sistema
− Pueden identificarse los servicios que le falte al
usuario
− Se pueden identificar y medir los servicios del
usuario difíciles de utilizar o confusos
− Los desarrolladores pueden detectar requisitos
incompletos e inconvenientes
− Disponer con rapidez de un sistema de trabajo
− Puede servir como especificación para el desarrollo
de un sistema
− Finalidades
− Evolucion a sistemas de producción
− Derivación de requerimientos que implica desechar
el prototipo y reconstruir el sistema
101
− El problema se centra en el TANDEM
Desarrollo rápido y facilidad de mantenimiento, que ra−
ra vez son compatibles
− De hecho
− El desarrollo rápido es el propósito de los
desarrolladores del prototipo
− La facilidad del mantenimiento debe ser la finalidad
del desarrollo de sistemas de calidad de producción
− Por eso al menos para grandes Sistemas es mejor desarro−
llarlo, pues la estructura se degrada con rapidez a medida
que avanza el mantenimiento
− El coste del prototipo y coste de sistema
− Implica no utilizar las mismas herramientas y Stan−
dares del producto final
− Reducción confiabilidad y calidad pues es desechado
ESPECIFICACIÓN
− Especificación de los requerimientos del software consti−
tuye el producto final de la fase de análisis de los reque−
rimientos y es el documento base para la fase de diseño
− Dado que la especificación tiene mucha incidencia en la
calidad de la resolución elegida para el desarrollo del
software, la abordaremos definiendo sus:
− Principios
− propiedades
Principios de la Especificación
1.− Separación entre funcionalidad e implementación
102
. Se especifica que hay que hacer no "como" se realiza
2.− Necesidad de un lenguaje de Especificación del sistema
orientado al proceso
. Del "que" se obtiene la especificación de un modelo,
del comportamiento deseado en términos de respuestas
funcionales
3.− Una especificación debe abarcar el sistema del cual el
software es un componente
. Dado que un sistema esta formado por componentes que
iteractuan
. Solo dentro del sistema global y conocida la inter−
pretación entre sus partes, se puede definir el
comportamiento especifico de un componente
4.− Una especificación debe alcanzar el entorno en el ope−
ra
5.− Una especificación del sistema debe ser un modelo
cognitivo, en vez de un modelo de diseño o implemen−
tación
. Debe describir el sistema tal y como es visto por
los usuarios
. Los objetivos corresponden a objetivos reales del
dominio.
. Debe poderse incorporar a la especificación las re−
glas o leyes que gobiernan los objetivos del dominio,
que pueden limitar el comportamiento de los agen−
tes
103
6.− Una especificación debe ser operacional de tal manera
que pueda usarse para determinar si una implementa−
cion propuesta satisface la especificación de pruebas
elegidas arbitrariamente
7.− La especificación del sistema debe ser tolerante con
con la incompletitud y aumentable
. Debido a que la especificación es siempre un modelo
(abstracción) de la realidad, será incompleta.
8.− Una especificación debe ser localizada y debidamente
acoplada
− La especificación no es una entidad estática, se cambiara
con el tiempo
− Las modificaciones se presentan en tres etapas
− Formulación : en la fase de análisis de requerimien−
tos
− Desarrollo: cuando la Especificación se esta elavo−
rando en la fase iterativa de diseño e implementación
− Mantenimiento: Cuando se modifica la especificación
para reflejar un cambio en el entorno y/o requerimien
tos funcionales nuevos
Propiedades de la Especificación de los requisitos del soft−
ware
− Especificación de requisitos como una especificación que
establece los requisitos para un sistema
− Propiedades que debe cumplir el documento de especificación
de requisitos de software
104
− No ambiguo
− Completo
− Verificable
− Consistente
− modificable
− Rastreable
− Usable en fase de operación y mantenimiento
− La asociación española para el control de calidad en su
Glosario de términos de calidad del software define el
software:
Programas, procedimientos, reglas y la posible documen−
tación asociada y datos que pertenezcan a la explotación de
un sistema de ordenadores
− No ambiguo:
. Un ERS no es ambiguo si y solo si cada requisito enun−
ciado en la especificación tiene una única interpretación
. Por esto debe de darse estas dos condiciones
1) como mínimo, esto requiere que la característica
del producto final sea descrita usando un único termino
2) En los casos donde un termino es un contexto parti−
ticular, pueda tener múltiples significados, se debe
incluir el término en un glosario, el cual debe ser
completo
− Completo
. Un ERS es completo si posee las siguientes cualidades
1) Incluye todos los requisitos significativos
105
2) Define los requisitos del software para todos los da−
tos de entrada en todas las clases de situaciones posible
3) Es conforme al STANDARD ERS en que se basa
4) Define todos los términos, unidades de medida y hace
referencia a todas las figuras, tablas y diagramas
5) Cualquier ERS que use la frase se determinará no es
completo
. Sin embargo los se determinara son necesarios algunas
veces. cuando sea necesario utilizarlo ira acompañado por:
a) Una descripción de las condiciones que lo causan, de tal
manera que la situación pueda ser resuelta
b) Una descripción de que debe hacerse para eliminarlo
− Verificable
. Un ERS es verificable si y solo si cada requisito enuncia−
do en el ERS es verificable
. Un requisito es verificable si y solo si existe algún
proceso finito de coste razonable en el que una persona o
maquina pueda probar que el producto software cumple el
requisito
− Consistente
. Un ERS es consistente si y solo si ningún conjunto de requi
sitos individuales descritos en el ERS tiene conflictos
. Hay tres tipos de conflictos en un ERS:
1) Dos o mas requisitos pueden describir el mismo objeto
real, pero usar términos diferentes para ese objeto
2) Las caracteristicas especificas de los objetos del mundo
106
real pueden tener conflicto
3) Puede haber conflictos lógicos o temporales entre dos
acciones especificas
− Modificable
. Un ERS es modificable si su estructura y estilo son tales
que cualquier cambio que sea necesario realizar en los requi−
sitos puede ser realizado de una manera facil completa y con−
sistente
. Generalmente se dice que un ERS es modificable:
1) Su organización es facil de usar y es coherente
2) si no es redundante : es decir que el mismo requisito no
aparezca en más de un lugar el ERS
. La redundancia puede llevar a errores fácilmente
. La redundancia da problemas de actualización
− Rastreable
. Un ERS sera rastreable si el origen de cada requisito es
claro y se facilita la referencia de cada requisito para un
desarrollo futuro o mantenimiento de la documentación
. Un documento puede ser rastreable de dos maneras
1) hacia atrás
2) hacia adelante
− Usable en la fase de operación y mantenimiento
. El ERS debe de tener en cuenta las necesidades de la fase
de operación y de mantenimiento
. Esto implica dos acciones:
a) que el ERS sea modificable
107
b) que el ERS contenga un registro con las caracteristicas
de cada requisito
Preparación del documento
− Quien lo hace: conjuntamente entre los usuarios y el ana−
lista
− Con que objetivos: establecer un cuerdo entre el usuario y
analista sobre que debe hacer el software
− El proceso de desarrollo del software comienza con un acuer−
do entre cliente y suministrador que realiza el software.
− este acuerdo es en forma de un ERS y debe prepararse conjun−
tamente
Perfil del analista en esta fase
− cuando se habla de perfil del analista se abarcan dos aspec
tos:
− Trabajo a realizar
− Caracteristicas que debe tener
− referente a las caracteristicas que debe tener, son habili−
dades para:
− Comprender conceptos abstractos, reorganizalos en
divisiones lógicas y sintetizar soluciones basadas
en cada división
− entresacar hechos importantes de fuentes conflicti−
vas o confusas
− Comprender entornos de usuario/cliente
− Aplicar elementos Hardware y/o software a entornos
de usuarios/cliente
108
− Comunicarse bien en forma oral y escrita
− evitar que los arboles no nos dejen ver el bosque
Evolucion en la Especificación de los requerimientos del
software
− Problemas
. El ERS puede necesitar evolucionar, a la vez que el desa−
rrollo del producto software progresa, debido a dos puntos:
1) Puede ser imposible cuando se inicia el proyecto, espe−
cificar algunos detalles
2) Pueden surgir cambios como consecuencia de deficiencias
en los requisitos
− Consideraciones
a) Los requisitos se deberán especificar tan completamente
como sea posible
b) iniciar un proceso de cambio formal para identificar,
controlar, seguir la pista e informar de los cambios tan
pronto como sean inicialmente identificados
− Para que los cambios que se puedan realizar en el ERS se
deben:
− Proveer un control de cambios preciso y completo
− permitir la revisión de partes actuales reemplazadas
en el ERS
Estructura de una Especificación de requerimientos (ERS)
− Indice de contenidos
1. Introducción
1.1 Propósito
109
1.2 Alcance
1.3 Definiciones, axiomas, abreviaciones
1.4 Referencias
1.5 Vision general
− Estructura Introducción
. La introducción deberá dar una vision general del ERS entero
. El propósito debe contener lo siguiente:
− Delinear el propósito particular del ERS
− Especificar a quien va dirigido el ERS
. La subsección de alcance deberá
− Identificar el producto software con su nombre
− Explicar que hará y qué no hará el producto software
− Describir la aplicación del software que se este
especificando
. La subseccion de definiciones deberá proveer las
definiciones de todos los términos y abreviaciones que son
necesarios para interpretar el ERS
. La subsección de Referencias deberá:
− Prever una lista completa de los documentos referencia−
dos
− Identificar cada documento por el titulo, nº de informe,
fecha y editorial
− Especificar donde se puede obtener
. La subseccion de Vision general deberá
− Describir lo que contiene el resto del ERS
− Explicar como esta descrita la ERS
110
− Descripción general
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Caracteristicas del usuario
2.4 Restricciones generales
2.5 Suposiciones y dependencias
− Estructura de la Descripción general
. la subsección de Perspectiva del producto hace ver al
producto con relación a otro producto o proyectos
. La subsección de funciones del producto deberá contener las
funciones a nivel general que realizara el software.
− Estas funciones sera legibles al usuario, no a alguien
que lea este documento por primera vez
− Una herramienta de ayuda para esto será un diagrama en
bloques
. la subseccion de caracteristicas del usuario describirá
aquellas caracteristicas generales de los usuarios eventuales
del producto que afectará los requisitos específicos
. La subseccion de restricciones generales suministrará una
descripción general de cualquier otro elemento que limitara
las operaciones del desarrollador para diseñar el sistema
Pueden ser:
− Normas
− Limitaciones hardware
− Interface otras aplicaciones
111
− consideraciones de seguridad
− En la subsección de Suposiciones y Dependencias se indican
los factores que afectan a los requisitos enunciados en el
ERS.
− Estos factores no son restricciones de diseño en el
Software si no cualquier cambio en esos factores que
puedan afectar los requisitos del ERS
− Requisitos específicos
3. Requisitos específicos
Tema 6 −− DISEÑO DEL SOFTWARE
Fundamentos
* La fase de diseño es un proceso creativo que requiere del
diseñador ciertas cualidades
* Los conceptos del diseño se aprenden en libros; el diseño
(como actividad) no, es necesario practicar y aprender por
medio de la experiencia
* Un sistema de software bien diseñado es facil de aplicar y
mantener, y además es comprensible y fiable
* Hasta la aparición de la Ingenieria del Software el proble−
ma del diseño era de enfoque
a) A partir de unas especificaciones generalmente en lengua
je natural, se confeccionaba un "diseño informal" normal−
mente en forma de organigrama.
A partir de esto se empezaba a codificar y se
modificaba el diseño a medida que se aplicaba el siste−
ma. Al final, el diseño y el sistema no se correspon−
112
dían con lo que el diseño era inútil.
b) A partir de la ingeniería del Software se comprende que
las especificaciones de requerimientos es fundamental,
que las notaciones informales(organigramas,etc) son ina−
decuadas para formular el diseño por lo que se desarro−
llan diferentes notaciones formales.
Así dada una especificación de requisitos,
que el ingeniero del software usa para desarrollar el
diseño, en los siguientes pasos
− Deben establecerse los subsistemas que componen el
sistema
− Cada subsistema debe dividirse en componentes
individuales y ha de establecerse la especifica−
cion de los subsistemas definiendo la función de
esos componentes.
− Después cada programa se puede diseñar a base de
subcomponentes que interactuen.
− A continuación se debe refinar cada componente,
implicando cada componente como una jerarquía de
subcomponentes
− En algún momento del proceso de refinamiento se
debe especificar con detalle los algoritmos uti−
utilizados en cada componente.
La_fase_de_desarrollo_y_el_diseño_del_software
* La fase de desarrollo comprende tres etapas:
− Diseño
113
− Generación de Código
− Pruebas
* La primera (el diseño) es la mas importante y es sobre la
que descansa la "calidad" del producto software
* Notese en la figura, las entradas para el proceso de diseño
− Estructura de la Información (Dominio información)
− Función y rendimiento (Comportamiento funcional)
Así como las salidas del mismo que muestran que son un refina
miento de las entradas
* Independientemente de la metodología que use, el proceso de
diseño se centra en tres aspectos
− Diseño de datos: Se centra en la definición de la es−
estructura de datos (refinamiento de la estructura de
la información)
− Diseño arquitectónico: se centra en las relaciones en−
entre los principales elementos del Software (R. Parti−
ción)
− Diseño procidimental: se centra en la transformación de
los elementos estructurales en una descripción procedi−
mental del software.
* Veamos a continuación cada uno de estos aspectos
Diseño_de_datos
* Es la primera y mas importante de as tres actividades de
diseño.
* El diseño de datos se materializa en las estructuras de
datos por medio de refinamiento de la estructura de la
114
información
* Una actividad asociada a las estructuras de datos es la
identificación de los módulos del programa que usara las
estructuras de datos
* Las estructuras de datos son muy importantes, pues tienen
un enorme efecto sobre:
− La estructura del programa
− La complejidad procedimental
* Debido a esto, las estructuras de datos bien diseñadas
llevan a :
− Una mejor estructura del programa
− Una mas eficiente modularidad
− Disminución de la complejidad procedimental
* Dada la gran importancia de las estructuras de datos,
existen normas para la especificación y diseño de las
estructuras de datos. Dichos principios podrían ser:
1º Los métodos de análisis sistemáticos aplicados al
software deben también aplicarse a los datos
. De la misma forma que se determinan y revisan
las especificaciones del Análisis de requerimientos y
diseño del sistema, y se presentan soluciones alternati−
vas, lo mismo debe hacerse con las estructuras de datos
debido al gran impacto que tienen sobre el diseño sobre
el software
2º Deben identificarse todas las estructuras de datos y
operaciones que han de ejecutarse sobre cada una de
115
ellas.
. Una estructura eficiente de datos debe contemplar
todas las operaciones que han de ejecutarse sobre
cada una de ellas (tratamiento astracto de datos).
. Ello nos llevara a un mas eficiente diseño del
software
3º Debe establecerse y hacerse un diccionario de datos para
definir el diseño de los datos y el software
. El diccionario muestra de forma explícita las
relaciones entre los datos y las ligaduras (interdepen−
dencias) de los elementos de una estructura de datos.
4º La decisiones de diseño de los datos a bajo nivel deben
retrasarse hasta las ultimas etapas del proceso de
diseño.
. Aplicar un proceso de refinamiento sucesivo durante
las fases de
− Análisis de requerimientos
− Diseño preliminar |
> Descomposición diseño
− Diseño detallado |
. Este proceso de diseño descendente en los datos
proporciona las ventajas (análogas) del diseño descenden
te del Software
5º La representación de una estructura de datos debe ser
conocida solo por los módulos que hagan uso directo de
los datos contenidos dentro de la estructura.
116
. Se basa en los conceptos de
− Ocultación de los datos (Información)
− Acoplamiento
6º Debe desarrollarse una biblioteca de estructuras de
datos útiles y de las operaciones que pueden aplicarse a
ellas.
. Implica contemplar las estructuras de datos y las
operaciones y sus operaciones asociadas como un recurso
para el diseño del software.
. Se fundamenta en los Tratamientos abstractos de datos ,
que pueden reducir el trabajo de especificación y diseño
de las estructuras de datos
7º El diseño del software y el lenguaje de programación
deben soportar la especificación y realización del trata−
miento abstracto de datos
* Estos principios son la base para cualquier método de dise−
ño de datos
Diseño_arquitectónico
* Tiene como objetivo principal:
− Desarrollo de una estructura de programa modular
− Representar las relaciones de control entre los módulos
* Otros objetivos son:
− Asociar
− Estructura de programas
− Estructuras de datos
− Definir las interfaces que facilitan el flujo de los
117
datos a lo largo del programa
Diseño_procedimental
* Se efectúa después de establecer:
− Estructura del programa
− Estructura de los datos
* Se centra en definir los detalles algorítmicos sin ninguna
ambigüedad
* La Especificación procedimental debe realizarse de alguna
forma
* La primera (y peor) es el lenguaje natural (ambiguo), por
ello deben utilizarse formas mas restringidas.
* Entre ellas:
− Programacion estructurada
− Herramientas gráficas de diseño
− Diagramas de flujo (organigrama)
− Diagramas Nassi−Schneiderman (Chapin)
− Herramientas tabulares de diseño (tablas verdad)
− Lenguajes de diseño de programas (LOP./PSC.)
Se han visto cuales son los principios (de c. metodologia)
del diseño. Veamos ahora como se logran
Proceso_de_diseño
* Los principios vistos, representan aspectos técnicos de la
función del diseño
* Desde la perspectiva de gestión del proyecto (cuando hacer
cada cosa) el proceso de diseño se realiza en dos pasos:
− Diseño preliminar/externo.
118
. Implica:
− Concebir
− Planear
− Especificar las características de un producto
de programación.
− Definición de pantallas
− Formatos de informes
− Definición de entradas
− Definición de salidas
− Características funcionales
− Estructura general del producto
− Etc.
. Materializándose dichas características en la transfor
mación de los requerimientos en
− Estructuras de datos
− Arquitectura de Software
. Este paso del diseño se alimenta (comienza) del
análisis de los requerimientos y continua en este
paso, por eso es difícil deslindarlos.
. En la realidad lo que sucede es que la distinción en−
tre ambos (análisis de requerimientos y diseño prelimi−
nar) no es clara, sucediendo un cambio gradual de aten−
cion entre el "que" y el "como".
− Diseño de Detalle/Interno
. Implica
− Especificar la estructura interna
119
− Detalles de procesamiento
− Respetar las decisiones de diseño y documentarla
− Elaborar planes de prueba
− Suministrar una guia para la instrumentación de
− Pruebas
− Mantenimiento
* Este paso de diseño se orienta hacia los refinamientos de
la representación arquitectónica que conducen a una estruc−
tura de datos detallada y a la representación algorítmica
del software
* Así podemos decir que los productos de este paso son:
− Especificación de la estructura arquitectónica
− Detalles de los algoritmos
− Las estructuras de datos en detalle
− Los planes de pruebas
* Un buen diseño de software se logra mejor utilizando una
metodologia consistente de diseño.
* Hay muchas, siendo cada una de ellas adecuadas para diferen
tes tipos de aplicaciones (productos software)
* La mayoría se puede clasificar en las siguientes áreas:
− Diseño funcional descendente
. Consiste en diseñar el sistema desde un punto de vista
funcional
. Se parte de una vision de alto nivel hasta llegar al
diseño mas detallado
. Ha sido muy utilizada tanto para proyectos de pequeña
120
y gran escala en diferentes áreas de aplicaciones
− Diseño orientado al objeto
. Consiste en ver al sistema mas como una colección de
objetos que como funciones
. Se basa en la idea del "ocultamiento de la informa−
ción" Es un desarrollo relativamente reciente
− Diseño controlado por los datos
. Consistente en plantear que la estructura de un
sistema software debe reflejar la estructura de datos
que procesa, lo que implica que el diseño del software
se obtiene del análisis de los datos del sistema de
entrada y salida.
. Se ha usado fundamentalmente en sistemas pequeños,
aunque no esta circunscrito solamente a estos.
Fundamentos_del_diseño_del_software
* Las técnicas son la manifestación de los conceptos en su
aplicación a situaciones particulares
* Las técnicas son pasajeras, pero los principios funadmenta−
les permanecen y proporcionan las bases para el desarrollo y
evaluación de las técnicas.
* Para evaluar un diseño, se han establecido un conjunto de
conceptos fundamentales, que ayudan al ingeniero del software
a responder a las siguientes preguntas
. Que criterios pueden usarse para subdividir el software
en componentes individuales
. Como se separan los detalles de una función o estructura
121
de datos de una representación conceptual del software
. Existen criterios uniformes que definan la calidad técni
técnica de un diseño de programa
* M. Jackson: El comienzo del saber de un ingeniero del
software es reconocer la diferencia entre obtener un programa
que funcione y obtener uno que funcione "correctamente".
* Los fundamentos del diseño nos proporcionan:
− Como hacerlo
− Evaluarlo
* Los fundamentos del diseño son:
− Refinamiento
. El refinamiento (por pasos) es una técnica para
la descomposición de una Especificación (Función, in−
formación) definida a alto nivel hasta sus niveles
mas elementales.
. Es decir la Especificación describe (función, infor
mación) conceptualmente, pero no detalles
. El refinamiento va ampliando ( en cada paso o elabo
ración) los detalles
. El diseño funcional descendente utiliza el concepto
de refinamiento sucesivo.
. Fue propuesto por N. Wirth y es análogo al proceso
de refinamiento y Partición usado durante el análisis
de requerimientos.
− Arquitectura del Software
. Hace referencia a dos características fundamentales
122
de un programa:
− Estructura jerárquica de los componentes procedi−
mentales (módulos)
− Estructura de los datos
. Se deriva mediante un proceso de partición que aso−
cia a los elementos de una solución software con las
partes de un problema (del mundo real) definido impli−
citamente durante el análisis de los requerimientos.
. La solución se obtiene cuando cada parte del
problema se resuelve mediante uno o mas elementos
software. (un programa para calcular; otros progra−
mas para listar)
. Contingencia: un mismo problema ( para un conjunto
de requerimientos puede solucionarse mediante dife−
diferentes estructuras
. Según metodologia se obtienen diferentes estructu−
ras, porque cada una se basa en fundamentos distin−
tos.
− Estructura del programa
. Representa la organización normalmente jerárquica
de los componentes procedimentales del programa
(módulos) e implica una jerarquía de control
. No representa aspectos procedimentales del software
(secuencia, repetición, operaciones, etc.)
. Para representar una estructura existen muchas nota−
ciones
123
− Estructura de datos
. Es una representación de la relación lógica
entre elementos individuales de datos
. Dado que afecta al diseño procedimental es tan
importante como la estructura en la Representación
de la arquitectura
. La estructura de datos determina:
− Organización
− Métodos de acceso
− Alternativas de procesamiento para la infor
mación
Procedimientos_de_software
* Se centra sobre los detalles de procesamiento de cada módu−
lo individualmente.
* Los procedimientos del software deben proporcionar:
− Especificación precisa del procesamiento
− Secuencia de sucesos
− Puntos de decisión exactos
− Operaciones repetitivas
− Organización y estructura de datos
− Referencia a todos los módulos subordinados, dado que
existe una relación estructura y procedimiento
* La representación procedimental del software se realiza por
capas
Modularidad
* Existen muchas acepciones del concepto de modularidad.
124
* Van desde una subrutina hasta la asignación de trabajo para
un programador. Todas son correctas
* La modularidad consiste en subdividir el software en partes
denominadas módulos, cada uno con un propósito especifico,que
se integran para satisfacer los requerimientos de un problema
* La modularidad es el atributo mas sencillo del software,que
permite a un programa ser manejable intelectualmente
* Asimismo, la modularidad es un enfoque comunmente aceptado
tanto para análisis como para diseño.
* La modularidad proporciona:
− Calidad de diseño
− Facilidad de instrumentación
− Facilidad de depuración
− Facilidad de pruebas
− Facilidad de documentación
− Facilidad de mantenimiento
* Sea:
E −−−> Esfuerzo en coste
C −−−> Complejidad
C(P1) > C(P2) ======> E(P1) > E(P2)
C(P1 + P2) > C(P1) + C(P2)
||
\/
E(P1 + P2) > E(P1) + E(P2)
* Nos lleva
− Cuantos más módulos mejor ===> mayor sencillez
125
− Contingencia: interfaces entre módulos
− Problema: buscar M (nº de módulos) adecuado
Abstracción
* Es una herramienta intelectual que permite trabajar con con−
ceptos y términos que son familiares al entorno independiente
mente de los detalles de bajo nivel
* La abstracción es una medida inversa al refinamiento (dis−
curren parejos)
* De hecho cada fase de la ingeniería del software es un refi
namiento del nivel de abstracción del producto.
Ocultación_de_la_información
* Concepto asociado al de modularidad.
* Consiste en especificar y diseñar los módulos, de forma que
la información (procedimientos y datos) contenida por cada mó
dulo sea inaccesible a otros módulos que no la necesiten.
* Esto implica que el diseño modular debe realizarse de tal
manera que el conjunto de módulos (estructura) se comuniquen
unos con otros sólo por la información que necesiten para lo−
grar la función asignada.
La Ocultación de información como criterio de diseño favorece
− Evitar propagación de errores
− Modificaciones (prueba)
− Modificaciones (mantenimiento)
Diseño_modular_efectivo
* El enfoque modular sirve para:
− Deducir complejidad (no solo procedimental)
126
− Facilitar mantenimiento
− Facilitar la implementación
− Favorecer el paralelismo
* De hecho este enfoque es aceptado en todas las disciplinas
de ingeniería
* Así el diseño arquitectónico tiene como objetivo producir
sistemas modulares bien estructurados
* Un módulo puede ser visto como una entidad definida que tie
ne las siguientes características:
− Los módulos contienen:
− Instrucciones
− Lógica de proceso
− estructuras de datos
− Los módulos pueden ser compilados aparte y guardarse en
bibliotecas
− Los módulos pueden quedar incluidos dentro de un programa
− Los segmentos de un módulo pueden ser utilizados por la
invocación de un nombre con algunos parámetros
− Los módulos pueden usar otros módulos
* Para mejor comprender esto, es necesario conocer las carac−
terísticas operacionales de los módulos, derivados de los con
ceptos de:
− Abstrcción
− Ocultación de la información
* Estas características operacionales son:
− Historia del tiempo de incorporación.
127
. Referida al momento en que le módulo se incorpora al
software
− En compilación
− En ejecución
− Mecanismos de activación
Referido a módulos externos y a como son activados
− Call
− Interrupción
− Camino de control
Referido a la forma en la que el módulo se ejecuta inter−
namente
− Convencionales: un punto de entrada y uno de salida.
Secuencial
− Reentrante:(tareas concurrentes)
El módulo no puede modificarse asimismo
* Vistas las caracteristicas operacionales de los módulos,
veamos una categorización de los módulos en una estructura
software
− Secuencial:
Características:
− Los más comunes
− Se ejecutan sin interrupción
− Internos o externos
− Incremental/o corrutinas:
Características:
− Pueden ser interrumpidos
128
− Se restablecen en el punto de interrupción
− Mantienen puntero para su reinicio
− Utiles para sistemas conducidos por interrupcio−
nes
− Paralelos/o conrrutinas
Características:
− Se ejecutan simultáneamente con otros en entor−
nos de multiprocesadores concurrentes.
− Utiles para cálculos de alta velocidad que nece−
sitan dos o más C.P.U trabajando en paralelo.
* Los dos últimos requieren métodos de diseño especiales des−
de las primeras fases de desarrollo, por no poder aplicarse
una estructura típica de jerarquía de control.
* Una característica fundamental en un módulo, esta contenida
en el concepto de Independencia Funcional, que es una deriva−
ción de los conceptos de:
− Modularidad
− Abstracción
− Ocultamiento de la información
y que consiste en desarrollar módulos con una función clara,
es decir, que se enfoque a un requerimiento específico y que
tenga la menor interacción con otros módulos, es decir, que
la interface con los otros módulos (cuando deba existir) sea
lo más sencilla posible
* La independencia funcional de un módulo es muy importante
debido a:
129
− Facilidad de desarrollo. Su función puede ser compartida
con sencillas interfaces
− Facilidad de prueba
− Facilidad de mantenimiento
− Limitación de los efectos secundarios en la modificación
tanto de diseño como de código
− Reducción de la propagación de errores
− Reutilización de módulos
* Se puede decir que:
Independencia : clave de un buen diseño
Buen diseño: clave de la calidad del software
* La indepencia funcional se mide por dos criterios cualitati
vos:
− Cohesión:
− Es una extensión del concepto de ocultación de la in
formación.
− La cohesión interna de un modulo se mide en términos
de la fuerza de unión de los elementos dentro de un
módulo
− Un módulo coherente ejecuta una tarea sencilla(mejor
única) en un procedimiento software, requiriendo po−
ca interación (la menor) con procedimientos que se
ejecutan en otra parte del programa.
− La cohesión puede representarse en una banda que va
desde la mas baja a la más alta
− Siempre se busca la cohesión más alta
130
− Coincidental: los elementos dentro de un módulo no
tienen relación aparente entre ellos ( modulariza−
ción por segmentación)
− Lógica: los elementos están relacionados lógicamente
(módulo que ejecute todas E/S; Módulo general para
edición de datos)
− Temporal: están más altos que los anteriores debido
a que todas las funciones se realizan al mismo
tiempo ( módulo de inicialización de un programa o
sistema)
− Procedimental: Cuando los elementos de procesamiento
están relacionados y deben ejecutarse en un orden
específico (Stock: calculo B.M. y calculo reposición)
− De comunicación: Cuando los elementos de procesamien
to se centran sobre la misma estructura de datos.
(Display en pantalla e imprimir fichero)
− Secuencial: Cuando la salida de un elemento es la en
trada para el siguiente.(leer siguiente , actualizar
maestro) Normalmente tiene parecido con la estructu−
ra del problema.
− Funcional : cuando los elementos de procesamiento
están referidos al desempeño de una sóla función
(calcular el cubo, determinar si primo)
− Acoplamiento
− Es una medida cualitativa de la interconexión entre
los módulos en una estructura de programas.
131
− Un módulo busca siempre el menor acoplamiento
− El acoplamiento depende de:
− La complejidad de la interface
− El punto en el que se hace una entrada o referen
cia a un módulo
− Los datos que pasan a través de la interface.
− El acoplamiento puede representarse en una banda que
va desde la más baja a la más alta.
− Sin acoplamiento directo: cuando los módulos no tie−
nen conexión entre si. (Fig 6.13)
− Acoplamiento de datos:cuando la interfaz es sencilla
Se pasan datos simples con correspondencia de uno a
uno. (Fig.6.13)
− Por estampado: cuando la interfaz del módulo pasa
una parte de la estructura de datos en vez de datos
simples.
− De control: cuando la interfaz pasa datos de control
− Externo: cuando los módulos están ligados a un entor
no externo al software (E/S por medio de comunicacio
nes, dispositivos, formateos)
− Común: cuando varios módulos referencian una misma
área de datos comunes (Fig. 6.15)
− Por contenido: cuando un módulo modifica los valores
locales o las instrucciones de otro módulo.
Diseño_y_la_calidad_del_software
* La importancia del diseño es tal, que sin un buen diseño no
132
existe un buen sistema.
* El diseño es tan importante, que en el se basa la calidad
del desarrollo de un sistema, debido a:
− Es el único medio para trasladar con precisión los re−
querimientos del cliente en un producto o sistema acaba
do
− Proporciona las representaciones del software que pue−
den establecerse para conseguir un producto con calidad
− Sirve como base para el resto de los pasos del desarro−
llo (código,pruebas)
− Facilita el mantenimiento
− Permite las revisiones técnicas formales.
* En términos generales un diseño debe de mostrar entre otras
las siguientes características:
− Una organización jerárquica que haga un uso eficiente
del control entre los elementos del software.
− Debe ser modular. Cada módulo debe realizar funciones
específicas
− Un diseño debe contener una representación distinta y
separable entre datos y procedimientos
− Debe conducir a módulos que muestren las máximas carac−
terísticas de independencia funcional
− Debe derivarse mediante un método repetible que este
conducido por la información obtenida de la fase de aná
lisis de requerimientos.
Notaciones_de_diseño
133
* Hay muchas notaciones diferentes
* Cada una de ellas puede ser adecuada a diferentes niveles
de diseño o a áreas de aplicación.
* Las notaciones de diseño sirven para:
− Evaluar
− Comparar
− Probar
− Comunicar
* Algunas de estas características son:
− Diagramas de flujo de datos (D.F.D).
. Se utilizan para describir un diseño de sistemas de
alto nivel.
. Muestran como se transforman los datos al pasar de un
componente a otro del sistema.
− Diagramas de estructura (D.E.)
. Son gráficas de jerarquía que muestran la relación es
tructural de los componentes de un sistema software
. Son útiles para descubrir el diseño de alto nivel
− Lenguaje para la descripción del diseño
. Es una notación con algunos atributos de los lengua−
jes de programación
. Adecuado para describir operaciones de control y de
diseño detallado
* Estas tres notaciones son complementarias
Atributos_de_las_notaciones_de_diseño
− Modularidad: debe soportar el desarrollo de software modular
134
− Simplicidad global: tiene que ser facil de:
− Aprender
− Usar
− Leer
− Facilidad de edición: que la representación del diseño pueda
ser editado. Facilitara tanto su estudio/comprensión como
la modificación del diseño procedimental.
− Legible por la máquina
− Mantenimiento: cualquier mantenimiento siempre implica modi−
ficación de la representación del diseño procedimental.
− Exigencia de estructura: notaciones que hagan uso sólo de
construcciones estructuradas (programacion estructurada)
− Procesamiento automático
− Representación de los datos : facilidad para representar
datos locales y globales
− Verificación lógica: debe reforzar la facilidad para verifi
cación lógica
− Disposición para la codificación: que el diseño procedimen−
tal se convierta con facilidad en Código.
Lenguaje_de_diseño_de_programas
* Un lenguaje de diseño de programas también llamado inglés
estructurado o pseudocódigo, es un lenguaje misto que utiliza
el vocabulario de un lenguaje (español,ingles) y la sintaxis
general de otro (lenguaje programación estructurada)
* La diferencia con un lenguaje de programación estriba en el
uso de texto narrativo insertado directamente dentro de las
135
sentencias del lenguaje de diseño de programas
* Una sintaxis básica para un lenguaje de diseño de programas
debe incluir:
− Definición de subprograma
− Descripción de interfaces
− Declaración y tipificación de datos
− Técnicas para estructurar en bloques
− Construcciones de condición
− Construcciones repetitivas
− Construcciones de E/S
* Ademas debe tener las siguientes características:
− Una sintaxis fija de palabras clave que den todas las
construcciones estructuradas, declaraciones de datos,
y características de modularidad
− Una sintaxis libre en lenguaje natural que describa
las características de procesamiento
− Facilidades para la declaración de estructuras de da−
tos tanto sencillas como complejas
− Una definición de subprogramas y técnicas de llamada que soporten los distintos modos de descripción de
in−
terfaces
Tema 13 −− TÉCNICAS DE PRUEBA DEL SOFTWARE
* La prueba no puede asegurar que no hay fallos en el pro−
ducto software; solo puede demostrar que hay fallos en el.
* La prueba constituye el último elemento critico para la
garantía de la calidad.
* Representa el último repaso de las especificaciones del:
136
− Diseño
− Codificación
* Las pruebas son imprescindibles, debido a que el software
representa (en su conjunto de actividades − desarrollo y man−
tenimiento) el mayor coste de un sistema basado en computado−
ra
* Recordamos que en la distribución de esfuerzos, asignamos a
la prueba el 40% del coste de desarrollo. Para sistemas críti
cos puede representar hasta cinco veces más que el resto del
coste.
Fundamentos_de_la_prueba_del_software
* La prueba representa una contradicción en el trabajo del in
geniero del software.
* Hasta ahora, ha intentado construir un producto software
(definición/desarrollo), materializado en la generación de có
digo.
* Ahora tiene que "demostrar" su calidad, es decir, realizar
pruebas.
* La prueba intenta "derribar" el software producido, por lo
que puede ser vista como una actividad destructiva en vez de
constructiva.
Objetivos_de_la_prueba
* Es diseñar pruebas que de forma sistemática descubran dife−
rentes clases de errores con el menor esfuerzo y coste posi−
ble.
* Por lo que podemos decir:
137
− Es un proceso de ejecución de un programa para descubrir
errores
− Un buen caso de prueba es aquel que tiene una alta proba
bilidad de mostrar un error no descubierto hasta enton−
ces.
− Una prueba tiene éxito si descubre algún error.
* Esto lleva a cambiar uno de los conceptos mas erróneamente
extendidos, de que una prueba tiene éxito si no se detectan
errores.
* Las pruebas proporcionan otras ventajas, que son las si−
guientes:
− Si las funciones del software se corresponden a las espe
cificaciones
− Si se alcanzan los requerimientos de rendimiento
− Proporcionan una indicación de la fiabilidad
− Indice de la calidad del software como un todo
− Documentación exhaustiva de las pruebas realizadas
− Optimizan el mantenimiento
Flujo_de_información_de_la_prueba
* Hay dos clases de entrada:
− Configuración software (incluye para este paso)
− Especificación de requerimientos
− Especificación de diseño
− Configuración de prueba
− Plan de prueba (Q)
− Procedimiento de prueba (C)
138
− Casos de prueba
− Resultados esperados
* Cuando los resultados obtenidos no se corresponden con los
esperados implica errores y comienza el proceso de depura−
ción.
* En el paso de evaluación es donde se determina la calidad y
fiabilidad del software debido a:
− Existen errores serios implica modificaciones en reque−
rimientos, diseño, lo que implica fiabilidad y calidad
en duda y posteriores pruebas.
− Existe errores sencillos, lo que implica:
− Calidad y fiabilidad aceptables
− Pruebas inadecuadas
− No existen errores, lo que implica al menos la duda de
que no se han realizado las pruebas adecuadas y que los
errores (si existen) serán descubiertos por el usuario.
Diseño_de_los_casos_de_prueba
* En base a las características del producto o el área de
aplicación, el diseño de los casos de prueba puede requerir
tanto esfuerzo como el propio diseño del producto.
* Hay dos enfoques para probar el producto:
− Conociendo la función específica para la que Fue diseña
do el producto, se pueden llevar a cabo pruebas que de−
muestren que cada función es completamente operativa.
A este tipo de pruebas se las denomina de "Caja negra"
− Conociendo el funcionamiento del producto se pueden de−
139
sarrollar pruebas que aseguren que todos los componen−
tes encajan, es decir, que la operación interna se ajus
ta a las especificaciones y que todos los componentes
internos son comprobados de forma adecuada. A este tipo
de pruebas se la denomina de "Caja blanca".
* Veamos cada uno de estos tipos de prueba
Prueba_de_la_caja_blanca
* Se basa en el examen de los detalles procedimentales.
* Se comprueban los caminos lógicos con casos de prueba que
ejecutan conjuntos específicos de condiciones y/o bucles.
* Se puede examinar el programa en varios puntos para confir−
mar si el estado real coincide con el esperado
* Utiliza la estructura de control del diseño procedimental
para derivar los casos de prueba.
* Estos casos de prueba garantizan:
− Se ejercitan por lo menos una vez todos los caminos inde
pendientes de cada módulo
− Se ejecutan todas las decisiones lógicas en sus vertien−
tes verdadera y falsa.
− Se ejecutan todos los bucles en sus límites y con sus lí−
mites operacionales.
− Se usan las estructuras de datos internas para asegurar
su validez
* Parece claro pensar, que si se efectuasen pruebas de caja
blanca exhaustivas,nuestro software quedaría perfectamente pro
dado. El problema estriba en el nº de pruebas que habría que
140
realizar (recordemos "menor coste y esfuerzo")
Prueba_del_camino_básico
* Es una técnica de caja blanca
* Permite derivar una medida de complejidad lógica de un dise
ño procedural, y usar esta medida para definir el conjunto bá
sico de caminos de ejecución.
* Dado que las pruebas de caja blanca utilizan la estructura
de control del diseño procedimental, esta debe ser traducida
en una representación de flujo de control que nos permita de−
rivar los casos de prueba.
* Dicha notación se denomina grafo de flujo o grafo del pro−
grama.
* Cada nodo representa una o más sentencias procedimentales.
* Un nodo puede corresponder a una secuencia de cuadros de
proceso y a un rombo de decisión.
* Las aristas (flechas grafo) representan el flujo de control
* Una arista debe terminar en un nodo, aunque este no repre−
sente ninguna sentencia procedural (notación/vacias).
* Regiones son las áreas delimitadas por una arista y un nodo
* Cuando en el diseño procedural existen condiciones compues−
tas se crea un nodo para cada una de las condiciones,llamándo
se predicados
* Complejidad_ciclomática
* Es una medida del software que proporciona una medición
cuantitativa de la complejidad lógica de un programa.
* En el contexto del medio de prueba del camino básico,la com
141
plejidad ciclomática define el número de caminos independien−
tes del conjunto básico del programa.
* Camino independiente es cualquier camino del programa que
introduce por lo menos un nuevo conjunto de sentencias o una
nueva condición
* Proporciona por tanto el límite superior del nº de pruebas
que se deben realizar para asegurar que se ejecutan al menos
una vez cada sentencia del programa
* La complejidad ciclomática se obtiene de la siguiente forma:
− C.C. = Nº Regiones grafo
− C.C. = E − N + 2 E−−−−> aristas N−−−> nodo
− C.C. = N + 1 N−−−> nodos
* Derivación_de_los_casos_de_prueba
1.− Usando el diseño o el Código, dibujar el grafo de flujo
2.− Determinar la complejidad ciclomática del grafo de flujo
resultante
3.− Determinar un conjunto básico de caminos linielmente inde−
pendientes
4.− Confeccionar los casos de prueba que ejecutaran cada cami
no del conjunto del conjunto básico.
Prueba_de_bucles
* Es una técnica de caja blanca
* Se centra en la validez de las construcciones de bucles
* Existen cuatro clases diferentes de bucles:
− Simples (N−−> valor límite del bucle)
. Saltar el bucle
142
. Pasar una sola vez
. Pasar dos veces
. Pasar M veces (M<N) (M>2)
. Ejecutar N−1 , N , N+1
_________
|_______|
|
|<−−−−−−|
___\|/___ |
|_______| |
/\______|
\/
|
− Anidados
. Aplicando la técnica de los simples implicaría un nº
de pasos elevadísimo.
. Un enfoque puede ser:
. Empezar en el bucle más interior. Dejar el resto
el resto en sus valores mínimos
. Realizar las pruebas de los simples, manteniéndo
los exteriores con sus valores mínimos.
Añadir otras pruebas para valores fuera de ran
go o excluidos
. Avanzar hacia afuera manteniendo los externos en
los valores mínimos y los internos en los comunes
. Continuar hasta probar todos los bucles
143
|
___\|/___
|_______|
|/______________
____|\___ |
|_______| |
|/_________ |
____|\___ | |
|_______| | |
/\_________| |
\/ |
____|____ |
|_______| |
/\______________|
\/
|
\|/
− Concatenados
. Si los bucles son independientes aplicar técnicas
simples
. Si los bucles son dependientes, aplicar técnica de
anidados
_________
|_______|
|/________
____|\___ |
144
|_______| |
/\________|
\/
____|____
|_______|
|/________ |/_______
____|\___ | ____|\___ |
|_______| | |_______| |
/\________| |/______|____
\/ |\ | |
______/ \ | |
− No estructurados | \ / | |
| |/_____ | |
. Rediseñar __________________\ | |\ | | |
/ | / \____|_| |
|\/||
| ____|____ | |
|−>|_______| | |
|||
/ \____| |
\/|
||
/ \__________|
\/
Prueba_de_la_caja_negra
* Referida a las pruebas que se realizan sobre la interface
145
del software
* Pretende demostrar:
− Que las funciones software son operativas
− Que la entrada se realiza adecuadamente
− Que la salida es la correcta
− Que la integridad de la información externa se mantiene
* Los métodos de prueba de este tipo, se enfocan hacia los
requerimientos funcionales del software, es decir, se derivan
conjuntos de condiciones de entrada que ejecutan todos los re
querimientos funcionales de un programa
* Los errores que intentan detectar este tipo de pruebas son:
− Funciones incorrectas o ausentes
− Errores de interface
− Errores en estructuras de datos o en accesos a bases de
datos externas
− Errores de rendimiento
− Errores de inicialización y determinación
* Las técnicas de prueba de caja negra tratan de derivar un
conjunto de pruebas que satisfagan los siguientes criterios:
− Casos de prueba que reducen, en un coeficiente menor que
1, el número de casos que se deben diseñar para alcanzar
una prueba razonable
− Casos de prueba que indiquen la ausencia o presencia de
clases de errores en vez de errores específicos asociados
a una prueba particular
* Existen diversos métodos de prueba fundamentados sobre la
146
caja negra. Algunos de ellos son:
Partición_equivalente
* Consiste en dividir el dominio de la entrada de un programa
en clases de datos de los que se pueden derivar casos de prue
bas
* Es decir define clases de errores, reduciendo de esta forma
el nº total de casos de prueba que hay que desarrollar
* La Partición equivalente se basa en la evaluación de clases
de equivalencia, siendo esta el conjunto de estados validos o
inválidos para condiciones de entrada(rango,valor numérico,es
pecífico,booleana etc.)
* Las clases de equivalencia se pueden definir:
− Si una condición de entrada especifica un rango, se de−
fine una clase de equivalencia válida y dos inválidas
− Si una condición de entrada requiere valor específico,
definir una clase equivalencia valida y dos invalidas
− Si una condición de entrada especifica un miembro de un
conjunto, definir una clase equivalencia válida y otra
inválida
− Si una condición de entrada es booleana, definir una
clase equivalencia válida y otra invalida
* La aplicación de estas normas para la Derivación de las cla
ses de equivalencias, permiten desarrollar y ejecutar casos
de prueba para cada elemento de datos del dominio de entrada.
Análisis_de_valores_límite
* Los errores tienden a darse más en los límites del dominio
147
de entrada que en el centro.
* La técnica de prueba de análisis de valores límite deriva
casos de prueba para ejercitar estos valores límite.
* Se enfoca sobre:
− Dominio de entrada
− Dominio de salida
* Es una prueba complementaria a la de partición equivalente
* Las directrices para esta prueba son:
− Si C.E. especifica un rango limitado por valores "A" y
"B" se deben diseñar casos de prueba : "A", "B", "A−1",
"A+1", "B−1", "B+1" (por debajo y por encima)
− Si el C.E. especifica un nº de valores, implica desarro
llar casos de prueba que:
− Ejecuten valores máximos y mínimos
− Ejecuten valores justo por debajo y por encima
del máximo y mínimo
− Aplicar las anteriores al dominio de salida
− Si estructuras de datos tienen límites (ej. tabla 100
elementos) implica diseñar casos de prueba que ejerci−
ten la estructura en sus limites.
Tema 14 −− ESTRATEGIAS DE PRUEBA DE SOFTWARE
* En el capítulo precedente se vieron dos métodos de pruebas
con algunas de sus técnicas asociadas.
* Hemos visto como se derivan casos de pruebas para detectar
cierto tipo de errores. Pero el producto software que estamos
construyendo, en la fase de pruebas requiere gran formalidad
148
para asegurar la calidad y fiabilidad del mismo. Esto lo pro−
porciona la estrategia.
* Una estrategia de prueba del software integra las técnicas
de diseño de casos de prueba en una serie de pasos bien pla−
nificados que llevan a una construcción correcta del softwa−
re.
* Una estrategia de prueba del software proporciona al
− Programador
− A la organización
− Control de calidad
− Cliente
Un plan que describe:
− Pasos a realizar como parte de la prueba
− Cuando se deben planificar
− Cuando se deben realizar
− Cuanto esfuerzo, tiempo, y recursos serán requeridos
* Ello implica que toda estrategia debe llevar:
− Planificación de la prueba (Pl y Pr)
− Diseño de casos de prueba
− Ejecución de las pruebas
− Evaluación de resultados
* Por último decir que la estrategia debe acomodar dos térmi−
nos contrapuestos:
. Flexibilidad : que permita la creatividad y adaptabili−
dad necesarias para adecuar las pruebas a todos los gran−
des sistemas basados en software.
149
. Rigidez: que permita un razonable seguimiento de la pla−
nificación y la gestión a medida que progresa el proyecto.
Un_enfoque_estratégico_de_la_prueba_del_software
* Como hemos visto la prueba comprende un conjunto de activi−
dades que se pueden planificar por adelantado y llevar a cabo
sistemáticamente.
* Existen diferentes enfoques estratégicos, y todos muestran
una serie de características generales:
− La prueba comienza a nivel de módulo y avanza hacia el
exterior hasta conseguir la integración del sistema com−
pleto.
− En diferentes puntos son adecuadas diferentes técnicas
de prueba.
− La prueba la realiza el desarrollador y/o un grupo inde−
pendiente de prueba.
− La prueba y la depuración son actividades diferentes,pe−
ro esta puede formar parte de cualquier estrategia de
prueba.
* Una estrategia debe ser:
− Una guía para el profesional
− Un conjunto de referencias para el ejecutivo.
− Debe permitir medir el progreso.
Organización_de_la_prueba_del_software
* Este enunciado esta referido a quien prueba el software.
* Recordemos que el paso de prueba es destructivo, en contra−
posición con el resto de pasos de la ingeniería del software,
150
que son constructivos.
* Se plantea una contradicción. A una persona se le encarga
un trabajo, que realiza con gran esfuerzo, y cuando lo ha
construido, se le pide que lo "tire".
* Por una parte, nadie mejor que el conoce el producto
* Por otra parte, tendrá la suficiente "independencia" (eva−
luación) a la hora de derivar pruebas para probar "eficiente−
mente" el software.
* También por otra parte, no podría suceder (dado que el es
quien mejor conoce el producto) que derivase casos de prueba
para aquello que el conoce perfectamente,pero es lo esperado?
* Por tanto la cuestión es:
¿ Quien debe realizar las pruebas ?
* Después de lo dicho podría deducirse:
− El desarrollador no debe realizar el proceso de prueba
− El software salvaguardado de extraños que puedan probar−
lo exhaustivamente.
− La prueba la realiza gente externa al equipo de trabajo
y sólo aparecen durante la fase de prueba.
* Cualquiera de esas premisas es falsa. El mejor enfoque es
el mixto.
* Por un lado están los desarrolladores que realizan las prue
bas de unidad y comunmente las de integración
* Una vez que la arquitectura del software está completa
(probada), entra en juego el grupo independiente de prueba
(G.I.P.) que realiza las pruebas de validación y del sistema.
151
* Así pues el objetivo ( desde la perspectiva humana) del
Grupo independiente de prueba es eliminar el conflicto de in−
tereses que se da en la prueba, es decir, que el constructor
pruebe lo que ha construido.
* El grupo independiente de prueba forma parte del equipo de
trabajo, pues desde el análisis de requerimientos (criterios
de validación) ya realiza el trabajo de plan y procedimientos
de prueba.
* El hecho de que forme parte del equipo (paralelismo) no im−
plica que pertenezca a la parte de la organización del desa−
rrollo del software.
* Normalmente es independiente de esta, lo que proporciona la
independencia que necesita.
* El grupo independiente de prueba, aunque es el encargado de
conducirla, mantiene un estrecho contacto con los desarrollado
res, tanto para la consulta como para la corrección de erro−
res (depuración). La corrección corre a cargo de los desarro−
lladores ( organización matricial ).
Una_estrategia_de_prueba_del_software
* Una estrategia de prueba de software, puede ser vista como
un proceso inverso a la construcción de un sistema.
* Prueba de unidad: Se enfoca sobre cada una de las unidades
del software tal y como están implementadas en código fuente.
* Prueba de integración: Se enfoca sobre el diseño, es decir,
la construcción de la arquitectura del software
* Prueba de validación: se enfoca sobre la validación de los
152
requerimientos especificados en el E.R.S., comparándolos con
el sistema construido.
* Pruebas del sistema: se enfoca en probar el software y otros
elementos como un todo.
* Desde un punto de vista del procedimiento, la prueba, en el
contexto de la ingeniería del software puede ser vista como
una serie de cuatro pasos que se realizan secuencialmente.
− Prueba de unidad, que implica:
− Prueba de módulos
− Desarrollo Procedimental
− Caja blanca
− Prueba de integración, que implica:
− Prueba integración módulos
− Desarrollo Arquitectónico
− Caja blanca/caja negra
− Prueba de validación, que implica:
− Prueba sistema software
− Arquitectura sistema
− Caja negra
− Prueba del sistema, que implica:
− Fuera alcance
− Ingenieria sistemas
− Funcionalidad y rendimiento del sistema total
Pruebas_de_unidad
1. Características
* Se centra en la verificación de la menor unidad del diseño,
153
el módulo.
* Usa la descripción del diseño procedimental como guía.
* La complejidad relativa de las pruebas y errores esta limi−
tada por el alcance establecido para la prueba.
* Admite el paralelismo con otros módulos
* Siempre usa técnicas de caja blanca.
* Los casos que se derivan durante la prueba son orientados
a:
. Interface del módulo. Se prueba para asegurar que la
información fluye correctamente hacia y desde la unidad
de prueba.
Es la primera que hay que realizar, pues si falla
la interface el resto fallará.
1º ¿Es igual el número de parámetros de entrada al núme−
ro de argumentos?
2º ¿Coinciden los atributos de los parámetros y los argu
mentos?
3º ¿Coinciden los sistemas de unidades de los parámetros
y de los argumentos?
4º ¿Es igual el número de argumentos transmitidos a los
módulos de llamada que el número de los parámetros?
5º ¿Son iguales los atributos de los argumentos transmi−
tidos a los módulos de llamada y los atributos de los
parámetros?
6º ¿Son iguales los sistemas de unidades de los argumen−
tos transmitidos a los módulos de llamada y de los pa
154
rámetros?
7º ¿Son correctos el número, los atributos y el orden de
los argumentos de las funciones incorporadas?
8º ¿Existen referencias a parámetros que no estén asocia
dos con el punto de entrada actual?
9º ¿Entran sólo argumentos alterados?
10º ¿Son consistentes las definiciones de variables globa
les entre módulos?
11º ¿Se pasan las restricciones como argumentos?
Cuando un módulo leve a cabo E/S externa, se deben
llevar a cabo pruebas de interfaz adicionales. De nuevo
de Myers:
1º ¿Son correctos los atributos de los archivos?
2º ¿Son correctas las sentencias de apertura?
3º ¿Cuadran las especificaciones de formato con las sen
tencias de E/S?
4º ¿Cuadran el tamaño del buffer con el tamaño del re−
gistro?
5º ¿Se abren los archivos antes usados?
6º ¿Se tienen en cuenta las condiciones de fin−de−archi
vo?
7º ¿Se manejan los errores de E/S?
8º ¿Hay algún error textual en la información de salida
Las estructuras de datos locales de cada módulo son
una fuente potencial de errores: Se deben diseñar casos
de prueba para descubrir errores de las siguientes ca−
155
tegorías:
1º Tipificación impropia o inconsistente
2º Iniciación o valores implícitos erróneos
3º Nombres de variables incorrectos(mal escri−
tos o truncados)
4º Tipos de datos inconsistentes
5º Excepciones de desbordamiento por arriba o
por debajo, o de direccionamiento.
. Estructuras de datos locales. Para asegurar que los da
tos mantenidos temporalmente conservan su integridad duran
te todos los pasos de ejecución del algoritmo.
Además también debe probar el impacto de los datos
globales sobre el módulo.
. Condiciones límite. Para asegurar que el módulo funcio
na correctamente en los límites establecidos como res−
tricciones de procesamiento.
. Caminos independientes. (caminos básicos de la estruc−
tura de control) Para asegurar que todas las instruccio−
nes del módulo se ejecutan al menos una vez.
Es fundamental este tipo de pruebas y está dirigi−
do a detectar errores debido a incorrección en:
− Cálculos
− Comparaciones
− Flujos de control.
. Caminos de manejos de errores. Enfocados a verificar
la terminación "limpia" cuando se detecta un error (Si
156
existe C.M.E).
2. Procedimientos de prueba de unidad
* Una vez generado el Código a partir del diseño procedi−
mental, es revisado y verificado en su sintaxis. El paso
siguiente es la prueba.
* Las directrices para la prueba la proporciona la infor−
mación del diseño procedimental, permitiendo derivar los
casos de prueba que con mayor probabilidad descubrirán
errores de los tipos a los que esta orientada la prueba de
unidad.
* Cada caso de prueba debe tener especificados los resulta−
dos esperados.
* La prueba de unidad se centra sobre los módulos, y dado
que estos no son programas independientes, es necesario de−
sarrollar un software especial denominado "conductor" y/o
resguardo.
* Las funciones de estos elementos software son:
− Conductor: Hace de programa principal cuya misión es:
− Aceptar los casos de prueba
− Pasarlos al módulo que se prueba
− Imprimir los resultados que sean relevantes
− Resguardo: su misión es:
− Sustituir a un módulo subordinado
− Usar su interface (del subordinado)
− Realizar la mínima manipulación sobre los datos (no
se está probando).
157
− Imprimir una verificación de la entrada y devuelve
el control.
* Ambos, conductores y resguardos, constituyen software adi−
cional, y por tanto no se adjunta al software final, asimismo
su escritura no requiere considerar aspectos formales.
* A veces, algún módulo no es posible probarlo de forma sim−
ple, con lo que se pospone su prueba hasta la realización de
la de integración.
* Para simplificar el trabajo, se deben mantener tanto los
conductores como los resguardos lo más simple posible, y esto
es favorecido ( grandemente) si los módulos fueron diseñados
con un alto grado de cohesión.
Pruebas_de_integración
* Representan el segundo paso en la fase de prueba.
* Se realiza, debido a que no es suficiente con las pruebas
de unidad. Es necesario ensamblar los distintos componentes
de la estructura.
* La Prueba de integración es una técnica sistemática para
construir la estructura de un programa al mismo tiempo que
se realizan pruebas para detectar errores asociados con la
interface.
* El objetivo es coger los módulos probados en la prueba de
unidad y construir una estructura de programa que coincida
con lo dictado en el diseño.
1. Enfoques para la prueba de integración
* Integración no incremental(BIG−BANG): consistente en la
158
construcción de la estructura de una sóla vez, es decir,
combinando todos los módulos de una sóla vez
. Es un enfoque poco operativo debido a que se tiende al
caos por:
− Se encuentran gran número de errores
− La corrección se hace difícil porque es difícil ais−
lar la causa de los errores con todo el programa en
prueba.
− Una vez corregidos los errores, aparecen otros y así
sucesivamente en lo que asemeja un ciclo sin fin.
* Integración incremental: es todo lo contrario a la no in−
cremental.
. Este enfoque es adecuado debido a:
− La estructura se construye y prueba mediante peque−
ños segmentos.
− En ellos los errores son más fáciles de aislar
− Facilita la prueba completa de las interfaces
− Permite la sistematización de la prueba.
. La integración incremental, admite diferentes estrate−
gias:
− Integración descendente
. Consiste en construir la estructura del programa
integrando módulos, moviendose hacia abajo por la
jerarquía de control, comenzando con el módulo de
control principal.
. Los módulos subordinados se van incorporando en
159
la estructura bien en profundidad o bien en anchura
. El proceso de integración descendente, consta de
5 pasos:
− Se usa el módulo de control principal como con−
ductor de la prueba, sustituyendo por reguardos
todos los módulos subordinados
− En base a la integración escogida (anchura−pro−
fundidad) se van sustituyendo los resguardos
por los módulos reales
− Se efectúan pruebas cada vez que se integra un
módulo
− Después de realizar cada conjunto de pruebas,
se reemplaza un resguardo por el módulo real
− Se realiza la prueba de regresión (todas o
algunas de las pruebas ya realizadas) para ase−
gurar que no se han introducido nuevos errores.
. Se repite el proceso desde el paso segundo, hasta
que se haya construido toda la estructura del pro−
grama.
. La integración descendente permite verificar los
puntos de decisión o de control principales antes
en al proceso de prueba.
. Lo que facilita el detectar los errores de con−
trol que son fundamentales.
. Así mismo si la integración es en profundidad,nos
permite ir implementando y demostrando las funcio−
160
nes completas del software (A,B,M)
. Este tipo de integración, puede presentar en la
práctica problemas. El más frecuente se da cuando
se necesitan procesamientos de los niveles más
bajos para probar los superiores
. Existen 3 tipos de opciones:
− Retrasar las pruebas hasta que los resguardos
sean reemplazados por módulos reales.Las conse−
cuencias son:
− Se pierde control sobre tipos de pruebas
− Mayor dificultad en detectar las causas de
de los errores.
− Se pierde la formalidad de la aproximación
descendente.
− Desarrollar resguardos que realicen funciones
limitadas que simulen el comportamiento de los
módulos reales
Las consecuencias son:
− Mayor esfuerzo en crear software para
pruebas
− Integrar el software desde abajo, que represen−
ta la otra estrategia de integración
− Integración ascendente
. Consiste en construir la estructura del software
partiendo(y probando) de los módulos más bajos.
. Esta estrategia puede ser acometida en cuatro pasos
161
− Se combinan los módulos de bajo nivel en grupos
(construcciones) que realicen una subfunción
del software.
− Se implementa (no formal) un conductor (que es
un programa de control de prueba) para contro−
lar la E/S de los casos de prueba.
− Se prueba el grupo (construcciones)
− Se elimina los conductores, combinando los gru−
pos y moviendose hacia arriba por la estructura
del programa.
2.− Ventajas e inconvenientes de las estrategias
* Normalmente, las ventajas de una representan inconvenientes
de otra.
* Descendente:
. Ventajas:
− Prueba antes los módulos de control
− Permite demostrar funciones completas del
software(A,B,M)
. Desventajas
− Necesidad de resguardos
− Problemas asociados al procesamiento de módulos
bajos
* Ascendente:
. Ventajas:
− No necesita resguardos
− Cuanto más progresa la prueba, se necesitan menos
162
conductores
− Más facilidad para diseño de casos de prueba.
. Desventajas:
− Necesita conductores
− El programa como unidad no existe hasta la
integración del último módulo.
* A la hora de realizar la prueba, la estrategia a escoger
dependerá de las características del software.
* Normalmente se puede escoger una estrategia combinada, de−
nominada prueba sandwich, que consiste en aplicar la estrate−
gia descendente para los niveles superiores (control) y la
ascendente para los niveles inferiores (procesamiento).
* Independientemente de la estrategia escogida, el encargado
de la prueba debe identificar los módulos críticos del pro−
grama, que se caracterizan por lo siguiente:
− Dirigido a varios requerimientos del Software
− Tiene un mayor nivel de control
− Es complejo o propenso a errores
− Tiene requerimientos de rendimiento muy definidos
3.− Criterios para las pruebas de integración
* Constituyen criterios a probar con la correspondiente
documentación
− Integridad de la interface: consiste en probar cada in−
terface interna y externa a medida que se incorpora
cada módulo o grupo a la estructura
− Validez funcional: consiste en realizar pruebas
163
diseñadas para descubrir errores funcionales
− Seguridad de la información: consiste en realizar
pruebas diseñadas para descubrir errores asociados con
las estructuras de datos globales y locales
− Rendimiento: consiste en realizar pruebas diseñadas
para verificar los límites de rendimiento fijados
durante el diseño del software
Pruebas_de_validación
* Constituye el tercer paso de prueba desde el punto de vista
del procedimiento
* Constituye el conjunto de pruebas a realizar para determi−
nar si el software funciona de acuerdo a las espectativas ra−
zonables del cliente.
* Antes de comenzar la prueba de validación, el software está
ensamblado como un paquete y ya se han encontrado y corregido
los errores.
* Esta prueba persigue confirmar que todos los componentes
del software juntos producen la función y el rendimiento de−
seado.
* La pregunta a esto es ¿ quien determina que se ha logrado
el objetivo?
* La repuesta es la especificación de los requerimientos del
software, que describe todos los atributos del software que
son visibles al usuario (F,R).
1.− Criterios para la prueba de validación
* La validación se consigue mediante pruebas de caja negra.
164
* El paso de prueba de validación esta alimentado por:
− Plan de pruebas: que define las pruebas que se van a rea
lizar
− Procedimiento de prueba: que define los casos de prueba
específicos que serán usados para confirmar la confor−
midad con los requerimientos.
− Software integrado
− E.R.S.
− Documentación del usuario.
* El plan y procedimiento de prueba se ha diseñado para demos
trar que:
− Se satisfacen los requerimientos funcionales
− Se satisfacen los requerimientos de rendimientos
− Se satisfacen los otros requerimientos (portabilidad,
recuperación de errores, mantenimiento, etc.)
− Que la documentación es correcta
* Una vez que se ha ejecutado cada caso de prueba, los re−
sultados admiten dos conclusiones:
− Las características de funcionamiento y/o rendimiento
coinciden con las especificaciones y por tanto es co−
rrecto
− Se detectan desviaciones de las especificaciones, crean−
do una lista de las diferencias, lo que implica a estas
alturas renegociar.
* Otra actividad que se tiene que finalizar con la prueba de
validación la constituye el Repaso de la configuración del
165
Software, consistente en asegurar que todos los elementos de
la configuración del software se han desarrollado adecuada−
mente, están registrados, y tienen suficiente nivel de deta−
lle para facilitar el mantenimiento
Pruebas_alfa_y_beta
* Es muy difícil Prever como un usuario final usará el soft−
ware construido. También es difícil Prever como responderá
frente al sistema
* Debido a esto, se realizan una serie de pruebas, denomina−
das de aceptación, que permiten al cliente validar todos los
requerimientos.
* Estas pruebas las realiza el usuario final en vez del
equipo de desarrollo.
* Estas pueden ser "informales" hasta "bien planificadas"
(pueden durar semanas o meses) (paralelismo de sistemas)
* Estas pruebas son:
− Alfa:
. La realiza el cliente en el lugar de desarrollo
. Consiste en usar el software de forma natural, con el
desarrollador controlando dicho proceso para:
− Registro de errores
− Problemática de uso
. Es por lo que se dice que se desarrollan en un entorno
controlado.
− Beta:
. Se realizan en uno o mas lugares del cliente por los
166
usuarios finales.
. El desarrollador no está presente
. La prueba es en vivo
. El entorno no es controlado por el equipo de desarro−
llo.
. El cliente es el que registra todos los problemas (rea
les originados)
. Informa a intervalos Regulares al equipo de desarrollo
Pruebas_de_sistema
* Hasta ahora se ha probado el software que es un componente
de un sistema.
* Consiste en una serie de pruebas de integración y valida−
ción del sistema "global".
Proceso_de_depuración
* Surge como consecuencia de una prueba efectiva, aunque no
es una tarea de prueba consiste en eliminar los errores pro−
ducidos por la ejecución de los casos de prueba, y se obtie−
nen resultados que difieren de los esperados.
* Muchas veces el error es un síntoma de una causa que está
oculta (truncado).
* El proceso de depuración trata de establecer la correspon−
dencia del síntoma con la causa.
* El proceso de depuración siempre tiene uno o dos resultados
− Se encuentra la causa, se corrige y se elimina
− No se encuentra la causa. Se debe sospechar.Diseñar caso
de prueba que ayude a confirmar. Así sucesivamente hasta
167
que se encuentre (proceso de rastreo de la causa del
error).
* El proceso de depuración es difícil porque intervienen facto−
res psicológicos:
− Se ha cometido un error
− Presión de tiempo
− Evaluación
− Habilidad personal
− etc.
* También tiene influencia las características de nuestro
producto (lógico) y en particular con el diseño.
* Algunas características de los errores nos facilitan algu−
nas orientaciones:
− El síntoma y la causa pueden ser remotos entre si (aco−
plamiento)
− El síntoma puede estar producido por algo que no es
error (redondeos)
− Puede ser difícil reproducir las condiciones de entrada
(S.T.R)
− El síntoma puede desaparecer (temporalmente) al corregir
otro error
− etc.
Enfoques_de_la_depuración
* Existen diversos enfoques para el proceso de depuración.
− Fuerza bruta: probablemente el más común y menos efecti
vo.
168
. Consiste en dejar que el ordenador encuentre error
(volcados,write,etc)
. Se espera que en toda información facilitada se encuen
tre o bien el error, o bien algún indicio.
. Se debe aplicar cuando el resto falla
− Vuelta atrás: representa un enfoque efectivo, con gran
éxito en programas pequeños.
. Partiendo del lugar en el que se detecta el síntoma se
recorre hacia atrás el código hasta que se identifica el
error.
. Si el programa es demasiado grande el número de cami−
nos se hace "menos manejable".
LA DOCUMENTACIÓN DEL PRODUCTO
* La documentación así como el mantenimiento son partes tediosas en la construcción de un sistema, pero
esenciales tanto para la producción como para el uso de los mismos.
* De nada vale construir un sistema de software si:
− No se puede comprender
− Solo lo saben utilizar los realizadores
− Si es difícil o imposible de mantener
* Un sistema no se puede mantener, si no existe documentación
* La documentación sirve para muchos propósitos:
− Describir la manera de uso de un programa
− La razón por la que se escribió
− Las técnicas utilizadas en su construcción
* A pesar de ello, suele ser ignorada, y en grandes sistemas puede requerir tanto esfuerzo como el propio
desarrollo
Documentación_del_software
169
* Independientemente de su aplicación, todos los grandes sistemas tienen asociada ingentes cantidades de
documentación.
* Puede clasificarse
− De usuario
− Del sistema
* La información (Doc.) que se proporciona con el sistema tiene que satisfacer diversos requisitos:
− Como usar el sistema
− Como instalar y operar el sistema
− Los requisitos y el diseño de todo el sistema
− La aplicación del sistema y los procedimientos de prue−
ba, para poder efectuar el mantenimiento
* La documentación puede ser útil en cualquier etapa del ciclo de vida del sistema.
* En general, todos los tipos de documentación necesitan índices, que permitan a quien consulte acceder con
rapidez y seguridad a ella.
* Sin indice un documento bueno puede "no" ser útil. Con índice un mal documento puede ser útil.
Documentación_del_usuario
* Está compuesta por todos los documentos relacionados con las funciones del sistema, sin referirse a la forma
de aplicarlas.
* Esta, suele ser el primer contacto que tienen los usuarios con el sistema, y debe proporcionar una visión
inicial precisa del sistema.
* No es necesario que todos los usuarios del sistema lean la mayoría o totalidad de la información para
descubrir de forma sencilla como utilizar el sistema.
* Ello obliga a que este estructurada de tal manera que el usuario pueda leerla con el nivel de detalle adecuado
a sus necesidades.
* Existen al menos cinco documentos que pueden agruparse bajo la denominación de documentación de
usuario:
1º Descripción funcional sobre lo que puede hacer el
sistema
. No debe entrar en detalles ni es necesario que cubra
todas las características.
170
. Debe proporcionar una visión general
− Una visión general
− Los requisitos
− Breve descripción del propósito de los implantadores
2º Manual introductorio
. Que describa en términos sencillos como iniciarse en
el sistema, y como se puede utilizar.
. También indica como salirse de un problema cuando
algo falla.
3º Manual de referencia
. Es el documento más importante sobre el uso del
sistema. La característica de este es que debe ser
completo, incluso es aceptable perder legibilidad
en aras de la complitud.
. Debe describir:
− Ventajas del sistema
− Uso de las mismas
− Informes de error generado
− Situaciones en las que se producen los errores
4º Documento de instalación
. Proporciona detalles completos sobre la manera de
instalar un sistema en un entorno particular.
. Debe contener entre otras:
− Como esta escrita la información
− Formatos
− Archivos que componen el sistema
171
− Configuración mínima de hardware
− Archivos permanentes del sistema
− Etc.
5º Guia del operador
. Solo en el caso de que se requiera un operador del
sistema
. Describe como actuar cuando se produce cualquier si−
tuación durante el uso del sistema
. Describe mensajes a recibir y como responder a ellos
* Existe una discusión acerca de quien debe realizar la docu−
mentación:
− Los ingenieros del software
− Escritores técnicos profesionales
* Si escritores técnicos profesionales implica para el ingeniero del software dedicarse al construcción del
software.
* Problema: comunicación
* Realidad ingeniero del software. Posibilidad mixta.
Documentación_del_sistema
* Referido a todos los documentos que pertenecen a la aplica−
ción del sistema.
* Desde la especificación de requerimientos, pasando por el
diseño hasta el plan de pruebas de aceptación final
* Los documentos asociados al diseño y pruebas son esenciales
si se desea comprender y mantener el sistema
* De igual forma que la documentación de usuario, la del sis−
tema debe estar estructurada con visiones generales que qué−
re el usuario hasta las descripciones más detalladas de cada
172
aspecto.
* La documentación del sistema debe incluir:
− Definición de requisitos y (fundamentación asociada)
− Especificación general de sistemas que muestre como se
descomponen los requisitos en un conjunto de programas
interrelacionados.
− Por cada programa del sistema, una descripción de como se
descompone el programa en componentes y una especifica−
ción de cada componente
− Por cada programa una descripción de su operación
− Un plan de pruebas amplio que describa como se prueba ca−
da unidad
− Un plan de pruebas que muestre como se realizó la prueba
de validación
− Un plan de pruebas de aceptación diseñado con el usuario
describiendo las pruebas necesarias para la aceptación
del mismo
* Cada uno de estos documentos es una representación distinta
del mismo producto software.
* Uno de los grandes problemas asociados al mantenimiento es
asegurar que todas estas representaciones se correspondan con
el sistema que representan.
* Para ello las relaciones y dependencias se deben reflejar
junto a ellos.
* Lo mejor es la utilización de herramientas.
Calidad_de_la_documentación
173
* La calidad de la documentación es tan importante como el
propio programa
* Sin la información de su uso o comprensión por ejemplo, la
utilidad del sistema queda reducido (mantenimiento status)
* Producir buena documentación, no es:
− Fácil
− Barato
* Aspectos que ayudan a producir buenos documentos son los
estandares para:
− Producir
− Revisar
− Acomodar
* los estandares deben describir con exactitud lo que:
− Debe incluir
− Notaciones a utilizar
* Cada organización puede definir sus propios estandares y
exigir que todos los documentos se ajusten a él
Estilo_de_redacción
* Uno de los factores más importantes en la calidad de la do−
cumentación es la habilidad del redactor para elaborar una
prosa técnica de forma clara y concisa
* La buena documentación requiere buena redacción.
* A la hora de realizar un documento, se debe:
. Redactar, leer, criticar y volver a escribir repitiendo
el proceso hasta que se obtiene el documento satisfactorio.
* Es difícil definir un conjunto de reglas que determinen co−
174
mo realizar esta actividad
* Unos principios generales pudieran ser:
− Utilizar formas gramaticales activas en vez de pasivas.
(verá un cursor / sera visto un cursor)
− No usar frases largas que presenten varios hechos
distintos, usar oraciones cortas. Cada oración puede ser
asimilada, sin necesidad de retener varias partes de in−
formación para comprender toda la oración
− No referenciar información solo con el número de referen
cia. Dar referencia y lo que cubre.
( 1.1 /1.1 Describe recursos humanos)
− Detallar los hechos siempre que sea posible (como esta
relación) mejor lista que frase
− Si determinada descripción es compleja debe repetirse.
A veces es adecuado presentar dos o mas descripciones
de la misma cosa.
− Ser concreto (B.Gracián)
− Ser preciso y definir los términos utilizados. Hay tér−
minos que tienen mas de un significado (Módulo,proceso)
− Utilizar párrafos cortos. Como regla general, ningún pa−
rrafo debe contener más de siete frases (limitaciones de
memoria temporal, retención de información inmediata li−
mitada.
− Utilizar títulos y subtítulos. Asociados a una numera−
ción consistente.
− Utilizar construcciones gramaticales y ortografía correc
175
ta
. No abusar infinitivos (al ver /cuando vea)
. Las faltas irritan y restan credibilidad
Como_desarrollar_documentación
* Básicamente existen dos modelos:
− Manual
− Con herramientas (Ej. sistemas edición)
* Las ventajas que conllevan la utilización de herramientas
son:
− La documentación siempre se tiene a mano
− Es mas facil modificar y mantener los documentos lo que
implica mayor probabilidad de mantener actualizada la
documentación del proyecto
− Se puede definir un formato para los documentos lo que
implica mayor facilidad para la distribución
− Los documentos se pueden compartir, varias personas
pueden trabajar a la vez en la producción de un docu−
mento
− Se simplifica el empleo de los documentos
− Es posible la recuperación automática de la información
. Por ejemplo: recuperar todos los documentos que con−
tengan una palabra clave en particular.
Mantenimiento_de_la_documentación
* A medida que se modifica un sistema, la documentación aso−
ciada debe modificarse para reflejar los cambios en el sis−
tema.
176
* Por desgracia esto no suele hacerse (al menos no formalmen−
te), con lo que con el paso del tiempo la documentación no
refleja la situación actual del sistema, lo que implica
problemas tanto para el usuario como para las personas que
realizan el mantenimiento
* Cuando se hace un cambio en un programa debe reflejarse en
todos los documentos afectados
METODOLOGIA DE LA PROGRAMACION
Universidad de La Coruña. Facultad de Informática.
¡Error!Marcador no definido.
177
Descargar