Welcome
Welcome to the Software Engineering Playbook (SEP), the definitive source of information designed to ensure consistency, efficiency, and excellence across all engineering works.
Whether you're new to Opencast and are getting acquainted with our ways of working or an experienced OC'er seeking to refine your skills, this playbook provides clear, actionable guidance on every aspect of software engineering within Opencast. By following this playbook and welcoming contributions from all, we aim to foster a collaborative environment where quality, innovation, and continuous improvement are paramount.
Please note that this site is auto-generated, so please DO NOT make manual changes to this site. We do however actively encourage people to share their knowledge, so if you wish to help please see the CONTRIBUTING guide.
What is Software Engineering?
Software engineering is the process of developing, testing and deploying computer applications to solve real-world problems by adhering to a set of engineering principles and best practices. The field of software engineering applies a disciplined and organized approach to software development with the stated goal of improving quality, time and budget efficiency, along with the assurance of structured testing and engineer certification.
Opencast pride ourselves on not only our culture and values, but also giving our clients the best possible outcome; So with this in mind our engineering playbook is a comprehensive guide that helps our software teams maintain consistency, quality, and efficiency in their work. This playbook serves as the central repository of principles, standards and best practice that we work to.
Audience
This playbook should be followed by any Opencast consultant delivering software either internally or to any of our clients.
How to use the playbook
To effectively use this playbook, you should start by familiarizing yourself with its structure and contents.
You should refer to the playbook regularly to guide tasks, ensuring alignment with our tried and tested ways of working.
During project planning, the playbook can help in setting clear expectations and provides a reference for troubleshooting and resolving issues.
There will be regular updates to the playbook to ensure it evolves with our needs and industry advancements, maintaining it's relevance and effectiveness in driving high-quality software.
Playbook Structure
This playbook is structured into three distinct levels, each designed to provide guidance that is increasingly specific to the various engineering practices and roles within Opencast.
This tiered structure ensures that all engineering roles have clear, actionable guidance from a high-level that apply to everyone, down to role-specific details that cater to the unique demands of individual roles.
Level 1: Universal
At the foundation, the first level contains principles, standards, and best practices that are applicable to all engineering roles. Whether you are a Software Developer, QA Tester, Platform Engineer, or Data Engineer, these guidelines define the overarching expectations and norms that guide how we approach engineering across all disciplines.
Level 2: Practice-Specific
The second level focuses on practice specific guidance. Each engineering practice Software Development, QA Testing, Platform Engineering and Data Engineering has it's own set of principles, standards, and best practices tailored to the distinct challenges and requirements of that domain.
Level 3: Role-Specific
The third and most detailed level contains role-specific guidance within each engineering practice. These principles, standards, and best practices are designed for specialized roles within each practice, such as a Cloud Engineer in Platform Engineering or a Front-End Developer in Software Development.
Principles
These are high-level factors that should guide our thinking and problem solving. If there is not yet a specific standard defined for your current context, being mindful of the principles should help you create a solution that aligns with Opencast's values.
Standards
These are prescriptive and should be followed by all. There will be times where client standards are different from ours, in these cases we should use our own higher standards where they are not in direct conflict with the clients. Where there is direct conflict we should work with the client to elevate them to our own standards.
Best Practice
These are more detailed recommendations that can improve ways of working and developer experience, but are not mandatory, unlike standards.
Roles and Responsibilities
The RACI matrix below outlines the roles and responsibilities related to the development and maintenance of the Software Engineering Playbook.
This matrix ensures clear distribution of responsibilities and accountability among the team members involved in the development and maintenance of the Software Engineering Playbook.
| Task | Head of Software Delivery | Practice Leads | Consultants |
|---|---|---|---|
| Define playbook objectives and scope | A | R | I |
| Gather best practices and guidelines | I | A | R |
| Draft initial playbook content | C | A | R |
| Review and approve playbook content | A | R | C |
| Conduct peer review of playbook | I | A | R |
| Integrate feedback and finalize playbook | A | R | C |
| Distribute playbook to consultants | A | R | I |
| Conduct training sessions on playbook usage | A | R | C |
| Regularly update playbook with new practices | I | A | R |
| Collect feedback from consultants | A | R | C |
| Evaluate and incorporate feedback into playbook | I | A | R |
| Ensure compliance with playbook standards | A | R | I |
| Maintain version control of playbook | A | R | C |
| Communicate updates to stakeholders | A | R | I |
Legend
- R: Responsible - The person(s) who do the work to complete the task.
- A: Accountable - The person who is ultimately accountable for the correct and thorough completion of the task.
- C: Consulted - The person(s) who provide information for the project and with whom there is two-way communication.
- I: Informed - The person(s) who are kept up-to-date on progress, often only on completion of the task.