IS SOFTWARE ENGINEERING FOR EVERYONE?
William Mitchell
University of Arkansas at Little Rock
Little Rock, AR 72204
ABSTRACT
The journey of Software Engineering education toward an undergraduate major reached another milestone with the draft publication of the most prestigious curriculum model to date. This paper reviews the model and traces its roots to show how it will affect the on-going debate over CS, SE, and IT.
This past summer the Computing Curriculum-Software Engineering (CCSE) task force released their first draft of what will certainly become an undergraduate alternative to computer science [1]. The new curriculum report is the third in a series of undergraduate curricula recommendations developed by international blue-ribbon panels that began their work back in 1998. The massive Computing Curricula 2001 effort updates and refines earlier recommendations for undergraduate computer science, information systems, and computer engineering curricula, and formalizes new undergraduate emphases in Software Engineering. In the next cycle, around 2010, we can expect possibly eight or ten distinct curricula might be presented (Information Science and Telecommunications are coalescing rapidly into segregable disciplines).
The problem that all this diversification poses for departments of Computer Science is whether to proliferate tracks, offer multiple degrees, or split into distinct departments focused on each specialty area. In the past, Information Systems, Computer Science, and Computer Engineering existed in separate colleges and had the option of collaborating or focusing on their differences (focusing on organizations, algorithms, or hardware, respectively). The current trend is toward IT colleges that house all computing programs and lesssharp distinctions as research blossoms onthe boundaries [2]. The re-organization of academia is an adjustment to the reality that IT applications know no boundaries and are increasingly inter-disciplinary. For example, bio-informatics poses a completely different problem.
What will be the impact of an international model Software Engineering curriculum for undergraduates? Can we expect in the coming decade a proliferation of departments of Computer Science and Software Engineering or independent departments of Software Engineering? Software Engineering could be pursued by any of the three existing host colleges because it is the twin of computer engineering, it is applied computer science, and it is a technical management discipline with analytic components akin to economics and operations research. Masters programs in Software Engineering already exist in all three academic contexts.
Below we examine the case that the model curriculum makes for a distinct undergraduate major in Software Engineering. In particular we will highlight the committee’s assessment of the weakness of the present curricula for preparing software engineers. We then consider the software engineering accreditation criteria established by ABET and applied for the first time in 2002-2003. With a clear view of what is the expectation of an undergraduate program in Software Engineering we can then turn to answering the title question. We first review the impediments that have slowed the movement toward a software engineering focus in the past and then we assess the factors that will likely constrain the software engineering curricula in the future.
HOW IS SOFTWARE ENGINEERING DISTINGUISHED?
The draft report distributes the SEEK topics over sample courses being guided by the example of 32 current international bachelor-level programs (none of which encompassed all of SEEK) and the work of the Computer Science Curriculum recommendation. “A key technique to develop curricula was to determine which SEEK topics can be covered by reusing CCSC courses” [1, p46]. The Report sketches fifteen overlapping 40-hour software engineering courses apportioned to three levels, each capturing the number of hours of SEEK topics shown in parenthesis.
The introductory level is SE101(35), SE102(36), SE200(38) [Software Engineering and Computing I, II, III], or SE201(34) [Introduction to Software Engineering for Software Engineers] when CS1 and CS2 are used.
The central level is SE212(25) [Software Engineering Approach to Human Computer Interaction ]and either SE211(36) [Software Construction], SE311(33) [Software Design and Evolution ], SE321(37) [Quality, Verification and Validation ], SE322(18) [Requirements ], and SE323(26) [Project Management ], or SE213(28) [Design and Architecture of Large Software Systems ], SE221(23) [Testing ], SE312(26) [Low-Level Design ], SE313(40) [Formal Methods in Software Engineering ], and SE324(39) [Process and Management ].
The final level is the year-long capstone SE400(34+)). In addition, an applied statistics, MA271(18), and three “non-technical” courses, NT271(13) [Engineering Economics ], NT181(11) [Group Dynamics and Communication ], and NT291(14) [Professional Software Engineering Practice ], are defined to capture the specific empirical, communication, economic, and professional practice topics of SEEK.
At a minimum, CS103(31) Data Structures and Algorithms, CS105(24) and CS106(27) Discrete Structures I & II, and two intermediate CS courses are required to supplement the SE courses in presenting the SEEK. These courses are woven into different four-year curriculum illustrations to demonstrate that various calendars and emphases can be accommodated while still encompassing the SEEK core. In one pattern the SEEK core is presented in eight CS courses, seven SE courses, plus the four extra core courses and the capstone. At the other extreme is a pattern that uses six CS courses, nine SE courses, and the four extra core courses and the capstone. The different curriculum patterns presented by the CCSE report show how the SEEK core can be embedded in a 120 hour degree program by augmenting it with from three to six SE technical electives and complementing it with different combinations of engineering, science, and mathematics coursework depending on the hypothesized context of the program.
Table 1. Characteristics of SEEK
|
Knowledge Area |
Hours of topics |
Number of Modules (total number of essential topics identified) |
|
Computing Essentials (CMP) |
172 |
4(37) |
|
Math and Engr. Fundamentals (FND) |
89 |
3(18) |
|
Professional Practice (PRF) |
35 |
3(15) |
|
Software Modeling & Analysis (MAA) |
53 |
7(33) |
|
Software Design (DES) |
45 |
6(31) |
|
Software Verification and Validation (VAV) |
42 |
5(28) |
|
Software Evolution (EVL) |
10 |
2(9) |
|
Software Process (PRO) |
13 |
2(13) |
|
Software Quality (QUA) |
16 |
5(25) |
|
Software Management (MGT) |
19 |
5(28) |
|
Non-Seek Supplementary topics |
|
Calculus, Physics, Engineering, etc. |
Computer Science departments offer most of the present undergraduate SE instruction. This evolutionary fact has encouraged the widely held belief that SE is a sub-discipline of CS [3,4], a belief that this report attempts to dispel. The report asserts that while the survey of software engineering commonly offered by CS programs covers the right topics [5], a knowledge of the existence of these topics is not adequate preparation for practice, and it argues that literally ten times the exposure is needed to acquire application competence.
The report, in chapter 5, suggests that in addition to lack of depth, computer science has not done well in providing the context and mentoring necessary to convey an accurate impression of the software engineering field. The report calls for software engineering faculty who have wide exposure to multiple domains of software engineering (real-time, data processing, systems software, etc.) and can thus focus on presenting concepts that are widely rather than narrowly applicable. These faculty must have a deep knowledge of computer science in order to ground software engineering practice, but they must also have intimate experience with software engineering practice. In order to give students a realistic introduction to software engineering, faculty must themselves appreciate the circumstances in which software engineers work and the multiple pressures that they balance. Students should see engineering principles emphasized and learn to make engineering judgments. Students should learn how to use tools, to work in teams, to interact with users, and to solve the variety of real-world problems that make software engineering a distinctive discipline. A good portion of the curriculum must be project based.
As with the curriculum recommendations in the other computing disciplines, the discussion of curriculum content and emphasis has been paralleled by independent efforts to state accreditation criteria. The Engineering Accrediting Commission (EAC) of ABET has adopted the following criteria for undergraduate Software Engineering [6] and the first programs seeking ABET accreditation were visited in the fall of 2002.
These program criteria apply to engineering programs which include software or similar modifiers in their titles.
1. Curriculum
The curriculum must provide both breadth and depth across the range of engineering and computer science topics implied by the title and objectives of the program. The program must demonstrate that graduates have: the ability to analyze, design, verify, validate, implement, apply, and maintain software systems; the ability to appropriately apply discrete mathematics, probability and statistics, and relevant topics in computer science and supporting disciplines to complex software systems; and the ability to work in one or more significant application domains.
2. Faculty
The program shall demonstrate that those faculty teaching core software engineering material have practical software engineering experience.
ABET does not prescribe the course structure or topic emphasis of a program beyond the broad requirements of the criteria, but the program evaluators are expected to look for the breadth and depth that exemplifies the best educational practice [7]. Four programs, three in Engineering units, were accredited in the first round of visits: Clarkson (www.clarkson.edu/software_engineering/), Milwaukee School of Engineering (www.msoe.edu/ eecs/se/), Mississippi State University (www.cse.msstate.edu/UNDERGRADUATE/) and Rochester Institute of Technology (www.se.rit.edu/). RIT’s program is offered by seven faculty in the Department of Software Engineering in the College of Computing and Information Sciences, while the other have added the SE degree within departments that offer other BS degrees. At Clarkson, because the Computer Science program is not in the Engineering unit responsible for SE, the program is classified as interdisciplinary. MSOE does not offer a CS degree. Table 2. displays the characteristics of the four programs where SE faculty are identified by the mention of software in the faculty member’s research interest on the website and the number of SE courses was determined as those offered by the department and required of SE majors but not required of majors in the department’s other degrees. The final column tabulates the portion of the coursework required in the SE degree that is taken within the host School or College (excluding required courses in mathematics, science, liberal arts, business, and free electives). All of the SE programs require courses in other engineering departments, such as Industrial Engineering, and in CS.
Table 2. ABET Accredited Software Engineering Programs
|
Institution |
Department |
Degrees Offered |
# SE faculty |
# SE Courses |
% of degree coursework in host unit |
|
Clarkson University |
Electrical and Computing |
CE (computer engr), EE, SE |
2 of 18 |
7 |
37% (+13% in CS) |
|
Milwaukee School of Engineering |
Electrical Engineering and Computer Science |
CE, EE, SE, EET, Biomedical Engr. |
3 of 32 |
13 |
53% |
|
Mississippi State |
Computer Science & Engineering |
CS, SE |
4 of 17 |
7 |
54% |
|
RIT |
Software Engineering |
SE |
7 |
13+ four Co-op quarters SE related |
39-47+% (+15-8% in Engr) |
RIT claims the first undergraduate SE degree program in the US started in 1996, however much effort to initiate an undergraduate major had been donated by SEI at Carnegie Mellon over the previous decade culminating in the straw man version of the SEI Undergraduate Curriculum in Software Engineering published in 1990 [12]. In his 1990 paper summarizing the report to the SIGCSE Technical Symposium Gary Ford [13] asserted
Software engineering education will not be achieved by adding modern programming languages and techniques to existing computer science course, nor by adding a team-programming course to the curriculum. An engineering approach to the whole curriculum is necessary.
He went on to note that because CS had lost its buzz and enrollments had dropped sharply, we were beginning to see the first of what became a mantra in the 1990s of manpower reports claiming that industry’s future was at risk. Moreover, the knowledge and skills he identified with software engineers were not emphasized in the then proposed CS curriculum recommendations (CS Curriculum 1991) that tried to strongly separate computer science from “programming”. However, as a result of work by Freeman, Wasserman, Fairley [14, 15,16] and others (the Wang Institute), software engineering had taken hold at the master’s level.
However, only about 20% of students continue for a master’s degree, so providing software engineering education only at the graduate level prevents the majority of software professionals from receiving that education. Therefore we believe that undergraduate software engineering programs are essential to the long-term health of the software profession…[We suggest] that the material in the software engineering courses might total fourteen courses in the areas of software analysis, software architectures, computer systems, and software process [13].
In attempting to strike a balance between ABET and CSAB the straw man curriculum also specified six Mathematics courses, three science courses, ten Humanities and Social Science courses, and seven electives (for a total of 120 semester hours).
Four years later, in 1994, Ford [17] reports:
We do not know of any undergraduate programs named “Bachelor of Science in Software Engineering” at any United States universities. However, several schools teach significant course sequences in software engineering at the undergraduate level, a few schools offer software-related programs (other than computer science), and some schools report that they are now developing undergraduate programs in software engineering.
He then describes the progress of eleven programs that seem headed toward the creation of an undergraduate SE degree. Five of those programs are among the 29 identified in table 1. Obviously the pace for establishing undergraduate SE programs is excruciatingly slow.
Pour, Griss, and Lutz enumerated the difficulties that must be overcome to establish an SE program in an article in the May 2000 issue of Computer [4], tracing the evolution of the discipline and, at the height of the dot.com boom, looking forward optimistically.
Software 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.
They see the key to rapid progress being a greatly enhanced partnership with industry and the inevitable maturation of a very young professional discipline. But the solution involves bridging two culture gaps, one the “not invented here” syndrome that impedes knowledge sharing between academics and practitioners, and the second the science vs. engineering orientation toward educating software professionals. The latter is fundamentally an issue of theory versus application in computing, a field whose theory and applications are both burgeoning beyond our manpower resources. Pour, Griss, and Lutz conclude that computer science has opted to be a science and therefore “[d]espite 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” [4]. Ten years earlier, John and Laurie Werth articulated that computer science faced this fundamental choice [18].
However, the possible divisions between software engineering and computer science depend largely on the nature of the relationship between computing and its applications. If computer science is unable to maintain a fruitful interaction with the applications of computing, an interaction which provides solutions to application problems and educates professionals who understand the principles of software engineering, then some mechanism will rise up to mediate between the applications and computer science.
Today Peter Denning, who contributed significantly to the scientific orientation of computer science in the late 1980s, is popularizing the applied field of Information Technology as a means of mediating between computer science and practicality [19]. Software Engineering is but one sub-field in Information Technology even though it is itself a broad and diverse area of practice. Denning points out that the rise of IT supports the separation of SE and CS [20].
Software engineering and computer science share the same conceptual principles, but they have significantly different professional approaches and practices. They can share curricula in the principles, but they need to go separate ways with professional practices. With the interpretation of the IT profession offered here, both are part of the profession but there is no requirement that one be part of the other.
On the other hand, the growth of many different IT degrees blurs the role of SE programs as the way to address computer applications. Already there are many narrowly the start of a trend to approach the various software professional roles from a technologist’s perspective. The crux of the issue is that the software engineering field is unified by its emphases on non-technical and “soft-skills” and segmented by the limited scope of its theories and best practices—the later being unequal to the tremendous diversity of circumstances under which software developers work [21].
Table 3. Bachelor Degree SE Programs in US in Fall 2003
|
Auburn University |
Missouri Tech |
|
Butler University |
Monmouth University |
|
California State University, Fresno |
Montana Tech |
|
California State University, Hayward |
Penn State at Erie |
|
Cal-Poly-SLO |
Rochester Institute of Technology |
|
Carroll College |
Rose Hulman |
|
Clarkson University |
Southern Polytechnic University |
|
Drexel University |
Stevens Institute of Technology |
|
Embry-Riddle Aeronautical University |
University of Michigan-Dearborn |
|
Florida Institute of Technology |
University of Missouri-Kansas City |
|
Florida State University |
University of Texas at Arlington |
|
Gannon University |
University of Texas at Dallas |
|
Michigan Tech |
University of Washington |
|
Milwaukee School of Engineering |
University of Wisconsin-Platteville |
|
Mississippi State University |
|
In May of 1999 the ACM Council established a committee to advise the Council on the likely outcomes of the efforts to codify the software engineering body of knowledge. This committee found that the diversity of software development environments and the multitude of roles that software professionals play argued against the utility of a monolithic approach to a software engineering body of knowledge. If the goal is the broad improvement of software quality, the solution will not be found by preparing software professionals uniformly [22].
We believe that role separation — defining different roles, such as programmers, software testers, designers, and systems analysts — is likely to be central to approaches that improve the quality of software systems. Separating roles may be done not only to separate professional from nonprofessional roles, but also to identify professional roles more specialized than the role implied by professional engineering registration. As a rough analogy, it may be that we are better positioned to define the analog of selected board specializations (e.g., software testers) than the analog of the general medical doctor degree (e.g., software engineers).
Given the considerable spectrum of viewpoints at every level of the discipline for and against instantiating undergraduate SE majors and the internal political and resource issues that new majors evoke within academia, we should not expect even the CCSE endorsement to motivate a rush of new degree programs.
The Computer Science Curriculum 2001 report [10] includes in chapters 9 and 10 a call for computer science programs to involve students in team projects, professional presentations, and discussions on workplace ethics. Indeed, the CS report includes twelve SE modules in its body of knowledge and specifies eight modules (31 hours) in its core curriculum. Further it defines a projects course, CS292 Software Development and Professional Practice, that integrates 21 of those hours and, additionally, CS490 Capstone Project, that incorporates 22 core hours. It is clear in the CS report that computer science is not merely a foundation for SE, analogous to Physics being the foundation for Mechanical Engineering, but that SE-lite is a necessary component of a computer science graduate, just as an English major cannot be ignorant of Shakespeare. Computer Science and Software Engineering may have different goals as disciplines, but they are at present joined at the hip. We can conclude that for some time we will see CS degrees and SE degrees offered by the same departments or colleges and that SE-lite will always be a component of CS degrees. Because the vast majority of CS majors graduate into careers developing or maintaining software, it is appropriate that they at least survey the issues that SE addresses and experience team-based projects. Many of these graduates will seek more SE education at the graduate level.
The point to be resolved is whether SE-lite is sufficient, now and in the future, to support the needs of our economy. The argument of the CCSE report is that while a CS education is good, it is not best for certain purposes and that our society is better served if we also have a significant influx of bachelor-level professionals who come with an orientation and expertise that matches the challenges we face in developing and maintaining software packages and systems. One Industry Advisory Board makes this point in the following words [11] (delivered to a top-rated undergraduate computing program):
The CSC Industrial Advisory Council believes that the time has come for a separate Software Engineering curriculum…. We find that today’s students are woefully unprepared to work in an environment with these [cost, schedule, and quality] constraints. Infrastructure activities that we take for granted in organizations — such as configuration management, project planning, and quality assurance — are poorly understood, and viewed with the suspicion that we used to see primarily focused on doing design before implementation. Collaborative skills are generally of a very low level. While we don’t expect new graduates to be fully qualified engineers that can skillfully manipulate all aspects of the software lifecycle, we would strongly prefer that they at least have had classroom and coursework exposure to these concepts.
This view asserts that the body of knowledge inculcated in software engineering programs will differ from the knowledge purveyed by computer science programs and that the orientation sought in SE programs will be that of an engineer constructing a useful artifact rather than a scientist discovering or refining new knowledge. Graduates of both programs will bring similar technical skills but different perspectives and problem solving frameworks to the workplace.
Not every CS graduate will become a software developer and large numbers of software developers will do so without a CS credential. The software quality issue is focused on large software-dependent systems that pervade the workplace and supply the nervous system of our economic infrastructure. As application systems grow more complex and as we interconnect applications, we need more than an exponentially growing workforce to write the code, we need better tools to cope with the complexity and better practices to combat defects. We need specialists who can leverage the skills of colleagues, organize and focus efforts, and communicate a clear vision of both the process and the software product that it generates. Every computing professional must be educated about the process of engineering a software product and understand the components of software quality. However imperfect, SE-lite will continue to be part of the computer science major and a capstone software project experience will certainly become the norm in undergraduate computer science degree programs.
The debate over the definition of SE and its relationship to CS will continue as both CS and SE mature, but it is becoming increasingly irrelevant. We are moving toward an IT era in which application domains and technologies that fit them engender computing specializations. All of these specializations need computer science fundamentals and all inherit an engineering attribute because of their application focus. Because each new computing specialization favors its own approach to modeling the phenomena of its application domain and employs sometimes-unique algorithms and hardware, there is pressure to introduce the undergraduate to this unique environment and thus create a new degree. IT is more like Education and Engineering than Medicine or Law in that a practical level of application competence can be acquired without studying the breadth of any computing discipline. Our society has accepted in IT and Education what in Law and Medicine are para-professionals: narrowly prepared individuals who are competent for the responsibilities of an entry-level position and who will learn on the job to be mature professionals.
The debate over whether SE should be an undergraduate major or just an emphasis in a CS degree is similarly becoming irrelevant. It will be both. SE-lite will become increasingly established in Computer Science and Computer Engineering programs, and in some departments the interest and resources will be available to create a distinct major. Expect five to ten new undergraduate SE programs to be inaugurated each year this decade, most from within colleges of engineering, and most seeking ABET accreditation [23]. Do not expect a large shift of students or faculty into these new programs. Students and faculty are more drawn by the opportunity to be clever in an application domain or to invent new technologies or techniques than by the disciplined process of coordinating resources to achieve a goal. Most will be satisfied with an SE-lite exposure to software development in CS majors. The professional discipline of Software Engineering is a unique engineering field, but it shares with all branches of engineering the characteristic skill of making useful artifacts by inventive application and extension of existing knowledge. Software Engineering is no more “programming” than is Computer Science, but it is programmers who are responsible for software. Although it has been predicted that “Within 50 years, software engineering will supplant computer science as the educational discipline for professional software developers” [24] there is little reason to believe this will happen unless we redefine what is meant by professional software developers. It is just as likely that in fifty years most of the process of software development will become automated to the extent that the skills to specify computer-mediated functionality will be universally taught.
CCSE has proposed the next iteration toward an undergraduate SE curriculum that will equip its graduate to be several steps closer than a CS graduate to the software engineering specialist that must be available in larger numbers to leaven the construction of enterprise-scale software applications. The bachelor-level SE graduate may indeed be the GP of software engineering who needs to be augmented with numerous other software experts or para-professionals. But the breadth of competence that the bachelor SE student acquires and her engineering perspective is a critical component for improving the application of software engineering knowledge in the software development team. Projects might aim for a ratio of one BS or MS software engineer for every eight to ten team members with SE-lite backgrounds.
The evolution of an undergraduate SE major is good for the software profession and it is good for Computer Science programs. Computer Science should not be stretched to include all of the details of SE, important as those details are to future practitioners. With the establishment of the SE major, Computer Science programs are freed to focus on the more limited SE-lite area, keeping their science-orientation. In fleshing out the scope and focus of the SE discipline, the model SE curriculum describes a graduate whose professional orientation exploits a different set of skills and attributes than are commonly developed in Computer Science program. The workplace needs both orientations and both skill sets.
[1] Joint Task Force on Computing Curriculum, Computing Curriculum-Software Engineering, IEEE Computer Society, ACM, July 17, 2003 [Downloaded from http://sites.computer.org/ccse/volume/FirstDraft.pdf on July 21, 2003]
[2] Mitchell, William, “New Faces in the Computing Landscape, “Not Your Father’s Oldsmobile!” Journal of Computing Sciences in Colleges, (18,6) June 2003 p. 97-108.
[3] Lethbridge, T., B. Probert, J. Raymond, D. Gibbons, D. Ionescu, L. Orozco-Barbosa and S. Szpakowicz (1998, July), "The University of Ottawa's Software Engineering Program: Curriculum Design Issues for a New Subdiscipline", Canadian Conference on Engineering Education, Halifax, pp. 551-560 [downloaded from http://www.site.uottawa.ca/~tcl/papers/C2E2/C2E298.html August 15, 2003]
[4] Pour, Gilda, Martin L. Griss, Michael Lutz, “The Push to Make Software Engineering Respectable”, IEEE Computer, May 2000, (33,5), pp 35-43.
[5] Carver, Doris, “Recommendations for Software Engineering Education,” SIGCSE Bulletin (19,1) February 1987, p. 228-232.
[6] 2002-2003 Engineering Criteria [Downloaded from http://www.abet.org/criteria.html on August 15, 2003]
[7] Bagert, Donald J., Mark A. Ardis,Cary Laxer “Overview of Bachelor of Science in Software Engineering at Rose-Hulman Institute of Technology,” published May 30, 2003 [downloaded from http://www.cs.rose-hulman.edu/curriculum/BSSEOverview.pdf on August 15, 2003]
[8] Current Survey Results [downloaded from http://www.engin.umd.umich.edu/CIS/Survey_ISEAP_2001/Survey_ISEAP.html on August 15, 2003]
[9] Hilburn, Tom, Software Engineering Undergraduate Programs (in the US) [Downloaded from http://faculty.db.erau.edu/hilburn/se-educ/se-programs.html on August 15, 2003]
[10]Computing Curricula, Final Draft, December 15, 2001 [Download from http://www.computer.org/education/cc2001/final/index.htm on August 15, 2003]
[11]White paper [Download from http://www.engr.sjsu.edu/smeldal/SEProgram/documents/IAC%20SE%20White%20Paper.pdf on August 15, 2003]
[12] Ford, Gary, 1990 SEI Report on Undergraduate Software Engineering Education, Technical Report CMU/SEI- 90-TR-3, March 1990. [obtainable at http://www.sei.cmu.edu/publications/documents/90.reports/90.tr.003.html]
[13]Ford, Gary, “The SEI Undergraduate Curriculum in Software Engineering,” SIGCSE Bulletin (23,1) March 1991, p. 375-385.
[14] Freeman, Peter, Anthony I. Wasserman, and Richard E. Fairley, “Essential Elements Of Software Engineering Education,” Proceedings Of The 2nd International Conference On Software Engineering,San Francisco, California, United States, 1976, 116 - 122
[15]Freeman, Peter and Anthony Wasserman, “A Proposed Curriculum For Software Engineering Education,” Proceedings of the 3rd international conference on Software engineering, Atlanta, Georgia, United States 1978, 56 - 62
[16] Petricig, Michael and Peter Freeman, “Software Engineering Education, A Survey” SIGCSE Bulletin, December 1984 (16,4), pp. 18-22.
[17]Ford, Gary, “The Progress of Undergraduate Software Engineering Education,” SIGCSE Bulletin, (26,4) December 1994, p. 51-55.
[18]Werth, John and Laurie Werth, “Directions in Software Engineering Education” Proceedings of the 13th International Conference on Software Engineering, May 13-17, 1991, Austin, TX. IEEE Computer Society / ACM Press, 1991 p. 353-357.
[19]Denning, Peter, “Crossing the Chasm,” Communications Of The ACM, April 2001/Vol. 44, No. 4, 21-25
[20]Denning, Peter, “Who Are We?” Communications Of The ACM, February 2001/Vol. 44, No. 2 1p.5-19
[21]Zvegintzov, Nicholas, “Do we Know Enough to Teach Software Engineering?” IEEE Software (20,5) September/October 2003, p. 110-112.
[22]Notkin, David, Michael Gorlick, Mary Shaw, An Assessment of Software Engineering Body of Knowledge Efforts, May 2000 [downloaded from http://www.cs.washington.edu/homes/notkin/bok_assessment.pdf on August 15, 2003]
[23]Saiedian, Hossein, Donald Bagert, and Nancy Mead, “Software Engineering Programs: Dispelling the Myths and Misconceptions,” IEEE Software (19,5) September/October 2000, pp. pp35-41.
[24]Henderson, Peter, “Software engineering education,” ACM SIGSOFT Software Engineering Notes (28,2) March 2003, 10 - 12 Downloaded from http://blue.butler.edu/~phenders/SEEd on August 15.