Apply Systems Engineering practices
Systems Engineering, defined as the practical application of scientific, engineering, and management skills required to transform a users need into a system configuration that satisfies the need, is much more a philosophy than an engineering discipline. Its basically an approach to solve complex problems.
As modern Systems Engineering largely grew out of NASA's high profile, high-risk projects such as Apollo in the 1960s and 1970s, the foundation is much older. It can be traced back to the late 19th century when traditional reductionism proved not work for biology and nuclear physics. The first formal statements on systems thinking is found in the German Gestalt Theory around 1910. The word gestalt mean an organized whole whose parts belong together.
So, how does this relate to software engineering practices in the 21th century? First of all, agile methods such as SCRUM are based on systems thinking and theory. To understand this, think of the development process as a system whose purpose is to create high quality products under changing circumstances where learning is a key success criteria.
Beyond an improved understanding of the dynamic in agile methods, which practices in systems engineering can be directly applied to improve software development practices? According to Dr. Derek Hitchins systems engineering philosophy is based on the following principles:
1. Systems engineering requires a clear singular mission and goal. I.e. to put man on the moon and return him safely to Earth by the end of the tour.
2. There should be a sound concept of operation from start to finish. I.e. The mission will be executed in phases, marked by transitions. The first phase will place three men in earth orbit.
3. There should be an overall system design that addresses the whole mission from start to finish. I.e. An overall system design is required to ensure there are no weak links in the chain.
4. Overall system design can be partitioned into complementary interacting subsystems. Each subsystem should have its own clear mission and concept of operation. I.e. Each subsystem must be clarely defined in terms of form, fit, function, and interfaces to ensure overall system integrity upon integration.
5. Each subsystem might be developed independently and in parallel with the others, provided that fit, form, function, and interfaces are maintained. I.e. As part of development, each subsystem should be rigorously tested in representative environment.
6. Upon integration of the subsystems, the whole systems should be subject to tests and trials, real and simulated that exposes it to extremes of environment and to hazards such as might be experienced during mission. I.e. The whole system, including the operators and crew should be subjected to rigorous tests and trials.
Applied on a software development these principles might sound:
1. Have a clear scope and purpose of the software.
2. Understand how the software is meant to be used, including how its going to be operated in use, how it should be maintained and further developed.
3. The software must be designed to support all its user's in context of each users tasks.
4. Apply sound functional partitioning to the software.
5. Automated build, test first and continuous integration.
6. Provide relevant training and end user documentation.
Beyond the philosophy, the most useful systems engineering artifact for an software engineers to master is the development of the software's operational concepts a.k.a. CONOPS. To understand more about the role of operational concepts in software development read IEEE Std 1362-1998 IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document -Description
By Einar Landre
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page