INSTITUTO SUPERIOR TECNOLGICO PBLICO

JOS PARDO

COMPUTACIN E INFORMTICA
UNIDAD DIDCTICA:

METODOLOGIA DE DESARROLLO DE SOFTWARE

TEMA:

PARADIGMAS DE DESARROLLO DE SOFTWARE

DOCENTE:

SEMESTRE: IV TURNO: NOCTURNO

INTEGRANTES:

MEZA CARBAJAL, BLADIMIR

VERA TAIPE, ROLANDO

2017
LIMA - PER
INDICE GENERAL:

I.INTRODUCCION:

II.CUERPO:

1. MODELOS DEL CICLO DE VIDA

1.1 MODELO DE DESARROLLO EN CASCADA (WATERFLOW):

1.2 MODELO DE DESARROLLO EN ESPIRAL:

1.3 MODELO DE DESARROLLO EN PROTOTIPOS:

1.4 MODELO DE DESARROLLO EVOLUTIVO:

1.5 MODELO DE DESARROLLO INCREMENTAL:

III. CONCLUSION:

IV. REFERENCIAS Y/O BIBLIOGRAFA:

I.INTRODUCCION:

Tenemos en cuenta que para los paradigmas de desarrollo de software hay comenzar
hablando de una metodologa de anlisis de software, conociendo de forma general cuales son
las etapas generales, de desarrollo de software. La cual est en la bsqueda constante de las
mejores herramientas, tcnicas, metodologas que hagan frente a estas dificultades, desde las
primeras fases de un proyecto, evitando as demoras y desaprovechamiento de los recursos
as como los grandes proyectos de software necesitan herramientas estables y completas, las
cuales brinden medios a lo largo de todas las etapas del desarrollo del software, tambin un
proceso de desarrollo de software tiene como propsito la produccin eficaz y eficiente de un
producto que rena los requisitos del cliente.

Este paradigma de desarrollo tiene como base la creatividad y juicio de las personas
involucradas en el desarrollo del software. Aunque es equiparable en muchos aspectos a
cualquier otra metodologa de desarrollo de software que hay una serie de desafos
adicionales, relativos esencialmente a las necesidades del usuario para tener idea de un
paradigma.
 PARADIGMAS DE DESARROLLO DE SOFTWARE

II.CUERPO:

Definicin: Para la Ingeniera de Software el paradigma es una agrupacin de mtodos,

herramientas y procedimientos con el fin de describir un modelo.
Concepto: Cuando nos centramos en gestionar todas las reas de proceso de una
organizacin, mediante la implantacin de una metodologa. La mayor informacin de los
procesos de modo que pueda controlarse y mejorarse, y produzcan as un aumento de la
calidad de los productos y servicios relacionados con ellos.

1. MODELOS DEL CICLO DE VIDA

Todo proyecto de ingeniera tiene unos fines ligados a la obtencin de un producto, proceso o
servicio que es necesario generar a travs de diversas actividades. Algunas de estas actividades
pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio,
necesario para continuar hacia el producto final y facilitar la gestin del proyecto. Al conjunto de
las fases empleadas se le denomina ciclo de vida. Para facilitar una metodologa comn entre
el cliente y la compaa de software, los modelos de ciclo de vida se han actualizado para
reflejar las etapas de desarrollo involucradas y la documentacin requerida.

1.1 MODELO DE DESARROLLO EN CASCADA (WATERFLOW):

Se denomina modelo en cascada porque su caracterstica principal es que no se comienza con
un paso hasta que no se ha terminado el anterior. Comenz a disearse en 1966 y se termin
alrededor de 1970. El principal problema de esta aproximacin es el que no podemos esperar el
que las especificaciones inciales sean correctas y completas y que el usuario puede cambiar de
opinin sobre una u otra caracterstica. Adems los resultados no se pueden ver hasta muy
avanzado el proyecto por lo que cualquier cambio debido a un error puede suponer un gran
retraso adems de un alto coste de desarrollo. Como es evidente esto es solo un modelo terico,
si el usuario cambia de opinin en algn aspecto tendremos que volver hacia atrs en el ciclo de
vida
.

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un sistema
mayor el trabajo comienza estableciendo los requisitos de todos los 48 elementos del sistema y
luego asignando algn subconjunto de estos requisitos al software.
Anlisis de los requisitos del software: el proceso de recopilacin de los requisitos se centra e
intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el
mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces
requeridas.
Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa: la estructura
de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la
interfaz. El proceso de diseo traduce los requisitos en una representacin del software con la
calidad requerida antes de que comience la codificacin.
Codificacin: el diseo debe traducirse en una forma legible para la mquina. El paso de
codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin
puede realizarse mecnicamente.
Prueba: una vez que se ha generado el cdigo comienza la prueba del programa. La prueba se
centra en la lgica interna del software, y en las funciones externas, realizando pruebas que
aseguren que la entrada definida produce los resultados que realmente se requieren.
Mantenimiento: el software sufrir cambios despus de que se entrega al cliente. Los cambios
ocurrirn debido a se han encontrado errores, a que el software deba adaptarse a cambios del
entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera
ampliaciones funcionales o del rendimiento.
Desventajas:
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay
iteraciones y se crean problemas en la aplicacin del paradigma.
Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos.
El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles incertidumbres que
pueden existir al comienzo de muchos productos.
1.2 MODELO DE DESARROLLO EN ESPIRAL:
Toma las ventajas del modelo de desarrollo en cascada y el de prototipos aadindole el
concepto de anlisis de riesgo. Se definen cuatro actividades: Planificacin: en la que se
recolectan los requisitos inciales o nuevos requisitos a aadir en esta iteracin. Anlisis de
riesgo; basndonos en los requisitos decidimos si somos capaces o no de desarrollar el software
y se toma la decisin de continuar o no continuar. Ingeniera, en el que se desarrolla un prototipo
basado en los requisitos obtenidos en la fase de planificacin. Evaluacin del cliente: el cliente
comenta el prototipo. Si est conforme con l se acaba el proceso, si no se aaden los nuevos
requisitos en la siguiente iteracin.

El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral,
donde los cuadrantes son, habitualmente, fases de especificacin, diseo, realizacin y
evaluacin (o conceptos y trminos anlogos). En cada fase el producto gana madurez
(aproximacin al final deseado) hasta que en una iteracin se logre el objetivo deseado y este
sea aprobado se termina las iteraciones. Durante las ltimas iteraciones, se producen versiones
cada vez ms completas de ingeniera del sistema. El modelo en espiral se divide en un nmero
de actividades estructurales tambin llamadas guiones de tareas. Estas inclusive pueden variar
de 3 a 6 tareas.
Cuando empieza este proceso evolutivo, el equipo de ingeniera del software gira alrededor de la
espiral en la direccin de las agujas del reloj, comenzando por el centro. El primer circuito de la
espiral produce el desarrollo de una especificacin de productos; los pasos siguientes en la
espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones ms
sofisticadas del software. Cada paso de la regin de planificacin produce ajustes en el plan del
proyecto. El costo y la planificacin se ajustan segn la reaccin ante la evaluacin del cliente.
Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones requeridas para
completar el software. En esencia, la espiral, cuando se caracteriza de esta forma, permanece
operativo hasta que el software se retira. Hay veces en que el proceso est inactivo, pero
siempre que se inicie un cambio, el proceso arranca en el punto de entrada adecuado (p. Ej.:
mejora el producto).
 El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran
escala. 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.

El modelo en espiral utiliza la construccin de prototipos como mecanismos de reduccin de

riesgos, pero lo que es ms importante, permite a quien lo desarrolla aplicar el enfoque de
construccin de prototipos en cualquier etapa de evolucin del producto.

Mantiene el enfoque sistemtico de los pasos sugeridos por el ciclo de vida clsico, pero lo
incorpora al marco de trabajo interactivo que refleja de forma ms realista el mundo real. El
modelo en espiral demanda una consideracin directa de los riesgos tcnicos en todas las
etapas del proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se
conviertan en problemticos.

El paradigma espiral, al igual que los dems modelos, se puede combinar con otros paradigmas.

1.3 MODELO DE DESARROLLO EN PROTOTIPOS:

El modelo de prototipos busca definir los objetivos globales del sistema para luego refinar en
conjunto con el cliente los requisitos especficos. En la primera etapa se crea un prototipo rpido
y luego se itera sobre l en base a la retroalimentacin obtenida desde el cliente. Esta modelo
es extremadamente til cuando el cliente no tiene claridad con respecto a lo que necesita, y
ayuda al equipo de desarrolladores a reducir los riesgos de cambios en las etapas ms
avanzadas del proceso de desarrollo. Sin embargo, dependiendo del cliente, este puede no
desear involucrarse en el proceso de desarrollo, lo que tambin implica un riesgo.

El paradigma de construccin de prototipos comienza con la recoleccin de requisitos.

El desarrollador y el cliente encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos, y las reas del esquema en donde es obligatoria ms
definicin. Entonces aparece un diseo rpido.

El diseo rpido se centra en una representacin de esos aspectos del software que sern
visibles para el usuario/cliente. El diseo rpido lleva a la construccin de un prototipo.

El prototipo lo evala el cliente/usuario y lo utiliza para refinar los requisitos del software a
desarrollar. La interaccin ocurre cuando el prototipo satisface las necesidades del cliente, a la
vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.
 Lo ideal sera que el prototipo sirviera como un mecanismo para identificar los requisitos del
software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los
fragmentos del programa ya existentes o aplica herramientas que permiten generar rpidamente
programas de trabajo.

El paradigma de la elaboracin por prototipos resulta una alternativa para el desarrollo rpido de
aplicaciones de software; pues el analista acorta en tiempo entre la determinacin de los
requerimientos de informacin y la entrega de un sistema funcional, adems que el usuario
podr modificar y depurar sus requerimientos conforme avance el desarrollo del proyecto.

Este enfoque tiene ventajas y desventajas entre otras estn:

El cliente ve lo que parece una versin del software y no tiene en cuenta que para realizarse
un prototipo rpido, se rebaja la calidad del producto software de esa manera el cliente puede
no entender que se debe realizar de nuevo el sistema y querr tener como versin final de su
sistema el prototipo ya desarrollado.

De forma demasiado frecuente la gestin de desarrollo del software es muy lenta.

Documentar el desarrollo suele ser tedioso y puede perderse control por parte de los jefes de
proyectos debido a la cantidad de versiones desarrolladas.

Por el otro lado el paradigma por prototipos tambin cuenta con una aceptacin amplia debido
a que el cliente le gusta ver versiones inmediatas de su sistema. Tambin suele ser muy
efectivo para el manejo y la identificacin de errores en etapas tempranas del proceso de
desarrollo.

1.4 MODELO DE DESARROLLO EVOLUTIVO:

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces

denominado como prototipo evolutivo) construye una serie de grandes versiones sucesivas de
un producto. Sin embargo, mientras que la aproximacin incremental presupone que el conjunto
completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los
requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que
son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores
construyen una implementacin parcial del sistema que recibe slo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los
desarrolladores.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo
evolutivo no demanda una forma especfica de observar el desarrollo de algn incremento. As,
el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente,
el desarrollo incremental y evolutivo puede ser combinado tambin.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos
(incremental), y comprender al principio que muchos nuevos requerimientos es probable que
aparezcan cuando el sistema sea desplegado o desarrollado. El desarrollo de software en forma
evolutiva requiere un especial cuidado en la manipulacin de documentos, programas, datos de
test, etc. desarrollados para distintas versiones del software.

Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las
actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos
hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras.
El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para
mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por
definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para
experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el
sistema adecuado. Las actividades concurrentes: especificacin, desarrollo y validacin, se
realizan durante el desarrollo de las versiones hasta llegar al producto final.
1.5 MODELO DE DESARROLLO INCREMENTAL:

El enfoque incremental de desarrollo se ve 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 (ver Figura 10). Es una combinacin del Modelo de
Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las
decisiones hasta tener experiencia en el sistema.

Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo,

dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un
buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Modelo de desarrollo iterativo incremental.

Entre las ventajas del modelo incremental se encuentran:

Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar
a usarlo desde el primer incremento.
Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas
del sistema.
Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada
incremento.
Las partes ms importantes del sistema son entregadas primero, por lo cual se realizan
ms pruebas en estos mdulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son:

Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas).
Cada incremento debe aumentar la funcionalidad.
Es difcil establecer las correspondencias de los requisitos contra los incrementos.
Es difcil detectar las unidades o servicios genricos para todo el sistema.
 Visin del
Funciona con
Produce progreso
requisitos y Permite
Modelo de software Gestin de por el
arquitectura correcciones
proceso altamente riesgos Cliente y el
no sobre la marcha
fiable Jefe del
predefinidos
proyecto

Cascada Bajo Alto Bajo Bajo Bajo

Evolutivo Medio o
Medio o Alto Medio o Alto Medio Medio o Alto
exploratorio Alto

Prototipo Alto Medio Medio Alto Alto

Incremental Bajo Alto Medio Bajo Bajo

Espiral Alto Alto Alto Medio Medio

III.CONCLUSION:

El desarrollo de software es uno de los pilares fundamentales de la Informtica y al cual se

dedican muchas horas de esfuerzos en universidades, centros de investigacin y empresas de
todos los tamaos.
Conforme la tecnologa va avanzando, van apareciendo nuevas soluciones, nuevas formas de
programacin, nuevos lenguajes, y un sin fin de herramientas que intentan realizar el trabajo del
desarrollador un poco ms fcil. Tambin surgen nuevos modelos de proceso de desarrollo y
nuevas metodologas que tratan de adaptar la manera de trabajar a las necesidades concretas
de una organizacin y de sus proyectos. Es importante conocer bien estos modelos, para tener
un esquema mental que nos permita gestionar proyectos y organizar equipos de manera
racional, cuando abordemos el desarrollo de software, especialmente en el caso de aplicaciones
grandes y complejas.
El tener un enfoque disciplinado para la asignacin de tareas y responsabilidades dentro de una
organizacin; nos llevan al cumplimiento de uno de los objetivos que se sigue, el cual es la
produccin de software de alta calidad que satisfaga las necesidades de sus usuarios finales
dentro de un presupuesto y tiempo predecibles

V. REFERENCIAS Y/O BIBLIOGRAFIA:

https://es.wikiversity.org/wiki/Procesos_de_desarrollo_software

www.e-market.cl/dir/umayor/ingsw/06-01_vesp/espiral.ppt

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

Amador Duran Toro, Beatriz Bernrdez Jimnez,

Metodologa para el anlisis de requisitos de sistemas de
software versin 2.2, Universidad de Sevilla, departamento
de Lenguajes y Sistemas informticos