ingenieriadesw

[ingenieriadesw]

Conceptos básicos

[1] Software Engineering, Theory and Practice, 4 edition

Shari Lawrence Pfleeger and Joanna M. Atlee.

[ingenieriadesw]

Extreme programming

Es un modelo que pertenece a las metodologías ágiles. Es una disciplina de desarrollo de software basada en los valores de la sencillez, la comunicación, la retroalimentación y coraje. Su acción consiste en traer todo el equipo juntos en la presencia de prácticas simples, con información suficiente para que el equipo para ver dónde están y para ajustar las prácticas a su situación particular.

Actividades que se realizan en este modelo:

Whole Team: En esta actividad, se sientan juntos todos los integrantes del proyecto, incluyendo una representante de negocio (el cliente), quien va a dar los requerimientos, las propiedades y dirigirá el proyecto es mejor si el este representante, es el verdadero usuario final de sistema, pues ya que sabe con exactitud las necesidades que se tienen. El equipo obviamente debe integrar programadores, así como también testers (probadores), un analista que va a ayudar al cliente a expresar de manera más clara e interpretar para los programadores, también debe existir un coach que ayudará a mantener al equipo unido y así facilitar el proceso.

Planning game: En esta actividad si toman en cuenta dos puntos claves para el desarrollo del software, la planeación de lanzamiento y la planeación de las iteraciones, en la primera, es donde el cliente presenta a los programadores las necesidades y una fecha aproximada de entrega, los programadores calculan la dificultad y los costos que esto conlleva para llegar a un acuerdo con el cliente.

En la planeación de las iteraciones, se tienen periodos de dos semanas en los cuales los programadores tienen que cubrir los primero requerimientos del cliente y entregar el resultado después de estas iteraciones de dos semanas, y el cliente presenta los nuevos requerimientos para la siguiente iteración.

Customer Tests: Se puede realizar esta actividad después de la primera iteración, en ella el “cliente“ en el equipo realizará las actividades pertinentes para determinar si el sistema cumple o no con las especificaciones dadas, y se auxiliará del analista para esta actividad, pues el es quién tradujo las necesidades a los programadores.

Small Releases: En esta actividad se presentan pequeños avances en dos importantes puntos. Primero el equipo lanza corriendo, el avance del software probado, entregando valores de negocio elegido por el cliente, cada iteración. El cliente puede utilizar este software para cualquier propósito, si la evaluación o incluso liberar a los usuarios finales (muy recomendable). El aspecto más importante es que el software es visible, y la entrega al cliente, al final de cada iteración. Esto mantiene todo abierto y tangible.

En segundo lugar, los equipos XP lanzan el avance a sus usuarios finales con frecuencia también. En proyectos Web, los equipos XP liberan tan a menudo como todos los días, en los proyectos de vivienda mensuales o más frecuentes. Incluso productos encogidos se envían con la frecuencia de 3 meses.

Collective Code Ownership: En un proyecto de Extreme Programming, cualquier par de programadores puede mejorar cualquier código en cualquier momento. Esto significa que todo el código obtiene el beneficio de atención de muchas personas, lo que aumenta la calidad del código y reduce los defectos. Hay otro beneficio importante, así: cuando el código es propiedad de los individuos, las características requeridas a menudo se ponen en el lugar equivocado, como un programador descubre que tiene una característica de código en algún lugar que no es de su propiedad. El propietario está demasiado ocupado para hacerlo, por lo que el programador pone la función en su propio código, en donde no pertenece.

Coding Standard: Como muchos pares de programadores pueden estar involucrados en el proyecto es importante regular un estándar de codificación para que todos los programadores puedan entender clara y rápidamente que es lo que se está haciendo en una parte del código, puesto que ya sabemos que cada programador tiene su estilo, lo que se busca en esta actividad es precisamente que sea un estilo que todos puedan utilizar y entender.

Metaphor: Equipos de Extreme Programming desarrollan una visión común de cómo funciona el programa, lo que le llama  metaphor (metáfora) y consiste en una simple descripción evocadora de cómo funciona el programa, tales como "este programa funciona como una colmena de abejas, salir a polen y llevarlo a la colmena" como una descripción de un sistema de información basado en agentes de recuperación.

Como podemos observar este modelo es bastante practico para cuando se requiere un sistema que está en constante movimiento, sería adecuado utilizarlo para un sistema en la web, que requiere una comunicación con el cliente muy frecuente y un trabajo en equipó por parte de los programadores a fin de que no solo sea útil la funcionalidad, sino también la parte del diseño visual del sistema sea atractivo, sin en cambio no sería adecuado utilizar esta metodología en un sistema de investigación relacionado con la ciencia, como por ejemplo un sistema para calcular fenómenos relacionados con la geología de la tierra,  quizá para esos propósitos, un modelo incremental o en espiral sería más adecuado.

[ingenieriadesw]

Modelo de Procesos en Espiral

Es un modelo propuesto por Barry Boehm, que se basa en experiencias de grandes sistemas para el gobierno,  y en el se introduce el termino de reducción de riesgos en el desarrollo del software, proporciona un enfoque ciclico del desarrollo gradual del sistema, reduciendo los riesgos por los que pasa en cada ciclo.

Tiene 4 cuadrantes como se muestra en la figura:

Las actividades que se realizan en este modelo son las siguientes:

1.- Identificar los objetivos, alternativas y restricciones de cada ciclo del espiral 

2.- Se evalúan las alternativas relativas a los objetivos y restricciones, en esta etapa son identificados y evaluados  algunos de los riesgos.

3.- Dependiendo de los riesgos identificados, en esta fase se desarrolla un prototipo que puede ser modificado más a detalle cuando se vuelva a pasar por este cuadrante en otro ciclo del espiral, por otra parte, si el riesgo se redujo substancialmente, el siguiente paso será la toma de requisitos, diseño y código como en el modelo en cascada. 

4.- Se evalúan los logros con respecto a los objetivos y se planea el siguiente ciclo del espiral.

Como podemos observar, este modelo se puede utilizar para un sistema que requiere mucho análisis y es por eso que se hacen ciclos, puesto que ya sabemos que el análisis es quizá la etapa que consume más tiempo para la resolución de un problema, en problemas tan grandes y con altos riesgos, pasaríamos muchísimo tiempo en esta etapa, es por eso que se realizan prototipos y avanzar, para después volver al análisis en el siguiente ciclo. Para un sistema sencillo en el cual no se tienen riesgos, este modelo sería inútil, ya que generaríamos artefactos quizá innecesarios y le estaríamos dando mucho la vuelta, si el problema se puede resolver mejor con el modelo en cascada.

[ingenieriadesw]

Modelo de Procesos Incremental

Este modelo puede verse visto como una modificación del modelo en cascada, en los primeros años que se tiene la ingeniería de software se pensaba que el modelo en casacada, que fue uno de los primeros era el más eficaz ya que se basa en abstraer la producción de un producto común de manera en que no podemos avanzar de una fase, sin antes terminar otra. Por ejemplo en la elaboración de un pastel; es decir no podemos cubrir de crema el pastel, sin antes haber hecho el pan.

El modelo incremental consistía en dividir el problema en módulos más pequeños y resolver los nuevos problemas de manera imcremental e iterativa, todos los componentes eran integrados y probados de manera conjunta en la fase final de esta manera, se permitia que si alguno de los modulos fallaba, los demás podían seguir de manera independiente, básicamente este modelo adopta la frase de divide y venceras. El problema de este modelo es que los componentes se entrelazan y hacen que sea dificil el desacoplamiento de las partes independientes.

Las actividades que se realizan en este modelo son:

Recaudo de requisitos: En esta actividad, como su nombre lo dice, se obtienen las funciones que debe realiazar el sistema, como ya sabemos, existen varias clasificaciones de requisitos, los más comunes: requisitos funcionales y no funcionales.

Diseño: En esta etapa se analiza el problema y se planea, cómo se van a resolver los requisitos principales del sistema en la primera iteración.                                                                                             

Codificación: Se representa la fase anterior en el leguaje de programación elegido. 

Pruebas: Se realiza una secuencia de pruebas para comprobar que la funcionalidad es correcta, esto no implica que no se puede continuar con el siguiente requisito, si en la primera iteración hay errores o resultados no deseados, se puede continuar y  resolver los problemas en futuras iteraciones.

Entrega: Se presenta el avance del sistema conforme cada iteración y se toman en cuenta los errores que se hayan dado en la mísma.

Como podemos ver, este modelo es útil cuando tenemos el tiempo adecuado para la realización de un sistema y  la interaccón con el cliente es continua, ya se que se van mostrando los avances y pueden surgir nuevos requerimentos y arreglar los errores de las primeras iteraciones.

[ingenieriadesw]

Modelos de procesos para el desarrollo de Software

Muchas veces nos preguntamos, ¿cómo hacen los grandes sistemas de cómputo? Y es que cuando pensamos en hacer un programa o una aplicación, nos imaginamos cómo quedaría el código o en que lenguaje lo haríamos, etc. Sin embargo, para los grandes sistemas no existe una receta que nos diga que pasos llevar a cabo para poder desarrollarlos, ya que se tiene que pensar antes de la parte de la implementación o de la programación, en toda la etapa de análisis y planeación que es la base fundamental para el entendimiento del problema y por ende el buen funcionamiento del mismo.

 Para tener una idea de cómo proceder ante el desarrollo de un sistema, surgen propuestas que van a ser como un tipo de molde u orden de los posibles pasos a realizar para obtener el sistema y a estos se les conoce como Modelos de Procesos, en ellos, diferentes autores expresan su propuesta para proceder y cada uno de los modelos tiene sus propios artefactos y técnicas para los diferentes fines u objetivos de los sistemas. Existen diferentes modelos como el cascada, espiral, prototipos, el RUP ( rational unified process), incremental, desarrollo rápido de aplicaciones, ágiles, etc. En este blog se pretenden describir los modelos:

Incremental

Extreme programming que pertenece a las metodologías ágiles

Modelo en espiral