1

CICLO DE VIDA DE DESARROLLO DE SISTEMA (CVDS)

Asumir el reto de desarrollar e implantar un sistema de informacin es una tarea compleja que involucra
muchas fases distintas, cada una de las cuales con frecuencia debe ser completada antes de que se pueda
comenzar una tarea subsiguiente, as para crear sistemas de informacin exitosos fue desarrollado el ciclo de
vida del desarrollo de sistemas (CVDS) que es el conjunto de fases o actividades que realizan los
analistas, diseadores, programadores y usuarios finales para desarrollar e implantar un sistema de
informacin.
Se puede decir, que el CVDS es un proceso por el cual los analistas de sistemas, los ingenieros de software,
los programadores y los usuarios finales, se relacionan y estudian la situacin actual con el objetivo de
elaborar un sistema de informacin o alguna aplicacin informtica; en todo caso se trata de una herramienta
de gestin de proyectos que planea, ejecuta y controla los proyectos de desarrollo de sistema.
En trminos generales el grupo de analistas, diseadores y programadores enfrentan el escenario de resolver
un problema para un grupo de usuarios finales, donde los miembros del departamento de sistemas lo
denominan genricamente con el nombre Proyecto.
Fase 1----
Investigacin Preliminar: comienza con la solicitud por parte de la gerencia, la
administracin, un grupo de usuarios o los especialistas de sistemas en mejorar un proceso, aplicar una
norma o aprovechar una oportunidad para mejorar la organizacin, sin importar cual sea el origen de la
solicitud el proceso se inicia.
Cuando se formula la solicitud comienza la primera fase del CVDS, la esta conformada por:
a) Aclaracin de la solicitud
b) Estudio de factibilidad
c) Aprobacin de la solicitud.
a) Aclaracin de la solicitud: Antes de considerar el desarrollo de un sistema es necesario
precisar: qu desea o aspira el usuario?, pues muchas peticiones que provienen de obreros,
supervisores, gerentes y administradores no estn formuladas de manera clara, pero
representan la voz de la organizacin y sus problemas; por consiguiente, antes de considerar
el desarrollo de cualquier proyecto de sistema es necesario que la solicitud se examine con
detenimiento, para ir estableciendo los limites del mismo.

b) Estudio de factibilidad: El desarrollo de un sistema de Informacin suele ser caro, as antes de

iniciar cualquier proyecto se debe hacer un estudio de viabilidad; que es una investigacin
rpida de los planes, problemas, las oportunidades o las normas que desencadenan y
permiten el desarrollo de este proyecto Whitten, Lonnie y Victor, (1996, 112).
El Estudio de Factibilidad lo lleva a cabo un pequeo equipo de personas que pertenecen a la
organizacin o asesores externos y que se vern afectados por el proyecto y que no debe durar
ms de 8 das hbiles. En la investigacin preliminar se estudian los siguientes aspectos:
b.1) Factibilidad Tcnica: Consiste en determinar si dentro o fuera de la organizacin existe la
tecnologa y el recurso humano capacitado para poder desarrollar el proyecto.

b.2) Factibilidad Econmica. Consiste en determinar si los costos de desarrollo e implantacin

del sistema se justifican en funcin de los beneficios que se obtienen; para esta fase por
lo general se desarrollan tablas de costo x beneficio

b.3) Factibilidad operacional: Consiste en determinar si los usuarios potenciales estn en

capacidad de usar apropiadamente el sistema, o cuanto tiempo se requerir para formar el
personal en el uso apropiado del nuevo sistema de informacin.

b.4) Factibilidad de Calendario: Consiste en dar respuesta a la siguientes pregunta:Puede la

solucin desarrollarse e implantarse en un plazo aceptable?, es decir, la construccin del
sistema puede desarrollarse en un tiempo razonable para recuperar la inversin y
satisfacer a los usuarios finales.

