Giáo trình Quản trị dự án phần mềm (Phần 1)

Việc quay lui để chỉnh sửa chắc chắn là tốn kém. Nhưng thực tế thì những phát hiện sai sót, hoặc những thay đổi 
xẩy ra trong lúc làm dự án hoặc sau đó thì hệ thống vẫn phải cập nhật được các thay đổi đó. Độ phức tạp của 
những cập nhật này không chỉ phụ thuộc vào bản chất của thay đổi mà còn phụ thuộc vào tính uyển chuyển của 
hệ thống. Ví dụ một ứng dụng dùng các tập tin định dạng binary để lưu trữ dữ liệu thì khó thay đổi hơn là những 
cái dùng cơ sở dữ liệu quan hệ. Tuy nhiên đây là loại vấn đề thuộc kỹ thuật mà dự án dùng trong thiết kế, chứ 
không phải của qui trình thác nước. 
Qui trình này thích hợp với những dự án đã biết rõ yêu cầu của khách hàng. Do đó qui trình này thường được 
dùng sau khi đã thu thập đầy đủ yêu cầu bằng các qui trình khác (ví dụ qui trình prototype). 
6.3.2 Qui trình Prototype - Qui trình Phát triển lặp (Iterative Development) 
Qui trình này dựa trên ý tưởng rằng thông qua 1 loạt các pha; ứng với mỗi pha thêm vào vài chức năng, và với 
mỗi chức năng đưa khách hàng đánh giá để gợi ý khách hàng khai báo các yêu cầu rõ hơn; cứ lặp lại như thế cho 
đến vòng lặp cuối cùng là lúc „vét cạn‟ được hết các yêu cầu của khách hàng, không cần biết có thể các yêu cầu 
này lúc đầu mơ hồ như thế nào. 
Nguy hiểm của qui trình này, đại khái là những công việc mà người ta thử và sửa sai thông qua ngẫu nhiên. Vì 
vậy để có thể áp dụng qui trình này có khả năng thành công thì dự án phải cần được xác định 3 đặc trưng sau: 
1. Mục tiêu chung của dự án: ở giai đoạn đầu phạm vi của dự án có thể không rõ ràng hoặc không được 
xác định tốt, nhưng nói chung phải biết mục đích của dự án là gì. 
2. Kế hoạch tổng quan: dự án có thể chỉ ra có cụ thể bao nhiêu vòng lặp, mỗi vòng lặp sẽ xây dựng 
những chức năng nào. 
3. Kế hoạch cho từng vòng lặp: có thể lên kế hoạch chi tiết cho từng vòng lặp, mỗi vòng lặp được coi 
như là một dự án. Kế hoạch chi tiết cho một vòng lặp gồm các công việc sau: 
 Xác định các yêu cầu hay các đặc tả chức năng cho vòng lặp đó. 
 Thiết kế các chức năng này. 
 Lập trình và kiểm thử đơn vị các chức năng này. 
 Kiểm thử tích hợp và chuyển dần kết quả thành sản phẩm cuối. 
Có thể áp dụng qui trình thác nước cho từng vòng lặp. 
Trưởng dự án phải bảo đảm rằng mỗi vòng lặp được lên kế hoạch trong phạm vi của mục tiêu tổng thể của dự án 
và rằng mỗi vòng lặp được vận hành theo cùng các qui tắc của toàn dự án, và dần trở thành sản phẩm cuối cùng. 
Cần lưu ý rằng có 2 cách sử dụng kết quả của vòng lặp: 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
19 
Nếu kết quả của mỗi vòng lặp chỉ với mục đích là làm rõ và xác định được các yêu cầu của khách hàng thì qui 
trình này sẽ mang tên là qui trình Prototype. Lúc này kết quả của mỗi vòng lặp không cần phải kiểm thử, không 
cần phải theo đúng các chuẩn của tổ chức. Vì sau khi nắm rõ các yêu cầu của khách hàng, các kết quả đó sẽ bị bỏ 
đi, người ta sẽ bắt đầu phân tích, thiết kế,.. để phát triển phần mềm dựa trên các yêu cầu đã thu được này. 
Như tên gọi, qui trình prototype chủ yếu là tạo ra một phần mềm nháp dùng để thu thập đủ và đúng các yêu cầu 
của khách hàng . 
Hình 3.2: qui trình Prototype 
Nếu kết quả của mỗi mức lặp là một (số các) chức năng đơn vị, sẽ được kết lại với nhau ở vòng lặp cuối để thành 
sản phẩm cuối cùng, thì qui trình này sẽ mang tên là qui trình Phát triển lặp. Lúc này kết quả của mỗi vòng lặp 
sẽ được giao cho khách hàng sử dụng, do đó nó phải theo đúng các chuẩn đã đề ra, phải được kiểm thử kỹ càng, 
phải có hồ sơ phát triển, phải có chất lượng, và phải được khách hàng chấp nhận. 
Hình 3.3 
Trưởng dự án phải chắc chắn công sức bỏ ra để phát triển các vòng lặp phải tương ứng với mục đích sử dụng kết 
quả của nó để không lãng phí. 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
20 
6.3.3 Qui trình tăng dần (Incremental lifecycle model) 
Qui trình này thích hợp với bài toán có yêu cầu có thể phân hoạch thành những gói độc lập. Chỉ cần thiết kế kiến 
trúc tổng thể cho bài toán với những phân hoạch cụ thể, thành những hệ thống con độc lập, kế đó xây dựng từng 
hệ thống này và giao sản phẩm cuối (hệ thống con) cho khách hàng. 
Hình 3.4 
6.3.4 Qui trình xoắn ốc (Spiral Life Cycle) 
Qui trình xoắn ốc là một loại qui trình lặp. qui trình này sẽ lặp lại nhiều lần 4 giai đoạn chính trước khi tạo ra kết 
quả cuối cùng. Qui trình khởi đầu ở trung tâm của xoắn ốc –mặt phẳng phần tư bên trái, trên. Từ điểm bắt đầu 
đó, qui trình sẽ đi xoắn ốc ngược chiều kim đồng hồ qua 4 giai đoạn, mỗi giai đoạn được biểu diễn trên một phần 
tư mặt phẳng: 
1. Xác định các mục tiêu, các giải pháp, và các ràng buộc: giai đoạn này là thiết lập các mục đích 
chung bắt đầu và lấy được thỏa thuận, yêu cầu của khách hàng để có thể tiến hành các giai đoạn kế tiếp. 
2. Xác định và giải quyết rủi ro: giai đoạn này là phân tích rủi ro, lên chiến lược đối phó rủi ro ngay từ 
lúc rất sớm có thể được. Nếu các rủi ro không thể khắc phục được thì hủy dự án ngay lúc này, thiệt hại 
sẽ ít hơn. 
3. Phát triển prototype: xây dựng prototype thứ i dựa trên các yêu cầu của giai đoạn 1, 2. 
4. Khách hàng đánh giá: chạy thử prototype i cho khách hàng xem, gợi ý khách hàng nói rõ thêm các 
yêu cầu còn mơ hồ hoặc còn tiềm ẩn. 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
21 
Hình 3.5: mô hình xoằn ốc 
Qui trình này thích hợp cho các dự án lớn hoặc các dự án có những mục tiêu không rõ ràng. Mỗi vòng lặp sẽ chi 
tiết hóa cái nhìn về phạm vi và về giải pháp, cho tới khi kết quả thỏa được các yêu cầu của khách hàng. 
6.3.5 Lập trình cực độ (Extreme Programming) 
Qui trình này mới xuất hiện gần đây. Nó nhấn mạnh việc tổ chức nhóm nhỏ, nhanh; xây dựng hệ thống được tiếp 
cận theo lối làm việc cộng tác. Lập trình cực độ có các đặc trưng sau: 
 Nhóm sẽ họp trực diện, ngắn gọn mỗi ngày thay vì mỗi tuần. 
 Lập trình đôi, nghĩa là 2 người sẽ cùng lập trình trên một máy tính chứ không phải một cá nhân đơn 
độc. 
 Mã nguồn sẽ được giao nộp theo cá nhân, nhưng là tài sản của tòan nhóm nghĩa là mã nguồn được sở 
hữu và phát triển bởi cả nhóm. 
 Dùng „câu chuyện người dùng ‟ (user stories) để mô tả yêu cầu ở dạng phi hình thức. 
 Rất nhấn mạnh kiểm thử, trong đó kế hoạch kiểm thử được xây dựng ở giai đoạn đầu phát triển chứ 
không phải ở cuối. 
Lập trình cực độ là qui trình lặp. Nó được lặp trong kế hoạch phát hành (release) tổng thể. Ở mỗi vòng lặp, nhóm 
sẽ review các câu chuyện của người dùng và, cùng với người dùng quyết định câu chuyện nào sẽ được phát triển 
ở vòng lặp kế. Người dùng có hợp tác chặt chẻ trong qui trình phát triển: tinh chỉnh các câu chuyện, chuẩn bị, 
phê duyệt các kế hoạch kiểm thử, và review, kiểm thử, phê duyệt các kết quả. Mỗi vòng lặp, có thể ngắn vài 
tuần, sẽ phải giao những bản phát hành nhỏ để người dùng có thể cài đặt dùng ngay. 
Lập trình cực độ có vẻ như gồm những qui trình về sự cộng tác giữa nhóm và khách hàng, hai bên hợp tác chặt 
chẻ và kết hợp năng lực cao độ để tạo ra kết quả cuối cùng mà không bị giới hạn bởi một khái niệm qui ước nào 
về phát triển ứng dụng. 
Tóm lại, lập trình cực độ gồm lên kế hoạch chiến lược phát hành tổng thể, lên kế hoạch mỗi vòng lặp, và trong 
mỗi vòng lặp, các giai đoạn quen thuộc như xác định yêu cầu, rút ra từ câu chuyện người dùng; thiết kế rút ra từ 
các kế hoạch kiểm thử; phát triển rút ra từ lập trình đôi; và cài đặt rút ra từ các kiểm thử của người dùng. Đó là 
các phần cốt lõi của qui trình. 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
22 
Câu hỏi: sự khác biệt giữa các qui trình phát triển lặp, prototype và xoắn ốc, lập trình cực độ? 
6.4 Sửa đổi quy trình (Process Tailoring) 
Ở một mức độ vĩ mô, một quy trình chuẩn có thể cung cấp một cấu trúc tốt nhất của các pha cho một lớp các dự 
án và tạo ra một điểm khởi đầu tốt cho việc xác định tiến trình.Tuy nhiên, một quy trình chuẩn không thể phù 
hợp cho mọi tình huống; quy trình tốt nhất có thể là sự sửa đổi dựa trên một quy trình chuẩn nào đó. Vì vậy, để 
quyết định sử dụng quy trình nào, trưởng dự án phải lựa chọn quy trình căn bản và cũng quyết định cách điều 
chỉnh (customize) để có được một quy trình mới phù hợp với dự án. 
Một quy trình không được xác định – dù cho đó là quy trình chuẩn mực của một tổ chức hay quy trình đã sử 
dụng trong đề án trước - thì đều có thể áp dụng cho mọi trường hợp và mọi đề án. Một quy trình đã được xác 
định phải được sửa đổi để phù hợp với những yêu cầu của đề án hiện tại. 
Sửa đổi là tiến trình điều chỉnh một quy trình đã có sẳn của một tổ chức để đạt được một quy trình phù hợp cho 
những yêu cầu thương mại, kĩ thuật đặt biệt của một dự án. Có thể hiểu sửa đổi nghĩa là thêm, xóa bỏ, hay chỉnh 
sửa các giai đoạn hay công việc của một quy trình sao cho quy trình kết quả thích hợp cho việc đạt được các mục 
tiêu của dự án. 
 Không điều khiển được việc sửa đổi qui trình một cách hiệu quả sẽ đưa đến việc tạo ra một quy trình dở. Để việc 
tái sử dụng một cách hiệu quả các quy trình cũ, tổ chức phải cung cấp sẳn các hướng dẫn cho việc sửa đổi. Các 
hướng dẫn này xác định các điều kiện và những loại thay đổi nào nên thực hiện trên qui trình chuẩn. Thực chất là 
chúng xác định một tập các khuynh hướng cho phép trên quy trình chuẩn với hi vọng là có thể xác định một quy 
trình tối ưu cho dự án. 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
23 
Hình 3.6 Sửa đổi qui trình 
Để minh họa nhu cầu sửa đổi, hãy xem một công việc trong qui trình phát triển phần mềm – Thực hiện review 
mã nguồn, review mã nguồn có thể được thực hiện bởi một nhóm hoặc bởi một cá nhân. Qui trình phát triển 
chuẩn không chỉ rõ review mã nguồn được thực hiện như thế nào. Các hướng dẫn có thể hướng dẫn trưởng dự án 
với lời khuyên rằng Thực hiện review mã nguồn chỉ được thực hiện cho các loại chương trình nào đó (như 
chương trình phức tạp hay các giao tiếp bên ngoài) và bằng việc đề nghị một dạng review tối ưu (nhóm hay cá 
nhân). 
Sửa đổi qui trình được thực hiện ở hai mức : sơ lược và chi tiết. 
6.4.1 Sửa đổi sơ lược: 
Ở mức sửa đổi sơ lược, phụ thuộc vào đặc tính của dự án, trưởng dự án áp dụng các hướng dẫn tổng quan cho 
việc sửa đổi quy trình chuẩn. Nghĩa là, cung cấp một vài qui tắc chung liên quan đến loại hoạt động chi tiết nào 
đó. Để thực hiện bước này, đầu tiên trưởng dự án phải xác định các đặc trưng của dự án. Đối với dự án phần 
mềm, các đặc trưng sau đây được sử dụng cho việc sửa đổi : 
 Kinh nghiệm và mức kĩ năng của nhóm và trưởng dự án. 
 Kích thước tối đa của nhóm làm dự án. 
 Sự rõ ràng của yêu cầu 
 Thời gian hoàn thành đề án 
 Hiệu quả của ứng dụng 
Kinh nghiệm của một nhóm được xem là cao nếu đa số các thành viên có nhiều hơn hai năm kinh nghiệm với kĩ 
thuật đang được triển khai trong dự án, ngược lại, thì xem là thấp. Hiệu quả của ứng dụng được xem là cao nếu 
hiệu quả của nó trên nghiệp vụ của khách hàng hay trên nghiệp vụ của công ty (làm dự án) là đáng kể, ngược lại 
là thấp. Thời gian hoàn thành đề án được xem là đặc biệt ngắn nếu đề án chỉ kéo dài ít hơn ba tháng. 
Các hướng dẫn sửa đổi sơ lược được cung cấp cho các giá trị khác nhau của các đặc trưng này. Nói chung, chúng 
liên quan đến review, đến nguồn lực, đến lịch biểu, đến nguồn tài nguyên hay những nghi thức. Các hướng dẫn 
liên quan đến review chỉ rõ khi nào review nên được thực hiện và loại review nào được áp dụng. Tương tự, các 
hướng dẫn liên quan đến nguồn lực đề nghị các bước được chọn cho dự án mà có thể ảnh hưởng đến sự nguồn 
Qui trình kết quả. 
(Quy trình của đề án) 
Sửa đổi Quy Trình 
Đặc trưng của dự án. 
Qui trình chuẩn 
Các hướng dẫn sửa đổi 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
24 
lực. Những hướng dẫn chung đó thiết lập ngữ cảnh cho việc sửa đổi quy trình chi tiết và định nghĩa một quy 
trình phù hợp cho dự án. 
6.4.2 Sửa đổi chi tiết: 
Sửa đổi chi tiết bao gồm sự thực thi các hành động, như review, viết tài liệu cần thiết. Hướng dẫn (sửa đổi) có 
thể xác định một hành động như là tùy chọn, trong trường hợp này trưởng dự án có thể quyết định có hay không 
thực thi hành động đó. Ví dụ, với review, có 3 tùy chọn là Review theo nhóm, Review cá nhân hoặc Không 
review. Ngoài ra trưởng dự án có thể thêm một vài hành động mới hay có thể lặp lại một vài hành động nào đó. 
Khi việc sửa đổi chi tiết hoàn thành, một dãy các hành động được thực thi trong qui trình phần mềm của dự án đã 
được định nghĩa. Những sự định nghĩa này sau đó được sử dụng để lên kế hoạch và lập thời gian hoạt động cho 
các công việc của dự án và hình thành nền tảng cho sự thực thi dự án. Sự sửa đổi được thực hiện nổi bật trong kế 
hoạch dự án, vì thế định nghĩa và sửa đổi qui trình cũng phải được review khi kế hoạch được review. 
6.5 Qui trình làm dự án. (Chu kỳ sống của dự án) 
Hay ngắn gọn hơn Qui trình làm dự án. Có nhiều qui trình được đề nghị, nhưng các chức năng cốt lõi vẫn giống 
nhau. Qui trình được giới thiệu dưới đây [3] gồm năm pha: 
Nhận xét: các pha 2,3,4 tạo thành một vòng lặp: 
1. Trong khi kế hoạch được thực thi (pha 3), 
2. Trưởng dự án phải giám sát chặt chẻ coi trong thực tế dự án có được thực thi đúng như theo kế hoạch 
không (pha 4)? 
3. Nếu có sự khác biệt xẩy ra thì trưởng dự án phải điều chỉnh lại bản kế hoạch sao cho dự án kịp tiến độ 
(pha 2). Kế đó quay lên bước 1 với bản kế hoạch vừa mới được cập nhật. 
Vòng lặp sẽ chấm dứt khi kết thúc dự án. Sau đây là nội dung cụ thể của từng pha. 
6.5.1 Xác định phạm vi của dự án 
Pha này nếu bị bỏ qua thì thời gian thực hiện dự án sẽ bị kéo dài do yêu cầu bị hiểu sai, rủi ro tăng cao. 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
25 
Xác định phạm vi dự án là một quá trình trao đổi giữa 2 bên về thông tin của dự án, kết quả của pha này là một 
văn bản diễn đạt bằng ngôn ngữ nghiệp vụ. 
Các bước: 
1. Xác định mục đích chung: mục đích tổng quan của dự án. 
2. Định nghĩa các mục tiêu cần đạt: chi tiết hóa mục đích tổng quan thành các mục tiêu nhỏ hơn. 
3. Xác định các lợi ích nghiệp vụ: trình bày khách hàng sẽ được hưởng lợi ích gì, nhóm thực hiện sẽ được 
hưởng lợi ích gì, khi dự án thành công. 
4. Liệt kê các giả thiết, rủi ro, trở ngại: dự án này có khả năng gặp những rủi ro, trở ngại gì? Các giải pháp 
khắc phục. 
Kết quả của pha này là một bảng phát biểu công việc (Statement Of Work –SOW, xem chương 4) 
6.5.2 Lên kế hoạch. 
-Xác định các công việc và ước lượng tài nguyên: từ các yêu cầu trừu tượng (mục tiêu ban đầu), trưởng dự án sẽ 
cụ thể hóa thành các công việc chi tiết đủ để có thể ước lượng thời gian thực hiện và các tài nguyên cho từng 
công việc này. Từ đây sẽ tính được chi phí thực hiện các công việc của dự án. 
-Sắp xếp thứ tự thực hiện các công việc: xác định trình tự thực hiện các công việc để tính thời gian thực hiện của 
toàn dự án. 
 -Chọn ra qui trình làm phần mềm: dựa vào bản chất của dự án mà trưởng dự án sẽ chọn hoặc chế tác 
