Software Engineering to Professionalize Software Development

Raccis, 1(1), 6-14, 2011.
Revista Antioqueña de las
Ciencias Computacionales y la Ingeniería de Software
ISSN: 2248-7441
www.fundacioniai.org/raccis/index.htm
[email protected]
Software Engineering to Professionalize Software Development
Ingeniería de Software para Profesionalizar el Desarrollo de Software
Juan Miguel Alonso1, Fernando García2
1
2
Universidad Carlos III. Madrid, España. Jma(AT)ia.uc3m
Universidad Carlos III. Madrid, España. Fgcar(AT)ing.uc3m.es
INFORMACIÓN DEL ARTÍCULO
Tipo de artículo
Reflexión
Historia del artículo
Recibido: 13-06-2011
Correcciones: 22-09-2011
Aceptado: 25-09-2011
Categories and Subject Descriptors
K.3.2 [Computers and Education]:
Computer and Information Science
Education – Curriculum.
General Terms
Computer
Science,
Engineering.
Software
ABSTRACT
The role, increasingly important, that plays the software in the systems with widespread
effects presents new challenges for the formation of Software Engineers. Not only
because social dependence software is increasing, but also because the character of
software development is also changing and with it the demands for software developers
certified. In this paper are propose some challenges and aspirations that guide the
learning processes Software Engineering and help to identify the need to train
professionals in software development.
RESUMEN
El rol, cada vez más importante, que juega el software en los sistemas de amplia
repercusión presenta nuevos retos para la formación de los Ingenieros de Software. No
sólo porque la dependencia social del software es cada vez mayor, sino porque el
carácter del desarrollo de software también está cambiando y con él las demandas por
desarrolladores de software certificados. En este trabajo se proponen algunos desafíos y
aspiraciones que orientan los procesos formativos de la Ingeniería de Software y que
ayudan a identificar la necesidad de formar profesionales en desarrollo de software.
Keywords
Software Engineering, Training
Processes, Software Development,
Professional Certification.
Palabras clave
Ingeniería de Software, Procesos
Formativos, Desarrollo de Software,
Certificación Profesional.
1. INTRODUCCIÓN
Al entrar en el nuevo milenio los productos software se
han convertido en partes esenciales de las actividades
cotidianas y de los negocios en la economía global y de la
sociedad en general. La calidad de esos productos
depende de la capacidad de los desarrolladores de
software, quienes deben ser competentes y mantenerse
actualizados en su conocimiento. Pero, hasta el momento,
a los desarrolladores de software se les forma de acuerdo
con los procesos tradicionales. Desafortunadamente,
estos procesos formativos no han generado la cantidad ni
la calidad de desarrolladores necesarios para satisfacer la
creciente demanda. Además, la formación tradicional no
provee la ayuda necesaria para que los estudiantes
mantengan sus conocimientos actualizados. En el área del
software, por ejemplo, todavía no se acepta al desarrollo
de software como una profesión, por lo que la formación
para ingenieros de software se confunde con la de formar
a “programadores” y a otros no-ingenieros.
© 2011 IAI. All rights reserved.
En las próximas décadas, los procesos formativos para los
desarrolladores de software deberán formar a los
estudiantes de manera diferencial y de acuerdo con las
diversas funciones que desempeñan en la gestión de los
Sistemas de Información; se deberá intervenir
agresivamente los contenidos de los programas de
ingeniería relacionados; ayudar a los estudiantes a
mantenerse actualizados frente a los rápidos cambios y
establecer la acreditación continua, de forma que reflejen
con exactitud las capacidades de los profesionales.
Aunque los ejemplos específicos en este trabajo se
describen en términos de los Estados Unidos, las
implicaciones, en general, son globales. Desde ahora se
deben iniciar procesos de “modernización” a los
programas de ingeniería que tengan alguna relación con
el desarrollo de productos software. Además, es necesario
tomar conciencia de que el desarrollo de software, dadas
6
las implicaciones de sus productos, es una profesión,
como la Medicina, la Ingeniería Civil o la Ingeniería
Eléctrica y, por tanto, requiere procesos formativos en
Ingeniería de Software.
2. ESTADO DE LA CUESTIÓN
Actualmente, los desarrolladores de software se forman
tradicionalmente, como se ha hecho durante años y
variando sólo con la reciente incorporación de la
formación Online. Sin embargo, las presiones externas y
las provenientes del carácter cambiante del software
inciden sobre las instituciones formativas, para que
implementen cambios en los contenidos de los
programas, en las metodologías formativas y en la
apreciación con la que actualmente se forma a los
desarrolladores de software.
2.1 La formación en desarrollo de software
En las últimas tres décadas, los desarrolladores de
software se han formado, en los programas de pregrado y
de posgrado en las universidades, mediante cursos de
formación profesional y de cualificación empresarial y
por iniciativa personal en la capacitación en nuevas
técnicas. Tomayko [1] identificó tres períodos en la
historia de la formación en Ingeniería de Software en los
EEUU: (1) la era de la auto-capacitación, antes de 1978,
(2) los primeros programas de posgrado, entre 1978 y
1988 y (3) la rápida proliferación de programas de
posgrado, influenciada por los esfuerzos del Software
Engineering Institute desde 1988. Este panorama no
difiere mucho de lo sucedido en otros países de América,
de Europa y de Asia.
El estudio de Knoke y Bagert [2], acerca de los programas
de posgrado en Ingeniería de Software, aunque
incompleto, identificó programas de posgrado en 77
instituciones en todo el mundo. La mayoría de estas
instituciones ofrecía un programa de maestría en alguna
área relacionada con el software, y nueve ofrecían un
doctorado con electivas en Ingeniería de Software. Los
programas de doctorado en Ingeniería de Software
también comenzaban a aparecer, por ejemplo, en el
Institute for Software Research de Carnegie Mellon
University. Estos programas se diferenciaban en el énfasis
de sus contenidos; por ejemplo, algunas maestrías
estaban relacionadas principalmente con la gestión de las
actividades del software, mientras que otras eran
principalmente técnicas. También diferían en el énfasis de
la carrera: los programas de doctorado, por su naturaleza,
preparaban a los estudiantes para la investigación y la
formación universitaria, aunque muchos optaban por
trabajar en el desarrollo industrial. Algunos de los
programas de maestría eran programas académicos que
preparaban para los programas de doctorado. Muchos de
los programas de maestría estaban diseñados para
preparar a los estudiantes en la práctica profesional, con
un alto nivel de responsabilidad técnica o de gestión y no
para el ingreso a un programa de doctorado.
Actualmente, la mayoría de las universidades ofrece
títulos de pregrado en Ciencias Computacionales e
Informática, y muchas ofrecen una amplia selección de
cursos relacionados con software. Típicamente, estos
programas les permiten a los estudiantes formarse en
áreas como el diseño y la implementación de software y
les proporcionan una base de formación común para la
“programación” básica. Desde hace más de dos décadas,
algunos miembros de la comunidad de formación en
software han abogado por programas de pregrado en
Ingeniería de Software, separados de las Ciencias
Computacionales.
Dichos
programas
pretenden
proporcionar una mejor base para profesionalizar el
“desarrollo de software”, muy diferente a lo que se logra a
través de un programa de Ciencias Computacionales
tradicional. En 1998, Tomayko [1] señalaba que, con la
introducción de programas de pregrado en Ingeniería de
Software, se entraba en una nueva era para el software,
pero esa idea todavía no se ha generalizado hasta el
momento.
Las habilidades específicas para desarrollar software se
imparten por fuera del sistema universitario, en centros
de formación y cualificación profesional, en cursos de
corta duración o por auto-capacitación. Se diferencian en
la extensión, en el costo y en el grado en que se
transfieren los conocimientos y, algunos, conducen a
certificaciones de vendedor con competencias en
productos específicos. A pesar de todas estas
oportunidades, regularmente se escucha las quejas de la
industria del software acerca de la grave carencia en el
número de desarrolladores de software profesionales
disponibles.
2.2 Tendencias en el área de desarrollo de software
La relación entre los usuarios finales y el desarrollo de
software está experimentando cambios fundamentales,
debido fundamentalmente a que los productos software
permean toda actividad humana. Algunos de estos
cambios tienen que ver con el carácter evolutivo del
software y otros tienen que ver con la creciente presión
por la necesidad de profesionalizar su desarrollo.
Evolución de los modelos de desarrollo de software. El
modelo predominante de desarrollo de software, en el
que se basa la mayoría de los programas formativos,
involucra a un equipo de desarrolladores de software en
una institución aislada, trabajando bajo un proceso y un
ciclo de vida del producto bien definidos, para producir
software para un cliente conocido y para entregarlo en un
tiempo igualmente conocido. Este modelo de desarrollo
de software, de “negocio cerrado”, cada vez más está en
contradicción con la práctica real. Algunas de esas
discrepancias son:
 Los requisitos del sistema surgen cuando los clientes
