Keynote Speaker: Pierre Bourque

Prof. Dr. Pierre Bourque

Pierre Bourque is a faculty member since 2000 in the Department of Software and IT Engineering of the École de technologie supérieure (ÉTS) of the Université du Québec. He is presently on sabbatical (2019-2020) in industry at CGI after being Dean of Studies at ÉTS (2013-2019). He is also lead co-editor of the Guide to the Software Engineering Body of Knowledge (SWEBOK) V3 published in 2014 and was co-editor of the 2001 and 2004 versions. He received his Ph.D. from the University of Ulster (Northern Ireland). Prior to his appointment at ÉTS, he was involved in software engineering, data modeling, and database design at the National Bank of Canada and the Université du Québec à Montréal (UQAM).

The SWEBOK Guide—More Than 20 Years Down the Road

The proof of concept document of the Guide to the Software Engineering Body of Knowledge (SWEBOK) was made available in 1998—now more than 20 years ago. The speaker has played a key role in all published versions, as lead author of the proof of concept document or Straw Man version [1], co-editor of the Trial Version published in 2001 [2] and of the 2004 version [3], and lead editor of most recent version, SWEBOK Version 3.0, published in 2014 [4]. In this talk, the keynote speaker will reflect on the impact of the SWEBOK Guide, make some observations about its current content after recently spending a year in industry, and provide some remarks on moving forward.

The software engineering body of knowledge itself already exists in the published literature. The purpose of the SWEBOK Guide is to describe what portion of this body of knowledge is generally accepted, to organize that portion and to provide a topical access to it.

As stated in the Straw Man version [1], the SWEBOK Guide project was established with the following five objectives:

  • To characterize the contents of the software engineering body of knowledge;
  • To provide topical access to the software engineering body of knowledge;
  • 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 provide a foundation for curriculum development, individual certification, and licensing material.

As also stated in the Straw Man version [1], the intended audience for the SWEBOK Guide comprises the following groups:

  • Public and private organizations wishing to use and promote a consistent view of software engineering internally, notably when defining education and training, job classification and performance evaluation policies;
  • Practicing software engineers wishing to enhance their professional skills;
  • Makers of public policy engaged in defining software engineering licensing rules and guidelines for professionals;
  • Professional societies engaged in defining software engineering university program accreditation guidelines, and certification rules and guidelines for professionals;
  • Software engineering students learning the discipline;
  • Educators and trainers engaged in defining curricula and course content;
  • Researchers looking for an agreed-upon framework when discussing their work.

Using the initial project objectives and intended audience as a framework, this keynote presentation will reflect on the impact of the SWEBOK Guide through some selected examples of its use. The speaker will then make some observations about the current content of the SWEBOK Guide, having recently completed a sabbatical year in industry. These observations include a shift toward operations management rather than project management, coverage of a somehow forgotten component of the definition of software engineering, an emphasis on process discipline that is not through maturity models, and some significantly overlapping bodies of knowledge. The speaker will then provide some remarks on some of the challenges on moving forward the SWEBOK Guide, notably in terms of better coverage but also with regard to setting boundaries with other categories of knowledge within software engineering, with many other bodies of knowledge, and with the growing number of related disciplines.