PEO Recommendations of the Software Engineering Panel

The following memorandum from the Chair of the PEO Software Engineering Task Force was forwarded to the Canadian Council of Professional Engineers and the other provincial engineering associations/order in early November. It represents PEO's position on the recommendation of the CCPE/AUCC Software Engineering Panel that software engineering programs at Canadian universities be accredited by a new, separate accreditation body comprising representatives of the Canadian Engineering Accreditation Board and the Computing Science Accreditation Council. The submission was endorsed by PEO's Executive Committee on November 7, 2000.

Memorandum

To: Peter DeVita, President PEO
From: George Comrie, Chairman OSWET
Date: October 31, 2000
Subject: RECOMMENDATIONS OF THE SOFTWARE ENGINEERING PANEL

As requested by PEO Council, the Professional Engineers Ontario Software Engineering Task Force (OSWET) reviewed the recommendations of the Software Engineering Panel and makes the following report.

The primary objective of the Software Engineering Panel (SWEP) was to find a solution that would prevent confusion in the use of the term “software engineering” within the undergraduate university community. A secondary objective was to improve the working relationships between the engineering and computer science disciplines. PEO fully agrees with these objectives and wishes to pursue a win-win solution for both engineering and computer science.

The proposed SWEP solution of establishing a separate board for accrediting undergraduate software engineering programs (Software Engineering Accreditation Board or SEAB) does not meet the primary objective and in fact makes the issue more confusing. The SWEP recommendations are based on some questionable assumptions, such as:

The proposed SEAB accreditation methodology and criteria will ensure that software engineering programs offered to Canadian universities meet or exceed minimal educational standards for professional engineering. Accreditation units and CEAB weighting coefficients are not equivalent to course equivalents and the CSAC accreditation methodology is not equivalent to the CEAB accreditation methodology. The CEAB methodology for accrediting university courses considers them in the context of the total program environment and within the culture of professional engineering practice. The CSAC methodology is calendar driven with an emphasis on course title over course content and context. Accreditation and teaching by non-Professional Engineers does not ensure that the requisite common engineering culture is preserved. Any modification to the existing CEAB criteria and accreditation methodology is unwarranted. Furthermore, it poses the risk of rendering a program ‘accredited’ under such new criteria unacceptable to our Academic Requirements Committee.
The distinction between Software Engineering and computer science is unimportant and the same criteria (body of knowledge) can be used to define both. There are strong overlaps but the differences are crucial to identifying the types of work where licensure is necessary to protect the public interest. Criteria which would be acceptable to both communities would not be demanding of either. For example, the same criteria are not used to accredit Civil Engineering and Architecture programs. The proposed solution, therefore, denies the value to society of both disciplines as distinct disciplines.
Joint sponsorship of the proposed SEAB is equivalent to joint operation. The proposed SEAB is a separate independent body, and due to resource constraints is unlikely to have any common members with the CEAB. The process for evolving the SEAB criteria is not defined and the criteria may diverge significantly from the CEAB’s criteria over time. The CEAB, at its September 2000 meeting in Charlottetown, expressed concerns about the delegation of the important accreditation responsibility to a separate independent body. In fact, neither the CCPE nor the CEAB is authorised to pass this function over to any other party or group without the agreement of the constituent associations/ordre, which are responsible by statute for setting the academic qualifications for licensing and have delegated this responsibility to the CEAB, while retaining the authority for final determination.
The Information System Professional (ISP) designation is equivalent to the Professional Engineer (P. Eng.) licence and a computer science practitioner is equivalent to a licensed Professional Software Engineer. The ISP designation is voluntary whereas the P. Eng. licence is established by legislation with the exclusive right to practice engineering. In implying equivalency, we deny the legitimate role of licensure in protecting the public interest as vested in legislation.

The proposed solution creates a situation in which students from Engineering and students from Computer Science (CS) will be able to graduate from programs named Software Engineering (SE). Currently, only individual courses in CS have been named SE not entire Programs. Nevertheless, the SEAB criteria are such that it is desired that both types of programs be accredited even though there will be a difference between these programs. In essence, we will have two standards for a software engineering program: one Engineering driven and the other CS driven. The proposal for the creation of the SEAB creates the illusion of one program but not the reality. This solution would leave the profession in a worse position than when we started and the potential for undergraduate and public confusion is greater.

PEO’s mandate is to ensure that the public welfare and interest are served where engineering is concerned. Since the practice of software engineering has the potential of impacting the public interest, PEO is responsible for its regulation. This view is consistent with the IEEE definition of software engineering as: the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software: that is the application of engineering to software. Furthermore, the direction in the US is to place software engineering under the engineering umbrella as demonstrated by the expansion of the ABET scope to be “Accreditation Board for Engineering, Computing and Technology” (i.e. ABECT).

Software engineers, like engineers in other disciplines, need to have a broad awareness and understanding of core engineering in order to be able to recognise the boundaries of the other disciplines. Competence implies the awareness of the limits of one’s own competency. These core components, particularly in the basis sciences, provide engineers with this awareness of other disciplines. This knowledge is crucial for the licensing of software engineering practitioners, who via our Licensing structure could move into any other field of engineering as long as the code of ethics was followed. Only those applicants who can demonstrate that they satisfy these requirements should be licensed.

Improving the working relationships between the engineering and computer science disciplines is very important. The objective of reducing the confusion as to the meaning of software engineering amongst both academia and the public is strongly supported by PEO and the other associations/ordre. The CSAC-CCPE task force has contributed greatly in increasing our understanding of this very complex issue. However, other options identified by SWEP should be explored further before a final decision is made.

The PEO Software Engineering Taskforce (OSWET) concludes that the SWEP recommendation to establish the SEAB does not achieve the primary objective and in fact makes the issue more confusing. Moreover, we conclude that it will inhibit PEO in fulfilling its legislative mandate to protect the public interest through licensure.