comprenden mejor tanto la tecnología como las
oportunidades en su propio entorno y cuando están
íntimamente involucrados en un desarrollo
progresivo. A menudo, esto requiere desarrollar,
paralelamente, software y reingeniería de negocios.
 Los sistemas se diseñan y despliegan bajo complejas
limitaciones económicas y legales que afectan su
diseño y que, a menudo, se distribuyen no sólo al
7
software sino a sistemas hardware/software. La
mayoría de programas formativos subestiman la
importancia de estas limitaciones adicionales.
ISO 9000 direccionan la calidad organizacional, sin
embargo, la certificación profesional en desarrollo de
software se encuentra todavía en una etapa inmadura.
 Actualmente el software, especialmente el de sistemas
de bajo nivel, se desarrolla en comunidades de
voluntarios cooperantes [3]. En el software de fuente
abierta, el código se publica libremente y los usuarios
interesados lo critican y proponen cambios. La calidad
surge de un proceso social intenso y paralelo que se
retroalimenta rápidamente y no por un proceso
cuidadosamente gestionado.
Actualmente, existe una considerable presión en todo el
mundo por profesionalizar la Ingeniería de Software. En
Estados Unidos, esta presión está tomando forma de
debate acerca de los méritos del licenciamiento
profesional para los ingenieros de software. El argumento
a favor es que, al igual que en otras disciplinas
ingenieriles, se deben establecer normas para la práctica
debido a que existe una gran demanda, por parte de
empleadores y de clientes, acerca de cómo establecer las
competencias de un desarrollador de software y la
certificación es una forma de responder a esas demandas;
además, podría mejorar la calidad de la práctica. El
argumento en contra, hasta el momento, es que las
certificaciones profesionales acarrean un compromiso
con el público de que es posible alcanzar un nivel de la
práctica en el que se proporciona cierta seguridad y
propiedades de utilidad del producto, pero ese nivel de la
práctica aún no se logra rutinariamente; además, que la
práctica certificada de la Ingeniería de Software no se ha
distinguido de otros aspectos del desarrollo de software,
y que la certificación tiene un rango estrecho de
aplicabilidad para asuntos de interés público. Un equipo
de trabajo, contratado por ACM, The Computer Society e
IEEE, está tratando de definir el “cuerpo de conocimiento”
que un ingeniero de software debe dominar [5].
Curiosamente, existe muy poco esfuerzo para distinguir
las responsabilidades ingenieriles de las tareas de
desarrollo.
 El software, a menudo, se desarrolla creando
coaliciones entre recursos existentes, que no están
bajo el control del desarrollador [4]. Estos recursos
incluyen cuentas, comunicación, control, información
y servicios que, comúnmente, están distribuidos, son
dinámicos, son autónomos y se administran de forma
independiente. Además, se pueden modificar o retirar
sin notificar a los usuarios. Este modelo de desarrollo
de “negocio abierto” es un cambio importante
respecto del habitual modelo de “negocio cerrado” y,
consecuentemente, las incertidumbres asociadas con
los recursos administrados externamente requieren
un análisis más sofisticado.
 El desarrollo de software está cada vez más desintermediado, es decir, los propios usuarios finales y
no los desarrolladores de software, son los encargados
de adaptarlo, ajustarlo, componerlo o crearlo. Estos
usuarios necesitan comprender el desarrollo de
software en sus propios términos y, particularmente,
cómo decidir la cantidad de fe que colocarán en sus
creaciones.
Para responder a esto, las instituciones de formación
deben preparar a los desarrolladores de software para
que construyan y analicen sistemas fuertemente limitados
por consideraciones no técnicas y que dependen de
recursos distribuidos independientes. Además, los
desarrolladores de software deben aprender a crear
productos lo suficientemente confiables como para ser
utilizados, reutilizados y adaptados por no profesionales.
Certificación profesional en desarrollo de software. La
importancia pública del software se incrementa cada vez
más, ya sea como un elemento esencial en los sistemas
ingenieriles o como la personificación principal de
capacidades cuyo fallo traería consecuencias importantes
para la sociedad en general o para una persona en
particular. El público quiere y merece garantías acerca de
la calidad, tanto de los sistemas con software embebido
como de los sistemas que están principalmente
embebidos en software. Es posible alcanzar directamente
la confianza en la calidad del producto a través de su
validación, o desde antes, ya sea al confiar en las personas
que producen el software o en la organización que
gestiona su producción. Muchas tecnologías –
especialmente las pruebas, el diseño, las revisiones de
código y el análisis formal– soportan la validación del
producto. El Capability Maturity Model y la certificación
Además, algunos proveedores de software certifican en
capacidades para el uso de productos específicos. La
diversidad y la especificidad de estas certificaciones son
evidentes a partir de algunos ejemplos: Certified Novell
Engineer
or
Administrator,
IBM’s
Application
Development Certifications in XML and VisualAge,
Microsoft Certified Systems Engineer or Database
Administrator, Oracle Certified Professional tracks, Sun
Certified Programmer or Developer for Java, Sun Certified
System or Network Administrator y the multivendor
Certified Internet Professional. A menudo, estas
certificaciones son específicas para una determinada
versión de la aplicación, haciendo que sean aún más
restringidas. Las certificaciones son menos restringidas
que las licencias profesionales, pero más amplias que las
certificaciones en productos, sin embargo, no son
ampliamente publicitadas y reconocidas.
2.3 Tendencias en las instituciones formativas
Los incentivos para cambiar los procesos, con los cuales
se forma a los desarrolladores de software, no sólo surgen
de los cambios en la forma como se desarrolla el software,
sino también de las presiones institucionales. Desde hace
tiempo, las universidades conviven con la tensión entre
un sistema de valores interno, que enfatiza en la
formación en principios duraderos, y las demandas de los
empleadores, que centran la formación en el uso de las
tecnologías actuales. Las diferentes escuelas buscan el
equilibrio en diferentes lugares, con el acuerdo general de
8
que ninguno de los extremos es el adecuado. Sin embargo,
algunos desarrollos recientes intensifican esa tensión: en
primer lugar, la misma comunidad formativa se está
movilizando cada vez más desde los cursos teóricos a los
proyectos en equipo, la resolución de problemas, la
participación directa en desarrollos reales y a otros
formatos que los estudiantes necesitan para ejercitar las
ideas que discuten. En segundo lugar, el déficit de
desarrolladores profesionales de software es tan grave
que, a menudo, los propios estudiantes se enfrentan con
la posibilidad de elegir entre un trabajo de
“programación”, bien pago, o completar sus estudios; esto
es particularmente grave en los programas de doctorado,
pero también es un problema en los pregrados. A las
facultades les puede resultar difícil convencer a los
estudiantes de que la elección del trabajo de
“programador” les limita las opciones de una carrera
profesional como “desarrollador”. En tercer lugar, la
estructura institucional de las universidades es cada vez
más cuestionada por las escuelas con ánimo de lucro –que
ahora se llaman “universidades” o escuelas de formación
profesional– que enfatizan en habilidades de utilidad
inmediata, y por críticos externos que argumentan a favor
de una mayor responsabilidad y eficiencia y por el
entrenamiento y la formación on-line.
Esta discusión establece las bases para identificar los
desafíos para la comunidad de formación en Ingeniería de
Software y para seleccionar algunas aspiraciones
específicas como metas de progreso.
3. DESAFÍOS Y AMBICIONES DEL DESARROLLO
PROFESIONAL DE SOFTWARE
La ingeniería implica crear soluciones prácticas costoefectivas para problemas mediante la aplicación de
conocimientos científicos; es crear cosas para colocarlas
al servicio de la humanidad [6]. Preferiblemente y cuando
están disponibles, los ingenieros aplican conocimientos
científicos y matemáticos y, en otras ocasiones, aplican
conocimientos sistemáticos; además, trabajan bajo
limitaciones, tanto de tiempo como de conocimiento. Son
responsables de la conciliación entre restricciones
conflictivas, especialmente las limitaciones de costos, y
toman decisiones deliberadas acerca de diseños
alternativos, sea por razones técnicas o no técnicas [7].
Sus juicios se basan en el conocimiento profundo de la
disciplina que ejercen, y asumen la responsabilidad
personal por la seguridad y la calidad de los sistemas que
diseñan. Este punto de vista acerca de la ingeniería difiere
del de Maibaum [8], quien sugiere un largo proceso lineal
de creación, con refinamiento iterativo, pero sin revisión.
El punto de vista de Maibaum carece del sentido trazado
por la experiencia disciplinar acumulada, de la
conciliación de las restricciones conflictivas, de la
necesidad de generar alternativas candidatas en las
distintas etapas y elegir entre ellas.
En este trabajo se toma a la “Ingeniería de Software” en el
sentido de ingeniería y se centra principalmente en la
formación de estos ingenieros, que esperan ser
preparados para realizar el diseño técnico, para tomar
decisiones y para asumir la responsabilidad por el éxito o
fracaso de sus productos. Además, se refiere a la
comunidad de personas involucradas en el desarrollo de
productos software como “desarrolladores de software”,
no como “programadores”.
3.1 Identificar los diferentes roles del desarrollo de
software y proporcionar una apropiada formación
para cada uno
El desarrollo y el soporte de software requieren muchas
habilidades que incluyen: diseño, gestión, técnicas de
programación, validación, verificación, análisis, estudios
de usuarios, documentación, integración de sistemas y de
técnicas específicas para diseñar seguridad y fiabilidad.
Mientras que los ingenieros aplican la mayor parte de
estas habilidades, no todos los que tiene alguna de ellas
son ingenieros. A pesar de que existen algunos intentos
intermitentes por identificar los roles específicos, las
diferencias siguen siendo poco claras. De hecho, gran
variedad de desarrolladores de software, muchos de ellos
sin responsabilidades ingenieriles, aspiran al título de
“Ingeniero de Software”.
Actualmente, la ambigüedad acerca de los roles en el
desarrollo de software se encuentra reflejada en los
programas formativos. Las universidades ofrecen, en
diferentes departamentos y facultades, materias
relacionadas con el desarrollo de software, pero sus
programas se diferencian, en el enfoque acerca de lo que
es software, del que tienen otras áreas en campos
respectivos. Sin embargo, rara vez tienen un sentido de
especialización relacionado con el software.
Primera Ambición: Discriminar entre los diferentes roles
en el desarrollo de software. El conocimiento disponible
acerca del desarrollo de software supera con creces lo
que una persona puede llegar a conocer. Otras áreas del
conocimiento han respondido a ese crecimiento en el
conocimiento mediante funciones especializadas. La
especialización puede ser vertical –especialista en un área
de aplicación como la computación científica–, horizontal
–especialista en seguridad de sistemas–, o por nivel de
responsabilidad –desarrollador vs ingeniero. Como en
otras áreas más maduras, estas divisiones se convierten
en una estructura reconocida del área, permitiendo tanto
la profesionalización como la especialización del personal.
Por razones históricas, algunas distinciones en el
software ya están bien establecidas, como la
administración de bases de datos y, más recientemente, el
desarrollo de sitios web. Aún no es claro si una
especialización, vertical u horizontal, sería mejor que la
otra. El progreso hacia la identificación de los
conocimientos necesarios para ejercer funciones
específicas ayudará a comprender cómo alinear las
especialidades.
Segunda Ambición: Hacer de los pregrados de formación
en desarrollo de software una valiosa inversión a largo
plazo. La principal responsabilidad de las universidades,
especialmente en los programas de pregrado, es formar
con contenidos actualizados y duraderos que los
estudiantes puedan utilizar en el tiempo. Por razones
prácticas y pedagógicas, es apropiado utilizar material
9
con ejemplos de la práctica diaria. Sin embargo, en los
cursos cuyo énfasis principal es la tecnología, la mayoría
del conocimiento se vuelve obsoleto cuando esa
tecnología está ampliamente desfasada con relación a la
vida real.
subyacentes a la formulación de problemas y a la
validación de resultados [9], lo mismo que para
incrementar su curiosidad y creatividad. Los programas
de doctorado se basan en gran medida en desarrollar
estas habilidades y talentos.
En el fondo, el diseño curricular es un problema de
asignación de recursos, con el espacio curricular –medido
por cursos, horas de estudio, trabajo independiente,
proyectos,...– como un recurso escaso. Los cursos deben
ganarse un lugar suficientemente compacto en el plan de
estudios, con contenidos duraderos para justificar el
espacio curricular que utilizan. Regularmente, las
universidades enfrentan la presión de potenciales
empleadores para sacrificar la comprensión sistemática
en pro de habilidades de utilidad inmediata. Cada
universidad debe seleccionar su propio equilibrio entre
conocimiento inmediato y de largo plazo. Por lo tanto, es
necesario resistir la tentación de ofrecer nuevos
programas de pregrado en Ingeniería y mucho menos
crear nuevos departamentos académicos. La Ingeniería de
Software aún no tiene un plan de estudios independiente
con suficiente contenido codificado y duradero en el
tiempo como para justificar un plan de estudios de
pregrado independiente. Sustancialmente, la mayor parte
de los contenidos se superponen con buenos contenidos
en Informática.
3.2 Inculcar una actitud ingenieril en los programas
formativos
Cualquier estudiante que pretenda formarse en alguna de
las áreas del desarrollo de software debe ser bueno en el
desarrollo de software. Esto requiere dominar cuestiones
como la lógica, la abstracción, el diseño y la programación
misma. Esas competencias requieren una visión
ingenieril: comprender y modelar problemas, resolver
limitantes, considerar a los usuarios, comparar
alternativas, entre otras. Se debe tratar de esta manera al
desarrollo de software, no sólo para los futuros
ingenieros de software, sino para todos los estudiantes.
Actualmente, los programas de pregrado en Informática y
en Tecnologías de la Información incluyen cursos de
desarrollo de software, y todos los estudiantes,
incluyendo a los ingenieros de software, deben formarse
siempre con un punto de vista de ingeniería en cada uno
de esos cursos.
Al adicionarles un sentido más fuerte de ingeniería a
través de la mayoría de planes de estudio, se beneficiarían
los programas de pregrado en Informática y la energía,
necesaria para administrar programas o departamentos
separados, se invertiría mejor en optimizar la disciplina y
sus cursos. Además, las asociaciones de profesionales se
deben abstener de proponer planes de estudio. La
evidencia en los últimos 30 años es que las propuestas de
contenidos creativos e innovadores provienen de
asociaciones y universidades individuales –cuyos
miembros tienen intereses diversos y conflictivos– y no
de grandes comités que integren a la industria, a la
academia y al Estado.
Tercera Ambición: Proporcionar especialización a través
de capacitación y formación de posgrado. Debido a que las
especializaciones actualmente tienen un amplio mercado,
las instituciones formativas deben estructurar estrategias
para direccionarlas. El carácter de estas oportunidades
depende del nivel de responsabilidad que el estudiante
asuma. Los futuros ingenieros deberían poder comenzar
la especialización concentrándose en el pregrado y en los
cursos electivos; pero, en el actual estado de madurez de
los procesos formativos, deben esperar a culminar su
pregrado y esperar, al menos un año de estudios de
postgrado –o el comparable en tiempo laboral– para ser
competentes en una especialidad. En el extremo opuesto,
los centros de formación profesional, las escuelas
privadas y el entrenamiento in house ofrecen capacitación
en habilidades para productos específicos.
En ingeniería, por supuesto, la preparación para
investigar es diferente de la preparación para aplicar. Un
investigador necesita más formación en principios
Regularmente, se escuchan quejas acerca de que los
planes de estudio de los pregrados en Informática no
cumplen con el objetivo de formar ingenieros. En muchos
aspectos, el problema radica en el fracaso de los cursos de
desarrollo de software para hacer frente a las
consideraciones prácticas del software real. Estos
problemas se deben abordar en los cursos para todos los
estudiantes; para mejorar, no basta con separar los cursos
de Ingeniería de Software de los demás cursos del plan
curricular. Además, estos cursos pueden mejorar el plan
de estudios para los estudiantes que se forman en el
ámbito del software, no sólo para los potenciales
ingenieros de software.
En particular, los ingenieros deben considerar numerosas
alternativas y seleccionar la apropiada para la tarea en
cuestión; necesitan diferentes grados de precisión en
diferentes situaciones, en diferentes puntos del programa
y para diferentes estructuras de datos [10], y deben
aplicar juicios para realizar análisis apropiados a la luz de
los costos y las necesidades. Boehm y Sullivan [7]
enfatizan en que la Ingeniería de Software tiene un lado
comercial y por eso las consideraciones económicas, así
como las técnicas, afectan las decisiones que se toman.
Cuarta Ambición: Integrar un punto de vista ingenieril a
los pregrados en Ciencias Computacionales y a otros planes
de estudios en Tecnologías de la Información. En la
práctica, un buen software no se desarrolla por accidente.
Este proceso requiere conocimientos de diseño que no
están relacionados con el diseño de la ingeniería
tradicional. Incluso, una mirada superficial a lo que los
ingenieros saben revela los problemas en el actual
currículo del software. Las deficiencias incluyen:
 Programación desde cero. La mayoría de cursos
preparan a los estudiantes para codificar desde cero,
10
en lugar de modificar los programas existentes o
mediante el trabajo en soluciones modelo. Por otra
parte, rara vez los estudiantes leen buenos programas.
Es como si se incitara a los estudiantes a escribir
buena prosa sin haber leído primero buena prosa.
 Programar antes de razonar. Aunque la situación está
mejorando, la codificación y la depuración todavía
parecen estar por encima de procesos cuidadosos para
especificar, analizar y construir o derivar.
 Implementar el primer diseño. A menudo, los
problemas admiten más de una solución. La mejor
solución en un entorno dado depende en gran medida
de cuestiones acerca del usuario o del uso previsto
para el sistema.
 Diseñar para el implementador. Los implementadores
suelen optar por soluciones que responden a sus
propios gustos, no a las necesidades del cliente.
 Fallar al comprender la escala del problema. Los
proyectos de curso generalmente enfatizan en la
funcionalidad y omiten los requisitos de desempeño,
especialmente requisitos de escala como el tamaño y
el rendimiento.
 Escribir ejercicios para usar y tirar. Dado que los
estudiantes descartan los proyectos tan pronto como
se gradúan, no tienen ningún incentivo para crear
software comprensible, bien documentado y de fácil
mantenimiento.
 Ignorar la fiabilidad, la seguridad, la economía y otros
requisitos del sistema. Por lo general, los proyectos de
aula se centran en conseguir resultados correctos para
entradas correctas. Ocasionalmente, requieren
comprobaciones rudimentarias para las entradas y, en
ocasiones, para medir el desempeño. Los estudiantes
realizan muy poco análisis sistemático de fiabilidad y
seguridad. Similarmente, estos proyectos direccionan
el rendimiento asintótico de los algoritmos y, a veces,
la codificación rápida, pero muchos estudiantes nunca
confrontan un requisito con la respuesta práctica en
tiempo real y es raro que encuentren problemas no
técnicos que originen la toma decisiones.
Modificando el énfasis en los cursos individuales será
posible resolver estos problemas, sin trastornos
significativos en la estructura de un programa. El
resultado podría mejorar la calidad de los cursos para
todos los estudiantes, no sólo para los de software.
 Estudiar buenos ejemplos de sistemas software. Hacer
esto correctamente requiere estudios de casos
organizados. Mientras tanto, hacer una cuidadosa guía
de lectura de un buen código y estructurar proyectos
de aula que comiencen desde un código que facilite el
logro de las competencias.
 Presentar teorías y modelos en el contexto de la
práctica. Enfatizar en ideas duraderas que vayan más
allá de un cambio importante en la tecnología. A
menudo, los estudiantes aprenden mejor trabajando
sobre ejemplos concretos; los buenos ejemplos se
pueden mezclar para aplicar reutilización.
 Exigir la consideración de al menos dos diseños
importantes. Hacer que los estudiantes elijan entre
distintas alternativas de diseño para hacer frente a las
necesidades del cliente.
 Exigir consultas a los usuarios finales. Utilizar
proyectos con clientes reales. A menos que los
usuarios finales tengan voz en la revisión del diseño,
los estudiantes no entenderán que sus necesidades y
preferencias son diferentes de las de esos clientes.
 Formar en procesos de estimación. A menudo, los
estudiantes creen que no pueden hacer ningún análisis
hasta que tengan todos los hechos concretos. Se les
debe formar en cómo hacer estimaciones rápidas de
los niveles de uso, del rendimiento, del tamaño y del
ancho de banda, y mostrarles cómo esto les puede
proporcionar una orientación temprana acerca de la
escala y el rendimiento del proyecto.
 Crear, modificar y combinar programas. Formar a los
estudiantes para trabajar con estructuras de
programas elaborados por otros, a reutilizar
componentes, que respeten las normas y a que valoren
los beneficios de una buena documentación.
 Implementar pruebas con datos erróneos. Ejecutar
casos de prueba elegidos por otros, no sólo con los
datos de demostración por parte del estudiante.
Incluir no sólo las entradas correctas sino también
entradas malintencionadas e incluso erróneas, y
hacerlo no como una tarea aislada sino como una
cuestión continua.
 Ejecutar funciones con requisitos embebidos. Los datos
erróneos no son la única fuente de exigencias del
mundo real. Es necesario ejecutar funciones que
expongan a los estudiantes a requisitos finales, al no
determinismo, a condiciones de prueba y a
restricciones no técnicas.
3.3 Mantener los procesos formativos ajustados a los
rápidos cambios
Los procesos de formación de los desarrolladores de
software deben ser proporcionales a los cambios en las
tecnologías del software y de los modelos de desarrollo.
En primer lugar, las propias instituciones de formación
deben ser capaces de adaptarse con rapidez, tanto en el
contenido de sus ofertas como en su capacidad para
explotar las nuevas tecnologías que apoyan los procesos
formativos. En segundo lugar, las instituciones deben
preparar a sus estudiantes para asumir la responsabilidad
de mejorar sus propias habilidades a lo largo de la vida
profesional.
Quinta Ambición: Desarrollar planes de estudio flexibles y
sensibles al cambio. Los principios centrales y los modelos
duraderos en el plan de estudios cambian más lentamente
que la práctica real. Sin embargo, en comparación con
11
otros campos, incluso el núcleo del plan de estudios de
desarrollo de software debe cambiar rápidamente. Por
ejemplo, la mayoría de planes de estudio no reconocen el
papel que juegan las buenas abstracciones en el diseño
para las arquitecturas software [11]. Además, la evolución
de Internet en los últimos años, desde un servicio de
correo electrónico/telnet/ftp a un sistema de distribución
de información integrado en la cultura popular, ha
introducido nuevas técnicas y modelos para el diseño y el
desarrollo:
 Desarrollo de software de código abierto.
 Sistemas de Información altamente distribuidos a gran
escala, incluyendo el almacenamiento en caché local, la
actualización automática, los servicios de empujar y
tirar, el control de eventos estilo y otras
características.
 La seguridad para transacciones entre partes que no
preestablece contraseñas o claves.
 El software independiente de la plataforma que no
interfiere con el equipo en el que se ejecuta.
 La computación realizada a través de coaliciones de
recursos independientes.
 La recopilación de información y de minería de datos
de información personal a gran escala, con los
relacionados problemas de privacidad.
El plan de estudios de hace cinco años no cubre los
conceptos necesarios para comprender estos fenómenos
y, mucho menos, para controlarlos.
Las instituciones necesitan flexibilidad y recursos para
reaccionar a estos cambios, que no deben estar
obstaculizados por fragmentaciones internas en forma de
múltiples programas o de competencias departamentales;
y externamente no deberían estar limitados por normas
que restrinjan los planes de estudio, como planes y
estándares de acreditación desarrollados en los comités
de las sociedades profesionales. Si las sociedades
profesionales van a participar, se deben establecer niveles
de calidad y realizar foros para intercambiar ejemplos de
planes de estudio, no para imponer cuestiones de
contenido.
Sexta Ambición: Aprovechar la tecnología para apoyar la
formación. Las Ciencias Computacionales y los currículos
en Tecnología de la Información han sido siempre
agresivos cuando se trata de tareas que implican
programación, y en este sentido les llevan ventaja a
muchas otras áreas. Sin embargo, es posible hacerlo
mejor si se aprovecha la tecnología para apoyar los
procesos formativos. Se podría hacer en las aulas un
mejor uso de las simulaciones y de los ejercicios de
juegos, para obtener mayor provecho de los tutoriales
que incluyen y que proporcionan toda la información
necesaria. De esta forma se beneficiarán todos los
usuarios y se podrían amortizar los costos de desarrollo a
través de una gran comunidad de usuarios.
Comúnmente, se utiliza Internet simplemente como una
manera fácil de distribuirles a los estudiantes los
materiales de un curso o para ofrecer cursos a distancia.
Aunque la mayoría de cursos a distancia son en
habilidades para el uso de aplicaciones específicas o en
lenguajes de programación, muchos se orientan a otro
tipo de formación en línea. La mayoría de las funciones en
el aula se pueden apoyar en una combinación de la web, la
distribución avanzada de lecturas o CD-ROM y salas de
chat o teleconferencias. La principal excepción a este
sistema es la interacción espontánea entre el instructor y
los estudiantes y entre los estudiantes. Cuando este déficit
tecnológico se supere –quizás a través de avances en
tecnología asistida por computador para el trabajo
cooperativo–, las universidades deberán estar preparadas
para su explotación.
Desafortunadamente, la inversión inicial en la
preparación de un soporte electrónico para un curso
puede ser grande, al igual que el costo de las revisiones
periódicas para reflejar el cambio tecnológico. Los
modelos tradicionales de administración de las facultades
no toman en cuenta estos factores.
Séptima Ambición: Proporcionar medios eficaces para que
los ingenieros de software puedan mantener sus
habilidades. El objetivo de la formación es la capacitación.
Incluso en el aula, el objetivo de formar es crear un
entorno fértil para que el estudiante se forme. Sin
embargo, después de la graduación ese estudiante se
convierte en responsable de su propia formación. Incluso
con la mejor formación de pregrado los desarrolladores
de software –especialmente los ingenieros de software–
tendrán que actualizar periódicamente sus conocimientos
y su dominio de las nuevas tecnologías, por lo que una de
las responsabilidades de la formación formal es
prepararlos en competencias para la auto-formación
permanente e independiente.
Las habilidades individuales de formación se deben
complementar con otros materiales para el estudio
independiente. Los esfuerzos ocasionales de las
sociedades profesionales, para proporcionar la
autoevaluación
y
los
materiales
de
estudio
independientes, no han logrado completamente sus
objetivos. Los cursos intensivos de los proveedores
comerciales tienden a ser muy concretos y costosos. Las
ofertas de estudios universitarios a distancia requieren
un compromiso sustancial y, normalmente, los cursos
están mal adaptados a las necesidades individuales de los
profesionales.
Es necesario ofrecer oportunidades de formación
personalizada y de acuerdo con la demanda y la
localización; proveer un soporte que valore y potencialice
el conocimiento previo de cada estudiante y poder
actualizarlos y, posteriormente, proporcionar una
secuencia de cursos que reúnan los contenidos para
lograr el objetivo de formación de acuerdo con los
requisitos previos de cada estudiante.
Cuando un estudiante llega a mediados de su carrera no
necesita estar encerrado dentro del calendario
académico. Este es el momento para la formación
individual, programada con base en competencias, donde
12
el estudiante dedica al estudio el tiempo que sea
necesario para dominar el material y los conceptos. En
esta estructuración, el estudiante no avanzará en su
proceso formativo hasta que demuestre el logro de las
competencias programadas.
3.4 Establecer la acreditación
Como se señaló anteriormente, existe al menos tres
maneras de hacer fiable al software: la validación directa
del producto, la confianza en la organización
desarrolladora y la confianza en el desarrollador. La
preocupación aquí es cómo hacer para que los
profesionales de software independientes, especialmente
los ingenieros de software, puedan garantizarles a los
clientes que son competentes.
Acreditar a los profesionales es posible –de hecho se
hace– tanto por organismos públicos como privados. Los
resultados de las tarjetas profesionales, como derechos,
restricciones, privilegios y responsabilidades, serán
diferentes para lo público y para lo privado. La
credencialización pública de los médicos generalmente se
hace a nombre del interés público. Su objetivo es
garantizar el cumplimiento, en la práctica, de estándares
mínimos tanto técnicos como éticos. Estas tarjetas se
deberían expedir tanto para profesionales –ingenieros,
médicos– como para no profesionales –conductores
públicos, electricistas, plomeros. Las credenciales
privadas se pueden tramitar por muchas razones; pero en
software, actualmente, la más común es para los grados
académicos y se expide con la intención de asegurar la
profundidad de la comprensión y la capacidad de crecer
en el campo, así como en competencias actuales; pero un
proveedor de certificación de competencias también
expide tarjetas específicas, con la intención de asegurar
una competencia en un conjunto específico de
herramientas.
Las tarjetas profesionales públicas, para individuos que
participan en la práctica de una disciplina ingenieril,
requieren:
 Un nivel alcanzable de la práctica, que asegure una
calidad consistente con la seguridad pública; es decir,
expectativas razonables intuitivas pero no la
perfección.
 Un instrumento de evaluación, que se puede aplicar
con confianza para predecir si un individuo puede
mantener un buen nivel de conocimientos en el futuro.
 En un campo en evolución tan constante como la
Ingeniería de Software, es necesario asegurar que el
profesional mantendrá sus habilidades sin importar el
nivel de mejora de la práctica.
Particularmente, estas normas no se logran al momento
de acreditar ingenieros. Para otras habilidades, más
estrechas o de más bajo nivel, se han considerado las
certificaciones
de
proveedores
asociados
con
determinadas versiones de sistemas. Las credenciales,
especialmente las públicas, se asemejan a la
especificación del software: definen compromisos acerca
de la capacidad del profesional. Es necesario asegurar que
las credenciales garanticen el reflejo de habilidades
demostradas y que direccionan asuntos relacionados con
la competencia que son de interés para los clientes,
quienes son laicos en lo que respecta a las Ciencias
Computacionales.
Octava Ambición: Establecer credenciales diferentes y
apropiadas para los distintos roles en el desarrollo de
software. Siguiendo a la Primera Ambición, se deben
establecer credenciales que coincidan con los roles en
desarrollo, o al menos con aquellos cuyo campo de acción
esté lo suficientemente maduro. Esto implica tanto la
identificación de contenidos como la clara separación de
roles. La separación de roles se debe hacer no sólo para
separar los profesionales de los no profesionales, sino
también para identificar aquellos más especializados que
los especificados en el registro profesional de ingeniería.
Es cierto que existen algunas áreas técnicas en las que
puede ser útil contar con cierto nivel de experiencia,
como en habilidades para administrar una determinada
marca de software. Otras son de más alto nivel, como
administrar bases de datos o ciertos aspectos de
seguridad. Pero se debe continuar con las actuales
actividades para establecer credenciales apropiadas para
esas habilidades. Esto puede establecer expectativas
razonables, brindar experiencia con la certificación y
proporcionar una distinción entre desarrolladores de
software con competencias auditadas y aquellos que no.
Las certificaciones pueden ser añadidas como garantía y,
dejando en claro lo que está certificado, se puede evitar la
confusión del público o de los clientes.
Novena Ambición: Establecer credenciales que reflejen
con exactitud la práctica alcanzable. La cuestión de si “la
Ingeniería de Software debería ser o no una profesión”, a
menudo se plantea en forma de “¿no es tiempo ya de
comenzar a licenciar ingenieros de software a través de
los mecanismos habituales del registro profesional de
ingeniería?”. Sin embargo, existe un problema al utilizar el
registro ingenieril como agente para incrementar los
estándares profesionales: el propósito del registro
profesional ingenieril es proteger al público,
proporcionándole alguna garantía externa de que un
ingeniero está preparado para producir sistemas fiables.
Al firmar un proyecto el ingeniero asume la
responsabilidad personal. El nivel de presentación
requerido por esta declaración no es el de que “lo mejor lo
podemos hacer ahora”, sino que lo que se hace es
“suficientemente bueno”. Por desgracia, todavía no
tenemos un nivel establecido y ampliamente aceptado, en
la práctica de la Ingeniería de Software, que cumpla con
esta norma. La propuesta de certificar ingenieros sobre la
base de las mejores prácticas, incluso las que prometen
elevar los estándares a medida que se mejora,
simplemente no tienen en cuenta este criterio primordial.
Se necesitan dos cosas antes de elevar a los ingenieros de
software a la calidad de ingenieros profesionales. En
primer lugar, se necesita un nivel ampliamente alcanzable
en la práctica que le proporcione una protección
13
razonable al público. En segundo lugar, se necesita un
instrumento de evaluación que pueda hacer predicciones
razonables de que una persona en particular pueda
practicar ese nivel. No tiene sentido buscar la segunda
hasta no lograr la primera.
4. CONCLUSIONES
La formación que se imparte actualmente para los
desarrolladores de software enfatiza en contenidos
inspirados en estructuras desactualizadas y se ofrece en
gran medida en formatos tradicionales de aula. El
entrenamiento también sigue las líneas tradicionales:
capacitar en habilidades específicas mediante cursos
cortos, sobre papel y en formatos de estudio
independientes.
En la próxima década es posible mejorar, incluyendo la
clarificación de los roles involucrados en el desarrollo de
software y la acreditación apropiada; mejorando el
tratamiento de las cuestiones de ingeniería; respondiendo
rápidamente, desde los contenidos formativos, a los
cambios en tecnología y a los conocimientos
fundamentales y mejorando el uso de las tecnologías de la
información en la formación y el entrenamiento.
Pero, lo más importe será trabajar en programas cuyo
objetivo sea potencializar la capacidad lógicainterpretativa y abstractiva de los futuros profesionales.
Esa deficiencia en la ejecución de las actividades
ingenieriles, y de casi todas las “profesiones”, no les
permite a los países un adecuado desarrollo y los
productos ofrecidos, entre ellos los de software, no
infunden credibilidad entre los usuarios [12].
Para lograr las ambiciones que se describen en este
trabajo se requiere imaginación, flexibilidad y voluntad
política. Lo más importante será proporcionarles a los
maestros interesados: apoyo, recursos y oportunidades, y
desafiarlos a establecer sus propios estándares, lo
suficientemente altos como para elevar el nivel de la
Ingeniería de Software y lograr de esta forma la
profesionalización del desarrollo de software.
5. REFERENCIAS
[1]
Tomayko, J. E. 1998. Forging a discipline: An outline
history of software engineering education. Annals of
Software Engineering, 6(1-4), 3-18.
[2] Knoke, P. & Bagert, D. 1998. Graduate Software
Engineering Program Survey Results & Evaluation. Forum
for Advancing Software engineering Education FASE
(Vancouver, Canada, September 15), 8(9).
[3] Raymond, E. S. 2010. The Cathedral and the Bazaar. Online:
http://catb.org/~esr/writings/homesteading/
[Feb.
2011].
[4] Shaw, M. 1998. Architectural Requirements for Computing
with Coalitions of Resources. First Working IFIP
Conference on Software Architecture WICSA1 (San
Antonio, TX, USA, 22-24 February).
[5] The Computer Society. 2005. Guide to the Software
Engineering Body of Knowledge SWEBOK. Online:
https://www.createspace.com/3603000 [Mar 2011].
[6] Shaw, M. 1990. Prospects for an engineering discipline of
software. IEEE Software, 7(6), 15-24.
[7] Boehm, B. W. & Sullivan, K. J. 2000. Software Economics: A
roadmap. Proceedings of the Conference on The Future of
Software Engineering ICSE '00 (New York, USA, 13-15
Nov).
[8] Maibaum, T. S. E. 2000. Mathematical Foundations of
Software Engineering: A Roadmap. Proceedings of the
Conference on the Future of Software Engineering ICSE '00
(New York, USA, 13-15 Nov).
[9] Perry, D. E.; Porter, A. A. & Votta, L. G. 2000. Empirical
Studies of Software Engineering: A Roadmap. Proceedings
of the Conference on the Future of Software Engineering
ICSE '00 (New York, USA, 13-15 Nov).
[10] Jackson, D. & Rinard, M. 2000. Software Analysis: A
roadmap. Proceedings of the Conference on the Future of
Software Engineering ICSE '00 (New York, USA, 13-15
Nov).
[11] Garlan, D. 2000. Software Architecture: A Roadmap.
Proceedings of the Conference on the Future of Software
Engineering ICSE '00 (New York, USA, 13-15 Nov).
[12] Serna, M. E. 2011. La importancia de la abstracción en la
informática. Scientia et Technica, 2(48), 122-126.
14