Bài giảng Công nghệ phần mềm - Khó khăn trong xây dựng phần mềm - Phạm Đào Minh Vũ

Nội dung text: Bài giảng Công nghệ phần mềm - Khó khăn trong xây dựng phần mềm - Phạm Đào Minh Vũ

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