LABORATORIO DE SISTEMAS DE INFORMACIN

Pgina 1 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

CONTENIDO TEMTICO

UNIDA
D

TEMA

PG.

IV.

Desarrollo e Implantacin.

4.1.

Plan de Trabajo.
4.1.1. Implantacin.

3
3

4.2.

Capacitacin de Usuarios del Sistema.

4.2.1. Tipos de Capacitacin.
4.2.2. Mtodos de Capacitacin.
4.2.3. Tiempo de Conversin a Utilizar.

4
4
5
7

4.3.

Manual de Instalacin Detallada.

4.4.

Mantenimiento y Robustez del Sistema.

Pgina 2 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

DESARROLLO E IMPLANTACIN.
4.1. PLAN DE TRABAJO.
Consiste en determinar los objetivos del proyecto, las posibles alternativas y las restricciones. Esta fase
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.
Durante esta etapa se lleva a cabo el anlisis de riesgos, se definen los recursos necesarios para desarrollar
el software y se establecen las estimaciones de tiempo y costos. El propsito de esta etapa de planificacin
es proporcionar una indicacin preliminar de la viabilidad del proyecto de acuerdo con el costo y con la
agenda que se hayan establecido. Posteriormente, la gestin del proyecto durante el desarrollo del mismo
realiza y revisa el plan de proyecto de software.
4.1.1. IMPLANTACIN.
Es la ltima fase del desarrollo de Sistemas. Es el proceso de instalar equipos o Software nuevo, como
resultado de un anlisis y diseo previo como resultado de la sustitucin o mejoramiento de la forma de
llevar a cabo un proceso automatizado.
Al Implantar un Sistema de Informacin lo primero que debemos hacer es asegurarnos que el Sistema sea
operacional o sea que funcione de acuerdo a los requerimientos del anlisis y permitir que los usuarios
puedan operarlo.
Existen varios enfoques de Implementacin:
Es darle responsabilidad a los grupos.
Uso de diferentes estrategias para el entrenamiento de los usuarios.
El Analista de Sistemas necesita ponderar la situacin y proponer un plan de conversin que sea
adecuado para la organizacin.
El Analista necesita formular medidas de desempeo con las cuales evaluar a los Usuarios.
Debe Convertir fsicamente el sistema de informacin antiguo, al nuevo modificado.
En la preparacin de la Implantacin, aunque el Sistema este bien diseado y desarrollado correctamente su
xito depender de su implantacin y ejecucin por lo que es importante capacitar al usuario con respecto a
su uso y mantenimiento.

Pgina 3 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

4.2. CAPACITACIN DE USUARIOS DEL SISTEMA.
Es ensear a los usuarios que se relacionan u operan en un proceso de implantacin.
La responsabilidad de esta capacitacin de los Usuarios Primarios y Secundarios es del Analista, desde
el personal de captura de datos hasta aquellos que toman las decisiones sin usar una Computadora.
No se debe incluir a personas de diferentes niveles de habilidad e intereses de trabajo; debido a que si en
una Empresa existen trabajadores inexpertos no se pueden incluir en la misma seccin de los expertos ya
que ambos grupos quedaran perdidos.
Aun y cuando la Empresa puede contratar los Servicios de Instructores externos, el analista es la persona
que puede ofrecer la mejor capacitacin debido a que conoce el personal y al Sistema mejor que cualquier
otro. A la falta o imposibilidad del analista la organizacin puede contratar otros servicios de capacitacin
como son:
Vendedores: Son aquellos que proporcionan capacitacin gratuita fuera de la Empresa de uno o dos
das.
Instructor pagado externamente: Son aquellos que pueden ensear todo acerca de las computadoras
pero para algunos usuarios esta no es una capacitacin necesaria.
Instructores en casa: Estn familiarizados con el personal y pueden adecuar los materiales a sus
necesidades, pero le faltara experiencia en Sistemas de Informacin que es realmente la necesidad del
usuario.
El Objetivo de los Usuarios, es lograr que los usuarios tengan el dominio necesario de las cosas bsicas
acerca de las maquinarias y procesos que se emplean para su operacin de manera eficiente y segura.
En nuestro pas existe una ley institucional (Ley 116 del 16 de Enero de 1980) creado durante el gobierno del
Presidente Antonio Guzmn Fernndez llamada INFOTEP, representante de los trabajadores y empresarios
en el mbito de Capacitacin y entrenamiento, la cual Asesora y brinda Sus servicios a las Empresas y Sus
trabajadores.
4.2.1. TIPOS DE CAPACITACIN.
Capacitacin de Operadores y Usuarios para Operar el Sistema
En algunos casos los sistemas de las compaas de ms prestigio pueden tener xito o fracasar debido
a la forma en que se operan y se usan. Como consecuencia la calidad de capacitacin recibida por el
personal manipular el sistema ayuda u obstruye, y puede llegar a impedir, la implantacin exitosa de
un sistema de informacin.
Aquellas personas que se encuentren asociadas o afectadas por el sistema deben conocer cul es su papel,
cmo pueden usar el sistema y qu har o no har el sistema. Tanto operadores como los usuarios del
sistema requieren de capacitacin.
Capacitacin de operadores. La mayora de los sistemas dependen del personal de Centro de
Cmputo, el cual es el encargado de mantener los equipos de cmputo funcionando, as como de
proporcionar el apoyo necesario.
La capacitacin que el personal reciba debe de asegurar que puedan manejar todas las operaciones
posibles, tanto rutinarias como extraordinarias.

Pgina 4 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

La capacitacin que reciba el operador tambin debe contemplar al personal de captura de datos.
Si el sistema requiere de la instalacin de equipo nuevo, el personal debe ser capacitado en lo necesario
para encender y apagar el equipo, as como conocimiento de lo que es su operacin y su uso normal.
Como parte de la capacitacin se le debe dar al personal una lista de formas de resolver los problemas y
que identifique los posibles problemas y solucin, as como datos personales de las personas a quin
buscar cuando surjan problemas inesperados.
Capacitacin de usuarios. La capacitacin de usuarios incluye la identificacin de problemas,
determinando si el problema que surge es ocasionado por hardware o por software, o por algo realizado
por los mismos usuarios que ocasione la falla del sistema.
No hay nada ms desesperante que trabajar con un sistema y que suceda un problema y no ser capaz
de determinar si es falla del propio sistema, del equipo o de los usuarios. El lugar para prevenir estos
casos es durante la capacitacin. La mayor parte de la capacitacin de los usuarios tiene que ver con la
operacin del sistema en s. La capacitacin en la codificacin de los datos marca la pauta en el proceso
de captura a partir de las transacciones, o en la preparacin de datos necesarios para las actividades de
apoyo a las decisiones.
Las actividades de manipulacin de los datos que recibe la mayor atencin en la capacitacin de
usuarios son la captura de datos (Cmo modificar datos previamente almacenados), la formulacin de
consultas (Cmo localizar informacin especfica u obtener respuestas a preguntas) y el borrados de los
registros de datos. La parte fundamental de la capacitacin cae sobre esta actividad dedicndose la
mayor parte del tiempo a esta rea.
En algunos casos los usuarios tienen que tener conocimiento de la operacin bsica de algunos
perifricos tales como una impresora, en donde deben tener el conocimiento de como colocar el papel
cambiar la cinta de la impresora, as como otros procesos rutinarios como mantener limpio el equipo, y
adems del conocimiento para la manipulacin de los discos como es formatear y probar discos.
En la capacitacin de usuarios se debe tomar en cuenta dos aspectos importantes mencionados
anteriormente los cuales consisten en la familiarizacin con el sistema de procesamiento en s (es decir,
el equipo usado para la captura y procesamiento de datos) y la capacitacin en el uso de la aplicacin
(es decir, el software que acepta los datos, los procesa y produce los resultados). La debilidad de
cualquier aspecto de la capacitacin puede ser una posibilidad para la generacin de errores. Una buena
documentacin, aunque es importante, no reemplaza la capacitacin.
4.2.2. MTODOS DE CAPACITACIN.
La capacitacin a operadores y usuarios se puede manifestar de diferentes formas. Las actividades de
capacitacin se pueden llevar a cabo en las instalaciones de los proveedores, locales rentados como
podra ser el caso de hoteles y Universidades, en casa, o en las instalaciones de la empresa. Los
mtodos y contenido de la capacitacin varia de acuerdo a la fuente y del lugar de la capacitacin
Instalacin y Pruebas del Usuario para Aceptacin del Sistema. En la instalacin y prueba del usuario,
son algunas actividades que realiza el usuario con el fin de verificar el sistema si funciona con el
hardware diferente al hardware de desarrollo, as como su instalacin y funcionamiento en general, en
esta etapa se abarcan cuatro aspectos importantes :
La Prueba de Entrada que implica ver si las formas electrnicas y las de papel as como la estructura
de codificacin cumplen con las guas y especificaciones de diseo, tambin se hacen una Autoprueba
a los usuarios finales del sistema para saber si estn llenando correctamente las formas. Al efectuar
estas pruebas se supone que el usuario ya recibi capacitacin y en ella se les enseo como llenar los
formatos. Las pruebas en esta etapa consisten en determinar si fueron capacitados correctamente.
Pgina 5 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

Muchas organizaciones contratan personas cuya nica funcin es capturar datos siendo de gran
importancia en una capacitacin adecuada para la captura de datos.
La Prueba de Salida, en la mayora de estas pruebas son un subproducto de la prueba de otros
componentes estructurales. Por ejemplo, mientras se prueban la entrada y las bases de datos, se revisa
la utilidad y exactitud de la salida resultante.
Una prueba de salida no es otra cosa que la generacin de un reporte, su entrega al usuario y
determinar si satisface las necesidades de informacin. Una buena forma de llevar a cabo la prueba de
salida consiste en entregar un reporte a una persona no familiarizada con el sistema, si esta persona
puede explicar el reporte, entonces probablemente el formato puede ser entendido por los usuarios.
Prueba de la base de datos. Las pruebas importantes para determinar si las bases de datos satisfacen
las necesidades de los usuarios, en gran medida, es la prueba de salida. Sin embargo se pueden llevar
a cabo pruebas adicionales para asegurarse que las bases de datos contengan la informacin que
satisfaga todas las demandas que se le plantean.
Incluyendo pruebas tales como la creacin de un nuevo registro antes del primer registro en el archivo
maestro, la creacin de un nuevo registro despus del ltimo, la creacin de un registro de un
departamento que no existe, intentar leer o escribir en un archivo con el disco fuera de la unidad (en el
caso de sistemas en unidades flexibles).
Prueba de los controles. El propsito primordial de la prueba de controles es asegurar que estos se
encuentren en su lugar y trabajen segn se plane. Las transacciones de prueba ayudan a asegurar que
los controles de procesamiento, como las verificaciones de lmite y racionalidad, la prueba aritmtica y la
identificacin estn en su lugar funcionando correctamente. Algunas pruebas de control que
normalmente se realizan son :
Tratar de leer o escribir en un archivo incorrecto.
Introducir varios campos con datos incompletos o faltantes.
Tratar de procesar una transaccin delicada sin la autorizacin apropiada y ver si el sistema lo
rechaza.
Hacer verificaciones de caracteres numricos, alfabticos y especiales, por ejemplo en la captura de
una clave se debern introducir nicamente valores numricos, en donde se deben introducir valores
alfabticos. Una verificacin que funcione correctamente detectar el error antes de realizar el
procesamiento.
Hacer verificaciones de lmite y racionalidad, por ejemplo: Un docente no puede tener ms de 40
horas en una jornada al da, se probar introduciendo valores que excedan la jornada de un da.
Realizar verificaciones de validez de campos clave, por ejemplo: introducir una clave invlida y ver
como responde el sistema.
Introducir en un campo numrico valores negativos y ver si lo acepta como tal, o los efectos que
ocasiona.
Las pruebas de los controles incluyen tambin una revisin de la documentacin que aparece en los
reportes del desarrollo de sistemas. Despus de que el usuario considera que el software pas las
pruebas, deber llevarse a cabo una reunin de aceptacin, a la que asista el gerente de operaciones de
sistemas, el analista de sistemas y el personal usuario.
En este momento se le da terminacin oficial del proyecto de desarrollo obteniendo as la clausura final
de sistemas, es entonces cuando el equipo de desarrollo queda libre para otra tarea o para disear o
implementar algunas de las solicitudes y sugerencias de mejora del sistema que fueron suspendidas
anteriormente.

Pgina 6 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

4.2.3. TIEMPO DE CONVERSIN A UTILIZAR.
El Estudio de Tiempo, es una tcnica para determinar con la mayor exactitud posible, partiendo de un
nmero de observaciones, el tiempo para llevar a cabo una tarea determinada con arreglo a una norma de
rendimiento preestablecido.
Conversin. Consiste en el cambio del sistema anterior con el sistema nuevo, as como los mtodos para
llevarla a cabo y verificacin de que la conversin se haya efectuado correctamente.
Existen cuatro mtodos para efectuar una conversin en un sistema, en donde cada mtodo tiene ventajas y
desventajas entre los mismos. Es conveniente mencionar que algunos mtodos de conversin se ajustan
perfectamente a problemas planteados, en donde nos es conveniente aplicar otro mtodo debido a que los
posibles resultados sean ampliar los periodos de conversin, situacin que puede crear problemas con los
usuarios y los analistas.
Sistemas paralelos. Este mtodo es un modelo seguro, ya que el sistema nuevo funciona al mismo
tiempo que el sistema anterior; debido a que si encuentran fallas en el sistema nuevo, el anterior
permanece en constante funcionamiento sin perdidas de tiempo, ni de informacin.
Una desventaja muy notable es que este mtodo de conversin es muy costoso ya que se duplican los
recursos humanos como materiales para trabajar en forma paralela ambos sistemas duplicando as los
costos de operacin.
Conversin directa. El sistema anterior ser reemplazado por el nuevo sistema, ya que la organizacin
confa plenamente en el nuevo sistema. Obligando as a los usuarios a que hagan funcionar al nuevo
sistema encontrando en l nuevos mtodos y controles.
En caso de encontrar errores no existe un sistema que lleve un respaldo de seguridad en las
operaciones, este mtodo ocasiona una planeacin ms cuidadosa.
Enfoque piloto. En este mtodo se implanta el nuevo sistema en una parte de la organizacin. Con
base a retroalimentacin se hacen cambios y el sistema se instala en el resto de la organizacin
mediante algunos otros mtodos, esto en gran medida proporciona experiencia y prueba directa antes
de la implantacin.
Ocasionando la desventaja de que el nuevo sistema puede dar la impresin de que el nuevo sistema no
es confiable, ni est libre de errores.
Conversin por etapas. Se implanta el nuevo sistema de manera gradual, reemplazando partes del
sistema anterior, permitiendo a los primeros usuarios aprovechar las ventajas del nuevo sistema, as
como la capacitacin de los mismos, llevando a cabo la instalacin de una nueva etapa una vez que fue
aceptada sin hacer uso necesario de recursos extras.
Plan De Conversin
El plan de conversin incluye una lista de actividades para llevar a acabo la implantacin del nuevo
sistema y ponerlo en operacin. En l se identifica a las personas responsables de cada actividad, as
como un programa de actividades para dar seguimiento a cada una de estas etapas.
El plan de conversin debe prevenir los posibles problemas y la forma de enfrentarlos implementando planes
de emergencia adecuados. Algunos problemas que se presentan comnmente son:
Documentos perdidos
Variacin entre datos de los formatos nuevos y anteriores
Pgina 7 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

Errores en la conversin de datos
Extravo de datos o prdida de archivos
Omisin en algunos pasos de la conversin
Durante la conversin se deben considerar diversos aspectos, desde la instalacin del equipo hasta el orden
de las formas y los suministros. Algunas actividades de conversin comienzan realmente desde que un
sistema se est desarrollando, as como contactar proveedores.
Acondicionamiento de las Instalaciones
Frecuentemente los analistas trabajan con el personal de los proveedores para definir el
acondicionamiento de las instalaciones. El cliente o el ingeniero de sistemas presentar una lista de
especificaciones para el cableado elctrico y los contactos, necesidades de aire acondicionado,
controles de humedad y exigencias de espacio, lo ms recomendable es tener el local antes de la
llegada del equipo.

4.3. MANUAL DE INSTALACIN DETALLADA.

El objetivo de este paso es elaborar el Manual de Instalacin.
Una copia de cada manual debe quedar en poder del Equipo de Proyecto para que se incorpore a la Carpeta
del Sistema.
En una lista de factores de calidad del software, uno podra esperar encontrar la presencia de buena
documentacin como parte de los requerimientos. Pero este no es un factor de calidad separado; sino que la
necesidad de documentacin es una consecuencia de los otros factores que intervienen en el anlisis y
desarrollo de sistemas. Se puede distinguir entre tres especies de documentacin:
La necesidad de documentacin externa, la cual permite a los usuarios entender el poder del sistema y
usarlo convenientemente, es una consecuencia de la definicin de facilidad de uso.
La necesidad de documentacin interna, la cual permite a los desarrolladores de software entender la
estructura y la implementacin del sistema, es una consecuencia del requerimiento de extensibilidad.
La necesidad de documentacin de interfaz de mdulo o subsistema, permite a los desarrolladores de
software entender las funciones provedas por un mdulo o subsistema sin tener que entender su
implementacin, es una consecuencia del requerimiento de reutilizacin. Tambin fluye del factor de
extensibilidad, ya que la documentacin de la interfaz de subsistema hace posible determinar si un cierto
cambio afecta a otros mdulos.
En vez de tratar a la documentacin como un producto por separado del software, es preferible hacer
software tan auto-documentable como sea posible. Esto aplica a los tres tipos de documentacin:
Incluir ayuda en lnea facilita y reafirma convenios claros y consistentes para la interfaz al usuario, se
mitiga la tarea de los autores de manuales de usuario y otras formas de documentacin externa.
Un buen lenguaje de implementacin disminuye la necesidad de documentacin interna si favorece la
claridad y estructura del software. Este es uno de los requerimientos para la notacin del mtodo
orientado a objetos.

Pgina 8 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

La notacin deber soportar encapsulamiento (ocultamiento de informacin) y otras tcnicas (tales
como afirmaciones, assertions) para separar la interfaz de los mdulos de su implementacin. As, es
posible usar herramientas para producir automticamente la documentacin de interfaz de mdulos a
partir del cdigo fuente.

Pgina 9 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

Estas tcnicas disminuyen el rol de la documentacin tradicional, aunque por supuesto no podemos esperar
que lo eliminen por completo.

4.4. MANTENIMIENTO Y ROBUSTEZ DEL SISTEMA.

Mantenimiento
El software sufrir cambios a lo largo de su vida til. Estos cambios pueden ser debidos a tres causas:
Que, durante la utilizacin, el cliente detecte errores en el software: los errores latentes.
Que se produzcan cambios en alguno de los componentes del sistema informtico: por ejemplo cambios
en la mquina, en el sistema operativo o en los perifricos.
Que el cliente requiera modificaciones funcionales (normalmente ampliaciones) no contempladas en el
proyecto.
En cualquier caso, el mantenimiento supone volver atrs en el ciclo de vida, a las etapas de codificacin,
diseo o anlisis dependiendo de la magnitud del cambio.
El modelo en cascada, a pesar de ser lineal, contiene flujos que permiten la vuelta atrs. As, desde el
mantenimiento se vuelve al anlisis, el diseo o la codificacin, y tambin desde cualquier fase se puede
volver a la anterior si se detectan fallos. Estas vueltas atrs no son controladas, ni quedan explcitas en el
modelo, y este es uno de los problemas que presenta este paradigma
La lista de factores no incluye una cualidad que a menudo es citada: mantenibilidad. Para entender porque,
veamos ms de cerca la nocin bsica: mantenimiento.
El mantenimiento es lo que se hace despus de que un producto de software ha sido entregado . Las
discusiones de mtodos de software tienden a enfocarse en la fase de desarrollo; as tambin los cursos
bsicos de programacin. Sin embargo, esta ampliamente estimado que el 70% de los costos del software
esta dedicado al mantenimiento. Cualquier estudio acerca de la calidad del software estara incompleto si
desatiende este aspecto.
Que significa el mantenimiento para el software? Si reflexionamos por un minuto vemos que este
trmino esta equivocado: un producto de software no se desgasta por el uso continuo, y por lo tanto no
necesita ser mantenido en la forma que un automvil recibe servicios de mantenimiento.
En la prctica, la palabra es usada por la gente de desarrollo para describir algunas nobles y otras no tan
nobles actividades. La parte noble es modificacin: tanto como las especificaciones de los sistemas
cambien, reflejando los cambios en el mundo externo, as tambin lo harn los sistemas. La parte no tan
noble es la post-depuracin: eliminando errores que, en primer lugar, nunca deberan haber estado all.
Ms del 42% de los costos estn dedicados a las extensiones y modificaciones solicitadas por el usuario.
Esto es lo llamamos la parte noble del mantenimiento, la cual es una parte inevitable. La pregunta an sin
respuesta es cuanto del costo total en mantenimiento se podra ahorrar una compaa si construyera su
software con ms preocupacin por la extensibilidad desde el principio. Tenemos pruebas de que el mtodo
orientado a objetos puede ayudar.
El siguiente aspecto en orden decreciente de costo en porcentaje es particularmente interesante: el efecto
de los cambios en el formato de los datos. Cuando cambia la estructura fsica de los archivos y otras piezas
de datos, los programas tienen que ser adaptados.

Pgina 10 de 11

LABORATORIO DE SISTEMAS DE INFORMACIN

En algunas organizaciones el clamor generalizado es: gran parte de nuestro presupuesto esta dedicado a
costos de mantenimiento de sistemas, nada nuevo es creado, ninguna ayuda o apoyo a las nuevas
estrategias de negocio que harn frente a la feroz competencia en el mercado; ! Las reas de informtica no
estn ayudando mucho!
Robustez
Robustez es la habilidad de los sistemas de software para reaccionar apropiadamente a las
condiciones anormales
Robustez complementa la exactitud. Exactitud tiene que ver con la conducta del sistema cubierta por su
especificacin; Robustez caracteriza que sucede fuera de dicha especificacin.

ESPECIFICACION
Exactitud
Robustez

Robustez es una nocin ms difusa por naturaleza como lo muestra su definicin. Debido a que lo que nos
concierne aqu son los casos que no estn cubiertos por la especificacin, no es posible decir, como en la
exactitud, que el sistema realizar sus tareas en tales casos; una vez que estas tareas son conocidas, el
caso anormal se convierte en parte de la especificacin y regresaramos al terreno de la exactitud.
Esta definicin de caso anormal es til cuando se estudia el manejo de excepciones. Implica que las
nociones de casos normales y anormales son siempre relativos a cierta especificacin; un caso anormal
es simplemente un caso que no esta cubierto por la especificacin. Si amplias la especificacin, los
casos anormales se convierten en casos normales, an si dicho evento es una entrada errnea por parte
del usuario. Normal en este sentido no significa deseable, sino simplemente considerar su
ocurrencia en el diseo del software.
Aunque de entrada puede parecer paradjico que errores de tecla debieran ser llamados casos
normales pero de otra forma habra que depender de criterios subjetivos y podran ser intiles.
Siempre habr casos que la especificacin no incluye explcitamente. El rol del requerimiento de robustez es
asegurar que si esos casos surgen, el sistema no causar eventos catastrficos; deber producir mensajes
de error apropiados, terminar su ejecucin adecuadamente, o entrar en un modo elegantemente reducido.

Pgina 11 de 11