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