Aspectes humans i socials

Transcription

UCLM-ESI
PGSI
TEMA 9
ASPECTOS HUMANOS Y SOCIALES EN LOS PROYECTOS
INFORMÁTICOS
Lecturas incluidas en este documento:
1. Sobre Dirección de SI/TI.
•
B. Boehm. The Art of Expectations Management. IEEE Computer, January 2000.
2. Sobre aspectos humanos y sociales de la profesión deTI.
•
El Código de Ética y Práctica Profesional de Ingeniería del Software de la ACM / IEEE
Computer Society. Novática, nº 140.
•
P. Morrogh. Las TI y la profesionalidad: una visión desde dentro. Novática, nº 152.
•
P. Denning. ¿Quienes somos?. Novática, nº 152.
•
E. del Peso y R. Fernández. Legislación sobre Tecnologías de la Información y las
Comunicaciones: material de consulta. Novática, nº 139.
•
P. Denning. El Futuro de la Profesión de TI. Novática, nº 147.
•
P. Denning & R. Dunham. The Core of the Thrid-Wave Professional. Communications of
the ACM. November 2001/Vol.44,No.11.
•
G. Pour, M.L. Griss y M. Lutz. The Push to Make Software Engineering Respectable . IEEE
Computer, May 2000.
Otras fuentes de información:
•
Molina, M.A. (2000): Gestión de Recursos Humanos en Proyectos Informáticos. Trabajo de
la asignatura PGSI. UCLM-ESI.
•
IEEE Computer (special issue may-2000): Software Engineering- A Maturing Profession ?.
•
Novática (Julio-agosto 2001): Presente y futuro de la profesión informática.
•
Sección de ëtica y profesión de la web de ATI (http://www.ati.es/DOCS/index.html)
9 – Aspectos Humanos y Sociales en los Proyectos Informáticos
1
SO FTWARE MANAGE M E NT
WHAT’S THE PROBLEM?
The Art of
Expectations
Management
(Dedicated to the memory of Tom Bauer)
Barry Boehm, University of Southern California
O
ne of the most valuable skills
a software professional can
develop, expectations management is something surprisingly
few people know or practice.
I’ve witnessed more than 100 stakeholder software requirements negotiations in which inflated expectations
about the simplicity of the problem or
ease of providing a solution have caused
the most difficulty. Expectations management holds the key to providing winwin solutions to these situations.
When I ran TRW’s office of Software
Cost Estimation, my greatest asset was
Tom Bauer. Tom programmed and operated TRW’s version of the Constructive
Cost Model (Cocomo), which the company used on all its projects and proposals. He had been a project and department manager, and had gone back to his
first love, programming, after a heart
attack. He had a lot of experience and
wisdom, and a smile for everyone.
One day I went to Tom and said, “We
need to add a new computer security cost
driver to Cocomo for this new proposal.
It looks like a straightforward addition
to our algorithm, and they need it in a
week. Can you fit it in?”
Tom said, “Well, let’s see. Besides the
change in the algorithm, we’ll need to
change our data structures, our file formats, our input forms and user interfaces, our output formats, and our help
and error messages. Besides that, there’s
regression testing, the changes to the
122
Computer
users’ manual and model definition manual, and the Basis of Estimate feature I’m
working on for Pricing. That looks more
like six weeks to me.
“In the short term, though, if there’s
one of the other cost drivers they’re not
In my experience, three main culprits
cause expectations problems in software
project development. First, developers
often show a desire to please that’s taken
to the point of avoiding any confrontation. This behavior leads to many situations in which people will promise more
than they can confidently deliver.
Second, in their desire to sell, developers sometimes become overenthusiastic
about how well their methods, tools, or
packaged products will solve clients’
problems. Rosy sales literature about a
product or unscalable demos of how well
it works on a sample problem can be just
as misleading as optimistic assumptions.
Third, developers and clients have such
divergent viewpoints they can legitimately
be called “The Two Cultures.” In his classic book with that title (C.P. Snow, The
Two Cultures and the Scientific Revolution, Cambridge University Press, New
York, 1959), C.P. Snow explains that science and technology policymaking is par-
Clear communication,
careful estimation, and
precise planning can help
you shape and meet
realistic expectations.
using, I can give them a special version
of the program with that slot replaced by
computer security in a couple of days.
How’s that for an interim solution?”
This proposal wasn’t what I expected,
but it looked reasonable, so I went along
with it. Tom delivered the quick fix on
schedule, and three weeks later Tom
pleasantly surprised me by delivering the
full new version in half the promised time.
But suppose Tom had initially said, “Sure,
no problem,” to my request for a one-week
completion, and proceeded to deliver the
solution in three weeks. This would have
made me distinctly unhappy with Tom, and
the new-proposal people would have been
distinctly unhappy with me.
Instead, Tom had successfully managed
my expectations, and had provided an
acceptable short-term fix while doing so.
ticularly difficult because it requires the
combined expertise of scientists and
politicians, two cultures with little understanding of each other. Software developers and their clients in various
industries have similar problems. For
example, neither community has a good
feel for the capabilities, hot-buttons, or
difficulties of the other.
HOW DO WE SOLVE IT?
The key strategies for uniting the two
cultures and managing client expectations involve clear communication and
solid planning.
Speaking clearly
To defuse potentially problematic situations, you must first clarify what the
customer really wants and why. In the
example I gave, we didn’t really want a
fully packaged new model in one week;
we wanted quick access to a model,
including the computer security cost driver, followed by a fully packaged new
model sometime later. Tom Bauer clarified this distinction when he counterproposed a more achievable approach to
meeting our requirements.
Next, you must work out the details
and explain them. Tom Bauer’s six-week
estimate was clearly more realistic than
the one-week estimate, once he articulated a more detailed set of necessary
tasks. Customers usually focus on the visible-applications tip of the software iceberg, and are generally unaware of how
much additional, essential software lies
underneath.
Clear customer communication depends on two factors. First, you must
choose the most suitable communications media: If a picture can be worth a
thousand words, a prototype can be
worth a thousand pictures.
Second, you must carefully define communications content. Does “interoperable” mean just CORBA-compatible or
full plug-and-play guarantees? When you
say “advanced information hiding techniques,” will your customer hear “module descriptions confined to essential
capabilities and not implementation
details?” Or will they get the wrong idea
and think that you’re not going to let
them know what their system is doing?
Simplifier and complicator lists can
help developers gauge how much effort
the client must expend to complete a
given task—and vice versa. For example,
we put out a series of 15 to 20 digital
library applications annually, built by
teams of computer scientists for groups
of librarians. The two-cultures problem
reared its ugly head when we saw that
one group didn’t know what was easy or
hard for the other group to do. By having the groups become familiar with
domain-specific lists of things to facilitate
or complicate the application, we were
able to reduce the first-review failure rate
for these projects from roughly 25 percent to roughly 5 percent. In a multimedia archive application, for example,
using standard query languages, search
engines, and media formats made appli-
Additional Reading
Several books have helped me find customer-information-gathering techniques
that can be combined with expectations-management prototypes, scenarios,
consensus-building questions, and brainstorming.
Naomi Karten, Managing Expectations, Dorset House, New York, 1994.
This book has numerous suggestions and examples on establishing clear communication, such as avoiding conflicting messages (including body-language
messages), avoiding or carefully explaining jargon, establishing communication
media preferences, and addressing perceptions as well as facts.
Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Quality
Before Design, Dorset House, New York, 1989.
The chapters on “Preferences” and “Expectations” in this book provide further insights and techniques for prioritizing requirements and limiting expectations.
Roger Fisher and William Ury, Getting to Yes, Houghton Mifflin, Boston,
1981.
Part of the Harvard Negotiation Project, this book presents principled negotiation techniques.
cations much easier for the development
teams; while trying to achieve naturallanguage processing, automated metadata determination, or simultaneously
achieving rapid access and high-fidelity
media presentation made applications
much more difficult. (Barry Boehm,
Marwan Abi-Andoun, Dan Port, Julie
Kwan, Anne Lynch, “Requirements Engineering, Expectations Management, and
the Two Cultures,” Proc. 1999 Int’l Conf.
Requirements Engineering, IEEE CS Press,
Los Alamitos, Calif., June 1999.)
Planning for success
Several planning tools can help you
manage expectations and negotiate realistic requirements and deadlines. Software
risk assessments and high-risk item identification techniques such as prototyping,
benchmarking, and reference checking
can highlight high-risk expectations, and
can provide techniques for reducing those
expectations, thereby yielding an acceptable but lower risk solution. One large
TRW project that I worked on had a
requirement for a one-second maximum
response time, based on expectations that
a subsecond response time would vastly
improve productivity. The initial archi-
tecture required to achieve this performance would have cost $100 million to
develop and had several high-risk elements. Faced with this situation, TRW
and the customer developed and implemented a prototype, which indicated that
users found a response time of four seconds was about as good as one-second 90
percent of the time. We revised the project
to develop a much lower risk system with
a four-second response time, at a cost of
$30 million. Had we and they implemented the prototype two years earlier, it
would have resulted in revised expectations and avoided two years’ work in
specifying an overly ambitious solution.
Use calibrated models to calibrate
expectations. Another two-cultures problem is that customers and users have little feel for the difficulty of developing a
given quantity of software within budget
and on schedule. This leads to unrealistic
expectations by customers that can be
reinforced by developers’ desire-to-please
or desire-to-sell tendencies, leading to frequent budget and schedule overruns.
Well-calibrated software cost and schedule estimation models have helped many
customers and users recalibrate their
expectations and produce realistic goals
January 2000
123
Software Management
for their projects. Calibrated performance
and reliability models can perform similar functions.
Accept only one independent variable.
One clear message from software cost
and schedule models is that larger
amounts of developed software require
larger amounts of budget and schedule.
Microsoft Rising
... and other tales
of Silicon Valley
by Ted G. Lewis
This is the story of Microsoft® and how it
rose to become the first monopoly of the
Information Age. It is assembled from Ted
Lewis’s columns published in Computer,
Internet Computing, and Scientific American. Microsoft Rising is a tale of greed,
emotion, and marketing hype in one of
the fastest-growing industries of the
world. It is an eyewitness account of the
changing computer industry and the
story of Silicon Valley and how it works.
This book reports the author’s personal history through the early 1990s to the end of
the decade. These stories often try to predict or explain the chaos of Silicon Valley.
It analyzes the industry and shows how
hi-tech industry is constantly changing in
turmoil and upheaval. The book does not
promise any answers, but rather concludes this short journey into the recent
past with a number of provoking ideas
about the future of hi-tech.
350 pages 6" x 9" Softcover
0-7695-0200-8
Catalog # BP00200
$24.95 Members / $29.95 List
Order Today!
Online Catalog
http://computer.org
In the U.S. & Canada call
+1 800.CS.BOOKS
124
Computer
Express your needs
as negotiable
‘win conditions’
rather than
non-negotiable
‘requirements.’
Yet many software developers accept
both “fixed amount of software” and
“fixed cost or schedule” as conditions to
be simultaneously satisfied, without wellvalidated analyses to demonstrate that
this approach is indeed feasible. If it’s not,
it’s better to tell your customers that they
can expect either a “fixed amount of software” or a “fixed cost or schedule,” but
not both. Called “cost (or schedule) as
independent variable” (CAIV or SAIV),
this last option has customers prioritize
their requirements. Developers then
implement a core set of highest-priority
requirements, and continue adding lowerpriority features so long as the budget or
schedule lasts. Similar strategies can be
developed for other incompatible combinations of independent variables.
Techniques for win-win requirements
negotiation can produce advantages for
expectations management and project
outcomes. These techniques can help you
• express your needs as negotiable
“win conditions” rather than nonnegotiable “requirements,” which
creates a more flexible climate for
adjusting expectations;
• assimilate other stakeholders’ win
conditions to provide a greater
understanding of how their constraints may affect your level of
achievable results and thus your
expectations;
• sense that the other stakeholders are
looking out for your win conditions, which often increases your
willingness to help accommodate
their win conditions by adjusting
your expectations; and
• collaborate to understand each
other’s win conditions.
Using these techniques, you can help
bridge the two-cultures gap and increase
stakeholders’ ability to invent new winwin options for mutual gain.
ith the new millennium upon us,
I hope all of us learn how better
to manage expectations and seek
win-win solutions.The alternative—winlose situations—generally devolve into
lose-lose situations, ensuring worldwide
frustration and chaos. ✸
W
COMING AWAY A WINNER
When applied to software requirements
determination, the win-win approach
involves all of a project’s key stakeholders in the negotiation of a mutually satisfactory set of requirements (B.W. Boehm
et al., “Using the WinWin Spiral Model:
A Case Study,” Computer, July 1998, pp.
33-44). It often involves concurrent engineering or joint application development
by an integrated product team of stakeholders, as well as principled negotiation
techniques. Reflexively, good expectations
management facilitates win-win solutions.
Tom Bauer’s three-week delivery was a
win if you were expecting six weeks; it
would have been a loser if you were
expecting delivery in one week.
Barry Boehm is director of the USC
Center for Software Engineering. He
developed the Constructive Cost Model
(Cocomo), the software process Spiral
Model, and the Theory W (win-win)
approach to software management and
requirements determination. Contact
him at [email protected].
Editor: Barry Boehm, Computer Science
Department, University of Southern California,
Los Angeles, CA 90089; boehm@sunset.
usc.edu
Novática 140: Código de Etica de Ing. de SW de ACM/IEEE
Novática es la revista de ATI (Asociación de Técnicos de Informática)
Nota importante: Se permite la reproducción y difusión de este artículo por cualquier medio, excepto si está marcado con © o
Copyright, debiéndose en todo caso citar su procedencia
Important notice: This article can be reproduced and disseminated via any medium except if marked with © or Copyright. Full mention
of the source is mandatory
Novática 140 (Julio-Agosto 1999)
Sección: /DOCS/
El Código de Ética y Práctica Profesional de Ingeniería del Software de la ACM /
IEEE Computer Society
Introducción y Traducción: Javier Dolado
Facultad de Informática de San Sebastián
Universidad del País Vasco - Euskal Herriko Unibersitatea
Socio de ATI
<[email protected]>
●
Introducción
●
Bibliografía
●
Código
❍
Préambulo; Principio 1: Sociedad; Principio 2: Cliente y empresario; Principio 3: Producto; Principio 4:
Juicio; Principio 5: Gestión; Principio 6: Profesión; Principio 7: Compañeros; Principio 8: Persona
Introducción
A continuación se presenta la traducción del Código de Ética y Práctica Profesional de Ingeniería del Software en su versión
5.2 (http://www.acm.org/serving/se/code.htm), tal como la ha recomendado el grupo de trabajo conjunto de la IEEE
Computer Society/ACM sobre ética en ingeniería del software y prácticas profesionales, dirigido por Donald Gotterbarn.
Esta versión ha sido aprobada por la ACM (Association for Computing Machinery) y por la IEEE-CS (IEEE Computer
Society) como el estándar para la enseñanza y la práctica de la ingeniería del software.
Conviene mencionar que este código se ha propuesto tras varias versiones y después de revisar códigos de otras sociedades,
que se han tenido en cuenta las opiniones de las encuestas aparecidas en conocidas revistas de estas sociedades y que se ha
seguido el proceso de revisión formal del IEEE. La ACM aprobó el código en noviembre de 1998 y la IEEE Computer
Society, en diciembre del mismo año.
Los códigos de ética tienen una función esencial para caracterizar una profesión, y para que una disciplina adquiera el
carácter de profesión debe poseer un código de conducta.
Se pueden resumir las principales funciones de los códigos de ética en los siguientes apartados [Bowyer, 1996]:
1) simbolizar una profesión;
2) proteger los intereses del grupo;
3) inspirar buena conducta;
4) educar a los miembros de tal profesión;
5) disciplinar a sus afiliados;
6) fomentar las relaciones externas;
7) enumerar los principios morales básicos;
8) expresar los ideales a los que se debe aspirar;
9) mostrar reglas básicas de compor-tamiento;
10) ofrecer guías de comportamiento;
11) enumerar derechos y responsabilidades.
Los códigos de conducta van más allá de la pura normativa legal, puesto que ayudan a guiar el comportamiento en infinidad
de situaciones para las que no existe ninguna referencia legal.
http://www.ati.es/novatica/1999/140/docs140.html (1 de 7) [10/05/2002 14:07:06]
En el caso de la disciplina de "ingeniería del software", la existencia de un código de ética específico posee cada vez más
importancia, dada la relevancia que las actividades relacionadas con el software tienen en nuestra vida diaria. Puesto que en
estos momentos se está hablando sobre la creación de los colegios de ingenieros en infor-mática en España, es pertinente
considerar los códigos de conducta que sean aplicables a tales colegios profesionales. Gran parte de las tareas de los
ingenieros en informática están relacionadas con el software, por lo que el código de la ACM/IEEE-CS que a continuación
se muestra puede ser de gran utilidad para orientar la profesión en nuestro país.
Agradecimientos
El autor de esta traducción agradece la revisión de Mª José Rueda y los comentarios de F. Javier Herrera. Parte de este
trabajo se ha realizado bajo los proyectos UPV-EHU 141.226-EA083/98 y CICYT TIC 98 1179-E.
Bibliografía
Kevin W. Bowyer, Ethics and computing: living responsibly in a computerized world, IEEE Computer Society Press, Los
Alamitos, California, 1996.
D. Gotterbarn, “The ethical software engineer”, The Institute, vol. 23, nº. 2, p. 2, febrero de 1999.
IEEE, The IEEE Ethics Committee, http://www.ieee.org/committee/ethics
El Código de Ética y Práctica Profesional de Ingeniería del Software de la ACM / IEEE
Computer Society
Preámbulo
Los ordenadores poseen hoy en día una función básica cada vez mayor en comercio, industria, administración, medicina,
educación, entretenimiento, relaciones sociales y vida diaria. Son ingenieros del software quienes contribuyen, mediante
participación directa o enseñanza, al análisis, la especificación, el diseño, el desarrollo, la certificación, el mantenimiento y
pruebas de sistemas de software. Debido a su papel en el desarrollo de estos sistemas, tienen suficientes oportunidades para
aportar beneficios u ocasionar daños, o para influir en otros o permitir a otros hacer esto mismo Para garantizar, en la medida
de lo posible, que sus esfuerzos se utilizarán en buenos modos, los ingenieros del software deben obligarse a hacer de su
disciplina una profesión respetada y beneficiosa. De acuerdo con tal cometido, se adherirán al siguiente Código de Ética y
Práctica Profesional.
El Código contiene ocho Principios clave, relacionados con el comportamiento y las decisiones tomadas por los ingenieros
del software profesionales, tanto si son profesionales en ejercicio, educadores, gestores, directivos y responsables, como si se
trata de educandos y estudiantes. Los Principios identifican las diferentes relaciones en las que los individuos, grupos y
organizaciones participan, y las principales obligaciones de tales relaciones. Las Cláusulas de cada Principio son la imagen
de los diferentes niveles de obligación incluidos en esas relaciones. Estas obligaciones se funda-mentan en las características
humanas del ingeniero del software, en el especial cuidado al que está obligado con las personas que se ven afectadas por su
trabajo y en los elementos peculiares de la práctica de la ingeniería del software. El Código prescribe estas exigencias como
obligaciones de cualquiera que se identifique como ingeniero del software o que aspire a serlo.
No se pretende que se utilicen partes individuales del Código aisladamente, para justificar errores por omisión o comisión.
La lista de Principios y Cláusulas no es exhaustiva. Las Cláusulas no deben leerse como la frontera separadora entre lo
aceptable y lo inaceptable en todas las situaciones posibles de la conducta profesional. El Código no es un simple algoritmo
ético que genera decisiones éticas. En algunas situaciones los estándares pueden entrar en conflicto entre sí o con estándares
de otras fuentes. Estas situaciones requieren que el ingeniero del software haga uso de su juicio ético para actuar de la
manera que resulte más coherente con el espíritu del Código de Ética y Práctica Profesional, teniendo en cuenta las
circunstancias.
Las tensiones éticas se pueden manejar mediante una valoración cuidadosa de los principios fundamentales, mejor que
apoyándose ciegamente en reglamentos detallados. Los Principios deberían ayudar a los ingenieros del software a considerar
extensamente quién se ve afectado por su trabajo; a examinar si él o sus compañeros tratan al resto de las personas con el
debido respeto; a reflexionar sobre cómo la sociedad consideraría sus decisiones si estuviera bien informada; a analizar cómo
el menos favorecido quedará afectado por su decisión; y a considerar si un profesional ideal que trabajara como ingeniero del
software estimaría que sus actos son valiosos.
En todas estas valoraciones, la preocupación principal es la de la seguridad, la salud y el bienestar públicos; esto es, el
"Interés Público" es esencial en este Código.
El contexto dinámico y exigente de la ingeniería del software requiere que el código sea relevante y adaptable a las nuevas
situaciones a medida que surjan. Sin embargo, incluso con esta generalidad, el Código proporciona apoyo a los gestores e
ingenieros del software que necesiten actuar posi-tivamente, documentando la postura ética de la profesión. El Código aporta
un fundamento ético al que los individuos de un grupo o el propio grupo pueden acudir. El Código también ayuda a definir
cuestiones cuya solicitud a un ingeniero o grupos de ingenieros del software es ética-mente impropia.
El Código no está simplemente orientado a identificar la naturaleza de los actos cuestionables, sino que también tiene una
función educativa. Puesto que este código representa el consenso de la profesión en cuestiones éticas, es un medio para
educar, tanto a la sociedad como a los futuros profesionales, acerca de las obliga-ciones éticas de todos los ingenieros del
software.
Principio 1: Sociedad
Los ingenieros del software actuarán de manera coherente con el interés general. En particular, deberán, según sea adecuado:
1.01. Aceptar la completa respon-sabilidad de su trabajo.
1.02. Mitigar sus propios intereses, los del empresario, los del cliente y los de los usuarios con los del bienestar público.
1.03. Dar el visto bueno al software sólo si se tiene fundada creencia de que es seguro, de que cumple las especificaciones,
de que ha pasado las pruebas pertinentes y de que no disminuye la calidad de la vida, la confidencialidad ni daña el medio
ambiente. El efecto último del trabajo debería ser el bienestar público.
1.04. Revelar a las personas o autoridades correspondientes cual-quier peligro real o potencial para el usuario, la sociedad o
el medio ambiente, peligro que razonablemente consideren que está asociado con el software o con documentos
rela-cionados.
1.05. Cooperar en las materias relacionadas con preocupaciones graves causadas por el software, su instalación,
mantenimiento, soporte o documentación.
1.06. Ser justos y veraces en todas las afirmaciones, especialmente en las que sean públicas, relativas al software o a
documentos, métodos y herramientas relacionados.
1.07. Considerar las cuestiones de discapacidades físicas, asignación de recursos, desventajas económicas y otros factores
que puedan disminuir el acceso a los beneficios del software.
1.08. Estar dispuestos a utilizar las capacidades profesionales para buenas causas y contribuir a la educación del público en
general con respecto a su disciplina.
Principio 2: Cliente y empresario
Los ingenieros del software deberán actuar de tal modo que se sirvan los mejores intereses para sus clientes y empresarios, y
consecuentemente con el interés general. En particular, deberán, según sea adecuado:
2.01. Proporcionar servicios sólo en las áreas de su competencia, siendo honestos y francos acerca de cualquier limitación
que haya en su experiencia o educación.
2.02. No utilizar conscientemente software obtenido o retenido de manera ilegal o no ética.
2.03. Utilizar la propiedad de un cliente o patrón sólo de maneras adecuadamente autorizadas, y con el conocimiento y el
consentimiento de éste.
2.04. Garantizar que cualquier documento en el que se confía ha sido aprobado, cuando así se requiera, por alguien con
autoridad para hacerlo.
2.05. Mantener como privada cualquier información confidencial obtenida mediante el trabajo profesional, siempre que tal
confidencialidad no sea inconsistente con los aspectos de interés general ni con la ley.
2.06. Identificar, documentar, recoger evidencia e informar con prontitud al cliente o al empresario si, en su opinión, existe
la probabilidad de que un proyecto fracase, resulte demasiado caro, viole la legislación sobre propiedad intelectual o sea
proble-mático.
2.07. Identificar, documentar e informar al empresario o al cliente sobre cualquier asunto de interés social, o del que se tenga
conocimiento, acerca del software o de documentos rela-cionados.
2.08. No aceptar trabajo externo que vaya en detrimento de aquél que desarrollen para su principal contra-tante.
2.09. No representar interés contrario al del empresario o al del cliente, a menos que se comprometa otro valor ético más
elevado; en este último caso se informará al empresario o a otra autoridad competente acerca de esa preocupación ética.
Principio 3: Producto
Los ingenieros del software deberán garantizar que sus productos y las modificaciones relacionadas con ellos cumplen los
estándares profesionales de mayor nivel más que sea posible. En particular, deberán, según sea adecuado:
3.01. Promover la máxima calidad, un coste aceptable y un plazo razonable, garantizando que los compromisos
significativos al respecto quedan claros, que el empresario y el cliente los aceptan y que están disponibles para consideración
del usuario y del público en general.
3.02. Garantizar objetivos adecuados y alcanzables para cualquier proyecto en el que trabajen o vayan a trabajar.
3.03. Identificar, definir y examinar temas éticos, económicos, culturales, legales y medioambientales relacionados con
cualquier proyecto.
3.04. Garantizar, mediante una conveniente combinación de edu-cación, adiestramiento y experiencia, que están cualificados
para cualquier proyecto en el que trabajen o vayan a trabajar.
3.05. Garantizar una metodología adecuada para cualquier proyecto en el que trabajen o vayan a trabajar.
3.06. Trabajar para seguir los estándares de la industria, si están disponibles, que sean los más adecuados para las tareas,
desviándose de los mismos sólo cuando esté justificado ética o técnicamente.
3.07. Esforzarse para entender completamente las especificaciones del software que están desarrollando.
3.08. Garantizar que las especificaciones para el software sobre el que trabajan han sido bien documentadas, satisfacen los
requisitos
3.09. Garantizar estimaciones cuantitativas realistas de coste, plazos, personal y resultados de cualquier proyecto en el que
trabajen o vayan a trabajar, y proporcionar una evaluación de la incertidumbre de esas estimaciones.
3.10. Garantizar unas pruebas, depuraciones y revisiones adecuadas del software y de los documentos relacionados en los
que trabajen.
3.11. Garantizar una correcta documentación, incluyendo problemas significativos descubiertos y las soluciones adoptadas,
para cualquier proyecto en el que trabajen.
3.12. Trabajar para desarrollar software y documentos relacionados que respeten la confidencialidad de aquéllos que van a
verse afectados por ese software.
3.13. Ser cuidadosos para manejar sólo datos precisos, obtenidos mediante medios legales y éticos, y utilizarlos sólo de
maneras debida-mente autorizadas.
3.14. Mantener la integridad de los datos, siendo sensibles a aquéllos que estén obsoletos o equivocados.
3.15. Tratar todas las formas del mantenimiento del software con la misma profesionalidad que los nuevos desarrollos.
Principio 4. Juicio
Los ingenieros del software deberán mantener integridad e independencia en su valoración profesional. En particular,
deberán, según sea adecuado:
4.01. Moderar todos los juicios técnicos por la necesidad de amparar y mantener valores humanos.
4.02. Firmar sólo los documentos preparados bajo su supervisión o dentro de sus áreas de competencia, y con los que están
de acuerdo.
4.03. Mantener objetividad profesional con respecto a cualquier software o documentos relacionados para los que se les pida
evaluación.
4.04. No involucrarse en prácticas financieras engañosas, tales como sobornos, dobles facturaciones u otras prácticas
impropias.
4.05. Comunicar a todas las partes los conflictos de intereses que no puedan evitarse razonablemente.
4.06. Rechazar la participación, como miembros o asesores, en organismos privados, gubernamentales o profesionales
vinculados con temas de software, en los que ellos, o sus patronos o clientes, tengan potenciales conflictos de intereses no
revelados.
Principio 5. Gestión
Los gestores y líderes en ingeniería del software suscribirán y promoverán un enfoque ético a la gestión del desarrollo y el
mantenimiento del software. En particular, los ingenieros de software en funciones de dirección o liderazgo deberán, según
sea adecuado:
5.01. Garantizar una buena gestión en cualquier proyecto en el que trabajen, incluyendo procedimientos efectivos para
promover calidad y reducción del riesgo.
5.02. Garantizar que se informa a los empleados de los estándares antes de adherirse a ellos.
5.03. Garantizar que los empleados conocen las políticas y los procedimientos del empresario para la protección de las
claves de acceso, ficheros y otra información que sea confidencial para el empresario o para otros.
5.04. Asignar trabajo sólo después de tener en cuenta la educación y la experiencia, teniendo en cuenta el deseo de mejorar
tal educación y experiencia.
5.05. Garantizar unas estimaciones cuantitativas realistas de coste, plazo, personal, calidad y productos en cualquier proyecto
en el que trabajen o tengan intención de trabajar, y proporcionar una valoración de la incertidumbre de esas estimaciones.
5.06. Atraer empleados sólo mediante una descripción completa y precisa de las condiciones del trabajo.
5.07. Ofrecer una remuneración adecuada y justa.
5.08. No impedir injustamente a otro obtener la posición que merece de acuerdo con su cualificación.
5.09. Garantizar que hay un acuerdo correcto en lo referente a la propiedad de cualquier software, proceso, investigación,
escrito, u otra propiedad intelectual a la que el ingeniero del software haya contribuido.
5.10. Proporcionar los medios correspondientes en caso de alegaciones de incumplimiento de la política del empresario o de
este Código.
5.11. No pedir a un ingeniero del software hacer algo inconsistente con este Código.
5.12. No castigar a nadie por expresar preocupaciones éticas sobre un proyecto.
Principio 6. Profesión
Los ingenieros del software deberán progresar en la integridad y la reputación de la profesión, coherentemente con el interés
general. En particular, deberán, en la medida de lo posible:
6.01. Ayudar a desarrollar un ambiente organizativo favorecedor de un comportamiento ético.
6.02. Promover el conocimiento general de la ingeniería del software.
6.03. Diseminar el conocimiento de la ingeniería del software mediante la participación en organizaciones profesionales,
reuniones y publicaciones.
6.04. Apoyar, como miembros de una profesión, a otros ingenieros que se esfuercen en seguir este Código.
6.05. No promover el interés propio a costa de la profesión, el cliente o el empresario.
6.06. Obedecer todas las leyes que gobiernen su trabajo, a menos que, en circunstancias excepcionales, tal cumplimiento sea
inconsistente con el interés general.
6.07. Ser precisos en la descripción de las características del software en el que trabajan, evitando, no sólo falsas
declaraciones, sino también aquéllas otras que razonablemente podrían suponerse especulativas, vacías, decepcionantes,
engañosas o dudosas.
6.08. Tener la responsabilidad de detectar, corregir e informar errores en el software y documentos asociados en los que
trabajen.
6.09. Asegurarse de que los clientes, patronos y gerentes conocen la obligación del ingeniero del software con respecto a este
Código de ética, y las ramificaciones subsecuentes de tal obligación.
6.10. Evitar asociaciones con empresas y organizaciones que estén en conflicto con este código.
6.11. Considerar que las inobservancias de este Código son inconsistentes con ser un ingeniero del software profesional.
6.12. Expresar las preocupaciones a las personas implicadas cuando se detecten incumplimientos significativos de este
Código, a menos que sea imposible, contraproducente o peli-groso.
6.13. Informar sobre las vulneraciones de este Código a las autoridades pertinentes cuando esté claro que sea imposible,
contraproducente o peli-groso consultar a las personas implicadas en estas inobservancias.
Principio 7. Compañeros
Los ingenieros del software serán justos y apoyarán a sus compañeros. En particular, deberán, según sea apropiado:
7.01. Animar a los compañeros a adherirse a este Código.
7.02. Ayudar a los compañeros en el desarrollo profesional.
7.03. Reconocer completamente el trabajo de otros y abstenerse de atribuirse méritos que no son propios.
7.04. Revisar el trabajo de los demás de forma objetiva, sincera y convenientemente documentada.
7.05. Tratar justamente las opiniones, preocupaciones o quejas de un compañero.
7.06. Ayudar a los compañeros en el conocimiento completo de los estándares de trabajo, incluyendo políticas y
procedimientos
para proteger claves de acceso, ficheros y otra información confidencial, y medidas de seguridad en general.
7.07. No interferir injustamente en la carrera profesional de un compañero; sin embargo, la preocupación por el empresario,
el cliente o el interés público puede exigir, con buena voluntad, a cuestionar la competencia de un compañero.
7.08. En las situaciones que quedan fuera de las áreas de competencia personales, consultar las opiniones de otros
profesionales que tengan competencia en ese área.
Principio 8. Persona
Los ingenieros del software deberán participar en el aprendizaje continuo de la práctica de su profesión y promoverán un
enfoque ético en ella. En particular, deberán continuamente preocuparse de:
8.01. Mejorar su conocimiento de los avances en el análisis, la especificación, el diseño, el desarrollo, el mantenimiento y
pruebas del software y documentos relacionados, junto con la gestión del proceso de desarrollo.
8.02. Mejorar su capacitación para crear software de calidad, seguro, fiable y útil, con un coste y en un plazo razonables.
8.03. Mejorar su capacidad para producir documentación precisa informativa y correctamente escrita.
8.04. Mejorar su comprensión del software y documentos relacionados en los que trabajan y del entorno en el que se
utilizarán.
8.05. Mejorar su conocimiento de los estándares pertinentes y de las leyes que regulan el software y los documentos
relacionados en los que trabajan.
8.06. Mejorar su conocimiento de este Código, su interpretación y su aplicación al trabajo.
8.07. No dar un tratamiento injusto a nadie por prejuicios irrelevantes.
8.08. No influir a otros para emprender acción alguna que conlleve el incum-plimiento de este Código.
8.09. Reconocer que las inobservancias personales de este Código son inconsistentes con ser un ingeniero del software
profesional.
Vuelta a inicio
Novática 139: Material de Consulta
Novática es la revista de ATI (Asociación de Técnicos de Informática)
Nota importante: Se permite la reproducción de este artículo, excepto si está marcado con © o Copyright, debiéndose en todo caso
citar su procedencia
Important notice: This article can be reprinted except if marked with © or Copyright. If reprinted full mention of the source is
mandatory
Novática 139: monografía "LegisTIC (Legislación sobre Tecnologías de Ia Información y las
Comunicaciones)"
Material de Consulta
Emilio del Peso Navarro, Rafael Fernández Calvo
Como complemento de la monografía, recogemos aquí, sin pretensiones de exhaustividad, una serie de publicaciones y sitios
web relacionados, de forma directa o indirecta, con Legislación y Etica sobre Tecnologías de la Información y de las
Comunicaciones, y que consideramos de interés para nuestros lectores.
■
Bibliografía
■
Sitios web
■
Legislación
■
Etica Profesional
■
Otros
Bibliografía
Barriuso Ruíz, Carlos. La contratación electrónica. Dykinson. Madrid 1998.
Barutel Manaut, Carles. Las tarjetas de pago y crédito. Bosch. Barcelona 1997.
Carrascosa López, Valentín; Pozo Arranz, Mª A. y Rodríguez de Castro E.P. La contratación informática: el nuevo
horizonte contractual. Editorial Comares. Granada 1997.
Comercio Eléctrónico; monografía de Novática nº 135 (Septiembre-Octubre 1998) .
Davara Rodríguez, Miguel Ángel.
- De las autopistas de la información a la Sociedad Virtual. Aranzadi. Pamplona, 1996.
- La protección de datos en Europa. ASNEF-Equifax y Universidad Pontificia Comillas ICADE. Madrid, 1998.
- Manual de Derecho Informático. Aranzadi. Pamplona, 1997.
Fernández Calvo, Rafael. El ciberespacio y sus dilemas. El País, 5 de Noviembre de 1996, Especial SIMO (puede
obtenerse también en http://www.elpais.es).
Fernández Masiá y otros. Los derechos de propiedad intelectual en la nueva sociedad de la información. Editorial
Comares. Granada, 1996.
Galindo Ayuda, Fernando. Derecho e Informática. La Ley, Actualidad. Madrid, 1998.
Gete-Alonso y Calera, María del Carmen. El pago mediante tarjeta de crédito. La Ley. Madrid, 1990.
Gutierrez Francés, María Luz. Fraude informático y estafa. Ministerio Justicia. Madrid, 1991.
Hernando, Isabel. Productos Multimedia y derechos de autor. Editorial LC. San Sebastián, 1997.
Contratos informáticos. Editorial LC. San Sebastián, 1995.
Hubin J. Y Poulet, Yves. La sécurité informatique entré technique et droit. E. Story-Scientia. Namur, 1995.
Huxley Aldoux. Un mundo feliz. Circulo de Lectores. Barcelona, 1965.
Lointier, Pascal. Internet pour les juristes. Dalloz, 1996.
Ley Orgánica 5/1992 de Regulación del Tratamiento Automatizado de los Datos de carácter personal (LORTAD). BOE
del 31 de octubre de 1992, núm. 262.
Lopez Garrido D., García Arán M. El Nuevo Código Penal y la voluntad del legislador. Eurojuris, Madrid,1996.
Morant Ramon, José Luis; Ribagorda Garnacho, Arturo y Sancho Rodríguez, Justo. Seguridad y protección de la
Información. Ramón Areces. Madrid, 1994.
http://www.ati.es/novatica/1999/139/material.html (1 de 3) [10/05/2002 14:47:31]
Negroponte, Nicholas. Mundo Digital. Editorial B, Madrid, 1996.
Orwell, George. 1984. Destino. Barcelona, 1987.
Paez Mañá, Jorge. Bases de Datos Jurídicas. CSIC. CINDOC. Madrid, 1994.
Pastor Franco, José y Sarasa López, Miguel Ángel. Criptografía digital. Fundamentos y aplicaciones. Prensas
Universitarias de Zaragoza. Zaragoza, 1998.
Peso Navarro, Emilio y Ramos González, Miguel Ángel. LORTAD. Análisis de la Ley. Díaz de Santos. Madrid, 1998.
Peso Navarro, Emilio; Ramos González, Miguel Ángel; Fernández Sánchez, Carlos Manuel e Ignoto Azaustre, María
José. Manual de Dictámenes y Peritajes Informáticos. Díaz de Santos. Madrid, 1995.
Ribas Alejandro, Javier. Aspectos jurídicos del Comercio Electrónico en Internet. Aranzadi. Pamplona, 1998.
Saéz Vacas F. Inforpistas inteligentes. Editorial América Ibérica. Madrid, 1996.
Sieber Ulrich (edt). Information Technology Crime. Carl Heymanns Verlag. K.C. Köln, 1994.
Tapper Colin. Computer Law. Longman. England, 1989.
Zamiatin, Yevgueni. Nosotros. Tusquets. Barcelona, 1991.
Sitios web
Nota importante: enlaces comprobados en Mayo de 1999. No se garantiza su fiabilidad más allá de dicha fecha.
Legislación
Àrea de Dret Civil de la Universitat de Girona: http://civil.udg.es/
Boletin Hispanoamericano de Informática y Derecho: http://members.theglobe.com/boletin/
CEDIB (Centro de Estudios de Derecho e Informática de Baleares): http://www.uib.es/depart/dpr/cedibcas.html
CRDI (Centre de Recherches Informatique et Droit), Faculté de Droit, Université de Namur:
http://www.droit. fundp.ac.be/liens/default.htm
CPSR (Computer Professionals for Social Responsability) Computer Crime and Legal Resource Directory:
http://www.cpsr.org/cpsr/privacy/crime/crime.html
ECLIP (Electronic Commerce Legal Issues Platform), ESPRIT IV Project EP 27028:
http://www.jura.uni-muenster.de/eclip/
EULISP (European Legal Informatics Study Programme): http://www.eulisp.uni-hannover.de/
EUR-Lex, el Derecho de la Unión Europea: http://europa.eu.int/eur-lex/es/index.html
FindLaw (legislative search engine): Legal Subjects: Cyberspace Law:
http://www.findlaw.com/01topics/10cyberspace/index.html
Instituto de Informática Jurídica, ICADE, Madrid: http://www.upco.es/pagnew/titulos/infjur/portada.htm
Paladella Salord, Carlos de. Páginas sobre Derecho y Tecnología: http://members.xoom.com/_XOOM/cpaladella/index.htm
Porras Quintela, Manuel. Páginas sobre Derecho, Informática y Tecnologías de la Información y Comunicaciones:
http://www.ctv.es/USERS/mpq/principal.html
Ribas, Javier. Legislación sobre TIC: http://www.onnet.es/leyes.htm
Seminario Informática y Derecho, Universidad de Zaragoza: http://www.unizar.es/DERECHO/FYD/INDEX.HTM
Thomas. USA Legislative Information on the Internet: http://thomas.loc.gov/
United Nations. Manual on the prevention and control of computer-related crime:
http://www.ifs.univie.ac.at/~pr2gq1/rev4344.html
Etica Profesional
ACM (Association for Computer Machiner). Code of Ethics and Professional Conduct:
http://www.acm.org/constitution/code.html
ACM. Software Engineering Code of Ethics and Professional Practice. http://www.acm.org/serving/se/code.htm
ACM. Computing and Public Policy: http://www.acm.org/serving/
ACS (Australian Computer Society). Code of Ethics: http://www.acs.org.au/national/pospaper/acs131.htm
AIP (Associazione Informatici Professionisti). Codice Deontologico degli Informatici Professionisti:
http://www.a-i-p.it/info/cod_deon.html
ATInet: Código de Conducta para usuarios: http://www.ati.es/socios/introATInet.html (accesible solamente a socios de ATI)
BCS (British Computer Society). Code of Conduct:http://www.bcs.org.uk/aboutbcs/coc.htm
BCS. Code of Practice: http://www.bcs.org.uk/aboutbcs/cop.htm
Centre for Applied Ethics: Computer Ethics Resources on WWW: http://www.ethics.ubc.ca/papers/computer.html
CEPIS (Council of European Professional Informatic Societies). Code of Conduct: http://www.cepis.org/conduct.htm(ver
traducción al castellano en esta misma monografía)
GI (Gesellschaft für Informatik) Ethische Leitlinien: http://www.gi-ev.de/uebersicht/ethische_leitlinien.html
IEEE (Institute of Electrical and Electronic Engineers) Code of Ethics:
http://www4.ncsu.edu/unity/users/j/jherkert/ethics.html
IFIP (International Federation for Information Processing)Harmonization of Professional Standards:
http://www.ifip.or.at /minutes/C99/C99_harmonization.htm
WWW Ethics Center: Codes Of Ethics And Conduct: http://www.cwru.edu/affil/wwwethics/codes.html
Otros
Agencia de Protección de Datos: http://www.ag-protecciondatos.es
Alvarez Marañón, Gonzalo. Páginas sobre amenazas a la privacidad y medios para defenderla:
http://www.iec.csic.es/criptonomicon/
CNIL (Commission Nationale de l'Informatique et des Libertés), Francia: http://www.cnil.fr/
DGXIII at the European Commission: http://europa.eu.int/comm/dg13/index.htm
EFF (Electronic Frontier Foundation): http://www.eff.org
EPIC (Electronic Privacy Information Center): http://www.epic.org/
OSTP (White House Office of Science and Technology Policy): http://www.whitehouse.gov/OSTP.html
50 Edición digital/ ©ATI 2000
SECCIONES TÉCNICAS
NOVATICA sep./oct. 2000 nº147
Profesión informática
Peter Denning
Department of Computer Science School of Intormation,
Tecnology and Engineering, George Mason University
El futuro de la profesión de
Tecnología de la Información
Traducción: Eduardo Pérez Pérez
 ACM Entrevista publicada en el número 5 de la revista Ubiquity de
ACM (21 de marzo de 2000) y accesible en inglés en http://acm.org/
ubiquity/interviews/p_denning_1.html. Se publica con los correspondientes
permisos del autor y de ACM (Association for Computing Machinery).
UBIQUITY: ¿Qué nos enseñan sobre los profesionales de la
Tecnología de la Información los recientes ataques por
bloqueo de servidores en Internet?
y trabaja. Tarde o temprano, buscamos ayuda profesional
sobre problemas legales como hipotecas, escrituras, testamentos, fianzas, contratos mercantiles, impuestos y muchos
más.
PETER DENNING: Tuvieron una consecuencia positiva
(que, por supuesto, no era la intención de sus autores). Los
ataques han atraído masivamente la atención pública sobre
uno de esos pequeños secretos de los que nadie quiere hablar.
El secreto es que nos hemos hecho altamente dependientes
de los sistemas digitales y de los profesionales que los
diseñan y mantienen. Ahora todos saben la verdad: nuestros
sistemas de ordenadores y comunicaciones son fáciles de
inhabilitar por vándalos anónimos. ¿Podemos confiar en
profesionales que nos ayuden a defendernos contra esos
ataques y mantener todo funcionando? ¿Quiénes son estos
profesionales? ¿Quién los educa? ¿Mantienen su formación
al día? ¿Quién les otorga el permiso para ejercer? ¿Hay
suficientes profesionales? ¿Son de confianza? Las empresas
siempre han mostrado preocupación por nuestros planes de
estudios, la preparación y cualificación de nuestros titulados
universitarios, las especialidades que pueden seguir, las
prácticas en empresas para complementar una formación
conceptual, los métodos para trabajos conjuntos con universidades y la profesionalidad de nuestros titulados universitarios. Ahora todos están preocupándose de estas cosas y de
otras más.
U: ¿Son esas analogías aplicables a la Tecnología de la
Información?
PD: Completamente. Hace diez o veinte años, muchos
observadores de la informática creían que la computación
era un rama de la ingeniería electrónica, las matemáticas o
la gestión empresarial, pero no un campo por sí mismo.
Ahora no. Hay un amplio consenso de que todos somos
completamente dependientes de la Tecnología de la Información y necesitamos ayuda profesional. El campo de
preocupación humana permanente es nada menos que la
comunicación y coordinación entre seres humanos. La
Tecnología de la Información se ha convertido en parte
permanente del medio a través del cual tienen lugar las
actividades humanas. No tenemos que persuadir a nadie de
que necesitamos muchos profesionales bien formados y
entrenados en la Tecnología de la Información. Esto plantea
a las asociaciones existentes en el campo de la Tecnología de
la Información el mayor reto que han tenido hasta la fecha:
trabajar conjuntamente para organizarse y formar una profesión.
U: Antes de preguntar cómo se percibe dentro de la profesión de la Tecnología de la Información esa lista de preocupaciones, debemos preguntar ¿cuál es su noción de «profesión» y qué significa ser un «profesional»?
U: Entonces ¿a quiénes podemos considerar profesionales
de la Tecnología de la Información?
PD: Para mí es útil aprender de otras profesiones ya consolidadas como medicina o abogacía. Uno de los aspectos más
llamativos de las profesiones es su longevidad y durabilidad.
Esto no es casual. Las profesiones se forman en torno a
campos de preocupación humana permanente: cosas que
afectan a todos, en cualquier momento, lugar y cultura. Por
ejemplo, ningún ser humano puede evitar la preocupación
por la salud. Tarde o temprano todos tenemos algún problema de salud y buscamos ayuda profesional. El profesional
del cuidado de la salud necesita una experiencia sólida para
ser útil, experiencia que va mucho más allá de lo que un
aficionado puede aprender mediante lecturas o charlas. El
profesional del cuidado de la salud debe estar bien formado
y orientado para ayudar a las personas. Se pueden hacer
afirmaciones similares sobre la abogacía. Ningún ser humano puede escapar la preocupación por las leyes de donde vive
PD: Ésa es una cuestión importante. Nuestra visión tradicional de los informáticos como programadores y analistas de
sistemas es demasiado restringida. La informática tradicional no estudia el abanico completo de preocupaciones que la
gente tiene respecto a la Tecnología de la Información y es
frecuentemente criticada por sus diversos tipos de restricciones. Pondré algunos ejemplos. Pocos departamentos de
informática ofrecen especialidades en seguridad de la información, que es una preocupación primordial de los usuarios
de los sistemas de información. Muchos ingenieros de
software creen ahora que los planes de estudios tradicionales
en informática son demasiado limitados para acomodar la
troncalidad científica y profesional de la ingeniería del
software. Están promoviendo el establecimiento de planes
de estudios y departamentos de ingeniería del software
independientes. Muchas empresas creen que los departa-
El concepto de profesional
mentos de informática sobrevaloran la teoría. Confían en sus
propias universidades de empresa1 para cubrir las carencias
de formación práctica en Tecnología de la Información.
¿Sabía usted que existen más de 1.600 universidades de
empresa? ¡Este número es mayor que el número de departamentos académicos de informática! Y eso que en él no se
incluyen muchos cientos de organizaciones educativas no
académicas.
Los departamentos de informática no se plantean las necesidades educativas de todos esos técnicos de asistencia al
consumidor, la gente que responde telefónicamente a preguntas sobre software y ordenadores personales. Sin estar
formados como informáticos, estos técnicos atienden las
preocupaciones de la gente sobre sus ordenadores y redes.
Ellos son, a mi entender, miembros de pleno derecho de la
profesión de Tecnología de la Información. Lo mismo se
puede afirmar sobre los diseñadores profesionales de portales de web.
El año pasado hice un sondeo rápido para ver qué grupos
profesionales estaban ya organizados en varias especialidades de Tecnología de la Información. ¡Conté una docena!
Estoy seguro de que hay otra docena más. No es posible que
la informática tradicional pueda formar gente en todas estas
especialidades. La informática se ha convertido en una más
de las muchas especialidades de la Tecnología de la Información, si bien tiene una categoría especial, como la que
corresponde a los padres de una gran familia. Yo he tenido
que romper el viejo cliché de creer que aquellos que tienen
un diploma universitario en informática son los únicos
miembros de pleno derecho de la profesión de la Tecnología
de la Información.
U: ¿Piensa que esta visión suya está ampliamente aceptada,
o encuentra resistencias?
PD: Hace unos años había resistencia. Hoy día crece el
número de personas que están cambiando de opinión. En el
último año, el National Research Council publicó un informe titulado «Dominio de la Tecnología de la Información»
(título original Fluency in Information Technology), que
proponía la idea de que todo ciudadano debería tener un
cierto nivel de dominio de los ordenadores, en vez de sólo un
nivel básico. Este informe llamó la atención de muchos
educadores, que ahora quieren colaborar con los informáticos
para definir un marco conceptual en el que sus estudiantes
puedan alcanzar ese dominio. ACM e IEEE Computer
Society han estado trabajando en una revisión de la
troncalidad de los planes de estudios de informática, denominada Curriculum 2001. En las propuestas iniciales presentadas a otros grupos descubrieron que esos otros grupos
querían que la troncalidad informática sirviera a los muchos
clientes de la informática que existen ahora. La visión
restringida y especializada ya no es la filosofía básica
correcta. Los profesionales informáticos están respondiendo positivamente a estos cambios, participando en la cuestión de cuál es la troncalidad de toda la Tecnología de la
Información. Creo que esto es un acontecimiento afortunado. Los informáticos están empezando a preguntarse: ¿quié-
Edición digital/ ©ATI 2000 51
nes son nuestros clientes? Creo que la actitud extravertida
que emana de esta forma de pensar se extenderá. Nos
permitirá replantearnos nuestras relaciones entre especialidades profesionales. El viejo pensamiento llevó al enfrentamiento entre miembros de la profesión, tales como
informáticos, ingenieros de software y científicos de la
computación, y a enfrentamientos con otros profesionales,
como bibliotecarios digitales, arquitectos de software,
webmasters o técnicos de asistencia al consumidor. Creo que
el nuevo planteamiento va a incluir a todos estos grupos.
Todos ellos son parte del campo de la Tecnología de la
Información.
U: ¿Así que está ocurriendo una especie de «balcanización»
(N. del E.: división aguda y difícil de conciliar)?
PD: Sí. Se podría decir eso. En medio de los enfrentamientos
hay una tendencia natural de cada grupo a seguir su propio
camino, operar de forma autónoma y tratar de evitar
interacciones que podrían ser desagradables e improductivas. Me siento optimista respecto a que encontraremos un
consenso bajo un único abrigo: el de la Tecnología de la
Información.
U: ¿Tiene consecuencias negativas este desvío hacia la
balcanización? ¿Son importantes?
PD: Creo que hay consecuencias negativas importantes. El
siguiente es un ejemplo que afectará a muchos ingenieros de
software en los próximos años: tanto ACM como IEEE
Computer Society están profundamente preocupadas con la
ingeniería del software, pero no están de acuerdo en si la
ingeniería del software tiene la madurez suficiente como
para poder convertirse en una profesión. Por tanto, tienen
enfoques diferentes. IEEE Computer Society cree que la
ingeniería del software debería ser una profesión y, por
tanto, debe comportarse como tal. Dado que otorgar permiso
oficial para ejercer es parte de la profesión, ellos están
dispuestos a ayudar a los diferentes Estados de EE.UU. en la
creación de buenos exámenes para poder ejercer oficialmente como ingenieros de software. Por otro lado, ACM cree que
otorgar permisos oficiales de ejercicio como ingeniero en el
campo todavía inmaduro de la ingeniería del software daría
la falsa impresión de que los ingenieros que hayan obtenido
dicho permiso son sistemáticamente capaces de producir
sistemas fiables y seguros. El conjunto de conocimientos
base de la ingeniería del software no está suficientemente
desarrollado como para asegurar que el permiso oficial para
ejercer como ingeniero de software sea significativa. ¿Cómo
podemos reconciliar estos dos puntos de vista? ¿Cómo
alcanzaremos alguna coherencia entre los requisitos que
establezcan los Estados para otorgar el permiso oficial si las
dos asociaciones líderes no están de acuerdo en si ese
permiso tiene algún significado?
U: ¿Tiene esta balcanización algún impacto directo en los
profesionales de la Tecnología de la Información?
PD: Seguro. El ingeniero de software en Texas, donde se
prevé otorgar permisos oficiales, se enfrentará a un dilema.
¿Qué haría usted si fuera un ingeniero? ¿Prepararse para el
examen, sabiendo que IEEE le respalda, u olvidarse de él
porque ACM dice que la gente terminará creyendo que los
permisos oficiales de ejercicio profesional no significan
nada?
Certificación y permiso oficial
U: ¿Tiene la certificación, que no el permiso oficial de
ejercicio profesional, algún papel dentro de este debate?
PD: Vamos a distinguir entre certificación y permiso oficial
de ejercicio profesional. La certificación es un proceso por
el cual los representantes de la comunidad garantizan que
usted tiene ciertas habilidades. El permiso oficial es algo que
le otorga un Estado para que usted pueda ejercer su profesión
en ese Estado. Muchos Estados pueden perfectamente hacer
que la certificación emitida por asociaciones profesionales
sea un requisito para la titulación. Me consta que tanto ACM
como IEEE Computer Society creen en la certificación
otorgada por la profesión. Puedo imaginar fácilmente la
cooperación entre ambas asociaciones en programas para
certificar ingenieros de software a pesar de que no colaboren
en ayudar a los Estados a desarrollar sus exámenes para
obtener el permiso oficial de ejercicio profesional. Ni siquiera tienen que otorgar la certificación ellas mismas. Pueden
reconocer los planes de estudios de universidades que preparen para la certificación y pueden ayudar al ICCP (Institute
for Certification of Computer Professionals - Instituto para
Certificación de Profesionales Informáticos) a desarrollar
una certificación de ingeniería del software. Si las asociaciones profesionales no colaboran en la certificación, los exámenes estatales para la obtención del permiso oficial se
convertirán en certificaciones de hecho y no habrá coherencia entre la diferentes regiones. ¡Podría haber 50 interpretaciones de la certificación dentro de EE.UU.! Si las asociaciones colaboran, tendremos un conjunto de certificaciones
estándar para todos y todos los Estados que quieran otorgar
permiso oficial de ejercicio profesional podrán utilizar
dicho conjunto como referencia.
U: La certificación es claramente una preocupación internacional y no sólo una preocupación de los Estados que forman
EE.UU. ¿Se cubre con ambas organizaciones un abanico
suficientemente amplio?
PD: Oh, sí, por supuesto. Tanto ACM como IEEE Computer
Society operan internacionalmente. Ambas pertenecen a
IFIP (International Federation of Information Processing
Societies). Alrededor del 40% de los miembros de ACM son
internacionales (de fuera de EE.UU.). Hace unos pocos
años, ACM reorganizó su Consejo para reducir la representación de EE.UU. y aumentar la representación internacional. ACM ha replicado sus servicios web en varios puntos
distribuidos internacionalmente, para que todo el mundo
pueda tener un acceso bueno a los servicios de ACM en la
web (http://acm.org).
U: ¿Qué piensan organizaciones como ACM sobre esos
famosos chavales que dejan la escuela primaria para conver-
tirse en especialistas en webs o abandonan la universidad
para crear una empresa? ¿Ayuda ACM a este tipo de gente?
PD: Ambas asociaciones recomiendan a los jóvenes la
obtención de titulaciones universitarias en disciplinas de la
Tecnología de la Información. Ni ACM ni IEEE, que yo
sepa, tienen programas específicos para los alumnos que
abandonan sus estudios universitarios y entran en el mercado de trabajo tan pronto. Su pregunta trae a colación otra
cuestión: el aprendizaje continuo de por vida. A lo largo de
los años, ACM ha desarrollado relaciones de trabajo mucho
más cercanas con las universidades que con el sector de la
Tecnología de la Información. Esto debe cambiar. ACM y
las otras asociaciones tendrán que desarrollar un consenso
más amplio sobre un modelo de formación profesional
continuada que defina los papeles de la educación superior,
las organizaciones educativas no académicas, y las universidades empresariales. Esto mostrará a la gente joven los
tipos de itinerarios que pueden seguir en su carrera y dónde
pueden conseguir ayuda para seguir dichos itinerarios.
Espero que esto sea parte de los resultados de la iniciativa
ITP (Information Technology Profession - Profesión de
Tecnología de la Información).
El papel de la innovación
U: Usted ha comentado el papel de la educación en la
profesión. ¿Qué hay sobre la innovación? ¿No tiene el
mundo de los negocios en la Tecnología de la Información
un enfoque sobre la innovación diferente del que tienen las
universidades?
PD: Hay una cantidad increíble de innovación dentro del
mercado de la Tecnología de la Información. Muchos de mis
colegas de la universidad me dicen que aprenden más sobre
las nuevas tecnologías a través de los periódicos que en sus
congresos de investigación. Muchos malentendidos tienen
su origen en que las universidades y el mundo de los
negocios utilizan la misma palabra, «investigación», para
referirse a distintos modelos de innovación. Las universidades creen que toda innovación tiene su origen en las ideas.
Sus laboratorios de investigación se concentran en producir
ideas y extenderlas mediante publicaciones científicas y
conferencias. Algunas de esas ideas son asumidas por el
mercado y finalmente producen innovaciones. Sin embargo,
el comercio y la industria creen que las invenciones no son
innovaciones. Piense en todos esos inventos que fueron
patentados pero nunca produjeron un céntimo para sus
inventores. El comercio y la industria piensan que las
innovaciones ocurren en la práctica, en la vida cotidiana de
la gente. Buscan nuevos productos que permitan prácticas
nuevas e innovadoras. Buscan servicios que ayuden a la
gente a realizar prácticas nuevas e innovadoras. Forman a la
gente en prácticas nuevas e innovadoras. Los emprendedores son los agentes que facilitan que esto ocurra, ayudados
al principio por el dinero de inversores arriesgados. Así
pues, tenemos dos dinámicas en marcha. Los laboratorios de
investigación de las universidades y de las empresas negocian con ideas, y obtienen fondos del gobierno o de presupuestos corporativos para investigación. Los emprendedo-
Edición digital/ ©ATI 2000 53
res negocian con productos, servicios y nuevas prácticas, y
obtienen fondos de los capitalistas de riesgo.
podría conseguirse a través de programas de cooperación,
prácticas en la empresa y acuerdos de trabajo-estudio.
U: Con estas ideas en mente, ¿cómo cambiaría usted los
enfoques actualmente usados en la educación superior?
En mi opinión, el mundo de los emprendedores no es contemplado por las universidades porque pertenece a un mundo
distinto: las universidades se dedican a trasformar ideas y los
emprendedores se dedican a trasformar prácticas. Las prácticas son los siervos en el reino de las ideas. Los programas
enfocados a las prácticas profesionales y al desarrollo de
niveles altos de competencia profesional no son el objetivo
del diseño curricular. Si pudiera volver a empezar, diseñaría
un currículo en el que el conocimiento concreto fuese un
compañero de igual a igual con el conocimiento conceptual
y en el que la innovación a través de la transformación de las
prácticas tuviese el mismo lugar que la innovación a través
de las ideas.
PD: Me gustaría que ocurrieran dos cosas: la expansión de
los planes de los laboratorios de investigación y la enseñanza sobre el mundo de los emprendedores o «emprendedoriado» (N. del T.: entrepreneurism, en el original
inglés). Estas dos cosas están relacionadas porque la clase de
innovación que se puede incorporar a los laboratorios de
investigación es exactamente del mismo tipo que dominan
los emprendedores. Los laboratorios de las universidades
podrían mejorar sus dotes de innovación añadiendo a sus
planes proyectos de I+D que ayuden a los negocios y a la
industria a desarrollar productos. Esto también ayudaría a la
industria a movilizar parte del poder intelectual existente en
los laboratorios universitarios hacia el examen de las cuestiones profundas de las tecnologías subyacentes en sus
productos. También me gustaría ver que aprendemos a
enseñar a nuestros estudiantes a ser emprendedores. La
habilidad principal del emprendedor es crear prácticas
innovadoras y hacer que la gente las use. No basta con tener
una buena idea. Cuesta trabajo convertir esa idea en práctica
y el emprendedor es el catalizador que lo facilita. No estamos
enseñando esto ahora. Las empresas y el sector están interesados en ayudar a que las universidades aprendan a enseñar
esto.
U: Lo que está usted sugiriendo contrasta con la realidad
actual.
PD: Nuestros currículos están basados en dos hipótesis
relacionadas entre sí sobre cómo aprende la gente. Una es
que las ideas preceden a la acción. Por tanto, necesitamos
dar a nuestros estudiantes conceptos y modelos mentales del
mundo, junto con unas pocas oportunidades para aplicar
esos modelos a la acción. La otra es que la misión de las
universidades es preparar a los estudiantes para un largo
viaje centrándonos en principios fundamentales y perpetuos. Mi objeción es que estas dos hipótesis son incompletas.
Ignoran una tremenda esfera de conocimiento que yo llamo
«prácticas». Las prácticas son rutinas, hábitos, habilidades,
procedimientos y procesos que, una vez asimilados, se usan
sin meditación. Cuando se considera que alguien es un
profesional competente, son sus prácticas lo que está siendo
evaluado, no su conocimiento conceptual. Usted puede
haberse dado cuenta de que muchas empresas no están
demasiado contentas con la calidad de nuestros titulados
universitarios (los absorben ávidamente a todos y a la vez
protestan). Les gustaría que nuestros titulados universitarios salieran no sólo con la cabeza llena de ideas, sino
también con sus cuerpos llenos de prácticas que se ajusten a
los puestos de trabajo en Tecnología de la Información. Las
universidades y la industria necesitan encontrar un nuevo
entendimiento sobre cómo aprenderán los estudiantes un
equilibrio mejor entre conocimiento conceptual y prácticas
profesionales. Esto no implica una reducción del número de
horas dedicado a la troncalidad del currículo, sino que
ITP, ICDL ...
U: Vamos a terminar con un comentario sobre la iniciativa
ITP (Information Technology Profession - Profesión de
Tecnología de la Información). ¿En qué consiste?
PD: Es una iniciativa tomada por ACM, con la visión general
de acabar estableciendo la Tecnología de la Información
como una profesión, y en ese proceso trasformar quién es
ACM y cómo interactúa con los profesionales de la Tecnología de la Información y con el público en general. ACM
pretende ayudar a formar esta profesión que nos hace compañeros, superar las tendencias hacia la balcanización, llegar
a los profesionales de Tecnología de la Información que no
habían estado involucrados antes y ofrecer más ayuda a los
usuarios de la Tecnología de la Información. Esto requerirá,
durante un periodo de tiempo, nuevas iniciativas de ACM,
nuevos proyectos y servicios de ACM, nuevas colaboraciones, nuevas alianzas, nuevas formas de hacer negocios ...
toda clase de innovaciones. Yo presido un comité director de
profesionales para ayudar a guiar la iniciativa y sugerir
proyectos a desarrollar.
U: ¿Hay ya algunos proyectos en marcha?
PD: Sí. Hay dos en marcha y está previsto un tercero. Uno es
el proyecto Ubiquity, que es un híbrido entre una revista de
opinión bien editada y un foro de debate bien moderado.
Mucha gente tendrá la oportunidad de hablar abiertamente
a través de Ubiquity y de influir en las directrices de ACM
haciéndonos saber lo que realmente les preocupa. Ubiquity
se plantea llegar a muchos grupos nuevos, involucrándolos
en el debate de lo que significa ser una profesión y ser
profesionales. Ubiquity está abierta a todo el mundo, de
forma gratuita.
El segundo proyecto es el ICDL (International Computer
Driving License o acreditación internacional de manejo de
ordenadores. N. del E.: versión internacional del programa
ECDL - European Computer Driving License, promovido
por CEPIS, del que ATI es promotor en España). Se trata de
una certificación de habilidades laborales básicas para sistemas informáticos de oficina donde se incluyen proceso de
texto, hojas de cálculo, bases de datos e Internet. Organizaremos la rama estadounidense del popular programa europeo que certifica a 45.000 personas al mes. Es interesante
que el primer esfuerzo de certificación en el que ACM se
involucra no es para profesionales de la Tecnología de la
Información, sino para otros profesionales que usan la
Tecnología de la Información en su trabajo.
El tercer proyecto, que esperamos comenzar en otoño del
año 2000, es un proyecto de identidad ITP (Information
Technology Profession). Su misión es definir la estructura
del campo de la Tecnología de la Información, incluyendo
su troncalidad profesional e intelectual, sus estándares de
cualificación, sus instituciones y sus grupos profesionales.
El comité director para este proyecto se formará a partir de
diversos sectores del campo y habrá amplias oportunidades
para que todos los involucrados en el campo puedan afectar
al resultado. Hace unos años, lideré un grupo que produjo el
informe Computing as a Discipline, que fue la base de una
amplia revisión curricular en 1991, llevada a cabo conjuntamente por ACM e IEEE Computer Society. También
sirvió a los científicos de la computación y a los científicos
experimentales informáticos para encontrar su lugar en
nuestro campo de actividad.
El comité director está considerando otros proyectos, entre los
que se incluyen formación del profesorado de enseñanza
secundaria, formación de profesionales de la Tecnología de la
Información, certificación de profesionales de la Tecnología de
la Información, modelos de formación continuada, conjuntos
de habilidades para la Tecnología de la Información, y movilidad de los profesionales de la Tecnología de la Información.
El futuro
U: Si fuéramos a tener otra charla como esta dentro de unos
cinco años, ¿piensa que las cuestiones serían completamente diferentes, o volverían a ser las mismas?
PD: Esa es una buena pregunta. Si todo va bien, dentro de
cinco años habrá muchas cosas nuevas a considerar. Estaremos de acuerdo en lo que es nuestro campo y en cómo
encajan sus muy diversas especialidades. Tendremos un
acuerdo general sobre el modelo de formación continuada
para los profesionales de la Tecnología de la Información,
un modelo que reconozca los papeles de la formación
académica, no académica y corporativa. Tendremos programas de estudios para enseñar Tecnología de la Información
a los profesores de secundaria. Ofreceremos amplios programas de actualización para los profesionales de la Tecnología
de la Información y promoveremos la certificación de los
profesionales. El programa ICDL será más amplio y ofrecerá más niveles de certificación. La informática habrá aprendido a tender su mano y servir a sus muchos clientes. Los
centros universitarios de Tecnología de la Información
enseñarán a ser emprendedores e incluirán los procesos de
innovación comercial dentro de sus planes de investigación.
El campo será mucho más atractivo para más jóvenes,
incluyendo jóvenes mujeres, y habrá menos carencia de
trabajadores en la Tecnología de la Información.
U: Y ¿cómo espera que las organizaciones profesionales
hayan cambiado para entonces?
PD: Creo que en el plazo de cinco años veremos muchos más
proyectos conjuntos entre ACM, IEEE y otros grupos profesionales. Por ejemplo, espero que estos esfuerzos interasociaciones produzcan avances significativos en certificación, especialmente para los ingenieros de software. Las
asociaciones profesionales podrán resucitar el ICCP como el
principal ente administrador de certificaciones. Espero avances significativos en los currículos a través de esfuerzos
conjuntos. Espero avances significativos en nuestro conocimiento técnico en muchas áreas, incluyendo algunas que
nos causan bastantes problemas hoy día como fiabilidad de
los sistemas software y seguridad de la información. Finalmente, cada asociación ofrecerá nuevos programas para el
desarrollo profesional, la formación y la ayuda al público.
U: Con su mirada en el futuro, ¿qué procesos acabarán
siendo los más importantes dentro de la profesión?
PD: La valoración del conocimiento práctico como compañero paritario del conocimiento conceptual, dentro de la
profesión de la Tecnología de la Información. La aceptación
del «emprendedoriado» como un proceso de innovación
junto con la producción de ideas. El reconocimiento de las
universidades de empresas y los proveedores de formación
no académica como parte del sistema de formación continuada. La inclusión, dentro de la profesión de la Tecnología
de la Información, de especialidades orientadas a los servicios. La combinación de estos logros y una apariencia e
identidad mucho más humana de la profesión harán las
carreras de la Tecnología de la Información mucho más
atractivas para muchos jóvenes, especialmente jóvenes
mujeres. Todo esto constituirá un desarrollo muy importante y muy bien acogido.
Nota del Traductor
1. Aunque las universidades de empresa, muy abundantes en
los Estados Unidos de América, no son universidades en el
sentido estricto, es decir, no tienen el reconocimiento legal
correspondiente en algunos países como España, he preferido mantener la palabra universidad en la traducción. Un
ejemplo de universidad de empresa es Motorola University
(http://mu.motorola.com) y hay más detalles sobre este tipo
de universidades en http://www.glresources.com.
The Profession of IT
Peter J. Denning and
Robert Dunham
The Core of the
Third-Wave Professional
The IT profession is the first profession in the third wave of civilization.
JASON SCHNEIDER
F
or some time, IT professionals have been grappling
with four dilemmas. They
are: skills, breadth versus
depth, design, and licensing.
The IT skills dilemma. Employers say that IT graduates lack
important skills needed in the
workplace, notably knowledge of
current IT and various “soft” skills,
including presentation, customer
relations, leadership, and team
work. At the same time, employers
tell university departments they
value the general, principles-based
education universities offer; and
they snap up every graduate.
Should we change the curriculum or not?
The breadth versus depth
dilemma. The market seems
to demand graduates with
great depth in a technical
specialty and at the same time a
broad grasp of the IT field. Educators see no clear path to a
response. There are so many specialties that any given academic
department can cover only a few.
There is already too much to
cover in the 60 credit hours allocated for major courses within a
BS degree. Moreover, depth and
breadth appear to be individual
choices—in what areas does a person seek depth? Across what spec-
trum does a person seek breadth?
The design dilemma. Our current software design processes consistently yield systems with a wide
range of flaws, making them unreliable and difficult to use. Michael
Dertouzos documents these flaws
and argues that the complexities of
IT cannot be successfully hidden
from users without a fundamental
change in the design process [3].
Dertouzos is the most recent of a
long lineage who for over 20 years
have exhorted us to move from
technology-centered to humancentered design. Our inability to
consistently develop software that
meets specifications and satisfies
customers has led not only to widespread dissatisfaction with commercial-off-the-shelf (COTS)
software, but to the licensing
dilemma discussed next. Makers of
COTS software packages keep
encountering users who find the
systems hopelessly complex, overloaded with unneeded features,
missing useful features, and backed
with surly, thin technical support.
These software makers deny any
liability for malfunction and refuse
to offer a warranty. No other
industry takes so little responsibility
for its products. Through the Uniform Computer Information Technology Acts (UCITA) movement,
software makers entreated state legislatures to exempt them from liability. Why is it so difficult to
move toward a new system of
software development?
The licensing dilemma. Among
software engineers there is contentious disagreement over the
value of licensing software engineers who work on critical systems.
Software engineers consulted by
ACM are split nearly 50/50. Consensus is currently impossible, and
no licensing system will work without a consensus. Those who favor
licensing point to other fields
where licensing has produced value
COMMUNICATIONS OF THE ACM
November 2001/Vol. 44, No. 11
21
The third wave is why we suffer simultaneous crises in
so many institutions at once, including education, research,
health, justice, family, and politics.
by giving assurances that professions meet minimum standards of
competence and understand their
responsibilities. In those fields,
most professionals themselves see
the license as a mark of distinction
conferring credibility. These software engineers believe licensing
would strengthen the field, channel
the most experienced talent to critical systems, improve the safety of
systems, and demonstrate that software engineers take their responsibilities seriously. Those who oppose
licensing believe the field is immature—no license would distinguish
the competent software engineers
from the others. Indeed, they
believe a license would give false
assurances that a software engineer
is capable of producing safe systems. These software engineers also
believe licensing would diminish
diversity and stifle creativity of software developers; they do not see a
license as a mark of distinction, and
they view certification and licensing
in other professions (such as medicine) with great suspicion and cynicism. Should we advocate for or
against licensing?
It is so often the case that
dilemmas are matters of perception
rather than objective reality. When
we broaden our perception, we can
reinterpret the world in a way that
resolves the dilemma. What is the
larger phenomenon of which these
22
four dilemmas are manifestations?
Our belief is this: We are in a
transition from the second wave of
civilization (the Industrial Age) to
the third wave (the Network Age).
The IT profession is the first profession of the Network Age. Our
traditions for understanding professions are rooted in the Industrial
Age and do not adequately inform
us about coping with the new realities of the Network Age.
The Third Wave
In 1970 Alvin Toffler published an
influential book, Future Shock, in
which he interpreted the history of
our civilization in three waves: the
Agrarian Age, the Industrial Age,
and the Information Age. He characterized the essence of the second
wave as production through muscle
power, and of the third wave production through brain power. In
1990 Toffler followed up with The
Third Wave, a thorough investigation of the changes by then well
under way.
Toffler’s premise is that our
emerging information society is not
just digital and electronically networked. We are experiencing difficult cultural, social, institutional,
and moral changes in society. The
third wave is why we suffer simultaneous crises in so many institutions at once, including education,
research, health, justice, family, and
politics—institutions with tradi-
November 2001/Vol. 44, No. 11 COMMUNICATIONS OF THE ACM
tions rooted in a mass-production
industrial society. Because it makes
communication fast, global, and
cheap, IT has been facilitating
changes in business, commerce,
and education. Once people experience the benefits from the changes,
they don’t want to turn back. We
are creating a new civilization that
will coexist with agrarian and
industrial components. Some agrarian societies, such as Western
China, will enter the third wave
directly without passing through an
industrial age.
In the Information Age, distance
becomes less important as the cost
and speed of communication drops.
A host of new, intangible digital
products such as e-books, music,
video, shrink-wrapped software,
and other intellectual property are
widely available for sale. Because
making new copies costs almost
nothing, most of the cost of these
products is in their development.
Time appears to compress as the
Internet brings us requests and
offers at an increasing rate; potential
competitors, who may now number
in the thousands, can appear
quickly and unexpectedly. More
people are falling prey to stress
induced by information overload.
One of the deeper changes is the
system of wealth creation. In the
second wave, wealth was created
through production; capital was
based in tangible assets. In the third
wave, wealth is created through
transactions that bring value to the
customer, for which the customer is
willing to pay the provider; capital
is in the form of electronic marks
on hard disks. Much wealth is created by transactions that do not
involve intangible goods. Taiwan
techno-entrepreneur Sayling Wen
believes that wealth created through
value-generating transactions is the
essence of e-commerce, which is a
new dimension of commerce that
could not be realized in the Industrial Age [9]. He puts the start of
the third wave in 2000, the year in
which e-business reached a critical
mass. He refers to the third wave as
the Network Age.
The IT profession is forming
along the wavefront; it is a new
profession addressing the concern
for the advancement and the health
of the IT enabling the third-wave
society. It is the first profession of
the third wave.
The wave interpretation gets us
to the same place as the chasm
interpretation offered in [2]. To
cross the chasm separating inventors and visionaries from the multitudes of pragmatists, IT
professionals must connect with the
pragmatic customers’ concerns. To
function effectively in the third
wave, every professional, whether in
IT or not, must deal with customers through value-generating
relationships. In the third wave,
value-generating skills will distinguish professionals from technicians.
Customer-Centric
The term network in “Network
Age” is an apt play on words. It can
refer to the technology that interconnects computers. It can also
refer to the social webs of relationships among people. Relationships
are at the center of the third wave’s
system of wealth creation. In the
third wave, the customer, not the
producer, becomes the driving force
in business; and value, not the
amount produced, becomes the
measure of wealth. Value comes in
a variety of forms depending on the
interests of the customer—for
example, sales of tangible and
intangible products, services, cost
savings, increased identity, personal
convenience, reduction of complexity, and increased personal creativity. These new ways of creating
value are stimulating innovations in
e-commerce technologies.
Who is the customer of an IT
professional? We say the customer
is anyone to whom the professional
makes a value-producing promise.
This definition applies not only to
the ordinary notion of someone
purchasing a product or a service,
but also to users of software systems, to clients of IT professionals,
to students of IT teachers, and
team members with each other and
their team leaders.
Human-centered design, a twodecades-old concept now gaining in
favor among software developers, is
an excellent example of customercentric practice. It refers to a new
kind of relationship between the
software developer and the customer (or user). Many models of
software development are technology-centered. They emphasize a
formal process beginning with a
specification and ending with customer acceptance of a system meeting the specification. They usually
iterate through several versions of
the system, each reviewed by the
customer. Despite years of experience with these models, many software projects are cancelled or late,
many others leave their customers
complaining “It does what I said
but not what I want.”And many
systems have chronic flaws of the
kind Dertouzos documents. The
problem is that technology-centered models are not attuned to
customer value and do not
acknowledge that most developers
work in teams. In a human-centric
design process, the developer creates a succession of system versions
(beginning with prototypes) and
their specifications; but the developer’s focus is on working as an
effective team that understands
how the evolving system shows up
in the customers’ world, what
breakdowns it causes, and what
value it brings. The developer listens skillfully and co-designs each
improvement with the customer.
This process ends with a system
meeting the specifications and with
a satisfied customer.
Value Skills
To create value for customers, the
network-age professional needs two
kinds of knowledge. One is deep
technical skills, which is at the core
of any promise to a customer. The
other we call value skills, which
enables the professional to connect
with the customer and successfully
23
deliver the promise. Without
Value skills make good
Value skills
both, the professional will be
business. If every action
ineffective. With technical
within a business transacValue Skill Sets
Examples
skills alone, a person will be
tion brings value to the
Request, offer, promise, negotiate
Coordination
seen as a “nerd,” a low-value
customer, there is no
counteroffer, defer, decline, insist
technician, not a profeswaste. With no waste, the
Listen for customer concerns, articulate a customer gets results as
sional. Value skills are part of Customer
value proposition, make declarations, cothe core skills of an IT pro- Relations
quickly as possible and at
design value propositions with customers
fessional.
the lowest cost.
In industrial-age thinkValue skills are good
Maintain commitment records, allocate
Commitment
time and resources to each commitment,
Management
ing, knowledge is interfor engineering as well.
adjust load to one's capacity, communicate Each value skill set adds
preted as an asset—
with customers about progress, build trust
structured information that
to the quality of the result
through a history of kept commitments
can be managed in databy connecting the engiDeclare a mission, invite members, make
bases. In the Network Age, Teams
neer’s expertise to what is
commitments to the team leader, manage
knowledge is interpreted as
delivered to the customer.
commitments together, measure progress,
the capacity to perform
share assessments within the team, raise
The Dilemmas
effectively. Value skills conand resolve red flags
Answered
nect a professional’s techniUnderstand
levels
of
professional
Lifelong
Learning
Let’s see how customercal performance with the
competency, seek situations and mentors
centric orientation and
customer. In other words,
for advancement, obtain certifications of
without value skills, cusprofessional competence from recognized value skills address the
authorities
four dilemmas.
tomers will not assess you as
The IT skills dilemma
knowledgeable.
Listen for widely held concerns, follow
Business and
can be resolved by recogIn delivering their techni- Entrepreneurship and interpret trends the world, identify
nizing that the missing
cal expertise to customers,
innovative practices that can solve central
problems, build an offer, a business plan,
skills are embodied
IT professionals manage
and
a
team,
practice
within
a
code
of
ethics
skills—those learned only
commitments; build trust;
by extensive practice and
sell products and services;
demonstrated only in performance.
write and present proposals; orgaduction. This is not so in the NetEmbodied value skills enable the
nize, manage, and serve on project work Age, where every technical
professional to make embodied
teams; manage commitments to
professional must be minimally
technical knowledge available to
multiple customers; stay current
competent in relationships with
customers. Technical skills can be
with the technology; and start and
customers, internal and external.
run businesses [4]. The critical
Soft skills also suggests that tech- embodied through hands-on projects in university courses or
skills involved in doing this are
nical skills are difficult to learn and
through intensive training courses
listed in six categories in the
value skills easy. In fact, the value
from private vendors and corporate
accompanying table.
skills are every bit as difficult to
Many engineers and developers
learn as the conceptual skills our IT education departments. Value skills
use the term “soft skills” for the
curricula specialize in. One does not can be embodied through ongoing
leadership and professional mastery
value skills. This terminology comes learn value skills by studying them
workshops adjoined to regular curfrom industrial-age thinking, in
in a book or a lecture hall; one
which production-line workers did
learns them by practice, often under ricula or corporate training programs, and through coaching on
not interact with customers. The
the watchful eye of a competent
the job. The increasingly popular
soft skills were of little value to pro- coach [5].
24
November 2001/Vol. 44, No. 11 COMMUNICATIONS OF THE ACM
senior capstone project courses in
universities offer excellent settings
for teaching value skills.
The breadth-depth dilemma can
be resolved if every professional is
deep in at least one technical specialty and is competent in the team
skills. A team’s composition can be
adjusted to achieve the required
breadth and technical depth as
needed for its mission. In effect,
designing the team offers a way to
customize technical expertise to the
satisfaction of the team’s customer.
The design dilemma can be
resolved by human-centered development processes. The developer
learns the customer’s environment
as a framework for the customer’s
actions. The developer then evolves
a system (and its specification)
through a series of refinements of
rapidly produced versions evaluated
by the customer, all the while listening skillfully for what is of value
and concern to the customer. This
process continues after the system is
delivered, helping the customer
adapt changing markets and experience with the system. Extreme programming is an excellent example
of a technology that supports and
encourages adaptive software development of this kind [1].
The licensing dilemma is more
difficult to resolve, given the strong
feelings on all sides of the issue. Let
us suggest some distinctions from
the third-wave interpretation that
may shed light on the sources of the
dilemma. Many software engineers
view established, customer-oriented
professions such as medicine, law,
and some branches of engineering—formed in the Industrial
Age—as dinosaurs that are inappropriate models for software engineering in the Network Age.
Is this skepticism well-placed? In
those professions, certification and
licensing are accepted as two sides
of the same issue—raising public
confidence in the competence of
professionals and giving assurances
that professionals understand their
responsibilities. Licensing is a state
requirement; a professional cannot
practice without it. Certification is
a service offered by professional
societies and is often used to satisfy
components of state licensing
requirements. Medical professionals
developed their system of certification because of pressure from governments to minimize quackery;
doctors have since found patients
want them to be board-certified.
Law and engineering are similar.
No one believes doctors will cure
every disease, that lawyers will win
every case, or that engineers will
build bridges that never collapse.
Certification and licensing raise
confidence but do not guarantee
certainty of the outcome [7].
Many software engineers hold
the view that the software development process is ultimately a
formal derivation of a correct system from specifications. This
view inclines its adherents to
believe certification is a promise
that any system produced by a
certified software engineer must
be safe and reliable. No design
process, customer-centric or otherwise, can guarantee every system is 100% safe and reliable. A
customer-centric design process
can, however, reduce misunder-
standings about the safety and
reliability of a system.
Although it is characteristic of
the third wave that technologies
change rapidly, the rate of change is
limited by human willingness to
adopt and adapt [6]. Many professions are beset with rapid changes
in technologies and knowledge, but
they nonetheless keep their certifications up to date. We do not agree
that rate of technological change
make meaningful certification
impossible.
These potential answers to vexatious dilemmas demonstrate power
in the third-wave, customer-centric
interpretation of the world. The
third-wave perspective reveals the
importance of value skills for successful professionals. c
References
1. Beck, K. Extreme Programming Explained:
Embrace Change. Addison-Wesley, Reading MA,
1999.
2. Denning, P. Crossing the chasm. Commun.
ACM 44, 2 (Feb. 2001), 21–25.
3. Dertouzos, M. The Unfinished Revolution.
Harper Collins Business, 2001.
4. Flores, F. The leaders of tomorrow. In Beyond Calculation, P. Denning, Ed. Copernicus Books,
1997.
5. Heckler, R. Holding the Center. Frog, Ltd, 1997.
6. Odlyzko, A. The Myth of Internet Time. Tech.
Rev. 104, 3 (Apr. 2001), 92–93.
7. Parnas, D. Why software developers should be
licensed. Engineering Dimensions (May–June
2001), 36–39.
8. Toffler, A. and Toffler, H. The Third Wave.
Bantam Books, NY, 1990.
9. Wen, S. 2001. The Future of E-Commerce. AsiaPac Books, Singapore; www.asiapacbooks.com.
Peter Denning ([email protected]) is the
past president of ACM and the chair of the ACM
Education Board.
Robert Dunham ([email protected]) is the president of Enterprise Design.
© 2001 ACM 0002-0782/01/1100 $5.00
25
COVE R F E AT UR E
The Push to
Make Software
Engineering
Respectable
A recognized engineering profession must have an established body of
knowledge and skill that its practitioners understand and use consistently.
After 30 years, there is still a wide gap between the best and the typical
software engineering practices. To close this gap, we need a deeper
partnership among industry, academia, and professional societies.
Gilda Pour
San Jose State
University
Martin L.
Griss
Hewlett-Packard
Laboratories
Michael Lutz
Rochester
Institute of
Technology
oftware engineering (SE) is maturing as a discipline and profession, but three decades after
the first NATO Conference on Software
Engineering, it is still not regarded as a legitimate, respectable engineering profession. In
1995, Gary Ford and Norman Gibbs of the Software
Engineering Institute evaluated what it means for a
profession to be mature and how SE was doing.1 Their
extensive and fascinating study found that, relative to
other fields and engineering branches, most elements
that make SE a profession were quite immature.
Five years later, SE has countless practitioners (a.k.a.
software developers), thousands of articles, dozens of
conferences and workshops, and a respectable number
of education and training programs. The computer science (CS) and SE communities (educators, researchers,
practitioners, and professional societies) are further
along in defining a body of knowledge, code of ethics,
accreditation guidelines, and licensing programs.
But despite all this progress, SE, while recognizable, is
still immature—as evidenced by the significant gap
between vision, education, and standard practice. The
reasons are legion, but they boil down to one simple fact:
The field is still young. There just hasn’t been enough
time to gain widespread community consensus on issues,
to stabilize a core body of knowledge, and to develop a
large enough pool (several generations) of experienced
practitioners and educators. The rapid changes in this
field make the road to maturity even rougher.
Although we believe time will eventually mature SE,
a calculated push can accelerate the maturation process.
By “push,” we mean defining, accrediting, and evaluating new curricula that stress CS and SE fundamentals
S
0018-9162/00/$10.00 © 2000 IEEE
and practice, focus on lifelong learning and team experience, and increase the role of the professional societies
in accreditation, certification, and licensing efforts.
Although the push will not overcome all issues, it will
go far in addressing the most knotty ones.
Establishing SE programs is fraught with economic,
political, and pedagogic challenges—notably how to
divorce SE (or if it should be divorced) from existing
CS and computer engineering (CE) curricula. Any
solutions will have to come from deeper, more extensive industrial-academic-professional society partnerships. This is key.
We have spent some time considering the reasons for
SE’s immaturity. All of us are heavily involved in both
industry and academia and have been active in professional societies that aim to promote SE as a profession.
Promotion efforts are by no means limited to the US,
but because our experience is primarily with US activities, that is our focus in this article. Our main goal is
to explore, from a multifaceted perspective, why we
are where we are now and how we can move forward.
WHAT MAKES A PROFESSION MATURE?
As Table 1 shows, a mature profession must have
several key infrastructure components. In addition to
solid education programs, proper guidance from
industry and professional societies is critical to adequately prepare graduates for entrance to an SE profession. Accreditation of programs and possible
certification and licensing of graduates safeguard the
quality of any education and training program and
provide assurance that graduates meet and maintain
requisite levels of knowledge and practice.
May 2000
35
The various infrastructure components work
together to ensure that those entering the profession
become familiar with the currently accepted body of
knowledge and that they practice it in a manner consistent with the tenets of the profession. Research and
practice will evolve the body of knowledge; thus, practitioners must continue to enhance their skills and
practice as they gain enough experience to specialize.
Table 1 indicates the relative maturity of each infrastructure component, using Ford and Gibbs’ four-level
scale.1 However, the ratings do not reflect the consensus or breadth of compliance on a particular component, which tends to be low.
A major symptom of a not-quite-mature field—and
a frustrating one to address—is the wide gap between
education and practice and between best and typical
practice. Ongoing efforts in many maturity elements
are attempting to narrow these gaps.
PROFESSIONAL SOCIETIES
There are many engineering and CS professional societies, but the two most clearly identified with the SE profession are the Association for Computing Machinery
(ACM) and the IEEE Computer Society (IEEE CS).
Recently, the two joined forces to define SE as a profession, provide a code of conduct for professionals, and
formulate appropriate criteria for accrediting SE edu-
cational programs. The Software Engineering Coordinating Committee (SWECC) defines the scope of these
constituent tasks and monitors and coordinates the
working groups. SWECC membership is divided evenly
between the ACM and the IEEE CS—a balance that is
the hallmark of SWECC-commissioned activities. Table
2 lists some of SWECC’s current projects.
Although the ACM and the IEEE CS sponsor
SWECC projects, international participation has been
uncommonly strong. More important, professional
groups in other countries are beginning to take SE seriously: Graduates of UK computing programs that are
accredited by the British Computer Society are eligible
for Chartered Engineer status, and licensing for graduates of accredited SE programs in Australia is similar to licensing for other engineering graduates.
Canada also seems to be leaning toward similar treatment of SE as a profession.
Barriers. Activities to develop a body of knowledge,
accreditation, curricula, a code of ethics, and licensing
and certification are ongoing but are proceeding rather
slowly, staffed primarily by volunteers. Although the
IEEE CS and the ACM have actively promoted professionalism in SE since 1993, they do not agree on all
issues related to SE as a profession. Their positions on
licensing professionals and the pace of accreditation
are far apart, for example.
Table 1. How does software engineering rate on the maturity scale?
Infrastructure component of a mature profession
How software engineering measures up*
Recognized body of knowledge
IEEE-CS/ACM task force has released a first body of knowledge report with
consensus expected to take at least 4 years (level 2-3)
IEEE-CS, ACM, and SIGSOFT, active, a specific SE society under discussion (level 2-3)
Recently developed for SE, but not widely known or practiced (level 1-2)
Some SE BS degrees recently offered by CS departments and special SE departments in the US, the UK, Europe, Canada, and Australia (level 1-2)
Accreditation Board for Engineering and Technology (ABET) criteria for SE are in
place, which the Computer Science Accreditation Board (CSAB) will evolve
(level 1-2)
Several MSE programs, certificate short courses, and so on (level 1)
Professional society/societies
Code of ethics
Initial professional education system
Accreditation of professional education programs to improve
program quality and ensure some uniformity
Skills development mechanism for professionals
entering the practice
Professional development programs to maintain currency of
knowledge and skills
Certification of professionals administered by the profession
Licensing of professionals administered by government
authorities
Fragmented offerings—extension courses, seminars, professional conferences,
manufacturer certification programs (level 1)
Limited, inconsistent, technology-based; some certificates issued by manufacturers
(for example, Microsoft MCSE) (level 0-1)
Recently in the US (Texas), Canada, and the UK (level 1-2)
*Level 0 = Nonexistent.
Level 1 = Ad hoc, some form of element exists, but is not identified with the SE profession.
Level 2 = Specific, the element exists and is clearly identified with the SE profession.
Level 3 = Maturing, the element has existed for many years, is continually improving, and is under active stewardship of an appropriate professional
body.
36
Computer
Table 2. Software engineering projects jointly sponsored by the ACM and the IEEE CS through the Software Engineering Coordinating
Committee.
SWECC project*
Description and status as of April 2000
Software Engineering Body of
Knowledge (SWEBOK)
Software Engineering Code of
Ethics and Professional
Practice (SWCEPP)
Software Engineering Education
Project (SWEEP)
Create an index to the core body of knowledge (BOK), structure it, refine with specialist area committees, and
gain community consensus. — Phase two BOK draft (Stoneman) essentially complete.
Create an expanded and detailed code of SE ethics for educators and practitioners based on a shorter engineering
code of ethics. Provide case studies and training materials to help rapidly educate community. — Final draft
submitted for approval.
Define model accreditation criteria and sample curricula consistent with SWEBOK for BS and other SE education
programs. — SWECC approved accreditation guidelines in December 1998.
* More details and current status of key activities are described in the IEEE Software special issue on professional software engineering (Nov./Dec.
1999) and at http://www.computer.org/tab/swecc.
At the national level, the President’s Information
Technology Advisory Council (PITAC) report articulated the urgency of SE issues, and Congress approved
money for the National Science Foundation (NSF),
but these recommendations are not coordinated with
the societies, nor do final proposals really target funds
toward SE issues. Thus, progress is limited to the rate
at which society members and leadership can change.
Possible solutions. The societies, via member involvement, must strive to create a broader consensus on the
core of the SE profession. Perhaps the SE community
needs to address issues more aggressively. We could accelerate progress with full-time paid staff, for example,
rather than relying on the efforts of part-time volunteers.
Body of knowledge
In long-established professions, such as medicine,
law, or civil engineering, the body of knowledge was
codified as part of a long maturation process. To accelerate the maturation of new professions, professional
communities can consciously and explicitly define the
body of knowledge, rather than waiting for a natural
evolution. The codification proclaims what is unique
about the profession, demarcates the boundaries with
related professions, and significantly aids education,
certification, and licensing. Getting practitioners and
educators to agree on the core body of knowledge is
a key milestone in any discipline.
SWECC established the Software Engineering Body
of Knowledge (SWEBOK) project to collect and document the state of SE practice, using a three-phase
consensus-building approach.2 So far, the SWEBOK
project has identified and is structuring many topics
that texts and SE programs cover. Area committees
are expanding and distilling the material, using public reviews and surveys to reach consensus. The goal
is to categorize the material as core, advanced, or
research to determine what should be taught and
known at various professional development levels.
It will take at least four years to reach initial consensus, with ongoing refinement and evolution. The
first two phases—strawman and stoneman—are
essentially complete, providing a basis for significant
work on model curricula and certification.
Barriers. Achieving consensus on the common core
takes time, as will agreeing on related specialties. More
time will elapse before curricula incorporate this core,
especially when state education processes are involved.
Possible solutions. Some ongoing activities are
increasing awareness and buy-in. Adding workshops
and panels at major conferences could heighten
awareness even more. Support for innovative programs can accelerate the rate of change. Also, significant industry, government, and society sponsorship
and funding can help create sponsored and widely
advertised pilot or magnet programs to help jumpstart change, as well as offer fast-track certification
programs. Neither academia nor industry will change
overnight, however. Current mind-sets must change,
which may require new blood in upper ranks.
Code of ethics and professional practice
SWECC established the Software Engineering
Code of Ethics and Professional Practice (SWCEPP)
project to develop a code that the SE community as
a whole would find acceptable. An international
effort produced a detailed add-on to the standard
engineering code of ethics, which differs across countries.3 Some decry the extra detail as unnecessary,
claiming that we already have an adequate engineering code. We agree with others who believe the extra
detail and clarity are needed, both to enhance education and to clarify to SE educators and practitioners
that they are indeed engaged in an engineering effort
that affects society.
The ACM and the IEEE CS recently approved the
draft code, with the goal of having it recognized as
appropriate for all involved in SE. There are as yet no
May 2000
37
formal consequences for professionals who violate the
code. In other professions, a licensing board hears
accusations and can recommend disbarment (as in the
legal profession) or some other sanction. The code
could also be used in legal proceedings to determine
whether or not a software engineer has acted in accordance with professional norms and the accepted body
of knowledge.
Barriers. Awareness is the biggest problem. Many
of those involved in SE still have not heard of the draft
code or SWCEPP and are confused about how it
affects them. Only a handful of schools yet teach SE
ethics and professional practice.
Possible solutions. We need to have more articles and
studies at key conferences, active industrial lobbying,
wider-spread accreditation. Most of all, we need to
allow time for awareness and practice to grow. We
can then begin self-monitoring.
Education and accreditation
Many fledgling undergraduate SE programs exist
in the US and abroad,2,4 and we expect to see more in
the next few years. The sidebar “Elements of a Good
Software Engineering Program” describes what constitutes an effective program. Common to all programs is the recognition that SE is fundamentally
different from CS and CE. The sidebar “The Case for
Software Engineering Independence” describes some
of these differences.
The Software Engineering Education Project
(SWEEP)4 provides a detailed set of guidelines for SE
programs that will eventually seek accreditation.
SWECC officially adopted the SWEEP accreditation
guidelines in December 1998. Also in 1998, the
Computer Science Accreditation Board started a formal
integration of its operations and criteria with the
Accreditation Board for Engineering and Technology—
Elements of a Good Software Engineering Program
A comprehensive undergraduate SE program builds on a
traditional CS program, incorporating
various components adapted from typical
engineering education programs. It has
eight main elements:
• CS fundamentals provide the core
technical knowledge and skills about
software and hardware artifacts and
techniques to address key technical
problems. These include programming
languages, modeling, formalisms,
mechanisms, databases, operating systems, networking, algorithms, programming, and distributed systems.
• SE fundamentals provide the core
technical knowledge and process skills
and tools to create, manage, and maintain software and documentation and
deal with complexity and human
error. These include software process
discipline, life-cycle models, software
metrics and economics, architecture,
design methods and skills, design
inspections, testing, configuration
management, and standards.
• Engineering practice and ethics provide an understanding of general systems principles, economic and
functional trade-offs, the implication
38
Computer
•
•
•
•
•
of building artifacts for use, and how
engineers serve society and balance
their responsibilities to their employers, their customers, and society.
Effective communication and teamwork skills provide knowledge and
skills in working with diverse human
beings—from peers to management
and customers.
Experience in an application domain
that exposes students to real-world
problems. This element is key to
grounding and consolidating core
knowledge and skills in a particular
area.
A significant team project exposes students to issues such as requirements
change, project management, configuration management, use of tools,
and team dynamics. The project is
typically run under somewhat controlled conditions in a laboratory or
studio setting and can be completed
in assigned time, with mentors oriented to the educational experience.
Experience in some industrial setting,
perhaps through a required internship
or co-op program, provides even more
exposure to real-world issues, people,
pragmatics, and the vagaries of real
projects under real-time pressure.
Tools for effective lifetime learning,
including experiences that rehearse
how to seek, evaluate, and use information not directly provided by
assigned texts and lectures. For
example, projects might require students to find information on the Web
or in the library, evaluate and integrate possibly conflicting materials,
and attend and report on a conference and a tutorial. Students might
also participate in an ongoing “journal club” or “research seminar,”
where they would read, analyze, and
compare many papers.
Because software technologies crop up
quickly and because IT’s role is constantly
changing, any SE program must emphasize lifelong learning. Numerous phenomena and issues (open source, the Web,
component- and service-oriented computing) will affect SE, and SE professionals must be able to understand and
evaluate those effects.
Also, different parts of software construction require a different mix of skills:
For some segments, a laboratory-style
team project is important (do an experiment, measure it, evaluate it); in others a
studio approach is better (do creative
work in some medium under the watchful eye of a mentor or instructor).
a merger that will unify the criteria and process used to
accredit SE programs. SWEEP will use the accreditation
guidelines as a specification to design one or more model
curricula for SE, leveraging the initial work of SWEBOK
and the Computer Curriculum 2001 task force (recently
formed by the IEEE CS and the ACM to review and
upgrade the 1991 computing curricula), among others.
In other countries, the development of undergraduate SE programs is even further along. Australia and
the UK, for example, established initial programs in the
early 1990s. As a result, both countries have accreditation criteria for SE programs, and graduates have
equal professional standing with those in more traditional engineering disciplines. India’s software indus-
try is also growing rapidly, in large part because of the
disciplined engineering approaches used in Indian firms.
Barriers. Establishing SE in undergraduate (or even
graduate) curricula is rarely straightforward. Several
educational institutions, including the Rochester
Institute of Technology (RIT), have successfully established an undergraduate SE program, but one model
is unlikely to work for all institutions. The California
state university system, for example, must ensure that
appropriate two-year programs are in place in parallel with introducing the four-year degree.5
A critical problem is finding faculty interested in
and capable of teaching SE because few CS faculty
have enough real-world SE experience. Teaching SE
The Case for Software Engineering Independence
This definition focuses on acquiring and
applying technical standards, but does not
address ethical standards.
entists have fundamentally different goals.
As David Parnas says, “Scientists learn science plus the scientific methods needed to
extend it,” and “Engineers learn science
plus the methods needed to apply it.”2
Debates about the relationship between
SE and CS date back to the late 1970s,
when Anthony Wasserman and Peter
Freeman3 identified five key areas that
provide the foundation for SE: computer
science, management, communication
skills, problem solving, and design
methodology. Mary Shaw,4 Bill Wulf,5
and Parnas2 highlight the intimate connections between (software) science and
engineering, and discuss the costs and
benefits of separating computing into distinct science and engineering disciplines.
Despite the political and emotional reasons to claim that SE should be just a part
of CS and CE, the strong differences in the
goals and style of education—and the
need for professional software engineers—motivate distinct SE programs.
Learning and building
The ACM/IEEE CS Task Force on the
Core of CS for Computing defines the computing discipline as “the systematic study
of algorithmic processes that describe and
transform information: their theory, analysis, design, efficiency, implementation, and
application.” Thus, the scientific question
underlying all of computing is “What can
be (efficiently) automated?”1
Software engineers and computer sci-
Art and science
There is some controversy about what
kind of engineering discipline SE actually
is and how it differs from CS. Distinct factions in the software community believe
that creating software is primarily an
artistic endeavor; others consider it more
mathematical, while others believe that
process and method are key. But both art
and science are at the core of engineering,
as attested to by this quote from Henry
Many institutions tend
to think of software
engineering (SE) as just
a kind of computer science (CS) or computer engineering (CE). This leads to
problems because the disciplines differ in
both focus and approach: SE studies software; CS and CE study primarily hardware, algorithms, and languages. CS and
CE develop knowledge; SE applies that
knowledge to engineer high-quality software systems. The IEEE Standard 610.12
definition of software engineering states:
(1) The application of a systematic,
disciplined, quantifiable approach to
the development, operation, and maintenance of software; that is, the application of engineering to software, and
(2) The study of approaches as in (1).
Petroski, a noted civil and environmental
engineer and author of the acclaimed “To
Engineer is Human”:6
The conception of a new structure can
involve as much a leap of the imagination and as much synthesis of experience and knowledge as any artist is
required to bring to his/her canvas or
paper. Once the design is completed, it
must be analyzed by the engineer as scientist in as rigorous an application of
the scientific method as any scientist
must make.
References
1. P.J. Denning et al., “Computing as a Discipline,” Comm. ACM, Jan. 1989, pp. 9-23.
2. D.L. Parnas, “Software Engineering Programs Are Not Computer Science Programs,” IEEE Software, Nov./Dec. 1999,
pp. 19-30.
3. A.I. Wasserman and P. Freeman, “Software Engineering Concepts and Computer Science, Curricula,” Computer,
June 1977, pp. 85-91.
4. M. Shaw, “Prospects for an Engineering
Discipline of Software,” IEEE Software,
Nov. 1990, pp. 15-24.
5. W.A. Wulf, “Are We Scientists or Engineers?” ACM Comp. Surveys, Mar. 1995,
pp. 55-57.
6. H. Petroski, To Engineer Is Human: The
Role of Failure in Successful Design, Vintage Books, N.Y., 1992, p. 40.
May 2000
39
requires competence in SE life-cycle processes
and so on—things that do not “feel like” CS.
Compounding the problem is the tradition of
basing faculty hiring on the applicants’ research.
Typical systems- or theory-oriented colleagues
see SE research and practice as fuzzy, decrying
the lack of evidence that SE principles and techniques actually work. SE research that could
validate efficacy, such as metrics, management,
teams, processes, or methods typically involve
social-science-like experiments, which bothers
many traditional CS researchers. As a result,
new or prospective SE faculty often face skeptical or even hostile colleagues.
Another sensitive issue is the independence of the
SE program from CS, CE, or any other department.6
Many institutions resist SE independence, remembering the battle over the EE-CS split. The concern is that
SE is an attractive combination of engineering and CS,
and that traditional programs will lose resources and
students as a consequence.
Possible solutions. Sometimes a partnership with CE,
industrial engineering, management, or business can
provide the ideal SE instructional team. An interdisciplinary program that incorporates the strengths of
both CS and CE can result in a more stable and harmonious environment for both students and faculty.7
Industry and NSF advocacy and funding of SE programs, projects, or chairs can help increase interest
and respect. If industry demanded a more standard,
comprehensive, and accredited SE education program
(as it does for other engineering professions) and was
willing to invest in developing such a program (not
just an SE training program to address a programmer
shortage), more institutions would comply.
In several regions, local industry does work closely
with local educational institutions to help motivate and
drive change, but for the most part, industry support
and encouragement is still lacking. In all US cases of successful industry support, the program resulted from a
small, motivated contingent of faculty who established
credibility with the upper administration. Examples are
RIT’s co-op program,7 the University of Utah, Georgia
Tech, and the University of California at Santa Cruz.
A challenge to proponents of these programs, as well
as to researchers, will be to prove that students of these
programs produce better systems more economically,
relative to untrained students. Anecdotal evidence from
the RIT co-op program is encouraging, but it is only a
small step in the right direction. True validation of this
hypothesis will require cooperative work between
academia and industry to gather and analyze data.
A challenge to
proponents of
accredited SE
education programs
is proving that their
graduates produce
better systems more
economically.
Skills development
SE has many facets, and different training will be
required for different software roles and specialties,
40
Computer
including, but not limited to, architect, system engineer, design engineer, test engineer, quality engineer,
maintenance engineer, programmer, and technician.
Different problem domains will surely require different specialist skills; consider the difference in content
and scale between architecting and developing the user
interface (UI) subsystem for a large-scale, multiuser
computer game versus a UI system for a reactor or airplane controller. Even more different are the skills
needed for UI design versus those for database or operating system development.8 Programmers must know
specific languages and associated tools, and be familiar with the skills needed to apply coding guidelines
and standards. A senior software engineer must have
both broad technical knowledge of CS and SE principles and be able to apply technical and managerial
practices that cover everything from project feasibility to product delivery and ongoing support.
Just as chemical and electrical engineering are
treated as distinct fields within “physical engineering,”
so we could distinguish, educate, and certify wellunderstood, distinct specialties in SE, such as compilers, databases, and operating systems.8
Barriers. SE covers a vast range of subdisciplines,
and some senior members of the field propose that
“SE for _____” is how we should move forward.
However, there is yet no consensus on the core areas,
nor on which parts of the core apply to which subdisciplines. Some core guidelines, such as design and
code inspections, are probably good for all parts of
SE, but some faculty are adamant that good practices
like code inspections do not belong in CS. This makes
it hard to find a place for these practices if the institution does not endorse a separate degree for SE.
Possible solutions. SWEBOK and SWEEP will help
distinguish core, advanced, and special areas and
define which curricula contain which parts. This incremental strategy will help support an initial consensus
and then broaden that consensus as the experience
base widens. We must agree on the body of knowledge and drive model curricula that incorporate core
elements and meet accreditation guidelines. We need
more effort than current part-time volunteers can provide to make this happen. Greater industry involvement will garner interest, help shape programs, and
provide skilled practitioners, along with opportunities to study real-world problems. Fortunately, the
SWEBOK project has significant industrial sponsorship.
Lifelong, self-directed education is also important. In
a world of free agents and contractors, software engineers must pick up—on their own—many of their specialty skills. Commercial certification (MCSE and
Cisco CCIE or CCNA, for example) is valuable, and
classes from university extension or private institutions
are key to keeping skills current and marketable.9
Licensing and certification
Licensing and certification is a significant (but not
essential) aspect of an engineer’s professional stature.
Society increasingly depends on software for a wide
variety of mission- and life-critical systems. Concerns
are escalating about liability and contracts that call for
a certified level of expertise in the software professional. The furor over Y2K has certainly raised awareness of the potential impact of SE design decisions.
The degree of licensing in practice varies from profession to profession. Licensing seems to pertain mostly
to those who must sign off on a contracted deliverable
or who do bonded private consulting. Most engineers
who work for companies are not legally required to be
licensed, though many civil and electrical engineers will
do so to help advance their careers.
Accreditation, licensing, and certification mechanisms together aim to protect the public’s health,
safety, and welfare by providing some assurance that
a practitioner is competent in the certified or licensed
specialty. Licensing also protects members of the profession, both by limiting the number of professionals
so licensed and by establishing norms that protect
individuals and groups in some liability suits. The legislative bodies of all 50 states and the US territories
have created statutes that require an engineer performing work for the general public to be licensed by
the state or territory in which the work is being performed. The laws require licensing applicants to meet
certain standards of education and work experience
and to pass a series of examinations.
Barriers. The SE community has mixed opinions
about whether professional licensing at this time is a
good idea.10,11 Does it make sense to license software
engineers before making an SE body of knowledge
available? The ACM recommended against licensing
on the basis of advice from a blue-ribbon ACM committee. This is largely a political issue—people are
afraid of being controlled, of limiting access to a scarce
labor pool, and of legislating best practices.
Many feel that licensing is premature given the
SWEBOK’s current state and the absence of corresponding accredited education programs. They doubt
what SE practice can actually guarantee. Their concern is that best current SE practices do not result in
systems with the same reliability and safety that other
engineering disciplines produce.
Possible solutions. The Texas State Board of Engineering
Licensing uses an equivalency process to award a professional SE license without examination.12 Following its law
and tradition, Texas requires licensing only for engineers
whose services are publicly available. Still, the ramifications of any licensing have led to serious debates within
the computing community, which will take time to resolve.
Many believe that other states eventually will follow
Texas. But regardless of the outcome, society and lawsuits
will dictate that we proceed incrementally, starting
in safety-critical industries. Many believe that starting licensing now will at least improve the state of
the practice and reduce error. Licensing efforts are
also under way outside the US, including in the UK
and Canada (British Columbia and Ontario).
A SUSTAINED PARTNERSHIP
Involving industry
more in SE teaching
and research
requires proactivity
on both sides.
A common theme in solutions to SE maturity
barriers is to involve industry more in SE teaching and research. To do so, we need proactivity
on both sides. A deep, sustained partnership will
encourage the development of more effective SE education programs and ensure that university research
will have more access to and influence on industrialscale development. We get the best of both worlds:
industrial involvement and advice and academia’s
long-term view of what makes a quality education.
This emphasis on the long-term view is what differentiates the partnership in education from a training
exercise.
The partnership should focus on helping universities
arrive at the appropriate balance between fundamental knowledge and its engineering application. Because
many large companies have had to mount significant
SE training programs—in large part because of the
dearth of SE education in college, they should be more
than willing to assist in nurturing SE programs that
emphasize developing core skills. Increased collaboration has many immediate benefits, such as reduced training costs for companies and more focused SE research
for institutions. Increased collaboration between academia, engineering institutes, and industry would substantially reduce serious mismatches in expectations.
Indeed, effective industry involvement is not trivial.
Goals and investments must match—typically, academia wants to train in fundamentals and lifelong learning, while industry focuses on acquiring skills to fill an
immediate need.
The sidebar “Building a Strong Industrial-Academic
Partnership Now” lists some steps each side can take
right away to begin forging this partnership.
oftware engineering is an emerging profession
that will greatly mature within the next decade.
The SE community must define, accredit, and
evaluate new curricula, stressing lifelong learning, significant team experience, and practical theory and fundamentals. We must also address the lack of consistency among the undergraduate SE programs that
do exist. Educators do not yet agree on the core elements to teach; without systematic accreditation and
licensing, there is less pressure to quickly adapt programs to increase consistency and incorporate new
knowledge and skills. Academia is slow to incorporate
practices that work well (for example, inspections).
S
May 2000
41
Building a Strong Industrial-Academic Partnership Now
Companies and academic institutions can
take several immediate steps to align their expectations for the
software engineering profession.
If you are in industry:
• Develop relationships with selected
universities and SE faculty.
• Provide support for development of
educational programs rather than just
training programs. This means preparing students for an SE career, not just
a job. You could offer guest lectures
and mentoring, for example, or participate on an SE advisory board.
• Provide input to the schools on how
their graduates fare in industry.
• Create more exciting and educationally aligned internship programs.
• Provide financial support. This is important, not only because of its direct
value, but also because it is a measure
of respect. Even if you can’t fund a
big project, you can fund a small collaborative research project and invite
the faculty and students to work with
you. Be sure to provide access to real
data and project records. Sanitize the
data and records to remove confidential information as needed or
work under nondisclosure agreements. Work closely with academic
colleagues to help them produce valued publications that respect your
company’s need for confidentiality.
• Help clarify and articulate your company’s position on longer-term professional training versus short-term
skills acquisition and how this affects
your relationship with educational
institutions.
•
•
•
• Convince your colleagues of the efficacy of good SE practice. Show them
that a project with good design,
construction, quality assurance, and
so on is better than a thrown-together
project.
• Explain the implications and opportunities of accreditation and licensing and
what effect they could have on expecta-
Acknowledgments
We greatly appreciate the excellent suggestions by
colleagues who reviewed an earlier draft of this artiComputer
•
If you are in academia:
Too often, it disdains considering the gap between best
and current practices—a significant education and
research issue. Industry, on the other hand, is far too
slow to adopt practices validated by research and experience or to invest in reducing the practices gap.
Society and industry have tolerated the consequent
poor quality and practice because of the shortage of
trained practitioners and the dearth of experienced managers who can recognize and sell good practice. The lack
of a mature infrastructure and the influence of societal
and business pressure make the widespread recognition
and adoption of best practice slow and sporadic.
Unfortunately, even if initial professional education more
quickly tracked the emerging body of knowledge, many
areas deemed critical would still be excluded. Internetbased e-commerce technology, for example, is moving
so rapidly that only a handful of institutions have tried
to offer it—even industry has a hard time keeping up.
Industrial-academic partnerships in education and
research will enable practitioners to learn and hone a
broader range of skills and practices. The efforts we
have described will significantly drive the maturation
of SE as a profession, but we will need to sustain and
build on them to bring SE closer to its ultimate goal
of respectability. ✸
42
•
•
tions for a CS/SE degree. Teach an ethics
module. Include information about the
Software Engineering Coordination
Committee (SWECC) and its projects.
Integrate some SE into any software
course you teach, and help your colleagues, especially those building
large systems, inject some SE principles into their projects. Be sure to
note any successes, however small.
Have your SE project classes help the
software efforts of non-SE colleagues.
Include industrial SE practitioners as an
advisory board and as guest lecturers.
Advocate required industrial internships for students. Monitor the
results and benefits.
Take minisabbaticals in industry, even
if the hosting corporation isn’t funding it. Invite industry experts in for a
sabbatical, a mini-sabbatical, or to be
a “software artist in residence” to
inspire and mentor students and staff.
Develop and offer collaborative educational programs with colleagues in
computer engineering, business management, or industrial engineering.
cle: Patricia Collins, Paula Hawthorn, Robert Kessler,
Joe Podolsky, and Anthony Wasserman.
References
1. G. Ford and N.E. Gibbs, “A Mature Profession of Software Engineering,” Tech. Report CMU/SEI-96-TR-004,
Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh,
1996.
2. P. Bourque et al., “The Guide to the Software Engineering Body of Knowledge,” IEEE Software, Nov./Dec.
1999, pp. 35-44.
3. D. Gotterbarn, “How the New Software Engineering
Code of Ethics Affects You,” IEEE Software, Nov./Dec.
1999, pp. 58-64.
4. G.L. Engel, “Program Criteria for Software Engineering
Accreditation Programs,” IEEE Software, Nov./Dec.
1999, pp. 31-34.
5. G. Pour and A. Hambaba, “An Undergraduate Software
and Information Engineering Curriculum under Development at San Jose State University,” Proc. Frontiers in
Education (FIE) Conf., IEEE CS Press, Los Alamitos,
Calif., 1999, CD-ROM.
6. D.L. Parnas, “Software Engineering Programs Are Not
Computer Science Programs,” IEEE Software,
Nov./Dec. 1999, pp. 19-30.
7. M.J. Lutz and J.F. Naveda, “The Road Less Traveled: A
Baccalaureate Degree in Software Engineering, ” Proc.
28th SIGCSE Technical Symp. Computer Science Eduation, ACM Press, New York, 1997, pp. 287-291.
8. M. Jackson, “Will There Ever Be Software Engineering,”
IEEE Software, Jan./Feb. 1998, pp. 36-39.
9. A. Wasserman, “Software Processes and Software Professionals in the 21st Century,” Cutter IT J., Sept. 1999,
pp. 17-23.
10. M.L. Griss, “Letter from the SIGSOFT Executive Committee,” ACM SIGSOFT Software Eng. Notes, Sept.
1998, pp. 1-2.
11. J.R. Speed, “What Do You Mean I Can’t Call Myself a
Software Engineer?” IEEE Software, Nov./Dec. 1999,
pp. 45-50.
12. D.J. Bagert, “Texas Board Votes to License Software
Engineers,” ACM SIGSOFT Software Eng. Notes, Sept.
1998, p. 7.
Gilda Pour is a professor of software and information engineering at San Jose State University, where
she helped develop a software and information engineering curriculum. She develops and teaches courses
in object-oriented and component-based software
engineering and distributed object computing in both
industry and academia. Her industrial and research
experience is in object-oriented component-based
enterprise software engineering, with current emphasis on automated generation of Web-based enterprise
applications. Pour received a PhD in computer science/software engineering from the University of
Massachusetts. Contact her at [email protected].
Martin L. Griss is principal laboratory scientist for software engineering at Hewlett-Packard Laboratories,
where he has researched software engineering processes
and systems, systematic software reuse, object-oriented
development, and component-based software engineering. He created and led the first HP corporate reuse
program and participated in the development and execution of the HP corporate software initiative. Griss
received a PhD in physics from the University of Illinois. He is an adjunct professor at the University of Utah
and a member of the ACM SIGSOFT Executive Committee and SWEEP. Contact him at [email protected].
Michael Lutz is Motorola professor of software engineering at the Rochester Institute of Technology,
where he heads RIT’s undergraduate software engineering program. His interests in software architecture, software design, and lightweight formal methods
led to development of core software engineering
courses in these areas. Lutz earned an MS in computer
science from the State University of New York at Buffalo. He is a member of the editorial board of Computer and of the IEEE CS Educational Activities
Board. Contact him at [email protected].
Set
Industry
Standards
Our members write
important IT standards,
including IEEE 802.3,
the standard for Ethernet,
the most widely deployed
LAN. But technology
networks are not the
only kind of standards
developed here.
Grow
Your Career
Find Out How @
computer.org/
standards/
Did You
Know?
Right now, over 200
Working Groups are
drafting IEEE
standards.
May 2000
43

Aspectes humans i socials

Transcription

Similar documents

Perros RSG86 - entrevista

To View Article

PDF Link - Revista Latinoamericana de Metalurgia y Materiales

2015 -16 Dress Code Update

escapulario?

TT Engineering Mexico - Tri

Dibujos de Eduardo Arroyo Fotografía de Michal Novak

22, 23 y 24 de Abril Lima