SWECOM Public Review PDF

1 TheSoftwareEngineeringCompetency
2 Model(SWECOM)
3 Contents
4 1. Introduction
5 2. SWECOM and the US IT Competency Model
6 3. The Elements of SWECOM
7 4. SWECOM Technical Skills
8 5. SWECOM Competency Levels
9 6. Employer and Individual Gap Analysis
10 7. SWECOM Validation
11 8. Acknowledgements
12 9. References
13 10. Glossary of Terms
14 11. Software Requirements Skill Area
15 12. Software Design Skill Area
16 13. Software Construction Skill Area
17 14. Software Testing Skill Area
18 15. Software Sustainment Skill Area
19 16. Software Process and Life Cycle Skill Area
20 17. Software Systems Engineering Skill Area
21 18. Software Quality Skill Area
22 19. Software Security Skill Area
23 20. Software Safety Skill Area
24 21. Software Configuration Management Skill Area
25 22. Software Measurement Skill Area
26 23. Human-Computer Interaction Skill Area
27 24. Appendix A: Contributors
28 25. Appendix B: SWECOM Intended Audiences
29 26. Appendix C: SWECOM Use Cases
30 27. Appendix D: Gap Analysis Worksheets
31
SWECOM 1 IEEE 2014
32 ASoftwareEngineeringCompetency
33 Model(SWECOM)
34 Abstract
35 This software engineering competency model (SWECOM) describes competencies for software
36 engineers who participate in development of and modifications to software-intensive systems.
37 Skill areas, skills within skill areas, and work activities for each skill are specified. Activities are
38 specified at five levels of increasing competency. Case studies of how the SWECOM model can
39 be used by a manager, an employee, a new hire, or a curriculum designer are provided. Staffing
40 Gap Analysis and Individual Gap Analysis worksheets are included in an appendix.
41 1.Introduction
42 A competent person has the skills needed to perform, at a given level of competency, the work
43 activities assigned to her or him. Knowledge in this competency model is contrasted to skill:
44 knowledge is what one knows; skill is what one can do. This document presents a competency
45 model for use by those who develop software, their managers, human-resource personnel,
46 curriculum designers, and others listed in Appendix B of this document. An individual who
47 develops or maintains software might use this competency model to assess his or her current
48 competency levels for various software engineering activities or to develop a plan for improving
49 her or his competencies (e.g., requirements elicitation, design synthesis, software construction,
50 test planning). A manager (project, functional, or line manager) might use this competency
51 model to inventory staff skills and identify areas for needed additions and improvements. In
52 addition, a manager might use this model to counsel individual employees. Also, HR personnel
53 might use the model to identify needed training and recruitment activities. Each activity in this
54 competency model is described at five levels of competency.
55 Skill areas in this competency model include skills that are decomposed into activities, rather
56 than job roles, because job roles are typically dependent on the organizational environment in
57 which the work activities occur. The activities in this model can be grouped into job roles by
58 organizations, organizational units, and projects to satisfy their needs.
59 This competency model is termed the Software Engineering Competency Model (SWECOM). It
60 has been validated by invited reviews from subject matter reviewers and reviews from interested
61 public reviewers. Subsequent revisions have been made in response to those reviews. The
62 contributors to development of SWECOM are listed in Appendix A.
63 Appendix B lists the intended audience for SWECOM. Appendix C includes use cases to
64 indicate how managers, employees, and new hires might find SWECOM to be useful. Appendix
SWECOM 2 IEEE 2014

65 D includes gap analysis worksheets for use by individual practitioners and those who do staffing
66 for projects and organizational units. A Glossary of Terms provides definitions of terms whose
67 meanings, as used in SWECOM, may differ from conventional meanings.
68 SWECOM includes skill areas, skills, and activities for individuals who develop and maintain
69 software (i.e., software engineers and other persons). SWECOM is based on the following
70 primary references:
71 SWEBOK Guide Version 3 (Guide to the Software Engineering Body of Knowledge),
72 ISO/IEEE Standard 12207 (software engineering processes),
73 Elements of ISO/IEEE Standard 15288 (systems engineering processes)
74 applicable to development of software-intensive systems,
75 Relevant material in SEBoK (Systems Engineering Body of Knowledge) and
76 GRCSE (Graduate Reference Curriculum for System Engineering),
77 The Software Assurance Competency Model,
78 GswE2009 (graduate software engineering curriculum guidelines), and
79 SE2004 (undergraduate software engineering curriculum guidelines).
80 The references section of this document provides citations for these foundational documents.
81 This competency model adds to the growing body of knowledge that characterizes the software
82 engineering profession and software engineering professionals. It is based on, and supplements,
83 the information in the primary references and the extensive list in the references section.
84 SWECOM is presented as a framework that can be tailored to fit the needs of organizations,
85 programs, and projects. It is not a prescriptive model of the software engineering profession or a
86 characterization of a software engineering professional. Various organizations, agencies, and
87 other institutions may choose to adopt and enforce particular elements of the model as fits their
88 needs and to extend SWECOM in various ways.
89 SWECOM covers technical skills but does not include project management or general
90 management skills, other than to identify the behavioral attributes and skills of effective software
91 developers and the leadership skills needed by technical leaders of the various skill areas for
92 software projects. The PMBOK Guide Fifth Edition [PMBOK 2013], the Software Extension
93 to the PMBOK Guide Fifth Edition [SWX 2013], and many other references address project
94 management and general management. Also, SWECOM does not recommend specific software
95 tools or development methods (e.g., waterfall, Scrum, XP).
96 2.SWECOMandtheUSITCompetencyModel
97 SWECOM includes elements similar to those in the US Department of Labor Information
98 Technology Competency Model (US IT) that was developed to identify the knowledge, skills,
SWECOM 3 IEEE 2014

99 and abilities needed for workers to perform successfully in the field of information technology
100 [INFOCOMP 2012].1
101 Table 1 indicates the correspondences between the Information Technology Competency Model
102 and the analogous elements of SWECOM.
103 Table 1. Correspondences between the US IT Competency Model and SWECOM
US IT Competency Model SWECOM
Personal Effectiveness Behavioral Attributes and Skills
Academic Competencies Requisite Knowledge for SWECOM
technical skills
Workplace Competencies Cognitive Skills
Industry-Wide Technical Competencies SWECOM Technical Skills
Industry-Sector Technical Competencies Possible extensions to SWECOM for
software applications, embedded
software, and domain-specific
competencies (e.g., health sciences,
communication, automotive domains)
Management Competencies Skills related to scheduling,
budgeting, and resource management
are excluded from SWECOM
Occupation-Specific Requirements Excluded from SWECOM
104
1
Information technology is broadly interpreted in the US IT competency model.
SWECOM 4 IEEE 2014

105 As indicated in Table 1, Knowledge, Behavioral Attributes and Skills, and Cognitive Skills are
106 the counterparts of Personal Effectiveness, Academic Competencies, and Workplace
107 Competencies in the US IT Competency Model. Technical skills are the primary focus of
108 SWECOM; they are the counterparts of Industry-Wide Technical Competencies. The other
109 elements of SWECOM are included to support the Technical Competencies. Industry-Sector
110 Competencies for various sectors of the software engineering industry represent extensions that
111 could be added to SWECOM. Management Competencies other than leadership skills related to
112 leading technical contributors are not included because management includes a distinct, but
113 related, set of competencies that are covered in the PMI Guide to the Project Management Body
114 of Knowledge (PMBOK Guide) [PMBOK 2013], the Software Extension to the PMBOK Guide
115 [SWX 2013], and other similar documents . Occupation-Specific Requirements include factors
116 such as certifications and licensing requirements needed to pursue specific occupations; they are
117 not included in SWECOM.
118 3.TheElementsofSWECOM
119 The elements of SWECOM are illustrated in Figure 1. Cognitive Skills and Behavioral Attributes
120 and Skills are described below. These foundations are not unique to SWECOM but were
121 developed for SWECOM as necessary for effective performance of software engineering
122 technical activities. Requisite knowledge is the intellectual basis for the software engineering
123 profession. The references listed above, those cited in the references section, and those in the
124 consolidated reference list in the SWEBOK Guide (www.swebok.org, Appendix C) characterize
125 requisite knowledge.
Cognitive Behavioral
Skills Attributes and Skills
Technical
Skills
Requisite Related
Knowledge Disciplines
126
127 Figure 1. The Elements of SWECOM
128 Related disciplines include but are not limited to:
129 Computer Engineering,
130 Computer Science,
131 General Management,
SWECOM 5 IEEE 2014

132 Mathematics,
133 Project Management,
134 Quality Management, and
135 Systems Engineering.
136 There are many related disciplines. These are the closely related disciplines, as cited in
137 [SWEBOK 2014].
138 Cognitive skills apply across all skill areas, skills, and activities of SWECOM. They are
139 exhibited in the ability to apply knowledge and reasoning while performing SWECOM activities
140 within technical skill areas. Competency levels for cognitive skills are not included in
141 SWECOM, but cognitive skills become increasingly important at higher levels of technical
142 competency because the scope and complexity of work activities increases and expands as the
143 level of competency and related job assignments increases. Some examples of cognitive skills
144 are listed and briefly described in Table 2.
145 As depicted in Table 2, the SWECOM cognitive skills include four classifications. It should be
146 emphasized that these classifications are not independent: the skills listed across classifications
147 overlap and combine to support effective cognitive competencies. Furthermore, the list in Table
148 2 is intended to be illustrative of cognitive skills for software engineers and not exhaustive.
149 Citations that provide the basis for and details of these cognitive skills are listed in the references
150 section of this document.
151 Table 2. SWECOM Cognitive Skills
Cognitive Skills Some Examples
Reasoning provides the basis for making Inductive Reasoning
decisions in a logical and effective Deductive Reasoning
manner. Heuristic Reasoning
Use of Abstraction
Hierarchical and Associative Reasoning
Analytical skills are related to techniques Application of Measurement Principles
that involve data collection, organization Statistical/Data Analysis
and aggregation of the data, and analysis Root Cause Analysis
and evaluation in order to draw
Risk Identification and Analysis
conclusions or make decisions.
Impact Analysis
Problem Solving is concerned with Divide and Conquer
various methods that employ reasoning, Stepwise Refinement
analytic techniques, and prioritizing of Top-down Approach
information to solve problems.
Bottom-up Approach
Analogy and Reuse
Patterns and Pattern Recognition
SWECOM 6 IEEE 2014

Iterative and Incremental Approaches
Innovation involves skills used to create Brainstorming
models and abstractions that support Prototype Development
analysis and problem solving. Modeling and Simulation
152
153 Behavioral attributes and skills are exhibited in the ability to productively apply knowledge,
154 cognitive skills, and technical skills; they are not unique to software engineering, but they allow
155 software engineers to contribute to desired outcomes in an effective manner. Some important
156 behavioral attributes and skills for software engineers are listed in Table 3; other behavioral
157 attributes and skills could be added.
158 Table 3. SWECOM Behavioral Attributes and Skills
Aptitude Exhibited by the ability to effectively perform a software
engineering task. Aptitude is not the same as knowledge or skill
but rather indicates the ability (either intuitive or learned) to
apply knowledge in a skillful way.
Initiative Exhibited by enthusiastically starting and following through on a
software engineering work task.
Enthusiasm Exhibited by expressing and communicating interest in
performing a work task.
Work ethic Exhibited by being reliable, acquiring new skills, and being
willing to perform work tasks.
Willingness Exhibited by undertaking a task when asked and capably
performing it, even if it is a task the individual is not enthusiastic
about performing.
Trustworthiness Demonstrated over time by exhibiting ethical behavior, honesty,
integrity, and dependability in an individuals decisions and
actions.
Cultural Exhibited by awareness of and accommodation for difference in
sensitivity communication styles, social interactions, dress codes, and
overall behavior based on ethnic, religious, gender orientation,
and other behavioral characteristics.
Communication Exhibited by expressing concepts, techniques, thoughts, and ideas
skills in both oral and written forms in a clear and concise manner while
interacting with team members, managers, project stakeholders,
and others; includes effective listening.
SWECOM 7 IEEE 2014

Team Exhibited by working enthusiastically and willingly with other
participation team members while collaborating on shared tasks.
skills
Technical Exhibited by effectively communicating a vision, strategy,
leadership skills method, or technique that is then accepted and shared by team
members, managers, project stakeholders, and others.
159
160 Behavioral attributes and skills apply to all elements and at all levels of technical skill areas,
161 skills, and activities. They and cognitive skills are not specified by competency level; however,
162 increasing competency in cognitive skills and behavioral attributes and skills becomes more
163 important as the levels of technical competencies increase and the scope of responsibilities and
164 breadth of interactions increase.
165 4.SWECOMTechnicalSkills
166 Technical skills and associated activities are the primary focus of SWECOM; they are grouped
167 as Life Cycle Skill Areas and Crosscutting Skill Areas. A Life Cycle Skill Area is one that
168 includes skills needed to accomplish various work activities within a phase of software
169 development or sustainment; for example, software requirements engineering. Life cycle skill
170 areas are categorized by typical phases of software development and modification. In practice,
171 software phases are often intermixed, interleaved, and iterated in various ways; however, no
172 implication of development processes (e.g., waterfall versus agile) is intended.
173 A Crosscutting Skill Area is one that applies across all Life Cycle Skill Areas (e.g., quality
174 assurance); crosscutting skills are applied as appropriate to each life cycle skill area, and in some
175 cases to other crosscutting skill areas, for each software project. In addition to cutting across life
176 cycle skill areas, crosscutting skill areas are sometimes called specialty disciplines that are
177 practiced by specialists in those skill areas (e.g., safety, security, systems engineering). Software
178 engineers at all competency levels typically have some working knowledge of the crosscutting
179 skill areas.
180 The five life cycle skill areas and eight crosscutting skill areas of SWECOM are listed in Tables
181 4 and 5, respectively. The references cited in the tables are in the references section of this
182 document; they provide the knowledge foundations for each skill area.
183 Table 4. Software Engineering Life Cycle Skill Areas and Skills
Life Cycle Skill Areas Skills
Software Requirements Skills Software Requirements Elicitation
Software Requirements Analysis
References: Software Requirements Specification
[ACM 2004] Software Requirements Verification
SWECOM 8 IEEE 2014

[Laplante 2009] Software Requirement Management
[Roberts 2006]
[SWEBOK 2014]
[Wiegers 2013]
Software Design Skills Software Design Fundamental Skills
Software Design Strategies and Methods
References: Software Architectural Design
[IEEE 1016-2009] Software Design Quality Analysis and
[IEEE 12207-2008] Evaluation
[IEEE 15528-2008]
[SWEBOK 2014]
Software Construction Skills Software Construction Planning
Managing Software Construction
References: Detailed Design and Coding
[ACM 2004] Debugging and Testing
[Fowler 1999] Integrating and Collaborating
[Hunt 1999]
[McConnell 2004]
[SWEBOK 2014]
Software Testing Skills Software Test planning
Software Testing Infrastructure
References: Software Testing Techniques
[IEEE 730-2002] Software Testing Measurement
[IEEE 829-2008] Defect Tracking
[IEEE 1012-2012]
[Myers 2011]
[SWEBOK 2014]
Software Sustainment Skills Software Transition

Software Support
References: Software Maintenance
[IEEE 12207-2008]
[ISO/IEC/IEEE 24765:2010]
[IEEE 828-2012]
[Lapham 2006]
[SWEBOK 2014]
184
SWECOM 9 IEEE 2014

185 Table 5. Software Engineering Crosscutting Skill Areas
Crosscutting Skill Areas Skills
Software Process Model and Life Cycle Software Development Life Cycle
Model Skills Models
Process Definition and Tailoring
References: Process Implementation and Management
[IEEE 12207-2008] Process Assessment and Improvement
[IEEE 15528-2008]
[SWEBOK 2014]
Software System Engineering Skills System Development Life Cycle
Modeling
References: Concept Definition
[IEEE 12207-2008] System Requirements Engineering
[IEEE 15528-2008] System Design
[SEBoK 2013] Requirements Allocation and Flowdown
[SWEBOK 2014] Component Engineering
System Integration and Verification
System Validation and Deployment
System Sustainment Planning
Software Quality Skills Software Quality Management
Reviews (review, walkthrough,
References: inspection)
[IEEE 730-2002] Audits (concentrates on both product and
[IEEE 829-2008] process, but it is done by an independent
[IEEE 1012-2012] internal or external organization)
[IEEE 12207-2008] Statistical Control
[IEEE 15528-2008]
[SWEBOK 2014]
Software Security Skills Requirements
Design
References: Construction
[Allen 2008] Testing
[BITS 2012] Process
[Hilburn 2013] Quality
[Merkow 2010]
[Seacord 2005]
Software Safety Skills Requirements
Design
References: Construction
[Hilburn 2013] Testing
[IEEE 12207-2008] Process
[Leveson 1995] Quality
[Stephans 2004]
[Vincoli 2006]
Software Configuration Management Plan SCM
SWECOM 10 IEEE 2014

Skills Conduct SCM
Manage Software Releases
References:
[Aiello 2010]
[Babich 1986]
[IEEE 828-2012]
[SWEBOK 2014]
Software Measurement Skills Plan measurement process
Perform measurement process
References:
[IEEE 12207-2008]
[IEEE 15528-2008]
[IEEE 15939-2008]
[SWEBOK 2014]
Human-Computer Interaction Skills Requirements
Interaction Style Design
References: Visual Design
[ISO 9241-210:2010] Usability Testing
[Rogers 2011] Accessibility
[SWEBOK 2014]
186
187 The activities for each skill in Tables 4 and 5 are listed in Tables A and Table B for each skill
188 area; see below. Tables A list the activities for each skill and Tables B list the activities by
189 competency level. SWECOM does not address competency in using tools or adherence to
190 prescribed standards to accomplish activities because these will be specific to organizations and
191 projects.
192 5.SWECOMCompetencyLevels
193 SWECOM is organized by skill area (e.g., Software Requirements), skills within skill areas (e.g.,
194 software requirements elicitation), and activities within skills (e.g., prototyping to elicit
195 requirements). Activities are specified at five levels of competency:
196 Technician
197 Entry Level Practitioner
198 Practitioner
199 Technical Leader
200 Senior Software Engineer
201 In general, a Technician follows instructions, an Entry Level Practitioner assists in performance
202 of an activity or performs an activity with supervision; a Practitioner performs activities with
203 little or no supervision; a Technical Leader leads individuals and teams in the performance of
204 activities; and a Senior Software Engineer modifies existing methods and tools, and creates new
205 ones. Some organizations may choose to merge the Technician and Entry Level Practitioner
SWECOM 11 IEEE 2014

