domingo, 24 de mayo de 2015

SCRUM

SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que procura facilitar la aplicación de scrum y gestionar cambios, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que ejecuta el desarrollo y demás elementos relacionados con el. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo y debe ser lo mas corta posible), el equipo crea un incremento de software potencialmente entregable(utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo conversa con el Product Owner buscando claridad y magnitud adecuadas (Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.
Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamadorequirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.
Las características más marcadas que se logran notar en Scrum serían: gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por último equipo motivado. Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

  
SCRUM
XP
Es una metodología de desarrollo ágil basada en la administración del proyecto.
Es una metodología de desarrollo que está más centrada en la programación o creación del producto.
Cada miembro de del equipo trabaja de forma indivisual.
Los miembro del equipo programan en parejas.
Las ietraciones de entrega son de 1 a 4 semanas.
Las ietraciones de entrega son de 1 a 3 semanas
Al finalizar un Sprint, las tareas del Sprint Backlog que se hayan realizado y que el Product Owner (propietario del producto) haya mostrado su conformidad ya no se retoca. Si funciona y está bién, se aparta y a otra cosa.
Las tareas se van terminando aunque son susceptibles de ser modificadas durante el transcurso de proyecto, incluso, después de que funcionen correctamente.
Trata de seguir el orden de prioridades que marca el Product Owneren el Sprint Backlog pero puede cambiarlo si es mejor para el desarrollo de la tareas.
El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definido por el cliente.



miércoles, 22 de abril de 2015

Historia de Usuario

1                               Petición de Casa
Mi cliente quiere construir una casa, que conste de dos pisos, en la planta baja desea cuatro cuartos: la sala, el comedor la cocina y un medio baño. En el piso superior desea cinco cuartos que son:
Tres recamaras, un baño y un estudio. El cliente desea que todos los cuartos tengan al menos una ventana, para que la casa sea luminosa.

Prioridad: 85                     Estimación:5                   Dependencia

  

lunes, 20 de abril de 2015

Programacion Extrema

Escenario
 La empresa el Pato Volador en la que usted labora ha sido contratada por una Agencia Espacial para desarrollar el software de un satélite que se desarrollará en 3 meses como máximo, ya que es el tiempo en que será el lanzamiento del satélite para ponerlo en órbita. El satélite auxiliará el retorno de una las naves espaciales que regresan a la tierra. La Agencia Espacial ha puesto a su disposición a los ingenieros encargados de proporcionar los requerimientos del software de tiempo completo, así como los recursos e instalaciones necesarios para lograr el desarrollo del software en el tiempo establecido. El Pato Volador ha propuesto a los directivos de la Agencia Espacial la metodología de Programación Extrema (XP por sus siglas en ingles) para la realización del software, ya que es indispensable terminar en tiempo el proyecto. Usted debe utilizar la metodología XP para organizar a su equipo de trabajo y a los ingenieros de la Agencia, explicándoles la metodología XP y las funciones que deben realizar en las diferentes fases del proceso de desarrollo del software.

¿Qué es la Programación Extrema?
La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.

 ¿Cuáles son los valores y principios de la Programación Extrema?
Los valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:
Simplicidad La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente.
Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece.
También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente.
Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.
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. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método.
Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas.
Realimentación 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.
Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.
Coraje o valentía
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran más fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente.
RespetoEl respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. 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. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo de producción.

¿Cuáles son las actividades, recursos y prácticas de la Programación Extrema?
1.- liberación limitada: los productos deben liberarse con rapidez, cuando los programadores no puedan implementar, todas las características en una sola pieza de software, la versión debe liberarse de acuerdo con el programador.
2.- semana de trabajo de 40 hrs: los equipos de desarrollo de xp fomentan una práctica cultural en la que el equipo trabaja de manera intensa durante una semana típica de 40 hrs.
3.- cliente en el sitio: llega al extremo al insistir en que un experto en el negocio debe trabajar en el sitio durante todo el proceso de desarrollo.
4.- programación en parejas: significa que dos programadores ejecutan las pruebas y conversan acerca de formas de hacer eficiente y eficazmente el trabajo.

 ¿Cuál son las fases del proceso de desarrollo de XP?
 1ª Fase: Planificación del proyecto.
......o Historias de usuario.
......o Release planning.
......o Iteraciones: 
......o Velocidad del proyecto.
......o Programación en pareja.
......o Reuniones diarias.
 2ª Fase: Diseño.
......o Diseños simples.
......o Glosarios de términos.
......o Riesgos.
......o Funcionalidad extra.
......o Tarjetas C.R.C.
 3ª Fase: Codificación.
 4ª Fase: Pruebas.
......oEl uso de los test en X.P es el siguiente.
......oTest de aceptación.
 ¿Qué es una historia de usuario?
Es una representación de un requisito de software escrito en una o dos frases utilizando el lenguaje común del usuario. 




lunes, 13 de abril de 2015

Actividad

Escenario
La Agencia Espacial en días anteriores ha perdido un satélite de comunicación debido al fallo del software del mismo. La investigación indicó que la falla fue porque no se cubrieron los requisitos de programación del sistema especificados por la propia agencia.
La Agencia Espacial tiene que remplazarlo lo más pronto posible, ya que las comunicaciones con las naves espaciales dependen del mismo. Afortunadamente para la agencia, existe un nuevo satélite ya construido que estaba programado para ser lanzado.
En un año, el inconveniente es que si se carga el mismo software el satélite se volverá a perder.
La empresa el Pato Volador en la que usted labora ha sido contratada para desarrollar el software del satélite en un proyecto de 3 meses como máximo, ya que es el tiempo en que retornará la próxima nave espacial que necesita los servicios del satélite para poder retornar a la tierra.
La Agencia pone a su disposición a los ingenieros encargados de proporcionar los requerimientos del software de tiempo completo, así como los recursos e instalaciones necesarios para lograr el desarrollo del software en el tiempo establecido. No es indispensable entregar la documentación formal del análisis y diseño del software, sin embargo debe haber evidencia que permita el entendimiento del sistema y el funcionamiento del mismo.

Usted debe proponer una metodología de desarrollo de software que permita organizar a su equipo de trabajo y a los ingenieros de la Agencia, mencionando los beneficios y riesgos que puedan existir.




¿Qué son las metodologías ágiles de desarrollo de software?
Son los valores y principios que permiten a los equipos de desarrollo de software hacerlo más rápidamente, respondiendo a los cambios que puedan surgir en el proyecto
¿Cuáles son las características en las que se basan las metodologías ágiles?
Debe definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc.
 ¿Cuáles son las ventajas y desventajas del empleo de las metodologías ágiles respecto a las tradicionales?
Son la alternativa rápida, que evita una documentación severa del sistema. El problema es que no sirve con proyectos grandes
¿Cuándo es recomendable utilizar metodologías ágiles en el desarrollo de software?
Cuando se quiere realizar un proyecto corto.
¿Cuáles son algunos tipos de metodologías ágiles?
Programacion extrema, Srum, Adaptive Software Development, Crystal Methodologies, Feature Driven development

sábado, 28 de marzo de 2015

Metodos Agiles de Programacion

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al des arrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales.

Cuestionario:


1. Los métodos ágiles se utilizan en:
 a) Programación Orientada a Objetos
2. ¿Qué modelo de desarrollo de software utilizan los métodos ágiles?
 a) Cascada
