Martes15 - Ing. SW II

UNIVERSIDAD SAN PEDRO
INGENIERIA DE SOFTWARE II

FACULTAD DE INGENIERIA
ESCUELA DE INGENIERIA
INFORMATICA

INTEGRANTES: CASTREJON TERAN Eduardo
HUAMAN VARGAS, Deyvis
VERA CABELLOS, Milagros

CURSO: INGENIERIA DE SOFTWARE II
DOCENTE: ING. FRANKLIN PEREZ URTEAGA
TEMA: METODODOLOGIA DE DESARROLLO DE
SOFTWARE

2014



INTRODUCCIN

Una metodologa es un conjunto de procedimientos, tcnicas, herramientas y
un soporte documental que ayuda a los desarrolladores a realizar un nuevo
software. Puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo
de vida indica qu es lo que hay que obtener a lo largo del desarrollo del
proyecto pero no cmo hacerlo.
La metodologa indica cmo hay que obtener los distintos productos parciales y
finales.
Finalmente depender de la metodologa utilizada los productos del proyecto,
por esta razn es necesario, conoces a fondo cada una de ellas y poder
diferenciar entre una y otra, para de este modo saber elegir la correcta en el
momento de desarrollar un nuevo software, de otra manera el producto no ser
el mejor e incluso puede ser intil.
Un sistema informtico est compuesto por hardware y software. En cuanto al
hardware, su produccin se realiza sistemticamente y la base de conocimiento
para el desarrollo de dicha actividad est claramente definida. La fiabilidad del
hardware es, en principio, equiparable a la de cualquier otra mquina
construida por el hombre. Sin embargo, respecto del software, su construccin
y resultados han sido histricamente cuestionados debido a los problemas
asociados, entre ellos podemos destacar los siguientes:
Los sistemas no responden a las expectativas de los usuarios.
Los programas fallan con cierta frecuencia.
Los costes del software son difciles de prever y normalmente superan
las estimaciones.
La modificacin del software es una tarea difcil y costosa.
El software se suele presentar fuera del plazo establecido y con menos
prestaciones de las consideradas inicialmente.
Normalmente, es difcil cambiar de entorno hardware usando el mismo
software.
El aprovechamiento ptimo de los recursos (personas, tiempo, dinero,
herramientas, etc.) no suele cumplirse.



CAPITULO I

MARCO TEORICO



METODOLOGIA DE DESARROLLO DE SOFTWARE

Una metodologa de desarrollo de software es un proceso organizado para la
produccin de un software. Especifica el ciclo de vida a utilizar indicando
adems que personas deben desempear cada rol en el desarrollo de la
actividad.
Es una serie de pasos sistemticos para que los diferentes grupos que
participan en un desarrollo poseen una buena comunicacin.
La metodologa de desarrollo de software tiene como propsito la produccin
eficaz y eficiente de un producto software que rena los requisitos del cliente.
Este proceso es intensamente intelectual, afectado por la creatividad y juicio de
las personas involucradas. Aunque un proyecto de desarrollo de software es
equiparable en muchos aspectos a cualquier otro proyecto de ingeniera, en el
desarrollo de software hay una serie de desafos adicionales, relativos
esencialmente a la naturaleza del producto obtenido. A continuacin se
explican algunas particularidades asociadas al desarrollo de software y que
influyen en su proceso de construccin.
Un producto software en s es complejo, es prcticamente inviable conseguir un
100% de confiabilidad de un programa por pequeo que sea. Existe una
inmensa combinacin de factores que impiden una verificacin exhaustiva de
las todas posibles situaciones de ejecucin que se puedan presentar (entradas,
valores de variables, datos almacenados, software del sistema, otras
aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).
Un producto software es intangible y por lo general muy abstracto, esto dificulta
la definicin del producto y sus requisitos, sobre todo cuando no se tiene
precedentes en productos software similar. Esto hace que los requisitos sean
difciles de consolidar tempranamente. As, los cambios en los requisitos son
inevitables, no slo despus de entregado en producto sino tambin durante el
proceso de desarrollo.
Adems, de las dos anteriores, siempre puede sealarse la inmadurez de la
ingeniera del software como disciplina, justificada por su corta vida comparada
con otras disciplinas de la ingeniera. Sin embargo, esto no es ms que un intil
consuelo.
MODELOS DE PROCESO SOFTWARE
1. METODOLOGA EN CASCADA.
Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las
modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la
necesidad de cambiar algo en el diseo, lo cual significa que se harn los



cambios necesarios en la codificacin y se tendrn que realizar de nuevo las
pruebas, es decir, si se tiene que volver a una de las etapas anteriores al
mantenimiento hay que recorrer de nuevo el resto de las etapas. Despus de
cada etapa se realiza una revisin para comprobar si se puede pasar la
siguiente.
El modelo en cascada tambin conocido como ciclo de vida clsico es el
modelo ms conocido y ofrece una velocidad de desarrollo aceptable en
algunas circunstancias. Este es el predecesor de todos los modelos de ciclo de
vida es el modelo en cascada. La visin del modelo cascada del desarrollo de
software es muy simple Este modelo en cascada se utiliza correctamente para
los ciclos de productos en los que se conoce muy bien el producto, y tambin
cuando se esta trabajando con metodologas tcnicas conocidas. En estos
casos el modelo en cascada ayuda a localizar errores en las primeras etapas
de la realizacin del proyecto a un bajo coste. El modelo cascada pura ayuda a
minimizar los gastos de la planificacin del proyecto porque permite realizarla
sin problemas. No da resultados tangibles en forma de software hasta el final
del ciclo del modelo, pero los que ya trabajan con el modelo cascada la
documentacin que este genera entrega indicaciones significativas de progreso
a lo largo del ciclo de vida del proyecto. Como es un modelo lineal secuencial
este no puede ser corregido con gran facilidad pues no puede dar retrocesos
as que esa es su gran desventaja adems que no se puede dar una vista de
los avances del proceso. Su ventaja es que es fcil de explicarlo. Si bien ha
sido ampliamente criticado desde el mbito acadmico y la industria, sigue
siendo el paradigma ms seguido al da de hoy Definido por Winston Royce a
fines de los 70 desde entonces muchos usuarios utilizan este modelo como
base para los modelos actuales de desarrollo de software. Y se trata
principalmente de que se debe completar un paso correctamente sin ningn
error para pasar al siguiente. Este modelo desde 10 a 15 aos atrs, ha sido
sujeto de numerosas criticas debido a que es restrictivo y rgido, lo cual dificulta
el desarrollo de proyectos de software moderno. En su lugar, muchos modelos
nuevos de ciclo de vida han sido propuestos, incluyendo modelos que
pretenden desarrollar software ms rpidamente, o ms incrementalmente o de
una forma ms evolutiva, o precediendo el desarrollo a escala total con algn
conjunto de prototipos rpidos. El modelo cascada mantiene que uno debe
moverse a una fase solamente en que se termina y se perfecciona su fase
precedente. Sin embargo, hoy en da hay varios modelos modificados de la
cascada que puede incluir leves variaciones o importantes sobre este proceso.
El modelo de cascada significa que primero haces una especificacin de
requisitos del sistema, luego haces un anlisis de los requisitos para especificar
la metodologa de desarrollo que usars, luego realizas el diseo de lo
analizado anteriormente, luego la compilacin, la prueba y el mantenimiento.
Esa metodologa tiene el problema de que solo le enseas el producto al
cliente cuando ya has terminado todo, y es difcil de modificarlas cosas.
2. METODOLOGA EN ESPIRAL



La metodologa de desarrollo en espiral es una evolucin de mtodo clsico en
cascada (Waterfall, top-down) y se considera un mtodo de desarrollo
incremental. Este tipo de metodologa equivale al de cascada, pero en l se
permite el solapamiento de varias etapas con el objetivo de flexibilizar y
compensar el tiempo de desarrollo total y alcanzar resultados funcionales en
etapas tempranas. Est considerada como un mtodo de desarrollo rpido y
eficiente.
Es adecuada para proyectos en los que se tienen claros los objetivos finales
pero no todos los detalles de implementacin estn elucidados.
La metodologa de desarrollo en espiral permite construir aplicaciones de
tamao medio manteniendo los recursos constantes.
3. METODOLOGA XP (PROGRAMACIN EXTREMA)

