[ Metodología de desarrollo de Software ]

Metodología de Desarrollo de Software

La "metodología de Desarrollo de Software", básicamente, nos habla de un enfoque que nos ayuda a interpretar la realidad o disciplina, en este caso, nos ayuda a interpretar a la "Ingeniería de Software".

Su uso radica en la planificación y control de un sistema de información en específico.

Existen diferentes modelos o metodologías que aplicamos para entender mejor a un a un sistema, procederemos de manera "breve" a explicar cada uno de ellos:

1.- Modelo de Cascada:

El "Modelo de Cascada" es uno de los métodos más usados por los Analistas de Sistemas para el desarrollo de Software, este método se centra en la "realización" de etapas por separado que irán culminando conforme vayan terminado las otras de manera satisfactoria, cada etapa tendrá como salida una serie de documentación que explicará los resultados previos.

Ingeniería y Análisis del Sistema: establece requisitos de los elementos del sistema.

Análisis de los requisitos del software: identifica las funciones del software, el rendimiento, sus interfaces y la información.

Diseño: se basa en estructura de datos, arquitectura del software el detalle de los procedimientos y la caracterización de la interfaz. Además escoge las herramientas para la codificación.

Codificación: el diseño se traduce en lenguaje de máquina.

Pruebas: Aquí se comprueba si existe algún error con el software o si funciona correctamente. Hasta que sea aceptado por el usuario.

Mantenimiento: esta fase se da debido a que después de la entrega pudo haber
errores en el software, o el software no se adapte al entorno externo o que el cliente requiera ampliaciones funcionales o de rendimiento.

2.- Modelo Espiral: 

El "Modelo Espiral" es un modelo que se centra en una serie de iteracciones incrementales, las cuales van aumentando para obtener un "software" más completo.
En las primeras iteracciones nos encontramos con un modelo en papel, básicamente un prototipo, mientras que en las últimas iteracciones ya encontramos un diseño bastante completo con un diseño elaborado.
El "Modelo Espiral" se divide en un número de actividades que también son llamadas "regiones de tareas":

Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.

Planificación: las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto.

Análisis de riesgos: Las tareas requeridas para evaluar riesgos técnicos y de gestión.

Ingeniería Las tareas requeridas para construir una o más representaciones de la aplicación.

Construcción y acción: Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica)

Evaluación del cliente: Las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación. Cada una de las regiones están compuestas por un conjunto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las características del proyecto que va a emprenderse. Para proyectos pequeños, el número de tareas de trabajo y su formalidad es bajo. Para proyectos mayores ymás críticos cada región de tareas contiene tareas de trabajo que se definen para lograr un nivel más alto de formalidad. En todos los casos, se aplican las actividades de protección.

3.- Metodología de Programación Extrema:

Este "método" se centra en evitar el desarrollo de funciones que sean innecesarias para nuestro sistema en particular, además posee el objetivo de entender sistemas que tengan un nivel de complejidad un tanto alto. Poseen la "desventaja" que suele ser un método que toma bastante tiempo, así como recursos humanos y capital, en comparación a otros métodos antes explicados.

4.- Metodología de Prototipo:

Este último método se centra en "permitir" a los desarrolladores de Software la posibilidad de validar su esencia funcional a los respectivos clientes, y realizar los cambios necesarios para poder entregar la fase final del sistema.
Posee la ventaja de poder obtener una idea bastante clara sobre el proceso funcional del software, reduciendo en gran cantidad las fallas que podrían producirse, produciendo una buena impresión en la entrega de los requisitos y en la entrega del análisis general.