Chương 2: Vòng đời phần mềm

• 1. Định nghĩa
NHẬP MÔN • 2. Quy trình phát triển phần mềm
CÔNG NGHỆ PHẦN MỀM • 3. Một số mô hình phát triển phần mềm
– 3.1. Mô hình CMM
(INTRODUCTION TO SOFTWARE – 3.2. Mô hình tuyến tính
– 3.3. Mô hình chế thử
ENGINEERING) – 3.4. Mô hình phát triển ứng dụng nhanh
– 3.5. Các mô hình tiến hóa
– 3.6. Mô hình hướng thành phần
– 3.7. Mô hình RUP
– 3.8. Các kỹ thuật thế hệ thứ 4
• 4. Đánh giá sản phẩm và quy trình

1 2

1 2

Chương 2: Vòng đời phần mềm Vòng đời phần mềm

2.1. Định nghĩa (Vòng đời phần mềm) • Mọi sản phẩm phần mềm đều có vòng đời.
– Vòng đời phần mềm là thời kỳ tính từ khi phần • Vòng đời thường khá dài — một số sản phẩm
mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc phần mềm đã “tồn tại” được 30 năm.
hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng
cho đến khi loại bỏ không đâu dùng) • Vòng đời có thể được rút ngắn do tiến bộ
– Quy trình phần mềm (vòng đời phần mềm) được công nghệ
phân chia thành các pha chính: phân tích, thiết kế,
chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có
khác nhau theo từng người

3 4

3 4
 Các phương pháp luận và kỹ thuật
Các pha trong vòng đời PM
cho từng pha
• Một cách rõ ràng hoặc rõ ràng, tất cả các sản
phẩm phần mềm đều trải qua ít nhất các giai Tên pha Nội dung nghiệp vụ Phương pháp, kỹ thuật
Xác định Đặc tả yêu cầu người dùng
đoạn sau: yêu cầu Xác định yêu cầu phần mềm
Phân tích cấu trúc hóa
– Yêu cầu — xác định nhu cầu của khách hàng và các Thiết kế Thiết kế cơ bản phần mềm
Thiết kế cấu trúc hóa
ràng buộc của sản phẩm hệ thống Thiết kế cấu trúc ngoài của phần mềm
– Thiết kế — xác định cấu trúc / tổ chức của hệ thống Thiết kế
Là thiết kế chi tiết: Thiết kế cấu trúc bên trong Lập trình cấu trúc
phần mềm] chương trình
của phần mềm (đơn vị chương trình hoặc Phương pháp Jackson
môđun) Phương pháp Warnier
– Mã hóa — viết phần mềm Lập trình Mã hóa bởi ngôn ngữ lập trình Mã hóa cấu trúc hóa
– Kiểm thử — vận hành hệ thống để tìm và loại bỏ các Đảm bảo Phương pháp kiểm thử
khiếm khuyết chất lượng
Kiểm tra chất lượng phần mềm đã phát triển
chương trình
– Bảo trì — sửa chữa và nâng cao sản phẩm sau khi Vận hành Sử dụng, vận hành phần mềm đã phát triển.
Chưa cụ thể
khách hàng triển khai Bảo trì Biến đổi, điều chỉnh phần mềm

5 6

5 6

Các mô hình vòng đời phần mềm 2. Quy trình phát triển phần mềm
• Quá trình là một tập hợp các hoạt động, với các đầu vào và
đầu ra được xác định rõ ràng, để hoàn thành một số nhiệm Khung quy trình chung (Common process framework)
vụ.
• Mô hình vòng đời là một mô tả về một quá trình thực hiện Hoạt động khung (Framework activities)
một sản phẩm phần mềm trong toàn bộ hoặc một phần Tập tác vụ (Task sets)
vòng đời của nó. Tác vụ (Tasks)
– Các mô hình vòng đời có xu hướng tập trung vào các pha chính
của chu kỳ và mối quan hệ của chúng với các pha khác. Điểm quan trọng
(milestones),sản phẩm chuyển
– Các nghiên cứu gần đây về quy trình phần mềm đã xem xét chi giao (deliverables)
tiết nhiều khía cạnh của việc phát triển và bảo trì.
– Mô hình vòng đời là một mô tả quy trình phần mềm, nhưng Điểm Kiểm Tra Chất Lượng
thuật ngữ mô hình vòng đời có trước các cuộc thảo luận về quy (SQA points)
trình phần mềm. Các hoạt động giám sát, đánh giá kỹ thuật, đảm bảo chất
lượng phần mềm, quản lý cấu hình, quản lý rủi ro, ...
(Umbrella activities)
7 8

7 8
 3. Một số mô hình phát triển PM 3.1. Mô hình khả năng thuần thục

3.1. Capability Maturity Model (CMM by SEI): Tại sao phải sử dụng mô hình CMM trong công
nghệ làm phần mềm?
Mô hình khả năng thuần thục • Khó khăn khi không sử
dụng CMM
– Các khái niệm • Các tiến trình phần mềm thường
– Tại sao sử dụng mô hình CMM bị thay đổi cập nhật mà không có
sự chuần bị trước.
– Các thức sử dụng mô hình • Đặc tả một tiến trình phần mềm
không chặt chẽ, dẫn đến sự
khủng hoảng khi thực hiện một
dự án.
• Thiếu cơ sở để đánh giá chất
lượng phần mềm, để đưa ra
phương thức tiến hành và cách
giải quyết các vấn đề phát sinh.
• Thuận lợi khi sử dụng
CMM
• Dễ dàng quản lý phát triển phần mềm.
Các tiến trình được cập nhật qua sự
điều khiển của các nhà phần tích và
kiểm thử.
• Vai trò, trách nhiệm của mỗi thành
viên trong các tiến trình được phân
định rõ ràng.
• Quản lý chất lượng của phần mềm,
thoả mãn các yêu cầu khách hàng. Có
cơ sơ chuẩn xác đánh giá chất lượng,
thời gian, chi phí và phân tích dự án và
các tiến trình.

9 10

9 10

Các khái niệm cơ bản trong CMM
• Tiến trình (Process)
– Một tiến trình phần mềm là một tập hợp các hành
động, phương thức, thực hành, thay đổi mà người ta
dùng để duy trì và phát triển phần mềm cũng như các
thành phần liên quan tới chúng (ví dụ: kế hoạch dự
án, thiết kế, lập trình, kiểm thử, tài liệu hướng dẫn...).
• Khả năng tiến trình phần mềm
(Software Process Capability)
– Cho biết phạm vi kết quả có thể mong đợi của một
tiến trình phần mềm.
– Dự đoán khả năng làm dự án phần mềm tiếp theo của
công ty.
11
Thực thi tiến trình phần mềm
(Software Process Performance)
• Thực thi tiến trình phần mềm cho biết kết quả
thực tế của một tiến trình phần mềm.
• Hướng tới kết quả đạt được còn khả năng tiến
trình phần mềm cho thấy kết quả có thể mong
đợi.
• Do phụ thuộc vào đặc trưng của dự án và từng
trường hợp cụ thể, nên kết quả thực tế thường
không phản ánh đầy đủ khả năng tiến trình của
một công ty.
12

11 12
 Độ thuần thục của tiến trình PM Mô hình chi tiết các thành phần trong
(Software process maturity) cấu trúc CMM.
Mức độ thuần nhận được từ
thục
• Chỉ rõ một tiến trình phần mềm được xác chỉ ra
Các vùng tiến
tổ chức bởi
định, quản lý, đánh giá, điều khiển, đạt hiệu trình chính

Khả năng
quả một cách rõ ràng. tiến trình
đạt được Các tính năng phổ
nhận được từ
biến
• Cho biết khả năng phát triển, chỉ ra giá trị của
Các mục tiêu ánh xạ Các thực hành
tiến trình phần mềm, tính vững chắc của dự chính

án. Thực thi hoặc mô tả

thể chế hoá
Cơ sỏ hạ tầng hoặc các
hoạt động
13 14

13 14

Mô hình 5 mức của CMM Mô hình 5 mức của CMM

Tiến trình phần mềm mang tính chất Có sự cải tiến hơn, chiến lược
tuỳ tiện, lộn xộn, có ít tiến trình quản lý dự án vµ thủ tục để thực
được xác định trước, hiệu quả của thi chiến lược ấy được thiết lập.
công việc mang tính riêng lẻ. Các kế hoạch và quản lý dự án
Khó có được một môi trường làm mới được dựa trên những kinh
việc ổn định. Kế hoạch và ngân sách, tiến trình cải Cải tiến nghiệm của dự án cũ. Tiến trình cải Cải tiến
chất lượng sản phẩm và vận hành tiến liên tục (5) tiến liên tục (5)
không thể dự đoán trước được.

Tiến trình dự Được quản lý Tiến trình dự Được quản lý

đoán được (4) đoán được (4)

Tiến trình ổn định, Được định nghĩa Tiến trình ổn định, Được định nghĩa
chuẩn (3) chuẩn (3)

Tiến trình có Có tính lặp lại Tiến trình có Có tính lặp lại
kỷ luật (2) Quá trình vận hành phụ thuộc vào khả năng của từng cá
kỷ luật (2) Kết quả là đưa được những hiệu quả quản lý tiến trình của
nhân riêng lẻ, và thường xuyên thay đổi do phụ thuộc vào kỹ một dự án nµy vào một dự án khác. Điều này cho phép lặp
năng, trình độ hiểu biết và các hoạt động của từng thành lại (repeatable) những thành công đối với một dự án tương
Ban đầu viên trong dự án. Ban đầu tự mặc dù có thể các dự án này cũng có những điểm khác
(1) (1) biệt.

15 16

15 16
 Mô hình 5 mức của CMM Mô hình 5 mức của CMM
Lập được tài liệu tiến trình tiêu Mục tiêu là điều khiển tiến trình.
chuẩn đối với việc phát triển và Các tiến trình phần mềm được
bảo trì phần mềm có tổ chức, bao quản lý để vận hành ổn định, an
gồm cả công nghệ phần mềm, các toàn. Có những đánh giá phần
tiến trình quản lý, và các tiến trình mềm và chất lượng, hiệu quả các
tích hợp với nhau (nghĩa rằng đầu Tiến trình cải Cải tiến hoạt động trong tiến trình. Tiến trình cải Cải tiến
ra của một tiến trình sẽ là đầu vào tiến liên tục (5) tiến liên tục (5)
của tiến trình tiếp theo ).

Tiến trình dự Được quản lý Tiến trình dự Được quản lý

đoán được (4) đoán được (4)

Tiến trình ổn định, Được định nghĩa Tiến trình ổn định, Được định nghĩa
chuẩn (3) chuẩn (3)

Tiến trình có Có tính lặp lại Tiến trình có Có tính lặp lại
kỷ luật (2) Một tiến trình được định nghĩa tốt gồm có các tính chất như
kỷ luật (2) Do các tiến trình ổn định và được đánh giá đúng nên khi có
có tiêu chuẩn, đầu vào, tiêu chuẩn và thủ tục rõ ràng để tiến các trường hợp ngoại lệ, sẽ xác định và chỉ rõ những nguyên
hành công việc, kiểm tra các đầu ra. nhân gây ra biến đổi.
Ban đầu Ban đầu
(1) (1)

17 18

17 18

18 Vùng tiến trình chính

Mô hình 5 mức của CMM
Tiếp tục cải tiến tiến trình, có thể
KPA (Key Process Area)
xác định được những điểm mạnh
và điểm yếu của tiến trình, có khả 7. Xem xét ngang nhau
năng phân tích các khiếm khuyết, LEVEL 2: Có thể lặp 8. Hợp tác giữa các 16.
xác định các nguyên nhân gây ra 1. Quản lý cấu hình nhóm Quản lý thay đổi
để tránh các khiếm khuyết này. Tiến trình cải Cải tiến phần mềm 9. Kỹ thuật sản phẩm tiến trình
tiến liên tục (5) 2. Đảm bảo chất phần mềm
14.
17.
Quản lý chất
lượng phần mềm 10. Quản lý phần mềm Quản lý thay đổi
lượng phần mềm
tích hợp
Tiến trình dự Được quản lý 3. Quản lý hợp đồng 15.
công nghệ
con phần mềm 11. Chương trình huấn 18.
đoán được (4) 4. Theo dõi và giám luyện
Quản lý quá trình
Phòng ngừa khiêm
12. Định nghĩa tiến trình định lượng
sát dự án phần mềm khuyết
Tiến trình ổn định, Được định nghĩa 5. Lập kế hoạch dự tổ chức
(3) án phần mềm 13. Trọng tâm tiến trình
chuẩn 6. Quản lý yêu cầu tổ chức

Tiến trình có Có tính lặp lại MỨC 3: Được định nghĩa

kỷ luật (2)
MỨC 4: Được quản lý
Ban đầu MỨC 5: Cải tiến
(1)

19 20

19 20
 Khả năng nhìn nhận tại mỗi mức Khả năng tiến trình và dự đoán theo
thuần thục các mức của CMM
• Khi mức độ thuần thục tăng, sự sai khác giữa kết
quả đạt được và kết quả dự tính giảm xuống.
• Khi mức độ thuần thục tăng, độ biến động của
kết quả thực tế so với kết quả đề ra giảm xuống.
• Khi mức độ thuần thục tăng thì các kết quả sẽ
được cải thiện. Đó là, chi phí giảm, thời gian phát
triển ngắn hơn, chất lượng và năng suất tăng.

21 22

21 22

Những điểm chung của 2 phương

Cách thức sử dụng mô hình CMM
thức sử dụng CMM
• Định giá tiến trình phần mềm (Software process Câu hỏi thuần
assessments ) xác định trạng thái của tiến trình Lựa chọn
thục
Phân tích
phần mềm hiện tại của tổ chức, xác định mức độ đội trả lời
ưu tiên đối với các vấn đề có liên quan tới tiến Các mẫu CMM
trình phần mềm khi xử lý chúng và xây dựng hệ
thống hỗ trợ phát triển tiến trình phần mềm. (1) (2) (3)

• Đánh giá khả năng phần mềm (Software Hồ sơ KPA

capability evaluations) xác định các nhà thầu có Thăm tại chỗ Tìm kiếm
đủ tư cách triển khai một dự án phần mềm hoặc Phỏng vấn và
quản lý hiện trạng của một hệ thống phần mềm xem xét tài
Dựa trên CMM
đã có sẵn.
liệu

(4) (5) (6)

23 24

23 24
 3.2. Mô hình tuyến tính
• Công nghệ học Hệ thống / Thông tin và mô hình hóa
(System / Information engineering and modeling):
thiết lập các yêu cầu, ánh xạ một số tập con các yêu
Mô hình tuyến tính
Tạo mã / lập trình (Code generation / programming):
Chuyển thiết kế thành chương trình máy tính bởi
ngôn ngữ nào đó. Nếu thiết kế đã được chi tiết hóa
thì lập trình có thể chỉ thuần túy cơ học
Kiểm thử (Testing): Kiểm tra các chương
trình và môđun cả về lôgic bên trong và
chức năng bên ngoài, nhằm phát hiện
ra lỗi và đảm bảo với đầu vào xác định
thì cho kết quả mong muốn

cầu sang phần mềm trong quá trình tương tác giữa
phần cứng, người và CSDL

Phân tích Thiết kế Lập trình Kiểm thử

Phân tích Thiết kế Lập trình Kiểm thử
Công nghệ học
Công nghệ học Hệ thống / Thông tin
Hệ thống / Thông tin
25 26

25 26

Mô hình tuyến tính Điểm yếu của Mô hình tuyến tính

• Hỗ trợ / Bảo trì (Support / Maintenance): Đáp • Thực tế các dự án ít khi tuân theo dòng tuần
ứng những thay đổi, nâng cấp phần mềm đã tự của mô hình, mà thường có lặp lại (như mô
phát triển do sự thay đổi của môi trường, nhu hình của Boehm)
cầu • Khách hàng ít khi tuyên bố rõ ràng khi nào
xong hết các yêu cầu
• Khách hàng phải có lòng kiên nhẫn chờ đợi
Phân tích Thiết kế Lập trình Kiểm thử
thời gian nhất định mới có sản phẩm. Nếu
Công nghệ học phát hiện ra lỗi nặng thì là một thảm họa!
Hệ thống / Thông tin

27 28

27 28
 3.3. Mô hình chế thử (Prototyping model) Mô hình chế thử: Khi nào ?
• Khi mới rõ mục đích chung chung của phần
mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao
hoặc chưa rõ yêu cầu đầu ra
Nghe Khách Tạo / sửa
trình bày bản mẫu • Dùng như “Hệ sơ khai” để thu thập yêu cầu
người dùng qua các thiết kế nhanh
• Các giải thuật, kỹ thuật dùng làm bản mẫu có
thể chưa nhanh, chưa tốt, miễn là có mẫu để
Khách kiểm tra
bản mẫu thảo luận gợi yêu cầu của người dùng

29 30

29 30

3.4. Mô hình phát triển ứng dụng nhanh

(Rapid Application Development: RAD) Mô hình phát triển ứng dụng nhanh
Team #3
Mô hình
nghiệp vụ
• Là quy trình phát triển phần mềm gia tăng, tăng dần Team #2 Mô hình
dữ liệu
Mô hình
từng bước (Incremental software development) với nghiệp vụ
Mô hình
tiến trình
mỗi chu trình phát triển rất ngắn (60-90 ngày) Team #1 Mô hình Tạo
ứng dụng
dữ liệu
Mô hình Mô hình Kiểm thử
• Xây dựng dựa trên hướng thành phần (Component- nghiệp vụ &Turnover
tiến trình
based construction) với khả năng tái sử dụng (reuse) Mô hình Tạo
ứng dụng
• Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo dữ liệu
Kiểm thử
Mô hình
các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hình tiến trình
&Turnover

xử lý, Tạo ứng dụng, Kiểm thử và đánh giá (Business,

Tạo
Data, Process, Appl. Generation, Test) ứng dụng
Kiểm thử
&Turnover
31
60 - 90 days

31 32
 RAD: Business modeling
• Luồng thông tin được mô hình hóa để trả lời
các câu hỏi:
– Thông tin nào điều khiển xử lý nghiệp vụ ?
– Thông tin gì được sinh ra?
– Ai sinh ra nó ?
– Thông tin đi đến đâu ?
– Ai xử lý chúng ?
33
33
RAD: Tạo ứng dụng và kiểm thử
• Tạo ứng dụng (Application Generation): Dùng
các kỹ thuật thế hệ 4 để tạo phần mềm từ các
thành phần có sẵn hoặc tạo ra các thành phần
có thể tái dụng lại sau này. Dùng các công cụ
tự động để xây dựng phần mềm
• Kiểm thử (Testing and Turnover): Kiểm thử các
thành phần mới và kiểm chứng mọi giao diện
(các thành phần cũ đã được kiểm thử và dùng
lại)
35
35
RAD: Mô hình dữ liệu và tiến trình
• Mô hình dữ liệu (Data modeling): các đối tượng
dữ liệu cần để hỗ trợ nghiệp vụ (business). Định
nghĩa các thuộc tính của từng đối tượng và xác
lập quan hệ giữa các đối tượng
• Mô hình tiến trình (Process modeling): Các đối
tượng dữ liệu được chuyển sang luồng thông tin
thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý
đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối
tượng dữ liệu
34
34
RAD: Hạn chế ?
• Cần nguồn nhân lực dồi dào để tạo các nhóm cho
các chức năng chính
• Yêu cầu hai bên giao kèo trong thời gian ngắn
phải có phần mềm hoàn chỉnh, thiếu trách nhiệm
của một bên dễ làm dự án đổ vỡ
• RAD không phải tốt cho mọi ứng dụng, nhất là với
ứng dụng không thể môđun hóa hoặc đòi hỏi tính
năng cao
• Mạo hiểm kỹ thuật cao thì không nên dùng RAD
36
36
 Mô hình gia tăng
3.5. Các mô hình tiến hóa
(The incremental model)
• Phần lớn các hệ phần mềm phức tạp đều tiến hóa theo • Kết hợp mô hình tuần tự và ý tưởng lặp lại của
thời gian: môi trường thay đổi, yêu cầu phát sinh thêm,
hoàn thiện thêm chức năng, tính năng chế bản mẫu
• Các mô hình tiến hóa (evolutionary models) có tính lặp • Sản phẩm lõi với những yêu cầu cơ bản nhất
lại. Kỹ sư phần mềm tạo ra các phiên bản (versions) ngày của hệ thống được phát triển
càng hoàn thiện hơn, phức tạp hơn
• Các mô hình tiêu biểu: • Các chức năng với những yêu cầu khác được
– Gia tăng (Incremental) phát triển thêm sau (gia tăng)
– Xoắn ốc (Spiral) • Lặp lại quy trình để hoàn thiện dần
– Xoắn ốc WINWIN (WINWIN spiral)
– Phát triển đồng thời (Concurrent development)
37 38

37 38

Mô hình gia tăng Mô hình xoắn ốc (spiral)

Gia tăng 1
Lập kế hoạch
Phân tích rủi ro
Phân tích Thiết kế Lập trình Kiểm thử Xuất xưởng 1
Công nghệ hệ
thống/thông tin Giao tiếp
khách hàng
Gia tăng 2 Phân tích Thiết kế Lập trình Kiểm thử Xuất xưởng 2
Khái niệm Kỹ nghệ

Gia tăng 3 Phân tích Thiết kế Lập trình Kiểm thử Xuất xưởng 3
Làm mới

Gia tăng 4 Phân tích Thiết kế Lập trình Kiểm thử XX 4 Nâng cấp
Khách hàng Xây dựng &
đánh giá Xuất xưởng
Thời gian/lịch Bảo trì

39 40

39 40
 Mô hình xoắn ốc (tiếp)
• Giao tiếp khách hàng: giữa người phát triển và
khách hàng để tìm hiểu yêu cầu, ý kiến
• Lập kế hoạch: Xác lập tài nguyên, thời hạn và
những thông tin khác
• Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật
và mạo hiểm quản lý
• Kỹ nghệ: Xây dựng một hay một số biểu diễn
của ứng dụng
41
41
Mô hình xoắn ốc: Mạnh và yếu?
• Tốt cho các hệ phần mềm quy mô lớn
• Dễ kiểm soát các mạo hiểm ở từng mức tiến
hóa
• Khó thuyết phục khách hàng là phương pháp
tiến hóa xoắn ốc có thể kiểm soát được
• Chưa được dùng rộng rãi như các mô hình
tuyến tính hoặc chế thử
43
43
Mô hình xoắn ốc (tiếp)
• Xây dựng và xuất xưởng: xây dựng, kiểm thử,
cài đặt và cung cấp hỗ trợ người dùng (tư liệu,
huấn luyện, . . .)
• Đánh giá của khách hàng: Nhận các phản hồi
của người sử dụng về biểu diễn phần mềm
trong giai đoạn kỹ nghệ và cài đặt
42
42
Mô hình xoắn ốc WINWIN
• Nhằm thỏa hiệp giữa người phát triển và
khách hàng, cả hai cùng “Thắng” (win-win)
– Khách thì có phần mềm thỏa mãn yêu cầu chính
– Người phát triển thì có kinh phí thỏa đáng và thời
gian hợp lý
• Các hoạt động chính trong xác định hệ thống:
– Xác định cổ đông (stakeholders)
– Xác định điều kiện thắng của cổ đông
– Thỏa hiệp điều kiện thắng của các bên liên quan
44
44

