Proyectos SociotecnológicosUna Guía para su Desarrollo en el Marco del Programa Nacional de Formación en

Informática

Elías Oswaldo Cisneros ArochaEquipo de Investigación Antonio José de Sucre

Los Teques, Venezuelacisnerose@cantv.net

Juan Vicente Cisneros ArochaEquipo de Investigación Antonio José de Sucre

Los Teques, Venezuelajuanv.cisneros@gmail.com

Resumen—El Programa Nacional de Formación enInformática (PNFI) es una iniciativa gubernamental parahomologar los programas de estudios universitarios públicos enel área de la informática a nivel nacional, el eje fundamental delPNFI son los Proyectos Sociotecnológicos (PST). Se propone unaguía de referencia para el desarrollo de PST del Trayecto III, seindican recomendaciones generales para profesores y estudiantespara el abordaje de los PST. Así mismo, se describen los roles,documentos y herramientas a emplear en cada trimestretomando como referencia la Metodología de la Red Nacional deIntegración y Desarrollo de Software Libre, el Diagnóstico SocialParticipativo y el programa de estudios del PNFI. Se indican unconjunto de estrategias, tareas y recursos para guiar el procesode desarrollo del PST. Se muestran los resultados de laexperiencia docente con dos grupos de la Unidad Curricular dePST entre los años 2011 y 2012. Uno de los principales problemasencontrados es mantener la cohesión del desarrollo del PST conel resto de las unidades curriculares del Trayecto. Finalmente, lasorientaciones indicadas en este artículo deben ser evaluadas yajustadas tomando en consideración la naturaleza de cadaproyecto, las pericias del equipo y otras variables que el docenteconsidere importantes.

Palabras clave—Proyecto Sociotecnológico, desarrollo desoftware, marco de trabajo, Programa Nacional de Formación enInformática.

I. INTRODUCCIÓN

El Programa Nacional de Formación en Informática (PNFI)es creado en 2008 por Estado Venezolano [1], entre losobjetivos del PNFI destacan la construcción de una red deconocimiento y aprendizaje para la generación, transformacióny apropiación social del conocimiento en el área de lainformática en el nivel universitario. El eje fundamental de esteprograma de estudios son los Proyectos Sociotecnológicos(PST), estos son unidades curriculares de integración desaberes y contraste entre teoría y práctica, además comprendenespacios de formación y vinculación social [1]. La motivaciónprincipal para el desarrollo de esta contribución es la escasacantidad de publicaciones arbitradas referidas a la gestión delos PST en el contexto del PNFI. En la actualidad es esencial eldesarrollo de software con calidad, de forma constante serealizan investigaciones y propuestas en este campo [2][3][4][5][6], este artículo describe un modelo de referencia basado enrecomendaciones específicas para el abordaje de los PST delTrayecto III, se describen roles, documentos, herramientas,estrategias y tareas para cada trimestre con el fin de generarsoluciones con calidad.

El método para recolectar la información consistió en larevisión de documentos oficiales y la observación directa delcampo en estudio. La población estudiada consistió en doscursos de la Unidad Curricular de Proyecto Sociotecnológico(UCPST) del Colegio Universitario de Caracas (CUC)matriculados en el Trayecto III de régimen nocturno entre losaños 2011 y 2012.

II. PROYECTO SOCIOTECNOLÓGICO III

La estructura del plan del estudios PNFI está compuestapor un Trayecto Inicial y cuatro Trayectos ordinarios, laduración de un Trayecto ordinario es de 36 semanas,equivalente a un año de estudio, dividido en 3 trimestres de 12semanas cada uno. La UCPST tiene la misma duración que unTrayecto ordinario y establece una carga horaria de 8 horassemanales, usualmente los equipos de trabajo lo conformanentre 2 y 4 estudiantes. Los PST se evalúan al final delTrayecto, y deben contar con el aval de los usuarios delsistema, los estudiantes que participaron, el profesorresponsable de UCPST y un comité de profesores.

Según cada Trayecto, la UCPST tiene un objetivoacadémico particular, los estudiantes que ingresan al TrayectoIII deben haber desarrollado en el Trayecto anterior lascompetencias de desarrolladores de software y de modeladoresde bases de datos de baja o mediana complejidad. En elTrayecto III se exige la identificación de un problema en elámbito comunitario, la descripción de los factores que logeneran y el desarrollo de un sistema informático que mejore lasituación problemática, cumpliendo el tiempo establecido ycon atributos de calidad [1]. Para cumplir los objetivosacadémicos los estudiantes aplican los conocimientos teóricosy prácticos obtenidos en cada Unidad Curricular (UC) delTrayecto III. Las Unidades Curriculares (UUCC) que aportanlos conceptos teóricos y prácticos para alcanzar estos objetivosse observan en la Tabla I.

TABLA I: UNIDADES CURRICULARES DEL TRAYECTO III

TrayectoIII

TrimestreIII

Investigaciónde Operaciones

ElectivaTodo el Trayecto:

- Proyecto Sociotecnológico

- Ingeniería del Software

-Formación Crítica

TrimestreII

Matemáticaaplicada II

Modelado deBases de Datos

Trimestre I

Matemáticaaplicada I

SistemasOperativos

175

Sesión de Gestión de Tecnologías de Información

Cada UC realiza aportes teóricos y prácticos durante lasfases específicas del proyecto, en el caso particular delTrayecto III, se esperan aportes en cuanto a enfoques socio-críticos, habilidades de razonamiento lógico, habilidadesinformáticas y habilidades para la gestión de proyectos, estasse desarrollan respectivamente en las siguientes UnidadesCurriculares:

UC Formación Crítica (FC): aportes en la vinculaciónsocial del proyecto, su importancia en el marco deldesarrollo de las capacidades técnicas nacionales, laconveniencia del uso de tecnologías de estándaresabiertos y/o software libre. Indicar orientaciones haciael desarrollo tecnológico nacional y el impulso de lasoberanía tecnológica.

UC Matemática aplicada (MA): aportes sobre laselección de métodos estadísticos, probabilísticos,modelos matemáticos y/o teoría de grafos aplicados a lanaturaleza del proyecto. Orientaciones sobre técnicascomputacionales para el procesamiento de datos.

UC Investigación de operaciones (IO): aportes sobre eluso de modelos matemáticos, estadística y algoritmoscon objeto de apoyar el proceso de toma de decisiones.Estudiar sistemas reales, con la finalidad de mejorar sufuncionamiento mediante los métodos de maximizacióno minimización.

UC Ingeniería de Software (IS): aportes teóricos yprácticos sobre modelos, herramientas y métodos parael desarrollo de software de calidad, paradigmas deprogramación, mejores prácticas de arquitectura desoftware según la naturaleza de cada proyecto.

UC Sistemas operativos (SO): aportes sobre laelección de sistemas operativos, sobre la infraestructuradel proyecto en cuanto a arquitecturas distribuidas,clientes servidor, entre otras. Mecanismos de seguridadde los sistemas operativos empleados en lainfraestructura del proyecto.

UC Modelado de bases de datos (MBD): aportes sobremodelos de persistencia de datos según losrequerimientos del proyecto, diseño, normalización yoptimización del modelo de datos del proyecto.

UC Proyecto Socio-Tecnológico: habilidades asociadasa la gestión de proyectos y asesoramientometodológico.

Esta guía está alineada al enfoque de cohesión entre las UCdel Trayecto III (Fig. 1), para ello se debe establecer un espacioperiódico de discusión entre los profesores del Trayecto paramantenerse articulados sobre los avances de cada equipo dePST y las dificultades particulares que presentan. Serecomienda vincular los documentos requeridos en la UCPSTcon algunas de las asignaciones del resto de las UC, de estamanera se podrá garantizar los aportes en estos documentos porparte de cada profesor.

III. MERINDE Y EL DIAGNÓSTICO SOCIAL PARTICIPATIVO

En concordancia con los lineamientos de soberaníatecnológica nacional [7][8] se consideró una metodología paraproyectos el desarrollo de software creada en el país, esta es la

Metodología de la Red Nacional de Integración y Desarrollo deSoftware Libre (MeRinde), esta es producto de la integraciónde mejores prácticas entre varias metodologías y marcos detrabajo del área de desarrollo de software [5]. Esta metodologíaes el resultado de un proyecto venezolano auspiciado por elEstado [9], propone un estándar para el proceso de desarrollode software que puede ser empleado y adaptado según losrequerimientos de cualquier comunidad u organización.MeRinde provee un conjunto de plantillas que sirven de puntopartida para los documentos utilizados en proyectos dedesarrollo de software.

Para vincular la metodología MeRinde con el Trayecto IIIse toma en cuenta el tiempo que se dispone para desarrollar elPST, este es de 36 semanas, dividido en 3 trimestres de 12semanas cada uno. Por otra parte, MeRinde establece 4 fases,las cuales son Inicio, Elaboración, Construcción y Transición.Para aplicar MeRinde se propone el esquema planteado en laFig. 2. Al finalizar el Trimestre I se debe obtener el objetivo delProyecto y la arquitectura candidata, ambos son hitos de lasfases Inicio y Elaboración respectivamente. Al finalizar elTrimestre II se espera que la solución propuesta tenga unacapacidad operacional con la mayoría de los requerimientosimplementados y finalmente en el Trimestre III la solucióndebe estar operativa para los usuarios, adicionalmente se esperaque la solución desarrollada sea liberada con alguna licenciaque permita su reutilización.

Por otra parte, el Diagnóstico Social Participativo (DSP)[10] es un método que permite el abordaje de una realidadsocial a través de la identificación de los problemas que afectana la población, con el fin de actuar sobre ella para ocasionarcambios, tomando en cuenta la participación activa de lapoblación y las instituciones vinculadas a la realidad socialestudiada. El DSP es aplicado durante la Fase de Inicio en elTrimestre I y proporciona una guía para el abordaje de lacomunidad para la cual se desarrolla el PST, enfocando losesfuerzos para identificar el contexto social, geográfico yeconómico. Adicionalmente se toma su planteamiento parapriorizar los problemas que inciden en la comunidad, suscausas y efectos; así como su enfoque para identificar elobjetivo del proyecto, sus medios y fines. Se generó unaplantilla llamada “Identificación del Proyecto” en la cual seincluyen aspectos relevantes del DSP relacionados con elplanteamiento del problema en estudio.

Fig. 1. Enfoque de cohesión entre las unidades curriculares III

176

Cuarta Conferencia Nacional de Computación, Informática y Sistemas / CoNCISa 2016 / ISBN: 978-980-7683-02-9 Colegio Universitario de Caracas, Caracas, Venezuela - 26 al 28 de octubre de 2016

A. Estimación del alcance de un Proyecto Sociotecnológico

Continuamente se realizan investigaciones en el área de laplanificación de proyectos de software que proponen diversosmétodos para abordarlos [11][12][13]. En el caso de estaexperiencia se consideró tomar como referencia la cantidad dehoras académicas que se disponen en la UCPST (8 horassemanales) y la cantidad de integrantes del equipo de PST. Enla Tabla II se observan la cantidad de horas que se disponensegún el escenario para 2, 3 y 4 integrantes por equipo de PST.

Esta estimación permite formar un criterio al momento deestablecer el alcance de un PST, además se deben considerar lacantidad de requerimientos, el tipo de infraestructuratecnológica, el área o dominio del negocio, la actualidad de latemática, las pericias de cada equipo, entre otras. Según laexperiencia de los autores en proyectos del PNFI se consideróque el esfuerzo total del PST se corresponde con 9% en tareasla fase de Inicio, 25% en tareas de la fase de Elaboración, 33%en tareas de la fase de Construcción y 33% en tareas de la fasede Transición, sin embargo estos criterios pudieran serajustados según el contexto de cada PST. Siguiendo la mejorpráctica de “demostrar resultados iterativamente eincrementalmente” propuesta por MeRinde, se recomiendaestablecer iteraciones de aproximadamente 3 semanas deduración, se espera que en cada trimestre se logren realizar 4iteraciones. En la Tabla III se observan la cantidad de horasestimadas que se dedican a cada fase de MeRinde durante laduración de la UCPST.

En la Fig. 3 se observa el énfasis de las disciplinas deMeRinde en cada iteración, así mismo se indican la cantidad deiteraciones en cada trimestre.

A continuación se indican las disciplinas de MeRinde y susaportes al desarrollo del PST:

Modelado de Negocio: analizar los procesos y laidentificación de los casos de uso del negocio,adicionalmente se incorpora el Diagnóstico SocialParticipativo con el propósito de identificar causas yefectos del problema, actores involucrados, yfinalmente medios y fines para solucionar el problema.

Requerimientos: capturar los requerimientosfuncionales y no funcionales, analizarlos, priorizarlos.El objetivo principal de esta disciplina es identificar lasfunciones del sistema.

Análisis y Diseño: transformar los requerimientos auna especificación que describa cómo implementar elsistema. El análisis consiste en obtener una visión delsistema a desarrollar. Por otro lado, el diseño es unrefinamiento que toma en cuenta como el sistemacumple sus objetivos.

Implementación: convertir los elementos del diseño enelementos de implementación, dichos elementos soncódigos fuentes, ejecutables, binarios, entre otros.

Pruebas: evaluar la calidad del producto que se estádesarrollando, mediante la aplicación de pruebas paravalidar que las suposiciones hechas en el diseño y losrequerimientos se estén cumpliendo satisfactoriamente,esto quiere decir que se verifica que el productofuncione como se diseñó y que los requerimientos sonsatisfechos. Probar y certificar la solución en elambiente operativo del cliente.

Implantación: distribuir e instalar el sistemadesarrollado y asegurar la disponibilidad del productopara los usuarios finales.

Gestión de Configuración y Cambios: mantener laintegridad de todos los objetos que se crean en elproceso y controlar los cambios. Se debe identificarelementos de configuración, restringir y auditar loscambios a esos elementos.

Gestión de Proyecto: realizar estudio de factibilidad,alcanzar los objetivos propuestos, administrar el riesgoy superar las restricciones para desarrollar un productoque sea acorde a los requerimientos de los usuarios.

Fig. 3. Disciplinas e iteraciones en el contexto del Trayecto III

