Modelo evolutivo Basado en Componentes

definición:
Un componente es una pieza de código pre-elaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar.

Etapas del modelo evolutivo Basado en Componentes

PLANEACION: En esta etapa evalúa la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible.

ANÁLISIS DE RIESGOS: en esta etapa l analista se encarga de analizar los riesgos que el software a crear estará expuesto y así encontrar la manera de corregirlos.

CONSTRUCCIÓN Y ADAPTACIÓN DE LA INGENIERÍA: en esta etapa se construye el software, se prueba si no tiene algún problema o para detectar errores,se instala , y luego se le brinda soporte al cliente.

VALUACIÓN DEL CLIENTE: el cliente tiene la tarea de evaluar el software para verificar si este cumple con los requisitos que este proporciono y esta en todo la tarea de aprobar o rechazar el software.

Características

• Es evolutivo

• Posee un enfoque evolutivo para la creación de software

• Comienza con la identificación de las clases más importantes

• Examina los datos que se van a manejar

• Permite la reutilización del software

• El ensamblaje de los componentes reduce el 70 del 100% del tiempo del ciclo del desarrollo del software y un 84 del 100% del costo del proyecto.

Ventajas / Desventajas

Ventajas	Desventajas
Reutilización del software. Simplifica las pruebas; pues estas se le hacen a los componentes antes de probar el conjunto completo de componentes ensamblados. Simplifica el mantenimiento del sistema. Mayor calidad.	Genera mucho tiempo en el desarrollo del sistema. Modelo costoso . Requiere experiencia en la identificación de riesgos. Genera mucho trabajo adicional.

Ejemplo:

A manera de ejemplo, pensemos en un equipo de sonido con cada una de sus piezas o componentes; es probable que por separado puedan ser funcionales, pero para que verdaderamente desempeñen la función que deberían, tienen que estar unidas formando un todo.

Modelo concurrente

definición:

El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades. Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera.

Características:
• se puede expresar de manera esquematizada

• las actividades llevan procesos concurrentes

• es aplicable a todo tipo de desarrollo de software

• es un modulo aplicable para cliente soñador

• esta dirigido por las necesidades del usuario

• es aplicable al cliente servidor

Etapas del modelo concurrente

Para identificar mejor las etapas o como es que el Método de desarrollo concurrente funciona , es conveniente ver la siguiente imagen :
La imagen anterior proporciona una representación esquemática de una actividad(análisis) como se puede observar todas las actividades existen concurrentemente, pero residen en estados diferentes , al principio es la comunicación con el cliente (no esta plasmada en la figura) y esta en estado de cambios en espera.La actividad de análisis esta en ninguna significa que ya se ha hecho la comunicación con el cliente luego hace una transición al estado bajo desarrollo. sin embargo si el cliente indica que se deben hacer cambios en requisitos , la actividad de análisis cambia del estado bajo desarrollo al estado cambios en espera.

El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software.

Ventajas / Desventajas

Ventajas	Desventajas
Excelente para proyectos en los que se conforman grupos de trabajo independientes. Proporciona una imagen exacta del estado actual de un proyecto.	Si no se dan las condiciones señaladas no es aplicable. Si no existen grupos de trabajo no se puede trabajar en este método

Ejemplo:

Como ya analizamos el modelo de desarrollo concurrente esta dirigido a satisfacer la necesidades del usuario. En cambio los otros modelos están determinados por el tiempo, cuanto mas tarden, mas atrás se encontraran en el proceso de desarrollo.

Para entenderlo mejor lo ejemplificaremos comparando este modelo a una empresa cuyos empleados trabajan para satisfacer necesidades.

Suponiendo que el equipo de trabajo este compuesto por 5 personas, dicho trabajo será distribuido por los 5, realizado simultáneamente y probado constantemente para satisfacer la necesidad presentada, si al final de todo es cliente (quien presenta la necesidad) desea algo mas, el resultado obtenido anteriormente es retomado y modificado (con el mismo proceso anterior) hasta llenar esa segunda necesidad. Esto ocurre sucesivamente dependiendo de las necesidades presentadas.

MODELO DE DESARROLLO RAPIDO DE APLICACIONES(DRA)

MODELO DRA (Desarrollo Rápido de Aplicaciones)

Definición	Fases	Características	Ventajas	Desventajas
Es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes.	Modelado de gestión Modelado de datos Modelado de proceso Generación de aplicaciones Pruebas de entrega	Modelo lineal secuencial orientado a un ciclo rápido de desarrollo. Basado en componentes para poder entregar un modelo totalmente operativo en un corto periodo de tiempo. Es fundamental para poder modular la aplicación para cada equipo pueda trabajar en diferentes modelos.	Es muy rápido. Permite trabajar en él a varias personas a la vez.	El enfoque DRA tiene inconvenientes para proyectos grandes, necesita suficientes recursos humanos para crear el número correcto de equipos. Si los desarrolladores y clientes no se comprenden con las actividades necesarias para completar el sistema, los proyectos fallarán. El DRA sería inapropiado cuando los riesgos técnicos son altos.

MODELO PROTOTIPO

Definición	Fases	Características	Ventajas	Desventajas
Es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final. Proporcionando una retroalimentación temprana por parte de los usuarios acerca del Sistema.	Plan rápido Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y retroalimentación Comunicación	El prototipo es una aplicación que funciona. Los prototipos se crean con rapidez. Los prototipos evolucionan a través de un proceso iterativo Los prototipos tienen un costo bajo de desarrollo	Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.	El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. Adoptarlo como el sistema final

Modelo Incremental

Es un modelo de tipo evolutivo que está basado en varios ciclos Cascada realimentados aplicados repetidamente, con una filosofía iterativa. 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.
El Modelo Incremental se puede ver aquí en forma grafica:
- 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.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica.
Características
- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.
- El usuario se involucre más.
- Difícil de evaluar el costo 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.

Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.
- El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
- Resulta más sencilo acomodar cambios al acotar el tamaño de los incrementos.
- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.
Desventajas:
- El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
- Requere de mucha planeacion, tanto administrativa como técnica.
- Requiere de metas claras para conocer el estado del proyecto.

El modelo incremental
Combina elementos del modelo lineal con la filosofía de creación de prototipos.
El primer incremento a menudo es un producto esencial (núcleo)
A partir de la evaluación se planea el siguiente incremento y así sucesivamente.
Es interactivo por naturaleza.
Es útil cuando el personal no es suficiente para la implementación completa.

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.

Desarrollo de Sistemas Incremental, en Espiral y Win Win

Desarrollo de Sistema Incremental, en Espiral y Win Win

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.
Este modelo fue propuesto por Boehm en 1988. Básicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser así. El Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada, con el agregado de gestión de riegos.

En cada vuelta o iteración hay que tener en cuenta
Los Objetivos: Que necesidad debe cubrir el producto.
Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:
1. Características: experiencia del personal, requisitos a cumplir, etc.
2. Formas de gestión del sistema.
3. Riesgo asumido con cada alternativa.
Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades
Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:
1. Angular: Indica el avance del proyecto del software dentro de un ciclo.
2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.



Modelo en Espiral Win Win


Es una modificación del modelo en espiral original desarrollado por el propio Boehm.
Sobre este modelo puedo comentar que define un conjunto de actividades de negociación al principio del desarrollo del software. Ya que se analiza en conjunto las condiciones de todos los que intervienen en el desarrollo del problema directa o indirectamente (Cliente, Jefes, Desarrollador, Usuario final, Mantenimiento).
El modelo en espiral WINWIN introduce tres hitos y proporcionan hitos de decisión antes de continuar el proyecto de software, mediante los cuales podemos establecer el progreso del desarrollo de software.
Con la implementación de sub ciclos dentro de la espiral, se convierte aun más en un modelo complejo, teniendo las mismas limitaciones que el modelo original.
Como conclusión se puede sacar, que al ser un modelo en el que solo puede ser aplicado a proyectos grandes y complejos, no se puede sacarle el máximo provecho al mismo, ya que el modelo en si es complejo, el cual solo su propio creador lo aplicado correctamente.

El modelo “win-win”. deriva su nombre del objetivo de estas negociaciones, es decir, de "ganar-ganar". El cliente recibe el producto que satisface la mayoría de sus necesidades, y el desarrollador trabaja para alcanzar presupuestos y fechas de entrega. Para lograr este objetivo, el modelo define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. En vez de una sola actividad de los clientes de comunicación las actividades se definen los siguientes:
• Identificación de los actores del sistema.
• Determinación de las partes interesadas de "ganar" condiciones
• Las negociaciones de la victoria de las condiciones de las partes interesadas a que reconciliarlos en un conjunto de condiciones de ganar-ganar para todos los interesados.
Además del énfasis inicial puesto en la condicion de ganar-ganar, el modelo también presenta tres etapas del proceso (puntos de anclaje), que ayudan a establecer la realización de un ciclo alrededor de la espiral y proporcionar los hitos de decisión antes de que el proyecto de producto de software. Estos son:
Objetivos del Ciclo de Vida (Life Cycle Objectives - LCO) - Define una serie de objetivos para cada actividad de software más importantes (un conjunto de objetivos relacionados con la definición de los principales requisitos de nivel de producto).
Arquitectura del Ciclo de Vida (Life Cycle Architecture - LCA) - Establece los objetivos que deben cumplirse como la arquitectura de software se define.
Initial Operational Capability (Initial Operational Capability - IOC) - Representa un conjunto de objetivos asociados a la preparación del software para la instalación y distribución, la preparación previa a las instalaciones del sitio, asistencia requerida por todas las partes que utilizará o soporte técnico del software.
Con esta breve descripcion se puede declarar que el Software de producción más rápido puede facilitarse a través de la participación colaborativa de las partes interesadas pertinentes ademas de ser barato a través de reproceso y mantenimiento reducciones.



Modelo Incremental

El incremental es un modelo de tipo evolutivo que está basado en varios ciclos Cascada realimentados aplicados repetidamente, con una filosofía iterativa.9 En la figura 5 se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas asociadas. Aquí se observa claramente cada ciclo cascada que es aplicado para la obtención de un incremento; estos últimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.


Fig. 5 - Modelo iterativo incremental para el ciclo de vida del software,.
Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, así por ejemplo, en la figura, mientras se realiza el diseño detalle del primer incremento ya se está realizando en análisis del segundo. La figura 5 es sólo esquemática, un incremento no necesariamente se iniciará durante la fase de diseño del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de “Operación y Mantenimiento” (indicada "Operación" en la figura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fácilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc.
Bajo este modelo se entrega software “por partes funcionales más pequeñas”, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.6
Como se muestra en la figura 5, se aplican secuencias Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es un sistema básico, con muchas funciones suplementarias (conocidas o no) sin entregar.
El cliente utiliza inicialmente ese sistema básico intertanto, el resultado de su uso y evaluación puede aportar al plan para el desarrollo del/los siguientes incrementos (o versiones). Además también aportan a ese plan otros factores, como lo es la priorización (mayor o menor urgencia en la necesidad de cada incremento) y la dependencia entre incrementos (o independencia).
Luego de cada integración se entrega un producto con mayor funcionalidad que el previo. El proceso se repite hasta alcanzar el software final completo.
Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente operacional en cada incremento, y no una parte que sea usada para reajustar los requerimientos (como si ocurre en el modelo de construcción de prototipos).9
El enfoque incremental resulta muy útil con baja dotación de personal para el desarrollo; también si no hay disponible fecha límite del proyecto por lo que se entregan versiones incompletas pero que proporcionan al usuario funcionalidad básica (y cada vez mayor). También es un modelo útil a los fines de evaluación.

El modelo incremental se aplica cuando en un proyecto tenemos un tiempo límite y no disponemos del personal suficiente para que nuestro propósito sea implementado completamente.
Además existen altos riesgos en este modelo pero se los puede reducir si tan solo construimos una parte del sistema y dejamos lo demás para complementarlo en versiones posteriores


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.
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 grafica:
- 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.

Modelo de Procesos:

El “IEEE Standard Glossary of Software Engineering Terminology” (Stad. 610.12-1990) ha desarrollado una definición más completa para ingeniería del software [1]: “(1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. (2) El estudio de enfoques en (1)”.

Pressman [1] caracteriza la Ingeniería de Software como “una tecnología multicapa”, ilustrada en la Figura 1.

Figura 1: Capas de la Ingeniería de Software.

Dichas capas se describen a continuación:

·       Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un esfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la ingeniería del software.

·       El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco de trabajo para  un conjunto de áreas clave, las cuales forman  la base del control de gestión  de proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

·       Los métodos de la ingeniería de software indican cómo construir técnicamente el software.  Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada  área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.

·       Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-automático para el proceso y los métodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering).

Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboración), mediante un proceso apoyado por métodos y herramientas.

A continuación nos enfocaremos en el proceso necesario para elaborar un producto de software.

El proceso de desarrollo del software

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la Figura 2 [3]. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas [4]. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.

Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).

Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son  inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.

Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo.

Figura 2: proceso de desarrollo de software.

El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos [4]:

1.    Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.

2.    Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación.

3.    Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.

4.    Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.

Además de estas actividades fundamentales, Pressman [1] menciona un conjunto de “actividades protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación:

·       Seguimiento y control de proyecto de software.

·       Revisiones técnicas formales.

·       Garantía de calidad del software.

·       Gestión de configuración del software.

·       Preparación y producción de documentos.

·       Gestión de reutilización.

·       Mediciones.

·       Gestión de riesgos.

Pressman [1] caracteriza un proceso de desarrollo de software como se muestra en la Figura 3. Los elementos involucrados se describen a continuación:

·       Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad.

·       Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades  del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto.

·       Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 3: Elementos del proceso del software

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo [5].

Figura 4: Relación entre elementos del proceso del software

En la Figura 4 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. Así las interrogantes se responden de la siguiente forma:

·       Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos.

·       Qué: Un Artefacto[1] es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones.

·       Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado de terminación de ciertos Artefactos.

La composición y sincronía de las actividades está basada en un conjunto de Principios y Prácticas. Las Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc.

Modelos de proceso software

Sommerville [4] 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 [7]:

·       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.