Por metodología se entiende "un conjunto integrado de técnicas y método que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo de un sistema de información"

• Sistema de Información: Es un conjunto de componentes (computadoras, periféricos, software y usuarios) que trabajan juntos para conseguir un objetivo, transformando elementos de entrada al sistema en otros elementos de salida (datos).
• Ciclo de Vida: Conjunto de fases implicadas en un proyecto de desarrollo de un sistema de información, desde su concepción inicial, pasando por su desarrollo, implantación, funcionamiento y mantenimiento, hasta que el sistema deja de utilizarse o se transforma en otro.
• Método: Concreción en etapas o pasos precisos, tanto el proceso de desarrollo en general (ciclo de vida) como cada una de las fases generales en las que se divide éste.
• Técnicas: Mecanismos, procedimientos y recursos de que se sirve la metodología.

La utilización de técnicas de diagramas favorece la comunicación entre el personal de desarrollo y los usuarios para los que se realiza el sistema. La documentación esquemática que se establece facilita el mantenimiento del sistema, lo que hace que se consiga mayor calidad del mismo. Para que todas estas ventajas sean efectivas, es preciso introducir la metodología gradualmente, diseñando previamente:

• Un plan de formación, que garantice el aprendizaje necesario;
• Un plan de normalización, fijando estándares relativos a nomenclatura, a las técnicas y a la documentación;
• Un plan de adaptación, mediante la aplicación de la metodología a un proyecto piloto.

El que un sistema deba o no ser informatizado es algo que discutiremos a lo largo del curso. Como analistas de sistemas supondremos que todo sistema con el que nos encontremos deberá ser informatizado y, el usuario con quien actuaremos generalmente supondrá tal predisposición. La labor primaria como analista, será analizar o estudiar el sistema para determinar su esencia: su comportamiento requerido, independientemente de la tecnología utilizada para implantar el sistema.

La incapacidad de estimar el tiempo, coste y esfuerzo necesario para el desarrollo de un producto software y, la falta de calidad del software producido son la causa de la aparición de la Ingeniería del software como una disciplina científica.

• Década 50-60: Programación Artesanal. Existe una fuerte dependencia del software sobre el hardware. Se caracteriza por el desarrollo artesanal de los productos software, ausencia total de planificación y escasa documentación de los mismos.
• Década 60-70: Lenguajes de Alto Nivel. Se produce un aumento en la complejidad de los sistemas, por lo que surge la necesidad de fiabilidad en los mismos, aunque hay una carencia de metodología para el desarrollo de aplicaciones. Reducción en el coste de procesamiento.
• Década 70-80: Ingeniería del software. Se intenta dar una solución a los problemas de etapas anteriores. Aparece la programación estructurada.
• Década 80-90: Paradigmas. Se produce un volcado de los resultados del álgebra y la lógica al campo práctico. Desarrollo de las herramientas CASE.
• Década 90: Inteligencia Artificial. Se caracteriza por la aparición de la Programación Orientada a Objetos.

Para clasificar el software se parte de la definición de Pressman: "El software se compone de los siguientes elementos:

La Calidad del software se mide en base a los conceptos de:

• Fiabilidad: Capaz de dar los mismos resultados bajo las mismas condiciones.
• Eficiencia: Utilización óptima de los recursos del sistema.
• Robustez o Tolerancia a Fallos: No poseer comportamiento catastrófico ante situaciones excepcionales.
• Corrección: Debe ajustarse a las especificaciones dadas por el usuario y sin errores de diseño y codificación.
• Adaptabilidad: Fácilmente modificables algunas de sus funciones sin afectar al resto.
• Portabilidad: Capacidad de poder integrarse en entornos distintos con un mínimo esfuerzo.
• Inteligible: Que tenga un diseño claro y fácil, bien documentado y estructurado.
• No erróneo: No debe haber diferencia entre valores reales y calculados.

Es el conjunto de fases por las que debe pasar un proyecto desde su concepción inicial, hasta que el sistema deja de utilizarse o se transforma en otro.

Existen diferentes modelos de ciclo de vida, que pueden aplicarse en función del tipo de sistema a desarrollar.

Este ciclo establece una serie de fases, al finalizar las cuales se obtiene una serie de productos (documentos, diagramas, programas) que permite evaluar lo realizado hasta ese momento y continuar con la fase siguiente o modificar algunos aspectos de las fases anteriores.

• Planificación estratégica: Su existencia es opcional. Si existe, su objetivo es adecuar los objetivos estratégicos de la organización (usuario) y la información necesaria para soportar dichos objetivos. Se debe determinar si el sistema es factible de informatizar, incluyendo algunas especificaciones básicas acerca de coste y tiempo necesarios para construir el sistema, así como los beneficios que se obtengan del nuevo sistema.

• Fase de Análisis: el objetivo de esta fase es el estudio de las necesidades de información que debe satisfacer el sistema a desarrollar, elaborando una serie de especificaciones formales que describan la funcionalidad del mismo y que permitan abordar con garantías la siguiente fase. Se puede estructurar en dos subfases:
• Análisis de Requerimientos del Sistema: se trata de establecer el alcance, los objetivos y requisitos del sistema, examinando las posibles alternativas que podrían solucionar las necesidades del usuario y recomendar una de ellas. Al final de esta subfase se obtiene un documento llamado "Documento de Requisitos del Sistema"
• Especificación Funcional del Sistema: conocida como Análisis Funcional. Una vez aceptado formalmente el documento anterior por ambas partes (equipo de desarrollo y usuario), se elabora un conjunto de especificaciones formales que describan la funcionalidad del sistema, estableciendo los subsistemas en que se descompondrá, definiendo los datos que utilizará y las interfaces de usuario. También se planificarán las pruebas que deberá superar el sistema, se estimará la relación coste/beneficio para comprobar si interesa su construcción y se establecerán los plazos de entrega del sistema. Todo ello se recoge en dos documentos, denominados "Documento de Especificación Funcional del Sistema" y "Documento de Pruebas del Sistema"

• Fase de Diseño: conocida como Análisis Orgánico. El objetivo de esta fase es obtener un conjunto de especificaciones que contemplarán los aspectos físicos del sistema, considerando las características tecnológicas del entorno específico en el que se implantará, que constituirá el punto de partida para la construcción del sistema. Equivale a la creación de una jerarquía apropiada de módulos de programas y de interfaces entre ellos para implantar la especificación creada en la fase anterior. Además, se encarga de la transformación de modelos de datos de Entidad-Relación en un diseño de base de datos. Al final de esta fase se obtienen el "Documento de Diseño Técnico" y el anterior "Documento de Pruebas del Sistema" con las ampliaciones relativas a la definición del entorno de pruebas.

• Fase de Construcción: el propósito de esta fase es, a partir de las especificaciones de diseño, la obtención del sistema completamente construido y probado, listo para ser implantado en la organización del usuario. También durante esta fase se desarrollará el conjunto de procedimientos y se llevará a cabo la formación necesaria que permitirá, tanto al personal del área de usuario final, como al personal del área de explotación o proceso de datos (si existe), la utilización óptima del sistema. Al final de esta fase se obtiene el Software correspondiente y, los siguientes documentos: "Documentación Técnica de Programación", "Manual de usuario", "Manual de Explotación", "Documento de Pruebas del Sistema" ampliado con los informes de las pruebas unitarias, de integración y globales.
• Generación de Pruebas Unitarias: Comprobar la validación de cada uno de los módulos.
• Generación de Pruebas de Integración: unión de todos los módulos y prueba de la unión.

• Fase de Implantación: el objetivo de esta fase es la puesta en servicio del sistema construido y conseguir su adaptación final por parte de los usuarios del mismo, para lo cual tratará de hacerse ver a éstos, mediante demostraciones formales (pruebas de aceptación) que el sistema cumple todos los objetivos y requisitos para los que fue desarrollado. En esta fase se incluye la ejecución y el mantenimiento del sistema, con lo que su duración se prolongará hasta que el sistema deje de utilizarse o sea sustituido por otro.
• Generación de Pruebas de Aceptación: Detección de errores de que el programa no se ajusta a las especificaciones.

1. Desarrollo manual.
1. Las herramientas utilizadas no están integradas ni relacionadas entre sí.
1. Los errores de análisis y diseño son muy caros de eliminar, ya que se encuentran muy tarde.
1. Se produce efecto bola de nieve: los errores se arrastran a las fases siguientes..

• Prototipo: primera versión de un producto, construido con poca funcionalidad y poca fiabilidad. La diferencia entre prototipo y producto final es que el prototipo es eficiente y el producto final debe serlo y, que en el prototipo no están todos los detalles y, el producto final debe contenerlos.

Clases de prototipos:

• Vertical: no recoge todas las funciones del sistema final.
• Horizontal: recoge todas las funciones, pero no las desarrolla por completo.

Este ciclo casi siempre supone que el modelo será operante, es decir, una colección de programas que simularán alguna o todas las funciones que el usuario desea. Pero dado que se pretende que dichos programas sean solo de modelo, también se supone que al concluirse el modelado, los programas se descartarán y se reemplazarán con programas reales. Normalmente se utilizan las siguientes herramientas:

• Un diccionario de datos integrado.
• Un generador de pantallas.
• Un generador de informes no guiado por procedimientos.
• Un lenguaje de programación de cuarta generación.
• Un lenguaje de consultas no guiado por procedimientos.
• Medios poderosos de administración de bases de datos.

1. Se incrementa la productividad del equipo de desarrollo. Se incrementa la calidad del producto final, ya que el prototipo permite trabajar, ensayar,...
1. disminuyen los costes de mantenimiento del producto final. Los tiempos de desarrollo son inferiores.
1. El tamaño del sistema es menor.
1. La especificación actúa como interface entre cliente y equipo de desarrollo.
1. El propio prototipo sirve de contrato con el cliente y cualquier cambio en el prototipo debe estar consolidado por ambas partes.
1. El prototipo es un documento vivo de buen funcionamiento del producto final.
1. Ayuda para determinar requerimientos expresados en el prototipo. Experimenta sobre los aspectos del sistema que representan mayor complejidad. Demuestran la viabilidad del sistema.
1. El cliente reacciona mucho mejor ante el prototipo, sobre el que puede experimentar, que no sobre una especificación escrita.

1. Fuerte inversión en un producto que se desechable: Los prototipos se descartan.
1. Tendencia a tratar de convertir el prototipo mismo en el sistema de producción.
1. Aumento del coste.
1. Se arrastran decisiones del diseño de prototipos al producto final.

El punto de partida es la utilización de un lenguaje formal de especificación, en el que las especificaciones son directamente ejecutables, o lo que es lo mismo, la especificación es el prototipo. El programa se obtiene de forma automática a partir de la especificación.

1. No se dispone de la tecnología necesaria para aplicarla en su totalidad.