DESARROLLO AGIL DE SOFTWARE

DESARROLLO AGIL DE SOFTWARE
DEFINICION
Se entiende como desarrollo ágil de software a un paradigma de desarrollo de
software basado en procesos agiles. Los procesos agiles de desarrollo de software
conocidos antes como metodologías livianas, intentan evitar tortuosos y burocráticos
caminos de la metodologías tradicionales enfocándose en la gente y los resultados.
Es un marco de trabajo conceptual de la ingeniería de software que promueve
iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen
muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando
software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo
se denomina una iteración, la cual debe durar de una a cuatro semanas, cada iteración
del iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño,
codificación, revisión y documentación. Una iteración no debe agregar demasiada
funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es
tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el
equipo vuelve a evaluar las prioridades del proyecto.
POLITICAS
Los métodos agiles enfatizan las comunicaciones cara a cara en vez de la
documentación.la mayoría de los equipos ágiles están localizados en una simple
oficina abierta, a veces llamadas plataformas de lanzamiento , la oficina debe incluir
revisores, escritores de documentación y ayuda, diseñadores de iteración y directores
de proyecto. Los métodos agiles también enfatizan que el software funcional es la
primera medida del progreso. Combinados con la preferencia por las comunicaciones
cara a cara, generalmente los métodos agiles son criticados y tratados como
“indisciplinados” por la falta de documentación técnica.
PROGRAMACIÓN EXTREMA
DEFINICION
Es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer
libro sobre la materia en 1999, Es el mas destacado de los procesos agiles del
desarrollo de software. Al igual que estos, la programación extrema se diferencia de
las metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Los defensores de xp consideran que los
cambios de requisitos sobre la marcha son un aspecto normal, inevitable e incluso
deseable del desarrollo de proyectos. Creen que adaptarse a los cambios de requisitos
en cualquier punto de la vida del proyecto, es una aproximación mejor y más realista
que intentar definir todos los requisitos el comienzo del proyecto e invertir esfuerzos
después en controlar los cambios en los requisitos.
Se puede considerar la programación extrema como la adopción de las mejores
metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto y aplicarlo de manera dinámica durante el ciclo de vida del software.
POLITICA
Los principios originales de la programación extrema son :
- Simplicidad
-Comunicación
-Retroalimentación
-coraje
SIMPLICIDAD
Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. con las
constantes revisiones del código por parte de los desarrolladores y su exponencial
crecimiento y mejoramiento se hace necesario la refactorización del código es decir
para la reestructuración del código fuente, alterando su estructura interna sin modificar
su comportamiento externo. Permitiendo de esta manera mantener el código simple a
medida que crece, se aplica este principio también en la documentación del código en
cuanto a sus comentarios para que este permanezca autodocumentado.
COMUNICACIÓN
La comunicación se realiza de diferentes formas. Para los programadores el código
comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse
para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios
ya que éstos últimos pronto quedan desfasados con el código a medida que es
modificado.
RETROALIMENTACION
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se
conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran
resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos
y ayuda a los programadores a centrarse en lo que es más importante. El código
también es una fuente de retroalimentación gracias a las herramientas de desarrollo.
CORAJE O VALENTIA
Se requiere coraje para implementar las características que el cliente quiere ahora sin
caer en la tentación de optar por un enfoque más flexible que permita futuras
modificaciones.
RESPETO
Los miembros respetan su trabajo porque siempre están luchando por la alta calidad
en el producto y buscando el diseño óptimo o más eficiente para la solución a través
de la refactorización del código.
DESARROLLO ADAPTATIVO DE SOFTWARE
DEFINICION
El desarrollo adaptativo de software (DAS)fue propuesto por jim highsmith como una
metodología para desarrollar software y sistemas muy complejos. El se centra en la
colaboración humana y la organización en equipo.
El ciclo de vida del DAS se conforma de tres fases; especulación, colaboración y
aprendizaje.
En la fase de especulación se inicia el desarrollo del proyecto. En ella se utiliza
información como la misión del cliente, las restricciones del proyecto y los requisitos
básicos para definir el conjunto de ciclos en el que se harán los incrementos del
software.
Para la fase de colaboración se busca que el equipo no solo se comunique o se
encuentren completamente integrados, se desea que exista confianza , donde se
pueda realizar críticas constructivas y ayudar si resentimientos, trabajar tan duro como
sea posible, comunicar de forma oportuna los problemas que se presenten para tomar
acciones efectivas y poseer un conjunto de actitudes que contribuyan al trabajo que se
encuentren realizando.
El aprendizaje permite mejorar el entendimiento real sobre la tecnología, los procesos
utlizados y el proyecto.El parendizaje individual permite al equipo tener mayor
posibilidad de éxito.
MODELO AGIL
Es una metodología basada en la práctica para modelado efectivo de sistemas de
software. La metodología AM es una colección de prácticas, guiadas por principios y
valores que pueden ser aplicados por profesionales de software en el día a día.
MA no es un proceso prescriptivo, ni define procedimientos detallados de cómo crear
un tipo de modelo dado. En lugar de eso, sugiere practicas para ser modelador
efectivo.es “suave al tacto “no es duro ni rápido, piense en MA como un arte, no una
ciencia.
POLITICA
-
Asumir simplicidad
Permitir el siguiente esfuerzo es el objetivo secundario
Cambio incremental
Maximizar la inversión de las partes interesadas en el proyecto
Modelar con un propósito
Múltiples modelos
Trabajo de calidad
Rápida retroalimentación
El software es el objetivo primario
El contenido es mas importante que la presentación
Adaptación local
MÉTODO DE DESARROLLO DE SISTEMAS DINAMICOS(MDSD)
El método de sistemas dinámicos (MDSD)permite la construcción de sistemas con
restricción de tiempo , realizando prototipos incrementales en un ambiente de proyecto
controlado .
Este modelo se compone de dos actividades que se realizan primero y consecuente
con ellas se realizan tres ciclos de vida adicionales, las dos actividades primarias son
el estudio de factibilidad en donde se establecen los requisitos básicos del negocio y
las restricciones asociadas a la metodología para evaluar si las misma puede ser
realizada bajo el esquema MDSD y la segunda es el estudio del negocio donde se
establecen los requerimientos funcionales y la arquitectura básica de la aplicación.
La iteración de modelo funcional , se realizan diversos prototipos incrementales que
permiten mostrar al cliente la funcionalidad del sistema. Con cada iteración se
recopilan requisitos adicionales que pueden ir siendo incluidos en el prototipo
La iteración de construcción y diseño , contribuye a agregar el valor operativo del
negocio para los usuarios, a través de la construcción de prototipos durante la
iteración del modelo funcional.
Implementación, los prototipos que vayan surgiendo de la fase de construcción y
diseño, se iran colocando en ambientes operativos(prototipos adicionales).
MELE
Es un modelo ágil de proceso desarrollado por Jeff Sutherland y su equipo a los
comienzos de la década de los 90(la palabra melé proviene de una palabra),Tambien
es conocido con el nombre de Scrum.
Posee los siguientes principios que van en concordancia con los métodos de
desarrollo agiles:
-
Equipos auto-dirigidos
Una vez elegida una tarea , no se agrega trabajo extra. En caso que se
agregue algo, se recomienda quitar alguna otra cosa
Iteraciones de 30 días, aunque se pueden realizar con más frecuencia.
Demostración a participantes externos una vez culminada cada iteración
Al principio de cada iteración , planeamiento adaptativo guiado por el cliente
EL CICLO DE VIDA DEL MELÉ
Planeamiento:El propósito es establecer la visión, definir expectativas y asegurarse la
financiación, las actividades son la escritura de la visión, el presupuesto, el registro de
acumulación o retraso del producto inicial y los ítems estimados , así como la
arquitectura de alto nivel, el diseño exploratorio y los prototipos.
Montaje: El propósito es identificar mas requerimientos y priorizar las tareas para la
primera iteración.las actividades son planificación , diseño exploratorio y prototipos.
Desarrollo : El propósito es implementar un sistema listo para entrega en una seria de
iteraciones de treinta días llamadas “corridas”.Las actividades son un encuentro de
planeamiento de corridas de cada iteración, la definición de registro de acumulación de
corridas y los estimados y encuentros diarios.
Liberación:El propósito es el despliegue operacional . las actividades ,
documentación, enfrentamiento , mercadeo y venta
METODOLOGÍA RUP
El Proceso Unificado de Racional (Rational Unified Process en inglés, habitualmente
resumido como RUP) es un proceso de desarrollo de software y junto con 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 no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software desarrollado por Rational, hoy
propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y
descripciones de las diversas actividades. Está incluido en el Rational Method
Composer (RMC), que permite la personalización de acuerdo a necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso
Unificado, y una especificación más detallada, el Rational Unified Process, que se
vendiera como producto independiente.
POLITICA
El RUP está basado en 6 principios clave que son:
Adaptar el proces
El proceso deberá adaptarse a las características propias del proyecto u organización. El
tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en
su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un
area subformal.
Equilibrar prioridades
Los requerimientos de los diversos participantes pueden ser diferentes, contradictorios o
disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos
de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el
futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada
iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y
se refina la dirección del proyecto así como también los riesgos involucrados
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe
haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones,
planes, resultados,etc.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del
software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos.
Esto evita que los ingenieros de software vayan directamente de los requisitos a la
codificación de software a la medida del cliente, sin saber con certeza qué codificar para
satisfacer de la mejor manera los requerimientos y sin comenzar desde un principio
pensando en la reutilización del código. Un alto nivel de abstracción también permite
discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden
acompañar por las representaciones visuales de la arquitectura, por ejemplo con el
lenguaje UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los
aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente.