As a systems engineer you must be aware that the software development process is its own monster. While software engineers will write the code itself, the act of writing the code itself should only be about 30% of the software engineering effort. The other 70% will be spent handling requirements, preliminary design, modeling, prototyping, critical design, design reviews, data analysis, integration and testing. These are all areas that the systems engineer should have some part in.
The complexities, intricacies and interdependences of all the all of the small pieces of functional software and large complex systems of software can wreak havoc on a program if not understood and respected for the difficulty it can pose. While the software engineers themselves will do the heavy lifting of designing and implementing the software architecture, the systems engineer must have a firm grasp and understanding of the processes that must be adhered to in the software development to ensure successful execution. Otherwise the whole project can go off the rails quickly. The project could incur massive amount of monetary and schedule overruns or even worse the program could entirely fail. This course takes a high level walk through some important areas while at the same time giving references to more in-depth material should the student wish to take a deeper dive or simply have for later reference.
The course first takes a look at the different types of development process one might encounter (spiral, waterfall, agile, etc). Each has their different phases and each of these has their place depending on the industry/project/company that one works for. Their benefits and deficiencies are discussed. The student will then walk through some of the process phases, starting with the gathering of requirements. Lectures and examples will discuss how to find the voice of the customer and how to elicit the needs and desire of the customer to ensure that the requirements and the ultimate design will meet their needs.
Following requirements, we move into design. This course will hammer home the need for strict and stringent design and design documentation. Robust design documentation is one of the most critical, and often overlooked, aspects of software engineering design. Without proper documentation the design cannot be sufficiently reviewed to ensure that it is proper and meets all the program needs. Having the design documentation fully fleshed out also ensures that your design doesn’t have holes in it that will not be found or understood until the coding phase or even worse until the integration phase. Along those lines, the course will take and in-depth look at the need for design review and inspection either iteratively through the process or are dedicated milestones.
Ending off the topics is an extensive look at “defects.” Defects are not necessarily errors or bugs, but are, more generally, anything that needs to be adjusted or changed for any reason throughout the lifecycle of a program. These defects came with a cost as in order to remediate them one must spend more money and take more time than originally planned. The cost of these changes grows as the program progresses along its timeline because the later you find the defect the more work there is that has been built in and around that defect. Therefore the goal is to find all defects as early in the process as possible, be it in the program “Vision” itself, or the requirements, or the early design. Not finding these defects until the program has completed and the product fielded would be the worst and most costly situation.
As a final step in the course, the concept of Orthogonal Defect Classification (ODC) will be discussed. This is a way to track and analyze the defects found on a program for the purpose of gaining an overarching insight into areas of the program/process/company/culture/etc that can be addressed for the purpose of process improvement which can in turn vast amounts of money.
Ford Ennis, Nov 2020