MODELOS DE DESARROLLO EN INGENIERIA

DE SOFTWARE




JONATHAN STEVEN DORADO SUAREZ
CODIGO 0108091102




ALVARO SALCEDO
INGENIERIA DE SOFTWARE



UNIVERSIDAD COOPERATIVA DE COLOMBIA
FACULTAD DE INGENIERIA
PROGRAMA DE SISTEMAS
SEMPTIEMBRE 6 DE 2011 BOGOTA D.C
1. MODELO PRESCRIPTIVO DEL PROCESO
Los modelos prescriptivos de software fueron ideados originalmente para ordenar
el caos del desarrollo de software, y la historia nos muestra que el uso de estos
han trado tanto un camino a seguir en el desarrollo de software as como
estructuras tiles, aunque el trabajo de ingeniera de software y el producto
resultante siguen estando en un punto entre el orden y el caos lo cual indica que
no se est en la estructura completa y que puede haber cierta dosis de creatividad
en el desarrollo de software y no se est en la desorganizacin total de manera
que puede seguirse un camino predecible para el proyecto.

Los modelos prescriptivos de software nos definen un conjunto de tareas
actividades, productos de trabajo que se requieren para desarrollar productos de
calidad que son importantes para llevar control, estabilidad y organizacin a una
actividad que tiende a ser catica, el modelo prescriptivo llena el marco de trabajo
con conjuntos de tareas explicitas para las acciones de la ingeniera de software.
Se debe considerar que aunque un proceso sea prescriptivo esto no se debe
asumir como esttico, estos se deben adaptar al personal, al proyecto y al
problema.

Los modelos son llamados prescriptivos ya que prescriben una serie de elementos
de proceso as como su flujo de trabajo, cada uno de los modelos se ajustan al
marco de trabajo estndar pero cada uno aplica diferencias a cada una de las
actividades y a su flujo de trabajo.

2. MODELO DE CASCADA
Llamado tambin Lineal secuencial. Proporciona una simple visin del desarrollo
del Software. A los procesos los representa como fases separadas y secuenciales
en tiempo.
Antes de codificar se debe disear el software, adems probarlo antes de
construirlo y ponerlo en operacin.

FASES DEL MODELO CASCADA

ngeniera y Anlisis del Sistema
Anlisis de los Requisitos
Diseo
Codificacin
Prueba
Mantenimiento
Ingeniera y AnIisis deI Sistema: Anlisis y de diseo de todos los
componentes del sistema computacional.

AnIisis de Requisitos Software: Se debe conocer que necesita el usuario para
saber que necesidades debemos cubrir.

Diseo: En esta fase se realizan los algoritmos necesarios para que se cumplan
los requerimientos del usuario as como tambin los anlisis necesarios para
saber que herramientas usar en la etapa de Codificacin. Se dividen en:

1. Diseo de Alto Nivel o Arquitectnico
2. Diseo Detallado

Codificacin: Es la fase de programacin propiamente dicha.

Pruebas: Las componentes una vez programadas, se ensamblan para formar el
sistema y se demuestra que trabaja correctamente antes de ser puesto en prctica
por el usuario.

Existen varios tipos de Pruebas:

* Pruebas de unidad
* Pruebas de integracin
* Pruebas de sistema.
* Pruebas de aceptacin

Mantenimiento: El software necesitar cambios despus de la entrega. Los tipos
de mantenimiento son:

* Mantenimiento Preventivo y Perfectivo
* Mantenimiento Correctivo
* Mantenimiento Evolutivo

VENTAJAS DEL MODELO CASCADA

1. Modelo y planificacin fcil y sencilla.
2. Sus fases son conocidas por los desarrolladores.
3. Los usuarios lo pueden comprender fcilmente.

DESVENTAJAS DEL MODELO CASCADA

1. Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y
en el diseo.
2. Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa
conocida.

3. MODELO EN ESPIRAL
El modelo en espiral del proceso del software que originalmente fue propuesto por
Boehm (1988), El modelo en espiral es una de las metodologas ms
recomendables para el desarrollo y creacin de un programa, ya que consta de
pocas etapas o fases, las cuales se van realizando en una manera continua y
cclica.

Cada ciclo de la espiral se divide en 4 etapas:

DEFINICION DE OBJETIVOS: Para esta fase del proyecto se definen los
objetivos
especficos. Se identifican las restricciones del procesos y el producto, y se
estipula un plan detallado de administracin. Se identifican los riesgos del
proyecto. Dependiendo de esos riesgos, se planean estrategias alternativas.

EVALUACION Y REDUCCION DE RIESGOS: Se lleva a cabo un anlisis
detallado para cada uno de los riesgos del proyecto. Se definen los pasos para
reducir dichos riesgos. Por ejemplo si existe el riesgo de tener requerimientos
inapropiados, se desarrolla un prototipo del sistema.

DESARROLLO Y VALIDACION: Despus de la evaluacin de riesgos, se elige un
modelo para el desarrollo del sistema. Por ejemplo, si los riesgos en la interfaz de
usuario son dominantes, un modelo de desarrollo apropiado podra ser la
construccin de prototipos evolutivos. Si los riesgos de proteccin son la principal
consideracin, un desarrollo basado en transformaciones formales podra ser el
mas apropiado, y as sucesivamente. El modelo de cascada es el mas apropiado
para el desarrollo si el mayor riesgo identificado es la integracin de los
subsistemas.
PLANEACION: El proyecto se revisa y se toma la decisin de si se debe continuar
con un ciclo posterior de la espiral. Si se decide continuar, se debe planear la
siguiente etapa.

CARACTERISTICAS
-Trata de mejorar los ciclos de vida clsicos y prototipos.
-Este modelo puede combinarse con otros modelos de proceso de desarrollo
(Cascada, evolutivo).
-En cada giro se construye un nuevo modelo del sistema completo.
-El anlisis de riesgo requiere la participacin de personal con alta calificacin.
-ncorpora objetivos de calidad y gestin de riesgos
-Elimina errores y alternativas no atractivas al comienzo
-Permite iteraciones, vuelta atrs y finalizaciones rpidas
-Cada ciclo empieza identificando:
*Los objetivos de la porcin correspondiente
*Las alternativas
*Restricciones

. MODELO ITERATIVO E INCREMENTAL
Los modelos iterativos e incrementales son los cuales disminuyen riesgos y nos
ayudan a tener un mejor desarrollo de software ya que estos modelos se basan
en la retroalimentacin por lo que nos ayudan a tener una mejor arquitectura del
software y son muy tiles cuando el usuario tiene ms requerimientos. En este
modelo aparecen los dos modelos por los cuales nosotros podemos aumentar o
modificar el software si se necesita.
EI modeIo incrementaI: Este modelo mantiene la funcin anterior y aumenta otra,
ya que puede ser que el primer incremento no hubiera tenido todos los
requerimientos que necesitaba el proyecto.
EI modeIo iterativo: Este modelo en cambio mejora cada versin es decir mejora
la funcin que tena el software anterior.
Entre las ventajas de estos modelos tenemos que disminuyen riesgos, tambin en
estos modelos nosotros podemos fcilmente cambiar los requerimientos pues
como nos basamos en una versin a esta la aumentamos o la modificamos.
Tambin reduce costos pues si algo sale mal solo volvemos a la antigua versin y
comenzamos de nuevo. Otra ventaja es que al usuario se le entrega parte del
producto es decir una versin con la cual l puede trabajar.
Algunas desventajas podran ser como que no todo proyecto puede tener
versiones entonces nosotros deberamos saber en qu proyectos usar este
modelo; adems estos necesitan una gran planeacin.

. MODELO DRA (DesarroIIo Rpido de ApIicaciones)
El Desarrollo Rpido 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 adaptacin a "Alta
velocidad en el que se logra el desarrollo rpido utilizando un enfoque de
construccin 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 informacin, el
enfoque DRA comprende las siguientes fases:
ModeIado de gestin: El flujo de informacin entre las funciones de gestin se
modela de forma que responda a las siguientes preguntas: Qu informacin
conduce el proceso de gestin? Qu informacin se genera? Quin la genera?
A dnde va la informacin? Quin la proceso?
ModeIado de datos: El flujo de informacin definido como parte de la fase de
modelado de gestin se refina como un conjunto de objetos de datos necesarios
para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos objetos.
ModeIado de proceso: Los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de informacin necesario para
implementar una funcin de gestin. Las descripciones del proceso se crean para
aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin
entre los objetos.
Generacin de apIicaciones: El DRA asume la utilizacin de tcnicas de cuarta
generacin, en lugar de crear software con lenguajes de programacin de tercera
generacin, 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 automticas
para facilitar la construccin del software.
Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, 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 interfaces a fondo.
Obviamente la limitacin de tiempo impuesto en un proyecto DRA demanda
"mbito en escalas. Si una aplicacin de gestin 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 puede ser afrontada 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 nmero correcto de equipos DRA.
El modelo DRA requiere clientes y desarrolladores comprometidos en las rpidas
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 construccin de los componentes necesarios
para DRA ser problemtico. 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
tcnicos son altos. Esto ocurre cuando una nueva aplicacin hace uso de
tecnologas nuevas, o cuando el nuevo software requiere un alto grado de
interoperabilidad con programas de computadora ya existentes.
El modelo DRA enfatiza el desarrollo de componentes de programas reutilizables.
La reutilizacin es la piedra angular de las tecnologas de objetos, y se encuentra
en el modelo de proceso de ensamblaje.

6. MODELO CONCURRENTE

El modelo de proceso concurrente se puede representar en forma de esquema
como una serie de actividades tcnicas importantes, tareas y estados asociados a
ellas.
Al principio la actividad de comunicacin con el cliente (no mostrada en la figura)
ha finalizado su primera iteracin y est en el estado de cambios en espera. La
actividad de anlisis (que estaba en el estado ninguna mientras que se iniciaba la
comunicacin inicial con el cliente) ahora hace una transicin al estado bajo
desarrollo. Si el cliente indica que se deben hacer cambios en los requisitos, la
actividad anlisis cambia del estado bajo desarrollo al estado cambios en espera.
El modelo de proceso concurrente define una serie de acontecimientos que
dispararn transiciones de estado a estado para cada una de las actividades.
Durante las primeras etapas del diseo, no se contempla una inconsistencia del
modelo de anlisis. Esto genera la correccin del modelo de anlisis de sucesos,
que disparar la actividad de anlisis del estado hecho al estado cambios en
espera.
El modelo de proceso concurrente se utiliza como paradigma de desarrollo de
aplicaciones cliente/servidor, que cuando se aplica, el modelo de proceso
concurrente define actividades en dos dimensiones: una dimensin de sistemas y
una dimensin de componentes. Los aspectos del nivel de sistemas se afrontan
mediante tres actividades: diseo, ensamblaje y uso.
La dimensin de componentes se afronta con dos actividades: diseo y
realizacin. La concurrencia se logra de dos formas: (1) las actividades de
sistemas y de componentes ocurren simultneamente y pueden modelarse con el
enfoque orientado a objetos; (2) una aplicacin cliente/servidor tpica se
implementa con muchos componentes, cada uno de los cuales se pueden disear
y realizar concurrentemente. En realidad, el modelo de proceso concurrente es
aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta
del estado actual de un proyecto.

7. MODELO DE PROTOTIPOS
Este modelo comienza con la recoleccin de requisitos, el desarrollador y el cliente
definen los objetivos globales para el software, originndose un diseo rpido que
se centra en una representacin de esos aspectos del software que sean visibles
para el usuario/cliente. De este diseo surge la construccin de un prototipo y este
es evaluado por el cliente/usuario. La interaccin ocurre cuando el prototipo
satisface las necesidades del cliente.

CONSTRUCCIN DE PROTOTIPOS.
Otro modelo adicional, como alternativa a los mencionados o bien como
complemento a los mismos es la construccin de prototipos, que consiste en
construir un modelo en computadora, que describa la interaccin sistema - usuario
y que implemente un subconjunto de la funcin requerida, sometindolo a la
revisin por parte del usuario en un proceso iterativo y evolutivo.
Los pasos necesarios para la construccin de prototipos son los siguientes:
. Evaluar la solicitud del software para determinar si el sistema es candidato
para la construccin de un prototipo. Considerando si es necesario
presentar la interaccin usuario-sistema y tomando en cuenta la
complejidad del desarrollo del propio prototipo.
. Elaborar una representacin abreviada de los requisitos. Utilizando alguno
de los modelos mencionados anteriormente.
. Crear un conjunto de especificaciones de diseo para el prototipo,
centrndose en los aspectos de ms alto nivel y no en el detalle.
V. Crear y probar el software del prototipo. De ser posible utilizar herramientas
automatizadas para tal efecto, como lenguajes de cuarta generacin,
mdulos de cdigo reusables, herramientas RAD o paquetes
especializados en prototipos.
V. Presentar el prototipo al usuario y orientarlo a que sea l quien lo "opere.
Aqu es donde el usuario podr validar sus propios requerimientos y
sugerir las modificaciones necesarias.
V. V. Repetir los pasos V y V hasta que todos los requisitos queden
formalizados.

El modelo de construccin de prototipos se recomienda especialmente cuando los
requerimientos cambian frecuentemente, cuando no se tiene la suficiente
participacin del usuario o cuando no se tienen suficientemente especificados los
requerimientos. Una ventaja importante es que el usuario va "viendo la evolucin
del sistema.
El principal inconveniente es que se desconoce el tiempo que se tardar en crear
un producto aceptable. No se sabe cuntas iteraciones se tendrn que realizar.
Otro inconveniente es que se pueden adoptar prcticas de programacin de
prueba-y-error, sin un anlisis y diseo formales previos.
8. MODELO RUP
El Proceso Unificado RacionaI (Rational Unified Process en ingls,
habitualmente resumido como RUP) es un proceso de desarrollo de software y
junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa
estndar ms utilizada para el anlisis, implementacin y documentacin de
sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin.
Tambin se conoce por este nombre al software desarrollado por Rational, hoy
propiedad de BM, el cual incluye informacin entrelazada de diversos artefactos y
descripciones de las diversas actividades. Est incluido en el RationaI Method
Composer (RMC), que permite la personalizacin de acuerdo con las
necesidades.
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso
Unificado, y una especificacin ms detallada, el Rational Unified Process, que
se vendiera como producto independiente.
El RUP est basado en 6 principios clave que son los siguientes:
Adaptar eI proceso
El proceso deber adaptarse a las necesidades del cliente ya que es muy
importante interactuar con l. Las caractersticas propias del proyecto u
organizacin. El tamao del mismo, as como su tipo o las regulaciones que lo
condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta
el alcance del proyecto en un rea subformal.
EquiIibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios
o disputarse recursos limitados. ebe encontrarse un equilibrio que satisfaga los
deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que
surjan en el futuro.
Demostrar vaIor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.
En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad
del producto, y se refina la direccin del proyecto as como tambin los riesgos
involucrados
CoIaboracin entre equipos
El desarrollo de software no lo hace una nica persona sino mltiples equipos.
Debe haber una comunicacin fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
EIevar eI niveI de abstraccin
Este principio dominante motiva el uso de conceptos reutilizables tales como
patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por
nombrar algunos. Esto evita que los ingenieros de software vayan directamente de
los requisitos a la codificacin de software a la medida del cliente, sin saber con
certeza qu codificar para satisfacer de la mejor manera los requisitos y sin
comenzar desde un principio pensando en la reutilizacin del cdigo. Un alto nivel
de abstraccin tambin permite discusiones sobre diversos niveles y soluciones
arquitectnicas. stas se pueden acompaar por las representaciones visuales de
la arquitectura, por ejemplo con el lenguaje UML.
Enfocarse en Ia caIidad
El control de calidad no debe realizarse al final de cada iteracin, sino en todos
los aspectos de la produccin. El aseguramiento de la calidad forma parte del
proceso de desarrollo y no de un grupo independiente.






BIBLIOGRAFIA Y WEBGRAFIA
O http://eIchrboy.bIogspot.com/2010/03/modeIos-prescriptivos-deI-
proceso.htmI
O http://www.mitecnoIogico.com/Main/ModeIoDeCascada
O http://cfIores33.bIogspot.es/119378920/
O http://www.mitecnoIogico.com/Main/ModeIoDesarroIIoRapidoApIicacio
nes
O http://www.mitecnoIogico.com/Main/EIModeIoDesarroIIoConcurrente