National Society of Professional Engineers Professional Engineers in Industry (PEI)1420 King StreetAlexandria, VA 22314http://www.nspe.org/peipei@nspe.org

Task Force Report and Recommendation for Computer and Software Engineering Licensure Path

August 10, 2006

Prepared by the Professional Engineers in Industry - Computer and Software

Engineering (PEI-CSE) Task Force for the NSPE Licensure & Qualifications for

Practice (L&QP) Committee

Executive Summary

The Computer and Software Engineering Task Force1 within Professional Engineers in Industry (PEI) assessed how National Society of Professional Engineers (NSPE) should consider the relationship of Computer Engineering and Software Engineering as disciplines for licensure. Software Engineering, like other engineering disciplines, now has its curriculum accredited by ABET. Computer Engineering has been a discipline accredited by ABET for several years.

The Task Force reviewed the current National Council of Examiners for Engineering and Surveying (NCEES) structure and available examinations for the Principles and Practice of Engineering with respect to current NCEES exam specifications. Also, we considered out-of-the-box approaches to examinations besides what is being offered by NCEES. For example, we considered the Certified Software Development Professional (CSDP) offered by the IEEE Computer Society and a new licensing effort by the Texas Board of Professional Engineers currently under revision by their Software Engineering Task Force.

The PEI Task Force evaluated how Computer and Software Engineering fits within the current engineering process. We considered how the courses for Software Engineering, Computer Engineering, Computer Science and Electrical Engineering are taught at accredited Universities, and how these types of jobs are being performed in U.S. industry. The Task Force felt it was important to understand the relationship among other related subjects taught in the University.

The Task Force developed three recommendations that PEI supports as conveyed by this Task Force. Each recommendation has been thoughtfully considered. Deference in each case was given to expedience and the path that would lead to the widest discipline coverage.

Summary of PEI Recommendations

Recommendation #1 PEI urges NSPE Board of Directors (BOD) to approve the position in this Recommendation, and request NCEES to develop a Computer and Software Engineering Principles & Practice Exam. Note: PEI felt that the NSPE Licensure & Qualifications for Practice Committee review the Recommendation and draft the language to be used in the formal request made to both the NSPE BOD and the communications to NCEES.

Recommendation #2 PEI urges NSPE to lobby at least 10 State Licensing Boards to collectively request NCEES to begin the process of developing a licensure path. We would expect that an NSPE Program Manager be designated to coordinate the timing between Recommendation #1 and Recommendation #2.

Recommendation #3 PEI suggests that the NSPE BOD’s issue a vote of approval for the finalized Software Engineering licensure path being developed by the State of Texas Licensing Board.

1 Formerly the Software Engineering Task Force, changed in Summer 2006 based on the research conducted in this Recommendation.

1

Introduction

One of the benefits of the Professional Engineering (P.E.) licensure process is that it establishes a minimum competency level ensuring that the P.E. is properly trained in mathematics, physics, chemistry, and other engineering sciences. It indicates that the P.E. has a solid understanding of both the practical and theoretical aspects of engineering in their field of specialization. Licensure also promotes ethics and accountability among practitioners. Additionally, the most important benefit of a Professional Engineer license is that it is legally required by all states to call oneself an “Engineer” when offering to provide engineering services.

Professional Engineers in Industry (PEI) has spent the past several years evaluating the merits of creating a path toward Computer and Software Engineering licensure as an option for P.E. candidates in the United States. This important area of industry lacks a viable path toward licensure. The outcome was to form the Software Engineering Licensure Task Force. The Task Force was established by then PEI Chair, Douglas Benner, P.E., F.NSPE, in 2001. The Task Force has had many qualified members serving upon it from both industry and academia that provided input for this recommendation. The current and past members are listed in Appendix C.

The Task Force consulted with individuals knowledgeable about the National Council of Examiners for Engineering and Surveying (NCEES), who administer examinations in most states throughout the country including Guam, Puerto Rico and District of Columbia. NCEES also develops a majority of the engineering licensure exams offered in the United States.

The Task Force’s approach is not to dwell on the aspects involved with health, welfare, financial projects, information security issues, and other life and non-life safety concepts of Computer and Software Engineering. Rather these well-researched topics are listed in Appendix B or available upon request for additional reading2. Rather, the Task Force addresses how to get from Point A to Point B in providing Computer and Software Engineers a path for licensure.

Background

Through its research, The Task Force found that the NCEES has made positive strides with the Electrical & Computer Engineering Exam they currently provide. This exam was restructured in early 2000 and made available at that time to P.E. candidates. The new format allows a candidate to select from one of three depth modules which includes Computers.

Current Path

The current structure of the Electrical & Computer Engineering Principles & Practice Exam consists of two 4-hour modules. The content of the A.M. session, called a Breadth Module, is shown in Table 1. Each of these subjects is required by everyone taking the Electrical and Computer Engineering Exam, or Breadth Module. The P.M. session, called a Depth Module, provides for an option of one of three 4-hour modules: Computers; Power and Electronics; and Controls and Communication. As shown in Table 2 for the

2 See Appendix B – References: [4], [5], [6], [11], [12], [13], [14], [15], and [16].

2

Computer option, Software is given 35% of the examination’s P.M. session but only 17.5% of the overall 8-hour examination.

Table 1, Top level specifications of the existing A.M. Breadth Module, effective April 2002. These subjects are required for all candidates taking the Electrical and Computer Engineering P.E. exam3.

Subject Matter, Breadth Module % % of Entire ExamBasic Electrical Engineering 45% 22.5%

Electronics, Electronic Circuits and Components 20% 10%

Controls and Communications Systems 15% 7.5%

Power 20% 10%

Total 100% 50%

Table 2, Top level specifications of the existing P.M. Depth Module, effective October 2005. These subjects are required for all candidates taking the Computers Depth Module4.

Subject Matter, Depth Module % % of Entire ExamGeneral Computer Systems 10% 5%

Hardware 45% 22.5%

Software 35% 17.5%

Networks 10% 5%

Total 100% 50%

Software Engineering Defined

Unlike Computer Engineering, Software Engineering is not as mature of an academic discipline. Therefore, it is worth establishing a definition for the purposes of the Recommendations. Software has come into its own as an engineering discipline within the last 15 to 20 years. Transistors, solid state devices, and computer architecture have enabled many advances in computing power. In order for computing power to continue to push the limit of engineering advances, software needs to take a more important role. In order for software to evolve, appropriate engineering principles, methods, and approaches have to be applied.

A complete discourse on software engineering is beyond the scope of this Recommendation; however, there are several references in Appendix B for further reading5. We only provide a brief overview and introduce its similarities and differences with computer engineering.

Software engineering is the analysis, design, implementation and assurance of the software that comprises or is a part of a system produced by the practice of engineering6.

3 NCEES website, <http://www.ncees.org/exams/professional/pe_electrical_breadth_exam_specs.pdf>.4 NCEES website, <http:/www.ncees.org/exams/professional/pe_electrical_computer_exam_specs.pdf>.5 See Appendix B – References: [3], [7], [8], [18], [19], [20], [22], [27], [28], and [29].6 Definition from the Software Engineering Board Advisory Committee, E.D. Dorchester, P.E. (Chairman) – Licensing Committee. Date Unknown.

3

Expected Interest Level

The Task Force believes that it is realistic to expect an initial number of potential participants for a Computer and Software Engineering Exam. This expectation is evident in several examples outlined in this section.

First, potential employment statistics (see Table 3), show a strong demand by the United States market of Computer and Software Engineers. This represents available employment over the next 10 years which should drive high school graduate to enter Software Engineer and Computer Engineering Undergraduate Programs, since that is where the jobs will be upon graduation from college. It is felt that if a path toward licensure is available for these graduates, a large number of them will fulfill the Fundamental of Engineering Exam and a subsequent Professional Engineering exam.

Table 3, Growth expectations of Computer and Software Engineers as determined by the United States Department of Labor’s Bureau of Labor Statistics (BLS)7 requiring Bachelor’s degree. Numbers are in thousands.

Employment ChangeOccupation 2004 2014 Number Percent

Computer software engineers, applications 460 682 222 48%

Computer software engineers, systems software

340 486 146 43%

Total (Calculated) 800 1,168 368 46%

Second, the convincing demonstration of interest level is the growth in Software Engineering and Computer Engineering Undergraduate Programs in the last 3 years that are ABET accredited. Table 4 shows the growth of accredited Software Engineering Programs increasing 50% or more over the last 3 years. Meanwhile, Computer Engineering programs continue to grow as well.

Table 4, Annual accredited basic programs for Software Engineering and Computer Engineering programs as reported on the ABET/EAC website. The Software Engineering programs reflect approximately 50% growth per year over 3 years8.

Year Software Computer2003 4 157

2004 6 170

2005 10* 180

Current List of ABET/EAC Accredited Software Undergraduate Engineering Programs*

1) Auburn University (Auburn, AL)

2) Clarkson University (Potsdam, NY)