TABLA III: HORAS SEGÚN INTEGRANTES DEL PST Y LA FASE DE MERINDE

Fig. 2. Relación entre Trimestres de PNFI y fases de MeRinde

TABLA II: INTEGRANTES Y HORAS ACADÉMICAS PARA DESARROLLAR EL PST

177

Sesión de Gestión de Tecnologías de Información

Gestión del Ambiente: dar soporte al proyecto con losprocesos, métodos y herramientas correctas. Ofrecer lasherramientas, plantillas, documentos, lineamientos aseguir para el desarrollo del software y del proyecto.

IV. ROLES, DOCUMENTOS Y HERRAMIENTAS

La conformación del equipo de PST es un asuntoimportante, cada integrante debe aportar habilidades esencialespara contribuir al proyecto [14][15][16]. Es común permitir laconformación voluntaria de los equipos de proyecto, sinembargo esta práctica puede generar equipos con habilidadesdesequilibradas. En este sentido, es aconsejable definir unmétodo que permita caracterizar las habilidades de cadaestudiante y proponer la conformación de equipos de trabajoequilibrados, en los cuales sus integrantes complementen susfortalezas y debilidades. Algunos criterios pueden ser lashabilidades técnicas en modelado de requerimientos, análisis ydiseño, programación, dominio de sistemas operativos, entreotras. También son importantes habilidades como la capacidadpara trabajar en equipo, redacción, gestión del tiempo,liderazgo, entre otras. A continuación se indican los roles másimportantes y su participación a lo largo del PST.

A. Roles propuestos

A medida que el proyecto avanza los miembros del equipoasumen distintos roles, la decisión de la asignación de los rolespuede ser consensuada entre el equipo de PST y el Profesor,tomando en cuenta las fortalezas de los integrantes del equipoy el desempeño que cada uno demuestre en las tareas delproyecto. A continuación se indican los roles que se consideranindispensables en el contexto del PST del Trayecto III:

Analista de Calidad: velar por el cumplimiento de lasmejores prácticas, se encarga de revisar los documentosque reflejan el avance del proyecto (diagrama Gantt,actas de reunión, reporte de pendientes, y otras afines alcontrol y seguimiento del proyecto), y de verificar quelos objetivos se cumplan.

Analista de Producto: dirigir el proceso de captura derequerimientos, definir los actores y casos de uso yestructurar el modelo de casos de uso, estableciendo laforma en que funcionará el sistema y cuáles son lasrestricciones del mismo.

Arquitecto de Software: definir la arquitectura delsistema y de la refinación de la misma en cadaiteración; debe construir prototipos necesarios paraprobar aspectos riesgosos desde el punto de vistatécnico; define los lineamientos generales del diseño yla implementación.

Desarrollador: codificar los componentes en códigofuente en algún lenguaje de programación; debeelaborar y ejecutar las pruebas unitarias realizadas sobreel código desarrollado; es responsable de loscomponentes que ha desarrollado debiendodocumentarlos, actualizarlos ante cambios ymantenerlas bajo el control de configuración mediantealguna herramienta.

Probador: realizar las pruebas definidas previamente,utilizando las instrucciones, métodos y herramientasnecesarias para esta tarea.

Analista de infraestructura: configurar y administrarlos recursos de infraestructura para el funcionamientodel sistema que está en desarrollo, esto incluye losaspectos de telecomunicaciones, procesamiento yalmacenamiento de datos.

Existen otros roles importantes, el involucrado, este rolagrupa a las personas que requieren la solución, estos puedenser usuarios y/o clientes. También están los profesores delTrayecto III, estos asumen el rol de Mentores, realizanacompañamiento a los equipos de trabajo mediante revisionesde los documentos y haciendo recomendaciones para mejorarlos mismos, cada profesor del Trayecto III hace aportes segúnla UC asignada y las disciplinas que les correspondan, estoscomplementan aspectos específicos según las orientaciones delProfesor de la UCPST. Estos Mentores están en la capacidad deaclarar dudas que puedan surgir sobre su área de competencia,así como también contribuir en la calidad general del desarrollodel proyecto. A continuación, en la Tabla IV se muestra laparticipación de cada rol según el trimestre en que se encuentreel PST.

B. Documentos propuestos

En este apartado se describen un conjunto de documentosy/o artefactos que han sido adaptados al contexto de la UCPST,estos están basados en MeRinde, el DSP y el plan de estudiosdel PNFI, a continuación se describen:

Identificación del proyecto: contiene elementos deldiagnóstico social participativo, la definición de lasituación problemática, objetivo general, específicos,causas, efectos, medios y fines de la propuesta deProyecto. Se aborda un estimado de costos y un análisisde factibilidad general. Finalmente las autoridadesacadémicas deciden sobre la aprobación de la propuestade PST.

Planificación, riesgos y visión: describe el alcance delproyecto, las tareas a realizar, los riesgos identificados yvisión general del sistema.

Especificación de requerimientos: indica losrequerimientos del sistema, describe las funciones delsistema, los requerimientos no funcionales,características del diseño, y otros elementos necesariospara proporcionar una descripción completa ycomprensiva de los requerimientos.

TABLA IV: PARTICIPACIÓN TRIMESTRAL DE LOS ROLES DEL PST

178

Cuarta Conferencia Nacional de Computación, Informática y Sistemas / CoNCISa 2016 / ISBN: 978-980-7683-02-9 Colegio Universitario de Caracas, Caracas, Venezuela - 26 al 28 de octubre de 2016

Documento de arquitectura: indica las especificacionesprincipales del diseño, proporciona una descripción dela arquitectura del sistema y sirve como medio decomunicación entre el arquitecto de software y otrosmiembros de equipo del proyecto con respecto a lasdecisiones arquitectónicas que se han tomado en elproyecto. Contiene varias vistas que muestran aspectosdistintos del sistema como son: vista de casos de uso,vista lógica, vista de implementación, vista del proceso,vista de implantación y vista de persistencia.

Plan de pruebas: especifica los casos de prueba yprocedimientos de prueba, este artefacto incluye elpropósito de las pruebas, elementos a probar,herramientas a utilizar y recursos. Al tener el resultadode las pruebas se puede comparar lo obtenido con loesperado.

Plan de implantación: describe el conjunto de tareaspara poner en funcionamiento el sistema en lasinstalaciones de los usuarios. Las actividades descritasen este documento abarcan temas referentes a lainstalación del sistema, instrucciones específicas sobrela sustitución de antiguos sistemas, compatibilidad delsistema, estrategias de migración y adaptación al nuevosistema, así como planes de contingencia en caso defallos que garanticen el menor impacto a la continuidaddel negocio.

Manual de usuarios: describe las funcionalidades delsistema desde la perspectiva de los usuarios, estáenfocado como un documento de ayuda a las personasque manipularan directamente el sistema.

Memoria descriptiva: es un requisito académico delPNFI que contiene la descripción de las actividades másrelevantes realizadas durante el desarrollo del PST.

A continuación, en la Tabla V se muestran los documentosy su evolución a lo largo del Trayecto III.

En la Tabla VI se muestra el esquema de revisiones porparte de los profesores de cada UC, las revisiones de cadaprofesor se deben enfocar hacia su área de competencia. Lasrevisiones de los documentos son coordinadas por el profesorde la UCPST, para ello se debe establecer un espacio decoordinación entre los profesores del Trayecto III. Existen ungrupo de documentos complementarios que se consideran degran valor para el proyecto, a continuación se describen:

Portafolio de evidencias: compendio de minutas,fotografías, avales de asistencia a jornadas técnicas,cursos, talleres, entre otros.

Vídeo testimonial: material audiovisual para mostrarlas actividades desarrolladas durante la realización delPST, es importante reflejar el testimonio de losinvolucrados, la situación problemática y los resultadosobtenidos con la implantación del sistema.

Avances del Trimestre I: documento con los avancesmás significativos del Trimestre I.

Avances del Trimestre II: documento con los avancesmás significativos del Trimestre II.

Sitio informativo: sitio web disponible en internet conlos aspectos más relevantes del PST, debe incluirobjetivo del proyecto, logros, capturas de pantallas,identificación del equipo de proyecto, información decontacto, documentación de interés.

Aval de divulgación pública: certificado depresentación del proyecto en una jornada dedivulgación de conocimientos o mediante unapublicación en alguna revista de acceso público.

Encuesta de valoración de usuarios: contiene lasvaloraciones de los usuarios luego de utilizar el sistemacon el propósito de conocer la aceptación del sistema ymejorar sus atributos de calidad.

A continuación, en la Tabla VII se observa la evolución decada uno de los documentos complementarios a lo largo delTrayecto III.

C. Herramientas propuestas

Durante el desarrollo del PST se utilizan variasherramientas de apoyo, los profesores del Trayecto III debenorientar a cada equipo sobre las herramientas más adecuadassegún la naturaleza de cada PST, a continuación se describenalgunas categorías de estas herramientas y se sugieren algunasque respetan los lineamientos de soberanía tecnológicanacional:

TABLA VI: DOCUMENTOS Y REVISIONES POR PARTE DE LAS UC DELTRAYECTO III

TABLA VII: EVOLUCIÓN DE LOS DOCUMENTOS COMPLEMENTARIOS

TABLA V: ELABORACIÓN Y EVOLUCIÓN DE LOS DOCUMENTOS

179

Sesión de Gestión de Tecnologías de Información

Generador de diagramas UML: crear los diagramas deingeniería de software como casos de uso, de clases, deactividades, de despliegue, de estados, entre otros. Sesugieren las herramientas Modelio, Umbrello yStarUML.

Diseñador de prototipos: crear prototipos de pantallasy validar los requerimientos funcionales. Se sugiere laherramienta Pencil Project.

Planificador de Proyectos: reflejar la planificación delproyecto, tareas, documentos, responsables, entre otros.Se sugiere la herramienta OpenProj.

Documentador de código fuente: documentar elfuncionamiento del código fuente, se generadocumentación detallada sobre los módulos, clases,atributos, métodos, entre otros. Se sugieren lasherramientas PHPDoc y PyDoc.

Gestor de versiones de software: mantener el controlsobre las versiones desarrolladas, es de utilidad paraequipos de trabajo que deben reutilizar componentes desoftware. Se sugiere la herramienta Subversion y Git.

Gestor de incidencias de software: documentarsistemáticamente las fallas, problemas y solucionesencontradas en el software. Se sugiere la herramientaMantis BT.

Monitor de recursos de hardware: obtener informaciónsobre el desempeño del software y el hardware almomento de realizar las pruebas de rendimiento.

Generador de pruebas de carga: diseñar y aplicarescenarios de pruebas de carga de datos, como ejemploconexiones a la base de datos, peticiones a losservidores, entre otras. Se sugiere la herramientaApache Jmeter.

Gestor de contenidos para la web: difundir en internetlos avances del proyecto y captar el interés de parte depotenciales usuarios. Se sugieren las herramientasDrupal y Wordpress.

Gestor de máquinas virtuales: implementar unainfraestructura de desarrollo y de pruebas empleandotécnicas de virtualización, así como implementarinfraestructuras con varios sistemas operativos. Sesugiere la herramienta VirtualBox.

En la Tabla VIII se muestra el énfasis que se emplea encada herramienta según el trimestre del Trayecto III.

V. ESTRATEGIAS, TAREAS Y RECURSOS

A continuación se presentan un conjunto de estrategias,tareas y recursos que pueden ser empleados por los profesoresde la UCPST para el desarrollo de sus clases, estos aspectosson referenciales y deberán ser evaluados por cada profesorsegún las características de cada PST y su contexto académico.

A. Estrategias

Se sugieren un conjunto de estrategias a lo largo lostrimestres que guíen el desarrollo de las actividades, en la TablaIX se describen estas estrategias.

TABLA IX: ESTRATEGIAS APLICADAS EN LA UCPST DEL TRAYECTO III

Trimestre Estrategias

Trimestre I Investigar la comunidad para conocerla, describirla ydetectar necesidades.Investigar sobre el campo de acción del proyecto.Investigar sobre la metodología de investigación y sobrela metodología de desarrollo de Software.

Trimestre II Aplicar un enfoque modular de la arquitectura delsoftware.Aplicar técnicas para pruebas de software.

Trimestre III Socializar la experiencia mediante la publicación enrevistas de acceso público, jornadas de divulgación,congresos e Internet.

Común a todos los trimestres se consideran las siguientesestrategias:

Asignar roles y responsabilidades en función de lasfortalezas del equipo de proyecto.

Realizar reuniones periódicas con los involucrados.

Participar en las asesorías con los profesores del restode las UC del Trayecto III.

Realizar reuniones de asesoría con especialistas deplataforma, bases de datos, desarrollo de software parael diseño de la Infraestructura Tecnológica.

Aplicar un enfoque iterativo e incremental para laimplementación de las funcionalidades del sistema.

Asistir a jornadas técnicas y académicos para conocersobre temas de actualidad.

Revisar los contenidos y lecturas complementariasindicadas por el profesor de la UCPST.

Tareas

El PST se evalúa al finalizar el Trayecto III, sin embargo,para facilitar el seguimiento del proyecto a lo largo lostrimestres se describen un conjunto de tareas de referencia, enla Tabla X se describen estas tareas.

TABLA VIII: USO DE LAS HERRAMIENTAS EN CADA TRIMESTRE

180

Cuarta Conferencia Nacional de Computación, Informática y Sistemas / CoNCISa 2016 / ISBN: 978-980-7683-02-9 Colegio Universitario de Caracas, Caracas, Venezuela - 26 al 28 de octubre de 2016

TABLA X: TAREAS EN LA UCPST DEL TRAYECTO III

Trimestre Tareas

Trimestre I Conformar el equipo de trabajo.Abordar al menos una comunidad e identificar lasnecesidades y oportunidades de mejora aplicando undiagnóstico social - participativo.Formular al menos una propuesta de proyecto, elaborar elplanteamiento de la situación problemática y susantecedentes.Definir los objetivos, alcance, factibilidad del proyecto.Identificar los riesgos.Definir las bases de teóricas según el campo de acción.Definir los requisitos funcionales y no funcionales.Realizar el análisis y diseño del sistema (diseñar prototiposno funcionales, modelo de persistencia, modelo de lógico).Configurar la plataforma de desarrollo.Elaborar la arquitectura candidata (implementar los casos deuso críticos relacionados a la arquitectura).

Trimestre II Refinar la arquitectura del sistema.Implementar las funcionalidades definidas en el alcance.Realizar las pruebas funcionales y de rendimiento.

Trimestre III Planificar la implantación del sistema.Elaborar la documentación para los usuarios.Configurar la plataforma de producción.Implantar el sistema.Obtener los indicadores de mejora de procesos.Divulgar los resultados del proyecto.Hacer de acceso público el código fuente del sistema conalgún licenciamiento que permita su reutilización.Presentar los resultados ante las autoridades académicas y lacomunidad beneficiada.

Común a todos los trimestres se consideran las siguientestareas:

Mitigar los riesgos identificados.

Hacer seguimiento al avance del proyecto.

Actualizar y registrar los cambios de todos losartefactos generados.

Realizar una presentación de avances.

En la Tabla XI indican un conjunto de contenidos,herramientas y plantillas que sirven de apoyo al desarrollo delas tareas indicadas en cada trimestre.

TABLA XI. RECURSOS EMPLEADOS EN LA UCPST DEL TRAYECTO III

Trimestre Recursos

Trimestre I Diseñador de prototipos.

Trimestre II Gestor de máquinas virtuales.Documentador de código fuente.Gestor de versiones de software.Gestor de incidencias de software.Monitor de recursos de hardware.

Trimestre III Gestor de máquinas virtuales.Generador de casos de pruebas de carga.Gestor de contenidos.

Común a todos los trimestres se consideran las siguientesherramientas y recursos:

Generador de diagramas UML.

Plantillas de documentos y/ artefactos.

Bibliografía especializada.

Contenidos generados por el Profesor.

Finalmente, en la Fig. 4 se observa el engranaje de los rolesprincipales, documentos y herramientas en los trimestres delTrayecto III, de esta forma se establece un modelo dereferencia para el abordaje de los PST con un enfoque donde seintegra las distintas disciplinas de la Ingeniería de Software conlos aportes de las áreas de conocimiento de todas las UC queconforman el Trayecto III del PNFI.

VI. CONCLUSIONES

En este artículo se define una guía de referencia para elabordaje de los PST del Trayecto III del PNFI, este modelodetalla un conjunto de actividades referenciales para guiar eldesarrollo del PST, incluye un conjunto de plantillas quepermiten organizar el proceso de documentación, indicaalgunas herramientas de apoyo a la gestión de proyecto yplantea un esquema para vincular las Unidades Curriculares delTrayecto III con la UCPST. Este modelo fue aplicado a dossecciones de la UCPST del Trayecto III del PNFI entre los años2011 y 2012 en el CUC, con un total de 56 estudiantes y 17equipos de PST, los resultados obtenidos con la aplicación deestas orientaciones fueron los siguientes:

El 70% de los equipos de PST (12) finalizaron laUCPST y fue aprobado el PST por parte del ComitéEvaluador.

El 24% de los equipos de PST (4) finalizaron laUCPST pero el PST no fue aprobado por el ComitéEvaluador.

El 6% de los equipos de PST (1) se retiraron del cursoantes de terminar la UCPST.

En la Fig. 5 se muestra la relación entre los PST aprobados,no aprobados y los no finalizados.

El PNFI propone un cambio de paradigma en el contextouniversitario venezolano, por ello es necesario explicardetalladamente a los estudiantes y profesores el objetivo de laUCPST, el método de evaluación, el perfil técnico del PST ydemás aspectos metodológicos. Así mismo se debe explicar elcarácter flexible de los enfoques aplicados para abordar los

Fig. 4. Trimestres, roles, documentos y herramientas

181

Sesión de Gestión de Tecnologías de Información

PST los cuales permiten a los profesores seleccionar aquellosmétodos que mejor se adapten a cada contexto de proyecto.Las orientaciones expuestas en este artículo deben serevaluadas y ajustadas según el contexto de cada PST, tomandoen consideración la naturaleza de cada proyecto.

También es importante recalcar la función del profesor dela UCPST como director de los proyectos, con el propósito deevaluar y facilitar la incorporación de los aportes provenientesde las demás Unidades Curriculares. En este sentido, lasprincipales dificultades se encontraron en la alineación decriterios entre la UCPST y el resto de las UnidadesCurriculares del Trayecto III, fue necesario esfuerzosimportantes para mantener el enfoque de cohesión de lasactividades de la UCPST, se realizaron múltiples reunionesentre los profesores que atienden el resto de las UnidadesCurriculares, en algunos casos no se alcanzó la receptividadesperada, sin duda este es uno de los desafíos más importantespara lograr implantar el modelo propuesto en este artículo.

Finalmente, para futuras experiencias en la UCPST seplanteará conformar un repositorio de acceso público deProyectos, empleando algún licenciamiento que permita sureutilización con alguna licencia compatible con la filosofía delSoftware Libre.

REFERENCIAS

[1] MPPEU. Programa Nacional de Formación en Informática. Ministeriodel Poder Popular para la Educación Universitaria, Caracas, Venezuela.2008.

[2] E. Paikari. “Model-based planning and control for balancingfunctionality and quality in iterative software construction” (Order No.NS23817). 2013. Available from ProQuest Dissertations & Theses FullText: The Sciences and Engineering Collection. (1518961409).Retrieved from http://search.proquest.com/docview/1518961409?accountid=50437 .

[3] J. Alvarez, S. Solé . “Experiencia en aseguramiento de calidad en elámbito de software libre”. Revista Electrónica Conocimiento Libre yLicenciamiento. No 8. Año 4. 2014. ISSN: 2244-7423 . Disponible en:http://convite.cenditel.gob.ve/files/2015/01/ExperienciaRevistaCLIC_n8_1.pdf.

[4] M. Stefanovic. “Advanced software engineering models for qualityimprovement” (Order No. MQ60501). Available from ProQuestDissertations & Theses Full Text: The Sciences and EngineeringCollection. (304745151). 2001. Retrieved from http://search.proquest.com/docview/304745151?accountid=50437

[5] K. Domínguez, M. Pérez, L. Mendoza, K. Santos, C. Marrero, H.Rivero. “Gestión de proyectos de desarrollo de software libre con unenfoque de calidad”. XII Seminario Latino-Iberoamericano de Gestión

Tecnológica, 2007. Disponible en: http://www.altec-dl.org/index.php/altec/article/view/1456

[6] E. Ichu. “Quality assurance in software development: An exploratoryinvestigation in software project failures and business performance”.(Order No. 3404630). Available from ProQuest Dissertations & ThesesFull Text: The Sciences and Engineering Collection. (518658207). 2010Retrieved from http://search.proquest.com/docview/518658207?accountid=50437

[7] Ley de Infogobierno, Gaceta Oficial de la República Bolivariana deVenezuela No. 40.274. Caracas, 2013. Disponible en: http://www.cnti.gob.ve/images/stories/documentos_pdf/leydeinfogob.pdf

[8] Decreto 3.390, Gaceta Oficial de la República Bolivariana de VenezuelaNo. 38.095. 2004. Disponible en: http://www.cnti.gob.ve/images/stories/documentos_pdf/decreto3390softwarelibre.pdf

[9] C. Marrero, K. Santos. “Metodología de la red nacional de integración ydsarrollo de software libre (MeRinde). Guía detallada”, CentroNacional de Tecnologías de Información. 2007. Disponible en:http://www.merinde.net/

[10] L. Sánchez. Diagnóstico social participativo. Caracas, Venezuela. FondoEditorial de la Fundación Escuela de Gerencia Social del Ministerio dePlanificación y Desarrollo. 2005 . ISBN: 980-6424-52-2.

[11] F. Gharehchopogh, A. Talebi, I. Maleki. “Analysis of use case pointsmodels for software cost estimation”. International Journal Of AcademicResearch, 6(3), 118-124. 2014, doi:10.7813/2075-4124.2014/6-3/A.16

[12] R. Rezaei, B. Arasteh. “A new method in software cost estimation withtabu search”. International Journal Of Academic Research, 6(5), 41-45.2014, doi:10.7813/2075-4124.2014/6-5/A.7

[13] S. Ebrahimi, A. Jafarian. “A new model for software cost estimation byusing artificial bee colony algorithm”. International Journal OfAcademic Research, 6(4), 178-184. 2014 doi:10.7813/2075-4124.2014/6-4/A.24

[14] M. André, M. Baldoquín. “Un sistema de soporte a la decisión para laasignación de recursos humanos a equipos de proyectos de software”.Revista Investigación Operacional Vol. 31, No. 1, 61-69 2010.Disponible en: http://rev-inv-ope.univ-paris1.fr/files/31110/31110-04.pdf

[15] J. Llorens. Gerencia de Proyectos de Tecnología de Información. Cómoorganizar, planificar, estimar, evaluar y controlar exitosamenteproyectos de tecnología de información. Caracas, Venezuela. EditorialCECSA. 2005. ISBN: 980-388-186-8.

[16] R. Pressman. Ingeniería del Software, un enfoque práctico. 6a ed.Distrito Federal, México. Editorial Mc Graw Hill. 2005 . ISBN: 970-10-5473-3.

Fig. 5. Resultados finales de los PST durante el período de estudio

182

Cuarta Conferencia Nacional de Computación, Informática y Sistemas / CoNCISa 2016 / ISBN: 978-980-7683-02-9 Colegio Universitario de Caracas, Caracas, Venezuela - 26 al 28 de octubre de 2016