Xem mẫu
- 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
nguon tai.lieu . vn