3) Embry-Riddle Aeronautical University (Daytona Beach, FL)

7 BLS website, <http://www.bls.gov/news.release/ecopro.t05.htm> and <http://www.bls.gov/oco/print/ocos267.htm>.8 ABET website, <http://www.abet.org/statistics.shtml>.

4

4) Florida Institute of Technology (Melbourne, FL)

5) University of Michigan(Dearborn, MI)

6) Milwaukee School of Engineering (Milwaukee, WI)

7) Mississippi State University

8) Monmouth University (West Long Branch, NJ)

9) Rochester Institute of Technology (Rochester, NY)

10) University of Texas (Arlington, TX)

The benefits and merits of NCEES providing a Computer and Software Engineering licensure path are important. ABET, by accrediting ten educational institution programs, has provided the first step in acknowledging that Software Engineering is a separate discipline of Engineering. The next step, the Task Force believes, is for NCEES to develop an examination that encompasses a more significant portion of the Computer and Software Engineering discipline. Moreover, the Task Force realizes that there is a gap between the technology as defined by multiple universities establishing degree programs and establishment of a P.E. for that technology.

This distinction is important because our profession encourages engineers practicing engineering be licensed. We also encourage licensure in our professional societies. For example, the new NSPE mission and vision explicitly call of supporting only EI/PE related programs. However, when we demand licensure for individuals, we must provide them a realistic path toward licensure. For example engineers graduating from a Software Engineering or Computer Engineering curriculum, will not be in a position to successfully understand the subject of Power as shown in Table 1 solely based on their Bachelor of Science curriculum. However, this is currently the most likely path that is available for either Engineer to become licensed in most States.

In the past, engineers in the software and computing industry who were cognizant interested in licensure followed several alternatives to obtain licensure. Each of these paths ultimately granted a P.E. license. However, these alternate paths forced the candidate to study outside his/her area of expertise.

Electrical and Computer exam with the Computers Depth Module

Electrical exam prior to the Electrical and Computer exam

Mechanical exam or some other related exam

Interest for licensure of Computer and Software Engineers in the United States are evident in many examples. However, licensure for Software Engineering already exists in Australia, Great Britain and most Canadian provinces9. The Task Force believes that it makes prudent economic sense to enable American Engineers practicing in Computer and Software Engineering the ability to reciprocate the licensure process with our most loyal trading partners and Allies.

9 Frailey, PhD, Dennis, Email correspondence, June 19, 2006.

5

Not only is the BLS projecting large growth among Computer and Software Engineering positions in the United States, the Missouri Department of Economic Development10 is projecting 35% growth in Computer Software Engineers for the same time period within the State of Missouri. This is stunning growth, even if one wants to believe that there is a significant export of engineering jobs to off-shore markets. So it becomes imperative that NSPE continue to focus upon promotion of Professional Engineering licensure as well as build a better relationship with NCEES as prescribed in the Future Directions Task Force Action Plan. This focus needs to go beyond traditional engineering disciplines.

Computer and Software Engineering Licensure

Exam Development Background

Each State Board is responsible for establishing new P.E. examinations in their respective states. It is typical that any Principles & Practice Exam created by NCEES will automatically be accepted and offered within each state. This does not imply that the State will license by discipline, for some, such as California, license in this manner. The Task Force believes the Recommendations presented by the Task Force will become transparent in the current State Licensing Board exam operations.

The NCEES Executive Board is composed of one member from each of the State Boards. In order for NCEES to realize the interest in a new exam ten members of the represented State Boards must formally motion the NCEES Board. This becomes an indicator for other outside organizations as well as NCEES to begin development of a new exam. It is recommended that NSPE be the outside organization expressing interest to NCEES for development of a Computer and Software Engineering exam. Therefore, coordination between allied State Boards and NSPE’s Government Relations or State Outreach office would be necessary in order to move the Recommendations forward. NSPE and PEI would develop a Program for the proposed exam.

The development of a new exam is a tedious and long process. There are specifications that must be written and extensive surveying performed to solicit topics and questions to be placed in the exam. This survey process is called the Professional Activities and Knowledge Study (PAKS) that includes sending out questionnaires and basing the responses on psychometric analysis11. Multiple face-to-face gatherings will be required to bring together all of those on the development team. A program needs to be established for the on-going resources required to maintain the exam, update questions, and provide continuing support. A typical period from start to finish for this process could be 3-5 years with a cost of $50,000 to $100,00012. An organization such as NSPE would cover this cost upon approval of their appropriate committees. It is likely, that NSPE would form one or more strategic alliances through the Memorandum of Understanding (MOU) process to share in the cost burden. The cost burden that NSPE might be required to support is beyond the scope of this Recommendation. The Task Force believes that there several important steps to complete in this process prior to understanding the unknowns of the full cost burden. One such unknown includes the expensive process of the PAKS survey. Further, the Task Force believes that the L&QP Committee has greater insight to proprietary NCEES information on exam development that is not available to the Task Force and thus, the reason for including them as a stakeholder in the approval process.

10 MERIC website, <http://www.missourieconomy.org/pdfs/gateway_skills2005.pdf>.11 Talbert, Desiree, October 2005.12Tripp, Leonard, November 17, 1999.

6

The Task Force believes that the software and computer portion could simply be used from existing, established examination processes as those indicated in Figure 2. Moreover, we strongly believe that the remaining networks portion of the examination would be representing less than a third of the overall exam. Further, with NSPE’s role as program management of this effort, the speed and development of the exam can be greatly simplified and fast-tracked compared with previous exam efforts. NSPE offers the unique ability to help recruit potential candidates to provide survey results, specification development and exam writing.

An alternative would be for an independent development of a Principles & Practice Exam. While this course of action has been accomplished in the past through the Control Engineering Principles & Practice Engineer Exam by the Instrument Society of America (ISA), the authors do not think NSPE has the immediate wherewithal to coordinate such an effort nor willingness. However, the Task Force considers this a last resort option, and should only be pursued after a period of inactivity from NCEES.

Approach

The Task Force proposes that the overall architecture of the exam be defined as indicated in Figure 1 which incorporates the topic areas within the Computer Engineering and Software Engineering that are interrelated between one another. The overlap area in Figure 1 could conceivably constitute the networks element of a proposed Computer and Software Engineering Exam. Further, the overlapped area is the area within each discipline that supports those elements that can be found in the middle of the OSI Layer Model shown in Figure 3.

This Task Force proposes a new Computer and Software Engineering exam that addresses software, computers and networks based on an Open Systems Interconnection (OSI) Layer Model as shown in Figure 3. The idea here is that the existing Electrical & Computer Engineering exam with Computers module would be left untouched by this Recommendation. The Task Force thought there might be duplication with a new Computer and Software Engineering exam, but considers that decision be left to the NCEES Board to evaluate and determine.

A functional block of the proposed exam shown in Figure 2 would remove a significant portion of the Electrical Engineering concepts in the current Electrical and Computer Engineering Exam and build upon an additional level of software, networks and computer topics. Additionally, the new exam would incorporate a greater amount of ethics and concepts of professionalism. The software topics would be based on those listed in Table 5 from the IEEE CDSP Software Engineering exam which would satisfy those subjects supporting Software Engineering in Figure 1. The computer topics would be based on the current specification of the Computers Depth Module and satisfy those subjects supporting Computer Engineering in Figure 1. The networks portion, shown as the overlapped section of Figure 1, would be more significant then currently addressed in the Computers Depth Module and indicated in Table 2.

7

Figure 1, Venn diagram showing the portion of commonality between the Computer Engineering and Software Engineering discipline. The overlap of Software Engineering and Computer Engineering subjects would represent the portion of networks found in each discipline. This overlap would, also shown in Figure 3, would be introduced in a proposed Computer and Software Engineering Examination.

Figure 2, Functional block organizational chart showing two levels of subject matter in a proposed Computer and Software Engineering Examination. Percentages are not indicated and be part of the PAKS survey. The important take-away from this figure is that the “software” and “computers” already provide a good insight on the characteristics of the examination and are currently being used to test competency.

The Task Force’s approach to the proposed Computer and Software Engineering exam is based on an intuitive approach of aligning top level subjects shown in Figure 2 with the

8

OSI Layer Model shown in Figure 3. This approach makes sense because it provides a well-established foundation for determining how to categorize problems and gives a basis to laying out the examination specifications. The primary reason for this approach is because that the concepts of software, computers and networks can systematically be aligned to provide a level of traceability. This alignment correlates the specification process of the PAKS survey with the widely accepted OSI Layer Model shown in Figure 3. This would provide verifiability during the process. The Task Force felt that health, welfare and safety aspects of software predominately had a reliance on either the computer and/or network elements of the OSI Layer Model. This is a fundamental notion to why the Task Force feels that a proposed Computer and Software Engineering exam be created rather than proceeding with a standalone Software, Computer and/or Network Engineering exam.

Figure 3, Distribution of disciplines among the OSI Layer Model. See definition of OSI.

Definition of OSI A model of network architecture and a suite of protocols (a protocol stack) to implement it, developed by ISO13 in 1978 as a framework for international standards in heterogeneous computer network architecture. The OSI architecture is split between seven layers, from lowest to highest: 1) physical layer, 2) data link layer, 3) network layer, 4) transport layer, 5) session layer, 6) presentation layer, 7) application layer. Each layer uses the layer immediately below it and provides a service to the layer above. In some implementations a layer may itself be composed of sub-layers.

As a last suggestion, the Task Force would like to finally bring into the fold, the testing of ethics and professionalism on a Professional Engineering examination, which seems to be missing in the current Electrical and Computer Engineering Exam. These key concepts

13 Definition from <http://www.dictionary.com>: The International Organization for Standardization that sets standards in many businesses and technologies, including computing and communications.

9

are extremely important as this realm engineering blurs further and further into morality issues such as cloning and traditional ethics dilemmas.

Institute of Electrical and Electronics Engineers (IEEE)

The IEEE Computer Society has established a Certified Software Development Professional14 (CSDP) Certificate in Software Engineering which is a very impressive and a proactive response from IEEE to address the Software Engineering discipline’s path toward licensure. The exam is broken down by those subjects shown in Table 5. The topics in the CSDP are applicable to a new Computer and Software Engineering exam which is demonstrated in Figure 2. The CSDP also has basic requirements for continuing education, much as states require of Professional Engineers. Moreover, exams are offered via Computer Based Testing (CBT), which helps produce faster results and creates less paperwork. There can be valuable synergies between the CSDP and a proposed Computer and Software Engineering Exam. In fact, the psychometricians used in the development of the CSDP exam, are the same as those used by NCEES.

Table 5, CSDP Exam Specifications by subject matter. These are the specifications listed as the second level categories in Figure 215.

Subject Matter %Business Practices and Engineering Economics 3-4%

Software Requirements 13-15%

Software Design 22-24%

Software Construction 10-12%

Software Testing 15-17%

Software Maintenance 3-5%

Software Configuration Management 3-4%

Software Engineering Management 10-12%

Software Engineering Process 2-4%

Software Engineering Tools and Methods 2-4

Software Quality 6-8%

Total 100%

Texas and Software Engineering16

The State of Texas in the past established a Software Engineering licensure path by a process of credentialing based on experience rather than examination. The Task Force’s understanding is that this license was not recognized throughout the Professional Engineering community. This process is undergoing a change at this moment. A Texas Board of Professional Engineers Software Engineering Task Force (SWETF) has been established in Texas to look at a proposed approach. The kickoff meeting was held May 2006 and is chaired by Dr. Dennis Frailey. The staff contact for SWETF is Mr. Lance Kinney, P.E., Deputy Director of the Texas Board of Professional Engineers.

14 CSDP website, <http://computer.org/certification>.15 CSDP website, <http://computer.org/certification>.16 Kinney, P.E, Lance, Email <lance.kinney@tbpe.state.tx.us> or 512-440-3080.

10

Vendor specific certification programs

In contrast with licensing and the aforementioned CSDP, the computer, software and networking industries have formulated a number of vendor-specific certification programs designed to designate individuals with sufficient knowledge and experience to provide qualified support for their specific products. These certifications do not have the emphasis on fundamentals that one would expect from licensing or from the CSDP, nor do they require the academic credentials that the latter do, but they may have some overlap with the subject matter one would expect a licensed engineer to understand.

Three of the more widely recognized certification programs in the computing and networking industry that have overlapping skill sets with a proposed Computer and Software Engineering exam are listed below. It has been a contentious issue in the past that some certification paths infer “Engineer” without being properly licensed or educated. The emphases on these programs are to indicate the value of their content and not the title that they may mistakenly bestow on an individual.

1) Microsoft Certified Systems Engineer (MCSE)17 – Microsoft Corporation

2) Certified Novell Engineer (CNE)18 – Novell Corporation

3) Cisco Certified Internetwork Professional (CCIP)19 – Cisco Systems

These areas of curriculum are significantly product specific. These and other similar programs can be self-study or classroom led and usually average six (6) months to a year to complete. These programs require passage of rigorous exams in approximately a half dozen areas that usually must accompany “hands on” experience in order to pass. A core set of two to three exams usually revolves around the core product or technology. Administration of the examinations is through Sylvan Prometric, which tightly controls and oversees the examination process.

The benefits of these three in particular are that they provide a reinforcement foundation in network engineering. Network engineering is becoming intrinsically application-centric and, so; the upper layers of the OSI Layer Model are becoming more relevant to a network engineer. Therefore, it would be prudent to encourage participation in these certification paths as one becomes a Professional Engineer under the proposed Computer and Software Engineer Exam.

It is conceivable, that many of those degreed-engineers in industry, who are already certified in one of the above programs, would be prime candidates for developing specifications under the proposed Computer and Software Engineer Exam. Moreover, these candidates could, become likely candidates for the first generation exam. It is felt by the Task Force that many of these individuals have migrated toward the vendor certifications, for the precise lack of a licensure path. Networks are far beyond simple configuration and management, and have just as much affect on health, welfare and safety as do Computer Engineering and Software Engineering.

17 For more information on the MCSE program: <http://www.microsoft.com/learning/mcp/mcse/default.asp>.18 For more information on the CNE program: <http://www.novell.com/training/certinfo/cne/index.html>.19 For more information on the CCIP program: <http://www.cisco.com/go/ccip>.

11

Proposed NSPE Response

The process that NCEES requires for development of a new exam is that any proposed exam development be initiated once a minimum of 10 State Licensing Boards request and show need for a new exam. As a reminder, the NCEES is a body that consists of membership of each of the 50 state license boards and District of Columbia, Guam and Puerto Rico. For the most part, each state will honor an exam by NCEES. Granted, an NCEES created exam is not mandatory nor the only method of licensing these new types of engineers. It is, however, the most expedient manner to move a process along that normally takes several years. Also, NCEES is in the test development business, while NSPE is not.

Having said this, it becomes important that NSPE leverage its Legislative & Government Affairs (L&GA) and State Legislative Network to lobby 10 states to submit interest and show a “need” for initiating the exam. This would formally be done at an NCEES meeting by the 10 participating State Boards. It is conceivable that a rudimentary list of 10 states could be compiled and contacted. This list could be developed with help from the NSPE Licensure and Qualifications for Practice (L&QP) Committee. From this list, the State in each state would be contacted by that are NSPE member within that state and recommend this action before NCEES. Once the initial contact is made by an NSPE member, the Government Relations committee would be put into action to follow-up and begin the process of whipping the votes until at least 10 supportive State Boards are found to request action from the NCEES. During this process, a draft recommendation could be made so that each state had common language in their request to the NCEES board. The Task Force believes that this will likely be a one year process as identified in Figure 4.

ID Task Name

1 Request for Comments2 Approval by PEI Executive Board3 Review by L&QP4 Approval by L&QP5 Review by NSPE BOD6 Approval by NSPE BOD7 Submittal to NCEES8 Review by NCEES9 Lobby 10 States10 10 States Request Exam by NCEES11 Exam Development Begins

SW TASK FORCE7/8

L&QP9/25

NSPE BOD1/221/23

NCEESGOVT RELATIONS5/175/18

Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct2006 2007

Figure 4, Schedule of tentative dates and tasks to the best of the Task Force’s knowledge.

With NSPE’s improved relations with NCEES, this will be a good time to structure a collaborative effort. Assuming that 10 State Boards approach NCEES and it is initiated, it will next become incumbent on NCEES to survey the industry for experts in this area to capture feedback. This is where NSPE can begin to use some of its tools at its disposal, such as PEI and the PEI Industrial Advisory Group (IAG), Professional Engineers in Higher Education20 (PEHE) and the PEHE Dean’s Council, the L&QP, NSPE members in allied professional organizations (i.e. IEEE-USA), the New Mexico American Engineers’ Association (AEA), etc.

20 nee Professional Engineers in Education (PEE). Name changed in Fall 2005.

12

Conclusions

In summary, it is concluded that,

The proposed Computer and Software Engineering Professional Engineering exam is essential.

A new exam will take approximately 3-5 years to develop unless NCEES entrusts the specification process that IEEE used to shorten this cycle

The State Board of Texas should be a key player in this (if willing) as they seem to be proactive in developing an exam. Others states will follow suit based on results of the state support solicitations.

Vendor specific certifications may have a great value in the industry but can not be replaced by P.E. examination.

The P.E. examination can add value to a Computer, Software or Network Engineer’s career by documenting an understanding of the core disciplines.

To initiate the process of developing a P.E. examination, the L&QP should urge the NSPE BODs to make a formal request to NCEES.

NSPE should develop a special partnership with PEI to foster the new Software Engineering discipline as well as Computer and Network Engineers.

A program manager on the NSPE staff and a volunteer should be established to centralize communication and understanding as this proposal proceeds.

Software Engineering degrees are growing significantly and they need a mechanism for licensure.

Public safety issues dictate that a licensing mechanism is required. Software affects physical devices and financial assets, and can thus cause substantial damage to life and property.

Computers and software control many aspects of our life and engineers practicing in these fields need to be qualified and appropriately trained when it comes to health, welfare, and safety is concerned.

In order for our profession to continue to survive and maintain credibility in the future, we must support and recognize Computer and Software Engineers. Computer and Software Engineers need to have the same ability of being licensed as Civil, Mechanical and Electrical Engineers have had for years. A proposed Computer and Software Engineering exam is essential.

Path Forward

The Task Force felt compelled to offer guidance to the anticipated next steps. These are to be taken only as suggestions and not in any particular order.

13

1) NSPE should assign a Program Manager to coordinate Government Relations, L&QP process and other activities of interrelated committees.

2) A communication should be sent to IEEE, IEEE-USA, ACM, Industrial Advisory Group alerting and other professional organizations that may have an interest in the licensure path indicating NSPE’s intentions.

3) A cost analysis could not addressed by the Task Force, but it is required at some stage. The suggestion here is that this be a request for collaboration between NSPE and NCEES upon Recommendation #1. A joint task force between NCEES and NSPE may be the best vehicle to accomplish this goal. The expertise required for this activity is beyond NSPE’s alone.

4) NSPE should begin the process of soliciting members to become exam writers and develop specifications for NSPE. These members would be subject matter experts in Computing Technology, Software Development and Networks.

5) Negotiations should commence with other professional organizations to assist in the cost sharing. NSPE will also need to evaluate what they are willing to contribute (if any) towards a new exam.

14

Appendix A - Acronyms

AEA (New Mexico) American Engineers’ Association

ABET Accreditation Board for Engineering and Technology

A.M. ante meridiem

BLS Bureau of Labor Statistics

BOD Board of Directors

CBT Computer Based Training

CCIP Cisco Certified Internetwork Professional

CNE Certified Novell Engineer

CSDP Certified Software Development Professional

EAC Engineering Accreditation Commission

IEEE Institute of Electrical and Electronics Engineers

IAG Industry Advisory Group

ISA Instrumentation Society of America

L&QP Licensure & Qualifications for Practice Committee

MCSE Microsoft Certified Systems Engineer

MOU Memorandum of Understanding

NCEES National Council of Examiners for Engineering and Surveying

NSPE National Society of Professional Engineers

OSI Open Systems Interconnection

PAKS Professional Activities and Knowledge Study

P.E. Professional Engineer

PEHE Professional Engineers in Higher Education

PEI Professional Engineers in Industry

P.M. post meridiem

SWETF (Texas Board of Professional Engineers) Software Engineering Task Force

15

Appendix B - References

[1] ACM and IEEE-CS, Software Engineering Code of Ethics, 1999, <http://www.acm.org/serving/se/code.htm> or <http://computer.org/computer/code-of-ethics.pdf>.

[2] ACM, Position on Licensing of Software Engineers and related position papers, 2000, <http://www.acm.org/serving/se_policy>.

[3] Bauer, Dr. F. L., “Software Engineering”, Report on a conference sponsored by NATO Science Committee, Garmisch, Germany, October 7-11, 1968.

[4] Cosgrove, P.E., John, “Software Engineering and the Law”, IEEE Software, May/June 2001, pages 14-16.

[5] Cosgrove, P.E., John, “Chapter 2 - Software Engineering Litigation”, Wiley.

[6] “Economic Impacts of Inadequate Infrastructure for Software Testing”, NIST Planning Report 02-3, May 2002, <http://www.nist.gov/director/prog-ofc/report02-3.pdf>.

[7] Ford, Gary and Norman E. Gibbs, A Mature Profession of Software Engineering, Carnegie-Mellon University Technical Report SEI-96-TR-004 1996.

[8] Frailey, Dennis, “Licensing Software Engineers”, Communications of the ACM, Vol 42, No 12, December 1999.

[9] Frailey, Dennis, “Professionalism and Licensing of Software and System Engineers”, published in Raytheon Electronic Systems Texas System Engineering Newsletter (March 2001), updated May 2003.

[10] Gotterbarn, Don, “Software Engineering as a Profession”, No Date.

[11] Lawson, H.W., “An Assessment Methodology for Safety Critical Systems,” (unpublished paper). Available at <Bud@lawson.se>.

[12] Lawson, H.W., and others, “Twenty Years of Safe Train Control in Sweden”, Available at <Bud@lawson.se>.

[13] Leveson, Nancy, “Final Report: A Demonstration Safety Analysis of Air Traffic Control Software”, NASA Grant, September 1997.

[14] Leveson, Nancy, System Safety Engineering: Back to the Future”, MIT, June 2002, <http://sunnyday.mit.edu/book2.pdf>.

[15] Leveson, Nancy, “The Role of Software in Spacecraft Accidents”, AIAA Journal, <http://sunnyday.mit.edu/papers/jsr.pdf>.

[16] Leveson, Nancy, “The Therac-25 Accidents”, IEEE, June 1993, <http://sunnyday.mit.edu/papers/therac.pdf>.

16

[17] Lethbridge, Timothy, "What Knowledge is Important to a Software Engineer?” IEEE Computer, May, 2000.

[18] IEEE Computer Society, Position Statement on Certification and Licensing of Software Engineers, 2000, <http://computer.org/computer/connection/CSBoGReports_3.htm>.

[19] IEEE Computer Society, Certified Software Engineering Professional web site, 2001, <http://computer.org/certification>.

[20] IEEE Computer Society, Software Engineering Body of Knowledge Project, <http://www.swebok.org>.

[21] Krebs, Robert, “Examining the cut-score process”, Licensure Exchange (NCEES), April 2006, pages 9-10.

[22] McConnell, Steve and Leonard Tripp, "Professional Software Engineering—Fact or Fiction?" IEEE Software, November, 2000.

[23] Mead, Nancy R. and Turner, A. Joe, "Current Accreditation, Certification, and Licensure Activities Related to Software Engineering," Annals of Software Engineering, vol 6 1998, 167-180. Baltzer Science Publishers.

[24] Mead, Nancy R., "Are We Going to Fish or Cut Bait?", Cutter IT Journal, May, 1998.

[25] National Society of Professional Engineers (NSPE) Forum, “Emerging Issues in Licensure: Software Engineering”, San Antonio, TX, July 11, 2003.

[26] National Society of Professional Engineers (NSPE) Forum, “Software/Computer Engineering Registration”, Detroit, MI, July 28, 2001.

[27] Parnas, David, “Software Engineering: Should it be viewed as Engineering”, November 27, 1998.

[28] Parnas, David, “Software Engineering Principles”, April 1984.

[29] Professional Engineers Ontario, Software Engineering Task Force, Memorandum on Recommendations of CCPE/AUCC Software Engineering Panel, 2000, <http://www.peo.on.ca//news/Software_ccpesubmission.htm>.

[30] Pyritz, Bill, “Craftsmanship versus Engineering: Computer Programming-An Art of Science?” Bell Labs Technical Journal, 8(3), 2003, pages 101-104.

[31] Registration Committee of the St. Louis Chapter of Missouri Society of Professional Engineers (MSPE), “Proposal for a Computer Engineering PE Exam in Missouri”, January 15, 2000.

[32] Keil-Slawik, Reinhard and Aspray, William and Parnas, David (Editor), “The History of Software Engineering”, Position Papers for Dagstuhl Seminar 9635, August 26-30, 1996.

[33] Shaw, Mary, "Software Engineering Education: A Roadmap," Proceedings 22nd International Conference on Software Engineering, ACM Press, 2000, pages 371-380.

17

[34] Speed, John, "What Do You Mean I Can't Call Myself a Software Engineer?" IEEE Software, November, 2000.

[35] Talbert, Desiree, “A Word on PAKS”, Licensure Exchange, NCEES, Clemson, SC, October 2005, page 9-10

[36] Texas Board of Professional Engineers, information on software licensing, <http://www.tbpe.state.tx.us/sofupdt.htm>.

[37] Werth, Laurie, “Certification and Licensing for Software Professionals and Organizations”, CSEE&T, January 29, 1998.

18

Appendix C - Acknowledgements

Donald Bagert, Ph.D., P.E. (Indiana, Texas)

Bob Becnel, P.E. (Missouri)

Doug Benner, P.E. (Georgia)

Douglass Bowman, Ph.D., P.E. (Florida)

Mark Ciechanowski, P.E. (Michigan)

Dave Dorchester, P.E. (Texas)

John Featherly, P.E. (Oregon)

Carl Gray, P.E. (Illinois)

Kathryn Gray, P.E. (Illinois)

Kyle Hardy, P.E. (Missouri)

Dennis Frailey, Ph.D. (Texas)

Lance Kinney, P.E. (Texas)

David Parnas, P.Eng (Canada)

Roger Zimmerman, Ph.D., P.E. (New Mexico)

19