focus
national and international standards expected of the Bachelor of Science graduate.
For accrediting a BS in Software Engineer-ing (BSSE) program in the US, the primary source is the Accreditation Board for neering and Technology. ABET hosts the Engi-neering Accreditation Commission (EAC), which maintains the accreditation criteria for
engineering and related programs.1 (For
infor-mation on other countries’ accreditation sources, see the sidebar “Software Engineering Accred-iting Bodies around the Globe”).
ABET, while authoritative in the US, is not the only source for BSSE program development. The Software Engineering Curriculum Guide-lines (SE2004) were developed to support BSSE
program development across the globe.2
SE2004 is available as a volume in the Comput-ing Curricula 2005 (CC05) series, which has been developed, maintained, and published by
the Joint Task Force for Computing Curricula.3
This is a cooperative project of the Association
for Computing Machinery, the Association for Information Systems, and the IEEE Computer Society.4,5Other useful sources include theGuide
to the Software Engineering Body of Knowledge (SWEBOK)5and other published materials on SE as a discipline.6
However, these sources define only one set of the requirements; they don’t define a com-plete, accreditable program, nor one that a particular university can successfully field ac-cording to its unique vision, organizational constraints, and practical constraints on pro-gram delivery. For example, in the initial de-velopment of an accreditable BSSE program at Gannon University, the constraints in-cluded the university’s mission, its core courses, and the need to maximize reuse of
the current courses and program flow.7The
university board of directors approved our initial BSSE program in 2003, and it launched in 2004. The first class will gradu-ate in May 2008 and the program will
un-Creating an Accreditable
Software Engineering
Bachelor’s Program
S
ince 1936, the accreditation of undergraduate engineering
pro-grams has been a cornerstone of modern engineering practice.
Ac-creditation validates that an engineering program serves its
con-stituents and the public well. In an emerging discipline such as
software engineering, accreditation standards also serve as a target—a
source of requirements for validating an SE program’s design. Accreditation
standards also help ensure that a program’s graduates will meet or exceed
curriculum development
Stephen T. Frezza, Mei-Huei Tang, and Barry J. Brinkman, Gannon University
A small university’s
BSSE program
grew out of several
requirements
sources and
accreditation
expectations. The
planners developed
effective design
processes and a
model curriculum.
dergo self-study and ABET visitation in fall 2008.
As with effective software design, one key to success in program design is validation. Using the various requirements sources available, we rigorously applied traceability matrices to match proposed program components (usually courses) to program requirements.7The tables also served as a structure for tracking changes and as a dis-cussion focus regarding feasibility issues, peda-gogy, course prerequisite structures, and staffing issues. We performed traceability analysis in two areas that support program development: knowledge, which refers to what the graduates
need to know, and student (or program)
out-comes, which define a broader picture of the graduate.
Defining the BSSE graduate
In general terms, outcomes describe what students are expected to know and be able to do by the time of graduation. Outcomes relate to broadly defined skills, knowledge, and be-haviors that students should acquire as they
progress through the program.8So, they
pro-vide a yardstick for measuring a program’s ef-fectiveness. If a graduate achieves all the pro-gram outcomes, this indicates that the student meets the program’s stated educational objec-tives and is equipped to function as expected of a BSSE graduate.
The design of an accreditable SE program must meet the educational objectives (for ex-ample, what career and professional accom-plishments the student is prepared to achieve) and criteria established for a BSSE program.
Essentially, these objectives and criteria define the minimal knowledge and skills for a BSSE graduate. In the US, the EAC provides two broad categories of objectives and criteria that
apply to the design of engineering programs.1
The broader set is the EAC Program Educa-tional Objectives, which apply to all engineer-ing programs. More specific program criteria similarly define objectives for each engineering discipline.
Figure 1 lists the EAC Program Educational Objectives in the left-hand column. These objec-tives cover a wide spectrum of engineering ac-complishments, ranging from applying knowl-edge and functioning as a team member to understanding ethical responsibility and main-taining knowledge of contemporary issues. The right-hand column of figure 1 lists the three EAC criteria for SE programs. In general, these crite-ria indicate that software engineers apply general engineering principles to complex software sys-tem development in one or more application do-mains. These are intentionally broad and leave much latitude for BSSE program development.
Although these objectives and criteria are definitive for accreditation, they don’t provide
as much detail as the SE2004 guidelines.3The
SE2004 lists seven outcomes for SE programs, which are shown in figure 1’s middle column. We’ve rearranged the SE2004 criteria’s order of presentation to support a gap analysis be-tween the two sets of criteria. The single ar-rows in figure 1 illustrate the overlap between the two sets of EAC criteria. Double arrows indicate the relationship between the out-comes that do not completely cover a
particu-Australia: Engineering programs (including SE) are accredited through Engineers Australia—www.engineersaustralia.org.au/ education/program-accreditation/program-accreditation.cfm
Canada: Engineering programs (including SE) are accredited through the Canadian Engineering Accreditation Board (CEAB) of the Canadian Council of Professional Engineers (CCPE)—www.ccpe.ca/e/prog_publications_3.cfm
Japan: Engineering programs are accredited through the
Japan Accreditation Board for Engineering Education (JABEE).
SE is not covered specifically (although it’s covered some-what under information engineering)—www.jabee.org/ english/OpenHomePage/e_criteria&procedures.htm
United Kingdom: The Degree Accreditation Board for
Char-tered Engineers (DABCE) and the Joint Accreditation Board
(JAB) merged in January 2006, forming the Engineering Accreditation Board (EAB). All 22 of the engineering institu-tions that are licensed by the Engineering Council UK (ECUK) to accredit academic programs are members of the new EAB—www.engab.org.uk
United States: The Accreditation Board for Engineering and Technology (ABET) accredits programs through four different commissions: the Engineering Accreditation Commission (EAC), the Computing Accreditation Commission (CAC), the Applied Science Accreditation Commission (ASAC), and the Technology Accreditation Commission (TAC). SE falls under EAC guidelines—www.abet.org
lar criterion. Gaps exist where criteria have no relationship or incomplete coverage. For ex-ample, two such gaps occur in the omission of “Broad education …” and “Contemporary is-sues …” from the SE2004 student outcomes.
The overlap, as well as the gap between EAC program objectives and SE2004 outcomes, im-plied that we needed to synthesize the objectives and outcomes into a usable summary of the out-comes expected of a BSSE graduate. We identi-fied 11 source statements as key to this sum-mary (they are shown in bold in figure 1):
1. Show mastery of the software engineering knowledge and skills and professional is-sues necessary to begin practice as a soft-ware engineer.
2. Appropriately apply science, discrete math-ematics, empirical techniques, probability and statistics, and relevant topics in com-puter science and supporting disciplines to the development of complex software systems.
3. Work as an individual and as part of a mul-tidisciplinary team to develop and deliver quality software artifacts.
4. Reconcile conflicting project objectives, finding acceptable compromises within limitations of cost, time, knowledge, and existing systems and organizations. 5. Design appropriate solutions in one or more
application domains using software engi-neering approaches that integrate ethical, social, legal, and economic concerns.
EAC Program Educational Objectives SE2004 student outcomes EAC SE program criteria
A. Ability to apply knowledge of science,
engineering, and mathematics
1a. Ability to analyze, design, verify, validate, implement, apply, and maintain software systems
B. Ability to design and conduct experiments
as well as to analyze and interpret the data
1b. Ability to appropriately apply 1b. Ability to appropriately apply
discrete mathematics, probability discrete mathematics, probability and statistics, and relevant topics and statistics, and relevant topics in computer science and supporting in computer science and supporting disciplines to the development disciplines to the development of complex software systems of complex software systems
D. Ability to function on multidisciplinary
teams
Work as an individual and as part of a team to Work as an individual and as part of a team to develop and deliver quality software artifacts develop and deliver quality software artifacts Reconcile conflicting project objectives, Reconcile conflicting project objectives, finding acceptable compromises within finding acceptable compromises within limitations of cost, time, knowledge, and limitations of cost, time, knowledge, and existing systems and organizations existing systems and organizations
1c. Ability to work in one or more significant application domains
F. Understanding of professional and ethical F. Understanding of professional and ethical
responsibility responsibility
E. Ability to identify, formulate, and solve
engineering problems
K. Ability to use the techniques, skills, and
modern engineering tools necessary
for engineering practice
G. Ability to communicate effectively
Demonstrate an understanding and appreciation Demonstrate an understanding and appreciation for the importance of negotiation, effective for the importance of negotiation, effective work habits, leadership, and good work habits, leadership, and good
communication with stakeholders in a typical communication with stakeholders in a typical software development environment. software development environment.
I. Recognition of the need for and an ability to
engage in lifelong learning
J. Knowledge of contemporary issues J. Knowledge of contemporary issues
H. Broad education necessary to understand the H. Broad education necessary to understand the
impact of engineering solutions in a global, impact of engineering solutions in a global, economic, environmental, and societal context economic, environmental, and societal context
C. Ability to design a system, component, or
process to meet desired needs within realistic
constraints such as economic, environmental,
social, political, ethical, health and safety,
manufacturability, and sustainability
Learn new models, techniques, and Learn new models, techniques, and technologies as they emerge and appreciate technologies as they emerge and appreciate the necessity of such continuing professional the necessity of such continuing professional development.
development.
Show mastery of the software engineering Show mastery of the software engineering knowledge and skills, and professional issues knowledge and skills, and professional issues necessary to begin practice as a software necessary to begin practice as a software engineer
engineer
Demonstrate an understanding of and apply Demonstrate an understanding of and apply current theories, models, and techniques that current theories, models, and techniques that provide a basis for problem identification and provide a basis for problem identification and analysis, software design, development, analysis, software design, development, implementation, and documentation. implementation, and documentation. Design appropriate solutions in one or more Design appropriate solutions in one or more application domains using software application domains using software
engineering approaches that integrate ethical, engineering approaches that integrate ethical, social, legal, and economic concerns social, legal, and economic concerns
Figure 1. Comparison of Education Accreditation Commission program objectives, software engineering student outcomes as described in SE2004, and EAC program criteria for SE. The bold statements comprise the summary outcomes expected of a BSSE graduate.
6. Understand professional and ethical respon-sibility.
7. Demonstrate an understanding of and apply
current theories, models, and techniques that provide a basis for problem identifica-tion and analysis, software design, develop-ment, implementation, and documentation. 8. Demonstrate an understanding and appre-ciation for the importance of negotiation, effective work habits, leadership, and good communication with stakeholders in a typi-cal software development environment. 9. Learn new models, techniques, and
tech-nologies as they emerge, and appreciate the necessity of such continuing professional development.
10. Grasp contemporary issues.
11. Have a broad education necessary to under-stand the impact of engineering solutions in a global, economic, environmental, and so-cietal context.
These essential program outcomes, while necessary, are insufficient. An individual insti-tution seeking accreditation is expected to not only cover the outcomes required for accredi-tation but also customize them to fit its con-straints and capitalize on its unique strengths. The customized outcomes also become tools to
measure and improve program effectiveness.8
Although important for defining and contin-ually improving program effectiveness, the out-comes by themselves don’t provide adequate depth into the “software engineering knowl-edge and skills” and “professional issues” ref-erenced. What specifically should we teach stu-dents? What should the courses contain? SE fortunately has other sources that define more specifically what students must know and be able to do.
What software engineers need to know
SE2004 defines the body of knowledge that every SE degree graduate fresh out of college needs to know as the Software Engineering Education Knowledge. SEEK is designed as a guide to support the development of under-graduate SE education curricula. SEEK defines
10 education knowledge areas; each KA is
di-vided into smaller modules called knowledge
units, and each KU is further divided into
top-ics. Some topics are designated as “essential”
and constitute the core knowledge required to obtain an undergraduate SE degree. Table 1 lists the SEEK KAs, the KUs defined for each KA, and their abbreviations.
Table 1
SE2004 SEEK knowledge areas, the knowledge
units defined for each KA, and abbreviations
MAA Software modeling and analysis
MAA.md Modeling foundations MAA.tm Types of models MAA.af Analysis fundamentals MAA.rfd Requirements fundamentals MAA.er Eliciting requirements
MAA.rsd Requirements specification and documentation MAA.rv Requirements validation
DES Software design
DES.con Design concepts DES.str Design strategies DES.ar Architectural design
DES.hci Human-computer interface design DES.dd Detailed design
DES.ste Design support tools and evaluation
VAV Software verification and validation
VAV.fnd V&V terminology and foundations VAV.rev Reviews
VAV.tst Testing
VAV.hct Human-computer user interface testing and evaluation VAV.par Problem analysis and reporting
EVO Software evolution
EVO.pro Evolution processes EVO.ac Evolution activities
PRO Software process
PRO.con Process concepts PRO.imp Process implementation
QUA Software quality
QUA.cc Software quality concepts and culture QUA.std Software quality standards
QUA.pro Software quality processes QUA.pca Process assurance QUA.pda Product assurance
MGT Software management
MGT.con Management concepts MGT.pp Project planning
MGT.per Project personnel and organization MGT.ctl Project control
MGT.cm Software configuration management
CMP Computing essentials
CMP.cf Computer science foundations CMP.ct Construction technologies CMP.tl Construction tools
CMP.fm Formal construction methods
FND Mathematical and engineering fundamentals
FND.mf Mathematical foundations FND.ef Engineering foundations of software FND.ec Engineering economics of software
PRF Professional practice
PRF.psy Group dynamics/psychology PRF.com Communication skills (specific to SE) PRF.pr Professionalism
SWEBOK,5on the other hand, characterizes the contents of the SE discipline—the knowl-edge needed for practicing SE after four years
in the workforce2—in 10 KAs. Figure 2 lists
the KAs for both SEEK and SWEBOK. The green
links connect similar KAs, while KAs without
links indicate where the SEEK and SWEBOK
KAs differ. Blue links in the figure indicate dis-tributed relationships, and orange indicates links that contain significant although incom-plete overlap.
As depicted in figure 2, the differences are noticeable in the SEEK Mathematical and En-gineering Fundamentals (FND) and
Profes-sional Practice (PRO) KAs relative to the SWE
-BOK. Some of these differences are intentional:
because SWEBOKfocuses on what’s within the
boundary of SE, its creators intentionally omitted the knowledge of related domains and
disciplines. Similarly, the SWEBOKKA Software
Requirements is covered as a part of Software
Modeling and Analysis (MAA), while SWE
-BOK’s Software Construction and Software
Configuration Management are partially cov-ered by the SEEK Computing Essentials (CMP) and Software Management (MGT)
KAs, respectively. The SWEBOKSoftware
Engi-neering Tools and Methods KA is embodied inside the CMP, MAA, DES, VAV, EVO, PRO, QUA, and MGT topics.
Both SEEK and SWEBOKdefine the specific
knowledge and skills a software engineer re-quires. For undergraduate SE graduates fresh out of college, the knowledge they attain comes from the courses they completed, so curricula play an important role in deciding what knowledge students would possess when
they graduate. While both SEEK and SWEBOK
are designed as a guide/foundation for SE cur-riculum development, SEEK is especially de-signed for undergraduate SE curriculum devel-opment. It defines topics in detail and expects accredited programs to reflect this set of knowl-edge and skills.
Case study: Designing a BSSE curriculum for accreditation
The design of an accreditable program has as its primary output a series of academic courses that give students opportunities for
mastering particular course objectives,9which,
when combined, lead to the students achieving program objectives. Because the courses pro-vide both the content and support for the
out-comes, linking courses to the program require-ments (both outcomes and KAs) is both a de-sign and validation method. Similarly, the courses selected for the program must also meet the other nonfunctional program require-ments, such as university mission, particular program vision, organizational constraints, and practical constraints on program delivery.
We applied these analysis and design princi-ples to a new BSSE program in our university. In our program design, identifying the known constraints proved to be a useful starting point. Working within existing constraints
Curriculum design in our university setting has three major driving constraints:
■ provide adequate credit hours for
univer-sity core (general education) courses,
■ maximize the reuse of existing courses,
and
■ limit the program to 135 (semester) credit
hours.
While the first constraint limits all pro-grams in our university, it leaves room for spe-cialization and creativity. The second con-straint resulted from needing to produce a new program compatible with the existing computing programs. The CS and SE pro-grams’ introductory and core material was very similar, because the entire faculty saw an overlapping need for solid, practical founda-tions in programming, systems, networking, distributed systems, introductory design, test-ing, and other SE topics. Furthermore, relatively few students enroll in these programs, so we
Software Evolution Software Process
Software Verification and Validation Software Quality Software Design Software Management Mathematical and EngineeringFundamentals Professional Practice Computing Essentials
Software Modeling and Analysis EVO PRO VAV QUA DES MGT FND PRF CMP MAA Software Maintenance Software Engineering Pocess Software Testing
Software Quality Software Design
Software Engineering Management Software Engineering Tools and Methods
Software Configuration Management Software Construction
Software Requirements
SEEK KA SWEBOK KA
Figure 2. Relationships between SEEK and SWEBOKknowledge areas. Green lines connect similar KAs, blue lines indicate distributed relationships, and orange ones indicate links with significant but incomplete overlap. The KAs without lines indicate differences between SEEK and SWEBOKKAs.
needed to make the programs as alike as possi-ble to make optimal use of staff and other re-sources and to let the students switch majors without needing to significantly extend their time at the university.8Unfortunately, this deci-sion restricts students’ opportunities for SE proj-ect experiences early in the program.
Table 2 shows the results of our preliminary design. It lists groups of existing courses that the program reuses, their associated credit hours and core contact hours, and the SEEK KUs that the courses address.
Table 2 indicates that the preliminary pro-gram design left at least 97 of 494 core contact
hours (20 percent), spread among 25 or more
SEEK KUs, to be integrated into the program.
It also shows there were 19 (135 116) or
fewer credit hours to accomplish this. So, the remaining design problem was to optimize the delivery of SE-specific courses to meet or ex-ceed the needs of the remaining SEEK KUs and to ensure that program outcomes were met.
A successful design process must balance an individual course’s cognitive load while ensur-ing adequate coverage throughout a program. In this context, cognitive loadrefers to the new knowledge and skills that a student must mas-ter in a particular course; a successful cognitive load for a particular course is highly instructor-and institution-dependent. However, over-loaded courses are more difficult to teach and generally less successful for all but the brightest students. Conversely, underloaded courses tend to bore both the students and faculty and use program resources less efficiently.
Balancing cognitive loads
For the SE-specific courses, we distributed the remaining SEEK KAs among the remaining credit hours using a detailed traceability
analy-sis of the SEEK topics.8Table 3 summarizes a
traceability analysis for a single course: Personal Software Process. We used traceability analyses for all the program courses that were assigned primary or secondary roles for particular topics. Primary roles are most important because they indicate where the program focuses content de-livery for a topic. Other courses also address several of the topics.
This traceability exercise for developing new courses provides detailed topical material
Table 2
Preliminary program design after applying first constraints
Existing course groups Credits SEEK knowledge units addressed Core contact hours
General education requirements 36 FND.ec, PRF.com 15 Computing and engineering fundamentals 35 CMP.cf, CMP.ct, CMP.tl, FND.ef 187
Mathematics 15 FND.mf 56
Domain electives 9 —
Science 8 —
Professional practice 7 PRF.psy, PRF.com, PRF.pr, VAV.rev, QUA.cc, MGT.con, MGT.pp, MGT.ctl 55 Software engineering 6 MAA.md, MAA.tm, MAA.af, MAA.rfd, DES.con, DES.dd, DES.ste,
VAV.fnd, VAV.rev, VAV.tst 84
Total reused credits 116 Total core contact hours 397 Remaining credits 19 Remaining hours 97+
Table 3
Traceability analysis of SEEK knowledge units and
topics for a Personal Software Process course
Knowledge unit Topic number Topic description
FND.ef 3 Measurement and metrics
FND.ef 6 Theory of measurement (for example, criteria for valid measurement)
VAV.rev 1 Desk checking VAV.rev 2 Walk-throughs
PRO.con 4 Measurement and analysis of software processes PRO.con 5 Software engineering process improvement
(individual and team)
PRO.imp 3 Life-cycle process models and standards (for example, IEEE and ISO)
PRO.imp 4 Individual software process (model, definition, measurement, analysis, improvement) MGT.pp 4 Effort estimation
that faculty can discuss in designing individual courses and balancing the cognitive trade-offs between existing and proposed courses. The SEEK topic detail, although extensive and at times cumbersome, facilitates discussion of the prerequisites, outcomes, potential texts, and feasibility of each course.
Traceability analysis also supports iterative program improvement. We’ve reviewed the traceability plans biannually for all program courses to help ensure that the current course instantiations are realistic with respect to the program and accreditation expectations.
Table 4 summarizes the traceability exer-cise, indicating the KUs that each new SE course addresses, either partially or completely. The design process steps of working with ex-isting constraints and balancing cognitive loads provides a draft of a nearly complete and feasi-ble program. Figure 3 provides a quick glance at the BSSE program we derived using this process (see www.gannon.edu/departmental/ ecs/cis/cisdefault.asp and www.gannon.edu/ PROGRAMS/UNDER/softengr.asp). The pro-gram attempts to assign each SEEK knowledge topic to a primary (and occasionally
second-Table 4
Responsibility assignment of SEEK knowledge units to new courses
New software engineering courses SEEK knowledge units covered Credits
Formal Methods in Software Development CMP.fm, MAA.md, MAA.rsd, MAA.rv 3 Personal Software Process FND.ef, PRO.con, PRO.imp, MGT.pp 3 Requirements and Project Management FND.ec, PRF.psy, MAA.tm, MAA.rfd, MAA.er, MAA.rsd, MAA.rv, MGT.con, MGT.pp, MGT.per,
MGT.ctl 3
Software Architecture MAA.md, DES.con, DES.str, DES.ar, DES.dd, DES.ste 3 Human Interface Design and Maintenance PRF.psy, DES.hci, VAV.hci, VAV.hct, EVO.pro, EVO.ac, MGT.cm 3 Testing and Quality Assurance MAA.rv, VAV.fnd, VAV.tst, VAV.par, QUA.cc, QUA.std, QUA.pca, QUA.pca, QUA.pda, MGT.ctl 3
Total 25+ 18
Professional practice Mathematics
Professional seminar 1 Calculus 6
Capstone design 1 and 2 6 Discrete mathematics 6 Science Probability and statistics 3 Physical sciences and labs 8 Formal methods (new) 3
Computing and engineering fundamentals Software engineering
Introduction to databases 1 Personal Software Process (new) 3 Introduction to computing (CS0) 3 Software design and test 3 Introduction to C++ (CS1) 3 Software engineering 3 Problem solving in C++ (CS11/2) 3 Requirements engineering (new) 3 Data structures (CS2) 3 Software architecture (new) 3 Advanced OOP 3 Testing and quality assurance (new) 3 Introduction to networks 3 Interface design and maintenance (new) 3 Computer architecture 3
Operating systems 3 Application domain
Database management systems 3 Application domain concentration 9 Distributed programming 3
General education
Writing 6 Literature 3
Social science elective 3 Theology 6
Introduction to philosophy 3 Philosophy of knowledge 3
History 3 Fine arts 3
Philosophical/theological/moral responsibility 3 Project economics 3
Figure 3. The current Gannon BSSE program at a glance.
ary) course responsible to deliver this KA. Having repeated this exercise several times during the initial program development effort, and subsequently during annual program re-view, we have three observations:
■ The courses could not cover all units (in
fact, not even all essentialunits).
■ Knowledge topics and units cover a broad
spectrum of university courses.
■ SE-specific courses (both new and reused)
covered the majority of knowledge units. Refining program outcomes
What remains to complete the design is to validate the program with respect to the pro-gram outcomes. We did this at Gannon through a series of proposals and analysis of the out-comes for both applicability and feasibility. We organized “outcome workshops” with partici-pating faculty to develop and refine outcome definitions and to trace these to courses to val-idate delivery.
The workshops resulted in the development of related BSSE program outcomes as well as outcomes for the BS programs housed in the same academic department—one in computer
science, the other in management information
systems.10 Table 5 provides the mapping of
these refined program outcomes to their equiv-alent general BSSE program outcomes.
Our department has since adopted these re-fined BSSE outcomes and reviews them annu-ally. The outcomes are the cornerstone for a continuous quality improvement (CQI) process aimed at improving the student-learning and program outcomes. These refined outcomes are important because they support both the anticipated ABET accreditation visit and Gan-non’s review of the program and its effective-ness. Biannually, we review the refined pro-gram outcomes and map them to individual course outcomes, for two reasons: to ensure program completeness and to collect objective
evidence needed for CQI work.9
W
hile extensive, the work wein-vested in program design has paid off so far: our institution has a new BSSE program, and early signs show that we have satisfied students. We hope that once the first graduates emerge, it will join the list of ABET-accredited BSSE programs.
Table 5
Mapping Gannon’s BSSE program outcomes to generic BSSE student outcomes
Gannon software engineering (BSSE) program outcomes Generic outcomes expected of BSSE graduates* 2006–7
1 2 3 4 5 6 7 8 9 10 11
Apply problem-solving strategies to software development X X X X Interface with business and analytical professionals to solve X X
software or systems development problems
Comprehend ethical decisions and their ramifications as X X X X X professionals
Demonstrate effective verbal, written, and listening communication skills as required for professional, group,
and team interactions X X X
Demonstrate the ability to continue professional development X X X X X and expand professional interests
Maintain a comprehension of changing technology and its X X ramifications
Realize and manage high-quality software development life- X X X X X X cycle processes in one or more application domains
Apply discrete mathematics and abstract structures to system X X development
Apply quantitative measures in the evaluation of software X X X X components and systems
*1–SE Mastery, 2–Related Disciplines, 3–Teamwork, 4–Conflict, 5–Application Domain, 6–Ethics, 7–Theory and Techniques, 8–Professional Practice, 9–Lifetime Learning, 10–Contemporary Issues, 11–Engineering Impact. Complete list of generic student outcomes is on pp. 29–30.
Acknowledgments
We thank and acknowledge the pioneering work of the SE program leaders who formed and led the Software Engineering Institute’s Working Group on Software Engineering and Education and Training. In particular, we acknowledge the program leaders at the Rochester Institute of Technology, Drexel University, Embry-Riddle Aeronautical University, and the Mil-waukee School of Engineering, from which our pro-gram development team drew inspiration, useful mod-els, critiques, and supportive advice.
References
1. Criteria for Accrediting Engineering Programs, Effective for Evaluations during the 2006–7 Accreditation Cycle, Accreditation Board for Eng. and Technology (ABET) Eng. Accreditation Commission (EAC), 2005; www. abet.org/forms.shtml.
2. Software Engineering 2004 Curriculum Guidelines for Undergraduate Degree Programs in Software Engineer-ing: A Volume of the Computing Curricula Series, tech. report, IEEE CS-ACM Joint Task Force on Computing Curricula, 2004; http://sites.computer.org/ccse. 3. Computing Curricula 2005, The Overview Report,
Cover-ing Undergraduate Degree Programs in Computer Engi-neering, Computer Science, Information Systems, Informa-tion Technology and Software Engineering: A Volume of the Computing Curricula Series, tech. report, IEEE CS-ACM Joint Task Force on Computing Curricula, 2005; www. acm.org/education/curric_vols/CC2005-March06Final.pdf. 4. J. Barrie Thompson, “Computing Curricula Software
Engineering—A Watershed in SE Education?”Proc. 28th Ann. Int’l Computer Software and Applications Conf.(COMPSAC04), 2004, p. 589.
5. A. Abran and J. Moore, eds., Guide to the Software Engineering Body of Knowledge, IEEE CS Press, 2004; www.swebok.org.
6. J. Diaz-Herrera, “Engineering Design for Software: On Defining the Software Engineering Profession,” Proc. 31st Am. Soc. Eng. Education/IEEE Frontiers in Edu-cation Conf., IEEE CS Press, 2001, T2D 1–7. 7. S. Frezza, S. Sasi, and J. Seol, “Report from the Trenches:
Applying the SEEK to BSSE Program Development,” Proc. 33rd Ann. Frontiers in Eng. Education Conf.(FIE 03), vol. 3, IEEE CS Press, 2003, pp. S3C 8–13. 8. P. Wankat and F. Oreovicz, “Chapter 4: Courses
Objec-tives and Text Books,” Teaching Engineering, McGraw Hill, 1993, pp. 46–65.
9. F.K. Mak and S.T. Frezza, “Process to Identify Mini-mum Passing Criteria and Objective Evidence in Sup-port of ABET EC2000 Criteria Fulfillment,” Proc. 2004 Am. Soc. Eng. Education Conf. (ASEE), Am. Soc. Eng. Education, 2004.
10. Gannon University Undergraduate Catalog 2006–2007, Gannon Univ. Press, 2006.
For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib
About the Authors
Stephen T. Frezzais an associate professor in the Computer and Information Science Department at Gannon University. His research interests include software engineering, auto-matic scheauto-matics generation, automated software testing, and the relationship between engi-neering and theology. He received his PhD in electrical engiengi-neering from the University of Pittsburgh. He’s a Certified Software Development Professional and a member of the IEEE, the ACM, and the Fellowship of Catholic Scholars. Contact him at Computer and Information Sci-ence, Gannon Univ., 109 University Square, MB 3181; [email protected].
Mei-Huei Tangis an assistant professor in the Computer and Information Science De-partment at Gannon University. Her research involves software engineering, object-oriented de-sign, software metrics, change impact analysis, software architecture, software reliability, and software testing. She received her PhD in computer science from the State University of New York at Albany and is a member of the ACM. Contact her at Computer and Information Science, Gannon Univ., 109 University Square, MB 3208; [email protected].
Barry J. Brinkmanis an assistant professor in the Computer and Information Science Department at Gannon University. His research interests include computer and network secu-rity and computer science education. He received his PhD in computer and information science from Ohio State University and is a member of the ACM. Contact him at at Computer and In-formation Science, Gannon Univ., 109 University Square, MB 3256; brinkman001@ gannon.edu.
