Ingenieria de Software
| Más


Si requiere informacion adicional o tiene alguna sugerencia para mejorar este sitio por favor pongase en contacto con nosotros, con gusto atenderemos sus requerimientos

Si buscas hosting web, dominios web, correos empresariales o crear páginas web gratis, ingresa a PaginaMX
Por otro lado, si buscas crear códigos qr online ingresa al Creador de Códigos QR más potente que existe


METODOLOGIAS CRYSTAL EN METODOS AGILES

                                       INTRODUCCION
Las metodologías ágiles, se han comenzado ha desarrollar hace muy poco tiempo, dentro de estas encontramos la Metodología Cristal la cual identifica con colores diferentes cada método, y su elección debe ser consecuencia del tamaño y criticidad del proyecto, de forma que los de mayor tamaño, o aquellos en los que la presencia de errores o desbordamiento de agendas implique consecuencias graves, deben adoptar metodologías más pesadas. De esta forma se pretende obtener mayor rentabilidad en el desarrollo de proyectos de software, Los métodos Crystal no prescriben prácticas concretas, porque están en continuo cambio.

PLANTEAMIENTO
Las metodologías Ágiles, son una herramienta que nos facilita en el desarrollo de software, De esta forma se agilizan los procesos de construcción de proyectos. También se puede observar que por medio de estas metodologías podemos obtener más fiabilidad y calidad en menos tiempo y con menos costo. Estas metodologías dependen de dos factores importantes como lo son El número de personas en el proyecto, y Las consecuencias de los errores. Su nombre se debe a las facetas de una gema: cada faceta es otra versión del proceso, y todas se sitúan en torno a un núcleo idéntico. Dado que el tamaño del proyecto indica el método a utilizar, se estableció una clasificación por colores, por ejemplo Cristal Crear (3 a 8 personas), seguido por Yellow (10 a 20 personas), Crystal Orange (25 a 50 personas), y así sucesivamente hasta azul, mientras que la importancia indica la dureza con que se debe aplicar. También el código matemático se aplica de forma tabular y se sitúa un rango de complejidad al cual se aplica una metodología.

También podemos encontrar dentro de estas metodologías ágiles la metodología llamada Clear, la cual se basa La más documentada es Crystal Clear (CC) al igual que la Crystal Orange apto para proyectos de duración estimada en 2 años.
CC puede ser usado en proyectos pequeños y como casi todos los otros métodos, CC consiste en valores, técnicas y procesos. Y las propiedades de CC son Entrega frecuente, Comunicación osmótica, Mejora reflexiva, Seguridad personal, foco. Fácil acceso a usuarios expertos, También están compuestas por unas técnicas, procesos, y existen unos roles para cada persona que integra el desarrollo del software.

Existen software basados en metodologías cristal las cuales Integran estrechamente capacidades de diseño, modificación y visualización en aplicaciones .NET, Java o COM. También Permitir a los usuarios finales acceder e interactuar con los reportes a través de portales Web, dispositivos móviles y documentos de Microsoft Office®. De esta forma podemos darnos cuenta que la aplicación de estas metodologías son extremadamente recomendables en el buen desarrollo de proyectos de software.

 

DESARROLLO

Se tiene en cuenta que Crystal da vital importancia a las personas que componen el equipo de un proyecto, y por tanto sus puntos de estudio son: Aspecto humano del equipo, Tamaño de un equipo (número de componentes), Comunicación entre los componentes, Distintas políticas a seguir, Espacio físico de trabajo. Compuesta por una características importantes como lo son Crystal aconseja que el tamaño del equipo sea reducido (Pocos componentes) También La mejora de la comunicación entre los miembros del equipo del proyecto, El Mismo lugar de trabajo à Disminuye el coste de la comunicación y Mejora individual à Mejora global del equipo, de esta forma se tienen en cuenta las políticas de equipo “Se utilizarán políticas diferentes para equipos diferentes” Codificación por colores de Crystal: esto Dependiendo del tamaño del equipo.

3-8
10-20
25-50
50-100
100-200
200-500
800+

También podemos hablar de las herramientas y de los roles de las personas involucradas Executive Sponsor (Patrocinador Ejecutivo) Project Manager (Jefe de Proyecto) Domain Expert (Experto en el Dominio), Usage Expert (Experto de uso), Designer-Programmer (Programador Diseñador), UI Designer (UI Diseñador), Tester (Realizador de Pruebas), Technical (Programador Técnico) y las herramientas que son las siguientes, Sampler Catalog, Use Cases, Non funcional Reqts, Architecture, Tests Cases, Writing Use, Responsabiliy, Program. Después de esto se puede hablar de los elementos basicos de las metodologías son los elementos a combinar para el éxito en un proyecto de desarrollo: estos son Quality, Tools, Products, Teams, Standards, Roles, Activities, Skins, Techniques. La importancia del tamaño de un equipo es algo que no se puede dejar del lado se puede tener presente que el Desarrollo + Tamaño de equipo produce Metodología más pesada. También la importancia de la comunicación La comunicación es más barata y mejor cuanto más “cercana” sea.
Crystal recomienda la interacción cara a cara, por ser éste el mejor método de comunicación.

Dentro de esta metodología podemos encontrar la FDD es un método ágil, iterativo y adaptativo. A diferencia de otras Metodologías Ágiles, no cubre todo el ciclo de vida sino sólo las fases de diseño y construcción y se considera adecuado para proyectos mayores y de misión crítica. FDD no requiere un modelo específico de proceso y se complementa con otras metodologías. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluación del progreso. FDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye el sistema. La parte iterativa soporta desarrollo ágil con rápidas adaptaciones a cambios en requisitos y necesidades del negocio. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida. Típicamente, la iteración de un rasgo emplea de una a tres semanas. Las fases se describen a continuación: Desarrollo de un modelo general, Construcción de la lista de rasgos, Planeación por rasgo, Diseño por rasgo y Construcción por rasgo. Por medio de estas metodologías podemos hacer los proyectos mas optimos y con mayor calidad. Lo cual hace que el cliente se sienta con superior tranquilidad de solicitar un buen desarrollo de software.

CONCLUSIONES
 

Cuantas más personas estén implicadas, más grande debe ser la metodología.
Si el proyecto tiene mucha densidad, un error no detectado puede ser crítico.
El aumento de tamaño o densidad añade un coste considerable al proyecto.
La forma más eficaz de comunicación es la interactiva (cara a cara).
En las dos últimas décadas las notaciones de modelado y posteriormente las herramientas han sido las "balas de plata" para el deseado éxito en el desarrollo de software. El proceso de desarrollo asumido en este contexto llevaba asociada una marcada tendencia hacia el control del proceso mediante una rigurosa definición de actividades, artefactos y roles. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo en proyectos de gran envergadura 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 contexto es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. En la práctica, para muchos equipos de desarrollo, ante las dificultades para utilizar metodologías tradicionales, se llegó a la resignación de prescindir del "buen hacer" de la ingeniería del software con el objetivo de ajustarse a estas restricciones. Ante esta situación, las metodologías ágiles aparecen como una posible respuesta para llenar este vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las metodologías ágiles constituyen una solución a medida, con una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto.

El tema es de rabiosa actualidad. La curiosidad que siente la mayor parte de ingenieros de software, profesores, e incluso alumnos, sobre los métodos ágiles hace prever una fuerte proyección industrial de las metodologías ágiles. Por un lado, para muchos equipos de desarrollo el uso de metodologías tradicionales les resulta muy lejano a su forma de trabajo actual considerando las dificultades de su introducción e inversión asociada en formación y herramientas. Por otro, las características de los proyectos para los cuales las metodologías ágiles han sido especialmente pensadas se ajustan a unamplio rango de proyectos industriales de desarrollo de software; aquellos en los cuales los equipos de desarrollo son pequeños, con plazos reducidos, requisitos volátiles, nuevas tecnologías, etc. Esto último abriría interesantes canales de cooperación entre la industria y la universidad. 

Tipos de metodologías de desarrollo de software 

Existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso 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 . 

Metodologías ágiles que se centran especialmente en el factor humano o el producto de software, ósea  dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo 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. 

Hay que tener en cuenta que la frase “mantener una alta calidad” se ve como un objetivo que personalmente, pienso que se cumple en cierta medida, ósea que no se mantiene del todo. Esto debido a que la optimización de tiempo a tiempo drástico que se define en  este texto, no me parece posible del todo.

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. 

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.  

METODOLOGÍAS ÁGILES 

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado al desarrollo de software.

Esto nos habla que las metodologías agiles de programación son realmente nuevas, sin embargo algunos desarrolladores piensan que representan la nueva era del 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 

El punto de partida es fue el Manifiesto Ágil, un documento que resume la filosofía “ágil”. 

Según el Manifiesto se valora:

  • Al individuo y las interacciones del equipo de desarrollo  sobre el proceso y las herramientas.
  • Es más importante construir un buen equipo que construir el entorno. 
  • Desarrollar software que funciona más que conseguir una buena documentación.

  “No producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”. 

  • La colaboración con el cliente más que la negociación de un contrato. 
    • Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.   
  • Responder a los cambios más que seguir estrictamente un  plan. 
    • Se debe ser hábil en responder a los cambios y a los fracasos, la planificación no debe ser estricta sino flexible y abierta.  

 

Metodologías Ágiles 

 

 

Metodologías Tradicionales

 

 

Basadas en heurísticas provenientes de prácticas de  producción de código 

 

Basadas en normas provenientes de estándares

seguidos por el entorno de desarrollo  

 

Especialmente preparados para  cambios durante el proyecto  

 

Cierta resistencia a los cambios  

 

Impuestas internamente (por el equipo) 

 

Impuestas externamente  

 

Proceso mucho más controlado, con numerosas

políticas/normas  

 

Proceso menos controlado, con pocos principios  

 

No existe contrato tradicional o al menos es bastante flexible  

 

Existe un contrato prefijado  

 

El cliente interactúa con el equipo de desarrollo  

 

El cliente es parte del equipo de desarrollo mediante reuniones  

 

Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio  

 

Grupos grandes y posiblemente distribuidos  

 

Pocos artefactos

 

Más artefactos  

 

Pocos roles 

 

Más roles  

 

Menos énfasis en la arquitectura del software  

 

La arquitectura del software es esencial y se

expresa mediante modelos  

Tabla 1. Diferencias entre metodologías ágiles y no ágilesDentro de la familia de las metodologías ágiles de desarrollo hay una variedad importante. Debemos hacer hincapié en el hecho de que todas se basan en los 12 principios propuestos en el Manifiesto Ágil, pero que cada una explota de manera difrente y en diferente grado cada uno de estos puntos. 

De esta manera podemos elegir una de las metodologías ágiles para cada tipo de proyecto, de forma que al priorizar ciertos puntos y al conocer las metodologías hacemos un trabajo mejor acabado y mas rápido. 

 Crystal Methodologies 

  Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo 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 equi 

Dynamic Systems Development Method (DSDM) 

 Define el marco para desarrollar un  proceso de producción de software. Nace en 1994 con 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)

 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. 

 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.

© 2024 Ingenieria de Software