Ingeniería del Software

IGEIERÍA DEL SOFTWARE.
Mª Dolores Carballar Falcón
28935146L
REFERECIA AL SISTEMA EDUCATIVO ACTUAL.
Los contenidos de este tema, están enfocados a introducir al alumno en el concepto
de Ingeniería del Software. Estos contenidos, según determina el Decreto 132/1995 por
el que se establece el currículo del ciclo formativo de grado superior de Desarrollo de
Aplicaciones Informáticas, se corresponden al módulo de Análisis y Diseño Detallado
de Aplicaciones Informáticas de Gestión. Puede ser tomado como tema inicial del
módulo porque ofrece una panorámica general del concepto de Ingeniería del Software,
el ciclo de vida del software así como las distintas metodologías que se utilizan en el
desarrollo de aplicaciones.
1.- ITRODUCCIÓ A LA IGEIERÍA DEL SOFTWARE
Software: instrucciones que cuando se ejecutan proporcionan la función deseada.
Sus características principales son:
a) es intangible, no es algo físico.
b) se desarrolla, no se fabrica. El desarrollo implica que hasta que no llegan las
fases finales no vemos el resultado.
c) el software no se estropea… ¿Seguro?:
Fallos del hardware en función
Fallo
del tiempo. (Vida normal de
s
cualquier hardware).
1)
En un principio la proporción
3)
de fallos del hardware 1) es
2)
alta debido a defectos en el
diseño o en la fabricación.
Tiempo
Posteriormente la proporción
de fallos se estabiliza 2) y en un plazo más lejano vuelven a aumentar los fallos
como consecuencia del deterioro de los componentes 3). Esta es la llamada curva de
bañera. Si nos fijamos ahora en los fallos del software en función del tiempo,
podemos observar una
primera línea que parte
de una gran cantidad de
Fallo
3´´)
fallos 1) debido a fallos
s
en el desarrollo o en el
1)
3) 3´)
diseño. Después se esta2)
biliza 2) debido
2´)
a la resolución de los
fallos, aunque rápidamente aparecen nuevos
Tiempo
fallos tanto en el mantenimiento como en el
nuevo desarrollo de
software 3) que aunque se solucionan, pronto vuelven a aparecer otros que también
se solucionan 3´) 3´´)...... pero contribuyen al deterioro definitivo del software.
En un principio podríamos pensar que la gráfica seguiría la línea 2´) debido a que el
software no se estropea, pero la realidad es, que aunque no se pueda deteriorar
físicamente, si lo hace en el ámbito de mantenimiento, siguiendo la pauta de la
anterior gráfica que se puede simplificar en la siguiente:
Fallo
s
Tiempo
Además, cuando un hardware se estropea, se sustituye por una pieza de repuesto,
pero no hay piezas de repuesto para el software. Cada fallo en el software implica
errores en el diseño o en el proceso de traducción de ese diseño al código ejecutable,
por tanto el mantenimiento del software es mucho más complicado que el del
hardware.
d) La mayoría del software se construye a medida, es decir, adaptado a las
necesidades del cliente en vez de ensamblar componentes existentes. Todavía está
por conseguir la reusabilidad del software.
Definiciones de Ingeniería del Software:
1) Es la disciplina que intenta obtener productos de calidad del software.
2) Es una disciplina tecnológica-administrativa dedicada a la producción
sistemática de productos de programación, que se han desarrollado y
modificado a tiempo y dentro de un presupuesto definido.
La Ingeniería del Software está compuesta por tres elementos claves:
1- Técnicas ó Métodos: proporcionan las normas a seguir al construir software
(MER, DFD,…)
2- Herramientas: sirven de soporte a las técnicas; hoy se habla de Herramientas
CASE (ingeniería del software asistida por computadora) como una gran ayuda en el
análisis y diseño de aplicaciones.
3- Procedimientos: Definen la secuencia en la que se aplican las técnicas.
2.-COCEPTOS BÁSICOS.
Sistema: Conjunto de componentes, que ordenadamente relacionados entre sí,
contribuyen a un determinado objetivo.
Sistemas de Información: Sistema que me proporciona información para la toma de
decisiones.
Sistema Informático: Es un sistema de información basado en ordenadores.
Aplicación Informática: También llamado proyecto software y es el conjunto de
programas que resuelven un determinado problema. Estas aplicaciones se desarrollan
siguiendo un esquema que recibe el nombre de ciclo de vida de una aplicación
(paradigma).
Un sistema informático sería el conjunto de elementos necesarios para la realización y
utilización de aplicaciones informáticas.
3.-ETAPAS DEL CICLO DE VIDA DE UA APLICACIÓ IFORMÁTICA.
Ciclo de vida se define como el conjunto de fases que transcurren desde que surge la
idea de construir una aplicación, hasta que la aplicación deja de tener validez y se
desecha.
Etapas fundamentales en el ciclo de vida de todo proyecto:
PLANIFICACIÓN
DESARROLLO
MANTENIMIENTO
-
Planificación: En esta fase se hace imprescindible conocer el sistema de
información o informático, en el que va a estar inmerso el software que voy a
desarrollar, determinar los objetivos a cumplir, definir un plan de acción
(proyecto a desarrollar y calendario que se va a seguir), evaluar los recursos
necesarios y determinar un plan de seguimiento con mecanismos de evaluación
adecuados. (Técnicas de Análisis Coste/Beneficio)
-
Desarrollo: Se divide en cuatro etapas:
Análisis: Consiste en responder a la siguiente pregunta: ¿Qué
es lo que tenemos que hacer? Se trata de conocer los datos a
manejar, el conjunto de entradas que necesita el sistema, el
conjunto de salidas que van a producirse y los procesos que
tengo que implantar. Siempre dependiendo de las
especificaciones marcadas por el cliente. (MER,MR,DFD)
Diseño: Consiste en responder a la siguiente pregunta: ¿Cómo
lo tenemos que hacer? Se trata de cómo los programas van a
conseguir los objetivos con los datos disponibles. (DE,DTE)
Codificación: Consiste en traducir los resultados del diseño a
un lenguaje de programación.
Pruebas: Consiste en verificar y validar la solución obtenida.
Existen pruebas unitarias, que comprueban el funcionamiento
de cada componente individual y pruebas de integración que
comprueban que componentes probados individualmente
funcionan bien de forma conjunta.
-
Mantenimiento: aquí me pregunto cómo se gestiona el cambio una vez que el
sistema está en explotación.
Mantenimiento Correctivo: Consiste en la corrección de errores
que aparezcan con el uso normal de los programas.
Mantenimiento Adaptativo: Consiste en modificar los programas
existentes, a causa de un cambio en el entorno físico y lógico en el
que están implantados.
Mantenimiento Perfectivo: Consiste en realizar mejoras y
ampliaciones que el cliente solicite sobre la aplicación.
Los tipos de mantenimiento adaptativo y perfectivo reinician el ciclo de vida.
4.-TIPOS DE CICLO DE VIDA DE UA APLICACIÓ IFORMÁTICA.
Ciclo de Vida Clásico
También es llamado ciclo de vida en cascada o "modelo de ciclo de vida tradicional".
Consiste en ir desarrollando cada una de las etapas secuencialmente, hasta la fase de
implantación del sistema. En este tipo de ciclo hay que esperar a que termine una etapa
para poder empezar la siguiente.
Definición
Análisis
Diseño
Codificación
Prueba
Mantenimiento
Este ciclo de vida está anticuado y es muy criticado porque no tiene vuelta atrás,
no se ve el producto hasta la etapa final (el usuario debe tener mucha paciencia) y
tampoco posibilita la realimentación. La secuencialidad no es real.
Ciclo de Vida en cascada con vuelta atrás
Introduce mejoras al ciclo anterior.
Definición
Análisis
Diseño
Codificación
Prueba
Mantenimiento
Este es el ciclo de vida más conocido y experimentado. En muchos casos, una
etapa del CV no puede ser completada del todo por falta de detalles en la definición del
problema. En estas situaciones, se hace necesario dejar dicha etapa sin terminar y pasar
a las siguientes, para regresar más tarde a completarla. En otras ocasiones, las
decisiones tomadas en etapas posteriores obligan a modificar otras ya dadas por
terminadas y definitivas. O bien se descubren errores en etapas ya superadas. Este ciclo
contempla la posibilidad de volver atrás desde cualquier etapa. También se le llama
ciclo de realimentación.
Ciclo de Refinamiento de Prototipos
FINAL
COMIENZO
Producto
ingeniería
Refinamiento
prototipo
Evaluación
prototipo
Recogida y
refinamiento de
requisitos
Diseño
rápido
Construcción
prototipo
Entendemos por prototipo un modelo evolutivo de la solución software final.
Poco a poco se irá refinando para adaptarlo a las necesidades del proyecto.
Dentro de los inconvenientes de este ciclo encontramos:
-
-
Posible incorporación al producto final de deficiencias asumidas en la
construcción del prototipo, ya que se continúa a partir del prototipo y no se
empieza de nuevo.
Ralentiza el proceso de desarrollo.
Se debe contar con la participación activa del cliente, mediante entrevistas,
sesiones de demostración,...etc.
Ventajas:
- Genera un producto más seguro, en cuanto a satisfacción de las necesidades del
cliente.
Ciclo de Vida en Espiral
Trata de aunar las ventajas de los modelos anteriores, incorporando el análisis de
riesgos, con lo que ganan importancia los factores económicos del proyecto.
Se distribuye en 4 etapas: Planificación, análisis de riesgos, ingeniería y
evaluación. Recibe su nombre por la forma circular y creciente en que se va pasando de
cada etapa a la siguiente: en cada vuelta del CV cada etapa es más compleja, comprende
más trabajo y consume más recursos (tiempo, dinero,...), pero está más cercana a la
solución final. De esta manera el proceso global de construcción del producto software
es claramente evolutivo (a la manera de los prototipos), mientras que en cada vuelta del
ciclo, este proceso es lineal (como el modelo en cascada).
Aquí el proyecto se comienza desde el primer instante, no como en el de prototipos.
Planificación
Análisis
de riesgo
Evaluación
del cliente
Ingeniería
El análisis de riesgo es una etapa donde nos preguntamos si es conveniente
seguir con el proyecto. Esto suele producirse a partir de la segunda versión.
En general:
Si el problema es perfectamente conocido,
en el que el usuario define claramente los
requisitos, y el equipo de desarrollo tiene
amplia experiencia en la cuestión
Si el desarrollo conlleva muchos riesgos
Si es importante ir probando el producto a
medida que se desarrolla para demostrarle
al usuario y al cliente su utilidad
CV en cascada
CV en espiral
CV basado en prototipos
En la vida real, no se da ninguna de estas situaciones en estado puro, sino mezcladas
entre sí. Por este motivo, el criterio y la experiencia de los jefes de proyecto y de los
analistas son cruciales para realizar una buena elección del tipo de ciclo de vida a
seguir.
5.-METODOLOGÍAS DE DESARROLLO DE SOFTWARE.
Definimos metodología como un conjunto de pasos y procedimientos, que deben
seguirse para el desarrollo del software.
Los enfoques metodológicos han ido evolucionando a lo largo del tiempo.
Inicialmente se identifica un período de desarrollo convencional, durante el cual las
prácticas de desarrollo eran totalmente artesanales y en el que no había metodologías
definidas, lo que acarreaba multitud de problemas.
Posteriormente surge el desarrollo estructurado partiendo de la programación
estructurada y que sigue con los métodos de análisis y diseño estructurado, hasta llegar
a metodologías estructuradas que cubren el ciclo de vida completo.
En la actualidad aparece el paradigma de la orientación a objetos, como un nuevo
enfoque en la ingeniería del software.
Desarrollo Convencional: en los años 50, no existían metodologías de
desarrollo. Las personas que desarrollaban los sistemas eran programadores más
enfocados en la tarea de codificar, que en la de recoger y comprender las
necesidades de los usuarios. Estos, a menudo, no quedaban satisfechos con el
sistema, porque sus necesidades no estaban definidas con claridad en una fase de
análisis previo. Ante esta perspectiva se vio la importancia del análisis y del
diseño en el desarrollo de un sistema. Ahora se empieza a hablar de analistas
programadores y analistas de sistemas.
Problemas:
1) Los resultados finales son impredecibles.
2) No hay forma de controlar lo que está sucediendo en el proyecto. El director de
proyecto, al no existir fases establecidas y productos intermedios concretos
sobre los que realizar verificaciones, no puede saber cuál es el estado actual del
proyecto; lo que influye en su toma de decisiones.
Esto lleva también a una detección tardía de defectos, que se pueden presentar
cuando se está probando el código o aún peor, cuando el sistema ya esté en
explotación, con lo que los costes se disparan.
Para controlar lo que está sucediendo en un proyecto, es necesario establecer
puntos de control donde se verifique que el desarrollo avanza de forma
adecuada; donde se confirme que los defectos detectados son corregidos y que
en su corrección no se produzcan nuevos errores.
3) Falta de documentación estandarizada y actualizada adecuadamente.
Desarrollo Estructurado: el nacimiento de las técnicas estructuradas se puede
considerar un punto de partida en el que se pasa de la construcción de programas
de forma artesanal, a una que sigue unos métodos de ingeniería, sentando las
bases para un desarrollo automatizado (herramientas CASE).
- Programación Estructurada: el enfoque de desarrollo estructurado
comenzó con la programación para determinar como se debía ver un programa
de forma que fuera lo más comprensible posible. Empieza a usarse a finales de
los 60. Consiste en establecer normas para la aplicación de las estructuras de
datos y de control.
⇒ Tipos de estructuras de control: secuencial, repetitiva (bucle), y alternativas.
⇒ Tipos de estructuras de datos: vectorial, matricial, listas,...
- Diseño Estructurado: a mediados de los 70, el enfoque estructurado se
extiende a la fase de diseño. Se define un nivel de abstracción más amplio
utilizando el módulo de programa como componente básico de construcción.
- Análisis Estructurado: hasta la aparición de los primeros conceptos
sobre el análisis estructurado, en la mayoría de los proyectos se hacía una
especificación narrativa de los requisitos tal y como los percibía el analista.
Estas especificaciones tenían varios problemas:
(1) Eran monolíticas, es decir había que leer la especificación de
requisitos completamente para poder entenderla.
(2) Eran redundantes, es decir, frecuentemente se repetía la
misma información en partes diferentes del documento. Esto implica que
si se cambia algún requisito del usuario, se debía modificar dicha
especificación en varios lugares, para evitar inconsistencias.
(3) Eran ambiguas, es decir, un informe detallado de los requisitos
se interpretaba de forma diferente por usuarios, analistas y diseñadores,
por esto se produce un movimiento gradual hacia las especificaciones
funcionales gráficas (aquellas compuesta por variedad de diagramas,
apoyados con técnicas textuales detalladas, que sirven de referencia a la
especificación. Ej: diagrama de flujo de datos), particionadas (aquellas
que permiten que se puedan leer porciones independientes de la
especificación) y mínimamente redundantes. Este enfoque se conoce
como análisis estructurado o también análisis descendente o Top-Down.
Desarrollo Orientado a Objetos: el paradigma orientado a objetos, a diferencia
del enfoque estructurado trata los procesos y los datos de forma conjunta, es
decir, modulariza tanto la información como el procesamiento. La orientación a
objetos empieza con los lenguajes de programación orientados a objetos; en
estos lenguajes los problemas del mundo real se representan como un conjunto
de objetos para los que se adjuntan un conjunto de operaciones. Ej: C++, Java.
En España, la metodología utilizada en la Administración pública es METRICA V3
(http://www.csi.map.es/csi/metrica3/). También existen otras para distintos países de
Europa como MERISSE en Francia y SSADM en el Reino Unido.