Metodologías Tradicionales y Agiles

Definición de Metodología Ágil.

El desarrollo de software ágil hace referencia a un grupo de metodologías de desarrollo de software que se basan en principios similares. Generalmente promueven:
  • Un proceso de gestión de proyectos que fomenta la inspección y adaptación  frecuente. Una filosofía líder que fomenta trabajo en equipo, organización propia y  responsabilidad.
  • Un conjunto de mejores prácticas de ingeniería que permite la entrega rápida de  software de alta calidad.
  • Un enfoque de negocio que alinea el desarrollo con las necesidades de los clientes y  los objetivos de la compañía
El desarrollo ágil de software es un grupo de metodologías de desarrollo de software que se basan en principios similares. Las metodologías ágiles promueven generalmente un proceso de gestión de proyectos que fomenta el trabajo en equipo, la organización y responsabilidad propia, un conjunto de mejores prácticas de ingeniería que permiten la entrega rápida de software de alta calidad, y un enfoque de negocio que alinea el desarrollo con las necesidades del cliente y los objetivos de la compañía.
Los métodos ágiles enfatizan la comunicación cara a cara sobre los documentos escritos. La mayoría de los equipos ágiles se encuentran localizados en una única ubicación abierta para facilitar esta comunicación. El tamaño del equipo es normalmente pequeño (5-9 personas) para ayudar a hacer la comunicación y la colaboración más fácil. Los esfuerzos de desarrollos largos deben ser repartidos entre múltiples equipos trabajando hacia un objetivo común o partes diferentes de un esfuerzo. Esto puede requerir también una coordinación de prioridades a través de los equipos.


Definición de Metodología Tradicional.

Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.
Entre las metodologías tradicionales o pesadas podemos citar:


  • RUP (Rational Unified Procces)
  • MSF (Microsoft Solution Framework)
  • Win-Win Spiral Model
  • Iconix
En el caso particular de RUP, presenta un especial énfasis en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.

Comparación entre Metodología Tradicional y Metodología Agil.




Modelos de Ciclo de Vida de un Software.

Modelo en Cascada

También denominado ciclo de vida  clásico, se caracteriza por seguir de manera secuencial las tareas que lleven al cumplimiento de los requisitos necesarios. Los resultados de una fase son tomados al inicio de la siguiente fase y así hasta finalizar el ciclo de vida.

ciclo de vida en cascada

Modelo V.

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.

Ciclo de vida V

Modelo Iterativo.

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos. 
Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente. 


Modelo de Desarrollo Incremental.

El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. 


Modelo en Espiral.

El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado de forma generalizada en la ingeniería del software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgos, comenzando por el bucle anterior. 

Este modelo de desarrollo combina las características del modelo de prototipos y el modelo en cascada. El modelo en espiral está pensado para proyectos largos, caros y complicados. 


Modelo de Prototipos.

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficiencia de un algoritmo, de la calidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-máquina. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. 
El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer. 




Definición de Ciclo de Vida

¿Que es un ciclo de Vida?

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado (muere). También se denomina a veces paradigma. 
Entre las funciones que debe tener un ciclo de vida se pueden destacar: 
  • Determinar el orden de las fases del proceso de software 
  • Establecer los criterios de transición para pasar de una fase a la siguiente 
  • Definir las entradas y salidas de cada fase 
  • Describir los estados por los que pasa el producto 
  • Describir las actividades a realizar para transformar el producto 
  • Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar.

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas que se pueden planificar. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de re-alimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones a los resultados intermedios que se van produciendo (re alimentación). 
  • Fases: una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). 
  • Entregables: son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. 



Diapositivas de la Exposición.


Aquí se publica la exposición del Equipo 1 de la materia de Teoría de Sistemas sobre la tesis titulada SISTEMA DE CONSULTAS DE INFORMACIÓN HISTÓRICA CLIMATOLÓGICA, VÍA WEB.


Metodologias y Desarrollo Adaptativo del Software (DAS)

Metodologías tradicionales y ágiles.

Metodologías tradicionales
Metodologías ágiles
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo.
Basadas en heuristicas provenientes de prácticas de producción de códigos.
Cierta resistencia a los cambios.
Especialmente preparados para cambios durante el proyecto.
Impuestas externamente.
Impuestas internamente(por el equipo).
Proceso mucho más controlado, con numerosas políticas/normas.
Proceso menos controlado, con pocos principios.
Existe un contrato prefijado.
No existe contrato tradicional o al menos es bastante flexible.
El cliente interactúa con el equipo de desarrollo mediante reuniones.
El cliente es parte del equipo de desarrollo.
Grupos grandes y posiblemente distribuidos.
Grupos pequeños (menos de 10 integrantes) y trabajando en el mismo sitio.
Más artefactos.
Pocos artefactos.
Más roles.
Pocos roles.
La arquitectura del software es esencial y se expresa mediante modelos.
Menos énfasis en la arquitectura del software.














_________________________________________________________________________________

Desarrollo Adaptativo del Software (DAS)

Es un modelo el cual sus características son ser iterativo y estar enfocado a los componentes del software más que a las tareas, además de ser tolerante a cambios.
El ciclo de vida que propone tiene 3 fases:
  • Especulación: Es la primer fase del método, se enfoca en el ciclo adaptativo de planeación que utiliza información del inicio del proyecto las metas del cliente, las restricciones del proyecto y los requisitos básicos para definir el conjunto de incrementos que se requerirán en el proyecto.
  • Colaboración: La segunda fase es donde se desarrollan las características del proyecto esto se hace en conjunto entre los desarrolladores que buscan multiplicar sus talentos y maximizar las salidas creativas de cada uno.
  • Aprendizaje: Lo importante del desarrollo de los componentes que integran el ciclo adaptativo es el aprendizaje, los desarrolladores aprenden a lo largo de todo el proyecto y este conocimiento les podria ayudar a comprender de manera más real el problema

Reporte de Tesis.


Introducción.

La República Mexicana cuenta con una red de estaciones climatológicas que a lo largo de su historia ha ido creando, aproximadamente cerca de 6000 estaciones distribuidas por todo el país, la información que cada estación que obtiene es almacenada en la Base Nacional de Datos Climatológicos (BNDC).

El inconveniente de los proyectos realizados para la obtención de información es que en muchas casos es complicada debido a que se encuentra en discos compactos y en el peor caso en copias fotostáticas.
Para solucionar este problema INTERNET seria una herramienta que simplifique la adquisición de la misma sin importar la distancia.

Planteamiento de Problema.

La información climatológica es un gran banco de datos, al cual se le pueden sacar muchos beneficios, su aplicación va desde los aspectos hidrológicos, agrícolas, estudios de riesgo naturales por eventos hidrometeoro lógicos, hasta aspectos relacionados con el turismo.

Pero no solo basta con obtener información, el reto consiste en almacenarla de manera que su consulta sea rápida y sencilla. 

Objetivos.

OBJETIVO GENERAL: Implementar un sistema de consultas en línea, haciendo uso de la metodología IWEB, con la finalidad de facilitar la obtención y comprensión de datos históricos climatológicos de la República Mexicana.

OBJETIVOS ESPECÍFICOS:
  • Analizar la información histórica climatológica, ademas de los requisitos del cliente.
  • Definir un sistema gestor para la base de datos y un lenguaje para la codificación del sistema.
  • Definir e implementar una base de datos, con sus entidades, atributos y relaciones.
  • Implementar el sistema para realizar pruebas y partir de ellas, seguir con la retroalimentación.
  • Etc.
Justificación.


Internet desde hace varios años se ha convertido en una herramienta fundamental para cualquier creatividad, por muchas razones desde la facilidad de uso, de acceso, su costo relativamente bajo por mencionar.

En la actualidad buscamos obtener información que sea válida, rápida y clara, tratando de conseguirla sin mucho esfuerzo.
Entonces porque no tener un sistema que nos brinde esta factibilidad de uso y de obtención de beneficios, tanto a instituciones cono a usuarios en general.