Anlisis y Diseo de Sistemas

http://www.monografias.com/trabajos/anaydisesis/anaydisesis.shtml
TEMA I.
PLAI!I"A"I# $E P%#&E"T#' $E '#!T(A%E

TEMA I. PLAI!I"A"I# $E ) P%#&E"T# $E 'I'TEMA'.
$E'A%%#LL#.
*.*. +,e es ,n proyecto de 'istema o 'oftware. -
Es el Proceso de gestin para la creacin de un Sistema o software, la cual encierra un
conjunto de actividades, una de las cuales es la estimacin, estimar es echar un vistazo al
futuro y aceptamos resignados cierto grado de incertidumbre. Aunue la estimacin, es mas un
arte ue una !iencia, es una actividad importante ue no debe llevarse a cabo de forma
descuidada. E"isten t#cnicas $tiles para la estimacin de costes de tiempo. % dado ue la
estimacin es la base de todas las dem&s actividades de planificacin del proyecto y sirve
como gu'a para una buena (ngenier'a Sistemas y Software.
Al estimar tomamos en cuenta no solo del procedimiento t#cnico a utilizar en el proyecto, sino
ue se toma en cuenta los recursos, costos y planificacin. El )ama*o del proyecto es otro
factor importante ue puede afectar la precisin de las estimaciones. A medida ue el tama*o
aumenta, crece r&pidamente la interdependencia entre varios elementos del Software.
+a disponibilidad de informacin ,istrica es otro elemento ue determina el riesgo de la
estimacin.
*... #bjeti/os de la Planificaci0n del Proyecto.
El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo
ue permita al gestor hacer estimaciones razonables de recursos costos y planificacin
temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de
un proyecto de software, y deber'an actualizarse regularmente medida ue progresa el
proyecto. Adem&s las estimaciones deber'an definir los escenarios del mejor caso, y peor caso,
de modo ue los resultados del proyecto pueden limitarse.
El -bjetivo de la planificacin se logra mediante un proceso de descubrimiento de la
informacin ue lleve a estimaciones razonables.
*.1 Acti/idades asociadas al proyecto de software.
*.1.* Ambito del 'oftware.
Es la primera actividad de llevada a cabo durante la planificacin del proyecto de Software.
En esta etapa se deben evaluar la funcin y el rendimiento ue se asignaron al Software
durante la (ngenier'a del Sistema de !omputadora para establecer un &mbito de proyecto ue
no sea ambiguo, e incomprensible para directivos y t#cnicos
.escribe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se eval$an las
funciones del &mbito y en algunos casos se refinan para dar mas detalles antes del comienzo
de la estimacin. +as restricciones de rendimiento abarcan los reuisitos de tiempo de
respuesta y procesamiento, identifican los limites del software originados por el hardware
e"terno, por la memoria disponible y por otros sistemas e"istentes.
El Ambito se define como un pre/reuisito para la estimacin y e"isten algunos elementos ue
se debe tomar en cuenta como es0
La Obtencin de la Informacin necesaria para el software. Para esto el analista y el
cliente se renen sobre las expectativas del proyecto y se ponen de acuerdo en los
puntos de inters para su desarrollo.
1.2 %E")%'#':
+a Segunda tarea de la planificacin del desarrollo de Software es la estimacin de los
recursos reueridos para acometer el esfuerzo de desarrollo de Software, esto simula a una
pir&mide donde las ,erramientas 3hardware y Software4, son la base proporciona la
infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pir&mide se
encuentran los !omponentes reutilizables.
% en la parte mas alta de la pir&mide se encuentra el recurso primario, las personas 3el recurso
humano4.
!ada recurso ueda especificado mediante cuatro caracter'sticas0
Descripcin del Recurso.
Informes de disponibilidad.
ec!a cronol"ica en la #ue se re#uiere el recurso.
$iempo durante el #ue ser% aplicado el recurso.

*.2.* %ec,rsos 3,manos.
+a !antidad de personas reueridas para el desarrollo de un proyecto de software solo puede
ser determinado despu#s de hacer una estimacin del esfuerzo de desarrollo 3por ejemplo
personas mes o personas a*os4, y seleccionar la posicin dentro de la organizacin y la
especialidad ue desempe*ara cada profesional.
*.2.. %ec,rsos o componentes de software re,tili4ables.
!ualuier estudio sobre recursos de software estar'a incompleto sin estudiar la reutilizacion,
esto es la creacin y la reutilizacion de bloues de construccin de Software.
)ales bloues se deben establecer en cat&logos para una consulta m&s f&cil, estandarizarse
para una f&cil aplicacin y validarse para la tambi#n f&cil integracin.
El Autor 5ennatan sugiere cuatro categor'as de recursos de software ue se deber'an tener en
cuenta a medida ue se avanza con la planificacin0
&omponentes ya desarrollados.
&omponentes ya experimentados.
&omponentes con experiencia Parcial.
&omponentes nuevos.


*.2.1 %ec,rsos de entorno.
El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de
(ngenier'a de Software, incorpora ,ardware y Software.
El ,ardware proporciona una plataforma con las herramientas 3Software4 reueridas para
producir los productos ue son el resultado de la buena practica de la (ngenier'a del Software,
un planificador de proyectos debe determinar la ventana temporal reuerida para el ,ardware y
el Software, y verificar ue estos recursos est#n disponibles. 6uchas veces el desarrollo de las
pruebas de validacin de un proyecto de software para la composicin automatizada puede
necesitar un compositor de fotograf'as en alg$n punto durante el desarrollo. !ada elemento de
hardware debe ser especificado por el planificador del Proyecto de Software.

*.5. E'TIMA"I# $EL P%#&E"T# $E '#!T(A%E.
En el principio el costo del Software constitu'a un peue*o porcentaje del costo total de los
sistemas basados en !omputadoras. ,oy en d'a el Software es el elemento mas caro de la
mayor'a de los sistemas inform&ticos.
7n gran error en la estimacin del costo puede ser lo ue marue la diferencia entre beneficios
y perdidas, la estimacin del costo y del esfuerzo del software nunca ser& una ciencia e"acta,
son demasiadas las variables0 humanas, t#cnicas, de entorno, pol'ticas, ue pueden afectar el
costo final del software y el esfuerzo aplicado para desarrollarlo.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles0
.eje la estimacin para mas adelante 3obviamente podemos realizar una estimacin al
cien por cien fiable despu#s de haber terminado el proyecto.
5ase las estimaciones en proyectos similares ya terminados.
7tilice t#cnicas de descomposicin relativamente sencillas para generar las
estimaciones de costos y esfuerzo del proyecto.
.esarrolle un modelo emp'rico para #l calculo de costos y esfuerzos del Software.
.esdichadamente la primera opcin, aunue atractiva no es pr&ctica.
+a Segunda opcin puede funcionar razonablemente bien si el proyecto actual es bastante
similar a los esfuerzos pasados y si otras influencias del proyecto son similares. +as opciones
restantes son m#todos viables para la estimacin del proyecto de software. .esde el punto de
vista ideal, se deben aplicar conjuntamente las t#cnicas indicadas usando cada una de ellas
como comprobacin de las otras.
Antes de hacer una estimacin, el planificador del proyecto debe comprender el &mbito del
software a construir y generar una estimacin de su tama*o.

*.5.* Estimaci0n basada en el Proceso.
Es la t#cnica m&s com$n para estimar un proyecto es basar la estimacin en el proceso ue se
va a utilizar, es decir, el proceso se descompone en un conjunto relativamente peue*o de
actividades o tareas, y en el esfuerzo reuerido para llevar a cabo la estimacin de cada tarea.
Al igual ue las t#cnicas basadas en problemas, la estimacin basada en el proceso comienza
en una delineacin de las funciones del software obtenidas a partir del &mbito del proyecto. Se
mezclan las funciones del problema y las actividades del proceso. !omo ultimo paso se
calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de software.

*.6. $I!E%ETE' M#$EL#' $E E'TIMA"I#.
E"isten diferentes modelos de estimacin como son0
*.6.* Los Modelos Emp7ricos:
.onde los datos ue soportan la mayor'a de los modelos de estimacin obtienen una muestra
limitada de proyectos. Por esta razn, el modelo de estimacin no es adecuado para todas las
clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos
de dichos modelos se deben utilizar con prudencia.

*.6.. El Modelo "#"#M#.
5arry 5oehm, en su libro cl&sico sobre econom'a de la (ngenier'a del Software, introduce una
jeraru'a de modelos de estimacin de Software con el nombre de !-!-6-, por su nombre
en (ngles 3!onstructive, !ost, 6odel4 modelo constructivo de costos. +a jeraru'a de modelos
de 5oehm esta constituida por los siguientes0
Modelo I. 'l (odelo &O&O(O b%sico calcula el esfuer)o y el costo del desarrollo de
*oftware en funcin del tama+o del pro"rama, expresado en las l-neas estimadas.
Modelo II. 'l (odelo &O&O(O intermedio calcula el esfuer)o del desarrollo de
software en funcin del tama+o del pro"rama y de un con.unto de conductores de
costos #ue incluyen la evaluacin sub.etiva del producto, del !ardware, del personal y
de los atributos del proyecto.

Modelo III. 'l modelo &O&O(O avan)ado incorpora todas las caracter-sticas de la
versin intermedia y lleva a cabo una evaluacin del impacto de los conductores de
costos en cada caso /an%lisis, dise+o, etc.0 del proceso de in"enier-a de *oftware.

*.6.1 3erramientas A,tom8ticas $e Estimaci0n.
+as herramientas autom&ticas de estimacin permiten al planificador estimar costos y
esfuerzos, as' como llevar a cabo an&lisis del tipo, ue pasa si, con importantes variables del
proyecto, tales como la fecha de entrega o la seleccin del personal. Aunue e"isten muchas
herramientas autom&ticas de estimacin, todas e"hiben las mismas caracter'sticas generales y
todas reuieren de una o m&s clases de datos.
A partir de estos datos, el modelo implementado por la herramienta autom&tica de estimacin
proporciona estimaciones del esfuerzo reuerido para llevar a cabo el proyecto, los costos, la
carga de personal, la duracin, y en algunos casos la planificacin temporal de desarrollo y
riesgos asociados.
En resumen el planificador del Proyecto de Software tiene ue estimar tres cosas antes de ue
comience el proyecto0 cuanto durara, cuanto esfuerzo reuerir& y cuanta gente estar&
implicada. Adem&s el planificador debe predecir los recursos de hardware y software ue va a
reuerir y el riesgo implicado.

Para obtener estimaciones e"actas para un proyecto, generalmente se utilizan al menos dos de
las tres t#cnicas referidas anteriormente. 6ediante la comparacin y la conciliacin de las
estimaciones obtenidas con las diferentes t#cnicas, el planificador puede obtener una
estimacin m&s e"acta. +a estimacin del proyecto de software nunca ser& una ciencia e"acta,
pero la combinacin de buenos datos histricos y t#cnicas puede mejorar la precisin de la
estimacin.































TEMA II.
AALI'I' $E 'I'TEMA' $E "#MP)TA"I#


















TEMA II. An8lisis de 'istemas de "omp,taci0n.
$E'A%%#LL#.
..* "onceptos y An8lisis:
Es un conjunto o disposicin de procedimientos o programas relacionados de manera ue
juntos forman una sola unidad. 7n conjunto de hechos, principios y reglas clasificadas y
dispuestas de manera ordenada mostrando un plan lgico en la unin de las partes. 7n
m#todo, plan o procedimiento de clasificacin para hacer algo. )ambi#n es un conjunto o
arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la
(nformacin. Esto se lleva a cabo teniendo en cuenta ciertos principios0
Debe presentarse y entenderse el dominio de la informacin de un problema.
Defina las funciones #ue debe reali)ar el *oftware.
Represente el comportamiento del software a consecuencias de acontecimientos
externos.
Divida en forma .er%r#uica los modelos #ue representan la informacin, funciones y
comportamiento.

El proceso debe partir desde la informacin esencial hasta el detalle de la (mplementacin.
La funcin del 1n%lisis puede ser dar soporte a las actividades de un ne"ocio, o desarrollar un
producto #ue pueda venderse para "enerar beneficios. Para conse"uir este ob.etivo, un
*istema basado en computadoras !ace uso de seis /20 elementos fundamentales3

*oftware, #ue son Pro"ramas de computadora, con estructuras de datos y su
documentacin #ue !acen efectiva la lo"-stica metodolo"-a o controles de
re#uerimientos del Pro"rama.
4ardware, dispositivos electrnicos y electromec%nicos, #ue proporcionan capacidad
de c%lculos y funciones r%pidas, exactas y efectivas /&omputadoras, &ensores,
ma#uinarias, bombas, lectores, etc.0, #ue proporcionan una funcin externa dentro de
los *istemas.
Personal, son los operadores o usuarios directos de las !erramientas del *istema.
5ase de Datos, una "ran coleccin de informaciones or"ani)adas y enla)adas al
*istema a las #ue se accede por medio del *oftware.
Documentacin, (anuales, formularios, y otra informacin descriptiva #ue detalla o da
instrucciones sobre el empleo y operacin del Pro"rama.
Procedimientos, o pasos #ue definen el uso especifico de cada uno de los elementos o
componentes del *istema y las re"las de su mane.o y mantenimiento.
)n An8lisis de 'istema se lle/a a cabo teniendo en c,enta los sig,ientes objeti/os en
mente:
Identifi#ue las necesidades del &liente.
'vale #ue conceptos tiene el cliente del sistema para establecer su viabilidad.
Realice un 1n%lisis $cnico y econmico.
1si"ne funciones al 4ardware, *oftware, personal, base de datos, y otros elementos
del *istema.
'stable)ca las restricciones de presupuestos y planificacin temporal.
&ree una definicin del sistema #ue forme el fundamento de todo el traba.o de
In"enier-a.

Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del
Hardware y el Software, as como de la ngeniera !umana "#anejo y Administraci$n de
%ersonal&, y administraci$n de base de datos'
... #bjeti/os del An8lisis.
....* Identificaci0n de ecesidades.
Es el primer paso del an&lisis del sistema, en este proceso en Analista se re$ne con el cliente
y8o usuario 3un representante institucional, departamental o cliente particular4, e identifican las
metas globales, se analizan las perspectivas del cliente, sus necesidades y reuerimientos,
sobre la planificacin temporal y presupuestal, l'neas de mercadeo y otros puntos ue puedan
ayudar a la identificacin y desarrollo del proyecto.

Algunos autores suelen llamar a esta parte ( Anlisis de )equisitos ( y lo dividen en cinco
partes0
Reconocimiento del problema.
'valuacin y *-ntesis.
(odelado.
'specificacin.
Revisin.

Antes de su reunin con el analista, el cliente prepara un documento conceptual del proyecto,
aunue es recomendable ue este se elabore durante la comunicacin !liente 9 analista, ya
ue de hacerlo el cliente solo de todas maneras tendr'a ue ser modificado, durante la
identificacin de las necesidades.

..... Est,dio de 9iabilidad.
6uchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el
tiempo no son realistas para su materializacin sin tener perdidas econmicas y frustracin
profesional. +a viabilidad y el an&lisis de riesgos est&n relacionados de muchas maneras, si el
riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce, sin embargo
se deben tomar en cuenta cuatro &reas principales de inter#s0


*' +iabilidad econ$mica'
7na evaluacin de los costos de desarrollo, comparados con
los ingresos netos o beneficios obtenidos del producto o
Sistema desarrollado.
,' +iabilidad -.cnica'
7n estudio de funciones, rendimiento y restricciones ue
puedan afectar la realizacin de un sistema aceptable.
/' +iabilidad 0egal'
Es determinar cualuier posibilidad de infraccin, violacin o responsabilidad legal en ue se
podr'a incurrir al desarrollar el Sistema.
Alternativas. 7na evaluacin de los enfoues alternativos del desarrollo del producto o Sistema.
El estudio de la viabilidad puede documentarse como un informe aparte para la alta gerencia.

....1 An8lisis Econ0mico y T:cnico.
El an&lisis econmico incluye lo ue llamamos, el an&lisis de costos 9 beneficios, significa una
valoracin de la inversin econmica comparado con los beneficios ue se obtendr&n en la
comercializacin y utilidad del producto o sistema.

6uchas veces en el desarrollo de Sistemas de !omputacin estos son intangibles y resulta un
poco dificultoso evaluarlo, esto varia de acuerdo a la caracter'sticas del Sistema. El an&lisis de
costos 9 beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del
Proyecto.
En el An&lisis )#cnico, el Analista eval$a los principios t#cnicos del Sistema y al mismo tiempo
recoge informacin adicional sobre el rendimiento, fiabilidad, caracter'sticas de mantenimiento
y productividad.

+os resultados obtenidos del an&lisis t#cnico son la base para determinar sobre si continuar o
abandonar el proyecto, si hay riesgos de ue no funcione, no tenga el rendimiento deseado, o
si las piezas no encajan perfectamente unas con otras.

....2 Modelado de la ar;,itect,ra del 'istema.
!uando ueremos dar a entender mejor lo ue vamos a construir en el caso de edificios,
,erramientas, Aviones, 6auinas, se crea un modelo id#ntico, pero en menor escala 3mas
peue*o4.
Sin embargo cuando auello ue construiremos es un Software, nuestro modelo debe tomar
una forma diferente, deben representar todas las funciones y subfunciones de un Sistema. +os
modelos se concentran en lo ue debe hacer el sistema no en como lo hace, estos modelos
pueden incluir notacin gr&fica, informacin y comportamiento del Sistema.
)odos los Sistemas basados en computadoras pueden modelarse como transformacin de la
informacin empleando una aruitectura del tipo entrada y salida.
....5 Especificaciones del 'istema.
Es un .ocumento ue sirve como fundamento para la (ngenier'a ,ardware, software, 5ase de
datos, e ingenier'a ,umana. .escribe la funcin y rendimiento de un Sistema basado en
computadoras y las dificultades ue estar&n presente durante su desarrollo. +as
Especificaciones de los reuisitos del software se produce en la terminacin de la tarea del
an&lisis.
En !onclusin un proyecto de desarrollo de un Sistema de (nformacin comprende varios
componentes o pasos llevados a cabo durante la etapa del an&lisis, el cual ayuda a traducir las
necesidades del cliente en un modelo de Sistema ue utiliza uno mas de los componentes0
Software, hardware, personas, base de datos, documentacin y procedimientos.





















TEMA III.
$I'E<# $E 'I'TEMA' $E "#M)TA"I#

TEMA III. $I'E<# $E 'I'TEMA' $E "#MP)TA"I=.
$E'A%%#LL#.
1.*. "onceptos y principios:
El .ise*o de Sistemas se define el proceso de aplicar ciertas t#cnicas y principios con el
propsito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para
permitir su interpretacin y realizacin f'sica.
+a etapa del .ise*o del Sistema encierra cuatro etapas0

1. 1l diseo de los datos.
)rasforma el modelo de dominio de la informacin, creado durante el
an&lisis, en las estructuras de datos necesarios para implementar el
Software.

,' 1l Diseo Arquitect$nico'
.efine la relacin entre cada uno de los elementos estructurales del
programa.

/' 1l Diseo de la nterfa2'
.escribe como se comunica el Software consigo mismo, con los
sistemas ue operan junto con el y con los operadores y usuarios ue
lo emplean.

3' 1l Diseo de %rocedimientos'
)ransforma elementos estructurales de la aruitectura del programa. +a importancia del .ise*o
del Software se puede definir en una sola palabra 4alidad, dentro del dise*o es donde se
fomenta la calidad del Proyecto. El .ise*o es la $nica manera de materializar con precisin los
reuerimientos del cliente.

El .ise*o del Software es un proceso y un modelado a la vez. El proceso de .ise*o es un
conjunto de pasos repetitivos ue permiten al dise*ador describir todos los aspectos del
Sistema a construir. A lo largo del dise*o se eval$a la calidad del desarrollo del proyecto con un
conjunto de revisiones t#cnicas0
El dise*o debe implementar todos los reuisitos e"pl'citos contenidos en el modelo de an&lisis
y debe acumular todos los reuisitos impl'citos ue desea el cliente.
.ebe ser una gu'a ue puedan leer y entender los ue construyan el cdigo y los ue prueban
y mantienen el Software.
El .ise*o debe proporcionar una completa idea de lo ue es el Software, enfocando los
dominios de datos, funcional y comportamiento desde el punto de vista de la (mplementacin.

Para evaluar la calidad de una presentacin del dise*o, se deben establecer criterios t#cnicos
para un buen dise*o como son0

6n dise+o debe presentar una or"ani)acin .er%r#uica #ue !a"a un uso inteli"ente del
control entre los componentes del software.
'l dise+o debe ser modular, es decir, se debe !acer una particin l"ica del *oftware
en elementos #ue realicen funciones y subfunciones especificas.
6n dise+o debe contener abstracciones de datos y procedimientos.
Debe producir mdulos #ue presenten caracter-sticas de funcionamiento
independiente.
Debe conducir a interfaces #ue redu)can la comple.idad de las conexiones entre los
mdulos y el entorno exterior.
Debe producir un dise+o usando un mtodo #ue pudiera repetirse se"n la informacin
obtenida durante el an%lisis de re#uisitos de *oftware.

'stos criterios no se consi"uen por casualidad. 'l proceso de Dise+o del *oftware exi"e buena
calidad a travs de la aplicacin de principios fundamentales de Dise+o, (etodolo"-a
sistem%tica y una revisin ex!austiva.

!uando se va a dise*ar un Sistema de !omputadoras se debe tener presente ue el proceso
de un dise*o incluye, concebir y planear algo en la mente, as' como hacer un dibujo o modelo o
crouis.

1... $ise>o de la 'alida.
En este caso salida se refiere a los resultados e informaciones generadas por el Sistema, Para
la mayor'a de los usuarios la salida es la $nica razn para el desarrollo de un Sistema y la base
de evaluacin de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben
realizar lo siguiente0
Determine #ue informacin presentar. Decidir si la informacin ser% presentada en
forma visual, verbal o impresora y seleccionar el medio de salida.
Dispon"a la presentacin de la informacin en un formato aceptable.
Decida como distribuir la salida entre los posibles destinatarios.

1.1. $ise>o de Archi/os.
(ncluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera
a emplear para guardar detalles de las transacciones, datos histricos, o informacin de
referencia. Entre las decisiones ue se toman durante el dise*o de archivos, se encuentran las
siguientes0
Los datos #ue deben incluirse en el formato de re"istros contenidos en el arc!ivo.
La lon"itud de cada re"istro, con base en las caracter-sticas de los datos #ue
conten"a.
La secuencia a disposicin de los re"istros dentro del arc!ivo /La estructura de
almacenamiento #ue puede ser secuencial, indexada o relativa0.

:o todos los sistemas reuieren del dise*o de todos los archivos, ya ue la mayor'a de ellos
pueden utilizar los del viejo Sistema y solo tenga ue enlazarse el nuevo Sistema al Archivo
maestro donde se encuentran los registros.

1.2. $ise>o de Interacciones con la ?ase de $atos.
+a mayor'a de los sistemas de informacin ya sean implantado en sistemas de cmputos
grandes o peue*os, utilizan una base de datos ue pueden abarcar varias aplicaciones, por
esta razn estos sistemas utilizan u administrador de base de datos, en este caso el dise*ador
no construye la base de datos sino ue consulta a su administrador para ponerse de acuerdo
en el uso de esta en el sistema.

1.5 3erramientas para el $ise>o de 'istemas.
Apoyan el proceso de formular las caracter'sticas ue el sistema debe tener para satisfacer los
reuerimientos detectados durante las actividades del an&lisis0

1.5.* 3erramientas de especificaci0n.
Apoyan el proceso de formular las caracter'sticas ue debe tener una aplicacin, tales como
entradas, Salidas, procesamiento y especificaciones de control. 6uchas incluyen herramientas
para crear especificaciones de datos.



1.5.. 3erramientas para presentaci0n.
Se utilizan para describir la posicin de datos, mensajes y encabezados sobre las pantallas de
las terminales, reportes y otros medios de entrada y salida.


1.5.1 3erramientas para el desarrollo de 'istemas.
Estas herramientas nos ayudan como analistas a trasladar dise*os en aplicaciones funcionales.

1.5.2 3erramientas para Ingenier7a de 'oftware.
Apoyan el Proceso de formular dise*os de Software, incluyendo procedimientos y controles, as'
como la documentacin correspondiente.

1.5.5 @eneradores de c0digos.
Producen el cdigo fuente y las aplicaciones a partir de especificaciones funcionales bien
articuladas.

1.5.6 3erramientas para pr,ebas.
Apoyan la fase de la evaluacin de un Sistema o de partes del mismo contra las
especificaciones. (ncluyen facilidades para e"aminar la correcta operacin del Sistema as'
como el grado de perfeccin alcanzado en comparacin con las e"pectativas.
+a revolucin del procesamiento de datos de manera computarizada, junto con las practicas de
.ise*o sofisticadas est&n cambiando de forma dram&tica la manera en ue se trasladan las
especificaciones de .ise*o d Sistemas de (nformacin funcionales.


1n 4onclusiones 5enerales' 'n una or"ani)acin o 'mpresa, el an%lisis y Dise+o de
*istemas, es el proceso de estudiar su *ituacin con la finalidad de observar como traba.a y
decidir si es necesario reali)ar una me.ora7 el encar"ado de llevar a cabo estas tareas es el
analista de sistemas.
1ntes de comen)ar con el desarrollo de cual#uier proyecto, se conduce un estudio de *istemas
para detectar todos los detalles de la situacin actual de la empresa. La informacin reunida
con este estudio sirve como base para crear varias estrate"ias de Dise+o. Los administradores
deciden #ue estrate"ias se"uir. Los 8erentes, empleados y otros usuarios finales #ue se
familiari)an cada ve) mas con el uso de computadoras est%n teniendo un papel muy
importante en el desarrollo de sistemas.

$odas las or"ani)aciones son *istemas #ue actan de manera reciproca con su medio
ambiente recibiendo entradas y produciendo salidas. Los *istemas #ue pueden estar formados
por otros *istemas de denominan *ub9sistemas y funcionan para alcan)ar los fines de su
Implantacin.
TEMA I9.
IMPLATA"I#A E9AL)A"I# & P%)E9A $E 'I'TEMA' $E "#MP)TA"I#


TEMA I9. IMPLATA"I#A E9AL)A"I# & P%)E9A'.
$E'A%%#LL#.
2.*. IMPLATA"I#. "oncepto y $efinici0n.
Es la ultima fase del desarrollo de Sistemas. Es el proceso instalar euipos o Software nuevo,
como resultado de un an&lisis y dise*o previo como resultado de la sustitucin o mejoramiento
de la forma de llevar a cavo un proceso automatizado.
Al (mplantar un Sistema de (nformacin lo primero ue debemos hacer es asegurarnos ue el
Sistema sea operacional o sea ue funcione de acuerdo a los reuerimientos del an&lisis y
permitir ue los usuarios puedan operarlo.
E"isten varios enfoues de (mplementacin0

's darle responsabilidad a los "rupos.
6so de diferentes estrate"ias para el entrenamiento de los usuarios.
'l 1nalista de *istemas necesita ponderar la situacin y proponer un plan de
conversin #ue sea adecuado para la or"ani)acin.

'l 1nalista necesita formular medidas de desempe+o con las cuales evaluar a los
6suarios.
Debe &onvertir f-sicamente el sistema de informacin anti"uo, al nuevo modificado.
En la preparacin de la (mplantacin, aunue el Sistema este bien dise*ado y desarrollado
correctamente su #"ito depender& de su implantacin y ejecucin por lo ue es importante
capacitar al usuario con respecto a su uso y mantenimiento.
2.;. !apacitacin de 7suarios del Sistema0
Es ense*ar a los usuarios ue se relacionan u operan en un proceso de implantacin.
+a <esponsabilidad de esta capacitacin de los 7suarios primarios y secundarios es del
Analista, desde el personal de captura de datos hasta auellos ue toman las decisiones sin
usar una !omputadora.
:o se debe incluir a personas de diferentes niveles de habilidad e intereses de trabajo= debido
a ue si en una Empresa e"isten trabajadores ine"pertos no se pueden incluir en la misma
seccin de los e"pertos ya ue ambos grupos uedaran perdidos.

>Es como uerer conducir dos 5arcos con diferentes destinos con un mismo 6apa de rutas o
con el mismo timn>.

Aun y cuando la Empresa puede contratar los Servicios de (nstructores e"ternos, el analista es
la persona ue puede ofrecer la mejor capacitacin debido a ue conoce el personal y al
Sistema mejor ue cualuier otro. A la falta o imposibilidad del analista la organizacin puede
contratar otros servicios de capacitacin como son0

:endedores3 *on a#uellos #ue proporcionan capacitacin "ratuita fuera de la 'mpresa
de uno o dos d-as.
Instructor pa"ado externamente3 *on a#uellos #ue pueden ense+ar todo acerca de las
computadoras pero para al"unos usuarios esta no es una capacitacin necesaria.
Instructores en casa3 'st%n familiari)ados con el personal y pueden adecuar los
materiales a sus necesidades, pero le faltar-a experiencia en *istemas de Informacin
#ue es realmente la necesidad del usuario.

En nuestro pa's e"iste una ley institucional 3+ey 11? del 1? de Enero de 1@AB4 creado durante
el gobierno del Presidente Antonio Cuzm&n Dern&ndez llamada (:D-)EP, representante de los
trabajadores y empresarios en el &mbito de !apacitacin y entrenamiento, la cual Asesora y
brinda Sus servicios a las Empresas y Sus trabajadores.
2.1.* #bjeti/os de la "apacitaci0n:
Es lograr ue los usuarios tengan el .ominio necesario de las cosas b&sicas acerca de las
mauinarias y procesos ue se emplean para su operacin de manera eficiente y segura.

2.2. La E/al,aci0n del 'istema:
Se lleva a cabo para identificar puntos d#biles y fuertes del Sistema implantado. +a evaluacin
ocurre a lo largo de cualuiera de las siguientes cuatro dimensiones0


2.2.* E/al,aci0n operacional:
Es el 6omento en ue s# eval$a la manera en ue funciona el Sistema, esto incluye su
facilidad de uso, )iempo de respuesta ante una necesidad o proceso, como se adecuan los
formatos en ue se presenta la (nformacin, contabilidad global y su nivel de 7tilidad.


2.2.. Impacto #rgani4acional:
(dentifica y mide los beneficios operacionales para la Empresa en &reas tales como, Dinanzas
3!ostos, (ngresos y Canancias4, eficiencia en el desempe*o laboral e impacto competitivo,
(mpacto, rapidez y organizacin en el flujo de (nformacin interna y e"terna.
2.2.1 $esempe>o del $esarrollo.
Es la evaluacin del Proceso de desarrollo adecuado tomando en cuentas ciertos criterios
como, )iempo y esfuerzo en el desarrollo concuerden con presupuesto y est&ndares y otros
criterios de Administracin de Proyectos. Adem&s se incluyen la valoracin de los m#todos y
herramientas utilizados durante el desarrollo del Sistema.


2.5. Pr,eba de 'istemas.
.ependiendo del tama*o de la Empresa ue usara el Sistema y el riesgo asociado a su uso,
puede hacerse la eleccin de comenzar la operacin del Sistema solo en un &rea de la
Empresa 3como una Prueba piloto4, ue puede llevarse a cabo en un .epartamento o con una
o dos personas. !uando se implanta un nuevo sistema lo aconsejable es ue el viejo y el
nuevo funcionen de manera simultanea o paralela con la finalidad de comparar los resultados
ue ambos ofrecen en su operacin, adem&s dar tiempo al personal para su entrenamiento y
adaptacin al nuevo Sistema.
.urante el Proceso de (mplantacin y Prueba se deben implementar todas las estrategias
posibles para garantizar ue en el uso inicial del Sistema este se encuentre libre de problemas
lo cual se puede descubrir durante este proceso y levar a cabo las correcciones de lugar para
su buen funcionamiento.
.esdichadamente la evaluacin de Sistemas no siempre recibe la atencin ue merece, sin
embargo cuando se lleva a cabo de manera adecuada proporciona muchas informaciones ue
pueden ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones futuras.

5(5+(-C<AD(A
1n%lisis y Dise+o de *istemas
1utor3 4enry . ;ort! < 1bra!am *ilbersc!at)
*e"unda 'dicion.
'ditora (c 8raw 4ill
In"enier-a del *oftware
1utor3 Ro"er *. Pressman
&uarta 'dicion.
'ditora (c 8raw 4ill
'nciclopedia de $rminos de &omputacin
1utor3 Linda 8ail= >o!n &!ristie
'ditora3 P44, Pentice 4all


)rabajo realizado por0
Pedro !oncepcin :ova
!8 <espaldo EB de 6arzo F B;.
Azua, <ep$blica .ominicana.
)el#fono0 3AB@4 G;1 2B;H
5eeper 3AB@4 H;;/1H;B
Da"0 3AB@4 G;1 2B;H.
E/6ail0 p.concepcionIcodetel.net.do
,omepage0 http088window.to8concepcion.com.do