Bài giảng Công nghệ phần mềm - Quản lý dự án phần mềm

z Thực hiện các nhiệm vụ song song khi
có thể
31
Lập lịch nên
z Giảm tối đa thời gian thừa
z Tận dụng tối đa các nguồn lực có thể
z Điều phối tài nguyên (chỗ thừa/thiếu)
z Xem xét các hạn chế
− phụ thuộc tiến trình
− phụ thuộc tài nguyên
z Là một qui trình lặp lại
− theo dõi thời gian biểu
− sửa chữa, lập lại thời gian biểu
z Sử dụng các công cụ tự động
32
I.1.1 Identify need and benefits
 Meet with customers
 Identify needs and project constraints
 Establish product statement
 Milestone: product statement defined
I.1.2 Define desired output/control/input (OCI)
 Scope keyboard functions
 Scope voice input functions
 Scope modes of interaction
 Scope document diagnostics
 Scope other WP functions
 Document OCI
 FTR: Review OCI with customer
 Revise OCI as required;
 Milestone; OCI defined
I.1.3 Define the functionality/behavior
 Define keyboard functions
 Define voice input functions
 Decribe modes of interaction
 Decribe spell/grammar check
 Decribe other WP functions
 FTR: Review OCI definition with customer
 Revise as required
 Milestone: OCI defintition complete
I.1.4 Isolate software elements
 Milestone: Software elements defined
I.1.5 Research availability of existing software
 Reseach text editiong components
 Research voice input components
 Research file management components
 Research Spell/Grammar check components
 Milestone: Reusable components identified
I.1.6 Define technical feasibility
 Evaluate voice input
 Evaluate grammar checking
 Milestone: Technical feasibility assessed
I.1.7 Make quick estimate of size
I.1.8 Create a Scope Definition
 Review scope document with customer
 Revise document as required
 Milestone: Scope document complete
week 1 week 2 week 3 week 4Work tasks week 5
33
Tham khảo
z Thời gian thực tế thường kéo dài hơn
ước lượng từ 25% đến 40%.
z Lý do:
− Một số công việc không ước lượng được
− Một số công việc phải làm lại
− Người phát triển tham gia đồng thời nhiều
công việc
34
3. Đảm bảo chất lượng phần mềm
z Software Quality Assurance – SQA
− Là công việc xuyên suốt quá trình phát triển
phần mềm
z Thế nào là chất lượng?
− Chất lượng của phần cứng = sự ổn định, sự
đồng đều
− Chất lượng phần mềm
ƒ Tin cậy, dễ sử dụng, hiệu quả, bảo trì
ƒ Khó đo đạc trực quan
35
Đảm bảo chất lượng
z Đảm bảo chất lượng khi bắt đầu dự án
− Con người
− Qui trình
− Công cụ
z Đảm bảo chất lượng trong quá trình
thực hiện dự án
− tuân thủ qui trình (các chuẩn, các tài liệu)
− họp xét duyệt
− kiểm thử sản phẩm
36
Giá trả cho tìm và sửa lỗi
100
10
log
scale
1
Req. Designcode
testsystem
test
field
use
0.751.00
1.50
3.00
10.00
60.00-100.00
37
Xét duyệt
z Tại mỗi pha công việc, cần họp xét duyệt để
đảm bảo chất lượng
− không để lỗi truyền sang pha sau
z Thực hiện theo nhóm
z Xét duyệt các tài liệu
− Phân tích
− Thiết kế
− Mã nguồn
− Tài liệu người dùng
− ...
38
4. Nghiên cứu khả thi
z Xác định, phân tích các yếu tố
− Phạm vi phần mềm
− Khả thi về kinh tế
− Khả thi về kỹ thuật
− Khả thi về pháp lý
− Các rủi ro và biện pháp khắc phục
39
Khả thi về kinh tế
z Phân tích lợi ích - chi phí
− chi phí xây dựng
− phí tổn vận hành
− hiệu quả kinh tế
− vị trí của sản phẩm
− khả năng tài chính của khách hàng
z Khách hàng và nhà phát triển có cách nhìn
khác nhau về tính kinh tế, nhà phát triển cần
thuyết phục khách hàng về tính kinh tế
40
Khả thi về kỹ thuật
z Khó đánh giá ở giai đoạn phân tích
− có công nghệ để thực hiện không?
− có năng lực thực hiện không?
− có tài nguyên (phần cứng) để thực hiện
không?
− khách hàng có vận hành được không
41
Khả thi về pháp lý
z Khả thi về pháp lý là yếu tố ít quen thuộc
đối với người phát triển
− Vi phạm bản quyền
ƒ sử dụng mã nguồn của người khác...
ƒ cung cấp âm nhạc trực tuyến...
− Vi phạm tự do cá nhân
ƒ kiểm duyệt email, phá mật khẩu...
− Gây hại đối với bên thứ ba
ƒ virus, spam email, DoS
− Các vi phạm pháp luật khác
ƒ cung cấp các dịch vụ cấm,...
42
Rủi ro và biện pháp
z Các nhân tố có thể làm thất bại dự án
− rủi ro kỹ thuật: quá khó
− rủi ro kinh tế: quá đắt
− rủi ro thời gian: thời gian quá ngắn
phân hoạch yêu cầu
• cần thiết
• mong muốn
• phụ (optional)
43
Báo cáo khả thi
z cần đưa ra quyết định
− làm
− không làm
− xem xét lại
44
Quản lý rủi ro
z Rủi ro là các sự kiện khiến dự án thất bại
− chi phí quá cao
− thời gian quá dài
− tính năng quá kém
z Là các yếu tố có thể quản lý được
z Nhiệm vụ của người quản lý dự án
− xác định (dự đoán) rủi ro
− phân tích rủi ro (khả năng và thiệt hại)
− quản lý rủi ro (đưa ra giải pháp)
− giám sát (theo dõi sự xuất hiện, tác động của rủi ro) 
và thực hiện biện pháp quản lý
45
Quản lý rủi ro
z Dựa trên phân hoạch yêu cầu
− chức năng cần thiết
− chức năng mong muốn
− chức năng phụ thêm
z Nguyên lý Pareto (80-20)
z Phân tích, đưa ra quyết định có áp dụng
biện pháp quản lý cần thiết hay không
− dựa trên thống kê (kinh nghiệm)
− dùng cây quyết định
46
5. Quản lý nhân sự
z Con người là yếu tố quan trọng nhất trong
phát triển phần mềm
z Các thành viên rất khác nhau về năng lực
z Một số các công việc đặc thù không phải ai
cũng làm được
− lập trình hệ thống
− giao diện đồ họa cao cấp
− điều khiển thiết bị
− cơ sở dữ liệu
47
Nhóm và đặc trưng
z Phần mềm phát triển theo nhóm
z Kích thước tối ưu của nhóm: 3~8 người
z Tổ chức nhóm
− lập trình viên
− chuyên gia giao diện
− chuyên gia miền ứng dụng
− thủ thư phần mềm (quản lý cấu hình)
− kiểm thử viên
z Cần có
− team leader
− technical leader
48
Nhóm và đặc trưng
z Không nên tổ chức nhóm quá lớn
− thời gian cho giao tiếp sẽ tăng cao
− khó tăng tốc độ bằng cách thêm người
z Một số công việc chỉ nên để cho một
người thực hiện
z Cần phân rã dự án lớn thành các dự án
nhỏ
49
Phân bổ thời gian làm việc
50%
giao tiếp
với các
thành viên
khác
20%
không trực tiếp
làm việc
30%
làm việc
50
Một số cách tổ chức nhóm
z Nhóm ngang quyền (democratic team)
− Công việc được thảo luận và các thành viên thống
nhất giải pháp chung
− Các thành viên đều có kinh nghiệm và năng lực
z Nhóm XP
− Một dạng của ngang quyền, lập trình đôi và chịu
trách nhiệm chung
z Nhóm quyền lực tập trung (chief programmer 
team)
− Nhóm trưởng có năng lực vượt trội và là người
thiết kế chính
− Các thành viên khác thực hiện công việc chi tiết
51
Nhóm làm việc hiệu quả
z Các mục đích được thống nhất
z Thành viên tin tưởng vào vai trò và mục tiêu
z Chấp nhận mục tiêu và tiêu chí chất lượng
z Có phương thức trao đổi thông tin hiệu quả
z họp, trao đổi ý tưởng, kiểm soát thay đổi
z Xác lập được mối quan hệ hợp tác giữa các
thành viên
52
6. Quản lý thay đổi
z Một trong các lý do khiến cho dự án thất
bại
z Luôn có sự thay đổi
− yêu cầu, thiết kế, mã hóa, sửa lỗi…
− phần mềm luôn tiến hóa
z Không nhận ra sự thay đổi của vấn đề
z không có phương pháp hiệu quả để
quản lý sự thay đổi
53
Quản lý thay đổi
z Định nghĩa thay đổi với bất cứ hoạt động
nào:
− phạm vi
− kết quả bàn giao
− kiến trúc cơ bản
− chi phí
− lịch trình
z Lập tài liệu đầy đủ về các thay đổi, đảm
bảo các thành viên hiểu rõ về các thay đổi
− sử dụng công cụ hỗ trợ
54
Quản lý cấu hình phần mềm
Configuration management
z Nhiệm vụ của quản lý cấu hình:
− quản lý phiên bản phần mềm
− lưu trữ tài liệu, mã nguồn, dữ liệu
− tạo điểm truy cập duy nhất (đảm bảo tính thống
nhất của mã nguồn)
z Trên diện hẹp, còn gọi là quản lý mã nguồn
55
Lợi ích
• Cung cấp cho người phát triển phiên bản
mới nhất của phần mềm
• Quản lý các mã nguồn được lưu trữ phân
tán
• Quản lý các phiên bản khác nhau
• Ghi chú lý do của sửa đổi mã nguồn
• Dễ dàng truy cập các phiên bản cũ
• Tích kiệm không gian đĩa
56
Quản lý phiên bản
z Thế nào là phiên bản phần mềm
− version
− variant
− release
z Phải đặt ra các tiêu chí để xác định phiên
bản, tiêu chí để định danh phiên bản
57
Phương thức hoạt động
• Lưu trữ tập trung
- mã nguồn, tài liệu, công cụ
• Lưu trữ duy nhất (logic)
• Quản lý sửa đổi
- không cho phép sửa đổi đồng thời
- lưu trữ phiên bản cũ
- thông tin sửa đổi: lý do, người thực hiện, 
thời điểm
58
Nội dung lưu trữ
• Tài liệu
- phân tích, thiết kế, tài liệu người dùng…
• Mã nguồn
• Công cụ phát triển
- cần công cụ cũ để biên dịch lại các
mã nguồn cũ cho việc bảo trì
• Các bộ dữ liệu test
Với phần mềm lớn, phải quản lý hàng nghìn tài liệu
59
Chia sẻ mã nguồn
Nhiều người đồng thời phát triển một tệp mã nguồn
• Sử dụng cơ chế lock/unlock chỉ cho phép
một người được quyền sửa đổi tại một thời điểm
- lock (check out): mở tệp để sửa đổi
- unlock (check in): kết thúc sửa đổi
Đồng thời sửa đổi / hệ thống giáp nối các
sửa đổi một cách tự động
60
Các công cụ
z RCS
− chạy trên hệ điều hành Solaris
− quản lí tệp
− check out/check in
z CVS
− dựa trên RCS
− dùng cơ chế ghép nối sửa đổi
z Visual SourceSafe
− trong bộ công cụ Visual Studio của Microsoft
− quản lí project
− check out/check in
61
7. Công cụ hỗ trợ quản lý dự án
z Microsoft Project 2000
− Hỗ trợ quản lý dự án phần mềm
z Microsoft SourceSafe
− Quản lý cấu hình, mã nguồn
z Visio 2000
− Tạo bảng biểu, mô hình
z 
62
63
64
Gantt Chart tạo bằng Visio 2000
ID Task Name Start End Duration
Feb 22 2004 Feb 29 2004
23 24 25 26 27 28 29 1 2 3 4
1 2d2/24/20042/23/2004GÆp gì kh¸ch
hµng
2 2d2/26/20042/25/2004Ph©n tÝch yªu cÇu
3 1d2/27/20042/27/2004 §Æc t¶ yªu cÇu
4 3d3/3/20043/1/2004Ph©n tÝch hÖ thèng
5 5d3/10/20043/4/2004ThiÕt kÕ tæng thÓ
Mar 7 2004
5 6 7 8 9 10 11
6
65
Timeline tạo bằng Visio 2000
66
67
Tổng kết: Quản lý dự án
z Người quản lý cần có kinh nghiệm, phải cứng
rắn
− Được trang bị kiến thức về quản lý dự án PM
− Có thâm niên trong việc phát triển phần mềm
ƒ Đã từng tham gia các công đoạn của quá trình phát triển
phần mềm
ƒ Kinh nghiệm đóng vai trò then chốt
ƒ Có trình độ quản lý tốt
ƒ Làm việc có kế hoạch
ƒ …
z Cần có các độ đo
z Phải được lập tài liệu
z Luôn cần xem xét, điều chỉnh
68