206 levels. A Senior Software Engineer may serve as a chief engineer for a software organization
207 and some Senior Software Engineers may be recognized as industry experts who contribute to
208 shaping and advancing the profession of software engineering.
209 In addition to the activities specified at the various competency levels, an additional competency
210 of all software engineers is to instruct and mentor others, as appropriate, in the methods, tools,
211 and techniques used to accomplish those activities. For example, a Technician or Entry Level
212 Practitioner might instruct or mentor others on the use of configuration management tools as
213 need to perform their activities, or a Team Leader might instruct or mentor a Practitioner on how
214 to lead inspections and reviews.
215 The following notations are also used in SWECOM:
216 Follows (F),
217 Assists (A),
218 Participates (P),
219 Leads (L), and
220 Creates (C).
221 For the requirements prototyping activity cited above, a Technician would be competent to use
222 software tools while following instructions to create prototypes. An Entry Level Practitioner
223 would be competent to assist in creating prototypes and to develop prototypes under supervision;
224 a Practitioner would create prototypes and interact with customers and users in evaluating the
225 prototypes; a Technical Leader would supervise and lead prototyping activities, and a Senior
226 Software Engineer would create new approaches to prototyping.
227 There may be situations where an Entry Level Practitioner might be competent, for example, to
228 lead a prototyping activity, or a Technical Leader might be competent to create a new approach
229 to prototyping, so notations are used in SWECOM to distinguish specific competencies from the
230 named competency levels when it is appropriate.
231 A Practitioner, for example, might be competent to either participate in an activity (P) or lead the
232 activity (L), depending on the scope and complexity of the work to be accomplished. In this case,
233 the activity is labeled (P/L) at the Practitioner level. Similarly, an Entry Level Practitioner might
234 be competent to assist or fully participate in an activity, which would be labeled (A/P).
235 SWECOM does not prescribe the knowledge level or years of experience associated with these
236 competency levels; however, the following general guidelines are typical:
237 An individual who is competent at the Technician level to perform the activities in one or more
238 skills or skill areas might have some advanced education (e.g., a two-year US associates degree
239 or equivalent), one or more industrial certifications, and any number of years of experience.
SWECOM 12 IEEE 2014

240 An individual who is competent as an Entry Level Practitioner to perform the activities in one or
241 more skills or skill areas would probably have requisite knowledge equivalent2 to that provided
242 by an ABET-accredited software engineering degree program or equivalent and zero to four or
243 five years of relevant experience.3
244 An individual who is competent at the Practitioner level to perform the activities in one or more
245 skills or skill areas would probably have knowledge equivalent to or greater than that of an Entry
246 Level Practitioner, might have a masters degree in software engineering or a related discipline,
247 and would probably have more than five years of experience in the relevant skill areas.
248 An individual who is competent as a Technical Leader for one or more SWECOM activities,
249 skills, or skill areas would likely have relevant knowledge and experience equal to or greater
250 than that of a Practitioner plus the behavioral attributes and skills needed to be an effective
251 technical leader.
252 A Senior Software Engineer is an individual who is competent to develop policies, procedures,
253 and guidelines for the technical processes and work products within an organizational unit that is
254 engaged in software engineering.
255 These characterizations of education and experience are examples and are not to be interpreted as
256 prescriptive requirements.
257 Some activities may not have corresponding lower level activities. For example, conducting an
258 impact analysis to determine the effect of modifying or adding requirements for product security
259 or performance might be a Practitioner skill and not an activity that a person at a lower level of
260 competency would be competent to perform.
261 An individual may be at different levels of competency for different skill areas, skills within skill
262 areas, and activities within skills, depending on educational background, work experiences, and
263 aptitude. The SWECOM activities, skills, and skill areas are presented as a framework that can
264 be tailored to fit the needs of individual organizations, programs, and projects. Some
265 organizations may choose to use SWECOM in a prescriptive manner by requiring software
266 engineers who are competent in a skill area at a given competency level to be competent in all of
267 the skills and activities in that skill area at that level and at all lower levels. Other organizations,
268 programs, and projects may use SWECOM to pick and choose activities, skills, and skill areas
269 needed for particular missions, programs, or projects.
270 An example from the matrix of activity competency levels for the skill of requirements
271 management in the software requirements skill area illustrates the approach taken in subsequent
272 sections of this competency model; see Table 6. In general, these notations correspond to the five
273 levels of competency. In some cases an individual at a lower level of skill competency may be
2
Knowledge equivalence might be gained by a combination of education, mentoring, training, and on-the-job
experience.
3
Relevant experience is the experience needed to acquire ability, at a given level of competency, for a SWECOM
skill area, skill, or activity.
SWECOM 13 IEEE 2014

274 competent to perform particular activities, but not all, at a higher level. For example, an Entry
275 Level Practitioner may be competent to perform traceability analysis (P), or a Practitioner may
276 be competent to lead certain activities (L).
277 Table 6. Illustrating Competency Levels for Software Requirements Management Work
278 Activities
Skill Area: Software Requirements
Skill: Requirements Management
Competency Technician Entry Level Practitioner Team Leader Senior Software
Levels Practitioner Engineer
Activities 1. Follows 1. Assists 1. Implements 1. Prepares 1. Modifies
defined requirements requirements requirement existing and
procedures to management management management creates new
support through the plans for plans for guidelines,
requirements use of projects (P/L) projects (L) templates, tools,
management appropriate and techniques
(F) tools (A) for requirement
management (C)
279
280 Note that in some cases (as in Practitioner in Table 6) an individual may be competent to
281 participate in or, in other cases, to lead a work activity such as implementing a requirements
282 management plan. Participating versus leading may depend on the size, scope, and complexity of
283 the project and product. In this case the notation is (P/L).
284 6.EmployerandIndividualGapAnalysis
285 Appendix D includes two worksheets similar to those in the Department of Labor Information
286 Technology Competency Model cited above [INFOCOMP 2012]. The first spreadsheet
287 (SWECOM Staffing Gap Analysis Worksheet) is for use by managers, human resources
288 personnel, and others who analyze available and needed skills within an organizational unit.
289 The second spreadsheet (SWECOM Individual Gap Analysis) is for use by an individual who
290 desires to assess his or her levels of competency for different skills and activities at different
291 competency levels. An individual can use the spreadsheet for self-assessment, or an individual
292 and a manager can use it as a basis for developing a plan of improvement; the improvement plan
293 might include future work assignments, mentoring, and/or additional education and training.
SWECOM 14 IEEE 2014

294 7.SWECOMValidation
295 SWECOM has been validated by 22 subject matter reviewers, and by XX public reviewers.
296 Many narrative review comments were received from the subject matter reviewers (SMEs) and
297 YY targeted comments were received from public reviewers. The SWECOM author team
298 adjudicated all comments and informed reviewers of their decisions.
299 Members of the SWECOM team interviewed six software engineering professionals. The
300 purpose of the interviews was to determine the value of a software engineering competency
301 model and the relevancy and usefulness of various SWECOM elements (e.g., cognitive
302 attributes, behavioral attributes and skills, skill areas, competency levels, etc.). The purpose of
303 the interviews was for the SWECOM developers to conduct a sanity check on SWECOM,
304 before releasing a draft for external review.
305 The interview results can be summarized as follows:
306 All those interviewed had degrees in computing related disciplines and 12 to 29 years of
307 experience in the software industry, and were serving in mid-level to high-level positions in
308 their organizations (e.g., system architect, quality assurance director, software development
309 manager, technical support manager, software development director).
310 There was unanimous agreement that SWECOM will provide valuable support for recruiting,
311 evaluating, developing, and advancing software engineering professionals.
312 Most interviewees voiced the opinion that nontechnical competencies were essential to the
313 success of a software engineering professional: good people skills, ability to communicate,
314 working in teams, working with customers, learning new things, flexibility, and the ability to
315 work with people from different cultures. As a result of the last observation, the SWECOM
316 developers added a behavioral attribute of Cultural Sensitivity.
317 Most of those interviewed thought five or six levels of competency were appropriate.
318 However, none of those interviewed who have used other competency models used the
319 equivalent of the Technician Level.
320 Some expressed the view that no degree or minimum years of experience should be specified
321 for the competency levels. SWECOM only describes typical backgrounds, and no
322 requirements or precise expectations are stated.
323 There were no recommendations for major changes to SWECOM.
324 These six interviews did not provide a statistically significant sample of opinions but they did
325 provide an indication that the SWECOM effort is well conceived. The SME and public review
326 comments provided many valuable recommendations but none invalidated the SWECOM
327 concept.
328 NOTE to public reviewers: the sentence above will be modified, if necessary, based on your
329 reviews.
SWECOM 15 IEEE 2014

330 The following sections of this document specify the life cycle and crosscutting skill areas and the
331 skills and activities at various competency levels within each skill area. Each skill area includes
332 two tables: Table A lists skills and corresponding activities for the skill area, and Table B lists
333 the activities across the five competency levels.
334 8.Acknowledgements
335 Appendix A lists the individuals who developed this competency model, the subject matter
336 expert reviewers, the public reviewers, and those who were interviewed.
337 9.References
338 [Abran 2010] Alain Abran, Software Metrics and Software Metrology, Wiley-IEEE Computer
339 Society Press, 2010.
340 [ACM 2004] ACM/IEEE-CS Joint Task Force on Computing Curricula, Software Engineering
341 2004, Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering,
342 Aug. 2004; www.acm.org/education/curricula.html.
343 [Aiello 2010] Bob Aielloand Leslie Sach, Configuration Management Best Practices: Practical
344 Methods that Work in the Real World, Addison-Wesley Professional, 2010.
345 [Allen 2008] Julia Allen et al., Software Security Engineering: A Guide for Project Managers,
346 Addison-Wesley Professional, 2008.
347 [Babich 1986] Wayne A. Babich, Software Configuration Management: Coordination for Team
348 Productivity, Addison-Wesley, 1986.
349 [BITS 2012] BITS Software Assurance Framework, Financial Services Roundtable, 2012;
350 www.bits.org/publications/security/BITSSoftwareAssurance0112.pdf.
351 [Bozzano 2010] Marco Bozzano and Adolfo Villafiorita, Design and Safety Assessment of
352 Critical Systems, CRC Press, 2010.
353 [Buxton 2007] Bill Buxton, Sketching User Experiences: Getting the Design Right and the Right
354 Design, Morgan Kaufmann Publishers, 2007.
355 [CMMI 2014] Capability Maturity Model Integrated, CMMI Institute, 2014;
356 http://cmmiinstitute.com.
357 [Fowler 1999] M. Fowler et al., Refactoring: Improving the Design of Existing Code, Addison-
358 Wesley, 1999.
359 [Hilburn 2013] Thomas Hilburn et al., Software Assurance Competency Model, Technical Note
360 CMU/SEI-2013-TN-004, Software Engineering Institute, Mar. 2013;
361 http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=47953.
362 [Hunt 1999] A. Hunt and D. Thomas, The Pragmatic Programmer: From Journeyman to
363 Master, Addison-Wesley, 1999.
SWECOM 16 IEEE 2014

364 [IEEE 730-2002] IEEE Std. 730-2002, IEEE Standard for Software Quality Assurance Plans,
365 IEEE, 2002.
366 [IEEE 828-2012] IEEE Std. 828-2012, IEEE Standard for Configuration Management in
367 Systems and Software Engineering, IEEE, 2012.
368 [IEEE 829-2008] IEEE Std. 829-2008, IEEE Standard for Software and System Test
369 Documentation, IEEE, 2008.
370 [IEEE 1012-2012] IEEE Std. 1012-2012, IEEE Standard for System and Software Verification
371 and Validation, IEEE, 2012.
372 [IEEE 1016-2009] IEEE Std. 1016-2009, IEEE Standard for Information Technology-Systems
373 DesignSoftware Design Descriptions, IEEE, 2009.
374 [IEEE 12207-2008] IEEE Std. 12207-2008, IEEE Standard for Systems and Software
375 EngineeringSoftware Life Cycle Processes, IEEE, 2008.
377 EngineeringSystem Life Cycle Processes, IEEE, 2008.
378 [IEEE 15939-2008] IEEE Std. 15939-2008, Standard Adoption of ISO/IEC 15939:2007 System
379 and Software Engineering Measurement Process, IEEE, 2008.
380 [IEEE/ISO/IEC 24765-2010] IEEE/ISO/IEC 24765:2010 Systems and Software Engineering
381 Vocabulary, IEEE, 2010.
382 [INFOCOMP 2012] Information Technology Competency Model, Employment and Training
383 Administration, United States Department of Labor, Sep. 2012;
384 http://www.careeronestop.org/competencymodel/pyramid_download.aspx?IT=Y.
385 [ISO 9241-210:2010] ISO 9241-210:2010, Ergonomics of Human-System Interaction, ISO,
386 2010.
387 [ISO/IEC 25060:2010] ISO/IEC 25060:2010, Systems and Software EngineeringSystems and
388 Software Product Quality Requirements and Evaluation (SQuaRE)Common Industry Format
389 (CIF) for Usability: General Framework for Usability-Related Information, ISO, 2010.
390 [ISO/IEC/IEEE 15289:2011] ISO/IEC/IEEE 15289:2011, Systems and Software Engineering
391 Content of Life-Cycle Information Products (Documentation), ISO, 2011.
392 [Kan 2002] Stephen H. Kan, Metrics and Models in Software Quality Engineering, 2nd ed.,
393 Addison-Wesley, 2002.
394 [Lams 2009] Alex van Lamsweerde, Requirements Engineering: From System Goals to UML
395 Models to Software Specifications, John Wiley and Sons, Inc., 2009.
396 [Lapham 2006] M. Lapham and C. Woody, Sustaining Software-Intensive Systems, CMU/SEI-
397 2006-TN-007, Software Engineering Institute, 2006; http://resources.sei.cmu.edu/library/asset-
398 view.cfm?assetID=7865.
399 [Laplante 2009] Phillip A. Laplante, Requirements Engineering for Software and Systems, 2nd
400 ed., CRC Press, 2009.
SWECOM 17 IEEE 2014

401 [Laplante 2013] Phillip A. Laplante, Beth Kalinowski, and Mitchell Thornton, A Principles and
402 Practices Exam Specification to Support Software Engineering Licensure in the United States of
403 America, Software Quality Professional, vol. 15, no. 1, Jan. 2013, pp. 4-15.
404 [Leveson 1995] N. Leveson, Safeware: System Safety and Computers, Addison-Wesley, 1995.
405 [Leveson 2011] N. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety,
406 The MIT Press, 2011.
407 [McConnell 2004] S. McConnell, Code Complete, 2nd ed., Microsoft Press, 2004.
408 [Merkow 2010] M. Merkow and L. Raghavan, Secure and Resilient Software Development, CRC
409 Press, 2010.
410 [Myers 2011] Glenford J. Myers, The Art of Software Testing, 3rd ed., Wiley, 2011.
411 [PMBOK 2013] Project Management Institute, A Guide to the Project Management Body of
412 Knowledge (PMBOK Guide), 5th ed., Project Management Institute, 2013.
413 [Pohl 2010] Klaus Pohl, Requirements Engineering: Fundamentals, Principles, and Techniques,
414 Springer-Verlag, 2010.
415 [Rierson 2013] Leanna Rierson, Developing Safety-Critical Software: A Practical Guide for
416 Aviation Software and DO-178C Compliance, CRC Press, 2013.
417 [Robertson 2012] Suzanne Robertson and James C. Robertson, Mastering the Requirements
418 Process: Getting Requirements Right, 3rd ed., Addison-Wesley Professional, 2012.
419 [Rogers 2011] Y. Rogers, H. Sharp, and J. Preece, Interaction Design: Beyond Human Computer
420 Interaction, 3rd ed., Wiley, 2011.
421 [RTCA DO-178C] RTCA, Inc., Software Considerations in Airborne Systems and Equipment
422 Certification, DO-178C/ED-12C, 13 Dec. 2011.
423 [Seacord 2005] R. Seacord, Secure Coding in C and C++, Addison-Wesley, 2005.
424 [SEBoK 2013] A. Pyster and D.H. Olwell, eds., The Guide to the Systems Engineering Body of
425 Knowledge (SEBoK), v. 1.2, The Trustees of the Stevens Institute of Technology, 2013;
426 http://sebokwiki.org.
427 [Stephans 2004] R.A. Stephans, System Safety for the 21st Century: The Updated and Revised
428 Edition of System Safety 2000, Wiley, 2004.
429 [SWEBOK 2014] P. Bourque and R.E. Fairley, eds., Guide to the Software Engineering Body of
430 Knowledge, Version 3.0, IEEE Computer Society Press, 2014; www.swebok.org.
431 [SWX 2013] Project Management Institute and IEEE Computer Society, Software Extension to
432 the PMBOK Guide Fifth Edition, Project Management Institute, 2013.
433 [Vincoli 2006] J.W. Vincoli, Basic Guide to System Safety, Wiley, 2006.
434 [Westfall 2009] Linda Westfall, The Certified Software Quality Engineering Handbook, Quality
435 Press, 2009.
436 [Wiegers 2013] Karl E. Wiegers and Joy Beatty, Software Requirements, 3rd ed., Microsoft
437 Press, 2013.
438
SWECOM 18 IEEE 2014
439 10.GlossaryofTerms
440 This Glossary of Terms provides definitions of terms whose meanings, as used in SWECOM,
441 may differ from conventional meanings. Other terms used in SWECOM are intended to convey
442 the meanings in IEEE/ISO/IEC Standard 24765:2010, Systems and Software Engineering
443 Vocabulary, IEEE, 2010 (SEVOCAB). The Guide to the Software Engineering Body of
444 Knowledge [SWEBOK 2014] also provides detailed discussions of many of the terms used in
445 SWECOM.
446 Terms italicized in the definitions of other terms are also defined in this Glossary.
447 Activity: a self-contained unit of work to be performed. Activities are the smallest units of
448 technical skills in SWECOM.
449 Behavioral Attribute: a characteristic of personality and character that enables an individual to
450 apply knowledge, experience, and cognitive attributes to perform activities in a productive
451 manner within the work environment.
452 Cognitive Skill: a characteristic of intellect that allows an individual to apply knowledge and
453 reasoning ability while performing activities within technical skill areas.
454 Competency: the demonstrated ability to perform work activities at a stated competency level.
455 Competency Level: one of five increasing levels of ability to perform an activity; denoted as
456 Technician, Entry Level Practitioner, Practitioner, Technical Leader, or Senior Software
457 Engineer.
458 Entry Level Practitioner: an individual who is competent to assist in performing an activity or to
459 perform activities with some supervision.
460 Fuzz Testing (i.e., fuzzing): an automated black box testing technique for software that involves
461 providing invalid, unexpected, or random data as inputs to a computer program.
462 Gap Analysis: the process of specifying the competencies an individual or an organization has,
463 competencies needed, and the gaps between have and needed.
464 Senior Software Engineer: an individual who is competent to create newand modify existing
465 processes, procedures, methods, and tools for performing activities, groups of activities within
466 skills, and skills within skill areas.
467 Practitioner: an individual who is competent to perform an activity with little or no supervision.
468 Skill: a grouping of logically related activities.
469 Skill Area: a grouping of logically related skills.
470 Technical Leader: an individual who is competent to lead and direct participants in the
471 performance of activities in a skill or skill area.
SWECOM 19 IEEE 2014

472 Technician: an individual who is competent to follow instructions while performing an activity.
473 Usability Test: a test case that states what the user needs to do but does not tell the user how to
474 perform the test. It measures the user interfaces ability to support user behavior.
475
SWECOM 20 IEEE 2014

476 11.SoftwareRequirementsEngineeringSkillArea
477
478 Software requirements engineering consists of activities performed to discover what functional
479 and nonfunctional attributes and interfaces a software system should have to satisfy the needs of
480 the customer. It also includes analysis and management activities performed in order to discover
481 flaws in requirements artifacts and to manage the requirements engineering process.
482 References
485 Aug. 2004; www.acm.org/education/curricula.html.
486 [Laplante 2009] Phillip A. Laplante, Requirements Engineering for Software and Systems, 2nd
487 ed., CRC Press, 2009.
488 [Robertson 2012] Suzanne Robertson and James C. Robertson, Mastering the Requirements
489 Process: Getting Requirements Right, 3rd ed., Addison-Wesley Professional, 2012.
492 [Wiegers 2013] Karl E. Wiegers and Joy Beatty, Software Requirements, 3rd ed., Microsoft
493 Press, 2013.
Table A11
Software Requirements Engineering Software Requirements Engineering Activities
Skill Sets
Software Requirements Elicitation Identifies stakeholders for elicitation of requirements
Engages stakeholders in elicitation of requirements
Uses appropriate methods to capture requirements
Negotiates conflicts among stakeholders during elicitation
Software Requirements Analysis Uses appropriate domain analysis techniques.
Performs analysis of requirements for feasibility and emergent
properties.
Software Requirements Specification Uses appropriate notations for describing requirements.
Software Requirements Verification Checks requirements for accuracy, lack of ambiguity, completeness,
and Validation consistency, traceability and other desired attributes.
Constructs and analyzes prototypes
Negotiates conflicts among stakeholders during verification
Software Requirements Process and Uses appropriate methods for management of requirements, including
Product Management configuration management
494
495
SWECOM 21 IEEE 2014

496 The following notations are used in table B11: Follow (F), Assist (A), Perform (P), Lead (L), Create (C).
Table B11
SSE Competency Software Requirements Engineering Skills Matrix
Levels Senior Software
Technician Entry Level Practitioner Technical Leader
Skill Sets Engineer
Software 1. Identifies
Requirements important
Elicitation stakeholders (P/L)
1. Assists in 2. Engages different
engaging stakeholders in
different determining needs
stakeholders in and requirements
determining (P)
needs and
requirements (A)
3. Applies different
methods as
appropriate to the
project to elicit
requirements (P)
1. Assists 2. Assists in 4. Assists in 1. Selects 1. Creates new
requirements applying negotiating conflicts appropriate ways to engage and
engineers with different between methods to engage communicate with
preparation of methods as stakeholders in and communicate stakeholders,
surveys and appropriate to requirements with stakeholders management team
other elicitation the project to elicitation (A) in requirements and developers in
instruments elicit activities (L) requirements
(F/A) requirements (A) activities (C)
2. Negotiates
conflicts between
stakeholders in
requirements
elicitation (P/L)
Software 1. Assists in 1. Selects the most 1. Leads 1. Creates new
Requirements domain analysis appropriate domain identification of domain analysis
Analysis (A) analysis methods emergent methods (C)
(P/L) properties and
requirements
throughout the
software
development
lifecycle (P)
SWECOM 22 IEEE 2014

Table B11
Skill Sets Engineer
2. Identifies
emergent properties
and requirements
throughout the
software
development
lifecycle (P)
Software 1. Assists with 1. Prepares 1. Selects the most 1. Leads 1. Creates new
Requirements preparation of requirements appropriate formal development of the requirements
Specification requirements for documentation and informal SRS (L) specification
consistency with including notations for methods (C)
internal and descriptions of describing interfaces
published interfaces and and functional and
standards (F/A) functional and nonfunctional
nonfunctional requirements (P/L)
requirements (P)
2. Selects the most
appropriate formal
and informal
notations for
describing
interfaces and
functional and
nonfunctional
requirements (L)
Software 1. Reviews 1. Reviews 1. Selects the most 1. Creates new
Requirements specifications of specifications of appropriate formal requirements
Verification requirements for requirements for and informal validation and
and errors and errors and omissions requirements verification
Validation omissions (P) (L) validation and techniques (C)
verification
techniques (L)
2. Assists in 2. Creates
prototype prototypes of
construction and different types as
testing (F/A) needed (P)
3. Assists in 2. Negotiates
negotiating conflicts conflicts between
between stakeholders in
stakeholders in requirements
SWECOM 23 IEEE 2014

Table B11
Skill Sets Engineer
requirements verification (P/L)

verification (A)
Software 1. Follows and 1. Assists in 1. Performs tradeoff 1. Sets strategy and
Requirements applies defined applying defined analysis of direction for the
Process processes for processes for requirements requirements
Management requirements requirements activities (P/L) process across
engineering with engineering (A) projects and
guidance (F/A) functional units of
an organization (L)
497
498
SWECOM 24 IEEE 2014

499 12.SoftwareDesignSkillArea
500 Software design skills are used to develop and describe the software architecture of a system
501 based on the software requirements: this consists of a description of how software is decomposed
502 into components and the interfaces between those components. The components are specified at
503 a level of detail that enables their construction. This skill area also includes skills related to
504 processes and techniques for software design quality, analysis, and evaluation.
505 References
506 [IEEE 1016-2009] IEEE Std. 1016-2009, IEEE Standard for Information Technology-Systems
507 DesignSoftware Design Descriptions, IEEE, 2009.
Table A12
Software Design Skill Sets Software Design Activities
Software Design Fundamentals Employ enabling techniques (e.g., abstraction, coupling/cohesion,
information hiding, etc.) in software design.
Apply exception handling and fault tolerance techniques in software
design.
Use restructuring and refactoring methods in software design.
Apply, as appropriate, design techniques in the areas of concurrency,
event handling, data persistence, or distributed software.
Software Design Strategies and Determine the process and strategy to be used in software design
Methods (e.g., top-down or bottom-up, stepwise refinement, use of patterns
and pattern languages, iterative and incremental processes, etc.).
Select and apply the appropriate design methodology (e.g., a
structural or an object-oriented approach)
Consider design alternatives and perform trade-off analysis
Manage software design activities.
Software Architectural Design Use architectural styles, views, models, and architectural patterns to
specify the high-level organization of a software system
Specify the component interfaces
Design software components and modules using models, design
patterns, notations, and diagramming techniques.
Software Design Quality Analysis and Utilize software design reviews.
Evaluation Perform static analysis tasks to evaluate design quality.
Develop and use simulation and prototypes to evaluate software
design quality.
Manage requirements change.
514
SWECOM 25 IEEE 2014

516 Table B12

Software Design Skill Sets and Activities by Competency Level
Skill Sets Engineer
Software 1. Assists 1. Assists in the 1. Applies enabling 1. Evaluates the 1. Analyzes and
Design software application of techniques (e.g., effectiveness of the makes
Fundamentals designers with enabling abstraction, application of recommendations
tools and techniques in the coupling/cohesion, software design related to
techniques for design of information hiding, enabling organization-wide
gathering software etc.) to the design of techniques. (P/L) application of
information components and software software design
about application modules. (A) components and fundamentals. (M)
and use of modules. (P)
software design
fundamentals.
(F/A)
2. Assists in the 2. As appropriate in 2. Provides
application of the domain of direction and
design application, applies advice on methods
techniques in the appropriate design and techniques to
areas of techniques in the be used in the areas
concurrency, areas of of concurrency,
event handling, concurrency, event event handling, or
data persistence, handling, data distributed
or distributed persistence, or software. (L)
software. (A) distributed software.
(P)
3. Assists in the 3. Applies exception
application of handling and fault
exception tolerance techniques
handling and in the design of
fault tolerance software
techniques in the components and
design of modules. (P)
software
components and
modules. (A)
4. Assists in the 4. Uses restructuring
use of and refactoring
restructuring and methods in the
refactoring design of software
methods in the components and
design of modules. (P)
SWECOM 26 IEEE 2014

Skill Sets Engineer
software
components and
modules. (A)
Software 1. Provides 1. Assists in the 1. Applies the 1. Determines the 1. Examines and
Design assistance in the application of the designated software process and assesses the
Strategies and installation and designated design strategy and strategy to be used effectiveness,
Methods use of tools software design methodology to in software design, across an
appropriate for a strategy and create a software at the project level organization, of the
projects methodology to design (e.g., an (e.g., top-down or application of
designated create a software incremental object- bottom-up, software design
design strategy design (e.g., an oriented approach). stepwise strategies and
and incremental (P) refinement, , use of methods. (M)
methodology object-oriented patterns and pattern
(e.g., an approach). (A/P) languages, iterative
incremental and incremental
object-oriented processes, etc.) (L)
approach) (F/A)
2. Selects the 2. Analyzes and
appropriate design makes
methodology (e.g., recommendations
object-oriented, related to
function-oriented, organization-wide
component-based) software design
and strategies to be strategies and
used at the project methodologies.
level. (L) (M)
3. Provides
guidance and
advice on the use
of software design
strategies and
methods. (L)
4. Evaluates the 2. Creates new
effectiveness of the techniques
application of the evaluating software
selected software design quality. (M)
design
methodology. (P/L)
2. Determines
design alternatives
and performs trade-
SWECOM 27 IEEE 2014

Skill Sets Engineer
off analysis.
Software 1. Provides 1. Assists in 1. Applies standard 1. Provides 1. Analyzes and
Architectural assistance in the architectural notations, direction and makes
Design installation and design tasks diagramming advice on standard recommendations
use of software associated with techniques, models, notations, related to
architecture use of standard and patterns (e.g., diagramming organization-wide
tools. (F/A) notations, architectural styles, techniques, models software
diagramming structural and and patterns to be architectural
techniques, behavioral models, applied. (L) design. (M)
models and GoF patterns
patterns. (A) Structured Systems
Design models, and
UML)to model the
high-level
organization of a
software system.
(P/L)
2. Applies a 2. Creates multiple 2. Evaluates the 2. Determines new
selected software views of the effectiveness of the methods and
design pattern to software system. creation of techniques to be
the design of a (P/L) software used in
software architecture. (P/L) architectural
component or design. (M)
module. (A/P)
3. Uses design
patterns and
frameworks to
design mid-level
software
components or
modules. (P)
Software 1. Assists 1. Participates in 1. Facilitates 1. Selects the 1. Analyzes and
Design software software design software design appropriate tools makes
Quality designers with reviews. (P) reviews (P/L) and techniques recommendations
Analysis and tools and (e.g., design related to
Evaluation techniques for reviews, static organization-wide
collecting design analysis, design quality
metrics and simulation and evaluation and
evaluating prototyping, design analysis
software design metrics) to ensure a techniques. (M)
quality. (F/A) software designs
quality. (L)
SWECOM 28 IEEE 2014

Skill Sets Engineer
2. Carries out 2. Leads static

static analysis analysis tasks to
tasks to evaluate evaluate design
design quality. quality. (P/L)
(P)
3. Assists in 3. Develops and
development and uses simulation and
use of simulation prototypes to
and prototypes to evaluate software
evaluate design quality. (P)
software design
quality. (A)
2. Uses the results 2. Creates new
of software design techniques for
quality evaluation evaluating software
activities to assess design quality. (M)
the quality of the
design, and to
decide on
corrective action, if
needed. (P/L)
3. Provides
guidance and
direction related to
the need for
requirements
change resulting
from design
review. (P/L)
517
518
SWECOM 29 IEEE 2014

519 13.SoftwareConstructionSkillArea
520
521 Software construction is the collection of activities and processes for implementing software
522 solutions to meet customer needs. It includes planning, designing, programming, debugging,
523 testing and integrating software components. Most software construction is performed by teams
524 of professionals using tools and processes to accomplish and coordinate their work.
525 References
528 August 2004; www.acm.org/education/curricula.html.
529 [Fowler 1999] M. Fowler et al., Refactoring: Improving the Design of Existing Code, Addison-
530 Wesley, 1999.
531 [Hunt 1999] A. Hunt and D. Thomas, The Pragmatic Programmer: From Journeyman to
532 Master, Addison-Wesley, 1999.
533 [McConnell 2004] S. McConnell, Code Complete, 2nd ed., Microsoft Press, 2004.
Table A13
Software Construction Skill Sets Software Construction Activities
Software Construction Planning Select appropriate processes and models for constructing software,
including appropriate reuse processes
Select appropriate languages and tools for software construction
Select appropriate frameworks, platforms and environments
Managing Software Construction Establish and follow project standards for version control and
configuration management
Collect and monitor standard measures of code quality and size
Detailed Design and Coding Create detailed designs that minimize complexity and enhance quality
Create code to implement detailed designs
Refactor code when needed
Establish and follow standards for designs and code
Use appropriate design patterns
Use defensive coding techniques to minimize propagation of errors
and threats
Documents code through comments to support software maintenance
Debugging and Testing Use appropriate tools and techniques for debugging
Create and execute unit tests for all delivered code
Achieve test coverage goals
Integrating and Collaborating Establish and follow integration strategy and processes
SWECOM 30 IEEE 2014

Perform integration testing as part of integration process
Collaborate with other team members in development activities (e.g.,
pair programming, informal reviews)
Participate or lead reviews and inspections
536
537
SWECOM 31 IEEE 2014

Table B13
Software Construction Skill Sets and Activities by Competency Level
Skill Sets Engineer
Software 1. Assists in the 1. Selects 1. Creates or

Construction selection of appropriate proposes new
Planning appropriate processes and processes and
processes and models for models for
models for software constructing software
construction (F/P) software on construction (C)
individual projects
(e.g., compilation,
generation from
domain specific
languages) (L)
2. Assists in the 2. Creates new
selection of languages and tools
appropriate for software
languages and tools construction (C)
for software
construction (F/P)
3. Assists in the 2. Selects 3. Creates or
selection of appropriate proposes new
appropriate languages and tools frameworks,
frameworks, for software platforms and
platforms and construction on environments (C)
environments for individual projects
software (L)
construction (F/P)
3. Selects
appropriate
frameworks,
platforms and
environments for
individual projects
(L)
Managing 1. Assists in the 1. Uses standard 1. Monitors standard 1. Establishes 1. Establishes
Software installation of tools and measures of code project standards organization
Construction tools and processes for quality and size (P) for version control standards for
repositories for version control and configuration version control and
version control and management (L) configuration
and configuration management (L)
configuration
SWECOM 32 IEEE 2014

Table B13
Skill Sets Engineer
management (A) management (P)

2. Collects 2. Sets organization
standard standards for code
measures of code quality and size (L)
quality and size
(P)
3. Creates new
tools and processes
for version control
and configuration
management (C)
Detailed 1. Assists in the 1. Creates code 1. Creates and 1. Measures and 1. Establishes
Design and installation of to implement reviews detailed monitors organization
Coding tools and detailed designs designs that organization's use standards for
repositories for (P) minimize of design patterns detailed designs
design and complexity (P) (L) and code (L)
coding (A)
2. Refactors code 2. Suggests and 2. Creates new

when needed (P) performs design patterns (C)
appropriate code
refactoring when
needed (L)
3. Follows 3. Selects or
project and establishes project
organization standards for
standards for designs and code (P)
designs and code
(F)
4. Uses 4. Suggests and uses
appropriate appropriate design
design patterns patterns (L)
(P)
5. Uses 5. Suggests and uses
defensive coding defensive coding
techniques to techniques to
minimize minimize
propagation of propagation of
SWECOM 33 IEEE 2014

Table B13
Skill Sets Engineer
errors and threats errors and threats

(P) (L)
6. Documents
code through
comments to
support software
maintenance (P)
Debugging 1. Assists in the 1. Uses 1. Ensures project 1. Establishes 1. Establishes
and Testing installation of appropriate tools standards for unit project standards organization
tools for and techniques test coverage are for unit test standards for unit
debugging and for debugging followed (P) coverage (L) testing (L)
testing (A) (P)
2. Creates and 2. Selects 2. Creates new unit
executes unit appropriate testing tools and
tests for all debugging tools methods (C)
delivered code and techniques for
(P) a project (L)
3. Achieves test
coverage goals
set by project
and organization
standards (P)
Integration 1. Assists in 1. Follows 1. Leads code 1. Assists in 1. Establishes
and installation of project reviews and selection of project organization
Collaboration integration tools integration inspections (L) tools and processes standards for
(A) strategy and for integration (P) integration tools
processes (P) and processes (L)
2. Assists in 2. Performs 2. Establishes
creation of code integration organization
inspection testing as part of standards for
packages (A) integration reviews and
process (P) inspections (L)
3. Assists in 3. Collaborates 3. Creates new
scheduling of with other team integration tools
code inspections members in and processes (C)
(A) development
activities (e.g.,
pair
programming,
SWECOM 34 IEEE 2014

Table B13
Skill Sets Engineer
informal
reviews) (P)
4. Participates in 4. Creates new
project defined code review and
reviews and inspection methods
inspections (P) (C)
539
SWECOM 35 IEEE 2014

540 14.SoftwareTestingSkillArea
541 Software testing is a component of overall software quality; however, the Software Quality skill
542 area in SWEBOK is a cross cutting skill area, whereas the Software Testing skill area is life
543 cycle phase skill area. Software testing includes all activities that are performed to evaluate
544 overall product quality, which requires code execution. This software testing skill area, covers
545 dynamic verification, and is concerned with selecting an appropriate set of test cases that
546 demonstrate the expected behavior of the product by executing the software using prepared test
547 cases and using the results to analyze and improve the quality of the product. It is well known
548 that software cannot be tested exhaustively for all possible situations; therefore, selecting
549 appropriate set of test cases has a major effect on the success or failure of testing activities.
550 References
552 IEEE, 2002.
553 [IEEE 829-1998] IEEE Std. 829-1998, IEEE Standard for Software Test Documentation, IEEE,
554 1998.
559 [Myers 2011] Glenford J. Myers, The Art of Software Testing, 3rd ed., Wiley, 2011.
Table A14
Software Testing Skill Sets Software Testing Activities
Software Testing Planning Identify all stakeholders involved in software testing
Identify success and failure criteria
Identify test completion criteria
Design and implement the software test plan
Identify and coordinate customer representatives and other
stakeholders participating in the software acceptance and/or
demonstration
Software Testing Infrastructure Identify tools to be used throughout testing activities
Identify appropriate documentation to be generated and archived
Design/select and implement the test environment
Software Testing Techniques Identify test objectives
Select appropriate testing/demonstration techniques
Design, implement, and execute test cases
Software Testing Measurement & Identify, collect, and store appropriate data resulting from
Defect Tracking testing/demonstration
SWECOM 36 IEEE 2014

Report test results to appropriate stakeholders
Identify, assign and perform the necessary corrective actions
Analyze test data for test coverage, test effectiveness and process
improvement
560
561 NOTE: Throughout industry a large number of testing techniques have been and are used.
562 Whenever testing techniques are discussed in this skill area it could potentially refer to any of
563 those techniques; in these cases testing is in italics. In a few instances a specific technique is
564 testing is in not in italic font in those cases.
565
566
SWECOM 37 IEEE 2014

568 Table B14

Software Testing Skill Sets and Activities by Competency Level
Skill Sets Engineer
Software 1. Identify unit 1. Identify 1. Establish 1. Establish

Testing and integration stakeholders organizational organizational
Planning testing success participating in procedures for procedures for
and failure demonstration and testing. (P) testing. (L)
criteria (P) testing activities (P)
2. Follow 2. Design and 2. Identify
software test implement a customer
plan (P) software test plan representative and
(P) other stake holders
participating in
acceptance testing
and demonstrations
(L)
3. Establish the 3. Identify success 3. Identify project
criteria for unit and failure criteria test objectives (L)
test execution for testing (L/P)
completion, such
as code
coverage, defect
intensity, etc. (P)
4. Develop unit 4. Develop 4. Identify success
test plan (P) demonstration, or and failure criteria
other test plans. (P) for system and
acceptance testing
(P)
5. Assist with the 5. Establish criteria 5. Identify test
development of for demonstration completion criteria
the test plan readiness (A/P) (P)
6. Select the most
appropriate
demonstration,
testing technique.
(P)
7. Establish the
criteria for test
completion, such as
defect arrival rate,
defect intensity, etc.
SWECOM 38 IEEE 2014

Skill Sets Engineer
(P)
8. Establish criteria
for regression,
testing such as
defect density, etc.
(P/L)
Software 1. Set up the 1. Select 1. Define the 1. Identify testing 1. Identify
Testing necessary test appropriate unit necessary set up for tools and test data organizational
Infrastructure and test techniques testing and warehousing across testing tools and
demonstration demonstration. (P/L) projects (P) data warehousing
environment (P) across project (L)
2. Install the 2. Select the 2. Identify the 2. Create new test
necessary tools most appropriate appropriate documentation
(P) testing tools (P) documentations (i.e., test plan,
necessary for the defect recording,
testing activities (P) etc.) (L/P)
3. Develop the 3. Design and 3. Design the test
appropriate implement the environment (L/P)
infrastructure for test environment
data warehousing (P)
(P)
Software 1. Perform 1. Design and 1. Specify 1. Design System 1. Create new
Testing manual test execute unit test appropriate test test plan and test testing (i.e., unit,
Techniques activities (i.e., cases (P) cases for the cases (L) integration, stress,
data entry, test selected testing etc.) techniques.
case execution, technique (L/P) (C)
etc.) (P)
2. Execute 2. Assist with the 2. Identify
regression development of automated testing
testing. (P) the test cases (P) opportunities (L/P)
3. During 3. Execute
demonstration, integration and
monitor system test cases
customer use, (P)
and record
customer
feedback for
product
improvement (A)
4. Ensure the 4. Execute test
SWECOM 39 IEEE 2014

Skill Sets Engineer
system is ready cases. (L/P)

for
demonstration by
performing
acceptance test
(P/L)
5. Develop
automated test case
scenarios (L/P)
Software 1. Perform all 1. Collect 1. Collect 1. Conduct root 1. Create new root
Testing appropriate data appropriate data appropriate data cause analysis. cause analysis
Measurement warehousing associated with associated with test (L/P) technique (P)
& Defect (gathering test execution (P) execution (L/P)
Tracking execution data,
data entry, data
archiving, etc.)
(P)
2. Generate 2. Evaluate test 2. Conduct root 2. Analyze test data
appropriate execution results cause analysis. (P) to decide on further
report associated and identify testing activities
with appropriate (L)
test/demonstratio rework. (P)
n execution. (P)
3. Collect 3. Monitor test 3. Using the test 3. Use the data to
appropriate data progress by results, assign evaluate test
associated with evaluating defect appropriate rework effectiveness (L)
executing test arrival rate, to team members (P)
cases (P) failure intensity,
etc. (A/P)
4. provide test 4. Use test execution 4. Evaluate test
result report to data and rework results to identify
appropriate results to evaluate appropriate process
stakeholders (P) test effectiveness improvement
and decide for opportunities (P)
additional testing or
regression testing
(P)
5. Monitor test 5. Monitor overall
progress by test progress by
evaluating defect evaluating defect
arrival rate, failure arrival rate, failure
SWECOM 40 IEEE 2014

Skill Sets Engineer
intensity, etc. (P) intensity, etc. (L)
569
570
SWECOM 41 IEEE 2014

571 15.SoftwareSustainmentSkillArea
572 As systems become larger, more complex, and increasingly reliant on software, sustainment
573 issues become increasingly complex and time consuming. A study of software systems effort
574 distribution indicated that 55% of software system life cycle effort involves sustainment
575 activities [CMU/SEI-2006-TN-007]. The risks of inadequate sustainment can potentially
576 undermine the stability, enhancement, and longevity of operational systems.
577 No authoritative definition of software sustainment exists. The Software Engineering
578 Institutes working definition is: The processes, procedures, people, materiel, and information
579 required to support, maintain, and operate the software aspects of a system [Lapham 2006].
580 The IEEE Standard Glossary of Software Engineering Terminology defines software
581 maintenance as: The process of modifying a software system or component after delivery to
582 correct faults, improve performance or other attributes, or adapt to a changed environment
583 [IEEE/ISO/IEC 24765-2010].
584 According to these definitions, software sustainment addresses issues of maintenance plus
585 documentation, deployment, operation, security, configuration management, training (users and
586 sustainment personnel), help desks, COTS product management, technology updates, and
587 software retirement.
588 Software maintenance activities (e.g. corrective, adaptive and perfective activities) involve
589 modifying a software product/system after delivery. A fourth category of software maintenance
590 activities focuses on preventive maintenance.
591 Successful software sustainment depends on the culture of the sustainment organization, the
592 skills of the sustainment team (which is the focus of this skill area), the flexibility of the
593 customer, and the operational domain of the product, in addition to skills needed to modify
594 source code for corrective, adaptive and perfective enhancements.
595 References
598 [IEEE/ISO/IEC 24765-2010] IEEE/ISO/IEC 24765:2010 Systems and Software Engineering
599 Vocabulary, IEEE, 2010.
600 [Lapham 2006] M. Lapham and C. Woody, Sustaining Software-Intensive Systems, CMU/SEI-
601 2006-TN-007, Software Engineering Institute, 2006; http://resources.sei.cmu.edu/library/asset-
602 view.cfm?assetID=7865.
SWECOM 42 IEEE 2014

Table A15
Software Sustainment Software Sustainment Activities
Skill Sets
Software Transition Develops transition plan
Identifies stakeholders for transition and operational requirements
Identifies system and software constraints
Identifies applicable systems and software operational standards
(e.g. Information Assurance)
Develops software transition and operational documentation
Installs software
Performs software operational training (users and sustainment
personnel)
Determines the impacts on the operational environment
Develops software system activation and check-out procedures
Participates in system acceptance
Software Operation Maintains current software configurations
Performs operational software assurance
Maintains currency of COTS and other software technology
updates
Diagnoses and responds to reported software defects, anomalies,
and operational incidents and events
Monitors system operation and collects operational data
Develops and implements software retirement procedures
Software Maintenance Establishes software maintenance processes and plans
Obtains and maintains baseline software artifacts
Performs problem identification and technical impact analysis
Makes and assures changes to software (corrective, adaptive,
enhance)
Performs preventative maintenance and software re-engineering
Monitors and analyzes software maintenance activities
605
606
SWECOM 43 IEEE 2014

The following notations are used in table B13: Follow (F), Assist (A), Perform (P), Lead (L), Create (C).
Table B15
Sustainment Skill Sets and Activities by Competency Levels
Levels Organizational
Skill Sets Leader
System Transition 1. Participates in 1. Leads 1. Modifies

developing development of existing and
transition plans (P) the transition creates new
plan (L) guidelines for
transition plans
(C)
2. Participates in the 2. Leads in the
identification of identification of
stakeholders for the stakeholders
transition and for transition and
operational operational
requirements (P) requirements (L)
3. Participates in the 3. Leads in the 2. Modifies
identification of identification of existing and
system and software the system and creates new
constraints (P) software guidelines for
constraints (L) the
identification of
stakeholders
(C)
4. Identifies 4. Modifies
applicable systems existing and
and software develops new
operational systems and
standards (P) software
operational
standards (L)
1. Assists in 5. Leads in the 5. Approves
identifying development of software
applicable software transition transition and
systems and and operational operational
software documentation (L) documentation
operational (L)
standards (A)
1. Follows 2. Assists in 6. Leads installation 6. Approves new 3. Modifies
instructions to development of software (L) software existing and
help develop of software installations (L) creates new
software transition and templates for
SWECOM 44 IEEE 2014

Table B15
Skill Sets Leader
transition and operational software

operational documentation transition and
documentation (A) operational
(F) documentation
(C)
Installs
software (P)
2. Follows 3. Assists in 7. Develops training 7. Approves
instructions to development material for training material
help install of training operational support for operational
software (F) material for personnel (P) support
operational personnel (L)
support
personnel (A)
3. Assists in 4. Performs 8. Leads software 8. Approves
delivery of training of operational training software system
training for software (L) activation and
operational operational check-out
support support procedures (L)
personnel (A) personnel (P)
5. Performs 9. Develops 9. Leads in
software software system determining the
system activation and impacts of
activation and check-out software changes
check-out procedures (P) on the
procedures (P) operational
environment (L)
6. Assists in 10. Participated in
determining determining the
the impacts of impacts of software
software changes on the
changes on the operational
operational environment (P)
environment
(A)
7. Assists in 11. Participates in 10. Leads system 4. Modifies
system system acceptance acceptance (L) existing and
acceptance (A) (P) creates new
guidelines for
SWECOM 45 IEEE 2014

Table B15
Skill Sets Leader
determining the
impacts of
software
changes on the
operational
environment
(C)
5. Modifies
existing and
develops new
system
acceptance
methods, tools,
and techniques
(C)
Operations 1. Operates 1. Performs 1. Develops 1. Approves 1. Modifies
operational operational operational software operational existing and
software software configuration software creates new
configuration configuration management plans configuration standards and
management management (L) management frameworks for
tools (A) (P) plans (L) operational
software
configuration
management
(C)
2. Follows 2. Performs 2. Leads operational 2. Develops
instructions to operational software assurance software
perform software activities (L) assurance plans
operational assurance (P) (L)
software
assurance tasks
(F)
3. Installs COTS 3. Maintains 3. Leads
and other currency of maintenance of
software updates COTS and currency of COTS
(P) other software and other software
(P) technologies (L)
4. Diagnoses and 4. Leads 4. Develops 3. Creates
SWECOM 46 IEEE 2014

Table B15
Skill Sets Leader
responds to software help software help desk policies that

reported software desk activities plans (L) cover help desk
defects, (L) operations (C)
anomalies, and
operational
incidents and
events (P)
5. Operates tools 5. Analyzes 5. Acquires tools 4. Develops 2. Modifies
to collect operational and supervises plans for existing and
operational data data (P) analysis of collecting and creates new
under operational data (L) processing methods, tools,
supervision (F) operational data and techniques
(L) for collecting
and processing
operational data
(C)
6. Assists in 6. Implements 5. Develops
implementing software retirement software
software procedures (P) retirement plans
retirement (L)
procedures (A)
Maintenance 1. Assists in 1. Implements 1. Leads 1. Modifies
implementing software development of existing and
software maintenance software creates new
maintenance processes and plans maintenance software
processes and (P) processes and maintenance
plans (A) plans (L) policies,
processes and
procedures (C)
2. Obtains and
maintains
software
baseline
artifacts (P)
1. Participates in 3. Performs 2. Identifies
obtaining the problem software baseline
baseline software identification artifacts (L)
artifacts (P) (P)
SWECOM 47 IEEE 2014

Table B15
Skill Sets Leader
4. Assists in 3. Performs change 2. Leads problem

making impact analysis (P) identification and
changes to technical impact
software analysis (P)
(corrective,
adaptive,
enhance) (A)
4. Implements plans 3. Leads 2. Modifies

and makes changes development of existing and
to software plans and creates new
(corrective, supervises policies and
adaptive, enhance) making changes procedures for
(P) to software making changes
(corrective, to software
adaptive, (corrective,
enhance) (L) adaptive,
enhance) (C)
2. Assists in 5. Performs 5. Leads 4. Makes plans 3. Modifies
performing preventative preventative for and existing and
preventative maintenance maintenance and supervises creates new
maintenance and and software software re- preventative policies and
software re- re-engineering engineering maintenance and procedures for
engineering activities (P) activities (L) software re- preventative
activities (A) engineering maintenance
activities (L) and software re-
engineering (C)
6. Assists in 6. Monitors and 5. Leads

monitoring analyzes software monitoring and
and analyzing maintenance analysis of
software activities (P) software
maintenance maintenance
activities (A) activities (L)
607
608
SWECOM 48 IEEE 2014

609 16.ProcessModelsandLifeCycleModelsSkillArea
610 Software process model and life-cycle model skills are concerned with process definition and
611 tailoring, implementation, workflow, assessment, measurement, management, and improvement
612 of the software life cycle processes, including both processes guiding a specific set of activities
613 and postmortem processes. The skills apply to a range of software process paradigms: heavy
614 weight processes (sometimes called plan-driven processes), lightweight processes (sometimes
615 called agile), and a spectrum of processes that includes both heavy weight and light weight
616 features.
617 A critical part of the use of software processes is to measure and assess the effectiveness of
618 individual activities and their combinations on software projects. The key purpose of process
619 assessment is to modify and improve the processes to better achieve project goals.
620 It should be noted that Software Process Model and Life-Cycle Model skills are apply across
621 most of the other skill areas in this document; both life cycle and other cross cutting skill areas.
622 References
629
630
SWECOM 49 IEEE 2014

Table A16
Process and Life Cycle Skill Process and Life Cycle Activities
Sets
Software Development Life- Determine one or more organization-wide life cycle models (e.g.,
Cycle Models Implementation waterfall, spiral, V-model, incremental, maturity models)
Select a team software process (plan-driven, agile)
Lead a small team in execution of some portion of a life-cycle process
model (e.g., software design)
Carry out process activities specified in a life-cycle process model script.
Process Definition and Define software processes for a project team or for a software engineering
Tailoring activity (e.g., requirements engineering)
Tailor a defined software process to the needs of a project team or a
software engineering activity.
Interpret and adapt a software process to individual process
responsibilities and tasks.
Lead definition and tailoring of organization-wide software processes.
Process Implementation and Implement and execute software processes.
Management Provide guidance and advice to software teams on how to implement and
manage software processes,
Serve as a member of a Software Engineering Process Group.
Process Assessment and Collect data for assessment of a software process.
Improvement Analyzes process assessment data and implement improvement of team
software processes.
Use assessment information and reports for software process
improvement.
631
632
SWECOM 50 IEEE 2014

634 Table B16

SWECOM Competency Levels Process and Life Cycle Models Skill Sets and Activities
Skill Sets Engineer
Software 1. Provides 1. Carries out 1. Leads a small 1. Selects a life- 1. Determines the
Development assistance in the process team in execution of cycle model need for and selects
Life-Cycle installation and activities some portion of a process for a or develops an
Models use of tools specified in a life-cycle process software team. (L) organization-wide
appropriate for life-cycle model (e.g., life-cycle model
a projects process model software design) (C)
designated life- script. (A/P) (P/L)
cycle model
(F/A)
2. Assists in 2. Selects
selection of a department or
department or organization-wide
organizational- process models.
wide life-cycle (C)
process model.
(P/L)
3. Advises on
process
infrastructure,
training, and tools.
(C)
Process 1. Provides 1. Interprets and 1. Provides review 1. Leads definition 1. Conducts
Definition and assistance in the adapts a of defined and and tailoring of research into
Tailoring installation and software tailored processes. software processes effective software
use of tools for process to (A/P) for a project team process definition
defining and individual or for a software and tailoring. (C)
2. Tailors a software
modifying process engineering
process to the work
software responsibilities activity (e.g.,
of a small team.
processes. (F/A) and tasks. (A/P) requirements
(P/L)
engineering,
design, etc.). (L/M)
2. Provides 2. Leads definition
guidance to others and tailoring of
involved in tailored organization-wide
processes software processes.
(individual and (L/C)
team) (L)
Process 1. Provides 1. Collaborates 1. Leads small 1. Leads large 1. Provides
SWECOM 51 IEEE 2014

Skill Sets Engineer
Implementation assistance in the in the execution teams in the teams or multi- organization-wide
and installation and of a team implementation and team projects in the guidance and
Management use of tools for software execution of a implementation advice on how to
implementing, process. software process. and execution of a implement and
managing, and (P/L) software process. manage software
measuring (L) processes. (C)
software
processes. (F/A)
2. Implements 2. Provides guidance 2. Provides
and manages and advice to guidance and
individual individuals on the advice to software
process. (F/A) implementation and teams on how to
management of their implement and
personal processes. manage software
(P/L) processes. (L/M)
3. Serves as a 3. Serves as leader 2. Provides
member of a of a SEPG. (L) guidance and
Software advice on the
Engineering Process formation,
Group (SEPG). (P) structure, and
responsibilities of
SEPGs. (C)
Process 1. Provides 1. Assists in 1. Leads small 1. Leads software 1. Conducts
Assessment and assistance in the collecting data teams in collecting teams in collecting research into the
Improvement installation and for assessment data for assessment data for assessment effectiveness and
use of tools for of a software of software of software improvement of
assessing and process. (A) processes. (P/L) processes. (P/L) software processes.
improving (C)
software
processes. (F/A)
2. Collects data 2. Analyzes process 2. Analyzes
relevant to assessment data and process assessment
individual implements data and
process improvement of implements
execution. small team software improvement of
(F/A) processes. (P/L) team software
processes. (P/L)
3. Assesses and 3. As a member of a 3. Leads the SEPG, 2. Uses assessment
implements SEPG, provides in providing data, team reports,
improvement of input on software guidance on and SEPG reports
an individual process department or to establish
software organization-wide organization
SWECOM 52 IEEE 2014

Skill Sets Engineer
process. (A/P) improvement. (A/P) software process procedures and

improvement. standards for
(L/M) software process
improvement. (C)
635
636
SWECOM 53 IEEE 2014

637 17.SoftwareSystemsEngineeringSkillArea
638 Systems are collections of interconnected components that interact with other systems
639 and the environment in which they are embedded. They include natural systems, such as our
640 solar system, and purposefully engineered systems, such as digital computers. Modern
641 engineered systems range from household appliances to medical devices, automobiles,
642 spacecraft, and nuclear reactors. Engineered systems are increasingly reliant on software to
643 provide functionality, behavior, interconnections among components, and external interfaces to
644 environments that may be complex and ill defined.
645 Software engineers are often members of, and may be leaders of, teams that develop and
646 modify large and/or complex systems composed of diverse kinds of components, including
647 software. Not all software engineers will be, or need to be competent software systems
648 engineers; however, those software engineers who participate as members of systems
649 engineering teams for software-intensive systems should have the skills required to participate in
650 systems engineering projects. The skills and activities in this skill area apply to development of
651 systems for which software is a critical component but for which software may not be the
652 primary cost item or the key technology to be exploited.
653 Not all software-intensive systems are engineered systems in the traditional sense. For
654 example, an enterprise information system (EIS) may be dependent on software but the time,
655 effort, and cost of procuring and installing hardware and infrastructure software may far exceed
656 the time, effort, and cost of developing business-specific software within the EIS environment.
657 Systems engineering skills will be needed in these cases.
658 Table A provides a list of skills and work activities for a software engineer to
659 competently participate, for the indicated skills, as a member of a systems engineering team that
660 develops or modifies a large and/or complex software-intensive system.
661 Table A does not include all of the competencies that are important for a software
662 engineer who participates in systems engineering of software-intensive systems but rather
663 highlights those skills and activities that are especially important at the systems level. For
664 example, requirements elicitation is not included because the necessary skills are similar at both
665 the systems and software levels. The difference in requirement elicitation, and in many other
666 skill areas, is in the scope of considerations that must be addressed and the kinds and numbers of
667 stakeholders that are typically involved at the systems level. System-level stakeholders usually
668 include different kinds of engineers who have different technical specialties and different ways
669 of thinking about systems that include electrical, mechanical, civil, and other kinds of
670 components.
671 Another important consideration is that software engineers who participate in systems
672 engineering activities at a given competency level should have the same or a higher level of
673 competency in the corresponding software engineering activity. For example, a software
674 engineer who participates as a Practitioner in systems requirement elicitation should be a
675 competent software engineering Practitioner for the activity of software requirements elicitation.
SWECOM 54 IEEE 2014

676 Similarly a Team Leader for Requirements Engineering at the systems level should be a
677 competent Team Leader for Requirements Engineering at the software level.
678 Although the activities in Table A are listed in a sequential order, they are often
679 accomplished in iterative and incremental steps. Table B includes the activities, at five different
680 competency levels, for each skill in this skill area.
681 References
686 [SEBoK 2013] A. Pyster and D.H. Olwell, eds., The Guide to the Systems Engineering Body of
687 Knowledge (SEBoK), v. 1.2, The Trustees of the Stevens Institute of Technology, 2013;
688 http://sebokwiki.org.
691
SWECOM 55 IEEE 2014

692 Table A17
Software Systems Engineering Software Systems Engineering Activities
Skill Sets
System Development Life Cycle Select and integrate a software engineering development model
Modeling into a systems engineering development model
Tailor policies, procedures, and templates, and select applicable
standards
Concept Definition Identify system stakeholders
Develop the operational concepts (system context, operational
environment(s), prioritized features, quality attributes, operational
scenarios, assumptions, dependencies, limitations, and exclusions)
System Requirements Establish the system development environment and identify
technology constraints
Identify system-level traceability requirements and tools
Identify system requirements
Develop the System Requirements Specification
Develop plans, procedures, and scenarios for system integration,
verification, validation, and deployment
System Design Develop alternative solution concepts
Identify system components and specify relationships and
interfaces among components
Conduct trade studies to identify major system components for
hardware/software/manual-operations
Participate in making acquisition decisions for system components
Influence system design to avoid isolated stovepipe units of
software
Requirements Allocation Allocate requirements and interfaces to system components
(functional, behavioral, structural, quality) and interfaces between
software components and other major system components
Develop bi-directional traceability between system requirements
and software requirements
Analyze, clarify, and refine requirements allocated to software
Component Engineering Determine needed kinds of software components (database,
algorithms, internet protocols)
Make acquisition decisions for software components (buy, build,
open source, etc)
Work with software engineers who develop and integrate software
components
Provide liaison from software engineering to systems engineering
and other major component engineering
System Integration and Integrate software with other system components
Verification Participate in system verification activities
Provide liaison to software component engineers
System Validation and Deployment Participate in simulated and live system tests
Participate in system acceptance testing
Provide liaison to software component engineers
System Sustainment Planning Participate in planning for system sustainment
Prepare for operational support
Provide liaison and participate in planning for software
sustainment
693
694
SWECOM 56 IEEE 2014

695 The following notations are used in table B17: Follow (F), Assist (A), Perform (P), Lead (L), Create (C)
696 Table B17

Software Systems Engineering Skills Sets and Activities by Competency Level
Levels Entry Level Senior Software
Technician Practitioner Technical Leader
Skill Sets Practitioner Engineer
System 1. Uses tools 1. Assists in 1. Participates in 1. Participates in 1. Prepares

Development Life and follows integrating the integrating the selection of the frameworks for
Cycle directions to selected software selected software system integrating an
prepared development development development life organizations
depictions and model into the model into the cycle model (P) system and
documentation systems system software
of tailored development development development
development model (A) model (P) models (C)
models (F)
2. Leads selection
of the software
development life
cycle model (L)
3. Leads
integration of the
software
development
model into the
system
development
model (L)
2. Participates in 4. Participates 2. Modifies
systems in/leads tailoring existing models
engineering of policies, and creates new
meetings and procedures, and models and
prepares meeting templates, and ways of
minutes to include selection of integrated
decisions made, applicable software
open issues, other standards for engineering and
relevant projects and system
discussions and programs (P/L) engineering
action items (A) development
models (C)
3. Determines
applicable
policies,
procedures,
standards, and
guidelines, and
tailors them, for
an
organizations
system and
software
development
SWECOM 57 IEEE 2014

models (C)
Concept Definition 1. Assists by 1. Identifies 1. Develops lists 1. Prepares 1. Develops
locating potential of stakeholders criteria for new techniques
identified stakeholders by and categorizes identifying for identifying
stakeholders (A) examining their likely stakeholders (L) stakeholders (C)
historical data and interests (P/L)
having
discussions with
appropriate
personnel inside
and outside the
systems
engineering team
(A/P)
2. Arranges 2. Attends 2. Leads
stakeholder stakeholder stakeholder
meetings (A) meetings and meetings (L)
solicits
stakeholder
needs, wants, and
desires (P)
3. Attends 2. Attends
stakeholder stakeholder
meetings and meetings to
takes meeting document
minutes (A) stakeholder needs,
wants, and desires
(P)
4. Follows 3. Develops 3. Leads 3. Facilitates 2. Develops
directions to elements of the development of development of new methods,
prepare elements Concept of scenarios, the Concept of tools, and
of the Concept Operations (A) storyboards, Operations (L) techniques for
of Operations prototypes, and concept
(F) use cases (L) definition (C)
4. Obtains
stakeholder
consensus on the
Concept of
Operations (L)
5. Develop
acceptance
criteria (P)
System 1. Attends 1. Establishes the 1. Establishes the 1. Establishes
Requirements meetings and system system organizational
documents the development development policies and
system environment and environment and procedures for
development identify identify system
SWECOM 58 IEEE 2014

environment and technology technology requirements

technology constraints (P) constraints (L) engineering
constraints (P)
2. Procures and 1. Provides 2. Identifies 2. Identifies 2. Modifies
operates training on system level system level existing and
traceability tools traceability traceability traceability develops new
to establish and procedures and requirements and requirements and methods, tools,
maintain tools (A) tools tools (L) and techniques
traceability for system
requirements
engineering (C)
3. Follows 2. Assists in 3. Participates in 3. Leads the
instructions to development of development of development of
document the the System the System the System
System Requirements Requirements Requirements
Requirement Specification (A) Specification (P) Specification (L)
Specification (F)
4. Documents 3. Assists in 4. Participates in 4. Leads the
plans, development of development of development of
procedures, and plans, procedures, plans, procedures, plans, procedures,
scenarios for and scenarios for and scenarios for and scenarios for
system system system system
integration, integration, integration, integration,
verification, verification, verification, verification,
validation, and validation, and validation, and validation, and
deployment deployment (A) deployment (P) deployment (L)
System Design 1. Assists in 1. Participates in 1. Leads 1. Develops
development of development of development of policies and
alternative alternative alternative procedures for
solution concepts solution concepts solution concepts system design
and conducting and conducting to identify major in an
trade studies to trade studies to system organization (C)
identify major identify major components (L)
system system
components (A) components (P)
2. Participates in 2. Participates in 2. Leads /
making buy/build identifying participates in
decisions for system making buy/build
software component and decisions for
components (P) the interfaces and major system
relationships components,
among (L/P)
components (P)
3. Assists in 3. Leads in
selecting making buy/build
components to be decisions for
procured (A) software
SWECOM 59 IEEE 2014

components (L)
1. Identifies 4. Procures
sources of selected software
software components (L)
components to
be procured (A)
5. Participates in 2. Leads / 2. Develops
system design participates in new approaches
meetings to avoid system design to system
isolated stovepipe meetings to avoid design to avoid
units of software isolated stovepipe isolated
(P) units of software stovepipe units
(P/L) of software (C)
Requirements 1. Documents 1. Assists in 1. Identify 1. Leads / 1. Develops
Allocation allocable and identifying allocable and non- participates in new methods,
non-allocable allocable and non- allocable meetings to tools, and
requirements (F) allocable requirements (P) identify and techniques for
requirements (A) allocate requirements
requirements allocation and
(functional, flowdown (C)
behavioral,
structural, quality)
and interfaces to
software
components and
other major
system
components (L/P)
2. Documents 2. Attends 2. Participates in
allocation of meetings and meetings to
requirements records minutes to allocate
(functional, allocate requirements
behavioral, requirements (functional,
structural, (functional, behavioral,
quality) and behavioral, structural, quality)
interfaces to structural, quality) and interfaces to
software and interfaces to software
components and software components and
other major components and other major
system other major system
components (F) system components (P)
components (P/L)
3. Participates in 3. Leads meetings
meetings to refine to refine
requirements requirements
allocated to allocated to
software (P) software (L)
SWECOM 60 IEEE 2014

1. Operates 3. Documents 3. Develops bi- 3. Leads

traceability tools traceability from directional traceability from
and prepares system traceability system
traceability reports requirements to between system requirements to
(F) software requirements and software
requirements (F) software requirements (L)
requirements (P)
4. Assists in 4. Participates in 3. Leads in clarify
clarifying and clarifying and and refine
refining refining requirements
requirements requirements allocated to
allocated to allocated to software (L)
software (A) software (P)
Component 1. Assist in 1. Determine 1. Lead 1. Modify
Engineering determining and needed software determination of existing and
documenting components (P) needed kinds of develop new
needed kinds of software methods, tools,
software components for a and techniques
components (A) project or program for component
(L) engineering (C)
1. Document 2. Assist in 2. Determine 2. Lead buy/build
buy/build determination of buy/build decision making
decisions for buy/build decisions for process for
software decisions for software software
components software components (P) components (L)
components (L)
2. Maintain 3. Develop and 3. Develop and 3. Establish
baselines of integrate software integrate software procedures to
software components (A/P) components (P/L) develop and
components (A) integrate software
components (L)
4. Provide liaison
from software
engineering to
systems
engineering and
other major
component
engineering (L)
System Integration 1. Assist in 1. Assist in system 1. Participate in 1. Lead 1. Modify
and Verification integration of verification integration of integration of existing and
software with activities (A) software with software with provide new
other system other system other system methods of
components (A) components (P) components (L) integrating
software with
other system
SWECOM 61 IEEE 2014

components (C)
2. Participate in 2. Lead /
system participate in
verification system
activities (P) verification
activities (L/P)
2. Assist in 3. Provide liaison 3. Lead /
providing liaison to software participate in
to software component providing liaison
component engineers (P) to software
engineers (A) component
engineers (L)
System Validation 1. Operate tools 1. Assist in 1. Participate in 1. Lead / 1. Modify
and Deployment for performing performing simulated and Participate in existing and
simulated and simulated and live live system tests simulated and live develop new
1. Participate in live system tests system tests (A) (P) system tests (P/L) methods, tools,
system acceptance (F) and techniques
testing for system
validation and
deployment (C)
2. Provide liaison to 2. Operate tools 2. Assist in system 2. Participate in 2. Establish

software component for performing acceptance testing system system
engineers system (A) acceptance testing acceptance
acceptance (P) criteria
testing (F)
3. Serve as liaison 3. Lead /
to software participate in
component system
engineers during acceptance testing
system validation (P/L)
and deployment
(P)
4. Lead in
providing liaison
to software
component
engineers during
system validation
and deployment
(P/L)
System Sustainment 1. Assist in 1. Participates in 1. Establish
Planning planning for identifying criteria and
system stakeholders and procedures for
sustainment (A) developing a system
transition plan
SWECOM 62 IEEE 2014

and requirements sustainment

for operational
support (P)
2. Prepare for 2. Lead/
operational participate in
support (P) planning for
system
sustainment (L)
697
698
SWECOM 63 IEEE 2014

699 18.SoftwareQualitySkillArea
700 The Software Quality skill area consists of fundamental skills that a software engineer needs to
701 possess in order to produce a high quality product; a high quality product is one that conforms to
702 its requirements and satisfies user needs. In SWECOM, the software quality skill area includes
703 both software quality assurance and software quality control, which includes verification and
704 validation. Measurement plays a major role in the areas of software quality assurance and
705 control. In this skill area, we only mention the data collection and data analysis portion of
706 measurement as an activity in a specific skill topic. The complete treatment of measurement is
707 covered in the software measurement skill area.
708 Software Quality Assurance (SQA) includes all the competencies that are associated with
709 ensuring a quality process. In other words, SQA within an organization establishes a series of
710 processes, methods, standards and techniques that are used throughout the organization to
711 develop high quality products. SQA is also responsible for implementing monitoring techniques
712 to assure that established processes, methods, standards and techniques are followed. Finally
713 SQA is responsible for implementing appropriate feedback loops that prevent defects from being
714 introduced into the product.
715 NOTE: For the purpose of this document, the treatment of SQA is not comprehensive, as some of
716 the SQA processes are covered in other skill areas (e.g., code source control in the construction
717 skill area), or as other skill areas (e.g., configuration management).
718 Software Quality Control (SQC) includes all the competencies that are associated with ensuring
719 a quality product. In other words, through SQC an organization ensures that the software product
720 will meet its quality goals. By collecting information and conducting root cause analyses it
721 continually improves the organizations ability to produce high quality software products in the
722 future. Software quality control may also be referred to as Software Validation and Verification;
723 however, there are some minor differences between the two terms.
724 Software Verification and Validation consists of fundamental competencies that a software
725 engineer should possess in order to produce a high quality product. Some of these competencies
726 are needed throughout the software development life cycle (e.g., reviews), and some are more
727 specific to a specific phase of the project (e.g., testing, which is covered in the Software Testing
728 skill area).
729 Within software industries some of the above terminologies have been used interchangeably. The
730 purpose of this competency model is not to debate the proper use of these terminologies, but to
731 identify some of the major skills and the corresponding activities that are required of software
732 engineers in order to deliver high quality products. Table A presents the skill areas and the
733 corresponding activities performed within those skill areas. Table B presents competency levels
734 for the activities. It is important to note that in this document, some of the activities that are
SWECOM 64 IEEE 2014

735 associated with a specific skill may belong to software quality assurance or to software quality
736 control.
737 References
739 IEEE, 2002.
740 [IEEE 829-2008] IEEE Std. 829-2008, IEEE Standard for Software and System Test
741 Documentation, IEEE, 2008.
748 [Kan 2002] Stephen H. Kan, Metrics and Models in Software Quality Engineering Second
749 Edition, Addison-Wesley, 2002.
750 [RTCA DO-178C] RTCA, Inc., Software Considerations in Airborne Systems and Equipment
751 Certification, DO-178C/ED-12C, 13 Dec. 2011.
754 [Westfall 2009] Linda Westfall, The Certified Software Quality Engineering Handbook, Quality
755 Press, 2009.
756
SWECOM 65 IEEE 2014

Table A18
Software Quality Skill Sets Software Quality Activities
Software Quality Management Instill a culture of producing high quality product
(SQM) Establish and follow quality goals and quality attributes
Establish and follow a quality plan
Identify, establish, follow and verify appropriate processes,
standards, and quality model that facilitates achieving the quality
goals and attributes
Identify the stakeholders that have authority and/or
accountability for the process and product quality
Identify and use the appropriate tools and measurements that are
needed to reach the quality goals and attributes
Establish and execute corrective actions if quality goals are not
achieved
Establish and execute appropriate continuous improvement
processes
Establish and update requirement traceability metrics and
verification metrics
Reviews (Review, walkthrough, Plan, organize, and conduct appropriate review meeting
inspection) Participate as a member of review team
Collect and analyze appropriate data resulting from the review
Identify, assign and perform the necessary corrective actions
Audits (concentrates on both Plan, organize, and conduct the independent audits
product and process, but it is done Collect appropriate data resulting from the audit raised as a
by an independent, internal or result of audit
external, organization) Collect and analyze the data collected from the audits
Establish and implement the appropriate resolutions for the
identified problems
Statistical Control Identify and collect set of quality data under statistical control
Identify set of subjective and objective variances for the data
Analyze the data collected
Establish and implement set of control processes
Evaluate the effectiveness of the control processes
757
758
SWECOM 66 IEEE 2014

760 Table B18

Software Quality Skill Sets and Activities by Competency Level
Skill Sets Engineer
Software 1. Follow defined 1. Follow quality 1. Establish Quality 1. Establish the 1. Create new and
Quality quality processes standards for the Standards for the culture of improved quality
Management and standards (P) product and product (P/L) producing quality practices for
supporting product, and delivering high
processes (P) following the quality product (C)
quality process
across the projects
(P/L)
2. Assist with 2. Follow 2. Select the 2. Create new
establishing the defined quality appropriate SQM processes (C)
appropriate models (P) processes for the
infrastructure (i.e., project that support
defect tracking the identified quality
tool) to support goals (P)
organizations
quality goals (A)
3. Use 3. Identify quality 2. Establish quality 3. Examines and
appropriate tools characteristics and standards, models assesses the
and resources to attributes for the and processes for effectiveness of a
develop quality product and projects (P/L) specific SQM
products (P) establish their process across an
priorities (P) organization. (C)
4. Assist with 4. Identify the 3. Analyze the 4. Make
identification of quality models that advantages and recommendations
the different need to be followed disadvantages of related to
quality for the project (P) alternative SQM organization-wide
characteristics processes and tools SQM processes.
and attributes for that can be used for (C)
the product (A/P) achieving
organizational
product quality
goals (P)
5. Ensure 5. Develop the 4. Develop QA 5. Create/modify
product quality Quality Assurance plan for the project SQM processes to
goals are (QA) plan for the (L) achieve higher
achieved (P) project (P) quality products
and processes. (C)
6. Collect quality 6. Identify 5. Identify 6. Propose/Design
SWECOM 67 IEEE 2014

Skill Sets Engineer
metrics and appropriate organizational new tools to

prepare quality stakeholders who measures that improve the
documentation to have authority and support achieving achievement of
be shared with accountability in product quality product quality
the appropriate regards to the goals (across goals. (L)
stakeholders (P) quality process and projects). (P/L)
quality product (P)
7. Develop and 7. Identify 6. Identify
update appropriate continuous
appropriate measures that improvement
traceability support achieving opportunities
matrix for the product quality across projects (L)
product (P) goals (P/L)
8. Identify
appropriate tools
and resources that
need to be used in
order to achieve the
product quality
goals. (P/L)
9. Verify the quality
goals are met, and
requirements are
met (P/L)
10. Identify
continuous
improvement
opportunities across
project (L)
Reviews 1. Assist with the 1. Participate as 1. Identify the 1. Identify the 1. Create new or
(review, necessary logistics an active appropriate review appropriate customize review
walkthrough, associated with member of processes that are organization wide process to meet the
and the reviews and review team in needed to achieve review processes. organizational
Inspection) inspections, which order to achieve the product quality (P/L) need. (C)
includes but not the goals of the goals. (P/L)
limited to: activity (P)
a. Meeting
logistics (P)
b. Perform all
appropriate data
warehousing (P)
c. Generate
SWECOM 68 IEEE 2014

Skill Sets Engineer
appropriate
report associated
with the meeting
(P)
2. Use 2. Identify the 2. Conduct across 2. Develop new
appropriate appropriate the organization root cause analysis
checklist called personnel that need data analysis for techniques. (C)
for by the review to participate in the the purpose of root
organizer (P) reviews activity. (P) cause analysis. (P)
3. Collect 3. Identify the 3. Based on the
appropriate and appropriate review data,
accurate data that measures that need identify appropriate
is called for by to be collected as corrective actions
the review part of the product to be implemented
organizer (P) review (P) across projects for
the purpose of
achieving product
improvement.
(P/L)
4. Produce the 4. Identify
appropriate appropriate artifacts
documentation under the review
that is called for and the
by the quality corresponding
management checklist (P)
plan (P)
5. Follow the 5. Analyze the
appropriate collected product
practices that are data, for the purpose
defined by the of root cause
quality analysis and
management assessment of the
plan (P) review effectiveness
(P)
6. Identify
appropriate
corrective actions in
order to achieve
product
improvement. (P)
7. Lead the review
SWECOM 69 IEEE 2014

Skill Sets Engineer
team (P)
Audits (both 1. Establish the 1. Conduct the 1. Plan, organize 1. Establish audit 1. Create new audit
independent necessary audit (P) and conduct audits infrastructure by processes (C)
product and environment to (P/L) identifying
process conduct the audit
a. appropriate
audit, (A/P)
organization
internal or
conducting the
external)
audit (P)
b. products and
processes that need
to be included in
audits (P)
and
c. stakeholders
receiving the audit
results (P)
2. Identify and 2. Analyze the
classify the issues audit results for
identified by the continuous
audits (P) improvement (P)
3. Establish and
implement
appropriate
resolution strategy
for identified issues
(P)
Statistical 1. Establish the 1. Collect set of 1. Analyze the data 1. Identify set of
Control necessary quality data collected (L) quality data under
environment for under statistical statistical control
data collection and control (P) (P)
warehousing (P)
2. Deploy set of 2. Identify set of
control process (P) subjective and
objective variances
for the data (P)
3. Evaluate the 3. Analyze the data
effectiveness of the collected (L)
control processes
(A)
SWECOM 70 IEEE 2014

Skill Sets Engineer
4. Establish and
implement set of
control processes
(P)
5. Evaluate the
effectiveness of the
control processes
(P)
761
762
SWECOM 71 IEEE 2014

763 19.SoftwareSecuritySkillArea
764 Software security is a crosscutting skill area that affects all of the software development
765 lifecycle. It includes techniques and processes to identify potential security vulnerabilities, to
766 avoid them in design and implementation, and to discover them in software artifacts. It includes
767 mimicking an attacker and reviewing attack patterns. It also includes collecting and monitoring
768 metrics to ensure that disciplined software development processes are followed. Testing is
769 included in a separate skill area.
770 References
771 [Allen 2008] Julia Allen et al., Software Security Engineering: A Guide for Project Managers,
772 Addison-Wesley Professional, 2008.
773 [BITS 2012] BITS Software Assurance Framework, Financial Services Roundtable, 2012;
774 www.bits.org/publications/security/BITSSoftwareAssurance0112.pdf.
775 [Hilburn 2013] Thomas Hilburn, et al., Software Assurance Competency Model, Technical Note
778 [Merkow 2010] M. Merkow and L. Raghavan, Secure and Resilient Software Development, CRC
779 Press, 2010.
780 [Seacord 2005] R. Seacord, Secure Coding in C and C++, Addison-Wesley, 2005.
781
782
783
SWECOM 72 IEEE 2014

Table A19
Software Security Skill Sets Software Security Activities
Requirements Identify security risks (e.g., misuse cases)
Create requirements that capture security issues
Perform initial threat modeling
Design Model threats and associated risks of new and modified systems
Identify the attack surface of new and modified systems
Follow recommended design principles to create secure systems
Use appropriate secure design patterns
Construction Follow recommended secure coding principles to avoid security
vulnerabilities (e.g., buffer overflow, input validation)
Follow recommended coding standards to avoid security
vulnerabilities
Process Collect and monitor metrics for security assessment processes
Quality Perform code reviews to identify security vulnerabilities
Use static analysis methods to identify security vulnerabilities
784
785
786
SWECOM 73 IEEE 2014

Table B19
Software Security Skill Sets and Activities by Competency Level
Skill Sets Senior Software
Levels Engineer
Requirements 1. Identifies security 1. Creates or

risks (e.g., misuse proposes new
cases) (P) methods for
recognizing
security
vulnerabilities (C)
2. Creates
requirements that
capture security
issues (P)
3. Perform initial
threat modeling (P)
Design 1. Follows 1. Models threats
recommended and associated risks
design principles of new and modified
to create secure systems. (P)
systems (e.g.,
providing
multiple layers
of protection,
using access
control
mechanisms and
encrypting
sensitive data).
(F)
2. Uses 2. Identifies the
appropriate attack surface (i.e.,
secure design the areas of potential
patterns. (F) weakness exploited
by attackers) of new
and modified
systems. (P)
Construction 1. Follows 1. Selects or 1. Establishes 1. Creates new
recommended establishes project organization coding standards to
secure coding coding standards to coding standards to avoid security
principles to avoid security avoid security vulnerabilities (C)
avoid security vulnerabilities (P) vulnerabilities (L)
SWECOM 74 IEEE 2014

Table B19
Software Security Skill Sets and Activities by Competency Level
Skill Sets Senior Software
Levels Engineer
vulnerabilities
(e.g., buffer
overflow, input
validation) (F)
2. Follows
recommended
coding standards
to avoid security
vulnerabilities
(e.g., validating
input, preventing
exception
handling
mechanisms
from revealing
too much
information
about
applications and
systems. (F)
Process 1. Assists in 1. Follows 1. Establishes
collection of project standards organization
metrics for in collection of standards for
security security security assessment
assessment assessment processes (L)
processes. (A) metrics. (F)
Quality 1. Assists in 1. Performs code 1. Selects 1. Creates new
installation of reviews to appropriate static static analysis
static analysis identify security analysis tools to methods or tools.
tools. (A) vulnerabilities. identify security (C)
(P) vulnerabilities. (P/L)
2. Uses static
analysis methods
to identify
security
vulnerabilities.
(P)
788
SWECOM 75 IEEE 2014

789 20.SoftwareSafetySkillArea
790 Software intensive systems that command, control, and monitor safety-critical functions require
791 analyses of extensive software safety. Safety is an essential attribute in such systems. Modern
792 system safety is based on analysis of system functionality and identification of hazards, risks,
793 and acceptance criteria. Analysis and identification result in specific safety requirements that
794 need to be considered in order to guide subsequent design and implementation.
795
796 The safety process must be comprehensive, with structured objectives that require rigorous
797 engineering evidence to verify safety functionality, which must be deterministic and result in a
798 system with acceptable risk in the intended operating environment. Development of safety-
799 critical systems must address functional hazard analyses and include detailed specification,
800 design and implementation artifacts at all levels.
801 References
802 [Bozzano 2010] Marco Bozzano and Adolfo Villafiorita, Design and Safety Assessment of
803 Critical Systems, CRC Press, 2010.
804 [Hilburn 2013] Thomas Hilburn, et al., Software Assurance Competency Model, Technical Note
809 [Leveson 2011] N. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety,
810 The MIT Press, 2011.
811 [Rierson 2013] Leanna Rierson, Developing Safety-Critical Software: A Practical Guide for
812 Aviation Software and DO-178C Compliance, CRC Press, 2013
813 [Stephans 2004] R.A. Stephans, System Safety for the 21st Century: The Updated and Revised
814 Edition of System Safety 2000, Wiley, 2004.
815 [Vincoli 2006] J.W. Vincoli, Basic Guide to System Safety, Wiley, 2006.
816
817
SWECOM 76 IEEE 2014

Table A20
Software Safety Software Safety Activities
Skill Sets
Requirements Conduct formal system hazard analyses.
Identify safety requirements and verify their completeness.
Assure that safety requirements are correct and realizable.
Design Propose and select design solutions to assure the hazards are mitigated.
Analyze design risk from the safety perspective.
Verify completeness and correctness of the design from a safety perspective.
Ensure safety requirements are met.
Construction Select project coding standards to assure code safety.
Implement code components and their interfaces, considering safe coding
practices to avoid safety violations.
Verify that the safety aspects of a design are implemented in the produced
code.
Testing Perform testing to assure safety requirements are met.
Use industry guidelines and established organization standards for safety
validation and verification.
Process Use established organization standards for safety assessment and selection of
safety criteria.
Identify artifacts required to establish a safety case.
Use industry criteria to verify the completeness of the safety requirements.
Quality Collect data and report about the safety aspects of the product and process.
Analyze quality management (QM) data to assess and manage the overall
project quality, with a focus on safety aspects.
818
819
SWECOM 77 IEEE 2014

821 Table B20

Software Safety Skill Sets and Activities by Competency Level
Levels Technician Entry Level Practitioner Technical Leader Senior Software
Engineer
Skill Sets
Requirements 1. Assists in 1. Creates and 1. Using tools, 1. Verifies
collecting data verifies conducts formal completeness and
for creation of a preliminary system hazard correctness of
hazard list hazard lists. analyses verifying safety
(F/A) (A/P) safety models. (P) requirements. (/L)
2. Assists in 2. Uses software
identification of tools to build
top-level safety models
mishaps and (FTA, ETA,
their causes. FMEA). (A/P)
(F/A)
3. Assists with 3. Assists in 2. Identifies safety 2. Interacts with
installation of safety requirements. (P) system and
safety and requirements software engineers
reliability tools. identification. to assure that
(F/A) (F/A) safety requirements
are complete and
realizable. (L)
3. Assures that 1. Creates or
safety requirements proposes new
are included in the methods for
overall system safety
requirements. (P) assessment,
mitigation, and
verification. (C)
Design 1. Assists in 1. Identifies 1. Proposes and 1. Verifies 1. Creates or
identifying design solutions selects design completeness and proposes new
mitigation to assure that the solutions to assure correctness of the design solutions
techniques for hazards are the hazards are design, including leading to
defined safety mitigated and the mitigated. (P) safety hazards and increasing safety
requirements. safety safety qualities. of new design.
(F/A) requirements are (P/L) (C)
met. (A/P)
2. Follows 2. Supervises design 2. Leads the
recommended team. Analyzes risk project deciding
design and verifies design the proposed
principles. (P) from the safety architectural
perspective. (P/L) solutions to
SWECOM 78 IEEE 2014

Engineer
Skill Sets
mitigate hazards.
(L)
3. Uses design 3. Evaluates risk
tools to build related to design
appropriate safe for safety. (P/L)
design patterns.
(P)
Construction 1. Implements 1. Selects project 1. Establishes 1. Creates new
large code coding standards to organization coding standards
components and assure code safety. coding standards to to prevent safety
their interfaces (P) prevent safety violations. (C)
considering safe violations. (L/C)
coding practices
to avoid safety
violations. (A/P)
2. Manages 2. Oversees and
interfacing of large verifies the safety
code components aspects of the
with special design are
attention to potential implemented in the
safety issues. (P/L) produced code. (L)
Testing 1. Assists in the 1. Performs 1. Selects 1. Establishes 1. Contributes
installation of testing using appropriate testing organization expertise to
tools and tools with a techniques for standards for safety establish new
infrastructure focus on safety assuring safety of validation and organization
for safety requirements. the application verification. (L/C) guidelines
requirements (A/P) supervising testing. related to testing
testing. (F/A) (P) of safety of
software
intensive
applications. (C)
2. Applies 2. Manages the
applicable industry project, being
standards to assure responsible for
that the product overall safety and
meets the industry meeting industry
safety criteria. (P) guidelines. (L)
Process 1. Assists in 1. Identifies 1. Contributes to 1. Leads the safety
collection of artifacts required and verifies the team responsible
data to establish to establish the completeness of the for project safety
the project safety case safety case case. (L)
SWECOM 79 IEEE 2014

Engineer
Skill Sets
safety case. following following the
(F/A) industry selected industry
standards. (A/P) criteria. (P)
2. Establishes 1. Contributes
organization expertise to
standards for safety establish better
assessment means to assess
processes and safety. (C)
selection of safety
criteria. (L/C)
Quality 1. Assists in 1. Collects safety 1. Supervises 1. Manages the 1. Contributes
collection of QM data and collection of QM overall project expertise to
Safety QM data. reports the data and their quality with focus improve means
(A) project status. compatibility with on the safety of measuring and
(A/P) the safety case. aspects. (L) establishing
(P/L) safety quality of
product and
process. (C)
822
823
824
SWECOM 80 IEEE 2014

825 21.SoftwareConfigurationManagementSkillArea
826 According to IEEE standard 828, configuration management is the discipline of applying
827 technical and administrative direction and surveillance to: identify and document the functional
828 and physical characteristics of a configuration item; control changes to those characteristics;
829 record and report change processing and implementation status; and verify compliance with
830 specified requirements [IEEE 828-2012]. According to the Software Configuration Management
831 KA in the SWEBOK Guide, the elements of software configuration management include
832 [SWEBOK 2014]:
833 Software configuration identification
834 Software configuration control
835 Software configuration status accounting
836 Software configuration auditing
837 Software release management and delivery
838 Skills for each of these elements and the associated activities are indicated in Table 1. The
839 following acronyms are used in Table 1 and throughout this skill area:
840 SCM: Software Configuration Management
841 SCMP: Software Configuration Management Plan
842 SCI: Software Configuration Item
843 SDLC: Software Development Life Cycle
844 References
845 [Aiello 2010] Bob Aiello and Leslie Sach, Configuration Management Best Practices: Practical
846 Methods that Work in the Real World, Addison-Wesley Professional, 2010.
847 [Babich 1986] Wayne A. Babich, Software Configuration Management: Coordination for Team
848 Productivity, Addison-Wesley, 1986.
849 [IEEE 828-2012] IEEE Std. 828-2012, IEEE Standard for Configuration Management in
850 Systems and Software Engineering, IEEE, 2012.
853
SWECOM 81 IEEE 2014

Table A21
Software Configuration Software Configuration Management Activities
Management (SCM) Skill Sets
Plan SCM Determine organizational context for and constraints on SCM
Identify software components to be controlled by SCM
Design data and code repositories
Plan versioning procedures for path branching and path integration
Develop/adopt an change control process
Identify and procure SCM tools
Establish SCM library
Develop SCMP
Conduct SCM Follow SCMP
Use SCM tools
Control path branching and path integration during development
Generate, classify, and manage problem reports
Maintain and update SCM baselines
Prepare SCM reports
Conduct SCM audits
Manage software releases Develop software release plan
Identify and procure software release tools
Use software release tools
Produce software releases
Design and implement tools and procedures for generating patches to
be delivered
854
855
SWECOM 82 IEEE 2014

856 The following notations are used in Table B21: Follow (F), Assist (A), Perform (P), Lead (L) Create (C).
Table B21
Software Configuration Management Skill Sets and Activities by Competency Level
Skill Sets Engineer
Plan SCM 1. Operate SCM 1. Assist in 1. Participate in 1. Determine 1. Develop new

tools (F) determining determining impact organizational ways of organizing
impact of of constraints on context for SCM to perform SCM
constraints on SCM imposed by (L) (C)
SCM imposed by policies, contract,
policies, and SDLC (P)
contract, and
SDLC (A)
2. Operate and 2. Assist in 2. Assist in 2. Adopt an 2. Develop new
maintain SCM developing, developing, existing way of templates and ways
library under updating, and updating, and organizing for of planning for
technical leader maintaining the maintaining the SCM and tailor and SCM (C)4.
supervision (F) SCMP (A) SCMP (A) template for the Develop new
SCMP (L) measures and
measurements for
SCM (C)
3. Provide 3. Develop and 3. Determine 5. Develop
measurement maintain the SCMP constraints and procedures for
data for SCM (L) impacts of identifying SCIs
measures (P) constraints on and the
SCM imposed by relationships
policies, contracts, among them (C)
and SDLC (L)4.
Develop and
maintain the SCMP
(L)
4. Assist in 4. Identify SCIs (P) 6. Specify SCM 6. Specify new
identifying measures to be SCM tools and
software used (L) ways of combining
configuration existing SCM tools
items (SCIs) (A) (C)
5. Assist in 5. Procure SCM 7. Identify SCIs 7. Specify new
selecting and tools (P) and the ways of organizing
procuring SCM relationships SCM libraries (C)
tools (A) among them (L)
6. Set up SCM 8. Specify SCM
library for a tools (L)
project under
SWECOM 83 IEEE 2014

Table B21
Skill Sets Engineer
technical leader
supervision (L)
9. Specify template
for, and supervise
setting up the SCM
library (L)
Conduct SCM 1. Operate tools 1. Implement 1. Evaluate and 1. Tailor and adopt 1. Revise existing
to generate SCM and document report to CCB mechanisms for and develop new
status and audit approved impacts of proposed requesting, mechanisms for
reports (F) changes to SCIs changes to SCIs (P) evaluating, and requesting,
approving software evaluating, and
changes, including approving software
deviations and changes, including
waivers (P) deviations and
waivers (C)
2. Generate, 2. Generate, 2. Generate, classify, 2. Appoint 2. Develop new
classify, and classify, and and manage problem members and mechanisms for
manage problem manage problem reports (L) convenes the CCB SCM status
reports reports (P)
(L) accounting (C)
3. Assist in using 3. Use established 3. Lead CCB in 3. Develop new
adopted procedures for making yes/no processes and
mechanisms for populating and decisions on procedures for
requesting, maintaining SCM change requests (L) generating SCM
evaluating, and library (P) audit reports (C)
approving
software
changes,
including
deviations and
waivers (A)
4. Assist in 4. Use established 4. Ensures that
establishing and mechanisms to approved changes
maintaining the record and report are made and
mechanisms for SCM information documented (L)
recording and (P)
reporting SCM
information and
generating SCM
audit reports
(A)Provide SCM
SWECOM 84 IEEE 2014

Table B21
Skill Sets Engineer
audit reports as
scheduled and as
requested (P)
5. Develop and 5. Maintain
tailor tools for mechanisms for
generating SCM recording and
audit reports (P) reporting SCM
information (L)
6. Establish and
maintain the
mechanisms for
generating SCM
audit reports (L)
Manage 1. Operate tools 1. Participate in 1. Participate in 1. Develop 1. Modify existing
Software to build software developing developing software software release and develop new
Releases releases (A) software release release plans (P) plans (L) formats and
plans (P) procedures for
implementing
software release
plans (C)
2. Use software 2. Participate in 2. Lead building and 2. Modify existing
release tools to building and verifying of and create new
produce software verifying software releases tools for building
releases (A) software releases (L) software releases
(P) (C)
3. Produce 3. Participate in 3. Implement release
software releases building of plans (P)
(P) software releases
(P)
857
858
859
SWECOM 85 IEEE 2014

860 22.SoftwareMeasurementSkillArea
861 Measurement is a foundation element of the engineering disciplines, including software
862 engineering. Measurements are used to quantify attributes of processes and products for the
863 purposes of assessing progress and providing indications of real or impending problems.
864 Measurement is a cross cutting skill area that applies to each of the other skill areas in this
865 competency model. To be effective, measurement activities are planned prior to implementation
866 and adjusted as necessary during implementation to improve effectiveness.
867 Planning at the project level includes identifying measurement needs, selecting measures and
868 measurement scales, establishing data collection and analysis methods, setting target values and
869 thresholds, and the other planning activities listed in Table A. Measurement planning skills at the
870 organizational level are also included. Plans are then implemented to perform measurement
871 activities. Planning and performing measurement includes the activities listed in Table B.
872 The skills and activities in this skill area apply equally to measurement of management attributes
873 such as schedule and budget; however, the emphasis of this skill area is on measurement of
874 process and product attributes. Process attributes to be measured may include items such as
875 percent of effort for various work activities, levels of rework for various work products, and so
876 forth. Product measures may include items such as work products completed, rate of defect
877 discovery and defect correction, and so forth. See the cited references for more information on
878 process and product measures and measurement.
879 References
880 [Abran 2010] Abran, Alain, Software Metrics and Software Metrology, Wiley-IEEE Computer Society Press, 2010.
885 [IEEE 15939-2008] IEEE Std. 15939-2008, Standard Adoption of ISO/IEC 15939:2007 System
886 and Software Engineering Measurement Process, IEEE, 2008.
889
SWECOM 86 IEEE 2014

Table A22
Software Measurement Skill Sets Software Measurement Activities
Plan measurement process Identify measurement needs
Define measures
Select measures and measurement scales
Establish data collection and analysis methods
Set target values and thresholds
Establish report formats and reporting procedures
Identify measurement tools
Procure and install measurement tools
Plan for data storage
Perform measurement process Use measurement tools and manual procedures to collect data
Validate collected data
Retain valid data in a repository
Generate and distribute reports
Identify and recommend improvements to the measurement process
890
891
SWECOM 87 IEEE 2014

Table B22
Software Measurement Skill Sets and Activities by Competency Level
Plan 1. Participate in 1. Define attributes

measurement identifying of the process and
process measures for an product measures
organization (P) to be used
throughout an
organization (C)
1.Particilate in 2. Lead 2. Develop new
identifying identification of ways to identify
measurement needs measurement needs measurement needs
for a project or for a project or (C)
program (P) program (L)
2. Assist in selecting 3. Select measures 3. Define new
measures and and measurement measures and
measurement scales scales (L) measurement
(A) scales (C)
3. Establish data 4. Review and 4. Develop new
collection and approve data data collection and
analysis methods (P) collection and analysis methods
analysis methods (C)
(L)
4. Participate in 5. Set target values
setting target values and thresholds (L)
and thresholds (A)
5. Participate in 6. Establish report 5. Develop new
establishing report formats and report formats and
formats and reporting reporting
reporting procedures procedures (L) procedures (C)
(P)
6. Identify 7. Review and 6. Identify new
measurement tools approve measurement tools
and manual measurement tools and manual
procedures (P) and manual procedures (C)
procedures (L)
1. Assist in 7. Plan for data 8. Review and
planning for data storage (P) approve plan for
storage (A) data storage (L)
SWECOM 88 IEEE 2014

Table B22
Software Measurement Skill Sets and Activities by Competency Level
2. Assist in 8. Select data 9. Approve data

selecting data collection and collection and
collection and analysis methods (P) analysis methods
analysis methods (L)
(A)
1. Procure and 3. Assist in 9. Select 10. Approve
install identifying measurement tools measurement tools
measurement measurement and manual and manual
tools (L) tools and manual procedures (A) procedures (A)
procedures (A)
Perform 1. Use 1. Use manual 1. Lead and 1. Periodically
measurement measurement procedures to coordinate the review methods,
process tools to collect collect data (P) measurement tools, and
data (P) process (L) techniques used to
perform the
measurement
process (C)
2.Maintain valid 2.Assist in 1. Validate collected 2. Approve tactical 2. Modify existing
data in a validating data (P) improvements to and develop new
repository (P) collected data the measurement review methods,
(A) process (L) tools, and
techniques used to
perform the
measurement
process (C)
3. Generate and 3. Identify and
distribute reports recommend
(P) improvements to
the measurement
process (A)
893
894
SWECOM 89 IEEE 2014

895 23.HumanComputerInteractionSkillArea
896 Design of Human Computer Interfaces (HCI) has been traditionally regarded as part computer
897 science and part human factors. Software engineers have, by necessity, become increasingly
898 involved in the development cycle of HCI analysis, design, implementation, evaluation, and
899 deployment because the user interface is often the difference between a successful product and a
900 product that is difficult to use or is not used. To the user, the interface is the system.
901 This skill area covers skills and activities specific to development of HCIs; however there is a
902 great deal of similarity to other skill areas. For example, requirements elicitation for HCIs has
903 some commonalities with conventional elicitation but there are some requirements gathering
904 skills that are particular to the development of human computer interfaces. Some activities are
905 unique to HCI; for example, the activities of Interaction Style Design.
906 References
907 [Buxton 2007] Bill Buxton, Sketching User Experiences: Getting the Design Right and the Right
908 Design, Morgan Kaufmann Publishers, 2007.
909 [ISO 9241-210:2010] ISO 9241-210:2010, Ergonomics of Human-System Interaction, ISO, 2010.
910 [ISO/IEC 25060:2010] ISO/IEC 25060:2010, Systems and Software EngineeringSystems and
911 Software Product Quality Requirements and Evaluation (SQuaRE)Common Industry Format
912 (CIF) for Usability: General Framework for Usability-Related Information, ISO, 2010.
913 [Rogers 2011] Y. Rogers, H. Sharp, and J. Preece, Interaction Design: Beyond Human Computer Interaction, 3rd
914 ed.,Wiley, 2011.
917
918
SWECOM 90 IEEE 2014

919 Table A23
HCI Skill Sets HCI Activities
Requirements Identify stakeholders who provide HCI
requirements
Determine process model for HCI
development
Select HCI related tools
Identify target users and their attributes
Develop user interface requirements
Identify constraints on user interface
implementation
Prototype to elicit requirements
Specify applicable standards
Specify Identify interface requirements
between user interface and system
components
Interaction Style Design Identify metaphors and conceptual models
Identify interaction mode(s)
Document primary and exception use case
scenarios
Develop interaction dialogs
Develop models and prototypes for
interaction flow
Design input error handling
Establish two-way traceability to user
interface requirements, test scenarios, and test
cases
Refine existing and develop new prototypes
Design technical interfaces between the user
interface and other system components
Visual Design Design page/screen layout
Select icons
Design menus
Select color theme and font styles and sizes
Develop mock-ups and sketches of screens
Usability Testing Test user interface with a usability checklist
Identify and obtain representative test
subjects
Design usability tests
Conduct usability tests with users
Analyze and report results of usability testing
Accessibility Determine accessibility needs of special
needs users (e.g., colorblindness, physical
disabilities, hearing or vision loss)
SWECOM 91 IEEE 2014

Test for special needs user accessibility
Utilize tools and techniques to provide
accessible interface elements
920
921
SWECOM 92 IEEE 2014

Table B23
HCI Skill Sets and Activities by Competency Level
Practitioner Engineer
Skill Sets
Requirements 1. Identify 1. Review 1. Coordinate work 1. Modify
stakeholders to identification of activities for existing and
provide HCI stakeholders stakeholder create new
requirements (P) providing HCI identification (L) methods and
requirements (P) tools for
stakeholder
Determine which identification
Assist in selecting process model (C)
process model for approach will be
HCI interface used by the HCI
development (P) team to develop the
interface (L)
Recommend HCI
tools for project use Select HCI tools for
(A) project use (P)
1. Assist in 2. Identify target 2. Review and refine 2. Modify
identifying users and their target user existing and
target users (A) attributes (P) identification and create new
describe their methods and
relevant attributes tools for target
(P) user
identification
(C)
3. Assist in 3. Lead 2. Lead review and
identifying user identification of user refinement of user
interface interface interface
requirements (A) requirements (L) requirements (L)
2. Follow 4. Design and 4. Review and refine 3. Modify
directions to create prototypes prototypes, test for existing and
create simple for use in eliciting elicitation and refine create new
prototypes for user interface user interface methods and
use in eliciting requirements (P) requirements (P) tools for
user interface prototyping (C)
requirements
(F)
5. Use prototypes to
elicit and refine user
interface
SWECOM 93 IEEE 2014

requirements (P)
6. Identify technical 3. Identify
interface constraints on user
requirements interface
(between user implementation (L)
interface and system
components) (P)
7. Design the details 4. Define the 4. Modify
of the technical technical interface existing and
interface requirements create new
requirements (between user methods and
(between user interface and tools for
interface and system system specifying
components) (P) components)(L) technical
interface
requirements (C)
5. Select applicable
standards (L)
Interaction 1. Follow 1. Document use 1. Review and refine 1. Lead and 1. Modify
Style Design instruction to cases, scenarios, use cases, scenarios, coordinate existing and
assist in interaction dialogs interaction dialogs interaction style create new
documenting and storyboards and storyboards (L) design activities (L) methods and
use cases, (P) tools for
scenarios, interaction style
interaction design (C)
dialogs and
storyboards (F)
2. Assist in 2. Assist in 2. Identify user input 2. Select and refine
identifying identifying user errors and error user error handling
user input input errors and handling approaches approaches (P)
errors (A) error handling (P)
approaches (A)
3. Assist in 3. Apply metaphors 3. Select metaphors
identifying and conceptual and conceptual
interaction modes models to define models (L)
(A) interaction style (P)
4. Identify and 4. Work with the 2. Modify
refine interaction system design team existing and
modes (P) to establish create new
component methods and
interfaces between tools for
user interface and interaction style
system components design (C)
(L)
SWECOM 94 IEEE 2014

3. Document 4. Establish two-
two-way way traceability
traceability to between use cases,
requirements scenarios,
and to test interaction dialogs
cases and test and storyboards
scenarios (P) and specific user
interface
requirements and
acceptance criteria
(P)
4. Follow 5. Develop 5. Review and refine
directions to interface interface prototypes
develop or prototypes (P) (P)
refine interface
prototypes (F)
Visual Design 1. Assist in 1. Design 1. Revise / approve 1. Modify
designing page/screen layout final page/screen existing and
page/screen layout (P) layouts (L) create new
(A) methods and
tools for Visual
Design (C)
2. Assist in 2. Select from 2. Revise / approve
selecting from existing icons and icons and identify
existing icons and design new icons (P) new icons as
designing new needed (L)
icons (A)
3. Assist in 3. Select color 3. Revise / approve
selecting color theme, and font color theme, and
theme, and font styles and sizes (P) font styles and sizes
styles and sizes (L)
(A)
4. Assist in menu 4. Design menus (P) 4. Review and
design (A) refine menu design
(L)
5. Review selections 5. Approve visual
for color theme, and design components
font styles and sizes and review design
and check selection with stakeholders
against applicable and/or target users
standards (P) (L)
1. Follow 5. Create mock- 6. Review and revise
instructions to ups and sketches mock-ups and
assist in (P) sketches (P)
creation of
SWECOM 95 IEEE 2014

mock-ups and
sketches (F)
Usability 1. Analyze a 1. Select and tailors 1. Lead and 1. Modify
Testing design with a one or more coordinate activities existing and
usability checklist usability checklists of Usability Testing create new
(P) (P) (L) methods and
tools for
usability testing
(C)
2. Assist in 2. Identify 2. Approve
identifying representative test selection of one or
representative test subjects from target more usability
subjects from user group (F) checklists (L)
target user group
(A)
3. Assist in 3. Review results of
obtaining test checklist analysis
subjects (A) and recommend
design changes (P/F)
4. Obtain test 3. Approve
subjects (P) selection of test
subjects (L)
Write user tests 4. Assist in 5. Design usability 4. Review, refine
that evaluate designing usability tests (P) and finalize
user behavior tests (A) usability tests (L)
(A)
1. Assist in 5. Conduct 6. Supervise
conducting usability tests and usability testing
usability tests collect data (P) (P/L)
and collecting
data (A)
2. Follow 6. Analyze results 5. Make 5. Review and
instructions to of usability testing recommendations approve
assist in (P) based on analysis of recommendations
analyzing usability testing and results of
results of results (P) usability testing (L)
usability
testing (F)
Accessibility 1. Assist in 1. Identify 1. Lead and 1. Develop new
identify accessibility needs coordinate tools and
accessibility needs for user interfaces accessibility techniques for
for user interfaces (P) activities (L) providing
(A) accessible
interface
SWECOM 96 IEEE 2014

elements (C)
2. Develop 2. Determine which
acceptance criteria accessibility needs
and tests for must be addressed
accessibility aspects in the user interface
of user interface (P) (L)
2. Assist in 3. Identify the needs 3. Determine the
identifying the for international extent to which the
needs for accessibility user interface must
international (languages, cultural accommodate needs
accessibility considerations, etc.) for international
(languages, (P) accessibility (L)
cultural
considerations,
etc.) (A)
3. Use the selected 4. Select tools and
tools and techniques for
techniques for providing the
implementing required
required accessibility (P)
accessibility (A)
923
SWECOM 97 IEEE 2014

924 24.AppendixA:Contributors
925 SWECOMTeamMembers
926 Mark Ardis, Stevens Institute of Technology
927 Dick Fairley, Software and Systems Engineering Associates (S2EA), Team Leader
928 Thomas Hilburn, Embry Riddle University
929 Ken Nidiffer, Software Engineering Institute
930 Massood Towhidnejad, Embry Riddle University
931 Mary Jane Willshire, Software and Systems Engineering Associates (S2EA)
932 Kate Guillemette, IEEE Computer Society
933 Interviewees
934 Elias Abughazaleh, Quality Assurance Director, Symantec Corporation

935 Laura Jordan, Technical Support Manager, Symantec Corporation
936 Matthew Larson, Software Development Manager, Symantec Corporation
937 Stephen Link, Chief Systems Engineer, Harris Corporation
938 Kim Madler, Software Development Director, Symantec Corporation
939 Thomas Schabowsky, System Engineer and Architect, Harris Corporation
940 SubjectMatterReviewers
941 Alain Abran, cole de technologie suprieure (TS)
942 Bob Aiello, CM Best Practices Consulting
943 Radu Babiceanu, Embry-Riddle Aeronautical University
944 Wayne Babich, Charles River Development
945 Pieter Botman, True North Systems Consulting
946 Nick Brixius, Embry-Riddle Aeronautical University
947 Drew Calhoun, Lockheed Martin
948 Cynthia Calongne, Colorado Technical University
949 Don Gelosh, Worcester Polytechnic Institute
950 Shafagh Jafer, Embry-Riddle Aeronautical University
951 Andrew Kornecki, Embry-Riddle Aeronautical University
952 Susan K. Land, Missile Defense Agency
953 Phil Laplante, Pennsylvania State University
954 Nancy Mead, Software Engineering Institute
955 Mark Merkow, Charles Schwab
956 Donald Reifer, Reifer Consultants LLC
957 Annette Reilly, Lockheed Martin
958 Leanna Rierson, Digital Safety Consulting
959 Linda Shafer, IEEE Press
960 Richard Hall Thayer, California State University
961 Steve Tockey, Construx
SWECOM 98 IEEE 2014

962 Janusz Zalewski, Florida Gulf Coast University
963
964
965 PublicReviewers
966 xxx
967
SWECOM 99 IEEE 2014

968 25.AppendixB:SWECOMIntendedAudiences
969 The intended audiences for this software systems engineering competency model (SWECOM)
970 include individual software and systems engineering practitioners, their managers, and workforce
971 planners. Others who may find these models to be useful are also indicated.
972 Software engineering and systems engineering practitioners will use SWECOM for self-
973 evaluation, self-improvement, and for career planning. In addition, practitioners can use a
974 competency model to provide guidance in selecting academic programs and training classes.
975 SWECOM can also provide a framework for discussions with leaders and supervisors.
976 Managers of practitioners will use SWECOM to select skills at various skill levels and
977 group them into job roles and job descriptions, to establish performance criteria, and as an
978 objective basis for performance evaluations and development of career paths for individual
979 practitioners, and to perform gap analysis.
980 Work force planners will use SWECOM to develop skills inventories and perform gap
981 analysis, to prepare workforce development plans, to define career ladders, and to select and hire
982 employees, contract personnel, and contractor organizations.
983 Curriculum designers will use SWECOM to design competency-based education and
984 training curricula.
985
986 Others who may find PAB competency models to be useful include:
987 IEEE Computer Society: for certification (EAB training and PAB exams), standards preparation,
988 services to industry (training and consulting), curriculum development, assistance to schools and
989 industry for development and assessment of professional development programs, and as a source
990 of authoritative credentials and credibility in the computing professions.
991 Other professional societies: to determine common interests, overlaps, and boundaries.
992 Legislative and legal bodies: to provide guidance for licensing criteria.
993 Regulatory agencies: guidance in establishing regulations that impact the health, safety, and
994 welfare of the general population.
995 Others: may find novel uses for SEWCOM not envisioned by the developers.
996 Society at large: a model for increasing the number of competent software and systems
997 engineering professionals.
998
SWECOM 100 IEEE 2014

999 26.AppendixC:SWECOMUseCases
1000 UseCase#1:UsingSWECOMtoCreateaNewHireJobDescriptionandScreenJobCandidates
1001 Goal: An organization will use SWECOM to create a job description and hire personnel.
1002 Actors: A hiring manager and human resource personnel
1003 Preconditions and Assumptions:
1004 1. There is a need to hire additional personnel with specific competencies.
1005 2. The organization has access to SWECOM and the Staffing Gap Analysis worksheet.
1006 Trigger: There is a need to hire additional personnel with specific competencies.
1007 Normal Flow:
1008 1. A manager has identified a need for additional personnel.
1009 2. The manager uses SWECOM and the Staffing Gap Analysis worksheet to identify the needed
1010 skills.
1011 3. The manager in collaboration with human resource personnel develops a job description to
1012 be posted.
1013 4. Human resource personnel conduct an initial screening of the applicants, using the job
1014 description and competency model as a guide.
1015 5. The manager and/or human resource personnel use SWECOM to choose the best candidate
1016 who meets the needs of the organization.
1017 Post Conditions:
1018 1. The organization has identified the needed skills.
1019 2. The organization has hired an employee who best matches the needed skills.
1020
1021

1022 UseCase#2:EmployeeUsingSWECOMforSelfImprovement
1023 Goal: An employee will use SWECOM to evaluate his or her software systems engineering
1024 competencies for the purposes of self-evaluation and improvement.
1025 Actor: A software engineer working in a software industry.
1027 1. The employee has identified an interest in software systems engineering.
1028 2. The employee has access to SWECOM and the Individual Gap Analysis worksheet.
1029 Trigger: The employee wants to conduct a self-evaluation of his/her own capabilities in
1030 software systems engineering and/or is interested in improving his or her capabilities in software
1031 systems engineering in order to reach a higher level of competency.
1032 Normal Flow:
1033 1. The employee has identified the software systems engineering skills he or she is interested in
1034 to conduct self-evaluation.
1035 2. The employee conducts a self-evaluation against each activity in the skills of interest.
1036 3. The employee identifies his or her current competencies.
1037 4. The employee uses the Individual Gap Analysis Worksheet to document his or her
1038 competencies for the selected skills.
1040 1. The employee has a good understanding of his or her current competency levels.
1041 2. The employee has a good understanding of activities to be improved to reach the desired
1042 competency levels for those activities.
1043

1044 UseCase#3:ManagerUsingSWECOMforEvaluationandImprovementPlanningforTeam
1045 Member
1046 Goal: A technical manager will use SWECOM and the Staffing Gap Analysis worksheet to
1047 evaluate a member of his or her team and/or develop an improvement plan for the team member.
1048 Actor: Technical Manager
1050 1. The team member to be evaluated or guided has been identified.
1051 2. The team members areas of expertise or his or her roles and responsibilities in the team have
1052 been identified.
1053 3. The manager has access to and familiarity with SWECOM and the Staffing Gap Analysis
1054 worksheet.
1055 Trigger: The manager has identified the need to assess the team members competencies and/or
1056 develop an improvement plan to guide him or her in advancement.
1057 Normal Flow:
1058 1. The manager has identified skill areas that apply to the team members present and future
1059 roles and responsibilities.
1060 2. The result of the gap analysis will be used as part of the team members evaluation and
1061 preparation of an improvement plan.
1063 1. The manager has completed the evaluation of the team member.
1064 2. The manager and team member have met to discuss the managers evaluation of the team
1065 members present competencies and competencies needed in the future.
1066 3. The team member has a good understanding of what he or she needs to improve in order to
1067 eliminate the existing gap between his or her present competencies desired competencies.
1068

1069 UseCase#4:CurriculumDesignerUsingSWECOMtoPrepareaCompetencyBasedCurriculum
1070 Goal: A curriculum designer will use SWECOM to prepare an academic or training curriculum
1071 for one or more of the SWECOM skills or skill areas, to achieve the desired level of competency
1072 for each skill or skill area.
1073 Primary Actor: Curriculum Designer
1074 Secondary Actor: the sponsoring academic or industrial organization.
1076 1. The skill area, or skill areas, and the level, or levels, of competency to be achieved have been
1077 identified.
1078 2. The curriculum designer has access to and familiarity with SWECOM and the Staffing or
1079 Individual Gap Analysis worksheet.
1080 Trigger: An academic or industrial organization has identified the need to improve identified
1081 competencies of students or employees and has commissioned a curriculum designer to prepare a
1082 competency-based curriculum for one or more skills or skill areas at stated level, or levels, of
1083 competency to be achieved.
1084 Normal Flow:
1085 1. The curriculum designer conducts a gap analysis to determine the skills that candidate
1086 students or employees currently have, the learning outcomes to be achieved and
1087 demonstrated, and the gap to be closed by education and/or training.
1088 2. The curriculum designer prepares the curriculum, to include topics to be covered, reference
1089 materials, facilities needed, and the learning outcomes to be demonstrated.
1090 3. The curriculum designer presents the curriculum to the academic or industrial organization
1091 and makes requested changes.
1093 1. The curriculum designer has completed preparation of the desired curriculum.
1094 2. The academic or industrial organization has reviewed and approved the curriculum, perhaps
1095 after requested revisions are made by the curriculum designer.
1096 3. The result curriculum is suitable as a basis for designing courses, preparing materials, and
1097 acquiring necessary facilities and resources.
1098

1099 27.AppendixD:GapAnalysisWorksheets4
Staffing Gap Analysis Worksheet
Date: [xxx]
Organizational Unit: [xxx]
Completed by: [names and titles of those completing the worksheet]
Note: analysis may be at the level of skill area or skill
Note: Have, Need, and Gap are indicated by number of individuals and
competency level
Competencies (from Table A of the SWECOM Skill Areas)

Skills: Have Need Gap
Software Requirements Skills
Software Requirements Elicitation
Software Requirements Specification
Software Requirements Verification
Software Requirement Management
Software Design Skills
Software Design Fundamentals
Software Architectural Design
Software Design Quality Analysis and Evaluation
Software Construction Skills
Software Construction Planning
Detailed Design and Coding
Debugging and Testing
Integrating and Collaborating
Software Sustainment Skills
Software Transition
Software Support
Software Maintenance
4
Excel spreadsheets for individual and staff gap analysis are at:
Individual Gap Analysis Worksheet: https://computer.centraldesktop.com/p/eAAAAAAACjPRAAAAAEMv3og
Staffing Gap Analysis Worksheet: https://computer.centraldesktop.com/p/eAAAAAAACjPWAAAAAE91mog

Software Process Model and Life Cycle Model Skills
Software Development Life Cycle Models
Process Implementation and Management
Process Assessment and Improvement
Software System Engineering Skills
System Development Life Cycle Modeling
Concept Definition
Software-Intensive Systems Engineering
System Design
Requirements Allocation and Flowdown
Component Engineering
Software Quality Skills
Software Quality Management
Reviews, Walkthroughs, and Inspections
Testing & Demonstration
Independent Process and Product Audits
Statistical Control
Software Security Skills
Requirements
Design
Construction
Testing
Process
Quality
Software Safety Skills
Requirements
Design
Construction
Testing
Process
Quality
Software Configuration Management Skills
Plan SCM
Conduct SCM
Software Measurement Skills
Plan Measurement Process
Perform Measurement Process
Human-Computer Interaction Skills

Requirements
Visual Design
Usability Testing
Accessibility
1100
1101

Individual Gap Analysis Worksheet
Gap Analysis for: [name of individual]

Date Completed: [xxx]
Names and titles of other participants:
[xxx]
Note: Have indicates that competencies for all activities for a skill at the
indicated level have been demonstrated and Gap indicates the difference
Note: Need includes the activity numbers for which competency must be
demonstrated to advance to the next level for that skill
Competencies (from Tables A and B of the SWECOM skill areas)
Skills: Have Need Gap

Software Requirements Skills
Software Requirements Elicitation
Software Requirements Specification
Software Requirements Verification
Software Requirement Management
Software Design Skills
Software Design Fundamentals
Software Architectural Design
Software Design Quality Analysis and Evaluation
Software Construction Skills
Software Construction Planning
Detailed Design and Coding
Debugging and Testing
Integrating and Collaborating
Software Sustainment Skills
Software Transition
Software Support
Software Maintenance
Software Process Model and Life Cycle Model Skills

Software Development Life Cycle Models

Process Implementation and Management
Process Assessment and Improvement
Software System Engineering Skills
System Development Life Cycle Modeling
Concept Definition
Software-Intensive Systems Engineering
System Design
Requirements Allocation and Flowdown
Component Engineering
Software Quality Skills
Software Quality Management
Reviews, Walkthroughs, and Inspections
Testing & Demonstration
Independent Process and Product Audits
Statistical Control
Software Security Skills
Requirements
Design
Construction
Testing
Process
Quality
Software Safety Skills
Requirements
Design
Construction
Testing
Process
Quality
Software Configuration Management Skills
Plan SCM
Conduct SCM
Software Measurement Skills
Plan Measurement Process
Perform Measurement Process
Human-Computer Interaction Skills
Requirements
Visual Design

Usability Testing
Accessibility
1102
1103
1104
1105
1106

SWECOM Public Review PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SWECOM Public Review PDF

Загружено:

Авторское право:

Доступные форматы

1 TheSoftwareEngineeringCompetency

SWECOM 2 IEEE 2014

SWECOM 3 IEEE 2014

SWECOM 4 IEEE 2014

SWECOM 5 IEEE 2014

SWECOM 6 IEEE 2014

SWECOM 7 IEEE 2014

SWECOM 8 IEEE 2014

Software Sustainment Skills Software Transition

SWECOM 9 IEEE 2014

SWECOM 10 IEEE 2014

SWECOM 11 IEEE 2014

SWECOM 12 IEEE 2014

SWECOM 13 IEEE 2014

SWECOM 14 IEEE 2014

SWECOM 15 IEEE 2014

SWECOM 16 IEEE 2014

SWECOM 17 IEEE 2014

SWECOM 19 IEEE 2014

SWECOM 20 IEEE 2014

SWECOM 21 IEEE 2014

SWECOM 22 IEEE 2014

SWECOM 23 IEEE 2014

requirements verification (P/L)

SWECOM 24 IEEE 2014

SWECOM 25 IEEE 2014

516 Table B12

SWECOM 26 IEEE 2014

SWECOM 27 IEEE 2014

SWECOM 28 IEEE 2014

2. Carries out 2. Leads static

SWECOM 29 IEEE 2014

SWECOM 30 IEEE 2014

SWECOM 31 IEEE 2014

Software 1. Assists in the 1. Selects 1. Creates or

SWECOM 32 IEEE 2014

management (A) management (P)

2. Refactors code 2. Suggests and 2. Creates new

SWECOM 33 IEEE 2014

errors and threats errors and threats

SWECOM 34 IEEE 2014

SWECOM 35 IEEE 2014

SWECOM 36 IEEE 2014

SWECOM 37 IEEE 2014

568 Table B14

Software 1. Identify unit 1. Identify 1. Establish 1. Establish

SWECOM 38 IEEE 2014

SWECOM 39 IEEE 2014

system is ready cases. (L/P)

SWECOM 40 IEEE 2014

intensity, etc. (P) intensity, etc. (L)

SWECOM 41 IEEE 2014

SWECOM 42 IEEE 2014

SWECOM 43 IEEE 2014

System Transition 1. Participates in 1. Leads 1. Modifies

SWECOM 44 IEEE 2014

transition and operational software

SWECOM 45 IEEE 2014

SWECOM 46 IEEE 2014

responds to software help software help desk policies that

SWECOM 47 IEEE 2014

4. Assists in 3. Performs change 2. Leads problem

4. Implements plans 3. Leads 2. Modifies