Las funciones de un arquitecto

En este artículo de "coding the architecture" se muestran las principales funciones de un arquitecto de aplicaciones o de sistemas en un proyecto de desarrollo de software.
El objetivo es el de asesorar en una entrevista de trabajo o también para identificar áreas de desarrollo en la carrera profesional.
Estos son los puntos a evaluar:

• Arquitectura: definición de arquitectura, arquitectura de sistemas, vista física, vista lógica, principios de arquitectura, seguridad, etc. ¿La has definido o has contribuido a definirla?

• Selección de software: pilas de aplicaciones, bases de datos, librerías, frameworks, estándares tecnológicos, etc. ¿Para un sistema nuevo (greenfield) o para uno existente?

• Selección de infraestructura: sistemas operativos, hardware, redes, sistemas de recuperación, etc. ¿Para un sistema nuevo o para uno existente?

• Requisitos no funcionales: rendimiento, escalabilidad, seguridad, etc. ¿Entrega, justificación o pruebas?

• Liderazgo: liderazgo técnico, responsabilidad y autoridad, dirección de equipos, etc. ¿Lo has realizado o has contribuido?

• Coaching y mentoring: ayuda sobe problemas técnicos, ayuda en la evolución profesional, etc. ¿En el diseño y codificación o en la arquitectura?

• Metodología de proyectos: estructura de proyectos, metodologías (Waterfall, Scrum, RUP, XP...). ¿La has definido o has contribuido?

• Procesos de desarrollo: control de versiones de código fuente, procesos de construcción, integración continua, automatización de pruebas y otros procesos y herramientas de desarrollo. ¿Los has definido o has contribuido?

• Prácticas y estándares: estándares de codificación y libros blancos, selección de herramientas, etc. ¿Los has definido, has contribuido o han sido impuestos?

• Diseño, desarrollo y pruebas: diagramas UML, codificación, pruebas unitarias, etc.

• Experiencia: Conocimiento sobre tecnologías y arquitecturas.
  

• Desarrollo de software y tendencias tecnológicas: Agile, Web 2.0, SOA, lightweight Java EE, etc. ¿Estás al día, opiniones?

¿Cuál tienes que mejorar?

Metodología SCRUM

Ya sabemos que SCRUM es una metodología para el desarrollo ágil de productos, aplicada sobre todo al desarrollo de software, en la que se pone de manifiesto que:

• El mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.
• Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.
• El mercado exige ciclos de desarrollo más cortos.
  

Algunos recursos relacionados muy buenos:

• Un artículo sobre las reglas del SCRUM (I), (II), (III) y (IV) en geeks.ms.
• SCRUM en 5 minutos (en inglés) en Softhouse.
• Herramienta Excel para SCRUM y el libro (pdf) "Flexibilidad con SCRUM" en Navegapolis.
• SCRUM checklists para imprimir (pdf, en ingés) en InfoQ (hay que registrarse para descargarlo, aunque el pdf gratuito no deja imprimir).

20/1/2008:

• Herramienta Excel para evaluar riesgos antes de empezar, también en Navegapolis.

¿Algún otro recurso interesante?

Gestión del tiempo GTD con GMail

A continuación se muestra un resumen de cómo podemos gestionar nuestro tiempo con GMail basándonos en el método Getting Things Done (GTD) de David Allen.

El objetivo es poder liberar a la mente del trabajo de organización, permitiéndonos la concentración en la realización de las tareas y disminuyendo nuestra saturación y dejadez.

El motivo de usar GMail es que es fácilmente accesible, fácilmente automatizable, cuenta con una búsqueda potente y es gratis. Aunque lo mismo podría hacerse con otros programas de correo u otros dispositivos.

Estos son los principios de funcionamiento:

Recolectar
Cada tarea que necesitemos seguir, recordar o realizar podemos enviarla a nuestra propia dirección de correo en GMail. Este envío puede realizarse desde el mismo GMail o desde otro medio que dispongamos en ese momento (una PDA, etc.).
Los correos que nos envían otras personas serán tratados también como tareas.
Así todas las tareas quedan pendientes de procesar en la bandeja de entrada.

Procesar y organizar
Las tareas se organizarán en GMail con "etiquetas" y con la marca de "destacado" (en forma de estrella), de la siguiente manera:

• Eiquetas de estado:
  
• "pospuesta" - A realizar en un tiempo.
  
• "en espera" - En espera de alguién o de que ocurra algo.
  
• "algún día" - A realizar algún día, ya que no es posible actualmente.
  

• Etiquetas de contexto: empezando siempre con admiración (!), para diferenciarlas de otras etiquetas.
  
• !casa
• !trabajo
• etc.
  

• Proyectos: si una tarea requiere varias acciones para llevarla a cabo, se crearán tantas tareas como acciones a realizar, clasificándolas con una de estas dos etiquetas para cada proyecto (con un asterisco (*) para diferenciarlas):
• *proyecto1:pendiente
• *proyecto1:realizado
  

• Acciones próximas: cada proyecto tiene múltiples acciones, pero sólo una es la acción a realizar próximamente. Esa tarea se marcará como "destacada" (símbolo de estrella amarilla).
  

Con esta organización, cada tarea que aparezca en la bandeja de entrada la procesaremos con las etiquetas correspondientes.
Si la tarea se puede realizar en menos de 2 minutos es mejor realizarla directamente, en vez de procesarla.
Finalmente, la bandeja de entrada debe quedar totalmente procesada, es decir, con las tareas etiquetadas y marcadas.

Revisar y hacer
La revisión debe llevarse a cabo periódicamente:

• Las tareas a realizar próximamente, marcadas como "destacadas" (símbolo de estrella).
• Las tareas pendientes de cada proyecto, mediante la etiqueta correspodiente (*proyecto1:pendiente).
• Las listas de tareas pospuestas, en espera o a realizar algún día.
• Se puede filtrar por un contexto concreto.
  

Cuando una tarea se realiza, se añaden y eliminan las etiquetas que correspondan y se cambia la marca de "tarea a realizar próximamente".

---

Vía Getting Things Done with Gmail.
Ver también Organízate con eficacia y GTD en el móvil de navegapolis.com.

---

17/09/2007:
En este artículo de la web de David Allen se presentan algunas facilidades:

• Se crea un contacto para cada etiqueta que tengamos, en la forma: tucorreo+etiqueta@gmail.com, de manera que puedan enviarse correos a esas direcciones, que realmente son una ampliación de tu dirección real: tucorreo@gmail.com. Es decir, todos los correos que se envíen a estas direcciones los recibirás en tu cuenta sin tener que hacer nada más.
  
• Se crea un filtro para cada una de estos contactos, de forma que cada correo recibido se archive (no aparecerá en la bandeja de entrada) y etiquete automáticamente.

Así se automatiza parte del proceso.

(Gracias, Jeroen Sangers).

Objetivos de una planificación de proyecto

Todas las planificaciones tienen al menos 3 objetivos:

• Establecer compromisos sobre quién y cuándo debe realizar una determinada actividad. Es como hacer una especie de contrato entre cada persona y el resto del equipo. A menudo sirve también para llegar a un acuerdo con un cliente externo al equipo.

• Fomentar la contribución de todo el equipo, de forma que todo el esfuerzo sea visto como un proyecto común, donde cada participante puede ver su contribución personal. Sirve además para dejar claro que:
  
• Cada persona realiza unas piezas que deben encajar con el resto de piezas del puzzle.
  
• La forma en que cada persona realice una tarea afectará al trabajo del resto de personas del equipo.
  

• Proporcionar al equipo una herramienta para dividir el trabajo en distintas tareas, de forma que además se pueda realizar el seguimiento de su progreso. Es importante elegir bien la granularidad de estas tareas: no deben ser ni muy grandes ni demasiado pequeñas.

Con esto, aunque las planificaciones no resuelven ni ayudan a remediar muchos de los problemas de un proyecto, constituyen una herramienta básica para su gestión, tanto más cuando mayor sea el proyecto.

Menos desarrolladores, pero más expertos

¿Es mejor contratar a menos desarrolladores, pero más expertos?
A continuación se exponen algunos motivos a favor y en contra, desde el punto de vista de la empresa.

Inconvenientes:

• Será necesario invertir más tiempo en el proceso de selección de estos desarrolladores.

• El trabajo aburrido (cuando lo haya) aburrirá más aún a las personas más preparadas.

• Cuando una de estas personas abandona la compañía existirá un mayor sentimiento de riesgo. Aunque esto es en realidad una percepción, ya que los buenos desarrolladores crean un código más legible y mantenible y documentan mejor su trabajo.

Ventajas:

• Cada desarrollador estará más satisfecho, en parte porque tendrán un mayor salario, pero también porque tendrán compañeros mucho más preparados.

• El desarrollo requerirá menos coordinación, al haber menos personas.

• Será más fácil captar a otros expertos, ya que suelen moverse en los mismos círculos sociales.

• Se ahorrarán costes comunes (departamento de RRHH, etc) y de infraestructura (espacio, ordenadores, luz, etc), al haber menos personas.

• Incluso se ahorrarán costes salariales, ya que el sueldo de un experto no es, ni de lejos, proporcional a su productividad. También se ahorrarán otros costes no salariales relacionados con los beneficios sociales que la compañía esté otorgando (tickets de comida, seguros médicos, etc).

¿Otras ventajas o inconvenientes?

Ideas extraidas de A Guide to Hiring Programmers: The High Cost of Low Quality.

Las virtudes del programador: pereza, impaciencia y orgullo

• PEREZA: La cualidad que te hace esforzarte para reducir el gasto de energía total. Te hace escribir programas de ayuda al trabajo que otros encontrarán útiles, y documentar lo que escribiste para no tener que responder a preguntas sobre ello. Esta es la primera gran virtud de un programador.

• IMPACIENCIA: La cólera que sientes cuando el ordenador está holgazaneando. Te hace escribir programas que no solo reaccionan a tus necesidades, si no que se anticipan a ellas. O al menos que simulan hacerlo. Esta es la segunda gran virtud de un programador.

• ORGULLO DESMEDIDO: Orgullo excesivo, el tipo de actitud por la que Zeus te fulminaría. También, la cualidad que te hace escribir (y mantener) programas que nadie querrá criticar. Esta es la tercera gran virtud de un programador.

Traducción realizada en el blog "más que código" (Creative Commons).

Y es que claro... somos tan perezosos que nos esforzamos para trabajar menos, tan impacientes que trabajamos con total serenidad para hacer un trabajo perfecto sin perder tiempo, y tan orgullosos que no nos cansamos de reconocer públicamente nuestra humildad...

Diez desarrolladores por el precio de uno

Según se comenta en este artículo, la diferencia de productividad entre programadores es tanta que suelen encontrarase relaciones de hasta 10 a 1. Hay estudios que hablan incluso de relaciones 28 a 1.

¿Cómo es posible? ¿Se trata de la capacidad de la persona, de su formación, de sus años de experiencia...?

Estos son los principales motivos: COMUNICACIÓN Y BUENAS COSTUMBRES.

• A veces se pierde bastante tiempo simplemente intentando comprender los requisitos, en vez de comunicarlo a su coordinador para aclararlos.
• Otras veces es porque se requiere un seguimiento contínuo por parte del coordinador, para asegurarse de que está progresando e incluso para resolver los problemas que puedan surgir.
• La introducción de errores en el código, casos no implementados y la falta de calidad del mismo, ocasionará siempre una perdida de tiempo posterior.
• El código debe ser fácil de mantener: comentado, fácil de entender por otras personas, y con mecanismos de traza adecuados.
• No emplear gran cantidad de código para algo que se puede hacer con mucho menos.
• Reutilizar desarrollos ya existentes.
• Para resolver problemas, que pueden haber resuelto otras personas, consultar las fuentes de información disponibles: foros, compañeros, etc.

Sí, son todos motivos bastante evidentes, pero... ¿se llevan realmente a cabo?

NOTA: si estás pensando en pedir un aumento de sueldo... a ver cómo pides que te lo multipliquen por diez!!

Ciclo de vida por defecto en Maven (lifecycle)

El ciclo de vida está formado por una secuencia de fases de forma que, para que se ejecute una fase, Maven ejecuta antes todas las fases previas.
Esta es la secuencia de fases del ciclo de vida por defecto (de costrucción, build) :

• validate - valida que el proyecto sea correcto y que toda la información necesaria esté disponible.
• generate-sources - genera el código fuente necesario a incluir en la compilación.
• process-sources - procesa el código fuente, por ejemplo para filtrar valores.
• generate-resources - genera los recursos a incluir en el paquete.
• process-resources - copia y procesa los recursos en el directorio de destino, preparados para su empaquetado.
• compile - compila el código fuente del proyecto.
• process-classes - post-procesamiento de los ficheros generados de la compilación, por ejemplo para hacer mejora de bytecodes en las clases Java.
• generate-test-sources - genera el código fuente de las clases de prueba necesarias.
• process-test-sources - procesa el código fuente de las clases de prueba, por ejemplo para filtrar valores.
• generate-test-resources - crea recursos para las pruebas.
• process-test-resources - copia y procesa los recursos en el directorio de destino de las pruebas.
• test-compile - compila las clases de prueba en el directorio de destino.
• test - ejecuta las pruebas usando el framework adecuado. Estas prebas no deben requerir que el código esté empaquetado y desplegado.
• prepare-package - realiza las operaciones necesarias para preparar el paquete antes del empaquetado propiamente dicho.
• package - toma el código compilado y lo empaqueta en su formato a distribuir, como puede ser un JAR.
• pre-integration-test - realiza las acciones requeridas antes de ejecutar las pruebas de integración, como puede ser la configuración del entorno necesario.
• integration-test - procesa y despliega el paquete, si es necesario, en el entorno donde se van a ejecutar las pruebas de integración.
• post-integration-test - realiza las acciones requeridas, después de que las pruebas de integración se hayan ejecutado, como puede ser la limpieza del entorno.
• verify - ejecuta los chequeos necesarios para verificar que el paquete cumple los criterios de calidad.
• install - instala el paquete en el repositorio local, para su uso como dependencias de otros proyectos locales.
• deploy - copia el paquete final al repositorio remoto, a compartir con otros desarrolladores y proyectos.

Otro ciclo de vida estándar es el de limplieza (clean), con las siguientes fases:

• pre-clean
• clean
• post-clean

Y otro es el de creación del sitio (site) de documentación e informes sobre el proyecto:

• pre-site
• site - genera el sitio y los reports
• post-site
• site-deploy - despliega el sitio en un servidor remoto

Los objetivos (goals) concretos que estén unidos a cada fase dependen, por defecto, del tipo de empaquetamiento del proyecto. Por ejemplo:

jar
Es el tipo de empaquetamiento por defecto y el más común.

• process-resources - resources:resources
• compile - compiler:compile
• process-test-resources - resources:testResources
• test-compile - compiler:testCompile
• test - surefire:test
• package - jar:jar
• install - install:install
• deploy - deploy:deploy

pom
Es el tipo de empaquetamiento más simple. El artefacto generado es él mismo.

• package - site:attach-descriptor
• install - install:install
• deploy - deploy:deploy

war
Es un tipo similar al jar, con la diferencia del objetivo (goal) war:war. Nótese que este plugin requiere un fichero web.xml de configuración de aplicación web.

• process-resources - resources:resources
• compile - compiler:compile
• process-test-resources - resources:testResources
• test-compile - compiler:testCompile
• test - surefire:test
• package - war:war
• install - install:install
• deploy - deploy:deploy

ear
Consiste en el despliegue de un fichero descriptor (application.xml), algunos recursos y algunos módulos.
El plugin ear ofrece la posibilidad de ejecutar el objetivo (goal) ear:generate-applicationxml, para generar el descriptor si se desea.

• generate-resources - ear:generate-application-xml
• process-resources - resources:resources
• package - ear:ear
• install - install:install
• deploy - deploy:deploy

Por último, comentar que estas son las formas de manipular el ciclo de vida de construcción:

• En función del tipo de empaquetado, se utilizará su ciclo de vida por defecto.
• Uniendo un objetivo (goal) a una fase, manualmente en el POM.
  
• Uniendo un objetivo (goal) a una fase por defecto, en la definición del Mojo. Los Mojos son objetos planos Java (POJOs, Plain Old Java Objects) pero para Maven. Un Mojo es un objeto que implementa un objetivo (goal) que puede ser ejecutado.
• Creando un ciclo de vida bifurcado y ejecutándolo en un Mojo.
  
• Creando un nuevo tipo de empaquetado, sobrescribiendo su ciclo de vida por defecto.

Ver los plugins disponiles: http://maven.apache.org/plugins.

Project Object Model (POM) de Maven

Un fichero POM de Maven contiene toda la información necesaria de un proyecto y de la configuración de los plugins a usar durante el proceso de construcción. Es decir, es la especificación declarativa del "quién", "qué" y "dónde", mientras que el ciclo de vida es el "cuándo" y el"cómo". Aunque el POM puede afectar al propio flujo del ciclo de vida.

Estos son los elementos que pueden definirse en un fichero POM (se ha considerado la versión 4.4.0, la única soportada actualmente en Maven 2). Los elementos optativos que no se declaren se heredarán de la configuración estándar por defecto de Maven (Super POM).

<project>
<modelVersion>4.0.0</modelVersion>

<!-- Los básicos -->
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<packaging>...</packaging>
<dependencies>...</dependencies>
<parent>...</parent>
<dependencyManagement>...</dependencyManagement>
<modules>...</modules>
<properties>...</properties>

<!-- Configuración de construcción -->
<build>...</build>
<reporting>...</reporting>

<!-- Otra información del proyecto -->
<name>...</name>
<description>...</description>
<url>...</url>
<inceptionYear>...</inceptionYear>
<licenses>...</licenses>
<organization>...</organization>
<developers>...</developers>
<contributors>...</contributors>

<!-- Configuración de entorno -->
<issueManagement>...</issueManagement>
<ciManagement>...</ciManagement>
<mailingLists>...</mailingLists>
<scm>...</scm>
<prerequisites>...</prerequisites>
<repositories>...</repositories>
<pluginRepositories>...</pluginRepositories>
<distributionManagement>...</distributionManagement>
<profiles>...</profiles>

</project>

groupId, artifactId y version
Son las coordenadas (espacial y temporal) de un proyecto en un repositorio Maven. Uno es el nombre del grupo de proyectos (p.e. org.apache.maven), otro es el del proyecto (p.e. mi-proyecto) y el último es la versión (p.e. 1.1).

packaging
Es el tipode artefacto que se genera en el proyecto (p.e. jar (por defecto), war, etc).

dependencies
Recoge las dependencias con otros proyectos durante la construcción o ejecución. Entre otras cosas sirven para que Maven los descargue y los incluya automáticamente cuando corresponda.

<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
<type>jar</type>
<scope>test</scope>
<classifier>memory</classifier>
<optional>true</optional>
</dependency>
...
</dependencies>

parent
Para indicar el proyecto padre del que heredar sus características. Están características podrán matizarse en el proyecto actual. Si no se indica, se considera que se hereda del Super POM, la configuración de proyecto estándar de Maven.

dependencyManagement
Es usado por un POM padre para definir propiedades sobre dependencias de los hijos, de forma que sean declaradas únicamente en un sitio.

modules
Para declarar los módulos que componen un proyecto, en el caso de que sea multi-módulo. Cada uno de estos módulos será a su vez otro proyecto Maven ubicado directamente en el proyecto principal.
NOTA: El hecho de que un proyecto seamulti-módulo (modules) es totalmente independiente de que exista herencia entre ellos (parent).

properties
Propiedades que pueden definirse, de forma que puedan ser usadas en el resto de la configuración del proyecto en la forma: ${propiedad}.

build
En estos elementos se declara, entre otras cosas, la estructura de directorios del proyecto:

<build>
<sourceDirectory>${basedir}/src/main/java</sourceDirectory>
<scriptSourceDirectory>${basedir}/src/main/scripts</scriptSourceDirectory>
<testSourceDirectory>${basedir}/src/test/java</testSourceDirectory>
<outputDirectory>${basedir}/target/classes</outputDirectory>
<testOutputDirectory>${basedir}/target/test-classes</testOutputDirectory>
...
</build>

La fase u objetivo a ejecutar por defecto, el directorio de construcción, nombre del producto final y ficheros de propiedades a usar:

<build>
<defaultGoal>install</defaultGoal>
<directory>${basedir}/target</directory>
<finalName>${artifactId}-${version}</finalName>
<filters>
<filter>filters/filter1.properties</filter>
</filters>
...
</build>

Se declara la ubicación de los archivos de recursos:

