UNIVERSIDAD PERUANA LOS ANDES

FACULTAD DE CIENCIAS ADMINISTRATIVAS Y CONTABLES

CARRERA PROFESIONAL DE ADMINISTRACION Y SISTEMAS

CICLO DE VIDA DE DESARROLLO

DE SISTEMA

ESTUDIANTE:
KEN LEE SAMAR AQUINO

DOCENTE:

LIC. LUIS DAVID ARRIAGA HUAMANI

FILIAL CHANCHAMAYO

2019 - 1
 INTRODUCCION
• Es un proceso (normativo)que provee una solución (modelo)
para el desarrollo de un sistema.„Identifica etapas y
secuencia en el desarrollo „ Encapsula el conocimiento de
casos pasados„ Facilita el desarrollo de nuevos casos
• Etapas: identificación de requerimientos, diseño (lógico y
físico), implantación, testeo, puesta en marcha, operación, y
mantención

Ventajas
• Evita partir de cero en cada proyecto
• Pone el énfasis en el proyecto mismo, en vez de la forma de
desarrollarlo
• Comúnmente aceptado (lenguaje común)

Desventajas
• Inflexibilidad en la adaptación a casos particulares.
Bajo ni
vel de cuestionamiento al
• adoptarlo.
 1

CICLO DE VIDA DE DESARROLLO DE SISTEMA (CVDS)

Asumir el reto de desarrollar e implantar un sistema de información 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 información exitosos fue desarrollado el ciclo de
vida del desarrollo de sistemas (CVDS) que “es el conjunto de fases o actividades que realizan los
analistas, diseñadores, programadores y usuarios finales para desarrollar e implantar un sistema de
información.”

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 situación actual con el objetivo de
elaborar un sistema de información o alguna aplicación informática; en todo caso se trata de una herramienta
de gestión de proyectos que planea, ejecuta y controla los proyectos de desarrollo de sistema.

En términos generales el grupo de analistas, diseñadores y programadores enfrentan el escenario de resolver

un problema para un grupo de usuarios finales, donde los miembros del departamento de sistemas lo
denominan genéricamente con el nombre Proyecto.

Fase 1----�Investlgaclon Prellmlnar: comienza con la solicitud por parte de la gerencia, la

administración, un grupo de usuarios o los especialistas de sistemas en mejorar un proceso, aplicar una
norma o aprovechar una oportunidad para mejorar la organización, 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) Aclaración de la solicitud
b) Estudio de factibilidad
c) Aprobación de la solicitud.

a) Aclaración 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 están formuladas de manera clara, pero
representan la voz de la organización 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.
 2

b) Estudio de factibilidad: El desarrollo de un sistema de Información suele ser caro, así antes de
iniciar cualquier proyecto se debe hacer un estudio de viabilidad; “que es una investigación
rápida 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 pequeño equipo de personas que pertenecen a la

organización o asesores externos y que se verán afectados por el proyecto y que no debe durar
más de 8 días hábiles. En la investigación preliminar se estudian los siguientes aspectos:

b.1) Factibilidad Técnica: Consiste en determinar si dentro o fuera de la organización existe la

tecnología y el recurso humano capacitado para poder desarrollar el proyecto.

b.2) Factibilidad Económica. Consiste en determinar si los costos de desarrollo e implantación

del sistema se justifican en función 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 están en

capacidad de usar apropiadamente el sistema, o cuanto tiempo se requerirá para formar el
personal en el uso apropiado del nuevo sistema de información.
 3

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

solución desarrollarse e implantarse en un plazo aceptable?, es decir, la construcción del
sistema puede desarrollarse en un tiempo razonable para recuperar la inversión y
satisfacer a los usuarios finales.

Alfinalizar estaetapaelgrupodetrabajodebeentregar uninformecon todaslasposibles

alternativas desoluciónacompañadas consuestudiodefactibilidadyelplandedesarrollo
correspondiente.

c) Aprobación de la solicitud Consiste en que la alta gerencia administrativa después de escuchar

el informe de factibilidad tome la decisión para continuar o no con el proyecto.
Aceptar la
recomendación

Enmendar la
recomendación

Devolver las
recomendaciones

Rechazar todos los

proyectos

En resumen en esta primera etapa el analista se involucra en al identificación de los problemas y las
oportunidades que ofrece la empresa a nivel de desarrollo de sistemas de información. En muchas
ocasiones la empresa ya tiene detectadas sus áreas débiles y se llama al analista ya con ciertos
objetivos previstos. Esta etapa es crítica, ya que nadie desea perder el tiempo resolviendo el problema
equivocado.
 4

1. Determlnaclon de Requerlmlentos: Después de realizar la investigación preliminar, el analista

tiene que plantear los requerimientos del usuario para el nuevo sistema; es decir, las necesidades y
características que deberá cubrir el nuevo sistema.

Para identificar los requerimientos de información se utilizan varias técnicas o herramientas como
los son documentos, la entrevista, los cuestionarios, etcétera.

2. Dlseño del slstema: El Diseño de un sistema de información produce los detalles que establecen la
forma en la que el sistema cumplirá con los requerimientos de información.

3. Desarrollo de Software: Consiste en escribir los programas necesarios para el sistema. Los
programadores son responsables de la documentación de los programas, que también se realiza
durante esta etapa, así como explicar el funcionamiento de los mismos y por qué ciertos
procedimientos se codifican de determinada forma.

La documentación es importante ya que por medio de ella será posible modificar o llevar a cabo el
mantenimiento del programa.

4. Prueba del slstema: 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. Implantaclon y evaluaclon: La implantación es el proceso de verificar e instalar nuevo equipo,

entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios.

Dependiendo del tamaño de la organización y del riesgo asociado al uso del nuevo sistema se puede
comenzar la operación del sistema sólo en un área de la empresa.

Es recomendable que trabajen paralelamente el anterior sistema y el nuevo para comparar los
resultados obtenidos.

La evaluación del sistema se lleva a cabo para identificar sus puntos débiles y fuertes.

Aunque en algunas ocasiones este proceso de evaluación no recibe la importancia que merece, si se
realiza de forma adecuada proporciona mucha información que puede ayudar a mejorar la
efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.
 5
1.- Prlnclplos generales del Clclo de Vlda de Desarrollo de Slstemas (CVDS)
1.1.- Impllcar al usuarlo: Es importante estar claro que el sistema a ser desarrollado le pertenece al usuario
del sistema, el analista es simplemente un experto en tecnología de la información que viene a resolver
uno o varios problemas puntuales de procesamiento de información; comprometer al usuario permite
evitar errores en la construcción del sistema, además 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 actlvldades de la Organlzaclon: Toda organización debe tener una Visión y
Misión específica, las cuales son su constante motivación; así la Administración es encargada de definir
las Políticas, Normas, Metas y Estrategias para cumplir con esos principios, de tal manera que cuando se
desarrollan los sistemas de información 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 Organización.

1.3.- Apllcar un método de resoluclon de problemas: En el momento que el analista estudia la situación
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 solución
de sistemas en forma eficiente se debe usar un método, con el cual se busca evitar que se pierdan
detalles en la construcción de un nuevo sistema; así El Ciclo de Vida de Desarrollo de Sistemas es ante
todo un método para resolver problemas, que le permite al analista estudiar en detalle la situación actual
y construir en detalle una solución, el cual consta de las siguientes actividades:
1. Investigación preliminar
2. Determinación de los requerimientos del sistema
3. Diseño del sistema
4. Desarrollo de software
5. Prueba de los sistemas
6. Implantación y evaluación
 6

En términos generales dichas fases o actividades se pueden resumir en:

1. Análisis
2. Diseño
3. Desarrollo de Software
4. Implantación

Anállsls Dlseño Desarrollo Implantaclon

de Software

SISTEMA DE INFORMACÓN o PROBLEMA

1.4.- Justlflcar los slstemas como una lnverslon de capltal: Los sistemas de información son ante todo
una inversión de capital, pues los propietarios o la organización deben pagar: luz, agua, teléfono,
personal, discos, hojas, etc...para su realización; 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 organización invierte para no recoger esa
inversión a un corto o mediano plazo.
 7

1.5.- Dlseñar el slstema para el creclmlento: La vida útil de un nuevo sistema debe ser visto como una
soluci6n a largo plazo, por lo tanto debe ser diseñado 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 entropía del
sistema.

2.- Anállsls: 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 informaci6n 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. Investigaci6n Preliminar
2.2. Determinaci6n de requerimientos
 8

2.1.- La Investigación preliminar

2.2) Determlnaclon de los Requerlmlentos: La siguiente fase del analisis consiste en conocer y
estudiar en detalle la situacion actual, para llegar a una compresion mas 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 basicos de la situacion actual
Obtener el diccionario de datos de la situacion actual
Definir las fortalezas, oportunidades, amenazas y debilidades del sistema actual (ANÁLISIS
DE LA SITUACIÓN ACTUAL)
Determinar los Requerimientos ser incorporados en el sistema propuesto.
Aprender como funciona el sistema actual se requiere de la participacion activa de los propietarios,
los usuarios(Directos e Indirectos), pues incrementa su sentido de responsabilidad y propiedad del
sistema de informacion 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 informacion al
usuario para la toma de decisiones; paralelamente se estructura el diccionario de datos de la
situacion actual.

Para realizar los D.F.Ds. el analista conversa con varias personas para reunir detalles relacionados
con los procesos de la organizacion, 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 mas de las
siguientes técnicas de investigacion de hechos:
Elaboracion de Entrevistas
Reunion y discusion en grupos
Observacion
Muestreo de archivos y formularios
Encuestas y cuestionarios.
Al concluir este fase el analista debe tener:
1. Los Requerlmlentos del Nuevo slstema, es decir, un listado de todas las características o
Entradas/Salidas que deben ser incluidas en el nuevo sistema, entre las cuales se puede señalar:
• 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 Dlcclonarlo de Datos del slstema Actual.
3. El Anállsls del Slstema Actual, es decir, un listado de las Fortalezas y Debilidades del
Sistema actual
a) Actlvldades de la Determlnaclon de Requerlmlentos:
a.1) Usar la Experlencla: 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 planificacion de proyectos
 9
Anticipar problemas
Prever un caracteristica del nuevo sistema
Definir procesos, datos y controles mas rapido
Optimizar el tiempo

a.2) Determlnar el objetlvo del slstema: Consiste en definir especificamente 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.

Objetlvo(s)
Slstema del Slstema
Actual
Propuesto

a.3) Determlnar los Requerlmlentos: Consiste en estudiar los hechos, los procesos, los datos,
los depositos y las personas del sistema actual, a través de algún modelo que represente el
sistema para definir cuales seran las características esenciales que deben ser incluidas en
el nuevo sistema.
 10

b) Los Requerimientos son:

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

Datos Proc 1. Proc 2. Proc 3.

Informacien

Asi POR CADA PROCESO BÁSICO 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, como lo hace paso a paso y
donde guarda los datos y/o la informacion; 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:
¿Cual es el nombre del proceso?
¿Cuales son los pasos o actividades del proceso?
¿Donde se realizan los pasos?
¿Quiénes realizan .los pasos?
¿Quiénes emplean la informacion resultante?
¿Con cuanta frecuencia se realizan?

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

Datos Informacien
Proceso

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

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

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

Ejemplos: 15 solicitudes, 50 ventas, 70’000 abonos, etc....

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

establece un supervision con los datos; en otras palabras, para establecer una
comparacion 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 estandares preestablecidos?
¿Quien se encarga de supervisar?
¿Como se detectan los errores?
¿Cada cuanto se presentan los errores?
¿Como se corrigen los errores?
¿Que datos se originan de fuentes externas y por que?
¿Como se presentan los errores?
¿Con que detalle se desea el informe de los errores?
¿Cada cuanto y por que se debe presentar un informe de errores?
 12

