Ciclo de Vida y Metodologias

Ao de la Consolidacin del Mar de
Grau
UNIVERSIDAD NACIONAL SAN

LUIS GONZAGA DE ICA
FACULTAD DE INGENIERA DE SISTEMAS
MODELOS DE CICLO DE VIDA DEL SOFTWARE Y
METODOLOGAS DE DESARROLLO DE SOFTWARE
CURSO
Control de Calidad de Software
DOCENTE
Ing. Alonso Morales

INTEGRANTES
Almora Castro Nellie

Huarcaya Gamboa Luis
Quintanilla Licapa Jhonatan
Salhuana Hernandez Carlos
CICLO
VIII
ICA PERU
2016
AGRADECIMIENTOS
Agradecemos a Dios, ya que gracias a l

tenemos a nuestros padres maravillosos,
los cuales nos apoyan en nuestras derrotas
y celebran nuestros triunfos.
A nuestros profesores quienes son
nuestros guas en el aprendizaje,
dndonos los ltimos conocimientos para
nuestro buen desenvolvimiento en la
sociedad.
CONTROL DE CALIDAD DE SOFTWARE
PAGINA 2
NDICE
INTRODUCCIN...................................................................................................................6
MODELO DE CICLO DE VIDA DE SOFTWARE.........7
1. Ciclo de Vida de Software................................................................................................7
2. Modelos de Ciclo de Vida................................................................................................8
2.1Clasificacion................................................................................................................8
2.1.1. Modelos Descriptivos vs. Modelos Prescriptivos....8
2.1.2. Modelos Tradicionales vs. Modelos Evolutivos.9
3. Modelos de Ciclo de Vida del Software ....10
3.1. Modelo Cascada...............................................10
3.1.1. Descripcin del modelo....10
3.1.2. Ventajas.........................................................................................................11
3.1.3. Desventajas......11
3.2. Modelo Prototipo..12
3.2.1. Ventajas...12
3.2.2. Desventajas...13
3.3. Modelo Espiral.13
3.3.1. Descripcin del modelo..14
3.3.2. Ventajas.14
3.3.3. Desventajas.14
3.4. Modelo en V..15
3.4.1. Ventajas.15
3.4.2. Desventajas.16
3.5. Desarrollo Rpido de Aplicaciones (DRA)..16
3.5.1. Caractersticas...16
3.6. Modelo Incremental.17
3.6.1. Caractersticas...17
3.7. Modelo Big Bang.18
4. Metodologas Para el Desarrollo de Software.19
4.1. Introduccin..19
4.2. Qu es un Mtodo?................................................................................................19
4.3. Qu es una Metodologa?......................................................................................19
4.4. El qu consiste las Metodologas de Desarrollo de Software?...............................19
4.5. Ventajas del uso de Metodologas para el Desarrollo de Software 19
4.5.1. Desde el Punto de Vista de Gestin...20
4.5.2. Desde el Punto de Vista de los Ingenieros de Software20
4.5.3. Desde el Punto de Vista del Cliente o Usuario...20
4.6. Metodologas Estructuradas..20
4.6.1. Metodologa Estructurada Orientada a Procesos.21
4.7. Metodologa Orientada a Datos..21
4.7.1. Jerrquicos.....21
4.7.2. Datos No Jerrquicos21
4.7.2.1. Metodologa Ingeniera de Informacin.......21
PAGINA 3
4.8. Metodologa Orientada a Objetos...22

4.8.1. Elementos del Modelo de Objetos...22
4.9. Metodologa Tradicional.22
4.9.1. Rational Unified Process (RUP)......23
4.9.1.1. Fases...23
4.9.1.2. Ventajas......24
4.9.1.3. Desventajas...24
4.9.2. Microsoft Solution Framework (MSF)...24
4.9.2.1. Fases........24
4.9.2.2. Ventajas...25
4.9.2.3. Desventajas...25
4.10. Metodologa gil.....25
4.10.1. Metodologa XP......28
4.10.1.1. Valores de la Metodologa XP...29
4.10.1.2 Caractersticas que Componen la Metodologa XP..31
4.10.1.3. Equipo de Trabajo Dentro de una Metodologa XP...32
4.10.2. Metodologa SCRUM....33
4.10.2.1. Cmo Funciona los Procesos SCRUM?.....................................34
4.10.2.2. Equipos que Componen los Procesos SCRUM...35
5.0. Conclusiones.37
6.0. Bibliografia.38
PAGINA 4
NDICE DE FIGURAS
Figura 1 Control de Calidad de Software.6
Figura 2 Ciclo de Vida del Software.7
Figura 3 Modelo Descriptivo.8
Figura 4 Modelo Tradicional.9
Figura 5 Modelo Cascada10
Figura 6 Modelo Prototipo..............................12
Figura 7 Modelo Espiral..13
Figura 8 Modelo V..15
Figura 9 Desarrollo Rpido de Aplicaciones....16
Figura 10 Modelo Incremental..17
Figura 11 Modelo Big Bang..18
Figura 12 Modelo Big Bang 2..18
Figura 13 Metodologa Estructurada.20
Figura 14 Metodologa Orientada a Objetos22
Figura 15 RUP.23
Figura 16 Fases del RUP...........................................23
Figura 17 Fases del MSF..24
Figura 18 Metodologa gil25
Figura 19 Metodologa XP..28
Figura 20 Caractersticas de XP30
Figura 21 Metodologa SCRUM33
Figura 22 Equipo SCRUM....35
PAGINA 5
INTRODUCCIN
El trmino ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la
fase final. El propsito de este programa es definir las distintas fases intermedias que se requieren
para validar el desarrollo de la aplicacin, es decir, para garantizar que el software cumpla los
requisitos para la aplicacin y verificacin de los procedimientos de desarrollo: se asegura de que
los mtodos utilizados son apropiados.
Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan
tarde dentro de la fase de implementacin. El ciclo de vida permite que los errores se detecten lo
antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software,
en los plazos de implementacin y en los costos asociados.
Figura 1 - Control de Calidad de Software
PAGINA 6
MODELOS DE CICLO DE VIDA DE SOFTWARE

1. CICLO DE VIDA DE SOFTWARE:
Describe el desarrollo de software desde la fase inicial hasta la fase final, proponiendo etapas
que sirven como referencia para realizar este proceso. Las fases que conforman el ciclo de
vida son:
Preanlisis
Anlisis
Diseo
Desarrollo
Pruebas
Implementacin
Mantenimiento
Figura 2 Ciclo de Vida del Software
PAGINA 7
2. MODELOS DE CICLO DE VIDA

Existen diversos modelos de ciclo de vida, pero cada uno de ellos va asociado a unos
mtodos, herramientas y procedimientos que debemos usar a lo largo de un proyecto.
2.1.
CLASIFICACIN:
2.1.1. MODELOS DESCRIPTIVOS VS. MODELOS PRESCRIPTIVOS
Un modelo de ciclo de vida del software es una caracterizacin descriptiva o
prescriptiva- de la evolucin del software.
Los modelos prescriptivos dictan pautas de cmo deberan desarrollarse los
sistemas de software; por lo tanto, son ms fciles de articular ya que los
detalles del desarrollo pueden ser ignorados, generalizados, etc. Esto puede
dejar dudas acerca de la validez y robustez de este tipo de modelos.
Otra forma de encarar el desarrollo de un modelo es la forma descriptiva, la
cual se basa en la observacin del desarrollo de sistemas reales.
Son ms difciles de articular debido a dos razones fundamentales:
La captura de datos es un proceso que puede tomar aos.
Los modelos descriptivos son especficos a los sistemas observados
y solamente generalizables a travs de anlisis sistemticos.
Figura 3 Modelos Descriptivos
PAGINA 8
2.1.2. MODELOS TRADICIONALES VS. MODELOS EVOLUTIVOS

Los modelos tradicionales focalizan su atencin en la direccin del cambio en
trminos de progreso a travs de una serie de etapas que eventualmente
conducen a alguna etapa final.
Aunque este tipo de modelos son a menudo intuitivos y muy tiles para el
establecimiento de marcos de trabajo, administracin y seleccin de
herramientas para el desarrollo de software, presentan serios problemas:
Fallan para proveer un mecanismo adecuado que permita gobernar
los cambios en el desarrollo del software.
Plantea una organizacin muy poco realista que implica una
secuencia uniforme y ordenada de actividades de desarrollo.
Como una solucin a estos problemas surgieron nuevas propuestas que
pueden agruparse bajo el nombre de modelos evolutivos. Los modelos
evolutivos presentan las siguientes caractersticas:
Existen tres orientaciones centrados en el producto, centrados en los
procesos y centrados en la administracin y organizacin del proceso.
Focalizan la atencin en los mecanismos y procesos que cambian
sistemas.
Estn caracterizados por el diseo, desarrollo y despliegue de una
capacidad inicial usando tecnologa actual que incluye previsin para
la adicin evolutiva de futuras capacidades a medida que se definen
nuevos requerimientos y que las tecnologas maduran.
Figura 4 Modelo Tradicional
PAGINA 9
3.
MODELOS DE CICLO DE VIDA DEL SOFTWARE

3.1.
MODELO CASCADA
El modelo cascada (waterfall), propuesto por Royce en 1970, fue derivado de
modelos de actividades de ingeniera con el fin de establecer algo de orden en el
desarrollo de grandes productos de software. Consiste en diferentes etapas, las
cuales son procesadas en una manera lineal. Comparado con otros modelos de
desarrollo de software es ms rgido y mejor administrable. El modelo cascada es un
modelo muy importante y ha sido la base de muchos otros modelos, sin embargo,
para muchos proyectos modernos, ha quedado un poco desactualizado.
3.1.1. DESCRIPCIN DEL MODELO

El modelo cascada es un modelo de ingeniera diseado para ser aplicado en
el desarrollo de software. La idea principal es la siguiente: existen diferentes
etapas de desarrollo, la salida de la primera etapa fluye hacia la segunda
etapa y esta salida fluye hacia la tercera y as sucesivamente.
Figura 5 Modelo Cascada
PAGINA 10
3.1.2. VENTAJAS
El modelo de cascada es el modelo ms antiguo y ms ampliamente utilizado
en el campo de desarrollo de software. Hay ciertas ventajas del modelo de
cascada, que hace que sea el modelo ms ampliamente utilizado hasta el
momento. Algunos de ellos se pueden enumerar como bajo.
No hace falta mencionar, es un modelo lineal y, por supuesto, los modelos
lineales son las ms simples a ser implementadas.
La cantidad de recursos necesarios para implementar este modelo es
mnimo.
Una gran ventaja del modelo de cascada es que la documentacin se
produce en cada etapa del desarrollo del modelo de cascada. Esto hace
que la comprensin del producto disear procedimiento ms sencillo.
Despus de cada etapa importante de la codificacin de software, las
pruebas se realizan para comprobar el correcto funcionamiento del
cdigo.
3.1.3. DESVENTAJAS
La pregunta que hay que te preocupa ahora es que, con tantas ventajas a la
mano, lo que podra ser las posibles desventajas del modelo de cascada.
Bueno, hay algunas desventajas de este modelo ampliamente aceptado
tambin. Echemos un vistazo a algunos de ellos.
Irnicamente, la mayor desventaja del modelo de cascada es uno de sus
mayores ventajas. No se puede volver atrs, si la fase de diseo ha ido mal,
las cosas pueden ser muy complicado en la fase de ejecucin.
Los Muchas veces, sucede que el cliente no es muy claro de lo que
exactamente quiere del software. Cualquier cambio que se menciona en
el medio puede causar mucha confusin.
Los pequeos cambios o errores que surgen en el software completo
puede causar mucho problema.
La mayor desventaja del modelo de cascada es que hasta la etapa final del
ciclo de desarrollo se ha completado, un modelo de trabajo del software
no est en las manos del cliente. Por lo tanto, es difcil en condiciones de
mencionar si lo que se ha diseado es exactamente lo que haba pedido.
PAGINA 11
3.2.
MODELO PROTOTIPO
Este modelo tambin se ha llamado evolutivo, se fundamenta en el desarrollo de un
producto inicial que se presenta al usuario para obtener su aprobacin y se
perfecciona, a travs de diferentes versiones, hasta obtener el producto adecuado.
Figura 6 - Modelo Prototipo
3.2.1. CARACTERSTICAS
Es un modelo menos formal de desarrollo
Se recomienda para el desarrollo de productos pequeos o de tamao
medio
til cuando se desconocen los requerimientos del producto o son poco
estables
Proporciona rapidez en el proceso de desarrollo
3.2.2. VENTAJAS
No modifica el flujo del ciclo de vida
Reduce el riesgo de construir productos que no satisfagan las necesidades
de los usuarios
Reduce costo y aumenta la probabilidad de xito
Exige disponer de las herramientas adecuadas
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.
PAGINA 12
3.2.3. DESVENTAJAS
Debido a que el usuario ve que el prototipo funciona piensa que este es el
producto terminado y no entienden que recin se va a desarrollar
el software.
El desarrollador puede caer en la tentacin de ampliar el prototipo para
construir el sistema final sin tener en cuenta los compromisos de calidad
y mantenimiento que tiene con el cliente.
3.3.
MODELO ESPIRAL
El problema con los modelos de procesos de software es que no se enfrentan lo
suficiente con la incertidumbre inherente a los procesos de software.
Importantes proyectos de software fallaron porque los riegos del proyecto se
despreciaron y nadie se prepar para algn imprevisto. Boehm reconoci esto y trat
de incorporar el factor riesgo del proyecto al modelo de ciclo de vida,
agregndoselo a las mejores caractersticas de los modelos Cascada y Prototipado. El
resultado fue el Modelo Espiral. La direccin del nuevo modelo fue incorporar los
puntos fuertes y evitar las dificultades de otros modelos desplazando el nfasis de
administracin hacia la evaluacin y resolucin del riesgo. De esta manera se permite
tanto a los desarrolladores como a los clientes detener el proceso cuando se lo
considere conveniente.
Figura 7 - Modelo Espiral
PAGINA 13
3.3.1. DESCRIPCIN DEL MODELO

Bsicamente, la idea es desarrollo incremental usando el modelo Cascada
para cada paso, ayudando a administrar los riesgos. No se define en detalle el
sistema completo al principio; los diseadores deberan definir e implementar
solamente los rasgos de mayor prioridad. Con el conocimiento adquirido,
podran entonces volver atrs y definir e implementar ms caractersticas en
trozos ms pequeos.
El modelo Espiral define cuatro actividades principales en su ciclo de vida:
Planeamiento: Determinacin de los objetivos, alternativas y
limitaciones del proyecto.
Anlisis de riesgo: Anlisis de alternativas e identificacin y solucin
de riesgos.
Ingeniera: Desarrollo y testeo del producto.
Evaluacin del cliente: Tasacin de los resultados de la ingeniera.
3.3.2. VENTAJAS
Evita las dificultades de los modelos existentes a travs de un
acercamiento conducido por el riesgo.
Intenta eliminar errores en las fases tempranas.
Es el mismo modelo para el desarrollo y el mantenimiento.
Provee mecanismos para la aseguracin de la calidad del software.
La reevaluacin despus de cada fase permite cambios en las
percepciones de los usuarios, avances tecnolgicos o perspectivas
financieras.
La focalizacin en los objetivos y limitaciones ayuda a asegurar la calidad.
3.3.3. DESVENTAJAS
Falta un proceso de gua explcito para determinar objetivos, limitaciones
y alternativas.
Provee ms flexibilidad que la conveniente para la mayora de las
Aplicaciones.
La pericia de tasacin del riesgo no es una tarea fcil. El autor declara que
es necesaria mucha experiencia en proyectos de software para realizar
esta tarea exitosamente.
PAGINA 14
3.4.
MODELO EN V
Se considera como una versin mejorada del modelo en cascada y, por tanto,
conserva las caractersticas de secuencialidad y organizacin. El modelo en V
fundamenta su enfoque en la minimizacin de riesgos, la mejora de calidad, la
reduccin total de gastos y el perfeccionamiento de la comunicacin entre los
participantes del proyecto de desarrollo de software. Adems, incorpora procesos de
verificacin y validacin.
Figura 8 - Modelo V
Realmente las etapas individuales del proceso pueden ser casi las mismas que las
del modelo en cascada. Sin embargo, hay una gran diferencia. En vez de ir para
abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la fase de
codificacin, formando una V. La razn de esto es que para cada una de las fases de
diseo se ha encontrado que hay un homlogo en las fases de pruebas que se
correlacionan.
3.4.1. VENTAJAS
Las ventajas que se pueden destacar de este modelo son las siguientes:
Es un modelo simple y fcil de utilizar.
En cada una de las fases hay entregables especficos.
Tiene una alta oportunidad de xito sobre el modelo en cascada
debido al desarrollo de planes de prueba en etapas tempranas del
ciclo de vida.
Es un modelo que suele funcionar bien para proyectos pequeos
donde los requisitos son entendidos fcilmente.
PAGINA 15
3.4.2. DESVENTAJAS
Entre los inconvenientes y las crticas que se le hacen a este modelo estn las
siguientes:
Es un modelo muy rgido, como el modelo en cascada.
Tiene poca flexibilidad y ajustar el alcance es difcil y caro.
El software se desarrolla durante la fase de implementacin, por lo
que no se producen prototipos del software.
3.5.
DESARROLLO RPIDO DE APLICACIONES (DRA)

El modelo DRA es una versin que integra las caractersticas de los modelos cascada
y prototipos, aadiendo velocidad de desarrollo. Propone la divisin del proyecto en
mdulos que son desarrollados por cada equipo de trabajo y luego se integran para
configurar el producto definitivo.
Figura 9 Desarrollo Rpido de Aplicaciones
Ofrece flexibilidad al proceso de desarrollo
Requiere el compromiso de los desarrolladores y los clientes
Los requisitos del producto deben ser comprendidos desde el inicio
PAGINA 16
Aquellos productos de software que se puedan dividir en mdulos, cuyo

tiempo de desarrollo no exceda los tres meses, pueden abordarse con este
modelo.
Resalta el uso de componentes de software existente
3.6.
MODELO INCREMENTAL
Combina elementos del modelo tradicional aplicado en forma iterativa. Este modelo
emplea secuencias lineales escalonadas que proporcionan incrementos del producto.
Figura 10 Modelo Incremental
Requiere de la planeacin del desarrollo del producto de acuerdo con las
prioridades de funcionalidad establecidas por el cliente.
Requiere poco personal para el desarrollo de los incrementos iniciales,
pero se puede vincular nuevo personal si los incrementos as lo exigen.
El primer incremento es un producto que incorpora las funcionalidades
prioritarias completamente funcionales.
La evaluacin del incremento, por parte del cliente, origina un plan para
el desarrollo del incremento siguiente.
Cada incremento integra nuevas funcionalidades al producto
PAGINA 17
3.7.
MODELO BIG BANG
Figura 11 Modelo Big Bang

Este modelo es el modelo con la forma ms simple. Requiere poca planificacin,
mucha programacin y tambin muchos fondos. Este modelo se conceptualiza
alrededor de la teora de creacin del universo 'Big Bang'.
Tal como cuentan los cientficos, despus del Big Bang muchas galaxias, planetas y
estrellas evolucionaron.
De la misma manera, si reunimos muchos fondos y programacin, quiz podemos
conseguir el mejor producto de software.
Para este modelo, se requiere poca planificacin. No sigue ningn proceso concreto,
y a veces el cliente no est seguro de las futuras necesidades y requisitos. Por tanto,
la entrada o input respecto a los requisitos es arbitraria.
Este modelo no es recomendable para grandes proyectos de software, pero es bueno
para aprender y experimentar.
Figura 12 Modelo Big Bang 2
PAGINA 18
4. METODOLOGAS PARA EL DESARROLLO DE SOFTWARE

4.1.
INTRODUCCIN
El desarrollo de software, es uno de los sectores tecnolgicos ms competitivos y no
es algo nuevo, ya que durante muchos aos lo ha sido, sin embargo ha tenido una
evolucin constante en lo que se refiere a las metodologas o bien, las formas en las
cuales se realiza la planeacin para el diseo del software, bsicamente con el
objetivo de mejorar, optimizar procesos y ofrecer una mejor calidad.
Sin embargo, antes de hablar acerca de metodologas y todo este tema tan amplio,
analicemos a detalle brevemente Qu es un mtodo? y para que lo acompaemos
tambin veamos qu es una metodologa? Seguramente los trminos te suenan
familiar, sin embargo el saber que significan de forma correcta es indispensable.
4.2.
QU ES UN MTODO?
Un Mtodo se compone de diversos aspectos que nos permitirn conseguir una meta
o lograr un objetivo. Se define ms claramente como un conjunto de herramientas,
las cuales utilizadas mediante las tcnicas correctas, permiten la ejecucin de
procesos que nos llevarn a cumplir los objetivos que buscamos. En pocas palabras
es un conjunto de herramientas, tcnicas y procesos que facilitan la obtencin de un
objetivo.
4.3.
QU ES UNA METODOLOGA?
En el desarrollo de software, una metodologa hace cierto nfasis al entorno en el
cul se plantea y estructura el desarrollo de un sistema. Existen una gran cantidad de
metodologas de la programacin que se han utilizado desde los tiempos atrs y que
con el paso del tiempo han ido evolucionando. Esto se debe principalmente a que no
todos los sistemas de la informacin, son compatibles con todas las metodologas,
pues el ciclo de vida del software puede ser variable. Por esta razn, es importante
que dependiendo del tipo de software que se vaya a desarrollar, se identifique
la metodologa para el diseo de software idnea.
4.4.
EN QU CONSISTE LAS METODOLOGAS DE DESARROLLO DE

SOFTWARE?
Una Metodologa de desarrollo de software, consiste principalmente en hacer uso de
diversas herramientas, tcnicas, mtodos y modelos para el desarrollo.
Regularmente este tipo de metodologa, tienen la necesidad de venir documentadas,
para que los programadores que estarn dentro de la planeacin del proyecto,
comprendan perfectamente la metodologa y en algunos casos el ciclo de vida del
software que se pretende seguir. Aunque actualmente existen mucha variedad
en metodologas de programacin. La realidad es que todas estn basadas en ciertos
enfoques generalistas que se crearon hace muchos aos.
PAGINA 19
4.5.
VENTAJAS DEL USO DE METODOLOGAS PARA EL DESARROLLO DE

SOFTWARE:
4.5.1. DESDE EL PUNTO DE VISTA DE GESTIN:
Facilitar la tarea de planificacin

Facilitar la tarea del control y seguimiento de un proyecto
Mejorar la relacin coste/beneficio
Optimizar el uso de recursos disponibles
Facilitar la evaluacin de resultados y cumplimiento de los objetivos
Facilitar la comunicacin efectiva entre usuarios y desarrolladores
4.5.2. DESDE EL PUNTO DE VISTA DE LOS INGENIEROS DEL SOFTWARE:
Ayudar a la comprensin del problema

Optimizar el conjunto y cada una de las fases del proceso de desarrollo
Facilitar el mantenimiento del producto final
Permitir la reutilizacin de partes del producto
4.5.3. DESDE EL PUNTO DE VISTA DEL CLIENTE O USUARIO:

Garanta de un determinado nivel de calidad en el producto final
Confianza en los plazos de tiempo fijados en el proyecto
Definir el ciclo de vida que ms se adecue a las condiciones y
Caractersticas de desarrollo
4.6.
METODOLOGA ESTRUCTURADA:
Estas metodologas proponen modelos del sistema que representen los procesos, los
flujos y las estructuras de datos de una forma descendente Top-Down.
Estas metodologas se basan en el modelo bsico entrada/proceso/salida, es decir los
datos entran al sistema y ste los transforma para dar lugar a las salidas, que se
clasifican en:
Figura 13 - Metodologa estructurada

PAGINA 20
4.6.1. METODOLOGA ESTRUCTURADA ORIENTADA A PROCESOS:

Partiendo del modelo bsico entrada/proceso/salida, estas metodologas se
centran en la parte del proceso. Estas metodologas utilizan el mtodo
descendente de descomposicin funcional para definir los requisitos del
sistema empleando en su descripcin un conjunto de tcnicas grficas que
dan lugar al concepto de especificacin estructurada.
Una especificacin estructurada es un modelo grfico particionado,
descendente y jerrquico de los procesos del sistema y de los datos utilizados
por los procesos. Ejemplos de esta metodologa son:
Diagrama de flujo de datos
Diccionario de datos
Especificaciones
4.7.
METODOLOGA ORIENTADA A DATOS

Se clasifican en dos Jerrquico y no Jerrquico
4.7.1. JERRQUICOS
La estructura de control del programa debe ser jerrquica y se debe
derivar de la estructura de datos del programa
El proceso de diseo consiste en definir primero las estructuras de los
datos de entrada y salida, mezclarlas todas en una estructura jerrquica
de programa y despus ordenar detalladamente la lgica procedimental
para que se ajuste a esta estructura.
El diseo lgico debe preceder y estar separado del diseo fsico
4.7.2. DATOS NO JERRQUICOS

Ejemplo de no jerrquicos:
4.7.2.1. METODOLOGA INGENIERA DE LA INFORMACIN

FASES:
Planificacin: Construir una arquitectura de la Informacin y una
estrategia que soporte los objetivos de la organizacin
Anlisis: Comprender las reas del negocio y determinar los
requisitos del sistema
Diseo: Establecer el comportamiento del sistema deseado por el
usuario y que sea alcanzable por la tecnologa
Construccin: Construir sistemas que cumplan los tres niveles
anteriores
PAGINA 21
4.8.
METODOLOGA ORIENTADA A OBJETOS

La metodologa orientada a objetos ha derivado de las metodologas anteriores a
ste. As como los mtodos de diseo estructurado realizados guan a los
desarrolladores que tratan de construir sistemas complejos utilizando algoritmos
como sus bloques fundamentales de construccin, similarmente los mtodos de
diseo orientado a objetos han evolucionado para ayudar a los desarrolladores a
explotar el poder de los lenguajes de programacin basados en objetos y orientados
a objetos, utilizando las clases y objetos como bloques de construccin bsicos.
Figura 14 - Metodologa Orientada a Objetos
4.8.1. ELEMENTOS DEL MODELO DE OBJETOS

Hay 4 elementos bsicos que constituyen dicho modelo:
4.9.
Abstraccin.
Encapsulamiento.
Modularidad.
Jerarqua.
METODOLOGA TRADICIONAL:
Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad
de mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que
importarse la concepcin y fundamentos de metodologas existentes en otras reas
y adaptarlas al desarrollo de software. Esta nueva etapa de adaptacin contena el
desarrollo dividido en etapas de manera secuencial que de algo mejoraba la
necesidad latente en el campo del software. Entre las principales metodologas
tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su
atencin en llevar una documentacin exhaustiva de todo el proyecto y centran su
atencin en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del
desarrollo del proyecto.
PAGINA 22
4.9.1. RATIONAL UNIFIED PROCESS (RUP):

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar
tareas y responsabilidades dentro de una organizacin de desarrollo. Su
objetivo es asegurar la produccin de software de alta calidad que satisfaga
los requerimientos de los usuarios finales (respetando cronograma y
presupuesto). Fue desarrollado por Rational Software, y est integrado con
toda la suite Rational de herramientas. Puede ser adaptado y extendido para
satisfacer las necesidades de la organizacin que lo adopte. Es guiado por
casos de uso y centrado en la arquitectura, y utiliza UML como lenguaje de
notacin.
Figura 15 - RUP
4.9.1.1. FASES
Las cuatro fases del ciclo de vida de RUP son:
Inicio
Elaboracin
Construccin
Transicin
Figura 16 - Fases de RUP
PAGINA 23
4.9.1.2. VENTAJAS
Evaluacin en cada fase que permite cambios de objetivos
Funciona bien en proyectos de innovacin.
Es sencillo, ya que sigue los pasos intuitivos necesarios a la
hora de desarrollar el software.
Seguimiento detallado en cada una de las fases.
4.9.1.3. DESVENTAJAS
La evaluacin de riesgos es compleja
Excesiva flexibilidad para algunos proyectos
Estamos poniendo a nuestro cliente en una situacin que
puede ser muy incmoda para l
Nuestro cliente deber ser capaz de describir y entender a un
gran nivel de detalle para poder acordar un alcance del
proyecto con l
4.9.2. MICROSOFT SOLUTION FRAMEWORK (MSF)

MSF es un compendio de las mejores prcticas en cuanto a administracin de
proyectos se refiere. Ms que una metodologa rgida de administracin de
proyectos, MSF es una serie de modelos que puede adaptarse a cualquier
proyecto de tecnologa de informacin.
4.9.2.1. FASES
Visin y Alcances
Planificacin
Desarrollo
Estabilizacin
Implantacin
Figura 17 - Fases del MSF
PAGINA 24
4.9.2.2. VENTAJAS
Crea una disciplina de anlisis de riesgos que ayuda y
evoluciona con el proyecto
Vinculacin con el cliente como tambin orientado al trabajo
en equipo
Tiene facilidad de soporte y mantenimiento
Es adaptable, se puede utilizar para proyectos de cualquier
magnitud
El modelo tiene facilidad de manejo por ser de una empresa
conocida
Aplica mucho e incentiva al trabajo en equipo y a la
colaboracin
4.9.2.3. DESVENTAJAS
Al estar basado en tecnologa Microsoft, trata de obligar a usar
sus propias herramientas
Solicita demasiada documentacin en sus fases
Si el anlisis de riesgos se hace muy exhaustivo puede retardar
el proyecto
Los precios de licencias, capacitacin y soporte de Microsoft
son caros
Alto grado de dependencias de tecnologas propietarias
4.10. METODOLOGA GIL

Con el paso del tiempo, estaba claro que las metodologas tradicionales,
simplemente no se iban a acoplar con las nuevas tecnologas, los nuevos lenguajes y
sobretodo los programadores modernos. Es por eso que desde principios del Siglo,
se han desarrollado lo que son las metodologas giles. Una metodologa gil,
consiste principalmente en trabajar con menos documentacin de la que, como
vimos, las metodologas tradicionales utilizan en todo momento.
Figura 18 - Metodologa gil
PAGINA 25
Existen una gran cantidad de metodologas giles de desarrollo de software y todas

las vamos a ver a continuacin. Sin embargo antes hay que comprender en que
consiste detenidamente la metodologa gil, para lo cual contamos con el manifiesto
gil. Un documento en el cul se resume la filosofa de este enfoque de desarrollo,
as seguramente despus de leer esos puntos, nos quedar an ms clara la idea de
hacia donde se pretende llegar y principalmente Cmo se pretende llegar a los
objetivos, cuyos principios son:
Al Individuo y las Interacciones del Equipo. Una de las cosas que sabemos
muy bien, es que las personas son quienes consiguen los xitos dentro de
un proyecto de software. Sin embargo tambin est claro que si el equipo
de trabajo falla, entonces todo se viene abajo y el enfoque que haba de
xito se convierte en incertidumbre. A diferencia de si el equipo funciona
perfectamente, se tienen ms cerca los objetivos, aun cuando no exista
una lista de procesos establecida como se haca con las metodologas de
antao.
Con este primer valor del desarrollo gil, se pretender hacer ver, que en
realidad no importa que el equipo de trabajo no sean las personas ms
brillantes del sector. Con que sean personas que saben hacer bien el
trabajo que se les asignar es ms que suficiente. En este caso, las
herramientas aunque son importantes para incrementar el rendimiento,
tambin es cierto que si hay herramientas de ms y que no sirven de nada
en un principio, lo mejor es dejarlas de lado o estas nos quitarn valioso
tiempo que no tendremos.
Software funcional en lugar de demasiada documentacin. Crear
documentacin, es una de las actividades que con las metodologas
tradicionales, absorban una gran cantidad de tiempo. Si nos acercamos a
analizaras las metodologas de antao, descubriremos que en cada una de
ellas, realizar la documentacin era una parte vital. Sin embargo en las
metodologas giles, esto ha cambiado, pues existe una regla que dice de
la siguiente forma: No producir documentacin, al menos que sean
sumamente necesarios al momento para tomar una decisin. Por lo que
adems se extienda hacia el enfoque de que la documentacin debe ser
corta y breve, nada sumamente extenso que requiera de una gran
cantidad de tiempo de lectura.
Te preguntars y entonces, cuando un nuevo programador o desarrollador
sea colocado en un puesto dentro del proyecto, como sabr hacia donde
ir y el enfoque que se est llevando a cabo. Para lo cual el manifiesto gil
nos dice que, existen dos elementos fundamentales para que un nuevo
miembro del equipo se ponga al da. El primero es el cdigo fuente, pues
suponiendo que es una persona conocedora, sabr hacia dnde va el
curso del proyecto con tan solo leer el cdigo. La segunda es que la
PAGINA 26
interaccin con el equipo de trabajo, ser el complemento ideal para que

se acople al proyecto. De este modo nos olvidamos de la extensa
documentacin para un software que al final del da debe estar
totalmente funcional.
Colaboracin con el Cliente en lugar de hacer Contrato. Una de las cosas
importantes dentro de las metodologas giles. Es que cambia el modo en
que se trabajaba con el cliente anteriormente. Y es que en las
metodologas de antao, el trabajo consista en tener una reunin previa
con el cliente para analizar los requerimientos del sistema, aqu se
analizaban las limitaciones del proyecto y se establecan los costos. Lo que
generaba cierta barrera de bloqueo entre las posibilidades de desarrollar
algo funcional para otras cosas o solo para el objetivo establecido en la
reunin. Esto al final poda ser desastroso y dificultar la llegada al xito por
parte del proyecto.
Sin embargo, ahora en el manifiesto gil, se propone que exista una
interaccin constante entre el cliente y el equipo de desarrolladores. La
idea es que el cliente vaya viendo cmo va el sistema y analice nuevas
funcionalidades u objetivos, ya que estos no tienen por qu plantearse
desde el principio, si el desarrollo nos puede llevar a una infinidad de
posibilidades. De esta forma el cliente al final queda totalmente satisfecho
con el producto final y habremos llegado al xito trabajando todos en
equipo de forma simultnea.
Posibilidad de Hacer cambios de planes a medio proyecto. Suena ms o
menos a lo que vimos en el punto anterior, pues bsicamente la idea es
evitar lo que es la planeacin extensa y empezar a crear cdigo que
permita expansin. Recordemos que con las metodologas tradicionales,
se acostumbraba a enlistar los requisitos del sistema y el desarrollo iba
enfocado solamente a eso, lo cual ya no permita que a medio desarrollo
hubiera cambios, pues era un cdigo poco moldeable y si se requeran
nuevas cosas, en algunas metodologas lo idea era volver a empezar.
La idea en las metodologas giles, es que durante el desarrollo del
software, si el cliente tiene la idea de incrementar sus objetivos,
especificaciones o requerimientos, lo pueda hacer sin ningn problema.
Pues bsicamente el sistema debe ser flexible para todo lo que pueda
surgir en el proceso. De esta forma, no solamente llegaremos al xito, si
no que el cliente quedar totalmente satisfecho con el trabajo
desarrollado, pues no tuvo que conformarse con lo primero que se le vino
a la mente, si no que se actualiz con las ideas que en la marcha fueron
surgiendo.
PAGINA 27
4.10.1.
METODOLOGA XP
Si hablamos de metodologas de la programacin sin mencionar a la
metodologa XP, es como no hablar de nada en absoluto. Esta
metodologa es posiblemente la ms destacada de las metodologas
giles y esto se debe a su gran capacidad de adaptacin ante cualquier
tipo de imprevisto que surja. Pues la idea no es mantener ciertos
requisitos desde que se est elaborando el proyecto, sino que durante
el proceso, estos vayan cambiando o vayan evolucionando
gradualmente sin complicaciones. Bsicamente los creadores de esta
metodologa XP, consideran que es mejor adaptarte en el proceso a
los requisitos que vayan apareciendo, que iniciar con requisitos y
desarrollar un proyecto en base a eso.
Si queremos ver la metodologa con otra perspectiva, se podra decir
que la metodologa XP o metodologa de programacin extrema,
como tambin se le conoce. Es la combinacin de las dems
metodologas, solamente que se van utilizando de acuerdo a como sea
necesario, por eso es considerada como la ms destacada de las
metodologas giles. As que es momento de entrar en detalles y
vamos a ver cules son los valores que conforman a la metodologa de
programacin XP.
Figura 19 - Metodologa XP
PAGINA 28
4.10.1.1. VALORES DE LA METODOLOGA XP

Como toda metodologa, la programacin extrema cuenta con
algunos valores que son fundamentales para que se lleve a cabo
como debe ser. En algunas otras metodologas estos puntos los
conocamos como principios bsicos, es realmente lo mismo solo
que ac los mencionan como valores, veamos cuales son:
Comunicacin. Del mismo modo que otras metodologas como
la Scrum, el cliente tiene una gran intervencin, pero
obviamente la comunicacin depender de ms factores. Por
ejemplo. El cdigo fuente de los programadores debe
transmitir esa comunicacin a todo el equipo, por eso las
variables amigables. De igual forma, se deben documentar las
cosas ms relevantes, independientemente de que sean
comentadas en el cdigo, pero es importante tener un
documento extra para explicaciones extensas, de lo contrario
el cdigo se ver infestado de escrito. En cuando a la
comunicacin entre personas, los programadores se
comunican constantemente ya que trabajan en parejas, la
comunicacin que se tiene con el cliente debe ser constante,
pues recordemos que incluso el forma parte del equipo de
trabajo y es responsabilidad del cliente, comunicarnos algunas
actualizaciones que requiera en el proceso, nuevas ideas,
soluciones a problemas o sencillamente algn problema que el
vea. Todo debe ser comunicado, esta parte es realmente
fundamental para el desarrollo de un producto exitoso.
Simplicidad. El primero de los valores de la metodologa de
programacin XP, es la simplicidad. Ya te haz de imaginar en
que consiste, puesto que la idea es que el desarrollo sea veloz,
por lo cual todas las cuestiones de diseo se simplifican al
mximo, lo mismo sucede con las lneas de cdigo, si se pueden
simplificar, se hacen, adems de que regularmente el mismo
cdigo es donde va la documentacin comentada, de esta
forma nos evitamos el estar haciendo documentacin extra.
Retroalimentacin. El hecho de que el cliente se encuentre
involucrado en el proyecto, ayudar inicialmente con la
retroalimentacin. Pues conforme pasan los das y se va
analizando el cdigo por pequeas etapas, el cliente puede ir
corrigiendo, agregando, quitando o excluyendo algunas cosas,
esa es la ventaja de la programacin por periodos cortos de
tiempo, es decir, imagina que llevas varios meses desarrollando
el proyecto y cuando vas con el cliente, el proyecto no le gusta
y desea hacer tantos cambios que te llevar una eternidad.
PAGINA 29
Precisamente eso es lo que se trata de evitar con la

metodologa XP.
Valenta. Hay elementos donde el coraje o la valenta de los
programadores sern fundamental. Por ejemplo el dar solucin
a los problemas frente a los cuales se enfrente. El pasar por la
eliminacin de cdigo fuente en el programa desarrollado, aun
cuando todo ese cdigo haya tomado una gran cantidad de
tiempo en hacerse o que tal el hecho de disear para hoy y no
para maana. Muchos lo hacen con esa idea en ocasiones, pero
con un poco de valenta y coraje que forman parte de los
valores de la metodologa, seguramente el xito llegar de
manera anticipada.
Respeto. Originalmente, este quinto valor no se encontraba en
la metodologa XP, sin embargo es importante mencionarlo
pues hoy en da ya lo conforma. El respeto es importante para
que haya una buena comunin entre los programadores del
equipo. Nunca hay que denigrar a nadie ni agregar u ofender,
pues una autoestima alta en el equipo garantizar un trabajo
mucho ms eficiente. Por esta razn, cosas como el cdigo
fuente, las modificaciones, los fallos obtenidos, los problemas
o la solucin de problemas, son procesos que se deben
respetar para que el ambiente de trabajo tambin sea ptimo.
4.10.1.2. CARACTERSTICAS QUE COMPONEN LA METODOLOGA

XP
Figura 20 - Caractersticas de XP
PAGINA 30
Tipo de Desarrollo Iterativo e incremental. Como hemos visto

en lo que llevamos hablando de la metodologa XP, el mtodo
est basado en lo que son las mejoras continuas, a base de
iteraciones y por supuesto un desarrollo incremental al estilo
espiral.
Pruebas Unitarias. Una de las caractersticas adems son las
pruebas unitarias. Se utiliza software de codificacin eso s,
dependiendo del lenguaje que estemos usando es la
herramienta que nos corresponde, pero de este modo se
analiza el cdigo y solucionan errores, antes de validarlo y darlo
por bueno.
Trabajo en Equipo. Ms especfico todava, es el trabajo en
parejas, el objetivo es que el enfoque en parejas sea mayor, las
distracciones son menores y el aprendizaje del uno con el otro
permite que el avance del proyecto sea mucho ms eficiente
que cuando una persona es la encargada.
Alguien del equipo trabaja con el cliente. Es fundamental que
el cliente intervenga en el desarrollo, pero obviamente el no
estar en la sala de desarrollo, se debe asignar a una persona
que sea le encargada de tener las reuniones con el cliente de
forma constante. El ser quien comunique al equipo los
cambios o el seguimiento del proyecto.
Correccin de Errores. Algo importante, el hecho de que la
metodologa XP sea realmente rpida para el desarrollo, no
significa que se pasen por alto los errores, de hecho, primero
se le tiene que dar correccin a los errores antes de seguir
avanzando en el proyecto.
Reestructuracin del Cdigo. La idea es clara una
refacturacin del cdigo siempre se debe realizar. Con esto lo
que haremos es simplificar el cdigo, pero no las funciones.
Pues regularmente cuando desarrollamos, agregamos algunas
cosas que pueden ser innecesarias y que no afectan en el
funcionamiento del sistema, estas son precisamente las que
hay que refacturar.
El Cdigo es de todos. Realmente, aunque se trabaje en
equipos, al final todos tendrn la posibilidad de ver el cdigo,
proponer cambios o incluso hacerlos. La idea es que, si uno no
detecta un error, otro lo podr hacer, por eso el cdigo fuente
es compartido entre todos.
PAGINA 31
Cdigo simple es la clave. Algo importante con la metodologa

extrema, es que la simplicidad siempre llevar la ventaja.
Principalmente porque cuando se requiera hacer un cambio, si
el cdigo fuente es muy complejo, posiblemente lleve muchas
horas realizar los cambios e incluso una alternativa seria ya no
hacer ningn cambio para no perder tiempo. Esta es
precisamente la razn por la cual el cdigo simple, es
fundamental en la metodologa.
4.10.1.3. EQUIPO DE TRABAJO DENTRO DE UNA METODOLOGA

XP
Ya para concluir con esta metodologa, recordemos que es una de
las mejores que podran existir y que realmente vale la pena
implementar. Veamos cuales son los roles que componen el
equipo de trabajo en un proyecto que se elaborar mediante la
metodologa XP, para que tengas una idea de la formacin que se
debe efectuar.
Programador. Realmente no creo que sea necesario que te
diga lo que hace el programador. Bueno, es el encargado del
cdigo del sistema y adems de hacer las pruebas unitarias que
se solicitan.
Tester. Bsicamente es el encargado de las pruebas del
desarrollo. Lo que se vaya implementando, el teste lo prueba y
le dice al cliente o mejor dicho, le comunica al cliente las
pruebas funcionales, para posteriormente comunicarle al
equipo los resultados.
Tracker. El seguimiento ser lo suyo. Ser el encargado de
realizar las comparaciones entre los tiempos estimados antes
de empezar un desarrollo y los tiempos reales que se
obtuvieron. Tratando siempre de mantener al tanto al equipo
para que traten de mejorar los tiempos.
Entrenador. Este elemento es realmente importante, puesto
que es el responsable del proyecto bsicamente y
precisamente hace las funciones de un entrenador. Se encarga
de guiar al equipo por el camino que deben seguir.
Consultor. Regularmente el consultor no formaba parte del
equipo, bueno de hecho no lo integra. El consultor sigue siendo
un externo, pero que cuenta con conocimientos especficos y
que ser capaz de ayudar en la solucin de problemas.
Gestor. Posiblemente el lder ms alto. Si se trata de unir a los
clientes con los programadores, el gestor es el intermedio, es
decir. Es el encargado de vincular e interrelacionar al cliente
con los programadores.
PAGINA 32
4.10.2.
METODOLOGA SCRUM
Figura 21 - Metodologa SCRUM
Para que tengas una idea rpida, para que un proyecto ingrese al marco de
lo que es el modelo Scrum, debe contar con las siguientes caractersticas:
Desarrollo Incremental. Una metodologa gil sin desarrollo incremental, no
puede ser considerada Scrum. Con incremental hago nfasis a olvidarnos de
la planeacin y de la ejecucin de las lneas sin salirnos de lo pre establecido,
pues con una metodologa Scrum, el desarrollo se ir incrementando poco a
poco, sin importar el orden en el cual se lleven a cabo los procesos.
Calidad de las personas. Bsicamente la calidad de un producto, no ser
analizada en base a la calidad de cada uno de los procesos llevados a cabo. Al
contrario, la calidad depender de las personas, la auto organizacin y el
conocimiento de los equipos de trabajo.
Adis al Secuencial y Cascada. Aqu en el modelo Scrum, hay algo a lo que se
le denomina, solapamiento. Esto consiste en que no importa en qu proceso
te encuentres, si un proceso necesita ser trabajado, vuelves a l para realizar
lo que tienes que hacer, a diferencia de las metodologas cascada o
secuencial, donde no haba vuelta atrs. Ac afortunadamente no hay ningn
problema con eso y la ventaja es que se ahorran tiempos.
La comunicacin es Fundamental. Una de las cosas que se realizan, son los
equipos de trabajo, sin embargo ac la ventaja que tendrs es que podrs
estar en constante comunicacin con los otros equipos de trabajo, nadie est
envuelto en su propia burbuja y toda la informacin que se maneje o lleve a
cabo, ser comunicada sin problema.
PAGINA 33
4.10.2.1. CMO FUNCIONAN LOS PROCESOS SCRUM?
La metodologa Scrum, es bastante amigable y fomenta lo que es

el trabajo en equipo en todo momento, con la finalidad de
conseguir los objetivos de una forma rpida. Veamos ahora cuales
son los procesos con los cuales funciona la metodologa,
empezando por el Product Backlog, el cual nos permitir llegar a
los Sprint.
Product Backlog. El Product Backlog no es ms que una lista de las
funcionalidades del producto a desarrollar. Este debe ser
elaborado por el Product Owner, puesto que ms adelante les
explicar. Sin embargo no se trata de una lista cualquiera hecha
con escritos y nada ms. El Product Backlog debe estar ordenado
de acuerdo a las prioridades del sistema de ms a menos, con la
idea de que las cosas con mayor prioridad sean las que se realicen
antes de cualquier cosa. De forma concreta, digamos que el
objetivo base del Product Owner, es que nos d respuesta a la
pregunta Qu hay que hacer?.
Sprint Backlog. Una vez que ya contamos con el Product Backlog
terminado, entonces aparecer el primer Sprint Backlog. Pero
Qu es el Sprint Backlog? Consiste bsicamente en seleccionar
algunos de los puntos escritos en el Product Backlog, los cuales
procedern a ser realizados. Sin embargo en este punto el Sprint
Backlog tiene como requisito marcar el tiempo en que se llevar a
cabo el Sprint.
Sprint Planning Meeting. Antes de iniciar un Sprint, el cual es la
fase de desarrollo, se realiza lo que es un Sprint Planning Meeting.
En este proceso del Scrum, es una reunin que se realiza para
definir plazos y procesos a efectuarse para el proyecto establecido
en el Product Backlog. Algo importante que debes saber, es que
cada Sprint, se compone de diversos features, que no son otra cosa
ms que procesos o subprocesos que se deben realizar, puede ser
la creacin de un logo, la gestin de contenido, el diseo visual,
etc. Todo depender del proceso que se desee llevar a cabo.
Daily Scrum o Stand-up Meeting. Cuando un Sprint est en
proceso, despus de haber hecho la planeacin del proyecto
mediante plazos y procesos, entonces entramos a lo que son los
Daily Scrum o Stand-up Meeting. Aqu bsicamente lo que se hace
son reuniones diarias mientras se est llevando a cabo un Sprint,
para responder las siguientes preguntas: Que hice ayer?, Qu
voy a hacer hoy, Qu ayuda necesito? Aqu entra en funcin el
Scrum Master, un puesto que igual ms adelante les explicar.
Pero el ser el encargado de determinar la solucin de los
problemas y cada complicacin que suceda.
Sprint Review. El Sprint Review, es bsicamente una resea de lo
que fue el Sprint. Consiste especficamente en la revisin del Sprint
terminado y para este punto ya tendra que haber algo que
PAGINA 34
mostrarle al cliente, algo realmente visual o tangible para que se

pueda analizar un cierto avance.
Sprint Retrospective. Para concluir, el Sprint Retrospective,
permite al equipo analizar los objetivos cumplidos, si se
cometieron errores, visualizarlos y tratar de no cometerlos
nuevamente ms adelante. Bsicamente tambin sirve este
proceso para lo que son la implementacin de mejoras.
4.10.2.2. EQUIPOS QUE COMPONEN LOS PROCESOS SCRUM

Durante el punto anterior, te describ los procesos que se llevan a
cabo en la Scrum Metodologa, y en varios puntos mencion
ciertos equipos que son encargados de algunos aspectos
importantes. Por eso a continuacin veremos cules son los
equipos que conforman la metodologa Scrum y con los cuales se
trabajar arduamente, obvio, cada quien con sus respectivas
responsabilidades.
Figura 22 - Equipo SCRUM

Product Owner. Si se trata de tener un lder de proyecto, entonces
el Product Owner lo ser. Bsicamente son los ojos del cliente, ser
la persona encargada del proyecto y de visorear que se lleve a cabo
de tal forma que cumpla las expectativas de lo que se espera.
Scrum Master. Ahora bien, para cada reunin realizada, siempre
debe estar un lder, en este caso el Scrum Master ser el lder de
cada una de las reuniones y ayudar en los problemas que hayan
surgido. Ser bsicamente como un facilitador el cual minimizar
PAGINA 35
obstculos, sin embargo, no los omitir. En realidad, el Scrum

Master debe ser una persona empapada de conocimientos sobre
el lenguaje o lenguajes bajo los cuales se llevar a cabo el proyecto,
de lo contrario no tendra como ayudar a solucionar problemas.
Scrum Team. Bsicamente es el ncleo de la metodologa Scrum,
pues es el equipo de desarrollo, encargado de lo que es la
codificacin del software y de cumplir los objetivos o metas
propuestas por el Product Owner.
Cliente. Aunque no lo creas, el cliente tambin forma parte del
equipo, hablamos de eso hace un rato, cuando coment que no es
como en las metodologas tradicionales donde al cliente se le
pedan requerimientos y se le daba un costo total. En la
metodologa Scrum, el cliente tiene la capacidad para influir en el
proceso, debido a que siempre estar empapado de l, ya sea que
proponga nuevas ideas o bien haciendo algn tipo de comentario.
PAGINA 36
CONCLUSIONES
Las metodologas de desarrollo de Software se basan en diversas pruebas, y cada una tiene proceso
divididos en fases. Cada una de estas estn diseadas para cumplir una necesidad especfica, 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, lo ideal sera
utilizar alguna metodologa ms explcita como la RUP.
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 desarrollo del software y la programacin es uno de los pilares fundamentales de la informtica
y al cual se dedican muchas horas de esfuerzos en empresas, colegios, academias y universidades.
Conforme a la tecnologa va avanzando, van apareciendo nuevas soluciones, nuevas formas de
programacin, nuevos lenguajes y un sinfn de herramientas que intentan realizar que el trabajo del
desarrollador sea un poco ms fcil.
La programacin orientada a objetos o los compiladores basados en mquinas virtuales
(mayormente multiplataforma), tambin a sus puestos unas renovacin en la manera de programar.
Microsoft como empresa desarrolladora de software, es consciente de lo importante que es hacer
buenos desarrollos y lo complicado que es; por eso, intenta aportar las mejores soluciones
al mercado. En la actualidad la sociedad se encuentra en una poca de transicin, que se encamina
hacia un nuevo estilo de programacin basada en estndares y para ello Microsoft propone la
plataforma .NET.
PAGINA 37
BIBLIOGRAFA
Mtodos
de
Desarrollo
de
Software.
Universidad
de
los
http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdf
Andes:
Metodologas de Desarrollo de Software. Instituto Tecnolgico Superior de Apatzingn:

http://www.monografias.com/trabajos-pdf4/metodologias-de-desarrollo-software/metodologiasde-desarrollo-software.pdf
Implementacin del Modelo Integral Colaborativo como Fuente de Innovacin para el Desarrollo
gil de Software en las Empresas de la Zona Centro. Jos Luis Cendejas Valdz:
http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm
Ingeniera
del
Software.
Metodologas
del
Desarrollo
del
Software.
http://www.eici.ucm.cl/Academicos/R_Villarroel/descargas/ing_sw_1/Metodologias.pdf
Desarrollo
del
Software.
Metodologas
ms
conocidas.
http://www.monografias.com/trabajos39/desarrollo-del-software/desarrollo-del-software2.shtml
PAGINA 38

Ciclo de Vida y Metodologias

Cargado por

Información del documento

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

Ciclo de Vida y Metodologias

Cargado por

Copyright:

Formatos disponibles

Ao de la Consolidacin del Mar de

UNIVERSIDAD NACIONAL SAN

Ing. Alonso Morales

Almora Castro Nellie

Agradecemos a Dios, ya que gracias a l

CONTROL DE CALIDAD DE SOFTWARE

CONTROL DE CALIDAD DE SOFTWARE

4.8. Metodologa Orientada a Objetos...22

CONTROL DE CALIDAD DE SOFTWARE

CONTROL DE CALIDAD DE SOFTWARE

Figura 1 - Control de Calidad de Software

CONTROL DE CALIDAD DE SOFTWARE

MODELOS DE CICLO DE VIDA DE SOFTWARE

Figura 2 Ciclo de Vida del Software

CONTROL DE CALIDAD DE SOFTWARE

2. MODELOS DE CICLO DE VIDA

Figura 3 Modelos Descriptivos

CONTROL DE CALIDAD DE SOFTWARE

2.1.2. MODELOS TRADICIONALES VS. MODELOS EVOLUTIVOS

Figura 4 Modelo Tradicional

CONTROL DE CALIDAD DE SOFTWARE

MODELOS DE CICLO DE VIDA DEL SOFTWARE

3.1.1. DESCRIPCIN DEL MODELO

Figura 5 Modelo Cascada

CONTROL DE CALIDAD DE SOFTWARE

CONTROL DE CALIDAD DE SOFTWARE

Figura 6 - Modelo Prototipo

CONTROL DE CALIDAD DE SOFTWARE

Figura 7 - Modelo Espiral

CONTROL DE CALIDAD DE SOFTWARE

3.3.1. DESCRIPCIN DEL MODELO

CONTROL DE CALIDAD DE SOFTWARE

CONTROL DE CALIDAD DE SOFTWARE

DESARROLLO RPIDO DE APLICACIONES (DRA)

Figura 9 Desarrollo Rpido de Aplicaciones

CONTROL DE CALIDAD DE SOFTWARE

Aquellos productos de software que se puedan dividir en mdulos, cuyo

Figura 10 Modelo Incremental

CONTROL DE CALIDAD DE SOFTWARE

MODELO BIG BANG

Figura 11 Modelo Big Bang

Figura 12 Modelo Big Bang 2

CONTROL DE CALIDAD DE SOFTWARE

4. METODOLOGAS PARA EL DESARROLLO DE SOFTWARE

EN QU CONSISTE LAS METODOLOGAS DE DESARROLLO DE

CONTROL DE CALIDAD DE SOFTWARE

VENTAJAS DEL USO DE METODOLOGAS PARA EL DESARROLLO DE

Facilitar la tarea de planificacin

4.5.2. DESDE EL PUNTO DE VISTA DE LOS INGENIEROS DEL SOFTWARE:

Ayudar a la comprensin del problema

4.5.3. DESDE EL PUNTO DE VISTA DEL CLIENTE O USUARIO:

Figura 13 - Metodologa estructurada

4.6.1. METODOLOGA ESTRUCTURADA ORIENTADA A PROCESOS:

METODOLOGA ORIENTADA A DATOS

4.7.2. DATOS NO JERRQUICOS

4.7.2.1. METODOLOGA INGENIERA DE LA INFORMACIN

CONTROL DE CALIDAD DE SOFTWARE

METODOLOGA ORIENTADA A OBJETOS

Figura 14 - Metodologa Orientada a Objetos

4.8.1. ELEMENTOS DEL MODELO DE OBJETOS

CONTROL DE CALIDAD DE SOFTWARE

4.9.1. RATIONAL UNIFIED PROCESS (RUP):

Figura 16 - Fases de RUP

CONTROL DE CALIDAD DE SOFTWARE