Portada

Instituto Tecnológico Superior de Jerez 
     

Ing. Sistemas Computacionales

            Ingeniería de software
               

 6to semestre

Blog Metodologias de desarrollo de software

Nombre: Lucero Acuña de la Torre.

No. Control: 13070011

Docente: ISC Ricardo Saldívar Quezada.

Introducción

Una metodología es una colección de procedimientos, técnicas, herramientas, formada por fases, cada una de las cuales se puede dividir en sub-fases, que guiarán a los desarrolladores de sistemas a elegir las técnicas más apropiadas encada momento del proyecto y también a planificarlo, gestionarlo, controlarlo y evaluarlo. 

Existen 2 tipos de metodologías:

1)  Metodologías clásicas

Son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.

      2)  Metodologías Ágiles.

Serie de técnicas para la gestión de proyectos que han surgido como competencia a los métodos clásicos.

La constante innovación tecnológica hace que cada vez sea necesaria la aplicación de nuevas metodologías adaptadas a los nuevos tiempos y, sin embargo, siguen figurando en los libros de texto viejas metodologías pensadas para viejos problemas, cosa que no sería necesariamente malo si las nuevas metodologías tuviesen también su lugar, pero a menudo no es así.
Obviamente, las metodologías modernas responden a problemas y necesidades más actuales.

Metodologías Clásicas

Cascada

También llamado Lineal secuencial, es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.

Es el más básico de todos los modelos y ha servido como bloque de construcción para los demás paradigmas de ciclo de vida.

Fases:

1. 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.
2. 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.
3. 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. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.
4. Codificación: el diseño debe traducirse en una forma legible para la maquina. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente.
5. Prueba: una vez que se ha generado el código comienza la prueba del programa. 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.
6. Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debidos a que se haya encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos) o a que el cliente requiera ampliaciones funcionales o del rendimiento.

Ventajas: 

• Sencillez.
• Organización sin mezcla de fases.
• Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
• Ayuda a minimizar los gastos de la planificación porque permite realizarla sin problemas.
• La calidad del producto resultante es alta.

Desventajas: 

• Gran dependencia en los requerimientos iniciales.
• Difícilmente un cliente va ha establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso en este modelo, ya que es muy restrictivo y no permite movilizarse entre fases.
• El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos serán entregados a tiempo.
• Inicio de la codificación muy tarde en el ciclo de vida del proyecto.
• Es difícil incorporar nuevas cosas si se quiere actualizar.

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 adquirirexperiencia 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(aplicados repetidamente) con la filosofía interactiva de construcción de prototipos. Aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. 

Es decir, bajo este modelo se entrega software “por partes funcionales mas pequeñas”, pero re-utilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.

El proceso se divide en 4 partes:

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

El modelo incremental aplica secuencias lineales de forma escalonada mientras procesa el tiempo en calendario. Cada secuencia lineal produce un incremento del software. el primer incremento generalmente es un producto esencial denominado núcleo.

Este modelo es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.

Características:

• Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.
• El usuario se involucra mas.
• Dificil de evaluar el costo total.
• Dificil 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 positivo.
• En lugar de entrega del sistema en una sola entrega, el desarrollo y la entrega están fracturados bajo incrementos, con cada incremento que entrega parte dela funcionalidad requerida.

Ventajas:

• Los clientes no tienen que esperar hasta que el sistema se entregue completamente para comenzar a hacer uso de él.
• Los clientes pueden usar los incrementos iniciales como prototipo para precisarlos requerimientos posteriores del sistema.
• Minimización del riesgo de falla en el proyecto porque los errores se van corrigiendo progresivamente. 
• El resultado puede ser muy positivo.
• 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.
• 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.
• Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo.
• Riesgos largos y complejos.
•  Pueden aumentar el coste debido a las pruebas.
•  Los errores en los requisitos se detectan tarde. 

Evolutiva

Esta metodología fue propuesto por Mills en 1980.Surge porque en los primeros desarrollos se podía esperar largo tiempo hasta que el software estuviese listo.

Permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado. Se asume que NO todos los requerimientos son conocidos desde el primer momento.

La metodología consiste en el desarrollo de n iteraciones:

1) Iteración

Se desarrolla la primera versión, que recoge los requisitos conocidos.

2) Iteración

Los usuarios utilizan el software desarrollado, generándose una nueva lista de requerimientos, con la que se desarrolla una nueva versión en la siguiente fase y así sucesivamente.

El usuario ve la materialización del proyecto más rápido que si hubiera que hacer un estudio largo para concretar las especificaciones. Además, puede modificar/añadir requerimientos sin afectar al proyecto y conseguir algo que se ajuste mejor a sus necesidades. 

Existen dos 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.
• Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.
• Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.
• Hay que implicar a los usuarios.

Desventajas: 

• Es difícil predecir el coste y duración de un proyecto, por lo que es conveniente limitar el número de fases, recursos y plazos si es un proyecto con principio y fin.
• Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.
• Hay que mantener muy bien la documentación del proyecto para facilitar el control de versiones y su mantenimiento
• Puede resultar costoso si hay que reiniciar el desarrollo.

Espiral

El creador del modelo en espiral fue Barry Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software.

Es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal y secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

El modelo espiral tuvo varias modificaciones que son:

   1.  Modelo Original de Boehm.

Cada vuelta se divide en 4 sectores: 

• Planeación : determinación de los objetivos, alternativas y restricciones
• Análisis de riesgo : análisis de alternativas e identificación/resolución de riesgos
• Ingeniería : desarrollo del producto hasta "el siguiente nivel".
• Evaluación : valoración por parte del cliente de los resultados obtenidos  El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez más completas. Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente de los resultados del software.

2.     Modelo Típico de Seis Regiones.

• Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
• Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
• Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
• Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
• Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
• Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.

3.    Modelo WINWIN.

                                               

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:

• Identificación del sistema o subsistemas clave de los directivos.
• Determinación de las condiciones de victoria de los directivos.
• Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados

Ventajas: 

• El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. 
• Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos. 
• El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. 
• El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. 
• En la utilización de grandes sistemas a doblado la productividad.

Desventajas:

• Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
• Genera mucho tiempo en el desarrollo del sistema.
• Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
• Modelo costoso.
• Requiere experiencia en la identificación de riesgos.

Prototipo

Cuando el cliente tiene una necesidad legitima, pero está desorientado sobre los detalle, el primer paso es desarrollar un prototipo.

El prototipo es una versión funcional de un sistema de información o de parte de éste, pero su propósito es el de servir de modelo preliminar.

Una vez en operación, el prototipo se refinará más aún hasta que cumpla con precisión los requerimientos de los usuarios. Una vez finalizado el diseño, el prototipo se puede convertir en un sistema en producción refinado.

La creación de prototipos consiste en construir rápida y económicamente un sistema experimental para que lo evalúen los usuarios finales.

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 necesita hacer.

Lo ideal seria que el prototipo sirviera como mecanismo para identificar los requisitos de software.

Etapas: 

Características:

• El prototipo funcional evolutivo desarrolla un comportamiento que satisface los requisitos y necesidades que se han entendido claramente. Realiza por tanto, un proceso real de datos, para contrastarlo con el usuario.
• Se va modificando y desarrollando sobre la marcha, según las apreciaciones del cliente. Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el software está constantemente variando, pero, a la larga, genera un producto más seguro, en cuanto a la satisfacción de las necesidades del cliente.

Ciclo de vida:

Ventajas:

• Útil cuando los requerimientos son inciertos o cuando la interfaz del usuario final es muy importante.
• Promueve la participación del usuario.
• Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
• También ofrece un mejor enfoque cuando el responsable del desarrollo de software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-maquina.
• Se puede reutilizar el código.
• Ayuda al desarrollo de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.

Desventajas: 

• Impropio para sistemas complejos y grandes.
• Puede omitir pasos en el análisis, la documentación y las pruebas.
• El usuario quiere empezar a trabajar desde el primer momento con el prototipo para
  solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el
  producto.

_________________________________________________________________________

Bibliografia: 

http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html

http://www.ecured.cu/Modelo_en_cascada

https://procesosoftware.wikispaces.com/Modelo+Incremental

http://ingenieria.uatx.mx/labastida/files/2013/01/Modelo-Incremental.pdf

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

http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarrollo%20software.pdf

 http://sofware1nathalygrijalva.blogspot.mx/2012/10/modelo-espiral.html

http://es.geocities.com/modeloespiral/definicion.htm

http://148.202.148.5/cursos/cc321/fundamentos/unidad1/espiral.htm

https://books.google.com.mx/books?id=KD8ZZ66PF-gC&pg=PA395&dq=metodolog%C3%ADa+prototipo&hl=es&sa=X&ved=0ahUKEwiihPyq253LAhUW32MKHTQcCQEQ6AEILzAC#v=onepage&q=metodolog%C3%ADa%20prototipo&f=false

_________________________________________________________________________                            

Metodologias Ágiles

Desarrollo basado en competencia

Proceso que enfatiza el diseño y construcción de equipo basado en sistemas, usando software de "componentes" re-utilizable.

El desarrollo basado en componentes está cambiando el camino largo de software.

"Compra, no construyas".

¿Para que es?

Rama de ingeniería de software la cual enfatiza la separación de preocupaciones respecto a las amplias disponibilidades validas a lo largo de sus sistema de software dado.

Objetivo

Producir una amplia calidad de software de acuerdo a los beneficios de corto y largo plazo para el sistema.

Los componentes pueden producir eventos o consumirlos y pueden ser usados por eventos dirigidos a arquitecturas.

Caracteristicas

• Reducción de costos y tiempo de construcción a largo plazo y sistemas complejos.
• Mejora de software.
• Detección de defectos dentro del sistema.
  
  

Proceso unificado

El proceso unificado  (UP, o Unified Development Process) es un tipo de metodología tradicional empleada en el desarrollo de software. Es una versión libre y abierta (no propietaria) del proceso iterativo e incremental de ingeniería de software propuesto por Jacobson, Booch y Rumbaugh  en su libro El proceso unificado de desarrollo de software, publicado por Addisson-Wesley en 1999. El lenguaje para especificar y diagramar en el UP es UML, por lo cual puede apoyarse en cualquier herramienta que soporte UML.

Cada fase representa un ciclo de desarrollo en la vida de un producto de software.

1. Inicio: Tiene por finalidad definir la visión, los objetivos y el alcance del proyecto, tanto desde el punto de vista funcional como del técnico, obteniéndose como uno de los principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto. 
2. Elaboración: Tiene como principal finalidad completar el análisis de los casos de uso y definir la arquitectura del sistema, además se obtiene una aplicación ejecutable que responde a los casos de uso que la comprometen. A pesar de que se desarrolla a profundidad una parte del sistema, las decisiones sobre la arquitectura se hacen sobre la base de la comprensión del sistema completo y los requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido. 
3. Construcción: Está compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto.Los cambios en los requerimientos no se incorporan hasta el inicio de la próxima iteración.
4. Transición: Inicia con una versión “beta” del sistema y culmina con el sistema en fase de producción.

Características:

• Está dirigido por casos de uso.
• Está centrado en la arquitectura (es decir, en una solución de conjunto.
• Tiene un ciclo de vida iterativo incremental.

Ventaja: 

Su uso es libre (sin condiciones).Hay excelentes textos, que explican la aplicación de este proceso paso a paso.

Desventaja:

Es necesario “aterrizar” los conceptos, lo cual puede resultar un poco difícil para quien no tenga experiencia en el uso de procesos de ingeniería de software.

Ingeniería Web

La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la www.

La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta vía.

Internet se volvió más que una diversión y empezó a ser tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la Web se volviera como un desafío para los (Ingeniería del software) ingenieros del software, a raíz de esto se crearon enfoques disciplinados, sistemáticos y metodologías donde tuvieron en cuenta aspectos específicos de este nuevo medio.

Uno de los aspectos más tenidos en cuenta, en el desarrollo de sitios web es sin duda alguna el diseño gráfico y la organización estructural del contenido. En la actualidad la web está sufriendo grandes cambios, que han obligado a expertos en el tema a utilizar herramientas y técnicas basadas en la ingeniería del software, para poder garantizar el buen funcionamiento y administración de los sitios web. ´

Caracteristicas:

• Diseño de procesos de negocio para aplicaciones web.
• Herramientas CASE para aplicaciones web.
• Generación de código para aplicaciones web.
• Desarrollo web colaborativo.
• Pruebas de rendimiento de aplicaciones basadas en web.
• Control de calidad y pruebas de sistemas.
• Ingeniería de requisitos para aplicaciones web.
• Accesibilidad para la web.
• Metodologías de diseño web.
• Diseño de interfaces de usuario.

Ventajas:

•  Es de fácil uso.
• Permite la comunicación rápida y directa con una o varias personas que se encuentre en cualquier parte del mundo, ayudando de esta manera en las TICs
• Desarrollo de diferentes proyectos y propuestas para dar a conocer dichos proyectos a traves de la red.
• Ayuda en el proceso de globalizacion de las empresas, ya que permite contactar diferentes entidades y personas en el mundo sin altos costos.
• Crear publicidad para que los clientes puedan acceder a productos y servicios y tengan información actualizada de ellos.
• Creación de ventaja competitiva, ya que la empresa o entidad se encontraría a la vanguardia de la tecnología.

  

Desventajas

•  No posee muchas funcionalidades para la empresa. solo suple necesidades de comunicación.
• No ofrece diversidad de opciones

Fases:

• Análisis de Requisitos: Fija los requisitos funcionales de la aplicación Web para reflejarlos en un modelo de casos de uso.
• Diseño Conceptual: Materializado en un modelo de dominio, considerando los requisitos reflejados en los casos de uso.
• Diseño Navegacional: Muestra la forma de navegar ante el espacio de navegación.
• Diseño de Presentación: Representa las vistas del interfaz del usuario mediante modelos estándares de interacción UML.

Desarrollo ágil

¿Que es?

Es la combinación filosófica con lineamientos de desarrollo.
La filosofía pone énfasis en la satisfacción del cliente y en la entrega rápida de software.

Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados. 

El proceso ágil usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incoporando los cambios continuamente.

¿Quien lo hace?

Ingeniería de software (Gerentes, clientes, usuario final, etc.).

¿Porque es importante?

Contiene un ambiente moderno que genera sistemas basados en computadora y productos de software que evolucionan de forma rápida y sencilla.

Fases

• Comunicación
• Planeación
• Modelado
• Construcción
• Despliegue

El trabajo estará bien hecho si el equipo ágil concuerda que el proceso funciona y en que produce incrementos de software utilizables que satisfagan al cliente.

Características:

• Proceso iterativo e incremental.
• Mitigación del riesgo mediante iteraciones fijas.
• Mejora continua.
• Calidad desde el primer día.
• Priorización de requerimientos de acuerdo a su valor.
• Equipos dedicados y auto-gestionados.
• Colaboración continua con el cliente.
• Incorporar al cambio.
• Prácticas de desarrollo modernas.

SCRUM

Proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

Características:

• Equipos autodirigidos.
• 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.

Roles y responsabilidades

Scrum clasifica a todas las personas que intervienen o tienen interés en el desarrollo del proyecto en: propietario del producto, equipo.

Los tres primeros grupos (propietario, equipo y gestor) son los responsables del proyecto, los que según la comparación siguiente (y sin connotaciones peyorativas) serían los “cerdos”; mientras que el resto de interesados serían las gallinas.

Cerdos y gallinas.

Esta metáfora ilustra de forma muy gráfica la diferencia de implicación en el proyecto entre ambos grupos:

Una gallina y un cerdo paseaban por la carretera.

La gallina dijo al cerdo: “Quieres abrir un restaurante conmigo”.

El cerdo consideró la propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”.

La gallina respondió: “Huevos con jamón”.

El cerdo se detuvo, hizo una pausa y contestó:

“Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido, mientras que tú estarías sólo implicada”.

Roles Cerdo

Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamón en el plato".

Product Owner

El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Equipo

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc).

