On April 30, 1999, a Titan IV B rocket carrying a military satellite into orbit was launched from Space Launch Complex 40 at Cape Canaveral Air Station, Florida. The flight performance of the Titan solid rocket motor and the core vehicle was nominal. However, the vehicle began experiencing instability about the roll axis during the first burn. This instability was greatly magnified during the upper stage second main engine burn, resulting in uncontrolled vehicle tumbling. As a result of these anomalous events the satellite was placed in an unusable low elliptical final orbit instead of an intended geosynchronous orbit. After several days of satellite life-saving effort by Air Force and satellite contractor personnel the satellite was declared a complete loss by the acting secretary of the Air Force on 4 May 1999.
The investigation into this accident concluded that the cause was due to a failed software development, testing, and quality assurance process. This process did not detect and correct a software engineer error in a manual entry of a constant value of a roll rate filter, which is the value initially entered in the Inertial Measurement flight software file. The value should have been entered as 1.992476, but was entered as 0.1992476. The incorrect roll rate filter constant zeroed any roll rate data, resulting in the loss of roll axis control, which then caused loss of yaw and pitch control.
What could have been done to prevent the problem? The answer to this question points to lack of organization and control in the software development process.
Why did the software engineer need to manually type the constant value into that file? Well, it turns out that the original file provided by the Control Dynamics group was somehow lost and he had to recreate it from scratch. While human error can be considered as a factor, the primary cause of this one billion dollar disaster was the accidental loss of the original file.
You can view the full story on the Internet at: http://sunnyday.mit.edu/accidents/titan_1999_rpt.doc
This one-billion dollar disaster could have been avoided if the software development team had used a Software Configuration Management (SCM) system that stored all the files safely from accidental loses. However, SCM can do much more than that.
While the rest of this book is focused on the Microsoft Visual SourceSafe 2005 tool, this first chapter is neutral to any SCM tool. In this chapter you will learn the basic terminology and concepts used in the SCM world. If you are already familiar with these concepts you can skip this chapter, although I would still suggest you take a quick look.
First, let me tell you the story of my first interaction with SCM tools and principles. It was during my first job. I was hired along with one of my friends by a small company that had just opened its new software development department. We were the first developers and we had to build an ERP system. All we knew was to write (spaghetti) code. They told us what the application should do and that was it. We were all on our own to make it happen (sounds familiar?). So we scratched our heads and started to write the code. It wasn't long until we needed to work on the same files. We scratched our heads again and came up with a state-of-the-art source management system—manually copying the files from one another. When one person finished the work on a file it was like, "Hey dude, you can take the file now. Oh wait, I must make a backup in case you mess it up." It was like that for a couple of days until we got sick and tired of all the file backups. We had to do something about it.
Then we saw in the Visual Studio suite something called Visual SourceSafe. We told ourselves, "Hey, this thing has something to do with the source files. Let's see what it does!", and installed SourceSafe on our machines. The rest is history. We were now able to work together but independently, without manual file backups, sticky notes, and all that hassle. We never got the chance to experience what would have happened if a third developer had come in before SourceSafe and we had to exchange files between all three of us. It probably wouldn't have been as disastrous as the Titan case but still a serious problem. We thus resolved the source management problem. Now we had to build the ERP system. But that's another story.
SCM was invented to resolve problems of this kind and many more. During the early days of software engineering, the impact of the rapid increases in computer power and the complexity of the problems that could be tackled resulted in the so called "software crisis". This was characterized by an inability to develop software on time, within budget, and within requirements. As a result new ideas, principles, and practices had to be developed. The Software Configuration Management concepts were born.
Software Configuration Management appeared as a solution to software problems, when it was clear that programming does not cover every aspect in software engineering and there was a need for predictability in software development. In this context we can define Software Configuration Management as follows:
Note
Software Configuration Management is the discipline of managing how software is modified and built through techniques including source code control, revision control, object build tracking, and release construction. SCM involves identifying the configuration of the software at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software development lifecycle.
As you can see from its definition, Software Configuration Management aggregates several different concepts and techniques. You may be familiar with some of them as they can work on their own. But as the whole is more than the sum of its parts; SCM is more than all these techniques used independently.
So, let's start with... the end. What is the software development lifecycle?