Antologia

Anlisis y Diseo de Sistemas de Informacin Antologa
INDICE

CAPITULO I. INTRODUCCION

1.1 El Ambiente de los Sistemas de Informacin 1
1.2 Administradores, Sistemas y la Toma de Decisiones 8
1.3 El Panorama de Aplicaciones 10

CAPITULO II. COMPONENTES DE LOS SISTEMAS DE INFORMACION

2.1 La Gente 15
2.2 El Hardware 16
2.3 El Software 17
2.4 La Metodologa 20

CAPITULO III. ANALISIS Y DISEO DE SISTEMAS

3.1 Investigacin Preliminar 37
3.2 Anlisis de factibilidad 43
3.3 El Papel del Analista de Sistemas 57
3.4 Herramientas de Anlisis y Diseo 58

CAPITULO IV. CICLO DE DESARROLLO DEL SISTEMA

4.1 Seguimiento del Ciclo de Vida del Proyecto 65
4.2 Diseo de Archivos 75
4.3 Administracin de Bases de Datos 80
4.4 Comunicacin de Datos 87
4.5 Generadores de Aplicaciones y Lenguajes no Procedurales 89
4.6 Paquetes 94
4.7 Prototipos y Programacin para Usuarios Finales 96
4.8 Especificaciones de Diseo 99
4.9 Estudio de Factibilidad 102
4.10 Diseo de Sistemas de Acuerdo al Hardware 105
4.11 Administracin del Desarrollo del Proyecto 105
4.12 Documentacin 116
4.13 Prueba e Instalacin 117
4.14 Mantenimiento 119
4.15 Optimizacin 120

CAPITULO V. ADQUISICION DE EQUIPO

5.1 Comparacin de Fuentes de Abastecimiento 122
5.2 El Servicio 124
5.3 Evaluacin y Seleccin 125

CAPITULO VI. ADQUISICION DE LOS PROGRAMAS

6.1 Comparacin de Fuentes de Abastecimiento 127
6.2 Servicio externo contra Servicio Interno 128
6.3 Evaluacin y Seleccin de Programas 154

Universidad de la Sierra A. C. SNE

CAPITULO VII. LA ADMINISTRACION DE LOS SISTEMAS DE INFORMACION

7.1 El Centro de Informacin 165
7.2 Mantenimiento 169
7.3 Actualizacin y Modernizacin 170

CAPITULO VIII. ESTUDIO DE CASOS DE DISEO DE SISTEMAS

8.1 Estudio de Campos 176
8.2 Elaboracin de Casos 184

CAPITULO IX. EL FUTURO DE LOS SISTEMAS DE INFORMACION

9.1 El Diseo de Sistemas en el Futuro 191


I. INTRODUCCION

En la actualidad, para muchas organizaciones, los sistemas de informacin basados en computadoras
son el corazn de las actividades cotidianas y objeto de gran consideracin en la toma de decisiones. Las
empresas consideran con mucho cuidado las capacidades de sus sistemas de informacin cuando deciden
ingresar o no en nuevos mercados o cuando planean la respuesta que darn a la competencia.

Sin ayuda automatizada, las dependencias gubernamentales tendran que hacer un alto ante el
volumen de trabajo que abrumara a sus administradores y empleados. Por otra parte, la capacidad de datos
determina tanto el lugar como el momento en que fluir la informacin. El desarrollo de sistemas involucra tanto
a los analistas de sistemas como a todos aquellos que harn uso de las aplicaciones que desarrollen, es decir
los usuarios finales. El anlisis y diseo de sistemas de informacin incluye diversas partes de las
organizaciones y no estn limitados al dominio de los especialistas en computadoras.

1.1 El Ambiente de los Sistemas de Informacin

Las organizaciones han reconocido, desde hace mucho, la importancia de administrar recursos. La
informacin se ha colocado en un lugar adecuado como recurso principal. Comprender que la informacin no es
solo un subproducto de la conduccin, si no que a la vez se alimenta a los negocios y puede ser el factor critico
para la determinacin del xito o fracaso del negocio. 1

Que es Informacin?: La informacin la componen datos que se han colocado en un contexto significativo y
til y se ha comunicado a un receptor, quien la utiliza para tomar decisiones.

Clasificacin de la informacin:

Se puede clasificar de muchas formas diferentes pero para una empresa la importancia que tiene es
respecto a quien va dirigida y para quien es til:
Estratgica:
Informacin estratgica es un instrumento de cambio.
Enfocada a la planeacin a largo plazo
Orientada a la alta administracin.

1 KENDALL & KENDALL . Anlisis y diseo de sistemas, 3.ed., Mxico,Pretince Hall, 1997 Pag. 1

1

Tctica:
Informacin de control administrativo
Es un tipo de informacin compartida.
Tiene una utilidad a corto plazo.
Operacional:
Informacin rutinaria.
Muestra la operacin diaria.
Tiene una utilidad a muy corto plazo.
Conceptos del Anlisis y Diseo de Sistemas de Informacin:
Anlisis de Sistemas: Es el proceso de clasificacin e interpretacin de hechos, diagnostico de problemas y
empleo de la informacin, para la implantacin de un sistema o en caso de existir uno recomendar mejoras al
sistema.

Diseo de Sistemas: Es el proceso de planificar, reemplazar o completar un sistema organizacional. Especifica
que es lo que el sistema debe hacer.
Anlisis y Diseo de Sistemas, (Kendall y Kendall): Elemento decisivo que en un momento dado determina
el xito o fracaso del negocio ya que no es un producto exclusivamente colateral de la operacin de la
empresa, sino que es uno de los promotores de la misma.
Anlisis y Diseo de Sistemas de Informacin, (James A. Senn): Conjunto de datos que dentro de contexto
significativo y til, esta se comunica a un receptor, quien la utiliza para tomar decisiones.
El Anlisis y Diseo de Sistemas: Se refiere al proceso de examinar la situacin de una empresa con el
propsito de mejorarla con mtodos y procedimientos mas adecuados.
Sistema:
Un sistema es "una red de procedimientos relacionados entre s y desarrollado de acuerdo con un esquema
integrado para lograr una mayor actividad de la empresa.
Un sistema es "un ensamble de partes unidas por interferencia y que se lleva a cabo por las empresas para
lograr as los objetivos de las mismas.

2

Los sistemas son todo lo que rodea al ser humano; por ejemplo, se sienten sensaciones fsicas
originadas por un complejo sistema nervioso, un conjunto de partes que incluye al cerebro, espina dorsal,
nervios y clulas sensitivas especiales debajo de la piel, que trabajan conjuntamente para hacer sentir calor,
fro, comezn, etc.
El hombre se comunica por medio del lenguaje, que es un sistema altamente desarrollado de palabras y
smbolos que tienen significado; vive de acuerdo con un sistema econmico en el cual los bienes y servicios se
intercambian por otros de valor comparable.
Con frecuencia no se advierte; pero un negocio tambin es un sistema. Sus partes tienen nombres
como mercadotecnia, produccin, ventas, investigacin, embarque, contabilidad y personal. Estos componentes
trabajan todos juntos para crear una utilidad que beneficie a los empleados y a los accionistas de la firma. Cada
una de estas partes es un sistema en s mismo.
Caractersticas de los Sistemas:
Totalidad: su funcionamiento requiere de la unin de todos los subsistemas que en l estn integrados.
Bsqueda de objetivos: para la permanencia del sistema ste busca definir un sentido de unidad y
propsito.
Equifinalidad: el sistema tiene ms de una forma de lograr los objetivos.
Interrelacin e Interdependencia: todos los elementos del sistema interactan entre s, y el resultado
de cada uno de ellos depende por lo menos de la actividad de sus elementos.
Regulacin: son los esfuerzos del sistema para mantener su equilibrio dinmico.
Jerarqua: todo sistema contiene elementos los cuales a su vez cuentan con sub-elementos y todo el
sistema a su vez es parte de un sistema mayor.
Adaptabilidad: Es la capacidad del sistema para adaptarse a su entorno.
Eficiencia: son los esfuerzos para utilizar los recursos en la mejor forma posible.
Sinergia: la interaccin de las partes individuales, se vuelve ms eficiente que si cada parte actuara de
manera aislada.
Homeostasis: tratan de mantener su naturaleza, intentando controlar las amenazas de los factores
externos. Estando en constante cambio.
Cuando se comienza a ver lo abundante que son los sistemas, no sorprende darse cuenta que cada
sistema del negocio depende de una o ms entidades abstractas llamadas sistemas de informacin. Por medio
de estos sistemas los datos pasan de una persona o departamento a otro y puede realizarse cualquier cosa,
desde comunicaciones entre oficinas y comunicaciones telefnicas, hasta un sistema de computadora que
genere informes peridicos para diferentes usuarios.

3

Los sistemas de informacin, sirven a todos los sistemas de un negocio. Ellos son el lazo que mantiene
unidos a diferentes componentes en forma total, que pueden trabajar de manera efectiva hacia el mismo
objetivo.
Sistema de Informacin (SI):
Es un grupo de gente, una serie de procedimientos o equipo de procesamiento de datos que escoge,
almacenan, procesan y recuperan datos para disminuir la incertidumbre en la toma de decisiones mediante el
suministro de informacin a los niveles gerenciales para que sea utilizada eficientemente.
Es el medio por el cual los datos fluyen de una persona o departamento hacia otros y puede ser
cualquier cosa, desde la comunicacin interna entre los diferentes componentes de la organizacin y lneas
telefnicas hasta sistemas de cmputo que generan reportes peridicos para varios usuarios.
Sistema de Informacin: Es el conjunto total de procedimientos, operaciones, funciones y difusin de datos o
informacin de una organizacin.

Caractersticas de los Sistemas Modernos de Informacin:
Sistemas sencillos sirviendo a funciones y niveles mltiples dentro de la empresa.
Acceso inmediato en lnea a grandes cantidades de informacin.
Fuerte confiabilidad en la tecnologa de telecomunicaciones.
Mayor cantidad de inteligencia y conocimientos implcita en los sistemas.
La capacidad para combinar datos y grficas.
Los sistemas de informacin cumplirn dentro de las organizaciones tres objetivos bsicos.
a) Automatizacin de procesos operativos. (Sistemas transaccionales)
b) Proporcionar informacin que sirva de apoyo al proceso de la toma de decisiones. (Sistemas de soporte
a las decisiones).

4

Elementos de un Sistema de Informacin:

ENTRADAS SALIDAS PROCESO

Datos, Registros y
Recursos
Informacin,
Transacciones y
Reportes
Cont R.H. Arch
Pro
Sw
Hw
Retroalimentacin

Figura 1.1 Elementos de los Sistemas de Informacin
Estos elementos son de naturaleza diversa y normalmente incluyen:
El Equipo Computacional: Es decir, el hardware necesario para que el sistema de informacin pueda
operar. Lo constituyen las computadoras y el equipo perifrico que puede conectarse a ellas.
El Recurso Humano: que interacta con el Sistema de Informacin, el cual esta formado por las
personas que utilizan el sistema, alimentndolo con datos o utilizando los resultados que genere.
Los Datos o Informacin Fuente: que son introducidos en el sistema; son todas las entradas que
necesita el sistema para generar como resultado la informacin que se desea.
Los Programas: que son procesados y producen diferentes tipos de resultados. Los programas son
parte del software del sistema de informacin que har que los datos de entrada introducidos sean
procesados correctamente y generen los resultados que se esperan.

5

Componentes de un Sistema de Computadoras:
1. Entrada (input)
2. Proceso (process)
3. Salida (output)
4. Almacenamiento (strorage)
Entradas: Las entradas son los ingresos del sistema que pueden ser recursos materiales, recursos humanos o
informacin. Las entradas constituyen la fuerza de arranque que suministra al sistema sus necesidades
operativas.
Las entradas pueden ser:
En serie: Es el resultado o la salida de un sistema anterior con el cual el sistema en estudio est
relacionado en forma directa.
Aleatoria: Es decir, al azar, donde el termino "azar" se utiliza en el sentido estadstico. Las entradas
aleatorias representan entradas potenciales para un sistema.
Retroaccin: Es la reintroduccin de una parte de las salidas del sistema en s mismo.
Proceso: El proceso es lo que transforma una entrada en salida, como tal puede ser una mquina, un
individuo, una computadora, un producto qumico, una tarea realizada por un miembro de la organizacin, etc.
Salidas: Las salidas de los sistemas son los resultados que se obtienen de procesar las entradas. Al igual que
las entradas estas pueden adoptar la forma de productos, servicios e informacin. Las mismas son el resultado
del funcionamiento del sistema o, alternativamente, el propsito para el cual existe el sistema. Las salidas de un
sistema se convierten en entrada de otro, que la procesar para convertirla en otra salida, repitindose este
ciclo indefinidamente.
Relaciones: Las relaciones son los enlaces que vinculan entre s a los objetos o subsistemas que componen a
un sistema complejo.

6

Podemos clasificarlas en:
Simbiticas: es aquella en que los sistemas conectados no pueden seguir funcionando solos. A su vez
puede subdividirse en unipolar o parasitaria, que es cuando un sistema (parsito) no puede vivir sin el
otro sistema (planta); y bipolar o mutual, que es cuando ambos sistemas dependen entre si.
Sinrgica: es una relacin que no es necesaria para el funcionamiento pero que resulta til, ya que su
desempeo mejora sustancialmente al desempeo del sistema. Sinergia significa "accin combinada".
Sin embargo, para la teora de los sistemas el trmino significa algo ms que el esfuerzo cooperativo.
En las relaciones sinrgicas la accin cooperativa de subsistemas semi-independientes, tomados en
forma conjunta, origina un producto total mayor que la suma de sus productos tomados de una manera
independiente.
Superflua: Son las que repiten otras relaciones. La razn de las relaciones superfluas es la
confiabilidad. Las relaciones superfluas aumentan la probabilidad de que un sistema funcione todo el
tiempo y no una parte del mismo. Estas relaciones tienen un problema que es su costo, que se suma al
costo del sistema que sin ellas puede funcionar.
Atributos: Los atributos de los sistemas, definen al sistema tal como lo conocemos u observamos. Los
atributos pueden ser definidores o concomitantes: los atributos definidores son aquellos sin los cuales una
entidad no sera designada o definida tal como se lo hace; los atributos concomitantes en cambio son aquellos
que cuya presencia o ausencia no establece ninguna diferencia con respecto al uso del trmino que describe la
unidad.
Contexto: Un sistema siempre estar relacionado con el contexto que lo rodea, o sea, el conjunto de objetos
exteriores al sistema, pero que influyen decididamente a ste, y a su vez el sistema influye, aunque en una
menor proporcin, influye sobre el contexto; se trata de una relacin mutua de contexto-sistema.
Tanto en la Teora de los Sistemas como en el mtodo cientfico, existe un concepto que es comn a
ambos: el foco de atencin, el elemento que se asla para estudiar. El contexto a analizar depende
fundamentalmente del foco de atencin que se fije. Ese foco de atencin, en trminos de sistemas, se llama
lmite de inters.

7

Para determinar este lmite se consideraran dos etapas por separado:
La determinacin del contexto de inters
La determinacin del alcance del lmite de inters entre el contexto y el sistema.
Se suele representar como un crculo que encierra al sistema, y que deja afuera del lmite de inters a
la parte del contexto que no interesa al analista.
En lo que hace a las relaciones entre el contexto y los sistemas y viceversa. Es posible que slo
interesen algunas de estas relaciones, con lo que habr un lmite de inters relacional.
Determinar el lmite de inters es fundamental para marcar el foco de anlisis, puesto que slo ser
considerado lo que quede dentro de ese lmite. Entre el sistema y el contexto, determinado con un lmite de
inters, existen infinitas relaciones. Generalmente no se toman todas, sino aquellas que interesan al anlisis, o
aquellas que probabilsticamente presentan las mejores caractersticas de prediccin cientfica.
Rango: En el universo existen distintas estructuras de sistemas y es factible ejercitar en ellas un proceso de
definicin de rango relativo. Esto producira una jerarquizacin de las distintas estructuras en funcin de su
grado de complejidad. Cada rango o jerarqua marca con claridad una dimensin que acta como un indicador
claro de las diferencias que existen entre los subsistemas respectivos.
Esta concepcin denota que un sistema de nivel 1 es diferente de otro de nivel 8 y que, en
consecuencia, no pueden aplicarse los mismos modelos, ni mtodos anlogos a riesgo de cometer evidentes
falacias metodolgicas y cientficas. Para aplicar el concepto de rango, el foco de atencin debe utilizarse en
forma alternativa: se considera el contexto y a su nivel de rango o se considera al sistema y su nivel de rango.
Refirindonos a los rangos hay que establecer los distintos subsistemas. Cada sistema puede ser
fraccionado en partes sobre la base de un elemento comn o en funcin de un mtodo lgico de deteccin. El
concepto de rango indica la jerarqua de los respectivos subsistemas entre s y su nivel de relacin con el
sistema mayor.
1.2 Administradores, Sistemas y La Toma de Decisiones

Antes de comenzar el desarrollo de cualquier proyecto, se conduce un estudio de sistemas para detectar
todos los detalles de la situacin actual en la empresa. La informacin reunida con este estudio sirve como base
para crear varias estrategias de diseo. Los administradores deciden que estrategia seguir.

8

Los gerentes, empleados y otros usuarios finales que se familiarizan cada vez ms con el empleo de
computadoras estn teniendo un papel muy importante en el desarrollo de sistemas. Un administrador necesita
informacin para tomar decisiones, segn sea el tipo de decisin, requerir cierto tipo de informacin, es lgico,
segn sea la funcin que uno tenga en su puesto, tendr que hacer toma de decisiones especficas para llevar
a cabo sus actividades de manera efectiva.

Los Elementos que intervienen en una toma de decisin:

a) El puesto o nivel que se tiene en la empresa y las actividades que se realizan
b) El tipo de decisin
c) Otros factores, variables controlables y no controlables

Tipos de gerentes:

De nivel inferior: Tienen a su cargo la toma de decisiones operativas bsicas, las cuales controlan tareas
especficas de uso comn en la organizacin.
De nivel medio: Son los gerentes que deben tomar decisiones tcticas, que incluyen reas de control,
asignacin de recursos de todos tipos, y reportar sus resultados a los niveles altos.
De nivel alto: Quienes deben conocer todas las actividades de la empresa de forma general. Tomar
decisiones que implican riesgos, requieren informacin que les permita tomar decisiones estratgicas.

Tipos de Decisiones:

Decisiones estructuradas: Son aquellas que se toman de manera rutinaria y requiere de solo la
informacin necesaria y bsica para realizarse, no se corren riesgos al llevarlas a cabo.
Decisiones no estructuradas: Son las no rutinarias, son decisiones que requieren diversos tipos de
informacin para ser tomadas debido a las variables que intervienen, se requiere tener a la mano la
informacin necesaria para manipularla, recuperarla y analizarla, no son planeadas.

La Administracin existe en las organizaciones en tres amplios niveles horizontales:

Control operacional
Planeacin y control administrativo
Administracin estratgica

9

Cada nivel tiene sus propias responsabilidades y todos trabajan para el logro de metas y objetivos
organizacionales en su manera propia.

Administracin de Operaciones: El control operacional forma el nivel inferior de la administracin a tres
niveles. Los administradores de operaciones toman decisiones usando reglas predeterminadas que tienen
resultados predecibles cuando son implementadas correctamente. Los administradores de operaciones son los
tomadores de decisiones cuyo trabajo es el ms claro, debido al alto nivel de certeza en su ambiente de toma
de decisiones. Los administradores de operacin supervisan los detalles de la organizacin en tiempo y de
acuerdo con las restricciones organizacionales.

Administracin Media: La administracin media forma el segundo nivel, o intermedio, del sistema de
administracin de tres niveles. La administracin media realiza decisiones de planeacin y control a corto plazo
sobre la manera en que son mejor asignados los recursos para satisfacer los objetivos organizacionales. La
administracin media experimenta muy poca certeza en su ambiente de toma e decisiones. Sus decisiones van
desde la prediccin de requerimientos futuros de recursos hasta la resolucin de problemas de personal que
amenacen la productividad. Pocas de las decisiones que toman los administradores operacionales. El dominio
de toma de decisiones de los administradores medios puede ser caracterizado en forma til como parte
operacional y parte con fluctuaciones constantes.

Administracin Estratgica: La administracin estratgica comprende el tercer nivel del control administrativo
de tres niveles. Los administradores estratgicos ven fuera de la organizacin hacia el futuro, tomando
decisiones que guiarn a los administradores medios o de operacin en los meses y aos por venir. Los
administradores estratgicos trabajan en un ambiente de toma de decisiones altamente incierto. Por medio de
enunciados de objetivos y la determinacin de las estrategias y polticas para lograrlos, los administradores
estratgicos definen a la organizacin como un todo. 2

1.3 El Panorama de Aplicaciones

Los sistemas de informacin son desarrollados con propsitos diferentes, dependiendo de las
necesidades de cada empresa.

2 KENDALL & KENDALL, Anlisis y diseo de sistemas, 3. ed. Mxico,.Pretince Hall ,1997 Pag. 36, 37

10

Los Sistemas de Procesamiento de Transacciones, por sus siglas en ingles (TPS Transactions Process
System):

El sistema, basado en computadora, mas importante dentro de una organizacin es el que esta
relacionado con el procesamiento de las transacciones. Tienen como finalidad mejorar las actividades rutinarias
de una empresa y de las que depende toda la organizacin, una transaccin es cualquier suceso o actividad
que afecta a toda la organizacin. Las transacciones ms comunes incluyen: facturacin, entrega de mercanca,
pago a empleados y deposito de cheques.

Las principales caractersticas son:
A travs de stos suelen lograrse ahorros significativos de mano de obra.
Normalmente son el primer tipo de SI que se implanta en las organizaciones.
Son intensivos en entrada y salida de informacin; sus clculos y procesos suelen ser simples y poco
sofisticados.
Tienen la propiedad de ser recolectores de informacin.
Son fciles de justificar ante la direccin ya que sus beneficios son visibles y palpables.
Sistemas de Automatizacin de Oficina, por sus siglas en ingles (OAS Office Automatization Systems):

Que dan soporte a los trabajadores de datos, quienes por lo general, no crean un nuevo conocimiento si
no que utilizan la informacin para analizarla y transformar datos, para manejar y despus compartirla.

Sistemas de Manejo de Conocimiento, por sus siglas en ingles (KWS Knowledge Workshop Systems):

Otorga soporte a los trabajadores profesionales, tales como cientficos, ingenieros y doctores, ayudando
a crear un nuevo conocimiento que contribuya a la organizacin.

Sistemas de Informacin Gerencia, por sus siglas en ingles (MIS Management Information Systems):

Ayudan a los directivos a tomar decisiones y resolver problemas. Los directivos recurren a los datos
almacenados como consecuencia del procesamiento de las transacciones, pero tambin emplean otra
informacin. En cualquier organizacin se deben tomar decisiones sobre muchos asuntos que se presentan con
regularidad (a la semana, al mes, al trimestre, etc.) y para hacerlo se requiere de cierta informacin, dado que
los procesos de decisin estn claramente definidos, entonces se puede identificar la informacin necesaria
para formular las decisiones.

11

Sistemas de Apoyo a Decisiones, por sus siglas en ingles (DSS Decisin Support Systems):

Apoyan a los directivos que deben tomar decisiones no muy estructuradas, tambin denominadas no
estructuradas o decisiones semiestructuradas. Una decisin se considera no estructurada si no existen
procedimientos claros para tomarla y tampoco es posible identificar, con anticipacin, todos los factores que
deben considerarse en la decisin. Un factor clave en el uso de estos sistemas es determinar la informacin
necesaria, en situaciones bien estructuradas es posible identificar esta informacin con anticipacin, pero no en
un ambiente no estructurado resulta difcil hacerlo.

Caractersticas principales:
Suelen introducirse despus de haber implantado los sistemas transaccionales.
Suelen ser intensivos en clculos y escasos en entradas y salidas de informacin.
La informacin que generan sirve de apoyo a los mandos intermedios y de alta administracin en el
proceso de la toma de decisiones.
No suelen ahorrar mano de obra.
La justificacin econmica para el desarrollo de estos sistemas es difcil.
Suelen ser SI interactivos y amigables, con altos estndares de diseo grfico y visual, ya que estn
dirigidos al usuario final.
Apoyan la toma de decisiones que por su naturaleza son repetitivas.
Pueden ser desarrollados directamente por el usuario final sin la participacin operativa de los analistas

Sistemas Expertos e Inteligencia Artificia, por sus siglas en ingles (AI Artifitial Intelligence):

Un sistema experto tambin llamado sistema basado en conocimiento, utiliza la comprensin del
lenguaje natural y el anlisis de la habilidad para razonar un problema y llegar a conclusiones lgicas, captura
en forma efectiva y usa el conocimiento de un experto para resolver un problema particular experimentado en
una organizacin. La Inteligencia Artificial (IA) es un campo de estudios muy amplio, y en constante cambio, sin
embargo, su producto final es siempre software. Estos programas, producto del trabajo de la IA, son
denominados Sistemas Inteligentes (SI).

12

Un SI incorpora conocimiento sacado de la experiencia de los expertos humanos. Los campos de
aplicacin de tales SI son muy variados, pensemos por ejemplo en un sistema de diagnstico mdico, o en
un sistema integrado de ayuda a la toma de decisiones empresariales. En cualquier caso, un SI partir de
unos datos y los convertir en informacin (conocimiento), de modo que ayude a tomar una decisin. Para
convertir los datos en informacin til, emplear algoritmos de razonamiento, aprendizaje, evolucin, etc.
Adems, el SI actuar siempre en tiempo real, lo que representa un aumento de la productividad.
Un SI puede aplicarse, como se mencion, a numerosas actividades. Adems de las ya citadas,
podemos destacar:

Manufactura inteligente
Diagnstico de problemas en tiempo crtico
Mantenimiento preventivo en condiciones ptimas

Es muy difcil definir la IA, debido a la dificultad de definir el concepto de comportamiento inteligente.
En cualquier caso, su meta es construir sistemas que piensen y acten racionalmente. Debemos, pues,
definir qu es lo que vamos a caracterizar como pensamiento o actuacin racional. Basndonos en ello,
habr cuatro modos diferentes de entender los sistemas que quiere construir la IA:

Sistemas que acten como humanos
Sistemas que piensen como humanos
Sistemas que piensen racionalmente
Sistemas que acten racionalmente

Sistema de Apoyo a Decisiones de Grupo, por sus siglas en ingles (DGS Group Decisin Support
Systems):

Estn orientados para reunir a un grupo, a fin de que resuelva un problema con la ayuda de varios
apoyos como votaciones, cuestionarios, aportacin de ideas y creacin de escenarios, puede ser diseado para
minibar el comportamiento negativo tpico de un grupo.

Sistemas de Apoyo a Ejecutivos, por sus siglas en ingles (ESS Executive Support Systems):

Ayuda a los ejecutivos a la toma de decisiones a nivel estratgico, organizacin de interacciones con el
ambiente externo, proporcionando apoyo de grficos y comunicaciones en lugares accesibles tales como salas
de junta u oficinas personales corporativas. 3

3 A. SENN J ames, Anlisis y diseo de sistemas de informacin, 2 ed., Mxico, Mac Graw Hill, 1994, Pag. 20,21

13

Caractersticas principales:

Su funcin principal no es apoyar a la automatizacin de procesos operativos ni proporcionar
informacin para la toma de decisiones. Sin embargo, este tipo de sistemas puede llevar a cabo dichas
funciones.
Tpicamente su forma de desarrollo es a base de incrementos y a travs de su evolucin permanente
dentro de la organizacin.
Su funcin es lograr ventajas que los competidores no posean, tales como ventajas en costos y
servicios diferenciados con clientes y proveedores.
Apoyan el proceso de innovacin dentro de la empresa.

14

II. COMPONENTES DE LOS SISTEMAS DE INFORMACION

Los sistemas de informacin, estn integrados por diversos componentes, los cuales en conjunto
forman parte importante para dichos sistemas. Puesto que contribuyen en gran medida a su desarrollo y
desempeo.

2.1 La gente

Cualquier persona que interactu con un sistema de informacin en el contexto de su trabajo en la
organizacin puede ser llamada usuario final, por lo cual se puede decir que un usuario final es: Aquella
persona que no es especialista en sistemas de informacin, pero que utilizan las computadoras para
desempear su trabajo, y las cuales se agrupan en cuatro categoras:

Usuarios Primarios o Directos: Son los que interactan con el sistema, ellos lo alimentan con datos
(entradas) o reciben salidas quizs por medio de una terminal. Por ejemplo: Los agentes de reservacin de
vuelos que emplean las terminales para consultar el sistema y obtener informacin relacionada con pasajeros,
vuelos y boletos.

Usuarios Indirectos: Son aquellos que se benefician de los resultados o reportes generados por estos
sistemas pero que no interactan de manera directa con el hardware y software. Por ejemplo: Los gerentes de
mercadotecnia son los responsables de las aplicaciones de anlisis de ventas que generan los reportes
mensuales de la compaa en este ramo.

Usuarios Gerentes o Administradores: Aquellos que tienen responsabilidades administrativas en los
sistemas de aplicacin. Por ejemplo: Los gerentes de las empresas que utilizan en gran medida los sistemas de
informacin. Mientras estas personas no utilicen los sistemas ya sea directa o indirectamente no tendrn la
autoridad para aprobar o no la inversin en el desarrollo de aplicaciones, adems no tendrn la responsabilidad
ante la organizacin de la efectividad de los sistemas.

Usuarios Directivos: El cuarto grupo de usuarios, toman cada vez ms responsabilidad en el desarrollo de
sistemas de informacin. Los directivos deben evaluar de manera constante los riesgos a los que se expone la
empresa en caso de falla de los sistemas de informacin. 4

4 A. SENN J ames, Anlisis y diseo de sistemas de informacin, 2. ed., Mxico, Mac Graw Hill, 1994, Pag. 17,18

15

2.2 El hardware

El hardware o soporte fsico es todo aquello que podemos tocar: CPU, disco duro, placa, disquetes,
monitor, etc. El termino hardware hace referencia a los componentes materiales o fsicos de un sistema
informtico, como lo son los circuitos electrnicos, partes mecnicas etc.

Los Dispositivos:

Conjunto de componentes empleados por los usuarios para comunicarse con las computadoras. El
usuario dirige el funcionamiento de la mquina mediante instrucciones, denominadas genricamente entradas.
Las entradas se introducen mediante diversos dispositivos, por ejemplo un teclado, y se convierten en seales
electrnicas que pueden ser procesadas por la computadora. Estas seales se transmiten a travs de circuitos
conocidos como bus, y son coordinadas y controladas por la unidad de proceso central y por un soporte lgico
conocido como sistema operativo.

Una vez que la UPC ha ejecutado las instrucciones indicadas por el usuario, puede comunicar los
resultados mediante seales electrnicas, o salidas, que se transmiten por el bus a uno o ms dispositivos de
salida, por ejemplo una impresora o un monitor.

Dispositivos de entrada y salida:

Para introducir datos se emplean dispositivos muy diversos. La mayora de las computadoras
personales incluyen un teclado, el mouse, la bola de seguimiento o trackball y el joystick son otros dispositivos
de entrada que permiten sealar, seleccionar y mover objetos en un monitor.

Los dispositivos de salida ms habituales son las impresoras y los monitores en color. La salida de
audio tambin es corriente, as como las complejas conexiones con sintetizadores que producen una amplia
gama de sonidos musicales. Este tambin es un punto muy importante que el analista de sistemas debe tomar
en cuenta al desarrollar un nuevo software, ya que si no se toman en cuenta las caractersticas del hardware el
sistema puede no satisfacer todas las necesidades de la manera ms idnea. Es decir un analista no puede
elegir el hardware antes de elaborar un software.

El analista de sistemas necesita trabajar junto con los usuarios para determinar que hardware ser
necesario. Las determinaciones de hardware solo pueden darse en conjuncin con la determinacin de
requerimientos de informacin. El conocimiento de la estructura organizacional tambin puede ser til para las
decisiones de hardware. Slo cuando los analistas de sistemas, usuarios y administradores tienen un buen
conocimiento del tipo de tareas que deben de ser logradas, pueden ser consideradas las opciones de hardware.

16

La determinacin de las disponibilidades de hardware actuales ayudar a un proceso de toma de
decisiones ms firme cuando se tengan que realizar, a final de cuentas, las decisiones de hardware, debido a
que ser eliminada mucha de la adivinacin sobre lo que existe. Por medio de las entrevistas, cuestionarios e
investigacin de datos.

Dispositivos de almacenamiento:

Una unidad de disco, junto con los discos que graba, es un dispositivo de almacenamiento. A veces se
dice que una computadora tiene dispositivos de almacenamiento primarios (o principales) y secundarios (o
auxiliares). Cuando se hace esta distincin, el dispositivo de almacenamiento primario es la memoria de
acceso aleatorio (RAM) de la computadora, un dispositivo de almacenamiento permanente pero cuyo contenido
es temporal.
El almacenamiento secundario incluye los dispositivos de almacenamiento ms permanentes, como
unidades de disco y de cinta. Son importantes los dispositivos de almacenamiento debido a que es ah en
donde almacenaremos el sistema o sistemas con los que cuente la empresa.

2.3 El software
Concepto de Software:
El software es la parte intangible (fsicamente) de un computador. Se utiliza este trmino para referirse a
todo el soporte lgico utilizado por un computador (conjunto de datos y programas). As mismo cuando se
adquiere software, es importante analizarlo en base a su flexibilidad, capacidad y soporte del vendedor.
La flexibilidad debe incluir la capacidad de cumplir con los requerimientos cambiantes y las diferentes
necesidades del usuario. La capacidad se refiere al nmero de archivos que puede guardar el sistema y el
nmero de archivos que puede conservar.

El soporte del proveedor, es un punto muy importante que debe considerar, ya que el analista debe
determinar quien lo llevara a cabo y a que costo, antes de afirmar el contrato de compra-venta adems de
detallar los trminos del mantenimiento; si hay cargo por actualizaciones, cuota mensual, anual, etc., adems
de preguntarle que servicios adicionales puede brindar.

Clasificacin del Software:
Segn la funcin
Segn el grado de estandarizacin o uso.

17

Segn la funcin: Esta clasificacin para nuestro tema es solamente ilustrativa, dentro de este bloque
encontramos.
Software de base: Son los que controlan el funcionamiento interno del ordenador, perifricos que sirva para el
correcto funcionamiento de otros programas dentro de ellos se pueden destacar, software de memoria,
sistemas operativos, lenguaje de programacin, entre otros.
Software aplicativo: Son programas de montos o funciones especficos, que el usuario, adquiere de acuerdo a
sus necesidades; entre las cuales podemos mencionar:
Hojas de Clculo
Procesadora de Textos
Base de Datos
Diseo Grfico
Segn el uso o estandarizacin: Existen tres sub divisiones que son considerada software aplicativos debido
a que ellos son requeridas atendiendo la necesidad del usuario, y que a mencionar son:
El Software Aplicativo: Tambin llamado package, estos programa estn dirigidos al mercado en general, lo
cual a originado el origen de empresas creadoras de software, que estn pues estas son propia nos bien
definidos, bien es hoja calculo, base de datos, o conjuntos de programas en grupo.
El Software a Medida: Tambin denominada (Custom mode), son los creados por empresas para sus propias
actividades, tambin son susceptibles de modificacin
Tipos de Software:
Sistema operativo: Es el conjunto de programas que permiten la interaccin (comunicacin) entre el
usuario y el hardware. Adems, hace que el hardware sea utilizable y lo administra de manera de lograr
un buen rendimiento.
Caractersticas de los sistemas operativos:

18

En general, se puede decir que un sistema operativo tiene las siguientes caractersticas:
Conveniencia: Un Sistema Operativo hace ms conveniente el uso de una computadora.
Eficiencia: Un Sistema Operativo permite que los recursos de la computadora se usen de la manera
ms eficiente posible.
Habilidad para evolucionar: Un Sistema Operativo deber construirse de manera que permita el
desarrollo, prueba o introduccin efectiva de nuevas funciones del sistema sin interferir con el servicio.
Encargado de administrar el hardware: El Sistema Operativo se encarga de manejar de una mejor
manera los recursos de la computadora en cuanto a hardware se refiere, esto es, asignar a cada
proceso una parte del procesador para poder compartir los recursos.
Relacionar dispositivos (gestionar a travs del kernel): El Sistema Operativo se debe encargar de
comunicar a los dispositivos perifricos, cuando el usuario as lo requiera.
Organizar datos para acceso rpido y seguro.
Manejar las comunicaciones en red: El Sistema Operativo permite al usuario manejar con alta
facilidad todo lo referente a la instalacin y uso de las redes de computadoras.
Procesamiento por bytes de flujo a travs del bus de datos.
Facilitar las entradas y salidas: Un Sistema Operativo debe hacerle fcil al usuario el acceso y
manejo de los dispositivos de Entrada/Salida de la computadora.
Tcnicas de recuperacin de errores.
Evita que otros usuarios interfieran: El Sistema Operativo evita que los usuarios se bloqueen entre
ellos, informndoles si esa aplicacin esta siendo ocupada por otro usuario.
Generacin de estadsticas.
Permite que se puedan compartir el hardware y los datos entre los usuarios.
Sistemas Operativos de red:
Son aquellos sistemas que mantienen a dos o ms computadoras unidas a travs de algn medio de
comunicacin (fsico o no), con el objetivo primordial de poder compartir los diferentes recursos y la informacin
del sistema, estos son de suma importancia en los casos de que el sistema a disearse requiera ser usado bajo
una red. Los Sistemas Operativos de red mas ampliamente usados son: Novell Netware, Windows NT Server,
UNIX, Linux, Windows 200 Server, 2003 Server.
Programas de Ampliacin: O tambin llamado software de aplicacin; es el software diseado y escrito para
realizar una tarea especifica, ya sea personal, o de procesamiento. Aqu se incluyen las bases de datos,
procesadores de textos, hojas electrnicas, grficas, comunicaciones etc.

19

Lenguajes de Programacin: Conjunto de instrucciones escritas en algn lenguaje entendible por la mquina.
A travs de los programas el computador puede realizar variadas operaciones, desde procesar textos y dibujos
hasta resolver complejos problemas matemticos.
Existen varios tipos de lenguajes de programacin, como son:

Lenguajes de Bajo nivel: Son aquellos que estn ms prximos al lenguaje que entiende el computador.
Lenguaje maquina
Lenguaje ensamblador

El Lenguaje maquina: Es una coleccin de instrucciones muy detalladas que controlan la circuiteria interna de
la maquina.

Lenguaje ensamblador: Tipo de lenguaje de programacin en que el conjunto de instrucciones del
microprocesador se representa por MNEMNICOS, en vez de dgitos BINARIOS o HEXADECIMALES. Con el
fin de facilitar la escritura de programas. Un lenguaje ensamblador es un lenguaje de BAJ O NIVEL, es decir,
esta muy cerca de las operaciones reales del microprocesador.

Lenguajes de Alto Nivel: Son aquellos que estn ms prximos al lenguaje natural, por tanto no son
entendibles directamente por el computador, es necesario hacer una traduccin.
La Programacin Visual (VP): Se refiere a cualquier sistema que le permite al usuario especificar un
programa en dos o ms. (La moda del dimensionsional.)

2.4 La Metodologa

Este punto hace referencia en la manera de cmo vamos a resolver o a llevar a cabo cierta actividad, o
bien que pasos se van a seguir para desarrollar el sistema. La metodologa del trabajo no consiste
simplemente en desarrollar, desde el exterior, las herramientas e instrumentos que permitan mejorar la gestin
en estas empresas, sino que se trata de implicar a los responsables de las mismas en esta tarea, y ello por dos
razones fundamentales:

Todo sistema de informacin que se desarrolle en el seno de una organizacin posee un marcado
carcter instrumental. Por tanto, todo intento de disear e implantar tales sistemas debe partir de tomar
en consideracin las exigencias y objetivos que a stos les plantean sus usuarios.
La experiencia nos indica que para que una nueva herramienta, o tcnica de gestin, tenga xito, es
preciso que sea asumida y entendida claramente por parte de aquellos que finalmente van a ser los
responsables de llevarla a la prctica.

20

Las metodologas vienen en muchas formas y tamaos, como pueden ser:

El enfoque de cascada:

La cascada tradicional tiene una cierta lgica, se hace un plan para un proyecto y luego se realiza el
anlisis del dominio del problema cuando se finaliza el anlisis comienza el diseo, una vez que esta terminado
el diseo comienza la construccin.

Una metodologa de cascada:

La cascada tiene un atractivo ordenado que hace que sea un modelo especialmente conveniente para
la enseanza de las tcnicas de ingeniera de software. La organizacin para el aprendizaje da una serie de
tcnicas no siempre es igual a la organizacin para el empleo en nuestro catico y ambiguo mundo real. El
desarrollo en fases incrementales y algn grado de iteracin de ajuste, siempre ha sido una prctica clave en la
implementacin exitosa de cualquiera de los llamados mtodos de cascada.

Los buenos gerentes de proyectos lo han estado haciendo durante aos, las metodologas de cascada
en realidad sufren una mala analoga, el agua siendo victima de la gravedad, no tiende a regresar hacia arriba
de la colina para dar otro paso por su propia cada. De manera similar, la gente tiende a tratar los regresos
hacia el anlisis o el diseo como una falla en vez de ser un paso hacia delante.

Implementacin en fases: Es una practica censara hacer los proyectos grandes en fases, una de las
principales razones es que el aprendizaje que se obtiene mientras se toma una parte del proyecto a travs de
un cielo de vida completo proporciona experiencia valiosa que agiliza el desarrollo de fases subsecuentes.
Otro beneficio es la entrega temprana de algunas partes del sistema que puede usar el negocio.

El Enfoque Espiral:

El modelo en espiral se basa en una serie de iteraciones en las que se cumplen unos objetivos
definidos previamente, una de estas iteraciones puede estar dedicada a la elaboracin de un estudio de
viabilidad, de los requerimientos, del trabajo de diseo, a la obtencin de prototipos funcionales, a la
depuracin, a la ampliacin de los resultados.

21

La figura siguiente refleja un modelo del ciclo de vida en espiral

DEFINICION DE
REQUERIMIENTOS
Identificar y
resolver riesgos
Determinar objetivos,
alternativas y restricciones.
Evaluar alternativas
Definicin de
requerimientos
Prototipo
operativo
DOCUMENTACION,
REQUERIMIENTOS E
INFORME DE
VALIDACION
REQUERIMIENTOS
ACORDADOS
Documentacin de
requerimientos
Validacin de
requerimientos
BORRADOR DOC. REQUERIMIENTOS

Figura 2.1 Modelo en Espiral

Lo que distingue fundamentalmente a este modelo de los anteriores, es su consideracin del riesgo, y
de los aspectos econmicos del desarrollo, mientras otros modelos atienden fundamentalmente a la elaboracin
de unos requerimientos adecuados, o a favorecer el mantenimiento o simplemente a completar
satisfactoriamente la construccin de un sistema de software. El modelo espiral se basa en el ciclo de desarrollo
en cascada, pero en vez de ser una concepcin lineal del proceso de construccin del software, lo ve como un
proceso iterativo en el que los avances hacen gradualmente y en el que se prepara rigurosamente cada paso.

22

Cada ciclo de la espiral comienza con la identificacin de ciertos elementos fundamentales para el trabajo
posterior:

Los objetivos del producto que va a ser construido: funcionalidad y de rendimiento.
Alternativas para el desarrollo: Otros diseos, rehso de elementos ya conocidos.
Las limitaciones impuestas: A la aplicacin de las alternativas.

El siguiente paso es la evaluacin de las alternativas fijando la atencin en los objetivos y las
limitaciones establecidas. Durante este proceso se suelen identificar de estas incertidumbres y la formulacin
de estrategias para resolver problemas asociados a ellas. Cuando se han evaluado los riesgos para el
desarrollo, las acciones siguientes estn determinadas por los resultados obtenidos. Si se presenta la
oportunidad de elaborar un prototipo del sistema de una forma econmica y robusta, se procede a ello.

Mientras este prototipo no se ajuste al resultado esperado se suceder el ciclo de elaboracin, cuando
el prototipo (en realidad el interfase de usuario) es satisfactorio, el proceso se orienta a la obtencin de
aspectos funcionales del sistema. Las sucesivas versiones del sistema incrementan sus capacidades en cada
ciclo de acuerdo con los objetivos marcados y las limitaciones impuestas, y respetando las condiciones para
evitar la materializacin de los riesgos identificados.

Antes de cada nueva iteracin se procede a evaluar la anterior, se valora hasta que punto se han
alcanzado los objetivos marcados y se han respetado las limitaciones impuestas. Tambin se revisan los planes
elaborados para el prximo ciclo y los riesgos detectados, aumentando el control se pretende reducir los
posibles inconvenientes que pudieran surgir durante cada ciclo.

La monitorizacin del proceso sirven tambin para identificar el momento en que la espiral debe
terminar, aunque las condiciones de cada ciclo llevan implcitos los objetivos finales del proceso, es necesaria
una nueva evaluacin continua para asegurar el cumplimiento de las condiciones de finalizacin del trabajo. Las
ventajas obtenidas de emplear este modelo frente a otros se resume en que dada la gran cantidad de opciones
disponibles se puede obtener un trabajo que haga uso de los mejores elementos de los restantes modelos de
desarrollo, y gracias a la continua evaluacin de riesgos, se evita caer en los problemas de estos modelos.

Indica tambin que potencia la reusabilidad, la incorporacin de mecanismos de calidad, la preparacin
del mantenimiento, la consideracin igualitaria de este proceso y del desarrollo, la eliminacin temprana de
errores y alternativas poco atractivas y constituye un marco en el que se integra el desarrollo de hardware y
software. La idea fue dividir el proyecto en fases mas cortas de anlisis, diseo, desarrollo y evaluacin,
despus de cada fase se evala la viabilidad del trabajo terminado junto con una estimacin refinada para las
siguientes fases.

23

Esta tcnica de presupuestacin proporciono revisiones de factibilidad cruciales para proyectos, se
toma una decisin en la fase de evaluacin sobre si se debe continuar con otra iteracin de ajuste. La idea de la
espiral ha cambiado ligeramente para adaptarse a las sensibilidades peculiares de la industria del software, la
espiral ha llegado a ser popular bajo en termino RAD (Desarrollo Rpido de Aplicaciones).

El RAD combina el enfoque espiral con una estrategia de divisin de un proyecto grande en cuadros de
tiempo. Un cuadro de tiempo es un conjunto de caractersticas definido que se compromete entregar a los
usuarios dentro de un marco de tiempo fijo, digamos noventa das, dentro del cuadro de tiempo se realiza algo
de anlisis, un diseo breve y luego, usando herramientas de desarrollo de alto poder, se construye un prototipo
funcional.

El prototipo es revisado por los usuarios y se solicitan modificaciones, el ciclo de codificacin y de
refinacin del prototipo se repite tres veces, continuando en espiral volviendo a analizar, disear y evala. Al
final del cuadro de tiempo se instala la aplicacin resultante. En la prctica, RAD sufre de las malas
aplicaciones igual que la cascada, muchos gerentes y programadores ven en el modelo espiral como tres
iteraciones de ajuste de codificacin.

La ventaja principal del RAD es la codificacin, y en muchos el establecimiento de la produccin de
cdigo es visto como la nica medida tangible de que se ha realizado una actividad significativa. Los puntos
fuertes del RAD son que los usuarios se involucran intensamente, la creacin temprana de prototipo y la
implementacin en fases.

Sus puntos dbiles incluyen una tendencia hacia la codificacin temprana, lo que hace que pasen
muchas tareas de anlisis y diseo a manos del programador y por lo tanto, depende de los tcnicos con
conocimientos generales el enfoque abrumador sobre el cuadro de tiempo hace difcil la construccin de los
componentes reutilizables a largo plazo, y cuando se acerca la fecha de entrega lo primero que se hace es la
documentacin.

En vez de administrar contra una especificacin tangible, el administrador se encuentra armado solo
con un ltigo y un cronometro, la medida de avance principal se convierte en la cantidad de revisiones que se
han hecho al cdigo.

Tanto el enfoque de cascada como el espiral tienen sus puntos buenos, desafortunadamente ambos
sufren de abusos brutales en el mundo real.
Lo que hace que una metodologa sea buena, es el armar a sus practicantes con un juego de herramientas de
tcnicas confiables y repetibles que se adecuen particularmente bien a los problemas que se estn tratando de
resolver.

24

Las tcnicas del modelador deben permitirle combinar el balance y mezcla adecuados de tcnicas para
el problema, no todos los problemas de negocios se crean igual. Algunos son ricos en datos, pero tienen muy
pocos requerimientos de procesamiento. Otros son ricos en eventos, casi sin procesamiento, pero comprenden
grandes cantidades de datos, y as sucesivamente.

Una metodologa balanceada incluye tcnicas que le dan a los analistas y diseadores una amplia
cobertura de todos los aspectos que deban modelar, pero les permite desviar sus nfasis de modelado para
adaptarse a la tendencia del problema de negocios.

Una buena metodologa de anlisis o diseo debe tener cinco caractersticas principales:

Motivar la actividad pretendida
Ser completa
Ser modificable en su correccin
Producir productos contra los que se pueda medir el avance
Ser fcilmente aprovechable en la fase subsecuente

El buen diseo debe motivar la toma de decisiones ayudando a evaluar alternativas:

Todo el diseo es acerca de compromisos, no hay solucin perfecta en el ambiente cliente/servidor, para
cada requerimiento esencial del negocio habr muchas formas posibles de lograrlo. Una tcnica de diseo debe
permitir que el diseador evalu su decisin contra otras posibilidades, por ejemplo: usando el modelo de
anlisis de eventos acoplado con el esquema de diseo de datos.

El diseo necesita ser completo, de tal forma que cubra cada uno de los aspectos principales del software
que necesita construirse, esto causara que se tengan varios tipos diferentes de modelos en la documentacin
del diseo. En forma similar a los planos arquitectnicos para la cimentacin, ningn modelo puede mostrar
todas las facetas del sistema funcional completo, esto seria el sistema mismo.

El diseo debe ser verificable antes de su construccin, uno de los propsitos principales del diseo es
revisar y discutir antes de lanzarse a la carga y codificarla, con una buena especificacin de diseo se debe ser
capaz de demostrar que se satisfarn los requerimientos del proyecto y as mismo se distinguir entre varias
versiones del diseo en cualquier momento. Una buena metodologa de diseo crea productos diferenciados
que son mesurables.

25

Una de las tareas mas difciles de cualquier proyecto es estimar cuando se terminara, para hacer
estimacin el gerente del proyecto deber tomar medidas, las cuales involucran el conteo de cosas que
necesitan hacerse y la aplicacin de algn tipio de medida sobre ellas para estimar que tanto tiempo se llevara
el hacerlas.

Por ultimo, pero no menos importante, el diseo debe ser fcilmente aprovechado en el producto final,
debe expresarse el uso y la estructura del sistema en una forma muy cercana al resultado pretendido. El lema
del diseador es: hacer un mapa de la tcnica hacia el destino, si el sistema va a operar con una base de datos
relacional se deben escoger tcnicas que sean particularmente adecuadas para el diseo de bases de datos
relacinales. Si el sistema empleara un lenguaje orientado a objetos, entonces se debern usar tcnicas de
diseo orientadas a objetos para las partes del sistema que requieren objetos para lograr sus tareas.

Caractersticas de las buenas metodologas de anlisis:

1. Una tcnica de anlisis debe motivar el acto del descubrimiento proporcionando un marco de trabajo en
el que el analista puede escribir lo que ellos saben y evaluar lo que tiene que aprender, esto incluye el
tener inventiva para guiar el anlisis.
2. La metodologa de anlisis debe ser completa respecto a que cubra adecuadamente cada uno de los
aspectos del problema de negocios, los sistemas de negocios tienen datos que deben recordarse,
reglas de procesamiento y comportamiento definible.
3. Los resultados de anlisis necesitan ser modificables, la fase de anlisis tambin tiene un publico dual,
el usuario promedio no va a descubrir una relacin de cardinalidad que no sea exacta en un modelo de
informacin, como tampoco va a poner en duda el empleo de la herencia mltiple en los diagramas de
Case orientados a objetos.
4. Esto nos lleva al punto final de la posibilidad de su aprovechamiento, nadie en esta industria puede
negar que una metodologa de anlisis debe motivar al propio anlisis, ser completa, verificable y
mesurable.
Metodologa CASE para el desarrollo de sistemas:
Los sistemas informticos, al agilizar y optimizar el almacenamiento, difusin y procesamiento de la
informacin, mejoran la produccin de las organizaciones que los emplean para la automatizacin de sus
funciones. Sin embargo, si no se tienen en cuenta ciertos elementos en el diseo e implantacin, no siempre la
automatizacin significa un aumento de la produccin.

26

Hay que considerar por un lado, que hay un costo asociado a la adquisicin de nueva tecnologa
consistente en equipos y programas; y por otro, que an teniendo la tecnologa ms moderna, la automatizacin
puede ser ineficiente y no operativa si no se realiz previamente un anlisis de las necesidades de la
organizacin, de las diferentes ofertas tecnolgicas en el mercado y un diseo de los sistemas adecuado tanto
a las funciones de la organizacin como a la tecnologa empleada.
Por ejemplo, en la actualidad es muy comn automatizar de manera independiente ciertas funciones de
una organizacin utilizando computadoras personales y paquetes comerciales econmicos. En un principio
este tipo de sistemas pueden satisfacer las necesidades de la funcin automatizada, pero posteriormente
cuando es necesario contar con accesos flexibles de informacin consistente y que englobe todas las funciones
de la organizacin, dichos sistemas se vuelven inadecuados, otra posibilidad es que debido a la falta de un
dimensionamiento previo del sistema, el equipo adquirido puede resultar a corto plazo insuficiente u obsoleto.
Por lo tanto, antes de iniciar una automatizacin es importante tener en cuenta que:
Las organizaciones son complejas y realizan diversas funciones que estn relacionadas entre si, que
sus necesidades de manejo de informacin cambian y crecen, y que adems del manejo operativo de la
informacin hay una necesidad de contar con un acceso global que permita una mejor toma de
decisiones
La tecnologa es muy cambiante, cada vez hay mayor variedad de equipos y sistemas mas poderosos
de costos diversos, lo que complica la seleccin de la tecnologa adecuada
El diseo, la programacin y la operacin de los sistemas requieren de especialistas
Por lo antes mencionado, si se pretende que realmente una automatizacin no solamente redunde en
una mejora de la produccin sino que adems resulte una inversin rentable en cuanto a la adquisicin de una
tecnologa adecuada, es necesario contar con una metodologa de desarrollo de sistemas. Dado que el
desarrollo de sistemas de informacin es una actividad compleja, sta puede dividirse para su estudio en las
siguientes etapas:
Definicin y anlisis de los requerimientos del usuario.
Diseo del sistema y de la base de datos.
Implantacin y prueba de mdulos.
Integracin y prueba del sistema.
Operacin y mantenimiento.
Como estas etapas a su vez son muy elaboradas, han surgido varias metodologas que permiten realizarlas
de una manera estructurada.

27

El mtodo CASE (Computer Aided Systems Engineering) plantea una secuencia de etapas que es
aproximadamente equivalente a la citada arriba, pero es ms detallada, y adems proporciona para cada etapa
su descripcin, definicin de objetivos y metas, productos de la etapa, factores crticos de xito, y la lista de
tareas que conviene realizar.
Adems es posible auxiliarse de herramientas CASE que facilitan grandemente la puesta en prctica del
mtodo. Esta tecnologa ha sido utilizada para el diseo de diversos sistemas que se han desarrollado en
LANIA. A continuacin presentamos la metodologa CASE.
Etapas en el mtodo CASE:
La metodologa CASE se basa en un anlisis y desarrollo del tipo descendiente ("topdown") en que el
ciclo de vida de un sistema se compone de las siguientes etapas [1], [2] y [3] (ver figura 2.1):
Estrategia
Anlisis
Diseo
Construccin
Documentacin
Transicin
Produccin

Figura 2.2 Etapas del mtodo CASE.

28

Estrategia:
Esta es una de las etapas ms importantes, ya que tiene por objetivo lograr un entendimiento claro de
las necesidades de la organizacin y del ambiente en que operar el sistema o sistemas a implantar. Con el fin
de tener una visin desde los puntos de vista de la direccin corporativa, se analizan las diferentes funciones
que realiza la organizacin y sus necesidades de informacin a todos niveles, durante esta etapa se realizan
una serie de entrevistas con la direccin y los responsables de los departamentos.
As a partir de esta informacin se realiza as un primer modelado de los requerimientos del sistema de
informacin adecuado a las necesidades de la organizacin. Posteriormente para la definicin de una primera
versin de la arquitectura del sistema, adems de los requerimientos antes obtenidos, se toman en cuenta las
tecnologas en ese momento disponible y los sistemas de informacin ya existentes en operacin. En la figura
2.3 se muestra este proceso.

Figura 2.3 Etapa de Estrategia
Los resultados de esta etapa son, un conjunto de modelos de la empresa, un conjunto de
recomendaciones, y un plan acordado de desarrollo de los sistemas de informacin, la elaboracin de este
ltimo se har de acuerdo las necesidades actuales y futuras de la organizacin, tomando en cuenta
restricciones operativas, financieras y tcnicas.
Anlisis:
La etapa de anlisis toma y verifica los descubrimientos de la etapa de estrategia y expande estos en
suficiente detalle para asegurar la precisin de los modelos de la empresa, posibilitando un fundamento slido
para el diseo, dentro del alcance de la organizacin y tomando en cuenta sistemas existentes.

29

Con el fin de obtener un refinamiento de los modelos, durante esta etapa se realiza otra serie de
entrevistas ya no a un nivel directivo como en la anterior, sino a un nivel operativo y tcnico. Con la
participacin los responsables de la operacin de las funciones que sern automatizadas se realizan un anlisis
detallado de sus requerimientos especficos en cuanto a objetivos, subfunciones, informacin, datos, etc.
As, en esta etapa a partir de los modelos de la organizacin obtenidos en la anterior y del producto del
anlisis de sta, se genera el modelado del sistema. Los modelos bsicos de esta etapa son: El de entidad-
relacin, que modela mediante relaciones lgicas todos los datos involucrados en el sistema, de tal manera que
cualquier tipo de explotacin (consulta o modificacin) sean posibles. El funcional, que modela las diferentes
servicios que ofrecer el sistema mediante una organizacin y clasificacin de las diversas funciones y
subfunciones que fueron identificadas en el anlisis.
Como resultados de esta etapa, adems del modelo de entidad-relacin y el funcional, se definen las
restricciones que tendrn el sistema y la estrategia que se seguir en la etapa de transicin. El proceso de esta
etapa y sus resultados se muestran en la figura 2.4.
Figura2.4 Etapa de Anlisis
Diseo:
La etapa de diseo toma los requerimientos y el modelado de la etapa de anlisis y determina la mejor
manera de satisfacerlos, logrando niveles de servicios acordados, dados el ambiente tcnico y las decisiones
previas en los niveles requeridos de automatizacin.

30

Es decir que del diseo conceptual se pasa al diseo final que ser utilizado para la implantacin, por
ejemplo en esta etapa, el modelo entidad-relacin ser transformado en un diseo de base de datos, y en
especificaciones de almacenamiento y el modelo de funcional, en mdulos y manuales de procedimientos.
El diseo final del sistema integra tres diseos, el de la base de datos, el de la aplicacin y el de la red
adems se elaboran los planes de prueba y de transicin y se realizan los diseos de los sistemas de auditoria
y control, y el de respaldos y recuperacin. Los resultados de esta etapa lo constituyen, la arquitectura del
sistema, el diseo de la base de datos, la especificacin de los programas, la especificacin de los manuales de
procedimientos.
En la figura 2.5 se muestra esta etapa

Figura 2.5 Etapa de Diseo
Construccin:
A partir del diseo final generado en la anterior etapa, en esta de construccin, se codificarn y
probarn los nuevos programas, usando herramientas apropiadas. Esta etapa involucra planeacin, diseo de
la estructura del sistema, codificacin de abajo a arriba (prueba de unidades y enlaces), pruebas de arriba a
abajo (prueba del sistema) y un enfoque disciplinado en la realizacin del trabajo y en el control de versiones
del sistema y pruebas. Los resultados de esta etapa son los programas probados y la base de datos afinada.
Los resultados de esta etapa lo constituyen los programas probados y las bases de datos afinada, en la
siguiente figura se muestra el proceso de esta etapa.

31

Figura 2.6 Etapa de Construccin
Documentacin:
Uno de los productos fundamentales para un uso y un mantenimiento efectivos y eficientes de los
sistemas programados son los manuales. Esta metodologa incluye una etapa dedicada a esta actividad tan
importante y hace hincapi para que en su elaboracin se consideren el estilo de trabajo y las necesidades
propias de los usuarios que utilizarn y mantendrn el sistema. Esta etapa se realiza al mismo tiempo que la de
construccin.
Los manuales, resultados de esta etapa, se elaboran a partir de las especificaciones de diseo, de los
programas realizados y del anlisis del estilo de trabajo y nivel de competencia de los usuarios y operadores de
los sistemas. En la figura 2. 6 se muestra el proceso de esta etapa.

Figura 2.7 Etapa de Documentacin

32

Transicin:
La implantacin de sistemas no necesariamente implica la sustitucin total de los antiguos subsistemas
y de sus bases de datos correspondientes. En ciertos casos, por razones operativas y/o econmicas, los
nuevos sistemas integran algunos de los antiguos; pero como quiera que sea, la introduccin ya sea de un
sistema completamente nuevo o un sistema que integra ya existentes implica un nuevo tipo de uso y de
operacin que deber ser asimilado y aprendido por los usuarios y operadores.
Por esta razn, el desarrollo de un sistema no se termina con su programacin; antes de su liberacin
para su uso, se debe prever un perodo de transicin que deber incluir la alimentacin de las nuevas bases de
datos, la capacitacin de los usuarios y el desarrollo de pruebas.
En esta metodologa la transicin conforma una de sus etapas y en ella se realizan se realizan todas las
tareas necesarias para la implementacin y proporciona un periodo inicial de soporte al sistema. La transicin
debe llevarse a cabo con una interrupcin mnima de la organizacin, y debe dejar a los usuarios confiados y
listos para explotar el nuevo sistema. El resultado final de esta etapa es un reporte que muestre que las
pruebas fueron satisfactorias, en la figura siguiente se muestra el proceso de esta etapa.

Figura 2. 8 Etapa de Transicin

33

Produccin:
Finalmente, en la etapa de produccin se asegura que el sistema funcione correctamente en la mayora
de los casos, y con intervencin mnima de los administradores del sistema. Para esto se realizan nuevas
pruebas, se reevalan los resultados y se hacen refinamientos del sistema, los cambios necesarios debern ser
introducidos sin afectar a los usuarios, y deber conseguirse la mxima confianza de los usuarios. El resultado
de esta etapa un sistema listo para su operacin.

Figura 2. 9 Etapa de Produccin

34

III. ANALISIS Y DISEO DE SISTEMA

El anlisis es el proceso de determinar que se necesita hacer antes de decir como debe hacerse, el
diseo es el proceso de determinar cual de muchas posibles soluciones es la mejor para lograr que se necesite
hacer, respetando las restricciones tecnolgicas y de presupuesto del proyecto. El diseo escoge un como
especifico para aplicarlo al que, el anlisis es el acto de descubrimiento, el diseo es el arte del compromiso.

Tradicionalmente, los esfuerzos del anlisis han tenido una dudosa reputacin en el desarrollo del
software, casi todos saben que algn proyecto al que se le dedicaron intocables meses( o a veces aos)
dibujando miles de burbujas, cuadros, lneas, solo para ser abandonados en un librero y comenzar a codificar
apresuradamente. La mayora de los proyectos que fracasaron lo hacen por falta de una buena administracin
del proyecto y por fallas en el anlisis de las necesidades del negocio y para disear una solucin antes de
realizar la construccin del producto.

Se podra decir que el propsito del anlisis y diseo, es al menos, evitar que se cargue el proyecto y lo
optimo que articule completamente las necesidades del negocio con base en una comprensin de sus
problemas actuales y que encuentre la solucin que mejor satisfaga las necesidades y se ajuste a las
restricciones presupustales de recursos y tiempo impuesto por el propio negocio. Un arquitecto residencial
determina los deseos gustos, problemas particulares, necesidades y presupuesto del propietario de la casa y
luego explora las soluciones de diseo para verificar y validar los requerimientos antes de construir.

El analista de software define la naturaleza del problema del negocio y el diseador de software explora
diversas soluciones, tomando decisiones bien informadas para llegar a un producto que dejara a los usuarios
satisfechos. Esto se reduce a un concepto muy simple: Encuentre lo que el negocio requiere que se haga
antes de comenzar a imaginarse como hacerlo.
Objetivos del anlisis del sistema:
Identificar las necesidades del cliente
Evaluar la viabilidad del sistema
Realizar un anlisis tcnico y econmico
Modelado de la arquitectura del sistema
Especificaciones del sistema

35

Identificacin de necesidades:
Es el primer paso del anlisis del sistema, en este proceso en Analista se rene con el cliente y/o
usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales, se
analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificacin temporal y
presupuestal, lneas de mercadeo y otros puntos que puedan ayudar a la identificacin y desarrollo del
proyecto. Antes de su reunin con el analista, el cliente prepara un documento conceptual del proyecto, aunque
es recomendable que este se elabore durante la comunicacin Cliente analista, ya que de hacerlo el cliente
solo de todas maneras tendra que ser modificado, durante la identificacin de las necesidades.
Estudio de viabilidad:
Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo
no son realistas para su materializacin sin tener prdidas econmicas y frustracin profesional. La viabilidad y
el anlisis de riesgos estn relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de
producir software de calidad se reduce, sin embargo se deben tomar en cuenta cuatro reas principales de
inters:
Viabilidad econmica: Una evaluacin de los costos de desarrollo, comparados con los ingresos netos
o beneficios obtenidos del producto o Sistema desarrollado.
Viabilidad tcnica: Un estudio de funciones, rendimiento y restricciones que puedan afectar la
realizacin de un sistema aceptable.
Viabilidad legal: Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en
que se podra incurrir al desarrollar el Sistema.
Alternativas: Una evaluacin de los enfoques alternativos del desarrollo del producto o Sistema. El estudio de
la viabilidad puede documentarse como un informe aparte para la alta gerencia.
Anlisis econmico y tcnico:
El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios, significa una
valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y
utilidad del producto o sistema. Muchas veces en el desarrollo de Sistemas de Computacin estos son
intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la caractersticas del Sistema.
El anlisis de costos beneficios es una fase muy importante de ella depende la posibilidad de
desarrollo del Proyecto. En el Anlisis Tcnico, el Analista evala los principios tcnicos del Sistema y al mismo
tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas de mantenimiento y
productividad.

36

Los resultados obtenidos del anlisis tcnico son la base para determinar sobre si continuar o
abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no
encajan perfectamente unas con otras.
Modelado de la arquitectura del sistema:
Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios, Herramientas,
Aviones, Maquinas, se crea un modelo idntico, pero en menor escala (mas pequeo). Sin embargo cuando
aquello que construiremos es un Software, nuestro modelo debe tomar una forma diferente, deben representar
todas las funciones y subfunciones de un Sistema.
Los modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos pueden
incluir notacin grfica, informacin y comportamiento del Sistema. Todos los Sistemas basados en
computadoras pueden modelarse como transformacin de la informacin empleando una arquitectura del tipo
entrada y salida.
Especificaciones del sistema:
Es un Documento que sirve como fundamento para la Ingeniera Hardware, software, Base de datos, e
ingeniera Humana. Describe la funcin y rendimiento de un Sistema basado en computadoras y las dificultades
que estarn presentes durante su desarrollo. Las Especificaciones de los requisitos del software se producen
en la terminacin de la tarea del anlisis.
Un proyecto de desarrollo de un Sistema de Informacin comprende varios componentes o pasos
llevados a cabo durante la etapa del anlisis, el cual ayuda a traducir las necesidades del cliente en un modelo
de Sistema que utiliza uno ms de los componentes: Software, hardware, personas, base de datos,
documentacin y procedimientos.
3.1 Investigacin Preliminar
Cuantas veces se est en situaciones en donde se pregunta si no existe una mejor manera de hacer algo? :
Por ejemplo, abrir una tienda departamental adicional que crear una necesidad para nuevos
procedimientos de facturacin, cuando un alto porcentaje de clientes utiliza la cuenta de crdito de esta
compaa de esta compaa y compra en todas las tiendas. Duplicar el nmero de clientas para agrandar las
instalaciones y la introduccin de muchos nuevos productos, puede traer nuevos requerimientos de pago e
cuentas. Un cambio en las reas de los gerentes departamentales puede guiarlos hacia nuevas formas para
registrar las ventas, con implicaciones para el sistema de entrada de pedidos basado en computadora.

37

Una compaa en crecimiento, puede contemplara los sistemas de informacin computarizados como
una forma para hacer posible el crecimiento continuo, sin tener dificultades en el proceso de los pedidos de los
clientes. Se puede inicias una peticin por muchas razones, pero la clave es que alguien, ya sea gerente, un
empleado o un especialista de sistemas, inicie un requerimiento para recibir ayuda de un sistema de
informacin. Cuando ese requerimiento se realiza, la primera actividad de sistemas, es decir, la investigacin
preliminar, se inicia.
Esta actividad tiene tres partes: clarificacin de requerimiento, estudio de la factibilidad y aprobacin del
requerimiento. El resultado ser aprobar el requerimiento para la atencin posterior o rechazarlo como no
factible para un desarrollo futuro.
Clarificacin del requerimiento:
En las empresas muchos requerimientos de los empleados y usuarios no estn establecidos
claramente; por lo tanto, antes de que pueda considerarse la investigacin del sistema, le proyecto requerido
debe examinarse para determinar para determinar precisamente lo que desea la empresa. Una simple llamada
telefnica puede ser suficiente si la persona que requiere el servicio tiene una idea clara, pero no sabe cmo
establecerla. Por otro lado, la persona que hace el requerimiento puede estar simplemente pidiendo ayuda sin
saber qu es lo que est mal o por qu existe un problema. La clarificacin del problema es este caso, antes
de poder llagar a otro paso, el requerimiento de proyecto debe estar claramente establecido.
Estudio de Factibilidad:
Un resultado importante de la investigacin preliminar es la determinacin de que el sistema requerido
es factible. Existen tres aspectos en el estudio de factibilidad de la investigacin preliminar:
1. Factibilidad tcnica: Puede realizarse el trabajo para el proyecto con el equipo actual, tecnologa de
software y el personal disponible? Si se requiere nueva tecnologa, qu probabilidades hay de que
pueda desarrollarse?
2. Factibilidad econmica: Existen suficientes beneficios en la creacin del sistema para hacer que los
costos sean aceptables? O, en forma inversa, son tan altos los costos como para que el proyecto no
deba llevarse a cabo?
3. Factibilidad operativa: Se utilizar el sistema si se desarrolla y pone en marcha? Habr resistencia
de los usuarios, que los posibles beneficios reducirn del sistema.
El estudio de factibilidad se lleva a cabo con un pequeo grupo de gente, familiarizada con las tcnicas
de los sistemas de informacin, que entienden la parte de la empresa que ser afectada por el proyecto y tienen
los conocimientos suficientes del proceso de anlisis y diseo de sistemas.

38

Aprobacin del requerimiento:
No todos los proyectos requeridos son deseables o factibles. Sin embargo, aquellos que son tanto
factibles como deseables deben anotarse para tomarlos en cuenta. En algunos casos, el desarrollo puede
comenzar inmediatamente, pero en la mayor parte, los miembros del departamento de sistemas estn
ocupados en otros proyectos que se encuentran en marcha. Cuando esto sucede, la gerencia decide que los
proyectos son ms importantes y entonces los programas.
Despus de que se aprueba la requisicin de un proyecto, se estima su costo, la prioridad, el tiempo de
terminacin y los requerimientos del personal que se utilizan, para determinar qu lista existente los proyectos
se incluirn. Posteriormente, cuando se terminan algunos proyectos anteriores, puede iniciarse el desarrollo de
la aplicacin propuesta. En este momento, comienza la recabacin de datos y la determinacin de los
requerimientos.
Determinacin de requerimientos:
El punto clave de anlisis de sistemas se consigue al adquirir un conocimiento detallado de todas las
facetas importantes dentro del rea de negocios que se investiga. (Por esta razn, a menudo esta actividad se
conoce como investigacin detallada.) Los analistas, al trabajar con los empleados y gerentes, deben estudiar
el proceso que actualmente se efecta para contestar estas preguntas clave:
Qu se est haciendo?
Cmo se est haciendo?
Qu tan frecuentemente ocurre?
Qu tan grande es la cantidad de transacciones o decisiones?
Qu tan bien se lleva acabo la tarea?
Existe algn problema?
Si el problema existe, qu tan serio es?
Si el problema existe, cul es la causa principal?
Para contestar estas preguntas, los analistas de sistemas hablarn con diferentes personas para
recabar los detalles en relacin con el proceso, as como sus opiniones sobre las causas por las cuales
suceden las cosas de esa manera y algunas ideas en relacin a modificarlas. Se utilizan cuestionarios para
recopilar esta informacin, aplicndolos a grandes que no pueden entrevistarse en forma individual. Las
investigaciones detalladas tambin requieren el estudio de manuales y reportes, la observacin real de las
actividades de las actividades de trabajo y algunas veces la recabacin de formas y documentos para entender
completamente el proceso.

39

Conforme se recopilan los elementos, los analistas estudian los requerimientos de datos para identificar
las caractersticas que tendr el nuevo sistema, incluyendo la informacin que el sistema debe producir y las
caractersticas operativas, como son controles de procesamiento, tiempos de respuesta y mtodos de entrada y
salida.
Desarrollo del sistema prototipo:
La preparacin de prototipos es el proceso de crear, desarrollar y refinar un modelo funcional del
sistema final. Se puede crear un modelo prototipo preliminar durante la etapa de definicin del problema. Un
miembro del equipo de reconocimiento -suponga que se trata de un especialista en el procesamiento de datos-
puede construir un modelo de este tipo que muestre la composicin de las pantallas y los formatos de los
informes. Durante una sesin de requerimientos, otros miembros del equipo y usuarios del futuro sistema
examinan esta muestra en la forma con el constructor del modelo entiende en principio el problema y los
resultado que debe producir el sistema. En este momento puede iniciarse un proceso de refinacin si los
usuarios sealan omisiones y equivocas.
Durante este proceso de refinacin, cuyo objetivo es definir la necesidad que existe, uno o ms
miembros del equipo pueden utilizar una computadora personal y un paquete de programas de prototipos a fin
de crear una serie de pantallas en la computadora personal. Estas pantallas no son las salidas que producen
los programas ya terminados, pero pueden parecerse mucho a esos resultados. Es posible exhibir en el monitor
de la computadora, como una secuencia de diapositivas, mens de captura de datos, la interfaz con el usuario
debe servir para buscar, consultar y manipular datos y el formato de los informes de salida.
Por ejemplo, se pueden simular los resultados de una serie de selecciones hechas en mens para que
los usuarios tengan una idea ms clara de la forma como el constructor o los constructores del sistema estn
interpretando el problema. Si los usuarios no estn convencidos de lo que se exhibe define con precisin sus
necesidades, pueden modificar fcilmente las plantillas prototipo hasta que estn satisfechos.
La creacin de un modelo preliminar de prototipo en este punto produce varios beneficios: los usuarios
pueden ver que se est avanzado, se les motiva para que participen activamente en la definicin del problema,
se mejora la comunicacin 4entre todas las partes interesadas y se aclaran los equvocos en una etapa
temprana del estudio de sistemas, antes de que se conviertan en costosos errores.
Como se acaba e ver, puede ser necesario un proceso repetitivo (o interactivo) para terminar el paso de
definicin del problema. No existe un procedimiento definido que se deba seguir antes de que se pueda
iniciarse el anlisis detallado del sistema.

40

Un alto ejecutivo puede creer que existen diferencias de informacin. Puede preparar una declaracin
general de los objetivos y nombrar a un gerente para que realice un reconocimiento. Pueden realizarse varias
sesiones de requerimientos para traducir los deseos generales a objetivos ms especficos. Asimismo, pueden
crearse y refinarse modelos preliminares de prototipo; se puede ampliar o reducir el alcance del estudio y es
posible tambin que cambien los objetivos conforme se renan los datos.
Una vez que parezca haberse logrado la aprobacin en cuanto a la definicin del problema, el equipo
de reconocimiento deber poner la definicin detallada por escrito y enviarla a todas las personas interesadas,
las cules debern aprobarla tambin por escrito. Si persisten diferencias, debern resolverse en sesiones
adicionales de requerimientos.
Hay quienes se impacientan con los retrasos en el desarrollo del sistema causados por estas sesiones
adicionales. Sin embargo, las personas ms prudentes saben que los retrasos verdaderamente largos y
costosos se presentan cuando los usuarios descubren, ya muy avanzados el proceso del desarrollo, que el
sistema diseado no es satisfactorio por haberse pasado por alto algunos requerimientos.
Diseo del sistema:
El diseo de un sistema de informacin produce los elementos que establecen cmo el sistema
cumplir los requerimientos indicados durante el anlisis de sistemas. A menudo los especialistas de sistemas
se refieren a esta etapa como en diseo lgico, encontraste con desarrollo del software de programas, que se
conoce como diseo fsico. Los analistas de sistemas comienzan por identificar los informes y otras salidas que
el sistema producir. A continuacin los datos especficos con stos se sealan, incluyendo su localizacin
exacta sobre el papel, la pantalla de despliegue u otro medio. Usualmente, los diseadores dibujan la forma o la
visualizacin como la esperan cuando el sistema esta terminado.
El diseo del sistema tambin describe los datos calculados o almacenados que se introducirn. Los
grupos de datos individuales y los procedimientos de clculo se describen con detalle. Los diseadores
seleccionan las estructuras de los archivos y los dispositivos de almacenamiento, como son discos magnticos,
cintas magnticas o incluso archivos en papel. Los procedimientos que ellos escriben muestran cmo se van a
procesar los datos y a producir la salida. Los documentos que contienen las especificaciones de diseo utilizan
muchas formas para representar los diseos, diagramas, tablas y smbolos especiales, algunos de los cuales el
lector puede haber utilizado ya y otros que pudieran ser totalmente nuevos. La informacin del diseo detallado
se pasa al grupo de programacin para que pueda comenzar el desarrollo del software.
Los diseadores son responsables de proporcionar a los programadores las especificaciones completas
y escritas con claridad, que establezcan lo que debe hacer el software. Conforme comienza la programacin,
los diseadores estn pendientes para contestar preguntas, esclarecer ideas confusas y manejar los problemas
que confronten los programadores cuando utilicen las especificaciones de diseo.

41

Desarrollo del software:
Los desarrollares del software pueden instalar o modificar; por ejemplo, software comercial que se haya
comprado, o pueden escribir programas nuevos diseados a la medida. La decisin de qu se va a hacer
depende del costo de cada una de las opciones, el tiempo disponible para describir el software y la
disponibilidad de programadores.
En forma usual, en las grandes empresas los programadores de computadoras (o la combinacin de
analistas-programadores) son parte del grupo profesional permanente. Las compaas ms pequeas en donde
los programadores permanentes no se han contratado, pueden obtener servicios externos de programacin con
base en un contrato.
Los programadores tambin son responsables de documentar el programa e incluir los comentarios que
expliquen tanto cmo y por qu se utilizo cierto procedimiento conforma se codifico de cierta forma. La
documentacin es esencial para probar el programa y darle mantenimiento una vez que la aplicacin se ha
puesto en marcha.
Prueba de los sistemas:
Durante la prueba, el sistema se utiliza en forma experimental para asegurar que el software no falle; es
decir, Que corra de acuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga. Se
examinan datos especiales de prueba en la entrada del procesamiento y los resultados para localizar algunos
problemas inesperados. Puede permitirse tambin a un grupo limitado de usuarios que utilice el sistema, de
manera que los analistas puedan captar si tratan de utilizarlo en forma no planeadas.
Es preferible detectar cualquier anomala antes de que la empresa ponga en marcha el sistema y
dependa de l. En muchas compaas la prueba se lleva a cabo por personas diferentes a aquellos que los
escriben en forma original; es decir si se utilizan personas que no conocen como se disearon ciertas partes de
los programas, se asegura una mayor y ms completa prueba, adems de ser imparcial, lo que da a un
software ms confiable.
Puesta en marcha:
Cuando el personal de sistemas verifica y pone en uso el nuevo equipo, entrena al personal usuario;
instala la nueva aplicacin y constituye los archivos de datos que se necesiten, entonces el sistema est puesto
en marcha. De acuerdo con el tamao de la empresa que emplear la aplicacin y el riesgo asociado con su
uso, los desarrolladores del sistema pueden escoger una prueba piloto para la operacin del sistema solamente
en un rea de la compaa; por ejemplo, en un departamento o slo con una o dos personas.

42

A veces corrern en forma paralela tanto el sistema anterior como el nuevo para comparar los
resultados de ambos; en otras situaciones, los desarrolladores pararn por completo el sistema anterior un da y
al siguiente empezarn a utilizar el nuevo. Como se puede apreciar, cada estrategia para la puesta en marcha
tiene sus mritos, que dependen de la situacin del negocio considerado.
Sin importar la estrategia para la puesta en marcha que se haya utilizado, los desarrolladores tendrn
que asegurarse que el uso inicial del sistema est libre de problemas. Una vez instalada, con frecuencia la
aplicacin se utiliza por muchos aos; sin embargo, tanto la empresa como los usuarios cambiarn, y el medio
ambienta ser diferente tambin a travs del tiempo.
Por lo tanto, la aplicacin indudablemente necesitar mantenimiento; es decir, se harn cambios y
modificaciones al software, y a los archivos o procedimientos para cubrir los requerimientos nuevos de los
usuarios. Los sistemas de la empresa y el medio ambiente de los negocios estn en continuo cambio. Los
sistemas de informacin deben mantenerse de la misma forma; es este sentido, la propuesta en marcha es un
proceso continuo.
Retroalimentacin:
Ya implementado el sistema se recibe retroalimentacin de parte de los usuarios para ver si es necesaria
alguna modificacin o mejora que no se haya detectado durante las pruebas o la implementacin inicial.
3.2 Anlisis de Factibilidad
Es el proceso por el cul se miden distintos aspectos del posible xito de un proyecto y el producto que
genera, Para qu y cundo analizar la factibilidad?:

Se usa para ayudar a decidir si seguir adelante o no con un proyecto de Ingeniera de Software.
Deber llevarse a cabo a lo largo del ciclo de vida del sistema.

La cuestin clave: Los proyectos comienzan cuando alguien tiene una oportunidad de crear un negocio
usando tecnologa informtica.

43

Qu se debe estudiar?: La organizacin dnde se inserta el proyecto, incluyendo usuarios, polticas,
funciones, objetivos, plan de negocios, etc.:

Las restricciones existentes, incluyendo requerimientos no funcionales (superficialmente).
Las alternativas posibles (entre ellas, dejar todo como est).
Pros y contras de cada alternativa.

Tcnicas:

Factibilidad Operativa
Factibilidad Tcnica
Factibilidad de Cronograma
Factibilidad Econmica

Factibilidad operativa:

Vale la pena que el problema sea resuelto o la solucin para el problema funcionar?
Qu piensan la gerencia y los usuarios finales?

Aspectos a considerar:

Performance
Informacin
Economa
Control
Eficiencia
Servicios
Ejemplo:
Tomemos el caso de un banco que en la actualidad maneja el conjunto de sus operaciones en forma
tradicional cuyos sistemas tienen un gran porcentaje de procesamiento manual y en algunos casos batch (en la
casa matriz), que decide utilizar tecnologa de punta, y automatizar el grueso de sus operaciones, incorporar
cajeros automticos, conectar todos sus sistemas a una red de comunicaciones, y distribuir capacidad de
procesamiento para sus 50 sucursales.

44

Desde el punto de vista tcnico y econmico, el proyecto resulta, viable, dado que este tipo de
instalacin est ampliamente aprobada por otras entidades financieras, los beneficios que resultan de un
proyecto de inversin de esta naturaleza son de fcil comprobacin no hay ms que consultar a las otras
empresas y adems las compaas proveedoras de equipos ya han adquirido experiencia suficiente, con un
gran parque instalado y hasta existe la posibilidad de adquirir sistemas preplaneados de buen rendimiento y
bajo costo.
En este caso el anlisis de Factibilidad operativo adquiere, su mayor significacin, ya que la viabilidad
del sistema no est en duda, pero lo que falta verificar es si este Banco, est en condiciones de absorberlo; ya
que, el personal no tiene experiencia en el manejo de este tipo de sistemas, los gerentes vern modificados los
procedimientos del conjunto de su operatoria y adems debern estar a la cabeza del cambio. Surgirn
adems los temores de una racionalizacin, adems de la resistencia natural al cambio en todos los niveles; la
operatoria de cada sucursal sufrir profundas modificaciones, se requerir la capacitacin del personal en gran
escala; la participacin como usuario
(Una nueva funcin) en la definicin de los futuros sistemas, podrn surgir modificaciones en la
estructura de poder de la organizacin que tendrn relacin directa con la reestructuracin orgnica, etc. y
adems de todo esto se deber seguir cumpliendo con las actividades diarias para que el Negocio siga
funcionando. Como vemos un cambio de esta envergadura puede generar una sucesin interminable de
conflictos que si se dejan librados al azar las posibilidades de xito del proyecto tendrn un alto grado de
aleatoriedad. No se puede relativizar el estudio operativo y a efectos de reducir los mrgenes de riesgo se
deber:
Establecer el alcance de los cambios organizacionales
Evaluar las normas, mtodos y funciones organizacionales vigentes.
Evaluar el desarrollo organizativo alcanzado.
Analizar las relaciones de poder actuales y futuras y su efecto sobre el proyecto.
Trazar una hiptesis de conflictos potenciales.
Efectuar un anlisis sobre la oportunidad del proyecto.

45

Definicin de los cambios organizacionales a efectuar, en esta fase se deber:
Efectuar una estimacin sobre las reas que debern ser reestructuradas y la envergadura del cambio
en cada caso.
Disear la estructura del rea de sistemas en relacin con los resultados del estudio de Factibilidad
tcnico.
Definir roles y funciones.
Establecer criterios para planificar la capacitacin del personal afectado.
Estimar costos y beneficios operativos (Tangibles e intangibles)
Factibilidad tcnica:

La solucin propuesta es prctica?
La tecnologa para alguna solucin definida est normalmente disponible?
Est madura?
Es fcilmente aplicable?
Est ampliamente difundida?

Preguntas a considerar:

Hay antecedentes de su uso en casos similares?
Poseemos la tecnologa necesaria?
Tenemos el conocimiento tcnico necesario?
Podemos incorporar la nueva tecnologa en nuestra estructura de desarrollo?
Podemos incorporar la nueva tecnologa en el cliente?
Evaluacin preliminar:
A efectos de disear la configuracin del equipo ser necesario, en forma previa, dimensionar la
instalacin, es decir, establecer la cantidad de dispositivos, su capacidad y velocidades para cada tipo de
proceso, segn los requerimientos de las aplicaciones a procesar, como as tambin, definir el tipo de
dispositivos perifricos a configurar.
Estos elementos se debern evaluar dentro del encuadre que fija la Estrategia de Sistemas en cuanto a
la filosofa de procesamiento y arquitectura de los grupos, desarrollo de software de base y aplicacin, sistemas
de comunicacin de datos y automatizacin de oficinas.

46

Para dimensionar la instalacin ser necesario conocer los volmenes por tipo de operacin, tamao de
los archivos, nivel de actividad sobre los mismos, cantidad de caracteres por tipo de documento a procesar,
crecimiento anual del volumen de operaciones y archivos, y tipo de procesamiento para cada aplicacin, de
forma tal, que se pueda definir la capacidad y forma de almacenamiento de los datos.
Disponer de esta informacin supone el conocimiento de los sistemas de informacin cuyas funciones
computarizadas sern procesadas en el nuevo equipo, y si bien la estrategia de Software puede definir criterios
para la asignacin de prioridades en el desarrollo de sistemas, y aun las modalidades de procesamiento;
difcilmente pueda dilucidar los inconvenientes que presenta el dimensionamiento de la instalacin. Por lo tanto,
ser necesario efectuar un relevamiento que permita acopiar la informacin sealada anteriormente. Al efecto,
se debern relevar, entre otras, las siguientes actividades y funciones de negocio:
Produccin:
Caractersticas de la lnea de produccin
Planeamiento (Planes de produccin, abastecimiento, etc.)
Programacin de la produccin
Gestin y administracin de stocks
Control de inventarios
Materias primas
Produccin en proceso
Repuestos y materiales
Costos industriales
Anlisis de consumo
Mano de obra
Control de calidad
Ingeniera industrial (Mtodos, tiempos y control de eficiencia)
Administracin de produccin
Mantenimiento de planta (Plan de mantenimiento, costeo de ordenes de trabajo, etc.)
Desarrollo de nuevos productos (Prototipos y especificaciones)
Requerimientos contables para produccin

47

Gestin de compras:
Emisin de requisiciones
Plan de Compras
Activamiento
Control de Recepciones
Circuito compras-proveedores
Comercializacin:
Canales de distribucin
Pedidos-facturacin
Plan de ventas
Investigacin de mercado
Marcas y nuevos productos
Administracin:
Contabilidad general
Proveedores
Deudores-facturacin
Caja-bancos
Proyeccin de pagos y cobranzas
Planificacin financiera
Bienes de uso (Activo Fijo)
Crditos y cobranzas
Costos
Presupuestos
Planes econmicos
Control de gestin
Impuestos y seguros

48

Administracin de personal:
Inventario de personal
Anlisis de desempeo
Empleos
Capacitacin
Remuneraciones
Accidentes
Liquidacin de sueldos
Si bien se han detallado las actividades principales a considerar en una industria, el alcance del
relevamiento en cada caso depender del tipo de Negocio de cada Empresa y de sus caractersticas
principales, segn se trate de entidades financieras, empresas de servicios, etc., y estas a su vez sean,
estatales o privadas, nacionales o extranjeras, etc.
El anlisis de la informacin obtenida en el relevamiento permitir establecer las necesidades en
materia de informacin tanto operativas, administrativas y de gestin; como as tambin respecto de la toma de
decisiones. En cada caso se debern considerar: volmenes, confidencialidad, frecuencia, complejidad para su
obtencin, integridad, redundancia, seguridad, oportunidad, control interno y los factores particulares inherentes
a la Empresa. Sobre la base de los resultados del relevamiento y la estrategia de sistemas se deber:
Efectuar una revisin de la estrategia de sistemas a efectos de detectar posibles incongruencias en las
definiciones previas, respecto a los resultados que arroja el relevamiento.
Establecer una hiptesis sobre los sistemas de informacin cuyo caudal de procesamiento deber ser
absorbido por la nueva instalacin.
Analizar la modalidad de procesamiento global, estableciendo porcentajes para cada tipo de proceso.
Establecer requerimientos especiales de hardware y software (Dispositivos especiales).
Analizar requerimientos de tcnicas especiales de procesamiento de datos a emplear para el corto y
mediano plazo
Dimensionamiento de la instalacin:
En primer lugar se proceder a calcular la capacidad por tipo de dispositivo y a establecer el perfil
tcnico de los perifricos en funcin de los sistemas que sern procesados por la futura instalacin, como ser:

49

Unidad central de proceso:
Tamao y organizacin de la memoria
Velocidad de transferencia
Capacidad de la unidad de control
Niveles de interrupcin
Discos:
Tiempo medio de acceso
Capacidad
Fijos o removibles
CDs y reproductoras de CDs
Cintas:
Densidad
Velocidad
Pistas
Terminales de vdeo:
Inteligentes o no inteligentes
Funciones avanzadas de hardware
Tamao de la pantalla o buffer
Velocidad de transferencia
Impresoras:
Chorro de tinta o lser
Tamao
Velocidad

50

Software:
Multiprogramacin
Despacho de tareas
Seguridad en el manejo de datos
Edicin interactiva
Procesamiento en lotes de programas de aplicacin
Medios para manejos de formatos
Servicios de tipo general
Si el anlisis incluye la utilizacin de tcnicas de procesamiento como el teleproceso, se deber evaluar
por un lado los nodos (Componentes de hardware que pueden realizar procesamiento de la informacin y
control de la red) y por otro los enlaces (Medios que emplean para transmitir informacin entre los nodos). En
relacin con los nodos, adems de los dispositivos sealados anteriormente se deber evaluar:
Controlador de comunicaciones:
Programable
Requerimientos para conexin de lneas
Serializacin para transmisin asincrnica, serie o paralelo
Posibilidad de almacenar y retransmitir
Manejo de prioridades
Deteccin y correccin de errores
Manejo de tiempo agotado
Manejo de respuestas o llamadas en forma automtica
Modems:
Facilidad de acoplamiento acstico
Cantidad de hilos
Ecualizacin automtica
Velocidad
Indicadores de estado
Facilidades para manejo de ms de un modo de transmisin
En relacin con los enlaces se deber definir el tipo de enlace y la modalidad y velocidad de transmisin
que el mismo deber soportar.

51

En cuanto al software de comunicaciones se deber evaluar por un lado la utilizacin de una
arquitectura de teleprocesamiento y una disciplina de control de lneas, y por otro disponer de un monitor de
teleprocesamiento con las funciones bsicas.
Automatizacin de oficinas:
Procesamiento de textos
Correo electrnico
Distribucin de computadoras personales conectadas a la instalacin central
Software para modelizacin
Desarrollo de actividades
Diseo de la configuracin:
Una vez definidos los parmetros de capacidad y perfil tcnico de los componentes se proceder a su
cuantificacin; fundamentalmente de los dispositivos perifricos. Para definir la cantidad de terminales de vdeo
se debern considerar variables como: horas pico, colas de espera, tiempo para reingreso de datos por errores
de digitacin, aspectos funcionales como adyacencia fsica de ciertos usuarios, terminales especializadas
segn su uso (Para programacin, sistemas con altos tiempos de uso, etc.)
Una vez cuantificados los dispositivos de la instalacin se analizar la flexibilidad para el crecimiento
futuro de la instalacin y la dotacin requerida para su funcionamiento. A partir de este anlisis se establecern
los ajustes finales y se disear la configuracin
Evaluacin de los equipos ofrecidos en el mercado:
Cada compaa proveedora de equipos de computacin suele confeccionar sus propuestas a partir de
sus pautas de comercializacin y generalmente describen con mayor amplitud los aspectos favorables de su
producto en relacin con la competencia, y no se profundiza (y en algunos casos no se hace mencin) sobre los
elementos que estn en desventaja frente a otros proveedores. Por tal motivo, se suelen presentar dificultades
en el momento de la seleccin de propuestas. Para evitar estos inconvenientes se deber confeccionar un
informe para las compaas proveedoras que contenga las variables a fin de estandarizar las propuestas sobre
las cuales se efectuar la seleccin.

52

En dicho informe se deber requerir la cotizacin de:
Configuracin a cotizar
Apertura del costo por dispositivo
Cargos por importacin
Cargos por instalacin
Modalidades de contratacin
Forma de pago
Plazos de entrega
Recargos o impuestos
Servicio tcnico (Caractersticas y costo)
Asesoramiento y apoyo
Equipo de backup
Horas de mquina para desarrollo (Cantidad, lugar y costo)
Posibilidades de ampliacin
Lista de usuarios con equipos instalados similares al cotizado
Una vez recibidas las propuestas se debern fijar los criterios para seleccionar las mismas con el objeto
de seleccionar una terna
Resumir el resultado del anlisis de factibilidad tcnica:
Es esta fase se proceder a confeccionar el informe con los resultados del anlisis de factibilidad
tcnica que contendr los fundamentos tcnicos de las decisiones adoptadas y resumir los resultados de la
etapa. Dependiendo de las caractersticas del proyecto y de la modalidad con que la Empresa encar el mismo,
los aspectos organizacionales pueden haber sido evaluados al definirse la estrategia de sistemas, en cuyo
caso, no se requerir la ejecucin de esta fase. En caso contrario, se deber efectuar el estudio
correspondiente que tiene por objeto evaluar el impacto del proyecto sobre la organizacin.
Factibilidad Econmica: Los distintos tipos de factibilidad pueden entrar en conflicto. Para resolverlo conviene
reunir a las partes (usuarios finales, gerencia, etc.) y decidir en conjunto la solucin ms conveniente.

53

Aspectos a considerar:
Cuantificacin de la inversin:
Para efectuar el anlisis de Factibilidad econmico-financiera resulta imprescindible conocer la totalidad
de los gastos en que incurrir la Empresa para incorporar el nuevo sistema, como as tambin el incremento de
los costos por cargas de estructura que demandar su funcionamiento posterior de la puesta en marcha. Dado
que los costos de hardware y software se incluyen en el estudio tcnico, ser necesario conocer los siguientes
costos complementarios:
Dotacin: Con el detalle de los sueldos ms las cargas sociales, para la totalidad de puestos y vacantes.
Mobiliario: Con el detalle de los elementos y el costo unitario de los mismos. Se deber especificar los
muebles de oficina (Escritorios, sillas, etc. ), y los de computacin (archivos, mesas para terminales, etc. )
Instalacin elctrica:
Tablero de comando
Regulador de tensin
Ramal trifsico
Puesta a tierra (J abalinas de cobre)
Alimentacin de grupos de computacin (Con seguridad antillama u otros)
Suministros:
Formularios
Cartuchos de tinta para impresoras (Color y Negro)
Toner para impresoras lser
Disquetes
CDs
Etc.
Layout:
Planos
Modificacin de artefactos de iluminacin, mamparas, etc.

54

Sistema de seguridad:
Caja centrifugada
Sistema contra incendios (Con detectores de humo)
Servicios de microfilmacin para documentacin
Etc.
Cursos de capacitacin:
Detalle y costo
Seguro:
Detalle de cobertura y costo
Fletes:
Detalle y costo
Para establecer estos costos se deber consultar a tres proveedores como mnimo y en cada caso
se deber conocer:
Tiempo de vigencia de los presupuestos
Formas de pago
Fecha de iniciacin estimada de los trabajos
Tiempo de ejecucin de las tareas
Plazos de entrega
Etc.
A estos costos se debern agregar los que tiene el estudio tcnico:
Costo de Hardware
Costo de Software
Cargos por importacin
Cargos por instalacin
Recargos e impuestos
Servicio Tcnico
Garanta para la modalidad de alquiler
Cargos por backup de instalacin

55

Con todos estos datos se proceder a cuantificar la inversin y evaluar la modalidad de contratacin
ms ventajosa.
Anlisis comparativo:
En primer lugar se establecer el monto de inversin inicial, que incluye gastos por nica vez, y luego,
el cargo mensual del nuevo centro de costos. A efecto de medir la incidencia del cargo mensual, de deber
tomar un ndice que permita visualizar el grado de participacin en el cargo total de la compaa, como por
ejemplo las ventas o cualquier otro ndice que permita visualizar el grado de participacin en el cargo total de la
compaa, como por ejemplo las ventas o cualquier otro que utilice la Empresa para efectuar estas mediciones.
Finalmente se deber:
Efectuar una revisin de la evaluacin de costos
Analizar la inversin frente a la posicin financiera de la Empresa
Establecer los beneficios totales (Incluyendo los intangibles)
Analizar el retorno de la inversin (VAN Valor actualizado Neto, TIR Tasa Interna de Retorno)
Medir en trminos de producto la inversin total
Resumir los resultados del estudio econmico-financiero:
Se deber confeccionar un informe que resuma el estudio de Factibilidad econmico-financiero. Por
ltimo, se confeccionar el informe final para la alta direccin, con el resumen del anlisis de Factibilidad del
Proyecto de inversin en Informtica.
El mismo deber contener:
Introduccin
Antecedentes y necesidades
Estrategia
Resultados del estudio tcnico
Resultados del estudio operativo
Resultados del estudio econmico-financiero
Sugerencia del equipo de proyecto
Anexo con las propuestas recibidas y los cuadros comparativos

56

3.3 El Papel del Analista de Sistemas
Los analistas de sistemas generalmente valoran la manera en que funcionan los negocios examinando
la entrada, el procesamiento de datos y la salida de informacin con el propsito de mejorar los procesos
organizacionales.
Muchas mejoras involucran mejor apoyo para las funciones de los negocios por medio del uso de
sistemas de informacin computarizados. Esta definicin enfatiza un enfoque sistemtico y metdico para
analizar, y posiblemente mejorar, lo que esta sucediendo en el contexto especfico creado por un negocio.
El analista de sistemas debe ser capaz de trabajar con gentes de todas las descripciones y debe tener
experiencia en el trabajo con computadoras. El analista desempea muchos papeles, balanceando a veces
varios al mismo tiempo. Los tres papeles del analista de sistemas son: consultor, experto de soporte y agente
de cambio.
El Analista de Sistemas como Experto de Soporte: En este papel el analista se apoya de su experiencia
profesional relacionado con el hardware y software de computadora y su uso en el negocio. Este trabajo no es
proyecto de sistema completo, si no solamente pequeas modificaciones o decisiones que afectan a un solo
departamento.
El Analista de Sistemas como Agente de Cambio: Como analista es un agente de cambio cada vez que se
ejecuta cualquiera de las actividades del ciclo de vida del desarrollo del sistema y esta presente en el negocio
por un periodo extendido. Un agente de cambio puede ser definido como una persona que sirve de catalizador
para el cambio, desarrolla un plan para el cambio y trabaja junto con otros para facilitar ese cambio.
Cualidades del Analista de Sistemas:
A partir de la descripcin anterior en los papeles que desempea el analista de sistemas, es fcil ver
que el analista de sistemas exitoso debe poseer un alto rango de cualidades. Muchos tipos de gentes diferentes
son analistas de sistemas, por lo que cualquier descripcin quedar corta en alguna forma. Sin embargo, hay
algunas cualidades que parecen mostrar la mayora de los analistas de sistemas:
Antes que nada, el analista es un solucionador de problemas, es una persona que ve el anlisis de los
problemas como un reto y que disfruta el encontrar soluciones funcionales, cuando es necesario, el analista
debe de ser capaz de atacar sistemticamente la situacin a la mano por medio de la aplicacin hbil de
herramientas, tcnicas y experiencia.

57

El analista tambin debe ser comunicador capaz de relacionarse en forma significativa con las dems
gentes a travs de periodos extensos, los analistas de sistemas necesitan la suficiente experiencia en
computacin para programar, para comprender las capacidades de las computadoras, para recoger los
requerimientos de informacin de los usuarios y para comunicar lo que se necesita a los programadores.
El analista de sistemas debe ser un individuo autodisciplinado y automotivado, capaz de manejar y
coordinar innumerables recursos, incluyendo a otras gentes, el analista de sistemas es una carrera que
demanda mucho, pero en compensacin es siempre cambiante y siempre retadora.
Trabajo del analista de sistemas:
El trabajo del analista de sistemas, bsicamente se puede dividir en tres pasos:
Anlisis de Sistemas: Consiste en conducir estudios relevantes de hechos relacionados con la
actividad de la empresa. Su funcin es reunir informacin y determinar los requerimientos.
Anlisis y Diseo de Sistemas: Adems de la actividad anterior, tiene la responsabilidad de disear
un sistema.
Anlisis, Diseo y Programacin: Conduce a la investigacin de sistemas, desarrolla las
especificaciones de diseo y escribe el software para implantar el diseo. 5
3.2 Herramientas para el Anlisis y Diseo
Una herramienta es cualquier dispositivo que, cuando se emplea en forma adecuada, mejora el desempeo
de una tarea. En general las herramientas se agrupan en las siguientes categoras:

Anlisis
Diseo
Desarrollo

5 KENDALL & KENDALL, Anlisis y diseo de sistemas 3 ed., Mxico, Pretince Hall ,1997 Pag 5,6,7,8

58

Herramientas para anlisis: Estas herramientas ayudan a los especialistas en sistemas a documentar un
sistema existente, y a determinar los requerimientos de una nueva aplicacin, estas herramientas incluyen:

Herramientas para la Recoleccin de Datos: Capturan detalles que describen sistemas y
procedimientos en uso, documentan procesos y actividades de decisin.
Herramientas para Diagramacin: Crean representaciones graficas de sistemas y actividades, apoyan
el dibujo y revisin de diagramas de flujo de datos e iconos asociados con el anlisis estructurado.
Herramientas para el Diccionario: Registran y mantienen las descripciones de los elementos del
sistema, tales como grupos de datos, procesos y almacenamiento de datos.

Herramientas para el diseo: Las herramientas de diseo apoyan el proceso de formular las caractersticas
que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades de anlisis:

Herramientas de especificacin: Apoyan el proceso de formular las caractersticas que el sistema
debe tener una aplicacin, tales como entradas, salidas, procesamiento y especificaciones de control.
Herramientas para presentacin: Se utilizan para describir la posicin de datos, mensajes y
encabezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida.

Herramientas para el Desarrollo: Estas herramientas ayudan al analista a trasladar los diseos en
aplicaciones funcionales:

Herramientas para ingeniera de software: Apoyan el proceso de formular diseos de software,
incluyendo procedimientos y controles, as como la documentacin correspondiente.
Generadores de cdigo: Producen el cdigo fuente y las aplicaciones a partir de especificaciones
funcionales bien articuladas.
Herramientas para prueba: Incluye facilidades para examinar la correcta operacin del sistema as
como el grado de perfeccin alcanzado en comparacin con las expectativas. 6
En los ltimos aos los analistas han comenzado a beneficiarse de nuevas herramientas de
productividad que han sido creadas implcitamente para mejorar su trabajo rutinario mediante un apoyo
automatizado. A esta se le llama Herramientas CASE, que significa herramientas para ingeniera de software
asistido por computadora.

6 A. SENN J ames, Anlisis y diseo de sistemas de informacin, 2 ed., Mxico, Mc Graw Hill, 1994, Pag. 47,48,49

59

En informtica, acrnimo de Computer Aided Software Engineering, que define el uso de computadoras
para el desarrollo de software en todo su ciclo de vida. Es un entorno de trabajo asistido por computadora que
ayuda tanto a jefes de proyecto como a analistas y programadores en el diseo e implementacin de todo tipo
de software. Los analistas se apoyan en las herramientas Case para aumentar la productividad, comunicarse
mas efectivamente con los usuarios e integrar el trabajo que realizan en el sistema, desde el principio hasta el
fin del ciclo de vida.
El mtodo CASE, plantea una secuencia de etapas pero mas detallada, y adems proporciona para
cada etapa su descripcin, definicin de objetivos y metas, productos de la etapa, factores crticos de xito, y la
lista de tareas que conviene realizar. Adems es posible auxiliarse de herramientas CASE que facilitan
grandemente la puesta en practica del mtodo. Esta tecnologa ha sido utilizada para el diseo de diversos
sistemas que se han desarrollado. 7

7 KENDALL & KENDALL, Anlisis y diseo de sistemas, 3 ed., Mxico, Pretince Hall 1997 , Pag. 13

60

IV. CICLO DE DESARROLLO DEL SISTEMA

Es el conjunto de actividades de los analistas, diseadores y usuarios que necesitan llevarse a cabo
para desarrollar y poner en marcha un sistema de informacin. El ciclo de desarrollo de los sistemas o ciclo de
vida de los sistemas (SDLC: Systems Devetopment Life Cycle) es un enfoque por etapas de anlisis y de
diseo, que postula que el desarrollo de los sistemas mejora cuando existe un ciclo especfico de actividades
del analista y de los usuarios. Se realizan al mismo tiempo diversas actividades, y stas llegan a repetirse. Por
ello es de mayor utilidad suponer que e! ciclo de desarrollo de los sistemas transcurre en etapas (con
actividades en accin que luego cesan poco a poco) y no como elementos separados. Cuando la gerencia, o en
algunas ocasiones el personal de desarrollo sistemas, se da cuenta de que cierto sistema del negocio necesita
mejorarse, llevando a cabo las siguientes etapas:
Nacimiento: Esta fase da inicio al ciclo de vida con el surgimiento de una necesidad o de un requerimiento por
parte del usuario. En este momento debe hacerse un estudio de factibilidad para decidir si en realidad se
justifica el desarrollo del sistema.
Desarrollo: Una vez realizado un estudio de factibilidad, se procede al desarrollo del sistema en el cual se
analizan los requerimientos y se elabora un diseo que servir de base para el desarrollo. Adems, se elaboran
los programas necesarios para que el sistema pueda operar. La fase de desarrollo consiste en disear,
construir y/o adecuar los programas que se requieren para resolver el problema del usuario.
Operacin: En este momento el sistema ya est terminado y el usuario trabaja introduciendo datos y
obteniendo informacin y reportes que soporten la operacin de la empresa. Si el sistema no satisface los
requerimientos funcionales del usuario o si se detecta algn error en los programas, es necesario pasar a la
fase de mantenimiento.
Mantenimiento: Consiste en corregir los errores que se detectan en los programas o en las funciones que
realiza el sistema. En esta fase adems el usuario puede agregar nuevos requerimientos.
Muerte: Un sistema de informacin llega a esta fase cuando deja de ser necesario o cuando debe
reemplazarse por otro mejor. Si al sistema original se le hacen mejoras o cambios se inicia nuevamente el
proceso, debido a que el sistema anterior ya ha muerto y se desarrollar uno nuevo.
En general, los analistas no estn de acuerdo respecto al nmero exacto de etapas que conforman el
ciclo de desarrollo de los sistemas; sin embargo, se reconoce la importancia de su enfoque sistemtico. Se
dividir el ciclo de vida en siete etapas, que aunque se presentan de manera discreta, nunca se llevan a cabo
como un elemento independiente.

61

El ciclo de vida del desarrollo de sistemas consiste en las siguientes actividades:
Investigacin preliminar.
Determinacin de requerimientos.
Desarrollo del sistema prototipo.
Diseo del sistema.
Desarrollo de software.
Prueba de los sistemas.
Puesta en marcha.
Investigacin Preliminar:
En ocasiones hemos pensado en que seria bueno solucionar las cosas de una mejor manera, (por
ejemplo, las largas filas para obtener el registro de algn curso o el pago de colegiaturas), que solucione
demoras o problemas, y ha pensado que eso sera ms rpido con un sistema de cmputo. Es entonces
cuando debe iniciar la primera actividad de sistemas, es decir, la investigacin preliminar, se inicie. Esta
actividad tiene tres partes: clarificacin del requerimiento, estudio de factibilidad y aprobacin del requerimiento.
El resultado ser aprobar el requerimiento para una atencin posterior por rechazarlo como no factible para un
desarrollo futuro.
Se inicia siempre con la peticin de una persona (administrador, empleado o especialista de
sistemas).Cuando se formula la solicitud comienza la primera actividad de sistemas: La investigacin preliminar,
tiene que ver con la identificacin de problemas, oportunidades y objetivos. Frecuentemente estos ya han sido
vistos por los usuarios y son la razn para la cual el analista fue llamado.
El aprovechar las oportunidades de mejora, puede permitir que el negocio gane un avance competitivo
o ponga un estndar en la industria. Las personas involucradas en la primera fase son los usuarios, analistas y
administradores de sistemas que coordinan el proyecto.
Las actividades de esta fase consisten en entrevistas a los administradores de los usuarios,
sumarizacin del conocimiento obtenido, estimacin del alcance del proyecto y documentacin de los
resultados. El objetivo final de esta fase es un estudio de factibilidad que contiene una definicin del problema y
la sumarizacin de los objetivos.

62

Conforme se renen los detalles, los analistas estudian los datos con la finalidad de identificar las
caractersticas que debe tener el nuevo sistema, incluyendo la informacin que deben producir los sistemas
junto con las caractersticas operacionales tales como controles de procesamiento, tiempos de respuesta y
mtodos de entrada y salida. El analista prepara una propuesta del sistema que sumariza los que ha sido
encontrado, proporciona anlisis de costo/beneficio de las alternativas y hace recomendaciones sobre lo que
debe ser hecho. Cada problema de sistemas es nico y nunca hay una sola solucin correcta.
Determinacin de requerimientos:

El aspecto fundamental del anlisis es comprender todas las facetas importantes de la parte de la
empresa que se encuentra bajo estudio. El analista debe formarse una imagen de la empresa y sus objetivos,
en esta fase el analista esta esforzndose por comprender que informacin necesitan los usuarios para realizar
su trabajo. Las personas involucradas son analistas y los usuarios. El analista debe saber los detalles de las
funciones del sistema.
Desarrollo del sistema prototipo:
En algunos casos, puede no ser posible decidir por anticipado todas las caractersticas del sistema. A
menudo se seleccionan como prototipo situaciones nicas, de las cuales las personas que desarrollan el
sistema no tienen ninguna informacin ni experiencia. Tambin se evalan situaciones de alto costo y alto
riesgo, en donde el diseo propuesto es nuevo y no haba sido probado a travs del prototipo.
Por ejemplo, la factibilidad de que los vendedores introduzcan pedidos al sistema de computadora de la
compaa desde el exterior, a travs de terminales porttiles que fcilmente se conectan a las lneas telefnicas
pblicas, es todava una alternativa no probada en muchas compaas. Los gerentes y operadores de sistemas
pueden escoger entre construir una versin a pequea escala del software, comprar una cantidad limitada de
terminales o tener un grupo selecto de vendedores que prueben el concepto introduciendo pedidos desde sus
diferentes lugares de ventas.
El prototipo proporcionar informacin preliminar en relacin a la factibilidad del concepto. Ellos pueden
encontrar, por ejemplo, que todos los vendedores tratarn de introducir sus pedidos a una hora del da cuando
la computadora no est disponible para recibirlas. Obsrvese que el prototipo es realmente un piloto o una
prueba. Se espera que el prototipo se modifique despus de varios intentos; esto es, el diseo evolucionar
conforme se vaya rindiendo informacin adicional del diseo a travs de su uso.

63

Si el uso del sistema prototipo de ventas revela que los nombres de los clientes que se introducen y sus
direcciones a travs de la terminal porttil provocan demasiados errores, los diseadores deben modificar el
sistema de manera que solamente sean necesarios los nombres de los clientes; las direcciones se deben
consultar en forma automtica en los archivos almacenados del sistema. El prototipo es un sistema de trabajo
diseado para que se pueda modificar con facilidad. La informacin que se obtiene a travs de su uso se aplica
a un diseo modificado.
La versin modificada puede utilizarse, a su vez, como el prototipo para obtener an ms informacin
valiosa del diseo. El proceso se repite tantas veces como sea necesario para revelar los requerimientos
esenciales del diseo. El desarrollo del prototipo a menudo coincide con el diseo de sistemas.
Diseo del sistema.

El Diseo de un sistema de informacin produce los detalles que establecen la forma en que el sistema
cumplir con los requerimientos identificados durante la fase de anlisis. El analista usa la informacin
recolectada anteriormente para realizar un diseo lgico. Los analistas de sistemas comienzan el proceso de
diseo identificado, los reportes y dems salidas que debe producir el sistema, hecho lo anterior se determina
con toda precisin los datos especficos para cada reporte y salida.

El diseo de un sistema tambin indica los datos de entrada, aquellos que sern calculados y los que
deben ser almacenados en la base de datos que servir a los administradores en la toma de decisiones. As
mismo, se escriben con todo detalle los procedimientos de calculo y los datos individuales. Los diseadores son
los responsables de dar a los programadores las especificaciones de software completas y claramente
delineadas.
Desarrollo de Software:
Los encargados de desarrollar software pueden instalar paquetes comprados a terceros o escribir
programas diseados a la medida del solicitante. La eleccin depende del costo de cada alternativa, del tiempo
disponible para escribir el software y de la disponibilidad de los programadores.
Prueba de los sistemas
La prueba se lleva a cabo por personas diferentes a aquellas que los escriben en forma original; es
decir, si se utilizan personas que no conocen cmo se disearon ciertas partes de los programas, se asegura
una mayor y ms completa prueba, adems de ser imparcial, lo que da un software ms confiable.

64

Puesta en marcha
De acuerdo con el tamao de la empresa que emplear la aplicacin y el riesgo asociado con su uso,
los desarrolladores del sistema pueden escoger una prueba piloto para la operacin del sistema solamente en
un rea de la compaa.
A veces corrern en forma paralela tanto el sistema anterior como el nuevo para comparar los
resultados de ambos; en otras situaciones, los desarrolladores pararn por completo el sistema anterior un da y
al siguiente empezarn a utilizar el nuevo. Como se puede apreciar, cada estrategia para la puesta en marcha
tiene sus mritos, que dependen de la situacin del negocio considerado. Sin importar la estrategia para la
puesta en marcha que se haya utilizado, los desarrolladores tendrn que asegurarse que el uso inicial del
sistema est libre de problemas.
Una vez instalada, con frecuencia la aplicacin se utiliza por muchos aos; sin embargo, tanto la
empresa como los usuarios cambiarn, y el medio ambiente ser diferente tambin a travs del tiempo. Por lo
tanto, la aplicacin indudablemente necesitar mantenimiento; es decir, se harn cambios y modificaciones al
software, y a los archivos o procedimientos para cubrir los requerimientos nuevos de los usuarios. Los sistemas
de la empresa y el medio ambiente de los negocios estn en continuo cambio. Los sistemas de informacin
deben mantenerse de la misma forma; en este sentido, la puesta en marcha es un proceso continuo.
4.1 Seguimiento del Ciclo de Vida del Proyecto

Las fases del ciclo de vida se realizan a travs del proceso global de concepcin, desarrollo, implantacin y
utilizacin de las infraestructuras, las instalaciones o plantas industriales y los sistemas tcnicos que, como todo
profesional bien informado sabe esta conformado en tres fases fundamentales las cuales son:
La fase de elaboracin del plan maestro: (proyecto, de acuerdo con la singular nomenclatura
espaola) de las infraestructuras, las instalaciones o plantas industriales y los sistemas tcnicos que se
pretende implantar y utilizar.
La fase de ejecucin del plan maestro: De las infraestructuras, las instalaciones o plantas industriales
y los sistemas tcnicos planeados.
La fase de utilizacin y conservacin de las infraestructuras, las instalaciones o plantas industriales
y los sistemas tcnicos implantados.
En las entidades avanzadas, ya sean pblicas o privadas, la funcin de los ingenieros est
perfectamente determinada a lo largo del ciclo de vida sealado para las infraestructuras, las instalaciones o
plantas industriales y los sistemas tcnicos y, asimismo, la funcin de los dems grupos profesionales.

65

La fase de elaboracin del plan maestro: La elaboracin del plan maestro de las infraestructuras, las
instalaciones o plantas industriales y los sistemas tcnicos requiere la intervencin no solo ingenieros
colegiados, sino de muy diversos grupos profesionales, puesto que su contenido fundamental comprende:
El estudio y la estimacin de la demanda de bienes o servicios a satisfacer con la correspondiente
infraestructura, instalacin, planta industrial o sistema tcnico.
Los requerimientos operacionales y la solucin conceptual o enfoque tcnico para satisfacer la
demanda;
La localizacin y el anlisis del impacto medio ambiental de la infraestructura, la instalacin, la planta
industrial o el sistema tcnico.
El plazo o los plazos en que se deber disponer de la capacidad total o parcial para satisfacer la
demanda y,
Las fuentes financieras del plan maestro y la viabilidad econmica y/o financiera del plan maestro.
La funcin propia de los ingenieros durante la fase de elaboracin del plan maestro consisten
fundamentalmente en:
Traducir los trminos en que se explicita la demanda - cantidades y cualidades de los bienes o los
servicios demandados - en requerimientos operacionales y criterios tcnicos y, a partir de stos,
Decidir el enfoque tcnico y el diseo conceptual de la correspondiente, infraestructura, instalacin,
planta industrial o sistema tcnico, que mejor y mas eficazmente satisface la demanda.
Ahora bien, la sola funcin de los ingenieros durante la fase de elaboracin del plan maestro, sin la
intervencin de los profesionales de la direccin general, la direccin de marketing, la direccin financiera, etc.
de la entidad promotora no pasara de ser un mero ejercicio acadmico. An ms, cualquier plan maestro, sin la
intervencin de todo el elenco de profesionales citados y otros sin citar, no debera tener otro destino que su
insercin en cualquier revista de divulgacin profesional y, en ltimo caso, la papelera, si alguien insiste en
darle valor como documento de planificacin.

66

La fase de ejecucin del plan maestro: Durante la fase de ejecucin del plan maestro, normalmente dividida
en cuatro subfases - definicin; realizacin; integracin operativa, pruebas y puesta en uso; y verificacin de
garantas tcnicas y aceptacin definitiva, los ingenieros realizan lo que se ha venido denominando la ingeniera
(preliminar y final) del sistema tcnico, la infraestructura, la instalacin o la planta industrial. La ingeniera
preliminar, que se efecta durante la subfase de definicin, consiste en lneas generales en lo siguiente:
El anlisis y la atribucin de los requerimientos.
La elaboracin del diseo preliminar o bsico.
Las revisiones iniciales del diseo.
Los estudios de apoyo logstico integrado.
Los anlisis de fiabilidad/mantenibilidad/disponibilidad.
El establecimiento de la filosofa de control y automatizacin.
Los anlisis de ergonoma.
Los anlisis preliminares de seguridad.
Los anlisis de compatibilidad e integridad fsica.
El anlisis de la proteccin fsica del sistema.
La seleccin de cdigos, reglamentos y normas.
La definicin y la especificacin de las unidades funcionales principales del sistema.
La evaluacin tcnica de Alternativas propuestas por los licitantes para el diseo, desarrollo, produccin
y entrega las unidades funcionales principales del sistema.
El estudio del coste del ciclo de vida del sistema.
La elaboracin del plan de garanta de calidad.
La modelizacin de la infraestructura, la instalacin, la planta industrial o el sistema tcnico para su
simulacin dinmica. La construccin de maquetas de la infraestructura, la instalacin, la planta industrial o el
sistema tcnico.

67

Los estudios tcnicos y los anlisis para la optimizacin de la infraestructura, la instalacin, la planta
industrial o el sistema tcnico. El plan bsico de ensayos y evaluacin de la infraestructura, la instalacin, la
planta industrial o el sistema tcnico. La ingeniera final, que se efecta durante la fase de realizacin y la fase
de integracin operativa, consiste en lneas generales en lo siguiente:
La coordinacin y el control del programa tcnico global.
El seguimiento y control del diseo de los componentes efectuado por los contratistas.
La integracin de los componentes y el desarrollo del diseo final.
La conduccin del programa de garanta de calidad.
El anlisis y la aprobacin de la documentacin tcnica entregada por los contratistas.
Los anlisis finales de seguridad de la infraestructura, la instalacin, la planta industrial o el sistema
tcnico
La auditoria fsica y la auditoria funcional de los suministros y las obras o instalaciones de los
contratistas.
La presensacin (witnessing) de las pruebas funcionales, de integracin y de aceptacin de la
infraestructura, la instalacin, la planta industrial o el sistema tcnico.
La elaboracin de la documentacin tcnica de la infraestructura, la instalacin, la planta industrial o el
sistema tcnico.
La elaboracin de la documentacin de obra acabada (as built) de la infraestructura, la instalacin, la
planta industrial o el sistema tcnico.
La emisin de la certificacin de aceptacin tcnica de la infraestructura, la instalacin, la planta
industrial o el sistema tcnico.
La fase de utilizacin y conservacin: Durante la fase de utilizacin y conservacin la funcin de los
ingenieros es de naturaleza residual y consiste bsicamente en hacer seguimiento de las prestaciones y
caractersticas tcnicas del sistema tcnico, la infraestructura, la instalacin o la planta industrial, proponer y
disear modificaciones para paliar su paulatina degradacin u obsolescencia y, en su caso, verificar su
realizacin.
En un proyecto de software participan muchos implicados con intereses opuestos, incluyendo a los
jefes, desarrolladores, usuarios finales, clientes y personas de mantenimiento. Theory-W proporciona un
entorno de trabajo para la gestin de proyectos orientado a la reconciliacin de intereses opuestos. Se basa en
la realizacin de un esfuerzo explicito para comprender lo que necesitan para tener xito las diferentes partes
implicadas, negociar conflictos entre las condiciones de xito de los implicados y estructurar el proyecto de
forma que todos alcancen sus condiciones de xito.

68

Theory-W reduce la planificacin mejorando la eficiencia en las relaciones laborales, mejorando la
visibilidad del progreso y reduciendo el riesgo. Theory-W toma su nombre de su principio mas importante: make
everyone a winner (hacer que todos ganen).
Caractersticas:
Diseado para el uso combinado con el modelo de ciclo de vida en espiral.
Particularmente efectivo durante las negociaciones de planificacin.
Se basa en el uso del mtodo de negociacin conveniente.
La gestin Theory-W de proyectos de software defiende que hacer que todos los implicados salgan
ganando en un proceso de software es una condicin suficiente y necesaria para que un proyecto de software
se ejecute con xito. Los proyectos donde todos pierden o algunos ganan pero otro no tendr xito. La gestin
Theory-W apoya el desarrollo rpido de aplicaciones, ya que mira a todas las partes implicadas de la misma
manera, de esta manera todas las partes implicadas tendrn la misma importancia y trascendencia para el
proyecto.
Es importante mencionar que los conflictos entre las partes que participan en un proyecto son la base
de la mayora de los problemas de gestin de los proyectos de software, y afectan la posibilidad de establecer
los objetivos, definir fechas de entrega, dar prioridad a las tareas y adaptarse a los cambios. Especficamente la
gestin Theory-W soporta el desarrollo rpido en los siguientes aspectos:
Objetivos ms claros del proyecto: Un proyecto Theory-W comienza identificando los puntos de xito de
cada uno de los implicados. La negociacin que da lugar al comienzo del proyecto refuerza y documenta los
objetivos del proyecto. Establecer los objetivos de forma clara es la clave mas importante para motivar a los
desarrolladores y la motivacin de los diseadotes es probablemente la clave mas importante para el desarrollo
rpido.
Mejores relaciones con el cliente: Es difcil mantener buenas relaciones cuando una de las partes (cliente-
desarrollador) esta perdiendo. Los proyectos Theory-W mejoran las relaciones entre los desarrolladores y los
clientes. Existen varios puntos en los que se puede aumentar la velocidad del desarrollo y que se deben a las
relaciones con el cliente.
Mejora de la eficiencia, debido a una mejor comunicacin y compresin del cliente con respecto a la
funcin que desempea en el proyecto.
Disminucin de trabajo repetido, gracias a que se realiza de mejor forma la tarea de analizar los
requerimientos.
Establecer pronto los objetivos produce unas expectativas de la planificacin realistas.

69

Reduccin del riesgo relacionado con el cliente: Hay muchos riesgos originados por parte del cliente en una
relacin de desarrollo, establecer una relacin Theory-W con el cliente ayuda a eliminar minimizar o eliminar
esos riesgos, ayuda a gestionar los riesgos que quedan, ya que tiene a la vista los riesgos relacionados con el
cliente.
Utilizacin de la gestin Theory-W: Cuando se utiliza el mtodo de gestin Theory-W, se renen todas las
partes implicadas y se obtiene as, cada una de las condiciones de xito de las partes implicadas a nivel de
proyecto. En el resto del proyecto, la gestin consiste en controlar el proyecto para asegurar que cada uno de
los implicados continu ganado. Si alguno de los implicados comienza a perder, se ajusta el proyecto segn
corresponda.
Hacer que todos ganen: A continuacin se muestra un esquema de un proceso general que se puede utilizar
para establecer una situacin de ganancia a partir de ser positivos, partiendo de:
Separar a las personas del problema.
Centrarse en los intereses en lugar de la posiciones.
Crear opciones para el beneficio mutuo.
Insistir en el uso de criterios objetivos.
Pasos en la gestin de proyectos Theory-W:
Paso 1: Establecer las precondiciones donde todos ganen: En este caso precondiciones se refiera a
criterios de entrada, si no se puede imaginar como hacer que todos ganen, no comience siquiera el proyecto,
adems es necesario que comprenda la forma en que las personas desean ganar, establecer expectativas
razonables por parte de todos los implicados, hacer corresponder las tareas de las personas con sus
condiciones de xito, y establecer un entorno de apoyo.
Antes de intentar entender la forma en que los implicados desean ganar, es importante identificar cada
una de los implicados claves. Es importante ponerse en el lugar de todos los implicados para saber que es lo
que cada uno de ellos necesita para obtener el xito. De todos los implicados probablemente el mas difcil de
entender es el de el cliente (regularmente es el menos representado), hay que trabajar mucho y armarse de
paciencia para comprender las situaciones de xito para el cliente.

70

Las etapas del ciclo de vida de una aplicacin de bases de datos son las siguientes:
1. Planificacin del proyecto.
2. Definicin del sistema.
3. Recoleccin y anlisis de los requisitos.
4. Diseo de la base de datos.
5. Seleccin del SGBD.
6. Diseo de la aplicacin.
7. Prototipado.
8. Implementacin.
9. Conversin y carga de datos.
10. Prueba.
11. Mantenimiento.
Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas varias
veces, haciendo lo que se conocen como ciclos de realimentacin. Por ejemplo, los problemas que se
encuentran en la etapa del diseo de la base de datos pueden requerir una recoleccin de requisitos adicional y
su posterior anlisis. A continuacin, se muestran las tareas ms importantes que se realizan en cada etapa:

1. Planificacin del proyecto: Esta etapa conlleva la planificacin de cmo se pueden llevar a cabo las etapas
del ciclo de vida de la manera ms eficiente. Hay tres componentes principales: el trabajo que se ha de realizar,
los recursos para llevarlo a cabo y el dinero para pagar por todo ello.
Como apoyo a esta etapa, se necesitar un modelo de datos corporativo en donde se muestren las
entidades principales de la empresa y sus relaciones, y en donde se identifiquen las principales reas
funcionales. Normalmente, este modelo de datos se representa mediante un diagrama entidad-relacin.
En este modelo se tiene que mostrar tambin qu datos comparten las distintas reas funcionales de la
empresa. La planificacin de la base de datos tambin incluye el desarrollo de estndares que especifiquen
cmo realizar la recoleccin de datos, cmo especificar su formato, qu documentacin ser necesaria y cmo
se va a llevar a cabo el diseo y la implementacin.
El desarrollo y el mantenimiento de los estndares puede llevar bastante tiempo, pero si estn bien
diseados, son una base para el personal informtico en formacin y para medir la calidad, adems, garantizan
que el trabajo se ajusta a unos patrones, independientemente de las habilidades y la experiencia del diseador.
Por ejemplo, se pueden establecer reglas sobre cmo dar nombres a los datos, lo que evitar redundancias e
inconsistencias. Se deben documentar todos los aspectos legales sobre los datos y los establecidos por la
empresa como, por ejemplo, qu datos deben tratarse de modo confidencial.

71

2. Definicin del sistema: En esta etapa se especifica el mbito y los lmites de la aplicacin de bases de
datos, as como con qu otros sistemas interactan. Tambin hay que determinar quienes son los usuarios y las
reas de aplicacin.

3. Recoleccin y Anlisis de los Requisitos: En esta etapa se recogen y analizan los requerimientos de los
usuarios y de las reas de aplicacin. Esta informacin se puede recoger de varias formas:
Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en
las reas de inters.
Observando el funcionamiento de la empresa.
Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar informacin.
Utilizando cuestionarios para recoger informacin de grandes grupos de usuarios.
Utilizando la experiencia adquirida en el diseo de sistemas similares.
La informacin recogida debe incluir las principales reas de aplicacin y los grupos de usuarios, la
documentacin utilizada o generada por estas reas de aplicacin o grupos de usuarios, las transacciones
requeridas por cada rea de aplicacin o grupo de usuarios y una lista priorizada de los requerimientos de cada
rea de aplicacin o grupo de usuarios.
Esta etapa tiene como resultado un conjunto de documentos con las especificaciones de requisitos de
los usuarios, en donde se describen las operaciones que se realizan en la empresa desde distintos puntos de
vista. La informacin recogida se debe estructurar utilizando tcnicas de especificacin de requisitos, como por
ejemplo tcnicas de anlisis y diseo estructurado y diagramas de flujo de datos. Tambin las herramientas
CASE ( Computer-Aided Software Engineering) pueden proporcionar una asistencia automatizada que
garantice que los requisitos son completos y consistentes.
4. Diseo de la base de datos: Esta etapa consta de tres fases: diseo conceptual, diseo lgico y diseo
fsico de la base de datos. La primera fase consiste en la produccin de un esquema conceptual, que es
independiente de todas las consideraciones fsicas. Este modelo se refina despus en un esquema lgico
eliminando las construcciones que no se pueden representar en el modelo de base de datos escogido
(relacional, orientado a objetos, etc.).

En la tercera fase, el esquema lgico se traduce en un esquema fsico para el SGBD escogido. La fase
de diseo fsico considera las estructuras de almacenamiento y los mtodos de acceso necesarios para
proporcionar un acceso eficiente a la base de datos en memoria secundaria.

72

Los objetivos del diseo de la base de datos son:
Datos disponibles, para cuando el usuario desee usarlos.
Datos precisos y consistentes (deben poseer una integridad)
Almacenamiento eficiente de los datos as como su actualizacin
Que el acceso a la informacin tenga un propsito
Representar los datos que requieren las principales reas de aplicacin y los grupos de usuarios, y
representar las relaciones entre dichos datos.
Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar sobre los
datos.
Especificar un esquema que alcance las prestaciones requeridas para el sistema.
Hay varias estrategias a seguir para realizar el diseo: de abajo a arriba, de arriba a abajo, de dentro a
fuera y la estrategia mixta. La estrategia de abajo a arriba parte de todos los atributos y los va agrupando en
entidades y relaciones. Es apropiada cuando la base de datos es simple, con pocos atributos. La estrategia de
arriba a abajo es ms apropiada cuando se trata de bases de datos complejas.

Se comienza con un esquema con entidades de alto nivel, que se van refinando para obtener entidades
de bajo nivel, atributos y relaciones. La estrategia de dentro a fuera es similar a la estrategia de abajo a arriba,
pero difiere en que se parte de los conceptos principales y se va extendiendo el esquema para considerar
tambin otros conceptos, asociados con los que se han identificado en primer lugar.

La estrategia mixta utiliza ambas estrategias, de abajo a arriba y de arriba a abajo, con un esquema de
divide y vencers. Se obtiene un esquema inicial de alto nivel, se divide en partes, y de cada parte se obtiene
un subesquema. Estos subesquemas se integran despus para obtener el modelo final.

5. Seleccin del SGBD: Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger
un SGBD que sea adecuado para el sistema de informacin. Esta eleccin se debe hacer en cualquier
momento antes del diseo lgico.

6. Diseo de la Aplicacin: En esta etapa se disean los programas de aplicacin que usarn y procesarn la
base de datos. Esta etapa y el diseo de la base de datos, son paralelas. En la mayor parte de los casos no se
puede finalizar el diseo de las aplicaciones hasta que se ha terminado con el diseo de la base de datos. Por
otro lado, la base de datos existe para dar soporte a las aplicaciones, por lo que habr una realimentacin
desde el diseo de las aplicaciones al diseo de la base de datos.

73

En esta etapa hay que asegurarse de que toda la funcionalidad especificada en los requisitos de
usuario se encuentra en el diseo de la aplicacin. Habr algunos programas que utilicen y procesen los datos
de la base de datos. Adems, habr que disear las interfaces de usuario, aspecto muy importante que se
suele ignorar. El sistema debe ser fcil de aprender, fcil de usar, ser directo y estar ``dispuesto a perdonar''. Si
la interfase no tiene estas caractersticas, el sistema dar problemas, sin lugar a dudas.
7. Prototipado: Esta etapa, que es opcional, es para construir prototipos de la aplicacin que permitan a los
diseadores y a los usuarios probar el sistema. Un prototipo es un modelo de trabajo de las aplicaciones del
sistema. El prototipo no tiene toda la funcionalidad del sistema final, pero es suficiente para que los usuarios
puedan utilizar el sistema e identificar qu aspectos estn bien y cules no son adecuados, adems de poder
sugerir mejoras o la inclusin de nuevos elementos.
Este proceso permite que quienes disean e implementan el sistema sepan si han interpretado
correctamente los requisitos de los usuarios. Otra ventaja de los prototipos es que se construyen rpidamente,.
esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto riesgo o
utiliza nuevas tecnologas.
8. Implementacin: En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e
interno, as como los programas de aplicacin. La implementacin de la base de datos se realiza mediante las
sentencias del lenguaje de definicin de datos (LDD) del SGBD escogido. Estas sentencias se encargan de
crear el esquema de la base de datos, los ficheros en donde se almacenarn los datos y las vistas de los
usuarios.
Los programas de aplicacin se implementan utilizando lenguajes de tercera o cuarta generacin.
Partes de estas aplicaciones son transacciones sobre la base de datos, que se implementan mediante el
lenguaje de manejo de datos (LMD) del SGBD. Las sentencias de este lenguaje se pueden embeber en un
lenguaje de programacin anfitrin como Visual Basic, Delphi, C, C++. En esta etapa, tambin se implementan
los mens, los formularios para la introduccin de datos y los informes de visualizacin de datos.
Para ello, el SGBD puede disponer de lenguajes de cuarta generacin que permiten el desarrollo rpido
de aplicaciones mediante lenguajes de consultas no procedurales, generadores de informes, generadores de
formularios, generadores de grficos y generadores de aplicaciones.
Tambin se implementan en esta etapa todos los controles de seguridad e integridad. Algunos de estos
controles se pueden implementar mediante el LDD y otros puede que haya que implementarlos mediante
utilidades del SGBD o mediante programas de aplicacin.

74

9. Conversin y carga de datos: Esta etapa es necesaria cuando se est reemplazando un sistema antiguo
por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se
convierten al formato que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicacin
del sistema antiguo tambin se convierten para que se puedan utilizar en el sistema nuevo.

10. Prueba: En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para
ello, se debe disear una batera de tests con datos reales, que se deben llevar a cabo de manera metdica y
rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve
para encontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrir los errores en los programas
de aplicacin y en la estructura de la base de datos.
Adems, demostrar que los programas ``parecen'' trabajar tal y como se especificaba en los requisitos
y que las prestaciones deseadas ``parecen'' obtenerse. Por ltimo, en las pruebas se podr hacer una medida
de la fiabilidad y la calidad del software desarrollado.
11. Mantenimiento: Una vez que el sistema est completamente implementado y probado, se pone en marcha.
El sistema est ahora en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas:
Monitorizacin de las prestaciones del sistema: Si las prestaciones caen por debajo de un
determinado nivel, puede ser necesario reorganizar la base de datos.
Mantenimiento y actualizacin del sistema: Cuando sea necesario, los nuevos requisitos que vayan
surgiendo se incorporarn al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de
presentar.
4.2 Diseo de archivos
Un archivo es un elemento de informacin conformado por un conjunto de registros. Estos registros a su
vez estn compuestos por una serie de caracteres o bytes. Archivos convencionales: Un archivo es un
elemento de informacin conformado por un conjunto de registros. Estos registros a su vez estn compuestos
por una serie de caracteres o bytes.
. Actualmente las organizaciones estn utilizando bases de datos para generar resultados o para compartir
dicha informacin con otros sistemas. Sin embargo, los principales componentes de las bases de datos son los
archivos. Las formas en las cuales pueden organizarse los archivos, son archivos secunciales o archivos
directos.
En los archivos secunciales los registros estn almacenados en una secuencia que depende de algn
criterio definido, por ejemplo, pueden almacenarse los registros de los empleados de la empresa de manera
secuencial de acuerdo al departamento al que pertenecen o de acuerdo a su antigedad.

75

El uso de archivos secunciales presenta algunas desventajas en el proceso de actualizacin, consulta
o registro de informacin cuando se maneja gran volumen de datos. Por ejemplo, si se desea registrar un nuevo
empleado de acuerdo al departamento en el que va a laborar es necesario buscar uno por uno en los registros
del archivo hasta encontrar la posicin en la cual debe agregarse la informacin del nuevo empleado.
La otra forma de organizar los archivos es a travs de archivos directos, con los cuales se eliminan las
desventajas mencionadas en los archivos secunciales, ya que los archivos directos dan mayor flexibilidad en
su manejo. Esta forma de organizacin es la que hace posible que existan las bases de datos. Los archivos
directos permiten acceder directamente un registro de informacin sin tener que buscar uno a uno por todos los
registros del archivo, utilizando una llave de acceso dentro del archivo.
Tipos de sistemas de archivo:
Un sistema de archivos ( file system ) es una estructura de directorios con algn tipo de organizacin el
cual nos permite almacenar, crear y borrar archivos en diferentes formatos. En esta seccin se revisarn
conceptos importantes relacionados a los sistemas de archivos.
Almacenamiento Fsico de Datos: En un sistema de cmputo es evidente que existe la necesidad por parte de
los usuarios y aplicaciones de almacenar datos en algn medio, a veces por periodos largos y a veces por
instantes. Cada aplicacin y cada usuario debe tener ciertos derechos con sus datos, como son el poder
crearlos y borrarlos, o cambiarlos de lugar; as como tener privacidad contra otros usuarios o aplicaciones.
El subsistema de archivos del sistema operativo se debe encargar de estos detalles, adems de
establecer el formato fsico en el cual almacenar los datos en discos duros, cintas o discos flexibles. Debe ser
conocido por todos que tradicionalmente la informacin en los sistemas modernos se almacena en discos
duros, flexibles y unidades de disco ptico, y en todos ellos se comparten algunos esquemas bsicos para
darles formato fsico: las superficies de almacenamiento son divididas en crculos concntricos llamados "pistas"
y cada pista se divide en "sectores".
A la unin lgica de varias pistas a travs de varias superficies "paralelas" de almacenamiento se les
llama "cilindros", los cuales son inspeccionados al momento de lectura o escritura de datos por las respectivas
unidades fsicas llamadas "cabezas".
Las superficies de almacenamiento reciben el nombre de "platos" y generalmente estn en movimiento
rotatorio para que las cabezas accesen a las pistas que los componen. Los datos se escriben a travs de los
sectores en las pistas y cilindros modificando las superficies por medio de las cabezas. El tiempo que una
cabeza se tarda en ir de una pista a otra se le llama "tiempo de bsqueda" y depender de la distancia entre la
posicin actual y la distancia a la pista buscada.

76

El tiempo que tarda una cabeza en ir del sector actual al sector deseado se le llama tiempo de latencia y
depende de la distancia entre sectores y la velocidad de rotacin del disco. El impacto que tiene las lecturas y
escrituras sobre el sistema est determinado por la tecnologa usada en los platos y cabezas y por la forma de
resolver las peticiones de lectura y escritura, es decir, los algoritmos de planificacin.
Algoritmos de planificacin de peticiones: Los algoritmos de planificacin de peticiones de lectura y escritura
a discos se encargan de registrar dichas peticiones y de responderlas en un tiempo razonable.
Asignacin del espacio de almacenamiento: El subsistema de archivos se debe encargar de localizar
espacio libre en los medios de almacenamiento para guardar archivos y para despus borrarlos, renombrarlos o
agrandarlos. Para ello se vale de localidades especiales que contienen la lista de archivos creados y por cada
archivo una serie de direcciones que contienen los datos de los mismos. Esas localidades especiales se llaman
directorios. Para asignarle espacio a los archivos existen tres criterios generales que se describen enseguida:
Asignacin contigua: Cada directorio contiene la los nombres de archivos y la direccin del bloque inicial de
cada archivo, as como el tamao total de los mismos. Por ejemplo, si un archivo comienza en el sector 17 y
mide 10 bloques, cuando el archivo sea accesado, el brazo se mover inicialmente al bloque 17 y de ah hasta
el 27. Si el archivo es borrado y luego creado otro ms pequeo, quedarn huecos intiles entre archivos tiles,
lo cual se llama fragmentacin externa.
Asignacin encadenada: Con este criterio los directorios contienen los nombres de archivos y por cada uno de
ellos la direccin del bloque inicial que compone al archivo. Cuando un archivo es ledo, el brazo va a esa
direccin inicial y encuentra los datos iniciales junto con la direccin del siguiente bloque y as sucesivamente.
Con este criterio no es necesario que los bloques estn contiguos y no existe la fragmentacin externa, pero en
cada "eslabn" de la cadena se desperdicia espacio con las direcciones mismas. En otras palabras, lo que se
crea en el disco es una lista ligada.
Asignacin con ndices (indexada): En este esquema se guarda en el directorio un bloque de ndices para
cada archivo, con apuntadores hacia todos sus bloques constituyentes, de manera que el acceso directo se
agiliza notablemente, a cambio de sacrificar varios bloques para almacenar dichos apuntadores. Cuando se
quiere leer un archivo o cualquiera de sus partes, se hacen dos accesos: uno al bloque de ndices y otro a la
direccin deseada. Este es un esquema excelente para archivos grandes pero no para pequeos, porque la
relacin entre bloques destinados para ndices respecto a los asignados para datos es incosteable..

77

Mtodos de acceso en los sistemas de archivos: Los mtodos de acceso se refieren a las capacidades que
el subsistema de archivos provee para accesar datos dentro de los directorios y medios de almacenamiento en
general. Se ubican tres formas generales: acceso secuencial, acceso directo y acceso directo indexado:
Acceso secuencial: Es el mtodo ms lento y consiste en recorrer los componentes de un archivo uno en uno
hasta llegar al registro deseado. Se necesita que el orden lgico de los registros sea igual al orden fsico en el
medio de almacenamiento. Este tipo de acceso se usa comnmente en cintas y cartuchos.
Acceso directo: Permite accesar cualquier sector o registro inmediatamente, por medio de llamadas al sistema
como la de seek. Este tipo de acceso es rpido y se usa comnmente en discos duros y discos o archivos
manejados en memoria de acceso aleatorio. _ Acceso directo indexado: Este tipo de acceso es til para
grandes volmenes de informacin o datos. Consiste en que cada archivo tiene una tabla de apuntadores,
donde cada apuntador va a la direccin de un bloque de ndices, lo cual permite que el archivo se expanda a
travs de un espacio enorme. Consume una cantidad importante de recursos en las tablas de ndices pero es
muy rpido.
Operaciones soportadas por el subsistema de archivos: Independientemente de los algoritmos de
asignacin de espacio, de los mtodos de acceso y de la forma de resolver las peticiones de lectura y escritura,
el subsistema de archivos debe proveer un conjunto de llamadas al sistema para operar con los datos y de
proveer mecanismos de proteccin y seguridad.
Las operaciones bsicas que la mayora de los sistemas de archivos soportan son:
Crear (Create ) : Permite crear un archivo sin datos, con el propsito de indicar que ese nombre ya est usado
y se deben crear las estructuras bsicas para soportarlo.
Borrar (Delete ): Eliminar el archivo y liberar los bloques para su uso posterior.
Abrir (Open ): Antes de usar un archivo se debe abrir para que el sistema conozca sus atributos, tales como el
dueo, la fecha de modificacin, etc. _ Cerrar ( close ): Despus de realizar todas las operaciones deseadas, el
archivo debe cerrarse para asegurar su integridad y para liberar recursos de su control en la memoria.
Leer o Escribir (Read, Write ): Aadir informacin al archivo o leer el carcter o una cadena de caracteres a
partir de la posicin actual. _ Concatenar ( append ): Es una forma restringida de la llamada `write', en la cual
slo se permite aadir informacin al final del archivo. _ Localizar ( seek ): Para los archivos de acceso directo
se permite posicionar el apuntador de lectura o escritura en un registro aleatorio, a veces a partir del inicio o
final del archivo.

78

Leer Atributos: Permite obtener una estructura con todos los atributos del archivo especificado, tales como
permisos de escritura, de borrado, ejecucin, etc.
Poner Atributos: Permite cambiar los atributos de un archivo, por ejemplo en UNIX, donde todos los
dispositivos se manejan como si fueran archivos, es posible cambiar el comportamiento de una terminal con
una de estas llamadas.
Renombrar (Rename ): Permite cambiarle el nombre e incluso a veces la posicin en la organizacin de
directorios del archivo especificado. Los subsistemas de archivos tambin proveen un conjunto de llamadas
para operar sobre directorios, las ms comunes son crear, borrar, abrir, cerrar, renombrar y leer. Sus
funcionalidades son obvias, pero existen tambin otras dos operaciones no tan comunes que son la de `crear
una liga' y la de `destruir la liga'. La operacin de crear una liga sirve para que desde diferentes puntos de la
organizacin de directorios se pueda accesar un mismo directorio sin necesidad de copiarlo o duplicarlo. La
llamada a `destruir la liga' lo que hace es eliminar esas referencias, siendo su efecto la de eliminar las ligas y no
el directorio real. El directorio real es eliminado hasta que la llamada a `destruir liga' se realiza sobre l..
Algunas facilidades extras de los sistemas de archivos:
Algunos sistemas de archivos proveen herramientas al administrador del sistema para facilitarle la vida.
Las ms notables es la facilidad de compartir archivos y los sistemas de `cotas'. La facilidad de compartir
archivos se refiere a la posibilidad de que los permisos de los archivos o directorios dejen que un grupo de
usuarios puedan accesarlos para diferentes operaciones" leer, escribir, borrar, crear, etc. El dueo verdadero es
quien decide qu permisos se aplicarn al grupo e, incluso, a otros usuarios que no formen parte de su grupo.
La facilidad de `cotas' se refiere a que el sistema de archivos es capaz de llevar un control para que
cada usuario pueda usar un mximo de espacio en disco duro. Cuando el usuario excede ese lmite, el sistema
le enva un mensaje y le niega el permiso de seguir escribiendo, obligndolo a borrar algunos archivos si es que
quiere almacenar otros o que crezcan. La versin de UNIX SunOS contiene esa facilidad.
Sistemas de archivos aislados: Los sistemas de archivos aislados son aquellos que residen en una sola
computadora y no existe la posibilidad de que, an estando en una red, otros sistemas puedan usar sus
directorios y archivos. Por ejemplo, los archivos en discos duros en el sistema MS-DOS clsico se pueden ver
en esta categora.

79

Sistemas de archivos compartidos o de red: Estos sistemas de archivos es factible accesarlos y usarlos
desde otros nodos en una red. Generalmente existe un `servidor' que es la computadora en donde reside el
sistema de archivos fsicamente, y por otro lado estn los `clientes', que se valen del servidor para ver sus
archivos y directorios de manera como si estuvieran localmente en el cliente.
4.3 Administracin de bases de datos
Base de Datos: Es un conjunto de datos interrelacionados, por ejemplo: una gua de telfonos.
Hoy, la importancia e impacto de las bases de datos es incuestionable a medida que organizaciones
gubernamentales, instituciones acadmicas, y entidades comerciales crean y mantienen importantes bases de
datos que contienen toda clase de informacin desde documentos de texto en lenguaje natural, tablas
estadsticas, datos financieros y objetos multimediales hasta datos de naturaleza tcnica y cientfica.
Muchas bases de datos estn compuestas de metadatos, lo cual significa que los registros guardan
"datos acerca de los datos" tales como informacin acerca del tamao y carcter de otra base de datos en lugar
de ser la fuente primaria de contenido tal como nombre y domicilio de una persona.
Las tecnologas de bases de datos, incluyendo mtodos de arquitectura y acceso, se estn
desarrollando rpidamente para mantenerse al da con esta demanda de mecanismos de administracin de la
informacin. Los diseadores y administradores de bases de datos enfrentan muchos desafos que reflejan la
complejidad del floreciente entorno de la informacin.
Las tecnologas de bases de datos deben manejar masivas cantidades de datos, extraer informacin til
desde estos repositorios, y tener la habilidad para reflejar las relaciones entre los datos mantenidos en
diferentes bases de datos. Adems de la arquitectura y sistema deben proveer integridad, recuperacin,
concurrencia, y seguridad.
Para responder a estos desafos, los tres modelos fundamentales de bases de datos (jerrquico, red y
relacional), han servido como la base para desarrollar modelos de datos ms potentes y flexibles, tales como
los modelos relacional extendido y el relacional de objetos . Un esquema de datos y una arquitectura bien
definida aseguran almacenamiento de datos lgico y eficiente lo cual incrementa la capacidad de la base de
datos y extiende las capacidades de los lenguajes de consulta y otros mtodos de acceso.
Adems, la minera de datos crea informacin til al identificar datos relacionados dentro de los vastos
almacenamientos. Los investigadores ahora luchan con las complejidades de los temas relacionales y la
interoperabilidad. Por ejemplo los investigadores son capaces ahora de usar metadatos de manera ms
eficiente para la diseminacin mejorada de datos. Los investigadores son capaces tambin de usar estrategias
federadas para bases de datos distribuidas.

80

Sistema administrador de bases de datos (SABD o DBMS):
En el contexto de la organizacin, un SABD provee la informacin oportuna para la toma de decisiones,
siendo ste, su objetivo principal. Entendemos este SABD asociado al computador, el cual posee
caractersticas que lo hacen ser la herramienta ms adecuada para cumplir el objetivo del SABD; rapidez,
capacidad, manejo de grandes volmenes de informacin. Esto concluye que es necesario:
Definir estructuras de informacin
Definir mecanismos que permitan acceder a tal informacin. Por ejemplo: un lenguaje de consulta para
el usuario final, mecanismos de seguridad, mecanismos de proteccin de la informacin, etc.
Sistema de procesamiento de archivos:
Desventajas:
Redundancia e Inconsistencia de datos: Existen diversos tipos de inconsistencia de datos producidos
por la redundancia (ms de una copia de un mismo dato).
Dificultades para el acceso de los datos: En este enfoque cualquier requerimiento es satisfecho
como caso puntual, lo que implica dos cosas; el usuario no obtiene su informacin, o la obtiene a un
costo muy alto. Esta dificultad se debe a la inflexibilidad de estos sistemas. La inflexibilidad se debe a
que los sistemas han sido diseados sin coordinacin entre los grupos de desarrollo.
Aislamiento de los datos: Este aislamiento hace que sea imposible integrar la informacin para
satisfacer los requerimientos de gestin de la empresa, pues para ello es necesario efectuar procesos
complejos de importacin, transformacin, exportacin de datos.
Privacidad y seguridad: Usualmente no existen mecanismos de control de acceso, respaldos
uniformes y la recuperacin ante fallas de hardware y/o software, es una aventura. En general los datos
se encuentran muy susceptibles a ser daados en forma involuntaria o intencional.
Integridad: Hay que gastar mucho dinero en mantencin para lograr sistemas estables.
Otros: No hay metodologas de desarrollo, no hay estandarizacin, baja productividad, excesiva
mantencin y no existe departamento de informtica.
El problema de este enfoque, es que se ha dado excesiva importancia a los procesos, dejando de lado
lo ms importante, reconocido como un recurso de la organizacin, que es la informacin. Cualquier sistema en
el contexto de la organizacin, no es ms que un conjunto de procesos actuando sobre un conjunto de datos y
por lo tanto, debemos enfrentar el problema no solamente preocupndonos de los procesos, sino tambin de
los datos.

81

Es posible enfrentar el problema de satisfacer adecuadamente los requerimientos de informacin de los
usuarios viendo a la empresa, desde el punto de vista de la informacin utilizada. Denominamos a este
enfoque, el enfoque de datos. El que se concentra en analizar la informacin y en establecer una
representacin adecuada de sta para satisfacer los requerimientos de los usuarios.
Modelo de datos:
Al igual que en el ciclo de desarrollo del software y en general cualquier anlisis de resolucin de
problemas, los analistas involucrados en el estudio lo enfrentan en diferentes niveles de abstraccin. En el
proceso de establecer un modelo de la informacin manejado por una organizacin, podemos identificar tres
niveles de abstraccin.
Visin
Conceptual
Fsico
Por lo tanto, el modelo de datos, se define como una coleccin de herramientas conceptuales que
permiten describir datos, relaciones entre ellos, significado y restricciones de integridad y consistencia.
Simbologa o notacin:
Varias personas se ponen de acuerdo en la simbologa entendible o conocida por todos para lograr una
representacin abstracta. El principal objetivo de los modelos de datos, es obtener una representacin abstracta
de una realidad. (Informacin utilizada para llevar a cabo alguna funcin).
Tipos de Modelos de Datos:
Existen tres tipos de modelos de datos dependiendo del nivel de abstraccin en el que se utilizan, y son:
Modelos lgicos basados en entidades u objetos:
Se utilizan preferentemente en los niveles de visin y conceptual en el marco de diversas metodologas
de desarrollo. Algunos de estos modelos son: diagramas de entidades, diagramas de entidad relacin, modelo
semntico, modelo de Bachmann. Los modelos ms utilizados son el modelo entidad relacin y modelo
semntico.

82

Es importante destacar que este tipo de modelo, debe utilizarse absolutamente independiente de la
tecnologa de computacin que se utilice eventualmente para el desarrollo y construccin de los sistemas que
utilizaran la informacin modelada. La representacin de estos modelos es eminentemente lgica
(independientemente del formato de registros, de tipos de datos, estructuras de almacenamiento, etc.)
Modelo lgico basado en registros:
Se aplican fundamentalmente en los niveles conceptual y fsico en el marco de las metodologas de
diseo de aplicaciones, los modelos ms utilizados de este tipo son:
Modelo J errquico: se basa en una visin jerrquica de los datos entendiendo una jerarqua como una
relacin de uno (padre) a muchos (hijos), donde cada hijo tiene un solo padre. Por ejemplo; una
estructura orgnica. El producto ms usado de este tipo en su tiempo fue IMS (IBM).
Modelo Reticular: se basa en una estructura de redes entendiendo una red como una relacin de
muchos (nodos) a muchos. El producto ms usado en su tiempo fue Accent-r, dbms-10, total.
Modelos fsicos o internos:
Modelos Fsicos o Internos: estos modelos se utilizan nicamente en el nivel fsico en el marco de la
implementacin o construccin de un SABD:
Inicio: se caracteriza por el procesamiento de datos, es decir se utilizan sistemas operacionales de alta
rentabilidad. Ejemplo: sueldos, contabilidad. En esta etapa podemos identificar a un tipo de usuario
temeroso. Adems no se controlan los costos relacionados con informtica. En otras palabras, no existe
cultura informtica.
Contagio: en esta etapa, la organizacin detecta el computador y no hay una planificacin coherente,
lo que causa un crecimiento explosivo e irracional. Se siguen desarrollando sistemas operacionales sin
control, comenzando la mantencin de los sistemas en produccin.
Control: se caracteriza porque la organizacin se da cuenta que los costos son altos y crecientes y los
beneficios son mnimos, adems se advierte la necesidad de planificar y debido a la presin de los
usuarios, aparece el departamento de informtica.
Integracin: la planificacin ha sido asimilada y hay una adecuada definicin de polticas.
Arquitectura: la organizacin comienza su desarrollo tecnolgico. (Comunicacin, teleproceso, bases
de datos distribuidas, redes, etc.)
Madurez: comienza a pensar en largo plazo. La organizacin ve a la informacin como un recurso y a
la informtica como un rea estratgica, pero tambin la rentabilidad.

83

En el contexto de las aplicaciones: Podemos utilizar el enfoque de base de datos a nivel de las aplicaciones,
cuando:
Los requerimientos de informacin, estn en constante cambio.
Se requiere acceso rpido a la informacin estructurada de diferentes formas. Para lograr esto, la
informacin debe estar bien modelada.
Existen costos de desarrollo muy altos y crecientes, por lo tanto es urgente aplicar el enfoque de Base
de Datos. Los mayores costos se dan en la mantencin, por lo tanto se podra cambiar las herramientas
de desarrollo. (De Cobol a Power Builder).
Exista necesidad de compartir datos. Diferentes aplicaciones pueden compartir los mismos datos.
Exista necesidad de comunicar informacin entre diferentes reas funcionales ubicadas en puntos
geogrficos distantes. (Base de Datos Distribuidas).
Necesidad de contar con datos de mayor calidad. Grado de preparacin de la informacin, rapidez y
confiabilidad de los datos que estn almacenados.
Beneficios de usar base de datos:
Minimiza la redundancia de datos. Existe redundancia, pero controlada a fin de poder relacionar los
datos.
Aumento de la consistencia, debido a que la redundancia es mnima.
Integracin de los datos. Se tiene una visin ms centralizada de los datos.
Facilidad para compartir datos. Es de fcil acceso porque se comparten.
Mayor estandarizacin. Las aplicaciones accesan la Base de Datos de la misma forma. (Administracin
centralizada).
Facilidad para el desarrollo de las aplicaciones. Esta es consecuencia del punto anterior y con esto,
aumenta la productividad, porque me preocupo solo de los procesos.
Flexibilidad en el acceso de los datos. Existe ms de una forma de accesar a los datos.
Reduccin de la necesidad de mantencin de las aplicaciones.
Independencia de los datos. Es la capacidad de modificar una definicin, respecto de un conjunto de
datos en el nivel de abstraccin, sin afectar la definicin equivalente en el nivel superior siguiente, se
llama independencia de datos. (Niveles visin, conceptualizacin y fsico.)
Independencia fsica de los datos. Es la capacidad de modificar una definicin de datos en el nivel fsico
sin provocar que se deban escribir los programas de aplicacin nuevamente. Cuando hay problemas de
eficiencia, se produce el cambio en el nivel fsico.

84

Costos que implica usar el enfoque de base de datos:
Requerimiento de recursos especializados, ya que se requiere de especialistas en software y
metodologas.
Necesidad de respaldos de informacin, debido a la centralizacin de la informacin.
Conflicto organizacional, porque cuando la gente tiene que compartir su informacin, se siente
amenazada por la prdida de poder. La organizacin entera debe comprometerse con el nuevo enfoque
y es la nica forma de evitar la resistencia al cambio.
Complejidad del software, ya que el Sistema Administrador de Base de Datos tiene un alto costo ya que
la complejidad de este software, requieren mucha capacitacin
Tipos de usuarios:
Ingenuo: es el usuario ms bsico, o aquel que interacta con el sistema a travs de las interfaces que
proveen las aplicaciones (estructuradas). Ejemplo: un cajero de un banco.
Programador de Aplicaciones: es el constructor de los programas.
Sofisticados: es aquel que hace requerimientos de informacin no anticipados por las aplicaciones y
por lo tanto, requiere de un lenguaje de consulta para interactuar con los datos.
Administrador de base de datos: es el responsable de la definicin lgica y fsica de los datos
almacenados y de su contenido.
Funciones del administrador de base de datos:
Definicin de esquemas: El administrador tiene una doble funcin, debido a que debe interactuar con
usuarios e interactuar con programas de aplicacin. Esto se explica, debido a que ste, es responsable
del modelo lgico (Modelamiento de datos) y modelo fsico (Base de Datos, archivos) de los datos. Es
decir, est encargado de la estructura de la informacin.
Concesin de autorizacin: es responsable de definir quienes tienen accesos y a qu informacin
tienen acceso. Debe manejar los perfiles a acceso.
Especificacin de restricciones de integridad: Son reglas para validar datos.
Caractersticas del sistema administrador de base de datos:
Provee la interfaz entre los datos almacenados en la Base de Datos y los programas de aplicacin y
consultas (efectuadas por los usuarios) que interactan con el sistema. Es la interfaz entre los usuarios
y los datos.

85

Administracin de la base de datos:
Para que una Base de Datos sea exitosa, la administracin de ella debe ser eficiente. Se debe distinguir
dos objetivos:
1. Administracin de los Datos.
2. Administracin de la Base de Datos.
El A.D. es el responsable del desarrollo y administracin de las polticas, procedimientos, planes y prcticas
para la organizacin, proteccin y uso eficiente de los datos. Normalmente esta funcin es asignada a un grupo
de personas de alto nivel en la organizacin que conoce las necesidades de informacin en todos los niveles
organizacionales, especialmente en el nivel gerencial.
El D.B.A. es el responsable de la administracin de la Base de Datos durante el ciclo de vida de sta. Dado
que el objetivo del D.B.A. es el administrar la Base de Datos en s (y no los datos) deber preocuparse de las
polticas de seguridad, respaldos, recuperacin, etc.
Tareas de un administrador de base de datos:
Software:
Instalacin, desinstalacin y actualizacin de software y clientes
Instalacin y desinstalacin de parches
Pruebas de productos
Documentacin sobre bugs y versiones de productos
Creacin de informes de recomendacin de software
Conocimiento de las aplicaciones de los usuarios
Creacin de BD:
Configuracin parmetros de funcionamiento de la BD:
Gestin de
Usuarios
Creacin, Baja
Gestin de privilegios

86

Recursos:
Asignacin de tablee paces, espacio en HD
Actualizacin de parmetros del sistema
Backup y recuperacin:
Cargas de datos
Crear y modificar programas de carga
Ejecutar programas de carga
Mantenimiento de la BD. Altas, Bajas y Modificaciones de Objetos de la BD (vistas, ndices, tablas, etc.)
Monitorizacin:
Accesos de los usuarios
Rendimiento de los procesos
Crecimiento de ficheros
Creacin de estadsticas:
Crear y modificar programas de estadsticas
Optimizacin, mejoras de rendimiento.
4.4 Comunicaciones de Datos
Es importante para el desarrollo de sistemas de informacin cuando es requerido el intercambio de datos
por medio de una red. O el compartir archivos o bases de datos que requieran ser acezadas simultneamente
por diferentes usuarios.
Redes de datos:
La comunicacin entre computadoras siempre implica la transferencia de datos en bloques, en lugar de
secuencias continuas de datos. Esto se traduce en que no hace falta una conexin permanente entre dos
ordenadores o computadoras para intercambiar datos. A diferencia de las personas, pueden funcionar con un
enlace que exista slo de forma parcial durante el dilogo. Esto significa que hay alternativas para la
comunicacin de datos inviables en las llamadas normales de telfono.

87

La comunicacin de datos utiliza una tcnica denominada conmutacin de paquetes, que aprovecha la
posibilidad de transferir bloques de datos entre terminales sin establecer una conexin punto a punto. Por el
contrario, se transmiten de enlace a enlace, quedando almacenados temporalmente y en espera de ser
transmitidos cuando se establece el correspondiente enlace.
Las decisiones sobre su destino se toman basndose en la informacin de direccionamiento contenida
en la cabecera que va al principio de cada bloque de datos. El trmino paquete abarca la cabecera ms el
bloque de datos. Este tipo de conexin suele ser ms eficaz que un enlace punto a punto entre ambas partes,
mantenida hasta el final de la comunicacin. En la prctica, un mismo enlace fsico puede ser compartido por
ms de un usuario, gracias a una tcnica llamada multiplexacin. El precio a pagar por el mayor rendimiento es
el retraso que sufren algunos paquetes.
Topologas:
La topologa de una red, es el patrn de interconexin entre nodos y servidor, existe tanto la topologa
lgica (la forma en que es regulado el flujo de los datos), como la topologa fsica (la distribucin fsica del
cableado de la red). Las topologas fsicas de red ms comunes son:
Estrella.
Bus lineal
Anillo.
Topologa de Estrella: Red de comunicaciones en que la que todas las terminales estn conectadas a un
ncleo central, si una de las computadoras no funciona, esto no afecta a las dems, siempre y cuando el
"servidor" no est cado.
Topologa Bus Lineal: Todas las computadoras estn conectadas a un cable central, llamado el "bus" o
"backbone". Las redes de bus lineal son de las ms fciles de instalar y son relativamente baratas.
Topologa de Anillo: Todas las computadoras o nodos estn conectados el uno con el otro, formando una
cadena o crculo cerrado.
Protocolos:
Son conjuntos de normas para el intercambio de informacin, consensuadas por las partes
comunicantes. En trminos informticos, un protocolo es una normativa necesaria de actuacin para que los
datos enviados se reciban de forma adecuada. Hay protocolos de muy diversos tipos. Unos se ocupan de
aspectos bastante primarios como, por ejemplo, el de asegurar que el orden de los paquetes recibidos
concuerda con el de emisin.

88

A un nivel algo superior hay protocolos para garantizar que los datos enviados por una computadora se
visualicen correctamente en el equipo receptor. La informtica moderna utiliza muchos protocolos distintos.
Debido al auge de Internet, uno de los ms empleados es el protocolo TCP/IP. La norma publicada por la
International Standards Organization y conocida como modelo de 7 niveles, recoge la estructura general
comn a todos los protocolos.
La totalidad de los aspectos contemplados en la comunicacin entre ordenadores queda clasificada en
siete niveles. La idea es que los protocolos concretos desarrollados en cada uno de los niveles puedan
entenderse para conseguir una comunicacin eficaz.
4.5 Generadores de Aplicaciones y Lenguajes No Procedurales
Una aplicaciones un programa informtico que realiza una tarea. Una aplicacin en base de datos es
aquella que utiliza los datos e un sistema de gestin de base de datos. Sgbd La mayora de aplicaciones de
base de datos presentan en forma til o introducen o actualizan datos en la base de datos.
Una poltica que admita la revisin, por parte del departamento de sistemas, de todas las aplicaciones
diseadas por los usuarios ser de gran ayuda para el desarrollo de sistemas que cumplan con su finalidad y
que sean confiables. Desde el punto de vista de la organizacin, esta estrategia tambin permite hacer cumplir
de manera estricta los estndares de diseo y la validacin de las suposiciones hechas durante la formulacin
de las especificaciones.
El mtodo de desarrollo por parte de los usuarios se est utilizando cada vez ms en muchas
organizaciones. Los procedimientos eficaces para su manejo sern de gran ayuda para asegurar que los
resultados beneficien a los individuos y a la organizacin. Todas las "aplicaciones" (software para el "usuario
final") que conocemos han debido ser creadas especificando primero sus funciones y traduciendo stas en
"instrucciones" comprensibles por la mquina.
Para esto, el o los programadores utilizan un determinado "lenguaje de programacin", que es como un
idioma: cuenta con un diccionario (los "comandos") y una gramtica (reglas de sintaxis). El programador
traduce las especificaciones de funciones y operaciones (que estn en su idioma natural y/o en grficos que
especifican su secuencia) en este idioma, elaborando un producto llamado "programa fuente".
Este programa fuente ha de ser luego traducido (por el mismo computador) en el "lenguaje de
mquina", que es el que "entiende" el microprocesador. La traduccin, por lo tanto, debe hacerse teniendo en
cuenta el "lenguaje" propio del chip procesador (de ah que un mismo programa tendr una versin "para Power
PC (PPC)", "para Pentium", etc.

89

Esta traduccin puede hacerse de dos maneras: en forma previa al uso, con lo cual se genera el
"programa compilado" o "programa objeto", o bien se instala junto con el programa de traduccin en el
computador del usuario y se hace que la mquina traduzca las rdenes a medida que lee el programa fuente.
En la tercera parte de este captulo, se explica ms detalladamente lo que se entiende por "compilador"
e "intrprete" y cmo operan. A diferencia de un programa interpretado, un programa compilado (como la
mayora de las aplicaciones que hoy puede comprar el usuario comn) slo puede ser utilizado, pero no puede
ser ledo, revisado o modificado: la compilacin lo hace ilegible.
Tratar de "decompilarlo" para conocer su estructura y modo de funcionar (lo cual se llama "reverse
engineering") es muy complejo y normalmente prohibido en las condiciones de venta. As, la versin "fuente"
constituye un "secreto comercial", celosamente guardado por los fabricantes. Veremos, al final del captulo, que
este secreto puede ser algunas veces perjudicial para los usuarios. Pero antes hablaremos ms detalladamente
de los lenguajes de programacin.
Aunque el clculo relacional es difcil de entender y de usar, tiene una propiedad muy atractiva: es un
lenguaje no procedural. Esto ha hecho que se busquen tcnicas no procedurales algo ms sencillas, resultando
en dos nuevas categoras de lenguajes relacionales: orientados a transformaciones y grficos. Los lenguajes
orientados a transformaciones son lenguajes no procedurales que utilizan relaciones para transformar los datos
de entrada en la salida deseada.
Estos lenguajes tienen estructuras que son fciles de utilizar y que permiten expresar lo que se desea
en trminos de lo que se conoce. Uno de estos lenguajes es SQL (Structured Query Language). Los lenguajes
grficos visualizan en pantalla una fila vaca de cada una de las tablas que indica el usuario. El usuario rellena
estas filas con un `ejemplo' de lo que desea y el sistema devuelve los datos que siguen tal ejemplo. Uno de
estos lenguajes es QBE (Query-by-Example).
Otra categora son los lenguajes de cuarta generacin (4GL), que permiten disear una aplicacin a
medida utilizando un conjunto limitado de rdenes en un entorno amigable (normalmente un entorno de mens),
algunos sistemas aceptan cierto lenguaje natural, una versin restringida del idioma ingls, al que algunos
llaman lenguaje de quinta generacin (5GL), aunque todava se encuentra en desarrollo.
Lenguajes de bajo y alto nivel:
En efecto, lo nico que entienden y pueden manipular la Unidad de Control y la Unidad Aritmtica son
dgitos binarios o sea series de ceros y unos (paso o no paso de corriente elctrica). As, mientras el hombre
usa un "lenguaje natural" (idioma) muy rico en significados, la mquina usa un sistema en que existira un slo
"significado": la diferencia entre 0 y 1 (o sea un bit de informacin).

90

Cmo lograr ms? Simplemente concibiendo un nuevo lenguaje constituido de "bloques" de dgitos binarios
(llamados "bytes" ). Este es el primer paso o "primer nivel" en la construccin de lenguajes de computacin.
1 Nivel: Se dice que el cdigo binario es de "bajo nivel" o "primer nivel" (porque al usar pocos signos logra muy
difcilmente expresar cosas complicadas), mientras un lenguaje humano es de "muy alto nivel" (con una
cantidad mayor de signos y con reglas combinatorias logra expresar con facilidad cosas muy complicadas).
Todo el esfuerzo, entonces, para facilitar la comunicacin del hombre con el computador, ha de
centrarse en el desarrollo de lenguajes de mayor nivel. El fabricante de un procesador fija los bloques de bits
que llevarn a la CPU (unidad central de procesos) a reconocer y realizar diferentes operaciones. Este el el
" cdigo de mquina" , primer lenguaje que la mquina puede interpretar y transformar en acciones. Pero es
evidentemente muy difcil de usar para un ser humano. Supongamos que quiera hacer imprimir y para ello deba
decir "10011101 11100010": cmo recordar rdenes de este tipo y no equivocarse al escribirlas?
Prcticamente nadie trabaja hoy a este nivel, excepto los diseadores de "chips" procesadores. Del
mismo modo que es posible pasar de un sistema binario a un sistema decimal (ms comprensible y ms
desarrollado en trminos de signos legibles) es posible asociar a los bloques de bits no solo valores decimales
sino tambin otros signos. Esto lleva a un segundo nivel de expresin.
Hemos de recordar que el teclado equivale a un conjunto de interruptores: cada tecla que pulsamos
equivale a cerrar brevemente uno de stos, es decir produciendo un bit de informacin (no teclear =0, teclear
=1). Pero dado que hay muchas teclas, hay que identificar cada una, por lo cual pulsar una tecla significa activar
un circuito que generar un "bloque" binario (byte) especfico que identifica esa tecla.
A cada tecla est asociado un cdigo decimal y un cdigo hexadecimal. El hexadecimal (16 caracteres:
de 0 a 9 y de la A a la F) es el que sirve de intermediario a la mquina, para traducir nuestro cdigo natural
(alfanumrico) al cdigo binario.
2 Nivel: La creacin de un lenguaje ms comprensible por el hombre consiste por lo tanto en establecer la
equivalencia de bloques binarios con signos de nuestro lenguaje habitual. Para permitir la programacin
(secuencia de comandos), se usan pequeos conjuntos de signos ("palabras") de fcil memorizacin, con las
cuales se redactan programas, por ejemplo "ADC" significar "sumar con reserva" (en ingls: "ADd with Carry").
Este tipo de lenguaje se llama "ensamblador" o "Assembler" (Vea ms adelante la "Descripcin" de
Lenguajes). La mquina misma har la tarea de traducirlo en cdigo binario, para seguir las instrucciones,
gracias a otro programa cuya funcin es traducir la expresin humana en "lenguaje de mquina" (binario). Es
programa se llama "compilador.

91

Aunque el Assembler es un inmenso progreso en relacin al cdigo binario, su desventaja reside en que
permanece estrechamente ligado a los bloques binarios que reconoce la CPU (es decir al "hardware"). Para
facilitar ms la tarea, se han inventado lenguajes de "alto nivel", es decir ms cercanos al modo de expresar del
hombre que de operacin de la mquina.
Los primeros y ms comunes son los llamados de "tercera generacin", ms fciles de manejar y ms
independientes de las caractersticas tcnicas de los procesadores. Ahora, hasta un aficionado puede llegar a
redactar un programa, sin tener que preocuparse por el cdigo binario o de ensamble: si un programa traductor
poda resolver la transformacin de bloques de signos en bloques binarios, era cosa de extender las habilidades
del traductor para "ensear" a la mquina cmo "entender" un lenguaje ms complejo y agregar mecanismos
automticos de manejo de la memoria para poder utilizar lenguajes an ms comprensibles.
3 Nivel: El avance en el desarrollo de "compiladores" e "intrpretes" (los dos tipos de programas traductores)
ha sido por lo tanto fundamental en el desarrollo de los lenguajes de "3 generacin" cuyas ventajas adems de
la facilidad de aprendizaje y lectura/escritura son las facilidades de correccin, transformacin y conversin de
un lenguaje a otro. Con el micro-computador naci el BASIC ("para principiantes"). Mucha importancia tiene el
PASCAL, especialmente en la docencia. (Ms detalles luego, en la "Descripcin" de los lenguajes).
Generadores de aplicaciones o 4 nivel: Posteriormente, usando estos lenguajes, se han redactado
programas destinados a facilitar un nmero variado de operaciones en campos de aplicacin especficos como
simulacin de fenmenos fsicos, manipulacin de datos estadsticos, etc. Los ms avanzados y flexibles de
estos programas son las planillas electrnicas u hojas de clculo y los programas de administracin de archivos
o bases de datos (Vea el captulo "Aplicaciones").
Dados que tales aplicaciones no "hacen nada" sin que el usuario defina ciertas estructuras y ciertas
operaciones, pueden ser consideradas como "generadores" de aplicaciones, aunque este nombre se reserva
habitualmente para niveles ms avanzados en que los usuarios pueden generar sistemas muy diferentes unos
de otros, con "herramientas" que se parecen a lenguajes de programacin. stas herramientas conforman los
lenguajes de cuarto nivel que son por esencia "programas para crear programas" con una finalidad especfica,
como el "CASE" destinado a facilitar el trabajo de los analistas de sistemas.

92

Estructura de un lenguaje: Todo lenguaje, para permitir la programacin, ha de contener diversos tipos de
instrucciones:
Instrucciones simples:
De entrada: para buscar y recoger datos en la memoria central o auxiliar, o bien obtenerla por
interaccin con el usuario (p.ej. mensaje en el monitor de video que debe ser contestado en el teclado),
De salida: datos expuestos en el monitor de video o impresos, o transmitidos en una red,
De asignacin: asignar un valor a una variable, sea directamente (p.ej. Variable1 =15) sea por clculo
(p.ej. Var3 =Var1 +Var2).
Instrucciones compuestas:
De secuencia: por principio el orden dado a las instrucciones determina el orden en que se ejecuten,
salvo instrucciones especiales de "salto" como las previstas en instrucciones de alternacin o iteracin.
Toda instruccin compuesta debe tener una ENTRADA y una SALIDA. Puede siempre reemplazarse
una instruccin simple por una compuesta mantenindose el principio de secuencialidad de las
instrucciones.
De alternacin: escoger entre dos alternativas en funcin del cumplimiento de una condicin (p.ej. if X
>15 then ... else ...: si X es mayor que 15 haga esto, sino este otro)
De iteracin: ejecutar repetidamente un grupo de instrucciones mientras se cumpla una condicin (p.ej.
para contar de 1 hasta 10: N=1, while N <10 repeat {N =N+1, print N}. O sea mientras N sea inferior a
10, agregue 1 al valor anterior de N).
En este ejemplo, se introduce un concepto muy importante en el desarrollo y uso de lenguajes de
programacin: la recursividad, factible por el hecho de que lo que se manipula es siempre un valor colocado
en alguna celda de memoria. As, si bien la matemtica no puede aceptar una ecuacin como N=N+1, aqu
estamos ante una instruccin (no una ecuacin) que significa "tomar el valor que est en una celda llamada N,
sumarle 1 y volver a colocar el nuevo valor en la celda llamada N. sta es una "instruccin de asignacin".

93

Algunos lenguajes van an ms lejos y permiten una recursividad consistente en la posibilidad de que
una instruccin compuesta ordene la ejecucin de s misma. El siguiente podra ser una breve ejemplo, para
imprimir una lista con una instruccin recursiva, basta tener en cuenta que una lista se compone de una cabeza
(primer elemento) y una cola (el resto). Obviamente la cola es tambin una lista, por lo cual se le puede aplicar
el procedimiento consistente en separar su cabeza de su cola, y as sucesivamente, hasta encontrar una cola
vaca. Por lo tanto, se puede ordenar algo as:
Imprimir lista =imprimir cabeza
Lista =cola [borra de la lista la cabeza ya impresa]
Si lista no es vaca, imprimir lista [orden de recursin]
Sino: fin.

Programacin estructurada:
Como explicado a propsito de las "Instrucciones", todo programa se compone de una secuencia de
instrucciones que pueden ser simples o compuestas. La presencia de instrucciones que deban repetirse
muchas veces no slo se expresa en las iteraciones, donde dicha repeticin es inmediata. Existen muchos
casos en que la repeticin no es un flujo contino sino dependiente de otras operaciones o condiciones que son
muy variables. Es el caso por ejemplo de las instrucciones para leer o grabar datos en un disco.
La programacin estructurada, que es una forma de redaccin de programas (obligatoria u optativa,
segn el lenguaje escogido), se hace cargo de este requisito facilitando la constitucin de "paquetes" de
instrucciones (llamados "sub-rutinas" o "procedimientos"), los que pueden escribirse una sola vez y ser
"llamados" (utilizados) las veces que se requiera. Adems, pone nfasis en la conveniencia de facilitar la
lectura de los programas haciendo ms visible la dependencia jerrquica de las instrucciones compuestas , es
decir modificando el ancho del margen izquierdo para cada grupo de instrucciones.
4.6 Paquetes
Un paquete (package) es una unidad que agrupa un conjunto de entidades relacionadas. Su aplicacin ms
corriente es para realizar la declaracin de un tipo de datos junto con las operaciones primitivas para su
manejo, de forma que stas puedan ser usadas desde el exterior pero se mantengan ocultos sus detalles de
funcionamiento.
En otras palabras, un paquete es un mecanismo de encapsulamiento y ocultacin de informacin
especialmente til para definir tipos abstractos de datos. Un paquete se divide generalmente en dos partes:
especificacin e implementacin que se sitan en ficheros diferentes con las extensiones respectivas "*.ads" y
"*.adb". es

94

Paquetes de diseo grfico: Facilitan las presentaciones grficas con la posibilidad de encadenar grficos,
diagramas y dibujos en una secuencia sobre la pantalla. Dentro de stos se tiene Harvard Graphics, PowerPoint,
etc..
Diseo asistido: Enfocado a diseo industrial, permite realizar dibujos tcnicos por lo que son especialmente
tiles para determinados y especializados trabajos.
Aplicaciones avanzadas: Son herramientas de software capaces de resolver problemas complejos:
Gestin de proyectos: permiten al usuario planificar, distribuir y controlar las personas, los recursos
fsicos y los costes de mantenimiento y ejecucin de un determinado proyecto, como la construccin de
una autopista, etc. Los resultados de la planificacin se obtienen en grficos y tablas relacionando los
datos con el tiempo que dure el proyecto. De esta forma se controla el gasto y el tiempo previstos para
la ejecucin del proyecto.
Diseo con ordenador: el ordenador se puede utilizar como herramienta de diseo en ingeniera,
arquitectura, actividades artsticas, ilustraciones, etc. En diseo son importantes los paquetes de
aplicacin conocidos como CAD que significa Diseo Asistido por Ordenador. Y en fbricas de utilizan
los programas conocidos como CAM, Fabricacin Asistida por Ordenador.
Aplicaciones mdicas: existen aplicaciones mdicas como el seguimiento de la evolucin de un
paciente, diagnsticos de enfermedades, historias clnicas e investigacin mdica, incluso el control de
operaciones y su realizacin.
Aplicaciones en la enseanza: se emplean programas especiales como los CAI, Enseanza Asistida
por Ordenador. Tambin existen programas para el control de matrculas, notas, becas, etc.
Inteligencia artificial (AI): es una tcnica que intenta desarrollar ordenadores y programas capaces de
simular los procesos del pensamiento y las acciones del hombre. Los robots son mquinas empleadas
en tareas repetitivas o peligrosas. Existen tambin otras aplicaciones de la inteligencia artificial como
son los sistemas expertos, que son n conjunto de programas utilizados para la toma de decisiones.
Existen tambin ordenadores que realizan la conocida Realidad Virtual (RV), constituida por equipos
sensoriales interactivos con los que es posible simular realidades que aparentan el mundo fsico que
nos rodea.
Autoedicin: se emplean microordenadores, impresoras y el software necesario para mezclar textos y
grficos creando as publicaciones.
Multimedia: las tcnicas de multimedia combinan textos, grficos, animacin, vdeo, msica y voz, por
lo que el ordenador es el nexo de unin entre dispositivos como escner, cmaras de vdeo,
digitalizadores de sonido, cmaras de televisin, altavoces, etc.

95

4.7 Prototipos y programacin para usuarios finales
La palabra prototipo es usada en muchas formas diferentes, en vez de tratar de sintetizar todas ellas en una
solo definicin, o de imponer un enfoque correcto al tema algo controvertido de la elaboracin de prototipos,
ilustraremos como puede ser aplicada tilmente cada una de las varias concepciones de la elaboracin de
prototipos en una situacin particular. La elaboracin de prototipos de un sistema de informacin es una tcnica
valiosa para la recopilacin rpida de informacin especfica acerca de los requerimientos de informacin de los
usuarios.
Tipos de prototipos:
Prototipo parchado: El primer tipo en la elaboracin de prototipos tiene que ver con la construccin de un
sistema que trabaja, pero que esta parchado, un ejemplo de un prototipo en sistemas de informacin es un
modelo operable que tiene todas las caractersticas necesarias, pero que es ineficiente.
Prototipo no operacional: La segunda concepcin de un prototipo es la de un modelo a escala no funcional
para objeto de probar determinados aspectos el diseo, un ejemplo de este enfoque es un modelo a escala
completo de un automvil para ser usado en pruebas de tnel de viento, el tamao y la forma del auto son
precisas, pero el coche no es operacional, en este caso y solamente son incluidas las caractersticas del
automvil esenciales para la prueba del tnel de viento.
Prototipo primero de una serie: Una tercera concepcin de la elaboracin de prototipos involucra la creacin
de un primer modelo a escala completa de un sistema, llamado a veces un piloto. Un ejemplo es la elaboracin
de prototipo del primer avin de una serie, el prototipo es completamente operacional y es una realizacin de lo
que el diseador espera que sea una serie de aviones con caractersticas idnticas. Este tipo de prototipos es
til cuando se tienen planeadas muchas instalaciones del mismo sistema de informacin.
Prototipo de caractersticas seleccionadas: Una cuarta concepcin de la elaboracin de prototipos se refiere
a la construccin de un modelo operacional que incluye algunas, pero no todas, las caractersticas que tendr el
sistema final. Una antologa podra ser un nuevo complejo de ventas al menudeo que atiende al publico antes
de que toda la construccin este terminada,
Cuando se elaboran prototipos de sistemas de informacin en esta forma, son incluidas algunas, pero
no todas, de las caractersticas esenciales, por ejemplo: un men de sistema puede aparecer en la pantalla
listando seis caractersticas: aadir un registro (caracterstica uno), borrar un registro (caracterstica 3) y listar
un registro (caracterstica 5).

96

Cuando se construye este tipo de prototipo, el sistema se va construyendo por mdulos, de modo que si
las caractersticas reciben una evaluacin satisfactoria estas pueden incorporarse en el sistema final, mucho
mas grande sin tener que hacer un trabajo inmenso en interfaces, los prototipos hechos de esta forma son parte
del sistema actual, no son simplemente una maqueta.
Desarrollo de prototipos: La elaboracin de prototipos es una forma magnifica para deducir retroalimentacin
del sistema propuesto y que tan fcilmente esta satisfaciendo las necesidades de informacin de los usuarios.
Lineamientos para el desarrollo de prototipos,una vez que ha sido tomada la decisin de realizar el prototipo,
hay cuatro lineamientos principales a realizar cuando se integra la elaboracin del prototipo:
Trabajar en mdulos manejables
Construir el prototipo rpidamente
Modificar el prototipo en interacciones sucesivas
Enfatizar la interfaz de usuario
Trabajo en mdulos manejables: Cuando se realiza el prototipo de alguna de las caractersticas de un
sistema para obtener un modelo funcional, es imperativo que el analista trabaje en mdulos manejables, una de
las ventajas distintivas de la elaboracin de prototipos es que no es necesario, ni deseable construir un sistema
funcional completo para efectos del prototipo.
Construccin rpida del prototipo: La velocidad es esencial para la elaboracin satisfactoria de un prototipo
en un sistema de informacin. Los analistas pueden usar la elaboracin de prototipos para acortar lapsos,
usando tcnicas de recoleccin de informacin tradicionales para resaltar los requerimientos de informacin
salientes y luego tomando decisiones rpidamente que lleven a un modelo funcional.
Modificacin del prototipo: Un tercer lineamiento para el desarrollo del prototipo es que su construccin debe
dar soporte a las modificaciones. El hacer el prototipo modificable significa crearlo en mdulos que no son muy
interdependientes. En este lineamiento se encuentra menor resistencia cuando es necesario hacer
modificaciones al prototipo.
Enfatizar la interfaz de usuario: La interfaz del usuario con el prototipo es muy importante. Debido a que lo
que se esta tratando realmente de lograr con el prototipo es hacer que los usuarios muestre cada vez mas sus
requerimientos de informacin, deben ser capaces de interactuar fcilmente con el prototipo del sistema.

97

Desventajas de los prototipos:
Tal como pasa con cualquier tcnica de recopilacin de informacin, hay varias desventajas en la
elaboracin de prototipos:
La primera es que puede ser bastante difcil el manejar el prototipo como un proyecto dentro de un
esfuerzo para un sistema ms grande.
La segunda desventaja es que los usuarios y analistas pueden adoptar al prototipo como un sistema
completo cuando es, de hecho, inadecuado y nunca se pretendi que sirviera como un sistema
terminado.
El analista necesita ponderar estas desventajas contra las ventajas conocidas cuando decida si se hace el
prototipo, cuando lo hace y que tanto del sistema debe incluir en el prototipo.
Ventajas de los prototipos:
La elaboracin de prototipos no es necesaria o adecuada en todo proyecto de sistemas, sin embargo,
tambin se deben considerar las ventajas cuando se decida si se hace el prototipo:
La posibilidad de cambiar el sistema en etapas tempranas de su desarrollo
La oportunidad para detener el desarrollo de un sistema que no es funcional
Y la posibilidad de desarrollar un sistema que ataca ms adecuadamente las necesidades y
expectativas de los usuarios.
Papel de los usuarios en los prototipos:
El papel de los usuarios e la elaboracin de prototipos pueden ser resumidos en dos palabras:
Involucramiento honesto:
Si no se queda involucrado el usuario hay pocas razones para hacer prototipos, los comportamientos
precisos necesarios para la interaccin con el prototipo pueden variar, pero esta claro que el usuario es un
punto bsico para el proceso de la elaboracin de este.
Al darse cuenta de la importancia del usuario para el xito del proceso, el equipo de anlisis de
sistemas debe motivar y dar buena acogida a los comentarios recibidos y resguardarse contra su propia
resistencia natural a cambiar el prototipo.

98

Interaccin con el prototipo: Hay tres formas principales e que un usuario puede ser de ayuda en la
elaboracin del prototipo:
Experimentando con el prototipo
Reaccionar abiertamente ante el prototipo.
Sugiriendo adiciones y/o eliminaciones del prototipo.
Experimentando con el prototipo:
Los usuarios deben tener libertad para experimentar con el prototipo, a diferencia de una simple lista de
caractersticas del sistema, el prototipo permite a los usuarios la realidad de la interaccin real. Reaccionar
abiertamente ante el prototipo:
Otro aspecto del papel de los usuarios en la elaboracin de prototipos es sugerir adiciones y/o
eliminaciones a las caractersticas que se estn probando, el papel del analista es deducir tales sugerencias,
asegurando a los usuarios que la retroalimentacin que proporciona es tomada en serio, observando a los
usuarios mientras interactan y realizando entrevistas cortas y especificas con los usuarios en relacin con su
experiencia con el prototipo. 8
4.8 Especificaciones de Diseo
En esta actividad se definen y especifican la tecnologa asociada al sistema, indicando adems los
requisitos de comunicaciones, operacin, seguridad y control del sistema.
Los objetivos de la presente actividad son los siguientes:
Descripcin de los componentes del equipo fsico y lgico en que funcionara el sistema
Descripcin de las restricciones fsicas impuestas por los componentes anteriores.
Definicin de los estndares tcnicos que se aplicaran al diseo del sistema, incluyendo:

Lenguajes: Procedimientos de entrada y salida de datos, acceso al sistema manejo de errores y copia de
seguridad.

8 KENDALL & KENDALL, Anlisis y diseo de sistemas, 3 ed., Mxico, Pretince Hall, 1997, Pag. 210-212

99

Descripcin de la actividad: En esta actividad se especificar los requisitos del entorno tecnolgico del
sistema, incluyendo el dise de la arquitectura del sistema y de la estructura fsica de datos, as mismo
contemplar las especificaciones en comunicaciones, operacin y control del mismo.

Tcnicas requeridas: En la presente actividad no se requiere tcnica alguna, en vista que se usan criterios
en funcin al diseo de la arquitectura fsica del sistema y de la estructura fsica de datos.

Componentes a definir:

Equipo Fsico: Procesadores, dispositivos, ordenadores personales, estaciones de trabajo, etc.
Gestin de Datos: Sistemas de gestin de bases de datos, diccionarios de datos, etc.
Comunicaciones: Controladores de red, interfases externas, protocolos, recuperacin, respaldo, etc.
Equipo Lgico: Sistemas operativos, lgica de red, generadores de aplicaciones, lenguajes de
consulta, facilidades para el desarrollo de aplicaciones, herramientas CASE.
Gestin de Operaciones en Explotacin: Herramientas de control de trabajos, planes de
contingencia, etc.

Especificacin de requisitos de comunicacin del sistema:

Disea las comunicaciones para el sistema, es decir, si el sistema esta localizado en diferentes
puntos geogrficos, se disear la configuracin de la red de intercambio de datos entre estos puntos teniendo
en cuenta los requisitos no funcionales especificados en la Fase de Anlisis de Sistemas. Entre los
principales requisitos no funcionales se destacan los siguientes:

Crecimiento y evolucin estimada del sistema, con respecto a cambios en su distribucin
geogrfica, descentralizacin de funciones, etc.
Puntos geogrficos o nodos de tratamiento de datos.
Volmenes de intercambio de datos entre las distintas redes, especificando periodos de sobrecarga.
Tiempos de respuesta exigidos.
Los pasos a seguir para realizar el diseo de la configuracin de la red son los siguientes:
Seleccionar las caractersticas de la red de comunicaciones (topologa, medios de transmisin, equipo
lgico de la red, tipo de acceso, etc.),
Especificar los nodos de la red y asignar requisitos de rendimiento a cada uno, teniendo en cuenta
la distribucin geogrfica de las funciones del sistema y los requisitos de rendimiento del sistema.
Asignar terminales a los nodos de la red.
Especificar accesos locales en cada uno de los nodos.

100

Especificacin de requisitos de operacin, seguridad y control: En esta tarea, se definen para cada uno de
los componentes del sistema, los requisitos de operacin del mismo. Para ello, es preciso establecer: Los
componentes del sistema que se ejecuten en forma regular. Considerando, para estos componentes, los
puntos que se indican a continuacin:

Identificar los requisitos del tratamiento interactivo.
Identificar los requisitos de tratamiento diario y definir la secuencia en que deben ser realizados,
as como sus interdependencias.
Examinar el resto de los procesos que no sean diarios y establecer otros perodos de tiempo
requeridos.
Los componentes del sistema que solo se realicen si hay peticin. Considerando, para estos
componentes los siguientes puntos:
Identificar el tipo de peticin de tratamiento de los componentes que no se vayan a utilizar en forma
regular.
Establecer los procedimientos de peticin y acordarlos con los usuarios.

As mismo, ser de utilidad la identificacin de actividades fsicas del sistema, as como la
descripcin de los componentes ,disear la arquitectura fsica del sistema, para establecer los Requisitos de
operacin del sistema.Adems, se especificar n en detalle los requisitos de Seguridad y control, que debern
minimizar o eliminar la Perdida o alteracin de los datos.

Para ello, se debern revisar los requisitos no Funcionales del sistema, definidos en la Fase de
Ana lisis De Sistemas y especificar los procedimientos necesarios Para cumplir estos requisitos entre los que
cabe destacar:

Especificacin de claves de acceso al sistema.
Especificaciones claves de acceso de los datos o a funciones especificas del sistema.
Desarrollo de ficheros que permitan controlar los accesos al sistema.
Limitacin del nmero de intentos de acceso.
Especificacin de recuperacin y reanudacin de trabajos.
Especificacin de copias de seguridad o respaldo peridicas.
Especificacin en detalle de los procedimientos de control de trabajos.

101

4.9 Estudio de Factibilidad
El estudio de factibilidad no es un estudio de sistema completo, en vez de ello, se usa al estudio de
factibilidad para recopilar datos burdos para la administracin, para que a su vez les permitan tomar decisin
sobre si deben continuar con el estudio de sistema.
Los datos para el estudio de factibilidad pueden ser recolectados por medio de entrevistas, el tipo de
entrevista esta directamente relacionado con el problema u oportunidad que esta siendo sugerido, el analista
comnmente entrevista a aquellos que requieren ayuda y a los que estn directamente involucrados con el
proceso de toma de decisin, que son tpicamente los administradores.
Aunque es importante atacar el problema adecuado, el analista de sistemas no debe gastar mucho
tiempo haciendo estudios de factibilidad, debido a que muchos proyectos sern solicitados y solamente unos
cuantos debern ser ejecutados. El estudio de factibilidad debe ser altamente comprimido en el tiempo,
comprendiendo varias actividades en un pequeo lapso.
Definicin de objetivos:
La determinacin de factibilidad en general de un proyecto solicitado significa el encontrar cuales son
los objetivos organizacionales, y luego determinar si el proyecto sirve para mover el negocio hacia sus objetivos
en alguna forma, los objetivos del proyecto deben ser calificados por medio de entrevistas con la persona,
grupo o departamento que lo propone, adems, tambin es til una revisin de los trabajos escritos que se
relacionen con el proyecto solicitado. Existen varios objetivos aceptables para los proyectos de sistemas que
estos incluyen, pero no estn limitados, a:
Reducir errores
Reducir el costo de la salida del sistema mediante la agilizacin y eliminacin de reportes duplicados o
innecesarios.
Integrar los subsistemas del negocio
Mejorar los servicios al cliente para ganar una posicin competitiva.
Acelerar la entrada.
Acortar el tiempo de procesamiento de datos
Automatizar los procedimientos manuales para mejorarlos en alguna forma (reducir errores, aumentar la
velocidad o precisin, disminuir el tiempo requerido por empleado, etc.)

102

Tambin existen algunos objetivos inaceptables para los proyectos de sistemas:
Realizar un proyecto solamente para probar la destreza del equipo de analistas de sistemas, o
simplemente para afirmar la superioridad de un departamento sobre los dems acerca de su poder para dirigir
los recursos internos, tambin es intimarlos, o invertir en tecnologa nueva debido al encaprichamiento con los
nuevos atractivos que proporcionan sobre lo que tiene el sistema actual sin tomar en consideracin su
contribucin verdadera para el logro de los objetivos de la organizacin.
Los objetivos del proyecto necesitan ser puestos en claro formalmente en papel, as como
informalmente platicando con las personas del negocio. Considerando cual es el problema que ellos creen que
resolver el proyecto de sistema, o cual situacin se mejorara y cuales son sus expectativas acerca del sistema
propuesto.
Determinacin de recursos:
La determinacin de recursos para el estudio de factibilidad sigue el mismo patrn amplio tratado
anteriormente, y ser revisado y vuelto a evaluar cuando se encomiende el estudio de sistema formal, los
recursos sern tratados en relacin con tres reas de factibilidad:
Tcnica
Econmica
Operacional
Factibilidad tcnica:
Una gran parte de la determinacin de recursos tiene que ver con la valoracin de la factibilidad tcnica.
El analista debe encontrar si los recursos tcnicos actuales pueden ser mejorados o aadidos, en forma tal que
satisfaga la peticin bajo consideracin. Sin embargo, algunas veces las adiciones a los sistemas existentes
son costosas y no valen la pena, debido simplemente a que satisfacen las necesidades en forma ineficiente, si
los sistemas existentes no pueden ser aadidos, la siguiente pregunta es si hay tecnologa en existencia para
satisfacer las especificaciones.

103

Factibilidad econmica: La factibilidad econmica es la segunda parte de la determinacin de recursos, los
recursos bsicos a considerar son:
El tiempo propio y el del equipo de sistemas
El costo de hacer un estudio de sistema completo (incluyendo el tiempo de los empleados con los que
se trabajara)
El costo del tiempo de los empleados del negocio
El costo estimado de hardware
Y el costo estimado del software y/o desarrollos de software
El negocio de que se trate deber ser capaz de hacer ver el valor de la inversin en su ponderacin
antes de comprometerse a un estudio de sistemas completo, si los costos a corto plazo no son sobrepasados
por las ganancias a largo plazo, o no producen una reduccin inmediata en los costos de operacin, el sistema
no es factible econmicamente y el proyecto ya no debe continuar.
Factibilidad operacional:
Supongamos por un momento que se juzguen adecuados los recursos tcnicos y econmicos, el
analista de sistemas deber todava considerar la factibilidad operacional del proyecto solicitado. La factibilidad
operacional depende de los recursos humanos disponibles para el proyecto, e involucra proyectar si el sistema
operara y ser usado una vez que este instalado.
Si los usuarios estn casados virtualmente con el sistema presente, no ven problemas con el y, por lo
general, no estn involucrados en la peticin de un nuevo sistema, la resistencia ante la implementacin del
nuevo sistema ser fuerte, las oportunidades de que alguna vez llegue a ser operacional son escasas. En forma
alterna, si los usuarios han expresado la necesidad de que un sistema que es operacional la mayor parte del
tiempo tenga una forma mas eficiente y accesible, se tiene mejor oportunidad de que el sistema solicitado
llegue a ser utilizado.
La determinacin de la factibilidad operacional requiere imaginacin creativa por parte del analista de
sistemas, as como de su poder de persuasin, que permita que los usuarios sepan cuales interfaces son
posibles y cuales satisfacen sus necesidades, el analista de sistemas tambin debe escuchar cuidadosamente
lo que en realidad quieren los usuarios y lo que parece que usaran, sin embargo para evaluar la factibilidad
operacional, con mucha frecuencia hay que practicar el arte de adivinar.

104

4.10 Diseo de Sistemas de Acuerdo al Hardware
Los analistas de sistemas comienzan el proceso de diseo identificando los reportes y dems salidas
que debe producir el sistema, hecho lo anterior se determinan con toda precisin los datos especficos para
cada reporte y salida. Es comn que los diseadores hagan un bosquejo del formato o pantalla que esperan
que aparezca cuando el sistema este terminado.
Lo anterior se efecta en papel o en pantalla de una terminal utilizando para ello algunas de las
herramientas automatizadas disponibles para e desarrollo de sistemas. El diseo de un sistema tambin indica
los datos de entrada, aquellos que sern calculados y los que deben ser almacenados, as mismo, se escriben
con todo detalle los procedimientos de clculo y los datos individuales.
Los diseadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento, tales
como discos y cintas magnticas o incluso archivos de papel, los procedimientos que se escriben indican como
procesar los datos y producir las salidas. Los documentos que contienen las especificaciones de diseo
representan a este de muchas maneras (diagramas, tablas y smbolos especiales).
El entorno es donde se apoya el proyecto de software, llamado a menudo entorno de ingeniera de
software, incorpora hardware y software. El hardware proporciona una plataforma con las herramientas
(software) requeridas para producir los productos que son el resultado de la buena practica de la ingeniera del
software. Un planificador de proyectos debe determinar la ventana temporal requerida para el hardware y el
software, y verificar que estos recursos estn disponibles.
Muchas veces el desarrollo de las pruebas de validacin de un proyecto de software para la composicin
automatizada puede necesitar un compositor de fotografas en algn punto durante el desarrollo, cada elemento
de hardware debe ser especificado por el planificador del proyecto de software.
4.11 Administracin del Desarrollo del Proyecto
Realiza las siguientes funciones:
Organizar
Planificar y
Calendarizar los proyectos de software

105

Objetivos:
Introducir la administracin de proyectos de software y describir sus distintas caractersticas
Discutir la planificacin de proyectos y el proceso de planificacin
Mostrar cmo la administracin de proyectos usa representaciones grficas de calendarios
Discutir el concepto de riesgos y el proceso de manejar los riesgos
La administracin de un proyecto de software:
Involucra asegurar que el software sea entregado a tiempo y de acuerdo con los requerimientos de las
organizaciones que desarrollan y compran el software. La administracin del proyecto siempre es necesaria
porque el desarrollo de software est sujeto a las restricciones de presupuesto y calendario que estn
determinadas por la organizacin que desarrolla el software.
Las distinciones de administracin de software:
El producto es intangible
El producto es nicamente flexible
La ingeniera de software no es reconocida como una disciplina de ingeniera como ingeniera
mecnica, ingeniera electrnica, etc.
El proceso de desarrollo de software no es estandarizado
Muchos proyectos de software son proyectos que se hacen una sola vez y no son parecidos a ningunos
otros proyectos
Las actividades de administracin:
Escribir propuestas
Planificar y calendarizar proyectos
Determinar los costos de proyectos
Monitorear y revisar el proyecto
Seleccionar y evaluar personal
Las similitudes de administracin:
Estas actividades no son propias de la administracin de software
Muchas tcnicas de administracin de proyectos de ingeniera son igualmente aplicables a la
administracin de proyectos de software
Sistemas tcnicamente complejos de ingeniera tienden a sufrir de los mismos problemas que los
sistemas de software

106

Proveer personal de proyectos:
Puede ser imposible nombrar las personas ideales a trabajar en un proyecto
El presupuesto del proyecto tal vez no puede dejar el uso de personal bien pagado.
El personal con las habilidades necesitas tal vez no est disponible.
Una organizacin puede querer desarrollar las habilidades de los empleados usando un proyecto.
Los directores necesitan trabajar dentro de estas restricciones especialmente cuando hay una escasez
internacional de personal de tecnologa de informacin
Planificar el proyecto:
Probablemente la actividad que consume la mayor parte del tiempo en administracin de proyectos
Actividad contina desde el concepto inicial hasta la entrega del sistema. Es necesario revisar los
planes con regularidad cuando haya nueva informacin disponible
Varios tipos diferentes de planes pueden ser desarrollados para soportar el plan principal del proyecto
que trata del calendario y presupuesto.
Los tipos de plan de proyecto:
Plan Descripcin
Plan de calidad Describe los procedimientos y estndares de calidad que sern usados en un
proyecto.
Plan de validacin Describe el enfoque, los recursos y calendario usados para la validacin del
sistema.
Plan de manejo de
configuracin
Describe los procedimientos y estructuras de manejo de configuracin que sern
usados.
Plan de mantenimiento Predice los requerimientos de mantenimiento del sistema, los costos de
mantenimiento y el esfuerzo requerido.
Plan de desarrollo de
personal
Describe como las habilidades y la experiencia de los miembros del equipo del
proyecto sern desarrolladas.

107

El Proceso de planificar un proyecto:

Establecer las restricciones del proyecto
Hacer juicios iniciales sobre los parmetros del proyecto
Definir los hitos y entregables del proyecto: WHILE el proyecto no ha sido completado o cancelado
LOOP.
Crear el calendario del proyecto
Iniciar las actividades conforme al calendario
Esperar durante algn tiempo
Revisar el progreso del proyecto
Revisar las estimaciones de los parmetros del proyecto
Renegociar las restricciones y entregables del proyecto: IF surgen problemas THEN
Iniciar un repaso tcnico y posible revisin: END IF, END LOOP

La estructura de un plan proyecto:
Introduccin
Organizacin del proyecto
Anlisis de los riesgos
Los requerimientos de los recursos de hardware y software
Desglose de trabajo
Calendario del proyecto
Organizacin de actividades:
Las actividades en un proyecto deben ser organizadas para producir salidas tangibles para que el
director pueda juiciar el progreso
Hitos ("milestones") son las puntas finales de una actividad de un proceso
Entregables ("deliverables") son los resultados del proyecto entregados al cliente
El proceso de cascada permite la definicin sencilla de hitos de progreso

108

Actividades

Estudio
Fehaciente
Anlisis de
Requerimientos
Desarrollo del
Prototipo
Estudio de
Diseo
Especificacin
de
Requerimientos

Reporte
Fehaciente

Definicin de
Requerimientos

Reporte de
Evaluacin

Diseo
Arquitectnico

Especificacin de
Requerimientos

Figura 4.1 Ejemplo de Hitos en el Proceso de Requerimientos:

Actividades:

Estudio de factibilidad
Anlisis de requerimiento
Desarrollo de prototipo
Estudio de diseo
Especificacin de requerimientos
HITOS
Reporte de factibilidad
Requerimientos del usuario
Reporte de evaluacin
Diseo arquitectnico
Requerimientos del sistema

109

Calendarizar el proyecto:
Partir el proyecto en tareas y estimar el tiempo y recursos requeridos para cumplir cada tarea
Organizar las tareas concurrentemente para hacer uso ptimo del personal
Minimizar las dependencias de tareas para evitar retrasos causados por una tarea esperando que otra
tarea se cumpla
Depende en la intuicin y experiencia del director

Identificar
Actividades
Dependencias
Indefinidas y
Actividad
Recursos
Estimados para
Actividades
Localizar Gente
para
Actividades
Crear
Proyecto de
Carteles
Actividades en Carteles y
Carteles de Barra Requerimientos de
Software
Figura 4.2 Ejemplo del Proceso de Calendarizar un Proyecto:
Requerimientos de software:

Identificar actividades
Identificar dependencias entre actividades
Estimar recursos para actividades
Repartir actividades a personas
Crear grficas del proyecto
Grficas de actividades y barras

110

Problemas con la candelarizacin:
Es difcil estimar la dificultad de problemas y, por eso, es difcil estimar el costo de desarrollar una
solucin
La productividad no es proporcional al nmero de personas trabajando en una tarea
Agregar personas a un proyecto atrasado lo hace atrasarse ms por los gastos de comunicacin
Cosas inesperadas tambin ocurren. Siempre haga planes de contingencia cuando est planificando
Graficas de barras y redes de actividad:
Notaciones grficas usadas para ilustrar el calendario del proyecto
Muestre el desglose del proyecto en tareas. Las tareas no deben ser demasiado pequeas. Ellas deben
tomar ms o menos una o dos semanas
Las grficas de actividades muestran las dependencias entre tareas y la trayectoria crtica
Las grficas barras muestran el calendario de proyecto versus tiempo

Figura 4.3 Ejemplo de Lnea de Asignacin del Personal:

111

Figura 4.4 Ejemplo de Asignacin del Personal.

El manejo de riesgos:
El manejo de riesgos involucra identificar los riesgos y crear planes para minimizar su efecto en un
proyecto
Un riesgo es una probabilidad que alguna circunstancia adversa pueda ocurrir
Los riesgos de un proyecto afectan el calendario o recursos
Los riesgos de un producto afectan la calidad o el rendimiento del producto
Los riesgos de negocio afectan la organizacin que desarrolla o compra el software

112

Los riesgos del software:

Riesgo
Tipo de
riesgo
Descripcin
Movimiento de personal Proyecto
El personal con experiencia saldr el proyecto
antes de que el proyecto sea completado
Cambio en administracin Proyecto
Habr un cambio en administracin
organizacional con diferentes prioridades
Hardware no disponible Proyecto
Hardware que es imprescindible para el
proyecto no ser entregado a tiempo
Requerimientos cambian
Proyecto y
producto
Habrn un nmero ms grande de cambio a los
requerimientos que esperaba
Retrasos en
especificacin
Proyecto y
producto
Las especificaciones de interfaces
imprescindibles no estarn disponibles a
tiempo
Subestimacin de tamao
Producto y
proyecto
El tamao del sistema ha sido subestimado
Subrendimiento de
herramientas CASE
Producto
Herramientas CASE que soportan el proyecto
no funcionan como esperada
Cambio en tecnologa Negocio
La tecnologa en que el sistema es construida
es suplantada por nueva tecnologa
Competencia del
producto
Negocio
Un producto competitivo est publicitado antes
de que el sistema est completo

El proceso de manejar riesgos:
Identificar riesgos
Identificar los riesgos de proyecto, producto y negocio
Analizar riesgos
Planificar riesgos
Crear planes para evitar o minimizar los efectos del riesgo
Monitorear riesgos
Monitorear los riesgos durante todo el proyecto

113

Identificacin de riesgos:
Riesgos de tecnologas
Riesgos de personas
Riesgos de la organizacin
Riesgos de los requerimientos
Riesgos de estimacin
Analizar riesgos:
Valorar la probabilidad y seriedad de cada riesgo
La probabilidad puede ser muy baja, baja, moderada, alta o muy alta
Los efectos del riesgo pueden ser catastrficos, serios, soportables o insignificantes

114

Anlisis de riesgos:

Riesgo Probabilidad Efectos
Problemas financieros de la organizacin hacen que se
reduzca el presupuesto del proyecto.
Baja Catastrficos
Es imposible reclutar personal con las habilidades
requeridas para el proyecto.
Alta Catastrficos
El personal clave est enfermo en un momento crtico para
el proyecto.
Moderada Serios
Componentes de software que se deberan rehusar
tienen defectos que limitan su funcionalidad.
Moderada Serios
Cambios en requerimientos que requieren trabajo de
rediseo significante son propuestos.
Moderada Serios
La organizacin es reorganizada de tal manera que una
administracin diferente es ahora responsable del proyecto.
Alta Serios
La base de datos usada en el sistema no puede procesar la
cantidad de transacciones por segundo como se esperaba.
Moderada Serios
El tiempo requerido para desarrollar el software es
subestimado.
Alta Serios
Las herramientas CASE no pueden ser integradas. Alta Tolerables
Los clientes no logran entender el impacto de los cambios
de requerimientos.
Moderada Tolerables
Entrenamiento requerido para el personal no esta
disponible.
Moderada Tolerables
La velocidad de reparacin de defectos es subestimada. Moderada Tolerables
El tamao del software es subestimado. Alta Tolerables
El cdigo generado por las herramientas CASE es
ineficiente.
Moderada Insignificantes

115

Monitorear Riesgos:

Valorar cada riesgo identificado con regularidad para determinar si est volvindose ms o menos
probable
Tambin valorar si los efectos del riesgo han cambiados
Cada riesgo clave se debe discutir con la administracin durante reuniones de progreso
Factores de riesgo:
Tipo de riesgo Indicadores potenciales
Tecnologa
Entrega tarde de hardware o software de soporte, muchos problemas
reportados de tecnologa
Personal
Baja moral del personal, malas relaciones entre miembros del equipo,
disponibilidad de trabajo
Organizacin Una falta de accin por la administracin superior
Herramientas
Desgana por los miembros del equipo por usar herramientas, quejas
sobre las herramientas CASE, exigencias para computadoras con ms
poder
Requerimientos
Muchas solicitudes para cambios de requerimientos, quejas por el
cliente
Estimacin
Fracaso a alcanzar el calendario convenido, fracaso al arreglar defectos
reportados
4.12 Documentacin
La documentacin es el conjunto de informacin interna y externa al programa que facilitar su posterior
mantenimiento. La documentacin puede ser interna y externa.
Documentacin interna, est constituida por:
Comentarios dentro del cdigo del programa
La presentacin. Es la manera de estructurar el cdigo para facilitar su lectura y comprensin.

Documentacin externa: No est contenida dentro del cdigo del programa, est constituida por:

116

Manual del Usuario
Manual del Programador
Manual de Mantenimiento del Programa
Especificaciones del Programa
Lista de Datos de Prueba (test) y Resultados
Historia del desarrollo del programa, modificaciones posteriores
Diseo descendente con detalle en mdulos y submdulos
Versiones en uno y diferencia entre s.
Durante esta fase, el analista tambin colabora con los usuarios para desarrollar, la documentacin
indispensable del software, incluyendo los manuales de procedimientos, la documentacin le dir al usuario
como operar el software y as tambin que hacer en caso de presentarse algn problema. A parte de los
manuales tcnicos, de instalacin y de usuario, se producen los siguientes productos adicionales:
Diseo formal, que define claramente las estructuras de desarrollo contemplado las herramientas y
plataformas diseadas para lo mismo.
Plantillas de dato
Casos de uso y negocio
Esquemas fsicos de las bases de datos
Algoritmos propios del dominio de la aplicacin
Estndares de programacin
Catlogos de informacin
Script s o guiones de las bases de datos
Esquemas de seguridad, definicin del esquema de seguridad con usuarios, grupos, permisos,
restricciones, bitcoras, etc.
Definicin del esquema de seguridad de las aplicaciones, como de las interfaces de comunicacin con
otros sistemas, mecanismos de respaldo y recuperacin de datos.
4.13 Prueba e Instalacin
Es la ultima fase el desarrollo de sistemas, es el proceso de instalar equipos o software nuevo, como
resultado de un anlisis y diseo previo, resultado de la sustitucin o mejoramiento de la forma de llevar a cabo
un proceso automatizado.

117

Al implantar un sistema de informacin lo primero que debemos hacer es asegurarnos que el sistema sea
operacional o sea que funcione de acuerdo a los requerimientos del anlisis y permitir que los usuarios puedan
operarlo. Existen varios enfoques de implementacin como son :
Darle responsabilidad a los grupos.
Uso de diferentes estrategias para el entrenamiento de los usuarios.
El analista de sistemas necesita ponderar la situacin y proponer un plan de conversin que sea
adecuado para la organizacin.
El analista necesita formular medidas de desempeo con las cuales evaluar a los usuarios.
Debe convertir fsicamente el sistema de informacin antiguo, al nuevo modificado.
En la preparacin de la implantacin, aunque el sistema este bien diseado y desarrollado correctamente
su xito depender de su implantacin y ejecucin por lo que es importante capacitar al usuario con respecto a
su mantenimiento.
Capacitacin de usuarios del sistema: Es ensear a los usuarios que se relacionan u operan en un proceso
de implantacin. La responsabilidad de esta capacitacin de los usuarios primarios y secundarios es del
analista, desde el personal de captura de datos hasta aquellos que tomas las decisiones sin usar una
computadora.
No se debe incluir a personas de diferentes niveles de habilidad e inters de trabajo, debido que si en
una empresa existen trabajadores inexpertos no se pueden incluir en la misma seccin otros servicios de
capacitacin como son:
Vendedores: Son aquellos que proporcionan capacitacin gratuita fuera de la empresa de uno o dos
das.
Instructor pagado externamente: Son aquellos que pueden ensear todo acerca de las
computadoras, pero para algunos usuarios esta no es una capacitacin necesaria.
Instructores en casa: Estn familiarizados con el personal y pueden adecuar los materiales a sus
necesidades, pero le faltara experiencia en sistemas de informacin que es realmente la necesidad del
usuario.

118

Objetivos de la capacitacin: Es lograr que los usuarios tengan el dominio necesario de las cosas bsicas
acerca de las maquinarias y procesos que se emplean para su operacin de manera eficiente y segura.
La Evaluacin del Sistema: Se lleva a cabo para identificar puntos dbiles y fuertes del sistema implantado, la
evaluacin ocurre a lo largo de las siguientes cuatro dimensiones:
Evaluacin Operacional: Es el momento en que se evala la manera en que funciona el sistema, esto incluye
su facilidad de uso, tiempo de respuesta ante una necesidad o proceso, como se adecuan los formatos en que
se presenta la informacin.
Impacto Organizacional: Identifica y mide los beneficios operacionales para la empresa en reas tales como:
finanzas (costos, ingresos y ganancias), eficiencia en el desempeo laboral e impacto competitivo, impacto,
rapidez y organizacin en el flujo de informacin interna y externa.
Desempeo en el desarrollo: Es la evaluacin del proceso de desarrollo adecuado tomando en cuenta ciertos
criterios como: tiempo y esfuerzo en el desarrollo de presupuestos y estndares y otros criterios de
administracin de proyectos, adems incluye la valoracin de los mtodos y herramientas utilizados durante el
desarrollo de sistema.
Prueba de Sistemas: Dependiendo del tamao de la empresa que usara el sistema y el riesgo asociado a su
uso, puede hacerse la eleccin de comenzar la operacin del sistema solo en un rea de la empresa (como una
prueba piloto), que puede llevarse cabo en un departamento o con una o dos personas, cuando se implanta un
nuevo sistema ,lo aconsejable es que el viejo y el nuevo funcionen de manera simultanea o paralela con la
finalidad de comparar los resultados que ambos ofrecen en su operacin, adems de dar tiempo al personal
para su entrenamiento y adaptacin al nuevo sistema.
Durante el proceso de implantacin y prueba se deben implantar todas las estrategias posibles para
garantizar que en el uso inicial del sistema este se encuentre libre de problemas lo cual se puede descubrir
durante este proceso y llevar a cabo las correcciones para su buen funcionamiento.
4.14 Mantenimiento
Nuestro comportamiento nunca termina con la liberacin de los sistemas, sino que apenas comienza como
consecuencia de la supervisin continua, corrigiendo y actualizando el sistema que se les entrega a los
usuarios. El mantenimiento es otro de los factores cruciales a tomar en cuenta durante la evaluacin tcnica de
las propuestas, consiste bsicamente en la capacidad de un proveedor para proporcionar un soporte y servicio
adecuado, para asegurar el funcionamiento continuo e interrupcin del sistema computacional.

119

Algunos de los aspectos a considerar son los siguientes:
Calidad y cantidad de personal capacitado de tiempo completo disponible en hardware y software.
Tiempo promedio que tarda el proveedor en atender las fallas reportadas, tiempo o porcentaje de
sistemas.
Tiempo promedio que el sistema permanece cado durante cada falla.
Existencia de una bodega cercana con partes y repuestos para responder con mayor oportunidad a
fallas.
Existencia de horario extendido, siete das y veinticuatro horas para atender fallas.
Por Mantenimiento Preventivo: Se entiende al conjunto de pasos que se realizan para llevar a cabo la
revisin de un equipo a fin de evitar posibles fallas dentro del hardware y software.
Por mantenimiento Correctivo: Se entiende al conjunto de actividades que se realizan cuando el sistema de
informacin no cumple con los requerimientos establecidos
Mantenimiento Evolutivo: Se entiende a todas aquellas actividades que se realizan, a peticin de los usuarios,
con el fin de mejorare funcionalmente el software por exigencias del negocio, nuevas normativas, etc.
Podemos resaltar que las actividades de mantenimiento son una actividad necesaria para el
funcionamiento de la organizacin y que el reconocimiento de su existencia es fundamental para poder articular
soluciones eficaces, basadas en acuerdos e nivel de servicio.
4.15 Optimizacin
Los trminos frecuentemente usados en estudios y anlisis de optimizacin del diseo son los siguientes:
Variables de diseo ( design variables)
Funcin objetivo (objetive function)
Restricciones de comportamiento (behavior constraints)
Valores de respuesta (response quantities)
Viabilidad del diseo (feasible design)
Diseo optimo (optimun design), y
Sensibilidad (sensivity)

120

Variables de diseo: Las variables e diseo son las dimensiones (parmetros) del modelo que el usuario
desea optimizar, cualquier dimensin o parmetro puede ser definido como una variable de diseo, para cada
variable de diseo hay que especificar un valor mnimo y mximo, as como la tolerancia. Al especificar los
limites sin problemas en todas sus combinaciones.
Funcin objetivo: La funcin objetivo es un valor nico que el usuario busca minimizar o maximizar, la funcin
objetivo debe ser una funcin continua de las variables de diseo, el peso (o volumen) de una estructura es un
ejemplo de las funciones objetivo mas utilizada.
Restricciones de comportamiento: Las restricciones establecen las condiciones que el diseo ptimo debe
cumplir para que sea un diseo viable, las restricciones de comportamiento tpicamente son valores de
respuesta funcin de las variables de diseo. Cada restriccin se define en base a los resultados obtenidos
mediante un estudio inicial, con un lmite inferior, uno superior y una tolerancia.
Las restricciones pueden ser:
Tensiones
Deformaciones unitarias
Desplazamientos
Carga critica de pandeo
Frecuencias naturales
Temperaturas
Gradientes de temperatura
Flujo de calor
Diseo viable: Un diseo viable es un diseo que satisface todas las restricciones y sus variables de diseo se
encuentran dentro de los lmites establecidos, un diseo viable puede ser o no el diseo optimo.
Diseo optimo: Un diseo ptimo es un diseo viable que mejor satisface la funcin objetivo.
Estudios de sensibilidad: Un estudio de sensibilidad permite conocer la variacin de una respuesta al cambiar
una variable de diseo, as podemos conocer mediante graficas de respuesta x-y la variacin de la tensin o
los valores de frecuencias naturales de una estructura, o los valores de desplazamiento, etc., al modificar el
valor de las variables de diseo introducidos mediante una tabla, o indicando el valor mnimo y mximo y el
numero de steps.

121

V. ADQUISICION DE EQUIPO
Para la adquisicin de hardware, deben tomarse en cuenta los siguientes puntos:
Determinacin del tamao y requerimiento de capacidad
Evaluacin y medicin de la computadora.
Compatibilidad.
Factores financieros.
Mantenimiento y soporte tcnico.
Al realizar la compra se deben considerar los siguientes aspectos:
Tamao interno de la memoria
Velocidad de procesamiento
Nmero de canales para entrada/salida de datos y comunicaciones
Tipos o nmeros de dispositivos de almacenamiento
Software que se proporciona y sistemas desarrollados disponibles.
La propuesta del sistema es un resumen de todo lo que el analista de sistemas ha aprendido acerca de
la empresa y de lo que esta requiere para mejorar su desempeo, con el fin de abordar de manera adecuada
las necesidades de informacin, el analista hace uso de medios sistemticos para la adquisicin de hardware
(equipo); identifica y pronostica el costo y los beneficios futuros y realiza un anlisis costo-beneficio.
Las necesidades de informacin de los usuarios determinan en ltima instancia el tipo de equipo de
cmputo, los dispositivos de almacenamiento de datos. Los analistas de sistemas deben trabajar en conjunto
con los usuarios para determinar el equipo. (Hardware) que ser requerido, el establecimiento de equipos se
apegara a los requerimientos de informacin. Las opciones de equipo podrn considerarse una vez que los
analistas de sistemas, los usuarios y los directivos cuenten con una clara concepcin de las tareas que
realizaran.

122

Inventario del equipo de cmputo:
Comenzando por hacer un inventario de todo el equipo de cmputo que se encuentre disponible en la
organizacin, si no se cuenta con un inventario actualizado del equipo de cmputo, el analista de sistemas
deber establecerlo de manera rpida, conociendo:
El tipo de equipo, nmero de modelo y fabricante
El status de la operacin del equipo por instalar, en operacin, en almacenamiento y con necesidades
de reparacin.
La estimacin del tiempo de uso de equipo.
La vida proyectada del equipo.
La localizacin fsica del equipo.
La persona, departamento responsable del equipo.
El status financiero del equipo: propio, rentado o en arrendamiento con opcin de compra.
Una vez que se define el equipo disponible, se apoya an ms el proceso de toma de decisiones,
cuando llegue el momento de revisar el equipo requerido, ya que muchas de las dudas existentes acerca del
equipo existente se eliminaran.
Estimacin de la carga de trabajo:
El siguiente paso para definir las necesidades de equipo es estimar la carga de trabajo, esto significa
que los analistas de sistemas formulen el numero que represente, tanto la carga del trabajo actual como la
proyectada para el sistema, de tal forma que cualquier equipo que se adquiera cuente con la posibilidad de
manejar las cargas de trabajo actuales y futuras.
Evaluacin del equipo de cmputo o hardware:
La evaluacin del equipo de cmputo es una responsabilidad compartida entre la direccin, los usuarios
y los analistas de sistemas, aunque los vendedores le darn todo tipo de detalles acerca de sus ofertas
particulares, los analistas necesitan supervisar de manera personal el proceso de evaluacin, ya que ellos
tendrn el mayor inters en la empresa. Adems el analista puede orientar a los usuarios y a la directiva acerca
de las ventajas y desventajas del equipo antes que ellos puedan desarrollar tal capacidad, con base en el
inventario del equipo de computo actual y de estimados adecuados de las cargas de trabajo actuales y futuras.

123

Tamao y uso de las computadoras:
El vertiginoso avance de la tecnologa obliga al analista de sistemas a estudiar los distintos tipos de
computadoras disponibles en el momento en que se escribe la propuesta de sistemas, por ello es que mas que
profundizar en modelos especficos de computadoras, daremos una revisin de carcter general de las
dimensiones disponibles de las computadoras, el tamao de las computadoras abarca desde las computadoras
personales porttiles mas pequeas hasta las supercomputadoras del tamao de una habitacin, cada una de
ellas cuenta con distintas caractersticas al considerar la manera de implantar un sistema de computo.
Dispositivos de almacenamiento de datos:
El almacenamiento de datos, ya sea antes o despus del proceso, es sumamente importante para
mejorar el funcionamiento y el costo del sistema, en general, la eleccin de un medio de almacenamiento se
determina por el tipo de proceso, dentro de las preguntas fundamentales se tienen cuantos datos y por cuanto
tiempo sern conservados hasta su proceso, que tan grandes son los archivos y que tipo de acceso se
necesitar para los datos almacenados. 9
5.1 Comparacin de Fuentes de Abastecimiento
Algunos de los factores mas influyentes a considerar para la decisin de que opcin es la mejor para
una instalacin particular, incluye los costos iniciales contra los cos costos a largo plazo, si el negocio puede
afrontar el atar capital al equipo de computo y si el negocio desea control completo y la responsabilidad del
equipo e computo.
La compra implica que el negocio mismo es propietario del equipo:
Una de las primeras determinantes para comprar es la vida proyectada del sistema, si el sistema ser
usado mas de cuatro o cinco aos (mantenindose constante los dems factores), la decisin que
generalmente se toma es la de compra. El arrendamiento financiero, en vez de la compra, de hardware
computacional es otra posibilidad, el arrendamiento de equipo de parte del vendedor o de una compaa de
arrendamiento de terceros es mas practica cuando la vida proyectada del sistema es menor de cuatro aos,
adems si es inminente un cambio significativo de tecnologa, el arrendamiento es una alternativa mejor.

9 KENDALL & KENDALL, Anlisis y diseo de sistemas, 2 ed., Mxico, Pretince Hall, 1991, Pag. 400-408.

124

El arrendamiento tambin permite al negocio poner su dinero en cualquier otro lugar en donde pueda
estar trabajando para la compaa, en vez de estar atado a capital de equipo, sin embargo, a la larga el
arrendamiento no es una forma econmica para la adquisicin de poder de cmputo. La renta de equipo de
hardware computacional es la tercera opcin principal para la adquisicin de computadoras, una de las
principales ventajas de la renta es que no esta atada a ningn capital de la compaa, por lo tanto, no se
requiere financiamiento.
Tambin la renta de hardware computacional facilita el cambio del hardware del sistema, por ltimo, el
mantenimiento y seguros estn, por lo general, incluidos en los acuerdos de renta. Sin embargo, debido a los
altos costos involucrados y al hecho de que la compaa no poseer el equipo rentado, la renta debe ser
contemplada solamente como una maniobra a corto plazo para manejar necesidades de cmputo no
recurrentes o limitadas a tiempos tecnolgicamente voltiles.
5.2 El Servicio
Organizaciones y personal destinado a cuidar inters o satisfacer necesidades referentes a la
adquisicin de equipos. A travs de sus funciones o prestaciones desempeadas por estas organizaciones y su
personal. Considerando que la mayora de las casas comerciales ofrecen la prueba del equipo al recibirlo y una
garanta de 90 das contra cualquier defecto de fbrica, los establecimientos de prestigio se distinguen sobre
sus competidores por la gama de servicios que ofrecen.
Los servicios de soporte incluyen el mantenimiento rutinario y preventivo del equipo; el tiempo de
respuesta queda especificado si el equipo llegara a fallar (dentro de las primeras 6 horas; al siguiente da hbil,
etc.); el prstamo de equipo en caso de que el equipo deba cambiarse o si fuera necesaria una reparacin
externa y la capacitacin interna o a la organizacin de seminarios externos para grupos de usuarios.
5.3 Evaluacin y Seleccin
Qu debemos evaluar para seleccionar un equipo?
En primer lugar, la arquitectura del equipo que analizamos, esto implica evaluar cual es la arquitectura
que mejor se adapta para el procesamiento de las aplicaciones que pensamos desarrollar en nuestro futuro
equipo, debemos evaluar la filosofa con que fue construida la computadora y la orientacin tcnica de sus
componentes, en relacin con el tipo de procesamiento para el que fue pensado originalmente. Segn la
filosofa de su construccin, el procesamiento puede ser: centralizado, descentralizado o distribuido, y de
acuerdo a la envergadura de algunas compaas, una mezcla e ellos. Cada una de estas filosofas apunta a
resolver los distintos problemas que puede enfrentar una Empresa, en relacin con el procesamiento de datos,
y a su vez, contemplan las pautas polticas con que cada Empresa encara la resolucin de sus problemas.

125

Como vemos, los equipos de computacin abarcan un amplio espectro en lo que hace a la
problemtica empresarial, y esto es as, porque de esta forma los proveedores de equipos se aseguran una
mayor penetracin en el mercado. Cada filosofa establece un diseo o arquitectura de construccin de cada
dispositivo de la "maquina", y es en funcin de esas pautas que se determinan el tamao, capacidad, velocidad,
etc., de cada componente del sistema.
Por lo expuesto, resulta imprescindible el conocimiento del "problema" de la Empresa, antes de iniciar
la evaluacin tcnica que permita definir la filosofa, arquitectura y tipo de procesamiento a emplear. Por tal
motivo, ser necesario conocer y comprender las particularidades del "Negocio" de la Empresa, que adems
evitara desvos en la caracterizacin de sus problemas por consideraciones de tipo terico fuera de su contexto,
por otra parte, se debern analizar los motivos por los cuales la Empresa decide invertir en equipos de
computacin. Estos pueden ser:
Por encontrarse en etapa de expansin
Por prever una futura etapa de expansin
Por encontrarse en etapa de recesin (Necesidad critica de reducir costos)
En los dos primeros casos, el desarrollo de sistemas esta ligado al desarrollo de la Empresa, por tal
motivo, invierte en computacin. En el tercer caso, la inversin en computacin forma parte de un "Plan de
Austeridad" y entonces, solo el ahorro inmediato justifica la misma. Puede observarse que, en cada caso, las
restricciones sobre el proyecto actan de manera diferente, y son un condicionante crtico tanto para definir la
configuracin, como para dimensionar la instalacin, si bien en los tres casos estamos frente a un "Estudio de
Factibilidad para incorporar un computador".
Generalmente, suele pensarse que el diseo de la configuracin de una instalacin solo depende del
volumen de informacin a procesar, y que una vez cuantificada esta variable el responsable del proyecto decide
cuantas terminales, impresoras, etc., necesita. Sin lugar a dudas, esto es un grave error, dado que el volumen
de la informacin, como parmetro, incide en la evaluacin de las velocidades de cada dispositivo y en la forma
de almacenamiento de los datos, pero no determina el diseo de la configuracin, que necesariamente estar
condicionada a las polticas que encuadran al proyecto.
Como hemos visto, la configuracin debe contemplar los aspectos polticos que la condicionan, los
volmenes, las velocidades y capacidad de los dispositivos, y finalmente los aspectos tcnicos referidos al
hardware y software. La complejidad que presenta la evaluacin de un proyecto de inversin como la toma de
un computador, impone la utilizacin de una metodologa que establezca una disciplina de trabajo que permita
el planeamiento y control del proyecto, facilite la asignacin de tareas y mejorar las estimaciones, y en definitiva
nos permita reducir el riesgo.

126

VI. ADQUISICION DE LOS PROGRAMAS
En esta etapa se debe evaluar la funcin y el rendimiento que se asignaron al software durante la
ingeniera del sistema de computadora para establecer un mbito de proyecto que no sea ambiguo e
incomprensible para directivos y tcnicos. Describe la funcin, el rendimiento, las restricciones, las interfaces y
la fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan para dar mas detalles antes del
comienzo de la estimacin. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y
procesamiento, identifican los lmites del software originados por el hardware externo, por la memoria disponible
y por otros sistemas existentes. El mbito se define como un pre-requisito para la estimacin y existen algunos
elementos que se deben tomar en cuenta como es:
La obtencin de la informacin necesaria para el software, para esto el analista y el cliente se renen
sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo
Una vez que conozcamos los requerimientos de los sistemas que vamos a desarrollar, debemos hacer
una comparacin entre todos los paquetes que cumplen con las condiciones que requerimos y as elegir
el ms apto.
Preguntas que debo hacerme en cuanto a requerimientos de software:
Qu transacciones y que tipos de datos vamos a manejar?
Qu reportes o salidas debe producir el sistema?
Qu archivos y bases de datos se manejan en el sistema?
Cul es el volumen de datos a almacenar?
Cul es el volumen de operaciones?
Qu hardware y caractersticas de comunicaciones se requiere?
Cunto cuesta?
6.1 Comparacin de Fuentes de Abastecimiento
El software comercial debe ser evaluado a partir de demostraciones con datos de la empresa; as
mismo, examinar la documentacin que le acompae, una mera descripcin del vendedor no ser suficiente,
normalmente el vendedor le asegura que el software funciona que ha sido probado en sus instalaciones, pero
eso no garantiza que este libre de errores en un momento dado o que no fallar cuando se lleven a cabo las
acciones incorrectas por parte de los usuarios.

127

La necesidad de copias mltiples del software, implica negociar con el vendedor una licencia de uso
mltiple, de tal forma que los derechos del autor no se infrinjan al crear copias ilegales, con frecuencia esto
implica la compra de un paquete de software al precio regular y la compra de copias adicionales a un precio
reducido. Tambin es posible negociar un contrato de servicios especiales que cubra el soporte del software
adquirido, dentro de el quedara incluido el mantenimiento de emergencia y el preventivo; las actualizaciones
sin costo o aun precio reducido, las copias adicionales de la documentacin y la capacitacin de los usuarios.
6.2 Servicio Externo contra Servicio Interno
La contratacin de un servicio de computacin no difiere, en sus aspectos formales, de la contratacin
de cualquier otro tipo de servicio, por parte de una empresa. En nuestro caso corresponder la evaluacin
tcnica del tipo de servicio a contratar para el procesamiento electrnico de datos, y en particular la contratacin
de un servicio de computacin. Es importante considerar que es esta una alternativa para resolver el
procesamiento de la informacin de una empresa, dependiendo de la relacin costo-beneficio y, una vez ms,
la poltica que define la empresa para la resolucin de sus problemas.
Contratacin externa de servicios de informacin

El costo del desarrollo y la implementacin de aplicaciones es alto. El desarrollo, el respaldo y la
operacin son componentes costosos, y un personal experimentado es esencial. Una de las principales razones
del alto costo es la complejidad de los sistemas el cual requiere el uso de tecnologa sofisticada y respaldo
sumamente capacitado. Mientras que en aplicaciones de otros sectores empresariales la tecnologa da
respuesta a las necesidades de los usuarios con productos de mercado o relativamente simples, las
aplicaciones deben centrarse en tecnologa de informacin compleja que puede requerir diversas soluciones y
plataformas de diferentes proveedores.

Para satisfacer las metas de los sistemas y los objetivos bsicos, los administradores deben enfrentarse
con el cambio, administrar la complejidad y hallar trabajadores capacitados. En este punto es donde se observa
que la contratacin externa mejora enormemente la eficiencia para el desarrollo y la operacin de los sistemas
de informacin. Las compaas que han optado por contratos externos, citan varias metas claves:

Reducir costos de operacin
Compartir los riesgos con el socio contratado
Acceder a caractersticas de vanguardia a travs de la experiencia de los Proveedores
Limitarse a su competencia interna.

128

La contratacin externa permite a muchas empresas concentrarse en las reas de su competencia, en
el desarrollo de productos y en otros elementos relacionados ms directamente con la prestacin de servicios o
la generacin de ingresos. En realidad, las operaciones, se manejan con contratos externos con mayor
frecuencia que cualquier otro tipo de operacin empresarial.

Razones para la contratacin externa:

Falta de personal capacitado: Debido a la complejidad y a las exigencias de proyectos de la mayora
de las empresas que han agotado la capacidad de sus recursos internos. Los sistemas actuales exigen
conocimientos tcnicos inditos del personal que, con frecuencia, no pueden ser satisfechos por el
personal actual Esto resulta en esfuerzos constantes de capacitacin, retrasos en el progreso de
proyectos, o costos ms elevados como consecuencia de la contratacin y el uso de consultores
externos. Anteriormente, los proyectos para el desarrollo de aplicaciones se mantenan generalmente
en el mbito interno. Sin embargo, en la actualidad, las empresas con frecuencia se enfrentan con la
falta de los conocimientos tcnicos adecuados o la capacidad para satisfacer sus requisitos de producir
aplicaciones a tiempo, y por esta razn recurren a la contratacin externa, para el desarrollo de
sistemas de informacin.
Convertir sistemas antiguos a nuevos sistemas: Los sistemas desactualizados constituyen a
menudo una barrera en el soporte de sistemas de atencin dados los costos implcitos y los tiempos
prolongados de los ciclos de implementacin, no obstante, con la metodologa correcta, estos sistemas
pueden transformarse en un punto de lanzamiento para reducir el costo y el tiempo de las iniciativas de
desarrollo.
Optimizar las capacidades: Es necesario mejorar los sistemas y procedimientos desactualizados para
hacer frente a la demanda real de las empresas.
Compartir el riesgo de implementacin: La contratacin externa es una oportunidad para compartir
los riesgos del proyecto con el proveedor de servicios subcontratados.

129

Factores de xito en la contratacin externa:

Siempre hay riesgos cuando se recurre a la contratacin externa. Para evitar posibles problemas y
aumentar las perspectivas de un proyecto satisfactorio de contratacin externa deben considerarse algunos
temas importantes, entre otros los siguientes:

Seleccionar los servicios que se subcontratarn: Definir, establecer y observar un proceso de planificacin
para el proyecto de contratacin externa. Considere el tiempo para la diligencia debida y seleccione un grupo
diversificado de profesionales de la organizacin para preparar un informe de evaluacin sobre los requisitos de
la empresa, que especifique las reas que sern objeto de la contratacin externa en sintona con los planes y
las prioridades de la misma.

Seleccionar el proveedor de servicios: La seleccin de un proveedor de servicios para la contratacin
externa es crucial. Los trminos y las condiciones del contrato deben considerarse cuidadosamente con
anterioridad a la firma de cualquier convenio, la organizacin que contrata externamente debe estar preparada
para supervisar, ponderar, y administrar los resultados de la contratacin externa. La meta principal de la
mayora de los proveedores de servicios es aumentar sus ingresos, y la manera para alcanzar esta meta es
vender sistemas nuevos grandes o servicios ampliados a los clientes, en lugar de ampliar aplicaciones
existentes. Los proveedores tambin ofrecen servicios mediante alianzas con otros distribuidores, lo cual
puede no constituir la opcin ms interesante para los clientes:

Liderazgo: El liderazgo es un tema importante para la prestacin satisfactoria y se recomienda en gran medida
la existencia de un lder en la organizacin contratante con experiencia acerca del proceso de contratacin.

Elegir un equipo comprometido y competente para la implantacin: Se debe formar un equipo para
supervisar el proyecto de contratacin externa al comienzo del proceso con la combinacin correcta de usuarios
y profesionales tcnicos, es tambin importante obtener la promesa de los gerentes para que se asignen estas
personas, algunas veces de tiempo completo, al equipo del proyecto.

Establecer reuniones para informes de progreso y anlisis de los puntos crticos del proyecto: Son
imprescindibles las revisiones frecuentes al plan del proyecto por medio de entrevistas y participacin del
equipo de implementacin durante el proceso de seleccin. Los canales de comunicacin entre el equipo de
implementacin y la administracin siempre deben estar abiertos para el anlisis de problemas imprevisibles
durante el perodo de implementacin. Los gerentes necesitan supervisar las actividades, comprobar que estn
aplicndose los convenios y el cronograma de implementacin y proporcionar los recursos necesarios al equipo
para llevar adelante su tarea de la manera ms dinmica.

130

Instruccin del equipo de gestin de proyectos y los usuarios: Reconocer las inquietudes y las dudas que
trae aparejada la contratacin externa y disponer de una estrategia para tratar los complejos temas relativos al
personal, que caractersticamente ocurren en toda implementacin. La comunicacin interpersonal deficiente y
la falta de educacin de los usuarios en cuanto a los temas relacionados pueden imponer, y en efecto lo harn,
una carga en la contratacin externa. Es importante que el equipo del proyecto consiga apoyo de todos los
usuarios o clientes del sistema.

Respaldar la gestin para los proyectos: El apoyo de la gestin es vital para el xito de los proyectos. El
personal directivo superior debe considerar la implementacin como un proceso empresarial, esencial para la
asistencia el cual integra requisitos de informacin diferentes y modifica las tareas y las funciones de gestin y
cotidianas con el objetivo de mejorar el desempeo operativo.

Establecer metas realistas para los proveedores: Deben evitarse proveedores que ofrecen soluciones
rpidas a problemas de largo plazo. Establezca plazos realistas para la finalizacin de tareas complejas. Se
requiere tiempo para que una entidad externa comprenda ntegramente las caractersticas empresariales de
una institucin, establezca operaciones e introduzca procesos. Los proyectos complejos necesitan tiempo.

Realizar pruebas frecuentes durante el desarrollo o el mantenimiento de una aplicacin: Las instituciones
deben garantizar que un equipo interno realice una prueba meticulosa de las aplicaciones contratadas
externamente. El proyecto para el desarrollo o el mantenimiento de sistemas a travs de contratacin externa
debe estar libre de errores y ser funcionalmente completo. Deben observarse los parmetros definidos durante
la fase de implementacin y el sistema debe integrarse eficazmente con otros sistemas en la empresa y
desempearse a niveles satisfactorios. Los proveedores subcontratados afrontan muchos de los mismos
problemas experimentados por sus clientes.

La escasez de trabajadores capacitados en un mercado sumamente competitivo ha ocasionado que
algunos proveedores exijan demasiado del personal en relacin con el nmero y la complejidad de los
proyectos asignados. En consecuencia, algunos clientes potenciales, especialmente aquellos con recursos
adecuados, con capacidad para concentrarse tanto en operaciones empresariales, pueden elegir la seguridad
relativa del desarrollo o el control interno de las operaciones. Algunos clientes tambin pueden vacilar en hacer
contratacin externa porque han odo casos de proveedores de servicios de contratacin externa que toman
demasiadas atribuciones que requieren el control total de los departamentos y ello genera problemas de
comunicacin que obstaculizan las operaciones de la empresa. A pesar de ello, un mercado en maduracin
significa que ms clientes saben lo que desean y necesitan, y ms proveedores estn decididos a contribuir al
logro de sus metas.

131

Contratacin de proveedores de servicios: Los proveedores tienen generalmente contratos de venta
estndar que garantizan la mxima proteccin, al tiempo que confieren mnima proteccin legal a la empresa.
Antes de firmar un contrato, debe lograrse un entendimiento acabado de sus trminos y condiciones.

Si es necesario, se modificar el contrato estndar, pero una combinacin de competencia legal y
tcnica es esencial para abordar enmiendas y modificaciones. Con el objetivo de evitar problemas y examinar el
desempeo del proveedor, se debe evitar que los contratos de servicios queden fijados a un proveedor que
presente mal desempeo.

Se deben favorecer los contratos a corto plazo con clusulas de extensin en vez de contratos a largo plazo
que aten a la institucin con un proveedor determinado. Algunas de las medidas que se deben tomar antes de
firmar un contrato son las siguientes:

Contratar o asignar personal interno para formar parte de un equipo de administracin de Contratos
Resistir la presin de los proveedores para contratos a ms largo plazo
Asegurar que el nivel ms alto de la administracin est de acuerdo con el contrato externo y preparado
para evaluar los resultados previstos, las limitaciones, los productos y la repercusin del proyecto.

El proceso de negociacin: El proceso de negociacin debe aclarar la finalidad y los lmites de cada elemento
en el contrato. Cuando se negocia un contrato, el equipo debe enumerar explcitamente los elementos
prioritarios que es preciso abordar. Una lista de verificacin de los temas por tratar debe incluir los principales
objetivos del contrato, como son los parmetros para los criterios de aceptacin, las garantas de
mantenimiento, los lmites de costos para los cargos de los proveedores y las normas para la entrega en
funcin del tiempo, la cantidad y la calidad. La lista incluir manuales de documentacin, trminos de pago,
normas de desempeo, tareas correctivas para el software o el equipo, cobertura de equipo y software en el
contrato en el caso de que el vendedor quiebre, y causales para la cancelacin del contrato. He aqu varios
puntos importantes que exigen especificacin en todo contrato para sistemas disponibles en el mercado,
adaptados, o diseados a medida:

Cambios: El contrato debe especificar si la empresa o el contratista puede cambiar las especificaciones de los
sistemas, las autorizaciones requeridas a tal fin, las tasas de reembolso al contratista para el trabajo autorizado
adicional y los resultados de cualquier repercusin en los plazos, las fechas o los cronogramas.

Controversias: El contrato incluir disposiciones para resolver las diferencias en el contrato el proceso de
mediacin, la persona autorizada legalmente para resolver el problema y las soluciones a las que tiene acceso
cada parte.

132

Incumplimiento: Se detallarn cuidadosamente las condiciones que constituyen incumplimiento por cualquiera
de las partes, y las soluciones disponibles para la otra parte se determinarn claramente. La declaracin debe
incluir la responsabilidad especfica por los costos incurridos como resultado del incumplimiento.

Derechos a los datos tcnicos y al desarrollo: El contrato debe especificar quin conserva los derechos a los
datos tcnicos, los productos, los documentos o los desarrollos que surjan del cumplimiento del contrato. La
empresa debe prever razonablemente conservar algn inters en tales desarrollos, si lo desea; por el contrario,
no debe prever el acceso a derechos sobre los datos tcnicos o los desarrollos de los contratistas realizados
fuera de la vigencia del contrato. El contrato especificar si la empresa, el proveedor o ambos conservan la
propiedad del sistema despus de la finalizacin.

Aceptacin: Quizs la clusula contractual ms importante para ambas partes es una descripcin clara de lo
que constituye la aceptacin de los resultados intermedios y finales de la iniciativa contractual. Esta
especificacin debe incluir la capacidad del sistema, los cronogramas y las condiciones formales para la
aceptacin.

Autorizaciones: El contrato determinar quin est autorizado a comprometer a cada una de las partes al
contrato y quin autorizar modificaciones o agregados.

Garanta, mantenimiento y modificacin: El contrato establecer claramente si el proveedor proporcionar
alguna garanta para el sistema y su operacin, el lmite de tiempo en la garanta y cualesquiera limitaciones o
exclusiones. Tambin debe incluir clusulas en lo referente a las disposiciones para el mantenimiento y la
modificacin del sistema durante y despus del perodo de garanta.

Negociaciones de contratos: Las negociaciones de contratos se prepararn cuidadosamente, asegurndose
de que se consideren todos los puntos pertinentes. Algunas de las medidas que conviene tomar con
anterioridad a las negociaciones son las siguientes:
Nombrar a negociadores para el contrato (administradores, gerentes, personal tcnico y contable,
representante legal) y determinar los niveles de autoridad y responsabilidad.
Contratar, si es necesario, a un experto externo para ayudar a la organizacin a tomar la decisin
apropiada para esta tarea tan crucial.
Determinar el tipo de contrato que se va a negociar (es decir, precio fijo, reembolso costos, tiempo y
materiales, o una combinacin).
Determinar las reas flexibles que se pueden negociar y las que se definirn inflexiblemente.
Aclarar la terminologa utilizada en el contrato.
Definir las responsabilidades de la institucin de atencin de salud y las del proveedor para la
evaluacin de los requisitos y el diseo, el desarrollo y la implementacin de los sistemas.

133

Determinar y definir los componentes del contrato:

a) Especificaciones bsicas del sistema
b) Fiabilidad y mantenimiento
c) Otros servicios de los proveedores
d) Trminos de aceptacin
e) Costos y condiciones de pago
f) Entrega
g) Derechos de los usuarios
h) Opciones de los usuarios
i) Proteccin de precios
j) Daos o sanciones
k) Otras disposiciones.

Componentes de un contrato para sistema de informacin:

Lista de trminos o glosario: Enumeracin y explicacin de los principales trminos tcnicos.

Especificaciones bsicas del sistema: Configuracin de equipos, configuracin de software, normas de
desempeo para los componentes, normas de desempeo para el sistema, garantas de compatibilidad de los
componentes (interoperabilidad), alteraciones y anexos, clusulas de seguridad y confidencialidad.

Fiabilidad y mantenimiento - Parmetros que se utilizaran, garantas, reemplazo, costos de reemplazo,
informes sobre mal funcionamiento, lugares autorizados para mantenimiento, crdito para mantenimiento,
equipo poco fiable, equipo de urgencia, tiempos de respuesta, disponibilidad ininterrumpida.

Otros servicios de los proveedores: Apoyo y asistencia, con inclusin de: desarrollo o modificacin de
software, diseo de bases de datos, documentos adjuntos, diseo, conversin, planificacin de sitios,
instalacin, relaciones pblicas. Instruccin y capacitacin (programa de estudios, asignacin, garanta de
continuidad, disponibilidad de instructores, materiales, derechos a cursos futuros). Documentacin
(disponibilidad, derechos para la reproduccin, derechos de autor y proteccin de patentes, materiales futuros).
Tiempo de mquina para pruebas, desarrollo y uso de urgencia (cantidad, cronograma, ubicacin).

Trminos de la aceptacin: Pruebas de aceptacin, productos que se van a entregar: criterios para la
aceptacin de cada material entregado, firma de finalizacin.

134

Costos y condiciones de pago: Condiciones del acuerdo por tipo de costo especfico, mtodo de pago,
condiciones para el no pago, impuestos, cargos y mtodo de cobro del tiempo extra y trabajo en das feriados,
mantenimiento, transporte, reubicacin, seguro, suministros.

Entrega: Fechas de entrega, opciones para la entrega temprana, retrasos, responsabilidad por la instalacin,
responsabilidad por la preparacin de sitios, daos a los equipos, software y el sitio durante la entrega,
reubicacin y devolucin del equipo.

Derechos de los usuarios: Uso y funcin del sistema, ubicacin del sistema, cancelacin de componentes,
sustitucin de componentes, cambios y anexos, actualizacin de equipos o software, derechos a los datos
tcnicos.

Opciones de usuarios: - Compra, alquiler, crdito por alquiler, cambio, transferencia de ttulo, opcin a la
actualizacin, disponibilidad de unidades para ampliacin, fuentes alternativas.

Proteccin de precios: Antes de la entrega, durante el trmino del contrato, mejoramiento y ampliacin,
mantenimiento, suministros y servicios.

Daos o sanciones: Incumplimiento antes de la entrega, despus de la entrega y durante el desarrollo,
incluidos daos, costos de usuarios e incumplimiento con consentimiento

Otras disposiciones

Lista de verificacin de las disposiciones esenciales del contrato: Las disposiciones del contrato
necesariamente deben incluir, entre otros elementos:

Duracin, Riesgo compartido, Desempeo, Acceso a toda la capacidad del proveedor, Compromisos de capital
para adquirir establecimientos, equipos o tecnologa, incluidos activos actualmente propiedad de la empresa
segn sea necesario, Entrega, Aceptacin del sistema, Documentacin, Derechos a los programa,
Capacitacin del personal, Instalaciones del usuario, Equipo para copias de seguridad, Garantas, Seguro,
Temas de confidencialidad y divulgacin, Acceso de los distribuidores/proveedores a las instalaciones y
documentos institucionales de los clientes, Mantenimiento, Arbitraje, Proteccin de trasgresin, Actualizaciones,
Disposiciones contractuales especiales, Garantas de software, Apoyo al mantenimiento, Garanta de fiabilidad,
Clusula de nueva produccin, Opcin de renovacin, Clusula de terminacin

135

Cmo evitar problemas en la contratacin externa:

Una vez que una empresa determina la mejor asignacin de recursos internos, los analistas recurren a
la cautela para seguir adelante con un convenio de contratacin externa. Es imperativo llegar a la mesa de
negociaciones con solicitudes bien definidas de referencias de clientes satisfechos. Los proveedores de
contratacin externa tienen que demostrar una trayectoria de desempeo en proyectos dentro de los tiempos
revistos y de acuerdo con el presupuesto planeado. Por otra parte, antes de firmar un contrato los
administradores deben especificar exactamente a los posibles socios de contratacin externa quin responder
a quien y cundo.

Tambin se especificarn los convenios a nivel de servicios, incluidos los puntos de referencia para
calidad y experiencia del personal que trabajar en el proyecto. Muchos proveedores iniciarn un proyecto con
personal de nivel tcnico superior, solo para retirarlos para asignarlos a su siguiente contrato, dejando como
personal efectivo a miembros auxiliares del personal que no pueden desempearse al mismo nivel. Los
proveedores de servicios deben estar preparados para aceptar un traspi financiero ante el incumplimiento de
contratos. Las sanciones deben asociarse con el bajo rendimiento a largo plazo. No negocie un contrato basado
en los procesos existentes y estructure los contratos considerando un horizonte de tres a cinco aos.

Para los administradores sin experiencia en la proyeccin de sus necesidades, es aconsejable contratar
a un consultor externo acreditado. Dado que la empresa de contratacin externa podra fusionarse con otra
firma o adquirir otra compaa y dado que los avances de la tecnologa podran determinar nuevas inversiones,
se recomienda la negociacin de trminos de renegociacin de contratos y temas centrales del proyecto. Se
deben tener en cuenta las polticas monopolizadoras de fijacin de precios y los proveedores que exigieron el
control total para llegar a la economa de escala. Prcticamente todo contrato implica riesgos. No obstante,
existen unas cuantas reglas o principios esenciales que las instituciones pueden seguir cuando se estructura
una contratacin externa para evitar problemas posteriormente, entre otros:

Realice un plan de contratacin externa en el contexto del plan general de la empresa: Investigue las
necesidades reales de la misma y solo contrate externamente los proyectos que no pueden realizarse
internamente. Los proveedores de servicios externos deben estar en condiciones de finalizar un proyecto de
manera ms rpida y en mejores condiciones que si fuese realizado internamente.

Las empresas deben ser selectivas al cursar invitaciones a los proveedores de servicios para licitar
contrato: Antes de redactar una solicitud de propuestas, prepare una solicitud de informacin a fin de
investigar a los proveedores con experiencia, conocimiento y recursos adecuados para manejar un contrato,
solo a los ms capacitados se los invitar a licitar en respuesta a la solicitud de propuesta.

136

Las empresas deben ser cautelosas con los proveedores de servicios que prometen soluciones rpidas
a problemas a largo plazo: El equipo de evaluacin debe realizar una evaluacin minuciosa del proveedor
para evitar problemas futuros.

No debe seleccionarse a los distribuidores, consultores y proveedores de servicios solamente sobre la
base del precio: Reconozca que los proveedores que contratan los mejores profesionales y dedican ms
recursos al contrato pueden costar ms que los proveedores que desean sencillamente obtener un contrato.

Elija mltiples proveedores, si fuera necesario: Los proveedores de servicios, consultores y proveedores se
especializan en diferentes reas. Un contrato total con un vendedor puede ser riesgoso si el vendedor no se
encuentra a la vanguardia de los servicios requeridos. La especializacin ayuda a los clientes a obtener los
proveedores ms competentes de acuerdo con las necesidades.

Evite firmar contratos de larga duracin: Deben establecer contratos a corto plazo con clusulas de
extensin para evitar comprometerse con todo un contrato con un proveedor que, con el tiempo, podr tener un
desempeo deficiente.

Presente una descripcin clara e integral del alcance de los servicios requeridos: Cuanto ms clara e
integral es la definicin del alcance de los servicios, ms fcil ser para el proveedor comprender y realizar las
tareas comprendidas en un contrato.

Establezca canales de comunicacin eficaces y sin obstculos entre la administracin, el equipo del
proyecto y el proveedor de servicios: Deben prepararse peridicamente informes de progreso para informar
sobre los problemas, las soluciones y las mejoras y para comprobar que se est observando el cronograma
adecuado.
El proceso de innovacin tecnolgica de recursos computacionales:
El costo total de los departamentos de Informtica en las empresas est constituido por varios renglones.
Una gran parte de este costo se encamina a la adquisicin o desarrollo de programas de aplicacin que
resuelven problemas funcionales a los usuarios. Otra parte importante del costo se relacione con la operacin
de los sistemas computacionales. Otro rengln importante de costos est relacionado directamente con los
recursos de hardware y equipo que deben adquirirse para desarrollar y operar los Sistemas de Informacin.
Esta ltima decisin es una de las ms costosas e importantes a la que se enfrenta el administrador y est
relacionada con la tecnologa de informacin de naturaleza diversa.

137

Las decisiones relacionadas con la adquisicin de recursos computacionales debern hacerse
considerando factores tecnolgicos, tcnicos y financieros. No obstante lo anterior, no existen procedimientos
completos que guen a los administradores de la informtica durante todo el proceso de cambio de equipo, el
cual se inicia con la determinacin de los requerimientos de cmputo, hasta la administracin de la conversin
de programas y la transicin y traslado de datos al nuevo sistema computacional.
Con mucha frecuencia el no conocer la forma de obtener los recursos de hardware, software y servicios
de informacin puede resultar en diferimiento indefinido del uso, o peor, en la inadecuada seleccin y compra
de los sistemas incorrectos. Normalmente el director o gerente de informtica de las empresas, apoyndose en
los departamentos de soporte tcnico, operaciones y/o desarrollo de sistemas de aplicaciones quien coordina el
proceso de cambio de equipo computacional. Adems se requiere que le usuario de las diferentes reas que
integran la empresa se involucre durante el proceso de cambio de equipo. Es importante conocer los sntomas
que se observan en las empresas y que constituyen un detonante para el proceso de cambio de equipo, a fin de
que el administrador de los recursos de hardware se prepare para el manejo del proyecto.
Estas causas pueden incluir las siguientes:
Problemas de servicio con el proveedor actual: Esto se refiere a que la empresa no est obteniendo el
servicio que esperaba, por ejemplo: la empresa necesita que se le d mantenimiento al equipo actual y el
proveedor no cumple con la fecha indicada para ello y por eso desea cambiar de proveedor y de equipo.
El equipo computacional actual es obsoleto: La empresa no se ha actualizado en lo que se refiere a compra
de equipo computacional.
Saturacin y falta de capacidad del equipo computacional: El equipo ya no es suficiente para hacer frente a
las necesidades de tecnologa de informacin.
Necesidad de incorporar nuevos sistemas de aplicacin: El medio ambiente lleva consigo la necesidad de
que la empresa utilice nuevos sistemas que requieran capacidades de equipo diferentes a las actuales y por
ello es necesario adquirir nuevo equipo.
El haber tomado una decisin equivocada durante el proceso de seleccin del equipo actual: Si las
decisiones referentes a la adquisicin de equipo computacional no han sido las adecuadas a las necesidades
de la organizacin, ser necesario adquirir nuevo equipo.
Cuando se tienen requerimientos de competitividad que no pueden ser alcanzados con la tecnologa
actual: En estos casos, para estar a la par con la competencia es necesario que la empresa adquiera nuevo
equipo.

138

Determinacin de requerimientos: La primera fase consta en determinar los requerimientos de nuevo equipo
que ser adquirido. Para lograr con xito lo anterior, es necesario llevar a cabo algunas actividades que se han
denominado previas a la aplicacin de la presente gua. Los especialistas en planeacin de las capacidades en
equipos de cmputo invierten una gran cantidad de tiempo y esfuerzo en crear a detalle modelos
computacionales altamente complejos, para determinar la configuracin que se aproxime mejor a las cargas de
trabajo futuras de la organizacin.
Actividades previas a la determinacin de requerimientos:
Conocimiento de la organizacin: El primer paso previo es tener un conocimiento profundo de la
organizacin que recibir el servicio del equipo que ser adquirido,. Por ejemplo, si el equipo va a ser adquirido
por una empresa que se dedica a la manufactura de bienes de consumo, el responsable del proyecto deber
conocer las reas de venta, administracin, mercadotecnia, produccin, finanzas y recursos humanos. El
conocimiento de la organizacin implica, por otra parte, conocer el plan general o estratgico del negocio. Este
plan en la mayora de las empresas es elaborado por los departamentos de finanzas y administracin, o bien,
por el rea de planeacin estratgica.
Plan de desarrollo de aplicaciones: El siguiente paso previo es contar con un plan de desarrollo de
aplicaciones a corto plazo. La idea en este punto consiste en conocer las aplicaciones que sern desarrolladas
durante el horizonte de planeacin del proyecto. El horizonte del, proyecto se define como el lapso de tiempo
futuro que se considera en un anlisis.
Filosofa de operacin o tipo de solucin requerida: El plan deber incluir aspectos tecnolgicos requeridos
para el desarrollo de las nuevas aplicaciones, tales como bases de datos, cdigos de barras, sistemas batch o
en lnea, ya que estas especificaciones pueden modificar de manera sensible los requerimientos y restricciones
a considerar en el nuevo equipo.

139

Figura 6.1 Modelo propuesto para estimar los requerimientos de equipo
Los recursos que deben estimarse durante esta fase del proceso incluyen los siguientes:
Capacidad de cmputo expresada
Capacidad de almacenamiento en memoria principal expresada Capacidad de almacenamiento
secundario expresada
Capacidad total de impresin requerida expresada
Cantidad de terminales requeridas para la captura o consulta de informacin, tales como terminales
inteligentes, concentradores, ruteadores, etctera.
Requerimientos obligatorios: Se definen como requerimientos obligatorios al conjunto de caractersticas
deben estar, de forma obligada y necesaria,. Ejemplos de stos podrn ser los siguientes:
El costo total del equipo o el presupuesto mximo autorizado
El tiempo mximo de entrega del equipo requerido
Compatibilidad con el lenguaje computacion1 actual
El apoyo del proveedor durante la conversin de las aplicaciones
Requerimientos opcionales: Los requerimientos opcionales constituyen el conjunto de caractersticas que
sern de gran ayuda y utilidad si se encuentran presentes en el equipo, no implica que la propuesta del
proveedor ser descartada.

140

La existencia de usuarios con configuraciones similares a la que se est proponiendo y que se
encuentren localidades geogrficas cercanas para tener un soporte mutuo. Disponibilidad de algn sistema de
aplicacin o paquete ya desarrollado para asegurar una implantacin rpida y exitosa. Alto grado de
satisfaccin de los usuarios actuales. La definicin adecuada de restricciones en el proceso de cambio de
equipo facilitar el trabajo durante la evaluacin tcnica y financiera de las propuestas, ya que solamente se
analizarn aquellas propuestas o soluciones que hayan cumplido con todos los requerimientos obligatorios.
Requerimientos futuros de las aplicaciones actuales (RFA): El clculo no considera situaciones que pueden
presentarse durante el horizonte de planeacin, como las siguientes, lo cual puede traer como consecuencia
desviaciones en el clculo:
Crecimiento del negocio por arriba o por debajo del porcentaje estimado
Fusiones o compra de nuevos negocios
Rediseo o cambios importantes en las aplicaciones actuales.
Requerimientos futuros de las nuevas aplicaciones (RFN): La manera de llevar a cabo lo anterior es
conocer las aplicaciones que van a ser desarrolladas durante el horizonte de planeacin, tal como se sugiere en
el plan de desarrollo de aplicaciones. Para cada una de las aplicaciones habr que elaborar un prediseo
estimando los volmenes requeridos de cada uno de los recursos. El valor o valores que se obtengan de este
anlisis, debern sumarse a los valores obtenidos en la seccin anterior, de tal forma que podamos estimar el
valor total de los requerimientos del nuevo equipo para cada uno de los recursos.
Evaluacin tcnica de las propuestas: La evaluacin tcnica de las propuestas es el proceso mediante el
cual el administrador del proyecto de cambio de equipo define y evala las caractersticas y los factores
tcnicos de los equipos a considerar, el resultado de esta evaluacin tcnica, sumado al resultado de la
evaluacin econmica y financiera, constituyen la plataforma de decisin del equipo y de la solucin a adquirir.
Elaboracin del RFP (Request For Proposal): La evaluacin tcnica de los equipos se facilita con la correcta
elaboracin de las propuestas por parte de los proveedores de soluciones. Una vez que se ha determinado la
estimacin de los requerimientos para el equipo nuevo que se va a adquirir, es necesario elaborar una solicitud
o requisicin de propuesta. La requisicin de propuesta (RFP) es un documento que define los requerimientos
de la organizacin para el equipo o la red, requerida por la organizacin.

141

El RFP, tiene varias funciones, entre las cuales se incluyen:
Sirve como una propuesta del sistema que invita a los proveedores a participar en el concurso
Establece los primeros puntos de evaluacin y negociacin entre los proveedores de soluciones
computacionales y la organizacin
Obliga al administrador del proyecto de cambio de equipo a formalizar el proceso de determinacin de
los requerimientos de equipo
Constituye un documento que describe claramente las prioridades tcnicas del sistema.
La estructura del R. F. P puede variar dependiendo de la naturaleza del proyecto de cambio de equipo
que se desarrollar. No obstante lo anterior, se recomienda incluir, entre otros los siguientes puntos:
Datos generales del responsable del proyecto
Fecha lmite para recibir la propuesta por parte del proveedor de equipo computacional que desea
concursar
Bases y lineamientos generales que sern utilizados para hacer la comparacin entre los diferentes
equipos
Breve descripcin de la situacin actual de la compaa y de la funcin de informtica dentro de la
empresa
Requerimientos del sistema computacional:
Requerimientos de equipo actual vs. el equipo propuesto
Requerimientos obligatorios y opcionales
Informacin ms detallada de las pruebas de benchmark o pruebas de rendimiento que sern
efectuadas a las soluciones propuestas que estarn concursando
Y en trminos generales deber incluirse toda la informacin relevante descrita en la seccin de
determinacin de los requerimientos
Formato de la propuesta que recibir a los proveedores concursantes: Es importante definir estndares de
la propuesta que se ha de recibir de los diferentes proveedores de soluciones, con el fin de facilitar la
evaluacin tcnica y financiera de estas propuestas y, por ende, de la decisin final. El formato de la propuesta
podr variar de una empresa a otra o dependiendo del problema especfico que deba ser resuelto utilizando la
tecnologa de la informacin. No obstante lo anterior, se incluye una lista de parmetros que pueden ser
incluidos en las propuestas que entregan los proveedores:
Sistema o solucin configurada: Este punto normalmente es presentado con un adecuado nivel de detalle
por la mayora de los proveedores. Es importante cerciorarse que incluya la descripcin tcnica detallada de la
solucin propuesta y las capacidades de crecimiento del sistema. Esta informacin debe incluir manuales
tcnicos de hardware configurado, as como diagramas esquemticos de la configuracin propuesta.

142

Requerimientos de instalacin: Los requerimientos de instalacin de los equipos pueden cambiar una
decisin determinada, ya que afecta el costo total de la solucin. Esta informacin debe incluir requerimientos
de:
Espacio fsico que ocupa el equipo
Instalaciones elctricas y equipos de reguladores de voltaje
Temperatura ambiental y equipos de refrigeracin
Requerimientos especiales tales como piso falso, equipo de control de humedad, por ejemplo, y en
general todos los requerimientos de instalacin de equipo.
Soporte de proveedor: Soporte del proveedor es tan importante como el producto dentro del cuadro global.
Desafortunadamente con frecuencia esto no se considera hasta despus de que el equipo ha sido adquirido. La
informacin que se requiere por parte del proveedor en este rengln incluye:
Soporte para el entrenamiento del personal en el nuevo equipo y calendario de cursos, incluyendo su
costo.
Personal de soporte para hardware, software y en general, para el mantenimiento del equipo
computacional.
Inventario de equipos de respaldo compatibles con el equipo configurado en la propuesta.
Apoyo y experiencia en la conversin de las aplicaciones y de los programas de aplicacin que han de
ser convertidos al nuevo equipo computacional.
Informacin de costos: En este punto se incluye toda la informacin econmica y financiera, comprende
precios, plazos de pago y opciones de compra disponibles por parte del proveedor, y en general, todos los
datos requeridos para desarrollar la evaluacin econmica del proyecto de inversin.
Condiciones del contrato: Las condiciones del contrato por lo general se especifican en formatos fijos que el
proveedor anexa en la mayora de las propuestas. Este formato es elaborado por el departamento legal de la
compaa.
Nivel o grado de cumplimiento de los requerimientos obligatorios y opcionales del cliente que tiene la
solucin presentada por el proveedor: Es importante insistir a los proveedores que esta informacin deber
incluirse en la propuesta entregada en forma expresa y por separado.
Abrir el concurso de proveedores Una vez que se elabor el RFP es necesario abrir formalmente el
concurso de los proveedores que deciden concursar o competir por el contrato. Durante esta fase del proceso
es importante elaborar un documento que contiene todas las especificaciones descritas antes y entregarlo
formalmente a cada uno de los proveedores.

143

Descartar propuestas: Se debe recordar que si la invitacin a los proveedores fu exhaustiva, es de esperarse
que la cantidad de propuestas recibidas tambin sea elevada. El anlisis y evaluacin de todas puede resultar
tardado y costoso.
Factores que deben evaluarse: La evaluacin tcnica de las propuestas debe realizarse exclusivamente sobre
las soluciones que cumplen al cien por ciento los requerimientos obligatorios y que cumplen mejor los
requerimientos opcionales.
Factores de hardware: Son las caractersticas relacionadas con los componentes fsicos de la computadora y
sus indicadores ms representativos, tienen que ver con las capacidades y velocidades de los diferentes
componentes. Estos componentes incluyen procesador, memoria RAM, discos, terminales, impresora, etc.
Factores de software: Software interno o software de sistemas, el cual se compone de programas de control,
incluyendo el sistema operativo, software de comunicaciones y administrador de bases de datos, adems
se-consideran paquetes especiales, tales como simuladores, anlisis financieros programacin lineal, control de
proyectos, anlisis estadsticos y paquetes que se enfocan a resolver problemas funcionales a los usuarios,
tales como contabilidad, cuentas por pagar, facturacin, entre otros. Finalmente, es importante destacar que en
la mayora de los casos el tiempo de vida til del software de aplicacin es superior al tiempo de vida til de las
plataformas de hardware.
Factores de proveedor: El tercer grupo de factores que se deben tomar en cuenta, durante la evaluacin
tcnica de la propuesta se refiere al proveedor. Un aspecto importante que debe considerar es la tendencia a
que mientras ms tiempo permanezca un cliente con un mismo proveedor, el servicio y soporte del proveedor
se decremento. Todo lo anterior, justifica la necesidad de analizar los posibles factores a considerar en relacin
al servicio y al proveedor.
Generalidades del proveedor: Las generalidades el proveedor es toda aquella informacin relacionada con la
imagen que tiene el proveedor en el mercado local, regional y mundial, considerando aspectos tcnicos,
mercadolgicos y financieros, de tal manera que aseguren la permanencia y continuidad del proveedor. Los
factores a evaluar incluyen:
Representacin mundial y regional del proveedor:
Tiempo de entrega del equipo ofertado y futuras ampliaciones
Profesionalismo y preparacin de los vendedores
Situacin econmica y financiera del proveedor
Calidad de la documentacin y manuales disponibles

144

Apoyo en la capacitacin: Brinda en la capacitacin al personal tcnico y usuarios en el uso de los recursos
de hardware y software propuestos. Estos factores incluyen:
Capacitacin al personal de las reas de investigacin y soporte tcnico
Capacitacin del rea de anlisis y programacin
Capacitacin a operadores
Capacitacin a usuarios
Es importante resaltar que los costos de capacitacin pueden variar de manera significativa de un
proveedor a otro, inclusive existen proveedores que no tienen disponibles los cursos dentro de la localidad en la
que ser instalado el equipo, situacin que modifica la estructura integral de costos de las diferentes
alternativas de equipo computacional.
Mantenimiento de hardware y software: El mantenimiento es otro de los factores cruciales a tomar en cuenta
durante la evaluacin tcnica de las propuestas, consiste bsicamente en la capacidad de un proveedor para
proporcionar un soporte y servicio adecuado, para asegurar el funcionamiento continuo e ininterrupcin del
sistema computacional. Algunos de los aspectos a considerar son los siguientes:
Calidad y cantidad de personal capacitado de tiempo completo disponible en hardware y software
Tiempo promedio que tarda el proveedor en atender las fallas reportadas Tiempo o porcentaje de
sistema funcionando
Tiempo promedio que el sistema permanece cado durante cada falla
Existencia de una bodega cercana con partes y repuestos para responder con mayor oportunidad a
fallas
Existencia de horario extendido, siete das a la semana y 24 horas diarias para atender fallas.
Equipos de respaldo: Los equipos de respaldo disponibles por parte el proveedor y otros usuarios constituyen
un aspecto a considerar durante la evaluacin de los proveedores. Pueden soportar la operacin de la empresa
del cliente durante fallas prolongadas. Algunos de estos factores pueden incluir:
Cantidad de equipos de respaldo existentes
Facilidad de trasladar procesos a los equipos de respaldo
Grado de satisfaccin de estos usuarios en relacin con el proveedor

145

Apoyo en la conversin de aplicaciones: Se refiere al apoyo que el proveedor puede proporcionar al cliente
durante el proceso de conversin y traslado de las aplicaciones y programas al nuevo equipo. Este factor
depender de la cantidad de programas que se convertirn a la nueva plataforma de hardware, como
consecuencia del cambio de equipo. Algunos conceptos a tomar en cuenta son los siguientes:
La experiencia que tiene el proveedor en el apoyo a otros clientes en conversiones similares a las
requeridas
Facilidad de iniciar la conversin de aplicaciones antes de la llegada de equipo, a fin de reducir el
tiempo y costo de la operacin paralela de ambo equipos
Mtodos de evaluacin tcnica de las propuestas:
Mtodo de mezcla de instrucciones: Para comparar velocidades de procesador de varios equipos se puede
escoger un conjunto de instrucciones representativas y ms utilizadas por los programas de usuario, la tcnica
consiste en sacar un promedio ponderado del tiempo de ejecucin de ellas.
Las desventajas del mtodo incluyen las siguientes:
Solamente se mide la velocidad del procesador, no se toma en cuenta espacio en disco, memoria RAM
o alguna otra caracterstica que puede influir posteriormente
La frecuencia en el uso de las instrucciones en los programas puede variar
Las instrucciones A, B, y C, pueden no hacer exactamente lo mismo en lo diferentes equipos
Mtodo de Kernel: Es un problema simple y representativo de las aplicaciones tpicas a computarizar en el
nuevo equipo y se mide el tiempo de ejecucin de esta aplicacin en cada uno de los equipos que se
comparan.
Las ventajas de este mtodo son:
Es ms completo, se utilizan ms instrucciones
Se toma un problema real y representativo del usuario
Las desventajas del mtodo son:
El Kernel escogido puede no ser representativo del resto de las aplicaciones del usuario
Es necesario generar una inversin del kernel para que corra en cada equipo que se desea comparar.
Esto puede resultar tardado y costoso.

146

Mtodo de simulacin: Consiste en hacer uno o varios programas utilizando tcnicas y lenguajes de
simulacin con el fin de imitar el funcionamiento de un sistema computacional. Se definen parmetros como
tiempo de ejecucin capacidad de memoria principal, acceso a dispositivos de entrada/salida demanda de
usuarios en terminales, entre otros, y se generan diferentes escenarios y corridas para cada uno de los equipos.
La gran ventaja de esta tcnica es que se pueden evaluar un gran nmero de escenarios diferentes en
poco tiempo. Sin embargo, existen pocas referencias recientes respecto al uso de este mtodo, por las
desventajas que presenta, entre las cuales se pueden mencionar:
El costo y tiempo de desarrollar o adquirir el modelo de simulacin
Los tiempos de ejecucin, y los resultados no son reales
Los resultados dependen en gran medida de los algoritmos de simulacin que se usen
Mtodo de Benchrnark: Este mtodo ha sido empleado para comparar el rendimiento de un programa de
aplicacin en diferentes plataformas de hardware o bien, comparar diferentes programas de aplicacin que
pueden correr en una misma plataforma de hardware. Se trata de escoger un conjunto de programas
representativos del usuario. Otra de sus ventajas es que utilizan tiempo y datos reales del usuario para apoyar
la decisin tcnica del equipo. La desventaja principal del mtodo es el esfuerzo en tiempo y recursos
econmicos que conlleva la conversin de una aplicacin del usuario a las diferentes plataformas de hardware
propuestas por los proveedores.
Mtodos de factores ponderados: Este mtodo se utiliza en la prctica, consiste en asignar un peso a cada
uno de los factores de hardware, software, calificar a cada equipo propuesto de acuerdo a la medida en que
cumple con el factor considerado. El equipo o la propuesta que obtiene el mayor puntaje se considera el
ganador.
Evaluacin financiera de las propuestas: La evaluacin financiera de las propuestas es el proceso mediante
el cual el administrador del proyecto de cambio de equipo define y evala las caractersticas y los factores
econmicos de los equipos que debe considerar la empresa. El resultado de esta evaluacin, sumando el
resultado de la evaluacin tcnica, constituye la plataforma de decisin del equipo y de la solucin que se
adquirir.

147

Alterativas de adquisicin y financiamiento:
Renta: La renta es el proceso por el cual el usuario toma en cuenta el equipo del proveedor por un perodo
definido como obligatorio. Al terminar este periodo suelen tenerse tres alternativas:
Cancelar el contrato y regresar el equipo al proveedor.
Renovar el periodo de renta, en cuyo caso es posible negociar con el proveedor de equipo un
descuento sustancial en la nueva renta. El monto del descuento depender de la duracin del periodo
anterior de renta y del nuevo que se negocia.
Ejercer la opcin de compra del equipo.
La renta de computadoras tiene algunas ventajas con respecto a otras alternativas de adquisicin de
equipo. Algunas de estas ventajas de presentan a continuacin:
No implica un desembolso inicial de dinero
El proveedor del equipo computacional es responsable de mantenerlo funcionando en buen estado
No es una opcin obligatoria para el usuario en el largo plazo, la opcin de renta puede ser ventajosa
en aquellos casos en los que no se tenga una completa seguridad del equipo o solucin requerida
Evita la obsolescencia y es ms fcil hacer un cambio de equipo posterior
La renta de computadoras presenta algunas desventajas:
La renta usualmente es ms costosa si el equipo seleccionado se empleara por un largo periodo
Las rentas estn sujetas a incremento por parte del proveedor
Compra: Una segunda opcin es la compra del equipo computacional.
Las ventajas que presenta la adquisicin de equipo son:
Es el mtodo ms barato cuando el equipo se requiere por periodos largos de tiempo
No existen incrementos en los pagos y las devaluaciones de la moneda no afectan los flujos del negocio
Se tiene un valor de recuperacin del equipo al final del periodo
Algunas desventajas de utilizar el mtodo de compra incluyen:
Es ms fcil llegar a tener un equipo obsoleto
Si la solucin adquirida no es la adecuada resulta el mtodo ms caro
Implica un desembolso fuerte de dinero con el problema del financiamiento
Se tiene incertidumbre en el valor de reventa del equipo

148

Arrendamiento financiero: Es una alternativa viable para la adquisicin de equipo computacional en la
mayora de los pases. Presenta algunas de las ventajas del esquema de renta, pero en el fondo se trata de una
compra. En la mayora de los casos la operacin se realiza a travs de un tercero que es la arrendadora, la cual
paga el equipo al proveedor y retiene la propiedad del equipo hasta que el usuario le liquide cada uno de los
pagos. Es usual que el usuario pague al proveedor mensualmente el mantenimiento del equipo.
Evaluacin econmica de las propuestas: Es el proceso mediante el cual se evalan econmicamente cada
una de las alternativas que presentan los proveedores. Los flujos positivos que pueden considerarse dentro de
la evaluacin del proyecto incluyen, entre otros:
Beneficios econmicos que se derivan del proyecto
Valor de rescate del equipo al final del horizonte de planeacin del proyecto
Beneficio en los impuestos
Los flujos negativos que pueden considerarse dentro de la evaluacin del proyecto incluyen, entre otros:
Pagos de renta
Gasto de conversin de las aplicaciones actuales
Mantenimiento de equipo
Seguros y fianzas
Gastos de capacitacin
Acondicionamiento local
Criterios de decisin y negociacin final: Es un proceso que requiere de mucho cuidado y depende del
esquema o lnea de pensamiento del responsable del proyecto. Existen tomadores de decisiones que estn
dispuestos a asumir riesgos. La decisin debe ser la consecuencia de un equilibrio entre la evaluacin tcnica
y la evaluacin financiera puesta sobre la balanza.
Se requiere que el administrador o responsable del proyecto recomiende en forma concreta alguna de
las alternativas consideradas, sin embargo, dada la trascendencia del proyecto es posible involucrar a la
Direccin General o an al consejo de Administracin de la empresa durante la decisin final. Se culminan la
negociacin con el proveedor y la firma del contrato, el cal se recomienda que sea revisado por el rea legal de
la empresa.
Actividades posteriores a la firma de contrato: A la firma del contrato aseguran la implementacin correcta
del proyecto de innovacin tecnolgica. El administrador y responsable del proyecto desarrolla estas
actividades de una manera emprica. Basado en su experiencia personal.

149

La importancia de conocer y planear adecuadamente estas actividades se basa en el hecho de que en
algunas soluciones computacionales el costo de las actividades posteriores a la instalacin del equipo puede
ser significativo. Las actividades que deben desarrollarse despus de la negociacin y firma del contrato
incluyen:
Acondicionamiento del local
Capacitacin y curso
Conversin de programas
Traslado de la informacin al nuevo equipo
Acondicionamiento del local: Es el conjunto de actividades relacionadas con el lugar fsico que ocupar el
equipo. Las actividades que deben realizarse como parte de la planeacin de la infraestructura de la sala de
cmputo incluyen:
Planeacin del espacio fsico.
Colocacin de piso falso en caso necesario.
Instalacin elctrica.
Reguladores de corriente elctrica.
Equipos de aire acondicionado.
Accesorios adicionales tales como equipo para filtracin de polvo ambiental, extinguidores, detectores y
control de humedad, fuentes interrumpidas de corriente, controles de accesos y seguridad, dispositivos
de deteccin de agua, equipos telefnicos y de intercomunicacin.
Capacitacin y cursos: Es una de las actividades ms importantes que deben llevarse a cabo antes de la
llegada del nuevo equipo computacional. Esta capacitacin debe incluir a los siguientes puestos de la
organizacin:
Al personal del rea de soporte tcnico o de los programadores de sistema
A los analistas y programadores de aplicaciones, quienes tendrn a su cargo la conversin de
aplicaciones al nuevo equipo.
Al personal del rea de operaciones
A los usuarios quienes recibirn capacitacin en la utilizacin de paquetes enfocados a usuarios final y
operacin bsica del equipo

150

Conversin de programa: El proceso mediante el cual las aplicaciones que corren en un equipo
computacional son convertidas para que puedan correr en otro equipo. El proceso de cambio de equipo
computacional trae consigo, la problemtica de convertir los programas para que puedan ejecutarse en el nuevo
equipo. El primer paso consiste en determinar el nivel de conversin que se realizar a fin de estimar el nivel
de esfuerzo requerido:
El primero y ms sencillo nivel de conversin se llamar nivel A, en este caso los programas objeto de
una plataforma funcionan correctamente en la nueva solucin, por lo que solo se requiere transcribir los
procedimientos y copiar los archivos de un equipo a otro. Lo anterior se logra cuando un equipo
computacional emula a otro.
El segundo nivel, implica la recopilacin de los programas en nuevo equipo, para lo cual debe existir
una fuerte compatibilidad en los lenguajes de ambos equipos. No implica el cambio de lenguaje de
programacin al hacer la conversin.
El nivel C de conversin implica un cambio de lenguaje al hacer la conversin de aplicaciones, lo cual
puede hacerse de manera manual, o bien, utilizar convertidores que traducen el cdigo fuente a los
estndares del nuevo equipo.
El ltimo nivel de conversin o nivel D, implica un rediseo y programacin de las aplicaciones, lo cual
implica tirar a la basura los programas que se encuentran en funcionamiento.
Es muy recomendable realizar las siguientes actividades previas al proceso de conversin de los
programas:
Hacer un inventario de todos los programas fuentes a convertir y estar seguro que todos los programas
localizados corresponden en su versin a los programas objeto que se encuentran corriendo.
Revisar que toda la documentacin de las aplicaciones est disponible para efectos de que los
programadores que participan en la conversin puedan utilizarla.
Diseo del procedimiento y estndares de conversin para controlar y dar seguimiento al proceso de
conversin.
Elaborar el plan de conversin, el cual debe incluir cuando menos la secuencia de programas a
convertir, personas asignadas y fechas de liberacin simultnea de sistemas que requieran datos entre
s.

151

Contratacin de un Servicio Interno de Computacin:

En este punto es donde se observa que la contratacin interna mejora enormemente la eficiencia para
el desarrollo y la operacin de los sistemas de informacin. Las compaas que han optado por el servicio
interno citan varias metas claves:
No implica un desembolso inicial de dinero
Adoptar decisiones ms adecuadas
Evitar un nivel de dependencia con el servicio, que le impida resolver los inconvenientes planteados de la
forma ms adecuada para sus intereses.

Razones para optar por un servicio interno:

Personal capacitado: Los sistemas actuales exigen conocimientos tcnicos inditos del personal. Esto incluye
que el personal sea sumamente capacitado para asumir cualquier situacin ya sea sencilla o compleja en el
momento que sea requerido.

Respuesta inmediata a las necesidades de los usuarios: En caso de presentarse alguna falla
inmediatamente podr ser resulto el problema, sin el mayor retraso de tiempo. Puesto que ah mismo es en
donde se concentra el rea de soporte y no se perder mayor tiempo en reportarlo y llegar a la solucin.

Es ms fcil hacer un cambio de equipo posterior: En caso de requerir de mejoras o cambios posteriores, le
ser aun ms fcil a este servicio realizarlas. Puesto que conoce a fondo lo que verdaderamente se esta
requiriendo en el momento necesario.

Ahorro de costos: La mayora de las empresas, tienen como objetivo principal: el minimizar costos y el
servicio interno ofrece una excelente alternativa para este fin. Pero siempre y cuando el servicio interno sea tan
bueno y viable a las necesidades planteadas.

152

Factores de xito en el servicio interno:

Definir, establecer y observar un proceso de planificacin para el proyecto de adquisicin interna.
Considerar el tiempo para la diligencia debida.
Seleccionar un grupo diversificado de profesionales de la organizacin para preparar un informe de
evaluacin sobre los requisitos de la empresa, que especifique las reas que sern objeto de la
contratacin interna en sintona con los planes y las prioridades de la misma.
El liderazgo es un tema importante para la prestacin satisfactoria y se recomienda en gran medida la
existencia de un lder en la organizacin con experiencia acerca del proceso del servicio.
Elegir un equipo comprometido, para supervisar el proyecto de contratacin interna al comienzo del
proceso con la combinacin correcta de usuarios y profesionales tcnicos: Es tambin importante
obtener la promesa de los gerentes para que se asignen estas personas, algunas veces de tiempo
completo, al equipo del proyecto.
Instruccin del equipo de gestin de proyectos y los usuarios: Reconocer las inquietudes, las dudas y
disponer de una estrategia para tratar los complejos temas relativos al sistema, que caractersticamente
ocurren en toda implementacin.
La comunicacin interpersonal deficiente y la falta de educacin de los usuarios en cuanto a los temas
relacionados con el servicio: Es importante que el equipo del proyecto logre apoyo de todos los usuarios
o clientes del sistema.
Respaldar la gestin para los proyectos: El apoyo de la gestin es vital para el xito de los proyectos. El
personal directivo superior debe considerar la implementacin como un proceso institucional esencial
para la institucin asistencial, el cual integra requisitos de informacin diferentes y modifica las tareas y
las funciones de gestin y cotidianas con el objetivo de mejorar el desempeo operativo.
Realizar pruebas frecuentes durante el desarrollo o el mantenimiento de una aplicacin: Las
instituciones deben garantizar que un equipo interno realice una prueba meticulosa de las aplicaciones.
Y asegurar que el proyecto para el desarrollo o el mantenimiento de sistemas debe estar libre de
errores y ser funcionalmente completo.

Como evitar problemas con el servicio interno:

Una vez que la empresa determina optar por este servicio se debe tener en cuenta que el
funcionamiento o fracaso solo defender de la experiencia que se tenga para asumir cualquier inconveniente,
as como de la capacitacin y coordinacin dentro de la empresa.

153

6.3 Evaluacin y seleccin de programas
Una de las preguntas ms difciles en la eleccin del software, una vez que se conocen los
requerimientos del sistema, es el determinar si un cierto paquete de software cumple con los requerimientos.
Despus de la seleccin inicial, es necesario escudriar un poco mas para determinar lo deseable de
un software particular comparado con otros candidatos.
Preguntas acerca de los requerimientos de una aplicacin:
Qu transacciones y que datos de cada transaccin se deben manejar?
Qu reportes, documentos y otras salidas debe producir el sistema?
Qu archivos y bases de datos maneja el sistema? Qu archivos de transacciones son necesarios
para mantenerlos?
Cul es el volumen de los datos por almacenar? Qu volumen de transacciones ser procesado?
Existen caractersticas nicas en esta aplicacin que requieran de especial atencin cuando se elija el
software?
Qu requerimientos de consultas debe soportar el sistema?
Cules son las posibles ampliaciones y cuales de ellas ofrecer el sistema?
Qu caractersticas de hardware y comunicacin requiere el software?
Cules son las limitaciones del software?
Lineamientos para la evaluacin del software:
1.-Eficacia en el desempeo:
Capacidad para realizar las tareas requeridas
Capacidad para realizar las tareas que se desearn ms adelante
Buen diseo en pantalla
Capacidad adecuada
2.- Eficiencia operativa:
Tiempos de respuesta rpidos
Captura eficiente
Salidas eficientes
Almacenamiento de datos eficiente
Respaldos eficientes

154

3.-Facilidad del uso:
Uso de interfaces satisfactorios
Disponibilidad de mens de ayuda
Interfaz flexible
Retroalimentacin adecuada
Buena recuperacin ante errores
4.-Flexibilidad:
Opciones de entrada
Opciones para la salida
Compatibilidad con otro software
5.-Calidad de la documentacin:
Buena organizacin
Programas tutoriales de calidad
Respuestas adecuadas a las preguntas
6.-Soporte del fabricante:
Lnea de consulta directa
Boletines
Actualizaciones frecuentes 10
6.4 La decisin de Diseo Interno de sistemas
El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito de
definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y
realizacin fsica.

10 KENDALL & KENDALL, Anlisis y diseo de sistemas, 2 ed. ,Mxico, Pretince Hall , 1991 Pag. 416.

155

El diseo de sistemas encierra las siguientes etapas:
Diseo efectivo de salidas
Diseo de una entrada eficaz
Diseo de la interfaz del usuario
Diseo de procedimientos precisos de captura de datos
Diseo de los archivos y de bases de datos
Diseo efectivo de salidas: Las salidas pueden tomar distintas formas: los reportes impresos tradicionales y
salidas en formatos, tales como pantallas en monitor, microformas y salidas de audio. Los usuarios confan en
las salidas para la realizacin de sus tareas; y con frecuencia, juzgan el merito del sistema exclusivamente por
salidas. Con el fin de crear una salida de utilidad, el analista de sistemas trabaja estrechamente con el usuario,
mediante un proceso interactivo, hasta que el resultado llegue a ser satisfactorio.
Los objetivos de una salida son los siguientes:
Disear una salida para satisfacer el objetivo planteado.
Disear una salida que se adapte al usuario
Proveer la cantidad adecuada de informacin
Asegurar que la salida este disponible donde se necesita
Proporcionar oportunamente la salida
Elegir el mtodo correcto de salida
Diseo de la salida para satisfacer el objetivo planteado: Toda salida debe contar con un propsito explicito,
no es suficiente que se presente a los usuarios un reporte o una pantalla, solo por que tecnolgicamente es
posible hacerlo. Durante la fase del anlisis de determinacin de los requerimientos de informacin, el analista
de sistemas identifica los propsitos a satisfacer y con base en tales propsitos se disea la salida.
Diseo de la salida para adaptarse al usuario: Es difcil personalizar la salida con un gran sistema de
informacin que atiende a numerosos usuarios con diferentes propsitos, con base en entrevistas,
observaciones, consideraciones de costo y tal vez, prototipos, ser posible disear salidas que se apeguen a la
mayora, si no a todas las necesidades de los usuarios y sus preferencias. En trminos generales, es mas
practico crear una salida especifica para el usuario cuando se disea para un sistema de apoyo de toma de
decisiones, sin embargo, es posible disear salidas que se apeguen a las salidas de los usuarios en la
organizacin.

156

Proveer la cantidad adecuada de informacin: Mas no siempre es mejor, en especial si nos referimos al
volumen apropiado de informacin, parte de la tarea del diseo de la salida es decidir que cantidad de
informacin es correcta para los usuarios, pronto se dar cuenta que es una tarea muy difcil ya que los
requerimientos de informacin cambian de manera continua. El problema de la saturacin de la informacin es
tan comn, pero no deja de ser una recomendacin valida, si la informacin es excesiva y solo se da con el fin
de demostrar la capacidad del sistema. Cuando decida la magnitud de la salida, siempre tenga en mente al
tomador de decisiones, con frecuencia, ellos no requieren de un gran volumen de informacin de salida, en
especial si existe otra manera sencilla con mayor posibilidad de acceso.
Asegrese de que la salida este disponible donde se requiere: La salida se encuentra impresa en el papel,
desplegada en pantallas, difundida a travs de bocinas y adems, almacenada en microformas. Con frecuencia,
la salida se produce en un sitio (por ejemplo, en el departamento de procesamiento de datos) y luego se
distribuye entre los usuarios. El incremento de las salidas en lnea (on-line), desplegadas en pantalla y que son
accesibles de manera individual, han resuelto parte del problema de la distribucin, pero una distribucin
apropiada todava es importante objetivo para el analista de sistemas, para ser til y aprovechada, la salida
debe presentarse al usuario adecuado. No importa que tan bien se diseen los reportes, si estos no los ven los
tomadores de decisiones pertinentes.
Proporcionando oportunamente la salida: Una queja comn de los usuarios es que no reciben de manera
oportuna la informacin para la toma de decisiones, lo anterior debe quedar dentro de los objetivos del analista
de sistemas para la salida. No nicamente debe estar conciente acerca de quien recibe la salida, si no tambin
debe considerar la puntualidad de su distribucin. Aunque la oportunidad no lo es todo, desempea un papel
importante para la toma de decisiones.
Eleccin del mtodo correcto de salida: Como se menciono con anterioridad, la salida puede tomar
diferentes formas, incluyendo los reportes impresos en papel, la informacin presente en pantalla, sonidos de
audio y digitalizados que simulan la voz humana y las microformas. La eleccin del mtodo correcto para cada
tipo de usuario es otro de los objetivos en el diseo de la salida. Para mucha gente, la salida se asocia con la
idea de voluminosos bultos de papel de computadora, pero esto ha cambiado ltimamente, con el movimiento
hacia los sistemas en lnea, la mayora de la informacin se despliega en pantalla. El analistas debe evaluar las
ventajas involucradas al elegir un mtodo de salida, los costos difieren, as como la flexibilidad, vida media,
distribucin, almacenamiento y posibilidades de acceso y transporte; y finalmente, el impacto global hacia el
usuario. La eleccin del mtodo de salida no es trivial ni es una conclusin predeterminada.

157

La eleccin de la tecnologa de salida: Para producir diferentes tipos de salidas, se requiere el uso de
diferentes tecnologas, para salidas impresas de computadora, las opciones con que contamos son las
impresoras de impacto y no impacto. Para salidas de pantalla, tenemos como opciones monitores
independientes o integrados. Las microformas son salidas creadas por equipos de cmaras especiales y
filmadas, como se puede ver, se tienen numerosas alternativas.
Consideraciones al elegir la tecnologa de salida: Aunque la tecnologa cambia con rapidez, hay principios
tiles que permanecen prcticamente constantes en relacin a los avances tecnolgicos, estos elementos son:
Quin usara (vera) la salida (requisito de calidad)?
Cuntas gentes necesitan la salida?
En donde se necesita la salida (distribucin/logstica)?
Cul es el propsito?
Con que velocidad se requiere?
Con que frecuencia?
Durante cuanto tiempo ser almacenada (o debe almacenarse)?
Bajo que relaciones particulares se produce la salida, almacena y distribuye?
Cules son los costos iniciales y posteriores de mantenimiento y de suministros?
Cules son los requisitos ambientales (absorcin de ruido, temperatura controlada, espacio para
equipo y cableado) paran las tecnologas de salida?
Al examinar de manera separada cada uno de estos factores, usted podr identificar sus interrelaciones
y como pueden compararse los sistemas en particular.
Diseo de una entrada eficaz: La calidad de la salida del sistema esta determinadas por la calidad de su
acceso o entrada, durante el diseo de las formas de entrada y las pantallas es vital tener en mente esta
relacin decisiva. Al insistir en el buen diseo de la entrada, el analista de sistemas queda advertido que
entradas pobres ponen en entredicho la calidad del sistema completo. Un buen diseo de los formatos y las
pantallas de entrada debe satisfacer los objetivos de eficacia, precisin, facilidad de uso, consistencia, sencillez
y atraccin. Tales objetivos se pueden alcanzar cuando se tiene el conocimiento de lo que se requiere como
entradas para el sistema y cuando se llega a una comprensin de la manera en que el usuario responder a los
diferentes elementos de las formas las pantallas.

158

Buen diseo de las formas: Aunque pudiera contarse con un especialista en el diseo de formas dentro de la
empresa, el analista de sistemas debe tener habilidad para disear de manera integral una forma que resulte
til, tambin es importante el reconocimiento de diseos pobres, duplicidades o formas innecesarias que
desperdician los recursos de la organizacin y que debern evitarse. Las formas son instrumentos importantes
para el desempeo adecuado del trabajo. Por definicin, las formas son documentos duplicados o preimpresos
que requieren ser llenados por las personas, en respuesta a un procedimiento estandarizado. Las formas hacen
surgir y capturan la informacin que los miembros de la organizacin requieren; y con frecuencia se alimentan a
la computadora. A travs de este proceso, las formas sirven comnmente como documentos fuente para el
personal que los alimenta. Se deben observar cuatro lineamientos para el diseo de formas con el fin de
alcanzar una utilidad:
Diseo de formas fciles de llenar
Asegrese que las formas cumplan con el propsito para el cual fueron diseadas.
Disee formas que aseguren un llenado preciso
Mantenga las formas atractivas
Diseo de la interfaz del usuario: Para la mayora e los usuarios, la interfaz es el sistema, aunque este bien o
mal diseado, permanece como una representacin del sistema y por tanto es de la competencia del analista
de sistemas. Se debe tener como objetivo, el diseo de una interfaz que ayuden a los usuarios y a sus
empresas a obtener o introducir informacin al sistema y que satisfagan los siguientes objetivos:
Eficacia: Al lograr mediante el diseo de interfaces, que el usuario tengan acceso al sistema, de tal
forma que sea congruente con sus necesidades particulares.
Eficiencia: Demostrada a travs de interfaces que mejoren la velocidad de captura de los datos y
reduzcan errores.
Consideracin del usuario: Al demostrar un diseo adecuado de la interfaz y que favorezca la
retroalimentacin del sistema para los usuarios en forma apropiada.
Productividad: Considerada a travs del apego a los principios del diseo ergonmico de las interfaces
de los usuarios y de sus reas de trabajo.
Tipos de Interfaces de usuario:
Interfaz de preguntas y respuestas
Mens
Formas de entrada/salida
Interfaz de manejo directo
Ratn (Mouse)

159

Diseo de procedimientos precisos de captura de datos: Es de fundamental importancia asegurarse de que
los datos se capturen con precisin, es un axioma establecido que la calidad de la captura de datos determine
la calidad de la informacin de salida. La calidad de los datos es una medida de cmo la consistencia y
correccin de los datos se encuentran dentro de ciertos limites preestablecidos. Cuando los datos se introducen
en forma eficiente, la captura satisface los parmetros establecidos de desempeo que se apegan a una
relacin entre el tiempo invertido en la captura y el nmero de datos capturados. Una captura eficiente de datos
tambin indica que los capturitas puedan descifrar los datos con rapidez y sencillez.
Diseo de los archivos y de bases de datos: En un sistema de informacin basado en computadoras se
cuenta con dos enfoques para el almacenamiento de los datos. El primer mtodo consiste en almacenar los
datos en archivos individuales, exclusivos para una aplicacin en particular. El segundo enfoque para el
almacenamiento de datos es un sistema basado en computadora, involucra la elaboracin de una base de
datos.
Los archivos convencionales: Sin duda alguna, permanecen como una manera practica de almacenar los
datos de ciertas (si no de todas) las aplicaciones. Un archivo convencional se puede disear y elaborar de
manera rpida, reduciendo los problemas de disponibilidad de datos y de seguridad.
Bases de datos:Las bases de datos son meramente una coleccin de archivos, mas bien, una base de datos
es una fuente central de datos significativos, los cuales son compartidos por numerosos usuarios para diversas
aplicaciones.
Los objetivos de eficacia de las bases de datos son:
Asegurar que los datos puedan ser compartidos por los usuarios para una variedad de aplicaciones.
Que el mantenimiento de los datos sea preciso y consistente
Asegurar que todos los datos requeridos para las aplicaciones presentes y futuras se encuentren
siempre disponibles.
Permitir que la base de datos evolucione y se adapte a las necesidades crecientes de los usuarios.
Permitir que los usuarios desarrollen su propia visin de los datos, sin preocuparse por la manera en
que los datos se encuentren almacenados fsicamente.
Antes de considerar el uso de los archivos o del enfoque de las bases de datos, es importante entender
como se presentan los datos. Los datos se consideran aislados del mundo real y posteriormente se considera
su almacenamiento en los archivos.

160

Realidad, datos y metadatos: Solamente el mundo real en si puede ser mencionado como la realidad,
aquellos datos que se obtienen de las personas, de lugares o de eventos de realidad, eventualmente sern
almacenados en archivos o bases de datos. Con el fin de comprender la forma y la estructura de los datos, se
requiere de informacin acerca de los datos mismos, aquella informacin descriptiva de los datos se denomina
como metadato.
Entidades: Una entidad es cualquier objeto o evento, acerca del cual, se recolectan datos. Una entidad puede
ser una persona, un lugar o un objet, por ejemplo: un vendedor, una ciudad o un producto.
Relaciones: Las relaciones son asociadas entre entidades (y algunas se refieren como asociaciones de datos).
Atributos: Un atributo es una caracterstica e una entidad, puede haber muchos atributos para cada entidad,
por ejemplo: un paciente (entidad) puede tener numerosos atributos tales como el apellido, nombre, direccin,
ciudad, estado, etc.
Registros: Un registro es una coleccin de datos elementales que tienen algo en comn.
Llaves: Una llave es un dato elemental en un registro que se utiliza como criterio de identificacin para este,
cuando una llave identifica de manera exclusiva a un registro se le denomina llave primaria.

161

VII. LA ADMINISTRACIN DE LOS SISTEMAS DE INFORMACIN
La administracin se define como el proceso de crear, disear y mantener un ambiente en el que las
personas, que laboran o trabajando en grupos, alcancen con eficiencia metas seleccionadas. Y sus
caractersticas son las siguientes:
La administracin se aplica en todo tipo de corporacin.
Es aplicable a los administradores en todos los niveles de una corporacin.
La administracin se ocupa del rendimiento; esto implica eficiencia y eficacia
Origen y evaluacin:
Las actuales concepciones administrativas son la resultante de un proceso iniciado en los mismos
albores de la humanidad y que ha venido evolucionando y adquiriendo sus propios perfiles a travs de
diferentes pocas y etapas. Dicho proceso administrativo se inici como un hecho obligado cuando dos
individuos tuvieron que coordinar sus esfuerzos para hacer algo que ninguno de ellos pudo hacer por s solo y
evolucion hasta convertirse en un acto previo y cuidadosamente planificado y racional que permite alcanzar
objetivos con los menores esfuerzos posibles y con las mayores satisfacciones para los individuos.
La administracin en la edad contempornea:
Los historiadores estn de acuerdo conque hubo una segunda revolucin industrial de 1860 a 1914,
llamada tambin revolucin del acero y la electricidad, que sustituy el hierro por acero como material bsico
para la industria en el campo de la energa. La administracin cientfica de Taylor surgida en esta poca
cumpli a cavalidad con esa funcin, suministrndole las herramientas, tcnicas necesarias para su expansin
y desarrollo. La administracin cientfica surgi durante la segunda revolucin industrial, sus precursores ms
destacados son:
Charles Babbage: Es no slo considerado como un precursor del pensamiento administrativo cientfico, sino
tambin el de la computadora, ya que en 1822 fabrico una maquina mecnica de calcular que sirvi de
orientacin para la invencin de las modernas computadoras.
Henry R. Towne: En 1886, ante la sociedad Norteamericana de Ingenieros Mecnicos, pronunci una
conferencia titulada El Ingeniero como Economista, entre los asistentes se encontraba Frederick Taylor, en la
misma se peda que la administracin se considerara como una ciencia. Ide un plan de reparto de ganancias
como sistema de pago de salario.

162

Henry Metacalfe: Se distingui por implantar nuevas tcnicas de control administrativos e ide un buen
sistema de control. Posteriormente Metacalfe fue considerado por Taylor como una persona muy eficiente.
Public un libro titulado El Costo de Produccin y la Administracin de Talleres Pblicos y Privados,
considerado como una obra precursora de la administracin cientfica.
Woodrow Wilson: Escribi un estudio sobre administracin pblica, es el ms famoso y discutido articulo de la
ciencia de la administracin que se haya jams escrito en Amrica. Wilson hizo una separacin entre poltica y
administracin y le dio el calificativo de ciencia a la administracin.
Marco que rodea la empresa:
En la actualidad, el entorno externo sufre cambios acelerados y continuos que tienen muy diversos
efectos en las organizaciones y sus estrategias administrativas. A su vez han cambiado los parmetros con que
se juzga el desempeo de los administradores. Antes era suficiente que las organizaciones maximizaran sus
utilidades; el desempeo se juzgaba en base a que tambin velaban por los intereses de los accionistas. Hoy
en da, las organizaciones deben responsabilizarse no slo ante los accionistas sino tambin ante la ms
extensa y diversa comunidad que ejerce influencia, aquellos grupos o individuos que se ven afectados, directa o
indirectamente, por la forma en que la organizacin busca alcanzar sus objetivos. Los administradores se ven
sujetos a una presin cada vez mayor para prever y responder a esta serie de fuerzas externas y pensar en
forma global. El componente de accin directa del entorno est compuesto por los grupos de inters de la
organizacin, es decir, por los grupos que tienen impacto directo en las actividades de la organizacin.
Los grupos de inters externos incluyen a los clientes, proveedores, gobierno, grupos de inters
especial, medios de comunicacin, sindicatos, instituciones financieras, y a la competencia. Los grupos de
inters incluyen a los empleados, accionistas y al consejo de administracin. Los administradores deben
balancear los intereses de los diversos grupos de influencia para el bien de la organizacin como un todo.
Deben distinguir entre cambios cclicos y estructurales en la economa y ajustarse a ellos. Los avances
tecnolgicos en las comunicaciones y el transporte han provocado que el entorno internacional sea cada vez
ms importante. El entorno determina tanto el aumento de la incertidumbre que afronta una organizacin como
el grado de dependencia de otros en cuanto a recursos vitales. Los administradores, en especial los de alto
nivel, deben supervisar en entorno exterior y tratar de pronosticar los cambios que afecten a la organizacin.

163

La administracin y los modernos sistemas de informacin:
La aplicacin de la tecnologa de la computacin para la administracin de la informacin y sistemas de
apoyo de decisiones ciertamente ha tenido un efecto en la manera en que los administradores desempaan sus
labores y en como se comportan las organizaciones. Uno de los primeros estudios del impacto de la
computarizacin sugiri que podra haber una estructuracin cada vez mayor de la administracin de mandos
medios a un nivel ms alto para algunas posiciones de la administracin de mandos medios, ms diferencias
entre la alta y la administracin de mandos, medios y una recentralizacin de la organizacin.
El principal efecto de la computarizacin en las organizaciones ha sido la capacidad para procesar
papeleo con precisin y velocidad inusitada; la segregacin de los administradores de mandos medios a los
papeles de funcionario y programador no se ha dado. La cantidad de usos que la administracin de alto nivel
hace de la informacin basada en la computacin y de las mismas computadoras vara de organizacin a
organizacin y es una materia de disputa entre los autores sobre administracin. El reto para la administracin
es explotar estas nuevas tecnologas, para cuestionar el status quo de la organizacin y para controlar el
cambio ms que trabajar para prevenir o limitarlo.
No es una exageracin decir que estamos pasando rpidamente de una sociedad basada en la
industria a una que se funda en la informacin. La ampliacin de las capacidades de la computadora y el
desarrollo de la inteligencia artificial, seguramente favorecern la introduccin de ajustes importantes en la
forma en que trabajan los administradores y en que acten las organizaciones. Llegar el da en que realmente
podamos crear una sociedad basada en la informacin cuyos miembros tendrn suficiente tiempo para disfrutar
los frutos de sus industrias principales: conocimiento, comunicacin y productos de consumo basado en la
computadora. Las organizaciones siempre han tenido algn tipo de sistema de informacin administrativa.
Antes estos sistemas tenan una composicin y un uso sumamente informales. Cuando el personal de
la oficina de inscripciones llevaba transcripciones sobre grficas manuscritas, estaban usando un sistema de
informacin. No fue sino hasta el advenimiento de las computadoras, con su capacidad para procesar y
condensar grandes cantidades de datos, que el diseo de los sistemas de informacin administrativa se
convirti en un proceso formal, as como en un campo de estudio.
Procesamiento electrnico de datos, por sus siglas en ingles: (EDP Electronic Dates Process)Cuando
empezaron las organizaciones a usar las computadoras se usaban primeramente para procesar datos en
cuanto a unas cuentas funciones de la organizacin por regla general, contabilidad y facturacin. Conforme fue
aumentando la velocidad y la exactitud para procesar datos, otras tareas de procesamiento de datos y de
informacin administrativa se fueron computarizando. Para enfrentar estas nuevas tareas, los departamentos de
(EDP) elaboraron informes estandarizado par que lo usaran los gerentes de operaciones.

164

Nacen los sistemas de informacin administrativa:
Con el crecimiento de los departamentos de EPD llev a los gerentes a concentrarse ms en la
planificacin de los sistemas de informacin de sus organizaciones. Estos esfuerzos condujeron al nacimiento
de los Sistema de Informacin Computarizado (CBIS). Este es un sistema de informacin que va ms all de la
mera estandarizacin de datos para ayudar con el proceso de planificacin.
Sistema de apoyo para decisiones: El sistema de apoyo para decisiones es un sistema interactivo de
computadora, de fcil acceso y operacin, a menos de personas que no son especialistas en computadoras y
que usan el DSS para que les ayude a planificar y tomar decisiones. El uso del DSS est extendindose,
conforme a los avances recientes en mquinas y programas de computadoras, permiten que los gerentes y
otros empleados designados tengan acceso basndose en datos de MIS. El uso generalizado de la micro
computadoras ha permitido a los gerentes crear sus propias bases de datos y manejar informacin, en forma
electrnica, conforme a la necesidad, en lugar de tener que esperar los informes emitidos por el departamento
de EDP/MIS.
Informacin diferente para diferentes niveles administrativos: Anthony Gorry Y M.S. Morton han sealado
que el sistema de informacin de una organizacin debe proporcionar informacin a administradores con tres
niveles de responsabilidad: Control de operaciones, control administrativo y planificacin estratgica. El diseo
de MIS debe tomar en cuenta las necesidades de informacin de distintos niveles administrativos, as como las
necesidades rutinarias de procesamiento de transacciones de la organizacin entera.
Control de operaciones: Un MIS par el control de operaciones debe ofrecer informacin muy exacta y
detalladas los das o semanas. El supervisor de produccin debe saber si se desperdician demasiados
materiales, los MIS debe ofrecer un volumen grande de informacin oportuna y detalladas.
7.1 El Centro de Informacin
Un centro de computo es un rea de trabajo cuya funcin es la de concentrar, almacenar y procesar los
datos y funciones operativas de una empresa de manera sistematizada. Adems de ser el rea en donde se
desarrollaran, actualizara y modernizaran sistemas de informacin, objetivo de un centro de cmputo:

La computadora como herramienta de solucin para problemas de clculo de operaciones,
investigacin de procesos, enseanza, etc. establece las bases para determinar el objetivo de un centro de
computo, como es el de prestar servicios a diferentes reas de una organizacin ya sea dentro de la misma
empresa, o bien fuera de ella, tales como: produccin, control de operaciones, captura de datos, programacin,
dibujo, biblioteca, etc.

165

Principales departamentos del centro de computo:
Departamento de operacin: Este departamento es el encargado de operar y/ manipular el sistema, los
datos del mismo, y el equipo con que cuenta la empresa; en otras palabras el software y el hardware.
Departamento de produccin y control: Este departamento se encarga de verificar que los programas o
sistemas que se producen en el departamento de sistemas de cmputo estn correctamente estructurados. As
mismo le compete a este departamento, probar el sistema programa tantas veces como sea necesario hasta
estar seguro de su correcto funcionamiento.
Departamento de administracin de sistemas: Este es el encargado de administrar los suplementos del
software, as como el responsable de dotar instalar en cada departamento del centro de cmputo, los
requerimientos que para su buen desempeo sean necesarios. En otras palabras este es el departamento que
se encarga de organizar y distribuir el software necesario para el funcionamiento de los departamentos.
Departamento de programacin: Este es el encargado de codificar los programas, bases de datos, etc. Que
se requieren para el funcionamiento de la empresa. El programador captura, codifica y disea el programa
sistema y posteriormente lo convierte a ejecutable para su uso dentro de la empresa.
Departamento de implementacin: En este departamento como su mismo nombre lo indica, le corresponde
implementar el software necesario de manera que a cada rea del centro de cmputo se le destine el material
que requiere para el buen desempeo de sus funciones dentro de la empresa.
Departamento de soporte: Este es el encargado de verificar que el software y hardware, funcionen
correctamente y en caso de que se localice algn error, debern repararlo. Normalmente este departamento
solo existe en empresas que manejan gran cantidad de informacin dinero ya que el costo de un
departamento de estos es muy alto.
Adquisicin de software y hardware:
Elementos esnciales y decisivos en la integracin de un sistema de informacin, ya que ambos
comparten ciertas caractersticas de compatibilidad para poder dar los resultados esperados.

166

1.-Procedimiento de adquisicin:
Adquisicin de software: Para la adquisicin del software intervienen 7 factores principales que son:
Asignar el personal
Preparar listas de requerimientos
Requisicin de propuestas
Evaluar alternativas
Contactar usuarios para confirmar
Financiamiento para la adquisicin
Negociacin de contrato
Seleccin del hardware: El proceso de seleccin del hardware esta diseado de manera tal que, la adquisicin
del hardware sea una accin fcil de realizar y consta de los mismos pasos que el proceso de seleccin del
software.
Adquisiciones del hardware y software: Las consideraciones que debemos tomar en cuenta para la
adquisicin de software y hardware, son:
Formar un equipo de evaluacin
Tomar en consideraciones a todos los requerimientos as como las restricciones
Solicitud de propuesta: La solicitud de propuesta deber realizarse mediante las requisiciones que debern
incluir:
Informacin general
Objetivo
Propsito
Fecha limite de entrega
Fecha limite de aclaraciones
Cobertura de requerimientos:
Mnimos
Deseables
Solicitud de descripcin detallada del producto o servicio
Solicitar especificaciones detallada de servicios de soporte de usuario.
Coordinar presentaciones

167

Evaluacin de propuesta: Para llevar a cabo una buena evaluacin de las propuestas presentadas debern
tomarse en cuenta los siguientes trminos:
Validar lo que ofrece del proveedor (credibilidad de propuesta)
Analizar propuesta
Costo
Disponibilidad
Calidad de diseo
Soporte y mantenimiento
Expansin
Configuracin
Ambiente de software
Documentacin
Y posteriormente se deber verificar con terceros la informacin sobre los productos o servicios ofrecidos
por el proveedor.
Financiamiento: Son tres los puntos que debemos considerar para el financiamiento de la adquisicin del
software y son:
Renta
Arrendamiento
Compra
Negociacin de contrato: La negociacin del contrato deber contemplar entre otros los siguientes puntos:
Obtener un contrato justo
Puntos de negociacin:
Precios
Costo
Capacitacin
Penalizaciones
Posibles problemas que se puedan presentar:
Contrato a favor del proveedor
Vendedor profesional, comprador amateur o principiante.
Convenios no incorporados en clusulas
Ausencia de penalizaciones
Clusulas integradoras ( dejar sin valides cualquier acuerdo previo)

168

Permisos y licencia:
Licencias de uso: Este punto resulta ser de suma importancia, puesto que el regula la proteccin de los
programas de computacin, sealando adems que los programas de computo que tengan por objeto el causan
efectos nocivos a otros programas o equipos, lgicamente no sern protegidos. Sanciona el comercio de
programas de dispositivos o sistemas cuya finalidad sea desactivar dispositivos electrnicos de un programa de
cmputo. Por otra parte, se refiere a la facultad del titular de los derechos de autor sobre un programa de
computacin o sobre una base de datos. De conservar an despus de la venta de ejemplares de los mismos el
derecho de autorizar o prohibir el arrendamiento de dichos programas.
7.2 Mantenimiento
Uno de los puntos de mayor inters para el departamento de sistemas o informtica ya que involucra
diferentes factores, los cuales deberan ser considerar antes de su funcionamiento pues de ello depender el
verdadero funcionamiento del centro de cmputo, lo que da como resultado un mejor servicio, tomando en
cuenta los siguientes factores:
Fuente de mantenimiento: Una vez que el sistema se ha entregado e instalado, existe un perodo de garanta
en el cual la unidad de ventas que efectu la operacin tiene la responsabilidad del mantenimiento; despus de
este tiempo el comprador puede solicitar mantenimiento de varias fuentes, por ello antes de que caduque la
garanta es preciso que cualquier anomala se de a conocer al proveedor a fin de hacerla validad cubrindola
esta en tiempo y forma.
Trminos de mantenimiento: El contrato puede cubrir todo tipo de necesidades que el equipo requiera y en el
momento que se le indique, por lo cual se aconseja que dicho contrato se redacte de manera que se
especifique todo aquello que sea preciso, como por ejemplo: el cubrir la mano de obra como las piezas que se
hayan necesitado en el mantenimiento, mano de obra y piezas por separado, etc. segn las ventajas que esto
represente para la organizacin.
Servicio y respuesta: El apoyo de mantenimiento es til si este se encuentra disponible cuando se requiere.
Sin embargo dos puntos de inters son: el tiempo de respuesta y las horas en las que se puede obtener el
apoyo, por lo cual es necesario vigilarlos pues representara un gasto para la organizacin si este no cubriera el
ser eficiente, eficaz y oportuno.

169

7.3 Actualizacin y Modernizacin
Departamento o rea de implementacin: Esta rea es la encargada de implantar nuevas aplicaciones
garantizando tanto su calidad como su adecuacin a las necesidades de los usuarios. Algunas funciones
principales generales que realiza esta rea son:
Coordinar con las reas de sistemas y usuarios la implantacin de las aplicaciones.
Disear los planes de calidad de las aplicaciones y garantizar su cumplimiento.
Validar los nuevos procedimientos y polticas a seguir por las implementaciones de los proyectos
liberados.
Probar los productos y servicios a implementar antes de ser liberados al usuario final.
Elaborar conjuntamente con el rea de Programacin o Desarrollo, los planes de capacitacin de los
nuevos usuarios.
Coordinar la presentacin de las nuevas aplicaciones a los usuarios.
La actualizacin de datos involucra la elaboracin de un plan de actividades para ese fin, en el cual deben
contemplarse todos los aspectos tcnicos y metodolgicos que sean necesarios, y tambin la determinacin de
las actividades que formaran parte del sistema y que tendrn a cargo la parte operacional o de realizacin del
programa. Estas actividades son fundamentales para evitar la duplicacin de esfuerzos y el mal uso de recursos
disponibles. Y hay que destacar que la efectividad de la coordinacin que se establezca depende en gran parte
del respaldo legal que ella tenga. Aspectos que deben considerarse para la actualizacin de datos, la
actualizacin de los datos requiere que se identifiquen y determinen con el mayor grado de detalle posible,
aspectos tales como:
Propsito y alcance de estudio.
Lista de datos o caractersticas (variables), que se van a estimar y para la cual debe recolectarse
informacin, esta lista puede agruparse en conjuntos o subconjuntos segn temas o materias de
estudio.
Descripcin del tipo de investigacin, sea por enumeracin completa
Dominio del estudio cubierto por la investigacin
Procedimiento de recoleccin de datos
La actualizacin guiada por los pasos antes mencionados, busca el mejoramiento y el desarrollo de los
sistemas de informacin. Para ello es necesario poner nfasis en la necesidad de integrar los diversos
proyectos de manera que se logre mayor eficiencia, calidad y consistencia de los datos pertinentes y de utilizar
los recursos disponibles en la mejor forma posible.

170

Modernizacin:
La Modernizacin se refiere, al proceso de transformacin que sufrirn los sistemas de informacin
dentro de un centro de cmputo, con la finalidad de mantenerlo a la vanguardia tecnolgica, que en nuestros
das es tan cambiante. El tomar la decisin de una modernizacin, es un punto que solo corresponde a los
directivos de la empresa. Considerando algunos aspectos como son:
Se quiere ser actual
Cuenta con un sistema totalmente obsoleto

171

VIII. ESTUDIO DE CASOS DE DISEO DE SISTEMAS
El Lenguaje de Modelado Unificado (UML) es la sucesin de una serie de mtodos de anlisis y diseo
orientadas a objetos que aparecen a fines de los 80's y principios de los 90s. UML es llamado un lenguaje de
modelado, no un mtodo. Los mtodos consisten de ambos de un lenguaje de modelado y de un proceso. El
lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para expresar un diseo. El
proceso indica los pasos que se deben seguir para llegar a un diseo. La estandarizacin de un lenguaje de
modelado es invaluable, ya que es la parte principal del proceso de comunicacin que requieren todos los
agentes involucrados en un proyecto informtico. Si se quiere discutir un diseo con alguien ms, ambos deben
conocer el lenguaje de modelado y no as el proceso que se sigui para obtenerlo.
Una de las metas principales de UML es avanzar en el estado de la integracin institucional
proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr
un intercambio exitoso de modelos de informacin entre herramientas, se requiri definir a UML una semntica
y una notacin. La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje de
modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los elementos y
conceptos como son: una clase, una asociacin y una multiplicidad. Y qu significa exactamente una
asociacin o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama,
usualmente de clases, que define la notacin). Para que un proveedor diga que cumple con UML debe cubrir
con la semntica y con la notacin. Una herramienta de UML debe mantener la consistencia entre los
diagramas en un mismo modelo. Bajo esta definicin una herramienta que solo dibuje, no puede cumplir con la
notacin de UML., el lenguaje est dotado de mltiples herramientas para lograr la especificacin determinante
del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:
Modelamiento de Clases
Casos de Uso
Diagrama de Interaccin
El UML (Lenguaje Unificado de Modelado), es una de las herramientas ms emocionantes en el mundo
actual del desarrollo de sistemas. Esto se debe a que permite a los creadores de sistemas generar diseos que
capturen sus ideas en forma convencional y fcil de comprender para comunicarlas a otras personas. La
comunicacin de la idea es de suma importancia. Antes del advenimiento del UML, el desarrollo de sistemas,
era, con frecuencia, una propuesta al azar. Los analistas de sistemas intentaban evaluar los requerimientos de
sus clientes, generar un anlisis de requerimientos de algn tipo de notacin que ellos mismos comprendieran
(aunque el cliente no lo comprendiera), dar tal anlisis a uno o varios programadores y esperar que el producto
final cumpliese con lo que el cliente deseaba.

172

Dado que el desarrollo de sistemas es una actividad humana, hay muchas posibilidades de cometer
errores en cualquier etapa del proceso, por ejemplo: el analista pudo haber mantenido al cliente, es decir,
probablemente produjo un documento que el cliente no pudo comprender. Tal vez ese documento tampoco fue
comprendido por los programadores quienes, por ende, pudieron generar un programa difcil de utilizar y no
generar una solucin al problema original del cliente.
Por qu es necesario el UML?: En los principios de la computacin, los programadores no realizaban
anlisis muy profundos sobre el problema por resolver, si acaso, garabateaban algo en una servilleta. Con
frecuencia comenzaban a escribir el programa desde el principio, y el cdigo necesario se escriba conforme se
requera. Aunque anteriormente esto agregaba un aura de aventura y atrevimiento al proceso, en la actualidad
es inapropiado en los negocios de alto riesgo. Hoy en da, es necesario contar con un plan bien analizado, un
cliente tiene que comprender que es lo que har un equipo de desarrolladores; adems tiene que ser capaz de
sealar cambios si no se han captado claramente sus necesidades (o si cambia de opinin durante el proceso).
A su vez, el desarrollo es un esfuerzo orientado a equipos, por lo que cada uno de sus miembros tiene que
saber que lugar toma su trabajo en la solucin final (as como saber cual es la solucin en general).
Conforme aumenta la complejidad del mundo, los sistemas informticos tambin debern crecer en
complejidad, en ellos se encuentran diversas piezas de hardware y software que se comunican a grandes
distancias mediante una red, misma que esta vinculada a bases de datos que, a su vez, contienen enormes
cantidades de informacin. Si desea crear sistemas que lo involucren con este nuevo milenio Cmo manejara
tanta complejidad?. La clave esta en organizar el proceso de diseo de tal forma que los analistas, clientes,
desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y convengan con el,
el UML proporciona tal organizacin.11
Importancia de los casos de uso: As como el diagrama de clases es un buen medio para estimular a un
cliente a que hable respecto a un sistema desde su propio punto de vista, el caso de uso es una excelente
herramienta para estimular a que los usuarios potenciales hablen, de un sistema, desde sus propios puntos de
vista. No siempre es fcil para los usuarios explicar como pretenden utilizar un sistema, puesto que el desarrollo
tradicional de los sistemas era, con frecuencia, algo as como una ciencia oculta, con muy poca informacin
para los usuarios, a aquellos que osaban preguntar se les daba informacin muy poco explicita o ciertamente
confusa respecto a lo que utilizaran.

11 SCHMULLER, J oseph Aprendiendo UML [trad. A. David Garza] Marn Mxico, Pretince Hall,200,pag. 5,6,7

173

La idea es involucrar a los usuarios en las etapas iniciales del anlisis y diseo del sistema, esto
aumenta la probabilidad de que el sistema sea de mayor provecho para la gente a la que supuestamente
ayudara, en un lugar de ser un manojo de expresiones de computaciones incomprensibles e inmanejables por
los usuarios finales. Suponga que empezar a disear una mquina despachadora de gaseosas, para obtener
el punto de vista del interesado, entrevistara a varios usuarios potenciales respecto a la manera en que
utilizaran dicha maquina. Dado que la funcin principal de una mquina de gaseosas es permitir a un cliente
adquirir una lata de gaseosa, probablemente las personas le dirn que se enfrentara a diversos escenarios, un
caso de uso, en otras palabras que podra etiquetar como comprar gaseosa. Examinemos cada posible
escenario en este caso de uso, recuerde que tales escenarios podran aparecer durante la conversin con los
usuarios.
Ejemplo de Casos de Uso: El Caso de Uso Comprar Gaseosa :
El actor, en este caso de uso, es un cliente que desea comprar una lata de gaseosa, el escenario
iniciara cuando el cliente inserte dinero, posteriormente realizara una seleccin; y si todo funciona bien, la
maquina contara con, al menos, una lata de la gaseosa elegida, misma que pondr al alcance del
cliente.,adems de la secuencia, hay otros aspectos del escenario anterior que merecen cierta consideracin
Qu condiciones llevaron al cliente a iniciar el escenario en el caso de uso comprar gaseosa la sed es la mas
obvia, Qu se obtiene como resultado de tal escenario?, nuevamente, lo obvio es que el cliente tenga una
gaseosa en su poder.
Lo que he descrito es la nica posibilidad de comprar gaseosa?, habra otras cuestiones que
saltaran a la vista, por ejemplo:, es posible que la mquina no tenga la gaseosa que desee el cliente; tambin
es posible que el cliente no tenga el importe exacto de la gaseosa, Cmo diseara a la mquina de gaseosas
para controlar tales escenarios?. Veamos el caso en que la maquina se haya quedado sin gaseosa, otra
secuencia de pasos en el caso de uso comprar gaseosa, imaginero como una ruta alternativa dentro del caso
de uso, el cliente inicia el caso de uso al insertar dinero en la maquina y posteriormente hace una seleccin. La
maquina no cuenta con ninguna lata de la gaseosa seleccionada, por lo que mostrara un mensaje al cliente que
indicara que no tiene de esa marca, lo ideal seria que el mensaje le pida al cliente que haga otra seleccin, la
maquina tambin debera dar la opcin de devolver el dinero al cliente.
En este punto, el cliente selecciona otra marca que la maquina entregara (siempre y cuando cuente con
provisiones de esta marca), o devolver el dinero. La condicin previa es un cliente sediento y el resultado es
una lata de gaseosa o la devolucin del dinero. Analicemos ahora el escenario de la cantidad de dinero
incorrecta, nuevamente, el usuario inicia el caso en la forma usual y posteriormente hace una seleccin.,
asumamos que la maquina tiene provisin de la marca elegida, en la maquina hay una reserva de moneda
fraccionaria y devuelve la diferencia al despachar la gaseosa.

174

Si la maquina no cuenta con una reserva de moneda fraccionaria, devolver el dinero y mostrara un
mensaje que pida el importe exacto, la condicin previa es la ya indicada, el resultado ser una lata de gaseosa
junto con el cambio, o la devolucin del dinero originalmente depositado. Otra posibilidad es que tan pronto
como se agote la moneda fraccionaria, aparezca un mensaje que informe a los clientes que se requiere el
importe exacto, el mensaje permanecer a la vista hasta que la maquina sea reabastecida con moneda
fraccionaria.
Casos de Usos Adicionales: Ya ha examinado a la maquina de gaseosas desde el punto de vista de un
usuario: el cliente, hay otros usuarios que intervienen, como el proveedor que tiene que reabastecer a la
maquina, el recolector de dinero (que tal vez sea el mismo que el proveedor) que tiene que recoger el dinero
acumulado en la alcanca e la maquina, etc. Esto nos indica que debemos crear al menos dos casos de usos:
reabastecer y recolectar dinero, cuyos detalles surgirn durante las entrevistas con los proveedores y los
recolectores. Veamos el caso de uso reabastecer, el proveedor inicia este caso de uso dado que algn
intervalo (digamos dos semanas) ha pasado, el representante del proveedor le quita el seguro a la maquina (tal
vez mediante una llave y un cerrojo, pero eso entra dentro de la implementacin), jala la puerta para abrir la
maquina, y llena el compartimiento de cada marca hasta su capacidad. El representante tambin rellena la
reserva de moneda fraccionaria, luego, cierra el frente de la maquina y vuelve a poner el seguro, la condicin
previa es el paso del intervalo, el resultado es que el proveedor cuenta con un nuevo conjunto de ventas
potenciales.
Para el caso de uso de recolectar dinero, el recolector inicia debido tambin a que ha pasado cierro
tiempo, la persona deber seguir la misma secuencia que en reabastecer para cerrar y poner el seguro a la
maquina, la condicin previa es el paso del intervalo y el resultado es el dinero en las manos del recolector. Vea
que cuando derivamos un caso de uso, no nos preocupamos por la forma de implementarlo, en nuestro
ejemplo, no nos interesamos en los aspectos internos e la maquina de gaseosas, tampoco por la forma en que
funcione el mecanismo de refrigeracin o por la forma en que la maquina controle la cantidad de dinero que
contenga, tan solo intentamos ver la forma en que la maquina lucir para alguien que tenga que utilizarla. El
objetivo es derivar una coleccin de casos de uso que, finalmente, mostraremos a las personas que diseen la
maquina de gaseosas y a las personas que la constituirn, por aadidura, nuestros casos de uso reflejan lo que
los clientes, recolectores y proveedores desean, por lo que el resultado ser una maquina que todos esos
grupos puedan utilizar con facilidad.

175

Inclusin de los Casos de Uso: En los casos de uso reestablecer y recolectar dinero, tal vez distingui
ciertos pasos en comn, ambos empezaban con abrir la maquina y finalizaban con el cierre de la maquina y su
aseguramiento, podramos eliminar la duplicacin de pasos de un caso de uso a otro?. Si podemos, la forma
de hacerlo es tomar cada secuencia de pasos en comn y conformar un caso adicional a partir de ellos,
combinemos los pasos necesarios para quitar el seguro y abrir la maquina y llammoslo exhibir el interior y
los pasos cerrar la maquina y asegurarla en otro caso de uso llamado cubrir el interior.
Con estos nuevos casos de uso a la mano, el caso de uso reabastecer iniciara con el caso de uso
exhibir el interior, luego el representante del proveedor seguir los pasos ya indicados, y concluir con el caso
de uso cubrir el interior, de forma similar el caso de uso recolectar dinero iniciara con exhibir el interior,
procedera como se indico, y finalizara con el caso e uso cubrir el interior. Como ve reabastecer y recolectar
dinero incluyen los nuevos casos de uso, por ello, a esa tcnica de aprovechamiento de un caso de uso se le
conoce como inclusin a un caso de uso.
Extensin de los Casos de Uso: Es posible volver a utilizar un caso de uso de una forma distinta a una
inclusin, en ocasiones crearemos un caso de uso agregndole algunos pasos a un caso de uso existente.
Regresemos al caso de uso reabastecer, antes e colocar nuevas latas de gaseosas en la maquina, suponga
que el representante del proveedor nota las marcas que se han vendido bien, as como las que no se han
vendido tambin, en lugar de solo reabastecer todas las marcas, el representante podra sacar aquellas que no
se han vendido bien y reemplazarlas por latas de las marcas que han probado ser mas populares. De esta
forma tendra que indicar al frente e la maquina en nuevo surtido de marcas disponibles. Si agregamos estos
pasos a reabastecer, tendremos un nuevo caso de uso que llamaramos reabastecer de acuerdo a las
ventas, este nuevo caso de uso es una extensin del original, accin a la que se le conoce como extensin de
un caso de uso.
8.1 Estudio de Campos
Casos de Uso (Use Case):
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en
desarrollo, adems de la forma, tipo y orden en como los elementos interactan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos de Uso.
Relaciones de uso, herencia y comunicacin

176

Actor: Una definicin previa, es que un actor es un rol que un usuario juega con respecto al sistema. Es
importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente
representa a una persona en particular, sino ms bien la labor que realiza frente al sistema.

Figura 8.1 Representacin grafica de un actor
Caso de Uso: Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea
desde una peticin de un actor o bien desde la invocacin desde otro caso de uso.

Figura 8.2 Representacin grafica de un caso de uso
Relaciones:
Asociacin: Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra
operacin (caso de uso). Dicha relacin se denota con una flecha simple.

Figura 8.3 Representacin grafica de asociacin.
Dependencia o Instanciacin: Es una forma muy particular de relacin entre clases, en la cual una clase
depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada.

Figura 8.4 Representacin grafica de dependencia
Generalizacin: Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de
su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

177

Figura 8.5 Represtacin grafica de generalizacin

Extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas).
Uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un
caso de uso y no se desea mantener copiada la descripcin de la caracterstica. De lo anterior cabe mencionar
que tiene el mismo paradigma en diseo y modelamiento de clases, en donde esta la duda clsica de usar o
heredar.
Actor: Inicia un caso de uso y otro (posiblemente el que inicio, pero no necesariamente) que recibir algo de
valor de el, la representacin grafica es directa, una elipse representa a un caso de uso, una figura agregada
representa a un actor. El actor que inicia se encuentra a la izquierda del caso de uso, y el que recibe a la
derecha, el nombre del actor aparece justo debajo de el, y el nombre del caso de uso aparece ya sea dentro de
la elipse o justo debajo de ella.
Una lnea asociativa conecta a un actor con el caso de uso, y representa la comunicacin entre el actor
y el caso de uso, la lnea asociativa es slida, como la que conecta a las clases asociadas. Uno de los
beneficios del anlisis del caso de uso es que le muestra los confines entre el sistema y el mundo exterior,
generalmente los actores estn fuera del sistema, mientras que los casos de uso estn dentro de el, utilizarn
el rectngulo (con el nombre del sistema en algn lugar dentro de el), para establecer el confn del sistema. Los
actores, casos de uso y lneas de interconexin componen un modelo de caso de uso, la Fig. 8.6 le muestra
estos smbolos:

CASO DE USO
SISTEMA

178

Figura 8.6, Es un Modelo de caso de uso, una figura agregada representa a un actor; una elipse a un caso de
uso y una lnea asociativa representa la comunicacin entre el actor y el caso de uso.

Una nueva vista a la maquina de gaseosas:
Apliquemos los smbolos al ejemplo de la maquina de gaseosas, como recuerda, desarrollo los casos
de uso para una maquina de gaseosas. El caso de uso Comprar gaseosa se encuentra dentro del sistema
junto con reabastecer y recolectar dinero, los actores son el cliente, representante del proveedor y el
recolector, la Figura 8.7 le muestra un modelo UML de caso de uso para maquina de gaseosas.

Recolectar dinero
Reabastecer
Comprar gaseosa
Maquina de Gaseosas
Cliente Cliente
Representante
del Proveedor Representante
del Proveedor
Recolector Recolector

Figura 8.7 Un Modelo de caso de uso proveniente de la mquina de gaseosas
Secuencia de pasos en los escenarios: Cada caso de uso es una coleccin de escenarios y cada escenario
es una secuencia de pasos, como, puede ver tales pasos no aparecen en el diagrama. No se encuentran en
notas adjuntas a los casos de uso, aunque el UML no lo prohbe, la claridad es clave en la generacin de

179

cualquier diagrama y el adjuntar notas a cada caso de uso podra volverlo confuso, Cmo y donde hara la
secuencia de pasos?
El uso de los diagramas de casos de uso ser, por lo general, parte de un documento de diseo que el
cliente y el equipo de diseo tomaran como referencia cada diagrama tendr su propia pgina, de igual manera,
cada escenario de caso de uso tendr su propia pgina, donde se listara en modo de texto a:
El actor que inicia al caso de uso
Condiciones previas para el caso de uso
Pasos en el escenario
Condiciones posteriores cuando se finaliza el escenario
El actor que se beneficia del caso de uso
Tambin puede enumerar las conjeturas del escenario (por ejemplo, que un cliente a la vez utilizar la
mquina de gaseosas) y una breve descripcin de una sola frase del escenario.
Concepcin de las relacione entre casos de uso: El ejemplo de la maquina de gaseosas mostr dos formas
en que los casos de uso se pueden relacionar entre si, una de ellas, la inclusin, le permite volver a utilizar los
procesos de un caso de uso dentro de otro, la otra, extensin, le permite crear un caso de uso mediante la
adicin de pasos a uno existentes. Existen otros dos tipos de relaciones que son generalizacin y
agrupamiento, como en las clases, la generalizacin cuenta con un caso de uso que se hereda de otro, el
agrupamiento es una manera sencilla de organizar los casos de uso.
Inclusin: Examinemos los casos de uso reabastecer y recolectar dinero , ambos se inician mediante la
apertura de la maquina y finalizan con el cierre y sellado de la misma, el caso de uso exhibir el interior se creo
para capturar el primer par de pasos y cubrir el interior para el segundo, tanto reabastecer, como recolectar
dinero incluye este par de casos de uso. Para representar a la inclusin utilizara el smbolo que se usa para la
dependencia entre clases: una lnea discontinua con una punta de flecha que conecta las clases apuntando
hacia la clase dependiente, justo sobre la lnea, agregara un estereotipo: la palabra incluir bordeada por dos
pares de parntesis angulares.

180

La figura 8.8 le muestra la relacin de inclusin en el modelo de caso de uso de la maquina de gaseosas.

Mquina de Gaseosas
Incluir
Exhibir el interior
Reabastecer
Comprar gaseosa
Cubrir interior
Recolectar dinero
Recolector Recolector
Exhibir interior
Cubrir interior
Representante del
proveedor
Cliente
Representante del
proveedor
Figura 8.8 El modelo de caso de uso en la maquina de gaseosas con la inclusin
Extensin: El caso de uso reestablecer podra ser la base de otro caso de uso: reabastecer de acuerdo a las
ventas. En lugar de solo reabastecer la maquina de gaseosas para que todas las marcas tengan la misma
calidad de latas, por lo que podemos decir que el nuevo caso de uso extiende al original dado que agrega otros
pasos a la secuencia del caso de uso original, que se conoce como el caso de uso base.
La extensin solo puede realizarse en puntos indicados de manera especfica dentro de la secuencia
del caso de uso base, a estos puntos se les conoce como puntos de extensin. En el caso e uso reabastecer,
los nuevos pasos (anotar las ventas y abastecer de manera acorde) se daran luego que el representante haya
abierto la maquina y este listo para llenar los compartimientos de las marcas de gaseosas, en este ejemplo, el
punto de extensin es llenar los compartimientos. Como la inclusin, podr concebir la extensin con una
lnea de dependencia (lnea discontinua con punta una punta de flecha), junto con un estereotipo que muestra

181

extender entre parntesis angulares, dentro del caso de uso bsico, el punto de extensin aparecer debajo
del nombre del caso de uso.
La figura 8.9 le muestra la relacin de extensin para reabastecer y reabastecer de acuerdo a las ventas,
junto con la inclusin de relaciones para reabastecer y recolectar dinero.

Exhibir interior
Reabastecer, punto de extensin
llenar los compartimientos
Extender (Llenar
compartimientos)
Cubrir interior
Reabastecer de acuerdo a las
ventas
Incluir
Incluir

Figura 8.9 Un diagrama de casos de uso que muestra la extensin y la inclusin.
Generalizacin: Las clases pueden heredarse entre si y esto tambin se aplica a los casos e uso. En la
herencia de los casos de uso secundario hereda las acciones y significado del primario y adems agrega sus
propias acciones. Puede aplicar el caso de uso secundario en cualquier lugar en donde aplique el primario.

182

En el ejemplo deber imaginar un caso de uso comprar un vaso de gaseosa que se hereda de comprar
gaseosa, el caso e uso secundario tiene acciones como agregar hielo y mezclar marcas de gaseosas.
Modelara la generalizacin de casos de uso de la misma forma que lo hace con las clases: con lneas continuas
y una punta de flecha en forma de triangulo sin rellenar que apunta hacia el caso de uso primario, como se
muestra en la figura 8.10.

Comprar un vaso de gaseosa
Comprar gaseosas

Figura 8.10 Un caso de uso se puede heredar el sentido y comportamiento de otro.
La relacin de generalizacin puede establecerse entre actores, as como entre caso de uso, quiz
tenga personificados al representante del proveedor, al recolector y al agente del proveedor. Si cambia el
nombre del representante como reabastecedor, tanto este como el recolector sern secundarios del agente
proveedor, como lo muestra la figura 8.11.

Agente
proveedor

Recolector

Reabastecedor

Figura 8.11 Como las clases y los casos de uso, los actores pueden estar en una relacin de generalizacin.

183

Agrupamiento: En ciertos diagramas de casos de uso, podra tener varios casos de uso que querr organizar,
esto puede ocurrir cuando un sistema consta de varios subsistemas. Otra posibilidad seria cuando entrevista a
los usuarios para obtener los requerimientos de un sistema, cada requerimiento podra ser representado como
un caso de uso separado, necesitara alguna forma de ordenar los requerimientos por categoras, la forma mas
directa de organizar seria agrupar en un paquete los casos de uso que se relacionen, recuerde que un paquete
aparece como una carpeta tabular. Los casos de uso agrupados aparecern dentro de carpeta.
8.3 Estudio de los Casos
Estudio de un caso que aplica al UML, bajo el contexto del proceso GRAPPLE, en el cual se trataran los
siguientes temas:
El panorama del caso por estudiar
Como descubrir y modelar los procesos del negocio
Sugerencias al hacer entrevistas
La empresa multinacional (y ficticia) La Hudra, Nar y Goniff, S.A., ha hecho una encuesta sobre el mundo
de los restaurantes y ha llegado a sorprendentes conclusiones: a la gente le gusta comer fuera, pero no
disfrutan algunos momentos de esa experiencia.
Bueno, dijo La Hudra, puede haber predicho los resultados de nuestra encuesta, cuando salgo a comer,
me disgusta cuando el mesero toma mi orden y se desaparece por una hora, al ir uno a un restaurante con
clase se espera un trato diferente. Cierto, respondi Nar, En ocasiones cambio de parecer luego de hacer mi
orden y quiero decirle al mesero que aguarde, o tengo una pregunta o algo y no puedo encontrarlo.
Goniff asistente: Estoy de acuerdo, pero, con todo, el comer fuera es divertido; me agrada cuando alguien
me sirve y adems, me gusta la idea de que el personal de cocina me prepare la comida, los resultados de
nuestra encuesta muestran que la mayora de las personas tambin opinan de esa forma. No habra alguna
manera en que podamos mantener la experiencia bsica y mejorarla de alguna forma? Cmo?, pregunto
Nar. Yo se como!, dijo La Hudra. Con tecnologa. Y as fue que decidieron que uno de sus equipos de
desarrollo de software corporativo construyera el restaurante futuro.

184

Aplicacin de GRAPPLE al problema:
Los miembros del equipo de desarrollo se cien de GRAPPLE, saben que la mayor parte del tiempo en
el proyecto deber orientarlo al anlisis y diseo, de esa forma, la codificacin se genera con rapidez y
eficiencia, con lo que aumentara la posibilidad de una instalacin y distribucin sin problemas. El proyecto debe
iniciar con la recopilacin de necesidades, y con la asimilacin del dominio del restaurante, como podr
recordar de la hora anterior, la recopilacin de necesidades consta de las siguientes acciones:
Descubrir los procesos del negocio
Realizar un anlisis del dominio
Identificar los sistemas cooperativos
Descubrir los requerimientos del sistema
Presentar los resultados al cliente
Descubrir los procesos de negocio:
La Hudra, Nar y Goniff lo hacen todo a lo grande, estn listos para entrar al mundo de los restaurantes y
han conformado una divisin de restaurantes LNG. Han contratado a varios restauranteros, meseros
(camareros), chefs y personal de mantenimiento experimentados. Todo lo que esperan es el apoyo tecnolgico
para el restaurante del futuro, luego, establecern su primer restaurante, integro, con todo y la tecnologa para
mejorar el placer de comer en un restaurante.
Los miembros del equipo de desarrollo estn e suerte, iniciarn con un papel en blanco, todo lo que
debern hacer ser comprender los procesos del negocio y el dominio para continuar en esa lnea. El anlisis
del proceso del negocio empieza con la entrevista de un analista a un restaurantero, durante la entrevista,
alguien tomara nota en una computadora porttil, al mismo tiempo, un modelador plasmara en una pizarra
blanca un diagrama de actividades que el analista, quien esta tomando nota y el restaurantero podrn ver. En
las siguientes subsecciones, seguiremos la entrevista en cada proceso del negocio en un restaurante, la meta
es producir los diagramas de actividades que modelen los procesos.
Servir a un Cliente: Gracias por atendernos, dice el analista. Es un placer, dice el restaurantero. Qu es
exactamente lo que desean saber? Empecemos con una sencilla transaccin de negocios. Qu sucede
cuando un cliente entra al restaurante? Bueno, si el cliente tiene un abrigo o chaqueta, le ayudamos a
quitrselo, lo almacenamos en un guardarropa y le damos un boleto para solicitarlo posteriormente, eso mismo
hacemos con un sombrero, luego, nosotros

185

Un momento, suponga que hay una lnea de espera.Primero se forma, o da su nombre al capitn,
o? No intentamos que se sienta tan cmodo como sea posible al llegar, luego nos preocupamos por la lnea
de espera, en caso de haber alguna. De hecho, si hay una lista de espera, le preguntamos al cliente si hizo
alguna reservacin, si la hizo, intentamos honrarlos de forma oportuna y darles asiento tan pronto como sea
posible, si no hay una reservacin, deja su nombre y puede ir a nuestro bar para tomar algo antes de comer.
Claro no es obligatorio que lo hagan, pueden tan solo sentarse en un rea de espera claramente indicada.
Interesante, an no se han sentado a comer y ya se han logrado algunos puntos decisivos.
Hagamos una pausa para determinar a donde llegamos, el diagrama del proceso del negocio ahora luce como
la figura 8.12

Figura 8.12 Las fases iniciales del diagrama del proceso del negocio del restaurante servir a un cliente

Guardarlo
Esperar enel bar
Prefiere el bar
Lista de espera
Trae abrigo y/o sombrero
Ayudarle a
quitrselo
Prefiere el rea de espera
Aguardar en el
rea de espera
Dejar su
nombre

186
Anlisis y Diseo de Sistemas de Informacin

Antologa

187

Tiene abrigo y/o sombrero
Entra el cliente

Ayudarle a
quitrselo
Lista de espera
Dejar el nombre
Esperar en el
bar
Aguardar en el
rea de espera
Prefiere el bar

Guardar abrigo

Sentar al cliente
No hizo reservacin

Alistar lamesa

Llamar al mesero
Mostar el men
Desea bebida
Servir pan y agua
Llamar al asistente
Traer bebida
Ir por lasbebidas
Sugerir platillo Leer men Elegir
Notificar al
chef

Preparar
platillo
Traer
entrem
Ingerir entrems
Traer plato
fuerte
Ingerir plato
fuerte
Traer postre
Traer
postre
Servir caf
Ingerir
postre
Beber caf
Traer cuenta
Recoger abrigoosombrero Salir
Liquidar cuenta,
dejar propina
Servir caf
Toma un
pedido de
bebidas

Figura 8.13
El
diagrama
de
actividades
completo
para el
proceso
del negocio
del
restaurante


Mozo de piso

Cliente
Entrar

Quitar
abrigo/so
mbrero
Guardar
abrigo/so
mbrero
Dejar
nombr
Aguard
ar en el
bar
Aguardar
en el rea
de espera
Sentar al
cliente
Llamar al
mesero
Entregar
men
Tomar
orden de
bebidas
Llamar al
asistente
Ir por
bebida
Traer
Servir pan
y agua
Capitn de
meseros
Mesero Chef Asistente
Alistar la
mesa

188

Continuacin

Mozo de piso
Desea postre
Asistente
Chef
Ingerir
plato
fuerte

Traer men
de postres
Servir
caf
Servir
caf
Traer
postre
Desea
caf
Tomar
caf
Salir
Liquida
r cuenta
Traer cuenta
Cliente
Leer
men
Capitn de meseros Mesero
Sugerir
platillos
Hacer
eleccin
Notificar al
chef
Traer
entrems
Ingerir
entrem
s
Traer plato
fuerte
Preparar
plato fuerte

189

Recibir comanda
Iniciar la preparacin
del plato fuerte
Preparar entrems
Llevar entrems
Coordinar la preparacin
de otros pedidos
Ingerir entrems
Recibir la
notificacin de que
los entremeses casi
se han consumido

Llevar plato fuerte
Tomar el plato fuerte
Finalizar la preparacin del plato fuerte

Figura 8.15 Un diagrama de actividades para Preparacin de platillos

190

IX EL FUTURO DE LOS SISTEMAS DE INFORMACION
A la hora de tomar decisiones estratgicas en cuanto a la marcha de una empresa, las tcnicas de
soporte a la toma de decisiones, apoyan al directivo. De igual modo sucede en diversas aplicaciones que van
desde las industrias de produccin, entretenimiento, etc.
Entretenimiento: Los videojuegos han llegado a ser calificados por algunos como cine interactivo, pero en
realidad tienen un uso social muy especfico y actualmente constituyen un mercado de una rentabilidad superior
a la de la industria del cine. De todas las aplicaciones informticas que han ido surgiendo en los ltimos aos en
torno a la imagen y los medios audiovisuales, los videojuegos constituyen el primer xito comercial. Los juegos
de inmersin en un espacio virtual podemos encontrarlos en parques de atracciones o, los ms modestos, en
salas de juegos recreativos. En esencia son simuladores de algn tipo de experiencia: viaje en un avin a
reaccin que rompe la barrera del sonido, viaje a la luna en el trasbordador espacial, viaje a Marte de diez
minutos, expedicin al lago Ness, mina del diablo con piscinas llenas de cido corrosivo, tneles de cal viva,
barriles de plvora que estallan, etc.

En cuanto a los aspectos formales de los videojuegos podemos observar, generalmente, en una
estructura planificada, sistemtica y predecible, con opciones predefinidas. La estructura tpica consiste en una
trayectoria con un principio, una secuencia de desplazamientos con incidentes redundantes y un final que
valora con una puntuacin al jugador. Los procesos son ms importantes que los sujetos, lo que se traduce en
tcnicas de animacin limitada (por ejemplo slo se mueven brazos y piernas) y en la estereotipacin de los
personajes y de los objetos.

Publicidad: Es frecuente el uso de los sistemas multimedia interactivos con fines publicitarios. Las primeras
aplicaciones destacables de los multimedia a la publicidad han sido las del sector financiero. de forma similar a
la instalacin de cajeros automticos, se instalan terminales, frecuentemente multimedia, destinados a ofrecer
todo tipo de informacin financiera a los potenciales clientes. Tambin se pueden establecer puntos de
informacin comercial en ferias y superficies de venta. Cul es el secreto de este xito tan rpido? Pues,
lgicamente, que el sistema consigue una gran eficacia comercial. Las entidades bancarias y financieras
conciben los terminales interactivos como un apoyo bsico para la venta de sus productos. Se ha comprobado
que cerca de un 90% de los usuarios que realiza la simulacin de un crdito en una terminal de informacin
acaban las operaciones. La interactividad evidentemente es una ventaja para el usuario en cuanto que puede
disponer de una mayor soberana en el proceso de lectura del mensaje recibido, pero tambin constituye una
mayor facilidad persuasiva para el emisor del mensaje. En un anuncio televisivo se pone en juego un gran
despliegue persuasivo, confiando en que la forma de procesar la informacin recibida por parte de los
espectadores, sea capaz de originar una determinada conducta favorable comprar un producto, o ser prudente
en a carretera, etc. a los propsitos del anunciante.

191

Que un sistema sea capaz de captar la atencin y el inters de un usuario, depende en gran medida de
un adecuado tratamiento audiovisual e interactivo del programa con el cual el cliente debe dialogar. No poda
ser de otra manera, puesto que es el programa con el que realiza las funciones del vendedor. Y por regla
general sabemos que un buen vendedor siempre consigue buenos resultados, la interactividad permite conocer
rpidamente la reaccin del usuario, es ms, persigue una reaccin inmediata que se traduzca en consumo.
Sistemas empotrados: En primer lugar, resulta significativo el hecho de que cada vez es mayor el nmero y la
variedad de sistemas de tiempo real que toman la forma de sistemas empotrados en todo tipo de sistemas de
ingeniera y de consumo. El abaratamiento del hardware ha hecho posible la extensin de los sistemas de
tiempo real empotrados, que hasta hace poco se limitaban a sistemas de alto coste y alta tecnologa, a los
productos de uso cotidiano. As, los sistemas de tiempo real ya no se encuentran nicamente en sistemas de
control de aviones o cohetes, control de fbricas o sistemas de telecomunicacin complejo sino que tambin
forman parte, a menudo invisible, de productos como telfonos mviles, reproductores de discos DVD,
televisores e incluso afeitadoras o aspiradoras. Por otro lado, todo hace pensar que en los sistemas del futuro
convergern una serie de tecnologas, cuya evolucin hay que tener en cuenta si queremos tener al menos un
atisbo de cules sern sus caractersticas ms importantes.
Algunos de estos campos son:

Comunicaciones: Los medios de comunicacin para sistemas de tiempo real tienen que cumplir un requisito
fundamental: es necesario poder predecir la duracin mxima del tiempo de transmisin de los mensajes. Esta
necesidad slo se ha manifestado recientemente y ha dado lugar a la aparicin en los ltimos aos de
protocolos de comunicacin con tiempo de transmisin determinista. Aunque el motivo principal de estos
desarrollos ha sido la necesidad de implementar sistemas de tiempo real distribuidos en la industria del
automvil, se ha extendido rpidamente a otros campos de aplicacin. Es de esperar que esta tendencia
contine y que en un futuro prximo se generalicen los protocolos de comunicacin con comportamiento
temporal previsible, junto un mayor ancho de banda y tolerancia de fallos. El desarrollo de protocolos de
comunicacin por radio, adems, facilitar previsiblemente el desarrollo de sistemas empotrados porttiles.

Ingeniera de software: El abaratamiento del hardware y el incremento de la densidad de integracin facilitan
la realizacin de sistemas de tiempo real cada vez ms complejos. Es de prever que esta tendencia contine en
el futuro prximo, lo que hace necesario disponer de mtodos y herramientas adecuado para desarrollar
sistemas de tiempo real complejos, teniendo en cuenta adems que la dificultad de desarrollar este tipo de
sistemas es mayor que en el caso de sistemas convencionales. Esto se debe a que hay que considerar los
requisitos temporales y fiabilidad, ya que los fallos en estos sistemas pueden causar cuantiosos daos
materiales, e incluso en ocasiones la prdida de vidas humanas.

192

Que un sistema sea capaz de captar la atencin y el inters de un usuario, depende en gran medida de
un adecuado tratamiento audiovisual e interactivo del programa con el cual el cliente debe dialogar. No poda
ser de otra manera, puesto que es el programa con el que realiza las funciones del vendedor. Y por regla
general sabemos que un buen vendedor siempre consigue buenos resultados, la interactividad permite conocer
rpidamente la reaccin del usuario, es ms, persigue una reaccin inmediata que se traduzca en consumo.
Sistemas empotrados: En primer lugar, resulta significativo el hecho de que cada vez es mayor el nmero y la
variedad de sistemas de tiempo real que toman la forma de sistemas empotrados en todo tipo de sistemas de
ingeniera y de consumo. El abaratamiento del hardware ha hecho posible la extensin de los sistemas de
tiempo real empotrados, que hasta hace poco se limitaban a sistemas de alto coste y alta tecnologa, a los
productos de uso cotidiano. As, los sistemas de tiempo real ya no se encuentran nicamente en sistemas de
control de aviones o cohetes, control de fbricas o sistemas de telecomunicacin complejo sino que tambin
forman parte, a menudo invisible, de productos como telfonos mviles, reproductores de discos DVD,
televisores e incluso afeitadoras o aspiradoras. Por otro lado, todo hace pensar que en los sistemas del futuro
convergern una serie de tecnologas, cuya evolucin hay que tener en cuenta si queremos tener al menos un
atisbo de cules sern sus caractersticas ms importantes.
Algunos de estos campos son:

Comunicaciones: Los medios de comunicacin para sistemas de tiempo real tienen que cumplir un requisito
fundamental: es necesario poder predecir la duracin mxima del tiempo de transmisin de los mensajes. Esta
necesidad slo se ha manifestado recientemente y ha dado lugar a la aparicin en los ltimos aos de
protocolos de comunicacin con tiempo de transmisin determinista. Aunque el motivo principal de estos
desarrollos ha sido la necesidad de implementar sistemas de tiempo real distribuidos en la industria del
automvil, se ha extendido rpidamente a otros campos de aplicacin. Es de esperar que esta tendencia
contine y que en un futuro prximo se generalicen los protocolos de comunicacin con comportamiento
temporal previsible, junto un mayor ancho de banda y tolerancia de fallos. El desarrollo de protocolos de
comunicacin por radio, adems, facilitar previsiblemente el desarrollo de sistemas empotrados porttiles.

Ingeniera de software: El abaratamiento del hardware y el incremento de la densidad de integracin facilitan
la realizacin de sistemas de tiempo real cada vez ms complejos. Es de prever que esta tendencia contine en
el futuro prximo, lo que hace necesario disponer de mtodos y herramientas adecuado para desarrollar
sistemas de tiempo real complejos, teniendo en cuenta adems que la dificultad de desarrollar este tipo de
sistemas es mayor que en el caso de sistemas convencionales. Esto se debe a que hay que considerar los
requisitos temporales y fiabilidad, ya que los fallos en estos sistemas pueden causar cuantiosos daos
materiales, e incluso en ocasiones la prdida de vidas humanas.

193

Por este motivo resulta preocupante la visin, ingenua pero frecuente, de que el desarrollo de sistemas
empotrados se simplifica utilizando sin ms los mtodos de desarrollo de software que han dado buenos
resultados en otros campos de aplicacin, o que hacer sistemas de tiempo real consiste nicamente en hacer
sistemas ms rpidos o ms eficientes. Para poder desarrollar este tipo de sistemas de forma que satisfagan
los requisitos de determinismo temporal y fiabilidad que les son inherentes manteniendo unos costes
razonables, es absolutamente necesario disponer de tcnicas de ingeniera de software ms avanzadas. En
este sentido se dispone un buen bagaje de tcnicas de diseo y anlisis desarrolladas en su mayor parte en los
ltimos diez aos, que se pueden utilizar de manera efectiva para conseguir estos objetivos. No obstante
resulta preocupante el hecho de que en algunos desarrollos recientes de lenguajes de programacin o de
sistemas operativos se hayan ignorado casi complemente los avances tecnolgicos realizados en este campo
en los ltimos aos.

Inteligencia artificial: La complejidad de las aplicaciones de sistemas de tiempo real del futuro hace pensar
que ser necesario emplear tcnicas de inteligencia artificial para adaptar su comportamiento a los cambios del
entorno, aprender y emplear tcnicas de toma de decisiones, y para aumentar su autonoma y prestaciones.
Estas tcnicas ya se utilizan en muchos tipos de sistemas informticos, pero la satisfaccin de requisitos
temporales presenta dificultades adicionales que no siempre se sabe resolver de manera adecuada. El
desarrollo de tcnicas que permitan compatibilizar los mtodos de la inteligencia artificial con un
comportamiento temporal previsible dar todava trabajo a la prxima generacin de investigadores.

Sistemas distribuidos: Es previsible que la mayora de los sistemas de tiempo real del futuro sern
distribuidos. La necesidad de utilizar diversos computadores estar motivado por la necesidad de disponer de
una gran potencia de cmputo, por la distribucin fsica de estos sistemas y por la necesidad de hacer que
toleren una mayor cantidad y variedad de fallos. Problemas como la sincronizacin de los relojes de los
diversos procesadores, el determinismo temporal y la distribucin dinmica de la carga son algunos aspectos
que debern ser solucionados de forma adecuada.

Tolerancia de fallos: La necesidad de disponer de sistemas fiables y que puedan funcionar de manera
continua es cada vez ms frecuente, y es previsible que se acreciente en el futuro prximo. Para tal fin, las
tcnicas de tolerancia de fallos, tanto de hardware como de software, debern tener en cuenta los requisitos
temporales, de forma que la recuperacin y el tratamiento de los fallos de hardware o de software no impliquen
una degradacin inadmisible del comportamiento temporal del sistema. La previsin consiste en que los
sistemas de tiempo real sern una tecnologa de base para desarrollar sistemas de control empotrados con una
serie de caractersticas comunes.

194

Sern autnomos, en el sentido que tendrn prefijadas sus funciones y las realizarn sin intervencin
humana directa. Para ser capaces de realizar estas funciones, ser imprescindible disponer de sistemas
sensoriales avanzados que les permitan conocer el estado de los elementos del entorno, segn sea necesario.
Dispondrn de capacidades de comunicacin inalmbricas, lo que les permitir comunicar con los humanos,
entre ellos y con centros avanzados de control. Tendrn capacidades de aprendizaje y de adaptacin a
entornos cambiantes. Los dispositivos generales descritos tendrn una aplicacin especfica en distintos
campos, que se analizan a continuacin con algo ms de detalle.

Transporte: Uno de los campos de aplicacin ms importantes de los sistemas de tiempo real ha sido
tradicionalmente el control de los medios de transporte, como aviones, trenes, etc. Una de las tendencias ms
interesantes en relacin con este tipo de sistemas es la de conseguir un funcionamiento autnomo de los
mismos.

Los sistemas de tiempo real (STR) son sistemas informticos que se encuentran en multitud de
aplicaciones, desde la electrnica de consumo hasta el control de complejos procesos industriales, estn
presentes en prcticamente todos los aspectos de nuestra sociedad como, telfonos mviles, automviles,
control de trfico, ingenios espaciales, procesos automticos de fabricacin, produccin de energa, aeronaves,
etc. Adems, el auge de los Sistemas de tiempo real est en constante aumento, ya que cada vez ms
mquinas se fabrican incluyendo un nmero mayor de sistemas controlados por computador. Un claro ejemplo
es la industria del automvil; un turismo actual de gama media incluye alrededor de una docena de estos
automatismos (ABS, airbag, etc). Otro claro ejemplo son los electrodomsticos de nueva generacin, que
incluyen Sistemas de tiempo real para su control y temporizacin. Hoy da son tantas las aplicaciones de estos
sistemas que su nmero duplica actualmente al de los sistemas informticos "convencionales" o de propsito
general. Las previsiones son que esta diferencia vaya en constante aumento, debido fundamentalmente el
elevado crecimiento de la automatizacin en casi todas las facetas de la vida cotidiana. Esto convierte a esta
asignatura en un complemento muy atractivo para la formacin de un Ingeniero Informtico.
La caracterstica diferenciadora de los sistemas de tiempo real es que sus acciones deben producirse
dentro de unos intervalos de tiempo determinados por la dinmica del sistema fsico que supervisan o controlan.
Por poner un ejemplo, el sistema de control de inyeccin de combustible en un motor alternativo (como los que
estn presentes en los automviles) debe realizar la inyeccin de la mezcla dentro del intervalo de tiempo
marcado por la rotacin del motor, de otro modo el motor no funcionar correctamente. En este caso, se trata
de un sistema de tiempo real empotrado, es decir, el sistema informtico se encuentra fsicamente incluido en
un sistema de ingeniera ms complejo.

195

La mayora de los sistemas de tiempo real son sistemas empotrados y suelen tener restricciones
adicionales en cuanto al uso de recursos computacionales con respecto a otros tipos de sistemas informticos.
Adems, suelen tener requisitos de seguridad y fiabilidad mas severos, ya que si el sistema falla puede
ocasionar prdidas econmicas (por ejemplo, avera del motor) o incluso humanas (por ejemplo, si el motor
fuera de una aeronave).
La complejidad es mayor en el caso de otros medios de transporte como los aviones, trenes o
automviles. Los avances que se estn produciendo en sistemas de navegacin, censores e inteligencia
artificial permiten esperar un progreso notable en aplicaciones como el despegue, aterrizaje y navegacin de
aviones, o en el funcionamiento automtico de los sistemas de control y circulacin de trenes.
Fabricacin automtica: La utilizacin de las tecnologas descritas en la industria permite esperar el desarrollo
de fbricas automticas. Un conjunto de robots y mquinas especiales se encargarn de fabricar los productos
con mnima intervencin de operadores. La capacidad de adaptacin y reconfiguracin de estos componentes
podra permitir cambiar las caractersticas del producto fabricado en un tiempo muy reducido. De esta manera
aumentar la flexibilidad de estas instalaciones y ser posible el desarrollo de productos a la carta. Los
componentes de una fbrica podran estar conectados a los centros de planificacin mundiales de la compaa,
lo que permitira ajustar la cantidad y el tipo de productos a fabricar.

Los Sistemas Expertos:

Sistemas expertos en las empresas: Desde que naciera la Inteligencia Artificial como tal ciencia, a principios
de los 60, hasta la actualidad, se han venido realizando numerosos trabajos, especialmente en los Estados
Unidos, para el desarrollo de los diversos campos que componen la Inteligencia Artificial. De todos esos
campos, quiz el que puede tener mayor nmero de aplicaciones prcticas sea el de los Sistemas Expertos,
siendo dichas aplicaciones de utilidad en temas tan variados que pueden ir desde la medicina hasta la
enseanza. En las empresas, los Sistemas Expertos empiezan a tener cada vez mayor auge, hasta el punto de
ir suponiendo un punto de referencia importante en la toma de decisiones para la junta directiva. En realidad,
incluso se podra decir que el lmite de las aplicaciones objeto de los Sistemas Expertos est en la imaginacin
humana, siendo siempre de utilidad all donde se necesite un experto. El sistema experto ayuda a la gestin de
una empresa por medio de:
Interpretacin
Diagnosis
Prediccin
Monitorizacin

196

Ejemplo: Dentro de este grupo podemos incluir tambin el sistema que recibe seales de habla fonticas e
identifica las frases a partir del flujo de seales en el tiempo.
Prediccin: En este apartado se encuentran los SSEE de apoyo a las decisiones. Y prcticamente son los
nicos pertenecientes a esta categora.
Monitorizacin: Son sistemas de diagnostico pero que tienen la limitacin de la necesidad de operar en tiempo
real, es decir con una fuerte restriccin de tiempo. Leen como entrada una situacin y deben producir tanto la
interpretacin como el diagnostico en un intervalo de tiempo predefinido como se comentaba. Como un tipo de
sistema especial, encontramos aquellos que podramos llamar como de ayuda a la educacin, es decir, que
supervisan al alumno en la resolucin de problemas. Tienen la dificultad adicional de acepar el trabajo del
alumno y saber corregirlo, no solo de solucionar los problemas propuestos.
Criterios de posibilidad y viabilidad: A la hora de la realizacin de un sistema experto, como cualquier otro
producto informtico, ciertos aspectos deben ser tenidos en cuenta, de forma que nos aseguren cierta
probabilidad de xito. As los Sistemas Expertos basados en reglas tienen un mbito de aplicacin ciertamente
amplio, si bien debe ser evaluado si el mbito del proyecto se adapta a las caractersticas de este paradigma.
Cabe distinguir los siguientes rasgos:
El procedimiento de resolucin empleado sin el sistema, actualmente debe tener un componente
importante de razonamiento. Siendo claramente menos relevantes, los aspectos de calculo.
El proceso de resolucin utilizado por los expertos, debe ser suficientemente conocido. Su nivel de
complejidad debe ser tal que resuelva los problemas en plazos razonables; de esta forma, el tamao
del dominio del discurso (numero de conceptos y atributos), ser limitado y manejable. Es importante
que el nmero de expertos dispuestos a colaborar sea suficiente.
El proceso de resolucin empleado, si se plantea algortmicamente, debe tener una complejidad
combinatoria importante, de forma que pueda apreciarse el empleo de una base de conocimiento como
reductor de la explosin combinatoria.
Por la naturaleza de reglas de los sistemas expertos, el conocimiento debe poder introducirse de forma
incremental en el. Donde existen lneas coincidentes entre tcnicas de investigacin operativa e
inteligencia artificial, con la diferencia de que para los objetivos de aquella (bsqueda de algoritmos
matemticos ptimos) la heurstica es un recurso, mientras que la inteligencia artificial es prcticamente
el mtodo, ya que el conjunto de heursticos es ya una base de conocimiento elemental.
Sistemas de Interfase. que ayudan en la formulacin del problema para el modelo de simulacin,
cuando la complejidad de este lo justifique.
Sistemas asesores, que incorporan la experiencia de los utilizadores del modelo y sintetizan una
muestra pasada de este, en donde aparecen explcitos datos y resultados de la simulacin.

197

La opcin de sistemas expertos como asesores en el gobierno de organizaciones puede llegar a ser muy
til a la utilizacin de los propios modelos de simulacin en si, se procesan los archivos de resultados de cada
campaa de simulacin con el modelo y se obtienen nuevos elementos de la base de conocimiento
representando esas pasadas. Este proceso repetido a lo largo del tiempo, incorporando adems los conceptos
que los usuarios personales del modelo juzguen oportunos tanto para corregir las propuestas del sistema como
para complementarlas, puede llegar a producir un sistema del que se obtenga directamente conclusiones
suficientes para la planificacin y gobierno de la organizacin o empresa.
El SIAD en la empresa: Es claro que podemos englobar los sistemas de apoyo a la decisin, entre aquellos
sistemas expertos orientados hacia la prediccin. Adems podemos hacer la siguiente clasificacin:
Ayuda a la valoracin de situaciones, se trata de un sistema experto de prediccin, que trata de obtener
conclusiones acerca de la posible evolucin del sistema (empresa, negocio, etc.), sobre la base de los
actuales parmetros introducidos.
Ayuda a la toma de decisiones, en base a la poltica de la empresa, la situacin actual y cualquier otro
posible factor que seguramente enriquecer la toma de la decisin.
Ayuda a la operacin legal, tratan exclusivamente de la ayuda a los lideres burocrticos o legales.
Podemos constatar, sin lugar a dudas que los sistemas expertos se engloban en los sistemas de
informacin de la empresa. Constituyendo simplemente una herramienta informtica mas para ensear a los
futuros usuarios.
El modelo: Se trata del modelo de razonamiento en el sistema lo que le correspondera en un sistema experto
clsico con el motor de inferencias. Si bien en este tipo de sistemas es probable que haya incluso mas de una
herramienta colaborando en la obtencin del resultado final.
Sistemas Expertos en los diversos campos de aplicacin: Un Sistema Experto es una aplicacin informtica
que simula el comportamiento de un experto humano en el sentido de que es capaz de decidir cuestiones
complejas, si bien en un campo restringido. Para esto, se debe tener en cuenta que la principal caracterstica
del experto humano viene a ser el conocimiento o habilidades profundas en ese campo concreto, por
consiguiente, un Sistema Experto debe ser capaz de representar ese conocimiento profundo con el objetivo de
utilizarlo para resolver problemas, justificar su comportamiento e incorporar nuevos conocimientos. Se podra
incluir tambin el hecho de poder comunicarse en lenguaje natural con las personas, si bien esta capacidad no
es tan determinante como las anteriores de lo que se puede definir como Sistema Experto. La potencia de un
Sistema Experto se basa ms en una gran cantidad de conocimientos que en un formalismo deductivo muy
eficaz. La idea que se persigue cuando se construye un Sistema Experto es la de automatizar la labor del
experto, partiendo en ocasiones de informacin insuficiente o incompleta.

198

Segn la clase de problemas hacia los que estn orientados, podemos clasificar los Sistemas Expertos
en diversos tipos entre los que cabe destacar diagnosis, pronstico, planificacin, reparacin e
instruccin; vamos a ver algunas de las aplicaciones existentes (o en periodo de desarrollo) para cada uno de
los campos citados. Los sistemas de diagnosis siguen un proceso de bsqueda de las razones del
funcionamiento incorrecto de un sistema a partir de la informacin disponible. Aqu se podran tener en cuenta
tanto aplicaciones de diagnstico mdico como de averas. Otro tipo de Sistemas Expertos son los orientados a
la reparacin, sin embargo, no se puede decir que sea un tipo realmente nuevo, ya que este enfoque abarca
diagnosis y planificacin. Dentro de este grupo se incluyen sistemas como DELTA, que ayuda a los mecnicos
en el diagnstico y reparacin de locomotoras diesel-elctricas. DELTA no solo da consejos expertos, sino que
tambin presenta informaciones por medio de un reproductor de vdeo. De hecho se podra encasillar a DELTA
ms en el rea de la instruccin que en reparacin, dado que adems proporciona ayudas al trabajo que
permiten al estudiante determinar si existe o no un determinado problema, proporcionando tambin formacin
especfica sobre el modo de realizar ciertas reparaciones.
Un sistema de instruccin (Sistema Experto para formacin) realiza un seguimiento del proceso de
aprendizaje de un estudiante. El sistema detecta errores de los estudiantes e identifica el remedio adecuado, es
decir, desarrolla un plan de enseanza para facilitar el proceso de aprendizaje y la correccin de errores.
Adems de DELTA, existen numerosos sistemas de este tipo; STEAMER, por ejemplo, se cre para ensear a
los oficiales de la armada los problemas de funcionamiento de una planta de propulsin a vapor, como las que
impulsan a ciertos barcos. Este era el problema de formacin ms importante que exista, dada la complejidad
de los sistemas. El objetivo es dar al estudiante una concepcin global de lo que pasa en la planta en cualquier
momento, con la ventaja de que adems el modelo de presentacin es grfico (utilizando Interlisp). Con un
objetivo similar al de STEAMER, Construcciones Aeronuticas S. A. (CASA) desarroll el Proyecto Eolo CN-
235. En este caso, el problema est en el hecho de que pilotar un avin que cuesta cientos de millones de
pesetas es un asunto muy serio a la vez que peligroso, lo que exige mucho tiempo de entrenamiento, tanto para
pilotos como mecnicos, suponiendo para las compaas areas un gran problema, dado el elevado coste de
los cursos y la escasez de instructores. El proyecto surgi de la voluntad de Construcciones Aeronuticas S. A.
de ofrecer un curso especfico para pilotos y tcnicos de mantenimiento, a todos los compradores del avin CN-
235. Eolo CN-235 es un sistema de enseanza interactivo que integra grficos, texto y vdeo.
Otro sistema de este tipo, aunque en este caso orientado a medicina, es GUIDON, pensado para que lo
utilicen las Facultades de Medicina para formar a los mdicos en la realizacin de consultas. GUIDON viene a
ser una reorganizacin de MYCIN con intenciones educativas, por esto, tiene la ventaja adicional de disponer
de toda la base de conocimientos de MYCIN adems de la experiencia acumulada, por consiguiente, puede
recuperar como ejemplo cualquier caso que MYCIN haya tratado.

199

Adems de las reas de aplicacin ya citadas, existen otras como las relativas a los sistemas de
interpretacin, que realizan tareas de inferencia a partir de una serie de datos observables (p. ej. anlisis de
imgenes, o bien interpretacin de seal). Solamente indicar que el futuro de dichas aplicaciones pasa por la
imaginacin de cada uno, siempre que el rea elegida requiera la presencia de un experto para la obtencin de
cualquier tipo de beneficio.
9.1 Diseo de Sistemas en el Futuro
Tendencias en el desarrollo de sistemas operativos futuros, existen cuatro principios dominantes que
deben regir en el diseo de sistemas operativos futuros:
1.- Abstraccin: El principio de la abstraccin es que un nivel del ambiente de software no debe necesitar "
saber " los detalles sobre la implementacin en otros niveles. Por ejemplo, un Programador no debe requerir
saber qu clase de procesador ser usado cuando se ejecute su programa, y un usuario de correo-electrnico
no debe requerir de conocimientos de los protocolos de red.
2. Robustez y gestin de errores: Los sistemas operativos futuros deben ser extremadamente robustos, sus
metas:
Ninguna accin del usuario debe hacer que el sistema comporte en una extraa o ilgica manera
Debe ser imposible que cualquier programa interrumpa el funcionamiento de otros programas, o de la
mquina en su totalidad. Es decir sin importar las acciones y las decisiones del usuario y del
programador, la computadora nunca debe "colapsarse ". Adems, cualquier acontecimiento inesperado
se debe manjar de una manera prctica. Los problemas que el sistema operativo no puede solucionar
se deben sealar al usuario de una manera no-secreta (tales como un "cuadro de dilogo"), y se deben
explicar de una manera no tcnica (utilizar un lenguaje dependiendo del mdulo de programacin).
El sistema debe enumerar claramente las opciones de las cuales el usuario debe elegir.

200

3.- Estandarizacin: Actualmente, hay numerosos sistemas operativos y sistemas de hardware que se
comportan de varias maneras. Por lo tanto, la comunicacin entre las mquinas de diferente arquitectura es
difcil, y esta situacin es confusa para cualquier usuario que procure cambiarse de una plataforma a otra. Esta
confusin da lugar a un costo significativo debido a la capacitacin y al tiempo perdido durante la transicin y
fase de aprendizaje. Un sistema operativo bien diseado debe ser estandardizado de una manera tal que se
adapte y siga siendo til indefinidamente. Debe crecer en a la par con la tecnologa de cmputo, la
visualizacin, y tecnologas de interaccin, y preferencias del usuario. La naturaleza modular del sistema
operativo del maana ser tal que piezas del sistema sern continuamente modificadas y puestas al da reflejar
estos cambios. Para que estas caractersticas sean posibles, el sistema requerir: 1) un conjunto muy bien
definido de los estndares pblicos disponibles (para la comunicacin entre las capas y los objetos), 2) que este
conjunto de estndares se desarrolle con un cierto plazo de tiempo pero que siga siendo claro y conciso, y 3)
que los estndares no cambien tan rpidamente como para causar problemas de compatibilidad o altos costos
de cambio de hardware.
4.- Diseo para facilidad de empleo y desarrollo de software: La mayora de los sistemas operativos
actuales fueron diseados para ser fciles de poner en ejecucin. En contraste, los sistemas operativos de
maana sern diseados para el uso fcil y el desarrollo fcil. El diseo ser hecho con pocas disminuciones en
cuanto a su facilidad de implementacin con excepcin de su modularidad y estandardizacin inherentes.
Debido a estos buenos principios del diseo, el sistema operativo del maana no ser difcilmente de
implementar. Estas mismas cualidades facilitarn el trabajo de los programadores tambin, en cuanto a la
mayora de los proyectos de desarrollo necesitarn solamente ensamblar objetos de alto nivel. Esos mdulos
que deben escribir para s mismos sern reutilizables y fcilmente adaptables a las necesidades de cada
programador.

201

202

203

Antologia

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Antologia

Uploaded by

Copyright:

Available Formats

Anlisis y Diseo de Sistemas de Informacin Antologa

You might also like