1 / 25

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

skyler
Download Presentation

Guide to the Software Engineering Body of Knowledge

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 ofSWE • 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

More Related