Metodolias Pruebas

Valor Creativo - Autor: Valor Creativo
1

Metodologas
Aseguramiento de
Calidad de Software
C
u
r
s
o
:

P
r
u
e
b
a
s

d
e

S
o
f
t
w
a
r
e

2
0
1
4

INTEGRANTES:
- GALLEGOS COLQUE, Golman
- OSCAMAYTA MAMANI, Omar
- PILCO ORTEGA, Geyler

UPT Pruebas de Software
2

2

Contenido
INTRODUCCION ..................................................................................................................................................... 3
ANTECEDENTES HISTORICOS ........................................................................................................................ 4
DESARROLLO ......................................................................................................................................................... 5
TIPOS DE METODOLOGIA ................................................................................................................................. 8
CUADRO COMPARATIVO ................................................................................................................................. 25
CONCLUSION ........................................................................................................................................................ 29
WEBGRAFIA .......................................................................................................................................................... 30

Metodologas

3

3

INTRODUCCION

Una metodologa de desarrollo de software se refiere a un framework que es usado
para estructurar, planear y controlar el proceso de desarrollo en sistemas de
informacin.
A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados
diferencindose por su fortaleza y debilidad.
El framework para metodologa de desarrollo de software consiste en:
Una filosofa de desarrollo de programas de computacin con el enfoque del
proceso de desarrollo de software
Herramientas, modelos y mtodos para asistir al proceso de desarrollo de
software
Estos frameworks son a menudo vinculados a algn tipo de organizacin, que
adems desarrolla, apoya el uso y promueve la metodologa. La metodologa es a
menudo documentada en algn tipo de documentacin formal.

Metodologa para Aseguramiento Calidad

4

4
ANTECEDENTES HISTORICOS
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.
Metodologas de Desarrollo de Software tiene como objetivo presentar un conjunto
de tcnicas tradicionales y modernas de modelado de sistemas que permitan
desarrollar software de calidad, incluyendo heursticas de construccin y criterios
de comparacin de modelos de sistemas.
Para tal fin se describen, fundamentalmente, herramientas de Anlisis y Diseo
Orientado a Objetos (UML), sus diagramas, especificacin, y criterios de aplicacin
de las mismas. Como complemento se describirn las metodologas de desarrollo
de software que utilizan dichas herramientas, ciclos de vida asociados y discusin
sobre el proceso de desarrollo de software ms adecuado para las diferentes
aplicaciones ejemplos que se presentarn. Principalmente, se presentar el
Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

Kendall y Kendall
I. Identificacin del problema, oportunidades y objetivos. II. Determinacin de los
requerimientos de informacin. III. Anlisis de las necesidades del sistema. IV.
Diseo del sistema recomendado. V. Desarrollo y documentacion del software. VI.
Pruebas y mantenimiento del sistema. VII. Implantacin y evaluacin del sistema.
James Senn
I. Ciclo de vida y desarrollo del sistema. II. Desarrollo por anlisis estructurado III.
Prototipo del sistema.
Llorens Fabregas
I. Requerimientos. II. Analisis/Diseo. III. Construccin. IV. Pruebas. V. Produccin
y mantenimiento.
Jonas Montilva
I. Definir el proyecto. II. Anlisis del contexto. III. Definicin de los requerimientos.
IV. Diseo preliminar. V. Diseo detallado.
Roger Pressman
I. Anlisis de los requerimientos del Software. II. Diseo. III. Genaracion de cdigo.
IV. Pruebas. V. Mantenimiento.
5

5
DESARROLLO
METODOLOGAS PARA DESARROLLO DE SOFTWARE
Un proceso de software detallados y completo suele denominarse Metodologa.
Las metodologas se basan en una combinacin de los modelos de proceso
genricos (cascada, evolutivo, incremental, espiral entre otros). 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
tambin denominadas 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.

A continuacin se revisan brevemente cada una de estas categoras de
metodologas:

METODOLOGAS ESTRUCTURADAS
Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la
Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas
para el Diseo (por ejemplo: el diagrama de Estructura) primero y posteriormente
para el Anlisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologas
son particularmente apropiadas en proyectos que utilizan para la implementacin
lenguajes de 3ra y 4ta generacin.
Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE
(Francia), MTRICA (Espaa), SSADM (Reino Unido). Ejemplos de propuestas de
6

6
mtodos estructurados en el mbito acadmico: Gane & Sarson, Ward & Mellor,
Yourdon & DeMarco e Information Engineering.

METODOLOGAS ORIENTADAS A OBJETOS
Su historia va unida a la evolucin de los lenguajes de programacin orientada a
objeto, los ms representativos: a fines de los 60s SIMULA, a fines de los 70s
Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y
actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a consolidarse
algunos mtodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea
de conseguir una unificacin de sus mtodos y notaciones, que posteriormente se
reorienta a un objetivo ms modesto, para dar lugar al Unified Modeling Language
(UML), la notacin Orientada a Objetos ms popular en la actualidad.
Algunas metodologas orientadas a objetos que utilizan la notacin UML son:

Rational Unified Process (RUP),
OPEN,
MTRICA (que tambin soporta la notacin estructurada).

METODOLOGAS TRADICIONALES
Las metodologas no giles son aquellas que estn guiadas por una fuerte
planificacin durante todo el proceso de desarrollo; llamadas tambin
metodologas tradicionales o clsicas, donde se realiza una intensa etapa de
anlisis y diseo antes de la construccin del sistema.
Todas las propuestas metodolgicas antes indicadas pueden considerarse como
metodologas tradicionales. Aunque en el caso particular de RUP, por el especial
nfasis que presenta en cuanto a su adaptacin a las condiciones del proyecto
(mediante su configuracin previa a aplicarse), realizando una configuracin
adecuada, podra considerarse gil.

METODOLOGAS GILES
Un proceso es gil cuando el desarrollo de software es incremental (entregas
pequeas de software, con ciclos rpidos), cooperativo (cliente y desarrolladores
trabajan juntos constantemente con una cercana comunicacin), sencillo (el
mtodo en s mismo es fcil de aprender y modificar, bien documentado),
y adaptable (permite realizar cambios de ltimo momento).
7

7
Entre las metodologas giles identificadas son:

Extreme Programming
Scrum
Familia de Metodologas Crystal
Feature Driven Development
Proceso Unificado Rational, una configuracin gil
Dynamic Systems Development Method
Adaptive Software Development
Open Source Software Development

8

8
TIPOS DE METODOLOGIA
MODELOS CONVENCIONALES O PRESCRIPTIVOS DE PROCESOS
Los modelos convencionales o modelos prescriptivos de procesos permiten llenar
el marco de trabajo con un conjunto de tareas orientadas al desarrollo de un
software.
Se les llama "prescriptivos" porque presciben un conjunto de elementos del
proceso, tales como:
Actividades del Marco de Trabajo.
Acciones de la Ingeniera del software.
Tareas.
Productos de trabajo.
Aseguramiento de la calidad.
Mecanismos de control del cambio para cada proyecto.

Modelo en Cascada
El modelo en cascada, algunas veces llamado el ciclo de vida clsico, sugiere
un enfoque sistemtico, secuencial hacia el desarrollo del software, que se
inicia con la especificacin de requerimientos del cliente y que contina con
la planeacin, el modelado, la construccin y el despliegue para culminar en
el soporte del software terminado.
Este modelo es aplicable en donde existen ocasiones en que los requisitos
de un problema se entienden de una manera razonable y deben estar bien
definidos, tambin cuando el trabajo fluye desde la comunicacin a travs
del despliegue de una manera casi lineal, esta situacin se encuentra a veces
cuando es necesario hacer adaptaciones o mejoras bien definidas a un
sistema existente.
El modelo en cascada es el paradigma ms antiguo para la ingeniera del
software. Sin embargo, en las dcadas pasadas, las criticas a este modelo de
proceso han ocasionado que aun sus ms fervientes practicantes hayan
cuestionado su eficacia. Entre los problemas que algunas veces se
encuentran al aplicar el modelo en cascada estn:
1. Es muy raro que los proyectos reales sigan el flujo secuencial que
propone el modelo. A pesar de que el modelo lineal incluye
iteraciones, lo hace de manera indirecta. Como resultado, los
cambios confunden mientras el equipo de proyecto acta.
9

9
2. Con frecuencia es difcil para el cliente establecer todos los requisitos
de manera explcita. El modelo en cascada lo requiere y se enfrentan
dificultades al incorporar la incertidumbre natural presente en el
inicio de muchos proyectos.
3. El cliente debe tener paciencia. Una versin que funcione de los
programas estar disponible cuando el proyecto est muy avanzado.
Un error grave ser desastroso si no se detecta antes de la revisin
del programa.
En un anlisis interesante de proyectos reales, Bradac(1994) concluy que
la naturaleza lineal del modelo en cascada conduce a "estados de bloqueo"
en los cuales algunos miembros del equipo del proyecto deben esperar a
otros para terminar tareas dependientes. De hecho, el tiempo de espera
puede superar el que se aplica en el trabajo productivo. El estado de
bloqueo tiende a ser ms comn al principio y al final del proceso
secuencial.
En la actualidad, el trabajo del software est acelerado y sujeto a una cadena
infinita de cambios (de caractersticas, funciones y contenido de la
informacin). Con frecuencia, el modelo en cascada no es apropiado para
dicho trabajo. Sin embargo, puede servir como un modelo de proceso til en
situaciones donde los requerimientos estn fijos y donde el trabajo se
realiza, hasta su conclusin, de una manera lineal.

Modelo de Procesos Incrementables
El modelo incremental combina elementos del modelo en cascada aplicado
en forma iterativa.El modelo incremental aplica secuencias lineales de
manera escalonada conforme avanza el tiempo en el calendario. Cada
secuencia lineal produce "incrementos" del software. Por ejemplo, el
software procesador de texto, desarrollado con el paradigma incremental
en su primer incremento, podra realizar funciones bsicas de
administracin de archivos, edicin y produccin de documentos; en el
segundo incremento, ediciones ms sofisticadas, y tendra funciones ms
complejas de produccin de documentos; en el tercer incremento, funciones
de correccin ortogrfica y gramatical; y en el cuarto, capacidades
avanzadas de configuracin de pgina. Se debe tener en cuenta que el flujo
del proceso de cualquier incremento puede incorporar el paradigma de
construccin de prototipos que se expone ms adelante.
A menudo, al utilizar un modelo incremental el primer incremento es un
producto esencial. Es decir, se incorporan los requisitos bsicos, pero
10

10
muchas caractersticas suplementarias (algunas conocidas, otras no) no se
incorporan. El producto esencial queda en manos del cliente (o se somete a
una evaluacin detallada). Como resultado de la evaluacin se desarrolla un
plan para el incremento siguiente. El plan afronta la modificacin del
producto esencial con el fin de satisfacer de mejor manera las necesidades
del cliente y la entrega de caractersticas y funcionalidades adicionales. Este
proceso se repite despus de la entrega de cada incremento mientras no se
haya elaborado el producto completo.
El modelo de proceso incremental, al igual que la construccin de
prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a
diferencia de la construccin de prototipos, el modelo incremental se enfoca
en la entrega de un producto operacional con cada incremento. Los
primeros incrementos son versiones incompletas del producto final, pero
proporcionan al usuario la funcionalidad que necesita y una plataforma
para evaluarlo.
El desarrollo incremental es til sobre todo cuando el personal necesario
para una implementacin completa no est disponible. Los primeros
incrementos se pueden implementar con menos gente. Si el producto
esencial es bien recibido se agrega (si se requiere) ms personal para
implementar el incremento siguiente. Adems, los incrementos se pueden
planear para manejar los riesgos tcnicos. Por ejemplo, un sistema grande
podra requerir la disponibilidad de un hardware nuevo que est en
desarrollo y cuya fecha de entrega es incierta. Sera posible planear los
primeros incrementos de forma que se evite el uso de este hardware, lo que
permitira la entrega de funcionalidad parcial a los usuarios finales sin
retrasos desordenados.

Modelo de desarrollo rpido de aplicaciones (DRA)
El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso de
software incremental que resalta un ciclo de desarrollo corto. El modelo
DRA es una adaptacin a "alta velocidad" del modelo en cascada en el que se
logra el desarrollo rpido mediante un enfoque de construccin basado en
componentes. Si se entienden bien los requisitos y se limita el mbito del
proyecto, el proceso DRA permite que un equipo de desarrollo cree un
"sistema completamente funcional" dentro de un periodo muy corto (por
ejemplo, de 60 a 90 das).
Como otros modelos de proceso, el enfoque DRA cumple con las actividades
genricas del marco de trabajo que ya se han presentado. La comunicacin
11

11
trabaja para entender el problema de negocios y las caractersticas de
informacin que debe incluir el software. La planeacin es esencial porque
varios equipos de software trabajan en paralelo sobre diferentes funciones
del sistema. El modelado incluye tres grandes fases modelado de
negocios, modelado de datos y modelado del proceso y establece
representaciones del diseo que sirven como base para la actividad de
construccin del modelo DRA. La construccin resalta el empleo de
componentes de software existente y la aplicacin de la generacin
automtica de cdigo. Por ltimo, el despliegue establece una base para las
iteraciones subsecuentes, si stas son necesarias.
El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las
restricciones de tiempo impuestas sobre un proyecto DRA exigen un
"mbito de escalas". Si una aplicacin de negocios se puede modular de
forma que cada gran funcin pueda completarse en menos de tres meses
(mediante la aplicacin del enfoque ya descrito), sta es una candidata para
el DRA. Cada gran funcin se puede abordar mediante un equipo de DRA
por separado, para despus integrarlas y formar un todo.
Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes:
1) Para proyectos grandes, pero escalables, el DRA necesita suficientes
recursos humanos para crear en nmero correcto de equipos DRA.
2) Si los desarrolladores y clientes no se comprometen con las actividades
rpidas necesarias para completar el sistema en un marco de tiempo
muy breve, los proyectos DRA fallarn.
3) Si un sistema no se puede modular en forma apropiada, la construccin
de los componentes necesarios para el DRA ser problemtica.
4) Si el alto rendimiento es un aspecto importante, y se alcanzar al
convertir interfaces en componentes del sistema, el enfoque DRA podra
no funcionar.
5) El DRA sera inapropiado cuando los riesgos tcnicos son altos (por
ejemplo, cuando una aplicacin nueva aplica muchas nuevas
tecnologas).
Es un modelo de proceso del software incremental que resulta un ciclo de
desarrollo corto. El modelo DRA es una adaptacin a alta velocidad del
modelo en cascada en el que se logra el desarrollo rpido mediante un
enfoque de construccin basado en componentes. Hace un uso intensivo de
componentes reusables de software con un ciclo de desarrollo
extremadamente corto.

12

12
Modelos Evolutivos
Se reconoce que el software al igual que todos los sistemas complejos
evoluciona con el tiempo, los requisitos de gestin y de producto a menudo
cambian conforme a que el desarrollo procede haciendo que el camino que
lleva al producto final no sea real. El desarrollo evolutivo consta del
desarrollo de una versin inicial que luego de exponerse se va refinando de
acuerdo de los comentarios o nuevos requerimientos por parte del cliente o
del usuario final. Los modelos evolutivos son iterativos, se caracteriza por la
forma en que permiten a los ingenieros en software desarrollar versiones
cada vez ms completas del software. A continuacin se presentan algunos
de los modelos que se clasifican en esta categora.
Construccin de prototipos
Modelos en espiral
Modelo de desarrollo concurrente
Etapas:
Plan rpido.
Modelado, diseo rpido.
Construccin del Prototipo.
Desarrollo, entrega y retroalimentacin.
Comunicacin.
Ventajas:
Este modelo es til cuando el cliente conoce los objetivos generales
para el software, pero no identifica los requisitos detallados de
entrada, procesamiento o salida.
Tambin ofrece un mejor enfoque cuando el responsable del
desarrollo del software est inseguro de la eficacia de un algoritmo,
de la adaptabilidad de un sistema operativo o de la forma que
debera tomar la interaccin humano-mquina.
Reduce el riesgo de construir productos que no satisfagan las
necesidades de los usuarios.
Reduce costos y aumenta la probabilidad de xito.
Exige disponer de las herramientas adecuadas.
Una vez identificados todos los requisitos mediante el prototipo, se
construye el producto de ingeniera.
Desventajas:
El usuario tiende a crearse unas expectativas cuando ve el prototipo
de cara al sistema final. A causa de la intencin de crear un prototipo
13

13
de forma rpida, se suelen desatender aspectos importantes, tales
como la calidad y el mantenimiento a largo plazo, lo que obliga en la
mayor parte de los casos a reconstruirlo una vez que el prototipo ha
cumplido su funcin. Es frecuente que el usuario se muestre reacio a
ello y pida que sobre ese prototipo se construya el sistema final, lo
que lo convertira en un prototipo evolutivo, pero partiendo de un
estado poco recomendado.
El desarrollador suele tomar algunas decisiones de implementacin
poco convenientes (por ejemplo, elegir un lenguaje de programacin
incorrecto porque proporcione un desarrollo ms rpido). Con el
paso del tiempo, el desarrollador puede olvidarse de la razn que le
llev a tomar tales decisiones, con lo que se corre el riesgo de que
dichas elecciones pasen a formar parte del sistema final.

Modelo en Espiral
El modelo en espiral representa en forma de espiral una secuencia de
actividades.2 Este modelo fue originalmente propuesto por Boehm en 1988,
y se diferencia de los dems modelos por considerar el riesgo. El modelo en
espiral para la ingeniera de software es actualmente el enfoque ms
realista para el desarrollo de software y de sistemas a gran escala. Utiliza un
enfoque evolutivo, permitiendo al desarrollador y al cliente entender y
reaccionar ante los riesgos en cada nivel evolutivo.2
El modelo en espiral se divide en un nmero de actividades estructurales,
tambin llamadas regiones de tareas, segn Sommerville (2005) el ciclo de
vida del modelo en espiral se divide cuatro sectores:
1. Definicin de objetivos. En esta fase se identifica las restricciones
del proceso y le producto, y dependiendo los riesgos para trazar
objetivos y respectivamente panes estratgicos.
2. Evaluacin y reduccin de riesgos. Se hace un anlisis detallado
para casa riesgo y se establece los pasos para reducirlos.
3. Desarrollo y validacin. Despus de evaluar los riesgos, se elige un
modelo para el desarrollo del sistema.
4. Planificacin. El proyecto se revisa y se toma la decisin de si debe
continuar con un ciclo posterior de la espiral.
Las caractersticas que se pueden indicar del modelo en espiral son:
El software se desarrolla en una serie de versiones incremntales.
Durante las primeras iteraciones.
14

