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

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

- 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.

- 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

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.

- 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

- 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

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

/|\

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-

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.

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-

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

- 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

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 |

|

|___________________________________

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

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

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.

- 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

- 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

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.

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

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.

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

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

- 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

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

- 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,

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

- 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

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% |________| |_________

| |________| | 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.

- 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

- 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

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

- 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

- 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

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

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

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

- 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-

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.

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

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

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-

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-

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

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

- 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 |

| | | | | |________|

| | | | | |

| | | | | |

|_________\|/_______\|/_______\|/__________\|/_______|

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

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

- 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

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|

| | | |

|___________________________| |____________|

- 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

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___|___\|/_____

|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

- 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.

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

- 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

- 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

- 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

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

- 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-

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

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,

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

- 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

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)

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

- 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:

- 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)

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

- 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

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

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

- 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

- 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-

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

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

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

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-

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)

- 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

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

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

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

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

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

\ | / \| /

o o

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.

- 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

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-

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)

- 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

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)

- 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

- 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

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,

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

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)

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

- 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

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

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

- 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

. 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

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

- 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

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

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

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

- 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

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

- 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

- 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-

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

- 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

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

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.

. 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

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.

. 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

- 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

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

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

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

- 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.

* 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

- 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)

- 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.

. 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

- 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:

- 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

- 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.

- 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

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

* 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

- 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

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:

- 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:

- 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)

- 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-

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

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

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

. 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

|

___\|/___

|_______|

|/______________

____|\___ |

|_______| |

|/_________ |

____|\___ | |

|_______| | |

/\_________| |

\/ |

____|____ |

|_______| |

/\______________|

\/

|

\|/

- Concatenados

. Si los bucles son independientes aplicar técnicas

simples

. Si los bucles son dependientes, aplicar técnica de

anidados

_________

|_______|

|/________

____|\___ |

|_______| |

/\________|

\/

____|____

|_______|

|/________ |/_______

____|\___ | ____|\___ |

|_______| | |_______| |

/\________| |/______|____

\/ |\ | |

______/ \ | |

- No estructurados | \ / | |

| |/_____ | |

. Rediseñar __________________\ | |\ | | |

/ | / \____|_| |

| \ / | |

| ____|____ | |

|->|_______| | |

| | |

/ \____| |

\ / |

| |

/ \__________|

\ /

Prueba_de_la_caja_negra

* Referida a las pruebas que se realizan sobre la interface

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

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

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

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.

. 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,

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.

* 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

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,

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

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-

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

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).

- 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

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

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-

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

- 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

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

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.

* 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

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

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

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.

. 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

* 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.

. 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

- 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

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

* 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-

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

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.

* 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.