Documents - Tips Administracion de Centros de Informatica PDF

Primera Edicin
OCE-0620
ADMINISTRACIN DE CENTROS DE INFORMTICA
Manual Terico| Luis Fernando Zelaya Iras
Administracin de Centros de Informtica
Manual Terico
INDICE
IDICE ---------------------------------------------------------------------------------------------------------------------- 2
1
COCEPTOS BSICOS DE ADMIISTRACI --------------------------------------------------------- 4

1.1
1.2
1.3
1.4
1.5
1.6
DEFINICIN --------------------------------------------------------------------------------------------------------- 4
LA ADMINISTRACIN UNA CIENCIA O UNA TCNICA? ------------------------------------------------------- 4
RELACIN DE LA ADMINISTRACIN CON OTRAS CIENCIAS -------------------------------------------------- 5
CARACTERSTICAS DE LA ADMINISTRACIN ------------------------------------------------------------------ 5
OBJETIVOS DE LA ADMINISTRACIN ---------------------------------------------------------------------------- 6
PROBLEMAS ESPECFICOS DE LOS ADMINISTRADORES ------------------------------------------------------ 6
SISTEMA DE EMPRESA Y SISTEMA DE ADMIISTRACI --------------------------------------- 7

2.1
2.2
2.3
SISTEMAS DE EMPRESA ------------------------------------------------------------------------------------------- 7

SISTEMAS DE ADMINISTRACIN --------------------------------------------------------------------------------- 9
ELEMENTOS PARA LA CONSTRUCCIN DE SERVICIOS INFORMTICOS ------------------------------------ 12
EL GERETE DE IFORMTICA -------------------------------------------------------------------------- 13
PLAEACI ESTRATGICA Y OPERATIVA --------------------------------------------------------- 14

4.1
4.2
4.3
4.4
4.5
PLAEACI E U CETRO DE IFORMTICA -------------------------------------------------- 23

5.1
5.2
5.3
INTRODUCCIN ---------------------------------------------------------------------------------------------------- 23
COMO MANEJAR LAS PLANIFICACIONES IMPOSIBLES -------------------------------------------------------- 23
COMO GANAR TIEMPO EN UNA PLANIFICACIN DE ACTIVIDADES DEL CENTRO DE INFORMTICA --- 25
ORGAIZACI------------------------------------------------------------------------------------------------- 28
6.1
6.2
6.3
CONCEPTO DE PLANEACIN ------------------------------------------------------------------------------------- 14

OBJETIVOS DE LA PLANEACIN--------------------------------------------------------------------------------- 15
DEFINICIONES DE LOS COMPONENTES DE LA PLANEACIN ------------------------------------------------- 15
ESTRUCTURA DE UN PLAN ESTRATGICO --------------------------------------------------------------------- 19
ESTRUCTURA DE UN PLAN OPERATIVO------------------------------------------------------------------------ 20
DEFINICIN -------------------------------------------------------------------------------------------------------- 28
PASOS DE LA ORGANIZACIN ----------------------------------------------------------------------------------- 28
ESTRUCTURA ORGANIZACIONAL ------------------------------------------------------------------------------- 28
ORGAIZACI: EQUIPOS DE TRABAJO E CETROS DE IFORMTICA -------------- 31

7.1
7.2
7.3
7.4
DEFINICIN -------------------------------------------------------------------------------------------------------- 31
GRUPOS Y EQUIPOS ----------------------------------------------------------------------------------------------- 31
CREACIN DE UN EQUIPO DE ALTO RENDIMIENTO ----------------------------------------------------------- 31
CAUSAS DE FALLO DE LOS EQUIPOS --------------------------------------------------------------------------- 33
8
ORGAIZACI: ESTRUCTURA DE EQUIPOS DE TRABAJO E CETROS DE
IFORMTICA --------------------------------------------------------------------------------------------------------- 35
8.1
8.2
8.3
9
MOTIVACI ---------------------------------------------------------------------------------------------------- 40
9.1
9.2
9.3
9.4
9.5
10
INTRODUCCIN ---------------------------------------------------------------------------------------------------- 35
TIPOS DE EQUIPOS ------------------------------------------------------------------------------------------------ 35
MODELOS DE EQUIPO -------------------------------------------------------------------------------------------- 37
INTRODUCCIN ---------------------------------------------------------------------------------------------------- 40
MOTIVACIONES TPICAS DEL INFORMTICO ------------------------------------------------------------------ 40
CINCO FACTORES PRINCIPALES DE MOTIVACIN ------------------------------------------------------------- 41
USO DE OTROS FACTORES DE MOTIVACIN ------------------------------------------------------------------- 43
DESTRUCTORES DE LA MORAL ---------------------------------------------------------------------------------- 44
LIDERAZGO ------------------------------------------------------------------------------------------------------ 46
2/86
10.1
10.2
10.3
11
DEFINICIN -------------------------------------------------------------------------------------------------------- 53
CONTROLES GENERALES EN EL CENTRO DE INFORMTICA ------------------------------------------------ 53
ESTNDARES EN LOS CENTROS DE INFORMTICA ----------------------------------------------------------- 55
COTROL: PROTECCI DE DATOS, HARDWARE Y SOFTWARE ---------------------------- 60

13.1
13.2
13.3
13.4
13.5
13.6
14
INTRODUCCIN ---------------------------------------------------------------------------------------------------- 49
MODELO DE COMUNICACIN ----------------------------------------------------------------------------------- 49
EL MENSAJE-------------------------------------------------------------------------------------------------------- 50
FORMAS DE COMUNICACIN ------------------------------------------------------------------------------------ 50
TIPOS DE COMUNICACIN --------------------------------------------------------------------------------------- 51
DIRECCIONES DE LA COMUNICACIN --------------------------------------------------------------------- 51
COMO MEJORAR LOS PROCESOS DE COMUNICACIN --------------------------------------------------- 51
COTROL ---------------------------------------------------------------------------------------------------------- 53
12.1
12.2
12.3
13
INTRODUCCIN ---------------------------------------------------------------------------------------------------- 46
DEFINICIN DE LIDERAZGO ------------------------------------------------------------------------------------- 46
TENDENCIAS DEL LIDERAZGO ---------------------------------------------------------------------------------- 47
COMUICACI ------------------------------------------------------------------------------------------------ 49
11.1
11.2
11.3
11.4
11.5
11.6
11.7
12
Manual Terico
INTRODUCCIN A LA PROTECCIN DE LOS DATOS ----------------------------------------------------------- 60

POLTICAS Y PROCEDIMIENTOS --------------------------------------------------------------------------------- 60
PROTECCIN DE LOS DATOS: POLTICAS DE RESPALDOS --------------------------------------------------- 60
PROTECCIN DE LOS DATOS: POLTICA DE REVISIN DE BITCORA -------------------------------------- 62
PROTECCIN DEL SOFTWARE: POLTICAS EN LA ADQUISICIN DE LICENCIAS DE SOFTWARE --------- 62
PROTECCIN DEL HARDWARE: POLTICAS DE SEGURIDAD FSICA DEL CENTRO ----------------------- 63
ADMIISTRACI DE PROYECTOS IFORMTICOS --------------------------------------------- 65

14.1
14.2
14.3
14.4
14.5
14.6
14.7
INTRODUCCIN ---------------------------------------------------------------------------------------------------- 65
ESTRATEGIA BSICA PARA EL DESARROLLO DE PROYECTOS INFORMTICOS --------------------------- 65
LAS CUATRO DIMENSIONES DE UN PROYECTO INFORMTICO --------------------------------------------- 66
BUSCANDO UN DESARROLLO EFICIENTE DE PROYECTOS INFORMTICOS -------------------------------- 68
ERRORES CLSICOS EN LA ADMINISTRACIN DE PROYECTOS INFORMTICOS --------------------------- 68
BASES DEL DESARROLLO DE PROYECTOS INFORMTICOS ------------------------------------------------- 74
GESTIN DE RIESGOS --------------------------------------------------------------------------------------------- 81
3/86
Manual Terico
1 CONCEPTOS BSICOS DE ADMINISTRACIN

1.1 DEFINICIN
Esta es una de las definiciones ms sencillas de administracin: Administracin es
lograr que las cosas se hagan mediante otras personas . Estas es una definicin
muy acertada an y cuando cause la impresin entre los legos en administracin
de que los administradores no hacen nada, por aquello de que el administrador
no est fsicamente trabajando, olvidando que lo que un administrador hace es
llevar a la prctica las funciones bsicas de la administracin que son:
Planeacin, Organizacin, Direccin y Control. A esas funciones se les conoce
como proceso administrativo.
E.F.L. Brech dice que: Administracin es el proceso social que lleva consigo la
responsabilidad de planear y regular de forma eficiente las operaciones de una
empresa para lograr un propsito dado.
Koontz y ODonnell dan la siguiente definicin: Administracin es la direccin de
un organismo social y su efectividad en alcanzar objetivos, fundada en la
habilidad de conducir a sus integrantes. Puede deducirse, de esta y la anterior
definicin, que hay dos elementos son los cuales es imposible hablar de
administracin: personas y objetivos. As que es imposible encontrar una
administracin sin objetivos definidos, aunque es frecuente encontrar empresas sin
objetivos.
Una descripcin ms detallada del proceso administrativo se logra definiendo
cada una de las funciones como una respuesta a las siguientes preguntas:
PREVISIN: Qu puede hacerse?
PLANEACIN: Qu se va a hacer?
ORGANIZACIN: Cmo se va a hacer?
INTEGRACIN: Con qu se va a hacer?
DIRECCIN: Ver que se haga
CONTROL: Cmo se est realizando?
1.2 LA ADMINISTRACIN UNA CIENCIA O UNA TCNICA?

Dentro de los diferentes conceptos de administracin existe una vieja controversia
en cuanto a considerar la administracin como una ciencia o como una tcnica.
Una definicin de las mismas nos puede ayudar a formar nuestro propio
concepto.
La ciencia...
La tcnica...
Nos ensea a conocer
Nos ensea a hacer
Busca la verdad
Busca la eficiencia
Descubre
Crea
Descubre principios
Establece reglas
4/86
Manual Terico
En cada una de esas definiciones encontramos elementos que se aplican a la

administracin, ya que esta rene conocimiento, tiene principios subyacentes y
busca la verdad mediante el mtodo cientfico, pero a la vez busca la eficiencia,
crea y establece reglas. De hecho, la administracin no solo rene conocimiento,
sino que tambin lo aplica. Por tanto puede concluirse que la administracin es
una ciencia y una tcnica.
1.3 RELACIN DE LA ADMINISTRACIN CON OTRAS CIENCIAS

La administracin se relaciona con otras ciencias en diversos aspectos:
Aspecto sociolgico: Ya que de la sociologa toma los siguientes principios:
divisin del trabajo, unidad de fin, unidad de mando, coordinacin de
actividades y medios de accin.
Aspecto econmico: La economa ensea a la administracin la mejor manera
de aprovechar los recursos de que dispone y al organismo productivo le permite
conocer las tendencias estadsticas, las fuentes de abastecimiento, los medios de
comunicacin, los mercados locales e internacionales y los medios de
distribucin.
Aspecto legal: El derecho proporciona a la administracin la estructura jurdica de
los organismos sociales.
Aspecto psicolgico: La sociologa proporciona a la administracin los medios de
motivar la conducta de los miembros componentes del grupo, de manera tal
que, en el aspecto interno se logre la adecuada comunidad de ideas y
coordinacin de actividades. En el aspecto interno se usa la sicologa para el
trato con los clientes, la promocin de ventas, publicidad, etc. En el aspecto
moral se dan reglas para guiar la conducta de las personas, recurdese que la
administracin es una actividad, su prctica se llama administrar y quien la realiza
es el administrador; sin embargo, la tarea de administrar consiste esencialmente
en utilizar con eficiencia los esfuerzos del grupo, y el hecho de que la
administracin sea una actividad de grupo y no individual resalta la importancia
de este aspecto.
1.4 CARACTERSTICAS DE LA ADMINISTRACIN

Entre las caractersticas de la administracin deben sealarse las siguientes:
1. Universalidad: Porque se da dondequiera que haya un grupo social con
fines comunes.
2. Unidad: Porque si bien es cierto que el proceso administrativo consta de
varios elementos, constituye un fenmeno que es nico y se da en todo
momento.
3. Es trascendental: En una empresa se desarrollan diversas funciones tales
como: produccin, ventas, finanzas, etc. Y cada una de ellas requiere de
especialistas en la materia; pero si cada uno de ellos se coloca frente a un
grupo de personas para planear, organizar, dirigir o controlar esas
funciones, en ese preciso momento se convierte un administrador. En
consecuencia, el fenmeno administrativo es trascendental ya que
acompaa a otras funciones o ir acompaado de ellas, pero ser
especfico y distinto de los dems.
5/86
Manual Terico
1.5 OBJETIVOS DE LA ADMINISTRACIN

Para que exista un sentido de satisfaccin debe existir un objetivo, lo que da un
propsito al esfuerzo; adems el objetivo debe tener un significado y un valor; as
que la definicin de un objetivo es: Objetivo Administrativo es una meta que se
fija, que requiere un campo de accin definido y que sugiere la orientacin para
los esfuerzos de un dirigente. Hay cuatro elementos en esta definicin:
1. Meta
2. Campo de accin
3. Definicin de la accin
4. Orientacin.
La falta de objetivos hace que la administracin sea innecesariamente difcil, si es
que se puede hablar en rigor de administracin, as que los objetivos bsicos son
un prerrequisito para determinar cualquier curso de accin y deben ser definidos
con claridad para que los comprendan todos los miembros de la empresa.
1.6 PROBLEMAS ESPECFICOS DE LOS ADMINISTRADORES

Las reas de problemas que enfrentan los gerentes son las siguientes:
a. Desarrollo y mejoramiento de los objetivos
b. Mejoramiento de los recursos, principalmente los humanos
c. Finanzas
d. tica administrativa
e. Efectividad de los medios de comunicacin.
Especficamente los problemas que enfrentan los gerentes estn particularmente
relacionados con:
a. Dificultad para obtener informacin contable y financiera
b. Costos, utilizacin de planes de costos estandarizados
c. Toma de decisiones, uso de la investigacin de operaciones
d. Capacitacin y desarrollo de empleados.
e. Obtencin de financiamiento
f. Actitud en el trabajo, determinar lo que los empleados piensan de la
empresa
g. Diseo de productos y servicios que llenen los requisitos del mercado y de
la empresa
h. Planeacin de la produccin, lotes econmicos, inventarios adecuados y
utilizacin ptima de maquinaria y equipo.
i. Control de calidad
j. Reclutamiento y seleccin de personal
k. Administracin de sueldos y salarios
6/86
Manual Terico
2 SISTEMA DE EMPRESA Y SISTEMA DE ADMINISTRACIN

2.1 SISTEMAS
DE EMPRESA
El estudio de las empresas y la administracin puede afrontarse desde un punto

de vista de sistemas.
El sistema de empresa, a su vez, puede abordarse desde dos ngulos: el esttico y
el dinmico.
El enfoque esttico es el estudio de los componentes del sistema de empresa y su
interdependencia. Por otra parte, el anlisis de la administracin y del
funcionamiento de la empresa representa el enfoque dinmico. Los dos enfoques
con complementarios y permiten un mejor conocimiento de la empresa.
Los sistemas de empresa pueden agruparse en tres categoras bsicas:
a. Sistemas de empresa industrial
b. Sistemas de empresa comercial
c. Sistemas de empresa de servicios
En nuestro caso particular nos interesa estudiar un centro de informtica, el cual
corresponde con los sistemas de empresa de servicios.
Estudiaremos ahora el centro de informtica utilizando los dos enfoques.
2.1.1 ENFOQUE ESTTICO

Un centro de informtica es una pequea empresa de servicios dentro de la
empresa madre y como tal tiene una serie de componentes que se
interrelacionan para darle un funcionamiento sistemtico. Estos componentes
suelen ser: servicios de fabricacin, de aprovisionamiento, mercadotecnia (si!
Informtica debe vender sus productos), finanzas y personal; adems el sistema
centro de informtica se compone de: la estructura organizacional, los
administradores y los empleados.
Un centro de informtica, visto desde un enfoque esttico puede representarse
grficamente de la siguiente manera:
7/86
Manual Terico
Componentes del Sistema de

un Centro de Informtica
Recursos
Financieros
Recursos
Humanos
PRODUCCIN
estudio de
necesidades
concepcin del
servicio
desarrollo e
implantacin
concepcin del
procedimiento
Recursos
Materiales
Mercadotecnia
Consumidores
El funcionamiento de este sistema puede resumirse en el ciclo principal, el cual

constituye el corazn del mismo.
A partir del estudio de necesidades el centro de informtica se forma una idea
del servicio solicitado y es capaz de planificar la manera en que ese servicio ser
producido. Seguidamente disea el servicio, lo desarrolla y lo pone a disposicin
del cliente o consumidor, mejor conocido en este caso como usuario.
El sistema de produccin de servicios informticos se alimenta de recursos
financieros, humanos y materiales que le son provistos por la empresa para su
funcionamiento.
2.1.2 ENFOQUE DINMICO

El enfoque dinmico se concentra ms en el flujo de la produccin del servicio
que en los componentes que componen el sistema de empresa. El flujo de la
produccin es un ciclo operacional que la empresa, o , en nuestro caso, el centro
de informtica, cumple para lograr la produccin de servicios solicitados por las
diferentes reas de la empresa.
Los centros de informtica realizan un mnimo tareas rutinarias, sus principales
acciones pueden calificarse de pequeos proyectos de produccin de servicios,
que siguen un ciclo operacional que tiene principio y final y que es reactivado en
la medida en que se van recibiendo nuevos requerimientos.
El ciclo operacional de un centro de informtica puede representarse
grficamente as:
8/86
Previsiones
Concepcin de
productos y
procedimientos
Manual Terico
Planificacin de
la produccin
Reclutamiento y
ajuste del
personal
Puesta en
marcha
Aprovisionamiento
Fabricacin
Ciclo Operacional del sistema de centro de

informtica
Obviamente, el ciclo operacional se inicia con la concepcin del los productos a
producir (servicios informticos) y con la definicin de los procedimientos a seguir
para producirlos. Seguidamente habr que estimar cuales y cuantos sern los
insumos que se utilizarn productos que se van a producir, para proceder al
aprovisionamiento de los mismos. Una vez que se cuente con todos los recursos
necesarios se procede a la fabricacin (desarrollo) y finalmente a la entrega y
puesta en marcha del servicio producido.
La llegada de nuevos requerimientos hace que retornemos al principio del ciclo.
2.2 SISTEMAS DE ADMINISTRACIN

Los sistemas de administracin son 100% dinmicos. Se refieren a procesos y no a
estructuras. Ms que estar formados por componentes, estn formados por
subsistema, que se interrelacionan entre s para ejecutar las funciones del proceso
administrativo. El sistema de administracin puede representarse as:
SISTEMA DE CONTROL
SUBSISTEMA DE ORGANIZACION
ADMINISTRATIVA
SISTEMA ORGANIZACIONAL
SUBSISTEMA DE INFORMACIN
Informaciones
Operacionales
Informaciones
de Control
SISTEMA OPERACIONAL
Sistema de Administracin
9/86
Manual Terico
El sistema operacional es la base del sistema administrativo, de all provienen las

informaciones operacionales y de control que retroalimentan a la empresa y dan
una idea sobre el rendimiento. Adems, lo ms importante, all es donde se
producen los servicios.
2.2.1 SISTEMA DE CONTROL

Los sistemas de administracin se componen de subsistemas que se encargan de
ejecutar las funciones bsicas del proceso administrativo.
Todos ellos requieren de un agentes humanos y materiales para ejecutar su
funcin y tienen un procedimiento para cumplir su objetivo.
El primero de ellos es el sistema de control que est compuesto por los siguientes
elementos:
2.2.1.1.1.1.1 Agente
Humano
Administrador
Director
Director Adjunto
Responsable
Agente Fsico

Equipo
Sistemas
Otros
Funcin: Administrar eficaz y racionalmente los recursos

Procedimiento:
Insumos
(Datos)
Identificacin de
Variables
Determinacin de un
valor para cada
variable
Eleccin de una
solucin
Medicin de
resultados
Evaluacin de las
variaciones
Producto
(Plan Estratgico,
Polticas y reglas,
Decisiones,
Informacin)
Sistema de Control
La funcin del sistema de control es administrar eficazmente los recursos,
materiales, humanos y financieros de una unidad productiva. Esto significa aplicar
el proceso administrativo. Se trata aqu de definir los objetivos, establecer los
10/86
Manual Terico
medios para alcanzarlos, medir los resultados, evaluar las variaciones y tomar las
decisiones correctivas que sean necesarias.
Los agentes humanos que intervienen en el sistema de control son los
administradores de todos los niveles jerrquicos.
2.2.2 SISTEMA OPERACIONAL

Su misin es ejecutar los trabajos que le confa el sistema de control. Estos trabajos
tienen como finalidad realizar un producto determinado. En el caso de un centro
de informtica, se busca obtener un servicio informtico.
El sistema operacional est compuesto por los siguientes elementos:
2.2.2.1.1.1.1 Agente
Humano
Obreros
Tcnicos
Analistas
Agente Fsico

Equipo
Sistemas
Herramientas
Otros
Funcin: Realizar un producto terminado

Procedimiento:
Insumos
(Datos,
Materiales,
Productos semiterminados
Energa,
etc.)
Procedimiento de
Produccin
Producto o servicio terminado

(Sistemas de informacin,
Redes construidas,
Equipo reparado,
etc.)
Sistema Operacional
El procedimiento de produccin vara de acuerdo a las caractersticas tcnicas
del servicio a producir. La caracterstica fundamental de ese procedimiento es
que debe permitir la produccin del servicio de manera eficiente, con la calidad
requerida a un costo mnimo.
2.2.3 SISTEMA ORGANIZACIONAL

Su misin es implantar las estructuras administrativas y operacionales necesarias
para el buen funcionamiento del sistema de empresa. Su producto tiene dos
aspectos: la organizacin social y la informacin.
a. El subsistema de organizacin social: Comprende el conjunto de
estructuras jerrquicas de la empresa que definen las relaciones entre los
miembros del personal. Estas relaciones se representan mediante un
diagrama llamado organigrama administrativo, el cual permite visualizar las
lneas de autoridad y de comunicacin en el seno de la empresa. Este
organigrama suele acompaarse de un manual que describe las polticas,
reglas y funciones de cada dependencia y puesto dentro de las unidades
de la estructura.
11/86
Manual Terico
b. El subsistema de informacin: Este es el conjunto de informes relativos a las

actividades del sistema operacional y los informes de control, y permite al
sistema de control evaluar las operaciones. El subsistema de informacin
constituye un puente entre el sistema de control y el sistema operativo.
El sistema organizacional est compuesto de los siguientes elementos:
2.2.3.1.1.1.1 Agente
Humano
Directores
Asesores
Analistas
Agente Fsico

Equipo
Sistemas
Otros
Funcin: Implantar estructuras organizacionales y operacionales

Procedimiento:
Insumos
(Datos concernientes a los
objetivos y los recursos)
Proceso de anlisis y
resolucin de
problemas
Proceso de concepcin
de sistemas
Producto
(Organigrama administrativo,
Manual de organizacin,
Sistemas de informacin
internos)
Sistema Organizacional
2.3 ELEMENTOS PARA LA CONSTRUCCIN DE SERVICIOS INFORMTICOS

En esencia, para la creacin de servicios informticos en necesario tener en
cuenta que los siguientes elementos deben ser orquestados (sin excepcin) para
construir servicios slidos y tiles:
ESTRUCTURA
GEREENTE/PRESI DENTE, SUBGERENTES, GERENTES FUNCION ALES
OBJETIVOS
ELEMENTOS
GENER AR PRODUCTOS DE UTILIDAD Y SATISFACCIN DEL USU ARI O

PERSON AS, I NSTAL ACI ONES, EQUIPO, DINERO, MATERI ALES
ENTRADAS
PROCESO REALIZADO
MATERI ALES, I NFORM ACI N, ENERG A
CONVERTI R PARTES Y M ATERI AS PRIMAS EN BIENES TERMINADOS,

