Desarrollo de Software. CMMI (Capability Maturity Model Integration). Nivel 1: Inicial

El nivel 1 de CMMI se considera nivel inicial porque hace referencia a la ausencia de procesos o en el caso de que existan a la ausencia de control, seguimiento y/o cumplimiento de los mismos.

Una organización dedicada al desarrollo de software que se encuentre en este nivel se entiende que no tiene un control real sobre los proyectos en los que está trabajando: no se conoce realmente el grado de ejecución de los mismos, no hay control de plazos, no hay control de los costes económicos, no existe una motivación para la toma de determinadas decisiones, etc…

Estamos ante una situación en la que cada proyecto es quien maneja las riendas y no la organización quien las lleva, por tanto, si ya es complicado intentar conseguir un comportamiento predecible en un proyecto de desarrollo de software, todavía lo es más cuando no existe un control sobre el mismo y predomina la reacción ante las circunstancias que van aconteciendo a la acción.

Este nivel se caracteriza, por tanto, por el comportamiento impredecible de los proyectos por la ausencia de procesos definidos o por el no cumplimiento de los mismos (que viene a ser lo mismo) de manera que cada equipo de proyecto o incluso cada desarrollador sigue su propia estrategia o metodología, como una decisión personal o de grupo, pero no siguiendo unas directrices a nivel organizativo.

11 comentarios
    • jummp dijo:

      Muy buena definición.

  1. Ricardo dijo:

    Y así es como funciona la mayoría de las empresas en este gran país. Lógico que la calidad de los proyectos y empresas sea tan mala.

    Por cierto, Jummp, ¿qué opinas de que, para tener un mínimo de madurez, el nivel 2, haya que gestionar los requisitos (y su trazabilidad) y en cambio en XP (y similares) no se contempla la trazabilidad de requisitos?
    Lo pregunto porque para mí la trazabilidad es básica para mantener y evolucionar sistemas, y muy especialmente por aquellos que no programaron directamente el sistema, como que sí o sí ocurrirá.

    Saludos.

  2. Johann dijo:

    la trzabilidad es indispensable en los desarrollos.
    XP analiza los requisitos en cada fase. Analiza los requisitos de la fase, y por lo tanto se indica que requisitos están en cada timebox y en cada release (y por lo tanto está en la documentación, aunque sea informal).

    Quizás no sea de los más exahustivo, pero al menos es algo y no estamos en CMMi 1 :))

  3. Ricardo dijo:

    ¿Puedes en XP coger un método, variable o clase totalmente aleatoria y trazarlo al requisito que representa? No me suena a mí eso, pero puede que me equivoque.

  4. Johann dijo:

    desde mi punto de vista, eso no da valor añadido al desarrollo de proyectos.
    Al revés, por supuesto. Pero del código a los requisitos, no lo veo claro.
    Como BP lo veo bien, pero ya está.

    • Ricardo dijo:

      ¿A qué te refieres con lo que no da valor?
      Si te refieres a la trazabilidad, para mantener un proyecto a largo plazo es indispensable. El mismo cmmi así lo dice.

      ¿Qué es BP?

      • jummp dijo:

        Como he expresado en el artículo dedicado a la gestión de requisitos en el nivel 2 de CMMI, lo importante es quedarse con el espíritu de lo que se pretende: análisis de impacto y análisis de inconsistencia, más que tratar la trazabilidad de requisitos al pie de la letra. Lo importante es trabajar de manera que realizar esos análisis sea posible y en un tiempo razonable.

        El caso de XP que comentas, se podría llegar al nivel que se quisiera, independientemente de que como toda metodología ágil anteponga que el producto funcione al proceso (sin considerar que el proceso no es importante), pero por su propia naturaleza de funcionamiento requiere una agilidad en el trabajo que una trazabilidad de requisitos al pie de la letra no le permitiría obtener, sin embargo sí que entiendo que es posible hacer los análisis indicados en un tiempo razonable (proporcional al tamaño y complejidad del proyecto).

Deja un comentario