Al finalizar esta etapa el grupo de trabajo debe entregar un informe con todas las posibles
alternativas de solucin acompaadas con su estudio de factibilidad y el plan de desarrollo
correspondiente.
c) Aprobacin de la solicitud Consiste en que la alta gerencia administrativa despus de escuchar
el informe de factibilidad tome la decisin para continuar o no con el proyecto.
Aceptar la
recomendacin
Enmendar la
recomendacin
Devolver las
recomendaciones
Rechazar todos los
proyectos

En resumen en esta primera etapa el analista se involucra en al identificacin de los problemas y las
oportunidades que ofrece la empresa a nivel de desarrollo de sistemas de informacin. En muchas
ocasiones la empresa ya tiene detectadas sus reas dbiles y se llama al analista ya con ciertos
objetivos previstos. Esta etapa es crtica, ya que nadie desea perder el tiempo resolviendo el problema
equivocado.

4
1. Determinacin de Requerimientos: Despus de realizar la investigacin preliminar, el analista
tiene que plantear los requerimientos del usuario para el nuevo sistema; es decir, las necesidades y
caractersticas que deber cubrir el nuevo sistema.
Para identificar los requerimientos de informacin se utilizan varias tcnicas o herramientas como
los son documentos, la entrevista, los cuestionarios, etctera.
2. 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 de informacin.
3. Desarrollo de Software: Consiste en escribir los programas necesarios para el sistema. Los
programadores son responsables de la documentacin de los programas, que tambin se realiza
durante esta etapa, as como explicar el funcionamiento de los mismos y por qu ciertos
procedimientos se codifican de determinada forma.
La documentacin es importante ya que por medio de ella ser posible modificar o llevar a cabo el
mantenimiento del programa.

4. Prueba del sistema: Cada uno de los programas desarrollados es probado de tal manera que
funcione correctamente.
Durante esta fase el sistema es empleado en forma experimental para asegurarse que el software no
tiene fallas, se alimentan al sistema datos de entrada para su procesamiento y se examinan los
resultados obtenidos.
Es recomendable que las pruebas sean conducidas por personas ajenas a las que desarrollan el
software, con esto se busca que las pruebas sean completas e imparciales y que el software sea
confiable.
5.

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.
Dependiendo del tamao de la organizacin y del riesgo asociado al uso del nuevo sistema se puede
comenzar la operacin del sistema slo en un rea de la empresa.
Es recomendable que trabajen paralelamente el anterior sistema y el nuevo para comparar los
resultados obtenidos.
La evaluacin del sistema se lleva a cabo para identificar sus puntos dbiles y fuertes.
Aunque en algunas ocasiones este proceso de evaluacin no recibe la importancia que merece, si se
realiza de forma adecuada proporciona mucha informacin que puede ayudar a mejorar la
efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.

5
1.- Principios generales del Ciclo de Vida de Desarrollo de Sistemas (CVDS)
1.1.- Implicar al usuario: Es importante estar claro que el sistema a ser desarrollado le pertenece al usuario
del sistema, el analista es simplemente un experto en tecnologa de la informacin que viene a resolver
uno o varios problemas puntuales de procesamiento de informacin; comprometer al usuario permite
evitar errores en la construccin del sistema, adems que ayuda a vencer el miedo al cambio que toda
persona tiene al momento que un nuevo sistema es instalado, y siempre se debe recordar ellos son los
que pagan.

1.2.- Se deben Apoyar las actividades de la Organizacin: Toda organizacin debe tener una Visin y
Misin especfica, las cuales son su constante motivacin; as la Administracin es encargada de definir
las Polticas, Normas, Metas y Estrategias para cumplir con esos principios, de tal manera que cuando se
desarrollan los sistemas de informacin ellos se deben desarrollar para servir de apoyo a la alta gerencia
y a la toma de decisiones con lo cual se garantiza la productividad de la Organizacin.

