101 formas de saber que vuestro proyecto software está condenado al fracaso

(13)

Aquí tenéis algunas de las que más me han gustado en castellano. El resto lo podéis leer en inglés en Codesqueeze.

  • Tu jefe podría ser sustituido por un script de redirección de correo
  • Los jefes han renombrado el modelo de ciclo de vida en Cascada a Cascada Ágil
  • Comenzais a contratar consultores para poder culparlos
  • Los requisitos están escritos en una servilleta
  • Cada reunión de control comienza con la frase "¿Quieres las buenas noticias o las malas?"
  • Vuestro sistema de control de versiones consiste en una serie de carpetas en un disco compartido
  • El desarrollador web piensa que la X de XHTML viene de eXtremo.
  • Los desarrolladores utilizan el bloc de notas como IDE
  • Tu jefe se pasa la hora de la comida llorando en el coche (basado en hechos reales)
  • Los de ventas disminuyen tus estimaciones porque piensan que puedes trabajar más rápido
  • Los del turno de noche de Starbucks te conocen por tu nombre
  • Consideras romperte los dedos para obtener una baja
  • Empiezas a plantearte si trabajar dos turnos en el Pizza Hut será una mejor alternativa laboral
  • Los de la grua se llevan tu coche del aparcamiento porque pensaban que lo habías abandonado
  • "Ah, si, casi me olvidaba. Ehh, voy a necesitar que vengais el Domingo también… gracias"

Ingenieros de software de la antigua Roma

(9)

Cuando los ingenieros romanos terminaban un puente debían colocarse debajo de este mientras la primera legión lo cruzaba. Si los programadores tuvieran que hacer lo mismo hoy en día, es probable que desarrollaran un interés mucho mayor en usar Ada.

-- Robert Dewar (CEO de AdaCore)

El software y las catedrales

(8)

El software y las catedrales se parecen mucho. Primero lo construimos, después rezamos.

-- Anónimo

Revisiones de examenes

(8)

Increíble vídeo de una pequeña obra de teatro en verso que parodia las correcciones de exámenes en la Escuela de Ingenieros de Sevilla.

Correcto es el resultado,
el planteamiento adecuado,
todo está bien explicado,
pero lo siento, ¡no os ha tocado!

Vía

Salidas de la Ingeniería Informática

(12)

Los Ingenieros Informaticos Españoles tienen tres salidas: por Tierra, por Mar y por Aire

-- El profesor, de la hermana, de un usuario de los foros de Noticias3D.

'Programador', no Ingeniero Informático

(94)

Si, soy pro-colegio de informática aunque a muchos les parezca injusto o elitista. Un industrial, un psicólogo, un biólogo,… no puede (en principio) hacer el trabajo de un informático. Así que cuando un informático pide que se contraten informáticos y no químicos en un trabajo de informático no es una nena llorona intentando conseguir el trabajo con trapicheos legales en lugar de por sus aptitudes.

Empecemos por puestos de programador. Lo que aprende un informático en la carrera no es un lenguaje de programación. Cualquiera salido de un curso CCC de 3 meses puede aprender Java y hacer un programa de contabilidad para el carnicero de su barrio. Pero igualmente yo puedo construir una casa para mi perro y no por eso sé arquitectura.

Porque un Ingeniero Informático no se pasa los cinco años de carrera jugando al mus, aunque parece que algunos lo crean; y se verá claramente la diferencia en el momento en que el programa a desarrollar sea medianamente complejo, y tanto mas cuanto mas complejo sea. Un informático ha estudiado patrones de diseño, metodología del desarrollo, programación lógica y funcional, estructuras de datos,… si al compararlo con un programa desarrollado por alguien que solo conoce la sintaxis del lenguaje de programación en cuestión te parecen lo mismo tienes un problema.

Punto fundamental: conocer la sintaxis de un lenguaje de programación no es saber programar. Un niño de cuatro años puede conocer la sintaxis del castellano y saber escribir pero no vas a compararlo con Becquer o García Lorca. Yo llevo programando desde que tenía nueve años y nunca se me ocurriría decir que se programar, aún después de todo lo que he aprendido en la carrera, así que cuando veo los libros del tipo "Aprenda a programar en (introduzca aquí el nombre de su lenguaje preferido) en 21 días" dan ganas de reír.

Pero lo mas grave no es contratar como desarrolladores gente que no sepa programar, lo mas preocupante es tenerlos como analistas o jefes de proyecto, que también los hay. Porque la toma de requisitos, el análisis y el diseño son las partes mas importantes en el proceso de desarrollo de software, no la implementación. Eso es ingeniería del software (arquitectura) y programar es simplemente poner ladrillos. Y por mucho que les duela, alguien que solo conoce la sintaxis de un lenguaje de programación como mucho se le puede llamar programador y no analista (llamarlo programador ya es suficientemente grave) y dedicarse a programar y no a hacer de analista software en sus ratos libres. El simple hecho de programar no te convierte en programador, y mucho menos en un ingeniero, así como un obrero de la construcción no es arquitecto por poner ladrillos, y yo mucho menos por hacer la caseta a mi perro.

