Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Visual SourceSafe 2005 Software Configuration Management in Practice

You're reading from   Visual SourceSafe 2005 Software Configuration Management in Practice Best practice management and development of Visual Studio .NET 2005 applications with this easy-to-use SCM tool from Microsoft

Arrow left icon
Product type Paperback
Published in Feb 2007
Publisher Packt
ISBN-13 9781904811695
Length 404 pages
Edition 1st Edition
Languages
Arrow right icon
Toc

Table of Contents (15) Chapters Close

Visual SourceSafe 2005 Software Configuration Management in Practice
Credits
About the Author
About the Reviewers
1. Preface
1. Controlling the Evolution of Software Products FREE CHAPTER 2. The SourceSafe 2005 Architecture 3. Creating a Service-Oriented Application 4. Adding Solutions to the SourceSafe Database 5. Developing Solutions under Source Control 6. Working from Remote Locations 7. Managing the Software Development Lifecycle Installing Visual SourceSafe 2005 Creating and Configuring SourceSafe Databases Database Maintenance

Chapter 1. Controlling the Evolution of Software Products

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.

What is Software Configuration Management?

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?

You have been reading a chapter from
Visual SourceSafe 2005 Software Configuration Management in Practice
Published in: Feb 2007
Publisher: Packt
ISBN-13: 9781904811695
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image