Metodologias para el desarrollo del software

Análisis y Sistemas
20/05/2015
Por: Yeltsin Aldair Torres Recinos
INSTITUTO PRIVADO TECNOLÒGICO SPENCER W. KIMBALL
Bachiller industrial y perito en computación.
5to computación
Análisis y sistemas
Prof.: Álvaro Martínez
Metodologías para el desarrollo del software.
Yeltsin Aldair Torres Recinos
Fecha de entrega: 20/05/2015

20/05/2015
Introducción
El presente el trabajo trata sobre la metodología para desarrollo del software que es Un
proceso de software detallado y completo suele denominarse “Metodología”, también sus
características y los tipos de metodologías.

20/05/2015
Índice vinculado
Metodologías para el desarrollo del software..................................................................................................... 1
METODOLOGÍAS ESTRUCTURADAS.....................................................................................................................................3
METODOLOGÍAS ORIENTADAS A OBJETOS........................................................................................................................3
METODOLOGÍAS TRADICIONALES........................................................................................................................................3
METODOLOGÍAS ÁGILES ........................................................................................................................................................4
CARACTERISTICAS DESEABLESDE UNA METODOLOGIADE UNA METODOLOGIA .......................................................4
EVOLUCION ......................................................................................................................................................... 4
Los tipos de metodologías para el desarrollo del software son:......................................................................... 6
Ciclo de vida del software.....................................................................................................................................................6
Modelos de ciclo de vida .......................................................................................................................................................7
Modelo V .................................................................................................................................................... 7
Modelo en cascada..................................................................................................................................... 8
Modelo espiral............................................................................................................................................ 8
Método espiral .................................................................................................................................................... 9
METODOLOGÍA RUP.............................................................................................................................................................. 10
Principales características .................................................................................................................................................. 10
CICLO DE VIDA.........................................................................................................................................................................11
Fases del ciclo de vida del RUP:..........................................................................................................................................11
Disciplina de soporte RUP....................................................................................................................................................13
Elementos del RUP................................................................................................................................................................13
Artefactos................................................................................................................................................................................13
METODOLOGÍA SCRUM ...................................................................................................................................... 15
Características....................................................................................................................................................................... 15
METODOLOGIA XP ............................................................................................................................................. 17
Entendimiento........................................................................................................................................................................17
1. Interacción con el cliente............................................................................................................................... 19
2. Planificación del proyecto………………………………………………………………………………………………………………………………19
3.Diseño, desarrollo y pruebas …………………………………………………………..…………………………………………………..……20

20/05/2015
1 Por: Yeltsin Aldair Torres Recinos
Metodologías para el desarrollo del software.
Un proceso de software detallado y completo suele denominarse “Metodología”. Las
metodologías se basan en una combinación de los modelos de proceso genéricos (cascada,
evolutivo, incremental, espiral entre otros). Adicionalmente una metodología debería definir
con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas
recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de
herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a
técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del
proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la
diversidad de propuestas y diferencias en el grado de detalle, información 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 análisis y diseño,
podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y
Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo,
aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en
especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías
Tradicionales (o también denominadas Metodologías Pesadas, o Peso Pesado). Otras
metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de
código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños,
hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran
activamente al cliente en el proceso.
Se describe como el conjunto de herramientas, técnicas, procedimientos y soporte
documental para el diseño de Sistemas de información.
En Ingeniería de software cuando se habla de desarrollo de software se habla de desarrollo
de programas y por lo tanto se considera como una tarea de ingeniería, en el cuál se debe
ejecutar una serie de fases, etapas para obtener un programa que funcione de acuerdo con
métodos ya establecidos en otras disciplinas de ingeniería. Las actividades que los
ingenieros de software realizan se encuentran asociadas a un proceso de software donde
intervienen diferentes elementos (fases, actividades, producto, roles, agentes) que
permiten la definición del software a producir (producto), el desarrollo o el diseño del
software, la validación del software tanto lo interno (requerimientos específicos) como lo
externo (expectativas del cliente), y la evolución del software donde se modifica para
adaptarlo a los cambios.
Por otro lado, Sommerville (2002) define que “un método de ingeniería de software es un
enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la
producción de software de alta calidad de una forma costeable”, cabe destacar que para
usar este enfoque se debe manejar conceptos fundamentales tales como; procesos,
métodos, tareas, procedimientos, técnicas, herramientas, productos, entre otros.
Particularmente, una metodología se basa en una combinación de los modelos de proceso
genéricos para obtener como beneficio un software que soluciones un problema.