PREST AR SERVI CIOS Y SUMINI STRAR I NFORM ACI N
SALIDAS
PRODUCTOS, I NFORM ACI N, SERVICIOS
12/86
Manual Terico
3 EL GERENTE DE INFORMTICA
El puesto de gerente de informtica es de mucha responsabilidad.
La mejor preparacin que puede tener una persona para este puesto se basa en
tres clases de experiencia:
Una formacin universitaria en materia informtica
Experiencia en el rea informtica (desarrollo y administracin de sistemas
de informacin particularmente), y
Experiencia en la gerencia de lnea de nivel medio.
No basta la educacin, ni la experiencia tcnica para ser un buen gerente.
Tienen importancia extrema las habilidades de trato con la gente.
El siguiente cuadro muestra una clasificacin de la importancia que tiene cada
una de las cualidades (o habilidades) que debe reunir un gerente de informtica,
comparando con la importancia que cada una tiene en un gerente de un rea
meramente administrativa.
HABILIDAD
CLASIFICADA POR
EJECUTIVOS EN INFORMTICA
CONOCIMIENTO TOTAL DE LA COMPA A Y SUS
CLASIFICADA POR
EJECUTIVOS GENERALES
CAPACIDAD DE DIRIGIR PROYECTOS
RELACIONES CON LA ALTA GERENCIA
RELACIONES CON LOS SUBORDINADOS
DE
CAPACIDAD DE DISEAR SERVICIOS Y ANALIZAR Y
OBJETIVOS
CAPACIDAD DE COMUNICARSE CON EFICACIA, EN

FORMA ORAL Y POR ESCRITO
RELACIONES CON LOS OTROS DEPARTAMENTOS

QUE UTILIZAN LOS SERVICIOS QUE OFRECE LA
UNIDAD DE INFORMTICA
CONOCIMIENTO
DE LAS
INFORMACIN UTILIZADAS
TECNOLOGAS
JUZG AR DISEOS
Esta clasificacin, que est basada en entrevistas con gerentes de informtica en

todo Estados Unidos, revela que la jornada del gerente de informtica es a las de
ejecutivos de otras reas en el sentido de que realizan muchas actividades
diferentes y sobre todo porque (aunque parezca sorprendente) durante la
jornada no tienen contacto con la parte medular de sus actividades: la
computadora.
En cambio, pasan das hablando con los usuarios de los servicios a crear y ofrecer,
y planeando como mejorarlos.
Estas dos actividades primarias se combinan con varias otras, entre ellas: asuntos
legales, administracin de personal del departamento y una avalancha de
material de lectura.
Esta situacin se presenta, obviamente, dependiendo de la etapa de crecimiento
en la que est cada empresa.
13/86
Manual Terico
4 PLANEACIN ESTRATGICA Y OPERATIVA

4.1 CONCEPTO DE PLANEACIN
Cada erudito en administracin tiene su propio concepto de lo que es la
planeacin. Examinar varios de ellos puede llevarnos a formar nuestro propio
concepto:
Planeacin es el diseo de un futuro deseado y de formas efectivas de
convertirlo en realidad.
4.1.1.1.1.1.1.1 Russell Ackoff
Planeacin es un proceso que empieza con objetivos, define estrategias,
polticas y planes detallados para lograrlos, que establece la organizacin para
implementar decisiones, e incluye una revisin de actuacin y retroalimentacin
para iniciar un nuevo ciclo de planeacin.
4.1.1.1.1.1.1.2 George Steiner
Planeacin es el proceso continuo de tomar decisiones empresariales presentes
en forma sistemtica y con el mejor crecimiento posible de su futuridad,
organizando sistemticamente los esfuerzos necesarios para llevar a cabo estas
decisiones contra las expectativas mediante retroalimentacin organizada y
sistemtica.
4.1.1.1.1.1.1.3 Peter Drucker
La planeacin llena el vaco entre donde estamos y donde queremos ir y su
tarea es exactamente minimizar los riesgos a la vez que se obtienen ventajas de
las oportunidades.
4.1.1.1.1.1.1.4 Annimo
La combinacin de estos elementos nos llevan a determinar el contenido de la
planeacin, es decir, todo lo que tiene que estar claro para que la empresa
pueda echar a andar un plan que le lleva hacia donde quiere llegar:
Contenido de la Planeacin
Dnde estamos?
Anlisis de Fortalezas y Debilidades
a dnde queremos ir?
Objetivos/Metas
a dnde podemos llegar?
Visin de la organizacin
a dnde debemos llegar?
Misin de la organizacin
Cmo podemos llegar?
Polticas/Estrategias
Cundo queremos llegar?
Programacin de Actividades
Quin es el responsable?
Planeacin
organizacin
Cunto costar?
Recursos Humanos y financieros?
operativa
de
la
14/86
Manual Terico
4.2 OBJETIVOS DE LA PLANEACIN

Los objetivos de la planeacin son:
a. Proporcionar una imagen clara de lo que la empresa desea.
b. Traducir la visin de la empresa en planes, metas y objetivos, los cuales
adems debern ser fieles a la misin de la misma.
c. Aumentar la responsabilidad y el compromiso total de la empresa a
travs de la definicin exacta de lo que se va a hacer.
d. Establecer una base sobre la cual pueda evaluarse el desempeo de la
organizacin en general y del personal en particular, en todos los
niveles (directivo, administrativo y operativo).
4.3 DEFINICIONES DE LOS COMPONENTES DE LA PLANEACIN

Los conceptos anteriores ameritan la aclaracin de algunas definiciones:
Anlisis FODA: Las siglas FODA significan Fortalezas, Oportunidades,
Debilidades y Amenazas,. Este anlisis se hace antes de cualquier proceso de
planeacin para determinar:
e. Fortalezas: son los puntos fuertes al interior de la organizacin, sus
ventajas competitivas. Podran ser, por ejemplo: La excelente formacin
acadmica de sus empleados, la tecnologa que se posee, etc.
f. Oportunidades: son las situaciones que se dan al exterior de la
organizacin y que pueden redundar en beneficios o posiciones
favorables para la misma. Por ejemplo: La aprobacin de un proyecto
de cooperacin tcnica para la organizacin, la aprobacin de
intercambios
de
tecnologa
con
otras
instituciones,
el
perfeccionamiento de la tecnologa de internet y el surgimiento de ebusiness, etc.
g. Debilidades: son los puntos dbiles que se tienen en el interior de la
organizacin y que limitan la posibilidad de fijarse altas expectativas en
una planificacin. Estas pueden ser: Limitaciones logsticas para el
desarrollo de las actividades, escasez de recursos financieros, base
tecnolgica deficiente, etc.
h. Amenazas: son las situaciones que se dan al exterior de la organizacin
y que pueden afectar negativamente a la misma. Podran ser, por
ejemplo: Cancelacin de ayuda internacional para proyectos
relacionados con tecnologa, aparicin de tecnologas que permitan la
violacin de la seguridad de los sistemas, etc.
Obviamente, un plan estratgico, y su consecuente plan operativo, debe
orientarse a explotar las fortalezas, aprovechar las oportunidades, eliminar las
debilidades y anular las amenazas.
Visin: Es la expresin de lo que la organizacin aspira a ser al cabo de un
plazo determinado. Es imaginar y construir una idea del futuro deseado. Es la
inspiracin que seala el camino a seguir en la planeacin. La visin de un
centro de informtica podra ser:
15/86
Manual Terico
El centro de informtica ser en el plazo de cinco aos la fuente nica,

segura y confiable de informacin para toda la organizacin, la cual
estar completamente automatizada y comunicada de forma
electrnica a nivel nacional.
Misin: Es la razn de ser de la organizacin, en base a lo que se espera de

ella. La misin proporciona las pautas para el diseo de un plan estratgico.
Ejemplo de misin1:
Proveer a la Direccin Ejecutiva de Ingresos los servicios informticos
integrales que incluyen el desarrollo e implantacin de sistemas de
informacin, construccin de infraestructura de comunicaciones y
soporte tcnico a los usuarios de equipo y programas informticos .
Objetivos: Son los fines que se pretenden alcanzar en un futuro
determinado para la accin y el xito deseado. Puede ser en forma total de la
empresa o en alguna de sus reas o secciones. Los objetivos se definen en dos
niveles: generales y especficos. Ejemplos de objetivo general:
Contar con sistemas de informacin eficientes que provean
informacin oportuna y confiable a todos los niveles en la DEI.
Ejemplo de objetivos especficos:
Establecer en la Divisin de Informtica una estructura eficiente y
ajustada a los grandes objetivos de la institucin.
Institucionalizar un sistema de informacin tributaria automatizado que
haga ms eficientes las actividades en las reas de Recaudacin,
Fiscalizacin, Cuenta Corriente, Reclamos, Cobranzas, Estadsticas.
Integrar de manera automatizada la informacin tributaria y aduanera
a nivel nacional
Metas: Representan la cuantificacin de los objetivos. Son los resultados
deseados (expresados cuantitativamente en forma precisa) necesarios para
cumplir el objetivo de cada programa. Son medibles y limitadas en tiempo, es
decir que se ajustan a un calendario de trabajo. Ejemplo de metas:
A septiembre del 2000 estar completo el proceso de reestructuracin
de la Divisin de Informtica
A septiembre del 2001 tener implantado y operando el SIT en las reas
de : Recaudacin, Fiscalizacin, Cuenta Corriente, Reclamos,
Cobranzas, Estadsticas, con informacin base depurada en un 100%
A diciembre del 2002 tener completamente integrado los sistemas SIT y
SIDUNEA con una cobertura a nivel nacional de un 100%.
La mayora de los ejemplos que aqu se mencionan han sido tomados del Plan
Estratgico y Operativo de la Direccin Ejecutiva de Ingresos, formulado en mayo del
2000.
16/86
Manual Terico
Polticas: Son las normas generales que sirven de gua al pensamiento y la

accin. Las polticas se apoyan en los objetivos y comprometen a la direccin
a seguir un curso de accin determinado para alcanzar objetivos especficos y
tienen que establecerse tomando en cuenta la eficiencia de la empresa.
Ejemplos de polticas:
Toda inversin en hardware y software que exceda el valor de
Lps.100,000 deber ser sometida al Procedimiento de Compras del
Estado.
Todo el personal que se contrate para el proyecto de desarrollo e
implantacin del SIT deber tener un ttulo de educacin superior en el
rea de informtica.
El personal contratado por organismos internacionales que labore
dentro de la institucin se regir bajo las normas laborales establecidas
para el resto de los empleados de la institucin
Estrategias: Es el arte de emplear las destrezas y recursos de una empresa
para lograr sus objetivos bsicos en las condiciones ms ventajosas. Las
estrategias muestran la direccin y empleo general de recursos y esfuerzos.
Ejemplos de estrategias:
La Direccin Ejecutiva de Ingresos desarrollar e implementar,
sistemas de informacin integrados, modernos, eficientes, confiables y
que gocen de aceptacin y credibilidad con la participacin de los
usuarios, facilitadores y consultores internacionales.
La institucin contratar de manera permanente recursos humanos
con formacin slida en informtica y de acuerdo a perfiles
previamente definidos para facilitar la implantacin de sistemas con el
fin de dar un mejor servicio a las distintas dependencias.
La institucin financiar sus proyectos informticos a travs de
prstamos y donaciones de organismos internacionales.
Programas: Son esquemas en donde se establece, la secuencia de
actividades que habrn de realizarse para lograr objetivos y el tiempo
requerido para efectuar cada una de sus partes y todos aquellos eventos
involucrados en su consecucin2.
Presupuestos: Son los planes de todas o algunas de las fases de actividad
del grupo social expresado en trminos econmicos, junto con la
comprobacin de la realizacin de dicho plan.
Actividades: Son acciones concretas diseadas para lograr las metas.
Ejemplos de actividades:
Revisar y actualizar el estudio tcnico mediante el cual se propone la
reestructuracin de la Divisin de Informtica
La herramienta ms utilizada para la representacin de un programa es el cronograma,

el cual hace un mayor nfasis en el tiempo en que las actividades van a realizarse.
2
17/86
Manual Terico
Proceder con la reestructuracin de la Divisin de Informtica

ejecutando las actividades incluidas en el estudio tcnico que se refiere
al proceso de reubicacin del personal, reasignacin de funciones y
contratacin de nuevo personal
Integrar los equipos o comisiones de trabajo cuya responsabilidad
principal ser realizar un diagnstico completo sobre la situacin real
actual de las reas de: Recaudacin, Fiscalizacin, Cta. Cte., Reclamos,
Cobranzas, Estadsticas
Realizar un estudio para determinar la mejor forma de lograr la
integracin de los sistemas SIT y SIDUNEA
18/86
Manual Terico
4.4 ESTRUCTURA DE UN PLAN ESTRATGICO

Un plan estratgico puede estructurase de la siguiente manera:
4.4.1.1.1.1.1.1.1
PLAN ESTRATGICO
<Empresa YYY>
<Mes inicio> del <Ao inicio> a <Mes final> del <Ao Final>
VISIN
<...>
MISIN
<...>
OBJETIVO GENERAL
<...>
ESTRATEGIAS
1. ...
4. ...
2. ...
5. ...
3. ...
6. ...
OBJETIVOS
ESPECIFICOS
METAS
ACTIVIDADES
ESTRATGICAS
1. ...
1. ...
1. ...
2. ...
2. ...
2 . ...
3 . ...
3 . ...
3 . ...
19/86
Manual Terico
4.5 ESTRUCTURA DE UN PLAN OPERATIVO
4.5.1.1.1.1.1.1.1
PLAN OPERATIVO ANUAL

<Empresa YYY>
<Mes inicio> del <Ao inicio> a <Mes inicio> del <Ao final>
Perodo
Descripcin de la Actividad Desde
Cronograma (May - Abr)
Recursos Requeridos
Humanos
Hasta M J J A S O N D E F M A Responsable
Actividad 1
02/05/00 08/05/00
Funcionario X Soporte
Actividad 2
09/05/00 15/05/00
Funcionario Z
Actividad 3
16/06/00 31/12/01
Actividad 4
16/06/00 31/12/00
Materiales Financieros
Equipo
de100,000
Administrativ cmputo
o
IDEM
Soporte
Equipo
de180,000
Administrativ cmputo
o
IDEM
Funcionario Y Consultor
20/86
IDEM
IDEM
Materiales y200,000
equipo de
oficina
Observaciones
Manual Terico
21/86
Manual Terico
5 PLANEACIN EN UN CENTRO DE INFORMTICA

5.1 INTRODUCCIN
La mayora de las personas relacionadas con sistemas de informacin, inclusive los
gerentes de informtica no controlan su propia planificacin. Las planificaciones
se transmiten como los 10 Mandamientos, desde arriba, ya sea esto la gerencia
general, el gerente financiero, el de marketing, etc.
Lo ms grave es que estos jefes, por considerar nicamente sus fines sin conocer
las limitaciones que puedan sufrirse suelen plantear planificaciones imposibles. Y
estas planificaciones son el mayor problema del rea de informtica.
Otro problema que se afronta es que, al no estar el centro de informtica
familiarizado con la actividad de planeacin, se suele incurrir en significativas
prdidas de tiempo en actividades perjudiciales e improductivas, produciendo
retrasos difciles de justificar ante los que exigen resultados al rea de informtica.
5.2 COMO MANEJAR LAS PLANIFICACIONES IMPOSIBLES

La mayora de las actividades del centro de informtica se desarrollan bajo un
concepto de proyecto, y generalmente el rea que solicita el proyecto desea
que el mismo se desarrolle lo ms pronto posible .
Casi siempre, la demanda del desarrollo rpido de una tarea en informtica llega
procedente de los usuarios o clientes o desde los altos cargos. Todos ellos son
clientes del centro de informtica y pueden aplicar una enorme presin para
hacer que un proyecto informtico se desarrolle ms rpido, pero en ocasiones lo
que necesitan realmente es un menor costo o un menor riesgo. Simplemente no
saben como pedir las cosas o no saben que esas cosas no estn ligadas con la
velocidad mxima de desarrollo.
Antes de orientar el proyecto hacia una planificacin ms corta, en vez de
orientarlo hacia el menor costo o la mejor funcionalidad, hay que descubrir que
es lo que realmente se necesita. Hay varias apariencias de desarrollo rpido que
parecen clamar por la mxima velocidad de desarrollo, pero lo que realmente
pide es otra cosa, como ser:
i. Evitar retrasos: Lo que el cliente desea realmente es asegurarse de que
el proyecto terminar ajustndose a los plazos y presupuestos previsto.
La solucin no est en correr, sino en aplicar una mejor gestin de
riesgos, hacer una estimacin realista de los tiempos y recursos a utilizar
y mantener un permanente control sobre las actividades.
j. Predecibilidad: En muchos casos los clientes desean coordinar la parte
de desarrollo de software de un proyecto con previsiones de beneficios,
marketing, planificacin del personal y, quizs, otros proyectos de
software. Aunque pueden pedir mxima velocidad al centro de
informtica lo que realmente estn demandando es una predecibilidad
suficientemente buena para poder coordinar los esfuerzos
relacionados. En este caso, en lugar de sacrificar la planeacin y forzar
el desarrollo del proyecto, se debe centrar esfuerzos en lograr un
23/86
Manual Terico
desarrollo eficiente y hacer hincapi en los mtodos que reduzcan los

riesgos, para no incurrir en retrasos.
k. Menor Coste: No es raro que los clientes quieran minimizar el costo del
proyecto informtico. En estos casos hablarn de terminar pronto el
proyecto, pero, en realidad, harn nfasis en su preocupacin por el
presupuesto y no en la planificacin. Aunque resulte lgico suponer que
la planificacin corta del proyecto es tambin la ms barata, los
mtodos que minimizan el costo y la planificacin son diferentes.
Alargar un poco la planificacin por encima de la inicial y disminuir el
tamao del equipo puede reducir el costo total de un proyecto.
l. Fecha fija de prdida de valor: Hay ocasiones en que el beneficio a
obtener del desarrollo de un proyecto informtico desciende
paulatinamente a lo largo del tiempo, y en ocasiones desciende
precipitadamente pasado un cierto tiempo. Pinsese por ejemplo en
una compaa de ventas de servicio de telefona satelital queriendo
implantar su sistema automatizado de ventas y servicio al cliente antes
que lo haga la competencia y que esta acapare los clientes
importantes. Si existe un punto en el que el valor o beneficio de un
proyecto desciende precipitadamente , parece lgico decir:
Necesitamos toda la velocidad posible de desarrollo para estar
seguros de que entregaremos el producto antes de ese punto. Sin
embargo, la necesidad de acelerar el desarrollo depende realmente
del tiempo que se tenga para realizar el proyecto, y del tiempo
necesario para desarrollarlo eficientemente. Si se puede completar el
proyecto antes de la fecha de perdida de valor, utilizando mtodos
eficientes, en lugar de mtodos acelerados, hay que hacerlo,
centrndose en la reduccin de riesgos y no en la velocidad de
desarrollo. Esto ofrece una mayor posibilidad de terminar el proyecto a
tiempo.
m. Deseo de horas extras gratuitas: No es muy frecuente, pero en algunas
ocasiones el inters del cliente o directivo por acelerar un proyecto
informtico enmascara el deseo de obtener una ganancia econmica
en forma de tiempo extra gratuito del personal de informtica. Esta
circunstancia es fcil de distinguir, ya que el cliente insistir en la
importancia de la planeacin y, simultneamente, se negar a ofrecer
el soporte necesario para mejorar la velocidad de desarrollo por
cualquier otro medio que no sean las horas extras sin remunerar. El
cliente no insistir en tener ms personal, mejorar las herramientas de
hardware y software u otros tipos de soporte. En verdadero caso de
necesidad de reducir el tiempo del proyecto el cliente estar dispuesto
a considerar cualquier medio para reducir la planificacin.
La solucin para manejar, o mejor dicho evitar, las planificaciones imposibles,
consiste en lograr el perfecto equilibrio de tres factores: la planificacin, el costo y
el producto.
Un tringulo de equilibrio entre planificacin, costo y producto es algo bsico
para la gestin de proyectos en el centro de informtica. En el extremo del
producto se incluyen la calidad y todos los atributos relacionados con el
24/86
Manual Terico
producto, incluyendo prestaciones, complejidad, usabilidad, facilidad de

modificacin, mantenimiento, tasa de errores y dems.
Lograr ese equilibrio es una tarea difcil ya que, como acertadamente lo dice
Watts Humphrey Con raras excepciones, la estimacin de recursos y la
planificacin iniciales son inaceptables. Esto no se debe a que el personal de
informtica sea irresponsable, sino a que, generalmente, los usuarios desean ms
de lo que pueden abarcar. Si el trabajo no entra en la planificacin y recursos
disponibles, tiene que reducirse, o bien tienen que incrementarse el tiempo y los
recursos.
Costo
Producto
Es apropiado representar grficamente este tringulo para demostrar la

importancia de lograr el equilibrio:
Planificacin
Para mantener equilibrado el tringulo hay que calibrar la planificacin el costo y

el producto. Si se desea incidir en la esquina del producto, tendr que
incrementarse el costo, la planificacin o ambos. Con las dems combinaciones
pasa lo mismo. Si se desea modificar uno de los vrtices del tringulo, se tendr
que modificar al menos uno de los otros para mantenerlo equilibrado.
Una tcnica para equilibrar el tringulo mediante concenso entre informtica y el
cliente es dar al cliente uno o dos vrtices a controlar. El otro lo controla
informtica. De manera que si un cliente se centra en los vrtices producto y
costo, Informtica se centra en explicar como resulta afectada la
planificacin y, en lo posible, de equilibrar el tringulo manipulando ese vrtice.
De igual manera si el cliente se fija nicamente en el producto, Informtica
puede darle una gran variedad de opciones de costo y planificacin.
5.3 COMO
GANAR TIEMPO EN UNA PLANIFICACIN DE ACTIVIDADES DEL

CENTRO DE INFORMTICA
Estudios hechos en Estados Unidos demuestran que las reas de informtica

tienen una eficiencia menor al 50%. El tiempo restante se gasta en actividades
improductivas , como el uso de herramientas de productividad que no funcionan,
la reparacin de mdulos desarrollados de forma descuidada, trabajo perdido
debido a la falta de control de configuracin, entre otras causas.
25/86
Manual Terico
Dnde se puede ahorrar tiempo?. Podemos ganar tiempo si lo recuramos de

algunas de las siguientes reas donde los desperdicios son muy frecuentes:
a. Trabajo repetido: Repetir requerimientos, diseo y cdigo defectuoso
puede consumir generalmente de un 40 a un 50% del costo total de un
proyecto informtico. La correccin temprana de defectos, cuando
resultan menos costosos de corregir y cuando las correcciones evitan
una repeticin posterior del trabajo ofrece una oportunidad potente
para reducir el tiempo.
b. Cambio de prestaciones del producto: El cambio de prestaciones
puede deberse a cambios en los requerimientos por parte del cliente o
meticulosidad por parte del informtico. Un proyecto normal
experimenta al menos un 25% de cambios a lo largo de su desarrollo, lo
que aade al menos un 25% ms de esfuerzo. No limitar los cambios en
los requerimientos a los estrictamente necesarios es un error clsico que
afecta enormemente el tiempo de la planificacin. Eliminar o minimizar
el cambio de prestaciones ayuda mucho a eliminar los retrasos globales
en la planificacin.
c. Especificacin de requerimientos: Esta actividad se da antes del inicio
formal de proyecto, al menos antes de la participacin fuerte de
Informtica en el mismo, y es ms abierta que el resto, por lo que es
posible desperdiciar grandes cantidades de tiempo en ella. Un
moderado sentido de urgencia durante la recopilacin de
requerimientos puede evitar una sensacin total de pnico al final del
proyecto.
d. El inicio difuso: El tiempo total necesario para desarrollar un proyecto
informtico va desde el punto en que el proyecto es solo una visin
en la mente de alguien hasta que el producto terminado est en
manos del cliente. Algn tiempo despus de que el proyecto es una
visin se toma la decisin de comenzar. El tiempo entre ambos
eventos puede ser muy largo, y, sin embargo,, en la mente del cliente
es tiempo puede formar parte del tiempo previsto para el proyecto.
Esto es un inicio difuso el cual puede consumir gran parte del tiempo
destinado para el proyecto. Como no se realizan controles formales (no
hay planificacin, ni presupuesto, ni metas, ni objetivos) durante este
perodo el progresos es difcil de controlar. En el inicio difuso se puede
perder tiempo por estas razones:
Nadie tiene asignada la responsabilidad del desarrollo del proyecto.
No existe sensacin de urgencia para tomar la decisin de
comenzar/no comenzar el proyecto.
Los aspectos clave en la viabilidad del proyecto no pueden ser
explorados hasta que se apruebe el presupuesto del proyecto.
El proyecto debe esperar un ciclo anual de aprobacin de
proyectos y presupuestos.
26/86
Manual Terico
El equipo que desarrolla el proyecto no es el mismo que trabaj

para su aprobacin. Al preparar el equipo de desarrollo, familiarizarlo
con el producto y encargarle la tarea se pierde tiempo y empuje.
El esfuerzo empleado en el inicio de un proyecto suele ser bajo, pero el
costo del retraso puede ser alto. La nica forma de recuperar un mes
perdido en el inicio difuso es acortar en un mes el desarrollo del
proyecto en su fase final, y hacer esto al final cuesta ms que hacerlo al
inicio.
Aprovechar el tiempo al inicio del proyecto representa una de las
oportunidades ms econmicas y efectivas ganar tiempo en la
planificacin de proyectos informticos.
27/86
Manual Terico
6 ORGANIZACIN
6.1 DEFINICIN
Una Organizacin es un patrn de relaciones, muchas relaciones simultneas
entrelazadas, por medio de las cuales las personas, bajo el mando de los
gerentes, persiguen metas comunes establecidas en la planeacin.
Las metas que los administradores desarrollan en funcin de la planificacin
suelen ser ambiciosas y de largo alcance. Los gerentes quieren estar seguros de
que sus organizaciones podrn aguantar mucho tiempo. Por su parte, los
miembros de una organizacin necesitan un marco estable y comprensible en el
cual puedan trabajar unidos para alcanzar las metas de la organizacin.
La funcin gerencial de Organizacin implica tomar decisiones para crear este
tipo de marco, de manera tal que las organizaciones puedan durar desde el
presente hasta un futuro de mediano y largo plazo.
6.2 PASOS DE LA ORGANIZACIN

A pesar de lo enunciado anteriormente, organizar es una funcin gerencial
permanente. Las estrategias pueden cambiar, el entorno tambin y la eficacia y
eficiencia de las actividades de la organizacin pueden no estar acorde con el
nivel que los gerentes querran. Sea que se este consituyendo una organizacin
nueva, que se est modificando una existente o que se cambien radicalmente las
relaciones de una organizacin, hay cuatro pasos bsicos que el gerente debe
dar para construir una organizacin:
a. Divisin del Trabajo: Dividir la carga de trabajo entera en tareas que
puedan ser ejecutadas, en forma lgica y cmoda, por personas o
grupos.
b. Departamentalizacin: Combinar las tareas de forma lgica y
eficiente. La agrupacin de los empleados y tareas.
c. Jerarqua: Especificar quien depende de quin en la organizacin.
d. Coordinacin: Establecer mecanismos para integrar las actividades
de los departamentos en un todo congruente y para vigilar la
eficacia de dicha integracin.
6.3 ESTRUCTURA ORGANIZACIONAL

La estructura organizacional se refiere a la forma en que se dividen, agrupan y
coordinan las actividades de la organizacin en cuanto a las relaciones entre los
gerentes y los empleados, entre gerentes y gerentes y ente empleado y
empleados. Los departamentos de una organizacin se pueden estructurar
formalmente en en tres formas bsicas: por funcin, por producto/mercado, o en
forma de matriz.
6.3.1 ESTRUCTURA ORGANIZACIONAL DE UN CENTRO DE INFORMTICA

Cualquiera de las tres formas bsicas de organizacin aplica para los centros
informtica de una empresa, y ser esta la que decidir cual forma se ajusta
28/86
Manual Terico
mejor a sus necesidades, segn la importancia estratgica que tenga el centro o

departamento de informtica.
6.3.1.1 Organizacin Funcional

Esta organizacin rene, en un departamento a todos los que se dedican a una
actividad o varias relacionadas, que se llaman funciones. Por ejemplo, un centro
de informtica dividido por funciones puede tener la siguiente estructura:
Compaa XYZ
Estructura Organizacional
Centro de Informtica
Gerente de
Informtica
Seccin de
Soporte a Usuarios
Seccin de
Desarrollo de
Sistemas
Seccin de Admon.
de Sistemas y
Operaciones
Seccin de
Comunicaciones
Es probable que la organizacin funcional sea la manera ms lgica y bsica de

departamentalizacin. Una ventaja importante es que facilita mucho la
supervisin, pues cada gerente debe ser experto solo en una gama limitada de
habilidades. Adems la estructura funcional facilita el movimiento de las
habilidades especializadas para usarlas en los puntos donde ms se necesitan,
aprovechando con eficiencia los recursos especializados.
Por supuesto, esta forma de organizacin conlleva sus desventajas, entre ellas:
a. Es ms difcil determinar la responsabilidad y juzgar los resultados de
un proyecto informtico.
b. La coordinacin de funciones de los miembros de la organizacin se
puede convertir en un serio problema para los gerentes de
informtica.
6.3.1.2 Organizacin por Producto/Servicio/Regin

Rene en una unidad de trabajo a todos los que participan en la produccin e
implantacin de una solucin informtica, a todos los que estn en una cierta
zona geogrfica o a todos los que tratan con un cierto tipo de cliente(usuario).
En un centro de informtica esta organizacin podra ser as:
29/86
Manual Terico
Compaa XYZ
Estructura Organizacional
Centro de Informtica
Gerente de
Informtica
Equipo de Proyecto
Sistema Administrativo
Equipo de Proyecto
Sistema de Produccin/
Ventas
Equipo de Proyecto de
Sistema de Informacin
Estadstica
Equipo de Proyecto de
E-Business/Ecommerce
La mayor parte de las empresas grandes, con grandes sistemas, tienen este tipo
de organizacin. Dentro de cada una de esas unidades hay una estructura
funcional como la definida anteriormente.
Cuando la departamentalizacin de una empresa se torna demasiado compleja
para coordinar la estructura funcional, la gerencia de informtica crear estas
divisiones semiautnomas. En cada divisin los gerentes y empleados disean,
desarrollan e implantan sus propios servicios o productos.
6.3.1.3 Organizacin Matricial

Es un producto hbrido que trata de combinar los beneficios de los dos tipos de
diseo a la vez que pretende evitar sus inconvenientes. Una organizacin de tipo
matricial cuenta con los dos tipos de estructura al mismo tiempo. Los empleados
tienen, de hecho, dos jefes, es decir, trabajan con dos cadenas de mando. Una
cadena de mando corresponde a las funciones y otra a los proyectos especficos
(divisiones) a las que est asignado.
La diferencia radica en el tipo de autoridad que ejerce cada gerente. En estas
estructuras el gerente funcional ejerce autoridad en cuanto a la definicin de
polticas, condiciones de trabajo, estndares y normas en general que regulan el
trabajo del empleado. Por su parte, el gerente de divisin/producto, tiene la
misin fundamental de asegurarse que los productos y servicios se estn
produciendo, acorde con los estndares establecidos por la gerencia funcional.
La desventaja es que no todo mundo se adapta bien al sistema matricial . Los
miembros del equipo, para ser efectivos, deben contar adems con buenas
habilidades interpersonales y ser flexibles y cooperativos. Adems la moral se
puede ver afectada de manera negativa cuando el personal se reordena, una
vez terminado un proyecto, y se inician otros nuevos.
Por ltimo, si las jerarquas no estn establecidas con solidez y comunicadas con
eficiencia, existe el peligro, en opinin de algunos analistas, de que las directrices
contradictorias y las responsabilidades mal definidas aten las manos de los
gerentes.
30/86
Manual Terico
7 ORGANIZACIN: EQUIPOS DE TRABAJO EN CENTROS DE

INFORMTICA
7.1 DEFINICIN
Un equipo es un nmero de personas pequeo con habilidades complementarias,
que estn comprometidas en un propsito, objetivos de rendimiento y con un
enfoque comn, en el que todos sean responsables ante todos.
Si las mentes trabajan juntas, a veces el total puede ser mayor que la suma de las
partes. Si las mentes estn en desacuerdo el resultado puede ser menor. Un
equipo existe siempre que dos cabezas juntas funcionan mejor que cada una por
separado.
7.2 GRUPOS Y EQUIPOS

No todos los grupos son equipos. Algunos proyectos se pueden llevar a cabo por
un grupo de personas que cooperan pero que no forman un equipo. Algunos
proyectos no llegan al nivel de compromiso que supone un equipo.
Adems del compromiso los miembros de un equipo unido y bien conformado
trabajan duro, se divierten con su trabajo y emplean gran parte de su tiempo
centrndose en los objetivos del proyecto.
7.3 CREACIN DE UN EQUIPO DE ALTO RENDIMIENTO

Un equipo con gran cohesin y alto rendimiento tiene las siguientes
caractersticas:
Alta visin u objetivo compartidos: Una visin comn crea confianza entre
los miembros del equipo, porque todos trabajan para llegar al mismo objetivo.
Tambin ayuda a que el equipo se mantenga concentrado y a evitar que se
pierda tiempo debido a errores. La visin tambin necesita ser elevada para
que surta un efecto de motivacin. El equipo necesita que se le presente un
desafo, una misin.
Sentido de identidad del equipo: A medida que los miembros del equipo
trabajan juntos hacia su visin comienzan a percibir una sensacin de
identidad del equipo. Las compaas inteligentes refuerzan el sentido de
identidad del equipo proporcionando camisetas del equipo, block de notas,
tasas, o cualquier implemento que identifique al equipo como una entidad
legtima. La satisfaccin proviene de los logros del equipo. Los objetivos
comunes se consideran ms importantes que los personales. Tienen la
oportunidad de conseguir con el equipo algo que individualmente no
conseguiran.
Estructura dirigida por resultados: Los equipos se pueden estructurar de
forma que se obtenga una salida ptima, o se pueden estructurar de forma
que sea casi imposible que produzcan algo. Para los proyectos informticos se
necesita estructura el equipo teniendo en cuenta la mxima velocidad de
desarrollo. Las cuatro caractersticas fundamentales de una estructura de
equipo dirigida por resultados son:
31/86
Manual Terico
a. Las tareas deben ser claras y todos deben ser responsables de su

trabajo en todo momento.
b. El equipo debe tener un sistema de comunicacin efectivo que admita
el libre flujo de informacin entre los miembros del equipo.
c. El equipo debe tener algn medio de control sobre el rendimiento
individual y la realimentacin. Debe saber a quin recompensar, quien
necesita desarrollarse individualmente y quin puede asumir mayor
responsabilidad en el futuro.
d. Las decisiones se deben tomar, si es posible, basndose en hechos ms
que en opiniones subjetivas.
Miembros competentes del equipo: Suele escogerse a los miembros del
equipo por las razones equivocadas. Por ejemplo: porque tienen un cierto
inters en el proyecto, porque cobran poco o, lo ms normal, porque
simplemente estn disponibles.
Los miembros del equipo deben elegirse comprobando quienes poseen estas
tres clases de aptitudes:
a. Habilidades tcnicas especficas: rea de aplicacin, plataforma,
metodologas y herramientas informticas (lenguajes de programacin,
sistemas operativos, etc.).
b. Un fuerte deseo de colaborar.
c. Habilidades de colaboracin especficas que son necesarias para
trabajar eficientemente con otros.
Compromiso con el equipo: Las caractersticas de visin, reto e identidad
del equipo se funden en el rea del compromiso. En un equipo efectivo, sus
miembros se comprometen con el equipo. Hacen sacrificios personales por el
equipo que no haran para las grandes organizaciones.
Confianza mutua: La confianza consta de cuatro componentes:
a.
b.
c.
d.
Honestidad
Franqueza
Firmeza
Respeto
Si se infringe uno de estos elementos, aunque sea solo una vez, la confianza
se rompe.
Interdependencia entre los miembros: Los miembros del equipo confan en
la fuerza individual de los dems, y hacen todo lo que sea mejor para el
equipo. Todos sienten que tienen posibilidades de contribuir y que su
contribucin es importante. Todos participan en las decisiones.
Comunicacin efectiva: Los miembros de los equipos unidos estn al
corriente constantemente de lo que les sucede a los dems. Tienen cuidado
de comprobar que todos les entienden cuando hablan, y su comunicacin se
beneficia del hecho de que muestran una visin comn y un sentido de
identidad.
Sensacin de autonoma: Una de las razones por las que los proyectos, o los
equipos de trabajo, funciona tan bien, es porque se les da a los miembros la
32/86
Manual Terico
oportunidad de hacer lo que crean conveniente. Pueden trabajar sin

interferencias. El equipo puede cometer algunos errores, pero las ventajas en
motivacin compensarn los errores.
Sentido de refuerzo: La organizacin no se limita a permitirles hacer todo lo
que piensan que es correcto, sino que les apoya a la hora de llevarlo a cabo.
Un caso comn en el que los equipos no reciben un refuerzo positivo se
produce cuando no se compran elementos menores necesarios para ser
efectivos.
Tamao reducido del equipo: Si se puede mantener un equipo unido a lo
largo de varios proyectos, se puede aumentar el tamao del equipo, siempre
que sus miembros compartan una cultura profundamente arraigada.
Alto nivel de disfrute: No todo equipo que se divierte es productivo, pero la
mayora de los equipos productivos son divertidos. A los informticos les gusta
ser productivos. Adems, las personas, por naturaleza emplean ms tiempo en
hacer cosas que les divierten que las que no les divierten.
7.4 CAUSAS DE FALLO DE LOS EQUIPOS

Algunas de las razones por las que fallan los equipos son:
Falta de visin comn: Las organicaciones impiden a veces la cohesin de los
equipos echando abajo sus ideas. Cuando la idea se viene abajo, el equipo
tambin.
Falta de identidad: Sin uno o ms miembros estuvieran trabajando de forma
individual en lugar de formar parte del equipo.
Falta de reconocimiento: Algunas veces los miembros de un equipo ponen su
corazn y su alma solo para encontrar que su esfuerzo no se aprecia.
Barreras de la productividad: Las personas no pueden sobrevivir si el entorno no
contiene suficiente oxgeno, y los equipos no pueden sobrevivir si se les impide
realizar su trabajo.
Comunicacin ineficiente: Las barreras de la comunicacin incluyen: falta de
correo electrnico, insuficiencia de salas de conferencias y separacin de los
miembros del equipo en lugares geogrficamente dispersos.
Falta de confianza: Una razn por la que normalmente los equipos no se
conforman dentro de las organizaciones burocrticas es porque las
organizaciones estn basadas en la falta de confianza. Los gerentes que prestan
ms atencin a los detalles de administracin del equipo que a los resultados que
consiguen, demuestran falta de confianza.
Personas problemticas: Estas personas son fciles de identificar, solo hay que
evaluar las siguientes caractersticas y determinar si la persona en cuestin las
tiene:
a. Ocultan su ignorancia en vez de intentar aprender de sus compaeros
de equipo.
b. Tienen un deseo excesivo de intimidad
c. Son reservados
33/86
Manual Terico
d. Se quejan de las decisiones del equipo y continan revisando antiguas

discusiones despus de que el equipo las ha terminado.
e. Los otros miembros del equipo se ren o se quejan de la misma persona.
f. No se ponen a trabajar en las actividades del equipo.
No hay que tener temor de echar a una persona que no tiene mayor inters en el
equipo ya que:
a. Es raro ver un problema importante provocado por falta de
experiencia. Es casi siempre cuestin de actitud, y las actitudes son
difciles de cambiar.
b. Cuanto ms tiempo se mantiene a una persona problemtica, esta
persona adquirir ms legitimidad a travs de contactos casuales con
otros grupos y directivos, un crecimiento de la base de cdigo que la
persona tiene que mantener, etc.
34/86
Manual Terico
8 ORGANIZACIN: ESTRUCTURA DE EQUIPOS DE TRABAJO EN

CENTROS DE INFORMTICA
8.1 INTRODUCCIN
Aunque se tenga personal formado, motivado y acostumbrado a trabajar duro,
una estructura errnea del equipo puede minar el esfuerzo en lugar de lograr un
desempeo exitoso. Una mala estructura del equipo puede aumentar el tiempo
para desarrollar un proyecto, reducir la calidad, deteriorar la moral, incrementar
los cambios de personal y llevar a la cancelacin de proyectos.
8.2 TIPOS DE EQUIPOS

8.2.1 CLASIFICANDO SEGN EL CRITERIO DE OBJETIVO GENERAL
La primera consideracin al organizar un equipo es determinar el objetivo general
del mismo. Los objetivos generales de un equipo en el rea de informtica son:
Resolucin de Problemas
Creatividad
Ejecucin tctica
Una vez identificado el objetivo ms general del equipo, se prepara una
estructura de equipo que haga hincapi en la caracterstica ms importante
para este tipo de equipo.
Equipo para resolucin de problemas: Un grupo de programadores
intentando diagnosticar un nuevo defecto del software formaran un equipo
de este tipo. Los miembros de este equipo deben ser: de confianza,
inteligentes y pragmticos. Este tipo de grupo est ms ocupado en
cuestiones muy especficas.
Equipo para creatividad: El objetivo de un equipo de este tipo es explorar
posibilidades y alternativas. Un grupo de programadores que est sentando
nuevas bases en aplicaciones multimedia sera un tipo de equipo para
creatividad. Los miembros de este equipo necesitan: estar motivados, ser
independientes, creativos y persistentes.
Equipo para ejecucin tctica: Un equipo de este tipo se centra en la
ejecucin de un plan bien definido. Un equipo de software trabajando sobre
una actualizacin bien definida de un producto, en la que el propsito no es
definir nuevas bases, sino poner caractersticas bien conocidas en manos de
los usuarios tan pronto como sea posible, es un buen ejemplo de este tipo de
equipo. Los miembros de un equipo para ejecucin tctica necesitan tener:
sentido de la urgencia de su misin, estar ms interesados en la accin que en
la intelectualizacin esotrica y ser leales al equipo.
El siguiente cuadro resume los objetivos de los equipos y las estructuras de equipo
que soportan dichos objetivos:
35/86
Manual Terico
Objetivo General
Resolucin de
Problemas
Creatividad
Caracterstica Dominante
Ejemplo tpico en un
centro de informtica
Confianza
Mantenimiento corrector
en sistemas en marcha
Autonoma
Desarrollo de un nuevo
producto
nfasis en el Proyecto
Centrado en cuestiones
especficas
Explorar posibilidades y
alternativas
Modelos apropiados del

ciclo de vida
Codificar y corregir,
espiral
Criterios de seleccin del

equipo
Inteligentes,
desenvueltos, sensibles,
alta INTEGRIDAD
Modelos apropiados
equipo de Software
Equipo de negocios,
equipo de bsqueda y
rescate, equipo SWAT
Prototipado evolutivo,
entrega evolutiva,
espiral, diseo para
planificacin, disemo
para herramientas
Cerebrales,
independientes,
pensadores con
iniciativa, tenaces
Equipo de negocios,
equipo con programador
en jefe, equipo en la
sombra, equipo de
prestaciones, equipo de
teatro
de
Ejecucin Tctica
Claridad
Desarrollo de una
actualizacin de un
producto
Tareas muy centradas con
funciones claras. Marcadas
por un claro xito o
fracaso
Cascada, cascada
modificada, entrega por
etapas, diso para
planificacin, diseo para
herramientas
Leales, comprometidos,
dispuestos a la accin, con
sentido de urgencia,
responsables
Equipo de negocios, equipo
con programador jefe,
equipo de prestaciones,
equipo SWAT, equipo
profesional de atletismo
8.2.2 CARACTERSTICAS ADICIONALES PARA EL DISEO DE EQUIPOS

Hay cuatro caractersticas de la estructura de equipos que parecen caracterizar
todos los tipos de equipos que funcionan con efectividad:
Papeles y responsabilidades claras: En un equipo de alto rendimiento, todo
el mundo cuenta y cada uno sabe lo que debe hacer.
Monitorizacin del rendimiento individual y retroalimentacin: La otra cara
de las responsabilidades consiste en que los miembros del equipo necesitan
saber si estn trabajando de acuerdo a las expectativas del equipo. El equipo
necesita disponer de mecanismos para que sus miembros sepan en qu
aspectos tienen un rendimiento aceptable y cuales son los que necesitan
mejorar.
Comunicacin efectiva: La informacin debe ser fcil de consultar.
Reservar la informacin es malo para la moral de un equipo. Toda la
informacin relevante debe estar disponible para todos. Adems los miembros
del equipo necesitan tener oportunidad de plantear cuestiones que no estn
en la agenda formal del grupo. Y debe mantenerse una historia de las
cuestiones planteadas y las decisiones tomadas.
Toma de decisiones basada en hechos: Los juicios subjetivos pueden minar
la moral de un equipo. Los miembros del equipo necesitan comprender las
bases de todas las decisiones que les afectan.
36/86
Manual Terico
8.3 MODELOS DE EQUIPO

8.3.1 EQUIPO DE NEGOCIOS
Es la estructura ms comn: un grupo de iguales encabezado por un jefe tcnico.
Aparte del jefe tcnico todos los miembros del equipo tienen el mismo estatus
diferencindose en su mbito de experiencia: bases de datos, grficos, interfases
de usuario, redes, comunicaciones o lenguajes de programacin, por ejemplo.
Generalmente, el jefe es elegido por su experiencia tcnica y no por su eficacia
como gestor.
Habitualmente el jefe es responsable de tomar decisiones finales sobre cuestiones
tcnicas.
Este modelo funciona bien con grupos pequeos, que llevan juntos mucho
tiempo y que pueden estructurar sus relaciones con el tiempo.
Es adaptable a todos los tipos de equipo (resolucin de problemas, creatividad y
ejecucin tcnica), pero casi siempre es posible encontrar un modelo mejor para
cada situacin particular.
8.3.2 EQUIPO CON PROGRAMADOR JEFE

Ms orientado a los proyectos de software. Saca partido del hecho de que
algunos tcnicos son 10 veces ms productivos que otros. La estrella del equipo es
el programador jefe. Esta persona hace la especificacin completa, todo el
diseo, escribe la mayor parte de los programas y es responsable final de
prcticamente todas las decisiones del proyecto.
El resto de los miembros del equipo son libres de especializarse, crendose
algunos papeles como los siguientes:
Programador de reserva. El otro yo del programador jefe. Crtico,
ayudante de investigacin y contacto tcnico con los grupos externos
(usuarios).
Administrador. Gestiona cuestiones administrativas, como dinero,

personal, espacio y equipos.
Herrero. Responsable de crear herramientas solicitadas por el
programador jefe (utileras, macros, programas especiales, etc.).
Abogado del lenguaje. Responde preguntas tericas complicadas
acerca de las herramientas que se estn utilizando.
Esta estructura es adecuada para algunos proyectos de creatividad ya que
teniendo un cerebro al frente se mantiene la integridad conceptual de la solucin
buscada, y para proyectos de ejecucin tctica en los que el programador jefe
resulta ser una especie de dictador que implante las condiciones ms adecuadas
para culminar con xito el proyecto.
Sin embargo, es un modelo difcil de implantar ya que requiere una superestrella
que desea trabajar excepcionalmente duro, que apenas tiene otros intereses y
que est dispuesto a trabajar jornada doble. La mayora de las organizaciones
carece de elementos como este.
37/86
Manual Terico
8.3.3 EQUIPO EN LA SOMBRA

Aglutina un grupo de tcnicos creativos y con talento, se les pone en una
situacin en la que son liberados de restricciones burocrticas y se les da la
libertad de desarrollar e innovar. La directiva no desea saber detalles de cmo
trabajan, solo quieren saber que lo estn haciendo.
Este modelo tiene la ventaja de crear una sensacin de propiedad y compromiso.
El efecto motivacional puede ser impresionante. Tiene la desventaja de no
ofrecer mucha visibilidad del progreso del equipo.
Los equipos en la sombra son adecuados para proyectos exploratorios en los que
la creatividad es absolutamente importante. Un equipo de estos no es una
estructura rpida cuando se necesita resolver un problema claramente definido,
o cuando se necesita ejecutar un plan bien entendido.
8.3.4 EQUIPO DE PRESTACIONES

El desarrollo, el control de calidad, la documentacin, la gestin del programa y
el marketing estn organizados con las estructuras jerrquicas tradicionales de
responsabilidad. Los analistas informan al jefe de analistas, los programadores al
jefe de programadores, los tcnicos de hardware y software informan al
responsable de soporte tcnico, etc. El equipo de prestaciones se hace
responsable sobre la parte del producto que le corresponde.
Los equipos de prestaciones presentan ventajas de potenciacin, facilidad de
seguimiento y equilibrio.
Los equipos de prestaciones resultan adecuados para proyectos de resolucin de
problemas, ya que ofrecen el refuerzo y la facilidad de seguimiento necesarios
para resolver las cuestiones planteadas de forma expedita.
8.3.5 EQUIPO DE BSQUEDA Y RESCATE

Se centra en resolver un problema especfico. Necesita conocer ntimamente el
terreno donde busca, necesita estar listo para actuar en el momento en que se le
requiera. Combina un conocimiento especializado de herramientas de hardware
y software especficas con un conocimiento igualmente especializado del
entorno de la empresa. Debe tener la capacidad de responder inmediatamente.
Obviamente es el ms apropiado para equipos orientados a la resolucin de
problemas. Est demasiado dirigido a problemas bsicos como para soportar
mucha creatividad, y est demasiado orientado a corto plazo como para
soportar la ejecucin tctica.
8.3.6 EQUIPO SWAT

Esta basado en equipos policacos o militares SWAT significa armas y tcticas
especiales (special weapons and tactics). En este tipo de equipo, cada miembro
est entrenado especialmente en un tema.
La idea bsica de este equipo es reunir un grupo de personas con slida
formacin en una herramienta o mtodo determinado, y dedicarlas a un
problema que se adapta perfectamente a ser resuelto con esa herramienta o
mtodo.
38/86
Manual Terico
Dicha herramienta o mtodo puede ser: un lenguaje de programacin (Delphi,

PowerBuilder, Visual Basic, etc.), un DBMS (Oracle, Informix, Parados, etc), un
sistema operativo (NT, Unix, etc.) o cualquier otra herramienta informtica.
Estos grupos son generalmente permanentes. Son muy adecuados para
proyectos de ejecucin tctica, ya que su trabajo no consiste en ser creativos,
sino en implementar una solucin dentro de los lmites de una herramienta o
metodologa que conocen a la perfeccin. Tambin funcionan para grupos de
solucin de problemas.
8.3.7 EQUIPO DEPORTIVO

El presidente de un equipo deportivo gestiona las decisiones entre bastidores.
Decisiones importantes, estratgicamente hablando, pero no es l quien patea la
pelota. Los hinchas no van a ver al presidente, ven a los jugadores.
De forma similar el responsable del software es importante, pero no por sus
capacidades de desarrollo. El papel del responsable es despejar el camino de
obstculos y permitir que los desarrolladores trabajen en forma eficiente. Los
desarrolladores podran crear un producto sin el responsable, pero el responsable
no hara nada sin los desarrolladores.
Los equipos deportivos tienen papeles altamente especializados. Un pitcher no
dice Ya me cans de ser pitcher, ahora quiero se catcher. En los equipos de
software que adoptan este modelo sucede lo mismo.
Este modelo se aplica mejor a los proyectos de ejecucin tctica, que hacen
nfasis en los papeles altamente especializados.
8.3.8 EQUIPO DE TEATRO

Este modelo se caracteriza por una fuerte direccin y una gran negociacin de
los papeles del proyecto. El papel central del proyecto es ocupado por el director
quien mantiene una visin del producto y asigna a la gente responsabilidades en
reas individuales. Los participantes pueden adaptar sus papeles como les dicten
sus propios instintos. Pero no pueden llevar demasiado lejos sus propias ideas,
evitando colisionar con la visin del director. La visin del director debe
prevalecer para la buena marcha del proyecto.
En el modelo de teatro, no se asigna a las personas al proyecto. Se participa en
una audicin y se acepta un papel. Antes de aceptar el papel hay una larga
negociacin.
Este modelo es particularmente apropiado para equipos informticos dominados
por fuertes personalidades.
Se aplica a proyectos de creatividad en los que se necesita, sin embargo,
mantener un control algo estricto.
Este modelo se aplica en proyectos multimedia. Antes los proyectos de software
requeran varios desarrolladores de software, ahora tienen que integrar las
contribuciones de diseadores grficos, escritores, productores de video, editores,
ilustradores y varios desarrolladores de software.
39/86
Manual Terico
9 MOTIVACIN
9.1 INTRODUCCIN
El desarrollo de trabajo en el rea de informtica, particularmente proyectos,
requiere de alcanzar un equilibrio en el manejo de cuatro factores: personas,
proceso, producto y tecnologa. Entre ellas las personas son las que ofrecen la
mayor posibilidad de mejorar el tiempo y la calidad del proyecto.
La motivacin es, indudablemente, la mayor influencia individual sobre como
trabajan las personas.
La motivacin es un factor intangible y, como tal, es difcil de cuantificar.
9.2 MOTIVACIONES TPICAS DEL INFORMTICO

Personas diferentes se motivan con factores diferentes, y los informticos no se
motivan siempre con los mismos factores que sus directivos ni con los mismos
factores que las personas en general.
Comparados con las personas en general, los informticos estn mucho ms
motivados por la posibilidad de superacin, su vida personal, la oportunidad de
ejercer supervisin tcnica y las relaciones interpersonales con sus semejantes. Los
informticos, a diferencia de las personas en general, estn menos motivados por
su posicin social, relaciones interpersonales con los subordinados,
responsabilidad y reconocimiento.
Comparados con sus directivos, los informticos estn un poco ms motivados por
la posibilidad de superacin, vida personal y oportunidad de supervisin tcnica.
Los informticos estn mucho menos motivados por la responsabilidad,
reconocimiento y relaciones interpersonales con los subordinados.
Si Ud. Es directivo e intenta motivar a los informticos de igual forma que le
gustara que le motivaran a Ud., realmente fallar.
Si se desea motivar a los informticos, debe hacerse hincapi en los estmulos
tcnicos, autonoma, posibilidad de aprender, utilizar nuevas tcnicas y correr en
la planificacin (adems de respetar sus vidas familiares).
El siguiente cuadro no muestra una verdad absoluta sino una tendencia que
puede observarse en la comparacin de la jerarqua de motivaciones para
informticos, directivos de los informticos y personas en general:
INFORMTICOS
DIRECTIVOS DE INFORMTICOS
PERSONAS EN GENERAL
1) REALIZACIN
2) POSIBILIDAD DE SUPERACIN
1) RESPONSABILIDAD
2) REALIZACIN
1) REALIZACIN
2) RECONOCIMIENTO
3) EL PROPIO TRABAJO
4) VIDA PERSONAL
5) OPORTUNIDAD DE
4) RECONOCIMIENTO
4) RESPONSABILIDAD
5) ASCENSO
6) RELACIONES
6) SALARIO
8) RELACIONES
INTERPERSONALES,
SUPERVISIN TCNICA
6) ASCENSO
7) RELACIONES
INTERPERSONALES, IGUAL
NIVEL
INTERPERSONALES,
SUBORDINADOS
7) RELACIONES
SUBORDINADOS
40/86
INFORMTICOS
8) RECONOCIMIENTO
9) SALARIO
10) RESPONSABILIDAD
11) RELACIONES
INTERPERSONALES, SUPERIORES
12) SEGURIDAD EN EL TRABAJO
13) RELACIONES
INTERPERSONALES,
SUBORDINADOS
14) POLTICAS DE LA COMPA A Y

DE ADMINISTRACIN
Manual Terico
DIRECTIVOS DE INFORMTICOS
NIVEL
8) ASCENSO
9) SAL ARIO
10) RELACIONES
11) POLTICAS DE LA COMPAA Y
DE ADMINISTRACIN

13) OPORTUNIDAD DE
SUPERVISIN TCNICA
15) CONDICIONES DE TRABAJO
14) POSICIN SOCIAL

15) VIDA PERSONAL
16) POSICIN SOCIAL
PERSONAS EN GENERAL
9) POSICIN SOCIAL
10) RELACIONES
11) RELACIONES
NIVEL
12) OPORTUNIDAD DE
SUPERVISIN TCNIC A
13) POLTICAS DE L A COMPAA Y

DE ADMINISTRACIN

15) VIDA PERSONAL
Estos factores, obviamente, pueden variar. Por ejemplo, la seguridad en el trabajo

puede tomar mayor relevancia en sociedades en las que la amenaza de
desempleo es mayor.
9.3 CINCO FACTORES PRINCIPALES DE MOTIVACIN

9.3.1 REALIZACIN
A los informticos les gusta trabajar. La mejor forma de motivarlos es darles un
entorno que les facilite centrarse en lo que ms les gusta hacer. Hay ciertos
subfactores que promueven la realizacin:
9.3.1.1 Propiedad
Las personas trabajan ms duro para lograr sus propios objetivos que para
alcanzar los de otras personas. Hay que procurar que los informticos creen sus
propias planificaciones, que tomen propiedad de sus planificaciones, asegurando
as su adhesin.
9.3.1.2 Definicin de objetivos

Si se establece un objetivo del tiempo de desarrollo trabajarn realmente los
informticos para conseguirlo? Si conocen como calza ese objetivo con otros, y si
el conjunto de objetivos es razonable, la respuesta es S,. Los informticos no
pueden responder a objetivos que cambian diariamente o que son imposibles de
cumplir en conjunto.
Definir demasiados objetivos al mismo tiempo es un problema comn,
diluyndose el tiempo en demasiadas prioridades.
Para obtener mejores resultados, se selecciona un objetivo y se deja claro que ese
es el ms importante.
9.3.2 POSIBILIDAD DE SUPERACIN

Uno de los aspectos ms excitantes de ser informtico es trabajar en un campo
que est cambiando constantemente. Cada da hay que aprender algo para
41/86
Manual Terico
estar actualizado, y la mitad de lo que hoy se necesita para trabajar ser

anticuado dentro de tres aos.
Una organizacin puede influir en esta motivacin dando a los informticos las
oportunidades de crecer en sus proyectos. Esto requiere alinear los objetivos de
crecimiento de la organizacin con los objetivos de superacin individuales.
Una organizacin puede mostrar inters en el progreso profesional de sus
informticos de cualquiera de estas formas:

Financiando cursos de desarrollo profesional

Dando tiempo para asistir a cursos o clases
Financiando la compra de libros profesionales

Asignando los informticos a proyectos que aumentaran su experiencia

Asignando un tutor a cada informtico nuevo
Evitando presiones excesivas en la planificacin
9.3.3 EL TRABAJO EN S
Cinco dimensiones del trabajo en s contribuyen a la motivacin. Las tres primeras
contribuyen a ver el significado que las personas encuentran en su trabajo:
La diversidad de tcnicas: Es el grado en que el trabajo requiere que ejercite
una serie de tcnicas, de forma que pueda evitar el aburrimiento y la fatiga.
La identidad de la tarea: Es el grado en que su trabajo requiere que cubra una
parte completa, identificable de su trabajo. Que se sienta que la participacin
es importante.
La importancia de las tareas: es el grado en el que el trabajo del informtico
afecta a otras personas y contribuye al bienestar social.
La cuata caracterstica contribuye al sentimiento de responsabilidad sobre el
resultado del trabajo:
Autonoma: Es el grado en el que el informtico tiene control sobre los medios
y mtodos que utiliza para realizar su trabajo, el sentimiento de ser su propio
jefe, y el margen de maniobra del que dispone.
La quinta y ltima caracterstica contribuye al conocimiento de las personas sobre
el resultado de sus actividades:
Retroalimentacin del trabajo: Es el grado en que la realizacin del trabajo en
s proporciona informacin clara y directa sobre cmo es de efectivo. El
desarrollo de software, por ejemplo proporciona una gran retroalimentacin;
es posible ver si el programa funciona cuando se ejecuta.
Finalmente, es importante que la organizacin propicie un ambiente que de la
oportunidad de centrarse en el trabajo en s.
9.3.4 VIDA PERSONAL

La vida personal es el cuarto factor en importancia para la motivacin de un
informtico. La prioridad que tiene este factor para un directivo es diferente de la
que tiene para un informtico y es, junto a la responsabilidad uno de los factores
ms difciles de comprender para un directivo.
Un resultado de esa disparidad es que los directivos premian en ocasiones a sus
mejores empleados asignndoles proyectos ms complejos y de mayor presin.
42/86
Manual Terico
Para lo directivos, la responsabilidad extra sera un placer, y la disminucin de la

vida personal no importara mucho. Para el informtico esto sera ms bien un
castigo.
Una empresa no puede hacer mucho para explotar este factor motivacional,
excepto por: Planificar los proyectos de una manera realista, respetar los perodos
de vacaciones y fiestas, y siendo susceptibles a peticiones ocasionales de tiempo
libre durante el trabajo.
9.3.5 OPORTUNIDAD DE SUPERVISIN TCNICA

Una oportunidad de este tipo implica que el informtico ha alcanzado un nivel de
experiencia tcnica suficiente para dirigir a otros. Para un directivo, una
oportunidad de supervisin tcnica probablemente representara un paso atrs;
el directivo ya est supervisando a otros, y, de hecho, est contento de no tener
que supervisar los detalles tcnicos.
9.4 USO DE OTROS FACTORES DE MOTIVACIN

Aparte de los cinco factores principales de motivacin, hay otros factores que se
pueden utilizar para motivar al equipo:
9.4.1 PREMIOS E INCENTIVOS

Cenas de reconocimiento con ejecutivos de la compaa, pagos extraordinarios,
gratificaciones de vacaciones, obsequios de agradecimiento, cursos especiales
(fuera del lugar de trabajo) y ceremonias de premios, entre otros.
Los informticos se cansan de trabajar para compaas desagradecidas, por
tanto, los premios son una motivacin importante a largo plazo.
Es importante dar un premio como un reconocimiento ms que como un
incentivo. El trabajo en s debe ser el motivador ms importante, as que cuando
ms nfasis se de al premio como un incentivo, se pierde ms la motivacin
potencial a largo plazo y permanente de la satisfaccin al trabajo.
9.4.2 PROYECTOS PILOTO

Uno de los ms famosos experimentos sobre motivacin y productividad se realiz
entre 1927 y 1932, en la empresa Hawthorne Works of the Western Electric
Company en Chicago. Su objetivo era determinar el efecto de la iluminacin en
la productividad.
Primero aumentaron la luz y la productividad subi.
Luego bajaron las luces y la productividad subi nuevamente.
Finalmente dejaron las luces constantes y la productividad volvi a subir.
Conclusin: Bueno, obviamente la iluminacin no tena nada que ver con los
niveles de luz. Pero si se descubri que el simple hecho de haber hecho el
experimento haba aumentado la productividad.
Este fenmeno se ha conocido desde entonces como el efecto Hawthorne, el
cual ensea que es motivante desarrollar cada proyecto como un experimento,
como un proyecto piloto. Hay que intentar una nueva metodologa en cada
proyecto nuevo y asegurarse que el equipo sepa y entienda que es un proyecto
piloto.
43/86
Manual Terico
9.5 DESTRUCTORES DE LA MORAL

9.5.1 AUSENCIA DE FACTORES DE HIGIENE
Los factores de higiene son las condiciones bsicas que un trabajador necesita
para trabajar efectivamente. En el mejor caso, los factores de higiene no crean
descontento. En el peor caso, su ausencia crea descontento.
Estos son solo algunos de los factores de higiene que condicionan el desempeo
de los informticos:
Condiciones ambientales apropiadas.
Espacio adecuado

Intimidad suficiente
Tranquilidad para poder concentrarse
Acceso a equipo de oficina

Acceso no restringido a las computadora

Equipo informtico actualizado
Reparacin inmediata o casi inmediata de equipo en mal estado.

Disponibilidad de infraestructura de comunicaciones

Hardware adecuado
Manuales de referencia y publicaciones pertinentes
Libros de consulta y ayudas de referencia en lnea
Formacin mnima en software, metodologa y herramientas.
Copias legales del software.
Libertad para escoger el horario de trabajo.
9.5.2 MANIPULACIN DE LA DIRECTIVA

Los informticos son susceptibles a ser manipulados por los directivos, a pesar de
que su deseo es que se les trate de forma sincera. Algunos directivos intentan
manipular a los informticos estableciendo fechas lmite falsas, y la mayora de los
informticos pueden oler una fecha lmite falsa a 100 metros. Los directivos que se
esfuerzan por no proporcionar detalles sobre porqu una fecha lmite es
importante, debern recordar que sus explicaciones pueden ser desalentadoras
para los informticos.
9.5.3 PRESIN EXCESIVA DE LA PLANIFICACIN

Muchas veces los directivos, y las personas de la empresa en general, no ven la
cantidad de trabajo que los informticos estn realizando, de forma que piensan
que no estn haciendo mucho y que hay que asignarles ms trabajo. En realidad,
los informticos suelen estar extremadamente automotivados, trabajan duro,
muchas horas, y encontrarse acusados de holgazanear es muy desalentador.
9.5.4 PARTICIPACIN DE DIRECTIVOS SIN PREPARACIN TCNICA

Los informticos pueden ser motivados por directivos tcnicamente incapaces,
siempre que estos reconozcan que no tienen preparacin tcnica y que limiten el
control del proyecto a decisiones no tcnicas. Si intentan meterse en decisiones
tcnicas que no comprenden, se convertirn en el blanco de las bromas del
44/86
Manual Terico
equipo de desarrollo, y la mayora de las personas no pueden ser motivadas por

alguien a quien no respetan.
9.5.5 NO INVOLUCRAR A LOS INFORMTICOS EN DECISIONES QUE LES AFECTAN

Tales como:
Compromiso con nuevas planificaciones
Modificaciones a las caractersticas de lo productos informticos que se
desarrollan en el departamento.
Contratar a nuevos miembros del equipo
Designar a informticos para otras tareas (por breves que sean) ajenas al
proyecto en que est trabajando actualmente.
Cambiar la oficina
Cambiar el hardware
Cambiar el software.
9.5.6 BARRERAS A LA PRODUCTIVIDAD

El equipo debe centrarse en el trabajo en vez de salvar las distracciones.
9.5.7 BAJA CALIDAD

Los informticos derivan parte del su amor propio a partir de los productos que
desarrollan. Si desarrollan un producto de gran calidad se sienten bien.
Si el directivo insiste en disminuir la calidad, para ganar tiempo y recursos, est
reduciendo tambin la motivacin por orgullo de propiedad.
45/86
Manual Terico
10 LIDERAZGO
10.1 INTRODUCCIN
La visin que tienen en general los trabajadores de su jefe es que ordenan,
mandan, deciden, dicen lo que se debe hacer, imponen criterios, distribuyen el
trabajo, controlan y supervisan las tareas.
La preocupacin de los directivos y mando debera estar centrada en crear una
imagen tal, que sus subordinados lo catalogaran como un colaborador ms,
orientador, escucha de su gente, generador de confianza; aceptado
naturalmente por el grupo, buen comunicador persona que apoye y ayude, que
transmite seguridad.
El mando que es lder trabaja para ser aceptado por su carisma y su servicio a un
equipo que compra ayuda y orientacin para cumplir con las metas prefijadas
que se han negociado previamente.
El lder es el respaldo del equipo, el que potencia a las personas para que se
desarrollen sus inquietudes, iniciativas y creatividad. Fomenta la responsabilidad,
el espritu de equipo, el desarrollo personal, y, especialmente, es el artesano de la
creacin de un espritu de pertenencia que une a los colaboradores para decidir
las medidas a tomar.
10.2 DEFINICIN DE LIDERAZGO

Rallph M. Stogdill, en su resumen de teoras e investigacin del liderazgo, seala
que existen casi tantas definiciones del liderazgo como personas que han
tratado de definir el concepto.
Aqu, se entender el liderazgo gerencial como:
el proceso de dirigir las actividades laborales de los miembros de un grupo y de
influir en ellas
Esta definicin tiene cuatro implicaciones importantes:
En primer trmino, el liderazgo involucra a otras personas; a los empleados
o seguidores. Los miembros del grupo; dada su voluntad para aceptar las
rdenes del lder, ayudan a definir la posicin del lder y permiten que
transcurra el proceso del liderazgo; sino hubiera a quien mandar, las
cualidades del liderazgo seran irrelevante.
En segundo el liderazgo entraa una distribucin desigual del poder entre
los lderes y los miembros del grupo. Los miembros del grupo no carecen de
poder; pueden dar forma, y de hecho lo hacen, a las actividades del grupo
de distintas maneras. Sin embargo, por regla general, el lder tendr ms
poder.
El tercer aspecto del liderazgo es la capacidad para usar las diferentes
formas del poder para influir en la conducta de los seguidores, de diferentes
maneras. De hecho algunos lderes han influido en los soldados para que
mataran y algunos lderes han influido en los empleados para que hicieran
46/86
Manual Terico
sacrificios personales para provecho de la compaa. El poder para influir nos

lleva al cuarto aspecto del liderazgo.
El cuarto aspecto es una combinacin de los tres primeros, pero reconoce
que el liderazgo es cuestin de valores. James MC Gregor Burns argumenta
que el lder que para por alto los componentes morales del liderazgo pasar a
la historia como un malandrn o algo peor. El liderazgo moral se refiere a los
valores y requiere que se ofrezca a los seguidores suficiente informacin sobre
las alternativas para que, cuando llegue el momento de responder a la
propuesta del liderazgo de un lder, puedan elegir con inteligencia.
Chiavenato, Idalberto (1993), Destaca lo siguiente:
Liderazgo es la influencia interpersonal ejercida en una situacin, dirigida a
travs del proceso de comunicacin humana a la consecucin de uno o diversos
objetivos especficos
Cabe sealar que aunque el liderazgo guarda una gran relacin con la
administracin y el primero es muy importante para la segunda, el concepto de
liderazgo no es igual al de administracin. Warren Bennis, al escribir sobre el
liderazgo, a efecto de exagerar la diferencia, ha dicho que la mayor parte de las
organizaciones estn sobreadministradas y sublideradas. Una persona quizs sea
un gerente eficaz, buen planificador y administrador, justo y organizado, pero
carente de las habilidades del lder para motivar. Otras personas tal vez sean lder
eficaces, con habilidad para desatar el entusiasmo y la devolucin, pero carente
de las habilidades administrativas para canalizar la energa que desatan en otros.
Ante los desafos del compromiso dinmico del mundo actual de las
organizaciones, muchas de ellas estn apreciando ms a los gerentes que
tambin tiene habilidades de lderes.
El liderazgo es importante en una institucin, as como en un centro de
informtica, porque:
Es importante por ser la capacidad de un jefe para guiar y dirigir.
Una organizacin puede tener una planeacin adecuada, control y
procedimiento de organizacin y no sobrevivir a la falta de un lder apropiado.
Es vital para la supervivencia de cualquier negocio u organizacin.
Por lo contrario, muchas organizaciones con una planeacin deficiente y
malas tcnicas de organizacin y control han sobrevivido debido a la
presencia de un liderazgo dinmico.
10.3 TENDENCIAS DEL LIDERAZGO

