Thảm hoạ phần mềm
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ì?
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