14
La versin incremental podra ser un modelo en papel o un
prototipo.
A medida que se va incrementando el nmero de iteraciones, se
producen versiones cada vez mas completas.
Ventajas:
Puede adaptarse y aplicarse a lo largo de la vida del software.
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.
Permite a quien lo desarrolla aplicar el enfoque de construccin de
prototipos en cualquier etapa de evolucin del producto.
Demanda una consideracin directa de los riesgos tcnicos en todas
las etapas del proyecto. Reduce los riesgos antes de que se
conviertan en problemticos.
Desventajas:
Puede resultar difcil convencer la grandes clientes de que el enfoque
evolutivo es controlable (particularmente en situaciones de
contrato).
Si un riesgo importante no es descubierto y gestionado,
indudablemente surgirn problemas.
Como es un modelo relativamente nuevo no es muy utilizado.
Otros inconvenientes que pueden surgir es convencer al cliente que
es un enfoque controlable,por lo que se requiere de experiencia en la
identificacin de riesgos y refinamiento para su uso generalizado.

Modelos iterativos
Este modelo busca reducir el riesgo que surge entre las necesidades del
usuario y el producto final por malos entendidos durante la etapa de
recogida de requisitos. Consiste en la iteracin de varios ciclos de vida en
cascada. Al final de cada iteracin se le entrega al cliente una versin
mejorada o con mayores funcionalidades del producto. El cliente es quien
despus de cada iteracin evala el producto y lo corrige o propone
mejoras. Estas iteraciones se repetirn hasta obtener un producto que
satisfaga las necesidades del cliente.
El modelo iterativo se suele utilizar en proyectos en los que los requisitos
no estn claros por parte del usuario, por lo que se hace necesaria la
creacin de distintos prototipos para presentarlos y conseguir la
15

15
conformidad del cliente. Cada iteracin es un mini proyecto en cascada auto
contenido compuesto de actividades como anlisis de requerimientos,
diseo, programacin y pruebas.
Ventajas:
Permite crear cada vez versiones ms completas de software
Resolucin de problemas de alto riesgo en tiempos tempranos del
proyecto.
Visin de avance en el desarrollo desde las etapas iniciales del
desarrollo.
Menor tasa de fallo del proyecto, mejor productividad del equipo, y
menor cantidad de defectos
El trabajo iterativo deja una experiencia en el equipo que permite ir
ajustando y mejorando las planificaciones, logrando menores
desvos en la duracin total del proyecto.
Desventajas:
Requiere de un cliente involucrado durante todo el curso del
proyecto. Hay clientes que simplemente no estarn dispuestos a
invertir el tiempo necesario.
Infunde responsabilidad en el equipo de desarrollo al trabajar
directamente con el cliente, requiriendo de profesionales sobre el
promedio.

16

16
MODELOS DE DESARROLLO GILES
Las metodologas giles son un conjunto de mtodos de ingeniera del software,
que se basan en el desarrollo iterativo e incremental, teniendo presente los
cambios y respondiendo a estos mediante la colaboracin de un grupo de
desarrolladores auto-organizados y multidisciplinares.
En las metodologas giles, los procesos se desarrollan de manera solapada, donde
el ciclo de vida del proyecto, es cclico. La diferencia en el ciclo de vida de un
proyecto gil, en comparacin con uno tradicional, se debe a la forma en la que el
agilismo, solapa los procesos de manera iterativa.
La tendencia del control de procesos para desarrollo de software ha trado como
resultado que proyectos no resulten exitosos debido al cambiante contexto que
existe, por lo cul las metodologas giles pretende resolver este inconveniente,
construyendo soluciones a la medida asegurando la calidad.

Programacin Extrema (XP)
La programacin extrema (XP, extreme Programming) es un modelo de
proceso de software el fue acuado por Beck el cual toma los principios y
practicas aceptadas y las lleva a niveles extremos. Tiene como objetivo
reducir el riesgo en el ciclo de vida del software mediante grupos de
desarrollo pequeos, considera que la mejor manera de tratar la falta de
requisitos estables en un sistemas, es mediante la agilidad de un grupo
pequeo de desarrollo 8 . Esta se basa en la simplicidad, la comunicacin y
el reciclado continuo de cdigo. El modelo considera varios aspectos
problemticos del desarrollo de software como lo son los retrasos ,
proyectos cancelados, cambios en el negocio y la rotacin del personal. Sus
actividades bsicas son : Codificar, hacer pruebas, escuchar y disear.
Los objetivos de XP son muy simples:
1. La satisfaccin del cliente: trata de dar al cliente el software que l
necesita y cuando lo necesita.
2. Potenciar al mximo el trabajo en grupo: Tanto los jefes de proyecto,
los clientes y desarrolladores, son parte del equipo y estn
involucrados en el desarrollo del software.
XP define cuatro variables para proyectos de software: coste, tiempo,
calidad y mbito. Adems de estas cuatro variables, Beck propone que slo
tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y
clientes), mientras que el valor de la cuarta variable debe ser establecido
por los programadores en funcin de las otras tres.
17

17
Los valores originales de la programacin extrema son:

Simplicidad: XP propone el principio de hacer la cosa ms simple que
pueda funcionar, en relacin al proceso y la codificacin. Esta es la
base de la programacin extrema.
Comunicacin: Los programadores se comunican constantemente
gracias a la programacin por parejas y adems la comunicacin con
el cliente es fluida ya que el cliente forma parte del equipo de
desarrollo
Retroalimentacin: retroalimentacin concreta y frecuente del
cliente, del equipo y de los usuarios finales da una mayor
oportunidad de dirigir el esfuerzo.
Coraje o valenta : La valenta le permite a los desarrolladores que se
sientan cmodos con reconstruir su cdigo cuando sea necesario.
Esto significa revisar el sistema existente y modificarlo si con ello los
cambios futuros se implementaran mas fcilmente.
Principios bsicos en la Programacin extrema:
Planificacin Incremental: los requerimientos se registran en tarjetas
de historias, estas incluyen el tiempo y la prioridad relativa.
Entregas pequeas: estas entregas son frecuentes e
incrementalmente aaden funcionalidad al primera entrega
Diseo sencillo: solo se lleva a cabo el diseo necesario para cumplir
los requerimientos actuales
Desarrollo previamente probado; se utiliza un sistema de pruebas,
para escribir pruebas de las nuevas funcionalidades antes de que
estas se implementen.
Refactorizacin: conserva el cdigo sencillo y mantenible.
Programacin en parejas: esta es la mas importante de todos los
principios, los desarrolladores trabajan en parejas, verificando cada
uno el trabajo del otro, proporcionando la ayuda para hacer siempre
un buen trabajo
Propiedad colectiva: las parejas trabajan en todas las reas del
sistema.
Integracin continua: cuanto acaba el trabajo en una tarea, se integra
en el sistema entero.
Ritmo sostenible: No se consideran aceptables grandes cantidades de
horas extras, ya que a menudo, reduce la calidad del codigo y la
productividad a medio plazo.
18

18
Cliente presente: Debe estar disponible al equipo de XP, un
represente de los usuarios finales del sistema a tiempo completo. En
un proceso XP el cliente es parte del equipo de desarrollo

Desarrollo Adaptativo del Software (DAS)
El desarrollo adaptativo de software (DAS) 1998 fue propuestos por Jim
Highsmith como una metodologa para desarrollar el software y sistemas
muy complejos. Este se centra en la colaboracin humana y la organizacin
del equipo 2. El Desarrollo adaptativo del software proporciona un marco
para el desarrollo iterativo de sistemas grandes y complejos, el mismo
fomenta el desarrollo iterativo e incremental con el uso de prototipos.
El ciclo de vida del DAS se conforma de tres fases: Especulacin,
colaboracin y aprendizaje
Fase de especulacin: Es la primera de las fases esta inicia en el
desarrollo del proyecto. Se utiliza informacin como la visin del cliente,
las restricciones del proyecto y los requisitos bsicos para definir el
conjunto de ciclos en el que se harn los incrementos del software. En
esta fase es donde se lleva a cabo la planificacin tentativa del proyecto
en funcin de las entregas que se iran realizando
Fase de colaboracin: Se busca que el equipo colabore inmensamente
para lograr la funcionalidad planeada, se comunique o se encuentre
completamente integrados, se desea que exista confianza, donde se
puedan realizar crticas constructivas y ayudar si resentimientos, as
como tambin comunicar de una forma oportuna los problemas que se
presenten para tomar acciones efectivas y poseer un conjunto de
actitudes que contribuyan al trabajo que se encuentran realizando.
Fase del aprendizaje: consiste en la revisin de calidad que se realiza al
final de cada ciclo, esto permite mejorar el entendimiento real sobre la
tecnologa, los procesos utilizados y el proyecto. El aprendizaje
individual permite al equipo tener mayor posibilidad de xito.

Modelo de Desarrollo de Sistemas Dinmicos (MDSD)
Es un metodo de desarrollo agil de software que apoyado por su continua
implicacion del usuario en un desarrollo iterativo y creciente que sea
sensible a los requerimientos cambiantes, para desarrollar un sistema que
reuna las necesiadades de la empresa en tiempo y presuspuesto. Este se
caracteriza por proporcionar un marco de trabajo el cual permita construir
19

19
y mantener sistemas con restricciones de tiempo muy estrechas mediante el
empleo de la construccin de prototipos incremntales en un ambiente de
proyecto controlado
El MDSD comienza con un estudio de viabilidad y de negocio, son las
primeras actividades que deben realizarse
Estudio viabilidad: Se evala si la aplicacin es viable, para el
proceso teniendo en cuenta los requisitos bsicos del negocio y sus
restricciones asociadas.
Estudio de negocios: establece los requisitos funcionales y de
informacin que permitirn que la aplicacin proporcione un valor al
negocio; tambin define la arquitectura bsica de la aplicacin.
El resto del proceso forma tres ciclos iterativos que son:
Iteracin de modelo funcional: produce una serie de prototipos
incremntales que demuestran la funcionalidad para el cliente. Su
propsito durante este ciclo es recopilar requisitos adicionales y
producir documentacin de anlisis.
Iteracin de construccin y diseo: revisa la construccin de
prototipos durante la iteracin del modelo funcional, en este se
disea el sistema para el uso operacional. En algunos casos, la
iteracin del modelo funcional y esta, suceden en forma concurrente.
Implementacin: coloca el incremento de software ms reciente en el
ambiente operativo, se ocupa del despliegue al uso operacional.
Puede destacarse que 1) el incremento puede no estar 100 por
ciento completo o 2) se pueden requerir cambios cuando el
incremento se coloca en el sitio.

Modelo Scrum
Scrum es una metodologa gil de gestin de proyectos cuyo objetivo
primordial es elevar al mximo la productividad de un equipo, fue
desarrollado por Jeff Sutherland y elaborado ms formalmente por Ken
Schwaber. 11. Se enfoca en el hecho de que procesos definidos y repetibles
slo funcionan para atacar problemas definidos y repetibles con gente
definida y repetible en ambientes definidos y repetibles. Y se divide un
proyecto en iteraciones (que ellos llaman carreras cortas) de 30 das. La
literatura de Scrum se orienta principalmente en la planeacin iterativa y el
seguimiento del proceso .

20

20
Caractersticas:
Enfatiza valores y prcticas de gestin, sin pronunciarse sobre
requerimientos, prcticas de desarrollo, implementacin y dems
cuestiones tcnicas.
Hace uso de Equipos auto-dirigidos y auto-organizados
Puede ser aplicado tericamente a cualquier contexto en donde un
grupo de gente necesita trabajar junta para lograr una meta comn.
Desarrollo de software iterativos incrementales basados en prcticas
agiles
Iteraciones de treinta das; aunque se pueden realizar con mas
frecuencia, estas iteraciones, conocidas como Sprint
Dentro de cada Sprint se denomina el Scrum Master al Lder de
Proyecto quien llevar a cabo la gestin de la iteracin
Se convocan diariamente un Scrum Daily Meeting el cual
representa una reunin de avance diaria de no ms de 15 minutos
con el propsito de tener realimentacin sobre las tareas de los
recursos y los obstculos que se presentan. En la cual se responden
preguntas como: Qu has hecho desde el ultimo encunetro? Qu
obstaculos hay para cumplir la meta? Qu haras antes del proximo
encuentro?
Ciclo de Vida de Scrum
En cuanto al ciclo de vida del modelo Scrum es el siguiente:
1. Pre-Juego / Planeamiento: El propsito es establecer la visin,
definir expectativas y asegurarse la financiacin. Las actividades son
la escritura de la visin, el presupuesto, el registro de acumulacin o
retraso Metodologas giles (backlog) del producto inicial y los tems
estimados, as como la arquitectura de alto nivel, el diseo
exploratorio y los prototipos. El registro de acumulacin es de alto
nivel de abstraccin.
2. Pre-Juego / Montaje (Staging): El propsito es identificar ms
requerimientos y priorizar las tareas para la primera iteracin. Las
actividades son planificacin, diseo exploratorio y prototipos.
3. Juego / Desarrollo: El propsito es implementar un sistema listo
para entrega en una serie de iteraciones de treinta das llamadas
corridas (sprints). Las actividades son un encuentro de
planeamiento de corridas en cada iteracin, la definicin del registro
de acumulacin de corridas y los estimados, y encuentros diarios de
Scrum.
21

21
4. Pos-Juego/ Liberacin: El propsito es el despliegue operacional.
Las actividades, documentacin, entrenamiento, mercadeo y venta.

Desarrollo conducido por caractersticas (DCC)
El desarrollo conducido por caractersticas (DCC) lo concibieron
originalmente Peter Coad como un modelo de proceso prctico para la
ingeniera del software orientada a objetos. Stephen Palmer y John Felsin
han extendido y mejorado el trabajo de Coad, al describir un proceso
adaptativo y gil que puede aplicarse en proyectos de software de tamao
moderado y grande. En el contexto del DCC una caracterstica "es una
funcin evaluada por el cliente que puede implementarse en dos semanas o
menos.13
Beneficios que se le concede a la definicin de caractersticas:
Las caractersticas se pueden organizar en un agrupamiento
jerrquico relacionado con el negocio.
Como las caractersticas son bloques pequeos de funcionalidad
entregable, los usuarios las describen con mayor facilidad, pueden
entender cmo stas se relacionan con otras con mayor rapidez, y
pueden revisarlas de mejor manera en bsqueda de ambigedades,
errores u omisiones.
Una caracterstica es el incremento de software entregable, el equipo
desarrolla caractersticas operativas cada dos semanas.
Debido a que las caractersticas son pequeas, sus diseos y
representaciones de cdigo son ms fciles de inspeccionar de
manera efectiva
El DCC se encuentra dividido en cinco fases o actividades:
1. Desarrollar un modelo General
2. Elaborar una lista de caractersticas
3. Plan por caractersticas
4. Diseo por caractersticas
5. Construccin por caractersticas
El desarrollo de un modelo general: En una fase ya se tiene el dominio, el
contexto, y los requerimientos del sistema a construir. En este momento se
posee informacin bsica de las especificaciones funcionales. referencias
La construccin de la lista de caractersticas los ensayos, modelos de
objetos y documentacin de requerimientos proporcionan la base para
22

22
construir una amplia lista de caractersticas . Las funciones se agrupan
conforme a diversas actividades en reas de dominio especificas y la lista de
caractersticas es revisada por los usuarios para asegurar su validez y
exhaustividad
El diseo y la construccin por caractersticas, se selecciona las
caractersticas a desarrollar y los equipos dispuestos por cada una de ellas.
Luego se procede iterativamente hasta que se producen las caractersticas
seleccionadas.

Proceso Unificado de Rational (RUP)
El Proceso Unificado de Rational es una metodologa de desarrollo de
software orientada a objetos creada por Rational Software Corporation.
Es una de las metodologas ms extendidas y conocidas por su amplia
difusin comercial. Se puede estudiar como una metodologa representativa
de tipo clsico. Fue definido por los creadores del UML unificando los
mtodos de Ivar Jacobson, Grady Booch y James Rumbaugh. El hecho de que
la empresa RATIONAL tambin distribuya herramientas especficas basadas
en el mismo mtodo, que facilitan el desarrollo, ha contribuido a su gran
expansin
Las caractersticas que tiene el RUP. son:
Est basado en componentes. Estos componentes a su vez estn
conectados entre s a travs de interfaces.
Utiliza el UML como notacin bsica.
Dirigido por casos de uso. El proceso utiliza Casos de Uso para
manejar el proceso de desarrollo desde la Incepcin hasta el
Despliegue.
Centrado en la arquitectura. El proceso busca entender los
aspectos estticos y dinmicos ms significativos en trminos de
arquitectura de software. La arquitectura se define en funcin de las
necesidades de los usuarios y se determina a partir de los Casos de
Uso base del negocio.
Ciclo de vida iterativo e incremental. El proceso reconoce que es
prctico dividir grandes proyectos en proyectos ms pequeos o
mini-proyectos. Cada mini-proyecto comprende una iteracin que
resulta en un incremento. Una iteracin puede abarcar la totalidad
de los flujos del proceso. Las iteraciones son planificadas en base a
los Casos de Uso.
23

23
Proceso de cuatro fases
El proceso Unificado consta de ciclos que puede repetir a lo largo del ciclo
de vida de un sistema. Un ciclo consiste en cuatro fases: Incepcin,
Elaboracin, Construccin y Transicin. Un ciclo concluye con una
liberacin, tambien hay versiones dentro de un ciclo.
Esta es una descripcin breve de las fases de un ciclo:
Fase de Incepcin: Durante la fase inicial se concibe la idea central
del producto, se arma el documento de visin. En esta fase, se
revisan y confirma nuestro entendimiento sobre los objetivos
centrales del negocio. Queremos entender los argumentos
comerciales en favor de porqu el proyecto debe intentarse. La fase
de incepcin establece la viabilidad del producto y delimita el
alcance del proyecto.
Se describe el producto final. Se responde a las preguntas:
Cules son las principales funciones del sistema para sus
usuarios ms importantes?. La respuesta est en el modelo de
casos de uso simplificado.
Cmo podra ser la arquitectura del sistema?
Cul es el plan del proyecto y cunto costar desarrollar el
producto?

