TEMA N 2

EL ANLISIS DE SISTEMAS Y LOS CICLOS DE VIDA

DE DESARROLLO DE SISTEMAS DE INFORMACIN














Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
18
TEMA N 2 EL ANLISIS DE SISTEMAS Y LOS CICLOS DE VIDA
DE DESARROLLO DE SISTEMAS DE INFORMACIN

2.1. Introduccin
Todo proyecto de ingeniera est ligado a la obtencin de un producto,
proceso o servicio que es necesario generar a travs de diversas
actividades las pueden agruparse en fases porque globalmente
contribuyen a obtener un producto intermedio, necesario para continuar
hacia el producto final y facilitar la gestin del proyecto. Al conjunto de
las fases empleadas se le denomina ciclo de vida.
Sin embargo, la forma de agrupar las actividades, los objetivos de cada
fase, los tipos de productos intermedios que se generan, etc. pueden ser
muy diferentes dependiendo del tipo de producto o proceso a generar y
de las tecnologas empleadas.
La complejidad de las relaciones entre las distintas actividades crece
exponencialmente con el tamao, con lo que rpidamente se hara
inabordable si no fuera por la tctica muy empleada de divide y
vencers. De esta forma la divisin de los proyectos en fases sucesivas
es un primer paso para la reduccin de su complejidad, tratndose de
escoger las partes de manera que sus relaciones entre s sean lo ms
simples posibles.
La definicin de un ciclo de vida facilita el control sobre los tiempos en
que es necesario aplicar recursos de todo tipo (personal, equipos,
suministros, etc.) al proyecto. Si el proyecto incluye subcontratacin de
partes a otras organizaciones, el control del trabajo subcontratado se
facilita en la medida en que esas partes encajen bien en la estructura de
las fases. El control de calidad tambin se ve facilitado si la separacin
entre fases se hace corresponder con puntos en los que sta deba
verificarse (mediante comprobaciones sobre los productos parciales
obtenidos).
De la misma forma, la prctica acumulada en el diseo de modelos de
ciclo de vida para situaciones muy diversas permite que nos beneficiemos
de la experiencia adquirida utilizando el enfoque que mejor se adapte a
los requerimientos de los usuarios.
2.2. Definiciones de anlisis de sistemas

Las siguientes definiciones de Anlisis y Diseo de Sistemas estn
enfocadas a un conjunto de elementos para realizar un objetivo
predefinido en el procesamiento de la informacin, las mismas estn
relacionadas con la forma de representar el flujo de informacin de una
entidad o empresa segn etapas definidas en una notacin.


Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
19
El Anlisis y Diseo de Sistemas es un conjunto de hechos,
principios y reglas clasificadas y dispuestas de manera ordenada
mostrando un plan lgico en la unin de las partes.
Dentro de las organizaciones, el Anlisis y Diseo de Sistemas se
refiere al proceso de examinar la situacin de una empresa con el
propsito de mejorarla con mtodos y procedimientos ms
adecuados, por consiguiente, es el proceso de clasificacin e
interpretacin de hechos, diagnstico de problemas y empleo de la
informacin para recomendar mejoras al sistema.

2.3. La necesidad del anlisis y diseo de sistemas

El anlisis y diseo de sistemas, tal como es ejecutado por los analistas
de sistemas, busca analizar sistemticamente el problema, las
especificaciones de entrada o flujo de datos, el proceso o transformacin
de los datos, el almacenamiento y la salida de informacin dentro del
contexto de una empresa o institucin. Adems el diseo y anlisis de
sistemas es usado para analizar, disear e implementar mejoras en el
funcionamiento de negocios que pueden ser logrados por medio del uso
de sistemas de informacin computarizados.

La instalacin de un sistema sin la planificacin adecuada lleva a
grandes frustraciones, y frecuentemente causa que el sistema deje de ser
usado. El anlisis y diseo de sistemas, contiene la estructura del
desarrollo de un sistema de informacin, gran parte del mismo involucra
el trabajo con los usuarios actuales y eventuales.

El anlisis y diseo de sistemas aporta en la estructura al anlisis y diseo
de sistemas de informacin, un costoso esfuerzo que de otra forma podra
haber sido hecho de modo casual. Puede ser visto como una serie de
procesos llevados a cabo sistemticamente para mejorar una organizacin
por medio del uso de sistemas de informacin computarizados.

2.4. Razones para iniciar un anlisis de sistemas
Los analistas de sistemas deben entender en primer lugar por qu se va a
realizar un trabajo de sistemas, donde es necesario tomar en cuenta los
siguientes puntos:
Necesidad de resolver un problema: Puede suceder que el actual
sistema no este funcionando como se esperaba entonces se acude
al analista de sistemas para que corrija esta anomala.
Nuevas necesidades: Esto ocurre cuando surgen nuevas
disposiciones en la organizacin. Puede tratarse de una nueva ley,
una prctica contable, una nueva prctica administrativa,
independientemente de la causa que de origen a la nueva
necesidad el analista de sistemas identificar las modificaciones o
adiciones que deben hacerse al sistema, con el propsito de que la
empresa pueda satisfacer dicha necesidad.
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
20
Implantacin de una nueva tecnologa: Puede ser el caso de
implantar una tcnica diferente por ejemplo: si se implementa un
lector de huella digital para el control de asistencia, lo ms
probable es que haya la necesidad de disear un nuevo
subsistema.
Mejoramiento general de los sistemas: El analista debe encontrar
un mecanismo para mejorar lo que se tiene.
2.5. Modelo para el procesamiento de anlisis

El Desarrollo de Sistemas de Informacin incluye la adopcin de una
metodologa (anlisis y diseo estructurado u orientado a objetos) o un
lenguaje de modelado unificado UML (estndar de modelado orientado a
objetos) para representar el funcionamiento de las actividades de una
empresa u organizacin. En la actualidad los estndares actuales de
modelado superaron al anlisis y diseo estructurado por ser muy simple
y de poco alcance, la experiencia con sistemas grandes y complejos
descubrieron las limitaciones de ese mtodo, particularmente cuando se
desarrollan sistemas con requerimientos inestables.

Un modelo es una abstraccin de la realidad, un modelo es un
anteproyecto o proyeccin del sistema. El modelado es una tcnica
aprobada en la Ingeniera para tener una vista previa del producto final.
Se debe modelar para entender mejor el problema que estamos
desarrollando.

Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
21
Ejemplo: Mostrar la interaccin de un cliente con un servicio de cajero
automtico, para efectuar un retiro.

Tabla N 1
Cliente Sistema Servicio de Cajeros
1. Inserta una tarjeta
bancaria en el lector
del CA.

2. Lee el cdigo de la
tarjeta y verifica que es
correcto

3 Pide el cdigo de PIN
(4 dgitos)

4 Ingresa el PIN
5 Enva Id. De tarjeta
y PIN

6 Verifica que el PIN
sea correcto
7- Mostrar seleccin de
tipo de cuenta

8- Elegir opcin: Retiro
9. Pedir cuenta y monto
10- Ingresa cuenta y
monto

11. Enva al SC el Id.
Tarjeta, PIN, cuenta y
monto

12 Contesta: Continuar
(OK) o No Continuar
13 Entrega el dinero
14 Imprime recibo
15 Devuelve la tarjeta I

Modelo representado en un flujo de datos

2.6. Responsabilidades del analista de sistemas
Los analistas de sistemas de informacin surgieron como respuesta a las
necesidades de mejorar el uso de los recursos informticos para satisfacer
los nuevos requisitos del proceso de informacin de las aplicaciones en las
empresas.
A pesar de las posibilidades tecnolgicas, la computadora debe su poder y
utilidad a las personas, siendo stas las que definen las necesidades que
deben cubrirse. Pero desafortunadamente siempre en cualquier
organizacin se encuentra un vaco entre los usuarios y los
programadores o tcnicos al momento de aplicar la tecnologa en la
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
22
solucin de problemas. Es aqu donde se ubica el lugar del analista,
comportndose como un puente en este vaco.
Los analistas de sistemas generalmente valoran la manera en que
funcionan los negocios examinando la entrada, el procesamiento de los
datos y la salida de resultados.
Un analista de sistemas, es una persona que comprende tanto las
necesidades de la empresa como la tecnologa informtica. Los analistas
de sistemas transforman las necesidades de informacin y de los usuarios
en soluciones tecnolgicas basadas en computadoras.

El analista de sistemas es el personaje clave en cualquier proyecto de
desarrollo de sistemas, es fcil ver que el analista debe poseer un amplio
rango de habilidades y cualidades puesto que ocupa un cargo superior
dentro de la institucin.

El analista es solucionador de problemas, es una persona que ve el
anlisis de los problemas como un reto y disfruta al encontrar soluciones
empleando herramientas, tcnicas y experiencia en anlisis, diseo,
programacin e implementacin para comprender mejor los
requerimientos de la organizacin y de los usuarios.

El analista debe ser comunicador y mediador capaz de relacionarse en
forma significativa con todo tipo de personas (gerentes, auditores,
contadores, personal de sistemas como diseadores y programadores
etc.) a travs de periodos extensos.

El analista de sistemas debe ser un individuo autodisciplinado y
automotivado capaz de manejar recursos del proyecto incluyendo a
personas (debe tener alto grado de moralidad).

Las responsabilidades de un analista cambian de una organizacin a otra;
a continuacin se mencionan solo algunas de las actividades ms
comunes asignadas a los analistas de sistemas:

- Anlisis de sistemas: en este caso su responsabilidad es conducir
estudios sobre los sistemas relevantes dentro de la organizacin, para
detectar hechos relevantes. Considerar que la parte ms importante es
reunir la informacin y determinar los requerimientos. En este punto, slo
el analista es responsable del anlisis de la informacin.

- Anlisis y diseo de sistemas: el analista tiene la responsabilidad
adicional de disear el nuevo sistema, desarrollando las especificaciones
de diseo, tomando como base el anlisis de los hechos previamente
recolectados.
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
23
- Anlisis, diseo y programacin: el analista cuando realiza esta
actividad conduce la investigacin, desarrolla el diseo del nuevo sistema
y describe el software necesario para implantar el diseo.

2.7. Usuarios

Los analistas emplean el trmino usuario final para referirse a las
personas vinculadas con los sistemas de informacin:

Los usuarios finales se clasifican en cuatro categoras:

Usuarios primarios: Interactan en forma directa con el sistema ya sea
con entradas, o recibiendo salidas de una terminal (usuarios finales).

Ejemplo: Usuarios operadores

Usuarios indirectos: Son aquellos que se benefician con los resultados o
reportes sin interactuar de manera directa con el hardware o software.

Ejemplo: Auditores, Encargados de cuentas

Usuarios gerentes: Son los que tienen responsabilidades administrativas
en los sistemas de aplicacin.

Ejemplo: Gerentes encargados de la toma de decisiones de una
institucin.

Usuarios responsables: Encargados del desarrollo de sistemas de
informacin y consecuentemente de las mejoras que deben tener estos.

Ejemplo: Analistas, desarrolladores, programadores.

2.8. El ciclo de vida del desarrollo de sistemas
El desarrollo de sistemas es un proceso formado por las etapas de anlisis
y diseo, ste inicia cuando en la organizacin se detecta que el sistema
necesita reformas.
El ciclo de vida de un sistema es el conjunto de actividades que los
analistas diseadores y usuarios realizan para desarrollar e implantar un
sistema de informacin. Cuando se realiza un anlisis se debe considerar
que todas las actividades que en una organizacin se realicen estn
ntimamente relacionadas, lo que en ocasiones impide determinar con
exactitud en qu orden estas actividades se realizan, as como el conocer
los pasos que hay que seguir para efectuarlos.
El ciclo de vida de un sistema es el proceso en el cual los analistas, los
ingenieros de software, los programadores y los usuarios finales elaboran
sistemas de informacin.
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
24
A menudo, los desarrolladores de un programa comienzan codificando sin
haber realizado un estudio o anlisis previo. El ciclo de vida, es la
sucesin de etapas por las que pasa el software desde que un nuevo
proyecto es concebido hasta que se deja de usar. Cada una de estas
etapas lleva asociada una serie de tareas que deben realizarse, y una
serie de documentos (en sentido amplio: software) que sern la salida de
cada una de estas fases y servirn de entrada en la fase siguiente.

El ciclo de vida del desarrollo de sistemas SDLC (por sus siglas en ingls)
es un enfoque por fases del anlisis, diseo e implementacin que
sostiene que los sistemas son desarrollados de mejor manera mediante el
uso de un ciclo especfico de actividades.

