Modelo dinámico reducido v.1: Informe Técnico LSI-2000-12

MODELO DINÁMICO REDUCIDO 1 Departamento de Lenguajes y Sistemas Informáticos Facultad de Informática y Estadística Universidad de Sevilla MODELO DINÁMICO REDUCIDO Isabel Ramos, Miguel Toro, Mercedes Ruiz V.1 INFORME TÉCNICO: LSI-2001-01 MODELO DINÁMICO REDUCIDO 2 ÍNDICE 1. OBJETIVOS....................................................................................................................... 3 2. JUSTIFICACIONES PARA LA CREACIÓN DE UN MODELO DINÁMICO REDUCIDO....................................................................................................................... 4 2.1 Modelos estáticos y modelos dinámicos de estimación............................................... 5 2.1.1 Comparación...................................................................................................... 8 2.2 Diagrama Causal Básico............................................................................................. 10 3. MODELO DINÁMICO REDUCIDO................................................................................. 13 3.1 Reducción del Modelo Dinámico Intermedio.............................................................. 14 3.2 Descripción del Modelo Dinámico Reducido ............................................................. 15 3.3 Tamaño del Modelo Dinámico Reducido frente al Modelo Dinámico Intermedio..... 18 4. VALIDACIÓN DEL MODELO DINÁMICO REDUCIDO.............................................. 19 4.1 Resultados obtenidos con el proyecto CASO1............................................................ 19 4.2 Resultados obtenidos con el proyecto CASO2............................................................ 21 4.2.1 Introducción....................................................................................................... 21 4.2.2 Datos utilizados.................................................................................................. 22 4.2.3 Análisis de la información obtenida................................................................... 23 5. REGLAS DE GESTIÓN OBTENIDAS CON EL MODELO DINÁMICO REDUCIDO. 26 5.1 Reglas de gestión para el proyecto CASO1................................................................. 27 5.2 Reglas de gestión para el proyecto CASO2................................................................. 29 6. CONCLUSIONES.............................................................................................................. 32 7. BIBLIOGRAFÍA................................................................................................................. 33 ANEXO 1: Ecuaciones del Modelo Dinámico Intermedio..................................................... 36 ANEXO 2: Ecuaciones del Modelo Dinámico Reducido....................................................... 49 ANEXO 3: Parámetros y tablas.............................................................................................. 57 MODELO DINÁMICO REDUCIDO 3 1. OBJETIVOS Los objetivos de este documento son, en primer lugar, presentar un Modelo Dinámico Reducido (en adelante, MDR) para Proyectos de Desarrollo de Software (en adelante PDS) que sea sencillo y fácil de entender. Y en segundo lugar, presentar los resultados obtenidos con dicho modelo. La disponibilidad de un MDR nos permitirá: 1. Poder realizar estimaciones en las primeras etapas de un proyecto software, etapas en las que aún se dispone de poca información sobre el mismo. Especialmente para: x Aquellas organizaciones o empresas que no disponen de una base histórica de proyectos, o la información necesaria para definir tanto las características del entorno de desarrollo en el que se trabaja (relativas al proyecto y a la organización o empresa) como las características que permitan definir el grado de madurez adquirido. x Las organizaciones o empresas que trabajan en entornos de desarrollos diferentes y/o variables. 2. Poder enseñar a nuestros alumnos, o al personal novel en temas de gestión de PDS, cuáles son los lazos o bucles de realimentación básicos que definen el comportamiento de las variables fundamentales de dichos proyectos. 3. Obtener reglas de gestión donde intervenga un número reducido de parámetros. El MDR se ha obtenido a partir del estudio realizado a modelos dinámicos para proyectos de I+D (Investigación y Desarrollo ) y a modelos dinámicos para proyectos software. El MDR mantiene la estructura en subsistemas del Modelo de Abdel-Hamid y Madnick [ABDE 91], y se ha implantado en el entorno de simulación Vensim (Ventana Simulation V. 1.61). En los siguientes apartados se justificará, en primer lugar, la utilidad que tienen los modelos dinámicos reducidos o simplificados en la gestión de un PDS. Para ello, se da una breve descripción de los modelos de estimación dinámica y los modelos de estimación estática para analizar los huecos que se deberían cubrir con la creación de nuevos modelos de estimación dinámica [RUIZ 00], para continuar con otras justificaciones que nos han llevado a la creación del MDR [RAMO 97a]. Posteriormente, pasaremos a describir el MDR y finalmente presentaremos los resultados obtenidos con el mismo. MODELO DINÁMICO REDUCIDO 4 2. JUSTIFICACIONES PARA LA CREACIÓN DE UN MODELO DINÁMICO REDUCIDO Las consideraciones que nos han llevado a la creación de un modelo dinámico reducido, sencillo y fácil de entender fueron las siguientes: 1. La jerarquía de los modelos de estimación desarrollados por Boehm [BOEH 81] (univariables estáticos) nos sugirió la posibilidad de crear también una jerarquía de modelos de estimación dinámicos (multivariables) dependiendo del conocimiento que tuviéramos de nuestro proyecto, este conocimiento dependerá, fundamentalmente, de la etapa en la que nos encontremos. 2. La existencia de un diagrama causal básico común tanto para los proyectos de I+D (Investigación y Desarrollo) como para los PDS [RAMO 97b]. Los primeros modelos dinámicos de PDS están basados en modelos dinámicos anteriores sobre proyectos de I+D [ROBE 81], por tener ambos tipos de proyectos bastantes similitudes. 3. La necesidad de conocer un número importante de atributos, tanto del proyecto como del proceso, para poder simular los modelos dinámicos existentes (alrededor de 60 entre parámetros y tablas en el Modelo de Abdel-Hamid y Madnick [ABDE 91@). 4. La creación de modelos simplificados, a partir de otros ya existentes, se viene realizando en otros campos de conocimiento, fundamentalmente, a partir de los trabajos de simplificación de modelos dinámicos realizados por Robert L. Eberlein [EBER 89@. Estos trabajos están centrados en la reducción de modelos dinámicos de un cierto tamaño, para obtener un modelo más pequeño en los que se eliminan los bucles de realimentación que se consideran que no son esenciales para el comportamiento que se quiere analizar. Según Eberlein, la simplificación de modelos dinámicos grandes y/o complejos no solamente es útil, sino que además es un trabajo que debe de realizarse siempre para conocer los bucles de realimentación básicos. Por tanto, la creación del MDR tiene como objetivo obtener un modelo dinámico simplificado con un número de atributos (tablas y parámetros) reducido para realizar estimaciones tempranas, que contenga los bucles de realimentación básicos de cualquier PDS, pequeño y mediano. Siguiendo los consejos de Eberlein, en la obtención del MDR hemos partido de un modelo dinámico ya existente: el Modelo de Abdel-Hamid y Madnick [ABDE 91@. La elección de este modelo1 se ha debido, fundamentalmente, por ser: x El modelo dinámico por excelencia, referencia obligada en la creación de los modelos dinámicos posteriores a él. Además, se dispone de una amplia información tanto del modelo como de los resultados obtenidos por sus autores. 1 Ver Anexo A.1. MODELO DINÁMICO REDUCIDO 5 x Es un modelo dinámico susceptible de ser reducido por el número de ecuaciones y bucles de realimentación que posee. x Y en definitiva, es un modelo dinámico que recoge gran parte de las políticas de gestión aplicables a los PDS, así como los modos de comportamiento de los mismos. En los siguientes apartados, se intentará ampliar las consideraciones 1 y 2 realizadas anteriormente. La reducción del número de atributos conseguida con el MDR se verá en el apartado de validación del modelo. 2.1. Modelos estáticos y modelos dinámicos de estimación La aplicación de la Dinámica de Sistemas a los PDS nos permite considerarlos como sistemas dinámicos socio-tecnológicos complejos, cuya evolución temporal vendrá dada tanto por su estructura interna como por las políticas de dirección empleadas, y las relaciones establecidas entre el personal técnico que participa en el proyecto. La anterior definición, permite desarrollar modelos multivariables dinámicos para describir los procesos mentales seguidos por los gestores de proyectos en la toma de decisiones, en muchas ocasiones basados exclusivamente en la experiencia y, lo que es más importante, poder simular el comportamiento del modelo en base a las decisiones tomadas. Los modelos dinámicos de PDS se pueden dividir en dos categorías: 1. Los de carácter general, creados para simular entornos específicos de desarrollo dentro de una determinada organización, que permiten analizar el comportamiento de sus proyectos ante diferentes políticas de gestión como los recogidos en [ABDE 91@, [LIN 91@, [SMIT 93@,[RODRI 97@2 entre otros. 2. Los de carácter específico, para analizar problemas concretos presentados en la gestión de un PDS como los recogidos en [ARAN 93@, [CHIC 93@2 entre otros. Para poder simular los modelos de carácter general anteriores se necesita conocer de antemano: por un lado, las estimaciones iniciales del proyecto (recursos asignados inicialmente al proyecto, como esfuerzo, tiempo, número medio de técnicos, etc.) para lo que se utilizará cualquiera de los métodos tradicionales conocidos y la experiencia del responsable del proyecto y, por otro lado, es necesario definir, también inicialmente, una serie de atributos, que vienen dados por relaciones tipo tabla (variación de una variable respecto a otra) y por parámetros o constantes. Estas tablas y parámetros permiten definir, para cada proyecto, no sólo las características del entorno de desarrollo del proyecto y las características de la 2 Estas referencias y otras referencias comentadas se pueden encontrar en la página web http://www.sc.ehu.es/jiwdocoj/remis/docs/modelos.html. MODELO DINÁMICO REDUCIDO 6 empresa u organización que realiza el desarrollo, sino también las diferentes políticas de gestión que se aplican sobre el proyecto. Las características relativas al proyecto serán específicas para cada uno de ellos, dentro de una misma organización, mientras que las características relativas a la organización suelen permanecer constante o variar poco entre un proyecto y otro, ya que la organización seguirá siendo, básicamente, la misma. Por otro lado, frente a los modelos dinámicos de estimación se encuentran los modelos estáticos (o tradicionales). Entre los modelos estáticos de estimación destacaremos, por ser los más utilizados, los modelos de estimación empíricos univariables estáticos [PRES 97]. Estos modelos utilizan fórmulas derivadas empíricamente (obtenidas a partir de una muestra reducida de proyectos) para predecir los datos requeridos y vienen dado por una relación del tipo siguiente (1): (1) Recurso a b (Variable Estimada)c u donde “Recurso” puede ser el esfuerzo (E), medido normalmente en técnicos-mes, el tiempo de desarrollo, el número de técnicos, o las líneas de documentación técnica, “a”, “b” y “c” son constantes empíricas derivadas de la muestra de proyectos utilizada y “Variable Estimada” puede ser el número de miles de líneas de código fuente (KLDC) o Puntos de Función (PF), el esfuerzo u otra característica del software estimada previamente. Para utilizar estos modelos sólo se necesita conocer, básicamente, el tipo de los PDS que se utilizaron en la muestra que sirvió de base para su elaboración y la estimación previa del tamaño del producto a desarrollar. Entre los muchos modelos de estimación orientados a LDC para estimar el esfuerzo requerido (E) destacamos los siguientes: x El Modelo de Walston-Felix x El Modelo de Bailey-Basili x Los modelos de Boehm (se verán a continuación) x El Modelo de Doty para KLDC > 9 Y entre los modelos de estimación orientados a PF, centrados también en la estimación del esfuerzo requerido (E), destacamos los siguientes: x El Modelo de Albretch-Gaffney x El Modelo de Kemerer x El Modelo de Matson-Barnett-Mellichamp E5.2(KLDC) 0.91 u E 5.5 0.73 (KLDC)1.16 u E 5.288 (KLDC)1.047 u E 13.39 0.054 PF  u E 60.62 7.728 10 8PF3 uu  u E = 585.7 15.12 PF u MODELO DINÁMICO REDUCIDO 7 Los modelos anteriores están basados, generalmente, en muestras relativamente pequeñas de PDS que pertenecen a entornos de desarrollo muy concretos y organizaciones específicas, por lo que es de esperar que cada uno producirá resultados diferentes para el mismo valor de KLDC y PF. La no portabilidad de los modelos de estimación empírica fue demostrada por Mohanty [MOHA 81]. La aplicación de diferentes modelos de estimación empírica para un mismo proyecto dio como resultado una diferencia entre la mayor y la menor estimación del 65 %. Mohanty resalta en su estudio la importancia que tienen en los modelos de estimación, no sólo los aspectos técnicos del entorno de desarrollo sino también las diferentes políticas de gestión que se aplican. Estas políticas dependen de las características de la propia organización e inclusive de los propios directores de proyectos, aspectos que la mayoría de estos modelos no consideran. Entre los modelos de este tipo COCOMO (COnstructive COst MOdel) desarrollado por Barry Boehm en 1981 [BOEH 81] y actualizados con el nombre de COCOMOII3 está considerado como el modelo empírico más completo y utilizado tradicionalmente. Según R. Pressman [PRES 97]: “COCOMO es el modelo empírico más completo para la estimación del software publicado hasta la fecha”. COCOMO, pensado como una jerarquía de modelos, contempla las etapas de Análisis/Diseño, Codificación y Prueba, y considera que los requisitos software definidos inicialmente no se van a modificar una vez que el proyecto haya comenzado4. Cada uno de los modelos COCOMO están definidos para tres tipos de proyectos software, que según la terminología de Boehm [BOEH 81] son: 1. Modo orgánico: proyectos software pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre un conjunto de requisitos poco rígidos. 2. Modo semiacoplado: proyectos software intermedios, en tamaño y complejidad, en los que equipos con variados niveles de experiencia deben satisfacer requisitos poco o medio rígidos. 3. Modo empotrado: proyectos software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringido. A continuación presentamos un breve resumen de cada uno de los modelos COCOMO, destacando exclusivamente los aspectos más relevantes para el análisis comparativo que realizaremos en el siguiente apartado: 3 Ver http://sunset.usc.edu/research/COCOMOII/index.html. 4 En este sentido es similar al Modelo de Abdel-Hamid y Madnick. MODELO DINÁMICO REDUCIDO 8 x El Modelo COCOMO Básico es un modelo que calcula el esfuerzo (y por tanto el coste) del desarrollo de software a partir del tamaño del producto medido en líneas de código fuente. Este modelo es aplicable en las primeras etapas del proyecto, cuando no se conoce en profundidad el proyecto a realizar, por la poca información que se requiere para su utilización. Viene dado por las ecuaciones siguientes (2) (3): siendo E el esfuerzo necesario en técnico-mes, D el tiempo de desarrollo en meses cronológicos, KLDC el número estimado de miles de líneas de código fuente y “a”, “b”, “c” y “d” son constantes empíricas específicas para el Modelo Básico cuyos valores dependerán del tipo de proyecto. x El COCOMO Intermedio es una ampliación del modelo anterior que incorpora un conjunto de “atributos o guías de coste”. Calcula el esfuerzo del desarrollo de software a partir de una relación similar a la anterior (2) multiplicada por el denominado FAE (Factor de Ajuste del Esfuerzo). Para obtener el FAE es necesario evaluar un total de 15 “guías de coste” o atributos agrupados en cuatro categorías: atributos del proceso de producción o proyecto, atributos del producto a desarrollar, atributos del hardware que se utilizará y atributos del personal que va a participar en el proyecto. Por tanto, este modelo se puede aplicar cuando, además del tamaño del producto software en miles de líneas de código fuente, se dispone de una mayor información sobre diferentes aspectos, tanto del producto y del proyecto como del hardware y del personal. Cada uno de los 15 atributos es valorado en una escala de 6 puntos (desde “muy bajo” a “extra alto” en importancia). A partir de esta evaluación se obtiene un multiplicador de esfuerzo a partir de las tablas publicadas por Boehm [BOEH 81]. Con el producto de todos los multiplicadores de esfuerzo se obtiene el FAE cuyos valores típicos van de 0.9 a 1.4. Con esto la ecuación del Modelo Intermedio toma la forma siguiente (4): Donde, “a” y “b” son constantes empíricas específicas para el Modelo Intermedio cuyos valores dependerán del tipo de proyecto. x El COCOMO Avanzado es un modelo que incorpora todas las características del modelo anterior pero realiza una evaluación de las “guías de coste” para cada una de las etapas que considera Boehm (Análisis/Diseño, Codificación y Prueba) y, por tanto, se puede aplicar cuando se tiene un conocimiento específico sobre cada una de las etapas básicas del proyecto. 2.1.1 Comparación A continuación, vamos a realizar una comparación entre los modelos dinámicos de carácter general y la jerarquía de modelos de estimación empíricos-estáticos creados por Boehm. y (3) D c (E)d bb u (2) E a (KLDC)b bb u (4) E (ai(KLDC)bi)FAE uu MODELO DINÁMICO REDUCIDO 9 Utilizando una nomenclatura similar a la de Boehm, podríamos clasificar a los modelos dinámicos en tres grupos: Modelos Dinámicos Básicos, Modelos Dinámicos Intermedios y Modelos Dinámicos Avanzados, dependiendo del nivel de detalle de información que necesitemos para poderlos utilizar y del nivel de detalle que proporcionan. En el Cuadro 1, se recogen los modelos empíricos-estáticos desarrollados por Boehm frente a la clasificación dada anteriormente para los modelos dinámicos. La comparación de los modelos dinámicos de propósito general, que se han desarrollado hasta la fecha, con los modelos estáticos nos ha llevado a la consideración de que los modelos dinámicos actuales estarían, salvando las diferencias, en el nivel del Modelo Intermedio propuesto por Boehm, es decir, podemos encuadrarlos dentro del grupo denominado Modelos Dinámicos Intermedios. Estos modelos dinámicos necesitan para poder ser utilizados, del conocimiento de un número importante de atributos del proyecto y de la organización de desarrollo, como se ha comentado anteriormente y se aplican globalmente a un PDS. MODELOS COCOMO MODELOS DINÁMICOS COCOMO BÁSICO MODELO DINÁMICO BÁSICO (Modelo Dinámico Reducido) COCOMO INTERMEDIO MODELOS DINÁMICOS INTERMEDIOS (Abdel-Hamid y Madnick, Draper, SEPS, etc) COCOMO AVANZADO MODELOS DINÁMICOS AVANZADOS ( ? ) Cuadro 1: Comparación de los Modelos COCOMO con los Modelos Dinámicos para PDS. En el recuadro correspondiente a modelos dinámicos aplicables en las primeras etapas del proyecto, es decir, los modelos dinámicos encuadrados en el grupo de Modelos Dinámicos Básicos, entrarían aquellos modelos que puedan ser utilizados cuando se tiene poca información sobre el proyecto a realizar y necesitamos tener una primera aproximación de cuál podría ser la evolución de las variables fundamentales del mismo. Actualmente, no conocemos modelos dinámicos de este tipo. Consideramos que este hueco quedaría cubierto con la creación del MDR ya que, como veremos a continuación, el número de atributos que necesitamos conocer para simular el modelo se reduce aproximadamente a la mitad, utilizando como base de comparación el Modelo de Abdel-Hamid y Madnick [ABDE 91@ al que por comodidad, llamaremos simplemente Modelo Dinámico Intermedio (en adelante MDI). Por otro lado, en el grupo denominado Modelos Dinámicos Avanzados entrarían los modelos dinámicos que estén pensados y puedan ser aplicados, específicamente, en cada una de las etapas básicas del ciclo de vida de un PDS. La utilidad de estos modelos sería doble: por un lado, permitiría analizar de manera aislada las singularidades de cada etapa fundamental del ciclo de vida y, por otro, permitiría enlazar los resultados de una etapa con la siguiente para analizar las repercusiones que tiene una etapa concreta sobre el resto del proyecto. MODELO DINÁMICO REDUCIDO 16 nuevas (síndrome del 90 %). Estas tareas nuevas aumentarán con el número de tareas descubiertas no previstas. Las modificaciones de las estimaciones iniciales se llevan a cabo mediante la llamada presión del proyecto (5), la cual viene dada por la diferencia existente, en cada momento, entre el esfuerzo estimado para acabar, que dependerá del progreso del proyecto y de las tareas nuevas que se vayan incorporando al mismo, y el esfuerzo pendiente para acabar según lo previsto [ABDE 91]: (5) Presión = (Esfuerzo Estimado - Esfuerzo pendiente)/Esfuerzo Pendiente Por tanto, si la presión es positiva indicará que el proyecto se está retrasando y si es negativa indicará que se esta adelantando respecto a lo previsto. Tiempo Transcurrido Tiempo pendiente Tamaño proyecto en tiempo Esfuerzo total gastado Esfuerzo pendiente para acabar Ajuste del esfuerzo Tamaño proyecto en esfuerzo Tareas descubiertas Esfuerzo estimado para acabar Tareas nuevas Tamaño proyecto en tareas Tareas pendientes Tareas acabadas Esfuerzo diario Técnicos Necesarios Despido Contratación Técnicos Comunicación Errores Aprendizaje Productividad Dedicación real Presión Figura 6: Diagrama causal del Modelo Dinámico Reducido. Una presión positiva o negativa modifica las variaciones producidas en las previsiones aumentando o disminuyendo, respectivamente, mediante las actividades de contratación o despido, el número de técnicos en el proyecto (6), que también dependerá de la rotación de los mismos (tiempo medio de un técnico en la empresa). Lo anterior, afectará al esfuerzo diario disponible para la realización de tareas y a la productividad de los técnicos y por tanto al progreso del proyecto. (6) d Técnicos / d t = Contratación - Despido - Rotación La relación entre el nivel de técnicos y la productividad no es lineal. Al aumentar el nivel de técnicos aparecen dos tipos de pérdidas de productividad: las debidas a las líneas de MODELO DINÁMICO REDUCIDO 17 comunicación (oral y escrita) que se establecen en el equipo de trabajo y las debidas a las actividades de formación y adecuación llevadas a cabo por el personal experto para integrar al personal inexperto en el proyecto. La productividad también se verá afectada de manera positiva al aumentar la dedicación real de los técnicos. Este aumento de la dedicación viene producido por una eliminación de los tiempos muertos, motivada por un incremento de la presión, y del nivel de aprendizaje y conocimiento que tienen los técnicos sobre el proyecto, lo cual irá aumentando con el progreso del mismo. Lo anterior, recogido en el diagrama de la Figura 6, se puede ver en (7), donde se representa las variables que afectan a la productividad haciendo que aumente o disminuya (  (7) Productividad = f (Técnicos +, Comunicación / formación -, Dedicación +, Aprendizaje +) Por otro lado, cuando la presión es positiva se suele corregir el retraso detectado actuando, además de sobre el número de técnicos, sobre la dedicación real de los técnicos al proyecto y/o reduciendo los niveles de calidad del producto final. Estos factores actúan de manera directa sobre la generación de errores, debido al aumento de personal inexperto en el proyecto, a la aparición de los síntomas de cansancio de los técnicos y a la disminución del esfuerzo diario dedicado a revisión. En contraposición, cuanto mayor es el número de errores producidos, mayor será el esfuerzo necesario para detección y revisión de errores, en detrimento del esfuerzo diario para realización de tareas. En definitiva, los comportamientos más usuales en los modelos dinámicos de PDS dependen del conocimiento que se tenga en cada momento de la presión, tanto en plazo o como en esfuerzo. Estos comportamientos están recogidos también en el MDR y se resumen a continuación. Cuando la presión es positiva se consideran tres tipos de acciones: 1. Aumentar el nivel de recursos humanos del proyecto incrementando el número de técnicos, mediante las actividades de contratación, que dependerá de los técnicos necesarios y del tiempo que quede para acabar el proyecto. A consecuencia de ello, la productividad se verá modificada doblemente, por un lado, disminuirá debido al aumento de las líneas de comunicación que se establece en el equipo de trabajo y al aumento del esfuerzo requerido para las actividades de adecuación y formación de los nuevos técnicos y, por otro lado, aumentará por el incremento de técnicos que se ha producido en el proyecto. 2. Aumentar la dedicación al proyecto, debido a una mayor eficiencia de los técnicos bien por aumentar éstos su dedicación a actividades propias del proyecto frente a otros tipos de actividades ajenas al mismo o bien por aumentar el número de horas de dedicación al mismo. En cualquier caso, al incrementar el trabajo extraordinario habrá que considerar los efectos que tiene el agotamiento del personal sobre la tasa de generación de errores. MODELO DINÁMICO REDUCIDO 18 3. Disminuir el esfuerzo dedicado a las actividades de revisión para dedicarlo a actividades propias de producción. Esto produce un aumento de la productividad de los técnicos pero disminuye la calidad del producto obtenido al ser mayor la probabilidad de errores. Cuando la presión es negativa se consideran dos tipos de acciones: 1. Disminuir el número de técnicos asignados al proyecto mediante las actividades de despido. 2. Disminuir la dedicación de los técnicos a actividades propias del proyecto, es decir, se produce el efecto de relajación. El cual, si no se controla, puede provocar posibles retrasos no esperados en el proyecto. 3.3. Tamaño del Modelo Dinámico Reducido frente al Modelo Dinámico Intermedio Con los criterios de reducción anteriores, el tamaño del MDR es de aproximadamente la mitad (Cuadro 2) del Modelo Dinámico Intermedio, habiéndose conseguido eliminar algunas variables, tablas y parámetros difíciles de evaluar para muchas empresas de desarrollo, como el tiempo de recuperación de los técnicos cuando realizan horas extras, el tiempo que están dispuestos a sobretrabajar, el esfuerzo necesario por error en la fase de pruebas, el cansancio de los técnicos medidos en unidades de agotamiento, etc. SUBSISTEMAS Parámetros (P) Tablas (T) Ecuaciones Total (P+T) MDR MDI MDR MDI MDR MDI MDR MDI Recursos Humanos 6 7 0 0 13 23 6 7 Asignación 0 2 0 2 7 22 0 4 Calidad 1 2 4 6 19 34 5 8 Desarrollo 3 6 5 8 28 43 8 14 Pruebas - 4 - 3 - 30 - 7 Control 1 4 4 5 32 52 5 9 Total 11 25 13 24 99 204 24 49 Cuadro 2: Reducción obtenida con el MDR al compararlo con el MDI. Podemos comprobar, que el número de ecuaciones ha pasado de 204 en el MDI, a 99 en el MDR, sin considerar en ambos casos el Subsistema de Planificación y el apartado correspondiente a estimaciones iniciales, lo que supone una reducción del 48,5 %. En el Cuadro 3, se recogen los porcentajes de reducción, en cuanto al número de parámetros y tablas. En dicho cuadro, podemos observar que la mayor reducción se ha conseguido en el Subsistema de Producción de Software y en el Subsistema de Control, casi un 61 y un 44 por ciento respectivamente. La reducción total en este caso, es decir considerando sólo los parámetros y tablas, ha sido de un 51 %. MODELO DINÁMICO REDUCIDO 19 SUBSISTEMAS % DE REDUCCIÓN Recursos Humanos 14.28 Producción de Software 60.60 Control 44.44 Total 51 Cuadro 3: Porcentaje de reducción obtenido con el MDR al compararlo con el MDI. 4. VALIDACIÓN DEL MODELO DINÁMICO REDUCIDO En este apartado se presentan los resultados obtenidos con el MDR al simular el comportamiento del proyecto que hemos denominado CASO 1 y del proyecto denominado CASO 2. El proyecto CASO 1 fue el proyecto utilizado por los autores Abdel-Hamid y Madnick en la validación del Modelo Dinámico Intermedio [ABDE 91]. El proyecto CASO 3, es un proyecto real desarrollado en una empresa de nuestro entorno y del que se desconocía inicialmente un número importante de atributos. 4.1 Resultados obtenidos con el proyecto CASO 1 En este apartado veremos como el MDR es capaz de reproducir los patrones de evolución del proyecto CASO1. En las Figuras 7, 8 y 9, aparece la evolución de algunas de las variables del MDR frente a la evolución de esas variables en el MDI. En la Figura 7, observamos que el número de errores en el MDR al final del proyecto es menor que en el MDI pero el comportamiento es similar, es decir, podemos afirmar que la evolución del número de errores en el proyecto aumentará gradualmente durante las etapas primeras e intermedias del ciclo de vida y que se producirá un salto importante al final del mismo. 400 días 400 días 14 error 14 error 300 días 300 días 0 error 0 error 0 40 80 120 160 200 240 280 320 Días E volució n d el tiem p o en el M D R días E vo lució n d el tiem p o en el M D I días Evolución del número de errores en el M DR error Evolución del número de errores en el M DI error Figura 7: Evolución del tiempo y del número de errores en el MDR y el MDI. MODELO DINÁMICO REDUCIDO 20 Igualmente, en la Figura 8, observamos que el tamaño del proyecto en número de tareas en el MDR es menor que en el MDI y, como era de esperar dado que el número de tareas es menor. También es menor el esfuerzo requerido para la realización de estas tareas en el MDR frente al MDI pero en ambos casos, tanto la evolución del esfuerzo necesario como la evolución del tamaño del proyecto en tareas, tienen un comportamiento similar. 650 tarea 650 tarea 2000 técnicos-día 2000 técnicos-día 300 tarea 300 tarea 1,000 técnicos-día 1,000 técnicos-día 0 40 80 120 160 200 240 280 320 Días Evolución del núm ero de tareas en el M DR tarea Evolución del núm ero de tareas en el M DI tarea Evolución del esfuerzo en el M DR técnicos-día Evolución del esfuerzo en el M DI técnicos-día Figura 8: Evolución del tamaño del proyecto en tareas y del esfuerzo en el MDR y el MDI. En la Figura 9, observamos que la evolución del número de técnicos y de la productividad del MDR se ajusta bastante a la del MDI. 2 tareas/técnicos-día 2 tareas/técnicos-día 15 técnicos 15 técnicos .5 tareas/técnicos-día .5 tareas/técnicos-día 1 técnicos 1 técnicos 0 40 80 120 160 200 240 280 320 Días Evolución de la productividad en el MDR tareas/técnicos-día Evolución de la productividad en el MDI tareas/técnicos-día Evolución del número de técnicos en el MDR técnicos Evolución del número de técnicos en el MDI técnicos Figura 9: Evolución de la productividad y el número de técnicos en el MDR y el MDI. A la vista de estos resultados, podemos decir que se ha perdido en precisión debido a que el MDR no considera aspectos del proceso de desarrollo incluidos en el MDI, pero que se ha ganado en oportunidad (prontitud) debido a la dificultad que se tiene para realizar estimaciones en las etapas tempranas del proyecto. Por otro lado, podemos decir que el MDR es poco adecuado para obtener valores cuantitativos de las variables del modelo, pero proporciona una información valiosa desde el punto de vista cualitativo en el sentido de que podremos decir si el coste, tiempo de entrega, calidad o cualquier otra variable que se desee MODELO DINÁMICO REDUCIDO 21 analizar aumentará, disminuirá o se mantendrá constante durante las diferentes etapas del proyecto. En estas etapas, en la que se tiene poca información sobre el PDS, el MDR proporciona un apoyo importante al responsable del proyecto al poderse obtener una primera aproximación de cómo será el comportamiento de las variables más importantes del mismo. 4.2. Resultados obtenidos con el proyecto CASO 2 4.2.1. Introducción El proyecto de desarrollo de software denominado “Subsistema de Gestión de Concursos” (en adelante CASO 2) se realizó conjuntamente por las empresas SADIEL y SOPLATA [SADI 92] . La Gestión de Concursos es un subsistema de información de gran importancia en la Gestión de la Situación del Personal del S.I.G.P8 de la Junta de Andalucía, tanto por el elevado volumen de información que recibe tratamiento de cada concurso, como por la necesaria agilidad que se debe proporcionar en la resolución de los mismos. Básicamente, la gestión de concursos comprende un ciclo de tratamiento que consta de: x Definición de la convocatoria. x Recepción y registro de las instancia de solicitud de participación. x Comprobación y verificación de las solicitudes y su documentación adicional determinando, en su caso, la validez de datos y exclusiones por no verificación de requisitos. x Baremación de las distintas solicitudes. Grabación de puntuaciones y su comprobación. x Recepción y registro de las instancias de preferencias de puestos. x Comprobación y verificación de las instancias de preferencias de puesto. x Determinación de la resolución provisional. x Gestión y resolución de las reclamaciones planteadas a dicha resolución provisional. x Determinación de la resolución definitiva. Los datos siguientes corresponden a las fases de Diseño, Codificación y Pruebas del sistema. No se consideran, por tanto, las fases de Análisis y las actividades relacionadas con la aceptación final del sistema. Los lenguajes de programación utilizados fueron COBOL y RDB. El sistema fue desarrollado e implantado en un equipo FUJITSU serie K (sistema operativo Unios F5). Los datos métricos documentados fueron el número de técnicos, el tiempo empleado y el esfuerzo necesario, tanto los estimados al principio del proyecto como los valores finales obtenidos. Al no disponer de una historia detallada del proyecto, ha sido fundamental para obtener la información siguiente la colaboración desinteresada del director del proyecto. 8 Sistema Integrado de Gestión de Personal. MODELO DINÁMICO REDUCIDO 22 4.2.2. Datos utilizados A continuación, en el Cuadro 4, se recogen algunos datos de interés utilizados en la simulación del CASO 2 con el Modelo Dinámico Reducido, aportados por el responsable del proyecto, explicándose a continuación la obtención de los datos más relevantes de dicho proyecto. NOMBRE DESCRIPCIÓN VALOR (unidad) DEDIC NOMINAL Dedicación nominal 0.85 (adimensional) DEDICACION FORMACION Dedicación media de los técnicos a formación 0.15 (adimensional) INFRAESF Infraestimación inicial del esfuerzo 48 (%) INFRALDC Infraestimación inicial del tamaño del proyecto 15 (%) INFRATEC Infraestimación inicial del número de técnicos 1 (adimensional) MAX TOLER Máximo aplazamiento en el tiempo de entrega 1.5 (adimensional) MAXTEC Número máximo de técnicos a contratar por cada técnico a tiempo completo 1.5 (técnicos/técnicos) PRODUC POT Productividad Potencial 1 (tarea/técnico-días) RETRASO CONTRAYADEC Retraso medio en la contratación y adecuación de los técnicos contratados 20 (días) RETRASO CORRECCION Retraso medio en las actividades de revisión y corrección 5 (días) RETRASO SALIDA Retraso medio en salir los técnicos del proyecto 1 (días) RETRASO TAREAS Retraso medio en la detección de tareas nuevas 5 (días) ROTACION Tiempo medio de rotación de los técnicos 1000 días Cuadro 4: Otros datos de interés utilizados en la simulación del CASO 2. El tamaño total de este proyecto fue de 135.600 LDC, de las cuales un tercio del código era desarrollo propio y el resto era código reutilizado. El tamaño considerado, 67.800 LDC, se obtiene a partir de (8) [ABDE 91]: (8) Tamaño en LDC = LDC nuevas +LDC muy modificadas + 0.2 * LDC poco modificadas Si consideramos que un 5 % del software reutilizable ha sido muy modificado, obtendremos el tamaño del proyecto CASO 2, será el obtenido en (9): (9) 67.800 = 45.200 + 0.05 * 90.400 + 0.2 * 90.400 El esfuerzo inicial estimado fue de 208 técnicos-día (t-d) mientras que el esfuerzo real fue de 404, por lo que la infraestimación del tamaño del proyecto en esfuerzo fue de un 48 %. El tiempo inicial estimado fue de 101 días hábiles, mientras que el tiempo de entrega real fue de 141. El número inicial de técnicos fue de 5, aunque prácticamente al comienzo del proyecto se incorporó un técnico más, por lo que se considera que la infraestimación inicial del número de técnicos fue de 1. Es decir, que el número medio de técnicos estimados para la ejecución del proyecto coincide con los técnicos que comenzaron su ejecución. Del esfuerzo real gastado, el 85 % se dedicó a Desarrollo y el 15 % a Prueba. Si al esfuerzo dedicado a Desarrollo restamos el dedicado a actividades de SQA y Corrección, un 10 %, MODELO DINÁMICO REDUCIDO 23 obtenemos que el esfuerzo total gastado en actividades de Desarrollo (Diseño, Codificación) fue de 309 t-d. Por tanto, la Productividad media de desarrollo se obtiene según (10) y es la obtenida en (11): (10) Productividad = Tamaño en LDC / Esfuerzo en Desarrollo (11) 219,4 = 67.800 / 309 Para obtener el valor de la Productividad Nominal Potencial tenemos que obtener previamente el valor del Multiplicador de la Productividad debido a pérdidas por Comunicación y Motivación o eficiencia9 (MPCM). Este multiplicador se formula según lo siguiente (12): (12) MPCM = Dedicación Nominal * (1 – Pérdidas por comunicación) Si para el CASO 2 la Dedicación Nominal es del 85 % y las Pérdidas por comunicación se estimaron en un 4 % (el número medio de técnicos fue de 6). El valor de MPCM aparece en (13): (13) 0,81 = 0,85 * (1 – 0,04) Por tanto, la Productividad Nominal Potencial será (14): (14) 219,4 / 0,81 = 270 LDC / t-d Como la Productividad Potencial se ha definido como el esfuerzo necesario para desarrollar una tarea, podemos decir que el tamaño de una tarea para el CASO 2 es de 270 LDC, así la Productividad Nominal Potencial será igual a 1 tarea / t-d. La dedicación media del personal fue del 40 %, obtenida a partir de los datos estimados para el esfuerzo, número de técnicos y tiempo de entrega (15) y (16): (15) 208 t-d / 5 técnicos = 41 días si estuvieran trabajando a tiempo completo (16) 41 días / 101 días = 0.4 Por otro lado, el número de técnicos nuevos que se asignan al proyecto está en una relación de 3 técnicos nuevos por cada dos técnicos expertos por lo que el valor del número máximo de técnicos a contratar por cada técnico experto es de 1.5. 4.2.3. Análisis de la información obtenida A continuación, Figuras 10 y 11, se presentan las curvas de la evolución del coste, tiempo de entrega, productividad y calidad obtenidas con el Modelo Dinámico Reducido para el proyecto CASO 2. En la Figura 10, se muestra la evolución del tiempo de entrega y del 9 Recoge las pérdidas de productividad debido a las líneas de comunicación (oral/escrita) que se establece en el equipo de trabajo y las pérdidas/aumento de productividad debido al efecto de la motivación de los técnicos en el proyecto. MODELO DINÁMICO REDUCIDO 24 esfuerzo necesario. Según los datos obtenidos en la simulación del CASO 2 el tiempo real de entrega sería de 151 días en lugar de los 141 y el esfuerzo necesario sería de 410 en lugar de los 404 reales. Lo que implica que ha existido una desviación de un 7 % y un 1.5 %, aproximadamente, entre el tiempo y el esfuerzo obtenido en la simulación y el tiempo de entrega y el esfuerzo real respectivamente. 500 t-d 200 días 250 tareas 350 t-d 150 días 125 tareas 200 t-d 100 días 0tareas 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 días Esfuerzo necesario t-d Tiempo de entrega días Tareas pendientes tareas Figura 10: Evolución del esfuerzo necesario, el tiempo de entrega y el número de tareas pendientes en el CASO 2. En la Figura 10, vemos que las primeras correcciones importantes en el esfuerzo necesario y en el tiempo se producen casi a la mitad del proyecto, cuando se detecta que el número de tareas pendientes para acabar es mayor del previsto. Este hecho coincide con la evolución real del CASO 2. Es decir, se ha consumido más de la mitad del tiempo estimado y aún queda más de la mitad de las tareas por realizar. Si la pendiente de la curva que nos representa la evolución de las tareas pendientes por acabar no se modificase, perjudicaría seriamente tanto al tiempo como al esfuerzo final. Se constata también, que como en la mayoría de los proyectos, se suele modificar antes las previsiones en esfuerzo que en tiempo y que es a la mitad del proyecto, aproximadamente, cuando se producen las primeras modificaciones en el tiempo de entrega. Vemos también, que las modificaciones en esfuerzo y tiempo se realizan de manera simultánea. El comportamiento del tiempo y el esfuerzo estimado mediante la simulación, según la opinión del responsable del proyecto, coincide con el comportamiento que se tuvo en este proyecto, especialmente en dos aspectos: 1. Las primeras revisiones se hicieron cuando se había superado la mitad del tiempo estimado. 2. Las revisiones realizadas para ajustarse a las desviaciones detectadas afectaron paralelamente al tiempo y al esfuerzo. MODELO DINÁMICO REDUCIDO 25 En la Figura 11, aparece la evolución de la productividad media del equipo y el número de errores cometidos. En esta figura, observamos que se producen tres picos en la productividad. Podemos comprobar cómo existe una estrecha relación entre la evolución de la productividad y el número de errores producidos. Por otro lado, los dos primeros picos de la productividad coinciden con el comienzo de la etapa de codificación y la etapa de pruebas del sistema. En cuanto al comportamiento de la productividad y el número de errores estimados mediante la simulación, según la opinión del responsable del proyecto, en este caso no coincide completamente con su experiencia personal en gestión de proyectos, aunque los datos simulados en este caso no pueden compararse con los datos reales de la productividad y el número de errores por no disponer de dicha información. Según el responsable del proyecto la evolución de la productividad y el número de errores coinciden con su experiencia hasta el día 120 aproximadamente. A partir de esta fecha la evolución que debieran seguir ambas variables viene reflejada, en línea gruesa, en la Figura 11. Esto es así por lo siguiente: x A partir del día 100, aproximadamente, comienza la etapa de Pruebas del sistema, en la que se es consciente de los problemas que se producen en la misma, en un proyecto en el que se sabe que no se están cumpliendo las previsiones de tiempo ni de coste. Ante esta situación, es normal que aumente la productividad media del equipo de trabajo y ésta no debe bajar hasta que el proyecto esté finalizado. x Por otro lado, es usual que el número de errores aumente al comienzo de la etapa de Codificación, alrededor del día 70, disminuyendo al final de la misma y que se vuelvan a detectar nuevos errores en la etapa de Pruebas, alrededor del día 100. Conforme se avanza en esta etapa, una vez detectados los errores, éstos deben empezar a disminuir. Por tanto, hasta el día 120 el comportamiento experimentado con el simulado coinciden pero a partir de esa fecha, en la que se está terminando la etapa de pruebas y por tanto el proyecto, el número de errores debe disminuir. 3tareas/t-d 40 errores 2.37 tareas/t-d 30 errores 1.75 tareas/t-d 20 errores 1.12 tareas/t-d 10 errores .5 tareas/t-d 0errores 0 20 40 60 80 100 120 140 días Productividad tareas/t-d Errores errores Figura 11: Evolución de la productividad y el número medio de errores producidos en el CASO 2. MODELO DINÁMICO REDUCIDO 32 En la Figura 16, mostramos la relación entre la dedicación media de los técnicos en el proyecto y la dedicación media a formación obtenida con el MDR para los casos que hacen BUENO, simultáneamente, el tiempo y el coste del CASO 2. Podemos comprobar, aunque los casos encontrados sean poco significativos por ser sólo cinco, que la dedicación media de los técnicos toma valores altos y que la dedicación media a formación toma valores comprendidos entre un 10 y un 20 %. 0 0,1 0,2 0,3 0,4 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 Dedicación media Dedicación a formación Media Alta Ba j a Media Alta Baja Figura 16: Relación entre la dedicación media de los técnicos en el proyecto y la dedicación a formación en los casos en los que se hacen BUENO, simultáneamente, el coste y el tiempo del CASO 2. 6. CONCLUSIONES Con la construcción del MDR se ha creado un modelo dinámico, que simule el comportamiento básico de los PDS, completo, sencillo y fácil de entender. El MDR es una herramienta útil que puede ser utilizado para realizar estimaciones y analizar el comportamiento de un PDS, en especial, en los siguientes casos: x Cuando aún se dispone de poca información sobre el mismo, normalmente en los primeros contactos con el cliente, al igual que se utiliza el Modelo de COCOMO Básico frente a los Modelos de COCOMO Intermedio y Avanzado. x Cuando la empresa de desarrollo no dispone de una base histórica de proyectos o ésta no es lo suficientemente completa para poder definir en las primeras etapas un número importante de atributos del proyecto y del proceso de desarrollo. x Cuando tenemos que enseñar al personal novel en gestión de PDS el comportamiento básico de un proyecto. El MDR se ha validado con el proyecto CASO 1 y con un PDS real, el CASO 2, y se han obtenido para ambos proyectos reglas de gestión que hubiesen mejorado los resultados finales. Actualmente estamos trabajando en la validación del MDR con diferentes proyectos para conocer en qué grado se ajusta este modelo a los proyectos realizados en diferentes entorno de trabajo. MODELO DINÁMICO REDUCIDO 33 Por último indicar, que aunque el MDR se puede utilizar en etapas tempranas de nuestro proyecto y facilita su estimación, tenemos que ser consciente de que al utilizarlo se pierde en la precisión de dicha estimación, si lo comparamos con el MDI, debido al nivel de reducción realizada. 7. BIBLIOGRAFÍA [ABDE 91] Abdel-Hamid T. K., Madnick S.E.; “Software Project Dynamics. An Integrated Approach”. Prentice-Hall, New Jersey 1991. [ABDE 93] Abdel-Hamid T. K., “A multiproject Perspective of Single-Project Dynamics”. Jounal Systems Software, Nº 22, pp.: 151-165, 1993. [ARAN 93] Aranda A., Friddman T., Oliva R.; “Quality MicroWorlds: Modelling the Impact of Quality Initiatives Over the Software Product Life Cycle”. American Programmer, pp.: 52-61. Mayo 1993. [BOEH 81] Boehm B.; “Software Engineering Economics”. Prentice-Hall, New Jersey 1981. [CHIC 93] Chichakly K. J.; “The Bifocal Vantage Point. Managing Software Projects from a Systems Thinking Perspective”. American Programmer, pp.: 18-25. Mayo 1993. [EBER 89] Eberlein R. L.; “Simplification and understanding of models”. System Dynamics Review, System Dynamics Society. Nº 5, 1:51-68, 1989. [LIN 93] Lin C. Y.; “Walking on Battlefields: Tools for Strategic Software Management”. American Programmer. Mayo 1993. [MOHA 81] Mohanty S. N.; “Software Cost Estimation: Present and Future”. SofwarePractice and Experience, Vol. 11, pp.: 103-121, 1981. [PRES 97] Pressman R. S.; “Ingeniería del Software. Un enfoque práctico”. McGraw-Hill 1997. [PUTN 96] Putnam L. H., Myers W.; “Executive Briefing. Controlling Software Development”. IEEE Computer Society Press 1996. [RAMO 97a] Ramos I.; Ruiz M.: “Análisis de las estructuras dinámicas comunes a los Proyectos de Desarrollo de Software y a los Proyectos de Investigación y Desarrollo”. III Jornadas de Informática, El Puerto de Santa María, pp.: 127136, 1997. [RAMO 97b] Ramos I.; Ruiz M.; “Modelo Dinámico simplificado para la gestión de MODELO DINÁMICO REDUCIDO 34 proyectos software”, pp.: 146-157. II Jornadas de Ingeniería del Software. San Sebastián 1997. [RAMO 99] Ramos I., Riquelme J. C.; “The Dynamic Models for Software Development Projects and the Machine Learning Techniques”. International Conference on Product Focussed Software Process Improvement. Pp.: 560-574. Oulu (Finland), 1999. [ROBE 81] Roberts E. B.; “A Simple Model of R&D Project Dynamics, Managerial applicatons of Systems Dynamics”. Edited by E. B. Roberts. Cambridge, MA: the MIT. Press 1981. [RODR 97] Rodríguez A. G., Williams T. M.; “System dynamic in software project management: towards the development a formal a integrated framework”. European Journel of Information Systems, nº 6, pp. 51-66, 1997. [RUIZ 00] Ruiz M., Ramos, I.; “A Dynamic Estimation Model for the Early Stages of a Software Project”. Software Process Simulation Modeling Workshop. Londom (U.K.), 2000. [SADI 92] SADIEL, SOPLATA; “Subsistema de Gestión de Concursos”. Presentación y Memoria de Seguimiento Secretaría General para la Función Pública. Junta de Andalucía, 1992. [SMIT 93] Smith B. J, Nguyen N., Vidale R.; “Death of a software manager: How to avoid career suicide through dynamic software process modeling”. American Programmer. Mayo 1993. MODELO DINÁMICO REDUCIDO 35 ANEXOS MODELO DINÁMICO REDUCIDO 36 ANEXO 1:ECUACIONES DEL MODELO DINÁMICO INTERMEDIO A continuación se presentan las ecuaciones de los Subsistemas de Recursos Humanos, Producción y Control del Modelo Dinámico Intermedio [ABDE 91] adaptado al entorno de simulación Vensim. En la cabecera de cada subsistema se indica además del nombre del mismo, el número total de ecuaciones (incluidos parámetros y tablas), parámetros y tablas que lo constituyen (entre paréntesis). Para cada variable se añade las unidades de medida y una breve descripción de la misma. ********************************************************************************************** SUBSISTEMA DE RECURSOS HUMANOS (23 ecuaciones, 7 parámetros, 0 tablas) *********************************************************************************************~ | WFNEW=INTEG((HIRERT-ASIMRT-NEWTRR),0) ~ técnicos ~ Técnicos nuevos. | ASIMRT=WFNEW/ASIMDY ~ técnicos/día ~ Flujo de adaptación o adecuación de los técnicos nuevos en el proyecto. | ASIMDY=20 ~ día ~ Retraso medio en la adaptación de los técnicos nuevos en el proyecto. | AVEMPT=1000 ~ día ~ Tiempo medio de rotación de los técnicos con experiencia en la organización. | ADMPPS=0.5 ~ dmnl ~ Dedicación media diaria de los técnicos en el proyecto. | HIRERT=MAX(0,WFGAP/HIREDY) ~ técnicos/día ~ Número de técnicos contratados. | HIREDY=30 ~ día ~ Retraso medio en la contratación de técnicos. | NEWTRR=MIN(TRNFRT,WFNEW/TIME STEP) ~ técnicos/día ~ Flujo de técnicos nuevos que deben abandonar el proyecto. | EXPTRR=MIN(WFEXP/TIME STEP,TRNFRT-NEWTRR) ~ técnicos/día ~ Flujo de técnicos expertos que deben abandonar el proyecto. | QUITRT=WFEXP/AVEMPT ~ técnicos/día ~ Rotación de los técnicos expertos. | FTEXWF=WFEXP*ADMPPS ~ técnicos ~ Técnicos con experiencia a tiempo completo. | CELNWH=FTEXWF*MNHPXS ~ técnicos MODELO DINÁMICO REDUCIDO 37 ~ Número máximo de técnicos nuevos que se pueden contratar. | MNHPXS=3 ~ técnico/técnico ~ Número máximo de técnicos nuevos que se pueden contratar cada técnico experto a tiempo completo. | CELTWF=CELNWH+WFEXP ~ técnicos ~ Número máximo de técnicos en el proyecto. | FTEQWF=TOTWF*ADMPPS ~ técnicos ~ Número total de técnicos equivalente a tiempo completo. | FRWFEX=WFEXP/TOTWF ~ dmnl ~ Porcentaje de técnicos con experiencia. | TRPNHR=0.25 ~ dmnl ~ Dedicación media de los técnicos expertos a formación. | WFGAP=WFS-TOTWF ~ técnicos ~ Desnivel en el número de técnicos. | TRNFRT=MAX(0,-WFGAP/TRNSDY) ~ técnicos/día ~ Técnicos que sobran en el proyecto. | TRNSDY=10 ~ día ~ Retraso medio en la salida de los técnicos del proyecto. | WFEXP=INTEG((ASIMRT-EXPTRR-QUITRT),WFSTRT) ~ técnicos ~ Número total de técnicos con experiencia. | WFS=MIN(CELTWF,WFNEED) ~ técnicos ~ Número de técnicos deseados o técnicos que pueden incorporarse al proyecto en función de la predisposición a modificar el equipo y en función del número máximo de técnicos en el equipo . | TOTWF=WFNEW+WFEXP ~ técnicos ~ Número total de técnicos con y sin experiencia. | ********************************************************************************************** SUBSISTEMA DE PRODUCCIÓN: ASIGNACIÓN (22 ecuaciones, 2 parámetros, 2 tabla) *********************************************************************************************~ | DMPTRN=WFNEW*TRPNHR ~ técnicos/día ~ Esfuerzo diario para formación de los técnicos nuevos. | CMTRMD=INTEG(DMPTRN,0) ~ técnicos-día ~ Esfuerzo acumulado en formación. | CUMMD=INTEG(TOTDMP,0.0001) ~ técnicos-día ~ Acumulación del esfuerzo total gastado. | DMPATR=TOTDMP-DMPTRN ~ técnicos-día ~ Esfuerzo disponible después de formación. | MODELO DINÁMICO REDUCIDO 38 DMPQA=MIN((AFMPQA*TOTDMP),0.9*DMPATR) ~ técnicos-día/día ~ Esfuerzo diario asignado a calidad. | AFMPQA=ACTIVE INITIAL(PFMPQA*(1+ADJQA),PFMPQA) ~ dmnl ~ Porcentaje actual de esfuerzo asignado a las tareas de calidad. | ADJQA=TADJQA(SCHPR) ~ dmnl ~ Ajuste de la variable “PFMPQA”. | TADJQA(0,=.1,0.2,0.3,0.4,0.5,0,-0.025,-0.15,-0.35,-0.475,-0.5) ~ dmnl ~ Valores de la tabla “ADJQA”. | PFMPQA=TPFMQA(PJBAWK)*(1+QO/100) ~ dmnl ~ Porcentaje de esfuerzo planificado para las actividades de calidad. | TPFMQA(0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1,0.325, 0.29,0.275,0.255,0.25,0.275,0.325,0.375,0.4,0.4,0) ~ dmnl ~ Valores de la tabla “PFMQA”. | CMQAMD=INTEG(DMPQA,0) ~ técnicos-día ~ Esfuerzo acumulado en tareas de calidad. | DMPSWP=DMPATR-DMPQA ~ técnicos-día/día ~ Esfuerzo diario para producción de software. | DESECR=ACTIVE INITIAL(DTCERR/DESRWD,0) ~ errores/día ~ Tasa de corrección de errores deseada. | DESRWD=15 ~ día ~ Retraso medio deseado en la revisión de errores. | DMPRW=ACTIVE INITIAL(MIN((DESECR*PRWMPE),DMPSWP),0) ~ técnicos-día/día ~ Esfuerzo diario asignado para revisión de errores. | PRWMPE=INTEG((RWMPPE-PRWMPE)/TARMPE,0.5) ~ técnicos-día/error ~ Esfuerzo necesario observado por error para revisión. | TARMPE=10 ~ día ~ Tiempo de ajuste de la variable “prwmpe”. | DMPDVT=DMPSWP-DMPRW ~ técnicos-día/día ~ Esfuerzo diario para Desarrollo/Prueba. | DMPSDV=DMPDVT*(1-FREFTS) ~ técnicos-día/día ~ Esfuerzo diario para desarrollo. | DMPTST=DMPDVT*FREFTS ~ técnicos-día/día ~ Esfuerzo diario para pruebas. | TOTDMP=TOTWF*ADMPPS ~ técnicos-día/día ~ Esfuerzo total diario. MODELO DINÁMICO REDUCIDO 39 | CMRWMD=INTEG(DMPRW,0) ~ técnicos-día ~ Esfuerzo acumulado en las actividades de revisión. | ********************************************************************************************** SUBSISTEMA DE PRODUCCIÓN: CALIDAD (34 ecuaciones, 2 parámetros, 6 tablas) *********************************************************************************************~ | AQADLY=10 ~ día ~ Retraso medio en las tareas de calidad. | QART=DELAY3(SDVRT,AQADLY) ~ tareas/día ~ Flujo de realización de las tareas de calidad. | TSKWK=INTEG((SDVRT-QART),0) ~ tareas ~ Nivel de tareas para revisar y corregir. | QO=0 ~ dmnl ~ Objetivo de calidad. | NERPTK=NERPK*DSIPTK/1000 ~ errores/tarea ~ Número nominal de errores por tarea. | NERPK=TNERPK(PJBAWK) ~ errores/kldc ~ Número nominal de errores por kldc. | TNERPK(0,0.2,0.4,0.6,0.8,1,24,22.9,20.75,15.25,13.1,12) ~ dmnl ~ Valores de la tabla “NERPK” | MERGWM=TMEGWM(FRWFEX) ~ dmnl ~ Efecto de la mezcla de técnicos (con y sin experiencia) sobre la generación de errores. | TMEGWM(0,0.2,0.4,0.6,0.8,1,2,1.8,1.6,1.4,1.2,1) ~ dmnl ~ Valores de la tabla “MERGWM”. | MERGSP=TMEGSP(SCHPR) ~ dmnl ~ Efecto de la presión sobre la generación de errores. | TMEGSP(-0.4,-0.2,0,0.2,0.4,0.6,0.8,1,9,0.94,1,1.05,1.14,1.24,1.36,1.5) ~ dmnl ~ Valores de la tabla “MERGSP”. | ERRPTK=NERPTK*MERGSP*MERGWM ~ errores/tarea ~ Número de errores por tarea. | ERRGRT=SDVRT*ERRPTK ~ errores/día ~ Flujo de generación de errores. | PERDRT=DMPQA/QAMPNE ~ errores/día ~ Flujo potencial de detección de errores. | QAMPNE=NQAMPE*(1/MPDMCL)*MDEFED ~ técnicos-día/error MODELO DINÁMICO REDUCIDO 40 ~ Esfuerzo necesario para detectar un error en durante las actividades de calidad. | NQAMPE=TNQAPE(PJBAWK) ~ técnicos-día/error ~ Esfuerzo nominal para detectar un error durante las actividades de calidad. | TNQAPE(0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1,0.4,0.4,0.39,0.375,0.35,0.3,0.25,0.225,0.21,0.2,0.2) ~ dmnl ~ Valores de la tabla “NQAMPE”. | MDEFED=TMDFED(ERRDSY) ~ dmnl ~ Efecto sobre la detección de errores de la densidad de errorores existente. | TMDFED(0,1,2,3,4,5,6,7,8,9,10,50,36,26,17.5,10,4,1.75,1.2,1,1,1) ~ dmnl ~ Valores de la tabla “MDEFED”. | ERRDSY=ANERPT*1000/DSIPTK ~ errores/kldc ~ Densidad de errores. | PTDTER=INTEG((ERRGRT-ERRDRT-ERRSRT),0) ~ errores ~ Errores potencialmente detectables. | ERRDRT=MIN(PERDRT,PTDTER/TIME STEP) ~ errores/día ~ Flujo de detección de errores. | ERRSRT=QART*ANERPT ~ errores/día ~ Flujo de errores no detectados. | CUMTQA=INTEG((QART-TSRATE),0) ~ tareas ~ Número total de tareas revisadas y corregidas. | CMERD=INTEG(ERRDRT,0) ~ errores ~ Número total de errores detectados. | PRCTDT=100*CMERD/(CUMERG+0.001) ~ dmnl ~ Porcentaje de errores detectados. | CMERES=INTEG(ERRSRT,0) ~ errores ~ Número total de errores no detectados. | CUMERG=INTEG(ERRGRT,0) ~ errores ~ Número total de errores generados durante el desarrollo. | RWMPPE=NRWMPE/MPDMCL ~ técnicos-día/error ~ Esfuerzo necesario por error para revisión. | RWRATE=MIN(DTCERR/TIME STEP,DMPRW/RWMPPE) ~ errores/día ~ Flujo de revisión de errores. | DTCERR=INTEG((ERRDRT-RWRATE),0) ~ errores ~ Errores detectados. | CMRWED=INTEG(RWRATE,0) MODELO DINÁMICO REDUCIDO 41 ~ errores ~ Número total de errores revisados durante la etapa de desarrollo. | NRWMPE=TNRWME(PJBAWK) ~ técnicos-día/error ~ Esfuerzo nominal necesario por error para revisión. | TNRWME(0,0.2,0.4,0.6,0.8,1,0.6,0.575,0.5,0.4,0.325,0.3) ~ técnicos-día/error ~ Valores de la tabla “NRWMPE”. | ********************************************************************************************** SUBSISTEMA DE PRODUCCIÓN: DESARROLLO (43 ecuaciones, 6 parámetros, 8 tablas) *********************************************************************************************~ | ANPPRD=FRWFEX*NPWPEX+(1-FRWFEX)*NPWPNE ~ tareas/técnicos-día ~ Productividad potencial nominal media. | AFMDPJ=INTEG(WRADJR,NFMDPJ) ~ dmnl ~ Fracción actual de un técnico-día en el proyecto. | CMDVMD=INTEG((TIME STEP*DMPDVT*(1-FREFTS))/TIME STEP,0) ~ técnicos-día ~ Esfuerzo acumulado en desarrollo. | SDVRT=ACTIVE INITIAL(MIN((DMPSDV*SDVPRD),TSKPRM/TIME STEP),0) ~ tareas/día ~ Flujo de tareas desarrolladas. | FREFTS=TFEFTS(TSKPRM/PJBSZ) ~ dmnl ~ Porcentaje de esfuerzo para pruebas del sistema. | TFEFTS(0,0.04,0.08,0.12,0.16,0.2,1,0.5,0.28,0.15,0.05,0) ~ dmnl ~ Valores de la tabla “TFEFTS”. | SDVPRD=POTPRD*MPDMCL ~ tareas/técnicos-día ~ Productividad media de Desarrollo de Software. | NPWPEX=1 ~ tareas/técnicos-día ~ Productividad potencial nominal de los técnicos con experiencia. | NPWPNE=0.5 ~ tareas/técnicos-día ~ Productividad potencial nominal de los técnicos sin experiencia. | MPPTPD=TMPTPD(PJBAWK) ~ dmnl ~ Multiplicador de la productividad potencial debido al conocimiento de los técnicos adquirido al ir progresando el proyecto. |TMPTPD(0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1,1,1.0125,1.0325,1.055,1.09,1.15,1.2,1.22,1.245,1.25,1.25) ~ dmnl ~ Valores de la tabla “MPPTPD”. | POTPRD=ANPPRD*MPPTPD ~ tareas/técnicos-día ~ Productividad potencial. | MPDMCL=AFMDPJ*(1-COMMOH) ~ dmnl ~ Multiplicador de la productividad debido a los efectos de la motivación de los técnicos y a las líneas de comunicación establecidas en el equipo de trabajo. MODELO DINÁMICO REDUCIDO 48 ~ Porcentaje de tareas adicionales que puede realizarse sin modificar el esfuerzo estimado. | TFAHWO(0,0.2,0.4,0.6,0.8,1,1.2,1.4,1.6,1.8,2,0,0,0,0,0,0,0.7,0.9,0.975,1,1) ~ dmnl ~ Valores de la tabla “FADHWO”. | MSZTWO=0.01 ~ dmnl ~ Porcentaje máximo de tareas adicionales que pueden incluirse en el proyecto sin modificar el tamaño actual del proyecto en esfuerzo. |IRDVDT=(RTINCT/ASSPRD)*(FADHWO) ~ técnicos-día/día ~ Flujo de crecimiento del tamaño del proyecto en esfuerzo para Desarrollo debido a las tareas nuevas. | IRTSDT=(RTINCT/PRTPRD)*(FADHWO) ~ técnicos-día/día ~ Flujo de crecimiento del tamaño del proyecto en esfuerzo para Prueba debido a las tareas nuevas. | JBSZMD=INTEG((IRDVDT+IRTSDT+ARTJBM),DEVMD+TSTMD) ~ técnicos-día ~ Tamaño del proyecto en esfuerzo. |ARTJBM=(MDRPTN+CUMMD-JBSZMD)/DAJBMD ~ técnicos-día/día ~ Flujo de ajuste del tamaño del proyecto en esfuerzo. | DAJBMD=TDAJMD(TIMERM) ~ día ~ Retraso medio en el ajuste de la variable “ARTJBM”. | TDAJMD(0,20,0.5,3) ~ día ~ Valores de la tabla ”DAJBMD”. | MDRM=MAX(0.001,JBSZMD-CUMMD) ~ técnicos-día ~ Esfuerzo que queda para acabar. | TSTPRM=PJBSZ-CUMTKT ~ tareas ~ Tareas que quedan por probar. | TSTSPD=50 ~ día ~ Retraso medio en la productividad de pruebas. | UNDJTK=INTEG((-RTDSTK),RJBSZ-PJBSZ) ~ tareas ~ Tareas no descubiertas. | TSKPRM=PJBSZ-CMTKDV ~ tareas ~ Tareas nuevas estimadas pendientes para realizar. | TSSZMD=INTEG((TIME STEP*(IRTSDT+ARTJBM)*IF THEN ELSE(FREFTS >= 0.9, 1, 0 ) ) /TIME STEP,TSTMD) ~ técnicos-día ~ Técnicos-día planificado para pruebas antes empezar la etapa de prueba. | MODELO DINÁMICO REDUCIDO 49 ANEXO 2: ECUACIONES DEL MODELO DINÁMICO REDUCIDO A continuación se presentan las ecuaciones de los Subsistemas de Recursos Humanos, Producción y Control, en el entorno de simulación Vensim, del Modelo Dinámico Reducido (MDR): - Subsistema de Recursos Humanos. Este subsistema se encarga de controlar el número de técnicos necesarios en el proyecto en función de la información que le llega sobre las previsiones de tiempo y esfuerzo: mediante las actividades de contratación de personal cuando sea necesario aumentar el equipo de trabajo o bien, mediante las actividades de despido de personal cuando sea necesario reducir el número de técnicos en el proyecto. El control de los técnicos se realiza mediante una sola variable de nivel denominada “técnicos” donde se engloban tanto a los técnicos expertos como a los técnicos nuevos. - Subsistema de Producción. Este subsistema se encarga de controlar las tareas de desarrollo y de prueba que se van realizando en función de la productividad media del equipo (tareas desarrolladas o realizadas). El MDR considera dentro de las tareas de desarrollo tanto las tareas de Análisis / Diseño y Codificación como las de Prueba sin distinguir entre unas y otras (Subsistema de Desarrollo). Dentro del subsistema de Producción están englobados además del Subsistema de Desarrollo: el Subsistema de Calidad, que se encarga de revisar y corregir los errores producidos en las tareas que se van realizando, y el Subsistema de Asignación de esfuerzo. Este subsistema asigna el esfuerzo total disponible entre las diferentes actividades del proyecto: formación, desarrollo y calidad. - Subsistema de Control. Evalúa el esfuerzo estimado que queda para acabar el proyecto, en función del trabajo realizado y de los recursos consumidos hasta el momento así como del trabajo que aún queda por realizar. En la cabecera de cada subsistema se indica además del nombre del mismo, el número total de ecuaciones (incluidos parámetros y tablas), parámetros y tablas que lo constituyen (entre paréntesis). Para cada variable se añade las unidades de medida y una breve descripción de la misma. ********************************************************************************************** SUBSISTEMA DE RECURSOS HUMANOS (13 ecuaciones, 6 parámetros, 0 tablas) *********************************************************************************************~ | MAXTEC = 3 ~ técnicos ~ Número máximo de técnicos que pueden contratarse por cada técnico a tiempo completo. | MAXTECCONT = ((TÉCNICOS*POR)*DEDIC)*MAXTEC ~ técnicos ~ Número máximo de técnicos que se pueden contratar. | TECNICOS SOBRANTES = MAX(0,-(TEC BUSCADOS-TECNICOS)/RETRASO SALIDA) ~ técnicos/día ~ Técnicos que sobran en el proyecto. | MODELO DINÁMICO REDUCIDO 50 TEC BUSCADOS = MIN(MAXTECCONT,TECNICOS NECESARIOS) ~ técnicos ~ Número de técnicos necesarios que pueden incorporarse al proyecto en función de las restricciones de contratación y de las estimaciones. |FLUJO SALIDA TECNICOS = MIN(TECNICOS SOBRANTES,TECNICOS/TIME STEP) ~ técnicos/día ~ Técnicos que deben abandonar el proyecto. | ROTACION = 1000 ~ día ~ Tiempo medio de rotación de los técnicos en la organización. | TECNICOS = INTEG((FLUJO CONTRATACION - FLUJO SALIDA TECNICOS - FLUJO ROTACION TECNICOS),TECINI) ~ técnicos ~ Número de técnicos en el proyecto. | RETRASO SALIDA = 10 ~ día ~ Retraso medio en la salida de los técnicos del proyecto. | RETRASO CONTRAYADEC = 50 ~ día ~ Retraso medio en la contratación de técnicos y la adecuación del personal en el proyecto. | FLUJO ROTACION TECNICOS = TECNICOS/ROTACION ~ técnicos/día ~ Número de técnicos que abandonan la organización. | FLUJO CONTRATACION = MAX( 0, (TEC BUSCADOS - TECNICOS)/RETRASO CONTRAYADEC) ~ técnicos/día ~ Número de técnicos contratados. | DEDIC = 0.5 ~ dmnl ~ Dedicación media de los técnicos en el proyecto. | DEDICACION FORMACION = 0.25 ~ día/día ~ Dedicación media diaria de los técnicos a formación. | ********************************************************************************************** SUBSISTEMA DE PRODUCCIÓN: ASIGNACIÓN (7 ecuaciones, 0 parámetro, 0 tablas) *********************************************************************************************~ | ESFUERZO D FORMACION = (TECNICOS/(1-POR)*DEDICACION FORMACION ~ técnicos-día ~Esfuerzo diario asignado a las actividades de formación. | ESFUERZO TOTAL CORRECCION = INTEG(ESFUERZO D CORRECCION,0) ~ técnicos-día ~ Esfuerzo total asignado a las actividades de revisión y corrección. | ESFUERZO TOTAL GASTADO = INTEG(ESFUERZO DIARIO,0.0001) ~ técnicos-día ~ Esfuerzo total gastado. | ESFUERZO D CORRECCION = ESFUERZO D PRODUCCION*PORCENTAJE ESF CORRECCION ~ técnicos-día ~ Esfuerzo diario asignado a las actividades de revisión y corrección. | ESFUERZO D PRODUCCION = ESFUERZO DIARIO-ESFUERZO D FORMACION ~ técnicos-día ~ Esfuerzo diario asignado para la realización de tareas productivas (Desarrollo y Corrección y Revisión) una vez deducido el esfuerzo dedicado a formación. | ESFUERZO D REALIZAR TAREAS = ESFUERZO D PRODUCCION*(1-PORCENTAJE ESF CORRECCION) MODELO DINÁMICO REDUCIDO 51 ~ técnicos-día ~ Esfuerzo diario asignado a las tareas productivas una vez deducido el esfuerzo asignado a las tareas de Corrección y Revisión. | ESFUERZO DIARIO = TECNICOS*DEDIC ~ técnicos-día ~ Esfuerzo diario disponible. | **************************************************************************************** SUBSISTEMA DE PRODUCCIÓN: CALIDAD (19 ecuaciones, 1 parámetro, 4 tablas) ***************************************************************************************~ | ERRORES NOM POR KLDC =TERRORES NOM POR KLDC(PORCENTAJE TAREAS ACABADAS) ~ errores/kldc ~ Número nominal de errores por kldc. | TERRORES NOM POR KLDC ([(0,0)-(10,10)],(0.0257732,6.34868) , (4.04639, 5.65789), (6.93299,4.375) , (8.1701, 3.84868),(9.97423,3.45395)) ~ dmnl ~ Valores de la tabla “ERRORES NOM POR KLDC”. | ERRORES POR PRESION = TERRORES POR PRESION(PRESION) ~ dmnl ~ Efecto de la presión sobre la generación de errores. | TERRORES POR PRESION ([(-1,0.8)-(1,2)],(-0.4,0.9),(-0.2,0.94), (0,1),(0.2,1.05),(0.4,1.14),(0.6,1.24),(0.8,1.36),(1,1.5) ) ~ dmnl ~ Valores de la tabla “ERRORES POR PRESION”. | RETRASO CORRECCION = 10 ~ día ~ Retraso medio en las tareas de detección y corrección de errores. | NUMERO MEDIO ERRORES POR TAREA = MAX(ERRORES/(TAREAS ACABADAS+0.0001),0) ~ errores/tarea ~ Número medio de errores por tarea. | RETRASO EN CORRECCION TAREAS = DELAY3(FLUJO REALIZACION TAREAS,RETRASO CORRECCION) ~ tareas/día ~ Retraso producido en las actividades de corrección. | FLUJO GENERACION = FLUJO REALIZACION TAREAS*ERRORES POR TAREAS ~ errores/día ~ Flujo de generación de errores. | FLUJO CORRECCION = MIN(ERRORES/TIME STEP,ESFUERZO D CORRECCION/ESF CORRECCION POR ERROR) ~ errores/día ~ Flujo de corrección de errores. | FLUJO DE ESCAPE = RETRASO EN CORRECCION TAREAS*NUMERO MEDIO ERRORES POR TAREA ~ errores/día ~ Flujo de errores que no son detectados. | ESF EST POR ERROR = INTEG((ESF CORRECCION POR ERROR-ESF EST POR ERROR)/10,0.5) ~ técnicos-día/error ~ Esfuerzo estimado para corregir un error. | ESF NOMINAL CORRECCION = TESF NOMINAL CORRECCION(PORCENTAJE TAREAS ACABADAS) ~ técnicos-día/error ~ Esfuerzo nominal para corregir un error. | TESF NOMINAL CORRECCION(0,0.2,0.4,0.6,0.8,1,0.6,0.575,0.5,0.4,0.325,0.3) ~ técnicos-día/error ~ Valores de la tabla “ESF NOMINAL CORRECCION”. | ESF CORRECCION POR ERROR = ESF NOMINAL CORRECCION/EFICIENCIA ~ técnicos-día/error ~ Esfuerzo necesario para corregir un error. MODELO DINÁMICO REDUCIDO 52 | ERRORES NOM POR TAREA = (ERRORES NOM POR KLDC*LDC POR TAREA)/1000 ~ errores/tarea ~ Número nominal de errores por tarea. | ERRORES POR TAREAS = ERRORES NOM POR TAREA*ERRORES POR PRESION ~ errores/tarea ~ Número de errores por tarea. | ERRORES = INTEG(FLUJO GENERACION-FLUJO CORRECCION-FLUJO DE ESCAPE,0) ~ errores ~ Número de errores producidos. | PORCENTAJE ESF CORRECCION = TPORCENTAJE ESF CORRECCION(TAREAS PEND/TAMAÑO ACTUAL EN TAREAS) ~ dmnl ~ Porcentaje de esfuerzo dedicado a corrección | TPORCENTAJE ESF CORRECCION ([(0,0)-(0.4,1)],(0,1),(0.04,0.5),(0.08,0.28),(0.12,0.15),(0.16,0.05),(0.2,0) ) ~ dmnl ~ Valores de la tabla “PORCENTAJE ESF CORRECCIÓN”. | ********************************************************************************************** SUBSISTEMA DE PRODUCCIÓN: DESARROLLO (28 ecuaciones, 3 parámetros, 5 tablas) *********************************************************************************************~ | RETRASO EN AJUSTE = DELAY3((DEDIC1-DEDIREAL)/AJUSTETASATRAB,RETAJUSTE) ~1/día ~ Retraso en el ajuste de la tasa de trabajo. | RETAJUSTE = 10 ~día ~ Retraso de la variable “RETRASO EN AJUSTE”.. | DEDIC1 = (1+EFECTOPRESION)*DEDIC NOMINAL ~ dmnl ~ Tasa de trabajo deseada. | AGOTA =TAGOTA(DEDIC REAL) ~ dmnl ~ Efecto de la dedicación real de los técnicos en el proyecto sobre el agotamiento. | TAGOTA(0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1,1,0.9,0.8,0.7,0.6,0.5,0.4,0.3,0.2,0.1,0) ~ dmnl ~ Valores de la tabla “AGOTA”. | AJUSTEDEDICREAL = TAJUSTEDEDICREAL(TIEMPO PARA FINALIZAR) ~ día ~ Ajuste del retraso en la tasa de trabajo. | TAJUSTEDEDICREAL (0,5,10,15,20,25,30,2,3.5,5,6.5,8,9.5,10) ~ dmnl ~ Valores de la tabla “AJUSTEDEDICREAL”. | AJUSTETASATRAB = AJUSTEDEDICREAL*(IF THEN ELSE(DEDIC1>=DEDIC REAL,1,0.75)) ~ día ~ Efecto de la tasa de trabajo deseada sobre la dedicación real. | EFECTOPRESION = IF THEN ELSE(PRESION EN ESFUERZO>=0,ESFUERZO RECUPERADO / ((TECNICOS*DEDIC)*(AGOTAMIENTO+ 0.0001)), ESFUERZO RECUPERADO/(PRESION EN ESFUERZO+0.0001)) ~ dmnl ~ Efecto de la presión sobre la tasa de trabajo deseada. | AGOTAMIENTO = TIEMPO*AGOTA ~ día ~ Máxima duración del sobretrabajo. | MAXDEFICIT = AGOTAMIENTO*(TECNICOS*DEDIC) MODELO DINÁMICO REDUCIDO 53 ~ técnicos-día ~ Máximo déficit en técnicos-dia que se puede cubrir. | DEDIC REAL = INTEG(RETRASO EN AJUSTE,DEDIC NOMINAL) ~ dmnl ~ Fracción actual de un técnico-día al proyecto. | INIREALIZACION = INITIAL(0) ~ tareas/día ~ Inicialización de “flujo realización tareas”. | TIEMPO = TTIEMPO(TIEMPO PARA FINALIZAR) ~ día ~ Máxima duración nominal del tiempo de sobretrabajo. | TTIEMPO(0,10,20,30,40,50,0,10,20,30,40,50) ~ día ~ Valores de la tabla “TIEMPO”. | FLUJO REALIZACION TAREAS = ACTIVE INITIAL(MIN((ESFUERZO D REALIZAR TAREAS*PRODUCTIVIDAD), (TAREAS PEND/TIME STEP)),INIREALIZACION) ~ tarea/día ~ Tasa de realización de tareas. | TAREAS ACABADAS = INTEG(FLUJO REALIZACION TAREAS-RETRASO EN CORRECCION TAREAS,0) ~ tareas ~ Número total de tareas acabadas. | PORCENTAJE ESTIMADO TAREAS ACABADAS = ACUMULACION TAREAS ACABADAS/TAMAÑO ACTUAL EN TAREAS ~ dmnl ~ Porcentaje estimado de tareas acabadas. | PORCENTAJE TAREAS ACABADAS = ACUMULACION TAREAS ACABADAS/TOTAL TAREAS INICIALES ~ dmnl ~ Porcentaje de tareas acabadas. | PRODUCTIVIDAD = PRODUC MAXIMA*EFICIENCIA ~ tareas/técnicos-día ~ Productividad media en la realización de tareas. | PRODUC POT = 1 ~ tareas/técnicos-día ~ Productividad potencial de los técnicos. | PRODUC MAXIMA = PRODUC POT*APRENDIZAJE ~ tareas/técnicos-día ~ Productividad máxima. | DEDIC NOMINAL = 0.6 ~ dmnl ~ Dedicación nominal de los técnicos. | APRENDIZAJE = TAPRENDIZAJE(PORCENTAJE TAREAS ACABADAS) ~ dmnl ~ Aumento de la productividad al aumentar el conocimiento que tienen los técnicos de su trabajo conforme se avanza en el proyecto. | TAPRENDIZAJE([(0,0.8)(1,2)],(0,1),(0.1,1.0125),(0.2,1.0325),(0.3,1.055),(0.4,1.09),(0.5,1.15),(0.6,1.2),(0.7,1.22),(0.8,1.245),(0.9,1.25),( 1,1.25)) ~ dmnl ~ Valores de la tabla “APRENDIZAJE”. | COMUNIC = TCOMUNIC(TECNICOS) ~ dmnl ~ Pérdidas de productividad debido a las líneas de comunicación del equipo. | TCOMUNIC(0,5,10,15,20,25,30,0,0.015,0.06,0.135,0.24,0.375,0.54) ~ dmnl MODELO DINÁMICO REDUCIDO 54 ~ Valores de la tabla “COMUNIC”. | EFICIENCIA = DEDIC REAL*(1-COMUNIC) ~ dmnl ~ Multiplicador de la productividad debido a la motivación de los técnicos y a las líneas de comunicación establecidas en el equipo de trabajo. | ********************************************************************************************** SUBSISTEMA DE CONTROL ( 32 variables, 1 parámetro, 4 tablas) *********************************************************************************************~ | RETRASO TAREAS = 10 ~ día ~ Retraso medio en la incorporación de tareas nuevas en el proyecto. | TAREAS NUEVAS DIARIAS = TTAREAS NUEVAS DIARIAS(PORCENTAJE ESTIMADO TAREAS ACABADAS) ~ 1/día ~ Porcentaje diario de tareas nuevas incorporadas al proyecto. | TTAREAS NUEVAS DIARIAS ([(0,0)-(100,100)],(0,0),(20,24.58),(40,24.58),(60,26.46),(80,28.35),(100,100) ) ~ dmnl ~ Valores de la tabla "TAREAS NUEVAS DIARIAS". | TAMAÑO ACTUAL EN ESFUERZO = INTEG((FLUJO ESFUERZO+AJUSTE ESF),ESFINI) ~ técnicos-día ~ Esfuerzo total necesario para realizar el proyecto. | TAMAÑO ACTUAL EN TAREAS = INTEG(RETRASO FLUJO TAREAS NUEVAS,TOTAL TAREAS INICIALES INFRAESTIMADAS) ~ tareas ~ Número total de tareas. | TAREAS NUEVAS = INTEG((-FLUJO TAREAS NUEVAS),(TOTAL TAREAS INICIALES-TOTAL TAREAS INICIALES INFRAESTIMADAS)) ~ tareas ~ Tareas nuevas. | TAREAS PEND = TAMAÑO ACTUAL EN TAREAS-ACUMULACION TAREAS ACABADAS ~ tareas ~ Tareas estimadas que aún quedan para acabar. | PRODUCTIVIDAD1 =IF THEN ELSE(ESFUERZO PEND TAREAS PEND=0,0.01, TAREAS PEND/ESFUERZO PEND TAREAS PEND) ~ tareas/técnicos-día ~ Productividad de desarrollo estimada en función de las tareas que aún quedan para acabar. | PRODUCTIVIDAD2 = ACUMULACION TAREAS ACABADAS/(ESFUERZO TOTAL GASTADO-ESFUERZO TOTAL CORRECCION) ~ tareas/técnicos-día ~ Productividad de desarrollo estimada en función del trabajo realizado. | PESO GASTO RECURSO = TPESO GASTO RECURSO(ESFUERZO TOTAL GASTADO/TAMAÑO ACTUAL EN ESFUERZO) ~ dmnl ~ Efecto del consumo de recursos sobre la variable “PESO”. | TPESO GASTO RECURSO([(0,0) - (1,1)], (0,1) , (0.1,1), (0.2,1), (0.3,1), (0.4,1), (0.5,1), (0.6,0.975), (0.7,0.9), (0.8,0.75), (0.9,0.5), (1,0) ) ~ dmnl ~ Valores de la tabla "PESO GASTO RECURSO". | PESO TAREAS ACABADAS = TPESO TAREAS ACABADAS(PORCENTAJE ESTIMADO TAREAS ACABADAS/100) ~ dmnl ~ Efecto del trabajo realizado sobre la variable “PESO”. | TPESO TAREAS ACABADAS([(0,0)-(1,1)],(0,1),(0.1,1),(0.2,1),(0.3,1), (0.4,1), (0.5,1), (0.6,0.975), (0.7,0.9), (0.8,0.75), (0.9,0.5), (1,0) ) ~ dmnl ~ Valores de la tabla "PESO TAREAS ACABADAS". | PRODUCTIVIDAD ESTIMADA = PRODUCTIVIDAD1*PESO+PRODUCTIVIDAD2*(1-PESO) MODELO DINÁMICO REDUCIDO 55 ~ tareas/técnicos-día ~ Productividad estimada de desarrollo. | FLUJO ESFUERZO = RETRASO FLUJO TAREAS NUEVAS/(PRODUCTIVIDAD ESTIMADA+0.0001) ~ técnicos-día/día ~ Aumento diario del esfuerzo para realizar las tareas nuevas. | PESO = PESO TAREAS ACABADAS*PESO GASTO RECURSO ~ dmnl ~ Ponderación de la productividad estimada de desarrollo. | PRESION EN ESFUERZO = ESF EST PARA ACABAR-ESF PEN PARA ACABAR ~ técnicos-día ~ estimado de esfuerzo. | RETRASO FLUJO TAREAS NUEVAS = DELAY3(FLUJO TAREAS NUEVAS,RETRASO TAREAS) ~ tareas/día ~ Retraso medio diario en la incorporación de tareas nuevas al proyecto | FLUJO TAREAS NUEVAS = TAREAS NUEVAS*TAREAS NUEVAS DIARIAS/100 ~ tareas/día ~ Incorporación diaria de tareas nuevas al proyecto. | PRESION = (ESF EST PARA ACABAR-ESF PEN PARA ACABAR)/ESF PEN PARA ACABAR ~ dmnl ~ Presión (planificación adelantada o atrasada). | ESFUERZO EST TAREAS PEND = TAREAS PEND/(PRODUCTIVIDAD ESTIMADA+0.0001) ~ técnicos-día ~ Esfuerzo estimado para realizar las tareas pendientes. | ESF EST CORRECCION = ERRORES*ESF EST POR ERROR ~ técnicos-día ~ esfuerzo estimado para corregir las tareas pendientes. | ESFUERZO PEND TAREAS PEND = MAX(0,ESF PEN PARA ACABAR-ESF EST CORRECCION) ~ técnicos-día ~ Esfuerzo que queda para realizar las tareas pendientes. | AJUSTE ESF = (ESFUERZO NOTIFICADO+ESFUERZO TOTAL GASTADO-TAMAÑO ACTUAL EN ESFUERZO)/RETRASO EN AJUSTE ESF ~ técnicos-día/día ~ Ajuste diario del trabajo a realizar en técnicos-día. | DEFICIT ESFUERZO NOTIFICADO = PRESION EN ESFUERZO-ESFUERZO RECUPERADO ~ técnicos-día ~ Deficit de esfuerzo notificado. | ESFUERZO NOTIFICADO = ESF PEN PARA ACABAR+DEFICIT ESFUERZO NOTIFICADO ~ técnicos-día ~ Esfuerzo notificado que se necesita para acabar. | ESFUERZO RECUPERADO = IF THEN ELSE(PRESION EN ESFUERZO>=0,MIN (MAXDEFICIT,PRESION EN ESFUERZO),0) ~ técnicos-día ~ Esfuerzo que debe recuperarse por parte de los técnicos. | ACUMULACION TAREAS ACABADAS = INTEG(FLUJO REALIZACION TAREAS,0) ~ tareas ~ Acumulación de las tareas que se van acabando. | ESF EST PARA ACABAR = ESFUERZO EST TAREAS PEND+ESF EST CORRECCION ~ técnicos-día ~ Esfuerzo total estimado para acabar. | ESF PEN PARA ACABAR = MAX(0.001,TAMAÑO ACTUAL EN ESFUERZO-ESFUERZO TOTAL GASTADO) ~ técnicos-día ~ Esfuerzo pendiente para acabar. MODELO DINÁMICO REDUCIDO 56 | RETRASO EN AJUSTE ESF = TRETRASO EN AJUSTE ESF(TIEMPO PARA FINALIZAR) ~ día ~ Retraso medio en “AJUSTE ESF”. | TRETRASO EN AJUSTE ESF([(0,0)-(20,4)],(0,0.5),(20,3)) ~ día ~ Valores de la tabla "RETRASO EN AJUSTE ESF". | MODELO DINÁMICO REDUCIDO 57 A.3. PARÁMETROS Y TABLAS A continuación extraemos del Anexo 1 los parámetros y las tablas utilizados. Para cada parámetro y tabla se incluye una breve descripción. En el caso de las tablas se indica, entre paréntesis, la variable de la cual depende. ****************************************************************************************** SUBSISTEMA DE RECURSOS HUMANOS (7 parámetros, 0 tablas) ****************************************************************************************** * ASIMDY: Retraso medio en la adaptación de los técnicos sin experiencia en el proyecto. * AVEMT: Tiempo medio de rotación de los técnicos expertos en la empresa. * ADMPPS: Dedicación media diaria de los técnicos en el proyecto. * HIREDY: Retraso medio en la contratación de los técnicos nuevos. * MNHPXS: Número máximo de técnicos nuevos que se pueden contratar por cada técnico con experiencia a tiempo completo. * TRNSDY: Retraso medio en el tiempo de salida de los técnicos del proyecto. * TRPNHR: Dedicación media diaria de los técnicos con experiencia a formación. ****************************************************************************************** SUBSISTEMA DE PRODUCCIÓN: ASIGNACIÓN, CALIDAD, DESARROLLO Y PRUEBA (14 parámetros, 19 tablas) ****************************************************************************************** ASIGNACIÓN (2 parámetros, 2 tablas) * DESRWD: Retraso medio deseado en la revisión de errores. * TARMPE: Tiempo de ajuste del esfuerzo necesario observado por error para revisión. * PFMPQA (PJBAWK): Porcentaje de esfuerzo planificado para las actividades de calidad. * ADJQA (SCHPR): Ajuste de la variable “pfmpqa”. ASEGURAMIENTO DE LA CALIDAD (2 parámetro, 6 tablas): * AQADLY: Retraso medio en las actividades de calidad. * QO: Objetivo de calidad. * NERPK (PJBAWK): Errores nominales por cada mil líneas de código fuente (Kldc). * MERGWM (FRWFEX) : Efecto de la mezcla de técnicos sobre la generación de errores. * MERGSP (SCHPR): Efecto de la presión en la producción de errores. * NQAMPE (PJBAWK): Esfuerzo nominal necesario para detectar un error.