PARADIGMAS

La ingeniería de software esta compuesta por una serie de pasos que abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de software. La elección de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas requeridos.

Gama de paradigmas de la ingeniería de software:

PARADIGMA CICLO DE VIDA DEL SOFTWARE

Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento.

Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software; esta versión del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.

La ingeniería y análisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequeña cantidad de análisis y diseño a nivel superior. Además de un análisis costo beneficio del sistema es decir si toda la inversión que se hará para el sistema conviene a los beneficios que traerá el mismo.

Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.

Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.

• estructura de datos
• arquitectura de software
• detalle procedimental

El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.

Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.

Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.

Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.

El ciclo de vida clásico es el mas viejo y más ampliamente usado paradigma en la ingeniería de software. Sin embargo con el paso de unos cuantos años se han producido criticas al paradigma, incluso por seguidores activos que cuestionan su aplicabilidad a todas las situaciones. Entre los problemas que se presentan algunas veces cuando se aplica este paradigma se encuentran:

1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre ocurre iteraciones y se crea problemas en la aplicación del paradigma.
2. Normalmente es difícil para el cliente establecer explícitamente el principio todos los requerimientos del sistema. El ciclo de vida clásico requiere esto y tiene dificultades para acomodar posibles incertidumbres que puedan existir al comienzo de dichos proyectos.
3. El cliente debe tener paciencia. Una versión funcional del programa no esta disponible hasta las etapas finales del desarrollo del proyecto. Un error importante no detectado hasta que el programa este en funcionamiento puede ser desastroso.
4. Los responsables del desarrollo se retrasan innecesariamente.

PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS

Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.

En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:

Un prototipo en papel que describa la interrelacion hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelacion; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.

La secuencia de sucesos para el paradigma de construcción de prototipos se muestra en al siguiente figura:

Como todos los métodos de desarrollo de software la construcción de prototipos comienza con la recolección de los requerimientos del sistema. El técnico y el cliente se reúnen y definen los objetivos globales para el software, identifican todos los requerimientos conocidos y perfilan las áreas donde será necesario una mayor definición. Luego se produce un diseño rápido. El diseño rápido se enfoca sobre la representación de los aspectos del software visibles al usuario por ejemplo: métodos de entrada y formatos de salida. El diseño rápido conduce a la construcción de un prototipo. El prototipo es evaluado por el cliente-usuario y se utiliza para refinar los requerimientos del software a desarrollar. Se produce un proceso interactivo en el que prototipo es afinado para que satisfaga las necesidades del cliente al mismo tiempo que facilita al que lo desarrolla una mejor comprensión de todo lo que hay que hacer idealmente, el prototipo sirve como un mecanismo para identificar los requerimientos del software. Si se construye un prototipo que funcione, el realizador intenta hacer uso de fragmentos de programas existentes o aplique herramientas por ejemplo: gestores de informes, gestores de ventanas, etc. Que faciliten la rápida generación de programas que funcione.

CARACTERISTICAS:

• Este paradigma ayuda al cliente a brindar requisitos paso a paso.
• También facilita al programador ir probando algoritmos no explotados con anterioridad, de los que no tiene seguridad de su eficiencia.
• Consiste en la creación de prototipos

DESVENTAJAS:

La construcción de prototipos como paradigma para la ingeniería de software puede ser problemático por las siguientes razones:

1. El cliente ve funcionando lo que parece ser una versión del software ignorando que el prototipo se ha hecho con chicle y alambres, ignora que por las prisas hacer que funcione no han considerado los aspectos de calidad y mantenimiento a largo plazo del software. Cuando se informa al cliente que el producto debe ser reconstruido, este grita horrible y solicita que el producto se le aplique en cuantas mejoras se han necesarias para hacer del prototipo un producto final que funcione. Demasiadas veces el gestor del desarrollo del software sede.
2. El técnico del desarrollo realiza frecuentemente ciertos compromisos de implementación en orden a obtener un prototipo que funcione rápidamente. Puede utilizarse un S.O. o lenguaje de programación inapropiado simplemente porque esta disponible y es conocido. Un algoritmo ineficiente puede implementarse de forma sencilla para demostrar su capacidad; después de pasar un tiempo en el que el técnico esta familiarizado con estas selecciones, olvida las razones por las que eran inapropiadas. La elección menos ideal forma ahora parte integral del sistema.

Aunque se puede presentar problemas, la construcción de prototipos es un paradigma efectivo para la ingeniería de software. La clave de esta es definir desde el comienzo las reglas del juego, esto es que el cliente y el técnico deben de estar de acuerdo en que el prototipo se construya para servir solo como un mecanismo de definición de los requerimientos. Posteriormente ha de ser descartado o al menos una parte y debe construirse el software real con ojos puestos en la calidad y mantenimiento.

PARADIGMA DEL MODELO ESPIRAL

Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. 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 mas completas de ingeniería del sistema.

CARACTERISTICAS:

• Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos.
• Incluye la etapa de análisis de riesgos, no incluida anteriormente.
• Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras.
• La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
• Este es el enfoque más realista actualmente.

El modelo en espiral se divide en un numero de actividades estructurales, 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 otras informaciones relacionadas con el proyecto. Son todos los requerimientos.

Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.

Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.

Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

Evaluación el 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 implementación durante la etapa de instalación.

Cuando empieza el 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 produce 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 mas sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente.

VENTAJAS:

• El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.
• Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
• Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
• Reduce los riesgos antes de que se conviertan en problemáticos.

Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.

La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representan el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.

PROBLEMAS:

• Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable.
• Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la evolución

EL MODELO DRA

El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) 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. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

• Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
• Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
• Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.

Obviamente la limitación de tiempo impuestas en un proyecto DRA demanda "ámbito en escalas". Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.

Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:

• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.
• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.

No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes.

DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.

PARADIGMA DE TÉCNICAS DE CUARTA GENERACION

El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.

Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existe, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.

El paradigma T4G para la ingeniería de software se describe en la siguiente figura:

Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. Idealmente el cliente debe describir los requerimientos y estos debe traducirse directamente en un prototipo operacional pero este no funciona. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo en este momento el dialogo cliente técnico descrito por los otros paradigmas permanecen como una pequeña parte esencial del enfoque T4G. Para aplicaciones pequeñas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementación, usando un lenguaje de cuarta generación no procedimental (L4G) sin embargo es necesario un mayor esfuerzo para desarrollar una estrategia del diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para grandes proyectos causará las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptación por el cliente) que se encuentran cuando se desarrolla software usando los métodos convencionales.

La implementación usando L4G facilita el que desarrolla al software la descripción de los resultados deseados, los cuales se traducen automáticamente en código fuente para producir dichos resultados. Obviamente debe existir una estructura de datos con información relevante y debe estar rápidamente accesible al L4G.

El ultimo paso de la figura anterior contiene la palabra producto par transformar una implementación T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentación con sentido y ejecutar todas las otras actividades de transición requeridas en los otros paradigmas de la ingeniería de software. Además del software desarrollado con T4g, debe ser construido de forma que facilite que el mantenimiento y pueda ser ejecutado de una forma experitiva. Los defensores aducen reducciones dramáticas en el tiempo de desarrollo en el software y una mejora significativa en la productividad de la gente que construye el software. Los retractores de este paradigma aducen que los lenguajes de programación, que el código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistema de software desarrollado usando T4g esta abierta a discusión.

Hay algunos méritos en las razones de cada parte. Aunque es algo difícil separar los hechos de las suposiciones es posible resumir el estado actual de los métodos T4G:

1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas.
2. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño.
3. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.

Para resumir las técnicas de cuarta generación se convertirán en una parte importante en el desarrollo del software durante la siguiente década. Como muestra la siguiente figura la demanda del software continuara creciendo durante el resto del siglo, pero los métodos y paradigmas convencionales contribuirán cada vez menos al desarrollo del mismo.

Las T4G rellenan el hueco que existe hasta que sean practicables los métodos de la IA de la quinta generación.

EL MODELO DE DESARROLLO CONCURRENTE

Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:

Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

La figura siguiente proporciona una representación esquemática de una actividad dentro del modelo de proceso concurrente. La actividad "análisis" se puede encontrar en uno de los estados destacados anteriormente en cualquier momento dado. De forma similar otras actividades se pueden representar de una forma análoga. Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto, la actividad de comunicación con el cliente (no mostrada en la figura) ha finalizado su primera interacción y existe en el estado de cambios en espera. La actividad de análisis (que existía en el estado ninguno mientras que comenzaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad 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. Por ejemplo, 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 disparara la actividad de análisis del estado hecho al estado cambios en espera.

El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una división de sistemas y una división de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y realización. La concurrencia se logra de dos formas (1) las actividades del sistema y de componente ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente; (2) una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniería de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultáneamente con otras. Los sucesos generados dentro de una actividad dada o algún otro lado de la red de actividad inicia las transiciones entre los estados de una actividad.

COMBINACIÓN DE PARADIGMAS

Frecuentemente se describe a los paradigmas de la ingeniería de software tratados en las secciones anteriores como métodos alternativos, para la ingeniería de software en vez de los métodos complementarios.

En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un único proyecto.

La siguiente figura muestra como pueden combinarse los 3 paradigmas mencionados durante un trabajo de desarrollo del software, en todos los casos el trabajo comienza con la recolección de requerimientos. El método puede seguir el ciclo de vida clásico (ingeniería de sistemas análisis de requerimiento de software) o puede ser la definición menos formal del problema usada en la construcción de un prototipo, independientemente debe producirse la comunicación cliente-realizador del software.

La naturaleza de aplicación dictara la aplicabilidad del método de construcción de prototipos. Si los requerimientos para la función y rendimiento del software están razonablemente bien comprendidos pueden ser aplicables los métodos de especificación recomendados para el ciclo de vida clásico. Por otra parte si la aplicación del software exige una fuerte interacción hombre-maquina o requiere algoritmos no probados o técnicas de control de salidas pueden regresarse a un prototipo. En tales casos puede usarse un lenguaje de cuarta generación para el desarrollo de un prototipo. Una vez que se haya evaluado y reafinado el prototipo pueden aplicarse los pasos de diseño e implementación del ciclo de vida clásico para desarrollar el software formalmente.