c c
 





DESCRIPCIÓN

El desarrollo de sistemas es un proceso formado por las etapas de

análisis y diseño, éste inicia cuando en la organización se detecta que el
sistema necesita reformas. El ciclo de vida de un sistema es el conjunto de
actividades que los analistas diseñadores y usuarios realizan para desarrollar e
implantar un sistema de información. Cuando se realiza un análisis se debe
considerar que todas las actividades que en una org anización se realicen están
íntimamente relacionadas, lo que en ocasiones impide determinar con exactitud
en qué orden estas actividades se realizan, así como el conocer los pasos que
hay que seguir para efectuarlos.

El ciclo de vida de un sistema es el pr oceso en el cual los analistas, los

ingenieros d software, los programadores y los usuarios finales elaboran
sistemas de información.

Las etapas del ciclo de vida de un sistema son:

1. Definición del problema.

2. Recopilación de información.
3. Análisis de información.
4. Diseño del sistema.
5. Programación.
6. Pruebas del programa.
7. Documentación.
8. Implantación.

 c  



Esta etapa suele ser la primera y la más difícil de todo el proceso del
ciclo de vida debido a que se encarga del reconocimiento de las fallas o
problemas que una organización puede enfrentar.

Tradicionalmente han sido los usuarios y los directivos de las empresas

quienes impulsan la mayoría de los proyectos. Por su parte, los analistas están
encargados de descubrir mejoras dentro de la organización; por lo tanto el
analista debe identificar los problemas, las oportunidades y las normas y
objetivos que rigen a la empresa.

Problema es una situación no deseable que impide que la organización pueda

alcanzar plenamente sus propósitos metas y objetivos.

Una oportunidad es toda posibilidad de mejorar el sistema o lograr la ausencia

de problemas específicos.

Una norma es todo requisito impuesto por la dirección, las instituciones

gubernamentales o cualquier influencia externa .
Si una oportunidad no es usada en su momento, ésta a la larga puede
convertirse en un problema ya que esto pudiera implica el no usar situaciones
favorables tanto para el analista como para la organización.

Con relación a las normas que se aplican en una organización, éstas

representan problemas, pues implican el cambio de actividades o procesos
internos dentro del tratamiento de información.

Los problemas se dan a notar de diversas formas; es decir, éstos pu eden estar
presentes en la organización y tomarse como prácticas normales de trabajo y
depende en gran parte del usuario (directivos) poder descubrir estos problemas
y del analista para determinarlos. La mayoría de los problemas dentro de las
organizaciones se refieren al desempeño (ausentismo, falta de compromiso por
parte de los empleados, alta rotación de personal).

Sin olvidar a los clientes o proveedores del sistema ya que ellos ejercen el tipo
de retroalimentación que el sistema esté recibiendo. Consi dere como
retroalimentación las quejas o sugerencias que se reciben, así como ventas no
consolidadas o canceladas, etc, además del reflejo al momento de medir los
resultados contra los objetivos planeados. Estos son síntomas que deben ser
tomados en cuenta para iniciar de inmediato el análisis del sistema.

c
c   c  

Esta fase del ciclo de vida del sistema involucra al analista con el
sistema, ya que la tarea principal del analista al finalizar esta etapa es tener
una imagen general del s istema.

El analista debe conocer a detalle las funciones actuales del sistema

considerando las siguientes preguntas:

-¿Quién?: para conocer a la gente involucrada.

-¿Qué?: actividad de la organización.
-¿Dónde?: ambiente de trabajo, incluye el lugar.
-¿Cuándo?: momento o instante de tiempo en que se realiza la actividad.
-¿Cómo?: procedimientos o formas para realizar la actividad.

Muchas de estas preguntas serán contestadas si el analista pregunta sobre el

sistema actual que la organización está utilizando. Teniendo al final de esta
investigación una comprensión general del sistema, las funciones y la
información sobre personas, datos y procesos que se realizan.




 


 c  

El uso de información puede iniciarse por un sin número de razo nes como:

-Petición de una persona.

-Solicitud de empleados y usuarios del sistema.
-Necesidades de información de los niveles directivos.

Al considerar estas peticiones es necesario investigar si el sistema que

actualmente funciona en la organización cubre las necesidades y en qué
porcentaje, para saber con exactitud lo que el solicitante desea, por lo que la
solicitud del proyecto debe incluir todas y cada una de las necesidades a cubrir.
Esta actividad permitirá al analista determinar si es convenien te rediseñar el
sistema actual, diseñar uno nuevo, comprar el sistema de información
considerando el costo, los resultados esperados y el perfeccionamiento de las
actividades (aun considerando que algunas de éstas sean de forma manual).
Para que esta investigación se realice se debe elaborar un plan o programa de
trabajo para dar a conocer al cliente todas y cada una de las actividades que la
investigación involucra y el tiempo que requerirán, así como los usuarios que
deberán ser investigados.

Antes de implantar el plan de investigación es necesario conocer:

- FUENTES INTERNAS: son todas las personas contactos en la investigación,

aquellas de nivel jerárquico de la unidad afectada, así como los usuarios
operativos y administradores.

- FUENTES EXTERNAS: considerar a todas las dependencias que tienen

relación al sistema a investigar, sus clientes y personal que se encuentra
involucrado, sin olvidar a la información que ellos generan.

- TÉCNICAS DE RECOLECIÓN DE DATOS: hay que considerar que el trabajo

del análisis no es una función para un solo analista; este debe crear grupos de
trabajo que deben encargarse de recopilar y analizar datos para saber si existe
coincidencia de anomalías en el sistema.

El análisis de la información es la etapa más importante de l análisis debido a

que se va a evaluar el sistema que se investigó; para ello se integrará la
información recopilada durante todo el proceso anterior de investigación,
obteniendo como resultados la mejora del sistema y la factibilidad de su
mejoramiento si así lo requiere.
Las actividades a realizar dentro de esta etapa son:

1. Cruce de la información: el analista se reúne con sus colaboradores y de los

datos recopilados se determinan aquellos lugares críticos o vulnerables dentro
de la organización que determinan los problemas que la empresa está
enfrentando.

2. Análisis de alternativas: una vez expuestos los problemas de la organización

y localizados los procesos a ser mejorados se deberán analizar todas y cada
una de las alternativas de solución utili zando la información recabada. Tales
alternativas podrían ser:

 Aceleración de procesos.
 Eliminar procesos innecesarios.
 Combinación de procesos (manual y automatizado) .
 Reducción de errores.
 Reducción de salidas redundantes .
 Integración de sistemas.
 Satisfacción del trabajador .
 Mejora en la interacción cliente - servidor.

La alternativa a escoger estará en función directa del estudio de factibilidad

correspondiente para respaldar su implementación. La factibilidad es valorada
en tres formas principales para su posterior evaluación:

1. Factibilidad técnica.
2. Factibilidad económica.
3. Factibilidad operacional.

1. Factibilidad técnica: ésta se refiere a la valoración de los recursos técnicos

con los que cuenta la organización, si permiten realizar el proyecto o se
necesitan nuevos recursos (personal, software, material, ect); se debe
considerar también si los recursos técnicos actuales de la organización pueden
ser mejorados a añadidos.

2. Factibilidad económica: se refiere a valorar si los beneficios obtenidos serán

suficientes para aceptar los costos del nuevo proyecto, o bien el no llevar a
cabo el proyecto. La factibilidad económica es el segundo paso para determinar
los recursos tiempo y costo.

3. Factibilidad operacional: esta etapa depende de los recursos humanos, ya

que ellos determinarán en gran medida si se desarrolla e implanta el nuevo
sistema, dependiendo de la forma en que actualmente estén trabajando con el
sistema para saber si el nuevo será aceptado o rechazado de acuerdo a la
satisfacción que tengan con su trabajo.
Una forma de conocer si la factibilidad de los proyectos está bien definida es
cerciorarse de cubrir los tres aspectos de factibilidad técnica, económica y
operacional sobre todo porque el hecho de llevar a cabo un proyecto de gran
magnitud tiene implicaciones directas sobre el sistema y por tanto no es una
decisión fácil de tomar. Para valorar la factibilidad se hace uso de herramientas
como lo es el análisis costo / efectividad, éste implica el conocer los costos y
beneficios que deberán ser considerados juntos, debido a la gran interrelación
y frecuencia dentro del sistema.

Una forma de analizar estos costos y beneficios es aplicando técnicas como

son:

 Análisis del punto de equilibrio.

 Recuperación.
 Análisis de flujo de efectivo.
 Valor presente.







Conocidas ya las necesidades de los usuarios, se procede a realizar el

diseño del sistema de información. Ahora el trabajo del analista consiste en
diseñar procedimientos precisos y eficaces para el procesamiento de datos, a
fin de que al ser usados por el sistema sean los correctos; es decir. crear
entradas efectivas para que los resultados esperados sean los correctos,
mediante el uso de formas y pantallas.

El diseño incluye el diseño de archivos y bases de datos en las que se

almacenarán los datos necesarios para la toma de decisiones.
Dentro del diseño el analista no debe olvidar el control y respaldos de la
información y del sistema. Todo esto además de cr ear paquetes de programas
específicos dentro del sistema que permitirán el proceso de entradas y salidas
así como los detalles de archivos y procesamiento de información, estructuras
de datos utilizadas, etc.

ALTERNATIVAS DE DISEÑO.

El trabajo del analista consiste en elaborar una o más alternativas de

automatización de los sistemas de procesamiento de información que cubra los
requerimientos de los usuarios. Al elaborar un diseño de sistema, se deben
considerar aspectos referentes al procesamiento de ope raciones y la reducción
de costos, sin olvidar la oportunidad y calidad de los resultados.

Por lo tanto es necesario recurrir a preguntas como:

¿Qué parte del sistema debería automatizarse?

¿Se comprará el software o se elaborará?
¿Qué formato de proceso tendrán los archivos?
¿Cuál será el tipo de tecnología a implantar para su uso?

PUNTOS DE CONTROL.

Al referirse a este aspecto deberán considerarse las interfaces de operación del

sistema, indicando los puntos de control y cuáles son las variaciones en ellos.

Los puntos de control a considerar por el analista son:

1. Describir los elementos de control, tales como estándares y métodos para

evaluar el desempeño del sistema en relación con los demás estándares sobre
sistemas de información.

2. Especificar la manera de proporcionar información a cada uno de los

diferentes usuarios de la organización para que cubra sus necesidades de
toma de decisiones correctamente.

c  

Dentro de este aspecto el analista deben considerar si el software a

utilizar será comprado a terceros o bien diseñar software de acuerdo a las
necesidades del sistema. La elección en cada caso dependerá del costo de
cada una de las alternativas, el tiempo disponible para el desarrollo y de la
disponibilidad de programadores (acción que puede ejercer el analista como
analista programador).

En caso de seleccionar el desarrollo del software se tendrán que realizar todas

y cada una de las técnicas que para el desarrollo de software se conocen y
sean adecuadas dependiendo de la pericia d el programador.

ELECCIÓN DEL LENGUAJE DE PROGRAMACIÓN.

El analista junto con el grupo de trabajo deberá elegir y aplicar el lenguaje de

programación más adecuado para la realización del software para desarrollar el
sistema.
La elección del software dependerá en gran parte del conocimiento y
experiencia del analista al usar determinados lenguajes; otro tipo de elemento
que determinará la aplicación de un lenguaje será el tipo de sistema a realizar,
ya que dependiendo de lo que se desee en cuestión del si stema, se
seleccionará el lenguaje que facilite su creación.








El realizar pruebas a cada uno de los elementos que conforman el nuevo

sistema de información es una tarea fundamental para garantizar su adecuado
funcionamiento y evitar resultados no favorables al momento de implantarlo.
Por ello, es necesario considerar que los datos contengan la mayor variedad de
condiciones posibles a fin de probar toda la capacidad de cada programa y que
las anomalías detectadas sean corregidas de fo rma inmediata, además de
hacer lo mismo con la documentación. Es muy importante recordar que el
probar un sistema no es pérdida de tiempo.

Las fuentes para la obtención de datos de prueba son los datos reales y los
artificiales, cada uno con sus ventajas e inconvenientes.

USO DE DATOS DE PRUEBA REALES.

Este tipo de datos son extraídos de los archivos de la organización; se usan

estos datos para probar parcialmente al sistema.

Uso de datos de prueba artificiales.

Los datos de prueba artificiales se crean só lo con fines de prueba, y son

usados para generar todas las combinaciones de formato y de valores.
Prueba de escritorio.

La prueba del programa es responsabilidad de quien programa y del analista,

aunque sólo es un indicador para conocer el funcionamiento del sistema y sólo
se limitan a pruebas en papel.

c c  

Un sistema debe contemplar una documentación adecuada y completa

