domingo, 28 de febrero de 2016
domingo, 21 de febrero de 2016
Métodos Ágiles de Programación || Cuestionario y Mapas 3 y 4 ||
Presentación 4:
¿Qué
es la Programación Extrema?
La
programación extrema es una metodología de desarrollo ágil que tiene como
principal objetivo aumentar la productividad a la hora de desarrollar un
proyecto software. Da prioridad a los trabajos que dan un resultado directo y
en los cuales se reduce la burocracia que pueda existir en el entorno de
trabajo.
Esta
metodología tiene como base la simplicidad y como objetivo principal la
satisfacción del cliente
¿Cuáles
son los valores y principios de la
Programación Extrema?
Comunicación
Es
muy importante que haya una comunicación constante con el cliente y dentro de
todo el equipo de trabajo, de esto dependerá que el desarrollo se lleve a cabo
de una manera sencilla, entendible y que se entregue al cliente lo que
necesita.
Simplicidad
En
la XP se refiere que ante todo y sin importar qué funcionalidad requiera el
usuario en su sistema, éste debe ser fácil. El diseño debe ser sencillo y
amigable al usuario, el código debe ser simple y entendible, programando sólo
lo necesario y lo que se utilizará.
Retroalimentación
Es
la comunicación constante entre el desarrollador y el usuario.
Coraje
Se
refiere a la valentía que se debe tener al modificar o eliminar el código que
se realizó con tanto esfuerzo; el desarrollador debe saber cuando el código que
desarrolló no es útil en el sistema y, por lo mismo, debe ser eliminado.
También se refiere a tener la persistencia para resolver los errores en la
programación.
Dentro
de la programación extrema se tiene 12 principios que llevan o guían el
desarrollo con esta metodología:
1.
El principio de pruebas
2.
Proceso de planificación
3.
El cliente en el lugar
4.
Programación en parejas
5.
Integración continua
6.
Refactorización
7.
Entregas pequeñas
8.
Diseño simple
9.
Metáfora
10.
Propiedad colectiva del código
11.
Estándar de codificación
12.
La semana de 40 horas
¿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, me explico 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). Cuando implementamos nuevas características en nuestros programas
nos planteamos la manera de hacerlo lo mas simple posible, después de
implementar esta característica, nos preguntamos como hacer el programa mas
simple sin perder funcionalidad, este proceso se le denomina recodificar o
refactorizar (refactoring).
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
mas 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 mas simple posible, después de implementar
esta característica, nos preguntamos como hacer el programa mas simple sin
perder funcionalidad, este proceso se le denomina recodificar o refactorizar
(refactoring). No debemos de recodificar ante especulaciones si no solo cuando
el sistema te lo pida.
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 mas 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. El viernes quiero estar cansado y satisfecho para sentir
que tengo dos días para pensar en algo distinto y volver el lunes lleno de
pasión e ideas. 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.
No es fácil aplicar una nueva
metodología en un equipo de desarrollo ya que obliga a aprender una nueva forma
de trabajar. También obliga a abandonar cómo se hacían las cosas antes, que
aunque no fuera la mejor forma posible ya se conocía. 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 aplicarla. 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.
Bibliografia:
http://www.ecured.cu/Programaci%C3%B3n_Extrema_(XP)
--------------------------------------------------------------------------------------------------------------------------
Presentación 3:
¿Qué son las metodologías ágiles de desarrollo de software?
Las metodologías ágiles son una serie de técnicas
para la gestión de proyectos que han surgido como contraposición a los métodos
clásicos de gestión como CMMI. Aunque surgieron en el ámbito del desarrollo de
software, también han sido exportadas a otro tipo de proyectos.
¿Cuáles son las características en las que se basan las metodologías
ágiles?
Los individuos y su interacción, por encima de los
procesos y las herramientas.
El software que funciona, frente a la documentación
exhaustiva.
La colaboración con el cliente, por encima de la
negociación contractual.
La respuesta al cambio, por encima del seguimiento
de un plan.
¿Cuáles son las ventajas y desventajas del empleo de las
metodologías ágiles respecto a las
tradicionales?
Ventajas:
Rápida respuesta al cambio de los requisitos a lo
largo del desarrollo
El cliente es parte del equipo de desarrollo
Importancia
de la simplicidad al eliminar trabajo innecesario
Desventajas:
Falta de documentación del diseño. Al no haber
documentación es el código (junto con sus comentarios) lo que se toma como
documentación.
Problemas derivados de la comunicación oral. No
hace falta decir que algo que está escrito “no se puede borrar”, en cambio,
algo dicho es muy fácil crear ambigüedad.
Fuerte dependencia de las personas.
Falta de reusabilidad derivada de la falta de
documentación
Restricciones en cuanto a tamaño de los proyectos
¿Cuándo es recomendable utilizar metodologías ágiles en el desarrollo de software?
-Cuando se tiene un proyecto pequeño en tiempo o
con un equipo de desarrollo reducido de 3 a 8 personas
-Requerimientos dinámicos; cuando te encuentras
ante un ámbito de actuación los puntos de vista de análisis estan
constantemente cambaindo como podría ser un datamart de fuerza de ventas
-Si tu cliente tiene tiempo para dedicarlo al
proyecto
-Si se tiene un equipo de desarrollo con un nivel
mayor a junior, en general las
metodologías ágiles requieren de una gran madurez, experiencia y una dosis de
talento.
¿Cuáles son algunos tipos de metodologías ágiles?
Programación Extrema, es uno de los ejemplos más
exitosos de metodología ágil.
Scrum
Crystal
Evolutionary Project
Management (Evo)
Feature Driven Development
(FDD)
Adaptive Software
Developmen(ASD)
Lean Development (LD) y
Lean Software Development (LSD)
Proceso Unificado de Desarrollo Software
Bibliografía:
domingo, 14 de febrero de 2016
PROF. JUAN MANUEL CRUZ
CECyT 9 "JUAN DE DIOS BATIZ"
INSTITUTO POLITÉCNICO NACIONAL
MÉTODOS ÁGILES DE LA PROGRAMACIÓN
CONCEPTUAL MAP METODOS DE SOFTWARE
Referencias: *Piattini, A. C. (2005). Ingenieria del software basada en componentes. Buenos Aires : Revista de Tecnología. *Roldán, C. S. (2013). Codejobs . Recuperado el 14 de febrero de 2016, de https://www.codejobs.biz/es/blog/2013/05/25/el-proceso-del-software *Ruiz, F. (2009). Ingenieria del software. Cantabria: Universidad de Cantabria.
domingo, 7 de febrero de 2016
MÉTODOS ÁGILES DE PROGRAMACIÓN
INTRO:
En las dos últimas décadas las notaciones de modelado y posteriormente las herramientas de desarrollo de software pretendían ser el éxito en el desarrollo de software, sin embargo, las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante elemento, la metodología de desarrollo, había sido postergado. De nada sirven buenas notaciones y herramientas si no se proveen directivas para su aplicación. Así, esta década ha comenzado con un creciente interés en metodologías de desarrollo. Hasta hace poco el proceso de desarrollo llevaba asociada un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drástica mente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del “buen hacer” de la ingeniería del software, asumiendo el riesgo que ello conlleva. En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto.
Las metodologías ágiles son sin duda uno de los temas recientes en ingeniería de software que están acaparando gran interés. Prueba de ello es que se están haciendo un espacio destacado en la mayoría de conferencias y workshops celebrados en los últimos años. Es tal su impacto que actualmente existen 4 conferencias internacionales de alto nivel y específicas sobre el tema Además ya es un área con cabida en prestigiosas revistas internacionales.
CUERPO:
En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término "ágil" aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Varias de las denominadas metodologías ágiles ya estaban siendo utilizadas con éxito en proyectos reales, pero les faltaba una mayor difusión y reconocimiento.
Aunque los creadores e impulsores de las metodologías ágiles más populares han suscrito el manifiesto ágil y coinciden con los principios enunciados anteriormente, cada metodología tiene características propias y hace hincapié en algunos aspectos más específicos. A continuación se resumen dichas metodologías ágiles, dejando el análisis más detallado de XP para la siguiente sección.
- SCRUM. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto. Éstas son las verdaderas protagonistas, especialmente la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.
- Crystal MethodologiesSe trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).
- Dynamic Systems Development Method (DSDM) Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases.
- Adaptive Software Development (ASD) Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.
- Feature-Driven Development (FDD) Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad.
- Lean Development (LD) Definida por Bob Charette’s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios.
UN Ejemplo de como se han mejorado algunos procesos debido a la aplicación de los métodos ágiles de programación se muestra en la siguiente tabla:
CONCEPTUAL MAP:
DESENLACE:
No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos que tienen estas características. Una de las cualidades más destacables en una metodología ágil es su sencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costos de implantación en un equipo de desarrollo. Esto ha llevado hacia un interés creciente en las metodologías ágiles. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicación, tales como: están dirigidas a equipos pequeños o medianos (Beck sugiere que el tamaño de los equipos se limite de 3 a 20 como máximo, otros dicen no más de 10 participantes), el entorno físico debe ser un ambiente que permita la comunicación y colaboración entre todos los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las prácticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboración y la relación contractual son claves), el uso de tecnologías que no tengan un ciclo rápido de realimentación o que no soporten fácilmente el cambio, etc.
BIBLIOGRAFIA:
Abrahamsson,
P., Salo, O., Ronkainen, J., Warsta, J. "Agile software development
methods Review and analysis". VTT Publications. 2002.
Beck, K..
"Extreme Programming Explained. Embrace Change", Pearson Education,
1999. Traducido al español como: "Una explicación de la
programación extrema. Aceptar
el cambio", Addison Wesley, 2000.
Coad P.,
Lefebvre E., De Luca J. "Java Modeling In Color With UML: Enterprise
Components and Process". Prentice Hall. 1999.
Cockbun,
A., Williams, L. "The Costs and Benefits of Pair Programming". Humans
and Technology Technical Report. 2000.
Cockbun, A.
"Agile Software Development". Addison-Wesley. 2001.
Fowler, M.
"Is Design Dead?". 2001.
www.martinfowler.com/articles/designDead.html
Fowler, M.,
Foemmel M. "Continuous Integration". 2001.
www.martinfowler.com/articles/designDead.html
Fowler, M.,
Beck, K., Brant, J. "Refactoring: Improving the Design of Existing
Code". Addison-Wesley. 1999
CUESTIONARIO:
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
martes, 23 de junio de 2015
Costo Altas y consultas Conexión a Base de datos
Costo Altas
y consultas Conexión a Base de datos
En este
caso yo soy un programador de una empresa en la que por trabajar 8 horas diaria
me pagan
7000 pesos mensuales
Y un
cliente de la empresa solicita unas altas y consultas con JSP para el cual la
empresa me pide
realizar el programa, la empresa para la que trabajo cobra 20 dólares
la hora de programador,
Yo, me
tardo para ese programa aproximadamente 2 horas
2 horas = 40
dólares tipo de cambio 15.60 pesos
640 pesos
va a cobrarle mi empresa al cliente para el programa
Ahora 7000 pesos al mes / 20 días de trabajo = 350 pesos diarios
/ 8 horas
diarias = 43.75 pesos por hora, cobro yo.
Así que
para ese programa de dos horas me van a pagar 87.50 pesos de los 640 que cobra
la empresa
640 – 87.50 = 552.50 pesos de ganancia por parte de
la empresa, descontento mi sueldo por el programa.
Suscribirse a:
Comentarios (Atom)