UNIVERSIDAD TECNOLÓGICA DE SAN JUAN
DEL RÍO.
TECNOLOGÍAS DE LA INFORMACIÓN Y DE LA
COMUNICACIÓN.
TIC01SM-15.
METODOLOGÍAS TRADICIONALES Y ÁGILES
METODOLOGÍA.
Hace referencia al camino o al conjunto de procedimientos racionales utilizados para alcanzar el objetivo o la gama de objetivos que rige una investigación científica, una exposición doctrinal o tareas que requieran habilidades, conocimientos o cuidados específicos.
(WIKIPEDIA, 2016)
PROGRAMACIÓN.
Es el proceso de diseñar, codificar, depurar y mantener el código fuente de programas computacionales.
(WIKIPEDIA, 2016)
METODOLOGÍA DE DESARROLLO DE
SOFTWARE.
Es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información.
Enfoques de desarrollo de software.
Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias metodologías específicas. Estos enfoques son los siguientes:
Modelo en cascada: Framework lineal.
Prototipado: Framework iterativo.
Incremental: Combinación de framework lineal e iterativo.
Espiral: Combinación de framework lineal e iterativo.
Modelo en cascada
Es un proceso secuencial, fácil de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implantación, pruebas (validación), la integración, y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce W. en 1970, aunque Royce no utiliza el término "cascada" de este artículo.
Los principios básicos del modelo de cascada son los siguientes:
El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.
Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez. Un estricto control se mantiene durante la vida del proyecto a
través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff por el usuario y la tecnología de la información de gestión al final de la mayoría de las fases antes de comenzar la próxima fase.
Prototipado
El prototipado permite desarrollar modelos de aplicaciones de software que permiten ver la funcionalidad básica de la misma, sin necesariamente incluir toda la lógica o características del modelo terminado. El prototipado permite al cliente evaluar en forma temprana el producto, e interactuar con los diseñadores y desarrolladores para saber si se está cumpliendo con las expectativas y las funcionalidades acordadas. Los Prototipos no poseen la funcionalidad total del sistema pero si condensa la idea principal del mismo, Paso a Paso crece su funcionalidad, y maneja un alto grado de participación del usuario.
Incremental
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro.
Los principios básicos son:
Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del sistema.
El concepto inicial de software, análisis de las necesidades, y el diseño de la arquitectura y colectiva básicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalación del prototipo final.
Espiral
Los principios básicos son: La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo el proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo, así como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideración de la continuación del proyecto durante todo el ciclo de vida.
Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: determinar objetivos, alternativas, y desencadenantes de la iteración; Evaluar alternativas; Identificar y resolver los riesgos; desarrollar y verificar los resultados de la iteración, y plan de la próxima iteración.
Cada ciclo comienza con la identificación de los interesados y sus condiciones de ganancia, y termina con la revisión y examinación.
Rapid Application Development (RAD)
El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo iterativo y la construcción de prototipos. El desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.
Principios básicos:
Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión. Intenta reducir el riesgos inherente del proyecto partiéndolo en
segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo.
computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestión de bases de datos (DBMS), lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos. Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la excelencia es de menor importancia.
Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha límite.
En general incluye Joint application development (JAD), donde los usuarios están intensamente participando en el diseño del sistema, ya sea a través de la creación de consenso estructurado en talleres, o por vía electrónica.
La participación activa de los usuarios es imprescindible.
Iterativamente realiza la producción de software, en lugar de enfocarse en un prototipo.
Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.
METODOLOGÍA TRADICIONAL.
Las metodologías tradicionales de desarrollo de software son orientadas por planeación. Inician el desarrollo de un proyecto con un riguroso proceso de elicitación de requerimientos, previo a etapas de análisis y diseño. Con esto tratan de asegurar resultados con alta calidad circunscritos a un calendario.
En las metodologías tradicionales se concibe un solo proyecto, de grandes dimensiones y estructura definida; se sigue un proceso secuencial en una sola dirección y sin marcha atrás; el proceso es rígido y no cambia; los requerimientos son acordados de una vez y para todo el proyecto, demandando grandes plazos de planeación previa y poca comunicación con el cliente una vez ha terminado ésta.
Rational Unified Process (RUP)
RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de software de alta calidad que satisfaga los requerimientos de los usuarios finales (respetando cronograma y presupuesto). Fue desarrollado por Rational Software, y está integrado con toda la suite Rational de herramientas. Puede ser adaptado y extendido para satisfacer las necesidades de la organización que lo adopte. (Customización). Es guiado por casos de uso y centrado en la arquitectura, y utiliza UML como lenguaje de notación.
Fases
Las cuatro fases del ciclo de vida son:
Concepción
Elaboración
Construcción
Transición
Ventajas
Evaluación en cada fase que permite cambios de objetivos
Funciona bien en proyectos de innovación.
Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.
Desventajas
La evaluación de riesgos es compleja
Excesiva flexibilidad para algunos proyectos
Estamos poniendo a nuestro cliente en una situación que puede ser muy incómoda para él.
Nuestro cliente deberá ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con él.
Microsoft Solution Framework (MSF)
Descripción
MSF es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnología de información.
Todo proyecto es separado en cinco principales fases:
Visión y Alcances.
Planificación.
Desarrollo.
Estabilización.
Implantación.
La fase de visión y alcances trata uno de los requisitos más fundamentales para el éxito del proyecto, la unificación del equipo detrás de una visión común. El equipo debe tener una visión clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en términos que motivarán a todo el equipo y al cliente. Se definen los líderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas últimas se deben respetar durante la ejecución del proyecto en su totalidad, y se realiza la evaluación inicial de riesgos del proyecto.
Planificación:
Es en esta fase es cuando la mayor parte de la planeación para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto.
Desarrollo:
Durante esta fase el equipo realice la mayor parte de la construcción de los componentes (tanto documentación como código), sin embargo, se puede realizar algún trabajo de desarrollo durante la etapa de estabilización en respuesta a los resultados de las pruebas. La infraestructura también es desarrollada durante esta fase.
Estabilización:
En esta fase se conducen pruebas sobre la solución, las pruebas de esta etapa enfatizan el uso y operación bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solución para el lanzamiento.
Implantación:
Durante esta fase el equipo implanta la tecnología base y los componentes relacionados, estabiliza la instalación, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobación final del cliente.
El modelo de equipos de MSF (MSF team model) fue desarrollado para compensar algunas de las desventajas impuestas por las estructuras jerárquicas de los equipos en los proyectos tradicionales.
Los equipos organizados bajo este modelo son pequeños y multidisciplinarios, en los cuales los miembros comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que están desarrollando. Comparten una visión común del proyecto y se enfocan en implementar la solución, con altos estándares de calidad y deseos de aprender.
El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. Cada rol puede estar compuestos por una o más personas, la estructura circular del modelo, con óvalos del mismo tamaño para todos los roles, muestra que no es un modelo jerárquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas del proyecto, ninguno puede ser omitido.
La comunicación se pone en el centro del círculo para mostrar que está integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicación efectiva y es esencial para el funcionamiento del mismo
Ejemplo de metodología MSF aplicada
Fase 1 - Estrategia y alcance
En esta fase deberían tener lugar los siguientes trabajos:
Elaboración y aprobación del Documento de Alcance y Estrategia definitivo: debe ser un documento de consenso con la participación del mayor número de agentes implicados en el proyecto. En este documento quedarán definitivamente reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la solución a implantar.
Formación del Equipo de Trabajo y distribución de competencias y responsabilidades: generalmente se definen como áreas principales la de Diseño de Arquitectura, Pruebas de Laboratorio, Documentación, Logística y Coordinación.
Elaboración del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Los mecanismos y protocolos de intercambio de información y coordinación deben quedar suficientemente bien establecidos y consensuados.
Elaboración de la matriz de Riesgos y Plan de Contingencia: los principales riesgos detectados deben tener un plan de mitigación y actuación y revisarse con periodicidad.
Para un proyecto de migración a Windows 2000 podría estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervención de un Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner.
Fase 2 - Planificación y Prueba de Concepto
Deben alcanzarse los siguientes objetivos e hitos:
Documento de Planificación y Diseño de Arquitectura: es el documento principal, donde se describen en detalle los aspectos funcionales y operativos de la nueva plataforma. La aprobación de este documento es el hito principal de esta fase, y supone la directriz última de todos los trabajos técnicos, que, a partir de ese momento, deben ser consistentes con esta Guía. Si en el curso de las fases sucesivas fuera necesario revisar estos contenidos, se deberá hacer por acuerdo y conocimiento de todo el equipo de trabajo y se llevará un registro de versiones que permita hacer un seguimiento adecuado de estas revisiones.
los diversos escenarios a simular, los criterios de validez, el control de incidencias y las métricas de calidad son objetivos a cubrir en este documento. Es un documento dinámico, en el que se recoge la idea y la experiencia práctica al llevarla a cabo en entorno controlado y aislado. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Documento de Alcance y Estrategia, y su grado de estabilidad y rendimiento es considerado como "suficiente".
Habitualmente, en las propuestas de preventa no se pueden indicar con precisión parámetros como el esfuerzo técnico, tiempo o coste definitivo que puede suponer esta fase. De otras experiencias anteriores se puede obtener una relación de trabajos sólo a título orientativo, y que debe ser revisado y acordado por todas las partes:
El cómputo de jornadas para la relación de actividades descritas (que como se observa sólo recogen las relativas a la Planificación y Diseño, y deja aparte las necesarias para elaborar el plan de Migración), ofrecería
este resultado:
Jornadas totales: 80 (aprox. 4 meses)
Jornadas / técnico del PARTNER: 150 jornadas (2 personas) Jornadas / técnico del CLIENTE: 110 jornadas (Max. 2 personas)
Fase 3 – Estabilización
La solución implantada en la maqueta se pasa a un entorno real de explotación, restringido en número de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situación. Los hitos y objetivos fundamentales de esta fase son:
Gestión de Incidencias: aunque esta labor se habrá iniciado en la fase anterior, el éxito de la prueba piloto dependerá de que se forme un sistema de recogida de incidentes (helpdesk o similar), de atención al usuario (formación, consultas) y de resolución de problemas y documentación de los mismos (versionado de la plataforma).
Revisión de la documentación final de Arquitectura: el documento de Planificación y Diseño de Arquitectura se puede ver alterado parcialmente como resultado de esta fase. El documento final, aprobado por consenso, supone el principal documento del Proyecto y la culminación de los trabajos de diseño, al menos en sus líneas principales. Este documento se considerará definitivo cuando la solución puesta en marcha se muestre estable y el número de incidencias graves (de intervención o de resolución) sea nulo y la cantidad de las consideradas leves quede por debajo de un límite establecido en las Métricas de Calidad.
Elaboración de la documentación de Formación y Operaciones: con vistas al soporte post proyecto y los programas de formación a usuarios y administradores, en esta fase deben elaborarse las Guías de Usuario, de Administración, las "paso-a-paso", y otros cuyos contenidos deben acordarse previamente.
Elaboración del Plan de Despliegue: se debe consensuar la fecha de finalización de la fase Piloto, y las condiciones de calidad que debe cumplir la solución final para iniciar el despliegue. En el Plan deben identificarse las fases, estrategia de implantación, fechas, tareas a realizar, procedimientos de validación y método de control de incidencias.
Elaboración del Plan de Formación: con anterioridad al despliegue definitivo, debe haberse aprobado el Plan de Formación orientado a usuarios finales y administradores, y debe hacerse compatible con los ritmos acordados en el Plan de Despliegue.
Fase 4 – Despliegue
Se llevarán a cabo en esta fase los planes diseñados en la anterior, principalmente el de despliegue y el de formación. Los principales trabajos e hitos a conseguir son, en este caso, además de los obvios (implantación de la plataforma, puesta en servicio de todas las funciones, formación a los usuarios y administradores), los siguientes:
Continuación con las labores de recepción de incidencias, clasificación, tratamiento, resolución y distribución de faxes o intervención on-site.
Registro de mejoras y sugerencias, funcionalidades no cubiertas y novedades a incorporar en sucesivas versiones de la plataforma, incluyendo mejoras aportadas por los fabricantes de software (nuevas versiones o Service Packs, por ejemplo)
Revisión de las Guías y manuales de usuario, rectificación de errores y obtención de los documentos de formación definitivos.
Entrega de los documentos definitivos acordados como "deliverables" en la fase de Vision Scope.
Revisión (si procede) de la matriz de riesgos, las métricas de calidad y establecimiento de los estándares de calidad y SLA definitivos.
Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo proyecto en base a la información y experiencia obtenidas.
La duración fase de despliegue, puesto que debe planificarse, no puede establecerse a priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad política o de negocio) que pueden retardar o acelerar la conclusión.
METODOLOGÍA ÁGILES.
Las metodologías ágiles son flexibles, pueden ser modificadas para que se ajusten a la realidad de cada equipo y proyecto.
Los proyectos ágiles se subdividen en proyectos más pequeños mediante una lista ordenada de características. Cada proyecto es tratado de manera independiente y desarrolla un subconjunto de características durante un periodo de tiempo corto, de entre dos y seis semanas. La comunicación con el cliente es constante al punto de requerir un representante de él durante el desarrollo. Los proyectos son altamente colaborativos y se adaptan mejor a los cambios; de hecho, el cambio en los requerimientos es una característica esperada y deseada, al igual que las entregas constantes al cliente y la retroalimentación por parte de él. Tanto el producto como el proceso son mejorados frecuentemente.
(Andres Navarro Cadavid, 2007)
Extreme Programming (XP)
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.
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.
Programación por 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 interacció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.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.
Ventajas
Apropiado para entornos volátiles
Estar preparados para el cambio, significa reducir su coste.
Planificación más transparente para nuestros clientes, conocen las fechas de entrega de funcionalidades. Vital para su negocio
Permitirá definir en cada iteración cuales son los objetivos de la siguiente
Permite tener realimentación de los usuarios muy útil.
La presión esta a lo largo de todo el proyecto y no en una entrega final
Desventajas
Delimitar el alcance del proyecto con nuestro cliente
Para mitigar esta desventaja se plantea definir un alcance a alto nivel basado en la experiencia.
AUP (Agil Unified Process)
disciplinas y entregables incrementales con el tiempo. El ciclo de vida en proyectos grandes es serial mientras que en los pequeños es iterativo. Las disciplinas de Aup son:
Modelado
Implementación
Prueba
Despliegue
Administración de la configuración
Administración o gerencia del Proyecto
Entorno
Scrum
Scrum es un proceso ágil y liviano que sirve para administrar y controlar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteración es un ciclo corto de construcción repetitivo). Cada ciclo o iteración termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco para otras prácticas de ingeniería de software como RUP o Extreme Programming.
que realmente resuelva las necesidades, aumentando la satisfacción del cliente.
En Scrum, el equipo se focaliza en una única cosa: construir software de calidad. Por el otro lado, la gestión de un proyecto Scrum se focaliza en definir cuales son las características que debe tener el producto a construir (qué construir, qué no y en qué orden) y en remover cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo. Se busca que los equipos sean lo más efectivos y productivos posible.
Scrum tiene un conjunto de reglas muy pequeño y muy simple y está basado en los principios de inspección continua, adaptación, auto-gestión e innovación. El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto iteración a iteración y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa.
Por otro lado, los desarrolladores encuentran un ámbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivación de los integrantes del equipo.
Iconix
Y, el proceso se queda igual a la visión original de Jacobson del manejo de casos de uso, esto produce un resultado concreto, específico y casos de uso fácilmente entendible, que un equipo de un proyecto puede usar para conducir el esfuerzo hacia un desarrollo real. La Figura 6 muestra el cuadro del proceso. El diagrama retrata la esencia del enfoque aerodinámico al desarrollo del software, que incluye un juego mínimo de diagramas de UML y algunas valiosas técnicas que se toman de los casos del uso para codificar rápida y eficazmente. El enfoque es flexible y abierto; siempre se puede seleccionar de los otros aspectos del UML para complementar los materiales básicos.
(Roberth G. Figueroa, 2008)
Lean software development
La metodología de desarrollo de software lean (traducción aproximada de lean: «fino» o «esbelto») es una traducción de los principios y las prácticas de la forma de producir lean, hacia el área del desarrollo de software. Inicialmente, originado en el Sistema de Producción de Toyota y ahora, apoyado por una corriente que está surgiendo desde la comunidad Ágil. Este método ofrece todo un marco teórico sólido y basado en la experiencia, para las prácticas ágiles de gestión.
Los principios
lean
El desarrollo lean puede resumirse en siete principios, similares a los principios de manufactura esbelta.
Eliminar los desperdicios
Todo lo que no añade valor al cliente se considera un desperdicio: Código y funcionalidades innecesarias
Retraso en el proceso de desarrollo de software Requisitos poco claros
Burocracia
Comunicación interna lenta
mapping (o mapa de flujo de valor) para distinguir y reconocer los desperdicios. El segundo paso consiste en señalar las fuentes de los desperdicios y eliminarlos. Lo mismo debe hacerse iterativamente hasta que incluso los procesos y procedimientos que parecían esenciales sean eliminados.
Ampliar el aprendizaje
El desarrollo de software es un proceso de aprendizaje continuo, a ello se le suman los retos de los equipos de desarrollo y el tamaño del producto final. El mejor enfoque para encarar una mejora en el ambiente de desarrollo de software es ampliar el aprendizaje. La acumulación de defectos debe evitarse ejecutando las pruebas tan pronto como el código está escrito en lugar de añadir más documentación o planificación detallada. Las distintas ideas podrían ser probadas escribiendo código e integrándolo. El proceso de recopilación de requisitos de usuarios podría simplificarse mediante la presentación de las pantallas de los usuarios finales para que estos puedan hacer sus aportes. El proceso de aprendizaje es acelerado con el uso iteraciones cortas cada una de ellas acompañada de refactorización y sus pruebas de integración.
Incrementando la retroalimentación mediante reuniones cortas con los clientes se ayuda a determinar la fase actual de desarrollo y se ajustan los esfuerzos para introducir mejoras en el futuro. Durante las reuniones, tanto los clientes como el equipo de desarrollo, logran aprender sobre el alcance del problema y buscan posibles soluciones para un mejor desarrollo. Por lo tanto, los clientes comprenden mejor sus necesidades basándose en el resultado de los esfuerzos del desarrollo y los desarrolladores aprenden a satisfacer mejor estas necesidades.
Otra idea para ampliar el aprendizaje es a través de la integración del cliente en el ambiente de desarrollo para concentrar la comunicación en las soluciones futuras y no en las soluciones posibles, promoviendo así el nacimiento de la solución a través del diálogo con el cliente.
Decidir lo más tarde posible
iterativo promueve este principio: la capacidad de adaptarse a los cambios y corregir los errores, ya que un error podría ser muy costoso si se descubre después de la liberación del sistema.
Un enfoque de desarrollo de software ágil puede llevarles opciones rápidamente a los clientes, lo que implica, retrasar algunas decisiones cruciales hasta que los clientes hayan reconocido mejor sus necesidades. Esto también permite la adaptación tardía a los cambios y previene las costosas decisiones delimitadas por la tecnología. Esto no significa que no haya planificación involucrada en el proceso, por el contrario, las actividades de planificación deben centrarse en las diferentes opciones y se les adapta a la situación actual; así como, se deben clarificar las situaciones confusas estableciendo las pautas para una acción rápida. Evaluar las diferentes opciones es eficaz tan pronto como queda claro que ellos no son libres, pero proporcionando la flexibilidad necesaria para una tardía toma de decisiones.
Reaccionar tan rápido como sea posible
En la era de la rápida evolución tecnológica, no es el más grande quien sobrevive, sino el más rápido. Cuanto antes se entrega el producto final sin defectos considerables más pronto se pueden recibir comentarios y se incorporan en la siguiente iteración. Cuanto más cortas sean las iteraciones, mejor es el aprendizaje y la comunicación dentro del equipo. Sin velocidad, las decisiones no pueden ser postergadas. La velocidad asegura el cumplimiento de las necesidades actuales del cliente y no lo que éste requería para ayer. Esto les da la oportunidad de demorarse pensando lo que realmente necesitan, hasta que adquieran un mejor conocimiento. Los clientes valoran la entrega rápida de un producto de calidad.
La ideología de producción Just In Time podría aplicarse a programas de desarrollo, reconociendo sus necesidades específicas y el ambiente. Lo anterior se logra mediante la presentación de resultados , la necesidad de dejar que el equipo se organice y dividiendo las tareas para lograr el resultado necesario para una iteración específica.
de parte de sus colegas o del cliente. Esto requiere la transparencia del proceso, que es también beneficioso para la comunicación del equipo. Otra idea clave del Sistema de Desarrollo de Producto de la Toyota se establece a base de diseño. Si un nuevo sistema de frenos es necesario para un coche, por ejemplo, tres equipos pueden diseñar soluciones al mismo problema. Cada equipo aprende sobre el ambiente del problema y diseños de una posible solución. Cuando una solución se considera irrazonable, se desecha. Al final de un periodo, los diseños sobrevivientes se comparan y se elige uno, quizá con algunas modificaciones basadas en el aprendizaje de los demás, un gran ejemplo de compromiso aplazado hasta el último momento posible. Las decisiones en el software también podrían beneficiarse de esta práctica para minimizar el riesgo provocado por un solo gran diseño realizado por adelantado.
Potenciar el equipo
Ha habido una creencia tradicional en la mayoría de las empresas acerca de la toma de decisiones en la organización: los administradores dicen a los trabajadores cómo hacer su propio trabajo. En una técnica llamada Work-Out, los roles cambian: a los directivos se les enseña a escuchar a los desarrolladores, de manera que éstos puedan explicar mejor qué acciones podrían tomarse, así como ofrecer sugerencias para mejoras. Los directores de proyecto más experimentados simplemente han declarado la clave de éxito de los proyectos: "Buscar la buena gente y dejarles hacer su propio trabajo".
Crear la integridad
El siempre exigente cliente debe tener una experiencia general del sistema. A esto se le llama percepción de integridad: ¿Cómo es publicitado, entregado, implementado y accedido? ¿Es su uso intuitivo? ¿Precio? ¿Hasta qué punto resuelve los problemas?. Integridad Conceptual significa que los componentes separados del sistema funcionan bien juntos, como en un todo, logrando equilibrio entre la flexibilidad, sostenibilidad, eficiencia y capacidad de respuesta. Esto podría lograrse mediante la comprensión del dominio del problema y resolviéndolo al mismo tiempo, no secuencialmente. La información necesaria es recibida por los pequeños lotes, no en una vasta cantidad y con una preferible comunicación cara a cara, sin ninguna documentación por escrito. El flujo de información debe ser constante en ambas direcciones, a partir del cliente a los desarrolladores y viceversa, evitando así la gran y estresante cantidad de información después de un largo periodo de desarrollo en el aislamiento.
Una de las maneras más saludables hacia una arquitectura integrante es la refactorización. Cuantas más funcionalidades se añaden a las del sistema, mas se pierde del código base para futuras mejoras. Así como en la Programación extrema (XP), la refactorización es mantener la sencillez, la claridad, la cantidad mínima de funcionalidades en el código. Las repeticiones en el código son signo de un mal diseño de código y deben evitarse. El completo y automatizado proceso de construcción debe ir acompañada de una suite completa y automatizada de pruebas, tanto para desarrolladores y clientes que tengan la misma versión, sincronización y semántica que el sistema actual. Al final, la integridad debe ser verificada con una prueba global, garantizando que el sistema hace lo que el cliente espera que haga. Las pruebas automatizadas también son consideradas como parte del proceso de producción y, por tanto, si no agregan valor deben considerarse residuos. Las pruebas automatizadas no deberían ser un objetivo, sino, un medio para un fin; específicamente para la reducción de defectos.
Kanban (desarrollo)
Este artículo se refiere a la gestión de procesos y método de mejora. Para el proceso de manufactura esbelta, consulte Kanban.
hasta su entrega al cliente, se muestra para que los participantes lo vean y los miembros del equipo tomen el trabajo de una cola.
Kanban se puede dividir en dos partes:
Kanban - Un sistema de gestión de proceso visual que le indica qué producir, cuándo producirlo, y cuánto producir.
El método Kanban - Una aproximación a la mejora del proceso evolutivo e incremental para las organizaciones.
El método Kanban
En el desarrollo de software, utilizamos un sistema Kanban virtual para limitar el trabajo en curso. A pesar de que el nombre se origina del idioma japonés "Kanban", y se traduce aproximadamente como "tarjeta de señal", y hay tarjetas utilizadas en la mayoría de las implementaciones de Kanban en desarrollo de software, estas tarjetas no funcionan en realidad como señales para realizar más trabajo. Representan los elementos de trabajo. De ahí el término "virtual" porque no existe una tarjeta física.
El método Kanban formulado por David J. Anderson1 2 es una aproximación al proceso gradual, evolutivo y al cambio de sistemas para las organizaciones. Utiliza un sistema de extracción limitada del trabajo en curso como mecanismo básico para exponer los problemas de funcionamiento del sistema (o proceso) y estimular la colaboración para la mejora continua del sistema. Un ejemplo del sistema de extracción es el sistema Kanban, y es después de esta popular forma de trabajo en curso, que se ha denominado el método.
Los principios del método Kanban
El método Kanban tiene sus raíces en cuatro principios básicos: 1. Comience con lo que hace ahora
2. El método Kanban se inicia con las funciones y procesos que ya se tienen y estimula cambios continuos, incrementales y evolutivos a su sistema.
3. Se acuerda perseguir el cambio incremental y evolutivo
5. Respetar el proceso actual, los roles, las responsabilidades y los cargos
6. Tenemos que facilitar el cambio futuro; acordando respetar los roles actuales, responsabilidades y cargos, eliminamos los temores iniciales. Esto nos debería permitir obtener un mayor apoyo a nuestra iniciativa Kanban.
7. Liderazgo en todos los niveles
Cinco prácticas centrales del método Kanban
Anderson identificó cinco características básicas que habían sido observadas en cada implementación correcta del método Kanban. Posteriormente fueron etiquetadas como prácticas y se ampliaron con la adición de una sexta característica.
1. Visualizar
Visualizar el flujo de trabajo y hacerlo visible es la base para comprender cómo avanza el trabajo. Sin comprender el flujo de trabajo, realizar los cambios adecuados es más difícil. Una forma común de visualizar el flujo de trabajo es el uso de columnas. Las columnas representan los diferentes estados o pasos en el flujo de trabajo.
2. Limitar el trabajo en curso
Limitar el trabajo en curso implica que un sistema de extracción se aplica en la totalidad o parte del flujo de trabajo. El sistema de extracción actúa como uno de los principales estímulos para los cambios continuos, incrementales y evolutivos en el sistema.
3. Dirigir y gestionar el flujo
Se debe supervisar, medir y reportar el flujo de trabajo a través de cada estado. Al gestionar activamente el flujo, los cambios continuos, graduales y evolutivos del sistema pueden ser evaluados para tener efectos positivos o negativos.
4. Hacer las Políticas de Proceso Explícitas
Configure las reglas y directrices de su trabajo. Entienda las necesidades y asegúrese de seguir las reglas. Las políticas definirán cuándo y por qué una tarjeta debe pasar de una columna a otra. Escríbalas. Cambie las reglas cuando la realidad cambie.
5. Utilizar modelos para reconocer oportunidades de mejora
Comportamiento emergente con Kanban
Hay una creciente lista de comportamientos emergentes que hemos llegado a esperar de la implementación de Kanban, tales como4
Proceso único a la medida de cada cadena de valor Cadencias desacopladas
Trabajo programado por el costo de la demora Valor optimizado con clases de servicio
Gestión de riesgo con asignación de capacidad Tolerancia en la experimentación de procesos Gestión cuantitativa
Propagación viral de Kanban en toda la organización
TABLA COMPARATIVA.
Metodología
XP Metodología RUP Metodología para juegos Metodología Aplicaciones para Móviles
Metodología para
aplicaciones en Educación
Nace en busca de
simplificar el
desarrollo del
software y que se lograra reducir el costo del proyecto.
Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo).
Para el desarrollo
de un juego
hacemos la
utilización de
metodologías agiles.
La cantidad de móviles que se están vendiendo actualmente dan un cambio drástico a la industria de las aplicaciones móviles, consiguiendo expandir el uso de dichas
aplicaciones y servicios
comercialmente.
Las metodologías convencionales de
Ingeniería de Software Educativo (ISE) tienen mecanismos robustos para hacer un análisis de necesidades y diseño educativo completo.
Planificación Diseño Codificación Pruebas
Especificación de casos de uso
Análisis y diseño Requerimiento Prueba Desarrollo Requisitos Análisis Diseño preliminar Diseño detallado Codificación Pruebas.
Evaluación de necesidades Guion grafico
Flujo UML. Cliente/Servidor Diseño
Desarrollo en línea/fuera de línea
Prueba
Proceso de firma
Distribución de
aplicaciones
Actualizaciones regulares
Análisis, diseño educativo y comunicacional.
Prueba piloto. Prueba de campo. Diseño
Diagrama de clases Diagrama de casos de uso
Tabla de
requerimientos Historias de usuario
Casos de Uso Paquetes
Modelo Conceptual Contratos Diagrama de secuencias
Diagrama de casos de uso Tabla de requerimientos
Estructura de la aplicación
Navegación de botones y paginas Flujo de las páginas en el ámbito de la aplicación.
Experiencias de usuario
Diseño de objetos bajo criterios de pantalla táctil y teclado Soporte multiresolución
Definición formal de cada pantalla Objetivo
Eventos del modelo del mundo que está en capacidad de detectar Diagrama de la pantalla, indicando cuáles objetos tiene y dónde están ubicados.
Listado de las características tanto de la pantalla como de cada objeto Enlaces con otros elementos de la interfaz.
Notas adicionales.
(Fabiola)
TABLA COMPARATIVA
BIBLIOGRAFÍA
https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_s oftware
