Bài giảng Khó khăn trong xây dựng phần mềm: Chương 0 - ThS. Phạm Đào Minh Vũ

Chia sẻ: Caphesuadathemmatong | Ngày: | Loại File: PDF | Số trang:25

Thêm vào BST

Báo xấu

48
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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!

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Khó khăn trong xây dựng phần mềm: Chương 0 - ThS. Phạm Đào Minh Vũ

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
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
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
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
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
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
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
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
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
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
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?  P hả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
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
0.5. Một số dự án lớn của NASA 13
0.6. So sánh chi phí Phần cứng và Phần mềm 14
0.6. Chi phí các pha 15
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
0.6. Chi phí các pha 17
0.6. Backlog tại 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 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
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