para mantenerlo y actualizarlo de manera satisfactoria; sin embargo muchos
analistas hacen caso omiso de este aspecto.

Al documentar un sistema se debe buscar cubrir los siguientes objetivos:

 Estandarizar la documentación.
 Facilitar el desarrollo de la misma.
 Ahorrar tiempo.

Una vez contemplados los puntos anteriores, es necesario aplicar estas

ventajas para realizar la documentación del sistema, debido a que si se logra
una documentación eficiente del sistema se tendrán las siguientes ventajas:
 y Será una herramienta didáctica para nuevos miembros de la
organización y por lo tanto nuevos usuarios.
y Es requisito básico para quien tenga la responsabilidad del
mantenimiento del sistema o modificación del mismo.
y Ayuda a los analistas a trabajar en áreas relativas, evitando
redundancias y facilitando la integración de todos los sistemas.
y Asegura que el sistema opere correctamente con el mínimo de errores.
y Los recursos se usan de forma más eficiente.

Los manuales para considerar a un sistema documentado de forma completa

son:

1. Manual de programación: enlista la elección del lenguaje de programación y

el porqué, la lógica para re solver el problema, pruebas de módulos y el
programa en sí. Éste está dirigido a los programadores y diseñadores del
sistema.

2. Manual de usuario: su objetivo es informar al usuario qué es lo que debe

hacer y cómo hacerlo, conozca el sistema o no.

3. Manual del sistema: define el nombre del sistema, características de

implantación, hardware, software y demás formas que requiere el sistema.

IMPLANTACIÓN

La implantación involucra a todas las actividades que se dan al pasar de un

sistema viejo a uno nuevo. Se pueden encontrar las siguientes situaciones al
hablar de implantación: 

y El sistema es totalmente nuevo y reemplaza al que ya existe, sea de

forma manual o automatizada.
y Puede ser una modificación hacia algunos de los componentes del
sistema que actualmente se usan.

Cualquiera que sea la forma en la que se haya modificado a la organización, la

implantación es un elemento determinante para el buen funcionamiento del
sistema y que permita lograr sus objetivos. Para ello es necesario tomar en
cuenta los siguientes aspectos:

CAPACITACIÓN AL PERSONAL.

El elemento del cual necesitamos para el buen funcionamiento y cumplimiento

de los objetivos del nuevo sistema se encuentra en la capacitación que tiene el
personal para la adecuada operación y confiabilidad del sistema.
La capacitación deberá incluir a todos aquellos que de alguna u otra manera se
encuentren involucrados con el sistema, es decir, desde los técnicos, operarios
y demás usuarios.
Esta capacitación involucra aspectos técnicos, referentes al equipo que se
utilizará en las operaciones rutinarias como extraordinarias, es decir, desde
saber cómo encender el equipo, usarlo, operarlo y el apagarlo. Deberá
mencionarse los desperfectos que posiblemente se presentarán, desde los más
comunes hasta las situaciones más complicadas, su reconocimiento y su
solución.
Al capacitar a los usuarios del sistema deberá tomarse en cuenta los
problemas no solo de hardware, sino también de software. Por lo tanto es
necesario tener la documentación correspondiente a este tipo de fallas.
Recordemos que la capacitación se refiere directamente a la forma de
operación del sistema, preparación, captura, almacenamiento y recuperación
de los datos para los sistemas transaccionales, o bien en la elaboración de
reportes, consultas y mantenimiento de la información para la toma de
decisiones.

Al realizar la capacitación se debe centrar bá sicamente en dos puntos:

1. El sistema de procesamiento, que involucra que el usuario se familiarice con

él para su adecuado manejo.

2. La aplicación del sistema que se refiere a la forma de impacto del sistema a

la organización (toma de decisiones).

El no incluir la capacitación es una determinante para que el sistema no genere

los resultados deseados, no solo hacia la organización, sino también desde el
aspecto personal de cada usuario. Además si a ello unimos el hecho de no
contar con una adecuada documentación del sistema, provocarán resultados
no
deseados, debido a que en muchas ocasiones esta documentación sirve de
consulta.







Antes del proceso de la implantación del sistema es necesario un periodo de

prueba para poder determinar s i aún existen problemas no resueltos y no hacer
un doble trabajo de acondicionamiento al sistema.

Las pruebas por las cuales deberá pasar el sistema antes de ser implantado
son:

a) Pruebas de recuperación: se consideran en este tipo de prueba los posibles

fallos en el procesamiento de los datos involucrando tiempo específico; aquí se
determina que el sistema sea confiable en cuestiones referentes a seguir su
funcionamiento cuando alguno de los componentes falle.

b) Pruebas de seguridad: de esta prueba dep enderá la vulnerabilidad que tiene

el sistema en contra la intromisión de personal no autorizado para su uso y
manejo, debido a que se intentará violar su métodos de protección de datos.
Esta prueba es necesaria para conocer los puntos de control más susce ptibles
del sistema.

c) Pruebas de resistencia: la prueba de resistencia permite observar la

demanda que tiene el sistema en cuanto a cantidad de recursos, frecuencia o
volúmenes anormales. Los tipos de resistencia a las cuales se somete el
sistema son:

y Diseño de pruebas sobre interrupciones por segundo.

y Aumento de la frecuencia de datos de entrada.
y Pruebas que requieran uso excesivo de memoria u otro recurso.
y Pruebas sobre el sistema operativo u otro software.
y Crear excesivas búsquedas de datos.

Todo esto con el objetivo de crear conflicto y romper el programa.

d) Pruebas de rendimiento: esta prueba está diseñada para probar el

rendimiento del software en tiempo de ejecución dentro del contexto del
sistema integrado. Las pruebas de rendimiento se unen a las pruebas de
resistencia y requieren de verificar el hardware y software, es decir, la
utilización de recursos de forma exacta.

CONVERSIÓN DEL SISTEMA.

Este proceso se da cuando se realiza el cambio del sistema anterior al nuevo,

ya que existen varias formas de realizar la conversión al nuevo sistema; cada
uno de estos métodos tienen sus beneficios así como sus inconvenientes;
dependerá del tipo de método utilizado la adopción y adaptación al nuevo
sistema, sin olvidar por parte del analista que ésta debe realizarse lo más
pronto posible, de no ser así podría causar efectos de rechazo o frustración
para las personas involucradas.

Los métodos de conversión son:

a) Sistemas paralelos: éste es uno de los métodos más seguros para la

conversión de un sistema, ya que trabaja con ambos sistemas (nuevo y viejo)
al mismo tiempo. Con esta perspectiva, los usuarios operan el sistema anterior
de forma acostumbrada, pero comienzan a usar el nuevo sirviendo el viejo
sistema de respaldo de las operaciones para el nu evo sistema.

Las desventajas de este método son:

-Los costos se duplican por existir dos sistemas.

y Se necesita mayor uso de personal

y Se puede generar una resistencia potencial al uso del nuevo sistema,
por preferir el anterior.

b) Conversión directa: este enfoque transforma el sistema anterior al nuevo de

manera abrupta, puede ser tan precipitada como cambiar de un fin de semana
a otro o en casos extremos de un día a otro. El efecto psicológico de este
enfoque es radical en los usuarios, pues ellos no tienen otro sistema al cual
recurrir en caso de falla, quedando la posibilidad de parar operaciones en caso
de una falla.

Este tipo de conversión requiere de una planificación muy cuidadosa en cuanto

a la capacitación, el equipo, corrección de errores, el lugar. etc. Esta de
conversión se da cuando se instala equipo nuevo o bien los sistemas son
comprados y puestos en operación inmediatamente.

c) Enfoque piloto: a veces los sistemas implican métodos nuevos de trabajo de

la organización, debido a ello el en foque piloto es utilizado. Este enfoque
permite implantar una versión de trabajo en una parte de la organización, como
sería un área ó departamento. Los usuarios saben que están probando un
sistema y que se pueden hacer cambios para mejorar el sistema.
Cuando el sistema se ha probado en su totalidad, éste se instala en toda la
organización y puede darse por conversión directa o usando el método por
etapas.
Una de las grandes ventajas de este método es proporcionar una gran
seguridad en las pruebas a las cuales es sometido el sistema y eliminar los
posibles errores.

d) Método por etapas: este método se usa cuando no es posible instalar de

golpe un nuevo sistema, debido a los archivos, la capacitación o el equipo son
factores que impiden la instalación del si stema. El problema de este método es
la expectativa que pueda causar en los usuarios, ya que de no usar al mismo
tiempo el sistema, estos pueden ser vulnerables al desempeño del sistema por
no usarlo al mismo tiempo que sus compañeros de trabajo.