4.1 Ciclo de vida del desarrollo del software.

El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción define le alcance del proyecto y desarrolla un caso de negocio. La elaboración define un plan del proyecto, especifica las características y fundamenta la arquitectura. La construcción crea el producto y la transición transfiere el producto a los usuarios.
Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de información. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO. El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnología OO. Una de las especificaciones más importantes es la adopción en 1998 del Lenguaje de Modelado Unificado o UML (del inglés Unified Modeling Language) como un estándar, que junto con el Proceso Unificado están consolidando la tecnología OO.

4.2 Requerimientos.

Alternativas de Modelos de Ciclo de Vida

Modelo Cascada

Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuye a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación.

El modelo de ciclo de vida cascada, captura algunos principios básicos:

• Planear un proyecto antes de embarcarse en él.

• Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.

• Documentar los resultados de cada actividad.

• Diseñar un sistema antes de codificarlo.

• Testear un sistema después de construirlo.

Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.

4.3 Análisis.

Definición de un Modelo de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

• Describe las fases principales de desarrollo de software.

• Define las fases primarias esperadas de ser ejecutadas durante esas fases.

• Ayuda a administrar el progreso del desarrollo, y

• Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

4.4 Diseño.

Principios básicos de diseño
•El diseñador debe considerar enfoques alternativosjuzgando a cada uno en base a los requisitos del problema, los resultados disponibles y los criterios de calidad interna
•Se deberían poder seguir los pasos de diseño hasta el modelo de análisis
•El diseño no va a reinventar nada que ya esté inventado
•El diseño debería presentar uniformidade integración
•Debe estructurarse para admitir cambios
•El diseño no es escribir código y escribir código no es diseñar
•Se debería valorar la calidad del diseño mientras se crea, no después de terminado
•Diseño de datos:
–Modelo de información a estructuras de datos.
•Diseño arquitectónico:
–Define las relaciones entre los elementos estructurales de nuestro programa.
•Diseño procedimental:
–Se transforman los elementos estructurales de nuestro programa en una descripción procedimental del software.
•Diseño de interfaz:
–Describe cómo se comunica el software consigo mismo y con su entorno.

Directrices para un buen diseño

•El diseño debe implementar todos los requisitos explícitoscontenidos en el modelo de análisis y debe acomodar todos los requisitos implícitosque desee el cliente
•El diseño debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el software
•El diseño debería proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y de comportamiento desde la perspectiva de la implementación.

Modelo De Desarrollo Incremental y evolutivo.

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

• Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.

• Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.

• Si un error importante es realizado, sólo la última iteración necesita ser descartada.

• Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.

• Si un error importante es realizado, el incremento previo puede ser usado.

• Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo De Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.

El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.

Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.

Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.

El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.

Modelo de Prototipado de Requerimientos.-

El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.

El Prototipado ha sido usado frecuentemente en los 90, porque la especificación de requerimientos para sistemas complejos tienden a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer retroalimentación convenientemente basado en la manipulación, desde un prototipo, en vez de leer una especificación de requerimientos potencialmente ambigua y extensa.

Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente.

En caso que ustedes construyan requerimientos bien entendidos, el cliente podría responder con "sí, así es", y nada podría ser aprendido de la experiencia.

4.5 Evolución.

Un entorno de desarrollo integrado o IDE (acrónimo en inglés de integrated development environment), es un programa informático compuesto por un conjunto de herramientas de programación.

Puede dedicarse en exclusiva a un sólo lenguaje de programación o bien, poder utilizarse para varios.
Dev C++, un IDE para el lenguaje de programación C++.‎.
WebDevStudio, un IDE en línea para el lenguaje de programación C/C++.‎.

Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI). Los IDEs pueden ser aplicaciones por sí solas o pueden ser parte de aplicaciones existentes. El lenguaje Visual Basic, por ejemplo, puede ser usado dentro de las aplicaciones de Microsoft Office, lo que hace posible escribir sentencias Visual Basic en forma de macros para Microsoft Word.

Los IDE proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación tales como C++, Python, Java, C#, Delphi, Visual Basic, etc. En algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde se permite utilizar el lenguaje de programación en forma interactiva, sin necesidad de trabajo orientado a archivos de texto, como es el caso de Smalltalk u Objective-C.

Es posible que un mismo IDE pueda funcionar con varios lenguajes de programación. Este es el caso de Eclipse, al que mediante plugins se le puede añadir soporte de lenguajes adicionales.

Ejemplos de IDE:

Acceleo : El eclipse y el EMF plantilla-basaron el sistema para la generación del fuente-código de modelos de UML.
ArgoUML : un Java - la herramienta basada de la ingeniería de la fuente abierta UML, sigue de cerca el estándar de UML, licencia del DEB.
Astade : una UML-herramienta de la plataforma-independiente basada en wxWidgets.
ATL - un QVT - herramienta que puede transformar modelos de UML en otros modelos. Disponible del proyecto del GMT del eclipse (herramientas de modelado generativas).
BOUML: la caja de herramientas de la multi-plataforma UML 2.0, revés/genera C++/Java/IDL. Rendimiento muy alto (escrito en C++ con el cuarto de galón). Autorizado bajo GNU GLP .
Diámetro : un GTK+ /herramienta diagramming del GNOMO que también apoya UML (autorizado debajo del GNU GLP)
Eclipse : con el eclipse modelando el marco (EMF) y proyectos de UML 2.0 (modelo de meta sin GUI ).
Fujaba : Siglas para el " De UML a Java y al back". Permite comportamiento de modelado usar diagramas de la historia.
Gaphor : un GTK+ /ambiente de modelado del GNOMO UML 2.0 escrito en el pitón
Kivio : parte del proyecto de KOffice
Evolución de MetricView: una herramienta para el calidad-análisis métrica-basado y una mejor comprensión de los modelos de UML
MonoUML : de acuerdo con el último mono, GTK+ y ExpertCoder.
NetBeans : con el paquete de la empresa de NetBeans IDE 5.5
Omondo : Eclipse 3.
Papiro : una herramienta de la fuente abierta UML2 basada en eclipse y autorizada bajo EPL (www. Ver también Topcased abajo.
StarUML : una plataforma MDA de UML/para Microsoft Windows, autorizada bajo versión modificada de GNU GLP, escrita sobre todo en Delphi
Taylor : " modelo-conducido de la arquitectura; en rails" (autorizado bajo LGPL del GNU)

IDEs de Java por Sunmicrosystems.
JCEE
JCSE
JCME
JCLE