Video: https://youtu.be/lNru8Id3DpU
06 marzo 2016
29 febrero 2016
21 febrero 2016
Programación extrema (Sesión 4)
MÉTODOS ÁGILES DE PROGRAMACIÓN
SESIÓN 4
6IM7
GONZALEZ GARCIA GONZALO
PARRA GARCILAZO CINTHYA DOLORES
TAREA
Programación extrema
Preguntas
¿Qué es la Programación Extrema?
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.
La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y una docena de prácticas correctas que propician un aumento en la productividad a la hora de generar software.
La programación extrema se basa en la simplicidad, la comunicación y el reciclado continuo de código, para algunos no es más que aplicar pura lógica.
¿Cuáles son los valores y principios de la Programación Extrema?
Para garantizar el éxito de un proyecto, los autores de XP han considerado como fundamentales cuatro valores:
1. Comunicación.
Muy importante. La XP ayuda mediante sus prácticas a la comunicación entre los integrantes del grupo de trabajo: jefes de proyecto, clientes y desarrolladores.
2. Sencillez.
Los programas deben ser los más sencillos posibles y tener la funcionalidad necesaria que se indican en los requisitos. No hay que añadir algo que no se necesite hoy. Si se necesita añadir más funcionalidad mañana pues ya se hará entonces.
3. Retroalimentación.
Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema.
4. Valentía.
Asumir retos, ser valientes ante los problemas y afrontarlos. El intentar mejorar algo que ya funciona. Aunque gracias a las pruebas unitarias no existe el riesgo de ‘meter la pata’.
5. Algunas voces, añaden además un quinto valor: la humildad. Con la compartición de código, la refactorización y el trabajo de equipo tan estrecho una buena dosis de humildad siempre es de agradecer.
¿Cuáles son las actividades, recursos y prácticas de la Programación Extrema?
Las prácticas son las siguientes:
1. El juego de la planificación (the planning game).
Es un permanente diálogo entre las partes empresarial (deseable) y técnica (posible).
2. Pequeñas entregas (small releases).
Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, no puedes implementar media característica y lanzar la versión.
3. Metáfora (metaphor).
Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas “Programa de gestión de compras, ventas, con gestión de cartera y almacén”. Las metáforas ayudan a cualquier persona a entender el objeto del programa.
4. Diseño sencillo (simple design).
5. Pruebas (testing).
No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa más seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
6. Refactorización (refactoring).
Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo más simple posible, después de implementar esta característica, nos preguntamos cómo hacer el programa más simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring).
7. Programación por parejas (pair programming).
Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa más estratégicamente. Cualquier miembro del equipo se puede emparejar con cualquiera.
8. Propiedad colectiva (collective ownership).
Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.
9. Integración continua (continuos integration).
El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%.
10. 40 horas semanales (40-hour week).
Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche.
Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.
11. Cliente en casa (on-site costumer).
Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades.
12. Estándares de codificación (coding standards).
Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.
XP ha sido adoptado por un gran número de equipos en los últimos años y de sus experiencias se ha extraído una conclusión sencilla: es mejor empezar a hacer XP gradualmente.
¿Cuál son las fases del proceso de desarrollo de XP?
El proceso que recomiendan los autores de XP es el siguiente:
- Identifica el principal problema del proceso de desarrollo actual.
- Escoge la práctica que ayuda a resolver ese problema y aplícala. Cuando ese haya dejado de ser un problema, escoge el siguiente. En realidad se recomienda que se apliquen las prácticas de dos en dos. El objetivo es que las prácticas de XP se apoyan unas a otras y por tanto dos prácticas aportan más que la suma de ambas y por tanto es más fácil comprobar los resultados.
- El objetivo final debe ser aplicar todas las prácticas, ya que representan un conjunto completo, "si no las aplicas todas no estás haciendo eXtreme Programming".
En resumen sería Planificación del proyecto, diseño, codificación y pruebas.
¿Qué es una historia de usuario?
Es una representación de un requisito de software escrita por el cliente en 1 a 4 frases en su lenguaje común. Son usadas para la especificación de requerimientos y para estimar tiempos de desarrollo. El tiempo de desarrollo de cada una es entre 1 y 3 semanas.
Las historias de usuario son una forma rápida de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rápidamente a los requisitos cambiantes.
Referencias Bibliográficas:
Beck, K. (1999) "Extreme Programming Explained. Embrace Change": Pearson Education.
Highsmith, J. (2002) "Agile Software Development Ecosystems". Addison-Wesley
Wells D. (2002) Extreme Programming: A gentle introduction
Martin, R. & Newkirk, J. (2002). La Programacion Extrema en Practica. Pearson Addison-Wesley
Métodos ágiles de programación (Sesión 3)
MÉTODOS ÁGILES DE PROGRAMACIÓN
SESIÓN 3
6IM7
GONZALEZ GARCIA GONZALO
PARRA GARCILAZO CINTHYA DOLORES
TAREA
¿Qué son las metodologías ágiles de desarrollo de software?
Son una serie de procesos que se encargan de facilitar las actividades realizadas en el desarrollo de software para que puedan realizarse con mayor rapidez y adaptabilidad a los cambios en el transcurso de todo el proyecto, esto en comparación con los procesos tradicionales.
Se usan generalmente para proyectos un tanto cortos pero sin descuidar la calidad.
El desarrollo que se realiza es iterativo e incremental.
¿Cuáles son las características en las que se basan las metodologías ágiles?
Rapidez, flexibilidad, trabajo en equipo y disponibilidad.
El trabajo en equipo es importante para el desarrollo, se valora más que el entorno.
Es más importante el desarrollo del software que la documentación de este.
Su propuesta es una mayor participación del cliente en el proceso del análisis y en el trayecto de todo el proceso de desarrollo del proyecto.
Tienen una gran adaptabilidad al cambio y trabajar sobre la marcha.
Dentro de las características que componen a los métodos descritos anteriormente se incluyen el desarrollo iterativo, este tiene una gran ventaja pues al desarrollarse mediante iteraciones permite al equipo de desarrollo adaptarse a los cambios de de los requisitos.
¿Cuáles son las ventajas y desventajas del empleo de las metodologías ágiles respecto a las tradicionales?
Una de las ventajas más importantes de los métodos ágiles de programación es que el cliente es el que se encarga de los procesos de negocios y ahorra a los analistas la investigación de dichos proceso.
Otra ventaja principal es que al utilizar las metodologías ágiles al presentarse algún error de cualquier tipo, el desarrollador no tiene que empezar desde el inicio sino que es fácilmente adaptable.
Una desventaja es que no se puede implementar en todo tipo de proyectos, únicamente a los que sean de tiempos relativamente cortos, proyectos no muy extensos
¿Cuándo es recomendable utilizar metodologías ágiles en el desarrollo de software?
Cuando los proyectos no sean muy extensos, los integrantes del mismo deben estar en un mismo entorno de trabajo.
Es recomendable usar metodologías ágiles generalmente cuando se cuenta con un lapso corto para el desarrollo del proyecto.
¿Cuáles son algunos tipos de metodologías ágiles?
- eXtreme Programming,
- Scrum,
- Iconix,
- Cristal Methods,
- AUP.
- Adaptive Software Development y
- Feature Driven Development.
Referencias:
Canós, J. H., Letelier, P., & Penadés, M. C. (2003). Metodologías ágiles en el desarrollo de software. Universidad Politécnica de Valencia, Valencia.
Robles, G., & ferrer, J. (10 de cotubre de 2002). Programación Extrema y Software Libre. Recuperado el 26 de marzo de 2012, de TLDP: http://es.tldp.org/Presentaciones/200211hispalinux/ferrer/robles-ferrer-ponencia-hispalinux-2002.html
Cadavid A., Fernández J., Morales J., “Revisión de metodologías ágiles para el desarrollo del software”, Prospect. Vol 11, No 2, Julio-Diciembre de 2013
Jorge F., “Introducción a las metodologías ágiles, otras formas de analizar y desarrollar”, Universitat Oberta de Catalunya
19 febrero 2016
15 febrero 2016
14 febrero 2016
Modelos de Procesos de Software
Introducción:
Analizaremos los principales
modelos de procesos del software, describiendo cada una de sus características
esenciales, esto con la finalidad de que se logre apreciar las diferencias que
radican unas con otras.
Se explicará brevemente en qué
consiste la serie de pasos que lleva cada uno, se espera también que con esto
se pueda visualizar en qué tipo de proyectos se adaptan cada uno de estos
procesos ya que, a pesar de que hay algunos más antiguos que otros y por teoría
más completos, no hay alguno que convenga por completo en todo tipo de
proyectos.
Desarrollo:
Podemos entender proceso de
software como un marco de trabajo de las tareas que se requieren para construir
software de alta calidad. Éstos surgieron como la respuesta a la necesidad de
establecer una estrategia de desarrollo para cada paso que se requiere al
momento de desarrollar software; como los procesos, métodos y herramientas
implementadas.
Es importante que durante el
proceso no se abandone el modelo, esto quiere decir, se debe seguir desde el
inicio del proyecto hasta el final. Sin
embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de
vida) ni cómo realizar las diferentes actividades incluidas en cada proceso,
por lo que cada empresa deberá utilizar los métodos, técnicas y herramientas
que considere oportuno.
Cada uno de los modelos es una
representación de un proceso real, esto quiere decir, cada uno de estos se
adapta a cada una de las necesidades que requieran los desarrolladores. No hay
un modelo absoluto.
Estos son algunos ejemplos con
sus respectivas características:
Modelo lineal (o en cascada)
-El más antiguo de los modelos
de Ingeniería del Software.
-Presenta una estructura
secuencial formada por seis etapas:
Análisis de Sistema: Establece requisitos de todos los
elementos del sistema
Análisis de requisitos de Software: Se analizan las
necesidades de los usuarios finales para delimitar
un objetivo
Diseño:
Traduce los requisitos en una
representación del software con la calidad requerida antes de que comience la
codificación
Estructura de datos
Arquitectura del software
Detalle procedimental
Caracterización de la interfaz
Codificación: Fase de programación.
Prueba:
Se centra en la lógica interna del software, y en las funciones externas
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren.
Mantenimiento:
Es muy probable que se deban realizar modificaciones al software después de
haber hecho la entrega al cliente. Dichos cambios son con la finalidad de
corregir errores, se deba adaptar a cambios o existan nuevos requerimientos.
-No permite retroceder, al
final de cada fase es necesario que el analista verifique y valide todo el
trabajo realizado.
-Desventajas
No siempre se sigue este flujo de secuencia en la realidad,
siempre hay iteraciones.
Puede
ser complicado que el cliente especifique bien los requerimientos al inicio del
proyecto.
Hasta
llegar a las etapas finales, no estará disponible una versión operativa del
programa.
-Ventajas
Es sencillo seguir los pasos intuitivos necesarios para su
desarrollo.
Modelo en espiral.
-Se desarrolla en una serie de
versiones incrementales.
-Se integra de los siguientes
pasos:
Planificación:
Se definen los objetivos, las alternativas y las restricciones, se analiza e
identifican los riegos.
Análisis
de Riesgos: Se analiza el proyecto y se toma la decisión de si se debe
continuar con el ciclo.
Ingeniería
(Construcción del prototipo): Se desarrolla y se valida.
Evaluación
del cliente: El cliente evalúa y sugiere modificaciones.
- Utiliza un enfoque
evolutivo, permitiendo al desarrollador y al cliente entender y reaccionar a
los riesgos en cada nivel.
Modelo incremental:
-Evolución del modelo de
casada
-Es un modelo no secuencial
-Comienza con el análisis de
los requerimientos
-Realiza iteraciones para
bifurcar diseños, es decir, comienza el diseño arquitectura, estructura, etc.
del software, puede comenzar con una segunda iteración sin necesidad de
modificar los requerimientos.
-Puede realizar tantas
iteraciones como sean necesarias.
-El primer incremento a menudo
es un producto esencial.
- El modelo de proceso
incremental, como la construcción de prototipos y otros enfoques evolutivos, es
iterativo por naturaleza
-Se centra en la entrega de un
producto operacional con cada incremento. Los primeros incrementos se pueden
implementar con menos personas
Proceso Unificado de
Desarrollo
-Guía para administrar el
desarrollo iterativo de un modo controlado
Requerimientos de negocio
Tiempo al mercado
Riesgos del proyecto
-Está basado en componentes.
-Utiliza UML para expresar
gráficamente todos los esquemas de un sistema de software.
-Iterativo e incremental.
-Dirigido por casos de uso
-Centrado en la arquitectura.
Conclusión:
Podemos analizar con esto que
cada uno de estos procesos tiene características específicas que se adaptan a
los diferentes proyectos que se puedan realizar. Conforme han pasado los años
se van visualizando nuevas necesidades y se forman procesos más dinámicos para
la resolución de problemas.
Referencias:
- Baetjer, H. (2009). dsc.itmorelia.edu.mx. Obtenido de https://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&sqi=2&ved=0ahUKEwj56LD5n_fKAhUCOiYKHfKdB-oQFgggMAE&url=http%3A%2F%2Fdsc.itmorelia.edu.mx%2F~jcolivares%2Fcourses%2Fsdf11b%2Fsdf_p4.doc&usg=AFQjCNEcbMnY2x6Cq--wB1rozMn0FHeaEg
- de Desarrollo, P. U. Modelos de Proceso del Software.
- Adaptada de la presentación original “Ingeniería de Software” de Gloria Lucia Giraldo Gómez. Universidad Nacional de Colombia. Sede Medellín.
06 febrero 2016
Cuestionario: Métodos ágiles de programación
1. Los métodos ágiles se utilizan
en:
a)
Programación
Orientada a Objetos
b)
Desarrollo
de software
c)
Soporte
de Software
d)
Programación
estructurada
e)
Calidad
de Software
2. ¿Qué modelo de desarrollo de
software utilizan los métodos ágiles?
a)
Cascada
b)
Lineal
c)
Iterativo
d)
Espiral
e)
Evolutivo
3. ¿Cuáles son las principales
características en las que se basa el método ágil?
a)
Trabajo
en equipo, adaptable, avances funcionales
b)
Satisfacción
del cliente, reduce tiempo, una sola entrega final.
c)
Comunicación,
no se adapta a los cambios, no es interactivo.
d)
Orientado
a resultados, no hay comunicación, no hay trabajo en equipo
4. ¿Cuáles son las características
que diferencian al método ágil del
convencional?
a)
El
cliente participa en el equipo de desarrollo
b)
Trabajo
en equipo
c)
Satisfacción
del cliente
d)
Presenta
avances incrementales del proyecto al cliente
e)
Adaptable
en cualquier etapa del proyecto
5. En los métodos ágiles el
cliente:
a)
Desarrolla
Software
b)
Se
incorpora al equipo de trabajo
c)
Trabaja
en otros proyectos de software
d)
Resuelve
problemas de comunicación del equipo
e)
Proporciona
los recursos materiales
Suscribirse a:
Entradas (Atom)