Actividades del desarrollo de software
Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay algunos modelos más para representar este proceso.
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 s, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros s del software.
El mantenimiento o 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
Los modelos de desarrollo de software son una representación abstracta de una manera en particular. Realmente no representa cómo se debe desarrollar el software, sino de un enfoque común. Puede ser modificado y adaptado de acuerdo a las necesidades del software en proceso de desarrollo. 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. Existen tres paradigmas de los modelos de desarrollo de software:
1. Paradigma Tradicional:
Es uno de los paradigmas más antiguo, se inventó durante la creación del método estructurado. Si se elige un proyecto, el método varia en etapas. Como todo modelo, existen sus pros y contras al usar este paradigmas:
Si se aplica este paradigma, unos de los principales problemas , es que las etapas realizadas no son autónomas de las siguientes, creando una dependencia estructural y en el acaso de un error atrasaría todo el proyecto. Se tiene que tener pautas bien definidas, y que no se incurra a modificación porque implicaría en que el software no cumpla con su ciclo de vida. Tener en cuenta que el cliente no se vea afectado por la impaciencia.
2. Paradigma Orientado a Objetos:
Estos modelos se basan en la Programación orientada a objetos; por lo tanto, se refiere al concepto de clase, el análisis de requisitos y el diseño. El modelo o paradigma orientado a objetos posee dos características principales, las cuales son:
Permite la re-utilización de software.
Facilita el desarrollo de herramientas informáticas de apoyo al desarrollo, el cual es simple al implementarla en una notación orientado a objetos llamado UML.
3. Paradigma de Desarrollo Ágil:
Es un paradigma de las Metodologías De Desarrollo basado en procesos ágiles. Estos intentan evitar los tediosos caminos de las metodologías tradicionales enfocándose en las personas y los resultados. Usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incorporando los cambios continuamente.
Modelo de cascada
El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:
1.Especificación de requisitos
2.Diseño del software
3.Construcción o Implementación del software
4.Integración
5.Pruebas (o validación)
6.Despliegue (o instalación)
7.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 interaciones 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 De Software - Parte 3
Comentarios