Escolar Documentos
Profissional Documentos
Cultura Documentos
Aprobacin de la solicitud
No todos los proyectos solicitados son deseables o factibles. En algunos casos el
desarrollo puede comenzar inmediatamente, aunque lo comn es que los miembros del equipo de
sistemas se encuentren ocupados con otros proyectos. Cuando esto ocurre, la administracin
decide qu proyectos son los ms importantes y decide el orden en que se llevarn a cabo.
Despus de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario
para terminarlo y las necesidades de personal; con esta informacin se determina dnde ubicarlo
dentro de la lista existente de proyectos.
Determinacin de los requerimientos del sistema
El aspecto fundamental del anlisis 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 los procesos de una empresa para dar respuesta a las siguientes
preguntas clave:
1. Qu es lo que se hace?
2. Cmo se hace?
3. Con qu frecuencia se presenta?
4. Qu tan grande es el volumen de transacciones o de decisiones?
5. Cul es el grado de eficiencia con el que se efectan las tareas?
6. Existe algn problema?
7. Si existe un problema, que tan serio es?
8. Si existe un problema, cul es la causa que lo origina?
Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles
relacionados con los procesos de la empresa, sus opiniones sobre por qu ocurren las cosas, las
soluciones que proponen y sus ideas para cambiar el proceso.
Asimismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la
observacin en condiciones reales de las actividades del trabajo y, en algunas ocasiones,
muestras de formas y documentos con el fin de comprender el proceso en su totalidad.
Conforme se renen los detalles, los analistas estudian los datos sobre requerimientos con
la finalidad de identificar las caractersticas que debe tener el nuevo sistema, incluyendo la
informacin que deben producir los sistemas junto con caractersticas operacionales tales como
controles de procesamiento, tiempos de respuesta y mtodos de entrada y salida.
Diseo del sistema
El diseo de un sistema de informacin produce los detalles que establecen la forma en la
que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los
especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste
con la de desarrollo del software, a la que denominan diseo fsico.
Los analistas de sistemas comienzan el proceso de diseo identificando los reportes y
dems salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisin
los datos especficos para cada reporte y salida. Es comn que los diseadores hagan un bosquejo
del formato o pantalla que esperan que aparezca cuando el sistema est terminado.
El diseo de un sistema tambin indica los datos de entrada, aquellos que sern
calculados y los que deben ser almacenados. Asimismo, se escriben con todo detalle los
procedimientos de clculo y los datos individuales. Los diseadores seleccionan las estructuras
de archivo y los dispositivos de almacenamiento.
La informacin detallada del diseo se proporciona al equipo de programacin para
comenzar la fase de desarrollo de software. Los diseadores son los responsables de dar a los
programadores las especificaciones de software completas y claramente delineadas.
Desarrollo de software
Los encargados de desarrollar software pueden instalar (o modificar y despus instalar) software
comprado a terceros o escribir programas diseados a la medida del solicitante.
Los programadores tambin son responsables de la documentacin de los programas y de
proporcionar una explicacin de cmo y por qu ciertos procedimientos se codifican en
determinada forma. La documentacin es esencial para probar el programa y llevar a cabo el
mantenimiento una vez que la aplicacin se encuentra instalada.
Prueba de sistemas
Durante la fase de 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.
En ocaciones se permite que varios usuarios utilicen el sistema para que los analistas observen si
tratan de emplearlo en formas no previstas.
En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribi
los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean
completas e imparciales y, por otra, que el software sea ms confiable.
Implantacin y evaluacin
La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios,
instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla.
Una vez instaladas, las aplicaciones se emplean durante muchos aos. 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; realizar cambios y modificaciones en el software, archivos o
procedimientos para satisfacer las nuevas necesidades de los usuarios. Dado que los sistemas de
las organizaciones junto con el ambiente de las empresas experimentan cambios de manera
continua, los sistemas de informacin deben mantenerse siempre al da. En este sentido, la
implantacin es un proceso en constante evolucin.
La evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La
evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones:
en una pantalla, o que lleva a cabo otras actividades significativas. Es la primera versin, o
iteracin de un sistema de informacin; es el modelo original.
Razones para desarrollar prototipos de sistemas
Los requerimientos de informacin no siempre estn bien definidos o pueden ser
demasiado vagos aun al formular el diseo.
Los prototipos permiten evaluar situaciones extraordinarios donde los encargados de
disear e implantar sistemas no tienen informacin ni experiencia, o tambin donde existen
situaciones de riesgo y costo elevados, y aquellas donde el diseo propuesto es novedoso y an
no ha sido probado.
El prototipo es, en realidad, un modelo piloto o de prueba; el diseo evoluciona con el
uso. Aunque el prototipo es un sistema que funciona, est diseado para ser modificado con
facilidad. La informacin obtenida con su uso se aplica en un nuevo diseo que se emplea, otra
vez, como prototipo y que revela ms informacin valiosa sobre el diseo. El proceso se repite
las veces que sea necesario para revelar los requerimientos esenciales del diseo.
Los prototipos tienen mayor utilidad bajo las siguientes condiciones:
Los encargados de disear e implantar sistemas nunca han desarrollado uno con las
caractersticas del sistema propuesto.
Se conoce slo una parte de las caractersticas esenciales del sistema; las dems no son
identificables a pesar de un cuidadoso anlisis de requerimientos.
La experiencia con el uso del sistema aadir una lista significativa de requerimientos que el
sistema debe satisfacer (ms que la que puede obtenerse con cualquier otro mtodo de
desarrollo).
Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo
adicional y el refinamiento de sus caractersticas.
Los usuarios del sistema participan en el proceso de desarrollo.
El principio fundamental del desarrollo de prototipos es el siguiente:
Los usuarios pueden sealar las caractersticas que les agradara o no tener, junto con los
problemas que presenta un sistema que existe y funciona, con mayor facilidad que si se les
pidiese que las describieran en forma terica o por escrito. El uso y la experiencia producen
comentarios ms significativos que el anlisis de diagramas y las propuestas por escrito.
El desarrollo de prototipos de sistemas es un proceso interactivo. Comienza con unas
cuantas funciones y crece al incluir otras que son identificadas con posterioridad. Tambin puede
comenzar con un conjunto de funciones que tanto el analista como los usuarios consideran
completo y que puede aumentar o disminuir con el uso y la experiencia. En general, los pasos a
seguir en el proceso de desarrollo de prototipos son los siguientes:
1. Identificar los requerimientos de informacin que el usuario conoce junto con las
caractersticas necesarias del sistema.
2. Desarrollar un prototipo que funcione.
3. Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto expande la lista de
los requerimientos de sistemas conocidos.
No
Cliente
812
102721
1319
103654
2107
Nombre
Cliente
Harper University
McGraw
Manufacturing
Union Hospital
Direcc.
Cliente
33 whipple
Lane,Rosboro,NY
13514
90 Main, Endicott,
NY 13760
1021 6th Avenue,
NY,NY 10021
Fecha
Solic.
12/01
No
Artculo
T101
12/01
B16
C118
B14
C118
12/02
B14
Descrip.
Artculo
Manteles
Precio
Artculo
.95
Cant.
Solicita
100
Costo
Total
185.40
Cobijas
Sbanas
Toallas
Sbanas
1.55
.29
.42
.29
50
30
10
10
5.80
Toallas
.42
60
118.20
incluya la informacin sobre el pedido y el cliente. Sin ambargo, al considerar cada registro
como un pedido aparte se aumenta la complejidad para el cambio de los detalles de cualquier
parte del pedido y utiliza espacio adicional.
Cuando un pedido especifica un artculo, los detalles es ste se establecen slo una vez. Cuando
se piden cuatro, los detalles del artculo se repiten cuatro veces. La parte del registro de los datos
que se repite de denomina grupo de repeticin.
La primera forma normal se alcanza cuando un registro se disea de longitud fija. Esto se
lleva a cabo quitando el grupo de repeticin y creando un archivo o relacin aparte que contenga
al grupo de repeticin. El registro original y el nuevo se interrelacionan mediante un punto
comn de los datos.
Registro de Pedidos
No
Pedido
101456
102721
103654
105489
No
Cliente
812
1319
2107
824
Nombre
Cliente
Harper University
Mcgraw Manufacturing
Union Hospital
Hara Enterprises
Registro de Artculos
No
Pedido
101456
101456
101456
101456
102721
103654
103654
105489
No
Artculo
T101
B16
C118
B14
C118
B14
B16
N38
Direccin
Cliente
33 Whipple Lane, Rosboro, NY 13514
98 Main, Endicott, NY 13760
1021 6th Avenue, NY, NY 10021
Commerce Circle, Endicott, NY 13760
Descripcin
Artculo
Manteles
Cobijas
Sbanas
Toallas
Cobijas
Toallas
Cobijas
Servilletas
Fecha
Solic.
12/01
12/01
12/02
11/30
Precio
Artculo
.95
.33
.29
.12
.29
.12
.33
.84
Costo
Total
185.40
5.80
118.20
84.00
Cantidad
Solicitada
100
50
30
10
20
60
60
100
Registro de Pedidos
Pedido
101456
120721
103654
105489
105490
Cliente
812
1319
2107
824
836
Fecha
12/01
12/01
12/02
11/30
11/28
Registro de Proveedores
Nmero Cliente
Nombre Cliente
812
Harper University
1319
McGraw Manufacturing
2107
Union Hospital
824
Hara Enterprises
836
Holiday Inn Downtown
Total
185.40
5.80
118.20
84
78.50
Direccin Cliente
33 whipple Lane, Rosboro, NY 13514
98 Main, Endicott, NY 13760
1021 6th Avenue, NY, NY 10021
Commerce Circle, Endicott, NY 13760
10 Downey Street, Buffalo, NY 13240
Anlogamente, el registro de partes contiene la llave de nmero de parte y todos los dems datos
en el registro dependen funcionalmente de l.
Tercera Forma Normal
La tercera forma normal se alcanza cuando se quitan las dependencias transitivas de un diseo de
registro. El caso general es el siguiente:
A, B, y C son tres datos en un registro
Si C es funcionalmente dependiente de B y
B es funcionalmente dependiente de A,
entonces C es funcionalmente dependiente de A
Por lo tanto, existe una dependencia transitiva
En el manejo de datos, la dependencia transitiva es una preocupacin, ya que los datos
pueden perderse de manera inadvertida cuando la relacin est oculta. En el caso anterior si se
quita A, entonces tambin se quitan B y C, sea o no sta la intencin. Este problema se elimina
diseando el registro para la tercera forma normal. La conversin a la tercera forma normal quita
la dependencia transitiva dividiendo la relacin en dos relaciones separadas.
Consideremos este ejemplo. Al utilizar la informacin sobre el proveedor de:
No del
producto
No del
proveedor
Nombre
proveedor
Direccin
proveedor
No de
parte
Descrip.
Parte
Cantidad
utilizada
Descrip.
Producto
Costo del
producto
Cantidad utilizada
Nmero proveedor
Direccin proveedor
Los registros adicionales dan mayor flexibilidad para cubrir los requerimientos futuros a la vez
que eliminan las dificultades mencionadas arriba.