Communications of the ACM

Communications of the ACM

Viewpoint: Taking the Lead in Licensing Software Engineers

By Donald J. Bagert
Communications of the ACM, April 1999, Vol. 42 No. 4, Pages 27-29
10.1145/299157.299163
Comments

It was inevitable.

In the mid-1970s, the term "software engineering" became a permanent part of the computing lexicon. For instance, ACM started the Special Interest Group on Software Engineering (SIGSOFT), and ACM Software Engineering Notes and IEEE Transactions on Software Engineering were first published. From that point on, there has been a steady increase in the use of the job title "software engineer."

Since there are engineering licensing boards legally bound to restrict the use of the term "engineering" according to specific guidelines in almost all U.S. states, it was only a matter of time before one of those boards decided to address the matter of licensing software engineers. This was part of the reason that ACM and IEEE-CS established a Joint Steering Committee for the Establishment of Software Engineering as a Profession (see www.computer.org/tab/seprof) in 1993, despite the fact that many members were and are opposed to the concept of licensing.

However, for various reasons, most of the work of the steering committee progressed slowly over the next four years. In the meantime, various companies started certification programs, which, if completed, would supply professionals with titles such as "certified system engineer" or "network engineer"; this caused the engineering boards even more concern. By 1997, the Texas Board of Professional Engineers had started seriously considering the possibility of licensing professional engineers (PEs) in software engineering. At about the same time, another event occurred that would have repercussions on licensing: ABET, the accreditation board for engineering programs in the U.S., asked IEEE for advice on guidelines for accrediting software engineering programs, which have steadily grown in number over the years.

There is a strong relationship between engineering accreditation and licensing in the U.S.; a graduate from an accredited engineering program is expected to have the knowledge and skills to be able pass some version of the Fundamentals of Engineering licensing examination. Therefore, some degree of compatibility between accreditation guidelines and the licensing exam content is needed. Initially, some members of the Texas Board expected that software engineering would be classified as a sub-area of electrical engineering. Also, IEEE (not IEEE-CS) began working on ABET's request through its Engineering Accreditation Committee. At this point a scenario in which software engineering accreditation and licensing guidelines would be developed mostly by electrical engineers was very possible. An example of how this might have worked can be found in the discipline of computer engineering. Even though computer science and computer engineering were defined as having a common core in Computing Curricula 91, the latter field is now closely coupled with EE. The accreditation guidelines for electrical and computer engineering are virtually identical: computer engineers must take EE licensing exams in most states, and most computer engineering programs are in the same department as EE.

This is not intended to blame either EE or the engineering field as a whole. However, it does demonstrate what might have happened if the software profession had not gotten involved in the accreditation and licensing processes in late 1997 and 1998. First, after some discussions between the Texas Board and a cross-section of the state's computing community, the Board formed a software engineering advisory committee that included Dennis Frailey, co-chair of the previously mentioned software engineering Joint Steering Committee. The result was a set of licensing guidelines that included a definition of software engineering that reflects the state of the discipline (www.main.org/peboard/softw.htm). ACM and IEEE-CS subsequently agreed to help write the first licensing exams, either for the National Council of Examiners for Engineering and Surveying (if they decide to start offering software engineering examinations in the near future), or for the Texas Board (if they do not). Several thousand practitioners in the field being tested are asked to review such exams, so it is expected that ACM and IEEE-CS members working in the software engineering field will be contacted for this purpose.

---

Software engineering needs to be accepted by the engineering community, and the computing community needs to accept software engineering as a discipline.

---

With regards to accreditation, an IEEE-CS/ACM Education Task Force developed their own set of proposed undergraduate software engineering accreditation guidelines (www.computer.org/tab/seprof/Accreditation.html). These guidelines were not integrated into the short formal guidelines passed by the ABET Board of Directors on Oct. 31, 1998. However, on that same date, ABET and CSAB (the accreditation board for computer science) agreed to merge over the next two years, so the two organizations will be working together to implement the new software engineering guidelines, to be administered under the Engineering Accreditation Commission of ABET. The more detailed IEEE-CS/ACM guidelines will likely be a key resource for ABET and CSAB in their implementation efforts.

So cooperation between representatives of both the computing and engineering disciplines has provided a framework for the licensing of software engineers and the accreditation of software engineering degree programs that is satisfactory to all involved. However, that does not mean that work related to accreditation and licensing is complete. Among the ongoing tasks are:

The software engineering body of knowledge (SWEBOK) needs to be identified. An IEEE-CS committee has developed a SWEBOK "Straw Man" document (available at www.lrgl.uqam.ca). Feedback from software professionals is needed for this project, which will be essential to the formulation of the licensing exams.

Undergraduate software engineering curriculum models need to be formulated. The curriculum affects and is affected by accreditation criteria, which in turns affects the licensing exam content. The IEEE-CS/ACM Education Task Force will be working on such a curriculum model, using the software engineering accreditation guidelines as a requirements document for such a curriculum. In addition, the Working Group on Software Engineering Education and Training is developing Guidelines for Software Engineering Education (the current draft is at erau.db.erau.edu/~hilburn/se-educ/guide.html), which when completed will provide recommendations for software engineering education throughout computing curricula. Both projects would benefit from as much reviewer input as possible.

Software engineering needs to be accepted by the engineering community, and the computing community needs to accept software engineering as a discipline. There are at least two reasons that make software engineering a discipline different from any that have preceded it. First, the engineering product (software) is a non-physical entity, which means it's not directly affected by the physical or the engineering sciences. Instead, software engineering has a theoretical foundation based almost entirely in mathematics. This means that licensing exams for software engineers should be somewhat different from the norm, which of course is of a concern to many engineers.

The second unique feature of software engineering is that it was developed not as an outgrowth of an existing engineering discipline, but within the computing field. This means that engineers and computing professionals have not interacted much, especially in academia, which leads to some distrust on both sides. Many engineers and computer scientists are also concerned about the validity of software engineering as an engineering discipline. The strongest arguments in favor of its being considered an engineering discipline are that the development process is virtually identical to that of other engineering products, and that the expectations of customers with regards to reliability, usability, economy, and efficiency are also similar. However, there is much work to be done by both communities to find a common ground so they can work together.

The issue of software application domains must be addressed. Software developers work in a wide variety of domain areas, such as real-time and embedded systems, information or financial systems, user interfaces, and networks (the examples provided in the Texas Board definition are available at www.main.org/peboard/softw.htm). This means that undergraduate curricula may need to be tailored to a particular application area, and that licensing exams may also require a specialization area. (A recent model suggested by Mike McCracken of Georgia Tech and others is one similar to that used by the medical industry, involving student rotations in different departments, and eventual specialization in a particular area such as emergency medicine. Part of a software engineering licensing exam might therefore focus on a specialization area.)

Note that virtually nothing has been said about the benefits and drawbacks of licensing itself (there are many of each) nor about who will need to be licensed (not everyone). Those are important issues, but the primary messages of this "Viewpoint" are:

• The licensing of software engineers has already started, and will likely spread to most of the U.S.
• Licensing will directly or indirectly affect the development of all new software professionals in the years to come.
• The computing community should continue taking the lead in both licensing and accreditation, and everyone needs to get involved. (For those of you that want to know how to get involved, contact Dennis Frailey at [email protected].)

If computing and engineering professionals can work together on software engineering guidelines, and produce a result that is satisfactory and beneficial to both parties, it could be the best thing that ever has happened to either field, and could provide a powerful foundation for the future.

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 1999 ACM, Inc.

---

No entries found