4.1 Proceso de Desarrollo de Software:
La complejidad en el software.
En un sistema, la complejidad es directamente proporcional al número de elementos involucrados y a la complejidad de cada elemento. La mayoría de las aplicaciones que son especificadas, desarrolladas, mantenidas y utilizadas por una sola persona no son complejas.
Por otro lado, las aplicaciones que forman parte del software de dimensión industrial exhiben un conjunto muy rico de comportamientos, y son propensas a tener un ciclo de vida muy largo.
Estas aplicaciones son complejas y no pueden ser desarrolladas por una sola persona. Su mantenimiento y su utilización también involucran a varios individuos.
La complejidad es parte esencial de los sistemas de software de gran tamaño. Se puede manejar, pero no se puede eliminar.
Según Grady Booch, la complejidad de los sistemas de software se deriva de cuatro elementos:
* La complejidad del dominio del problema.
* La complejidad del dominio del problema.
Los problemas que se intentan resolver son inherentemente complejos, con una gran cantidad de requisitos que compiten entre sí.
* La dificultad de gestionar el proceso de desarrollo.
* La dificultad de gestionar el proceso de desarrollo.
Los desarrolladores de software enfrentan el reto de dar a los usuarios la impresión de simplicidad, esto es reducir al mínimo la complejidad externa. Este reto les obliga a incrementar el tamaño de los sistemas, a inventar mecanismos ingeniosos, o a reutilizar diseños y código ya existentes.
* La flexibilidad que se puede alcanzar a través del software.
* La flexibilidad que se puede alcanzar a través del software.
La elaboración de software es una actividad muy laboriosa porque empuja al desarrollador a construir por sí mismo prácticamente todos los bloques fundamentales sobre los que se apoyan las abstracciones de más alto nivel. Esto es propiciado, en gran medida, por la existencia de pocos estándares para el control de calidad.
* Los problemas de caracterizar el comportamiento de sistemas discretos.
* Los problemas de caracterizar el comportamiento de sistemas discretos.
Los comportamientos de la mayoría de los objetos se representan por sistemas analógicos en los que, a través de funciones continuas, pequeños cambios en las entradas siempre producen pequeños cambios en las salidas.
Por el contrario, puesto que el software se ejecuta en computadoras digitales, se tienen sistemas con un número finito de estados discretos. En sistemas grandes, este número puede crecer a cantidades enormes. Como no existen herramientas matemáticas para modelar el comportamiento completo de los grandes sistemas discretos, se debe aceptar la pérdida de cierto grado de confianza en cuanto a que las salidas sean correctas
* El papel de la descomposición.
* El papel de la descomposición.
Desde tiempos remotos, el ser humano ha enfrentado la complejidad por medio de la descomposición de un gran problema original en problemas más y más pequeños.
Este precepto, que ha sido aplicado en diversos ámbitos, también se aplica en el diseño de sistemas de software complejos, descomponiéndolos hasta llegar a un nivel tal que puedan manejarse como problemas independientes.
Para manejar la descomposición es importante definir el criterio básico de descomposición eligiendo un modelo o paradigma.
* Descomposición algorítmica.
* Descomposición algorítmica.
En este proceso de descomposición cada módulo del sistema representa alguna parte de un proceso global, centrándose en la funcionalidad de los objetos y dejando aparte los datos que representan sus atributos.
La mayoría de los de los desarrolladores han sido adiestrados en el diseño estructurado descendente; y por eso suelen afrontar la descomposición como un proceso de descomposición algorítmica.
* Descomposición orientada a objetos
* Descomposición orientada a objetos
En este tipo de descomposición el problema no se resuelve centrándose en el código, sino que se modela como un conjunto de agentes autónomos, llamados objetos, que colaboran para generar la solución.
Cada objeto sabe realizar ciertas tareas que otros objetos, a través de mensajes, les piden realizar.
El criterio de descomposición orientado a objetos es mejor para ayudar a organizar la complejidad innata de los sistemas de software, porque modela mejor a los objetos del mundo real.
El papel de los recursos software en sistemas complejos
Blanchard define un sistema en la primera monografía de esta serie como: una combinación de recursos (como seres humanos, materiales, equipos, software, instalaciones, datos, entre otros.) integrados de forma tal que cumplan una función específica en respuesta a una necesidad designada de un usuario [1]. No sólo incluye los recursos utilizados directamente en el cumplimiento de la misión (esto es, equipo principal, software operativo, personal usuario), sino también los diferentes elementos del apoyo (como por ejemplo: equipos de apoyo y prueba, repuestos y requisitos relacionados de inventario, personal de mantenimiento e instalaciones).
Esta es una definición genérica que incluye todo tipo de sistemas. Desde sistemas en los que no existen «recursos software» hasta aquellos otros en los que ésos son los elementos fundamentales para conseguir la funcionalidad pretendida. Llamamos recurso software a un programa o conjunto de programas ejecutables que proporcione algunas de las funciones requeridas por el sistema.
Desde esta perspectiva tan amplia, un sistema se considerará como sistema de software cuando sus recursos software constituyan su elemento básico y la fuente de su funcionalidad básica. Dicho de otro modo, cuando en el proceso de desarrollo sean los recursos software los que determinan el proceso general de desarrollo de todo el sistema y cuando su ejecución pueda realizarse sobre una plataforma hardware genérica.
Conviene distinguir entre un sistema de software y un programa ejecutable. Siguiendo una definición clásica de Wirth, un programa es un algoritmo codificado junto con unas estructuras de datos. Algunas veces se emplea el término paquete ejecutable para referirse a un conjunto de programas que se necesitan mutuamente durante la ejecución del sistema y que deben distribuirse conjuntamente al usuario final.
Un sistema de software, por el contrario, es mucho más. Implica una interacción con el contexto al que sirve que constituye el referente básico de su utilidad. Un sistema de software posee programas ejecutables pero también otros tipos de recursos (ficheros de datos, de documentación, entre otro.).
Gran parte de los problemas que acechan a los diseñadores e implementadores actuales reside en que emplean durante el proceso de desarrollo una perspectiva limitada a los programas necesarios y no a una concepción sistémica del desarrollo del mismo ni del contexto social, humano y técnico que enmarca su ejecución.
Características relevantes de un sistema de software
Con el fin de clasificar a los sistemas de software hemos seleccionado un conjunto de características relevantes de los sistemas de software complejos. Las características consideradas son las siguientes:
* Tamaño: Que el tamaño condiciona el desarrollo de un sistema es algo que intuitivamente todos podemos suponer.El tamaño final del sistema de software ha sido también empleado para conocer los requisitos sobre la infraestructura de ejecución y/o comunicación y, por comparación con otros sistemas, aspectos de prestaciones en tiempos de ejecución.
No obstante lo anterior, en el desarrollo de un sistema de software en el que se hayan empleado generadores de código (programas especializados que, a partir de una especificación de muy alto nivel de lo que el usuario desea, son capaces de generar código fuente en un lenguaje de programación convencional) en el proceso de construcción, el tamaño no puede emplearse como una medida relativa del esfuerzo necesario. Si el código es parcialmente generado de forma automática, el esfuerzo del diseñador se desplaza hacia el diseño o la especificación de requisitos del sistema.
* Vida útil: Que los sistemas tengan larga vida hace que un porcentaje apreciable del esfuerzo y costes se desplacen desde las fases de desarrollo a las de mantenimiento o evolución del mismo.
* Información manipulada: Todo sistema de software necesita manipular información durante su ejecución; por información entendemos datos, texto, imágenes, entre otros. Que deban ser procesadas o transmitidas. En alguno de ellos, no obstante, el volumen de información necesario obliga a que la atención en el desarrollo se centre en su captura, almacenamiento estructurado, procesamiento y actualización.
Los sistemas complejos requieren que su arquitectura interna refleje la estructura de estos datos y los procedimientos de gestión de los mismos.
* Estructura interna: Un sistema de software posee una estructura interna en el que las funciones a realizar se agrupan en módulos u objetos con cierta interacción entre ellos. Los sistemas de software complejos suelen estar compuestos por módulos que operan concurrentemente entre sí y, en muchos casos, sus módulos se ejecutan en lugares geográficamente distantes.
Gran parte de los lenguajes de programación clásicos (estructurados) poseen un conjunto de construcciones cuya finalidad es determinar el orden de ejecución de las instrucciones. Todos ellos comparten la idea de que en cada momento sólo se ejecuta una instrucción. Esta restricción se ha trasladado a las técnicas de diseño limitando el modelado. En el caso de los sistemas de software complejos, la necesidad de disponer de módulos que actúen concurrentemente o de forma distribuida ya no es ocultable o prescindible. Los diseñadores deben disponer de técnicas que les permitan definir y controlar la concurrencia entre módulos del sistema o, incluso, entre subsistemas diferenciados asegurando que la interacción entre ellos se lleva a cabo coordinadamente en función del lugar en el que se ejecutarán.
* Prestaciones: De un sistema de software se espera que haga lo que tenga que hacer dentro de límites de tiempo preestablecidos o que sea capaz de manipular un volumen de información dado dentro de restricciones de espacio conocidas. Estos valores determinan las prestaciones del sistema En resumen, un sistema de software complejo suele ser grande, tener una vida útil muy larga, procesar una información rica y compleja, organizarse en módulos u objetos que operan concurrente y distribuidamente y requerir la satisfacción de prestaciones críticas
Ingeniería de los sistemas de Software
Es la aplicación de un enfoque sistemático, disciplinario y cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de enfoques, es decir, la aplicación de la ingeniería al software. es la aplicación de la ingeniería al software, ya que integra matemáticas, ciencias de la computación y practicas cuyos orígenes se encuentran en la ingeniería
Los modelos de ciclo de vida de software es una lista de actividades que ocurren durante el desarrollo de software, en el cual se intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas
Modelos del 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
Es la forma mediante la cual se describen los diferentes pasos que se deben seguir para el desarrollo de un software, partiendo desde la necesidad hasta llegar a la puesta en marcha de una solución y su apropiado mantenimiento. El ciclo de vida para un software comienza cuando se tiene la necesidad de resolver un problema, y termina cuando el programa que se desarrollo para cumplir con los requerimientos, deja de ser utilizados.
Existen varias versiones del ciclo de vida del software entre las cuales se destacan: el ciclo de vida clásico o en cascada, el modelo en espiral, el desarrollo de prototipos, el modelo por incrementos y el modelo extremo.
Etapas del ciclo de vida del software
El ciclo de vida clásico del software siendo uno de los más utilizados tal como lo plantean diferentes autores, está conformado en su versión ampliada por siete etapas que se pueden representar mediante un modelo en cascada así:
*Ingeniería de sistemas: En esta etapa el analista luego de un minucioso y detallado estudio de los sistemas de una organización, detecta un problema o una necesidad que para su solución y satisfacción es necesario realizar un desarrollo de software.
* Análisis: En esta etapa se debe entender y comprender de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal manera que se obtenga la información necesaria y suficiente para afrontar su respectiva solución
* Diseño: Una vez que se tiene la suficiente información del problema a solucionar, es importante determinar la estrategia que se va a utilizar para resolver el problema.
* Implementación: Partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programa que solucione el problema mediante el uso de una herramienta computacional determinada.
* Pruebas: Los errores humanos dentro de la programación de los computadores son muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor número de situaciones posibles a las que se pueda enfrentar.
* Documentación: Es la guía o comunicación escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa. La importancia de la documentación radica en que a menudo un programa escrito por una persona, es modificado por otra. Por ello la documentación sirve para ayudar a comprender o usar un programa o para facilitar futuras modificaciones (mantenimiento). La documentación se compone de tres partes:
Documentación Interna: Son los comentarios o mensajes que se añaden al código fuente para hacer más claro el entendimiento de los procesos que lo conforman.
Documentación Externa: Se define en un documento escrito con los siguientes puntos:
ü Descripción del Problema
ü Datos del Autor
ü Algoritmo (diagrama de flujo o Pseudocódigo)
ü Diccionario de Datos
ü Código Fuente (programa)
* Manual de Usuario: Describe paso a paso la manera como funciona el programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.
* Mantenimiento: Una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o satisfacer una determinada necesidad, es importante mantener una estructura de actualización, verificación y validación que permitan a dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil. Para realizar un adecuado mantenimiento, es necesario contar con una buena documentación del mismo.
Modelo en Cascada
El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a las fases siguientes:
Modelo de cascada ideal
El Modelo en espiral
El modelo en espiral, propuesto originalmente
por Boehm, es un modelo de proceso de software evolutivo que conjuga la
naturaleza iterativa de construcción de prototipos con los aspectos controlados
y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el
desarrollo rápido de versiones incrementales del software. En el modelo
espiral, el software se desarrolla en una serie de versiones incrementales.
Durante las primeras iteraciones, la versión incremental podría ser un modelo
en papel o un prototipo. Durante las últimas iteraciones, se producen versiones
cada vez más completas del sistema diseñado.
El modelo en espiral se divide en un número de
actividades de marco de trabajo, también llamadas regiones de tareas.
Generalmente, existen entre tres y seis regiones de tareas.
*Comunicación con el cliente: Las tareas requeridas para establecer
comunicación entre el desarrollador y el cliente.
*Planificación: Las tareas requeridas para definir recursos, el tiempo
y otra información relacionadas con el proyecto.
*Análisis de riesgos: Las tareas requeridas para evaluar riesgos
técnicos y de gestión.
*Ingeniería: Las tareas requeridas para construir una o más representaciones
de la aplicación.
*Construcción y acción: Las tareas requeridas para construir, probar,
instalar y proporcionar soporte al usuario (por ejemplo: documentación y
práctica).
*Evaluación del cliente: Las tareas requeridas para obtener la reacción
del cliente según la evaluación de las representaciones del software creadas
durante la etapa de ingeniería e implementada durante la etapa de instalación.
Cuando empieza este proceso evolutivo, el equipo de
ingeniería del software gira alrededor de la espiral en la dirección de las
agujas del reloj, comenzando por el centro. El primer circuito de la espiral
puede producir el desarrollo de una especificación de productos; los pasos
siguientes en la espiral se podrían utilizar para desarrollar un prototipo y
progresivamente versiones más sofisticadas del software. Cada paso por la
región de planificación produce ajustes en el plan del proyecto.
Características del modelo en espiral
Se caracteriza principalmente por:
*Un enfoque cíclico para el crecimiento
incremental del grado de definición e implementación de un sistema, mientras
que disminuye su grado de riesgo.
*Un conjunto de puntos de fijación para
asegurar el compromiso del usuario con soluciones de sistema que sean factibles
y mutuamente satisfactorias.
*Es considerado como un modelo evolutivo ya que
combina el modelo clásico con el diseño de prototipo
Modelo incremental
El modelo incremental combina elementos del modelo
en cascada con la filosofía interactiva de construcción de prototipos. Se basa
en la filosofía de construir incrementando las funcionalidades del programa.
Este modelo aplica secuencias lineales de forma escalonada mientras progresa el
tiempo en el calendario. Cada secuencia lineal produce un incremento del
software.
Cuando
se utiliza un modelo incremental, el primer incremento es a menudo un producto
esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega
de un producto operativo con cada incremento. Los primeros incrementos son
versiones incompletas del producto final, pero proporcionan al usuario la
funcionalidad que precisa y también una plataforma para la evaluación.
Ventajas
Entre
las ventajas que puede proporcionar un modelo de este tipo encontramos las
siguientes:
*Mediante
este modelo se genera software operativo de forma rápida y en etapas tempranas
del ciclo de vida del software.
*Es un
modelo más flexible, por lo que se reduce el coste en el cambio de alcance y
requisitos.
*Es más
fácil probar y depurar en una iteración más pequeña.
*Es más
fácil gestionar riesgos.
*Cada
iteración es un hito gestionado fácilmente
Inconvenientes
Para el uso de este modelo se requiere una
experiencia importante para definir los incrementos y distribuir en ellos las tareas
de forma proporcionada. Entre los inconvenientes que aparecen en el uso de este
modelo podemos destacar los siguientes:
*Cada fase de una iteración es rígida y no se
superponen con otras.
*Pueden surgir problemas referidos a la arquitectura
del sistema porque no todos los requisitos se han reunido, ya que se supone que
todos ellos se han definido al inicio
Modelos basados en Prototipos desechables e incremental
El Modelo Incremental combina elementos del
MLS con la filosofía interactiva de construcción de prototipos.
En una visión genérica, el proceso se
divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la
producción del Software, se usa el principio de trabajo en cadena o “Pipeline”,
utilizado en muchas otras formas de programación. Con esto se mantiene al
cliente en constante contacto con los resultados obtenidos en cada incremento.
Es el mismo cliente el que incluye o
desecha elementos al final de cada incremento a fin de que el software se
adapte mejor a sus necesidades reales. El proceso se repite hasta que se
elabore el producto completo.
De esta forma el tiempo de entrega se
reduce considerablemente.
Al igual que los otros métodos de
modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia
de aquellos en que al final de cada incremento se entrega un producto
completamente operacional.
El Modelo Incremental es
particularmente útil cuando no se cuenta con una dotación de personal
suficiente. Los primeros pasos los pueden realizar un grupo reducido de
personas y en cada incremento se añadir• personal, de ser necesario. Por otro
lado los incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí
en forma gráfica:
*Se evitan proyectos largos y se entrega
algo de valor a los usuarios con cierta frecuencia.
*El usuario se involucra más.
*Difícil de evaluar el coste total.
*Difícil de aplicar a los sistemas
transaccionales que tienden a ser integrados y a operar como un todo.
*Requiere gestores experimentados.
*Los errores en los requisitos se
detectan tarde.
*El resultado puede ser muy positivo.
Pipeline
La arquitectura en pipeline (basada en
filtros) consiste en ir transformando un flujo de datos en un proceso
comprendido por varias fases secuenciales, siendo la entrada de cada una la
salida de la anterior.
Esta arquitectura es muy común en el
desarrollo de programas para el intérprete de comandos, ya que se pueden
concatenar comandos fácilmente con tuberías (pipe).
También es una arquitectura muy natural
en el paradigma de programación funcional, ya que equivale a la composición de
funciones matemáticas.
4.2
Tecnología de Software:
Concepto
de Tecnología del software
Es
un conjunto integrado de notaciones, herramientas y métodos, basados en unos
sólidos fundamentos, que permiten el desarrollo de un producto software en un
contexto organizativo dado.
Una
tecnología de software puede considerarse constituida por los siguientes
componentes
Métodos
de desarrollo
Un
método aporta una forma sistemática de refinar las especificaciones de un
sistema haciendo que en cada paso se obtenga cierto nivel de confianza en que
el refinamiento efectuado sea correcto. Es este incremento en el nivel de
confianza, tanto a nivel individual como a nivel organizativo.
La
forma que un método tiene para lograr el objetivo de permitir incrementar la
confianza del diseñador es imponer una disciplina en el proceso de desarrollo
conjugando la utilización de una o varias notaciones y formas de razonar sobre
el sistema en desarrollo con un conjunto de directrices que guían al diseñador
en el proceso y generalmente apoyados por unas herramientas que soportan el
método. Sus objetivos concretos son:
Proponer
un procedimiento para capturar los requisitos del usuario y relacionarlos entre
sí para facilitar la comprobación de su consistencia.
Distribuir
el desarrollo entre un equipo de trabajo mediante la adecuada agrupación de
funciones en estructuras de diseño (objetos, módulos multifuncionales, entre
otros.).
Identificar
interfaces claras entre los componentes del sistema a diseñar (objetos,
módulos, entre otros.)
Proponer
una serie de heurísticos para guiar el refinamiento en varias etapas asegurando
la consistencia en cada uno de los pasos de refinamiento basados en la
experiencia de los proponentes del método en diseñar sistemas reales con el
mismo.
Herramientas de soporte: entornos de
desarrollo
Un
sistema de software cuya finalidad es la de ayudar a construir otros sistemas.
Desde este punto de vista lo que permite es mejorar la capacidad del ingeniero
de software en diversas fases del desarrollo.
Las
herramientas requeridas a lo largo del desarrollo son muy dispares.
Históricamente, las primeras que aparecen son editores para generar las
descripciones de los sistemas en algún lenguaje, compiladores para generar
código, depuradores para analizar las posibles fuentes de error, entre otros.
Todas ellas dedicadas a soportar la fase de implementación. Recientemente, han
surgido otras para soportar las fases iniciales del ciclo de vida.
Componentes
reutilizables
Son
módulos genéricos que pueden componerse para construir un sistema. Un diseño
basado en componentes de un catálogo conlleva, además, un problema de confianza
en la corrección de los módulos a utilizar; de ellos dependerá la corrección
del sistema final.
Es
interesante comentar en este caso la aparición en la ingeniería de sistemas de software
de un fenómeno bien conocido en la ingeniería de sistemas: el control de
calidad de las piezas es básico para obtener un producto de calidad. Cada vez
será más importante disponer de bibliotecas de calidad porque de ellas se
derivará la calidad del producto final.
Suscribirse a:
Entradas (Atom)
1 comentarios:
Muy bueno el análisis, aunque faltaron los modelos de sistemas automatizados.
Publicar un comentario