Un Framework Unificado de Desarrollo de Software para los Pregrados Relacionados con Ingeniería de Sistemas

Descargar este artículo en PDF (clic aquí)

Un Framework Unificado de Desarrollo de Software para los Pregrados Relacionados con Ingeniería de Sistemas

Jorge Hernán Abad Londoño

Universidad Eafit, Medellín, Colombia.

jabadlon@eafit.edu.co

jorge.abad@gmail.com
Septiembre 2012

Resumen

La adopción de la gestión basada en procesos por parte de la industria del software y el establecimiento de repositorios de procesos en donde los ingenieros puedan consultar y adaptar el Proceso Software según el tipo de proyecto a desarrollar, marca una invitación a la academia relacionada con los programas académicos de las carreras de Ingeniería de Sistemas, Ciencias de la Computación, Ingeniería Informática y afines, a contar con métodos y procesos depositados y administrados en un framework metodológico que le permita a los estudiantes (orientados por los docentes) construir software para las diferentes prácticas académicas, apoyándose en estándares, logrando de esta forma una comprensión y aprehensión de los procesos metodológicos, reduciendo así los tiempos de adaptación de los egresados de estos programas académicos en la industria y mejorando la calidad de los desarrollos realizados por ellos.

Palabras clave

Ingeniería de Software, academia, proyectos académicos, trabajos de pregrado, SPEM, biblioteca de métodos, biblioteca de procesos, Eclipse Process Framework, Proceso Software, CMMI, RUP.

1           Estado actual de la industria

La industria del software desde hace más de 20 años ha venido trabajando en una orientación por procesos, apoyada tanto por el estándar ISO 9000, como por modelos específicos para esta industria, como ISO/IEC 15504, ISO/IEC 12207, PSP (Personal Software Process), TSP (Team Software Process), Métrica 3, Moprosoft, CMM y posteriormente CMMi, entre muchos otros. Como consecuencia, para las organizaciones que los han adoptado de forma disciplinada y consciente les ha significado una madurez en la ejecución y gestión del Proceso Software, que les permite realizar proyectos exitosos en términos de cumplimiento de tiempo, costo y alcance, calidad y satisfacción de los clientes.

Como lo expresa CHRISSIS y otros [3] (afirmación que se ha convertido en el fundamento de CMM y posteriormente de CMMi), un buen producto o servicio depende de tres pilares: Personas, Técnicas y herramientas, y Procesos (ver Figura 1); por lo tanto, el buen resultado en la consecución de productos y servicios dependerá fuertemente de los procesos establecidos para construirlos, pues estos son la única variable de la ecuación de calidad y productividad que depende de la definición y forma de trabajo de la organización en sí misma; es decir, organizaciones de software con similares talentos humanos y herramientas, producirán bienes y servicios similares o disimiles entre sí, en función de los procesos de software definidos al interior de ellas, siendo por ende la forma de ejecución del Proceso Software el factor diferenciador y que agrega valor.

Los procesos dentro de las organizaciones de software son creados, publicados y mantenidos por áreas como gerencias de calidad, gerencias de procesos, gerencias de producción y/o PMO (Project Managment Office); y los Ingenieros de Software son capacitados en el uso de estos procesos para la producción de software. Estas capacitaciones en uso de estos Procesos Software, al igual que el tiempo en que los ingenieros son completamente productivos (o sea, su dominio de los procesos es tal que no requieren ayuda de otros compañeros, o de las áreas dueñas de los procesos) dependerá en su gran mayoría en lo habituado que este el Ingeniero a una orientación por procesos, siendo este hábito enseñado desde una compañía anterior que provenga o desde la formación universitaria recibida para los recién egresados.

Figura 1: Vértices que garantizan un buen producto o servicio. [3]       

2           La academia vs la gestión basada por procesos.

Desde hace más de 10 años las universidades en Colombia trabajan en su acreditación institucional (ver Figura 2), que consiste en la adopción de modelos de gestión para los procesos académicos, buscando la calidad en la educación superior y el cumplimiento de estándares internacionales.

Con la acreditación, el que-hacer académico queda gobernado por el ciclo de mejora PHVA, y toda la comunidad académica queda inmersa en una ejecución de actividades y procesos que son gestionados y llevados a ciclos de mejora.

Por lo tanto, profesores, alumnos, cuerpo académico y personal de soporte están guiados por la ejecución de procesos, tareas, procedimientos, actividades, manuales, que están gobernados por un sistema de calidad, administrado y mantenido por la organización educativa.

Figura 2: Evolución de la acreditación C.N.A. (Concejo Nacional de Acreditación) 1998 – 2011 [4]

Los estudiantes de programas como, Ingeniería de Sistemas, Ciencias de la Computación, Ingeniería Informática y afines, a pesar de encontrarse inmersos en un escenario gobernado por procesos (dentro de instituciones acreditadas, o que trabajan en su acreditación), y de ser instruidos en metodologías de desarrollo de software, que se encargan de presentar el Proceso Software como un cuerpo coherente y organizado de conocimiento, buenas prácticas, actividades, que conducen al ingeniero y al equipo involucrado en la producción de buen software, no logran percibir, ni adoptar este Proceso Software como fundamental para la realización de las prácticas, laboratorios, proyectos de semestre, proyectos de grado, e incluso tesis y proyectos de investigación, que impliquen algún tipo desarrollo de software.

A continuación se presentan algunas de las situaciones características que se evidencian en el entorno académico relacionado con Ingeniería de Sistemas, cuando se requiere construir software en escenarios académicos.

2.1          Un esquema desarticulado de docentes frente al Proceso Software en las prácticas académicas

En entornos de trabajo en donde los docentes se encuentran desarticulados en su forma de solicitar prácticas y desarrollos de software a los estudiantes, es decir, no existen formas estandarizadas de recibir los entregables del Proceso Software construidos por los estudiantes en las materias durante el ciclo de formación, se presentan las siguientes situaciones:

• No se trabaja de forma estandarizada,

• En los cursos donde se requiere realizar desarrollo de software o componentes, los entregables esperados son diferentes.
• Aunque el resultado (que involucre desarrollo de software) es lo más importante del proyecto a ser evaluado, el docente en muchos casos no verifica el uso de las buenas prácticas, herramientas y el proceso utilizado al momento de construirlo, ni de los distintos roles que juegan los estudiantes en un proyecto de desarrollo
• Se presentan esfuerzos aislados de diferentes docentes para inculcar buenas prácticas de desarrollo de software, pero no es un trabajo coordinado por todo el Departamento/Carrera/Equipo.
• Existen casos de profesores que enseñan sólo su especialidad, sin tener en cuenta el estado de la industria, del mercado local e internacional.

2.2          Forma de trabajo de los estudiantes frente a las prácticas académicas que impliquen construcción de software y componentes en escenarios desarticulados.

De igual forma, los estudiantes al no contar con un referente organizado que les exija una forma estructurada de producir software, presentan las siguientes características en estos escenarios académicos:

• La construcción del software (componente, sistema) se enfoca sólo en el resultado y no se emplean buenas prácticas de manera generalizada. Estas solo son empleadas por los estudiantes más curiosos. Bajo este esquema, sólo importa el resultado y carece de valor el proceso.
• Los estudiantes construyen software de la forma que creen o les dicen sus compañeros; no son guiados por un MAESTRO (un experto en producción de software).
• En la construcción de software se emplean los artefactos y prácticas que les “obligan” algunos profesores en unas materias, que después de ser aprobadas, son olvidados dichos artefactos.
• Los estudiantes aprenden a desarrollar software por “voz a voz” y no saben cuál es la mejor forma de hacerlo.
• El Proceso Software no se adhiere a su “ADN académico”, quedando sólo como un referente cognitivo para el estudiante y no como una herramienta indispensable para su ciclo formativo y desempeño profesional.

2.3          Consecuencias de un enfoque no articulado en el Proceso Software de proyectos académicos.

A continuación se enumeran algunas consecuencias de un enfoque no articulado del Proceso Software, tanto para los estudiantes, docentes e industria de IT en general:

• Los estudiantes no perciben el proceso software como un esquema formal y coherente de trabajo, de forma que no se identifican ni se adhieren al ADN cognitivo del estudiante las mejores prácticas para llevar a cabo un proyecto de software exitoso.
• Ausencia de uniformidad en los entregables producidos tanto en la documentación funcional como en la técnica a lo largo de todo el ciclo formativo.
• Carencia de documentación de soporte al ciclo de vida en los proyectos académicos de software y poca valoración de la misma durante el ciclo formativo y el ejercicio profesional.
• Para las materias diferentes a Ingeniería de Software, no hay un esquema de control en el cual se asegure que se están adoptando las mejores prácticas de la industria en la producción de software.
• La evaluación de los trabajos académicos se concentra fundamentalmente en los resultados (producto de software), sin considerar el proceso realizado y los roles involucrados, dejando de lado la posibilidad de incorporar esquemas de evaluación que consideren componentes del producto y del proceso: manejo de versiones y repositorio, documentación, patrones, pruebas unitarias, pruebas funcionales, entre otros.
• Falta de uniformidad de criterios para construir, gestionar, y evaluar proyectos de software en las asignaturas que los incluyen.
• Los frameworks metodológicos son conocidos por los estudiantes como una referencia etérea, mas no son concebidos como una herramienta clave para el desempeño y éxito profesional.
• En consecuencia, es escasa la adopción de las mejores prácticas de la industria de software por parte de los alumnos egresados debido a la baja adherencia y uso de las mismas durante el ciclo formativo.
• En la industria de software se incurre en largos periodos de entrenamiento de los nuevos profesionales debido a su desconocimiento de metodologías, procesos, buenas prácticas de desarrollo y construcción de software, con los reconocidos altos costos que esto conlleva y exagerados tiempos para que sean productivos.
• En muchos casos, los desarrollos realizados por los recién egresados están viciados por errores metodológicos que influencian negativamente la iniciativa.
• Los ciclos de certificación en modelos de procesos y de referencia tipo ISO 9000, CMMi, PSP, TSP, son más largos debido a la baja adherencia del Proceso Software en el futuro profesional.

