Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información.
A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.
El framework para metodología de desarrollo de software consiste en:
- Una filosofía de desarrollo de programas de computación con el enfoque del proceso de desarrollo de software
- Herramientas, modelos y métodos para asistir al proceso de desarrollo de software
Estos frameworks son a menudo vinculados a algún tipo de
organización, que además desarrolla, apoya el uso y promueve la
metodología. La metodología es a menudo documentada en algún tipo de
documentación formal.
Historia
El desarrollo de los sistemas tradicionales de ciclo de vida se
originó en la década de 1960 para desarrollar a gran escala funcional de
sistemas de negocio en una época de grandes conglomerados
empresariales. La idea principal era continuar el desarrollo de los
sistemas de información en una muy deliberada, estructurada y metódica,
reiterando cada una de las etapas del ciclo de vida. Los sistemas de información en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de cálculo.
Metodologías de Desarrollo de Software tiene como objetivo presentar
un conjunto de técnicas tradicionales y modernas de modelado de sistemas
que permitan desarrollar software de calidad, incluyendo heurísticas de
construcción y criterios de comparación de modelos de sistemas.
Para tal fin se describen, fundamentalmente, herramientas de Análisis
y Diseño Orientado a Objetos (UML), sus diagramas, especificación, y
criterios de aplicación de las mismas. Como complemento se describirán
las metodologías de desarrollo de software que utilizan dichas
herramientas, ciclos de vida asociados y discusión sobre el proceso de
desarrollo de software más adecuado para las diferentes aplicaciones
ejemplos que se presentarán. Principalmente, se presentará el Proceso
Unificado el cual utiliza un ciclo de vida iterativo e incremental.
Kendall y Kendall
- Identificación del problema, oportunidades y objetivos.
- Determinación de los requerimientos de información.
- Análisis de las necesidades del sistema.
- Diseño del sistema recomendado.
- Desarrollo y documentacion del software.
- Pruebas y mantenimiento del sistema.
- Implantación y evaluación del sistema.
James Senn
- Ciclo de vida y desarrollo del sistema.
- Desarrollo por análisis estructurado
- Prototipo del sistema.
Llorens Fabregas
- Requerimientos.
- Análisis/Diseño.
- Construcción.
- Pruebas.
- Producción y mantenimiento.
Jonas Montilva
- Definir el proyecto.
- Análisis del contexto.
- Definición de los requerimientos.
- Diseño preliminar.
- Diseño detallado.
Roger Pressman
- Análisis de los requerimientos del Software.
- Diseño.
- Generación de código.
- Pruebas.
- Mantenimiento.
Proceso para el desarrollo de software
Un proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software.
Hay varios modelos a seguir para el establecimiento de un proceso para
el desarrollo de software, cada uno de los cuales describe un enfoque
diferente para diferentes actividades que tienen lugar durante el
proceso. Algunos autores consideran un modelo de ciclo de vida un
término más general que un determinado proceso para el desarrollo de
software. Por ejemplo, hay varios procesos de desarrollo de software
específicos que se ajustan a un modelo de ciclo de vida de espiral.
Planificación
La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los requisitos.
Los clientes suelen tener una idea más bien abstracta del resultado
final, pero no sobre las funciones que debería cumplir el software.
Una vez que se hayan recopilado los requisitos del cliente, se debe
realizar un análisis del ámbito del desarrollo. Este documento se conoce
como especificación funcional.
Implementación, pruebas y documentación
La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto. Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la función de detectar los errores de software lo antes posible.
La documentación
del diseño interno del software con el objetivo de facilitar su mejora y
su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir
la documentación de un API, tanto interior como exterior.
Despliegue y mantenimiento
El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción.
Entrenamiento y soporte para el software
es de suma importancia y algo que muchos desarrolladores de software
descuidan. Los usuarios, por naturaleza, se oponen al cambio porque
conlleva una cierta inseguridad, es por ello que es fundamental instruir
de forma adecuada a los futuros usuarios del software.
El mantenimiento
y mejora del software de un software con problemas recientemente
desplegado puede requerir más tiempo que el desarrollo inicial del
software. Es posible que haya que incorporar código que no se ajusta al
diseño original con el objetivo de solucionar un problema o ampliar la
funcionalidad para un cliente. Si los costes de mantenimiento son muy
elevados puede que sea oportuno rediseñar el sistema para poder contener
los costes de mantenimiento.
Modelos de desarrollo de software
Hay varios modelos para perfilar el proceso de desarrollo, cada uno
de las cuales cuenta con pros y contras. El proyecto debería escoger el
más apropiado para sus necesidades. En ocasiones puede que una
combinación de varios modelos sea apropiado.
Modelo de cascada
El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:- Especificación de requisitos
- Diseño del software
- Construcción o Implementación del software
- Integración
- Pruebas (o validación)
- Despliegue (o instalación)
- Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo cuando se
finaliza una fase, comienza la otra. En ocasiones se realiza una
revisión antes de iniciar la siguiente fase, lo que permite la
posibilidad de cambios (lo que puede incluir un proceso de control
formal de cambio). Las revisiones también se utilizan para asegurar que
la fase anterior ha sido totalmente finalizada; los criterios para
completar una fase se conocen frecuentemente con el término inglés
"gate" (puerta). Este modelo desaconseja revisitar y revisar fases que
ya se han completado. Esta falta de flexibilidad en un modelo de cascada
puro ha sido fuente de crítica de los defensores de modelos más
flexibles.
Modelo de espiral
La principal características del modelo en espiral es la gestión de
riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue
creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones,
pero dando énfasis en un área que para muchos no jugó el papel que
requiere en otros modelos: un análisis iterativo y concienzudo de los
riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a través de algunas
iteraciones con el diagrama de los cuatro cuadrantes representativos de
las siguientes actividades:
- crear planes con el propósito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;
- Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;
- la implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en
las condiciones de las opciones y limitaciones para facilitar la
reutilización de software, la calidad del software puede ayudar como una
meta propia en la integración en el desarrollo del producto. Sin
embargo, el modelo en espiral tiene algunas limitaciones, entre las que
destacan:
- El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que acepten este análisis y actúen en consecuencia. Para ello es necesaria confianza en los desarrolladores así como la predisposición a gastar más para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.
- Si la implementación del riesgo de análisis afectará de forma esencial los beneficios del proyecto, no debería utilizarse este modelo.
- Los desarrolladores de software han de buscar de forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la búsqueda de un plan para conseguir los
objetivos con las limitaciones del proyecto para así buscar y eliminar
todos los riesgos potenciales por medio de un cuidadoso análisis, y si
fuera necesario incluyendo la fabricación de un prototipo. Si es
imposible descartar algunos riesgos, el cliente ha de decidir si es
conveniente terminar el proyecto o seguir adelante ignorando los
riesgos. Por último, se evalúan los resultados y se inicia el diseño de
la siguiente fase.
Desarrollo iterativo e incremental
El desarrollo iterativo recomienda la construcción de secciones
reducidas de software que irán ganando en tamaño para facilitar así la
detección de problemas de importancia antes de que sea demasiado tarde.
Los procesos iterativos pueden ayudar a desvelar metas del diseño en el
caso de clientes que no saben cómo definir lo que quieren.
Desarrollo ágil
El desarrollo ágil de software utiliza un desarrollo iterativo como
base para abogar por un punto de vista más ligero y más centrado en las
personas que en el caso de las soluciones tradicionales. Los procesos
ágiles utilizan retroalimentación en lugar de planificación, como
principal mecanismo de control. La retroalimentación se canaliza por
medio de pruebas periódicas y frecuentes versiones del software.
Hay muchas variantes de los procesos ágiles:- En el caso de la programación extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un día o en una semana, en lugar de los meses o años de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al desarrollo. Después se programa el código, que será completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabrían como mejorar el conjunto de pruebas necesario. El diseño y la arquitectura emergen a partir de la refactorización del código, y se da después de programar. El diseño lo realizan los propios desarrolladores del código. El sistema, incompleto, pero funcional se despliega para su demostración a los usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de más importancia.
Codificación y corrección
El desarrollo de codificación y corrección (en inglés "Code and fix")
es, más que una estrategia predeterminada, el resultado de una falta de
experiencia o presión que se ejerce sobre los desarrolladores para
cumplir con una fecha de entrega. Sin dedicar tiempo de forma explícita para el diseño, los programadores comienzan de forma inmediata a producir código. Antes o después comienza la fase de pruebas de software (a menudo de forma tardía) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software.
Fuentes:
0 comentarios: