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ồiquay 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
• Project Management :
Backlog graph : biểu đồ các công việc cần làm trên số ngày còn lại.
Sprint backlog : đưa ra các công việc cho vòng lặp.
Product / Release backlog : giống phần requirements ( quá trình đưa ra
product và release backlog lặp đi lặp lại tùy vào sự thay đổi của khác hàng)
• Quản lý cấu hình:
Dùng tool để ql cấu hình, mã nguồn.
Nếu dùng srum để phát triển những sp có dấu gạch sẽ lặp đi lặp lại do
product backlog luôn thay đổi. tuy nhiên k có dấu gạch thi chỉ có 1
printbacklog. Nhưng trong lần đầu tiên có bao nhiêu cũng được tùy vào
k/hành.
• ( Scrum roles) Vai trò Scrum:
1/ Customer ( khách hàng ) : Khách hàng là quan trọng nhất.
o Trực tiếp hoặc gián tiếp tham gia vào quá trình này, nhiệm vụ quan trọng nhất
tạo ra các backlog và đưa ra mức độ ưu tiên.
o Chọn các backlog cho sprint tiếp theo.
o Sau đó xem các kết quả sau 30 ngày rồi đưa ra phản hồi, nhận xét.
2/ Scrum Team ( nhóm phát triển ):
o Nhóm này phát triển từng backlog một, ko có sự phân biệt ngôi thứ giữa các
thành viên, vai trò từng người trong nhóm là như nhau.
3/ Scrum Master ( trưởng nhóm ) :
o Người tham gia vào phát triển phần mềm ít nhất là 50% code.
o Có cái nhìn chung tổng quan về dự án.
o Quản lỳ được chất lương nhóm làm việc.
o Là cầu nối giữa các nhóm làm việc.
o Theo dõi quá trình phát triển và loại bỏ những khó khăn liên quan để quá trình
phát triển.
o Cần tổ chức các buổi họp hằng ngày và đưa ra các quyết định.
o Tổng hợp các review sprint ( phản hồi của khách hàng ) trong vòng 30 ngày.
4/ Chicken:
o người chỉ quan sát trong quá trình phát triển nhưng ko được tham gia hay có ý
kiến gì vào quá trình phát triển. Thường là tổng giám đốc , CEO…
(Scrum Practies) Quy trình scrum tiến hành như thế nào?
- Requirements bao gồm các bước:
KX_CPHGHL Tây Ninh Page 11
Pre-Game Planning (nói ở phần trên).
Sprint planning : 30 ngày tới sẽ làm gì dựa vào các backlog , lên kế hoạch.
Sprint review : tất cả những gì làm ra và các bug , ghi lại các phản hồi của khách
hàng sau mỗi vòng lặp.
- Design : thiết kế ở mức độ cấp cao ( như là gởi mail…)
- Test : là sprint review.
- Project management :
o Chống sự thay đổi của vòng lặp ( mỗi sprint là cố định ko thêm bất cứ gì vào ví
dụ thêm features).
o Chicken(tổng giám đốc, CEO) and Pigs(developer) : Tổng giám đốc , CEO ko
nói chuyện với developer
o Pregame planning : luôn có bản kế hoạch
o Tường lửa : các tài nguyên trong team làm việc là làm đúng theo backlog items
ko quan tâm đến bất cứ vấn đề gì xảy ra, developer ko quan tâm. Scrum master
giải quyết các vấn đề phát sinh .
o Daily scrum : họp 15 phút hàng ngày.
o Tự giác : tự giải quyết vấn đề của mình.
o Sprint planning : luôn có kế hoạch , viết rõ cụ thể từng hàng một bao gồm cái
gì.
o Sprint : 30 ngày, ko thêm ko thiếu ngày.
o Quyết định trong vòng 1 giờ : những gì khó khăn quyết định trong vòng 1 giờ,
ko quá 1 giờ.
o Block gone in 1 day : tất cả những gì trở ngại , khó khăn giải quyết trong vòng
1 ngày.
o Bảy người 1 nhóm.
- Quản lí cấu hình :
KX_CPHGHL Tây Ninh Page 12
Mỗi người lấy code người khác về build hằng ngày.
Developer phải hiểu code người khác.
- Lợi ích :
o Commitment : hiển thị rõ những gì cần làm.
o Focus : tập trung làm việc(phải luôn tạo ra backblog mới) vì đã có kế hoạch ở
mỗi ngày.
o Openness : mọi người ngang bằng, cởi mở với nhau, hàng ngày gặp 15 phút.
o Respect : tôn trong lẫn nhau, tự giải quyết vấn đề của mình, ko ai được phép can
thiệp.
o Courage : dũng cảm từ giải quyết vấn đề của mình.
10/Trình bày quy trình XP.
•
Extreme programming( mô hình XP): là một nhánh của agile.
o
Bắt đầu với các user stories với cái nhìn tổng quát về hệ thống -> release
planning, test statement ->(lặp) đưa cho khách hàng test ->( lấy phản hồi) bugs
o
Sau cuỗi mỗi vòng lặp sẽ có sản phẩm cho khách hàng test.
o
Bảng kế hoạch cho vòng lặp dựa vào user stories, bugs.
o
Mỗi ngày cũng có cuộc họp.
o
Collective code ownership: tất cả mọi người code chung để: fix bug, rút ra
kinh nghiệm-> chia sẽ hằng ngày
o
Pair programming: lặp trình đôi hai người cùng lập trình trên một máy tính
luân phiên.
o
Refactor: làm mềm dẻo hệ thống mà không phá vỡ hệ thống, không fix bug.
o
Move people around: chuyển người qua lại.
o
Crc card: là 1 hình thức xem mỗi liên hệ giữa các lớp.
o
Quy trình xp: có task -> chọn pair -> viết test <==> (sữa đổi cho đến khi
pass).
Xp work products:
1.
Story card: 1 mảnh giấy nhỏ.
1.
CRC card:
1.
Thiết kế sơ bộ hệ thống
1.
Implementation:
KX_CPHGHL Tây Ninh Page 13
1.
…
Đối với mô hình xp thì phần mềm và story card là hai thứ quan trọng nhất.
Xp roles:
1.
Customer: có nhiệm vụ kiểm thử, chọn ra các story card cho từng release.
1.
Programmer and tester
i.
Programmer: nhận các story và đưa ra các yêu cầu
i.
Tester: có nhiệm vụ test tất cả các hệ thống.
1.
Management:
i.
Coach: xem xét toàn bộ tiến trình làm việc, hướng dẫn giải quyết các vấn đề
phức tạp cho từng nhóm.
i.
Tracker:(hay QA) thu thập tất cả các dữ liệu về tiến trình làm việc của dự án,
theo dõi bug…
1.
Tư vấn ():(khác với scrum ở chỗ) những người tư vấn có thể nói chuyện với ltv
và trưởng dự án để đưa ra ý kiến trong khi Scrum thì không được đưa ra ý kiến.
Xp practices:
1.
Planning: phải luôn có kế hoạch.
1.
: khách hàng phải luôn bên cạnh, khi nào ltv cần thì sẽ có khách hàng.
1.
Test chấp nhận (acceptance test).
1.
Tất cả mọi người phải hình dung được dự án (vì mọi người cùng làm việc chung
cùng code chung, pair programming), thường xuyên refactor( sữa chữa hệ thống
mà không fix bua).
1.
Sử dụng các design đơn giản.
1.
Quá trình viết code luôn gắn liền với quá trình refactor dựa vào ý kiến chuyên
gia, tuân thủ các chuẩn code, thực hiện pair programming, team code owner
ship.
1.
Test chấp nhận( thực hiện bởi khách hàng), test first( viết unit test trước khi viết
code).
1.
Phần quản lý: planning(đối với phần quản lý) thực hiện nhiều release ngắn càng
tốt( quản lý thời gian làm release), quản lý từng bước, stand up meeting( phải có
những buổi họp mặt hàng ngày).
1.
Quản lý cấu hình: ( đảm bảo cho hệ thống chạy ổn định) tích hợp liên tục, hệ
thống tích hợp tự động hoặc có người chuyên dụng, phải có phòng chung, xài
chung tài nguyên.( đối với xp thì mỗi ngày trước khi làm việc phải lấy code của
mọi người vệ build thành công mới làm tiếp nếu không thì feedback lên cho
trưởng dự án).
KX_CPHGHL Tây Ninh Page 14
Không có nhận xét nào:
Đăng nhận xét