INTRODUCCION
En la introducción de este trabajo de investigación se describe el tema a investigar, el objeto de estudia, de manera sustancial, pero en forma clara y breve.
Al momento de dieñar un sistema,es necesario tomar en cuenta diferentes factores que influyen en el desarrollo y en el buen funcionamiento de este.
El ciclo de vida de un software es un enfoque por fases del análisis que sostiene a los
sistemas ,son desarrollados de mejor manera mediante el uso de un ciclo
especifico de actividades del analista y del usuario.
El software es la aplicación de un
enfoque sistemático.Según James Senn, existen tres
estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida
de desarrollo de sistemas, el método de desarrollo por análisis estructurado y
el método de construcción de prototipos de sistemas. Cada una de estas
estrategias tienen un uso amplio en cada una de los diversos tipos de empresas
que existen, y resultan efectivas si son aplicadas de manera adecuada .(1)
Marco Teorico
Metodología
Siguiendo una metodología en el desarrollo de software se busca
de unamanera sistemática, realizar, gestionar y administrar un proyecto de
forma talque se tengan altas probabilidades de éxito. Lo que se busca al
guiarse conuna metodología es projilidad, corrección, y control en cada etapa
deldesarrollo de un programa.La ingeniería de software requiere llevar a cabo
numerosas tareas,dentro de etapas como las siguientes:
Planificación: planeamiento detallado que guíe la gestión del
proyecto,temporal y económicamente.
Implementación: conjunto de actividades que componen la
realizacióndel producto.
Puesta en producción: el proyecto entra en etapa de definición,
donde espresentado al cliente, sabiendo que cumple los
requerimientossolicitados y funciona correctamente.(2)
En complemento a las tres etapas anteriormente citadas, existen
otras dos:
•Inicio: este es el nacimiento de la idea. Aquí se definen los
objetivos delproyecto y los recursos necesarios para su implementación. El
iniciodefine hacia donde queremos ir, no como queremos ir.
•Control en producción: control del producto, analizando como
elproducto difiere o no de los requerimientos originales e iniciando de ser
necesario las correcciones respectivas.Objetivos de cada etapa
•Expresión de necesidades: tiene como objetivo el armado de
undocumento que en el cual se reflejan los requerimientos yfuncionalidades que
ofrecerá el sistema al usuario.
•Especificaciones: se trata de la formalización de los
requerimientos, setoma como base el documento anterior.
•Análisis: se tiene una descripción clara del producto a
construir, quefuncionalidades aportara y que comportamiento tendrá.
•Diseño: definir relaciones y entidades de las bases de datos
yseleccionar el lenguaje de programación a utilizar.
•Implementación: se empiezan a codificar algoritmos y
estructuras dedatos en el lenguaje antes definido. En el caso de modelo de
ciclo devida Code&Fix, se empieza meramente por esta etapa, saltándose
lasetapas de especificaciones, análisis y diseño con la siguiente perdida
decontrol sobre la gestión del proyecto.
•Debugging: el objetivo de esta etapa es garantizar que el
programa nocontenga errores de diseño o codificación.
•Validación: esta etapa tiene como objetivo la verificación de
que elsistema desarrollado cumple con los requerimientos expresadosinicialmente
por el cliente y que han dado lugar al presente proyecto.
•Evolución: también conocida como Mantenimiento y evolución, se
leasigna el agregado de nuevas funcionalidades (evolución) y lacorrección de
errores que surgen (mantenimiento).(2)
Modelos de Ciclo de Vida
El ciclo de vida del software describe el desarrollo de
software, desde lafase inicial hasta la fase final. Su propósito es definir las
distintas fasesintermedias que se requieren para validar el desarrollo de la
aplicación, esdecir, para garantizar que el software cumpla los requisitos para
la aplicación yverificación de los procedimientos de desarrollo.Las principales
diferencias entre distintos modelos de ciclo de vida estándivididas en tres
grandes visiones:
-El alcance del ciclo de vida, que depende de hasta donde se
desee llegar con el proyecto.
-La cualidad y cantidad de las etapas en que se dividirá el
ciclo de vida.
-La estructura y la sucesión de las etapas, se existe
realimentación entreellas y si hay libertad de iterar(3)
Ciclo de vida lineal.
Es el más sencillo de todos los modelos. Consiste en descomponer
laactividad global del proyecto en etapas separadas que son realizadas demanera
lineal, es decir, cada etapa se realiza una sola vez.
Con un ciclo devida lineal es muy fácil dividir las tareas, y preveer los tiempos (sumandolinealmente los de cada etapa).
Las actividades de cada una de las etapas mencionadas 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 derealimentación correctiva. Se requiere que se conozca desde el primer momento lo que va a ocurrir en cada una de las distintas etapas antes decomenzarla, minimizando asi las posibilidades de error durante la codificacion yreduciendo al minimo la necesidad de requerir informacion del cliente o delusuario.
Con un ciclo devida lineal es muy fácil dividir las tareas, y preveer los tiempos (sumandolinealmente los de cada etapa).
Las actividades de cada una de las etapas mencionadas 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 derealimentación correctiva. Se requiere que se conozca desde el primer momento lo que va a ocurrir en cada una de las distintas etapas antes decomenzarla, minimizando asi las posibilidades de error durante la codificacion yreduciendo al minimo la necesidad de requerir informacion del cliente o delusuario.
Fig 1. Ciclo de vida en línea.
Se destaca como ventaja la sencillez de su gestion y
administraciontanto economica como temporal, ya que se acomoda perfectamente a proyectos
internos de una empresa para programas muy pequeños de altas,bajas y
moficicaciones sobre un conjunto de datos. Tiene como desventaja que es muy
costoso retomar una etapa anterior al detectar una falla.Es válido tomar este
ciclo de vida cuando algún sector pequeño de unaempresa necesita llevar un
registro de datos acumulativos, sin necesidad derealizar procesos sobre ellos
más que una consulta simple, es decir,almacenamiento de datos
Ciclo de vida en cascada puro.
Este modelo de ciclo de vida fue propuesto por Winston Royce en
el año1970. Es un ciclo de vida que admite iteraciones, contrariamente a la
creenciade que es un ciclo de vida secuencial como el lineal. Después de cada
etapa serealiza una o varias revisiones para comprobar si se puede pasar a la
siguiente.Es un modelo rígido, poco flexible, y con muchas restricciones.
Fig 2. Ciclo de Vida en Cascada
La necesidad de conocer los requerimiento al principio del
proyecto esprimordial al elegir este modelo de ciclo de vida a pesar de
permitir iteraciones(3)
Modelo
De Desarrollo Incremental
Los riesgos asociados con el desarrollo de
sistemas largos y complejos son enormes. Una forma de reducir los riesgos es
construir sólo una parte del sistema, reservando otros aspectos para niveles
posteriores. El desarrollo incremental es el proceso de construcción siempre
incrementando subconjuntos de requerimientos del sistema. Típicamente, un
documento de requerimientos es escrito al capturar todos los requerimientos
para el sistema completo.
Note que el desarrollo incremental es 100%
compatible con el modelo cascada. El desarrollo incremental no demanda una
forma específica de observar el desarrollo de algún otro incremento. Así, el
modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo,
como se muestra en la figura.
El modelo de desarrollo incremental provee
algunos beneficios significativos para los proyectos:
·
Construir
un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
·
Al
ir desarrollando parte de las funcionalidades, es más fácil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.
·
Si
un error importante es realizado, sólo la última iteración necesita ser
descartada.
·
Reduciendo
el tiempo de desarrollo de un sistema (en este caso en incremento del sistema)
decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar
durante el desarrollo.
·
Si
un error importante es realizado, el incremento previo puede ser usado.
·
Los
errores de desarrollo realizados en un incremento, pueden ser arreglados antes
del comienzo del próximo incremento.
Modelo De Desarrollo Evolutivo
Como el modelo de desarrollo incremental, el
modelo de desarrollo evolutivo (algunas veces denominado como prototipado
evolutivo) construye una serie de grandes versiones sucesivas de un producto.
Sin embargo, mientras que la aproximación incremental presupone que el conjunto
completo de requerimientos es conocido al comenzar, el modelo evolutivo asume
que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos
son cuidadosamente examinados, y sólo esos que son bien comprendidos son
seleccionados para el primer incremento. Los desarrolladores construyen una
implementación parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los
usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en
esta retroalimentación, la especificación de requerimientos es actualizada, y
una segunda versión del producto es desarrollada y desplegada. El proceso se
repite indefinidamente.
Note que el desarrollo evolutivo es 100%
compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma
específica de observar el desarrollo de algún incremento. Así, el modelo
cascada puede ser usado para administrar cada esfuerzo de desarrollo.
Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.(4)
Modelo de Prototipado de Requerimientos.
El prototipado de requerimientos es la
creación de una implementación parcial de un sistema, para el propósito
explícito de aprender sobre los requerimientos del sistema. Un prototipo es
construido de una manera rápida tal como sea posible.
Esto es dado a los
usuarios, clientes o representantes de ellos, posibilitando que ellos
experimenten con el prototipo. Estos individuos luego proveen la retroalimentación
sobre lo que a ellos les gustó y no les gustó acerca del prototipo
proporcionado, quienes capturan en la documentación actual de la especificación
de requerimientos la información entregada por los usuarios para el desarrollo
del sistema real. El prototipado puede ser usado como parte de la fase de
requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos).(4)
El modelo espiral de los procesos software es
un modelo del ciclo de meta-vida.
En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno
completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo
ejecutado, puedes seguir estos cuatros pasos:
· Determinar qué quieres lograr.
· Determinar las rutas alternativas que puedes
tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados
finales, y seleccionar la mejor.
· Seguir la alternativa seleccionada en el paso
2.
· Establecer qué tienes terminado.
La dimensión radial en la figura refleja
costos acumulativos incurridos en el proyecto.
Observemos un escenario particular. Digamos
que en este proyecto, nosotros viajaremos a resolver un conjunto particular de
problemas del cliente. Durante el primer viaje alrededor de la espiral,
analizamos la situación y determinamos que los mayores riesgos son la interfaz
del usuario. Después de un cuidadoso análisis de las formas alternativas de
direccionar esto (por ejemplo, construir un sistema y esperar lo mejor,
escribir una especificación de requerimientos y esperar que el cliente lo
entienda, y construir un prototipo), determinamos que el mejor curso de acción
es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo
al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el
segundo viaje alrededor de la espiral.
Este tiempo decidimos que el mayor
riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer
sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas,
y decidimos que la mejor aproximación es construir un incremento del sistema
que satisfaga sólo los requerimientos mejor entendidos.
El modelo espiral captura algunos principios
básicos:
·
Decidir
qué problema se quiere resolver antes de viajar a resolverlo.
·
Examinar
tus múltiples alternativas de acción y elegir una de las más convenientes.
·
Evaluar
qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
·
No
ser tan ingenuo para pensar que el sistema que estás construyendo será
"EL" sistema que el cliente necesita, y
·
Conocer
(comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del
modelo cascada, ellos son completamente compatible.
Modelo Concurrente
Como el modelo espiral, el modelo concurrente
provee una meta-descripción del proceso software. Mientras que la contribución
primaria del modelo espiral es en realidad que esas actividades del software
ocurran repetidamente, la contribución del modelo concurrente es su capacidad
de describir las múltiples actividades del software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado
involucrado con las diversas actividades que ocurren en algún tiempo del
proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son usualmente
"líneas de base", cuando una mayoría de los requerimientos comienzan
a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al
diseño. Sin embargo, una vez que comienza el diseño, cambios a los
requerimientos son comunes y frecuentes (después de todo, los problemas reales
cambian, y nuestro entendimiento de los problemas desarrollados también).(4)
Resumen
Uno de los problemas actuales en el desarrollo de sistemas de software es la complejidad, cada vez más alta, de analizar y garantizar el comportamiento fiable de estos sistemas. Este proyecto está orientado al desarrollo de métodos, técnicas y herramientas para la construcción de software fiable y de calidad, incidiendo en la posibilidad real de su aplicación en los procesos de producción de la industria del software. Con este objetivo, la propuesta se centra en el uso "ágil" (lightweight) de los métodos formales en la Ingeniería del Software.
Esta aproximación se basa en la utilización parcial de formalismos a distintos niveles (lenguaje, modelado, análisis y composición), donde la idea fundamental es la de sacrificar el objetivo de lograr métodos generalistas que soporten todo el proceso de desarrollo de software, en beneficio del uso puntual de formalismos en determinadas etapas del ciclo de vida del software. Para ilustrar las posibilidades de este enfoque, muchas de las actividades del proyecto se desenvolverán fundamentalmente en el desarrollo de software basado en componentes.
El proyecto es una propuesta coordinada de los equipos de cuatro universidades, con experiencia previa en I dentro del campo de los métodos formales en la ingeniería del software y la programación declarativa multiparadigma.
Este proyecto no debe considerarse uno más en el campo de los métodos formales, sino una propuesta rigurosa para hacer factible la construcción de software fiable
Referencia Bibliográficas
1)Senn, James A Análisis de
Sistemas de Información[monografía en internet]. Segunda Edición. Editorial
McGrawHill. México . [citada 2011 Agosto 24]. Disponible desde:
2) James, Moitra, Deependra Ciclo de Vida del Software[monografía en internet]. [citada 2001 Abril 16].Disponible
desde:
3) José R. Álvarez y Manuel Arias Ciclo de Vida del Software[monografía en internet]. [citada 2002 Octubre 29].Disponible desde:
4)Ana S. Ciclo de Vida del Software[citada 2011 Noviembre 25]. [monografía
en internet]. Disponible desde:
