ProgramingXtreme.blogspot.com
martes, 14 de julio de 2009
"Metodologia Orientada a Prototipos"
La Metodología de Prototipado Rápido, MPR, está orientada al desarrollo de prototipos y
fuertemente apoyada en tecnología de Bases de Datos y herramientas visuales para Desarrollo
Orientado a Objetos. En MPR se concentra un gran esfuerzo en la involucración del Usuario
en dos fases fundamentales: la definición del problema que se va a abordar y en la ejecución
de las pruebas, donde además se potencia el uso de lenguajes de cuarta generación utilizados
como lenguajes de consulta para verificar la estructura y funcionalidad del prototipo desarrollado,
asegurándose de que su diseño responde a las definiciones especificadas.
fuertemente apoyada en tecnología de Bases de Datos y herramientas visuales para Desarrollo
Orientado a Objetos. En MPR se concentra un gran esfuerzo en la involucración del Usuario
en dos fases fundamentales: la definición del problema que se va a abordar y en la ejecución
de las pruebas, donde además se potencia el uso de lenguajes de cuarta generación utilizados
como lenguajes de consulta para verificar la estructura y funcionalidad del prototipo desarrollado,
asegurándose de que su diseño responde a las definiciones especificadas.
Como se ha expuesto, la idea fundamental de MPR es el desarrollo de prototipos. Un
prototipo es un modelo inicial de lo que al final se corresponderá con la Base de Datos
definitiva y sus procedimientos asociados. Este prototipo se someterá a pruebas para comprobar
su funcionalidad, de las que surgirán modificaciones que darán origen a un segundo
prototipo, versión mejorada y posiblemente ampliada del primero, el cual se volverá a probar,
repitiéndose sucesivamente el proceso hasta alcanzar el prototipo definitivo.
La responsabilidad y ejecución de estas pruebas fundamentalmente recae, como ya se ha
mencionado, en el propio usuario, quien deberá de comprobar que el prototipo resultante es
capaz de resolver todos los problemas planteados en el momento de la definición de las
especificaciones del proyecto.
lunes, 13 de julio de 2009
Definicion de Rapid Prototyping
El Rapid Protoyping consiste en modelas el producto final y permite efectuar un test sobre determinados atributos del mismo sin necesidad de que este disponible. Se trata, simplemente, de progrmar al momento que el el gerente de una detemrina empresa va indicando como desearia que su automatizacion funcinara y que funciones quisiera que hiciera, haciendo uso del modelo.
ProgramingXtreme.blogspot.com
¿Como se lleva a cabo esta metodologia?
Se comienza elaborando un prototipo del producto final: qué aspecto tendrá, cómo funcionará,...Para muchas interfaces de usuario, este modelo puede resultar tan simple como unos dibujos con lápiz y papel o tan complejo como el propio código operativo final.
Para interfaces de hardware o estaciones de trabajo, el modelo puede consistir en maquetas de espuma, caucho, cartón o cartulina.
Cuanto más próximo se encuentre el prototipo al producto real, mejor será la evaluación, si bien se pueden obtener magníficos resultados con prototipos de baja fidelidad.
ProgramingXtreme.blogspot.com
¿Cuando puede Utilizarse Rapip Prototyping?
Esta técnica puede ser utilizada en cualquier etapa del desarrollo. A medida que el proceso progresa y el producto se completa, el prototipo ha de abarcar, cada vez más las características del producto final. Llegados a un punto, la construcción de prototipos adicionales resultará menos eficiente que usar las construcciones iniciales para el producto.
Hay un cierto número de términos que se oyen en conjunción con los métodos de prototipado.
Los siguientes son una muestra de algunas de estas distinciones:
Metodos de Prototipado "Rapid Prototyping"
- Prototipado rápido (Rapid Prototyping)
Metodología de diseño que desarrolla rápidamente nuevos diseños, los evalúa y prescinde del prototipo cuando el próximo diseño es desarrollado mediante un nuevo prototipo.
Prototipado reutilizable (Reusable Protyping)
También conocido como "Evolutionary Prototyping"; no se pierde el esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados para construir el producto real. Mayormente es utilizado en el desarrollo de software, si bien determinados productos de hardware pueden hacer uso del prototipo como la base del diseño de moldes en la fabricación con plásticos o en el diseño de carrocerías de automóviles.
Prototipado Modular (Modular Prototyping)
También conocido como Prototipado Incremental (Incremental prototyping); se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa.
Prototipado Horizontal (Horizontal Prototyping)
El prototipo cubre un amplio número de aspectos y funciones pero la mayoría no son operativas. Resulta muy útil para evaluar el alcance del producto, pero no su uso real.
Prototipado Vertical (Vertical Prototyping)
El prototipo cubre sólo un pequeño número de funciones operativas. Resulta muy útil para evaluar el uso real sobre una pequeña parte del producto.
Prototipado de Baja-fidelidad (Low-fidelity Prototyping)
El prototipo se implementa con papel y lápiz, emulando la función del producto real sin mostrar el aspecto real del mismo. Resulta muy útil para realizar tests baratos.
Protipado de Alta-fidelidad (High-fidelity Prototyping)
El prototipo se implementa de la forma más cercana posible al diseño real en términos de aspecto, impresiones, interacción y tiempo.
domingo, 12 de julio de 2009
Deficion de Xtreme Programing o Programacion Extrema
La programación extrema o Xtreme Programming (XP) es un enfoque de la ingeniería de software formulado 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.
- Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.
Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.
Caracterisiticas del Xtreme Programing
Características
Las características fundamentales del método son:
Las características fundamentales del método son:
Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo Pruebas de Regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi y NUnit para la plataforma.NET. Estas dos últimas inspiradas en JUnit.
Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
ProgramingXtreme.blogspot.com
Practicas de Desarrollo en Xtreme Programing
Este grafico representa como su titulo indica praticas de desarrollos en Xtreme Programing , mas sin embargo casi todas las metodologias existente a exepcion del Rapid Prototyping utilizan estas practicas de desarrollos al momento de iniciar y finalizar la creacion de un sistema de informacionProgramingXtreme.blogspot.com
Principios del Xtreme Programing
Principios
Los principios originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto principio, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco principios 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.
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.
Retroalimentación (feedback): 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.
Coraje o valentía: Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje?. Para los gerentes la programación en parejas puede ser difícil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores está escribiendo código. Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del código sin repercutir negativamente en la productividad.
Respeto:
El 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 se 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.
ProgramingXtreme.blogspot.com
Cuadro Comparativo de todas las Metodologias
- Para observar el cuadro comparativo en tamaño aumentado deja tu correo y con gusto te lo enviaremos "Atentamente FyM"
Suscribirse a:
Entradas (Atom)