(customize) ra một qui trình từ các qui trình có sẳn để phát triền phần mềm đó. 
-Thử các chiến lược : trưởng dự án có thể dùng bản kế hoạch (ban đầu) này như một mô hình để thử, dự đoán 
các biến cố có thể xẩy ra trong tương lai và đưa ra những chiến lược, giải pháp khắc phục. Giống như người ta 
dùng mô hình toán học để tính toán lưu lượng xe chạy qua các con đường trong thành phố, để từ đó có thể dự 
đoán được các con đường nào thường hay xảy ra kẹt xe và đưa ra những giải pháp khắc phục. 
-Một số tình huống cho mô hình kế hoạch: 
 Trưởng dự án xét coi nếu có công việc nào có khả năng hòan tất sớm/trễ thì liệu có thể điều chỉnh lại 
lịch biểu của các công việc sau nó, để cho dự án không bị trễ không? 
 Hoặc nếu có một công việc có khả năng kết thúc trễ thì liệu có thể điều động nguồn lực từ các dự án 
khác để phục hồi tiến độ dự án không? 
 Về phân công tài nguyên, liệu có thể khắc phục được các mâu thuẫn không thể giải quyết được, để 
không làm ảnh hưởng đến lịch biểu? Ví dụ có công việc thiết kế web cần 1 người thực hiện toàn thời 
gian trong 2 ngày nhưng trong công ty chỉ có duy nhất một người biết thiết kế web mà chỉ rảnh bán thời 
gian. Hãy liệt kê các phương án giải quyết? Xem gợi ý cuối chương. 
 Có thể phân công nguồn lực từ dự án này sang dự án khác mà không làm ảnh hưởng xấu lịch biểu của 
từng đề án? 
Kết quả của pha này là bảng kế hoạch chi tiết cua dự án. (Project Plan xem chương 4) 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
26 
6.5.3 Thực thi kế hoạch 
Pha này là cụ thể hóa pha 2. Ở pha 1 chỉ ước lượng số lượng tài nguyên, về người thì chưa biết cụ thể là ai, về 
thời gian thực hiện cũng chưa biết cụ thể ngày, tháng, năm nào. Tất cả chi tiết chung chung này sẽ được rõ ràng, 
cụ thể ở pha này. 
Các công việc: 
-Tuyển mộ và tổ chức nhân sự: lên kế hoạch chọn nhân sự trong công ty, hoặc phỏng vấn để tuyển mộ nhân sự từ 
bên ngoài công ty. 
-Thiết lập các quy tắc họat động: đưa ra các chuẩn, quy định, nguyên tắc chung của dự án. 
-Phân cấp các nguồn lực: tổ chức nhân sự. Tránh để một cá nhân chịu trách nhiệm thành bại về dự án. 
-Lên lịch biểu: phân công công việc, thời gian lịch thực hiện công việc đó và vật tư cho nhân sự cụ thể. 
-Sưu liệu cho từng công vịêc: ghi vết lại tất cả các công việc đã làm. 
6.5.4 Giám sát và điều chỉnh 
Pha này chủ yếu là quản lý thay đổi, giám sát xem có sự khác biệt nào giữa kế hoạch và thực tế không? Nếu có, 
trưởng dự án phải điều chỉnh lại kế họach để giữ bản kế hoạch ở thế cân bằng, nghĩa là bảo đảm, chất lượng, 
không bị trễ, vượt chi, v..v.. 
Để tiến trình giám sát được tốt, cần phải thực hiện các công việc sau: 
-Xây dựng hệ thống báo cáo tiến độ: trưởng dự án phải thiết kế sẳn những biểu mẫu báo cáo, các biểu mẫu này 
sẽ được tái sử dụng, tinh chế và tùy biến theo từng dự án sau này. 
-Cài đặt công cụ, qui trình kiểm sóat sự thay đổi: các công cụ, qui trình này có thể vừa là thủ công, vừa tự động 
(dùng phần mềm), vừa bán tự động. 
-Định nghĩa các quy trình phát hiện vấn đề: tương tự như trên. 
6.5.5 Đóng dự án. 
Gồm các công việc sau: 
-Lấy xác nhận của khách hàng: Lấy chữ ký kết thúc của khách hàng, công việc này sẽ không dễ dàng nếu trong 
quá trình thực hiện dự án trưởng dự án đã có sự giao tiếp không tốt với khách hàng, không lấy được lòng tin của 
khách hàng., v..v 
-Cài đặt các kết quả của dự án 
-Huấn luyện sử dụng: tổ chức huấn luyện khách hàng sử dụng sản phẩm. 
-Hòan tất tài liệu: gồm tài liệu kỹ thuật, tài liệu huấn luyện sử dụng,.v..v.. 
-Chuẩn bị bảo hành bảo trì. 
-Thông báo kết thúc đề án: thông báo kết thúc dự án trên toàn công ty, giải phóng nhân sự, máy móc, mặt bằng, 
tài khoản,.v..v 
-Cập nhật thông tin kinh nghiệm tiến trình: lưu vết những kinh nghiệm về dự án để học tập và chia sẻ 
Giáo Trình Quản Trị Dự Án Phần Mềm Khoa Công Nghệ Thônh Tin 
 Bộ Môn Công Nghệ Phần Mềm Đại Học Khoa Học 
27 
Một góc nhìn khác về mức độ giao nhau giữa các pha trong qui trình làm dự án. 
6.5.6 Áp dụng cả 5 pha của qui trình? 
Việc áp dụng các pha của qui trìnhvào dự án còn phụ thuộc vào các yếu tố như việc dự án có các sử dụng công 
nghệ mới, độ phức tạp, độ lớn, thời gian thực hiện dự án, v..v 
Với những dự án lớn, thực hiện trên 1.5 năm, nhiều rủi ro, độ phức tạp cao, có dùng công nghệ mới ra, v..v.. 
thường người ta áp dụng cả 5 pha. Với những dự án nhỏ, thường người ta chỉ áp dụng một số bước trong một số 
pha. 
Đáp án: 
Các phương án: 
1. Thuê hằn một người ngoài thực hiện tòan thời gian công việc này. 
2. Thuê một người ngoài thực hiện bán thời gian chung với người trong công ty. 
3. Đề một mình người trong công ty thực hiện và làm thêm ngoài giờ cho kịp tiến độ. 
Chọn phương án 2. Tại sao?