Christian A. Estay-Niculcar's research blog

Espacio de reflexión personal dedicado a la investigación aplicada cuando se vincula la ciencia proyectual con la disciplina informática, y se aplican al desarrollo de las personas y de la gestión empresarial.

Ingeniería del Proyecto: Hacia una más adecuada gestión de proyectos informáticos a través del reconocimiento de sus dimensiones

Cuando se pretende gestionar un proyecto informático, hay dos extremos, o se asume la evidencia anecdótica de que estos proyectos son especiales y tienen una gestión “especial” o nos ponemos serios y apostamos por hacer una gestión profesional de estos proyectos. En este ultimo caso, se propone como previo a una gestión formal de proyectos informáticos, el identificar las dimensiones del proyecto con el fin de reconocer sus principales componentes e intentar clasificarlos. Estas ideas son muy antiguas (1997) y la verdad útiles especialmente en momentos en que se intenta introducir la gestión de proyectos en los proyectos informáticos.

Los proyectos informáticos son un tipo particular de proyecto, los cuales, según como se mire, podrían ser proyectos industriales en la medida de producir un artefacto, o podrían considerarse proyectos de ingeniería en razón de buscar y crear soluciones (proyecto de acción). No se quiere entrar en una discusión taxonómica, pero si se puede afirmar que los proyectos informáticos se distinguen por ser un universo por sí solos. Se puede indicar entonces que existen tipos de proyectos informáticos que pueden clasificarse por sector o por sus singularidades y criterios. Por sector sería atender al producto final y es una buena forma de clasificarlos, no obstante, son más los software de uso general que los específicos por sector, por ende clasificarlos sería una tarea bastante inocua. Por singularidades y criterios si permite acercarse a reconocer elementos distintivo que para un gestor de proyectos es bueno manejar y conocer para definir sus acciones.

Por este motivo, se discuten aquí tipos de proyectos informáticos según los siguientes criterios derivados de la observación etnometodología de casos reales y casos retrospectivos bibliográficos:

  • dimensión del artefacto;
  • dimensión de alcance;
  • dimensión del trabajo;
  • dimensión de desarrollo; y,
  • dimensión organizacional.

A continuación se describe cada dimensión. Cabe añadir que si alguien pretende una taxonomía de proyectos informáticos para conseguir una buena gestión de proyectos en ellos, lo mejor es hacerla en base a dimensiones, no en base a tipos específicos.

SEGÚN DIMENSIÓN DEL ARTEFACTO

Esta dimensión cubre la naturaleza del principal producto físico a entregar, atendiendo a la forma de la solución que se entrega. En este caso, puede ser un estudio y/o un conjunto de componentes como:

  • Informes sobre los beneficios de la solución informática.
  • Software y sus versiones de desarrollo dispuestas en unidades de almacenamiento, en una o varias copias.
  • Personal requerido para la operación del software según indicaciones de habilidades y aptitudes.
  • Documentación y manuales del software de diverso índole y naturaleza dependiendo de los lectores de tal material.
  • TIC asociadas al uso del producto material de software.

Lo anterior no evita que puedan distinguirse dos tipos de proyectos:

  • a) Proyecto de software. Este es el proyecto más común y se caracteriza por que el producto es un software en algún soporte físico. Según Alter un proyecto de software es un sistema de trabajo de tiempo limitado que busca satisfacer un requerimiento particular. Solucionar el problema de Y2K es un ejemplo. El proyecto comienza con algún software existente y su objetivo es remover problemas desde tal software sin cambiar su función pretendida. El objetivo es hacer cosas que no cambian el medio externo, como por ejemplo, la nueva versión de un procesador de textos donde el resultado directo puede ser unsoftware a bajar (download) o un parche, en lugar de hacer cambios en un sistema informático operacional dentro de una organización particular.El gestor de este tipo de proyectos, en este caso, declara una victoria cuando el software corre en un ordenador de la manera deseada, independiente de quien le esté usando. Un proyecto de software puede ser parte de un proyecto de sistema de información o de un proyecto de un sistema de trabajo (un sistema humano-máquina de trabajo). Si es así, el esfuerzo no es completo hasta que finalmente el proyecto de software opera como se pretende dentro del sistema deinformación o el sistema de trabajo. Dentro de esta definición tienen cabida todos los proyectos informáticos vinculados al diseño lógico, implantación, etc. o cualquier otra actividad que finalmente conduce a software operando en hardware.
  • b) Proyecto de infraestructura informática. Estos proyectos son poco frecuentes, pero no por ello ausentes en esta dimensión. Estos proyectos, según Steiner, son casos especiales en que no hay necesariamente un desarrollo de software, sino se encuentran caracterizados por la elección de hardware para una mayor aplicación, consolidar servidores o rediseñar redes de telecomunicaciones.

