Brian On Software

The term ‘software engineering’ was coined some forty years ago at the 1968 NATO Software Engineering Conference, in Germany. Software engineering is a new branch in the engineering field when compared to other engineering disciplines such as electrical, mechanical, building and construction engineering. No wonder that most of the world sees the profession of software engineering as an immature and young discipline. Nonetheless, the field of software engineering is very promising. In the last forty years, there has been a large amount of breakthrough, innovation, change, improvement and research in the fields of computer science, mathematics, business, management, leadership, human behaviors, and interactions, which are all pillars that feed and support the engineering practice that we call ‘software engineering’ today. As you may or may not know, a liberal profession is more often based on failures rather than success, and as you should know, there have been many failures in the area of software engineering and development. However, most of these failures have been documented in order to avoid repeating them, but most importantly their solutions have also been documented. As I said earlier, the discipline of software engineering encompasses areas related to computer science, mathematics, business, management, leadership, etc. That being said, there are currently many roles that a person can play in a typical software project today. In fact, if you search for ‘software’ as a search criteria for an employment opportunity in Monster or Workopolis, you will see what I mean. Most popular roles in a typical software projects include software project manager, business analyst, software architect, specialist in software quality assurance, software tester and software engineer (or software designer, software developer). A good question to ask ourselves (especially if you’re involved in HR or recruitment) is “How do I know what this specific role will do and won’t do in this project?”. Another question can be “What should I expect this person to know in order for him or her to perform well at this position?”. Fortunately, some smart people have taken time to answer these kinds of questions. In fact, many of the answers can be found in what we call today a Body of Knowledge (BoK). A BoK is "…an aggregate of what is known and understood within a defined field of endeavor due to familiarity gained through experience or association." Did you know there is currently a BoK for each of the roles that were mentioned above? Yep. Today you have a BoK specific to project managers (and even software project managers), business analysts, software architects and other roles. Some of them are in their final publications and others are in draft, but regardless of their state, these BoK are constantly being improved and approved by a committee. Some of them are freely available and others can be purchased. Nevertheless, you can use them today in your own organization to clarify the expected knowledge and activities that a role must support in a project. If you already have a framework available in your organization that guides people in their specific roles, you could use these BoK to improve on what you already have. Furthermore, if you’re interested, you can also participate in developing and improving a BoK that fits with your wisdom and expertise on a specific area. Another thing you might want to know is that there are also worldwide certifications which are solemnly based on these BoK, and which can help you to not only show your expertise in an area, but also to participate in making your profession more professional. I know this is a large post, but I truly believe that taking time to download (or buy) some of the guides related to these Body of Knowledge documents and to read them (alone or in a group) can be very beneficial because not only will you be learning more about your profession, but you will also learn to embrace it and make it better. My tip when reading these kind of documents is to see what makes sense to you and your organization, what you can use, what you could improve and what you can discard to make your projects more successful and your projects’ team members more knowledgeable in their activities. I’ll finish this post with a list of common BoK which might be of great interest if you’re in the software engineering field.

• For project managers, there is the popular Project Management Body of Knowledge (PMBOK) which is regulated by the Project Management Institute. The Guide to the PMBOK is the recommended source of information to pass the Project Management Professional certification.

• For software project managers, there is the Software Project Manager Body of Knowledge (SPMBOK) which is regulated by the Quality Assurance Institute. The Guide to the SPMBOK is the recommended source of information to pass the Certified Software Project Manager certification.

• For business analysts, there is the Business Analysis Body of Knowledge (BABOK) which is regulated by the International Institute of Business Analysis. The BABOK is the recommended source of information to pass the Certified Business Analysis Professional certification.

• For software architects, there isn’t yet an official body of knowledge (as far as I know). Nevertheless, I highly recommend visiting any of these sites which are fully committed in making the profession of software architects more mature: the Worldwide Institute of Software Architects and the International Association of Software Architects.

• For software engineers, there is the Software Engineering Body of Knowledge (SWEBOK) which is regulated by the. The Guide to the SWEBOK is the recommended source of information to pass the Certified Software Development Professional certification and is available in PDF, HTML and hard cover book. I strongly suggest you to listen to the DotNetRocks show with professional software engineer Steve McConnell to have a better view on this type of certification.

• For software quality assurance specialists, there is the Software Quality Assurance Body of Knowledge (SQABOK) which is regulated by the Quality Assurance Institute and the Software Quality Engineering Body of Knowledge (SQEBOK) which is regulated by the American Society for Quality. The Guide to the SQABOK is the recommended source of information to pass the Certified Software Quality Assurance certification. The Guide to the SQEBOK is the recommended source of information to pass the Certified Software Quality Engineering certification.

• For software testers, there is the Software Testing Engineering Body of Knowledge (STEBOK) which is regulated by the Quality Assurance Institute. The Guide of the STEBOK is the recommended source of information to pass the Certified Software Test Engineer certification.

These are the most common, popular and important body of knowledge documents for each of the areas that support a typical software engineering project. Of course there are many more which haven’t been written yet, i.e., the software architecture body of knowledge, but with time and dedication, people like you and me will make this “new branch of engineering” a more solid and respectful one. Feel free to add your comments and provide links to other useful resources related to body of knowledge documents that I may have missed.

Resources:

• "Software Engineering: An Emerging Profession?", an excellent article written by David Alex Lamb which presents the current state of software engineering and where it is heading.

• Software Engineering Professional Certification Programs by Learning Tree International provides a list of other software engineering-related certifications that might be interesting for you.