Mô hình xoắn ốc WINWIN
2. Xác định điều kiện
thắng của cổ đông
1. Xác định mức
tiếp của cổ đông
7. Xét duyệt và đánh giá
6. Kiểm định sản phẩm
và quy trình
Mô hình phát triển đồng thời
(concurrent development)
3a. Hòa hợp điều kiện thắng
• Xác định mạng lưới những hoạt động đồng thời
3b. Thiết lập mục tiêu mức tiếp
và các ràng buộc, dự kiến
(Network of concurrent activities)
• Các sự kiện (events) xuất hiện theo điều kiện vận
động trạng thái trong từng hoạt động
4. Đánh giá tiến trình và
dự kiến sản phẩm,
• Dùng cho mọi loại ứng dụng và cho hình ảnh khá
giải quyết rủi ro
chính xác về trạng thái hiện trạng của dự án
• Thường dùng trong phát triển các ứng dụng
khách/chủ (client/server applications): hệ thống
5. Xác định mức tiếp của
sản phâm và quy trình,
và các thành phần cấu thành hệ thống được phát
kể cả phân chia nhỏ
triển đồng thời
45 46

45 46

3.6. Mô hình hướng thành phần

Mô hình dựa thành phần
Component-based model
• Gắn với những công nghệ hướng đối tượng Lập kế hoạch
(Object-oriented technologies) qua việc tạo các lớp Phân tích rủi ro Xác định
thành phần

(classes) có chứa cả dữ liệu và giải thuật xử lý dữ

ứng viên
Giao tiếp
liệu khách hàng
Xây dựng Tìm
bước lặp thứ n thành phần
• Có nhiều tương đồng với mô hình xoắn ốc của hệ thống từ thư viện

• Với ưu điểm tái sử dụng các thành phần qua Thư Đặt Lấy

viện / kho các lớp: tiết kiệm 70% thời gian, 80% giá Kỹ nghệ
thành phần
vào thư viện
thành phần
nếu có

thành, chỉ số sản xuất 26.2/16.9 Khách hàng Xây dựng & Xây dựng
đánh giá Xuất xưởng thành phần
• Với UML như chuẩn công nghiệp đang triển khai nếu kh.có

47 48

47 48
 2.3.7. Mô hình RUP
(Rational Unified Process)
• SV tự nghiên cứu
49
49
3.8. Các kỹ thuật thế hệ thứ 4
(Fourth generation techniques)
• Tập hợp các công cụ cho phép xác định đặc
tính phần mềm ở mức cao, sau đó sinh tự
động mã nguồn dựa theo đặc tả đó
• Các công cụ 4GT điển hình: ngôn ngữ phi thủ
tục cho truy vấn CSDL; tạo báo cáo; xử lý dữ
liệu; tương tác màn hình; tạo mã nguồn; khả
năng đồ họa bậc cao; khả năng bảng tính;
khả năng giao diện Web; vv
51
51
Tổng kết các mô hình
• Thác nước: mô hình tuyến tính
• Chế thử: mô hình lặp đi lặp lại
• Gia tăng: kết hợp giữa mô hình tuyến tính và
lặp đi lặp lại
• Xoăn ốc: kết hợp giữa mô hình tuyến tính và
lặp đi lặp lại
• Phát triển nhanh: mô hình lặp đi lặp lại
50
50
4GT: Tại sao ?
• Từ thu thập yêu cầu cho đến sản phẩm: đối thoại
giữa khách và người phát triển là quan trọng
• Không nên bỏ qua khâu thiết kế. 4GT chỉ áp dụng
để triển khai thiết kế qua 4GL
• Mạnh: giảm thời gian phát triển và tăng năng
suất
• Yếu: 4GT khó dùng hơn ngôn ngữ lập trình, mã
khó tối ưu và khó bảo trì cho hệ thống lớn Þ cần
kỹ năng của kỹ sư phần mềm
• Tương lai: 4GT với mô hình theo thành phần
52
52
 4. Đánh giá: Sản phẩm và quy trình
(Product and process)
• Quy trình yếu thì sản phẩm khó mà tốt, song
không nên coi trọng quá mức vào quy trình
hoặc quá mức vào sản phẩm
• Sản phẩm và quy trình cần được coi trọng như
nhau

53

53
 Chương 3. Phương pháp Agile
• Outline
NHẬP MÔN – 1. Đặt vấn đề
CÔNG NGHỆ PHẦN MỀM – 2. Tuyên ngôn của phương pháp Agile
(INTRODUCTION TO SOFTWARE – 3. Các nguyên lý của phương pháp Agile
– 4. So sánh Agile và Waterfall
ENGINEERING) – 5. Nguyên tắc cơ bản của phương pháp Agile
– 6. Tính phù hợp của các phương pháp Agile
– 7. Một số phương pháp Agile phổ biến
• Scrum
• Lean development
• Extreme Programming (XP)

1 2

1 2

1. Đặt vấn đề Mô hình thác nước – nhắc lại

• Tại sao dự án phần mềm lại thất bại? • Mô hình Thác nước (nổi bật những năm 70)
– Không xác định được rủi ro • Mô hình thác nước là mô hình vòng đời lâu đời nhất;
được đề xuất bởi Winston Royce vào năm 1970.
– Xây dựng sai sản phẩm
• Mô hình này được gọi là thác nước vì nó thường được
– Bị công nghệ chi phối vẽ với một chuỗi các hoạt động qua các giai đoạn của
• Do đó: vòng đời “xuống dốc” từ trái sang phải:
– Việc áp dụng một quy trình và vòng đời phần mềm tốt – phân tích, yêu cầu, đặc tả, thiết kế, cài đặt, kiểm thử, bảo
trì
sẽ giúp giải quyết vấn đề này.
• Có nhiều phiên bản của mô hình thác nước:
– Tuy nhiên, điều đó vẫn không đảm bảo sự thành công. – các giai đoạn / hoạt động có thể được cấu trúc theo các
Vì không bao giờ có thể có một quá trình phát triển mức độ chi tiết khác nhau
hoàn toàn hợp lý – phản hồi có thể linh hoạt hơn hoặc ít hơn

3 4

3 4
 Vòng đời lý tưởng - Thác nước
Non-strict waterfall model
(Nghiêm ngặt) Không có phản hồi
• Mặc dù mô hình thác nước nhấn mạnh một chuỗi tuyến tính
của các pha, trên thực tế, trong thực tế luôn có một lượng lớn
sự lặp lại các pha trước đó, một điểm được tạo bởi các mũi
tên dẫn ngược lên thác nước

5 6

5 6

Mô hình thác nước Yêu cầu

• Điểm mạnh:
– Nhấn mạnh việc hoàn thành một giai đoạn trước khi tiếp tục
• Mô hình thác nước:
– Nhấn mạnh việc lập kế hoạch sớm, đầu vào của khách hàng và – chú trọng nhiều vào tài liệu phân tích và thiết kế.
thiết kế
– Nhấn mạnh kiểm tra như một phần không thể thiếu của vòng • Phương pháp Agile:
đời
– Cung cấp các cổng chất lượng ở mỗi giai đoạn vòng đời – kết hợp quá trình tạo mẫu và dựa trên thử
• Điểm yếu: nghiệm: nơi có sự phát triển liên tục của lập trình
– Phụ thuộc vào các yêu cầu được xác định sớm từ đầu (viết mã) và liên tục xác nhận các yêu cầu của
– Phụ thuộc vào việc tách các yêu cầu khỏi thiết kế khách hàng
– Không khả thi trong một số trường hợp đòi hỏi có nhiều thay
đổi
– Nhấn mạnh vào sản phẩm hơn là quy trình

7 8

7 8
 Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, and Jussi
History of Agile:
Lịch sử của Agile
Ronkainen. 2003. New directions on agile methods: a comparative
Where Did it analysis. In Proceedings of the 25th International Conference on
Come From? Software Engineering (ICSE '03). IEEE Computer Society, Washington,
DC, USA, 244-254.

• Agile không phải là một bộ công cụ hay một

phương pháp duy nhất, mà là một triết lý
được đưa ra vào năm 2001. 1990

• Agile thay đổi đáng kể từ cách tiếp cận phát

triển phần mềm nặng theo hướng tài liệu -
chẳng hạn như mô hình thác nước.
2000

9 10

9 10

2. Tuyên ngôn phương pháp Agile Agile: Values, Principles and Methods
• Cách tốt hơn để phát triển phần mềm là làm điều
đó và giúp người khác làm điều đó. Thông qua
việc này, các giá trị sau sẽ được nhận ra:
– Các cá nhân và tương tác qua các quy trình và công cụ
– Phần mềm làm việc dựa trên tài liệu toàn diện
– Sự hợp tác của khách hàng trong quá trình đàm phán hợp đồng
– Đáp ứng sự thay đổi so với việc tuân theo kế hoạch
• Mặc dù các giá trị có trong các mục trên bên phải,
nhưng các mục bên trái được coi trọng hơn.
http://agilemanifesto.org/

11 12

11 12
 3. Agile: 12 nguyên lý 3. Agile: 12 nguyên lý
1. Ưu tiên cao nhất của là làm hài lòng khách hàng thông qua việc 7. Phần mềm làm việc là thước đo chính của sự tiến bộ.
phân phối sớm và liên tục các phần mềm có giá trị. 8. Các quy trình Agile thúc đẩy sự phát triển bền vững. Các
2. Hoan nghênh các yêu cầu thay đổi, ngay cả trong giai đoạn muộn nhà tài trợ, nhà phát triển và người dùng sẽ có thể duy trì
của việc phát triển. Các quy trình nhanh khai thác sự thay đổi vì lợi
thế cạnh tranh của khách hàng. một tốc độ phát triển liên tục.
3. Cung cấp sản phẩm phần mềm thường xuyên, từ vài tuần đến vài 9. Sự quan tâm liên tục, sự xuất sắc về kỹ thuật và thiết kế
tháng, ưu tiên khoảng thời gian ngắn hơn. tốt giúp tăng cường sự nhanh nhẹn.
4. Người kinh doanh và nhà phát triển phải làm việc cùng nhau hàng 10. Sự đơn giản - nghệ thuật tối đa hóa khối lượng công việc
ngày trong suốt dự án. chưa hoàn thành - là điều cần thiết.
5. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung 11. Các kiến trúc, yêu cầu và thiết kế tốt nhất xuất hiện từ các
cấp cho họ môi trường và sự hỗ trợ mà họ cần, và tin tưởng để họ nhóm dự án.
hoàn thành công việc.
6. Phương pháp hiệu quả nhất để truyền tải thông tin đến và trong 12. Theo định kỳ, các nhóm phản ánh về cách trở nên hiệu
nhóm phát triển là trò chuyện trực tiếp. quả hơn, sau đó điều chỉnh hoạt động của mình sao cho
cho phù hợp.
13 14

13 14

4. Agile vs Waterfall Nguyên tắc cơ bản: số lần lặp

• Waterfall có các giai đoạn riêng biệt với các điểm kiểm tra • Các phương pháp luận Agile gồm các bước lặp lại.
và phân phối, trong khi các phương thức nhanh có các lần • Các nhóm nhỏ làm việc cùng với các bên liên quan để xác định các
lặp trong đó đầu ra của mỗi lần lặp nhanh là mã nguồn có nguyên mẫu nhanh, bằng chứng về các khái niệm hoặc các phương
thể được sử dụng để đánh giá và đáp ứng các yêu cầu thay tiện trực quan khác để mô tả vấn đề cần giải quyết. Nhóm xác định
đổi và phát triển của người dùng. các yêu cầu cho việc lặp lại, phát triển mã, xác định và chạy các tập
lệnh kiểm tra tích hợp và người dùng xác minh kết quả.
• Waterfall giả định rằng có thể hiểu rõ các yêu cầu ngay từ • Việc kiểm định diễn ra sớm hơn nhiều trong quá trình phát triển.
đầu. Nhưng trong phát triển phần mềm, các bên liên quan
thường không biết họ muốn gì và không thể nói rõ các yêu
cầu của họ. Với kiểu thác nước, sự phát triển hiếm khi
mang lại những gì khách hàng muốn ngay cả khi đó là
những gì khách hàng yêu cầu.
• Với Agile nhấn mạnh vào khách hàng và yêu cầu của họ.

15 16

15 16
 Tính phù hợp của các phương pháp
Một số phương pháp Agile phổ biến
Agile
• Khó xác định về loại dự án phần mềm nào phù hợp • Scrum
nhất cho cách tiếp cận Agile.
• Lean Development
• Nhiều tổ chức lớn gặp khó khăn trong việc chuyển từ
phương pháp truyền thống sang một phương pháp • Extreme programming (XP)
Agile (linh hoạt).
• Adaptive Software Development (ASD)
• Khi Agile có rủi ro:
– Phát triển quy mô lớn (> 20 nhà phát triển) • Agile Modeling
– Phát triển phân tán (các nhóm không nằm chung) • Crystal Methods
– Các công ty kiểm soát kỳ quặc
– Khách hàng hoặc người liên hệ không đáng tin cậy
• Dynamic System Development Methodology
– Bắt buộc một quy trình nhanh trong nhóm phát triển
(DSDM)
– Nhà phát triển thiếu kinh nghiệm • Feature Driven Development
17 18

17 18

J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods

Scrum October 2011

Scrums cho các vấn đề xấu October 2011

‘Scrum’ (liên quan đến “scrimmage”) là thuật ngữ chỉ một nhóm người chơi tụ
tập với nhau để hoàn thành công việc trong môn bóng bầu dục. Trong phát
triển phần mềm, công việc là đưa ra một bản phát hành.
Comes from Japan and based from industrial process control theory:
Takeuchi, Hirotaka and Nonaka, Ikujiro: The New New Product Development
Game, Harvard Business Review, 1986.
“Stop running the relayy race and take up rugby”
"Dừng chạy cuộc đua tiếp sức và chơi bóng bầu dục"
Speed Up
development
"Cách tiếp cận quản lý dự Peter DeGrace and Leslie Hulet Stahl.
án thích ứng tốt nhất cho Wicked Problems, Righteous Solutions.
các dự án phần mềm xấu" 1990. Yourdon Press
Nhiều vấn đề hệ thống mà các nhà phát triển phần mềm gặp phải (các đặc điểm xấu):
1. Không có công thức chính xác cho một vấn đề xấu.
2. Những vấn đề xấu không có quy luật dừng.
3. Giải pháp cho các vấn đề xấu không phải đúng-hay-sai mà là tốt-hay-xấu
4. Không có thử nghiệm tức thời và cuối cùng nào về giải pháp cho một vấn đề xấu.
5. Mọi giải pháp được thực hiện cho một vấn đề xấu đều có hậu quả.
6. Các vấn đề xấu không có một tập hợp các giải pháp tiềm năng tốt.
7. Mọi vấn đề xấu xa về cơ bản là duy nhất.
8. Mọi vấn đề xấu có thể được coi là một nguyên nhân của một vấn đề khác.
9. Nguyên nhân của một vấn đề xấu có thể được giải thích theo nhiều cách.
10. Người lập kế hoạch (thiết kế) không có quyền sai.

19 20

19 20
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods

Scrums phases October 2011 Main scrum concepts October 2011

Burndown chart. Biểu đồ này, được cập nhật mỗi ngày, cho thấy công việc còn lại trong
sprint. Biểu đồ burndown được sử dụng để theo dõi tiến trình spint và quyết định khi nào các
Scrum Phase mục phải được loại bỏ khỏi sprint backlog và hoãn lại sprint tiếp theo.

Product backlog. Product backlog là danh sách đầy đủ các yêu cầu — bao gồm lỗi, yêu cầu
nâng cao, cải tiến khả năng sử dụng và hiệu suất — hiện không có trong bản phát hành sản
phẩm.

ScrumMaster. ScrumMaster là người chịu trách nhiệm quản lý dự án Scrum.

Sprint backlog. Sprint backlog là danh sách các hạng mục tồn đọng được chỉ định cho một
sprint, nhưng chưa hoàn thành. Trong thực tế phổ biến, không có hạng mục tồn đọng nào
của sprint phải mất hơn hai ngày để hoàn thành. Sprint backlog giúp nhóm dự đoán mức độ
nỗ lực cần thiết để hoàn thành một sprint.

21 22

21 22

J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods

Scrum Meetings October 2011

Scrum Meetings October 2011

Quá trình phát triển được chia thành một loạt

các lần lặp ngắn được gọi là spint. Trước mỗi
sprint, các thành viên trong nhóm xác định các
hạng mục tồn đọng cho sprint. Khi kết thúc
sprint, nhóm sẽ xem xét sprint để nêu rõ các
bài học kinh nghiệm và kiểm tra tiến độ.

Trong thời gian một spint, nhóm có một cuộc họp hàng ngày. Mỗi thành viên trong nhóm mô tả công
việc sẽ được thực hiện trong ngày hôm đó, tiến độ từ ngày hôm trước. Để giữ cho các cuộc họp ngắn
gọn, cuộc họp phải được tiến hành với tất cả mọi người (họp đứng trong cùng một phòng).

The backlog is key: it is populated during the planning phase of a release
and defines the scope of the release
Việc tồn đọng là khóa: nó được điền vào trong pha lập kế hoạch của lần
phát hành sản phẩm và xác định phạm vi của bản phát hành
23
Khi đủ các backlog đã được thực hiện để người dùng cuối tin rằng bản phát hành đáng được đưa vào
sản xuất, kết thúc quá trình phát triển. Sau đó, nhóm thực hiện kiểm tra tích hợp, đào tạo và tài liệu
khi cần thiết để phát hành sản phẩm.
24

23 24
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods

Scrum Meetings October 2011

Scrum Meetings October 2011

Cuộc họp đứng hàng ngày (còn được gọi là "cuộc họp hàng ngày", "cuộc họp
hàng ngày", "điểm danh buổi sáng", v.v.), để giữ cuộc họp ngắn, được mô tả
như sau: Mục đích cho daily stand-up là Good Start, Improvement, Focus,
Team, Status (GIFTS)
• Cả nhóm họp hàng ngày để cập nhật tình trạng nhanh chóng.
Có một số mục tiêu cho cuộc họp đứng hàng ngày:
• Tuy nhiên việc này không thực sự đảm bảo giúp phân biệt một phương án
• Để giúp khởi đầu ngày mới tốt đẹp
hiệu quả với việc lãng phí thời gian.
• Để hỗ trợ cải thiện
• Đối với những người có kinh nghiệm, với việc đứng lên theo bản năng, khi • Để củng cố sự tập trung
gặp sự cố họ sẽ biết phải điều chỉnh những gì để khắc phục tình hình. • Để củng cố tinh thần đồng đội
• Để thông báo những gì đang xảy ra
• Đối với những người mới bắt đầu, khi mọi thứ gặp trục trặc, ít có khả năng
họ sẽ tìm ra giải pháp (những gì phải làm) và có nhiều khả năng là từ bỏ The purpose is not to meet... it is to improve.
hoàn việc nếu không được hỗ trợ. -- Joe Ely, "More on Daily Start-Up Meetings"

• Điều này sẽ mang lại giá trị đáng kể cho cả đội. 25 26

25 26

J Paul Gibson: Agile Methods

Scrum Meetings Scrum Meetings October 2011

Ai tham dự?
Mọi người và các đại diện từ các lĩnh vực khác nhau muốn biết và/hoặc đóng góp Ở đâu và khi nào và như thế nào?
vào dự án. Trạng thái giao tiếp trong nhiều cuộc họp cần nhiều sự nỗ lực.
• Gặp gỡ nơi công việc xảy ra
Do đó. Thay thế một số hoặc tất cả các cuộc họp và báo cáo bằng cuộc họp hàng • Cùng một nơi, cùng một lúc
ngày. Bất kỳ ai trực tiếp tham gia hoặc muốn biết về hoạt động hàng ngày của dự • Vào đầu ngày? … hay không?
án đều nên tham gia cuộc họp đứng hàng ngày. • Đứng gần nhau
• Chuẩn bị trước
Nhưng. Những người không liên quan trực tiếp có thể làm gián đoạn cuộc họp nếu • Mười lăm phút hoặc ít hơn… Thực hiện giải quyết vấn đề ngoại tuyến
họ không rõ về hành vi được mong đợi. Điều này có thể được giải quyết bằng cách • Khuyến khích quyền tự chủ (xoay người điều hành?)
thông báo trước cho những người tham gia và quan sát viên mới về các chỉ tiêu dự
kiến.

27 28

27 28
 J Paul Gibson: Agile Methods

October 2011

Scrum
Pros
Scrum sử dụng Sprint nhỏ để chia hệ thống
thành các thành phần nhỏ hơn một cách
hiệu quả và phân chia cho các nhóm.
Một hoạt động chính trong scrum là “cuộc
họp scrum hàng ngày”, giúp các thành viên
trong nhóm đưa ra bằng chứng về việc
hoàn thành nhiệm vụ và cho phép cải tiến
liên tục, do đó cho phép áp dụng kỹ thuật từ
dưới lên một cách nhanh chóng
Cons
Lean development
Scrum chỉ hoạt động khi ban quản lý “tin (phát triển tinh gọn)
tưởng các nhà phát triển sử dụng phán
đoán của riêng mình” để hoàn thành nhiệm
vụ. Các thuộc tính chính của scrum là khả J Paul Gibson: Agile Methods
năng kiểm soát nhẹ nhàng và tinh tế. Vì
October 2011
vậy, nếu đội ngũ phát triển còn trẻ và chưa
trưởng thành, Scrum trở rất rủi ro.
Scrum được thiết kế lý tưởng cho công ty
có “các phương pháp nhanh hiện có”. Do
đó, một công ty phải có một số kiến thức
làm việc về các phương pháp nhanh trước
khi sử dụng Scrum.

29 30

29 30

Lean development J Paul Gibson: Agile Methods

October 2011 Lean Software Development – key ideas

J Paul Gibson: Agile Methods

October 2011

Lean software development là bản dịch các nguyên tắc và thực

hành sản xuất tinh gọn sang lĩnh vực phát triển phần mềm. Được
điều chỉnh từ Hệ thống sản xuất Toyota, một tiểu văn hóa ủng hộ
tinh gọn đang xuất hiện trong cộng đồng Agile:
is a translation of lean manufacturing principles and practices to
the software development domain. Adapted from the Toyota
Production System, a pro-lean subculture is emerging from within
the Agile community:
• Cuộc sống sẽ dễ dàng hơn rất nhiều nếu khách hàng ngừng thay đổi suy
nghĩ của họ.
• Hãy để khách hàng trì hoãn quyết định của họ về chính xác những gì họ
muốn càng lâu càng tốt và khi họ yêu cầu điều gì đó, hãy đưa nó cho họ
nhanh đến mức họ không có thời gian để thay đổi ý định.
• Các thiết kế tuyệt vời đến từ các nhà thiết kế vĩ đại và các nhà thiết kế vĩ đại
hiểu rằng các thiết kế xuất hiện khi họ phát triển sự hiểu biết ngày càng cao
về vấn đề, chứ không phải thu thập số lượng lớn các yêu cầu.
• Cung cấp hệ thống làm việc nhanh nhất có thể.

QUESTION: Do you agree with this?

31 32

31 32
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods
Lean Software Development October 2011 October 2011
Lean software development: focus on testing
1. Eliminate waste. Bất kỳ hoạt động nào không “tự trả giá” trong nỗ lực giảm thiểu ở những
nơi khác trong hệ thống và cần được loại bỏ.
2. Amplify learning. Các nhà phát triển luôn cần học các phương pháp mới để tạo ra một hệ
thống mạnh mẽ nhất.
3. Decide as late as possible. Lợi ích của việc đưa ra quyết định vào phút cuối là tránh đưa ra
quyết định sai lầm sớm và sau đó phải sửa chữa nó sau này.
4. Deliver as fast as possible. Nguyên tắc này là nếu bạn cung cấp rất nhanh, nó sẽ làm giảm
cơ hội thay đổi yêu cầu. Điều này có thể phải trả giá rất lớn nếu sự thay đổi đến muộn
trong quá trình phát triển.
5. Empower the team. Để mọi người chịu trách nhiệm, có động lực và gắn bó với nhau như
một đội, họ cần phải chịu trách nhiệm về kết quả và được ủy quyền để biến nó thành
hiện thực.
6. Build integrity in: Điều quan trọng là hệ thống duy trì tính toàn vẹn trong suốt chu trình
phát triển. Điều đó có nghĩa là phải kiểm tra tích hợp, kiểm thử đơn vị và kiểm thử chung,
đặc biệt là từ khách hàng.
7. See the whole. Đừng chia nhỏ hệ thống thành nhiều phần mà hãy giữ nguyên toàn bộ hệ
thống.

33 34

33 34

J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods

October 2011 Lean Software Development October 2011

Lean software development: focus on testing

Pros
Tư duy toàn bộ hệ thống, mặc dù khó đối
với hệ thống phức tạp, giúp đảm bảo tính
nhất quán và toàn vẹn của hệ thống. Giảm
thời gian tích hợp kể từ khi được phát triển
dưới dạng đơn vị số ít.
Nhóm làm việc thiết kế các quy trình của
riêng mình, đưa ra các cam kết riêng, thu
thập thông tin cần thiết để đạt được mục
tiêu và tự lập chính sách để đạt được các
mốc quan trọng của mình.
Cons
Với hệ thống lớn hoặc hệ thống phức tạp,
cách duy nhất để các nhà phát triển hình
dung cấu trúc của nó là thông qua việc
phân vùng hệ thống. Nhưng LSD đề xuất
điều ngược lại, điều này có thể khó thực
hiện.
Quyết định càng muộn càng tốt có thể ảnh
hưởng xấu đến lịch trình. Điều này có thể
làm tổn hại đến sự phát triển song song và
làm tăng thời gian thực hiện.

35 36

35 36
 J Paul Gibson: Agile Methods Extreme Programming J Paul Gibson: Agile Methods

October 2011 October 2011

Extreme Programming (XP) From: Embracing Change with Extreme Programming, Beck, 1999

XP is not this extreme!

37 38

37 38

Extreme Programming (XP) J Paul Gibson: Agile Methods Extreme Programming (XP) J Paul Gibson: Agile Methods

Embracing Change with Extreme October 2011 Embracing Change with Extreme October 2011

Programming, Beck, 1999 Programming, Beck, 1999

Không thể lập trình cho đến khi biết mình đang lập trình gì.
XP coi khoảng thời gian trước khi hệ thống đi vào sản xuất lần đầu
tiên là một bất thường nguy hiểm trong vòng đời của dự án và cần
được khắc phục càng nhanh càng tốt. Tuy nhiên, mọi dự án đều phải
bắt đầu từ đâu đó.
Làm thế nào để xác định thời điểm nên lập trình?
Khách hàng chọn bản phát hành tiếp theo bằng cách chọn các tính năng có giá trị nhất
(được gọi là các câu chuyện trong XP) trong số tất cả các câu chuyện có thể có, được xác
định bởi chi phí của các câu chuyện và tốc độ của nhóm trong việc cài đặt các câu chuyện.
Khách hàng chọn câu chuyện của lần lặp lại tiếp theo bằng cách chọn những câu chuyện có
giá trị nhất còn lại trong bản phát hành, được thông báo lại bằng chi phí của các câu chuyện
và tốc độ của nhóm.

Kết hợp phân tích tổng thể dưới dạng các câu chuyện là số lượng của
một trường hợp sử dụng. Mỗi câu chuyện phải theo định hướng
kinh doanh, có thể kiểm tra và ước tính được.
Một tháng là một khoảng thời gian dài để đưa ra những câu chuyện
cho một dự án.
39
Các lập trình viên biến các câu chuyện thành các nhiệm vụ chi tiết nhỏ hơn mà họ tự nhận
trách nhiệm.
Sau đó, lập trình viên biến một nhiệm vụ thành một tập hợp các trường hợp kiểm thử để
chứng minh rằng nhiệm vụ đã hoàn thành.
Làm việc với một đối tác, lập trình viên làm cho các trường hợp kiểm thử chạy, đồng thời
cải tiến thiết kế để duy trì thiết kế đơn giản nhất có thể cho toàn bộ hệ thống.
40

39 40
 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods

October 2011 October 2011

XP Practices I (Usually associated with Agile) XP Practices I (Usually associated with Agile)

Planning game. Khách hàng quyết định phạm vi và thời gian phát hành dựa trên các ước
tính do lập trình viên cung cấp. Các lập trình viên chỉ triển khai các chức năng được yêu cầu
bởi các câu chuyện trong lần lặp này.
Small releases. Hệ thống được đưa vào sản xuất trong vài tháng, trước khi giải quyết toàn
bộ vấn đề. Các bản phát hành mới được thực hiện thường xuyên — bất cứ nơi nào từ hàng
ngày đến hàng tháng.
Metaphor. Hình dạng của hệ thống được xác định bằng một phép ẩn dụ hoặc một tập hợp
các phép ẩn dụ được chia sẻ giữa khách hàng và lập trình viên.
Simple design. Tại mọi thời điểm, thiết kế chạy tất cả các tests, truyền đạt mọi thứ mà lập
trình viên muốn giao tiếp, không chứa mã trùng lặp và có ít mã nhất các lớp và các phương
thức. Quy tắc này có thể được tóm tắt là, "Nói mọi thứ một lần và chỉ một lần.
Tests. Các lập trình viên viết các bài test đơn vị. Các tests này được thu thập và tất cả chúng
phải chạy chính xác. Khách hàng viết các test chức năng cho các câu chuyện trong một lần
lặp lại. Tất cả các thử nghiệm này cũng nên chạy, mặc dù trên thực tế, đôi khi phải đưa ra
quyết định kinh doanh so sánh chi phí cho một lỗi đã biết và chi phí của sự chậm trễ.
Refactoring. Thiết kế của hệ thống được phát triển thông qua các biến đổi của thiết kế hiện
có để giữ cho tất cả các thử nghiệm hoạt động.
Continuous integration. Tích hợp mã mới hệ thống hiện tại sau không quá vài giờ. Khi tích
hợp, hệ thống được xây dựng từ đầu và tất cả các bài kiểm tra phải vượt qua hoặc các thay
đổi bị loại bỏ.

41 42

41 42

J Paul Gibson: Agile Methods XP – Daily Communication is Key J Paul Gibson: Agile Methods

October 2011 October 2011

XP Practices II (also found outside Agile)

Pair programming. Tất cả mã được viết bởi hai người tại một màn hình / bàn phím / chuột.

Collective ownership. Mọi lập trình viên đều cải thiện bất kỳ mã nào ở bất kỳ đâu trong hệ
thống vào bất kỳ lúc nào nếu họ thấy có cơ hội.

On-site customer. Một khách hàng ngồi với nhóm toàn thời gian.

40-hour weeks. Không ai có thể làm thêm tuần thứ hai liên tiếp. Ngay cả thời gian làm
thêm giờ được sử dụng quá thường xuyên cũng là dấu hiệu của những vấn đề lớn cần được
giải quyết.

Open workspace. Nhóm làm việc trong một căn phòng lớn với các buồng nhỏ. Lập trình
viên theo cặp làm việc trên máy tính được thiết lập tại trung tâm.

Just rules. Khi là thành viên của nhóm Extreme, bạn đăng ký để tuân theo các quy tắc.
Nhưng chúng chỉ là các quy tắc. Nhóm có thể thay đổi các quy tắc bất kỳ lúc nào miễn là họ
đồng ý về cách họ sẽ đánh giá tác động của thay đổi.
43 44

43 44
 Extreme Programming (XP) J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods

October 2011 The pros of XP October 2011

Để XP thành công, cần có kiến thức chuyên môn quan trọng.
• Xây dựng câu chuyện người dùng - Một câu chuyện người dùng
mô tả các vấn đề cần giải quyết của hệ thống đang được xây
dựng. Những câu chuyện này phải được viết bởi người dùng và
phải dài khoảng ba câu. Câu chuyện của người dùng không mô tả
một giải pháp, sử dụng ngôn ngữ kỹ thuật hoặc chứa các yêu cầu
truyền thống.
• Chuyển câu chuyện thành mã - Vì câu chuyện của người dùng
ngắn và hơi mơ hồ, XP sẽ chỉ hoạt động nếu đại diện khách hàng
có mặt để xem xét và phê duyệt việc triển khai câu chuyện của
người dùng.
• Biến các câu chuyện thành mã thử nghiệm - Kiểm thử đơn vị là
trọng tâm của XP, trong đó hai điểm xoay quanh các chiến lược
kiểm thử thông thường giúp kiểm tra hiệu quả hơn nhiều: Các
lập trình viên viết các bài kiểm tra của riêng họ và họ viết các bài
kiểm tra này trước khi viết mã.
• Thiết kế phát triển - Không được phá vỡ các thử nghiệm hiện có
và cũng phải hỗ trợ phát triển gia tăng có thể mở rộng 45
• Nếu được hoàn thành tốt, XP cải thiện tinh thần đồng đội.
• Nó xây dựng năng lực thực sự ở tất cả các thành viên trong nhóm.
• Nó làm cho một ngày làm việc thú vị và trung thực.
• Nó đưa mọi người ra khỏi khối của họ và nói chuyện với nhau.
• TDD (Test-driven development) dạy các nhà phát triển về cách viết mã chất
lượng và cách cải thiện quan niệm của họ về thiết kế; nó giúp họ cải thiện ước
tính. Nó cải thiện hồ sơ của các nhà phát triển.
• Nó cung cấp cho quản lý nhiều công cụ, bao gồm khả năng dự đoán, tính linh
hoạt của các nguồn lực, tính nhất quán và khả năng hiển thị về những gì thực
sự đang diễn ra.
• Nó cung cấp cho khách hàng khả năng xem liệu một công ty có thể thực hiện
những lời hứa của mình hay không.
• Bạn không dành nhiều thời gian cho những cuộc họp ngu ngốc, lãng phí và
bạn không tạo ra nhiều tài liệu vô ích.
46

45 46

J Paul Gibson: Agile Methods

The cons of XP October 2011

• Thiết kế trở nên tiềm ẩn thay vì rõ ràng

• Dựa vào thiết kế là rủi ro
• Rất khó để viết các tests tốt
• Lặp lại quá thường xuyên có thể làm giảm chất lượng
• Để làm tốt, bạn cần phải làm thường xuyên - vì vậy rất khó để giới thiệu
thành công

47

47
 Chương 4: Quản lý dự án phần mềm

NHẬP MÔN 1. Khái niệm

CÔNG NGHỆ PHẦN MỀM 2. Nguyên lý và quy trình quản lý dự án
(INTRODUCTION TO SOFTWARE 3. Kỹ năng, kỹ thuật quản lý dự án
ENGINEERING) 4. Các yếu tổ quyết định thành công của dự án

1 2

1 2

1. Khái niệm Dự án phần mềm

• Dự án (project): Một dự án là một công việc có thời hạn • Do đội ngũ thành viên gồm ít nhất 2 người thực
nhằm tạo ra một sản phẩm, dịch vụ hay kết quả duy nhất.
hiện
– Tính thời hạn (Temporariness) : có điểm bắt đầu và điểm kết thúc
– Tính duy nhất (Uniqueness) : • Giới hạn về thời gian, ngân sách, và nhân lực
• Dự án là riêng biệt, độc lập
• Có sản phẩm cụ thể cuối cùng
• Sản phẩm là phần mềm mới hoặc phần
• Sản phẩm hoặc môi trường dự án là duy nhất mềm có sẵn được cải tiến
• Mang lại yếu tố mới cho đội ngũ thực hiện
• Sản phẩm phải góp phần tạo dựng quy trình
à Dự án cần được quản lý với giả định sẽ xảy ra thay đổi.
nghiệp vụ mới, hữu ích, hoặc mang lại lợi
ích đáng kể cho quy trình nghiệp vụ hiện có.

3 4

3 4
 Giá thành + Thời gian+ Chất lượng
Quản lý dự án (Cost + Schedule + Quality)
• Quản lý dự án là áp dụng kiến thức, kỹ • Quản lý dự án là để đưa ra một sản phẩm cuối cùng:
năng, công cụ và kỹ thuật vào các hoạt – trong phạm vi ngân sách hay nguồn tài chính cho phép
động của dự án nhằm đáp ứng yêu cầu – đúng hạn
của dự án. – với nguồn lực cho phép
– Đạt mục tiêu dự án – phù hợp với đặc tả
– Đạt hoặc vượt các yêu cầu hay kỳ vọng của – chất lượng đủ để phục vụ các nhu cầu kinh doanh và đáp
những người có quyền lợi và nghĩa vụ liên ứng các tiêu chuẩn chuyên môn và kỳ vọng của công tác
quan (stakeholders) quản lý
– Cân bằng giữa các yếu tố: thời gian, chi phí,
chất lượng sản phẩm
5 6

5 6

Các nhiệm vụ trong quản lý dự án Các lĩnh vực quản lý dự án

KIỂM SOÁT (CONTROLLING)
Dự án
Ai thẩm định kết quả ? Dựa vào các tiêu chuẩn nào ?

CHỈ ĐẠO (DIRECTING) LẬP KẾ HOẠCH (PLANNING) 3

Ai quyết định cái gì, khi Nhắm tới mục tiêu nào, tại
nào? TÀI NGUYÊN
sao?
CỦA DỰ ÁN
2
Con người
1
Sản phẩm
TẠO ĐỘNG LỰC (MOTIVATION) TỔ CHỨC (ORGANIZING) People
Điều gì khiến mọi người có thể bộc lộ Liên quan đến cái gì, tại sao?
những phẩm chất tốt nhất trong công Tiến trình
việc ?
7 8

7 8
 1. Giải quyết bài toán quản lý dự án
QUẢN LÝ DỰ ÁN PHẦN MỀM ĐẦU VÀO TIẾN TRÌNH (Đặc Tính thuần thục của quá trình, Phương pháp luận, Đánh ĐẦU RA TIẾN TRÌNH (Ví dụ
trưng) giá và tối ưu, Ràng buộc, khuôn mẫu, cơ sở hạ tầng, Nền chọn lọc)
tảng văn hoá và chính sách

Thông tin Project Business Case

CÁC BƯỚC TIẾN Danh mục đầu tư dự án tối ưu

Công nghệ
Khái niệm TRÌNH

Nguyên lý và tiến trình quản lý dự án Các công cụ về chất lượng

và số lượng
Báo cáo khả thi dự án

1. Giải quyết bài toán quản lý dự án Đầu ra của các tiến trình Quy hoạch tổng thể dự án (kế
1 2 3 N
khác hoạch lệ thuộc)
2. Sàng lọc dự án
Yêu cầu thay đổi của khách
3. Nhiệm vụ của người quản lý dự án Đầu vào vật chất Chuyển đổi đầu vào thành đầu ra hàng

4. Các pha quản lý dự án Tương tác các bên liên Thời gian & Giá
Chi phí sửa đổi và lịch trình cơ
quan bản
Kỹ năng, kỹ thuật quản lý dự án thành

Hiệu quả của tiến trình Báo cáo trạng thái dự án

Các yếu tổ quyết định thành công của dự án Các yêu cầu, chỉ dẫn

Chất lượng đầu vào của quá trình, Do kết quả của một quá trình quản lý dự án thường là đầu Quản lý dự án sử dụng rộng rãi các quy trình
Kiến thức, Năng lực,Kinh nghiệm, Sự vào của một quá trình khác, sai sót trong một hoặc nhiều để sản xuất "sản phẩm" (xem mẫu ở trên).
rõ ràng, Khả năng, Truyền thông, quá trình sẽ kéo theo sai sót trên toàn chuỗi toàn bộ quá Một số quy trình khá phức tạp và có nguy cơ
9 Hợp tác, Phối hợp trình lỗi cao. 10

9 10

2. Sàng lọc dự án Ý tưởng đề xuất 3. Nhiệm vụ của người quản lý dự án

dự án

• Làm thế nào để

Cần / phù hợp
• Tập trung vào sự đa dạng Thu thập dữ liệu
chiến lược/ ROI /
và sao lưu
của các thành viên trong
tăng khả năng:
rủi ro hoàn vốn

nhóm và độ phức tạp của

công việc: Tự đánh giá các – Tạo ra sản phẩm
– Xem xét các sự việc khác tiêu chí dự án
có chất lượng
nhau ở các góc độ khác
nhau, xuất phát từ thành – Tôn trọng lịch Đội ngũ lãnh đạo
Ban chỉ đạo
viên và các công việc cần Nhóm ưu tiên
đánh giá đề xuất
trình thực hiện Giám đốc dự án
làm Đánh giá định Quay lại để thêm Nhà tài trợ

– Sử dụng quy trình “Plan -

kỳ các ưu tiên
và xem xét danh
mục đầu tư để
thông tin – Thỏa mãn yêu cầu Liên lạc nội bộ
Liên lạc bên ngoài

Do - Check - Act“ cân bằng rủi ro của khách hàng Bộ phận trực tuyến
Các dự án khác
Quản lý
dự án
Đối tác thương mại
Các nhà cung cấp

– Người quản lý dự án giỏi – Tạo khả năng kinh CNTT Các nhà thầu

phải tìm ra các năng lực

tiềm ẩn của từng thành viên doanh Nhóm dự án
Người tham gia
Phân phối
và sử dụng đầy đủ các Loaị bỏ Hold for
Resources
Phân quyền ưu
tiên, tài – Đạt được thành Nhiệm vụ
năng lực đó. nguyên, quản
lý dự án và
công
đánh giá tiến
độ
11 12
ROI: return on investment

11 12
 PM = Tâm điểm giao tiếp Bài tập
• Không phải là công
việc bán thời gian • Phân biệt vai trò, nhiệm vụ của người
• Phải biết chu kỳ
sống của dự án, các quản lý (managers) và người lãnh đạo
tiến trình của dự án
và vai trò của các
tiến trình này trong
(leaders)
việc thực hiện các
công việc ở các pha • Các kỹ năng người quản lý dự án cần có
khác nhau trong chu
kỳ sống của dự án
• Nhận biết được sự
phức tạp của môi
trường thực hiện
dự án
• Phải được chuẩn
bị để đối phó với
các mối xung đột Hầu hết các dự án thất bại vì thiếu quản lý dự án
khác nhau và quản lý con người, không phải vì lý do kỹ
thuật
13 14

13 14

Nhà quản lý vs. Nhà lãnh đạo Kỹ năng quản lý cho Quản lý dự án
Nhìn chung, nhà lãnh đạo có nhiệm vụ chỉ ra mục tiêu và liên kết mọi người • Lãnh đạo (nhất thiết khác với ‘quản lý’!)
để đạt được mục tiêu. – Thiết lập đường hướng (tầm nhìn và chiến
lược)
Lãnh đạo cố gắng để tìm ra những điểm chung.
– Săp xếp người (tầm nhìn giao tiếp và chiến
Lãnh đạo cần phải có được hình ảnh rõ ràng về tương lai.
lược bằng lời nói và hành động)
Lãnh đạo tập trung vào các phản ánh liên quan đến kỳ vọng. – Thúc đẩy và tạo cảm hứng
Một nhà lãnh đạo tốt luôn luôn tập trung vào việc tương lai hướng đến đồng – Lãnh đạo có thể được thể hiện ở tất cả các
nhất nhóm của mình. cấp
• Đàm phán với người khác để đạt được
thoả thuận
– Phạm vi, chi phí, thời hạn, hợp đồng,
nhiệm vụ, nguồn lực v..v.
• Giải quyết vấn đề
– Định nghĩa vấn đề (kỹ thuật, quản lý, giao
tiếp)
– Ra quyết định (xác định các giải pháp khả

• Lãnh đạo • Quản lý • Giao tiếp rõ rang, không nhập nhằng thi và thực hiện lựa chọn với yếu tố thời
– Viết và nói, nghe và nói gian)
– Tập trung vào tương lai – Tập trung vào hiện tại
– Tích hợp – Đa dạng – Nội bộ và bên ngoài • Ảnh hưởng đến tổ chức

– Hi vọng – Trông coi – Trang trọng và thân mật – Sự hiểu biết về các động thái chính thức và
– theo chiều dọc (cấp trên, cấp dưới) và không chính thức của tổ chức (sức mạnh &
– Tầm nhìn – Hỗ trợ
chiều ngang (cấp ngang hàng) (Vertical and chính trị - theo nghĩa tích cực)
– Sáng tạo – Giải quyết vấn đề
horizontal)
– Cảm hứng – Phân tích
– Sáng kiến – Cấu trúc, sắp xếp
– Cơ hội – Thực tế
15 16

15 16
 4. Các pha quản lý dự án 4. Các pha quản lý dự án

Phân bố lợi Phân bổ lợi

Định nghĩa và thiết kế dự án Định nghĩa và thiết kế dự án
ích ích
Các giai đoạn Phase / Stage

Lập kế hoạch quản

Kết thúc dự án
Kết thúc dự án
Lập kế hoạch quản lý

Khái niệm, mục tiêu, cách tiếp cận và cách biện minh rằng
một dự án đã được định nghĩa đúng, được đồng ý, và được

lý
truyền đạt đúng.

Sơ lược kế hoạch quản lý tổng thể, trong đó xác định, lập

Thực thi phức tạp, với nhiều giai đoạn và quá trình
dự toán và thời gian thực hiện cho các tài nguyên có sẵn,
Tuân thủ tuyệt đối vòng đời nghiệp vụ, từ việc định nghĩa, chứng minh tính khả thi, cho đến khi phân bổ lợi ích cho
mua lại hay hợp đồng con
doanh nghiệp
Đánh giá lại nghiệp vụ để đảm bảo là các giả định và biện
• Các kỹ năng quản lý dự án là rất cần thiết ngay từ đầu: hiểu biết rõ về các quy trình của dự án + ước tính minh ban đầu vẫn đúng
đáng tin cậy + lập, xem xét kế hoạch dự án một cách cẩn thận Xác định chi tiết và chủ định thực hiện các tiến trình quản
• Các lĩnh vực và quy trình bổ trợ làm giúp đảm bảo lòng tin rằng dự án sẽ tạo ra một kết quả có giá trị lý

17 18

17 18

4. Các pha quản lý dự án 4. Các pha quản lý dự án

Định nghĩa và thiết kế dự án Phân bổ lợi Phân bổ
ích
Định nghĩa và thiết kế dự án
Pha / Giai đoạn
lợi ích
Pha / Giai đoạn
Lập kế hoạch quản

Lập kế hoạch

Kết thúc dự
Kết thúc dự án

quản lý

án
lý

Báo cáo kiểm Q Báo cáo kiểm Q

soát quản lý A soát quản lý A
Sự huy động Huy động

Theo dõi và quản lý lợi ích

Quản lý chất lượng
Một dự án có thể trải qua nhiều giai đoạn, mỗi giai đoạn có mục tiêu và kết quả cần đạt khác nhau. Quản lý rủi ro
Các giai đoạn thường yêu cầu các kỹ năng, cấu trúc và mức độ tài nguyên khác nhau. Việc lập kế hoạch, ước lượng chi phí Quản lý vấn đề
và phân bổ tài nguyên riêng cho từng giai đoạn là bình thường. Kiểm soát thay đổi phạm vi
Quản lý cấu hình
Kiểm soát tài liệu
Xây dựng đội ngũ, sự hợp tác và thông tin liên lạc nội bộ
Quản lý thay đổi tổ chức
Thông tin liên lạc bên ngoài
Chi tiêu & Kế toán
19 Quản lý nhà thầu phụ 20

19 20
 4. Các pha quản lý dự án 4. Các pha quản lý dự án
Định nghĩa và thiết kế dự án Phân bổ lợi Định nghĩa và thiết kế dự án Phân bổ lợi
ích ích
Pha / Giai đoạn Phase / Stage
Lập kế hoạch quản

Lập kế hoạch quản

Kết thúc dự án

Kết thúc dự án
Lợi ích theo kế hoạch sẽ được đánh giá và theo dõi
lý

lý
trong suốt dự án

Rà xét việc thực hiện dự án

Rà xét việc thực hiện dự án

Tối ưu hóa lợi ích là một trong số các mục tiêu chính
Management
Q
của người quản lý dự án. Control
Mobilisation Reporting A

• Chuyển giao công việc, quy trình, kết quả cần đạt cho Theo dõi và quản lý lợi ích
các bộ phận chuyên ngành khác. Quản lý chất lượng
• Nộp hồ sơ, tài liệu đúng hạn, đầy đủ chi tiết về hoạt động Quản lý rủi ro
cũng như quá trình kiểm tra giám sát dự án, đây là cơ sở để Quản lý vấn đề
bảo trì và phát triển dự án trong tương lại. Kiểm soát thay đổi phạm vi
• Giải phóng nhân lực, thiết bị và phương tiện Quản lý cấu hình
Kiểm soát tài liệu
Xây dựng đội ngũ, sự hợp tác và thông tin liên lạc nội bộ
Quản lý thay đổi tổ chức
• Đánh giá mức độ thành công của dự án Thông tin liên lạc bên ngoài
• Xác định các mục cần cải tiến Chi tiêu & Kế toán
• Rút ra bài học kinh nghiệm Quản lý nhà thầu phụ
21 22

21 22

Bức tranh tổng thể quản lý dự án

Khởi động Xây dựng phát biểu về Tạo công bố dự án
dự án công việc

Hoạch định
Xây dựng cấu trúc
công việc
Thực hiện ước
lượng
Lên lịch
biểu
Lên ngân
sách
QUẢN LÝ DỰ ÁN PHẦN MỀM
dự án

Tạo ra tài liệu dự án

Tổ chức và đưa hoạt động
Lập tổ dự án
Thực hiện công Khái niệm
quản trị dự án vào bố tài nguyên
dự án Nguyên lý và tiến trình quản lý dự án
Xác định cách Kỹ năng, kỹ thuật quản lý dự án
làm lại
1. Quản lý rủi ro
Kiểm soát Quản lý dự Theo dõi và Không 2. Quản lý chất lượng
Phân tích sự Lập KH lại ?
dự án án điều phốI tiến
độ
khác biệt 3. Kiểm soát dự án và lập báo cáo
Có 4. Quản lý cấu hinh

Kết thúc
Xác định sửa Các yếu tổ quyết định thành công của dự án
Kết thúc dự đổi cần thiết
dự án án
Thực hiện sửa
đổi
24

23 24
 Mở đầu 1. Quản lý rủi ro
• Quản lý dự án bao gồm kỹ năng quản lý chung • Rủi ro là gì ? Có thể quản lý được
(general management) và kỹ năng lãnh đạo – Những sự kiện có thể làm phá vỡ một dự án rủi ro
(leadership), có tính đến các yếu tố cá nhân. – Những điều không chắc chắn, những khoản nợ
hay những điểm yếu có thể làm cho dự án
– Phương pháp kỹ thuật lập kế hoạch, lập dự toán, kiểm không đi theo đúng kế hoạch đã định
soát công việc để đạt được một kết quả mong muốn đúng
hạn, trong phạm vi ngân sách và phù hợp với đặc tả kỹ • Tại sao cần quản lý rủi ro ? Không thể loại trừ
hết rủi ro
thuật – Tất cả các dự án đều phụ thuộc vào rủi ro
– Quy trình độc lập, gồm các hoạt động phối hợp, kiểm soát – Tiến trình sẽ không đúng theo kế hoạch trong
được, có thời hạn rõ ràng, được thực hiện nhằm đạt được một số giai đoạn của dự án
Giảm thiểu ảnh hưởng của các
một mục tiêu phù hợp với yêu cầu cụ thể về chi phí, thời • Khi nào cần quản lý rủi ro ? sự cố không biết trước cho
gian và nguồn lực. – Khi lập kế hoạch quản lý dự án
– Lập kế hoạch, tổ chức, chỉ đạo và kiểm soát các nguồn tài – Khi dự án sẵn sàng thực thi Nâng cao xác suất thực hiện
nguyên của công ty cho một mục tiêu tương đối ngắn hạn – Khi khôi phục một dự án đã bỏ dở thành công dự án
nhằm tiến tới hoàn thành mục đích và các mục tiêu cụ thể. – Khi rà xét dự án Tạo ra ý thức kiểm soát
Có được các giải pháp hiệu quả
– Khi có sự sai lệch lớn so với kế hoạch xảy ra và kịp thời

25 26

25 26

Quy trình quản lý rủi ro Ví dụ

• Giảm tối thiểu ảnh hưởng của những sự cố không biết trước • Chậm tiến độ xây dựng phần mềm vì các LTV gặp
cho dự án bằng cách xác định và đưa ra những giải pháp tình phải nhiều khó khăn trong giai đoạn lập trình hơn
huống trước khi có những hậu quả xấu xảy ra dự đoán.
Xác định Phân tích Xử lý Giám sát
• Với tiến độ hiện tại, xác suất các LTV không thể
đáp ứng các sự kiện sắp tới đúng hạn là khoảng
30 %.
Xác định mức rủi ro
ban đầu của dự án

bước 1
lập thành văn
bản các rủi ro cụ
thể
• Hành động ngăn ngừa có thể gồm:
Phân tích ảnh
hưởng rủi ro
– Giảm thiểu rủi ro: đào tạo huấn luyện bổ sung cho các
bước 2 LTV
– Loại bỏ rủi ro: hợp đồng thuê khoán chuyên môn với
Xây dựng và triển
khai kế hoạch quản
bước 3
các LTV giàu kinh nghiệm
lý rủi ro
giám sát và cập nhật
các tài liệu rủi ro
bước 4

27 28

27 28
 2. Quản lý chất lượng Quy trình quản lý chất lượng
• Thích hợp với mục đích
1.Lập kế hoạch 2.Thiết lập khung đảm 3. Tiến hành các hoạt 4. Triển khai các họat
• Giảm tối đa sự lãng phí bằng cách thực hiện chất lượng bảo chất lượng động kiểm soát chất
lượng
động hiệu chỉnh

đúng ngay từ lần đầu

à Cân bằng chất lượng
Mục đích

Thoả mãn Đạt chất lượng phải đựợc lên kế hoạch - không tuỳ tiện
nhu cầu Đạt chất lượng xuất phát từ bảo đảm chất lượng và kiểm soát chất lượng
Phương pháp Thực hiện Đạt chất lượng phụ thuộc vào sự hỗ trợ quản lý

29 30

29 30

3. Kiểm soát dự án và lập báo cáo Lập báo cáo

• Lập báo cáo và kiểm soát dự án là nền tảng để quản lý dự
án • Quản trị viên dự án, trưởng nhóm và thành
– Kiểm soát dự án: Nắm bắt và quản lý tiến trình viên nhóm phải:
– Lập báo cáo dự án: Truyền bá hiệu quả những kiến thức này
– Lắng nghe tin nhắn chuyển đến
• Quản trị viên dự án có thể:
– Báo cáo khách quan về thực trạng dự án – Chấp nhận tin xấu và tốt
– Xác định những cản trở và hành động hiệu chỉnh – Hỗ trợ tích cực các thành viên trong nhóm để
– Triển khai các giải pháp
– Hiểu sự ảnh hưởng của công việc tương lai vượt qua trở ngại
– Đưa ra những quyết định hợp lý dựa trên thông tin xác thực

31 32

31 32
 Trao đổi tình trạng dự án Lập báo cáo – WBS
Dự án
• Tập trung vào các thành tựu của các mục tiêu Mức WBS

kinh doanh, chứ không phải vào quy trình dự 1 Giai đoạn

án
• Đưa ra thông tin chính xác tin cậy dựa trên kế 2 Phạm vi

hoạch dự án
3 Hoạt động
• Nêu bật những điểm ngoại lệ so với kế hoạch Quan sát bên ngoài

Chi tiết đội dự án

• Cung cấp thông tin kịp thời 4 Nhiệm vụ

• Bao gồm cả mức nỗ lực có thể chấp nhận

5 Bước t/h
33 34

33 34

Create WBS(3)
Lập báo cáo – WBS
Mức độ phân chia công việc phụ thuộc vào mục tiêu
• Có nhiều cách phân chia công việc: theo sản
phẩm cần bàn giao, theo quy trình, theo mốc 0
Hệ thống m ới
・Bạn có thể hiểu
được các yếu tố của
thời gian, v.v. WBS?
2 3
･Bạn thường xuyên
1 Hỗ trợ
<Chart Form WBS> <Tabular Form WBS> Phát triển Chuyển đổi kiểm tra tiến độ thế
phát triển
nào?
･Có sự phân chia rõ
1. Quản lý dự án
1.1 lập kế hoạch 2.1 2.2 ràng về vai trò
1.1.1 Đưa ra phạm vi
1.1.2 Danh sách hoạt động
Hệ thống con 1 Hệ thống con 2 không?
1.1.3 Lập kế hoạch về tài nguyên ･Gói công việc cần
1.1.4 Ước lượng thời gian
1.1.5 Ước lượng chi phí
dự tính chính xác
1.1.6 Phân tích rủi ro 2.2.1 2.2.2 2.2.3 2.2.4 hơn không?
1.1.7 Lập lịch Test Kiểm
Thiết kế Lập trình
1.1.8 Kế hoạch quản lý dự án Specification thử
1.2 Thực hiện
2. Thiết kế

35 36
 Quy trình lập báo cáo và kiểm soát dự
Lập kế hoạch, theo dõi, báo cáo án
kế hoạch theo dõi và rà xét rà xét các
công việc các dữ kiện KQBG và
Các mục tiêu kinh Báo cáo các chi tiết mục tiêu nỗ lực
báo cáo và phân tích tiến trình Tái định hướng dự án

doanh vấn đề dữ liệu

nhiệm vụ

dữ liệu lập báo cáo

Xác định kết quả bàn giao Xác định vấn đề tiến trình
hiện trạng
kế hoạch quản lý hoạt động
nguồn phân tích
quản lý xu hướng hiệu chnh
dữ liệu
Kết quả bàn giao Báo cáo thực KH công việc hoàn thiện nguồn
quản lý
thực hành
trạng chi tiết
kiểm soát tài chính
Replan/
khác Rebaseline
thay đổi
khác
phiên bản
xác định kế hoạch Các báo cáo từ kế haọch
Dữ liệu hiện tại vấn đề
giải pháp
- đầy đủ Kế hoạch chất lương
- cố gắng hoạt động
tham gia của văn
- chi phí Kế hoạch cập nhật phòng dự án

37 38

37 38

Khuôn khổ kiểm soát dự án Chu kỳ kiểm soát dự án

Mức Công việc kiểm soát Báo cáo
kiểm soát • Nêu rõ ràng chu kỳ các sự kiện cho việc lập báo cáo thực trạng
• Xác định các thông tin thông thường được yêu cầu với các mức điều hành,
quản lý, nhóm
B/c Ban điều hành • Thiết lập thời gian biểu cho việc lập báo cáo yêu cầu đối với từng mức
kế hoạch quản lý
Ban điều hành

B/c Quản trị viên dự án

Ai Khi nào
kế hoạch quản lý HĐQT Các giám đốc dự án hàng tháng: thứ sáu

kế hoạch công việc chi tiết Quản trị viên dự án

Các giám đốc dự án
Uỷ ban điều hành Các nhà tài trợ kinh doanh 2 tuần 1 lần: thứ tư
B/c trưởng nhóm Chủ thực hiện
kế hoạch công
Chủ thực hiện
việc chi tiết Trưởng nhóm Quản lý đơn vị kinh
Quản trị viên dự án 2 tuần 1 lần: thứ hai
doanh
Quản lý kinh doanh
B/c thành viên nhóm
hàng tuần: thứ sáu
Nhóm và Quản trị viên dự án
danh mục nhiệm vụ
Nhóm
39 40
Các báo cáo và biên bản hiện trạng làm theo quy định của VPDA

39 40
 4. Quản lý thay đổi và vấn đề phát
Kiểm soát nguồn thay đổi tiềm năng
sinh
Các yêu cầu mới và
• Thay đổi là gì ? Các đánh giá khác
đưa ra những khám
Luật pháp
phá Kiểm tra
– Bất cứ hoạt động nào thay đổi phạm vi, kết quả bàn giao, kiến trúc cơ Xuất hiện nhà cung
nhau của người sử
dụng
• Đơn vị
bản, chi phí, lịch trình của một dự án cấp phần mềm mới
• Khối
• Tích hợp
• Tại sao cần phải quản lý thay đổi và vấn đề phát sinh ? • Chấp thuận

– Thay đổi và vấn đề phát sinh là 2 lý do thường làm dự án thất bại

• Làm thế nào để kiểm soát thay đổi và giải quyết các vấn đề phát Các nguồn thay
đổi tiềm năng
sinh ? các tổ chức bên
Tinh chỉnh mã
nguồn
ngoài
– Giảm rủi ro dự án nhờ quy trình hiệu quả quản lý thay đổi và vấn đề • Khách quan
• Chủ quan
– Các thành viên nhóm hiểu được quy trình quản lý thay đổi và vấn đề
– Ghi chép đầy đủ về các yêu cầu thay đổi/ vấn đề Các quyết định
về chính sách và
nghiệp vụ

Các nguồn cụ thể của

dự án
Rà xét
Chuyển đổi kiểm soát
41 chất lượng 42

41 42

Kiểm soát chi phí thay đổi 5. Quản lý cấu hình

• Quan niệm sai về quản lý cấu hình:
– Đây là vấn đề về LANs, WANs, phần cứng, ...
– Đây là các hoạt động mang tính kỹ thuật cao
– Nó liên quan rất ít đến quản lý dự án
• Quản lý cấu hình để làm gì ?
– Cung cấp việc truy cập an toàn và đơn giản đối với bản
sao tổng thể về các kết quả bàn giao đã được thông
qua.
– Kiểm soát được thực trạng của các kết quả bàn giao
Yêu Thiết Viết Kiểm Sử và mối quan hệ qua lại lẫn nhau giữa các kết quả này.
cầu kế code thử dụng

43 44

43 44
 Kỹ thuật và quy trình quản lý cấu hình Kiểm soát phiên bản
• Cung cấp một kho chứa an toàn đối với các kết
quả bàn giao
• Cho phép việc kiểm soát và tiết lộ có nguyên tắc
các kết quả bàn giao thông qua vòng đời của nó, 0.1 0.2 0.n 1.1 1.2 1.n
với đầy đủ các dấu tích lịch sử, đảm bảo phiên
bản đúng và cập nhật, đã được kiểm tra và phát
hành
• Kiểm soát thay đổi cuả các kết quả bàn giao, đảm
bảo các kết quả này được lưu theo đúng thứ tự Được chấp nhận
• Cung cấp việc lập báo cáo về hiện trạng của các
kết quả bàn giao và những thay đổi của chúng 1.0 2.0

45 46

45 46

Các chức năng quản lý cấu hình

Trả lại mục được Cập nhật Gửi mục

QUẢN LÝ DỰ ÁN PHẦN MỀM

(3) & baseline
(4)

Lấy mục để cập nhật

(2) Kho QL
Cấu hình
Backup / lưu giữ (5)

Bổ sung khoản
mục mới (1) Khái niệm
Nguyên lý và tiến trình quản lý dự án
Kỹ năng, kỹ thuật quản lý dự án
Các báo cáo Các yếu tổ quyết định thành công của dự án
Kiểm soát
(6)

47 48

47 48
 Bài tập: Tỉ lệ thành công của dự án Dự án nào là thành công ?
phần mềm là bao nhiêu ? Dự án nào tốt hơn ?
– 90% ? • Hệ thống A
– 70% ? – Bàn giao hệ thống đúng hạn
– 50% ? – Hoàn thành dự án với kinh phí được cấp
– 30% ? – Hầu như không dùng đến sau khi nghiệm thu
• Tại sao các dự án lại thất bại ?
• Điều gì khiến một dự án thành công ? • Hệ thống B
– Trễ hạn
– Cần thêm vốn đầu tư để hoàn thành dự án
– Đã được sử dụng hơn 10 năm
49 50

49 50

Dự án nào là thất bại ? Dự án nào là thất bại ?

• Một dự án mà: • Một dự án mà:
– Không đạt được các mục tiêu của dự án, và/hoặc – Không đạt được các mục tiêu của dự án, và/hoặc
– Bị vượt quá ngân sách ít nhất 30% – Bị vượt quá ngân sách ít nhất 30%
Tại sao dự án thất bại ? Tại sao dự án thất bại ?
Không quen thuộc với không giao nhiệm
phạm vi và sự phức tạp vụ với trách nhiệm
của dự án: 17% lý do khác: 12% lý do khác: 18%
cụ thể: 18%

thiếu kỹ năng
chuyên môn: 15%

thiếu thông tin: 21%

quản lý dự án quản lý dự án
Không phối
Không rõ không tốt: 32% không tốt: 48%
hợp đồng bộ: 21%
các mục tiêu: 18%
51 52

51 52
 Nguyên nhân thất bại của Project Để tránh thất bại
• Cán bộ không hiểu các yêu cầu của khách hàng
• Phạm vi của dự án không rõ ràng Cải tổ việc quản
lý dự án
• Quản lý thay đổi yếu kém Nghiên cứu khả
• Công nghệ được lựa chọn bị thay đổi thi

• Các yêu cầu nghiệp vụ bị thay đổi Tăng số thành viên

tham gia
• Hạn công việc không thực tế
• Khách hàng cản trở Tăng các phương sách từ
bên ngoài

• Nhà tài trợ bị thay đổi Không phải những lý

• Thiếu cán bộ có kỹ năng thích hợp do trên

• Các nhà quản lý lảng tránh các kinh nghiệm và các bài 0 10 20 30 40 50 60 70 80 90 %

học tốt. Đáp ứng

53 54

53 54

Các mức đánh giá thành công của một

Yếu tố thành công của dự án
dự án
• Bắt đầu bằng đối xử đúng với đúng quyền hạn
Mức 4 • Luôn quan tâm, theo dõi định kỳ
Tiềm năng
tương lai • Luôn theo dõi ghi chép tiến trình
Thành công Mức 3 • Ra quyết định đúng đắn, sáng suốt
kinh doanh
• Tiến hành phân tích đúc rút bài học kết thúc
Thành công dự án Mức 2 dự án.

Thành công quản lý dự án

Mức 1

55 56

55 56
 10 quy tắc vàng Nguyên tắc 5W2H (Boehm)
• Quản lý dự án thành công chính là vấn đề về con người
– nhưng không được quên quản trị
• Tại sao hệ thống đang được phát triển (Why)
• Khám phá các nguồn hỗ trợ và chống đỡ • Những cái gì sẽ được hoàn thành (What)
• Sự hiện diện có thể là dối trá - xem xét lịch trình ẩn đằng sau
• Phải hiểu rằng những con người khác nhau thì có những cách nhìn khác nhau • Khi nào (When)?
•
– hãy đặt mình vào địa vị của họ
Thiết lập kế hoạch của bạn sao cho có thể chỉnh sửa dễ dàng
• Ai sẽ chịu trách nhiệm về 1 chức năng(Who)
• Đối mặt với từng sự kiện như là nó đã có từ trước • Nó sẽ được đặt ở đâu trong tổ chức (Where)
• Sử dụng quản trị để hỗ trợ cho các mục đích của dự án
• Thời gian mục tiêu đối với từng nhiệm vụ không được giống như đã nêu trong kế • Công việc sẽ được hoàn thành về mặt Kĩ thuật
•
hoạch
Đọc lại phạm vi và các mục tiêu của dự án mỗi tuần 1 lần
và được quản trị như thế nào (How)
• Không ngạc nhiên! • Lượng tài nguyên cần thiết (How)?

57 58

57 58

Kết luận
• Quản lý dự án phần mềm là hoạt động bao
trùm các hoạt động sản xuất phần mềm.
• Nhân tố chính là Con người. Các kỹ thuật khác
nhau về giao tiếp và phối hợp được dùng để
hỗ trợ công tác nhân sự.
• Quản lý dự án nhấn mạnh công tác đánh giá,
lượng hoá, kế hoạch và kiểm soát rủi ro.

59

59