DESARROLLO DE SOFTWARE

INTRODUCCIÓN
Desarrollar un software significa construirlo simplemente mediante su descripción. Está es una muy
buena razón para considerar la actividad de desarrollo de software como una ingeniería. En un nivel
más general, la relación existente entre un software y su entorno es clara ya que el software es
introducido en el mundo de modo de provocar ciertos efectos en el mismo.

Aquellas partes del mundo que afectarán al software y que serán afectadas por él será el Dominio de
Aplicación. Es allí donde los usuarios o clientes observarán si el desarrollo del software ha cumplido
su propósito.

Una de las mayores deficiencias en la práctica de construcción de software es la poca atención que se
presta a la discusión del problema. En general los desarrolladores se centran en la solución dejando
el problema inexplorado. El problema a resolver debe ser deducido a partir de su solución.

Esta aproximación orientada a la solución puede funcionar en campos donde todos los problemas
son bien conocidos, clasificados e investigados, donde la innovación se ve en la detección de nuevas
soluciones a viejos problemas.

Pero el desarrollo de software no es un campo con tales características. La versatilidad de las

computadoras y su rápida evolución hace que exista un repertorio de problemas en constante cambio
y cuya solución software sea de enorme importancia.

ANTECEDENTES
El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960 para
desarrollar a gran escala funcional de sistemas de negocio en una época de grandes conglomerados
empresariales.

La idea principal era continuar el desarrollo de los sistemas de información en una muy deliberada,
estructurada y metódica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de
información en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de
cálculo.

¿Qué es el Desarrollo de Software?

El software moderno habitualmente consiste en una serie de componentes que interactúan entre sí
para realizar las tareas que se requieren al implementar la aplicación. El desarrollo implica la creación
de estos componentes mediante la escritura de código fuente en uno de los muchos lenguajes
disponibles. Este código define las acciones individuales fundamentales que el equipo informático
deberá llevar a cabo para alcanzar el resultado final especificado en el diseño de la aplicación. Estas
acciones pueden ser tan sencillas como sumar números, configurar valores de los objetos dentro de
los componentes o ejecutar diferentes partes del código según una comparación de los valores de las
variables definidas en el código. Es posible que también implique cálculos matemáticos más
complejos dentro del código y la aplicación de operaciones lógicas para generar los resultados
requeridos. Otras actividades que implica el desarrollo incluyen depuración del código para ubicar y
corregir errores; seguimiento del trabajo mediante metodologías formales; trabajo con repositorios
de códigos compartidos; y participación en reuniones sobre diseño, planeación, comentarios y
revisión de código.

Este documento describe el desarrollo de tareas en el contexto del ciclo de vida de la creación de
software. Lo ayudará a comprender qué incluyen las responsabilidades de desarrollo, las metas
amplias y los procesos que se llevan a cabo. En la figura se muestra una descripción general del ciclo
de vida típico para desarrollo de software.

El proceso de creación de software abarca una amplia gama de tareas; desde el diseño original hasta
la implementación final y la aceptación del cliente. La labor principal durante el desarrollo consiste
en convertir el diseño original en código de trabajo utilizando herramientas como Microsoft Visual
Studio y lenguajes como Visual Basic, C# y JavaScript. Sin embargo, habitualmente incluye alguna
participación durante el ciclo de vida completo de desarrollo de software, especialmente al trabajar
solo o en un equipo muy pequeño (en cuyo caso realizará frecuentemente una combinación de tareas
de desarrollo, pruebas y arquitectura). Las secciones siguientes describen las tareas principales del
desarrollo dentro del ciclo de vida del software.

Metodología:
Todo desarrollo de software es riesgoso y difícil de controlar, pero si no llevamos una metodología
de por medio, se obtiene clientes insatisfechos con el resultado y desarrolladores aún más.
Sin embargo muchas veces no se toma en cuenta el utilizar una metodología adecuada, sobre todo
cuando se trata de proyectos pequeños de dos o tres meses.

Con relación a los proyectos que se desarrollan con mayor envergadura, hay si se toma el sentido de
basarse en una metodología de desarrollo y se empieza a buscar cual sería la más apropiada para dicho
caso. A fin de cuenta no encontramos muchas veces la meas adecuada y se termina por hacer un
diseño propio de metodología, por supuesto no está mal siempre y cuando sirva para alcanzar el
objetivo.

Muchas veces se realiza el diseño del software de manera rígida, tal cual como el cliente lo solicito,
de esa manera cuando el cliente en la "etapa de prueba" solicita un cambio se hace muy difícil de
realizarlo, pues si se hace altera las cosas que no se habían previsto, y este es uno de los factores que
atrasan el proyecto y crea incomodidad al desarrollador y en muchas oportunidades no llegan a
cumplir con el cambio solicitado, esto conlleva malestar en el cliente puesto que no se sido tomado
en cuenta su pedido; para evitar estos incidentes se debe llegar a un acuerdo formal con el cliente al
inicio del proyecto de manera que no perjudique el desarrollo del mismo.
Muchas veces los usuarios finales se dan cuenta que dejaron de mencionar algunas cosas y lo
manifiestan en la etapa inicial del proyecto cuando se le muestra el prototipo del mismo.

ALGUNAS Metodologías conocidas:

• La metodología RUP es la más adaptable para proyectos de largo plazo.
• La metodología XP en cambio, se recomienda para proyectos de corto plazo.
• La metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología.
• Se puede decir además que lo más importante antes de elegir la metodología que se debe usar
para implementar el software, es determinar el alcance que tendrá y luego de allí ver cuál es
la que más se acomoda a la aplicación.

Fases
RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en número variable
según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades.

• Inicio
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores,
identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de
software y producir el plan de las fases y el de iteraciones posteriores.

 Revisión de información del cliente y los objetivos del proyecto

La primera tarea en la creación de una aplicación de software consiste en captar información y generar
el diseño de alto nivel según los requisitos del cliente. A medida que el diseño de alto nivel se traduce
en documentación más específica y más centrada técnicamente, se requiere información de
implementación técnica para proporcionar comentarios sobre las capacidades del hardware y la
implementación práctica del diseño. Esto puede ayudar a evitar sorpresas posteriores, y garantiza que
el diseño final del software pueda implementarse en un tiempo razonable y en el hardware y la
infraestructura disponibles.

• Elaboración
En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del
sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y
el primer análisis del dominio del problema, se diseña la solución preliminar.
  Escribir código para componentes
Esta es la actividad central del desarrollo y la actividad que impulsa todo el proceso de creación de
software. La persona que crea el código usará una especificación o lista de requisitos que describen
lo que debe realizar un componente o sección de la aplicación, los resultados que debe generar y la
forma en que se comunicará con otras partes de la aplicación. Esta especificación puede ser en una
de muchas formas diferentes, como modelos escritos en un lenguaje de modelado estándar,
descripciones de la funcionalidad o simplemente diagramas en una pizarra.

Durante el desarrollo, se usan las funciones del lenguaje de programación elegido para crear archivos
de código fuente que contienen la serie requerida de instrucciones que ejecutará el equipo.

Básicamente, este código asimilará un conjunto de valores de entrada, realizará algún procesamiento
con estos valores y generará los resultados. Para lograr esto puede hacer uso de otros componentes
y funciones dentro del software, y también puede hacer uso de bibliotecas de códigos y funciones
que fueron escritos por el equipo u obtenidos de proveedores externos. Las herramientas y entornos
de desarrollo que se usen, como Microsoft Visual Studio (en la figura 2), ayudan a facilitar la escritura
de código al sugerir los nombres de objetos y variantes, al comprobar la sintaxis para garantizar que
se compilará correctamente y al indicar errores.

• Construcción
El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los
requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los
usuarios y se realizan las mejoras para el proyecto.

 Revisión de códigos con miembros del equipo

Para cualquier sección de código que los desarrolladores escriban, rara vez hay sólo una solución
correcta única. Las habilidades de un desarrollador radican en utilizar las características y capacidades
de los lenguajes de código para construir código que realice la tarea requerida, y puede haber muchas
maneras distintas de lograrlo. Distintos desarrolladores pueden utilizar hábilmente diferentes
enfoques y diferentes combinaciones de instrucciones de código.

Con una revisión del código por parte de pares y gerentes se realizan dos tareas vitales. En primer
lugar, reúne los puntos de vista y las opiniones de varios desarrolladores que pueden ofrecer enfoques
alternativos, señalar errores desapercibidos o sugerir mejoras al código. Esto ayuda a optimizar la
eficiencia y el rendimiento de los códigos. En segundo lugar, ayuda a ampliar el conocimiento de
todos los miembros del equipo al compartir experiencia, lo cual mejora el desempeño de todo el
equipo con el tiempo.

 Compilación y prueba del código

Según el lenguaje de código que se use, el desarrollo implica la compilación del código fuente para
convertirlo en una forma que el equipo informático pueda ejecutar. Generalmente las herramientas y
entornos de desarrollo realizarán esta tarea. Un miembro del equipo (habitualmente el creador inicial,
luego los evaluadores) ejecuta después el código para garantizar que funcione como debería. Si el
equipo utiliza un enfoque Test Driven Design (TDD), un miembro del equipo habrá escrito
anteriormente pruebas unitarias que pueden ejecutarse para garantizar que el código se ejecuta
correctamente y genera los resultados requeridos.

La compilación, ejecución y prueba del código es un proceso iterativo que se produce mientras el
código se crea. Habitualmente, se crea primero el código mínimo básico para probar el concepto,
asegurando que se compila y ejecuta, y luego se agrega o actualiza código progresivamente para
maximizar el rendimiento y la eficiencia y, a la vez, confirmar que genera los resultados correctos.

 Registro y actualización del repositorio de códigos

En la mayoría de los proyectos medianos y grandes se usa un sistema de información de equipo y
repositorio de códigos como Team Foundation Server (TFS) para almacenar códigos, documentos e
información sobre el proyecto. El desarrollador registra el código que creó para que forme parte del
proyecto general y pueda compilarse en la solución completa durante las compilaciones regulares.

Habitualmente estas compilaciones se realizan a diario, y el equipo de prueba trabaja con la nueva
compilación cada día para confirmar que los errores informados existentes se hayan resuelto y para
ubicar cualquier defecto nuevo.

El repositorio por lo general incluirá elementos de trabajo e informes. El desarrollador actualiza

elementos de trabajo relevantes para el código creado, marca los elementos de trabajo para errores
que se hayan resuelto y agrega otra información relevante para la tarea que resultará útil a otros
miembros del equipo, incluidos el equipo de prueba y el equipo de documentación. El equipo puede
ejecutar informes basados en estos elementos de trabajo para supervisar el progreso del proyecto y
descubrir cualquier problema en curso. En la figura 3 se muestra Microsoft Visual Studio Team
Foundation Server.

• Transición
El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar
los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el
soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones
entregadas por las personas involucradas en el proyecto.

 Implementación de cambios y depuración y corrección de errores

Si las pruebas dan como resultado errores que se informan en el código, el desarrollador debe volver
atrás, encontrar la causa de esos errores y luego cambiar el código para resolverlos. La depuración es
la tarea de localizar el origen de los errores, que se puede producir en cualquier parte del código y que
sólo puede surgir en el punto descubierto durante las pruebas. La depuración a veces se considera
como un “arte secreto” porque requiere experiencia y también un enfoque lógico, especialmente si el
error sólo aparece intermitentemente o es difícil de reproducir.

Sin embargo, las herramientas y entornos de desarrollo modernos como Visual Studio incluyen
características que permiten a los miembros del equipo recorrer el código mirando los valores de las
variables y observando cómo cambian. Esto hace que la localización de errores sea un proceso mucho
más fácil y más lógico. Otras características y herramientas que proporcionan una lista de los
procedimientos de código que se ejecutan y la forma en que el procesador del equipo informático los
maneja, ayudan al equipo a localizar errores. Además, el equipo puede agregar instrumentación (como
código para escribir eventos en archivos de registro) que supervisará el código mientras se ejecuta y
ayudará a localizar errores.

También es común que durante las pruebas de aceptación el cliente solicite cambios en características
de la aplicación a fin de ajustar el software exactamente a sus requisitos. El desarrollador
implementará estos cambios, generalmente según una revisión de los requisitos y un estudio detallado
del impacto que los cambios pueden tener sobre el resto del software. Un buen diseño original que
separe correctamente las responsabilidades de cada componente facilitará la implementación de
cambios sin afectar otras partes de la aplicación.

El ciclo de vida de desarrollo de software es un proceso iterativo, y muchas de las tareas descritas se
repiten a medida que el desarrollo continúa. Por ejemplo, durante el desarrollo el equipo puede crear
varias versiones completadas por partes del software o los componentes y luego mejorarlas o
cambiarlas según los resultados de las pruebas y los comentarios del cliente.

 Trabajar como parte de un equipo

Algunos desarrolladores trabajan solos o en grupos pequeños, mientras que otros trabajan en equipos
organizados grandes. Como individuo o en un equipo pequeño, el desarrollador puede ser
responsable de todas las tareas del ciclo de vida de desarrollo, incluidos diseño, pruebas,
implementación y mantenimiento. En los equipos grandes normalmente hay grupos separados
responsables del diseño, pruebas, implementación y mantenimiento, y así el desarrollador se centrará
más en la tarea central de escribir código.

Los equipos más grandes por lo general operan de forma estructurada para poder administrar y
supervisar el ciclo de vida de desarrollo y el proceso de desarrollo. Existen muchos enfoques distintos
para administrar el desarrollo de software en un equipo, incluido el ciclo tradicional orientado al
diseño que se basa en tareas planeadas previamente que se siguen una a otra (el enfoque de “cascada”)
y el enfoque más orientado a comentarios donde la planeación se ejecuta en paralelo con tareas de
desarrollo según la información regular del cliente (el enfoque “ágil”). En la figura 4 se muestran estos
dos enfoques principales para el desarrollo de software.

Figura 4: comparación de los procesos de desarrollo “en cascada” y “ágil”

Independientemente del enfoque de desarrollo que se use, es esencial la buena comunicación entre
los miembros del equipo y los administradores de proyectos. Aunque muchos equipos se ubican en
un solo lugar, cada vez es más común que estos incluyan miembros ubicados geográficamente en
otro lugar y que en las reuniones se utilicen instalaciones para teléfono y videoconferencia. Las
reuniones programadas en forma regular a las que asisten todos los miembros del equipo, incluidos
desarrolladores, diseñadores de software (arquitectos), evaluadores y administración de proyectos, se
usan para analizar el progreso, para planear actividades y para recibir comentarios de otros miembros
del equipo y clientes. Esto garantiza que los desarrolladores estén bien informados sobre la evolución
inevitable del diseño de software y que puedan actuar según los comentarios regulares que pueden
afectar la implementación del software.

Fases del proceso de desarrollo de software

Esquema desarrollo software.

Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los
clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y
experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o
contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS,

Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios
estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se
plasman las principales entidades que participarán en el desarrollo del software. La captura, análisis y
especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en
gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo
para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de Requisitos. La IEEE
Std. 830-1998 normaliza la creación de las Especificaciones de Requisitos Software (Software
Requirements Specification).

Diseño y arquitectura
Se refiere a determinar cómo funcionará de forma general sin entrar en detalles. Consiste en
incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se
definen los casos de uso para cubrir las funciones que realizará el sistema, y se transforman las
entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a
la programación orientada a objetos.

Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero
no es necesariamente la porción más larga. La complejidad y la duración de esta etapa está
íntimamente ligada al o a los lenguajes de programación utilizados.

Pruebas
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación.
Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma
integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas
por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de
lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de
organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que
desconozca el tema de pruebas, de esta forma se evalúa que la documentación] entregada sea de
calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace
las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por
programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones
puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no
consideraría.

Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del
proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales
técnicos, etc.; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y
ampliaciones al sistema.
Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede
llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería
de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en
arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De
manera similar, alrededor de 2/3 de toda la Ingeniería civil, Arquitectura y trabajo de construcción es
dar mantenimiento.

Se puede decir que con la mejora continua garantiza la calidad del producto, ya que el estarla aplicando
día con día es la mejor decisión que puede llegar a tener cualquier empresa, porque de esta manera
evita grandes problemas en la elaboración o desarrollo de los productos. Esto es fundamental para
todas las empresas ya que se vuelven competitivas, con mayor productividad y eficiencia. No hay que
olvidar que la mejora se da porque el cliente es el rey y hay que satisfacer todas y cada una de sus
necesidades siempre garantizando la calidad.

Importancia
Actualmente la transición que estamos viviendo hacia una sociedad del conocimiento ha cambiado
profundamente las relaciones entre las personas, empresas y gobiernos: las empresas usan la red para
comunicarse con los clientes, utilizan también herramientas de gestión del conocimiento para hacer
más eficientes, los gobiernos mejoran su presencia en Internet y los servicios a los ciudadanos a través
de la red, los usuarios usan las herramientas para sus relaciones personales, etc. Se va de forma
imparable hacia una sociedad altamente interconectada donde el eje fundamental es la información.

El software es el intermediario cada vez más grande entre la información y la inteligencia humana.
De la misma manera que preocupa para poder acceder a la información, si existe la censura, es tema
de preocupación de quien controla este intermediario y las garantías de su transparencia y
confiabilidad.

En principio, el software es un programa informático o conjunto de ellos que tiene un fin

determinado, es el de procesar los textos que usamos, el controlador de grabación de nuestros
espacios favoritos o las aplicaciones que permiten operar un teléfono móvil.

Está compuesto por un conjunto de instrucciones que el usuario realiza para ejecutar una función
específica. Normalmente los programadores escriben en un lenguaje en el que todos pueden entender
y que después es traducido al lenguaje binario el único que las máquinas entienden. El conjunto de
órdenes en el lenguaje que todos trabajan se llaman código fuente.

Si no se accede al código solo se puede usar el programa, no se puede ver cómo está hecho o
introducir comentarios. Un ejemplo muy utilizado es el de la receta de cocina, en el que el código
fuente son las instrucciones que permite confeccionar un plato. Sin la receta solo se pude degustar el
plato, pero no se sabe si se le añade algo vaya en contra de algunos de esos ingredientes ya que se
desconocen su composición y proporción. En este sentido, el código fuente juega un papel
fundamental en la manera como se debe entender el software.

Se podrían poner varios ejemplos para entender dicha importancia. A finales de los 90 se pudo ver
en todo el mundo la preocupación por parte de empresa y gobiernos por las consecuencias que podían
tener el llamado efecto 2000. El famoso error informático era debido al hecho de que muchos
programas almacenaban la parte de la fecha correspondiente al año utilizando únicamente dos dígitos,
de tal manera, que después del año 99 (el 1999) podíamos pasar al año 00 (¿año 2000 o año 1900?)
Causando todo tipo de errores en el cálculo de período de tiempo.

Los ordenadores de las empresas eléctricas, centrales nucleares, sistema de control de aviación,
bancos y en general, todo el software de uso cotidiano, tuvieron que ser revisados. Finalmente algunas
aplicaciones fueron corregidas, otras ya funcionaban correctamente y no hubo que lamentar ninguna
catástrofe, pero hubo miles de predicciones apocalípticas sobre las consecuencias que se podría llegar
a obtener este error, así podría haber sido si no se hubiera reparado a tiempo.

Es por eso, el software tiene un papel muy importante en la sociedad sobre manera garantizar
métodos trasparentes en sus diferentes fases de producción y explotación.

Modelos del Proceso de Desarrollo Software

No existe consenso sobre cuál es el mejor modelo del proceso software. Distintos equipos de
desarrollo pueden utilizar diferentes modelos de proceso software para producir el mismo tipo de
sistema software. Sin embargo, algunos modelos son más apropiados para producir ciertos tipos de
sistemas, de forma que si no se utiliza un modelo adecuado puede ocurrir que el sistema software
resultante sea de menor calidad.

El reparto de costes entre las distintas fases del proceso de desarrollo es difícil de determinar dado
los distintos modelos de proceso existentes. Sin embargo, en dependencia del modelo que se adopte,
al menos el 60% del coste total se emplea en la actividad de evolución del sistema. La estimación de
este porcentaje es pesimista, ya que la tasa de crecimiento de nuevos productos software es mucho
mayor que la tasa de productos software que quedan en desuso (no tienen que ser mantenidos), por
lo que el número de operaciones de mantenimiento que se realizan sigue aumentando. El proceso de
diseño software debería, por tanto, tener en cuenta la posterior evolución del sistema.

Las características deseables de un proceso de desarrollo software son:

 Claridad: El proceso de desarrollo es claro cuando se entiende con facilidad.
 Visibilidad: Un proceso de desarrollo es visible cuando sus actividades producen resultados
claros identificables externamente.
 Facilidad de soporte: Exige disponer de herramientas CASE (Computer-Aided Software
Engineering) que den soporte a todas o alguna de las actividades del proceso de desarrollo.
 Fiabilidad: Un proceso de desarrollo es fiable cuando es capaz de detectar posibles errores.
 Facilidad de mantenimiento: Requiere capacidad para incorporar nuevos requisitos o
modificar alguno o algunos de los existentes.
 Rapidez: Un proceso software es rápido cuando se puede obtener, a partir de la
especificación, una implementación del sistema en un tiempo reducido.

Modelo en cascada o convencional

Tomado de otras ingenierías es el primer modelo de desarrollo software propuesto. Ampliamente
usado en la industria por su facilidad de gestión y visibilidad. En la figura 1 se representa el secuencia
miento de las actividades de este modelo de desarrollo.

Figura 1: Modelo en cascada o convencional.