1.3.- Aplicar un mtodo de resolucin de problemas: En el momento que el analista estudia la situacin
actual se encuentra con: normas, reglamentos, oportunidades, amenazas, actividades, personas,
documentos, es decir, el medio ambiente en general que rodea un sistema; para desarrollar una solucin
de sistemas en forma eficiente se debe usar un mtodo, con el cual se busca evitar que se pierdan
detalles en la construccin de un nuevo sistema; as El Ciclo de Vida de Desarrollo de Sistemas es ante
todo un mtodo para resolver problemas, que le permite al analista estudiar en detalle la situacin actual
y construir en detalle una solucin, el cual consta de las siguientes actividades:
1. Investigacin preliminar
2. Determinacin de los requerimientos del sistema
3. Diseo del sistema
4. Desarrollo de software
5. Prueba de los sistemas
6. Implantacin y evaluacin

En trminos generales dichas fases o actividades se pueden resumir en:

1. Anlisis
2. Diseo
3. Desarrollo de Software
4. Implantacin

Anlisis

Diseo

Desarrollo
de Software

Implantacin

SISTEMA DE INFORMACN o PROBLEMA

1.4.- Justificar los sistemas como una inversin de capital: Los sistemas de informacin son ante todo
una inversin de capital, pues los propietarios o la organizacin deben pagar: luz, agua, telfono,
personal, discos, hojas, etc...para su realizacin; es por ello que todo analista de sistemas debe plantearse
de ante un nuevo sistema:
Primero, para cualquier problema es probable que existan varias soluciones,
y segundo se debe evaluar la viabilidad de cada una de ellas.
El analista debe tener presente esas premisas, pues, ninguna organizacin invierte para no recoger esa
inversin a un corto o mediano plazo.

1.5.- Disear el sistema para el crecimiento: La vida til de un nuevo sistema debe ser visto como una
solucin a largo plazo, por lo tanto debe ser diseado para que progresivamente el sistema se vaya
adaptando a los cambios planteados por los usuarios a los datos, por ejemplo: ingresar nuevos productos,
cambiar el iva, cambiar niveles de seguridad, entre otros; de tal manera que se evite la entropa del
sistema.

2.- Anlisis: Es el estudio en detalle del sistema actual para conocer:

 Los procesos
 Las personas que los manejan
 Los controles
 Los documentos que se usan
 Los datos que usan
 La informacin que genera y su calidad
Y de esta forma poder definir donde efectuar mejoras al sistema; para poder lograr este objetivo se
deben cumplir las siguientes fases:
2.1. Investigacin Preliminar
2.2. Determinacin de requerimientos

8
2.1.- La Investigacin preliminar
2.2) Determinacin de los Requerimientos: La siguiente fase del anlisis consiste en conocer y
estudiar en detalle la situacin actual, para llegar a una compresin ms profunda de los
problemas, las normas, las oportunidades, las limitaciones, los procesos, los datos y todo el medio
ambiente en general del sistema actual. Los objetivos fundamentales de esta fase son:
 Conocer los procesos bsicos de la situacin actual
 Obtener el diccionario de datos de la situacin actual
 Definir las fortalezas, oportunidades, amenazas y debilidades del sistema actual (ANLISIS
DE LA SITUACIN ACTUAL)
 Determinar los Requerimientos ser incorporados en el sistema propuesto.
Aprender cmo funciona el sistema actual se requiere de la participacin activa de los propietarios,
los usuarios(Directos e Indirectos), pues incrementa su sentido de responsabilidad y propiedad del
sistema de informacin a ser desarrollado.
Para llegar a conocer el funcionamiento en detalle del sistema actual se usan por lo general los
Diagramas de Flujo de Datos (D.F.D.), que son modelos que muestran el flujo de los datos desde
que entran al sistema, son procesados, almacenados y finalmente se entrega informacin al
usuario para la toma de decisiones; paralelamente se estructura el diccionario de datos de la
situacin actual.
Para realizar los D.F.Ds. el analista conversa con varias personas para reunir detalles relacionados
con los procesos de la organizacin, sus opiniones sobre por qu ocurren las cosas, las soluciones
que proponen y sus ideas para cambiar el proceso; es decir, el analista hace uso de una o ms de las
siguientes tcnicas de investigacin de hechos:
 Elaboracin de Entrevistas
 Reunin y discusin en grupos
 Observacin
 Muestreo de archivos y formularios
 Encuestas y cuestionarios.