b.2) De Decisien: A diferencia de las actividades de transaccion, las relacionadas con las
decisiones no siguen ningun procedimiento especifico; es mas, las decisiones siempre se
toman en base al resultado de los sistemas de transaccion, de alli 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 estadisticas de los
aprobados y reprobados por seccion 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 creacion de una nueva seccion, el jefe de
departamento debe tener en sus manos buena cantidad de informacion para poder tomar
la decision mas acertada, es decir crear la seccion con X cantidad de alumnos..
Se recomienda plantearse las siguientes preguntas:
¿Que Informacion se usa para tomar decisiones?
¿Cual es la fuente de la informacion?
¿Que sistema de transaccion produce la informacion que es usada en la toma de
decisiones y por que?
¿Que otros datos son necesarios y por que?
¿Quien toma las decisiones y por que?

b.3) De Organizacien: En las Organizaciones cada departamento, seccion, area depende uno
de otro para brindar servicios o bienes a sus clientes, por consiguiente el trabajo de un
departamento afecta al de los demas. El analista de sistemas debe determinar cuales 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
organizacion.

Fase 1: Análisis de Necesidades

Durante el analisis 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 solucion y definir su funcionalidad.

La fase 1 comienza cuando se identifica una necesidad para un sistema nuevo o modificado. Por ejemplo,
los usuarios podrian quejarse de que el sistema actual es dificil de usar. Los procedimientos simples
requieren demasiados pasos, y el sistema se cae repetitivamente, con la consecuencia de una perdida de
 13
informacion. Opcionalmente, un administrador se podria acercar de Informatica para pedir un reporte que
actualmente no es producido por el sistema.

Los analistas de sistemas comienzan entonces una investigacion preliminar, hablando con los usuarios y los
administradores del departamento afectado. El primer reto es definir el problema con precision. Con el
problema exactamente definido, el departamento de Informatica puede decidir si va a tomar el proyecto(la
decision de “ir o no ir”.

Cuando una decision para proceder esta tomada, los analistas de sistemas llevan acabo una investigacion
concienzuda del sistema actual y sus limitaciones. Trabajan con la gente directamente involucrada con el
problema para documentar como puede resolverse.

El conocimiento reunido en relacion al sistema actual se documenta de varias maneras diferentes. Algunos
analistas usan diagramas de flujo de datos, los cuales muestran flujo de informacion a traves del
sistema(VER GRAFICO DE EJEMPLO). Podrian usar algoritmos estructurados para describir alternativas y
acciones del sistema actual. Otra opcion es presentar las acciones que se toman bajo diferentes condiciones
en un arbol de decision(VER EJEMPLO). La representacion grafica es mas facil de comprender que un a
lista. Con esta base, los analistas estan listos para considerar varias soluciones al problema. Podrian llamar
cientificos de computacion del departamento de Informatica 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 solucion rapidamente, el equipo del departamento de Informatica
podria considerar soluciones que fueran menos ideales, sin embargo, tiene la ventaja de un rapido cambio
de posicion.
Al finalizar la fase 1, equipo recomienda una solucion para ser adoptada. Los analistas usan la informacion
que ya reunieron con los usuarios del sistema para determinar que caracteristicas debe haber en la solucion
(Que reportes deberian generarse, en que forma seran emitidos y que herramientas especiales se necesitan).
Mediante la fase de analisis de necesidades, permanecen enfocados en “que” deberia hacer el sistema, no
“como” seran implementadas las caracteristicas.

Fase 2: Diseño del sistema

Durante la segunda fase, Diseño del sistema, el equipo de proyecto encara el “como” de la solucion elegida.
Por ejemplo, una aplicacion de la base de datos deberia ser capaz de aceptar informacion de los usuarios y
almacenarla. Éstas son funciones generales, pero ¿Como las implementara el equipo? Por ejemplo, ¿Cuantas
pantallas de entrada son necesarias y como se veran? ¿Que tipo de opciones de menu debe haber? ¿Que
tipo de base de datos usara el sistema?

Los analistas y programadores involucrados hasta este punto, usan con frecuencia una combinacion de
diseño descendente y ascendente para responder esas preguntas. En el Diseño 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 mas y mas pequeñas. Cada una de estas actividades sera
programada en la siguiente fase CVDS.

En el Diseño Ascendente, el quipo comienza con los detalles ( Por ejemplo, los reportes que seran
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 especificos para la
salida –por ejemplo, cheques para pago de nomina, los cuales deben contener ciertas piezas de informacion-.

A traves de la fase 2, el administrador del equipo del proyecto revisa el progreso en el diseño de diferentes
componentes del sistema. Al final de la fase se lleva a cabo una revision mas amplia, involucrado
 14
normalmente al departamento que sera afectado y a la administracion superior. Si el diseño pasa la
inspeccion, el desarrollo comienza. En algunos casos la revision pone de relieve problemas con la solucion
general, y el equipo debe regresar a analizar o terminar el proyecto.

Muchas herramientas estan disponibles para ayudar a los equipos a traves de los pasos del diseño de
sistemas. La mayoria de estas herramientas tambien pueden usarse durante de la fase de desarrollo, o,
incluso, durante el analisis. Por ejemplo, muchos equipos usan modelos de funcionamiento llamados
Prototipos para explorar la vista y percepcion de las pantallas en relacion con los usuarios. Tambien usan
aplicaciones de software especiales para crear esos prototipos rapidamente, asi como para crear diagramas,
escribir codigo y administrar el esfuerzo de desarrollo. Estas aplicaciones entran en la categoria de
herramientas de ingeniería de software asistidas por computadora(CASE). En otras palabras, el
software de computo esta usandose para desarrollar otro software de computo mas confiable y rapidamente.

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 especificos del sistema general. Si un componente esta creandose, los programadores escriben
el codigo necesario o usan herramientas CASE (Si es posible) para acelerar el proceso de desarrollo. Para
los componentes comprados, los programadores deben personalizar el codigo segun sea necesario para hacer
que el componente encaje dentro del nuevo sistema.

Hay dos rutas alternativas a traves de la fase 3:La ruta de la adquisicien o la ruta del desarrollo local.
Tan temprano como la fase 1, analisis de necesidades, el equipo del proyecto podria darse cuenta de que
algunos o todos los componentes necesarios del sistema estan 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 mas rapido 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 podrian necesitar ser personalizados para
encajar dentro del sistema general de informacion. 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 adquisicion como de desarrollo local a traves del CVDS al mismo tiempo.

Los redactores tecnicos trabajan con los programadores para producir la documentacion tecnica para el
sistema. La documentacion tecnica es sumamente distinta de la documentacien para el usuario, en ella se
describe a los usuarios finales como usar el sistema; en cambio, la documentacien técnica incluye
informacion acerca de las caracteristicas tecnicas del software y de la programacion, acerca del flujo de
informacion y del procesamiento a traves del sistema, y acerca del diseño y disposicion 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. Ademas, la
documentacion tecnica 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 documentacion para el usuario, y los arquitectos de asistencia
al usuario comienzan a plantear la arquitectura del sistema de ayuda en linea. Estos esfuerzos normalmente
no son terminados hasta llegar a las primeras etapas de la fase de puesta en practica.

Poner a prueba es una parte integral de las fases 3 y 4 (Desarrollo y puesta en practica). El enfoque tipico 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
instalacion, 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 aceptacion, 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 “informacion viva”- . Esto ayuda a asegurase de que el
sistema puede manejar el flujo de informacion esperado sobre una base diaria despues que le sistema se
pone en linea. Sin embargo, los programadores tambien debieran probar el sistema con datos invalidos o
condiciones de excepcion. Por ejemplo, ¿Que pasa cuando un usuario teclea mal “1X33345” en vez de
“1333345” dentro de un campo que solamente acepta informacion numerica? Este tipo de errores no debe
existir en los datos que se usan normalmente para probar el sistema, pero probablemente ocurrira cuando el
sistema sea usado por empleados reales.

:
Fase 4: Implementacien
En la fase de Implementacien, 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.
Despues, los usuarios comienzan a usar el sistema para realizar trabajo, no solo para proporcionar
retroalimentacion en el desarrollo del sistema.

El proceso de cambiar del antiguo sistema al nuevo se llama conversien. Los profesionales de los sistemas
de informacion deben manejar cuidadosamente este proceso para evitar perder o corromper datos y frustrar
a los usuarios que tratan de realizar su trabajo. La conversion puede ser:
Conversien Directa: Todos los usuarios dejan de usar el sistema antiguo al mismo tiempo y
despues comienzan a usar el nuevo. Esta opcion es rapida, pero puede ser destructiva. Ademas,
la presion sobre el personal de soporte puede resultar excesiva.
Conversien en paralelo: Los usuarios continuan usando el sistema antiguo mientras que una
cantidad creciente de informacion es procesada mediante el nuevo sistema. Las salidas de los dos
sistemas son comparadas, y si estan de acuerdo se hace el cambio. Esta opcion es util para mas
pruebas reales del nuevo sistema, pero es muy desgastante porque ambos sistemas estan
operando al mismo tiempo.
Conversien en Fases: Los usuarios comienza a usar el nuevo sistema componente por
componente. Esta opcion solo funciona para sistemas que pueden ser divididos en
compartimientos o modulos.
Conversien piloto: El personal usa el nuevo sistema en un solo sitio piloto y luego la
organizacion completa hace el cambio. A pesar que este nuevo enfoque podria llevar mas tiempo
que los otros tres, da oportunidad al personal de soporte para probar concienzudamente la
respuesta del usuario al sistema, y estaran mejor preparados cuando muchas personas hagan la
conversion.

Los capacitadotes y el personal de soporte tienen un papel significativo durante la conversion. Los
cursos de capacitacion generalmente involucran conferencias del tipo de salon de clase, sesiones de
manos a la obra con datos de muestra y capacitacion basada en computadoras, con la cual los usuarios
pueden trabajar en su propio tiempo.

Fase 5: Mantenimiento
 16
Despues que los sistemas de informacion son implementados, los profesionales del Departamento de
Informatica proporcionan soporte durante la fase de mantenimiento. Monitorean varios indices de la
ejecucion del sistema, como el tiempo de respuesta, para asegurarse que el sistema se desempeña segun
se pretendia. Tambien 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,
podria reconocer situaciones donde un pequeño cambio en el sistema podria permitirles ser mas
efectivos. O el administrador de un departamento usuario podria requerir cambios debido a nuevas
disposiciones en el estado o en las regulaciones federales de la industria.

Los errores en el sistema tambien se corrigen durante la fase 5. Con frecuencia los sistemas se instalan
en un ambiente de usuario con errores de programacion o diseño ya conocidos. Normalmente estoe
errores han sido identificados como no criticos, o no suficientemente importantes para retrasar la
instalacion. Los programadores tiene listas de tales errores para corregirlos durante la fase de
mantenimiento. En adicion, el uso diario del sistema podria resaltar errores mas serios para que los
programadores los arreglen.

Durante el lapso de vida restante del sistema se realizan regularmente cambios o actualizaciones. Sin
embargo, en algun punto las reparaciones al sistema ya no cubren los requerimientos del usuario, los
cuales podrian haber cambiado radicalmente desde que el sistema fue instalado. Los profesionales del
departamento de Informatica o los administradores de un departamento usuario comienzan a pedir una
modificacion importante o un nuevo sistema. En ese momento, el CVDS ha regresado a su punto inicial
y la fase de analisis comienza de nuevo.

REFERENCIAS BIBLIOGRÁFICAS
1.- Analisis y Diseño de Sistemas, Centro de Computacion Profesional de Mexico(CCPM),
McGraw-Hill Interamericana, Editores S.A. de C.V., Agosto 2001, paginas 4-23.
2.- Introduccion a la Computacion, Peter Norton, McGraw-Hill Interamericana, Tercera
Edicion,Marzo 2001, paginas 402-431.
 CONCLUSIONES

Los modelos de ciclos de vida aportan al

desarrollo del proyecto

„ Es necesario seleccionar un modelo de ciclo de vida

teniendo en cuenta las características del problema y el
equipo de trabajo.
„ Los modelos de ciclos de vida son normativos, y por
ellos deben adaptarse acada situación.
GRACIAS