Modelos de

Desarrollo de
Software
Juan Gerardo Rosales Lpez
Prof.: Juan Carlos Morales Ponce

Modelos de Desarrollo de
Software
Introduccin.
Un modelo para el desarrollo de software es una representacin abstracta de
un proceso. Cada modelo representa un proceso desde una perspectiva
particular y as proporcione informacin parcial sobre el proceso. A continuacin
les dejare los modelos de desarrollo de software, sus etapas, sus problemas y
unos esquemas que explican cmo funcionan.
1.- El modelo de codificar y fijar
El modelo bsico usado en los primeros das del desarrollo de software, tiene
dos pasos:
(1) Escribir algn cdigo.
(2) Fijar los problemas en el cdigo.
As, el orden de los pasos era fabricar algn cdigo primero y pensar sobre los
requerimientos, diseo, prueba y mantencin a continuacin.
Este modelo tiene las dificultades de presentar una baja estructuracin del
cdigo luego de alguna cantidad de fijaciones, pese a que se puede desarrollar
un software de calidad, es posible que ste tenga una correspondencia muy
pobre con las reales necesidades del usuario y, finalmente, si no existe la
conciencia de la necesidad real de pruebas y modificaciones el costo de las
sucesivas fijaciones ser muy alto.

2.- modelo de etapas

En 1956, el enfrentarse a un gran sistema de software como el SemiAutomated Ground Environment (SAGE) hizo que se reconocieran los
problemas inherentes a la codificacin y esto llev al desarrollo del modelo de
etapas, con el objetivo de poder mejorar estos nuevos problemas. Este modelo
estipula que el software ser desarrollado en sucesivas etapas la cuales son:

Plan operativo

Etapa donde se define el problema a resolver, las metas del proyecto, las
metas de calidad y se identifica cualquier restriccin aplicable al proyecto.
Especificacin de requerimientos
Permite entregar una visin de alto nivel sobre el proyecto, poniendo nfasis en
la descripcin del problema desde el punto de vista de los clientes y
desarrolladores. Tambin se considera la posibilidad de una planificacin de los
recursos sobre una escala de tiempos.

Especificacin funcional

Especifica la informacin sobre la cual el software a desarrollar trabajar.

Diseo

Permite describir como el sistema va a satisfacer los requerimientos. Esta

etapa a menudo tiene diferentes niveles de detalle. Los niveles ms altos de
detalle generalmente describen los componentes o mdulos que formarn el
software a ser producido. Los niveles ms bajos, describen, con mucho detalle,
cada mdulo que contendr el sistema.

Implementacin

Aqu es donde el software a ser desarrollado se codifica. Dependiendo del

tamao del proyecto, la programacin puede ser distribuida entre distintos
programadores o grupos de programadores. Cada uno se concentrar en la
construccin y prueba de una parte del software, a menudo un subsistema. Las
pruebas, en general, tiene por objetivo asegurar que todas las funciones estn
correctamente implementadas dentro del sistema.

Integracin

Es la fase donde todos los subsistemas codificados independientemente se

juntan. Cada seccin es enlazada con otra y, entonces, probada. Este proceso
se repite hasta que se han agregado todos los mdulos y el sistema se prueba
como un todo.

Validacin y verificacin

Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es
probado para verificar que el sistema es consistente con la definicin de
requerimientos y la especificacin funcional. Por otro lado, la verificacin
consiste en una serie de actividades que aseguran que el software implementa
correctamente una funcin especfica. Al finalizar esta etapa, el sistema ya
puede ser instalado en ambiente de explotacin.

Mantencin

La mantencin ocurre cuando existe algn problema dentro de un sistema

existente, e involucrara la correccin de errores que no fueron descubiertos en
las fases de prueba, mejoras en la implementacin de las unidades del sistema
y cambios para que responda a los nuevos requerimientos. Las mantenciones
se puede clasificar en: correctiva, adaptativa, perfectiva y preventiva.
El modelo de etapas consideraba que cada una de ellas debera ir a
continuacin de la anterior, poniendo nfasis en la documentacin que resulta
de cada una y que es la entrada de la siguiente, formalizando los
procedimientos de planificacin y de control. Todo tendiente a conformar una
cadena de produccin de software, de manera similar a una cadena de montaje
de automviles.

3.- Modelo de fases para el ciclo de vida de desarrollo de productos de

programacin
El anlisis consta de dos subfases: planeacin y definicin de requisitos. Los
productos de la planeacin son la Definicin del Sistema y el Plan del Proyecto. La
Definicin, por lo regular, se expresa en espaol o en algn otro lenguaje natural, y
puede contener cuadros, figuras, grficas y ecuaciones de distintos estilos. La
notacin exacta empleada en la Definicin depende mucho del rea del problema.
Obviamente, en un sistema de contabilidad se usa diferente terminologa que en uno
de control de procesos.

4.- El modelo de cascada

El modelo de cascada es tambin conocido como Modelo en cascada o
Modelo lineal secuencial o Ciclo de vida bsico o Ciclo de vida clsico.
Es un refinamiento altamente influenciado para 1970 del modelo de etapas.
Existe, para este modelo, un reconocimiento de los ciclos de retroalimentacin
entre etapas, y una gua para confinar las retroalimentaciones a las etapas
sucesivas con el objetivo de minimizar el costo del retrabajo involucrado en
retroalimentaciones a travs de muchas etapas.
Las ventajas que presentan tanto el modelo de etapas y de cascada tiene
relacin con la idea de postular un marco de trabajo claro, que reconoce y
define las actividades involucradas en el desarrollo de software, permitiendo
establecer relaciones de cooperacin entre ellas. Corresponden, tambin, a los
mtodos ms usados en desarrollo de software y que han sido exitosos durante
dcadas tanto en el desarrollo de grandes sistemas como en el de pequeos.
Etapas

Ingeniera y anlisis del sistema.

Interrelacin con hardware, personas, bases de datos. (Documentar cada

paso.)

Anlisis de los requisitos del software.

Hay que comprender el mbito de la informacin del software, as como la

funcin, el rendimiento y las interfaces requeridas.

Diseo.

La estructura de los datos, la arquitectura del sw, el detalle procedimental, y la

caracterizacin de la interface.

Codificacin.

Traducir el diseo para que lo entienda la mquina.

Prueba.

Cuando ya se ha generado el cdigo.

Mantenimiento.

El software sufrir cambios despus de que se entregue al cliente.

Problemas:
1. No siempre se sigue el flujo secuencial.
2. Es difcil tener un 100% de los requisitos al inicio.
3. El cliente debe tener paciencia. Los primeros resultados sern hasta que ya
est operando el sistema.

5.-Modelo de desarrollo orientado a prototipos

Si bien algunos autores consideran que esto es parte del ciclo de vida clsico
(Boehm, 1988), es tambin posible verlo como un mtodo independiente .
Las ventajas de un enfoque de desarrollo orientado a prototipos estn dadas
por: reduccin de la incertidumbre y del riesgo, reduccin de tiempo y de
costos, incrementos en la aceptacin del nuevo sistema, mejoras en la
administracin de proyectos, mejoras en la comunicacin entre desarrolladores
y clientes, etc.
Si bien, el desarrollo orientado a prototipos tiene considerables ventajas,
tambin presenta desventajas como: la dependencia de las herramientas de
software para el xito ya que la necesidad de disminucin de incertidumbre
depende de las iteraciones del prototipo, entre ms iteraciones existan mejor y
esto ltimo se logra mediante el uso de mejores herramientas lo que hace a
este proceso dependiente de las mismas. Tambin, no es posible aplicar la
metodologa a todos los proyectos de software y, finalmente, la mala
interpretacin que pueden hacer los usuarios del prototipo, al cual pueden
confundir con el sistema terminado.
Las fases que comprende el mtodo de desarrollo orientado a prototipos
seran:

Investigacin preliminar

Las metas principales de esta fase son: determinar el problema y su mbito, la

importancia y sus efectos potenciales sobre la organizacin por una parte y, por
otro lado, identificar una idea general de la solucin para realizar un estudio de
factibilidad que determine la factibilidad de una solucin software.

Definicin de los requerimientos del sistema

El objetivo de esta etapa es registrar todos los requerimientos y deseos que los
usuarios tienen en relacin al proyecto bajo desarrollo. Esta etapa es la ms
importante de todo el ciclo de vida, es aqu donde el desarrollador determina
los requisitos mediante la construccin, demostracin y retroalimentaciones del
prototipo. Por lo mismo esta etapa ser revisada con ms detalle luego de esta
descripcin.

Diseo tcnico

Durante la construccin del prototipo, el desarrollador ha obviado el diseo

detallado. El sistema debe ser entonces rediseado y documentado segn los
estndares de la organizacin y para ayudar a las mantenciones futuras. Esta
fase de diseo tcnico tiene dos etapas: por un lado, la produccin de una
documentacin de diseo que especifica y describe la estructura del software,
el control de flujo, las interfaces de usuario y las funciones y, como segunda
etapa, la produccin de todo lo requerido para promover cualquier mantencin
futura del software.

Programacin y prueba

Es donde los cambios identificados en el diseo tcnico son implementados y

probados para asegurar la correccin y completitud de los mismos con
respecto a los requerimientos.

Operacin y mantencin

La instalacin del sistema en ambiente de explotacin, en este caso, resulta de

menor complejidad, ya que se supone que los usuarios han trabajado con el
sistema al hacer las pruebas de prototipos. Adems, la mantencin tambin
debera ser una fase menos importante, ya que se supone que el refinamiento
del prototipo permitira una mejor claridad en los requerimientos, por lo cual las
mantenciones perfectivas se reduciran. Si eventualmente se requiriese una
mantencin entonces el proceso de prototipado es repetido y se definir un
nuevo conjunto de requerimientos.
La fase ms importante corresponde a la definicin de requerimientos, la cual
correspondera a un proceso que busca aproximar las visiones del usuario y del
desarrollador mediante sucesivas iteraciones. La definicin de requerimientos
consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:

Anlisis grueso y especificacin

El propsito de esta subfase es desarrollar un diseo bsico para el prototipo

inicial.

Diseo y construccin

El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe

concentrarse en construir un sistema con la mxima funcionalidad, poniendo
nfasis en la interface del usuario.

Evaluacin

Esta etapa tiene dos propsitos: extraer a los usuarios la especificacin de los
requerimientos adicionales del sistema y verificar que el prototipo desarrollado
lo haya sido en concordancia con la definicin de requerimientos del sistema.
Si los usuarios identifican fallas en el prototipo, entonces el desarrollador
simplemente corrige el prototipo antes de la siguiente evaluacin. El prototipo
es repetidamente modificado y evaluado hasta que todos los requerimientos del
sistema han sido satisfechos. El proceso de evaluacin puede ser dividido en
cuatro pasos separados: preparacin, demostracin, uso del prototipo y
discusin de comentarios. En esta fase se decide si el prototipo es aceptado o
modificado.

Modificacin

Esto ocurre cuando la definicin de requerimientos del sistema es alterada en

la subfase de evaluacin. El desarrollador entonces debe modificar el prototipo
de acuerdo a los comentarios hechos por los usuarios.

Trmino

Una vez que se ha desarrollado un prototipo estable y completo, es necesario

ponerse de acuerdo en relacin a aspectos de calidad y de representacin del
sistema.

6.- El modelo de desarrollo evolutivo

El desarrollo evolutivo es una metodologa de desarrollo de software muy
relacionada con, pero claramente distinta de, desarrollo por prototipos. El
nfasis esta puesto sobre la importancia de obtener un sistema de produccin
flexible y expandible. As, si los requerimientos cambian durante el desarrollo
del sistema, entonces con un mnimo de esfuerzo y tiempo se puede
desarrollar un sistema de trabajo flexible.

Pero, existiran algunas dificultades tcnicas que no pueden dejar de ser

mencionadas, por ejemplo:
- No facilita la integracin de aplicaciones que han sido desarrolladas como
sistemas independientes.
- Facilita la posibilidad de que existan casos de "esclerosis de informacin", en
el sentido que trabajos temporales alrededor de algunas deficiencias del
software se solidifican como poderes inmodificables a la evolucin. Es decir, en
la medida que se evoluciona, esta misma facilidad a la evolucin llevara a que
no sea posible seguir evolucionando.
- Pueden ocurrir que el software nuevo es un reemplazo incremental de un
subsistema dentro de un gran sistema existente. Si el sistema existente est
pobremente modularizado, entonces es obvia la dificultad en hacer que la
nueva versin se acople con facilidad al resto.
Lehman propone que la evolucin de un sistema de software esta sujeta a
varias leyes. Ha determinado estas leyes a partir de observaciones
experimentales de varios sistemas, como los grandes sistemas operativos (...).
Dice Lehman que hay cinco leyes de la evolucin de los programas:

Cambio Continuo.

Un programa que se utiliza en un ambiente del mundo real debe cambiar o ser
cada vez menos til en ese ambiente.

Complejidad creciente.

A medida que un programa en evolucin cambia, su estructura se hace ms

compleja, a menos que se lleven a cabo esfuerzos activos para evitar este
fenmeno.

Evolucin del programa.

La evolucin del programa es un proceso autorregulador, y una medicin de

atributos del sistema, como el tamao, el tiempo entre versiones, el nmero de
errores advertidos, etc., revela las tendencias estadsticas significativas y las
caractersticas invariantes.

Conservacin de la estabilidad organizativa.

Durante el tiempo de vida de un programa, su rapidez de desarrollo es casi

constante e independiente de los recursos dedicados al desarrollo del sistema.

Conservacin de la familiaridad.

Durante el tiempo de vida de un sistema, la evolucin del cambio del sistema

en cada versin es, aproximadamente, constante.

7.- El modelo de transformacin

Desde la perspectiva de la evolucin del software y las leyes de Lehman, se
hace una revisin del ciclo de vida del software, el cual lleva al desarrollo de un
mtodo que se podra denominar el modelo de transformacin.
Desde la ptica de lan Sommerville, este modelo se caracteriza por que... un
concepto de aplicacin se transforma de modo paulatino en una especificacin
formal de software. Esto implica la reduccin de la cantidad de informacin
bruta en cada etapa de la transformacin, proceso que el denomina
abstraccin. Una vez establecida la especificacin, se aade la informacin (a
esto le llama materializacin) y el sistema abstracto se transforma, mediante un
conjunto de notaciones formales, en un programa operacional.
La clasificacin ...est basada en el reconocimiento de el hecho que,...,
cualquier programa es un modelo de un modelo dentro de una teora de un
modelo de una abstraccin de alguna porcin del mundo o de algn universo
del discurso. La clasificacin categoriza a los programas en tres clases, S, P y
E....

Programas-S.
Los Programa-S son aquellos cuya funcin puede ser definida formalmente por
y derivable desde, una especificacin.... Las sentencias del problema, el
programa y la solucin, cuando es obtenida, puede relacionarse con un mundo
externo. Pero esto es una relacin casual y no causal. En efecto, cuando esto
existe somos libres para cambiar nuestro inters y redefinir el problema. Pero el
resultado de esto es un nuevo programa para esta solucin. Puede ser posible
y eficiente derivar el nuevo programa desde el antiguo. Pero es un programa
diferente que define una solucin para un problema diferente.

Programas - P

En los Programas - P (solucin de problemas del mundo real)... a despecho de

el hecho de que el problema a ser resuelto pueda ser definido precisamente, la
aceptacin de la solucin est determinada por el medio ambiente en que est
involucrada. La solucin obtenida ser evaluada por comparacin con el medio
ambiente real... En los Programas - S, el juicio sobre la correccin, y por lo
tanto el valor, del programa est relacionado con la definicin solamente de
esta especificacin, las sentencias del problema que debe ser reflejado. En los
Programas - P, el asunto no est centrado en el problema pero si sobre el valor
y la validez de la solucin obtenida, esto es sobre el contexto del mundo real.

Programas - E.
La tercera clase, los Programas - E, estn inherentemente ms inclinados al
cambio. Estos son programas que mecanizan una actividad humana o social...
La instalacin de los programas junto con este sistema asociado -...- cambia la
real naturaleza del problema a ser resuelto, el programa puede hasta
convertirse en parte del mundo que el mismo modela, est embebido en l...No
como otros sistemas artificiales donde,..., el cambio es ocasional, aqu este
aparece continuamente. La presin del cambio est construida con l.... Los
Programas P y E estn estrechamente relacionados, podemos establecer la
clase unin de P y E como Programas-A. stos difieren de los Programas-S en
el sentido que representan una aplicacin computacional en el mundo real.

8.- Modelo Espiral

El modelo Espiral de Boehm para Ingeniera de Software agrupa las mejores
caractersticas del modelo del ciclo de vida clsico y de prototipos. Pero
tambin agrega nuevas funciones que no estn incluidas en los otros modelos,
como el anlisis de riesgo. El modelo espiral define cuatro actividades
principales para el ciclo de vida.
Planificacin
La determinacin de los objetivos del proyecto, alternativas y restricciones.
Anlisis de Riesgo
El anlisis de alternativas y la identificacin y solucin de riesgos.
Ingeniera
Desarrollo del producto.
Evaluacin del cliente
El asentimiento de los resultados de la ingeniera.
Este modelo reconoce la necesidad de la revisin regular de un desarrollo
conforme este progresa y sus requerimientos etc. Pero, por desgracia,
cambian. El ciclo de vida evolutivo se representa por lo general mediante un
modelo de "espiral" o caracol.

Al usar el modelo, cada incremento de trabajo pasa por las siguientes

etapas:

Una revisi6n de los objetivos percibidos.

Aseguramiento de los riesgos para cada una de las opciones de la

siguiente etapa de trabajo.

Plan para el desarrollo de la opci6n seleccionada.

Desarrollo.