El software como tal sigue un proceso de desarrollo en el cual se atraviesa por diferentes fases que conformaran lo que conocemos como el ciclo de vida clásico.
Este ciclo de vida clásico recibe diferentes nombres entre ellas “ciclo de vida básico”, “modelo en cascada” o “modelo lineal secuencial”, estos nombres nos dicen que se trata de un modelo de desarrollo de software en el que tenemos que seguir una serie de etapas ordenadas de forma sistemática con el fin de generar un software.
Típicamente estos modelos de desarrollo se enfocan al software empresarial y la mayoría de los autores hacen referencia a aquel software que se desarrolla a la medida de la organización, pero esto no quiere decir que el resto del software no deba seguir las mismas etapas o faces, así que por esta ocasión trataremos de hacerlo de carácter general.
A continuación se puede apreciar un esquema con el ciclo de vida clásico de los sistemas:
En este caso, quise mostrar el proceso desde el origen de todo el proceso, es decir, el origen del software, que como cualquier invención u obra humana surge de una necesidad, oportunidad o problema.
Sin importar cual sea el tipo de software del que hablemos, todos surgen de algunas de esas tres simples palabras, , si tengo la necesidad de eficiente el control de calificaciones o la necesidad de conseguir un buen lugar donde comer puedo desarrollar un software que cubra cualquiera de esas necesidades, ya sean propias o de un tercero, entonces estoy desarrollando para cubrir una necesidad; si tengo el problema de que existen muchos faltantes en el almacén o que soy muy olvidadizo con los cumpleaños puedo desarrollar un software que me ayude a controlar el inventario del almacén o me ayude a recordar las fechas de cumpleaños de las personas que conozco, entonces estoy desarrollando para solucionar un problema; y si en algún momento veo que no existe un software que cubra las necesidades de algún sector de la sociedad, puedo desarrollar un software que cubra esa necesidad, entonces estoy desarrollando porque he sabido detectar una buena oportunidad. Recordemos que todo problema o necesidad es una oportunidad.
Bien una vez detectada la necesidad el problema o la necesidad podemos comenzar el proceso:
ANALISIS
Esta fase realizamos una investigación a conciencia para tratar de conocer todos los requisitos e implicaciones del proyecto que estamos por abordar. Es de vital importancia que reunamos toda la información pertinente al software a desarrollar y que comprendamos la naturaleza del problema o necesidad que tratamos de cubrir. No podemos elaborar un software que solucione un problema que no comprendemos o no sabemos cómo se debe solucionar. Recordemos que al computadoras son maquinas capaces de resolver problemas muy complejos, pero que somos nosotros a través del software los que decimos como solucionar esos problemas.
Cuando se trata de un software empresarial, esta fase se enfoca en conocer no solo los requisitos o necesidades de la organización, sino también en conocer el funcionamiento de la organización, para crear un software que responda no solo a las necesidades, sino también a la estructura y funciones de la empresa.
DISEÑO
El diseño del software es la fase en donde modelamos la estructura y apariencia del software una vez que ya conocemos la naturaleza del problema y hemos determinado cual será la solución más optima. El diseño del software se enfoca en modelar la base de datos, la arquitectura del software, la interfaz y los algoritmos o procedimientos del mismo.
En el proceso del diseño debemos construir la solución que será el software basándonos en los requerimientos obtenidos del análisis, en este sentido el diseño es el mapa o el plano que seguirá el programador para construir el software.
CODIFICACIÓN
En esta fase tomamos todo lo que se plasmo en el diseño y lo traducimos en el conjunto de órdenes para computadora que es el software.
PRUEBAS
En esta fase tomamos el software que se produjo en la codificación y probamos todas las partes y procesos del mismo, para asegurarnos que cumple con los requisitos que se habían especificado.
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 qué no fue diseñado para la cantidad de operaciones que se realizan hoy en día, sea cual fuere la razón una vez que el software es obsoleto es tiempo de crear una nueva versión del software y es cuando volvemos a encontrar nuestra necesidad, oportunidad o problema.
Modelo en Espiral del siclo de vida del software
El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
Ciclos o Iteraciones
En cada vuelta o iteración hay que tener en cuenta:
- Los Objetivos: qué necesidad debe cubrir el producto.
- Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:
- Características: experiencia del personal, requisitos a cumplir, etc.
- Formas de gestión del sistema.
- Riesgo asumido con cada alternativa.
- Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:
- Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:
- Angular: Indica el avance del proyecto del software dentro de un ciclo.
- Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.
Tareas
Para cada ciclo habrá cuatro actividades:
- Determinar Objetivos.
- Análisis del riesgo.
- Desarrollar y probar.
- Planificación.
Determinar o fijar objetivos
- Fijar también los productos definidos a obtener: requisitos, especificación, manual de usuario.
- Fijar las restricciones.
- Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
- Hay una cosa que solo se hace una vez: planificación inicial.
Desarrollar, verificar y validar(probar)
- Tareas de la actividad propia y de prueba.
- Análisis de alternativas e identificación resolución de riesgos.
- Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.
Análisis del riesgo
- Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir. Se evalúan alternativas. Se debe tener un prototipo antes de comenzar a desarrollar y probar.
En resumen, es para tener en cuenta los riesgos de cada uno de los ámbitos
Mecanismos de control
- La dimensión radial mide el coste.
- La dimensión angular mide el grado de avance del proyecto.
Ventajas
El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.
- Reduce riesgos del proyecto
- Incorpora objetivos de calidad
- Integra el desarrollo con el mantenimiento, etc.
Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.
Desventajas
- Genera mucho tiempo en el desarrollo del sistema
- Modelo costoso
- Requiere experiencia en la identificación de riesgos
Inconvenientes
Planificar un proyecto con esta metodología es a menudo imposible, debido a la incertidumbre en el número de iteraciones que serán necesarias. En este contexto la evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluación requiere la intervención de profesionales de gran experiencia.
Salto de página
Modelo de Desarrollo por Prototipos
El prototipo es una aplicación que funciona.[Salto de ajuste de texto]La finalidad del prototipo es probar varias suposiciones formuladas por analistas y usuarios con respecto a las características requeridas del sistema.[Salto de ajuste de texto]Los prototipos se crean con rapidez, evolucionan a través de un proceso interactivo y tienen un bajo costo de desarrollo.
Objetivos de los Prototipos
Los objetivos de los prototipos son:[Salto de ajuste de texto]a) aclarar los requerimientos de los usuarios
b) verificar la factibilidad del diseño del sistema
Razones para emplear los Prototipos
Las razones para emplear los prototipos son:[Salto de ajuste de texto]a) aumentar la productividad
b) redesarrollo planificado
c) entusiasmo de los usuarios respecto a los prototipos
Condiciones para aplicar Prototipos
Las condiciones para aplicar prototipos son:[Salto de ajuste de texto]a) no conocer los requerimientos
b) evaluar los requerimientos
c) costos altos de inversión
d) alto riesgo
e) nueva tecnología
Etapas del Método con Prototipos
Las etapas del método con prototipos son:[Salto de ajuste de texto]1- identificación de requerimientos conocidos [Salto de ajuste de texto]2- desarrollo de un modelo de trabajo[Salto de ajuste de texto]3- participación del usuario[Salto de ajuste de texto]4- revisión del prototipo[Salto de ajuste de texto]5- iteración del proceso de refinamiento
El método con prototipos o construcción de los mismos se puede graficar de la siguiente manera:
Usos de los Prototipos
El uso de los prototipos está dado por:
1- El abandono de la aplicación[Salto de ajuste de texto]El prototipo satisfizo pero no es necesario en el desarrollo
2- La implantación del prototipo[Salto de ajuste de texto]El prototipo en este caso es la aplicación que se necesita sin un desarrollo posterior.
3- El redesarrollo de la aplicación[Salto de ajuste de texto]El prototipo representa la determinación de requerimientos
4- El inicio de un nuevo prototipo[Salto de ajuste de texto]Necesidad de un enfoque diferente. La experiencia ganada con el prototipo anterior facilita el nuevo enfoque.
Herramientas para el Desarrollo de Prototipos
Las herramientas para el desarrollo de prototipos serían:
– Lenguajes de Cuarta Generación – Focus – SQL
– Lenguajes no Orientados a Procedimientos
– Lenguajes de Consulta y Recuperación – QBEXAMPLE
– Generadores de reporte – EASYTRIEVE
– Generadores de aplicaciones – Focus – Natural
– Generadores de pantallas – SDA
– Diccionarios de datos
– Desarrollo sobre PC
– Oracle (Designer/2000, Developer/2000)
Estrategias para el Desarrollo de Prototipos
Las estrategias para el desarrollo de prototipos son:
1- Prototipos para pantallas[Salto de ajuste de texto]El elemento clave es el intercambio de información con el usuario.
2- Prototipos para procedimientos de procesamiento[Salto de ajuste de texto]El prototipo incluye solo procesos sin considerar errores.
3- Prototipos para funciones básicas [Salto de ajuste de texto]Solo se desarrolla el núcleo de la aplicación, es decir solo los procesos básicos.
Errores sobre el tema Prototipos
Los errores sobre el tema de prototipos son:[Salto de ajuste de texto]– el desarrollo del prototipo es trivial
– es solo para aplicaciones pequeñas
– es solo para aplicaciones sencillas
– la participación del usuario es simbólica
Tareas de los usuarios
Las tareas de los usuarios son: [Salto de ajuste de texto]1- identificar la finalidad del sistema
2- describir la salida del sistema
3- describir los requerimientos de datos
4- utilizar y evaluar el prototipo
5- identificar las mejoras necesarias
6- documentar las características no deseables
Salto de página
Cuestionario
- ¿Cuál es el siclo de vida del software?
Son un conjunto de procedimiento que se llevan a cabo para crear y mantener una aplicación
- ¿Cuál es el modelo clásico?
Es el esquema tradicional que se sigue para darle mantenimiento a una aplicación
- ¿Cuáles son las etapas del modelo clásico?
Análisis
Diseño
Desarrollo
Prueba
Implementación
Mantenimiento
- ¿Cuál es el modelo en Espiral?
El modelo en espiral está basado en cuatro tareas repetitivas las cuales son Determinar Objetivos, Análisis del riesgo, Desarrollar y probar, Planificación, y al finalizar estas tareas nuevamente se inicia con el proceso, para ir escalando el software.
- ¿Cuál es el modelo basado en prototipos?
Es un modelo del siclo de vida del software basado en la creación de una aplicación que cumpla con las principales características que se requieren para luego a partir de este implementar mejoras y volver mas robusto el software.
Un comentario en “Modelo Clásico del ciclo de vida del software”