3. ¿Cuáles son las principales características en las que se basa el método ágil?
b) Satisfacción del cliente, reduce tiempo, una sola entrega final.
 4. ¿Cuáles son las características que diferencian al método ágil del convencional?
  c) Satisfacción del cliente
 5. En los métodos ágiles el cliente:
 e) Proporciona los recursos materiales

miércoles, 4 de febrero de 2015

Pruebas de integración 

Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez. 

Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente. Determina cómo la base de datos de prueba será cargada, Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente, Decide qué acciones tomar cuando se descubren problemas.

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos. 

Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase de la prueba de software en la cual módulos individuales de software son combinados y probados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden a las pruebas del sistema. 

Pruebas de Sistema 

Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación.

 Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en técnicas de caja negra, ésto es, verificar el sistema (y sus procesos internos), la interacción con las aplicaciones que lo usan via GUI y analizar las salidas o resultados. 

 En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio. 

Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las pruebas previas realizadas pueden frecuentemente ser reorganizados y rehusados durante la prueba de sistema. No obstante, deben ser desarrollados casos de prueba adicionales para aquellos aspectos del sistema, tales como documentación, procedimientos y desempeño que no han sido probados durante la prueba unitaria y de integración. 

La prueba de sistema es compleja porque intenta validar un número de características al mismo tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del sistema al mismo tiempo.