Content and Competencies for Interdisciplinary Teaching of Nonfunctional Software Requirements and User Experience in Computing Courses: An Asset Mapping of Curricular References Guidelines

This paper describes our innovative web based system, DoIT. DoIT is an acronym for Dynamic Curriculum Organisation by Innovation through Technology. IEEE-CS and ACM have been working on developing a comprehensive body of knowledge on software engineering (SWEBOK) [1]. Carnegie-Mellon Software Engineering Institute [CMU/SEI-99-TR-032] has produced a document that presents some guidelines for using the SWEBOK to support effective curriculum design. Our DoIT project has used the SWEBOK classification to map the core units in our current BSE curriculum against the SWEBOK knowledge key areas. In many engineering disciplines, the accreditation of university curricula and the licensing and certification of practicing professionals are taken very seriously. These are seen as critical to ensure upgrading of course content and structure where warranted to achieve improvements in the level of professional practice. Recognition of the core body of knowledge in a discipline is crucial to the development and accreditation of university curricula. DoIT system has been engineered in a systematic and disciplined manner and allows our Bachelor of Software Engineering students at Monash University to view the key areas of software engineering body of knowledge (SWEBOK) that they learn in their core subjects of study as they progress through our course. The main objective of the system is to provide an Internet facility for the students to learn about what they have learnt in their subjects in terms of SWEBOK objectives. The main inputs to DoIT are the SWEBOK key areas, our BSE core subjects mapped to SWEBOK and BSE student information extracted from Monash' student ORACLE database at the beginning of each new semester of our BSE course. Our BSE students are able to interact with the DoIT system to retrieve a personalized competency profile (PCP) at the completion of each semester of study. The contents visualized through the web site DoIT evolves as the students move through the course and works with up to date information about students. The web-based system, DoIT can be viewed at http://www.csse.monash.edu.au/~doit/. The learning outcomes from DoIT can be considered from three perspectives [2]. It is about:

Introduction Many authors (Graff & Van Wyk, 2002; Howard, 2005; Howard & LeBlanc, 2002; Lipner & Howard, 2005; Microsoft, 2009; Shumba, Walden, Ludi, Taylor, & Wang, 2006; Walden & Frank, 2006; Viega & McGraw, 2002, Viega & Messier, 2003) have discussed integration of the concept of security into the software life cycle; however, none of them has done so within the framework of the Software Engineering Body of Knowledge (SWEBOK). Moreover, from an academic point of view, few university software engineering courses or textbooks incorporate guidelines and practices related to software engineering. Most focus on securing only one phase of the development process, which is coding (Graff & Van Wyk, 2002; Howard & LeBlanc, 2002; Viega & Messier, 2003). From an industry point of view, current surveys indicate that we are far from being able to develop acceptably secure software systems, CERT (CERT, 2003; PricewaterhouseCoopers, 2004) having reported over 5,000 software vulnerabilities in 2005. One of the main reasons for this is that software engineers do not always have a strong background in computer security and lack expertise in secure software system development. In spite of this, in practice, they are asked to develop software systems that call for security features. Without appropriate methodologies and modeling languages to guide them during the development process, it is likely that they will fail to produce effective solutions (McDermott & Fox, 1999). Articulating a body of knowledge is an essential step in the development of a profession because it represents a broad consensus regarding the contents of the discipline. The IEEE Computer Society, with the support of a consortium of industrial sponsors, has published the Guide to the Software Engineering Body of Knowledge (SWEBOK). It has also gained international recognition as ISO Technical Report 19759. Although the concept of security is not explicitly referred to in it, the Guide describes generally accepted knowledge about software engineering, and its ten knowledge areas summarize basic concepts and include a list of references to detailed information. This paper takes from the Guide a summary of the guidelines and practices that can measurably reduce software requirements, as well as design and implementation defects, and improve the education of current and future software developers. Our paper introduces a new way of teaching secure software engineering based on the SWEBOK Guide. This work differs from others by the following outcomes: * The topic of security will be highlighted through the SWEBOK Guide. * The summary of guidelines and practices are derived from the SWEBOK Guide to secure requirements analysis, design, implementation, and testing phases * The proposed topics to be covered in the course during the academic term are provided based on the SWEBOK Guide. Differences between our work and that of others are more detailed in the Literature Review section. The paper summarizes the guidelines and practices derived from the SWEBOK Guide in the Proposed Guidelines and Practices based on SWEBOK section. In the Proposed Course Topics section, it describes the detailed topics to be covered during the academic term, and in the section Suggested Recommendations to Enhance SWEBOK Guide we recommend some possible additions for SWEBOK 2010. The conclusions and our plans for future work are introduced in the last section. Literature Review Many authors have discussed the integration of security into the coding phase of the development process (Graff & Van Wyk, 2002; Howard & LeBlanc, 2002; Microsoft, 2009; Viega & McGraw, 2002, 2003). Howard and Leblanc (2002) described the best practices for writing secure code and stopping malicious hackers in their tracks, based on the knowledge of top security experts at Microsoft. …