20/05/2015
Adicionalmente una metodología debería definir con precisión los artefactos, roles y
actividades, junto con prácticas, técnicas recomendadas y guías de adaptación de la
metodología al proyecto. Sin embargo, la complejidad del proceso de creación de software
es netamente dependiente de la naturaleza del proyecto mismo, por lo que el escogimiento
de la metodología estará acorde al nivel de aporte del proyecto, ya sea pequeño, mediano o
de gran nivel.

20/05/2015
A continuación se revisan brevemente cada una de estas categorías de metodologías:
METODOLOGÍAS ESTRUCTURADAS
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el
Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis
(por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente
apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta
generación.
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia),
MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos
estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco
e Information Engineering.
METODOLOGÍAS ORIENTADAS A OBJETOS
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los
más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera
versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines
de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de
conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a
un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación
Orientada a Objetos más popular en la actualidad.
Algunas metodologías orientadas a objetos que utilizan la notación UML son:
 Rational Unified Process (RUP),
 OPEN,
 MÉTRICA (que también soporta la notación estructurada).
METODOLOGÍAS TRADICIONALES
Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación
durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o
clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del
sistema. Todas las propuestas metodológicas antes indicadas pueden considerarse como
metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que
presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su
configuración previa a aplicarse), realizando una configuración adecuada, podría
considerarse Ágil.

20/05/2015
METODOLOGÍAS ÁGILES
Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de
software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último
momento).
Entre las metodologías ágiles identificadas son:
 Extreme Programming
 Scrum
 Familia de Metodologías Crystal
 Feature Driven Development
 Proceso Unificado Rational, una configuración ágil
 Dynamic Systems Development Method
 Adaptive Software Development
 Open Source Software Development
CARACTERISTICAS DESEABLESDE UNA METODOLOGIADE UNA METODOLOGIA
 Existencia de reglas predefinidas
 Cobertura total del ciclo de desarrollo
 Verificaciones intermedias
 Planificación y control
 Comunicación efectiva
 Utilización sobre un abanico amplio de proyectos
 Fácil formación
 Herramientas CASE
 Actividades que mejoren el proceso de desarrollo
 Soporte al mantenimiento
 Soporte de la reutilización de software
EVOLUCION
Desde que se empezó a trabajar sobre el desarrollo de programas, se siguieron ciertos
métodos que permitían llevar a producir un buen proyecto, estas metodologías aplicadas
eran simples, solo se preocupaban por los procesos mas no por los datos, por lo tanto los
métodos eran desarrollados hacia los procesos. El modelo de procesos predominaba para
los años 60 y consistía en codificar y corregir (Code-and-Fix), si al terminar se descubría que
el diseño era incorrecto, la solución era desecharlo y volver a empezar 3
, este modelo
implementaba el código y luego se pensaba en los requisitos, diseño, validación y
mantenimiento. Los principales problemas del modelo de procesos son:
 Los arreglos se hacen costosos, después de tantas correcciones el código tenía una
mala estructura.

20/05/2015
 El software no se ajusta a las necesidades del usuario, por lo que es rechazado o su
reconstrucción es muy cara.
 El código es difícil de reparar por su pobre preparación para probar y modificar.
En la década de los setenta empezó a tomar la importancia de los datos, y para solucionar
sistemas complejos empezó el análisis por partes o etapas, se introducen la planeación y
administración. El modelo en cascada surge como respuesta al modelo de procesos, este
modelo tiene más disciplina y se basa en el análisis, diseño, pruebas y mantenimientos.
La década de los ochenta es la época marcada por las metodologías dirigida a datos cuya
importancia va tomando cuerpo en las organizaciones. Se empiezan a estudiar los objetos
en sí como unidades de información. Para los años 90 se quiere dar respuesta al entorno
siempre cambiante y en rápida evolución en que se han de desarrollar los programas
informáticos, lo cual da lugar a trabajar en ciclos cortos (como mini-proyectos) que
implementan una parte de las funcionalidades, pero sin perder el rumbo general del
proyecto global.
Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en lograr
que el proyecto sea puesto en funcionamiento sino en minimizar costos durante su
desarrollo y sobre todo durante su mantenimiento. Los nuevos métodos van buscando
minimizar riesgos y, puesto que los errores más perjudiciales se producen en los primeros
pasos, se comienza ya desde la fase más general del estudio por analizar los riesgos que
significa seguir con las siguientes fases del desarrollo.
Las metodologías más utilizadas a nivel mundial en orden cronológico:
 Década de los 70s
 Programación Estructurada Jackson desde 1975
Década de los 80s
 Structured Systems Analysis and Design Methodology (SSADM) desde 1980
 Structured Analysis and Design Technique (SADT) desde 1980
 Ingeniería de la Información (IE/IEM) desde 1981
Década de los 90s
 Rapid Application Development (RAD) desde 1991
 Programación Orientada a Objetos (OOP) a lo largo de la década de los 90's
 Virtual Finite State Machine (VFSM) desde 1990s
 Dynamic Systems Development Method desarrollado en UK desde 1995.
 Rational Unified Process (RUP) desde 1999
Año 2000 en adelante
 Extreme Programming (XP) desde 1999
 Enterprise Unified Process (EUP) extensiones RUP desde 2002
 Constructionist Design Methodology (CDM) desde 2004 por Kristinn R. Thórisson
 Agile Unified Process (AUP) desde 2005 por Scott Ambler

20/05/2015
Los tipos de metodologías para el desarrollo del software son:
 CICLO DE VIDA
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en las
distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas
según la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la
eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la
arquitectura. Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de
modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la
arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la
arquitectura. En la fase de construcción, se lleva a cabo la construcción del producto por
medio de una serie de iteraciones. Para cada iteración se seleccionan algunos Casos de Uso,
se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una
pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la
implementación de la nueva versión del producto. En la fase de transición se pretende
garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de
la fase el esfuerzo dedicado a una disciplina varía.
Ciclo de vida del software
El termino ciclo de vida del software describe el desarrollo de software desde la fase inicial
hasta la fase final. El propósito de este programa es definir las distintas fases intermedias
que se requieren para validar el desarrollo de la aplicación.
El ciclo de vida básico de un software consta de los siguientes requerimientos:
 Definición de objetos: define el resultado del proyecto y su papel en la estrategia
global.
 Análisis de los requisitos y su viabilidad: Recopilar, examinar y formular los requisitos
del cliente y examinar cualquier descripción que se pueda aplicar.
 Diseño general: Requisitos generales de la arquitectura de la aplicación.

20/05/2015
 Diseño en detalle: Definición precisa de cada subconjunto de la aplicación.
 Programación: Implementación de un lenguaje de programación para crear las
funciones definidas durante la etapa de diseño.
 Prueba de unidad: Prueba individual de cada subconjunto de la aplicación para
garantizar que se implementara de acuerdo con las especificaciones.
 Integración: Para garantizar los diferentes módulos se integren con la aplicación.
 Prueba beta o validación: Para garantizar que el software cumple con las
especificaciones originales.
 Documentación: Sirve para documentar información necesaria para los usuarios del
software y para desarrollos futuros.
 Implementación: Poner en producción.
 Mantenimiento: Para todos los procedimientos correctivos y las actualizaciones
secundarias del software (Mantenimiento continuo).
Modelos de ciclo de vida
Para facilitar una metodología común entre el cliente y la compañía de software, los
modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo
involucradas, y la documentación requerida, de manera que cada etapa se valide antes de
continuar con la siguiente etapa.
Modelo V
El modelo de ciclo de vida V proviene del principio que establece que los procedimientos
utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado
en la fase de diseño.

20/05/2015
Modelo en cascada
El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y termina alrededor de
1970. Se define como una secuencia de fases en la etapa final de cada una de ellas se reúne
la documentación para garantizar que cumple con las especificaciones y los requisitos antes
de pasar a la siguiente fase
Modelo espiral
El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que
conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos
del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones
incrementales. En el modelo Espiral el software se construye en una serie de versiones
incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en
papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más
completas del sistema diseñado.

20/05/2015
Método espiral
DESARROLLO EN ESPIRAL
Éste es un tipo de desarrollo evolutivo, las versiones de cada etapa van evolucionando,
madurando de acuerdo a cada iteración que se haga cabe recalcar que en cada iteración se
desarrollará todas las etapas en orden.
CARACTERÍSTICAS:
-Es ideal para crear productos con diferentes versiones mejoradas como se hace con el
software moderno de microcomputadoras.
- puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
COMUNICACIÓN CON EL CLIENTE:
Aquí establecemos los requerimientos y objetivos que se quieren del sistema.
PLANIFICACIÓN
Seguidamente debemos estructurar nuestro trabajo, planificar tiempo, establecer metas,
etc.
ANÁLISIS DE RIESGOS
Se debe identificar los riesgos relacionados con el proyecto, todas aquellas eventualidades
que pueden ocurrir, y tratar de que estos riesgos no se den o en el caso de que lleguen a
pasar establecer acciones para resolverlas.
INGENIERÍA
Las tarea necesarias para construir la aplicación (la representación del sistema y
debidamente estructurada).
CONSTRUCCIÓN Y ADAPTACIÓN
Luego se debe construir el software, realizar las pruebas correspondientes y brindar
soporte al usuario.
EVALUACIÓN DEL CLIENTE
El cliente es quien debe dar la conformidad del avance y si el resultado del trabajo cumple
con las expectativas del usuario.
VENTAJAS
A medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan
mejor ante riesgos en cada uno de los niveles.
-Reduce los riesgos antes de que se conviertan en problemáticos.

20/05/2015
METODOLOGÍA RUP
Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los
procesos y se mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado
UML, constituye la metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos.
El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada
organización.
Describe cómo aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos
para su realización.
Se centra en la producción y mantenimiento de modelos del sistema.
Principales características
 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y
cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software

20/05/2015
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar
centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código
fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso).
CICLO DE VIDA
Esfuerzo en actividades según fase del proyecto
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en las
distintas actividades.
Fases del ciclo de vida del RUP:
1. Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto
con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión
muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones
posteriores.
2. Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que
permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza

20/05/2015
la especificación de los casos de uso seleccionados y el primer análisis del dominio del
problema, se diseña la solución preliminar.
3. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema,
para ello se deben clarificar los requerimientos pendientes, administrar los cambios de
acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.
4. Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para
los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar
que el producto cumpla con las especificaciones entregadas por las personas involucradas
en el proyecto.
La metodología RUP tiene 6 principios clave:
1. Adaptación del proceso: El proceso debe adaptarse a las características de la
organización para la que se está desarrollando el software.
2. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores
del proyecto.
3. Colaboración entre equipos: Debe haber una comunicación fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros.
4. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma
interna, en etapas iteradas. En cada iteración se evaluará la calidad y estabilidad del
producto y analizará la opinión y sugerencias de los inversores.

20/05/2015
5. Elevar el nivel de abstracción: Motivar el uso de de conceptos reutilizables.
6. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la
producción.
Disciplina de desarrollo de RUP
Determina las etapas a realizar durante el proyecto de creación del software.
 Ingeniería o modelado del negocio: Analizar y entender las necesidades del negocio
para el cual se está desarrollando el software.
 Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del
sistema.
 Análisis y diseño: Trasladar los requisitos analizados anteriormente a un sistema
automatizado y desarrollar una arquitectura para el sistema.
 Implementación: Crear software que se ajuste a la arquitectura diseñada y que tenga
el comportamiento deseado.
 Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo
solicitado está presente.
 Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.
Disciplina de soporte RUP
Determina la documentación que es necesaria realizar durante el proyecto.
 Configuración y administración del cambio: Guardar todas las versiones del proyecto.
 Administración del proyecto: Administrar los horarios y recursos que se deben de
emplear.
 Ambiente: Administrar el ambiente de desarrollo del software.
 Distribución: Hacer todo lo necesario para la salida del proyecto.
Elementos del RUP
 Actividades: Procesos que se han de realizar en cada etapa/iteración.
 Trabajadores: Personas involucradas en cada actividad del proyecto.
 Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un
documento, un modelo, un elemento del modelo.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de
artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema
(entre otros). Estos artefactos (entre otros) son los siguientes:

20/05/2015
Inicio:
 Documento Visión
 Especificación de Requerimientos
Elaboración:
 Diagramas de caso de uso
Construcción:
 Documento Arquitectura que trabaja con las siguientes vistas:
VISTA LOGICA:
 Diagrama de clases
 Modelo E-R (Si el sistema así lo requiere)
VISTA DE IMPLEMENTACION:
 Diagrama de Secuencia
 Diagrama de estados
 Diagrama de Colaboración
VISTA CONCEPTUAL
 Modelo de dominio
VISTA FISICA
 Mapa de comportamiento a nivel de har

20/05/2015
METODOLOGÍA SCRUM
Scrum es una metodología ágil de desarrollo, aunque surgió como modelo para el
desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con
requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el
desarrollo de determinados sistemas de software.
Es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa
en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la
evolución del proyecto.
Scrum es una metodología ágil, y como tal:
 Es un modo de desarrollo de carácter adaptable más que predictivo.
 Orientado a las personas más que a los procesos.
 Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y
revisiones.
Se comienza con la visión general del producto, especificando y dando detalle a las
funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a
cabo en un periodo de tiempo breve (normalmente de 30 días).
Cada uno de estos periodos de desarrollo es una iteración que finaliza con la producción de
un incremento operativo del producto.
Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de
reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior
y el previsto para el día siguiente.
Estructura central de Scrum
Características
 Equipos auto dirigidos
 Utiliza reglas para crear un entorno ágil de administración de proyectos
 No prescribe prácticas específicas de ingeniería
 Los requerimientos se capturan como ítems de la lista Product Backlog.
 El producto se construye en una serie de Sprints de un mes de duración.

20/05/2015
Herramientas y Prácticas
Scrum no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica prácticas y
herramientas de gerencia que se aplican en sus distintas fases para evitar el caos originado
por la complejidad e imposibilidad de realizar predicciones.
Product Backlog List
Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un
proyecto comienza es muy difícil tener claro todos los requerimientos sobre el producto. Sin
embargo, suelen surgir los más importantes que casi siempre son más que suficientes para
un Sprint.
El objetivo es asegurar que el producto definido al terminar la lista es el más correcto, útil y
competitivo posible y para esto la lista debe acompañar los cambios en el entorno y el
producto.
Existe un rol asociado con esta lista y es el de Product Owner. Si alguien quiere realizar
cualquier modificación sobre la lista por ejemplo: agregar o incrementar la prioridad de sus
elementos tiene que convencer al Product Owner.
Sprints
Un Sprint es el procedimiento de adaptación de las cambiantes variables del entorno
(requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos iterativos en los
cuales se desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante
un Sprint el producto es diseñado, codificado y probado. Y su arquitectura y diseño
evolucionan durante el desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fácil de recordar
y esté siempre presente en el equipo.
Burn down Chart
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una
línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso
del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en
el sentido de que los requisitos están bien definidos desde el principio y no varían nunca)
hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más
requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden
nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si
se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos
tramos.
Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los ítems de la Product Backlog
List que van a ser implementados en el siguiente Sprint.

20/05/2015
Los ítems son seleccionados por el Scrum Team, el Scrum Master y el Product Owner en la
Sprint Planning Meeting a partir de la priorización de los ítems y los objetivos que se
marcaron para ese Sprint. A partir de los objetivos a cumplir durante el Sprint el Scrum
Team determina que tareas debe desempeñar para cumplir el objetivo. De esto surge el
Sprint Backlog.
Stabilization Sprints
En estos Sprints el equipo se concentra en encontrar defectos, no en agregar funcionalidad.
Suelen aplicarse cuando se prepara un producto para el release. Son útiles cuando se están
realizando pruebas beta, se está introduciendo a un equipo en la metodología de Scrum o
cuando la calidad de un producto no alcanza los límites esperados.
No fueron definidos por Scrum pero han sido recomendados por su utilidad al aplicar esta
metodología.
Scrum of Scrums o MetaScrum
Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo está metodología
ha sido aplicada en proyectos que involucran más de 600 personas. Esto ha sido llevado a
cabo dividiendo a los accionistas en equipos de pequeños de hasta 10 personas
aproximadamente. Y definiendo jerárquicamente personas que pertenecen a dos equipos,
es decir, además de su rol específico dentro de un equipo tienen el rol de enlace en un
equipo superior.
METODOLOGIA XP
Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se
actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del
producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3
semanas como máximo.
Entendimiento
1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por
el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en
proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos.
Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma
sencilla.
2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia
de cómo funciona el sistema completo. XP estimula historias, que son breves descripciones
de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified
Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el
alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración)
también ayudarán al equipo a definir actividades durante el diseño del sistema. Cada tarjeta

20/05/2015
representa una clase en la programación orientada a objetos y define sus responsabilidades
(lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas).
3. Propiedad colectiva del código: un código con propiedad compartida. Nadie es el
propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los
métodos tradicionales en los que un simple programador posee un conjunto de código. Los
defensores de XP argumentan que mientras haya más gente trabajando en una pieza,
menos errores aparecerán.
4. Estándar de codificación: define la propiedad del código compartido así como las reglas
para escribir y documentar el código y la comunicación entre diferentes piezas de código
desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera
que el código en el sistema se vea como si hubiera estado escrito por una sola persona.
Bienestar del programador.
1. La semana de 40 horas: la programación extrema sostiene que los programadores
cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los
programadores frescos, generará código de mayor calidad. Como dice Beck, está bien
trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas
seguidas.
PROCESO DE DESARROLLO
La programación extrema parte del caso habitual de una compañía que desarrolla software
normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño), uno
de desarrollo y los clientes finales. La relación entre el equipo de diseño, los que desarrollan
el software y clientes es totalmente diferente al que se ha producido en las metodologías
tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y
de una fase de validación posterior al mismo.

20/05/2015
1. Interacción con el cliente.
En este tipo de programación el cliente pasa a ser parte implicada en el equipo de
desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en
efectuar las reuniones de planificación. Tiene un papel importante de interacción con el
equipo de programadores, sobre todo después de cada cambio, y de cada posible problema
localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de
programación existirán pruebas de aceptación de la programación que ayudarán a que su
labor sea lo más provechosa posible.
Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo. Se
elimina la fase inicial de recopilación de requerimientos, y se permite que éstos se vayan
cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que
el cliente pueda ir cambiando de opinión sobre la marcha, pero a cambio han de estar
siempre disponibles para solucionar las dudas del equipo de desarrollo.
En XP aparece un nuevo concepto llamado “Historia de usuario”. Se trata de una lista de
características que el cliente necesita que existan en el producto final. Estas constan de dos
fases:
o En la primera fase, el cliente describe con sus propias palabras las características y, es el
responsable del equipo, el encargado de informarlo de las dificultades técnicas de cada una
de ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un conjunto
de historias y las ordena en función de la prioridad que tiene para él. De esta manera ya es
posible definir unas fechas aproximadas para ellos.
En la segunda fase, el cliente cogerá las primeras historias a implementar y las dividirá en
trabajos a realizar. El cliente también participa, pero hay más peso por parte del equipo de
desarrolladores, esto dará como resultado una planificación más exacta. Este método se
repetirá para cada historia.
A diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige que sea el
cliente el encargado de escribir los documentos con las especificaciones de lo que
realmente quiere, como un documento de requisitos de usuario.
En esta fase, el equipo técnico será el 'encargado de catalogar las historias del cliente y
asignarles una duración. La norma es que cada historia de usuario tiene que poder ser
realizable en un espacio entre una y tres semanas de programación. Las que requieran
menos tiempo serán agrupadas, y las que necesiten más serán modificadas o divididas.
Finalmente decir que las historias de los usuarios serán escritas en tarjetas, lo que facilitará
que el cliente pueda especificar la importancia relativa entre las diferentes historias de
usuario, así como el trabajo de los programadores que podrán catalogarlas correctamente.
Este formato también es muy útil en el momento de las pruebas de aceptación.
2. PLANIFICACIÓN DEL PROYECTO
En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán
diferentes iteraciones. Para hacerlo será necesaria la existencia de reglas que se han de
seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se
sientan realmente partícipes de la decisión tomada.

20/05/2015
Las entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el cliente ha de
recibir una nueva versión. Cuanto más tiempo se tarde en introducir una parte esencial,
menos tiempo se tendrá para trabajar con ella después. Se aconseja muchas entregas y
muy frecuentes. De esta manera un error en la parte inicial del sistema tiene más
posibilidades de detectarse rápidamente.
Una de las máximas a aplicar es, los cambios, no han de suponer más horas de
programación para el programador, ya que el que no se termina en un día, se deja para el
día siguiente.
Se ha de tener asumido que en el proceso de planificación habrán errores, es más, serán
comunes, y por esto esta metodología ya los tiene previstos, por lo tanto se establecerán
mecanismos de revisión. Cada tres o cinco iteraciones es normal revisar las historias de los
usuarios, y renegociar la planificación.
Cada iteración necesita también ser planificada, es lo que se llama planificación iterativa, en
la que se anotarán las historias de usuarios que se consideren esenciales y las que no han
pasado las pruebas de aceptación. Estas planificaciones también se harán en tarjetas, en las
que se escribirán los trabajos que durarán entre uno y tres días.
Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al proceso de
desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que aún no
han estado programados.
Este tipo de planificación en iteraciones y el diseño iterativo, hace que aparezca una práctica
que no existía en la programación tradicional. Se trata de las discusiones diarias informales,
para fomentar la comunicación, y para hacer que los desarrolladores tengan tiempo de
hablar de los problemas a los que se enfrentan y de ver cómo van con sus trabajos.
3. DISEÑO, DESARROLLO Y PRUEBAS
El desarrollo es la parte más importante en el proceso de la programación extrema. Todos
los trabajos tienen como objetivo que se programen lo más rápidamente posible, sin
interrupciones y en dirección correcta.
También es muy importante el diseño, y se establecen los mecanismos, para que éste sea
revisado y mejorado de manera continuada a lo largo del proyecto, según se van añadiendo
funcionalidades al mismo.
La clave del proceso de desarrollar XP es la comunicación. La mayoría de los problemas en
los proyectos son por falta de comunicación en el equipo.
En XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es mejorar la
comunicación entre todos los integrantes del equipo, al crear una visión global y común de
lo que se quiere desarrollar. La metáfora tiene que ser expresada en términos conocidos
por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollará con
alguna cosa de la vida real.

20/05/2015
Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir:
Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una
prueba sencilla, y después escribir el código para que la pase. Una vez pasada se amplía y
se continúa. En XP hay una máxima que dice "Todo el código que puede fallar tiene que
tener una prueba".
Con estas normas se obtiene un código simple y funcional de manera bastante rápida. Por
esto es importante pasar las pruebas al 100%.
Respecto a la integración del soft, en XP se ha de hacer una integración continua, es decir,
cada vez se tienen que ir integrando pequeños fragmentos de código, para evitar que al
finalizar el proyecto se tenga que invertir grandes esfuerzos en la integración final. En todo
buen proyecto de XP, tendría que existir una versión al día integrada, de manera que los
cambios siempre se realicen en esta última versión.
Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del
programa.
De esta manera se evita que haya partes "propietarias de cada programador". Por esto es
tan importante la integración diaria.
Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programación en parejas,
es decir, hacer que los programadores no trabajen en solitario, sino que siempre estarán
con otra persona. Una pareja de programadores ha de compartir el teclado, el monitor y el
ratón. El principio fundamental de este hecho es realizar de manera continua y sin parar el
desarrollo de código. Las parejas tienen que ir cambiando de manera periódica, para hacer
que el conocimiento se difunda en el grupo. Está demostrado que de esta manera el trabajo
es más eficaz y también se consigue más y mejor código.

20/05/2015
Conclusiones
 Las metodologías se basan en una combinación de los modelos de proceso
genéricos (cascada, evolutivo, incremental, espiral entre otros).
 Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para
el Diseño (por ejemplo: el diagrama de Estructura)
 El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo
evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos
controlados y sistemáticos del Modelo Cascada.
 Es una metodología RUP cuyo fin es entregar un producto de software. Se
estructura todos los procesos y se mide la eficiencia de la organización.

20/05/2015
E-grafía
 http://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARROLLO+
DE+SOFTWARE
 http://paradigmasiut.blogspot.com/2013/04/metodologia-de-desarrollo-de-
software.html
 http://html.rincondelvago.com/ciclo-de-vida-del-software.html
 http://procesosdesoftware.wikispaces.com/metodo+espiral
 http://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
 http://procesosdesoftware.wikispaces.com/METODOLOGIA+SCRUM
 http://procesosdesoftware.wikispaces.com/METODOLOGIA+XP

Metodologias para el desarrollo del software

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Metodologias para el desarrollo del software

Similar to Metodologias para el desarrollo del software (20)

Metodologias para el desarrollo del software