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.

Information Systems Philosophy: Criterios para tomar la decisión sobre cual modelo de desarrollo de software emplear en un proyecto o ante un determinado problema

¿Es posible saber cómo escoger una metodología de desarrollo ante un proyecto o un problema nuevo? La verdad que es algo complejo pero intentando hacer algo, revisando literatura y conversaciones con colegas, se aisló un conjunto de criterios y sus cuantificadores para poder tener una base que facilite a alguien saber cual metodología de desarrollo es adecuada. Hay que dejar claro que esto no es un acto terminal de investigación, sino simplemente un ejercicio organizador.

Vemos útil este tema para decisores informaticos vinculados a portafolios y carteras de proyectos y por supuesto a gestores de proyectos.

A. Antecedentes

Sin ser exhaustivo, sino simplemente genérico se revisaron los siguientes modelos de desarrollo de software (tanbién citados como paradigmas): Cascada, RAD (Rapid Application Development), Incremental, Prototipado (o por prototipos), Espiral, XP (Extremme Programming), SCRUM, ASD (Adaptive Software Development) y CM (Crystal Methods).

Los criterios identificados para seleccionar estos modelos son:

  • disponibilidad de recursos;
  • complejidad del proyecto;
  • entendimientos de requerimientos;
  • conocimiento del dominio del problema;
  • manejo de la perspectiva de riesgos;
  • tiempos de desarrollo;
  • costo de los proyectos;
  • calidad del software; y,
  • documentación.

Cabe señalar que para cada criterio se definieron cuantificadores o mejor dicho valores cualitativos basados en análisis de otros parámetros, variables o consideraciones que para efectos de este documento no es necesario entrar a describir sino mencionar para efectos de comparación. Es adecuado indicar con énfasis, que los cuantificadores se presentan como sugerencias pues su obtención puede ser un proceso más riguroso o dependiente de cada organización. En este ejercicio, eso sí, se exponen las bases desde las cuales extraer los valores de cuantificación que creemos son los adecuados.

B. Criterios de decisión y sus cuantificadores

Se encuentra a continuación la definición de los criterios más representativos que servirían de referencia en la toma de decisión de adoptar una metodología de desarrollo.

Disponibilidad de recursos: este criterio hace referencia los recursos equipo y materiales calificados en el momento indicado y durante el tiempo requerido. En este criterio, los valores posibles son:

  • Todos (Que la organización ha dispuesto o dispondrá todos los recursos necesarios para la ejecución del proyecto); y,
  • Algunos (Que la organización ha dispuesto o dispondrá algunos de los recursos necesarios para la ejecución del proyecto).

Complejidad del proyecto: este criterio hace referencia al tamaño del sistema y la complejidad del mismo, donde según la complejidad del proyecto aplica o no aplica una metodología específica. Los cuantificadores se han obtenido en base a dos parámetros: (a) en base a un cálculo de complejidad como Puntos de Función o COCOMO u otros; y (b) en base a la experiencia de las personas y de la madurez en los procesos empleados por la organización). En este criterio, los cuantificadores posibles son:

  • Alta (Proyectos de Complejidad Alta),
  • Media (Maneja proyectos de complejidad media); y,
  • Baja (Es recomendable para proyectos de complejidad baja).

Entendimientos de requerimientos: este criterio hace referencia a tener claro los requerimientos del sistema en la etapa inicial del proyecto por parte del analista o diseñador. Los cuantificadores se han obtenido en base a la conjugación de dos cosas: (a) la experiencia del observador; y, (b) el manejo que tenga de las herramientas de descripción). En este criterio, los cuantificadores posibles son:

  • Especifico (Es necesario que el analista o diseñador tengan muy claro todos los requerimientos de forma detallada y especifica al inicio del proyecto); y,
  • Bajo (No es necesario por parte del analista o diseñador el entendimiento de todos los requerimientos al inicio del proyecto).

Conocimiento del dominio del problema: el Conocimiento del dominio del problema se refiere al conocimiento del problema de negocio y su entorno que posee el analista o diseñador antes de revisar una situación o fenómeno. Los cuantificadores se han obtenido en base a la conjugación de dos cosas: (a) el grado de capacitación del observador en el tema; y, (b) la experiencia del observador en casos iguales o similares y/o en proyectos similares o parecidos). En este criterio, los cuantificadores posibles son:

  • Alto (cuyo valor se consigue cuando el observador tiene un completo dominio de todos los factores y procesos que participan del fenómeno en estudio),
  • Regular (cuyo valor se consigue cuando el observador tiene algún dominio de los factores y procesos que participan del fenómeno de estudio); y,
  • Pobre (cuyo valor se consigue cuando el observador tiene poco dominio de todos los factores y procesos que participan del fenómeno en estudio).

Manejo de las perspectivas de riesgos: este criterio hace referencia a tener en cuenta la definición de riesgos y perspectivas de los mismos en alguna de las metodologías tienen en cuenta este criterio. Los cuantificadores se han obtenido en base a la consideración de dos aspectos: (a) en base a instrumentos cuantitativos de medición de riesgos, y (b) en base a la experiencia de las personas y la madurez de la organización en sus procesos de desarrollo. En este criterio, los cuantificadores posibles son

  • No (cuyo valor se consigue cuando el paradigma contempla entre sus fases la definición de perspectivas de riesgo); y,
  • Si (cuyo valor se consigue cuando el paradigma no contempla entre sus etapas la definición de manejo de perspectivas de riesgo).

Tiempos de desarrollo: este criterio hace referencia al tiempo requerido para el desarrollo de proyectos de software utilizando un paradigma particular.Los cuantificadores se han obtenido en base a: (a) instrumentos cuantitativos de medición como Puntos de Función, COCOMO u otros, (b) en la experiencia de las personas y la madurez de la organización en sus procesos de desarrollo. En este criterio, los cuantificadores posibles son:

  • Alto (cuyo valor se consigue cuando los tiempos de desarrollo para ejecutar el proyecto de software son mayores de un año),
  • Medio (cuyo valor se consigue cuando los tiempos de desarrollo para ejecutar el proyecto de software son mayores de entre 6 meses y un año); y,
  • Bajo (cuyo valor se consigue cuando los tiempos de desarrollo para ejecutar el proyecto de software son menos de 6 meses).

Costos de los proyectos: este criterio hace referencia a los costos tangibles e intangibles para poder llevar a cabo proyectos de software. Los cuantificadores se han obtenido en base a. (a) a instrumentos cuantitativos de medición como Puntos de Función, COCOMO u otros, y (b) en la experiencia de las personas y la madurez de la organización en sus procesos de desarrollo. Adicionalmente, los costes deben evaluarse en función de cualitativos como el coste de no-calidad, de la rentabilidad a obtener y la inversión a incurrir en términos organizacionales (no limitados a los usados en un proyecto). En este criterio, los cuantificadores posibles son:

  • Alto (cuyo valor se consigue cuando se requiere invertir grandes cantidades de dinero),
  • Medio (cuyo valor se consigue cuando se requiere invertir un valor considerable de dinero); y,
  • Bajo (cuyo valor se consigue cuando se requiere invertir pocas cantidades de dinero).

Calidad del software: este criterio hace referencia que el paradigma asegura, de una manera objetiva, que los productos software y los procesos son conformes a los requerimientos especificados y se ajustan a los planes establecidos. Los cuantificadores se han obtenido en base a: (a) la consideración de instrumentos cuantitativos de medición de tiempo como Puntos de Función, COCOMO u otros que aportan luces de sobre tiempo y coste, y (b) en la experiencia de las personas y la madurez de la organización en sus procesos de desarrollo. Cabe añadir, que la calidad no es un bien o un activo organizacional transable, es una decisión de alto riesgo. Ningún proyecto debería comenzar con una calidad esperada que no sea ALTA. En este criterio, los cuantificadores posibles son:

  • Bajo (cuyo valor se consigue cuando el paradigma contempla entre sus fases el aseguramiento de la calidad del software); y,
  • Alto (cuyo valor se consigue cuando el paradigma contempla entre sus fases el aseguramiento de la calidad del software).

Documentación: este criterio hace referencia que el paradigma contempla el proceso para registrar la documentación producida por un proceso o actividad del ciclo de vida. El proceso contiene el conjunto de actividades para planificar, diseñar, desarrollar, producir, editar, distribuir y mantener aquellos documentos que necesitan todos los involucrados tales como gerentes, ingenieros y usuarios del sistema o producto software. Los cuantificadores se han obtenido en base a la conjugación de consideraciones como: (a) la cantidad de documentos a generar, (b) el nivel de “especificación” exigida, (c) el proceso de actualización, control y autorización de documentos, y (d) las copias a generar y distribuir. Cabe añadir que si bien no incluyen aspectos de documentación, NO hay que dejar de considerar el uso de instrumentos cuantitativos de medición de tiempo como Puntos de Función, COCOMO u otros, la experiencia de las personas y la madurez de la organización en sus procesos de desarrollo. En este criterio, los cuantificadores posibles son:

  • Bajo (cuyo valor se consigue cuando el paradigma no contempla entre sus fases la documentación),
  • Medio (cuyo valor se consigue cuando el paradigma contempla entre sus fases la documentación de forma no tan estricta); y,
  • Alto (cuyo valor se consigue cuando el paradigma contempla entre sus fases la documentación).

C. Análisis por criterio de los paradigmas

A continuación se comparan los paradigmas en base a los criterios anteriormente introducidos. Se destaca que los valores (cuantificadores) puestos en cada paradigma por cada criterio, son referenciales y pueden variar según cada caso de proyecto, y experiencia de las personas y las organizaciones.

Análisis por criterio de modelos de desarrollo de software - (c) Arleth Saurith - (c) Christian A. Estay-Niculcar

Análisis por criterio de modelos de desarrollo de software - (c) Arleth Saurith - (c) Christian A. Estay-Niculcar

___________________________________________
Estas ideas las desarrollé en un apunte que diseñé y colaboré en su contenido llamado Análisis y Diseño Integral de Sistemas y Requerimientos, cuya referencia es:

  • Saurith, Arleth; y, Estay-Niculcar, Christian. (2010). Análisis y Diseño Integral de Sistemas y Requerimientos. Fundación Universitaria Iberoamericana. ISBN. 978-84-96542-77-8 . Mayo. 167 pp. Barcelona, España. Ver.

Algo más del tema y puesto en la misma referencia se puede consultar en el post “Information Systems Philosophy: ¿Cómo modelar sistemas para insertarlos en organizaciones? una visión sistémica orgánico-estructural para una deconstrucción pensada en usuarios y operadores (2010)” -Febrero 28, 2010-.

Más ideas pueden enlazarse con este el post “Information Systems Philosophy: los 5 sentidos como base de mejora de competencias en Analistas de Sistemas … reporte de experiencia” – Febrero 23, 2011- o con el post “Information Systems Philosophy: el rol de los Sistemas de Información y la filmografía: 3 roles organizacionales … 3 películas (TRON, You’ve got email, Firewall)” -Abril 25, 201

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: