˜
 


 
En la actualidad para muchas organizaciones, los sistemas de información basados
en computadoras son el corazón de las actividades cotidianas y objeto de gran
consideración en la toma de decisiones, las empresas consideran
con mucho cuidados las capacidades de
sus sistemas de informacióncuando deciden ingresar o no en nuevos mercados o
cuando planean la respuesta que darán a la competencia.
Al establecer los sistemas de información basados en computadoras deben tener la
certeza de que se logren dos objetivos principales: que sea unsistema correcto y
que este correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos
será completamente útil para la gerencia uorganización.
Si los dispositivos de un sistema de información no se adaptan a
su población de clientes, no lograra sus objetivos potenciales. A mismo tiempo,
aun cuando se identifiquen precisamente las necesidades del usuario, un sistema
de información va tener un valor único si funciona en forma adecuada.
Los informes y las salidas producidas por el sistema deben ser precisos, confiables
y completos. La función del Análisis puede ser dar soporte a las actividades de
un negocio, o desarrollar un producto que pueda venderse para generar beneficios.
Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra
un conjunto de actividades, una de las cuales es la estimación, estimar es echar un
vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.
Aunque la estimación, es más un arte que una Ciencia, es una
actividad importante que no debe llevarse a cabo de forma descuidada.
Existen técnicasútiles para la estimación de costes de tiempo. Y dado que la
estimación es la base de todas las demás actividades
de planificación del proyecto y sirve como guía para
una buena Ingeniería Sistemas y Software.
Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en
el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El
Tamaño del proyecto es otro factor importante que puede afectar la precisión de
las estimaciones.
A medida que el tamaño aumenta, crece rápidamente la interdependencia
entre varios elementos del Software. La disponibilidad de información Histórica es
otro elemento que determina el riesgo de la estimación.
˜
  
   

El ciclo de vida de un sistema de información es un enfoque por fases del análisis
y diseño que sostiene que los sistemas son desarrollados de mejormanera mediante
el uso de un ciclo especifico de actividades del analista y del usuario.

c/

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.
˜
  

   
El método de ciclo de vida para el desarrollo de sistemas es el conjunto de
actividades que los analistas, diseñadores y usuarios realizan para desarrollar e
implantar un sistema de información. El método del ciclo de vida para el
desarrollo de sistemas consta de 6 fases:
 
   La solicitud para recibir ayuda de un sistema de
información puede originarse por varias razones: sin importar cuales sean estas, el
proceso se inicia siempre con la petición de una persona.
 

    El aspecto fundamental del
análisis de sistemas es comprender todas las facetas importantes de la parte de la
empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados
y administradores, deben estudiar losprocesos de una empresa para dar respuesta
a las siguientes preguntas clave:
¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?
    El diseño de un sistema de información produce los
detalles que establecen la forma en la que el sistema cumplirá con los
requerimientos identificados durante la fase de análisis. Los especialistas en
sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste
con la del desarrollo del software, a la que denominan diseño físico.
   Los encargados de desarrollar software pueden
instalar software comprobando a terceros o escribir programasdiseñados a la
medida del solicitante. La elección depende del costo de cada alternativa, del
tiempo disponible para escribir el software y de la disponibilidad de los
programadores.
Por lo general, los programadores que trabajan en las grandes organizaciones
pertenecen a un grupo permanente de profesionales.

/

|
   : Durante la prueba de sistemas, el sistema se emplea de
manera experimental para asegurarse de que el software no tenga fallas,
es decir, que funciona de acuerdo con las especificaciones y en la forma en que los
usuarios esperan que lo haga.
Se alimentan como entradas conjunto de datos de prueba para su procesamiento y
después se examinan los resultados.
! " 
# 

 La implantación es el proceso de verificar e instalar
nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos
los archivos de datos necesarios para utilizarla. Una vez instaladas,
las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones
y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con
el paso de las semanas y los meses.
Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones.
La evaluación de un sistema se lleva a cabo para identificar puntosdébiles y
fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes
dimensiones:
$% 

"
  Valoración de la forma en que funciona el sistema,
incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos
de información, confiabilidad global y nivel de utilización.
$ "
  &
  Identificación y medición de los beneficios para la
organización en áreas tales como finanzas, eficiencia operacional e impacto
competitivo. También se incluye el impacto sobre el flujo de información externo e
interno.
$'"        evaluación de las actividades de directivos y
administradores dentro de la organización así como de los usuarios finales.
$ "  La evaluación de proceso de desarrollo de acuerdo
con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan
con presupuestos y estándares, y otros criterios de administración de proyectos.
También se incluye la valoración de los métodos yherramientas utilizados en el
desarrollo.
() "   


 
Muchos especialistas en sistemas de información reconocen la dificultad de
comprender de manera completa sistemas grandes y complejos. El método de
desarrollo del análisis estructurado tiene como finalidad superar esta dificultad
por medio de:
1). La división del sistema en componentes
2). La construcción de un modelo del sistema.

[/

El análisis estructurado se concentra en especificar lo que se requiere que haga el
sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo
que hará el sistema) separados de los componentes físicos ( computadora,
terminales, sistemas de almacenamiento, etc.). Después de esto se puede
desarrollar un diseño físico eficiente para la situación donde será utilizado.
El análisis estructurado es un método para el análisis de sistemas manuales o
automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos
o para efectuar modificaciones a los ya existentes. Éste análisis permite al
analista conocer un sistema o proceso en una forma lógica y manejable al mismo
tiempo que proporciona la base para asegurar que no se omite ningún detalle
pertinente.
˜ "
*+ 
 Iconos y convenciones para identificar y describir los
componentes de un sistema junto con las relaciones entre estos componentes.


    descripción de todos los datos usados en el sistema. Puede
ser manual o automatizado.

 "
"
#"
  declaraciones formales que usan
técnicas y lenguajes que permiten a los analistas describir actividades importantes
que forman parte del sistema.
,  estándares para describir y documentar el sistema en forma correcta y
completa.
 %


 
El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis
Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de
especificaciones del software.
El objetivo del Diseño Estructurado es programas formados por
módulos independientes unos de otros desde el punto de vista funcional.
La herramienta fundamental del Diseño Estructurado es el diagrama estructurado
que es de naturaleza gráfica y evitan cualquier referencia relacionada con
el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas
(que es la tarea de los diagramas de flujo).
Los Diagramas Estructurados describen la interacción entre módulos
independientes junto con los datos que un módulo pasa a otro cuando interacciona
con él.
-  
. 

r/

Estudia el empleo de los datos para llevar a cabo procesos específicos de
la empresa dentro del ámbito de una investigación de sistemas usa los diagrama
de flujos de datos y los diccionarios de datos.
£  
Las herramientas muestran todas las características esenciales del sistema y la
forma en que se ajustan entre si, como es muy difícil entender todo un proceso de
la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes
esenciales de un sistema, junto con sus acciones.
  
. 
Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual
se desarrollan otros componentes.
El modelo original se detalla en diagramas de bajo nivel que muestran
características adicionales del sistema. Cada proceso puede desglosarse en
diagramas de flujos de datos cada vez más detallados. Repitiéndose esta secuencia
hasta que se obtienen suficientes detalles para que el analista comprenda la parte
del sistema que se encuentra bajo investigación.
El diagrama físico de datos da un panorama del sistema en uso, dependiente de la
implantación, mostrando cuales tareas se hacen y como son hechas.
Incluyen nombres de personas, nombres o números de formato y documento,
nombres de departamentos, archivos maestro y de transacciones, equipo y
dispositivos utilizados, ubicaciones, nombres de procedimientos.
El diagrama lógico de datos da un panorama del sistema, pero a diferencia del
físico es independiente de la implantación, que se centra en el flujo de datos entre
los procesos, sin considerar los dispositivos específicos y la localización de
los almacenes de datos o personas en el sistema. Sin indicarse las características
físicas.
/
 son cuatro símbolos, que fueron desarrollados y promovidos la mismo
tiempo por dos organizaciones: Yourdon y Gane y Sarson.
0
.  son movimientos de datos en una determinada dirección, desde un
origen hasta un destino. Es un paquete de datos.
()" "  
La construcción de prototipos representa una estrategia de desarrollo, cuando no
es posible determinar todos los requerimientos del usuario. Es por ello que incluye
el desarrollo interactivo o en continua evolución, donde el usuario participa de
forma directa en el proceso.
Este método contiene condiciones únicas de aplicación, en donde los encargados
del desarrollo tienen poca experiencia o información, o donde los costos
y riesgos de que se cometa un error pueden ser altos.

/

Así mismo este método resulta útil para probar la facilidad del sistema e identificar
los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso
de una aplicación. El método del prototipo de sistemas consta de 5 etapas:
 


 

 La determinación de los
requerimientos de una aplicación es tan importante para el mÄtodo de desarrollo
de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis
estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario
deben de trabajar juntos para identificar los requerimientos conocidos que tienen
que satisfacer.
 
  . Es fácil comenzar el procesos de
construcción del prototipo con el desarrollo de un plan general que permita a los
usuarios conocer lo que se espera de ellas y del proceso de desarrollo. Un
cronograma para el inicio y el fin de la primera interacción es de gran ayuda. En el
desarrollo del prototipo se preparan los siguientes componentes:
a). El lenguaje para el dialogo o conversación entre el usuario y el sistema.
b). Pantallas y formatos para la entrada de datos.
c). Módulos esenciales de procesamiento.
d). Salida del sistema
1  &
" " Es responsabilidad del usuario trabajar con el
prototipo y evaluar sus características y operación. La experiencia del sistema bajo
condiciones reales permite obtener la familiaridad indispensable para determinar
los cambios o mejoras que sean necesarios, así como las características inadecuadas
,  " " Durante la evaluación los analistas de sistemas desean
capturar información sobre los que les gusta y lo que les desagrada a los usuarios.
Los cambios al prototipo son planificados con los usuarios antes de llevarlos a
cabo, sin embargo es el analista responsable de tales modificaciones.
|,"
"
 

 
   El proceso antes descrito
se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de
acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las
características necesarias.
2

El término ciclo de vida del software describe el desarrollo de software, desde la

fase inicial hasta la fase final. El propósito de este programa es definir las distintas
fases intermedias que se requieren para validar el desarrollo de la aplicación, es
decir, para garantizar que el software cumpla los requisitos para la aplicación y
verificación de los procedimientos de desarrollo: se asegura de que los métodos
utilizados son apropiados.
Ñ/

 Estos programas se originan en el hecho de que es muy costoso rectificar los
errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida
permite que los errores se detecten lo antes posible y por lo tanto, permite a los
desarrolladores concentrarse en la calidad del software, en los plazos de
implementación y en los costos asociados.

Modelos de ciclo de vida:

Para facilitar una metodología común entre el cliente y la compañía de software,

los modelos de ciclo de vida se han actualizado para reflejar las etapas de
desarrollo involucradas y la documentación requerida, de manera que cada etapa
se valide antes de continuar con la siguiente etapa.

' ˜
 de v da L ea

' ˜
 de v da e
as
ada  bás

' ˜
 de v da e V
' ˜
 de v da t  sash 
' ˜
 de v da  etad a bjets

' ˜
 de v da de tt s.


' ˜
 de v da e es a.
˜
     ' ˜
 de v da teat v y
e
ete.



 
' ˜
 de Desa Rá d de A
a
es RAD.
' ˜
 de v da de Métd de Desa de S steas D á
 DSDM.

' ˜
 de v da de P
es U 
ad UP.
 
' ˜
 de v da de P
es U 
ad Ra
a RUP.
' ˜
 de v da de P aa

 Extea XP.

†/

 × ˜
  

Etapas de ciclo de vida lineal de una aplicación:

%2" 
  

Esta etapa tiene como objetivo la consecución de un primer documento en que

queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del
sistema a desarrollar (qué, y no cómo, se va a desarrollar).

Dado que normalmente se trata de necesidades del cliente para el que se creará
la aplicación, el documento resultante suele tener como origen una serie de
entrevistas cliente-proveedor situadas en el contexto de una relación comercial,
siendo que debe ser comprendido por ambas.

%"




Ahora se trata de formalizar los requerimientos; el documento obtenido en la

etapa anterior se tomará como punto de partida para esta fase. Su contenido es
aún insuficiente y lleno de imprecisiones que será necesario completar y
depurar.

Por medio de esta etapa se obtendrá un nuevo documento que definirá con más
precisión el sistema requerido por el cliente (el empleo de los casos de uso, ~


, de Jacobson es una muy buena elección para llevar a cabo la especificación
del sistema).

l/

-  

Es necesario determinar qué elementos intervienen en el sistema a desarrollar,

así como su estructura, relaciones, evolución en el tiempo, detalle de sus
funcionalidades,que van a dar una descripción clara de qué sistema vamos a
construir, qué funcionalidades va a aportar y qué comportamiento va a tener.
Para ello se enfocará el sistema desde tres puntos de vista relacionados pero
diferentes:

‡ Funcional.

‡ Estático.

‡ Dinámico.

 

Tras la etapa anterior ya se tiene claro qué debe hacer el sistema; ahora tenemos
que determinar cómo va a hacerlo (¿cómo debe ser construido el sistema?; aquí
se definirán en detalle entidades y relaciones de las bases de datos, se pasará de
casos de uso esenciales a su definición como casos expandidos reales, se
seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a
utilizar en su caso, librerías, configuraciones hardware, redes, etc.).
 " 


Llegado este punto se empieza a codificar algoritmos y estructuras de datos,

definidos en las etapas anteriores, en el correspondiente lenguaje de
programación y/o para un determinado sistema gestor de bases de datos.

 

El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado

correctamente, sin errores de diseño y/o programación. Es conveniente que sean
planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de
integración del sistema (según sea la naturaleza del proyecto en cuestión se
podrán tener en cuenta pruebas adicionales).

3  


Esta etapa tiene como objetivo la verificación de que el sistema desarrollado

cumple con los requisitos expresados inicialmente por el cliente y que han dado
lugar al presente proyecto (para esta fase también es interesante contar con los ~


]/


, generados a través de las correspondientes fases previas, que servirán de
guía para la verificación de que el sistema cumple con lo descrito por estos).

(  #



Finalmente la aplicación resultante se encuentra ya en fase de producción (en

funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido
creada). A partir de este momento se entra en la etapa de mantenimiento, que
supondrá ya pequeñas operaciones tanto de corrección como de mejora de la
aplicación, así como otras de mayor importancia,
fruto de la propia evolución.

× ˜
  






El ciclo de vida básico de un software consta de los siguientes procedimientos:

V 
     definir el resultado del proyecto y su papel en la

estrategia global.

V
              recopilar, examinar y formular los

requisitos del cliente y examinar cualquier restricción que se pueda aplicar.

V   requisitos generales de la arquitectura de la aplicación.

V   definición precisa de cada subconjunto de la aplicación.

‡
  
    
  es la implementación de un

lenguaje de programación para crear las funciones definidas durante la etapa de
diseño.

V    prueba individual de cada subconjunto de la aplicación para

garantizar que se implementaron de acuerdo con las especificaciones.

V 
  para garantizar que los diferentes módulos se integren con la

aplicación. Éste es el propósito de la prueba de integración que está
cuidadosamente documentada.

V    
  para garantizar que el software cumple con las
especificaciones originales.

c /

V 
 
  sirve para documentar información necesaria para los usuarios
del software y para desarrollos futuros.

V 
 

V     para todos los procedimientos correctivos (mantenimiento

correctivo) y las actualizaciones secundarias del software (mantenimiento
continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de

una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el
cliente y el equipo de desarrolladores.

× ˜
  3
El modelo de ciclo de vida V proviene del principio que establece que los
procedimientos utilizados para probar si la aplicación cumple las especificaciones
ya deben haberse creado en la fase de diseño. 

cc /

 × ˜
   

Según el modelo en cascada puro una fase solo puede empezar cuando ha
terminado la anterior. En este caso sin embargo, se permite un solapamiento entre
fases. Por ejemplo, sin tener terminado del todo el diseño se comienza a
implementar. El nombre ``sashimi'' deriva del modo del estilo de presentación de
rodajas de pescado crudo en Japón. Una ventaja de este modelo es que no necesita
generar tanta documentación como el ciclo de vida en cascada puro debido a la
continuidad del mismo personal entre fases. Los problemas planteados son: 

× Es aún más difícil controlar el progreso del proyecto debido a que los finales
de fase ya no son un punto de referencia claro.
× Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir
inconsistencias.
La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo
de tecnología y el tipo de ciclo de vida. El diseño arquitectónico es el de alto nivel,
el detallado el de bajo nivel. En la figura se ha representado la estructura del ciclo
de vida sashimi.

Ciclo de vida sashimi

× ˜
     


Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida
pensado para la orientación a objetos y posiblemente el más seguido. Un proyecto
se divide en las fases:

1. Planificación del negocio

c /

 2. Construcción: Es la más importante y se divide a su vez en otras cinco
actividades
ô Planificación

ô Investigación

ô Especificación

ô Implementación

ô Revisión

3. Entrega
La primera y la tercera fase son independientes de la metodología de desarrollo
orientado a objetos. Además de las tres fases, existen dos periodos:

1. Crecimiento: Es el tiempo durante el cual se construye el sistema

2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se
planifica igual que el periodo anterior, es decir, con las fases de
Planificación del negocio, Construcción y Entrega.
Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una
puede estar en una fase diferente en un momento cualquiera. La ventaja es que
permite un desarrollo solapado e iterativo. En la figura se muestra un esquema de
este tipo de ciclo de vida.

ô ()
 

c[ /

 × ˜
  

Pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido
en poco tiempo, usando los programas adecuados y no se debe utilizar mucho
dinero pues a partir de que este sea aprobado nosotros podemos iniciar el
verdadero desarrollo del software.

El diseño rápido se centra en una representación de aquellos aspectos del software

que serán visibles para el cliente o el usuario final. Este diseño conduce a la
construcción de un prototipo, el cual es evaluado por el cliente para una
retroalimentación; gracias a ésta se refinan los requisitos del software que se
desarrollará. La interación ocurre cuando el prototipo se ajusta para satisfacer las
necesidades del cliente. Esto permite que al mismo tiempo el desarrollador
entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo

ñ

§ Plan rápido
§ Modelado, diseño rápido
§ Construcción del Prototipo
§ Desarrollo, entrega y retroalimentación
§ Comunicación

· 

Este modelo es útil cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida.

También ofrece un mejor enfoque cuando el responsable del desarrollo del

software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debería tomar la interacción humano-
máquina.

cr /

La construcción de prototipos se puede utilizar como un modelo del proceso
independiente, se emplea más comúnmente como una técnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos del proceso
expuestos. Sin importar la forma en que éste se aplique, el paradigma de
construcción de prototipos ayuda al desarrollador de software y al cliente a
entender de mejor manera cuál será el resultado de la construcción cuando los
requisitos estén satisfechos. De esta manera, este ciclo de vida en particular,
involucra al cliente más profundamente para adquirir el producto.


   

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al

sistema final. A causa de la intención de crear un prototipo de forma rápida, se
suelen desatender aspectos importantes, tales como la calidad y el mantenimiento
a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez
que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre
reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo
convertiría en un prototipo evolutivo, pero partiendo de un estado poco
recomendado.

En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar

algunas decisiones de implementación poco convenientes (por ejemplo, elegir un
lenguaje de programación incorrecto porque proporcione un desarrollo más
rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que
le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas
elecciones pasen a formar parte del sistema final.

× ˜
   


Definido por primera vez por Barry Boehm en 1988. 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 priori, sino que las
siguientes se eligen en función del análisis de riesgo, comenzando por el bucle
interior.

ñ ~
 


  ~



~

½' .  Que necesidad debe cubrir el producto.

c
/

-    Las diferentes formas de conseguir los objetivos de forma exitosa,
desde diferentes puntos de vista como pueden ser:
1. Características: experiencia del personal, requisitos a cumplir, etc.
2. Formas de gestión del sistema.
3. Riesgo asumido con cada alternativa.
  #3 
 Programar y probar el software.
¦


~  


~  







   ~ 



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:
1. -
  Indica el avance del proyecto del software dentro de un ciclo.
2. ,   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.
˜
· 
Para cada ciclo habrá cuatro actividades:

   .  . 

cÑ /

 × Fijar también los productos definidos a obtener: requerimientos,
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 o previa.
-   
Se refiere a analizar los riesgos
  4 
#   5" 
× 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.
  

× Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos
con las fases siguientes y planificamos la próxima actividad.
3 . 
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.

c† /

 . 
× Genera mucho tiempo en el desarrollo del sistema
× Modelo costoso
× Requiere experiencia en la identificación de riesgos

× ˜
   

 


Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de
software, creado en respuesta a las debilidades del modelo tradicional de cascada.
Para apoyar el desarrollo de proyectos por medio de este modelo se han creado
frameworks (entornos de trabajo), de los cuales los dos más famosos son el
Rational Unified Process y el Dynamic Systems Development Method. El
desarrollo incremental e iterativo es también una parte esencial de un tipo de
programación conocido como Extreme Programming y los demás frameworks de
desarrollo rápido de software.
˜
 

El proceso en sí mismo consiste de:

× Etapa de inicialización
× Etapa de iteración
× Lista de control de proyecto
% "  
 &


Se crea una versión del sistema. La meta de esta etapa es crear un producto con el
que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe
ofrecer una muestra de los aspectos claves del problema y proveer una solución lo
suficientemente simple para ser comprendida e implementada fácilmente. Para
guiar el proceso de iteración, una lista de control de proyecto se crea, y esta 

 


~ 
 

   
 ~



 


  ~
    
~
 ~ 






 
 



 
 ~
 




ñ 

  





  


  
~ 








% "  


cl /

Esta etapa involucra el rediseño e implementación de una tarea de la lista de
control de proyecto, y el análisis de la versión más reciente del sistema. La meta del
diseño e implementación de cualquier iteración es ser simple, directa y modular,
para poder soportar el rediseño de la etapa o como una tarea añadida a la lista de
control de proyecto. El código puede, en ciertos casos, representar la mayor fuente
de documentación del sistema. El análisis de una iteración se basa en la
retroalimentación del usuario y en el análisis de las funcionalidades disponibles
del programa. Involucra el análisis de la estructura, modularidad, usabilidad,
confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del
proyecto se modifica bajo la luz de los resultados del análisis.

Las guías primarias que guían la implementación y el análisis incluyen:

× Cualquier dificultad en el diseño, codificación y prueba de una modificación

debería apuntar a la necesidad de rediseñar o recodificar.
× Las modificaciones deben ajustarse fácilmente a los módulos fáciles de
encontrar y a los aislados. Si no es así, entonces se requiere algún grado de
rediseño.
× Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si
dicha modificación no ocurre rápidamente, se debe aplicar algo de rediseño.
× Las modificaciones deben ser más fáciles de hacer conforme avanzan las
iteraciones. Si no es así, hay un problema primordial usualmente
encontrado en un diseño débil o en la proliferación excesiva de parches al
sistema.
× Los parches normalmente deben permanecer solo por una o dos iteraciones.
Se hacen necesarios para evitar el rediseño durante una fase de
implementación.
× La implementación existente debe ser analizada frecuentemente para
determinar que tan bien se ajusta a las metas del proyecto.
× Las facilidades para analizar el programa deben ser utilizadas cada vez para
ayudar en el análisis de implementaciones parciales.
× La opinión del usuario debe ser solicitada y analizada para indicar
deficiencias en la implementación referida por él.

c] /

     

× Requiere de un cliente involucrado durante todo el curso del proyecto. Hay

clientes que simplemente no estarán dispuestos a invertir el tiempo
necesario.
× Infunde responsabilidad en el equipo de desarrollo al trabajar directamente
con el cliente, requiriendo de profesionales sobre el promedio.
× Sufre fuertes penalizaciones en proyectos en los cuales los requerimientos
están previamente definidos, o para proyectos "todo/nada" en los cuales se
requiere que se completen en un 100% el producto para ser implementado
(por ejemplo, licitaciones)

ô ()" 
El desarrollo de software de " ) " " (también denominado å 
 


 o abreviado ) reduce el tiempo del ciclo de vida del software (por lo
tanto, acelera el desarrollo) al desarrollar, en primera instancia, una versión
prototipo y después integrar la funcionalidad de manera iterativa para satisfacer
los requisitos del cliente y controlar todo el ciclo de desarrollo.

Por lo tanto, en el año 2001, 17 personas redactaron el manifiesto ágil, en el que

expresaron los siguientes puntos principales:

× individuos e interacciones en lugar de procesos y herramientas

× desarrollo de software en lugar de documentación exhaustiva
× trabajo con el cliente en lugar de negociaciones contractuales
× apertura para los cambios en lugar de cumplimiento de planes poco
flexibles
Con la ayuda de los métodos rápidos, el cliente tiene control total de su proyecto y
logra una rápida implementación del software. De esta forma, se permite al
usuario involucrarse desde el inicio del proyecto.

× ˜
 ! 


 !



/

El  "  "

 (*acrónimo en inglés de 





 
) definido por James Martin a principios de la década de 1980, consiste
en un ciclo de desarrollo corto basado en tres fases (Requisitos, Diseño y
Construcción) con un plazo de entrega ideal de 90 a 120 días como máximo.

El método comprende el desarrollo iterativo, la construcción de prototipos y el uso

de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el
desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad
y la rapidez de ejecución.
Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces
gráficas de usuario tales como Glade, o entornos de desarrollo integrado
completos. Algunas de las plataformas más conocidas son Visual Studio, Delphi,
Foxpro , Anjuta o Velneo.


× ˜
  "  
 " 


El *( (å   

  
¦




 ) se desarrolló para completar lo
que le faltaba al método RAD al proporcionar una estructura que tome en cuenta el
ciclo de desarrollo completo. 

Las características principales del método DSDM son las siguientes:

× Participación del usuario

× Desarrollo iterativo y creciente
× Frecuencia de entrega mejorada
× Pruebas integradas en cada fase
× La aceptación de los productos entregados depende directamente del
cumplimiento de los requisitos.


× ˜
 
#
#


El método "

 
 (‰ ) es un proceso de desarrollo iterativo y creciente.
Esto significa que el proyecto se divide en fases más cortas y que se envía una
nueva versión gradual al final de cada fase.

c/

Este enfoque está basado en el modelo UML para la descripción de la arquitectura
del software (funcional, de aplicación y física) y para el desarrollo del caso del
usuario. Dicho modelo describe los requisitos y las demandas del usuario.

˜
$


  
  

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto

de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada
una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo
consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como
resultado un


 del producto desarrollado que añade o mejora las
funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de
requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen
incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una
de ellas varía a lo largo del proyecto.

   "



En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos
funcionales y para definir los contenidos de las iteraciones. La idea es que cada
iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el
camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el
proceso dirigido por casos de uso es el rup. Nota: en UP se está     "

 #  de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona
el tema.

˜   


 

El Proceso Unificado asume que no existe un modelo único que cubra todos los
aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que
definen la arquitectura de software de un sistema. La analogía con la construcción
es clara, cuando construyes un edificio existen diversos planos que incluyen los
distintos servicios del mismo: electricidad, fontanería, etc.

%
 

/

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar
los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada
iteración, en especial los de la fase de Elaboración, deben ser seleccionados en un
orden que asegure que los riesgos principales son considerados primero.

× ˜
 
#
!
 !#


,1 (  
 ~

  
) es un método de desarrollo iterativo promovido
por la compañía *
¦ 
, que fue comprada por IBM.

El método RUP especifica, principalmente, la constitución del equipo y las escalas

de tiempo, así como un número de modelos de documento.




$


× Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,

cuándo y cómo)
× Pretende implementar las mejores prácticas en Ingeniería de Software
× Desarrollo iterativo
× Administración de requisitos
× Uso de arquitectura basada en componentes
× Control de cambios
× Modelado visual del software
× Verificación de la calidad del software

 

El RUP está basado en 6 principios clave que son los siguientes:

- "   "
 El proceso deberá adaptarse a las necesidades del cliente ya
que es muy importante interactuar con él. 

%
   "    Los requisitos de los diversos participantes pueden ser
diferentes, contradictorios o disputarse recursos limitados. 

         Los proyectos se entregan, aunque sea de un

modo interno, en  "    . En cada iteración se analiza la opinión de los

[/

inversores, la estabilidad y calidad del producto, y se refina la dirección del
proyecto así como también los riesgos involucrados

˜ 
  
" El desarrollo de software no lo hace una única
persona sino múltiples equipos. Debe haber una comunicación fluida para
coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

%      

 Este principio dominante motiva el uso de

conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de
referencia (frameworks). 

%
   
   El control de calidad no debe realizarse al final de cada

iteración, sino en  los aspectos de la producción. El aseguramiento de la
calidad forma parte del proceso de desarrollo y no de un grupo independiente.

˜
 

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el proyecto y en las que se hace un mayor o
menor hincapié en las distintas actividades

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto,
la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea
Base) de la arquitectura.

    
 las iteraciones hacen mayor énfasis en actividades de
modelado del negocio y de requisitos.

ñ  
  las iteraciones se orientan al desarrollo de la baseline de

la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la
baseline de la arquitectura.

ñ  
 

 , se lleva a cabo la construcción del producto por medio
de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y

diseño y se procede a su implementación y pruebas. Se realiza una pequeña
cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la
implementación de la nueva versión del producto.

r/

ñ   
 se pretende garantizar que se tiene un producto preparado
para su entrega a la comunidad de usuarios.

× ˜
 
 ñ %


El método XP (  
 

) define un conjunto de prácticas óptimas para
el desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el
centro del proceso de desarrollo, manteniendo una cercana relación con dicho
cliente.

La Programación extrema se basa en los siguientes conceptos:

× Los equipos de desarrollo trabajan directamente con el cliente durante ciclos

cortos de una o dos semanas como máximo.
× La entrega de las versiones del software ocurre muy temprano y en
intervalos muy cortos para maximizar la interacción con el usuario.
× Existe una fuerte colaboración entre el equipo de desarrollo mientras trabaja
en el código.
× El código se prueba y depura a lo largo del proceso de desarrollo.
× Existen indicadores que miden el progreso del proyecto para poder
actualizar el plan de desarrollo.

/