Roles "Gallina"

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Usuarios

Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie ¿Hace ruido? Aqui la definicion sería Si el software no es usado ¿fue alguna vez escrito?.

Stakeholders (Clientes, Proveedores).

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint.

Managers

Es la gente que establece el ambiente para el desarrollo del producto.

Extreme programing

Metodología de desarrollo ágil, una de las más exitosas en tiempo reciente. Su autor principal es Kent Beck, quien eligió algunas características de otras metodologías y las relacionó de forma que cada una complementara a la otra.

Así, la XP se puede definir como un conjunto de pasos de diversas metodologías, acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso común, para realizar un desarrollo más agradable y sencillo.

Esta metodología tiene como base la simplicidad y como objetivo principal la satisfacción del cliente; para lograrlo se deben tomar en cuenta cuatro valores fundamentales:

_{Comunicación}

_{Es muy importante que haya una comunicación constante con el cliente y dentro de todo el equipo de trabajo, de esto dependerá que el desarrollo se lleve a cabo de una manera sencilla, entendible y que se entregue al cliente lo que necesita.}

_Simplicidad

_{En la XP se refiere que ante todo y sin importar qué funcionalidad requiera el usuario en su sistema, éste debe ser fácil. El diseño debe ser sencillo y amigable al usuario, el código debe ser simple y entendible, programando sólo lo necesario y lo que se utilizará.}

_{Retroalimentación}

_{Es la comunicación constante entre el desarrollador y el usuario.}

_Coraje

_{Se refiere a la valentía que se debe tener al modificar o eliminar el código que se realizó con tanto esfuerzo; el desarrollador debe saber cuando el código que desarrolló no es útil en el sistema y, por lo mismo, debe ser eliminado. También se refiere a tener la persistencia para resolver los errores en la programación.}

_{Dentro de la programación extrema se tiene 12 principios que llevan o guían el desarrollo con esta metodología:}

1. El principio de pruebas
2. Proceso de planificación
3. El cliente en el lugar
4. Programación en parejas
5. Integración continua
6. Refactorización
7. Entregas pequeñas
8. Diseño simple
9. Metáfora
10. Propiedad colectiva del código
11. Estándar de codificación
12. La semana de 40 horas

Caracteristicas:

• 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

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.

______________________________________________________

Bibliografia:

http://fundamentosoftware.blogspot.mx/p/proceso-unificado-de-desarrollo.html

https://mdjesus.wordpress.com/2010/05/19/84/

http://ingenieriaweb2584.blogspot.mx/2013/04/metodologia-ingenieria-web.html

http://www.dosideas.com/wiki/Desarrollo_Agil_De_Software

https://procesosdesoftware.wikispaces.com/METODOLOGIA+SCRUM

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Rational+Team+Concert+for+Scrum+Projects/page/SCRUM+como+metodolog%C3%ADa

http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html

http://www.uv.mx/universo/486/infgral/infgral_15.html

_________________________________________________________________________