viernes, 23 de marzo de 2012
miércoles, 21 de marzo de 2012
Practica 4: Herramientas CASE
Práctica
Memoria
Héctor Arce de las Heras - Manual de instalacion e introduccion (imagenes)
Pablo Arcos López - Diagramas, conclusion y pruebas (imagenes)
Paula Benedicto Martínez - Manual de uso (imagenes)
domingo, 11 de marzo de 2012
LEAN SOFTWARE DEVELOPMENT
RESUMEN
LEAN
SOFTWARE DEVELOPMENT
Esta
metodología es una adaptación de la manufactura esbelta al desarrollo software.
Este
proceso de desarrollo software consta de siete principios:
1)
Eliminar los
desperdicios:
si no añade valor se considera un desperdicio. Algunos ejemplos de desperdicios
son: código y funcionalidades innecesarias, retraso en el desarrollo,
requisitos confusos, burocracia o comunicación interna lenta.
Para eliminar estos desperdicios se han de poder detectar, si se puede llegar al mismo resultado descartando una actividad esta se considera un desperdicio. También podemos clasificar como desperdicios las funcionalidades no utilizadas, las esperas, los defectos en el software o los gastos de gestión que no producen un valor real.
A la hora de detectar estos desperdicios se utiliza el mapa de flujo de valor. Después se distinguen los orígenes de los desperdicios y se eliminan.
Este proceso de detección y eliminación se repite de forma iterativa.
Para eliminar estos desperdicios se han de poder detectar, si se puede llegar al mismo resultado descartando una actividad esta se considera un desperdicio. También podemos clasificar como desperdicios las funcionalidades no utilizadas, las esperas, los defectos en el software o los gastos de gestión que no producen un valor real.
A la hora de detectar estos desperdicios se utiliza el mapa de flujo de valor. Después se distinguen los orígenes de los desperdicios y se eliminan.
Este proceso de detección y eliminación se repite de forma iterativa.
2)
Ampliar el aprendizaje: se basa en un
aprendizaje continuo. La acumulación de defectos debe evitarse realizando
pruebas inmediatamente después de escribir el código en lugar de producir
documentos o planificaciones. Las ideas pueden probarse escribiéndolas e
integrándolas en el código.
El proceso de aprendizaje se acelera y dinamiza por el uso de iteraciones cortas. También se realizan reuniones cortas con los clientes para determinar la fase de desarrollo y ajustar los esfuerzos para introducir mejoras. En estas reuniones cliente y equipo de desarrollo aprenden la medida del problema y buscan soluciones para un mejor desarrollo. Así los clientes distinguen mejor sus necesidades basándose en los resultados del desarrollo y los desarrolladores aprenden a satisfacer mejor estas necesidades.
Para aumentar el aprendizaje se integra al cliente en el ambiente de desarrollo concentrando la comunicación con el diálogo directo.
El proceso de aprendizaje se acelera y dinamiza por el uso de iteraciones cortas. También se realizan reuniones cortas con los clientes para determinar la fase de desarrollo y ajustar los esfuerzos para introducir mejoras. En estas reuniones cliente y equipo de desarrollo aprenden la medida del problema y buscan soluciones para un mejor desarrollo. Así los clientes distinguen mejor sus necesidades basándose en los resultados del desarrollo y los desarrolladores aprenden a satisfacer mejor estas necesidades.
Para aumentar el aprendizaje se integra al cliente en el ambiente de desarrollo concentrando la comunicación con el diálogo directo.
3)
Decidir lo más tarde
posible:
obtiene mejores resultados al basar sus decisiones en hechos no es
suposiciones, retrasa las decisiones hasta que esto sea posible. Cuanto más
complejo es el proyecto más capacidad de cambio necesita de forma que debe
permitir el retraso de los compromisos cruciales. El desarrollo iterativo
fomenta la capacidad de adaptarse a los cambios y corregir los errores.
Un desarrollo ágil puede presentar opciones rápidamente al cliente de forma que se deben retrasar algunas decisiones importantes hasta que el cliente tenga claramente reconocidas sus necesidades. Esto también favorece la adaptación tardía a los cambios. Esto sin embargo no significa que no haya planificación si no que la planificación se centra en las opciones y se adaptan a la situación actual. La evaluación de las diferentes opciones es eficaz, los desarrolladores, aunque no son libres, cuentan con flexibilidad para tomar decisiones tardías.
Un desarrollo ágil puede presentar opciones rápidamente al cliente de forma que se deben retrasar algunas decisiones importantes hasta que el cliente tenga claramente reconocidas sus necesidades. Esto también favorece la adaptación tardía a los cambios. Esto sin embargo no significa que no haya planificación si no que la planificación se centra en las opciones y se adaptan a la situación actual. La evaluación de las diferentes opciones es eficaz, los desarrolladores, aunque no son libres, cuentan con flexibilidad para tomar decisiones tardías.
4)
Reaccionar lo más rápido
posible:
cuanto antes se entrega el producto final antes se reciben peticiones de mejora
que añadir a la próxima iteración y cuanto más cortas sean estas iteraciones
mejor es la comunicación y aprendizaje del equipo. La velocidad asegurar que se
cumplan las necesidades actuales del cliente no las antiguas.
En un principio el cliente cuenta con unos requisitos necesarios y los desarrolladores estudiarán el tiempo necesario para realizar cada una de las historias propuestas. Así la organización cambia, cada día se realizan una reunión donde cada miembro estima lo que hizo ayer, lo que debe hacer hoy y mañana, y se informa de cualquier nuevo requisito necesario. Esto requiere transparencia en el proceso y beneficia la comunicación del equipo.
Otra de las ideas de este proceso de desarrollo es el diseño de una solución a un mismo problema por varios equipos, cuando la solución no es válida se desecha y al finalizar un periodo las soluciones validas se comparan y se elige una. Esta también puede sufrir modificaciones basadas en el aprendizaje de los demás equipos.
En un principio el cliente cuenta con unos requisitos necesarios y los desarrolladores estudiarán el tiempo necesario para realizar cada una de las historias propuestas. Así la organización cambia, cada día se realizan una reunión donde cada miembro estima lo que hizo ayer, lo que debe hacer hoy y mañana, y se informa de cualquier nuevo requisito necesario. Esto requiere transparencia en el proceso y beneficia la comunicación del equipo.
Otra de las ideas de este proceso de desarrollo es el diseño de una solución a un mismo problema por varios equipos, cuando la solución no es válida se desecha y al finalizar un periodo las soluciones validas se comparan y se elige una. Esta también puede sufrir modificaciones basadas en el aprendizaje de los demás equipos.
5)
Potenciar el equipo: en el desarrollo de
software las personas no se consideran recursos, necesitan algo más que una lista
de tareas y la seguridad de que esta no va a cambiar durante la realización.
Las personas necesitan motivación y un objetivo alcanzable para el cual
trabajar con la seguridad de que el equipo pueda elegir los sus compromisos.
Los desarrolladores deben poder comunicarse con el cliente, además existe un
jefe de equipo que proporciona ayuda y apoyo en situaciones complicadas y se
asegura de mantener vivo el espíritu del equipo.
6)
Crear integridad: el cliente debe tener
siempre una experiencia general del sistema, una percepción de la integridad de
este. La integridad se refiere a que los componentes del sistema funcionan
correctamente juntos, esto se puede lograr comprendiendo el dominio del
problema y resolviéndolo al mismo tiempo, no secuencialmente. La información
necesaria se recibe en pequeñas partes y con una comunicación directa, sin
documentación. La comunicación debe ser constante entre desarrolladores y
cliente evitando la acumulación de información tras un periodo de desarrollo
aislado.
Una de las maneras para conseguir una arquitectura integrante es la refactorización, esto es mantener la sencillez, la cantidad mínima de funcionalidades en el código evitando repeticiones. El proceso de construcción además se complementa con pruebas de una misma versión para desarrolladores y clientes. Al finalizar la integridad se confirma con una prueba global que garantiza el correcto funcionamiento. Las pruebas no son un objetivo sino un medio para la reducción de defectos.
Una de las maneras para conseguir una arquitectura integrante es la refactorización, esto es mantener la sencillez, la cantidad mínima de funcionalidades en el código evitando repeticiones. El proceso de construcción además se complementa con pruebas de una misma versión para desarrolladores y clientes. Al finalizar la integridad se confirma con una prueba global que garantiza el correcto funcionamiento. Las pruebas no son un objetivo sino un medio para la reducción de defectos.
7)
Vista de todo el
conjunto:
los sistemas no son la suma de sus partes sino el producto de sus
interacciones. Los defectos de software tienden a acumularse durante el
desarrollo por la descomposición en pequeñas tareas y la normalización de las
etapas de desarrollo. Cuanto más grande sea el sistema más organizaciones
tomarán parte en su desarrollo por lo que habrá más equipos diferentes y una
necesidad mayor de definir los diferentes proveedores para alcanzar una buena
interacción entre los componentes del sistema.
El desarrollo Lean tiene que ser comprendido por todos los integrantes de un proyecto antes de aplicarlo. La importancia de comprender los principios Lean y llevarlos a cabo durante el proceso se puede resumir en: “Piensa en grande, actúa en pequeño, equivócate y aprende con rapidez”.
El desarrollo Lean tiene que ser comprendido por todos los integrantes de un proyecto antes de aplicarlo. La importancia de comprender los principios Lean y llevarlos a cabo durante el proceso se puede resumir en: “Piensa en grande, actúa en pequeño, equivócate y aprende con rapidez”.
PREGUNTAS TIPO TEST
49. La metodología de desarrollo de software Lean es una traslación de:
a) Los principios y prácticas de la manufactura esbelta
b) La ideología del funcionamiento del software Umbrello
c) Los principios de Test Drive Developement y su manera de funcionar
d) El sistema de producción de Sony
50. Se considera desperdicio:
a) El adelanto en el proceso de desarrollo del software
b) La comunicación externa lenta
c) La burocracia
d) El código de programa necesario para su funcionamiento
51. Para ajustar esfuerzos e introducir mejoras en el futuro se:
d) Alargaran las reuniones con el cliente.
52. Los mejores resultados se alcanzan:
a) Basando las decisiones en suposiciones
53. La ideología principal de Lean Software Development es:
54. Se usa la técnica Work-Out que tiene como característica principal que:
a) Los clientes desarrollan el producto
b) Los desarrolladores escuchan las ideas de los directivos
c) Los directivos escuchan las ideas de los desarrolladores
55. La manera más saludable hacia una arquitectura integrante se obtiene gracias a:
a) La repetición en el código
b) Mantener la complejidad en el diseño del software
c) Añadir la menor cantidad de funcionalidades al sistema
d) La refactorización
56. Se obtendrá un buen producto solo si:
a) Los principios y prácticas de la manufactura esbelta
b) La ideología del funcionamiento del software Umbrello
c) Los principios de Test Drive Developement y su manera de funcionar
d) El sistema de producción de Sony
50. Se considera desperdicio:
a) El adelanto en el proceso de desarrollo del software
b) La comunicación externa lenta
c) La burocracia
d) El código de programa necesario para su funcionamiento
51. Para ajustar esfuerzos e introducir mejoras en el futuro se:
a) Realiza el menos número de reuniones entre desarrolladores y clientes
b) Incrementa la retroalimentación mediante reuniones cortas con los clientes.
c) Eliminan reuniones entre miembros del equipod) Alargaran las reuniones con el cliente.
52. Los mejores resultados se alcanzan:
a) Basando las decisiones en suposiciones
b) Llevando a cabo metodología de no retrasar las decisiones pero basando estas en hechos.
c) Con un enfoque basado en realizar código y probar hasta obtener el resultado deseado
d) Con un enfoque basado en opciones53. La ideología principal de Lean Software Development es:
a) Cuanto mas rápido se entrega un producto sin defectos, antes se obtendrán comentarios de fallos para mejorar.
b) Mejor realizar una entrega lenta que rápida
c) Los comentarios obtenidos del producto no se introducen en la siguiente iteración
d) No importa lo rápido o lo lenta que se realice la entrega del producto y tampoco los comentarios que se realizan al respecto
54. Se usa la técnica Work-Out que tiene como característica principal que:
a) Los clientes desarrollan el producto
b) Los desarrolladores escuchan las ideas de los directivos
c) Los directivos escuchan las ideas de los desarrolladores
d) Se forma un equipo de desarrollo del producto entre directivos, cliente y desarrolladores.
55. La manera más saludable hacia una arquitectura integrante se obtiene gracias a:
a) La repetición en el código
b) Mantener la complejidad en el diseño del software
c) Añadir la menor cantidad de funcionalidades al sistema
d) La refactorización
56. Se obtendrá un buen producto solo si:
a) Aplicando todos los principios de Lean con sentido común, y usando todas las herramientas referidos a este.
b) Aplicando solamente los principios de integridad
c) Con una buena comunicación entre el directivo y el cliente, dejando de lado al desarrollador
d) Usando las ideas del cliente sin ninguna aportación del desarrollador miércoles, 7 de marzo de 2012
Practica 3: Otras metodologías ágiles
Práctica 3
Pablo Arcos López - DSDM: Dynamic Systems Development Method
Paula Benedicto Martínez - FDD: Feature Driven development
Suscribirse a:
Entradas (Atom)