You are on page 1of 20

TEMA Nº 2

EL ANÁLISIS DE SISTEMAS Y LOS CICLOS DE VIDA
DE DESARROLLO DE SISTEMAS DE INFORMACIÓN














Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
18
TEMA Nº 2 EL ANÁLISIS DE SISTEMAS Y LOS CICLOS DE VIDA
DE DESARROLLO DE SISTEMAS DE INFORMACIÓN

2.1. Introducción
Todo proyecto de ingeniería está ligado a la obtención de un producto,
proceso o servicio que es necesario generar a través 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 gestión 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 tecnologías empleadas.
La complejidad de las relaciones entre las distintas actividades crece
exponencialmente con el tamaño, con lo que rápidamente se haría
inabordable si no fuera por la táctica muy empleada de “divide y
vencerás”. De esta forma la división de los proyectos en fases sucesivas
es un primer paso para la reducción de su complejidad, tratándose de
escoger las partes de manera que sus relaciones entre sí sean lo más
simples posibles.
La definición 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 subcontratación 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 también se ve facilitado si la separación
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 práctica acumulada en el diseño 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 análisis de sistemas

Las siguientes definiciones de Análisis y Diseño de Sistemas están
enfocadas a un conjunto de elementos para realizar un objetivo
predefinido en el procesamiento de la información, las mismas están
relacionadas con la forma de representar el flujo de información de una
entidad o empresa según etapas definidas en una notación.


Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
19
 El Análisis y Diseño de Sistemas es un conjunto de hechos,
principios y reglas clasificadas y dispuestas de manera ordenada
mostrando un plan lógico en la unión de las partes.
 Dentro de las organizaciones, el Análisis y Diseño de Sistemas se
refiere al proceso de examinar la situación de una empresa con el
propósito de mejorarla con métodos y procedimientos más
adecuados, por consiguiente, es el proceso de clasificación e
interpretación de hechos, diagnóstico de problemas y empleo de la
información para recomendar mejoras al sistema.

2.3. La necesidad del análisis y diseño de sistemas

El análisis y diseño de sistemas, tal como es ejecutado por los analistas
de sistemas, busca analizar sistemáticamente el problema, las
especificaciones de entrada o flujo de datos, el proceso o transformación
de los datos, el almacenamiento y la salida de información dentro del
contexto de una empresa o institución. Además el diseño y análisis de
sistemas es usado para analizar, diseñar e implementar mejoras en el
funcionamiento de negocios que pueden ser logrados por medio del uso
de sistemas de información computarizados.

La instalación de un sistema sin la planificación adecuada lleva a
grandes frustraciones, y frecuentemente causa que el sistema deje de ser
usado. El análisis y diseño de sistemas, contiene la estructura del
desarrollo de un sistema de información, gran parte del mismo involucra
el trabajo con los usuarios actuales y eventuales.

El análisis y diseño de sistemas aporta en la estructura al análisis y diseño
de sistemas de información, un costoso esfuerzo que de otra forma podría
haber sido hecho de modo casual. Puede ser visto como una serie de
procesos llevados a cabo sistemáticamente para mejorar una organización
por medio del uso de sistemas de información computarizados.

2.4. Razones para iniciar un análisis 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 anomalía.
 Nuevas necesidades: Esto ocurre cuando surgen nuevas
disposiciones en la organización. Puede tratarse de una nueva ley,
una práctica contable, ó una nueva práctica 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 propósito de que la
empresa pueda satisfacer dicha necesidad.
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
20
 Implantación de una nueva tecnología: Puede ser el caso de
implantar una técnica diferente por ejemplo: si se implementa un
lector de huella digital para el control de asistencia, lo más
probable es que haya la necesidad de diseñar 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 análisis

El Desarrollo de Sistemas de Información incluye la adopción de una
metodología (análisis y diseño estructurado u orientado a objetos) o un
lenguaje de modelado unificado UML (estándar de modelado orientado a
objetos) para representar el funcionamiento de las actividades de una
empresa u organización. En la actualidad los estándares actuales de
modelado superaron al análisis y diseño estructurado por ser muy simple
y de poco alcance, la experiencia con sistemas grandes y complejos
descubrieron las limitaciones de ese método, particularmente cuando se
desarrollan sistemas con requerimientos inestables.

Un modelo es una abstracción de la realidad, un modelo es un
anteproyecto o proyección del sistema. El modelado es una técnica
aprobada en la Ingeniería para tener una vista previa del producto final.
Se debe modelar para entender mejor el problema que estamos
desarrollando.

Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
21
Ejemplo: Mostrar la interacción de un cliente con un servicio de cajero
automático, 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 código de la
tarjeta y verifica que es
correcto

3 Pide el código de PIN
(4 dígitos)

4 Ingresa el PIN
5 – Envía Id. De tarjeta
y PIN

6 – Verifica que el PIN
sea correcto
7- Mostrar selección de
tipo de cuenta

8- Elegir opción: Retiro
9. Pedir cuenta y monto
10- Ingresa cuenta y
monto

11. Envía 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 información surgieron como respuesta a las
necesidades de mejorar el uso de los recursos informáticos para satisfacer
los nuevos requisitos del proceso de información de las aplicaciones en las
empresas.
A pesar de las posibilidades tecnológicas, 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
organización se encuentra un vacío entre los usuarios y los
programadores o técnicos al momento de aplicar la tecnología en la
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
22
solución de problemas. Es aquí donde se ubica el lugar del analista,
comportándose como un puente en este vacío.
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 tecnología informática. Los analistas
de sistemas transforman las necesidades de información y de los usuarios
en soluciones tecnológicas basadas en computadoras.

El analista de sistemas es el personaje clave en cualquier proyecto de
desarrollo de sistemas, es fácil ver que el analista debe poseer un amplio
rango de habilidades y cualidades puesto que ocupa un cargo superior
dentro de la institución.

El analista es solucionador de problemas, es una persona que ve el
análisis de los problemas como un reto y disfruta al encontrar soluciones
empleando herramientas, técnicas y experiencia en análisis, diseño,
programación e implementación para comprender mejor los
requerimientos de la organización 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 diseñadores y programadores
etc.) a través 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 organización a otra;
a continuación se mencionan solo algunas de las actividades más
comunes asignadas a los analistas de sistemas:

- Análisis de sistemas: en este caso su responsabilidad es conducir
estudios sobre los sistemas relevantes dentro de la organización, para
detectar hechos relevantes. Considerar que la parte más importante es
reunir la información y determinar los requerimientos. En este punto, sólo
el analista es responsable del análisis de la información.

- Análisis y diseño de sistemas: el analista tiene la responsabilidad
adicional de diseñar el nuevo sistema, desarrollando las especificaciones
de diseño, tomando como base el análisis de los hechos previamente
recolectados.
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
23
- Análisis, diseño y programación: el analista cuando realiza esta
actividad conduce la investigación, desarrolla el diseño del nuevo sistema
y describe el software necesario para implantar el diseño.

2.7. Usuarios

Los analistas emplean el término usuario final para referirse a las
personas vinculadas con los sistemas de información:

Los usuarios finales se clasifican en cuatro categorías:

Usuarios primarios: Interactúan 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 aplicación.

Ejemplo: Gerentes encargados de la toma de decisiones de una
institución.

Usuarios responsables: Encargados del desarrollo de sistemas de
información 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 análisis
y diseño, éste inicia cuando en la organización se detecta que el sistema
necesita reformas.
El ciclo de vida de un sistema es el conjunto de actividades que los
analistas diseñadores y usuarios realizan para desarrollar e implantar un
sistema de información. Cuando se realiza un análisis se debe considerar
que todas las actividades que en una organización se realicen están
í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 información.
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
24
A menudo, los desarrolladores de un programa comienzan codificando sin
haber realizado un estudio o análisis previo. El ciclo de vida, es la
sucesión 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 serán la salida de
cada una de estas fases y servirán de entrada en la fase siguiente.

El ciclo de vida del desarrollo de sistemas SDLC (por sus siglas en inglés)
es un enfoque por fases del análisis, diseño e implementación que
sostiene que los sistemas son desarrollados de mejor manera mediante el
uso de un ciclo específico de actividades.

Los analistas proceden sistemáticamente 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 clásico, y
se basa en el ciclo de ingeniería convencional. Consta de una serie de
fases o etapas, con las siguientes características:

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 técnico y los usuarios tienen la
oportunidad de revisar el progreso del proyecto.

Figura Nº 1

Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
25
1. Ingeniería y análisis del sistema. El software siempre va a formar
parte de otro sistema mayor, por tanto, el primer paso debe ser el
análisis de las características y comportamiento de ese sistema.
2. Análisis y definición 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. Diseño. A partir de la especificación de requisitos se elabora una
documentación en la que se plasma una representación del software que
se va a construir. Esta representación tiene un nivel de abstracción que la
hace fácilmente comprensible y muestra los componentes software que se
codificarán. El diseño 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 diseño traduce los requisitos a una representación del
software que se pueda evaluar por calidad antes de que comience la
generación del código
4. Implementación o codificación. Se codifican, prueban y depuran
cada uno de los módulos diseñados en la fase anterior. Un diseño
exhaustivo convertirá esta fase en algo casi automático
5. Prueba. Una vez integrados los módulos desarrollados, se prueban
para detectar errores y comprobar que producen el resultado esperado
6. Mantenimiento. Después de haber sido entregado al cliente, el
software sufrirá cambios:

o Se han detectado errores (errores latentes).

o El cliente desea alguna modificación o mejora funcional

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

En cualquier caso, debemos volver atrás en el ciclo de vida y
volveremos a una etapa más atrás cuanto más significativo sea la
modificación requerida
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
26
Por último, decir que algunos autores consideran una fase más en este
modelo. Es la fase de sustitución Cuando la vida útil de un producto
software finaliza y es sustituido por otro, debe de hacerse de una manera
planificada: mejor una sustitución progresiva, permitiendo la coexistencia
de los dos productos esto facilitará la adaptación 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 redefinición de requisitos una vez
empezada la codificación

o Por lo general resulta difícil para el cliente exponer los requisitos
desde el primer momento. En el modelo resulta difícil 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 realización de
modificaciones al sistema si se ha detectado un error u omisión
llegaría a ser muy costoso.
2.10. El modelo de creación de prototipos
Surge como solución a dos de las críticas que se le hacían al modelo en
cascada:

o Es difícil tener claros todos los requisitos al inicio
o No se dispone de una versión 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 adaptación a
un sistema operativo o de la forma en que debería implementarse la
interfaz hombre/máquina,... En estos casos el paradigma de construcción
de prototipos puede ser un buen candidato.

Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
27
Un prototipo:

o Es un programa ejecutable que muestra la interfaz
hombre/máquina de forma que facilite al usuario la comprensión de
cómo se producirá tal interacción.
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
características como el rendimiento, el control de errores.
o Un programa existente que ejecute parte o toda la función
deseada, pero que tenga otras características que deban ser
mejoradas en el nuevo trabajo de desarrollo.
Figura Nº 2















Modelo o aproximación prototipo
El proceso de desarrollo de software basado en prototipos consiste en:

o Lo primero que hay que hacer es una recolección de requisitos
(refinamiento si no es el primer prototipo). El técnico y el cliente se
reúnen y definen los objetivos globales para el software, identifican
todos los requerimientos conocidos y perfilan las áreas en donde será
necesario una mayor definición.

o Luego se hace un diseño rápido del prototipo (se centrará en
aspectos visibles por el usuario: formatos de la entrada/salida de
datos). El diseño rápido conduce a la construcción 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 creación de prototipos)

Escuchar al
Cliente
El cliente prueba la maqueta
Construir y revisar maqueta
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
28
o Se presenta al cliente para que lo evalúe y se repite el ciclo, hasta
que los requisitos están totalmente definidos y se puede comenzar
con el desarrollo del producto final.
Figura Nº 3


La construcción del software basada en prototipos es de gran ayuda en la
fase de especificación de requisitos Sin embargo tenemos productos
intermedios que podemos aprovechar para el producto final.
La construcción del prototipo también 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 programación
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,
solución 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 utilización de prototipos en cualquier etapa e incorpora el
análisis de riesgos.
Análisis y Diseño de Sistemas de Información 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. Comunicación con el cliente: Especificación de tareas
requeridas para establecer la comunicación entre el desarrollador y
el cliente

2. Planificación: Especificación 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
recolección de requisitos del ciclo de vida clásico e incluye además
la planificación de las actividades a realizar en cada iteración.

3. Análisis de riesgos: El desarrollo de cualquier proyecto
complejo lleva implícito 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 errónea).

 Identificar riesgos: Pueden ser: riesgos del
proyecto (presupuestarios, de organización, del
cliente. etc.), riesgos técnicos (problemas de diseño,
codificación, mantenimiento), riesgos del negocio
Ingeniería
Construcción y adaptación
Evaluación del
cliente
Comunicación
con el cliente
Planificación
Análisis de riesgos
Análisis y Diseño de Sistemas de Información I

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

 Estimación de riesgos: Para cada riesgo se debe
identificar la probabilidad de que ocurra y las
consecuencias que podría causar.

 Evaluación de riesgos: Establecer niveles de
referencia que permitan, llegado el caso, interrumpir el
proyecto. Por ejemplo, si superamos un determinado
costo o duración.

 Gestión de riesgos: Supervisar el desarrollo del
proyecto de forma que se detecten los riesgos tan
pronto como aparezcan y minimizar daños

4. Ingeniería: Consiste en el desarrollo de la aplicación o
prototipo, para construir una o más representaciones del caso en
estudio.

5 Construcción y adaptación: Consiste en la especificación de
tareas para construir, probar e instalar el sistema o prototipo y
proporcionar soporte al usuario (documentación).

6. Evaluación del cliente: tareas para obtener la reacción del
cliente al mostrarle el software o prototipo desarrollado.
En cada región existen una serie de tareas que se adaptan a las
características del proyecto. Para proyectos pequeños el número de
tareas y su formalidad será baja y para proyectos grandes incrementará
la complejidad.

Cuando empieza este proceso evolutivo, el equipo de ingeniería del
software gira alrededor de la espiral en la dirección de las agujas del reloj
y comenzando por el centro. En la primera iteración se definen los
requisitos del sistema y se realiza la planificación inicial. Se analizan los
riesgos y se desarrolla una versión o prototipo del sistema. El cliente la
evalúa y con sus comentarios se refinan los requisitos, se reajusta la
planificación.

En este modelo, los prototipos son sucesivas versiones del producto, cada
vez más detalladas (el último es el producto final) y constituyen el
esqueleto del producto de ingeniería; por tanto deben construirse
siguiendo estándares de calidad.


2.12 Modelo Incremental

Dado que los proyectos de software son largos, es común dividir el
trabajo en miniproyectos, cada miniproyecto es una iteración que resulta
un incremento. Las iteraciones se refieren a pasos en flujo de trabajo y
los incrementos referencian un crecimiento en el producto.
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
31
Para hacer más 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 iteración considerada como miniproyecto aborda actividades del
desarrollo de sistemas como el análisis, diseño, implementación 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 diseño superficial por un diseño más
detallado. En las fases posteriores los incrementos pueden ser aditivos.

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

 La iteración controlada reduce los riesgos de costo a los de una
iteración. Si es necesario repetir una iteración sólo se pierde el
esfuerzo de una iteración 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
planificación de los riesgos más 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 más 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 fácilmente
adaptable a cambios en el entorno.















Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
32
Figura Nº 5


Aproximación iterativa e incremental
2.13 Técnicas de cuarta generación
El término "técnicas de cuarta generación" abarca un amplio espectro de
herramientas de software que tienen algo en común: todas facilitan, al
que desarrolla el software, la especificación de algunas características del
software a alto nivel. Luego, la herramienta genera automáticamente el
código fuente basándose en la especificación del técnico.

Los tipos más habituales de generadores de código 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.

Generación de código. A partir de una especificación de los requisitos
se genera automáticamente toda la aplicación.

Generación de pantallas. Permiten diseñar la pantalla dibujándola
directamente, incluyendo además el control del cursor y la gestión de
errores de los datos de entrada.

Gestión de entornos gráficos.

Análisis Diseño Código Pruebas
Análisis
Análisis
Diseño Código Pruebas
Diseño Código
Ingeniería de
Sistemas/Información
Tiempo de calendario
Incremento 1
Incremento 2
Incremento 3 Pruebas
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
33
Generación de informes. (de forma similar a las pantallas).
Figura Nº 6

Técnicas de cuarta generación
Al igual que en otros paradigmas, el proceso comienza con la recolección
de requisitos, que pueden ser traducidos directamente a código fuente
usando un generador de código. Sin embargo el problema es el mismo
que se plantea en el ciclo de vida clásico: es muy difícil 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 difícil
expresarlo de la forma en que precisa la herramienta de cuarta
generación para poder entenderla.

Si la especificación es pequeña, podemos pasar directamente del análisis
de requisitos a la generación automática de código, sin realizar ningún
tipo de diseño. Pero si la aplicación es grande, se producirán los mismos
problemas que si no usamos técnicas de cuarta generación: mala calidad,
dificultad de mantenimiento y poca aceptación por parte del cliente). Es
necesario, por tanto, realizar la estrategia de diseño, puesto que el propio
generador se encarga de parte de los detalles del diseño tradicional:
descomposición modular, estructura lógica y organización de los ficheros,
etc.).

Las herramientas de cuarta generación se encargan también de producir
automáticamente la documentación del código generado, pero esta
documentación a veces es incomprensible para algunos casos, por ello, es
difícil de seguir, es así que es necesario completarla hasta obtener una
documentación con sentido.

Para transformar una implementación TG4 en un producto, el que lo
desarrolla debe dirigir una prueba completa, desarrollar una
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
34
documentación con sentido y ejecutar el resto de actividades de
"transición" requeridas en los otros paradigmas. Además, el software
desarrollado con TG4 debe ser construido de forma que facilite la
realización del mantenimiento de forma expeditiva.

No obstante a su aplicabilidad, este modelo ha recibido algunas críticas
como:

 No son más fáciles de utilizar que los lenguajes de tercera
generación.
 El código fuente que producen en ocasiones es poco eficiente.
 Sólo son aplicables al software de gestión.

2.14. Modelo DRA
El Desarrollo Rápido 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 adaptación a "Alta velocidad" en el que se logra el
desarrollo rápido utilizando un enfoque de construcción 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
información, el enfoque DRA comprende las siguientes fases:
Modelado de gestión: El flujo de información entre las funciones de
gestión se modela de forma que responda a las siguientes preguntas:
¿Qué información conduce el proceso de gestión? ¿Qué información se
genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la
procesa?
Modelado de datos: el flujo de información definido como parte de la
fase de modelado de gestión se refina como un conjunto de objetos de
datos necesarios para apoyar la empresa. Se definen las características
(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
información necesaria para implementar una función de gestión. Las
descripciones del proceso se crean para añadir, modificar, suprimir, o
recuperar un objeto de datos. Es la comunicación entre los objetos.
Generación de aplicaciones: El DRA asume la utilización de técnicas de
cuarta generación. En lugar de crear software con lenguajes de
programación de tercera generación, 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
Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
35
casos se utilizan herramientas automáticas para facilitar la construcción
del software.
Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, 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 limitación de tiempo impuestas en un proyecto DRA
demanda "ámbito en escalas". Si una aplicación de gestión 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 número correcto
de equipos DRA.
 DRA requiere clientes y desarrolladores comprometidos en las
rápidas 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


Análisis y Diseño de Sistemas de Información I

TEXTO DE ASIGNATURA
36
2.15. Metodología de desarrollo de software

Las metodologías de desarrollo de software son un conjunto de
procedimientos, técnicas y ayudas a la documentación para la elaboración
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.
Además detallan la información que se debe producir como resultado de
una actividad y la información necesaria para comenzar la actividad.

Se debe utilizar una metodología porque:

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

Además, la utilización de una metodología de análisis y diseño, soluciona:

 Falta de planificación habitual
 La mala definición de los requerimientos de los usuarios
 Cambios constantes durante el desarrollo
 Sistemas pobremente diseñados
 Programas mal codificados



BIBLIOGRAFÍA

1. Técnicas de cuarta generación
http://lafacu.com/informatica/trabajos/t4gl.html

2. Pressman Roger Ingeniería del software, Editorial MC- Graw Hill,
México 2002.

3. Kendall and Kendall Análisis y Diseño de Sistemas de Información,
Prentice Hall, Tercera Edición, 1997.

4. Introducción a los sistemas de información Instituto técnico de sonora,
México 2008
http://www.geocities.com/SiliconValley/Pines/7894/sistemas/introduccion
.html#administracion

5. Seen James A. Análisis y Diseño de Sistemas de Información, Editorial
McGraw-Hill, Segunda Edición, 1992.

6. J. Monzón F. Y David Spence Análisis y Diseño de Sistemas
Informáticos, Editorial Gómez, Perú, 2009.