Currently, I'm taking the course Quantitative Software Engineering through Stevens Institute of Technology. I am interested in learning about software engineering and software lifecyle process models because software is such a HUGE part of so many systems. You can have the best, most robust hardware and still have system failure if the software is flawed. An example discussed in the text this week (Bernstein, L and Yuhas, C.M., Trustworthy Systems Through Quantitative Software Engineering, Wiley, 2005) was the Patriot missile defense failure that resulted in a Scud missile hitting an American military post in Dhahran, Saudi Arabia in 1991.
Credit: Wikipedia Commons
To give a really simplified overview, the software had a small timing error that resulted in miscalculating the location where a missile "should" be at a certain time based on the location where it was detected. If the missile was not where it "should" be, then the system considered it a false alarm (i.e. the object was not moving the correct speed to be a missile) and did not act to intercept it. When the software ran for an extended period of time, these (very small) timing errors added up enough to cause the system to consider an actual missile to be a false alarm. Other systematic problems existed (software flaw was known and was being fixed, how long an "extensive period of time" was never communicated to the operators, system was originally designed as anti-aircraft) which could be an entirely other discussion, but this seemingly small software "glitch" resulted in 28 deaths and 97 injuries. Clearly, software is crucial to systems that are responsible for protecting human lives.
So this week our class discussion covered the software engineering body of knowledge, or SWEBOK. This includes software: requirements analysis, design, construction, testing, maintenance, configuration management, quality analysis, engineering management, engineering infrastructure, and engineering process. With education in mechanical and systems engineering, I can see a definite correlation between software and hardware development and between the software and systems engineering lifecycles. This makes sense to me, because all these steps are crucial to getting a successful end product that actually does what the customer wanted it to do.
I am interested software requirements analysis and the software engineering process, as these seem to be the main overlap between software and systems engineering (or at least this is where there should be an overlap/interface). Traditional systems engineering looked at software as another “sub-assembly” – but today software is really integrated into almost all systems and sub-systems, and needs to be developed and managed considering the integrated nature of systems. Because of this, it is important that there be early and frequent communication between system and software engineers, as well as discipline engineers/technical experts. Early communication and understanding of goals, objectives, risk tolerance, etc should facilitate the development of robust requirements. Depending on the project size, risk tolerance, fluidity of design, development team size, and other factors discussed this week, an appropriate SW process model should be followed to allow continued communication between the system and software engineers to ensure that requirements remain valid and that requirements can be added (through decomposition, generation, realizing that requirements are incomplete) or changed if necessary. Of course, misunderstood or changing requirements is often a symptom of a challenged project, but the reality is that requirements can and do change, and this can be dealt with through communication throughout the project lifecycle.
"Throughout the project lifecycle" is key. If a system is adapted for use in a new environment or for even a slightly different purpose (such as withthe Dhahran example – system was adapted from anti-aircraft to anti-missile defense system) the whole project lifecycle needs to be considered – from requirements to testing and maintenance.
Megan K. Jaunich 