<build>
...
<resources>
<resource>
<targetPath>META-INF/plexus</targetPath>
<filtering>false</filtering>
<directory>${basedir}/src/main/plexus</directory>
<includes>
<include>configuration.xml</include>
</includes>
<excludes>
<exclude>**/*.properties</exclude>
</excludes>
</resource>
</resources>
<testResources>
...
</testResources>
...
</build>

Los plugins, indicando si cargar las extensiones de cada plugin, si la configuración es heredable por proyectos hijos, y la propia configuración de cada plugin, dependencias y objetivos a ejecutar.

<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>echodir</id>
<goals>
<goal>run</goal>
</goals>
<phase>verify</phase>
<inherited>false</inherited>
<configuration>
<tasks>
<echo>Build Dir: ${project.build.directory}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

La gestión de plugins:

<build>
...
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<id>pre-process-classes</id>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>pre-process</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
...
</build>

Y las extensiones: otros artefactos a activar durante la construcción.

<project>
<build>
...
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-alpha-3</version>
</extension>
</extensions>
...
</build>
</project>

Recursos sobre Maven

Maven (http://maven.apache.org)

Maven es un frameworc para la gestión de un proyecto software. Propone un modelo de proyecto y herramientas para su gestión, todo configurable de forma declarativa y ampliable mediante plugins. De esta forma, pueden aprovecharse las mejores prácticas en gestión de proyectos.

Las principales ideas que aporta son:

• Una convención sobre la configuración. Propone una estructura estándar para los proyectos, con denominaciones estándar. En cualquier caso pueden adaptarse si es necesario. En Maven, cada proyecto produce una única salida (fichero JAR, WAR, etc).
  
• Reutilización de la lógica de construcción. Mediante plugins. Existen multitud de plugins para compilación, ejecución de pruebas, empaquetado, generación de JavaDocs, instalación, despliegue, etc., que pueden configurarse, o bien pueden desarrollarse nuevos plugins.
  
• Ejecución declarativa. En Maven todo se configura mediante ficheros POM (Project Object Model). Los proyectos heredan de un proyecto estándar, sobre el que pueden particularizarse ciertos aspectos. Pueden definirse herencias entre proyectos. Maven define un ciclo de vida estándar, que también puede particularizarse.
  
• Organización coherente de las dependencias. Gestiona la dependencia entre artefactos generados y artefactos externos.
  

Wiki oficial: http://docs.codehaus.org/display/MAVENUSER/Home

Guías de usuario de Maven:

http://www.sonatype.com/book/maven-user-guide.pdf

http://www.devzuz.com/c/document_library/get_file?folderId=8&name=DLFE-38.pdf

Integración con IDEs:

• JDeveloper: http://www.oracle.com/technology/products/jdev/howtos/1013/maven/maven.html
• Eclipse: http://m2eclipse.codehaus.org

Una presentación sobre Maven:
http://www.manuelrecena.com/docs/maven_061106.pdf

Introducción a Maven y comparación con Ant:

http://metaware-inc.wiki.mailxmail.com/AntMaven

Otra wiki, en español, con información sobre Maven, más un artículo sobre primeros pasos con Maven:

http://www.chuidiang.com/chuwiki/index.php?title=Categor%C3%ADa:Maven

http://www.chuidiang.com/java/herramientas/maven.php

Errores frecuentes en el desarrollo de un sistema de información

Estos son algunos errores bastante comunes que suelen llevar al fracaso en el desarrollo de un sistema de información.

• Cambiarlo todo para que todo siga igual

No hay que limitarse a la automatización de las tareas que antes se realizaban manualmente, ni a un simple cambio de interfaz para las funciones que ya estuvieran sistematizadas. Hay que ver también la oportunidad para rediseñar y optimizar los procesos subyacentes.

• No entender bien los requisitos de los usuarios previamente a la implementación

Es importante que los requisitos queden bien especificados desde el principio, para evitar conflictos entre los intereses de los distintos tipos de usuarios y los de la organización, que pueden verse agravados por las diferencias de lenguaje. Y estos son precisamente los motivos que hacen que esta fase de especificación de requisitos inicial sea algo incomoda de realizar.

• No resolver problemas organizativos cuanto antes

Hay que resolver, a nivel directivo y cuanto antes, las diferencias entre distintas partes de la organización, pues con el tiempo suelen agravarse.

• Externalizar a ciegas los desarrollos

Es necesario hacer un seguimiento técnico exhaustivo al proveedor del desarrollo.

• No verificar prototipos ni realizar pruebas piloto antes del paso a explotación

Algunos atajos terminan convirtiéndose en caminos más difíciles para lograr los objetivos.

Es bastante común que se den algunas de estas circunstancias en un proyecto, pero cuando se dan varias a la vez será mayor la probabilidad de fracaso.

Estos fracasos pueden tener distintas formas y diversas consecuencias. A veces toman la forma de una sucesión de pequeños desastres, difíciles de medir, pero no por ello menos reales.

El método científico de la toma de decisiones

Estos son los pasos a seguir para resolver un problema que implique la toma de decisiones.

No se trata de una secuencia rígida a seguir sino de una serie de requisitos lógicos a cumplir, en algún momento y en cierto grado.

Debe combinarse adecuadamente el rigor del método con la espontaneidad de la persona, es decir, la ciencia con la creatividad.

Diagnóstico

Se trata de una etapa espontánea de recogida de información y de otras etapas rigurosas de clasificación de dicha información y de definición del problema.

- La información a recoger es aquella que nos parezca relevante en principio. También en función del tiempo disponible y de su coste.

- Filtrar y relacionar esa información.

- Es importante distinguir hechos de jucios y opiniones.

- Analizar rigurosamente el problema, diseccionándolo convenientemente.

- Atender a los problemas más que a los síntomas.

- Identificar bien las relaciones entre las distintas variables.

Formulación de alternativas

Proceso espontáneo en el que se enumeran las posibles alternativas, sin entrar a valorarlas.

Criterios de valoración

Etapas rigurosas donde se formulan los criterios de valoración, para no tomar las decisiones por impulso o por corazonada, definiéndolos independientemente del objetivo final. Y se valoran las distintas alternativas.

- Priorizar bien.

- Ser coherente.

- Además de los criterios racionales y objetivos, tener en cuenta las querencias de las personas.

Decisión

Tomar la decisión.

- Decidir con prudencia: metidos en la realidad y previendo las consecuencias. No como limitante o temerosa sino llevando a la acción.

- Sagacidad: hacer lo que hay que hacer en el momento en el que hay que hacerlo.

Plan de acción

Llevar a cabo el plan de acción diseñado.