Modelo de ciclo de vida del sofware tradicional ¿Qué es el ciclo de vida del software? El ciclo de vida del desarrollo del software (también conocido como SDLC o Systems Development Life Cycle) contempla las fases necesarias para validar el desarrollo del software y así garantizar que este cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo, asegurándose de que los métodos usados son apropiados. En la actualidad, existen dos grandes metodologías para el ciclo de vida del desarrollo de Software, una que es la tradicional ( cascada ), y otra que surge en el año 2001, denominada Metodologia Ágil. Tradicional Agile iteracion es muy importante la adaptación por parte de la metodología, mediante la cual se va a llevar a cabo el proyecto, a las necesidades tanto de usuarios como de los desarrolladores MODELO RAD El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. FASES DEL RAD Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso? Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos. Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software. Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo. OMT (Object Modeling Technique) es una de las metodologías de análisis y diseño orientadas a objetos, más eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software. Las fases que conforman a la metodología OMT son: Análisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades más importantes. El modelo de análisis es una abstracción resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se hará. Los elementos del modelo deben ser conceptos del dominio de aplicación y no conceptos informáticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informáticos. Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema. Diseño de objetos. El diseñador de objetos construye un modelo de diseño basándose en el modelo de análisis, pero incorporando detalles de implementación. El diseño de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseño puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.). Implementación. Las clases de objetos y relaciones desarrolladas durante el análisis de objetos se traducen finalmente a una implementación concreta. Durante la fase de implementación es importante tener en cuenta los principios de la ingeniería del software de forma que la correspondencia con el diseño sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilización de código y la correspondencia entre el dominio del problema y el sistema informático, si luego perdemos todas estas ventajas con una implementación de mala calidad. OUM Es el método basado en estándares de Oracle que permite el ciclo de vida completo de la Tecnología de Información Empresarial. Proporciona un enfoque de implantación que es rápido, adaptado ampliamente y enfocado al negocio, y ha evolucionado para ser la metodología para todos los productos de Oracle. El OUM incluye un proyecto completo y un marco de gestión de programa y materiales para apoyar el crecimiento de Oracle con un enfoque en la estrategia de tecnología de información, arquitectura y dirección a nivel empresarial. Modelo Espiral fue propuesto por Barry W. Boehm en su ensayo "A Spiral Model of Software Development and Enhancement." En ese momento, el modelo de desarrollo en cascada prevalecía, por lo que los inconvenientes asociados fueron discutidos con frecuencia. A diferencia de otros modelos como "code and fix" o el "modelo cascada", el desarrollo en espiral está basado en el riesgo. La identificación y resolución de riesgos juega un papel importante en las diferentes espirales del proyecto una vez definidos los objetivos y condiciones. principios básicos del modelo espiral: Decidir qué problema se quiere resolver antes de viajar a resolverlo. Examinar tus múltiples alternativas de acción y elegir una de las más convenientes. Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo. No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita Conocer (comprender) los niveles de riesgo, que tendrás que tolerar. Cómo funciona Objetivo y determinación alternativa: Los objetivos se determinan conjuntamente con el cliente. Al mismo tiempo, se discuten posibles alternativas y se especifican las condiciones marco (por ejemplo, sistemas operativos, entornos y lenguajes de programación). Análisis y evaluación de riesgos: Se identifican y evalúan los riesgos potenciales. También se evalúan las alternativas existentes. Los riesgos son registrados, evaluados y luego reducidos utilizando prototipos, simulaciones y softwares de análisis. En este ciclo, existen varios prototipos como plantillas de diseño o componentes funcionales Desarrollo y prueba: Los prototipos se amplían y se añaden funcionalidades. El código real es escrito, probado y migrado a un entorno de prueba varias veces hasta que el software pueda ser implementado en un entorno productivo. Planificación del siguiente ciclo: El siguiente ciclo se planifica al final de cada etapa. Si se producen errores, se buscan soluciones, y si una alternativa es una mejor solución, se prefiere en el siguiente ciclo. regiones de tareas que componen este modelo Conclusión En esta nueva generación, las metodologías tradicionales de desarrollo de software fueron quedado obsoletas en determinados sectores, en los que la propia demanda de los usuarios es más rápida que la capacidad de producción de las empresas ancladas a las viejas metodologías de gestión de proyectos de sistemas informáticos. Este gran impacto en las tecnologías, ha generado la necesidad de encontrar y crear nuevas metodologías de trabajo y gestión, que aseguren la entrega en tiempo y forma del producto. Esta necesidad de calidad, eficiencia, flexibilidad y rapidez en la entrega de un producto informático se volvió prioridad y en conjunto con su necesidad se crearon las nombradas Metodologías Agiles.
