Unidad IV
Ingeniería del
Software
Introducción
Hoy
en día el software tiene un doble papel. Es un producto, pero simultáneamente
es el vehículo para hacer entrega de un producto. Como producto permite el uso
del hardware, ya sea, por ejemplo, un ordenador personal o un teléfono móvil
celular. Como vehículo utilizado para hacer entrega del producto, actúa como
base de control, por ejemplo un sistema operativo, o un sistema gestor de
redes. El software hace entrega de lo que se considera como el producto más
importante de siglo XXI, la información. El software transforma datos
personales para que sean más útiles en un entorno local, gestiona información
comercial para mejorar la competitividad, proporciona el acceso a redes a nivel
mundial, y ofrece el medio de adquirir información en todas sus formas.
Actualmente se considera la Ingeniería
del Software como
una nueva área de la ingeniería, y la profesión de ingeniero informático es una
de las más demandadas, aunque en España los salarios suelen ser bajos para la
cualificación de estos profesionales. La palabra ingeniería tiene una
connotación de prestigio que provoca que muchas ramas del conocimiento tiendan
a autodenominarse así.
Objetivo
Aplicar conceptos de
Ingeniería de Software enfatizando el proceso de Desarrollo y Tecnología de
Software.
Contenidos
v Proceso de Desarrollo de Software: La Complejidad de los Sistemas de Software. Recursos de Software
en sistemas Complejos. Características de los Sistemas de Software. Ingeniería
de los Sistemas de Software. Modelos de Ciclos de Vida: Análisis Comparativo.
Modelo en Cascada; Elementos, Características. Modelo Incremental; Modelos
basados en Prototipos desechables e incremental. Modelo del Sistema
Automatizado. Meta. Modelo en Espiral.
v Tecnología de Software: Conceptos.
Métodos de desarrollo de Herramientas de Soporte. Entornos de desarrollo.
Componentes reutilizables. Ejemplos. De Tecnologías de Software. Desarrollo
Estructurado y Orientado a Objetos.
MODELOS
DE DESARROLLO DEL SOTFWARE
Los modelos de desarrollo de software son una
representación abstracta de una manera en particular. Realmente no representa
cómo se debe desarrollar el software, sino de un enfoque común. Puede ser
modificado y adaptado de acuerdo a las necesidades del software en proceso de
desarrollo. 1 Hay
varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales
cuenta con pros y contras. El proyecto debería escoger el más apropiado para
sus necesidades. En ocasiones puede que una combinación de varios modelos sea
apropiado. Existen tres paradigmas de los modelos de
desarrollo de software:
Es uno de los paradigmas más antiguo, se inventó
durante la creación del método estructurado. Si se elige un proyecto, el método
varia en etapas. Como todo modelo, existen sus pros y contras al usar este
paradigma:
Si se
aplica este paradigma, unos de los principales problemas, es que las etapas
realizadas no son autónomas de las siguientes, creando una dependencia
estructural y en el acaso de un error atrasaría todo el proyecto. Se tiene que
tener pautas bien definidas, y que no se incurra a modificación porque
implicaría en que el software no cumpla con su ciclo de vida. Tener en cuenta
que el cliente no se vea afectado por la impaciencia.
·
Permite la re-utilización de software.
·
Facilita el desarrollo de herramientas informáticas
de apoyo al desarrollo, el cual es simple al implementarla en una notación orientada
a objetos llamado UML.
3. Paradigma de Desarrollo
Ágil: Es un paradigma de las Metodologías De Desarrollo basado
en procesos ágiles. Estos intentan evitar los tediosos caminos de las
metodologías tradicionales enfocándose en las personas y los resultados. Usa un
enfoque basado en el Valor para construir software, colaborando con el cliente
e incorporando los cambios continuamente.
Modelo de cascada
El modelo
de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:
1.
Especificación de requisitos
2.
Diseño del software
3.
Construcción
o Implementación del software
4.
Integración
5.
Pruebas (o validación)
6.
Despliegue (o instalación)
7.
Mantenimiento
Siguiendo
el modelo de cascada de forma estricta, sólo cuando se finaliza una fase,
comienza la otra. En ocasiones se realiza una revisión antes de iniciar la
siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir
un proceso de control formal de cambio). Las revisiones también se utilizan
para asegurar que la fase anterior ha sido totalmente finalizada; los criterios
para completar una fase se conocen frecuentemente con el término inglés
"gate" (puerta). Este modelo desaconseja revisitar y revisar fases
que ya se han completado. Esta falta de flexibilidad en un modelo de cascada
puro ha sido fuente de crítica de los defensores de modelos más flexibles.
Modelo de espiral
La
principal característica del modelo en espiral es la gestión de riesgos de
forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm,
combinando algunos aspectos clave de las metodologías del modelo de cascada y
del desarrollo rápido de aplicaciones,
pero dando énfasis en un área que para muchos no jugó el papel que requiere en
otros modelos: un análisis iterativo y concienzudo de los riesgos,
especialmente en el caso de sistema complejos de gran escala.
La
espiral se visualiza como un proceso que pasa a través de algunas interaciones
con el diagrama de los cuatro cuadrantes representativos de las siguientes
actividades:
1.
crear planes con el propósito de identificar los
objetivos del software, seleccionados para implementar el programa y clarificar
las restricciones en el desarrollo del software;
2.
Análisis de riesgos: una evaluación analítica de
programas seleccionados, para evaluar como identificar y eliminar el riesgo;
3.
la implementación del proyecto: implementación del
desarrollo del software y su pertinente verificación;
Modelo de
espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las
opciones y limitaciones para facilitar la reutilización de software, la calidad
del software puede ayudar como una meta propia en la integración en el
desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas
limitaciones, entre las que destacan:
1.
El énfasis se sitúa en el análisis de riesgo, y por
lo tanto requiere de clientes que acepten este análisis y actúen en
consecuencia. Para ello es necesaria confianza en los desarrolladores así como
la predisposición a gastar más para solventar los temas, por lo cual este
modelo se utiliza frecuentemente en desarrollo interno de software a gran
escala.
2.
Si la implementación del riesgo de análisis
afectará de forma esencial los beneficios del proyecto, no debería utilizarse
este modelo.
3.
Los desarrolladores de software han de buscar de
forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo
funcione.
La
primera fase es la búsqueda de un plan para conseguir los objetivos con las
limitaciones del proyecto para así buscar y eliminar todos los riesgos
potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo
la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el
cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante
ignorando los riesgos. Por último, se evalúan los resultados y se inicia el
diseño de la siguiente fase.
Desarrollo
iterativo e incremental
El desarrollo iterativo recomienda la construcción de secciones
reducidas de software que irán ganando en tamaño para facilitar así la
detección de problemas de importancia antes de que sea demasiado tarde. Los
procesos iterativos pueden ayudar a desvelar metas del diseño en el caso de
clientes que no saben cómo definir lo que quieren.
Desarrollo ágil
El
desarrollo ágil de software utiliza un desarrollo iterativo como base para
abogar por un punto de vista más ligero y más centrado en las personas que en
el caso de las soluciones tradicionales. Los procesos ágiles utilizan retroalimentación
en lugar de planificación, como principal mecanismo de control. La
retroalimentación se canaliza por medio de pruebas periódicas y frecuentes
versiones del software.
Hay
muchas variantes de los procesos ágiles:
·
En el caso de la programación extrema (XP), las fases
se realizan en pasos muy cortos (o "continuos") con respecto al
anterior. El primer paso (intencionalmente incompleto) por los pasos puede
ocurrir en un día o en una semana, en lugar de los meses o años de cada paso
completo en el modelo en cascada. En primer lugar, se crean pruebas
automatizadas para proveer metas concretas al desarrollo. Después se programa
el código, que será completo cuando todas las pruebas se superan sin errores, y
los desarrolladores ya no sabrían como mejorar el conjunto de pruebas
necesario. El diseño y la arquitectura emergen a partir de la refactorización del código, y se da
después de programar. El diseño lo realizan los propios desarrolladores del
código. El sistema, incompleto, pero funcional se despliega para su
demostración a los usuarios (al menos uno de los cuales pertenece al equipo de
desarrollo). Llegado este punto, los profesionales comienzan a escribir las
pruebas para la siguiente parte del sistema de más importancia.
Codificación y corrección
El
desarrollo de codificación y corrección (en inglés "Code and fix")
es, más que una estrategia predeterminada, el resultado de una falta de
experiencia o presión que se ejerce sobre los desarrolladores para cumplir con
una fecha de entrega. Sin dedicar tiempo de forma explícita para el diseño, los
programadores comienzan de forma inmediata a producir código.
Antes o después comienza la fase de pruebas de software (a menudo de forma
tardía) y los inevitables errores que
se encuentran han de eliminarse antes de poder entregar el software.
Orientado
a la Reutilización
La
reutilización de software es un proceso donde se recurre al uso de activos de
software en las especificaciones de análisis, diseños, implementación y pruebas
de una aplicación o sistemas de software.
La reutilización tiene ciertos Indicadores por ejemplo:
1. Entre
el 40% y 60% de una aplicación es re-utilizable en otra.
2.
Aproximadamente el 60% de una aplicación administrativa es re-utilizable.
3. Aproximadamente
el 75% de las funciones son comunes a más de un programa.
4. Solo
el 15% del código encontrado en muchos sistemas es único y novedoso a una
aplicación especifica.
El rango
general de uso recurrente esta entre el 15% y 85%.
La
reutilización tiene Principios como la existencia de parecidos
en distintos sistemas de un mismo dominio, donde el software puede
representarse como una combinación de módulos y los sistemas nuevos se puede
caracterizar por diferencias respecto a los antiguos sistemas.
Material Intruccional
Presman. McGraw Hill (1993) Introducción a la
Ingeniería de Software.
Yourdon
E. (1993) Análisis Estructurado Moderno Edit. Prentice Hall.
Estrategias de Evaluación
1. Realización de prueba escrita de los
temas: Proceso de Desarrollo de Software, Tecnología de Software.
