Beneficios

de

los

modelos

de

desarrollo

de

software

El objetivo de un proceso de desarrollo es incrementar la calidad del software a travs de una mayor transparencia y control sobre el proceso. Para obtener calidad en el producto final, es fundamental producir lo esperado en tiempo y costo estimados. Para tener un proceso de produccin de software con el menor nmero de fallos, adecuado a las necesidades del cliente y entregar a tiempo el producto, la produccin de software debe convertirse en un proceso disciplinado. Es muy importante saber seleccionar un proceso para el desarrollo del sistema ya que dependiendo del que elija se pueden obtener beneficios como:

Aumentar la velocidad de desarrollo. Predecir tiempos y costos. Mejorar la calidad, el control y el seguimiento del sistema. Minimizar gastos y riesgo. Mejorar las relaciones con los usuarios. Definir roles y perfiles.

Los beneficios para los involucrados en el desarrollo de software como desarrolladores, dueos del negocio y expertos del dominio.se presentan los siguientes: Los desarrolladores y/o diseadores: son los responsables de hacer realidad los requerimientos del sistema a desarrollar, cuyos beneficios son: Un menor nmero de lneas de cdigo escritas. Disear una aplicacin o artefactos de software partiendo de lo ms general a lo ms concreto. Especificacin de requisitos de usuario a varios niveles obteniendo un sistema flexible a los cambios.

Evitar la adopcin de una nica tecnologa de hardware sin generar un vnculo particular. Interoperabilidad entre los objetos en los sistemas.

Dueos del negocio: son los encargados de coordinar y/o financiar el proyecto de desarrollo e implementacin del sistema dentro de la organizacin o institucin, y los beneficios son: Desarrollo de componentes de software para los sistemas de repositorios. Preservacin digital de los recursos y/o de los objetos generando estrategias que parten de los niveles altos de abstraccin. Generacin de cdigo para plataformas previamente especificadas a travs de la funcionalidad que ofrece el paradigma. Reduccin de costes en el desarrollo de aplicaciones debido a la disminucin del recurso humano requerido, de las horas hombre y del tiempo invertido en las diferentes actividades relacionadas. Documentacin de todo el proceso de desarrollo de software.

Expertos del dominio: representan a los especialistas presentes en las fases del mundo de los RI. Los beneficios son: Permitir el desarrollo de modelos por parte de los distintos expertos del dominio. Generacin de lenguajes especficos del dominio en las fases de la implementacin. Interoperabilidad entre los distintos modelos PSM principalmente, ya que pueden pertenecer a distintas tecnologas (plataformas).

Criterios para tomar la decisin sobre cual modelo de desarrollo de software emplear en un proyecto o ante un determinado problema
Es posible saber cmo escoger una metodologa 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 cul metodologa de desarrollo es adecuada. Hay que dejar claro que esto no es un acto terminal de investigacin, sino simplemente un ejercicio organizador. Vemos til este tema para decisores informticos vinculados a portafolios y carteras de proyectos y por supuesto a gestores de proyectos. 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 documentacin.

Cabe sealar que para cada criterio se definieron cuantificadores o mejor dicho valores cualitativos basados en anlisis de otros parmetros, variables o consideraciones que para efectos de este documento no es necesario entrar a describir sino mencionar para efectos de comparacin. Es adecuado indicar con nfasis, que los cuantificadores se presentan como sugerencias pues su obtencin puede ser un proceso ms riguroso o dependiente de cada organizacin. En este ejercicio, eso s, se exponen las bases desde las cuales extraer los valores de cuantificacin que creemos son los adecuados. 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 organizacin ha dispuesto o dispondr todos los recursos necesarios para la ejecucin del proyecto); Algunos (Que la organizacin ha dispuesto o dispondr algunos de los recursos necesarios para la ejecucin del proyecto).

Complejidad del proyecto: este criterio hace referencia al tamao del sistema y la complejidad del mismo, donde segn la complejidad del proyecto aplica o no aplica una metodologa especfica. Los cuantificadores se han obtenido en base a dos parmetros: (a) en base a un clculo de complejidad como Puntos de Funcin o COCOMO u otros; y (b) en base a la experiencia de las personas y de la madurez en los procesos empleados por la organizacin). 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 diseador. Los cuantificadores se han obtenido en base a la conjugacin de dos cosas: (a) la experiencia del observador; y, (b) el manejo que tenga de las herramientas de descripcin). En este criterio, los cuantificadores posibles son:

Especifico (Es necesario que el analista o diseador 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 diseador 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 diseador antes de revisar una situacin o fenmeno. Los cuantificadores se han obtenido en base a la conjugacin de dos cosas: (a) el grado de capacitacin 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 fenmeno en estudio), Regular (cuyo valor se consigue cuando el observador tiene algn dominio de los factores y procesos que participan del fenmeno de estudio); y, Pobre (cuyo valor se consigue cuando el observador tiene poco dominio de todos los factores y procesos que participan del fenmeno en estudio).

Manejo de las perspectivas de riesgos: este criterio hace referencia a tener en cuenta la definicin de riesgos y perspectivas de los mismos en alguna de las metodologas tienen en cuenta este criterio. Los cuantificadores se han obtenido en base a la consideracin de dos aspectos: (a) en base a instrumentos cuantitativos de medicin de riesgos, y (b) en

base a la experiencia de las personas y la madurez de la organizacin 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 definicin de perspectivas de riesgo); y, Si (cuyo valor se consigue cuando el paradigma no contempla entre sus etapas la definicin 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 medicin como Puntos de Funcin, COCOMO u otros, (b) en la experiencia de las personas y la madurez de la organizacin 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 ao), Medio (cuyo valor se consigue cuando los tiempos de desarrollo para ejecutar el proyecto de software son mayores de entre 6 meses y un ao); 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 medicin como Puntos de Funcin, COCOMO u otros, y (b) en la experiencia de las personas y la madurez de la organizacin en sus procesos de desarrollo. Adicionalmente, los costes deben evaluarse en funcin de cualitativos como el coste de no-calidad, de la rentabilidad a obtener y la inversin a incurrir en trminos 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 consideracin de instrumentos cuantitativos de medicin de

tiempo como Puntos de Funcin, COCOMO u otros que aportan luces de sobre tiempo y coste, y (b) en la experiencia de las personas y la madurez de la organizacin en sus procesos de desarrollo. Cabe aadir, que la calidad no es un bien o un activo organizacional transable, es una decisin de alto riesgo. Ningn proyecto debera 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).

Documentacin: este criterio hace referencia que el paradigma contempla el proceso para registrar la documentacin producida por un proceso o actividad del ciclo de vida. El proceso contiene el conjunto de actividades para planificar, disear, 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 conjugacin de consideraciones como: (a) la cantidad de documentos a generar, (b) el nivel de especificacin exigida, (c) el proceso de actualizacin, control y autorizacin de documentos, y (d) las copias a generar y distribuir. Cabe aadir que si bien no incluyen aspectos de documentacin, NO hay que dejar de considerar el uso de instrumentos cuantitativos de medicin de tiempo como Puntos de Funcin, COCOMO u otros, la experiencia de las personas y la madurez de la organizacin 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 documentacin), Medio (cuyo valor se consigue cuando el paradigma contempla entre sus fases la documentacin de forma no tan estricta); y, Alto (cuyo valor se consigue cuando el paradigma contempla entre sus fases la documentacin). C. Anlisis por criterio de los paradigmas A continuacin 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 segn cada caso de proyecto, y experiencia de las personas y las organizaciones.

Anlisis por criterio de modelos de desarrollo de software - (c) Arleth Saurith - (c) Christian A. Estay-Niculcar Referencia es:
Saurith, Arleth; y, Estay-Niculcar, Christian. (2010). Anlisis y Diseo Integral de Sistemas y Requerimientos. Fundacin Universitaria Iberoamericana. ISBN. 978-84-96542-77-8 . Mayo. 167 pp. Barcelona, Espaa. Ver.