ISSN 0798 1015
ISSN 0798 1015
Vol. 38 (Nº 36) Año 2017. Pág. 11
Nohora MERCADO-CARUSO 1; Edwin PUERTA DEL CASTILLO 2; Harold PÉREZ OLIVEIRA 3
Recibido: 22/02/2017 • Aprobado: 22/03/2017
2. Métodos de estimación de costos de software
RESUMEN: En este artículo se analizan por medio del método predictivo Delphi diferentes escenarios realistas de como las empresas estiman los costos en sus productos de software; los cuales se valoraron y clasificaron por expertos del sector en Barranquilla, Colombia, teniendo en cuenta los métodos de estimación de software más usados a nivel mundial. De esta manera se generó un modelo de estimación de costos de software para ayudar a los líderes de proyectos a contar con estimaciones más precisas al interior de sus empresas. |
ABSTRACT: Through the Delphi predictive method, different realistic scenarios of how companies estimate costs for their software products are analyzed in this article. Industry experts in Barranquilla Colombia have valued and classified these scenarios, taking into account the most widely used software estimation methods worldwide. In this way a software cost estimating model has been generated to help project leaders to have more accurate estimates within their companies. |
La estimación de proyectos de software es una actividad compleja y crucial para las empresas de desarrollo de software. La permanencia de muchas de ellas en el mercado, depende de una buena estimación, la cual determina el éxito o fracaso de un proyecto de software al influir en todas las fases de desarrollo. El autor Heemstra (1990) señala que para muchas organizaciones es alarmante controlar el desarrollo del software; demostrando que esta es razón suficiente para que la estimación de costo ocupe un lugar importante en la disciplina de ingeniería de Software. Alguno de los factores que afectan la precisión de las estimaciones y logra que se torne un proceso difícil y complicado son:
Las empresas constantemente tienen que tratar de seleccionar el método más acertado según su necesidad y tratar de manejar una base histórica para eliminar la diferencia entre las medidas reales y estimadas (Almache C, Raura, & Ruiz R, 2015). Las organizaciones aplican metodologías de desarrollo de software en sus procesos de crecimiento, para diseñar las mejores herramientas computacionales con los mejores requerimientos, teniendo en cuenta las necesidades de cada unidad de trabajo y su integración como un sistema, lo que origina un producto cuya calidad dependerá de muchos factores en un tiempo y costo que pueden sobrepasar el presupuesto asignado para ello (Gil, Orozco, De la hoz, De la Hoz, & Morales, 2016)
Existen diferentes métodos para realizar estimaciones de costos de software y cada uno tiene su ventaja e inconveniente, por lo tanto, muchos autores recomiendan aplicar más de uno, comparar sus resultados y verificar el método más preciso. En este artículo se explica el proceso utilizado por medio del método Delphi para establecer una manera práctica de realizar estimaciones de costos de software en las empresas desarrolladoras teniendo como base las empresas pertenecientes al sector de desarrollo de software.
El concepto de estimación de costo de software, el autor Felix (1997) lo define como el proceso de predecir el esfuerzo requerido para el desarrollo de un sistema de software, donde la mayor parte del costo de desarrollo es debido al esfuerzo humano; indica una complejidad en el desarrollo del proyecto de software. En ocasiones no se cuenta con una base de datos histórica, no hay entrenamiento del personal para realizar las estimaciones correspondientes y los factores implicados no están bien interrelacionados. La precisión de la estimación del costo de software tiene un impacto directo y significativo sobre la calidad de las decisiones de inversión del software, significando perdida o ganancia para la empresa desarrolladora (Al-Sakran, 2006).
La estimación de costos, está asociada con la estimación fiable del tamaño y los recursos necesarios para producir el producto de software que proporciona al administrador de proyecto la información necesaria para desarrollar la programación, presupuesto y asignación de personal y recursos. De esta manera el objetivo de la estimación de costo de software consiste en estimar el tamaño, el esfuerzo, la complejidad y el costo del proyecto de software para poder encontrar la mejor decisión de desarrollo y asegurar que el gasto se encuentre de acuerdo a lo presupuestado. (Bozhikova y Stoeva, 2010). Por todo lo anterior, la estimación de costos de software es importante para la planificación, programación, presupuesto y establecer el precio indicado al desarrollo del software (Magazinius y Feldt, 2010). Es fundamental para el éxito de la gestión del proyecto de software, al afectar la mayoría de las actividades de gestión incluyendo la asignación de recursos, la licitación de proyectos y la planificación. Algunos de los métodos de estimación más utilizados en la industria del software se pueden apreciar en la siguiente figura:
Método de Estimación |
Ventajas |
Limitaciones |
COCOMO |
Se basa en la evaluación de factores de esfuerzo del proyecto, lo que hace que en la estimación se incluyan varios factores que inciden en el costo del proyecto. |
Predisposición por parte del equipo de la gestión ante la utilización de fórmulas matemáticas. |
Estimación de expertos |
Las estimaciones generadas son tan buenas como las generadas por modelos más costosos y que consumen más tiempo |
Se basa en la intuición y experiencia. Se limita por la disponibilidad del experto |
Analogía |
Si se cuenta con buena información histórica de proyectos pasados, se pueden obtener estimaciones bastante acertadas. |
Requiere contar con una base de datos histórica que sea constantemente actualizada. Compara proyectos actuales con desarrollos pasados, que en ocasiones sean desactualizados |
Precio para ganar |
La estimación se realiza de una manera muy sencilla. |
La estimación muy probablemente estará incorrecta, y el costo real estará muy alejado de la realidad. |
Bottom-Up |
Descomponer un proyecto en partes más pequeñas para realizar estimaciones por separado, logrando que sea sencilla esta tarea y obteniendo una estimación global de todo el proyecto mucho más completa |
Al descomponer el proyecto y realizar las estimaciones se puede perder de vista que las partes al estar relacionadas como un todo. |
Tabela 1. Ventajas y desventajas de los métodos de estimación. Adaptado de (Forigua y Ballesteros, 2007)
El método Delphi es definido por Kavantzas, et al. (2004) como un método de estructuración de un proceso de comunicación grupal que es efectivo a la hora de permitir a un grupo de individuos, como un todo, tratar un problema complejo.
El método consiste en la selección de un grupo de expertos a los que se les pregunta su opinión sobre cuestiones referidas a acontecimientos del futuro. Las estimaciones de los expertos se realizan en sucesivas rondas, anónimas, al objeto de tratar de conseguir consenso, pero con la máxima autonomía por parte de los participantes.
Por lo tanto, la capacidad de predicción del método se basa en la utilización sistemática de un juicio intuitivo emitido por un grupo de expertos. Es decir, el método Delphi procede por medio de la interrogación a expertos con la ayuda de cuestionarios sucesivos, a fin de poner de manifiesto convergencias de opiniones y deducir eventuales consensos. La encuesta se lleva a cabo de una manera anónima (actualmente es habitual realizarla haciendo uso del correo electrónico o mediante cuestionarios web establecidos al efecto) para evitar los efectos de "líderes". El objetivo de los cuestionarios sucesivos, es "disminuir el espacio intercuartil precisando la mediana".
El método Delphi es generalmente asociado a los pronósticos y planificaciones de los problemas, pero los autores de Kavantzas et al. (2004) Gregory J. Skulmoski (2000) y (Gordon Xu, 2006) identificaron diferentes usos para este método incluyendo el análisis de datos históricos. Sin embargo, este estudio de estimación de Costos de Software en las empresas desarrolladoras utiliza el método Delphi para obtener una opinión de consensos de problemas futuros.
El método Delphi se utiliza para pronósticos a largo plazo y se basa en la experiencia de expertos por lo que es uno de los métodos más confiables tipo cualitativo. En el siguiente cuadro se analizan los métodos según el horizonte de beneficio. (Reich, 2009)
Método cualitativo |
Horizonte de beneficio |
Método Delphi |
Mediano y largo plazo |
Juicio informado |
Corto plazo |
Analogía de ciclo de vida |
Mediano y largo plazo |
Investigación de Mercado |
Corto y mediano plazo |
Tabla 2. Horizonte beneficios métodos cualitativos. Adaptado de (Reich, 2009)
El método Delphi por medio de un conjunto de rondas con un panel de expertos identifica un consenso general de un tema específico. Al poner en práctica el método, la primera ronda por medio de una lista de sugerencias del tema, incentiva a los encuestados a pensar en su experiencia y conocimiento sobre los diferentes métodos de estimación de costos de software. La segunda ronda considera lo «más importante» y « lo más probable que ocurra" temas o tendencias. El objetivo de la tercera ronda del proceso es generar un consenso, donde se envían los resultados y los expertos tienen la opción de cambiar algún punto de vista al conocer el resultado global, pero manteniendo en anonimato a los expertos. Aunque no hay forma de determinar el número óptimo de expertos para participar en una encuesta Delphi, estudios realizados por investigadores de la Rand Corporation Dalkey, et al. (1999) señalan que si bien parece necesario un mínimo de siete expertos habida cuenta que el error disminuye notablemente por cada experto añadido hasta llegar a los siete expertos, no es aconsejable recurrir a más de 30 expertos, pues la mejora en la previsión es muy pequeña y normalmente el incremento en coste y trabajo de investigación no compensa la mejora (Puertas Del Castillo, 2011).
En este estudio se utilizó el método Dephi donde el objetivo de cada ronda se formuló a través del "método convencional de Delphi de Linstone y Turoff (2002). El diseño del formato es texto simple y utiliza un formato sencillo para incentivar a su diligenciamiento. En la tabla 3 se puede apreciar las fases del método Delphi.
FASE 1 |
FASE 2 |
FASE 3 |
FASE 4 |
Formulación del problema |
Elección de expertos |
Elaboración y lanzamiento de los cuestionarios (en paralelo con la fase 2) |
Desarrollo práctico y explotación de resultados |
Se trata de una etapa fundamental en la realización del método. La importancia de esta fase es definir con precisión el campo de investigación, por cuanto es preciso estar muy seguros de que los expertos reclutados y consultados poseen todos la misma noción de este campo. |
La etapa es importante en cuanto que el término de "experto" es ambiguo. Con independencia de sus títulos, su función o su nivel jerárquico, el experto será elegido por su capacidad de encarar el futuro y posea conocimientos sobre el tema consultado. |
Los cuestionarios se elaborarán de manera que faciliten, en la medida en que una investigación de estas características lo permite, la respuesta por parte de los consultados. Preferentemente las respuestas habrán de poder ser cuantificadas y ponderadas (año de realización de un evento, probabilidad de realización de una hipótesis, valor que alcanzará en el futuro una variable o evento. |
El cuestionario es enviado a cierto número de expertos (hay que tener en cuenta las no-respuestas y abandonos). El objetivo de los cuestionarios sucesivos es disminuir la dispersión de las opiniones y precisar la opinión media consensuada. |
Tabla 3. Fases del método Delphi aplicadas al estudio. Tomado de Kavantzas et al. (2004),
Skulmoski et al. (2000), Xu y Gutiérrez (2006)
La lista de escenarios a evaluar por los expertos proviene de la revisión de la literatura sobre el tema. Se presentaron las categorías de Juicio Experto, Estimación por analogía, Precio para ganar y estimaciones por medio del uso de aplicaciones sistematizadas.
A continuación se detalla cada uno de los escenarios propuestos que fueron evaluados por los expertos:
Los panelistas analizaban los escenarios propuestos y realizaban comentarios según la experiencia en los procesos de estimación de costos de software desde su compañía. Los objetivos planteados para esta primera ronda fueron estimular a los panelistas o expertos sobre cuáles son las variables que afectan sobre estimaciones más precisas, e identificar cambios o recomendaciones sobre los escenarios planeados.
De la revisión bibliográfica se distribuyeron una lista de 4 escenarios iniciales, los cuales son el resultado de los métodos más utilizados según el referente de estudios a nivel mundial. Escenarios propuestos y el análisis de estos escenarios por parte de 10 expertos del área de software se muestran a continuación:
Tabla 4. Fases del método Delphi aplicadas al estudio. Tomado de Kavantzas et al. (2004),
Skulmoski et al. (2000), Xu y Gutiérrez (2006)
Escenario A Juicio experto |
Escenario B Analogía |
Escenario C precio para ganar |
Escenario D Aplicaciones sistematizadas |
Las empresas desarrolladoras de software solicitan el apoyo de la experiencia de varias personas que están familiarizadas con el desarrollo de aplicaciones de software similares. La característica principal en la empresa es la ausencia de datos cuantificados de proyectos anteriores. Cada una de las personas estima el costo del proyecto de desarrollo de software basándose solo en su experiencia y conocimientos anteriores; luego las estimaciones se comparan y con todo el grupo se discuten las diferencias e inconsistencias. |
Las empresas desarrolladoras de software cuentan con datos cuantificables y/o históricos de proyectos anteriores, utilizados para predecir el costo del nuevo proyecto. La empresa utiliza los valores de parámetros como el alcance, el costo, el presupuesto y la duración, o medidas de escala tales como el tamaño, el peso y la complejidad de un proyecto anterior similar, como base para estimar el mismo parámetro o medida para un proyecto actual. De esta manera, el líder del proyecto estima las similitudes entre el nuevo proyecto y los proyectos anteriores y se escoge la más parecida. Existen multitud de medidas de similitud entre ejemplares, siendo las más usadas las distancias de Euclides, de Manhattan y de Minkowski. La más utilizada es la de Euclides. |
La empresa desarrolladora de software considera que el costo del proyecto del software está en función de lo que el cliente está dispuesto a paga ya que no se puede dar el lujo de perder un cliente. El problema que se presenta es que la probabilidad de que el cliente obtenga el producto que quiere es pequeña, ya que los costes no reflejan realmente el trabajo requerido para su desarrollo y se puede generar retrasos en la entrega u obligar al equipo de desarrollo a trabajar horas extras. Las estimaciones de costos se basan en el presupuesto del cliente en lugar de la funcionalidad del software. |
La empresa desarrolladora de software no se complica realizando cálculos manuales y decide adquirir una herramienta para realizar sus estimaciones Estos software son comerciales y proporcionar un núcleo de funciones |
-----
Tabla 5. Recomendaciones y/o puntos de vista de los expertos sobre los
escenarios de estimación de costos de software propuestos- Ronda 1
Expertos |
Escenarios |
||||
A |
B |
C |
D |
OBSERVACIONES |
|
1 |
Realizan estimaciones por medio de la experiencia, según la metodología. El grupo de desarrollo se reúne y proponen un límite de tiempo para desarrollar una tarea. El riesgo de realizar estimaciones de esta manera es que muchas veces los programadores se equivocan en el tiempo estimado. |
No aplica, manejan una base de datos histórica (Base de datos de conocimiento), es una guía para manejar estimaciones futuras, pero hasta la fecha se está empezando a implementar. Desconocemos la fórmula propuesta. |
No está completamente en función al presupuesto del cliente, sino de acuerdo a lo que el cliente está de acuerdo a pagar, se desarrollan las funcionalidades del producto. No es muy recomendable su aplicación, ya muchas veces que el producto a entregar no es el deseado por el cliente. |
No aplica, la empresa maneja redmind para gestión de proyectos de software. Se realizan estimaciones de tiempos. |
|
2 |
No aplica en nuestra empresa. No lo utilizaríamos este método |
Si utilizamos base de datos histórica, pero es necesario actualizarla. La fórmula nos parece confusa |
Para no perder un cliente a veces se negocia, pero es importante no realizar promesas de tiempo. |
Utilizamos herramientas de gestión para apoyarnos en las estimaciones |
|
3 |
Este escenario es utilizado en la empresa al aplicar la experiencia para identificar el tiempo para desarrollar una actividad. Normalmente el desarrollador Senior realiza esta estimación. No se realiza en conjunto sino que al asignar las actividades a los responsables del proyecto, según su experiencia identifican la duración para culminarla. |
Se considera importante tener datos históricos para realizar estimaciones más precisas, sin embargo no conozco esta fórmula. |
Este escenario es viable cuando el cliente tiene un presupuesto establecido, se negocia con el cliente pero sin incurrir en compromisos insostenibles. Al cerrar la negociación según lo que el cliente esté disponible a pagar se establece el alcance del software y las funciones que se incorporaran. |
La empresa utiliza aplicaciones como dashable para disminuir la incertidumbre y estimar las tareas. Cabe resaltar que esta aplicación fue desarrollada por la misma empresa. |
Proponen un nuevo escenario que se tiene en cuenta para afinar los escenarios propuestos |
4 |
Me parece un método poco acertado debido a que puede tener muchas opiniones y lo que van a suceder es que se van a ir con el costo que muestre el consenso, que no es lo mismo que el costo adecuado. |
Comparto el hecho de soportarse en la base histórica de proyectos realizados, para medir el costo del nuevo proyecto. En cada estimación lo importante es disminuir el factor de incertidumbre, es decir si podemos tener certeza de los desarrollos que hay que realizar y su complejidad podemos estimar las horas ingeniero que se requieren y los tiempos de cada etapa, lo que va a dar un alto nivel de precisión en el costo. Sobre la formula expresada no estoy familiarizado con esta. |
No comparto este escenario, bajo ningún punto de vista. Cada desarrollo tiene un costo y debe dejarle utilidad a la empresa que lo desarrolla, de lo contrario será un desastre. |
Esta metodología puede ser de gran ayuda, pero volvemos a la base del proyecto y es eliminar el nivel de incertidumbre para poder estimar el esfuerzo real de cada tarea. La herramienta provee una metodología organizada y probada pero si las estimaciones de los esfuerzos no son las correctas debido al grado de incertidumbre, el resultado será igualmente incorrecto. |
|
5 |
Estoy de acuerdo, la empresa utiliza el enfoque de planning Poker, que reúne al grupo de desarrolladores que van a participar en el proyecto. |
Al tener el problema de rotación de personal esto hace que las estadísticas se vuelvan inválidas rápidamente. La empresa tiende a ser muy dinámica y se vincula nuevo personal a diferentes proyectos. Es interesante este método. |
La empresa costea dependiendo del nivel económico del cliente. Hemos tenido la experiencia con este escenario. Pero no es recomendable y actualmente no lo utilizamos |
No es recomendable su uso, pero si apoyarse en herramientas de gestión de proyectos de software |
|
6 |
La empresa calcula el esfuerzo de esta manera, pero utilizando la llamada baraja de cartas para llegar a un consenso. Puede variar el tiempo estimado dependiendo del perfil Ing. senior, junior, coordinadores. Las personas expertas son consideradas los mismos desarrolladores asignados a un proyecto. |
No manejan este escenario. Es interesante, pero consideramos que cada proyecto es diferente, sin embargo es importante tener una base de conocimientos para almacenar el histórico de las estimaciones y utilizarlas como referentes |
Consideramos que es un escenario poco viable para la empresa, no es recomendado. En ningún momento han tenido que manejar la operación de esta manera |
No utilizamos este escenario, pero utilizamos la herramienta de gestión de proyectos Doproject. |
|
7 |
Inconvenientes con Expertos dentro y fuera dispuestos y en los tiempos requeridos para la estimación |
No es confiable por haber factores humanos que afectan en un proyecto en menor o mayor medida por tanto la métrica fallaría |
Escenario no viable, ya que en un momento se generaran pérdidas en la compañía al igual que el cliente, esto se producen en clientes que no tienen la madurez informática, es decir conocimientos mínimos de como es el proceso de desarrollo de Software, su complejidad y sus diferencias de la producción industrial de otros bienes y servicios de la sociedad, que no son aplicables al desarrollo de software. |
Hoy día el número de líneas de código es irrelevante, las mayorías de IDEs generan código que distorsiona el costo. |
Proponen un nuevo escenario que se tiene en cuenta para afinar los escenarios propuestos |
8 |
Solo usamos esto cuando necesitamos un estimado a corto plazo. Y normalmente no la consideramos como el estimado final. . Manejamos planning Poker |
Esto daría un mejor estimados, pero teniendo en cuenta el programador que se usaría para estos estimados. Es importante llevar un histórico de su desempeño. |
Eso no lo recomiendo para nadie. |
No lo utilizamos, pero manejamos herramientas de gestión |
|
9 |
La empresa utiliza Planning Póker, que es una técnica para calcular una estimación basada en el consenso, en su mayoría utilizada para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de software. Es una variación del método Wideband Delphi. Es utilizado comúnmente en el desarrollo ágil de software, en particular en la metodología Extreme Programming. |
No lo maneja el área de desarrollo, el área administrativa lo maneja en cuanto tiempo y costo del proyecto en general. |
Han tenido la experiencia con este escenario. Quitan funciones del software y generan un precio. No es la mejor manera. |
No utilizan ninguna herramienta. |
Proponen un nuevo escenario que se tiene en cuenta para afinar los escenarios propuestos |
10 |
Para desarrollos nuevos se basan en la experiencia que han tenido con proyectos anteriores. Buscan desarrolladores que han trabajado en experiencia en el proyecto actual, se reúnen y dan su opinión frente al tiempo y el costo del proyecto, llegando a un consenso. Se tiene en cuenta el alcance del proyecto y dependiendo de las actividades realizan las estimaciones. |
Evalúan el proyecto anterior y tiene en cuenta imprevisto que no se tuvieron anteriormente en cuento al costo y ejecución del proyecto. No conocen la formula |
Han tenido la experiencia, pero no recomiendan este escenario. Ven un cliente potencial y para no perderlo negocian el precio. Las actualizaciones las realizan en el contrato de mantenimiento. |
No utilizan ninguna herramienta. |
Proponen un nuevo escenario que se tiene en cuenta para afinar los escenarios propuestos |
Al obtener información de la primera ronda se mejoraron y eliminaron los escenarios que no estaban acordes a la realidad del entorno estudiado. Igualmente se agregaron escenarios fusionados de diferentes expertos que coincidían en sus apreciaciones y que era importante tener en cuenta (ver tabla No 5)
Los objetivos de realizar esta segunda ronda fueron:
De esta manera en la segunda ronda quedaron refinados para clasificar y evaluar 5 escenarios donde también se podían realizar comentarios o puntos de vista alternativos. Los nuevos escenarios generados para clasificar se pueden apreciar en la tabla No 6
A los expertos se les pidió en esta ronda clasificar la importancia de los escenarios con una escala de cinco puntos, siendo 1 el primero que aplicarían y 5 el último. Igualmente los participantes tuvieron que valorar los escenarios en una escala del 1 al 5, donde 5 expresa su total acuerdo y 1 su total desacuerdo con las diferencias tendencias generándose una probabilidad de ocurrencia. A continuación se muestra las tablas que se utilizó para realizar estas mediciones (ver tabla No 7).
Tabla No 6. Escenarios refinados según expertos. Elaboración propia.
Escenario A1 |
Escenario B1 |
Escenario C2 |
Escenario D1 |
Escenario E1 |
Una de las formas de realizar la estimación de esfuerzo o tamaño relativo de las tareas de desarrollo e basa en utilizar una baraja de cartas que se encuentran enumeradas mostrando la secuencia Fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Se utiliza esta secuencia para identificar la incertidumbre de cada una de las estimaciones. Cada uno de los integrantes del proyecto posee un mazo de cartas; el moderador que puede ir guiado por el coordinador del proyecto proporciona las características de la tarea a desarrollar, y el grupo puede intervenir para aclarar sus dudas. |
La empresa considera que es importante crear una base de datos histórica para medir el costo de un nuevo proyecto. La base de conocimiento tendría información como descripción del requerimiento, complejidad del requerimiento, tiempo estimado, tiempo real, duración general del proyecto en horas, valor por hora dependiendo del perfil del desarrollador, etc. |
La empresa debe establecer el alcance y los requisitos del proyecto en cada una de las fases para realizar una buena estimación. Por cada una de las fases se descomponen los requisitos en tareas o funcionalidades más específicas y sobre estas se realizan estimaciones de tiempo, así como el valor por hora de desarrollo dependiendo del perfil del desarrollador que la va a realizar. |
El cliente se considera con poca fundamentación para establecer requerimientos, solo cuenta con una idea general del producto que quiere. La empresa desarrolladora genera un producto mínimo viable. Se realizan entregas parciales al cliente (pueden ser semanales) el cliente lo prueba y con las recomendaciones se agregan funcionalidades y modificaciones hasta llegar al producto deseado |
Se debe tener en cuenta el alcance del proyecto para realizar una buena estimación del costo de este. En muchas ocasiones existe un problema de aprendizaje donde el líder del proyecto y desarrolladores no entiende lo que desea el cliente. Es importante primero conocer cómo opera el cliente, para lo cual se deben realizar reuniones con el cliente. Al determinar cómo se va a hacer, se determina el tiempo, el cual impacta en los recursos. |
Tabla 7. Escala de clasificación y valoración de cada uno de los escenarios
Clasificar este tema (Escenario A1 de estimación de costos de software) |
|
De 5 |
Valoración de este tema : |
5 |
4 |
3 |
2 |
1 |
Resaltar la puntuación |
Totalmente de acuerdo |
Parcialmente de acuerdo |
Ni en acuerdo/ ni en desacuerdo |
Parcialmente en desacuerdo |
Totalmente en desacuerdo |
Comentario o punto de vista alternativo:
|
|||||
El objetivo de esta ronda es que los expertos puedan verificar la información suministrada. El ejercicio que se realizó fue consolidar la información obtenida y enviarla a cada uno de los panelistas con el fin de que cada uno conociera el consenso general de todo el equipo, así como los comentarios y puntos de vista generados.
En esta ronda el experto realiza ajustes de clasificación y valoración y tiene la opción de responder a comentarios realizados por otros panelistas.
Al analizar la información evaluada por los expertos, estos se inclinan al escenario C2 y D2 ya refinados tanto en las escalas de clasificación y valoración. Se destacan ciertas las observaciones realizadas, específicamente por el experto 8 el cual asegura que con la base de datos historia se logra un mejor estimado, pero se debe tener en cuenta el programador que se usaría para estos estimados, esto en términos de su experiencia con el lenguaje de programación y familiaridad del proyecto. El experto 2 comenta que basan sus estimaciones en técnicas de descomposición teniendo en cuenta el número de requerimientos, tamaño de las tareas en cada requerimiento, número y complejidad de las interfaces y la prioridad por tareas. Las anteriores observaciones serán tenidas en cuenta para el diseño del modelo de mejora de procesos de estimación de costos de software.
De los métodos refinados y evaluados por los expertos se escogieron los escenarios C2 y D1. El modelo se presenta a continuación:
El modelo se basa en 3 agentes: Metodología, capacidad de equipo de trabajo y herramientas tecnológicas; donde el cliente es pieza principal del proceso de desarrollo al ser parte activa de este y tomar decisiones importantes a lo largo del ciclo de vida del proceso.
El proceso empieza cuando el cliente identifica que tipo de solución desea para su compañía, una solución a la medida o un software empaquetado. Cabe resaltar que un software empaquetado ya cuenta con algunas funciones necesarias para su implementación, siendo más complicada su adaptación al tener que ajustarlas a las necesidades del cliente.
El cliente tiene relación directa con el agente “capacidad equipo de trabajo” al poder participar en la escogencia del número de recursos para el desarrollo de un proyecto. Si el equipo tiene los roles bien definido y se encuentran altamente capacitados en las herramientas de desarrollo y aquellas que soportan la gestión de su actividad el tiempo de respuesta van a ser más efectivo.
Grafica 1. Modelo de estimación costos.
Adaptado de (Puerta del castillo, Salas Navarro, & Mercado Caruso, 2015)
Igualmente es importante que existan políticas de capacitación y plan de incentivos al personal. Debe existir constante retroalimentación por parte del cliente del progreso del proyecto, lo que permitirá ajustar requisitos funcionales y no funcionales. El líder del proyecto debe conocer el progreso real del proyecto por medio de reuniones con su equipo donde se evalúe el cronograma de trabajo, los tiempos y la solución a bloqueos y a errores en la aplicación.
El agente de “herramientas tecnológicas” se basa en el uso de tecnologías para la arquitectura, patrones de desarrollo con abstracción de capas, lenguajes de programación apropiados para el proyecto. Igualmente se debe utilizar herramientas de apoyo a la gestión donde el cliente pueda ver en tiempo real el progreso del software, el número de personas que participan, el tiempo ejecutado y sobre esto pueda tomar decisiones del desarrollo del proyecto. Por otra parte, al utilizar el equipo herramientas para controlar el código pueden revertir errores locales, así como usar métodos para asegurar la calidad del producto.
Los factores anteriormente mencionados están relacionados y se debe tener en cuenta el grado de incertidumbre del proyecto, por lo que la fase de reuniones iniciales con el cliente es muy importante para conocer los requisitos del proyecto.
Los agentes anteriormente mencionados permiten marcar la diferencia entre beneficios y pérdidas para la compañía desarrolladora al evaluar aspectos como tiempo, costo, recursos disponibles, etc.
El objetivo final es desarrollar un producto que satisfaga las necesidades del cliente en el tiempo deseado y a un valor acorde. Al basarse el modelo propuesto en un Sprint y sobre estos entregables el cliente evalúa lo obtenido y vuelve al inicio del proceso para refinar o agregar funcionalidades al sistema.
Este modelo propone mejoras a tener en cuenta en los procesos de desarrollo para estimar los costos de un proyecto de manera mucho más realista al contemplar los componentes de metodología, herramientas tecnológicas y equipo de trabajo.
Se evidencio que los métodos no se aplicaban en su totalidad, sino que se adaptaron a un contexto muy particular de acuerdo a las condiciones socio económico de la región caribe. Es por esto que para la segunda ronda, los diferentes métodos propuestos según la literatura consultada son modificados y refinados de acuerdo con la experiencia y aplicación en las empresas, siendo la base para la creación del modelo propuesto de mejora de procesos de estimación de costos de software.
Almache C, M., Raura, G., & Ruiz R, J. (2015). Modelo Neuronal de Estimación para el Esfuerzo de Desarrollo en Proyectos de Software (MONEPS). Revista Latinoamericana de Ingeniería de Software, 148-154
Heemstra, F. J. (1990). "Software cost estimation." Butterworth-Heinemann Ltd 34: 286 - 297.
Mario Piattini V, F. G. R. (2008). Medición y estimación del software. Técnicas y métodos para mejorar la calidad y la productividad.
Felix, C. E. W. a. C. P. (1997). "A method of programming measurement and estimation." 16: 54-73.
Al-Sakran, H. (2006). Software Cost Estimation Model Based on Integration of Multi- agent and Case-Based Reasoning. Journal of Computer Science, 2(3): 276-282.
Magazinius, A. y R. Feldt (2010). "Exploring the Human and Organizational Aspects of Software Cost Estimation." ACM SIGSOFT Software Engineering Notes.
Kavantzas, N. et al. (2004). "Web Services Choreography Description Language (WS-CDL) vesion 1."
Gregory J. Skulmoski, F. T. H., Jennifer Krahn (2000). "The Delphi Method for Graduate Research." Journal of Information Technology Education 6.
Gordon Xu, J. A. G. ( 2006). "An Exploratory Study of Killer Applications and Critical Success Factors in M-Commerce." Journal of Electronic Commerce in Organizations: 63-79.
Reich, C. S. (2009). "PRONÓSTICOS CUALITATIVOS."Retrieved 27 Febrero, 2013, from http://shreich.wordpress.com/2009/10/07/pronosticos-cualitativos/.
Dalkey, N. C. et al. (1999). "The Delphi Method, III: Use of self rating to improve group estimates." Technological Forecasting and Social Change 1: 283-291.
Magazinius, A. y R. Feldt (2010). "Exploring the Human and Organizational Aspects of Software Cost Estimation." ACM SIGSOFT Software Engineering Notes.
Puertas Del Castillo, E. (2011). Método de integración empresarial orientada a servicios: Pequeñas y medianas empresas Investigativa, Universidad Tecnologica de Bolivar.
Linstone H., Turoff M. The Delphi Method. Techniques and applications. Portland: Portland State University; 2002.
Xu, G. y J. A. Gutiérrez (2006). "An Exploratory Study of Killer Applications and Critical Success Factors in M-Commerce." Journal of Electronic Commerce in Organizations: 63-79.
Skulmoski, G. J. et al. (2000). "The Delphi Method for Graduate Research."Journal of Information Technology Education vol 6.
Puerta del castillo, E., Salas Navarro, K., & Mercado Caruso, N. (2015). Mejora de los procesos de estimación de costos de software. Caso sector de software Barranquilla. Medellin: Revista Ingenierías Universidad de Medellín.
Gil, C., Orozco, M., De la hoz, A., De la Hoz, E., & Morales, r. (2016). AGILE TESTING PRACTICES IN SOFTWARE QUALITY:STATE OF THE ART REVIEW. Journal of Theoretical and Applied Information Technology.
1. Maestría en Ingeniería de Sistemas. Profesor Adjunto. Universidad de la Costa. Barranquilla, Colombia. nmercado1@cuc.edu.co
2. Maestría en Ingeniería. Énfasis en Sistemas. Docente Tiempo Completo, Ingeniería de Sistemas. Universidad Tecnológica de Bolívar UTB. Parque Industrial y Tecnológico Carlos Vélez Pombo, Km 1 Vía Turbaco. Cartagena. epuerta@unitecnologica.edu.co
3. Magister en Ingeniería Industrial, Ingeniero Industrial, Decano Facultad de Ingenierías Corporación Universitaria Americana, Barranquilla, Colombia, hperez@coruniamericana.edu.co