The Essential Competencies of Software Professionals: A Unified Competence Framework

Context: Developing high-quality software requires skilled software professionals equipped with a set of basic and essential software engineering competencies (SEC). These competencies and the satisfaction levels derived from them change over a project ’ s lifecycle, or as software professionals move from one project to another. Objective: Previous studies suggest a lack of means enabling SEC stakeholders to identify and assess competencies suitable for different projects. Additionally, previous research has mainly portrayed SEC to be static and over- looked their evolution over time and across projects. We investigate how we could effectively identify and match the competencies of software professionals necessary for different projects. Method: We follow a mixed-method approach to iteratively develop and evaluate a framework for identifying and managing SEC. In so doing, we use the results of an extensive literature review, focus group discussions with experts from academia and industry, and data collected through interviews with 138 individuals with a supervisory role in the software industry. Results: Drawing on the Kano model and Competency Framework for Software Engineers, we propose a Unified Competence Gate for Software Professionals (UComGSP), a framework for identifying and managing SEC. The UComGSP consists of 62 hard competencies, 63 soft competencies, and 25 essential SEC competencies. Addi-tionally, we propose three stakeholders ’ satisfaction levels for SEC assessment: basic, performance, and delighter. Furthermore, based on empirical observation, we report 27 competencies not mentioned in the reviewed literature; 11 of them are considered essential competencies. Conclusion: Competence development involves different stakeholders, including software professionals, educators, and the software industry. The UComGSP framework enables SEC stakeholders to (i) identify SE compe- tencies, (ii) identify the essential SEC, and (iii) assess the satisfaction levels that can be derived from different competencies. Future research is needed to evaluate the effectiveness of the proposed framework across software development projects.


Introduction
Considering the critical role of software in modern societies, there is an increasing demand for highly competent software professionals. This is because software development is a complex human-intensive process, and therefore, the quality of its outcomes is influenced by the skills and competencies of software professionals [1]. In such a complex environment where personal skills and teamwork are essential, having the means to know in advance the potential of the competencies of software professionals may serve as an assurance for the stakeholders.
Colomo-Palacios et al. [1] suggest that the development and management of human competencies is one of the key concerns of the software industry. These authors also point out to the lack of established career paths for software professionals, due to no clear role definitions agreed on in the field, and inadequate verification of software professional competencies. Additionally, not having capable people assigned to the roles and problems with team management are two human factors that are found to contribute to failures in software projects [2][3][4]. In short, the competencies of software professionals are a key to successful software project management, and for this, essential competencies can be discerned [5,6]. However, a covering search of the literature did not present a holistic Software Engineering Competence (SEC) model or a framework to identify competencies, competence satisfaction levels, and the essential competencies to be used in different software projects (cf. Section 2.1). Furthermore, the analysis of the existing SEC models and frameworks (cf. Section 2.1) suggests that they are resource-intensive and complex to use, while they cannot be customized according to the specifics of different software projects. Thus, in most software projects, people are assigned to roles and teams based on the sometimes limited experience of the project manager or team leader [4]. Previous research has looked at competence identification and classification [6][7][8], competence measurement and assessment [9,10], and curriculum development [11][12][13]. However, we lack studies looking at SEC from the point of view of staffing software development projects. Thus, we look at SEC from a software engineering management perspective.
Over the past years, SEC research has attempted to identify different sets of essential software engineering competencies (e.g. [1,5,6,[14][15][16][17][18]). These previous studies suggest that the essential competencies are same for every software development project. We, however, posit that these competencies change over a project's lifecycle or as software professionals move from one project to another. Following the assertion of previous SEC research, we emphasize the importance of the essential competencies for software development research and practice. However, we highlight the need for novel solutions that make the identification of the essential competencies less complex and according to the needs of a particular software project. Thus, we aim to develop a holistic framework for determining the essential competencies for software development that can be customized according to the characteristics of a particular software project. Such framework better aligns with the recent software development methodologies such as agile [19] and DevOps [20]. To achieve this goal, we set out to answer the following question: How could we effectively identify and match the competencies of software professionals necessary for different software development projects?
To answer our research question, we first examine the extant literature on SEC. Adopting the Kano model [21] and the Competency Framework for Software Engineers [8] as a basis, we propose a framework called Unified Competence Gate for Software Professionals (UComGSP). Next, through several rounds of stakeholder consultations and interview data, we evaluate the applicability and useability of the framework. As such, this study contributes to software engineering research and practice by proposing a framework for managing and developing SEC. It is worth mentioning that the field of education (cf. the ACM community work on defining the educational content and practices [22], is not much touched in the manuscript. This is deliberate because the paper takes the viewpoint of an industry practitioner. Additionally, we define competence satisfaction levels and identify a set of essential competencies for software professionals. Finally, the study shows how the UComGSP framework can be used in practice for determining the competence satisfaction levels and essential competencies for different software development projects.
The rest of the paper is structured as follows: In Section 2 we discuss the research background. In Section 3 the methodology is discussed and in Section 4 the results are presented. In Sections 5 and 6 we discuss the results and conclusions of the study, respectively.

Concepts and definitions
Competence is defined as "a set of abilities, knowledge, and skills for performing an assigned task in a given context" [23] or "the personal qualities causally related to effective performance in an area of work, where individual competence integrates Knowledge, Skills, and Dispositions in a professional Context" [24]. We define competence in software engineering as "a complete set of abilities, skills, knowledge, and capabilities needed to actively engage in a software development effectively." On the other hand, the essential competence of a software professional is defined as knowledge, skills, and attitudes for exceptional performance in a software project [6]. Competence is mainly categorized into soft and hard skills. Soft competencies relate to the personal behavior of an individual in its interaction with others within a setup [25,26]. Hard competencies are defined as skills, knowledge, abilities, and attitude that are teachable, acquired mostly through formal training and studies, that one needs to perform a job or an assignment [27,28].

Background in the context of software engineering bodies of knowledge
A concern of the software industry is the development of the talents of human resources. This is so because the quality and innovation of products and services produced by the industry are dependent on the knowledge, abilities, and skills of the software professionals [4,8]. As already stated, the development of software does not require complex machinery, rather it requires competent software professionals. However, the software industry faces a significant shortage of skilled software professionals [29]. To identify and train such professionals, studies have proposed various curricula to support the training development of skills, the identification and classification of competencies of SEC, and a means to assess software professionals' competencies [23,[30][31][32][33].
Various attempts have been made to define the competencies needed by software professionals for software development [34,35]. Their success in doing so, however, is debatable [35]. For example, several works such as [6,[30][31][32][36][37][38] have defined, identified, and classified competencies for software engineering. In proposing a Software Engineering Body of Skills (SWEBOS), Sedelmaier & Landes identified and structured competencies of software professionals into three categories. These include (i) comprehension of the complexity of software engineering processes, (ii) awareness of problems and understanding of cause-effect relationships, and (iii) team competency including communication skills [33]. Also, practitioner guide documents such as SWECOM is for assessing SEC by looking at the skill area and work activity for each skill activities in an increasing level of 5 stages. are [23], The Software Assurance (SwA) Competency Model is for assessing and providing assurance to software professionals. It has five competence levels [22]. The European e-Competence Framework (e-CF) aims at standardizing the ICT professionals' competencies within the European Union. It has 40 reference competencies and five e-CF areas [39]. The essence kernel of OMG looks at the capabilities required to carry a work of software engineering. The kernel competencies are further subdivided using the three discrete areas into stakeholder representation, analysis, development, testing, leadership, and management as competency areas for competency management. Each competency area has five levels of which teams can assess the competencies [40]. These models or frameworks mentioned above have attempted to consolidate their assessment to five levels, maybe because they take more fine-grained approaches suitable for education and related assessment. It is worth mentioning that the competencies of the software professional have not kept pace with what the industry requires [8,23,41].
Some studies in the SEC area suggest that there is a gap between the competencies needed by the industry and what the educational institutions produce [31,33,[42][43][44]. Also, it has been established that the software industry faces a shortage of skilled software professionals. Although there are scientific studies (e.g., [11,45,46]) and practitioner documents (e.g. [47,48]) for training software professionals, the gap remains between what the educational institutions produce and what the industries require. We acknowledge the existence of well-structured curricula to support the training of software professionals such as the current CC2020 and the previous ones. However, they are mostly viewed from an academic or scientific perspective. As suggested by studies such as [31,33,42], there exists a gap between competencies that the education institute produce and what the industry needs. SEC 3 development is not the sole responsibility of one institution. For this reason, in this study, we approach SEC from software business and project management viewpoints. Therefore, the study departs from the frameworks that assess the gradual development of an individual's skills, abilities, and knowledge in their journey to becoming a professional or a more proficient professional. Instead, it fills the gap in developing a framework for managing competencies needed for software projects. In short, a better way of staffing a software development efforts.

Software engineering competency frameworks and models
To develop an appropriate competence framework, we have analyzed the existing SEC models or frameworks proposed by previous studies (see Table 1). To do that, we synthesized the concepts and results reported by these studies, including stakeholders, software engineering roles, competence categorization, competence satisfaction levels, personnel competence, organizational competence, and valued competence. Stakeholders are a person(s) or party(/ies) with interest in SEC development. According to [24], stakeholders of SEC development may include "educators, students, industry, and other employers of computer graduates, policymakers, professional societies, etc." Thus, for our study, we simplify them to include software professionals (i.e., individuals who hold software engineering competencies), educators (i.e., institutions that provide software engineering education to software professionals and communities of practice within the software engineering field), and software industry (i.e., entities who utilize the competencies held by the software professionals for-profit or for non-profit purpose). Connected to the categorization are the satisfaction levels. In looking at the prerequisites for software engineering education, Thurner et al. [7] argued that the "core problem is not a lack of general intellectual capacity, but rather significant deficiencies in specific base competencies" [20, p. 1069]. Thus, they defined the base competence with a stack level necessary for acquiring technical competencies as three levels, that is, self-competencies, social competencies, and practical and cognitive competencies [7].
The software assurance competency model enables software organizations to assess the capabilities of software assurance of professionals on a scale of one to five [22]. Therefore, we propose a satisfaction level to represent studies that report some form of assessment level for SEC. We also suggest classifying the frameworks and models into two categories: Personnel research, and organizational research, according to their research area of origin. Thus, we define the personnel competence area as the research that focuses on the software professional competencies (i.e., the skills, the abilities, and the attitudes required for developing software products or services). And the organizational competence area is the research that focuses on tools or instruments used for organizing, assessing, measuring, and managing the personnel competencies (e.g., SEC assessment and identification models and frameworks). Last but not least, work such as [6,29,52,23,24], etc., have studied and established that there exist some competencies that are essential for software development. To observe and analyze any phenomenon requires a framework or model of the entire area. Therefore, we identify existing models and frameworks created for SEC to collect the elements for a comprehensive framework development.
The list of models and frameworks in Table 1 is based on an extensive review on previous studies that present a 'framework' or a 'model' for the SEC area [53]. To identify potential studies that have been published after our earlier literature review study [53], we searched Google Scholar , using the search terms such as 'software competency model', 'software competency framework', 'software competence model', and 'software competence framework'. From the listed models or frameworks in Table 1, three models consider some form of stakeholder in their analysis [14,24,49,7,17,25]. Five studies propose models or frameworks that consider different software engineering roles [4,8,14,49,50,7,[25][26][27]. Concerning competence categorization, four models or frameworks provide the means to categorize competencies [4,14,24,49,7,17,25]. However, we did not find any model from the identified studies that could be used to identify the satisfaction levels of SEC. All the models identified in this analysis represent the personnel competence research area. With respect to the organizational competence research area, there is only one model, which is the work of [49]. We also did not find any model that could be used to identify the essential competencies.
Based on the above comparison of models and frameworks of SEC, we conclude that no model or framework considers the assurance of competence satisfaction level to the stakeholders. Additionally, we were not able to find any model or framework for assessing the essential competencies of software professionals. Lastly, from the categories listed as valuation points by this study, we also did not find any previous model or framework that would consider all the elements identified in Table 1. Therefore, to fill this gap, we set out to develop a unified SEC framework that not only considers the key elements of SEC (i.e., competence identification, competence assessment, and the key stakeholder of competence development), but also can be used to determine the essential competencies of software professionals and also to provide competence assurance to the stakeholders. It must be noted that we have specifically focused on identifying different competency models and frameworks relevant for software engineers, rather than studies proposing frameworks for general human resources competencies (e.g., see Bohlouli et al. [54]).

Table 1
Comparison of competence models and framework for software professionals.

Kano model
The Kano model is a quality framework for mapping and prioritizing product features to customer needs [21]. The model was initially introduced in the manufacturing industry, but more recently it has been applied in the software development industry. The model takes into consideration the views of both the customer and developer in the development of a product instead of a passive approach of only developers [55]. According to [23,24], competence development is not the sole responsibility of software professionals, rather it involves key stakeholders like software companies and the software industry in general. In our view, this is similar to the objective of the Kano model. Additionally, the Kano model provides a means for assessing the quality of the product to be developed. Similarly, in SEC studies measurement and assessment is one of the main areas according to [6,8-12, 23,22,45, 56]. Therefore, we claim that the identification, assessment, and development of SEC is an interrelated function of the developer and the customer, hence our choice of the Kano model, which has recently been gaining grounds in SE studies and it related field with studies like [55,57]. As such, the model assists software development teams in determining the basic, performance, and delighter categories of features of a product or service. Previous studies have deployed the Kano model for the development of the IT systems and concluded that the model prioritizes user involvement, i.e., it allows the inclusion of customers' views to the development of a system [55,[57][58][59][60][61][62]35]. In this study we use the Kano model to consider the views of SEC stakeholders about the set of competencies that they value the most. In this scenario, the "customer" is the software industry (i.e., entity using the competencies) and the set of competencies that they value the most is considered as a product or service.
According to Kano et al. [21], a customer's decision-making options on product or service acquisition are based on conscious and subconscious deliberations [21]. There is, therefore, the need to understand these processes of decision-making to help develop products or services. Kano et al. [21] categorized these processes into three requirement levels: basic, performance, and delighter. Basic requirements relate to the customer's expectations about a product or service. These requirements are classified as basic since their presence is not dynamic enough to change the options and the opinion a customer has about the product. However, their absence may result in complaints from the customer. Performance requirements, on the other hand, are an expected pre-requisite that customers know, and they are essential influential factors in the customer's decision-making. These critical pre-requisite requirements create high levels of satisfaction when employed appropriately. The last requirement termed delighters are those requirements that do not engender any complaints from the customers when absent, however, they surprise the customer pleasantly when present. Delighters are sometimes referred to as attractive or "wow" factors [21].

Competency framework for software engineers
Competency Framework for Software Engineers (CFSE) is a framework that facilitates and guides the development of software professional competencies as well as identifies the training needs for developing those competencies [8]. The framework is based on the activities and interactions of professionals during the software development process. The constructs of this framework are the main classification of competence: hard and soft. The hard competency category relates to the technical aspects of software engineering based on the definition of the software engineering roles proposed in SWEBOK [63]. They are project management, requirement analysis, software design, programming, validation and verification tests, configuration management, quality, tests, documentation, and maintenance. We acknowledge that these roles can be performed by a dedicated person or be shared and performed by all members of a team. The latter especially applies to agile software development methodologies, which rely on small and self-organized teams. In adopting these roles, we also want to acknowledge that the field of software engineering has been undergoing a paradigm shift, such as agile [19] and DevOps [20] approaches to developing software. Such a shift brings into focus some emerging roles and responsibilities that hitherto were not part of the one being used for the study, for example, "product owner" and "scrum master". Notwithstanding this paradigm shift of approach, our study shows that even if agile methods are broadly adopted in practice and are also present in software engineering research, their specificity has not yet received much attention in SEC research; therefore, we relied on the traditional role definitions as the basis for our competence study. The soft part of the categorization is classified into social competencies and personal competencies. Social competencies include interpersonal relations, cooperation and working in a team, and handling and conflicts resolution. Personal competencies, on the other hand, include development in the job, personal development, rights, and limits. The authors of CFSE defined it as "a set of knowledge, abilities and key behaviors, with special emphasis on the soft skills" [8]. It is important to note that CFSE was chosen because, in organizational settings, competencies are linked to roles. CFSE provides software engineering roles in the hard competence category.

Competence satisfaction levels
The development of UFSCSL and UFHCSL (see Fig.1), which are derived from the CFSE and the Kano model, is reported in detail in previous work [64,65]. To enable the classification based on soft and hard competencies, the CFSE was divided into two separate frameworks. This is because each category, either hard or soft, has a different granularity. From among frameworks such as (e.g., [66][67][68][69]) for identifying software engineering competencies, the CFSE framework is the one with more granularity, thus making it easy for an in-depth analysis. In addition, the Kano model is acknowledged and used for research in software engineering, but so far, not for analyzing competencies. However, the Kano model provides a means for prioritizing features on competencies development path based on how they satisfy the "customers", meaning in our case, the software community stakeholders. Thus, this provides a means to chart a new path for competence research. Therefore, these frameworks (UFHCSL and UFSCSL) support determining the satisfaction levels in competencies and, further, determining the essential competencies of software professionals.
To use the UFSCSL, first, the competencies are identified and classified using the variables in [8] within the frameworks. Then each competence identified or classified is subjected to the metrics of the Kano model to determine its satisfaction levels. Thus, given as basic, performance and delighter competencies for the social competencies (interpersonal relation, cooperation and work in a team, and handling and conflicts resolution) and the personal competencies (development in the job, personal development, rights, and limits) were used for the classification the soft competencies. On the UFHCSL, hard competencies are identified and classified using the hard category in [8] framework, followed by competency identification or classification subjected to the metrics of the Kano model (see Table 2) to determine its satisfaction levels. The Categorization metrics are divided into three main parts (satisfaction levels): basic, performance, and delighter competencies. In each part a number of parameters are considered for the roles (project management, requirement analysis, software design, programming, validation & verification, configuration management, test & quality, and documentation). The key in this is the satisfaction levels and the determination of the essential competencies. Therefore, one can avoid using the soft and hard categorization and use any categorization suitable to the project. The development of the two models above was iterative and conducted with expert consultation that will be detailed next. 5 Fig. 2 shows the research process phases followed in this study. In each of the three phases, we used different methods and sources for collecting research data.

Phase 1
In phase 1, we reviewed the SEC literature (cf. Section 2.3) to understand different models and frameworks used for identifying, assessing, and evaluating or managing competencies in software engineering. To that end, several studies were identified and considered including [4, 8,71-74, 10,14,24,49,51,66,68,69]. After an analysis, it was apparent that the SEC research area lacks a holistic model or framework that can be used by both practitioners and academics without resorting to a heavy academic exercise. Furthermore, existing models dealt with the stakeholders separately [24]. Therefore, to develop a unified and comprehensive framework, we adopted the Kano model and CFSE as a starting point. Thus, the initial version that had the intention of identifying competencies of software development, in general, was achieved through the literature review and the competence analysis. This version was subsequently carried to phase 2 for further development.

Phase 2
In phase 2, different versions of the framework were published in peer-reviewed conferences. This was done to obtain feedback for the incremental design of the final framework. The first version (i.e., version 1) was published as a work-in-progress in the proceedings of Euromicro SEAA 2019, Greece. The framework was presented to the conference participants of the work-in-progress track, to collect feedback for the incremental development of the framework. Thus, the conference was used as a forum for collecting data from a group of experts on the subject (i.e., similar to a focus group discussion). Participants in the session were informed of this intended purpose of the presentation, the framework was presented to them, and their comments and suggestions were collected by the first author. The participants suggested two main areas for improvement. First, competence categorization (i.e., soft and hard) is essential for the development of the framework, mainly because both categories have different meanings and usage [32]. Second, the satisfaction levels of SEC must be added as a key new feature to the framework.
In the follow-up versions 2a and 2b, the categorization of the competencies was considered. Thus, two different frameworks were created, for soft and hard competencies respectively. The SEC research has so far treated hard and soft competencies as separate categories. Therefore, creating a framework for each was necessary at this point. Additionally, a minimum satisfaction level was introduced in both versions, 2a and 2b   (cf. Section 2.6). These two versions of the framework were presented at separate conferences. This was deliberate, to validate the feedback on the initial version (version 1). The hard competence framework (version 2a, (UFHCSL) was presented at the 10th International Conference on Software Business 2019 (more details in [65]). Participants of the conference were at all occasions informed that the paper presentation will be used as a focus group discussion to take feedback for the incremental development of the framework. At the end of the discussion, it was noticed that presenting only the hard competence framework does not argue strongly for a full development stack of software. Also, since the framework is not only focusing on the identification of competencies, but it includes the determination of satisfaction levels, there is a need to complement it with the soft competence framework. Additionally, it was also noticed that role titles differ in different software development processes; therefore, it will be appropriate to use generic role titles for the framework. Furthermore, presenting only the proposed framework without some preliminary results, to justify its validity is not enough for the participants to appreciate its usefulness. Version 2b (UFSCSL) was presented at the 12th International Conference of Software Quality Days 2020. In this conference, we presented the framework for soft competencies (more details in [64]). Additionally, we acted upon one of the feedback items from version 2a, which is to use the proposed framework to analyze competence data and include it as a preliminary result. The focus group discussions focused on version 2b framework, with identified competencies and the satisfaction levels proposed. At the end of the discussions, the following were noted for further development: (i) for the study to be appreciated by the community, both categorizations must be considered, and (ii) the determination must be shown as a blueprint rather than a static identified competence for all projects. It is worth mentioning that the conference setup, which has similarities to a focus group discussion, adds to the reliability of the evaluative feedback: The authors have no direct connections to the attendees, nor can they influence the discussion at a forum moderated by the track chair. Additionally, the conferences were targeted both at the academic and professional communities. The track attendees have interest in the subject area, and diverse research and practice experiences and perspectives. Therefore, their opinion on how to move forward with the development can be considered objective.
In all three stakeholder's consultation was administered before the final framework was developed. Fig. 3. shows participants of the stakeholder consultations. The participants were people who participated in the specific track in which the said papers were presented. That is, for the Euromicro SEAA 2019 Greece (Work-in-progress track), 10th International Conference on Software Business 2019, Finland (Software Business Education track), and International Conferences on Software Qualities 2020, Austria (Industry Challenges and Collaborations track).

Phase 3
To achieve the goal of this study, which is to develop a holistic framework for the determination of satisfaction levels for SE competencies and the essential competencies for SE, we propose a framework that can be used by both academia and practitioners. In phase 3, we developed the final proposed framework, called Unified Competence Gate for Software Professionals (UComGSP), the assumptions of the framework, and a scenario of using the framework. As already stated, the proposed framework must support the key SEC stakeholders in determining the satisfaction levels and essential competencies for software engineering. As suggested earlier, here 'competence' is treated as a 'product' (cf. the Kano model) to be developed, as expected by the 'customers' of that product, meaning the software community. Fig. 4. shows an overview of the three steps for using the UComGSP. Before entering step 1, the definition of the project is provided by the project manager or management team; this includes details to enable a concise project type selection. In the first step, based on the project definitions, the project management identifies the competencies needed for the project. In the second step of the process, each identified competence is assessed using the metrics in Table 2. Based on the assessment, the competencies are classified to be either basic, performance, or delighter. If the value of a competence satisfies metric 1, it is classified as basic, if it satisfies metric 2, it is performance, and if it satisfies metrics 3, it is delighter (see Table 2). In step 3, the prioritized list of competencies generated in step 2 is used to select a candidate with the most suitable profile.
In the next section, we present a scenario to illustrate the use of the proposed framework (UComGSP). Table 3 contains competencies that have been identified and classified using the categorization of hard and soft competencies.
To make a choice using the metrics stated in Table 2, the following must be observed. The categorization of soft competencies (teamwork, knowledge transfer, and cooperation) was used as an example to illustrate how the choice is made. On the hard competencies' categorization (coding competencies across platforms, good coding skills, and basic coding skills) were also used to show how the choice is made. Making a choice as preference will mean that, cooperation which is a behavioral competence is defined as the ability to work with others in a software project which is required in any software project. This competence meets metrics 1 in Table 2. Thus, cooperation will be classified as basic competence. Teamwork is a competence that allows software professionals to work together for the effective development of a software product or service. Teamwork leads to higher performance in a software project. Therefore, they are expected pre-requisites that are known, and they are essential influential factors on the software industry decisionmaking options on competence. These are critical pre-requisite requirements that create high levels of satisfaction when employed appropriately. Therefore, teamwork meets metric 2 in Table 2 and is classified as performance competence. Knowledge transfer competence is a behavioral competence of having an outstanding ability to impart knowledge to others in a software project. This type of competence does not engender any complaints from the software industry when absent from the software professional. However, it surprises the software industry when present. Thus, a knowledge transfer meets metrics 3 and is classified delighter. Basic coding skills are technical skill such as the ability to read and understand code. This competence is required from any software professional. Such competencies are taken for granted; however, their absence will be noticed by the software industry. Therefore, they meet metric 1 and are classified as basic competence. Good coding skills are technical competence such as commenting well and self-reliance in coding. Such technical competencies are expected pre-requisites that are known, and they are essential influential factors on the software industry decision-making options on competence. Therefore, it is a performance competence. Coding competencies across platforms is a technical competence of being able to code on multiple platforms. Thus, it is a technical delighter competence. Using the scenario illustrated above the software community can use the framework proposed (UComGSP) above to determine the satisfaction levels of competencies for any software project. Table 4a. provides details of the competencies and their satisfaction levels used in the scenario.
Basic competencies (satisfaction level) are pre-requisite competencies that are necessary and are expected by the software industry. Mostly they are taken for granted. The software industry sees these competencies as natural when delivered properly. However, when delivered poorly, the software industry will complain. Performance competencies (satisfaction level) are competencies that the software industry expects and can articulate. They are mostly in the minds of the software industry actors, and when they are delivered well, they create more satisfaction. These competencies can be described as "uni-dimensional" competence. Delighter competencies (satisfaction level) are competencies unexpected by the software industry. Mostly unexpected by the software industry but increases the delight and surprise when available; However, its absence may have no effect on the software industry. It is important to note that the satisfaction levels have been formed by the researchers and not professionals (interview data). However, the models and the levels were presented to professionals (in workshops) to get their feedback for further development of the final model.
In developing the final version, which is presented in this paper, all feedback from the group discussions was taken into consideration. Thus, in this paper, to provide an avenue for different usage of the framework, we present the two separate frameworks, one for soft and one for hard (cf. Section 2.5) competence for determination of competence and satisfaction levels. Additionally, we present a scenario for determining satisfaction levels based on different software projects. Thus, Fig. 5 is the final framework. The A -UComGSP shows the framework without the competencies used to illustrate how to use the framework. The B -UComGSP shows the framework with specific competencies stacked to show the levels.
The proposed framework can be used by software professionals, educators, and the software industry. Software professionals can use the framework to determine with which competencies they are employable. Educators can also use the framework to determine which competencies they need to teach to the software professionals for them to be employable. Finally, the software industry can also use the framework to

Framework validation
We use a job advertisement for the position of software developer published on monster.com (see Appendix E) to show how the UComGSP can be used for the selection of a suitable candidate depending on the project, and the satisfaction level is expected to be achieved in the project. As pointed out by [75], a competence framework enables companies to efficiently manage the competencies of the employees in terms of recruiting and optimizing their employment. To that end, depending on the objective of the software project, the UComGSP helps in prioritizing the competencies needed to successfully complete a software project. A common description of necessary and desirable competencies in job advertisements include statements like "required skills to succeed in this job" and "valuable skills but not necessary". The question is how project managers determine these different categories and how do they select people for the said positions. In our example, we assume that a project manager uses the UComGSP to guide the job profiling process for one-person software development project or a small software development team. In step 1 competence identification, the project manager identifies the competence needed for the job. As can be seen these competencies are identified and are listed. In this scenario, the competencies are listed in Table 4b column 2 and categorized according to the satisfaction levels proposed in the UComGSP. In step 2 competence prioritization, we used the gate to prioritize the competencies (cf. Section 3.3). Table 4b column 3,4, and 5 show the prioritization for this job seeking to fill a software developer role.
Step 3 candidate selection, based on the resume of the candidates, selection is made using the prioritization guide for step 3. Now, let us use two different scenarios to demonstrate how our framework can help managers to choose a suitable candidate. In the first scenario, the new software developer is expected to complete a one-person software development project (i.e., all the activities in the project are conducted by one person). In this scenario, someone with all the five competencies is an ideal candidate, someone with the first four competencies (i.e., all the basic and performance competencies) is desirable, and someone with the first two competencies is satisfactory for completing this project.
In the second scenario, the new software developer will join a small software development team. Using Table 4b, the project manager can prioritize candidates so that the combination of team members' skills would suit their intended satisfaction level. In small development teams, the members must collectively have the skills and competencies required for delivering the project on time and within budget [76]. However, considering the collaborative nature of such projects communication and teamwork skills are crucial [29]. Therefore, in this scenario, someone with all the five competencies is an ideal candidate, someone with great communication skills and the skills missing in the team is desirable, and someone with skills missing in the team is satisfactory for completing this project.
Even though we used "project manager" for the illustration, as suggested by [23,24], the development of competencies is not the sole responsibility of one role or even only one institution. We believe that other stakeholders can also consider the framework in a similar manner.

Data collection and analysis
To validate the framework, an interview data set with 138 participants from various positions within the industry (i.e., software engineers, managers, supervisors, mentors) was used. All the participants were from Norway. Students of SE course at Norwegian University of Science and Technology (135) conducted the interviews with a given interview structure from the course lecturer. 1 The interview data was processed by 4-5 students into a spreadsheet (Appendix A). To analyze the data, we followed the guidelines suggested by [77,78]. Fig. 6 represents an overview of the respondents' characteristics.
As the data set was qualitative data and the authors also aimed to analyze it with a qualitative approach, we made use of content analysis. Content analysis can be used to characterize responses in an open-ended survey, focus group, and interview transcripts [79,80]. It is defined as exploring large amounts of textual information in an orderly way to establish a trend or pattern [81]. "Content analysis is a research technique for making replicable and valid inference from texts (or other  Analytical mindset and problemsolving skills x v Experience in consulting or digital commence x meaningful matter) to the contexts of their use" [80]. In this study, it will be used in determining the presence of certain themes or concepts within an interview data of 138 participants into an organized and concise conceptual structure. The expected outcome of content analysis can be quantitative or qualitative. We examine meanings of the content of the interview data for the identification of relevant concepts based on the research question "what are the competencies expected from persons working as software professionals in your organization". A content analysis must follow a certain procedure [80]. Thus, [80] developed a framework for content analysis with the following components: texts (a body of the text of which the analytical effort will begin), Research questions (a question of which the text will help to answer), context (context of the analyst's choice of making sense of the text), Analytical constructs (units of words for the operationalization of the research question), inference (meaning extracted to answer the research question), and validating (evidence to justify the analysis). In addition, [82] proposed the following six steps: design, unitizing, sampling, coding, drawing inferences, and validation for conducting a content analysis. [79] also suggest the following: start with a research question, decide on a sampling strategy, define the recording unit, construct categories for analysis, test the coding on samples of the text and assess reliability, and carry out the analysis as what to consider, when using content analysis for empirical study. Both [79] and [80] agree that there is a certain methodological approach for conducting a content analysis study, and that the methodology adds to the rigor. Therefore, adopting the steps recommended by [79] and [82], we followed the stages and steps shown in Fig. 7 for perfroming the content analysis.
As can be seen from Fig. 7, the processing of the interview data and the analysis followed in three stages, familiarizing with the data set, coding and classification, and developing the framework. We explain each of these stages, steps, and the outcome as sub-sections below.

Stage onedata set
Step 1 in Fig. 7 shows the selection of dataset used for the content analysis. The dataset consists of interviews with 138 software professionals in a supervisory role including senior software engineers, team leads, managers, and mentors from Norway. The data set includes the transcripts of interviews in English, demographic information about the participants, and the lists of competencies mentioned by them. In Step 2 (Fig. 7), the first author familiarized themselves with the data set. This was done by reading through the original transcripts and the competencies extracted from the transcript. The listed competencies were entered into a spreadsheet to allow for easy coding. Discussions were made with the head of the data collection team to resolve any ambiguity in the data. In Step 3, the first author revisited the interview questions and the listed competencies to compare both data. This was to enable the first author to properly get acquainted with the data with a specific focus on the interview questions and the research question for this study. At the end of stage one, it was concluded that the data source contains texts that can be used for the analysis. Table 5 shows a sample of interviewees and the competencies that they expected from a software professional. The directed or theory-led approach for coding is appropriate for this text because it allows for a top-down or theory-driven approach to coding based on emerging themes from literature. This process was done together by all the authors.

Stage twocoding
As can be seen from Table 5, the data source brings forth competencies mentioned by different participants that are the same, similar, or unique depending on which part of the information communication technology industry the participants are coming from. However, our aim is to identify competencies for software development. This we did by  N. Assyne et al. coding and classification of the data set by manually reading the listed competencies in the spreadsheet. Therefore, we made an attempt to find consistent meaning by finding patterns and themes. In Step 4 to Step 7, the coding is performed. Coding and classification are defined as the segmenting and categorizing meaningful analytical units from a text [80].
Step 4 (Fig. 7), Organizing communication is the starting point of the coding process. In this process, we focus our reading of the text by identifying the exact meanings of the phrases or terms provided by the participants specifically, mentioning words as skills, knowledge, or attitude. We focused on the manifest meaning of the obvious contents of the text. This is because the interview questions asked the participants to list the competencies, they expect from software professionals. Thus, the intent was obvious in the text. In Step 5 Identify relevant content, we focus on meaning relevant to our question, therefore, the manifest meaning was used for coding. Therefore, the descriptive meaning of skills, knowledge, attitude, etc., were used to identify the relevant content. This was done by working manually through the text in the spreadsheet. In Step 6, we classified the identified relevant contents to themes. That is, codes with the same meaning were grouped together. This was done by identifying patterns and connections in the codes. Thus, we developed a master list with all identified codes. At this stage, 641 codes were identified (1st order concepts) without paying attention to duplicates. Therefore, in Step 7, we removed duplicate codes, i.e., coded units with the same meaning. This was done according to the objective of the study, to identify competencies of software professionals. At the end of Step 7, a new master list of 125 codes was generated by assigning fitting or more appropriate names to the generated codes, with reference to previous literature. Table 6 shows some of the codes (different codes identified) and final codes names (proposed fitting name) after the coding process (2nd order themes).
In Step 8, we approached the master list generated using the deductive approach. That is, the generated codes were classified using the categories "hard" and "soft" competencies (aggregate dimensions). Thus, we identified 63 soft competencies and 62 hard competencies (see Fig. 8). In all, three levels of grouping were applied to our raw data during the analysis. As suggested by Gioia et al. [83], one of the features of rigor in qualitative research is how analysis is approached. As explained above, We illustrate our approach by adopting the concepts from the work of [83]. That is, "1st order concepts", "2nd order themes", and "aggregated dimensions". The 1st order concepts were identified leading to creating the 641 list codes. These 1st order concepts where categorised as 2nd order themes, which were ultimately were aggregated resulting in aggregated dimensions such as hard competencies, soft competencies, satisfaction levels, and the identification of competencies using the roles of software engineering.

Stage threedevelop
As stated in Section 3.5 the participants were asked open-ended questions about the competencies needed and expected from software professionals working in their organization. However, the theoretical lens, the UComGSP was used during the analysis of the data. Section 3.5.3 Therefore, we applied our development frameworks (UFSCSL, UFSCSL, and UComGSP) to respond to the main research question of the study as the final analysis (cf. Section 3.3). This results in the development of the soft and hard satisfaction levels of software professionals, the identification of the essential competencies, and the proposed UComGSP for future competence identification template. UComGSP is developed based on Kano as a theoretical base, secondary data from SE literature, and feedback from experts. It entails Kano and CFSE.  Category names and codes after content analysis.
Proposed fitting name Different codes identified Basic Programming Skills coding skills, be able to code, write understandable code, skill to assess code, able to interpret the code, programming skills, programming languages, programming, basic principles of programming, basic principles of programming, basic programming skills, fundamentals in programming, enthusiasm for programming, knowledge and skills related to programming, good knowledge of the fundamentals Good Programming Skills good at coding, writing good code, well-written code, write good and effective code, writes code that is robust and easily maintainable, write code of high quality, good at coding, ability to program well, ability to program well, ability to program well, being a good programmer, good at programming, broad knowledge of programming, programming experience and coding skills, being a proficient coder Development Process Skills broad understanding of design, user-oriented design, utilize existing solutions, design methodology/documentation requirements, knowledge of the whole software development process, basic knowledge of systematic working methods, development process, adapt methods and software Leadership Skills Leadership, arouse enthusiasm in others, ability to inspire, understand people they work with, estimation of workload, approachable, ability to handle a high workload, understanding of the corporate structure, constantly communicate status Teamwork team spirit, communication and working together in a team, master cooperative teams, communication and teamwork Self-Reliance Skills eager and independent, independent, work independently, self-reliance, ability to work independently, able to work independently, work independently, independency, work efficiently as an individual Fig. 8 shows all the competencies identified during the content analysis. These competencies are classified into soft competencies (n = 63) and hard competencies (n = 62). As can be seen in the figure, soft competencies are divided into two main groups of social and personal competencies. The figure also shows the satisfaction levels for each group of competences.

Satisfaction levels of soft and hard competencies
The results show the individual competencies and their satisfaction levels, meaning basic, performance, and delighters. The soft competence was grouped according to the broader category of social and personal competencies. With regards to hard competence as stated in Section 3.4.3, the analysis was done using UFHCSL. Therefore, we present the result using the roles of software engineering from SWEBOK [63]. The roles as stated in the UFHCSL are project management, requirement analysis, software design, programming, validation and verification tests, configuration management, tests and quality engineering, documentation, and maintenance. We also provided definitions using the classification levels from the Kano model for the competencies. It is worth mentioning that the satisfaction levels are dynamic and might differ based on a role or a project. Fig. 8 shows soft and hard competencies and their satisfaction levels.
As shown in Fig. 8, out of the 63 soft competencies s, 34 were personal competencies and 29 were social competencies. Personal competencies are personal attributes for working well in different spheres of life, while social competencies are competencies for organizing cooperation and interpersonal relations in a software development project. In the social competencies category, cooperation and work in a team had the highest number of items (13), followed by interpersonal relation and handling and solving conflicts with eight each. In the personal competencies category, development in the job environment has the highest number of competencies with 17, personal development is next with 14 competencies, followed by rights and limits with four competencies. The result also shows that performance satisfaction level is highest with 26 competencies. These are what the software community expects and can articulate. They are mostly in the minds of the software community and when they are delivered well, they create more satisfaction. These competencies can be described as a "uni-dimensional" competence in that the satisfaction grows exponentially when executed properly. Basic satisfaction is second highest with 21 competencies. Basic competencies are pre-requisite competencies that are necessary and are expected by the software community. Mostly they are taken for granted. The software community sees these competencies as natural when delivered properly. However, when delivered poorly, they will complain. Next is delighter with 16 competencies. They are competencies that are unexpected by the software community. Mostly unexpected by the software community but increases the delight and surprise when available however its absence may have no effect on the software community. Fig. 8 further shows hard competencies and their satisfaction levels using the roles of software engineering. Programming has the most, 20 competencies. It is followed by software design with 11 competencies, requirement engineering with ten competencies and test & quality engineering with six competencies. Configuration management and maintenance have five competencies each, whereas project management has only three, and documentation has two. In our data, no competencies were identified for validation and verification. As stated earlier, this phase of the study focuses on hard competencies and their satisfaction levels. Table 6 shows only data regarding hard competencies. Readers interested in the satisfaction levels of soft competence can read more detail on the soft competencies and their satisfaction levels in the work of [84]. For the satisfaction levels, 28 hard competencies were identified as pre-requisite competencies necessary and are expected by the software community: 25 performance satisfaction levels and nine delight satisfaction levels. Despite categorizing the competencies based on the traditional software engineering roles proposed by SWEBOK, we believe that the UComGSP framework can be used by newer methods such as agile and DevOps. For instance, effective communication, collaboration, and teamwork are three agile SEC proposed by [85]. These soft competencies are also considered in our framework, as shown in Fig. 8. Therefore, it is important to note that the competencies included in our framework may change depending on a specific methodology. However, as stated the framework allows for providing inputs and output based on the dynamics of the projects.

Essential competencies of software professionals
According to the definition of [21], delighters are attractive or so-called "wow"-factors that are valued in a product. Therefore, we present our delight competencies as the essential competencies for software engineering. Since we intend to show the essential competence of software professionals, we present the essential competencies for both hard and soft competence categories Table 7 shows the competencies we classified as the essential competencies. This is divided into soft and hard competence categories. A total of 25 essential competencies were identified from our data. This is made up of 9 hard essential competencies and 16 soft essential competencies.

Discussion
In this study we aimed at developing a holistic framework for determining the essential competencies for software development that can be customized according to the type of a software project. Upon analyzing the extant literature, we identified a lack of frameworks that take into consideration the key SEC stakeholders (i.e., software industry, software professionals, and educators). Therefore, we propose the UComGSP, a framework that enables different SEC stakeholders to identify software professional competencies, including the essential ones, and to determine their satisfaction levels.

Contributions
Our study has several contributions to research and practice. First, even though previous research has treated soft and hard competencies separately, our study contributes with a framework that allows for a holistic view. The difference between some of these soft and hard competencies is becoming narrower. An example is the definition that hard competencies can be taught [86]. In fact, these days, soft competencies are also being taught. With the holistic framework resulting from our study, SEC studies can consider the key stakeholders in one look instead of looking at them individually. Additionally, to advance research on SEC, we have analyzed different models and frameworks of SEC to elicit variables (stakeholders, software engineering roles, competence categorization, competence satisfaction levels, personnel competence, organizational competence, and essential (cf. Table 1)) from literature. This analysis provides a pretext for studying SEC or analyzing and comparing different SEC models and frameworks.
Additionally, in this study, we identify 25 essential competencies of software professionals. Sixteen were soft essential competencies and 9 were hard essential competencies. Most of these identified competencies are consistent with the ones reported in previous studies such as [6,38,87,88]. However, we made a total of 11 new observations of essential competencies (e.g., business knowledge, knowledge of industry standards, coding competencies across platforms, knowledge transfer). Under them, seven belong to hard competencies and four to soft competencies. We present the complete list using the categories UFSCSL and UFHCSL in  (12) can apply theories in application development, (13) see opportunity in systems, (14) initiative, (15) separate work and being available, (16) self-sufficient appendices B and C. It is important to note that we do not mean the new observations are new competencies. Rather, they are not reported in previous SEC literature, to the best of our knowledge. Thus, we call for further empirical research to learn more about these new observations in the SE environment. For instance, software security used to be considered after the development of the software, but this is not the case anymore [89]. For this reason, IT security, which is observed as a new competence for software professionals, needs to be investigated further to understand the implications on software development. We argue the same for all new observations identified in this study. Previous studies suggest that the essential competencies are a core part of SEC studies and that a landmark study on the essential competence was published in 1995 [6]. The SE field has evolved greatly since the 1990 ′ s. In Appendix D, we compare the essential competencies identified in this study with prior studies. Furthermore, according to the findings of this study, agile methodology skills are a prerequisite competence necessary and expected from software professionals. Therefore, we cannot separate agile methodology skills from other SEC, but pay attention to them in any curriculum development for software engineering.
In practice, the UComGSP framework can be used for SEC management. This includes the development, assessment, and customization of SEC, across software projects. The SEC stakeholders can use the framework to identify competencies, determine their satisfaction levels, and identify the essential competencies for software development. Development teams and companies can use this framework to identify competencies that are needed for a particular software project. As discussed before, and also highlighted by [90], staffing people for software development is not straightforward. Using the UComGSP, organizations can assess the competencies needed for a particular type of software or project and fill the software engineering roles accordingly. Similarly, considering that the quality of software products is influenced by software professionals competencies [31], an organization can assess the satisfaction level they may derive from a particular competence. In other words, software developed by employing the most suitable and relevant bundle of SEC more likely excels in quality and is successful in the market.
Another important contribution of this study is categorizing SEC into three satisfaction levels. As such, the UComGSP provides a means to assess the competence level of software professionals (i.e., the satisfaction level of competence) at three levels: basic, performance, and delighter. The UComGSP can be used by companies to determine the basic competencies expected from software professionals before they can be employed. Similarly, there are some competencies that enable an organization to increase its performance in developing software products and services. Lastly, delighter competencies are not expected from software professionals before they can be employed. However, they give an edge to the companies in the competition. The software professionals can also compare their competencies to the framework. They can use it to determine pre-requisite competencies (basic competencies) and competencies that they can develop when they are working in the industry (performance and delighter competencies). For a professional, performance competencies become a benchmark for employment while delighters give them a competitive advantage in the employment market. Therefore, software professionals can use these levels as a careerbuilding ladder and manage their career path, which, according to [31], is one of the problems facing software professionals. The educational institutions providing the foundational competencies and training software professionals can use the framework to identify and consider for their curricula the competencies expected by the software industry.

Limitations
To discuss the limitations of this study, we use four types of threat to validity suggested by [91] and [92]. Construct validity concerns the use of the right operational measures to study the main research phenomenon, in our case SEC. SEC is associated with individuals and enterprises [93,94]. Therefore, the concept sometimes becomes misconstrued when studying it. Thus, in this study, to mitigate this threat, we based this study using operational words from the definition of [23][24][25]27]. Thus, the transcribed interviews were analyzed using well-established operational words from literature. Additionally, this study used the identified competencies to propose the essential competencies of software professionals. It is important to note that previously studied models and frameworks were used to attain the results. Furthermore, the results were compared with previous studies on the subject matter to see the consistency of our results.
Causal relations as it relates to the internal validity was not an issue with this study. This is because we did not apply statistical inference in this study for causal relationships. Thus, this study did not suffer this threat.
External validity concerns the extent to which the findings of a study can be generalized [91]. Our study is based on literature review, interview data, and group discussion. The first limitation is related to the scope of the literature review. As mentioned in Section 3.1, we have specifically focused on identifying different models and frameworks related to SEC. Therefore, because of this methodological decision we might have excluded some studies that do not focus on SEC, but still proposing competency frameworks (e.g., on human resources in general) that could be used also in the SEC context. Another limitation of the study is the scope of the data collection was conducted in companies situated in one country (Norway). Nevertheless, most of the companies that the interviewees worked for have global representation and businesses outside Norway. Additionally, it must be noted that the cultural settings of the Scandinavia counties are similar. Notwithstanding this, the limitation invites further studies with data from other countries to test the generalizability of the results. With the development of the competence satisfaction levels, we call for further studies to understand how specific competencies evolve within different projects. That is, how the competencies of an individual evolve and the competency within a software organization (e.g., a software or IT company, or IT organization within a user organization) develops its SE competency as part of their HR management.
Finally, reliability as defined by [91] is the extent to which the data collection and analysis processes are influenced by the researchers involved in the study. To this end, a well-structured process for collecting and analyzing the data was developed and followed. This process that was followed has been provided in the study to allow for replication of the study. Again, since the authors of this study were not directly involved in the data collection, to increase the reliability of the finding, the authors consulted the leader of the data collection team during the analysis stage to resolve ambiguity in the dataset. On the development of the frameworks, we purposefully selected different conferences that are attended by both practitioners and academics. Thus, the process of validating the frameworks was done by the key stakeholders in SEC. Last but not least, different data sources were used to attain the findings.

Conclusions
This study aimed to provide a holistic framework enabling SEC stakeholders (i.e., software professionals, educators, and the software industry) to (i) identify SE competencies, (ii) identify the essential SEC, and (iii) assess the satisfaction levels derived from those competencies. A qualitative approach was adopted for the study for the reason to be open to emerging issues. The research literature on SEC, interview data from 138 participants in various positions within the industry in Norway, and expert consultations were used to develop and validate the proposed framework. In total, we identified 63 soft competencies and 62 hard competencies and mapped them to the acknowledged roles in the software engineering practice. Amongst the identified competencies, 25 essential competencies of software professionals were identified. We have also provided a working definition for the essential competencies as the skills, knowledge, and attitudes of software professionals necessary for excellent performance in a software project. Next, using the Kano model of quality assessment, the competencies were analytically assigned to three satisfaction levels (i.e., basic, performance, and delighters) with the respective definitions. Through a scenario illustration, we demonstrated how SEC stakeholders could evaluate the competence levels for different software projects. However, we suggest further research to understand how competencies within the satisfaction levels can change (e.g., from basic to performance or delighter). Future research is needed to further study and validate the newly observed competencies, from which 11 were classified as essential competencies. Additionally, the developed framework must be validated by allowing the stakeholders to use it in software development projects.

Data Availability
Data will be made available on request.

A. Appendices
Appendix A -Interview structure