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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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 management – Software engineering process – Software engineering tools and methods – Software quality

8. 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?

9. 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?

10. 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?

11. 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

12. 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

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

14. 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

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

16. 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.

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

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

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

20. 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

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

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

23. 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

24. 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

25. 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