Sin embargo, su principal problema reside en su poca flexibilidad al separar el proceso de desarrollo
en etapas totalmente distintas. En la práctica estas etapas no tienen fronteras tan bien definidas, lo
que hace que, en no pocas ocasiones, se solapen y compartan información.
Los principales problemas de este modelo son: dificultad para realizar prototipos, reutilizar software
y realizar pruebas sin disponer de una implementación del sistema.

Modelo evolutivo
En este modelo se entrelazan las actividades de especificación, desarrollo y validación. Inicialmente,
se desarrolla rápidamente un sistema inicial a partir de una especificación muy abstracta. El sistema
se va refinando con la información que van suministrando los clientes y/o usuarios hasta que se
obtiene un sistema final que satisfaga todas las necesidades previstas. El sistema final obtenido puede
rediseñarse para producir otro más robusto y más fácil de mantener. En la figura 2 se esquematiza
este modelo.

Figura 2: Modelo evolutivo.

Existen dos tipos de procesos de desarrollo evolutivos:

Exploratorio: Su objetivo es trabajar con el cliente para identificar y construir el sistema final a partir
de una especificación informal. El resultado del proceso es el sistema final.

Prototipado desechable: Su objetivo es entender los requisitos del cliente. El resultado del proceso es
la especificación del sistema (el prototipo se deshecha).

Los principales problemas de este modelo son: escasa visibilidad; los continuos cambios que hacen
que los sistemas desarrollados estén deficientemente estructurados; y la necesidad de disponer, en
muchos casos, de un equipo de desarrollo altamente calificado. Estos problemas hacen que la
aplicación de este modelo se suela limitar a sistemas interactivos de tamaño pequeño o mediano. La
deficiente estructura dificulta las tareas de mantenimiento de ahí que se suela aplicar a sistemas con
una vida corta y a partes de grandes sistemas, especialmente a sistemas de inteligencia artificial y a
interfaces de usuario.

Modelo transformacional
Se basa en disponer de una especificación formal del sistema y en transformar, con métodos
matemáticos, esta especificación en una implementación. Si las transformaciones que se aplican son
correctas es posible asegurar que el sistema construido satisface la especificación, es decir, es posible
obtener programas correctos por construcción.
 Figura 3: Modelo transformacional.

Otra de sus ventajas es la posibilidad de realizar el mantenimiento a nivel de especificación. Por lo

que es necesario disponer de una especificación inicial correcta y de diseñadores altamente calificados.
Además no existe apenas experiencia en la aplicación de este modelo a grandes proyectos.

Modelo basado en reutilización: En este modelo se supone que alguno de los componentes del
sistema final ya existe. El proceso de desarrollo se centra en integrar las partes ya existentes más que
en construir todo el sistema desde el principio.

Las ventajas que desde un punto de vista económico puede producir este modelo actualmente
empiezan a ser estudiadas en profundidad. Prácticamente no existe experiencia sobre el empleo de
este modelo, si bien, se están haciendo numerosos estudios e investigaciones para posibilitar su uso.

Modelo en espiral
Desarrollado por Boehm en el año 1988 con el objetivo de reunir las ventajas de los modelos de
proceso software en cascada y de prototipado. Se incluye el análisis de riesgo como una parte
importante del proceso de desarrollo software.

El modelo tiene la forma de una espiral en la que cada vuelta representa cada una de las fases en las
que se estructura el proceso software y está organizada en cuatro sectores:

1. Definición de objetivos, alternativas y restricciones de cada fase del proyecto.

2. Evaluación de alternativas y análisis de riesgos.
3. Desarrollo y validación. Se elige el modelo de proceso de desarrollo que se considere más adecuado.
4. Planificación de las siguientes fases del proyecto.

Figura 4: Modelo en espiral.

Bibliografía

https://sites.google.com/site/metdlgsddesarrollodesoftware/antecedentes
https://www.monografias.com/trabajos39/desarrollo-del-software/desarrollo-del-software2.shtml
https://www.ecured.cu/Desarrollo_de_software
https://msdn.microsoft.com/es-es/hh126359.aspx
http://sofware1nathalygrijalva.blogspot.com/2012/10/modelo-espiral.html
https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
http://metodologiadesoftware.blogspot.com/2012/11/fases-del-modelo-rup_27.html
https://es.slideshare.net/jcabot/mdd-desarrollo-de-software-dirigido-por-modelos-que-
funciona-de-verdad
http://todounidad3fsi.blogspot.com/2014/04/31-modelo-en-cascada_2303.html