Lý Thuyết Quản Lý Quy Trình Phần Mềm

Lý Thuyết Quản Lý Quy Trình Phần Mềm
(Tổng kết theo Slide bài giảng)
1/Trình bày các pha trong chu trình sống của phần mềm. Nếu các hoạt động chính
và s\n phẩm chính của từng pha.
Các pha trong chu trình sống của phần mềm:
- Lên kế hoạch.
- Phân tích yêu cầu.
- Thiết kế hệ thống.
- Code.
- Tích hợp , kiểm thử
- đưa cho khách hàng đánh giá.
- Release cho khách hàng đánh giá.
- Bảo trì và hỗ trợ khách hàng.
1/lên kế hoạch :
- gặp khách hàng lấy yêu cầu: hỏi khách hàng có bao nhiêu tiền, bao lâu có kết
quả, muốn làm gì.
- Coi xem mình có bao nhiêu người làm dự án này, xem thử đã làm những dự án
nào tương tự như thế này chưa? Đưa ra kế hoạch cho dự án đặt ra mục tiêu cần
đạt được. => Định giá dự án => lên thời gian biểu cho dự án => chia công việc
cho từng người.
2/ Phân tích yêu cầu:
- Sử dụng use case.
- Từ use case viết ra bảng Spec(bảng ghi chi tiết các chức năng), đây là file.xls
dùng để ghi yêu cầu.
- Sử dụng bản SRS đưa ra từng yêu cầu của dự án.
- Statement of work: danh sách liệt kê các công việc cần làm, thông thường là
file word.
3/ Design:
- Thiết kế tổng quát hệ thống  thiết kế chi tiết.
KX_CPHGHL Tây Ninh Page 1
- Thiết kế hệ thống:chia hê thống thành những phần riêng lẻ( gồm những phần

nào, làm gì)
- Thiết kế chi tiết: bao gồm từng lớp, mỗi lớp có bao nhiêu phương thức cụ thể, vẽ
ra mối quan hệ.
4/ Implementation (hiện thực hóa code)
5/Testing
- Test Specs(có đúng với các use case,feature mô tả trong specs hay không)
 Chứa các trường hợp cần kiểm thử
 Đảm bảo các testcase đầy đủ
 Dữ liệu cần kiểm thử
- Test Data and Hardware(Dữ liệu đủ hay không,phần cứng load có tốt hay
không,có đúng với các mô tả về giao diện,…)
- Integration : Mô tả cách mà ứng dụng sử dụng trong thực tế  đảm bảo tích hợp
các module chạy ok.
 Sử dụng mô hình tích hợp nào

 Sử dụng mô hình thanh toán nào trong ứng dụng ,..
6/Evaluation:
- đưa cho khách hàng đánh giá, phù hợp hay không còn biết mà chỉnh sửa.
KX_CPHGHL Tây Ninh Page 2
7/Release:
- Chuyền giao phần mềm cho khách hàng, cùng với hướng dẫn sử dụng chương
trình.
8/ Bảo trì:
- sửa các lỗi, thêm chức năng phụ, chuyển từ hệ thống này sang hệ thống khác,
đưa bản hướng dẫn sử dụng mới.
2/Trình bày các khái niệm của quản trị dự án.
3/Trình bày các khái niệm của đảm bảo chất lượng.
Quản lý chất lượng: đảm bảo phần mềm đạt được những yêu cầu cao nhất mà
khách hàng quyết định.
Quản lý chất lượng có 2 yêu cầu:

- QA(đưa ra các plan, kết quả..)QA là người đảm bảo chất lượng.
- QC: đảm bảo chất lượng.
Đảm bảo chất lượng khác gì kiểm thử?
- Kiểm thử thật ra là kiểm tra các Unit Test, kiểm tra tích hợp trên những gì ta
viết mã nguồn, Test.
KX_CPHGHL Tây Ninh Page 3
- Đảm bảo chất lượng: ví dụ, trong quá trình lên kế hoạch ta có 1 bảng kế hoạch
chứa toàn bộ những Plan của dự án đó, hỏi rằng ai đảm bảo bảng kế hoạch đó là
đúng?--> chính QA là người sẽ lọc dữ liệu, dùng công thức tính toán xem có
hợp lý chưa để cuối cùng đưa ra bảng đánh giá xem có đạt chất lượng không?
Khác gì với Test?
Test gồm Review và Inspection(thanh tra)
Coding Inspection là gì?
Tất cả thành viên trong nhóm họp lại, đem toàn bộ mã nguồn ra đọc, xem
xét xem nó có đạt yêu cầu hay không, có đúng chuẩn code, có hợp lý hay
không?
Inspection : đảm bảo chất lượng tốt nhất mọi nơi.
4/Trình bày các khái niệm của quản lý rủi ro.
- Liệt kê được tất cả những rủi ro có thể xảy ra trong toàn dự án, và tỉm phương pháp
loại bỏ tất cả các rủi ro đó.
- Thường xảy ra đẩu dự án.
- Thường thể hiện rõ trong pha đầu của quản lý dự án.
- Nhiệm vụ chủa chúng ta trong quản lý rủi ro:
o Định danh, liệt kê, xác định được tất cả rủi ro có thể xảy ra.
o Quản lý được những rủi ro đó.
Định danh như thế nào?
- Đề xuất tất cả những rủi ro có thể xảy ra.
- Phân tích xem nó có đúng là rủi ro không.
- Xác định độ ưu tiên xem rủi ro nào cần giải quyết trước.
- Lên kế hoạch, phương pháp giải quyết.

- Tiếp tục theo dõi sau khi rủi ro đã được xử lý.
5/Trình bày các khái niệm của quản lý cấu hình
Quản lý cấu hình :làm thế nào đảm bảo tính toàn vẹn của tất cả các sản phẩm
trong tất cả các pha của quá trình phát triển phần mềm.
KX_CPHGHL Tây Ninh Page 4
Tính toàn vẹn: không mất mát, đầy đủ cho phép truy cập bất cứ lúc nào.
Sản phẩm: là tất cả mã nguồn, Statement of work, Spect, bản kế hoạch…
Quản lý cấu hình thực chất: là quản lý những phiên bản mà khi ta cần có thể truy
xuất nhanh và chính xác.
Quản lý cấu hình gồm 4 bước:
- định danh: trước khi bước vào 1 dự án nào ta cũng cần liệt kê tất cả những gì
cần được đảm bảo tính toàn vẹn: Spect, Design, Code, Version hệ thống…
- quản lý: sử dụng phần mềm lưu dấu vết những thao tác trên dự án đó: visual
SourceSafe,..
- quản lý trang thái: quản lý từng trạng thái thay đổi.
- kiểm kê: sau 1 thời gian ta ngồi kiểm tra lại tất cả cấu hình, phương pháp cần
quản lý cấu hình và phiên bản mới nhất…
 quản lý cấu hình giúp ta: làm việc an toàn hơn, nhanh hơn, cho sản phẩm
tốt hơn.
6/Trình bày về mô hình thác nước và các biến thể của nó.Nêu những thuận lợi và
khó khăn của mô hình này.
Tập hợp các pha liên tiếp nhau, pha sau chỉ thực hiện khi pha trước kết thúc và kết
thúc mỗi pha là 1 sản phẩm nhất định.
Gồm mấy bước là do ta chọn!
Ưu điểm: đơn giản, dễ áp dụng.
Khuyết điểm:
o không thể quay ngược lại để chỉnh sửa.
o pha sau phải đợi pha trước xong mới thực hiện được.
o áp dụng cho dự án nhỏ đơn giản hoặc dự án cực lớn.
a/ Biến thể SaShuMi

waterfall with subprojects : giống waterfall nhưng khác ở chỗ 2 pha có thể thực hiện
song song khi có một ít kết quả của pha trước không cần phải đợi pha trước kết
KX_CPHGHL Tây Ninh Page 5
thúc, chi thành các dự án con, 3 pha đầu phải giống waterfall tức làm pha trước làm
xong mới tới pha sau chứ không được chia.
Các pha thực hiện song song;
- ƯĐ và KĐ giống WaterFall.
- Ưu điểm hơn: pha sau không cần đợi pha trước hoàn thành.
- Khuyết điểm hơn: không phải dự án nào cũng chia nhỏ được.
b/ Mô hình thác nước kết hợp với giảm rủi ro
o Quan trọng nhất là yêu cầu.
o Do kết thúc 1 pha khog thể quay lại nên đảm bảo rủi ro xảy ra ít nhất có thể có
để chất lượng là cao nhất-> đưa quản lý rủi ro vào phần Requirement hoặc
phân tích thiết kế hệ thống là cần thiết. Tuy nhiên tùy vào năng lực của thành
viên tham gia vào dư án mà có sữ kết hợp cho phù hợp.
7/Trình bày về mô hình kiểu mẫu, mô hình xoắn ốc và mô hình chữ V?
I/ Prototype Model( Mô hình kiểu mẫu):chú trọng vào khâu thiết kế mô hình phần mềm
a.
Các bước của mô hình này: Tìm kiếm yêu cầu của khách hàng => mô tả ngắn
gọn các yêu cầu => xây dựng các mẫu( prototype: ko có dữ liệu hoặc dữ liệu giã
trong code, chỉ làm một vài chức năng chính của phần mềm) => đưa khách hàng
xem và đánh giá => sữa chữa lại mẫu( nếu cần) => quay nhanh lại tiếp tục
design => sữa chữa …… lặp…… đến khi mô hình đã hoàn chỉnh được kh chấp
nhận….. => engineer product( xây dựng thực sự).
b.
Giống với mô hình giảm thiểu rủi ro bằng cách đưa công việc quản lý rủi ro vào
pha thiết kế.
c.
Ưu điểm: khách hàng có thể xem trước được mô hình của sản phẩm, giảm thiểu
rủi ro trong thiết kế, dễ áp dụng.

d.
Khuyết điểm:
i.
Mang các khuyết điểm của mô hình thác nước.
ii.
Xây dựng mô hình không dễ dàng.
iii.
Tốn thời gian công sức.
KX_CPHGHL Tây Ninh Page 6
II/Spiral Model( mô hình xoắn ốc):
a.
Các bước giống hệt nhau trong từng vòng tròn nhưng phát triển rộng ra sau
mỗi vòng.
b.
4 bước không thể thiếu trong mô hình này là:
o
Xác định mục tiêu của chu trình hiện tại.
o
Xác định mục tiêu của chu trình tiếp theo.
o
Phát triển phần mềm và kiểm tra sản phẩm.
o
Đánh giá và phân tích rủi ro.
c.
Giảm thiểu rủi ro = cách phát triển từng mô hình sau đó phát triển sp thực sự.
d.
Khác với mô hình kiểu mẫu ở chổ mô hình này xây dựng hệ thống thực sự
của một số chức năng.
e.
Khuyết điểm: tốn thời gian, công sức, giống thác nước không quay lại bước

trước đó.
III/Mô hình chữ V:
8/Trình bày các khái niệm của phát triển lặp và tiến hóa.
- Phát triển lặp: là 1 mô hình phát triển phần mềm trong đó toàn bộ chu trình sống của
phần mềm được chia ra thành các vòng lặp hay pha kế tiếp nhau.(Lặp là làm đi làm lại
giống nhau).
- Kết quả của mỗi vòng lặp là 1 Release hoặc more realease + hệ thống hoàn chỉnh có
thể đưa cho KH sử dụng.
- Chia dư án nhỏ thành các vòng lặp khác nhau, kết thúc mỗi vòng lặp là 1 sp hoàn chỉnh
chạy đảm bào cấu hình đúng chức năng.
- Trong mỗi vòng lặp gồm: phân tích yêu cầu, thiết kế, code, Test, lăp đi lặp lại.
Chi tiết Quá trình lặp:
o xây dựng 1 số yêu cầu.
o chọn ra 1 số yêu cầu(vd 3 yêu cầu), bắt tay vào xây dưng pm đó, trong vòng 3
tuần làm sao đưa ra hệ thống sp chạy đủ yêu cầu đã chọn.
o đưa cho k/hàng sử dụng những chức năng đã hoàn thành.
o nhận phản hồi từ K/Hàng.
o chọn ra 1 số yêu hồi khác, xem xét ở bảng trước có cần chỉnh sửa gì không.
KX_CPHGHL Tây Ninh Page 7
o Xây dựng pm tiếp theo dựa trên pm đã hoan thành và chọn các yêu cầu khác
hoàn thành trong vòng 3 tuần.
o Tăng thêm 3 yêu cầu ta được thêm những chức năng mới ta đưa cho k/hàng sử
dụng và nhận phản hồi từ k/hàng,lại chọn yêu cầu , lại xdpm tiếp theo, lặp cho
đến khi đưa ra 1 release mà khàng có thể sdụng được.
Chú ý:
- Mô hình thác nước: phải hoàn thành yêu cầu ngay bước đầu sau đó mới design, hoàn
thành design mới chuyển bước, Lặp :chỉ là xây dựng 1 số yêu cầu.
- Khác với chia nhỏ(chỉ làm 1 phần nào đó) lặp làm tất cả nhưng m công việc được chia
đều.
- Mô hình xoắn ốc: reqiurement chỉ có ở 2 hay 3 vòng đầu của dự án còn lặp thì luôn hội

tụ đủ các yếu tố.
***Chu trình sống của 1 phần mềm k đổi mà chỉ thay đổi ở cách tiếp cận và xây dựng.
- KN TimeBox: cố định thời gian hoàn thành vòng lặp: lên lịch thời gian dealine cụ thể
cho từng công việc.
- KN Phát triển tiến hóa:
o chia ra thành các vòng lặp và thời gian cụ thể cho từng vòng lặp.
o Khó nhất là định lượng được 1 dự án.
o Sai số kho hoạch định dự án.
- Agile<thích nghi, nhanh, gọn, tốc độ>
{con người + sàn phẩm làm ra+ khách hàng+ sự thay đổi}
o Là 1 nhánh con của phát triển lặp, nó áp dụng các vòng lặp timebox + phát triển
tiến hóa có kế hoạch thích nghi luôn đưa ra các sản phẩm sớm đưa ra sản phẩm
theo chiều hướng tiến hóa dần.
<phát triển tiến hóa: làm phần mềm từ từ >
<sản phẩm sớm: áp dụng quy trình này sau vòng lặp 1 đã có sp >
<kế hoạch thích nghi: có kế hoạch thích nghi dần với dự án>
< sản phẩm theo chiều hướng tiến hóa dầncái sau bao gồm all chức năng cái
trước và luôn mở rộng>
o ĐĐ : Cho phép phát triển nhanh,mềmdẻo, thích ứng mọi sự thay đổi.
o tập trung vào sự tương tác của từng cá nhân thay vì công cụ.
KX_CPHGHL Tây Ninh Page 8
o tập trung vào sản phẩm phần mềm thay cho tài liệu: phần mềm chạy có tốt
không, có đạt yêu cầu không? Không quan trọng design, test cause, plan,
requirement,…
o tương tác với khách hàng thay vì hợp đồng?
o sẵn sàng cho sự thay đổi thay vì yêu cầu cố định ban đầu.
- POC ( Proot of Concertion) chứng minh cho KH thấy mình có khả năng làm được phần
khách hàng yêu cầu:
o Đưa ra 1 số phần mềm tương tự.
o Build 1 số phần mềm free với 1 số tính năng tương tự.

• Chú ý:
o Một số bước co bản : Ban đầu ta phảicó ý tưởng POC  xây dựng Phần mềm
nhỏ  đưa KH dùng nhận phải hồiquay lại tiếp tục tiến hóa dần lên.
o Khách hàng rất quan trọng: là người chạy phần mềm chứ k phải tester.
Sử dụng Story thay cho Requirement:
o Không yêu cầu cụ thể không cần các bước như requirement.
o Phát triển theo Agile cần đơn giản, dễ thay đổi.
o Nhiệm vụ của LTV là làm sao cho Story càng đơn giản càng thể hóa càng tốt.
**Agile gồm nhiều Story sắp xếp thứ tự từ cao đến thấp, ta làm từ cao đến thấp,
mỗi story có thể đưa vào bất cứ gia đoạn nào trong hoạt động của chúng ta.
9/Trình bày quy trình Scrum.
Scrum : là quy trình phần mềm được thiết kế dựa trên phát triển lặp.Gồm 3 bước:
o Pre – Game : chuẩn bị.
o Development : phát triển.
o Release : triển khai, sản phẩm, tài liệu hướng dẫn.
1/ Pre Game chia thành 2 bước nhỏ :
o Lên kế hoạch ( planning) :
 cần phải xem xét all những gì liên quan về dự án, có cái nhìn tổng thể
chung về dự án dự án này cần bao nhiêu nhân sự, tiền bạc, cần làm
những gì, có bao nhiêu stories…
 ngoài việc lên kế hoạch, ta còn xem xét có nên xây dựng 1 mô hình đơn
giản cho hệ thống không ? đưa ra bản sơ phác thảo về hệ thống chung,
 khác với các quy trình thác nước
KX_CPHGHL Tây Ninh Page 9
o Chuẩn bị bước đầu ( staging) : cần phải cụ thể yêu cầu của khách hàng, hiểu
rõ các stories, bản phác thảo sơ về hệ thống được hoàn tất trong bước này.
2/ Development: <quan trọng nhất>
- Nói đến Scrum là nói đến vòng lặp 30 ngày, là 1 ước lượng chuẩn, nhưng ta có thể
thay đổi tùy theo dự án. Sau 30 ngày ta phải đưa ra 1 ralease hoàn chỉnh.
- Sau khi xác định vòng lặp làm trong vòng 30 ngày, chuẩn bị các sprint backlog ( sprint

backlog là tập hợp các stories(xác dịnh công việc yêu cầu của khách hàng) làm trong
vòng 30 ngày). Toàn bộ hệ thống được chia ra thành các backlog , tập hợp tất cả các
backlog này gọi là product backlog.
- Đối với mỗi sprint( vòng lặp ) chúng ta chọn ra 1 backlog làm trong vòng 30 ngày đó.
- Chia các backlog này ra thành các công việc nhỏ hơn, cụ thể hơn gọi là backlog items (
bao gồm code, test …).
- Khách hàng đưa Product backlog( yêu cầu k/hàng = pbacklog), nhiêm vụ của K/hàng
là gủi cho chúng ta Product backlog; chọn 1 chức năng nổi bật(PBlog) và hoàn thành
trong 30 ngày. Việc chia nhỏ item là của nhóm phát triển phần mềm.
- Cứ sau 30 ngày đưa ra 1 release, cho đến khi hết các backlog thì dừng.
- Chia 30 ngày này thành từng ngày 1 : nhiệm vụ của 1 ngày là chia ra 15 phút họp mặt
làm việc lại với nhau, sau đó giải quyết các backlog items. Trong 15 phút họp nhóm
có 3 bước cơ bản cần giải quyết :
o Mỗi người chuẩn bị một danh sách các công việc đã làm được cái gì?
o Mỗi người đưa ra câu trả lời có việc gì ngăn chặn việc phát triển các backlog
item hay ko?
o Phải làm gì tiếp theo sau mỗi buổi họp này?
- Sau 15 phút phải làm thế nào để giải quyết được các công việc trên.
3/ Release: triển khai khách hàng, hướng dẫn hỗ trợ phát triển tài liệu.
( Scrum work products) Các sản phẩm cần có trong Scrum ( không tính mã nguồn ):
• Requirements :
 Release backlog : những gì đã làm được,
 Product backlog : những gì phải làm.
Chú ý: Không cần design, imlementation, test vì đã có tất cả trong product backlog.
KX_CPHGHL Tây Ninh Page 10