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:
3.3 Modelo ágil
El paradigma AGIL puede ser utilizado en el análisis de
cualquier sistema social. Puede utilizarse, por ejemplo, en virtud de la
Sociología de las organizaciones, no solo para estudiar las organizaciones
formales empresas, gobierno, agencias de formación, etc.), sino también en los
componentes elementales de la sociedad (comofamilia, el grupos de interés,
etc.).
Las metodologías ágiles (como por ejemplo XP, SCRUM, DSDM,
Crystal, etc...). Forman parte del movimiento de desarrollo ágil de sotfware,
que se basan en la adaptabilidad de cualquier cambio como medio para aumentar
las posibilidades de éxito de un proyecto. De forma que una metodología ágil es
la que tiene como principios que:
- Los individuos y sus interacciones son más importantes que los procesos y las herramienta.
- El software que funciona es más importante que la documentación exhaustiva.
- La colaboración con el cliente en lugar de la negociación de contratos.
- La respuesta delante del cambio en lugar de seguir un plan cerrado.
3.1 ¿Qué es agilidad?
Agilidad
Un equipo ágil es un
equipo diestro que reacciona apropiadamente al
cambio.
Los cambios están siempre presentes: cambios en el software a construir, en los miembros del equipo, en la tecnología o cambios de otro tipo que tienen repercusión en el proyecto o en el producto.
Los cambios están siempre presentes: cambios en el software a construir, en los miembros del equipo, en la tecnología o cambios de otro tipo que tienen repercusión en el proyecto o en el producto.
Los ingenieros de
software deben “tener buenos reflejos”
para dar cabida a los cambios descritos.
Comunicación
La agilidad también fomenta actitudes y estructuras grupales que facilitan la comunicación (entre integrantes
del equipo, entre tecnólogos y ejecutivos, y entre ingenieros de software y gerentes).
La agilidad adopta al cliente como parte del equipo ágil de desarrollo.
La agilidad pone más énfasis en la entrega rápida de software operacional y menos énfasis en
productos de trabajo intermedios
Planificación
La agilidad reconoce que la planificación bajo condiciones de incertidumbre tiene sus límites y el plan
de un proyecto debe ser flexible.
La agilidad puede aplicarse a un proceso de software siempre y cuando:
El proceso permita al equipo adaptar tareas y hacerlas más eficientes.
La planificación debe comprender la fluidez del enfoque ágil.
Dejar sólo los productos de trabajo que sean esenciales y concisos.
El cliente reciba software funcional de forma incremental lo más rápido posible para el tipo de producto y ambiente de operación.
Matrial extra :
Unidad III introducción al desarrollo ágil
El desarrollo ágil son métodos de ingeniería del software
basados en el desarrollo iterativo e incremental, donde los requerimientos y
soluciones evolucionan mediante la colaboración de grupos auto organizados y
multidisciplinarios. Existen muchos métodos de desarrollo ágil; la mayoría
minimiza riesgos desarrollando software en lapsos cortos. El software
desarrollado en una unidad de tiempo es llamado una iteración, la cual debe
durar de una a cuatro semanas. Cada 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, sino que la meta es tener una
«demo» (sin errores) al final de cada iteración. Al final de cada iteración el
equipo vuelve a evaluar las prioridades del proyecto.
Algunos métodos ágiles de desarrollo de software:
- Adaptive Software Development (ASD).
- Agile Unified Process (AUP).
- Crystal_Clear.
- Essential Unified Process (EssUP).
- Feature Driven Development (FDD).
- Lean Software Development (LSD).
- Kanban.
- Open Unified Process (OpenUP).
- Programación Extrema (XP).
- Método de desarrollo de sistemas dinámicos (DSDM).
- Scrum.
- G300.
Material extra:
2.5 Adaptación de UML al proceso de desarrollo
Existen dos tipos de metodologías: antiguas y recientes. Se
entiende por metodología a la estructura y naturaleza de los pasos en un
esfuerzo de desarrollo. Pero antes de iniciar a programar los desarrolladores
deben tener claridad sobre el problema.
Método antiguo
Las etapas deben suceder en lapsos definidos, una después de
otra. Obsérvese el método en cascada:
Este método reduce el impacto de la comprensión obtenida en
el proyecto. Si el proceso no puede retroceder y volver a ver los primeros
estados, es posible que las ideas desarrolladas no sean utilizadas.
Método reciente
Tiende a la colaboración entre las fases de desarrollo esta
moderna ingeniería de programas, los analistas y diseñadores hacen revisiones
para desarrollar un sólido fundamento para los desarrolladores. Existe
interacción entre todo el equipo de trabajo.
La ventaja es que conforme crece la comprensión, el equipo
incorpora nuevas ideas y genera un sistema más confiable.
Lo que debe hacer un proceso de desarrollo
El equipo tiene que formarse de analistas para comunicarse
con el cliente y comprender el problema, diseñadores para generar una solución,
programadores para codificarla e ingenieros de sistemas para distribuirlas.
A su vez debe asegurar que sus fases no sean discontinuas.
GRAPPLE
Significa Guías para la Ingeniería de Aplicaciones Rápidas,
tiene dentro de sí una condensación de ideas de varias otras personas.
Consta de cinco segmentos en lugar de fases, cada segmento
consta de diversas acciones cada acción
es responsabilidad de un jugador.
Los segmentos son: recopilación, análisis, diseño, desarrollo y distribución. Lo que otorga un acrónimo RADDD.
- Recopilación de necesidades
- La función es comprender lo que desea el cliente
- Realice un análisis del dominio
El objetivo es comprender de la mejor manera posible el
dominio del cliente. El analista debe acomodarse al cliente.
Descubra las necesidades del sistema
El equipo realiza su primera sesión de JAD(Desarrollo de
conjunto de aplicaciones).En dónde se reúne a quienes toman las decisiones en
la empresa del cliente, a los usuarios potenciales y a los miembros de los
equipos de desarrollo.
Presentar los resultados al cliente
Cuando finaliza todas las acciones de Necesidades, el
administrador de proyectos presentará los resultados al cliente.
Análisis
En este segmento aumenta la comprensión por parte del
equipo.Se necesita trabajar sobre: la comprensión del uso del sistema, hacer
realidad de los casos de uso, depurar los diagramas de clases, analizar cambios
de estado en los objetos, definir la comunicación entre objetos, analizar la
integración con diagramas de colaboraciones.
Diseño
El equipo trabajará con los resultados del segmento de
Análisis para diseñar la solución, en este punto se harán revisiones
pertinentes hasta que el diseño se haya completado. Contiene las siguientes
fases: desarrollo y depuración de diagramas de componentes, desarrollo de diagramas
de componentes, planeación para la distribución, diseño y prototipos de la
interfaz del usuario, pruebas de diseño, iniciar la documentación.
Desarrollo
De este segmento se encargan los programadores, debe
realizarse con rapidez y sin problemas.
Fases: generación del código, verificación del código,
generación de interfaces del usuario y conexión con el código, prueba,
consumación de la documentación.
Distribución
En este segmento se distribuye en el hardware adecuado y se
integra con los sistemas cooperativos.
Fases: planeación para copias de seguridad y recuperación,
instalación del sistema terminado en el hardware adecuado, verificación del
sistema instalado, celebración.
2.4 Diagrama de comportamiento
2.4.1 Diagrama de caso de uso
En el Lenguaje de Modelado Unificado, un diagrama de casos
de uso es una especie de diagrama de comportamiento UML mejorado. El Lenguaje
de Modelado Unificado (UML), define una notación gráfica para representar casos
de uso llamada modelo de casos de uso. UML no define estándares para que el
formato escrito describa los casos de uso, y así mucha gente no entiende que
esta notación gráfica define la naturaleza de un caso de uso; sin embargo una
notación gráfica puede solo dar una vista general simple de un caso de uso o un
conjunto de casos de uso. Los diagramas de casos de uso son a menudo
confundidos con los casos de uso. Mientras los dos conceptos están
relacionados, los casos de uso son mucho más detallados que los diagramas de
casos de uso.
La descripción escrita del comportamiento del sistema al
afrontar una tarea de negocio o un requisito de negocio. Esta descripción se
enfoca en el valor suministrado por el sistema a entidades externas tales como
usuarios humanos u otros sistemas.
La posición o contexto del caso de uso entre otros casos de
uso. Dado que es un mecanismo de organización, un conjunto de casos de uso
coherentes y consistentes promueven una imagen fácil de comprender del
comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario
y el equipo de desarrollo.
En esta práctica es común crear especificaciones
suplementarias para capturar detalles de requisitos que caen fuera del ámbito
de las descripciones de los casos de uso. Ejemplos de esos temas incluyen
restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o
cumplimiento de estándares.
El diagrama describe la funcionalidad de un Sistema
Restaurante muy simple. Los casos de uso están representados por elipses y los
actores están, por ejemplo, los casos de uso se muestran como parte del sistema
que está siendo modelado, los actores no.
La interacción entre actores no se ve en el diagrama de
casos de uso. Si esta interacción es esencial para una descripción coherente
del comportamiento deseado, quizás los límites del sistema o del caso de uso
deban de ser re-examinados. Alternativamente, la interacción entre actores
puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los
actores son una especie de rol, un usuario humano u otra entidad externa puede
jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la
misma persona.
2.4.2 Diagrama de estados
Los diagramas de estado muestran el conjunto de estados por
los cuales pasa un objeto durante su vida en una aplicación en respuesta a
eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con
sus respuestas y acciones. También ilustran qué eventos pueden cambiar el
estado de los objetos de la clase. Normalmente contienen: estados y
transiciones. Como los estados y las transiciones incluyen, a su vez, eventos,
acciones y actividades, vamos a ver primero sus definiciones.
Al igual que otros diagramas, en los diagramas de estado
pueden aparecer notas explicativas y restricciones
2.4.3 Diagrama de secuencias
Un diagrama de secuencia muestra la interacción de un
conjunto de objetos en una aplicación a través del tiempo y se modela para cada
caso de uso. Mientras que el diagrama de casos de uso permite el modelado de
una vista business del escenario, el diagrama de secuencia contiene detalles de
implementación del escenario, incluyendo los objetos y clases que se usan para
implementar el escenario y mensajes intercambiados entre los objetos.
Tipos de mensaje
Existen dos tipos de mensajes: sincrónicos y asincrónicos.
Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que
recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que
termina la llamada. Este tipo de mensajes se representan con flechas con la
cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un
nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con
la cabeza abierta.
Pueden ser usados de dos formas
De instancia: describe un escenario específico (un escenario
es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para un caso de uso.
Utiliza ramificaciones ("Branches"), condiciones y bucles.
Material extra:
http://tt717.galeon.com/DSecuencia.htm
Material extra:
http://tt717.galeon.com/DSecuencia.htm
2.3 Diagramas estructurales
2.3.1 Diagrama de
clases
Diagrama de
Clases: Un diagrama que muestra un conjunto de clases, interface y
colaboraciones y las relaciones entre estos, los diagramas de clases muestran
el diseño de un sistema desde un punto de vista estatico, un diagrama que
muestra una coleccion de elementos (estaticos) declarativos.
Un diagrama
de clases es un tipo de diagrama estático que describe la estructura de
unsistema mostrando sus clases, orientados a objetos.
Propiedad de
objetos que tienen propiedades y/u operaciones que contienen un contexto y un
dominio, los primeros dos ejemplos son clases de datos y el tercero clase de
lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los
datos con las operaciones.
El diagrama
de clases incluye mucha más información como la relación entre un objeto y
otro, la herencia de propiedades de otro objeto, conjuntos de
operaciones/propiedades que son implementadas para una interfaz gráfica.
Presenta las
clases del sistema con sus relaciones estructurales y de herencia
 |
| Ejemplo de diagrama de clases de la universidad |
características
Identificar
las ideas principales al ser incluidas en el diagrama de flujo. Deben estar
presentes el autor o responsable del proceso, los autores o responsables del
proceso anterior y posterior y de otros procesos interrelacionados, así como
las terceras partes interesadas.
- Definir qué se espera obtener del diagrama de flujo.
- Identificar quién lo empleará y cómo.
- Establecer el nivel de detalle requerido.
- Determinar los límites del proceso a describir.
- Establecer el alcance del proceso a describir. De esta manera quedará fijado el comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso siguiente.
- Identificar y listar las principales actividades/subprocesos que están incluidos en el proceso a describir y su orden cronológico.
Tipos
Formato
vertical: En él, el flujo y la secuencia de las operaciones, va de arriba hacia
abajo. Es una lista ordenada de las operaciones de un proceso con toda la
información que se considere necesaria, según su propósito.
Formato
horizontal: En él, el flujo o la secuencia de las operaciones, va de izquierda
a derecha.
Formato
panorámico: El proceso entero está representado en una sola carta y puede
apreciarse de una sola mirada mucho más rápido que leyendo el texto, lo que
facilita su comprensión, aun para personas no familiarizadas. Registra no solo
en línea vertical, sino también horizontal, distintas acciones simultáneas y la
participación de más de un puesto o departamento que el formato vertical no
registra.
Formato
Arquitectónico: Describe el itinerario de ruta de una forma o persona sobre el
plano arquitectónico del área de trabajo. El primero de los flujogramas es
eminentemente descriptivo, mientras que los utilizados son fundamentalmente
representativos.
2.3.2 Diagrama de
componentes
Diagrama de
Componentes: Un diagrama que muestra un conjunto de componentes y sus
relaciones, los diagramas de componentes muestran los componentes de un sistema
desde un punto de vista estático.
Un diagrama
de componentes representa cómo un sistema de software es dividido en
componentes y muestra las dependencias entre estos componentes. Los componentes
físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos,
ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de
la arquitectura de software pero pueden ser usados para modelar y documentar
cualquier arquitectura de sistema.
Debido a que
los diagramas de componentes son más parecidos a los diagramas de casos de
usos, éstos son utilizados para modelar la vista estática y dinámica de un
sistema. Muestra la organización y las dependencias entre un conjunto de
componentes. No es necesario que un diagrama incluya todos los componentes del
sistema, normalmente se realizan por partes. Cada diagrama describe un apartado
del sistema.
En él se
situarán librerías, tablas, archivos, ejecutables y documentos que formen parte
del sistema.Uno de los
usos principales es que puede servir para ver qué componentes pueden
compartirse entre sistemas o entre diferentes partes de un sistema.
2.3.3 Diagrama de
objetos
Diagrama de
Objetos: Un diagrama de muestra un conjunto de objetos y sus relaciones en un momento
determinado; los diagramas de objetos muestran el diseño o los procesos de un
sistema desde un punto de vista estático.
Los
diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de
los sistemas informáticos en la metodología UML.
Se puede
considerar un caso especial de un diagrama de clases en el que se muestran
instancias específicas de clases (objetos) en un momento particular del
sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de
un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni
los roles, aunque su notación es similar a los diagramas de clase. Una
diferencia con los diagramas de clase es que el compartimiento de arriba va en
la forma Nombre de objeto: Nombre de clase.
Por ejemplo,
Miguel: Persona.
Un diagrama
de Objetos está relacionado de cerca con un diagrama de Clases, con la
diferencia de que éste describe las instancias de los objetos de clases en un
punto en el tiempo. Esto podría parecer similar al diagrama de Estructura
Compuesta, que modela el comportamiento en tiempo de ejecución; la diferencia
es que el diagrama de Objetos ejemplifica al diagrama de Clases estático,
mientras que los diagramas de Estructura Compuesta refleja las arquitecturas
diferentes de sus contrapartes estáticas. Los diagramas de Objetos no presentan
arquitecturas que varíen de sus correspondientes diagramas de Clases, pero
reflejan la multiplicidad y los roles a los que las clases instanciadas podrían
servir. Ellos son muy útiles en la comprensión de diagramas de Clases
complejos, al crear diferentes casos en los que se aplican las relaciones y las
clases. Un diagrama de Objetos puede ser también un tipo de diagrama de
Comunicaciones, el cual modela también las conexiones entre pares de objetos y
además las secuencias de eventos a lo largo de cada camino.
2.3.4 Diagrama de
paquetes
En el
Lenguaje Unificado de Modelado, un diagrama de paquetes muestra cómo un sistema
está dividido en agrupaciones lógicas mostrando las dependencias entre esas
agrupaciones. Dado que normalmente un paquete está pensado como un directorio,
los diagramas de paquetes suministran una descomposición de la jerarquía lógica
de un sistema.
Los Paquetes
están normalmente organizados para maximizar la coherencia interna dentro de
cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas
líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión.
Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias
entre ellos pueden indicar el orden de desarrollo requerido.
Suscribirse a:
Entradas (Atom)