De todas las metodologas giles, sta es la que ha recibido ms atencin.
Esto se debe en parte a la notable habilidad de los lderes XP, en particular
Kent Beck, para llamar la atencin. Tambin se debe a la habilidad de Kent
Beck de atraer a las personas a este acercamiento, y tomar un papel principal
en l. De algunas maneras, sin embargo, la popularidad de XP se ha vuelto un
problema, pues ha acaparado la atencin fuera de las otras metodologas y sus
valiosas ideas.
La XP empieza con cuatro valores: Comunicacin, Retroalimentacin,
Simplicidad y Coraje. Construye sobre ellos una docena de prcticas que los
proyectos XP deben seguir. Muchas de estas prcticas son tcnicas antiguas,
tratadas y probadas, aunque a menudo olvidadas por muchos, incluyendo la
mayora de los procesos planeados. Adems de resucitar estas tcnicas, la XP
las teje en un todo sinrgico dnde cada una refuerza a las dems.
Una de las ms llamativas, as como inicialmente atractiva para m, es su fuerte
nfasis en las pruebas. Mientras todos los procesos mencionan la
comprobacin, la mayora lo hace con muy poco nfasis. Sin embargo la XP
pone la comprobacin como el fundamento del desarrollo, con cada
programador escribiendo pruebas cuando escriben su cdigo de produccin.
Las pruebas se integran en el proceso de integracin continua y construccin lo
que rinde una plataforma altamente estable para el desarrollo futuro.
En esta plataforma XP construye un proceso de diseo evolutivo que se basa
en refactorar un sistema simple en cada iteracin. Todo el diseo se centra en
la iteracin actual y no se hace nada anticipadamente para necesidades
futuras. El resultado es un proceso de diseo disciplinado, lo que es ms,
combina la disciplina con la adaptabilidad de una manera que indiscutiblemente
la hace la ms desarrollada entre todas las metodologas adaptables.



Capitulo II

MARCO CONCEPTUAL



METODOLOGIA DE DESARROLLO DE SOFTWARE

a. DEFINICION.
Un proceso de software detallado y completo suele denominarse
Metodologa. Las metodologas se basan en una combinacin de los modelos
de proceso genricos (cascada, evolutivo, incremental, etc.). Adicionalmente
una metodologa debera definir con precisin los artefactos, roles y actividades
involucrados, junto con prcticas y tcnicas recomendadas, guas de
adaptacin de la metodologa al proyecto, guas para uso de herramientas de
apoyo, etc. Habitualmente se utiliza el trmino mtodo para referirse a
tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas)
actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos
de anlisis y/o diseo.
La comparacin y/o clasificacin de metodologas no es una tarea sencilla
debido a la diversidad de propuestas y diferencias en el grado de detalle,
informacin disponible y alcance de cada una de ellas. A grandes rasgos, si
tomamos como criterio las notaciones utilizadas para especificar artefactos
producidos en actividades de anlisis y diseo, podemos clasificar las
metodologas en dos grupos: Metodologas Estructuradas y Metodologas
Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo,
aquellas metodologas con mayor nfasis en la planificacin y control del
proyecto, en especificacin precisa de requisitos y modelado, reciben el
apelativo de Metodologas Tradicionales (o peyorativamente denominada
Metodologas Pesadas, o Peso Pesado). Otras metodologas, denominadas
Metodologas giles, estn ms orientadas a la generacin de cdigo con
ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos,
hacen especial hincapi en aspectos humanos asociados al trabajo en equipo e
involucran activamente al cliente en el proceso.
b. LNEA DEL TIEMPO METODOLOGAS DE DESARROLLO DE
SOFTWARE.
El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la
dcada 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 informacin en una muy
deliberada, estructurada y metdica, reiterando cada una de las etapas del
ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas
pesadas para el procesamiento de datos y rutinas de clculo.
1970 Programacin estructurada desde 1969
Programacin estructurada Jackson desde 1975
1980 Structured Systems Analysis and Design Methodology (SSADM) desde
1980 Structured Analysis and Design Technique (SADT) desde 1980



Ingeniera de la informacin (IE/IEM) desde 1981

ITSA METODOLOGAS DE DESARROLLO DE SOFTWARE
1990 Rapid application development (RAD) desde 1991.
Programacin orientada a objetos (OOP) a lo largo de la dcada de los 90's
Virtual finite state machine (VFSM) desde 1990s
Dynamic Systems Development Method desarrollado en UK desde 1995.
Scrum (desarrollo), en la ltima parte de los 90's
Nuevo milenio Programacin extrema desde 1999
Enterprise Unified Process (EUP) extensiones RUP desde 2002
Rational Unified Process (RUP) desde 2003.
Constructionist design methodology (CDM) desde 2004 por Kristinn R.
Thrisson
Agile Unified Process (AUP) desde 2005 por Scott Ambler
c. CUL ES EL MODELO DE PROCESO MS ADECUADO?
Cada proyecto de software requiere de una forma de particular de abordar el
problema. Las propuestas comerciales y acadmicas actuales promueven
procesos iterativos, donde en cada iteracin puede utilizarse uno u otro modelo
de proceso, considerando un conjunto de criterios (Por ejemplo: grado de
definicin de requisitos, tamao del proyecto, riesgos identificados, entre otros).
En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos
criterios bsicos para la seleccin de un modelo de proceso, la medida utilizada
indica el nivel de efectividad del modelo de proceso de acuerdo al criterio (Por
ejemplo: El modelo Cascada responde con un nivel de efectividad Bajo cuando
los Requisitos y arquitectura no estn predefinidos):
2. MODELOS DE PROCESO SOFTWARE

2.1 METODOLOGA EN CASCADA.

2.1.1 DEFINICION.
Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las
modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la
necesidad de cambiar algo en el diseo, lo cual significa que se harn los
cambios necesarios en la codificacin y se tendrn que realizar de nuevo las



pruebas, es decir, si se tiene que volver a una de las etapas anteriores al
mantenimiento hay que recorrer de nuevo el resto de las etapas. Despus de
cada etapa se realiza una revisin para comprobar si se puede pasar la
siguiente.
El modelo en cascada tambin conocido como ciclo de vida clsico es el
modelo ms conocido y ofrece una velocidad de desarrollo aceptable en
algunas circunstancias. Este es el predecesor de todos los modelos de ciclo de
vida es el modelo en cascada. La visin del modelo cascada del desarrollo de
software es muy simple Este modelo en cascada se utiliza correctamente para
los ciclos de productos en los que se conoce muy bien el producto, y tambin
cuando se esta trabajando con metodologas tcnicas conocidas. En estos
casos el modelo en cascada ayuda a localizar errores en las primeras etapas
de la realizacin del proyecto a un bajo coste. El modelo cascada pura ayuda a
minimizar los gastos de la planificacin del proyecto porque permite realizarla
sin problemas. No da resultados tangibles en forma de software hasta el final
del ciclo del modelo, pero los que ya trabajan con el modelo cascada la
documentacin que este genera entrega indicaciones significativas de progreso
a lo largo del ciclo de vida del proyecto. Como es un modelo lineal secuencial
este no puede ser corregido con gran facilidad pues no puede dar retrocesos
as que esa es su gran desventaja adems que no se puede dar una vista de
los avances del proceso. Su ventaja es que es fcil de explicarlo. Si bien ha
sido ampliamente criticado desde el mbito acadmico y la industria, sigue
siendo el paradigma ms seguido al da de hoy Definido por Winston Royce a
fines de los 70 desde entonces muchos usuarios utilizan este modelo como
base para los modelos actuales de desarrollo de software. Y se trata
principalmente de que se debe completar un paso correctamente sin ningn
error para pasar al siguiente. Este modelo desde 10 a 15 aos atrs, ha sido
sujeto de numerosas criticas debido a que es restrictivo y rgido, lo cual dificulta
el desarrollo de proyectos de software moderno. En su lugar, muchos modelos
nuevos de ciclo de vida han sido propuestos, incluyendo modelos que
pretenden desarrollar software ms rpidamente, o ms incrementalmente o de
una forma ms evolutiva, o precediendo el desarrollo a escala total con algn
conjunto de prototipos rpidos. El modelo cascada mantiene que uno debe
moverse a una fase solamente en que se termina y se perfecciona su fase
precedente. Sin embargo, hoy en da hay varios modelos modificados de la
cascada que puede incluir leves variaciones o importantes sobre este proceso.
El modelo de cascada significa que primero haces una especificacin de
requisitos del sistema, luego haces un anlisis de los requisitos para especificar
la metodologa de desarrollo que usars, luego realizas el diseo de lo
analizado anteriormente, luego la compilacin, la prueba y el mantenimiento.
cliente cuando ya has terminado todo, y es difcil de modificarlas cosas.
2.1.1.2 EL MODELO ORIGINAL DE LA CASCADA DE WINSTON ROYCEE
especificacin de requisitos



Diseo
Construccin (AKA puesta en prctica o codificacin)
Integracin
Prueba y el eliminar errores (Verificacin de AKA)
Instalacin
Mantenimiento Los que utilizan tales mtodos no distinguen siempre
formalmente entre el modelo puro de la cascada y los varios modelos
modificados de la cascada, as que puede ser difcil discernir exactamente que
los modelos se estn utilizando y en qu medida
2.1.1.3 EL MODELO CASCADA, TIENE ALGUNOS PRINCIPIOS BSICOS
LOS CUALES SELOS NOMBRA A CONTINUACIN:

Planear un proyecto antes de comenzar con l.
Definir el comportamiento externo deseado del sistema antes de disear su
arquitectura interna.
Documentar los resultados de cada actividad.
Disear un sistema antes de codificarlo.
Testear un sistema despus de construirlo.

2.1.1.4 ESTRUCTURA MODELO EN CASCADA (BENNINGTON 1956)
El ms conocido, est basado en el ciclo convencional de una ingeniera, el
paradigma del ciclo de vida abarca las siguientes actividades:
El mantenimiento se realiza en el cdigo fuente
Las revisiones de proyectos de gran complejidad son muy difciles
Impone una estructura de gestin de proyectos
Un error importante no detectado hasta que el programa est funcionando
puede ser desastroso
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por
el proceso de prueba y hasta que el software no est completo no se opera.
Esto es la base para que funcione bien.
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. En Ingeniera de software el desarrollo
en cascada, tambin llamado modelo en cascada, es el enfoque metodolgico



que ordena rigurosamente las etapas del ciclo de vida del software, de tal
forma que el inicio de cada etapa debe esperar a la finalizacin de la
inmediatamente anterior. 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 costes 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. El modelo de cascada significa que primero haces una especificacin
de requisitos del sistema, luego haces un anlisis de los requisitos para
especificar la metodologa de desarrollo que usars, luego realizas el diseo de
lo analizado anteriormente, luego la compilacin, la prueba y el mantenimiento.
cliente cuando ya has terminado todo, y es difcil de modificarlas cosas



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 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 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
CODIFICACIN
El diseo debe traducirse en una forma legible para la mquina. El paso de
codificacin realiza esta tarea.
PRUEBA:
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 que hayan 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 ampliacin funcional eso del
rendimiento
CARACTERSTICAS
Es el ms utilizado.



Es una visin del proceso de desarrollo de software como una sucesin de
etapas que producen productos intermedios.
Para que el proyecto tenga xito deben desarrollarse todas las fases.
Las fases continan hasta que los objetivos se han cumplido.
Si se cambia el orden de las fases, el producto final ser de inferior calidad.

VENTAJAS
El modelo cascada por su sencillez solo utiliza los pasos intuitivos necesarios
a la hora de desarrollar el software, adems es muy entendible para cliente.
La planificacin es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco cualificado
DESVENTAJAS
La planificacin es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco cualificado.
No refleja realmente el proceso de desarrollo del software
Se tarda mucho tiempo en pasar por todo el ciclo
Perpeta el fracaso de la industria del software en su comunicacin con el
usuario final
El mantenimiento se realiza en el cdigo fuente
Las revisiones de proyectos de gran complejidad son muy difciles
Impone una estructura de gestin de proyectos
Los proyectos raramente siguen el flujo secuencial que propone el modelo
cascada, hay iteraciones
El cliente no puede establecer al principio todos los requisitos.
El cliente deber tener paciencia pues la versin operativa del producto solo
estar disponible en las ltimas etapas del proyecto.



2.2. METOLOGA ESPIRAL.
2.2.1 DEFINICIN. La metodologa de desarrollo en espiral es una evolucin
de mtodo clsico en cascada (Waterfall, top-down) y se considera un mtodo
de desarrollo incremental. Este tipo de metodologa equivale al de cascada,
pero en l se permite el solapamiento de varias etapas con el objetivo de
flexibilizar y compensar el tiempo de desarrollo total y alcanzar resultados
funcionales en etapas tempranas. Est considerada como un mtodo de
desarrollo rpido y eficiente.
Es adecuada para proyectos en los que se tienen claros los objetivos finales
pero no todos los detalles de implementacin estn elucidados.

La metodologa de desarrollo en espiral permite construir aplicaciones de
tamao medio manteniendo los recursos constantes.

Normalmente el proyecto se divide en mdulos ms pequeos y a cada uno de
ellos se le aplica el siguiente proceso:

Anlisis de requerimientos: Durante esta etapa de estudia detalladamente los
requerimientos que cada objetivo con lleva. Aqu establecen todos los detalles
funcionales deseados.



Diseo del sistema: Con los datos de la etapa anterior, se disea el sistema.

Etapas de construccin: La etapa de construccin comprende bsicamente la
codificacin y test de unidades. Esta etapa es un trabajo de programacin pura.

Test y evaluacin: En esta etapa se realiza un test del mdulo completo as
como su evaluacin frente al estudio de requerimientos. En muchos casos en
es esta etapa los usuarios finales participan de manera activa aportando
informacin decisiva para la usabilidad del sistema.

Puntos fuertes:

Permite el desarrollo de proyectos en donde los objetivos finales estn
perfectamente definidos pero todos los detalles no pueden ser
completamente establecidos al principio.
Es adaptable: algunos de los requerimientos (que no los objetivos)
pueden cambiar durante el ciclo de desarrollo.
Permite la especializacin de los equipos de trabajo.
Apela a una gestin de proyecto ordenada.
Facilita la distribucin de recursos de desarrollo.
Economa: es posible mantener constantes los recursos de desarrollo.
Permite conseguir funcionalidad en etapas tempranas.

MODELO 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.

CARACTERSTICAS DEL MODELO EN ESPIRAL PARA EL DESARROLLO
DE SOFTWARE

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 poder 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.

VENTAJAS DEL MODELO ESPIRAL
No requiere una definicin completa de los requerimientos del software a
desarrollar para comenzar su funcionalidad.
En la terminacin de un producto desde el final de la primera iteracin es muy
factible aprobar los requisitos.



Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos
presentados tempranamente y existe la forma de poder corregirlos a tiempo.

DESVENTAJAS DEL MODELO ESPIRAL
Existe complicacin cuando se evala los riesgos.
Se requiere la participacin continua por parte del cliente.
Se pierde tiempo al volver producir inicialmente una especificacin completa de
los requerimientos cuando se modifica o mejora el software.

POR QU LA NUEMARCIN?
1.3.2 PROGRAMACIN EXTREMA O XP (EXTREME PROGRAMMING).a
primera metodologa ya ha sido comentada y es la que le dio conciencia al
movimiento actual de metodologas giles. De la mano de Kent Beck, XP ha
conformado un extenso grupo de seguidores en todo el mundo, disparando una
gran cantidad de libros a los que dio comienzo el mismo Beck en [Beck, 2000].
Inclusive
Addison-Wesley ha creado una serie de libros denominada The XP Series. Fue
la misma gente del proyecto C3 la que produjo tambin otro de los libros
importantes de XP
[Jeffries, 2001] en el que se bajaban los conceptos de Beck a la puesta en
prctica en un proyecto.
La imagen mental de Beck al crear XP [Beck, 2000] era la de perillas en un
tablero de control. Cada perilla representaba una prctica que de su
experiencia saba que trabajaba bien. Entonces, Beck decidi girar todas las
perillas al mximo para ver que ocurra. As fue como dio inicio a XP.
Los principios de XP citados verbatim de Beck:
El juego de Planeamiento: Rpidamente determinar el alcance del prximo
release mediante la combinacin de prioridades del negocio y estimaciones
tcnicas. A medida que la realidad va cambiando el plan, actualizar el mismo.
Pequeos Releases: Poner un sistema simple en produccin rpidamente,
luego liberar nuevas versiones en ciclos muy cortos.
Metfora: Guiar todo el desarrollo con una historia simple y compartida de
cmo funciona todo el sistema.
Diseo Simple: El sistema deber ser diseado tan simple como sea posible
en cada momento. Complejidad extra es removida apenas es descubierta.
Testing: Los programadores continuamente escriben pruebas unitarias, las
cuales deben correr sin problemas para que el desarrollo contine. Los clientes
escriben pruebas demostrando que las funcionalidades estn terminadas.
Refactoring: Los programadores reestructuran el sistema sin cambiar su
comportamiento para remover duplicacin, mejorar la comunicacin, simplificar,
o aadir flexibilidad.



Programacin de a Pares: Todo el cdigo de produccin es escrito por dos
programadores en una mquina.
Propiedad Colectiva del Cdigo: Cualquiera puede cambiar cdigo en
cualquier parte del sistema en cualquier momento.
Integracin Continua: Integrar y hacer builds del sistema varias veces por
da, cada vez que una tarea se completa.
Semana de 40-horas: Trabajar no ms de 40 horas semanales como regla.
Nunca trabajar horas extras durante dos semanas consecutivas.
Cliente en el lugar de Desarrollo: Incluir un cliente real en el equipo,

disponible de forma full-time para responder preguntas.
Estndares de Codificacin: Los programadores escriben todo el cdigo de
acuerdo con reglas que enfatizan la comunicacin a travs del mismo.
Como se observan, muchas de las prcticas propuestas contribuyen a
maximizar la comunicacin entre las personas, permitiendo de esa forma una
mayor transferencia de conocimiento entre los desarrolladores y con el cliente,
quien tambin es parte del equipo. Esto es logrado en la prctica gracias a la
disposicin fsica del lugar de trabajo.
La idea es reunir a todas las personas en una misma oficina manteniendo una
se observan escritorios dispuestos en el centro con varias computadoras, cada
una con dos sillas dispuestas de forma de permitir la programacin de a pares.
En las paredes se observan pequeos boxes o escritorios con sillas, los cuales
pueden ser usados por los programadores en forma privada, para realizar
llamados, consultar mail, o simplemente descansar la mente.
Consecuentemente se logra el objetivo mencionado al inicio del prrafo de
maximizar la comunicacin y la transferencia de informacin en el rea comn,
mientras que se mantiene la individualidad de las personas en las mencionadas
cavernas.
Asimismo, XP impone un alto nivel de disciplina entre los programadores. El
mismo permite mantener un mnimo nivel de documentacin, lo cual a su vez
se traduce en una gran velocidad en el desarrollo. Sin embargo, una
desventaja que deviene de esta falta de documentacin es la incapacidad de
persistir la arquitectura y dems cuestiones de anlisis, diseo e
implementacin, an despus de que el proyecto haya concluido.
El nfasis que pone en XP en las personas se manifiesta en las diversas
prcticas que indican que se deben dar ms responsabilidades a los
programadores para que estimen su trabajo, puedan entender el diseo de
todo el cdigo producido, y mantengan una metfora mediante la cual se
nombra las clases y mtodos de forma consistente. La prctica denominada
Semana de 40 horas indica la necesidad de mantener un horario fijo, sin horas
extras ya que esto conlleva al desgaste del equipo y a la posible desercin de
sus miembros. Beck afirma que como mximo se podra llegar a trabajar
durante una semana con horas extras, pero si pasando ese tiempo las cosas
no han mejorado entonces se deber hacer un anlisis de las estimaciones de
cada iteracin para que estn acordes a la capacidad de desarrollo del equipo.
Si bien XP es la metodologa gil de ms renombre en la actualidad, se
diferencia de las dems metodologas que forman este grupo en un aspecto en
particular: el alto nivel de disciplina de las personas que participan en el



proyecto. XP ser tratada en detalle ms adelante en relacin a algunas
prcticas que comparte con AgEnD.

Es una metodologa para el desarrollo de software y consiste bsicamente en
ajustarse estrictamente a una serie de reglas que se centran en las
necesidades del cliente para lograr un producto de buena calidad en poco
tiempo.
La Programacin Extrema es una metodologa gil centrada en potenciar las
relaciones interpersonales como clave para el xito en el desarrollo de
software.
Promueve el trabajo en equipo, preocupndose en todo momento del
aprendizaje de los desarrolladores y estableciendo un buen clima de trabajo.
Este tipo de mtodo se basa en una realimentacin continuada entre el cliente
y el equipo de desarrollo con una comunicacin fluida entre todos los
participantes, tambin busca simplificar las soluciones implementadas y coraje
para los mltiples cambios.
Este tipo de programacin es la adecuada para los proyectos con requisitos
imprecisos, muy cambiantes y con un riesgo tcnico excesivo.

1.3.3 ROLES DE LA PROGRAMACIN EXTREMA (XP).
Segn la propuesta de Beck los roles que nos podemos encontrar son los
siguientes:
Programador: El programador escribe las pruebas unitarias y produce el
cdigo del sistema.
Cliente: Escribe las historias de los usuarios y las pruebas funcionales
para validar su implementacin. El cliente da una gran prioridad a las
historias de usuarios y decide cual implementar en cada iteracin
centrndose en aportar mayor valor al negocio.
Encargado de Pruebas (Tester): Ayuda al cliente a escribir las pruebas
funcionales. Se encarga de ejecutar las pruebas con regularidad,
difunde los resultados obtenidos al equipo y es el responsable de las
herramientas que dan soporte a las pruebas.
Encargado de Seguimiento (Tracker) : Es el que proporciona la
realimentacin al equipo. Realiza el seguimiento del proceso de cada
iteracin y verifica el grado de acierto entre las estimaciones realizadas
y el tiempo real dedicado en ello para la mejora de futuras estimaciones.
Entrenador (Coach): Es el responsable del proceso global. Se encarga
de proveer guas al equipo de forma que se apliquen las practicas XP y
se vaya siguiendo el proceso correctamente.
Consultor: Es un miembro externo del equipo con un conocimiento
especfico en algn tema que es necesario para el proyecto, en el que
surgen problemas.
Gestor (Big boss): Es el vnculo entre clientes y programadores, ayuda a
que el equipo trabaje efectivamente creando las condiciones
adecuadas. Su labor esencial es la de coordinacin.



CAPITULO III

EJEMPLOS DE APLICACIN







CAPITULO IV
CONCLUSIONES Y
SUGERENCIAS

CONCLUSIONES

Despus de realizar el presente trabajo grupal se obtuvieron las siguientes
conclusiones:
Las metodologas de desarrollo de Software se basan en diversas pruebas, y
cada una tiene proceso divididos en fases.
Cada metodologa est diseada para cumplir una necesidad especifica es
decir, no todas tienen la misma funcionalidad, por ejemplo si el objetivo es la
fcil y rpida creacin de un programa sencillo se pude utilizar el modelo en



espiral o el de cascada; pero si por el contrario se requiere el diseo de un
programa tecnificado arquitectnico ms complicado.
Por otro lado cabe mencionar que es necesario conocer todas y cada una de
estas metodologas de desarrollo, para poder ser acertados en la eleccin de la
adecuada segn nuestro objetivo.
El prototipo del modelo en espiral para la ingeniera de software es en la
actualidad el enfoque ms realista para el desarrollo de software y de sistemas
a gran escala. Utiliza un enfoque evolutivo para la ingeniera de software,
permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en
cada nivel del modelo en espiral.



CAPITULO V
BIBLIOGRAFIA

1. http://es.wikipedia.org/wiki/Desarrollo_en_espiral
2. http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf
3. http://es.wikipedia.org/wiki/Software#Proceso_de_creaci.C3.B3n_del_software
4.

Martes15 - Ing. SW II

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Martes15 - Ing. SW II

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD SAN PEDRO

Potrebbero piacerti anche