Las actividades que contribuyen para producir una solución de sistema de

información para un problema u oportunidad organizacional se denominan

desarrollo de sistemas. El cual es un tipo estructurado de problema que se
resuelve con distintas actividades, que consisten en análisis de sistemas, diseño
de sistemas, programación, prueba, conversión, además de producción y
mantenimiento.

La siguiente figura ilustra el proceso de desarrollo de sistemas. Las actividades de

desarrollo de sistemas que se describen se realizan por lo general en orden
secuencial. Sin embargo, tal vez haya que repetir algunas de las actividades, o
quizás otras se realicen al mismo tiempo, dependiendo de la metodología de
creación de sistemas que se emplee.

EL PROCESO DE DESARROLLO DE SISTEMAS. La creación de un sistema se

puede dividir en seis actividades básicas.

ANÁLISIS DE SISTEMAS.

El análisis de sistemas es el análisis de un problema que una firma trata de

resolver mediante un sistema de información. Consiste en definir el problema,
identificar sus causas, especificar la solución e identificar los requerimientos de
información que debe cumplir una solución de sistemas.

El analista de sistemas crea un mapa de la organización y los sistemas existentes,

en el cual se identifica a los propietarios y usuarios principales de los datos, junto
con el hardware y software existente. Después el analista de sistemas detalla los
problemas de los sistemas existentes. Al examinar los documentos, papeles y
procedimientos, observar las operaciones del sistema y entrevistar a los usuarios
clave de los sistemas, el analista puede identificar las áreas problemáticas y los
objetivos que lograría una solución.

A menudo es necesario crear un nuevo sistema de información o mejorar uno

existente. El análisis de sistemas también ofrece un estudio de viabilidad para
determinar si esa solución es viable, o si se puede alcanzar desde un punto de
vista financiero, técnico y organizacional. El estudio de viabilidad determina si se
espera que el sistema propuesto sea una buena inversión, si está disponible la
tecnología necesaria para el sistema, si los especialistas en sistemas de
información de la firma pueden operarlo, y si la organización puede manejar los
cambios introducidos por el sistema.

Por lo general, el proceso de análisis de sistemas identifica varias soluciones

alternativas para la organización y evalúa la viabilidad de cada una de ellas. Un
informe de propuesta de sistemas por escrito describe los costos y beneficios,
además de las ventajas y desventajas, de cada alternativa. Es responsabilidad de
la gerencia determinar qué mezcla de costos, beneficios, características técnicas e
impactos organizacionales representa la alternativa más deseable.

Establecimiento de los requerimientos de información.

Tal vez la tarea más desafiante del analista de sistemas sea definir los
requerimientos específicos de información que debe cumplir la solución del
sistema seleccionado. En el nivel más básico, los requerimientos de
información de un nuevo sistema implican identificar quién necesita qué
información, en dónde, cuándo y cómo. El análisis de los requerimientos describe
con cuidado los objetivos del sistema nuevo o modificado y desarrolla una
descripción detallada de las funciones que debe realizar el nuevo sistema.

Un análisis de requerimientos mal realizado es una de las principales causas de

fallas en el sistema y de los costos elevados en el desarrollo de sistemas.

Un sistema diseñado con base en el conjunto incorrecto de requerimientos se

tendrá que descartar debido al mal desempeño, o tendrá que sufrir modificaciones
considerables. Algunos problemas no requieren una solución de sistema de
información, sino que necesitan un ajuste en la administración, una capacitación
adicional o el refinamiento de los procedimientos organizacionales existentes. Si el
problema está relacionado con la información, tal vez aún sea necesario realizar
un análisis de sistemas para diagnosticar el problema y llegar a la solución
apropiada.
DISEÑO DE SISTEMAS.

El análisis de sistemas describe lo que debería hacer un sistema para cumplir con
los requerimientos de información, y el diseño de sistemas muestra cómo
cumplirá con este objetivo.

El diseño de un sistema de información es el plan o modelo general para ese

sistema. Al igual que el plano de construcción de un edificio o una casa, consiste
en todas las especificaciones que dan al sistema su forma y estructura.

El diseñador de sistemas detalla las especificaciones del sistema que ofrecerán

las funciones que se identificaron durante el análisis de sistemas. Estas
especificaciones deben lidiar con todos los componentes administrativos,
organizacionales y tecnológicos de la solución del sistema. La siguiente tabla lista
los tipos de especificaciones que se producen durante el diseño de sistemas.

ESPECIFICACIONES DE DISEÑO.
Al igual que las casas o los edificios, los sistemas de información pueden tener
muchos posibles diseños. Cada diseño representa una mezcla única de todos los
componentes técnicos y organizacionales. Lo que hace que un diseño sea
superior a los otros es la facilidad y eficiencia con la que cumple los
requerimientos del usuario dentro de un conjunto específico de restricciones
técnicas, organizacionales, financieras y de tiempo.

La función de los usuarios finales.

Los requerimientos de información de los usuarios controlan todo el esfuerzo de
creación del sistema. Los usuarios deben tener el suficiente control sobre el
proceso de diseño para asegurar que el sistema refleje sus prioridades de
negocios y sus necesidades de información, no las predisposiciones del personal
técnico. Al trabajar en el diseño aumenta la comprensión y aceptación de los
usuarios para con el sistema.

El hecho de que el usuario no participe lo suficiente en el esfuerzo de diseño es

una de las principales causas de que fallen los sistemas. Sin embargo, algunos
sistemas requieren más participación de los usuarios que otros.

COMPRESIÓN DEL PROCESO DE DESARROLLO DE SISTEMAS.

El resto de las etapas en el proceso de desarrollo de sistemas traducen las

especificaciones de la solución que se establecieron durante el análisis y el diseño
de sistemas en un sistema de información completo y operacional. Estas etapas
concluyentes consisten en: programación, prueba, conversión, producción y
mantenimiento.

Programación.

Durante la etapa de programación, las especificaciones del sistema que se

prepararon durante la etapa de diseño se traducen en código de programa de
software. En la actualidad, muchas organizaciones ya no necesitan encargarse de
su propia programación para los nuevos sistemas. En cambio, compran el
software que cumple con los requerimientos de un nuevo sistema a través de
fuentes externas, como los paquetes de software de un distribuidor de software
comercial, los servicios de software de un proveedor de servicios de aplicación o
subcontratan firmas que desarrollan software de aplicación personalizado para sus
clientes.

Prueba.

Se debe realizar una prueba exhaustiva y detallada para determinar si el sistema

produce o no los resultados correctos. La prueba responde a la pregunta:
¿Producirá el sistema los resultados deseados bajo condiciones conocidas?.
Algunas compañías están empezando a usar servicios de computación en la nube
para este trabajo.

En la planificación de proyectos de sistemas, es una tradición subestimar la

cantidad de tiempo necesaria para responder a esta pregunta. El proceso de
prueba consume tiempo: hay que preparar con cuidado los datos de prueba,
revisar los resultados y hacer las correcciones en el sistema. En algunos casos, tal
vez sea necesario rediseñar partes del sistema. Si se pasa por alto esta etapa los
riesgos resultantes son enormes.

Podemos dividir la prueba de un sistema de información en tres tipos de

actividades: prueba de unidad, prueba de sistema y prueba de aceptación.

La prueba de unidad, o prueba de programa, consiste en probar cada programa

por separado en el sistema. Una creencia popular es que el propósito de dicha
prueba es garantizar que los programas estén libres de errores, pero en realidad
esta meta es imposible. Debemos ver la prueba como un medio de localizar
errores en los programas y enfocarnos en encontrar todas las formas para hacer
que falle un programa. Una vez señalados, los problemas se pueden corregir.

La prueba de sistema evalúa el funcionamiento del sistema de información como

un todo. Trata de determinar si los módulos discretos funcionarán en conjunto
según lo planeado, y si existen discrepancias entre la forma en que funciona el
sistema en realidad y la manera en que se concibió. Entre las áreas a examinar
están el tiempo de desempeño, la capacidad de almacenamiento de archivos y el
manejo de cargas pico, las capacidades de recuperación y reinicio, y los
procedimientos manuales.

La prueba de aceptación provee la certificación final de que el sistema está listo

para usarse en un entorno de producción. Los usuarios evalúan las pruebas de
sistemas y la gerencia las revisa. Cuando todas las partes están satisfechas de
que el nuevo sistema cumple con sus estándares, se acepta de manera formal
para su instalación.

El equipo de desarrollo de sistemas trabaja con los usuarios para idear un plan de
prueba sistemático. El plan de prueba abarca todas las preparaciones para la
serie de pruebas que acabamos de describir.
La siguiente figura muestra un ejemplo de un plan de prueba. La condición general
a evaluar es un cambio de registro. La documentación consiste en una serie de
pantallas del plan de prueba que se mantienen en una base de datos (tal vez una
base de datos en una PC), la cual se adapta de manera ideal a este tipo de
aplicación.

UN PLAN DE PRUEBA DE EJEMPLO PARA EVALUAR UN CAMBIO DE

REGISTRO. Al desarrollar un plan de prueba, es imperativo incluir las diversas
condiciones a evaluar, los requerimientos para cada condición evaluada y los
resultados esperados. Los planes de prueba requieren entrada tanto de los
usuarios finales como de los especialistas en sistemas de información.
La conversión es el proceso de cambiar del sistema anterior al nuevo. Se pueden
emplear cuatro estrategias principales de conversión: la estrategia paralela, la
estrategia de reemplazo directo, la estrategia de estudio piloto y la estrategia de
metodología en fases.

En una estrategia paralela, tanto el sistema anterior como su reemplazo potencial

se operan en conjunto durante un tiempo, hasta que todos estén seguros de que
el nuevo funciona de manera correcta. Ésta es la metodología de conversión más
segura ya que, en caso de errores o interrupciones en el procesamiento, todavía
es posible usar el sistema anterior como respaldo. Sin embargo, esta metodología
es muy costosa y tal vez se requieran personal o recursos adicionales para operar
el sistema adicional.

En la estrategia de reemplazo directo se sustituye el sistema anterior en su

totalidad con el nuevo, en un día programado con anterioridad. Es una
metodología muy riesgosa que puede llegar a ser más costosa que operar dos
sistemas en paralelo, en caso de que se encuentren problemas graves en el
nuevo sistema. Aquí no hay otro sistema de respaldo. El costo de los traslados, las
interrupciones y de las correcciones puede llegar a ser enorme.
La estrategia de estudio piloto introduce el nuevo sistema a sólo un área
limitada de la organización, como un solo departamento o una sola unidad
operacional. Cuando esta versión piloto está completa y trabaja de manera
uniforme, se instala en el resto de la organización, ya sea de manera simultánea o
en etapas.

La estrategia de metodología en fases introduce el nuevo sistema en etapas, ya

sea con base en las funciones o las unidades organizacionales.

Por ejemplo, si el sistema se introduce con base en la función, un nuevo sistema

de nómina podría empezar con trabajadores por horas que reciban un pago

semanal, para seis meses después agregar empleados asalariados (que reciben
pago mensual) al sistema. Si éste se introduce con base en la unidad

organizacional, podrían convertirse primero las oficinas corporativas, seguidas de

las unidades de operación periféricas cuatro meses después.

Para cambiar de un sistema antiguo a uno nuevo es necesario capacitar a los
usuarios finales para que utilicen el nuevo sistema. La documentación detallada
que muestre cómo funciona el sistema, desde un punto de vista tanto técnico
como para el usuario final, se completa durante el tiempo de conversión para
usarla en las operaciones diarias y en la capacitación.

La falta de capacitación y documentación adecuadas contribuye a que el sistema

fracase, por lo que esta parte del proceso de desarrollo de sistemas es muy
importante.

Producción y mantenimiento.

Una vez que se instala el nuevo sistema y se completa el proceso de conversión,

se dice que está en producción. Durante esta etapa, tanto los usuarios como los
especialistas técnicos usarán el sistema para determinar qué tan bien ha cumplido
con sus objetivos originales, y para decidir si hay que hacer alguna revisión o
modificación. En ciertos casos, se prepara un documento formal de auditoría
posimplementación. Una vez que el sistema se pone a punto, hay que darle
mantenimiento mientras está en producción para corregir errores, cumplir con los
requerimientos o mejorar la eficiencia del procesamiento. Los cambios en
hardware, software, en la documentación o los procedimientos de un sistema en
producción para corregir errores, cumplir con los nuevos requerimientos o mejorar
la eficiencia del procesamiento se denominan mantenimiento.
Cerca del 20 por ciento del tiempo dedicado al mantenimiento se utiliza para
depurar o corregir problemas de emergencia en producción. Otro 20 por ciento
trata con los cambios en los datos, archivos, informes, hardware o software del
sistema. Sin embargo, el 60 por ciento de todo el trabajo de mantenimiento
consiste en realizar mejoras para los usuarios, mejorar la documentación y volver
a codificar los componentes del sistema para obtener una mayor eficiencia en el
procesamiento. La cantidad de trabajo en la tercera categoría de los problemas de
mantenimiento se podría reducir de manera considerable por medio de mejores
prácticas de análisis y diseño de sistemas. La siguiente tabla sintetiza las
actividades de desarrollo de sistemas.

DESARROLLO DE SISTEMAS.