Parte II

Introducción al Análisis y
Diseño de Sistemas
Introducción a los sistemas de información. Cómo se desarrollan los sistemas de información.
El paradigma orientado a objetos, UML y el proceso unificado.

Esta parte del curso consta de los fundamentos de tres tópicos que contienen la información
básica necesaria para realizar el ​análisis y diseño de sistemas o, dicho de una manera más
precisa, el ​análisis y diseño de los sistemas orientados a objetos apoyándose en el UML y
el proceso unificado (PU)​. Estos tópicos explican qué es el análisis y diseño de sistemas, qué
significa la frase "orientado a objetos" y lo que son el UML y el proceso unificado y por qué son
tan importantes.

Capítulo 1​. Introducción a los sistemas de información. Este capítulo proporciona información
básica sobre los sistemas de información. El tema principal de este tópico son las fases del
ciclo de vida del desarrollo de sistema de información tradicional.

Capítulo 2​. Se cubren aspectos de ¿Cómo se desarrollan los sistemas de información?.

Mientras que en el capítulo 1 describe cómo se desarrollarían los sistemas de información en
un mundo ideal, en el capítulo 2 se explica con detalle por qué esto no ocurre en la práctica. La
mayor parte del capítulo se dedica al ciclo de vida iterativo y por incrementos, la manera en la
cual por lo general se desarrollan en el mundo real.

Capítulo 3​. El paradigma orientado a objetos, UML y el proceso unificado es el título del
capítulo 3. La aproximación (“estructurada") tradicional para desarrollar sistemas de
información ha probado ser poco satisfactoria para los sistemas de información más grandes.
El paradigma orientado a objetos es la aproximación moderna para desarrollar los sistemas de
información. Este se explica con detalle en el capítulo 3, el cual también contiene una
introducción al UML y el proceso unificado.
Capítulo 1.

Introducción a los sistemas de

información
Objetivos de aprendizaje. ​Después de estudiar este capítulo, usted podrá:

● Definir qué se quiere decir con análisis y diseño de sistemas.

● Describir el ciclo de vida de sistemas de información tradicional.
● Discutir la importancia de la evaluación, aplicación de pruebas y documentación
continuas.
● Describir los diferentes tipos de sistemas de información.
● Describir la organización de los servicios de información.
● Apreciar la importancia de observar un código de ética.
La empresa ​AgroPlus​, está perdiendo dinero. La mayoría de los clientes viven en poblados
aislados a tres horas o más en auto. Después de un largo viaje a la tienda principal, los
agricultores esperan que los productos agrícolas que desean comprar esté disponible. Sin
embargo, últimamente más y más clientes se han dado cuenta de que la proveedora ​AgroPlus​,
olvida contactar a los mayoristas para pedir un reabastecimiento de productos y suministros
agrícolas que vendió a otros clientes. Molestos por su expedición infructuosa a ​AgroPlus,​
cuando regresan a sus siembras hacen un pedido de los insumos a ​revendedores informales​,
reduciendo el volumen de ventas y las ganancias de la compañía.

AgroPlus decide que lo que necesita es un ​sistema automatizado para hacer pedidos,​ así
que contacta a GlobalTech Consultores, C.A., una empresa local de desarrollo.

Le comenta a Pascual Troncone, un analista de sistemas que trabaja en GlobalTech

Consultores, que le gustaría que cuando un cajero pase por el escáner el código de barras de
un producto agrícola que compre un cliente en AgroPlus, el sistema registre los detalles de ese
producto. Al final del día, el sistema debe contactar automáticamente a los mayoristas que
abastecen de mercancía a AgroPlus y hacer el pedido de cada producto vendido ese día.
Cuando llegue el pedido de reposición de productos que envían los mayoristas, los datos
deben registrarse de modo que el sistema de información pueda añadirlos a la base de datos
de productos en existencia.

El consultor de sistema le asegura a AgroPlus que eso no es problema. De hecho, GlobalTech

Consultores desarrolló un sistema como ése hace algunos años y ofrece a AgroPlus
proporcionarle una larga lista de clientes que le dirán lo felices que están de que GlobalTech
les haya instalado el sistema automatizado para hacer pedidos en sus tiendas.

Pero AgroPlus no considera que este sistema estándar sea lo adecuado para sus necesidades.
Le dice a GlobalTech que además de hacer pedidos y actualizar las existencias en forma
automática, el sistema debe detectar nuevas tendencias en las compras de los clientes. De
esta manera, si las ventas de un determinado producto de pronto aumentan de una semana a
la otra, el sistema de información debe hacer un pedido adicional de este, de manera
automática. AgroPlus muestra a GlobalTech la fórmula que debe utilizar para calcular el
número de productos adicionales por ordenar. La fórmula que AgroPlus ha desarrollado es
compleja, pero la cuestión es que entre mayor sea el incremento en las ventas cada semana,
mayor será el número de productos que se deben pedir.

GlobalTech desarrolla el sistema de AgroPlus y lo instala. Durante los primeros siete meses
todo va bien. El sistema automatizado para hacer pedidos funciona de manera correcta. Casi
todos los clientes encuentran los productos y las cantidades deseadas y una vez más AgroPlus
está obteniendo una ganancia sustancial. Sin embargo, la porción del sistema que detecta las
nuevas tendencias no se ha desencadenado ni siquiera una vez durante esos siete meses.

Entonces, un buen día, un general acaudalado, propietario de un finca, pasa por AgroPlus y ve
un fertilizante nuevo para tierras muy secas en el mostrador. Le llama la atención dado que ese
es el tipo de tierra de su finca. Entra, en la sala y ve las especificaciones técnicas y le parecen
muy apropiadas. Realiza la compra y sale de la tienda rumbo a su finca con la mercancía.
Maneja de regreso a su finca y en todo el trayecto de regreso no hace más que pensar en sus
cultivos y en lo ventajoso de utilizar este fertilizante.

Durante la semana siguiente el sistema automatizado para hacer pedidos se asegura de que
AgroPlus tenga en existencias toda la variedad de fertilizantes. Esto es bueno, porque una
semana después los agricultores de las zonas bajas, vecinos del general acaudalado, van a
AgroPlus a comprar ese fertilizante. Toda la semana el general acaudalado no ha hecho otra
cosa que hablar de la ventaja de fertilizar sus tierras con ese nuevo producto, acortando
tiempo de cosecha y ahorrando dinero, por lo cual sus vecinos agricultores piensan que para
que el general deje de hablar todo el día del tema, deben ellos comprarlo también.

Como resultado, las ventas de ese fertilizante saltan de 10 sacos a cuarenta sacos por
semana. Al final, esto desencadena una nueva tendencia en la venta de fertilizantes y el
sistema hace un pedido en forma automática para duplicar las existencias de este fertilizante a
1320 sacos.

Lamentablemente, la compra que hacen los vecinos no logra apagar el entusiasmo del general.
De hecho, él aprecia tanto el fertilizante que piensa que la próxima vez que esté en el pueblo
comprara un un camión completo de fertilizante. Sí, el costo será grande, pero el general está
seguro de que pronto recuperará el gasto a través de una mayor productividad en menor
tiempo y un aumento en la cosecha. Así que cuando va al pueblo una semana después para
firmar un contrato de ganado, pasa por AgroPlus y compra los 1320 sacos.

AgroPlus está totalmente encantado. Su sistema de información le ha costado una cantidad

considerable de dinero. Sin embargo, el sistema automatizado para hacer pedidos y la parte del
sistema que detecta las tendencias futuras casi se han pagado por sí solos con el aumento en
las ganancias y, por lo tanto, las existencias de pedidos adicionales con base en su fórmula se
han justificado con la venta de 132 sacos, la mayor venta que ha tenido hasta entonces.

AgroPlus pasa los siguientes días contándoles a todos sus conocidos de su brillante fórmula
para hacer pedidos con base en las tendencias futuras detectadas, hasta el final de la semana,
cuando, como resultado del aumento en las ventas semanales de 40 a 1320 sacos, AgroPlus
recibe un pedido de 56.943 sacos.

Hay muchas lecciones que aprender de esta historia. Quizá la más importante es que nuestra
tarea como analistas de sistemas es trabajar con los clientes para determinar el sistema de
información que necesitan, el cual no siempre es el sistema de información que creen
necesitar.
1.1 Sistemas de información

Un sistema es una serie de artefactos (componentes) que en conjunto logran algún resultado.
Un s​istema de información es aquel que logra un resultado empresarial. Dicho con más detalle,
un sistema de información recopila, manipula, almacena y crea reportes de información
respecto de las actividades de negocios de una empresa, con el fin de ayudar a la
administración de esa empresa en el manejo de las operaciones de negocios.

Hay dos categorías importantes de sistemas de información computarizados: los ​sistemas de

información personalizados y los paquetes comerciales de distribución general. Un ​sistema de
información personalizado es aquel que se ha desarrollado para un cliente específico, del
mismo modo que se hace un traje a la medida para un individuo. Por ejemplo, el sistema de
información desarrollado para AgroPlus es un sistema de información personalizado, ninguna
otra compañía utiliza el componente de detección de la tendencia en productos agrícolas.

Los tres actores principales cuando se ​desarrolla (​ construye) un sistema de información son:

● El​ cliente,​ quien paga por el sistema de información que se va a desarrollar.

● Los​ usuarios​ futuros del sistema de información.
● Los ​desarrolladores​ de ese sistema de información.

La tarea de los desarrolladores es determinar las necesidades del cliente y desarrollar un

sistema de información que satisfaga dichas necesidades y pueda ser utilizado por los
usuarios. Otro ejemplo de un sistema de información del cliente es un ​sistema de información
de administración para una importante compañía arrendadora de autos. Los sistemas de
información personalizados son costosos y una empresa podría verse tentada a recuperar
parte del costo vendiendo una copia de su sistema de información personalizado a un
competidor. Es poco probable que, por ejemplo, Hertz opera exactamente de la misma manera
que, por ejemplo, RentalCars. Por esta razón, el mercado de reventa para los sistemas de
información personalizados en general es pequeño. Pero lo que es más importante, un sistema
de información personalizado incorpora el modelo de negocios de la empresa que lo encargó y
vender una copia de este sistema de información personalizado significa entregar información
propia a la competencia. Volviendo al ejemplo, si Hertz permitiera que su sistema de
información personalizado se vendiera a un competidor, éste se daría cuenta del modelo de
negocios de Hertz y esta empresa perdería su ventaja de negocios.

Por el contrario, se venden muchas copias de un ​paquete comercial de distribución general

(Paquetes de sistemas administrativos). Ejemplo de estos son Profit, SAINT, A2, GALAC, entre
otros.

Sólo hay dos interesados importantes para un paquete administrativos:

● Los ​desarrolladores.​
● Los ​usuarios.​
Un ​sistema de información personalizado se desarrolla para satisfacer las necesidades de un
cliente, mientras que los ​paquetes administrativos fueron concebidos con la idea de
proporcionar funciones que satisfagan las necesidades de un grupo de usuarios lo más grande
posible.

Algunos paquetes administrativos son relativamente pequeños y baratos, y tienen la intención

de satisfacer las necesidades de sistemas de información de empresas pequeñas. Por ejemplo,
un paquete de contabilidad integrado con un paquete de impuestos satisfará la mayor parte de
las necesidades del sistema de información de una compañía de plomería o de una tienda de
reparación de computadoras. En contraposición, un ​sistema de planeación de los recursos de
la empresa (ERP: ​enterprise resource planning​) como PeopleSoft o SAP es un paquete enorme
dirigido a cubrir casi todas las necesidades de una empresa grande, incluyendo la contabilidad,
la nómina, el inventario, las ventas, las compras, el personal, etc. Un paquete como éste a
menudo cuesta millones de dólares y requiere meses (si no es que años) adaptar el paquete a
los requisitos específicos de cada empresa que lo compra. Esta adaptación de un ERP es una
forma de personalización. En otras palabras, existen sistemas de información personalizados
puros, y también paquetes administrativos puros que se usan sin cambios. En medio están los
sistemas ERP que necesitan adaptarse a cada empresa específica que los usa.
1.2 Desarrollo del sistema de información tradicional
El ciclo de vida del sistema de información es la manera en que se construye el sistema de
información. Debido a que casi siempre es más fácil realizar una secuencia de tareas pequeñas
que una tarea grande, el ciclo de vida general se divide en una serie de pasos pequeños
llamados fases. El número de fases varía de empresa a empresa, puede haber tan pocas como
cuatro o tantas como ocho. Comúnmente hay seis fases, que se listan en a continuación. Cada
una de estas fases se describe a continuación con detalle.

1. Fase de requisitos
2. Fase de análisis
3. Fase de diseño
4. Fase de implementación
5. Fase de Mantenimiento
6. Retiro

1.2.1 La fase de requisitos

En la fase de requisitos se extraen los requisitos del cliente. Es decir, el cliente y los futuros
usuarios del sistema de información por desarrollar interactúan con el equipo de desarrollo de
sistemas de información con el fin de determinar las necesidades del cliente. Los resultados de
este estudio se presentan en forma de un​ documento de requisitos​.

En el caso del sistema de información desarrollado por AgroPlus, el documento de requisitos

lista las necesidades de AgroPlus relacionadas con los pedidos automatizados, así como con
sus necesidades respecto de detectar y reaccionar a las nuevas tendencias en compras de
productos agrícolas. Debido a que el sistema de información de AgroPlus es relativamente
sencillo, el documento de requisitos consta de solo unas cuantas páginas, con una lista de
necesidades específicas.

1.2.2 La fase de análisis

La segunda fase es la de ​análisis.​ El objetivo de esta es preparar el documento de
especificaciones. El ​documento de especificaciones (o las ​especificaciones​) plantea lo que
debe hacer el sistema de información. Si el sistema de información entregado satisface las
especificaciones funcionales, entonces el cliente paga a los desarrolladores lo que cuesta el
sistema de información. Si no, los desarrolladores tienen que corregirlo hasta que cumpla con
las especificaciones. ​Las especificaciones funcionales describen lo que el sistema de
información es capaz de hacer.​ Una vez que el cliente aprueba el documento de
especificaciones, puede redactarse el ​plan de administración de proyectos.​ Este plan detallado
incluye un ​presupuesto,​ las necesidades de ​personal ​y una lista de ​módulos del sistemas que
se entregará al cliente y cuándo.

A diferencia del documento de requisitos relativamente informales, un documento de

especificaciones en esencia es un contrato entre el cliente y los desarrolladores. Por lo tanto,
en el caso del AgroPlus y GlobalTech, el documento de especificaciones funcionales describe
con detalle lo que hará el sistema. Especifica la entrada (el código de barras en los productos
fertilizantes) y las distintas salidas, incluyendo los pedidos generados en forma automática;
informes/reportes que listan las ventas al público y las compras a los mayoristas. Además, el
documento de especificaciones describe de manera precisa cómo el sistema determinará
cuando hay una nueva tendencia en ventas de fertilizantes y cuántos sacos adicionales se van
a pedir si se detecta una nueva tendencia. Esta última parte del documento de especificaciones
se basan en las fórmulas proporcionadas por AgroPlus.

1.2.3 La fase de diseño

La ​fase de diseño viene a continuación. Aquí los miembros del equipo de desarrollo describen
cómo se va a desarrollar el sistema de información​. Por lo general, el sistema se divide en
piezas pequeñas llamadas ​módulos.​ Cada módulo se diseña posteriormente con detalle; el
equipo de desarrollo describe los ​algoritmos ​usados por el módulo (es decir, como el módulo
realiza esta tarea) y las ​estructuras de datos dentro del módulo (es decir, los datos con los
cuales va a operar el módulo). El resultado se presenta en forma de un documento de diseño.

El sistema de información de AgroPlus se compone de varios módulos. Algunos de ellos

manejan los pedidos automatizados con base en las ventas y algunos de los pedidos
adicionales como una consecuencia de la detección de nuevas tendencias en la venta de
fertilizantes.

Con el fin de apreciar la diferencia entre un documento de especificaciones y un documento de

diseño, considere el informe de ventas que AgroPlus quiere imprimir al final de cada semana.
El documento de especificaciones establece que el informe debe incluir las compras semanales
de fertilizantes de cada uno de los mayoristas y el total general de ventas. Es decir, el
documento de especificaciones lista ​lo que se va imprimir. Por otro lado, el documento de
diseño establece en qué parte de la página va a aparecer el logo (esquina superior derecha),
cuáles serán los encabezados de columna (“Fecha", "Mayorista" y "Ventas”), cuántos
caracteres se utilizarán para el nombre del mayorista, cuántos espacios en blanco se deben
dejar y luego cuántos dígitos se usarán para el total semanal de ventas de fertilizantes de ese
mayorista y así por el estilo. En otras palabras, el diseño del informe establece ​cómo s​ e va
imprimir el informe.

1.2.4 La fase de implementación

La cuarta fase es la de implementación. Los diseños de los módulos se entregan al equipo de
programación para que los traduzcan en un lenguaje de programación apropiado. Python es
uno de los lenguajes de programación más usado en el mundo. Podemos listar varios ,entres
los cuales se encuentran: C, Java, Perl, PHP, entre otros. Los módulos se integran (se
combinan) para formar el sistema de información completo.

1.2.5 La fase de mantenimiento

Después de que se ha instalado el sistema de información, necesitará modificarse, ya sea para
eliminar cualquier falla restante o porque necesita ampliarse de alguna manera. Esta quinta
fase se llama fase de mantenimiento.

En el caso del sistema de información desarrollado para AgroPlus, la primera operación de

mantenimiento fue, lo cual no es sorprendente, desactivar la parte del programa que hacía un
pedido automático de más sacos de fertilizantes cuando detectaba una nueva tendencia en la
compra de éstos. En vez de ello, ahora el sistema imprimía un informe de modo que AgroPlus
pudiera decidir si en realidad había una nueva tendencia o no, y en caso afirmativo pudiera
decidir de cuántos sacos adicionales sería el pedido.

1.2.6 El retiro
Finalmente, después de 10, 15 o más años de mantenimiento, un sistema de información se
retira si ya no da un servicio útil.

1.3 ¿Por qué no hay una fase de planificación?

¿Cómo es posible desarrollar un sistema de información administrativo sin un plan? La
respuesta es simple: ​no se puede​. Pero en ese caso, ¿​por qué no hay una fase de
​
planificación al principio del proyecto?

La principal observación es que hasta saber exactamente qué se va a desarrollar, no hay

manera de idear un plan detallado preciso. Por lo tanto, hay tres tipos de actividades de
planificación que ocurren cuando se desarrolla un sistema de información:

● Primero​, se lleva a cabo la planificación preliminar de modo que se puedan manejar las
fases de análisis y requisitos.
● Segundo​, una vez que se sabe con precisión lo que se va a desarrollar, se idea el ​plan
de administración de proyectos.​ Este incluye el ​presupuesto,​ los ​requisitos de personal y
un ​calendario detallado. Lo más pronto que puede idearse el ​plan de administración de
proyectos es cuando el ​cliente h​ a aprobado el ​documento de especificación​. Hasta ese
momento la planificación tiene que ser preliminar y parcial.
● Tercero​, a lo largo de todo el proyecto la administración necesita supervisar el plan de
administración y estar al pendiente de cualquier desviación. Por ejemplo, suponga que
el ​plan de administración del proyecto específico establecía que la fase de diseño
tardaría cuatro meses. Sin embargo, ya han pasado 12 meses y no parece que el
proyecto esté muy avanzado. Es casi seguro que se debe abandonar y los fondos
 invertidos a la fecha se habrán desperdiciado. En vez de ello, la administración debe
notar después de dos meses máximo que hay un problema serio con la fase de diseño.
En ese momento se podría tomar una decisión de cuál es la mejor manera de proceder.
​ ara
Por lo general, el paso inicial en una situación como ésta es llamar a un ​consultor p
determinar si el proyecto es factible y si el equipo de diseño es competente para realizar
la tarea o si el riesgo en caso de continuar es muy grande. Con base en el reporte del
consultor ahora se consideran varias alternativas, que incluyen la reducción del alcance
del objetivo del sistema de información y luego diseñar e implantar uno menos
ambicioso. El proyecto sólo debe cancelarse si todas las demás alternativas se
consideran prácticas. En el caso del proyecto específico, esta cancelación habría
ocurrido 10 meses antes si la administración hubiera supervisado el plan de cerca,
ahorrando, por consiguiente, una suma considerable de dinero.

En otras palabras, no hay una fase de planificación separada. En vez de ello, las actividades de
planificación se realizan a lo largo de todo el ciclo de vida. No obstante, hay ocasiones en que
las actividades de planificación predominan. Éstas incluyen el inicio del proyecto (planificación
preliminar) e inmediatamente después el documento de especificaciones que ha aprobado el
cliente (plan de administración de proyectos).

1.4 ¿Por qué no hay una fase de pruebas?

¿Por qué no hay una fase de pruebas? Sin duda es esencial verificar con mucho cuidado un
sistema de información después de que se ha desarrollado.

Lamentablemente, verificar el sistema de información una vez que está listo para ser entregado
al cliente es demasiado tarde. Por ejemplo, si hay una ​falla en el documento de
especificaciones, ésta se pasará al diseño y a la implementación. Suponga que el documento
de especificaciones para AgroPlus incluye la frase incorrecta de que ​los fertilizantes están
exentos de impuestos sobre ventas (IVA).​ Entonces el diseño del sistema de información no
incluye el cálculo de los impuestos sobre ventas ni tampoco lo incluye la implementación. Si el
sistema de información no se hubiera revisado hasta estar completo, entonces cuando la falla
se descubriera finalmente sería necesario hacer cambios importantes al sistema. Primero, el
documento de especificaciones habría tenido que corregirse para reflejar el hecho de que el
impuesto sobre ventas si se aplica a los fertilizantes. Segundo, el diseño tendría que
modificarse en los lugares apropiados. Tercero, estos cambios también se hubieran tenido que
hacer dentro del código. Sin embargo, si el documento de especificaciones se revisa antes de
que se inicie el diseño, sólo se tendría que modificar el documento de especificaciones y
únicamente en la parte que se refiere al impuesto sobre ventas. La conclusión obvia es que,
además de revisar el sistema de información como un todo cuando esté completo (​validación​),
el sentido común dicta que también debe revisarse al final de cada fase (​verificacion​).
Pero incluso esto no es suficiente. Se requiere la revisión continua de un sistema de
información. No necesita decirle a un profesional de la tecnología de la información que se
relaje mientras está desarrollando un sistema. De la misma manera, una verificación cuidadosa
debe ser un acompañante automático de cada actividad de desarrollo del sistema de
información. A la inversa, una fase de pruebas separada es incompatible con el objetivo de
asegurar que un sistema esté lo más libre de fallas posible en cualquier momento.

1.5 ¿Por qué no hay una fase de documentación?

Del mismo modo que nunca debe haber una fase de planeación o una fase de pruebas
separadas, nunca debería haber una ​fase de documentación separada. Por el contrario, en
todo momento la documentación del sistema de información debe estar completa, ser correcta
y estar actualizada. Por ejemplo, durante la fase de análisis, el documento de especificaciones
debe reflejar la versión actual de las especificaciones, lo mismo que para otras fases.

● Una razón por la cual es esencial asegurar que la documentación siempre esté
actualizada es la gran rotación de personal en las empresas de desarrollo de sistemas
de información. Por ejemplo, suponga que la documentación del diseño no se ha
actualizado y que el jefe de diseñadores renuncia para tomar otro empleo. Ahora será
sumamente difícil actualizar el documento de diseño para reflejar los cambios que se
hicieron mientras se diseñaba el sistema.
● Una segunda razón es que resulta casi imposible seguir los pasos de una fase
específica a menos que la documentación de la fase anterior esté completa, sea
correcta y esté actualizada. Por ejemplo, un documento de especificación incompleto
debe dar como resultado un diseño incompleto y, por lo tanto, una implementación
incompleta.
● Tercero, es virtualmente imposible probar si un programa funciona correctamente a
menos que haya documentos que establezcan cómo se supone que se comportará ese
programa (Documento de especificación de pruebas). Por ejemplo, no habría sido
posible probar la parte del programa que se encarga de la detección de una nueva
tendencia en la compra de fertilizantes, a menos que el documento de especificaciones
explicara con exactitud qué constituye una nueva tendencia y de cuántos sacos
adicionales va a ser el pedido.
● Cuarto, el mantenimiento es casi imposible a menos que haya una serie completa y
correcta de documentación que describa de manera precisa qué hace la versión actual
del sistema.

Por lo tanto, del mismo modo que no hay una fase de planificación o de pruebas separada,
tampoco hay una fase de documentación separada. En vez de ello, la planificación, la
aplicación de pruebas y la documentación deben ser actividades que acompañen a todas las
demás tareas mientras se construye un sistema de información.
1.6 Análisis y diseño de sistemas
Dentro del contexto del desarrollo tradicional de sistemas de información, el término ​análisis de
sistemas se refiere a las primeras dos fases (de requisitos y análisis) y ​diseño de sistemas se
refiere a la tercera fase, la de diseño.

Por desgracia, la terminología del desarrollo tradicional de sistemas de información puede

conducir fácilmente a una confusión:

● ​ or sí mismo se usa para denotar sólo la segunda fase. Es decir,

El término ​análisis p
mientras análisis de sistemas se refiere a la primera y segunda fases del desarrollo
tradicional de sistemas de información, ​análisis ​se refiere sólo a la segunda. No hay
duda de que estos dos usos diferentes de la palabra "análisis” son muy confusos, pero
simplemente no es posible cambiar la terminología utilizada en la tecnología de la
información durante los 50 años anteriores.
● El término ​analista de sistemas también se utiliza con dos sentidos diferentes. En
algunas empresas la tarea de los ​analistas de sistemas es determinar las necesidades
del cliente en relación a un sistema de información (fase de requisitos) y luego elaborar
el documento de especificaciones para registrar formalmente lo que se debe desarrollar
(fase de análisis). Luego, los ​diseñadores de sistemas planean el sistema que se quiere
crear. No obstante, en la mayoría de las empresas no hay desarrolladores de sistemas
independientes. Los analistas, por lo tanto, son responsables de las tres primeras fases,
a saber, las de requisitos, análisis y diseño. En esta guia didactica de estudio se usa el
término "analista de sistemas" en este segundo sentido debido a que es el método de
uso más común en la industria de los sistemas de información.

1.7 Mantenimiento
Una concepción errónea común es que sólo un sistema de información malo debe modificarse
después de la instalación. Por el contrario, los sistemas de información malos se botan a la
basura, mientras los sistemas de información buenos se modifican durante muchos años. La
figura 1.2 es un diagrama clave. Representa el porcentaje promedio de tiempo (=dinero)
dedicado a un sistema antes de la instalación (​desarrollo)​ y después de la instalación
(​mantenimiento)​ en la computadora del cliente [Hatton, 1998; Schach, 2002].
Al observar la figura 1.2, es claro que, en promedio, por cada dólar gastado en desarrollo, se
gastan dos en mantenimiento. De hecho, algunos expertos afirman que la figura 1.2 se queda
corta y que por cada dólar gastado en desarrollo, se gastan tres o más en mantenimiento
durante la vida del sistema de información (Yourdon, 1992). Ya sea que la razón 1:2 calculada
por lo bajo entre el dinero gastado en desarrollo y en mantenimiento que se muestra en figura
1.2 sea correcta, o que la razón real sea 1:3, es claro que el mantenimiento es la fase más
importante del ciclo de vida del sistema de información.

Hay tres actividades de mantenimiento principales:

● El ​mantenimiento correctivo es la reparación de las fallas del sistema de información,

que con frecuencia están en el código, pero el mantenimiento correctivo también incluye
la reparación de todos los demás artefactos de un sistema de información, incluyendo el
documento de especificaciones, el documento de diseño, los manuales, etcétera.
● El ​mantenimiento perfectivo consiste en los cambios hechos al sistema de información
debido a que el cliente desea ampliar las funciones del sistema. Por ejemplo, el cliente
puede querer que el sistema tenga un tiempo de respuesta más corto o sea capaz de
manejar la conversión de precios a euros además de a dólares.
● Cuando hay un cambio en el entorno en el cual opera el sistema de información, éste
debe modificarse. A esto se le llama ​mantenimiento adaptativo​. Por ejemplo, si el tipo de
impuesto sobre las ventas cambia, cualquier sistema de información relacionado con la
compra y venta debe cambiar en consecuencia. Además, si el sistema de información
debe cambiarse de modo que pueda correr en una computadora diferente o con un
sistema operativo diferente, también se considera mantenimiento adaptativo.

Ahora considere los mantenimientos perfectivo y adaptativo, los cuales se conocen en conjunto
como ​mejoramiento​. Cuando se realiza un mejoramiento los requisitos cambian. Hablando en
términos más específicos, en el caso del mantenimiento perfectivo los requisitos varían porque
el cliente quiere que se amplíen las funciones del sistema; en el caso del mantenimiento
adaptativo, los requisitos cambian porque el entorno ha cambiado. En ambos casos hay un
cambio en los requisitos, que a su vez induce a variantes en el documento de especificaciones,
documento de diseño e implementación.

En otras palabras, cada mejoramiento de un sistema de información puede verse como un ciclo
de vida completo en sí mismo, comenzando con la fase de requisitos y terminando con la
implementación. Se debe reconocer que la planificación, la aplicación de pruebas y la
documentación son aspectos intrínsecos del mejoramiento, ya que forman parte de la actividad
de todo sistema de información, sin excepciones.

Como se mencionó antes, el término ​análisis de sistemas se refiere a las fases de análisis y
requisitos del ciclo de vida del sistema de información, y diseño de sistemas se refiere a la fase
de diseño. Pero, como también se señaló antes, las actividades del análisis y diseño de
sistemas se llevan a cabo no sólo durante el desarrollo, sino también durante el mejoramiento.

Como se refleja en la figura 1.2, se invierte el doble de tiempo en el mantenimiento que en todo
el desarrollo.
1.8 Profesionales de la tecnología de la información
El ​software ​consiste no sólo en las instrucciones a la computadora (el programa de
computadora o el código), sino también en toda la documentación que es un componente
intrínseco de cada proyecto. Por lo tanto, el software incluye los documentos de
especificaciones, de diseño y legales, y de contabilidad de todo tipo, el plan de administración
de proyectos y otros documentos de administración, así como todo tipo de manuales.

Los profesionales de la tecnología de la información trabajan en dos tipos de organizaciones.

Primero, hay algunas como Google, Facebook, Apple, Microsoft, Inc. y Oracle, Inc., cuya
actividad principal es la producción de software. Éstas varían en tamaño desde gigantes como
Google (al momento de escribir esto, es la primera compañía más grande en el mundo con
base en la capitalización de mercado), hasta individuos que desarrollan software en casa.

Por otra parte, una empresa como General Motors (GM) tiene un grupo de software enorme
dentro de su división de servicios de información, al igual que General Electric (GE). La
diferencia entre GM Y GE, por una parte, y Google y Facebook por otra, es que el software no
es un producto de primera necesidad de GM Y GE. Por ejemplo, aun cuando en la actualidad
es inconcebible pensar en un automóvil GM sin computadoras que controlan el motor, es
importante tener presente que el auto es un producto principal de GM; el software en él es sólo
un componente, como el cinturón de seguridad o los faros.

Muchas empresas más pequeñas también tienen analistas de sistemas para realizar las
primeras tres fases del ciclo de vida del sistema de información dentro de esa empresa. En
particular, virtualmente cada empresa de comercio electrónico (conocidas como dot-com, que
significa punto-com), sin importar qué tan pequeña sea, tiene una división de sistemas de
información para manejar ese aspecto del negocio.

Así, los profesionales de la tecnología de la información son empleados por compañías de

todos tamaños, tanto aquellas donde el software es el producto principal como aquellas donde
es sólo un componente de sus productos. Además, en cada empresa los sistemas de
información manejan las actividades de misión-crítica. (Si una actividad de misión-crítica se
termina, la empresa ya no puede realizar las actividades básicas del negocio. Para algunas
compañías las actividades de misión-crítica incluyen la compra o la venta; para la mayoría,
mantener sus registros es de fundamental importancia.) Por ejemplo, una compañía de seguros
como tiene una división enorme de servicios de información, responsable de los sistemas que
manejan cada aspecto de su operación, desde los servicios a los asegurados hasta el
mantenimiento de los registros de los bienes raíces.

La mayor parte de las empresas importantes emplean sus propios analistas de sistemas. Unas
cuantas empresas importantes y muchas empresas más pequeñas contratan proveedores
externos; es decir, otras compañías, como GlobalTech Consultores, C.A., para manejar todos
los aspectos de sus sistemas de información. Algunas empresas tienen su propio personal de
mantenimiento, pero contratan proveedores externos para el desarrollo de nuevos sistemas de
información; los sistemas desarrollados por compañías que se especializan en ella se llaman
sistemas de información por contrato.

La estructura de organización tradicional para una división de servicios de información dentro

de una empresa grande se representa en la ​figura 1.3​. El puesto técnico de nivel básico dentro
de muchas divisiones de servicios de información es el de programador. Después de obtener
experiencia al implementar diseños en el código, el de programador puede ser promovido a
programador-analista, donde él o ella adquirirán experiencia en el análisis y diseño de sistemas
mientras que seguirá involucrado en actividades de programación. El siguiente nivel es el de
analista de sistemas, que se encarga del análisis y el diseño de sistemas. La siguiente
promoción es un puesto gerencial, con frecuencia gerente de desarrollo de sistemas de
información. Esta es una asignación de nombre del puesto que se queda corta porque, como
se explicó en la sección 1.7, la vasta mayoría de sus actividades se refieren al mantenimiento,
no al desarrollo. Los gerentes de desarrollo reportan al director de desarrollo de sistemas de
información, quien es el gerente de desarrollo con mayor responsabilidad en la empresa. Este
director, a su vez, reporta al jefe de información (CIO: chief information officer), quien es
responsable de todos los aspectos de tecnología informática dentro de la organización,
incluyendo el hardware, software, conectividad en red, seguridad, etc. El CIO, a su vez, reporta
al presidente (CEO: chief executive officer).
Un ​analista de sistemas necesita tener varias habilidades. Las de carácter técnico son
esenciales —todos los analistas de sistemas deben conocer las técnicas modernas de análisis
de sistemas y ser capaces de aplicarlas de manera eficaz—. Las habilidades de comunicación
son importantes por igual. El analista de sistemas tiene que comunicarse tanto verbalmente
como por escrito con el cliente y los usuarios futuros del sistema de información, así como con
sus propios gerentes. Además, los analistas de sistemas tienen que poder programar, aun
cuando, por lo general, su trabajo no incluye las tareas de programación. La razón es que el
diseño del sistema que ellos producen es la principal fuente de instrucción de los analistas de
sistemas para los programadores. A menos que los analistas estén familiarizados con los
conceptos de programación, es probable que la comunicación escrita y oral con los
programadores esté propensa a tener errores.

Una manera de asegurar que los analistas puedan programar es promover a los mejores
programadores a puestos de analistas, como se describió antes. Aun cuando es lo que se
acostumbra, muchas empresas han observado que un buen programador con frecuencia se
vuelve un mal analista de sistemas. Otra ruta de carrera en nuestros días es que un analista de
sistemas comience como un analista de negocios; es decir, un especialista en resolver
problemas de negocios. Una vez que un analista de negocios ha adquirido experiencia en
programación, tal vez al tomar un curso apropiado en una universidad, podría contemplarse su
promoción a analista de sistemas.

La figura 1.3 muestra las categorías de puestos principales dentro de una organización de
servicios de información tradicional. Por lo general, también hay una serie de especialistas
técnicos. Por ejemplo, el administrador de bases de datos es responsable de todos los
aspectos de la base de datos y de su sistema de administración, y el administrador de red se
encarga de la red de área local (LAN). Los programadores de sistemas mantienen el software
del sistema operativo. Los miembros del grupo de aseguramiento de la calidad son
responsables de asegurar que no haya fallas en el software. Los ingenieros de software son
especialistas en el desarrollo y mantenimiento del mismo. Los analistas de sistemas consultan
a estos especialistas técnicos cuando es necesario. Es decir, los analistas, por lo general, no
se especializan en ninguna de estas áreas técnicas, pero saben suficiente sobre cada una
como para poder utilizar el consejo de los especialistas técnicos de una manera efectiva.

Este guía concluye con una recomendación. Al margen de cómo se organice la división de
servicios de información, en resumidas cuentas los sistemas de información son desarrollados
por seres humanos. Si esos individuos son trabajadores, inteligentes, sensibles, están
actualizados y sobre todo son éticos, entonces hay buenas posibilidades de que la manera en
que los sistemas de información se desarrollan dentro de esa empresa sea satisfactoria.
Lamentablemente, lo contrario es verdadero de la misma manera.

La mayoría de las sociedades para los profesionales del procesamiento de la información tiene
un código de ética al cual deben apegarse todos sus miembros. Por ejemplo, el código de ética
de la Association of Information Technology Professionals (AITP) incluye los párrafos siguientes
[AITP; 1997):

Reconozco:

Que tengo un compromiso con mi colegio o universidad; por lo tanto, debo mantener sus
principios éticos y morales.

Que tengo un compromiso con mi empleador, quien depositó su confianza en mí; por lo tanto,
debo esforzarme por cumplir con este compromiso con toda mi capacidad, proteger los
intereses de mi empleador y aconsejarle sabiamente y con honestidad.

Acepto estos compromisos como una responsabilidad personal y como un miembro de esta
Asociación. Cumpliré con estos compromisos y me dedicaré a ese fin.

Los códigos de ética de otras sociedades para los profesionales del procesamiento de la
información expresan un sentir parecido. Es vital para el futuro de los profesionales de esta
profesión apegarse rigurosamente a estos códigos de ética.

Preguntas de repaso
1. ¿Cuáles de las siguientes son las dos categorías principales de los sistemas de
información computarizados?
2. Mencione las diferencias entre ERP y paquetes administrativos
3. ¿Cuáles son las seis fases del ciclo de vida de sistemas de información tradicional?
4. Menciona la documentación que se produce durante cada fase del ciclo de vida del
sistema de información.
5. Describa brevemente qué se hace durante cada fase del desarrollo tradicional de los
sistemas de información.
6. ¿Por qué no hay una fase de planeación separada?
7. ¿Por qué no hay una fase de pruebas separada?
8. ¿Por qué no hay una fase de documentación separada?
9. Mencione dos usos diferentes de la palabra análisis en el contexto del sistema de
información.
10. Por cada dólar gastado en el desarrollo de un sistema de información, ¿cuánto se
invierte en el mantenimiento durante su tiempo de vida?
11. ¿Cuáles son los dos tipos principales de mantenimiento? Describa brevemente cada
uno.
12. ¿Cuáles son los dos tipos principales de empresas en las que trabajan los profesionales
de la tecnología de la información?
 13. Describa una situación donde el cliente, el desarrollador y el usuario sean la misma
persona.
14. ¿Qué ventajas puede otorgar que el cliente, el desarrollador y el usuario sean la misma
persona?
15. Considere la fase de requisitos y la fase de análisis. ¿Tendría más sentido combinar
estas actividades en una fase que tratarlas por separado?
16. Se realizan más pruebas durante la fase de implementación que durante cualquier otra
fase de desarrollo. ¿Sería mejor dividir esta fase en dos, una que incorpore todos los
aspectos no relacionados con las pruebas y la otra que realice todas las pruebas?
17. ¿Hasta qué punto Pascual Troncone, el analista de sistemas de GlobalTech, fue
responsable de la entrega de 56.943 sacos a AgroPlus? ¿Pascual podría haber
impedido que esto ocurriera?
18. Usted es un analista de sistemas. El vicepresidente ejecutivo de una editorial de libros
quiere que usted desarrolle un sistema de información que realice todas las funciones
de contabilidad de la compañía y proporcione información en línea al personal de la
oficina central con respecto a los pedidos y al inventario de varios almacenes de la
compañía. Se requieren computadoras para 15 empleados de contabilidad 32 de
pedidos y 42 de almacén. Además, 18 gerentes necesitan tener acceso a los datos. El
presidente desea pagar 30.000 dólares por el hardware y el sistema de información
juntos y quiere el sistema de información completo en cuatro semanas. ¿Qué le diría?
Tenga en cuenta que su compañía quiere este contrato, no importa cuán razonable sea
su solicitud.
19. Busque la palabra sistema en un diccionario. ¿Cuántas definiciones diferentes hay?
Anote aquellas que se apliquen a los sistemas de información.
20. El retiro es un suceso raro. ¿Por qué cree que esto es así?
21. Debido a un incendio en Elmer's Information System Developers, Inc. toda la
documentación de un sistema de información se destruyó bruscamente justo antes de
que el sistema de información se entregara y se instalara. ¿Cuál es el impacto de la
falta de documentación resultante?

Material de consulta
Association of Information Technology Professionals Code of Ethics, 27 de agosto de 1907 ble
on www
org/about/code_of-ethics.html Hatton, L., “Does OO Sync with How We Think?", en IEEE
Softwares (mayo-junio de 1908). pp. 46-54 Schach, S. R., Object-Oriented and Classical
Software Engineering, Saed, Nueva York WCH.Moraw-Hit 2002 Seddon, P.: V. Graeser y L.
Willcocks, "Measuring IS Effectiveness Senior IT Management Perspective, informe
técnico, Oxford Institue of Information Management, Templeton Colle University of Oxford Reino
Unido
2000. Yourdon, The Decline and full of the Amerim Purnimer Upper Nadele tiver u dency
Youndton