Project

General

Profile

CosmoSys » History » Version 9

Txinto Vaz, 09/21/2026 04:35 PM

1 9 Txinto Vaz
{{>toc}}
2 1 Redmine Admin
# cosmoSys
3
4
**cosmoSys es un entorno libre, abierto y gratuito para organizar proyectos de ingeniería como modelos vivos, comprensibles y documentables.**
5
6
Se construye sobre [Redmine](https://www.redmine.org/) y conserva sus proyectos, usuarios, roles, workflows, wikis, documentos y mecanismos de colaboración. Sobre esa base añade identidades de ingeniería, árboles navegables, diagramas, matrices de dependencias, referencias documentales, informes profesionales y herramientas para intercambiar o reutilizar proyectos.
7
8 4 Redmine Admin
{{thumbnail(cosmosys-overview.png, size=600, title=Del proyecto al modelo vivo y la documentación)}}
9
10 1 Redmine Admin
## Un proyecto que también puede leerse
11
12
Las listas planas funcionan mientras el proyecto es pequeño. Cuando crece, empiezan a mezclarse actividades, decisiones, documentos y elementos técnicos sin dejar claro qué contiene a qué ni dónde debería buscarse cada cosa.
13
14
cosmoSys organiza los ítems como un árbol. Esa estructura sirve al mismo tiempo para navegar por el proyecto y para leerlo como un libro compuesto por capítulos y subcapítulos. El usuario puede reorganizar su jerarquía, mientras el sistema respeta las reglas de qué clases de ítems pueden contener a otras.
15
16
La jerarquía no se confunde con las relaciones. Que un ítem aparezca dentro de un capítulo indica dónde se presenta; que bloquee, preceda o esté relacionado con otro expresa una conexión distinta. Separar ambas dimensiones permite reorganizar el documento sin inventar dependencias y modificar las relaciones sin desordenar su estructura editorial.
17
18 4 Redmine Admin
{{thumbnail(cosmosys-hierarchy-relations.png, size=600, title=Jerarquía y relaciones como dimensiones independientes)}}
19
20 1 Redmine Admin
## Desde una tarea hasta un programa completo
21
22
[Redmine](https://www.redmine.org/) y cosmoSys organizan su universo como un bosque de proyectos. Un proyecto grande puede dividirse progresivamente en subproyectos más sencillos, cada uno con sus propios miembros, roles, permisos y contenido.  Y una única instancia de cosmoSys puede contener innumerables árboles de proyectos, por eso lo defimos como 'bosque'.
23
24
Esta organización encaja especialmente bien con una organización cuyos proyectos siguen una WBS (*Work Breakdown Structure*): un programa se divide en paquetes de trabajo o ámbitos de responsabilidad, mientras cada unidad organizativa obtiene visibilidad únicamente en los paquetes de trabajo en los que participa.
25
26 8 Redmine Admin
{{thumbnail(cosmosys-project-forest.png, size=600, title=Bosque de proyectos y visibilidad por ámbito)}}
27
28 1 Redmine Admin
## Identidades que se pueden recordar
29
30
Los números globales de una base de datos son útiles para la máquina, pero no siempre para una conversación de ingeniería. cosmoSys asigna a cada ítem un **CSID estable y legible**, como `M2-0027`, compuesto a partir del código del proyecto que lo creó.
31
32
El CSID permite citar un elemento en textos, búsquedas, informes o conversaciones sin ambigüedades. Un ítem puede cambiar de capítulo o moverse dentro del mismo árbol de proyectos sin perder su identidad.
33
34
Además del CSID, los capítulos tienen una numeración calculada a partir de la estructura vigente. Identidad y presentación permanecen separadas: reorganizar el libro puede cambiar un capítulo, pero no convierte el ítem en otro distinto.
35
36 4 Redmine Admin
{{thumbnail(cosmosys-identity-and-chapter.png, size=600, title=Identidad estable y capítulo calculado)}}
37
38 1 Redmine Admin
## Diagramas vivos
39
40
Los diagramas de cosmoSys nacen del contenido actual del proyecto. No son ilustraciones mantenidas a mano, ni fotografías que empiezan a envejecer en cuanto se exportan.
41
42
- Los **diagramas jerárquicos** muestran cajas dentro de cajas para explicar la estructura.
43
- Los **diagramas de dependencias** recorren relaciones y cadenas causales.
44
- Los **diagramas combinados** superponen jerarquía y dependencias para aumentar el contexto.
45
46
El usuario decide qué relaciones quiere mostrar y hasta dónde desea recorrerlas.  Los diagramas pueden detenerse en la frontera del proyecto o seguir las relaciones hacia otros proyectos.
47
48
Los diagramas son navegables en la web y pueden incorporarse después a los informes.
49
50
## Una DSM para entender las dependencias
51
52
Un Gantt representa una planificación concreta. Una matriz DSM (*Design Structure Matrix*) ayuda a comprender qué secuencias de tareas son compatibles con las dependencias reales.
53
54
La DSM coloca los ítems en filas y columnas y marca las relaciones en sus cruces. Al reordenarlos, las dependencias hacia atrás aparecen por encima de la diagonal y hacen visibles secuencias imposibles, realimentaciones y ciclos potencialmente costosos.
55
56
Esto permite distinguir una precedencia técnica —una tarea no puede comenzar antes que otra— de una decisión circunstancial de planificación —dos tareas podrían intercambiarse, pero compartían recursos—. Cuando aparece un imprevisto, el DSM ayudará en la replanificación del proyecto garantizando que la nueva secuencia siga siendo válida.
57
58 4 Redmine Admin
{{thumbnail(cosmosys-dsm-reordering.png, size=600, title=Reordenar una DSM para comprender las dependencias)}}
59
60 1 Redmine Admin
## Perfiles que adaptan la herramienta al dominio
61
62
No todos los ítems representan lo mismo. Una tarea, un capítulo estructural, un dato del proyecto o un requisito necesitan campos, reglas y formas de presentación diferentes.
63
64
Los **item profiles** describen esas capacidades sin acoplar el código a nombres concretos de trackers. Determinan, entre otras cosas, si un ítem puede contener hijos, aparecer en diagramas, aportar metadatos al informe o utilizar determinadas validaciones. Los trackers son configuraciones reemplazables que consumen esos perfiles.
65
66
Los **project profiles** preparan un proyecto para una finalidad: seleccionan módulos, tipos de ítems, columnas habituales, plantillas y otras opciones coherentes. Esto permite que proyectos de tareas y proyectos de requisitos convivan en una misma instancia sin obligarlos a mostrar los mismos campos ni a trabajar de la misma forma.
67
68
De esta manera, otros plugins dependientes de éste, como por ejemplo [[csys-req:cosmoSys-Req]], pueden crear sus propios item-profiles en los que centrar su código de una manera robusta, sin depender de que el usuario borre o cambie el nombre de cualquiera de sus elementos clave.
69
70
[Redmine](https://www.redmine.org/) sigue aportando sus propios mecanismos configurables: roles, permisos, workflows, campos personalizados y módulos. cosmoSys añade contratos de dominio sin anular esa flexibilidad.
71
72 8 Redmine Admin
{{thumbnail(cosmosys-profiles.png, size=600, title=Perfiles de dominio y trackers reemplazables)}}
73
74 1 Redmine Admin
## Datos compartidos dentro del árbol
75
76
`csDatum` permite definir datos reutilizables mediante una clave estable, un nombre legible y un valor textual con sus unidades o interpretación.
77
78
Un texto puede utilizar expresiones como:
79
80
```text
81
The mirror system shall reach ${AverageThroughput.value} average throughput.
82
```
83
84
Al presentarlo, cosmoSys sustituye la expresión por el valor vigente. `${AverageThroughput}` muestra el nombre legible y `${AverageThroughput.value}` muestra su valor. Si la clave no existe, la expresión permanece visible en lugar de ocultar silenciosamente el problema.
85
86
El sistema evita así mantener el mismo valor escrito a mano en muchos lugares.
87
88 8 Redmine Admin
{{thumbnail(cosmosys-project-data.png, size=600, title=Un dato del proyecto reutilizado en una tarea de compra)}}
89
90 1 Redmine Admin
## Referencias documentales
91
92
Adjuntar un fichero no explica por qué se utiliza. cosmoSys permite catalogar documentos como referencias, documentos aplicables o documentos de cumplimiento, y mostrarlos mediante etiquetas como `RD.1`, `AD.2` o `CD.1`.
93
94
Cada ítem puede citar un documento indicando su **sentido** —por qué resulta relevante— y su **localización** —capítulo, página, tabla, cláusula o anexo—. Un mismo documento puede aparecer en muchas partes del proyecto sin perder el contexto específico de cada cita.
95
96
Las referencias almacenan una identidad interna estable. Las etiquetas visibles se calculan a partir del orden actual del catálogo: si éste se reorganiza, los textos muestran automáticamente la nueva numeración sin tener que buscar y reemplazar referencias por todo el proyecto.
97
98
Los documentos conservan además título, código externo, fecha, versión y ficheros adjuntos. El catálogo, las citas en el texto, las tablas del informe y los enlaces de navegación se construyen sobre la misma información.
99
100 4 Redmine Admin
{{thumbnail(cosmosys-document-reference.png, size=600, title=Del catálogo documental a la cita en el informe)}}
101
102 1 Redmine Admin
## Informes que parecen documentos de ingeniería
103
104
El informe presenta el proyecto como un documento jerárquico: capítulos, textos, metadatos, referencias y diagramas forman una vista HTML que puede revisarse antes de exportar.
105
106
Las plantillas de LibreOffice controlan el aspecto final, incluidos estilos, portada, cabeceras, pies, logos y propiedades del documento. El mismo contenido puede convertirse en ODT, DOCX o PDF sin reducir el proyecto a una tabla con decenas de columnas.
107
108
Los item profiles determinan qué metadatos se muestran y cómo se integran en el cuerpo. Algunos ítems actúan como marcadores de capítulos generados automáticamente, por ejemplo para insertar el catálogo documental, los datos del proyecto o los elementos retirados en el punto del árbol que el usuario elija.
109
110
Cada ítem puede decidir qué diagrama lo acompaña. Cuando una figura tendría que reducirse demasiado, cosmoSys puede trasladarla a una página con la orientación opuesta, siempre que la plantilla proporcione esa alternativa y el cambio mejore su legibilidad.
111
112
La documentación procede así del mismo modelo que consulta el equipo. Sigue siendo responsabilidad del usuario revisar cada entrega, pero deja de existir una segunda especificación que envejece separada del proyecto vivo.
113
114
## Intercambio ODS con revisión previa
115
116
cosmoSys exporta ítems y metadatos a hojas ODS abiertas y editables, con posibilidad de incluir proyectos descendientes. Esto facilita revisiones, trabajo temporal sin conexión e intercambio con colaboradores que no operan directamente sobre la instancia.
117
118
La importación no aplica los cambios a ciegas. Primero crea una transferencia, compara el contenido con el proyecto, distingue altas, modificaciones e ítems intactos, señala incidencias y exige confirmación.
119
120
El libro conserva identidades de fila y un manifiesto de linaje. De este modo se pueden detectar cambios concurrentes respecto a la exportación de origen, evitar duplicados y devolver un ODS reconciliado con las identidades definitivas después de la carga.
121
122
ODS es un canal de intercambio revisado, no una segunda base de datos destinada a competir indefinidamente con el proyecto.
123
124
## Snapshots, copias y plantillas
125
126
Un snapshot captura de forma inmutable el estado material visible de uno o varios proyectos seleccionados dentro del mismo árbol. Al descargarlo, cosmoSys genera un paquete `.csys`: un ZIP con un manifiesto JSON y los ficheros binarios organizados por contenido para no duplicarlos dentro del paquete.
127
128
El snapshot no pretende ser un volcado forense completo de [Redmine](https://www.redmine.org/). Preserva el contenido necesario para reconstruir el proyecto soportado por su contrato, mientras el historial de actividad queda fuera y algunas clases de configuración continúan incorporándose por fases.
129
130
Al materializar un snapshot o copiar directamente un proyecto se puede escoger entre una copia fiel y una copia limpia. La fiel conserva el estado material y puede mantener los CSID cuando el destino no presenta colisiones. La limpia reinicia el estado de trabajo y genera normalmente identidades nuevas, por lo que resulta adecuada para reutilizar un patrón como plantilla.
131
132
La selección puede abarcar un proyecto o varios proyectos del mismo árbol. Antes de escribir, un preflight muestra el destino, las identidades, los componentes disponibles y los posibles conflictos para que el usuario confirme una operación coherente.
133
134 4 Redmine Admin
{{thumbnail(cosmosys-portable-transfers.png, size=600, title=Intercambio ODS y paquetes csys)}}
135
136 1 Redmine Admin
## Colaboración sin encerrar la información
137
138
cosmoSys es una aplicación web multiusuario. Todo el equipo autorizado trabaja sobre la misma información en vez de intercambiar copias privadas del modelo. Proyectos y subproyectos distribuyen visibilidad y responsabilidad; roles, permisos y workflows determinan quién puede consultar, editar o consolidar cada contenido.
139
140
Las wikis, noticias, foros, repositorios y demás módulos de [Redmine](https://www.redmine.org/) pueden convivir con los ítems de ingeniería. La API permite integrar procesos externos y evita que el navegador sea la única puerta de acceso a los datos.
141
142
La información puede exportarse mediante formatos abiertos y el código puede auditarse, modificarse y desplegarse sin depender de la continuidad comercial de un proveedor. No hay licencias por puesto que obliguen a dejar fuera del proceso a parte del equipo.
143 8 Redmine Admin
144
{{thumbnail(cosmosys-shared-collaboration.png, size=600, title=Colaboración y visibilidad sobre un modelo común)}}
145 1 Redmine Admin
146
## cosmoSys-Req: requisitos sobre la misma base
147
148 5 Txinto Vaz
[[csys-req:cosmoSys-Req]] añade ingeniería de requisitos sin crear una plataforma aislada. Los requisitos utilizan los mismos árboles, relaciones, documentos, diagramas, informes, transferencias y mecanismos de colaboración que el resto del proyecto.
149 1 Redmine Admin
150
Sobre esa base incorpora atributos, perfiles, workflows y comprobaciones propias: derivación, métodos de verificación, cumplimiento, madurez y evidencia del texto realmente aprobado. Un proyecto de requisitos puede relacionarse con proyectos de tareas o con requisitos de otros niveles sin perder la frontera entre sus respectivos ámbitos.
151
152
No hace falta leer primero una página para comprender la otra: cosmoSys-Req explica nuevamente las capacidades que necesita. La repetición es deliberada porque cada producto debe poder evaluarse desde su propia puerta de entrada.
153
154
## Lo que cosmoSys no decide por ti
155
156
cosmoSys estructura información, conserva identidades y hace visibles relaciones e incoherencias. No determina si una planificación es viable, si una relación causal es correcta ni si un documento está preparado para publicarse.
157
158
Su objetivo es más concreto: que el equipo pueda encontrar el origen de una decisión, comprender sus consecuencias, revisar qué ha cambiado y producir una representación coherente del proyecto en ese momento.
159
160
La generación actual es una refundación técnica y conceptual de un sistema utilizado desde 2019. Continúa en evolución activa y conviene evaluar cada despliegue de forma controlada, como corresponde a cualquier herramienta que participa en un proceso de ingeniería.
161
162
## Libre, abierto y gratuito
163
164 6 Txinto Vaz
cosmoSys es software FLOSS impulsado por [cosmoBots.eu](https://cosmobots.eu). Puede utilizarse, estudiarse, adaptarse y mejorarse sin cuotas por usuario y sin entregar el control del proyecto a un proveedor.
165 1 Redmine Admin
166
La apertura no es sólo una cuestión de precio. Permite conocer qué hace la herramienta, conservar los datos, automatizar procesos mediante su API y decidir cómo debe evolucionar. Si una organización necesita una variante, puede construirla sobre el mismo código en lugar de esperar a que una estrategia comercial la considere rentable.
167
168
El propósito es que equipos científicos, educativos, públicos o de ingeniería con recursos limitados puedan trabajar con algo mejor que una hoja de cálculo sin tener que elegir entre controlar su proyecto y financiar el laboratorio, prototipo o servicio que quieren construir.
169 4 Redmine Admin
170
## Código y recursos
171
172
- **Código fuente:** [cosmoBots/cosmoSys](https://github.com/cosmoBots/cosmoSys) en GitHub.
173
- **Versiones publicadas:** [releases de cosmoSys](https://github.com/cosmoBots/cosmoSys/releases).
174
- **Instalación y actualización:** [instrucciones del repositorio](https://github.com/cosmoBots/cosmoSys#installation-classic-no-docker).
175
- **Licencia:** [GNU General Public License v3.0](https://github.com/cosmoBots/cosmoSys/blob/main/LICENSE).
176
- **Documentación funcional:** [[Guía funcional de cosmoSys]].
177 1 Redmine Admin
178
## Para seguir
179
180 2 Redmine Admin
- [[csys-req:cosmoSys-Req]] — gestión de requisitos sobre cosmoSys.
181 1 Redmine Admin
- [[Guía funcional de cosmoSys]] — explicación detallada de las capacidades y su uso.
182 7 Redmine Admin
- [Cosmobots](https://cosmobots.eu/)  — la asociación sin ánimo de lucro que impulsa el proyecto.