Instituto Tecnolgico de Mrida

Departamento de Sistemas Computacionales

Materia

FUNDAMENTOS DE INGENIERIA DE SOFTWARE

Unidad 2

Investigacin metodologas de desarrollo de software

Grupo: 5SD

Alumno:
BR. JORGE ALFREDO CAUICH DIAZ.

METODOLOGIAS DE DESARROLLO SOFTWARE

Modelo de cascada
En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en
cascada, es el enfoque metodolgico que ordena rigurosamente las etapas
del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa
debe esperar a la finalizacin de la etapa anterior. Las etapas que posee este
modelo son:
1. Anlisis de requisitos.
2. Diseo del Sistema.
3. Diseo del Programa.
4. Codificacin.
5. Pruebas.
6. Implantacin.
7. Mantenimiento.
De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce
necesariamente al rediseo y nueva programacin del cdigo afectado,
aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la
metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un
cambio en las fases ms avanzadas de un proyecto.
Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria,
sigue siendo el paradigma ms seguido al da de hoy.
Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada
SRD (documento de especificacin de requisitos), que contiene la especificacin
completa de lo que debe hacer el sistema sin entrar en detalles internos.
Es importante sealar que en esta etapa se debe consensuar todo lo que se
requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no
pudindose requerir nuevos resultados a mitad del proceso de elaboracin del
software.
Diseo del Sistema
Descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado
surge el SDD (Documento de Diseo del Software), que contiene la descripcin de
la estructura relacional global del sistema y la especificacin de lo que debe hacer
cada una de sus partes, as como la manera en que se combinan unas con otras.
Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo
detallado. El primero de ellos tiene como objetivo definir la estructura de la

solucin (una vez que la fase de anlisis ha descrito el problema) identificando

grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus
relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo
define los algoritmos empleados y la organizacin del cdigo para comenzar la
implementacin.
Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de
los requerimientos del usuario as como tambin los anlisis necesarios para
saber que herramientas usar en la etapa de Codificacin.
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos
as como de pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y
componentes reutilizables dentro del mismo proyecto para hacer que la
programacin sea un proceso mucho ms rpido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de
ser entregado al usuario final.
Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el sistema
no falle.
En la creacin de desarrollo de cascada se implementa los cdigos de
investigacin y pruebas del mismo
Mantenimiento
Una de las etapas ms crticas, ya que se destina un 75% de los recursos, es el
mantenimiento del Software ya que al utilizarlo como usuario final puede ser que
no cumpla con todas nuestras expectativas.

Modelo

incremental
Sugiri el enfoque incremental de desarrollo como una forma de reducir la
repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la
toma de decisiones en los requisitos hasta adquirir experiencia con el sistema.
El primer incremento generalmente es un producto esencial denominado ncleo.
En una visin genrica, el proceso se divide en 4 partes:
1. Anlisis
2. Diseo
3. Cdigo
4. Prueba
Sin embargo, para la produccin del Software, se usa el principio de trabajo en
cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o
desecha elementos al final de cada incremento a fin de que el software se adapte
mejor a sus necesidades reales. El proceso se repite hasta que se elabora el
producto completo. De esta forma el tiempo de entrega se reduce
considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada
incremento la entrega de un producto completamente operacional. Este modelo es
particularmente til cuando no se cuenta con una dotacin de personal suficiente.
Los primeros pasos los pueden realizar un grupo reducido de personas y en cada
incremento se aadir personal, de ser necesario. Por otro lado los incrementos
se pueden planear para gestionar riesgos tcnicos.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al
final terminar siendo la solucin completa requerida por el cliente, pero stas
partes no se pueden realizar en cualquier orden, sino que dependen de lo que el
cliente este necesitando con ms urgencia, de los puntos ms importantes del

proyecto, los requerimientos ms bsicos, difciles y con mayor grado de riesgo,

ya que estos se deben hacer al comienzo, de manera que se disminuya la
dificultad y el riesgo en cada versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin) que
podr ser entregada al cliente para que ste pueda trabajar en ella y el
programador pueda considerar las recomendaciones que el cliente efecte para
hacer mejoras en el producto. Estas nuevas mejoras debern esperar a ser
integradas en la siguiente versin junto con los dems requerimientos que no
fueron
tomados
en
cuenta
en
la
versin
anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa
del sistema, seguido de sucesivos incrementos funcionales. Cada incremento
tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad
ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre

el mismo, sino nicamente correccin de errores. Dado que la arquitectura

completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos
completos
al
comienzo
del
desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos,
las funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de
requisitos funcionales y ser el cliente quien se encarga de priorizar que
funcionalidades son ms importantes. Con las funcionalidades priorizadas, se
puede confeccionar un plan de incrementos, donde en cada incremento se indica
un subconjunto de funcionalidades que el sistema entregar. La asignacin de
funcionalidades a los incrementos depende de la prioridad dada a los requisitos.
Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Modelo de espiral

El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida
del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un
esfuerzo del desarrollo por ah mismo comienza otro; adems en cada ejecucin
del desarrollo se sigue cuatro pasos principales:
1. Determinar o fijar los objetivos. En este paso se definen los objetivos
especficos para posteriormente identifica las limitaciones del proceso y del
sistema de software, adems se disea una planificacin detallada de gestin y se
identifican los riesgos.
2. Anlisis del riesgo. En este paso se efecta un anlisis detallado para cada
uno de los riesgos identificados del proyecto, se definen los pasos a seguir para
reducir los riesgos y luego del anlisis de estos riesgos se planean estrategias
alternativas.
3. Desarrollar, verificar y validar. En este tercer paso, despus del anlisis de
riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo
desarrolla.
4. Planificar. En este ltimo paso es donde el proyecto se revisa y se toma la
decisin si se debe continuar con un ciclo posterior al de la espiral. Si se decide
continuar, se desarrollan los planes para la siguiente fase del proyecto. Con cada
iteracin alrededor de la espiral, se crean sucesivas versiones del software, cada
vez ms completas y, al final, el sistema de software ya queda totalmente
funcional. La diferencia principal entre el modelo espiral y los modelos anteriores
(ej.: cascada, evolutivo, incremental, etc.) es la evaluacin del riesgo. El riesgo es
todo lo que pueda salir mal en un proyecto de desarrollo de software. Por ejemplo,
si queremos utilizar un lenguaje de programacin para desarrollar un sistema
operativo, un riesgo posible es que los compiladores utilizables no produzcan un
cdigo objeto eficiente. Los riesgos originan problemas en el proyecto, como el
exceso de los costos. Es as que, la disminucin de los riesgos es una actividad
muy importante. Un modelo espiral comienza con la determinacin de los objetivos
tanto funcionales como de rendimiento. Despus se enumeran algunas formas
posibles de alcanzar estos objetivos identificando las fuentes de riesgos posibles.
Luego continuamos con el siguiente paso que es resolver estos riesgos y llevar a
cabo las actividades de desarrollo, para finalizar con la planificacin del siguiente
ciclo de la espiral.
Es considerado como un modelo evolutivo ya que combina el modelo clsico con
el diseo de prototipos. Contiene una nueva etapa que es el anlisis de riesgos,
no incluida anteriormente. Este modelo es el indicado para desarrollar software
con diferentes versiones actualizadas como se hace con los programas modernos
de PCs. La ingeniera puede desarrollarse a travs del ciclo de vida clsico o el

de construccin de prototipos. Este es el enfoque ms realista actualmente. El

modelo en espiral esta compartida en varias actividades estructurales, tambin
llamadas regiones de tareas. Existen seis regiones de tareas que son:
Comunicacin con el cliente: esta es una tarea requerida para establecer
comunicacin entre el desarrollador y el cliente.
Planificacin: esta tarea es necesaria aplicarla para pode definir los recursos, el
tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los
requerimientos.
Anlisis de riesgos: esta es una de las tareas principales por lo que se aplica el
modelo en espiral, es requerida para evaluar los riesgos tcnicos y otras
informaciones relacionadas con el proyecto. Ingeniera: esta es una tarea
necesaria ya que se requiere construir una o ms representaciones de la
aplicacin.
Construccin y adaptacin: esta tarea es requerida en el modelo espiral porque
se necesita construir, probar, instalar y proporcionar soporte al usuario.
Evaluacin el cliente: esta tambin es una tarea principal, necesaria para adquirir
la reaccin del cliente segn la evaluacin de las representaciones del software
creadas durante la etapa de ingeniera y la de implementacin creada durante la
etapa de instalacin.

MODELO INCREMENTAL
Caractersticas.
Combina elementos del modelo en cascada con la filosofa interactiva de
construccin de prototipos. Se basa en la filosofa de construir incrementando las
funcionalidades del programa.

Ventajas y desventajas.
Ventajas
Mediante este modelo se genera software operativo de forma rpida y en
etapas tempranas del ciclo de vida del software.
Es un modelo ms flexible, por lo que se reduce el coste en el cambio de
alcance y requisitos.

 Es ms fcil probar y depurar en una iteracin ms pequea.

Es ms fcil gestionar riesgos.
Cada iteracin es un hito gestionado fcilmente
Inconvenientes
Para el uso de este modelo se requiere una experiencia importante para definir los
incrementos y distribuir en ellos las tareas de forma proporcionada.
Cada fase de una iteracin es rgida y no se superponen con otras.
Pueden surgir problemas referidos a la arquitectura del sistema porque no
todos los requisitos se han reunido, ya que se supone que todos ellos se
han definido al inicio
Modelo de desarrollo por etapas
Es un modelo en el que el software se muestra al cliente en etapas refinadas sucesivamente.
Con esta metodologa se desarrollan las capacidades ms importantes reduciendo el tiempo
necesario para la construccin de un producto; el modelo de entrega por etapas es til para el
desarrollo de la herramienta debido a que su uso se recomienda para problemas que pueden
ser tratados descomponindolos en problemas ms pequeos y se caracteriza principalmente
en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se
van desarrollando simultneamente con las diferentes versiones del cdigo.
En este modelo pueden distinguirse las siguientes fases:

Especificacin conceptual.

Anlisis de requisitos.

Diseo inicial.

Diseo detallado (codificacin, depuracin, prueba y liberacin).

Cuando es por etapas, en el diseo global estas fases pueden repetirse segn la cantidad de
etapas que sean requeridas.
Entre sus ventajas tenemos:

Deteccin de problemas antes y no hasta la nica entrega final del proyecto.

Eliminacin del tiempo en informes debido a que cada versin es un avance.

Estimacin de tiempo por versin, evitando errores en la estimacin del proyecto

general.

Cumplimiento a la fecha por los desarrolladores.

Proceso unificado del desarrollo de software

El proceso unificado es un proceso de software genrico que puede ser utilizado para una
gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes
tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos.
Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una
organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta
calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y
presupuesto predecible.
El proceso unificado tiene dos dimensiones:

Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del
proceso a lo largo de su desenvolvimiento

Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una
manera lgica de acuerdo a su naturaleza.

La primera dimensin representa el aspecto dinmico del proceso conforme se va

desarrollando, se expresa en trminos de fases, iteraciones e hitos (milestones).
La segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en
trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y
roles.
El refinamiento ms conocido y documentado del proceso unificado es el RUP (proceso
unificado racional).
El proceso unificado no es simplemente un proceso, sino un marco de trabajo extensible que
puede ser adaptado a organizaciones o proyectos especficos. De la misma manera, el

proceso unificado de rational, tambin es un marco de trabajo extensible, por lo que muchas
veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del
proceso unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para
referirse a un mismo concepto.

Modelo de desarrollo concurrente

El modelo de desarrollo concurrente es un modelo de tipo de red donde todas las personas
actan simultneamente o al mismo tiempo. Este tipo de modelo se puede representar a
manera de esquema como una serie de actividades tcnicas importantes, tareas y estados
asociados a ellas.
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 ingeniera del
software. Por ejemplo, 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 disparara la actividad de anlisis del estado hecho al estado cambios en espera.
Este modelo de desarrollo 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 divisin de sistemas y una divisin de
componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades:
diseo y realizacin.
La concurrencia se logra de dos maneras:

Las actividades del sistema y de componente ocurren simultneamente y pueden

modelarse con el enfoque orientado a objetos descrito anteriormente;

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 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 ingeniera de software a una secuencia de sucesos, define una red de
actividades, todas las actividades de la red existen simultneamente con otras. Los sucesos
generados dentro de una actividad dada o algn otro lado de la red de actividad inician las
transiciones entre los estados de una actividad.

Fuentes:
http://isw-udistrital.blogspot.mx/2012/09/ingenieria-de-software-i.html