This paper describes our innovative web based system, DoIT. DoIT is an acronym for Dynamic Curriculum Organisation by Innovation through Technology. IEEE-CS and ACM have been working on developing a comprehensive body of knowledge on software engineering (SWEBOK) [1]. Carnegie-Mellon Software Engineering Institute [CMU/SEI-99-TR-032] has produced a document that presents some guidelines for using the SWEBOK to support effective curriculum design. Our DoIT project has used the SWEBOK classification to map the core units in our current BSE curriculum against the SWEBOK knowledge key areas. In many engineering disciplines, the accreditation of university curricula and the licensing and certification of practicing professionals are taken very seriously. These are seen as critical to ensure upgrading of course content and structure where warranted to achieve improvements in the level of professional practice. Recognition of the core body of knowledge in a discipline is crucial to the development and accreditation of university curricula. DoIT system has been engineered in a systematic and disciplined manner and allows our Bachelor of Software Engineering students at Monash University to view the key areas of software engineering body of knowledge (SWEBOK) that they learn in their core subjects of study as they progress through our course. The main objective of the system is to provide an Internet facility for the students to learn about what they have learnt in their subjects in terms of SWEBOK objectives. The main inputs to DoIT are the SWEBOK key areas, our BSE core subjects mapped to SWEBOK and BSE student information extracted from Monash' student ORACLE database at the beginning of each new semester of our BSE course. Our BSE students are able to interact with the DoIT system to retrieve a personalized competency profile (PCP) at the completion of each semester of study. The contents visualized through the web site DoIT evolves as the students move through the course and works with up to date information about students. The web-based system, DoIT can be viewed at http://www.csse.monash.edu.au/~doit/. The learning outcomes from DoIT can be considered from three perspectives [2]. It is about: Students' learning about what they have learnt in terms of course content shown as knowledge areas covered in SWEBOK objectives. Lecturing staff and curriculum designers able to track the curriculum and see how the various topics relate together, and ascertain if there are any overlaps and gaps in knowledge. The educational institution able to see the organisational knowledge assets in terms of graduate capabilities from our course.

The Guide to the Software Engineering Body of Knowledge (GSWEBOK) is a good first step in characterizing the contents of the software engineering discipline and in providing a topical access to the Software Engineering Body of Knowledge (SWEBOK). However, the GSWEBOK is seriously lacking as a guide to how the SWEBOK can be used to explore system failures as a way of enhancing practitioner's preparations for the software engineering profession. This lack is not limited to the Guide. This is why it is very important, in order that software system failure may be understood from a software engineering point of view, that a new conception of what the SWEBOK is, as well as new approaches to its access, need to be developed.

This paper is the result of a workshop held in Montreal in October 2002 during the Software Technology and Practice Conference (STEP 2002). The purpose of the paper is to present a preliminary mapping of two related but distinct software engineering body of knowledge initiatives, and also a list of proposals to improve them: the guide to the Software Engineering Body of Knowledge (SWEBOK) and the Software Engineering Education [body of] Knowledge (SEEK). The SWEBOK guide is aimed at identifying and describing the body of knowledge of a software engineering professional who has an undergraduate degree and four years of experience. The intended audiences of the SWEBOK Guide include industry, academia and policy-making organizations. The SEEK is aimed at delimiting the knowledge that professionals teaching software engineering agree is necessary for anyone to obtain an undergraduate degree in this field. The mapping shows that, though there are no major school of thought divergences between the two bodies of knowledge, there are a number of differences in the details of each breakdown in terms of vocabulary, level of detail, decomposition approach and topics encompassed.

The fields like Software Engineering (SE) and Human Computer Interaction (HCI) are considered dissimilar.. SE based process model mostly discuss modeling of functional requirement while the HCI based approaches are mostly concerned with the modeling of quality attributes. The quality attributes are mostly discussed during late phases of software development. The non-functional requirements as quality attributes can be integrated in software products by considering quality or non-functional modeling approaches during all of the phases of software engineering process model. The separation of SE and HCI concerns restricts formal specification of quality attributes during all of the phases of SE process model. The software systems or products are generally less user centered because SE process models can’t address formal specification of quality attributes in SE process models. In this research a methodology for the formal specification of approaches that model functional requirements and quality attribute during SE process model is proposed. The proposed methodology is based on waterfall SE process model. It can be utilized in design and development of users centered software products. Our proposed methodology also bridges gap between SE and HCI fields.

Problem-Based Learning (PBL) has often been seen as an all-or-nothing approach, difficult to apply in traditional curricula based on traditional lectured courses with exercise and lab sessions. Aalborg University has since its creation in 1974 practiced PBL in all subjects, including computer science and software engineering, following a model that has become known as the Aalborg Model. Following a strategic decision in 2009, the Aalborg Model has been reshaped. We first report on the software engineering program as it was in the old Aalborg Model. We analyze the programme wrt competence levels according to Bloom’s taxonomy and compare it with the expected skills and competencies for an engineer passing a general software engineering 4-year program with an additional 4 years of experience as defined in the IEEE Software Engineering Body of Knowledge (SWEBOK) [Abran et al. 2004]. We also compare with the Graduate Software Engineering 2009 Curriculum Guidelines for Graduate Degree Programmes in Software Engineering (GSwE2009) [Pyster 2009]. We then describe the new curriculum and draw some preliminary conclusions based on analyzing the curriculum according to Bloom’s taxonomy and the results of running the program for 2 years. As the new program is structured to be compliant with the Bologna Process and thus presents all activities in multipla of 5 European Credit Transfer System points, we envision that elements of the program could be used in more traditional curricula. This should be especially easy for programs also complying with the Bologna Process.

SECDEP: Software engineering curricula development and evaluation process using SWEBOK

The Software Engineering Body of Knowledge (SWEBOK) provides generally accepted knowledge for the software engineering profession. The SWEBOK had been designed to guide the in-house developers and software contractors but the current trend is that it is being used by the innovators. Thus, the SWEBOK has very little guidance for the emerging role. The focus of the innovators will be to improve the business processes as well as study the business practice to learn the concealed requirements of the customer. This paper is an attempt to analyze the existing proposals on the SWEBOK contents, structure, and make a proposal on what kind of contents it should have, and how it should be structured so that the innovators as well as in-house and software contractors can have proper guidance and can benefit from it.

The software engineering institute published the last reference curriculum for a master's in software engineering in 1991. In 2007, a coalition from academia, industry, and government began creating a new reference curriculum. An early step was to establish a baseline of graduate education by surveying 28 master's programs in software engineering. The survey was largely limited to US schools. Key findings showed that the universities viewed software engineering largely as a specialization of computer science, that faculty size is generally small with few dedicated professors, and that new master's programs continue to start despite the decrease in computer science majors over the past few years. We used the IEEE Computer Society's Software Engineering Body of Knowledge (SWEBOK) to structure our analysis of the 28 curricula, focusing primarily on courses and topics required or semirequired of all students. (A course is semirequired if there is at least a 50 percent chance a student must take it.) Major findings show wide variation in the depth and breadth of SWEBOK coverage in required and semirequired courses, less than 40 percent of all programs requiring an introductory course on software engineering, and many universities having required and semirequired courses that are peripheral to SWEBOK.

The Road Map to Software Engineering: A Standards-Based Guide by James Moore is recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society as a useful guide for software practitioners applying software engineering standards. Using software engineering standards in producing effective software This book provides a single overview of codified software engineering, the set of knowledge and best practices that apply to most projects most of the time. By laying out the accepted techniques, the text allows managers—as well as those paying the bill—to eliminate wasteful experimentation with unproved software practices while giving more attention to true innovations. Prepared in accordance with the Guide to the Software Engineering Body of Knowledge (SWEBOK), The Road Map to Software Engineering organizes relevant IEEE software and systems standards, along with standards from other sources, using two framewor s: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. Each framework reinforces the other, showing when other standards should be applied, as well as how they relate to one another. The Road Map to Software Engineering allows practitioners to quickly locate the standards pertinent to questions arising in real projects. Providing students with a comprehensive body of knowledge, the text also assists experienced professionals in finding and filling gaps in their understanding. Endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society, this book is a useful guide for both practitioners and students.

The Road Map to Software Engineering: A Standards-Based Guide by James Moore is recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society as a useful guide for software practitioners applying software engineering standards. Using software engineering standards in producing effective software This book provides a single overview of codified software engineering, the set of knowledge and best practices that apply to most projects most of the time. By laying out the accepted techniques, the text allows managers—as well as those paying the bill—to eliminate wasteful experimentation with unproved software practices while giving more attention to true innovations. Prepared in accordance with the Guide to the Software Engineering Body of Knowledge (SWEBOK), The Road Map to Software Engineering organizes relevant IEEE software and systems standards, along with standards from other sources, using two framewor s: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. Each framework reinforces the other, showing when other standards should be applied, as well as how they relate to one another. The Road Map to Software Engineering allows practitioners to quickly locate the standards pertinent to questions arising in real projects. Providing students with a comprehensive body of knowledge, the text also assists experienced professionals in finding and filling gaps in their understanding. Endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society, this book is a useful guide for both practitioners and students.

Identifying an agreed body of knowledge is an essential step in moving software engineering from an ideal to a recognized profession. Sponsored by the IEEE Computer Society and managed by the Université du Québec à Montréal, the Software Engineering Body of Knowledge (SWEBOK) project is developing a guide to the body of knowledge of software engineering. A trial version of the guide is currently available without charge at http://www.swebok.org . Following an additional two years of trial usage and feedback, the project will revise the Guide. This article will begin by discussing the desired characteristics of a profession for software engineering. Then the objectives and contents of the Guide are described. Finally, the SWEBOK project and its future will be described.

This paper provides a summary of the proceedings of a panel on the Guide to the Software Engineering Body of Knowledge (SWEBOK) held under the auspices of the Thirty-Fourth International Conference on Software Engineering and Knowledge Engineering (SEKE 2022), as well as the discussion that ensued thereafter among the panelists. In this regard, a synopsis of the underlying motivation and structure of SWEBOK is given, and the means for integrating SWEBOK in software-intensive organizations and educational institutions offering software engineering-related courses are highlighted and illustrated by pedagogically-oriented examples.

Students and instructors struggle to provide an integrated view of learning content that is spread over personal and shared file systems, course management systems, team project repositories, wikis, blogs, and other content storage and retrieval systems. Further, they struggle to organize this content when each system provides a different organizational mechanism and strategy. Course management systems fragment content by semester, course, and class session. File systems fragment content into hierarchically organized folders and files with only folder and file names to describe the content. Project repositories fragment information into versions, artifact types, and subsystems organized as folders. It is especially a challenge for a student who does not yet have the knowledge for how to organize and describe their learning content. We have developed an initial version of a learning and knowledge management system and piloted it for an Introduction to Software Engineering course. To hold the common repository of learning content, we used digital library technology. To organize content, we tagged content using subject headings based on the Software Engineering Body of Knowledge (SWEBOK) subject taxonomy. Instructors and students can contribute content, tag it using SWEBOK and other terms, and search through it using SWEBOK and other terms. The results of our pilot were mixed. A digital library-based repository is insufficient for dynamically changing and evolving content. A significant amount of learning content needs to be provided (more than for just one course), and there needs to be one location of record for accessing content, rather than multiple locations. A positive result was some validation that using SWEBOK to organize, tag, and search for content is helpful in readily accessing information and helping provide students with an understanding of the organization of knowledge of their discipline. Since the main intent of this research project was to gain some operational experience and initial validation of using a domain-specific taxonomy to organize learning content, we consider the project to be a success.