Embed Size (px)
Citation preview
REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR.
INSTITUTO UNIVERSITARIO DE TECNOLOGÍA DEL ESTADO BOLÍVAR
IV-INF-IM
FUNDAMENTOS DE LA INGENIERIA DEL SOFTWARE
.
Profesora: Bachiller:
Joel Poyo Jiménez Cis C.I. 18961206
Ciudad Bolívar, Junio de 2013
EL SOFTWARE
El software no es sólo código, sino también las especificaciones del diseño,
los datos tratados y la documentación que permite el desarrollo, instalación y
mantenimiento.
Estrictamente, se puede definir como:
1) Instrucciones que, cuando se ejecutan, proporcionan la funcionalidad
deseada.
2) Estructuras de datos que facilitan a las instrucciones manipular
adecuadamente la información.
3) Documentos que describen el desarrollo, uso, instalación y mantenimiento
de los programas.
Características del Software
1. Es un elemento lógico, no físico, en contraposición con el hardware.
2. Se desarrolla, no se fabrica.
3. No se estropea, se deteriora, con el tiempo, el hardware se va estropeando por la
presencia de componentes físicos el software, al carecer de ellos, se deteriora
CUALIDADES DEL SOFTWARE
Correcto
Confiable
Robusto
Eficiente
Amigable
Verificable
Reusable
Portable
Interoperable
Productivo
A Tiempo
Visible
Coheso
Desacoplado
Comprensible
Mantenible
FACTORES DE CALIDAD DEL SOFTWARE
La calidad del software La obtención de un software con calidad implica la
utilización de metodologías o procedimientos estándares para
el análisis,diseño, programación y prueba del software que permitan uniformar
la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y
facilidad de prueba, a la vez que eleven la productividad, tanto para la labor
de desarrollo como para el control de la calidad del software.
Los requisitos del software son la base de las medidas de calidad. La falta de
concordancia con los requisitos es una falta de calidad.
Los estándares o metodologías definen un conjunto de criterios de desarrollo que
guían la forma en que se aplica la ingeniería del software. Si no se sigue
ninguna metodología siempre habrá falta de calidad.
Existen algunos requisitos implícitos o expectativas que a menudo no se
mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un
buen mantenimiento) que también pueden implicar una falta de calidad.
La política establecida debe estar sustentada sobre tres principios básicos:
tecnológico, administrativo y ergonómico.
El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo
del software.
El principio administrativo contempla las funciones de planificación y control del
desarrollo del software, así como la organización del ambiente o centro de
ingeniería de software.
El principio ergonómico define la interfaz entre el usuario y el ambiente
automatizado.
La adopción de una buena política contribuye en gran medida a lograr la calidad
del software, pero no la asegura. Para el aseguramiento de la calidad es necesario
su control o evaluación.
A partir del siguiente gráfico se observa la interrelación existente entre la Gestión
de la Calidad, el Aseguramiento de la Calidad y el Control de la Calidad.
La gestión de la calidad
Gestión de la calidad: "Aspectos de la función de gestión que determinan y
aplican la política de la calidad, los objetivos y las responsabilidades y que lo
realiza con medios tales como la planificación de la calidad, el control de la
calidad, la garantía de calidad y la mejora de la calidad".
Dentro de la gestión de la calidad se observa:
Gestión de la calidad de software (ISO 9000): Conjunto de actividades de
la función general de la dirección que determina la calidad, los objetivos y
las responsabilidades y se implanta por medios tales como la planificación
de la calidad, el control de la calidad, el aseguramiento (garantía) de la
calidad y la mejora de la calidad, en el marco del sistema de calidad
Política de calidad (ISO 9000): Directrices y objetivos generales de una
organización, relativos a la calidad, tal como se expresan formalmente por
la alta dirección.
La gestión de la calidad se aplica normalmente a nivel de empresa. También
puede haber una gestión de calidad dentro de la gestión de cada proyecto.
El aseguramiento de la calidad
Ante todo se debe conocer:
Aseguramiento de la calidad: "Conjunto de acciones planificadas y
sistemáticas necesarias para proporcionar la confianza adecuada de que
un producto o servicio satisfará los requerimientos dados sobre calidad".
Aseguramiento de la calidad de software: Conjunto de actividades
planificadas y sistemáticas necesarias para aportar la confianza en que el
producto (software) satisfará los requisitos dados de calidad.
El aseguramiento de calidad del software se diseña para cada aplicación antes de
comenzar a desarrollarla. Hay quienes prefieren decir garantía de calidad en vez
de aseguramiento.
La garantía, puede confundir con garantía de productos, mientras que el
aseguramiento pretende dar confianza en que el producto tiene calidad.
El aseguramiento de calidad del software está presente en:
Métodos y herramientas de análisis, diseño, programación y prueba.
Inspecciones técnicas formales en todos los pasos del proceso de
desarrollo del software.
Estrategias de prueba multiescala.
Control de la documentación del software y de los cambios realizados.
Procedimientos para ajustarse a los estándares (y dejar claro cuando se
está fuera de ellos).
Mecanismos de medida (métricas).
Registro de auditorias y realización de informes.
Las actividades para el aseguramiento de calidad del software se detallan en:
Métricas de software para el control del proyecto.
Verificación y validación del software a lo largo del ciclo de vida (Incluye
las pruebas y los procesos de revisión e inspección).
La gestión de la configuración del software.
Algunos métodos del aseguramiento:
Revisiones técnicas y de gestión (su objetivo es la evaluación).
Inspección (su objetivo es la verificación). ¿Estamos construyendo el
producto correcto?.
Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto
correctamente?.
Auditorias (su objetivo es la confirmación del cumplimiento).
El control de la calidad
Se debe conocer:
Control de calidad: "Conjunto de técnicas y actividades
de carácter operativo, utilizadas para verificar los requerimientos relativos a
la calidad del producto o servicio".
Control de la calidad del software: Técnicas y actividades de carácter
operativo, utilizadas para verificar los requisitos relativos a la calidad,
centradas en mantener bajo control el proceso de desarrollo y eliminar las
causas de los defectos en las diferentes fases del ciclo de vida.
El control de la calidad del software está centrado en dos objetivos fundamentales:
Mantener bajo control un proceso.
Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
En general, se puede decir que el control de de la calidad del software son las
actividades para evaluar la calidad de los productos desarrollados.
Las estrategias de trabajo se representan como sigue:
INGENIERÍA DEL SOFTWARE
La Ingeniería del Software es una disciplina que integra métodos, técnicas y
herramientas para el desarrollo de software de computadora.
Ingeniería
Es la aplicación sistemática de conocimiento científico para la creación y
construcción de soluciones rentables a problemas prácticos al servicio de la
humanidad.
Sus elementos son:
Herramientas: Programas que mecanizan los métodos y las técnicas.
Métodos: Conjunto de tareas ordenadas para conseguir un fin. Los métodos se
desarrollaron para cada una de las fases del desarrollo (análisis, diseño,
implementación, etc.).
Técnicas: Ayudan con las dificultades para llevar a cabo lo que se indica en los
métodos.
Objetivos de la ingeniería de software
mejorar la calidad de los productos de software
aumentar la productividad y trabajo de los ingenieros del software.
Facilitar el control del proceso de desarrollo de software.
Suministrar a los desarrolladores las bases para construir software de alta calidad
en una forma eficiente.
Definir una disciplina que garantice la producción y el mantenimiento de los
productos software desarrollados en el plazo fijado y dentro del costo estimado.
VISIÓN GENERAL DEL PROCESO DE LA INGENIERÍA DEL SOFTWARE
El ciclo de vida del software se divide en varias fases desde que nace hasta que
muere:
Planificación: Se identica el proyecto, se le da nombre y se dene el alcance.
Desarrollo: Se desarrolla e implanta.
Mantenimiento: Desde que se implanta hasta que se abandona.
Fase de planificación
Se realiza un inventario de todas las actividades que se realizan en una empresa y
se agrupan por proyectos estableciendo una correspondencia entre éstos y las
áreas organizativas.
También se discute la arquitectura hardware, la topología de red, el lenguaje de
programación, etc., y se da una prioridad a cada proyecto.
Se concluye con un documento denominado Plan de Sistemas de Información.
Como anotación, se puede comentar que no se encuentra entre las normas ISO
debido a que se realiza una vez cada períodos muy grandes de tiempo (una vez
cada década o incluso más).
Fase de desarrollo
Se llevan a cabo las tareas hasta tener el proyecto funcionando. Conlleva varias
actividades: análisis, diseño, construcción, pruebas e implantación.
Fase de mantenimiento
Su objetivo es la obtención de una nueva versión de un sistema debido a
peticiones de cambio que los usuarios realizan por un problema detectado, o por
la necesidad de una mejora del mismo, para acomodarlo a los cambios de su
entorno externo o para conseguir una mayor adecuación a los requisitos, mayor
eciencia, o simplemente recoger nuevas funcionalidades no expresadas en la fase
de denición del sistema.
Comprende el mantenimiento:
Correctivo: Cambia el software para corregir los defectos.
Evolutivo: Introduce mejoras en el software.
Adaptativo: Modica el software para acomodarlo a los cambios de su entorno
externo.
Perfectivo: Lleva al software más allá de sus requisitos funcionales originales.
CICLO DE VIDA DEL SOFTWARE
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se
mueve un proyecto de desarrollo de software.
Fases del ciclo de vida:
Fase I - Requerimientos
Elaborar una especificación completa y validada de las funciones requeridas
Fase II - Análisis / Diseño
Análisis:
El propósito es conocer exactamente cómo trabaja el sistema actual, determinar y
documentar qué debe hacer el sistema y recomendar las posibles soluciones.
Diseño:
El propósito de esta fase es desarrollar un diseño (cómo va a quedar) del sistema
de información que satisfaga todos los requisitos documentados. Se determina
qué va a hacer el sistema. Se identifican las entradas (Input), salidas (Output),
archivos, programas, procedimientos y controles del sistema.
Actividades dentro de la fase de Análisis/Diseño.
· Analizar y Diseñar Proceso: Las operaciones y los requerimientos de
funcionamiento definidos en la primera fase, se toman en cuenta con el propósito
de determinar la forma en que debe funcionar el sistema.
· Analizar y Diseñar Los Datos: Con los requerimientos de información definidos
en la fase I se debe organizar los distintos modelos de datos que nos ayuden a
diseñar la base de datos que hagan falta para que el sistema funcione de acuerdo
al modelo de funcionamiento.
· Diseñar y Organizar Los Componentes Físicos: Todo componente físico como
(pantallas, base de datos) que hagan posible el funcionamiento del sistema de
acuerdo al modelo de funcionamiento.
· Planificar El Desarrollo De Los Componentes Físicos: actividad en la cual
planificamos la forma en que pueden ser construidos e implementados los
componentes físicos de una forma rápida y productiva.
En esta fase de análisis / diseño puede incluirse una sub.-fase de evaluación de
paquetes. Esta se pudiese realizar si en los requerimientos se estableció adquirir
un paquete de aplicaciones en lugar de completar un diseño arquitectónico.
Fase III – Construcción
Dentro de esta fase de construcción existen actividades separadas en cinco sub.-
fases:
• Desarrollo de infraestructura
Durante esta fase se desarrollará y organizará la infraestructura que permita
cumplir las tareas de construcción en la forma más productiva posible.
• Adaptación de paquete
Uno de los objetivos centrales de esta subfase es conocer al máximo detalle
posible el funcionamiento del paquete, este asegurará que el paquete será
utilizado con el máximo provecho, tanto desde el punto de vista del negocio, como
de la utilización de recursos. Cada componente del paquete será revisado en
forma exhaustiva por el equipo Analista – Usuario, con el fin de conocer y
comprender todos los aspectos del paquete.
• Desarrollo de unidades de diseño interactivas
Las unidades de diseño interactivas, son procedimientos que se cumple o se
ejecutan a través de un dialogo usuario – sistema.
Las actividades de esta subfase tienen como objetivo central:
• Especificar en detalle las tareas que debe cumplir la unidad de diseño
• Desarrollar componentes
• Realizar las pruebas unitarias y las pruebas de integración a nivel de la unidad
de diseño.
• Desarrollo de unidades de diseño batch
En esta sub.-fase se preparan especificaciones hechas utilizando una
combinación de técnicas como flujo gramas, diagramas de estructuras, tablas de
decisiones etc. Cualquiera que se utilice será útil para que la especificación sea
clara y se logre el propósito de que el programador comprenda y pueda programar
y probar los programas correspondientes.
• Desarrollo de unidades de diseño manuales
Las actividades de esta subfase tienen como objetivo central desarrollar todos los
procedimientos administrativos que rodearán y gobernarán la utilización de los
componentes computarizados desarrollados en la fase de diseño detallado y
construcción.
Fase IV – Pruebas
Esta fase, da inicio luego de que las diferentes unidades de diseño han sido
desarrolladas y probadas por separado. Durante su desarrollo, el sistema se
emplea de forma experimental para asegurar que el software no falle, es decir que
funcione deacuerdo a sus especificaciones y a la manera que los usuarios
esperan que lo haga, y de esta forma poder detectar cualquier anomalía, antes de
que el sistema sea puesto en marcha y se dependa de el. Para evaluar el
desenvolvimiento del sistema, en esta fase se llevan a cabo varios niveles de
prueba:
• Funcional: Prueba desde el punto de vista de los requerimientos funcionales.
• De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema
y de desempeño.
• De Integración: Prueba de interfaces.
• De Aceptación Técnica: Prueba de manejo de condiciones extremas.
Si el Sistema cumple de forma satisfactoria con estos niveles mencionados
anteriormente, se procede a realizar la carga de los archivos, base de datos y
tablas del nuevo sistema, para de esta forma dar inicio al proceso de aceptación
final, durante el cual, el sistema comenzará a funcionar bajo la responsabilidad del
departamento de operaciones y del usuario, por un lapso determinado de tiempo
llamado Periodo de Aceptación.
Finalizado el Periodo de Aceptación, se le dará al sistema la aprobación final, para
que pase a ser el sistema oficial.
Fase V - Producción / Mantenimiento
“Una vez que un sistema pasa a formar parte de la vida diaria de la empresa o
institucion, cada programa, cada procedimiento y cada estructura de datos se
convierte en una pieza del negocio que, como tal, deberá funcionar en forma
constante, exacta y confiable. L a operación del negocio ahora dependerá del
funcionamiento del sistema, por lo que las tareas de mantenimiento cobran vital
importancia.
Durante la fase de mantenimiento, se ponen en práctica todas las políticas y los
procedimientos destinados a garantizar la operación continúa de los de los
sistemas y a asegurar su uso efectivo, con el fin, de que éstos se constituyan en
una verdadera herramienta de apoyo al logro de los objetivos estratégicos de la
empresa
FUNDAMENTACION TEORICA
Paradigmas de programación
Existe una infinidad de definiciones de lo que es un paradigma. Un paradigma es
un determinado marco desde el cual miramos el mundo, lo comprendemos, lo
interpretamos e intervenimos sobre él. Abarca desde el conjunto de conocimientos
científicos que imperan en una época determinada hasta las formas de pensar y
de sentir de la gente en un determinado lugar y momento histórico.
Adam Smith define paradigma, en su libro “Los poderes de la mente”, como
“un conjunto compartido de suposiciones. Es la manera como percibimos el
mundo: agua para el pez. El paradigma nos explica el mundo y nos ayuda a
predecir su comportamiento".
En nuestro contexto, el paradigma debe ser concebido como una forma aceptada
de resolver un problema en la ciencia, que más tarde es utilizada como modelo
para la investigación y la formación de una teoría. También, el paradigma debe ser
concebido como un conjunto de métodos, reglas y generalizaciones utilizadas
conjuntamente por aquellos entrenados para realizar el trabajo científico de
investigación.
En nuestro contexto, los paradigmas de programación nos indican las diversas
formas que, a lo largo de la evolución de los lenguajes, han sido aceptadas como
estilos para programar y para resolver los problemas por medio de una
computadora.
Se muestran a continuación un resumen de los paradigmas de uso más extendido
en programación.
Programación por procedimientos
Es el paradigma original de programación y quizá todavía el de uso más común.
En él, el programador se concentra en el procesamiento, en el algoritmo requerido
para llevar a cabo el cómputo deseado.
Los lenguajes apoyan este paradigma proporcionando recursos para pasar
argumentos a las funciones y devolviendo valores de las funciones. FORTRAN es
el lenguaje de procedimientos original, Pascal y C son inventos posteriores que
siguen la misma idea. La programación estructurada se considera como el
componente principal de la programación por procedimientos.
Programación modular
Con los años, en el diseño de programas se dio mayor énfasis al diseño de
procedimientos que a la organización de la información. Entre otras cosas esto
refleja un aumento en el tamaño de los programas. La programación modular
surge como un remedio a esta situación. A menudo se aplica el término módulo a
un conjunto de procedimientos afines junto con los datos que manipulan. Así, el
paradigma de la programación modular consiste en:
a) Establecer los módulos que se requieren para la resolución de un problema.
b) Dividir el programa de modo que los procedimientos y los datos queden
ocultos en módulos.
Este paradigma también se conoce como principio de ocultación de
procedimientos y datos. Aunque C++ no se diseño específicamente para
desarrollar la programación modular, su concepto de clase proporciona apoyo
para el concepto de módulo.
Abstracción de datos
Los lenguajes como ADA y C++ permiten que un usuario defina tipos que se
comporten casi de la misma manera que los tipos definidos por el lenguaje. Tales
tipos de datos reciben a menudo el nombre de tipos abstractos o tipos definidos
por el usuario. El paradigma de programación sobre este tipo de datos consiste
en:
a) Establecer las características de los tipos de datos abstractos se desean
definir.
b) Proporcionar un conjunto completo de operaciones válidas y útiles para cada
tipo de dato.
Metodologías para desarrollo de software
Un proceso de software detallado y completo suele denominarse “Metodología”.
Las metodologías se basan en una combinación de los modelos de proceso
genéricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodología
debería definir con precisión los artefactos, roles y actividades involucrados, junto
con prácticas y técnicas recomendadas, guías de adaptación de la metodología al
proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza
el término “método” para referirse a técnicas, notaciones y guías asociadas, que
son aplicables a una (o algunas) actividades del proceso de desarrollo, por
ejemplo, suele hablarse de métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido
a la diversidad de propuestas y diferencias en el grado de detalle, información
disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como
criterio las notaciones utilizadas para especificar artefactos producidos en
actividades de análisis y diseño, podemos clasificar las metodologías en dos
grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por
otra parte, considerando su filosofía de desarrollo, aquellas metodologías con
mayor énfasis en la planificación y control del proyecto, en especificación precisa
de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o
peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras
metodologías, denominadas Metodologías Ágiles, están más orientadas a la
generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de
desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al
trabajo en equipo e involucran activamente al cliente en el proceso. A continuación
se revisan brevemente cada una de estas categorías de metodologías.
Metodologías estructuradas
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas
para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente
para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías
son particularmente apropiadas en proyectos que utilizan para la implementación
lenguajes de 3ra y 4ta generación.
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE
(Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas
de métodos estructurados en el ámbito académico: Gane & Sarson , Ward &
Mellor , Yourdon & DeMarco e Information Engineering .
Metodologías orientadas a objetos
Su historia va unida a la evolución de los lenguajes de programación orientada a
objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s
Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y
actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a
consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea
de conseguir una unificación de sus métodos y notaciones, que posteriormente se
reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language
(UML) , la notación OO más popular en la actualidad.
Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch),
OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la notación UML son:
Rational Unified Process (RUP) , OPEN , MÉTRICA (que también soporta la
notación estructurada).
Metodologías tradicionales (no ágiles)
Las metodologías no ágiles son aquellas que están guiadas por una fuerte
planificación durante todo el proceso de desarrollo; llamadas también
metodologías tradicionales o clásicas, donde se realiza una intensa etapa de
análisis y diseño antes de la construcción del sistema.
Todas las propuestas metodológicas antes indicadas pueden considerarse como
metodologías tradicionales. Aunque en el caso particular de RUP, por el especial
énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto
(mediante su configuración previa a aplicarse), realizando una configuración
adecuada, podría considerarse Ágil.
Metodologías ágiles
Un proceso es ágil cuando el desarrollo de software es incremental (entregas
pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores
trabajan juntos constantemente con una cercana comunicación), sencillo (el
método en sí mismo es fácil de aprender y modificar, bien documentado), y
adaptable (permite realizar cambios de último momento)
Entre las metodologías ágiles identificadas en :
• Extreme Programming
• Scrum
• Familia de Metodologías Crystal
• Feature Driven Development
• Proceso Unificado Rational, una configuración ágil
• Dynamic Systems Development Method
Modelos de proceso software
Sommerville define modelo de proceso de software como “Una representación
simplificada de un proceso de software, representada desde una perspectiva
específica. Por su naturaleza los modelos son simplificados, por lo tanto un
modelo de procesos del software es una abstracción de un proceso real.”
Los modelos genéricos no son descripciones definitivas de procesos de software;
sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar
diferentes enfoques del desarrollo de software.
Modelos que se van a discutir a continuación:
Codificar y corregir
Modelo en cascada
Desarrollo evolutivo
Desarrollo formal de sistemas
Desarrollo basado en reutilización
Desarrollo incremental
Desarrollo en espiral
Codificar y corregir (Code-and-Fix)
Este es el modelo básico utilizado en los inicios del desarrollo de software.
Contiene dos pasos:
Escribir código.
Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de
requisitos, diseño, validación, y mantenimiento.
Este modelo tiene tres problemas principales:
Después de un número de correcciones, el código puede tener una muy mala
estructura, hace que los arreglos sean muy costosos.
Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades
del usuario, por lo que es rechazado o su reconstrucción es muy cara.
El código es difícil de reparar por su pobre preparación para probar y modificar.
Modelo en cascada
El primer modelo de desarrollo de software que se publicó se derivó de otros
procesos de ingeniería [8]. Éste toma las actividades fundamentales del proceso
de especificación, desarrollo, validación y evolución y las representa como fases
separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos: Los servicios, restricciones y objetivos son
establecidos con los usuarios del sistema. Se busca hacer esta definición
en detalle.
2. Diseño de software: Se particiona el sistema en sistemas de software o
hardware. Se establece la arquitectura total del sistema. Se identifican y
describen las abstracciones y relaciones de los componentes del sistema.
3. Implementación y pruebas unitarias: Construcción de los módulos y
unidades de software. Se realizan pruebas de cada unidad.
4. Integración y pruebas del sistema: Se integran todas las unidades. Se
prueban en conjunto. Se entrega el conjunto probado al cliente.
5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema
es puesto en marcha y se realiza la corrección de errores descubiertos. Se
realizan mejoras de implementación. Se identifican nuevos requisitos.
La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como
resultado documentos que deben ser aprobados por el usuario.
Una fase no comienza hasta que termine la fase anterior y generalmente se
incluye la corrección de los problemas encontrados en fases previas.
En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción
entre las distintas fases de desarrollo. Algunos problemas que se observan en el
modelo de cascada son:
Las iteraciones son costosas e implican rehacer trabajo debido a la producción
y aprobación de documentos.
Aunque son pocas iteraciones, es normal congelar parte del desarrollo y
continuar con las siguientes fases.
Los problemas se dejan para su posterior resolución, lo que lleva a que estos
sean ignorados o corregidos de una forma poco elegante.
Existe una alta probabilidad de que el software no cumpla con los requisitos del
usuario por el largo tiempo de entrega del producto.
Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es
difícil responder a cambios en los requisitos.
Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se
utiliza como parte de proyectos grandes.
Desarrollo evolutivo
La idea detrás de este modelo es el desarrollo de una implantación del sistema
inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que
se desarrolle el sistema adecuado. En la Figura 6 se observa cómo las actividades
concurrentes: especificación, desarrollo y validación, se realizan durante el
desarrollo de las versiones hasta llegar al producto final.
Una ventaja de este modelo es que se obtiene una rápida realimentación del
usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan
en cada iteración.
Existen dos tipos de desarrollo evolutivo:
Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario
los requisitos hasta llegar a un sistema final. El desarrollo comienza con las
partes que se tiene más claras. El sistema evoluciona conforme se añaden
nuevas características propuestas por el usuario.
Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario
y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo
exploratorio, se comienza por definir los requisitos que no están claros para el
usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda
a terminar de definir estos requisitos.
Entre los puntos favorables de este modelo están:
La especificación puede desarrollarse de forma creciente.
Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto
se refleja en una mejora de la calidad del software.
Es más efectivo que el modelo de cascada, ya que cumple con las necesidades
inmediatas del cliente.
Desde una perspectiva de ingeniería y administración se identifican los siguientes
problemas:
Proceso no Visible: Los administradores necesitan entregas para medir el
progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir
documentos que reflejen cada versión del sistema.
Sistemas pobremente estructurados: Los cambios continuos pueden ser
perjudiciales para la estructura del software haciendo costoso el mantenimiento.
Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan
herramientas que pueden ser incompatibles con otras o que poca gente sabe
utilizar.
Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de
código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su
desarrollo y sin generar documentación para cada versión.
Para proyectos largos es mejor combinar lo mejor del modelo de cascada y
evolutivo: se puede hacer un prototipo global del sistema y posteriormente
reimplementarlo con un acercamiento más estructurado. Los subsistemas con
requisitos bien definidos y estables se pueden programar utilizando cascada y la
interfaz de usuario se puede especificar utilizando un enfoque exploratorio.
Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a
un programa ejecutable.
La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación
automática. Se distinguen dos fases globales: especificación (incluyendo
validación) y transformación. Las características principales de este paradigma
son: la especificación es formal y ejecutable constituye el primer prototipo del
sistema), la especificación es validada mediante prototipación. Posteriormente, a
través de transformaciones formales la especificación se convierte en la
implementación del sistema, en el último paso de transformación se obtiene una
implementación en un lenguaje de programación determinado. , el mantenimiento
se realiza sobre la especificación (no sobre el código fuente), la documentación es
generada automáticamente y el mantenimiento es realizado por repetición del
proceso (no mediante parches sobre la implementación).
Observaciones sobre el desarrollo formal de sistemas:
Permite demostrar la corrección del sistema durante el proceso de
transformación. Así, las pruebas que verifican la correspondencia con la
especificación no son necesarias.
Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y
confiabilidad importantes.
Requiere desarrolladores especializados y experimentados en este proceso
para llevarse a cabo.
Desarrollo basado en reutilización
Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización.
Este modelo consta de 4 fases ilustradas en la Figura 9. A continuación se
describe cada fase:
1. Análisis de componentes: Se determina qué componentes pueden ser utilizados
para el sistema en cuestión. Casi siempre hay que hacer ajustes para
adecuarlos.
2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para
concordar con los componentes de la etapa anterior. Si no se puede realizar
modificaciones en los requisitos, hay que seguir buscando componentes más
adecuados (fase 1).
3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo
para el sistema. Se debe tener en cuenta los componentes localizados en la
fase 2 para diseñar o determinar este marco.
4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se
integran los componentes y subsistemas. La integración es parte del desarrollo
en lugar de una actividad separada.
Las ventajas de este modelo son:
Disminuye el costo y esfuerzo de desarrollo.
Reduce el tiempo de entrega.
Disminuye los riesgos durante el desarrollo.
Desventajas de este modelo:
Los “compromisos” en los requisitos son inevitables, por lo cual puede que el
software no cumpla las expectativas del cliente.
Las actualizaciones de los componentes adquiridos no están en manos de los
desarrolladores del sistema.
Procesos iterativos
A continuación se expondrán dos enfoques híbridos, especialmente diseñados
para el soporte de las iteraciones:
Desarrollo Incremental.
Desarrollo en Espiral.
Desarrollo incremental
Mills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir la
repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la
toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver
Figura 10). Es una combinación del Modelo de Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para
retrasar las decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o
evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a
implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es
dudoso, evolutivo.
Entre las ventajas del modelo incremental se encuentran:
Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema.
Pueden empezar a usarlo desde el primer incremento.
Los clientes pueden aclarar los requisitos que no tengan claros conforme ven
las entregas del sistema.
Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede
distribuir en cada incremento.
Las partes más importantes del sistema son entregadas primero, por lo cual se
realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000
líneas).
Cada incremento debe aumentar la funcionalidad.
Es difícil establecer las correspondencias de los requisitos contra los
incrementos.
Es difícil detectar las unidades o servicios genéricos para todo el sistema.
Desarrollo en espiral
El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los más
conocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa
como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva
de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del
proceso y del producto. Se realiza un diseño detallado del plan administrativo.
Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de
estos.
2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada
riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de
requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.
3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la
evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales,
evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente
fase del proyecto.
Este modelo a diferencia de los otros toma en consideración explícitamente el
riesgo, esta es una actividad importante en la administración del proyecto.
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las
restricciones se determinan distintas alternativas. Se identifican los riesgos al
sopesar los objetivos contra las alternativas. Se evalúan los riesgos con
actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un
poco el sistema. Se planifica la siguiente fase.
REFERENCIAS
Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.
Naur P., Randell B., Software Engineering: A Report on a Conference Sponsored
by the NATO Scienc, 1969.
Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de
Software, Addison Wesley 2000.
Sommerville, I., Ingeniería de Software, Pearson Educación, 2002.
Letelier, P., Proyecto Docente e Investigador, DSIC, 2003.
Beck, K., Una explicación de la Programación Extrema. Aceptar el cambio,
Pearson Educación, 2000.
Boehm, B. W., A Spiral Model of Software Develpment and Enhancement, IEEE
Computer ,1988.
Royce, W., Managing the developmento of large software systems: concepts and
technique, IEEE Westcon, 1970.
Mills, H., O´Neill, D., The Management of Software Engineering, IBM Systems,
1980.
Laboratorio Ing. Soft., Ingeniería de software 2, Departamento de Informática,
2002.
Abrahamsson, P., Salo, O., Ronkainen, J., Agile Software Development Methods.
Review and Analysis, VTT, 2002.
Schwaber, K., Scrum Development Process. Workshop on Business Object Design
and Implementation, OOPSLA´95, 1995.