A medida que cambian las condiciones y las personas, cambian los estilos de
liderazgo. Actualmente la gente busca nuevos tipos de lder que le ayuden a
lograr sus metas. Histricamente han existido cinco edades del liderazgo (y
actualmente estamos en un periodo de transicin hacia la sexta). Ellas son:
47/86
10.3.1
Manual Terico
EDAD DEL LIDERAZGO DE CONQUISTA
Durante este perodo la principal amenaza era la conquista. La gente buscaba el

jefe omnipotente; el mandatario desptico y dominante que prometiera a la
gente seguridad a cambio de su lealtad y sus impuestos.
10.3.2
EDAD DEL LIDERAZGO COMERCIAL.
A comienzo de la edad industrial, la seguridad ya no era la funcin principal de

liderazgo la gente empezaba a buscar aquellos que pudieran indicarle como
levantar su nivel de vida.
10.3.3
EDAD DEL LIDERAZGO DE ORGANIZACIN
Se elevaron los estndares de vida y eran ms fciles de alcanzar. La gente

comenz a buscar un sitio a donde pertenecer. La medida del liderazgo se
convirti en la capacidad de organizarse.
10.3.4
EDAD DEL LIDERAZGO E INNOVACIN
A medida que se incrementa la taza de innovacin, con frecuencia los productos

y mtodos se volvan obsoletos antes de salir de la junta de planeacin. Los lderes
del momento eran aquellos que eran extremadamente innovadores y podan
manejar los problemas de la creciente celeridad de la obsolescencia.
10.3.5
EDAD DEL LIDERAZGO DE LA INFORMACIN
Las tres ltimas edades se han desarrollado extremadamente rpido (empez en

la dcada del 20). Se ha hecho evidente que en ninguna compaa puede
sobrevivir sin lderes que entiendan o sepan como se maneja la informacin. El
lder moderno de la informacin es aquella persona que mejor la procesa, aquella
que la interpreta ms inteligentemente y la utiliza en la forma ms moderna y
creativa.
10.3.6
LIDERAZGO EN LA NUEVA EDAD
Las caractersticas del liderazgo que describiremos, han permanecido casi

constante durante todo el siglo pasado. Pero con la mayor honestidad, no
podemos predecir qu habilidades especiales van ha necesitar nuestros lderes en
el futuro. Podemos hacer solo conjeturas probables. Los lderes necesitan saber
como se utilizan las nuevas tecnologas, van ha necesitar saber como pensar para
poder analizar y sintetizar eficazmente la informacin que estn recibiendo, a
pesar de la nueva tecnologa, su dedicacin debe seguir enfocada en el
individuo. Sabrn que los lderes dirigen gente, no cosas, nmeros o proyectos.
Tendrn que ser capaces de suministrar la que la gente quiera con el fin de
motivar a quienes estn dirigiendo. Tendrn que desarrolla su capacidad de
escuchar para describir lo que la gente desea. Y tendrn que desarrollar su
capacidad de proyectar, tanto a corto como a largo plazo, para conservar un
margen de competencia.
48/86
Manual Terico
11 COMUNICACIN
11.1 INTRODUCCIN
En este capitulo se analiza el tema de la comunicacin trmino que refleja el
inters de transmitir informacin, ideas, sentimientos, pensamientos, conceptos
con el fin de que sean entendidos y que tengan la posibilidad de ser aplicados en
algo de inters comn o particular.
11.1.1
QU ES LA COMUNICACIN?
La comunicacin es la facultad que tiene el ser vivo de transmitir a otro u otros,

informaciones, sentimientos y vivencias. En toda comunicacin tiene que haber
un emisor, un mensaje y un receptor.
11.1.2
CMO NOS COMUNICAMOS?
Cuando hablamos de seres vivos, no nos referimos tan slo a los humanos, ya que
desde los insectos hasta los grandes mamferos tienen dicha facultad, siendo el
hombre el nico ser que puede comunicarse por va oral; mientras que los dems,
lo hacen por sonidos (pjaros, cuadrpedos, delfines, ballenas) , friccin de
elementos de su cuerpo (grillos, chicharras) o por accin (formacin de vuelo de
las abejas, posicin del cuerpo de perros o venados, formacin de nado de los
peces). Los mamferos, incluido el hombre, tambin tienen la caracterstica de
comunicarse por el tacto (contacto corporal).
El proceso de la comunicacin se da a travs de una fuente (informacin), la
codificacin, el mensaje, el canal, la decodificacin, el receptor y la
retroalimentacin.
11.2 MODELO DE COMUNICACIN

El modelo bsico de comunicacin se compone de los siguientes elementos:
Canal de seales
Fuente
Codificador
Decodificador
Receptor
Mensaje: Qu vamos a decir, a quin se lo vamos a decir, cmo se lo

vamos a decir y por qu se lo vamos a decir. En el grfico anterior el mensaje
es lo que fluye a travs de las lneas que unen cada uno de los elementos.
Fuente: Es el emisor del mensaje.
Codificador: Acta sobre el mensaje para convertirlo en seales que
acepte el canal.
49/86
Manual Terico
Canal de seales: Transportan las seales codificadas.

Decodificador: Acta sobre las seales recibidas para extraer el mensaje
en una forma que el receptor pueda utilizar.
Receptor: Es el que recibe el mensaje en la forma en que la extrae el
decodificador.
Alrededor de estos elementos estn las fuentes de ruido que son los hechos
externos introducen las seales de interferencia, y que pueden distorsionar el
mensaje en cualquiera de sus etapas a partir de que el mensaje sale de la fuente.
Una vez recibido y entendido el mensaje, el receptor prepara una respuesta, lo
que se conoce como retroalimentacin, en la que l se convierte en la fuente y el
emisor se convierte en receptor.
11.3 EL MENSAJE
En toda comunicacin el emisor proyecta un mensaje que es recibido por el
receptor. Esta es la triloga de la comunicacin.
EMISOR
MENSAJE
RECEPTOR
En el momento de recibir el mensaje, el receptor inicia un proceso mental por el

cual lo decodifica y toma una actitud, sea de reaccin o de asimilacin. Aqu se
inicia la gran diferencia entre el animal y el hombre.
En ese momento intervienen dos elementos:
La Carga Emocional: En todo mensaje, el emisor proyecta una carga emocional,
la cual puede ser considerada como simptica, antiptica, aptica o emptica.
La percepcin: La gran diferencia entre el animal y el hombre en cuanto a la
comunicacin se refiere, es que el ser humano adems de recibir la
comunicacin, la percibe y la discierne. Es decir, la asimila y, de acuerdo a los
estereotipos, prejuicios y cargas emocionales, crea una actitud frente a ella,
despus de lo cual proyecta la respuesta o la retroalimenta. Es la diferencia entre
ver y mirar, or y escuchar o tocar y palpar.
11.4 FORMAS DE COMUNICACIN

La comunicacin puede estructurarse de forma:
Directa: Es la comunicacin que se desarrolla entre el emisor y el receptor o
receptores en forma personal, con o sin ayuda de herramientas. Es llamada
tambin comunicacin boca-odo. (Hablar frente a frente, charlas,
conferencias, etc.
Indirecta: Es aquella donde la comunicacin est basada en una
herramienta o instrumento ya que el emisor y el perceptor estn a distancia. La
comunicacin indirecta puede ser personal o colectiva.
50/86
Manual Terico
Indirecta/personal: Se desarrolla con la ayuda de una herramienta o

instrumento (hablar por telfono, enviar una comunicacin impresa,
radioaficionados, correo electrnico, chat por internet, etc.)
Indirecta/colectiva: El emisor se comunica con un grupo de receptores
ayudado por una herramienta o instrumento (peridicos, televisin, radio, cine,
libros, pgina web, videos, etc.). Se le conoce tambin como comunicacin
social o de masas.
11.5 TIPOS DE COMUNICACIN

La interrelacin de las personas en una institucin puede ser catalogada as:
Formal: Es aquella comunicacin cuyo contenido est referido a aspectos
laborales. En general, sta comunicacin utiliza la escritura como medio
(Comunicados, memoranda, etc.. La velocidad es lenta debido a que tiene
que cumplir todas las formalidades burocrticas.
Informal: Es aquel tipo de comunicacin cuyo contenido, a pesar de ser de
aspectos laborales, utiliza canales no oficiales. (Reunin alrededor del botelln
de agua, encuentros en los pasillos, etc.). Es ms veloz que la formal.
Rumores: Es la comunicacin informal que recorre la institucin sin respetar
canales y a la velocidad de la luz.
11.6 DIRECCIONES DE LA COMUNICACIN

Existen direcciones en la comunicacin:
Vertical Descendente: Puede realizarse de manera descendente que va
de los puestos gerenciales a los niveles ms bajos, por ejemplo: el notificar a los
operarios de produccin que debido a su esfuerzo la empresa logro grandes
utilidades y que se llevaran a la bolsa un bono. Esta noticia, probablemente, se
les har llegar a travs de un memorando.
Vertical Ascendente: la comunicacin adems se lleva a cabo de manera
ascendente, de manera contraria a la anterior, haciendo que las personas de
un puesto inferior hagan llegar sus quejas o sugerencias a su jefe inmediato a
la direccin general si as lo requiere el caso. En una comunicacin
corporativa ptima, debera existir la comunicacin vertical ascendente.
Horizontal: Se desarrolla entre los empleados de un mismo nivel corporativo.
Muy pocas veces utiliza las canales oficiales y es totalmente informal. Tambin
es conocida como comunicacin plana.
11.7 COMO MEJORAR LOS PROCESOS DE COMUNICACIN

La diferencia entre una comunicacin efectiva y una inefectiva puede radicar en
el grado en que las partes que se comunican manejen debidamente cuatro
aspectos del proceso de la comunicacin: las diferencias de percepcin, las
emociones, las incongruencias entre la comunicacin verbal y no verbal y la
confianza (o desconfianza) previa de las partes.
51/86
Manual Terico
Diferencias de Percepcin: Es uno de los obstculos ms comunes para la

comunicacin. Las personas que tienen diferentes antecedentes, en cuanto a
conocimientos y experiencias, suelen percibir el mismo fenmeno desde
diferentes perspectivas.
Las diferencias de percepcin pueden guardar tambin una estrecha relacin
con las diferencias de lenguaje, las diferencias de sexo, etc.
Para superar las diferencias de percepcin el mensaje se debe exponer de
manera tal que lo puedan entender todos los tipos de receptores. Siempre que se
pueda debe obtenerse informacin de los antecedentes de las personas con las
que se establecer comunicacin.
Hay que completar la situacin desde el punto de vista de la otra parte
(empata).
Es muy til pedirle al receptor que confirme los puntos bsicos del mensaje.
Adems se debe tener la sensibilidad para encontrar diversas alternativas al emitir
un mensaje. En ocasiones, incluso u pequeo cambio en la formulacin del
mensaje puede tener consecuencias muy positivas.
Reacciones emocionales: Ira, amor, odio, defensiva, celos, miedo, vergenza.
Todas estas emociones influyen en la manera en que los mensajes son
interpretados. Por ejemplo, si estamos en un ambiente donde sentimos la
amenaza de perder poder o prestigio, quiz perdamos la capacidad de
interpretar correctamente los mensajes y respondamos de forma defensiva o
agresiva.
La mejor manera de manejar las emociones es aceptarlas como parte del
proceso de comunicacin y tratar de entenderlas cuando causan problemas. Si
los empleados estn agresivos o molestos hay que hacer que hablen de lo que les
preocupa y y prestar atencin a lo que dicen.
Comunicacin verbal y no verbal: No solo existe la comunicacin oral y
escrita. Debemos poner especial cuidado en la influencia de factores no
verbales, tales como: movimientos corporales, ropa, la distancia entre una
persona y su interlocutor, la postura, los gestos, las expresiones faciales, los
movimientos de los ojos y el contacto corporal.
Confianza/Desconfianza: El hecho de que el receptor confe o desconfe de un
mensaje est en funcin, en gran medida de la credibilidad que el emisor tenga
en la mente del receptor.
En trminos generales, la credibilidad de un gerente ser mucha si los dems lo
perciben como una persona conocedora, confiable y verdaderamente
interesada en el bienestar de los dems. La credibilidad es resultado de un
proceso en el que la honradez, el juicio equilibrado y las buenas intenciones de
una persona son reconocidos por los dems.
52/86
Manual Terico
12 CONTROL
12.1 DEFINICIN
El control es la funcin administrativa mediante la cual se comprueba que lo
planificado se est cumpliendo de acuerdo a lo esperado. Mediante el control se
previenen problemas y obstculos al desempeo o se corrigen fallas encontradas
en las actividades ya realizadas. Es por eso que el control puede clasificarse
como:
Preventivo o proactivo: Mediante el cual se detectan los problemas o fallas
antes de que estas produzcan una anomala o retraso a las actividades
programadas.
Correctivo: Que es el que detecta fallas en las actividades y sugieren su
correccin.
En los centros de informtica, para efectos de control, es importante la definicin
de estndares de desempeo, que establezcan medidas contra las cuales
comparar los resultados obtenidos.
Adems es importante el establecimiento de controles generales en el
departamento de informtica que sirvan para supervisar y evaluar las
actuaciones de los empleados del departamento.
12.2 CONTROLES GENERALES EN EL CENTRO DE INFORMTICA

Pueden identificarse cinco tipos de controles generales en los centros de
informtica:
Controles orientados a las actividades del centro y al personal que las
realiza: Estos controles se centran en la planificacin, la organizacin del
departamento y las operaciones del departamento. Examina las funciones
gerenciales normales que llevan a cabos los gerentes de informtica y los
lderes de proyecto (Planear, organizar, dirigir y controlar las actividades
relacionadas con los objetivos del departamento). Los controles de este tipo
pueden incluir:
a. Presentacin peridica de informes de tareas realizadas.
b. Comparacin de dichos informes con los cronogramas de tareas
elaborados en la planificacin, auxilindose de herramientas con los
diagramas de GANTT y PERT para determinar desviaciones en los
tiempos, con especial nfasis en la ruta crtica.
c. Supervisin peridica en el campo de trabajo.
d. Evaluaciones del desempeo.
Controles de Procedimientos de Sistemas y Programas: Se pueden disear
los procedimientos para controlar el proceso de revisin de sistemas y
programas, as como los procedimiento de correccin y ajustes de fallas en los
sistemas.
El nivel de documentacin que se genera en el centro de informtica es muy
importante. Incluye diseos tcnico, manuales de operacin y manuales de
usuario. Con demasiada frecuencia, este aspecto importante es ignorado por
53/86
Manual Terico
el personal informtico que suele dar mayor prioridad a labores que implican
un mayor reto.
En resumen, las categoras bsicas de controles para procedimientos de
sistemas y programas, cubren:
a. Mtodos y Procedimientos para el desarrollo de sistemas (o para
cualquier otro tipo de producto que se desarrolle en el centro de
informtica).
b. Procedimientos administrativos en los que estn basados los sistemas y
productos creados en el centro.
c. Procedimientos y estndares generales de programacin.
d. Procedimientos de revisin correccin y modificacin de sistemas.
e. Documentacin bsica (Diseos tcnicos, Organigramas, Diagramas,
Manuales de operacin y Manuales de usuario).
Controles interconstruidos de hardware y software: Los incorporan los
fabricantes de hardware y software para verificar la confiabilidad del equipo
de computacin y su sistema operativo. De ordinario, incluyen verificaciones
de paridad, verificaciones de duplicacin, control de sobreflujo, controles y
alarmas de sistema operativo, mecanismos de auto apagado, controles
predeterminados de acceso a dispositivos, etc.
Controles del Centro de Informtica en s: En este tipo de control pueden
definirse como normas de comportamiento para la gente que labora en el
centro de informtica o que tiene alguna vinculacin con el mismo, de
disposiciones como las siguientes:
a. Como regla, cualquiera que no est involucrado en las operaciones o
programacin de sistemas deber ser escoltado en todo momento al
cuarto donde estn los servidores principales.
b. Se restringe el acceso a la biblioteca de cintas, discos y otros respaldos
al personal del departamento de Administracin del Sistema.
Los mecanismos de control que suelen regir el comportamiento de un
departamento suelen incluir:
a. Horarios de trabajo.
b. Controles de entrada y salida.
c. Formularios para solicitud de permisos o reportes de inasistencias, entro
otros.
Controles de Seguridad: Bsicamente, los controles de seguridad cubren
contingencias no cubiertas adecuadamente por otros controles. Deben estar
estandarizados para todas las operaciones diarias, en caso contrario se
presentarn dificultades operativas y acciones correctivas inconsistentes. Los
centros de informtica suelen contar con controles de seguridad que incluyen:
a. Bitcoras en los sistemas.
b. Mecanismos para prevencin y recuperacin en caso de fallas en el
sistema elctrico.
c. Mecanismos de proteccin contra incendios.
54/86
Manual Terico
d. Mecanismos de proteccin ambiental.
12.3 ESTNDARES EN LOS CENTROS DE INFORMTICA

Un punto de arranque para el control efectivo en un centro de informtica es el
establecimiento de estndares de desempeo adecuados, tanto para el rea de
desarrollo de sistemas, como para las reas de administracin de sistemas,
operaciones y soporte a clientes.
12.3.1
EL PORQU DE LOS ESTNDARES EN LOS CENTROS DE INFORMTICA
La razn de ser de un Centro de Informtica es proporcionar servicios al usuario. El

administrador del centro debe velar porque los servicios se desarrollen en forma
adecuada, se entreguen en un tiempo oportuno y se operen de forma efectiva.
Los estndares definen aspectos clave de los servicios provistos al usuario tales
como:
Qu incluye el servicio?
Cmo se desarrollar el servicio?
Cmo se evaluar el servicio?
Quin proveer el servicio y cmo?
Los estndares sirven como un medio para la comunicacin de las expectativas
de la gerencia y de los usuarios. Las actividades de planeacin, organizacin,
direccin y control de la gerencia reciben un gran apoyo derivado de esta mayor
comunicacin.
Los estndares para el desarrollo de productos informticos pueden ser la
herramienta ms til para medir la productividad del centro de informtica.
A travs de la aplicacin adecuada de estndares adecuados, los recursos
(tiempo del personal, tiempo mquina, etc.) requeridos para desarrollar proyectos
informticos se puede reducir enormemente.
12.3.2
EL VALOR DE LOS ESTNDARES EN UN CENTRO DE INFORMTICA
El valor de los estndares en los centros de informtica resulta obvio cuando se

consideran los siguientes hechos:
En una centro de informtica tpico se dedican entre el 60 y el 75% de los
recursos totales en el mantenimiento y mejora de los sistemas existentes. Una
buena documentacin de sistemas y el cumplimiento de estndares durante
el desarrollo original reducir drsticamente tanto el mantenimiento como las
necesidades requeridas.
En el rea de sistemas, el agregar nuevas aplicaciones a sistemas ya
existentes, incrementa los costos de una manera proporcionalmente mayor
que al inicio del diseo original. Los problemas principales son documentacin
pobre e inflexibilidad de los sistemas.
Los factores anteriores, combinados con el incremento en la demanda de
servicios y productos informticos ocasiona retrasos de meses, y hasta aos, en
el desarrollo de nuevos proyectos. Cada mes que pasa sin la implementacin
de nuevos sistemas redunda en prdida de oportunidades (y quizs
econmicas) para los usuarios potenciales de los sistemas.
55/86
12.3.3
Manual Terico
AREAS TPICAS DE CONTROL DONDE SE APLICAN ESTNDARES
Antes de profundizar en los estndares tpicos de control en los centros de

informtica, es til definir los lineamientos principales para el establecimiento de
estndares en las actividades del desarrollo de sistemas:
1. Estndares distintos son apropiados para diferentes productos
informticos. Los factores que se considerarn en la aplicacin de
estndares deben incluir si el sistema es en lote o interactivo, que tipo
de hardware puede ser usado, la naturaleza del sistema, en caso de
software, la frecuencia de operacin (diaria, semanal, mensual), y el
programa y presupuesto para desarrollo.
2. Los estndares caen generalmente en estas tres categoras:
a. Requerimientos absolutos que deben ser cumplidos
b. Requerimientos negociables que pueden o no ser necesarios, o
c. Prcticas recomendadas que sera til seguir, pero que no son
obligatorias.
3. Los encargados de desarrollar las actividades y proyectos en el centro
de informtica deben estar claros acerca de cuales son los estndares
que se espera que cumplan antes de comenzar su trabajo.
Las cuatro reas especficas de preocupacin para el gerente de informtica , y
que requieren la aplicacin de estndares son:
Planeacin de recursos: La gerencia debe desarrollar programas para
proyectos u operaciones, as como planes de persona, realistas. El uso de
estndares vlidos permite determinar los recursos necesarios para cada
funcin asociada con un proyecto u operacin especficos.
Un centro de informtica tpico tiene un retraso de 12 a 30 meses y est
luchando continuamente por asignar prioridades. La planeacin ms
importante de recursos que la organizacin puede realizar es la de tomar la
decisin correcta acerca de los recursos que deben ser comprometidos y a
qu nivel de esfuerzo.
La efectividad y la respuesta pueden mejorar enormemente mediante el
establecimiento de estndares para la asignacin de prioridades. Por ejemplo:
a. Una organizacin puede adoptar la poltica de que los sistema de
informacin que permita a la organizacin cumplir con un requisito
legal o de gobierno tendrn la prioridad ms alta
b. Que los que darn un beneficio cuantificable como resultado de un
aumento neto en las utilidades o una reduccin en los gastos operativos
tengan prioridad dos, y, obviamente se realizan primero los que
ofrezcan una tasa de retorno proyectada ms elevada
c. Finalmente debe asignarse prioridad tres a los proyectos con beneficios
intangibles. Si los beneficios no compensan los costos no debe realizarse
el proyecto.
Garanta de calidad: Los estndares ayudan a asegurar que un nivel de
calidad especificado por el gerente/usuario sea obtenido en el desarrollo de
productos y servicios desarrollados por el centro de informtica.
56/86
Manual Terico
Las formas adecuadas para asegurar una adecuada garanta de calidad son
dos:
a. Hacer que el equipo de informticos asignados a la tarea y los usuarios
del producto o servicio solicitado definan los criterios para una
terminacin exitosa del proyecto, antes de que se haga el primer
esfuerzo. Los criterios para el xito debern ser documentados y
aprobados por ambos grupos.
b. Establecer puntos de verificacin de calidad durante toda la vida del
proyecto. Los puntos de verificacin deben ser definidos con tal certeza
que cada uno de los participantes sepa con certeza qu es lo que va a
ser evaluado en cada uno de los puntos de verificacin y qu es lo que
constituye una calidad aceptable. Siempre es importante hacer que los
estndares sean lo suficientemente flexibles y que ofrezcan
posibilidades de expansin.
Reduccin de costos: Los estndares proporcionan lineamientos que se
seguirn por terceros para el logro de un objetivo. Ayudan a especificar cmo
se debe llevar a cabo una labor con base en el anlisis cuidadoso de
experiencias anteriores, ayudando de esta forma a otros a evitar formas
menos efectivas y eficientes.
Tres tipos bsicos de estndares pueden ayudar a reducir los costos del
desarrollo de productos informticos:
a. Identificar claramente las tareas que se deben realizar durante cada
una de las fases de ciclo de vida del proyecto. Esto asegurar que se
hagan slo las cosas correctas y que la terminacin de cada fase
representa un trabajo completo y exhaustivo de todo lo que se deba
hacer hasta ese momento.
b. Usar unidades modulares para la construccin de soluciones
informticas. Esto tiene que ver ms que todo con el software. Por
ejemplo: La lgica bsica de un procesamiento para efectuar una
actualizacin de un archivo puede disearse de manera tal que resulte
aplicable a un archivo empleados, a uno de clientes y as
sucesivamente. La idea es tener elementos de soluciones informticas
generalizados, documentados, depurados y almacenados que puedan
reutilizarse fcilmente en futuros productos.
c. Permitir que todo el que desarrolla productos y servicios informticos
tenga acceso, preferiblemente en lnea a todo el material necesario
para realizar su trabajo. Debe contarse con material de referencia de
buena calidad. La clave para un uso efectivo de de los materiales de
referencia est en el conocimiento de la informacin con que se
cuenta y la posibilidad de un acceso rpido a dicha informacin en el
momento adecuado.
Evaluacin de desempeo: Los estndares ayudan a definir una base para
comparar el desempeo individual contra las expectativas del gerente o del
usuario.
El personal informtico debe ser evaluado fundamentalmente en cuanto a
tres factores:
57/86
Manual Terico
a. Son aceptables para los usuarios los productos o servicios diseados?.

Para llegar a una conclusin al respecto los usuarios deben haber
convenido los criterios para considerar satisfactorio el producto o
servicio.
b. Se complet el esfuerzo del desarrollo de los productos o servicios
dentro del presupuesto?.
c. Se complet el esfuerzo del desarrollo de los productos o servicios de
acuerdo al programa?. Se debe definir claramente cuando es la fecha
de terminacin, la cual puede ser: cuando el se termina la construccin
del producto, cuando el usuario est debidamente entrenado para su
uso o cuando el producto comienza a dar frutos satisfactoriamente.
12.3.4
ESTNDARES PARA CONTROLAR LAS OPERACIONES DEL CENTRO DE
INFORMTICA
El centro de informtica es una organizacin de servicio, y como tal debe ser muy
sensible a dos consideraciones clave para cualquier organizacin de este tipo:
Cules son las demandas del usuario del sistema, tanto actuales como a
futuro?
Cmo se pueden satisfacer estas demandas en la forma ms eficiente en
costo y efectiva en relacin a las necesidades?
Si el centro de informtica se ve a s mismo como una organizacin de servicio,
deber contar con un proceso de revisin continua del desempeo para
asegurar el cumplimento de las necesidades de servicio actuales y futuras de
forma eficiente en cuanto a costo y eficiente en cuanto a la satisfaccin de la
necesidad. El proceso de revisin del desempeo deber incluir las siguientes
actividades:
Evaluar que tan efectiva y eficientemente se estn satisfaciendo las
necesidades actuales de servicio. Esta revisin deber abarcar todos los
aspectos de las operaciones: procesamiento y procedimientos de entrada,
asignacin de etapas a las labores, distribucin de las salidas y la relacin con
los usuarios. Lo usuarios y el personal del centro de informtica debern
compartir ideas respecto a reas problemticas y posibilidades para
mejorarlas. Se debe hacer un esfuerzo por identificar necesidades especficas
de servicio que no estn siendo satisfechas.
Medir la utilizacin actual de recursos y determinar la capacidad
excedente actual: Se debern determinar el nmero de turnos, horas por turno
y personal por turno. A qu actividades dedican estas personas su tiempo?
En cuanto al equipo, existe una gran cantidad de dispositivos de monitoreo
para el hardware y software que miden la utilizacin de CPU, memoria
unidades de disco, etc. Muchos centro de informtica cuentan con un grupo
de desempeo que emplea estos monitores para ayudar a obtener el mejor
desempeo con el equipo actual y recomendar actualizaciones de hardware
y software.
Determinar necesidades de servicio a futuro y efectuar la planeacin de
recursos para satisfacer estas necesidades:: Los largos tiempos de entrega,
58/86
Manual Terico
asociados con la obtencin de equipo, el rpido crecimiento de los negocios

y la dificultad de obtener fondos, son algunas de las razones por las que una
planeacin exitosa de recursos requiere pensarse con una anticipacin de tres
a cinco aos. Lo anterior requiere una excelente comunicacin entre usuarios
e informticos para que ambos estn concientes de las aplicaciones que,
posiblemente aparezcan dentro del horizonte de planeacin. Tambin
requiere que se mantenga al corriente en cuanto a nuevo equipo y
tecnologa.
59/86
Manual Terico
13 CONTROL: PROTECCIN DE DATOS, HARDWARE Y SOFTWARE

13.1 INTRODUCCIN A LA PROTECCIN DE LOS DATOS
Los datos son uno de los recursos ms valiosos de las organizaciones, y, aunque
son intangibles, necesitan ser controlados con el mismo cuidado que los dems
inventarios de la organizacin.
Se debe tener presente que la responsabilidad de los datos es compartida
conjuntamente por alguna funcin determinada de la organizacin y la direccin
de informtica.
En todo centro de informtica debe contarse con una serie de polticas que
permitan la mejor operacin de los sistemas.
13.2 POLTICAS Y PROCEDIMIENTOS

Las polticas existentes deben estar actualizadas en todas las actividades, estar
debidamente documentadas y ser del conocimiento del personal.
No contar con polticas y procedimientos actualizados que rijan la administracin
del rea de informtica podra ocasionar:
Administracin inadecuada de la operacin
Relajamiento en el cumplimiento de las obligaciones del personal
Inadecuada revisin de labores
Las polticas y procedimientos deben incluir los siguientes puntos:
Seguridad de la informacin (fsica y lgica)
Adquisicin de hardware y software
Operacin del centro de cmputo
Es recomendable que se documenten todos los procedimientos de las diversas
actividades. Junto con las normas y polticas esos procedimientos forman los
manuales de operacin.
Al proceder de esta manera se obtienen las siguientes ventajas:
Se tiene una base uniforme, estable y formal para capacitacin, consulta y
supervisin y se fomenta la eficiencia del personal en sus funciones.
Ante la rotacin del personal, se evita el desvirtuamiento de las normas y
procedimientos originales creados
Se precisa la responsabilidad individual de los participantes en una
operacin, en caso de errores y omisiones.
13.3 PROTECCIN DE LOS DATOS: POLTICAS DE RESPALDOS

Los respaldos de la informacin deben realizarse mensual, semanal o diariamente
y se deben observar los siguientes puntos:
Contar con polticas formales por escrito para efectuar los respaldos
mensuales, semanales y diarios de informacin.
60/86
Manual Terico
Todos los medios magnticos de respaldo no deben estar

almacenados en un mismo lugar, aunque se tengan los medios
magnticos de operacin en el centro, por lo que si hubiera una
contingencia grave (incendio, inundacin) no se tendra riesgo de
perder parte o la totalidad de informacin, ya que se cuenta con otro
lugar de respaldos.
Debe tenerse acceso restringido al rea en donde se tienen
almacenados los medios magnticos, tanto de operacin como de
respaldo.
Se deben tener almacenadas las cintas por fecha, concepto y
consecutivo, y es conveniente elaborar y actualizar la relacin sobre
las cintas, el contenido de los datos de registro y los responsables de
efectuarlos.
Se debe contar con una poltica que indique los procedimientos a
seguir en cuanto al almacenamiento de las cintas de respaldo en un
lugar diferente de la ubicacin del centro, en donde se pueda tener
acceso las 24 horas del da y donde se designen los responsables de
mantener actualizada la informacin vital de la organizacin.
No contar con estas polticas de respaldo puede provocar que haya riesgo de
prdida de informacin en caso de alguna contingencia y no tener una
disponibilidad inmediata de la informacin de respaldo para recuperar la
informacin y conseguir la continuidad en la organizacin.
Se debe elaborar por escrito una serie de polticas y procedimientos para la
elaboracin de los respaldos, contemplando los pasos a seguir, la informacin
que debe ser respaldada, segn el perodo correspondiente (mensual, semestral
o anual), as como el personal asignado para cada caso.
Tambin se debe especificar la forma de etiquetacin, nomenclatura, pruebas,
rotacin de cintas, los nombres de los responsables de efectuar los respaldos y las
cintas que sern designadas para ser resguardadas fuera de las instalaciones.
Tambin se debe tener una relacin por escrito de la ubicacin y el contenido de
las cintas, que debe ser entregada al responsable de la seguridad del centro, as
como al gerente del rea de informtica.
61/86
Manual Terico
13.4 PROTECCIN DE LOS DATOS: POLTICA DE REVISIN DE BITCORA

Deben existir bitcoras de operacin en las que se registren los procesos
realizados, los resultados de su ejecucin, la concurrencia de errores, los procesos
ejecutados en el equipo y la manera en que concluyeron.
No contar con una poltica de revisin de bitcoras de operacin de los
diferentes procesos puede ocasionar problemas como:
Carecer de bases para el rastreo de errores de procesamiento
Falta de parmetros de evaluacin respecto al funcionamiento del
equipo y del departamento de sistemas
Ausencia de controles en cuanto al registro de seguimiento de
problemas
Falta de parmetros para determinar las causas de una falla
significativa en el sistema y dar seguimiento a su correccin
Dependencia del personal para solucin de errores
Los errores pueden presentarse de forma recurrente y no ser
detectados, lo cual causa prdidas de tiempo en la correccin.
Puede presentarse una prdida de tiempo al no programarse
adecuadamente las funciones, lo que tiene como consecuencia una
confusin en el rea respecto a los procesos que ya se han realizado
y los que se deban realizar.
Es necesario establecer una poltica de revisin de las bitcoras de operacin,
asignando responsables por proceso y funcin, lo que traera como beneficio
detectar y corregir a buen tiempo los errores recurrentes y poder tomar medidas
preventivas para que estos ya no se presenten.
13.5 PROTECCIN
DEL SOFTWARE:
LICENCIAS DE SOFTWARE
POLTICAS
EN LA ADQUISICIN DE
Todas las organizaciones deben tener un inventario de las licencias de software

actualizado, que asegure que toda la paquetera y software en general sea legal
y est amparada por una licencia, para evitar posibles problemas legales por
pago de derechos de uso y explotacin del software.
Al no contar con las licencias correspondientes, no se le puede exigir al proveedor
el servicio de soporte o actualizacin de software, ya que para poder contar con
estos servicios es necesario presentar las licencias de adquisicin o el nmero de
serie instalado dentro de la licencia, el cual se encuentra clasificado en una base
de datos dentro de los equipos del proveedor. Es muy fcil detectar si la licencia
es pirata o ya venci.
Por ello es muy importante:
Actualizar el inventario de hardware y software, sealando los
paquetes que se tienen instalados por mquina y verificando que
cada uno de estos est amparado por una licencia.
62/86
Manual Terico
En caso de no contar con las licencias, es necesario contactar al

proveedor del software o del paquete en cuestin para actualizarlas
o adquirirlas lo ms pronto posible.
Elaborar un plan verificador de software, para revisar que no se instale
paquetera pirata
Designar una persona responsable del rea de informtica para
guardar y tener actualizadas las licencias
Promover un plan de concientizacin entre el personal con el fin de
que no se instale paquetera pirata en las mquinas propiedad de la
empresa, y aplicar sanciones al personal que no acate estas medidas.
13.6 PROTECCIN
CENTRO
DEL
HARDWARE: POLTICAS
DE
SEGURIDAD FSICA
DEL
Deben existir polticas y procedimientos que describan los aspectos de seguridad

mnimos que deben regir dentro del departamento de informtica.
Se deben observar los siguientes puntos:
El acceso al centro debe estar restringido por una puerta, la cual
contar con una chapa adecuada de seguridad, o con un
dispositivo electrnico de control de acceso. Se deben tener
dispositivos adecuados de deteccin de humo, as como
extinguidores para incendios.
Se debe tener proteccin en los servidores para que no puedan ser
desconectados accidental o intencionalmente y provocar as serios
daos al equipo.
Deben existir documentos o carteles que indiquen las normas de
seguridad mnima que deben observarse al estar en el centro.
El personal operativo no debe permitir el acceso a personal ajeno al
departamento.
Los equipos que se utilizan para limpieza dentro del centro no deben
estar directamente conectados a los toma corrientes a los que estn
conectados los equipos de cmputo y los servidores.
Los equipos elctricos, interruptores o de comunicacin no deben
estar al alcance de cualquier persona.
Hay que elaborar polticas formales de seguridad y disear las caractersticas para
el centro, por lo que se recomienda lo siguiente:
Seguridad fsica del centro de cmputo. Disear un lugar exclusivo y
adecuado para los equipos centrales. Implementar dispositivos
adecuados para la prevencin y extincin de incendios que
garanticen la salvaguarda del equipo y la informacin que se
encuentre en el centro.
Acceso al centro de cmputo. El acceso al centro de cmputo debe
estar restringido por llaves electrnicas, chapas magnticas, etc.
Adems es necesario que se implemente algn procedimiento de
control de acceso para personal no autorizado a las instalaciones. Se
63/86
Manual Terico
debe realizar una difusin correcta de las polticas y procedimientos

de seguridad fsica, con el objetivo de que el personal conozca las
responsabilidades y las acciones que les corresponde.
Plan de contingencias. Que permita que los sistemas sigan
funcionando en caso de algn siniestro o en caso de una huelga, o
un imprevisto de cualquier ndole. Un plan de contingencia debe
contener los siguientes controles:
Delegacin de funciones y entrenamiento de personal
Resumen de actividades a seguir en caso de contingencias
Estudio detallado de las contingencias que, de acuerdo a la zona
geogrfica, tienen ms probabilidad de ocurrir y los impactos que
cada una ocasionara.
Realizar un estudio de tiempo estimado de restablecimiento de
operaciones de acuerdo con una determinada contingencia, as
como un estudio de consecuencias potenciales que se
desprenderan por la inoperatividad de los sistemas.
Identificar las aplicaciones y archivos de datos crticos para la
operacin de servicios computacionales, as como, determinar las
prioridades de restablecimiento de estos. Se deben incluir
especificaciones
de
hardware
y
software,
tiempo
de
procesamiento, programa, archivos y documentacin de
programas y operacin.
Proveer los lineamientos necesarios para el restablecimiento de
operaciones a partir de los respaldos de informacin.
Desarrollo de pruebas peridicas del plan de contingencia, as
como
el
establecimiento
de
niveles
de
autoridad
y
responsabilidades para garantizar el buen resultado de la prueba.
Establecer procedimientos y responsabilidades para mantener el
plan de contingencias.
Procedimientos o planes para la reconstruccin de centro despus
de una contingencia.
Establecimiento de procedimientos manuales de operacin por
parte de los usuarios para restablecer operaciones mientras se
recuperan los sistemas.
Lineamientos para garantizar que dicho plan sea aprobado y
actualizado peridicamente.
64/86
Manual Terico
14 ADMINISTRACIN DE PROYECTOS INFORMTICOS

14.1 INTRODUCCIN
Los proyectos son planes especficos de accin dirigidos a la solucin de un
problema especfico y que cuenta con recursos exclusivos y un tiempo
predeterminado. Ms que lograr un objetivo, cumplir una misin o alcanzar una
visin, con el proyecto lo que se busca es un producto especfico. Se coordinan
recursos, se establecen actividades y el tiempo para lograrlas con el fin de crear
algo, un producto.
En el rea de informtica la mayor parte del trabajo se desarrolla en base a
proyectos, ya que, a diferencia de otras reas de servicio de la empresa, los
servicios que presta el centro de informtica son casi siempre diferentes. No son
servicios permanentes o rutinarios, sino nuevas necesidades con caractersticas
distintas cada vez (pinsese en el desarrollo del software, por ejemplo). Por tanto,
cada nuevo requerimiento suele plantearse como un nuevo proyecto a
desarrollar.
Sumado a esto hay que decir que la gerencia y los usuarios exigen que los
proyectos informtico se desarrollen con rapidez, y en la medida de lo posible
esto debe cumplirse y para ello existen tres maneras de afrontar un proyecto
informtico:
Mejorando la velocidad de desarrollo del proyecto. Ventaja: Permite la
entrega rpida del producto solicitado. Desventaja: Se corre un mayor riesgo
Reduciendo el riesgo en base a una planificacin ms detallada. Ventaja:
Se evitan retrasos por imprevistos. Desventaja: Se avanza ms lento.
Haciendo visible el progreso. Ventaja: Permite disipar la impresin de que
se est trabajando lento. Desventaja: Realmente se est trabajando ms
lento.
En las siguientes pginas se ampliar ms sobre la mejor manera de emprender
proyectos informticos, definiendo estrategias y consideraciones a tener para su
mejor desarrollo.
14.2 ESTRATEGIA BSICA

INFORMTICOS
PARA
EL
DESARROLLO
DE
PROYECTOS
Si tomsemos 100 msicos de gran calidad y prestigio y los pusiramos en una

orquesta sin director no sonaran como una orquesta de calidad. Indicar a esos
msicos que hagan lo mejor que puedan no les ayudara a saber si deben ir
ms rpido o ms lento.
En el desarrollo de proyectos informticos suele darse un desperdicio similar de
talento. Equipos de desarrolladores inteligentes y dedicados utilizan las tcnicas
mejores y ms recientes y siguen sin poder alcanzar sus objetivos.
Para lograr un desarrollo exitoso de proyectos informticos debe plantearse una
estrategia basada en cuatro elementos:
e. Evitar los errores clsicos
f. Aplicar las bases del desarrollo
65/86
Manual Terico
g. Gestionar los riesgos para evitar un retorno catastrfico

h. Basarse en la planificacin.
La consideracin de estos cuatro elementos constituye la estrategia bsica para
el desarrollo exitoso de un proyecto informtico.
14.3 LAS CUATRO DIMENSIONES DE UN PROYECTO INFORMTICO

Un proyecto informtico se desarrolla a travs de cuatro dimensiones principales:
Personas, Proceso, Producto y Tecnologa.
Las organizaciones ms efectivas en el desarrollo de proyectos informticos
optimizan simultneamente las cuatro dimensiones.
14.3.1
PERSONAS
O podramos decir peopleware. La tecnologa no es la respuesta. Los proyectos

ms exitosos son los que sacan provecho del potencial humano de los
informticos. Cualquier organizacin que trate seriamente de mejorar la
productividad debe ocuparse primero de temas relacionados con el personal,
como la motivacin, el equipo de trabajo, seleccin del personal y formacin.
Seleccin de personal para equipos de proyectos informticos: Los cinco
principios para la seleccin de personal son:
i. Mximo talento. Usar poco, pero buen personal.
j. Trabajo adecuado. Asignar tareas segn la habilidad y motivacin de
la gente disponible.
k. Progresin profesional. Ayudar a la gente a actualizarse por si misma en
vez de obligarles a trabajar donde ms experiencia tienen o donde son
ms necesarios.
Equilibrado del equipo. Seleccionar a gente que se complemente y
armonice con los dems.
m. Eliminar la inadaptacin. Eliminar y reemplazar a los miembros
problemticos lo antes posible.
Organizacin del equipo: Los administradores de centros de informtica
sacan provecho de la estructura de sus equipos para que concuerden con el
tamao del proyecto, las caractersticas del producto y los objetivos de
planificacin.
Motivacin: Una persona que carece de motivacin no va a querer
trabajar duro y prefiere dejarse llevar. La motivacin es potencialmente el
aliado ms fuerte para el desarrollo exitoso de un proyecto informtico.
l.
14.3.2
PROCESO
Centrarse en el proceso, procurando hacerlo cada vez ms eficiente puede ser

de gran utilidad para el desarrollo de un proyecto. La clave est en optimizarlos y
hacerlos ms giles, ya que en muchos casos se cae en el error de convertir los
procesos en algo agobiante, rgido y burocrtico.
Para lograr procesos tiles y eficientes se necesita:
a. Evitar la repeticin de trabajo. Si en las ltimas etapas del proyecto hay
un cambio en los requerimientos, es necesario redisear, recodificar y
66/86
b.
c.
d.
e.
f.
g.
14.3.3
Manual Terico
volver a hacer las pruebas. Si ha habido problemas en el diseo que no

se descubren hasta la prueba, se debe volver al diseo detallado y la
codificacin y comenzar de nuevo. Una de las mejores formas de
ahorrar tiempo en los proyectos informticos es orientar el proceso de
forma que se evite hacer la misma cosa dos veces.
Control de calidad. Tiene dos objetivos principales. El primero es
asegurarse de que el producto tiene un nivel de calidad aceptable. El
segundo objetivo es detectar los errores del proceso en el momento en
que haya que emplear menos tiempo (y menos diseo) para
corregirlos.
Bases del desarrollo. Hay que definir estndares. A pesar de que los
mtodos estndares en rea de la informtica como la ingeniera de
software, entre otras, para el anlisis, diseo, construccin, integracin y
pruebas no van a hacer andar el plan por si solas, pueden evitar que los
proyectos se queden fuera de control. La mitad del desafo en el
desarrollo de proyectos informticos consiste en evitar el desastre y esta
es un rea en la que sobresale la aplicacin de estndares.
Gestin de riesgos. Es una de las tcnicas especficas que se centran en
evitar el desastre.
Atencin a los recursos. El objetivo es asegurarse de que cada da se
hace todo el trabajo posible.
Planificacin del ciclo de vida. De manera tal que se sepa desde y
hasta cuando se utilizarn los recursos en el proyecto.
Orientacin al cliente. Los informticos han aprendido que desarrollar
proyectos a partir de la especificacin solo es la mitad del trabajo. La
otra mitad es ayudar al cliente a definir el producto que desea.
Mtodos como la entrega por etapas, entrega evolutiva, prototipado
evolutivo, prototipado deshechable y negociacin conveniente
aportan ventajas en esta rea.
PRODUCTO
La dimensin ms tangible del cuarteto es la dimensin producto, y ocuparse del

tamao y caractersticas del producto plantea enormes oportunidades de reducir
la planificacin. Al reducir el conjunto de prestaciones del producto se reduce el
plan.
El total en la reduccin sobre el plan que se obtiene al ajustar en el tamao y las
caractersticas del producto slo se ve limitado por el concepto de producto que
tiene el cliente y la creatividad de equipo.
Las siguientes caractersticas del producto determinan la rapidez y eficiencia con
que el mismo ser desarrollado:
Tamao de producto. Puesto que el esfuerzo para construir el producto se
incrementa exponencialmente ms rpido que el tamao del producto en s,
la reduccin del tamao mejorar la velocidad del desarrollo en la misma
proporcin.
Caractersticas del producto. Tales como: Rendimiento, uso de memoria,
robustez y fiabilidad.
67/86
14.3.4
Manual Terico
TECNOLOGA
Una forma rpida de desarrollar proyectos eficaces y eficientes es pasar de usar

herramientas menos efectivas a otras ms efectivas. En la historia del desarrollo de
software, por ejemplo, uno de los cambios de mayor influencia fue el paso de
lenguajes de bajo nivel a lenguajes de alto nivel.
14.3.5
SINERGIA
Hay un momento en que ocuparse de la gente, el proceso, el producto y la

tecnologa se convierte en un todo. Lo que debe buscarse es que los resultados
alcanzables combinando estos cuatro elementos sean mayores a la suma de los
mismos.
14.4 BUSCANDO UN DESARROLLO EFICIENTE DE PROYECTOS INFORMTICOS

Hay diversos enfoques acerca de cmo debe emprenderse un proyecto
informtico. He aqu una comparacin de ellos:
EFECTO DEL ENFOQUE DE DESARROLLO EN EL..
Enfoque de Desarrollo
...Plan
Mtodo Normal
Medio
...Costo
...Producto
Medio
Medio
Desarrollo Eficiente (equilibrio de Mejor que la Mejor que la Mejor que la

costo, plan y funcionalidad)
media
media
media
Desarrollo eficiente (orientado al Mucho
Algo mejor Algo
mejor
mejor plan)
mejor que la que
la que la media
media
media
Desarrollo rpido a fondo
El ms corto Peor que la Peor que la

posible
media
media
De ms est decir que el mejor enfoque es el segundo, ya que con el se logra un

equilibrio, mejorando en las tres categoras (Plan, costo y producto). Mucha gente
alcanza sus objetivos de planificacin solamente evitando los errores clsicos,
sentando las bases para el desarrollo y gestionando los riesgos. Descubren que
despus de todo no necesitaban un proyecto rpido, solo necesitaban
organizarse!.
Esa es la clave.
14.5 ERRORES
CLSICOS
INFORMTICOS
EN
LA
ADMINISTRACIN
DE
PROYECTOS
Algunas tcnicas de desarrollo de proyectos informticos han sido elegidas con

tanta frecuencia, por tanta gente, con resultados tan malos y predecibles que
son dignas de ser llamada errores clsicos. Muchos de los errores tienen una
apariencia seductora. Necesitamos salvar un proyecto retrasado? metamos
ms gente! tenemos que reducir el plan? Planifiquemos de forma ms agresiva!
algunos de los miembros clave incomodan al resto del equipo? Esperemos a
que se acabe el proyecto para despedirlo! hay que acelerar el proyecto para
68/86
Manual Terico
acabar? Tomemos cuantos informticos hayan disponibles y que comiencen lo

antes posible!
Los informticos, directivos y clientes normalmente tienen buenas razones para
tomar las decisiones que toman, y la apariencia seductora de los errores clsicos
es una de las razones de que esos errores se cometan tan a menudo. Pero debido
a que se han cometido muchas veces sus consecuencias se han hecho fciles de
predecir.
Para facilitar su estudio se ha dividido la lista empleando las dimensiones de un
proyecto informtico: personas, proceso, producto y tecnologa.
14.5.1
PERSONAS
A continuacin aparecen algunos errores clsicos relacionados con las personas:

n. Motivacin dbil. Muchas veces los directivos toman decisiones que
minan la moral como ser: dar nimos a diario al principio, para pedir
horas extras a la mitad, o irse de vacaciones cuando el equipo est
incluso trabajando horas extras, dar recompensas de poco valor, etc.
o. Personal mediocre. Despus de la motivacin, la capacidad individual
de los miembros del equipo y sus relaciones como equipo tienen la
mayor influencia en la productividad. Muchas veces los directivos
contratan al personal que est disponible ms pronto (y a menor costo)
en lugar de basarse en un perfil de capacidad en consonancia con las
necesidades del proyecto.
p. Empleados problemticos incontrolados. Un fallo al tomar una decisin
acerca del empleado problemtico es una de las quejas ms comunes
del los miembros del equipo con respecto a sus superiores. Una
manzana podrida puede estropear el proyecto completo.
q. Hazaas. Algunos informticos ponen un gran nfasis en la realizacin
de hazaas en los proyectos. Pero lo que hacen tiene ms de malo que
de bueno. Es mejor tener progresos firmes y consistentes, que desarrollar
proyectos en tiempo y esfuerzo record, los cuales, si bien son
meritorios, corren un riesgo extremo.
r. Aadir ms personal a un proyecto retrasado. Este es quizs el ms
clsico de los errores clsicos. Cuando un proyecto se alarga, aadir
ms gente puede quitar ms productividad a los miembros del equipo
de la que aaden los nuevos miembros
s. Oficinas repletas y ruidosas. La mayora de los informticos consideran
sus condiciones de trabajo como insatisfactorias. Cerca del 60% de
ellos considera que no tienen suficiente silencio ni privacidad.
t. Fricciones entre los usuarios y los informticos. A los clientes puede
parecerles que los informticos no cooperan cuando rehsan
comprometerse con el plan propuesto por los clientes o cuando fallan
al entregar lo prometido. Por su parte a los informticos puede
parecerles que los clientes no son razonables cuando insisten en planes
irreales o cambios en los requerimientos despus de que estos han sido
fijados. El principal efecto de estas fricciones es la mala comunicacin,
y los efectos secundarios de la mala comunicacin incluyen el pobre
69/86
u.
v.
w.
x.
y.
14.5.2
Manual Terico
entendimiento de los requerimientos, el pobre diseo de la interfaz de

usuario y, en el peor de los casos, el rechazo del cliente hacia el
producto. Adems, remediar estas fricciones consume tiempo y distraen
tanto a desarrolladores como a clientes, del trabajo real en el proyecto.
Expectativas poco realistas. El gerente de proyectos informticos debe
tener el valor y la firmeza de corregir una expectativa irrealista del
cliente. Este problema tiene variantes, ya que en algunos casos son los
directivos del proyecto quienes se buscan problemas al pedir recursos y
proponer plazos basndose en estimaciones demasiado optimistas.
Falta de un promotor efectivo del proyecto. Para soportar muchos de los
aspectos del desarrollo exitoso de proyectos informticos es necesario
un promotor de alto nivel, particularmente para: hacer una
planificacin realista, llevar el control de cambios e introducir nuevos
mtodos de desarrollo. Sin un promotor ejecutivo efectivo el resto de
personal de alto nivel de la institucin puede forzar a que se acepten
plazos irreales o hacer cambios que debiliten el proyecto.
Falta de participacin de los implicados. Las personas que deben
participar en el proyecto incluyen: promotores, ejecutivos, responsables
del equipo, miembros del equipo, personal de ventas, usuarios finales,
clientes, y cualquiera que juegue algn papel en el proyecto.
Falta de participacin del usuario. Los proyectos que no implican al
usuario desde el principio corren el riesgo de ser imprecisos en cuanto a
requerimientos y vulnerables a que se consuma tiempo en prestaciones
descubiertas demasiado tarde.
Ilusiones. Las ilusiones no son solo optimismo. Realmente consisten en
cerrar los ojos y esperar que todo funciones cuando no se tienen bases
razonables para pensar que ser as. Las ilusiones al principio del
proyecto llevan a grandes explosiones al final.
PROCESO
Los errores relacionados con el proceso retrasan los proyectos, malgastando el

esfuerzo y talento del personal. A continuacin se enumeran algunos de los
peores errores relacionados con el proceso:
a. Planificacin excesivamente optimista. Fijar un plan excesivamente
optimista predispone a que el proyecto falle por infravalorar el alcance
del proyecto, afectando la planificacin efectiva, y reduciendo las
actividades crticas para el desarrollo, como el anlisis de
requerimientos o el diseo. Tambin supone una excesiva presin para
los desarrolladores, quienes a largo plazo se ven afectados en su moral
y su productividad.
b. Gestin de riesgos insuficiente. Hay que dejar tiempo y recursos de
reservas para afrontar los imprevistos. Con solo que vaya mal una cosa
se retrasar el proyecto.
c. Fallos de los contratados. Las compaas contratan a veces la
realizacin de partes de un proyecto cuando tienen demasiada prisa
hacer el trabajo en casa. Pero los contratados frecuentemente
70/86
d.
e.
f.
g.
h.
i.
j.
k.
l.
Manual Terico
entregan su trabajo tarde, con una calidad inaceptable o que falla al

no coincidir con la especificacin. Riesgos como requerimientos mal
definidos pueden ser enormes cuando se contrata a alguien externo, y
esto puede ocasionar retrasos en el proyecto en lugar de acelerarlo.
Planificacin insuficiente. Si no se planifica para tener un proyecto
exitoso, no se puede esperar que el mismo se de.
Abandono de las planificacin bajo presin. Es comn en el rea de
informtica el hacer planes y abandonarlos en cuanto se presenta un
problema. A partir de ese punto el trabajo no tiene coordinacin ni
elegancia. Se falla en no crear un plan alternativo o no tener un plan
de contingencias.
Prdida de tiempo en el inicio difuso. Es mucho ms fcil, barato y
menos arriesgado suprimir unas pocas semanas o meses del inicio difuso
en vez de comprimir el plan de desarrollo en ese mismo tiempo.
Escatimar en las actividades iniciales. Los proyectos que se aceleran
intentando acortar las actividades no esenciales suelen terminar mal.
Por ejemplo, en un proyecto de desarrollo de software es comn
acortar actividades como el anlisis de requerimientos, la arquitectura y
el diseo, dado que estos no producen cdigo. Es comn que cuando
se pregunta por el diseo en un proyecto desastroso el responsable
diga No hemos tenido tiempo de hacer el diseo.
Diseo inadecuado. Un caso especial de escatimar en las actividades
iniciales es diseo inadecuado. Proyectos acelerados generan un
diseo indeterminado, dominado por las conveniencias ms que por la
calidad requerida.
Escatimar en el control de la calidad. En los proyectos que se hacen
con prisa suele cortarse por lo sano, eliminando las revisiones, la
planificacin de pruebas y realizando solo actividades superficiales. Esto
es contraproducente. A la larga, acortar en un da las actividades de
control de calidad al comienzo del proyecto probablemente supondr
de 3 a 10 das de actividades finales.
Control insuficiente de la directiva. Sobre todo cuando hay poco
control para detectar a tiempo los signos de posibles retrasos en el plan,
ya sea porque no se definieron al principio o porque se abandonaron
en el camino.
Convergencia prematura o excesivamente frecuente. Bastante antes
de la fecha en que se haya programado entregar un producto, hay un
impulso para preparar el producto para la entrega, mejorar el
rendimiento del producto, imprimir la documentacin final, registrar las
ayudas, etc. En proyectos hechos con prisa hay una tendencia a forzar
prematuramente la convergencia. Estos intentos son prdida de tiempo
y prolongan el plan.
Omitir tareas necesarias en la estimacin. El esfuerzo omitido suele
aumentar el plan de desarrollo en un 20 o 30 %.
71/86
Manual Terico
m. Planificar ponerse al da ms adelante. Si se ha trabajado 3 meses en un

proyecto y se ha logrado nicamente lo correspondiente a 2 meses
Qu hacer? En muchos proyectos se plantea recuperar el retraso ms
tarde, pero nunca se hace. En realidad se aprende ms sobre el
producto conforme se est construyendo, incluyendo ms sobre lo que
llevar su construccin. Estos conocimientos necesitan reflejarse en una
reestimacin del plan.
n. Desarrollo a destajo. Algunas organizaciones piensan que el desarrollo
de actividades libre, tal como salga, al mejor criterio de cada
informtico es el camino para el desarrollo de proyectos informticos.
Grave error.
14.5.3
PRODUCTO
Estos son los errores clsicos relacionados con la forma en que se define un
producto:
a. Exceso de requerimientos. Algunos proyectos tienen ms requerimientos
de los que realmente necesitan, desde el mismo inicio. Hay que
identificar las prestaciones complejas, ya que por regla general estas
suelen ser las de menos inters para el usuario, y las que requieren ms
trabajo para el informtico.
b. Cambio de las prestaciones. Incluso si se han evitado los requerimientos
excesivos, los proyectos sufren un promedio del 255 de cambios en los
requerimientos a lo largo de su vida. Y esto puede ser grave si se trabaja
con plazos y recursos ajustados.
c. Informticos meticulosos. Los informticos encuentran fascinante la
nueva tecnologa, y a veces estn ansiosos por probar nuevas
prestaciones de sus herramientas, las necesite o no el producto
solicitado. El esfuerzo requerido para disear, implementar, probar,
documentar, o mantener estas prestaciones innecesarias alarga el plan.
d. Estira y encoge en la negociacin. Suele suceder que un directivo
apruebe el retraso de un plan de un proyecto porque se haya dado
cuenta de que el plan estaba errado, pero que despus aada nuevas
tareas al mismo plan. Esto, obviamente, solo puede ir en detrimento del
plan.
e. Desarrollo orientado a la investigacin. Caso particular del desarrollo de
software. Si el proyecto fuerza los lmites de la informtica porque
necesita la creacin de nuevos algoritmos o nuevas tcnicas de
computacin,
no
estamos
desarrollando
software,
estamos
investigando en software. Los planes de desarrollo de software deben
ser razonablemente predecibles.
14.5.4
TECNOLOGA
El resto de los errores clsicos estn relacionados con el uso correcto o incorrecto
de la tecnologa:
a. Sndrome de la panacea. Cuando el equipo del proyecto se aferra solo
a una nueva tcnica, tecnologa o proceso rgido, y espera resolver con
ello sus problemas, est inevitablemente equivocado.
72/86
Manual Terico
b. Sobreestimacin de las ventajas del empleo de nuevas herramientas.

Los beneficios de las nuevas tcnicas son parcialmente desplazados por
las curvas de aprendizaje que llevan asociadas y aprender a utilizar
nuevas tcnicas para aprovecharlas al mximo lleva tiempo. Las
nuevas tcnicas, adems, suponen nuevos riesgos que solo se
descubren con su uso. Un caso especial de sobreestimaciones de las
mejoras se produce cuando se reutilizan cdigo o materiales de
proyectos anteriores. Este tipo de reutilizacin suele ser efectiva pero no
se gana tanto tiempo como se espera.
c. Cambiar de herramientas a mitad de proyecto. Es un viejo recurso que
funciona raramente. Puede tener sentido actualizar incrementalmente,
dentro de una misma lnea de productos (versin 1.0 a versin 2.0). Pero
a medio camino, la curva de aprendizaje, rehacer el trabajo y los
inevitables errores, anulan cualquier posible beneficio.
d. Falta de control automtico del cdigo fuente. De nuevo hablando de
software. Sin l, si dos desarrolladores estn trabajando en la misma
parte del programa, deben coordinar su trabajo manualmente. Pero
invariablemente, alguno sobrescribir el trabajo del otro.
73/86
Manual Terico
14.6 BASES DEL DESARROLLO DE PROYECTOS INFORMTICOS

Los fundamentos tienen al menos tanta influencia como los tcnicos en la
planificacin de desarrollos.
La gestin normalmente controla las tres magnitudes del tringulo de equilibrio
clsico (planificacin, costo y producto).
Los fundamentos de gestin consisten en determinar el tamao del producto
(incluyendo funcionalidad, complejidad y otras caractersticas del producto),
asignando los recursos apropiados a un producto de ese tamao, creando un
plan para aplicar esos recursos y luego controlando y dirigiendo esos recursos
para impedir que el proyecto se desve.
14.6.1
BASES DE GESTIN
14.6.1.1
Estimacin y planificacin
Los proyectos bien ejecutados pasan por tres etapas bsicas para crear una
planificacin. Primero se estima el tamao del proyecto, luego se estima el
esfuerzo necesario para construir un producto con ese tamao y por ltimo se
realiza una planificacin, basndose en la estimacin de esfuerzo.
La planificacin y estimacin son las bases de desarrollo porque una estimacin
incorrecta reduce la eficiencia en el desarrollo. Una estimacin correcta es una
condicin necesaria para la planificacin efectiva, que adems es esencial para
un desarrollo eficiente.
La planificacin de un proyecto informtico incluye las actividades siguientes:
Estimacin y planificacin
Determinar el nmero de personas que deben participar en el equipo del
proyecto, que habilidades tcnicas son necesarias, cuando aumentar el
nmero de personas y quien participar.
Decidir como organizar el equipo
Elegir el modelo de ciclo de vida que se va a utilizar (proyecto de software)
Gestin de riesgos
Tomar decisiones estratgicas, tales como controlar el conjunto de
prestaciones del producto y decidir si hay que comprar o crear algunas
partes del producto.
14.6.1.2
Seguimiento
Una vez que se haya planificado el proyecto hay que seguir el proceso de
desarrollo para comprobar que se est cumpliendo el plan previsto: que satisface
sus objetivos de planificacin, coste y calidad.
Normalmente el control de seguimiento en el nivel de gestin incluye: listas de
tareas, reuniones e informes sobre el estado, revisiones de hitos, informes de
presupuestos y dems gestiones. El control de seguimiento en el nivel tcnico
normalmente incluye las intervenciones y revisiones tcnicas y las entradas de
calidad que controlan si los hitos se consideran terminados.
74/86
Manual Terico
El seguimiento es fundamental. Si no existe no se puede saber si el pan se est

llevando a cabo ni lo que se debera hacer despus. Tampoco habra forma de
controlar los riesgos.
14.6.1.3
Medidas
Una de las formas de progresar en centro de informtica, a largo plazo es recoger

datos mtricos para analizar la calidad y productividad de los productos y
servicios creados.
Prcticamente todos los proyectos recogen datos sobre los costos y la
planificacin. Pero estos datos son limitados y no ayudan mucho a reducir los
costes o a disminuir la planificacin.
Recoger ms datos puede suponer mucho ms tiempo. Si adems de datos de
costo y planificacin se obtienen datos histricos como el tamao de los
programas en lneas de cdigo, o en cualquier otra medida, se tendrn las bases
para la planificacin de proyectos futuros, que siempre es mejor que el instinto.
Cuando el jefe diga: Pueden desarrollar este producto en 9 meses?, podremos
decir: Nunca organizacin nunca ha desarrollado un producto de ese tamao
en menos de 11 meses y el tiempo medio para tal producto es de 13 meses.
Para realizar el desarrollo de forma eficiente se necesita tener conocimientos
bsicos sobre las medidas o mtricas del software.
14.6.2
BASES TCNICAS
14.6.2.1
Gestin de requerimientos
Es el proceso que consiste en reunir requerimientos; plasmarlos en un documento,

correo electrnico, cuaderno de interfaz de usuario, prototipo ejecutable o
cualquier otro formato; hacer un seguimiento del diseo y del servicio informtico
a producir; y gestionar los cambios para el resto del proyecto.
Es muy comn que los desarrolladores se lamenten de los problemas asociados a
los mtodos de gestin de requerimientos tradicionales, siendo la mayora de ellos
demasiado rgidos.
Algunos mtodos pueden ser demasiado rgidos, pero la alternativa que ofrecen
suele ser peor. Un estudio realizado en ms de 8,000 proyectos encontr que las
tres razones principales por la que los proyectos eran entregados tarde, por
encima del presupuesto y con menos funcionalidad de la que se esperaba se
deban a fallas en la gestin de requerimientos: falta de informacin del usuario,
requerimientos incompletos y cambios en los requerimientos.
El xito de la gestin de requerimientos depende del conocimiento de suficientes
mtodos diferentes, de forma que es posible escoger los ms apropiados para un
proyecto especfico.
En el caso de un proyecto de desarrollo de software. Las bases de la gestin de
requerimientos son:
Metodologas de anlisis de requerimientos, incluyendo anlisis
estructurado, anlisis estructurado de datos y anlisis orientado a objetos.
75/86
Manual Terico
Mtodos para crear el modelo del sistema, como diagramas de clases,

diagramas de flujos de datos, diagramas entidad-relacin, notacin del
diccionario de datos y diagramas de estado-transicin.
Mtodos de comunicacin, como el Desarrollo Conjunto de Aplicaciones
(JAD), prototipazo de la interfaz del usuario y mtodos generales de
entrevistas.
Las relaciones entre la gestin de requerimientos y los diferentes modelos
del ciclo de vida, incluyendo prototipazo evolutivo, entrega por etapas,
espiral, cascada y codificar y corregir.
La gestin de requerimientos proporciona de dos formas diferentes una gran
influencia en la velocidad de desarrollo de un servicio informtico:
a) En primer lugar, la recogida de requerimientos es un paso que tiende a
hacerse sin prisas, comparado con otras actividades del desarrollo del
servicio. Si este paso se acelera, sin perjudicar la calidad, se puede
disminuir en conjunto el tiempo de desarrollo.
b) En segundo lugar, obtener un requerimiento como es debido en el primer
paso normalmente cuesta de 50 a 200 veces menos que si se espera a las
fases de construccin o mantenimiento.
14.6.2.2
Diseo
Del mismo modo que tiene sentido crear una serie de bocetos antes de construir
una casa, tiene sentido crear una arquitectura y un diseo antes de construir un
servicio informtico. Un error de diseo que no se detecta hasta la fase de
comprobacin, necesita 10 veces ms tiempo para arreglarlo que si se detectara
en la fase de diseo.
Los temas bsicos cuando se habla de arquitectura y diseo son:
Principales estilos de diseo (como diseo orientado aobjetos, diseo
estructurado, diseo orientado a la estructura de datos).
Conceptos fundamentales del diseo (como ocultamiento de informacin,
modularidad, abstraccin, encapsulacin, cohesin, asociacin, jerarqua,
herencia, polimorfismo, algoritmos bsicos y estructuras de datos bsicas).
Enfoques de diseo estndar en reas generalmente duras (incluyendo
manejo de excepciones, internacionalizacin y localizacin, portabilidad,
almacenamiento de cadenas, entrada/salida, gestin de memoria,
almacenamiento de datos, diseo de bases de datos, rendimiento y
reutilizacin).
Consideraciones de diseo propias del servicio informtico que se est
produciendo (aplicaciones financieras, aplicaciones cientficas, sistemas en
tiempo real, software de seguridasd crtica, entre otros).
Esquemas de arquitectura (como organizacin de subsistemas, niveles,
estilos de comunicacin de subsistemas, etc.)
Uso de herramientas para diseo.
Es posible contruir un servicio informtico sin disearlo primero. Sin embargo, el
diseo es la base de la construccin, planificacin, seguimiento y control del
proyecto, y ese diseo efectivo es imprescindible para conseguir la velocidad
mxima de desarrollo.
76/86
14.6.2.3
Manual Terico
Construccin
En el momento en que se llega la construccin ya se ha llevado a cabo la mayor

parte del trabajo para el xito o fracaso del proyecto. Tanto la gestin de
requerimientos como el diseo ofrecen una mayor influencia en el desarrollo de
un servicio informtico que la construccin. En estas actividades los cambios
pequeos pueden marcar una gran diferencia en la planificacin.
La construccin no ofrece muchas posibilidades de reduccin, pero el trabajo de
construccin es tan detallado y laborioso que es importante hacerlo bien. Si en un
principio la calidad del servicio no es ptima es casi imposible volver hacia atrs y
mejorarla. No es efectivo hacerlo dos veces.
Aunque la construccin es una actividad de bajo nivel, se presenta la posibilidad
de perder el tiempo en cosas poco eficientes o de despistarse en tareas que,
aunque no son crticas, consumen tiempo. Por ejemplo, se puede perder tiempo
en depurar cdigo intil, o ejecutar con esmero pequeas secciones del sistema
antes de saber si es necesario afinarlas.
Los malos mtodos de construccin pueden introducir errores sutiles que pueden
requerir das o incluso semanas para encontrarlos y corregirlos. A veces se puede
perder tanto tiempo en encontrar un error de un programa como en tener que
volver a disear o implementar un mdulo mal diseado.
Las bases de la construccin incluyen los temas siguientes:

Mtodos de codificacin (incluyen las variables y funciones, presentacin y

la denominacin de documentacin).
Conceptos relativos a los datos (incluyendo el mbito, persistencia y
momento de asignacin).
Directrices para utilizar tipos de datos especficos (incluyendo los nmeros
en general, enteros, punto flotante, caracteres, cadenas de caracteres,
volanos, constantes, vectores y punteros).
Conceptos relativos al control (incluyendo la organizacin lineal del
cdigo, uso de condicionales, control de bucles, utilizacin de expresiones
booleanas, control de la complejidad y utilizacin de estructuras de control
poco usuales, como goto, return y procedimientos recursivos).
Aserciones y otros mtodos de deteccin de errores, centrados en el
cdigo.
Reglas para compactar cdigo dentro de rutinas, mdulos, clases y
archivos.
Mtodos de depueracin y comprobacin de unidades.
Estrategias de integracin (como la integracin incremental y desarrollo
evolutivo).
Estrategias y mtodos para afinamiento del cdigo.
Las ventajas, inconvenientes y detalles del lenguaje de programacin que
se est utilizando.
Uso de herramientas de construccin (incluyendo entornos de
programacin, soporte para grupos de trabajo, como correo electrnico y
el control del cdigo fuente, bibliotecas de cdigo y generadores de
cdigo).
77/86
Manual Terico
Algunas de las bases anteriores requieren tiempo, aunque en la vida del proyecto
en general ahorran tiempo. Es mejor ir ms despacio pero ser ms cuidadoso, ya
que hay bastantes servicios informticos que tienen demasiados fallos y tienen
que volver a hacerse.
Las buenas construcciones previenen la creacin de nidos de ratas de cdigo
indescifrable, que hacen que el proyecto se pare lenta y ruidosamente cuando
una persona se enferma, cuando se descubre un fallo crtico o, simplemente,
cuando se necesita hacer algn cambio.
De esta manera se mejoran las previsiones y el control que se tiene sobre el
proyecto y se incrementa la probabilidad de entregarlo a tiempo.
14.6.3
BASES DEL CONTROL DE CALIDAD
Al igual que las bases de gestin y tcnicas, las bases de control de calidad
proporcionan un apoyo fundamental para obtener la mxima eficiencia y
eficacia en el desarrollo de un servicio informtico. Cuando un producto
informtico tiene demasiados errores, los desarrolladores emplean ms tiempo
corrigindolo que construyndolo. La clave principal para no cometer errores es
prestar atencin a las bases de control de calidad desde el primer da.
Algunos proyectos intentan ahorrar tiempo reduciendo el tiempo que se emplea
en el diseo y las revisiones peridicas. Otros (que van retrasados) intentan
recuperar el tiempo perdido reduciendo las pruebas, lo cual es bastante sensible
para la reduccin porque normalmente es el camino crtico al final del proyecto.
Estas son algunas de las peores decisiones que una persona que desea realizar en
forma eficiente y eficaz un producto informtico puede tomar, porque al
aumentar la calidad (desde el punto de vista de menor tasa de defectos) se
reduce el tiempo de desarrollo.
Pocas son las organizaciones que tienen una tasa de defectos extremadamente
baja.
Los proyectos que se realizan con prisas son particularmente vulnerables a
engaos en cuanto al nivel de calidad del que lo desarrolla. Cuando se tienen
prisas se hacen recortes porque solo faltan 30 das para la entrega. En vez de
escribir un mdulo de impresin completamente distinto, se hace a partir del
mdulo de visualizacin en pantalla. Se sabe que el diseo es malo, que no es
ampliable o de mantenimiento fcil, pero no hay tiempo de hacerlo bien. Se
tienen prisas por terminar el producto, de forma que uno se siente obligado a
tomar el camino ms corto.
Tres meses ms tarde el producto an no se ha terminado, y empiezan a
aparecer los problemas derivados de esos recortes. Se encuentra con que los
usuarios no estn contentos con la forma de imprimir, y que la nica manera de
satisfacer sus requerimientos es aumentando significativamente la funcionabilidad
del mdulo de impresin. Desafortunadamente, hace tres meses el mdulo de
impresin y el de visualizacin en pantalla se han ido entrelazando. Redisear el
mdulo de impresin y separarlo del de visualizacin es una operacin difcil, que
consume tiempo y es susceptible a errores.
78/86
Manual Terico
El resultado es que en un proyecto que se supona que prestaba especial

atencin al desarrollo de una planificacin lo ms corta posible, se pierde el
tiempo en las actividades siguientes:
Disear e implementar el mdulo de impresin ya que la mayora del
cdigo se deshechar. El tiempo que se emple en la prueba y
depuracin del mdulo de impresin tambin se desperdici.
El tiempo adicional que se debe emplear para separar el mdulo de
impresin del mdulo de visualizacin por pantalla.
Se debe emplear tiempo de prueba y depuracin adicional en asegurar
que el cdigo de visualizacin que se ha modificado sigue funcionando
despus de separarlo del mdulo de impresin.
El nuevo mdulo de impresin, que debera haberse diseado como una
parte integral del sistema, se ha diseado fuera del sistema existente.
Todo esto sucede, cuando el nico coste necesario (si se hubieran tomado las
decisiones apropiadas en el momento correcto) era el diseo e implementacin
del mdulo de impresin,
Este ejemplo es bastante comn. El nmero de defectos que se presentan
cuando los informticos lanzan productos bajo una excesiva presin es hasta
cuatro veces mayor. En los proyectos que tienen problemas de planificacin, se
suelen obsesionar por por trabajar ms duro, en vez de trabajar de la forma ms
ingeniosa. Prestar atencin a la calidad es como si fuera un lujo.
Decidir al principio de un proyecto no centrarse en la deteccin de errores
equivale a la decisin de posponer la deteccin de defectos hasta ms tarde,
cuando ser ms cara y consumir ms tiempo. No es una decisin racional
cuando el tiempo apremia.
Si se pueden prevenir o detectar los defectos y eliminarlos pronto se obtiene una
ventaja significativa en la planificacin. Los estudios han demostrado que revisar
errores de requerimientos, diseo y producto desarrollado normalmente consume
del 40 al 50% de del coste total del desarrollo del producto. Como regla emprica,
cada hora que se emplea en prevenir defectos reduce el tiempo empleado en la
recuperacin de 3 a 10 horas. En el peor caso, revisar un problema de
requerimientos, una vez que el producto est en funcionamiento, normalmente
cuesta de 50 a 200 veces ms que lo que costara revisar el problema cuando
est en fase de requerimientos. Dado que ms del 60% de los errores se dan en
tiempo de diseo, se pueden ahorrar grandes cantidades de tiempo detectando
los errores antes de hacer la prueba del producto.
14.6.4
MTODOS PARA EL CONTROL DE CALIDAD
14.6.4.1
Prueba
El mtodo ms comn de control de calidad es indudablemente la prueba de

ejecucin: encontrar errores al ejecutar el programa y ver lo que hace. Las dos
clases ms comunes de pruebas de ejecucin son las pruebas individuales, en las
cuales el informtico comprueba su propio producto para verificar si funciona
correctamente, y las pruebas del sistema, en las que un probador independiente
comprueba si el sistema funciona como se esperaba.
79/86
Manual Terico
La eficacia de las pruebas vara enormemente. La prueba individual puede

encontrar del 10 al 50% de los defectos de un programa, y la prueba del sistema
del 20 al 60% . Al unir las dos, la tasa acumulada de deteccin de defectos suele
ser menor del 60%. Los errores que no se localizan se pueden encontrar por otras
tcnicas de deteccin de errores, probablemente cuando el producto ya est en
funcionamiento.
La prueba es la oveja negra en lo que respecta mtodos de control de calidad y
velocidad de desarrollo. Realmente se puede hacer tan mal como para retrasar
la entrega de un producto, pero si se hace bien puede descubrir que la calidad
del producto es demasiado baja para lanzarlo y que el mismo debe rretrasarse
hasta se pueda mejorar.
La mejor forma de fomentar la prueba, para poder entregar el producto lo ms
pronto posible, es preparar un plan antes de obtener las malas noticias;
establecer la prueba de forma que si se dan malas noticias, la prueba permita
lanzar el producto tan pronto como sea posible.
14.6.4.2
Revisiones fsicas
Incluyen toda clase de revisiones que se utilizan para detectar defectos en

requeimientos, diso, cdigo, casos de prueba o cualquier otro artefacto del
proyecto. Las revisiones varan en cuanto a nivel de formalidad y eficacia y
juegan un papel ms crtico en la velocidad del desarrollo que las pruebas. Entre
los tipos de revisiones ms comunes estn:
14.6.4.3
Reuniones
Las reuniones informales son el tipo ms comn de revisin. El trmino reunin se

define aproximadamente y se refiere a cualquier tipo de reunin en la que dos o
ms desarrolladores de proyectos revisan el trabajo tcnico con el objetivo de
mejorar la calidad y detectar errores antes de la prueba.
Una reunin puede detectar un defecto en los requerimientos, en tiempo de
especificacin, antes de que se realice el diseo o se cree el producto. Con este
mtodo pueden detectarse entre el 30 y 70% de los errores en un proyecto
informtico.
14.6.4.4
Inspecciones
Las inspecciones son un tipo de revisin tcnica formal, que ha demostrado ser
extremadamente efectivo en la deteccin de errores de un proyecto. Con las
inspecciones, los desarrolladores reciben una preparacin especial y juegan un
papel especfico durante las mismas.
El moderador se vuelca a trabajar en el producto para inspeccionarlo antes de
la reunin de inspeccin. Los revisores examinan el producto antes de la reunin
y utilizan listas de control para estimular su revisin. Durante la reunin de
inspeccin, el autor normalmente comenta el material inspeccionado, los
revisores identifican los errores y el secretario guarda los errores. Despus de la
revisin el moderador genera ujn informe sobre la inspeccin, describiendo cada
uno de los defectos e indicando lo que se har con ellos.
80/86
Manual Terico
Al igual que en las reuniones, las inspecciones se pueden utilizar para detectar
defectos antes de la prueba. Se pueden utilizar para detectar errores en
requerimientos, prototipos de interfaz de usuarios, diseo, cdigo, etc. Las
inspecciones encuentran entre un 60 y 90% de defectos en un proyecto
informtico.
14.7 GESTIN DE RIESGOS

Si quiere apostar seguro vaya a Las Vegas y juegue a las mquinas
tragamonedas. Los casinos han calculado minuciosamente las probabilidades y
han determinado que pueden obtener beneficios incluso cuando las mquinas
paguen hasta el 97% del dinero que entra en ellas, es decir que recuperar el 97%
de lo que invierta (el costo de su diversin ser un 3%). Si no le gustan las
tragamonedas, pruebe jugar blackjack y contar las cartas para aprovecharse de
las probabilidades.
Si Las Vegas le resulta aburrida, los proyectos informticos pueden ser el juego
apropiado para Ud. Los proyectos de software incluyen un amplio conjunto de
riesgos que intimidara hasta a los ms osados apostadores de Las Vegas.
Cambios en los requerimientos del usuario, mala estimacin de la planificacin,
personal contratado poco fiable, falta de experiencia en la gestin, problemas
de personal, problemas con la tecnologa, cambio de las leyes del gobierno,
entre otros, son solo algunos de los riesgos que se corren en un proyecto
informtico. La probabilidad de que un proyecto complejo finalice en el tiempo
estimado tiende a cero.
Hay una serie de mtodos de gestin de riesgos que pueden prevenir desastres
como estos, y que le harn aprender mucho de ellos antes de lo que aprendera
a contar las cartas en el blackjack.
El control de riesgos tiene una serie de problemas. Los proyectos que llevan un
control efectivo son menos excitantes que los que no lo hacen. Perder el miedo
que supone tener que decirle a su jefe que el proyecto tiene que retrasarse tres
meses por un problema que nunca haba mencionado. Dejar de ser un hroe
por trabajar noches y fines de semana durante seis meses sin descanso.
El control de riesgos en proyectos informticos es un tema relativamente nuevo,
pero ya existe informacin suficiente como para estudiarlo a profundidad. En este
captulo nos limitaremos a analizar los riesgos en la planificacin ignorando los
riesgos sobre costos y produccin.
14.7.1
ELEMENTOS DE LA GESTIN DE RIESGOS
La funcin de la gestin de riesgos en los proyectos informticos es identificar,

estudiar y eliminar las fuentes de riesgo antes de que empiecen a amenazar la
finalizacin satisfactoria de un proyecto informtico.
Hay varios niveles en la gestin de riesgos:
1. Control de crisis: Apagar el fuego; controlar los riesgos solo cuando se han
convertido en problemas
81/86
Manual Terico
2. Arreglar cada error: Detectar y reaccionar rpidamente ante cualquier

riesgo, pero solo despus de que se ha producido.
3. Mitigacin de riesgos: planificar con antelacin el tiempo que necesitara
para cubrir riesgos en caso de que ocurran, pero no intentar eliminarlos
inicialmente.
4. Prevencin: Crear y llevar a cabo un plan como parte del proyecto para
identificar los riesgos y evitar que se conviertan en problemas.
5. Eliminacin de las causas principales: Identificar y eliminar los factores que
puedan hacer posible la presencia de algn tipo de riesgo.
14.7.2
ESTIMACIN DE RIESGOS
Esta tarea se compone de tres partes:

Identificacin de riesgos: genera una lista de riesgos capaces de romper la
planificacin del proyecto.
Anlisis de riesgos: Mide la posibilidad y el impacto de cada riesgo y los
niveles de riesgo de los mtodos alternativos.
Asignacin de prioridades a los riesgos: genera una lista de riesgos
ordenados por su impacto. Esta lista sirve como base para el control de
riesgos.
14.7.3
CONTROL DE RIESGOS
Esta tarea tambin se compone de de tres partes:

Planificacin de la gestin de riesgos: Genera un plan para tratar cada
riesgo significativo. Tambin asegura que los planes para la gestin de
riesgos de cada uno de los riesgos individuales son consistentes entre s y
con el plan del proyecto.
Resolucin de riesgos: es la ejecucin del plan para resolver cada uno de
los riesgos significativos.
Monitorizacin de riesgos: Es la supervisin del progreso de las actividades
de anulacin de elementos de riesgo.
14.7.4
IDENTIFICACIN DE RIESGOS
El primer paso en la gestin de riesgos es la identificacin de los factores que

introducen un riesgo en un proyecto informtico.
Los riesgos ms habituales en un proyecto informtico son:
1. Cambios en los requerimientos
2. Meticulosidad en requerimientos o de los informticos que realizarn el
proyecto.
3. Escatimar en la calidad
4. Planificaciones demasiados optimistas
5. Diseo inadecuado
6. Sndrome de la panacea
7. Desarrollo orientado a la investigacin
8. Personal mediocre
9. Errores en la contratacin de outsourcing o personal externo
82/86
Manual Terico
10. Diferencias entre los informticos y los usuarios

Otros riesgos que vale la pena identificar pueden clasificarse as:
En la planificacin:
1. Planificacin que no incluye tareas necesarias.
2. La planificacin se ha basado en la utilizacin de personas especficas que
no estn disponibles
3. Presin excesiva en la planificacin reduce la productividad
4. Un retraso en una tarea produce retrasos en cascada en tareas
dependientes
Organizacin y gestin:
1. El proyecto carece de un promotor efectivo en los superiores
2. El proyecto languidece en el inicio difuso
3. Los despidos y reducciones en la plantilla reducen la capacidad del
equipo
4. La Direccin insiste en tomar decisiones tcnicas que alargan el tiempo de
desarrollo
5. Las tareas no tcnicas encargadas a terceros toman ms tiempo del
esperado (aprobacin de presupuesto, aprobacin de adquisicin de
materiales, etc.)
Entorno de desarrollo:
1. Los espacios no estn disponibles en el momento necesario
2. Los espacios estn disponibles pero no son adecuados
3. Los espacios estn sobreutilizados, son ruidosos o distraen
4. Las herramientas de desarrollo no estn disponibles en el momento
deseado
5. Las herramientas de desarrollo no funcionan como se esperaba o no
proporcionan las prestaciones previstas
6. La curva de aprendizaje para la nueva herramienta es ms larga de lo
esperado.
Usuarios finales:
1. Los usuarios finales insisten en nuevos requerimientos
2. En el ltimo momento a los usuarios finales no les gusta el producto
3. Los usuarios no tienen la infraestructura necesaria
4. Las herramientas de soporte y entorno que tiene el usuario no son
compatibles
Producto:
1. El requisito de trabajar con varios sistemas operativos necesita ms tiempo
del esperado.
2. Trabajar en un entorno de hardware y software desconocido causa
problemas imprevistos
83/86
Manual Terico
3. Requisitos rgidos de compatibilidad con el sistema existente necesitan un

trabajo extra de comprobacin diseo e implementacin.
Personal:
1. La contratacin tarda ms de lo esperado
2. Dificultades en la relacin entre la direccin y el equipo de informticos
3. Falta de motivacin y moral reduce la productividad
4. La falta de especializacin necesaria aumenta los defecto y la necesidad
de repetir el trabajo
5. El personal abandona el proyecto antes de su finalizacin
6. Se necesitan personas con habilidades muy especficas que no estn
disponibles
Obviamente, hay ms, muchos ms!
14.7.5
ANLISIS DE RIESGOS
Una vez que se hayan identificado los riesgos de un proyecto, el siguiente paso es
analizar cada riesgo para determinar su impacto. Se puede utilizar el anlisis de
riesgos para poder elegir entre varias alternativas de desarrollo, o para gestionar
los riesgos asociados con una alternativa que haya elegido.
Utilizando el mtodo de Exposicin a Riesgos se estiman la probabilidad de que
un riesgo se cristalice, el tiempo que se perdera si eso sucediera y,
consecuentemente, la prdida a la que estamos expuestos.
Un ejemplo de tabla de estimacin de riesgos es la siguiente:
RIESGO
PROBABILIDAD DE
MAGNITUD DE
EXPOSICIN A
PRDIDA
LA PRDIDA
RIESGO
PLANIFICACIN DEMASIADO OPTIMISTA
50%
2. 5
AADIR UN REQUISITO PARA LA ACTUALIZACIN
5%
20
1. 0
EL USUARIO AADE NUEVAS CARACTERSTICAS
35%
2. 8
DISEO INADECUADO (HAY QUE VOLVER A DISEAR)
15%
15
2. 25
LA APROBACIN DEL PROYECTO TARDA MS DE LO
25%
10%
0. 2
30%
1. 5
AUTOMTICA DESDE EL MAINFRAME
ESPERADO
LOS RECURSOS NO ESTN DISPONIBLES EN SU

MOMENTO
LAS NUEVAS HERRAMIENTAS DE PROGRAMACIN NO

PRODUCEN EL AHORRO PROMETIDO
Tanto las probabilidades como la magnitud son estimaciones subjetivas. Pero

puede mejorarse su exactitud. He aqu algunas ideas:
Disponer de la persona que est ms familiarizada con el proyecto para
que estime la probabilidad de cada riesgo.
84/86
Manual Terico
Usar tcnicas de concenso en grupo. Cada persona estima

individualmente cada riesgo y luego se discute hasta llegar a una
convergencia
Utilizar calibracin mediante adjetivos. Primero cada persona elige el
nivel de riesgo entre una serie de frases como: muy probable, bastante
probable, improbable, muy improbable. Despus se cuantifican estas
estimaciones.
14.7.6
CONTROL DE RIESGOS
Una vez identificados los riesgos hay que estar preparado para controlarlos. A
continuacin se describen los mtodos de control de los 10 riesgos ms habituales
que se enumeraron anteriormente:
RIESGO
1. CAMBIO DE PRESTACIONES
2. REQUERIMIENTOS SUPERFLUOS
O PERSONAL INFORMTICO
METICULOSO
3. RECORTE DE LA CALIDAD
MTODOS DE CONTROL
USO DE TCNICAS ORIENTADAS AL CLIENTE
USO DE TCNICAS DE DESARROLLO INCREMENTAL
CONTROL DEL CONJUNTO DE PRESTACIONES
DISEO ORIENTADO AL CAMBIO
FILTRADO DE REQUERIMIENTOS
DESARROLLO CON VENTANAS TEMPORALES
CONTROL DEL CONJUNTO DE PRESTACIONES
ENTREGA POR ETAPAS
PROTOTIPOS DESHECHABLES
DEJAR TIEMPO PARA LAS ACTIVIDADES DE CONTROL DE
CALIDAD
PRESTAR ATENCIN A LAS BASES DE CONTROL DE CALIDAD

4. PLANIFICACIN DEMASIADO
OPTIMISTA
UTILIZACIN
DE
TCNICAS
DE
ESTIMACIN,
ESTIMADORES Y HERRAMIENTAS DE ESTIMACIN
VARIOS
NEGOCIACIONES CONVENIENTES
TCNICAS DE DESARROLLO INCREMENTAL
5. DISEO INADECUADO
DESTINAR TIEMPO SUFICIENTE PARA LA ACTIVIDAD DE DISEO

PROGRAMAR LAS INSPECCIONES DE DISEO
6. SNDROME DE LA PANACEA
SER ESCPTICO SOBRE LOS PROBLEMAS DE PRODUCTIVIDAD

CONFIGURAR UN PROGRAMA DE MEDIDAS DE SOFTWARE
CONFIGURAR UN GRUPO DE HERRAMIENTAS DE SOFTWARE
7. DESARROLLO ORIENTADO A
LA INVESTIGACIN
8. PERSONAL MEDIOCRE
NO INTENTE INVESTIGAR Y MAXIMIZAR LA VELOCIDAD DE

DESARROLLO AL MISMO TIEMPO
PERSONAL CON TALENTO

CONTRATAR Y PLANIFICAR LOS MIEMBROS CLAVES DEL EQUIPO
MUCHO ANTES DE QUE COMIENCE EL PROYECTO
PREPARACIN Y CAPACITACIN
9. ERRORES EN LA
CONTRATACIN DE
OUTSOURCING O PERSONAL
PEDIR REFERENCIAS
ESTIMAR LA CAPACIDAD DEL PERSONAL CONTRATADO ANTES DE
CONTRATARLO
EXTERNO
85/86
RIESGO
Manual Terico
MTODOS DE CONTROL
TENER BUENAS RELACIONES CON EL PERSONAL CONTRATADO
10. DIFERENCIAS ENTRE LOS
UTILIZAR TCNICAS ORIENTADAS AL CLIENTE
INFORMTICOS Y LOS
USUARIOS
86/86

Documents - Tips Administracion de Centros de Informatica PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Documents - Tips Administracion de Centros de Informatica PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Primera Edicin

ADMINISTRACIN DE CENTROS DE INFORMTICA

Manual Terico| Luis Fernando Zelaya Iras

Administracin de Centros de Informtica

COCEPTOS BSICOS DE ADMIISTRACI --------------------------------------------------------- 4

SISTEMA DE EMPRESA Y SISTEMA DE ADMIISTRACI --------------------------------------- 7

SISTEMAS DE EMPRESA ------------------------------------------------------------------------------------------- 7

EL GERETE DE IFORMTICA -------------------------------------------------------------------------- 13

PLAEACI ESTRATGICA Y OPERATIVA --------------------------------------------------------- 14

PLAEACI E U CETRO DE IFORMTICA -------------------------------------------------- 23

CONCEPTO DE PLANEACIN ------------------------------------------------------------------------------------- 14

ORGAIZACI: EQUIPOS DE TRABAJO E CETROS DE IFORMTICA -------------- 31

Administracin de Centros de Informtica

COTROL: PROTECCI DE DATOS, HARDWARE Y SOFTWARE ---------------------------- 60

INTRODUCCIN A LA PROTECCIN DE LOS DATOS ----------------------------------------------------------- 60

ADMIISTRACI DE PROYECTOS IFORMTICOS --------------------------------------------- 65

Administracin de Centros de Informtica

1 CONCEPTOS BSICOS DE ADMINISTRACIN

1.2 LA ADMINISTRACIN UNA CIENCIA O UNA TCNICA?

Nos ensea a conocer

Nos ensea a hacer

Administracin de Centros de Informtica

En cada una de esas definiciones encontramos elementos que se aplican a la

1.3 RELACIN DE LA ADMINISTRACIN CON OTRAS CIENCIAS

1.4 CARACTERSTICAS DE LA ADMINISTRACIN

Administracin de Centros de Informtica

1.5 OBJETIVOS DE LA ADMINISTRACIN

1.6 PROBLEMAS ESPECFICOS DE LOS ADMINISTRADORES

Administracin de Centros de Informtica

2 SISTEMA DE EMPRESA Y SISTEMA DE ADMINISTRACIN

El estudio de las empresas y la administracin puede afrontarse desde un punto

2.1.1 ENFOQUE ESTTICO

Administracin de Centros de Informtica

Componentes del Sistema de

El funcionamiento de este sistema puede resumirse en el ciclo principal, el cual

2.1.2 ENFOQUE DINMICO

Administracin de Centros de Informtica

Ciclo Operacional del sistema de centro de

2.2 SISTEMAS DE ADMINISTRACIN

Administracin de Centros de Informtica

El sistema operacional es la base del sistema administrativo, de all provienen las

2.2.1 SISTEMA DE CONTROL

Funcin: Administrar eficaz y racionalmente los recursos

Administracin de Centros de Informtica

2.2.2 SISTEMA OPERACIONAL

Funcin: Realizar un producto terminado

Producto o servicio terminado

2.2.3 SISTEMA ORGANIZACIONAL

Administracin de Centros de Informtica

b. El subsistema de informacin: Este es el conjunto de informes relativos a las

Funcin: Implantar estructuras organizacionales y operacionales

2.3 ELEMENTOS PARA LA CONSTRUCCIN DE SERVICIOS INFORMTICOS

GEREENTE/PRESI DENTE, SUBGERENTES, GERENTES FUNCION ALES

GENER AR PRODUCTOS DE UTILIDAD Y SATISFACCIN DEL USU ARI O

MATERI ALES, I NFORM ACI N, ENERG A

CONVERTI R PARTES Y M ATERI AS PRIMAS EN BIENES TERMINADOS,

PRODUCTOS, I NFORM ACI N, SERVICIOS

Administracin de Centros de Informtica

CONOCIMIENTO TOTAL DE LA COMPA A Y SUS

CAPACIDAD DE DIRIGIR PROYECTOS

RELACIONES CON LA ALTA GERENCIA

RELACIONES CON LOS SUBORDINADOS

CAPACIDAD DE DISEAR SERVICIOS Y ANALIZAR Y