Modelo Lineal Secuencial
Modelo Lineal Secuencial
Modelo Lineal Secuencial
Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal
presenta una estructura secuencial.
Es también conocido como “Modelo en cascada”, “Modelo lineal secuencial”, “Ciclo
de vida básico” o “Ciclo de vida clásico”.
Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Tiene
su origen en el "Modelo de cascada" ingeniado por Winston Royce, sugiere un
enfoque sistemático o más bien secuencial del desarrollo de software que comienza
en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento.
PLANIFICACIÓN
Antes de que se le dé oficialmente la de salida a un proyecto de desarrollo de un
sistema de información, es necesario realizar una serie de tareas previas que
influirán decisivamente en la finalización con éxito del proyecto. Estas tareas se
conocen popularmente como el fuzzy front-end del proyecto al no estar sujetas a
plazos. Las tareas iniciales que se realizarán esta fase inicial del proyecto incluyen
actividades tales como la determinación del ámbito del proyecto, la realización de
un estudio de viabilidad, el análisis de los riesgos asociados al proyecto, una
estimación del coste del proyecto, su planificación temporal y la asignación de
recursos a las distintas etapas del proyecto.
DISEÑO:
Es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las
representaciones de la interfaz y el detalle procedimental (algoritmo). En forma
general se hace un esbozo de lo solicitado y se documenta haciéndose parte del
software.
El diseño es la etapa, en la que se fomenta la calidad. Sin diseño se corre riesgo de
construir un sistema inestable, y difícil de probar.
El diseño deberá implementar todos los requisitos explícitos del modelo de análisis
y deberá ajustarse a los requeridos por el cliente. El diseño tiene que ser una guía
comprensible para los que implemente en software y consecuentemente, los que
den soporte al mismo.
Es tanto un proceso como un modelo. Es un proceso porque es una secuencia de
pasos que el diseñador describe con el fin de construir el diseño del software. Es un
modelo porque comienza con la totalidad, y luego refina.
Tipos de diseño
Diseño de datos: Transforma el model del dominio obtenido del análisis, en
estructuras de datos, objetos, relaciones, etc. Por ejemplo un diagrama de entidad
relación.
Diseño arquitectónico: Define la relación entre los componentes más importantes
del software para lograr los requisitos del sistema. La información puede derivarse
de la especificación, del modelo de análisis y de la interacción de ls subsistemas
definidos.
Diseño a nivel de componentes: Transforma los elementos estructurales de la
arquitectura en una descripción procedimental de los componentes del software. La
información obtenida del diseño de datos, sirven como base.
Diseño de interface: Describe la forma de comunicación dentro del mismo sistema,
con otros sistemas y con las personas. Una interface implica flujo de información
(datos o control) y comportamiento.
Criterios técnicos
Un diseño deberá presentar una estructura arquitectónica que:
Se haya creado mediante patrones reconocibles.
Que esté formado por componentes que exhiban características de buen diseño.
Un diseño deberá ser modular e independiente. El software deberá dividirse
lógicamente en elementos que realicen funciones y subfunciones específicas.
Un diseño deberá contener distintas representaciones de datos, arquitectura,
interfaces y componentes.
Un diseño deberá conducir a interfaces que reduzcan la complejidad de las
conexiones entre módulos y con el entorno externo.
Debe comunicar de manera eficaz su significado.
Principios
Se deben tener en cuenta enfoques alternativos.
Deberá poderse rastrear hasta el modelo de análisis.
No inventar nada que ya esté inventado.
Minimizar la distancia intelectual entre el software y el problema.
Uniformidad e integración.
Admitir cambios.
Deberá estructurarse para degradarse poco a poco, incluso cuando se enfrenta con
datos, sucesos o condiciones de operaciones aberrantes.
El diseño no es escribir código y escribir código no es diseñar.
El diseño deberá evaluarse en función de la calidad mientras se va creando, no
después de terminado.
El diseño deberá revisarse para minimizar los errores conceptuales.
PRUEBAS
Consiste en hacer funcionar el producto o una parte de él y comprobar si los
resultados son correctos. No permite garantizar la calidad del producto. En general
no es posible probar un producto de forma exhaustiva, debido a su complejidad.
Una estrategia de pruebas integra los métodos de diseño de los casos de prueba
para lograr un software eficaz.
La prueba es un conjunto de actividades que se planean con anticipación y se
realizan de manera sistemática.
Una estrategia de pruebas debe incluir tanto pruebas de alto como de bajo nivel.
Son parte de la Verificación y Validación incluidas en el aseguramiento de la calidad
del software.
Verificación: Comprobar que el software está de acuerdo con su especificación,
donde se debe comprobar que satisface tanto los requerimientos funcionales como
los no funcionales.
Validación: El objetivo es asegurar que el software satisface las expectativas del
cliente.
Aspectos estratégicos:
Establecer explícitamente los objetivos de las pruebas.
Comprender cuáles son los usuarios del software y desarollar un perfil para cada
categoría.
Plan de pruebas para ciclos rápidos.
Construir un software robusto para probarse a sí mismo.
Usar revisiones técnicas formales y efectivas antes de las pruebas.
Desarrollar un enfoque de mejora continua para el proceso de pruebas.
Tipos de pruebas
Pruebas de unidad: Verifican que el componente funciona correctamente a partir del
ingreso de diferentes casos de prueba. Los errores más comunes son detectados
en estas pruebas.
Se examinan las estructuras de datos locales
Se prueban condiciones límite.
Se ejercitan todos los caminos independientes. Se utiliza un controlador
independiente para cada caso. Este es un programa que recibe las pruebas, las
envía al modulo y muestra el resultado.
Pruebas de integración: Verifican que los componentes trabajan correctamente en
forma conjunta.
Se toman los componentes que han pasado las pruebas de unidad y se los combina.
Estos tests sirven ya que los datos podrían perderse en alguna interfaz.
La combinación de los mismos podría traer efectos que no son los esperados.
La integración puede ser: * Descendente: Inician por el programa principal. * En
profundidad: Integra todos los módulos de un camino de control principal de la
estructura * En anchura: Incorpora todos los módulos directamente subordinados a
cada nivel. * Ascendente: Se empieza la prueba con los módulos atómicos. Datos
que los módulos se integran de abajo hacia arriba, el proceso requerido de los
módulos subordinados siempre está disponisble, pero no asi los conductores.
Pruebas de regresión: Esta prueba consiste en volver a ejecutar un subconjunto de
pruebas que se han llevado a cabo anteriormente para asegurarse de que los
cambios que se aplicaron no han propagado efectos colaterales no deseados.
Pruebas de validación: Proporcionan una seguridad final de que el software
satisface los requermientos.
Revisión de la configuración: Asegurar que todos los elementos de la configuración
del software se hallan desarrollado apropiadamente.
Pruebas de aceptación (ALFA y BETA): Las realiza el usuario final en lugar del
responsable del desarrollo.
Pruebas ALFA: Desarrolladores con clientes antes de liberar el producto.
Pruebas BETA: Seleccionando los clientes que efectuarán la prueba. El
desarrollador no se encuentra presente.
Pruebas deñ sistema: Verifica que cada elemento encaja de forma adecuada y que
se alcanza la funcionalidad y el rendimiento del sistema total.
Pruebas de recuperación: Se controla que el software se recupere ante fallas.
Generalmente se fuerza el fallo.
Pruebas de seguridad: Se comprueban los mecanismos de protección integrados.
Pruebas de resistencia: Se diseñan para enfrentar a los programas a situaciones
anormales.
Pruebas de rendimiento: Se prueba el sistema en tiempo de ejecución. A veces va
emparejada con la prueba de resistencia.
IMPLEMENTACIÓN
Esta es la fase en que ponemos el software en funcionamiento en el mundo real, o
dentro de la organización para la que fue desarrollado. En esta fase se realizan
todos los preparativos necesarios para asegurar que la inclusión del software dentro
de la organización se realizara sin contratiempos y produciendo la menor cantidad
de inconvenientes posible.
MANTENIMIENTO
Como sabemos las organizaciones no permanecen igual, cambian a lo largo del
tiempo, así también los gustos y necesidades de las personas cambian, entonces
el software necesita ser modificado para que se adapte a esos cambios, y es por
ello que surge lo que en el software general las famosas actualizaciones.
OBSOLECENCIA
Si bien es cierto que el mantenimiento hace el software se adapte a los cambios del
entorno, este mantenimiento no es eterno, llega un punto en el que ya no es posible
seguir haciendo modificaciones al sistema, en ese momento el software se vuelve
obsoleto, ya sea por la tecnología que se uso en su desarrollo o por que no fue
diseñado para la cantidad de operaciones que se realizan hoy en día, se cual fuere
la razón una vez que el software es obsoleto es tiempo de crear una nueva version
del software y es cuando volvemos a encontrar nuestra necesidad, oportunidad o
problema.