39  
German Lenin Dugarte Peña  
Universidad Carlos III de Madrid  
gdugarte@inf.uc3m.es  
Maria Isabel Sanchez Segura  
Universidad Carlos III de Madrid  
misanche@inf.uc3m.es  
https://orcid.org/0000-0001-9760-7084  
https://orcid.org/0000-0002-2339-7851  
Fuensanta Medina Domínguez  
Universidad Carlos III de Madrid  
fmedina@inf.uc3m.es  
Antonio de Amescua Seco  
Universidad Carlos III de Madrid  
amescua@inf.uc3m.es  
https://orcid.org/0000-0002-3249-2834  
https://orcid.org/0000-0003-4355-6896  
RECIBIDO 02/12/2019 ● ACEPTADO 07/03/2020 ● PUBLICADO 30/03/2020  
RESUMEN  
Poner en marcha cualquier proyecto de software involucra el consumo de recursos críticos. El  
ingeniero de software no puede experimentar con procesos de desarrollo sin ponerlos en marcha  
en proyectos reales, debido al tiempo que ello conlleva y a los elementos implicados, de modo  
que es importante contar con herramientas para previsualizar el resultado de la ejecución del  
proceso y cómo las variables de entorno le afectan, buscando anticipar en qué condiciones se va  
a desplegar el proceso. Este artículo presenta el modelado y simulación de un proceso de  
desarrollo de software por medio del enfoque de la Dinámica de Sistemas (DS), que permite  
representar gráficamente los elementos intervinientes en el proceso e incorporar la cantidad  
relevante de parámetros involucrados. Se tomó como referencia el modelo de estimación de  
costes COCOMO, que cuenta con una fundamentación teórico-práctica que avala su fiabilidad.  
Para la construcción del modelo, la referencia de sistema real fue el proceso software de Craig  
Larman (Método de Larman). El modelo de simulación presentado permite hacer estimaciones  
iniciales del comportamiento del proceso software, y de los elementos que lo conforman, durante  
el transcurso de un tiempo de simulación configurable. Se analizan variables de estado del  
sistema, que permiten concluir sobre efectos de los parámetros en el comportamiento del sistema  
en general. El modelo deriva en una herramienta de soporte a los equipos de gestión, y a las  
empresas que hacen de la Gestión de Proyectos Tecnológicos su negocio principal.  
Palabras claves: Dinámica de Sistemas, Software Engineering Economics, Gestión del Proceso  
Software, Método de Craig Larman, Modelado y Simulación de Procesos Software.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
40  
ABSTRACT  
The implementation of any software development process involves the consumption of critical  
resources. Software engineers cannot experiment with different development processes before  
starting them in real projects, due to the time that would entail and the number of elements that  
are involved, so it is vital to have tools that allow the pre-visualization of the results of executing  
the software development process and how the environmental variables affect it, thus being able  
to anticipate under what conditions the software development process will be deployed. This  
paper presents the modelling and simulation of a software development process using System  
Dynamics (SD), which allows the graphical representation of the elements intervening in the  
software process, and the incorporation of as many relevant elements as possible. As a software  
costs estimation reference, the COCOMO estimation model was used; which beyond being reliable  
has a theoretical-practical foundation. As an ideal, and real, software process system, the Craig  
Larman Software Process model was chosen, also known as the Larman Method. The simulation  
model developed here, allows one to make some initial estimation of the software process and  
its elements’ behavior in the course of the simulation time. This is possible thanks to the  
observation and study of the system’s state variables, empowering one to discern about the effect  
of changes in the parameters on the general process. This model becomes a tool for supporting  
Software Project Management teams and enterprises whose business care on Technological  
Projects Management.  
Keywords: Systems Dynamics, Software Engineering Economics, Software Process Management,  
Craig Larman’s Method, Software Process Simulation Modelling.  
INTRODUCIÓN  
En la gestión de procesos de ingeniería de software, cada vez se hace más evidente la necesidad  
de contar con herramientas que permitan una mayor supervisión y monitorización del proceso en  
su totalidad, con la idea de prever con antelación cual puede ser el mejor proceso a aplicar a un  
proyecto concreto según sus características, o qué decisiones se deben tomar en un momento  
determinado. El tiempo de desarrollo de los proyectos y el consumo de recursos necesarios para  
el proceso de ingeniería del software se han convertido en los factores clave que son sujeto de  
observación a la luz de distintas perspectivas o estilos que rigen los procesos de ingeniería de  
software; es así que se ha comenzado a hablar de técnicas ágiles para el desarrollo de software:  
XP, Scrum, etc. En este sentido, es evidente lo que Yu [1] y Smith [2] defienden sobre el hecho  
de que la necesidad de innovación en los equipos de software no está tan enfatizada en el  
producto software en sí, sino en la gestión de proyectos software, para lo que el modelado y la  
simulación, así como la gamificación [3], no solo son útiles sino necesarios.  
El consumo de recursos en la aplicación de los procesos de ingeniería del software conlleva gastos  
que, dependiendo de cada proyecto, pueden ser de significativa importancia, por lo que  
estrategias que sirvan para reducir, prevenir o controlar el consumo excesivo de recursos, son  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
41  
muy valoradas y tienden a tener una gran receptividad en las organizaciones. Según Kellner et  
al. [4] el modelado y simulación de procesos de desarrollo de software ha ido ganando el interés  
de los investigadores y desarrolladores dado que se convierte en una herramienta para analizar  
la complejidad del negocio del proceso software como un todo y para buscar respuesta a todas  
las interrogantes que se presentan en este proceso. Además, hay al menos dos poderosas razones  
para trabajar con modelos de procesos software: conseguir mejores formas de definir y guiar el  
desarrollo, mantenimiento y evolución del proceso; y, conseguir mejores formas de mejorar los  
procesos al nivel de actividades y del proceso como un todo [5].  
El enfoque del modelado y la simulación ha estado orientado hacia procesos industriales,  
químicos, tangibles, medibles, cuyos parámetros están bajo el control absoluto de los implicados  
en el proceso. Sin embargo, en los últimos años se ha dado cierta evolución en el espectro de  
enfoques, motivada por la necesidad de acceso al control de aspectos como la gestión estratégica  
[6], la búsqueda de mejoras de los procesos, o el entrenamiento en cuanto a gestión de proyectos  
de software, desde una perspectiva cercana a los datos reales y con garantía de replicabilidad  
práctica [7].  
Un posible impacto importante, que motiva a perseguir avances en el modelado y simulación de  
procesos software, es la reducción de la brecha que hay entre el equipo de desarrollo y las  
personas interesadas o involucradas como beneficiarios del producto a desarrollar. Una  
herramienta de simulación del proceso software puede representar un lenguaje común que  
permite el acercamiento entre desarrolladores y stakeholders, capaz de habilitar un entorno de  
diálogo en torno al proceso [8]. Esto es de interés para los desarrolladores de software, que  
cuentan con representaciones técnicas, como UML (entre otras muchas [9]), para abstraer y  
representar su sistema a desarrollar, las cuales pueden resultar confusas para los stakeholders,  
que suelen dominar un lenguaje mucho menos técnico y más cercano al mundo de la empresa,  
pudiendo perder interacción y comprensión suficiente del dominio del problema, si éste es  
abordado en conjunto con el equipo de desarrollo [10], [11].  
Los avances tecnológicos surgen y se desarrollan a un ritmo bastante acelerado y en paralelo a  
la disponibilidad de equipos potentes de cómputo surgen exigencias cada vez mayores de  
rendimiento por parte de los equipos humanos de desarrollo de software, así como de contar con  
estrategias y herramientas que permitan estimar el desempeño de los equipos de producción y  
los procesos que ellos implican. Debido a esto es menester contar con sistemas simulación y  
predicción de procesos software que apoyen y respalden la toma de decisiones en torno a todo el  
proceso de desarrollo.  
Para ahondar en torno a esto, se puede partir de dos bases de conocimiento concretas que ya  
cuentan con numerosos trabajos de investigación y proyectos y desarrollos concretos, lo que se  
detallará a continuación.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
42  
Por un lado, existe un marco conceptual claramente estructurado para el modelado y simulación  
de sistemas en general (Simulation Modelling), con múltiples aplicaciones y usos en áreas como  
la industrial, ambiental, química, electromecánica, etc. [6]; y por otro lado, se cuenta con una  
base conceptual en torno a la comprensión, análisis, diseño y monitorización de procesos de  
desarrollo de software; lo que permite explorar diferentes modelos de proceso, desde los más  
clásicos como el modelo estructurado en cascada (Waterfall), hasta modelos orgánicos y menos  
rígidos como el Rational Unified Process (RUP) [12], o el que se explica más adelante en este  
trabajo, el Método de Craig Larman [13].  
A partir de las dos bases de conocimiento mencionadas anteriormente, surge un interés de  
investigación en torno al modelado y simulación de procesos software, campo hasta el momento  
poco explorado y en el que la diversidad y dinamismo de los factores intervinientes aporta un  
grado de complejidad que afecta notablemente el comportamiento de los equipos de desarrollo y  
por ende todo el comportamiento organizativo. Se presenta aquí un trabajo en el que se tomó el  
Método de Larman y se diseñó un modelo de simulación para representar el funcionamiento de  
dicho método como proceso organizativo de desarrollo de software, dando continuidad al trabajo  
de Dugarte-Peña [14][8].  
El creciente auge en torno al desarrollo de software, las exigencias cada vez más complejas sobre  
las capacidades de los productos software y el deseo, cada vez mayor, por parte de la industria  
y de la academia, de comprender y acercar los productos software a la realidad a la que sirven;  
hacen que sea una necesidad importante contar con herramientas para comprender estos  
sistemas y su complejidad. El modelado y simulación de los procesos de desarrollo de software  
representa una oportunidad importante para ambos colectivos en el sentido de que con un mínimo  
consumo de recursos permite hacer exploraciones sobre el sistema emulado como si se tratase  
del sistema real, apoyando la toma de decisiones y proyectando escenarios que en la mayoría de  
los casos son inexplorables o inaccesibles por los altos costes que suponen.  
El Método de Larman, ilustrado en la Figura 1, al ser iterativo, incremental y dirigido por casos  
de uso, ha sido escogido en este trabajo como modelo ideal del proceso a ser simulado. Para  
1
hacer el modelado y simulación de este sistema “real” , se ha decidido trabajar con el enfoque  
de la Dinámica de Sistemas por la amplia documentación existente sobre su uso y  
aprovechamiento y por el valor agregado que le otorga el carácter sistémico que inspiró su  
nacimiento y las herramientas existentes para su uso. Además, se justifica su uso por la aún  
vigente importancia de los estudios in silico en el ámbito de la ingeniería del software [15].  
La Dinámica de Sistemas proporciona todo el marco conceptual para la construcción del modelo.  
1
Se usa la palabra “real” para diferenciar del sistema simulado, siguiendo la metodología de Modelado y Simulación de Sistemas. EL  
sistema “real” hace referencia a la situación compleja de interés, que en este caso es el proceso complejo de desarrollo, teniendo en  
cuenta todos sus factores, interrelaciones y perspectivas. El sistema simulado, en cambio, será una abstracción restringida de esta  
“realidad compleja”.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
43  
Se ha decidido trabajar con VENSIM [16] por ser una herramienta con amplia documentación a  
disposición de la comunidad, con una gran colección de experiencias de uso que argumentan su  
fiabilidad y por ofrecer a la comunidad académica una versión gratuita para fines académicos,  
como es el caso de este trabajo. Además de permitir la representación del sistema real, VENSIM  
es fácilmente manipulable y modificable para experimentar con variaciones de los parámetros  
usados en el modelo, permitiendo así modificaciones del estado del sistema que se pueden  
observar, medir y repetir, resultando idóneo para modelado y la simulación de sistemas, no sólo  
en el campo de la Ingeniería del Software sino en general [17].  
Figura 1. Bosquejo conceptual del método de Larman.  
Selección de Parámetros del Proceso Software  
En este modelo de simulación del proceso software se hará uso de los parámetros del proceso  
software que el modelo COCOMO ofrece. COCOMO® II (Constructive Cost Model II), es una  
versión más completa y mejorada de la herramienta COCOMO® (Constructive Cost Model),  
consistente de la implementación de un modelo de estimación implementado por Barry Boehm a  
finales de los años setenta, en el seno de la University of Southern California [18].  
COCOMO® II permite la estimación de coste, esfuerzo y programación de tareas en el proceso  
de planificación de un nuevo desarrollo de software. Además, permite la manipulación de tres  
submodelos: el de Composición de Aplicaciones (Applications Composition), el de Diseño  
Temprano (Early Design), y el de Modelos Post-arquitectura (Post-architecture models). Con  
respecto a los aspectos de un proyecto de desarrollo de software, Cocomo II se fija en cuatro  
tipos de atributos de un proceso software para hacer la estimación. Una descripción detallada de  
estos atributos, las funciones de estimación que usa y como se interrelacionan los atributos entre  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
44  
sí, se encuentra disponible en [19]. Debido a su importancia para este trabajo, el listado de  
atributos por tipo se presenta en la Tabla 1. Se muestra también una escala numeral que aporta  
los valores referenciales de entrada a los modelos y fórmulas matemáticas de las que se hace  
uso para estimar el coste y esfuerzo de un proyecto.  
Tabla 1. Parámetros-Atributos del modelo de Estimación de costes COCOMO II.  
COCOMO II: Parámetros y atributos  
Valor  
Nombre  
Atributo  
Muy bajo  
Bajo Nominal Alto  
Muy alto  
Extra alto  
Atributos de Software  
RELY  
DATA  
CPLX  
Fiabilidad  
Tamaño de Base de Datos  
Complejidad  
0.75  
__  
0.70  
0.88 1.00  
0.94 1.00  
0.85 1.00  
1.15  
1.08  
1.15  
1.40  
1.16  
1.30  
__  
__  
1.65  
Atributos de Hardware  
TIME  
Restricciones de tiempo de  
ejecución  
__  
__  
1.00  
1.11  
1.30  
1.66  
STOR  
VIRT  
TURN  
Restricciones de memoria virtual __  
Volatilidad de la máquina virtual __  
__  
1.00  
1.06  
1.15  
1.07  
1.21  
1.30  
1.15  
1.56  
__  
__  
0.87 1.00  
0.87 1.00  
Tiempo de respuesta  
__  
Atributos de Personal  
ACAP  
AEXP  
PCAP  
VEXP  
Capacidad de análisis  
1.46  
1.29  
1.42  
1.21  
1.19 1.00  
1.13 1.00  
1.17 1.00  
1.10 1.00  
0.86  
0.91  
0.86  
0.90  
0.71  
0.82  
0.70  
__  
__  
__  
__  
__  
Experiencia en la aplicación  
Calidad de los programadores  
Experiencia en la máquina  
virtual  
LEXP  
MODP  
TOOL  
SCED  
Experiencia en el lenguaje  
1.14  
1.07 1.00  
0.95  
0.91  
0.91  
1.04  
__  
__  
__  
__  
__  
Atributos del Proyecto  
Técnicas actualizadas de  
programación  
Utilización de herramientas de  
software  
Restricciones de tiempos de  
desarrollo  
1.24  
1.24  
1.22  
1.10 1.00  
0.82  
0.83  
1.10  
1.10 1.00  
1.08 1.00  
Modelado y Simulación del Proceso Software  
Teniendo como referencia la metodología de [20] para modelado con Dinámica de Sistemas, y la  
utilidad que tiene para ser explotada en el ámbito de la ingeniería del software[21]–[23], primero  
se hizo una descripción del sistema a modelar, después una representación de las causalidades  
existentes entre los elementos del sistema, seguido por la identificación y representación de los  
elementos propios de la Dinámica de Sistemas, y finalmente la configuración del modelo para su  
posterior uso, evaluación, y análisis de funcionalidad.  
El sistema que se va a modelar está compuesto por un conjunto de elementos intervinientes en  
el proceso de desarrollo de software como lo son: personas (analistas, programadores, directores,  
etc.), equipos informáticos, requisitos, activos de proceso software (código, especificaciones,  
prototipos, documentación), y elementos propios del entorno del sistema como las restricciones  
o fronteras (tiempos, capacidades máximas, etc.). Todos estos elementos están interrelacionados  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
45  
de alguna manera en alguna o en todas las fases que comprende el proceso de desarrollo de  
software, sin embargo, el funcionamiento de este conjunto de elementos sobrepasa esa mera  
descripción, resultando realmente en un comportamiento dinámico y lleno de causalidades  
complejas y variantes en el tiempo.  
El Método de Craig Larman se compone de tres fases o macro etapas claramente diferenciadas  
una de otra, y en esencia comunes a la gran mayoría de modelos y métodos de desarrollo de  
software: Planificación y Especificación de requisitos, Construcción e Instalación.  
Diagrama causal del modelo.  
A continuación, como si se tratase de una especie de “zoom” o “acercamiento” hacia lo que  
realmente se quiere representar, se muestra primero un macro diagrama que muestra cómo se  
relacionan las tres fases del proceso de desarrollo ya explicadas: planificación y especificación de  
requisitos, construcción e instalación.  
Seguidamente se muestra un primer grado de dinamismo e interactividad que se da en el proceso  
de software consecuencia de que en la fase de construcción están implicados no uno sino varios  
ciclos de desarrollo que son necesarios para alcanzar el grado de madurez aceptable del producto  
software que se desea construir.  
Finalmente se presenta un diagrama causal detallado del subproceso de la fase de construcción,  
lo que es un precedente y requisito para construir el modelo de Dinámica de Sistemas, es decir,  
el modelo en términos de niveles y flujos dinámicos.  
Macro diagrama del Proceso General de Desarrollo de Software de Craig Larman.  
Las tres fases del proceso están interconectadas, y, como se observa en las Figuras 2 y 3, suelen  
tener una fuerte interacción durante todo el proceso de desarrollo. Aunque la fase de planificación  
y especificación de requisitos es la inicial, desde las fases de construcción y de instalación se  
hacen constantes referencias a esta fase para realizar ajustes que corresponden a actividades de  
planificación y especificación de requisitos. Lo mismo ocurre entre las fases de Construcción e  
Instalación, lo que significaría que durante la instalación pueden generarse solicitudes de “re-  
engineering” de actividades que corresponden a la fase de construcción, es decir, se hacen  
cambios en los requisitos. Sin embargo, el núcleo de todo el proceso, o la fase en que la carga  
de trabajo es significativamente mayor, es la fase de construcción, que implica fuerte consumo  
de recursos para lograr obtener el producto listo para implantación a partir de su especificación.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
46  
Macro diagrama de la fase “Construcción” de un proceso de desarrollo de software.  
La fase de Construcción de un proceso de desarrollo de software tiene por sí misma cierta  
complejidad y comportamiento dinámico que merece ser estudiado y comprendido, tanto desde  
un punto de vista sistémico y sinérgico, como comprendiendo a su vez las distintas subetapas  
que contiene. Estas subetapas son los llamados ciclos de desarrollo que se llevan a cabo  
formalmente con posterioridad a la Planificación y Especificación de Requisitos y derivan en la  
presentación de un producto software que luego estará disponible para ser llevado a la fase de  
instalación.  
Figura 2. Diagrama general de fases del Método de Larman.  
Como se puede ver en la Figura 3, los ciclos de desarrollo están relacionados entre sí. En cada  
ciclo de desarrollo se van atendiendo casos de uso de los que se definen en la planificación y  
especificación de requisitos. El orden en que estos casos de uso son atendidos responde a la  
priorización que se hace sobre ellos, y, además, un caso de uso puede ser parte de más de un  
ciclo de desarrollo si la complejidad del caso lo amerita.  
Figura 3. Primer desdoblamiento de la complejidad del proceso: Construcción.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
47  
La cantidad de ciclos de desarrollo no es exacta, sino que se determina para cada caso en  
particular según la complejidad del proyecto y de sus casos de uso. En la Figura 3, observamos  
un primer “acercamiento” o “zoom” sobre el proceso general de desarrollo, en el que se muestra  
que la fase de construcción implica a su vez varios ciclos de desarrollo y que estos no son  
independientes uno del otro sino que están relacionado y hay relaciones de causalidad entre ellos:  
Para el ejemplo de la Figura 3, el ciclo 1 produce efectos en ciclos 2 y 3, y el ciclo 2 que se ha  
visto influenciado por el ciclo 1, también tendrá relevancia sobre el ciclo 3.  
Diagrama en detalle: Fase de construcción  
A continuación, en la Figura 4, se presentará el diagrama causal del sistema real que se está  
modelando en este trabajo. En este diagrama, a forma de segundo “acercamiento” o “zoom”  
sobre el sistema real, se han incorporado todos los elementos que se considera tienen algún  
efecto en la fase de construcción del proceso software. Se ha agregado la mayor cantidad de  
elementos posibles con la finalidad de hacer la representación pictográfica más representativa.  
Siguiendo el sentido de las flechas, se puede apreciar relaciones de causalidad entre los elementos  
a los extremos de las flechas, lo que nos permite apreciar la complejidad del proceso software al  
haber no sólo una cantidad considerable de flechas sino también un número elevado de  
realimentaciones, lo que según [20] justifica el uso de la Dinámica de Sistemas para modelar  
sistemas como éste. A continuación, se presentan los elementos clasificados en términos de la  
dinámica de sistemas (Detalles se han omitido en este artículo, pero las definiciones extensas se  
alinean con [13], [24]).  
Figura 4. Diagrama causal de la fase "Construcción" del Método Larman de ingeniería del Software.  
Identificación de Acumuladores, Niveles o Stocks  
Para el proceso de Ingeniería del Software aquí presentado, los elementos que tienden a  
acumularse en el tiempo y que por ende representan “niveles del sistema” en el dominio de la  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
48  
Dinámica de Sistemas son: Especificaciones, Estructuras de Diseño, Código, Pruebas realizadas  
y un nivel cuya funcionalidad es transversal pero no crítica para todo el proceso: Glosario.  
Identificación de flujos o tasas de crecimiento y decrecimiento.  
A continuación, se presentan los elementos del sistema que representan de alguna manera flujos  
de crecimiento y decrecimiento de los niveles anteriormente especificados: Análisis, Diseño,  
Implementación, Corrección y Pruebas.  
MODELO COMPUTACIONAL  
El modelo que se presenta, debido a su tamaño, comprende tres vistas de modelo, tomando  
ventaja de la propiedad de modelado paralelo del software Vensim. Inicialmente se pretendía  
construir un modelo general que englobara las tres fases del Método de Larman, sin embargo,  
durante el proceso de modelado fue necesario delimitar el proceso software de manera que las  
fases de “Planificación y Especificación de Requisitos” e “Instalación” sólo se llevan a cabo una  
vez, e implican tareas concretas, mientras que la fase de “Construcción” tiene implícita toda una  
dinámica (e iteratividad) en sí misma. La Figura 5 muestra el submodelo de la fase de Planificación  
y Especificación de Requisitos.  
Figura 5. Submodelo de simulación para la fase "Planificación y Especificación de Requisitos".  
Seguidamente se presenta el modelo de simulación para la fase de construcción (en tres vistas,  
o niveles de abstracción que forman parte del mismo modelo). La primera vista, presenta de  
forma esquemática los parámetros del proceso que afectan el proceso software que fueron  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
49  
explicados anteriormente. Estos parámetros tienen efecto en distintas partes del modelo de  
simulación, sin embargo, se han conglomerado en esta primera vista para facilitar su  
manipulación y la fácil calibración del modelo al momento de hacer pruebas variando sus valores.  
En esta primera vista (Figura 6) también se ha incorporado la parte del modelo en la que se  
implementan las ecuaciones usadas por [19] para la estimación de esfuerzo.  
La segunda vista del modelo en VENSIM (Figura 7) es la parte central del modelo, y en ella se  
han agregado los elementos principales representativos del proceso de desarrollo de software.  
RU-D-A  
RU-I-A  
RU-T-A  
RU-I-D  
RU-T-D  
RU-T-I  
LOC  
QOP  
QUC  
DOCU  
Relative  
Complexity  
RCPX  
RELY  
DATA  
CPLX  
RUSE  
SIZE  
<Relative  
Complexity>  
A
PREC  
FLEX  
<
PDIF> <PREX>  
TPtime  
ANtime  
AggregatedTime  
<
RUSE>  
<RUSE>  
<PERS>  
<
FCIL>  
PVOL  
DEtime  
COtime  
TEtime  
<
RCPX>  
B
PMnom  
<SCED>  
RESL  
TEAM  
PMAT  
STOR  
<
RELY>  
PDIF  
PERS  
TIMEp  
<DATA>  
<CPLX>  
ACAP  
PCAP  
PCON  
<
RUSE>  
PMadjPA  
<DOCU>  
<TIMEp>  
PMadjED  
AEXP  
TDEV-PMnom  
<
STOR>  
PVOL>  
PEXP  
LTEX  
PREX  
<SCED>  
<
<
ACAP>  
TDEV-PMadjED  
N-ED  
PPP  
<
PCAP>  
TOOL  
SITE  
FCIL  
SCED>  
TDEV-PMadjPA  
<
PCON>  
TMAX  
%GLana %GLdes  
GLimp %GLtest  
N-PA  
Related Cost  
<
<AEXP>  
SCED  
%
<
SCED>  
SITE>  
<
<
<PEXP>  
LTEX>  
TOOL>  
<
Figura 6. Vista 1: Submodelo de configuración de parámetros y estimación.  
En la Figura 6 se pueden observar los elementos del modelo COCOMO II de estimación, y como  
éstos afectan la estimación tanto en el modelo “Early Design” (ED) como “Post Architecture” (PA).  
Se han respetado los acrónimos del modelo COCOMO tanto para los atributos del modelo  
(
(
Variables auxiliares en esta vista) como para las variables producto de la estimación  
Estimaciones ED y PA).  
La Figura 7 muestra la vista del modelo que implementa las los elementos del proceso de  
desarrollo de software y cómo estas se van acumulando a medida que el tiempo de proyecto  
transcurre. Las fases que se “acumulan”, es decir, que se van cumpliendo durante el proceso son:  
Analysis, Design, Code, y Test. Hay otro nivel que se acumula referente a la incorporación de  
términos al Glosario de un proyecto. Los flujos que nutren estos niveles determinan el ritmo con  
el que crecen o decrecen y son dependientes de distintos factores que afectan el proceso, que en  
este caso se tomaron del modelo COCOMO de estimación, como se ha explicado anteriormente.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
50  
<
TMAX>  
<
AEXP>  
<RELY> <CPLX>  
<DATA>  
<
ACAP>  
AEXP>  
<
Time>  
<CPLX>  
<AEXP>  
<AEXP>  
<ANtime>  
<COtime>  
<
<
RU-T-I>  
<
TDEV-PMadjPA>  
<
analisis  
behavior>  
<
TPtime>  
AggregatedTime>  
<TOOL>  
<implementation>  
<
tests>  
<PCAP>  
<PCAP>  
VEXP>  
<TOOL>  
SCED>  
<
<RU-I-D>  
<ACAP>  
AEXP>  
TOOL>  
<SCED>  
<
SCED>  
<
<DEtime>  
<
<
<
VEXP>  
<
<
LEXP>  
analisis rate  
<implementation  
behavior>  
<
RU-T-D>  
<
RU-D-A>  
design>  
<LEXP>  
<
tests>  
<ANtime>  
<MODP>  
<TOOL>  
<
<
ANtime>  
implementation  
rate  
<
design behavior>  
analisis  
design  
implementation  
<
<
RU-I-A>  
tests  
GLContribution  
DEtime>  
<
implementation>  
<SCED>  
<
PM Analisis>  
<PM  
Implementation>  
design rate  
test rate  
<
PM Design>  
<PM TEsts>  
<
test behavior>  
<Time>  
<TPtime> aggregation  
AggregatedTime>  
<%GLtest>  
<tests>  
<
RU-T-A>  
tests>  
<
Analisis  
aggregation  
Design  
aggregation  
Tests  
aggregation  
Glossary  
<%GLimp>  
Code  
<
%GLdes> <implementation>  
<design>  
%GLana>  
<
<
PM Analisis>  
<
<
TDEV-PMadjPA>  
AggregatedTime>  
TPtime>  
<TDEV-PMadjPA>  
<SCED>  
<
analisis>  
<
<
Time>  
<TIMEp>  
STOR>  
<
<
<
TOOL>  
<
VIRT>  
<MODP>  
<
TURN>  
Figura 7. Vista 2: Submodelo de la fase de "Construcción" en un proceso de desarrollo.  
La tercera vista (Figura 8) se ha agregado para representar el consumo paulatino del esfuerzo  
correspondiente a cada una de las etapas de la fase de construcción de software. Se puede  
observar que el esfuerzo distribuido está acumulado en los niveles PM Analysis, PM Design, PM  
Implementation, y PM Tests. Los flujos que salen de cada nivel definen el ritmo en que este  
esfuerzo es consumido, y como se puede observar, son afectados por distintas variables del  
proceso.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
51  
<
PMnom>  
<
ANtime>  
<
DEtime>  
%PMAna  
<
PMana>  
<COtime>  
ANtime>  
<
PMdes>  
<PMimp>  
<PMtest>  
PM TEsts  
<
PMadjED>  
%PMDes  
<
%PMImp  
PM Implem  
entation  
PM Analisis  
PM Design  
PMana  
PMdes  
%PMTest  
<
PMadjPA>  
PMimp  
PMtest  
TDEV-PMadjPA>  
implementation  
effort use  
Analisis effort use Design effort use  
Test effort use  
<
normal implementation  
effort rate  
normal test effort  
rate  
normal design  
ANPeopleCost  
DEPeopleCost  
normal analisis  
effort use rate  
effort rate  
COPeopleCost  
implementation  
behavior  
TEPeopleCost  
design behavior  
<Time>  
test behavior  
analisis behavior  
<
TPtime>  
%TimeAna  
%
TimeDe  
<
TPtime>  
<
ANtime>  
%TimeCons  
COtime>  
%
TimeTest  
<AggregatedTime>  
<TDEV-PMadjPA>  
<
DEtime>  
<
<
TEtime>  
Figura 8. Vista 3: Submodelo de distribución del esfuerzo en el proceso de desarrollo de software  
EJECUCIÓN Y DISCUSIÓN DE LA SIMULACIÓN DEL MODELO COMPUTACIONAL  
Se ejecutó el modelo con los parámetros de COCOMO en sus valores “nominales”, obteniéndose  
lo que se esperaría sea el comportamiento normal del sistema simulado. Se puede observar una  
gran cantidad de factores y su variación en el tiempo; sin embargo, se enfocará la atención en  
mostrar aquellos aspectos del proceso que son de interés en la gestión de proyectos software: el  
comportamiento del sistema como un todo, el consumo de los recursos en el transcurso  
del tiempo, y los comportamientos de los acumuladores por tratarse de “variables de  
estado” que permiten crear panoramas generales del funcionamiento del sistema.  
En la Figura 8, se observa el comportamiento general del sistema con la figuración de parámetros  
nominales. Se puede observar como la realización de las actividades del proceso de construcción  
(representadas en el eje y como unidades atómicas de tareas por cada fase), aunque con ciertas  
simultaneidades, se concentra en su mayoría en distintas etapas (temporales) del proceso  
general. El análisis y el diseño tienden a concentrarse en la primera mitad del ciclo de vida del  
proceso, mientras que la implementación (y su correspondiente construcción de código fuente)  
se concentra en la mitad del proceso y las pruebas hacia la segunda mitad del ciclo de vida del  
proceso. Este comportamiento presenta cierta similitud con el proceso de software descrito en el  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
52  
Rational Unified Process, lo que da una primera idea de la aproximación de este modelo de  
simulación a los modelos teóricos existentes en la literatura.  
Nominal: El proceso como un todo  
2
4
000  
000  
9
0,000  
30  
1
2
000  
000  
4
5,000  
15  
0
0
0
0
0
3
6
9
12  
15  
18  
21  
24  
27  
30  
33  
36  
39  
42  
45  
48  
51  
54  
57  
60  
Time (Month)  
análisis : Current  
diseño : Current  
implementación : Current  
pruebas : Current  
Figura 8. Las fases de la "construcción" del proceso software: modelo nominal.  
Si se piensa en las actividades del proceso de construcción como metas que deben ser alcanzadas  
en el transcurso del tiempo, la Figura 9, es una ilustración del comportamiento de la maduración  
del alcance de estas metas. Se puede ver que los primeros conjuntos de actividades en  
completarse son los correspondientes a “Análisis” y “Diseño”, seguido por el correspondiente a la  
construcción del código, y finalmente las actividades de pruebas, que al principio del proceso eran  
muy pocas, pero que dominan el proceso hacia el final, cuando el producto se prepara para ser  
entregado.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
53  
Cumplimiento de actividades de Análisis, Diseño, Implementación y Pruebas.  
3
2
0,000  
0,000  
700,000  
600  
1
1
5,000  
0,000  
350,000  
300  
0
0
0
0
0
3
6
9
12  
15  
18  
21  
24  
27  
30  
33  
36  
39  
42  
45  
48  
51  
54  
57  
60  
Time (Month)  
Especificaciones : Current  
Madurez del Diseño : Current  
Código : Current  
Pruebas Realizadas : Current  
Figura 9. Maduración de las fases del proceso de construcción: modelo nominal.  
Una forma también interesante de verificar el funcionamiento del proceso es observando el  
comportamiento del “esfuerzo”, dado que este se distribuye durante todo el proceso en los  
distintos tipos de actividades que se llevan a cabo. En la Figura 10, (sin escalar) se ve que el  
esfuerzo consumido en el proyecto se distribuye entre análisis, diseño, codificación y pruebas  
respectivamente. En dicha imagen se observa en qué momentos de todo el proceso hay mayores  
flujos de esfuerzo en el proyecto, sin embargo, nótese que como es de esperar, las escalas no se  
corresponden; ya que, en cuanto a cantidades, el esfuerzo dedicado a algunas actividades de  
diseño, es mucho mayor que el dedicado a las pruebas, por ejemplo.  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
54  
El esfuerzo consumido durante el proyecto  
50  
30  
30  
3
25  
15  
15  
1
.5  
0
0
0
0
0
3
6
9
12  
15  
18  
21  
24  
27  
30  
33  
36  
39  
42  
45  
48  
51  
54  
57  
60  
Time (Month)  
Analisis effort use : Current  
Design effort use : Current  
implementation effort use : Current  
Test effort use : Current  
Figura 10. Esfuerzo consumido en el proceso de construcción, separado por fases: modelo nominal.  
Adicionalmente, el modelo ha permitido a los autores crear escenarios con los que estudiar el  
comportamiento del sistema y cómo este se ve afectado al variar los elementos de estimación  
que afectan el proceso. Los resultados parciales se presentan en [8] y se refinan para un futuro  
trabajo enfocado en el efecto que tienen los parámetros de estimación del producto software en  
el desempeño del proceso.  
CONCLUSIONES  
En este trabajo se decidió trabajar con la Dinámica de Sistemas como enfoque para la  
construcción del modelo de proceso software, basados en el hecho de que el proceso software,  
lejos de ser metódico y procedimental resulta ser complejo, variante y en muchas ocasiones  
contraintuitivo y con muchos fenómenos emergentes e impredecibles.  
Para la construcción del modelo, y atendiendo a la metodología tomada como referencia [20]; se  
hizo primero una profunda inmersión en el sistema a modelar, lo que se tradujo en una  
comprensión profunda y sistémica del proceso de ingeniería de software del Método de Larman,  
su funcionamiento, fases, características, y propiedades, constituyendo lo que es un primer nivel  
de abstracción del proceso. Parte de esta inmersión fue la exploración de enfoques que  
describieran los parámetros que afectan el proceso, para lo que resultó de gran utilidad y  
aprovechamiento hacer uso del modelo de costes COCOMO II, que tiene definidos una serie de  
parámetros comunes al proceso que tienen incidencia en el desarrollo y en el consumo de recursos  
relacionado. En el modelo que aquí se presentó se hizo uso de estos parámetros como una forma  
de incrementar la representatividad del modelo, lo que permitió incorporar los efectos de los  
REVISTA INNOVACIÓN Y SOFTWARE  
VOL 1 Nº 1 Marzo - Agosto 2020 ISSN Nº 2708-0935  
55  
parámetros del proceso, sobre el funcionamiento del proceso como un todo, y de esta manera  
estimar posibles efectos y comportamientos esperados a partir de ciertas configuraciones de  
parámetros; representando esta propiedad un aporte significativo para quienes quieren estudiar  
el proceso software con mínimos costes y por medio de una manera práctica, manejable, utilizable  
por múltiples usuarios y con un importante potencial para dar soporte a la toma de decisiones en  
los equipos de gestión de procesos software.  
Lo anterior fue el fundamento para la construcción de los diagramas causales representativos,  
inicialmente de todo el proceso, y después, a manera de un zoom dentro del sistema general, de  
la fase de construcción del proceso de ingeniería de software. El aporte principal en este aspecto  
vino al momento de modelizar dicho sistema (el subproceso de construcción) haciendo uso del  
enfoque de la Dinámica de Sistemas. En esta modelización, la identificación de variables, niveles  
y flujos que interactúan en el sistema, representan un segundo nivel de abstracción del sistema,  
de suma importancia y utilidad, ya que aquí se identifican relaciones entre los elementos del