Trong vài năm qua, có nhiều thảm hoạ phần mềm thế và phần lớn trong chúng có thể đã được tránh. Kiểm thử đóng vai trò quan trọng trong thành công dự án phần mềm nhưng nhiều người quản lý dự án không đánh giá được điều đó cho tốt. Họ thường không lập kế hoạch thời gian đủ cho kiểm thử. Thỉnh thoảng họ cắt bỏ kiểm thử chỉ để đáp ứng lịch biểu và đó là lí do tại sao nhiều thảm hoạ xảy ra. Sau đây là một số thí dụ:
Năm 2009, British Airways tổ chức lễ khánh thành nhà ga Terminal 5 của sân bay Heathrow. Nó được giả định là cơ hội lễ hội nhưng thay vì thế đã biến thành một thảm hoạ tuyệt đối vì hỏng của hệ thống chuyển hành lí đã làm ngắt quãng hàng nghìn du khách. Vào ngày khánh thành, với các quan chức chính phủ và những khách mời quan trọng tới để cử hành lễ, và với hàng trăm nghìn du khách sẵn sàng dùng nó, nhà ga mới đã không vận hành suôn sẻ. Hệ thống chuyển hành lí được máy tính kiểm soát đột nhiên sập và British Airways phải cắt bỏ 34 chuyến bay và sau đó bị buộc phải dừng mọi việc check in hành lí. Suốt 10 ngày sau đó, trên 28,000 túi đồ bị mất chuyến bay của chúng và trên 500 chuyến bay bị cắt bỏ. Vấn đề được tìm ra với hệ thống máy tính của nhà ga không làm việc đúng. Sau đó người ta thấy rằng người quản lý phần mềm đã ra lệnh cho người kiểm thử dừng kiểm thử chỉ để đáp ứng lịch biểu cho ngày khai mạc. Vấn đề này tốn của British Airways vài trăm triệu đô la.
Một thất bại khác có thể được qui cho là kiểm thử không đủ là hệ thống hộ chiếu của chính phủ Anh vài năm trước đây. Lúc đó là mùa hè khi hàng triệu người du hành nhưng không có được hộ chiếu của họ đúng hạn vì cơ quan quản lý hộ chiếu của chính phủ đã đem vào một hệ thống máy tính mới mà không kiểm thử nó và điều đó gây ra sập hệ thống thường xuyên. Về sau người ta phát hiện ra là do thời gian bị giới hạn của dự án phần mềm, người quản lý dự án đã ra lệnh cho người phát triển bỏ qua pha kiểm thử. Người đó nói: “Chúng ta bao giờ cũng có thể sửa được lỗi về sau, cứ làm cho phần mềm xong cho khách hàng trước hết để chúng ta có thể đáp ứng lịch biểu.” Phần mềm của vài triệu dòng mã chưa bao giờ được kiểm thử và tất nhiên là nó sập thôi. Hàng trăm nghìn người lỡ kì nghỉ của họ và cơ quan hộ chiếu phải trả hàng triệu để đền bù cho những người đã nộp đơn xin hộ chiếu mới mà không thể có được.
Máy bay Airbus A380 cũng kinh nghiệm các vấn đề và nhiều năm chậm trễ do kiểm thử không thích hợp. Theo nhiều nguồn, vấn đề nảy sinh với việc trao đổi giữa hai nước khi mỗi nước dùng các hệ thống máy tính khác nhau. Hệ thống của Đức dùng phiên bản phần mềm lạc hậu và hệ thống của Pháp dùng phiên bản mới nhất. Cho nên khi Airbus đem hai nửa của máy bay vào tích hợp, phần mềm khác nhau nghĩa là nối dây của hệ thống này không sánh đúng với nối dây của hệ thống kia. Dường như là quản lý cấu hình đã KHÔNG được xác định tốt, không ai kiểm thử giao diện, không ai kiểm thử tính tương hợp của hai phiên bản phần mềm và không ai tiến hành kiểm thử tích hợp cho tới khi thành quá trễ. Vấn đề sau đó được sửa, nhưng chi phí lên tới hàng trăm triệu đô la hay hơn.
Có hàng nghìn trường hợp tương tự về thất bại của máy tính ở mọi nước do kiểm thử không thích hợp và quyết định sai của cấp quản lý. Phần lớn các thất bại đều ở các dự án lớn và 75% số chúng là các dự án của chính phủ. Những thất bại này nảy sinh từ nhiều nguyên nhân nhưng 92% có thể qui cho thiếu năng lực quản lý. Ít hơn 8% có thể qui cho vấn đề kĩ thuật. Những vấn đề kĩ thuật này có thể được dõi vết về việc dùng công nghệ mới chưa bao giờ được dùng trước đây hay do thiếu hiệu năng khi người thiết kế không tính tới các thuộc tính chất lượng (hiệu năng, tính đổi qui mô, tính hiệu quả v.v.) trong pha kiến trúc. Bằng phân tích dữ liệu từ trên 4,000 dự án phần mềm thất bại, các nhà nghiên cứu thấy rằng: 52% số chúng không có viễn kiến, mục đích và mục tiêu được xác định tốt cho dự án; 48% số chúng có lập kế hoạch và ước lượng kém; 65% có người quản lý dự án không có đủ năng lực; 42% không có đủ số thành viên tổ. Tất cả trong chúng đều có thể được qui về vấn đề quản lý.
Không có hoài nghi gì rằng quản lý là nguyên nhân lớn nhất của vấn đề với dự án phần mềm. Câu hỏi của tôi là: Bao nhiêu sinh viên được dạy về quản lý dự án phần mềm trong trường ngày nay? Bao nhiêu trường đang dạy về quản lý dự án trong chương trình của họ? Bao nhiêu người hiểu rằng quản lý dự án phần mềm KHÔNG phải là quản lý dự án? Bao nhiêu người được đề bạt làm người quản lý dự án phần mềm mà không có đào tạo nào? Bao nhiêu người lập trình trở thành người quản lý dự án phần mềm bởi vì họ biết cái gì đó về mã? Bao nhiêu người quản lý dự án ra quyết định dựa trên lịch biểu và ngân sách thay vì chất lượng? Bao nhiêu người quản lý hiểu lập kế hoạch và ước lượng? Ngay cả ngày nay, với tất cả những thảm hoạ này, tôi vẫn nhận được nhiều email từ các sinh viên nói cho tôi rằng “Người quản lý ra lệnh dừng kiểm thử để đáp ứng lịch biểu” hay “Người quản lý của tôi ra lệnh bỏ qua thiết kế và bắt đầu viết mã.” Câu hỏi cuối cùng của tôi là: Bao nhiêu người điều hành và người quản lý cấp cao hiểu vấn đề với phần mềm sau khi mất nhiều tiền thế? Họ có học được điều gì không? Nếu thất bại dạy nhiều hơn thành công, hình dung xem họ có thể học được bao nhiêu từ tất cả những thảm hoạ phần mềm này? Làm sao nó vẫn xảy ra ngày nay? Hay họ đã chẳng học được cái gì?
—-English version—-
Software disasters
In the past few years, there were so many software disasters and most of them could have been avoided. Testing plays a important role in the software project success but many software project managers do not value it well. They often do not plan enough time for testing. Sometime they cancel testing just to meet the schedule and that is why many disasters happen. Following are some examples:
In 2009, British Airways celebrated the opening of Heathrow’s Airport Terminal 5. It was supposed to be a celebration occasion but instead turned into an absolute disaster as the failure of the baggage handling systems disrupted thousands of travelers. On the opening day, with government officials and important guests arrived to celebrate, and with hundred thousand travelers ready to use it, the new terminal was not operating smoothly. The baggage handling systems control by computers suddenly crashed and British Airways had to cancel 34 flights and was later forced to suspend all baggage check in. Over the following 10 days, over 28,000 bags were missing their flights and over 500 flights were cancelled. The problems were found with the terminal’s computer systems not properly functioning. Later it was found that software managers ordered testers to stop testing just to meet the opening day schedule. To problem cost British Airways several hundred million dollars.
Another failure that can be attributed to insufficient testing is the UK government’s passport system few years before. It was in the summer where million people travel but could not get their passports on time because the Government Passport Agency had brought in a new computer system without testing it and it crashed often. Later it was found that due to limited time of the software project, the project manager ordered developers to skip testing phase. He said: “We can always fix defects later, just get the software to customers first so we can meet the schedule”. The software of several million lines of code was never test and of course it crashed. Hundred thousand people missed their vacations and the passport office had to pay millions in compensation for people who applied to get new passports but could not.
The Airbus A380 also experienced problems and several years delays due to inadequate testing. According to several sources, the problem arose with communications between two countries when each used different computer systems. The German system used an out-of-date version of software and the French system used the latest version. So when Airbus was bringing together two halves of the aircraft to integrate, the different software meant that the wiring on one did not match the wiring in the other. It seemed that the configuration management was NOT well defined, no one test the interfaces, no one test the compatibility of two version of software and no one conduct integration test until it is too late. The problem was later fixed, but at a cost of hundred million dollars or more.
There are thousands similar cases of computer failures in every countries due to inadequate testing and management’s wrong decisions. Most of the failures are large projects and 75% of them are government’s projects. These failure resulted from many causes but 92% can be attributed to management incompetents. Less than 8% can be attributed to technical issues. These technical issues can be traced to the use of new technology that never been used before or the lack of performance when designers failed to take into consideration of quality attributes (Performance, scalability, efficiency etc.) during the architecture phase. By analyze data from over 4,000 failure software projects, researchers found that: 52% of them do not have well defined vision, goals and objectives for the project; 48% of them have bad planning and estimates; 65% have incompetent project managers; 42% have insufficient number of team members. All of them can be attributed to management issues.
There is no doubt that management is the single biggest cause of problems on software project. My questions are: How many students are taught about software project management in school today? How many schools are teaching software project management in their programs? How many people understand that software project management is NOT project management? How many people are promoted to software project manager without any trainings? How many programmers become software project managers because they know something about code? How many project managers make decisions based on schedule and budget instead of quality? How many managers understand planning and estimating? Even today, with all of these disasters, I still receive many emails from students tell me that “My manager orders stop testing to meet schedule” or “My manager orders skip designing and start coding”. My last questions are: How many executives and senior managers understand the problem with software after losing so much money? Have they learned anything? If failure teaches more than success, imagine how much they can learn from all these software disasters? How come it still happen today? Or have they ever learned anything?
