Quản lý dự án phần mềm docx

Quảnlýdự án phầnmềm
2
Nội dung
z Giớithiệuvề quảnlýdự án phầnmềm
z Đovàướclượng
z Lậplịch và theo dõi
z Đảmbảochấtlượng phầnmềm
z Nghiên cứukhả thi
z Quảnlýnhânsự
z Quản lý thay đổi
z Công cụ hỗ trợ quảnlýdự án
3
Tài liệu
z Pressman, Software Engineering,
McGraw Hill (chapter 2 & 3)
z Sommerville, Software Engineering,
Addison-Wesley (chapter 29)
z Ngô Trung Việt, Phương pháp luậnquản
lý dự án CNTT, NXB KHKT
z Giáo trình kỹ nghệ phầnmềm(chương 6)
z Các tài liệu điệntử khác
4
Tạisaophảiquảnlýdự án
z Các dự án thường:
− Không hoàn thành đúng hạn
− Chi phí xây dựng vượt quá dự toán
− Chấtlượng không đảmbảo
5
Thống kê của Standish Group (2006)
z Có tới 50% trong số các dự án phầnmềmthấtbại
z Chỉ có 16.2% dự án là hoàn thành đúng hạnvànằm

trong giớihạn ngân sách, đáp ứng tấtcả tính năng và
đặctínhnhư cam kếtban đầu
z 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ạnvàbộichi,
thêm nữa không đáp ứng đầy đủ tính năng và đặc
tính như thiếtkế ban đầu
z Và có 31.1% dự án thấtbạitrướckhiđược hoàn
thành
z -> hơn 83.8% dự án thấtbạihoặc không đáp ứng
những yêu cầu ban đầu
6
Mụctiêu
z Quảnlýcácyếutố:
− Thờigian: đúng thờihạn
− Chi phí: không vượtdự toán
− Sảnphẩm: đầy đủ các chứcnăng đã định
− Thỏamãnyêucầu khách hàng
 thỏamãnvề nhu cầu
 thỏamãnvề tiếntrình
7
Nhiệmvụ, quyềnhạncủangườiquảnlýdự án
z Thờigian
− lậplịch, điềuchỉnh lịch
− kiểmtra/đốichiếucáctiến trình con vớilịch biểu
− tạo độ mềmdẻo trong lịch biểu
z Tài nguyên
− thêm tiền, thêm người, thêm thiếtbị
z Sảnphẩm
− thêm, bớt, sửachứcnăng
z Rủiro

− phân tích rủiro
− đề xuấtgiải pháp
− thựchiệngiải pháp và giám sát
8
Các pha công việc
z Thiếtlập: viết đề án
z Ướclượng (chi phí, người, thiếtbị, )
z Phân tích rủiro
z Lậpkế hoạch
z Chọnngười
z Theo dõi và kiểm soát tiếntrình
z Viết báo cáo và trình diễn
9
Các hoạt động thường xuyên
z Đảmbảochấtlượng phầnmềm
− đảmbảosựđúng đắn
− đảmbảosự tuân thủ theo chuẩn
z Quản lý thay đổi/quảnlýcấuhìnhphầnmềm
− Quản lý thay đổivề yêu cầu, thiếtkế, mã
nguồn…
− Quảnlýcấuhình(được phát triển phân tán)
10
1. Đovàướclượng
z Cách thứctiếpcậpquảnlý: đovàướclượng
z Đophầnmềm
− kích thước, chi phí, hiệunăng, chấtlượng
z Ướclượng
− kích thước
− chi phí
− thờigian

z Chỉ quảnlýđượccácyếutố có thểđo được
11
Độ đovàướclượng
z Ướclượng phầnmềmlàcôngviệc quan
trọng hàng đầu trong quảnlýdự án
− kích cỡ, chi phí
− thời gian, nhân lực
z Để ướclượng đượccầncóđộ đo
− kích cỡ, chấtlượng, hiệunăng
z Nguyên lý: cầnphảixáclập độ đocho
mọicôngviệc
− độ đophải định lượng
12
Đo kích cỡ phầnmềm
z Đo theo dòng lệnh (LOC – Lines Of Code)
− trực quan
− phụ thuộcngônngữ
z Đo điểmchứcnăng (FP – Functional
Points)
− độclậpvới ngôn ngữ
− phụ thuộc các mô hình lựachọn (tham số)
-hiệunăng: KLOC/người-tháng
-chấtlượng: số lỗi/KLOC
- chi phí: giá thành/KLOC
13
Điểmchứcnăng
z Tổng hợpcácđặctrưng của module
− Input
− Output
− Interface

− Files
z Đặttrọng số cho các đặctrưng
z Trọng số phụ thuộcvàongữ cảnh (dự án) cụ thể
− độ phứctạpcủa bài toán
− Các yêu cầuvề chấtlượng, hiệunăng
− Kích thướccủadữ liệusử dụng
14
Điểmchứcnăng FP
z FP = a
1
I + a
2
O + a
3
E + a
4
L + a
5
F
− I : số Input
− O: số Output
− E: số yêu cầu
− L: số tệptruycập
− F: số giao diện ngoại lai (devices, systems)
15
Điểmchứcnăng: Ví dụ
z FP = 4I + 5O + 4E + 10L + 7F
z Hàm: Tính ướcsố chung lớnnhấtcủa
hai số nguyên
− Input I = 2

− Output O = 1
− Yêu cầuE = 1
-> Điểmchứcnăng FP = 17
16
Độ đovề chấtlượng dựa trên thống kê
z Độ tin cậy: MTBF – Mean Time Between
Failures
− thờigianchạy liên tục không có lỗi
z Thờigiankhôiphụchệ thống
− MTTR – Mean Time To Recover
z Tính sẵncó:
MTBF
MTBF + MTTR
17
Độ đohiệuquả phát hiệnlỗi
z Hiệuquả khử lỗi: E/(E+D)
− E(rror): lỗipháthiệntrước khi bàn giao
− D(efect): lỗi phát hiện sau khi bàn giao
z E/(E+d/0.9)
− d: số lỗi phát hiện trong 1 tháng sau khi bàn
giao
18
Ướclượng phầnmềm
z Các yếutố cần ướclượng
− kích cỡ phầnmềm
− chi phí (công sức) phát triển
− thờigian
− số người tham gia
z Nguyên tắc ướclượng
− phân rã chứcnăng

− ướclượng vớitừng chứcnăng
− dựa trên kinh nghiệm, dữ kiệnquákhứ
19
Ướclượng
z Kích cỡ
− LOC: ướclượng trựctiếpvớitừng mô đun
− FP: ướclượng gián tiếp thông qua ướclượng
input/output, yêu cầu
z Công sức:
− dựatrênkíchcỡ, độ phứctạp
− dựavàodữ liệu quá khứ
− đơnvị: person-day, person-week, person-month
20
Ví dụ
z Trang web xem kếtquả họctậpcủa sinh
viên bao gồmcácmôđun/giao diện
chính:
− nhập thông tin tìm kiếm: 100 LOC
− tìm kiếm trên CSDL sinh viên: 300 LOC
− sinh kếtquả: 100 LOC
công sức: 01 person-week
Vậyphầnmềm đào tạo 2000 LOC thì sao?
21
Mô hình ướclượng COCOMO - Costructive Cost Model
z Ướclượng nỗ lực, thời gian, số người
phát triểntừ kích cỡ phầnmềm.
z Sử dụng vớicácphầnmềmlớn
z Mô hình cơ sở
− Nỗ lực E = a * Lb
− Thời gian T = c * Ed

− Số ngườiN = E/T
L: số dòng lệnh (KLOC)
a, b, c, d: tham số
22
COCOMO: các bướctiếnhành
z Thiếtlậpkiểudự án
− organic: đơngiản, không truy cậpcácthiếtbị ngoạilai
− semi-detached
− embeded: phứctạp, truy cậpthiếtbị
z Xác lập (phân rã) mô đun và ướclượng số dòng
lệnh
z Tính lạisố dòng lệnh trên cơ sở tái sử dụng
z Tính nỗ lực phát triểnE chotừng mô đun
z Tính lạiE dựatrênđộ phứctạpcủadự án
− độ tin cậy, độ lớncủaCSDL
− yêu cầuvề tốc độ, bộ nhớ
z Tính thờigianvàsố người tham gia
23
COCOMO: tham số cơ sở
0.322.51.22.8embeded
0.352.51.123.0semi-detached
0.382.51.053.2organic
dcba
24
COCOMO: Ví dụ
z Phầnmềmkíchcỡ 33.3 KLOC.
− a = 3.0 b = 1.12 c = 2.5 d = 0.35
− E = 3.0 * 33.31.12 = 152 person-month
− T = 2.5 * E0.35 = 14.5 tháng
− N = E/D = ~ 11 người

25
Khó khăn trong ướclượng
z Các thông số không trựcquan
z Khó đánh giá tính đúng đắncủa các tham số
z Không có mô hình tổng quát
z Các kỹ thuật ướclượng đang thay đổi
•Ápdụng các mô hình khác nhau
•Tiếnhànhướclượng nhiềulần
• Ướclượng lại khi dự án tiếntriển