Điều đó không được dạy trong trường bởi vì không có môn học về nó. Vào thời đó, đào tạo máy tính phần lớn là về toán học, thuật toán và ngôn ngữ lập trình (Fortran 4 và Cobol). Khi tôi bắt đầu việc làm đầu tiên của mình, tôi đã phạm phải một sai lầm lớn là thay đổi một dòng mã trong phần mềm trước khi nó được đưa ra cho khách hàng. Tất nhiên, phần mềm này trước đó đã được kiểm thử đầy đủ cho nên người quản lí rất tự tin rằng sẽ không có vấn đề gì. Trong kiểm thử chấp nhận nơi khách hàng thực hiện phần mềm này và sẵn sàng trả cho công ti một số tiền lớn (vài trăm nghìn đô la) đột nhiên phần mềm chết. Tôi vẫn còn nhớ khuôn mặt của người quản lí chuyển từ đỏ sang tái xanh khi ông ấy cố gắng giải thích cho người quản lí cấp cao của mình. Tôi cũng thấy khách hàng giận dữ hỏi: “Điều này nghĩa là gì? Sao nó dừng lại? Các anh đã kiểm thử thực sự phần mềm này chưa?” Sau vài lần cho chạy lại, phần mềm vẫn chết cho nên khách hàng bỏ đi không kí séc trả tiền và người quản lí cấp cao bảo với người quản lí của tôi: “Tìm cho ra ai đã làm nó và lo về điều đó đi.”
Sau khi phần lớn mọi người rời khỏi phòng, người quản lí của tôi hỏi tổ dự án: “Ai đã can thiệp vào phần mềm được kiểm thử đầy đủ?” Tất nhiên, mọi thành viên đều im re vì họ thậm chí không tin được rằng điều đó có thể xảy ra. Tôi giơ tay lên nói: “Thưa ông, tôi chỉ đổi một dòng mã đêm qua.” Tôi vẫn còn nhớ cảm giác mặc cảm khi nhiều con mắt giận dữ nhìn vào tôi. Tôi nghĩ: “Chấm hết việc làm của mình rồi vì mình mới chỉ làm hai tuần trước.” Bỗng nhiên người quản lí của tôi cười to: “Tôi đã đoán ra rồi, đó phải là một kĩ sư mới vì anh ta không biết gì về quản lí cấu hình!” Ông ấy hỏi tôi về một dòng mã đó mà tôi đã thay đổi và lập tức sửa lại nó rồi cho dịch lại phần mềm. Rồi ông ấy gọi người quản lí cấp cao và trước sự ngạc nhiên của tôi, ông ấy nói: “Thưa ngài, chúng tôi đã tìm ra vấn đề, đó là môt mạch phần cứng nhỏ và nó không có liên quan gì tới phần mềm chất lượng cao của chúng tôi.” Ngày hôm sau, khách hàng được mời trở lại và sau khi chứng kiến kiểm thử chấp nhận vài lần, ông ấy hài lòng và rút cuốn sổ séc ra. Tôi để ý rằng mọi người đều sung sướng. Vào cuối ngày, người quản lí gọi tôi lên văn phòng của ông ấy: “Đây là hình phạt cho cậu, đi học môn học về quản lí cấu hình phần mềm ngay lập tức nếu cậu còn muốn giữ việc làm.” Tôi được cử tới một trường đào tạo đặc biệt để học về SCM trong một tuần.
Tôi đã biết rằng quản lí cấu hình phần mềm (SCM) là qui trình nhận diện, tổ chức, và kiểm soát các thay đổi đối với phần mềm. Bởi vì phần mềm thay đổi thường xuyên cho nên SCM nên được áp dụng cho toàn bộ vòng đời phát triển phần mềm. Điển hình SCM bao gồm bốn khu vực chức năng chính: Nhận diện cấu hình; kiểm soát cấu hình; giải trình trạng thái cấu hình; và kiểm định cấu hình. Việc làm về SCM là nhận diện các cấu phần phần mềm nào là quan trọng đối với dự án và kiểm soát các thay đổi với chúng để đảm bảo tính toàn vẹn của sản phẩm phần mềm. SCM cũng kiểm trạng thái của các cấu phần này để đảm bảo rằng chúng được giải trình đúng đắn. Cuối cùng, SCM tiến hành kiểm định để chắc chắn rằng mọi hoạt động trước đó là được thực hiện tương ứng với qui trình được xác định của tổ chức.
Ngay cả ngày nay, sau gần bốn mươi năm, tôi vẫn nhớ về sai lầm đầu tiên của tôi trong việc thay đổi chỉ một dòng mã. Tất nhiên, bây giờ tôi biết rằng ngay cả một thay đổi nhỏ, một dòng mã thay đổi có thể tạo ra khác biệt giữa thành công và thất bại.
When I was a computer science student, I never learned about Software Configuration Management (SCM). It was not taught in school because there was no course about it. At that time, the computer training was mostly on mathematics, algorithms, and programming languages (Fortran 4 and Cobol). When I started on my first job, I made a major mistake by changing one line of code in a software before it was released to the customer. Of course, the software was previously fully tested so managers were very confident that there should not be any problem. During the acceptance test where customer executed the software and ready to pay the company a large amount of money (Several hundred thousand dollars) suddenly the software crashed. I still remembered the face of my manager turning from red to blue as he tried to explain to his senior managers. I also saw the customer angrily asked: “What is the meaning of this? Why did it stop? Did you really test this software?”. After several restarts, the software still crashed so the customer left without signing the payment check and senior managers told my manager: “Find out who did it and take care of it.”.
After most people left the room, my manager asked the project team: “Who tampered with the fully tested software?” Of course, all members were quiet as they did not even believe that it could happen. I raised my hand: “Sir, I only change one line of code last night”. I still remembered the guilty feeling as many angry eyes looked at me. I thought: “This is the end of my job as I just started only two weeks ago”. Suddenly my manager laughed aloud: “I should have guessed, it must be the new engineer as he know nothing about configuration management!” He asked me about the one line of code that I changed and immediately corrected it then compiled the software. He then called the senior manager and to my surprise, he said: “Sir, we found out the problem, it was a small hardware circuit and it has nothing to do with our high quality software”. The next day, the customer was invited back and after witnessed the acceptance tests several time, he was pleased and pull out his checkbook. I noticed that everybody was happy. At the end of the day, my manager called me to his office: “This is your punishment, go take a course in software configuration management immediately if you want to keep your job”. I was sent to a special training school to learn SCM for one week.
I learned that Software Configuration Management (SCM) is the process of identifying, organizing, and controlling changes to the software. Because software changes often so SCM should be applied to the entire software development life cycle. Typically SCM consists of four major functional areas: Configuration Identification; Configuration Control; Configuration Status Accounting; and Configuration Auditing. The job of SCM is to identify what software components are important to the project and control changes to them to ensure the integrity of the software product. SCM also check for the status of these components to assure that they are being properly accounted for. Finally, SCM also conduct audits to make sure that all previous activities are being performed according to the organization’s defined process.
Even today, after almost forty years, I still remember about my first mistake of changing just one line of code. Of course, now I know that even one small change, one line of code change can make the difference between success and failure.
