Bài giảng Khó khăn trong xây dựng phần mềm: Chương 0 cung cấp cho người học những kiến thức như: Liệu có vấn đề trong việc phát triển phần mềm; Khủng hoảng phần mềm; Những khó khăn trong phát triển phần mềm. Mời các bạn cùng tham khảo!
KHÓ KHĂN TRONG XÂY DỰNG PHẦN MỀM Giảng viên : ThS Phạm Đào Minh Vũ Email : phamdaominhvu@yahoo.com Nội dung Liệu có vấn đề việc phát triển phần mềm ? Một số dự án thất bại Những số thống kê dự án phần mềm Khủng hoảng phần mềm Những khó khăn phát triển phần mềm 0.1 Một số dự án thất bại AAS (FAA Advanced Automation System) (1989): Hệ thống điều khiển không lưu, tiêu tốn 2,6 tỷ usd IBM phát triển (2.3 triệu dòng lệnh Ada) 1994: xây dựng lại từ đầu (vì đặc tả u cầu khơng đúng) Ariane (June 04, 1996) nổ sau phóng (40s) Do lỗi PM điều khiển (chuyển số thực 64bit -> số nguyên 16bit) Automated customer information and billing system [2002] Sydney Water Corp (Úc): hủy bỏ chừng sau chi 61 triệu AUD (33,2 triệu USD) Head of AF (Air Force) Systems Command: „„PM nhược điểm việc phát triển vũ khí“ 7/10 chương trình phát triển vũ khí đối mặt với vấn đề PM tỉ lệ tăng lên 0.1 Một số dự án thất bại (tt) Năm 2000, nhà bán lẻ Kmart Corp, Michigan, phát động nỗ lực đại hóa CNTT $ 14 triệu nhằm để cạnh tranh tốt với đối thủ Wal-Mart Tuy nhiên, 18 tháng sau , Kmart ngưng dự án đại hóa này, với việc đầu tư khoảng 130 triệu USD vào CNTT tháng sau, Kmart Corp tuyên bố phá sản 1992, Một hệ thống đặt phòng du lịch, Khách sạn Hilton , Marriott AMR , công ty mẹ American Airlines, tiêu tốn 165 triệu USD năm dự án bị hủy với lý chính: lịch trình phát triển lạc quan đánh giá thấp khó khăn kỹ thuật có liên quan Năm 1997, sau chi tiêu $ 40 triệu, tiểu bang Washington hủy dự án CNTT xử lý giấy phép lái xe đăng ký xe 0.2 Những số biết nói Việc phát triển ứng dụng > 5000 function points (~500,000 LOC) nhiệm vụ rủi ro giới đại (Capers Jones) Những rủi ro dẫn đến hủy đình trệ tăng nhanh với việc tăng kích thước ứng dụng (Capers Jones): 65% HT lớn (>1,000,000 LOC) bị hủy trước hoàn thành 50% HT ước lượng sai kích thước > 1/2 million LOC 25 % dự án > 100,000 LOC Tỷ lệ thất bại (Failure or cancellation) dự án lớn >20% (Capers Jones) 0.2 Những số biết nói Ví dụ kích thƣớc dự án Window Vista 50 Window 40 Window 50 Window 10 60 0.2 Những số biết nói (tt) Sau khảo sát 8,000 dự án IT, Standish Group cho biết khoảng 30% bị hủy trước hồn thành Trung bình dự án Mỹ bị hủy sau năm tiến hành tiêu tốn 200% kinh phí dự kiến (Capers Jones) Các dự án bị hủy chiếm khoảng 15% tổng kinh phí PM Mỹ ($14 billion in 1993 dollars) (Capers Jones) Trong năm 2004, phủ Mỹ chi tỷ usd phần mềm ( không kể phần mềm nhúng hệ thống vũ khí ), với tỷ lệ thất bại 5%, có nghĩa $300 triệu 0.2 Những số biết nói (tt) Thống kê Standish Group năm 2006 Có tới 50% số dự án phần mềm thất bại Chỉ có 16.2% dự án hoàn thành hạn nằm giới hạn ngân sách, đáp ứng tất tính đặc tính cam kết ban đầu Có 52.7% dự án hoàn thành vào hoạt động khơng hồn thành hạn bội chi, thêm khơng đáp ứng đầy đủ tính đặc tính thiết kế ban đầu Và có 31.1% dự án thất bại trước hoàn thành -> 83.8% dự án thất bại không đáp ứng yêu cầu ban đầu 0.2 Những số biết nói (tt) 2/3 dự án hồn thành vượt thời gian kinh phí dự kiến (Capers Jones) [bad estimates?] 1/3 dự án hoàn thành có độ tin cậy chất lượng thấp năm đầu triển khai (Jones) Tỷ lệ xảy lỗi PM từ 0.5 đến 3.0 /1000 LOC (Bell Labs survey) Civilian software: tối thiểu 100 từ tiếng Anh sinh cho câu lệnh Military: ~ 400 từ(Capers Jones) 0.3 Thảo luận Bạn tham gia dự án mà chưa kết thúc không sử dụng? Bạn có ví dụ khác thất bại dự án PM? 10 0.4 Khủng hoảng phần mềm 10/1968 Hội nghị NATO chuyên gia phần mềm đưa thuật ngữ “Khủng hoảng phần mềm” (Software crisis) Qua hàng chục năm, thuật ngữ dùng ngày mang tính cấp bách, với trăn trở : Phải làm với phần mềm chất lượng lỗi tiềm tàng có đó? Phải xử lý bảo dưỡng phần mềm? Phải giải thiếu kỹ thuật viên phần mềm? P hải chế tác phần mềm có yêu cầu phát triển theo qui cách xuất hiện? Làm để phần mềm đạt chất lượng tốt nhất? 11 0.4 Khủng hoảng phần mềm Một số yếu tố ảnh hƣởng đến khủng hoảng Phần mềm lớn kéo theo phức tạp hóa tăng chi phí phát triển Đổi vai trị giá thành Phần mềm Phần cứng Công sức cho bảo trì tăng chi phí cho Backlog lớn Nhân lực chưa đáp ứng nhu cầu phần mềm Những phiền hà phần mềm gây vấn đề xã hội …(?) 12 0.5 Một số dự án lớn NASA 13 0.6 So sánh chi phí Phần cứng Phần mềm 14 0.6 Chi phí pha 15 0.6 Chi phí pha Bảo trì phần (maintainance) mềm 20% sửa lỗi 20% thay đổi thích ứng 60% thay đổi hoàn thiện Hầu hết lỗi phần mềm bắt nguồn từ công đoạn thu thập yêu cầu, khơng phải lập trình 16 0.6 Chi phí pha 17 0.6 Backlog Nhật Bản 1995 18 0.6 Tiến hóa phần mềm (maintenance) Belady and Lehman’s Laws: PM tiếp tục thay đổi với tốc độ nhanh PM trở nên khơng có cấu trúc việc bị thay đổi Leveson’s Law: Việc áp dụng CNTT (MTĐT) không làm giảm nhân hay chi phí 19 0.6 Liệu có cải thiện? PM cải thiện chậm phần cứng? "Software expands to fill the available memory" (Parkinson) " Software is getting slower more rapidly than hardware becomes faster" (Reiser) Expectations are changing 20 0.7 Thảo luận Kỹ sư phần mềm khó kỹ sư phần cứng ? 21 0.8 Những khó khăn phát triển PM Khơng có phương pháp mô tả rõ ràng định nghĩa yêu cầu người dùng (khách hàng), sau bàn giao sản phẩm dễ phát sinh trục trặc (troubles) Với phần mềm quy mô lớn, tư liệu đặc tả cố định thời gian dài, khó đáp ứng nhu cầu thay đổi người dùng cách kịp thời thời gian Nếu khơng có Phương pháp luận thiết kế quán mà thiết kế theo cách riêng (của cơng ty, nhóm), dẫn đến suy giảm chất lượng phần mềm (do phụ thuộc nhiều vào người) 22 0.8 Những khó khăn phát triển PM (tt) Nếu khơng có chuẩn làm tư liệu quy trình sản xuất phần mềm, đặc tả khơng rõ ràng làm giảm chất lượng phần mềm Nếu khơng kiểm thử tính đắn phần mềm giai đoạn mà kiểm giai đoạn cuối phát lỗi, thường bàn giao sản phẩm khơng hạn Nếu coi trọng việc lập trình khâu thiết kế thường dẫn đến làm giảm chất lượng phần mềm Nếu coi thường việc tái sử dụng phần mềm (software reuse) → suất lao động giảm 23 0.8 Những khó khăn phát triển PM (tt) Phần lớn quy trình phát triển phần mềm có nhiều thao tác người thực → suất lao động thường bị giảm Không chứng minh lợi ính đắn phần mềm → độ tin cậy phần mềm giảm 10.Chuẩn phần mềm tốt đo cách định lượng → đánh giá hệ thống đắn hay không 11.Khi đầu tư nhân lực lớn vào bảo trì làm giảm hiệu suất lao động nhân viên 24 0.8 Những khó khăn phát triển PM (tt) 12 Cơng việc bảo trì kéo dài → giảm chất lượng tư liệu ảnh hưởng xấu đến việc khác 13 Quản lý dự án lỏng lẻo kéo theo quản lý lịch trình khơng rõ ràng 14.Khơng có tiêu chuẩn để ước lượng nhân lực dự toán làm kéo dài thời hạn vượt kinh phí dự án Đây vấn đề phản ánh khía cạnh khủng hoảng phần mềm, tìm cách nỗ lực vƣợt qua để tạo phần mềm tốt! 25 ... (>1 ,00 0 ,00 0 LOC) bị hủy trước hồn thành 50% HT ước lượng sai kích thước > 1/2 million LOC 25 % dự án > 100 ,00 0 LOC Tỷ lệ thất bại (Failure or cancellation) dự án lớn > 20% (Capers Jones) 0. 2... dụ kích thƣớc dự án Window Vista 50 Window 40 Window 50 Window 10 60 0.2 Những số biết nói (tt) Sau khảo sát 8 ,00 0 dự án IT, Standish Group cho biết khoảng 30% bị hủy trước hồn thành Trung... Tỷ lệ xảy lỗi PM từ 0. 5 đến 3 .0 / 100 0 LOC (Bell Labs survey) Civilian software: tối thiểu 100 từ tiếng Anh sinh cho câu lệnh Military: ~ 400 từ(Capers Jones) 0. 3 Thảo luận Bạn tham