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.

El MLS tiene las siguientes actividades:

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.

ANÁLISIS DE LOS REQUERIMIENTOS DEL SOFTWARE:

Es la fase en la cual se reúnen todos los requisitos que debe cumplir el software.
En esta etapa es fundamental la presencia del cliente que documenta y repasa
dichos requisitos.
análisis es la fase de definición del futuro sistema y tiene una importancia decisiva
en el desarrollo de todas las etapas posteriores. Con el análisis de requisitos se
trata de caracterizar el problema a resolver. El “cliente” trabaja con el analista para
elaborar las especificaciones y posteriormente se encargarán de verificar el
cumplimiento de las mismas (contrato). El análisis debe producir un modelo válido
necesario y suficiente para recoger todas las necesidades y exigencias del sistema,
así como las restricciones que los limiten. Para una especificación correcta se
requiere: Completo y sin omisiones Conciso y sin trivialidades Sin ambigüedades
Sin detalles de diseño o implementación Fácilmente entendible por el cliente
Separando requisitos funcionales u no funcionales (capacidades mínimas y
máximas, interfaces estándares, recursos necesarios, seguridad, fiabilidad,
mantenimiento, etc. División y jerarquía del modelo global, con el fin de simplificar
su comprensión Incluyendo los criterios de validación del sistema, para comprobar
si se ajusta al contrato inicial.

TAREAS DEL ANÁLISIS

Dependiendo de las características y complejidad del sistema se podrán seguir los
siguientes pasos:
ESTUDIO DEL SISTEMA EN SU CONTEXTO, análisis del dominio en un contexto
globalizador
IDENTIFICACIÓN DE NECESIDADES, detectar necesidades de medios dentro de
plazos y presupuestos
ANÁLISIS DE ALTERNATIVAS Y ESTUDIO DE VIABILIDAD, tanto técnica como
económica
ESTABLECIMIENTO DEL MODELO DEL SISTEMA, para lo que podemos usar
técnicas gráficas, texto, herramientas CASE, etc.
ELABORACIÓN DEL DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS,
dónde se recogen las conclusiones del análisis y sirve de punto de partida para el
diseñador.
REVISIÓN CONTINUADA DEL ANÁLISIS, a menudo en las etapas de diseño e
implementación se hace necesaria la revisión de alguno de los requisitos, o bien por
cambios de criterio del cliente.

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.

GENERACIÓN DEL CÓDIGO:

Es la etapa en la cual se traduce el diseño para que sea comprensible por la
máquina. Esta etapa va a depender estrechamente de lo detallado del diseño.
Generación de código. El diseño se debe traducir en una forma legible por la
máquina. El paso de generación de código lleva a cabo esta tarea. Si se lleva a
cabo el diseño de una forma detallada, la generación de código se realiza
mecánicamente.
Aunque el modelo lineal es a menudo denominado «modelo tradicional», resulto un
enfoque razonable cuando los requisitos se han entendido correctamente.

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.

DESVENTAJAS DEL MODELO LINEAL.

 Los proyectos reales raramente siguen el flujo secuencial que propone el
modelo, siempre hay iteraciones y se crean problemas en la aplicación del
paradigma.
 Normalmente, es difícil para el cliente establecer explícitamente al principio
todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en
acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.
 El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto,
no estará disponible una versión operativa del programa. Un error importante
no detectado hasta que el programa esté funcionando puede ser desastroso.
 En muchas ocasiones, los clientes no saben bien los requisitos que
necesitarán antes de ver una primera versión del software en funcionamiento.
Entonces, cambiarán muchos requisitos y añadirán otros nuevos, lo que
supondrá volver a realizar fases ya superadas y provocará un incremento del
coste.
 No se va mostrando al cliente el producto a medida que se va desarrollando,
si no que se ve el resultado una vez ha terminado todo el proceso. Esto cual
provoca inseguridad por parte del cliente que quiere ir viendo los avances en
el producto
 Los diseñadores pueden no tener en cuenta todas las dificultades que se
encontrarán cuando estén diseñando un software, lo que conllevará
rediseñar el proyecto para solventar el problema.
 Para proyectos a largo plazo, este modelo puede suponer un problema al
cambiar las necesidades del usuario a lo largo del tiempo. Si por ejemplo,
tenemos un proyecto que va a durar 5 años, es muy probable que los
requisitos necesiten adaptarse a los gustos y novedades del mercado.

VENTAJAS DEL MODELO LINEAL.

 La Ventaja de este método radica en su sencillez ya que sigue los pasos
intuitivos necesarios a la hora de desarrollar el software.
 Facilita la gestión del desarrollo.
 El tiempo que se pasa en diseñar el producto en las primeras fases del
proceso puede evitar problemas que serían más costosos cuando el proyecto
ya estuviese en fase de desarrollo.
 La documentación es muy exhaustiva y si se une al equipo un nuevo
desarrollador, podrá comprender el proyecto leyendo la documentación.
 Al ser un proyecto muy estructurado, con fases bien definidas, es fácil
entender el proyecto.
 Ideal para proyectos estables, donde los requisitos son claros y no van a
cambiar a lo largo del proceso de desarrollo.