METODOLOGÍAS PARA EL

DESARROLLO DE SOFTWARE
INTRODUCCIÓN AL ANÁLISIS DE SISTEMAS

ANÁLISIS DE SISTEMAS
2019
 UNIVERSIDAD NACIONAL “PEDRO RUIZ GALLO”
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
ESCUELA PROFESIONAL DE ESTADÍSTICA

MATERIA
ANÁLISIS DE SISTEMAS

TEMA
INTRODUCCIÓN AL ANÁLISIS DE SISTEMAS

CONTENIDO
“CICLOS DE VIDA EN EL DESARROLLO DE SISTEMAS DE INFORMACIÓN”

DOCENTE
FUENTES ADRIANZÉN DENNY JOHN.

INTEGRANTES
 APONTE SUYÓN LUCELY.
 CALDERON HUAMÁN SANDRA.
 RODAS AZALDE JHAN CARLOS.
 SANTAMARÍA VÁSQUEZ CARLOS.
 SILVA MONTAÑO KENIA.

FECHA
12/05/2015
 MODELO SECUENCIAL LINEAL

Este es también llamado "Modelo Clásico", "Modelo Tradicional" o "Modelo en Cascada".

Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás
modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple;
dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase
tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la
satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas
muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las
flechas hacia atrás representan la retroalimentación.

Características:

 Planear un proyecto antes de embarcarse en él.

 Definir el comportamiento externo deseado del sistema antes de diseñar su

arquitectura interna.

 Documentar los resultados de cada actividad.

 Diseñar un sistema antes de codificarlo.

 Testear un sistema después de construirlo.

Ventaja:

Una de las contribuciones más importantes del modelo cascada es para los
administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.

Desventajas:
 Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en
las etapas tempranas del proyecto. Si los cambios se producen en etapa madura
(codificación o prueba) pueden ser catastróficos para un proyecto grande.

 No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos
(etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos
es luego difícil de acomodar.

 El cliente debe tener paciencia ya que el software no estará disponible hasta muy
avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser
desastroso, implicando reinicio del proyecto con altos costos.
MODELO CASCADA

DESCRIPCIÓN

 Es un modelo sencillo (para explicar al cliente).

 También llamado ciclo de vida clásico, sugiere un enfoque sistémico secuencial en el

desarrollo del software.

 Requiere que los requerimientos estén bien definidos y estables en forma razonable.

 Es el paradigma más antiguo para la Ingeniería del Software.

FASES DEL MODELO CASCADA

 Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema
mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y
luego asignando algún subconjunto de estos requisitos al software.

 Análisis de los requisitos del software: El proceso de recopilación de los requisitos se centra
e Intensifica especialmente en el software. El ingeniero de software debe comprender
el ámbito de la Información del software, así como la función, el rendimiento y las
interfaces requeridas.

 Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz.

 Codificación: el diseño debe traducirse en una forma legible para la máquina. El paso de
codificación realiza esta tarea.

 Prueba: La prueba se centra en la lógica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados que
realmente se requieren.

 Mantenimiento: El software sufrirá cambios después de que se entrega al cliente. Los

cambios ocurrirán debido a que hayan encontrado errores, a que el software deba
adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o
debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
CARACTERISTICAS

 Es el más utilizado.

 Es una visión del proceso de desarrollo de software como una sucesión de etapas que
producen productos intermedios.

 Para que el proyecto tenga éxito deben desarrollarse todas las fases.

 Las fases continúan hasta que los objetivos se han cumplido.

 Si se cambia el orden de las fases, el producto final será de inferior calidad

VENTAJAS

 La planificación es sencilla.

 La calidad del producto resultante es alta.

 Permite trabajar con personal poco cualificado

DESVENTAJAS

 No refleja realmente el proceso de desarrollo del software

 Se tarda mucho tiempo en pasar por todo el ciclo

 El mantenimiento se realiza en el código fuente

 Las revisiones de proyectos de gran complejidad son muy difíciles

CONCLUSIONES

En conclusión a pesar de que es un modelo que es muy tardado ya que lleva una planeación que
debe cumplirse obligatoriamente para que los resultados sean satisfactorios.
MODELO INCREMENTAL

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque
incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de
desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir
experiencia con el sistema. Este modelo se conoce también bajo las siguientes
denominaciones:

 Método de las comparaciones limitadas sucesivas.

 Ciencia de salir del paso.

 Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía
interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo
incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el
calendario. Cada secuencia lineal produce un incremento del software. El primer incremento
generalmente es un producto esencial denominado núcleo.
En una visión genérica, el proceso se divide en 4 partes:

 Análisis
 Diseño
 Código
 Prueba

El Modelo Incremental se puede ver aquí en forma gráfica:

Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline.
Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada
incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a
fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se
elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.
PIPELINE

La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un

proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la
anterior.
Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya
que se pueden concatenar comandos fácilmente con tuberías (pipe).
También es una arquitectura muy natural en el paradigma de programación funcional, ya que
equivale a la composición de funciones matemáticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del
usuario por medio de una interfaz alfanumérica.

CARACTERÍSTICAS

 Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta
frecuencia.

 El usuario se involucre más.

 Difícil de evaluar el costo total.

 Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como
un todo.

 Requiere gestores experimentados.

 Los errores en los requisitos se detectan tarde.

 El resultado puede ser muy positivo.

VENTAJAS:

 Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se

implementa la funcionalidad parcial.

 También provee un impacto ventajoso frente al cliente, que es la entrega temprana de

partes operativas del Software.

 El modelo proporciona todas las ventajas del modelo en cascada realimentado,

reduciendo sus desventajas sólo al ámbito de cada incremento.

 Permite entregar al cliente un producto más rápido en comparación del modelo de

cascada.
  Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

DESVENTAJAS:

 El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto

nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

 Requiere de mucha planeación, tanto administrativa como técnica.

 Requiere de metas claras para conocer el estado del proyecto.

CONCLUSIÓN:

Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del
producto Software denominados "incrementos" del sistema, que son escogidos en base a
prioridades predefinidas de algún modo.
El modelo permite una implementación con refinamientos sucesivos (ampliación y/o mejoras).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora
la versión previamente implementada del producto software.
MODELO EVOLUTIVO
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y
complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de
operación. Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los más
conocidos y utilizados del tipo evolutivo.
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el
sistema adecuado. Una ventaja de este modelo es que se obtiene una rápida realimentación del
usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

TIPOS DE DESARROLLO EVOLUTIVO:

1. Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los

requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más
claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el
usuario.

2. Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y

trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se
comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para
experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

VENTAJAS

 La especificación puede desarrollarse de forma creciente.

 Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja
en una mejora de la calidad del software.

 Es más efectivo que el modelo de cascada, ya que cumple con las necesidades
inmediatas del cliente.

DESVENTAJAS
 Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el
sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen
cada versión del sistema.

 Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para
la estructura del software haciendo costoso el mantenimiento.

 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan

herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.
EL MODELO EN ESPIRAL

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la

construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.

El modelo en espiral fue desarrollado por Boehm, quien lo describe así:

El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que
se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con
muchos usuarios.

CICLOS O ITERACIONES

En cada vuelta tomamos en cuenta:

 Los Objetivos: Que necesidad debe envolver el programa.

 Las Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través
de diferentes puntos como son:

1. Las Características: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestión del sistema.

3. Riesgo asumido con cada alternativa.

 Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

 Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral

tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:

1. Angular: Indica el avance del proyecto del software dentro de un ciclo.

2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se
pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la
creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos
fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y
habilidad para detectar y catalogar correctamente los riesgos.
TAREAS

Para cada ciclo habrá cuatro actividades:

- Determinar o fijar objetivos
- Análisis del riesgo.
- Desarrollo y probar.
- Planificación.

DETERMINAR O FIJAR OBJETIVOS

 Fijar también los productos definidos para obtener: requisitos, especificación, manual de
usuario.
 Fijar las restricciones.
 Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
 Hay una cosa que solo se hace una vez: planificación inicial.

ANÁLISIS DEL RIESGO:

Desarrollar, verificar y validar (probar)

 Tareas de la actividad propia y de prueba.

 Análisis de alternativas e identificación resolución de riesgos.

 Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el

desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo,
cascada, etc.

DESARROLLAR, VERIFICAR Y VALIDAR (PROBAR)

 Tareas de la actividad propia y de prueba.
 Análisis de alternativas e identificación resolución de riesgos.
 Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el
desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada,
etc. así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de
desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de
protección son la principal consideración, un desarrollo basado en transformaciones formales
podría ser el más apropiado.
PLANIFICAR

Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes
y planificamos la próxima actividad.

VENTAJAS

 El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los
restantes modelos.
 Reduce riesgos del proyecto.
 Incorpora objetivos de calidad.
 Integra el desarrollo con el mantenimiento, etc.

DESVENTAJAS

 Genera mucho tiempo en el desarrollo del sistema.

 Modelo costoso.
 Requiere experiencia en la identificación de riesgos.

MODELO DE PROTOTIPOS
Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del
desarrollo del software puede no estar seguro de la eficiencia de un algoritmo, de la calidad de
adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-
máquina. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos
puede ofrecer el mejor enfoque. El paradigma de construcción de prototipos comienza con la
recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales
para el software, identifican los requisitos conocidos y las áreas del esquema en donde es
obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una
representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño
rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza
para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se
pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el
desarrollador comprenda mejor lo que se necesita hacer.
PROGRAMACION EXTREMA XP

La programación extrema o Extreme Programming (XP) es un enfoque de la ingeniería de software

formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999).
Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el
éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos
los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios.
XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo técnico.

¿QUÉ ES PROGRAMACIÓN EXTREMA O XP?

 Metodología liviana de desarrollo de software

 Conjunto de prácticas y reglas empleadas para desarrollar software
 Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes
 Originada en el proyecto C3 para Chrysler
 En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada
vez, a través de todo el proceso de desarrollo.

OBJETIVOS.

 Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de

proyectos.
 Mejorar la productividad de los proyectos.
 Garantizar la Calidad del Software desarrollando, haciendo que este supere las
expectativas del cliente.

CONTEXTO XP

 Cliente bien definido

 Los requisitos pueden (y van a) cambiar
 Grupo pequeño y muy integrado (máximo 12 personas
 Equipo con formación elevada y capacidad de aprender

CARACTERÍSTICAS XP

 Metodología basada en prueba y error

 Fundamentada en Valores y Prácticas
 Expresada en forma de 12 Prácticas–Conjunto completo–Se soportan unas a otras–Son
conocidas desde hace tiempo. La novedad es juntarlas
VALORES XP

1) Simplicidad XP: propone el principio de hacer la cosa más simple que pueda funcionar, en
relación al proceso y la codificación. Es mejor hacer hoy algo simple, que hacerlo complicado y
probablemente nunca usarlo mañana.

2) Comunicación: Algunos problemas en los proyectos tienen origen en que alguien no dijo algo
importante en algún momento. XP hace casi imposible la falta de comunicación.

3) Retroalimentación: Durante la vida de un proyecto son muy pocas las direcciones que
permanecen constantes, ya sean los detalles del desarrollo, los requerimientos del sistema, la
arquitectura y muchas otras pueden cambiar.

4) Coraje: Coraje es la acción efectiva frente al miedo, aunque nuestro medio no es

inherentemente peligroso, también nos enfrentamos al miedo de las consecuencias de nuestras
acciones. El coraje lo debemos de complementar con los otros valores para obtener una guía de
que hacer frente a una situación donde nos de miedo actuar, ya sea al resolver un problema o
tomar responsabilidad de una falla, la comunicación, simpleza y retroalimentación también se
benefician del coraje al obtener información concreta para actuar.
5) Respeto: Los valores anteriores se basan y dirigen con este, si no hay respeto y aprecio entre el
grupo de trabajo XP no se puede aplicar efectivamente, si el equipo no respeta el proyecto, este ya
está perdido.

EL ESTILO XP

 Está orientada hacia quien produce y usa el software

 Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema.
 Combina las que han demostrado ser las mejores prácticas para desarrollar software, y las
lleva al extremo.

PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA

Para que todo esto funcione, la programación extrema se basa en doce "prácticas básicas" que
deben seguirse al pie de la letra.
1) Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el
proyecto, incluido el cliente y el responsable del proyecto.
2) Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las
mini-versiones. La planificación se revisa continuamente.
3) Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas
para validar las mini-versiones.
4) Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para
poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y
no trozos de código que no pueda ver funcionando.
5) Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible.
Mantener siempre sencillo el código.
6) Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo
ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
7) Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba
automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.
8) Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en
cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse.
Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego
integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos
metido.
9) El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para
eso se hacen las pruebas automáticas.
10) Normas de codificación: Debe haber un estilo común de codificación (no importa cuál), de
forma que parezca que ha sido realizado por una única persona.
11) Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas
partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo
que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a
que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal
entendidos.
12) Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente.
Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben
hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay
que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o
mini-versión.

VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING

Ventajas:
Programación organizada.
Menor taza de errores.
Satisfacción del programador.
Desventajas:

Es recomendable emplearlo solo en proyectos a corto plazo.

Altas comisiones en caso de fallar.

CONCLUSIONES
Apostolado de metodologías exitosas
Aporte de la experiencia práctica a los modelos teóricos
Enfoque de conjunto de prácticas como rompecabezas
Tecnología en expansión
Importancia de revisitar las metodologías desde la experiencia práctica

Metodología Scrum
Historia
Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los
estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a
mediados de los 80. 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.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation
(Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en
Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken
Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96.
Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de
software scrum está considerado como modelo ágil por la Agile Alliance.

Definición
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo
principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en
construir primero la funcionalidad de mayor valor para el cliente y en los principios de
inspección continua, adaptación, auto-gestión e innovación.

Utilidad
Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve
crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software
con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o
de prioridad en el inicio de cada nueva iteración sin ningún problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma
parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar
sus capacidades.
Beneficios
1) Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le
aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el
Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product
Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al
equipo.
2) Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada
para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.
3) Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más
importantes del proyecto antes de que esté finalizado por completo.
4) Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión
funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.
5) Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos
para organizarse.
6) Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.
7) Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo
por sprint (los llamados puntos historia), con lo que consecuentemente, es
posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que
todavía está en el Backlog.
8) Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar
y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos
eficazmente de manera anticipada.
VALORES DE SCRUM
Scrum es una “carrocería” para dar forma a los principios ágiles. Es una ayuda para organizar a
las personas y el flujo de trabajo; como lo pueden ser otras propuestas de formas de trabajo ágil:
Cristal, DSDM, etc.
La carrocería sin motor, sin los valores que dan sentido al desarrollo ágil, no funciona.
Delegación de atribuciones (empowerment) al equipo para que pueda auto- organizarse y
tomar las decisiones sobre el desarrollo.
Respeto entre las personas.

Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades.
Responsabilidad y auto-disciplina (no disciplina impuesta).
Trabajo centrado en el desarrollo de lo comprometido Información, transparencia y visibilidad
del desarrollo del proyecto.
¿Qué ganamos con la metodología Scrum?
Los beneficios son amplios y repercuten en el equipo, en los Stakeholders y en la organización en su
conjunto.
Se fomenta el trabajo en equipo, focalizando todos los esfuerzos en alcanzar un objetivo común.
Se trata de un modelo basado en la auto-disciplina y la auto-gestión, lo que repercute
positivamente en la responsabilidad. Respecto al aspecto comunicativo, esta metodología
fomenta la comunicación entre los distintos miembros del equipo.
Los Stakeholders tienen un mayor control y transparencia sobre el proyecto, permitiendo una
mejor organización. El cliente puede hacer seguimiento más cercano de lo que pasa, sin tener que
esperar a un resultado final que no le convenza. Con las metas intermedias se minimizan riesgos.
En definitiva, la adopción de estas buenas prácticas permite reducir el tiempo de desarrollo de
productos, más capacidad de adaptación y flexibilidad frente a un entorno y unos requisitos
cambiantes aumentando el valor que se aporta a los clientes.

HERRAMIENTAS QUE UTILIZA LA METODOLOGÍA SCRUM

El gráfico de producto o burn-up: muestra en un vistazo el plan general de desarrollo del
producto. A partir de la velocidad del equipo y las estimaciones de trabajo previstas en la pila del
producto, representa las fechas o sprints en los que previsiblemente se irán terminando las
diferentes versiones.

Gráfico de producto o burn-up

El gráfico de avance o burn-down: es una herramienta ágil que monitoriza el ritmo de trabajo
(normalmente de un sprint). En el eje vertical de un diagrama cartesiano representa el trabajo
pendiente a lo largo del tiempo del sprint (eje horizontal).Las desviaciones sobre, o bajo la línea
diagonal que representaría el avance ideal del sprint alertan de formatemprana de desviaciones
sobre el ritmo de desarrollo previsto.

Gráfico de avance o burn-dow

La estimación de póquer: es una práctica ágil para reducir las dificultades habituales en las
reuniones de trabajo para planificación por juicio de expertos.En ella los participantes emplean un
juego de cartas para concretar las unidades de esfuerzo que estiman para cada tarea.
Hay dos variantes:

Natural: los participantes pueden estimar el esfuerzo con la cifra exacta que crean más
adecuada.
Fibonacci: las estimaciones solo se pueden realizar empleando números de la sucesión de
Fibonacci. En cada caso, el juego de cartas empleado tiene la numeración apropiada.

VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA SCRUM

VENTAJAS:
Programación organizada.
Menor taza de errores.
Satisfacción del programador.

DESVENTAJAS:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.

La estimación de póquer

COMPARATIVAS DE LAS METODOLOGÍAS SCRUM y XP

SEMEJANZAS
Es un Agile Manifiesto.
Existen una Interacción de Usuario a Usuario.
Realizan los Proyectos en un Corto Periodo de Tiempo.
Trabajan en Equipo.
DIFERENCIAS( CUADRO DE COMPARACION)

SCRUM
Las iteraciones de entregas son de 2 a 4
semanas.
Lo que se termina, funciona y este bien, se
aparta y ya no se toca.
Cada miembro del Scrum Team trabaja de forma
individual.
El Scrum Team trata de seguir el orden de
prioridad q marca el Product Owner en el Sprint
Backlog pueden ser modificadas.
Está basada en la administración del proyecto.

XP (EXTREME PROGRAMMING)
Las iteraciones de entrega son a 1 a 3
semanas.
Las tareas q se van entregando a los
diferentes clientes son susceptibles a las
modificaciones.
Los miembros del programan en pareja en
un proyecto XP.
El equipo de desarrollo sigue estrictamente
el orden de prioridad de las tareas definidas
por el cliente.
Se centra más en la propia programación o
creación del producto.

LINKOGRAFIAS
http://procesosoftware.wikispaces.com/Modelo+Incremental

http://jorgetrejos.blogspot.com/2010/08/modelo-evolutivo.html

http://es.wikipedia.org/wiki/Desarrollo_en_espiral

http://jorgetrejos.blogspot.com/2010/08/modelo-en-espiral.html

falta Modelos recientes y 4G