Al concluir este fase el analista debe tener:
1. Los Requerimientos del Nuevo sistema, es decir, un listado de todas las caractersticas o
Entradas/Salidas que deben ser incluidas en el nuevo sistema, entre las cuales se puede sealar:
 Como se capturan los datos
 Como se procesan los datos y que controles usan
 Cuales son los procesos
 Cual es el volumen y la frecuencia de los datos
 Cual es la frecuencia con la cual se genera un reporte
 Cuales son los niveles de acceso
2. El Diccionario de Datos del sistema Actual.
3. El Anlisis del Sistema Actual, es decir, un listado de las Fortalezas y Debilidades del
Sistema actual
a) Actividades de la Determinacin de Requerimientos:
a.1) Usar la Experiencia: Todo analista puede tener cierto grado de experiencia o contacto un
sistema similar al que se esta estudiando, y dicha referencia puede ser usada para:
 Establecer una mejor planificacin de proyectos

9





Anticipar problemas
Prever un caracterstica del nuevo sistema
Definir procesos, datos y controles mas rpido
Optimizar el tiempo

a.2) Determinar el objetivo del sistema: Consiste en definir especficamente cual es el

objetivo central del sistema a ser desarrollado, pues sin ello se puede llegar a divagar a tal
punto que el proyecto inicial se pierde.

Sistema
Actual

Objetivo(s)
del Sistema
Propuesto

a.3) Determinar los Requerimientos: Consiste en estudiar los hechos, los procesos, los datos,
los depsitos y las personas del sistema actual, a travs de algn modelo que represente el
sistema para definir cuales sern las caractersticas esenciales que deben ser incluidas en
el nuevo sistema.

10

b) Los Requerimientos son:

b.1) Bsicos: Son aquellas actividades o procesos indispensables que permiten cumplir con
los objetivos del sistema.

Datos

Proc 1.

Proc 2.

Proc 3.

Informacin

As POR CADA PROCESO BSICO se debe determinar lo siguiente:

 Nombre del Proceso: Consiste en estudiar en detalle cada una de las actividades
del proceso para especificar qu hace el proceso, cmo lo hace paso a paso y
donde guarda los datos y/o la informacin; dicho Nombre debe ser un verbo en
infinitivo claro, conciso y preciso, con el cual se identifica el proceso.
Se recomienda hacer las siguientes preguntas:
Cul es el nombre del proceso?
Cules son los pasos o actividades del proceso?
Dnde se realizan los pasos?
Quines realizan .los pasos?
Quines emplean la informacin resultante?
Con cunta frecuencia se realizan?

 Identificar que datos ingresan al proceso: Consiste en determinar que datos y/o
informacin utiliza el proceso para llevar a cabo sus actividades.
 Determinar que Informacin es generada: Consiste en determinar que datos
y/o Informacin da como resultado el proceso.

Datos

Proceso

Informacin

 Frecuencia: Se debe determinar el nmero de veces que se presenta el proceso en

el tiempo. Ejemplos: mensualmente, cada 15 das, cada tres meses, etc...

11

 Volumen: Consiste en determinar qu cantidad de unidades son procesadas.

Ejemplos: 15 solicitudes, 50 ventas, 70000 abonos, etc....

 Identificar los Controles empleados: Consiste en identificar los puntos donde se

establece un supervisin con los datos; en otras palabras, para establecer una
comparacin con una norma preestablecida, por ejemplo: validar que no ingresen
usuarios no autorizados, verificar que la cantidad vendida no supera la existen en
el inventario, garantizar que un usuario con un nivel de acceso no pueda modificar
los datos almacenados,.....
Por lo general se plantean las siguientes preguntas:
Existen estndares preestablecidos?
Quin se encarga de supervisar?
Cmo se detectan los errores?
Cada cuanto se presentan los errores?
Cmo se corrigen los errores?
Qu datos se originan de fuentes externas y por qu?
Cmo se presentan los errores?
Con qu detalle se desea el informe de los errores?
Cada cuanto y por qu se debe presentar un informe de errores?

12
b.2) De Decisin: A diferencia de las actividades de transaccin, las relacionadas con las
decisiones no siguen ningn procedimiento especfico; es mas, las decisiones siempre se
toman en base al resultado de los sistemas de transaccin, de all que entre mas seguros y
confiables sean, la alta gerencia toma decisiones mas confiable y acertadas. Ejemplo:
Cada vez que se debe iniciar un nuevo semestre se toman las estadsticas de los
aprobados y reprobados por seccin y materia, para con este dato y la cantidad de
alumnos por aula, el jefe de departamento decide crear las nuevas secciones. Al observar
este ejemplo se puede notar que para la creacin de una nueva seccin, el jefe de
departamento debe tener en sus manos buena cantidad de informacin para poder tomar
la decisin mas acertada, es decir crear la seccin con X cantidad de alumnos..
Se recomienda plantearse las siguientes preguntas:
Qu Informacin se usa para tomar decisiones?
Cul es la fuente de la informacin?
Qu sistema de transaccin produce la informacin que es usada en la toma de
decisiones y por qu?
Qu otros datos son necesarios y por qu?
Quin toma las decisiones y por qu?

b.3) De Organizacin: En las Organizaciones cada departamento, seccin, rea depende uno
de otro para brindar servicios o bienes a sus clientes, por consiguiente el trabajo de un
departamento afecta al de los dems. El analista de sistemas debe determinar cules son
los aspectos o elementos que produce el sistema actual y que afectan a otros
departamentos, para de esta forma buscar la manera de mejorar los procesos en toda la
organizacin.

Fase 1: Anlisis de Necesidades

Durante el anlisis de necesidades, la primera fase CVDS, el equipo se enfoca en completar tres tareas:
1. Definir el problema y decidir se ha de proceder.
2. Analizar el sistema actual, a fondo, y desarrollar posibles soluciones al problema.
3. Seleccionar la mejor solucin y definir su funcionalidad.
La fase 1 comienza cuando se identifica una necesidad para un sistema nuevo o modificado. Por ejemplo,
los usuarios podran quejarse de que el sistema actual es difcil de usar. Los procedimientos simples
requieren demasiados pasos, y el sistema se cae repetitivamente, con la consecuencia de una perdida de

13
informacin. Opcionalmente, un administrador se podra acercar de Informtica para pedir un reporte que
actualmente no es producido por el sistema.
Los analistas de sistemas comienzan entonces una investigacin preliminar, hablando con los usuarios y los
administradores del departamento afectado. El primer reto es definir el problema con precisin. Con el
problema exactamente definido, el departamento de Informtica puede decidir si va a tomar el proyecto(la
decisin de ir o no ir.
Cuando una decisin para proceder est tomada, los analistas de sistemas llevan acabo una investigacin
concienzuda del sistema actual y sus limitaciones. Trabajan con la gente directamente involucrada con el
problema para documentar cmo puede resolverse.
El conocimiento reunido en relacin al sistema actual se documenta de varias maneras diferentes. Algunos
analistas usan diagramas de flujo de datos, los cuales muestran flujo de informacin a travs del
sistema(VER GRAFICO DE EJEMPLO). Podran usar algoritmos estructurados para describir alternativas y
acciones del sistema actual. Otra opcin es presentar las acciones que se toman bajo diferentes condiciones
en un rbol de decisin(VER EJEMPLO). La representacin grfica es ms fcil de comprender que un a
lista. Con esta base, los analistas estn listos para considerar varias soluciones al problema. Podran llamar
cientficos de computacin del departamento de Informtica para ayudarlos a identificar distintos enfoques.
Cada uno es evaluado con base en las restricciones del proyecto, principalmente el presupuesto y el
calendario. Si se debe proporcionar una solucin rpidamente, el equipo del departamento de Informtica
podra considerar soluciones que fueran menos ideales, sin embargo, tiene la ventaja de un rpido cambio
de posicin.
Al finalizar la fase 1, equipo recomienda una solucin para ser adoptada. Los analistas usan la informacin
que ya reunieron con los usuarios del sistema para determinar qu caractersticas debe haber en la solucin
(Qu reportes deberan generarse, en qu forma sern emitidos y qu herramientas especiales se necesitan).
Mediante la fase de anlisis de necesidades, permanecen enfocados en qu debera hacer el sistema, no
cmo sern implementadas las caractersticas.
Fase 2: Diseo del sistema
Durante la segunda fase, Diseo del sistema, el equipo de proyecto encara el cmo de la solucin elegida.
Por ejemplo, una aplicacin de la base de datos debera ser capaz de aceptar informacin de los usuarios y
almacenarla. stas son funciones generales, pero Cmo las implementar el equipo? Por ejemplo, Cuntas
pantallas de entrada son necesarias y cmo se vern? Qu tipo de opciones de men debe haber? Qu
tipo de base de datos usar el sistema?
Los analistas y programadores involucrados hasta este punto, usan con frecuencia una combinacin de
diseo descendente y ascendente para responder esas preguntas. En el Diseo Descendente, el equipo
comienza con el panorama general y se va al detalle. Se ocupan de las funciones principales que el sistema
debe proporcionar y las dividen en actividades ms y ms pequeas. Cada una de estas actividades ser
programada en la siguiente fase CVDS.
En el Diseo Ascendente, el quipo comienza con los detalles ( Por ejemplo, los reportes que sern
producidos por el sistema) y entonces se dirigen al panorama general (las funciones o procesos principales).
Este enfoque es particularmente apropiado cuando los usuarios tiene requerimientos especficos para la
salida por ejemplo, cheques para pago de nmina, los cuales deben contener ciertas piezas de informacin-.
A travs de la fase 2, el administrador del equipo del proyecto revisa el progreso en el diseo de diferentes
componentes del sistema. Al final de la fase se lleva a cabo una revisin ms amplia, involucrado

14
normalmente al departamento que ser afectado y a la administracin superior. Si el diseo pasa la
inspeccin, el desarrollo comienza. En algunos casos la revisin pone de relieve problemas con la solucin
general, y el equipo debe regresar a analizar o terminar el proyecto.
Muchas herramientas estn disponibles para ayudar a los equipos a travs de los pasos del diseo de
sistemas. La mayora de estas herramientas tambin pueden usarse durante de la fase de desarrollo, o,
incluso, durante el anlisis. Por ejemplo, muchos equipos usan modelos de funcionamiento llamados
Prototipos para explorar la vista y percepcin de las pantallas en relacin con los usuarios. Tambin usan
aplicaciones de software especiales para crear esos prototipos rpidamente, as como para crear diagramas,
escribir cdigo y administrar el esfuerzo de desarrollo. Estas aplicaciones entran en la categora de
herramientas de ingeniera de software asistidas por computadora(CASE). En otras palabras, el
software de cmputo est usndose para desarrollar otro software de cmputo ms confiable y rpidamente.
Fase 3: Desarrollo del Software
Durante la fase de Desarrollo, los programadores juegan el papel clave, al crear o personalizar el software
para todas las varias partes del sistema. Normalmente, los programadores del equipo son asignados a
componentes especficos del sistema general. Si un componente est crendose, los programadores escriben
el cdigo necesario o usan herramientas CASE (Si es posible) para acelerar el proceso de desarrollo. Para
los componentes comprados, los programadores deben personalizar el cdigo segn sea necesario para hacer
que el componente encaje dentro del nuevo sistema.
Hay dos rutas alternativas a travs de la fase 3:La ruta de la adquisicin o la ruta del desarrollo local.
Tan temprano como la fase 1, anlisis de necesidades, el equipo del proyecto podra darse cuenta de que
algunos o todos los componentes necesarios del sistema estn disponibles como hardware o software a
nivel comercial, y deciden adquirirlos en vez de dedicarse a desarrollarlos. Adquirirlos componentes
comerciales significa que el sistema puede construirse ms rpido y barato que si cada componente debe
desarrollarse desde el principio. Otra ventaja de los componentes adquiridos es que ya se han puesto a
prueba y se ha demostrado que son confiables, a pesar de que podran necesitar ser personalizados para
encajar dentro del sistema general de informacin. En muchos casos, el equipo del proyecto de sistema
compran (o adquieren) algunos componentes y construyen (o desarrollan) otros. Por lo tanto, siguen las
rutas tanto de adquisicin como de desarrollo local a travs del CVDS al mismo tiempo.
Los redactores tcnicos trabajan con los programadores para producir la documentacin tcnica para el
sistema. La documentacin tcnica es sumamente distinta de la documentacin para el usuario, en ella se
describe a los usuarios finales cmo usar el sistema; en cambio, la documentacin tcnica incluye
informacin acerca de las caractersticas tcnicas del software y de la programacin, acerca del flujo de
informacin y del procesamiento a travs del sistema, y acerca del diseo y disposicin del hardware
necesario. Estos materiales proporcionan una vista general del sistema y, por lo tanto, sirven como una
referencia para los miembros del equipo enfocados en los componentes individuales. Adems, la
documentacin tcnica es vital para dar apoyo al personal y a los programadores a cargo del sistema durante
la fase de mantenimiento.
Otros redactores comienzan a trabajar con la documentacin para el usuario, y los arquitectos de asistencia
al usuario comienzan a plantear la arquitectura del sistema de ayuda en lnea. Estos esfuerzos normalmente
no son terminados hasta llegar a las primeras etapas de la fase de puesta en prctica.
Poner a prueba es una parte integral de las fases 3 y 4 (Desarrollo y puesta en prctica). El enfoque tpico de
poner a prueba es ir del componente individual hasta el sistema como un todo. El equipo de desarrollo del
proyecto prueba cada componente por separado (prueba de unidades) y entonces se ponen a prueba los

15
componentes del sistema con cada uno de los otros (Prueba del sistema). Los errores se corrigen, se
hacen, los cambios necesarios y las pruebas se llevan a cabo de nuevo. En seguida viene la prueba de la
instalacin, esto es, cuando el sistema es instalado en un ambiente de prueba y probado con otras
aplicaciones que use el negocio. Finalmente, se lleva a cabo una prueba de aceptacin, donde los usuarios
finales prueban el sistema instalado para asegurarse de que encaja con sus criterios.
Con frecuencia, los equipos de desarrollo del proyecto ponen a prueba sistemas o componentes de sistemas
con transacciones reales algunas veces llamados informacin viva- . Esto ayuda a asegurase de que el
sistema puede manejar el flujo de informacin esperado sobre una base diaria despus que le sistema se
pone en lnea. Sin embargo, los programadores tambin debieran probar el sistema con datos invlidos o
condiciones de excepcin. Por ejemplo, Qu pasa cuando un usuario teclea mal 1X33345 en vez de
1333345 dentro de un campo que solamente acepta informacin numrica? Este tipo de errores no debe
existir en los datos que se usan normalmente para probar el sistema, pero probablemente ocurrir cuando el
sistema sea usado por empleados reales.
:
Fase 4: Implementacin
En la fase de Implementacin, el equipo de desarrollo del proyecto terminara comprando el hardware
necesario para los usuarios del sistema e instala entonces el hardware y software en el ambiente del usuario.
Despus, los usuarios comienzan a usar el sistema para realizar trabajo, no slo para proporcionar
retroalimentacin en el desarrollo del sistema.
El proceso de cambiar del antiguo sistema al nuevo se llama conversin. Los profesionales de los sistemas
de informacin deben manejar cuidadosamente este proceso para evitar perder o corromper datos y frustrar
a los usuarios que tratan de realizar su trabajo. La conversin puede ser:
Conversin Directa: Todos los usuarios dejan de usar el sistema antiguo al mismo tiempo y
despus comienzan a usar el nuevo. Esta opcin es rpida, pero puede ser destructiva. Adems,
la presin sobre el personal de soporte puede resultar excesiva.
Conversin en paralelo: Los usuarios continan usando el sistema antiguo mientras que una
cantidad creciente de informacin es procesada mediante el nuevo sistema. Las salidas de los dos
sistemas son comparadas, y si estn de acuerdo se hace el cambio. Esta opcin es til para ms
pruebas reales del nuevo sistema, pero es muy desgastante porque ambos sistemas estn
operando al mismo tiempo.
Conversin en Fases: Los usuarios comienza a usar el nuevo sistema componente por
componente. Esta opcin slo funciona para sistemas que pueden ser divididos en
compartimientos o mdulos.
Conversin piloto: El personal usa el nuevo sistema en un solo sitio piloto y luego la
organizacin completa hace el cambio. A pesar que este nuevo enfoque podra llevar ms tiempo
que los otros tres, da oportunidad al personal de soporte para probar concienzudamente la
respuesta del usuario al sistema, y estarn mejor preparados cuando muchas personas hagan la
conversin.
Los capacitadotes y el personal de soporte tienen un papel significativo durante la conversin. Los
cursos de capacitacin generalmente involucran conferencias del tipo de saln de clase, sesiones de
manos a la obra con datos de muestra y capacitacin basada en computadoras, con la cual los usuarios
pueden trabajar en su propio tiempo.

Fase 5: Mantenimiento

16
Despus que los sistemas de informacin son implementados, los profesionales del Departamento de
Informtica proporcionan soporte durante la fase de mantenimiento. Monitorean varios ndices de la
ejecucin del sistema, como el tiempo de respuesta, para asegurarse que el sistema se desempea segn
se pretenda. Tambin responden a cambios en los requerimientos de los usuarios. Estos cambios
ocurren por una variedad de razones. Conforme los usuarios trabajan con el sistema en una base diaria,
podra reconocer situaciones donde un pequeo cambio en el sistema podra permitirles ser ms
efectivos. O el administrador de un departamento usuario podra requerir cambios debido a nuevas
disposiciones en el estado o en las regulaciones federales de la industria.
Los errores en el sistema tambin se corrigen durante la fase 5. Con frecuencia los sistemas se instalan
en un ambiente de usuario con errores de programacin o diseo ya conocidos. Normalmente estoe
errores han sido identificados como no crticos, o no suficientemente importantes para retrasar la
instalacin. Los programadores tiene listas de tales errores para corregirlos durante la fase de
mantenimiento. En adicin, el uso diario del sistema podra resaltar errores ms serios para que los
programadores los arreglen.
Durante el lapso de vida restante del sistema se realizan regularmente cambios o actualizaciones. Sin
embargo, en algn punto las reparaciones al sistema ya no cubren los requerimientos del usuario, los
cuales podran haber cambiado radicalmente desde que el sistema fue instalado. Los profesionales del
departamento de Informtica o los administradores de un departamento usuario comienzan a pedir una
modificacin importante o un nuevo sistema. En ese momento, el CVDS ha regresado a su punto inicial
y la fase de anlisis comienza de nuevo.

REFERENCIAS BIBLIOGRFICAS
1.- Anlisis y Diseo de Sistemas, Centro de Computacin Profesional de Mxico(CCPM),
McGraw-Hill Interamericana, Editores S.A. de C.V., Agosto 2001, pginas 4-23.
2.- Introduccin a la Computacin, Peter Norton, McGraw-Hill Interamericana, Tercera
Edicin,Marzo 2001, pginas 402-431.