1. QUẢN LÝ DỰ ÁN PHẦN MỀM
Chủ đề được trình bày bởi:
Bằng tiến sĩ. Trần Khánh Dũng
Khoa Công nghệ Phần mềm
Email: dungtk@nuce.edu.vn
01- 2017
2. Quan
tâm
● Các khái niệm và nguyên tắc quản lý dự án phần mềm cơ bản
● Quy trình và số liệu dự án
● Cơ sở để ra quyết định quản lý hiệu quả
● Kỹ thuật được sử dụng để
● ước tính chi phí,
● yêu cầu tài nguyên,
● và thiết lập một kế hoạch dự án hiệu quả
● Các hoạt động quản lý dẫn đến giám sát, giảm thiểu và quản lý rủi
ro hiệu quả
● Các hoạt động cần thiết để xác định nhiệm vụ dự án và thiết lập
lịch trình dự án khả thi
● Kỹ thuật đảm bảo chất lượng và kiểm soát thay đổi
3. tình trạng của
vấn đề
“Tôi đã đến thăm hàng chục cửa hàng thương mại, cả tốt lẫn
xấu, và tôi đã quan sát thấy rất nhiều nhà quản lý xử lý dữ
liệu, cả tốt lẫn xấu. Tôi đã quá thường xuyên chứng
kiến cảnh những người quản lý này vật lộn một cách vô ích
với các dự án ác mộng, vật lộn với thời hạn không thể thực
hiện được hoặc cung cấp các hệ thống khiến người dùng
của họ phẫn nộ và tiếp tục tiêu tốn một lượng lớn thời gian
bảo trì.”
[Page-Jones, M., Quản lý dự án thực hành, Dorset House,
1985]
6. Người - Người
chơi
Các nhà quản lý cấp cao xác định các vấn đề
kinh doanh
Các nhà quản lý dự án (kỹ thuật), những người
phải lập kế hoạch, động viên, tổ chức và kiểm
soát những người thực hành làm công việc
phần mềm.
Các học viên cung cấp các kỹ năng kỹ thuật cần
thiết để thiết kế một sản phẩm hoặc ứng dụng.
Khách hàng xác định các yêu cầu đối với phần
mềm được thiết kế
Người dùng cuối tương tác với phần mềm sau
khi nó được phát hành để sử dụng sản xuất.
7. Con người – Trưởng
nhóm
Động lực. Khả năng khuyến khích (bằng cách
“đẩy hoặc kéo”) những người kỹ thuật sản xuất
với khả năng tốt nhất của họ.
Tổ chức. Khả năng nhào nặn các quy trình hiện
có (hoặc phát minh ra những quy trình mới) sẽ
cho phép biến khái niệm ban đầu thành sản
phẩm cuối cùng.
Ý tưởng hoặc đổi mới. Khả năng khuyến khích
mọi người sáng tạo và cảm thấy sáng tạo ngay
cả khi họ phải làm việc trong giới hạn được
thiết lập cho một sản phẩm hoặc ứng dụng
phần mềm cụ thể.
8. Con người – Nhóm
phần mềm
Một dự án cần n người làm việc trong k năm:
1. n cá nhân được giao cho m nhiệm vụ chức năng khác
nhau, công việc kết hợp xảy ra tương đối ít; phối hợp là
trách nhiệm của người quản lý phần mềm, người có thể có
các dự án khác phải quan tâm.
2. n cá nhân được giao cho m nhiệm vụ chức năng khác
nhau ( m < n ) để các "đội" không chính thức được thành
lập; một trưởng nhóm đặc biệt có thể được bổ nhiệm; phối
hợp giữa các nhóm là trách nhiệm của người quản lý phần
mềm
3. n cá nhân được tổ chức thành t đội; mỗi đội được giao
một hoặc nhiều nhiệm vụ chức năng; mỗi nhóm có một cấu
trúc cụ thể được xác định cho tất cả các nhóm làm việc
trong một dự án; sự phối hợp được kiểm soát bởi cả nhóm
và
9. Con người – Nhóm
phần mềm
Để đạt được một nhóm hiệu suất cao:
• Các thành viên trong nhóm phải tin tưởng lẫn
nhau.
• Việc phân bổ các kỹ năng phải phù hợp với vấn
đề.
• Mavericks có thể phải bị loại khỏi đội nếu muốn
duy trì sự gắn kết của đội.
10. Các khái niệm chính -
Sản phẩm
Phạm vi được xác định bằng cách trả lời các câu hỏi
sau:
Bối cảnh.
Làm thế nào để phần mềm được xây dựng phù hợp với
một hệ thống, sản phẩm hoặc bối cảnh kinh doanh lớn
hơn và những ràng buộc nào được áp đặt do bối cảnh
đó?
Mục tiêu thông tin.
Những đối tượng dữ liệu khách hàng nào có thể nhìn
thấy được sản xuất dưới dạng đầu ra từ phần mềm?
Những đối tượng dữ liệu nào được yêu cầu cho đầu
vào?
Chức năng và hiệu suất.
Phần mềm thực hiện chức năng gì để biến đổi dữ liệu
11. Các khái niệm chính -
Quy trình
mô hình tuần tự tuyến tính
mô hình nguyên mẫu
mô hình gia tăng
mô hình Xoắn ốc
mô hình phát triển dựa trên thành phần
Mô hình kỹ thuật thế hệ thứ tư
12. Quy trình - Khung hoạt động
Giao tiếp với khách hàng—các nhiệm vụ cần thiết để thiết lập
việc gợi ra các yêu cầu hiệu quả giữa nhà phát triển và khách
hàng.
Lập kế hoạch—các nhiệm vụ cần thiết để xác định tài nguyên,
thời gian biểu và các thông tin liên quan đến dự án khác.
Phân tích rủi ro—nhiệm vụ cần thiết để đánh giá cả rủi ro kỹ thuật
và quản lý.
Kỹ thuật—các nhiệm vụ cần thiết để xây dựng một hoặc nhiều
biểu diễn của ứng dụng.
Xây dựng và phát hành—các nhiệm vụ cần thiết để xây dựng, thử
nghiệm, cài đặt và cung cấp hỗ trợ người dùng (ví dụ: tài liệu và
đào tạo).
Đánh giá của khách hàng—các nhiệm vụ cần thiết để thu thập
phản hồi của khách hàng dựa trên đánh giá các biểu diễn phần
mềm được tạo ra trong hoạt động kỹ thuật và được thực hiện
trong hoạt động xây dựng.
14. quá trình phân hủy
Khung quy trình chung (CPF)
quá trình phân hủy
hoạt động truyền thông khách hàng (48h – dự án nhỏ)
Xây dựng danh sách các vấn đề làm rõ.
Gặp gỡ khách hàng để giải quyết các vấn đề làm rõ.
Cùng phát triển một tuyên bố về phạm vi.
Xem xét tuyên bố về phạm vi với tất cả các bên liên quan.
Sửa đổi tuyên bố về phạm vi theo yêu cầu.
15. quá trình phân hủy
● Khung quy trình chung (CPF)
● quá trình phân hủy
● hoạt động giao tiếp khách hàng
● Xem lại yêu cầu của khách hàng.
● Lập kế hoạch và lên lịch một cuộc họp chính thức, thuận lợi với khách hàng.
● Tiến hành nghiên cứu để xác định giải pháp được đề xuất và các phương
pháp tiếp cận hiện có.
● Chuẩn bị một “tài liệu làm việc” và một chương trình nghị sự cho cuộc họp
chính thức.
● Tiến hành cuộc họp.
● Cùng nhau phát triển các thông số kỹ thuật nhỏ phản ánh dữ liệu, chức năng
và các tính năng hành vi của phần mềm.
● Xem xét từng thông số kỹ thuật nhỏ để biết tính chính xác, nhất quán và
không mơ hồ.
● Tập hợp các thông số kỹ thuật nhỏ vào một tài liệu phạm vi.
16. Dự án - Điều gì có thể sai trong một dự
án?
1. Những người làm phần mềm không hiểu nhu cầu của
khách hàng.
2. Phạm vi sản phẩm không được xác định rõ ràng.
3. Các thay đổi được quản lý kém.
4. Công nghệ được chọn thay đổi.
5. Nhu cầu kinh doanh thay đổi [hoặc không rõ ràng].
6. Thời hạn không thực tế.
7. Người dùng kháng cự.
8. Tài trợ bị mất [hoặc không bao giờ được nhận đúng
cách].
9. Nhóm dự án thiếu người có kỹ năng phù hợp.
10. Các nhà quản lý [và các học viên] tránh các bài học
kinh nghiệm và thực hành tốt nhất.
John Reel
17. Khái niệm chính - Dự
án
Bắt đầu bằng chân phải.
Điều này được thực hiện bằng cách làm việc chăm chỉ
(rất chăm chỉ) để hiểu vấn đề cần giải quyết và sau đó
đặt ra các mục tiêu và kỳ vọng thực tế cho tất cả
những người sẽ tham gia vào dự án.
Duy trì động lực.
Để duy trì đà phát triển, người quản lý dự án phải đưa
ra các biện pháp khuyến khích để giữ cho việc luân
chuyển nhân sự ở mức tối thiểu tuyệt đối, nhóm nên
nhấn mạnh chất lượng trong mọi nhiệm vụ mà nhóm
thực hiện và quản lý cấp cao nên làm mọi thứ có thể
để tránh cản trở nhóm.
18. Khái niệm chính - Dự
án
Theo dõi tiến độ.
Đối với một dự án phần mềm, tiến độ được theo dõi dưới
dạng sản phẩm công việc; quá trình phần mềm và các
biện pháp dự án có thể được thu thập và sử dụng để
đánh giá tiến độ
Đưa ra quyết định thông minh.
Về bản chất, các quyết định của người quản lý dự án và
nhóm phần mềm nên là "giữ cho nó đơn giản."
Tiến hành phân tích sau khi chết.
Thiết lập một cơ chế thống nhất để rút ra bài học kinh
nghiệm cho từng dự án. Đánh giá lịch trình đã lên kế
hoạch và thực tế, thu thập và phân tích các số liệu dự án
phần mềm, nhận phản hồi từ các thành viên trong nhóm
và khách hàng, đồng thời ghi lại các phát hiện dưới dạng
văn bản.
19. Nguyên tắc
W5HH
Tại sao hệ thống được phát triển?
Điều gì sẽ được thực hiện, bởi Khi nào?
Ai chịu trách nhiệm cho một chức năng?
Họ nằm ở đâu về mặt tổ chức?
Công việc sẽ được thực hiện như thế nào về
mặt kỹ thuật và quản lý?
Cần bao nhiêu cho mỗi tài nguyên?
Barry Boehm
20. State of Art – Định nghĩa dự án
● Một dự án là một nhiệm vụ được xác định rõ, là tập hợp của một số hoạt
động được thực hiện để đạt được mục tiêu (ví dụ: phát triển và phân phối
phần mềm). Một Dự án có thể được mô tả như sau:
● Mỗi dự án có thể có một mục tiêu duy nhất và khác biệt.
● Dự án không phải là hoạt động thường xuyên hoặc hoạt động hàng ngày.
● Dự án đi kèm với thời gian bắt đầu và thời gian kết thúc.
● Dự án kết thúc khi đạt được mục tiêu của nó, do đó đây là một giai đoạn
tạm thời trong vòng đời của một tổ chức.
● Dự án cần có đủ nguồn lực về thời gian, nhân lực, tài chính, vật chất và
ngân hàng tri thức.
dự án phần mềm
Dự án phần mềm là toàn bộ quy trình phát triển
phần mềm từ thu thập yêu cầu đến kiểm tra và
bảo trì, được thực hiện theo các phương pháp
thực hiện, trong một khoảng thời gian xác định để
đạt được sản phẩm phần mềm dự kiến.
21. Dự án - Thực tiễn quan
trọng
● Quản lý rủi ro chính thức: mười rủi ro hàng đầu cho
dự án này, khả năng xảy ra rủi ro, tác động nếu xảy ra
● Ước tính tiến độ và chi phí thực nghiệm: kích thước
ước tính hiện tại của phần mềm ứng dụng
● Quản lý dự án dựa trên số liệu: một chương trình số
liệu để đưa ra dấu hiệu sớm về các vấn đề đang phát
triển
● Theo dõi giá trị kiếm được: số liệu giá trị kiếm được
hàng tháng?
● Theo dõi lỗi so với các mục tiêu chất lượng: theo dõi
và báo cáo số lượng lỗi được tìm thấy, kiểm tra thực
thi từ khi bắt đầu chương trình, số lượng lỗi hiện
22. Các yếu tố quyết định chất lượng phần mềm & hiệu quả tổ chức
24. Tình trạng của
vấn đề
“Khi bạn có thể đo lường những gì bạn đang nói và diễn đạt
nó bằng những con số, thì bạn biết điều gì đó về nó; nhưng
khi bạn không thể đo lường, khi bạn không thể diễn đạt nó
bằng những con số, thì kiến thức của bạn thuộc loại ít ỏi và
không đạt yêu cầu: đó có thể là sự khởi đầu của kiến thức,
nhưng trong suy nghĩ của bạn, bạn hầu như không tiến tới
giai đoạn khoa học.”
[Chúa Kevin]
25. Mục tiêu đo lường phần mềm
● để hỗ trợ ước tính, kiểm soát chất lượng, đánh giá năng
suất và kiểm soát dự án
●
● có thể được các kỹ sư phần mềm sử dụng để giúp đánh giá
chất lượng của các sản phẩm công việc kỹ thuật và hỗ trợ
đưa ra quyết định chiến thuật khi dự án tiến hành
26. bước
● Xác định một tập hợp giới hạn các phép đo quy trình,
dự án và sản phẩm dễ thu thập (thường được chuẩn
hóa bằng cách sử dụng các phép đo định hướng kích
thước hoặc định hướng chức năng)
● Kết quả được phân tích và so sánh với mức trung bình
trong quá khứ cho các dự án tương tự được thực hiện
● Xu hướng được đánh giá và kết luận được tạo ra.
27. Các khái
niệm
Một biện pháp cung cấp một dấu hiệu định lượng về mức độ,
số lượng, kích thước, khả năng hoặc kích thước của một số
thuộc tính của sản phẩm hoặc quy trình
Đo lường là hành động xác định một biện pháp
Số liệu là thước đo định lượng về mức độ mà một hệ thống,
thành phần hoặc quy trình sở hữu một thuộc tính nhất định
[IEEE93, Thuật ngữ tiêu chuẩn của thuật ngữ kỹ thuật phần
mềm]
Một số liệu phần mềm liên quan đến các số đo riêng lẻ theo
một cách nào đó (số liệu quy trình, dự án và sản phẩm)
Chỉ báo là một thước đo hoặc sự kết hợp của các thước đo
cung cấp thông tin chi tiết về quy trình phần mềm, dự án
phần mềm hoặc chính sản phẩm
28. chỉ số dự án
Các chỉ số dự án cho phép người quản lý dự án
phần mềm
(1) đánh giá tình trạng của một dự án đang triển
khai,
(2) theo dõi các rủi ro tiềm ẩn,
(3) khám phá các khu vực có vấn đề trước khi chúng
trở nên “nguy kịch”,
(4) điều chỉnh luồng công việc hoặc nhiệm vụ,
(5) đánh giá khả năng của nhóm dự án trong việc
kiểm soát chất lượng sản phẩm công việc phần
mềm.
29. Đo lường phần mềm
●Các biện pháp trực tiếp
●bao gồm chi phí và nỗ lực áp dụng.
●bao gồm các dòng mã (LOC) được tạo, tốc
độ thực thi, kích thước bộ nhớ và các lỗi
được báo cáo trong một khoảng thời gian
nhất định.
●biện pháp gián tiếp
●bao gồm chức năng, chất lượng, độ phức
tạp, hiệu quả, độ tin cậy, khả năng bảo trì và
30. Số liệu định hướng
theo kích thước
Các phép đo phần mềm định hướng kích thước
được bắt nguồn bằng cách xem xét kích thước của
phần mềm đã được sản xuất
31. Số liệu định hướng
theo kích thước
●Lỗi trên mỗi KLOC (nghìn dòng mã).
●Lỗi trên mỗi KLOC.
●$ trên mỗi LỘC.
●Trang tài liệu cho mỗi KLOC.
●Công sức mỗi người-tháng.
●LOC mỗi người-tháng.
●$ cho mỗi trang tài liệu.
32. Số liệu hướng chức năng
●Các chỉ số phần mềm hướng chức năng sử dụng
thước đo chức năng do ứng dụng cung cấp làm giá
trị chuẩn hóa
●'chức năng' không thể được đo lường trực tiếp, nó
phải được tính gián tiếp bằng cách sử dụng các
biện pháp trực tiếp khác
●Một biện pháp được gọi là điểm chức năng được
đề xuất. Điểm chức năng dựa trên các phép đo có
thể đếm được (trực tiếp) về miền thông tin của
phần mềm và các đánh giá về độ phức tạp của
phần mềm
33. Số liệu hướng chức năng
● Điểm chức năng được tính bằng cách hoàn thành bảng sau
34. Số liệu hướng chức năng
●Năm đặc điểm miền thông tin được xác định và số
lượng được cung cấp ở vị trí bảng thích hợp. Giá trị
miền thông tin được xác định theo cách sau:
●Số lượng đầu vào của người dùng
●Số đầu ra của người dùng
●Số lượng yêu cầu của người dùng
●Số lượng tệp
●Số lượng giao diện bên ngoài
35. Số liệu hướng chức năng
●Số lượng đầu vào của người dùng. Mỗi đầu vào
của người dùng cung cấp dữ liệu định hướng
ứng dụng riêng biệt cho phần mềm đều được
tính. Đầu vào nên được phân biệt với yêu cầu,
được tính riêng
●Số lượng đầu ra của người dùng. Mỗi đầu ra
của người dùng cung cấp thông tin định hướng
ứng dụng cho người dùng đều được tính.
Trong ngữ cảnh này, đầu ra đề cập đến các báo
cáo, màn hình, thông báo lỗi, v.v. Các mục dữ
liệu riêng lẻ trong một báo cáo không được tính
riêng
36. Số liệu hướng chức năng
●Số lượng yêu cầu của người dùng. Một yêu cầu
được định nghĩa là một đầu vào trực tuyến dẫn
đến việc tạo ra một số phản hồi phần mềm ngay
lập tức dưới dạng đầu ra trực tuyến. Mỗi yêu
cầu riêng biệt được tính
●Số lượng tệp. Mỗi tệp chính logic (nghĩa là một
nhóm dữ liệu logic có thể là một phần của cơ
sở dữ liệu lớn hoặc một tệp riêng biệt) được
tính
●Số lượng giao diện bên ngoài. Tất cả các giao
diện có thể đọc được bằng máy (ví dụ: tệp dữ
37. Số liệu hướng chức năng
Để tính điểm chức năng (FP), mối quan hệ
sau đây được sử dụng:
FP = tổng số [0,65 + 0,01 Σ(Fi)]
Fi (i = 1 đến 14) là "giá trị điều chỉnh độ phức
tạp"
38. Số liệu hướng chức năng
Fi dựa trên câu trả lời cho các câu hỏi sau
1. Hệ thống có yêu cầu sao lưu và phục hồi đáng
tin cậy không?
2. Có cần truyền dữ liệu không?
3. Có các chức năng xử lý phân tán không?
4. Hiệu suất có quan trọng không?
5. Hệ thống sẽ chạy trong một môi trường hoạt
động hiện có, được sử dụng nhiều chứ?
6. Hệ thống có yêu cầu nhập liệu trực tuyến
không?
39. Số liệu hướng chức năng
7. Việc nhập dữ liệu trực tuyến có yêu cầu giao dịch
đầu vào phải được xây dựng trên nhiều màn hình hoặc
thao tác không?
8. Các tập tin chính có được cập nhật trực tuyến
không?
9. Đầu vào, đầu ra, tệp hoặc truy vấn có phức tạp
không?
10. Xử lý bên trong có phức tạp không?
11. Mã được thiết kế để có thể tái sử dụng?
12. Việc chuyển đổi và lắp đặt có bao gồm trong thiết
kế không?
13. Hệ thống có được thiết kế để cài đặt nhiều lần
trong các tổ chức khác nhau không?
14. Ứng dụng có được thiết kế để hỗ trợ người dùng
40. Số liệu hướng chức năng
●Mỗi câu hỏi này được trả lời bằng thang điểm từ 0
(không quan trọng hoặc có thể áp dụng) đến 5 (rất
cần thiết).
●Khi các điểm chức năng đã được tính toán, chúng
được sử dụng theo cách tương tự như LOC như
một cách để bình thường hóa các thước đo về
năng suất, chất lượng và các thuộc tính khác của
phần mềm:
●Lỗi trên mỗi FP
●Lỗi trên mỗi FP
●$ mỗi FP
41. Số liệu về chất lượng phần
mềm
●Chất lượng của một hệ thống chỉ tốt như các yêu
cầu mô tả vấn đề (đặc tả yêu cầu), thiết kế mô hình
hóa giải pháp (mô hình thiết kế), mã dẫn đến
chương trình thực thi (mã nguồn) và các bài kiểm
tra thực hiện phần mềm để phát hiện lỗi (trường
hợp thử nghiệm) và cả tiến trình của dự án
42. Đo lường các chỉ tiêu chất
lượng
Các chỉ số hữu ích:
tính đúng đắn. Một chương trình phải hoạt động chính xác
hoặc nó cung cấp ít giá trị cho người dùng. Tính chính xác
là mức độ mà phần mềm thực hiện chức năng cần thiết của
nó; lỗi trên mỗi KLOC được tính trong một khoảng thời gian
tiêu chuẩn, thường là một năm.
Khả năng bảo trì. Khả năng bảo trì là khả năng dễ dàng sửa
chữa chương trình nếu gặp lỗi, điều chỉnh nếu môi trường
của chương trình thay đổi hoặc nâng cao nếu khách hàng
mong muốn thay đổi yêu cầu; một số liệu theo định hướng
thời gian đơn giản là thời gian trung bình để thay đổi
(MTTC), thời gian cần thiết để phân tích yêu cầu thay đổi,
thiết kế một sửa đổi phù hợp, triển khai thay đổi, kiểm tra và
phân phối thay đổi cho tất cả người dùng.
43. Đo lường các chỉ tiêu chất
lượng
● Các chỉ số hữu ích:
● Chính trực. Thuộc tính này đo khả năng của một hệ thống
chống lại các cuộc tấn công (cả vô tình và cố ý) đối với an
ninh của nó. Các cuộc tấn công có thể được thực hiện trên
cả ba thành phần của phần mềm: chương trình, dữ liệu và
tài liệu.
● Để đo lường tính toàn vẹn, hai thuộc tính bổ sung phải
được xác định: mối đe dọa và bảo mật.
44. Đo lường các chỉ tiêu chất
lượng
Các chỉ số hữu ích:
Chính trực. Tính toàn vẹn của một hệ thống sau đó
có thể được định nghĩa là
tính toàn vẹn = tổng kết [(1 – mối đe dọa) (1 – bảo
mật)]
trong đó mối đe dọa và bảo mật được tổng hợp
theo từng loại tấn công.
Mối đe dọa là xác suất (có thể được ước tính hoặc
bắt nguồn từ bằng chứng thực nghiệm) rằng một
cuộc tấn công thuộc loại cụ thể sẽ xảy ra trong một
thời gian nhất định.
Bảo mật là xác suất (có thể được ước tính hoặc
bắt nguồn từ bằng chứng thực nghiệm) rằng cuộc
45. Đo lường các chỉ tiêu chất
lượng
● Các chỉ số hữu ích:
● Khả năng sử dụng. Nếu một chương trình không thân thiện
với người dùng, nó thường bị lỗi, ngay cả khi các chức
năng mà nó thực hiện là có giá trị. Khả năng sử dụng là một
nỗ lực để định lượng mức độ thân thiện với người dùng;
46. Đo lường các chỉ tiêu chất
lượng
Các chỉ số hữu ích:
Khả năng sử dụng có thể được đo lường theo bốn đặc điểm:
(1) kỹ năng thể chất và trí tuệ cần thiết để học hệ thống,
(2) thời gian cần thiết để trở nên hiệu quả vừa phải trong việc
sử dụng hệ thống,
(3) mức tăng ròng về năng suất (theo cách tiếp cận mà hệ
thống thay thế) được đo khi hệ thống được sử dụng bởi một
người có hiệu quả vừa phải,
(4) đánh giá chủ quan (đôi khi thu được thông qua bảng câu
hỏi) về thái độ của người dùng đối với hệ thống.
47. Hiệu quả loại bỏ lỗi
Một thước đo chất lượng mang lại lợi ích ở cả cấp độ dự
án và quy trình là hiệu quả loại bỏ lỗi (DRE).
DRE là thước đo khả năng sàng lọc của các hoạt động
kiểm soát và đảm bảo chất lượng khi chúng được áp dụng
xuyên suốt tất cả các hoạt động của khung quy trình.
DRE được định nghĩa theo cách sau:
DRE = E/(E + D)
Trong đó E là số lỗi được tìm thấy trước khi chuyển giao
phần mềm cho người dùng cuối và D là số lỗi được tìm
thấy sau khi chuyển giao.
Giá trị lý tưởng cho DRE là 1
49. Lập kế hoạch dự án phần
mềm
● Quản lý dự án phần mềm bắt đầu với một tập hợp các hoạt
động được gọi chung là lập kế hoạch dự án.
● Trước khi dự án có thể bắt đầu, người quản lý và nhóm
phần mềm phải ước tính
● công việc phải làm,
● các tài nguyên sẽ được yêu cầu,
● và thời gian sẽ trôi qua từ đầu đến cuối,
50. Mục tiêu lập kế hoạch dự
án
● Phạm vi phần mềm. Phạm vi phần mềm mô tả dữ liệu và
điều khiển sẽ được xử lý, chức năng, hiệu suất, các
ràng buộc, giao diện và độ tin cậy.
● Lấy thông tin về phạm vi phần mềm
● Ai đứng đằng sau yêu cầu cho công việc này?
● Ai sẽ sử dụng giải pháp?
● Lợi ích kinh tế của một giải pháp thành công là gì?
● Có nguồn nào khác cho giải pháp không?, v.v.
● tính khả thi
● Khi phạm vi được hiểu, nhóm phần mềm và những
người khác phải làm việc để xác định xem có thể thực
51. Mục tiêu lập kế hoạch dự
án
● Tài nguyên. Nhiệm vụ lập kế hoạch phần mềm thứ hai là
ước tính các tài nguyên cần thiết để hoàn thành nỗ lực
phát triển phần mềm.
52. Mục tiêu lập kế hoạch dự
án
● Tài nguyên. Mỗi tài nguyên được chỉ định với bốn đặc
điểm:
● mô tả tài nguyên,
● một tuyên bố về sự sẵn có,
● thời gian khi tài nguyên sẽ được yêu cầu;
● khoảng thời gian tài nguyên đó sẽ được áp dụng
53. Mục tiêu lập kế hoạch dự
án
● Tài nguyên.
● Nguồn nhân lực.
● Người lập kế hoạch bắt đầu bằng cách đánh giá phạm
vi và lựa chọn các kỹ năng cần thiết để hoàn thành quá
trình phát triển. Cả vị trí tổ chức (ví dụ: người quản lý,
kỹ sư phần mềm cao cấp) và chuyên môn (ví dụ: viễn
thông, cơ sở dữ liệu, máy khách/máy chủ) đều được chỉ
định.
● Đối với các dự án tương đối nhỏ (một người-năm hoặc
ít hơn), một cá nhân có thể thực hiện tất cả các nhiệm
vụ công nghệ phần mềm, tham khảo ý kiến của các
chuyên gia theo yêu cầu.
● Số lượng người được yêu cầu cho một dự án phần
54. Mục tiêu lập kế hoạch dự
án
● Tài nguyên.
● Tài nguyên phần mềm có thể tái sử dụng. Bốn loại tài
nguyên phần mềm:
● Linh kiện sẵn có. Phần mềm hiện có có thể được mua
từ bên thứ ba hoặc đã được phát triển nội bộ cho một
dự án trước đây
● Linh kiện full kinh nghiệm. Thông số kỹ thuật, thiết kế,
mã hoặc dữ liệu thử nghiệm hiện có được phát triển
cho các dự án trước đây tương tự như phần mềm được
xây dựng cho dự án hiện tại. Các thành viên của nhóm
phần mềm hiện tại đã có đầy đủ kinh nghiệm trong lĩnh
vực ứng dụng được đại diện bởi các thành phần này.
55. Mục tiêu lập kế hoạch dự
án
Tài nguyên.
Tài nguyên phần mềm có thể tái sử dụng. Bốn loại
tài nguyên phần mềm (tiếp):
Các thành phần kinh nghiệm một phần. Thông số
kỹ thuật, thiết kế, mã hoặc dữ liệu thử nghiệm
hiện có được phát triển cho các dự án trước đây
có liên quan đến phần mềm được xây dựng cho
dự án hiện tại nhưng sẽ yêu cầu sửa đổi đáng kể.
Các thành viên của nhóm phần mềm hiện tại chỉ
có kinh nghiệm hạn chế trong lĩnh vực ứng dụng
được đại diện bởi các thành phần này
Linh kiện mới. Các thành phần phần mềm phải
được xây dựng bởi nhóm phần mềm dành riêng
cho nhu cầu của dự án hiện tại.
56. Mục tiêu lập kế hoạch dự
án
● Tài nguyên.
● Tài nguyên Môi trường. Môi trường công nghệ phần
mềm (SEE) kết hợp phần cứng và phần mềm. Người lập
kế hoạch dự án phải quy định khung thời gian cần thiết
cho phần cứng và phần mềm và xác minh rằng các tài
nguyên này sẽ sẵn có.
57. Dự toán công trình phần
mềm
● Ước tính chi phí và nỗ lực của phần mềm.
● Nhiều biến số - con người, kỹ thuật, môi trường, chính trị -
có thể ảnh hưởng đến chi phí cuối cùng của phần mềm và
nỗ lực.
● Để đạt được ước tính chi phí và nỗ lực đáng tin cậy:
● Trì hoãn ước tính cho đến cuối dự án (rõ ràng, chúng ta có
thể đạt được ước tính chính xác 100% sau khi dự án hoàn
thành!).
● Ước tính cơ sở cho các dự án tương tự đã được hoàn
thành.
● Sử dụng các kỹ thuật phân tách tương đối đơn giản để tạo
ước tính chi phí và nỗ lực của dự án.
58. Dự toán công trình phần
mềm
Kỹ thuật ước lượng dự án phần mềm
Các kỹ thuật phân tách sử dụng cách tiếp cận "chia
để trị" để ước tính dự án phần mềm. Bằng cách phân
tách dự án thành các chức năng chính và các hoạt
động kỹ thuật phần mềm liên quan, ước tính chi phí
và nỗ lực có thể được thực hiện theo kiểu từng
bước (Ước tính dựa trên LOC, dựa trên FP) .
Các mô hình ước lượng theo kinh nghiệm có thể
được sử dụng để bổ sung cho các kỹ thuật phân
tách và đưa ra phương pháp ước lượng có giá trị
tiềm năng theo cách riêng của chúng (Mô hình
COCOMO).
Các công cụ ước tính tự động thực hiện một hoặc
nhiều kỹ thuật phân tách hoặc mô hình thực nghiệm.
60. Rủi ro phần
mềm
● Rủi ro luôn bao hàm hai đặc điểm
● Tính không chắc chắn - rủi ro có thể xảy ra hoặc không xảy
ra; nghĩa là không có rủi ro nào có thể xảy ra 100%.
● Tổn thất - nếu rủi ro trở thành hiện thực thì sẽ xảy ra những
hậu quả hoặc tổn thất không mong muốn.
61. Rủi ro phần
mềm
● Rủi ro luôn bao hàm hai đặc điểm
● Tính không chắc chắn - rủi ro có thể xảy ra hoặc không xảy
ra; nghĩa là không có rủi ro nào có thể xảy ra 100%.
● Tổn thất - nếu rủi ro trở thành hiện thực thì sẽ xảy ra những
hậu quả hoặc tổn thất không mong muốn.
62. Rủi ro phần
mềm
Rủi ro dự án đe dọa kế hoạch dự án, nếu rủi ro dự án trở
thành hiện thực, có khả năng lịch trình dự án sẽ trượt và chi
phí sẽ tăng lên (ngân sách, tiến độ, nhân sự, tài nguyên,
khách hàng và các vấn đề về yêu cầu).
Rủi ro kỹ thuật đe dọa chất lượng và tính kịp thời của phần
mềm được sản xuất. Nếu rủi ro kỹ thuật trở thành hiện thực,
việc triển khai có thể trở nên khó khăn hoặc không thể thực
hiện được (các vấn đề về thiết kế, triển khai, giao diện, xác
minh và bảo trì).
Rủi ro kinh doanh đe dọa khả năng tồn tại của phần mềm
được xây dựng.
63. Rủi ro phần
mềm
Xác định rủi ro là một nỗ lực có hệ thống để xác định các mối
đe dọa đối với kế hoạch dự án (ước tính, lịch trình, tải tài
nguyên, …)
Danh sách kiểm tra hạng mục rủi ro
Kích thước sản phẩm—rủi ro liên quan đến kích thước tổng
thể của phần mềm được xây dựng hoặc sửa đổi.
Tác động kinh doanh—rủi ro liên quan đến các ràng buộc do
ban quản lý áp đặt đối với thị trường
Đặc điểm của khách hàng—rủi ro liên quan đến sự phức tạp
của khách hàng và khả năng của nhà phát triển trong việc
giao tiếp với khách hàng một cách kịp thời.
64. Rủi ro phần
mềm
Danh sách kiểm tra hạng mục rủi ro (tiếp)
Định nghĩa quy trình—rủi ro liên quan đến mức độ mà quy
trình phần mềm đã được xác định và được tuân theo bởi tổ
chức phát triển
Môi trường phát triển—rủi ro liên quan đến sự sẵn có và chất
lượng của các công cụ được sử dụng để xây dựng sản
phẩm
Công nghệ được xây dựng—rủi ro liên quan đến sự phức tạp
của hệ thống được xây dựng và "tính mới" của công nghệ
được đóng gói bởi hệ thống
Quy mô và kinh nghiệm của nhân viên—những rủi ro liên
quan đến kinh nghiệm kỹ thuật và dự án tổng thể của các kỹ
sư phần mềm, những người sẽ thực hiện công việc.
65. Rủi ro phần
mềm
Dự báo rủi ro (được gọi là ước tính rủi ro), cố gắng đánh giá
từng rủi ro theo hai cách
khả năng hoặc xác suất rủi ro là có thật
hậu quả của các vấn đề liên quan đến rủi ro, nếu nó xảy ra.
67. Rủi ro phần
mềm
sàng lọc rủi ro
Để tinh chỉnh rủi ro thành một tập hợp các rủi ro chi tiết hơn
Thể hiện rủi ro trong điều kiện-chuyển đổi-hậu quả (CTC)
“Cho rằng <điều kiện> thì có mối lo ngại rằng (có thể) <hậu
quả>.”
Sau đó <điều kiện> sẽ được tinh chỉnh thành <điều kiện
con 1>, <điều kiện con 2>, <điều kiện con 3>,…
70. Lập kế hoạch dự
án
Lập lịch dự án phần mềm là một hoạt động phân phối nỗ lực
ước tính trong suốt thời gian dự án đã lên kế hoạch bằng cách
phân bổ nỗ lực cho các nhiệm vụ kỹ thuật phần mềm cụ thể.
Một lịch trình vĩ mô được tinh chỉnh thành một lịch trình chi tiết.
Phân bổ Nỗ lực: Quy tắc 40–20–40.
71. Lập kế hoạch dự
án
Xác định một bộ nhiệm vụ
Một bộ nhiệm vụ là một tập hợp các nhiệm vụ công việc
kỹ thuật phần mềm, các cột mốc và sản phẩm bàn giao
phải được hoàn thành để hoàn thành một dự án cụ thể.
Xác định mạng tác vụ
Mạng nhiệm vụ (mạng hoạt động) là biểu diễn đồ họa của
luồng nhiệm vụ cho một dự án.
72. Lập kế hoạch dự
án
Một ví dụ về mạng nhiệm vụ để phát triển khái niệm
73. Lập kế hoạch dự
án
lập kế hoạch
Hai phương pháp: Kỹ thuật đánh giá và xem xét chương
trình (PERT) và phương pháp đường tới hạn (CPM).
Được thúc đẩy bởi: ước tính nỗ lực, phân tách chức năng
sản phẩm, lựa chọn mô hình quy trình và tập nhiệm vụ
thích hợp, phân tách nhiệm vụ.
Xác định đường dẫn quan trọng—chuỗi nhiệm vụ xác định
thời lượng của dự án;
Thiết lập các ước tính thời gian “rất có thể” cho từng
nhiệm vụ bằng cách áp dụng các mô hình thống kê;
Tính “thời gian giới hạn” xác định “cửa sổ” thời gian cho
một tác vụ cụ thể.
74. Lập kế hoạch dự
án
Biểu đồ dòng thời gian (biểu đồ Gantt)
bắt đầu với một tập hợp các nhiệm vụ (cấu trúc phân chia
công việc)
nỗ lực, thời lượng và ngày bắt đầu sau đó được nhập cho
từng nhiệm vụ (có thể chỉ định các cá nhân cụ thể).
75. Lập kế hoạch dự
án
Bảng dự án
liệt kê tất cả các nhiệm vụ của dự án, ngày bắt đầu và
ngày kết thúc theo kế hoạch và thực tế của chúng, cùng
nhiều thông tin liên quan
các bảng dự án cho phép người quản lý dự án theo dõi
tiến độ.
76. Theo dõi lịch trình
Tiến hành các cuộc họp tình trạng dự án định kỳ, trong đó mỗi
thành viên trong nhóm báo cáo tiến độ và các vấn đề.
Đánh giá kết quả của tất cả các đánh giá được thực hiện trong
suốt quy trình công nghệ phần mềm.
Xác định xem các mốc quan trọng của dự án chính thức đã
được hoàn thành trước ngày dự kiến hay chưa.
So sánh ngày bắt đầu thực tế với ngày bắt đầu theo kế hoạch
cho từng nhiệm vụ dự án được liệt kê trong bảng dự án.
Gặp gỡ không chính thức với các học viên để có được đánh
giá chủ quan của họ về tiến độ cho đến nay và các vấn đề sắp
xảy ra.
77. kế hoạch
dự án
● Kế hoạch dự án phần mềm
● truyền đạt phạm vi và tài nguyên cho ban quản lý phần
mềm, nhân viên kỹ thuật và khách hàng;
● xác định rủi ro và đề xuất các kỹ thuật tránh rủi ro;
● xác định chi phí và lịch trình để xem xét quản lý;
● cung cấp một cách tiếp cận tổng thể để phát triển phần
mềm cho tất cả những người liên quan đến dự án;
● phác thảo cách đảm bảo chất lượng và thay đổi sẽ
