Guide to the Software Engineering Body of Knowledge

Guide to the Software Engineering Body of Knowledge Chapter 1 - Introduction

Initiation • Sponsored by IEEE Computer Society & ACM • Development began in 1998 • Supported by major IT, research and professional organizations – Boeing – Rational Software – Construx Software – MITRE Corporation – Raytheon Systems – SAP Labs-Canada – National Institute of Standards and Technology – National Research Council of Canada – the Canadian Council of Professional Engineers

Development Phases • Strawman – Early prototype showing how the guide might be organized • Stoneman – Ended in 2001 with the release of the Trial Version • Ironman – Ended in 2004 with the release of the SWEBOK Guide

Audience Organizations needing a consistent view of SWE Defining jobs and training requirements Classifying jobs Performance evaluation policies Specifying software development tasks Software Engineers Managers of Software Engineers Public policy officials responsible for licensure and professional guidelines • Professional societies and educators defining certification rules, accreditation policy and guidelines for professional practice • Students learning SWE • Educators and trainers • •

Objectives • To promote a consistent view of software engineering worldwide • To clarify the place—and set the boundary—of software engineering with respect to other disciplines such as computer science, project management, computer engineering, and mathematics • To characterize the contents of the software engineering discipline • Provide topical access to the SWEBOK • To provide a foundation for curriculum development and for individual certification and licensing material

Consistent World View • How do you achieve a consistent world view? – 500 reviewers from 42 countries (Stoneman) – 120 reviewers from 21 countries (Ironman) – Various professional and academic societies were invited to take part

Boundaries • Where does software engineering end and related disciplines begin? • 10 knowledge areas (KAs) recognized – – – – – Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering process Software engineering tools and methods Software quality

Boundaries • 8 related disciplines recognized – Computer engineering – Computer science – Management – Mathematics – Project management – Quality management – Software ergonomics – Systems engineering • Why does a software engineer need to know about these things?

Characterization of Contents of SWE • Hierarchical organization – Subareas – Topics – Sub-topics • Follows same structure and breakdown as major schools of thought, industry, SWE literature and standards • Does not presume specific application, business uses, philosophies, etc. – Why not?

Topical Access to SWEBOK • Identifies reference materials for each knowledge area – Books, papers, chapters, web sites, etc • Matrix relating reference material to listed topics • Intended to be suitable for mastery with an undergraduate education plus four years of experience • Can you think of any other professions that follow a similar approach?

Curriculum Development • Three categories of knowledge – Generally accepted knowledge “The generally accepted knowledge applies to most projects most of the time, and widespread consensus validates its value and effectiveness. ” – PMI definition – Specialized • Applicable in certain situations – Advanced and Research • Innovative practices not having reached maturity • Generally accepted knowledge should be included in SWE licensing exam

Why does SWE Need This? • Recognition as a profession • What is required to be a recognized profession? • Exercise – List 3 “professions” that you think satisfy the definition

Ordering of KAs • First 5 in waterfall order – What does this imply? • Remaining KAs and related disciplines are alphabetical

KA Description Structure • Introduction – Brief definition of the KA and an overview of its scope and relationship with other KAs • Topic Breakdown – Core of the description – Describes decomposition into subareas, topics and sub-topics – Matrix links topics to reference material • List of recommended references

Knowledge Area Overview • Requirements KA – – – Fundamentals Process Elicitation Specification Validation Practical considerations

Knowledge Area Overview • Design KA – Fundamentals – Key Issues • Data persistence, distribution, exception handling etc. – – Structure & Architecture Quality analysis & evaluation Design notations Strategies & methods • OO, structured, etc.

Knowledge Area Overview • Construction (Implementation) KAs – Fundamentals – Managing construction • Planning & measurement – Practical considerations • Languages, reuse, testing, integration, etc.

Knowledge Area Overview • Testing KAs – Fundamentals – Test levels – Test techniques • Usage-related, code-based, etc. – Test-related measures – Test process

Knowledge Area Overview • Maintenance KAs – Fundamentals – Key issues • Cost estimation, management, etc. – Maintenance process – Techniques • Reengineering, reverse engineering, etc.

Knowledge Area Overview • Configuration management KAs – “SCM is the discipline of identifying the configuration of software at distinct points in time for the purpose of systematically controlling changes… and maintaining integrity and traceability…throughout the system life cycle” – Version control – Allows for management of releases – Rollback to last stable version – ‘Change management’ is virtually synonymous

Knowledge Area Overview • Tools & methods KAs – Tools – Methods • Heuristic, formal, prototyping

Knowledge Area Overview • Quality KAs – Fundamentals – Quality management processes – Practical considerations • Defect characterization, measurement, requirements, etc.

• • Sponsored by IEEE & ACM In progress since 1993 Supported by major IT organizations Outlines SWE – Knowledge areas (KAs) – Recommended best practices • Baseline body of knowledge • Guide to the SWE literature • Handy quick reference

• SWEBOK establishes boundary of SWE profession • Divides SWE into Knowledge Areas (KAs) and closely related disciplines (e. g. , Project management) • SWE is NOT computer science – Scientists study laws of nature – Engineers apply laws of nature to build useful solutions to pressing problems

• SWEBOK vs. IT – IT more concerned with specific technologies • OO programming languages • Relational databases • XML parsers – Technology tools obsolesce quickly – SWE must know which tool(s) to use for the job – SWE best practices are developed & documented over time – SWE best practices do not obsolesce rapidly