IES Mare Nostrum

Tema 1 - Curso 2010/2011

Tema 1 - Principios bsicos de ingeniera del software

1. Introduccin a la ingeniera del software
1.1.

Software

Es el conjunto de los programas de cmputo, procedimientos, reglas, documentacin y

datos asociados que forman parte de las operaciones de un sistema de computacin.
Extrado del estndar 729 del IEEE
El software incluye:
Instrucciones que, cuando se ejecutan, proporcionan la funcionalidad deseada.
Estructuras de datos que facilitan a las instrucciones manipular adecuadamente
la informacin
Documentos que describen el desarrollo, uso, instalacin y mantenimiento de
los programas.
Incluye: entrenamiento, soporte al consumidor e instalacin
Caractersticas del software
ELEMENTO LGICO, NO FSICO
SE DESARROLLA, NO SE FABRICA
NO SE ROMPE, SE DETERIORA (CAMBIOS)
POCA O NULA REUTILIZACIN (SOFTWARE A MEDIDA)

Atributos de calidad del Software

Fiable: Capacidad de ofrecer los mismos resultados bajo las mismas

condiciones.
Eficiente: Utilizacin ptima de los recursos de la mquina.
Robusto: No poseer un comportamiento catastrfico ante situaciones
excepcionales (Tolerante a fallos).
Correcto: Se ajusta a las especificaciones dadas por el usuario.
Portable: Capaz de integrarse en entornos distintos con el mismo esfuerzo.
Adaptable (extensibilidad): Modificar alguna funcin sin que afecte a sus
actividades.
Inteligible: Diseo claro, bien estructurado y documentado.
No Errneo: No exista diferencia entre los valores reales y los calculados
Reutilizable (reusabilidad)

Anlisis y diseo de aplicaciones informticas - Pgina 1/21

IES Mare Nostrum

1.2.

Tema 1 - Curso 2010/2011

Evolucin del software

Primera Era: Aos 50

Programas con ensamblador
Funciones matemticas
poca de transicin: 60.

Crisis del software
Segunda Era: 70s.
Aparicin de computadoras ms potentes
Software de uso general, fuerte mantenimiento
No existe un conocimiento detallado de la estructura interna de los programas
Tercera Era: 80s
Marcada por PCs
Disminucin de precios
Programacin estructurada
Reduccin del mantenimiento
Cuarta ERA
Lenguajes de cuarta generacin
Programacin concurrente con ms de un procesador
Lenguajes orientados a objetos
Mejores herramientas, pero mayor complexidad

1.3.

Crisis del Software

La crisis del software se fundament en el tiempo de creacin de software, ya que en la

creacin del mismo no se obtenan los resultados deseados, adems de un gran costo y
poca flexibilidad.
Bsicamente, la crisis del software se debi a la dificultad en escribir programas libres
de defectos, fcilmente comprensibles, y que sean verificables. Las causas son, entre
otras, la complejidad que supone la tarea de programar, y los cambios a los que se
tiene que ver sometido un programa para ser continuamente adaptado a las
necesidades de los usuarios.
Englob a una serie de sucesos que se venan observando en los proyectos de desarrollo
de software:

Los proyectos no terminaban en plazo.

Los proyectos no se ajustaban al presupuesto inicial.
Baja calidad del software generado.
Software que no cumpla las especificaciones.
Cdigo inmantenible que dificultaba la gestin y evolucin del proyecto.

 Ello provoc la insatisfaccin y desconfianza del cliente, debido a un psimo control

de calidad

Anlisis y diseo de aplicaciones informticas - Pgina 2/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Situacin actual
Las aplicaciones de hoy en da son programas muy complejos, inabordables por una
sola persona. En sus comienzos se valor como causa tambin la inmadurez de la
ingeniera de software, aunque todava hoy en da no es posible realizar estimaciones
precisas del coste y tiempo que necesitar un proyecto de software.
Adems, no existen todava herramientas que permitan estimar de una manera exacta,
antes de comenzar el proyecto, cul es el esfuerzo que se necesitar para desarrollar un
programa. Este hecho provoca que la mayora de las veces no sea posible estimar cunto
tiempo llevar un proyecto, ni cunto personal ser necesario. Cuando se fijan plazos
normalmente no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el
personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de
ejecucin.
Aunque se han propuesto diversas metodologas para intentar subsanar los problemas
mencionados, lo cierto es que todava hoy no existe ningn mtodo que haya permitido
estimar de manera fiable el coste y duracin de un proyecto antes de sus comienzos.
En definitiva, la industria del software no ha acabado de salir de la fase artesanal
1.4.

Dificultades del desarrollo del software

Software es algo intangible, lo que conlleva dificultad para medirlo y as poder
planificar el esfuerzo en su desarrollo.

INDUSTRIA de la CONSTRUCCION
INDUSTRIA del SOFTWARE
-PEQUEOS PROYECTOS
(armario empotrado)
(pequeo programa)
1 da x 1 hombre
1 da x 1 hombre
+ GRANDES PROYECTOS
(La Dfense, Opera House)
(Gran proyecto Sw)
Varios aos x
Varios aos x
Contratistas,
empresa software,
constructores,
ingenieros software,
arquitectos,
analistas,
delineantes,
operadores,
obreros,
programadores,
auditores,
albailes,
auditores,
usuarios
Los proyectos ms pequeos (los de uso personal) se parecen a los pequeos
programas:
puede desarrollarlo el propio interesado, y en un tiempo mnimo.
Los proyectos ms grandes se parecen a los grandes proyectos software:
gran cantidad de personal y usuarios,
son personas distintas los que desarrollan, usan y mantienen,

cobran importancia fundamental las tareas relacionadas con aspectos

administrativos, de planificacin, estimacin y control.

Hay planos como en una obra cuando construimos software?

Anlisis y diseo de aplicaciones informticas - Pgina 3/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Relacin del coste del Software con el coste del Hardware

Porcentaje del coste

100
total del sistema
80

Hardware

60

Software

40
20

80

60

0
aos

Coste del desarrollo del software

Total

VALIDACIN + PP + MANT. = 7/8 (88%)

CODIFICACIN = 1/24 (4%)
ANLISIS + DISEO = 1/12 (8%)

Anlisis y diseo de aplicaciones informticas - Pgina 4/21

IES Mare Nostrum

1.5.

Tema 1 - Curso 2010/2011

Ingeniera del Software

rea de la informtica o ciencias de la computacin que ofrece mtodos y tcnicas para

desarrollar y mantener software de calidad para todo tipo de sistemas de software.

Ingeniera
del software
Desarrollo
de Software
Analisis
Diseo
Codificacin
Pruebas

Gestin de
proyectos

Metricas
del software

Planificacin
Organizacin
Reclutamiento
Direccin
Control

Mantenimiento
de software

Fiabilidad
Correccin de Errores
Usabilidad
Modificaciones
Flexibilidad
Mantenibilidad
Reusabilidad
Etc.

Principios de la ISW

La produccin de programas debe abordarse como una ingeniera ms.

La produccin de programas correctos, que se desarrollan a tiempo y dentro de

las estimaciones de presupuesto, y a la correspondiente documentacin para
desarrollarlos, usarlos y mantenerlos.

La Ingeniera del Software se fundamenta en tcnicas relacionadas con: ciencia

de la computacin, programacin, ingeniera, administracin, matemticas,
economa, etc

Pilares de la ISW

Abstraccin: Permite parcelar la complejidad. Por ello se olvidan aspectos

irrelevantes del sistema y se potencian los fundamentales.

Encapsulamiento u Ocultacin de la informacin: Esconder todos los detalles

que no afecten a otros mdulos, definiendo interfaces estrictos que sirvan de
interaccin entre los distintos modelos.

Modularidad: Sirve para parcelar la solucin en mdulos independientes con

fuerte cohesin interna.

Localizacin: Deben estar agrupados todos aquellos elementos que estn

afectados por un mismo hecho.

Uniformidad: Todos los mdulos deben tener una notacin similar.

Validacin y Verificabilidad: El producto final debe ser fcilmente validable y

verificable: Estamos desarrollando el programa correcto? Estamos
desarrollando correctamente el programa?

Anlisis y diseo de aplicaciones informticas - Pgina 5/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

1.5.1. Fases de la ISW

Anlisis de requisitos

Qu debe hacer el sistema?

La extraccin de los requisitos de un producto de software es la primera etapa para
crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que
hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer
requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de
requisitos con el cliente se plasma en un documento.
Es fundamental tener entrevistas con el usuario final para que este nos defina los
requisitos que espera que tenga el Software. Por ello es importante que nos defina las
pantallas, informes o cualquier informacin que nos sea til para poder especificar el
software.
Diseo de la aplicacin

Cmo construir el sistema?

El Diseo de sistemas es el arte de definir la arquitectura software, componentes,
mdulos y datos de un sistema de cmputo para satisfacer ciertos requerimientos.
El diseo de sistemas vendra a ser lo que para un arquitecto son los planos de un
edificio, en el se detalla los pasos a realizar para la creacin del software.
Programacin

Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de
software, pero no necesariamente es la que demanda mayor trabajo y ni la ms
complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al
o a los lenguajes de programacin utilizados, as como al diseo previamente realizado.
Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en la

especificacin del problema.
Una tcnica de prueba es probar por separado cada mdulo del software, y luego
probarlo de forma integral, para as llegar al objetivo. Se considera una buena prctica el
que las pruebas sean efectuadas por alguien distinto al desarrollador que la program,
idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer
sus propias pruebas.
En general hay dos grandes formas de organizar un rea de pruebas, la primera es que
est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta
forma se evala que la documentacin entregada sea de calidad, que los procesos
descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal
y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada por
programadores con experiencia, personas que saben sin mayores indicaciones en qu
condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que
personal inexperto no considerara.

Anlisis y diseo de aplicaciones informticas - Pgina 6/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Documentacin

Todo lo concerniente a la documentacin del propio desarrollo del software y de la

gestin del proyecto, diagramas, pruebas, manuales de usuario, manuales tcnicos, etc;
todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y
ampliaciones al sistema.
Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos.

Esto puede llevar ms tiempo incluso que el desarrollo inicial del software. Alrededor
de 2/3 de toda la ingeniera de software tiene que ver con dar mantenimiento.
Una pequea parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte
consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor
de 2/3 de toda la ingeniera civil, arquitectura y trabajo de construccin es dar
mantenimiento
Tipos de mantenimiento:

Correctivo: un programa no realiza correctamente la aplicacin para la que ha

sido diseado, y, por tanto, debe ser modificado.
Perfectivo: modificaciones a los programas para conseguir mayor adecuacin a
los requisitos, mayor eficiencia, o simplemente recoger nuevas funcionalidades
no expresadas en la fase de definicin del sistema.
Adaptativo: Adaptar los programas para acomodarlos a los cambios de su
entorno externo (modificaciones en la legislacin, CPU, SO, las reglas de
negocio, etc.)
Preventivo: El software se deteriora con los cambios, y este tipo de
mantenimiento hace cambios en los programas para que se puedan corregir,
adaptar y mejorar ms fcilmente (Reingeniera del software).

DEFINICIN

DESARROLLO
Fallos de definicin

MANTENIMIENTO
Errores

Modificaciones y adaptaciones

Anlisis y diseo de aplicaciones informticas - Pgina 7/21

IES Mare Nostrum

1.6.

Tema 1 - Curso 2010/2011

Roles en la ISW

Administrador del proyecto o responsable de proyecto: El administrador de proyecto

es la persona que administra y controla los recursos asignados a un proyecto, con el
propsito de que se cumplan correctamente los planes definidos. Los recursos asignados
pueden ser recursos humanos, econmicos, tecnolgicos, espacio fsico, etc. En un
proyecto, siempre debe existir un administrador. No obstante, un administrador puede
dirigir ms de un proyecto.
Objetivos
1. Tener el producto a tiempo, bajo presupuesto y con los requisitos de calidad
definidos.
2. Terminar el proyecto con los recursos asignados.
3. Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus
integrantes a cumplir sus objetivos particulares. Al final, se cumplir el objetivo
general.
4. Cumplir con xito las diferentes fases de un proyecto, utilizando herramientas de
administracin.
5. Cumplir con las expectativas del cliente.

Analistas: Trabajar con los analistas para estudiar las necesidades de los clientes y los
requisitos del sistema.
Esta se refiere a la habilidad de poder estudiar un problema de una complejidad
determinada, descomponiendo el problema en subproblemas de menor complejidad. De
esa forma, la solucin del problema completo se obtiene como la suma de las soluciones
de los subproblemas de menor complejidad.
Tareas:
Preparar un documento con preguntas a realizar al cliente durante las entrevistas.
Determinar las fechas de reunin con el cliente.
Generar un documento de especificacin de requisitos de usuario en base a los
acuerdos alcanzados en la primera reunin.
Presentacin del documento de especificacin al cliente en la siguiente reunin.
De ser necesario, realizar las modificaciones al documento de especificacin de
requisitos de usuario y presentarlas al cliente en la prxima reunin. Repetir esta
actividad las veces que sea necesario.
Revisar los diagramas de arquitectura con los diseadores.
De ser necesario, realizar las modificaciones a los diagramas.
Presentar los diagramas de arquitectura finales.
Construir el documento de requisitos de software.
Revisar el documento con los ingenieros de aseguramiento de la calidad y
cliente, realizando modificaciones de ser necesario.

Anlisis y diseo de aplicaciones informticas - Pgina 8/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Diseadores: Trabajar con ellos para disear la arquitectura del sistema de acuerdo con
los recursos asignados al proyecto. El administrador de proyecto requiere la arquitectura
del sistema para determinar el plan de trabajo de los dems roles.
Programadores: Los programadores deben convertir la especificacin del sistema en
cdigo fuente ejecutable utilizando uno o ms lenguajes de programacin, as como
herramientas de software de apoyo a la programacin.
Tareas:
Codificar y depurar.
Testear.
Realizar revisiones personales y reuniones.
Escribir la documentacin tcnica.

Tsters: Trabajar con ellos para determinar que tipo de testeo deber utilizarse, y con
que profundidad, de acuerdo con los requisitos de seguridad en el diseo del sistema y
de los recursos disponibles. Los resultados de los tests ayudan a determinar el xito del
proyecto, preocupacin principal de la administracin de proyecto.
Documentadores: El administrador de proyecto tomar como referencia los
documentos controlados por los documentadores para elaborar planes y la evaluacin
del proyecto.

Planificacin y control de procesos (planes, calendarios, estimaciones).

Reportes sobre recursos utilizados durante el desarrollo.
Estndares a ser utilizados en las diferentes fases.
Registro de ideas y estrategias a ser consideradas por el equipo.
Lgica de las decisiones de diseo.
Detalles de la comunicacin diaria entre los gerentes y el equipo de desarrollo.

Clientes: El administrador de proyecto deber administrar la relacin con los clientes,

desarrollando una comunicacin fluida con stos, y siendo la cara visible del proyecto.
Definir y priorizar requisitos.
Revisar y aprobar documentos en forma responsable.
Difundir el estado del proyecto al resto de su mbito de trabajo.
Entregar los recursos necesarios para la realizacin del proyecto.
Determinar y alertar del impacto del proyecto en otras reas de la organizacin.
Realizar la capacitacin del sistema a sus usuarios.
Construir el plan de pruebas de aceptacin del sistema y aplicarlo al final del proyecto,
aceptando o rechazando la entrega.

Anlisis y diseo de aplicaciones informticas - Pgina 9/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

2. Ciclo de Vida del Software

2.1.

Concepto de Ciclo de Vida

Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y

el mantenimiento del software [IEEE 1074].
Un marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la definicin de los requisitos hasta la
finalizacin de su uso [ISO 12207-1].

Tarea: Plantear cuestin sobre que modelo ellos seguiran para crear software. Ver
ventajas e inconvenientes.
2.2.

Procesos del Ciclo de Vida del software

Se define como Proceso al conjunto ordenado de pasos a seguir para llegar a la solucin
de un problema u obtencin de un producto, en este caso particular, para lograr la
obtencin de un producto software que resuelva un problema.

Proceso de Adquisicin: Actividades y tareas que el comprador, cliente o usuario

realiza para adquirir un sistema o producto software.
Proceso de Suministro: Actividades y tareas que efecta el suministrador.
Proceso de Desarrollo:
Anlisis de Requisitos del Sistema
Diseo de la Arquitectura del Sistema
Anlisis de los Requisitos del Software
Diseo de la Arquitectura del Software
Diseo Detallado del Software
Codificacin y Prueba del Software
Integracin del Software
Prueba del Software
Integracin del Sistema

Anlisis y diseo de aplicaciones informticas - Pgina 10/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Prueba del Sistema

Instalacin del Software
Soporte del proceso de Aceptacin del Software

Proceso de Explotacin: Incluye la explotacin del software y el soporte operativo a

los usuarios.
Proceso de Mantenimiento:
Aparece cuando el software necesita modificaciones.
El objetivo es modificar el software existente manteniendo su consistencia.

Proceso de Documentacin: Registra la informacin producida por un proceso o

actividad del ciclo de vida.
Proceso de Gestin de la Configuracin: Aplica ciertos procedimientos
administrativos y tcnicos durante todo el ciclo de vida relacionados con la
configuracin del software y con las modificaciones y versiones de los documentos.
Proceso de Aseguramiento de la Calidad: Aporta confianza en que los procesos y los
productos software del ciclo de vida cumplen con los requisitos especificados y se
ajustan a los planes establecidos.
Proceso de Verificacin: Determina si los requisitos de un sistema o del software estn
completos y son correctos, y si los productos software de cada fase del ciclo de vida
cumplen los requisitos y condiciones impuestos en fases previas.
Proceso de Validacin: Sirve para determinar si el sistema o software final cumplen
con los requisitos previstos para su uso.
Proceso de Revisin Conjunta: Sirve para evaluar el estado del software y sus
productos en una actividad del ciclo de vida o una fase de un proyecto.
Proceso de Auditora: Permite determinar, en los hitos predeterminados, si se han
cumplido los requisitos, los planes y el contrato.

Anlisis y diseo de aplicaciones informticas - Pgina 11/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Proceso de Resolucin de Problemas: Permite analizar y eliminar los problemas

descubiertos durante el desarrollo, la explotacin, el mantenimiento u otro proceso.
Cualquiera sea el "proceso" utilizado y aplicado al desarrollo del software casi
independientemente de l, siempre se debe aplicar un "Modelo de Ciclo de Vida

2.3.

Metodologas de desarrollo del Software

Metodologa de desarrollo de software en ingeniera de software es un marco de trabajo

usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de
informacin.
Un ejemplo de ello es la programacin estructurada o la programacin orientada a
objetos.

Modelos de Ciclo de Vida

2.4.

El modelo de proceso o modelo de ciclo de vida utilizado para el desarrollo define el

orden para las tareas o actividades involucradas tambin definen la coordinacin entre
ellas, enlace y realimentacin entre las mencionadas etapas.

2.4.1. Modelo en cascada

Caractersticas:

Cada fase empieza cuando se ha terminado la fase anterior

Anlisis y diseo de aplicaciones informticas - Pgina 12/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Para pasar de una fase a otra es necesario conseguir todos los objetivos de la
etapa previa

Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados

Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad de

revisar el progreso del proyecto

Desventajas del modelo cascada:

Los cambios introducidos durante el desarrollo pueden confundir al equipo

profesional en las etapas tempranas del proyecto. Si los cambios se producen en
etapa madura (codificacin o prueba) pueden ser catastrficos para un proyecto
grande.

No es frecuente que el cliente o usuario final explicite clara y completamente los

requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre
natural en los comienzos es luego difcil de acomodar.

El cliente debe tener paciencia ya que el software no estar disponible hasta muy
avanzado el proyecto. Un error detectado por el cliente (en fase de operacin)
puede ser desastroso, implicando reinicio del proyecto, con altos costos.

2.4.2. Modelo incremental

Anlisis y diseo de aplicaciones informticas - Pgina 13/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Anlisis y diseo de aplicaciones informticas - Pgina 14/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Caractersticas:

Corrige la necesidad de una secuencia no lineal de pasos de desarrollo

El sistema se crea aadiendo componentes funcionales al sistema incrementos

El sistema no se ve como una entidad monoltica con una fecha fija de entrega,
sino que es una integracin de resultados sucesivos obtenidos despus de cada
iteracin

Se ajusta a entornos de alta incertidumbre

Ejemplo:
Un procesador de texto que sea desarrollado bajo el paradigma Incremental podra
aportar, en principio, funciones bsicas de edicin de archivos y produccin de
documentos (algo como un editor simple). En un segundo incremento se le podra
agregar edicin ms sofisticada, y de generacin y mezcla de documentos. En un tercer
incremento podra considerarse el agregado de funciones de correccin ortogrfica,
esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y
ecuaciones matemticas. As sucesivamente hasta llegar al procesador final requerido.
As, el producto va creciendo, acercndose a su meta final, pero desde la entrega del
primer incremento ya es til y funcional para el cliente, el cual observa una respuesta
rpida en cuanto a entrega temprana; sin notar que la fecha lmite del proyecto puede no
estar acotada ni tan definida, lo que da margen de operacin y alivia presiones al equipo
de desarrollo.
El hecho de que existan incrementos funcionales del software lleva inmediatamente a
pensar en un esquema de desarrollo modular, por tanto este modelo facilita tal
paradigma de diseo.
En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con
entregas parciales del producto software denominados incrementos del sistema, que
son escogidos segn prioridades predefinidas de algn modo. El modelo permite una
implementacin con refinamientos sucesivos (ampliacin o mejora). Con cada
incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se
mejora la versin previamente implementada del producto software.

Ventajas y desventajas:

Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia
El usuario se involucra ms
Mayor retorno de la inversin
Difcil de evaluar el coste total
Difcil de aplicar a sistemas transaccionales que tienden a ser integrados y a
operar como un todo
Requiere gestores experimentados
El resultado puede ser muy positivo
Los errores en los requisitos se detectan tarde y su correccin resulta costosa

Anlisis y diseo de aplicaciones informticas - Pgina 15/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

2.4.3. Modelo en espiral

El modelo se divide en un nmero de Actividades de marco de trabajo, llamadas

"regiones de tareas". En general existen entre tres y seis regiones de tareas (hay
variantes del modelo). En la figura se muestra el esquema de un Modelo Espiral con 6
regiones.
Las regiones definidas en el modelo de la figura son:

Regin 1 - Tareas requeridas para establecer la comunicacin entre el cliente y

el desarrollador.
Regin 2 - Tareas inherentes a la definicin de los recursos, tiempo y otra
informacin relacionada con el proyecto.
Regin 3 - Tareas necesarias para evaluar los riesgos tcnicos y de gestin del
proyecto.
Regin 4 - Tareas para construir una o ms representaciones de la aplicacin
software.

Anlisis y diseo de aplicaciones informticas - Pgina 16/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Regin 5 - Tareas para construir la aplicacin, instalarla, probarla y proporcionar

soporte al usuario o cliente (Ej. documentacin y prctica).
Regin 6 - Tareas para obtener la reaccin del cliente, segn la evaluacin de lo
creado e instalado en los ciclos anteriores.

Cada ciclo empieza identificando:

Los objetivos de la porcin correspondiente
Las alternativas
Restricciones







Se evalan las alternativas respecto a los objetivos y las restricciones

Se formula una estrategia efectiva para resolver las fuentes de riesgos
Se plantea el prximo prototipo
Una vez resueltos los riesgos se sigue el ciclo en cascada
Cada ciclo se completa con una revisin que incluye todo el ciclo anterior y el
plan para el siguiente

Diferencias con los mtodos tradicionales:

Existe un reconocimiento explcito de las diferentes alternativas para alcanzar

los objetivos de un proyecto

La identificacin de riesgos asociados con cada una de las alternativas

La divisin de los proyectos en ciclos

El modelo se adapta a cualquier tipo de actividad

2.4.4. Ciclo de vida en Prototipado

Es la tcnica de construccin de interfaces de usuario o prototipos para que el usuario
final se haga una idea de cmo quedar la aplicacin.
Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente
para una retroalimentacin; gracias a sta se refinan los requisitos del software que se
desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las
necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda
mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
Los prototipos tienen una doble funcin:

El cliente ve el producto y refina sus requisitos

El desarrollador comprende mejor lo que necesita hacer

Anlisis y diseo de aplicaciones informticas - Pgina 17/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Caractersticas:

2.5.

No modifica el flujo del ciclo de vida

Reduce el riesgo de construir productos que no satisfagan las necesidades de los
usuarios
Reduce costos y aumenta la probabilidad de xito
Exige disponer de las herramientas adecuadas
No presenta calidad ni robustez
Suele utilizarse principalmente en dos reas:
o Prototipado de la interfaz de usuario
o Prototipado del rendimiento
Reduce el riesgo y aumenta la probabilidad de xito

La reutilizacin en el Ciclo de Vida

Principios de la reutilizacin:
Existen similitudes entre distintos sistemas de un mismo dominio de aplicacin
El software puede representarse como una combinacin de mdulos
Disear aplicaciones = especificar mdulos + interrelaciones
Los sistemas nuevos se pueden caracterizar por diferencias respecto a los
antiguos

Anlisis y diseo de aplicaciones informticas - Pgina 18/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Ventajas y desventajas:

2.6.

2.7.

Reduce tiempos y costes de desarrollo

Aumenta la fiabilidad
Dificultad para reconocer los componentes potencialmente reutilizables
Dificultad de catalogacin y recuperacin
Problemas de motivacin
Problemas de gestin de configuracin

Sntesis automtica de software

Se define el sistema utilizando un lenguaje formal

La implementacin es automtica, asistida por el ordenador
La documentacin se genera de forma automtica
El mantenimiento se realiza por sustitucin, no mediante parches
Hay dificultad en la participacin del usuario
Los diseos estn poco optimizados

Herramientas CASE

Desde que a finales de los aos sesenta se acua el trmino "crisis del software",
numerosos expertos han venido ocupndose del tema, proponiendo distintas tcnicas,
metodologas y herramientas para paliar esta situacin.
Entre todas ellas destaca la tecnologa conocida con el nombre de CASE (Computer
Aided/Assisted Software/System Engineering) que, en su acepcin ms amplia, se
puede definir como el conjunto de herramientas y metodologas que prestan soporte a
un enfoque de ingeniera en el desarrollo de software en alguna o todas las fases de este
proceso.

Anlisis y diseo de aplicaciones informticas - Pgina 19/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

La tecnologa CASE surge a mediados de los aos setenta cuando empiezan a aparecer
las primeras metodologas estructuradas y se inician las investigaciones sobre entornos
de desarrollo.
A mediados de los aos ochenta el CASE se populariza y surgen las primeras
herramientas de documentacin y diagramacin automtica. Surge asimismo el
concepto de repositorio/diccionario como ncleo de un entorno CASE, as como
generadores de programas y aplicaciones que automatizan gran parte de las ltimas
fases del ciclo de vida. En paralelo, aparecen tambin los gestores de proyectos algunos
de los cuales se integran con herramientas CASE.
A finales de los ochenta se produce un considerable aumento en la venta de estos
productos y empieza la etapa de asimilacin de la tecnologa, que fracasa debido a las
limitaciones de la "primera" generacin de productos, las falsas expectativas sobre sus
posibilidades y su incorrecta implantacin.
A mediados de los aos noventa empieza a surgir una "segunda generacin" de
herramientas que superan gran parte de las limitaciones existentes en las de primera
generacin. Adems, los usuarios conocen mejor sus posibilidades y han aprendido a
poner unas expectativas ms justas sobre stas, mejorando tambin los procesos de
adopcin de metodologas y herramientas.
La tecnologa CASE supone la "informatizacin de la informtica", es decir, "la
automatizacin del desarrollo del software", contribuyendo as a elevar la productividad
y la calidad en el desarrollo de sistemas de informacin. Este nuevo enfoque a la hora
de construir software persigue mejorar la calidad y la productividad de los sistemas de
informacin, para lo que se plantean los siguientes objetivos:

Permitir la aplicacin prctica de metodologas estructuradas, lo que resulta muy

difcil sin emplear herramientas.

Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones.

Simplificar el mantenimiento de los programas.

Mejorar y estandarizar la documentacin.

Aumentar la portabilidad de las aplicaciones.

Facilitar la reutilizacin de componentes software.

Permitir un desarrollo y un refinamiento "visual" de las aplicaciones mediante la

utilizacin de grficos.

Anlisis y diseo de aplicaciones informticas - Pgina 20/21

IES Mare Nostrum

Tema 1 - Curso 2010/2011

Tipos de herramientas CASE:

Herramientas de gestin, encargadas de la estimacin, planificacin y

seguimiento del proyecto.

Herramientas tcnicas, que se dividen tradicionalmente en CASE frontales

(Font-end) o superiores (Upper CASE) que abarcan las primeras fases de
anlisis y diseo; y, CASE dorsales (back-end) o inferiores (Lower CASE) cuyo
objetivo suele ser el diseo detallado y la generacin de cdigo.

Herramientas de soporte, como el sistema de repositorio/diccionario, control y

configuracin, seguridad, etc.

2.8.

Modelos para desarrollo de sistemas Orientados a Objetos

El modelo en cascada no permite aprovechar las ventajas de la tecnologa OO

Tecnologa OO:
Pretende acelerar el desarrollo de sistemas de una manera iterativa e incremental
Generalizar los componentes para que sean reutilizables
Todos estos modelos caracterizan el desarrollo OO por:
Eliminacin de fronteras entre fases, ya que debido a la naturaleza iterativa del
desarrollo OO, estas fronteras se difuminan cada vez ms
Una nueva forma de concebir los lenguajes de programacin y su uso, ya que se
incorporan bibliotecas de clases y otros componentes reutilizables
Un alto grado de iteracin y solapamiento, lo que lleva a una forma de trabajo muy
dinmica

Anlisis y diseo de aplicaciones informticas - Pgina 21/21