Ciclo de Vida del software
INTRODUCCION
La necesidad de adoptar los sistemas informáticos al mercado, obliga a los programadores realizar un relevamiento de las solicitudes de quien necesitaba cierto programa o producto, en estos requerimientos se incluye la tarea de codificar, que no era administrada ni supervisada, por lo que se corregía a medida que surgían los errores.
La complejidad de
los programas ha aumentado en las últimas décadas, por lo que la técnica de
“codificar y corregir” ha quedado obsoleta, porque en esta técnica se basa en
requerimientos ambiguos y sin especificaciones puntuales. Esto ocasionaba que
el cliente solo diera especificaciones generales del producto. Se trataba de
correcciones continuas que satisfagan las necesidades que surgían durante el
proceso.
Si bien con esto
se evita gastar recursos en el análisis, la planificación, gestión de recursos,
documentación, y otros procesos. Solo resulta beneficioso cuando se trata de un
proyecto muy pequeño.
Cuando el sistema
no se pequeño o es muy complicado esta técnica nos trae desventajas en el costo
de recurso que siempre se irá incrementando, además alargara el tiempo de
desarrollo y la calidad del software no será tan confiable.
El ciclo de vida
del software se compone de dos etapas principales que son; la necesidad de
adoptarlo y su definición y las metodologías que podemos adoptar. En este
proceso se usan modelos de ciclo de vida, en las cuales cada uno tiene
ventajas.
MARCO TEORICO
La metodología para el desarrollo de
software es un modo sistemático de realizar, gestionar y administrar un
proyecto para llevarlo a cabo con altas
posibilidades de éxito. Esta sistematización nos indica cómo dividiremos
un gran proyecto en módulos más pequeños llamados etapas, y las acciones que
corresponden en cada una de ellas, nos ayuda a definir entradas y salidas para
cada una de las etapas y, sobre todo, normaliza el modo en que administraremos
el proyecto. Entonces, una metodología para el desarrollo de software son los
procesos a seguir sistemáticamente para idear, implementar y mantener un
producto software desde que surge la necesidad del producto hasta que cumplimos
el objetivo por el cual fue creado.
Finalidad de usar metodología
Lo que buscamos guiándonos con una
metodología es prolijidad, corrección y control en cada etapa del desarrollo de
un programa. Lo que nos permitirá una forma sistemática para poder obtener un
producto correcto y libre de errores.
Clasificación
de las metodologías
Existen dos metodologías que tienen
analogía en la práctica con los paradigmas de programación. Metodología
estructurada y metodología orientada a objetos.
- Metodología estructurada: la orientación de esta metodología se dirige hacia los procesos que intervienen en el sistema a desarrollar, es decir, cada función a realizar por el sistema se descompone en pequeños módulos individuales. Es más fácil resolver problemas pequeños, y luego unir cada una de las soluciones, que abordar un problema grande.
- Metodología orientada a objetos: a diferencia de la metodología mencionada anteriormente, ésta no comprende los procesos como funciones sino que arma módulos basados en componentes, es decir, cada componente es independiente del otro. Esto nos permite que el código sea reutilizable. Es más fácil de mantener porque los cambios están localizados en cada uno de estos componentes.
En computación, el software -en
sentido estricto- es todo progqrama o aplicación programado para realizar
tareas específicas. El término "software" fue usado por primera vez
por John W. Tukey en 1957.
Algunos autores prefieren ampliar la
definición de software e incluir también en la definición todo lo que es
producido en el desarrollo del mismo.
La palabra "software" es un
contraste de "hardware"; el software se ejecuta dentro del hardware.
El
software en sentido amplio
Una definición más amplia de software
incluye mucho más que sólo los programas. Esta definición incluye:
- La representación del software:
programas, detalles del diseño escritos en un lenguaje de descripción de
programas, diseño de la arquitectura, especificaciones escritas en lenguaje
formal, requerimientos del sistema, etc.
- El conocimiento de la ingeniería del
software: Es toda la información relacionada al desarrollo de software (por
ejemplo, cómo utilizar un método de diseño específico) o la información
relacionada al desarrollo de un software específico (por ejemplo, el esquema de
pruebas en un proyecto). Aquí se incluye información relacionada al proyecto,
información sobre la tecnología de software, conocimiento acerca de sistemas
similares y la información detallada relacionada a la identificación y solución
de problemas técnicos.
El
"software" como programa
Consiste en un código en un lenguaje
máquina específico para un procesador individual. El código es una secuencia de
instrucciones ordenadas que cambian el estado del hardware de una computadora.
El software se suele escribir en un
lenguaje de programación de alto nivel, que es más sencillo de escribir (pues
es más cercano al lenguaje natural humano), pero debe convertirse a lenguaje
máquina para ser ejecutado.
El software puede distinguirse en tres
categorías: software de sistema, software de programación y aplicación de
software. De todas maneras esta distinción es arbitraria y muchas veces un
software puede caer unas varias categorías.
- Software de sistema: ayuda a
funcionar al hardware y a la computadora. Incluye el sistema operativo, controladores
de dispositivos, herramientas de diagnóstico, servidores, sistema de ventanas,
utilidades y más. Su propósito es evitar lo más posible los detalles complejos
de la computación, especialmente la memoria y el hardware.
- Software de programación: provee
herramientas de asistencia al programador. Incluye editores de texto,
compiladores, intérprete de instrucciones, enlazadores, debuggers, etc.
- Software de aplicación: permite a
los usuarios finales hacer determinadas tareas. Algún software de aplicación
son los navegadores, editores de texto, editores gráficos, antivirus,
mensajeros, etc.
Modelos de Ciclo de Vida
• El alcance del ciclo de vida, que
depende de hasta dónde deseamos llegar con el proyecto: sólo saber si es viable
el desarrollo de un producto, el desarrollo completo o el desarrollo completo
más las actualizaciones y el mantenimiento.
• La cualidad y cantidad de las etapas
en que se divide el ciclo de vida: según el ciclo de vida que adoptado, y el
proyecto para el cual lo adoptamos.
• La estructura y la sucesión de las
etapas, si hay realimentación entre ellas, y si tenemos libertad de repetirlas.
Es el más sencillo de todos los
modelos. Consiste en descomponer la actividad global del proyecto en etapas
separadas que son realizadas de manera lineal, es decir, cada etapa se realiza
una sola vez, a continuación de la etapa anterior y antes de la etapa
siguiente. Con un ciclo de vida lineal es muy fácil dividir las tareas, y
prever los tiempos (sumando linealmente los de cada etapa).
Las actividades de cada una de las etapas,
deben ser independientes entre sí, es decir, que es condición primordial que no
haya retroalimentación entre ellas, aunque sí pueden admitirse ciertos
supuestos de realimentación correctiva. Desde el punto de vista de la gestión,
requiere también que se conozca desde el primer momento, con excesiva rigidez,
lo que va a ocurrir en cada una de las distintas etapas antes de comenzarla.
Esto último minimiza, también, las posibilidades
de errores durante la codificación y reduce al mínimo la necesidad de requerir información
del cliente o del usuario.
Se destaca como ventaja la sencillez
de su gestión y administración tanto económica como temporal, ya que se acomoda
perfectamente a proyectos internos de una empresa para programas muy pequeños
de ABM (sistemas que realizan Altas, Bajas y
Modificaciones sobre un conjunto de
datos). Tiene como desventaja que no es apto para Desarrollos que superen
mínimamente requerimientos de retroalimentación entre etapas, es decir, es muy
costoso retomar una etapa anterior al detectar alguna falla.
Es válido tomar este ciclo de vida
cuando algún sector pequeño de una empresa necesita llevar un registro de datos
acumulativos, sin necesidad de realizar procesos sobre ellos más que una
consulta simple. Es decir, una aplicación que se dedique exclusivamente a
almacenar datos, sea una base de datos o un archivo plano. Debido a que la
realización de las etapas es muy simple y el código muy sencillo.
Este
modelo de ciclo de vida fue propuesto por Winston Royce en el año 1970. Es un
ciclo de vida que admite iteraciones, contrariamente a la creencia de que es un
ciclo de vida secuencial como el lineal. Después de cada etapa se realiza una o
varias revisiones para comprobar si se puede pasar a la siguiente. Es un modelo
rígido, poco flexible, y con muchas restricciones. Aunque fue uno de los
primeros, y sirvió de base para el resto de los modelos de ciclo de vida.
Una de sus ventajas, además de su planificación sencilla, es la de proveer un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado.
Se pueden considerar como
inconvenientes: la necesidad de contar con todos los requerimientos (o la
mayoría) al comienzo del proyecto, y, si se han cometido errores y no se
detectan en la etapa inmediata siguiente, es costoso y difícil volver atrás para
realizar la corrección posterior.
Además, los resultados no los veremos
hasta que no estemos en las etapas finales del ciclo, por lo que, cualquier
error detectado nos trae retraso y aumenta el costo del desarrollo en función
del tiempo que insume la corrección de éstos.
Es un ciclo adecuado para los
proyectos en los que se dispone de todos los requerimientos al comienzo, para
el desarrollo de un producto con funcionalidades conocidas o para proyectos,
que aun siendo muy complejos, se entienden perfectamente desde el principio.
Este ciclo fue diseñado por Alan
Davis, y contiene las mismas etapas que el ciclo de vida en cascada puro. A
diferencia de aquél, a éste se le agregaron dos sub-etapas de retroalimentación
entre las etapas de análisis y mantenimiento, y entre las de diseño y
debugging.
Las ventajas y desventajas de este
modelo son las mismas del ciclo anterior, con el agregado de los controles
cruzados entre etapas para lograr una mayor corrección.
Podemos utilizar este modelo de ciclo
de vida en aplicaciones, que si bien son simples (pequeñas transacciones sobre
bases de datos por ejemplo), necesitan una confiabilidad muy alta. Un ejemplo
claro en el que no nos podemos permitir el lujo de cometer errores es una
aplicación de facturación, en la que si bien los procedimientos vistos
individualmente son de codificación e interpretación sencilla, la aplicación en
su conjunto puede tener matices complicados.
Este ciclo de vida es parecido al
ciclo de vida en cascada puro, con la diferencia de que en el ciclo de vida en
cascada no se pueden solapar las etapas, y en éste sí. Esto suele, en muchos
casos, aumentar su eficiencia ya que la retroalimentación entre etapas se
encuentra implícitamente en el modelo.
Se hace notar como ventajas la
ganancia de calidad en lo que respecta al producto final, la falta de necesidad
de una documentación detallada (el ahorro proviene por el solapado de las
etapas). Sus desventajas también se refieren al solapamiento de las etapas: es
muy difícil gestionar el comienzo y fin de cada etapa y los problemas de comunicación,
si aparecen, generan inconsistencias en el proyecto.
Cuando necesitemos realizar una
aplicación que compartirá los recursos (CPU, memoria o espacio de almacenamiento)
con otras aplicaciones en un ambiente productivo, este modelo de ciclo de vida
es una opción muy válida. El solapamiento de sus etapas nos permite en la
práctica jugar un poco con el modelo de
tres capas ahorrando recursos.
Sigue el modelo de ciclo de vida en
cascada. Cada una de las cascadas se divide en sub-etapas independientes que se
pueden desarrollar en paralelo.
La ventaja es que se puede tener más
gente trabajando al mismo tiempo, pero la desventaja es que pueden surgir
dependencias entre las distintas subetapas que detengan el proyecto
temporalmente si no es gestionado de manera correcta.
Se puede utilizar este modelo para
administrar cualquier proyecto mencionado en los modelos anteriores. Pero
cuidando de administrar muy bien los tiempos.
También derivado del ciclo de vida en
cascada puro, este modelo busca reducir el riesgo que surge entre las
necesidades del usuario y el producto final por malos entendidos durante la
etapa de solicitud de requerimientos.
Es la iteración de varios ciclos de
vida en cascada. Al final de cada iteración se le entrega al cliente una
versión mejorada o con mayores funcionalidades del producto. El cliente es
quien luego de cada iteración, evalúa el producto y lo corrige o propone
mejoras.
Estas iteraciones se repetirán hasta
obtener un producto que satisfaga al cliente.
Se suele utilizar en proyectos en los
que los requerimientos no están claros de parte del usuario, por lo que se hace
necesaria la creación de distintos prototipos para presentarlos y conseguir la
conformidad del cliente.
Podemos adoptar el modelo mencionado
en aplicaciones medianas a grandes, en las que el usuario o cliente final no
necesita todas las funcionalidades desde el principio del proyecto. Quizás una
empresa que debe migrar sus aplicaciones hacia otra arquitectura, y desea
hacerlo paulatinamente, es un candidato ideal para este tipo de modelo de ciclo
de vida.
El uso de programas prototipo no es
exclusivo del ciclo de vida iterativo. En la práctica los prototipos se
utilizan para validar los requerimientos de los usuarios en cualquier ciclo de
vida.
Si no se conoce exactamente cómo
desarrollar un determinado producto o cuáles son las especificaciones de forma
precisa, suele recurrirse a definir especificaciones iniciales para hacer un
prototipo, o sea, un producto parcial y provisional. En este modelo, el
objetivo es lograr un producto intermedio, antes de realizar el producto final,
para conocer mediante el prototipo cómo responderán las funcionalidades previstas
para el producto final.
Antes de
adoptar este modelo de ciclo debemos evaluar si el esfuerzo por crear un prototipo
vale realmente la pena adoptarlo.
Se utiliza mayoritariamente en
desarrollos de productos con innovaciones importantes, o en el uso de
tecnologías nuevas o poco probadas, en las que la incertidumbre sobre los
resultados a obtener, o la ignorancia sobre el comportamiento, impiden iniciar
un proyecto secuencial.
La ventaja de este ciclo se basa en
que es el único apto para desarrollos en los que no se conoce a priori sus
especificaciones o la tecnología a utilizar. Como contrapartida, por este
desconocimiento, tiene la desventaja de ser altamente costoso y difícil para la
administración temporal.
Si deseamos migrar aplicaciones de
tecnología para adoptar sus nuevas funcionalidades o simplemente para estar en
la cresta de la ola, este modelo es ideal. Un claro ejemplo son las
llegadas de Java y la tecnología .NET que si bien contaban con respaldo y
material de ayuda, implantaron nuevas tendencias.
Este modelo acepta que los
requerimientos del usuario pueden cambiar en cualquier momento.
La
práctica nos demuestra que obtener todos los requerimientos al comienzo del proyecto
es extremadamente difícil, no sólo por la dificultad del usuario de transmitir su
idea, sino porque estos requerimientos evolucionan durante el desarrollo de
esta manera, surgen nuevos requerimientos a cumplir. El modelo de ciclo de vida
evolutivo afronta este problema mediante una iteración de ciclos requerimientos–desarrollo–evaluación.
Resulta ser un modelo muy útil cuando
desconocemos la mayoría de los requerimientos iniciales, o estos requerimientos
no están completos.
Tomemos como ejemplo un sistema
centralizado de stock–ventas–facturación, en el cual hay muchas áreas que
utilizarán la aplicación. Tenemos dos complicaciones: la primera, los usuarios
no conocen de informática, la segunda, no es uno, sino varios los sectores que
nos pueden pedir modificaciones o hacer nuevas solicitudes.
Además, el pedido de un sector puede
influir en los requerimientos del otro. Se hace necesario, entonces, lograr que
la aplicación evolucione hasta lograr las satisfacciones de los todos los
sectores involucrados.
Este modelo de ciclo de vida se basa
en la filosofía de construir incrementando las funcionalidades del programa. Se
realiza construyendo por módulos que cumplen las diferentes funciones del
sistema. Esto permite ir aumentando gradualmente las capacidades del software.Este
ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipo
desarrollar un módulo particular en el caso de que el proyecto sea realizado por
un equipo de programadores.
Es una
repetición del ciclo de vida en cascada, aplicándose este ciclo en cada
funcionalidad del programa a construir. Al final de cada ciclo le entregamos
una versión al cliente que contiene una nueva funcionalidad. Este ciclo de vida
nos permite realizar una entrega al cliente antes de terminar el proyecto.
El modelo de ciclo de vida incremental
nos genera algunos beneficios tales comolos que se describen a continuacion:
• Construir un sistema pequeño siempre
es menos riesgoso que construir un sistema grande.
• Como desarrollamos
independientemente las funcionalidades, es más fácil relevarlos requerimientos
del usuario.
• Si se detecta un error grave, sólo
desechamos la última iteración.
• No es necesario disponer de los
requerimientos de todas las funcionalidades en el comienzo del proyecto y
además facilita la labor del desarrollo con la conocida filosofía de divide
& conqueror.
Este modelo de ciclo de vida no está
pensado para cierto tipo de aplicaciones, sino que está orientado a cierto tipo
de usuario o cliente. Podremos utilizar este modelo de ciclo de vida para casi
cualquier proyecto, pero será verdaderamente útil cuando el usuario necesite
entregas rápidas, aunque sean parciales.
Este ciclo puede considerarse una
variación del modelo con prototipado, fue diseñado por Boehm en el año 1988. El
modelo se basa en una serie de ciclos repetitivos para ir ganando madurez en el
producto final. Toma los beneficios de los ciclos de vida incremental y por
prototipos, pero se tiene más en cuenta el concepto de riesgo que aparece
debido a las incertidumbres e ignorancias de los requerimientos proporcionados
al principio del proyecto o que surgirán durante el desarrollo. A medida que el
ciclo se cumple (el avance del espiral), se van obteniendo prototipos sucesivos
que van ganando la satisfacción del cliente o usuario.
A menudo, la fuente de incertidumbres
es el propio cliente o usuario, que en la mayoría de las oportunidades no sabe
con perfección todas las funcionalidades que debe tener el producto.
En este modelo hay cuatro actividades
que envuelven a las etapas.
- Planificación: Relevamiento de requerimientos iniciales o luego de una iteración.
- Análisis de riesgo: De acuerdo con el relevamiento de requerimientos decidimos si continuamos con el desarrollo.
- Implementación: desarrollamos un prototipo basado en los requerimientos.
- Evaluación: El cliente evalúa el prototipo, si da su conformidad, termina el proyecto. En caso contrario, incluimos los nuevos requerimientos solicitados por el cliente en la siguiente iteración.
Esta técnica fue presentada en la década del 90, tal vez como una de las
mejores metodologías a seguir para la creación de productos software.
Puede considerarse como un modelo pleno a seguir, como así también una
alternativa dentro de los modelos anteriores.
Al igual que la filosofía del paradigma de la programación orientada a
objetos, en esta metodología cada funcionalidad, o requerimiento solicitado por
el usuario, es considerado un objeto. Los objetos están representados por un
conjunto de propiedades, a los cuales denominamos atributos, por otra
parte, al comportamiento que tendrán estos objetos los denominamos métodos.
Vemos que tanto la filosofía de esta metodología, los
términos utilizados en ella y sus fines, coinciden con la idea de obtener un
concepto de objeto sobre casos de la vida real.
La característica principal de este
modelo es la abstracción de los requerimientos de usuario, por lo que
este modelo es mucho más flexible que los restantes, que son rígidos en
requerimientos y definición, soportando mejor la incertidumbre que los anteriores,
aunque sin garantizar la ausencia de riesgos. La abstracción es lo que nos permite
analizar y desarrollar las características esenciales de un objeto
(requerimiento), despreocupándonos de las menos relevantes.
Favorece la reducción de la
complejidad del problema que deseamos abordar y permite el perfeccionamiento
del producto.
Es necesario Establecer una metodología
para el desarrollo de un software, de la misma forma que se debe seleccionar un
modelo de ciclo de vida de software, y
con ellos aceptamos todos sus beneficios y desventajas que incluye. EL modelo
que escojamos debe adaptarse al proyecto que
se desarrolla. Debemos analizar para guiarnos en nuestra elección, la
complejidad del problema, el tiempo que disponemos para hacer la entrega final,
o si el usuario o cliente desea entregas parciales, la comunicación que existe
entre el equipo de desarrollo y el usuario. Además de la incertidumbre sobre si
los requerimientos dados por el usuario son correctos y completos.
Los diferentes modelos ofrecen características
diferentes:
Lineal. Debido a su sencillez y poca
complejidad, este modelo la mejor opción para el desarrollo de programas
pequeños.
En cascada Puro. Para usar este modelo
es necesario que conozcamos los requerimientos iniciales del proyecto.
En “V”. Gracias a su estructura este
modelo nos ofrece un buen soporte para realizar las correcciones necesarias al
terminar el proyecto.
Tipo Sashimi. Este modelo ofrece la
ventaja respecto a las etapas que se encuentran entrelazadas, sin embrago puede
generan contratiempo cuando se necesita definir el inicio y el fin de una
etapa.
Casaca con sub proyectos. En este
modelo cada etapa se encuentra divididas en sub etapas independientes y pueden desarrollarse
de manera paralela minimizando el tiempo de desarrollo.
Iterativo. Es un modelo que resulta
muy beneficioso si el cliente necesita observar ala evolución del software
debido a que en el proceso se presentan versiones mejoradas a la anterior.
Por Prototipos. Cuando no se conocen
exactamente los requerimientos, se realizan prototipos antes de presentar un
producto final, y comprobar si las funcionalidades probadas en los prototipos responderán
correctamente.
Evolutivo. En este modelo se tiene en
cuenta la variabilidad de los
requerimientos, entonces se realiza un proyecto y se evalúa con las nuevas
necesidades, y se adapta a estas en cada revisión que se realice.
Incremental. Este modelo se basa en el
ciclo de vida en cascada de manera repetida, y en cada ciclo cumplido se
integra una nueva funcionalidad a la versión dependiendo de las necesidades.
En espiral. El ciclo se repite las veces que sea necesario hasta que el cliente o
usuario obtiene la satisfacción de sus necesidades, momento en el cual nos
retiramos del espiral.
Orientado a
objetos. Este modelo es muy versátil y puede ser aplicado para proyectos pequeños
o grandes, o en conjunto con otro modelo.
Webgrafia
Webgrafia
http://www.alegsa.com.ar/Dic/software.php
www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html
img.redusers.com/imagenes/libros/lpcu097/capitulogratis.pdf
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/Capitulo%20I/problemas.htm
No hay comentarios:
Publicar un comentario