• Author / Uploaded
• Kamilo Ivan

Citation preview

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”.

 

 o

 o

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 Basadas

en

heurísticas

Metodologías Tradicionales provenientes

de Basadas en normas provenientes de estándares

prácticas de producción de código Especialmente preparados durante el proyecto

para

seguidos por el entorno de desarrollo cambios Cierta resistencia a los cambios

Impuestas internamente (por el equipo) Proceso mucho numerosas políticas/normas

más

controlado,

Impuestas externamente con Proceso menos principios

controlado,

con

pocos

No existe contrato tradicional o al menos es Existe un contrato prefijado bastante flexible El cliente interactúa con el equipo de El cliente es parte del equipo de desarrollo desarrollo mediante reuniones Grupos pequeños (