Software Engineering Across Computing Curricula Thomas 6. Hilburn
Donald J. Bagert
Department of Computer Science Embry-Riddle Aeronautical University Daytona Beach, FI 32114 I-904-226-6889
Department of Computer Science Texas Tech University Lubbock TX 79409-3104 i-806-742- 1189
[email protected]
bagert @ ttu.edu Dale Oexmann
Susan Mengel
Rose-Hulman Institute of Technology Terre Haute, IN 47803-3999 Lubbock TX 79409-3104 I-81 2-877-3527
Department of Computer Science Texas Tech University Lubbock TX 79409-3104 I-806-742-3527
[email protected]
mengel@ ttu.edu
dramatically. Unfortunately, there are serious problems in the cost, timeliness, and quality of development of many software products. The code in consumer products is doubling every two years; it is almost the norm for software projects to overrun their planned cost and schedule.One in four large-scale development projects is never completed, and many of those completed do not meet the user requirementsand are of poor quality [Sl. There are over a thousandacademicprograms in computing in the United Statesand many more throughout the world. These programs graduate tens of thousands of computer professionals a year. Less than fifteen percent go on to graduateschool and most of the rest are employed in some part of the computer industry [9]. A variety of disciplines are represented in these programs (including computer science, information systems, and software engineering), and they are housed in a variety of academic units (e.g. engineering,business,and arts & sciences). However, these programs vary widely in addressing the fundamentals of software educationin their respectivecurricula [6]. ” Employers claim that new hires do not know how to communicate, they have insufficient experience and preparation for working as part of a team, they lack the ability to managetheir individual work in an efficient and productive manner, and they do not understand or appreciate organisational structures or business practices [S]. Computer science education too often focuses on individual contributions rather than on managed group efforts that depend on defined standards, methodologies, and software processes,however, such group efforts are the norm in the software industry. New graduatesknow little about what are regarded as “best practices” in the software engineering profession (e.g., practices related to use of software processes, measurement and analysis, team building, front-end development methods, quality
1. ABSTRACT In this paper, we address issues that are pertinent to the improvement of software engineering curricula. We submit that a key impediment to the development of new courses and curricula and the advancement of software engineering education is the lack of guidance and support for such development. In this paper we propose the creation of a set of “Guidelines for Software Education”. We outline the content of such Guidelines and discuss some initial steps in defining the body of knowledge that is a foundation for the Guidelines. 1.1 Keywords Software engineering, computing curricula, curriculum design. 2. INTRODUCTION
Jnto the foreseeable future, software will play an increasingly important and central role in all aspects of daily life. The number, size, complexity, and application domains of programs being developed will grow Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ITiCSE ‘98 Dublin, Ireland 0 1998 ACM I-581 13-000-7/98/0008...
$5.00
117
engineering, software maintenance, and testing). This problem of inadequate preparation of current graduatesis further exacerbatedby the increasing demand for software engineersand other computing professionals. The solution to this problem dependsheavily on the ability of faculty to redesign and implement curricula that not only emphasise computer science, information science, and technology, but focus on the “practice” of software engineering (SE) and include the equally critical people and process issues. In this paper, we discuss the work of the Working Group on Software Engineering Education and Training (WGSEET) [14], a group of industry and academic professionals interested in promoting the development and future outlook of software engineering education and training. The WGSEET meets twice a year (in fall 1998 at the Frontiers in Education Conference, and in spring 1999 at the Conference on Software Engineering Education and Training) to engagein activities that promote and support the education and training of software engineers.One of its recent activities has been work on the development of a document entitled Guidelines for
There have been a number of recent efforts in proposing and developing new curriculum models that can be used to design and implement software engineering and related curricula. In [lo], Hilburn proposes a conceptual model for an undergraduate curriculum in software engineering. This model describes a curriculum that is focused on people, process, and technology, and provides a mix of computer science knowledge, communication and teamwork proficiency, and the definition and use of individual, team, and organisational processes.Cowling [3] proposes a model that includes four dimensions and concerns in the design of a software engineering curriculum: the different levels of abstraction for software and hardware components; the balance between the computing content of a curriculum and other branches of science and engineering; the balance between theory, modelling, and practical applications of them; and the balance between technical and non-technical material. This model and its multiple dimensions accommodates and supports a flexible approach in developing different softwareengineering programs. A collaborative effort between the ACM, the Association for Information Systems, and the Association for Information Technology Professionals has produced a model for curriculum programs in information systems(IS), IS’97 [4]. This model is comprehensive and includes the following elements: an IS body of knowledge, curriculum design objectives, an IS curriculum architecture, a set learning units, a set of courses and curriculum support material. Becauseof the overlapping nature of IS and SE, there is much in IS’97 that provides support for the developmentof SE’programs. Finally, as part of the efforts of the IEEE-ACM Joint Steering Committee for the Establishment of Software Engineering as a Profession, an Education Task Force was establishedin 1997. This Task Force was charged with the development of a program in Software Engineering Education based on the initial work of the Task Force on the Body of Software Engineering Knowledge. The first effort of the Task Force has been the development of draft accreditation criteria for undergraduate programs in software engineering [2]. We feel that the Task Force initiative is the most promising recent development for the improvement of software engineering education, and we hope that the WGSEET efforts will support the objectives of the Task Force and provide useful input for their deliberations and decisions.
Software Education.
3. COMPUTING
CURRICULUM
MODELS
In the last twenty years there has been significant advancementsin the state of computer science education (and in allied fields such as computer engineering and information systems). The Association for Computing Machinery (ACM), the IEEE Computer Society (IEEE-CS), and the Computer Sciences Accreditation Board (CSAB) have provided encouragement, support, and guidance in developing quality curricula that are viable and dynamic. We have moved from language and coding centred curricula to programs that emphasise theory, abstraction, and design. However, most computing programsstill devote little time to software life-cycle development, software processes,quality issues, team skills, and other areas of software engineering essential to effective commercial software development [5,6,7,11]. The problem is not in the computing sciencecurricula. For the most part, these curricula are designed to prepare students as scientists, not as engineers. For instance, in its development of Computing Curricula I991 [131, the ACM/IEEE-CS Joint Curriculum Task Force did not consider software engineering as a discipline unto itself, but rather as one of nine subfields of computing (algorithms and data structures, programming languages, computer architecture, numeric and symbolic computation, operating systems,software engineering, databaseand informational retrieval, artificial intelligence and robotics, and humancomputer interaction). Of the nine sample curricula included in Computing Curricula 1991, only one focuseson softwareengineering.
4. SOFTWARE
EDUCATION
GUIDELINES
In November 1997 the WGSEET met in Pittsburgh and began discussion for the need of a set of guidelines to support the design and implementation of software engineering courses and curricula. Although there are existing curriculum guides produced for various computing curricula (Section 2) there is no existing document that
118
provides comprehensive information and direction for the development of undergraduate programs in software engineering. The WGSEET has begun work on the Guidelines for SoftwareEducation. In its final form, it is envisioned that the Guidelines will contain the following: a description of the body of knowledge for software engineering (appropriate for curriculum development); a conceptual curriculum model; curriculum units and courses; sample curriculum implementations; curriculum support material; and guidance for assessmentand accreditation. For additional information on the work of WGSEET and related issues,seethe papersby Bagert[ 11and Mengel[l2]. As a first step, the following objectives were establishedfor
associatedwith the collection, analysis, specification, and review of softwarerequirements.
5.1.2 Software Design Component The SoftwareDesign Component includes knowledge aboul principles, methods and techniques for describing how a software product will be implemented so that its requirementsare satisfied. This includes all types of design activities: architectural design, component design, interface design, data design, and algorithm design.
5.I.3 Software Construction Component The SoftwareConstruction Component includes, in addition to knowledge about language syntax, issues related to coding style and standards, internal documentation, code prototyping, code reuse, analysis and choice of implementation tools, and implementation strategiesin the use of various language paradigms (such as assembler, procedural, and object-oriented).
the Guidelines: . Promote discussion among professionals in education
. .
.
and industry that will improve software education in all institutions at an international level. Encourage greater commonality in software education within and acrosscomputing disciplines.
5.1.4 Project Management Component
Provide a coherent, structured description of software engineering concepts, knowledge, and practices, that supportssoftware education curriculum development.
The Software Project Management Component addresses issues involving the creation, development, and maintenance of software projects. This area includes project management,risk analysis, project planning, project administration, and configuration management.
Develop a model curriculum for software engineering that can be applied in whole, or part, to the development of software education programs.
5. BODY OF KNOWLEDGE
5.1.5 Software Evolution Component
The WGSEET’s “body of knowledge” (BOK) description is centred on a high-level organisation of software engineering knowledge into “software engineering knowledge areas” where each area is organised into a set of “knowledge components”. The SE-BOK is organised into four knowledge areas:the Core Area, the Foundations Area, the Recurring Area, and the Supporting Area. In the following sectionswe outline the contents of each area.
The Software Evolution Component addresses the knowledge and techniques necessaryto be able to enhance, perfect, and modify software over time. It includes the issues of software maintenance, extensibility, software adaptability to different environments, and software reengineering.
5.2 Foundations Area The Foundations Area includes those components which underlay the Core Area and Recurring Area. The FoundationsArea consistsof the following components: . Computing Fundamentals . Human Factors
5.1 Core Area The Core Area includes those components that define the essenceof software engineering: . Software Requirements l
SoftwareDesign
.
l
SoftwareConstruction
5.2.1 Computing Fundamentals Component
. .
Software Project Management SoftwareEvolution.
The Computing FundamentalsComponent addressesthose topics upon which effective software development can be built. The topics include foundations of computing, programming, programming language concepts, history of computing, data structures, algorithm analysis, compiler organisation, computer complexity, operating systems,and computer architecture.
5.1.1 Sofbvare Requirements Component The Software Requirements Component includes knowledge concerned with establishing a common understanding of the requirements to be addressedby a software project. It includes methods,Icchniques, and tools
119
Application Domains.
5.2.2 Human Factors Component
5.3.4 Software Modelling Component
The Human Factors Component encompassesthe two broad categories characterised by users who utilise software and by systemdevelopers who construct software. In these two categories, interface design, ergonomics, development environments, team dynamics, and communication are of primary concern to facilitate and make efficient the computer-humaninterface.
The Software Modelling Component covers principles and methods for modelling software architectures and software development entities. This includes techniques for using abstraction, modularity and hierarchy to model software functionality, data object relationships, and behaviour.
5.3.5 Software Metrics Component The Software Metrics Component encompassesthe tools and techniques for performing experimental analysis on, keeping historical records on, and monitoring the progress of software engineering processes,artefacts,and resources. It involves metrics definitions, data collection, and experimental techniques.
5.2.3 Application Domains Component The Application Domains Component includes knowledge about how software engineering techniques should be effectively used in various application domains: real-time systems, database and information systems, high performance computing, intelligent systems, graphics applications, and systemssoftware.
5.3.6 Tools and Environments Component The Tools and Environments Component includes knowledge about the tools and environments that automate software processesat various stages of the software life cycle. It includes tool analysis, selection, and operation.
5.3 Recurring Area Components in the Recurring Area are threads that occur through all of the Core Area Components. The Recurring Componentsinclude the following: . Ethics and Professionalism . Software Processes . SoftwareQuality l
Software Modelling
l
Software Metrics
.
Tools and Environments
.
Documentation.
5.3.7 Documentation Component The Documentation Component encompassesall of the material required to support the building and later maintenanceof a software product. It includes methods, tools, and standardsto write clear and accessiblematerial for all artefactsand processesof the software life cycle.
5.4 Supporting
Area
The componentsin the Supporting Area include other fields of study which provide building blocks for rounding out the education of students in software engineering. They include, but are not limited to, general education, mathematics, natural sciences, social sciences, business studies,and engineering.
5.3.1 Ethics and Professionalism Component The Ethics and ProfessionalismComponent addressesthose ethical, social, and professional issuesinherent in producing software and in interacting with colleaguesand clients. The quality, confidentiality, component includes legal, environmental, safety, workplace and harassment, and professional certification concerns.
6. CONCLUSION Software engineering is a maturing discipline that is becoming increasingly critical in all aspects of htiman endeavour. The demand for well educated software engineersis increasing, but computing programs to support this demand do not exist. We believe that work of WGSEET in developing a Guidelines for Software Education that will help solve this problem by providing information and guidance will help faculty and institutions create and implement quality software engineering courses and curricula. The development of these Guidelines is viewed as a multi-year project and will require contributions from a broad range of software educators and practitioners. The WGSEET invites and encouragescooperation with other groups interested in the improvement of softwareengineering education.
5.3.2 Software Processes Component The Software ProcessesComponent involves the definition, implementation, evaluation and improvement of software engineering processes. It includes models for categorising software maturity and for applying software skills and techniques.
5.3.3 Software Quality Component The Software Quality Component encompasses the techniques and skills necessary to assure that software meets its requirements, that software development and maintenanceprocessesare sound and measurable,and that, when required, software exhibits the characteristics of survivability, safety, and fault-tolerance.
120
Software Engineering Institute, Carnegie Mellon University, 1994. [7] Ford, G. and Gibbs, N.E. Mature Profession of Software Engineering, CMIVSEI-96-TR-004. Software Engineering Institute, Carnegie Mellon University, 1996. [8] Gibbs, W.W. Software’s Chronic Crisis. Scientific American (September1994) 86-95. [9] Hartmanis, J. and Lin, H., Ed. Computing the Future. National Academy Press,1992. [IO] Hilburn, T.B. SE Education: A Modest Proposal. IEEE Software. 14, 6,44-48. [ 111Lethbridge, T.C. Survey of the Relevanceof Computer Science and Software Engineering Education. Proceedings of the 11th Conference on Software Education & Training (Pittsburgh, PA, February 1998), IEEE computer Society Press,44-55.
7. ACKNOWLEDGMENTS We would like to acknowledge the help of all the members of the WGSEET in formulating and assessingmany of the ideas in this paper. Our special thanks go to Dr. Nancy Mead of the SE1 for her leadership of the WGSEET and her substantial work in promoting efforts to improve softwareengineering education.
8. REFERENCES [I] Bagert, D.J. The Challenge of Curriculum Modelling for an Emerging Discipline: Software Engineering Education. (to appear) Proceedingsof the Frontiers in Education Conference. (Tuscan AZ, November 1998), IEEE Computer Press. [2] Barnes, et, al. Draft Software Engineering Accreditation Criteria, Computer, 3 1,4, 73-75. [33 Cowling, A.J., A Multi-dimensional Model of the Software Engineering Curriculum. Proceedings of the 1lth Conference on Software Education & Training (Pittsburgh, PA, February 1998), IEEE computer Society Press,44-55. [4] Davis, G. B., et. al. IS’97: Model Curriculum for IJndergraduate Degree Programs in Information Systems,1997: http://webfoot.csom.mn.edu/faculty/gdavis/curco~e.p df [5] Denning, P.J. Educating a New Engineer, Communications of the ACM. 35, 12,83-97. [6] Ford, G. A Progress Report on Undergraduate Software Engineering Education, CMU/SEI-94-TR-11.
[ 121Mengel, S.A. Guidelines Proposal for Undergraduate Software Engineering Education. (to appear) Proceedingsof the Frontiers in Education Conference. (Tuscan AZ, November 1998), IEEE Computer Press. [ 133Tucker, A. B., ed. Computing Curricula 1991: Report of the ACM/IEEE-CS Joint Curriculum Task Force. IEEE Computer Society Press,1991. [ 141Working Group on Software Engineering Education and Training, web site http://www.sei.cmu.edu/topics/collaborating/ed/workgr oup-ed.html
121