Pero lógicamente existe gente que no tiene el título de Ingeniero Informático trabajando en esa clase de puestos y que lo hacen mucho mejor que cualquier Ingeniero Informático. Todos los conocimientos que tienen los Ingenieros Informáticos se pueden obtener por tu cuenta, sin tener un título. Pero ocurre lo mismo en cualquier otra carrera o disciplina. Yo podría estudiar por mi cuenta arquitectura, e incluso ser el Gaudí del nuevo siglo, pero por muy bueno que fuera, el colegio de Arquitectura no me dejaría ejercer como arquitecto.

Nadie pone en duda el que haya gente sin la carrera de Ingeniería Informática que trabajen mucho mejor que los que la tienen. Y por supuesto que el tener un título no certifica que seas mejor en tu trabajo, pero es necesario establecer un filtro aunque sea injusto, porque por cada una de las personas que no tienen el título pero que de verdad es bueno en su trabajo que se contratan, se contratan nueve que no tiene la mas mínima idea.

En definitiva, estoy a favor de que se contrate a gente capacitada tengan su título universitario o no. Pero en una entrevista de trabajo en la que el entrevistador no puede valorar hasta que punto esa persona es buena en su trabajo, es necesario algún filtro, y el menos injusto es el haber estudiado la carrera, que al menos certifica unos conocimientos mínimos. Un colegio como el de Arquitectura o Derecho es el mal menor, y sería mucho mejor que la situación actual.

Lo ideal sería que para colegiarse se tuviera que aprobar un examen de forma que de verdad se demostraran esos conocimientos mínimos, y que a este examen pudiera presentarse gente con la carrera o sin ella. Lógicamente alguien que tenga la carrera tendría mas oportunidades de aprobar, pero no tendría sentido no querer colegiar por ejemplo a Turing por el simple hecho de no haber estudiado la carrera.

Ciclos de vida del software

(36)

Ciclo de vida se refiere al período de tiempo que comienza cuando se concibe la idea de generar el programa hasta que finalmente se retira.

  • Waterfall (en cascada): Se denomina modelo en cascada porque su característica principal es que no se comienza con un paso hasta que no se ha terminado el anterior.

    El principal problema de esta aproximación es el que no podemos esperar el que las especificaciones iniciales sean correctas y completas y que el usuario puede cambiar de opinión sobre una u otra característica. Además los resultados no se pueden ver hasta muy avanzado el proyecto por lo que cualquier cambio debido a un error puede suponer un gran retraso además de un alto coste de desarrollo.

    Como es evidente esto es solo un modelo teórico, si el usuario cambia de opinión en algún aspecto tendremos que volver hacia atrás en el ciclo de vida.

  • Prototipos: Consiste en iterar en la fase de análisis tantas veces como sea necesario, mostrando prototipos al usuario para que pueda indicarnos de forma mas eficiente los requisitos del sistema. La iteración finalizará cuando el usuario de el visto bueno al prototipo.
  • Evolutivo: Se diferencia del modelo por prototipos en que en prototipos se da por hecho que aunque se necesiten varias iteraciones para lograrlo al final se llegará a tener una serie de requisitos completos y sin errores, que no vayan a cambiar más.

    En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del ciclo de vida y no solo en la etapa de análisis.

  • Incremental: Es una aproximación muy parecida a la evolutiva. En este modelo se desarrolla el sistema para satisfacer un subconjunto de los requisitos especificados y en posteriores versiones se incrementa el programa con nuevas funcionalidades que satisfagan mas requisitos.

    En el caso del modelo evolutivo se desarrollaría una nueva versión de todo el sistema, en el incremental se parte de la versión anterior sin cambios y le añadimos las nuevas funciones.

  • En espiral: Toma las ventajas del modelo de desarrollo en cascada y el de prototipos añadiéndole el concepto de análisis de riesgo.

    Se definen cuatro actividades:

    • Planificación, en la que se recolectan los requisitos iniciales o nuevos requisitos a añadir en esta iteración.
    • Análisis de riesgo; basándonos en los requisitos decidimos si somos capaces o no de desarrollar el software y se toma la decisión de continuar o no continuar.
    • Ingeniería, en el que se desarrolla un prototipo basado en los requisitos obtenidos en la fase de planificación.
    • Evaluación del cliente: el cliente comenta el prototipo. Si esta conforme con el se acaba el proceso, si no se añaden los nuevos requisitos en la siguiente iteración.
  • Basada en transformaciones: Derivado del modelo en cascada, en el se considera que partiendo de las especificaciones y gracias a las herramientas CASE estas se transforman en diseño lógico del software, este se transforma en un diseño físico (un diseño dependiente de la tecnología) y éste en el código final.