SEGÚN DIMENSIÓN DE ALCANCE

Los proyectos pueden definirse en función del alcance pretendido. En este caso se distinguen proyectos de sistemas de información y proyectos de ingeniería de software.

  • a) Proyecto de sistema de información.Según Alter un proyecto de sistema de información es un sistema de trabajo de tiempo limitado cuyo objetivo es crear o modificar un sistema de información para que opere según un conjunto de requerimientos y sea mantenible. Un ejemplo de proyecto de sistema de información es construir un nuevo sistema de seguimiento de ventas. La esencia del sistema de trabajo es vender, pero el sistema de información le provee un soporte. El gestor de proyectos declara la victoria cuando el sistema de información está operando de la manera deseada, independiente de si las ventas se hacen o no efectivamente. Debe aclararse aquí que sistema de información se entiende en un sentido amplio, lo cual involucra entidades humanas e infraestructura TI. En este sentido el sistema de información se compone de un sistema informático, también llamado sistema de información basada en ordenador, aparte de un sistema no computacional.
    • a.1. Proyecto de sistema de información: visión de tecnológica. Según Alter un proyecto de sistema de información, desde la visión de TI es un proyecto cuyo objetivo inmediato es construir o modificar software. La victoria se declara cuando el software satisface requerimientos y es aceptado por los usuarios y/o sus directivos.
    • a.2. Proyecto de sistema de información: visión de negocios. Según Alter un proyecto de sistema de información, desde la visión de negocios, es un proyecto cuyo objetivo inmediato es mejorar un sistema de trabajo. La victoria se declara cuando el sistema de trabajo satisface objetivos de negocio y cuenta con un mecanismo para continuar cambios de manera exitosa.
  • b) Proyecto de ingeniería de software. Según Thayer los proyectos de Ingeniería de Software son frecuentemente partes de proyectos mayores que incluyen equipamiento (hardware), servicios (facilities), personal y procedimientos. Ejemplos son sistemas de vuelo, sistemas de contabilidad, sistemas de radar, sistemas de control de inventarios y sistemas de control ferroviario. Thayer añade que este tipo de proyectos puede considerarse un proyecto de software cuando el producto del proyecto es un software; aunque también debemos considerar el software como producto y vehículo de entrega al mismo tiempo.

SEGÚN DIMENSIÓN DEL TRABAJO

Aquí el proyecto se distingue por el tipo de trabajo a realizar sobre los materiales, el cual puede ser a medida o una adaptación.

  • a) Proyecto para construir algo nuevo o a medida. Aquí se elabora una solución que se plasma en un software y/o infraestructura hecho a la medida o nuevo. Un ejemplo de este tipo es el desarrollo de un sistema de información para una actividad organizacional específica o para un área vertical de servicios como lo es sanidad.
  • b) Proyecto de adaptación. Aquí se elabora una solución que involucra la adaptación de un software y/o infraestructura. Por ejemplo, aquí tienen cabida los desarrollos de aplicaciones ERP que requieren adaptación de código fuente.

SEGÚN DIMENSIÓN DE DESARROLLO

Esta dimensión permite caracterizar el proyecto según la actividad de desarrollo que se ejecuta o el modelo de desarrollo que se sigue. Las actividades son fases del desarrollo, las cuales se organizan u ordenan en procesos descritos en la literatura como modelos o paradigmas de desarrollo.

  • Fases. Sin entrar en detalles se puede decir que las fases características, habituales o más frecuentes son: Análisis de requisitos/requerimientos; Diseño; Implementación; Prueba; y, Entrega y Mantenimiento. No cabe profundizar en las fases pues existe abundante información bibliográfica impresa y online.
  • Modelos. Sin entrar en detalles se pueden señalar varios modelos de desarrollo (paradigmas) que organizan las fases: Modelo de Cascada; Modelos de Procesos Incrementales (Modelo Incremental. Modelo RAD); Modelos de Procesos Evolutivos (Prototipado, Modelo Espiral, Modelo de Desarrollo Concurrente); Modelos de Procesos Especializados (Desarrollo a base de Componentes, Modelo del Método Formal, Desarrollo de software Orientado a Objetos), Proceso Unificado (por ejemplo, RUP); y Modelos Ágiles (eXtremme programming, Adaptive Software Development -ASD-, Lean software development, Crystal Clear, o Scrum). En esta lista se incluye un tipo especial de proyecto encontrado en la literatura llamado e-project para desarrollo de sistemas online (se identifican 3 variantes: de nueva construcción, de remodelamiento, y de manutención). No cabe profundizar en todos estos modelos pues existe abundante información bibliográfica impresa y online.

SEGÚN DIMENSIÓN ORGANIZACIONAL

Esta dimensión permite distinguir un proyecto según las diferentes formas organizacionales que se ven involucradas en un proyecto. La dimensión organizacional se define administrativamente por su estructura organizacional, por la morfología de su equipo de trabajo, y por los roles existentes.

  • a.- Estructura organizacional. Existen diferentes formas de estructura organizacional: funcional, por proyectos, matricial, o mixta. La estructura organizacional frecuentemente condiciona la disponibilidad o los términos en los que se puede disponer de los recursos para el proyecto. Las estructuras organizacionales de un proyecto cubren un amplio espectro que va desde la estructura funcional a la organización por proyectos, con distintos tipos de estructuras matriciales entre ambas. La siguiente tabla tomada de diversas referencias detalla las características clave de los principales tipos de estructuras de organización reseñadas. La elección de la estructura es crucial en términos de comunicación, administración del proceso y formalismos organizacionales que deben cumplirse. Sobre los diversos tipos de estructuras organizacionales existentes no cabe profundizar aquí porque existe abundante bibliografía impresa y online.
  • b.- Equipo de trabajo. Los equipos en un proyecto son organizados de muchas maneras, cada una de los cuales tiene un efecto en la eficiencia de su desempeño. Una estructura de proyecto inadecuado puede conducir a tiempos de desarrollo extensos, costos altos, calidad pobre, mala comunicación y moral baja, además de una alta rotación, todo lo cual puede conducir a la cancelación o término del proyecto. No existen estructuras apropiadas a todos los proyectos informáticos, una estructura de equipo responde a un orden y una organización única para un determinado tipo de proyecto y para un determinado producto o servicio a generar. Su re-usabilidad en otro proyecto podría ser desastrosa. A continuación se muestran cuatro tipos habituales de estructuras de equipos para proyectos.
    • b.1.- Equipo de proyecto isomórfico. Un equipo isomórfico se organiza según la estructura de los principales módulos de software. Cada miembro del equipo es asignado a un módulo de software específico de inicio a fin. Las ventajas de esta estructura son: es organizacionalmente simple; muchas tareas son desarrolladas de forma paralela; y las tareas pueden ser claramente definidas y comprendidas.
Equipo de proyecto isomórfico

Equipo de proyecto isomórfico

        • b.1.1. La VENTAJA de los equipos isomórficos es que son adecuados para proyectos donde los módulos de software son relativamente independientes de cada otro.
        • b.1.2. La DESVENTAJA de este tipo de equipo es que puede conducir a dificultades en la integración de módulos, por problemas de comunicación entre desarrolladores.
    • b.2.- Equipo de proyecto de especialistas. En este tipo de estructura, cada miembro del equipo se dedica a resolver asuntos y temas relativos a su área de conocimiento o experticia a lo largo de todos los módulos o tareas a cumplir en un proyecto.

      Equipo de proyecto de especialistas

      Equipo de proyecto de especialistas

        • b.2.1. La VENTAJA de este tipo de proyecto es que permite aprovechar al máximo el potencial y la eficiencia de cada experto.
        • b.2.2. La DESVENTAJA es que surgen dificultades de integración, carencia de unidad en el módulo (cada experto a lo suyo), y problemas de monitoreo y seguimiento con relación a lo que aporta cada especialista.
    • b.3.- Equipo de proyecto democrático.Este tipo de estructura de equipo, llamado en ocasiones auto-gestionado, posee una estructura relativamente informal. Sus cualidades son: la toma de decisiones es compartida entre los miembros; y, la estructura promueve y fortalece la comunicación e interacción entre los miembros.

      Equipo de proyecto democrático

      Equipo de proyecto democrático

        • b.3.1. La VENTAJA de este tipo de equipo es que trabaja bien para proyectos de desarrollo mal definidos (ill-defined), esencialmente pequeños, donde la innovación y la creatividad son más importantes que el cumplimiento de plazos estrictos.
        • b.3.2. La DESVENTAJA es que no son efectivos. Sus fallas surgen debido a que sus miembros, particularmente personas de gran talento, tiene un alto ego, produciéndose conflictos más bien personales. Otro problema con estos equipos es que tienden a evolucionar sin un liderazgo debido a su ausencia.
    • b.4.- Equipo de proyecto de programador líder.Esta estructura se crea para proyectos informáticos de gran complejidad. La estructura, propuesta por IBM, es diametralmente opuesta a la democrática. Con esta propuesta todas las decisiones importantes son realizadas por un programador líder asistido por varios especialistas realizando funciones detalladas de apoyo asignadas por el mismo líder. Este planteamiento es conceptualmente similar a un equipo médico de cirugía, donde el cirujano realiza la cirugía sobre el paciente asistido por un equipo de asistentes especializados. En un desarrollo de software el programador líder es respaldado por un asistente de líder, quien trabaja de manera cercana al líder y es capaz de reemplazarle. En este caso, el gestor de proyecto es un administrador y un proveedor de recursos

      Equipo de proyecto de líder de programación

      Equipo de proyecto de líder de programación

        • b.4.1. La VENTAJA de este tipo de equipo es que la centralización permite una coordinación de los recursos y una mejor explotación de un experto.
        • b.4.2. La DESVENTAJA es que no hay “cirujanos” en informática y la centralización es un riesgo por sí sola.
  • c.- Roles involucrados.En un proyecto existen diversos tipos de roles involucrados, algunos ligadas directamente al hacer del proyecto y otros como agentes externos.
    • – Componentes considerados en el equipo del proyecto. En el primer grupo aparecen roles de: Jefe de proyecto; Diseñadores lógicos; Diseñadores tecnológicos; Personal de control de calidad y de mejora del proceso de software; Personal informático enviado por contratistas; Personal informático impuesto o enviado por la organización cliente; Expertos (sean enviados por la organización cliente o no); Gestores de Conocimiento; Auditores internos y personal de SQA, SCM y SEPG; Usuarios; etc.
    • – Agentes externos al proyecto. En el segundo grupo se cuenta con la presencia de: cliente(s); dueño(s); promotor (sponsor); financistas/inversionistas; consultores y asesores; auditores/evaluadores; Directores o jefaturas organizacionales; Director de Sistemas de Información o Informática; Directores de Departamentos de Calidad, Riesgo y Proyectos; Proveedores de hardware y software y abastecedores de insumos; Empresas de trabajo temporal que aportan personal; Contratistas, etc.

Referencias citadas

  • Alter, Steven. (2001). “Does the trend Toward e-Business Call for Changes in the Fundamental Concepts of Information Systems? A Debate”. Communications of the AIS, 5(10). April. http://cais.aisnet.org
  • STEINER, PHYLLIS A. (1999). Let’s Use Project Management for IT Infrastructure Projects. IS SIG Newsletters. April.
  • THAYER (ed.) (1985). Software Engineering Project Management. IEEE Computer Society. 529 pp.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

CEO & Co-Founder de EstayConsulting – Consultoría Estratégica

Miembro de Red

//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js (adsbygoogle = window.adsbygoogle || []).push({});

Categorías

A %d blogueros les gusta esto: