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
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.
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.
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>
|
