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



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.



Í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


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.



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.



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.



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.

http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_para_el_desarrollo_de_software#Referencias



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



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.



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.



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.

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

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



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.



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



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



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.



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:



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



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.



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.



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

http://procesosdesoftware.wikispaces.com/METODOLOGIA+XP



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.



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.



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.



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.



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.



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

Software

Transcript of Metodologias para el desarrollo del software