We continue to develop resources related to the COVID-19 pandemic. See COVID-19 initiatives on Appropedia for more information.


From Appropedia
Jump to navigation Jump to search

Click the "Add topic" above to add a new section, or just click edit.

Engr305 Appropriate Technology page in progress
This page is a project in progress by students in Engr305 Appropriate Technology. Please do not make edits unless you are a member of the team working on this page, but feel free to make comments on the discussion page. Check back for the finished version on May 15, 2017.



Short abstract describing the project from background to conclusion


Describe the background of the project. Make sure to cover who, what, why, when and where…

sfdhgian carkl

Literature Review

Introduce the literature review briefly and then use heading and subheadings for topics. This should focus on information… NO PLAGIARISM! Make sure to see assignments on Moodle.[1]

Grading criteria for Literature Review:

  • Formatting (should look good, see Appropedia suggested formatting) +20
  • Thoroughness of research (at least 3 books and 1 peer reviewed journal per person... lots of credible web refs) +40
  • Uses reference format +30
  • Extra (amazing sources) +10

This is a review of the available literature pertinent to the CCAT greenhouse dehumidifier project. Preliminary research for the dehumidifier project consists of peer-reviewed material science and environmental engineering journals, other home dehumidification system examples, and various books on humidity in cold regions.

Cost Table

Quantity Material Source Cost ($) Total ($)
1 3" diameter aluminum ducting elbow (rotating) Ace Hardware 4.99 4.99
1 3" diameter aluminum ducting round pipe (24" long) Ace Hardware 4.99 4.99
1 Premium Foil Duct Tape Ace Hardware 18.99 18.99
1 Flexible aluminum duct 3" diameter, 5' length with lint trap box Ace Hardware 16.99 16.99
1 Multi-purpose vent Ace Hardware 9.99 9.99
1 4" Dryer vent hood Ace Hardware 10.99 10.99
Total Cost $66.61

Introduction to dehumidification

A dehumidifier is a device that removes humidity from its surroundings. In this case this will be the CCAT greenhouse. Excess humidity in a greenhouse can be detrimental to plant health, which necessitates the introduction of an appliance designed to dehumidify. The dehumidification process involves drawing moisture from the air by use of a fan and tub system or by a form of naturally absorptive materials. Examples of such materials include calcium chloride, silica gel, and activated carbon.[2] Humidity can be quantified by a humidity sensor.

Dehumidification via fan

Mechanical dehumidifiers operate by a fan pulling the air from the room first through an evaporator and then a condenser.[3] Dry air is then blown by the fan back into the room, leaving the condensed water in a reservoir bucket. This method of dehumidification is far more common and is used in both home and commercial settings. Mechanical dehumidifiers are typically preferred in cold climates because relative humidity is higher in these areas,[4] so often a fan and filer are required to draw water from the air as opposed to a natural method. One benefit of this way to dehumidify is that the water collected in the bucket below the evaporator is can be reused to water the plants in the greenhouse. The clear downside to this method is energy consumption, so more research is required to find a solution to this. One possible alternative could be solar power.

Dehumidification via porous material

This method of dehumidification utilizes a material known as a desiccant, which acts as a drying agent by absorbing moisture from the air. Such materials include calcium chloride, silica, rock salt, and activated carbon.[5] All four of the substances will be evaluated, then compared with the mechanical dehumidifier to determine the most effective method for the greenhouse to use. one definite benefit to dehumidification through this method is that no energy is required to draw water from the air due to the desiccant properties of these materials.[6] One potential downside is the health hazards associated with calcium chloride such as lung damage and other respiratory problems.[7]


Show examples of the prototyping process including what you learned.


Very complete description of how final project is made. This large section should have lots of pictures. Use the Help:Images#Galleries and probably Template:How_to (e.g. Barrel O' Fun Worm Bin Instructions).


Introduce the timeline and include a table of the timeline.

Grading criteria for timeline:

  • Spelling and grammar +15
  • Completeness of timeline +35
  • Table formatting +15
  • Timeline introduced +15
  • Separate columns for propose and actual completion date.


Finish gathering all required materials 3/10/17
Initial assembly and testing at CCAT greenhouse 3/14/17
Efficiency assessment (fan, tubes, etc.) 3/16/17
Observably lower and maintain greenhouse humidity for a prolonged period of time 3/22/17
Teach CCAT members how to operate and maintain the completed dehumidifier system 4/10/17
CCAT Greenhouse Dehumidifier project completed and installed, presentation given to class, and Appropedia page submitted to Lonny 5/5/17 or earlier (must review dates)

Cost Table

Quantity Material Source Cost ($) Total ($)
1 3" diameter aluminum ducting elbow (rotating) Ace Hardware 4.99 4.99
1 3" diameter aluminum ducting round pipe (24" long) Ace Hardware 4.99 4.99
1 Premium Foil Duct Tape Ace Hardware 18.99 18.99
1 Flexible aluminum duct 3" diameter, 5' length with lint trap box Ace Hardware 16.99 16.99
1 Multi-purpose vent Ace Hardware 9.99 9.99
1 4" Dryer vent hood Ace Hardware 10.99 10.99
Total Cost $66.61


Description of costs, donations, the fact that this is just proposed, etc. See Help:Table_examples#Cost_Table for a very nice looking table format.

Grading criteria for costs:

  • Formatting (should look good, see Help:Table_examples#Cost_Table formatting) +20
  • Thoroughness and up-to-dateness of budget (should display necessary components, including donations, have an introduction, etc) +40
  • Mathematical accuracy +30
  • Extra (sortable, etc) +10


This is how to operate. It should have a brief introduction and very useful images with labels. Also it may work best for your project to use the step by step how to template {{How to}}. See #Troubleshooting for an example.


Introduce this maintenance section.


This is when to maintain what.

  • A daily task
  • A daily task
  • a weekly task
  • a weekly task
  • a monthly task
  • a monthly task
  • a yearly task
  • a yearly task
Every __ years
  • task
  • task


This is how to maintain. The step by step how to template {{How to}} is most likely best for this part.

How to Do Something
Backpack frame bike trailer Step 1 : Do something.
Aleiha's parabolic solar cooker Step 2 : Do something really complicated but made simple, etc.


Testing results

Describe the testing results.


Discuss the testing results.

Lessons learned

Discuss lessons were learned during this project and what you would do different next time.

Next steps

Discuss any next steps for the project as it goes on into the future.


This is only how to troubleshoot basic operation. For complex issues, the solution might just say contact ________. It should be a table in this format:

Problem Suggestion
Example issue Example solution or suggestion
Does not turn on Make sure it is plugged in
Another issue Et cetera


Introduce team and semester in the following format:

Grading criteria

Grading criteria for the remaining sections:

  • Grammar and spelling +10
  • Formatting +10
  • Depth, breadth and accuracy of content +70
  • Project documentation's potential for impact (e.g. reproduction) +10

All together these section grades are applied to a final grading rubric described on Moodle.


  1. For example at 305 literature review template you will see the recommendation to use Help:Footnotes.
  2. 5. Sultan, Muhammad, et al. "Experimental study on carbon based adsorbents for greenhouse dehumidification." Evergreen 1.2 (2014): 5-11.
  3. Geving, Stig, and Jonas Holme. "Mean and diurnal indoor air humidity loads in residential buildings." Journal of Building Physics 35, no. 4 (2012): 392-421. doi:10.1177/1744259111423084.
  4. Posudin, Yuriy. Methods of Measuring Environmental Parameters (1). Somerset, US: Wiley, 2014. Accessed January 30, 2017. ProQuest ebrary.
  5. 3. Seo, Y.-K., Yoon, J. W., Lee, J. S., Hwang, Y. K., Jun, C.-H., Chang, J.-S., Wuttke, S., Bazin, P., Vimont, A., Daturi, M., Bourrelly, S., Llewellyn, P. L., Horcajada, P., Serre, C. and Férey, G. (2012), Energy-Efficient Dehumidification over Hierarchically Porous Metal–Organic Frameworks as Advanced Water Adsorbents. Adv. Mater.
  6. 6. ShyeAnne. "How to Dehumidify Your Room Naturally." Dengarden. April 14, 2016. Accessed January 31, 2017.
  7. 8. The Dangers of Using Calcium Chloride for Dehumidifying. Eva-Dry. August 16, 2016. Accessed February 01, 2017.


1. "New inexpensive method for greenhouse dehumidification." Hortidaily: global greenhouse news. Accessed January 31, 2017. http://www.hortidaily.com/article/2015/New-inexpensive-method-for-greenhouse-dehumidification.

2. Geving, Stig, and Jonas Holme. "Mean and diurnal indoor air humidity loads in residential buildings." Journal of Building Physics 35, no. 4 (2012): 392-421. doi:10.1177/1744259111423084. http://journals.sagepub.com.ezproxy.humboldt.edu/doi/abs/10.1177/1744259111423084

3. Seo, Y.-K., Yoon, J. W., Lee, J. S., Hwang, Y. K., Jun, C.-H., Chang, J.-S., Wuttke, S., Bazin, P., Vimont, A., Daturi, M., Bourrelly, S., Llewellyn, P. L., Horcajada, P., Serre, C. and Férey, G. (2012), Energy-Efficient Dehumidification over Hierarchically Porous Metal–Organic Frameworks as Advanced Water Adsorbents. Adv. Mater. http://onlinelibrary.wiley.com.ezproxy.humboldt.edu/doi/10.1002/adma.201104084/full

4. Posudin, Yuriy. Methods of Measuring Environmental Parameters (1). Somerset, US: Wiley, 2014. Accessed January 30, 2017. ProQuest ebrary. http://site.ebrary.com.ezproxy.humboldt.edu/lib/hsulib/detail.action?docID=10907551

5. Sultan, Muhammad, et al. "Experimental study on carbon based adsorbents for greenhouse dehumidification." Evergreen 1.2 (2014): 5-11. http://catalog.lib.kyushu-u.ac.jp/ja/recordID/1495157?repository=yes

6. ShyeAnne. "How to Dehumidify Your Room Naturally." Dengarden. April 14, 2016. Accessed January 31, 2017. https://dengarden.com/cleaning/Ways-to-Dehumidify-Your-Greenhouse-andor-Home-Environment.

7. PSYCHROMETRICS for Engineers. PSYCHROMETRICS for Engineers. Accessed February 01, 2017.


8. The Dangers of Using Calcium Chloride for Dehumidifying. Eva-Dry. August 16, 2016. Accessed February 01, 2017.


Make sure to include other relevant categories at the bottom, e.g. [[Category:CCAT]], [[Category:Pedal_power]], etc.

Sistema de Gestión Documental (SIGEDOC)

Sistema de Gestión Documental (SIGEDOC)


El presente trabajo tiene como objetivo dar a conocer un caso de estudio real, consistente en un sistema fallido y el respectivo análisis causal, con las potenciales soluciones que podrían haberse aplicado para evitar o minimizar los riesgos de ocurrencia.

El sistema escogido corresponde al Sistema de Gestión Documental (SIGEDOC) desarrollado para la institución de gobierno, eGobChile, sobre el cual se presenta el análisis de fallas y soluciones abordando los componentes claves de todo sistema, como son: Personas, Procesos, Tecnología, Datos y los Activos Complementarios que podría también tener una injerencia en el resultado !--[if supportFields]> CITATION Ken12 \l 13322 !--[if supportFields]>![endif]-->.

Contexto y Descripción General del Sistema

El Sistema de Gestión Documental (SIGEDOC), surge de la necesidad, urgente, de contar con un Sistema de Información que opere sobre plataforma web, que permita hacer más robusta, segura y eficiente la tramitación de documentos a través de la Oficina de Partes de eGobChile.

Cabe señalar que eGobChile, es una Institución distribuida a lo largo de todo Chile, que genera normas que permiten regular al sector al cual pertenece, es por eso, que se ha declarado como crítico, el contar con un Sistema Documental que logre la conexión eficiente entre los usuarios externos (ciudadanos, proveedores, científicos, Direcciones Regionales, organismos públicos y privados, nacionales e internacionales), y los usuarios internos (Jefes, secretarias, administrativos, abogados y técnicos del negocio) clasificados según la estructura orgánica que muestra la Figura 1, a modo de visión general.

Figura 1: Vista General de la Estructura Organizacional de eGobChile

Objetivos de SIGEDOC

Como se mencionó en la descripción del Sistema, SIGEDOC es crítico para la eficiencia de eGobChile, y es por ello, que debe ser concebido para cumplir con los siguientes objetivos centrales:

!--[if !supportLists]-->1. !--[endif]-->Reemplazar el actual “Sistema de Documentos”, con el que cuenta la Institución, construido sobre una base de datos MS Access 2010, la cual fue pensada originalmente en registrar la correspondencia de la Oficina de Partes cuando existían pocos usuarios.

En la actualidad, eGobChile cuenta con 300 usuarios internos, que hacen uso de este sistema para la trazabilidad de documentos que ingresan y egresan físicamente vía Oficina de Partes. Cabe destacar, que durante el período 2015-2016, se han producido incidentes frecuentes sobre la base de datos, relacionados con la corrupción de los datos, puesto que es un archivo compartido en una carpeta de red, lo que la hace totalmente vulnerable. Estos incidentes, obligaron en varias oportunidades tener que recurrir a respaldos, y mientras se realiza el desarrollo de SIGEDOC, se restringió el acceso sólo a algunos usuarios responsables del seguimiento de documentos.

!--[if !supportLists]-->2. !--[endif]-->Desarrollar un Sistema Web, robusto y seguro, que permita gestionar la correspondencia interna y externa de eGobChile, además de llevar la trazabilidad interna de los documentos digitales o físicos. Dentro de este proceso se registran los eventos relacionados a recepción, derivaciones y envíos de correspondencia, con fecha y hora de cada cambio de estado, con el fin de realizar control y gestión.

!--[if !supportLists]-->3. !--[endif]-->Descentralizar la Oficina de partes, que actualmente se encuentra físicamente en la ciudad de Valparaíso, permitiendo a los usuarios que se encuentran en cualquier parte de territorio nacional facilitar la tramitación y digitalización de la documentación para distintos tipos de trámites, ya sea , administrativos, jurídicos o relativos a temas técnicos del negocio.

!--[if !supportLists]-->4. !--[endif]-->Contar con una plataforma tecnológica Institucional, flexible y escalable que permita la automatización de los trámites institucionales que actualmente se hacen de manera manual y llevarlos a un nivel de digitalización reconocido por el Programa de Mejoramiento de la Gestión (PMG) del Gobierno Central de Chile.

Datos del Sistema y su Procesamiento

Como en todo Sistema de Información, los datos son transformados conforme a las reglas de negocio que le permiten cumplir su propósito, transformándolos en información útil para la organización y su entorno. El diseño de SIGEDOC está diseñado en base a Sistemas que permiten procesar los datos en distintos niveles, como son:

!--[if !supportLists]-->1) !--[endif]-->Sistema de Gestión de Ingreso (SGI): Encargado de capturar los datos desde el entorno y hacerlos fluir hacia el interior de la Institución. El ingreso de los datos se puede hacer directamente por el usuario externo cuando es un trámite digital o bien desde la misma Oficina de Partes cuando el trámite es presencial o físico.

!--[if !supportLists]-->2) !--[endif]-->Sistema de Trazabilidad Documental (STD): Encargado de mover los documentos ingresados hacia el interior de la organización permitiendo llevar la trazabilidad tanto de las carpetas digitales como físicas, hasta que finalizan los respectivos trámites con una comunicación hacia el exterior.

!--[if !supportLists]-->3) !--[endif]-->Sistema de Gestión de Egreso (SGE): Encargado de despachar documentación desde el interior de la organización hacia los destinatarios externos una vez que haya terminado un trámite, o bien se haya generado documentación desde la misma Institución

La Figura 2 muestra los principales componentes de SIGEDOC y que serán descritos en más detalle en las secciones siguientes en términos de sus datos y procesamiento.

Figura 2: Mapa de Sistemas SIGEDOC eGobChile

Gestión de Ingreso

Todos los trámites pueden ser solicitados vía oficina de partes o vía Portal Web a través de la plataforma a la que los distintos tipos de usuarios acceden con su cuenta de usuario.

Para el Ingreso vía Portal Web, el solicitante debe ir al sitio www.egobchile.cl (ficticio), seleccionar la opción Trámites en Línea, si es persona natural, ingresar su Rut y clave de Acceso (Clave Única). Para el caso de Personas Jurídicas debe ingresar el Rut de la Persona Jurídica, el Rut del Administrador y la clave de acceso

El formulario de captura de datos cuenta con las siguientes 4 secciones:

!--[if !supportLists]-->1. !--[endif]-->Datos del Solicitante: Sección en la que se muestra la siguiente información del solicitante: tipo de solicitante (Persona Jurídica o Natural que realiza la solicitud), Rut, Nombre y Correo Electrónico. Además de lo anterior, el sistema permite seleccionar la opción de Aceptación por parte de quien realiza la solicitud, de la recepción de toda notificación a través del correo electrónico registrado.

!--[if !supportLists]-->2. !--[endif]-->Datos de la Solicitud: Sección en la que se deben ingresar los siguientes datos de la solicitud:

!--[if !supportLists]-->a. !--[endif]-->Tipo de Solicitud, esto es: nuevo trámite, asunto administrativo, comité u otro.

!--[if !supportLists]-->b. !--[endif]-->Materia o Rubro de la solicitud

!--[if !supportLists]-->c. !--[endif]-->Trámite a Realizar

!--[if !supportLists]-->d. !--[endif]-->Acción Asociada, que hace referencia a si es una solicitud nueva, prórroga, renuncia, informa, entre otras.

!--[if !supportLists]-->e. !--[endif]-->N° de trámite original (Sólo para aquellas solicitudes que se realizan sobre asuntos vigentes)

!--[if !supportLists]-->f. !--[endif]-->Observaciones

!--[if !supportLists]-->3. !--[endif]-->Documentación Anexa: Sección que permite adjuntar los documentos que deben ser presentados en cada trámite. El sistema debe solicitar aquellos documentos exigidos para el trámite, que no se encuentren previamente registrados por parte del usuario y que se encuentren en estado vigente.

En esta sección se indica si el documento adjunto no corresponde a un documento digitalmente válido para el trámite, en cuyo caso, éste debe ser presentado igualmente vía oficina de Partes, como un documento físico anexo a un trámite ya existente. Adicionalmente especifica el destino del documento físico al momento de ser presentado.

!--[if !supportLists]-->4. !--[endif]-->Descripción del Trámite: Sección en la que se describe, en forma breve, el trámite al cual se hace referencia.

Una vez que han sido ingresados todos los datos, el sistema entregará el número de solicitud y permitirá la impresión del comprobante de solicitud correspondiente.

Gestión Documental

Una vez que se ha realizado la Gestión de Ingreso de los documentos asociados a un trámite o solicitud administrativa, el Administrativo o Auxiliar de la Oficina de Partes organizan la documentación.

Cabe destacar que el Sistema permite realizar el despacho a destino de los documentos sin asignar éstos a una carpeta y también permite realizar el despacho previa asignación a una carpeta física que queda también registrada como una carpeta lógica.

En aquellos casos que se reciba documentación complementaria a un trámite existente, con posterioridad, el usuario responsable del trámite podrá realizar la asignación del documento a una nueva carpeta o bien reasignarla de una carpeta nueva a una ya existente.

Para registrar lo anterior, el Administrativo/Auxiliar de Oficina de partes deberá autentificarse en el sistema, ingresar a la opción Oficina de partes e ingresar al módulo “Gestión Documental”

Una vez en el formulario de Gestión Documental, debe ingresar, por ejemplo, el número de la solicitud que desea organizar o despachar a destino, reflejando cada vez el respectivo Estado del Documento.

El Administrativo/Auxiliar de Oficina de Partes selecciona o los documentos que desea trasladar del trámite asignados o no a una carpeta indicando, el ID de la carpeta, origen, destino y Estado “En tránsito” cuando va en camino al destino, o “Recibida” en caso que llegue a destino con el respectivo nombre del responsable.

Adicionalmente, el usuario que tenga permisos a este módulo del sistema podrá visualizar tanto el Historial de los Documentos por trámite, así como el Historial de las Carpetas que tienen asociada dicha documentación. En el Historial de documentos el sistema muestra cada uno de los movimientos de un documento al interior de la subsecretaría. Considerando: Estado, Fecha – Hora, Unidad y Usuario que realizaron el movimiento y Ubicación en la que quedó. En este contexto, la ubicación se refiere principalmente a las carpetas en las que se encuentran los documentos.

Gestión de Egreso

El envío documentos vía oficina de partes puede tener dos orígenes:

!--[if !supportLists]-->1. !--[endif]-->El primero de ellos, es la elaboración un documento oficial manualmente con firma física. De ser así, el Abogado que elaboró el documento, lo entrega en Oficina de Partes físicamente para su despacho. Esto también considera cualquier documento o encomienda que deba ser entregado físicamente a oficina de partes.

!--[if !supportLists]-->2. !--[endif]-->En caso que el documento sea digital, con firma digital avanzada y se esté realizando el envío vía oficina de partes, producto que el Solicitante no posee en los registros de eGobChile, un correo electrónico validado y autorizado para el envío de esta documentación, el Administrativo de Oficina de Partes deberá imprimir el documento desde el requerimiento del sistema y luego procede a ejecutar las mismas actividades que realizaría si se tratara de un documento que llegó físicamente a Oficina de Partes.

Para ambos casos anteriores, existen dos escenarios, aquellos en que la automatización del trámite se encuentra integrada con oficina de partes y el otro, en que la solicitud o trámite no se encuentra automatizado.

!--[if !supportLists]-->- !--[endif]-->En el primer escenario, oficina de partes recibirá de manera automática las notificaciones de las tareas creadas de despacho de distintos documentos desde la gestión propia de los sistemas.

!--[if !supportLists]-->- !--[endif]-->En el segundo escenario, el solicitante deberá ingresar, en el sistema, una solicitud de salida de un documento o encomienda vía oficina de partes.

Para solicitar el despacho de documentos, el profesional/técnico o administrativo de la SUBPESCA deberá autentificarse en el sistema, seleccionar del menú Categorías la opción Oficina de Partes, y acto seguido seleccionar la opción Gestión de Egresos – Solicitud de Despacho de Documentos

El formulario de Solicitud de Despacho contiene la siguiente información:

!--[if !supportLists]-->· !--[endif]-->Antecedentes de la Solicitud: Ámbito de la Solicitud, en el que se identifica la relación del documento de salida con la Subsecretaría, ejemplo: Comité, Trámite, Asunto Administrativo u otro. Además del ámbito deberá ingresar el Número de Solicitud.

!--[if !supportLists]-->· !--[endif]-->Datos del Destinatario: Deberá seleccionar el destinatario de la lista. En caso que el destinatario no se encuentre, deberá seleccionar nuevo destinatario e ingresar los siguientes datos: Rut, Nombre, Apellido Paterno, Apellido Materno, Género, Correo Electrónico, Teléfono Particular y Teléfono Móvil.

!--[if !supportLists]-->· !--[endif]-->Documento/Objetos a Despachar: En esta área de campos debe indicar el tipo de documento a despachar, el número de documento, que puede ser seleccionado de una lista que especifica los documentos asociados al destinatario o bien que puede ser ingresado manualmente, y el formato de envío de éste. En caso que el formato sea Físico Original o Encomienda, deberá hacer llegar obligatoriamente el documento físico a Oficina de Partes. En caso contrario, podrá adjuntar los documentos a la solicitud para que sean posteriormente impresas en Oficina de Partes para su envío. Deberá ingresar, además, la fecha de plazo para el envío y la vía de despacho.

!--[if !supportLists]-->· !--[endif]-->Dirección de Despacho: En caso que el destinatario no se encuentre en la lista, deberá ingresar los siguientes datos para el despacho: País, Región, Ciudad, Comuna, Código Postal y Dirección. En caso que el destinatario se encuentre en la lista podrá modificar los campos de dirección y teléfono para el envío.

!--[if !supportLists]-->· !--[endif]-->Adjuntar Documentos: En esta sección deberá adjuntar el o los documentos a despachar.

!--[if !supportLists]-->· !--[endif]-->Comentarios: Campo de texto abierto para el ingreso de comentarios o información que pueda ser de utilidad para el Administrativo de Oficina de Partes que realizará el despacho.

Una vez ingresados todos los antecedentes, el sistema entregará el número de solicitud al usuario.

Arquitectura Tecnológica SIGEDOC

El sistema SIGEDOC permite realizar el procesamiento de los datos como se presentó de manera resumida en las secciones anteriores, y la plataforma tecnológica que permite realizar esto se encuentra diagramada en la Figura 3.

-Se utiliza patrón MVC (Model View Controller) !--[if supportFields]> CITATION Try03 \l 13322 ![endif]-->[2]!--[if supportFields]>![endif]-->

-La capa de presentación se construirá utilizando HTML 4.01, CSS3 y Boostrap !--[if supportFields]> CITATION Boo \l 13322 ![endif]-->[3]!--[if supportFields]>![endif]-->

-La capa de servicios se centrará en 3 plataformas:

-.NET: capa de presentación !--[if supportFields]> CITATION Mic \l 13322 ![endif]-->[4]!--[if supportFields]>![endif]-->

-Alfresco: Gestor Documental !--[if supportFields]> CITATION Alf \l 13322 ![endif]-->[5]!--[if supportFields]>![endif]-->

-JBPM: Motor de Proceso !--[if supportFields]> CITATION JBo \l 13322 ![endif]-->[6]!--[if supportFields]>![endif]-->

.NET, Alfresco y JBPM se comunican por medio de servicios REST !--[if supportFields]> CITATION Wik \l 13322 ![endif]-->[7]!--[if supportFields]>![endif]-->

Para el gestor documental Alfresco se utiliza un servidor Windows Server 2008 R2 64 bits !--[if supportFields]> CITATION Mic1 \l 13322 ![endif]-->[8]!--[if supportFields]>![endif]-->

Para el desarrollo en .NET y JBPM se utiliza un servidor Windows Server 2008 R2 64 bits

La capa de base de datos consta de 2 sistemas administrador de base de datos

Motor de base de datos PostgreSQL !--[if supportFields]> CITATION pos \l 13322 ![endif]-->[9]!--[if supportFields]>![endif]--> para los metadatos del gestor documental Alfresco

Figura 3: Visión general de distribución de componentes

Motor de base de datos SQL Server !--[if supportFields]> CITATION Mic2 \l 13322 ![endif]-->[10]!--[if supportFields]>![endif]--> para los datos de la aplicación

Motor de base de datos SQL Server para el motor de procesos JBPM.

Active Directory provee de usuarios y grupos para el acceso a la aplicación.

Dueños de los Datos del Sistema

En estricto rigor los dueños de los datos, y la información, según la norma de Seguridad de la Información ISO 27001 !--[if supportFields]> CITATION Ins13 \l 13322 !--[if supportFields]>![endif]-->, corresponden a quienes tiene responsabilidad de asegurar la confidencialidad, la integridad, disponibilidad y autenticación. En este sentido, podríamos identificar dueños internos y externos de los datos, dependiendo en el ámbito en que se encuentren respecto de eGobChile, según muestra la Tabla 1:




Clientes Corresponde a quienes envían los datos a la Institución para los fines pertinentes, como son: Ciudadanos del sector económico de eGobChile (Ej. Informes, solicitudes de trámites, cartas), entidades públicas (Ej. Decretos, Oficios) y privadas (cartas, documentos técnicos), científicos e investigadores relacionados con el sector (Ej. Informes de Investigación, Reportes Científicos, Planos). Externo
Proveedores Corresponde a las empresas que prestan servicios a la Institución, por ejemplo, que ingresan informes de avances de proyectos en ejecución, boletas de garantías, facturas y boletas de servicios. Externo
Jefe de Servicio Corresponde al Jefe máximo de la Institución quien es el encargado de autorizar todo documento formal que se emite hacia el exterior, ejemplo, Resoluciones Exentas y No Exentas, Cartas y Oficios Interno
Jefe de Gabinete Corresponde al asesor del Jefe de Servicio que realiza la revisión de toda documentación previo a su firma Interno
Directores Regionales Corresponden a los representantes del Jefe de Servicio en regiones quienes tienen la facultad de revisar la documentación antes de enviar a firma oficial Interno
Jefes de División Corresponde a quienes tienen la facultad de aprobar o rechazar todas la documentación técnica y administrativa que tenga relación con trámites relacionados con su División Interno
Secretarias Para el caso de los trámites que se realizan de manera presencial con documentación física, corresponden a los puntos de recepción y despacho de todos los documentos que entran y salen, en las etapas intermedias del flujo, siendo el nexo entre oficina de partes y las respectivas áreas internas de la Institución. Interno
Profesionales Técnicos del Negocio Son los encargados de realizar las tareas más específicas del negocio, teniendo como insumo la documentación pertinente a su ámbito, emiten resultados de análisis a través de informes técnicos y redactan las resoluciones y cartas que posteriormente son validadas por los Jefes de División y Jurídica Interno
Administrativos Oficina de Partes Corresponden al nexo entre el entorno y la Institución, sobre todo en los que respecta a trámites presenciales donde se requiere la intervención manual para ingresar, digitalizar, archivar y despachar la documentación. Interno

Tabla 1: Dueños de los Datos

Información Generada por el Sistema

Como ya se vio en las secciones anteriores, el Sistema de Gestión Documental (SIGEDOC) permite el flujo y la trazabilidad de la documentación, con sus datos, desde el entorno hacia la Institución y desde la Institución al Entorno, permitiendo además la trazabilidad de los documentos internamente, ya sea, a través de carpetas físicas y/o digitales, lo cual es crítico para el funcionamiento de los procesos administrativos, de negocio y normativos de eGobChile.

La principal información que se genera corresponde al seguimiento documental o trazabilidad, que se materializa a través de la denominada “Hoja de Ruta”, que corresponde al registro de todos los movimientos que sufre la documentación y los datos al interior de la organización. Esta información, es utilizada por todos los involucrados en un trámite en particular, partiendo por el Cliente o Proveedor que inicia un trámite, pudiendo consultar en todo momento en qué estado se encuentra su trámite y quien es el responsable de la Institución de entregar los resultados esperados.

Los funcionarios de eGobChile usan esta información para hacer seguimiento y control de todos los trámites que sean pertinentes y que estén sometidos a niveles de servicio establecidos, con tiempos máximos de respuesta hacia el ciudadano, además, de fomentar la transparencia de la información bajo el perfilamiento de seguridad adecuado.

El Departamento de Planificación y Control utiliza la información de SIGEDOC para alimentar el Cuadro de Mando Integral (CMI), que permite llevar los indicadores de eficiencia de los trámites Institucionales, con el objeto de detectar los posibles “cuellos de botella”, y de esa forma, tomar las acciones correctivas necesarias. Algunos de estos indicadores de eficiencia, son informados al Gobierno Central en el marco de los Programas de Mejoramiento de la Gestión.

Como ya se expuso anteriormente, una de las potencialidades de SIGEDOC, es permitir, la tramitación de documentos digitales, los cuales quedan almacenados en un repositorio o gestor documental (Alfresco), con su respectivos metadatos, que sirve para consultar los expedientes históricos a través de un sistema anexo denominado Sistema de Consulta de Archivo Digital (SICAD) que es utilizado por todos los funcionarios de la Institución. Por ejemplo, si la División Jurídica quiere saber cuáles son las Resoluciones históricas, por período, que han regulado al sector atingente a eGobChile, y en determinada materia.

Análisis de Fallas del Sistema

Antes de comenzar con esta sección, es importante señalar que SIGEDOC no se muestra como caso de éxito, como se estila habitualmente en una publicación, sin embargo, para los fines académicos que se persiguen, es pertinente exponer el análisis de por qué este sistema falló desde varias perspectivas, como son las Personas, los Procesos, los Datos, Tecnología y los Activos Complementarios. Lamentablemente, el proyecto y el sistema en sí presentaron fallas en varias de esas dimensiones, y que hasta la fecha de esta publicación, se encuentran en vías de solución aquellos puntos abordables, otros simplemente ya provocaron cierto impacto. Estos últimos se analizarán en la siguiente sección.

Para mayor entendimiento de las problemáticas del proyecto, que llevaron a SIGEDOC a ser un sistema fallido, es relevante tener presente que el proyecto que dio origen a SIGEDOC se desarrolló en 2 etapas:

!--[if !supportLists]-->1. !--[endif]-->Levantamiento de Procesos, Especificaciones de Análisis y Diseño (terminado en tiempo, costo y calidad). Realizados por el área especialista en Procesos de la empresa TIProv Chile Ltda. (Equipo de Procesos), quienes generaron todos los insumos necesarios para la Construcción (segunda etapa). Las contrapartes de eGobChile fueron un Jefe de Proyectos TI, un Analista Funcional TI y contrapartes técnicas de negocio, administrativas, jurídicas y Oficina de Partes.

!--[if !supportLists]-->2. !--[endif]-->Dado el excelente trabajo realizado por TIProv Chile Ltda. en la primera etapa, se realizó la contratación directa de la Construcción, Pruebas, Pruebas de Usuario y Paso a Producción. Sin embargo, el Área de Desarrollo de Sistemas es independiente del Área de Procesos. Las contrapartes de eGobChile fueron un Jefe de Proyectos TI, un Analista Funcional TI, Ingeniero de Infraestructura TI y Oficina de Partes.

Habiendo clarificado el contexto, a continuación se presenta el estudio requerido, y para ello, la herramienta clásica para hacer este tipo de análisis, es el diagrama de Ishikawa, también conocido como diagrama causa efecto o “espina de pescado” por la forma que logra visualmente. Esta herramienta ha sido muy utilizada en los modelos de calidad aplicables a la industria, ya que, ofrece una visión global de las causas que han generado un problema y los efectos correspondientes !--[if supportFields]> CITATION Ari16 \l 13322 !--[if supportFields]>![endif]-->. La Figura 3 muestra el diagrama causa-efecto resultante del análisis de SIGEDOC como sistema fallido.

Figura 3: Diagrama Causa-Efecto Sistema Fallido (SIGEDOC)

Fallas atribuibles a Personas

En esta dimensión, surgieron los primeros problemas que causaron impacto futuro en el proyecto bajo las siguientes causales:

!--[if !supportLists]-->1) !--[endif]-->Equipo de Desarrollo sin Conocimiento: La causa corresponde a que los miembros del equipo de desarrollo original de TIProv Chile Ltda., iniciaron el proyecto desmotivados por las condiciones laborales que les ofrecía su empleador, lo cual se hizo notar en las primeras reuniones del proyecto mostrando displicencia al abordar los temas. Luego de unas semanas de trabajo en esas condiciones, se produjo el despido de uno de los programadores .NET y el cambio del Arquitecto que era experto en JBPM y Alfresco. Para suplir la situación la empresa reemplazó al programador .NET por otro quien tuvo que ser entrenado sobre la marcha para asumir los retos de JBPM y Alfresco sin tener conocimientos previos, con el apoyo de un arquitecto no presencial que se encontraba en Venezuela.'

!--[if !supportLists]-->2) !--[endif]-->Liderazgo Débil del Proyecto: La contraparte TI de eGobChile, solicitó explícitamente que la Jefa de Proyecto de la fase 1 del proyecto continuara liderando el desarrollo debido a los excelentes resultados obtenidos. Sin embargo, como el líder no pertenecía al área de desarrollo de la empresa, y los miembros estaban desmotivados, su liderazgo no fue tan efectivo como en las primeras etapa. A lo anterior, se debe agregar que luego de 3 meses de proyecto se fue con pre-natal, lo que gatilló el cambio de Jefe de Proyecto, el cual partió con mínimo conocimiento del contexto del Sistema y sin dedicación exclusiva para el proyecto.'

Fallas atribuibles a Procesos

Durante el transcurso del proyecto, quedaron en evidencia una serie de falencias relativas al proceso de desarrollo de software aplicado por la empresa, lo cual se manifestó en las siguientes causas que aportaron al Sistema fallido:

!--[if !supportLists]-->1) !--[endif]-->Planificación Deficiente: La principal causa de este problema, radica en que el Jefe de Proyectos y el equipo de desarrollo no logró el entendimiento a cabalidad de los requerimientos planteados, a pesar de que la documentación entregada en la fase 1 era bastante específica y completa (documentos de análisis y diseños logrados producto de 7 meses de trabajo). Esto llevó a realizar una mala estimación de tiempo, de costo y asignación de personal. A pesar de que el costo fue fijo para eGobChile, el tiempo fue la principal variable afectada para las expectativas del negocio, que era liberar el sistema para pruebas de aceptación de usuarios en noviembre de 2016 y partir en producción en Enero de 2017, cosa que no ocurrió.

!--[if !supportLists]-->2) !--[endif]--> Seguimiento y Control Deficiente: Cuando comenzó el proyecto con la Jefa de Proyectos anterior, se realizaban reuniones de avance todas las semanas en un día y hora determinados. Cuando fue reemplazada por el nuevo Jefe de Proyectos esta rutina dejó de hacerse, sin tener posibilidad, de revisar el avance del proyecto, los problemas y los riesgos. La contraparte de TI, solicitaba constantemente retomar estas reuniones, sin embargo, no había respuesta, ya que, como se mencionó anteriormente, el Jefe de Proyectos de la empresa tenía otras prioridades en otros proyectos.

!--[if !supportLists]-->3) !--[endif]-->Calidad del Software Deficiente. Cuando TIProv Chile Ltda., hizo entrega del primer release a eGobChile para pruebas funcionales internas, quedó de manifiesto inmediatamente que el producto no contaba con todas las funcionalidades solicitadas, una gran cantidad de errores en el sistema que bloqueaban completamente las pruebas sin poder avanzar en este proceso. Luego de analizar esta situación quedó al descubierto que la empresa no estaba aplicando el aseguramiento de calidad formal, si no que esta labor la estaba realizando el mismo desarrollador .NET.'

Fallas Atribuibles a Tecnología

Junto con los problemas ya vistos atribuibles a personas y proceso, se sumaron los problemas técnicos asociados a la plataforma soportada por la arquitectura ya explicada en la sección 2.6 Arquitectura Tecnológica SIGEDOC.

Principalmente en esta dimensión surgieron los siguientes problemas:

!--[if !supportLists]-->1) !--[endif]-->Plataforma Inestable: Luego de montar el primer release en ambiente de QA de eGobChile, el sistema presentó una serie de complicaciones relacionadas con las limitaciones de Alfresco para almacenar documentos de más de 2 Megabytes, aspecto que la empresa hasta el día de hoy no soluciona. A esto se le debe agregar que la plataforma JBMP presentaba un tiempo de más de 15 segundos en dar respuesta a la interfaz de usuario para desplegar los trámites ingresados para visualizar los estados y poder realizar el flujo. Esto implicó por lo menos, dos semanas para que el arquitecto pudiera resolver el problema.

!--[if !supportLists]-->2) !--[endif]-->Integración Tecnológica Compleja: Para este proyecto son requeridas dos integraciones tecnológicas con organismos de Gobierno distintos, Clave Única para autentificar a las personas naturales que ingresan al sistema contra el Servicio de Registro Civil e Identificación, y por otra parte, la integración con la plataforma de Firma Electrónica de Documentos del Ministerio de la Secretaría General de la Republica (MINSEGPRES). El equipo de desarrollo se encontró con muchas dificultades técnicas para lograr las integraciones en ambos frentes, a pesar de tener documentación bien detallada pero muy compleja de llevarlas a la práctica, además de la coordinación con cada organismo fue muy engorroso. Esto atrasó por lo menos un mes más el proyecto.

Fallas Atribuibles a Datos

Particularmente en esta dimensión no se encontraron hallazgos significativos que hayan tenido un impacto mayor en el resultado fallido, es por eso, que no se incluyó como parte del análisis causa efecto.

Fallas Atribuibles a Activos Complementarios

Para desarrollar este punto, ya hay una base de análisis en las secciones anteriores, y claramente, las principales causas apuntan a los siguientes activos complementarios relacionados respecto de la causa-efecto:

!--[if !supportLists]-->1) !--[endif]-->Empresa de Desarrollo No Idónea: Este activo complementario, está categorizado como un activo social, es decir, “Empresas de tecnología y servicios en mercados adyacentes para ayudar en la implementación”!--[if supportFields]> CITATION Ken12 \l 13322 !--[if supportFields]>![endif]-->. Como ya se mencionó anteriormente, la selección de la empresa de desarrollo, fue basada en el criterio de la buena experiencia en la fase 1 (Área de Procesos), sin embargo, el Área de Desarrollo, era independiente, y con ésta área, eGobChile no había tenido experiencia, además, el liderazgo de la fase 1 dio confianza junto con el antecedente de que TIProv Chile Ltda. es una empresa Multinacional valorada en un alto nivel de CMMI (Capability Maturity Model Integration) !--[if supportFields]>CITATION CMM17 \l 13322 !--[if supportFields]>![endif]-->. '

Dentro de este contexto, hubo dos principales activos complementarios que influyeron en el mal desempeño y categorización de empresa no idónea:

!--[if !supportLists]-->- !--[endif]-->Equipo de Desarrollo Débil: Desde esta perspectiva cabe señalar que eGobChile no cuenta con un equipo de desarrollo de software, ya que, está el equipo está orientado a la gestión de proyectos y análisis del negocio. Es por esto, que los desarrollos se contratan a terceros. En este caso particular, el activo organizacional relacionado con el equipo de desarrollo presentado por la empresa no fue el más adecuado, según lo declarado en las secciones anteriores.'

!--[if !supportLists]-->- !--[endif]-->Estándares de Gobierno Complejos : Otro activo complementario social, que impactó en el desarrollo negativamente, fueron los estándares para la incorporación de la firma electrónica avanzada establecido por MINSEGPRES, donde las principales dificultades radicaron en una de serie de actos administrativos para hacer uso de la plataforma, y por otro lado, la complejidad de la aplicación tecnológica. Situación similar se experimentó con la aplicación de las normas relativas al uso obligatorio de la Clave Única por parte del Servicio de Registro Civil e Identificación. Todo lo anterior, se sumó al equipo débil de desarrollo para dejar de manifiesto de la falta de idoneidad de la empresa para enfrentar el proyecto.'

Soluciones Propuestas

En esta sección se muestran conclusiones basadas en las soluciones que pudieron aplicarse, en base al análisis de las lecciones aprendidas, las cuales quedaron documentadas en la base de conocimiento para futuros proyectos, sobre todo para evitar o mitigar los riesgos e impacto negativo que ciertas situaciones puedan generar.

!--[if !supportLists]-->1) !--[endif]-->Elección de Empresa de Desarrollo Idónea: Quizás la primera reflexión que se viene a la mente después de analizar el caso en su totalidad, es simplemente, haber contratado a una empresa idónea para llevar a cabo el desarrollo de SIGEDOC, es decir, estamos en frente de un activo complementario clave, que podría haber salvado la inversión en costo, tiempo y satisfacción de las expectativas del negocio.

Esto se podría haber logrado con un proceso de licitación pública, donde se hace un llamado al mercado de empresas dispuestas a participar con sus ofertas. Los criterios de evaluación de las ofertas deberían contemplar exigencia con una alta valoración en el ítem de experiencia de la empresa en desarrollos de similares características y envergadura, años de experiencia en el mercado, Jefe de Proyectos y equipo de desarrollo con experiencia comprobable, metodología compatible con las exigencias del proyecto y certificaciones de calidad en el desarrollo de software CMMI, ISO u otra, aunque “no todo lo que brilla es oro”.

Un proceso de licitación requiere más tiempo, por los trámites administrativos que implica, pero paradójicamente, este proceso fue el que se realizó para el proyecto de levantamiento de procesos, análisis y diseño de SIGEDOC (Fase 1), y fue adjudicado meritoriamente a la misma empresa, sin embargo, como ya hemos dicho, se adjudicó al Área de Procesos, independiente del Área de Desarrollo, y que terminó en tiempo, forma y con la calidad esperada.

!--[if !supportLists]-->2) !--[endif]-->Liderazgo Efectivo: Muchos de los problemas que se generaron durante la ejecución del proyecto SIGEDOC, son frecuentes en todo proyecto donde no existe un liderazgo efectivo. Los problemas relacionados con las personas, los procesos y tecnología pudieron ser resueltos de mejor manera con una mejor gestión.

!--[if !supportLists]-->- !--[endif]-->Para el caso de las Personas, se debió contar con un Jefe de Proyecto con habilidades blandas desarrolladas, que sea capaz de motivar a su equipo de trabajo, favorecer un entorno grato de trabajo colaborativo, saber aprovechar las fortalezas y debilidades de cada uno y haber trabajado mejor la comunicación con todos los miembros del equipo. El trabajo con personas requiere de estas habilidades , tanto o más, que las habilidades técnicas y estar preparado para cualquier cambio que pudiera darse respecto del movimiento de personal, por ejemplo, considerando que este proyecto es crítico, haber asignado un miembro del equipo titular y suplente debidamente entrenado.

!--[if !supportLists]-->- !--[endif]-->Para el caso de los Procesos, aquí es donde entran las habilidades de gestión del Jefe de Proyecto, se debió exigir a un profesional 100% dedicado, con experiencia o certificado en la aplicación de las buenas prácticas de Project Management Institute (PMI) !--[if supportFields]> CITATION PMI \l 13322 !--[if supportFields]>![endif]-->, declaradas en el Project Management Body of Knowledge (PMBOK) !--[if supportFields]> CITATION PMI1 \l 13322 !--[if supportFields]>![endif]-->.

Con esto podría haber existido mayor rigurosidad en la Gestión del Alcance, siendo exhaustivo en la revisión de los documentos de procesos, análisis y diseño en conjunto con el equipo de trabajo y las contrapartes, de esta forma no hubiesen existido ambigüedades o malas interpretaciones y omisión de elementos importantes, asegurando estimaciones de tiempo, costo y personal más precisas. Además podría haber aplicado mejor la Gestión de Monitoreo y Control, realizando las reuniones de avance con frecuencia, Gestionando los Riesgos, el rendimiento del proyecto desde el punto de vista del Tiempo y del Costo, y con un adecuado Plan y equipo de Aseguramiento de Calidad, independiente del equipo de desarrollo.

!--[if !supportLists]-->- !--[endif]-->Para el caso de la Tecnología, el Jefe de Proyectos debió reclutar o contratar los servicios de los especialistas calificados en cada componente (Alfresco, JBPM) e integración tecnológica (Firma Electrónica, Clave Única), manejando sus respectivos suplentes capacitados, para no dar pie a la improvisación y permitir soluciones rápidas y efectivas en el momento.


Con todo lo expresado durante el desarrollo del presente trabajo, es importante recalcar, que un Sistema Fallido puede significar un impacto grande en una organización, la insatisfacción de toda un Institución que espera una buena solución documental, la impaciencia y frustración que ha significado un año de retraso en la entrega, con el riesgo que significa seguir trabajando con el sistema actual que se corrompe cada cierto tiempo y se pierde información vital para el cumplimiento de los propósitos organizacionales, que tienen una alto impacto en el sector.

Por otra parte, el excesivo retrabajo que ha implicado mucho esfuerzo, costos excesivos para TIProv Chile Ltda., que no han sido traspasados a eGobChile, sin embargo, el costo de oportunidad para el equipo de TI y el negocio es alto, ya que, se invierte tiempo y esfuerzo que impide avanzar en otros proyectos.

A modo de conclusión general, este trabajo debe hacer reflexionar acerca de que muchos de los problemas que llevan al fracaso los proyectos de desarrollo de Software, obteniendo Sistemas Fallidos, se explican en la variabilidad y la complejidad de gestionar a las personas, es por eso, que el desarrollo de las habilidades blandas de las personas, y sobre todo, del líder, son fundamentales, aspecto que debe ser considerado con más atención en las mallas curriculares de entidades educativas para que los profesionales egresados, se inserten en el mercado laboral con un mínimo desarrollo en las áreas blandas.


!--[if supportFields]> BIBLIOGRAPHY \l 13322 ![endif]-->

[2] T. Reenskaug, «The Model-View-Controller (MVC) Its Past and Present,» University of Oslo, Oslo, 2003.
[3] Bootstrap, «getbootstrap.com,» [En línea]. Available: http://getbootstrap.com/.
[4] Microsoft, «.NET,» [En línea]. Available: https://www.microsoft.com/net.
[5] Alfresco, «Gestión de Documentos,» [En línea]. Available: https://www.alfresco.com/es/capabilities/document-management.
[6] J. Comunity, «JBPM,» [En línea]. Available: https://www.jbpm.org/.
[7] Wikipedia, «Transferencia de Estado Representacional,» [En línea]. Available: https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional.
[8] Microsoft, «Windows Server 2016,» [En línea]. Available: https://www.microsoft.com/es-es/cloud-platform/windows-server.
[9] postgresql.org, «PostgreSQL,» [En línea]. Available: http://www.postgresql.org.es/.
[10] Microsoft, «SQL Server 2016,» [En línea]. Available: https://www.microsoft.com/es-es/sql-server/sql-server-2016.
[11] Instituto Nacional de Normalizacion . INN, Norma NCh-ISO 27001, Santiago de Chile: INN, 2013.
[12] A. d. Saeger, B. Feys y M. S. Hidalgo, El Diagrama de Ishikawa, España: 50Minutes.es, 2016.
[13] «What Is Capability Maturity Model Integration (CMMI)®?,» CMMI Institute LLC, 2017. [En línea]. Available: http://cmmiinstitute.com/capability-maturity-model-integration.
[14] PMI, «Project Management Institute,» [En línea]. Available: https://www.pmi.org/.
[15] PMI, «PMBOK® Guide and Standards,» [En línea]. Available: https://www.pmi.org/pmbok-guide-standards.

!--[if supportFields]>![endif]-->