Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
OCE-0620
Manual Terico
INDICE
I DICE ---------------------------------------------------------------------------------------------------------------------- 2 1 CO CEPTOS BSICOS DE ADMI ISTRACI 1.1 1.2 1.3 1.4 1.5 1.6 2 --------------------------------------------------------- 4
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 ADMI ISTRACI --------------------------------------- 7 2.1 2.2 2.3 SISTEMAS DE EMPRESA ------------------------------------------------------------------------------------------- 7 SISTEMAS DE ADMINISTRACIN --------------------------------------------------------------------------------- 9 ELEMENTOS PARA LA CONSTRUCCIN DE SERVICIOS INFORMTICOS ------------------------------------ 12
3 4
EL GERE TE DE I FORMTICA -------------------------------------------------------------------------- 13 PLA EACI ESTRATGICA Y OPERATIVA --------------------------------------------------------- 14 4.1 4.2 4.3 4.4 4.5 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
PLA EACI E U CE TRO DE I FORMTICA -------------------------------------------------- 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
ORGA IZACI ------------------------------------------------------------------------------------------------- 28 6.1 6.2 6.3 DEFINICIN -------------------------------------------------------------------------------------------------------- 28 PASOS DE LA ORGANIZACIN ----------------------------------------------------------------------------------- 28 ESTRUCTURA ORGANIZACIONAL ------------------------------------------------------------------------------- 28
ORGA IZACI : EQUIPOS DE TRABAJO E CE TROS DE I FORMTICA -------------- 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 ORGA IZACI : ESTRUCTURA DE EQUIPOS DE TRABAJO E CE TROS DE I FORMTICA --------------------------------------------------------------------------------------------------------- 35 8.1 8.2 8.3 9 INTRODUCCIN ---------------------------------------------------------------------------------------------------- 35 TIPOS DE EQUIPOS ------------------------------------------------------------------------------------------------ 35 MODELOS DE EQUIPO -------------------------------------------------------------------------------------------- 37
MOTIVACI ---------------------------------------------------------------------------------------------------- 40 9.1 9.2 9.3 9.4 9.5 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
10
LIDERAZGO ------------------------------------------------------------------------------------------------------ 46
2/86
Manual Terico
COMU ICACI ------------------------------------------------------------------------------------------------ 49 11.1 11.2 11.3 11.4 11.5 11.6 11.7 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
12
CO TROL ---------------------------------------------------------------------------------------------------------- 53 12.1 12.2 12.3 DEFINICIN -------------------------------------------------------------------------------------------------------- 53 CONTROLES GENERALES EN EL CENTRO DE INFORMTICA ------------------------------------------------ 53 ESTNDARES EN LOS CENTROS DE INFORMTICA ----------------------------------------------------------- 55
13
CO TROL: PROTECCI DE DATOS, HARDWARE Y SOFTWARE ---------------------------- 60 13.1 13.2 13.3 13.4 13.5 13.6 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
14
ADMI ISTRACI DE PROYECTOS I FORMTICOS --------------------------------------------- 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
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.
Manual Terico
6/86
Manual Terico
7/86
Manual Terico
PRODUCCIN
estudio de necesidades
desarrollo e implantacin
Mercadotecnia Consumidores
Recursos Materiales
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.
8/86
Manual Terico
Previsiones
Planificacin de la produccin
Puesta en marcha
Aprovisionamiento
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.
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.
Insumos (Datos)
Identificacin de Variables
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.
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.
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
Sistema Organizacional
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 CONOCIMIENTO TOTAL DE LA COMPA A Y SUS
OBJETIVOS CLASIFICADA POR EJECUTIVOS EN INFORMTICA CLASIFICADA POR EJECUTIVOS GENERALES
2 6 1
1 2 3
CAPACIDAD DE DIRIGIR PROYECTOS RELACIONES CON LA ALTA GERENCIA RELACIONES CON LOS SUBORDINADOS CONOCIMIENTO
DE LAS INFORMACIN UTILIZADAS JUZG AR DISEOS TECNOLOGAS DE
4 3 5 8 7
4 5 6 7 8
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
Contenido de la Planeacin
Dnde estamos? a dnde queremos ir? a dnde podemos llegar? a dnde debemos llegar? Cmo podemos llegar? Cundo queremos llegar? Quin es el responsable? Cunto costar? Anlisis de Fortalezas y Debilidades Objetivos/Metas Visin de la organizacin Misin de la organizacin Polticas/Estrategias Programacin de Actividades Planeacin organizacin operativa de la
14/86
Manual Terico
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.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. ... 2. ... 3. ...
OBJETIVOS ESPECIFICOS
19/86
Manual Terico
4.5.1.1.1.1.1.1.1
<Mes inicio> del <Ao inicio> a <Mes inicio> del <Ao final>
Perodo Descripcin de la Actividad Desde Cronograma (May - Abr) Recursos Requeridos
Humanos Materiales Financieros
Hasta M J J A S O N D E F M A Responsable
Observaciones
Actividad 1 Actividad 2
02/05/00 08/05/00
09/05/00 15/05/00
Actividad 3 Actividad 4
IDEM
IDEM
IDEM
IDEM
Funcionario Y Consultor
20/86
Manual Terico
21/86
Manual Terico
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. 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
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
Producto
Costo
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.
Manual Terico
mejor a sus necesidades, segn la importancia estratgica que tenga el centro o departamento de informtica.
Compaa XYZ
Estructura Organizacional Centro de Informtica Gerente de Informtica
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.
29/86
Manual Terico
Compaa XYZ
Estructura Organizacional Centro de Informtica Gerente de Informtica
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.
Manual Terico
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.
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
35/86
Manual Terico
Objetivo General
Resolucin de Problemas
Caracterstica Dominante Ejemplo tpico en un centro de informtica nfasis en el Proyecto Confianza Mantenimiento corrector en sistemas en marcha Centrado en cuestiones especficas
Creatividad
Autonoma Desarrollo de un nuevo producto Explorar posibilidades y alternativas
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
Inteligentes, desenvueltos, sensibles, alta INTEGRIDAD Equipo de negocios, equipo de bsqueda y rescate, equipo SWAT
de
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
36/86
Manual Terico
37/86
Manual Terico
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.
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.
DIRECTIVOS DE INFORMTICOS
1) RESPONSABILIDAD 2) REALIZACIN 3) EL PROPIO TRABAJO 4) RECONOCIMIENTO 5) POSIBILIDAD DE SUPERACIN 6) RELACIONES
INTERPERSONALES, SUBORDINADOS
PERSONAS EN GENERAL
1) REALIZACIN 2) RECONOCIMIENTO 3) EL PROPIO TRABAJO 4) RESPONSABILIDAD 5) ASCENSO 6) SALARIO 7) POSIBILIDAD DE SUPERACIN 8) RELACIONES INTERPERSONALES,
SUBORDINADOS
6) ASCENSO 7) RELACIONES
INTERPERSONALES, IGUAL NIVEL
7) RELACIONES
INTERPERSONALES, IGUAL
40/86
Manual Terico
INFORMTICOS
8) RECONOCIMIENTO 9) SALARIO 10) RESPONSABILIDAD 11) RELACIONES
INTERPERSONALES, SUPERIORES 12) SEGURIDAD EN EL TRABAJO 13) RELACIONES INTERPERSONALES, SUBORDINADOS
DIRECTIVOS DE INFORMTICOS
NIVEL
PERSONAS EN GENERAL
9) POSICIN SOCIAL 10) RELACIONES INTERPERSONALES, SUPERIORES 11) RELACIONES INTERPERSONALES, IGUAL
NIVEL
12) OPORTUNIDAD DE
SUPERVISIN TCNIC A
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.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.
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.
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.
Manual Terico
Manual Terico
equipo de desarrollo, y la mayora de las personas no pueden ser motivadas por alguien a quien no respetan.
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.
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.
47/86
Manual Terico
10.3.1
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
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
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
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
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
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
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.
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.
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.
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.
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
12.3.1
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 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
Manual Terico
12.3.3
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.
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
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.5 PROTECCIN
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.
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
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.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
Manual Terico
b.
c.
d. e. f. g.
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.
14.3.3
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
Manual Terico
14.3.4
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.
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
Manual Terico
u.
v.
w.
x.
y.
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.
14.5.2
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
Manual Terico
d. e.
f.
g.
h.
i.
j.
k.
l.
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.1
14.6.1.1
BASES DE GESTIN
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
14.6.2.1
BASES TCNICAS
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
Manual Terico
14.6.2.3
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
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
14.6.4.1
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.1
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 PLANIFICACIN DEMASIADO OPTIMISTA AADIR UN REQUISITO PARA LA ACTUALIZACIN
AUTOMTICA DESDE EL MAINFRAME
PROBABILIDAD DE
PRDIDA
MAGNITUD DE
LA PRDIDA
EXPOSICIN A
RIESGO
5 20 8 15 4 2 5
2. 5 1. 0 2. 8 2. 25 1 0. 2 1. 5
EL USUARIO AADE NUEVAS CARACTERSTICAS DISEO INADECUADO (HAY QUE VOLVER A DISEAR) LA APROBACIN DEL PROYECTO TARDA MS DE LO
ESPERADO
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 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
2. REQUERIMIENTOS SUPERFLUOS
O PERSONAL INFORMTICO METICULOSO
3. RECORTE DE LA CALIDAD
UTILIZACIN
VARIOS
NEGOCIACIONES CONVENIENTES TCNICAS DE DESARROLLO INCREMENTAL 5. DISEO INADECUADO 6. SNDROME DE LA PANACEA DESTINAR TIEMPO SUFICIENTE PARA LA ACTIVIDAD DE DISEO PROGRAMAR LAS INSPECCIONES DE DISEO 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
PERSONAL CON TALENTO CONTRATAR Y PLANIFICAR LOS MIEMBROS CLAVES DEL EQUIPO
MUCHO ANTES DE QUE COMIENCE EL PROYECTO
85/86
Manual Terico
MTODOS DE CONTROL TENER BUENAS RELACIONES CON EL PERSONAL CONTRATADO UTILIZAR TCNICAS ORIENTADAS AL CLIENTE
86/86