Los analistas proceden sistemticamente en el seguimiento de cada una
de las fases, las mismas pueden ser divididas, dependiendo del enfoque
que tengan cada uno de ellos.
2.9 El ciclo de vida en cascada (lineal o secuencial)

Propuesto por Royce, en 1970, es considerado como el modelo clsico, y
se basa en el ciclo de ingeniera convencional. Consta de una serie de
fases o etapas, con las siguientes caractersticas:

o Cada fase empieza cuando se ha terminado la anterior.

o Para pasar de una fase a otra es necesario conseguir todos los
objetivos de la anterior.
o Ayuda a prevenir que se sobrepasen las fechas de entrega y los
costes esperados.

o Al final de cada fase el personal tcnico y los usuarios tienen la
oportunidad de revisar el progreso del proyecto.

Figura N 1

Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
25
1. Ingeniera y anlisis del sistema. El software siempre va a formar
parte de otro sistema mayor, por tanto, el primer paso debe ser el
anlisis de las caractersticas y comportamiento de ese sistema.
2. Anlisis y definicin de requisitos. Se deben identificar los
requerimientos que debe satisfacer el software, tanto los requisitos de
funcionamiento como los de rendimiento y los de interfaz.
3. Diseo. A partir de la especificacin de requisitos se elabora una
documentacin en la que se plasma una representacin del software que
se va a construir. Esta representacin tiene un nivel de abstraccin que la
hace fcilmente comprensible y muestra los componentes software que se
codificarn. El diseo se aplica a:

o Las estructuras de datos.

o La arquitectura de las aplicaciones.

o Al algoritmo (estructura de los programas)

o Las interfaces.
El proceso de diseo traduce los requisitos a una representacin del
software que se pueda evaluar por calidad antes de que comience la
generacin del cdigo
4. Implementacin o codificacin. Se codifican, prueban y depuran
cada uno de los mdulos diseados en la fase anterior. Un diseo
exhaustivo convertir esta fase en algo casi automtico
5. Prueba. Una vez integrados los mdulos desarrollados, se prueban
para detectar errores y comprobar que producen el resultado esperado
6. Mantenimiento. Despus de haber sido entregado al cliente, el
software sufrir cambios:

o Se han detectado errores (errores latentes).

o El cliente desea alguna modificacin o mejora funcional

o Es necesario adaptarlo a un nuevo entorno (Ej. cambia el sistema
operativo; cambiamos impresora matricial-agujas, papel copia, por
impresora lser; etc.)

En cualquier caso, debemos volver atrs en el ciclo de vida y
volveremos a una etapa ms atrs cuanto ms significativo sea la
modificacin requerida
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
26
Por ltimo, decir que algunos autores consideran una fase ms en este
modelo. Es la fase de sustitucin Cuando la vida til de un producto
software finaliza y es sustituido por otro, debe de hacerse de una manera
planificada: mejor una sustitucin progresiva, permitiendo la coexistencia
de los dos productos esto facilitar la adaptacin de los usuarios y
permitir comprobar el funcionamiento del nuevo sistema.
Inconvenientes encontrados al ciclo de vida en cascada:

o Los proyectos reales rara vez siguen un esquema secuencial, por
ejemplo es frecuente la redefinicin de requisitos una vez
empezada la codificacin

o Por lo general resulta difcil para el cliente exponer los requisitos
desde el primer momento. En el modelo resulta difcil acomodar !a
incertidumbre inicial.

o Los clientes no siempre tienen la paciencia necesaria para "esperar
a ver algo que funcione" hasta las etapas finales del desarrollo

o Cuando existe cambio de parecer de los usuarios sobre las
necesidades reales, o requisitos del sistema, probablemente no
figuren en el producto final.

o En un proceso de desarrollo siempre hay retrasos innecesarios,
este modelo secuencial puede hacer que parte del equipo de
desarrollo deban esperar a que otros finalicen etapas dependientes

o Otro de los problemas de este modelo es que los resultados no se
ven hasta muy avanzado el proyecto, por tanto la realizacin de
modificaciones al sistema si se ha detectado un error u omisin
llegara a ser muy costoso.
2.10. El modelo de creacin de prototipos
Surge como solucin a dos de las crticas que se le hacan al modelo en
cascada:

o Es difcil tener claros todos los requisitos al inicio
o No se dispone de una versin operativa hasta el final

A veces, un cliente define un conjunto de objetivos generales para el
software, pero no es capaz de detallar los requisitos de entrada
procesamiento y salida. En otros casos el desarrollador puede no estar
seguro sobre la eficacia de un algoritmo, de la capacidad de adaptacin a
un sistema operativo o de la forma en que debera implementarse la
interfaz hombre/mquina,... En estos casos el paradigma de construccin
de prototipos puede ser un buen candidato.

Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
27
Un prototipo:

o Es un programa ejecutable que muestra la interfaz
hombre/mquina de forma que facilite al usuario la comprensin de
cmo se producir tal interaccin.
o Implementa un subconjunto de las funcionalidades para probar el
rendimiento de un algoritmo.
o Se trata de un producto intermedio a la espera de mejorar
caractersticas como el rendimiento, el control de errores.
o Un programa existente que ejecute parte o toda la funcin
deseada, pero que tenga otras caractersticas que deban ser
mejoradas en el nuevo trabajo de desarrollo.
Figura N 2















Modelo o aproximacin prototipo
El proceso de desarrollo de software basado en prototipos consiste en:

o Lo primero que hay que hacer es una recoleccin de requisitos
(refinamiento si no es el primer prototipo). El tcnico y el cliente se
renen y definen los objetivos globales para el software, identifican
todos los requerimientos conocidos y perfilan las reas en donde ser
necesario una mayor definicin.

o Luego se hace un diseo rpido del prototipo (se centrar en
aspectos visibles por el usuario: formatos de la entrada/salida de
datos). El diseo rpido conduce a la construccin de un prototipo.

o Se construye el prototipo (podemos usar el entorno de desarrollo
en el que se construir el producto final o usar alguna herramienta
para la creacin de prototipos)

Escuchar al
Cliente
El cliente prueba la maqueta
Construir y revisar maqueta
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
28
o Se presenta al cliente para que lo evale y se repite el ciclo, hasta
que los requisitos estn totalmente definidos y se puede comenzar
con el desarrollo del producto final.
Figura N 3


La construccin del software basada en prototipos es de gran ayuda en la
fase de especificacin de requisitos Sin embargo tenemos productos
intermedios que podemos aprovechar para el producto final.
La construccin del prototipo tambin tiene algunos inconvenientes:
o El cliente ve funcionando algo muy pronto, sin saber que "est
sujetado por alfileres", no entiende por qu se tarda tanto en
finalizar el producto.
o El desarrollador a. veces opta por lenguajes de programacin
inadecuados para el producto final, por ejemplo porque lo conoce y
quiere finalizar el prototipo cuanto antes. Y en vez de desarrollar el
producto final con el adecuado, por aprovechar el prototipo la,
solucin mala acaba siendo la utilizada.
2.11 Modelo en espiral

En este modelo se proporciona las ventajas del modelo de ciclo de vida en
cascada y el prototipado, el software se va desarrollando en una serie de
versiones incrementales. A pesar de ser un modelo relativamente reciente
y de no haber sido utilizado ampliamente, es un modelo realista para el
desarrollo de sistemas software complejos.

Permite la utilizacin de prototipos en cualquier etapa e incorpora el
anlisis de riesgos.
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
29
El modelo en espiral se divide en una serie de actividades o regiones de
tareas, generalmente se distinguen entre tres y seis:
Figura N 4



Modelo en espiral
1. Comunicacin con el cliente: Especificacin de tareas
requeridas para establecer la comunicacin entre el desarrollador y
el cliente

2. Planificacin: Especificacin de tareas para definir los recursos,
tiempo y otras informaciones relacionadas con el proyecto. En esta
fase se determina los objetivos del proyecto, las posibles
alternativas y las restricciones. Esta actividad equivale a la de
recoleccin de requisitos del ciclo de vida clsico e incluye adems
la planificacin de las actividades a realizar en cada iteracin.

3. Anlisis de riesgos: El desarrollo de cualquier proyecto
complejo lleva implcito una serie de riesgos: unos relativos al
propio proyecto (los riesgos que pueden hacer que el proyecto
fracase) y otros relativos a las decisiones que deben tomarse
durante su desarrollo (los riesgos asociados a que una de estas
decisiones sea errnea).

Identificar riesgos: Pueden ser: riesgos del
proyecto (presupuestarios, de organizacin, del
cliente. etc.), riesgos tcnicos (problemas de diseo,
codificacin, mantenimiento), riesgos del negocio
Ingeniera
Construccin y adaptacin
Evaluacin del
cliente
Comunicacin
con el cliente
Planificacin
Anlisis de riesgos
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
30
(riesgos de mercado: que se adelante la competencia
o que el producto no se venda bien).

Estimacin de riesgos: Para cada riesgo se debe
identificar la probabilidad de que ocurra y las
consecuencias que podra causar.

Evaluacin de riesgos: Establecer niveles de
referencia que permitan, llegado el caso, interrumpir el
proyecto. Por ejemplo, si superamos un determinado
costo o duracin.

Gestin de riesgos: Supervisar el desarrollo del
proyecto de forma que se detecten los riesgos tan
pronto como aparezcan y minimizar daos

4. Ingeniera: Consiste en el desarrollo de la aplicacin o
prototipo, para construir una o ms representaciones del caso en
estudio.

5 Construccin y adaptacin: Consiste en la especificacin de
tareas para construir, probar e instalar el sistema o prototipo y
proporcionar soporte al usuario (documentacin).

6. Evaluacin del cliente: tareas para obtener la reaccin del
cliente al mostrarle el software o prototipo desarrollado.
En cada regin existen una serie de tareas que se adaptan a las
caractersticas del proyecto. Para proyectos pequeos el nmero de
tareas y su formalidad ser baja y para proyectos grandes incrementar
la complejidad.

Cuando empieza este proceso evolutivo, el equipo de ingeniera del
software gira alrededor de la espiral en la direccin de las agujas del reloj
y comenzando por el centro. En la primera iteracin se definen los
requisitos del sistema y se realiza la planificacin inicial. Se analizan los
riesgos y se desarrolla una versin o prototipo del sistema. El cliente la
evala y con sus comentarios se refinan los requisitos, se reajusta la
planificacin.

En este modelo, los prototipos son sucesivas versiones del producto, cada
vez ms detalladas (el ltimo es el producto final) y constituyen el
esqueleto del producto de ingeniera; por tanto deben construirse
siguiendo estndares de calidad.


2.12 Modelo Incremental

Dado que los proyectos de software son largos, es comn dividir el
trabajo en miniproyectos, cada miniproyecto es una iteracin que resulta
un incremento. Las iteraciones se refieren a pasos en flujo de trabajo y
los incrementos referencian un crecimiento en el producto.
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
31
Para hacer ms efectivas las iteraciones deben ser controladas, es decir
deben ser seleccionadas y llevadas a cabo de una forma planificada de
manera que cada una de las iteraciones constituya un miniproyecto de
software.

Cada iteracin considerada como miniproyecto aborda actividades del
desarrollo de sistemas como el anlisis, diseo, implementacin y el test.
Por supuesto, un incremento no es necesariamente aditivo ya que
especialmente en las primeras fases del ciclo de vida los desarrolladores
pueden estar reemplazando un diseo superficial por un diseo ms
detallado. En las fases posteriores los incrementos pueden ser aditivos.

Se puede resumir los beneficios de asumir un proceso iterativo
controlado en:

La iteracin controlada reduce los riesgos de costo a los de una
iteracin. Si es necesario repetir una iteracin slo se pierde el
esfuerzo de una iteracin y no el valor del producto completo.

Reduce el riesgo de no tener el producto en el mercado en la
fecha de entrega pactada al comienzo del proyecto, mediante la
planificacin de los riesgos ms altos en las primeras fases del
desarrollo, el tiempo consumido en resolverlos se invierte al
principio del proceso cuando el equipo est menos apresurado
que ceca de la fecha de entrega.

Acelera el ritmo del esfuerzo de desarrollo global ya que los
desarrolladores trabajan de forma ms eficiente cuando ven los
objetivos a corto plazo.

Acepta una realidad a menudo ignorada, las necesidades de los
usuarios y por tanto los requisitos no se pueden definir
completamente desde el principio, sino que son refinados en
iteraciones sucesivas. Un enfoque iterativo es fcilmente
adaptable a cambios en el entorno.















Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
32
Figura N 5


Aproximacin iterativa e incremental
2.13 Tcnicas de cuarta generacin
El trmino "tcnicas de cuarta generacin" abarca un amplio espectro de
herramientas de software que tienen algo en comn: todas facilitan, al
que desarrolla el software, la especificacin de algunas caractersticas del
software a alto nivel. Luego, la herramienta genera automticamente el
cdigo fuente basndose en la especificacin del tcnico.

Los tipos ms habituales de generadores de cdigo cubren uno o varios
de los siguientes aspectos:

Acceso a bases de datos utilizando lenguajes de consulta de alto
nivel (derivados normalmente de SQL). Con ello no es necesario conocer
la estructura de los ficheros o tablas ni de sus ndices.

Generacin de cdigo. A partir de una especificacin de los requisitos
se genera automticamente toda la aplicacin.

Generacin de pantallas. Permiten disear la pantalla dibujndola
directamente, incluyendo adems el control del cursor y la gestin de
errores de los datos de entrada.

Gestin de entornos grficos.

Anlisis Diseo Cdigo Pruebas
Anlisis
Anlisis
Diseo Cdigo Pruebas
Diseo Cdigo
Ingeniera de
Sistemas/Informacin
Tiempo de calendario
Incremento 1
Incremento 2
Incremento 3 Pruebas
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
33
Generacin de informes. (de forma similar a las pantallas).
Figura N 6

Tcnicas de cuarta generacin
Al igual que en otros paradigmas, el proceso comienza con la recoleccin
de requisitos, que pueden ser traducidos directamente a cdigo fuente
usando un generador de cdigo. Sin embargo el problema es el mismo
que se plantea en el ciclo de vida clsico: es muy difcil que se puedan
establecer todos los requisitos desde el comienzo: el cliente puede no
estar seguro de lo que necesita, o, aunque lo sepa, puede ser difcil
expresarlo de la forma en que precisa la herramienta de cuarta
generacin para poder entenderla.

Si la especificacin es pequea, podemos pasar directamente del anlisis
de requisitos a la generacin automtica de cdigo, sin realizar ningn
tipo de diseo. Pero si la aplicacin es grande, se producirn los mismos
problemas que si no usamos tcnicas de cuarta generacin: mala calidad,
dificultad de mantenimiento y poca aceptacin por parte del cliente). Es
necesario, por tanto, realizar la estrategia de diseo, puesto que el propio
generador se encarga de parte de los detalles del diseo tradicional:
descomposicin modular, estructura lgica y organizacin de los ficheros,
etc.).

Las herramientas de cuarta generacin se encargan tambin de producir
automticamente la documentacin del cdigo generado, pero esta
documentacin a veces es incomprensible para algunos casos, por ello, es
difcil de seguir, es as que es necesario completarla hasta obtener una
documentacin con sentido.

Para transformar una implementacin TG4 en un producto, el que lo
desarrolla debe dirigir una prueba completa, desarrollar una
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
34
documentacin con sentido y ejecutar el resto de actividades de
"transicin" requeridas en los otros paradigmas. Adems, el software
desarrollado con TG4 debe ser construido de forma que facilite la
realizacin del mantenimiento de forma expeditiva.

No obstante a su aplicabilidad, este modelo ha recibido algunas crticas
como:

No son ms fciles de utilizar que los lenguajes de tercera
generacin.
El cdigo fuente que producen en ocasiones es poco eficiente.
Slo son aplicables al software de gestin.

2.14. Modelo DRA
El Desarrollo Rpido de Aplicaciones (DRA) (rapid application
Development RAD) es un modelo de proceso del desarrollo del software
lineal secuencial que enfatiza un ciclo de desarrollo extremadamente
corto. DRA es una adaptacin a "Alta velocidad" en el que se logra el
desarrollo rpido utilizando un enfoque de construccin basado en
componentes. Si se comprenden bien los requisitos y se limita el mbito
del proyecto, el proceso DRA permite al equipo de desarrollo crear un
"sistema completamente funcional" dentro de periodos cortos de tiempo.
Cuando se utiliza principalmente para aplicaciones de sistemas de
informacin, el enfoque DRA comprende las siguientes fases:
Modelado de gestin: El flujo de informacin entre las funciones de
gestin se modela de forma que responda a las siguientes preguntas:
Qu informacin conduce el proceso de gestin? Qu informacin se
genera? Quin la genera? A dnde va la informacin? Quin la
procesa?
Modelado de datos: el flujo de informacin definido como parte de la
fase de modelado de gestin se refina como un conjunto de objetos de
datos necesarios para apoyar la empresa. Se definen las caractersticas
(llamadas atributos) de cada uno de los objetos y las relaciones entre
estos objetos.
Modelado de proceso: los objetos de datos definidos en la fase de
modelado de datos quedan transformados para lograr el flujo de
informacin necesaria para implementar una funcin de gestin. Las
descripciones del proceso se crean para aadir, modificar, suprimir, o
recuperar un objeto de datos. Es la comunicacin entre los objetos.
Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de
cuarta generacin. En lugar de crear software con lenguajes de
programacin de tercera generacin, el proceso DRA trabaja para volver a
utilizar componentes de programas ya existentes (cuando es posible) o a
crear componentes reutilizables (cuando sea necesario). En todos los
Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
35
casos se utilizan herramientas automticas para facilitar la construccin
del software.
Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya
se han comprobado muchos de los componentes de los programas. Esto
reduce tiempo de pruebas. Sin embargo, se deben probar todos los
componentes nuevos y se deben ejercitar todas las interfases a fondo.
Obviamente la limitacin de tiempo impuestas en un proyecto DRA
demanda "mbito en escalas". Si una aplicacin de gestin puede
modularse de forma que permita completarse cada una de las funciones
principales en menos de tres meses (utilizando el enfoque descrito
anteriormente), es un candidato del DRA. Cada una de las funciones
pueden ser afrontadas por un equipo DRA diferente y ser integradas en
un solo conjunto.
Al igual que todos los modelos de proceso, el enfoque DRA tiene
inconvenientes:
Para proyectos grandes aunque por escalas, el DRA requiere
recursos humanos suficientes como para crear el nmero correcto
de equipos DRA.
DRA requiere clientes y desarrolladores comprometidos en las
rpidas actividades necesarias para completar un sistema en un
marco de tiempo abreviado. Si no hay compromiso, por ninguna de
las partes constituyentes, los proyectos DRA fracasaran.
Figura No 7

El Modelo DRA


Anlisis y Diseo de Sistemas de Informacin I

TEXTO DE ASIGNATURA
36
2.15. Metodologa de desarrollo de software

Las metodologas de desarrollo de software son un conjunto de
procedimientos, tcnicas y ayudas a la documentacin para la elaboracin
de productos software, es como un libro de recetas de cocina, en el que
se van indicando paso a paso todas las actividades a realizar para lograr
el producto deseado, indicando las personas que deben participar en el
desarrollo de las actividades y qu papel deben hacer en las mismas.
Adems detallan la informacin que se debe producir como resultado de
una actividad y la informacin necesaria para comenzar la actividad.

Se debe utilizar una metodologa porque:

Aumenta la productividad
Mejora la calidad de los productos terminados
Disminuye el mantenimiento
Mejora la calidad de vida de los analistas

Adems, la utilizacin de una metodologa de anlisis y diseo, soluciona:

Falta de planificacin habitual
La mala definicin de los requerimientos de los usuarios
Cambios constantes durante el desarrollo
Sistemas pobremente diseados
Programas mal codificados



BIBLIOGRAFA

1. Tcnicas de cuarta generacin
http://lafacu.com/informatica/trabajos/t4gl.html

2. Pressman Roger Ingeniera del software, Editorial MC- Graw Hill,
Mxico 2002.

3. Kendall and Kendall Anlisis y Diseo de Sistemas de Informacin,
Prentice Hall, Tercera Edicin, 1997.

4. Introduccin a los sistemas de informacin Instituto tcnico de sonora,
Mxico 2008
http://www.geocities.com/SiliconValley/Pines/7894/sistemas/introduccion
.html#administracion

5. Seen James A. Anlisis y Diseo de Sistemas de Informacin, Editorial
McGraw-Hill, Segunda Edicin, 1992.

6. J. Monzn F. Y David Spence Anlisis y Diseo de Sistemas
Informticos, Editorial Gmez, Per, 2009.