Fase de Elaboracin: Durante la fase de elaboracin la mayora de
los Casos de Uso son especificados en detalle y la arquitectura del
sistema es diseada. Esta fase se focaliza en las -bilidades del
proyecto. Se identifican los riesgos significativos y se preparan el
calendario, el equipo de trabajo y el costo del proyecto.
Fase de Construccin: Durante la fase de construccin, el foco del
producto se mueve de la arquitectura de base a un sistema lo
suficientemente completo como para llevarlo al usuario. El baseline
de arquitectura crece en complejidad y se convierte en un sistema
completo, de la misma manera, se refina el disea para llevarlo a
cdigo fuente.
Se construye el producto, se utilizan la mayor parte de los recursos, y
al finalizar se cubren todos los casos de uso. La pregunta que se
realiza es: Cubre el producto las necesidades de los usuarios como
para hacer una primera entrega?

24

24
Fase de Transicin: En la fase de transicin el objetivos es
garantizar que los requisitos se han cumplido, con la satisfaccin de
las partes interesadas. Esta fase a menudo se inicia con una versin
beta de la aplicacin. Otras actividades incluyen la preparacin del
ambiente, se completan, se identifican y corrigen defectos. La fase de
transicin termina con un cierre dedicado al aprendizaje de
lecciones, las cuales quedan para futuros ciclos.El producto existe en
versin Beta.

25

25
CUADRO COMPARATIVO
DIFERENCIAS ENTRE LOS MODELOS DE PROCESO CONVENCIONALES Y GILES

METODOLOGAS GILES METODOLOGAS CONVENCIONALES
Estn basadas en heurstica
provenientes de prcticas de
produccin de cdigos.
Estn preparadas para
cambios durante el proyecto.
Son impuestas internamente
(por el equipo).
Proceso menos controlado.
No existe contrato tradicional.
Son bastante flexibles.
El cliente es parte del equipo
de desarrollo.
Grupos pequeos y trabajando
en el mismo sitio.
Menos nfasis en la
arquitectura del software.
La arquitectura del software
es esencial y se expresa
mediante modelos
Basadas en normas provenientes
de estndares.
Presentan cierta resistencia a los
cambios.
Impuestas externamente.
Proceso mucho mas controlado,
con numerosas polticas.
Existe un contrato prefijado.
Son un poco rgidas.
El cliente interacta con el
equipo de desarrollo mediante
reuniones.
Grupos grandes y posiblemente
distribuidos.

METODOLOGA GIL METODOLOGA TRADICIONAL
Pocos Artefactos. El modelado
es prescindible, modelos
desechables.
Ms Artefactos. El modelado es
esencial, mantenimiento de
modelos
Pocos Roles, ms genricos y
flexibles
Ms Roles, ms especficos
No existe un contrato
tradicional, debe ser bastante
flexible
Existe un contrato prefijado
Cliente es parte del equipo de
desarrollo (adems in-situ)
El cliente interacta con el equipo
de desarrollo mediante reuniones
Orientada a proyectos
pequeos. Corta duracin (o
entregas frecuentes), equipos
Aplicables a proyectos de
cualquier tamao, pero suelen ser
especialmente efectivas/usadas en
26

26
pequeos (< 10 integrantes) y
trabajando en el mismo sitio
proyectos grandes y con equipos
posiblemente dispersos
La arquitectura se va
definiendo y mejorando a lo
largo del proyecto
Se promueve que la arquitectura
se defina tempranamente en el
proyecto
nfasis en los aspectos
humanos: el individuo y el
trabajo en equipo
nfasis en la definicin del
proceso: roles, actividades y
artefactos
Basadas en heursticas
provenientes de prcticas de
produccin de cdigo
Basadas en normas provenientes
de estndares seguidos por el
entorno de desarrollo
Se esperan cambios durante el
proyecto
Se espera que no ocurran cambios
de gran impacto durante el
proyecto

DIFERENCIAS ENTRE MODELOS
Modelo en
cascada
Modelo en
espiral
Modelo
incremental
Modelo DRA
(Desarrollo
Rpido de
Aplicaciones)
XP (Xtreme
Programming)
Qu es? Es el enfoque
metodolgico
que ordena
rigurosamente
las etapas del
ciclo de vida del
software
Consiste en una
serie de ciclos
que se repiten en
forma de espiral,
comenzando
desde el centro..
El incremental
es un modelo
de tipo
evolutivo que
est basado en
varios ciclos
Cascada
realimentados
aplicados
repetidamente,
con una
filosofa
iterativa
Es un modelo de
proceso de
desarrollo de
software lineal
secuencial que
enfatiza un ciclo
de desarrollo
extremadamente
corto.
Es una metodologa ligera
de desarrollo de software
que se basa en la
simplicidad.
Fases del
modelo
1. Anlisis de
requerimientos:
Contiene la
especificacin
completa de lo
que debe hacer
el sistema sin
entrar en
detalles
internos. 2.
Diseo del
Sistema
Contiene la
descripcin de
1. establecer la
comunicacin
entre el cliente y
el desarrollador.
2. definicin de
los recursos,
tiempo y otra
informacin
relacionada con
el proyecto. 3.
evaluar los
riesgos tcnicos
y de gestin del
proyecto. 4.
Dentro de
modelo
incremental
podemos
encontrar el
modelo DRA.
1.Modelado de
gestin: flujo de
informacin
entre las
funciones de
gestin responde
las siguientes
preguntas: que
informacin
conduce al
proceso de
gestin?, A
dnde va la
informacin?,
1. planificacin del
proyecto.definir las
historias de usuario con el
cliente, las historias de
usuario tienen la misma
finalidad que los casos de
uso, pero con algunas
diferencias, constan de 3 o
4 lineas escritas por el
cliente en un lenguaje no
tcnico, sin profundizar
mucho en los detalles.

2. diseo.
27

27
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.
3. Diseo del
Programa Es la
fase en donde
se realizan los
algoritmos
necesarios para
el cumplimiento
de los
requerimientos
del usuario. 4.
Codificacin 5.
Pruebas 6.
Implantacin
construir una o
ms
representaciones
de la aplicacin
software. 5.
construir la
aplicacin,
instalarla,
probarla y
proporcionar
soporte al
usuario o cliente
6. obtener la
reaccin del
cliente, segn la
evaluacin de lo
creado e
instalado en los
ciclos anteriores.
Quin la
procesa?

2.-modelado de
datos:flujo de
informacin
definido como
parte de la fase
del modelado de
gestin se refina
como un
conjunto de
objetos y datos
necesarios para
apoyar la
empresa.
3.modelado de
procesos: los
objetos de datos
definidos en la
fase de
modelado
quedan
transformados
para lograr el fin
deseado.

3. codificacin. Debe
hacerse atendiendo
estndares de codificacin
ya creados, para facilitar su
comprensin y
escalabilidad.

4 pruebas.
Uso de test para
comprobar el
funcionamiento de los
cdigos que se van
implementando.
Ventajas Se tiene todo
bien organizado
y no se
mezclan las
fases. Es
perfecto para
proyectos que
son rgidos, y
adems donde
se especifiquen
muy bien los
requerimientos
y se conozca
muy bien la
herramienta a
utilizar
Reduce riesgos
del proyecto
Incorpora
objetivos de
calidad. Integra
el desarrollo con
el
mantenimiento,
etc. Adems es
posible tener en
cuenta mejoras y
nuevos
requerimientos
sin romper con la
metodologa, ya
que este ciclo de
vida no es rgido
ni esttico.
Se reduce el
tiempo de
desarrollo
inicial, ya que
se implementa
la funcionalidad
parcial.
proporciona
todas las
ventajas del
modelo en
cascada
realimentado,
reduciendo sus
desventajas
slo al mbito
de cada
incremento.
ms rpido en
comparacin
del modelo de
cascada.
Resulta ms
sencillo
acomodar
cambios al
acotar el
tamao de los
incrementos.
Permiten que los
ingenieros de sw
desarrollen
versiones cada
vez ms
completas del
sw. Producen
una versin
completa en
forma
incremental con
cada iteracin
Programacin organizada
menor taza de errores
satisfaccin del
programador
Desventajas Un proyecto
rara vez sigue
una secuencia
lineal, esto crea
Genera mucho
tiempo en el
desarrollo del
sistema Modelo
El modelo
Incremental no
es
recomendable
Para proyectos
grandes,
necesita
suficientes
Es recomendable
emplearlo solo en
proyectos a corto plazo.
Altas comisiones en caso
28

28

una mala
implementacin
del modelo, lo
cual hace que
lo lleve al
fracaso. 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.
costoso Requiere
experiencia en la
identificacin de
riesgos.
para casos de
sistemas de
tiempo real, de
alto nivel de
seguridad, de
procesamiento
distribuido, y/o
de alto ndice
de riesgos.
Requiere de
mucha
planeacin,
tanto
administrativa
como tcnica.
Requiere de
metas claras
para conocer el
estado del
proyecto.
recursos
humanos para
crear el nmero
correcto de
equipos DRA Si
los
desarrolladores y
clientes no se
comprometen
con las
actividades
rpidas
necesarias para
completar un
sistema en un
marco de tiempo
muy breve, los
proyectos
fallarn. Si un
sistema no se
puede modular
en forma
apropiada, la
construccin de
los componentes
necesarios ser
problemtica
Inapropiado
cuando los
riesgos tcnicos
son altos
cuando se
aplican muchas
nuevas
tecnologas
de fallar.
Usos El modelo en
cascada se
despea bien
en proyectos
con requisitos
claros o cuando
se trabaja con
herramientas
tcnicas y es
des
aconsejable
cuando se
necesita un
rpido
desarrollo.
El modelo en
espiral es
beneficioso en
proyectos que
necesitan
reduccin de
riesgos.
El modelo
incremental es
til sobre todo
cuando el
personal
necesario para
una
implementacin
completa no
esta disponible.
El modelo DRA
es utilizado para
ciclos de vida del
software cortos.
Es utilizado para la
creacin y desarrollo
practico de software, es
utilizado mucho
ltimamente ya que es una
metodologa gil para el
desarrollo.
29

29

CONCLUSION

Una metodologa se basa en una combinacin de los modelos de proceso genricos
para obtener como beneficio un software que soluciones un problema
La trascendencia de las metodologas se ha hecho notoria, pasando de solo
programar, establecer funciones en etapas o mdulos, objetos, y por ltimo agilizar
el desarrollo del software y minimizar los costos.
En el desarrollo convencional todo el programa est en un solo bloque, con
ejecucin secuencial de instrucciones
En el desarrollo estructurado los programas estn divididos en distintos bloques,
estos bloques tienen funciones que se van confeccionado en forma de arriba-abajo,
empezando desde las generales hasta las particulares, hasta llegar a detallar cada
uno de los procedimientos y su interaccin.
El desarrollo orientado a objetos comprende dividir un programa en clases, donde
estas clases estarn estructuradas por propiedades, atributos, variables,
pretendiendo simular y describir de manera conceptual a un objeto.
Los mtodos giles fueron pensados especialmente para equipos de desarrollo
pequeos, con plazos reducidos, requisitos voltiles y nuevas tecnologas.
El modelado de negocio describe como desarrollar una visin de la nueva
organizacin, basado en esta visin se definen procesos, roles y responsabilidades
de la organizacin por medio de un Modelo de Casos de Uso del Negocio
Los modelos de procesos permiten al analista de sistemas desarrollar un plan de
requisitos del software, permiten establecer un trabajo en forma ordenada,
adems que existen muchos modelos que se adaptan a las exigencias del proyecto,
solo debemos saber cual nos conviene.

30

30

WEBGRAFIA

http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
http://laboratorios.fi.uba.ar/lsi/cataldi-tesisdemagistereninformatica.pdf
http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_para_el_desarrollo_de_
software
http://www.slideshare.net/guesta1695670/metodologias-de-desarrollo-de-software
https://www.youtube.com/watch?v=gJp7Y3oEmfY
http://noqualityinside.com.ar/nqi/nqifiles/XP_Agil.pdf
http://www.cyta.com.ar/ta0502/v5n2a1.htm

Metodolias Pruebas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodolias Pruebas

Cargado por

Copyright:

Formatos disponibles

Valor Creativo - Autor: Valor Creativo

También podría gustarte