Complejidad Ciclomática

Acabo de terminar de leer “La lógica oculta de la vida” de Tim Harford, autor de “El economista camuflado“. Se trata de otro libro que hace hincapié en la racionalidad de todas las cosas que suceden a diario en la vida de los humanos.

En los diferentes capítulos del libro se enumeran múltiples experimentos que intentan demostrar la racionalidad del racismo, delincuencia etc.. cayendo en mi opinión, en simplificaciones ridículas.

Por otra parte caben destacar los capítulos dedicados a la teoría de juegos y a la explicación de porque Malthus estaba equivocado. Pero sin dudas, el capítulo dedicado a las grandes ciudades como centros de innovación me ha resultado muy interesante.

El autor explica porqué las grandes ciudades son más prosperas que las pequeñas, de la realidad de que las ciudades donde hay empresas de diferentes sectores son más innovadoras frente aquellas que son importantes en un solo sector.(Seattle (Microsoft y Starbucks) frente a Detroit (Motor)).

Un libro ameno que no contiene grandes ideas pero interesante para este verano.

Lo único que aporta valor al cliente es el software que funciona, no los ppts ni la documentación.

Rodrigo Corral, en el curso de gestión de proyectos al que asisto en estos días.

Estoy leyendo “La lógica oculta de la vida” de Tim Harford y hay un capítulo dedicado a la Teoría de juegos de Von Neumann. Este señor, John von Neumann , aparece mucho en los temarios de Ingeniería Informática ya que es responsable de la arquitectura de computadores con su nombre, del algoritmo de ordenación mergesort, etc..

Esto me ha hecho pensar sobre lo poco conocidas que las figuras célebres en la informática por la sociedad; es más se identifican como tales a empresarios ( Bill Gates, Steve Jobs etc..) Por ello voy a listar algunos nombres que todo el mundo debería identificar:

1. Alan Turing: I.A. , Algoritmia, criptografía etc..
   
2. Edsger Dijkstra: Algoritma.
3. John Von Neumann: Algoritmia, Arquitectura…
4. Donald Knuth: Programación, algoritmia..
5. Dennis Ritchie: Desarrollo de UNIX y C.
6. John Eckert: Arquitectura de computadores.
7. George Boole: Álgebra booleana.
8. Charles Babbage: Idea de computadora.

Frase de la semana:

Si no me dejas decidir luego no esperes demasiado compromiso por mi parte.

De Julen Iturbe, a quien conocí en Blogak.  A través de Consultor Anónimo.

Como escribía el otro día a horas tardías, la gestión y planificación de proyectos informáticos es una tarea difícil y que en muchas ocasiones roza la adivinación.

El principal problema de la creación de sistemas de información radica en que los requisitos funcionales que debe cumplir son transmitidos por los usuarios. A diferencia del resto de las ingenierías que tienen parámetros, medidas y limitaciones impuestas por la realidad y por tanto objetivas; el desarrollo de sistemas de información establece el modelado de la realidad a través de la comunicación humana ( y desgraciadamente la comunicación humana dista mucho de ser perfecta). Siempre se ha dicho que lo que un cliente piensa es diferente de lo que verbaliza, bastante diferente de lo que el analista escucha y muy lejano de lo que finalmente este anota.

Junto con esta primera y gran dificultad, nos encontramos que generalmente se realizan proyectos a medida (hoy una aplicación de representación de información en tiempo real, mañana un B2C etc…) por lo que es difícil obtener métricas para aplicar a proyectos posteriores. Por otra parte y aunque parezca mentira, la decisión de los tiempos y costes no se realiza en función de criterios técnicos, sino de mercado. Los gerentes (esos que piensan que los problemas de rendimiento se solucionan comprando mejor hardware) y los comerciales son los que generalmente deciden cuanto debe costar un proyecto. - y por tanto en cuanto tiempo se debe realizar-.

Con estas 3 dificultades: 1. Dificultad  de comunicación de requisitos 2. Dificultad en la aplicación de la experiencia previa y 3. Falta de criterios técnicos en muchas fases. ¿ Cómo es posible llevar buen puerto el desarrollo de sistemas informáticos?. Respuesta: No se puede.( Menos de 1 de cada 3 proyectos informáticos terminan con éxito).

¿Qué se puede hacer?

Establecer metodologías apropiadas a la organización que controlen el riesgo de los puntos anteriores. Existen dos aproximaciones a la gestión y planificación de proyectos:

1. Metodologías orientadas a procesos predictivos
2. Metodologías ágiles

En próximos post entraré en detalle en cada una de las metodologías.

Si hoy tuviera que volver a realizar el proyecto fin de carrera y con la experiencia de casi 2 años en el sector TIC, estudiaría más a fondo la gestión de proyectos informáticos.

Todas las etapas de gestión en este tipo de proyectos son muy complejas por motivos que comentaré en próximos post - espero-. Pero en este me voy a centrar en la etapa inicial; donde  se estima el alcance del proyecto para realizar un presupuesto.

En el entorno en el que me muevo, la cosa va de la siguiente forma: un gerente y un comercial se reunen una hora con el posible cliente y no tengo muy claro de lo que hablan. Tras la reunión se genera un documento con cajas que representan módulos del sistema y se pasa la oferta - que en el mejor de los casos se ha aplicado un porcentaje de riesgo-.El cliente acepta.Todos contentos ¿Qué sucede después? Tras la generalmente escasa etapa de análisis, se determina que el proyecto tiene un 50% de horas más de lo presupuestado. ¿Cómo se resuelve?  El personal haciendo horas extras y el sistema con un recorte funcional tremendo.

La alternativa ideal, en mi opiníon, sería realizar un análisis (cobrado al cliente) y con él realizar la estimación de diseño, implementación, pruebas etc.. Lamentablemente, los clientes en mi entorno no están preparados para que se les cobre un análisis del que van a obtener un documento. (Aunque haciéndolo así se reduce treméndamente la incertidumbre en el desarrollo).

La solución intermedia sería realizar 2 o 3 reuniones con presencia de personal técnico. De esta manera se alcanzaría una solución de compromiso. El coste de las reuniones se incluiría en el presupuesto.

Algún lector tiene alternativas para solucionar la problematica de la estimación de los proyectos informáticos (cuando no puede existir un análisis previo).

NOTA: He re-leido el post y creo que lo voy a re escribir este fin de semana. Las 1.34 pm no es buena hora.

Nada más que añadir

Hacía mucho meses que no terminaba un libro debido a que el trabajo me tiene bastante ocupado. (El blog es un reflejo de esta situación). No obstante hoy he terminado “Descubre el economista que llevas dentro” .(Tyler Cowen en Planeta).

El libro reflexiona sobre las motivaciones que tenemos las personas al realizar tareas y en función de ellas se determina cueles serían los mejores incentivos. Es muy interesante como se explica que acciones en principio beneficiosas no lo son; se pone el ejemplo de como si todos dejaramos generosas propinas a los camareros, los dueños de los restaurantes bajarían los sueldos “para equilibrar” y el beneficio les repercutiría a ellos.

En definitiva un libro que sigue la estela de Freakconomics y el genial “El economista camuflado” aunque quizás con menos frescura.

Ahora tengo que decidirme entre  “La lógica  oculta de la vida“  y “Conectados“…

Justice - Cross (edición japonesa), comprado en París.