3           Una propuesta de un Framework Metodológico del Proceso Software en la Academia.

Bajo este escenario, en el cual existe una descontextualización y desarticulación general del Proceso Software tanto de forma semestral como intersemestral (a excepción de las materias y cursos de Ingeniería de Software, que su foco es el Proceso mismo), se evidencia claramente que uno de los pilares de la Ingeniería de Sistemas / Ciencias de la Computación / Ingeniería Informática, el cual es la Ingeniería de Software se encuentra en un panorama adverso de aprendizaje por parte del futuro profesional.

Desde la experiencia docente se observa, que si los conceptos aprendidos no son empleados de manera continua a lo largo del ciclo formativo tienden a caer en un olvido para el estudiante y a perder prioridad en su aplicabilidad para la resolución de los distintos retos a los cuales se enfrenta. Por tanto, se observa la necesidad de contar con una Biblioteca de Métodos o un Framework Metodológico que se constituya en la base para construir software de manera transversal y horizontal en el programa académico, convirtiéndose en parte del ADN cognitivo del futuro profesional de TI, debido a su continua utilización.

Esta Biblioteca de Métodos deberá contar, con:

·         Prácticas de desarrollo para construir componentes simples.

·         Metodologías para construir sistemas de información simples y complejos.

·         Procesos, actividades, tareas, roles y entregables que sean reutilizables a lo ancho y largo de la biblioteca.

·         Ejemplos de aplicabilidad del framework, de forma que tanto los profesores y estudiantes manejen la misma expectativa sobre lo que se construirá y estos se constituyan en ejemplos, referentes y ayudas para construir los diferentes componentes de software con sus distintos alcances a considerar.

·         Repositorio de mejores prácticas, artículos, guías, plantillas, formatos para guiar a los alumnos en los diferentes objetivos que se quieren cumplir con los diferentes tipos de proyectos, tareas y prácticas asignadas a lo largo de todo el ciclo profesional.

Figura 3: Terminología clave definida en la especificación del SPEM 2.0, mapeado Contenido del Método versus Proceso. [7]         

Esta biblioteca se constituirá en el repositorio de conocimiento para construir software a lo largo del pregrado y por ende, requerirá de estrategias de gestión que logren una adecuada utilización. A continuación se enumeran estas estrategias:

·         Mantener el framework vigente, adicionando, modificando o suprimiendo características innecesarias. Este mantenimiento es de revestida importancia, debido a la velocidad y variabilidad de estándares y tendencias en el ejercicio de la construcción de software.

·         Contar con Administradores del mismo, que se encarguen de su adecuada divulgación, capacitación y uso. Los Administradores, que corresponden a roles ejecutados por los docentes, deberán velar por la gobernabilidad y continuidad, y estar acompañados por estudiantes que se encarguen de realizar tareas de mantenimiento sobre el mismo, basados en cambios de tendencias, y observaciones de la comunidad de usuarios y administradores.

·         Usuarios (estudiantes) que se encarguen de emplear el framework y de realizar observaciones y sugerir ajustes al mismo.

Figura 4: Uso conceptual de framework SPEM 2.0, [7]

Esta estrategia de gobierno del Framework Metodológico permitiría la realización permanente del ciclo PHVA sobre el repositorio, de forma que se logre una constante mejora y empleo del mismo.

Se sugiere que la construcción de este Framework Metodológico sea apoyada por herramientas que permitan su fácil mantenibilidad y cumplimiento con estándares de especificación de procesos de Ingeniería de Software, como SPEM 2.0 (mantenido por la OMG). De igual forma se sugiere el uso del Eclipse Process Framework como herramienta de construcción y administración de los métodos y procesos construidos.

4           Beneficios esperados del framework metodológico.

A continuación se enumeran los beneficios esperados de la construcción y uso de un framework metodológico por parte de los docentes de Ingeniería de Sistemas, el cual se convertiría así en el hilo conductor para la realización de prácticas, componentes, sistemas de información, proyectos de grado, trabajos del semestre, proyectos de investigación y tesis de maestría al interior de la academia, que involucren producción de software:

• Una biblioteca de procesos y métodos que permita a los docentes y alumnos contar con un referente unificado para construcción de software de diferentes alcances dentro de la academia.
• Lograr una absorción del Proceso Software por parte de los estudiantes.
• Un proceso “adherido” en “ADN cognitivo” por el uso coherente y continuado por parte de los profesores, tanto a lo transversal como horizontal del pregrado.
• Buenas prácticas de desarrollo de software empleadas por el estudiante durante todas las prácticas de la carrera.
• Una documentación uniforme generada, tanto horizontal como verticalmente en la carrera.
• Una industria con menores tiempos y costos de capacitación y de certificación en estándares debido a la formación en procesos y buenas prácticas de los egresados.
• Un sector software más fuerte y con menos ciclos de certificación en estándares de la industria.

5           Referencias

[1]    AHERN, Dennis M., CLOUSE, Aaron and RICHARD TURNER, CMMI Distilled: A Practical Introduction to Integrated Process Improvement, Addison Wesley, 2003

[2]    CENTRO NACIONAL DE TECNOLOGÍAS DE INFORMACIÓN. Metodología de la red nacional de integración y desarrollo de software libre (MeRinde): Guía detallada.

[3]    CHRISSIS, Mary Beth, KONRAD, Mike and SHRUM, Sandy; (2007). CMMI: Guidelines for Process Integration and Product Improvement. Second Edition. Pearson Education, Inc., Boston, MA, USA, 676 p.

[4]    CONCEJO NACIONAL DE ACREDITACION (C. N. A.). Información estadística sobre acreditación de alta calidad. [en línea]. (Citada: 9 de Septiembre. 2012) <http://www.cna.gov.co/1741/articles-188924_recurso_1.pdf>

[5]    DE LA VILLA, Manuel, RUIZ, Mercedes, RAMOS, Isabel. Modelos de Evaluación y Mejora de Procesos: Análisis . (Citada: 9 de Septiemb de 2012)

[6]    ECLIPSE. Eclipse Process Framework - Getting Started. [en línea] (Citada: 17 de Junio de 2012). http://www.eclipse.org/epf/general/getting_started.php

[7]    ECLIPSE. Eclipse Process Framwork [en línea]. (Citada: 17 de Junio de 2012) <http://www.eclipse.org/epf/>

[8]    ECLIPSE. Introduction to OpenUP (Open Unified Process) [en línea]. (Citada: 16 de Junio. 2012) <http://www.eclipse.org/epf/general/OpenUP.pdf>

[9]    ÉCOLE POLYTECHNIQUE DE MONTRÉAL. Unified Process for Education (UPEDU) [en línea]. (Citada: 16 de Junio. 2012) <http://www.upedu.org/>

[10]FORD, Gary and GIBBS,Normanl, Mature Profession of Software Engineering, SEI, 1996

[11]Guide to the Software Engineering Body of Knowledge (SWEBOK) (Citada: 16 de Junio. 2012)

[12]HAUMER, Peter. Eclipse Process Framework Composer. Part 1: Key Concepts. 2007. [en línea] (Citada: 17 de Junio de 2012). <http://www.eclipse.org/epf/general/EPFComposerOverviewPart1.pdf>

[13]IBM. Rational Process Library: The industry’s most robust collection of best practices guidance [en línea]. (Citada: 16 de Junio. 2012) <http://www–01.ibm.com/software/awdtools/rmc/library/>

[14]OBJECT MANAGEMENT GROUP (OMG). Software & Systems Process Engineering Metamodel Specification (SPEM) Version 2.0. . [en línea]. (Citada: 17 de Junio de 2012) <http://www.omg.org/spec/SPEM/2.0/PDF>

[15]PALACIO, Juan. Sinopsis de los modelos SW-CMM y CMMI. 2006. [en línea] (Citada: 9 de Septiemb de 2012) <http://www.navegapolis.net/files/articulos/sinopsis_cmm.pdf>.

[16]RUIZ, Francisco y VERDUGO, Javier. Guía de Uso de SPEM 2 con EPF Composer Versión 3.0. [en línea]. (Citada: 17 de Junio de 2012) < http://alarcos.esi.uclm.es/ipsw/doc/guia-spem2&epf_v30.pdf>.

[17]SOFTWARE ENGINEERING INSTITUTE. CMMI ® for SCAMPI Class A Appraisal Results. 2011 End-Year Update. [Informe]. - Pittsburgh : [s.n.], 2012.

[18]SOFTWARE ENGINEERING INSTITUTE. CMMI ® for SCAMPI Class A Appraisal Results. 2011 End-Year Update. Pittsburgh,PA : s.n., 2012.

[19]SOFTWARE ENGINEERING INSTITUTE. CMMI for development, version 1.3 [en línea]. (Citada: 16 de Junio. 2012) <http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm>