Next Article in Journal
Systematic Review on Inclusive Education, Sustainability in Engineering: An Analysis with Mixed Methods and Data Mining Techniques
Next Article in Special Issue
Challenges for Open Education with Educational Innovation: A Systematic Literature Review
Previous Article in Journal
Identification of New Biocontrol Agent against Charcoal Rot Disease Caused by Macrophomina phaseolina in Soybean (Glycine max L.)
Previous Article in Special Issue
IC-Health Project: Development of MOOCs to Promote Digital Health Literacy: First Results and Future Challenges
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Review

Open BOK on Software Engineering Educational Context: A Systematic Literature Review

by
Pablo Alejandro Quezada-Sarmiento
1,*,
Jon A. Elorriaga
1,
Ana Arruarte
1 and
Hironori Washizaki
2
1
Computer Languages and Systems Department, University of the Basque Country UPV/EHU, 649 Postakutxa, 20080 Donostia, Spain
2
Department of Computer Science and Engineering, Waseda University, Tokyo 169-8050, Japan
*
Author to whom correspondence should be addressed.
Sustainability 2020, 12(17), 6858; https://doi.org/10.3390/su12176858
Submission received: 15 July 2020 / Revised: 19 August 2020 / Accepted: 21 August 2020 / Published: 24 August 2020
(This article belongs to the Special Issue Opportunities and Challenges for the Future of Open Education)

Abstract

:
In this review, a Systematic Literature Review (SLR) on Open Body of Knowledge (BOK) is presented. Moreover, the theoretical base to build a model for knowledge description was created, and it was found that there is a lack of guidelines to describe knowledge description because of the dramatically increasing number of requirements to produce an Open BOK, the difficulty of comparing related BOK contents, and the fact that reusing knowledge description is a very laborious task. In this sense, this review can be considered as a first step in building a model that can be used for describing knowledge description in Open BOK. Finally, in order to improve the educational context, a comparison among BOK, structure, and evolution is conducted.

1. Introduction

According to [1], a Body of Knowledge (BOK) is a concept used to represent concepts, terms, and activities that make up a professional domain. In addition, an Open BOK is necessary because it allows us to develop the abilities and talents of professionals in different Knowledge Areas (KAs) [2].
The goal of knowledge description is to reach a consensus on the core subsets of the knowledge characterizing engineering disciplines [3], and it is a well-known fact that developing an Open BOK is a complex task. This is done by considering the fact that knowledge can often be represented as interconnected BOK, KAs, Knowledge Units (KUs), and Knowledge Topics (KTs) [3].
The main guide that is used for the description of the necessary knowledge of technical academic disciplines is Software Engineering Body of Knowledge (SWEBOK V. 3.0) [3], which generally describes accepted knowledge about Software Engineering (SE). This guide is taken as a reference for the implementation of SE in industrial contexts [4,5,6], in educational contexts [7,8,9,10], and in Information Technology (IT), Governance, where the focus is on how the knowledge is being described [11].
In accordance with [12], from 2000 to 2010, knowledge was represented as knowledge, skills, and attitudes accepted and applied by investment professionals worldwide.
Furthermore, in [13] it is mentioned that knowledge was often written in a specific language with rules and algorithms that are not compatible with other Knowledge-Based Information Technology (KBE-IT) frameworks. In short, articulating an Open BOK is of paramount importance, because it is an essential step to develop an academic profession [14]. Nevertheless, a set of widely agreed guidelines on how to develop these BOKs and, more specifically, on the way to describe the knowledge, is not yet available.
The above-mentioned lack of guidelines to describe knowledge may dramatically increase the required effort to produce a BOK, makes it very difficult to compare BOKs addressing closely related disciplines, and makes it even more difficult to reuse knowledge descriptions when necessary.
In order to find a solution to this problem, this review presents a Systematic Literature Review (SLR) on different ways in which knowledge can be described, and how it should be structured. As part of the study carried out in this review, the relevance and usefulness of a BOK approach for different communities of stakeholders are also analyzed.
The open description of BOK in the educational context provides the basis for curriculum development, professional development, and current future certification schemas [3]. Open BOK promotes integration and connections with related disciplines in the educational context. Educational professional communities have created and used Open BOKs to consolidate their discipline, standardize practices, improve processes, and warehouse community knowledge.
In the same context, Open BOK has been used across different types of disciplines. The Open BOK could also be used by individuals for extending their skills and for career development. Researchers may find it useful for identifying technology applicable to their research and to help define the skills required for a research team.
The outline of this review is as follows: Section 2 is aimed at carrying out the analysis of related research works; Section 3 is devoted to describing the research methodology used in this paper; Section 4 shows the result and discussion; and the conclusions are given in Section 5.

2. Related Works

In the scientific literature, there is a great number of researches works on the knowledge description for Open BOK. For example, in [15], a BOK is built upon published research, [16] describes a BOK that has been modeled for software development, [17] shows representation and scientific reasoning used for the description of knowledge, [18] shows different elements needed to describe a given knowledge in engineering, and [19,20,21] show the usage of skills, attitudes, abilities, and capabilities to describe knowledge for BOK.
In addition, a conceptual model to describe knowledge is discussed in [22], and a framework for structured knowledge is shown in [23]. The framework created in [23] is aimed at facilitating the design of an adaptive knowledge management system, and the structural knowledge model is combined with processes that are used for ensuring the quality of knowledge acquisition in the framework. Moreover, in [23], the achievement levels needed for entry into professional practice and the roles of education and experience were addressed.
In [24], BOK is relevant to many and varied engineering stakeholders and scientific communities.
The analysis of references for Systems Engineering Body of Knowledge (SEBOK) is carried out in [25], and [26,27] show both the application of two more detailed guidelines structures (i.e., SWEBOK and SE2004) and a taxonomy that is applied in Software Engineering, which is done in order to examine recommendations and suggest an appropriate subset of topic areas for a software engineering service course.
In [28,29], a technical review on the software development knowledge area is aligned with an engineering perspective to assess a version of the SWEBOK Guide, and [30,31,32,33] show how stakeholders use knowledge to describe BOK. These studies symbolize a significant contribution to the Requirements of Engineering Body of Knowledge, and [34] presents solutions in the form of a mobile application that improves performance reporting for the Project Management Bodies of Knowledge (PMBOK) framework are presented.
In [35], within the context of natural resources management, stakeholders use BOK to manage the production and application of knowledge in a social context.
Also, in [36,37,38,39], stakeholders use BOK to develop academic programs where parameters can be synthetized to describe knowledge. Finally, BOKs such as the ones presented in [40,41,42,43,44,45,46,47,48,49,50,51], show further structures and guidelines to describe knowledge.

3. Methodology

Systematic reviews involve identifying, synthesizing, and assessing all available evidence, quantitative and/or qualitative, in order to generate a robust, empirically derived answer to a focused research question [52,53,54]. In this review, the SLR method was used as the research methodology.
According to Kitchenham, B.A. [54], the SLR was proposed in Software Engineering Research as a method to report reliable conclusions about a research area while systematically collecting quality pieces of evidence in knowledge description for BOKs.
Phases of a SLR—The review of the state of the art of BOKs was carried out by following the guidelines proposed in [52,53,54,55,56,57,58,59], where three main phases of an SLR were suggested. These phases are the following (see Figure 1):
Planning the review—This phase is aimed at developing the review protocol, which defines the methods to undertake a specific SLR, reducing the possibility of it being driven by research expectations. A detailed explanation of this phase is given in Section 3.1.
Conducting the review—This phase is aimed at executing the previous protocol. A detailed explanation of this phase is given in Section 3.2.
Reporting the review—This phase is aimed at providing the obtained results to the community. A detailed explanation of this phase is given in Section 3.3.

3.1. Planning the Review

This phase consists of developing a review protocol. The review protocol defines the methods to undertake a specific systematic literature review (SLR), reducing the possibility that this review is driven by research expectations. Protocol development must specify (i) the review objective and research questions, (ii) the search strategy, (iii) the explicit inclusion and exclusion criteria, (iv) the criteria to evaluate each study, and (v) the data extraction strategy and the strategy for synthesizing extracted data.
For the case under study, in this phase, the steps that were followed to implement the protocol were established. Moreover, the objectives were reviewed, and the necessary research works to describe Open BOK was searched for. Then, the following learned lessons were identified: needs, problems, and challenges to determine the elements, structure, and context of an Open BOK.
Next, taking into consideration the above information, the Research Questions (RQs) were defined:
  • RQ1: What are the necessary elements needed to describe knowledge in Open BOK?
  • RQ2: What is the structure of BOKs to develop a guide of knowledge in an educational context?
The search strategy for planning the review started with the identification of most relevant data bases in order to determine the Primary Studies (PS).
These most relevant data bases are shown in Table 1.
For all scientific areas, there is a specific database or at least some multidisciplinary one; therefore, the databases used in the review in relevant information, updating, accurate, proven, and quality in the area of Open BOK in an educational context.
Second, once the previously-mentioned databases were identified, the searching chains were formed to determine the PS.
Third, the relevant documents for answering the RQs were identified, and the criteria for the inclusion and exclusion documents of BOK were established. The review protocol also specifies inclusion criteria (IC) and exclusion criteria (EC), which determine whether each potential study should be considered or not for SLR.
Finally, a way for extracting these documents was found. An automatic search was realized in the scientific electronic databases and validated by SLR protocol [54].
One important point is that many articles of this research are indexed on the Scopus database.

3.2. Conducting the Review

Once it was clear what was going to be done in the planning phase, the search for PS was carried out at each database, in order to answer the RQs.
Firstly, to conduct the search for PS, the following key words were used: (a) Body of Knowledge, (b) Area Breakdown, (c) Component, (d) Guide, (e) Engineer, (f) Software, (g) Structure, and (h) Software Engineering Body of Knowledge. Moreover, alternative spellings and acronyms for major terms were used, such as: Information Technology BOK, SWEBOK, Open BOK. After that, the general search string was formed.
This string was the following: “OBOK” OR “Open Body of Knowledge” AND “SE” OR “Software Engineering” AND “Area Breakdown” OR “Software Engineering Body of Knowledge” OR “importance of Open BOK.” OR “Component”, “OR” Design” AND “Education”.
Moreover, the other documents related to the RQ were retrieved from different resources. Then, the total PS and relevant documents increased to 161. In Figure 2 the PS by type.
Table 2 provides an overview of the distribution studies grouped on their publication channel and classified by years. All studies fulfilled the criteria for quality assessment proposed in this SLR.
Furthermore, the research work presented in this article considered some inclusion and exclusion criteria to identify those PS that provided direct evidence to answer the RQs. Additionally, in order to reduce the likelihood of bias, the selection criteria were decided during the protocol definition. Here, the selection of PS was a multi-stage process [60].
Initially, the selection criteria were openly interpreted. Next, these criteria were refined to avoid duplication of information [61]. SLR requires explicit inclusion of some exclusion criteria to assess the fitness of the information in each PS to respond to the RQs [53].
The lists of IC and EC for the present SLR are shown below:
Inclusion criteria (IC):
  • Scientific Material (SM) is a general term that includes papers, short papers, experience reports, and summaries of workshops. SMs (i.e., journal articles, proceedings of conferences, workshops, and technical reports), written in English, and digitally accessible were included.
  • The paper should be focused on Open BOK.
  • The paper should be focused on Educational context based in Open BOK.
Exclusion criteria (EC):
  • Documents in computer science but not related to Open BOK.
  • Documents related to BOK but not related to the RQ of this study.
  • Remove false positives. That is documents that were not part of the research in the search string were discarded.
  • Poor arguments—that is, studies with low relevance according to the research—were excluded. In this context, to guide the interpretation of findings in the included studies and determine the strength of inferences, we evaluated the scientific quality criteria of the selected studies in order to determine the relevance of the results obtained in the review conducted. These criteria indicate the credibility of an individual study when synthesizing results. The result of the quality assessment of the included studies can reveal the potential limitations of the current search and guide future research in the field [57].
Kitchenham’s guidelines [54] “suggest performing a quality assessment of each included study; it complements the IC and EC defined above”. However, there is no universal agreed definition of “quality”. The Critical Appraisal Skill Programme (CASP) (http://www.casp-uk.net/appraising-the-evidence) defines criteria for assessing the quality of qualitative research. This systematic review has used the quality criteria defined for CASP and those proposed by Dybå et al. [61]. The criteria cover three main issues: rigor, credibility, and relevance. Briefly, we summarize the quality assessment form defined by [61] in Table 3.
In addition, the method proposed by Ivarsson and Gorschek [57] has been previously used together with systematic mapping studies in the educational domain [54]. Therefore, it is also applicable to Systematic Literature Reviews, and it has been applied to this review. The model provides a set of rubrics to measure rigor and relevance for the industry. Rigor refers to the precision or exactness of the used research method and how the study is presented. The model in [58] defines three aspects to measure rigor: context described, study design described, and validity discussed. Each of one of these aspects is associated with the values described in Table 3. As a result, we have measured the quality of our study from different perspectives to provide more rigor and credibility to our review results.
Reduction ad absurdum—that is, those studies that did not fulfill the IC—were excluded.
In order to interpret the findings in PS, the importance of the scientific quality of the articles under study was determined. The above inclusion and exclusion criteria indicated the credibility of the analyzed PS and identified potential limitations of the current search [55,56,57,58].
Finally, as part of this SLR phase (i.e., conducting the review), the data extraction strategy allowed us to identify the required information to answer the RQs.

3.3. Reporting the Review

This SLR phase consisted of the following steps:
First, the primary article information was extracted. Here, Electronic Sheets, Mendeley, and Atlas TI 8.0 as software tools were used [62].
With the aim of addressing the research questions posed in the review, electronic sheets allowed us to organize the relevant information of each one of the primary studies and evaluate their contribution.
Mendeley allowed us to organize the bibliographic references that are the scientific basis of this review.
In this revision, Atlas TI allowed associating codes or labels with fragments of text [63], from the primary studies and creating the concept networks that will be the basis of the description model. Furthermore, Atlas TI allowed us to search for pattern codes, classify them to establish the elements to describe an Open BOK in the educational context (see Supplementary Materials).
Second, the obtained information was synthesized to understand the Open BOK in an educational context.
Third, the data extraction forms were developed and uploaded in an online repository. At this point, it is important to mention that the synthesis strategies are important not only because they include multiple publications of the same data in an SLR, but also because they prevent duplicated reports that could bias the study results.
In Section 4, the most relevant information to support this research is included. Figure 3 shows the SLR synthesis process.
The reporting of the review phase was supported by the quality analysis that was performed for each primary study.
This validity is seen as the relevance of the Open BOK in different KA. Moreover, to develop the quality analysis, Atlas TI was set to use 8 codecs and 88 subcodecs, which were established based on the density and importance of each concept, and their relationship with the family of concepts (see Figure 4).
Moreover, the codes, quotation, and neighbors of one PS are shown in Figure 5.
Aligned with [64], the next step to building the knowledge model was to use the thematic synthesis to represent the Open BOK description problem. In order to obtain the concept networks, the iterative cycle was designed. Then, the concept networks were grouped into categories. After that, for each category, iterations were created, and representations schemes were created as well. Next, a narrative synthesis was made to establish the relationship among concepts. Finally, the description model for BOK was created (see Figure 6).

4. Results and Discussion

This section is devoted to showing the main results and discussion of the research work on the context, elements, and structure of Open BOK that allowed to establish a correct description of knowledge.

4.1. Open BOK Context

First, Open BOK is used by those who are interested in expanding their skills and professional training in different areas of knowledge. For the scientific community, BOK allows for the widening of the spectrum of research fields based on consensus and highlights similarities between disciplines [65]. For example, BOK highlights techniques used in materials science that are common between chemistry and physics [66].
Regarding the knowledge levels of a BOK, the amount of knowledge that will be offered within an educational program is defined in [67]. BOK has a specific structure according to the area of engineering or science in which they are applied.
Second, according to [36,66], to establish the description of the BOK, it is necessary to consider the Core Book (CB), and Context Domain (CD) of the BOK study area. In the same way, BOK must establish their respective KAs. Each description of KAs should use the structure shown in [3].
Moreover, as part of this second finding, it can be said that KA divided into smaller divisions called KU [33,36,64,66], which represent individual thematic modules within a KA. Each KU is subdivided into a set of topics, which are the lowest level of the hierarchy. The themes depend on the evolution and context of the KAs and the discipline.
Third, in the Open BOK context, it is also necessary to standardize a knowledge updating process according to how advanced the discipline is and the existing needs of the communities. In general, BOK has different committees, organizations, and collaborative groups that develop and update their contexts considering the progress of science and its areas of knowledge.
Fourth, in order to build an Open BOK with a bottom-up approach (Knowledge Sweep), researchers must consider the ‘materials’ from which the knowledge is extracted by the discipline-directed. When analyzing these materials, it is assumed that a certain degree of knowledge could be obtained and used to formulate an Open BOK.
The reference materials will be the scientifically agreed information [2,3,9,10], and the matrix of topics is divided into details in order to establish its relationship with the respective materials.
Moreover, a list of readings should be considered to complement the information of the proposed KAs. In the same context, when an Open BOK knowledge is developed, it is necessary to establish the origin of the information.
Fifth, it was found that there exist structures, elements, descriptions, and learned lessons of the BOK evolution. In order to show the evolution of BOK, this review provides the structure, versions, and learned lessons synthesized in Table 4.
Sixth, another finding of this article is the establishment of a general structure of an Open BOK in engineering. This structure begins with the set of KAs, continues KUs, and ends with topics according to the research area.
Seventh, Open BOKs provide the foundation for curriculum development and maintenance [69].
Open BOK promotes integrations and connections with other related disciplines [70].
Eighth, at the level of professional education in engineering contexts BOK, should provide the following detail levels [70]:
  • Know the basic concepts and the main areas of application.
  • Know the basic technologies and their relationship with basic concepts.
  • Know both authorized and unauthorized sources of information, and how to evaluate the quality of the information.
  • Have the ability to work with standards.

4.2. Open BOK in an Educational Context

Furthermore, as part of this finding, educational programs in engineering and engineering technology have been developed to address many aspects associated with computer science [71]. For example, the BOK of Computer Science Technology, the SWEBOK, and the IT BOK are based on inputs provided from various perspectives, including industry demand, previous works in the creation of computer BOKs, and institutional factors.
Knowledge should reflect current best practices, which inevitably change over time. However, updates cannot be carried out in an uncontrolled manner, since associated conferences and other educational materials must be kept in line with the BOK [72].
Finally, other important factors to consider in BOK are the Stakeholders [9], which are people, groups, companies, and either organizational or governmental entities that have an interest in educational programs.
All interested parties must be identified as well as their responsibilities towards educational programs based on BOK (RaPSEEM) [71]. An Open BOK has an important role in the advancement of an area as a knowledgeable practice [72]. SE is a young field of human experience if compared with others. However, the knowledge in this field has evolved at a very high speed, which is a characteristic of Computer Science in general [73].
SWEBOK provides a consensually validated characterization of the bounds of the software engineering discipline and to provide access to the BOK supporting that discipline [74]. On the other hand, SWEBOK [3] is oriented toward the private and public sector for this reason, the aims of the SWEBOK guide in the process of training, education, and evaluation of professional of software engineering. The SWEBOK knowledge architecture in this report provides a hierarchical description and decomposition of a body of knowledge for software engineering [75].
For the purposes of this article, the term “knowledge” is used to describe the whole spectrum of content for the discipline: information, terminology, artifacts, data, roles, methods, models, procedures, techniques, practices, processes, and literature [76].
The GSWEBOK is a good first step in characterizing the contents of the software engineering discipline and in providing topical access to the SWEBOK.
Figure 7 shows the three levels of abstraction and the relationships that were used in modeling SWEBOK v 3.0.
A hierarchical description of software engineering knowledge that organizes and structures the knowledge into three levels of hierarchy KC, KA, and KU [3]; in the same context, the highest level of the hierarchy is the education KA, representing a particular subdiscipline of SE that is generally recognized as a significant part of the SWEBOK that an undergraduate should know [48]. In particular, the curricular recommendations for an undergraduate degree program as put forward by the Working Group on SEET are considered [77].

4.3. Elements to Describe Knowledge on Open BOK

The Curriculum of SEE evolved in terms of a new design, revised, minor and major changes [78]. Software engineering curriculum (SEC) implementation and assessment in academia took place in different regions all over the world [79]. The process of building the Open BOK should assist in highlighting similarities across disciplines, for example, techniques used in materials science [80].
Elements needed to describe Open BOK is presented in Table 5. These elements permit an adequate description of Open BOK.

5. Conclusions

In this review, an SLR was carried out to determine the structure, elements, and learned lessons to describe knowledge for an Open BOK. Here, the general structure to develop a model to describe Open BOK was established, and the relationship between Open BOK and other scientific disciplines was established, as well.
It is important to mention that an Open BOK allows curricular and professional development with their respective certifications that contribute to the correct training of engineers and their contribution to society. The knowledge description for Open BOK presented in this article defined a set of knowledge, skills, concepts, and behavior that stakeholders and the related disciplines need for the correct consensus. Moreover, this knowledge description for Open BOK allowed us to have a validated classification of the boundaries of the disciplines that will support Open BOK. The BOKs described in this review showed the hierarchical structure of the content of each KA.
The Open Body of Knowledge provides the basis for curriculum development and maintenance and supports professional development and any current and future certification schemes. Lastly, it promotes integration and connections with related disciplines.
Another result of this research is that the Knowledge Description Model for Open BOK helps to determine the training needs of future professionals, allowing them to acquire strong competences in social, business, educational, and industrial fields.
One more result of this review was that it was found that the Knowledge Description of Open BOK can be used as a guide to assess and improve disciplines or scientific areas.
An additional result of this research is that learned lessons can be generalized to comparable courses that are taught at many academic institutions. Furthermore, it can be said that Open BOK provides the basis for curriculum development and maintenance and support professional development as continuous improvement of BOK certification.
Finally, in this review, a general structure of an Open BOK for engineering was established. This structure consisted of sets of KAs that contain KU, KTs, and KSs.

Supplementary Materials

The following are available online at https://www.mdpi.com/2071-1050/12/17/6858/s1 (1) BOK Codes (DescriptionofBOK) Atlas T.i.80 report; (2) Documents Reports; (3) Cloud Words about BOK; (4) Data extraction forms (.xlsx file).

Author Contributions

Conceptualization, P.A.Q.-S., J.A.E., A.A., and H.W.; Systematic Literature Review(SLR), P.A.Q.-S., J.A.E., and H.W.; Methodology, P.A.Q.-S., A.A., Codec Analysis P.A.Q.-S, H.W.; qualitative and quantitative analysis P.A.Q.-S., J.A.E., A.A.; investigation P.A.Q.-S., J.A.E., A.A., and H.W.; resources, P.A.Q.-S., A.A.; writing—original, P.A.Q.-S.; draft preparation P.A.Q.-S., J.A.E., A.A, and H.W.; validation A.A.; writing—review and editing, P.A.Q.-S., A.A.; visualization, J.A.E.; supervision, J.A.E., A.A. All authors have read and agreed to the published version of the manuscript.

Funding

This work is supported partially by RTI2018-096846-B-C21 (MCIU/AEI/FEDER, UE) and ADIAN grant IT980-16 (BasqueGovernment).

Acknowledgments

A special acknowledgment to Wilmar Hernández Perdomo for his support in this research.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Penzenstadler, B.; Fernandez, D.M.; Richardson, D.; Callele, D.; Wnuk, K. The requirements engineering body of knowledge (REBoK). In Proceedings of the 21st IEEE International Requirements Engineering Conference (RE), Rio de Janeiro, Brazil, 15–19 July 2013; pp. 377–379. [Google Scholar] [CrossRef]
  2. Ardis, M.; Bourque, P.; Hilburn, T.; Lasfer, K.; Lucero, S.; McDonald, J.; Shaw, M. Advancing Software engineering professional education. IEEE Softw. 2011, 28, 58–63. [Google Scholar] [CrossRef]
  3. Bourque, P.; Dupuis, R. Guide to the Software Engineering Body of Knowledge 2014 Version, SWEBOK. 2014. Available online: https://www.computer.org/education/bodies-of-knowledge/software-engineering (accessed on 18 March 2020).
  4. Pérez, F.; Marcen, A.C.; Lapena, R.; Cetina, C. Evaluating Low-cost in internal crowdsourcing for software engineering: The case of feature location in an industrial environment. IEEE Access 2020, 8, 65745–65757. [Google Scholar] [CrossRef]
  5. Napier, N.P.; Mathiassen, L.; Johnson, R.D. Combining perceptions and prescriptions in requirements engineering process assessment: An industrial case study. IEEE Trans. Softw. Eng. 2009, 35, 593–606. [Google Scholar] [CrossRef] [Green Version]
  6. Mylopoulos, J.; Chaudhri, V.; Plexousakis, D.; Shrufi, A.; Topologlou, T. Building knowledge base management systems. VLDB J. 1996, 5, 238–263. [Google Scholar] [CrossRef]
  7. Hill, E.; Johnson, P.M.; Port, D. Is an athletic approach the future of software engineering education? IEEE Softw. 2016, 33, 97–100. [Google Scholar] [CrossRef]
  8. Quezada-Sarmiento, P.A.; Morocho-Quezada, M.; Pacheco-Jara, L.; Garbajosa, J. Evaluation of occupational and professional profiles in ecuadorian context based on guide of knowledge SWEBOK and ontological model. In Proceedings of the 3rd International Conference on eDemocracy and eGovernment (ICEDEG), Sangolqui, Ecuador, 30 March–1 April 2016; pp. 42–47. [Google Scholar] [CrossRef] [Green Version]
  9. Fairley, R.E.D.; Bourque, P.; Keppler, J. The impact of SWEBOK version 3 on software engineering education and training. In Proceedings of the IEEE 27th Conference on Software Engineering Education and Training (CSEE&T), Klagenfurt, Austria, 23–25 April 2014; pp. 192–200. [Google Scholar] [CrossRef]
  10. Pyster, A.; Turner, R.; Henry, D.; Lasfer, K.; Bernstein, L. Master’s degrees in software engineering: An analysis of 28 university programs. IEEE Softw. 2009, 26, 94–101. [Google Scholar] [CrossRef]
  11. Abran, A.; Cuadrado, J.J.; García-Barriocanal, E.; Mendes, O.; Sánchez-Alonso, S.; Sicilia, M.A. Engineering the ontology for the SWEBOK: Issues and techniques. In Ontologies for Software Engineering and Software Technology; Springer: Berlin/Heidelberg, Germany, 2006; pp. 103–121. [Google Scholar] [CrossRef]
  12. Klein, P.; Pugliese, D.; Lützenberger, J.; Colombo, G.; Thoben, K.-D. Exchange of knowledge in customized product development processes. Procedia CIRP 2014, 21, 99–104. [Google Scholar] [CrossRef] [Green Version]
  13. Yang, H.Z.; Chen, J.F.; Ma, N.; Wang, D.Y. Implementation of knowledge-based engineering methodology in ship structural design. CAD Comput. Aided Des. 2012, 44, 196–202. [Google Scholar] [CrossRef]
  14. Eras, A.G.; Quezada, P.S.; González, P.L.; Gallardo, C. Comparing competences on academia and occupational contexts based on similarity measures. In Proceedings of the WEBIST 2015—11th International Conference on Web Information Systems and Technologies, Lisbon, Portugal, 20–22 May 2015; pp. 540–546. [Google Scholar] [CrossRef] [Green Version]
  15. Biffl, S.; Kalinowski, M.; Rabiser, R.; Ekaputra, F.; Winkler, D. Systematic knowledge engineering: Building bodies of knowledge from published research. Int. J. Softw. Eng. Knowl. Eng. 2014, 24, 1533–1571. [Google Scholar] [CrossRef]
  16. Taguchi, K.; Nishihara, H.; Aoki, T.; Kumeno, F.; Hayamizu, K.; Shinozaki, K. Building a body of knowledge on model checking for software development. In Proceedings of the IEEE 37th Annual Computer Software and Applications Conference, Kyoto, Japan, 22–26 July 2013; pp. 784–789. [Google Scholar] [CrossRef]
  17. Hunter, A.; Liu, W. A survey of formalisms for representing and reasoning with scientific knowledge. Knowl. Eng. Rev. 2010, 25, 199–222. [Google Scholar] [CrossRef] [Green Version]
  18. NSPE. Professional Engineering Body of Knowledge. Prepared by Licensure and Qualifications for Practice Committee of the National Society of Professional Engineers. 2013. Available online: https://www.nspe.org/sites/default/files/resources/nspe-body-of-knowledge.pdf (accessed on 10 July 2020).
  19. Chan, C.; Jiang, J.J.; Klein, G. Team task skills as a facilitator for application and development skills. IEEE Trans. Eng. Manag. 2008, 55, 434–441. [Google Scholar] [CrossRef]
  20. Jaakkola, M.; Frösén, J.; Tikkanen, H. Various forms of value-based selling capability—Commentary on “value-based selling: An organizational capability perspective”. Ind. Mark. Manag. 2015, 45, 113–114. [Google Scholar] [CrossRef]
  21. Garousi, V.; Giray, G.; Tuzun, E.; Catal, C.; Felderer, M. Closing the gap between software engineering education and industrial needs. IEEE Softw. 2020, 37, 68–77. [Google Scholar] [CrossRef] [Green Version]
  22. ASCE and American Society of Civil Engineers. Knowledge Committee of the Committee on Academic Prerequisites for Professional Practice (BOK Committee), Civil Engineering Body of Knowledge for the 21st Century: Preparing the Civil Engineer for the Future. Available online: https://www.asce.org/uploadedFiles/Education_and_Careers/Body_of_Knowledge/Content_Pieces/body-of-knowledge.pdf (accessed on 9 July 2020).
  23. Oguz, D.; Oguz, K. Perspectives on the Gap between the Software Industry and the Software Engineering Education. IEEE Access 2019, 7, 117527–117543. [Google Scholar] [CrossRef]
  24. Brooks, J.M.; Carroll, J.S.; Beard, J.W. Dueling stakeholders and dual-hatted systems engineers: Engineering challenges, capabilities, and skills in government infrastructure technology projects. IEEE Trans. Eng. Manag. 2011, 58, 589–601. [Google Scholar] [CrossRef] [Green Version]
  25. Lavrishcheva, E.M. Software engineering as a scientific and engineering discipline. Cybern. Syst. Anal. 2008, 44, 324–332. [Google Scholar] [CrossRef]
  26. Niazi, M. Teaching global software engineering: Experiences and lessons learned. IET Softw. 2015, 9, 95–102. [Google Scholar] [CrossRef]
  27. Quezada-Sarmiento, P.A.; Macas-Romero, J.D.C.; Roman, C.; Martin, J.C. A body of knowledge representation model of ecotourism products in southeastern ecuador. Heliyon 2018, 4. [Google Scholar] [CrossRef] [Green Version]
  28. Robert, F.; Abran, A.; Bourque, P. A technical review of the software construction knowledge area in the SWEBOK guide. In Proceedings of the 10th International Workshop on Software Technology and Engineering Practice, Montreal, QC, Canada, 6–8 October 2002; pp. 36–42. [Google Scholar] [CrossRef]
  29. Ding, W.; Liang, P.; Tang, A.; Van Vliet, H. Knowledge-based approaches in software documentation: A systematic literature review. Inf. Softw. Technol. 2014, 56, 545–567. [Google Scholar] [CrossRef]
  30. Hassan, H.; Martinez, J.-M.; Dominguez, C.; Perles, A.; Albaladejo, J. Innovative methodology to improve the quality of electronic engineering formation through teaching industrial computer engineering. IEEE Trans. Educ. 2004, 47, 446–452. [Google Scholar] [CrossRef]
  31. Negev, M. Knowledge, data and interests: Challenges in participation of diverse stakeholders in HIA. Environ. Impact Assess. Rev. 2012, 33, 48–54. [Google Scholar] [CrossRef]
  32. Kunseler, E.-M.; Tuinstra, W.; Vasileiadou, E.; Petersen, A.C. The reflective futures practitioner: Balancing salience, credibility and legitimacy in generating foresight knowledge with stakeholders. Futures 2015, 66, 1–12. [Google Scholar] [CrossRef] [Green Version]
  33. Bourque, P. SWEBOK refresh and continuous update: A call for feedback and participation. In Proceedings of the 22nd Conference on Software Engineering Education and Training, Hyderabad, Andhra Pradesh, India, 17–20 February 2009; pp. 288–289. [Google Scholar] [CrossRef]
  34. Sulaeman, H.T.G.; Rosmansyah, Y. Mobile application analysis and design for project performance reporting. In Proceedings of the International Conference on ICT for Smart Society 2013: “Think Ecosystem Act Convergence” (ICISS 2013), Jakarta, Indonesia, 13–14 June 2013; pp. 294–297. [Google Scholar] [CrossRef]
  35. Vassev, E.; Hinchey, M. Autonomy Requirements Engineering. Computer 2013, 46, 82–84. [Google Scholar] [CrossRef] [Green Version]
  36. Steyaert, P.; Barzman, M.; Billaud, J.-P.; Brives, H.; Hubert, B.; Ollivier, G.; Roche, B. The role of knowledge and research in facilitating social learning among stakeholders in natural resources management in the French Atlantic coastal wetlands. Environ. Sci. Policy 2007, 10, 537–550. [Google Scholar] [CrossRef]
  37. Fox, A.; Patterson, D. Is the New Software Engineering Curriculum Agile? IEEE Softw. 2013, 30, 88. [Google Scholar] [CrossRef]
  38. Sobel, A.E.K. Emphasizing formal analysis in a software engineering curriculum. IEEE Trans. Educ. 2001, 44. [Google Scholar] [CrossRef]
  39. Ardis, M.; Budgen, D.; Hislop, G.W.; Offutt, J.; Sebern, M.; Visser, W. SE 2014: Curriculum guidelines for undergraduate degree programs in software engineering. Computer 2015, 48, 106–109. [Google Scholar] [CrossRef]
  40. Medical Group Management Association Englewood. Body of Knowledge for Medical Practice Management. 2017. Available online: https://www.cmgma.org/acmpe/body-of-knowledge/ (accessed on 10 July 2020).
  41. Bevan, N. Usability Body of Knowledge; Usability Professionals’ Association: Bloomingdale, IL, USA, 2005. [Google Scholar]
  42. Pomeroy-Huff, M.; Mullaney, J.L.; Cannon, R.; Sebern, M. Personal Software Process (PSP) Body of Knowledge, Version 1.0. Available online: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=7317 (accessed on 24 August 2020).
  43. Masters, S.; Behrens, S.; Mogilensky, J.; Ryan, C. Scampi Lead Appraiser Body of Knowledge (SLA BOK); Software Engineering Institute, Carnegie Mellon University: Pittsburgh, PA, USA, 2005. [Google Scholar] [CrossRef]
  44. Dzimińska, M.; Fijalkowska, J.; Sułkowski, L. A Conceptual model proposal: Universities as culture change agents for sustainable development. Sustainability 2020, 12, 4635. [Google Scholar]
  45. Sánchez-Arias, L.F.; Solarte-Pazos, L. The body of knowledge of the project management institute-PMBOK® guide, and the specificities of project management—A critical review. Innovar 2010, 20, 89–100. [Google Scholar]
  46. Parnell, G.S.; Hardman, N.; McCarthy, D.J.; Yale, G.E. Using the guide to the systems engineering body of knowledge (sebok version 0.5) for undergraduate system engineering program assessment. INCOSE Int. Symp. 2012, 22, 2208–2220. [Google Scholar] [CrossRef]
  47. Agresti, W.W. An IT body of knowledge: The key to an emerging profession. IT Prof. 2008, 10, 18–22. [Google Scholar] [CrossRef]
  48. Olwell, D.H.; Henry, D.; Pyster, A.; Hutchison, N.; Enck, S.; Anthony, J.F., Jr. Analysis of the references from the guide to the systems engineering body of knowledge (SEBoK). Procedia Comput. Sci. 2013, 16, 1000–1006. [Google Scholar] [CrossRef] [Green Version]
  49. International Council on Systems Engineering. The INCOSE fellow’s edition: The technical vision of systems engineering; the intellectual content of systems engineering. INCOSE Insight 2006, 8, 1–64. [Google Scholar]
  50. Navarro, A.; Sierra, J.L.; Fernández-Valmayor, A.; Fernández-Manjón, B. A First Step towards the Web Engineering Body of Knowledge. In Web Engineering; Lowe, D., Gaedke, M., Eds.; Springer: Heidelberg, Germany, 2005; pp. 585–587. [Google Scholar] [CrossRef]
  51. Squires, A.; Hutchison, N.; Pyster, A.; Olwell, D.; Enck, S.; Ferris, T.L.J.; Gelosh, D. Work in process: A body of knowledge and curriculum to advance systems engineering (BKCASE). In Proceedings of the 2011 IEEE International Systems Conference, Montreal, QC, Canada, 4–7 April 2011; pp. 250–255. [Google Scholar] [CrossRef]
  52. Mallett, R.; Hagen-Zanker, J.; Slater, R.; Duvendack, M. The benefits and challenges of using systematic reviews in international development research. J. Dev. Eff. 2012, 4, 445–455. [Google Scholar] [CrossRef]
  53. Kitchenham, B.A.; Charters, S. Guidelines for Performing Systematic Literature Reviews in Software Engineering, Technical Report EBSE-2007-01; School of Computer Science and Mathematics, Keele University: Keele, UK, 2007. [Google Scholar]
  54. Kitchenham, B.A.; Pfleeger, S.L.; Pickard, L.M.; Jones, P.W.; Hoaglin, D.C.; El Emam, K.; Rosenberg, J. Preliminary guidelines for empirical research in software engineering. IEEE Trans. Softw. Eng. 2002, 28, 721–734. [Google Scholar] [CrossRef] [Green Version]
  55. Besker, T.; Martini, A.; Bosch, J. Managing architectural technical debt: A unified model and systematic literature review. J. Syst. Softw. 2018, 135, 1–16. [Google Scholar] [CrossRef]
  56. Brereton, P.; Kitchenham, B.A.; Budgen, D.; Turner, M.; Khalil, M. Lessons from applying the systematic literature review process within the software engineering domain. J. Syst. Softw. 2007, 80, 571–583. [Google Scholar] [CrossRef] [Green Version]
  57. Ivarsson, M.; Gorschek, T. A method for evaluating rigor and industrial relevance of technology evaluations. Empir. Softw. Eng. 2011, 16, 365–395. [Google Scholar] [CrossRef]
  58. Valverde-Berrocoso, J.; Garrido-Arroyo, M.C.; Burgos-Videla, C.; Morales-Cevallos, M.B. Trends in Educational Research about e-Learning: A Systematic Literature Review (2009–2018). Sustainability 2020, 12, 5153. [Google Scholar] [CrossRef]
  59. Tinoco-Giraldo, H.; Sánchez, E.M.; Garcia-Penalvo, F.J. E-Mentoring in Higher Education: A Structured Literature Review and Implications for Future Research. Sustainability 2020, 12, 4344. [Google Scholar] [CrossRef]
  60. Tlili, A.; Huang, R.; Chang, T.-W.; Nascimbeni, F.; Burgos, D. Open Educational Resources and Practices in China: A Systematic Literature Review. Sustainability 2019, 11, 4867. [Google Scholar] [CrossRef] [Green Version]
  61. Dybå, T.; Dingsøyr, T. Strength of evidence in systematic reviews in software engineering. In Proceedings of the 2008 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, Kaiserslautern, Germany, 9–10 October 2008. [Google Scholar] [CrossRef] [Green Version]
  62. Muñoz Justicia, J.; Sahagún Padilla, M.Á. Análisis Cualitativos Assisted Por Ordenador Con ATLAS.ti. In Investigar en Psicología de La Educación. Nuevas Perspectivas Conceptuales y Metodológicas; Izquierdo, C., Perinat, A., Eds.; Amentia: Barcelona, Spain, 2011; pp. 299–363. [Google Scholar]
  63. Hwang, S. Utilizing qualitative data analysis software: A review of Atlas.ti. Soc. Sci. Comput. Rev. 2007, 26, 519–527. [Google Scholar] [CrossRef]
  64. Dolog, P.; Thomsen, L.L.; Thomsen, B. Assessing problem-based learning in a software engineering curriculum using bloom’s taxonomy and the IEEE software engineering body of knowledge. ACM Trans. Comput. Educ. 2016, 16. [Google Scholar] [CrossRef]
  65. Batini, C.; Lenzerini, M.; Navathe, S.B. A comparative analysis of methodologies for database schema integration. ACM Comput. Surv. 1986, 18, 323–364. [Google Scholar] [CrossRef]
  66. Pyster, A.; Adcock, R.; Ardis, M.; Cloutier, R.; Henry, D.; Laird, L.; Lawson, H.B.; Pennotti, M.; Sullivan, K.; Wade, J. Exploring the Relationship between Systems Engineering and Software Engineering. Procedia Comput. Sci. 2015, 44, 708–717. [Google Scholar] [CrossRef] [Green Version]
  67. Bourque, P.; Stroian, V.; Abran, A. Proposed concepts for a tool for multidimensional performance modeling in software engineering management. In Proceedings of the IEEE International Symposium on Industrial Electronics, Montreal, QC, Canada, 9–13 July 2006. [Google Scholar] [CrossRef]
  68. MITRE. What is the Enterprise Architecture Body of Knowledge? Available online: http://www.eabok.org/ (accessed on 2 July 2020).
  69. Bourque, P.; Dupuis, R.; Abran, A.; Moore, J.W.; Tripp, L.; Wolff, S. Fundamental principles of software engineering—A journey. J. Syst. Softw. 2002, 62, 59–70. [Google Scholar] [CrossRef] [Green Version]
  70. Bourque, P.; Buglione, L.; Abran, A.; April, A. Bloom’s taxonomy levels for three software engineer profiles. In Proceedings of the 11th Annual International Workshop on Software Technology and Engineering Practice (STEP 2003), Amsterdam, The Netherlands, 19–21 September 2003; pp. 123–129. [Google Scholar] [CrossRef]
  71. Bull, C.N.; Whittle, J. Supporting reflective practice in software engineering education through a studio-based approach. IEEE Softw. 2014, 31, 44–50. [Google Scholar] [CrossRef]
  72. Thomas, B.; Hilburn, I.; Hirmanpour, S.; Khajenoori, R.; Turner, R.; Abir, Q. A Software Engineering Body of Knowledge Version 1.0. Technical Report CMU/SEI-99-TR-004, ESC-TR-99-004ACM. 1999. Available online: https://resources.sei.cmu.edu/asset_files/TechnicalReport/1999_005_001_16733.pdf (accessed on 1 July 2020).
  73. Alarifi, A.; Zarour, M.; AlOmar, N.; AlShaikh, Z.; Alsaleh, M. SECDEP: Software engineering curricula development and evaluation process using SWEBOK. Inf. Softw. Technol. 2016, 74, 114–126. [Google Scholar] [CrossRef]
  74. Garousi, V.; Giray, G.; Tuzun, E. Understanding the knowledge gaps of software engineers: An empirical analysis based on SWEBOK. ACM Trans. Comput. Educ. 2019, 20. [Google Scholar] [CrossRef] [Green Version]
  75. Voas, J.; Kuhn, R.; Paulsen, C.; Schaffer, K. Computer Science Education in 2018. IT Prof. 2018, 20, 9–14. [Google Scholar] [CrossRef]
  76. Dieste, O.; Juristo, N.; Moreno, A.M. How higher-education systems influence software engineering degree programs. IEEE Softw. 2004, 21, 78–85. [Google Scholar] [CrossRef]
  77. Kilicay-Ergin, N.; Laplante, P.A. An online graduate requirement engineering course. IEEE Trans. Educ. 2013, 56, 208–216. [Google Scholar] [CrossRef]
  78. Maxville, V. eScience: Building our body of knowledge. Procedia Comput. Sci. 2011, 4, 1953–1963. [Google Scholar] [CrossRef] [Green Version]
  79. Caulfield, C.; Xia, J.C.; Veal, D.; Paul Maj, S. A Systematic survey of games used for software engineering education. Mod. Appl. Sci. 2011, 5, 28–43. [Google Scholar] [CrossRef] [Green Version]
  80. Ekaputra, F.J.; Serral, E.; Biffl, S. Building an empirical software engineering research knowledge base from heterogeneous data sources. In Proceeding of the 14th International Conference on Knowledge Technologies and Data-driven Business, Graz, Austria, 16–19 September 2014. [Google Scholar]
Figure 1. Phases of the Systematic Literature Review (SLR) method proposed in [54].
Figure 1. Phases of the Systematic Literature Review (SLR) method proposed in [54].
Sustainability 12 06858 g001
Figure 2. Primary studies and relevant information in an Open Body of Knowledge (BOK) context.
Figure 2. Primary studies and relevant information in an Open Body of Knowledge (BOK) context.
Sustainability 12 06858 g002
Figure 3. SLR synthesis process.
Figure 3. SLR synthesis process.
Sustainability 12 06858 g003
Figure 4. Initial codes of BOK.
Figure 4. Initial codes of BOK.
Sustainability 12 06858 g004
Figure 5. Codes’ representation.
Figure 5. Codes’ representation.
Sustainability 12 06858 g005
Figure 6. Concepts network.
Figure 6. Concepts network.
Sustainability 12 06858 g006
Figure 7. Levels of abstraction of SWEBOK [3].
Figure 7. Levels of abstraction of SWEBOK [3].
Sustainability 12 06858 g007
Table 1. Scientific Data Base.
Table 1. Scientific Data Base.
DatabaseRetrievedIncludeExclude
IEEE Xplore Digital Library1449153
ACM Digital Library27243
Springer29227
Web of Science761
Science Direct13121
Total22015565
Table 2. Publication year and Primary Studies (PS) resource type.
Table 2. Publication year and Primary Studies (PS) resource type.
YearJournalConference PublicationsReportWeb PagesSpecial PublicationsDocumentsBook ChapterGuidesBOKTotal
1959 1
1980 1
19902
1995 1
19972
1998 1
199923 1 11
200012
2001 6 1
200215 1
200315
200421 111
2005 6 1
200634 6 6
200719 2
200822 1 1
2009
201024 1
201136 2 1
2012531
201319 1 1
2014110 21
201532
2016 21 1
2017
20182 11
20191
202021 1
3782322216413161
Table 3. Quality criteria. Adapted from [61].
Table 3. Quality criteria. Adapted from [61].
Topic: Article NameScoreNotes
1. Is this a research paper?
   1.1 Is the paper based on research (or is it merely a “lessons learned” report based on expert opinion)?
2. Is there a clear statement of the aims of the research?
   2.1. Is there a rationale for why the study was undertaken?
   2.2. Is there a clear statement of the study’s primary outcome (i.e., time-to-market, cost, or product or process quality)?
3. Is there an adequate description of the context in which the research was carried out?
4. Was the research design appropriate to address the aims of the research?
   4.1. Has the researcher justified the research design (e.g., have they discussed how they decided which methods to use)?
   4.2. Is the research design is appropriate for the research goals?
5. Was the recruitment strategy appropriate to the aims of the research?
   5.1. Has the researcher explained how the participants or cases were identified and selected?
   5.2. Are the cases defined and described precisely?
   5.3. Were the cases representative of a defined population?
   5.4. Have the researchers explained why the participants or cases they selected were the most appropriate to provide access to the type of knowledge sought by the study?
   5.5. Was the sample size sufficiently large?
6. Was there a control group with which to compare treatments?
   6.1. How were the controls selected?
   6.2. Were they representative of a defined population?
7. Was the data collected in a way that addressed the research issue?
   7.1. Were all measures clearly defined (e.g., unit and counting rules)?
   7.2. Is it clear how data was collected (e.g., semi-structured interviews, focus group etc.)?
   7.3. Has the researcher justified the methods that were chosen?
   7.4. Has the researcher made the methods explicit (e.g., is there an indication of how interviews were conducted, did they use an interview guide)?
   7.5. Whether the form of the data is clear (e.g., tape recording, video material, notes etc.)
   7.6. Whether quality control methods were used to ensure completeness and accuracy of data collection?
8. Was the data analysis sufficiently rigorous?
   8.1. Was there an in-depth description of the analysis process?
   8.2. Has sufficient data been presented to support the findings?
   8.3. To what extent has contradictory data been taken into account?
   8.4. Whether quality control methods were used to verify the results
9. Has the relationship between researcher and participants been considered adequately?
   9.1. Did the researcher critically examine their own role, potential bias and influence during the formulation of research questions, sample recruitment, data collection, and analysis and selection of data for presentation?
10. Is there a clear statement of findings?
   10.1. Are the findings explicit (e.g., magnitude of effect)?
   10.2. Has an adequate discussion of the evidence, both for and against the researcher’s arguments, been demonstrated?
   10.3. Has the researcher discussed the credibility of their findings (e.g., triangulation, respondent validation, more than one analyst)?
   10.4. Are limitations of the study discussed explicitly?
   10.5. Are the findings discussed in relation to the original research questions?
   10.6. Are the conclusions justified by the results?
11. Is the study of value for research or practice?
   11.1. Does the researcher discuss the contribution the study makes to existing knowledge or understanding (e.g., do they consider the findings in relation to current practice or relevant research-based literature)?
   11.2. Does the research identify new areas in which research is necessary?
   11.3. Does the researcher discuss whether or how the findings can be transferred to other populations, or consider other ways in which the research can be used?
Scale
Not mention the topic0
The topic is slightly analysis1
The topic is show partially2
The topic is mention totally3
Include20
Exclude−20
Table 4. Structure and version of relevant bodies of knowledge.
Table 4. Structure and version of relevant bodies of knowledge.
Body of Knowledge NameStructureVersions
B1: BOK for MPM [40].The Structure of the BOK has been outlined to identify the various knowledge, and skills required by today’s medical practice executive [40].Three versions [39].
B2: Usability Body of Knowledge [41].The Body of Knowledge is organized in an architectural hierarchy [41].Conditions, and circumstances that are relevant to an event, fact or knowledge, in the process of being organized.
B3: The Personal Software Process (PSP) Body of Knowledge [42].This BOK is organized in an architectural hierarchy in which the concepts and skills of the PSP are described and decomposed into three levels of abstraction [42].Unique version [42].
B4: SLA BOK [43].The SLA BOK is organized by competency clusters and knowledge areas. Individual competencies (CMP) include skills, related competencies, examples and high maturity skills [43].Unique version [43].
B5: SWEBOK [3].Hierarchical structure using different levels of topics.Three version [3].
B6: PMBOK [44].Hierarchical structure using different levels of topics.Six versions [44].
B7: ITS BOK [45].Structured by well-defined competencies, notional security roles, four primary functional perspectives, and an IT Security Role, Competency, and Functional Matrix.Unique version [45].
B8: WEBOK [46].Hierarchical structure using different levels of topics [46].Unique version [49].
B9: ITBOK.Hierarchical structure. 13 knowledge areas [46].Unique version [46].
B10: SEBOK [47].Sevent parts.SEBOK has versions 1.0 to 1.4 with very small changes in between [47].
B11: BKCASE [48].The BKCASE project is of courses structured similarly as the SEBOK itself [48].Three versions [48].
B12: EABoK [68]Hierarchical structure.Unique version [68].
Table 5. BOK elements to describe knowledge on Open BOK.
Table 5. BOK elements to describe knowledge on Open BOK.
ElementsAssociationDescription
C1. DomainC1.1 ContextKnowledge identified by name, context, and application.
C1.1.1 BOK Application
C1.2 Stakeholders
C1.3 Education
C1.4 Industry
C2. Knowledge OrganizationC2.1 BOK ContentThe conditions, and circumstances that are relevant to an event, fact or knowledge, in the process of being organized.
C2.1.1 Disciplines
C2.2 Structure
C2.2.1 Knowledge Categories
C2.2.2 Hierarchical Organization
C2.2.2.1 Knowledge Areas
C2.2.2.1.1 Organization of Knowledge Area
C2.2.2.1.2 Breakdown of Topics
C2.2.2.1.2.1 List of Future Readings
C2.2.2.1.2.2 List of Acronyms
C2.2.2.1.2.3 References
C2.2.2.1.2.3.1 Materials
C2.2.2.1.2.3.2 Matrix
C2.2.2.1.2.3.3 Related Disciplines
C2.2.2.1.2.4 Taxonomies
C2.2.2.1.2.4.1 Types of Taxonomies
C2.2.2.1.2.4.2 Levels of Taxonomies
C2.2.2.1.2.4.3Application of Taxonomies
C2.2.2.1.3 Knowledge Organization
C2.2.2.1.3.1 Knowledge Unit
C2.2.2.1.3.1.1 Knowledge Topic
C2.2.2.1.3.1.2 Knowledge Subtopic
C3. Knowledge RepresentationC3.1 ConceptsCharacteristics to represent knowledge in an educational context.
C3.2 Supporting Tools
C3.3 Ontology
C3.3.1 Models
C3.3.2 Vocabulary
C3.4. Skills
C3.4.1.1Instructional Skills
C3.4.1.1.1 Types of Skills
C3.4.1.1.1.1 Technical
C3.4.1.1.1.2 Pedagogical
C3.4.1.2 Capacities
C3.4.1.3 Capabilities
C4. Domain ManagementC4.1. BOK AreasStructure of BOKs, where topics are thoroughly detailed.
C4.2 BOK Details
C4.3 BOK Structure
C5. Knowledge AcquisitionC5.1Types of StandardsWays to acquire Knowledge.
C5.2 Application of Standards
C6. Evolution BoksC6.1 ConsensusAny process of formation, growth or development in the BOK context.
C6.2 BOK Objective
C6.2.1 Scope of BOK
C6.3 Type of BOK
C6.4 Knowledge Acquisition
C6.4.1 Lessons Learned
C6.4.2 Material
C7. Knowledge ResourceC7.1 GuidesResources about the BOK.
C7.2 Communities
C7.3 Standards
C8. Knowledge EducationC8.1 EducationA set of characteristics that identify a knowledge within the educational context
C8.1.1 Profile
C8.1.2 Guidelines for Profiles
C8.1.3 Educational Institution
C8.1.4 Educational Training
C8.1.4.1University Curricula
C8.1.4.1.1 Curriculum
C8.1.4.1.1.1Curriculum Process
C8.1.4.1.1.2 Curriculum Develop
C8.1.4.1.1.3Curriculum Resource
C8.1.4.1.1.4 Curriculum Architecture
C8.1.4.1.1.5 Code of Ethics
C8.1.4.2 BOK Accreditation
C8.1.5 Professional Certification
C8.1.5.1 Evaluation Policies
C8.1.5.2 Licensing
C8.1.5.2.1 Competences
C8.1.5.2.2 Certification
C8.1.5.3 Professional Standard
C8.1.5.4 Professional Practice
C8.1.5.5 Professional Development
C8.1.6 Educational Objectives
C8.1.7 Committees
C8.1.8 Innovation

Share and Cite

MDPI and ACS Style

Quezada-Sarmiento, P.A.; Elorriaga, J.A.; Arruarte, A.; Washizaki, H. Open BOK on Software Engineering Educational Context: A Systematic Literature Review. Sustainability 2020, 12, 6858. https://doi.org/10.3390/su12176858

AMA Style

Quezada-Sarmiento PA, Elorriaga JA, Arruarte A, Washizaki H. Open BOK on Software Engineering Educational Context: A Systematic Literature Review. Sustainability. 2020; 12(17):6858. https://doi.org/10.3390/su12176858

Chicago/Turabian Style

Quezada-Sarmiento, Pablo Alejandro, Jon A. Elorriaga, Ana Arruarte, and Hironori Washizaki. 2020. "Open BOK on Software Engineering Educational Context: A Systematic Literature Review" Sustainability 12, no. 17: 6858. https://doi.org/10.3390/su12176858

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop