Algunas practicas:
Material extra:
viernes, 29 de noviembre de 2013
4.3 Variables de programación extrema
Las cuatro variables.
XP define cuatro
variables para proyectos de software: coste, tiempo, calidad y ámbito.
Además de estas
cuatro variables, Beck propone que sólo tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes),
mientras que el valor de la cuarta variable debe ser establecido por los programadores en
función de las otras tres.
Pongámonos en un
episodio diario de desarrollo.
El jefe de proyecto:
“Quiero estos requisitos realizados para el día 1 de mes próximo, con lo que contáis con el equipo actual. ¡Ah ya sabéis que
la calidad es lo primero!”
-Todos sabemos qué es
lo primero que salta por la ventana en estos casos: “la calidad”, ¿ Por qué ? Porqué nadie es capaz de trabajar bien cuando se
le somete a mucha presión.
- XP nos propone que
juguemos todas las partes implicadas en el proyecto hasta que el valor que alcancen las cuatro variables sea el correcto para
todas las partes: “Si quieres mas calidad en menos tiempo tendrás que aumentar el equipo e
incrementar el coste”.
- Además con el
agravante de que estas cuatro variables no guardan una relación tan directa como en principio pueda parecer. El incremento del
número de programadores no repercutirá de manera lineal en el tiempo de desarrollo del
proyecto, siendo de todos conocido el dicho: “nueve mujeres no pueden tener un hijo en un mes”.
- Con la calidad suele
suceder un fenómeno extraño: frecuentemente un proyecto que tratemos de aumentar la calidad conduce a que el proyecto
pueda realizarse en menos tiempo, siempre con unos márgenes obviamente. Es verdad que cuando
un equipo de desarrollo se acostumbra a realizar pruebas intensivas, se siguen
estándares de codificación, poco a poco
se comenzara a andar mas rápido y mas seguro, por tanto mas
preparados para futuros cambios, sin estrés y así sucesivamente.
-Frente a esto existe
la tentación de entregar el trabajo mas rápido, por tanto probar menos, codificar más rápido y peor, sin hacer planteamientos
maduros, esto repercutirá en la confianza de nuestros clientes, al entregarle trabajos con
fallos. Esta es una apuesta a muy corto plazo y suele ser una invitación al desastre, conduce
a la desmoralización del equipo, y con ello a la larga a la ralentización del proyecto y la
perdida de tiempo que habríamos conseguido en un principio.
- La cuarta variable,
el ámbito del proyecto, suele ser conveniente que sea establecida por el equipo de desarrollo. Es una variable muy importante
que nos va a decir donde vamos a llegar con nuestro software, que problemas vamos a resolver
y cuales vamos a dejar para siguientes versiones. Cuantas veces hemos escuchado “Los
clientes no nos pueden decir lo que quieren. Cuando le damos lo que nos piden no les gusta”.
Y es que los requisitos nunca son claros al principio y el mismo desarrollo del software
hace cambiar los requisitos. Por tanto el ámbito debe de ser dúctil, podremos jugar con el, si el
tiempo para el lanzamiento es limitado, siempre habrá cosas que pudramos diferir para
siguientes versiones. Por tanto implementaremos primero los requisitos mas
importantes para el cliente, de forma que si tenemos que dejar algo para después que sea menos
importante que las que ya incorpore un sistema.
Material extra:
http://www.willydev.net/descargas/prev/ExplicaXP.pdf
Material extra:
http://www.willydev.net/descargas/prev/ExplicaXP.pdf
4.2 Ciclo de vida de la XP
El ciclo de vida
El ciclo de vida de XP se enfatiza en el carácter iterativo
e incremental del desarrollo, una iteración de desarrollo es un período de tiempo en el que se
realiza un conjunto de funcionalidades determinadas que en el caso de XP
corresponden a un conjunto de historias de usuarios.
Las iteraciones son relativamente cortas ya que se piensa
que entre más rápido se le entreguen desarrollos al cliente, más retroalimentación se
va a obtener y esto va a representar una mejor calidad del producto a largo plazo.
Existe una fase de análisis inicial orientada a programar las iteraciones de desarrollo
y cada iteración incluye diseño, codificación y pruebas, fases superpuestas de tal
manera que no se separen en el
tiempo.
fases:
Fase de Exploración
En esta fase, los clientes plantean a grandes rasgos las
historias de usuario que son de interés para la primera entrega del producto. Al mismo
tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas
que se utilizarán en el proyecto.
Se prueba la tecnología y se exploran las posibilidades de
la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de
pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los
programadores con la tecnología.
Fase del planeamiento
Se priorizan las historias de usuario y se acuerda el
alcance del release. Los
programadores estiman cuánto esfuerzo requiere cada historia
y a partir de allí se define el cronograma. La duración del cronograma del primer release
no excede normalmente dos meses.
La fase de planeamiento toma un par de días. Se deben
incluir varias iteraciones para lograr un release. El cronograma fijado en la etapa de
planeamiento se realiza a un número de iteraciones, cada una toma de una a cuatro semanas
en ejecución.
La primera iteración crea un sistema con la arquitectura del
sistema completo. Esto es alcanzado seleccionando las historias que harán cumplir la
construcción de la estructura
para el sistema completo. El cliente decide las historias
que se seleccionarán para cada iteración. Las pruebas funcionales creadas por el cliente se
ejecutan al final de cada iteración. Al final de la última iteración el sistema esta
listo para producción.
Planificación
Fase de producción
Requiere prueba y comprobación extra del funcionamiento del
sistema antes de que éste se pueda liberar al cliente. En esta fase, los nuevos
cambios pueden todavía ser encontrados y debe tomarse la decisión de si se incluyen o
no en el release actual. Durante esta fase, las iteraciones pueden ser aceleradas de
una a tres semanas. Las ideas y las sugerencias pospuestas se documentan para
una puesta en práctica posterior por ejemplo en la fase de mantenimiento. Después
de que se realice el primer realse productivo para uso del cliente, el proyecto de Xp
debe mantener el funcionamiento del sistema mientras que realiza nuevas
iteraciones.
Fase de mantenimiento
Requiere de un mayor esfuerzo para satisfacer también las
tareas del cliente. Así, la velocidad del desarrollo puede desacelerar después de que el
sistema esté en la producción. La fase de mantenimiento puede requerir la
incorporación de nueva gente y cambiar la estructura del equipo.
Fase de muerte
Ocurre cuando el cliente no tiene más historias para ser
incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en
otros aspectos como rendimiento y confiabilidad del sistema. Se genera la
documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no
genera los beneficios esperados por el cliente o cuando no hay presupuesto para
mantenerlo.
4.1 ¿Qué es la XP?
¿Qué es la XP?
Xp forma parte del conjunto de métodos ágiles que centran
sus prioridades en las personas, no en los procesos, en la actualidad Xp se
proyecta a ser un modelo de desarrollo común, sencillo y adaptable a las
características cambiantes y exigentes de empresas y clientes, es por ello que
en este documento se presentan en forma resumida las características
principales, las actividades, las prácticas, el ciclo de vida, los artefactos y
las críticas a esta metodología recopiladas en el transcurso de la investigación.
2. INTRODUCCIÓN
Los métodos ágiles surgen como una inflexión en un momento o
contexto definido, en donde se hace necesario una renovación metodológica que
busca satisfacer la necesidad de realizar los proyectos de una forma más rápida
sin disminuir la calidad del mismo pero sí reducir documentación, pasos,
procesos y tiempo. Indistintamente en el año 2001 firman para Xp en el
manifiesto ágil Kent Beck, Ward Cinningham, Martin Fowler, James Grenning, Ron
Jeffries, Brian Marick, y Robert C. Matin, poco después y hasta hoy surge un
gran número de libros y escritos que describen los pasos para aplicar esta
metodología.
3. PROGRAMACIÓN EXTREMA XP (eXtreme Programming)
Metodología ágil basada en cuatro principios: simplicidad,
comunicación, retroalimentación y valor. Además, orientada por pruebas y
refactorización, se diseña e implementan las pruebas antes de programar la
funcionalidad, el programador crea sus propios tests de unidad.
Este método es típicamente atribuido a Kent Beck, Ron
Jeffries y Ward Cinningham. El objetivo de Xp son grupos pequeños y medianos de
construcción de software en donde los requisitos aún son muy ambiguos, cambian
rápidamente o son de alto riesgo. Xp busca la satisfacción del cliente tratando
de mantener durante todo el tiempo su confianza en el producto. Además, sugiere
que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en
el centro los programadores, en la periferia los equipos individuales). Una
ventaja del espacio abierto es el incremento en la comunicación y el
proporcionar una agenda dinámica en el entorno de cada proyecto.
4. ACTIVIDADES DE LA Xp
4.1. Codificar
Es necesario codificar y plasmar nuestras ideas a través del
código. En programación, el código expresa la interpretación del problema, así
podemos utilizar el código para comunicar, para hacer comunes las ideas, y por
tanto para aprender y mejorar.
4.2. Hacer pruebas
Las características del software que no pueden ser
demostradas mediante pruebas simplemente no existen. Las pruebas dan la
oportunidad de saber si lo implementado es lo que en realidad se tenía en
mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos
pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema,
entonces habremos acabado por completo.
4.3. Escuchar
nos menciona en una frase, "Los programadores no lo
conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan
que son interesantes. Si ellos pudieran programarse su propio software ¿para
qué nos querrían?".
Si vamos a hacer pruebas tenemos que preguntar si lo
obtenido es lo deseado, y tenemos que preguntar a quien necesita la
información. Tenemos que escuchar a nuestros clientes cuáles son los problemas
de su negocio, debemos de tener una escucha activa explicando lo que es fácil y
difícil de obtener, y la realimentación entre ambos nos ayudan a todos a
entender los problemas.
4.4. Diseñar
El diseño crea una estructura que organiza la lógica del
sistema, un buen diseño permite que el sistema crezca con cambios en un solo
lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de
desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el
diseño o malos diseños, estos deben de ser corregidos cuanto antes.
Resumiendo las actividades de Xp: Tenemos que codificar
porque sin código no hay programas, tenemos que hacer pruebas por que sin
pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque
si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para
poder codificar, probar y escuchar indefinidamente.
Unidad IV programacion extrama
La programación extrema o eXtreme Programming (XP) es una
metodología de desarrollo de la ingeniería de software formulada por Kent Beck,
autor del primer libro sobre la materia, Extreme Programming Explained: Embrace
Change (1999). Es el más destacado de los procesos ágiles de desarrollo de
software. Al igual que éstos, 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 la XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural, inevitable e incluso
deseable del desarrollo de proyectos. Creen que ser capaz de 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 al
comienzo del proyecto e invertir esfuerzos después en controlar los cambios en
los requisitos.
Características
Las características fundamentales del método son:
Desarrollo iterativo e incremental: pequeñas mejoras, unas
tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y
automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código
de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de
prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la
plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la
cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar
tests, realizado para el lenguaje de programación Smalltalk.
- Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata. Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
- Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes. Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
- Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
- Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
3.4 Principales metodologias
3.4.1 Crystal
Material esxtra:
presentacion
http://prezi.com/diwsrctestwj/copy-of-metodologia-crystal/
METODOLOGÍA CRYSTAL EN MÉTODOS
INTRODUCCIÓN
Las metodologías ágiles, se han comenzado ha desarrollar
hace muy poco tiempo, dentro de estas encontramos la Metodología Cristal la
cual identifica con colores diferentes cada método, y su elección debe ser
consecuencia del tamaño y criticidad del proyecto, de forma que los de mayor
tamaño, o aquellos en los que la presencia de errores o desbordamiento de
agendas implique consecuencias graves, deben adoptar metodologías más pesadas.
De esta forma se pretende obtener mayor rentabilidad en el desarrollo de
proyectos de software, Los métodos Crystal no prescriben prácticas concretas,
porque están en continuo cambio.
PLANTEAMIENTO
Las metodologías Ágiles, son una herramienta que nos
facilita en el desarrollo de software, De esta forma se agilizan los procesos
de construcción de proyectos. También se puede observar que por medio de estas
metodologías podemos obtener más fiabilidad y calidad en menos tiempo y con
menos costo. Estas metodologías dependen de dos factores importantes como lo
son El número de personas en el proyecto, y Las consecuencias de los errores.
Su nombre se debe a las facetas de una gema: cada faceta es otra versión del
proceso, y todas se sitúan en torno a un núcleo idéntico.
También podemos encontrar dentro de estas metodologías
ágiles la metodología llamada Clear, la cual se basa La más documentada es
Crystal Clear (CC) al igual que la Crystal Orange apto para proyectos de
duración estimada en 2 años.
Existen software basados en metodologías cristal las cuales
Integran estrechamente capacidades de diseño, modificación y visualización en
aplicaciones .NET, Java o COM. También Permitir a los usuarios finales acceder
e interactuar con los reportes a través de portales Web, dispositivos móviles y
documentos de Microsoft Office®. De esta forma podemos darnos cuenta que la
aplicación de estas metodologías son extremadamente recomendables en el buen
desarrollo de proyectos de software.
DESARROLLO
Se tiene en cuenta que Crystal da vital importancia a las
personas que componen el equipo de un proyecto, y por tanto sus puntos de
estudio son: Aspecto humano del equipo, Tamaño de un equipo (número de
componentes), Comunicación entre los componentes, Distintas políticas a seguir,
Espacio físico de trabajo. Compuesta por una características importantes como
lo son Crystal aconseja que el tamaño del equipo sea reducido (Pocos
componentes) También La mejora de la comunicación entre los miembros del equipo
del proyecto, El Mismo lugar de trabajo à Disminuye el coste de la comunicación
y Mejora individual à Mejora global del equipo, de esta forma se tienen en
cuenta las políticas de equipo “Se utilizarán políticas diferentes para equipos
diferentes” Codificación por colores de Crystal: esto Dependiendo del tamaño
del equipo.
Dentro de esta metodología podemos encontrar la FDD es un
método ágil, iterativo y adaptativo. A diferencia de otras Metodologías Ágiles,
no cubre todo el ciclo de vida sino sólo las fases de diseño y construcción y
se considera adecuado para proyectos mayores y de misión crítica. FDD no
requiere un modelo específico de proceso y se complementa con otras
metodologías. Enfatiza cuestiones de calidad y define claramente entregas tangibles
y formas de evaluación del progreso. FDD consiste en cinco procesos
secuenciales durante los cuales se diseña y construye el sistema. La parte
iterativa soporta desarrollo ágil con rápidas adaptaciones a cambios en
requisitos y necesidades del negocio. Cada fase del proceso tiene un criterio
de entrada, tareas, pruebas y un criterio de salida. Típicamente, la iteración
de un rasgo emplea de una a tres semanas. Las fases se describen a
continuación: Desarrollo de un modelo general, Construcción de la lista de
rasgos, Planeación por rasgo, Diseño por rasgo y Construcción por rasgo. Por
medio de estas metodologías podemos hacer los proyectos mas optimos y con mayor
calidad. Lo cual hace que el cliente se sienta con superior tranquilidad de
solicitar un buen desarrollo de software.
Material esxtra:
presentacion
http://prezi.com/diwsrctestwj/copy-of-metodologia-crystal/
3.4.2 Scrum
Scrum es un proceso en el que se aplican de manera regular
un conjunto de buenas prácticaspara 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 paraproyectos en entornos
complejos, donde se necesita obtener resultados pronto, donde losrequisitos son
cambiantes o poco definidos, donde la innovación, la competitividad,
laflexibilidad y la productividad son fundamentales.
El proceso
El proceso parte de la lista de objetivos/requisitos
priorizada del producto, que actúa como plan del proyecto. En esta lista el
cliente prioriza los objetivos balanceando el valor que le aportan respecto a
su coste y quedan repartidos en iteraciones y entregas. De manera regular el
cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de
inversión mediante lareplanificación de objetivos del producto, que realiza
durante la iteración con vista a las siguientes iteraciones.
Las actividades que se llevan a cabo en Scrum son las
siguientes:
Planificación de la iteración
El primer día de la iteración se realiza la reunión de
planificación de la iteración. Tiene dos partes:
Selección de requisitos (4 horas máximo). El cliente
presenta al equipo la lista de requisitos priorizada del producto o proyecto.
El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos
más prioritarios que se compromete a completar en la iteración, de manera que
puedan ser entregados si el cliente lo solicita.
Planificación de la iteración (4 horas máximo). El equipo
elabora la lista de tareas de la iteración necesarias para desarrollar los
requisitos a que se ha comprometido. La estimación de esfuerzo se hace de
manera conjunta y los miembros del equipo se auto asignan las tareas.
Material extra:
http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum.html
Material extra:
http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum.html
3.4.3 DSDM
El método de desarrollo de sistemas dinámicos (en inglés
Dynamic Systems Development Method o DSDM) es un método que provee un framework
para el desarrollo ágil de software, apoyado por su continua implicación del
usuario en un desarrollo iterativo y creciente que sea sensible a los
requerimientos cambiantes, para desarrollar un sistema que reuna las
necesidades de la empresa en tiempo y presupuesto. Es uno de un número de
métodos de desarrollo ágil de software y forma parte del alianza ágil.
DSDM fue desarrollado en el Reino Unido en los años 90 por
un consorcio de proveedores y de expertos en la materia del desarrollo de
sistemas de información (IS), el consorcio de DSDM, combinando sus experiencias
de mejores prácticas.
DSDM reconoce que los proyectos son limitados por el tiempo
y los recursos, y los planes acorde a las necesidades de la empresa. Para
alcanzar estas metas, DSDM promueve el uso del RAD con el consecuente peligro
que demasiadas esquinas estén cortadas. DSDM aplica algunos principios, roles,
y técnicas.
Las fases de DSDM son:
Estudio de Viabilidad: estudio de requerimientos (humanos,
materiales y financieros) y los problemas de la empresa o cliente.
Estudio de la Empresa: como planificar las actividades de la
empresa.
Iteracion del Modelo Funcional: plantear un modelo previo
que de solucion aceptable a la problematica, esta es la etapa de diseño.
Diseño e Iteracion de Estructura: se realiza la codificacion
de la solucion, se prueba paralelamente la calidad del producto y se documenta
el manual de usuario y tecnico.
Implementacion: entrega del producto al cliente o usuario
final.
La fase del ciclo de vida del proyecto se subdivide en 5 etapas:
estudio de viabilidad,
estudio de la empresa,
iteración del modelo funcional,
diseño e iteración de la estructura, e implementación.
3.4.4 FDD
Metodología
FDD (Feature Driven Development). Es una metodología ágil para el
desarrollo de sistemas, basado en la calidad del software, que incluye un
monitoreo constante del proyecto.
FDD fue desarrollado por Jeff De Luca y Peter Coad a
mediados de los años 90. Esta metodología se enfoca en iteraciones cortas que
permite entregas tangibles del producto en corto periodo de tiempo que como
máximo son de dos semanas.
Caracteristicas
· -No hace énfasis en la obtención de los
requerimientos sino en como se realizan las fases de diseño y construcción.
·
Se preocupa por la calidad, por lo que incluye
un monitoreo constante del proyecto.
· -Ayuda a contrarrestar situaciones como el exceso
en el presupuesto, fallas en el programa o el hecho de entregar menos de lo
deseado.
·
Propone tener etapas de cierre cada dos semanas.
·
Se obtienen resultados periódicos y tangibles.
Procesos
El FDD tiene cinco procesos. Los primeros tres se hacen al
principio del proyecto.
· - Desarrollar un modelo global: Al inicio del
desarrollo se construye un modelo teniendo en cuenta la visión, el contesto y
los requisitos que debe tener el sistema a construir. Este modelo se divide en
áreas que se analizan detalladamente. Se construye un diagrama de clases por
cada área.
- -Construir una lista de los rasgos: Se elabora
una lista que resuma las funcionalidades que debe tener el sistema, cuya lista
es evaluada por el cliente. Cada funcionalidad de la lista se divide en
funcionalidades más pequeñas para un mejor entendimiento del sistema.
· -Planear por rasgo: Se procede a ordenar los
conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna
a los programadores jefes.
· - Diseñar por rasgo: Se selecciona un conjunto de
funcionalidades de la lista.
-Se procede a diseñar y construir la funcionalidad
mediante un proceso iterativo, decidiendo que funcionalidad se van a realizar
en cada iteración. Este proceso iterativo incluye inspección de diseño,
codificación, pruebas unitarias, integración e inspección de código.
Material extra:
Suscribirse a:
Entradas (Atom)